Aprofundando-se na estrutura técnica e nas vulnerabilidades de segurança do Hyperliquid

Recentemente, o Hyperliquid, amplamente comentado, é uma das exchanges de livro de ordens em cadeia mais influentes, com um valor total de ativos bloqueados que ultrapassa os 2 bilhões de dólares, sendo classificado pela indústria como "a versão em cadeia de uma conhecida exchange centralizada". Isso também reacendeu discussões sobre Layer3 e cadeias de aplicativos. Com uma valorização do projeto que atingiu 30 bilhões de dólares em apenas um mês desde o lançamento, o Hyperliquid ganhou ampla atenção. Atualmente, há vários relatórios de análise sobre o Hyperliquid no mercado, mas a maioria se concentra nas funcionalidades do produto e nos mecanismos de negociação, faltando uma análise aprofundada de sua arquitetura técnica e potenciais riscos de segurança.

Este artigo visa preencher esta lacuna, analisando o Hyperliquid puramente do ponto de vista técnico e de segurança, ajudando os leitores a compreender melhor a estrutura interna e os princípios deste projeto estrela. Vamos focar na análise do design e dos riscos do contrato da ponte cross-chain do Hyperliquid, bem como na arquitetura de dupla cadeia do HyperEVM e HyperL1, explorando em profundidade a forma como a tecnologia por trás é implementada.

Análise da ponte cross-chain Hyperliquid

Devido ao fato de a Hyperliquid não ter tornado seus componentes principais de código aberto, mas ter disponibilizado contratos de ponte relacionados, temos mais entendimento sobre os riscos associados aos contratos de ponte. A Hyperliquid implementou um contrato de ponte em uma rede Layer2, destinado a armazenar os ativos USDC depositados pelos usuários, e podemos observar parte do comportamento dos nós da Hyperliquid através do componente Bridge.

Conjunto de Validadores

Do ponto de vista da classificação de identidade de nós, o Hyperliquid possui 4 grupos de validadores, que são hotValidatorSet, coldValidatorSet, além de finalizers e lockers, cada um com responsabilidades diferentes. O hotValidatorSet é responsável por responder às operações de alta frequência dos usuários, como retiradas, geralmente utilizando carteiras quentes para processar rapidamente os pedidos dos usuários.

O coldValidatorSet é principalmente utilizado para modificar a configuração do sistema, como atualizar a lista de outros conjuntos de validadores ou lidar com o estado de bloqueio do contrato de ponte, e tem o direito de invalidar diretamente certos pedidos de retirada.

Lockers são um grupo de validadores com permissões especiais, semelhantes ao "comitê de segurança" comum no Layer2, que podem votar para decidir se devem suspender a operação da ponte cross-chain em situações de emergência. Atualmente, o conjunto de lockers da ponte Hyperliquid contém 5 endereços, e apenas 2 lockers precisam votar para suspender o contrato da ponte.

finalizers também são um grupo de validadores especiais, principalmente usados para confirmar mudanças de estado da ponte entre cadeias, como operações de depósito e retirada de usuários. A ponte entre cadeias da Hyperliquid adota um mecanismo de "submissão-confirmação", onde o usuário deve esperar um período de "disputa" após iniciar a retirada, e, após o término, os finalizers executam a transação de retirada.

Se houver problemas, como um pedido de retirada que exceda o saldo real do usuário, o nó Hyperliquid pode votar para suspender o contrato da ponte através dos lockers durante o período de disputa, ou o coldValidatorSet pode invalidar diretamente o pedido de retirada problemático.

Atualmente, a Hyperliquid possui apenas 4 nós validadores, portanto, o hotValidatorSet e o coldValidatorSet correspondem cada um a 4 endereços na cadeia. Na inicialização, a Hyperliquid registra automaticamente os endereços no hotValidatorSet como membros dos lockers e finalizers, enquanto o coldValidatorSet é controlado oficialmente, utilizando uma carteira fria para armazenar as chaves.

depósito

O contrato de ponte da Hyperliquid é baseado no método Permit do EIP-2612 para processar depósitos de usuários, e suporta apenas o ativo USDC. Em comparação com o modo tradicional de Aprovar-Transferir, o Permit é mais simples e facilita operações em massa.

Os contratos de ponte usam a função batchedDepositWithPermit para processar várias depósitos em lote, o processo é simples e sem risco de segurança de fundos, principalmente utilizando o método Permit para otimizar a experiência do usuário.

Retirada

