Interpretação do novo White Paper da Sei: Quais inovações tecnológicas são introduzidas com a atualização Giga?

Autor: Pavel Paramonov, fundador da Hazeflow

Compilado por: Felix, PANews

A Sei publicou um novo white paper, no qual apresenta a mais recente atualização Giga. A maioria dos leitores considera que o conteúdo técnico profundo de 17 páginas é difícil de ler. Portanto, este artigo explicará o que há de novo nesta atualização e como melhorar o desempenho da blockchain em diferentes níveis.

1. Sobre a geração de blocos em execução assíncrona

A principal ideia e base do Giga é a seguinte:

"Se a nossa lista de transações for ordenada e o estado inicial da blockchain for consistente, e todos os nós honestos processarem essas transações na mesma ordem, os nós alcançarão o mesmo estado final."

Neste caso, o resultado depende apenas do estado inicial e da ordem das transações. Isso significa que o consenso só precisa ser alcançado sobre a ordem das transações dentro do bloco, e cada nó pode calcular o estado final de forma independente.

• Neste modelo, a consensus e a execução são separadas, permitindo a execução assíncrona de blocos.
• Uma vez que o bloco é finalmente confirmado, os nós processarão e submeterão seu estado nos blocos subsequentes.
• Em seguida, valide o bloco através do consenso de estado para garantir que todos os nós calcularam o estado final correto.

Um detalhe importante aqui é que a execução e o consenso (geração) ocorrem em paralelo. Os nós, ao executar o cálculo de um bloco, também recebem outros blocos.

Portanto, os blocos são realmente executados em ordem total (e não em paralelo), enquanto o próprio processo de geração de blocos ocorre de fato em paralelo com o consenso. No entanto, para qualquer bloco dado, esses processos são completamente assíncronos.

É evidente que parece ser impossível realizar consenso e execução no mesmo bloco simultaneamente. Assim, ao executar o bloco n, os nós receberão o bloco n+1 para o próximo passo.

Se houver uma discrepância de consenso (por exemplo, se um terço dos nós da rede agir de forma maliciosa), a cadeia será pausada, semelhante ao protocolo BFT padrão.

As transações falhadas dentro do bloco não invalidam o bloco, apenas mantêm o estado de falha, uma vez que a geração e a execução do bloco são separadas, e o estado final do bloco atual será submetido nos blocos subsequentes.

2. Como o modelo de múltiplos proponentes é implementado e Autobahn o que é?

O próprio protocolo de consenso é chamado de "Autobahn" (assim como a autoestrada alemã sem limite de velocidade). Autobahn separa a disponibilidade de dados da ordenação de transações, com um modelo interessante por trás.

Assim como em qualquer faixa de uma autoestrada, existem várias faixas, e cada nó tem seu próprio canal. Os nós usam esses canais para apresentar propostas sobre a ordenação das transações. As propostas são apenas um conjunto ordenado de transações.

Autobahn às vezes executa a operação "tipcut", que agrega várias propostas para determinar a ordem final das transações.

• Como mencionado anteriormente, cada validador tem seu próprio canal para propor lotes de transações.
• Quando um nó recebe uma proposta válida, envia um voto para confirmar que a proposta foi recebida.
• Após a coleta de propostas e votação, será formado um Prova de Autenticidade (PoA), garantindo que os dados foram recebidos por pelo menos um nó honesto na rede.
• O tempo de ocorrência do Tipcut é medido em milissegundos, e as várias propostas que vêm do Autobahn serão "cortadas".

Os proponentes têm o incentivo de aguardar a publicação do bloco e, quando possível, publicar um único bloco, mas o limite de tempo de execução de cada bloco (semelhante ao limite de Gas) altera ligeiramente essa dinâmica.

Uma proposta em um canal geralmente equivale a um bloco, o que significa que, quando ocorre o Tipcut, vários blocos são cortados ao mesmo tempo.

Após isso, o líder do slot enviará o Tipcut para outros nós para completar a ordenação. Os nós, na verdade, estão se preparando para o próximo Tipcut enquanto votam no Tipcut individual.

Os nós que perderam o lote podem obter assincronamente dos validadores listados no PoA: esta é a razão essencial pela qual a disponibilidade de dados é necessária.

Sob condições de sincronização, se o líder estiver correto, o Autobahn completará a confirmação da proposta em duas rodadas de comunicação. Se o líder falhar, o mecanismo elegerá um novo líder para manter o processo.

