Fonte original: Gravity

Introdução

Desde o lançamento da Gravity Alpha Mainnet em agosto de 2024, a rede processou mais de 275 milhões de transações, com um volume médio diário de até 2,6 milhões de transações, e conseguiu taxas de transação de 30 milhões G. À medida que o Litepaper é lançado, estamos otimistas sobre o futuro desta blockchain EVM de alto desempenho. Este artigo irá analisar em profundidade o Litepaper, revelando como o Gravity constrói uma arquitetura excepcional de blockchain Layer-1 de alto desempenho para aplicações do mundo real.

Gravity é uma blockchain Layer-1 de alto desempenho e compatível com EVM criada pela Galxe. O desenvolvimento do Gravity surgiu das necessidades de crescimento da Galxe. A plataforma Galxe, como a maior plataforma de distribuição on-chain do mundo, conecta um grande ecossistema multi-chain, atraindo mais de 25 milhões de usuários. Ao longo de seu processo de desenvolvimento, a Galxe evoluiu para um super aplicativo descentralizado, integrando ferramentas inovadoras como Quest, Passport, Score, Compass e Alva, enquanto oferece uma rica gama de serviços como pontos de fidelidade, NFTs de eventos, recompensas em tokens, autenticação zk e poupança inteligente cross-chain. Durante seu contínuo desenvolvimento, o alto volume de transações da Galxe se tornou um fator importante para a construção do Gravity - seu sistema de pontos de fidelidade suporta 51,2 transações por segundo, enquanto suas atividades de recompensa em token suportam 32,1 transações por segundo. Isso nos levou a precisar migrar para uma blockchain EVM ao descentralizar o backend da Galxe, garantindo a melhor experiência do usuário.

À medida que a Galxe avança para uma total on-chain, o aumento adicional do volume de transações é esperado. A demanda de taxa de transferência deve atingir 50 milhões de gas por segundo, enquanto atender a necessidades mais amplas do ecossistema (como liquidação cross-chain, transações de pontos de fidelidade e mercados NFT) pode exigir capacidade de processamento de 500 milhões de gas por segundo. Para isso, o objetivo do Gravity é suportar uma taxa de transferência de 1 gigagas por segundo, a fim de atender às necessidades de escalabilidade de aplicações que consomem muitos recursos.

Entre as soluções existentes, muitas plataformas realizam escalabilidade através do Ethereum, mas os períodos de contestação do L2 Rollup inevitavelmente resultam em atrasos nas transações, o que não é amigável para aplicações como a Galxe que precisam de confirmações imediatas de transações. Embora alguns DApps tentem compensar os atrasos com modos de confiança ou monitoramento externo, esses métodos introduzem complexidade e riscos adicionais, o que não é ideal para cenários de aplicação principais.

Nesse contexto, o Gravity surgiu. O Gravity é baseado em um EVM paralelo, desenvolvendo o Grevm, atualmente o sistema de execução EVM paralelo de código aberto mais rápido, reduzindo a lacuna de desempenho entre L2 e L1. Além disso, o Gravity modulariza a arquitetura do Aptos, integrando componentes verificados como Quorum Store e o motor de consenso AptosBFT. Aproveitando a arquitetura madura do Aptos, o Gravity evita a complexidade e os riscos potenciais do desenvolvimento do zero. No final, o Gravity não apenas construiu uma blockchain Layer-1 de alto desempenho que oferece uma experiência de cadeia completa, mas também lançou o primeiro SDK de blockchain em pipeline, simplificando enormemente o fluxo de interação entre desenvolvedores e usuários.

O Gravity oferece escalabilidade, capacidade descentralizada e uma velocidade de transação quase instantânea sem precedentes. Sua tecnologia combina as vantagens do L1 e L2, alcançando 10.000 transações por segundo e finalidades sub-segundo. Ao integrar protocolos de reestaca como EigenLayer e Babylon, o Gravity não apenas assegura robusta segurança na fase de lançamento, mas também reduz o risco sistêmico de depender de um único ativo a longo prazo.

No futuro, o Gravity avançará conforme o seguinte roteiro:

· Lançamento da fase 1 do Devnet, testando o desempenho em tempo real;

· Lançamento do Longevity Testnet, validando a estabilidade da rede a longo prazo;

· Transição da Gravity Alpha Mainnet para a Gravity Mainnet totalmente operacional, estabelecendo a base para a aplicação em larga escala de tecnologia descentralizada.

Abaixo está a compilação completa do Gravity Litepaper.

Resumo

