Autor del original: Haotian

Lecturas relacionadas:

Epoch and slot: una ruta indicada por Vitalik para proporcionar tiempos de confirmación de transacción más rápidos en Ethereum

¿Cómo entender la reflexión de @VitalikButerin sobre los métodos de confirmación de transacciones en Ethereum? Debido a que el tiempo de confirmación de transacciones en la mainnet de 5-20 s ya se acerca a la velocidad de consumo de tarjetas de crédito, parece ser suficiente desde la percepción del usuario. Sin embargo, en comparación con el tiempo de confirmación a nivel de milisegundos en layer 2, existirá cierto riesgo de seguridad en la diferencia de confirmación de transacciones entre la mainnet y layer 2, por lo que ¿optimizar el tiempo de confirmación de transacciones en la mainnet es más una consideración para adaptarse a la gran estrategia de desarrollo de layer 2?

1. El mecanismo de consenso Gasper actual de Ethereum adopta los conceptos básicos de Slot (intervalo de tiempo) y Epoch (período de tiempo). Cada Slot dura 12 s y se selecciona un grupo de Validadores para votar sobre el estado de la cadena actual. Cada 32 Slots, es decir, 6.4 min, forman un Epoch, momento en el cual la mayoría de los validadores habrán completado su votación. La finalidad de las transacciones generalmente requiere dos Epochs, es decir, 12.8 minutos, lo que significa que una transacción no se puede revertir hasta 12.8 minutos después de haber sido iniciada.

2. Vitalik piensa que el Gasper mecanismo de consenso actual tarda demasiado tiempo y propone el método de mejora de Single-slot finality, que garantiza que cada bloque se confirme antes de que se genere el siguiente bloque, acelerando así el tiempo de confirmación de la finalidad. Sin embargo, la confirmación de la finalidad y la confirmación de la transacción son dos cosas diferentes, lo que no está relacionado con la percepción del usuario de la confirmación de la transacción de 5-20 s. Pero si se aplica a la red de capa 2, el problema será grande.

3. Debido a que el tiempo que los usuarios de la capa 2 tardan en enviar y confirmar transacciones es más corto, no solo es más rápido que el tiempo percibido por los usuarios de 5-20 s, sino que también puede llegar a ser del orden de milisegundos. Esto se debe al mecanismo de confirmación previa a la transacción utilizado en la capa 2 en general. Sin embargo, si el tiempo de confirmación final de las transacciones en la mainnet de la capa 1 es demasiado largo, teóricamente habrá un riesgo de desfase temporal en la capa 2: por ejemplo, los usuarios pueden confirmar rápidamente y realizar acciones adicionales en L1, pero pueden sufrir pérdidas de fondos debido al retraso en la confirmación del estado de L1; además, dado que la capa 2 en sí misma conlleva ciertos riesgos de centralización, un desfase temporal más largo puede dar lugar a riesgos desconocidos de alteración centralizada.

4）Por lo tanto, en mi opinión, la nueva propuesta de Vitalik para optimizar los tiempos de confirmación de las transacciones en la red principal de Ethereum, en cierto modo, es parte de una gran estrategia para adaptarse al avance conjunto de los sistemas de capa 2 y capa 1. Aunque hay personas en el mercado que critican la capa 2, esta parece haberse convertido en una dirección sólida e indispensable en el proceso de desarrollo de Ethereum.

Obviamente, Ethereum definitivamente será una estrategia "en capas" en el futuro, confiando en la capa 1 para centrarse en la seguridad y la descentralización, y confiando en la capa 2 para proporcionar un entorno de liquidación interactivo estable y confiable será la tendencia general. La propuesta de Vitalik para acelerar la confirmación de transacciones es esencialmente reducir la fricción de capas entre la capa 1 y la capa 2, y brindar a los usuarios una experiencia de capa 2 con un mejor entorno de interacción front-end y una base de liquidación back-end más segura.