Reenviar el Título Original 'Épocas y ranuras hasta el final: formas de dar a los usuarios de Ethereum tiempos de confirmación de transacciones más rápidos'

Una de las propiedades importantes de una buena experiencia de usuario en blockchain es el tiempo de confirmación rápido de las transacciones. Hoy en día, Ethereum ya ha mejorado mucho en comparación con hace cinco años. Gracias a la combinación de EIP-1559y tiempos de bloque estables despuésla Fusión, las transacciones enviadas por los usuarios en L1 se confirman de manera confiable en 5-20 segundos. Esto es aproximadamente competitivo con la experiencia de pagar con una tarjeta de crédito. Sin embargo, hay valor en mejorar aún más la experiencia del usuario, y hay algunas aplicaciones que requieren directamente latencias del orden de cientos de milisegundos o incluso menos. En esta publicación se analizarán algunas de las opciones prácticas que Ethereum tiene.

Visión general de ideas y técnicas existentes

Finalidad de ranura única

Hoy, Ethereum's Gasperel consenso utiliza una arquitectura de ranuras y épocas. Cada ranura de 12 segundos, un subconjunto de validadores publica un voto sobre la cabeza de la cadena, y a lo largo de 32 ranuras (6,4 minutos), todos los validadores tienen la oportunidad de votar una vez. Estos votos son luego reinterpretados como mensajes de forma vaga PBFT-likealgoritmo de consenso, que después de dos épocas (12.8 min) proporciona una garantía económica muy sólida llamada finalidad.

Durante los últimos años, nos hemos sentido cada vez más incómodos con el enfoque actual. Las razones clave son que (i) es complicado y hay muchos errores de interacción entre el mecanismo de votación de ranura en ranura y el mecanismo de finalización de época por época, y (ii) 12.8 minutos es demasiado tiempo y a nadie le importa esperar tanto.

La finalidad de una sola ranura reemplaza esta arquitectura por un mecanismo mucho más similar a Consenso de Tendermint, en el que el bloque N se finaliza antes de que se haga el bloque N+1. La principal desviación de Tendermint es que mantenemos el “fuga de inactividad“mecanismo, que permite que la cadena siga funcionando y se recupere si más de 1/3 de los validadores se desconectan.

Un diagrama de la principal propuestadiseño de finalidad de una sola ranura_

El principal desafío con SSF es que ingenuamente, parece implicar que cada validador de Ethereum tendría que publicar dos mensajes cada 12 segundos, lo que sería mucha carga para la cadena manejar. Hay ideas ingeniosaspara cómo mitigar esto, incluyendo el muy recienteOrbit SSFpropuesta. Pero aún así, si bien esto mejora significativamente la experiencia de usuario al hacer que la "finalidad" llegue más rápido, no cambia el hecho de que los usuarios necesitan esperar 5-20 segundos.

Preconfirmaciones de Rollup

Durante los últimos años, Ethereum ha estado siguiendo un hoja de ruta centrada en rollup, diseñando la capa base de Ethereum (el “L1”) en torno a la compatibilidad con disponibilidad de datos y otras funcionalidades que luego pueden ser utilizadas por protocolos de capa 2 como rollups(pero tambiénvalidiumsyplasmas) que puede brindar a los usuarios el mismo nivel de seguridad que Ethereum, pero a una escala mucho mayor.

Esto crea un separación-de-concernsdentro del ecosistema de Ethereum: Ethereum L1 puede centrarse en ser resistente a la censura, confiable, estable, y en mantener y mejorar un cierto nivel base de funcionalidad, y L2s pueden centrarse en llegar de manera más directa a los usuarios - tanto a través de diferentesculturaly compensaciones tecnológicas. Pero si decides seguir este camino, surge un problema inevitable: las L2 quieren servir a usuarios que desean confirmaciones mucho más rápidas que 5-20 segundos.

Hasta ahora, al menos en la retórica, ha sido responsabilidad de los L2 crear sus propias redes de "secuenciación descentralizada". Un grupo más pequeño de validadores firmaría bloques, quizás una vez cada pocos cientos de milisegundos, y respaldarían esos bloques con su "participación". Eventualmente, los encabezados de estos bloques L2 se publican en L1.

