1. Pode o Consenso Corrigir Blockchains?

Os mecanismos de consenso garantem que cada computador na rede concorde sobre quais transações são consistentemente e seguramente validadas e adicionadas ao blockchain, com base em um conjunto de regras de consenso.

Cada blockchain tenta alcançar um equilíbrio em relação ao trilema do blockchain: equilibrar velocidade, segurança e descentralização. Os projetos muitas vezes só podem priorizar duas características à custa de uma terceira.

Mecanismos de consenso são essenciais para evitar que atores maliciosos consigam adulterar com sucesso a rede ou seus dados. Eles impedem gastos duplos e mantêm tudo sincronizado, garantindo que cada nó na blockchain produza a mesma sequência de transações para cada bloco.

Pense neles como as regras de um jogo descentralizado, orientando os participantes em direção a uma “verdade” unificada. Aqui está uma visão geral dos principais mecanismos de consenso:

Prova de Trabalho (PoW): Os mineiros resolvem quebra-cabeças complexos com poder computacional para adicionar blocos, e são recompensados com criptomoedas. É seguro, mas consome muita energia e é lento (por exemplo, Bitcoin, Ethereum pré-2022).

Prova de Participação (PoS): Os validadores apostam criptomoedas para terem a oportunidade de criar blocos. Este método é eficiente em termos de energia e mais rápido, mas pode favorecer participantes mais ricos (por exemplo, Ethereum pós-2022, Cardano).

Prova Delegada de Participação (DPoS): Os detentores de tokens votam em delegados para validar transações, oferecendo velocidade e escalabilidade, mas arriscando centralização (por exemplo, EOS, Tron).

Prova de Autoridade (PoA): Nós confiáveis validam com base na identidade, tornando-o rápido e eficiente, mas menos descentralizado (por exemplo, VeChain).

Apesar da promessa de descentralização trazida pelas blockchains, raramente estas se traduzem no desempenho esperado, especialmente para blue chips:

O Bitcoin tem uma média de 7 transações por segundo (TPS).

Ethereum pós-PoS atinge 15–30 TPS.

Visa, por outro lado, tem uma média diária de 1.700 TPS.

Estas lacunas desencadeiam atrasos, congestão e taxas elevadas, expondo desafios de escalabilidade.

1.2 Novos Modelos de Consenso

Emergentes Layer-1s (L1) como @Hyperliquidx,@Monad_xyz, e @Soniclabsestão levando a novos mecanismos de consenso especificamente projetados para resolver esses desafios, aumentando a velocidade, escalabilidade e impacto, ao mesmo tempo que promovem a confiança.

Este artigo oferece uma análise aprofundada de como esses projetos lidam com o trilema do blockchain, avançando o design de consenso. Aprofundamos o background de cada projeto, mecanismos de consenso, relação com o Ethereum, soluções de escalabilidade, aplicações práticas, abordagens de financiamento e governança, e desafios principais.

2 Hyperliquid

Hyperliquid é uma blockchain L1 construída para negociação descentralizada de alta velocidade e baixo custo. Divide-se em dois pilares:

HyperCore: um motor on-chain para futuros perpétuos e livros de ordens à vista com finalidade de um bloco.

HyperEVM: uma plataforma de contratos inteligentes compatível com Ethereum.

Enquanto as L1s tradicionais enfrentam compensações entre descentralização, desempenho e acessibilidade, o Hyperliquid procura superar esses desafios ao oferecer um ecossistema de negociação de alto desempenho totalmente on-chain.

O HyperCore pode processar até 200.000 ordens por segundo, um pico teórico definido para aumentar com as atualizações de software do nó.

O HyperEVM introduz a plataforma de contratos inteligentes da Ethereum no Hyperliquid, oferecendo a liquidez e ferramentas financeiras do HyperCore como recursos abertos.

Com HyperCore e HyperEVM, a equipa visa permitir uma interação contínua entre aplicações descentralizadas (dApps) e componentes de blockchain sem sacrificar a eficiência ou a experiência do utilizador.

2.1 Mecanismo de Consenso

