Escrito por: Pavel Paramonov, fundador da Hazeflow
Compilado por: PANews
A Sei lançou um novo white paper, que apresenta a mais recente atualização Giga. A maioria dos leitores achou o conteúdo técnico de 17 páginas difícil de ler. Assim, este artigo explicará o que foi atualizado e como melhorar o desempenho da blockchain em diferentes níveis.
Sobre a geração de blocos em execução assíncrona
A principal ideia e base do Giga são as seguintes:
"Se a nossa lista de transações estiver ordenada e o estado inicial da blockchain for consistente, e se todos os nós honesto processarem essas transações na mesma ordem, então 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 concordar com a ordem das transações dentro do bloco, e cada nó pode calcular o estado final de forma independente.
Neste modelo, a consensualização é separada da execução, permitindo que os blocos sejam executados de forma assíncrona.
Uma vez que o bloco é finalmente confirmado, os nós irão processá-lo e submeter o seu estado em blocos subsequentes.
Em seguida, o bloco é validado 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 de forma paralela. Enquanto um nó executa o cálculo de um bloco, ele também recebe outros blocos.
Portanto, os blocos são realmente executados em uma 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 impossível ter consenso e execução no mesmo bloco ao mesmo tempo. Portanto, ao executar o bloco n, o nó receberá o bloco n+1 para o próximo passo.
Se houver uma discrepância no consenso (por exemplo, se um terço dos nós na rede agir de forma maliciosa), a cadeia será pausada, semelhante ao protocolo BFT padrão.
Transações que falham na execução dentro de um bloco não tornam esse bloco inválido, apenas mantêm o estado de falha, pois a geração e execução do bloco são separadas, e o estado final do bloco atual será submetido em blocos subsequentes.
Como funciona o modelo de múltiplos proponentes e o que é Autobahn?
O protocolo de consenso em si é chamado de "Autobahn" (assim como a autoestrada alemã sem limite de velocidade). O Autobahn separa a disponibilidade de dados da ordenação de transações, e por trás dele há um modelo interessante.
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 fazer propostas sobre a ordenação das transações. As propostas são apenas conjuntos ordenados de transações.
Autobahn às vezes executa a operação "tipcut", ou seja, 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 para votação, será gerada uma prova de validade (PoA), garantindo que os dados foram recebidos por pelo menos um nó honesto na rede.
O tempo do Tipcut é medido em milissegundos, e as várias propostas provenientes de Autobahn serão "cut.".
Os proponentes têm o incentivo de esperar pela publicação de blocos e, sempre que possível, publicar um único bloco, mas o limite de tempo de execução para 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 o Tipcut ocorre, 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, já estão se preparando para o próximo Tipcut enquanto votam em um único Tipcut.
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.
Em 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 progresso.
A próxima proposta de tip-cut pode, na verdade, 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 com a geração.
Na verdade, todo o modelo é um modelo de múltiplos proponentes, onde muitos nós podem propor simultaneamente a ordenação de seus blocos. 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.
Execução paralela e suas aplicações
Como mencionado anteriormente, o processo de execução de blocos e o consenso ocorrem em paralelo, embora os blocos em si sejam realmente executados em ordem. Você pode se perguntar se isso constitui uma verdadeira execução paralela.
A resposta é tanto afirmativa quanto negativa.
Embora os blocos sejam executados em ordem, as transações dentro de um bloco podem realmente ser 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 um do outro. 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 apresenta conflitos e processa essas transações simultaneamente em múltiplos núcleos de processador.
As alterações em cada transação são temporariamente armazenadas em um buffer privado e não são aplicadas imediatamente à blockchain.
Após a conclusão do processamento, o sistema verificará se a transação tem conflitos 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.
Também podem existir situações de conflitos frequentes, caso em que o sistema alternará para processar uma transação de cada vez, a fim de garantir que as transações possam avançar.
Em termos simples, a execução paralela distribui transações entre múltiplos núcleos, permitindo que aquelas transações que não entram em conflito sejam executadas ao mesmo tempo.
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 sua forma de armazenamento 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, a Giga também utiliza uma abordagem de armazenamento em camadas: os dados recentes são mantidos em SSDs (alta velocidade), enquanto os dados menos utilizados são migrados para sistemas de armazenamento mais lentos e mais econômicos.
Se um nó falhar, ele pode reproduzir o log para restaurar o estado correto e aplicar as atualizações ao RocksDB (um banco de dados dedicado) 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 de forma batch, permitindo que validadores e nós leves cheguem rapidamente a um consenso sobre o estado atual da blockchain.
O que significa tornar-se uma blockchain EVM L1 com múltiplos proponentes?
A infraestrutura L1 pode passar por várias melhorias, e diferentes L1 enfrentam diversos desafios técnicos, desde questões econômicas como MEV até questões técnicas como gerenciamento de estado.
Como a primeira cadeia L1 a suportar múltiplos proponentes, é bastante desafiador, especialmente para a L1 EVM, uma vez que o design da EVM não foi concebido para suportar sistemas de múltiplos proponentes.
No entanto, a Sei está a tentar diferentes abordagens para manter a EVM e muitas das ferramentas que os desenvolvedores estão habituados a 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 vários proponentes ajudam a melhorar o desempenho, podendo aumentar a taxa de execução em 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 transformou-se de uma cadeia Cosmos para uma cadeia EVM, e agora o Sei lançou um cliente de execução otimizado para velocidade.
O desenvolvimento futuro e os efeitos subsequentes destas medidas de otimização merecem atenção.
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Interpretação do novo White Paper da Sei: Quais inovações tecnológicas são introduzidas com a atualização Giga?
Escrito por: Pavel Paramonov, fundador da Hazeflow
Compilado por: PANews
A Sei lançou um novo white paper, que apresenta a mais recente atualização Giga. A maioria dos leitores achou o conteúdo técnico de 17 páginas difícil de ler. Assim, este artigo explicará o que foi atualizado e como melhorar o desempenho da blockchain em diferentes níveis.
Sobre a geração de blocos em execução assíncrona
A principal ideia e base do Giga são as seguintes:
"Se a nossa lista de transações estiver ordenada e o estado inicial da blockchain for consistente, e se todos os nós honesto processarem essas transações na mesma ordem, então 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 concordar com a ordem das transações dentro do bloco, e cada nó pode calcular o estado final de forma independente.
Neste modelo, a consensualização é separada da execução, permitindo que os blocos sejam executados de forma assíncrona.
Uma vez que o bloco é finalmente confirmado, os nós irão processá-lo e submeter o seu estado em blocos subsequentes.
Em seguida, o bloco é validado 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 de forma paralela. Enquanto um nó executa o cálculo de um bloco, ele também recebe outros blocos.
Portanto, os blocos são realmente executados em uma 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 impossível ter consenso e execução no mesmo bloco ao mesmo tempo. Portanto, ao executar o bloco n, o nó receberá o bloco n+1 para o próximo passo.
Se houver uma discrepância no consenso (por exemplo, se um terço dos nós na rede agir de forma maliciosa), a cadeia será pausada, semelhante ao protocolo BFT padrão.
Transações que falham na execução dentro de um bloco não tornam esse bloco inválido, apenas mantêm o estado de falha, pois a geração e execução do bloco são separadas, e o estado final do bloco atual será submetido em blocos subsequentes.
Como funciona o modelo de múltiplos proponentes e o que é Autobahn?
O protocolo de consenso em si é chamado de "Autobahn" (assim como a autoestrada alemã sem limite de velocidade). O Autobahn separa a disponibilidade de dados da ordenação de transações, e por trás dele há um modelo interessante.
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 fazer propostas sobre a ordenação das transações. As propostas são apenas conjuntos ordenados de transações.
Autobahn às vezes executa a operação "tipcut", ou seja, 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 para votação, será gerada uma prova de validade (PoA), garantindo que os dados foram recebidos por pelo menos um nó honesto na rede.
O tempo do Tipcut é medido em milissegundos, e as várias propostas provenientes de Autobahn serão "cut.".
Os proponentes têm o incentivo de esperar pela publicação de blocos e, sempre que possível, publicar um único bloco, mas o limite de tempo de execução para 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 o Tipcut ocorre, 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, já estão se preparando para o próximo Tipcut enquanto votam em um único Tipcut.
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.
Em 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 progresso.
A próxima proposta de tip-cut pode, na verdade, 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 com a geração.
Na verdade, todo o modelo é um modelo de múltiplos proponentes, onde muitos nós podem propor simultaneamente a ordenação de seus blocos. 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.
Execução paralela e suas aplicações
Como mencionado anteriormente, o processo de execução de blocos e o consenso ocorrem em paralelo, embora os blocos em si sejam realmente executados em ordem. Você pode se perguntar se isso constitui uma verdadeira execução paralela.
A resposta é tanto afirmativa quanto negativa.
Embora os blocos sejam executados em ordem, as transações dentro de um bloco podem realmente ser 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 um do outro. 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 apresenta conflitos e processa essas transações simultaneamente em múltiplos núcleos de processador.
As alterações em cada transação são temporariamente armazenadas em um buffer privado e não são aplicadas imediatamente à blockchain.
Após a conclusão do processamento, o sistema verificará se a transação tem conflitos 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.
Também podem existir situações de conflitos frequentes, caso em que o sistema alternará para processar uma transação de cada vez, a fim de garantir que as transações possam avançar.
Em termos simples, a execução paralela distribui transações entre múltiplos núcleos, permitindo que aquelas transações que não entram em conflito sejam executadas ao mesmo tempo.
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 sua forma de armazenamento 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, a Giga também utiliza uma abordagem de armazenamento em camadas: os dados recentes são mantidos em SSDs (alta velocidade), enquanto os dados menos utilizados são migrados para sistemas de armazenamento mais lentos e mais econômicos.
Se um nó falhar, ele pode reproduzir o log para restaurar o estado correto e aplicar as atualizações ao RocksDB (um banco de dados dedicado) 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 de forma batch, permitindo que validadores e nós leves cheguem rapidamente a um consenso sobre o estado atual da blockchain.
O que significa tornar-se uma blockchain EVM L1 com múltiplos proponentes?
A infraestrutura L1 pode passar por várias melhorias, e diferentes L1 enfrentam diversos desafios técnicos, desde questões econômicas como MEV até questões técnicas como gerenciamento de estado.
Como a primeira cadeia L1 a suportar múltiplos proponentes, é bastante desafiador, especialmente para a L1 EVM, uma vez que o design da EVM não foi concebido para suportar sistemas de múltiplos proponentes.
No entanto, a Sei está a tentar diferentes abordagens para manter a EVM e muitas das ferramentas que os desenvolvedores estão habituados a 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 vários proponentes ajudam a melhorar o desempenho, podendo aumentar a taxa de execução em 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 transformou-se de uma cadeia Cosmos para uma cadeia EVM, e agora o Sei lançou um cliente de execução otimizado para velocidade.
O desenvolvimento futuro e os efeitos subsequentes destas medidas de otimização merecem atenção.