Em comparação com depósitos, saques são operações de alto risco, portanto a lógica é mais complexa. Após o usuário iniciar um pedido de saque, o nó Hyperliquid chama a função batchedRequestWithdrawals do contrato da ponte. Neste momento, exige-se que cada pedido de saque obtenha 2/3 do peso de assinatura do hotValidatorSet, note que é "peso de assinatura de 2/3" e não "número de assinaturas de 2/3". Atualmente, o Hyperliquid possui apenas 4 nós com pesos iguais, portanto, a verificação do peso de assinatura e do número de assinaturas é temporariamente consistente, mas no futuro, nós de alto peso podem ser introduzidos.

Após iniciar o pedido de retirada, a ponte entre cadeias não transferirá imediatamente USDC, mas terá um "período de disputa" de 200 segundos. Durante este tempo, podem ocorrer duas situações:

1. lockers considera que existem sérios problemas com o pedido de retirada, podendo votar diretamente para congelar o contrato;

2. O nó considera que algumas retiradas têm problemas, os membros do coldValidatorSet podem chamar a função invalidateWithdrawals para invalidar essa retirada.

Se não houver anomalias durante o período de disputa, após o término, os membros do finalizers podem chamar a função batchedFinalizeWithdrawals para confirmar o estado final. Somente neste momento é que o USDC será transferido para o endereço da carteira do usuário na Layer2.

Do ponto de vista do modelo de segurança, se um atacante malicioso quiser causar danos no processo de retirada do Hyperliquid, precisa ultrapassar três linhas de defesa:

1. Dominar o peso de 2/3 das assinaturas do hotValidatorSet, ou seja, obter chaves privadas suficientes ou conluio. Atualmente, existem apenas 4 validadores, a possibilidade de controle ou conluio não é baixa;

2. Evitar que transações maliciosas sejam descobertas durante o período de disputa, caso contrário, pode desencadear o bloqueio do contrato pelos lockers.

3. Obtenha pelo menos uma chave privada de um membro finalizador e confirme a retirada. Atualmente, os finalizadores são basicamente consistentes com os membros do hotValidatorSet; satisfazer a condição 1 é suficiente para satisfazer a condição 3.

contrato de bloqueio da ponte

A Hyperliquid configurou a funcionalidade de bloqueio do contrato da ponte entre cadeias. Especificamente, os membros lockers devem chamar a função voteEmergencyLock para votar; atualmente, 2 membros lockers podem votar para bloquear e pausar o contrato da ponte.

É importante notar que a ponte Hyperliquid também oferece a função unvoteEmergencyLock, permitindo que os lockers retirem os votos. Uma vez que o contrato da ponte está bloqueado, só pode ser desbloqueado através da função emergencyUnlock, que requer a coleta de mais de 2/3 do peso das assinaturas dos membros do coldValidatorSet.

O desbloqueio de emergencyUnlock atualizará simultaneamente o conjunto de endereços dos validadores hotValidatorSet e coldValidatorSet, e terá efeito imediato.

Atualização do conjunto de validadores

Comparado a ultrapassar a linha de defesa do processo de retirada, usar diretamente a função updateValidatorSet para atualizar o conjunto de validadores é uma forma de ataque mais eficaz. Isso requer a assinatura de todos os membros do hotValidatorSet, e há um período de disputa de 200 segundos.

Após o término do período de contestação, os membros dos finalizers devem chamar a função finalizeValidatorSetUpdate para concluir a atualização final.

Resumo dos riscos existentes no contrato do Hyperliquid Bridge:

1. Hackers que controlam o coldValidatorSet podem ignorar obstáculos e roubar ativos dos usuários. Como o coldValidatorSet tem a permissão de emergencyUnlock, pode tornar os lockers inválidos e atualizar imediatamente a lista de nós. Atualmente há apenas 4 nós validadores, o risco de roubo de chaves privadas não é baixo;

2. os finalizadores recusam a confirmação das transações de retirada dos usuários, realizando uma investigação de ataque. Neste momento, os ativos do usuário estão seguros, mas podem não ser retirados;

3. lockers bloqueio malicioso da ponte cross-chain, impedindo a execução de todas as transações de retirada, só podendo esperar o desbloqueio do coldValidatorSet.

HyperEVM e Arquitetura de Interação de Duas Cadeias

Para realizar a programação do comércio de livros de pedidos, como a introdução de cenários de negociação privada que requerem suporte de contratos inteligentes, a Hyperliquid lançou a solução HyperEVM. Esta solução tem duas grandes vantagens em relação ao EVM tradicional: pode ler o estado do livro de pedidos da Hyperliquid e os contratos inteligentes internos podem interagir com o sistema de livro de pedidos, ampliando significativamente os cenários de aplicação.

Por exemplo, se os usuários precisarem garantir a privacidade das ordens pendentes, podem adicionar uma camada de privacidade através de contratos semelhantes ao Tornado Cash na HyperEVM, e depois acionar a ordem pendente no sistema de livro de ordens Hyperliquid através de uma interface específica.

