Explorar tiempos de confirmación de transacciones de Ethereum más rápidos
El tiempo de confirmación de transacciones rápido es una parte importante de la experiencia del usuario de blockchain de calidad. En los últimos años, Ethereum ha logrado avances significativos en este aspecto. Actualmente, 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 algunas aplicaciones incluso requieren una latencia en el subsegundo. Este artículo explorará algunas opciones viables para que Ethereum mejore el tiempo de confirmación de transacciones.
Resumen de la tecnología existente
finalización de un solo slot
El consenso Gasper actual de Ethereum adopta una arquitectura de ranuras y épocas. Cada 12 segundos se abre una ranura, y un número limitado de validadores vota 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 en un algoritmo de consenso tipo PBFT, proporcionando finalización con fuertes garantías económicas después de dos épocas (12.8 minutos).
En los últimos años, las desventajas de este método se han vuelto cada vez más evidentes: alta complejidad y un tiempo de confirmación final de 12.8 minutos que es demasiado largo. La finalización de un solo slot (SSF) ha reemplazado esta arquitectura mediante un mecanismo similar a Tendermint, donde el bloque N se confirma de forma definitiva antes de que se genere el bloque N+1. SSF mantiene el mecanismo de "fugas inactivas", que permite 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 es que cada apostador debe publicar dos mensajes cada 12 segundos, lo que genera una carga considerable en la cadena. Aunque hay algunas soluciones de mitigación, como la propuesta Orbit SSF, los usuarios aún deben esperar de 5 a 20 segundos.
Preconfirmación de Rollup
Ethereum adopta una hoja de ruta centrada en rollup, donde L1 proporciona disponibilidad de datos y funciones centrales, y los protocolos L2 (como rollups, validiums y plasmas) ofrecen servicios a gran escala a los usuarios sobre esta base. L2 espera proporcionar a los usuarios tiempos de confirmación más rápidos.
En teoría, L2 puede crear su propia red de "ordenadores descentralizados" que firma bloques cada pocos cientos de milisegundos. Sin embargo, exigir que todos los L2 realicen un ordenamiento descentralizado parece un poco injusto, ya que equivale a crear un nuevo L1.
Confirmación previa básica
La suposición básica de la pre-confirmación es que los proponentes de Ethereum son participantes complejos de MEV, aprovechando esta complejidad al incentivarlos a aceptar la responsabilidad de proporcionar servicios de pre-confirmación. Este enfoque crea un protocolo estandarizado, donde los usuarios pueden ofrecer tarifas adicionales para obtener una garantía instantánea de que sus transacciones se incluirán en el siguiente bloque. Si el proponente incumple su promesa, será penalizado.
Este mecanismo puede proporcionar preconfirmaciones para transacciones L1 y bloques L2 basados en.
Perspectivas futuras
Supongamos que se ha logrado la finalización de un solo slot y se ha utilizado tecnología similar a Orbit para reducir el número de validadores que firman cada slot, al mismo tiempo que se disminuye el umbral de staking. La duración del slot podría aumentar a 16 segundos y, combinado con la preconfirmación de rollup o la preconfirmación básica, se ofrecería a los usuarios una confirmación más rápida. Esto formará una nueva arquitectura de epoch-slot.
La razón por la que la arquitectura epoch-slot es difícil de evitar es que el tiempo necesario para alcanzar un consenso aproximado es más corto que el tiempo necesario para alcanzar un acuerdo de "finalidad económica" en su máxima expresión. Esto involucra factores como la cantidad de nodos y la "calidad" de los nodos.
Para L2, actualmente hay tres estrategias razonables:
Técnicamente y espiritualmente "basado en" Ethereum, optimizando sus atributos fundamentales y valores.
Convertirse en "servidor con andamios de blockchain", aprovechando al máximo la eficiencia del servidor.
Solución de compromiso: una cadena rápida con aproximadamente cien nodos, Ethereum proporciona interoperabilidad y seguridad adicionales.
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 1 segundo, el espacio para la tercera estrategia se reducirá considerablemente.
Actualmente, todavía estamos lejos de las respuestas definitivas a estas preguntas. La complejidad de los proponentes de bloques aún presenta incertidumbre. Diseños novedosos como Orbit SSF ofrecen oportunidades para 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.
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.
Ethereum acelerando en proceso: explorando soluciones de confirmación de transacciones en subsegundos
Explorar tiempos de confirmación de transacciones de Ethereum más rápidos
El tiempo de confirmación de transacciones rápido es una parte importante de la experiencia del usuario de blockchain de calidad. En los últimos años, Ethereum ha logrado avances significativos en este aspecto. Actualmente, 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 algunas aplicaciones incluso requieren una latencia en el subsegundo. Este artículo explorará algunas opciones viables para que Ethereum mejore el tiempo de confirmación de transacciones.
Resumen de la tecnología existente
finalización de un solo slot
El consenso Gasper actual de Ethereum adopta una arquitectura de ranuras y épocas. Cada 12 segundos se abre una ranura, y un número limitado de validadores vota 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 en un algoritmo de consenso tipo PBFT, proporcionando finalización con fuertes garantías económicas después de dos épocas (12.8 minutos).
En los últimos años, las desventajas de este método se han vuelto cada vez más evidentes: alta complejidad y un tiempo de confirmación final de 12.8 minutos que es demasiado largo. La finalización de un solo slot (SSF) ha reemplazado esta arquitectura mediante un mecanismo similar a Tendermint, donde el bloque N se confirma de forma definitiva antes de que se genere el bloque N+1. SSF mantiene el mecanismo de "fugas inactivas", que permite 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 es que cada apostador debe publicar dos mensajes cada 12 segundos, lo que genera una carga considerable en la cadena. Aunque hay algunas soluciones de mitigación, como la propuesta Orbit SSF, los usuarios aún deben esperar de 5 a 20 segundos.
Preconfirmación de Rollup
Ethereum adopta una hoja de ruta centrada en rollup, donde L1 proporciona disponibilidad de datos y funciones centrales, y los protocolos L2 (como rollups, validiums y plasmas) ofrecen servicios a gran escala a los usuarios sobre esta base. L2 espera proporcionar a los usuarios tiempos de confirmación más rápidos.
En teoría, L2 puede crear su propia red de "ordenadores descentralizados" que firma bloques cada pocos cientos de milisegundos. Sin embargo, exigir que todos los L2 realicen un ordenamiento descentralizado parece un poco injusto, ya que equivale a crear un nuevo L1.
Confirmación previa básica
La suposición básica de la pre-confirmación es que los proponentes de Ethereum son participantes complejos de MEV, aprovechando esta complejidad al incentivarlos a aceptar la responsabilidad de proporcionar servicios de pre-confirmación. Este enfoque crea un protocolo estandarizado, donde los usuarios pueden ofrecer tarifas adicionales para obtener una garantía instantánea de que sus transacciones se incluirán en el siguiente bloque. Si el proponente incumple su promesa, será penalizado.
Este mecanismo puede proporcionar preconfirmaciones para transacciones L1 y bloques L2 basados en.
Perspectivas futuras
Supongamos que se ha logrado la finalización de un solo slot y se ha utilizado tecnología similar a Orbit para reducir el número de validadores que firman cada slot, al mismo tiempo que se disminuye el umbral de staking. La duración del slot podría aumentar a 16 segundos y, combinado con la preconfirmación de rollup o la preconfirmación básica, se ofrecería a los usuarios una confirmación más rápida. Esto formará una nueva arquitectura de epoch-slot.
La razón por la que la arquitectura epoch-slot es difícil de evitar es que el tiempo necesario para alcanzar un consenso aproximado es más corto que el tiempo necesario para alcanzar un acuerdo de "finalidad económica" en su máxima expresión. Esto involucra factores como la cantidad de nodos y la "calidad" de los nodos.
Para L2, actualmente hay tres estrategias razonables:
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 1 segundo, el espacio para la tercera estrategia se reducirá considerablemente.
Actualmente, todavía estamos lejos de las respuestas definitivas a estas preguntas. La complejidad de los proponentes de bloques aún presenta incertidumbre. Diseños novedosos como Orbit SSF ofrecen oportunidades para 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.