Discusión sobre soluciones viables para mejorar la velocidad de confirmación de transacciones en Ethereum

Un indicador importante de la experiencia del usuario en blockchain es el tiempo de confirmación de las transacciones. Ethereum ha mejorado significativamente en este aspecto en comparación con hace cinco años. Actualmente, las transacciones enviadas por los usuarios en L1 suelen confirmarse en 5-20 segundos, comparable a la experiencia de pago con tarjeta de crédito. Sin embargo, acortar aún más el tiempo de confirmación sigue teniendo su valor, y algunas aplicaciones incluso requieren una latencia de nivel de milisegundos. Este artículo explorará varias posibles soluciones para mejorar el tiempo de confirmación de transacciones en Ethereum.

Resumen de la tecnología existente

finalización de un solo slot

Ethereum actualmente utiliza el mecanismo de consenso Gasper, que emplea una arquitectura de un solo slot y Epoch. Cada 12 segundos un slot, los validadores votan sobre la cabeza de la cadena, y todos los validadores tienen la oportunidad de votar una vez en 32 slots (6.4 minutos). Estos votos se interpretan como mensajes similares al algoritmo de consenso PBFT, proporcionando una finalización con fuertes garantías económicas después de dos Epochs (12.8 minutos).

Sin embargo, este método presenta problemas de complejidad y un tiempo de confirmación excesivamente largo. La finalización de un solo bloque (SSF) propone reemplazar la arquitectura actual con un mecanismo similar al de Tendermint, permitiendo que el bloque N se confirme de manera definitiva antes de que se genere el bloque N+1. El principal desafío del SSF radica en que se requiere que los validadores publiquen dos mensajes cada 12 segundos, lo que genera una carga considerable en la cadena.

Preconfirmación de Rollup

Ethereum sigue una hoja de ruta centrada en rollups, diseñando L1 para soportar funciones como la disponibilidad de datos, para su uso por protocolos L2. Esto ha causado una separación de puntos de atención: L1 se centra en funciones centrales como la resistencia a la censura y la confiabilidad, mientras que L2 se dirige más directamente a las necesidades de los usuarios.

En teoría, L2 puede crear su propia red de "ordenadores descentralizados" que firma bloques cada pocos cientos de milisegundos. Sin embargo, en la práctica, el rollup ha avanzado lentamente en el desarrollo de redes de ordenamiento descentralizadas.

Confirmación previa básica

La suposición básica de la preconfirmación es que el proponente de Ethereum es un participante relacionado con MEV complejo. Crea un protocolo estandarizado que permite a los usuarios ofrecer tarifas adicionales para obtener la garantía inmediata de que su transacción se incluya en el siguiente bloque. Si el proponente incumple su promesa, enfrentará una penalización. Este mecanismo puede proporcionar preconfirmaciones para transacciones L1 y L2.

Posibles direcciones de desarrollo

Supongamos que se ha logrado la finalización en un solo slot y que se utiliza una tecnología similar a Orbit para reducir la cantidad de validadores que firman en cada slot. La duración del slot podría aumentar a 16 segundos, y luego se utilizaría la preconfirmación de rollup o la preconfirmación básica para ofrecer a los usuarios una confirmación más rápida. Esto formará una nueva arquitectura de epoch-slot.

Esta arquitectura refleja una profunda razón filosófica: el tiempo necesario para alcanzar un consenso aproximado sobre algo es menor que el requerido para llegar a un acuerdo de "finalidad económica" máxima. Las razones incluyen factores como la cantidad de nodos y la "calidad" de los nodos.

Posibles estrategias de L2

Actualmente hay tres estrategias razonables para L2:

1. Técnicamente y espiritualmente "basado", optimizando las propiedades técnicas de la capa base de Ethereum y sus valores.
2. Convertirse en "servidor con andamiaje de blockchain", aprovechando al máximo la eficiencia del servidor.
3. Método de compromiso: una cadena rápida con aproximadamente cien nodos, Ethereum proporciona interoperabilidad y seguridad adicionales.

Para diferentes aplicaciones, los requisitos de tiempo de confirmación adecuados también son diferentes. Para aquellas aplicaciones que requieren una confirmación más rápida, la única solución es la arquitectura de epoch-and-slot.

Perspectivas Futuras

Actualmente, todavía estamos lejos de las respuestas finales a estas preguntas. La complejidad de los proponentes de bloques sigue siendo incierta. Diseños novedosos como Orbit SSF ofrecen posibilidades para explorar más a fondo la arquitectura de epoch-and-slot. Cuantas más opciones tengamos, mejor podremos servir a los usuarios de L1 y L2, y simplificar el trabajo de los desarrolladores de L2.