Análise aguda do roteiro do "Mercado de capitais da Solana": um "show de imitação" para alcançar a Hyperliquid

🚀 Prefácio: os pros da SOLANA estão em reunião

Recentemente, aconteceu algo muito interessante no ecossistema Solana. Incluindo a Fundação Solana, Anza, Jito Labs e outros pros, reuniram-se para lançar um roteiro técnico chamado “Internet Capital Markets(Internet Capital Markets, ICM)”. A ideia central deste roteiro é “Application Controlled Execution(Application Controlled Execution, ACE)”, em termos simples, é permitir que as aplicações on-chain tenham o direito de ordenação de transações de forma autônoma em milissegundos, criando uma “Wall Street on-chain” descentralizada.

No entanto, é interessante notar que, ao ler todo o roteiro, embora não mencione diretamente o Hyperliquid, o design está quase em todo o lado a direcionar-se para os pontos fortes do Hyperliquid. É como se a Solana estivesse a dizer: “O que você tem no Hyperliquid, nós também queremos ter, e queremos fazer melhor!”

É importante saber que a Hyperliquid ocupa uma posição dominante no mercado de contratos perpétuos em cadeia, com um volume de transações que chegou a representar cerca de 65% de todo o mercado descentralizado de contratos perpétuos. É evidente que, diante de concorrentes como este, a Solana não está disposta a ser superada pelos recém-chegados, e por isso lançou este roteiro ICM.

Então, o que é realmente esse “show de imitação”? A Solana pode realmente alcançar ou até superar a Hyperliquid? Hoje, vamos discutir este assunto em profundidade.

📋 ICM background and content

Quem está a liderar esta transformação?

Primeiro, vamos ver quem elaborou este roteiro. Os participantes são todos jogadores de peso do ecossistema Solana:

• Solana Foundation/Labs: Não é necessário dizer muito, o “pai” do Solana, responsável pela coordenação geral e desenvolvimento do protocolo central.
• Anza: uma empresa de desenvolvimento fundada por ex-membros da Solana Labs, um pouco como a ConsenSys do Ethereum. Eles assumiram muitas das principais tarefas técnicas neste roteiro, como o novo protocolo de consenso Alpenglow.
• Jito Labs: fornecedor de infraestrutura MEV na Solana, com grande influência, quase controla todo o fluxo MEV na Solana e detém o “poder de vida e morte”. Desta vez, eles lideraram a oferta do Block Assembly Marketplace (BAM) e outros esquemas de ordenação de transações.
• Multicoin Capital: uma famosa instituição de investimento em criptomoedas e também um dos primeiros apoiantes da Solana. Devido à posse de uma grande quantidade de SOL e participações em projetos do ecossistema, tem uma considerável influência na direção técnica.
• DoubleZero: Uma equipa focada em acelerar a comunicação na rede, oferecendo soluções de rede de fibra óptica dedicadas para melhorar a velocidade de comunicação entre os nós de validação da Solana.
• Drift: O projeto DEX de contratos perpétuos líder na Solana. Anteriormente, o Drift utilizava um modelo de correspondência off-chain, e, ao enfrentar o Hyperliquid completamente on-chain, parecia um pouco sobrecarregado. Desta vez, ao participar da definição do roteiro, é evidente que espera reverter a situação com a atualização da camada base.

Problema central a ser resolvido

O roteiro foca na melhoria da microestrutura do mercado, em outras palavras, o mecanismo atual de negociação em cadeia não é amigável para os market makers, ou seja, os Takers que iniciam ativamente as negociações se beneficiam, enquanto os Market Makers que aguardam a execução das ordens saem prejudicados. Isso ocorre porque os Takers geralmente têm acesso a informações mais recentes e aumentam ativamente as taxas de negociação para garantir que suas transações sejam executadas em primeiro lugar, enquanto os Makers muitas vezes não conseguem cancelar suas ordens a tempo e são forçados a negociar a preços desfavoráveis.

Alguns arbitradores de alta frequência vão aproveitar essa assimetria para lançar um ataque de “tráfego tóxico”. Por exemplo, se o preço na cadeia ainda não foi atualizado, mas o preço fora da cadeia já mudou, o arbitrador pode aceitar a ordem do formador de mercado ao preço antigo, fazendo com que o formador de mercado suporte a perda. O resultado é que o Maker, para se proteger, ou amplia o spread de compra e venda, ou reduz a quantidade de ordens pendentes, levando a uma piora na liquidez do mercado.

