Analyse approfondie de l'architecture et des problèmes potentiels de Hyperliquid du point de vue technique

Un échange décentralisé sur la blockchain récemment sous les projecteurs est devenu l'un des projets les plus influents, avec une valeur totale de valeur verrouillée (TVL) dépassant 2 milliards de dollars, et est qualifié de "version blockchain d'un célèbre échange centralisé". Ce projet a même ramené les concepts de Layer3 et de chaînes d'applications sous les feux de la rampe. Avec un exploit remarquable atteignant une valorisation de 30 milliards de dollars en un mois, ce projet a attiré une attention considérable. De nombreux rapports de recherche ont émergé sur le marché, mais la plupart se concentrent sur les fonctionnalités du produit et les mécanismes de trading, avec peu d'explorations approfondies de sa structure technique et des risques de sécurité.

Cet article vise à combler cette lacune en examinant le projet purement du point de vue de la construction technique et de la sécurité, afin d'aider davantage de personnes à comprendre sa structure et ses principes. Nous aborderons deux grands aspects : la construction et les risques des contrats de pont inter-chaînes, ainsi que la construction à double chaîne, en analysant en profondeur l'architecture technique et les méthodes de mise en œuvre qui se cachent derrière.

Analyse du contrat de pont inter-chaînes

Ce projet a déployé un contrat de pont inter-chaînes sur un réseau Layer2, destiné à stocker les actifs USDC déposés par les utilisateurs. On peut observer certains comportements des nœuds à partir du contrat.

Ensemble des validateurs

Ce projet a 4 groupes de validateurs, à savoir le groupe de validateurs chauds, le groupe de validateurs froids, ainsi que les décideurs et les bloqueurs, chacun ayant des fonctions différentes :

• Les validateurs chauds sont utilisés pour répondre aux opérations fréquentes des utilisateurs, comme les retraits, en utilisant un portefeuille chaud pour répondre aux demandes des utilisateurs à tout moment.

• Le groupe de validateurs froids est principalement utilisé pour modifier la configuration du système, comme la modification de la liste des validateurs, le traitement de l'état de verrouillage des contrats de pont, et peut directement rendre certaines demandes de retrait invalides.

• Les personnes verrouillées ressemblent à un "comité de sécurité", qui peut voter pour suspendre le pont inter-chaînes en cas d'urgence. Actuellement, il y a 5 adresses, seulement 2 votes sont nécessaires pour suspendre le contrat du pont.

• Le décideur confirme principalement les changements d'état du pont inter-chaînes, tels que les dépôts et retraits des utilisateurs.

Dépôt

Le contrat de pont traite les dépôts des utilisateurs en utilisant la méthode Permit de l'EIP-2612, n'autorisant que les dépôts en USDC. Utilisez la fonction de dépôt en masse pour gérer plusieurs dépôts, le processus est simple et sans risque de fonds.

Retrait

Le retrait est une opération à haut risque, le processus est assez complexe :

1. Après qu'un utilisateur ait initié une demande de retrait, il doit obtenir 2/3 du poids de signature du groupe de validateurs chauds.

2. Il y a une "période de contestation" de 200 secondes, pendant laquelle les personnes verrouillées peuvent voter pour geler le contrat, et les validateurs à froid peuvent rendre le retrait invalide.

3. Après la période de contestation, le décideur peut confirmer l'état final, et l'USDC sera transféré dans le portefeuille de l'utilisateur.

Contrat de pont verrouillé

Les utilisateurs verrouillés peuvent voter pour verrouiller le contrat de pont. Une fois que 2 utilisateurs verrouillés ont voté, le contrat est suspendu. Les utilisateurs verrouillés peuvent également retirer leur vote. Une fois le contrat verrouillé, il ne peut être déverrouillé que par la signature de 2/3 des validateurs à froid. Lors du déverrouillage, la liste des validateurs sera mise à jour.

Mise à jour des validateurs

La mise à jour du validateur nécessite la signature de tous les validateurs chauds, avec une période de contestation de 200 secondes. Une fois cette période écoulée, une confirmation de l'acheteur est nécessaire pour finaliser la mise à jour.

Principaux risques

1. Les hackers contrôlant des validateurs froids peuvent ignorer les obstacles pour voler les actifs des utilisateurs.

2. Le décideur peut refuser de confirmer la transaction de retrait et lancer un examen d'attaque.

3. Les personnes malveillantes verrouillent le contrat du pont, suspendent tous les retraits.

Architecture d'interaction à double chaîne

Pour rendre le trading sur carnet d'ordres programmable, le projet a lancé une solution EVM spéciale. Son avantage est qu'il peut lire l'état du carnet d'ordres, le contrat intelligent peut interagir avec le système de commandes, élargissant les cas d'utilisation.

Ce projet adopte un "schéma à double chaîne", les nœuds exécutent simultanément deux chaînes :

1. Chaîne dédiée au livre de commandes : système de permission, haute performance

2. Chaînes compatibles avec EVM : sans autorisation, possibilité de déployer des contrats intelligents, accès aux données de chaînes dédiées via des précompilations.

Les deux chaînes transmettent des données via le même protocole de consensus, mais s'exécutent séparément. La chaîne EVM peut lire les données des blocs de la chaîne dédiée passée et écrire des données dans les blocs futurs.

Mécanisme d'interaction

1. Précompilation : ajout de contrats spéciaux, permettant à l'EVM de lire l'état de la chaîne dédiée.

2. Événement : Les contrats EVM peuvent déclencher des événements, les nœuds exécutent des opérations correspondantes sur la chaîne dédiée.

Protocole de consensus

En utilisant le protocole HyperBFT basé sur HotStuff, il est théoriquement possible de traiter 2 millions de commandes par seconde.

Remarques sur le développement

1. msg.sender peut être l'adresse d'un contrat système

2. L'interaction non atomique peut entraîner une perte d'actifs

3. L'adresse du contrat EVM doit être mappée sur la chaîne dédiée.

4. Il se peut que le solde ne soit temporairement pas consultable lors du transfert d'actifs entre chaînes.

En résumé, la chaîne EVM de ce projet est similaire à une couche 2 de chaîne dédiée, mais offre une interopérabilité plus élevée. Son architecture innovante propose de nouvelles idées pour la combinaison d'un livre de commandes haute performance et de contrats intelligents, mais cela entraîne également certains risques potentiels et des difficultés de développement.