Hyperliquid projetou uma arquitetura especial para o HyperEVM. Considerando que o desempenho do sistema de livro de ordens personalizado supera em muito o ambiente EVM, para evitar a diminuição da velocidade, a Hyperliquid adotou uma "solução de dupla cadeia": cada nó executa simultaneamente duas cadeias, armazena localmente os dados de ambas as cadeias e processa as transações separadamente.

Hyperliquid configura uma cadeia dedicada para o sistema de livro de ordens (HyperL1, com permissão ), e simultaneamente introduz uma cadeia compatível com EVM (HyperEVM, sem permissão ). Os dados das duas cadeias são propagados através do mesmo protocolo de consenso, existindo como um estado unificado, mas operando em ambientes diferentes. A velocidade de geração de blocos do HyperL1 é mais rápida do que a do HyperEVM, mas os blocos ainda são executados em ordem. Os contratos na cadeia EVM podem ler dados de blocos L1 anteriores e escrever dados em blocos L1 futuros.

A interação entre HyperL1 e HyperEVM é realizada principalmente através de Precompiles e Eventos.

Precompiles

Pré-compilados (Precompiles) implementam operações complexas diretamente na camada inferior, utilizando linguagens como C/C++ para processar cálculos desfavoráveis ao Solidity. A pré-compilação é essencialmente um contrato inteligente especial, que outros contratos podem chamar e obter resultados de execução. Atualmente, a EVM nativa já implementou o comando ecRecover com pré-compilação (0x01 endereço ).

HyperEVM também adicionou código pré-compilado para permitir a leitura do estado do sistema de livro de ordens Hyperliquid. Um endereço pré-compilado conhecido é 0x0000000000000000000000000000000000000800, que pode ler as posições de contratos perpétuos dos usuários no bloco L1 mais recente.

Eventos

A HyperEVM escreve dados para o HyperL1 dependendo da implementação de Events. Events são um conceito nativo do EVM, permitindo que contratos enviem informações de log para o exterior. Por exemplo, ao fazer uma transferência ERC-20, um evento Transfer é disparado, facilitando a escuta. Muitos cenários de cross-chain também utilizam Events para transmitir parâmetros.

O nó HyperLiquid escuta os eventos emitidos pelo endereço 0x3333333333333333333333333333333333333333, obtendo informações sobre a intenção do usuário e convertendo-a em ações de negociação, gravando em futuros blocos L1. Se esse endereço fornecer uma função, ao ser chamada, ela emite o evento IocOrder; quando o bloco L1 é minerado, o nó detecta o novo evento IocOrder e o converte em operações de ordem pendente dentro do L1.

HyperBFT

No que diz respeito ao protocolo de consenso, a Hyperliquid utiliza o protocolo HyperBFT derivado do HotStuff. Inicialmente, era utilizado o algoritmo Tendermint, mas a eficiência era baixa, necessitando de trocas de mensagens All-to-All em cada fase, com complexidade O(n²).

Para atingir a velocidade de uma exchange centralizada, a equipe desenvolveu o HyperBFT e o implementou em Rust, podendo teoricamente processar 2 milhões de ordens por segundo. Todas as mensagens no HyperBFT são agregadas e transmitidas pelo Líder, eliminando a troca de mensagens entre nós, reduzindo significativamente a complexidade.

Em resumo, o HyperBFT é um protocolo de consenso em que o líder atual produz blocos, todos os nós votam e enviam os resultados ao líder, que depois alterna para o próximo líder.

Atenção para desenvolvedores

1. O mecanismo de leitura de dados baseado em Precompiles é bastante completo, mas é necessário ter atenção ao problema do msg.sender. Quando os usuários interagem com contratos do sistema L1, desencadeando indiretamente transações EVM, o msg.sender dentro da EVM é o endereço do contrato do sistema L1 e não o endereço do usuário.

2. Existem problemas de não atomicidade na interação entre EVM e L1. Por exemplo, se um usuário faz uma ordem na L1 através da EVM mas não tem fundos suficientes, a transação falha, mas não há mensagens de erro ao chamar a função. Os desenvolvedores precisam tratar a situação de falha da ordem no lado do contrato EVM e configurar uma função de recuperação de fundos.

3. O endereço do contrato EVM deve ter uma conta mapeada no L1. Após implantar o contrato EVM, deve-se transferir uma pequena quantidade de USDC para o endereço mapeado do L1 para criar a conta.

4. Preste atenção a situações especiais, como o saldo de tokens. O L1 possui endereços especiais para a transferência de ativos entre cadeias, mas após a transferência, o EVM pode não gerar blocos a tempo, e os usuários podem não conseguir ler o saldo temporariamente. Os desenvolvedores devem lidar com essas situações para evitar pânico entre os usuários.