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

Hyperliquid, en tant que l'un des représentants des échanges sur livre de commandes en chaîne, a un TVL dépassant 2 milliards de dollars et est surnommé "Binance en chaîne". Cet article analysera en profondeur les principes architecturaux de Hyperliquid sous les angles de la construction technique et de la sécurité.

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. Ce contrat de pont comprend quatre groupes de validateurs :

• hotValidatorSet: traiter les opérations fréquentes comme les retraits
• coldValidatorSet: modifier la configuration du système, peut invalider les demandes de retrait
• casiers : possibilité de suspendre l'exécution du contrat de pont
• finalizers : confirmer le changement 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, prenant en charge les opérations en masse. La logique de dépôt est simple et les risques de sécurité sont relativement faibles.

Processus de retrait

Les demandes de retrait doivent répondre aux conditions suivantes :

1. Obtenez 2/3 du poids des signatures du hotValidatorSet.
2. Après une période de contestation de 200 secondes
3. Confirmé finalement par les membres des finalizers

Pendant la période de contestation, les coffres peuvent suspendre le contrat de pont, et le coldValidatorSet peut rendre les retraits invalides.

Mécanisme de verrouillage du contrat de pont

Il faut que 2 lockers votent pour verrouiller le contrat de pont. Le déverrouillage nécessite un poids de signature de 2/3 de coldValidatorSet, tout en permettant de mettre à jour l'ensemble des validateurs.

Mise à jour du groupe de validateurs

La mise à jour de hotValidatorSet et coldValidatorSet nécessite la signature de tous les membres de hotValidatorSet, qui sera confirmée par les finalizers après une période de contestation de 200 secondes.

Risques potentiels

1. Une fois que le coldValidatorSet est contrôlé, il est possible de contourner les mécanismes de sécurité pour voler des actifs.
2. les finalisateurs peuvent refuser de confirmer les transactions de retrait
3. les lockers peuvent verrouiller malicieusement le contrat de pont

HyperEVM et architecture d'interaction à double chaîne

Hyperliquid adopte une architecture à double chaîne :

• Hyperliquid L1 : système de carnet d'ordres dédié, basé sur un système de licences
• HyperEVM: Chaîne compatible EVM, sans autorisation

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

• Precompiles : Permettre à HyperEVM de lire l'état L1
• Événements : Permettre à HyperEVM d'écrire des données sur L1

Consensus HyperBFT

Hyperliquid a développé l'algorithme de consensus HyperBFT basé sur HotStuff, avec une capacité de traitement théorique atteignant 2 millions de transactions par seconde.

Remarques pour les développeurs

1. msg.sender peut être l'adresse d'un contrat système
2. L'interaction entre EVM et L1 n'est pas atomique, il faut gérer les cas d'échec.
3. L'adresse du contrat EVM doit créer un compte de correspondance sur L1.
4. Les actifs inter-chaînes peuvent être temporairement invisibles et doivent être traités avec soin.

Dans l'ensemble, HyperEVM ressemble à une architecture de couche 2 de type L1, mais offre une interopérabilité accrue. Les développeurs doivent prêter attention aux détails techniques apportés par sa structure à double chaîne unique.