El camino de Ethereum hacia la resistencia a la censura: BRAID vs. FOCIL
En el panorama en evolución de Ethereum, la batalla por la resistencia a la censura ha introducido varios mecanismos innovadores. Entre ellos, BRAID y FOCIL destacan como dos enfoques prometedores diseñados para proteger la integridad de la red minimizando el riesgo de censura de las transacciones.
Ambas soluciones abordan problemas críticos del proceso de propuestas en bloque, pero adoptan enfoques fundamentalmente distintos para alcanzar sus objetivos. Este artículo profundiza en los matices de estos dos mecanismos y explora cuál podría resultar más eficaz en última instancia.
Comprender la amenaza de la censura en Ethereum
En el núcleo del proceso de generación y validación de bloques de Ethereum hay dos actores principales: los constructores y los proponentes. Los constructores se encargan de clasificar las transacciones y enviar un bloque a los proponentes, que seleccionan un bloque para firmarlo y proponerlo a la blockchain.
Este proceso, sin embargo, crea una vulnerabilidad potencial. Dado que los proponentes tienen la última palabra sobre qué bloque se propone, existe el riesgo de colusión entre proponentes y constructores para censurar determinadas transacciones, amenazando así el principio de resistencia a la censura de Ethereum.
La resistencia a la censura es crucial para mantener la imparcialidad y transparencia de la blockchain. Si los proponentes pueden incluir o excluir transacciones de forma selectiva, se socava la naturaleza descentralizada de la red y puede conducir a la explotación del ordenamiento de las transacciones, dando lugar a problemas como el valor extraíble por mineros (MEV).
Soluciones existentes: MCP y FOCIL
Para hacer frente a este reto, se han propuesto varias soluciones resistentes a la censura, siendo dos de las más discutidas los mecanismos de Lista de Inclusión Forzada (FOCIL) y de Proponente Multiconcurrente (MCP).
Lista de inclusión forzosa (FOCIL)
FOCIL está diseñado para garantizar la equidad mediante la participación de un comité de validadores seleccionados al azar durante cada franja horaria.
Estos validadores crean listas de inclusión locales basadas en sus puntos de vista del mempool y difunden estas listas.
A continuación, el proponente agrega estas listas locales en una lista de inclusión final que se añade al bloque.
Este mecanismo garantiza que ningún proponente tenga el control total de las transacciones incluidas en un bloque, reduciendo así el riesgo de censura.
Los validadores verifican que el bloque cumple las normas de consenso antes de aceptarlo en la cadena de bloques.
Proponente multiconcurrente (MCP)
MCP introduce el concepto de múltiples proponentes concurrentes, sugerido por primera vez por Max Resnick en el mecanismo Multiplicity.
En este sistema, varios proponentes trabajan en paralelo, seleccionando cada uno una parte de las transacciones del mempool.
Estas operaciones se agrupan en «paquetes de operaciones especiales» y son firmadas por los proponentes. El proponente principal debe incluir al menos dos tercios de estos paquetes en el bloque propuesto para que se considere válido.
Este método descentraliza el poder de un único proponente y reduce significativamente la probabilidad de censura de las transacciones.
BRAID: Una aplicación MCP mejorada
Basándose en el concepto MCP, Max Resnick desarrolló BRAID, una aplicación MCP más sofisticada y completa.
Presentado durante el seminario «DeFi en la era MEV» organizado por Paradigm, BRAID permite a varios proponentes proponer bloques en distintas cadenas paralelas simultáneamente.
A continuación, estos bloques se sincronizan mediante un mecanismo de consenso para garantizar la coherencia entre cadenas.
La capa de ejecución de Ethereum consolida todos los bloques generados dentro de la ranura en un único bloque de ejecución, donde las transacciones se deduplican, ordenan y ejecutan de acuerdo con reglas predefinidas.
Este enfoque reduce significativamente el poder de una sola entidad para manipular los registros de transacciones.
Una ventaja clave de BRAID es que evita funciones adicionales o complejas estructuras de incentivos, que pueden añadir complejidad.
Sin embargo, coordinar la sincronización entre varias subcadenas y gestionar el procesamiento de datos plantea sus propios retos.
Retos y consideraciones en BRAID
A pesar de sus puntos fuertes, BRAID no está exento de problemas. Uno de ellos es el modelo de «propina condicional», que exige a los usuarios disponer de liquidez para garantizar que sus transacciones no sean censuradas. Los usuarios deben fijar dos valores de propina al enviar las transacciones:
- Punta más alta (T): La cantidad máxima que un usuario está dispuesto a pagar para asegurarse de que su transacción se incluye aunque se intente censurar. Si solo un proponente incluye la transacción, recibe el importe total de T.
- Punta inferior (t): Propina más pequeña que se paga si varios proponentes incluyen la transacción. En este caso, la propina se distribuye entre los proponentes que incluyen la transacción.
Este modelo, aunque eficaz para desalentar la censura, introduce complejidad y costes adicionales para los usuarios. Estos necesitan reservar liquidez extra en el momento de la transacción, que puede congelarse hasta que se determine si será necesaria.
Para abordar estos problemas, Jonahb de Blockchain Capital sugiere dos posibles soluciones:
- Prueba de liquidez postestatal: Este enfoque permite a los usuarios aportar pruebas de que dispondrán de liquidez suficiente para pagar la propina más alta una vez ejecutada la transacción. Sin embargo, esto requiere que los proponentes comprendan el estado posterior a la transacción, lo que supone un reto en transacciones que implican un estado compartido u operaciones financieras complejas.
- Seguro de censura: Este concepto introduce terceros proveedores de Seguros de Censura (CI) que garantizan la propina del usuario a cambio de una comisión. Esto reduce la carga inmediata de liquidez para los usuarios, pero requiere el desarrollo de un mercado entre usuarios y proveedores de IC.
Perspectivas comunitarias: FOCIL frente a BRAID
La comunidad Ethereum está dividida en cuanto a los méritos relativos de FOCIL y BRAID. Terence, desarrollador del cliente Prysm de Ethereum, valora que BRAID no requiera participantes adicionales, lo que simplifica el proceso en comparación con FOCIL, que introduce limitaciones de tiempo adicionales para presentar y verificar las listas de inclusión. Sin embargo, FOCIL se considera en general más fácil de aplicar y más flexible.
Dan Robinson, investigador de Paradigm, elogia BRAID por su enfoque de la priorización de las transacciones, que reduce eficazmente los riesgos de MEV. También destaca el mecanismo de propina condicional como un fuerte incentivo contra la censura, un aspecto del que carece FOCIL.
Por el contrario, el desarrollador Dev se decanta por FOCIL por su sencillez y su sólida resistencia a la censura, lo que sugiere que FOCIL ofrece una aplicación más sencilla y con menos complicaciones.
El investigador de Ethereum barnabe.eth reconoce que aunque BRAID puede ofrecer mejoras en ciertas áreas, se muestra cauto a la hora de abandonar por completo el modelo basado en líderes sobre el que se construyen FOCIL y otros diseños de IL, citando la necesidad de más investigación y pruebas para validar la viabilidad de BRAID.
Conclusiones: ¿Qué mecanismo es superior?
El debate entre BRAID y FOCIL subraya la complejidad de lograr la resistencia a la censura en Ethereum. El enfoque innovador de BRAID para descentralizar el poder de los proponentes y reducir el riesgo de MEV es convincente, pero conlleva importantes retos de implementación y requiere un mayor desarrollo.
FOCIL, aunque más sencillo y flexible, puede no ofrecer el mismo nivel de solidez frente a intentos de censura sofisticados.
En última instancia, la elección entre BRAID y FOCIL puede depender de las prioridades específicas de la red Ethereum en cada momento. A medida que el ecosistema siga evolucionando, ambos mecanismos podrían desempeñar un papel en el fortalecimiento de la resistencia de Ethereum a la censura, garantizando que la red se mantenga fiel a sus principios descentralizados.