A próxima proposta de tip-cut pode realmente começar na fase de submissão do tip-cut atual, reduzindo assim a latência, uma vez que a execução ocorre em paralelo à geração.

Na verdade, todo o modelo é um modelo de múltiplos proponentes, onde muitos nós podem simultaneamente propor blocos para serem ordenados. Cada validador propõe seu próprio bloco e recebe a prova (PoA) de que a rede possui esses blocos, o que ajuda a aumentar a capacidade de processamento e a eficiência geral da rede.

3. Execução paralela e suas aplicações

Como mencionado anteriormente, o processo de execução de blocos ocorre em paralelo com o consenso, embora os blocos em si sejam executados em sequência. Você pode se perguntar se isso constitui uma verdadeira execução em paralelo.

A resposta é tanto afirmativa quanto negativa.

Embora os blocos sejam executados em ordem, as transações dentro do bloco podem ser realmente executadas em paralelo. Se as transações não modificarem (escreverem) o mesmo estado e o resultado de uma transação não afetar outra transação, então elas podem ser executadas em paralelo.

Em resumo, os seus caminhos de execução não devem depender uns dos outros. Giga não tem pool de memórias, as transações são imediatamente incluídas pelos nós.

• Giga assume que a maioria das transações não tem conflitos e processa essas transações simultaneamente em vários núcleos de processador.
• As alterações de cada transação são temporariamente armazenadas em um buffer privado e não são aplicadas imediatamente ao blockchain.
• Após a conclusão do processamento, o sistema verificará se a transação conflita com transações anteriores.
• Se houver conflitos, a transação será reprocessada. Se não houver conflitos, as suas alterações serão aplicadas à blockchain e finalizadas.

Pode haver situações de conflitos de alta frequência, caso em que o sistema alternará para processar uma transação de cada vez, a fim de garantir que a transação possa avançar.

De forma simples, a execução em paralelo atribui transações a vários núcleos, permitindo que aquelas transações que não têm conflito sejam executadas simultaneamente.

4. Problemas de armazenamento e otimização

Devido ao grande volume de transações, os dados precisam ser tanto seguros quanto de fácil acesso, portanto, a forma como são armazenados deve ser ligeiramente diferente do armazenamento tradicional em blockchain. O Giga armazena dados em um formato simples de chave-valor (key-value), que é uma estrutura relativamente plana, ajudando a reduzir as múltiplas atualizações ou verificações necessárias quando os dados são alterados.

Além disso, o Giga utiliza um método de armazenamento em camadas: dados recentes são mantidos em SSD (rápido), enquanto dados menos utilizados são migrados para um sistema de armazenamento mais lento e com melhor relação custo-benefício.

Se um nó falhar, ele pode reproduzir os logs para restaurar o estado correto e aplicar as atualizações ao RocksDB (um banco de dados especializado) para organizar os dados.

Este sistema de armazenamento utiliza um acumulador criptográfico (Cryptographic Accumulator), que pode provar a correção dos dados sem a necessidade de cálculos pesados. O acumulador é atualizado em modo de processamento em lote, permitindo que validadores e nós leves cheguem rapidamente a um consenso sobre o estado atual da blockchain.

5. O que significa tornar-se um múltiplo proponente EVM L1 blockchain?

A infraestrutura L1 pode passar por várias melhorias, e diferentes L1 enfrentam uma variedade de desafios técnicos, desde questões econômicas como MEV até problemas técnicos, como a gestão de estado.

Ser o primeiro L1 a suportar múltiplos proponentes é bastante desafiador, especialmente para L1 EVM, uma vez que o design do EVM não foi originalmente concebido para suportar sistemas de múltiplos proponentes.

No entanto, a Sei está a tentar diferentes abordagens para manter o EVM e muitas das ferramentas que os desenvolvedores costumam usar.

A execução paralela de transações, a obtenção de consenso durante o processo de execução e a operação paralela de múltiplos proponentes ajudam a melhorar o desempenho, com a taxa de execução podendo aumentar cerca de 50 vezes. No entanto, essas melhorias também podem enfrentar alguns dos riscos mencionados acima.

Esta é a segunda grande atualização do Sei, anteriormente o Sei passou da cadeia Cosmos para a cadeia EVM, e agora o Sei lançou um cliente de execução otimizado para velocidade.

O desenvolvimento seguinte, bem como os efeitos subsequentes dessas medidas de otimização, merecem atenção.

Leitura relacionada: Explorando o desempenho, conformidade e interoperabilidade da blockchain Sei