
L'affaire du vol de 1,4 ETH : comment le mécanisme de sécurité de Lido donne une leçon à l'industrie
TechFlow SélectionTechFlow Sélection

L'affaire du vol de 1,4 ETH : comment le mécanisme de sécurité de Lido donne une leçon à l'industrie
Dans la nuit, un pirate informatique a infiltré l'une des adresses du contrat multi-signatures de l'oracle Lido, dérobant 1,4 ETH avant de se faire repérer.
Rédaction : @IsdrsP, responsable des validateurs Lido
Traduction : Nicky, Foresight News
Dans la nuit du 10 mai, le fournisseur d'oracle Chorus One a révélé qu'un portefeuille chaud de l'oracle Lido avait été piraté, entraînant le vol de 1,46 ETH. Toutefois, selon une analyse de sécurité, cet incident isolé a eu un impact limité, car le portefeuille concerné était conçu dès l’origine uniquement pour des opérations légères.
Une attaque contre un oracle semble effectivement grave. Pourtant, l'architecture de Lido, les valeurs partagées par ses parties prenantes et sa culture axée sur la sécurité signifient que l'impact d’un tel événement reste extrêmement limité — même en cas de compromission totale de l’oracle, aucune conséquence désastreuse ne s’ensuivrait.
Qu’est-ce donc qui rend Lido si particulier ?
Une conception réfléchie et des mécanismes de protection multicouches
Les oracles de Lido ont pour fonction de transmettre les informations de la couche consensus vers la couche exécution, et de rapporter la dynamique du protocole. Ils ne contrôlent pas les fonds des utilisateurs. Un oracle défaillant n'entraîne qu’un simple dysfonctionnement mineur, et même une compromission du quorum n'aurait pas de conséquences catastrophiques.
Quelles actions malveillantes un oracle compromis pourrait-il tenter ?
A) Soumettre un rapport malveillant (mais qui sera ignoré par les oracles honnêtes) ;
B) Épuiser le solde ETH de l’adresse spécifique de cet oracle (cette adresse étant uniquement destinée aux transactions opérationnelles, sans fonds de participants au staking).
Quelles sont exactement les responsabilités des oracles ?
Les oracles de Lido constituent essentiellement un mécanisme distribué composé de 9 participants indépendants (nécessitant un accord 5/9), chargés principalement de rapporter l’état du protocole. Leurs fonctions principales actuelles incluent :
• La distribution des récompenses d’inflation de jetons (rebase)
• Le traitement des retraits
• La surveillance des sorties et performances des validateurs, à des fins de référence par le CSM (Community Security Module)
Ces oracles soumettent au protocole des « rapports » sur l’état qu’ils observent. Ces rapports servent à calculer les récompenses ou pénalités cumulées quotidiennement, à mettre à jour les soldes stETH, à traiter puis confirmer définitivement les demandes de retrait, à calculer les demandes de sortie des validateurs et à évaluer leurs performances.
Fondamentalement, les oracles de Lido diffèrent des « multisignatures » traditionnelles. Ils n’ont aucun accès aux fonds des participants au staking ni aux fonds du protocole, ne peuvent contrôler aucune mise à niveau de contrat, ni se mettre à jour eux-mêmes ni gérer leur propre adhésion. En revanche, c’est le DAO Lido qui maintient la liste des oracles via des votes.
Les fonctionnalités des oracles sont très restreintes — elles se limitent strictement à : soumettre des rapports conformes à des algorithmes déterministes, audités et open source, spécifiquement conçus pour différents objectifs du protocole ; et dans certains cas précis, exécuter des transactions afin de concrétiser les résultats des rapports (par exemple, l’opération quotidienne de rebase du protocole).
Si 5 des 9 oracles étaient compromis, quelle serait la pire situation possible ? Dans ce scénario, les oracles compromises pourraient s’entendre pour soumettre des rapports malveillants, mais tout rapport doit obligatoirement passer des vérifications de cohérence imposées par la chaîne.
Si un rapport viole ces vérifications de cohérence, son temps de traitement sera prolongé (voire potentiellement bloqué indéfiniment), car les valeurs contenues doivent respecter une plage de variation autorisée sur une période donnée (plusieurs jours ou semaines).
Dans le pire des cas, cela pourrait signifier qu’une opération de rebase du stETH (positive ou négative) prendrait plus de temps pour entrer en vigueur, affectant ainsi les détenteurs de stETH, bien que l’impact reste minime pour la majorité, sauf pour ceux utilisant le stETH avec effet de levier dans DeFi.
Il existe également d’autres risques : si des oracles malveillants ou leurs complices détiennent certaines informations ou sont capables d’imposer de lourdes sanctions au niveau de la couche consensus (comme des slashing massifs), ils pourraient exploiter le retard de mise à jour du stETH sur la couche exécution à des fins lucratives.
Par exemple, en cas de slashing massif, certaines personnes pourraient vendre une partie de leur stETH sur une DEX avant qu’un rebase négatif n’entre en vigueur. Cependant, cela n’affecterait pas les retraits initiés directement par les utilisateurs via Lido, car le mode « bunker » du protocole serait activé, garantissant un traitement équitable des retraits.
Transparence immédiate et complète
Depuis toujours, tous les acteurs de l’écosystème Lido — qu’il s’agisse des contributeurs, des opérateurs de nœuds ou des opérateurs d’oracles — placent la transparence et la bonne foi au premier plan, priorisant la protection des participants au staking et la santé globale de l’écosystème.
Que ce soit en publiant volontairement des analyses post-mortem détaillées, en compensant les pertes de staking dues à des interruptions d’infrastructure, en retirant préventivement des validateurs ou en publiant rapidement des rapports complets sur les incidents, ces acteurs ont constamment mis la transparence au cœur de leurs actions.
Amélioration continue
Lido se situe constamment à la pointe de la recherche technologique, s’efforçant d’utiliser la technologie des preuves à connaissance nulle (ZK) pour renforcer la sécurité et le caractère sans confiance de ses mécanismes d’oracle. Dès les premières étapes, l’équipe a alloué plus de 200 000 dollars en financement dédié pour permettre une vérification fiable des données de la couche consensus via des preuves ZK.
Ces explorations techniques ont abouti au développement par SuccinctLabs d’un mécanisme d’« double vérification » utilisant un oracle ZK SP1, dont le déploiement officiel est prévu cette année. Ce mécanisme, basé sur des données de consensus vérifiables, apportera une couche de sécurité supplémentaire pour valider toute opération potentielle de rebase négative.
Actuellement, ces technologies ZK sont encore en développement : les machines virtuelles ZK (zkVM) associées doivent encore être éprouvées en conditions réelles, et souffrent de limitations telles qu’une vitesse de calcul lente et un coût élevé, ne permettant pas encore de remplacer complètement les oracles de confiance. À long terme toutefois, ces solutions pourraient devenir des alternatives minimisant la confiance par rapport aux oracles existants.
La technologie des oracles est complexe et varie fortement selon les cas d’usage dans DeFi. Dans le protocole Lido, les oracles, conçus comme composant central, bénéficient d’une architecture soigneusement décentralisée, d’une séparation des responsabilités et de multiples couches de vérification, réduisant significativement l’étendue des impacts liés aux risques potentiels.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News














