Analyse approfondie de Hyperliquid : un examen de ce projet innovant sous l'angle technique et de la sécurité

Récemment, Hyperliquid, en tant qu'échange de livres de commandes en ligne très médiatisé, a dépassé un TVL de 2 milliards de dollars et est salué comme une "plateforme de trading en ligne". Cet article vise à analyser en profondeur Hyperliquid d'un point de vue technique et sécuritaire, afin d'aider les lecteurs à comprendre son architecture technique et ses méthodes de mise en œuvre. Nous nous concentrerons sur la construction des contrats de pont inter-chaînes d'Hyperliquid et les dangers potentiels, ainsi que sur la construction à double chaîne d'HyperEVM et HyperL1.

Analyse du pont inter-chaînes Hyperliquid

Puisque Hyperliquid n'a ouvert que le contrat de pont, nous pouvons comprendre une partie de son mécanisme de fonctionnement en analysant ce contrat. Hyperliquid a déployé un contrat de pont sur un réseau Layer2, utilisé pour stocker les actifs USDC des utilisateurs.

Ensemble de validateurs

Hyperliquid a 4 groupes de validateurs :

• hotValidatorSet : gérer des opérations à haute fréquence telles que les retraits des utilisateurs
• coldValidatorSet: responsable de la modification de la configuration du système
• finalisateurs : confirmer le changement d'état du pont inter-chaînes
• casiers : gérer les urgences, possibilité de suspendre le contrat de pont

Actuellement, Hyperliquid n'a que 4 nœuds de validation, hotValidatorSet et coldValidatorSet correspondant chacun à 4 adresses sur la chaîne.

processus de dépôt

Le contrat pont Hyperliquid utilise la méthode Permit de l'EIP-2612 pour traiter les dépôts, prenant en charge uniquement l'USDC. Le processus de dépôt est relativement simple, utilisant principalement la fonction batchedDepositWithPermit pour le traitement en lots.

Processus de retrait

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

1. L'utilisateur initie une demande de retrait
2. Nécessite d'obtenir 2/3 de poids de signature du hotValidatorSet
3. Entrez dans la "période de contestation" de 200 secondes
4. Après la fin de la période de contestation, les membres des finalisateurs confirment l'état final.

Le processus de retrait est doté de trois lignes de défense :

1. Il est nécessaire de contrôler 2/3 du poids des signatures de hotValidatorSet
2. Évitez d'être découvert pendant la période de litige.
3. Obtenez la clé privée d'au moins un membre des finalizers.

Mécanisme de verrouillage de contrat de pont

Les membres de lockers peuvent voter pour verrouiller le contrat de pont via la fonction voteEmergencyLock. Actuellement, 2 membres de lockers doivent voter pour verrouiller. Une fois verrouillé, il ne peut être déverrouillé que par la fonction emergencyUnlock de coldValidatorSet.

Mise à jour du pool de validateurs

La fonction updateValidatorSet peut être utilisée pour mettre à jour l'ensemble des validateurs, avec la nécessité d'une signature de tous les membres du hotValidatorSet et d'une période de contestation de 200 secondes.

Risques potentiels

1. Le coldValidatorSet contrôlé peut contourner la ligne de défense pour voler des actifs.
2. Les finalisateurs peuvent refuser de confirmer les transactions de retrait.
3. les lockers peuvent potentiellement verrouiller malicieusement le contrat de pont

HyperEVM et architecture d'interaction à double chaîne

Pour réaliser la programmabilité des transactions sur le livre de commandes, Hyperliquid a lancé le programme HyperEVM. Il peut lire l'état du livre de commandes Hyperliquid et interagir avec celui-ci.

Hyperliquid adopte une "solution à double chaîne":

• Hyperliquid L1(L1): chaîne dédiée au carnet de commandes, système de permis
• HyperEVM(EVM): chaîne sans permission, contrats intelligents déployables

Les deux chaînes interagissent grâce aux Precompiles et aux Events:

Précompilations

HyperEVM a ajouté du code précompilé, permettant à l'EVM de lire l'état du système de carnet de commandes Hyperliquid.

Événements

HyperEVM peut écrire des données sur L1 via des événements. Les nœuds Hyperliquid écoutent les événements d'adresses spécifiques et transforment l'intention de l'utilisateur en transactions L1.

consensus HyperBFT

Hyperliquid utilise le protocole de consensus HyperBFT 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 du contrat du système L1 et non l'adresse de l'utilisateur.
2. Le problème de non-atomicité dans l'interaction entre EVM et L1
3. L'adresse du contrat EVM doit avoir un compte mappé sur L1
4. Le transfert d'actifs inter-chaînes peut entraîner une invisibilité temporaire du solde.

Dans l'ensemble, HyperEVM est similaire à la couche 2 de Hyperliquid L1, mais offre une interopérabilité supérieure. Les développeurs doivent prêter attention aux cas particuliers mentionnés ci-dessus pour garantir la sécurité du protocole et l'expérience utilisateur.