Inicialmente, a Hyperliquid empregou o algoritmo de consenso Tendermint. No entanto, uma solução mais avançada era necessária para suportar melhor a negociação de alta frequência e alcançar uma maior capacidade de transações.

Para resolver este problema, a Hyperliquid desenvolveu um mecanismo de consenso chamado HyperBFT. Este sistema híbrido combina PoS com Tolerância a Falhas Bizantinas (BFT) e é otimizado para alta capacidade, baixa latência e segurança robusta.

O modelo PoS é baseado no protocolo HotStuff, onde os validadores geram blocos ao apostar$HYPE tokens. A abordagem híbrida do HyperBFT é mais eficiente em termos energéticos do que os métodos tradicionais de PoW, mantendo uma segurança robusta.

2.2 Escalabilidade e Velocidade

O HyperBFT alcança uma finalidade mediana de 0,2 segundos e latência inferior a 0,9 segundos. O livro de ordens on-chain imita a precisão da troca centralizada, suportando alavancagem de 50x, negociação com um clique e stop-loss.

Hyperliquid destaca-se em cenários de alto débito, processando 200.000 TPS simultaneamente sem shard. Atualmente, isso é limitado principalmente pela latência de rede e dispersão de validadores.

2.3 Desafios

Baixo número de validadores (segurança): A Hyperliquid é relativamente centralizada, com apenas 16 validadores em comparação com a vasta rede de mais de 800k validadores da Ethereum. Eles têm como objetivo expandir o seu conjunto de validadores à medida que a rede cresce, alinhando-se com o seu objetivo de descentralização.

Resiliência não testada contra grandes ciberataques, levantando questões sobre a sua descentralização e robustez a longo prazo. Esta centralização representa riscos de segurança, especialmente no que diz respeito aos 2,3 mil milhões de dólares.$USDCna ponte, alvo de uma tentativa de hacking em 2024.

Impacto da centralização: Em março de 2025, a Hyperliquid enfrentou um incidente com o $JELLYtoken. Um trader manipulou o sistema de liquidação da plataforma criando três contas e assumindo posições alavancadas: duas longas totalizando $4.05 milhões e uma curta de $4.1 milhão em $JELLYfuturos. Isso levou a um pico de preços de 400% e o trader se autoliquidou, causando à vault da Hyperliquid assumir uma posição vendida de $6 milhões. Isso resultou em perdas não realizadas para os provedores de liquidez, estimadas entre $700.000 e $10 milhões. No entanto, após a intervenção da Hyperliquid, a vault obteve um lucro de $700.000, já que a Hyperliquid acabou por retirar a listagem$JELLYcontrato, provocando debates sobre descentralização e transparência na governação.

Riscos de negociação de alta alavancagem: em 13 de março de 2025, uma baleia liquidou$ETHposições longas através de negociação de alta alavancagem, resultando numa perda de aproximadamente $4 milhões na Vault HLP. Tais eventos destacam a vulnerabilidade da plataforma à manipulação de mercado e a necessidade de estratégias robustas de gestão de risco.

Competição: O código fechado da Hyperliquid e a ausência de penalidades automáticas para validadores limitam a transparência e a resiliência. A concorrência de plataformas de alto rendimento como Solana, novos L1s como Monad e MegaETH e DEXs avançadas como dYdX apresenta desafios.

Escalabilidade: Hyperliquid é projetado para escalabilidade, lidando com até 200.000 TPS com finalidade em sub-segundo. No entanto, condições extremas como negociações alavancadas massivas podem introduzir desafios como tensão de liquidez ou atrasos de coordenação de validadores.

3. Monad

Monad é um L1 compatível com EVM para escalabilidade e desempenho, utilizando execução paralela e MonadBFT.

O Monad visa até 10k TPS com blocos produzidos a cada 500 milissegundos e finalizados em um segundo. Promove a descentralização ao enfrentar os gargalos da Ethereum (por exemplo, velocidades lentas, taxas elevadas e escalabilidade limitada). Sua testnet foi lançada em 19 de fevereiro de 2025, com especulações sobre o lançamento da mainnet no terceiro ou quarto trimestre de 2025.