Gravity é uma blockchain Layer-1 de alto desempenho e compatível com EVM criada pela Galxe, projetada para aplicações em larga escala e ecossistemas multi-chain. Suas características incluem uma taxa de transferência de 1 gigagas por segundo, confirmações finais de transações sub-segundo e um mecanismo de consenso PoS baseado em protocolos de reestaca. O design do Gravity se baseia em dois componentes de código aberto fundamentais: (1) Gravity SDK, um motor de consenso PoS de AptosBFT baseado em reestaca em forma de pipeline; (2) Gravity reth, uma camada de execução impulsionada pelo Grevm (Gravity EVM) em paralelo. Essas ferramentas oferecem aos aplicativos Web3 a capacidade de construir uma alternativa Layer-1 e uma Layer-2 eficiente, destacando-se especialmente em cadeias EVM. Este artigo explora em profundidade o design de engenharia e inovação técnica do Gravity, mostrando como atender às demandas de alto desempenho por meio de uma arquitetura de pipeline, algoritmos de consenso avançados, tecnologia de execução paralela e mecanismos de armazenamento otimizados (através do aprimoramento do reth e melhorias no motor de consenso Aptos).

Introdução

O desenvolvimento do Gravity surgiu dos desafios enfrentados pela Galxe em suas operações. A Galxe é um aplicativo Web3 líder que oferece serviços de pontos de fidelidade, NFTs de eventos, recompensas em tokens, autenticação zero-knowledge e poupança inteligente cross-chain. À medida que a Galxe se desenvolve rapidamente, seu sistema de pontos de fidelidade processa em média 51,2 transações por segundo, enquanto as atividades de recompensa em tokens processam em média 32,1 transações por segundo. Durante o processo de descentralização gradual da Galxe, migrar esses casos de uso para uma blockchain EVM, enquanto se garante uma experiência de usuário fluida, tornou-se um desafio. Portanto, desenvolver uma blockchain EVM de alto desempenho que possa atender à (1) alta taxa de transferência de transações e (2) confirmações de transações quase instantâneas tornou-se crucial.

Nesse contexto, a escolha entre soluções Layer-2 existentes ou o desenvolvimento de um novo Layer-1 é um ponto de decisão crítico. O Layer-1 alcança a finalização por meio de um algoritmo de consenso, enquanto o Layer-2 aborda essa questão com protocolos de Rollup. Há um trade-off entre os dois: o Layer-1 geralmente sacrifica parte da taxa de transferência devido às limitações do algoritmo de consenso, mas pode alcançar confirmações de transações mais rápidas. Por exemplo, um algoritmo de consenso baseado em AptosBFT pode confirmar transações em menos de um segundo, enquanto um Rollup otimista pode ter um período de contestação que dura até sete dias. Embora as provas de conhecimento zero possam acelerar esse processo, a confirmação final ainda pode levar várias horas. Considerando a necessidade do Gravity por confirmações finais sub-segundo (especialmente seu protocolo de intenção de cadeia inteira), optamos por construir um Layer-1.

Embora o Layer-2 tenha vantagens nativas na comunicação com o Ethereum, Layer-1 como o Gravity pode alcançar uma interoperabilidade profunda com Ethereum e outras blockchains através do protocolo de intenção Gravity e pontes cross-chain. Esse design não apenas colabora perfeitamente com o Ethereum, mas também melhora a conectividade de todo o ecossistema Web3.

Além disso, os protocolos de reestaca (restaking) reduziram significativamente a dificuldade de construir uma blockchain PoS Layer-1. O Gravity integra ativos de staking de Ethereum e Bitcoin, combinando-os com sua ampla rede de validadores através de protocolos como EigenLayer e Babylon. Isso fornece uma garantia econômica para o consenso PoS, permitindo que a descentralização e segurança do Gravity atinjam um nível comparável ao do Ethereum.

Em resumo, o Gravity foi construído como uma blockchain Layer-1 de alto desempenho e compatível com EVM para atender à escalabilidade e necessidades de desempenho das aplicações Web3 modernas. Embora seu desenvolvimento tenha sido inicialmente para servir a Galxe, a flexível estrutura oferecida pelo Gravity SDK e Grevm (Gravity EVM) é adequada para construir qualquer Layer-1 e Layer-2 eficiente, com funcionalidades semelhantes ao Tendermint/Cosmos SDK.

Precisamos de 1 gigagas/s de taxa de transferência

Para blockchains, a taxa de transferência é o indicador de desempenho mais crítico, geralmente medido em transações por segundo (TPS) ou uso de gás por segundo (gas/s). Tomando como exemplo o sistema de pontos de fidelidade do Galxe, ele requer pelo menos 4 milhões de gas/s para operar de forma estável. Esse número se baseia em cada transação de ponto de fidelidade consumindo em média 80.000 gás e sendo capaz de processar cerca de 51,2 transações por segundo.

Essa previsão foi apoiada por dados práticos da Gravity Alpha Mainnet. Como nossa rede Layer 2 em teste, as transações de pontos de fidelidade da Gravity Alpha Mainnet mostraram uma taxa de transferência estável de 4 milhões de gas/s, validando a precisão da estimativa anterior.

