Acelerar la confirmación de transacciones de Ethereum: explorar nuevas soluciones para mejorar la experiencia del usuario
Un elemento central de la experiencia del usuario en blockchain es el tiempo de confirmación de transacciones rápido. En los últimos años, Ethereum ha logrado avances significativos en este aspecto. Gracias a EIP-1559 y a los tiempos de bloque estables tras la transición a la prueba de participación, las transacciones enviadas en la red principal generalmente se confirman en 5-20 segundos, alcanzando prácticamente el nivel de 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 subsegundos. Este artículo explorará varias soluciones viables para mejorar el tiempo de confirmación de transacciones en Ethereum.
Resumen de la Tecnología Actual
finalización de un solo slot
Actualmente, el consenso Gasper de Ethereum utiliza una estructura de doble capa de ranura y época. Cada 12 segundos hay una ranura, y algunos validadores votan sobre el encabezado de la cadena; en 32 ranuras (6.4 minutos ), todos los validadores tienen la oportunidad de votar una vez. Estos votos se interpretan posteriormente como mensajes en un algoritmo de consenso tipo PBFT, y dos épocas (12.8 minutos ) después proporcionan una finalización con fuertes garantías económicas.
En los últimos años, las limitaciones de este método se han vuelto cada vez más evidentes. En primer lugar, la alta complejidad presenta numerosos problemas de interacción entre la votación a nivel de ranura y la finalización a nivel de época. En segundo lugar, el tiempo de espera de 12.8 minutos es demasiado largo, lo que resulta en una experiencia de usuario deficiente.
La finalización de un solo slot (SSF) reemplazó esta arquitectura a través de un mecanismo similar al de Tendermint, permitiendo la confirmación final del bloque N antes de la generación del bloque N+1. La principal diferencia con Tendermint es que se conserva el mecanismo de "fugas inactivas", lo que permite que la cadena continúe operando 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 necesita publicar dos mensajes cada 12 segundos, lo que genera una carga considerable en la cadena. Aunque hay algunas soluciones ingeniosas para mitigar este problema, como el Orbit SSF recientemente propuesto, los usuarios aún deben esperar entre 5 y 20 segundos.
Preconfirmación de Rollup
En los últimos años, Ethereum ha seguido una hoja de ruta centrada en rollups, diseñando la capa base para soportar la disponibilidad de datos y otras funciones para su uso por protocolos L2, con el fin de proporcionar garantías de seguridad a los usuarios a mayor escala.
Esto ha llevado a una separación de puntos de atención dentro del ecosistema de Ethereum: L1 se centra en la resistencia a la censura, la fiabilidad y las mejoras de las funciones centrales, mientras que L2 sirve a los usuarios directamente a través de diferentes culturas y tecnologías. Sin embargo, L2 espera ofrecer a los usuarios confirmaciones más rápidas que de 5 a 20 segundos.
Teóricamente, la creación de 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. Estos encabezados de bloques L2 finalmente se publicarán en L1.
Los validadores de L2 pueden hacer trampa: firman primero el bloque B1, luego firman el bloque en conflicto B2 y lo envían a la cadena antes que B1. Sin embargo, esto los expondrá y perderán sus activos en staking. Aunque ya hay casos prácticos de versiones centralizadas, el rollup avanza lentamente en el desarrollo de redes de ordenación descentralizadas.
Exigir que todos los L2 realicen un ordenamiento descentralizado parece poco razonable, ya que equivale a pedir que el rollup haga un trabajo casi idéntico al de crear un nuevo L1. Por lo tanto, se ha propuesto que todos los L2 (y L1) utilicen un mecanismo de preconfirmación compartido dentro del ámbito de Ethereum: la preconfirmación básica.
Confirmación Preliminar Básica
La suposición básica de preconfirmación es que los proponentes de Ethereum son participantes complejos que manejan MEV. Este enfoque aprovecha su experiencia al incentivar a estos proponentes a asumir la responsabilidad de proporcionar servicios de preconfirmación.
Su idea central es crear un protocolo estándar, donde los usuarios pueden pagar una tarifa adicional para obtener la garantía instantánea de que la transacción será incluida en el siguiente bloque, así como una declaración sobre el resultado de la ejecución. Si el proponente incumple su promesa, enfrentará una penalización.
Este mecanismo no solo es aplicable a las transacciones L1, para los rollups "basados en", todos los bloques L2 son transacciones L1, por lo que también puede proporcionar preconfirmación para cualquier L2.
Perspectivas futuras
Supongamos que se ha logrado la finalización de un solo slot, y se utiliza tecnología similar a Orbit para reducir la cantidad de validadores que firman en cada slot, al mismo tiempo que se busca disminuir el objetivo de 32 ETH de la puerta de slot. La duración del slot podría aumentar a 16 segundos, combinándose con 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, podríamos obtener una arquitectura de época-slot.
Esta arquitectura parece difícil de evitar, ya que el tiempo necesario para alcanzar un consenso aproximado sobre algo es mucho menor que el necesario para lograr la "finalidad económica" en su máxima medida. Las razones incluyen el número de nodos y la "calidad" de los nodos. Si pudiéramos confiar en un subconjunto especializado de nodos para alcanzar un protocolo aproximado, mientras utilizamos un conjunto completo de validadores para determinar la finalidad, el tiempo de confirmación podría reducirse a aproximadamente 2 segundos.
Por lo tanto, la arquitectura de epoch-slot parece ser la dirección correcta, pero hay diferencias entre las distintas implementaciones. Vale la pena explorar el establecimiento de un enfoque de separación de preocupaciones más fuerte entre los dos mecanismos, en lugar de estar estrechamente acoplados como en Gasper.
Selección de estrategia L2
Actualmente hay tres estrategias razonables para L2:
Tanto en tecnología como en filosofía, se "basa" en Ethereum, optimizando sus atributos y valores básicos.
Convertirse en "servidor con andamiaje de blockchain", aprovechando al máximo la eficiencia del servidor.
Solución de compromiso: una cadena rápida con alrededor de cien nodos, Ethereum proporciona interoperabilidad y seguridad adicionales.
Para algunas aplicaciones, un tiempo de bloque de 12 segundos es suficiente. Para otras aplicaciones, la única solución es la arquitectura de época - ranura. En los tres casos, "época" es el SSF de Ethereum, pero las "ranuras" son diferentes:
Arquitectura de época-bandeja nativa de Ethereum
Pre-confirmación del servidor
Pre-confirmación del comité
La cuestión clave es cuán bien puede funcionar la primera opción. Si el efecto es notable, el significado de la tercera opción podría disminuir. La segunda opción siempre existirá, ya que las soluciones "basadas en" no son adecuadas para ciertos datos fuera de la cadena L2. Si la arquitectura de época-bandeja nativa de Ethereum puede reducir el tiempo de bandeja a 1 segundo, el espacio de la tercera opción se reducirá significativamente.
Actualmente, las respuestas finales a estas preguntas aún no se han determinado. Una incertidumbre clave es cuán complejos se volverán los proponentes de bloques. Diseños novedosos como Orbit SSF ofrecen oportunidades para una exploración adicional, como su uso como época en un slot. Cuantas más opciones haya, 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.
21 me gusta
Recompensa
21
5
Compartir
Comentar
0/400
RektDetective
· hace14h
Este tps ha aumentado la latencia, ni siquiera es mejor que Alipay, tsk tsk.
Ver originalesResponder0
BlockchainBard
· 07-20 19:09
No te demores más, es mejor correr en L2 que seguir así.
Ver originalesResponder0
HallucinationGrower
· 07-18 21:22
Sería mejor si pudiera ser más rápido, aunque siento que va a tardar mucho tiempo otra vez.
Ver originalesResponder0
SandwichHunter
· 07-18 21:18
Ah, ¿por qué corres tan rápido? Un hombre que no ama la estabilidad no es digno de ser cómplice de toda la vida.
Ver originalesResponder0
MechanicalMartel
· 07-18 21:07
¿Aún persigues una mayor velocidad? 20 segundos ya es lo suficientemente rápido, ¿verdad?
Nueva solución de aceleración de Ethereum: de la finalización de un solo slot a la arquitectura de época-slot
Acelerar la confirmación de transacciones de Ethereum: explorar nuevas soluciones para mejorar la experiencia del usuario
Un elemento central de la experiencia del usuario en blockchain es el tiempo de confirmación de transacciones rápido. En los últimos años, Ethereum ha logrado avances significativos en este aspecto. Gracias a EIP-1559 y a los tiempos de bloque estables tras la transición a la prueba de participación, las transacciones enviadas en la red principal generalmente se confirman en 5-20 segundos, alcanzando prácticamente el nivel de 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 subsegundos. Este artículo explorará varias soluciones viables para mejorar el tiempo de confirmación de transacciones en Ethereum.
Resumen de la Tecnología Actual
finalización de un solo slot
Actualmente, el consenso Gasper de Ethereum utiliza una estructura de doble capa de ranura y época. Cada 12 segundos hay una ranura, y algunos validadores votan sobre el encabezado de la cadena; en 32 ranuras (6.4 minutos ), todos los validadores tienen la oportunidad de votar una vez. Estos votos se interpretan posteriormente como mensajes en un algoritmo de consenso tipo PBFT, y dos épocas (12.8 minutos ) después proporcionan una finalización con fuertes garantías económicas.
En los últimos años, las limitaciones de este método se han vuelto cada vez más evidentes. En primer lugar, la alta complejidad presenta numerosos problemas de interacción entre la votación a nivel de ranura y la finalización a nivel de época. En segundo lugar, el tiempo de espera de 12.8 minutos es demasiado largo, lo que resulta en una experiencia de usuario deficiente.
La finalización de un solo slot (SSF) reemplazó esta arquitectura a través de un mecanismo similar al de Tendermint, permitiendo la confirmación final del bloque N antes de la generación del bloque N+1. La principal diferencia con Tendermint es que se conserva el mecanismo de "fugas inactivas", lo que permite que la cadena continúe operando 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 necesita publicar dos mensajes cada 12 segundos, lo que genera una carga considerable en la cadena. Aunque hay algunas soluciones ingeniosas para mitigar este problema, como el Orbit SSF recientemente propuesto, los usuarios aún deben esperar entre 5 y 20 segundos.
Preconfirmación de Rollup
En los últimos años, Ethereum ha seguido una hoja de ruta centrada en rollups, diseñando la capa base para soportar la disponibilidad de datos y otras funciones para su uso por protocolos L2, con el fin de proporcionar garantías de seguridad a los usuarios a mayor escala.
Esto ha llevado a una separación de puntos de atención dentro del ecosistema de Ethereum: L1 se centra en la resistencia a la censura, la fiabilidad y las mejoras de las funciones centrales, mientras que L2 sirve a los usuarios directamente a través de diferentes culturas y tecnologías. Sin embargo, L2 espera ofrecer a los usuarios confirmaciones más rápidas que de 5 a 20 segundos.
Teóricamente, la creación de 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. Estos encabezados de bloques L2 finalmente se publicarán en L1.
Los validadores de L2 pueden hacer trampa: firman primero el bloque B1, luego firman el bloque en conflicto B2 y lo envían a la cadena antes que B1. Sin embargo, esto los expondrá y perderán sus activos en staking. Aunque ya hay casos prácticos de versiones centralizadas, el rollup avanza lentamente en el desarrollo de redes de ordenación descentralizadas.
Exigir que todos los L2 realicen un ordenamiento descentralizado parece poco razonable, ya que equivale a pedir que el rollup haga un trabajo casi idéntico al de crear un nuevo L1. Por lo tanto, se ha propuesto que todos los L2 (y L1) utilicen un mecanismo de preconfirmación compartido dentro del ámbito de Ethereum: la preconfirmación básica.
Confirmación Preliminar Básica
La suposición básica de preconfirmación es que los proponentes de Ethereum son participantes complejos que manejan MEV. Este enfoque aprovecha su experiencia al incentivar a estos proponentes a asumir la responsabilidad de proporcionar servicios de preconfirmación.
Su idea central es crear un protocolo estándar, donde los usuarios pueden pagar una tarifa adicional para obtener la garantía instantánea de que la transacción será incluida en el siguiente bloque, así como una declaración sobre el resultado de la ejecución. Si el proponente incumple su promesa, enfrentará una penalización.
Este mecanismo no solo es aplicable a las transacciones L1, para los rollups "basados en", todos los bloques L2 son transacciones L1, por lo que también puede proporcionar preconfirmación para cualquier L2.
Perspectivas futuras
Supongamos que se ha logrado la finalización de un solo slot, y se utiliza tecnología similar a Orbit para reducir la cantidad de validadores que firman en cada slot, al mismo tiempo que se busca disminuir el objetivo de 32 ETH de la puerta de slot. La duración del slot podría aumentar a 16 segundos, combinándose con 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, podríamos obtener una arquitectura de época-slot.
Esta arquitectura parece difícil de evitar, ya que el tiempo necesario para alcanzar un consenso aproximado sobre algo es mucho menor que el necesario para lograr la "finalidad económica" en su máxima medida. Las razones incluyen el número de nodos y la "calidad" de los nodos. Si pudiéramos confiar en un subconjunto especializado de nodos para alcanzar un protocolo aproximado, mientras utilizamos un conjunto completo de validadores para determinar la finalidad, el tiempo de confirmación podría reducirse a aproximadamente 2 segundos.
Por lo tanto, la arquitectura de epoch-slot parece ser la dirección correcta, pero hay diferencias entre las distintas implementaciones. Vale la pena explorar el establecimiento de un enfoque de separación de preocupaciones más fuerte entre los dos mecanismos, en lugar de estar estrechamente acoplados como en Gasper.
Selección de estrategia L2
Actualmente hay tres estrategias razonables para L2:
Para algunas aplicaciones, un tiempo de bloque de 12 segundos es suficiente. Para otras aplicaciones, la única solución es la arquitectura de época - ranura. En los tres casos, "época" es el SSF de Ethereum, pero las "ranuras" son diferentes:
La cuestión clave es cuán bien puede funcionar la primera opción. Si el efecto es notable, el significado de la tercera opción podría disminuir. La segunda opción siempre existirá, ya que las soluciones "basadas en" no son adecuadas para ciertos datos fuera de la cadena L2. Si la arquitectura de época-bandeja nativa de Ethereum puede reducir el tiempo de bandeja a 1 segundo, el espacio de la tercera opción se reducirá significativamente.
Actualmente, las respuestas finales a estas preguntas aún no se han determinado. Una incertidumbre clave es cuán complejos se volverán los proponentes de bloques. Diseños novedosos como Orbit SSF ofrecen oportunidades para una exploración adicional, como su uso como época en un slot. Cuantas más opciones haya, mejor podremos servir a los usuarios de L1 y L2, al mismo tiempo que simplificamos el trabajo de los desarrolladores de L2.