1. Pode Consenso Corrigir Blockchains?

Mecanismos de consenso garantem que cada computador na rede concorda 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: equilibrando velocidade, segurança e descentralização. Os projetos muitas vezes só podem priorizar dois recursos em detrimento de um terceiro.

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, direcionando os participantes para uma “verdade” unificada. Aqui está uma visão geral dos principais mecanismos de consenso:

Prova de Trabalho (PoW): Os mineradores 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): Validadores apostam criptomoedas para ter a chance 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 correndo o risco de 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 isso se traduz no desempenho esperado, especialmente para blue chips:

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

Ethereum pós-Proof-of-Stake atinge 15-30 TPS.

Visa, por outro lado, tem uma média de 1.700 TPS diariamente.

Essas lacunas causam atrasos, congestionamentos e altas taxas, expondo desafios de escalabilidade.

1.2 Novos Modelos de Consenso

Emergindo 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 fomentam a confiança.

Este artigo oferece uma análise aprofundada de como esses projetos abordam o trilema do blockchain, avançando ainda mais no design de consenso. Nós mergulhamos no histórico de cada projeto, nos mecanismos de consenso, na relação com o Ethereum, nas soluções de escalabilidade, nas aplicações práticas, nas abordagens de financiamento e governança, e nos principais desafios.

2 Hyperliquid

Hyperliquid é uma blockchain L1 construída para negociações descentralizadas de alta velocidade e baixo custo. Ela se divide em dois pilares:

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

HyperEVM: uma plataforma de contrato inteligente compatível com o Ethereum.

Enquanto os L1s tradicionais enfrentam trade-offs entre descentralização, desempenho e acessibilidade, a Hyperliquid procura superar esses desafios ao oferecer um ecossistema de negociação totalmente on-chain de alta performance.

HyperCore pode processar até 200.000 pedidos por segundo, um pico teórico definido para crescer com atualizações de software de nó.

HyperEVM introduz a plataforma de contrato inteligente do Ethereum para o Hyperliquid, oferecendo a liquidez do HyperCore e ferramentas financeiras como recursos abertos.

Com HyperCore e HyperEVM, a equipe tem como objetivo permitir a interação perfeita entre aplicativos descentralizados (dApps) e componentes de blockchain sem sacrificar eficiência ou experiência do usuário.

2.1 Mecanismo de Consenso

Inicialmente, o 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 taxa de transações.

Para resolver isso, 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 taxa de transferência, baixa latência e segurança robusta.

O modelo PoS é baseado no protocolo HotStuff, onde os validadores geram blocos por meio de staking $HYPE tokens. A abordagem híbrida do HyperBFT é mais eficiente em termos de energia do que os métodos tradicionais de PoW, ao mesmo tempo que mantém uma segurança robusta.

2.2 Escalabilidade e Velocidade

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 em um clique e stop-losses.

O Hyperliquid destaca-se em cenários de alto rendimento, processando 200.000 TPS simultaneamente sem fragmentação. Atualmente, isso é limitado principalmente pela latência da rede e pela dispersão dos validadores.

2.3 Desafios

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

Resiliência não testada contra grandes ciberataques, levantando questões sobre sua descentralização e robustez a longo prazo. Essa centralização representa riscos de segurança, especialmente em relação aos $2.3 bilhões $USDCna ponte, alvo de uma tentativa de hack 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ões em$JELLYfuturos. Isso levou a um aumento de preços de 400% e o trader se liquidou, fazendo com que o cofre da Hyperliquid assumisse uma posição curta 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, o cofre obteve um lucro de $700.000, já que a Hyperliquid acabou por retirar a listagem $JELLYcontrato, desencadeando debates sobre descentralização e transparência na governança.

Riscos de negociação de alta alavancagem: em 13 de março de 2025, uma baleia liquidou$ETHposições longas através de negociações de alta alavancagem, resultando em uma 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.

Concorrência: 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, L1s emergentes como Monad e MegaETH e DEXs avançados como dYdX apresenta desafios.

Escalabilidade: Hyperliquid é projetado para escalabilidade, lidando com até 200.000 TPS com finalidade de 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 do validador.

3. Monad

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

Monad visa até 10k TPS com blocos produzidos a cada 500 ms e finalizados em um segundo. Ele promove a descentralização ao lidar com os gargalos do Ethereum (por exemplo, velocidades lentas, taxas altas e escalabilidade limitada). Sua testnet foi lançada em 19 de fevereiro de 2025, com especulações sobre o lançamento da mainnet no T3-T4 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 execução em pipeline e comunicação eficiente para se distinguir dos designs tradicionais de blockchain.