O roteiro do ICM visa equilibrar esse padrão, atraindo liquidez de alta qualidade de volta à cadeia.

Os três passos do ICM

A Solana dividiu este grande plano em três fases:

Curto prazo (1-3 meses): O foco principal é otimizar a experiência de transações on-chain existente, tornando as aplicações de livro de ordens mais utilizáveis e reduzindo a interferência maliciosa do MEV. Especificamente, inclui:

• O módulo Block Assembly Marketplace (BAM) da Jito Labs foi lançado na mainnet. O significado deste módulo é fornecer um sistema externo temporário antes do lançamento do ACE (Application Controlled Execution) definitivo, permitindo que os contratos inteligentes na Solana tenham a autonomia na ordem das transações.
• A equipe Anza otimizou a taxa de sucesso de “entrar na mesma Slot de transação”, reduzindo assim o slippage e as perdas de MEV.

Essas melhorias estão previstas para ser implementadas gradualmente entre julho e setembro de 2025.

Médio prazo (3-9 meses): Introdução de uma rede de alta velocidade dedicada e uma nova versão do consenso, reduzindo significativamente a latência e aumentando a capacidade de processamento:

• Implementar uma rede de fibra ótica dedicada DoubleZero, proporcionando comunicação de alta velocidade com quase zero jitter e redução de latência de até 100ms para os validadores.
• Lançamento do protocolo de consenso Alpenglow, reduzindo o tempo de confirmação final de cerca de 12,8 segundos para cerca de 0,15 segundos.
• Desenvolvimento da Execução de Programas Assíncronos(Execução de Programas Assíncronos, APE), reduz o bloqueio da execução de transações no consenso.

Longo prazo (9-30 meses): Revolucionar a arquitetura central do Solana, com o objetivo de alcançar isso por volta de 2027:

• Vários Líderes Concorrentes (Multiple Concurrent Leaders, MCL): Permite que vários validadores proponham transações simultaneamente em seus próprios pipelines e, em seguida, ordenem esses blocos paralelos de acordo com a taxa de prioridade. Isso pode enfraquecer o monopólio de um único empacotador e aumentar a resistência à censura.
• Execução Controlada por Aplicação (, ACE) Função: dá realmente ao contrato inteligente na cadeia o poder de controlar a ordem de execução das transações.

Analisando até aqui, o autor acredita que a proposta do roteiro ICM tem uma história por trás assim: o DEX tradicional Drift na Solana foi superado pelo novato Hyperliquid com a excelente experiência de “Binance on-chain”. Drift, incapaz de resistir, teve que pedir ajuda a “pro” como Solana Labs, Anza e Jito. Os “pro” apresentaram um plano de reforma técnica chamado ICM, afirmando que iriam replicar todas as habilidades do Hyperliquid para equipar Drift e ajudá-lo a lutar novamente no mercado de DEX. No entanto, os “pro” também disseram que a dificuldade dessa reforma técnica é enorme, portanto, o plano técnico foi dividido em uma estratégia de três etapas, e o único equipamento que pode ser fornecido a Drift no curto prazo é o BAM da Jito, para que Drift possa se virar, competindo com Hyperliquid por enquanto.

Com o pano de fundo da história estabelecido, nos capítulos seguintes, o autor irá analisar detalhadamente quais habilidades de destaque o ICM realmente imitou e replicou do Hyperliquid.

🎭 Imitar um: Mecanismo de ordenação de transações

Problema: Como mencionado anteriormente, a cadeia atual favorece os takers, enquanto os makers sofrem com o “fluxo tóxico”. Usuários que tomam a iniciativa de consumir ordens podem, com base no preço mais recente fora da cadeia, iniciar transações instantaneamente em ordens pendentes na cadeia e priorizar a execução ao aumentar a taxa de transação, enquanto os formadores de mercado muitas vezes não têm tempo para atualizar ou cancelar ordens. O resultado é que os formadores de mercado ou aumentam o spread ou simplesmente retiram a liquidez, piorando a profundidade do mercado.

A solução final da ICM: aplicação de execução controlada (ACE)

O roadmap do ICM propõe o conceito de ACE (Application Controlled Execution), que é delegar o direito de ordenação das transações para as aplicações em cada cadeia, permitindo que as aplicações decidam como ordenar e executar as transações relacionadas a elas. Por exemplo, no Solana, que implementará o ACE no futuro, os contratos DeFi poderão implementar as seguintes regras personalizadas de ordenação de transações:

