Exploration approfondie de la structure technique et des risques de sécurité de Hyperliquid

Récemment, Hyperliquid, qui a suscité beaucoup d'attention, est l'une des bourses d'ordres en chaîne les plus influentes, avec une valeur totale verrouillée dépassant 2 milliards de dollars. Il est évalué par les professionnels de l'industrie comme "la version en chaîne d'un certain échange centralisé bien connu", et a également relancé les discussions sur Layer3 et les chaînes d'applications. Grâce à une valorisation de 30 milliards de dollars dans le mois suivant son lancement, Hyperliquid a attiré une large attention. Actuellement, il existe de nombreux rapports d'analyse sur Hyperliquid sur le marché, mais la plupart se concentrent sur les fonctionnalités du produit et le mécanisme de trading, manquant d'une analyse approfondie de son architecture technique et des risques de sécurité potentiels.

Cet article vise à combler cette lacune en analysant Hyperliquid uniquement sous un angle technique et de sécurité, afin d'aider les lecteurs à mieux comprendre la structure interne et les principes de ce projet phare. Nous allons nous concentrer sur l'analyse de la conception et des risques des contrats de pont inter-chaînes d'Hyperliquid, ainsi que sur l'architecture à double chaîne d'HyperEVM et d'HyperL1, en explorant en profondeur les méthodes techniques qui se cachent derrière.

Analyse du pont inter-chaînes Hyperliquid

Étant donné que Hyperliquid n'a pas rendu ses composants principaux open source, mais a ouvert l'accès aux contrats de pont associés, nous avons une meilleure compréhension des risques liés aux contrats de pont. Hyperliquid a déployé un contrat de pont sur un réseau Layer2, destiné à stocker les actifs USDC déposés par les utilisateurs, et nous pouvons observer certains comportements des nœuds Hyperliquid via le composant Bridge.

ensemble de validateurs

En termes de classification des identités des nœuds, Hyperliquid dispose de 4 groupes de validateurs, à savoir hotValidatorSet, coldValidatorSet ainsi que les finalizers et lockers, chacun ayant des responsabilités différentes. Le hotValidatorSet est responsable de la réponse aux opérations fréquentes des utilisateurs telles que les retraits, utilisant généralement des portefeuilles chauds pour traiter rapidement les demandes des utilisateurs.

coldValidatorSet est principalement utilisé pour modifier la configuration du système, comme mettre à jour la liste des autres ensembles de validateurs ou gérer l'état de verrouillage des contrats de pont, et a le pouvoir d'invalider directement certaines demandes de retrait.

Les lockers sont un groupe de validateurs avec des droits spéciaux, similaires au "comité de sécurité" couramment rencontré dans Layer2, qui peuvent voter pour décider de suspendre le fonctionnement du pont inter-chaînes en cas d'urgence. Actuellement, l'ensemble des lockers du pont Hyperliquid comprend 5 adresses, et seulement 2 lockers doivent voter pour suspendre le contrat du pont.

Les finalizers sont également un groupe de validateurs spéciaux, principalement utilisés pour confirmer les changements d'état des ponts inter-chaînes, comme les opérations de dépôt et de retrait des utilisateurs. Le pont inter-chaînes de Hyperliquid utilise un mécanisme de "soumission-confirmation", où l'utilisateur doit attendre une période de "contestation" après avoir initié un retrait, et après cette période, les finalizers exécutent la transaction de retrait.

En cas de problème, si une demande de retrait dépasse le solde réel de l'utilisateur, le nœud Hyperliquid peut voter via les lockers pour suspendre le contrat de pont pendant la période de contestation, ou le coldValidatorSet peut directement rendre le retrait problématique invalide.

Actuellement, Hyperliquid n'a que 4 nœuds validateurs, donc hotValidatorSet et coldValidatorSet correspondent chacun à 4 adresses on-chain. Lors de l'initialisation, Hyperliquid enregistre automatiquement les adresses à l'intérieur de hotValidatorSet en tant que membres de lockers et finalizers, tandis que coldValidatorSet est contrôlé par l'équipe officielle, utilisant un portefeuille froid pour stocker les clés.

Dépôt

Le contrat de pont d'Hyperliquid utilise la méthode Permit de l'EIP-2612 pour traiter les dépôts des utilisateurs et ne prend en charge qu'un seul actif, l'USDC. Par rapport au modèle traditionnel d'Approve-Transfer, le modèle Permit est plus simple et facilite les opérations en masse.

Le contrat de pont utilise la fonction batchedDepositWithPermit pour traiter plusieurs dépôts en batch, le processus est simple et sans risque pour la sécurité des fonds, principalement en utilisant la méthode Permit pour optimiser l'expérience utilisateur.

Retrait

