KelpDAO : 116 500 rsETH non garantis exposés après une…
L'échec inter-chaînes d'environ 294 millions de dollars a intensifié l'examen des configurations à DVN unique et a affirmé un changement par rapport à la vérification unilatérale 1/1.
Une violation ciblant la pile de messagerie et de vérification inter-chaînes de KelpDAO a déclenché la libération d'environ 116 500 rsETH d'une valeur de près de 294 millions de dollars sans garantie. L'échec s'est produit au niveau de l'RPC et de l'entrée du vérificateur, et non par une exploitation directe d'un contrat intelligent, et s'est achevé en quelques minutes.
Points clés
- La pile de vérification inter-chaînes de KelpDAO a accepté un message faux après que des attaquants ont ciblé l'infrastructure et la messagerie, et non la logique du contrat.
- Des nœuds RPC valides ont été submergés tandis que des nœuds malveillants alimentaient des données manipulées dans le chemin de vérification DVN.
- Environ 116 500 rsETH d'une valeur de près de 294 millions de dollars ont été libérés sans garantie, et la séquence s'est terminée en quelques minutes.
- Les configurations DVN à vérificateur unique (1/1) sont désormais sous une surveillance accrue, y compris une affirmation citée selon laquelle les configurations unilatérales 1/1 pourraient être abandonnées.
L'échec de vérification inter-chaînes de KelpDAO a libéré ~116 500 rsETH en quelques minutes.
L'incident de KelpDAO est présenté comme un échec de vérification inter-chaînes qui a entraîné la libération d'environ 116 500 rsETH, d'une valeur de près de 294 millions de dollars, sans garantie. Le détail opérationnel clé est la vitesse. La séquence s'est achevée en quelques minutes, ce qui est important car cela réduit la fenêtre d'intervention humaine à presque zéro une fois que le pipeline de vérification commence à faire confiance à de mauvaises entrées.
L'étendue décrite n'est pas une histoire typique de "bug dans un contrat". Le point d'échec se situe en amont, dans l'infrastructure de messagerie et de vérification qui décide si une instruction inter-chaînes est valide avant que les actifs ne soient libérés du côté de la destination. Cette distinction n'est pas académique. Elle change ce que les traders devraient considérer comme la surface de risque, du bytecode audité à la plomberie des données qui indique au vérificateur quelle est la réalité.
L'incident est daté du 18 avril. L'attribution est discutée comme étant "probablement liée" à l'unité TraderTraitor du groupe Lazarus, mais cela reste une couche non confirmée au-dessus des faits mécaniques.
Comment l'attaque a contourné les vérifications des contrats intelligents en empoisonnant les entrées RPC
Les mécanismes décrits rappellent que les « contrats sécurisés » peuvent encore être en aval d'une vérité non sécurisée. Les attaquants n'avaient pas besoin de contourner les vérifications au niveau des contrats s'ils pouvaient corrompre les entrées sur lesquelles repose le système de vérification inter-chaînes.
Le chemin décrit passe par des nœuds RPC, les points de terminaison du serveur qui fournissent des données blockchain aux applications et à l'infrastructure. Dans ce cas, ces nœuds RPC ont alimenté des données de transaction dans un DVN, un système de vérification utilisé pour confirmer si les messages et les transferts inter-chaînes sont valides.
La séquence d'attaque décrite comporte deux volets. Tout d'abord, des nœuds RPC valides ont été submergés. Ensuite, des nœuds RPC malveillants ont été introduits. La combinaison a contraint le système à s'appuyer sur des entrées de données manipulées qui ont ensuite été intégrées dans le processus de vérification DVN.
Ce qui ressort ici, c'est le camouflage opérationnel. Les attaquants sont décrits comme maintenant des « réponses normales pour les outils de surveillance » tout en altérant les données envoyées pour vérification. C'est le genre de mode de défaillance qui peut laisser les tableaux de bord en vert tandis que le vérificateur reçoit des entrées empoisonnées. Une fois que des nœuds sains ont été perturbés et que le système est revenu à des données compromises, de fausses transactions pouvaient passer pour valides.
C'est la leçon fondamentale que les traders continuent d'apprendre à chaque incident de pont et de chaîne croisée. L'exploitation n'a pas besoin d'être "dans le contrat" pour se terminer par la libération d'actifs. Si la couche de vérification est convaincue qu'un message est réel, le contrat peut s'exécuter exactement comme prévu et produire néanmoins un actif non garanti.actiflibération.
Configurations Single-DVN (1/1) sous le feu après le lancement non soutenu
Le débat porte désormais moins sur l'ingéniosité de l'intrusion et plus sur la fragilité du choix de conception qui l'a rendue décisive. L'incident est explicitement lié à une seule configuration DVN. LayerZero est cité, décrivant l'exploitation comme réussie parce que KelpDAO a utilisé un seul DVN, ce qui signifiait qu'il n'y avait pas de couche de vérification de sauvegarde une fois que le système a commencé à faire confiance à un faux message.
Les configurations à vérificateur unique, 1/1, sont populaires pour une raison. Elles sont moins chères et plus rapides, et le paquet note que de nombreux protocoles ont adopté des configurations similaires pour ces gains d'efficacité. Le problème est que l'efficacité s'achète en concentrant la confiance. Lorsque le point de confiance unique échoue, il n'y a pas de deuxième opinion.
En termes de structure de marché, cela transforme la conception de la vérification en un risque d'événement de liquidité. Si un système peut créer ou libérer une grande quantité de représentation non garantie "en quelques minutes", le marché est contraint de tarifer le risque comme soudain plutôt que gérable. Il n'y a pas de temps à attendre pour une pause de gouvernance, une réponse multisig ou un gel d'échange coordonné. L'effet de second ordre est la confiance. Le paquet cadre explicitement la conception de validation faible comme quelque chose qui peut "affaiblir la confiance du marché", et c'est généralement là que le contagion commence, pas où elle se termine.
Un signal politique séparé circule. L'analyste Darkfost est cité en disant que LayerZero "ne soutiendra plus les configurations unilatérales 1/1 DVN", impliquant un éloignement des configurations à vérificateur unique vers la redondance même si cela augmente le coût et ralentit l'exécution. Cette affirmation est directionnellement cohérente avec la critique de conception, mais c'est toujours une affirmation qui nécessite une confirmation primaire.
Liste de vérification de confirmation : Changements de politique DVN, post-mortems et attribution des acteurs.
Trois choses doivent être confirmées avant que cet incident puisse être proprement traduit en une revalorisation plus large du risque inter-chaînes.
Tout d'abord, un post-mortem de KelpDAO ou des références de transaction on-chain qui précisent le montant de rsETH, le chemin exact du message inter-chaînes, et si les fonds étaient récupérables ou déplacés. Le paquet fournit le chiffre principal et le mécanisme, mais il n'inclut pas de preuve on-chain indépendante ou de rapport d'incident formel.
Deuxièmement, une déclaration directe de LayerZero ou une mise à jour de documentation confirmant ou niant l'affirmation selon laquelle les configurations unilatérales 1/1 DVN ne seront plus prises en charge. Pour l'instant, le paquet contient une explication citée de LayerZero sur l'importance du DVN unique, plus l'affirmation de Darkfost sur la direction politique. Les traders devraient traiter le changement de politique comme non vérifié jusqu'à ce qu'il apparaisse dans la documentation primaire.
Troisièmement, surveillez si d'autres protocoles divulguent publiquement des changements de configuration loin des DVN 1/1 vers une redondance multi-vérificateur, y compris les délais. Si l'industrie est réellement en train de changer, cela apparaîtra comme des mises à jour de configuration concrètes, pas seulement des commentaires.
Concernant l'attribution, le cadre "probablement lié" du paquet autour de l'unité TraderTraitor du groupe Lazarus n'est pas une confirmation. Les rapports ultérieurs qui corroborent ou réfutent celalienavec des indicateurs concrets, cela compte, mais cela ne devrait pas être l'ancre pour la gestion des risques. L'échec de conception observable au niveau d'entrée RPC et DVN est la partie qui se généralise.
Les traders devraient considérer la conception de vérification comme une variable de risque de liquidité.
Je vois cela comme une histoire de structure de marché déguisée en histoire de sécurité. Les faits mécaniques sont simples. Les attaquants ont ciblé l'infrastructure de messagerie et de vérification inter-chaînes, ont submergé les nœuds RPC valides, ont introduit des nœuds malveillants et ont poussé des entrées manipulées dans un chemin DVN. Après que le système ait accepté un message faux, environ 116 500 rsETH d'une valeur de près de 294 millions de dollars ont été libérés sans couverture, et cela s'est produit en quelques minutes.
Le schéma à noter est celui où la confiance était concentrée. Un seul DVN signifiait qu'il n'y avait pas de redondance lorsque la couche de données était compromise. Si cela est exact, alors le mode de défaillance n'est pas « quelqu'un a trouvé un bug. » C'est « le système avait un point de contrôle, et le point de contrôle faisait confiance à des données empoisonnées. » Cette distinction est importante car elle change la rapidité avec laquelle des conceptions similaires peuvent échouer ailleurs. Les audits de contrat ne couvrent pas l'ensemble de la pile lorsque la pile inclut la livraison de données hors chaîne et les hypothèses de vérification.
Je vois trois scénarios à partir de maintenant.
Le premier scénario est le plus clair. KelpDAO publie un post-mortem avec des références on-chain qui correspondent au chiffre de ~116 500 rsETH et clarifie le chemin du message et les mouvements de fonds. LayerZero confirme alors, dans la documentation ou une déclaration directe, que les configurations unilatérales DVN 1/1 sont en cours de dépréciation ou ne sont plus supportées. Cette combinaison validerait la thèse selon laquelle le marché passe de « un seul vérificateur est acceptable pour la vitesse » à « la redondance est le coût par défaut des affaires. » Point de confirmation : documentation principale qui change explicitement la politique de support DVN.
Le deuxième scénario est une confirmation partielle. Le post-mortem valide la mécanique et le montant, mais le changement de politique de LayerZero reste non confirmé ou est atténué en un langage plus doux comme « découragé » plutôt que « non supporté. » Dans ce monde, la critique de conception reste valable, mais le calendrier pour un changement à l'échelle de l'écosystème s'étire. Point de confirmation : d'autres protocoles migrent publiquement de 1/1 à des configurations multi-vérificateurs avec des délais déclarés.
Le troisième scénario est le désordonné. Des détails clés restent non vérifiés, les récits d'attribution dominent, et l'industrie le traite comme un échec d'opérateur isolé plutôt qu'un problème de conception structurelle. Cela permettrait aux configurations 1/1 de survivre plus longtemps, ce qui signifie que la même classe de risque reste dans le système. Point d'invalidation : preuves que le chiffre de libération de rsETH ou le chemin de contamination RPC décrit est matériellement incorrect.
Ma synthèse est simple. Si le post-mortem et la documentation LayerZero convergent tous deux sur « l'empoisonnement des entrées RPC plus l'acceptation d'un seul DVN ont causé une libération sans couverture, » alors la conception de vérification cesse d'être une note technique et devient une variable de risque de liquidité de premier ordre que les traders doivent évaluer.
