SEI introduce mecanismos que incluyen la ejecución asíncrona, el consenso de múltiples proponentes, el paralelismo de transacciones y la optimización del almacenamiento en la actualización de Giga. Este artículo está escrito por Pavel Paramonov, fundador de Hazeflow, y es compilado, compilado y contribuido por Felix, PANews. (Sinopsis: $SEI 70% en un solo mes!) Lanzamiento de la propuesta SIP-3: transición a EVM pura, con el objetivo de 100,000 transacciones por segundo) (Antecedentes agregados: MetaMask admitirá la "primera billetera MetaMask no relacionada con la cadena EVM" de la red Solana fuera de la zona de confort de Ethereum en mayo) Sei ha publicado un nuevo documento técnico que presenta la última actualización de Giga. A la mayoría de los lectores les resulta difícil leer 17 páginas de contenido técnico en profundidad. Por lo tanto, este artículo explicará en qué consiste esta actualización y cómo mejorar el rendimiento de la cadena de bloques a diferentes niveles. 1. Las ideas principales y los fundamentos de la generación de bloques giga para la ejecución asíncrona son los siguientes: "Si nuestra lista de transacciones está en orden y el estado inicial de la cadena de bloques 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 solo del estado inicial y del orden de las transacciones. Esto significa que el consenso solo necesita ponerse de acuerdo sobre el orden de las transacciones dentro del bloque, y cada nodo puede calcular el estado final de forma independiente. En este modelo, el consenso está separado de la ejecución, lo que permite que los bloques se ejecuten de forma asíncrona. Una vez finalizado el bloque, el nodo lo procesa y confirma su estado en los bloques siguientes. A continuación, el bloque se valida por consenso de estado para garantizar 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. Cuando un nodo realiza el cálculo de un bloque, también recibe otros bloques. Como resultado, los bloques se ejecutan en orden total (en lugar de en paralelo), mientras que el proceso de generación de bloques en sí ocurre en paralelo con el consenso. Sin embargo, para cualquier bloque dado, estos procesos son completamente asíncronos. Obviamente, el consenso y la ejecución de un mismo bloque al mismo tiempo parece imposible. Por lo tanto, cuando se ejecuta el bloque n, el nodo recibe el bloque n+1 para el siguiente paso. Si el consenso está sesgado (por ejemplo, un tercio de los nodos de la red actúan de forma maliciosa), la cadena se suspende, de forma similar al protocolo BFT estándar. La ejecución de una transacción fallida dentro de un bloque no invalida el bloque, sino que simplemente permanece en un estado fallido porque la generación y la ejecución de bloques están separadas, y el estado final del bloque actual se confirma en los bloques subsiguientes. 2 ¿Cómo se implementa el modelo multiproponente y qué es Autobahn? El protocolo de consenso en sí se llama "Autobahn" (como la autopista alemana sin límite de velocidad). Autobahn separa la disponibilidad de datos del orden de las transacciones, y hay un modelo interesante detrás. Al igual que los carriles de cualquier autopista, hay varios carriles, cada nodo con su propio paso. Los nodos utilizan estos canales para hacer propuestas sobre el orden de las transacciones. Una propuesta no es más que una colección ordenada de transacciones. Autobahn a veces realiza una operación de "corte de punta", donde se agregan múltiples propuestas para finalizar el orden de las transacciones. Como se mencionó anteriormente, cada validador tiene su propio canal para proponer una gran cantidad de transacciones. Cuando un nodo recibe una propuesta válida, envía un voto para confirmar que la propuesta ha sido recibida. Una vez que se recopila una propuesta para una votación, se forma una prueba de disponibilidad (PoA), lo que garantiza que los datos hayan sido recibidos por al menos un nodo honesto de la red. Los cortes de punta se producen en milisegundos y, finalmente, se "cortan" varias propuestas de Autobahn. Los proponentes tienen un incentivo para esperar a que se liberen los bloques y liberar bloques individuales cuando sea posible, pero el límite de tiempo de ejecución para cada bloque (similar al límite de gas) cambia ligeramente esta dinámica. Una propuesta en un canal suele ser equivalente a un bloque, lo que significa que cuando se produce un corte de punta, se cortan varios bloques al mismo tiempo. A partir de entonces, el líder de la ranura pasa el corte de punta a otros nodos para completar la clasificación. De hecho, el nodo está votando sobre un solo corte de punta al mismo tiempo que ya está preparando el siguiente corte de punta. Los nodos que pierden lotes se pueden obtener de forma asíncrona de los validadores enumerados en el PoA: esta es la esencia de la necesidad de disponibilidad de datos. En condiciones sincrónicas, si el líder es correcto, Autobahn completa la confirmación de la propuesta en dos rondas de comunicación. Si un líder falla, el mecanismo elige a un nuevo líder para mantener el programa en orden. La siguiente propuesta de tip-cut puede comenzar durante la fase de confirmación del tip-cut actual, lo que reduce la latencia porque la ejecución se produce en paralelo con la compilación. De hecho, todo el modelo es un modelo multi-proponente en el que muchos nodos pueden hacer propuestas para su ordenación de bloques al mismo tiempo. Cada validador propone sus propios bloques y recibe una prueba de que la red es propietaria de esos bloques (PoA), lo que ayuda a mejorar el rendimiento y la eficiencia general de la red. 3 Ejecución paralela y su aplicación Como se mencionó anteriormente, el proceso de ejecución de bloques ocurre en paralelo con el consenso, aunque los bloques en sí se ejecutan secuencialmente. Es posible que se pregunte si esto constituye una verdadera ejecución paralela. La respuesta es sí y no. Aunque los bloques se ejecutan secuencialmente, las transacciones dentro de los bloques se pueden ejecutar en paralelo. Si las transacciones no modifican (escriben) el mismo estado y el resultado de una transacción no afecta a otra, se pueden ejecutar en paralelo. En resumen, sus rutas de ejecución no deben depender unas de otras. Giga no tiene un mempool, y las transacciones son incluidas inmediatamente por el nodo. Giga asume que no hay conflictos entre la mayoría de las transacciones y las procesa simultáneamente en múltiples núcleos de procesador. Los cambios en cada transacción se almacenan temporalmente en un búfer privado y no se aplican inmediatamente a la cadena de bloques. Una vez finalizado el procesamiento, el sistema verifica si la transacción entra en conflicto con transacciones anteriores. Si hay un conflicto, la transacción se volverá a procesar. Si no hay conflictos, sus cambios se aplican a la cadena de bloques y se finalizan. También puede haber colisiones de alta frecuencia, en cuyo caso el sistema cambia a procesar una transacción a la vez para garantizar que la transacción pueda avanzar. En términos simples, la ejecución paralela distribuye las transacciones a través de múltiples núcleos, lo que permite que las transacciones que no entran en conflicto se ejecuten simultáneamente. 4. Problemas de almacenamiento y optimización Debido al alto volumen de transacciones, los datos deben ser seguros y fácilmente accesibles, por lo que deben almacenarse de una manera ligeramente diferente al almacenamiento tradicional de blockchain. Los gigas almacenan datos en un formato de clave-valor simple, una estructura relativamente plana que ayuda a reducir la necesidad de múltiples actualizaciones o comprobaciones cuando los datos cambian. Además, Giga utiliza el almacenamiento por niveles: los datos recientes se conservan en SSD (alta velocidad), mientras que los datos menos utilizados se migran a sistemas de almacenamiento más lentos y rentables. Si un nodo se bloquea, puede reproducir los registros para restaurar el estado correcto y aplicar las actualizaciones a RocksDB, una base de datos especializada, para organizar los datos. El sistema de almacenamiento utiliza un acumulador criptográfico que demuestra la exactitud de los datos sin necesidad de realizar cálculos pesados. Los acumuladores se actualizan en lotes, lo que permite a los validadores y nodos ligeros ponerse de acuerdo rápidamente sobre el estado actual de la cadena de bloques. 5. Conviértase en un bloque EVM L1 multiproponente...
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?
SEI introduce mecanismos que incluyen la ejecución asíncrona, el consenso de múltiples proponentes, el paralelismo de transacciones y la optimización del almacenamiento en la actualización de Giga. Este artículo está escrito por Pavel Paramonov, fundador de Hazeflow, y es compilado, compilado y contribuido por Felix, PANews. (Sinopsis: $SEI 70% en un solo mes!) Lanzamiento de la propuesta SIP-3: transición a EVM pura, con el objetivo de 100,000 transacciones por segundo) (Antecedentes agregados: MetaMask admitirá la "primera billetera MetaMask no relacionada con la cadena EVM" de la red Solana fuera de la zona de confort de Ethereum en mayo) Sei ha publicado un nuevo documento técnico que presenta la última actualización de Giga. A la mayoría de los lectores les resulta difícil leer 17 páginas de contenido técnico en profundidad. Por lo tanto, este artículo explicará en qué consiste esta actualización y cómo mejorar el rendimiento de la cadena de bloques a diferentes niveles. 1. Las ideas principales y los fundamentos de la generación de bloques giga para la ejecución asíncrona son los siguientes: "Si nuestra lista de transacciones está en orden y el estado inicial de la cadena de bloques 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 solo del estado inicial y del orden de las transacciones. Esto significa que el consenso solo necesita ponerse de acuerdo sobre el orden de las transacciones dentro del bloque, y cada nodo puede calcular el estado final de forma independiente. En este modelo, el consenso está separado de la ejecución, lo que permite que los bloques se ejecuten de forma asíncrona. Una vez finalizado el bloque, el nodo lo procesa y confirma su estado en los bloques siguientes. A continuación, el bloque se valida por consenso de estado para garantizar 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. Cuando un nodo realiza el cálculo de un bloque, también recibe otros bloques. Como resultado, los bloques se ejecutan en orden total (en lugar de en paralelo), mientras que el proceso de generación de bloques en sí ocurre en paralelo con el consenso. Sin embargo, para cualquier bloque dado, estos procesos son completamente asíncronos. Obviamente, el consenso y la ejecución de un mismo bloque al mismo tiempo parece imposible. Por lo tanto, cuando se ejecuta el bloque n, el nodo recibe el bloque n+1 para el siguiente paso. Si el consenso está sesgado (por ejemplo, un tercio de los nodos de la red actúan de forma maliciosa), la cadena se suspende, de forma similar al protocolo BFT estándar. La ejecución de una transacción fallida dentro de un bloque no invalida el bloque, sino que simplemente permanece en un estado fallido porque la generación y la ejecución de bloques están separadas, y el estado final del bloque actual se confirma en los bloques subsiguientes. 2 ¿Cómo se implementa el modelo multiproponente y qué es Autobahn? El protocolo de consenso en sí se llama "Autobahn" (como la autopista alemana sin límite de velocidad). Autobahn separa la disponibilidad de datos del orden de las transacciones, y hay un modelo interesante detrás. Al igual que los carriles de cualquier autopista, hay varios carriles, cada nodo con su propio paso. Los nodos utilizan estos canales para hacer propuestas sobre el orden de las transacciones. Una propuesta no es más que una colección ordenada de transacciones. Autobahn a veces realiza una operación de "corte de punta", donde se agregan múltiples propuestas para finalizar el orden de las transacciones. Como se mencionó anteriormente, cada validador tiene su propio canal para proponer una gran cantidad de transacciones. Cuando un nodo recibe una propuesta válida, envía un voto para confirmar que la propuesta ha sido recibida. Una vez que se recopila una propuesta para una votación, se forma una prueba de disponibilidad (PoA), lo que garantiza que los datos hayan sido recibidos por al menos un nodo honesto de la red. Los cortes de punta se producen en milisegundos y, finalmente, se "cortan" varias propuestas de Autobahn. Los proponentes tienen un incentivo para esperar a que se liberen los bloques y liberar bloques individuales cuando sea posible, pero el límite de tiempo de ejecución para cada bloque (similar al límite de gas) cambia ligeramente esta dinámica. Una propuesta en un canal suele ser equivalente a un bloque, lo que significa que cuando se produce un corte de punta, se cortan varios bloques al mismo tiempo. A partir de entonces, el líder de la ranura pasa el corte de punta a otros nodos para completar la clasificación. De hecho, el nodo está votando sobre un solo corte de punta al mismo tiempo que ya está preparando el siguiente corte de punta. Los nodos que pierden lotes se pueden obtener de forma asíncrona de los validadores enumerados en el PoA: esta es la esencia de la necesidad de disponibilidad de datos. En condiciones sincrónicas, si el líder es correcto, Autobahn completa la confirmación de la propuesta en dos rondas de comunicación. Si un líder falla, el mecanismo elige a un nuevo líder para mantener el programa en orden. La siguiente propuesta de tip-cut puede comenzar durante la fase de confirmación del tip-cut actual, lo que reduce la latencia porque la ejecución se produce en paralelo con la compilación. De hecho, todo el modelo es un modelo multi-proponente en el que muchos nodos pueden hacer propuestas para su ordenación de bloques al mismo tiempo. Cada validador propone sus propios bloques y recibe una prueba de que la red es propietaria de esos bloques (PoA), lo que ayuda a mejorar el rendimiento y la eficiencia general de la red. 3 Ejecución paralela y su aplicación Como se mencionó anteriormente, el proceso de ejecución de bloques ocurre en paralelo con el consenso, aunque los bloques en sí se ejecutan secuencialmente. Es posible que se pregunte si esto constituye una verdadera ejecución paralela. La respuesta es sí y no. Aunque los bloques se ejecutan secuencialmente, las transacciones dentro de los bloques se pueden ejecutar en paralelo. Si las transacciones no modifican (escriben) el mismo estado y el resultado de una transacción no afecta a otra, se pueden ejecutar en paralelo. En resumen, sus rutas de ejecución no deben depender unas de otras. Giga no tiene un mempool, y las transacciones son incluidas inmediatamente por el nodo. Giga asume que no hay conflictos entre la mayoría de las transacciones y las procesa simultáneamente en múltiples núcleos de procesador. Los cambios en cada transacción se almacenan temporalmente en un búfer privado y no se aplican inmediatamente a la cadena de bloques. Una vez finalizado el procesamiento, el sistema verifica si la transacción entra en conflicto con transacciones anteriores. Si hay un conflicto, la transacción se volverá a procesar. Si no hay conflictos, sus cambios se aplican a la cadena de bloques y se finalizan. También puede haber colisiones de alta frecuencia, en cuyo caso el sistema cambia a procesar una transacción a la vez para garantizar que la transacción pueda avanzar. En términos simples, la ejecución paralela distribuye las transacciones a través de múltiples núcleos, lo que permite que las transacciones que no entran en conflicto se ejecuten simultáneamente. 4. Problemas de almacenamiento y optimización Debido al alto volumen de transacciones, los datos deben ser seguros y fácilmente accesibles, por lo que deben almacenarse de una manera ligeramente diferente al almacenamiento tradicional de blockchain. Los gigas almacenan datos en un formato de clave-valor simple, una estructura relativamente plana que ayuda a reducir la necesidad de múltiples actualizaciones o comprobaciones cuando los datos cambian. Además, Giga utiliza el almacenamiento por niveles: los datos recientes se conservan en SSD (alta velocidad), mientras que los datos menos utilizados se migran a sistemas de almacenamiento más lentos y rentables. Si un nodo se bloquea, puede reproducir los registros para restaurar el estado correcto y aplicar las actualizaciones a RocksDB, una base de datos especializada, para organizar los datos. El sistema de almacenamiento utiliza un acumulador criptográfico que demuestra la exactitud de los datos sin necesidad de realizar cálculos pesados. Los acumuladores se actualizan en lotes, lo que permite a los validadores y nodos ligeros ponerse de acuerdo rápidamente sobre el estado actual de la cadena de bloques. 5. Conviértase en un bloque EVM L1 multiproponente...