Embora os altos custos de operações on-chain possam levar a uma leve diminuição na demanda, a tendência de expansão da Galxe indica que a demanda pode aumentar de duas a três vezes em horários de pico. Além disso, com a adição de outros cenários de aplicação, como NFTs, recompensas em tokens e futuras tarefas on-chain suportadas por provas de conhecimento zero, se a Galxe se tornar totalmente on-chain, a demanda de taxa de transferência pode atingir 50 milhões de gas/s. Supondo que o uso de gas em aplicações na Gravity siga uma distribuição de Pareto (similar ao Uniswap consumindo 10% do gás do Ethereum), idealmente, seria necessário suportar uma taxa de transferência de 500 milhões de gas/s para atender às necessidades mais amplas do ecossistema, como liquidação cross-chain, transações de pontos de fidelidade e mercado NFT. Portanto, para atender a essas demandas potenciais, a blockchain deve ter capacidade de processamento de 1 gigagas por segundo, garantindo que possa se adaptar às necessidades de escalabilidade de aplicações que consomem muitos recursos.

Para alcançar uma taxa de transferência tão alta, a chave é introduzir a EVM paralela. Desenvolvemos o Grevm, que é o sistema de execução EVM paralelo de código aberto mais rápido atualmente, cujas especificações de desempenho podem ser vistas nos capítulos subsequentes.

Tempo de confirmação sub-segundo

Além da taxa de transferência, a velocidade de confirmação das transações é crucial para a experiência do usuário. Usuários modernos estão acostumados a respostas quase instantâneas semelhantes ao Web2, o que ainda é um desafio para a blockchain. Tomemos o Galxe como exemplo, que é semelhante a jogos totalmente na cadeia e tem certos requisitos de baixa latência. Atualmente, o tempo de confirmação de transações na maioria das blockchains EVM varia de segundos a dias, muito aquém desse requisito. Nós escolhemos o algoritmo de consenso AptosBFT para alcançar tempos de confirmação sub-segundo.

Embora o L2 Rollup possa teoricamente aumentar a taxa de transferência, seus períodos de contestação podem causar atrasos nas transações, o que é muito desfavorável para aplicações que exigem confirmações imediatas de transações, como a Galxe. Embora alguns DApps tentem otimizar isso por meio de modos de confiança ou monitoramento externo, isso introduz complexidade e riscos adicionais, o que não é ideal para aplicações críticas. O Gravity SDK reduz a diferença de desempenho entre L2 e L1 ao projetar um pipeline de cinco estágios que paraleliza os processos de consenso e execução (detalhes do design estão disponíveis mais adiante).

Segurança PoS baseada em reestaca (Restaking)

O Gravity SDK oferece uma maneira segura de escalar o Ethereum, não se limitando apenas ao L2 Rollup, mas optando por uma arquitetura de L1 protegida por reestaca, equilibrando desempenho, interoperabilidade e segurança. O módulo central integra protocolos de reestaca como EigenLayer e Babylon, oferecendo suporte econômico para garantir um consenso de prova de participação robusto.

Com 45 bilhões de dólares em ativos em staking no Ethereum e 850.000 validadores, além de 600 bilhões de dólares de ativos conectados ao Bitcoin através do Babylon, o Gravity pode estabelecer uma base de segurança robusta desde o início, evitando problemas comuns de inicialização e riscos de segurança em novas blockchains, ao mesmo tempo em que reduz o risco sistêmico de depender de um único ativo a longo prazo.

Arquitetura da Gravity Chain

Gravity Chain contém dois componentes principais: Gravity SDK e Gravity reth. O Gravity SDK é uma estrutura de blockchain aprimorada a partir da cadeia Aptos, que é a blockchain PoS mais avançada atualmente, baseada na família de algoritmos de consenso HotStuff, cuja arquitetura em pipeline aumenta significativamente a taxa de transferência e a eficiência de recursos. O Gravity reth é uma camada de execução baseada em reth, funcionando na forma de um reator de fluxo de blocos (BSR), para receber blocos propostos da camada de consenso. Ao otimizar o reth, o Gravity reth alcança execução paralela, cálculo assíncrono em lote de submissão de estado e melhorias na eficiência de armazenamento. Esses dois componentes estão intimamente integrados através da interface do motor de consenso Gravity (GCEI) e do adaptador reth, gerenciados dinamicamente pelo controlador de pipeline a cada fase.

Esse design separa a execução de blocos do consenso de blocos, fazendo com que a camada de execução atue como consumidora das propostas de blocos. Nossa otimização do reth torna-o perfeitamente adaptado ao fluxo de propostas de blocos gerenciado pelo reator de fluxo de blocos (BSR).

O fluxo de transações do Gravity Chain é o seguinte:

1. As transações são submetidas através da interface JSON RPC do Gravity reth, que é totalmente compatível com Ethereum.

2. Em seguida, as transações entram no pool de memória do Gravity SDK e se propagam pela rede, onde os validadores processam as transações em lote e geram um certificado Quorum Store (QS).

