Interpretación del nuevo White Paper de Sei: ¿Qué innovaciones tecnológicas introduce la actualización Giga?

Autor: Pavel Paramonov, fundador de Hazeflow

Compilado por: Felix, PANews

Sei ha publicado un nuevo libro blanco, en el que se presenta la última actualización Giga. La mayoría de los lectores consideran que el contenido técnico profundo de 17 páginas es difícil de leer. Por lo tanto, este artículo explicará el contenido de esta actualización y cómo mejorar el rendimiento de la blockchain en diferentes niveles.

1. Generación de bloques sobre la ejecución asíncrona

La idea principal y la base de Giga son las siguientes:

"Si nuestra lista de transacciones está ordenada y el estado inicial de la blockchain es consistente, y todos los nodos honestos procesan estas transacciones en el mismo orden, entonces los nodos alcanzarán el mismo estado final."

En este caso, el resultado depende únicamente del estado inicial y del orden de las transacciones. Esto significa que el consenso solo necesita llegar a un acuerdo sobre el orden de las transacciones dentro del bloque, y cada nodo puede calcular el estado final de forma independiente.

• En este modelo, se separa el consenso de la ejecución, lo que permite la ejecución asíncrona de bloques.
• Una vez que el bloque se ha finalizado, los nodos lo procesarán y enviarán su estado en bloques posteriores.
• Luego, verifica el bloque a través del consenso de estado para asegurarse de que todos los nodos han calculado el estado final correcto.

Un detalle importante aquí es que la ejecución y el consenso (generación) se llevan a cabo en paralelo. Los nodos, al ejecutar el cálculo de un bloque, también recibirán otros bloques.

Por lo tanto, los bloques se ejecutan en un orden total (y no en paralelo), mientras que el proceso de generación de bloques en sí ocurre de manera paralela a la consensuación. Sin embargo, para cualquier bloque dado, estos procesos son completamente asíncronos.

Es evidente que parece imposible lograr consenso y ejecución sobre el mismo bloque al mismo tiempo. Por lo tanto, al ejecutar el bloque n, el nodo recibe el bloque n+1 para el siguiente paso.

Si hay una desviación en el consenso (por ejemplo, si un tercio de los nodos en la red actúan de manera maliciosa), la cadena se detendrá, lo que es similar a los protocolos BFT estándar.

Las transacciones fallidas en un bloque no invalidan el bloque, simplemente permanecen en estado de fallo, ya que la generación y ejecución del bloque están separadas, y el estado final del bloque actual se presentará en bloques posteriores.

2. ¿Cómo se implementa el modelo de múltiples proponentes y qué es Autobahn ?

El protocolo de consenso en sí se llama "Autobahn" (igual que la autopista alemana sin límite de velocidad). Autobahn separa la disponibilidad de datos y el orden de las transacciones, respaldado por un modelo interesante.

Al igual que en cualquier carril de una autopista, hay múltiples carriles, y cada nodo tiene su propio canal. Los nodos utilizan estos canales para presentar propuestas sobre el orden de las transacciones. Una propuesta es simplemente un conjunto ordenado de transacciones.

Autobahn a veces ejecuta la operación "tipcut", es decir, agrega múltiples propuestas para determinar finalmente el orden de las transacciones.

• Como se mencionó anteriormente, cada validador tiene su propio canal para proponer lotes de transacciones.
• Cuando un nodo recibe una propuesta válida, enviará un voto para confirmar que la propuesta ha sido recibida.
• Una vez que se recojan las propuestas y se voten, se generará una prueba de disponibilidad (PoA), asegurando que los datos han sido recibidos por al menos un nodo honesto en la red.
• El tiempo de Tipcut se mide en milisegundos, y las múltiples propuestas finalmente provenientes de Autobahn serán "cortadas".

El proponente tiene el incentivo de esperar a publicar bloques y, si es posible, publicar un solo bloque, pero el límite de tiempo de ejecución de cada bloque (similar al límite de Gas) alterará ligeramente esta dinámica.

Una propuesta en un canal suele equivaler a un bloque, lo que significa que cuando ocurre el Tipcut, varios bloques se cortan simultáneamente.

Después de esto, el líder de ese slot enviará el Tipcut a otros nodos para completar el orden. Los nodos, de hecho, ya están preparando el siguiente Tipcut mientras votan sobre un Tipcut individual.

Los nodos que se perdieron en la ronda pueden obtener datos de forma asíncrona de los validadores listados en PoA: esta es la razón esencial por la que se necesita la disponibilidad de datos.

Bajo condiciones de sincronización, si el líder es correcto, Autobahn completará la confirmación de la propuesta en dos rondas de comunicación. Si el líder falla, el mecanismo elegirá un nuevo líder para mantener el proceso.

