Aumentar la velocidad de confirmación de transacciones de Ethereum: explorando la arquitectura epoch-slot
Los tiempos de confirmación de transacciones rápidos son uno de los factores clave en la experiencia del usuario de blockchain. En los últimos años, Ethereum ha logrado avances significativos en este aspecto. Actualmente, las transacciones en L1 suelen ser confirmadas en 5-20 segundos, comparable a la experiencia de pago con tarjeta de crédito. Sin embargo, seguir acortando los tiempos de confirmación sigue teniendo valor, ya que algunas aplicaciones incluso requieren retrasos en el rango de milisegundos. Este artículo explorará varias soluciones viables para mejorar los tiempos de confirmación de transacciones en Ethereum.
Resumen de la tecnología existente
finalización de un solo slot
El mecanismo de consenso Gasper que utiliza actualmente Ethereum se basa en la estructura de slots y epochs. Cada 12 segundos hay un slot, y los validadores votan alternativamente en la cabeza de la cadena. Después de dos epochs (12.8 minutos), las transacciones alcanzan el estado de finalización.
Este método presenta dos problemas principales: primero, la alta complejidad, la interacción entre la votación a nivel de ranura y la finalización a nivel de epoch es propensa a errores; segundo, el tiempo de confirmación final de 12.8 minutos es demasiado largo.
La finalización de un solo slot (SSF) propone reemplazar la arquitectura existente con un mecanismo similar al de Tendermint, permitiendo que el bloque N sea confirmado de manera definitiva antes de la generación del bloque N+1. SSF conserva el mecanismo de fuga inactiva, lo que permite que la cadena continúe funcionando incluso cuando más de 1/3 de los validadores están fuera de línea.
El principal desafío de SSF es que cada validador necesita publicar dos mensajes cada 12 segundos, lo que genera una gran carga en la red. Aunque hay algunas soluciones de mitigación, como la propuesta Orbit SSF, los usuarios aún deben esperar de 5 a 20 segundos para confirmar la transacción.
Preconfirmación de Rollup
Ethereum adopta una hoja de ruta centrada en rollups, diseñando L1 como una capa base que soporta la disponibilidad de datos y otras funciones para su uso por los protocolos L2. Esta arquitectura en capas permite que L1 se concentre en la resistencia a la censura, la fiabilidad y las funciones centrales, mientras que L2 se acerca más a las necesidades del usuario.
L2 espera proporcionar a los usuarios una velocidad de confirmación más rápida. En teoría, L2 puede crear su propia red de "ordenadores descentralizados", donde un pequeño grupo de validadores firma bloques cada pocos cientos de milisegundos. Sin embargo, exigir que todos los L2 implementen un ordenamiento descentralizado parece un poco injusto.
Confirmación previa básica
El mecanismo de preconfirmación básica asume que los proponentes de Ethereum son participantes complejos de MEV. Se aprovecha de su especialización incentivando a estos proponentes a ofrecer servicios de preconfirmación.
Los usuarios pueden pagar una tarifa adicional para obtener una garantía instantánea de que la transacción será incluida en el siguiente bloque. Si el proponente incumple la promesa, enfrentará una penalización. Este mecanismo se aplica tanto a las transacciones L1 como a las transacciones L2 basadas en L1.
Perspectivas de la arquitectura epoch-slot
Si logramos una finalización de un solo slot y adoptamos una tecnología similar a Orbit para reducir el número de validadores por slot, mientras mantenemos suficiente descentralización, podríamos obtener una arquitectura de epoch-slot:
epoch: utiliza el mecanismo SSF para confirmar un bloque cada 16 segundos.
slot: Utilizando la preconfirmación de rollup o la preconfirmación básica, proporciona una confirmación de transacción más rápida.
Esta arquitectura refleja una razón filosófica profunda: alcanzar un consenso aproximado requiere menos tiempo que lograr la "finalidad económica" en su máximo grado. Las razones principales incluyen:
Número de 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.
Tiempo de recolección de firmas: el aumento en el número de nodos prolongará el tiempo de recolección de firmas.
Calidad de nodo: Un subconjunto de nodos especializado puede alcanzar un acuerdo aproximado más rápidamente.
Por lo tanto, la arquitectura epoch-slot parece ser inevitable, pero puede haber diferencias significativas entre las diferentes implementaciones. Vale la pena explorar más el espacio de diseño, especialmente para lograr una separación de preocupaciones más fuerte entre los dos mecanismos.
Selección de estrategias de L2
Actualmente hay tres estrategias principales para L2:
"Basado en" Ethereum: optimizar la tecnología y los valores de la capa base de Ethereum.
"Servidor con andamiaje de blockchain": combina la eficiencia del servidor con la seguridad de blockchain.
Solución de compromiso: combinación de la rapidez de la cadena con la seguridad adicional que ofrece Ethereum.
Para diferentes escenarios de aplicación, estas tres estrategias tienen sus ventajas. La cuestión clave es cuán bien puede funcionar la arquitectura de epoch-slot nativa de Ethereum. Si se puede reducir el tiempo de slot a alrededor de 1 segundo, el espacio para la tercera estrategia podría disminuir drásticamente.
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 brindan oportunidades para una exploración adicional. Cuantas más opciones tengamos, mejor experiencia podremos ofrecer a los usuarios de L1 y L2, al mismo tiempo que simplificamos el trabajo de los desarrolladores de L2.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
12 me gusta
Recompensa
12
4
Compartir
Comentar
0/400
MEVHunter
· 08-04 10:34
Buscador de oportunidades de arbitraje MEV, investigador de préstamos relámpago, arquitecto de bots de arbitraje de fórmulas, activo en el ecosistema de Ethereum.
Ver originalesResponder0
Layer2Arbitrageur
· 08-04 10:19
lmao 12.8min de finalización... ngmi con estas guerras de gas tbh
Ver originalesResponder0
YieldHunter
· 08-04 10:16
técnicamente hablando, la finalización de 20s sigue siendo mala para los degens, para ser honesto
Explorando la arquitectura de epoch-slot de Ethereum: una nueva dirección para acelerar la confirmación de transacciones
Aumentar la velocidad de confirmación de transacciones de Ethereum: explorando la arquitectura epoch-slot
Los tiempos de confirmación de transacciones rápidos son uno de los factores clave en la experiencia del usuario de blockchain. En los últimos años, Ethereum ha logrado avances significativos en este aspecto. Actualmente, las transacciones en L1 suelen ser confirmadas en 5-20 segundos, comparable a la experiencia de pago con tarjeta de crédito. Sin embargo, seguir acortando los tiempos de confirmación sigue teniendo valor, ya que algunas aplicaciones incluso requieren retrasos en el rango de milisegundos. Este artículo explorará varias soluciones viables para mejorar los tiempos de confirmación de transacciones en Ethereum.
Resumen de la tecnología existente
finalización de un solo slot
El mecanismo de consenso Gasper que utiliza actualmente Ethereum se basa en la estructura de slots y epochs. Cada 12 segundos hay un slot, y los validadores votan alternativamente en la cabeza de la cadena. Después de dos epochs (12.8 minutos), las transacciones alcanzan el estado de finalización.
Este método presenta dos problemas principales: primero, la alta complejidad, la interacción entre la votación a nivel de ranura y la finalización a nivel de epoch es propensa a errores; segundo, el tiempo de confirmación final de 12.8 minutos es demasiado largo.
La finalización de un solo slot (SSF) propone reemplazar la arquitectura existente con un mecanismo similar al de Tendermint, permitiendo que el bloque N sea confirmado de manera definitiva antes de la generación del bloque N+1. SSF conserva el mecanismo de fuga inactiva, lo que permite que la cadena continúe funcionando incluso cuando más de 1/3 de los validadores están fuera de línea.
El principal desafío de SSF es que cada validador necesita publicar dos mensajes cada 12 segundos, lo que genera una gran carga en la red. Aunque hay algunas soluciones de mitigación, como la propuesta Orbit SSF, los usuarios aún deben esperar de 5 a 20 segundos para confirmar la transacción.
Preconfirmación de Rollup
Ethereum adopta una hoja de ruta centrada en rollups, diseñando L1 como una capa base que soporta la disponibilidad de datos y otras funciones para su uso por los protocolos L2. Esta arquitectura en capas permite que L1 se concentre en la resistencia a la censura, la fiabilidad y las funciones centrales, mientras que L2 se acerca más a las necesidades del usuario.
L2 espera proporcionar a los usuarios una velocidad de confirmación más rápida. En teoría, L2 puede crear su propia red de "ordenadores descentralizados", donde un pequeño grupo de validadores firma bloques cada pocos cientos de milisegundos. Sin embargo, exigir que todos los L2 implementen un ordenamiento descentralizado parece un poco injusto.
Confirmación previa básica
El mecanismo de preconfirmación básica asume que los proponentes de Ethereum son participantes complejos de MEV. Se aprovecha de su especialización incentivando a estos proponentes a ofrecer servicios de preconfirmación.
Los usuarios pueden pagar una tarifa adicional para obtener una garantía instantánea de que la transacción será incluida en el siguiente bloque. Si el proponente incumple la promesa, enfrentará una penalización. Este mecanismo se aplica tanto a las transacciones L1 como a las transacciones L2 basadas en L1.
Perspectivas de la arquitectura epoch-slot
Si logramos una finalización de un solo slot y adoptamos una tecnología similar a Orbit para reducir el número de validadores por slot, mientras mantenemos suficiente descentralización, podríamos obtener una arquitectura de epoch-slot:
Esta arquitectura refleja una razón filosófica profunda: alcanzar un consenso aproximado requiere menos tiempo que lograr la "finalidad económica" en su máximo grado. Las razones principales incluyen:
Por lo tanto, la arquitectura epoch-slot parece ser inevitable, pero puede haber diferencias significativas entre las diferentes implementaciones. Vale la pena explorar más el espacio de diseño, especialmente para lograr una separación de preocupaciones más fuerte entre los dos mecanismos.
Selección de estrategias de L2
Actualmente hay tres estrategias principales para L2:
Para diferentes escenarios de aplicación, estas tres estrategias tienen sus ventajas. La cuestión clave es cuán bien puede funcionar la arquitectura de epoch-slot nativa de Ethereum. Si se puede reducir el tiempo de slot a alrededor de 1 segundo, el espacio para la tercera estrategia podría disminuir drásticamente.
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 brindan oportunidades para una exploración adicional. Cuantas más opciones tengamos, mejor experiencia podremos ofrecer a los usuarios de L1 y L2, al mismo tiempo que simplificamos el trabajo de los desarrolladores de L2.