Escrito por: Pavel Paramonov, fundador de Hazeflow
Compilado por: PANews
Sei ha publicado un nuevo libro blanco que 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 cadena de bloques en diferentes niveles.
Sobre la generación de bloques mediante ejecución asíncrona
La idea principal y la base de Giga son las siguientes:
"Si nuestras listas de transacciones son ordenadas 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 manera independiente.
En este modelo, se separa el consenso de la ejecución, lo que permite que los bloques se ejecuten de manera asíncrona.
Una vez que el bloque está finalizado, los nodos lo procesarán y enviarán su estado en bloques posteriores.
Luego, se verifica el bloque a través del consenso de estado para asegurarse de que todos los nodos hayan 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 los cálculos 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 ocurre realmente en paralelo con el consenso. Sin embargo, para cualquier bloque dado, estos procesos son completamente asíncronos.
Es evidente que parece imposible alcanzar consenso y ejecutar el mismo bloque al mismo tiempo. Por lo tanto, al ejecutar el bloque n, el nodo recibirá 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 pausará, lo que es similar al protocolo BFT estándar.
Las transacciones fallidas en un bloque no invalidan el bloque; simplemente mantienen un estado de fallo, ya que la generación del bloque y su ejecución están separadas, y el estado final del bloque actual se presentará en bloques posteriores.
¿Cómo se implementa el modelo de múltiples proponentes y qué es Autobahn?
El protocolo de consenso en sí se llama «Autobahn» (al igual que la autopista alemana sin límite de velocidad). Autobahn separa la disponibilidad de datos y el orden de las transacciones, detrás del cual hay un modelo interesante.
Al igual que en cualquier carril de una autopista, existen múltiples carriles, y cada nodo tiene su propio canal. Los nodos utilizan estos canales para hacer 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, envía un voto para confirmar que la propuesta ha sido recibida.
Después de que la propuesta se recopile y se vote, se formará una prueba de disponibilidad (PoA) que asegura 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 que provienen de Autobahn serán "cut.".
Los proponentes tienen 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) modifica 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, el líder de ese slot enviará el Tipcut a otros nodos para completar el ordenamiento. Los nodos, de hecho, están preparando el siguiente Tipcut mientras votan sobre un único Tipcut.
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 envío del tip-cut actual, reduciendo así la demora, 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 la ordenación de sus bloques. Cada validador propone su propio bloque y recibe pruebas (PoA) de que la red posee esos bloques, lo que ayuda a mejorar el rendimiento y la eficiencia general de la red.
Ejecución en paralelo y sus casos aplicables
Como se mencionó anteriormente, el proceso de ejecución de bloques y el consenso ocurren en paralelo, aunque el bloque en sí se ejecuta en secuencia. 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 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 de inmediato por los nodos.
Giga asume que no hay conflictos entre la mayoría de las transacciones y procesa estas transacciones simultáneamente en varios núcleos de procesador.
Los cambios de cada transacción se almacenan temporalmente en un búfer privado y no se aplican inmediatamente a la cadena de bloques.
Después de completar el proceso, el sistema verificará si la transacción entra en conflicto con transacciones anteriores.
Si hay un conflicto, la transacción se volverá a procesar. Si no hay conflicto, sus cambios se aplicarán a la cadena de bloques y se confirmarán de manera definitiva.
También puede haber situaciones de conflictos de alta frecuencia, 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, permitiendo que aquellas transacciones que no tienen conflictos se ejecuten al mismo tiempo.
Problemas de almacenamiento y optimización
Debido al alto volumen de transacciones, los datos deben estar seguros y ser fácilmente accesibles, por lo que deben almacenarse de manera ligeramente diferente al almacenamiento tradicional de blockchain. Giga almacena los datos en un formato de clave-valor simple, que es una estructura relativamente plana que ayuda a reducir la necesidad de múltiples actualizaciones o comprobaciones cuando los datos cambian.
Además, Giga 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 se cae, puede reproducir los registros para recuperar el estado correcto y aplicar las 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 probar la corrección de los datos sin necesidad de realizar cálculos pesados. El acumulador se actualiza de manera por lotes, lo que permite que los validadores y los nodos ligeros lleguen rápidamente a un consenso sobre el estado actual de la cadena de bloques.
¿Qué significa convertirse en una blockchain EVM L1 con múltiples propuestas?
La infraestructura de L1 puede mejorar de muchas maneras, y diferentes L1 enfrentan varios desafíos técnicos, desde problemas económicos como el MEV hasta problemas técnicos como la gestión de estados.
Como la primera cadena L1 que soporta múltiples proponentes, es bastante desafiante, especialmente para L1 EVM, ya que el diseño de EVM no fue concebido para 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 están acostumbrados a usar.
La ejecución paralela de transacciones, el consenso alcanzado durante el proceso de ejecución y las operaciones paralelas de múltiples proponentes ayudan a mejorar el rendimiento, con un aumento del rendimiento de ejecución de aproximadamente 50 veces. Sin embargo, estas mejoras también pueden enfrentar algunos de los riesgos mencionados anteriormente.
Esta es la segunda gran actualización 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 los efectos de seguimiento de estas medidas de optimización merecen atención.
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Interpretación del nuevo White Paper de Sei: ¿qué innovaciones tecnológicas introduce la actualización Giga?
Escrito por: Pavel Paramonov, fundador de Hazeflow
Compilado por: PANews
Sei ha publicado un nuevo libro blanco que 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 cadena de bloques en diferentes niveles.
Sobre la generación de bloques mediante ejecución asíncrona
La idea principal y la base de Giga son las siguientes:
"Si nuestras listas de transacciones son ordenadas 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 manera independiente.
En este modelo, se separa el consenso de la ejecución, lo que permite que los bloques se ejecuten de manera asíncrona.
Una vez que el bloque está finalizado, los nodos lo procesarán y enviarán su estado en bloques posteriores.
Luego, se verifica el bloque a través del consenso de estado para asegurarse de que todos los nodos hayan 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 los cálculos 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 ocurre realmente en paralelo con el consenso. Sin embargo, para cualquier bloque dado, estos procesos son completamente asíncronos.
Es evidente que parece imposible alcanzar consenso y ejecutar el mismo bloque al mismo tiempo. Por lo tanto, al ejecutar el bloque n, el nodo recibirá 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 pausará, lo que es similar al protocolo BFT estándar.
Las transacciones fallidas en un bloque no invalidan el bloque; simplemente mantienen un estado de fallo, ya que la generación del bloque y su ejecución están separadas, y el estado final del bloque actual se presentará en bloques posteriores.
¿Cómo se implementa el modelo de múltiples proponentes y qué es Autobahn?
El protocolo de consenso en sí se llama «Autobahn» (al igual que la autopista alemana sin límite de velocidad). Autobahn separa la disponibilidad de datos y el orden de las transacciones, detrás del cual hay un modelo interesante.
Al igual que en cualquier carril de una autopista, existen múltiples carriles, y cada nodo tiene su propio canal. Los nodos utilizan estos canales para hacer 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, envía un voto para confirmar que la propuesta ha sido recibida.
Después de que la propuesta se recopile y se vote, se formará una prueba de disponibilidad (PoA) que asegura 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 que provienen de Autobahn serán "cut.".
Los proponentes tienen 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) modifica 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, el líder de ese slot enviará el Tipcut a otros nodos para completar el ordenamiento. Los nodos, de hecho, están preparando el siguiente Tipcut mientras votan sobre un único Tipcut.
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 envío del tip-cut actual, reduciendo así la demora, 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 la ordenación de sus bloques. Cada validador propone su propio bloque y recibe pruebas (PoA) de que la red posee esos bloques, lo que ayuda a mejorar el rendimiento y la eficiencia general de la red.
Ejecución en paralelo y sus casos aplicables
Como se mencionó anteriormente, el proceso de ejecución de bloques y el consenso ocurren en paralelo, aunque el bloque en sí se ejecuta en secuencia. 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 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 de inmediato por los nodos.
Giga asume que no hay conflictos entre la mayoría de las transacciones y procesa estas transacciones simultáneamente en varios núcleos de procesador.
Los cambios de cada transacción se almacenan temporalmente en un búfer privado y no se aplican inmediatamente a la cadena de bloques.
Después de completar el proceso, el sistema verificará si la transacción entra en conflicto con transacciones anteriores.
Si hay un conflicto, la transacción se volverá a procesar. Si no hay conflicto, sus cambios se aplicarán a la cadena de bloques y se confirmarán de manera definitiva.
También puede haber situaciones de conflictos de alta frecuencia, 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, permitiendo que aquellas transacciones que no tienen conflictos se ejecuten al mismo tiempo.
Problemas de almacenamiento y optimización
Debido al alto volumen de transacciones, los datos deben estar seguros y ser fácilmente accesibles, por lo que deben almacenarse de manera ligeramente diferente al almacenamiento tradicional de blockchain. Giga almacena los datos en un formato de clave-valor simple, que es una estructura relativamente plana que ayuda a reducir la necesidad de múltiples actualizaciones o comprobaciones cuando los datos cambian.
Además, Giga 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 se cae, puede reproducir los registros para recuperar el estado correcto y aplicar las 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 probar la corrección de los datos sin necesidad de realizar cálculos pesados. El acumulador se actualiza de manera por lotes, lo que permite que los validadores y los nodos ligeros lleguen rápidamente a un consenso sobre el estado actual de la cadena de bloques.
¿Qué significa convertirse en una blockchain EVM L1 con múltiples propuestas?
La infraestructura de L1 puede mejorar de muchas maneras, y diferentes L1 enfrentan varios desafíos técnicos, desde problemas económicos como el MEV hasta problemas técnicos como la gestión de estados.
Como la primera cadena L1 que soporta múltiples proponentes, es bastante desafiante, especialmente para L1 EVM, ya que el diseño de EVM no fue concebido para 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 están acostumbrados a usar.
La ejecución paralela de transacciones, el consenso alcanzado durante el proceso de ejecución y las operaciones paralelas de múltiples proponentes ayudan a mejorar el rendimiento, con un aumento del rendimiento de ejecución de aproximadamente 50 veces. Sin embargo, estas mejoras también pueden enfrentar algunos de los riesgos mencionados anteriormente.
Esta es la segunda gran actualización 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 los efectos de seguimiento de estas medidas de optimización merecen atención.