La próxima propuesta de tip-cut puede comenzar en la fase de提交 del tip-cut actual, reduciendo así la latencia, ya que la ejecución se lleva a cabo en paralelo con la generación.

En realidad, todo el modelo es un modelo de múltiples proponentes, donde muchos nodos pueden proponer simultáneamente el orden de sus bloques. Cada validador propone su propio bloque y recibe pruebas de que la red posee esos bloques (PoA), lo que ayuda a aumentar el rendimiento y la eficiencia general de la red.

3. Ejecución en paralelo y sus casos de aplicación

Como se mencionó anteriormente, el proceso de ejecución de bloques y el consenso ocurren de forma paralela, aunque el bloque en sí se ejecuta realmente en orden. Puede que se pregunte si esto constituye una verdadera ejecución en paralelo.

La respuesta es tanto afirmativa como negativa.

Aunque los bloques se ejecutan en orden, las transacciones dentro de un bloque pueden ejecutarse en paralelo. Si las transacciones no modifican (escriben) el mismo estado y el resultado de una transacción no afecta a la otra, entonces pueden ejecutarse en paralelo.

En pocas palabras, sus rutas de ejecución no deberían depender entre sí. Giga no tiene un pool de memoria, las transacciones son incluidas inmediatamente por los nodos.

• Giga asume que no hay conflictos entre la mayoría de las transacciones y procesa estas transacciones simultáneamente en múltiples núcleos de procesador.
• Los cambios de cada transacción se almacenarán temporalmente en un búfer privado y no se aplicarán de inmediato a la cadena de bloques.
• Una vez que se complete el procesamiento, el sistema verificará si la transacción entra en conflicto con transacciones anteriores.
• Si hay un conflicto, la transacción se reprocesará. Si no hay conflictos, sus cambios se aplicarán a la blockchain y se confirmarán.

También puede haber situaciones de alta frecuencia de conflictos, en cuyo caso el sistema cambiará a procesar una transacción a la vez para asegurar que las transacciones puedan avanzar.

En pocas palabras, la ejecución en paralelo asigna transacciones a múltiples núcleos, de modo que las transacciones sin conflictos puedan ejecutarse simultáneamente.

4. Problemas de almacenamiento y optimización

Debido al gran volumen de transacciones, los datos necesitan ser tanto seguros como de fácil acceso, por lo que su forma de almacenamiento debe ser ligeramente diferente a la del almacenamiento tradicional en blockchain. Giga almacena los datos en un formato de clave-valor (key-value) simple, que es una estructura relativamente plana que ayuda a reducir la cantidad de actualizaciones o verificaciones necesarias cuando se modifican los datos.

Además, Giga también utiliza un enfoque de almacenamiento jerárquico: los datos recientes se mantienen en SSD (alta velocidad), mientras que los datos menos utilizados se trasladan a un sistema de almacenamiento más lento y rentable.

Si un nodo falla, puede reproducir los registros para restaurar el estado correcto y aplicar actualizaciones a RocksDB (una base de datos especializada) para organizar los datos.

Este sistema de almacenamiento utiliza un acumulador criptográfico (Cryptographic Accumulator), que puede demostrar la corrección de los datos sin necesidad de realizar cálculos pesados. El acumulador se actualiza de manera por lotes, lo que permite a los validadores y nodos ligeros llegar rápidamente a un consenso sobre el estado actual de la blockchain.

5. ¿Qué significa convertirse en un multi-proponente en una blockchain EVM L1?

La infraestructura de L1 se puede mejorar de diversas maneras, y las diferentes L1 se enfrentan a una variedad de desafíos técnicos, que van desde aspectos económicos como MEV hasta aspectos técnicos como la gestión estatal.

Como la primera cadena L1 que soporta múltiples proponentes, es bastante desafiante, especialmente para L1 basado en EVM, ya que el diseño de EVM no tiene como objetivo soportar un sistema de múltiples proponentes.

Sin embargo, Sei está intentando diferentes enfoques para conservar EVM y muchas de las herramientas que los desarrolladores suelen usar.

La ejecución de transacciones en paralelo, el consenso alcanzado durante el proceso de ejecución y la operación paralela de múltiples proponentes ayudan a mejorar el rendimiento, pudiendo aumentar el rendimiento de ejecución en aproximadamente 50 veces. Sin embargo, estas mejoras también pueden enfrentar algunos de los riesgos mencionados anteriormente.

Esta es la segunda actualización importante de Sei, anteriormente Sei se transformó de la cadena Cosmos a la cadena EVM, y ahora Sei ha lanzado un cliente de ejecución optimizado para velocidad.

El desarrollo posterior y el efecto de seguimiento de estas medidas de optimización merecen atención.

Lecturas relacionadas: Explorando el rendimiento, la conformidad y la interoperabilidad de la blockchain Sei