Explorando soluciones para optimizar el tiempo de confirmación de transacciones de Ethereum: finalización de un solo slot y técnicas de preconfirmación
Discusión sobre propuestas para mejorar el tiempo de confirmación de transacciones en la Cadena de bloques
En el campo de la cadena de bloques, un tiempo de confirmación de transacciones rápido es uno de los factores clave para mejorar la experiencia del usuario. Ethereum ha logrado avances significativos en los últimos cinco años, y ahora las transacciones enviadas por los usuarios en L1 generalmente pueden ser confirmadas en 5-20 segundos, lo que es comparable a la experiencia de pago con tarjeta de crédito. Sin embargo, reducir aún más el tiempo de confirmación sigue teniendo su valor, especialmente para aquellos escenarios de aplicación que requieren una latencia de subsegundo. Este artículo explorará algunas opciones viables para mejorar el tiempo de confirmación de transacciones en Ethereum.
Resumen de la tecnología y las ideas existentes
finalización de un solo bloque
Actualmente, el mecanismo de consenso Gasper de Ethereum utiliza una arquitectura de un solo slot (Slot) y Epoch. Cada 12 segundos hay un slot, y un número limitado de validadores vota sobre el encabezado de la cadena; en 32 slots (6.4 minutos), todos los validadores tienen la oportunidad de votar una vez. Estos votos se interpretan posteriormente como mensajes similares a los del algoritmo de consenso PBFT, y después de dos Epochs (12.8 minutos), se proporciona una garantía económica fuerte conocida como finalización.
Sin embargo, este enfoque presenta dos problemas principales: complejidad y un tiempo de confirmación final más largo. Para abordar estos problemas, se propuso el concepto de Finalidad de un Solo Slot (Single Slot Finality, SSF), que reemplaza la arquitectura existente mediante un mecanismo de consenso similar al de Tendermint, permitiendo que el bloque N sea finalmente confirmado antes de que se genere el bloque N+1.
El principal desafío de la finalización de un solo bloque es que requiere que cada validador de Ethereum publique dos mensajes cada 12 segundos, lo que impone una gran carga a la red. Aunque hay algunas soluciones innovadoras como Orbit SSF que intentan aliviar este problema, los usuarios todavía tienen que esperar de 5 a 20 segundos para confirmar la transacción.
Preconfirmación de Rollup
Con el desarrollo centrado en rollup de Ethereum, soluciones L2 como rollups, validiums y plasmas pueden ofrecer a los usuarios un nivel de seguridad equivalente al de Ethereum a una escala mayor. Esta arquitectura permite que Ethereum L1 se concentre en funciones centrales como la resistencia a la censura, la fiabilidad y la estabilidad, mientras que L2 se dedica a atender directamente las necesidades de los usuarios a través de diferentes tecnologías y culturas.
Teóricamente, L2 puede crear su propia red de "ordenadores descentralizados", donde un pequeño grupo de validadores firma bloques cada pocos cientos de milisegundos y utiliza sus activos apostados como garantía. Sin embargo, este enfoque enfrenta el riesgo de que los validadores puedan actuar de mala fe, como firmar bloques en conflicto. A pesar de que ya hemos visto aplicaciones prácticas de versiones centralizadas, L2 ha avanzado lentamente en el desarrollo de redes de ordenamiento descentralizadas.
Confirmación previa básica
Para resolver el problema mencionado, se propone el concepto de preconfirmaciones básicas (Based preconfirmations). Este método asume que los proponentes de Ethereum son participantes complejos altamente sensibles al MEV, aprovechando su especialización al incentivar a estos proponentes a aceptar la responsabilidad de proporcionar servicios de preconfirmación.
La preconfirmación básica ha creado un protocolo estandarizado, donde los usuarios pueden obtener una garantía instantánea de que la transacción será incluida en el siguiente Bloquear pagando un costo adicional. Si el proponente incumple su promesa, enfrentará una penalización. Este mecanismo no solo se aplica a las transacciones de L1, sino que también puede proporcionar servicios de preconfirmación para L2 basados en Ethereum.
Dirección de desarrollo futura
Supongamos que hemos implementado la finalización de un solo bloque y adoptamos una tecnología similar a Orbit para reducir el número de validadores por bloque, manteniendo al mismo tiempo un grado suficiente de descentralización. La duración del bloque podría aumentar a 16 segundos, y luego podríamos utilizar la pre-confirmación de rollup o la pre-confirmación básica para ofrecer a los usuarios una confirmación más rápida. Esta arquitectura es esencialmente una estructura de época-bloque.
Esta estructura es difícil de evitar porque el tiempo necesario para alcanzar un consenso general sobre un asunto es mucho menor que el tiempo requerido para lograr el mayor grado de "finalidad económica". Esta diferencia proviene principalmente de la cantidad y calidad de los nodos participantes.
Para L2, actualmente hay tres estrategias razonables:
En términos técnicos y de filosofía, "basado en" Ethereum, optimizando sus propiedades y valores fundamentales.
Convertirse en "servidor con andamiaje de cadena de bloques", aprovechando al máximo la eficiencia centralizada mientras se conserva la ventaja clave de la descentralización.
Solución de compromiso: establecer una cadena rápida compuesta por alrededor de cien nodos, mientras se aprovecha la interoperabilidad y seguridad adicionales que ofrece Ethereum.
La clave del futuro radica en hasta qué punto podemos mejorar la arquitectura de epoch-and-slot nativa de Ethereum. Si podemos reducir el tiempo de slot a alrededor de 1 segundo, la necesidad de una tercera estrategia se reducirá considerablemente.
Actualmente, aún estamos lejos de las respuestas finales a estas preguntas. Existen incertidumbres en la complejidad de los proponentes de bloques y el potencial de nuevos diseños como Orbit SSF. Continuar explorando y optimizando estas soluciones ayudará a proporcionar una mejor experiencia para 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.
11 me gusta
Recompensa
11
4
Compartir
Comentar
0/400
MemeCurator
· hace4h
La mejora de la eficiencia aún no es lo suficientemente rápida
Explorando soluciones para optimizar el tiempo de confirmación de transacciones de Ethereum: finalización de un solo slot y técnicas de preconfirmación
Discusión sobre propuestas para mejorar el tiempo de confirmación de transacciones en la Cadena de bloques
En el campo de la cadena de bloques, un tiempo de confirmación de transacciones rápido es uno de los factores clave para mejorar la experiencia del usuario. Ethereum ha logrado avances significativos en los últimos cinco años, y ahora las transacciones enviadas por los usuarios en L1 generalmente pueden ser confirmadas en 5-20 segundos, lo que es comparable a la experiencia de pago con tarjeta de crédito. Sin embargo, reducir aún más el tiempo de confirmación sigue teniendo su valor, especialmente para aquellos escenarios de aplicación que requieren una latencia de subsegundo. Este artículo explorará algunas opciones viables para mejorar el tiempo de confirmación de transacciones en Ethereum.
Resumen de la tecnología y las ideas existentes
finalización de un solo bloque
Actualmente, el mecanismo de consenso Gasper de Ethereum utiliza una arquitectura de un solo slot (Slot) y Epoch. Cada 12 segundos hay un slot, y un número limitado de validadores vota sobre el encabezado de la cadena; en 32 slots (6.4 minutos), todos los validadores tienen la oportunidad de votar una vez. Estos votos se interpretan posteriormente como mensajes similares a los del algoritmo de consenso PBFT, y después de dos Epochs (12.8 minutos), se proporciona una garantía económica fuerte conocida como finalización.
Sin embargo, este enfoque presenta dos problemas principales: complejidad y un tiempo de confirmación final más largo. Para abordar estos problemas, se propuso el concepto de Finalidad de un Solo Slot (Single Slot Finality, SSF), que reemplaza la arquitectura existente mediante un mecanismo de consenso similar al de Tendermint, permitiendo que el bloque N sea finalmente confirmado antes de que se genere el bloque N+1.
El principal desafío de la finalización de un solo bloque es que requiere que cada validador de Ethereum publique dos mensajes cada 12 segundos, lo que impone una gran carga a la red. Aunque hay algunas soluciones innovadoras como Orbit SSF que intentan aliviar este problema, los usuarios todavía tienen que esperar de 5 a 20 segundos para confirmar la transacción.
Preconfirmación de Rollup
Con el desarrollo centrado en rollup de Ethereum, soluciones L2 como rollups, validiums y plasmas pueden ofrecer a los usuarios un nivel de seguridad equivalente al de Ethereum a una escala mayor. Esta arquitectura permite que Ethereum L1 se concentre en funciones centrales como la resistencia a la censura, la fiabilidad y la estabilidad, mientras que L2 se dedica a atender directamente las necesidades de los usuarios a través de diferentes tecnologías y culturas.
Teóricamente, L2 puede crear su propia red de "ordenadores descentralizados", donde un pequeño grupo de validadores firma bloques cada pocos cientos de milisegundos y utiliza sus activos apostados como garantía. Sin embargo, este enfoque enfrenta el riesgo de que los validadores puedan actuar de mala fe, como firmar bloques en conflicto. A pesar de que ya hemos visto aplicaciones prácticas de versiones centralizadas, L2 ha avanzado lentamente en el desarrollo de redes de ordenamiento descentralizadas.
Confirmación previa básica
Para resolver el problema mencionado, se propone el concepto de preconfirmaciones básicas (Based preconfirmations). Este método asume que los proponentes de Ethereum son participantes complejos altamente sensibles al MEV, aprovechando su especialización al incentivar a estos proponentes a aceptar la responsabilidad de proporcionar servicios de preconfirmación.
La preconfirmación básica ha creado un protocolo estandarizado, donde los usuarios pueden obtener una garantía instantánea de que la transacción será incluida en el siguiente Bloquear pagando un costo adicional. Si el proponente incumple su promesa, enfrentará una penalización. Este mecanismo no solo se aplica a las transacciones de L1, sino que también puede proporcionar servicios de preconfirmación para L2 basados en Ethereum.
Dirección de desarrollo futura
Supongamos que hemos implementado la finalización de un solo bloque y adoptamos una tecnología similar a Orbit para reducir el número de validadores por bloque, manteniendo al mismo tiempo un grado suficiente de descentralización. La duración del bloque podría aumentar a 16 segundos, y luego podríamos utilizar la pre-confirmación de rollup o la pre-confirmación básica para ofrecer a los usuarios una confirmación más rápida. Esta arquitectura es esencialmente una estructura de época-bloque.
Esta estructura es difícil de evitar porque el tiempo necesario para alcanzar un consenso general sobre un asunto es mucho menor que el tiempo requerido para lograr el mayor grado de "finalidad económica". Esta diferencia proviene principalmente de la cantidad y calidad de los nodos participantes.
Para L2, actualmente hay tres estrategias razonables:
La clave del futuro radica en hasta qué punto podemos mejorar la arquitectura de epoch-and-slot nativa de Ethereum. Si podemos reducir el tiempo de slot a alrededor de 1 segundo, la necesidad de una tercera estrategia se reducirá considerablemente.
Actualmente, aún estamos lejos de las respuestas finales a estas preguntas. Existen incertidumbres en la complejidad de los proponentes de bloques y el potencial de nuevos diseños como Orbit SSF. Continuar explorando y optimizando estas soluciones ayudará a proporcionar una mejor experiencia para los usuarios de L1 y L2, y simplificará el trabajo de los desarrolladores de L2.