HyperLiquid après le retrait de la spéculation : analyse technique de ses bridges cross-chain et de l'architecture HyperEVM

HyperLiquid, en tant qu'échange d'ordres on-chain très en vue, a vu sa TVL dépasser 2 milliards de dollars et est surnommé "Binance on-chain". Cet article explorera en profondeur HyperLiquid sous l'angle de sa construction technique et de sa sécurité, en se concentrant sur la structure et les risques de ses contrats de bridges cross-chain, ainsi que sur l'architecture à double chaîne de HyperEVM et HyperL1.

HyperLiquid bridges cross-chain解析

HyperLiquid a déployé un contrat de pont cross-chain sur Arbitrum pour stocker les actifs USDC des utilisateurs. Ce contrat de pont comprend quatre groupes de validateurs :

• hotValidatorSet: responsable des opérations à haute fréquence telles que les retraits des utilisateurs
• coldValidatorSet : responsable de la modification de la configuration du système, de la gestion de l'état de verrouillage des contrats de pont, etc.
• lockers : similaire au comité de sécurité, peut suspendre le fonctionnement du contrat de pont en cas d'urgence
• finalizers : confirmer les changements d'état des bridges cross-chain, tels que les dépôts et les retraits des utilisateurs

processus de dépôt

Le contrat HyperLiquid Bridge utilise la méthode Permit de l'EIP-2612 pour traiter les dépôts, ne permettant que le dépôt de l'USDC. L'opération de dépôt est relativement simple, utilisant la fonction batchedDepositWithPermit pour traiter plusieurs dépôts en lot.

processus de retrait

Le processus de retrait est relativement complexe:

1. L'utilisateur initie une demande de retrait, doit rassembler le poids de signature de 2/3 du hotValidatorSet.
2. Entrer dans la "période de contestation" de 200 secondes
3. Deux situations peuvent se produire pendant la période de contestation :
   • lockers pensent qu'il y a un problème, peuvent voter pour geler le contrat
   • coldValidatorSet peut rendre certaines demandes de retrait invalides
4. Après la fin de la période de contestation, les membres des finalizers appellent la fonction pour finaliser l'état final et transfèrent des USDC à l'utilisateur.

mécanisme de verrouillage de contrat de pont

• Il suffit de 2 votes de lockers pour verrouiller le contrat du pont.
• Il est possible de retirer un vote via la fonction unvoteEmergencyLock.
• Le déverrouillage nécessite un poids de signature de 2/3 du coldValidatorSet, tout en permettant la mise à jour de l'ensemble des validateurs.

mise à jour de l'ensemble des validateurs

Mise à jour par la fonction updateValidatorSet, nécessite la signature de l'ensemble des hotValidatorSet, avec une période de contestation de 200 secondes.

Les risques potentiels des bridges cross-chain

1. Les hackers contrôlant coldValidatorSet peuvent contourner les défenses pour voler des actifs.
2. Les finalisateurs peuvent refuser de confirmer les retraits, entraînant une attaque d'examen.
3. Les lockers peuvent verrouiller malicieusement les contrats de pont, entravant les retraits.

HyperEVM et architecture double chaîne

HyperLiquid utilise une architecture double chaîne:

• HyperLiquid L1(L1): chaîne dédiée au carnet de commandes, à accès contrôlé
• HyperEVM(EVM): chaîne sans permission, contrats intelligents déployables

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

• Précompilations : EVM lit l'état L1
• Événements : EVM écrit des données dans L1

consensus HyperBFT

Basé sur l'amélioration de HotStuff, la vitesse de traitement théorique peut atteindre 2 millions d'ordres par seconde.

Remarques pour les développeurs

1. msg.sender peut être l'adresse du contrat système plutôt que l'adresse de l'utilisateur
2. L'interaction entre EVM et L1 non atomique peut entraîner des risques d'actifs
3. L'adresse du contrat EVM doit créer un compte de mapping sur L1
4. Les actifs cross-chain peuvent temporairement ne pas être consultables.

Dans l'ensemble, HyperEVM est similaire à l'architecture de couche 2 basée sur HyperLiquid L1, mais offre une interopérabilité supérieure. Les développeurs doivent faire attention à bien gérer les différentes situations limites lors des interactions cross-chain.