Optimización del tiempo de confirmación de transacciones de Ethereum: explorando una experiencia de usuario más rápida
Una de las claves de la experiencia del usuario en blockchain es la velocidad de confirmación de las transacciones. En los últimos años, Ethereum ha logrado avances significativos en este aspecto. Actualmente, las transacciones en L1 suelen confirmarse en 5-20 segundos, lo que es comparable a los pagos 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 tiempos de respuesta inferiores a un segundo. Este artículo discutirá varias soluciones viables para que Ethereum mejore la velocidad de confirmación de las transacciones.
Resumen de la técnica existente
finalización de un solo slot
El mecanismo de consenso Gasper actualmente adoptado por Ethereum se basa en una estructura de ranuras y épocas. Cada 12 segundos hay una ranura, y algunos validadores votan sobre la cabeza de la cadena. Después de 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, proporcionando una finalización con fuertes garantías económicas después de dos épocas (12.8 minutos).
Este método presenta dos problemas principales: alta complejidad y un tiempo de confirmación final de 12.8 minutos que es demasiado largo. La finalización de una sola ranura (SSF) reemplaza la arquitectura existente a través de un mecanismo similar a Tendermint, permitiendo que el bloque N se confirme de manera 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 desconectados.
El principal desafío de SSF es que cada 12 segundos se requiere que todos los stakers publiquen dos mensajes, lo que supone una carga considerable para la red. Aunque existen algunas soluciones de mitigación, como el reciente Orbit SSF propuesto, los usuarios aún deben esperar de 5 a 20 segundos para confirmar la transacción.
Preconfirmación de Rollup
Ethereum ha adoptado en los últimos años una ruta de desarrollo centrada en rollups, donde L1 proporciona funciones básicas como la disponibilidad de datos para su uso por los protocolos L2. Esto ha llevado a una separación de enfoques: L1 se centra en la resistencia a la censura, la fiabilidad y las mejoras de funciones centrales, mientras que L2 se dirige más directamente a las necesidades de los usuarios.
En teoría, la creación de una red de ordenadores descentralizados es responsabilidad de L2. Un pequeño grupo de validadores puede firmar bloques cada pocos cientos de milisegundos y apostar activos como garantía. Finalmente, los encabezados de estos bloques de L2 se publicarán en L1.
Sin embargo, parecería poco razonable exigir que todos los L2 implementen un ordenamiento descentralizado, lo que equivale a crear un L1 completamente nuevo. Por lo tanto, se ha propuesto la idea de que todos los L2 (incluso L1) compartan un mecanismo de preconfirmación: la preconfirmación básica.
Confirmación previa básica
La preconfirmación básica aprovecha la complejidad de los proponentes de Ethereum, incentivándolos a asumir la responsabilidad de proporcionar servicios de preconfirmación. 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. Si el proponente incumple su promesa, enfrentará penalizaciones.
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 esencialmente transacciones de L1, por lo que también pueden disfrutar del mismo servicio de preconfirmación.
Perspectivas Futuras
Supongamos que hemos implementado la finalización en un solo slot y utilizamos tecnología similar a Orbit para reducir el número de validadores por slot, al mismo tiempo que aumentamos la duración del slot a 16 segundos. Combinando la preconfirmación de rollup o la preconfirmación básica, podemos ofrecer a los usuarios una experiencia de confirmación más rápida. Esta arquitectura puede denominarse estructura "época-slot".
La aparición de esta estructura tiene razones profundas: el tiempo necesario para alcanzar un consenso general sobre algo suele ser menor que el tiempo necesario para alcanzar el máximo "finalidad económica". Los factores que influyen incluyen el número de nodos participantes y la "calidad" de los nodos.
Para L2, actualmente hay tres estrategias viables:
En términos técnicos y de concepto, completamente "basado" en Ethereum, se puede considerar como "fragmentación de marca" o realizar innovaciones tecnológicas más audaces.
Como "servidor con andamiaje de blockchain", combinando tecnologías como la prueba de validez STARK, se obtiene la principal ventaja de estar en la cadena mientras se mantiene la eficiencia del servidor.
Solución de compromiso: establecer una cadena rápida compuesta por aproximadamente cien nodos, confiando en Ethereum para proporcionar interoperabilidad y garantías de seguridad adicionales.
Para diferentes escenarios de aplicación, un tiempo de bloque de 12 segundos puede ser suficiente. Para aplicaciones que requieren confirmaciones más rápidas, la arquitectura "época - ranura" parece ser la única solución. La clave radica en hasta qué punto podemos optimizar esta arquitectura, especialmente si podemos reducir el tiempo de ranura a 1 segundo, entonces la atractivo de la tercera estrategia se verá significativamente reducido.
Actualmente, estamos lejos de las respuestas finales a estas preguntas. La complejidad de los proponentes de bloques sigue siendo bastante incierta. Diseños innovadores como Orbit SSF brindan oportunidades para una exploración adicional. Cuantas más opciones tengamos, mejor podremos servir a los usuarios de L1 y L2, al 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
TrustMeBro
· hace11h
¡Apúrate, no te demores!
Ver originalesResponder0
GasFeeCryer
· hace15h
Ahora la tarifa de gas finalmente puede ser más barata.
Aceleración de la confirmación de transacciones de Ethereum: exploración desde la finalización de un solo slot hasta el mecanismo de preconfirmación
Optimización del tiempo de confirmación de transacciones de Ethereum: explorando una experiencia de usuario más rápida
Una de las claves de la experiencia del usuario en blockchain es la velocidad de confirmación de las transacciones. En los últimos años, Ethereum ha logrado avances significativos en este aspecto. Actualmente, las transacciones en L1 suelen confirmarse en 5-20 segundos, lo que es comparable a los pagos 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 tiempos de respuesta inferiores a un segundo. Este artículo discutirá varias soluciones viables para que Ethereum mejore la velocidad de confirmación de las transacciones.
Resumen de la técnica existente
finalización de un solo slot
El mecanismo de consenso Gasper actualmente adoptado por Ethereum se basa en una estructura de ranuras y épocas. Cada 12 segundos hay una ranura, y algunos validadores votan sobre la cabeza de la cadena. Después de 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, proporcionando una finalización con fuertes garantías económicas después de dos épocas (12.8 minutos).
Este método presenta dos problemas principales: alta complejidad y un tiempo de confirmación final de 12.8 minutos que es demasiado largo. La finalización de una sola ranura (SSF) reemplaza la arquitectura existente a través de un mecanismo similar a Tendermint, permitiendo que el bloque N se confirme de manera 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 desconectados.
El principal desafío de SSF es que cada 12 segundos se requiere que todos los stakers publiquen dos mensajes, lo que supone una carga considerable para la red. Aunque existen algunas soluciones de mitigación, como el reciente Orbit SSF propuesto, los usuarios aún deben esperar de 5 a 20 segundos para confirmar la transacción.
Preconfirmación de Rollup
Ethereum ha adoptado en los últimos años una ruta de desarrollo centrada en rollups, donde L1 proporciona funciones básicas como la disponibilidad de datos para su uso por los protocolos L2. Esto ha llevado a una separación de enfoques: L1 se centra en la resistencia a la censura, la fiabilidad y las mejoras de funciones centrales, mientras que L2 se dirige más directamente a las necesidades de los usuarios.
En teoría, la creación de una red de ordenadores descentralizados es responsabilidad de L2. Un pequeño grupo de validadores puede firmar bloques cada pocos cientos de milisegundos y apostar activos como garantía. Finalmente, los encabezados de estos bloques de L2 se publicarán en L1.
Sin embargo, parecería poco razonable exigir que todos los L2 implementen un ordenamiento descentralizado, lo que equivale a crear un L1 completamente nuevo. Por lo tanto, se ha propuesto la idea de que todos los L2 (incluso L1) compartan un mecanismo de preconfirmación: la preconfirmación básica.
Confirmación previa básica
La preconfirmación básica aprovecha la complejidad de los proponentes de Ethereum, incentivándolos a asumir la responsabilidad de proporcionar servicios de preconfirmación. 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. Si el proponente incumple su promesa, enfrentará penalizaciones.
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 esencialmente transacciones de L1, por lo que también pueden disfrutar del mismo servicio de preconfirmación.
Perspectivas Futuras
Supongamos que hemos implementado la finalización en un solo slot y utilizamos tecnología similar a Orbit para reducir el número de validadores por slot, al mismo tiempo que aumentamos la duración del slot a 16 segundos. Combinando la preconfirmación de rollup o la preconfirmación básica, podemos ofrecer a los usuarios una experiencia de confirmación más rápida. Esta arquitectura puede denominarse estructura "época-slot".
La aparición de esta estructura tiene razones profundas: el tiempo necesario para alcanzar un consenso general sobre algo suele ser menor que el tiempo necesario para alcanzar el máximo "finalidad económica". Los factores que influyen incluyen el número de nodos participantes y la "calidad" de los nodos.
Para L2, actualmente hay tres estrategias viables:
Para diferentes escenarios de aplicación, un tiempo de bloque de 12 segundos puede ser suficiente. Para aplicaciones que requieren confirmaciones más rápidas, la arquitectura "época - ranura" parece ser la única solución. La clave radica en hasta qué punto podemos optimizar esta arquitectura, especialmente si podemos reducir el tiempo de ranura a 1 segundo, entonces la atractivo de la tercera estrategia se verá significativamente reducido.
Actualmente, estamos lejos de las respuestas finales a estas preguntas. La complejidad de los proponentes de bloques sigue siendo bastante incierta. Diseños innovadores como Orbit SSF brindan oportunidades para una exploración adicional. Cuantas más opciones tengamos, mejor podremos servir a los usuarios de L1 y L2, al tiempo que simplificamos el trabajo de los desarrolladores de L2.