• Atualização de Preço do Oracle: As aplicações DeFi podem inserir uma transação antes da execução de grandes negócios para obter o preço mais recente do oracle, garantindo que as ordens sejam executadas ao preço razoável mais atual, evitando que as cotações dos market makers sejam arbitradas com base em preços desatualizados.
• Prioridade na execução de cancelamento de ordens: A aplicação pode definir que o “pedido de cancelamento” tenha prioridade sobre uma nova “execução de ordens”, permitindo que o maker tenha a oportunidade de retirar a ordem pendente a tempo quando o mercado estiver desfavorável.
• Leilão de Última Oportunidade: Por exemplo, após a ocorrência de uma grande ordem de compra que eleva o preço, a aplicação DeFi coloca à venda a oportunidade de “seguir de perto”, onde quem estiver disposto a devolver o maior benefício ao protocolo (ou aos usuários) terá sua transação executada logo após a grande ordem. As aplicações DeFi podem devolver os lucros do leilão aos usuários, transformando assim o fluxo MEV tóxico em receita benéfica.

BAM do JITO: plano de transição

Antes do lançamento oficial da ACE, a Jito Labs lançou uma solução de transição chamada Block Assembly Marketplace (BAM). O fluxo de trabalho do BAM é:

1. O usuário envia a transação para um nó que executa o software BAM (em vez de enviá-la diretamente ao líder atual).
2. O nó BAM coleta transações locais e executa vários plugins (plugin) para realizar a reorganização das pacotes de transação (Bundle) sob proteção de privacidade (os plugins são executados em um ambiente seguro de TEE, ocultando o conteúdo da transação antes da execução). Através do plugin, os desenvolvedores de aplicativos podem personalizar várias regras de ordenação para seus contratos, como priorizar cancelamentos, atualizar o preço do oráculo antes da correspondência, ou até executar lances complexos dentro do aplicativo.
3. O Bundle de transações ordenado é enviado ao Líder da Solana para ser empacotado na blockchain.

BAM pode ser visto como um campo de teste antes do ACE em cadeia, com funcionalidades muito próximas do ACE definitivo, apenas funcionando em uma rede independente fora do protocolo da cadeia principal Solana.

É importante notar que a Jito anteriormente oferecia infraestrutura voltada para a extração de MEV (como o Jito Block Engine), cujo modelo de negócios era criar oportunidades para arbitradores ao otimizar a ordem das transações e compartilhar os lucros. Isso, de certa forma, colocava a “lança” em oposição aos usuários comuns e aos que eram alvo de arbitragem. No entanto, a Jito fechou no início de 2024 a funcionalidade de mempool pública para robôs de arbitragem (mempool), a fim de reduzir externalidades negativas como ataques de sanduíche. Esta iniciativa indica que a comunidade Solana tende a reprimir o MEV prejudicial e a manter a equidade dos usuários.

O lançamento do BAM está em conformidade com esse pensamento: é essencialmente uma “escudo” que transforma o mecanismo de ordenação originalmente usado para arbitragem MEV, a fim de proteger provedores de liquidez, como os formadores de mercado, por exemplo, priorizando a retirada forçada para evitar perdas para os formadores de mercado e introduzindo incentivos de licitação para reduzir os lucros de corrida. Os antigos buscadores de MEV que desejam ganhar dinheiro devem mudar de papel e desenvolver plugins do BAM para servir protocolos DeFi, lucrando com as taxas dos plugins.

Pedir conselhos ao HYPERLIQUID

A abordagem ACE/BAM mencionada acima pode ser vista como uma tentativa de alcançar o mecanismo de correspondência em cadeia da Hyperliquid. A Hyperliquid é uma Appchain( dedicada, criada especificamente para serviços DEX. Além disso, o HLP Vault, operado oficialmente pela Hyperliquid, é na verdade um dos maiores formadores de mercado da plataforma, portanto, não é difícil entender que as regras da cadeia da Hyperliquid são mais voltadas para os provedores de liquidez, já tendo implementado muitas proteções para os formadores de mercado em nível de cadeia, como:

• Prioridade de proteção para ordens pendentes: A anulação de ordens e as ordens de maker são tratadas com prioridade, evitando que os market makers sejam prejudicados por transações desfavoráveis sem o seu conhecimento. A “execução prioritária de anulações” mencionada na Solana ACE já foi praticada pela Hyperliquid há muitos anos.
• Garantia do Preço Mais Recente: O processo de liquidação e correspondência da Hyperliquid enfatiza o uso do preço mais recente e do estado da margem para fazer uma “dupla verificação”. Por exemplo, quando há uma ordem correspondente, o sistema irá novamente buscar o preço mais recente do oráculo para avaliar as margens de ambas as partes, garantindo que não haja riscos devido a atrasos nos preços. Isto é semelhante ao ACE que insere atualizações do oráculo antes da execução da negociação.
• Proteção contra auto-negociação: Se o mesmo endereço comprar e vender, o Hyperliquid cancela automaticamente em vez de combinar, para evitar manipulação de volume ou custos desnecessários.

A ACE/BAM do ICM Solana é, sem dúvida, um “exemplo” de Hyperliquid. Hyperliquid, como líder de CLOB on-chain, implementou uma série de mecanismos amigáveis para market makers através de uma cadeia exclusiva. Agora, a Solana espera usar cadeias genéricas e plugins modularizados para replicar esse efeito - ou seja, permitir que cada aplicação tenha controle sobre a ordenação de transações semelhante ao da Hyperliquid.

) ⚡ Imitação Dois: Finalidade Instantânea

