Discusión sobre soluciones viables para mejorar la velocidad de confirmación de transacciones en Ethereum
Un indicador importante de la experiencia del usuario en blockchain es el tiempo de confirmación de transacciones. En los últimos años, Ethereum ha logrado avances significativos en este aspecto. Actualmente, las transacciones enviadas por los usuarios en L1 generalmente se confirman 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, y algunas aplicaciones incluso requieren una latencia de subsegundo. Este artículo explorará varias posibles soluciones para mejorar el tiempo 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 una estructura de ranuras y ciclos. Cada 12 segundos es una ranura, y algunos validadores votan sobre la cabeza de la cadena. En 32 ranuras (6.4 minutos), todos los validadores tienen la oportunidad de votar una vez. Estos votos se interpretan como mensajes en un algoritmo de consenso tipo PBFT, y después de dos ciclos (12.8 minutos), se proporciona una finalización con fuertes garantías económicas.
Sin embargo, este método presenta problemas de complejidad y tiempo excesivo. La finalización de un solo slot (SSF) propone reemplazar la arquitectura existente con un mecanismo similar al de Tendermint, es decir, completar la confirmación final del bloque actual antes de generar el siguiente bloque. El principal desafío de SSF es que requiere una gran cantidad de interacciones de mensajes cada 12 segundos, lo que impone una carga considerable a 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 para confirmar una transacción.
Preconfirmación de Rollup
Ethereum ha seguido una hoja de ruta centrada en rollup, diseñando L1 como una capa base que soporta la disponibilidad de datos y otras funcionalidades para el uso de protocolos L2. Esta arquitectura en capas permite que L1 se enfoque en la resistencia a la censura, la fiabilidad y la mejora de funciones centrales, mientras que L2 atiende más directamente las necesidades de los usuarios.
En teoría, L2 puede crear su propia red de "ordenadores descentralizados" que firman bloques cada pocos cientos de milisegundos. Sin embargo, exigir que todos los L2 implementen un ordenamiento descentralizado parece poco realista. Por lo tanto, se ha propuesto un esquema que permite que todos los L2 y L1 compartan un mecanismo de pre-confirmación: pre-confirmación básica.
Confirmación previa básica
La suposición básica de la preconfirmación es que los proponentes de Ethereum son participantes complejos de MEV. Este enfoque incentiva a estos proponentes a ofrecer servicios de preconfirmación. Los usuarios pueden pagar una tarifa adicional para obtener la garantía instantánea de que su transacción será incluida en el siguiente bloque. Si los proponentes incumplen su promesa, enfrentarán sanciones.
Este mecanismo no solo se aplica a las transacciones de L1, sino que para los rollups "basados en" Ethereum, todos los bloques de L2 son en realidad transacciones de L1, por lo que también pueden disfrutar del mismo mecanismo de preconfirmación.
Posibles direcciones de desarrollo
Supongamos que se ha logrado la finalización en un solo slot y se ha utilizado una tecnología similar a Orbit para reducir el número de validadores que firman en cada slot. La duración del slot podría aumentar a 16 segundos, mientras que se utiliza la preconfirmación de rollup o la preconfirmación básica para proporcionar a los usuarios una confirmación más rápida. Esto en realidad forma una nueva arquitectura de epoch-slot.
La arquitectura de epoch-slot parece inevitable, principalmente porque el tiempo necesario para alcanzar un consenso general es mucho menor que el tiempo necesario para alcanzar el máximo nivel de "finalidad económica". Esto involucra factores como la cantidad de nodos y la "calidad" de los nodos.
Posibles estrategias de L2
L2 actualmente tiene tres estrategias principales:
Tanto en términos técnicos como conceptuales, está "basado en" Ethereum, optimizando sus atributos fundamentales y valores.
Convertirse en "servidor con andamiaje de blockchain", aprovechando al máximo la eficiencia centralizada mientras se conservan las ventajas de la descentralización.
Solución de compromiso: combinación de la rapidez de la cadena y la seguridad de Ethereum.
Para diferentes aplicaciones, un tiempo de bloque de 12 segundos puede ser suficiente. Para aplicaciones que requieren confirmaciones más rápidas, la única solución es la arquitectura de epoch-slot. La cuestión clave es cuán bien puede funcionar la arquitectura de epoch-slot nativa de Ethereum, lo que afectará el espacio de desarrollo de otras soluciones.
Actualmente, estamos lejos de las respuestas finales a estas preguntas. Existen incertidumbres en cuanto a la complejidad de los proponentes de bloques y el potencial de nuevas tecnologías como Orbit SSF. Explorar más opciones de diseño ayuda a proporcionar un mejor servicio a los usuarios de L1 y L2, y simplifica 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.
13 me gusta
Recompensa
13
6
Compartir
Comentar
0/400
GasFeeNightmare
· hace6h
Otra espera de 20 segundos, mejor que sea cross-chain.
Exploración de la aceleración de Ethereum: nueva arquitectura de finalización de un solo slot, preconfirmaciones y epoch-slot
Discusión sobre soluciones viables para mejorar la velocidad de confirmación de transacciones en Ethereum
Un indicador importante de la experiencia del usuario en blockchain es el tiempo de confirmación de transacciones. En los últimos años, Ethereum ha logrado avances significativos en este aspecto. Actualmente, las transacciones enviadas por los usuarios en L1 generalmente se confirman 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, y algunas aplicaciones incluso requieren una latencia de subsegundo. Este artículo explorará varias posibles soluciones para mejorar el tiempo 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 una estructura de ranuras y ciclos. Cada 12 segundos es una ranura, y algunos validadores votan sobre la cabeza de la cadena. En 32 ranuras (6.4 minutos), todos los validadores tienen la oportunidad de votar una vez. Estos votos se interpretan como mensajes en un algoritmo de consenso tipo PBFT, y después de dos ciclos (12.8 minutos), se proporciona una finalización con fuertes garantías económicas.
Sin embargo, este método presenta problemas de complejidad y tiempo excesivo. La finalización de un solo slot (SSF) propone reemplazar la arquitectura existente con un mecanismo similar al de Tendermint, es decir, completar la confirmación final del bloque actual antes de generar el siguiente bloque. El principal desafío de SSF es que requiere una gran cantidad de interacciones de mensajes cada 12 segundos, lo que impone una carga considerable a 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 para confirmar una transacción.
Preconfirmación de Rollup
Ethereum ha seguido una hoja de ruta centrada en rollup, diseñando L1 como una capa base que soporta la disponibilidad de datos y otras funcionalidades para el uso de protocolos L2. Esta arquitectura en capas permite que L1 se enfoque en la resistencia a la censura, la fiabilidad y la mejora de funciones centrales, mientras que L2 atiende más directamente las necesidades de los usuarios.
En teoría, L2 puede crear su propia red de "ordenadores descentralizados" que firman bloques cada pocos cientos de milisegundos. Sin embargo, exigir que todos los L2 implementen un ordenamiento descentralizado parece poco realista. Por lo tanto, se ha propuesto un esquema que permite que todos los L2 y L1 compartan un mecanismo de pre-confirmación: pre-confirmación básica.
Confirmación previa básica
La suposición básica de la preconfirmación es que los proponentes de Ethereum son participantes complejos de MEV. Este enfoque incentiva a estos proponentes a ofrecer servicios de preconfirmación. Los usuarios pueden pagar una tarifa adicional para obtener la garantía instantánea de que su transacción será incluida en el siguiente bloque. Si los proponentes incumplen su promesa, enfrentarán sanciones.
Este mecanismo no solo se aplica a las transacciones de L1, sino que para los rollups "basados en" Ethereum, todos los bloques de L2 son en realidad transacciones de L1, por lo que también pueden disfrutar del mismo mecanismo de preconfirmación.
Posibles direcciones de desarrollo
Supongamos que se ha logrado la finalización en un solo slot y se ha utilizado una tecnología similar a Orbit para reducir el número de validadores que firman en cada slot. La duración del slot podría aumentar a 16 segundos, mientras que se utiliza la preconfirmación de rollup o la preconfirmación básica para proporcionar a los usuarios una confirmación más rápida. Esto en realidad forma una nueva arquitectura de epoch-slot.
La arquitectura de epoch-slot parece inevitable, principalmente porque el tiempo necesario para alcanzar un consenso general es mucho menor que el tiempo necesario para alcanzar el máximo nivel de "finalidad económica". Esto involucra factores como la cantidad de nodos y la "calidad" de los nodos.
Posibles estrategias de L2
L2 actualmente tiene tres estrategias principales:
Para diferentes aplicaciones, un tiempo de bloque de 12 segundos puede ser suficiente. Para aplicaciones que requieren confirmaciones más rápidas, la única solución es la arquitectura de epoch-slot. La cuestión clave es cuán bien puede funcionar la arquitectura de epoch-slot nativa de Ethereum, lo que afectará el espacio de desarrollo de otras soluciones.
Actualmente, estamos lejos de las respuestas finales a estas preguntas. Existen incertidumbres en cuanto a la complejidad de los proponentes de bloques y el potencial de nuevas tecnologías como Orbit SSF. Explorar más opciones de diseño ayuda a proporcionar un mejor servicio a los usuarios de L1 y L2, y simplifica el trabajo de los desarrolladores de L2.