Toutes les études
02Blockchain & risque

R7 — transformer une exposition ouverte en risque borné

Un pont inter-chaînes fonctionne en régime normal. La vraie question est ce qu’il perd lorsque ses hypothèses cessent d’être vraies.

Cadre de l’étude

Protocole, organisation, incidents et paramètres entièrement synthétiques. Simulation déterministe et reproductible.

100 000 années synthétiques par architecture

Plan de lecture

Du problème à la décision

  1. 01

    Suivre un transfert

    Bloquer sur la chaîne de départ, transmettre une preuve, créer sur la chaîne d’arrivée.

  2. 02

    Identifier les chemins de perte

    Clés compromises, message rejoué, gouvernance trop rapide ou finalité insuffisante.

  3. 03

    Borner l’exposition

    Plafonds, délais, registre anti-rejeu et règles propres à chaque route.

  4. 04

    Formuler la décision

    Comparer les preuves obtenues aux conditions nécessaires avant un éventuel pilote.

01

Avant de commencer

Le problème

Une organisation reconstituée conçoit R7, une passerelle qui immobilise un actif sur une blockchain avant d’en créer une représentation sur une autre.

Cette étude porte sur une passerelle entre deux blockchains. Son rôle est de donner sur une chaîne une représentation d’un actif immobilisé sur une autre chaîne.

Le contrat installé sur la chaîne d’arrivée ne peut pas lire directement l’état de la chaîne de départ. Il doit donc faire confiance à une preuve transportée entre les deux réseaux : ici, un message signé par des clés autorisées. Les signatures prouvent que certaines clés ont approuvé le message ; elles ne prouvent pas, à elles seules, que ce qu’il affirme est vrai.

Le danger apparaît si la chaîne de destination crée un actif sans que l’actif d’origine soit réellement bloqué. Cela peut arriver si un faux message obtient assez de signatures compromises, si un dépôt observé trop tôt disparaît lors d’une réorganisation de la chaîne de départ, ou si la même preuve authentique est réutilisée plusieurs fois. Dans chacun de ces cas, le contrat d’arrivée peut exécuter exactement sa règle tout en partant d’une information fausse ou périmée.

Par exemple, si 100 unités sont immobilisées sur la chaîne A mais que deux messages identiques conduisent à créer deux fois 100 jetons sur la chaîne B, il existe 200 promesses de remboursement pour seulement 100 unités en réserve. La passerelle a alors fabriqué une dette non couverte.

02

Phase 1

Ce que l’organisation a construit

Nous commençons par comprendre le système tel qu’il est présenté, sans le caricaturer et sans encore proposer de correction.

Le transfert, étape par étape

Imaginons 100 unités déposées sur la chaîne A. Un contrat les place dans un coffre numérique. Des validateurs observent ce dépôt et signent un message. Un programme relais transporte ce message vers la chaîne B, qui crée alors 100 jetons représentatifs.

Ces jetons sur B ne sont valables que si les 100 unités restent immobilisées sur A. Lors du retour, les jetons représentatifs sont détruits sur B avant que les unités d’origine soient libérées sur A.

Cette égalité est la règle comptable essentielle : à tout instant, la quantité de jetons représentatifs encore en circulation ne doit pas dépasser la réserve effectivement immobilisée. Le protocole doit donc vérifier non seulement une signature, mais aussi l’existence, le montant, la finalité et l’unicité du dépôt annoncé.

Comment l’architecture initiale peut créer des jetons non couverts

La chaîne B ne voit pas le coffre de la chaîne A. Elle voit seulement un message disant, par exemple, « le dépôt numéro 42 a immobilisé 100 unités sur A ». Si trois clés volées ou contrôlées par le même attaquant signent cette phrase inventée, le contrat de B reconnaît trois signatures cryptographiquement valides et peut créer 100 jetons, alors qu’aucune réserve n’existe sur A. La cryptographie authentifie les signataires ; elle ne rend pas vraie une déclaration mensongère.

Même avec des signataires honnêtes, un dépôt peut être observé avant d’être définitif. Les clés signent, B crée les jetons, puis la chaîne A est réorganisée : les derniers blocs sont remplacés et le dépôt disparaît de l’historique retenu. Sans règle d’attente adaptée et sans procédure de mise en quarantaine, les jetons créés sur B ne disparaissent pas automatiquement.