Comparação de consensos existentes

A Solana atualmente utiliza o Tower BFT. A confirmação e a finalidade são probabilísticas e progressivas: um bloco recebe 2/3 dos votos e é considerado “confirmado###Confirmed(”, mas é necessário acumular aproximadamente 32 blocos subsequentes na cadeia (geralmente cerca de 13 segundos) para ser ancorado como “finalizado)Finalized(”. Para algumas aplicações (como o trading de alta frequência), um tempo de confirmação final de alguns segundos ainda é muito longo.

HyperBFT é o algoritmo de consenso desenvolvido pela Hyperliquid. Inspirado no consenso HotStuff, adota a confirmação de blocos em duas rodadas de votação, alcançando a “finalidade instantânea”.

• Primeira rodada: pré-votação )Prevote(: Os validadores, ao receberem o bloco candidato transmitido pelo Proposer, realizarão uma validação rápida. Se a validação for bem-sucedida, cada validador emitirá um “voto prévio” )Prevote( para esse bloco e o transmitirá para toda a rede. Este voto representa: “Eu olhei preliminarmente, este bloco está ok.”
• Segunda rodada: Pré-submissão)Precommit(: Assim que um validador coleta votos Prevote de mais de dois terços dos validadores para o mesmo bloco candidato, ele adquire confiança suficiente, acreditando que a maioria dos membros da rede reconhece esse bloco. Assim, o validador emite um voto “pré-submissão”)Precommit( mais significativo e o transmite. Este voto representa: “Eu vi que a maioria da rede concorda, estou pronto para registrar oficialmente este bloco no livro razão.”
• Quando um validador coleta mais de dois terços dos validadores sobre o mesmo bloco candidato para o Precommit, o consenso é alcançado! Esse bloco é considerado finalizado)Finalized(. Ele será adicionado à blockchain de forma permanente e irreversível.

Isso significa que cada bloco do Hyperliquid é um bloco final, sem possibilidade de bifurcações ou retrocessos, com um atraso de geração de blocos extremamente baixo - a média de atraso de confirmação divulgada oficialmente é de cerca de 0,2 segundos, e em 99% dos casos não ultrapassa 0,9 segundos. Essa certeza final em milissegundos é ideal para negociações de alta frequência, pois uma vez que a transação é enviada, ela é rapidamente confirmada e não pode ser reestruturada, aumentando significativamente a eficiência do capital.

)# ALPENGLOW alcança finalização instantânea

Alpenglow é um novo protocolo de consenso que a Solana está prestes a lançar, com o objetivo de acelerar a confirmação final de blocos para 1-2 slots (cerca de 150ms), alcançando uma finalidade instantânea semelhante ao HyperBFT. O componente que substitui o TowerBFT, responsável pelo consenso no Alpenglow, é chamado de Votor, que é um sistema de votação de duas trilhas:

• Via Rápida: Se, na primeira rodada de votação de um bloco, mais de ou igual a 80% do “stake” da rede (que pode ser entendido como o peso do voto representado pela quantidade de tokens SOL que os validadores apostaram) votarem a favor da validade deste bloco, então este bloco será imediatamente confirmado como “finalizado”.
• Canal Lento: Se na primeira rodada de votação, a porcentagem de direitos que concordam não atingir 80%, mas for igual ou superior a 60%, o Votor iniciará a segunda rodada de votação. Se após a conclusão da segunda rodada de votação, a porcentagem de direitos que concordam com o bloco ainda se mantiver em 60% ou mais, então esse bloco também será confirmado finalmente.

