Confirmación rápida de transacciones: una nueva dirección para mejorar la experiencia del usuario de Ethereum

Un aspecto importante de la experiencia del usuario en blockchain es la velocidad de confirmación de las transacciones. En los últimos años, Ethereum ha logrado avances significativos en este aspecto. Gracias a EIP-1559 y a la estabilidad en el tiempo de bloque tras la transición a PoS, las transacciones enviadas por los usuarios en L1 suelen confirmarse en 5-20 segundos, lo que equivale aproximadamente a la experiencia de pago con tarjeta de crédito. Sin embargo, seguir acortando el tiempo de confirmación sigue siendo valioso, ya que algunas aplicaciones incluso requieren una latencia de subsegundo. Este artículo explorará varias soluciones viables para mejorar la velocidad de confirmación de las transacciones de Ethereum.

Resumen de la técnica existente

finalización de un solo slot

Actualmente, el consenso Gasper de Ethereum adopta la arquitectura de Slot( y Epoch). Cada 12 segundos hay un slot, donde algunos validadores votan por la cabeza de la cadena, y 32 slots dentro de 6.4 minutos permiten que todos los validadores voten una vez. Estos votos se interpretan como mensajes en un algoritmo de consenso tipo PBFT, proporcionando finalización con fuertes garantías económicas después de dos épocas en 12.8 minutos.

En los últimos años, este enfoque ha comenzado a mostrar defectos: en primer lugar, la alta complejidad; la interacción entre los mecanismos de nivel de ranura y de época es propensa a errores; en segundo lugar, el tiempo de espera de 12.8 minutos es demasiado largo. La Finalidad de una Sola Ranura (Single Slot Finality, SSF) ha reemplazado esta arquitectura a través de un mecanismo similar a Tendermint, permitiendo que el bloque N sea confirmado de manera definitiva antes de la generación de N+1. SSF mantiene el mecanismo de "fugas inactivas", permitiendo que la cadena continúe funcionando y se recupere incluso cuando más de 1/3 de los validadores están fuera de línea.

El principal desafío de SSF radica en que cada validor debe publicar dos mensajes cada 12 segundos, lo que genera una gran carga para la cadena. Aunque hay algunas soluciones de mitigación, como la reciente propuesta de Orbit SSF, los usuarios aún deben esperar entre 5 y 20 segundos para confirmar una transacción.

( Preconfirmación de Rollup

En los últimos años, Ethereum ha seguido una hoja de ruta centrada en rollups, diseñando L1 para apoyar funciones básicas como la disponibilidad de datos, para que los protocolos L2 ) como rollups, validiums y plasmas ( puedan utilizarlo, proporcionando la misma seguridad a los usuarios a mayor escala.

Esto ha llevado a una división del trabajo dentro del ecosistema de Ethereum: L1 se centra en la resistencia a la censura, la fiabilidad y la mejora de funciones centrales, mientras que L2 satisface de manera más directa las necesidades de los usuarios. Sin embargo, L2 espera proporcionar a los usuarios confirmaciones más rápidas que de 5 a 20 segundos.

Teóricamente, 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 como garantía. Los encabezados de estos bloques L2 finalmente se publicarán en L1.

Pero los conjuntos de validadores L2 pueden actuar de manera malintencionada: firman primero el bloque B1, y luego firman el B2 en conflicto y lo envían anticipadamente. Una vez que se descubren, perderán sus activos en garantía. Actualmente ya existen ejemplos de versiones centralizadas, pero el desarrollo de redes de ordenación descentralizadas mediante rollup avanza lentamente. Exigir que todos los L2 implementen un ordenamiento descentralizado parece bastante injusto, ya que es casi equivalente a crear un nuevo L1. Por lo tanto, se ha propuesto que todos los L2) y L1( compartan un mecanismo de preconfirmación dentro del rango de Ethereum: la preconfirmación básica.

) Confirmación previa básica

La suposición básica de preconfirmación es que los proponentes de Ethereum son participantes altamente complejos relacionados con MEV, aprovechando esta complejidad al incentivarlos a asumir la responsabilidad del servicio de preconfirmación.

