Autor original | Vitalik

Compilación | Odaily Estrella Diaria Nan Zhi

Una de las características importantes de una buena experiencia de usuario en blockchain es el tiempo rápido de confirmación de las transacciones. Hoy en día, Ethereum ha mejorado mucho en comparación con hace cinco años. Gracias a EIP-1559 y el tiempo estable de bloque después de la transición a Prueba de Participación (The Merge), las transacciones enviadas por los usuarios en L1 suelen confirmarse en 5-20 segundos, lo que es comparable a la experiencia de pagar con tarjeta de crédito. Sin embargo, mejorar aún más la experiencia del usuario tiene valor, ya que algunas aplicaciones requieren incluso cientos de milisegundos o incluso menos de latencia. En este artículo se explorarán algunas opciones prácticas para mejorar el tiempo de confirmación de transacciones en Ethereum.

Descripción de las ideas y tecnologías existentes

Finalidad del Soltero

Actualmente, el consenso Gasper de Ethereum utiliza una arquitectura de ranura (Slot) y Epoch. Cada 12 segundos hay una ranura donde algunos validadores votan por la cabeza de la cadena, y dentro de 32 ranuras (6.4 minutos), todos los validadores tienen la oportunidad de votar una vez. Estos votos se interpretan luego como mensajes en un algoritmo de consenso similar a PBFT, y después de dos Epochs (12.8 minutos), se les da una garantía económica muy fuerte llamada finalidad.

En los últimos años, estamos cada vez más insatisfechos con el método actual. Hay dos razones principales para esto, en primer lugar, el método es muy complicado, hay muchos errores de interacción entre el mecanismo de votación de slot-to-slot y el mecanismo de finalidad de Epoch-to-Epoch, en segundo lugar, 12.8 minutos es demasiado tiempo, nadie quiere esperar tanto.

La Finalidad de una Sola Ranura (Single Slot Finaty, SSF) reemplaza esta arquitectura mediante un mecanismo similar al consenso de Tendermint, donde el bloque N se determina definitivamente antes de que se genere el bloque N+1. La principal diferencia con Tendermint es que mantenemos el mecanismo de 'fuga de inactividad', que permite que la cadena continúe funcionando y se recupere cuando más de 1/3 de los validadores estén fuera de línea.

El principal desafío de la finalidad de la ranura única es que cada validador de Ethereum necesita publicar dos mensajes cada 12 segundos, lo que representa una carga significativa para la cadena. Hay algunas ideas ingeniosas que pueden mitigar este problema, incluida la reciente propuesta de Orbit SSF. Si bien esto acelera significativamente la "finalidad" para mejorar la experiencia del usuario, no cambia el hecho de que los usuarios todavía deben esperar de 5 a 20 segundos.

Confirmación previa de Rollup

En los últimos años, Ethereum ha seguido una hoja de ruta centrada en rollups, diseñando la capa base de Ethereum (L1) para admitir la disponibilidad de datos y otras funciones, que luego están disponibles para protocolos L2 (como rollups, validiums y plasmas) para ofrecer seguridad a los usuarios a una escala mayor similar a la de Ethereum.

Esto ha llevado a una separación de enfoques dentro del ecosistema de Ethereum: Ethereum L1 se centra en ser anticensura, confiable, estable, y en mantener y mejorar la funcionalidad central de una capa base, mientras que L2 se centra en interactuar de manera más directa con los usuarios a través de diferentes culturas y tecnologías. Sin embargo, si seguimos por este camino, surge un problema inevitable: L2 busca ofrecer confirmaciones más rápidas que los 5-20 segundos para los usuarios.

Hasta ahora, al menos en teoría, es responsabilidad de L2 crear su propia red de "secuenciadores de descentralización". Un pequeño grupo de validadores puede firmar Bloquear cada pocos cientos de milisegundos e invertir sus activos stake detrás de esos Bloquear. Eventualmente, los archivos de encabezado de estos bloques L2 se publican en L1.

Pero el conjunto de validadores de L2 puede cometer "fraude": pueden firmar primero el bloque B1, y luego firmar un bloque conflictivo B2 y enviarlo a la cadena antes que B1. Pero si lo hacen, serán descubiertos y perderán sus activos de apuesta. De hecho, ya hemos visto casos reales de versiones centralizadas, pero por otro lado, el rollup avanza lentamente en el desarrollo de redes de ordenación descentralizadas. Se podría argumentar que exigir que todos los L2 realicen una ordenación descentralizada es injusto: esto es como pedirle a rollup que haga un trabajo casi idéntico al de crear un nuevo L1. Por lo tanto, Justin Drake ha estado promoviendo un método para que todos los L2 (y L1) puedan utilizar un mecanismo de preacuerdo compartido a nivel de Ethereum: preacuerdo base.

Confirmación preliminar básica

El método de preconfirmaciones basadas asume que los proponentes de Ethereum son participantes altamente complejos relacionados con MEV. El método basado en preconfirmaciones utiliza la complejidad para incentivar a estos complejos proponentes a asumir la responsabilidad de proporcionar servicios de preconfirmación.

La idea básica de este método es crear un protocolo estandarizado en el cual los usuarios puedan pagar una tarifa adicional para asegurar que la transacción sea incluida en el siguiente bloque de manera inmediata y garantizada, así como para hacer una declaración sobre los resultados de la ejecución de dicha transacción. Si el proponente incumple cualquier compromiso hecho a cualquier usuario, puede ser penalizado.