Votor está a dizer: “Assumimos que fazemos uma ronda de votação como confirmação, mas se as condições não forem perfeitas, iniciamos um processo de votação em duas rondas quase idêntico ao HyperBFT como seguro.” Na verdade, é uma imitação do mecanismo de votação da Hyperliquid.

O custo e as estratégias da finalização instantânea

Hyperliquid pode realizar duas rodadas de votação, com uma condição importante: utiliza um conjunto de validadores muito reduzido, onde no início, menos de 5 entidades controlavam a maioria dos nós de validação. Uma rede de tamanho limitado pode reduzir significativamente os custos de comunicação do consenso BFT.

Mas se o número de nós aumentar para dezenas ou centenas, a complexidade do processo de votação aumentará rapidamente, porque a complexidade de cada rodada de votação é proporcional ao quadrado do número de nós participantes da comunicação. A Solana possui milhares de nós validadores, e realizar duas rodadas de votação mantendo um alto grau de descentralização apresenta uma dificuldade técnica muito maior do que a do Hyperliquid. Portanto, a Solana precisa fazer um grande trabalho em comunicação de rede. O roteiro mencionou várias medidas:

• No Alpenglow, há um componente Rotor que substitui o antigo protocolo de distribuição de dados Turbine. Ao contrário do Turbine, que precisa de múltiplas camadas de retransmissão, o Rotor adota um modo de “retransmissão de salto único”, permitindo que os blocos de dados cheguem mais rapidamente aos validadores alvo, reduzindo significativamente a latência de transmissão. Além disso, no atual mecanismo do Turbine, a posição dos nós na árvore de distribuição de dados é principalmente baseada na classificação de peso de stake, onde nós com maior stake são organizados em camadas mais altas, recebendo prioridade na recepção de fragmentos de dados (shreds), mas também tendo que assumir mais tarefas de retransmissão a jusante, consumindo mais largura de banda. A hipótese por trás desse design é que nós com mais stake são frequentemente “proprietários ricos”, presumivelmente com hardware mais poderoso e recursos de largura de banda mais abundantes. O Rotor atualizou essa lógica, não confiando mais apenas no tamanho do stake, mas considerando de forma abrangente a largura de banda real e o desempenho de comunicação de cada nó. Aqueles nós que apresentam melhor desempenho em rede em tempo real serão dinamicamente alocados em posições críticas, criando assim um caminho de propagação de dados otimizado para toda a rede, realizando um serviço de “entrega rápida” que é tanto rápido quanto estável.
• Rede de alta velocidade DoubleZero baseada em fibra óptica dedicada + tecnologia de multicast, oferece comunicação de baixa latência que é uma ordem de magnitude mais rápida do que a internet pública. Isso reduz a latência e a variação nas mensagens entre nós geograficamente dispersos, tornando a base física para um consenso rápido mais sólida.

Mesmo assim, é extremamente desafiador para a Solana conseguir simultaneamente “alta descentralização + finalização em milissegundos”. É por isso que a Alpenglow prevê que ainda precisará de mais de um ano de desenvolvimento, com lançamento previsto para o início de 2026 (só podemos esperar isso).

🔄 Imitação Três: Execução Assíncrona de Pipeline

HYPERLIQUID de pipeline assíncrono

As blockchains tradicionais são de thread única, um bloco deve ser completamente executado e validado antes que o próximo bloco possa começar a ser processado. O objetivo de fazer isso é eliminar a incerteza introduzida pelo multithreading, garantindo que todos os nós recebam os mesmos resultados na mesma ordem exata. No entanto, a desvantagem é que isso limita o desempenho dos modernos CPUs multicore.

E a Hyperliquid, por sua vez, introduziu a multitarefa de forma não convencional, desacoplando o fluxo de trabalho em duas linhas de montagem paralelas: “ordenamento (consenso)” e “execução”. O processo de execução é o seguinte:

1. Ponto no tempo T1:

   • Pipeline de Consenso: Os validadores concordam com o conteúdo e a ordem das transações do bloco N-1.

2. Momento T2 (o lugar onde a magia começa)

   • Pipeline de Consenso: Começando a processar o bloco N. Ele empacota, classifica e vota sobre a ordem das transações na rede, alcançando consenso sobre essa ordem. Ele não se importa com o resultado da execução do bloco N-1.
   • Pipeline de Execução: Obter o bloco N-1 que já alcançou consenso no momento T1 e começar a executar as transações nele.