Los conjuntos de validadores L2 podrían hacer trampa: podrían firmar primero el bloque B1, y luego firmar más tarde un bloque conflictivo B2 y comprometerlo en la cadena antes que B1. Pero si hacen esto, serían descubiertos y perderían sus depósitos. En la práctica, hemos visto versiones centralizadas de esto, pero las rollups han tardado en desarrollar redes de secuenciación descentralizadas. Y se puede argumentar que exigir que todos los L2 hagan secuenciación descentralizada es un trato injusto: estamos pidiendo básicamente a las rollups que hagan la mayor parte del trabajo como crear un nuevo L1 completo. Por esta razón y otras, Justin Drake ha estado promoviendo una forma de dar a todos los L2 (así como a L1) acceso a un mecanismo de preconfirmación compartido en toda la red Ethereum.preconfirmaciones basadas.

Preconfirmaciones basadas

El enfoque de preconfirmación basado asume que los proponentes de Ethereum se convertirán en actores altamente sofisticados por razones relacionadas con MEV (ver aquípara mi explicación de MEV, y ver también elentradas de ejecuciónlínea de propuestas). El enfoque previo a la confirmación basado aprovecha esta sofisticación incentivando a estos proponentes sofisticados a aceptar la responsabilidad de ofrecer preconfirmaciones como un servicio.

La idea básica es crear un protocolo estandarizado mediante el cual un usuario pueda ofrecer una tarifa adicional a cambio de una garantía inmediata de que la transacción se incluirá en el siguiente bloque, junto con posiblemente una reclamación sobre los resultados de ejecutar esa transacción. Si el proponente viola alguna promesa que haga a cualquier usuario, puede ser sancionado.

Como se describe, las preconfirmaciones basadas proporcionan garantías a las transacciones de L1. Si los rollups son“basado”, entonces todos los bloques L2 son transacciones L1, y así se puede utilizar el mismo mecanismo para proporcionar preconfirmaciones para cualquier L2.

¿Qué estamos mirando aquí en realidad?

Supongamos que implementamos la finalidad de un solo slot. Usamos Órbitatécnicas similares para reducir la cantidad de validadores que firman por ranura, pero no demasiado, para que también podamos avanzar en el objetivo clave de reducir el mínimo de 32 ETH para apostar. Como resultado, tal vez el tiempo de ranura aumente a 16 seg. Luego usamos preconfirmaciones de rollup, o preconfirmaciones basadas, para dar a los usuarios garantías más rápidas. ¿Qué tenemos ahora? Una arquitectura de época y ranura.

El meme de 'son la misma imagen' está siendo bastante sobreutilizado en este momento, así que simplemente colocaré un antiguo diagrama que dibujé hace años para describir la arquitectura de ranura y época de Gasper y un diagrama de preconfirmaciones L2 uno al lado del otro, y espero que eso aclare el punto.

Hay una razón filosófica profunda por la cual las arquitecturas de época y ranura parecen ser tan difíciles de evitar: inherentemente se tarda menos tiempo en llegar a un acuerdo aproximado sobre algo que en llegar a un acuerdo de “finalidad económica” máximamente endurecido sobre ello.

Una simple razón por la que es el número de nodos. Mientras el antiguo lineal @VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735">decentralización / tiempo de finalidad / compensación de sobrecarga está pareciendo más suave ahora debido a la agregación BLS hiper-optimizada y en el futuro cercano ZK-STARKs, todavía es fundamentalmente cierto que:

1. El "acuerdo aproximado" solo requiere unos pocos nodos, mientras que la finalidad económica requiere una fracción significativa de todos los nodos.
2. Una vez que el número de nodos supera cierto tamaño, necesitas dedicar más tiempo para recopilar firmas.

En Ethereum hoy en día, un intervalo de 12 segundos se divide en tres subintervalos, para (i) publicación y distribución de bloques, (ii) certificación, y (iii) agregación de certificación. Si el recuento de certificadores fuera mucho menor, podríamos reducirlo a dos subintervalos y tener un tiempo de intervalo de 8 segundos. Otro factor, y realísticamente más grande, es la 'calidad' de los nodos. Si también pudiéramos depender de un subconjunto profesionalizado de nodos para realizar acuerdos aproximados (y seguir utilizando el conjunto completo de validadores para la finalización), podríamos reducir ese tiempo a ~2 segundos de manera plausible.