Comparé aux dépôts, les retraits sont des opérations à haut risque, donc la logique est plus complexe. Après qu'un utilisateur ait initié une demande de retrait, le nœud Hyperliquid appelle la fonction batchedRequestWithdrawals du contrat de pont. À ce moment, chaque demande de retrait doit obtenir 2/3 du poids de signature du hotValidatorSet, notez qu'il s'agit de "poids de signature 2/3" et non de "nombre de signatures 2/3". Actuellement, Hyperliquid n'a que 4 nœuds avec un poids identique, donc la vérification du poids de signature et du nombre de signatures est temporairement cohérente, mais des nœuds à poids élevé pourraient être introduits à l'avenir.

Après avoir soumis une demande de retrait, le pont inter-chaînes ne transférera pas immédiatement l'USDC, mais il y aura une "période de contestation" de 200 secondes. Pendant cette période, deux scénarios peuvent se produire:

1. Les lockers estiment qu'il y a un problème grave avec la demande de retrait et peuvent voter directement pour geler le contrat;

2. Les nœuds considèrent que certains retraits posent problème, les membres du coldValidatorSet peuvent appeler la fonction invalidateWithdrawals pour rendre ce retrait invalide.

Si aucune anomalie n'est constatée pendant la période de contestation, les membres des finalizers peuvent appeler la fonction batchedFinalizeWithdrawals pour confirmer l'état final, c'est à ce moment-là que l'USDC sera transféré dans le portefeuille de l'utilisateur sur Layer2.

Du point de vue du modèle de sécurité, si un attaquant malveillant souhaite agir de manière malveillante dans le processus de retrait de Hyperliquid, il doit franchir trois lignes de défense :

1. Maîtriser le poids de signature de 2/3 de hotValidatorSet, c'est-à-dire obtenir suffisamment de clés privées ou conspirer. Actuellement, il n'y a que 4 validateurs, la possibilité d'être contrôlé ou de conspirer n'est pas négligeable;

2. Évitez que des transactions malveillantes soient détectées pendant la période de litige, sinon cela pourrait déclencher le verrouillage des contrats par les lockers.

3. Obtenez au moins une clé privée d'un membre des finalizers pour confirmer le retrait. Actuellement, les finalizers sont essentiellement identiques aux membres du hotValidatorSet, donc satisfaire la condition 1 suffit pour satisfaire la condition 3.

Verrouillage du contrat de pont

Hyperliquid a mis en place une fonction de verrouillage des contrats de pont inter-chaînes. Plus précisément, les membres des lockers doivent appeler la fonction voteEmergencyLock pour voter. Actuellement, 2 membres des lockers peuvent voter pour verrouiller et suspendre le contrat de pont.

Il est important de noter que le pont Hyperliquid propose également la fonction unvoteEmergencyLock, permettant aux lockers de retirer leur vote. Une fois que le contrat du pont est verrouillé, il ne peut être déverrouillé que par la fonction emergencyUnlock, nécessitant la collecte d'un poids de signature de plus de 2/3 des membres du coldValidatorSet.

L'activation de emergencyUnlock mettra à jour les ensembles d'adresses des validateurs hotValidatorSet et coldValidatorSet, et prendra effet immédiatement.

Mise à jour de l'ensemble des validateurs

Comparé à la percée des défenses du processus de retrait, l'utilisation directe de la fonction updateValidatorSet pour mettre à jour l'ensemble des validateurs est une méthode d'attaque plus efficace. Cela nécessite la signature de tous les membres de hotValidatorSet et il y a une période de contestation de 200 secondes.

Après la période de contestation, les membres des finalizers doivent appeler la fonction finalizeValidatorSetUpdate pour compléter la mise à jour finale.

Les risques suivants existent avec le contrat de pont Hyperliquid :

1. Les hackers peuvent ignorer les obstacles et voler les actifs des utilisateurs après avoir pris le contrôle du coldValidatorSet. Étant donné que le coldValidatorSet possède le droit d emergencyUnlock, il peut rendre les lockers inopérants et mettre à jour immédiatement la liste des nœuds. Actuellement, il n'y a que 4 nœuds validateurs, le risque de vol de clé privée n'est pas négligeable;

2. Les finalizers refusent de confirmer les transactions de retrait des utilisateurs, lançant une attaque d'examen. À ce stade, les actifs de l'utilisateur sont en sécurité mais peuvent ne pas être retirés;

3. Les lockers verrouillent malicieusement le pont inter-chaînes, empêchant l'exécution de toutes les transactions de retrait, il faut attendre que le coldValidatorSet soit déverrouillé.

HyperEVM et architecture d'interaction à double chaîne

Pour réaliser la programmabilité du trading sur carnet d'ordres, comme l'introduction de transactions privées et d'autres scénarios nécessitant le soutien des contrats intelligents, Hyperliquid a lancé la solution HyperEVM. Elle présente deux grands avantages par rapport à l'EVM traditionnel : elle peut lire l'état du carnet d'ordres Hyperliquid et les contrats intelligents internes peuvent interagir avec le système de carnet d'ordres, élargissant considérablement les cas d'utilisation.

Par exemple, si un utilisateur souhaite garantir la confidentialité de ses ordres, il peut ajouter une couche de confidentialité via un contrat similaire à Tornado Cash sur HyperEVM, puis déclencher l'ordre dans le système de carnet de commandes Hyperliquid via une interface spécifique.