3. Ponto no tempo T3 (linha de produção em funcionamento contínuo):

   • Pipeline de Consenso: Concluiu o consenso do bloco N e passou o resultado do consenso (uma lista de transações ordenada) para a pipeline de execução. Em seguida, começou imediatamente a processar o bloco N+1.
   • Executar Pipeline: Concluiu a execução do bloco N-1 e finalmente confirmou o estado. Em seguida, ele se conectou perfeitamente, recebendo imediatamente o bloco N que foi acabado de ser concluído pelo pipeline de consenso, e começou a executar suas transações.

Neste modo de Pipeline, diferentes núcleos da CPU podem ser utilizados de forma eficaz. Alguns núcleos podem ser dedicados ao processamento de mensagens de rede e votação de consenso (ordenação), enquanto outros núcleos podem se concentrar totalmente no cálculo de estado (execução), com ambas as pipelines funcionando simultaneamente, maximizando a eficiência do hardware.

O plano APE da ICM

execução

Mas implementar a execução segura paralela/assíncrona em uma cadeia descentralizada é, por si só, um desafio de engenharia extremamente difícil: Para garantir que todos os nós globais cheguem a um consenso total sobre os resultados das transações, é necessário eliminar qualquer fator que possa levar a resultados diferentes devido a ordens de execução distintas.

A razão pela qual o plano de pipeline assíncrono conseguiu ter sucesso na Hyperliquid é que a Hyperliquid, como uma appchain com uma única funcionalidade, possui um modelo de estado simples e claro (principalmente o livro de ordens dos mercados de negociação e as posições dos usuários). A equipe de desenvolvimento pode claramente dividir quais operações podem ser paralelizadas e quais têm dependências, e com base nisso, projetar um pipeline eficiente.

No entanto, a Solana, como uma cadeia genérica, tem relações de dependência nas transações que são muito mais complexas do que um sistema de livro de ordens. Portanto, para a Solana reproduzir o desempenho do Hyperliquid em um ambiente genérico, os desafios de engenharia são muito maiores e será necessário reescrever muito código, o que não pode ser realizado a curto prazo, por isso também é classificado como planejamento de médio prazo no roteiro do ICM. Mesmo assim, o verdadeiro lançamento do APE ainda precisa superar uma série de desafios:

• Complexidade extrema do código: Fazer com que sistemas distribuídos suportem execução assíncrona e paralela requer uma grande quantidade de reformas de baixo nível. Uma vez que a paralelização multithread é introduzida, a complexidade do software do cliente do nó de validação do Solana aumentará exponencialmente, e o risco de bugs desconhecidos também subirá. Uma condição de corrida mal tratada pode levar a erros de consenso, e o resultado será catastrófico.
• Requisitos de hardware aumentados: A execução paralela requer uma CPU multicore robusta e mais memória para executar vários threads de execução ao mesmo tempo, mantendo vários estados temporários e pontos de retrocesso. Os nós Solana já têm um limiar elevado, e se forem ainda mais exigentes, isso afetará a descentralização da rede.
• Tratamento de Pior Cenário: O pior cenário para a execução em paralelo é quando um grande número de transações compete pelo mesmo estado. Por exemplo, ao encontrar alguns contratos populares (como DEXs populares ou contratos de compra em massa) que fazem com que todas as transações leiam e escrevam na mesma conta, o escalonador paralelo continuará a detectar conflitos, reverter e reproduzir, podendo ser mais lento do que a execução em série. A forma de degradar elegantemente em situações de pior cenário, sem deixar o sistema preso em deadlock ou com um desempenho drasticamente reduzido, é um desafio no design da arquitetura.
• Dificuldade de desenvolvimento e auditoria: A verificação de segurança em ambientes assíncronos e multithread é muito difícil. A comunidade Solana precisa investir recursos adicionais para auditar o novo modelo de execução, a fim de prevenir a exploração maliciosa de falhas de consenso causadas pela paralelização.

🤔 Este espetáculo de imitação terá sucesso?

Com base na análise acima, o roteiro do Solana ICM é na verdade uma profunda “imitação” da arquitetura tecnológica da Hyperliquid. A equipe central do Solana planeja replicar uma a uma as habilidades principais da Hyperliquid e equipar a Drift, ajudando-a a competir novamente no mercado de DEX com a Hyperliquid. No entanto, não sou otimista em relação ao futuro desta imitação.

A dificuldade técnica aumentou exponencialmente

O sucesso da Hyperliquid baseia-se, em grande parte, nas suas condições inatas favoráveis:

• Como uma cadeia dedicada, pode otimizar o consenso e a execução em torno de uma única aplicação, sendo projetada sem a necessidade de considerar diferentes requisitos de contratos inteligentes;
• Como uma cadeia emergente, pode até sacrificar um certo grau de descentralização em troca de desempenho (os validadores iniciais são controlados pela equipe, e a maioria dos usuários também aceita isso).

Em contraste com a Solana, para alcançar o nível da Hyperliquid enquanto mantém a universalidade da blockchain pública e o grau de descentralização, a dificuldade técnica aumenta exponencialmente. Por exemplo, o consenso HyperBFT da Hyperliquid consegue operar com uma latência de 0,2 segundos com menos de 5 nós, enquanto a Solana, para que 2000 nós atinjam a mesma latência, precisa ultrapassar os limites de comunicação da rede; o motor de correspondência da Hyperliquid serve apenas a lógica de sua própria exchange, enquanto o ACE/BAM da Solana precisa se adaptar a uma variedade de protocolos DeFi.

Pode-se dizer que a Solana está a acompanhar as lições da Hyperliquid, e a dificuldade do curso é muito maior do que a que a Hyperliquid enfrentou inicialmente, que era “não se sabe até onde subiu”. O roadmap do ICM divide estas tarefas até 2027, o que demonstra que a equipa oficial também está ciente de que não é um trabalho de um dia.

A contradição entre descentralização e eficiência

Uma outra diferença entre Solana e Hyperliquid está no ritmo de governança e atualizações. A equipe da Hyperliquid é pequena, com decisões centralizadas e sem mecanismos de governança externa, o que permite uma ação muito rápida. Em março deste ano, quando a Hyperliquid enfrentou o incidente de manipulação do contrato JELLY, a equipe tomou a decisão de retirar rapidamente os mercados relacionados em questão de horas, protegendo a segurança dos fundos, demonstrando plenamente que a decisão centralizada, embora “politicamente incorreta”, é realmente eficaz e útil em momentos críticos.

E a Solana, como uma cadeia pública, tem uma fundação, desenvolvedores principais e uma comunidade que competem entre si, resultando em um processo de atualização relativamente lento e conservador. Por exemplo, o tão esperado Firedancer (cliente Solana de alto desempenho desenvolvido pela Jump) está em fase de testes desde seu lançamento em 2022 e ainda não está completamente online (até meio de 2025); qualquer alteração relacionada ao consenso requer longos períodos de auditoria e operação em rede de testes. As mudanças no planejamento do roteiro ICM são ainda mais significativas: haverá a substituição do algoritmo de consenso central, a introdução de uma nova execução paralela e a descentralização do poder-chave, o que traz dificuldades e riscos elevados. É previsível que, nos próximos dois a três anos, a equipe da Solana precisará avançar gradualmente com essas atualizações, e cada passo pode encontrar desafios técnicos inesperados ou resistência da comunidade.

Por exemplo, o BAM lançado pela Jito deve realmente beneficiar os usuários, desde que a maioria dos validadores migre para um cliente que suporte o BAM. Caso contrário, as transações dos usuários às vezes passarão pelo BAM e outras vezes não, o que resultará em uma experiência inconsistente e até mesmo em brechas para arbitragem. O problema é que a Solana não pode forçar os nós validadores a atualizar o cliente. Portanto, mesmo que o BAM seja desenvolvido com sucesso, a sua velocidade de promoção é difícil de prever. Assim, o cronograma no ICM é apenas um planejamento otimista, e sua realização pode ser adiada indefinidamente, não se sabe quando todos os objetivos serão alcançados.

Mesmo que tudo corra bem, até 2027 a Solana terá apenas “sucesso na recuperação” ao implementar funcionalidades como a ACE, alcançando o que a Hyperliquid já ofereceu entre 2023 e 2024. E a própria Hyperliquid não vai parar: por exemplo, a proposta HIP-3 será lançada no segundo semestre de 2025, permitindo que a comunidade adicione de forma independente o mercado de contratos perpétuos. Essas inovações irão expandir ainda mais a cobertura de mercado da Hyperliquid. Quando a Solana finalmente conseguir implementar as funcionalidades atuais da Hyperliquid, talvez a Hyperliquid já tenha aberto novas vantagens de liderança.

Superando a competição técnica

Embora este artigo tenha se concentrado na comparação entre Solana e Hyperliquid em termos de suas abordagens tecnológicas, também devemos observar que o sucesso da Hyperliquid não se deve apenas a fatores técnicos. A Hyperliquid possui muitos aspectos valiosos em sua operação e ecossistema:

