Autor: Vitalik, fundador de Ethereum; Traducción: 0xjs@金财经
Una característica importante de una buena experiencia de usuario de blockchain son los tiempos rápidos de confirmación de transacciones. Hoy en día, Ethereum ha recorrido un largo camino desde lo que era hace cinco años. Gracias al tiempo de bloqueo estable después de EIP -1559 y Merge, las transacciones enviadas por los usuarios en L1 se pueden confirmar de manera confiable en 5 a 20 segundos. Esto equivale aproximadamente a la experiencia de pagar con tarjeta de crédito. Sin embargo, es valioso mejorar aún más la experiencia del usuario, y algunas aplicaciones requieren latencias de cientos de milisegundos o incluso menos. Este artículo presentará algunas opciones prácticas para Ethereum.
Resumen de ideas y tecnologías existentes
Finalidad de una sola ranura
Hoy en día, el consenso Gasper de Ethereum adopta una arquitectura de ranura y época. Cada intervalo de 12 segundos, un subconjunto de validadores publica un voto en el encabezado del bloque de cadena y, dentro de los 32 intervalos (6,4 minutos), todos los validadores tienen la oportunidad de votar una vez. Luego, estos votos se reinterpretan como mensajes en un algoritmo de consenso similar al PBFT, que proporciona una garantía económica muy estricta llamada finalidad después de dos épocas (12,8 minutos).
En los últimos años, nos hemos sentido cada vez más insatisfechos con nuestro enfoque actual. Las razones principales son: (i) es complejo, con muchos errores de interacción entre el mecanismo de votación ranura por ranura y el mecanismo de finalidad época por época (ii) 12,8 minutos es demasiado tiempo y nadie quiere esperar eso; largo.
La finalidad de una sola ranura reemplaza esta arquitectura con un mecanismo más similar al consenso de Tendermint, donde el bloque N se completa antes de que se genere el bloque N+1. La principal diferencia con Tendermint es que conservamos el mecanismo de "fuga inactiva", que permite que la cadena continúe ejecutándose y recuperándose si más de 1/3 de los validadores se desconectan.
Dibujo de diseño final de tanque único
El principal desafío con SSF es que parece implicar ingenuamente que cada participante de Ethereum necesita publicar dos mensajes cada 12 segundos, lo cual es una carga significativa para la cadena de bloques. Hay algunas ideas inteligentes para mitigar esto, incluida la reciente propuesta Orbit SSF. Pero aun así, si bien esto mejora significativamente la experiencia del usuario al acelerar la "finalidad", no cambia el hecho de que los usuarios deben esperar entre 5 y 20 segundos.
Preconfirmación acumulativa
En los últimos años, Ethereum ha seguido una hoja de ruta centrada en la acumulación, diseñando la capa base de Ethereum ("L1") en torno al soporte de la disponibilidad de datos y otras características que luego se pueden acumular (junto con validiums y plasmas), que pueden proporcionar usuarios con el mismo nivel de seguridad que Ethereum, pero a una escala mucho mayor.
Esto crea una separación de preocupaciones dentro del ecosistema Ethereum: Ethereum L1 puede centrarse en la resistencia a la censura, la confiabilidad, la estabilidad y el mantenimiento y mejora de ciertos núcleos funcionales subyacentes, mientras que L2 puede centrarse en llegar a los usuarios de manera más directa, a través de diferentes compensaciones culturales y técnicas. . Pero si sigues este camino, surge un problema inevitable: L2 quiere atender a los usuarios que desean confirmaciones más rápidas, entre 5 y 20 segundos.
Hasta ahora, L2 ha sido responsable, al menos retóricamente, de crear su propia red de "ordenamiento descentralizado". Un pequeño grupo de validadores firma bloques, quizás cada pocos cientos de milisegundos, y ponen su "apuesta" detrás de esos bloques. Finalmente, los encabezados de bloque de estos bloques L2 se publican en L1.
El conjunto de validadores L2 puede hacer trampa: pueden firmar el bloque B1 antes de firmar el bloque en conflicto B2 y enviarlo a la cadena antes de B1. Pero si lo hacen, quedarán atrapados y perderán su apuesta. Hemos visto versiones centralizadas de este enfoque en la práctica, pero los paquetes acumulativos han tardado en desarrollar redes de pedidos descentralizadas. Se podría argumentar que exigir que L2 realice todos los pedidos descentralizados es un trato injusto: estamos pidiendo a los rollups que hagan esencialmente el mismo trabajo que crear un L1 completamente nuevo. Por esta y otras razones, Justin Drake ha estado promoviendo una forma de brindar a todos los L2 (así como a los L1) acceso a un mecanismo de preconfirmación compartido en todo Ethereum: la preconfirmación basada.
Basado en confirmación previa
El enfoque basado en la confirmación previa supone que los proponentes de Ethereum serán participantes altamente sofisticados por razones relacionadas con MEV. El enfoque basado en la confirmación previa explota esta complejidad al incentivar a estos proponentes maduros a aceptar la responsabilidad de proporcionar la confirmación previa como servicio.
La idea básica es crear un protocolo estandarizado a través del cual los usuarios puedan proporcionar una tarifa adicional a cambio de una garantía inmediata de que la transacción se incluirá en el siguiente bloque y posiblemente obtener una declaración sobre los resultados de la ejecución de la transacción. Si un proponente incumple cualquier promesa hecha a cualquier usuario, es castigado.
Como se mencionó anteriormente, el mecanismo de confirmación previa basado proporciona protección para las transacciones L1. Si el resumen está "basado", entonces todos los bloques L2 son transacciones L1, por lo que se puede utilizar el mismo mecanismo para proporcionar confirmación previa para cualquier L2.
¿Qué estamos viendo realmente aquí?
Supongamos que implementamos la finalidad de una sola ranura. Usamos tecnología similar a Orbit para reducir la cantidad de validadores que firman por ranura, pero no demasiado, de modo que también podamos avanzar en el objetivo clave de reducir la participación mínima de 32 ETH. Como resultado, el tiempo de la ranura puede aumentar gradualmente hasta 16 segundos. Luego utilizamos la confirmación previa acumulada o la confirmación previa basada para brindar a los usuarios garantías más rápidas. ¿Qué tenemos ahora? Una arquitectura de época y ranura.
El meme "son el mismo gráfico" se ha usado en exceso en este punto, así que simplemente reuniré un gráfico antiguo que hice hace unos años junto con el gráfico previo a la confirmación L2 para describir las ranuras y épocas de Gasper. Arquitectura y, con suerte, esto aclarará el punto.
Hay una profunda razón filosófica por la que parece difícil evitar el uso de la arquitectura de época y ranura: alcanzar un acuerdo aproximado sobre algo lleva inherentemente menos tiempo que alcanzar un acuerdo de máxima fuerza sobre "finalidad económica" sobre algo.
Una razón simple es la cantidad de nodos. Si bien la antigua relación entre descentralización lineal, tiempo eventual y gastos generales parece más leve ahora gracias a la agregación BLS ultraoptimizada y ZK-STARK en el futuro cercano, fundamentalmente los siguientes puntos siguen siendo ciertos:
1. Un "acuerdo aproximado" requiere sólo unos pocos nodos, mientras que la finalidad económica requiere una porción significativa de todos los nodos.
2. Una vez que la cantidad de nodos supere una determinada escala, deberá dedicar más tiempo a recopilar firmas.
En el Ethereum actual, el espacio de 12 segundos se divide en tres subespacios para (i) publicación y distribución en bloque, (ii) atestación y (iii) agregación de atestación. Si el número de probadores fuera mucho menor, podríamos reducirlo a dos subintervalos y reducir el tiempo del intervalo a 8 segundos. Otro factor que en realidad es más importante es la "calidad" del nodo. Si también pudiéramos confiar en un subconjunto especializado de nodos para llegar a un acuerdo aproximado (y aún usar el conjunto completo de validadores para la finalidad), podríamos reducir esto a ~2 segundos.
Por lo tanto, creo que (i) las arquitecturas de ranura y época son claramente correctas, pero (ii) no todas las arquitecturas de ranura y época son creadas de la misma manera, y es valioso explorar el espacio de diseño más completamente. En particular, vale la pena explorar opciones que no estén tan estrechamente entrelazadas como las de Gasper, sino que tengan una mayor separación de preocupaciones entre las dos mecánicas.
¿Qué debería hacer L2?
En mi opinión, actualmente existen tres estrategias razonables que L2 puede adoptar:
1. Ya sea a nivel técnico o espiritual, debe estar "basado". Es decir, están optimizados como canales de entrega para las propiedades técnicas de la capa base de Ethereum y su valor (alta descentralización, resistencia a la censura, etc.). En su forma más simple, se pueden considerar estos paquetes acumulativos como "fragmentos de marca", pero también pueden ser más ambiciosos e implicar una extensa experimentación con nuevos diseños de máquinas virtuales y otras mejoras técnicas.
2. Siéntete orgulloso de ser un "servidor con andamiaje blockchain" y aprovéchalo al máximo. Si comienza con el servidor, agregue (i) prueba de validez de STARK para garantizar que el servidor siga las reglas, (ii) garantice el derecho del usuario a retirar o forzar una transacción, y posiblemente (iii) libertad de elección colectiva, ya sea a través de una salida coordinada a gran escala o la capacidad de cambiar el orden mediante votación, entonces habrá obtenido muchos beneficios en la cadena y al mismo tiempo conservará la mayor parte de la eficiencia del servidor.
3. Compromiso: Ethereum, una cadena rápida con 100 nodos, proporciona interoperabilidad y seguridad adicionales. Esta es la hoja de ruta actual de facto para muchos proyectos de L2.
Para algunas aplicaciones (por ejemplo, ENS, almacenes de claves, determinados pagos), un tiempo de bloqueo de 12 segundos es suficiente. Para aquellas aplicaciones en las que esto no es suficiente, la única solución es la arquitectura de ranura y época. En los tres casos, "época" es el SSF de Ethereum (tal vez podríamos redefinir ese acrónimo para que signifique algo más que "ranura única", por ejemplo, podría ser "finalidad segura y rápida"). Pero en los tres casos anteriores, el "espacio" es diferente:
1. Arquitectura nativa de época y ranura de Ethereum
2. Preconfirmación del servidor
3. Preconfirmación por parte del comité
Una pregunta clave es: ¿qué tan bien podemos hacer algo en la categoría (1)? En particular, si las cosas se ponen realmente buenas, la categoría (3) ya no parece tener mucho sentido. La categoría (2) siempre existirá, al menos porque cualquier cosa "basada" no se aplica a los datos fuera de la cadena L2, como Plasma y validium. Pero si la arquitectura nativa de ranura y época de Ethereum se puede acortar a un tiempo de "ranura" de 1 segundo (es decir, preconfirmación), entonces el espacio para la categoría (3) se vuelve mucho más pequeño.
Hoy estamos lejos de tener respuestas definitivas a estas preguntas. Una cuestión clave –qué tan sofisticados serán los proponentes de bloques– sigue siendo un área donde existe considerable incertidumbre. Diseños como Orbit SSF son muy nuevos, lo que demuestra que diseños como Orbit SSF pertenecen a una era en la que el espacio de diseño para diseños de ranuras y épocas aún está poco explorado. Cuantas más opciones tengamos, mejor podremos hacerlo para los usuarios de L1 y L2, y más fácil podremos hacer la vida a los desarrolladores de L2.
