jakiro
Autor: 0xnatalie
Durante el proceso de generación de bloques y verificación de Ethereum, el constructor es responsable de seleccionar y clasificar las transacciones del grupo de transacciones y enviar los bloques al propuesta a través de un mecanismo de subasta.El proponente selecciona un bloque de estos bloques enviados para la firma y lo propone a la cadena de bloques.Dado que el proponente, como entidad única, tiene la opción final, esto aumenta el riesgo de una posible colusión entre el proponente y el constructor para revisar la transacción.
Uno de los valores centrales de Blockchain es su resistencia a la censura, es decir, cualquiera puede comerciar sin interferencia con la autoridad central.Esta característica se ve amenazada cuando el propositor puede controlar qué transacciones se incluyen en el bloque.Lesionar la justicia y la transparencia.Y este poder se puede usar para manipular el orden de las transacciones en el bloque, obteniendo así beneficios económicos adicionales, causando problemas de MEV.
Soluciones anticensorias existentes
Para abordar este desafío, la comunidad ha propuesto una variedad de soluciones contra la censura, como la lista de inclusión forzada (FOCIL).En el mecanismo de focil, cada ranura (ranura de tiempo) seleccionará aleatoriamente un grupo de validadores para formar un comité que contiene listas.Estos miembros del comité generan listas de inclusión local basadas en sus respectivas opiniones subjetivas del grupo de transacciones (MEMPOOL).El proponente es responsable de recopilar y agregar estas listas locales para formar una lista agregada e incluirlas en el bloque.Este mecanismo garantiza la equidad de los bloques, porque el validador verificará la corrección de la lista agregada basada en la lista local que se transmitió anteriormente, y solo los bloques que cumplan con las reglas de consenso se aceptarán y agregarán a la cadena de bloques.
Además de Focil, la comunidad también discutió los esquemas de múltiples propuestas de concurrencia (MCP).Este concepto fue propuesto por primera vez por Max Resnick en el mecanismo multiplicativo, con el objetivo deReduzca la capacidad de un solo nodo para revisar las transacciones mediante la introducción de múltiples propuestas de bloques paralelos para diversificar la potencia.En el mecanismo de multiplicabilidad, cada validador seleccionará una parte de la transacción de su grupo de negociación para formar un «paquete de transacción especial».Estos validadores firman y envían su paquete de transacción seleccionado al propositor de la ronda actual.Después de que el proponente lo recibe, debe incluir al menos 2/3 de los paquetes de transacciones en su bloque propuesto.Solo de esta manera este bloque puede considerarse válido.Este mecanismo asegura que el propositor no pueda decidir el contenido del bloque por separado, reduciendo así la posibilidad de censura.Para incentivar aún más a los propuestas para incluir transacciones de manera justa, este mecanismo implementa la regla de «punta condicional», es decir, solo aquellos propuestas que incluyen la transacción pueden recibir consejos de transacción.La punta de la transacción no se da automáticamente al primer propuesta que contiene la transacción, sino que se distribuye a todos los propuestas que realmente contienen la transacción de acuerdo con ciertas condiciones.Esto aumenta el costo de la revisión, y si desea revisar, debe sobornar a todos los propuestas que incluyen la transacción.
Trenza: solución mejorada de implementación de MCP
Basado en la multiplicabilidad, Max Resnick proponió una trenza, que es una implementación de MCP más compleja e integral.En un seminario sobre «Defi en la era MEV» en poder de Paradigm, Max introdujo la trenza.La trenza implementa MCP al permitir que múltiples propuestas propongan bloques en diferentes cadenas paralelas y utilizando un mecanismo de consenso sincrónico para mantener la consistencia entre cadenas.Cada cadena tiene su propio proponente, y todos los propuestas publican sus bloques simultáneamente dentro de la misma ranura.La capa de ejecución de Ethereum recopila todas las transacciones de bloque generadas por las subcadenas en esta ranura para formar un bloque de ejecución, y deduplicar, clasificar y ejecutar estas transacciones de acuerdo con las reglas predeterminadas, reduciendo así la manipulación del registro de transacciones por cualquier entidad.
El diseño de la trenza no introduce roles adicionales, evitando así la complejidad del mecanismo de incentivos/castigo, pero su implementación es relativamente compleja y requiere la coordinación de la sincronización y el procesamiento de datos de múltiples subcanvencias.
Problemas con el mecanismo de trenza
Blockchain Capital Team Jonahb señaló un problema en el mecanismo de trenza: el modelo «Consejo condicional» tiene requisitos de liquidez, lo que afecta el impacto de la experiencia del usuario.Este modelo es una estrategia de fijación de precios dinámica que requiere que los usuarios preparen una cierta cantidad de liquidez para garantizar la resistencia a la censura de la transacción.Los usuarios deben establecer dos valores de punta (T y T) al enviar una transacción.Los consejos reales pagados al final dependen del número de propuestas que contienen la transacción.
-
Consejo T más alto T: Representa la tarifa máxima que el usuario está dispuesto a pagar para garantizar que no se revise la transacción.El propósito es incentivar al propositor para elegir incluir cuando ningún otro propomista está dispuesto a incluir una transacción.Eventualmente, si solo un propositor está dispuesto a incluirlo, obtiene una T.
-
Consejo inferior t: Esta es una cantidad más baja establecida por el usuario.T se asignará entre múltiples propuestas.Si el usuario no está preocupado por la resistencia a la censura, puede establecer T = T y enviar sus transacciones a un solo propositor.
Sin embargo, este requisito de liquidez adicional aumenta la complejidad y el costo de participar en las transacciones de blockchain.Estos fondos reservados se congelan hasta que realmente se usan.
En este sentido, Jonahb propuso dos soluciones:
-
Prueba de liquidez posterior al estado: Al enviar una transacción, el usuario proporciona una prueba de que habrá suficiente liquidez después de que la transacción se ejecute para pagar t (por ejemplo, el usuario tendrá liquidez de $ 1M después de la transacción).De esta manera, incluso si no hay suficientes fondos para pagar T antes de la transacción, el usuario puede pagar después de la transacción por prueba.El desafío de este enfoque es que el proponente debe comprender el estado final de la transacción antes de que se ejecute la transacción, pero la mayoría de las transacciones financieras implican un estado compartido (como las transacciones múltiples comparten el mismo saldo de la cuenta), por lo que el proponente no puede juzgar con precisión hasta el Se determina el estado de la transacción.Esto requiere pruebas personalizadas para cada tipo de transacción, lo cual es menos práctico.
-
Seguro de censura: Introducción a un proveedor de seguros de revisión de terceros (proveedor de IC) para proporcionar garantías a la T. de los usuariosEl usuario paga una RT de prima de seguro por esto, donde R se calcula en función de la posibilidad de que se revise la transacción.Esta solución no solo reduce la necesidad de que los usuarios se preparen para grandes cantidades de liquidez de inmediato, sino que también recuerda a los usuarios que T es demasiado bajo y que existe un alto riesgo de escrutinio a través de CI.Pero lleva tiempo construir un mercado entre usuarios y proveedores de CI.
Vistas de la comunidad sobre Focil y Braid
Desarrollador de Prysm de clientes de EthereumTerence cree que una ventaja significativa de la trenza es que no requiere participantes adicionales.En la mayoría de los diseños de la lista de inclusión (IL), incluido Focil, se requiere un participante adicional, lo que agrega restricciones de tiempo en las ranuras de tiempo de Ethereum, como el tiempo para enviar IL, el tiempo para actualizar las ofertas y el validador verifica el tiempo de IL.Sin embargo, la solución Focil es más simple y más flexible que la trenza.
El investigador de paradigma Dan Robinson aprecia el diseño de Braid en la priorización de la transacción, en lugar de ser decidida por el líder (propuesta única) mitigar de manera efectiva MEV.Además, los mecanismos de inflexión condicional en la trenza incentivan los comportamientos no censurados, que no se reflejan en Focil.
Dev, un desarrollador, prefiere Focil a MCP, cree que Focil tiene más ventajas en proporcionar una fuerte resistencia y simplificar la implementación.Y se proporcionan algunas mejoras para hacer que Focil sea más fácil de implementar.
El investigador de Ethere Barnabe.eth cree que Focil es un mecanismo bastante general y escalable. Este no es un consenso en este momento y se necesita más trabajo para demostrar su viabilidad.
