En el proceso de producción y validación de bloques de Ethereum, los constructores son responsables de ordenar las transacciones y enviar bloques a los proponentes a través de un mecanismo de subasta. Los proponentes luego seleccionan un bloque para firmarlo y proponerlo a la cadena de bloques. Dado que los proponentes tienen la última palabra como una entidad única, existe un riesgo de colusión entre los proponentes y los constructores para censurar transacciones.

Uno de los valores fundamentales de la cadena de bloques es su resistencia a la censura, lo que significa que las transacciones pueden realizarse sin interferencia de autoridades centrales. Cuando los proponentes controlan qué transacciones se incluyen en un bloque, esta característica se ve amenazada, comprometiendo la equidad y la transparencia. Además, este poder puede ser explotado para manipular el orden de las transacciones en un bloque, lo que conlleva ganancias económicas adicionales y plantea problemas relacionados con el Valor Extraíble por Mineros (MEV).

Soluciones existentes resistentes a la censura

Para abordar este desafío, la comunidad ha propuesto varias soluciones contra la censura, como las Listas de Inclusión Forzada (FOCIL). En el mecanismo FOCIL, se selecciona aleatoriamente un conjunto de validadores para cada ranura y se forma un comité de lista de inclusión. Estos miembros del comité generan listas de inclusión locales basadas en su visión subjetiva de la mempool y las transmiten. Los proponentes son responsables de recopilar y agregar estas listas locales en una lista agregada única que se incluirá en el bloque. Este mecanismo garantiza la imparcialidad en la inclusión de bloques, ya que los validadores verifican la lista agregada frente a las listas locales transmitidas previamente, y solo se aceptan y agregan bloques que cumplan con las reglas de consenso a la cadena de bloques.

Además de FOCIL, la comunidad también ha discutido esquemas de Múltiples Proponentes Concurrentes (MCP). Este concepto fue inicialmente propuesto por Max Resnicken elMultiplicidad mecanismo, que tiene como objetivo dispersar el poder mediante la introducción de múltiples proponentes de bloques paralelos, reduciendo la capacidad de un solo nodo para censurar transacciones. En el mecanismo de multiplicidad, cada validador selecciona una parte de las transacciones de su propio mempool para formar un "paquete de transacciones especial". Estos validadores firman los paquetes de transacciones elegidos y los envían al proponente de la ronda actual. El proponente debe incluir al menos 2/3 de estos paquetes de transacciones en el bloque que propone para que se considere válido. Este mecanismo garantiza que los proponentes no puedan decidir unilateralmente el contenido del bloque, reduciendo así la posibilidad de censura. Para incentivar aún más a los proponentes a incluir las transacciones de manera justa, este mecanismo implementa una regla de "propina condicional", en la que solo los proponentes que incluyen la transacción reciben las tarifas de transacción. Las tarifas de transacción no se otorgan automáticamente al primer proponente que incluye la transacción, sino que se distribuyen a todos los proponentes que realmente incluyen la transacción en función de condiciones específicas. Esto aumenta el costo de la censura, ya que sería necesario sobornar a todos los proponentes que incluyan la transacción.

BRAID: Una implementación mejorada de MCP

Basándose en el concepto de Multiplicity, Max Resnick presentó BRAID, una implementación más compleja y refinada de MCP. Max presentó BRAIDen el seminario “DeFi en la era MEV” organizado por Paradigm. BRAID logra el MCP al permitir que múltiples proponentes propongan bloques en diferentes cadenas paralelas y utilicen un mecanismo de consenso de sincronización para mantener la consistencia entre estas cadenas. Cada cadena tiene su propio proponente, y todos los proponentes liberan sus bloques simultáneamente dentro del mismo slot. La capa de ejecución de Ethereum agrega los bloques generados por todas las subcadenas dentro de ese slot, formando un bloque de ejecución. Luego, deduplica, ordena y ejecuta estas transacciones de acuerdo con reglas predefinidas, reduciendo la capacidad de cualquier entidad individual para manipular registros de transacciones.

El diseño de BRAID evita introducir roles adicionales, evitando así las complejidades asociadas con los mecanismos de incentivos/castigos. Sin embargo, su implementación es relativamente compleja, requiriendo la coordinación de la sincronización y el procesamiento de datos de múltiples subcadenas.

Problemas con el mecanismo BRAID

Jonahbdel equipo de Blockchain Capital señaló unproblemacon el mecanismo BRAID: el modelo de "propina condicional" impone requisitos de liquidez que afectan la experiencia del usuario. Este modelo es una estrategia de precios dinámicos que requiere que los usuarios proporcionen una cierta cantidad de liquidez para garantizar la resistencia a la censura de la transacción. Al enviar una transacción, los usuarios deben establecer dos valores de propina (T y t). La propina real pagada depende del número de proponentes que incluyen la transacción.