3. A cada rodada, o líder propõe uma proposta de bloco que inclui metadados do bloco e transações ordenadas selecionadas da memória e QS.

4. Após a proposta ser marcada como ordenada, ela entrará na camada de execução.

5. A camada de execução do Grevm processa as transações em paralelo, gera o resultado da execução e passa o novo estado para o módulo de gerenciamento de estado.

6. O módulo de estado calcula a raiz de estado e a transmite ao mecanismo de consenso para alcançar o consenso sobre a raiz de estado.

7. Após a confirmação final da raiz de estado, o módulo de armazenamento persiste a raiz de estado e os dados do bloco.

Os próximos capítulos detalharão cada componente.

Gravity SDK: Prática inovadora de blockchain em pipeline

O Gravity SDK é uma estrutura de blockchain modular e de código aberto, desenvolvida a partir da blockchain Aptos pronta para produção. Seu objetivo é modularizar a arquitetura do Aptos, aproveitando componentes verificados como Quorum Store e o motor de consenso AptosBFT, criando o primeiro SDK de blockchain em pipeline.

As razões para a escolha do Aptos como base incluem:

· Arquitetura técnica de topo: Aptos é uma blockchain PoS avançada baseada no consenso da família HotStuff.

· Desempenho extremo: Aptos oferece uma taxa de transferência de 160.000 transações por segundo e um tempo de confirmação final inferior a 1 segundo.

· Confiabilidade em situações práticas: Aptos já foi validado em ambientes de produção, demonstrando estabilidade e eficiência excepcionais.

· Evitar reinventar a roda: aproveitar a arquitetura madura do Aptos pode evitar a complexidade e os riscos potenciais do desenvolvimento do zero, enquanto outras tentativas de superar o Aptos são, em sua maioria, teóricas e práticas insuficientes.

· Ganhos colaborativos: à medida que o Aptos continua a evoluir, o Gravity SDK poderá integrar perfeitamente seus novos recursos, como a API de números aleatórios, enquanto retroalimenta o Aptos através de sua arquitetura modular e mecanismos de segurança inovadores.

A blockchain baseada no Gravity SDK se conecta ao motor de consenso Gravity através da Gravity Consensus Engine Interface (GCEI). Embora o GCEI seja compatível com várias camadas de execução, o Gravity SDK atualmente suporta principalmente o Gravity reth. Detalhes sobre o GCEI serão discutidos em capítulos subsequentes.

Interface do Motor de Consenso Gravity (GCEI)

O protocolo GCEI (Gravity Consensus Execution Interface) é a ponte de comunicação entre a camada de consenso e a camada de execução. Ele padroniza a interação entre as duas camadas, garantindo que os processos de consenso e execução permaneçam sincronizados através do controlador de pipeline.

A principal diferença entre o SDK de blockchain tradicional e o Gravity SDK está em seu motor de consenso em pipeline. A camada de execução deve ser implementada como um reator de fluxo de blocos (Block Stream Reactor), o que significa que ela deve ser capaz de consumir continuamente o fluxo de blocos propostos, e o compromisso de estado deve ser calculado de forma assíncrona em relação à execução de transações. Além disso, a camada de execução precisa ser capaz de fornecer sinais de retroalimentação à camada de consenso para ajustar dinamicamente o ritmo das propostas de blocos.

Além disso, devido às características de pipeline do Gravity SDK, a camada de execução deve ser capaz de lidar com transações não executáveis nas propostas de blocos, pois a memória não pode verificar rigorosamente a validade de qualquer transação devido ao acesso ao estado mundial mais recente: a execução pode ainda não ter sido concluída. Ao mesmo tempo, os resultados da execução não devem bloquear a geração de blocos subsequentes, pois, após a paralelização do consenso de blocos com o consenso de estado, a camada de execução se torna um reator para o fluxo de propostas de blocos, podendo retornar os resultados de execução livremente nas fases subsequentes.

O protocolo GCEI especifica duas categorias de API:

· API da camada de consenso: essas APIs são implementadas pelo Gravity SDK para que a camada de execução responda às propostas de blocos do mecanismo de consenso e submeta o compromisso de estado.

· API da camada de execução: essas APIs devem ser implementadas pela camada de execução. O mecanismo de consenso usará essas APIs para validar diligentemente a proposta de transação antes de apresentá-la ao bloco, fluindo o bloco proposto e notificando a camada de execução do compromisso final de estado.

Do ponto de vista do ciclo de vida da transação, o protocolo GCEI define o seguinte:

1. check_txn (API da camada de execução)

· Entrada: recebe uma transação (GTxn) como entrada.

· Saída: retorna o endereço do remetente da transação, nonce e limite de gás.

