"La arquitectura de época y ranura es obviamente la respuesta correcta, pero la arquitectura y las soluciones de ranura aún deben explorarse".
Autor original |
Compilación | Odaily Planet Daily Nan Zhi
Uno de los atributos importantes de una buena experiencia de usuario de blockchain es el tiempo rápido de confirmación de la transacción. Hoy en día, Ethereum ha mejorado mucho con respecto a lo que era hace cinco años. Gracias a EIP-1559 y al tiempo de bloqueo estable después de cambiar a PoS (The Merge), las transacciones enviadas por los usuarios en L1 generalmente se pueden confirmar en 5 a 20 segundos, lo que equivale aproximadamente a la experiencia de pagar con una tarjeta de crédito. Sin embargo, es valioso mejorar aún más la experiencia del usuario, y algunas aplicaciones incluso requieren latencias de cientos de milisegundos o menos. Este artículo explorará algunas opciones prácticas para mejorar los tiempos de confirmación de transacciones en Ethereum.
Resumen de ideas y técnicas existentes.
finalidad de una sola ranura
Actualmente, el consenso Gasper de Ethereum utiliza una única ranura (Slot) y arquitectura Epoch. Cada 12 segundos, un espacio, un subconjunto de validadores votan en la cabeza de la cadena, y cada 32 espacios (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, lo que brinda una garantía económica muy fuerte llamada finalidad después de dos Épocas (12,8 minutos).
(Nota diaria: para obtener detalles sobre los principios específicos, consulte "Explicación detallada del principio de funcionamiento de Ethereum POS: época, ranura y bloque de baliza")
En los últimos años nos hemos sentido cada vez más insatisfechos con nuestro enfoque actual. Hay dos razones principales para esto: en primer lugar, el método es complicado y hay muchos errores de interacción entre el mecanismo de votación entre espacios y el mecanismo de finalidad de Época a Época, y en segundo lugar, 12,8 minutos es demasiado tiempo y nadie quiere hacerlo. espera tanto tiempo.
Single Slot Finality (SSF) reemplaza esta arquitectura con un mecanismo similar al consenso de Tendermint, donde el bloque N se finaliza antes de que se genere el bloque N+ 1. La principal diferencia con Tendermint es que conservamos el mecanismo de "fuga de inactividad", que permite que la cadena continúe ejecutándose y recuperándose si más de 1/3 de los validadores están fuera de línea.
(Nota diaria: la fuga de inactividad es un mecanismo en PoS diseñado para castigar a los validadores que han estado inactivos durante mucho tiempo. Una vez marcados como inactivos, su ETH apostado continuará siendo castigado. Tendermint es un algoritmo de consenso de tolerancia a fallas bizantino eficiente y seguro que permite para una confirmación rápida de la transacción y garantiza que el sistema blockchain aún pueda funcionar normalmente incluso si algunos nodos son maliciosos o están fuera de línea).
El principal desafío con la finalidad de una sola ranura es que significa que cada participante de Ethereum necesita publicar dos mensajes cada 12 segundos, lo que supone una carga significativa para la cadena. Hay algunas ideas inteligentes para mitigar este problema, incluida la reciente propuesta Orbit SSF. Aunque esto acelera significativamente la "finalidad" para mejorar la experiencia del usuario, no cambia el hecho de que los usuarios deben esperar entre 5 y 20 segundos.
(Nota diaria: la finalidad y la transacción empaquetada en un bloque y confirmada no son el mismo evento. Cuando se confirma la transacción pero no se logra la finalidad, puede ocurrir una bifurcación o una reversión).
Preconfirmación acumulativa
En los últimos años, Ethereum ha seguido una hoja de ruta centrada en el rollup, diseñando la capa base de Ethereum (L1) para admitir la disponibilidad de datos y otras características, que luego están disponibles para los protocolos L2, como rollups, validiums y plasmas. Proporcionar a los usuarios el mismo nivel de seguridad que Ethereum a mayor escala.
Esto crea una separación de preocupaciones dentro del ecosistema Ethereum: Ethereum L1 se enfoca en la resistencia a la censura, la confiabilidad, la estabilidad y el mantenimiento y mejora de las funciones principales de una determinada capa base, mientras que L2 se enfoca en llegar de manera más directa a los usuarios a través de diferentes culturas y tecnologías. . Pero si sigues este camino, surge un problema inevitable: L2 quiere proporcionar a los usuarios confirmaciones más rápidas que entre 5 y 20 segundos.
Hasta ahora, al menos en teoría, ha sido responsabilidad de L2 crear su propia red de "secuenciadores descentralizados". Un pequeño grupo de validadores puede firmar bloques cada pocos cientos de milisegundos y apostar su participación detrás de esos bloques. Finalmente, los archivos de encabezado de estos fragmentos L2 se publican en L1.
Pero el conjunto de validadores L2 puede "hacer trampa": pueden firmar primero el bloque B 1 y luego firmar un bloque B 2 en conflicto y enviarlo a la cadena antes de B 1. Pero si lo hacen, quedarán atrapados y perderán sus activos pignorados. De hecho, hemos visto ejemplos prácticos de versiones centralizadas, pero el rollup, por otro lado, ha tardado en desarrollar una red de clasificación descentralizada. Se podría argumentar que exigir un orden descentralizado de todas las L2 es injusto: estamos pidiendo que el rollup haga prácticamente el mismo trabajo que crear una L1 completamente nueva. Como tal, Justin Drake ha estado promoviendo una forma para que todos los L2 (y por lo tanto L1) utilicen un mecanismo de preconfirmación compartido en todo Ethereum: la preconfirmación base.
Preconfirmación básica
El enfoque de las preconfirmaciones basadas supone que los proponentes de Ethereum son participantes altamente sofisticados asociados con MEV. Los enfoques basados en la confirmación previa explotan esta complejidad al incentivar a estos proponentes complejos a aceptar la responsabilidad de proporcionar servicios de confirmación previa.
La idea básica de este enfoque es crear un protocolo estandarizado donde los usuarios puedan proporcionar una tarifa adicional para garantizar una garantía instantánea de que una transacción se incluirá en el siguiente bloque, así como un reclamo sobre los resultados de la ejecución de esa transacción. Si un proponente incumple alguna promesa hecha a cualquier usuario, puede ser eliminado.
Como se indicó, las transacciones L1 están garantizadas en base a una confirmación previa. Si los resúmenes están "basados", 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.
(Nota diaria: los proponentes de Ethereum pueden utilizar el mecanismo de tarifas para agrupar una serie de transacciones en un paquete y empaquetarlas en un bloque para garantizar la ejecución y el orden de la transacción. Por ejemplo, el conocido clip garantiza que comprar antes de una determinada transacción y vender El plan propuesto aquí por Vitalik es conceptualmente el mismo. Utilice este proponente para bloquear los resultados de la transacción por adelantado y acelerar la ejecución).
¿Qué estamos mirando realmente?
Supongamos que logramos una finalidad de una sola ranura. Usamos tecnología similar a Orbit para reducir la cantidad de validadores que firman por espacio, pero no demasiado para que también podamos avanzar en el objetivo clave de reducir el mínimo de participación de 32 ETH. El tiempo del intervalo se puede aumentar a 16 segundos y luego utilizamos la confirmación previa acumulada o la confirmación previa básica para brindar a los usuarios una confirmación más rápida. Con lo que terminamos: una arquitectura de ranura de época.
Hay una razón filosófica profunda por la que la arquitectura de época y ranura parece tan difícil de evitar: se necesita menos tiempo para llegar a un acuerdo aproximado sobre algo que para llegar a un acuerdo sobre algo con el mayor grado de "finalidad económica".
Una razón simple es la cantidad de nodos. Si bien la antigua compensación lineal entre descentralización, tiempo de finalidad y gastos generales ahora parece leve debido a la agregación BLS ultraoptimizada y los próximos ZK-STARK, no se pueden ignorar las siguientes razones:
El "consenso aproximado" sólo requiere un pequeño número de nodos, mientras que la finalidad económica requiere una mayoría de nodos.
Una vez que la cantidad de nodos excede un cierto tamaño, debe dedicar más tiempo a recopilar firmas.
En el Ethereum actual, el espacio de 12 segundos se divide en tres subespacios: publicación y distribución en bloque, atestación y agregación de atestación. Si el número de probadores se reduce significativamente, podemos reducirlo a dos subintervalos y utilizar un tiempo de intervalo de 8 segundos. Otro factor 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 determinar la finalidad), podríamos reducir esto a aproximadamente 2 segundos.
Entonces, en mi opinión, la arquitectura de época y ranura es claramente correcta, pero no todas las arquitecturas de época y ranura son iguales, y es valioso explorar el espacio de diseño más completamente. Una dirección que merece una mayor investigación no está tan estrechamente acoplada como la de Gasper, pero sí con una mayor separación de preocupaciones entre los dos mecanismos.
¿Qué debería hacer L2?
En mi opinión, L2 tiene actualmente tres estrategias razonables:
1. Tiene una “base” tanto técnica como espiritual. Es decir, optimizan 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, puede considerar estos paquetes acumulativos como "fragmentos de marca", pero también pueden ser mucho más ambiciosos y experimentar intensamente con nuevos diseños de máquinas virtuales y otras mejoras técnicas.
2. Conviértete en un “servidor con andamiaje blockchain” y aprovéchalo al máximo. Si comienza con un servidor y luego agrega pruebas de validez de STARK para garantizar que el servidor sigue las reglas para garantizar el derecho de los usuarios a retirar o forzar transacciones y para garantizar la libertad de elección colectiva, ya sea mediante retiro masivo coordinado o mediante; una votación de los encargados del cambio, entonces usted. La mayoría de los beneficios de conectarse a la cadena se han obtenido conservando la mayor parte de la eficiencia del servidor. (Nota diaria: Scaffolding se refiere a una herramienta o método que genera automáticamente la estructura básica y el marco de código de un proyecto para que los desarrolladores puedan comenzar a codificar rápidamente).
3. Un término medio: Ethereum, una cadena rápida con cien nodos, proporciona interoperabilidad y seguridad adicionales. Esta es la hoja de ruta real para muchos proyectos L2 en este momento.
Para algunas aplicaciones (por ejemplo, ENS, almacenamiento de claves, algunos protocolos de pago), un tiempo de bloqueo de 12 segundos es suficiente. Para aquellas aplicaciones en las que esto no es aplicable, la única solución es una arquitectura de época y ranura. En los tres casos, la "época" es la SSF de Ethereum, pero la ranura es diferente en cada uno de los tres casos:
Una arquitectura de época y ranura nativa de Ethereum
Preconfirmación del servidor
preconfirmación del comité
Una pregunta clave es: ¿qué tan buenos podemos ser en la Categoría 1? Especialmente si las cosas se ponen realmente buenas, parece que la Categoría 3 no significará tanto. Dado que todas las soluciones "basadas" no son aplicables a los datos L2 fuera de la cadena, como plasmas y validiums, la categoría 2 siempre existirá. Si una arquitectura de época y ranura nativa de Ethereum pudiera reducirse a un tiempo de ranura de 1 segundo, entonces el espacio de Clase 3 sería mucho más pequeño.
Hoy estamos lejos de tener respuestas definitivas a estas preguntas. Una pregunta clave es qué tan complejos se volverán los proponentes de bloques, lo que sigue siendo un área de considerable incertidumbre. Los diseños como Orbit SSF son muy novedosos, por lo que aún vale la pena explorar a fondo el espacio de diseño para esquemas como Orbit SSF como una época en una época y ranura. Cuantas más opciones tengamos, mejor podremos hacerlo para los usuarios de L1 y L2, y podremos hacer la vida más fácil a los desarrolladores de L2.
Enlace original
Este artículo se reimprime con autorización de Odaily Planet Daily.
Fuente