MonadBFT: Esse algoritmo transforma o processo de três fases do HotStuff em duas, melhorando a velocidade do validador. Os validadores se revezam como líderes: um propõe um bloco e reúne votos anteriores em um 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 com a ordem das transações primeiro e, em seguida, executam transações simultaneamente em várias threads usando uma abordagem otimista. Isso garante consistência com resultados sequenciais, enquanto aumenta significativamente o throughput.

PoS: Validadores apostam tokens para participar, garantindo a rede por meio de incentivos econômicos. Esse sistema de PoS equilibra velocidade e segurança, com ativos apostados desencorajando ações maliciosas.

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 rodadas sobrepostas.

Cada bloco progride por estágios: 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 L1s tradicionais ao lidar com transações de forma concorrente, evitando o particionamento e garantindo rapidez na finalização. Sua capacidade teórica poderia ser maior do que mencionado acima (10k TPS, finalização em sub-segundo), embora os resultados do mundo real dependam da latência da rede e da dispersã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 de Rede: TPS do mundo real e finalidade dependem da distribuição e latência dos validadores, correndo o risco de baixo desempenho.

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

Competição: Plataformas de alto rendimento rivais como Sonic, Arbitrum e Solana, poderiam desafiar a adoção de desenvolvedores e usuários.

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

Centralização: O controle inicial da Foundation 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 capacidade 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 demandas de recursos para validadores e melhorando a escalabilidade.

Essas atualizações abordam vários desafios de 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 por meio de seu programa de Monetização de Taxas (FeeM), fomentando 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 que os validadores processem transações e troquem 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 de processamento e a resiliência.

DAG: As transações são representadas como vértices e as dependências como arestas de DAG, permitindo adições de blocos concorrentes. Isso acelera a validação em comparação com os designs de blockchain linear, 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 validadores suficientes confirmam esses blocos como "raízes" na cadeia principal, alcançando finalidade em sub-segundos. Este sistema PoS equilibra velocidade, segurança e descentralização, com tokens em jogo dissuadindo conduta indevida.

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

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

Sonic recentemente atualizou seu mecanismo de consenso com o SonicCS 2.0, introduzido em 27 de março de 2025. Este protocolo alavanca uma abordagem baseada em DAG com eleições sobrepostas, reduzindo o esforço computacional e o uso de memória em 68%. Experimentos com 200 épocas de dados da mainnet do Sonic demonstram um aumento médio de 2.04x na velocidade (variando de 1.37x a 2.62x) e eficiência significativa de memória, reforçando a capacidade do Sonic de processar mais de 10k TPS com finalidade em sub-segundo. O SonicCS 2.0 está pronto para 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 mescla a adaptabilidade do DAG com a integridade do ABFT, proporcionando finalidade de transação rápida e segura sem a 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 do Sonic mais perto das estimativas teóricas de 396.825 TPs. No entanto, é bom ressaltar que os resultados práticos dependem da latência da rede e da distribuição dos validadores. De acordo com @AndreCronjetecho máximo de TPS em tempo real medido no Sonic foi de aproximadamente 5.140, o que é bastante impressionante.

O Sonic é totalmente compatível com o EVM, otimizando o desempenho dentro deste framework em vez de substituí-lo por uma máquina virtual distinta. As operações vetorizadas do SonicCS 2.0 e as eleições sobrepostas aprimoram 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 explorações.

Adaptação do Desenvolvedor: Embora compatível com EMV, os recursos avançados 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 de sub-segundo e 10k TPS dependem da distribuição de validadores e latência, o que pode 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 total no mundo real e possíveis gargalos ou bugs ainda não surgiram.

Domínio L2: As soluções L2 da Ethereum (por exemplo, Optimism, zkSync) oferecem desempenho semelhante a custos mais baixos, aproveitando a vasta liquidez e ecossistemas de desenvolvedores. O Sonic Gateway bridge da Sonic auxilia na interoperabilidade, mas competir como um L1 independente continua sendo um desafio.

Centralização: As 500.000 $Sa exigência de staking e o controle antecipado pela Sonic Foundation correm o risco de 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 aproveitam todos a compatibilidade com EVM, permitindo que os desenvolvedores implantem dApps em infraestrutura de alta velocidade usando ferramentas familiares e contratos inteligentes. Isso proporciona transações de baixo custo e alta taxa de transferência com segurança robusta, aproveitando o ecossistema do Ethereum sem reescrever o código.