Uso: este método é usado pelo mecanismo de consenso para realizar validação diligente antes de propor transações ao bloco. Este método pode ser chamado várias vezes para a mesma transação, por exemplo, quando a transação entra na memória, antes de ser proposta ao bloco e quando o compromisso de estado é finalizado.

2. submit_txn (API da camada de consenso)

Entrada: recebe uma transação (GTxn) da camada de execução.

Saída: retorna Result<()>, indicando se a transação foi adicionada com sucesso à memória.

Uso: a camada de execução pode usar este método para submeter transações à memória. O mecanismo de consenso, em seguida, propagará essa transação pela rede e formará um Quorum Store ao receber um lote de transações.

3. recv_ordered_block (API da camada de execução)

Entrada: recebe um ordered_block (do tipo BlockBatch), que contém transações ordenadas e metadados de blocos.

Saída: retorna Result<()>, indicando se a camada de execução conseguiu receber e aceitar o bloco.

Uso: assim que o mecanismo de consenso propõe um bloco, ele é enviado para a camada de execução para execução das transações. Este método permite que a camada de execução receba e processe o bloco proposto.

4. update_state_commitment (API da camada de consenso)

Entrada: compromisso de estado (StateCommitment) de um número de bloco específico.

Saída: retorna Result<()>, indicando se o compromisso de estado foi aceito com sucesso pelo mecanismo de consenso local.

Uso: após a camada de execução calcular o compromisso de estado, ele o enviará para a camada de consenso para a finalização, ou seja, para alcançar um consenso leve 2f+1 com outros validadores. Se o consenso do compromisso de estado estiver muito longe do progresso do bloco proposto, o controlador de pipeline ajustará o ritmo das propostas de blocos.

5. commit_block_hash (API da camada de execução)

Entrada: recebe um vetor de block_ids que representa os blocos que precisam ser submetidos.

Saída: retorna Result<()>, indicando se a operação foi bem-sucedida ou não.

Uso: quando o compromisso de estado é finalmente determinado, a camada de consenso notificará a camada de execução para submeter o hash do bloco ao armazenamento da blockchain.

Pipeline de blockchain

O Gravity SDK maximiza a utilização de recursos de hardware por meio de uma arquitetura de pipeline de cinco estágios, resultando em maior taxa de transferência e menor latência. O pipeline executa tarefas de forma intercalada entre diferentes blocos, e o gerenciador de pipeline usa um mecanismo de feedback para garantir que a blockchain avance de forma consistente. Os três primeiros estágios pertencem à camada de consenso, enquanto os dois últimos pertencem à camada de execução.

As fases são explicadas da seguinte forma:

· Fase 1: Propagação de transações: esta fase propaga transações de forma eficiente entre validadores, garantindo que as transações sejam incluídas de maneira oportuna e confiável durante a construção do bloco. O design desacopla a propagação de transações do mecanismo de consenso, seguindo as ideias de Narwhal & Tusk e Aptos, onde validadores compartilham continuamente lotes de transações, utilizando todos os recursos da rede para execução concorrente. Quando um lote de transações recebe uma assinatura ponderada 2f+1 (formando PoAv, ou prova de disponibilidade), garante-se que esse lote de transações seja armazenado por pelo menos f+1 validadores honestos, de modo que todos os validadores honestos possam recuperar essas transações para execução.

· Fase 2: Ordenação de metadados de blocos: esta fase estabelece uma ordem consistente e reconhecida de transações e metadados de blocos na rede. O mecanismo de consenso (AptosBFT) segue a regra de duas cadeias (2-chain rule) para fornecer blocos com tolerância a falhas bizantinas. Os blocos, em seguida, fluem para a fase de execução, prontos para processamento paralelo.

· Fase 3 (BSR): Execução paralela de transações: esta fase é parte da camada de execução, onde as transações são executadas em paralelo. Os resultados da execução serão passados para a fase de compromisso de estado.

· Fase 4: Compromisso de estado: esta fase finaliza as mudanças de estado causadas pela execução das transações e prepara o bloco para finalização. O compromisso de estado e a execução de transações são computados de forma assíncrona, garantindo que a execução do próximo bloco não seja bloqueada pelo compromisso de estado do bloco atual.

· Fase 5: Persistência de estado: esta fase persiste as alterações de estado comprometidas no armazenamento da blockchain. A raiz de estado final e os dados relacionados são armazenados no Gravity Store, que adota um mecanismo de armazenamento altamente otimizado, projetado para acesso rápido e confiável. Ao mesmo tempo, notifica a memória e o Quorum Store para limpar transações futuras que não poderão ser incluídas.

Módulos de Staking e Restaking

Construir uma blockchain Layer 1 de Prova de Participação (PoS) segura é uma tarefa complexa, especialmente quando depende apenas da estaca de Tokens específicos na cadeia. Essa abordagem pode enfrentar problemas de segurança econômica insuficiente em estágios iniciais, como flutuações de valor do Token ou baixa participação de validadores. Para resolver esse problema, o Gravity SDK oferece um módulo flexível de Staking e Restaking, projetado para aumentar a segurança da rede por meio de mecanismos de estaca locais e externos.

