V El pensamiento más reciente de Dios: Dos formas de resolver el problema MEV bajo el mecanismo de consenso PoS

Un agradecimiento especial a Justin Drake y al equipo de Flashbots por sus comentarios y debates. Un riesgo importante que amenaza la continua descentralización de la red de consenso gira en torno a la economía del valor extraíble por el minero (MEV), el complejo arte de beneficiarse de la capacidad de elegir el contenido del siguiente bloque. Tomemos un ejemplo simple de MEV: arbitre todos los DEX en cadena contra los cambios de precios que han ocurrido desde el último bloque. Si bien las recompensas generales de PoS son bastante igualitarias, ya que un solo validador obtiene la misma tasa de rendimiento que un grupo de validación sólido, existen importantes economías de escala para encontrar oportunidades de extracción de MEV complejas. En pocas palabras, un grupo que es 10 veces más grande tiene 10 veces más la oportunidad de extraer MEV, y puede dedicar más esfuerzo a la optimización para extraer más de cada oportunidad de ganancias. Además de este problema, MEV también complica los pools descentralizados, porque en los pools descentralizados todavía debe haber una entidad responsable de empaquetar y proponer bloques, y pueden retirar fácilmente MEV en secreto sin tener que ponerse en contacto con el propio pool de ingresos divididos. La solución más conocida es la división proponente/constructor de bloques. En lugar de que los proponentes de bloques intenten producir bloques que maximicen los ingresos por sí mismos, confían en un mercado en el que los actores externos que llamamos constructores de bloques producen paquetes que contienen el contenido completo del bloque y las tarifas del proponente, y el proponente elige el paquete con el costo más alto. La selección del proponente se reduce a elegir el paquete con la tarifa más alta, un algoritmo tan simple que en un grupo descentralizado incluso se puede hacer dentro del MPC para evitar el fraude. Esta publicación presenta algunos diseños sobre cómo se puede lograr esto. Vea también las ideas de 2018 que están estrechamente relacionadas con las ideas aquí: Esquema de compromiso de propuesta optimizado Nos centraremos en cinco propiedades deseadas principales: 1. Amabilidad del proponente que no es de confianza: hay poco o ningún riesgo de que un proponente engañe a un creador de bloques, por lo que los creadores de bloques tienen ningún incentivo para elegir un proponente con cierta reputación fuera de la cadena o una relación personal con el constructor (ya que esto beneficiaría a los grandes grupos). 2. Compatibilidad con constructores que no son de confianza: hay poco o ningún riesgo de que un constructor de bloques engañe a un proponente, por lo que los proponentes no tienen ningún incentivo para elegir un constructor con alguna reputación fuera de la cadena o una relación personal con el proponente (ya que esto haría que sea más difícil para ellos). nuevos constructores para entrar en el mercado). Si se requiere un depósito para lograr esto, el umbral debe mantenerse lo más bajo posible. La billetera de firmas múltiples Gnosis Safe ha completado la segunda instantánea de Airdrop de retroceso: Golden Finance News, el gerente de producto del equipo de Gnosis, Lukas Schor, dijo en Twitter que la billetera de firmas múltiples Gnosis Safe ha completado la segunda instantánea de Airdrop de retroceso para los usuarios, pero no ha revelado la altura de bloque específica de la instantánea. Según noticias anteriores, se aprobó la propuesta de GnosisDAO de escindir Gnosis Safe y lanzar tokens SAFE, que se utilizarán para administrar el ecosistema y la infraestructura de Gnosis Safe. Al mismo tiempo, GnosisDAO establecerá una Safe Foundation independiente en Suiza para proteger los activos estratégicos fuera de la cadena (IP, repositorio de Github, inversión estratégica). Según la propuesta, Safe Foundation acuñará mil millones de tokens SAFE. [2022/5/21 3:31:36] 3. Amabilidad débil para los proponentes: el mecanismo no debe requerir que los proponentes tengan (i) un gran ancho de banda u otros recursos informáticos o (ii) una alta complejidad técnica. 4. Los paquetes no se pueden robar: los proponentes no deben aceptar paquetes propuestos por los constructores de bloques y extraer transacciones de ellos para hacer sus propios paquetes, evitando así que los constructores de bloques se beneficien (y posiblemente les perjudiquen aún más). 5. Simplicidad y seguridad de la capa de consenso: desde la perspectiva de la capa de consenso, el mecanismo debe seguir siendo seguro y es mejor realizar el mismo análisis que el mecanismo de propuesta de bloque existente. 1. Los constructores de bloques generan paquetes y publican los encabezados de los paquetes que crean. Un encabezado de paquete contiene un compromiso con el cuerpo del paquete (el contenido esperado del bloque), el pago al proponente y la firma del Constructor. 2. El proponente elige el encabezado del paquete que ofrece el pago más alto (solo considerando los paquetes en los que el constructor tiene saldo suficiente para pagar). Firman y publican propuestas que incluyen este encabezado de paquete. 3. Después de ver la propuesta firmada, el creador de bloques que proporcionó el encabezado del paquete publicará el paquete completo. En este punto, la regla de elección de la bifurcación es capaz de tomar una de tres decisiones (en lugar de las dos habituales): 1. La propuesta de bloque no existe 2. La propuesta de bloque existe, pero el cuerpo del paquete no existe 3. El bloque la propuesta existe y el cuerpo del paquete aún se está procesando (pero los constructores de bloques no reciben ninguna tarifa ni adquieren MEV por sí mismos). Messari agrega Secret Network a su registro: según las noticias oficiales de Twitter, la cadena pública de privacidad Secret Network ha sido agregada a su registro (Messari Registry) por Messari para mejorar la transparencia del proyecto. Se informa que Messari Registry es un centro de depósito de código abierto para información de proyectos encriptada. [2020/12/17 15:35:31] Tres de las cinco propiedades se satisfacen fácilmente: 1. El proponente acepta el pago prometido incondicionalmente, por lo que el paquete no puede engañar al proponente 2. Los tres pasos están muy automatizados y son de bajo costo 3. Los proponentes no pueden ver el contenido del paquete que están firmando, por lo que satisface la propiedad de no robo del paquete y la propiedad de la capa de consenso, y no es confiable. Este diseño cambia la forma en que funciona la elección de la bifurcación, aumentándola de 2 a 3 opciones, lo que también significa que el proponente ya no es el último jugador en el juego. En teoría, uno podría deducir que si la elección de la bifurcación pudo tomar la decisión, entonces esto debería estar bien, pero aún es un cambio de ruptura potencialmente desconocido. Los proponentes no pueden ver el contenido del paquete, ni pueden engañar a los constructores de bloques mediante el robo de paquetes, pero pueden usar ataques más sutiles contra los constructores de bloques. Pueden publicar su propuesta al final de un período de tiempo, asegurándose de que el probador (probablemente) vea la propuesta a tiempo, pero no puede darle al creador de bloques tiempo suficiente para publicar el cuerpo, por lo que es probable que el probador no vea el cuerpo. a tiempo Esto crea un riesgo para los constructores de bloques y los incentiva a favorecer a los proponentes confiables. Además, crea una oportunidad a través de la cual una mayoría malintencionada puede imponer fuertes sanciones a los constructores de bloques que no les gustan. Para este problema, creo que hay dos mitigaciones: 1. El probador tiene un retraso de 2 segundos entre el tiempo máximo que tarda en aceptar una propuesta y el tiempo máximo que tarda en hacerse cuerpo. Si confía en el probador, esto básicamente resuelve el problema, aunque permanece el problema básico de los constructores de bloques que corren el riesgo de perder fondos. Además, no está claro si los probadores tienen incentivos para votar de esta manera (aunque podrían verse obligados a esperar al exigirles que prueben una solución VDF de 2 segundos de duración propuesta). 2. Si no se incluye un cuerpo, el proponente solo recibirá la mitad del pago (y el constructor del bloque solo pagará la mitad). Esto hace que el daño malicioso sea costoso para los proponentes, pero aún garantiza que el daño malicioso para los constructores de bloques siga siendo costoso (en ambos casos, el costo es lo suficientemente alto como para convencerlo de que incluso los participantes anónimos no quieren hacerlo). Por ejemplo, si un paquete tiene una tarifa de proponente de 1 y una ganancia de constructor de bloque de 1,05: (1) el comportamiento honesto resultará en (constructor, proponente) recompensas de (0,05, 1); (2) proponente o Si el probador publica demasiado tarde, resultando en un bloque con solo el encabezado aceptado, la recompensa es (-0.5, 0.5) 1. Los constructores de bloques hacen paquetes y publican los encabezados de paquetes que crearon. Un encabezado de paquete contiene un compromiso con el contenido, un pago al proponente y una firma del constructor. 2. El proponente elige y firma una declaración que consta de la lista de encabezados de paquetes que ve. 3. Después de ver la declaración, el generador de bloques seleccionado publica su cuerpo de paquete correspondiente. 4. El proponente elige un encabezado de paquete de su lista precomprometida y publica una propuesta con él. Hay una nueva condición de slashing que expulsa y penaliza a cualquier proponente que publique una propuesta que no pertenezca (dentro del mismo período de tiempo) a la lista. También tenga en cuenta que la lista de encabezados de paquetes enviados por el proponente en el paso (2) también puede ser una lista de hashes cifrados de los encabezados, donde cada hash se cifra con la clave pública del creador de ese paquete para que solo el creador o para saber si son aceptados. Esto reduce el riesgo de ataques DoS. Del mismo modo, tres de las cinco propiedades son fáciles de satisfacer: los proponentes no pueden robar paquetes, porque solo pueden ver el cuerpo de cualquier paquete si se han restringido a un conjunto limitado de encabezados de paquetes existentes. Sin incluir el cuerpo completo, no puede ocurrir ningún pago del constructor al proponente y, por lo tanto, el proponente no puede engañar económicamente al constructor. Las propiedades de consenso siguen siendo las mismas que antes, ya que el sistema sigue siendo un juego de proponente-último actor, y no hay cambios en lo que determinan las reglas de consenso. Las dos propiedades más difíciles de garantizar en este caso son la facilidad de uso para los proponentes débiles y la facilidad de uso para los constructores de bloques que no son de confianza. De manera preocupante, los creadores de bloques maliciosos podrían atacar a los proponentes proponiendo una gran cantidad de propuestas, todas las cuales ofrecen tarifas muy altas, pero nunca publicando el cuerpo de ninguna de ellas. Si los proponentes tienen un límite superior sobre la cantidad de paquetes que aceptan, este ataque puede eliminar el precio de todos los paquetes legales y dejar al proponente sin paquetes que puedan incluirse legalmente en su bloque. Si no hay un límite en la cantidad de paquetes que un proponente puede aceptar, esto podría resultar en el envío de una cantidad infinita de cuerpos de paquetes completos (piense en 500 kb cada uno) al proponente, lo cual es un requisito de ancho de banda enorme. Una solución a este dilema es clasificar los envíos de encabezados de paquete de límite de alguna manera que no esté estrictamente limitada. 1. La tarifa por enviar paquetes se ajusta a través de algún mecanismo similar a EIP-1559 para lograr una tarifa determinada (por ejemplo, 8 paquetes por ranura). 2. Los requisitos de depósito como constructor de bloques, y la regla de que cuando se incluye un paquete con un precio más bajo, pero el paquete que lanzó no está incluido, entonces no puede enviar el paquete para la siguiente bolsa de N tragamonedas. La tarifa en sí también puede cobrarse solo si su paquete no la incluye, pero un paquete de menor precio sí lo incluye, ya que este es un caso específico en el que puede estar actuando maliciosamente (o el proponente es malicioso o la red es mala). Hay un precedente para esto, como la tarifa de perdedor del 0,5% en las subastas de ENS para disuadir a las personas de ofertar cuando está claro que no ganarán (solo para aumentar la cantidad que el ganador debe pagar). Sin embargo, estas técnicas corren el riesgo de introducir requisitos de confianza en el proponente, por lo que esto debe hacerse con cuidado, y la sanción por no incluir el paquete no puede ser demasiado alta. Otra solución es permitir la distribución gratuita e ilimitada de paquetes de cuerpos, pero restringir la propagación de cuerpos en la capa de red. Un algoritmo simple consiste en agregar un ligero retraso al tiempo mínimo que el cuerpo del paquete puede propagar: el paquete que más paga tiene un retraso de 0 segundos, el segundo paquete que más paga tiene un retraso de 0,2 segundos y el tercer paquete que más paga tiene un retraso de 0,2 segundos. retraso de 0 segundos El retraso es de 0,38 segundos, y el K-ésimo paquete mejor pagado tiene un retraso de 0,38 segundos. Agregue una regla de que si un nodo ya ha transmitido un cuerpo de paquete de ingresos más altos, el nodo no transmitirá otro cuerpo de paquete. Estas dos técnicas se pueden combinar: puede cobrar una pequeña tarifa para reducir la cantidad esperada de paquetes a (digamos) 50 por ranura y luego usar tales mecanismos de capa de red para reducir aún más los requisitos de ancho de banda. A partir de ahora, no puedo decir si los dos métodos anteriores son la única forma de resolver el problema, puede haber otras formas. De los dos enfoques, la idea (1) es conceptualmente más simple, pero presenta riesgos para los constructores de bloques y requisitos de reglas de selección de bifurcaciones más complejos. Si bien la idea (2) es más simple desde una perspectiva de consenso y selección de bifurcaciones, presenta desafíos al tratar con ataques DoS de generadores de bloques maliciosos, y es probable que cualquier solución a este problema también genere otros problemas (aunque Imagine esto se puede minimizar). Hasta ahora, todavía no estoy seguro de qué solución es mejor..

Tags：

TUSD