Analyse technique de Hyperliquid : contrats de pont, architecture et risques potentiels

Hyperliquid, en tant qu'échange de livres de commandes sur la chaîne très médiatisé, mérite une exploration approfondie de sa construction technique et de sa sécurité. Cet article analysera techniquement Hyperliquid sous deux aspects : la structure des contrats de pont inter-chaînes et l'architecture double avec HyperEVM.

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. En termes de classification des identités des nœuds, Hyperliquid a quatre groupes de validateurs :

• hotValidatorSet: gérer des opérations fréquentes telles que les retraits
• coldValidatorSet: responsable de la modification de la configuration du système
• coffres: similaire au comité de sécurité, peut voter pour suspendre le contrat de pont
• finalizers : 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, permettant uniquement le dépôt d'USDC. La fonction batchedDepositWithPermit peut gérer plusieurs dépôts en lot, avec un processus simple et une sécurité relativement élevée.

Processus de retrait

Les demandes de retrait doivent obtenir un poids de signature de 2/3 du hotValidatorSet. Une fois lancées, il y a une "période de contestation" de 200 secondes, pendant laquelle :

1. Les lockers peuvent voter pour suspendre le contrat.
2. coldValidatorSet peut rendre un retrait invalide

Après la période de contestation, les membres des finalizers appellent la fonction batchedFinalizeWithdrawals pour confirmer le retrait.

Mécanisme de verrouillage des contrats de pont

2 lockers doivent voter pour verrouiller le contrat de pont. Le déverrouillage nécessite la signature de 2/3 du coldValidatorSet, et il est également possible de mettre à jour la liste des validateurs.

Mise à jour de l'ensemble des validateurs

La fonction updateValidatorSet peut mettre à jour hotValidatorSet et coldValidatorSet, nécessitant la signature de l'ensemble des hotValidatorSet, avec une période de contestation de 200 secondes.

Risques potentiels

1. coldValidatorSet contrôlé peut contourner la protection pour voler des actifs
2. les finalisateurs peuvent refuser de confirmer les transactions de retrait
3. verrouillages malveillants de contrat de pont

HyperEVM et architecture double chaîne

Hyperliquid utilise une "solution à double chaîne", fonctionnant simultanément sur la chaîne dédiée au carnet de commandes (HyperL1) et la chaîne compatible EVM (HyperEVM).

Précompilations

HyperEVM ajoute du code précompilé, permettant aux contrats intelligents de lire l'état de HyperL1. L'adresse précompilée connue 0x800 peut lire la position des contrats perpétuels du dernier bloc L1.

Événements

HyperEVM écrit des données vers HyperL1 via des événements. Les nœuds écoutent les événements de l'adresse 0x3333...3333 et transforment l'intention de l'utilisateur en transactions L1.

Consensus HyperBFT

Développé sur la base de HotStuff, la vitesse de traitement théorique peut atteindre 2 millions de transactions par seconde.

Considérations de développement

1. msg.sender peut être l'adresse du contrat du système L1
2. L'interaction non atomique entre l'EVM et L1 peut entraîner des pertes d'actifs
3. L'adresse du contrat EVM doit créer un compte de correspondance sur L1
4. Les actifs inter-chaînes peuvent temporairement ne pas être consultables.

Dans l'ensemble, HyperEVM est similaire à la couche 2 de Hyperliquid L1, mais offre une interopérabilité accrue. Les développeurs doivent faire attention à gérer diverses situations particulières pour garantir la sécurité des actifs des utilisateurs.