Uma das estratégias-chave do Gravity SDK é a introdução de protocolos de Restaking como EigenLayer e Babylon. Esses protocolos permitem que validadores reestacem ativos de outras redes maduras (como Ethereum e Bitcoin), aproveitando suas garantias de segurança existentes. Ao permitir que validadores coloquem em garantia os ativos dessas cadeias, o Gravity SDK consegue aumentar a segurança econômica da rede sem depender totalmente de Tokens locais. Essa abordagem não apenas fortalece a robustez da cadeia, mas também impulsiona a diversidade do ecossistema de validadores. O design do módulo de Staking é centrado na modularidade, e seu componente de Restaking possui alta flexibilidade, podendo facilmente se adaptar a novos protocolos de Restaking conforme o ecossistema da blockchain evolui.

Este módulo não apenas suporta ativos de Restaking, mas também suporta staking de tokens ERC20 personalizados na cadeia suportada, como o G Token no Ethereum. Os validadores podem participar do consenso ao estacar esses tokens permitidos, contribuindo para a segurança da rede. O direito de voto dos validadores é calculado com base no seu valor total em staking, incluindo tokens personalizados e ativos dos protocolos de reestaca. Esse cálculo é feito de acordo com a configuração específica da cadeia, garantindo que cada cadeia possa definir regras de staking e reestaca de forma flexível de acordo com suas necessidades.

O gerenciador de Epochs no mecanismo de consenso colabora diretamente com o módulo de Staking para calcular o peso do conjunto de validadores da próxima rodada. Ele obtém valores de staking da camada de execução, assegurando que o processo de consenso possa refletir com precisão a dinâmica mais recente de staking. Nesta arquitetura, ativos cross-chain (como ativos em staking provenientes do Ethereum) devem ser primeiro transferidos para a camada de execução antes de serem usados para calcular o valor total em staking dos validadores. A implementação do mecanismo de ponte é de responsabilidade da camada de execução, permitindo um tratamento mais flexível da comunicação cross-chain. As soluções possíveis incluem ponte PoS, provas de conhecimento zero sobre o estado da cadeia e mensagens cross-chain auto-inicializáveis embutidas.

Mais detalhes técnicos, design da API e uma descrição completa dos mecanismos de Staking e Restaking serão apresentados em documentos futuros.

Gravity Reth: camada de execução EVM do reator de fluxo de blocos

A integração da camada de execução da Ethereum Virtual Machine (EVM) na arquitetura do Gravity SDK trouxe desafios únicos, especialmente ao tirar proveito total das capacidades de seu motor de consenso em pipeline. Para alcançar integração sem costura e maximizar o potencial dessa arquitetura, precisamos implementar várias otimizações cruciais no cliente Ethereum de código aberto, reth. Essas otimizações transformam fundamentalmente o reth em Gravity reth, uma camada de execução otimizada em pipeline projetada para o motor de consenso em pipeline.

As arquiteturas de blockchain tradicionais processam blocos sequencialmente, garantindo que cada bloco seja totalmente validado e executado antes de propor o próximo bloco. No entanto, o Gravity SDK adota um mecanismo de consenso em pipeline, separando as várias fases do processamento de blocos para melhorar o desempenho. Essa mudança de paradigma introduz complexidade:

Transações inesperadas: em uma cadeia em pipeline, a memória não pode acessar o estado mundial mais recente, pois a execução do bloco anterior pode não ter sido concluída. Portanto, as transações incluídas na proposta de bloco podem não ser executáveis no momento da proposta, já que sua validade não pode ser rigorosamente verificada sem o estado mais recente.

Resultados de execução não bloqueantes: para evitar que o pipeline fique paralisado, os resultados da execução não devem bloquear a geração de blocos subsequentes. A camada de execução deve ser capaz de processar propostas de blocos assíncronas e retornar os resultados da execução em fases posteriores sem obstruir o processo de consenso. Para EVM, isso significa que é necessário redefinir o blockhash, eliminando a dependência do campo stateRoot no cabeçalho do bloco.

Para resolver esses problemas, introduzimos quatro otimizações-chave:

· Reator de fluxo de blocos (Block Stream Reactor, BSR): o BSR visa ajustar o reth ao fluxo de propostas de blocos em pipeline do Gravity SDK. Ele permite que a camada de execução consuma continuamente o fluxo de blocos propostos, funcionando como um reator de processamento assíncrono de blocos. O BSR estabelece um ciclo de feedback dinâmico com o mecanismo de consenso, combinando sinais de retroalimentação adequados. Esses sinais ajustam em tempo real a velocidade das propostas de blocos e da submissão de estado, dependendo da taxa de transferência e latência da camada de execução. Se a camada de execução atrasar devido a transações complexas ou limitações de recursos, o mecanismo de retroalimentação diminuirá a taxa de propostas de blocos para garantir a estabilidade do sistema.

