HyperEVM connaît une panne majeure, la page d’état officielle indique un fonctionnement normal, ce qui suscite des doutes

HyperEVM宕機

Le 2 avril, l’organisme de surveillance on-chain PeckShield a publié une alerte, confirmant que HyperEVM aurait subi une grave panne. D’après la capture d’écran publiée, la page du navigateur de blocs indique que le dernier bloc et les transactions sont restés figés à environ une heure auparavant ; en outre, les interactions réseau sont devenues anormalement perturbées dans leur ensemble. Cependant, la page officielle d’état de Hyperliquid continue d’afficher « All Systems Operational », ce qui crée un décalage évident avec la réalité on-chain.

Phénomènes de panne : données de surveillance de PeckShield et retours des utilisateurs

HyperEVM數據監測 (Source : PeckShield)

La capture d’écran publiée par PeckShield montre que, sur la page du navigateur de blocs d’HyperEVM, le dernier bloc et les transactions sont bloqués depuis environ une heure, ce qui signifie qu’à partir de ce moment-là, le réseau a cessé de produire des blocs. Conformément aux mécanismes fondamentaux de fonctionnement d’une blockchain, l’arrêt de la production de blocs implique que toutes les transactions en attente ne peuvent pas obtenir de confirmation, et que les interactions des contrats intelligents on-chain se retrouvent également gelées.

Les discussions pertinentes sur la plateforme X ont rapidement augmenté, et les principaux phénomènes anormaux rapportés par les utilisateurs incluent :

Transactions impossibles à confirmer : les transactions soumises restent bloquées pendant longtemps dans un état « en attente », sans parvenir à finaliser la compensation on-chain

Interruption des interactions de contrats intelligents : les protocoles DeFi et les applications reposant sur les contrats HyperEVM ne peuvent pas être appelés normalement

Arrêt des mises à jour du navigateur de blocs : les outils de données on-chain cessent de charger les derniers blocs, affichant un écart sérieux entre les données et l’état réel de la blockchain

À la date de publication, Hyperliquid officiel n’a pas encore publié d’annonce officielle ni expliqué de calendrier de reprise concernant cet incident de panne d’HyperEVM.

Angles morts de la page d’état officielle : stratification technique entre L1 et HyperEVM

La page officielle d’état de Hyperliquid affiche « All Systems Operational », mais ce statut ne couvre généralement que la couche de base du L1 et les interfaces API, sans nécessairement refléter immédiatement les problèmes réels de la couche d’exécution HyperEVM.

Sur le plan de l’architecture technique, HyperEVM est une couche additionnelle distincte placée au-dessus du moteur de matching/association et de règlement du cœur de Hyperliquid L1. Cela signifie que même si les fonctions de matching et de liquidation de base du L1 continuent de fonctionner normalement, l’environnement d’exécution des contrats intelligents d’HyperEVM peut tout de même connaître une panne système indépendante. La non-mise à jour immédiate de la page d’état officielle pourrait refléter un manque technique dans le cadre de supervision de Hyperliquid concernant la couche HyperEVM, plutôt qu’une volonté de dissimuler des informations sur la panne.

Tests de résistance de la disponibilité de la nouvelle mainnet

La mainnet d’HyperEVM a été mise en ligne officiellement au début de mars 2026. Son objectif de conception est de fournir aux infrastructures de contrats perpétuels durables à haute performance de Hyperliquid des capacités de contrats intelligents compatibles EVM, afin d’attirer les développeurs de l’écosystème Ethereum pour déployer des protocoles DeFi et des applications.

Cette panne est survenue moins d’un mois après la mise en ligne de la mainnet. Pour les utilisateurs et les développeurs ayant déployé des actifs ou des protocoles sur HyperEVM, il s’agit d’un test de résistance direct de la stabilité précoce des infrastructures d’une nouvelle chaîne. Lorsqu’un nouveau réseau émerge et qu’un incident majeur de panne survient au tout début, cela implique généralement des problèmes de configuration des nœuds, de conditions aux marges du mécanisme de consensus, ou de compatibilité de l’environnement d’exécution des contrats intelligents. Les causes précises restent à être expliquées par une annonce technique officielle.

Questions fréquentes

Qu’est-ce qu’HyperEVM, et pourquoi fait-on un suivi séparé de l’état de Hyperliquid L1 ?

HyperEVM est un environnement d’exécution de contrats intelligents compatible EVM, déployé au-dessus de Hyperliquid L1, et mis en ligne officiellement au début de mars 2026. Il permet aux développeurs d’utiliser des outils de l’écosystème Ethereum pour déployer des contrats intelligents sur la plateforme Hyperliquid. Comme HyperEVM est une couche additionnelle indépendante du moteur de matching du cœur de L1, les états techniques des deux peuvent être dissociés ; la page d’état officielle ne couvre pas forcément la situation en temps réel d’HyperEVM.

Quel impact concret cette panne a-t-elle sur les protocoles DeFi sur HyperEVM ?

Pendant la période où la production de blocs est interrompue, tous les contrats intelligents exécutés sur HyperEVM ne peuvent pas exécuter de nouvelles confirmations de transactions. La fonctionnalité normale des pools de liquidité, des protocoles d’emprunt et des applications reposant sur des appels de contrats est également affectée. Les transactions soumises par les utilisateurs durant la panne restent bloquées dans un état en attente, en attendant que le réseau reprenne la production de blocs pour pouvoir finaliser les confirmations.

