O SEI introduz mecanismos, incluindo execução assíncrona, consenso de vários proponentes, paralelismo de transações e otimização de armazenamento no upgrade do Giga. Este artigo é escrito por Pavel Paramonov, fundador da Hazeflow, e é compilado, compilado e contribuído por Felix, PANews. (Sinopse: $SEI 70% em um único mês!) Lançamento da proposta SIP-3: transição para EVM puro, visando 100.000 transações por segundo) (Background adicionado: MetaMask apoiará a "primeira cadeia não-EVM" da rede Solana MetaMask carteira fora da zona de conforto do Ethereum em maio) Sei lançou um novo white paper que apresenta a mais recente atualização Giga. A maioria dos leitores acha difícil ler 17 páginas de conteúdo técnico aprofundado. Portanto, este artigo explicará o que é essa atualização e como melhorar o desempenho do blockchain em diferentes níveis. 1. As principais ideias e fundamentos da geração de blocos giga para execução assíncrona são as seguintes: "Se nossa lista de transações estiver em ordem e o estado inicial do blockchain for consistente, e todos os nós honestos 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 independentemente. Neste modelo, o consenso é separado da execução, permitindo que os blocos sejam executados de forma assíncrona. Uma vez que o bloco é finalizado, o nó o processa e confirma seu estado nos blocos subsequentes. O bloco é então validado por consenso de estado para garantir que todos os nós tenham calculado o estado final correto. Um detalhe importante aqui é que a execução e o consenso (geração) ocorrem em paralelo. Quando um nó executa o cálculo de um bloco, ele também recebe outros blocos. Como resultado, os blocos são realmente executados em ordem total (e não em paralelo), enquanto o processo de geração de blocos em si ocorre em paralelo com o consenso. No entanto, para qualquer bloco, esses processos são completamente assíncronos. Obviamente, consenso e execução do mesmo bloco ao mesmo tempo parece impossível. Portanto, quando o bloco n é executado, o nó recebe o bloco n+1 para a próxima etapa. Se o consenso for distorcido (por exemplo, um terço dos nós na rede agir maliciosamente), a cadeia é suspensa, semelhante ao protocolo BFT padrão. A execução de uma transação com falha dentro de um bloco não invalida o bloco, mas simplesmente permanece em um estado de falha porque a geração e a execução do bloco são separadas e o estado final do bloco atual é confirmado nos blocos subsequentes. 2 Como é implementado o modelo multi-proposer e o que é Autobahn? O protocolo de consenso em si é chamado de "Autobahn" (como a autobahn alemã sem limite de velocidade). A Autobahn separa a disponibilidade de dados da ordem de transações, e há um modelo interessante por trás dela. Assim como as pistas de qualquer rodovia, existem várias pistas, cada nó com sua própria passagem. Os nós usam esses canais para fazer propostas sobre a ordenação de transações. Uma proposta é apenas uma coleção ordenada de transações. A Autobahn às vezes realiza uma operação de "tipcut", onde várias propostas são agregadas para finalizar a ordem das transações. Como mencionado anteriormente, cada validador tem seu próprio canal para propor muitas transações. Quando um nó recebe uma proposta válida, ele envia uma votação para confirmar que a proposta foi recebida. Uma vez que uma proposta é coletada para uma votação, uma Prova de Disponibilidade (PoA) é formada, garantindo que os dados foram recebidos por pelo menos um nó honesto na rede. As gorjetas ocorrem em milissegundos e, eventualmente, várias propostas da Autobahn são "cortadas". Os proponentes têm um incentivo para esperar que os blocos sejam liberados e liberar blocos individuais sempre que possível, mas o limite de tempo de execução para cada bloco (semelhante ao limite de gás) muda ligeiramente essa dinâmica. Uma proposta em um canal é geralmente equivalente a um bloco, o que significa que quando ocorre um tipcut, vários blocos são cortados ao mesmo tempo. Depois disso, o líder do slot passa o tipcut para outros nós para concluir a classificação. O nó está, na verdade, votando em um único tipcut ao mesmo tempo em que já está preparando o próximo tipcut. Os nós que perdem lotes podem ser obtidos de forma assíncrona a partir de validadores listados no PoA: esta é a essência da necessidade de disponibilidade de dados. Em condições síncronas, se o líder estiver correto, a Autobahn conclui a confirmação da proposta em duas rodadas de comunicação. Se um líder falhar, o mecanismo elege um novo líder para manter o programa em ordem. A próxima proposta de tip-cut pode realmente começar durante a fase de commit do tip-cut atual, reduzindo a latência porque a execução acontece em paralelo com a compilação. Na verdade, todo o modelo é um modelo multi-proposer onde muitos nós podem fazer propostas para a sua ordenação de blocos ao mesmo tempo. Cada validador propõe seus próprios blocos e recebe provas de que a rede possui esses blocos (PoA), o que ajuda a melhorar a taxa de transferência e a eficiência geral da rede. 3 Execução paralela e sua aplicação Como mencionado anteriormente, o processo de execução em bloco ocorre em paralelo com o consenso, embora os próprios blocos sejam realmente executados sequencialmente. Você pode estar se perguntando se isso constitui uma verdadeira execução paralela. A resposta é sim e não. Embora os blocos sejam executados sequencialmente, as transações dentro dos blocos podem, de fato, ser executadas em paralelo. Se as transações não modificarem (gravarem) o mesmo estado, e o resultado de uma transação não afetar outra, elas poderão ser executadas em paralelo. Em suma, os seus caminhos de execução não devem depender uns dos outros. Giga não tem um mempool, e as transações são imediatamente incluídas pelo nó. A Giga assume que não há conflitos entre a maioria das transações e as processa simultaneamente em vários núcleos de processador. As alterações em cada transação são armazenadas temporariamente em um buffer privado e não são aplicadas imediatamente ao blockchain. Quando o processamento é concluído, o sistema verifica se a transação está em conflito com as transações anteriores. Se houver um conflito, a transação será reprocessada. Se não houver conflitos, suas alterações são aplicadas ao blockchain e finalizadas. Também pode haver colisões de alta frequência, caso em que o sistema muda para processar uma transação de cada vez para garantir que a transação possa avançar. Em termos simples, a execução paralela distribui transações em vários núcleos, permitindo que as transações que não entram em conflito sejam executadas simultaneamente. 4. Problemas de armazenamento e otimização Devido ao alto volume de transações, os dados precisam ser seguros e facilmente acessíveis, por isso devem ser armazenados de uma maneira ligeiramente diferente do armazenamento blockchain tradicional. O Gigas armazena dados em um formato simples de chave-valor, uma estrutura relativamente plana que ajuda a reduzir a necessidade de várias atualizações ou verificações quando os dados são alterados. Além disso, o Giga usa armazenamento hierárquico: os dados recentes são retidos em SSDs (alta velocidade), enquanto os dados menos usados são migrados para sistemas de armazenamento mais lentos e econômicos. 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. O sistema de armazenamento usa um acumulador criptográfico que comprova a exatidão dos dados sem cálculos pesados. Os acumuladores são atualizados em lotes, permitindo que validadores e nós leves concordem rapidamente sobre o estado atual do blockchain. 5. Torne-se um bloco EVM L1 multi-proposer...
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Interpretação do novo White Paper da Sei: Quais inovações tecnológicas são introduzidas na atualização Giga?
O SEI introduz mecanismos, incluindo execução assíncrona, consenso de vários proponentes, paralelismo de transações e otimização de armazenamento no upgrade do Giga. Este artigo é escrito por Pavel Paramonov, fundador da Hazeflow, e é compilado, compilado e contribuído por Felix, PANews. (Sinopse: $SEI 70% em um único mês!) Lançamento da proposta SIP-3: transição para EVM puro, visando 100.000 transações por segundo) (Background adicionado: MetaMask apoiará a "primeira cadeia não-EVM" da rede Solana MetaMask carteira fora da zona de conforto do Ethereum em maio) Sei lançou um novo white paper que apresenta a mais recente atualização Giga. A maioria dos leitores acha difícil ler 17 páginas de conteúdo técnico aprofundado. Portanto, este artigo explicará o que é essa atualização e como melhorar o desempenho do blockchain em diferentes níveis. 1. As principais ideias e fundamentos da geração de blocos giga para execução assíncrona são as seguintes: "Se nossa lista de transações estiver em ordem e o estado inicial do blockchain for consistente, e todos os nós honestos 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 independentemente. Neste modelo, o consenso é separado da execução, permitindo que os blocos sejam executados de forma assíncrona. Uma vez que o bloco é finalizado, o nó o processa e confirma seu estado nos blocos subsequentes. O bloco é então validado por consenso de estado para garantir que todos os nós tenham calculado o estado final correto. Um detalhe importante aqui é que a execução e o consenso (geração) ocorrem em paralelo. Quando um nó executa o cálculo de um bloco, ele também recebe outros blocos. Como resultado, os blocos são realmente executados em ordem total (e não em paralelo), enquanto o processo de geração de blocos em si ocorre em paralelo com o consenso. No entanto, para qualquer bloco, esses processos são completamente assíncronos. Obviamente, consenso e execução do mesmo bloco ao mesmo tempo parece impossível. Portanto, quando o bloco n é executado, o nó recebe o bloco n+1 para a próxima etapa. Se o consenso for distorcido (por exemplo, um terço dos nós na rede agir maliciosamente), a cadeia é suspensa, semelhante ao protocolo BFT padrão. A execução de uma transação com falha dentro de um bloco não invalida o bloco, mas simplesmente permanece em um estado de falha porque a geração e a execução do bloco são separadas e o estado final do bloco atual é confirmado nos blocos subsequentes. 2 Como é implementado o modelo multi-proposer e o que é Autobahn? O protocolo de consenso em si é chamado de "Autobahn" (como a autobahn alemã sem limite de velocidade). A Autobahn separa a disponibilidade de dados da ordem de transações, e há um modelo interessante por trás dela. Assim como as pistas de qualquer rodovia, existem várias pistas, cada nó com sua própria passagem. Os nós usam esses canais para fazer propostas sobre a ordenação de transações. Uma proposta é apenas uma coleção ordenada de transações. A Autobahn às vezes realiza uma operação de "tipcut", onde várias propostas são agregadas para finalizar a ordem das transações. Como mencionado anteriormente, cada validador tem seu próprio canal para propor muitas transações. Quando um nó recebe uma proposta válida, ele envia uma votação para confirmar que a proposta foi recebida. Uma vez que uma proposta é coletada para uma votação, uma Prova de Disponibilidade (PoA) é formada, garantindo que os dados foram recebidos por pelo menos um nó honesto na rede. As gorjetas ocorrem em milissegundos e, eventualmente, várias propostas da Autobahn são "cortadas". Os proponentes têm um incentivo para esperar que os blocos sejam liberados e liberar blocos individuais sempre que possível, mas o limite de tempo de execução para cada bloco (semelhante ao limite de gás) muda ligeiramente essa dinâmica. Uma proposta em um canal é geralmente equivalente a um bloco, o que significa que quando ocorre um tipcut, vários blocos são cortados ao mesmo tempo. Depois disso, o líder do slot passa o tipcut para outros nós para concluir a classificação. O nó está, na verdade, votando em um único tipcut ao mesmo tempo em que já está preparando o próximo tipcut. Os nós que perdem lotes podem ser obtidos de forma assíncrona a partir de validadores listados no PoA: esta é a essência da necessidade de disponibilidade de dados. Em condições síncronas, se o líder estiver correto, a Autobahn conclui a confirmação da proposta em duas rodadas de comunicação. Se um líder falhar, o mecanismo elege um novo líder para manter o programa em ordem. A próxima proposta de tip-cut pode realmente começar durante a fase de commit do tip-cut atual, reduzindo a latência porque a execução acontece em paralelo com a compilação. Na verdade, todo o modelo é um modelo multi-proposer onde muitos nós podem fazer propostas para a sua ordenação de blocos ao mesmo tempo. Cada validador propõe seus próprios blocos e recebe provas de que a rede possui esses blocos (PoA), o que ajuda a melhorar a taxa de transferência e a eficiência geral da rede. 3 Execução paralela e sua aplicação Como mencionado anteriormente, o processo de execução em bloco ocorre em paralelo com o consenso, embora os próprios blocos sejam realmente executados sequencialmente. Você pode estar se perguntando se isso constitui uma verdadeira execução paralela. A resposta é sim e não. Embora os blocos sejam executados sequencialmente, as transações dentro dos blocos podem, de fato, ser executadas em paralelo. Se as transações não modificarem (gravarem) o mesmo estado, e o resultado de uma transação não afetar outra, elas poderão ser executadas em paralelo. Em suma, os seus caminhos de execução não devem depender uns dos outros. Giga não tem um mempool, e as transações são imediatamente incluídas pelo nó. A Giga assume que não há conflitos entre a maioria das transações e as processa simultaneamente em vários núcleos de processador. As alterações em cada transação são armazenadas temporariamente em um buffer privado e não são aplicadas imediatamente ao blockchain. Quando o processamento é concluído, o sistema verifica se a transação está em conflito com as transações anteriores. Se houver um conflito, a transação será reprocessada. Se não houver conflitos, suas alterações são aplicadas ao blockchain e finalizadas. Também pode haver colisões de alta frequência, caso em que o sistema muda para processar uma transação de cada vez para garantir que a transação possa avançar. Em termos simples, a execução paralela distribui transações em vários núcleos, permitindo que as transações que não entram em conflito sejam executadas simultaneamente. 4. Problemas de armazenamento e otimização Devido ao alto volume de transações, os dados precisam ser seguros e facilmente acessíveis, por isso devem ser armazenados de uma maneira ligeiramente diferente do armazenamento blockchain tradicional. O Gigas armazena dados em um formato simples de chave-valor, uma estrutura relativamente plana que ajuda a reduzir a necessidade de várias atualizações ou verificações quando os dados são alterados. Além disso, o Giga usa armazenamento hierárquico: os dados recentes são retidos em SSDs (alta velocidade), enquanto os dados menos usados são migrados para sistemas de armazenamento mais lentos e econômicos. 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. O sistema de armazenamento usa um acumulador criptográfico que comprova a exatidão dos dados sem cálculos pesados. Os acumuladores são atualizados em lotes, permitindo que validadores e nós leves concordem rapidamente sobre o estado atual do blockchain. 5. Torne-se um bloco EVM L1 multi-proposer...