Discutir soluciones prácticas para mejorar el tiempo de confirmación de transacciones en Ethereum

Un aspecto importante de la experiencia del usuario en blockchain es el tiempo de confirmación de las transacciones. En los últimos años, Ethereum ha logrado avances significativos en este sentido. Actualmente, las transacciones enviadas por los usuarios en L1 pueden confirmarse generalmente en 5-20 segundos, lo que es comparable a la experiencia de pago con tarjeta de crédito. Sin embargo, seguir reduciendo el tiempo de confirmación sigue siendo valioso, ya que ciertas aplicaciones incluso requieren una latencia en milisegundos. Este artículo explorará algunas opciones viables de Ethereum en este aspecto.

Resumen de la solución existente

finalización de un solo slot

Actualmente, el consenso Gasper de Ethereum utiliza una arquitectura de ranuras y épocas. Cada 12 segundos hay una ranura, los validadores votan por la cabeza de la cadena, y todos los validadores tienen la oportunidad de votar una vez dentro de 32 ranuras (6.4 minutos). Estos votos se interpretan como mensajes similares al algoritmo de consenso PBFT, y proporcionan una finalización con fuertes garantías económicas después de dos épocas (12.8 minutos).

Sin embargo, este método presenta problemas de complejidad y tiempo excesivo. La Finalidad de Un Solo Slot (SSF) reemplaza esta arquitectura mediante un mecanismo similar al de Tendermint, permitiendo que el bloque N se confirme de manera definitiva antes de que se genere el bloque N+1. SSF conserva el mecanismo de "fugas inactivas", que permite que la cadena continúe funcionando incluso cuando más de 1/3 de los validadores están desconectados.

El principal desafío de SSF es que cada validador debe publicar dos mensajes cada 12 segundos, lo que genera una carga considerable en la cadena. A pesar de algunas soluciones de mitigación, como la propuesta Orbit SSF, los usuarios aún deben esperar de 5 a 20 segundos.

Confirmación previa de Rollup

Ethereum adopta una hoja de ruta centrada en rollup, donde L1 proporciona disponibilidad de datos y otras funciones, y los protocolos L2 ofrecen servicios a gran escala basados en esto para los usuarios. Esto ha llevado a una separación de enfoques: L1 se centra en la resistencia a la censura, la fiabilidad y las funciones centrales, mientras que L2 se dirige directamente a las necesidades de los usuarios.

Teóricamente, L2 puede crear su propia red de "ordenadores descentralizados" que firman bloques cada pocos cientos de milisegundos. Pero esto requiere que L2 realice un trabajo casi idéntico al de crear un nuevo L1, lo que ralentiza el progreso. Por lo tanto, se ha propuesto permitir que todos los L2 compartan un mecanismo de preconfirmación dentro del ámbito de Ethereum: la preconfirmación básica.

confirmación previa básica

La confirmación previa básica utiliza la complejidad de los proponentes de Ethereum para incentivarlos a ofrecer servicios de confirmación previa. Los usuarios pueden pagar una tarifa adicional para obtener la garantía inmediata de que la transacción se incluirá en el próximo bloque. Si el proponente incumple su promesa, enfrentará una penalización. Este mecanismo no solo se aplica a las transacciones de L1, sino que también se puede utilizar en bloques de L2 "basados en" rollups.

Direcciones posibles en el futuro

Supongamos que se ha logrado la finalización en un solo slot, utilizando tecnologías similares a Orbit para reducir el número de validadores que firman en cada slot, mientras se disminuye el umbral de participación. La duración del slot podría aumentar a 16 segundos, combinando la precertificación de rollup o la precertificación básica para proporcionar a los usuarios una confirmación más rápida. Esto en realidad forma una arquitectura de epoch-slot.

La razón por la que esta arquitectura es difícil de evitar es que alcanzar un consenso aproximado requiere menos tiempo que lograr el mayor grado de "finalidad económica". Los factores que influyen incluyen el número de nodos y la "calidad" de los nodos. Si podemos confiar en un subconjunto especializado de nodos para alcanzar un protocolo aproximado, mientras utilizamos un conjunto completo de validadores para determinar la finalidad, es posible reducir el tiempo de confirmación a aproximadamente 2 segundos.

Por lo tanto, es valioso explorar el espacio de diseño de la arquitectura epoch-slot con un mayor enfoque en la separación de preocupaciones.

Selección de estrategia L2

Actualmente hay tres estrategias razonables para L2:

1. Técnicamente y espiritualmente "basado" en Ethereum, optimizando sus atributos técnicos y valores.
2. Convertirse en "servidor con andamiaje de blockchain", combinando la eficiencia del servidor y la seguridad de la blockchain.
3. Método de compromiso: la cadena rápida combinada con Ethereum proporciona interoperabilidad y seguridad adicionales.

Para ciertas aplicaciones, un tiempo de bloque de 12 segundos es suficiente. Para otras aplicaciones, la única solución es la arquitectura epoch-slot. La cuestión clave es cuán bien puede funcionar la arquitectura epoch-slot nativa de Ethereum, lo que afectará el significado de otras soluciones.

Actualmente, estamos lejos de las respuestas finales a estas preguntas. La complejidad de los proponentes de bloques sigue siendo incierta. Nuevos diseños como Orbit SSF ofrecen espacio para explorar más posibilidades. Cuantas más opciones tengamos, mejor podremos servir a los usuarios de L1 y L2, simplificando el trabajo de los desarrolladores de L2.