Alimentando Diversos dApps

Esses L1s oferecem tempos de confirmação de sub-segundo e alta capacidade de TPS, tornando-os ideais para uma ampla gama de dApps que podem ser implantados de forma transparente.

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 slot único.

Além do Web3: Potencial Empresarial

A velocidade e escalabilidade dessas redes as posicionam para uso empresarial em finanças, cadeia de suprimentos e pagamentos. Os varejistas podem lidar com pagamentos em grande volume a custos reduzidos, enquanto os provedores de saúde garantem dados de pacientes em tempo real com compatibilidade com sistemas existentes.

7. L2 como a resposta do Ethereum para a questão da 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 alcança até 4.000 TPS, enquanto o Base visa milhares com Flashblocks de 0,2 segundos até meados de 2025.

No entanto, os L2s dependem da segurança e finalidade do Ethereum, herdando 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 do Optimism se tornam finalizadas quando seus dados são incluídos em um bloco Ethereum finalizado. Isso pode afetar a experiência do usuário, especialmente para aplicativos que exigem finalidade de transação rápida.

Novas blockchains L1 como Hyperliquid, Monad e Sonic abordam essas limitações com mecanismos de consenso avançados. Ao contrário dos L2s, esses L1s são altamente eficientes 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 novos L1s introduz riscos, potencialmente desafiando a descentralização ou aumentando os custos. Enquanto as blockchains L1 fornecem uma camada base de segurança e descentralização, frequentemente 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ínuo no Twitter:

L2s facilitam a congestão da L1, mas atrelam sua escalabilidade às restrições do Ethereum. Eles são tão rápidos quanto o 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 do bloco da L1.

Ao mesmo tempo, novos L1s prometem independência e rapidez, mas eles 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.

Os desafios de escalabilidade das blockchains L1 podem ser efetivamente abordados por meio do desenvolvimento de novos mecanismos de consenso, ou a integração de soluções L2 é essencial apesar de suas compensações inerentes?

Essas considerações destacam a necessidade de pesquisas contínuas e diálogo dentro da comunidade blockchain para navegar pelas complexidades de escalabilidade, segurança e descentralização.

Conclusão e Reflexão

Um grande obstáculo no mercado atual é a liquidez fina e rotativa, afetando tanto novos quanto existentes usuários. A atenção é baixa e de curto prazo, tornando ainda mais desafiador garantir uma participação crescente neste setor lotado.

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

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

A segurança também é inegociável: os usuários esperam salvaguardas robustas para proteger seus ativos e dados, fomentando a confiança no sistema. E, é claro, precisa haver atividades na cadeia, que satisfaçam diferentes tipos de necessidades dos usuários.

Tanto os L1s quanto os L2s precisam lutar por esses interesses para permanecer relevantes. Em vez de se concentrar exclusivamente na "melhor tecnologia" e tentar "super melhorar" os mecanismos de consenso de sua cadeia, eles também devem ser pragmáticos e focar em oferecer aos usuários e desenvolvedores a melhor rede para construir e usar suas aplicações.

Para concluir, novos L1s, como Hyperliquid, Monad e Sonic, abordam as dependências do L2, mas enfrentam desafios, como visto na pequena pool de validadores da Hyperliquid, onde apenas quatro nós aumentaram os riscos de colusão, expondo vulnerabilidades. Expandir os validadores, garantir pontes e implementar limiares de aprovação mais altos, monitoramento em tempo real e detecção de anomalias pode reforçar a resiliência. Equilibrar segurança, escalabilidade e descentralização por meio de gerenciamento proativo de riscos é fundamental para fomentar a confiança e sustentar o crescimento do DeFi, instando os usuários a escrutinar as salvaguardas da plataforma e os desenvolvedores a priorizar defesas robustas.

Deixe os desenvolvedores fazerem algo: deixe-os lidar com o peso técnico e definir o trade-off dos mecanismos de consenso, impulsionando a busca pelo equilíbrio.

Além disso, não nos esqueçamos dos usuários: aqueles que simplesmente desfrutam de aplicativos responsivos, eficientes, descentralizados e seguros.

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

Será interessante ver como eles evoluem e como se entrelaçam uma vez que o Monad (e outros concorrentes) entram em operação.

Aviso Legal:

1. Este artigo é reproduzido a partir de [Castle Labs]. Todos os direitos autorais pertencem ao autor original [@cryptorinweb3]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Isenção de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. A equipe Gate Learn faz traduções do artigo para outros idiomas. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, a menos que mencionado.