Pourquoi la page d’état officielle de Hyperliquid affiche-t-elle toujours un fonctionnement normal pendant la panne ?

La page d’état officielle de Hyperliquid surveille principalement la couche de base du cœur de L1 et les services API. En tant qu’environnement d’exécution EVM de couche supérieure, HyperEVM n’a peut-être pas été inclus dans la portée de surveillance en temps réel. Cet angle mort de couverture provoque un écart entre l’affichage de l’état officiel et la réalité on-chain, mettant en évidence l’orientation vers l’amélioration du mécanisme de surveillance de l’état pour la nouvelle mainnet.

Avertissement : Les informations contenues dans cette page peuvent provenir de tiers et ne représentent pas les points de vue ou les opinions de Gate. Le contenu de cette page est fourni à titre de référence uniquement et ne constitue pas un conseil financier, d'investissement ou juridique. Gate ne garantit pas l'exactitude ou l'exhaustivité des informations et n'est pas responsable des pertes résultant de l'utilisation de ces informations. Les investissements en actifs virtuels comportent des risques élevés et sont soumis à une forte volatilité des prix. Vous pouvez perdre la totalité du capital investi. Veuillez comprendre pleinement les risques pertinents et prendre des décisions prudentes en fonction de votre propre situation financière et de votre tolérance au risque. Pour plus de détails, veuillez consulter l'avertissement.

Articles similaires

Pirateage du Kelp DAO attribué au groupe Lazarus ; prise de contrôle du domaine eth.limo via une ingénierie sociale

LayerZero a indiqué que l’exploitation du Kelp DAO, attribuée au groupe Lazarus de la Corée du Nord, a entraîné une perte de $292 millions de tokens rsETH en raison de vulnérabilités dans son réseau de vérificateurs décentralisés. De plus, eth.limo a fait l’objet d’une prise de contrôle de domaine via une attaque d’ingénierie sociale, mais la fonctionnalité DNSSEC a limité les dégâts importants.

GateNewsIl y a 1m

Un piratage DeFi déclenche $9 milliards de sorties de fonds depuis Aave, alors que des jetons volés servent de garanties

Un piratage récent qui a vidé près de $300 millions d’un projet crypto a entraîné une crise de liquidité sur Aave, poussant les utilisateurs à retirer environ $9 milliards. Des inquiétudes concernant la qualité des garanties ont suscité des retraits massifs, mettant en évidence les risques des prêts DeFi.

GateNewsIl y a 32m

Une attaque de phishing sur Ethereum vidant $585K Quatre utilisateurs, une seule victime perd $221K WBTC

Une attaque coordonnée de phishing sur Ethereum a soutiré 585 000 $ à quatre victimes, en exploitant les autorisations des utilisateurs via un lien trompeur. Cet incident met en évidence la perte rapide de fonds par ingénierie sociale, même sous l’apparence de la légitimité.

GateNewsIl y a 2h

Faites attention au contenu de la signature ! Vercel a fait l’objet d’un chantage par piratage de 2 millions de dollars, l’alerte est levée sur la sécurité du front-end du protocole crypto

La plateforme de développement cloud Vercel a été piratée le 19 avril. Les attaquants ont obtenu des droits d’accès via un outil d’IA tiers utilisé par les employés, et ont menacé de rançonner 2 millions de dollars. Bien que des données sensibles n’aient pas été consultées, d’autres données auraient pu être exploitées. L’incident a suscité des inquiétudes au sein de la communauté crypto au sujet de la sécurité ; Vercel mène actuellement une enquête et recommande aux utilisateurs de remplacer leurs clés.

ChainNewsAbmediaIl y a 3h

KelpDAO perd $290M dans l’attaque LayerZero du groupe Lazarus

KelpDAO a subi une perte de $290 million due à une faille de sécurité sophistiquée liée au groupe Lazarus. L’attaque a exploité des faiblesses de configuration dans leur système de vérification et a mis en évidence les risques liés au recours à une configuration de vérification à point unique. Des experts du secteur soulignent la nécessité d’améliorer les configurations de sécurité et de mettre en place une vérification multi-couches afin de prévenir de futurs incidents.

CryptoFrontierIl y a 4h

LayerZero répond à l’événement de 292 M$ du Kelp DAO : indique que Kelp a configuré un DVN 1 sur 1 pour son propre choix, et que le pirate est le Lazarus nord-coréen.

LayerZero a publié une déclaration concernant l’incident de piratage de 292 millions de dollars subi par Kelp DAO, affirmant que la configuration Kelp de 1-of-1 DVN autoselectionné a rendu l’événement possible, et que l’attaquant est le groupe nord-coréen Lazarus. LayerZero souligne que cet incident provient du choix de configuration, et qu’il ne prendra plus en charge ce type de configuration vulnérable. De plus, la question de l’attribution des responsabilités demeure controversée, sans proposer de plan d’indemnisation.

ChainNewsAbmediaIl y a 4h
Commentaire
0/400
Aucun commentaire