1. Un valor de propina más alto, T, representa la tarifa máxima que un usuario está dispuesto a pagar para asegurarse de que su transacción no sea censurada. El objetivo es incentivar a los proponentes a incluir la transacción incluso si ningún otro proponente está dispuesto a hacerlo. Si solo un proponente incluye la transacción, reciben la cantidad total, T.
2. Un valor de propina más bajo, t, es la cantidad mínima establecida por el usuario. Si la transacción es incluida por varios proponentes simultáneamente, el usuario solo necesita pagar t, que será compartido entre los proponentes. Si al usuario no le preocupa tanto la resistencia a la censura, puede establecer T igual a t y enviar su transacción solo a un proponente.

Sin embargo, este requisito adicional de liquidez aumenta la complejidad y el costo de participar en transacciones de blockchain. Los usuarios necesitan reservar fondos adicionales en el momento de la transacción únicamente para garantizar su resistencia a la censura. Estos fondos reservados permanecen congelados hasta que se utilizan realmente.

Para abordar este problema, Jonahb propuso dos soluciones:

• Prueba de liquidez del estado posterior a la publicación: Los usuarios proporcionan una prueba en el momento de la presentación de la transacción, indicando que tendrán suficiente liquidez para pagar T después de que se ejecute la transacción (por ejemplo, el usuario tendrá $1M en liquidez después de la transacción). Este método permite a los usuarios proceder incluso si no tienen suficientes fondos para pagar T antes de la transacción. El desafío con este enfoque es que los proponentes necesitan conocer el estado final de la transacción antes de la ejecución. Sin embargo, muchas transacciones financieras involucran estados compartidos (como múltiples transacciones que afectan el mismo saldo de la cuenta), lo que dificulta que los proponentes determinen con precisión el estado posterior a la transacción antes de que se finalice el orden de transacción. Este enfoque requiere pruebas personalizadas para cada tipo de transacción, lo que lo hace menos práctico.
• Seguro de censura: Introduce proveedores de seguro de terceros contra la censura (proveedores de CI) para garantizar el T del usuario. Los usuarios pagan una prima de seguro, rT, donde r se basa en la probabilidad de que la transacción sea censurada. Este enfoque reduce la necesidad de que los usuarios preparen inmediatamente una gran cantidad de liquidez y puede alertar a los usuarios si su T es demasiado bajo y corre un alto riesgo de censura. Sin embargo, establecer un mercado entre usuarios y proveedores de CI lleva tiempo.

Pensamientos de la comunidad sobre FOCIL vs. BRAID

Desarrollador del cliente Ethereum PrysmTerence notasuna ventaja significativa de BRAID es que no requiere participantes adicionales. La mayoría de los diseños de Lista de Inclusión (IL), incluido FOCIL, requieren un participante adicional, lo que agrega limitaciones de tiempo dentro de los espacios de Ethereum, como el tiempo para presentar la IL, actualizar las ofertas y que los validadores revisen la IL. Sin embargo, FOCIL es más simple y flexible de implementar en comparación con BRAID.

Investigador de ParadigmaDan Robinson apreciaEl diseño de BRAID para la priorización de transacciones no está determinado por un único líder (proponente), lo que mitiga eficazmente el MEV. Además, el mecanismo de propina condicional de BRAID incentiva el comportamiento de no censura, que no está presente en FOCIL.

Desarrollador Dev prefiereFOCIL sobre MCP, creyendo que FOCIL ofrece una resistencia más fuerte a la censura y es más fácil de implementar. También sugiere algunas mejoras para hacer que FOCIL sea más fácil de implementar.

Investigador de Ethereumbarnabe.eth vistasFOCIL como un mecanismo bastante general y escalable. Reconoce que BRAID podría mejorar algunas de las garantías proporcionadas por FOCIL, pero es cauteloso sobre el abandono completo del modelo basado en líderes. Cree que se necesita más trabajo para demostrar la viabilidad de BRAID.

declaración:

1. Este artículo es reproducido de [Investigación de ChainFeeds], el título original es 'El camino de Ethereum hacia la resistencia a la censura: ¿Quién es mejor, BRAID o FOCIL?', los derechos de autor pertenecen al autor original [0XNATALIE], si tiene alguna objeción a la reproducción, por favor contacte aEquipo de Aprendizaje de Gate , el equipo lo manejará lo antes posible de acuerdo con los procedimientos relevantes.

2. Renuncia: Las opiniones expresadas en este artículo representan únicamente las opiniones personales del autor y no constituyen ningún consejo de inversión.

3. Otras versiones del artículo en otros idiomas son traducidas por el equipo de Gate Learn, no mencionado en Gate.Gate.ioEl artículo traducido no puede ser reproducido, distribuido o plagiado.