3.1 Mecanismo de Consenso

A arquitetura do Monad centra-se no seu mecanismo de consenso personalizado MonadBFT, uma evolução otimizada do protocolo BFT HotStuff.

Integra a execução em pipeline e a comunicação eficiente para se distinguir dos designs tradicionais de blockchain.

MonadBFT: Este algoritmo transforma o processo de três fases do HotStuff em duas, melhorando a velocidade do validador. Os validadores alternam como líderes: um propõe um bloco e reúne votos anteriores num certificado de quórum (QC), uma prova de consenso para certificar o bloco anterior. Um mecanismo de timeout mantém a rede robusta se um líder falhar, garantindo segurança em ambientes parcialmente síncronos.

Execução Paralela: A execução paralela refere-se à capacidade de processar várias tarefas ou transações simultaneamente, em vez de uma de cada vez. Os nós concordam primeiro com a ordem das transações e, em seguida, executam as transações em paralelo em várias threads usando uma abordagem otimista. Isso garante consistência com resultados sequenciais, ao mesmo tempo que aumenta significativamente o throughput.

PoS: Os validadores apostam tokens para participar, garantindo a rede através de incentivos econômicos. Este sistema PoS equilibra velocidade e segurança, com ativos apostados desencorajando ações maliciosas.

O MonadBFT oferece finalidade escalável e confiável para dApps em tempo real, reduzindo a sobrecarga de comunicação,

O diagrama abaixo ilustra o processo de pipeline do MonadBFT, mostrando como os validadores (Alice, Bob, Charlie, David, etc.) propõem, votam e finalizam blocos (N, N+1, N+2, etc.) em rondas sobrepostas.

Cada bloco avança por etapas: proposto, votado e finalizado. Os validadores rotacionam a liderança, produzindo QCs para certificar blocos.

3.2 Escalabilidade e Velocidade

Monad combina a eficiência do MonadBFT com a execução paralela, permitindo que supere os L1 tradicionais lidando com transações em paralelo, evitando o sharding e garantindo uma finalização rápida. Sua capacidade teórica poderia ser ainda maior do que a mencionada acima (10k TPS, finalização em sub-segundo), embora os resultados do mundo real dependam da latência da rede e da distribuição dos validadores.

3.3 Desafios

Complexidade de Execução: A execução paralela otimista do Monad poderia levar a inconsistências, rollbacks ou vulnerabilidades (por exemplo, exploits de casos limite). Suas funcionalidades avançadas (MonadBFT e execução paralela) adicionam complexidade, aumentando os custos de desenvolvimento e manutenção, especialmente para equipes menores. Isso pode dificultar o crescimento e a segurança, desafiando equipes menores e tornando-o preferido por equipes com mais recursos e experiência de desenvolvimento.

Latência da Rede: TPS do mundo real e finalidade dependem da distribuição de validadores e latência, correndo o risco de baixo desempenho.

Escala não testada: Pré-mainnet, a alegação de 10.000 TPS do Monad permanece não comprovada, com possíveis bugs ou gargalos.

Concorrência: Plataformas de alto rendimento como Sonic, Arbitrum e Solana, poderiam desafiar a adoção por parte dos desenvolvedores e dos utilizadores.

Curva de Aprendizagem: Apesar da compatibilidade com EVM, os sistemas exclusivos do Monad (MonadBFT, MonadDB) podem atrasar a integração de desenvolvedores.

Centralização: O controle inicial da Fundação e um modelo de token concentrado poderiam centralizar o poder, ameaçando a descentralização e segurança a longo prazo.

4. Sonic

Sonic é um L1 compatível com EVM para alta taxa de transferência e finalidade de transação em sub-segundo, evoluindo a partir do ecossistema Fantom Opera.

Sonic introduz melhorias operacionais notáveis: seu mais recente protocolo de consenso, SonicCS 2.0, alcança um aumento de 2x na velocidade de consenso e uma redução de 68% no uso de memória por época (de 420 MB para 135 MB), reduzindo as exigências de recursos para validadores e melhorando a escalabilidade.