• Por exemplo, na economia de tokens, a Hyperliquid não recebeu financiamento de VC, mais de 76% dos tokens são alocados para a comunidade. Os lucros das taxas cobradas pela plataforma podem ser usados para recomprar tokens HYPE, realmente compartilhando benefícios com os usuários e evitando problemas de exploração excessiva dos usuários por parte dos investidores. Isso conquistou a reputação de muitos usuários fiéis para a Hyperliquid.
• Além disso, a equipe da Hyperliquid captura de forma extremamente sensível a demanda do mercado: quando os NFTs estão em alta, lançaram o índice de NFT; quando SocialFi está em alta, lançaram o índice FriendTech; o HIP-2 resolveu o problema da “dificuldade de início a frio e falta de liquidez inicial” de novos tokens; o Hyperps resolveu o problema de fornecer negociação de futuros para ativos que ainda não foram oficialmente lançados; a atualização HIP-3 planejada para este ano suportará qualquer projeto que emita seu próprio mercado de contratos perpétuos. A inovação de produtos é constante, e essas categorias de negociação ricas e formas inovadoras aumentam enormemente a atratividade da Hyperliquid como plataforma de negociação — os usuários vêm aqui não apenas pela velocidade, mas também pelas oportunidades de ganhar que não estão disponíveis em outros lugares.

Por outro lado, no setor de DEX da Solana, a Drift e outros DEX nativos da Solana atualmente não têm vantagens claras em termos de design de produtos e mecanismos de incentivos. Apenas recriar com sucesso a tecnologia da Hyperliquid e igualar o desempenho da blockchain, se não resolver funcionalidades características que atendam às dores dos usuários, não trará automaticamente um retorno em massa dos usuários, afinal, a migração de usuários também tem custos.

Portanto, se apenas seguir cegamente o caminho da Hyperliquid, sempre estará atrás, comendo poeira. A verdadeira oportunidade no roadmap do Solana ICM não está no campo dos contratos perpétuos ou livros de ordens. Há muitos outros campos no ecossistema Solana que a Hyperliquid ainda não explorou, como o campo de lançamento de MEME, protocolos de empréstimo, etc., que também podem aproveitar as melhorias trazidas pelo ICM para criar uma experiência de usuário mais suave. Se o Solana conseguir inovar funcionalidades e resolver os pontos problemáticos dos usuários nesses campos, mesmo que não consiga imediatamente reverter a situação no mercado de contratos perpétuos, ainda poderá consolidar a realização de sua visão de “mercado de capitais da internet”. Afinal, por mais forte que a Hyperliquid seja, é apenas um aplicativo em um setor vertical, enquanto o Solana possui um vasto e diversificado mapa de aplicações, que é seu maior capital a longo prazo.

🏁 Conclusão: é fácil imitar, difícil superar

O roteiro do ICM da Solana destaca a determinação da comunidade Solana em não ficar para trás e em correr atrás do prejuízo. Desde o ACE até o Alpenglow e depois o APE, cada um corresponde a uma funcionalidade característica do Hyperliquid, realmente carregando um sentido de “imitação direcionada”.

No entanto, imitar é fácil, superar é difícil. Para que a Solana tenha sucesso nesta imitação, precisa de um esforço abrangente em termos de avanços tecnológicos, colaboração no ecossistema e estratégias de mercado. A curto prazo, a Solana pode talvez melhorar a experiência de negociação em cadeia através de BAM e recuperar alguns usuários. Mas para realmente desafiar a posição de liderança da Hyperliquid, pode ser necessário mais tempo e mais inovações.

Pelo menos no momento, a Hyperliquid continua a expandir sua presença no mercado, aproveitando sua vantagem em participação de mercado, enquanto a Solana ainda está acelerando o processo de reforma do motor, e esse processo de reforma provavelmente vai durar um bom tempo.

O futuro retratado no roteiro do ICM é promissor, mas a capacidade de “ultrapassagem em curva” ainda precisa ser testada pelo tempo. Como usuários comuns, podemos esperar que esta competição traga uma melhor experiência de transação em cadeia — independentemente de quem vencer no final, os usuários são os beneficiários.

Este artigo é baseado em informações públicas e não constitui aconselhamento de investimento. O investimento em criptomoedas envolve riscos significativos, por favor, tome decisões com cautela, DYOR.

Se você gostou deste artigo, sinta-se à vontade para seguir, curtir e compartilhar seu apoio!