Diseño de mercado de tarifas compatible con la separación entre el proponente y el constructor de bloques.

Autor | Vitalik Buterin

Un agradecimiento especial a Justin Drake y al equipo de Flashbots por sus comentarios y debates.

Una amenaza significativa para las redes de consenso descentralizadas en funcionamiento hoy en día se refiere a la economía del valor extraíble de los mineros, el complejo arte de extraer ganancias de la capacidad de elegir el contenido del siguiente bloque. Un ejemplo simple de MEV es el arbitraje en todos los intercambios descentralizados en cadena en función del movimiento de precios del bloque anterior. Si bien normalmente las recompensas de PoS son razonables e incluso, es decir, la tasa de rendimiento para un solo validador es la misma que para un grupo de participación fuerte, encontrar oportunidades de extracción de MEV complejas ha resultado en economías de escala bastante significativas. Un grupo 10 veces más grande tiene 10 veces más posibilidades de extraer MEV, pero el grupo también debe poder invertir más en optimizaciones patentadas para extraer más valor por oportunidad.

Además de este problema, MEV también complica los grupos de participación descentralizados, porque en los grupos de participación descentralizados, las transacciones de empaquetamiento y la propuesta de bloques aún deben ser realizadas por una entidad, y pueden retirar fácilmente MEV en secreto en lugar de distribuir estos ingresos en el grupo.

La más conocida es la separación entre el proponente del bloque de soluciones y el constructor del bloque. En lugar de que los propios proponentes de bloques generen un bloque que maximice los ingresos, confían en un mercado compuesto por constructores de bloques externos que generan paquetes de transacciones que contienen el contenido completo del bloque y las tarifas para el proponente del bloque. El proponente luego selecciona el paquete de transacciones que contiene la tarifa más alta. De esta manera, la selección del proponente del bloque se reduce a seleccionar el paquete de transacciones con la tarifa más alta, que puede implementarse mediante un algoritmo simple: en un grupo descentralizado, incluso se puede hacer en MPC (Multi-Party Computation) para prevenir el engaño.

En este artículo se proponen algunos diseños sobre cómo lograrlo.

La idea de este artículo está muy directamente inspirada en este artículo de 2018: 

Esquema de compromiso de propuesta optimizado 20

Propiedades deseadas de un diseño de propuesta de bloque dividido de proponente/constructor

Las cinco características principales deseadas en las que nos centraremos:

No es necesario confiar en la amabilidad del proponente: el riesgo de que un proponente intimide a un constructor de bloques es prácticamente cero, por lo que los constructores de bloques no tienen ningún incentivo para favorecer a los proponentes fuera de la cadena con un grupo de compromiso).

No es necesario confiar en la amabilidad de los constructores: el riesgo de que los constructores intimiden a los proponentes es casi cero, por lo que los proponentes no tienen ningún incentivo para favorecer a los constructores fuera de la cadena con reputaciones o relaciones personales con los constructores (ya que esto podría llevar a que los nuevos constructores que ingresan al mercado no sean seleccionados). ).

Amabilidad débil para los proponentes: este mecanismo no debería requerir que los proponentes tengan (i) un gran ancho de banda u otros recursos informáticos, o (ii) una gran habilidad

Paquetes de transacciones que no se pueden robar: los proponentes no deberían poder aceptar paquetes de transacciones propuestos por los constructores de bloques y extraer transacciones de ellos para formar sus propios paquetes de transacciones, lo que evita que los proponentes de bloques obtengan ganancias (y potencialmente les perjudique aún más)

Secretario del Tesoro de EE. UU.: Las monedas estables necesitan una regulación adecuada: la Secretaria del Tesoro de EE. UU., Yellen, dijo que las monedas estables necesitan una regulación adecuada. Las monedas estables pueden mejorar la eficiencia y facilitar los pagos, pero solo si están adecuadamente reguladas. (Diez dorado) [2021/12/1 12:42:19]

Mantenga la capa de consenso simple y segura: desde la perspectiva de la capa de consenso, el mecanismo debe mantener la seguridad sin cambios, y es mejor poder usar el mismo marco de análisis con el mecanismo de propuesta de bloque existente.

Idea 1

Los constructores de bloques crean paquetes de transacciones y publican encabezados de paquetes para esos paquetes de transacciones. Un encabezado de paquete contiene un compromiso con el cuerpo del paquete (el contenido esperado del bloque), información de pago para el proponente y la firma del constructor.

El proponente elige el encabezado del paquete que ofrece la tarifa más alta (solo necesita considerar si el creador del paquete realmente tiene suficiente saldo para pagar). Firman el encabezado de la transacción y emiten una propuesta que contiene el encabezado de la transacción.