Estas atualizações abordam vários desafios da blockchain:

Processamento lento de transações

Altos custos operacionais

Ecossistemas fragmentados

Com uma identidade reformulada, a Sonic incentiva os desenvolvedores redistribuindo até 90% das taxas de transação da rede através do seu programa de Monetização de Taxas (FeeM), promovendo a criação e adoção de dApps.

4.1 Mecanismo de Consenso

O Consenso Lachesis da Sonic combina Gráficos Acíclicos Direcionados (DAGs) com Tolerância a Falhas Bizantinas Assíncronas (ABFT), avançando além da base da Fantom Opera.

ABFT: permite aos validadores processar transações e trocar blocos de forma assíncrona. Isso elimina os atrasos sequenciais dos sistemas baseados em Tolerância a Falhas Bizantinas Práticas (PBFT), aumentando a capacidade e a resiliência.

DAG: As transações são representadas como vértices e as dependências como arestas DAG, permitindo adições de blocos concorrentes. Isso acelera a validação em comparação com os designs de blockchain lineares, formando uma estrutura em forma de teia interconectada em vez de uma única cadeia.

PoS: Validadores apostam um mínimo de 500k $S tokens para participar, agrupando transações em blocos de eventos dentro de DAGs locais. O consenso é alcançado quando os validadores suficientes confirmam esses blocos como "raízes" na cadeia principal, alcançando uma finalização em sub-segundo. Este sistema de PoS equilibra velocidade, segurança e descentralização, com tokens apostados dissuadindo má conduta.

A figura abaixo ilustra um DAG para um nó específico:

Os eventos laranja representam eventos de líder candidato

Eventos amarelos indicam eventos de líder comprometidos.

Os eventos posicionados entre esses líderes podem ser sequenciados em uma cadeia, permitindo a extração de uma lista de transações para construir um bloco.

4.2 SonicCS 2.0 - Sua mais recente atualização do Mecanismo de Consenso

Recentemente, a Sonic atualizou o seu mecanismo de consenso com o SonicCS 2.0, introduzido em 27 de março de 2025. Este protocolo utiliza uma abordagem baseada em DAG com eleições sobrepostas, reduzindo o esforço computacional e a utilização de memória em 68%. Experimentos com 200 épocas de dados da mainnet da Sonic demonstram um aumento médio de velocidade de 2,04x (variando de 1,37x a 2,62x) e uma eficiência significativa de memória, reforçando a capacidade da Sonic de processar mais de 10k TPS com finalidade em sub-segundo. O SonicCS 2.0 está prestes a ser lançado na mainnet em breve, com um relatório técnico detalhado a caminho.

4.3 Escalabilidade e Velocidade

O consenso híbrido Lachesis da Sonic combina a adaptabilidade do DAG com a integridade do ABFT, proporcionando uma finalidade de transação rápida e segura sem necessidade de fragmentação. Este design suporta escalabilidade contínua à medida que a demanda da rede cresce.

SonicCS 2.0 pode potencialmente impulsionar o desempenho da rede principal Sonic mais perto das estimativas teóricas de 396.825 TPs. No entanto, é bom salientar que os resultados práticos dependem da latência da rede e da distribuição dos validadores. De acordo com @AndreCronjetecho TPS máximo em tempo real medido no Sonic já era cerca de 5.140, o que é bastante impressionante.

O Sonic é totalmente compatível com a EVM, otimizando o desempenho dentro deste framework em vez de o substituir por uma máquina virtual distinta. As operações vetorizadas do SonicCS 2.0 e as eleições sobrepostas melhoram a eficiência do validador e o desempenho do dApp.

Fonte: Chainspect

4.4 Desafios

Complexidade do Consenso: Sob carga elevada, o mecanismo de consenso do Sonic pode introduzir dependências intrincadas ou atrasos de validação, arriscando ineficiências ou exploits.

Adaptação do Desenvolvedor: Embora compatível com EMV, as funcionalidades avançadas do Sonic (por exemplo, a votação vetorizada do SonicCS 2.0) podem exigir que os desenvolvedores ajustem os fluxos de trabalho, potencialmente retardando a adoção.

