Kelp DAO migre rsETH vers Chainlink CCIP après un hack de…
Le PDG de LayerZero conteste le récit de défaut DVN de Kelp et annonce qu'un rapport d'analyse post-mortem d'une société de sécurité externe est en préparation.
Kelp DAO a déclaré qu'il déplacera la messagerie cross-chain de rsETH vers Chainlink CCIP après un exploit du 18 avril décrit comme un incident de 292 millions de dollars. L'attaquant a volé 116 500 rsETH d'un pont alimenté par LayerZero et a utilisé les jetons comme garantie sur Aave v3 pour emprunter de l'Ether emballé.
Points clés
- KelpDAOa déclarérsETHmigrera versChainlinkCCIP suite à un exploit d'avril décrit comme un incident de 292 millions de dollars.
- L'attaque du 18 avril a volé 116 500 rsETH d'un pont alimenté par LayerZero et a acheminé les jetons vers Aave v3 commecollatéral pour emprunter WETH.
- Le rapport post-incident de LayerZero a lié la perte à un unique chemin de vérification et a déclaré qu'il déconseillait cette configuration.DVN chemin de vérification et a déclaré qu'il déconseillait cette configuration.
- Le PDG Bryan Pellegrino a rejeté le cadre de Kelp, affirmant que Kelp était passé manuellement des paramètres multi-DVN à une configuration 1/1 et qu'un post-mortem externe sera publié bientôt.
Kelp déplace le pont rsETH vers Chainlink CCIP après un exploit de 292 millions de dollars
Kelp DAO a déclaré qu'il migrera sonrestaking jeton rsETH vers Chainlink CCIP après un exploit du 18 avril qu'il a décrit comme un incident de 292 millions de dollars. Le protocole a présenté ce mouvement comme une réponse directe à la sécurité liée à l'échec du pont.
« Après l'exploit récent de LayerZero, nous prenons des mesures pour garantir que rsETH est entièrement sécurisé, c'est pourquoi nous migrons vers Chainlink CCIP », a déclaré Kelp DAO dans un communiqué publié sur X.
Pour les traders, le titre n'est pas seulement un échange de fournisseur. Il maintient l'exploit au centre des préoccupations sur la manière dont le marché évalue le risque de messagerie inter-chaînes autour des wrappers rsETH.ETH wrappers, et il soulève des questions opérationnelles à court terme sur la manière dont rsETH se déplace entre les chaînes pendant la transition.
Comment le rsETH volé a été routé vers l'emprunt Aave v3
L'attaquant a volé 116 500 rsETH du pont alimenté par LayerZero de Kelp DAO le 18 avril, puis a utilisé le rsETH volé comme garantie sur Aave v3 pour emprunter de l'Ether enveloppé.
Ce flux est important car il transforme une compromission de pont en pression immédiate sur le bilan au sein des lieux de prêt, où le WETH emprunté peut être déplacé rapidement et où les liquidations et les changements de paramètres de risque peuvent se répercuter sur les garanties corrélées.
L'incident a été décrit comme l'un des plus grands événements de sécurité de l'année et a été lié à une contagion plus large de l'écosystème qui a impacté le marché du prêt crypto interconnecté. Même sans comptabilité on-chain complète dans les documents fournis, le routage vers Aave v3 est le détail clé de la structure du marché. C'est le chemin du pont vers le marché monétaire qui a tendance à amplifier les effets de second ordre.
Conflit de configuration DVN : défauts de vérificateur unique contre rétrogradation manuelle
L'attribution de la cause profonde reste contestée, et cette incertitude fait désormais partie du commerce.
Le post-mortem de LayerZero, publié un jour après l'exploitation, a soutenu que le piratage s'est produit parce que le réseau de vérificateurs décentralisés (DVN) de Kelp reposait sur un seul DVN LayerZero comme le seul chemin vérifié, plutôt que d'exiger plusieurs vérifications indépendantes. LayerZero a déclaré qu'il avait déconseillé cette configuration.
Kelp DAO conteste ce cadre. Il a déclaré que la configuration 1/1 DVN est la configuration par défaut et est utilisée par de nombreux autres protocoles, citant des données de Dune qui montrent qu'environ la moitié des utilisateurs de LayerZero ont un seul DVN. Kelp a également accusé LayerZero d'avoir approuvé la configuration et de ne pas avoir averti du risque de sécurité associé.
« Kelp a fonctionné sur l'infrastructure LayerZero depuis janvier 2024 et a maintenu un canal de communication ouvert avec l'équipe LayerZero tout au long. La question de la configuration DVN a été soulevée plusieurs fois et ces configurations ont été confirmées comme sécurisées à ce moment-là », a déclaré Kelp.
Le PDG de LayerZero, Bryan Pellegrino, a réagi publiquement, affirmant qu'un « tas » des revendications de Kelp étaient « tout simplement complètement fausses ». Il a soutenu que Kelp avait initialement utilisé des paramètres multi-DVN et avait ensuite changé manuellement pour une configuration 1/1 qui n'est pas recommandée pour les applications de production.
« Les paramètres auxquels Kelp fait référence dans leur capture d'écran étaient multiDVN ou DeadDVN, qui rejettent de force une application utilisant les paramètres par défaut et nécessitent qu'ils définissent manuellement la configuration. rsETH était initialement configuré pour utiliser la configuration par défaut de LayerZero d'une configuration multiDVN de LayerZero Labs + Google », a déclaré Pellegrino.
LayerZero renforce les règles de validation alors qu'un post-mortem externe se profile.
LayerZero a déclaré qu'il ne validera ni n'approuvera les messages inter-chaînes pour toute application qui repose sur un seul vérificateur, et qu'il migre les protocoles utilisant cette configuration vers une configuration multi-DVN. C'est un changement de politique concret qui peut forcer des changements dans d'autres applications intégrées à LayerZero, pas seulement Kelp.
Le prochain catalyseur est le post-mortem promis par une société de sécurité externe mentionné par Pellegrino, y compris s'il corrobore le compte de configuration DVN de LayerZero ou soutient la revendication de Kelp selon laquelle la configuration était effectivement considérée comme acceptable.
Par ailleurs, Kelp n'a pas fourni de détails sur la migration pour le passage CCIP dans les documents fournis, y compris le calendrier, si le pont est suspendu pendant la transition, et si les utilisateurs doivent agir.
Ce que la migration CCIP signale pour la tarification des risques inter-chaînes.
Je considère la migration CCIP comme un repositionnement axé sur la sécurité, pas comme une résolution propre. Le marché n'a toujours pas de cause profonde établie, et cela compte car cela détermine s'il s'agissait d'un échec de configuration au niveau de l'application ou d'un coup de confiance plus large au niveau de la couche de messagerie.
Le seuil qui compte est de savoir si le post-mortem externe comble le fossé d'attribution et si l'interdiction de validation à vérificateur unique de LayerZero force des migrations multi-DVN visibles et rapides à travers d'autres protocoles.
Si ces deux éléments se déroulent proprement, la configuration commence à sembler structurelle plutôt que dictée par le récit, et les primes de risque inter-chaînes seront revalorisées autour de normes de validation applicables plutôt que de revendications marketing.
