Discusión sobre soluciones prácticas para mejorar la velocidad de confirmación de transacciones en Ethereum
Ethereum ha logrado avances significativos en la velocidad de confirmación de transacciones en los últimos años. Actualmente, las transacciones enviadas por los usuarios en L1 generalmente se confirman en 5-20 segundos, lo que es comparable a la experiencia de pagar con tarjeta de crédito. Sin embargo, aún es muy necesario mejorar la experiencia del usuario, ya que algunas aplicaciones incluso requieren reducir la latencia a unos pocos cientos de milisegundos. Este artículo explorará algunas opciones viables para mejorar el tiempo de confirmación de transacciones en Ethereum.
Resumen de la tecnología y enfoques existentes
finalización de un solo slot
El mecanismo de consenso Gasper actualmente utilizado por Ethereum emplea una arquitectura de un solo slot y Epoch. Cada slot dura 12 segundos, y un grupo de validadores vota sobre la cabeza 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 fuerte garantía económica de lo que se denomina finalización.
Sin embargo, este método presenta dos problemas principales: alta complejidad y un tiempo de confirmación final de 12.8 minutos que es demasiado largo. Para resolver estos problemas, la Finalidad de Un Solo Slot (Single Slot Finality, SSF) propuso un mecanismo similar al consenso de Tendermint, que completa la confirmación final del bloque actual antes de generar el siguiente bloque.
El principal desafío de SSF es que cada apostador necesita publicar dos mensajes cada 12 segundos, lo que representa una gran carga para la red. Aunque hay algunas ideas innovadoras, como la propuesta Orbit SSF, que intentan aliviar este problema, los usuarios aún deben esperar de 5 a 20 segundos para confirmar la transacción.
Preconfirmación de Rollup
Con el desarrollo centrado en rollups de Ethereum, los protocolos L2 (como rollups, validiums y plasmas) pueden ofrecer a los usuarios servicios a gran escala con la misma seguridad que Ethereum. Esto ha llevado a una división de responsabilidades dentro del ecosistema de Ethereum: L1 se centra en la resistencia a la censura, la fiabilidad y el mantenimiento y mejora de las funciones básicas, mientras que L2 se dedica a satisfacer 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, utilizando sus activos en staking como garantía. Los encabezados de estos bloques L2 finalmente se publicarán en L1.
Sin embargo, parece poco realista exigir que todos los L2 establezcan una red de ordenamiento descentralizada, lo que equivale a pedir que el rollup complete un trabajo casi idéntico al de crear un nuevo L1. Por lo tanto, se ha propuesto que todos los L2 (así como el L1) compartan un mecanismo de preconfirmación dentro del alcance de Ethereum: la preconfirmación básica.
Confirmación previa básica
El método de preconfirmación básica asume que los proponentes de Ethereum son participantes altamente complejos. Este método aprovecha su experiencia incentivando a estos proponentes a aceptar la responsabilidad de proporcionar servicios de preconfirmación.
Su idea central es crear un protocolo estandarizado, 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 de la transacción. Si el proponente incumple su promesa, enfrentará sanciones.
Este mecanismo no solo se aplica a las transacciones de L1, para los rollups "basados en" Ethereum, todos los bloques de L2 son esencialmente transacciones de L1, por lo tanto, el mismo mecanismo también puede proporcionar servicios de preconfirmación para cualquier L2.
Direcciones de desarrollo futuro
Supongamos que hemos logrado la finalización en un solo slot y utilizamos una tecnología similar a Orbit para reducir el número de validadores por slot, manteniendo al mismo tiempo un grado suficiente de descentralización para reducir el umbral de participación. La duración del slot podría aumentar a 16 segundos, y luego podríamos aprovechar la preconfirmación de rollup o la preconfirmación básica para ofrecer a los usuarios una confirmación más rápida. Así, al final, obtenemos una arquitectura de epoch-slot.
Esta arquitectura es difícil de evitar principalmente porque el tiempo necesario para alcanzar un acuerdo general sobre un asunto es mucho menor que el tiempo necesario para alcanzar el máximo "finalidad económica". Las principales razones incluyen:
"Consenso aproximado" solo requiere la participación de unos pocos nodos, mientras que la finalización económica requiere la participación de la mayoría de los nodos.
Una vez que el número de nodos supera un cierto tamaño, el tiempo necesario para recopilar firmas aumentará significativamente.
Por lo tanto, la arquitectura de epoch-and-slot parece ser la dirección de desarrollo correcta, pero diferentes formas de implementación pueden tener efectos distintos. Vale la pena explorar más establecer un punto de separación de atención más fuerte entre los dos mecanismos, en lugar de acoplarlos tan estrechamente como en Gasper.
Estrategia de desarrollo de L2
Para L2, actualmente hay tres estrategias de desarrollo razonables:
En términos técnicos y conceptuales, "basado en" Ethereum, optimizando sus características técnicas fundamentales y valores.
Convertirse en "servidor con andamiaje de blockchain", aprovechando al máximo la eficiencia de los servidores centralizados, mientras se asegura la seguridad y descentralización mediante la incorporación de elementos de blockchain.
Solución de compromiso: establecer una cadena rápida con aproximadamente cien nodos, al mismo tiempo que se utiliza Ethereum para proporcionar interoperabilidad y seguridad adicionales.
Para diferentes escenarios de aplicación, estas tres estrategias tienen sus ventajas. Una pregunta clave es hasta qué punto podemos optimizar en la arquitectura de epoch-and-slot nativa de Ethereum. Si podemos reducir el tiempo de slot a 1 segundo, entonces el espacio de la tercera estrategia podría reducirse drásticamente.
Actualmente, estamos a cierta distancia de las respuestas finales a estas preguntas. La complejidad de los proponentes de bloques, el potencial de nuevos diseños como Orbit SSF y otros factores presentan una gran incertidumbre. Continuar explorando y perfeccionando estas soluciones ayudará a ofrecer una mejor experiencia a los usuarios de L1 y L2, al mismo tiempo que simplifica 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.
15 me gusta
Recompensa
15
4
Republicar
Compartir
Comentar
0/400
NotAFinancialAdvice
· hace4h
tps aún necesita acelerarse
Ver originalesResponder0
BugBountyHunter
· hace4h
La velocidad de transacción aún no es lo suficientemente rápida.
Ver originalesResponder0
AirdropF5Bro
· hace4h
Sin mercado, presiona F5 para el Airdrop.
Ver originalesResponder0
pvt_key_collector
· hace4h
¿De qué sirve la velocidad? Primero hay que sobrevivir y luego hablar.
Discusión sobre las soluciones de aceleración de Ethereum: finalización en una sola ranura, preconfirmación de Rollup y preconfirmación básica
Discusión sobre soluciones prácticas para mejorar la velocidad de confirmación de transacciones en Ethereum
Ethereum ha logrado avances significativos en la velocidad de confirmación de transacciones en los últimos años. Actualmente, las transacciones enviadas por los usuarios en L1 generalmente se confirman en 5-20 segundos, lo que es comparable a la experiencia de pagar con tarjeta de crédito. Sin embargo, aún es muy necesario mejorar la experiencia del usuario, ya que algunas aplicaciones incluso requieren reducir la latencia a unos pocos cientos de milisegundos. Este artículo explorará algunas opciones viables para mejorar el tiempo de confirmación de transacciones en Ethereum.
Resumen de la tecnología y enfoques existentes
finalización de un solo slot
El mecanismo de consenso Gasper actualmente utilizado por Ethereum emplea una arquitectura de un solo slot y Epoch. Cada slot dura 12 segundos, y un grupo de validadores vota sobre la cabeza 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 fuerte garantía económica de lo que se denomina finalización.
Sin embargo, este método presenta dos problemas principales: alta complejidad y un tiempo de confirmación final de 12.8 minutos que es demasiado largo. Para resolver estos problemas, la Finalidad de Un Solo Slot (Single Slot Finality, SSF) propuso un mecanismo similar al consenso de Tendermint, que completa la confirmación final del bloque actual antes de generar el siguiente bloque.
El principal desafío de SSF es que cada apostador necesita publicar dos mensajes cada 12 segundos, lo que representa una gran carga para la red. Aunque hay algunas ideas innovadoras, como la propuesta Orbit SSF, que intentan aliviar este problema, los usuarios aún deben esperar de 5 a 20 segundos para confirmar la transacción.
Preconfirmación de Rollup
Con el desarrollo centrado en rollups de Ethereum, los protocolos L2 (como rollups, validiums y plasmas) pueden ofrecer a los usuarios servicios a gran escala con la misma seguridad que Ethereum. Esto ha llevado a una división de responsabilidades dentro del ecosistema de Ethereum: L1 se centra en la resistencia a la censura, la fiabilidad y el mantenimiento y mejora de las funciones básicas, mientras que L2 se dedica a satisfacer 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, utilizando sus activos en staking como garantía. Los encabezados de estos bloques L2 finalmente se publicarán en L1.
Sin embargo, parece poco realista exigir que todos los L2 establezcan una red de ordenamiento descentralizada, lo que equivale a pedir que el rollup complete un trabajo casi idéntico al de crear un nuevo L1. Por lo tanto, se ha propuesto que todos los L2 (así como el L1) compartan un mecanismo de preconfirmación dentro del alcance de Ethereum: la preconfirmación básica.
Confirmación previa básica
El método de preconfirmación básica asume que los proponentes de Ethereum son participantes altamente complejos. Este método aprovecha su experiencia incentivando a estos proponentes a aceptar la responsabilidad de proporcionar servicios de preconfirmación.
Su idea central es crear un protocolo estandarizado, 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 de la transacción. Si el proponente incumple su promesa, enfrentará sanciones.
Este mecanismo no solo se aplica a las transacciones de L1, para los rollups "basados en" Ethereum, todos los bloques de L2 son esencialmente transacciones de L1, por lo tanto, el mismo mecanismo también puede proporcionar servicios de preconfirmación para cualquier L2.
Direcciones de desarrollo futuro
Supongamos que hemos logrado la finalización en un solo slot y utilizamos una tecnología similar a Orbit para reducir el número de validadores por slot, manteniendo al mismo tiempo un grado suficiente de descentralización para reducir el umbral de participación. La duración del slot podría aumentar a 16 segundos, y luego podríamos aprovechar la preconfirmación de rollup o la preconfirmación básica para ofrecer a los usuarios una confirmación más rápida. Así, al final, obtenemos una arquitectura de epoch-slot.
Esta arquitectura es difícil de evitar principalmente porque el tiempo necesario para alcanzar un acuerdo general sobre un asunto es mucho menor que el tiempo necesario para alcanzar el máximo "finalidad económica". Las principales razones incluyen:
Por lo tanto, la arquitectura de epoch-and-slot parece ser la dirección de desarrollo correcta, pero diferentes formas de implementación pueden tener efectos distintos. Vale la pena explorar más establecer un punto de separación de atención más fuerte entre los dos mecanismos, en lugar de acoplarlos tan estrechamente como en Gasper.
Estrategia de desarrollo de L2
Para L2, actualmente hay tres estrategias de desarrollo razonables:
Para diferentes escenarios de aplicación, estas tres estrategias tienen sus ventajas. Una pregunta clave es hasta qué punto podemos optimizar en la arquitectura de epoch-and-slot nativa de Ethereum. Si podemos reducir el tiempo de slot a 1 segundo, entonces el espacio de la tercera estrategia podría reducirse drásticamente.
Actualmente, estamos a cierta distancia de las respuestas finales a estas preguntas. La complejidad de los proponentes de bloques, el potencial de nuevos diseños como Orbit SSF y otros factores presentan una gran incertidumbre. Continuar explorando y perfeccionando estas soluciones ayudará a ofrecer una mejor experiencia a los usuarios de L1 y L2, al mismo tiempo que simplifica el trabajo de los desarrolladores de L2.