Como se mencionó, se proporciona garantía para las transacciones L1 basadas en preconfirmación. Si los rollups son "basados en", entonces todos los bloques L2 son transacciones L1, por lo que el mismo mecanismo puede usarse para preconfirmar cualquier L2.

¿Qué estamos viendo realmente?

Supongamos que logramos la finalidad de una sola ranura. Utilizamos una tecnología similar a la de Orbit para reducir la cantidad de validadores que firman en cada ranura, pero no reducimos demasiado para poder avanzar en nuestro objetivo clave de reducir al mínimo la apuesta de 32 ETH. La duración de la ranura puede aumentar a 16 segundos y luego utilizamos rollup preconfirmado o preconfirmado básico para proporcionar confirmaciones más rápidas a los usuarios. En última instancia, logramos una arquitectura de ranuras de época.

Hay una razón filosófica profunda por la cual la arquitectura de epoch-and-slot parece tan difícil de evitar: el tiempo requerido para llegar a un acuerdo aproximado sobre algo es menor en comparación con llegar a un acuerdo de 'finalidad económica' máximo sobre algo.

Una razón simple es la cantidad de nodos. Aunque, debido a la agregación BLS súper optimizada y la próxima aparición de ZK-STARKs, los antiguos compromisos lineales de descentralización / tiempo de finalización / costo ahora parecen moderados, no se pueden ignorar las siguientes razones:

• "Aproximadamente consenso" solo requiere unos pocos nodos, mientras que la finalidad económica requiere la mayoría de los nodos.
• Una vez que el número de nodos supere cierta escala, necesitarás invertir más tiempo en recopilar firmas.

En Ethereum hoy, los 12 intervalos se dividen en tres subintervalos: publicación y distribución de bloques, pruebas y agregación de pruebas. Si la cantidad de probadores disminuye significativamente, podemos reducirlo a dos subintervalos y utilizar un intervalo de 8 segundos. Otro factor más práctico y significativo es la 'calidad' de los nodos. Si también podemos depender de un subconjunto de nodos especializados para lograr un consenso aproximado (y aún utilizar un conjunto completo de validadores para determinar la finalidad), podemos reducirlo a aproximadamente 2 segundos.

Por lo tanto, en mi opinión, la arquitectura de epoch-and-slot parece ser la correcta, pero no todas las arquitecturas de epoch-and-slot son iguales, por lo que es valioso explorar más a fondo el espacio de diseño. La dirección que vale la pena investigar no es tan estrechamente integrada como Gasper, sino que hay un mayor enfoque en la separación de los dos mecanismos.

¿Cómo debería funcionar L2?

En mi opinión, actualmente hay tres estrategias razonables para L2:

• Tanto técnicamente como espiritualmente 'basado'. Es decir, optimizan las propiedades técnicas y los valores fundamentales de Ethereum (altamente descentralizado, resistente a la censura, etc.). En su forma más simple, puedes considerar estos rollups como 'fragmentación de marca', pero también pueden tener ambiciones más grandes, experimentando mucho en el diseño de una nueva máquina virtual y otras mejoras tecnológicas.
• Conviértase en un servidor con un marco de blockchain y úselo al máximo. Si comienzas desde el servidor y luego agregas la prueba de validez STARK para asegurar que el servidor cumpla con las reglas; garantizar el derecho de los usuarios a salir o forzar transacciones; libertad de elección colectiva, a través de una salida a gran escala coordinada o cambiando el voto de los ordenadores, entonces has obtenido la mayoría de los beneficios de la cadena, al tiempo que conservas la mayor parte de la eficiencia del servidor. *Método de compromiso: una cadena rápida con cien nodos, Ethereum proporciona interoperabilidad adicional y seguridad. Este es el roadmap actual de muchos proyectos L2.

Para algunas aplicaciones (como ENS, almacenamiento de claves y algunos protocolos de pago), el tiempo de bloque de 12 segundos es suficiente. Para aquellas aplicaciones que no son adecuadas, la única solución es la arquitectura de epoch-and-slot. En los tres casos, 'epoch' se refiere al SSF de Ethereum, pero el 'slot' varía en cada uno de los casos mencionados anteriormente:

• Una arquitectura de época y ranura nativa de Ethereum
• Servidor preconfirmado
• Comité de Preconfirmación

Una pregunta clave es qué tan bien podemos hacer en la Clase 1? Especialmente si se vuelve muy bueno, entonces el significado de la Clase 3 no sería tan importante. Debido a que todos los esquemas 'basados' no se aplican a datos fuera de la cadena como plasmas y validiums L2, la Clase 2 siempre existirá. Si una arquitectura de época y ranura nativa de Ethereum puede reducir el tiempo de ranura a 1 segundo, entonces el espacio de la Clase 3 será mucho más pequeño.

Hoy en día, todavía estamos lejos de encontrar las respuestas definitivas a estas preguntas. Una cuestión clave es cómo complejo se volverá el proponente de bloques, que sigue siendo un área con bastante incertidumbre. Diseños innovadores como Orbit SSF ofrecen un gran potencial, por lo que seguir explorando su integración en esquemas como epoch-and-slot sería beneficioso. Cuantas más opciones tengamos, mejor podremos atender a los usuarios de L1 y L2, y simplificar el trabajo de los desarrolladores de L2.