Latência de rede: Finalidade sub-segundo e 10k TPS dependem da distribuição de validadores e da latência, o que poderia degradar o desempenho no mundo real.

Escala não testada: Antes do lançamento da mainnet Pre-SonicCS 2.0, a reivindicação de 10k TPS carece de validação completa no mundo real e possíveis gargalos ou bugs ainda estão por surgir.

Dominância L2: As soluções L2 da Ethereum (por exemplo, Optimism, zkSync) oferecem desempenho semelhante a custos mais baixos, aproveitando vasta liquidez e ecossistemas de desenvolvedores. A ponte Sonic Gateway da Sonic ajuda na interoperabilidade, mas competir como um L1 independente continua sendo um desafio.

Centralização: Os 500,000$SA exigência de staking e o controle antecipado pela Sonic Foundation arriscam centralizar o poder, potencialmente alienando os usuários focados na descentralização e enfraquecendo a segurança se a distribuição de tokens favorecer os insiders.

5. Tabela de Comparação

6. Aproveitando o Ecossistema do Ethereum

Hyperliquid, Monad e Sonic tiram partido da compatibilidade com o EVM, permitindo aos programadores implementar dApps numa infraestrutura de alta velocidade utilizando ferramentas familiares e contratos inteligentes. Isto proporciona transações de baixo custo e elevada capacidade com segurança robusta, aproveitando o ecossistema da Ethereum sem reescrever código.

Alimentando Diversas dApps

Estas L1s oferecem tempos de confirmação inferiores a um segundo e uma capacidade de TPS elevada, tornando-as ideais para uma ampla gama de dApps que podem ser implantadas sem problemas.

A Hyperliquid oferece transações DEX rápidas e seguras com um livro de ordens on-chain, combinando a precisão da troca centralizada com alta escalabilidade.

Sonic adiciona finalidade rápida para aplicações DeFi eficientes, garantindo transações em menos de um segundo.

Monad melhora isso com 10.000 TYPS, tempos de bloco de 1 segundo e finalidade de um único slot.

Além do Web3: Potencial Empresarial

A velocidade e a escalabilidade destas redes posicionam-nas para uso empresarial em finanças, cadeia de abastecimento e pagamentos. Os retalhistas podem lidar com pagamentos de alto volume a custos reduzidos, enquanto os prestadores de cuidados de saúde garantem dados de pacientes em tempo real com compatibilidade com sistemas existentes.

7. L2 como a resposta da Ethereum para o problema de escalabilidade

E quanto aos L2s?

Por que precisamos de novas blockchains L1 com mecanismos de consenso sofisticados em primeiro lugar?

Soluções L2 como Arbitrum, Optimism e Base impulsionaram a escalabilidade do L1 processando transações off-chain. Arbitrum atinge até 4.000 TPS, enquanto o Base visa milhares com Flashblocks de 0,2 segundos até meados de 2025.

No entanto, as L2s dependem da segurança e finalidade do Ethereum, herdando as suas características e limitações. Por exemplo, a necessidade de provas de fraude em sistemas como rollups otimistas pode levar a atrasos, uma vez que as transações nas cadeias OP Stack da Optimism se tornam finalizadas quando os seus dados são incluídos num bloco Ethereum finalizado. Isto pode afetar a experiência do utilizador, especialmente para aplicações que requerem finalidade rápida das transações.

Novas blockchains L1 como Hyperliquid, Monad e Sonic abordam essas limitações com mecanismos avançados de consenso. Ao contrário dos L2s, esses L1s têm um alto desempenho sem depender da infraestrutura do Ethereum, evitando complexidades como provas de fraude ou gargalos de tempo de bloco L1.

No entanto, a construção de novas L1s introduz riscos, desafiando potencialmente a descentralização ou aumentando os custos. Embora as blockchains L1 forneçam uma camada base de segurança e descentralização, muitas vezes enfrentam desafios de escalabilidade devido aos mecanismos de consenso e limitações de tamanho de bloco. Além disso, não possuem o desempenho histórico e a confiança do Ethereum.

