Discusión sobre la optimización del tiempo de confirmación de transacciones en Ethereum: comparación entre SSF, Rollup y el esquema de preconfirmación básico.
Propuesta para optimizar el tiempo de confirmación de transacciones en Ethereum
Un aspecto importante de la experiencia del usuario en blockchain es el rápido tiempo de confirmación de transacciones. En los últimos años, Ethereum ha logrado avances significativos en este aspecto. Gracias a EIP-1559 y al tiempo de bloque estable después de la transición a PoS, las transacciones enviadas por los usuarios en L1 generalmente pueden confirmarse en 5-20 segundos, lo que es prácticamente equivalente a la experiencia de pago con tarjeta de crédito. Sin embargo, sigue siendo valioso mejorar aún más la experiencia del usuario, ya que ciertas aplicaciones incluso requieren una latencia de menos de un segundo. Este artículo explorará algunas opciones viables para que Ethereum mejore el tiempo de confirmación de transacciones.
Resumen de la tecnología existente
finalización de un solo slot
Actualmente, el consenso Gasper de Ethereum utiliza una arquitectura de un solo slot y Epoch. Cada 12 segundos hay un slot, donde algunos validadores votan sobre la cabeza de la cadena, y todos los validadores tienen la oportunidad de votar una vez en 32 slots. Estos votos se reinterpretan como mensajes similares al algoritmo de consenso PBFT, proporcionando una finalización con fuertes garantías económicas después de dos Epochs.
En los últimos años, la gente ha estado cada vez más insatisfecha con este método, principalmente por dos razones: primero, la alta complejidad, ya que existen numerosos problemas de interacción entre el mecanismo de votación de ranura a ranura y el mecanismo de finalización de Epoch a Epoch; segundo, el tiempo de finalización de 12.8 minutos es demasiado largo.
La finalización de un solo slot (SSF) reemplaza esta arquitectura a través de un mecanismo similar a Tendermint, permitiendo que el bloque N sea finalizado antes de que se genere el 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 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 apostador debe publicar dos mensajes cada 12 segundos, lo que genera una gran carga en la cadena. Aunque hay algunas soluciones de mitigación, como la reciente propuesta Orbit SSF, esto no ha cambiado el hecho de que los usuarios deben esperar entre 5 y 20 segundos.
Preconfirmación de Rollup
Ethereum ha seguido en los últimos años una hoja de ruta centrada en rollups, diseñando L1 como una capa base que soporta la disponibilidad de datos y otras funciones para su uso por los protocolos L2. Esto ha creado una separación de puntos de atención dentro del ecosistema: L1 se centra en la resistencia a la censura, la fiabilidad y la mejora de funciones centrales, mientras que L2 sirve más directamente a las necesidades de los usuarios.
Teóricamente, la creación de una red de ordenadores descentralizados es responsabilidad de L2. Un pequeño grupo de validadores podría firmar bloques cada pocos cientos de milisegundos y publicar los encabezados de estos bloques en L1. Sin embargo, exigir que todos los L2 realicen un ordenamiento descentralizado parece un poco injusto, ya que equivale a crear un nuevo L1.
Confirmación previa básica
La hipótesis de preconfirmación básica supone que los proponentes de Ethereum son participantes de MEV altamente complejos. Este enfoque aprovecha su complejidad incentivando a estos proponentes a aceptar la responsabilidad de proporcionar servicios de preconfirmación.
Su idea básica es crear un protocolo estandarizado, donde los usuarios pueden pagar una tarifa adicional para obtener una garantía instantánea de que la transacción será incluida en el próximo bloque, así como una declaración sobre el resultado de la ejecución. Si el proponente incumple su promesa, será penalizado.
Este mecanismo no solo es aplicable a transacciones L1, sino que también puede proporcionar preconfirmaciones para rollups "basados en".
Perspectivas futuras
Supongamos que se ha implementado la finalización de un solo espacio y se utiliza una tecnología similar a Orbit para reducir el número de validadores por espacio. La duración del espacio podría aumentar a 16 segundos, y luego se utilizaría la preconfirmación de rollup o la preconfirmación básica para proporcionar a los usuarios una confirmación más rápida. Finalmente, podríamos obtener una arquitectura de epoch-slot.
La arquitectura de epoch-slot parece inevitable, ya que el tiempo necesario para alcanzar un consenso aproximado sobre algo es menor que el necesario para alcanzar un acuerdo de "finalidad económica" en su máximo grado. Las razones incluyen la cantidad de nodos y la "calidad" de los nodos.
En la actual Ethereum, el slot de 12 segundos se divide en tres sub-slots. Si se reduce drásticamente el número de validadores, podría reducirse a dos sub-slots y utilizar un tiempo de slot de 8 segundos. Si se logra un acuerdo aproximado mediante un subconjunto de nodos especializados, podría acortarse aún más a aproximadamente 2 segundos.
Sugerencias de estrategia L2
Actualmente hay tres estrategias razonables para L2:
Técnica y espiritualmente "basado" en Ethereum, optimizando sus atributos técnicos y valores fundamentales.
Convertirse en "servidor con andamiaje de blockchain", aprovechando al máximo la eficiencia del servidor mientras se obtienen los beneficios de la cadena.
Método de compromiso: una cadena rápida con aproximadamente cien nodos, Ethereum ofrece 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 epoch-slot. La cuestión clave es qué tan bien puede funcionar la arquitectura epoch-slot nativa de Ethereum, lo que afectará el significado de otras soluciones.
Actualmente estamos lejos de las respuestas finales a estas preguntas. La complejidad de los proponentes de bloques sigue siendo bastante incierta. Diseños novedosos como Orbit SSF merecen ser explorados más a fondo. Cuantas más opciones tengamos, mejor podremos servir a 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.
22 me gusta
Recompensa
22
8
Republicar
Compartir
Comentar
0/400
ShibaMillionairen't
· 07-21 14:39
Comercio de criptomonedas es como soñar despierto, me muero de risa. Espera, si el tiempo de confirmación se acorta, ¿no sería imposible tomar a la gente por tonta?
Ver originalesResponder0
DefiPlaybook
· 07-20 15:55
Es realmente increíble, o quizás he estado trabajando un poco más de tiempo.
Ver originalesResponder0
GasFeeCryer
· 07-20 01:55
La confirmación en la L1 de la vieja escuela es tan lenta que da ganas de llorar, ahora apenas se puede usar.
Ver originalesResponder0
CryptoTherapist
· 07-20 01:48
la ansiedad de trading es real familia... meditemos sobre esos tiempos de confirmación y liberemos la mentalidad de fomo tbh
Ver originalesResponder0
MissedTheBoat
· 07-20 01:47
Ni siquiera una tarjeta de crédito es tan lenta... Apúrate.
Ver originalesResponder0
AllInAlice
· 07-20 01:46
Confirmar que está a punto de despegar, 5 segundos ya son increíbles, ¿de acuerdo?
Ver originalesResponder0
AirdropHunterZhang
· 07-20 01:28
Quiero aconsejarles que no se obsesionen con el gas, si baja, ¡todo dentro!
Ver originalesResponder0
FUD_Vaccinated
· 07-20 01:26
Me estoy riendo. ¿Aún te preocupa esta cosa? ¿No es mejor L2?
Discusión sobre la optimización del tiempo de confirmación de transacciones en Ethereum: comparación entre SSF, Rollup y el esquema de preconfirmación básico.
Propuesta para optimizar el tiempo de confirmación de transacciones en Ethereum
Un aspecto importante de la experiencia del usuario en blockchain es el rápido tiempo de confirmación de transacciones. En los últimos años, Ethereum ha logrado avances significativos en este aspecto. Gracias a EIP-1559 y al tiempo de bloque estable después de la transición a PoS, las transacciones enviadas por los usuarios en L1 generalmente pueden confirmarse en 5-20 segundos, lo que es prácticamente equivalente a la experiencia de pago con tarjeta de crédito. Sin embargo, sigue siendo valioso mejorar aún más la experiencia del usuario, ya que ciertas aplicaciones incluso requieren una latencia de menos de un segundo. Este artículo explorará algunas opciones viables para que Ethereum mejore el tiempo de confirmación de transacciones.
Resumen de la tecnología existente
finalización de un solo slot
Actualmente, el consenso Gasper de Ethereum utiliza una arquitectura de un solo slot y Epoch. Cada 12 segundos hay un slot, donde algunos validadores votan sobre la cabeza de la cadena, y todos los validadores tienen la oportunidad de votar una vez en 32 slots. Estos votos se reinterpretan como mensajes similares al algoritmo de consenso PBFT, proporcionando una finalización con fuertes garantías económicas después de dos Epochs.
En los últimos años, la gente ha estado cada vez más insatisfecha con este método, principalmente por dos razones: primero, la alta complejidad, ya que existen numerosos problemas de interacción entre el mecanismo de votación de ranura a ranura y el mecanismo de finalización de Epoch a Epoch; segundo, el tiempo de finalización de 12.8 minutos es demasiado largo.
La finalización de un solo slot (SSF) reemplaza esta arquitectura a través de un mecanismo similar a Tendermint, permitiendo que el bloque N sea finalizado antes de que se genere el 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 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 apostador debe publicar dos mensajes cada 12 segundos, lo que genera una gran carga en la cadena. Aunque hay algunas soluciones de mitigación, como la reciente propuesta Orbit SSF, esto no ha cambiado el hecho de que los usuarios deben esperar entre 5 y 20 segundos.
Preconfirmación de Rollup
Ethereum ha seguido en los últimos años una hoja de ruta centrada en rollups, diseñando L1 como una capa base que soporta la disponibilidad de datos y otras funciones para su uso por los protocolos L2. Esto ha creado una separación de puntos de atención dentro del ecosistema: L1 se centra en la resistencia a la censura, la fiabilidad y la mejora de funciones centrales, mientras que L2 sirve más directamente a las necesidades de los usuarios.
Teóricamente, la creación de una red de ordenadores descentralizados es responsabilidad de L2. Un pequeño grupo de validadores podría firmar bloques cada pocos cientos de milisegundos y publicar los encabezados de estos bloques en L1. Sin embargo, exigir que todos los L2 realicen un ordenamiento descentralizado parece un poco injusto, ya que equivale a crear un nuevo L1.
Confirmación previa básica
La hipótesis de preconfirmación básica supone que los proponentes de Ethereum son participantes de MEV altamente complejos. Este enfoque aprovecha su complejidad incentivando a estos proponentes a aceptar la responsabilidad de proporcionar servicios de preconfirmación.
Su idea básica es crear un protocolo estandarizado, donde los usuarios pueden pagar una tarifa adicional para obtener una garantía instantánea de que la transacción será incluida en el próximo bloque, así como una declaración sobre el resultado de la ejecución. Si el proponente incumple su promesa, será penalizado.
Este mecanismo no solo es aplicable a transacciones L1, sino que también puede proporcionar preconfirmaciones para rollups "basados en".
Perspectivas futuras
Supongamos que se ha implementado la finalización de un solo espacio y se utiliza una tecnología similar a Orbit para reducir el número de validadores por espacio. La duración del espacio podría aumentar a 16 segundos, y luego se utilizaría la preconfirmación de rollup o la preconfirmación básica para proporcionar a los usuarios una confirmación más rápida. Finalmente, podríamos obtener una arquitectura de epoch-slot.
La arquitectura de epoch-slot parece inevitable, ya que el tiempo necesario para alcanzar un consenso aproximado sobre algo es menor que el necesario para alcanzar un acuerdo de "finalidad económica" en su máximo grado. Las razones incluyen la cantidad de nodos y la "calidad" de los nodos.
En la actual Ethereum, el slot de 12 segundos se divide en tres sub-slots. Si se reduce drásticamente el número de validadores, podría reducirse a dos sub-slots y utilizar un tiempo de slot de 8 segundos. Si se logra un acuerdo aproximado mediante un subconjunto de nodos especializados, podría acortarse aún más a aproximadamente 2 segundos.
Sugerencias 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 epoch-slot. La cuestión clave es qué tan bien puede funcionar la arquitectura epoch-slot nativa de Ethereum, lo que afectará el significado de otras soluciones.
Actualmente estamos lejos de las respuestas finales a estas preguntas. La complejidad de los proponentes de bloques sigue siendo bastante incierta. Diseños novedosos como Orbit SSF merecen ser explorados más a fondo. Cuantas más opciones tengamos, mejor podremos servir a los usuarios de L1 y L2, y simplificar el trabajo de los desarrolladores de L2.