Analyse approfondie de l'architecture et des risques potentiels de Hyperliquid sous un angle technique
Hyperliquid, en tant qu'échange de livres de commandes en chaîne qui a récemment attiré beaucoup d'attention, a un TVL de plus de 2 milliards de dollars et est surnommé "Binance en chaîne". Cet article examinera en profondeur la structure des contrats de ponts inter-chaînes de Hyperliquid, l'architecture HyperEVM et ses potentielles vulnérabilités de sécurité, afin d'aider les lecteurs à comprendre pleinement la construction technique de ce projet vedette.
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: responsable des opérations à haute fréquence telles que les retraits d'utilisateurs
coldValidatorSet: responsable de la modification de la configuration du système et du traitement d'urgence
coffres: similaire à un comité de sécurité, peut suspendre le fonctionnement 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, ne permettant que le dépôt de l'USDC. La fonction batchedDepositWithPermit permet de traiter les dépôts en masse, simplifiant ainsi les opérations pour l'utilisateur.
Processus de retrait
Les demandes de retrait doivent obtenir 2/3 du poids de signature du hotValidatorSet. Ensuite, il y a une "période de contestation" de 200 secondes, pendant laquelle les lockers peuvent suspendre le contrat ou le coldValidatorSet peut rendre le retrait invalide. Après la période de contestation, les finalizers confirment l'état final.
Mécanisme de verrouillage du contrat de pont
Les lockers peuvent voter pour verrouiller le contrat de pont. 2 lockers doivent voter pour suspendre l'exécution. Le déverrouillage nécessite la signature de 2/3 du coldValidatorSet, et permet également de mettre à jour l'ensemble 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
coldValidatorSet contrôlé peut contourner la ligne de défense pour voler des actifs
Les finalisateurs peuvent refuser de confirmer les transactions de retrait.
Les lockers peuvent verrouiller malicieusement les contrats de pont.
HyperEVM et architecture d'interaction à double chaîne
Hyperliquid adopte une "solution à double chaîne" :
Hyperliquid L1 : chaîne dédiée au carnet de commandes, à accès contrôlé
HyperEVM : chaîne compatible EVM, sans autorisation
Les deux chaînes propagent des données à travers le même protocole de consensus, mais s'exécutent séparément. La vitesse de création de blocs de la L1 est plus rapide, la chaîne EVM peut lire les données de la L1 et écrire dans la L1.
Précompilations
HyperEVM ajoute du code précompilé pour permettre la lecture de l'état du carnet de commandes L1. Par exemple, l'adresse 0x800 peut lire la position du contrat perpétuel du dernier bloc L1.
Événements
HyperEVM écrit des données dans L1 via des événements. Les nœuds L1 écoutent les événements d'adresses spécifiques et les transforment en transactions L1.
Consensus HyperBFT
Développé sur la base de HotStuff, il est théoriquement capable de traiter 2 millions de commandes par seconde. Utilisant un mode de diffusion par agrégation de leader, il réduit la complexité.
Remarques pour les développeurs
msg.sender peut être l'adresse du contrat du système L1
L'interaction non atomique peut entraîner des pertes d'actifs
L'adresse du contrat EVM doit créer un compte de correspondance sur L1
Les actifs inter-chaînes peuvent temporairement ne pas être consultables.
Dans l'ensemble, HyperEVM est similaire à une architecture de couche deux basée sur L1, mais offre une interopérabilité plus élevée. Les développeurs doivent faire attention à gérer diverses situations particulières pour garantir la sécurité des actifs des utilisateurs.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
15 J'aime
Récompense
15
7
Reposter
Partager
Commentaire
0/400
GateUser-e87b21ee
· 08-02 20:50
TVL 2 milliards de dollars, les gens sont naïfs et ont beaucoup d'argent.
Voir l'originalRépondre0
MetaReckt
· 08-02 07:57
La sécurité est moyenne, je continue à observer.
Voir l'originalRépondre0
LidoStakeAddict
· 07-31 01:47
Bien que le TVL soit puissant, il n'arrive pas à tenir.
Voir l'originalRépondre0
MEVHunterX
· 07-31 01:45
Ceux qui se précipitent pour se faire prendre pour des cons jouent encore avec des bridges cross-chain.
Voir l'originalRépondre0
MetamaskMechanic
· 07-31 01:41
Une autre vulnérabilité de sécurité sur une chaîne de deuxième couche
Voir l'originalRépondre0
BitcoinDaddy
· 07-31 01:37
Avec cette sécurité, qui oserait investir de l'argent ?
Voir l'originalRépondre0
NervousFingers
· 07-31 01:22
La Maison Blanche m'a déjà appelé pour des dettes, je suis un vétéran du trading avec des mains tremblantes.
Analyse technique de Hyperliquid : avantages architecturaux et risques potentiels
Analyse approfondie de l'architecture et des risques potentiels de Hyperliquid sous un angle technique
Hyperliquid, en tant qu'échange de livres de commandes en chaîne qui a récemment attiré beaucoup d'attention, a un TVL de plus de 2 milliards de dollars et est surnommé "Binance en chaîne". Cet article examinera en profondeur la structure des contrats de ponts inter-chaînes de Hyperliquid, l'architecture HyperEVM et ses potentielles vulnérabilités de sécurité, afin d'aider les lecteurs à comprendre pleinement la construction technique de ce projet vedette.
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:
Processus de dépôt
Le contrat de pont 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. La fonction batchedDepositWithPermit permet de traiter les dépôts en masse, simplifiant ainsi les opérations pour l'utilisateur.
Processus de retrait
Les demandes de retrait doivent obtenir 2/3 du poids de signature du hotValidatorSet. Ensuite, il y a une "période de contestation" de 200 secondes, pendant laquelle les lockers peuvent suspendre le contrat ou le coldValidatorSet peut rendre le retrait invalide. Après la période de contestation, les finalizers confirment l'état final.
Mécanisme de verrouillage du contrat de pont
Les lockers peuvent voter pour verrouiller le contrat de pont. 2 lockers doivent voter pour suspendre l'exécution. Le déverrouillage nécessite la signature de 2/3 du coldValidatorSet, et permet également de mettre à jour l'ensemble 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
HyperEVM et architecture d'interaction à double chaîne
Hyperliquid adopte une "solution à double chaîne" :
Les deux chaînes propagent des données à travers le même protocole de consensus, mais s'exécutent séparément. La vitesse de création de blocs de la L1 est plus rapide, la chaîne EVM peut lire les données de la L1 et écrire dans la L1.
Précompilations
HyperEVM ajoute du code précompilé pour permettre la lecture de l'état du carnet de commandes L1. Par exemple, l'adresse 0x800 peut lire la position du contrat perpétuel du dernier bloc L1.
Événements
HyperEVM écrit des données dans L1 via des événements. Les nœuds L1 écoutent les événements d'adresses spécifiques et les transforment en transactions L1.
Consensus HyperBFT
Développé sur la base de HotStuff, il est théoriquement capable de traiter 2 millions de commandes par seconde. Utilisant un mode de diffusion par agrégation de leader, il réduit la complexité.
Remarques pour les développeurs
Dans l'ensemble, HyperEVM est similaire à une architecture de couche deux basée sur L1, mais offre une interopérabilité plus élevée. Les développeurs doivent faire attention à gérer diverses situations particulières pour garantir la sécurité des actifs des utilisateurs.