· Desacoplamento da submissão de estado e execução de transações: a segunda otimização envolve separar o cálculo de submissão de estado da execução de transações. Ao desacoplar esses processos, realizamos a assíncrona da computação de submissão de estado, permitindo que a execução dos blocos subsequentes não precise esperar pela conclusão da submissão de estado do bloco atual. Redefinimos o blockhash, removendo a dependência do campo stateRoot no cabeçalho do bloco, garantindo que o cálculo da raiz de estado não bloqueie a geração de blocos subsequentes.

· Otimização da camada de armazenamento: na arquitetura em pipeline, o cache eficiente e a persistência de valores de estado de múltiplas versões e submissões de estado são essenciais. A terceira otimização foca em aprimorar a camada de armazenamento para atender a essas demandas sem introduzir gargalos. Através da otimização do mecanismo de armazenamento, garantimos que os dados de estado possam ser rapidamente gravados e recuperados com alta concorrência. Isso inclui a construção de um mecanismo de armazenamento de múltiplas versões e suporte para I/O assíncrono de APIs de armazenamento de banco de dados.

· EVM paralela: a última otimização envolve a execução paralela de transações dentro da EVM. Desenvolvemos o Grevm, um runtime EVM paralelo que acelera significativamente o processamento de transações ao executar transações em paralelo. O Grevm utiliza dicas de dependência de dados obtidas da simulação de transações para otimizar a execução paralela, reduzindo a reexecução de transações e aumentando a taxa de transferência.

Grevm (Gravity EVM) - execução de EVM paralela

Grevm é um projeto de código aberto, hospedado no GitHub (se ainda não estiver aberto, será aberto no futuro). Consulte seu README para mais informações.

Grevm (Gravity EVM) é um runtime de EVM paralela baseado em revm. O algoritmo do Grevm é inspirado no BlockSTM e é aprimorado pela introdução de um gráfico de dependência de dados obtido da simulação. Esse mecanismo torna o agendamento da execução paralela mais eficiente, minimizando a reexecução de transações.

Em nossos testes de benchmark, o Grevm é atualmente a implementação de EVM paralela de código aberto mais rápida. Para transações sem conflitos, o Grevm é 4,13 vezes mais rápido que a execução sequencial, alcançando uma taxa de 26,50 gigagas/s. Se simularmos uma latência de I/O de 100 μs do mundo real, sua velocidade é 50,84 vezes a da execução sequencial, com uma taxa de 6,80 gigagas/s. Esse salto de desempenho é atribuído à integração da execução paralela com operações de I/O assíncronas - a paralelização permite que as operações de I/O se sobreponham de forma eficiente, acelerando ainda mais o processo.

A ideia central do Grevm é aproveitar a dependência de dados entre transações para otimizar a execução paralela, usando conjuntos de leitura/gravação especulativos. Embora nem todas as dicas sejam completamente precisas, essas dicas baseadas em simulação costumam ser suficientemente práticas. Por exemplo, na rede Ethereum, com base no histórico de uso de gás, cerca de 30% das transações são simples transferências de Ether, e outros 25%-30% são transferências de tokens ERC20, que geralmente envolvem a leitura e escrita de um número limitado de contas e slots de armazenamento. Para essas transações, os resultados da simulação têm consistência precisa.

Com base nesses insights, desenvolvemos um framework de execução paralela em três estágios para o Grevm, como um trabalho subsequente do modelo Block-STM, incorporando dicas de dependência de dados obtidas da simulação de transações:

· Fase 1: Geração de dicas e pré-carregamento de estado - simula transações para coletar dicas de dependência e pré-aquecer o cache da memória. Esta fase pode ser executada em diferentes pontos no tempo, dependendo do design da blockchain. Por exemplo, quando novas transações chegam à memória, a simulação pode ser executada imediatamente para preparar as dicas de dependência antecipadamente.

· Fase 2: Análise de dependência - transforma as dicas de dependência coletadas na fase de simulação em um gráfico acíclico direcionado (DAG) que representa as relações de dependência entre transações. Esse DAG é utilizado para planejar a programação de transações na execução paralela subsequente.

· Fase 3: Execução paralela sob resolução de conflitos - utiliza um algoritmo BlockSTM modificado baseado em dependência DAG para executar transações em paralelo. O agendador não seleciona mais estritamente as transações de acordo com os números de sequência nas transações no bloco (ex. 1, 2, 3, ..., n), mas prioriza a ordenação das transações com base no DAG, minimizando conflitos e reduzindo a necessidade de reexecução.

Submissão assíncrona em lote de estado

