- Tema
74465 Popularidad
28716 Popularidad
8501 Popularidad
3543 Popularidad
3672 Popularidad
28970 Popularidad
15301 Popularidad
21791 Popularidad
11366 Popularidad
1850 Popularidad
- Anclado
74465 Popularidad
28716 Popularidad
8501 Popularidad
3543 Popularidad
3672 Popularidad
28970 Popularidad
15301 Popularidad
21791 Popularidad
11366 Popularidad
1850 Popularidad
Discusión sobre las soluciones para acelerar la confirmación de transacciones de ETH: de la finalización en un solo slot al mecanismo de pre-confirmación.
Proporcionar tiempos de confirmación de transacciones más rápidos para ETH, mejorando la experiencia del usuario
El tiempo rápido de confirmación de transacciones es una de las características importantes de una buena experiencia de usuario en blockchain. En los últimos años, Ethereum ha logrado avances significativos en este aspecto. Gracias a EIP-1559 y a un tiempo de bloque estable tras la transición a PoS, las transacciones enviadas por los usuarios en L1 generalmente pueden confirmarse en 5-20 segundos, lo que es comparable a la experiencia de pago con tarjeta de crédito. Sin embargo, sigue siendo valioso mejorar aún más la experiencia del usuario, ya que ciertas aplicaciones incluso requieren latencias de sub-segundo. Este artículo explorará algunas opciones viables que Ethereum tiene para mejorar el tiempo de confirmación de transacciones.
Resumen de la técnica existente
finalización de un solo slot
Actualmente, el consenso Gasper de Ethereum adopta una arquitectura de ranura y época. Cada 12 segundos hay una ranura, y algunos validadores votan sobre la cabeza de la cadena; todos los validadores tienen la oportunidad de votar una vez dentro de 32 ranuras (6.4 minutos). Estos votos se reinterpretan como mensajes similares a los del algoritmo de consenso PBFT, y después de dos épocas (12.8 minutos), se proporciona una fuerte garantía económica de lo que se llama finalización.
En los últimos años, este enfoque ha perdido popularidad, principalmente por dos razones: en primer lugar, es demasiado complejo, hay muchos problemas de interacción entre el mecanismo de votación de ranura a ranura y el mecanismo de finalización de época a época; en segundo lugar, el tiempo de espera de 12.8 minutos es demasiado largo.
La finalización de un solo slot (SSF) reemplaza esta arquitectura a través de un mecanismo similar a Tendermint, donde el bloque N se finaliza antes de que se genere el bloque N+1. La principal diferencia con Tendermint es que se mantiene el mecanismo de "fugas inactivas", que permite que la cadena continúe funcionando y se recupere cuando más de 1/3 de los validadores están fuera de línea.
El principal desafío de SSF es que cada staker necesita publicar dos mensajes cada 12 segundos, lo que representa una gran carga para la cadena. Aunque hay algunas ideas innovadoras como Orbit SSF que pueden aliviar este problema, los usuarios aún deben esperar de 5 a 20 segundos.
preconfirmación de Rollup
Ethereum ha seguido un roadmap centrado en rollups, diseñando la capa base (L1) para soportar la disponibilidad de datos y otras funciones para su uso por protocolos L2. Esto ha creado una separación de preocupaciones dentro del ecosistema: L1 se enfoca en la resistencia a la censura, la confiabilidad y la estabilidad, mientras que L2 se dirige más directamente a los usuarios.
En teoría, la creación de una red de ordenadores descentralizada es responsabilidad de L2. Un pequeño grupo de validadores puede firmar bloques cada pocos cientos de milisegundos y apostar activos de garantía en esos bloques. Los encabezados de estos bloques de L2 eventualmente se publicarán en L1.
Sin embargo, parecería poco justo exigir que todos los L2 realicen un ordenamiento descentralizado, lo que equivale a pedir que el rollup complete casi el mismo trabajo que crear un nuevo L1. Por lo tanto, se ha propuesto que todos los L2 (así como el L1) utilicen un mecanismo de preconfirmación compartido dentro del ámbito de Ethereum: la preconfirmación básica.
Confirmación previa básica
El método básico de preconfirmación asume que los proponentes de ETH son participantes altamente complejos relacionados con MEV. Aprovecha esta complejidad incentivando a estos proponentes a aceptar la responsabilidad de ofrecer servicios de preconfirmación.
Este método crea un protocolo estandarizado, donde los usuarios pueden proporcionar tarifas adicionales para obtener la garantía instantánea de que la transacción será incluida en el siguiente bloque, así como una declaración sobre el resultado de la ejecución de dicha transacción. Si el proponente incumple su promesa, puede ser sancionado.
Este mecanismo no solo garantiza las transacciones de L1, sino que para los rollups "basados en", todos los bloques de L2 son transacciones de L1, por lo que también puede proporcionar preconfirmación para cualquier L2.
Perspectivas futuras
Supongamos que se ha logrado la finalización de un solo slot, utilizando una tecnología similar a Orbit para reducir el número de validadores que firman cada slot, al mismo tiempo que se avanza en la reducción del mínimo de 32 ETH de participación. La duración del slot podría aumentar a 16 segundos, y luego se utilizarían las pre-confirmaciones de rollup o pre-confirmaciones básicas para proporcionar a los usuarios una confirmación más rápida. Finalmente, hemos llegado a una nueva era: la arquitectura de slots.
Esta arquitectura parece inevitable, ya que el tiempo necesario para alcanzar un consenso aproximado sobre algo es más corto que el tiempo requerido para lograr la "finalidad económica" en su máxima expresión. Las razones incluyen la cantidad de nodos y la "calidad" de los nodos. Si se puede confiar en un subconjunto especializado de nodos para alcanzar un protocolo aproximado (utilizando aún un conjunto completo de validadores para determinar la finalidad), podemos reducir el tiempo de confirmación a aproximadamente 2 segundos.
Por lo tanto, explorar el espacio de diseño sigue siendo valioso, especialmente en direcciones donde hay una mayor separación de puntos de atención entre los dos mecanismos.
Selección de estrategia L2
L2 actualmente tiene tres estrategias razonables:
Para algunas aplicaciones, un tiempo de bloque de 12 segundos es suficiente. Para otras aplicaciones, la única solución es la arquitectura de época-slot. La cuestión clave es ¿qué tan bien puede funcionar la arquitectura de época-slot nativa de Ethereum? Si puede reducirse a un tiempo de slot de 1 segundo, entonces el espacio para la tercera estrategia se volverá muy pequeño.
Actualmente, estamos lejos de las respuestas definitivas a estas preguntas. La complejidad de los proponentes de bloques aún presenta incertidumbre, y nuevos diseños como Orbit SSF también merecen una exploración más profunda. Cuantas más opciones tengamos, mejor podremos servir a los usuarios de L1 y L2, y simplificar el trabajo de los desarrolladores de L2.