Su idea básica es crear un protocolo estandarizado, donde los usuarios pueden pagar una tarifa adicional para obtener una garantía de que la transacción se incluirá en el siguiente bloque, así como una declaración sobre el resultado de la transacción. Si el proponente incumple, será penalizado.

Mecanismo que puede ser utilizado tanto para transacciones L1, como para bloques L2 "basados en" rollups.

![Vitalik propuso el esquema Epoch y slot: para proporcionar tiempos de confirmación de transacciones más rápidos para ETH, mejorando la experiencia del usuario final]###https://img-cdn.gateio.im/webp-social/moments-cebb5794aeeb2ebb84fbdc0ea0ba2666.webp(

Perspectivas futuras

Supongamos que hemos implementado la finalización de un solo slot, utilizando tecnología similar a Orbit para reducir la cantidad de validadores de firma por slot, mientras avanzamos hacia el objetivo de reducir el umbral de 32 ETH para el staking. La duración del slot podría aumentar a 16 segundos, y luego utilizar rollup para preconfirmaciones o preconfirmaciones básicas para proporcionar a los usuarios una confirmación más rápida. Al final, obtenemos una nueva era: la arquitectura de slots.

La profunda razón por la cual esta arquitectura es difícil de evitar es que el tiempo necesario para alcanzar un acuerdo general sobre algo es mucho menor que el tiempo necesario para alcanzar el máximo "finalidad económica".

Las principales razones incluyen la cantidad de nodos y la "calidad" de los nodos. El "consenso aproximado" solo requiere unos pocos nodos, mientras que la finalización económica necesita la participación de la mayoría de los nodos. Un subconjunto de nodos especializados puede reducir el tiempo del protocolo aproximado a aproximadamente 2 segundos.

Por lo tanto, la arquitectura del epoch-slot parece estar en la dirección correcta, pero existen diferencias entre las distintas implementaciones. Vale la pena explorar el establecimiento de un punto de separación de atención más fuerte entre los dos mecanismos, en lugar de estar acoplados de manera tan estrecha como en Gasper.

![Vitalik propone el esquema Epoch y slot: para proporcionar tiempos de confirmación de transacciones más rápidos para ETH y mejorar la experiencia del usuario final])https://img-cdn.gateio.im/webp-social/moments-c36acc8d123e717d8dbd2c0b79a7a7ca.webp(

Elección de L2

Actualmente hay tres estrategias razonables para L2:

1. Tanto en términos técnicos como conceptuales, está "basado" en Ethereum, optimizando sus atributos y valores fundamentales. Se puede considerar como "fragmento de marca", y también se pueden hacer innovaciones audaces en aspectos como el diseño de nuevas VM.

2. Convertirse en un "servidor con andamios de blockchain", aprovechando al máximo las ventajas de la centralización, mientras se asegura la seguridad a través de pruebas de validez, mecanismos de salida, etc.

3. Solución de compromiso: una cadena rápida con alrededor de cien nodos, Ethereum proporciona interoperabilidad y seguridad adicionales. Esta es la ruta actual de muchos proyectos L2.

Para ciertas aplicaciones ) como ENS, almacenamiento de claves y algunos protocolos de pago ###, un tiempo de bloque de 12 segundos es suficiente. Otras situaciones requieren una arquitectura de época - ranura, donde "época" es el SSF de Ethereum, y "ranura" varía según la aplicación.

La cuestión clave es hasta qué punto puede llegar la arquitectura de épocas y ranuras nativa de Ethereum. Si el tiempo de ranura se puede reducir a 1 segundo, el espacio de la tercera opción se reducirá significativamente.

Actualmente, aún estamos lejos de las respuestas finales a estas preguntas. La evolución de la complejidad de los proponentes de bloques sigue teniendo una gran incertidumbre. Diseños novedosos como Orbit SSF ofrecen un amplio espacio para la exploración. Cuantas más opciones tengamos, mejor experiencia podremos ofrecer a los usuarios de L1 y L2, y también simplificaremos el trabajo para los desarrolladores de L2.