Hyperliquid a conçu une architecture spéciale pour HyperEVM. Étant donné que les performances du système de livre de commandes personnalisé dépassent de loin celles de l'environnement EVM, pour éviter une baisse de vitesse, Hyperliquid utilise une "solution à double chaîne" : chaque nœud exécute simultanément deux chaînes, stocke localement les données des deux chaînes et traite les transactions séparément.

Hyperliquid a établi une chaîne dédiée pour son système de carnet de commandes (HyperL1, sous un régime de permission ), tout en ajoutant une chaîne compatible EVM (HyperEVM, sans permission ). Les données des deux chaînes sont propagées via le même protocole de consensus, existant comme un état unifié, mais fonctionnant dans des environnements différents. HyperL1 a une vitesse de bloc plus rapide que HyperEVM, mais les blocs sont toujours exécutés dans l'ordre. Les contrats sur la chaîne EVM peuvent lire les données des blocs L1 passés et écrire des données dans les blocs L1 futurs.

L'interaction entre HyperL1 et HyperEVM se fait principalement via des Precompiles et des Events.

Précompilations

Précompilation(Precompiles) implémente des opérations complexes directement au niveau de la couche inférieure, en utilisant des langages tels que C/C++ pour traiter des calculs peu compatibles avec Solidity. La précompilation est essentiellement un contrat intelligent spécial, d'autres contrats peuvent l'appeler et obtenir des résultats d'exécution. Actuellement, l'EVM natif a utilisé la précompilation pour implémenter l'instruction ecRecover(0x01 adresse).

HyperEVM a également ajouté du code précompilé pour permettre la lecture de l'état du système de carnet de commandes Hyperliquid. Une adresse précompilée connue est 0x0000000000000000000000000000000000000800, qui permet de lire les positions des contrats perpétuels des utilisateurs dans le dernier bloc L1.

Événements

HyperEVM écrit des données vers HyperL1 en s'appuyant sur les événements. Les événements sont un concept natif de l'EVM, permettant aux contrats d'envoyer des informations de journal à l'extérieur. Par exemple, lors d'un transfert ERC-20, un événement Transfer est émis, ce qui facilite l'écoute. De nombreux scénarios de cross-chain utilisent également des événements pour transmettre des paramètres.

Le nœud HyperLiquid écoute les événements émis par l'adresse 0x3333333333333333333333333333333333333333, déduit l'intention de l'utilisateur à partir des informations et les transforme en actions de transaction, écrites dans le futur bloc L1. Si cette adresse fournit une fonction, l'appel génère un événement IocOrder. Lorsque le bloc L1 est créé, le nœud récupère le nouvel événement IocOrder et le transforme en opération de commande en attente sur L1.

HyperBFT

En ce qui concerne le protocole de consensus, Hyperliquid utilise le protocole HyperBFT dérivé de HotStuff. Au départ, l'algorithme Tendermint était utilisé, mais il était peu efficace, nécessitant un échange de messages All-to-All à chaque étape, avec une complexité de O(n²).

Pour atteindre la vitesse des échanges centralisés, l'équipe a développé HyperBFT et l'a implémenté en Rust, pouvant théoriquement traiter 2 millions d'ordres par seconde. Tous les messages dans HyperBFT sont résumés et diffusés par le Leader, éliminant les échanges de messages entre les nœuds, réduisant ainsi considérablement la complexité.

En résumé, HyperBFT est un protocole de consensus où le leader actuel produit des blocs, tous les nœuds votent et envoient les résultats au leader, puis un nouveau leader est élu.

Remarques pour les développeurs

1. Le mécanisme de lecture des données basé sur les Precompiles est assez complet, mais il faut faire attention au problème de msg.sender. Lorsque les utilisateurs interagissent avec le contrat du système L1, cela déclenche indirectement une transaction EVM, et dans l'EVM, msg.sender est l'adresse du contrat du système L1 et non l'adresse de l'utilisateur.

2. Il existe un problème de non-atomicité dans l'interaction entre l'EVM et le L1. Par exemple, si un utilisateur passe une commande sur le L1 via l'EVM mais que les actifs sont insuffisants, la transaction échoue sans message d'erreur lors de l'appel de la fonction. Les développeurs doivent gérer les situations d'échec de commande du côté du contrat EVM et mettre en place une fonction de récupération des fonds.

3. L'adresse du contrat EVM doit avoir un compte mappé sur L1. Après le déploiement du contrat EVM, il est nécessaire de transférer une petite quantité de USDC à l'adresse mappée sur L1 pour créer un compte.

4. Faites attention aux situations spéciales telles que le solde des tokens. L1 a des adresses spéciales pour le transfert d'actifs entre chaînes, mais après le transfert, l'EVM peut ne pas produire de blocs à temps, rendant temporairement impossible pour l'utilisateur de lire son solde. Les développeurs doivent gérer de telles situations pour éviter la panique parmi les utilisateurs.