A geração de compromissos de estado ainda é um gargalo crítico na pipeline da blockchain, devido à natureza sequencial da mercantilização. Cada cálculo de subárvore deve ser concluído antes que o compromisso de estado final possa ser gerado, resultando em atrasos significativos. Embora soluções existentes (como a paralelização em nível de conta do reth) introduzam algum grau de paralelização, ainda há muito espaço para otimização. No contexto da camada de execução do reator de fluxo de blocos (BSR) do Gravity reth, o compromisso de estado é desacoplado da execução de transações, permitindo que o cálculo do compromisso de estado seja adiado e processado em lote de forma assíncrona sem bloquear a execução.

Para resolver esses problemas, a estrutura proposta introduz as seguintes inovações-chave:

Cálculo assíncrono de hash em lote: aproveitando o desacoplamento do consenso de submissão de estado e execução de transações, essa estrutura implementa o cálculo assíncrono da submissão de estado. A atualização da raiz de estado é feita em lotes (por exemplo, calculada a cada 10 blocos) para reduzir a frequência do cálculo da raiz de estado. Esse método de processamento em lote permite uma eficiente computação de hash compartilhado de nós sujos, minimizando a sobrecarga de atualizações frequentes e reduzindo o custo computacional total. Para blocos pequenos, o processamento em lote pode aumentar significativamente a paralelização; para blocos grandes, pode reduzir os custos computacionais totais.

Totalmente paralelizado: esta estrutura estende a paralelização a toda a árvore de estados, e não apenas à árvore de contas única. Para nós, os nós marcados como "sujos", a estrutura usa um algoritmo de computação de estado paralelo, dividindo a árvore em subárvores independentes e processando essas subárvores em paralelo. Os resultados são agregados no nível superior para calcular eficientemente a raiz final. Essa abordagem garante que grandes blocos com um alto volume de transações e mudanças de estado possam tirar proveito total do multithreading, maximizando a taxa de transferência.

Raiz de estado de substituição rápida: para se adequar ao cabeçalho do bloco Ethereum e ao opcode BLOCKHASH (que requer acesso à raiz de estado dos 256 blocos mais recentes), redefinimos a raiz de estado. Em vez de depender de uma submissão de estado final (que não está disponível durante a execução da transação), calculamos a raiz de estado como a combinação do conjunto de mudanças no bloco e o hash da raiz de estado anterior. Esse método torna o cálculo da raiz de estado mais rápido, sem a necessidade de esperar que a submissão de estado completa seja concluída.

Gravity Store

Para atender à demanda de gerenciamento de grandes dados para blockchains de alto desempenho, o Gravity Store surge como uma camada de armazenamento otimizada de múltiplas versões. Baseado no design do reth, o reth já reduz o problema de expansão de estado ao separar o armazenamento de submissão de estado e dados de estado, enquanto reduz os custos de leitura e gravação de dados. No entanto, a camada de execução Gravity reth precisa de suporte adicional para processamento paralelo e submissão assíncrona de estado, levantando mais demandas técnicas.

Para resolver esses desafios, o Gravity Store propõe uma estrutura de árvore de múltiplas versões eficiente, especialmente projetada para nossa estrutura BSR (Block Stream Reactor). Essa estrutura de árvore suporta a gestão de múltiplas versões de atualizações de estado. Diferentemente da prática tradicional de atualizar o valor hash imediatamente após a modificação, o Gravity Store marca os nós modificados como "nós sujos", permitindo que o cálculo do hash seja processado de forma atrasada e em lote. Esse design permite a criação rápida de novas versões, consultas eficientes de dados em versões específicas e a limpeza de versões antigas abaixo de uma altura específica, melhorando significativamente o desempenho da gestão de estado da blockchain.

Estamos também pesquisando o desenvolvimento independente do mecanismo de armazenamento Gravity DB, cujo objetivo é fornecer uma camada de armazenamento otimizada para aplicações de blockchain, suportando operações de I/O totalmente assíncronas. O design desse mecanismo é inspirado no LETUS, um motor de banco de dados de estrutura de log de alto desempenho voltado para blockchain. Nosso principal desenvolvedor Richard, sendo um dos autores principais do LETUS, discutirá detalhadamente seu design em um artigo de blog que será publicado em breve.

Conclusão

Gravity Chain é uma blockchain de primeira camada de alto desempenho e compatível com EVM, projetada para atender às necessidades de escalabilidade e desempenho de aplicações web3 modernas. Combinando Gravity SDK, o motor de consenso AptosBFT em pipeline e a camada de execução Gravity reth impulsionada pelo Grevm, o Gravity alcança uma taxa de transferência de 1 gigagas por segundo, um tempo de confirmação sub-segundo para transações e segurança PoS baseada em mecanismos de reestaca. O design desses componentes técnicos fornece uma base sólida para criar blockchains L1 personalizadas ou soluções L2 mais eficientes para aplicações web3, especialmente adequadas para otimizar o uso de cadeias EVM.

Este artigo é uma submissão e não representa a opinião do BlockBeats