Enfin, un message authentique peut être présenté deux fois, ou présenté sur une autre route, si son identifiant n’est pas enregistré comme déjà consommé et si la signature ne nomme pas précisément les deux chaînes et les contrats concernés. Un seul dépôt de 100 peut alors autoriser plusieurs créations de 100. Un relais malveillant peut tenter ces soumissions ; il ne devrait réussir que si les vérifications du contrat sont incomplètes.

Un seul programme relais transporte les messages, toutes les routes attendent douze blocs et aucun plafond ne limite le montant total, le montant d’un transfert ou le débit horaire. Une même faute peut donc être répétée plusieurs fois avant que l’équipe la détecte et arrête le système.

Ce que signifie exactement « trois signatures sur cinq »

Le nombre cinq ne vient pas des blockchains A ou B. C’est un choix de l’architecture reconstituée : le contrat de B contient la liste de cinq clés publiques autorisées, idéalement détenues par cinq opérateurs et environnements techniques séparés. Chacune observe le même dépôt sur A et peut signer son identifiant, son montant et sa destination.

Le contrat accepte n’importe quel groupe composé de trois clés distinctes parmi ces cinq ; il ne s’agit pas de trois validateurs choisis à l’avance. Ce seuil maintient le service si une ou deux clés sont indisponibles, car il en reste au moins trois. Il empêche aussi une ou deux clés compromises de fabriquer seules une autorisation.

La contrepartie est précise : dès qu’un attaquant contrôle trois clés, il atteint lui-même le seuil et peut signer un faux dépôt. Le nombre de clés n’aide donc que si leurs opérateurs, logiciels, secrets et infrastructures sont réellement indépendants. Cinq clés conservées dans le même environnement peuvent subir une seule compromission corrélée. Le seuil trois sur cinq est ici une hypothèse de conception à évaluer, pas une garantie universelle.

Résumé de l’approche initiale

  • Le prototype désigne cinq clés de signature propres à la passerelle ; le contrat d’arrivée accepte n’importe quel groupe de trois clés distinctes. Il continue donc avec deux clés indisponibles, mais trois clés compromises peuvent signer un dépôt inventé.
  • Un seul programme transporte les messages entre les chaînes.
  • Chaque paire de chaînes attend exactement douze confirmations, malgré des risques de réorganisation différents.
  • Aucun registre global n’interdit explicitement de consommer la même preuve sur plusieurs routes.
  • Aucune limite ne borne le montant total, un transfert isolé ou le débit horaire.

03

Phase 2

Ce que l’évaluation vérifie et propose

La deuxième phase reproduit le mécanisme, localise ce qui casse et transforme la critique en modification testable.

Réduire le risque d’une compromission commune

La refonte synthétique remplace les cinq clés et le seuil de trois par sept clés et un seuil de quatre. Elle exige surtout que les quatre signatures nécessaires proviennent d’environnements de défaillance séparés : opérateurs, secrets et infrastructures ne doivent pas partager le même point de compromission.

Avec ce seuil, trois clés indisponibles peuvent être tolérées et trois clés volées ne suffisent pas à fabriquer une autorisation ; quatre clés compromises le peuvent encore. Passer de cinq à sept ne constitue donc pas, à lui seul, une preuve de sécurité. L’indépendance réelle des détenteurs de clés doit être documentée, testée et auditée.

Séparer la vitesse de la création définitive

La proposition ne demande plus au contrat de création définitive d’être rapide. Un apporteur de liquidité peut avancer temporairement les fonds à l’utilisateur, à son propre risque, tandis que la création canonique attend la finalité de la chaîne source.

Chaque route reçoit un nombre de confirmations adapté à sa vitesse et à son profil de réorganisation. Le message inclut l’identité des chaînes, du contrat et de l’opération ; un registre global interdit de le consommer deux fois.

Transformer une perte ouverte en plafond

Trois limites se cumulent : 500 000 dollars par transfert, 750 000 dollars par heure et 5 millions de dollars par route. Un délai de 48 heures empêche une modification de gouvernance de devenir immédiatement exécutable.

La simulation mesure ensuite la fréquence des années avec perte, la perte moyenne et le percentile 99. Ce percentile n’est pas un maximum absolu : une année simulée sur cent environ est encore plus mauvaise.

