*Reenviar el título original 'Epochs and slots all the way down: 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 rápido de confirmación de 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és dela 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 tiene Ethereum.

Visión general de ideas y técnicas existentes

Finalidad de una sola ranura

Hoy, Ethereum’sGasperconsenso utiliza una arquitectura de ranura y época. 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 luego se reinterpretan como mensajes en un sentido vago PBFT-likealgoritmo de consenso, que después de dos épocas (12.8 min) brinda 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 a ranura y el mecanismo de finalidad de época a época, y (ii) 12.8 minutos es demasiado largo y a nadie le importa esperar tanto tiempo.

La finalidad de un solo slot reemplaza esta arquitectura con un mecanismo mucho más similar aconsenso 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 propuesta diseño de finalidad de ranura única_

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 cual sería una gran carga para la cadena. Hay ideas inteligentespara saber cómo mitigar esto, incluyendo el muy recienteOrbit SSFpropuesta. Pero aun así, si bien esto mejora significativamente la experiencia del 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 una hoja de ruta centrada en rollup, diseñando la capa base de Ethereum (la “L1”) en torno al soporte disponibilidad de datos y otras funcionalidades que luego pueden ser utilizadas por protocolos de capa 2 como rollups (pero también validiums y plasmas) 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-preocupacionesdentro del ecosistema de Ethereum: Ethereum L1 puede centrarse en ser resistente a la censura, confiable, estable, y mantener y mejorar un cierto nivel base de funcionalidad, y L2 puede centrarse en llegar de manera más directa a los usuarios - tanto a través de diferentesculturaly compensaciones tecnológicas. Pero si sigues este camino, surge un problema inevitable: los L2 quieren servir a usuarios que desean confirmaciones mucho más rápidas que de 5-20 segundos.

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

Los conjuntos de validadores L2 podrían hacer trampa: primero podrían firmar el bloque B1, y luego firmar más tarde un bloque conflictivo B2 y confirmarlo 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 los rollups han sido lentos para desarrollar redes de secuenciación descentralizadas. Y se podría argumentar que exigir que todos los L2 hagan secuenciación descentralizada es un trato injusto: estamos pidiendo a los rollups que básicamente 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 al L1) acceso a un mecanismo de preconfirmación compartido en toda la red Ethereum:preconfirmaciones basadas.

Basado en preconfirmaciones

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 también ver elTickets de ejecuciónLa aproximación basada en la preconfirmación aprovecha esta sofisticación incentivando a estos proponentes sofisticados a aceptar la responsabilidad de ofrecer preconfirmaciones como un servicio (línea de propuestas).

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 la ejecución de esa transacción. Si el proponente viola cualquier promesa que haga a cualquier usuario, puede ser sancionado.

Como se describe, las preconfirmaciones basadas proporcionan garantías para las transacciones L1. Si los rollups son basado, entonces todos los bloques L2 son transacciones L1, por lo que el mismo mecanismo se puede utilizar para proporcionar preconfirmaciones para cualquier L2.

¿Qué estamos viendo aquí realmente?

Supongamos que implementamos una finalidad de una sola ranura. UsamosÓrbita- técnicas similares para reducir el número 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 se eleve a 16 segundos. Luego usamos preconfirmaciones de rollup o preconfirmaciones basadas para brindar 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 utilizado en este momento, así que simplemente pondré un viejo diagrama que dibujé hace años para describir la arquitectura de slot y época de Gasper y un diagrama de preconfirmaciones de L2 uno al lado del otro, y con suerte eso transmitirá el mensaje.

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

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

1. El "acuerdo aproximado" solo requiere algunos 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, un espacio de 12 segundos se divide en tres subespacios para (i) publicación y distribución de bloques, (ii) certificación, y (iii) agregación de certificaciones. Si el recuento de certificadores fuera mucho menor, podríamos reducirlo a dos subespacios y tener un tiempo de espacio de 8 segundos. Otro factor, y realista, es la “calidad” de los nodos. Si también pudiéramos depender de un subconjunto profesionalizado de nodos para llegar a acuerdos aproximados (y aún usar el conjunto completo de validadores para la finalidad), podríamos bajar eso a ~2 segundos de manera plausible.

Por lo tanto, me parece que (i) las arquitecturas de ranura y época son obviamente correctas, pero también (ii) no todas las arquitecturas de ranura y época son creadas 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é deben hacer los L2?

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

1. Ser “basados”, tanto tecnológica como espiritualmente. Es decir, se optimizan para ser conductos de paso para las propiedades técnicas y valores de la capa base de Ethereum (alta descentralización, resistencia a la censura, etc). En su forma más simple, se podría pensar en estos rollups como “fragmentos de 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 andamios de blockchain' y aprovechar al máximo. Si comienzas desde un servidor y luego agregas (i) pruebas de validez STARK para asegurarte de 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 la 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 mapa de ruta actual de facto de muchos proyectos L2.

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

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

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

Hoy en día, estamos lejos de tener respuestas definitivas a estas preguntas. Una pregunta clave - ¿qué tan sofisticados se volverá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 época donde algo como Orbit SSF es la época aún está bastante inexplorado. Cuantas más opciones tengamos, mejor podremos hacerlo para los usuarios tanto en L1 como en L2, y más podremos simplificar el trabajo de los desarrolladores de L2.

Descargo de responsabilidad：

1. Este artículo ha sido reimpreso de [vitalik]. Reenvíe el título original 'Épocas y tragamonedas hasta el final: formas de dar a los usuarios de Ethereum tiempos de confirmación de transacciones más rápidos'. Todos los derechos de autor pertenecen al autor original [vitalik*]. Si hay objeciones a esta reimpresión, por favor contacte alGate Learnequipo, y lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente del autor y no constituyen asesoramiento 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.