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 dentro de 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: en primer lugar, este 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. En segundo lugar, 12,8 minutos es demasiado y nadie quiere esperar. así de largo.

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, se seguirá perdiendo el ETH prometido.

Tendermint es un algoritmo de consenso bizantino tolerante a fallas eficiente y seguro que permite una confirmación rápida de las transacciones y garantiza que el sistema blockchain pueda seguir funcionando 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. Si bien 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

Ethereum ha estado siguiendo una hoja de ruta centrada en rollups durante los últimos años, diseñando la capa base de Ethereum (L1) para soportar la disponibilidad de datos y otras características, que luego se ponen a disposición de 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 la funcionalidad central de una determinada capa base, mientras que L2 se enfoca en comunicarse más directamente a través de diferentes culturas y tecnologías. a los usuarios. 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 el bloque B 1 primero 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 es injusto exigir que todas las L2 estén descentralizadas: estamos pidiendo que el rollup haga casi el mismo trabajo que crear una L1 completamente nueva. Por lo tanto, Justin Drake ha estado promoviendo una forma para que todos los L2 (así como L1) utilicen un mecanismo de preconfirmación compartido en todo Ethereum: la preconfirmación básica.

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 empaquetarlo en un bloque, asegurando la ejecución y el orden de la transacción. Por ejemplo, el conocido clip, a través del cual garantiza que comprar antes de un cierta transacción y luego vender. El plan propuesto aquí por Vitalik es conceptualmente consistente y utiliza 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. Lo que obtuvimos al final: una arquitectura de ranura de época.

Hay una profunda razón filosófica 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" requiere sólo un pequeño número de nodos, mientras que la finalidad económica requiere una gran 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: liberación y distribución de bloques, prueba y agregación de pruebas. 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 más realista y de mayor importancia es la "calidad" del nodo. 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 ~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. La 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:

  • Tanto técnica como espiritualmente "de base". 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.

  • 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 la libertad de elección colectiva, ya sea mediante un retiro masivo coordinado o cambiando el pedido; vota, entonces lo tienes. Logra la mayoría de los beneficios del enlace ascendente 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).

  • El término medio: una cadena rápida con cien nodos, Ethereum 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, 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, "época" es el SSF de Ethereum, pero la ranura es diferente en cada uno de los tres casos anteriores:

  • 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? En particular, si las cosas se ponen realmente buenas, parece que la Categoría 3 no significará tanto. Debido a que todas las soluciones "basadas" no funcionan con 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 se puede reducir a un tiempo de ranura de 1 segundo, entonces el espacio para la Categoría 3 será 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 el espacio de diseño de soluciones como el uso de Orbit SSF como época en época y ranura aún merece una exploración completa. 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.