Discusión sobre soluciones prácticas para mejorar el tiempo de confirmación de transacciones de Ethereum
En los últimos años, Ethereum ha logrado avances significativos en la velocidad de confirmación de transacciones. Gracias a EIP-1559 y la estabilidad en el tiempo de bloque tras la transición al mecanismo PoS, las transacciones enviadas por los usuarios en L1 generalmente pueden confirmarse en 5-20 segundos, lo que es casi comparable a la experiencia de pago con tarjeta de crédito. Sin embargo, aún tiene valor mejorar la experiencia del usuario, ya que algunas aplicaciones incluso requieren tiempos de respuesta en el rango de milisegundos. Este artículo explorará varias soluciones viables para mejorar la velocidad de confirmación de transacciones en Ethereum.
Resumen de la técnica existente
finalización de un solo slot
Actualmente, el consenso Gasper de Ethereum adopta una arquitectura de ranuras y períodos. Cada 12 segundos hay una ranura, y un grupo de validadores vota sobre el encabezado de la cadena, teniendo todos los validadores la oportunidad de votar una vez en 32 ranuras (6.4 minutos). Estos votos se interpretan como mensajes en un algoritmo de consenso tipo PBFT, y después de dos períodos (12.8 minutos), se proporciona una finalización con fuertes garantías económicas.
Este método presenta dos problemas principales: primero, la alta complejidad, ya que existen numerosos problemas de interacción entre el mecanismo de votación de ranura a ranura y el mecanismo de finalización de ciclo a ciclo; segundo, el tiempo de confirmación final de 12.8 minutos es demasiado largo y no cumple con las expectativas de los usuarios.
La finalización de un solo slot (SSF) reemplaza esta arquitectura a través de un mecanismo similar a Tendermint, donde el bloque N puede alcanzar una confirmación final antes de que se genere el bloque N+1. SSF conserva 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 es que cada validante necesita publicar dos mensajes cada 12 segundos, lo que representa una carga enorme para la cadena. Aunque hay algunas soluciones de mitigación, como la reciente propuesta Orbit SSF, los usuarios aún deben esperar de 5 a 20 segundos para confirmar la transacción.
Preconfirmación de Rollup
Ethereum ha seguido en los últimos años una hoja de ruta centrada en rollups, diseñando L1 como una capa base que apoya la disponibilidad de datos y otras funciones, para que los protocolos L2 (como rollups, validiums y plasmas) puedan ofrecer servicios con un nivel de seguridad equivalente al de Ethereum a una mayor escala para los usuarios.
Esto ha llevado a la separación de puntos de atención dentro del ecosistema de Ethereum: L1 se centra en la resistencia a la censura, la fiabilidad y la estabilidad, así como en el mantenimiento y la mejora de las funciones centrales; L2, por otro lado, sirve a los usuarios de manera más directa a través de diferentes culturas y tecnologías. Sin embargo, L2 espera ofrecer a los usuarios tiempos de confirmación más rápidos que 5-20 segundos.
En teoría, crear 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. Estos encabezados de bloques L2 eventualmente se publicarán en L1.
Sin embargo, exigir que todos los L2 implementen un ordenamiento descentralizado parece un poco injusto, lo que equivale a pedir que el rollup realice un trabajo casi idéntico al de 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: preconfirmación básica.
Confirmación previa básica
El método básico de preconfirmación supone que los proponentes de Ethereum son participantes complejos relacionados con el MEV. Aprovecha esta complejidad incentivando a estos proponentes a aceptar la responsabilidad de proporcionar servicios de preconfirmación.
Este método crea un protocolo estandarizado, donde 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, así como un compromiso sobre el resultado de la ejecución de esa transacción. Si el proponente incumple el compromiso, enfrentará penalizaciones.
Este mecanismo no solo es aplicable a las transacciones de L1, para los rollups "basados en" Ethereum, todos los bloques de L2 son en realidad transacciones de L1, por lo que el mismo mecanismo puede proporcionar servicios de preconfirmación para cualquier L2.
Arquitectura potencial futura
Supongamos que hemos implementado la finalización de un único slot y utilizamos una tecnología similar a Orbit para reducir el número de validadores que firman cada slot, al mismo tiempo que mantenemos suficiente descentralización para disminuir el umbral de staking. La duración del slot podría aumentar a 16 segundos, y luego utilizamos la preconfirmación de rollup o la preconfirmación básica para ofrecer a los usuarios una confirmación más rápida. Al final, obtenemos una arquitectura de ciclo-slot.
Esta arquitectura es difícil de evitar porque el tiempo necesario para alcanzar un consenso general sobre algo es mucho menor que el tiempo necesario para lograr el mayor grado de "finalidad económica". Las razones incluyen:
"Consenso aproximado" solo requiere una pequeña cantidad de nodos, mientras que la finalización económica necesita la participación de la mayoría de los nodos.
Una vez que el número de nodos supera cierto tamaño, el tiempo necesario para recopilar firmas aumentará significativamente.
En la actual Ethereum, el slot de 12 segundos se divide en tres sub-slots: publicación y distribución de bloques, prueba, agregación de pruebas. Si reducimos drásticamente el número de validadores, podemos reducirlo a dos sub-slots, logrando un tiempo de slot de 8 segundos. Si podemos confiar en un subconjunto de nodos especializados para alcanzar un protocolo aproximado (mientras seguimos utilizando el conjunto completo de validadores para determinar la finalización), incluso podríamos reducir el tiempo a aproximadamente 2 segundos.
Por lo tanto, la arquitectura de ciclo-slot parece ser inevitable, pero existen diferencias entre las distintas implementaciones. Una dirección que vale la pena explorar es establecer una separación de preocupaciones más fuerte entre los dos mecanismos, en lugar de acoplarlos de manera tan estrecha como lo hace Gasper.
Selección de estrategia L2
Actualmente hay tres estrategias razonables para L2:
En términos técnicos y conceptuales, están "basados" en Ethereum. Estos rollups pueden considerarse "fragmentos de marca" y también pueden experimentar mucho en nuevos diseños de máquinas virtuales y otras mejoras tecnológicas.
Convertirse en un "servidor con andamiaje de blockchain". Al agregar pruebas de validez STARK, garantizar los derechos de salida de los usuarios, apoyar la selección colectiva, entre otros, se obtienen la mayoría de los beneficios de estar en la cadena, al mismo tiempo que se preservan las ventajas de eficiencia del servidor.
Método de compromiso: establecer una cadena rápida con cien nodos, mientras se aprovecha la interoperabilidad y seguridad adicionales que ofrece Ethereum. Este es el mapa de ruta práctico actual de muchos proyectos L2.
Para ciertas aplicaciones (como ENS, almacenamiento de claves, algunos protocolos de pago), un tiempo de bloque de 12 segundos es suficiente. Para otras aplicaciones, la única solución es la arquitectura de ciclos y ranuras. En esta arquitectura, "ciclo" es el SSF de Ethereum, y "ranura" varía en diferentes circunstancias:
Arquitectura de ciclo-bandeja nativa de Ethereum
Preconfirmación del servidor
Confirmación previa del comité
La cuestión clave es qué tan bien puede funcionar la primera opción. Si se desempeña excepcionalmente, el significado de la tercera opción se verá debilitado. La segunda opción siempre existirá, ya que todas las soluciones "basadas en" Ethereum no son aplicables a datos L2 fuera de la cadena como plasmas y validiums. Si la arquitectura nativa de Ethereum de ciclos y ranuras puede reducir el tiempo de ranura a 1 segundo, el espacio para la tercera opción se reducirá drásticamente.
Actualmente, estamos lejos de las respuestas finales a estas preguntas. Una incertidumbre clave es cuán complejos se volverán los proponentes de bloques. Diseños novedosos como Orbit SSF nos ofrecen más espacio para explorar, como usar Orbit SSF como un período en la arquitectura de período-bloque. Cuantas más opciones tengamos, mejor podremos servir 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.
17 me gusta
Recompensa
17
5
Compartir
Comentar
0/400
¯\_(ツ)_/¯
· 08-03 14:17
¿Esta velocidad es incluso peor que pow?
Ver originalesResponder0
LightningAllInHero
· 08-02 19:40
Otra vez jugando con la velocidad de confirmación... No sirve de nada.
Ver originalesResponder0
rekt_but_resilient
· 08-02 19:33
L2 es para que sea más rápido.
Ver originalesResponder0
ValidatorViking
· 08-02 19:30
estos tiempos de finalización aún hacen que ragnarök parezca rápido... la infraestructura de nodos necesita pruebas de batalla serias antes de cualquier ajuste de consenso elegante, para ser honesto
Ver originalesResponder0
RugPullSurvivor
· 08-02 19:17
¿Quién va a leer tanto escrito en papel en blanco?
Solución para acelerar la confirmación de transacciones de Ethereum: un análisis completo desde SSF hasta la pre-confirmación en L2.
Discusión sobre soluciones prácticas para mejorar el tiempo de confirmación de transacciones de Ethereum
En los últimos años, Ethereum ha logrado avances significativos en la velocidad de confirmación de transacciones. Gracias a EIP-1559 y la estabilidad en el tiempo de bloque tras la transición al mecanismo PoS, las transacciones enviadas por los usuarios en L1 generalmente pueden confirmarse en 5-20 segundos, lo que es casi comparable a la experiencia de pago con tarjeta de crédito. Sin embargo, aún tiene valor mejorar la experiencia del usuario, ya que algunas aplicaciones incluso requieren tiempos de respuesta en el rango de milisegundos. Este artículo explorará varias soluciones viables para mejorar la velocidad de confirmación de transacciones en Ethereum.
Resumen de la técnica existente
finalización de un solo slot
Actualmente, el consenso Gasper de Ethereum adopta una arquitectura de ranuras y períodos. Cada 12 segundos hay una ranura, y un grupo de validadores vota sobre el encabezado de la cadena, teniendo todos los validadores la oportunidad de votar una vez en 32 ranuras (6.4 minutos). Estos votos se interpretan como mensajes en un algoritmo de consenso tipo PBFT, y después de dos períodos (12.8 minutos), se proporciona una finalización con fuertes garantías económicas.
Este método presenta dos problemas principales: primero, la alta complejidad, ya que existen numerosos problemas de interacción entre el mecanismo de votación de ranura a ranura y el mecanismo de finalización de ciclo a ciclo; segundo, el tiempo de confirmación final de 12.8 minutos es demasiado largo y no cumple con las expectativas de los usuarios.
La finalización de un solo slot (SSF) reemplaza esta arquitectura a través de un mecanismo similar a Tendermint, donde el bloque N puede alcanzar una confirmación final antes de que se genere el bloque N+1. SSF conserva 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 es que cada validante necesita publicar dos mensajes cada 12 segundos, lo que representa una carga enorme para la cadena. Aunque hay algunas soluciones de mitigación, como la reciente propuesta Orbit SSF, los usuarios aún deben esperar de 5 a 20 segundos para confirmar la transacción.
Preconfirmación de Rollup
Ethereum ha seguido en los últimos años una hoja de ruta centrada en rollups, diseñando L1 como una capa base que apoya la disponibilidad de datos y otras funciones, para que los protocolos L2 (como rollups, validiums y plasmas) puedan ofrecer servicios con un nivel de seguridad equivalente al de Ethereum a una mayor escala para los usuarios.
Esto ha llevado a la separación de puntos de atención dentro del ecosistema de Ethereum: L1 se centra en la resistencia a la censura, la fiabilidad y la estabilidad, así como en el mantenimiento y la mejora de las funciones centrales; L2, por otro lado, sirve a los usuarios de manera más directa a través de diferentes culturas y tecnologías. Sin embargo, L2 espera ofrecer a los usuarios tiempos de confirmación más rápidos que 5-20 segundos.
En teoría, crear 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. Estos encabezados de bloques L2 eventualmente se publicarán en L1.
Sin embargo, exigir que todos los L2 implementen un ordenamiento descentralizado parece un poco injusto, lo que equivale a pedir que el rollup realice un trabajo casi idéntico al de 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: preconfirmación básica.
Confirmación previa básica
El método básico de preconfirmación supone que los proponentes de Ethereum son participantes complejos relacionados con el MEV. Aprovecha esta complejidad incentivando a estos proponentes a aceptar la responsabilidad de proporcionar servicios de preconfirmación.
Este método crea un protocolo estandarizado, donde 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, así como un compromiso sobre el resultado de la ejecución de esa transacción. Si el proponente incumple el compromiso, enfrentará penalizaciones.
Este mecanismo no solo es aplicable a las transacciones de L1, para los rollups "basados en" Ethereum, todos los bloques de L2 son en realidad transacciones de L1, por lo que el mismo mecanismo puede proporcionar servicios de preconfirmación para cualquier L2.
Arquitectura potencial futura
Supongamos que hemos implementado la finalización de un único slot y utilizamos una tecnología similar a Orbit para reducir el número de validadores que firman cada slot, al mismo tiempo que mantenemos suficiente descentralización para disminuir el umbral de staking. La duración del slot podría aumentar a 16 segundos, y luego utilizamos la preconfirmación de rollup o la preconfirmación básica para ofrecer a los usuarios una confirmación más rápida. Al final, obtenemos una arquitectura de ciclo-slot.
Esta arquitectura es difícil de evitar porque el tiempo necesario para alcanzar un consenso general sobre algo es mucho menor que el tiempo necesario para lograr el mayor grado de "finalidad económica". Las razones incluyen:
En la actual Ethereum, el slot de 12 segundos se divide en tres sub-slots: publicación y distribución de bloques, prueba, agregación de pruebas. Si reducimos drásticamente el número de validadores, podemos reducirlo a dos sub-slots, logrando un tiempo de slot de 8 segundos. Si podemos confiar en un subconjunto de nodos especializados para alcanzar un protocolo aproximado (mientras seguimos utilizando el conjunto completo de validadores para determinar la finalización), incluso podríamos reducir el tiempo a aproximadamente 2 segundos.
Por lo tanto, la arquitectura de ciclo-slot parece ser inevitable, pero existen diferencias entre las distintas implementaciones. Una dirección que vale la pena explorar es establecer una separación de preocupaciones más fuerte entre los dos mecanismos, en lugar de acoplarlos de manera tan estrecha como lo hace Gasper.
Selección de estrategia L2
Actualmente hay tres estrategias razonables para L2:
En términos técnicos y conceptuales, están "basados" en Ethereum. Estos rollups pueden considerarse "fragmentos de marca" y también pueden experimentar mucho en nuevos diseños de máquinas virtuales y otras mejoras tecnológicas.
Convertirse en un "servidor con andamiaje de blockchain". Al agregar pruebas de validez STARK, garantizar los derechos de salida de los usuarios, apoyar la selección colectiva, entre otros, se obtienen la mayoría de los beneficios de estar en la cadena, al mismo tiempo que se preservan las ventajas de eficiencia del servidor.
Método de compromiso: establecer una cadena rápida con cien nodos, mientras se aprovecha la interoperabilidad y seguridad adicionales que ofrece Ethereum. Este es el mapa de ruta práctico actual de muchos proyectos L2.
Para ciertas aplicaciones (como ENS, almacenamiento de claves, algunos protocolos de pago), un tiempo de bloque de 12 segundos es suficiente. Para otras aplicaciones, la única solución es la arquitectura de ciclos y ranuras. En esta arquitectura, "ciclo" es el SSF de Ethereum, y "ranura" varía en diferentes circunstancias:
La cuestión clave es qué tan bien puede funcionar la primera opción. Si se desempeña excepcionalmente, el significado de la tercera opción se verá debilitado. La segunda opción siempre existirá, ya que todas las soluciones "basadas en" Ethereum no son aplicables a datos L2 fuera de la cadena como plasmas y validiums. Si la arquitectura nativa de Ethereum de ciclos y ranuras puede reducir el tiempo de ranura a 1 segundo, el espacio para la tercera opción se reducirá drásticamente.
Actualmente, estamos lejos de las respuestas finales a estas preguntas. Una incertidumbre clave es cuán complejos se volverán los proponentes de bloques. Diseños novedosos como Orbit SSF nos ofrecen más espacio para explorar, como usar Orbit SSF como un período en la arquitectura de período-bloque. Cuantas más opciones tengamos, mejor podremos servir a los usuarios de L1 y L2, al mismo tiempo que simplificamos el trabajo de los desarrolladores de L2.