A necessidade de desenvolver novas blockchains L1 na presença de soluções L2 existentes é um tópico de discussão contínua no Twitter:

L2s facilitam a congestão da L1, mas vinculam a sua escalabilidade às restrições da Ethereum. Eles são tão rápidos quanto a Ethereum, mas isso não leva em consideração que a finalidade de todas as transações da L2 depende dos tempos de confirmação dos blocos da L1.

Ao mesmo tempo, novas L1s prometem independência e velocidade, mas devem provar que podem escalar de forma segura para bilhões de usuários.

A interação entre as soluções L1 e L2 levanta questões críticas sobre a arquitetura futura das redes blockchain.

Será que os desafios de escalabilidade das blockchains L1 podem ser eficazmente abordados através do desenvolvimento de novos mecanismos de consenso, ou é essencial a integração de soluções L2 apesar dos compromissos inerentes?

Estas considerações sublinham a necessidade de pesquisa contínua e diálogo dentro da comunidade blockchain para navegar pelas complexidades de escalabilidade, segurança e descentralização.

Conclusão e Alimento para o Pensamento

Um grande obstáculo no mercado atual é a liquidez fraca e rotativa, afetando tanto novos quanto existentes utilizadores. A atenção é baixa e de curto prazo, tornando ainda mais desafiante garantir uma quota de mercado em crescimento neste setor lotado.

Portanto, para impulsionar a adoção, é essencial priorizar as necessidades tanto dos desenvolvedores quanto dos utilizadores.

Mas sejamos honestos: a maioria dos utilizadores preocupa-se mais com a funcionalidade prática do que com a tecnologia subjacente. Eles querem uma experiência perfeita, com transações rápidas e baixas taxas que tornem a rede acessível, especialmente para microtransações.

A segurança também é não negociável: os utilizadores esperam salvaguardas robustas para proteger os seus ativos e dados, fomentando a confiança no sistema. E, claro, há necessidade de atividades na cadeia, que satisfaçam diferentes tipos de necessidades dos utilizadores.

Tanto os L1s como os L2s precisam lutar por estes interesses para se manterem relevantes. Em vez de se concentrarem exclusivamente na “melhor tecnologia” e tentarem “sobrevalorizar” os mecanismos de consenso da sua cadeia, também devem ser pragmáticos e focar-se em oferecer aos utilizadores e programadores a melhor rede para construir e utilizar as suas aplicações.

Para concluir, novos L1s, como Hyperliquid, Monad e Sonic, abordam as dependências do L2, mas enfrentam desafios, como visto no pequeno pool de validadores do Hyperliquid, onde apenas quatro nós aumentaram os riscos de colusão, expondo vulnerabilidades. Expandir validadores, garantir pontes e implementar limites de aprovação mais altos, monitorização em tempo real e deteção de anomalias pode reforçar a resiliência. Equilibrar segurança, escalabilidade e descentralização através de uma gestão proativa de riscos é fundamental para fomentar a confiança e sustentar o crescimento do DeFi, instando os utilizadores a escrutinar as salvaguardas da plataforma e os programadores a priorizar defesas robustas.

Deixe os "devs fazerem algo": deixe-os fazer o pesado peso técnico e definir o trade-off dos mecanismos de consenso, alimentando a busca pelo equilíbrio.

Além disso, não nos esqueçamos dos utilizadores: aqueles que simplesmente apreciam aplicações responsivas, eficientes, descentralizadas e seguras.

Estes novos designs estão a empurrar os limites do que os modelos de consenso podem alcançar em termos de ritmo, segurança e interoperabilidade.

Será interessante ver como evoluem e como se entrelaçam uma vez que o Monad (e outros concorrentes) seja lançado.

Aviso legal:

1. Este artigo é reimpresso de [GateCastle Labs]. Todos os direitos de autor pertencem ao autor original [@cryptorinweb3]. Se houver objeções a esta reimpressão, por favor contacte o Gate Aprenderequipa e eles tratarão do assunto prontamente.
2. Aviso de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. A equipa do Gate Learn faz traduções do artigo para outras línguas. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, a menos que seja mencionado.