Por lo tanto, siento que (i) las arquitecturas de slot y época son obviamente correctas, pero también (ii) no todas las arquitecturas de slot y época son iguales, y hay valor en explorar más completamente el espacio de diseño. En particular, vale la pena explorar opciones que no estén estrechamente entrelazadas como Gasper, y donde en su lugar haya una separación más fuerte de preocupaciones entre los dos mecanismos.

¿Qué deberían hacer los L2s?

En mi opinión, hay tres estrategias razonables que los L2 deben adoptar en este momento:

1. Ser “basado”, tanto tecnológica como espiritualmente. Es decir, se optimizan para ser conductos de paso para las propiedades técnicas de la capa base de Ethereum y sus valores (alta descentralización, resistencia a la censura, etc). En su forma más simple, podrías pensar en estos rollups como “fragmentos con marca”, pero también pueden ser mucho más ambiciosos que eso, y experimentar bastante con nuevos diseños de máquinas virtuales y otras mejoras técnicas.
2. Orgullosamente ser un "servidor con andamiaje de blockchain", y sacarle el máximo provecho. Si partes de un servidor y luego añades (i) pruebas de validez STARK para asegurar que el servidor esté siguiendo las reglas, (ii) derechos garantizados para que el usuario salga o fuerce transacciones, y posiblemente (iii) libertad de elección colectiva, ya sea a través de una salida masiva coordinada o a través de la capacidad de votar para cambiar el secuenciador, entonces ya has obtenido gran parte de los beneficios de estar en cadena, manteniendo la mayoría de las eficiencias de un servidor.
3. El enfoque de compromiso: una cadena rápida de cien nodos, con Ethereum proporcionando interoperabilidad adicional y seguridad. Este es el de facto el actual roadmap de muchos proyectos L2.

Para algunas aplicaciones, (por ejemplo, ENS, almacenes de claves) algunas transacciones), un tiempo de bloque de 12 segundos es suficiente. Para aquellas aplicaciones que no lo son, la única solución es una arquitectura de ranura y época. En los tres casos, las “épocas” son el SSF de Ethereum (quizás podamos reinterpretar ese acrónimo para que signifique algo distinto a “single slot”, por ejemplo, podría ser “Finalidad Segura y Rápida”). Pero las “ranuras” son algo diferente en cada uno de los tres casos:

1. Una arquitectura de ranuras y épocas nativa de Ethereum
2. Preconfirmaciones del servidor
3. Preconfirmaciones del comité

Una pregunta clave es, ¿qué tan bueno podemos hacer algo en la categoría (1)? En particular, si se vuelve realmente bueno, entonces parece que la categoría (3) deja de tener tanto significado. La categoría (2) siempre existirá, al menos porque cualquier cosa "basada" no funciona para L2s de datos fuera de la cadena como plasmas y validiums. Pero si una arquitectura de espacio y época nativa de Ethereum puede llegar a tiempos de "ranura" de 1 segundo (es decir, pre-confirmación), entonces el espacio para la categoría (3) se vuelve bastante más pequeño.

Hoy, estamos lejos de tener respuestas finales a estas preguntas. Una pregunta clave - qué tan sofisticados se convertirán los proponentes de bloques - sigue siendo un área donde hay bastante incertidumbre. Diseños como Orbit SSFson muy recientes, lo que sugiere que el espacio de diseño de diseños de ranura y epoca donde algo como Orbit SSF es la epoca todavia esta bastante inexplorado. Cuantas mas opciones tengamos, mejor podremos hacer para los usuarios tanto en L1 como en L2s, y mas podremos simplificar el trabajo de los desarrolladores de L2.

Descargo de responsabilidad：

1. Este artículo es reimpreso de [Vitalik].Reenviar el Título Original 'Épocas y ranuras hasta el fondo: formas de dar a los usuarios de Ethereum tiempos de confirmación de transacción más rápidos'. Todos los derechos de autor pertenecen al autor original [Vitalik]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo y lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones y puntos de vista expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.