Le différend LayerZero s'aggrave après le drain du pont rsETH de $290 million

Kelp DAO remet en question la version de LayerZero concernant une exploitation du pont rsETH d’un montant de $290 millions, arguant que l’échec provient des défauts propres à la plateforme, et non d’une configuration inhabituelle. Le différend porte désormais sur qui contrôlait les clés, le code et les avertissements.

Ce qui s’est passé lors de l’exploitation

Samedi, des attaquants ont drainé 116 500 rsETH, d’une valeur d’environ $290 millions, du pont alimenté par LayerZero de Kelp après avoir empoisonné les serveurs utilisés pour vérifier les transferts. L’attaque n’a pas touché les contrats de restaking principaux de Kelp, et la pause d’urgence a été déclenchée 46 minutes plus tard.

Cette pause a bloqué deux tentatives de suivi qui auraient libéré environ $200 millions de rsETH supplémentaires. De plus, une source proche de Kelp a indiqué que la brèche est restée limitée à la couche du pont.

Comment Kelp explique le fonctionnement de la configuration

Kelp prévoit de soutenir que le DVN compromis était l’infrastructure propre à LayerZero, et non un vérificateur tiers choisi par le protocole. Le mémo examiné par CoinDesk indique que l’attaque a utilisé des serveurs LayerZero qui vérifiaient si les transactions inter-chaînes étaient légitimes.

Cependant, une source de Kelp a déclaré que les serveurs de secours ont été inondés de trafic indésirable, ce qui a poussé le vérificateur sur les nœuds compromis. Toute cette infrastructure a été construite et gérée par LayerZero, a précisé la source.

Le protocole conteste également l’affirmation selon laquelle il aurait ignoré les recommandations de s’éloigner d’une configuration à vérificateur unique. Par le biais d’un canal de communication direct ouvert depuis juillet 2024, Kelp affirme n’avoir reçu aucune recommandation spécifique pour modifier la configuration du DVN rsETH.

Pourquoi la configuration est sous scrutiny

Le rapport post-mortem de LayerZero indique que KelpDAO a choisi une configuration DVN 1-sur-1 malgré les recommandations d’utiliser une redondance multi-DVN. En pratique, une configuration 1/1 signifie qu’un seul validateur peut approuver un message inter-chaînes seul, tandis que les configurations multi-validateurs réduisent le risque de point de défaillance unique.

De plus, une source de Kelp a indiqué que le guide de démarrage rapide de LayerZero et la configuration par défaut sur GitHub pointent vers la même structure 1/1. La source a ajouté que 40 % des protocoles sur LayerZero utilisent actuellement cette configuration.

La même configuration apparaît dans le guide de démarrage rapide LayerZero V2 OApp, où le fichier layerzero.config.ts d’exemple attribue un DVN requis et aucun DVN optionnel. C’est exactement le modèle que Kelp affirme avoir suivi.

Les critiques estiment que la responsabilité est mal placée

Des chercheurs en sécurité réagissent également. Artem K, développeur de l’équipe principale de Yearn Finance, connu sur X sous le nom de @banteg, a déclaré que le code de déploiement public de LayerZero utilise par défaut une vérification à source unique sur Ethereum, BSC, Polygon, Arbitrum et Optimism.

Il a aussi noté que le déploiement laisse une endpoint publique exposée, ce qui divulgue la liste des serveurs configurés à quiconque la consulte. Cela dit, il a précisé qu’il ne pouvait pas prouver quelle configuration Kelp a utilisée.

Zach Rynes, responsable communautaire de Chainlink, a été plus incisif sur X, accusant LayerZero de détourner la responsabilité et de jeter Kelp en pâture pour avoir fait confiance à une configuration que LayerZero lui-même soutenait. Il a affirmé que l’entreprise tentait de rejeter la faute sur son infrastructure compromise.

CoinDesk a contacté LayerZero pour un commentaire, mais n’a pas reçu de réponse au moment de la publication. Par ailleurs, LayerZero a promis de cesser de signer des messages pour toute application utilisant une configuration à vérificateur unique, ce qui obligera à une migration plus large sur son réseau.

En fin de compte, le conflit autour de cet incident LayerZero ne concerne plus seulement un pont. Il est devenu un test de la documentation, des paramètres par défaut et de la responsabilité en matière de sécurité inter-chaînes.