Qui devrait payer pour la "configuration par défaut" ? Deux semaines après le piratage de rsETH, le PDG de LayerZero "assume volontairement la responsabilité"

null

Écrit par : Yangz, Techub News

Dans le monde Web3 qui ne dort jamais, le 18 avril n’était à l’origine qu’un jour ordinaire. Cependant, pour le secteur de la re-staking de liquidités et l’écosystème DeFi dans son ensemble, une « secousse » qui restera gravée dans l’histoire s’est silencieusement déroulée sur la chaîne. En moins d’une heure, un hacker (présumé être le Lazarus Group) a utilisé le pont cross-chain de Kelp DAO pour forger de nulle part 116 500 rsETH, d’une valeur d’environ 292 millions de dollars. Considérant que le rsETH est largement utilisé comme garantie, le hacker n’a pas précipité la vente à découvert, mais a plutôt transféré ces « certificats d’air » sans valeur dans des protocoles de prêt comme Aave, pour en retirer environ 236 millions de dollars en ETH, poussant directement Aave et d’autres protocoles de premier plan dans une crise de créances douteuses.

Ce n’est pas la première fois qu’un pont cross-chain subit une attaque, mais cette fois-ci, cela a ouvert une vieille plaie dans l’industrie Web3 : lorsque l’infrastructure sous-jacente (couche protocolaire) et la couche applicative (couche supérieure) se rencontrent et créent un vide, qui doit payer pour la disparition de milliards d’actifs ?

Au cours des plus d’un mois qui ont suivi, cette crise s’est transformée en une bataille ouverte sur la technologie, la responsabilité et le pouvoir. Depuis le début, avec des accusations mutuelles, jusqu’à la déclaration proactive de responsabilité du CEO de LayerZero, Bryan Pellegrino, cela marque une étape dans la délimitation des responsabilités.

Le « 1/1 DVN » fatal

Pour comprendre cette dispute, il faut d’abord analyser la méthode d’attaque du hacker. Fait intéressant, cette attaque ne provient pas d’une vulnérabilité complexe dans un contrat intelligent, mais d’un paramètre de configuration : le DVN 1/1.

Ce DVN, ou réseau de validateurs décentralisés, est un composant responsable de la validation des messages cross-chain dans l’architecture LayerZero V2. La configuration 1/1 signifie : tant qu’un seul validateur signe, le message cross-chain est considéré comme légitime et exécuté. Pire encore, le contrôle de cette « clé » ne repose pas entièrement sur Kelp, mais dépend des nœuds RPC sous-jacents. Le hacker, en empoisonnant le nœud RPC et en lançant une attaque DDoS, a détourné ce seul nœud validateur, lui envoyant de faux « enregistrements de destruction de la chaîne source ». Le validateur a cru, a signé, et cette énorme somme d’actifs a été créée de nulle part.

Alors, la question clé est : qui doit porter la responsabilité de ce « 1/1 DVN » ?

Les accusations mutuelles : collision de deux logiques

Dans les premières heures après l’attaque, l’opinion publique penchait initialement en faveur de LayerZero. Sur les réseaux sociaux, on se moquait de Kelp DAO : en tant que protocole de gestion de plusieurs centaines de millions de dollars, utiliser un « verrouillage en papier » avec un seul validateur 1/1 était presque impardonnable.

Cependant, lorsque le 21 avril, Kelp a publié une « déclaration officielle », un retournement spectaculaire de l’opinion s’est produit. Le point central de Kelp était une seule phrase : si la documentation officielle et la configuration par défaut sont intrinsèquement dangereuses, la responsabilité incombe à ceux qui ont écrit la documentation et défini les paramètres par défaut. Ce n’est pas une erreur de configuration utilisateur, mais un « défaut d’orientation » du produit lui-même. Bien que le CEO de LayerZero, Bryan Pellegrino, ait à plusieurs reprises souligné que cela relevait d’un choix au niveau de la couche applicative et non d’une vulnérabilité du protocole, le centre de la critique a commencé à se déplacer de l’« incompétence » de Kelp à la « arrogance systémique » de LayerZero — qui, en connaissance du risque, a quand même utilisé cette configuration comme exemple d’entrée rapide.

De plus, la voix des développeurs tiers a amplifié la controverse. Banteg, développeur principal de Yearn, a découvert lors d’un audit technique que le guide d’introduction rapide de LayerZero V2 utilisait cette vérification unique et dangereuse comme configuration par défaut sur Ethereum, BNB Chain, Polygon, Arbitrum et Optimism. Zach Rynes, responsable de la communauté Chainlink, a critiqué plus durement : il accuse LayerZero de faire passer ses utilisateurs suivant ses directives officielles pour des « boucs émissaires », afin de dissimuler la vulnérabilité de leur infrastructure face aux attaques de hackers de haut niveau.

Alors, qui a tort ou raison ? En réalité, personne n’a entièrement tort ni entièrement raison. La véritable nature de cette dispute est une collision de deux logiques : une « éthique de geek » — les outils sont neutres, et l’utilisateur doit assumer la responsabilité de ses choix —, et un « principe de sécurité par défaut » — le produit doit être dans un état de sécurité maximal à sa sortie d’usine. Les utilisateurs peuvent volontairement réduire la barrière d’entrée pour plus de commodité, mais le produit ne doit pas guider l’utilisateur vers le danger.