Analyse approfondie de Hyperliquid sous l'angle technique : contrats de pont, HyperEVM et problèmes potentiels

Hyperliquid, en tant qu'échange de carnet de commandes sur la chaîne très en vue, mérite une attention particulière sur son architecture technique et sa sécurité. Cet article analysera trois aspects : la structure des contrats de pont inter-chaînes, les caractéristiques techniques de HyperEVM et les potentielles vulnérabilités de sécurité.

Analyse du pont inter-chaînes Hyperliquid

Hyperliquid a déployé un contrat de pont inter-chaînes sur Arbitrum pour stocker les actifs USDC des utilisateurs. Du point de vue de l'identité des nœuds, Hyperliquid a quatre groupes de validateurs :

• hotValidatorSet: responsable du traitement des opérations à haute fréquence telles que les retraits des utilisateurs
• coldValidatorSet : responsable de la modification de la configuration du système et du traitement des situations exceptionnelles
• lockers : similaire à un comité de sécurité, peut voter pour suspendre le contrat de pont
• finalisateurs : confirmer les changements d'état du pont inter-chaînes

Processus de dépôt

Le contrat de pont utilise la méthode Permit de l'EIP-2612 pour traiter les dépôts, n'autorisant que les dépôts en USDC. L'opération de dépôt est assez simple, principalement traitée par la fonction batchedDepositWithPermit.

Processus de retrait

Le processus de retrait est relativement complexe :

1. L'utilisateur initie une demande de retrait
2. Confirmation du poids de signature de 2/3 du hotValidatorSet
3. Période de contestation de 200 secondes
4. confirmation finale des membres des finalizers

Pendant la période de litige, les lockers peuvent voter pour geler le contrat, et le coldValidatorSet peut rendre certains retraits invalides.

Mécanisme de verrouillage du contrat de pont

Les membres de lockers peuvent appeler la fonction voteEmergencyLock pour voter, 2 membres doivent voter pour verrouiller le contrat de pont. Le déverrouillage nécessite la signature de 2/3 du coldValidatorSet.

Mise à jour du groupe de validateurs

Mettez à jour hotValidatorSet et coldValidatorSet via la fonction updateValidatorSet, nécessitant la signature de tous les membres de hotValidatorSet, avec une période de contestation de 200 secondes.

principaux points de risque

1. coldValidatorSet contrôlé peut contourner toutes les défenses pour voler des actifs
2. Les finalisateurs peuvent refuser de confirmer des transactions de retrait, ce qui empêche les utilisateurs de retirer leurs actifs.
3. lockers verrouillage malveillant des contrats de pont, entrave aux retraits

HyperEVM et architecture d'interaction à double chaîne

Pour réaliser la programmabilité des échanges sur le carnet de commandes, Hyperliquid a lancé la solution HyperEVM. Ses caractéristiques sont :

1. État du carnet de commandes Hyperliquid lisible
2. Peut interagir avec le système de carnet de commandes Hyperliquid

Hyperliquid adopte un "schéma à double chaîne", fonctionnant simultanément sur deux chaînes :

• Hyperliquid L1 : chaîne dédiée au carnet de commandes, système de permission
• HyperEVM: chaîne compatible EVM, sans autorisation

Les deux chaînes interagissent via des Precompiles et des Events :

• Precompiles : code précompilé, permettant à l'EVM de lire l'état L1
• Événements : L'événement EVM est déclenché, le nœud L1 écoute et exécute l'opération correspondante

Consensus HyperBFT

Hyperliquid utilise un algorithme de consensus HyperBFT amélioré basé sur HotStuff, capable de traiter théoriquement 2 millions de commandes par seconde.

Remarques pour les développeurs

1. msg.sender peut être l'adresse d'un contrat système, pas l'adresse d'un utilisateur.
2. L'interaction entre EVM et L1 n'est pas atomique, il faut gérer les cas d'échec.
3. L'adresse du contrat EVM doit créer un compte de mapping sur L1
4. Pendant le processus de transfert d'actifs entre chaînes, le solde peut être temporairement invisible.

Résumé

Hyperliquid combine un carnet de commandes hautes performances et une programmabilité grâce à une architecture à double chaîne et des mécanismes d'interaction innovants. Cependant, son mécanisme de validateurs complexe et ses interactions inter-chaînes présentent également des risques de sécurité potentiels, qui méritent une attention et une optimisation supplémentaires.