Clé de révocation

Pourquoi la révocation

Un canal Lightning parcourt plusieurs états : à chaque paiement, un nouveau commitment est signé. Le problème : l'ancien commitment reste théoriquement publiable et permettrait à une partie de revenir à un état plus favorable. Pour empêcher cela, le protocole BOLT-3 introduit un mécanisme cryptographique de révocation : chaque mise à jour invalide rétroactivement le commitment précédent, en attribuant des conséquences catastrophiques à sa publication.

Comment ça marche

Lors de la création d'un commitment, chaque partie inclut une clé de revocation publique dans le script qui verrouille la sortie pénalisable. Cette clé est dérivée de la combinaison :

revocation_pubkey = base_point + per_commitment_point

Quand l'état devient obsolète (un nouveau commitment est signé), les parties s'échangent le per-commitment-secret correspondant à l'ancien commitment. À partir de ce secret, n'importe qui peut reconstruire la clé privée de révocation et signer la « justice transaction » qui prend tout le solde du canal.

Conséquence d'une publication frauduleuse

| Scénario | Conséquence | |----------|-------------| | Publication d'un commitment courant | Fermeture normale, solde respecté | | Publication d'un commitment révoqué | Pendant CSV, contrepartie peut tout prendre | | Pas d'observation pendant CSV | Le tricheur s'en tire avec son ancien solde |

Le délai CSV (Channel Sweep Verification, en pratique 144-2016 blocs) est la fenêtre où la justice peut s'exécuter. D'où l'importance des watchtowers.

Structure des secrets

LND, CLN et Eclair utilisent une structure d'arbre déterministe (per-commitment secret hash chain, type BIP-32) pour stocker compactement tous les secrets passés. Cela évite de devoir conserver une copie séparée pour chaque mise à jour, qui pourrait représenter des dizaines de milliers d'états sur un canal actif.

Limites du modèle

• Nécessite que chaque partie conserve l'historique des secrets
• Pas de récupération si l'opérateur perd son state (catastrophe : le moindre commitment publié serait considéré comme frauduleux)
• Complexité importante pour les implémentations
• DoS possible via update floods

Le modèle alternatif : eltoo

eltoo, proposé par Christian Decker, Rusty Russell et Olaoluwa Osuntokun en 2018, supprime la révocation au profit de state numbers monotones. Avec un soft fork SIGHASH_ANYPREVOUT (ex-SIGHASH_NOINPUT), un état postérieur peut toujours « réécrire » sur un état antérieur sans pénalité. Plus simple, plus sûr, mais ANYPREVOUT n'est toujours pas activé en 2026.

À retenir

La clé de révocation est l'astuce cryptographique qui rend Lightning sécurisé sans nécessiter de coopération continue : si vous trichez, vous perdez tout. Sa complexité opérationnelle reste le motif principal des recherches autour d'eltoo et de la simplification future du protocole.