Évaluation

  • Sous les hypothèses publiées, l’approche initiale produit une perte annuelle moyenne de 931 583 USD ; 99 % des pertes simulées restent sous 26,06 millions USD, mais 1 % les dépassent.
  • La chaîne d’arrivée ne voit pas directement le dépôt d’origine : elle agit sur un message. Un faux message signé par trois clés compromises, un dépôt supprimé par une réorganisation ou une preuve authentique rejouée peuvent donc créer plus de jetons que d’actifs immobilisés.
  • L’attente uniforme et une gouvernance immédiatement exécutable aggravent cette exposition, qui n’est plafonnée par aucune limite de montant ou de débit.
  • Ces chiffres décrivent le comportement d’un modèle synthétique, pas celui d’un protocole déployé.

Correction proposée

  • La refonte propose sept clés, quatre signatures obligatoires et quatre environnements de défaillance indépendants ; quatre clés compromises peuvent encore atteindre le seuil, ce qui doit être audité.
  • Chaque message nomme précisément ses chaînes, son contrat et son opération ; un registre global interdit de le consommer deux fois.
  • Le nombre de confirmations est adapté à chaque paire de chaînes.
  • Toute modification de gouvernance attend 48 heures ; le pouvoir d’urgence permet seulement une pause.
  • Les plafonds sont fixés à 5 millions USD par route, 500 000 USD par transfert et 750 000 USD par heure.
  • Un apporteur de liquidité peut avancer les fonds, tandis que la création définitive attend la finalité.

04

Notions et équations

Aucun symbole sans définition

Les mêmes fiches s’ouvrent depuis les liens « ? » placés dans le corps de l’article.

05

Résultats chiffrés

Ce que les nombres mesurent réellement

Les montants ci-dessous viennent d’un monde simulé. Ils servent à comparer deux architectures sous les mêmes règles de lecture, pas à prédire une perte réelle.

19.34% → 4.55%

années simulées avec perte

Fréquence des années où au moins une perte survient.

931 583 → 2 079 USD

perte annuelle moyenne

Moyenne sur 100 000 années synthétiques par architecture.

26,06 M → 20 122 USD

percentile 99 de la perte

99 % des pertes simulées sont inférieures ; 1 % sont pires.

1,06 M USD

borne opérationnelle d’incident

Plafond issu des limites de transfert, de débit et de réaction.

06 · Voir les preuves

Lire les graphiques pas à pas

Chaque figure indique d’abord comment lire ses axes et ses couleurs, puis ce qu’elle permet — ou non — de conclure.

07 · Protocole d’analyse

Comment l’analyse a été conduite

Protocole d’analyse

  • Deux simulations de 100 000 années, initialisées par les graines aléatoires 7173 et 7174.
  • Six familles d’incident ; leurs fréquences, gravités et montants exposés sont entièrement paramétrés.
  • 2 352 combinaisons de plafonds, de débit et de temps de réaction.
  • 192 règles d’attente et 12 scénarios de frais.
  • Le déroulement d’un transfert est représenté par quinze états successifs.

Limites à ne pas oublier

  • Toutes les probabilités et gravités sont des hypothèses de démonstration.
  • Les gains de la refonte dépendent en partie d’hypothèses améliorées par construction.
  • Les deux simulations n’emploient pas exactement les mêmes tirages aléatoires année par année.
  • Aucun contrat exécutable, réseau de test, audit ni preuve mathématique exhaustive du code.

09 · Décision

NO-GO

NO-GO initial — pilote plafonné uniquement après refonte et audit indépendant du code.

  1. 1

    L’architecture initiale permet à une erreur ou à trois clés compromises de créer une exposition sans plafond : elle est refusée.

  2. 2

    La refonte réduit fortement les pertes simulées grâce à des plafonds et des délais explicites. Une partie de l’amélioration vient toutefois des hypothèses choisies pour la refonte.

  3. 3

    Avant un pilote, il faut encore du code exécutable, des tests sur réseau de test, une vérification des invariants et un audit indépendant.

Étape suivante : La version initiale est refusée. Sous les seules hypothèses du modèle, la refonte ramène la perte annuelle moyenne à 2 079 USD et son percentile 99 à 20 122 USD. Un pilote reste conditionné à un audit indépendant du code.