Al ver una propuesta firmada, el creador de bloques que proporcionó el encabezado del paquete de transacciones empaquetadas publica el paquete de transacciones completo.

En este momento, la regla de selección de bifurcación puede hacer uno de los tres juicios siguientes (en lugar de los dos habituales, existencia de bloque frente a no bloqueo):

No hay propuesta de bloque

Hay una propuesta de bloque pero no un cuerpo de paquete de transacción

Existen tanto propuestas de bloque como cuerpos de paquetes de transacciones.

Tenga en cuenta que en el segundo caso, la propuesta aún se incluirá en la cadena y el pago del constructor del bloque al proponente aún se procesará (pero el propio constructor del bloque no recibirá ninguna tarifa ni MEV).

Analizar

Tres de las cinco propiedades son bastante fáciles de presentar:

Los proponentes de bloques aceptan los pagos prometidos incondicionalmente, por lo que los paquetes de transacciones no pueden intimidar a los proponentes.

Los tres pasos están muy automatizados y tienen un ancho de banda bajo, por lo que esto satisface la amabilidad del proponente débil.

Los proponentes no pueden ver la información sobre los paquetes que desean firmar, por lo que esto satisface la imposibilidad de robar los paquetes.

Las propiedades de la capa de consenso y la amabilidad del proponente sin confianza son más complicadas. De hecho, este diseño cambiará el mecanismo de selección de horquillas de dos opciones a tres, lo que significa que el proponente ya no será el último actor en este mecanismo. En teoría, uno podría razonar que si la elección de la bifurcación es la toma de decisiones, entonces esto debería estar bien, pero sigue siendo un cambio importante con posibles incógnitas.

Los proponentes de bloques no pueden ver el contenido de los paquetes de transacciones y no pueden intimidar a los constructores de bloques robando paquetes de transacciones, pero pueden lanzar un ataque más sutil contra los constructores de bloques. Podrían publicar la propuesta al final del espacio, asegurándose de que el probador (presuntamente) vea la propuesta a tiempo, pero el generador de bloques no tiene tiempo suficiente para publicar el cuerpo del paquete de transacciones, por lo que es muy probable que el Prover no verá el cuerpo del paquete de transacciones a tiempo. Esto crea un riesgo para los constructores de bloques y los alienta a favorecer a los proponentes confiables. Además, brinda la mayor posibilidad de que los actores malintencionados penalicen fuertemente a los constructores de bloques que no les gustan.

Creo que hay dos conjuntos de formas de aliviar este problema.

Los probadores tienen un retraso de 2 segundos entre el tiempo máximo en que aceptan una propuesta y el tiempo máximo en que aceptan el cuerpo de un paquete de transacciones. Si confía en el probador, esto básicamente resuelve el problema, aunque aún existe el riesgo de que el constructor de bloques pierda sus fondos. Además, no está claro si existe un incentivo para que los probadores voten de esta manera (aunque uno podría forzarlos a esperar pidiéndoles que prueben una propuesta para una función de verificación diferible de 2 segundos)

Si no se incluye el cuerpo del paquete de transacciones, el proponente solo recibe la mitad del pago (y el constructor del bloque solo paga la mitad). Esto hace que el sabotaje del proponente sea costoso, pero aún asegura que el sabotaje del constructor de bloques también sea costoso (cuando el costo es lo suficientemente alto en ambos casos, en general, puede confiar en que incluso los actores anónimos no querrán cometer actos de vandalismo). Por ejemplo, si la tarifa del proponente para un paquete de transacciones es 1, el constructor de bloques gana 1,05:

Los pagos del constructor y del proponente por un comportamiento honesto son 0,05 y 1, respectivamente.

Un proponente o probador publica demasiado tarde, lo que hace que solo se acepte el encabezado del bloque, por lo que las recompensas para el creador y el proponente son -0,5 y 0,5, respectivamente.

Idea 2

Los constructores de bloques construyen y publican paquetes de transacciones. Los encabezados de transacción contienen un compromiso con el contenido, un pago al proponente y la firma del constructor.

Los proponentes hacen una selección de los paquetes de transacciones que ven, forman una lista y firman la declaración de la que consta la lista.

Al ver esta declaración, el constructor de bloques elegido publica el cuerpo del paquete de transacciones correspondiente.

Un proponente selecciona uno de una lista de encabezados de transacción con los que se ha comprometido previamente y lo usa para emitir una propuesta.

También se requiere una nueva condición de corte, donde cualquier proponente que proponga un paquete de transacciones en el mismo espacio que no está en su lista de compromiso será expulsado y penalizado.

