Análise aprofundada do Hyperliquid: arquitetura técnica e riscos potenciais

Hyperliquid, como uma bolsa de ordens on-chain muito comentada, tem sua arquitetura técnica e segurança que merecem uma análise aprofundada. Este artigo irá analisar a implementação técnica do Hyperliquid em duas perspectivas: a estrutura do contrato da ponte cross-chain e a arquitetura de dupla cadeia HyperEVM e HyperL1.

Análise da Ponte Cross-Chain Hyperliquid

A Hyperliquid implementou um contrato de ponte na Arbitrum para armazenar os ativos USDC dos usuários. Este contrato de ponte contém quatro conjuntos de validadores: hotValidatorSet, coldValidatorSet, finalizers e lockers, cada um responsável por diferentes funções.

mecanismo de validadores

• hotValidatorSet: tratar operações de alta frequência, como retiradas de usuários
• coldValidatorSet: modificar a configuração do sistema, pode invalidar pedidos de retirada
• lockers: possibilidade de votar para pausar a operação do contrato da ponte
• finalizers: confirmar a mudança de estado da ponte entre cadeias

Atualmente, o Hyperliquid tem apenas 4 nós validadores, o hotValidatorSet e o coldValidatorSet correspondem a 4 endereços cada.

processo de depósito

O contrato de ponte utiliza o método Permit do EIP-2612 para processar depósitos, permitindo apenas a entrada de USDC. A função batchedDepositWithPermit pode processar múltiplos depósitos em lote, e o processo é relativamente simples.

Processo de Retirada

Os pedidos de retirada devem cumprir as seguintes condições:

1. Obter 2/3 do peso de assinatura do hotValidatorSet
2. Após 200 segundos de período de controvérsia
3. Confirmado finalmente pelos membros dos finalizadores

Durante o período de disputa, os lockers podem votar para suspender o contrato de ponte, e o coldValidatorSet pode invalidar os pedidos de retirada.

mecanismo de bloqueio do contrato de ponte

2 votantes de lockers podem bloquear o contrato da ponte. O desbloqueio requer 2/3 do peso da assinatura do coldValidatorSet e também pode atualizar o endereço do validador.

Atualização do validador

A função updateValidatorSet pode atualizar o hotValidatorSet e o coldValidatorSet, necessitando da assinatura de todos os membros do hotValidatorSet e passando por um período de contestação de 200 segundos.

Riscos potenciais

1. coldValidatorSet controlado pode contornar todas as defesas para roubar ativos dos usuários
2. os finalizadores podem recusar a confirmação de transações de retirada
3. lockers podem bloquear maliciosamente o contrato da ponte

HyperEVM e Arquitetura de Dupla Cadeia

Hyperliquid utiliza um "sistema de duas cadeias", operando simultaneamente em duas cadeias:

1. Hyperliquid L1: dedicado ao sistema de livro de ordens, licenciado
2. HyperEVM: cadeia compatível com EVM, sem permissões

As duas cadeias propagam dados por meio do mesmo protocolo de consenso, mas operam em ambientes de execução diferentes. HyperEVM pode ler o estado L1 e escrever dados no L1.

Precompiles

HyperEVM lê o estado do L1 através de código pré-compilado. O endereço pré-compilado conhecido 0x800 pode ler as posições de contratos perpétuos de usuários do bloco L1 mais recente.

Eventos

HyperEVM escreve dados para o L1 através de Eventos. Os nós L1 escutam Eventos de um endereço específico (0x3333...3333) e transformam a intenção do usuário em transações L1.

HyperBFT consenso

Hyperliquid utiliza o algoritmo de consenso HyperBFT baseado em HotStuff, podendo teoricamente processar 2 milhões de pedidos por segundo.

Considerações importantes para o desenvolvimento

1. msg.sender pode ser o endereço do contrato do sistema L1
2. A interação EVM com L1 não atômica pode levar à perda de ativos
3. O endereço do contrato EVM deve ter uma conta mapeada na L1
4. Pode ocorrer uma situação em que não é possível consultar o saldo temporariamente durante a transferência de ativos entre cadeias.

No geral, o HyperEVM é semelhante a uma camada dois baseada no Hyperliquid L1, mas oferece maior interoperabilidade.