Discusión sobre la optimización de la velocidad de confirmación de transacciones de Ethereum
En la experiencia del usuario de blockchain, el tiempo de confirmación de transacciones es un factor clave. Ethereum ha reducido el tiempo de confirmación de transacciones a entre 5 y 20 segundos en los últimos años mediante medidas como EIP-1559 y la transición a PoS, lo que es comparable a los pagos con tarjeta de crédito. Sin embargo, seguir reduciendo el tiempo de confirmación sigue siendo valioso, ya que algunas aplicaciones incluso requieren una latencia en el subsegundo. Este artículo explorará las soluciones viables para optimizar aún más el tiempo de confirmación de transacciones en Ethereum.
Resumen de la tecnología existente
finalización de un solo slot
Actualmente, Ethereum utiliza el mecanismo de consenso Gasper, con un slot cada 12 segundos, y 32 slots conforman una Epoch. Los validadores votan sobre la cabeza de la cadena, y se alcanza la finalización después de dos Epochs. Este mecanismo presenta problemas como alta complejidad y un largo tiempo de finalización (12.8 minutos).
La finalización de un solo slot ( SSF ) es similar al consenso de Tendermint, donde cada bloque puede lograr la finalización antes de la generación del siguiente bloque. El principal desafío radica en la alta carga de la red, ya que cada validador necesita publicar dos mensajes cada 12 segundos. Aunque hay algunas soluciones de optimización como Orbit SSF, los usuarios aún deben esperar de 5 a 20 segundos para confirmar la transacción.
Preconfirmación de Rollup
Ethereum adopta una ruta de escalado centrada en rollup, las soluciones L2 necesitan ofrecer a los usuarios confirmaciones más rápidas. Teóricamente, L2 puede establecer su propia red de "ordenadores descentralizados", firmando bloques cada pocos cientos de milisegundos. Pero esto exige que L2 realice un trabajo casi idéntico al de crear un nuevo L1, lo que lleva a un avance real más lento.
Confirmación previa básica
Este esquema utiliza la complejidad de los proponentes de bloques de Ethereum para incentivarlos a proporcionar servicios de pre-confirmación. Los usuarios pueden pagar una tarifa adicional para obtener la garantía instantánea de que su transacción será incluida en el próximo bloque. Si el proponente incumple su promesa, será penalizado. Este mecanismo puede proporcionar pre-confirmación para L1 y L2 basados en Ethereum.
Posibles soluciones de arquitectura
Supongamos que se ha logrado la finalización de un solo slot y se ha utilizado una tecnología similar a Orbit para reducir el número de validadores de firma por slot, al mismo tiempo que se utilizan rollups para preconfirmaciones o preconfirmaciones básicas para proporcionar una confirmación más rápida. Finalmente, obtenemos una arquitectura de epoch-slot:
Época: 16 segundos, garantizada por el mecanismo de finalización de un solo slot
Slot: aproximadamente 2 segundos, alcanzado por un subconjunto de nodos especializados para lograr un consenso cercano.
Esta arquitectura puede equilibrar las demandas de descentralización, finalización y confirmación rápida. L2 puede adoptar las siguientes estrategias:
Totalmente basado en Ethereum, optimizando las propiedades y valores de la capa base
Similar a "servidores con andamiaje de blockchain", obteniendo los beneficios de la cadena mientras se mantiene la eficiencia del servidor.
Solución de compromiso: una cadena rápida con aproximadamente 100 nodos, que ofrece seguridad adicional proporcionada por Ethereum
Para diferentes escenarios de aplicación, se puede elegir diferentes mecanismos de slot:
Arquitectura de epoch-slot nativa de Ethereum
Preconfirmación del servidor
Confirmación previa del comité
Si la arquitectura nativa de Ethereum puede reducir el tiempo de slot a 1 segundo, la importancia de la tercera opción disminuirá. Pero los datos fuera de la cadena L2( como plasmas y validiums) aún requieren la segunda opción.
Actualmente, estamos a una distancia considerable de la solución final. Las cuestiones clave incluyen la complejidad de los proponentes de bloques, el potencial de nuevos diseños como Orbit SSF, entre otros. Explorar más opciones ayuda a mejorar la experiencia del usuario en L1 y L2, y simplifica el trabajo de desarrollo en 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.
18 me gusta
Recompensa
18
4
Compartir
Comentar
0/400
LazyDevMiner
· 08-05 12:26
Sentir que se demora uno o dos segundos, ¿a quién le importa?
Ver originalesResponder0
ValidatorVibes
· 08-05 12:18
he estado despierto toda la noche pensando... ssf podría ser genial pero ¿qué pasa con las recompensas de los validadores?
Ver originalesResponder0
AirdropHunterWang
· 08-05 12:17
Apresúrate, hazlo rápido, lento como un montón.
Ver originalesResponder0
OnchainGossiper
· 08-05 12:08
¿No se trata de cambiar el mecanismo de consenso? ¿Por qué tanta prisa?
Optimización de la velocidad de confirmación de transacciones de Ethereum: explorando soluciones de latencia de subsegundo
Discusión sobre la optimización de la velocidad de confirmación de transacciones de Ethereum
En la experiencia del usuario de blockchain, el tiempo de confirmación de transacciones es un factor clave. Ethereum ha reducido el tiempo de confirmación de transacciones a entre 5 y 20 segundos en los últimos años mediante medidas como EIP-1559 y la transición a PoS, lo que es comparable a los pagos con tarjeta de crédito. Sin embargo, seguir reduciendo el tiempo de confirmación sigue siendo valioso, ya que algunas aplicaciones incluso requieren una latencia en el subsegundo. Este artículo explorará las soluciones viables para optimizar aún más el tiempo de confirmación de transacciones en Ethereum.
Resumen de la tecnología existente
finalización de un solo slot
Actualmente, Ethereum utiliza el mecanismo de consenso Gasper, con un slot cada 12 segundos, y 32 slots conforman una Epoch. Los validadores votan sobre la cabeza de la cadena, y se alcanza la finalización después de dos Epochs. Este mecanismo presenta problemas como alta complejidad y un largo tiempo de finalización (12.8 minutos).
La finalización de un solo slot ( SSF ) es similar al consenso de Tendermint, donde cada bloque puede lograr la finalización antes de la generación del siguiente bloque. El principal desafío radica en la alta carga de la red, ya que cada validador necesita publicar dos mensajes cada 12 segundos. Aunque hay algunas soluciones de optimización como Orbit SSF, los usuarios aún deben esperar de 5 a 20 segundos para confirmar la transacción.
Preconfirmación de Rollup
Ethereum adopta una ruta de escalado centrada en rollup, las soluciones L2 necesitan ofrecer a los usuarios confirmaciones más rápidas. Teóricamente, L2 puede establecer su propia red de "ordenadores descentralizados", firmando bloques cada pocos cientos de milisegundos. Pero esto exige que L2 realice un trabajo casi idéntico al de crear un nuevo L1, lo que lleva a un avance real más lento.
Confirmación previa básica
Este esquema utiliza la complejidad de los proponentes de bloques de Ethereum para incentivarlos a proporcionar servicios de pre-confirmación. Los usuarios pueden pagar una tarifa adicional para obtener la garantía instantánea de que su transacción será incluida en el próximo bloque. Si el proponente incumple su promesa, será penalizado. Este mecanismo puede proporcionar pre-confirmación para L1 y L2 basados en Ethereum.
Posibles soluciones de arquitectura
Supongamos que se ha logrado la finalización de un solo slot y se ha utilizado una tecnología similar a Orbit para reducir el número de validadores de firma por slot, al mismo tiempo que se utilizan rollups para preconfirmaciones o preconfirmaciones básicas para proporcionar una confirmación más rápida. Finalmente, obtenemos una arquitectura de epoch-slot:
Esta arquitectura puede equilibrar las demandas de descentralización, finalización y confirmación rápida. L2 puede adoptar las siguientes estrategias:
Para diferentes escenarios de aplicación, se puede elegir diferentes mecanismos de slot:
Si la arquitectura nativa de Ethereum puede reducir el tiempo de slot a 1 segundo, la importancia de la tercera opción disminuirá. Pero los datos fuera de la cadena L2( como plasmas y validiums) aún requieren la segunda opción.
Actualmente, estamos a una distancia considerable de la solución final. Las cuestiones clave incluyen la complejidad de los proponentes de bloques, el potencial de nuevos diseños como Orbit SSF, entre otros. Explorar más opciones ayuda a mejorar la experiencia del usuario en L1 y L2, y simplifica el trabajo de desarrollo en L2.