Análise profunda do Hyperliquid: examinando este projeto inovador sob a perspectiva técnica e de segurança

Recentemente, a Hyperliquid, como uma bolsa de pedidos on-chain muito comentada, teve seu TVL ultrapassando 2 bilhões de dólares, sendo considerada uma "plataforma de negociação on-chain". Este artigo pretende analisar profundamente a Hyperliquid do ponto de vista da construção técnica e da segurança, ajudando os leitores a entender a arquitetura técnica e os métodos de implementação por trás dela. Vamos focar na construção e nas potenciais vulnerabilidades do contrato da ponte cross-chain da Hyperliquid, bem como na construção de dupla cadeia do HyperEVM e do HyperL1.

Análise da ponte跨链 Hyperliquid

Como a Hyperliquid apenas tornou o contrato da ponte de código aberto, podemos entender parte de seu mecanismo de operação analisando esse contrato. A Hyperliquid implantou um contrato da ponte em uma rede Layer2, destinado a armazenar os ativos USDC dos usuários.

Conjunto de Validadores

Hyperliquid tem 4 grupos de validadores:

• hotValidatorSet: trata operações de alta frequência, como retiradas de usuários
• coldValidatorSet: responsável pela modificação da configuração do sistema
• finalizadores: confirmar a mudança de estado da ponte entre cadeias
• lockers: lidar com situações de emergência, pode suspender o contrato da ponte

Atualmente, a Hyperliquid tem apenas 4 nós de validação, hotValidatorSet e coldValidatorSet correspondem a 4 endereços na blockchain.

Processo de depósito

Os contratos do Hyperliquid Bridge utilizam o método Permit do EIP-2612 para processar depósitos, suportando apenas USDC. O processo de depósito é relativamente simples, principalmente utilizando a função batchedDepositWithPermit para processamento em lote.

Processo de levantamento

O levantamento é uma operação de alto risco, com um processo relativamente complexo:

1. O usuário inicia um pedido de retirada
2. É necessário obter 2/3 do peso de assinatura do hotValidatorSet
3. Entrar no "período de controvérsia" de 200 segundos
4. Após o término do período de disputas, os membros dos finalizadores confirmam o estado final.

O processo de levantamento tem três camadas de proteção:

1. É necessário controlar o peso da assinatura de 2/3 do hotValidatorSet.
2. Evitar ser descoberto durante o período de disputa
3. Obter a chave privada de pelo menos um membro dos finalizadores

Mecanismo de bloqueio de contrato de ponte

Os membros dos lockers podem votar para bloquear o contrato da ponte através da função voteEmergencyLock. Atualmente, são necessários 2 votos dos lockers para bloquear. Depois de bloqueado, só pode ser desbloqueado através da função emergencyUnlock do coldValidatorSet.

Atualização do conjunto de validadores

Pode atualizar o conjunto de validadores através da função updateValidatorSet, sendo necessário a assinatura de todos os membros do hotValidatorSet, e há um período de contestação de 200 segundos.

Riscos potenciais

1. coldValidatorSet controlado pode contornar a defesa e roubar ativos
2. os finalizadores podem recusar a confirmação de transações de retirada
3. os lockers podem bloquear maliciosamente o contrato da ponte

HyperEVM e a arquitetura de interação de duas cadeias

Para alcançar a programabilidade das transações no livro de ordens, a Hyperliquid lançou a solução HyperEVM. Esta pode ler o estado do livro de ordens da Hyperliquid e interagir com ele.

Hyperliquid adota a "solução de dupla cadeia":

• Hyperliquid L1(L1): cadeia exclusiva para livros de ordens, com licença
• HyperEVM(EVM): cadeia sem permissões, contratos inteligentes podem ser implantados

As duas cadeias interagem através de Precompiles e Events:

Precompiles

HyperEVM adicionou código pré-compilado, permitindo que o EVM leia o estado do sistema de livro de ordens Hyperliquid.

Eventos

HyperEVM pode escrever dados para L1 através de Events. Os nós Hyperliquid escutam os Events de endereços específicos, transformando a intenção do usuário em transações L1.

HyperBFT consenso

Hyperliquid utiliza o protocolo de consenso HyperBFT baseado em HotStuff, que teoricamente pode processar 2 milhões de ordens por segundo.

Avisos para desenvolvedores

1. msg.sender pode ser o endereço do contrato do sistema L1 e não o endereço do usuário
2. Existe um problema de não atomicidade na interação entre EVM e L1
3. O endereço do contrato EVM deve ter uma conta mapeada em L1
4. A transferência de ativos entre cadeias pode causar a invisibilidade temporária do saldo

De um modo geral, o HyperEVM é semelhante ao Layer 2 do Hyperliquid L1, mas oferece uma maior interoperabilidade. Os desenvolvedores devem estar atentos às situações especiais mencionadas acima para garantir a segurança do protocolo e a experiência do usuário.