También tenga en cuenta que en el paso 2, la lista de encabezados de transacción enviados por el proponente también puede ser una lista de hash cifrados de los encabezados de transacción, donde los hash se cifran con la clave pública del constructor de bloques, por lo que solo el constructor sabe si fueron aceptados. . Esto reduce el riesgo de ataques DoS.

Asimismo, el trinomio de las cinco propiedades es bastante fácil de mostrar:

Los proponentes no pueden robar paquetes de transacciones porque solo pueden ver el cuerpo de un paquete de transacciones cuando se han restringido a un conjunto limitado de encabezados de paquetes de transacciones existentes.

Es imposible que el constructor pague al proponente hasta que se haya empaquetado el paquete completo de la transacción, por lo que el proponente no puede engañar económicamente al constructor.

La característica de consenso se mantiene sin cambios, porque el establecimiento del sistema sigue siendo el proponente como último actor del mecanismo, y el contenido determinado por las reglas de consenso no ha cambiado.

En este caso, las dos propiedades más complicadas son la amabilidad del proponente débil y la amabilidad del constructor de bloques sin confianza. La preocupación con este esquema es que los constructores de bloques maliciosos podrían atacar a los proponentes haciendo muchas propuestas con tarifas de transacción altas, pero nunca publicando el cuerpo de estos paquetes de transacciones. Si el proponente tiene un límite superior en el número de paquetes de transacciones aceptados, este ataque puede excluir todos los paquetes de transacciones legales, de modo que el proponente no tenga paquetes de transacciones legales para proponer que se incluyan en el bloque. Si el proponente no tuviera un límite en la cantidad de paquetes que podría aceptar, entonces podría haber una cantidad infinita de cuerpos de paquetes completos (piense: 500 kB cada uno) enviados al proponente, lo que requeriría una gran cantidad de ancho de banda.

Una solución a este dilema es limitar de alguna manera la tasa de envío de encabezados de transacciones, que no es un límite estricto.

Hay una tarifa para enviar paquetes, escalada a una tarifa determinada (por ejemplo, 8 paquetes por ranura) a través de un mecanismo similar a EIP-1559

Convertirse en un proponente de bloque requiere un depósito (necesario de todos modos para garantizar que se le pague al proponente) y una regla que establece que si publica un paquete de transacciones que no está incluido, pero se incluye un paquete más barato, entonces no puede enviar paquetes de transacciones en los próximos N tragamonedas

Las tarifas se deducirán solo en este caso: su paquete de transacciones no está empaquetado, pero el paquete de transacciones de menor precio está empaquetado, porque en este caso específico puede ser que usted sea malvado (o que el proponente sea malvado, o que el estado de la red no bien).

Hay un precedente para esto, las subastas anteriores de ENS tenían una tarifa de perdedor del 0,5% para desanimar a alguien a ofertar cuando estaba claro que no iba a ganar, lo que obligaba al ganador a pagar más.

Sin embargo, estas técnicas pueden introducir requisitos de confianza en el proponente, por lo que deben manejarse con cuidado, y la sanción por no empaquetar paquetes de transacciones no debe ser demasiado alta.

Una alternativa es permitir la publicación gratuita y sin restricciones de cuerpos de paquetes de transacciones, pero restringir los cuerpos para transmitir en la capa de red. Un algoritmo simple es:

Agregue un límite de tiempo mínimo levemente retrasado para que los paquetes se propaguen: 0 segundos para el paquete con el precio de transacción más alto, 0,2 segundos para la segunda transacción más alta, 0,38 segundos para la tercera transacción más alta, en términos generales para la k-ésima transacción más alta El tiempo de transacción del precio es 2∗[1−0.9^(k−1)] segundos.

Se agregó una regla: si un nodo ya ha transmitido un cuerpo de paquete de transacción con una tarifa de transacción más alta, no puede transmitirlo nuevamente.

Estas dos técnicas se pueden combinar: puede reducir la cantidad esperada de paquetes de transacciones con una tarifa baja, digamos 50 paquetes por ranura, y luego usar mecanismos de capa de red como este para reducir aún más los requisitos de ancho de banda.

Conclusión

Hasta ahora, no sé si solo los dos métodos anteriores pueden resolver este problema, puede haber otros. De los dos enfoques, la idea (1) es conceptualmente más simple, pero crea riesgos para los constructores de bloques e introduce requisitos de reglas de selección de bifurcaciones más complejos. Idea (2) es más simple en la selección y el consenso de la bifurcación, pero tiene dificultades para lidiar con los ataques DoS provocados por constructores de bloques maliciosos, y cualquier solución a este problema es resistente a otros problemas, aunque es una forma concebible de minimizarlo. Hasta ahora, todavía no estoy seguro de cuál es mejor.

Tags：

Precio de Bitcoin USD