Il y a un peu plus d’un an, les trois équipes responsables des implémentations du réseau Lightning ont joint leurs forces pour travailler sur une spécification commune du stack du protocole. Maintenant que cette spécification et que nos trois implémentations sont en voie de stabilisation et deviennent utilisables, il est temps d’aller plus loin : améliorer encore le protocole, ajouter des nouvelles fonctionnalités, simplifier, corriger les problèmes.
L’une des innovations majeures qui ont rendu Lightning possible était un mécanisme de mise à jour hors-chaîne (off-chain) pour renégocier un nouvel état et garantir que les états précédents ne pourraient pas être fixés on-chain. Aujourd’hui, nous sommes heureux de publier un nouvel article de recherche au sujet d’un mécanisme de mise à jour nouveau et plus simple pour les protocoles de niveau 2, que nous avons baptisé eltoo.
Comment marche eltoo ?
Nous pouvons nous représenter une négociation hors-chaîne comme un accord contractuel entre des parties, et la résolution (settlement), comme une décision de cour de justice rendant le jugement final ; la cour étant en l’occurrence la blockchain. Étant donné que tous les changements d’état ont lieu hors-chaîne, nous avons besoin d’un moyen pour que la cour sur la blockchain puisse entendre tous les arguments avant de trancher. Dans le cas où l’un des participants demande la résolution du contrat, il faut donc un mécanisme qui retarde la décision finale afin de donner aux autres parties l’opportunité de produire un état plus récent. La cour doit donc attendre un nouvel état, jusqu’à ce qu’elle décide de s’arrêter sur le plus récent dont elle ait eu connaissance. Contre toute attente, la blockchain de Bitcoin contient déjà les pré-requis pour créer cette blockchain sur-mesure pour le 2ème niveau.
Figure 1 : un exemple d’exécution du protocole eltoo, qui montre comment éviter des états intermédiaires en liant une mise à jour ultérieure à une autre antérieure, ou même directement à la transaction initiale. Seule la dernière transaction de résolution peut être confirmée sur la blockchain.
Dans eltoo, chaque état est représenté comme un ensemble de deux transactions : une transaction de mise à jour qui dépense l’output du contrat et crée un nouvel output, et une transaction de résolution qui dépense l’output nouvellement mis à jour et répartit les fonds selon l’accord entre les parties. Les outputs ont un script qui permet d’attacher une transaction à jour ou d’attacher une transaction finale après un timeout configurable. Si les participants s’accordent sur une mise à jour avant la fin du timeout, ils vont ainsi créer une nouvelle transaction, dépenser l’output précédent et réaliser une double-dépense de la transaction finale, ce qui va l’invalider.
L’invalidation répétée de l’état préexistant pour s’accorder sur un nouvel état forme une longue chaîne de transactions de mises à jour qui sera finalisée par une ultime transaction. Cela présente un inconvénient majeur : si nous voulons arriver à une résolution, nous devons rejouer l’intégralité de la chaîne sur la blockchain. Autant jouer le protocole directement on-chain. L’idée principale de eltoo est que nous pouvons sauter les mises à jour intermédiaires, et connecter directement la transaction finale à celle qui a initialisé le contrat. Afin de réaliser ce court-circuit dans les mises à jour, nous proposons un nouveau SIGHASHflag, SIGHASH_NOINPUT, qui permet à l’input d’une transaction d’être lié à n’importe quel output de transaction dont le script correspond. Étant donné que les scripts des outputs des transactions précédentes correspondent aux scripts des inputs suivants, nous pouvons lier une mise à jour ultérieure à n’importe quelle transaction antérieure, nous autorisant effectivement à enjamber toutes les transactions intermédiaires. L’article contient l’ensemble de la construction du protocole, y compris les détails de celle des scripts.
Améliorer Lightning
Ce que nous avons présenté ci-dessus est une mécanisme de mise à jour qui autorise les points d’arrivée d’un canal de paiement à ajuster de façon répétée leur solde et à attacher des constructions plus avancées telles que des HTLCs à chaque état.
La contribution principale de l’article original sur Lightning portait justement sur un tel mécanisme de mise à jour, sommes-nous donc en train de remplacer Lightning avec cette proposition ? Absolument pas !
Figure 2 : un diagramme des différents sous-protocoles qui font partie du stack de Lightning.
Les spécifications du Lightning Network ne sont plus celles d’un protocole unique, mais plutôt celles d’un stack complet de protocoles, chacun avec ses propres responsabilités. Eltoo ne vise pas à remplacer l’intégralité de ce stack ; il s’agit d’un remplacement pour le mécanisme de mise à jour initial, et qui reste rétrocompatible avec les autres parties du stack.
Eltoo fait des compromis fondamentalement différents de ceux du mécanisme présenté dans l’article Lightning original, que nous appelons “LN-penalty” : là où LN-penalty cherche à pénaliser le comportement malhonnête d’une partie, eltoo se contente de faire respecter le dernier état du contrat hors-chaîne sur lequel les parties se sont accordées. Cela a des implications importantes pour la réalisation et la sécurité des protocoles construits sur ce mécanisme.
Cela est en partie dû au fait que tous les participants dans eltoo partagent les mêmes transactions, contrairement à LN-penalty qui implique une asymétrie dans les transactions accessibles à chaque participant et qui adapte la réaction à adopter face à une partie malhonnête. Ce changement élimine ce que nous appelons les “informations toxiques” dans Lightning. Ces “informations toxiques” sont les transactions appartenant à des états périmés, et dont la divulgation sur le réseau peut entraîner une perte de fonds. Cela n’arrive pas seulement quand une partie est malhonnête, mais aussi si un noeud oublie une mise à jour (par exemple, dans le cas d’une restauration depuis une sauvegarde). Avec eltoo cela n’est plus possible car seuls les états sur lesquels les parties se sont accordées peuvent être résolus sur la blockchain (autrement dit, il n’y a plus de pénalité dans eltoo).
La gestion des données est également simplifiée pour les participants avec ce nouveau paradigme : ils n’ont plus besoin de stocker des pré-images de hash pour les états déjà invalidés, et n’ont pas besoin de stocker des HTLCs invalidés, puisque la transaction finale à laquelle ils ont été attachés ne pourra jamais être validée sur la blockchain. Tout ce dont ils ont besoin, c’est la dernière transaction à jour, sa transaction finale correspondante, et éventuellement les HTLCs dépensés à partir de cette dernière. Bien plus, la résolution ne consiste plus qu’à relier la dernière transaction à l’output de la transaction initiale et à laisser expirer le timeout avant de la diffuser.
Nous pouvons combiner les outputs mis à jour avec SIGHASH_SINGLE pour permettre d’attacher des inputs et outputs supplémentaires à la transaction au moment de la résolution. Cela peut sembler un changement mineur, mais cela permet en fait d’attacher des frais de transaction à la transaction au moment où on demande sa résolution, ce qui dispense les parties d’avoir à s’accorder sur un montant fixe de frais en avance. Dans l’implémentation actuelle, nous devons nous accorder sur un montant fixe et, peut-être, le bloquer pendant des mois avant de tenter de confirmer la transaction sur la blockchain, ce qui nous oblige à tenter de prévoir l’évolution du marché des frais de transaction. Cela peut engendrer des surestimations massives, par mesure de sécurité. Avec une sélection des frais retardée au dernier moment nous n’avons plus besoin de trouver un accord sur un montant, et nous pouvons même les augmenter après coup s’ils sont insuffisants.
Grâce aux feature flags, qui permettent à un noeud de signaler la prise en charge d’une nouvelle fonctionnalité lorsqu’il se connecte pour la première fois à un pair, eltoo peut être déployé progressivement sur le réseau actuel. Pas besoin de lancer un nouveau réseau à partir de rien.
Au-delà de Lightning
En tant que mécanisme de mise à jour générique pour protocole de 2ème niveau, eltoo peut être utilisé par d’autres circuits que Lightning. Par exemple, il permet de créer des contrats hors-chaîne multi-parties, jusqu’à 7 participants actuellement, et ce nombre peut devenir illimité si combiné avec les signatures de Schnorr.
L’un de ces contrats hors-chaîne pourrait être “l’usine de canaux” présentée par Burchert et al. comme un moyen de créer un nombre illimité de canaux de paiement avec une seule transaction sur la blockchain, et de modifier ou réallouer les fonds de façon dynamique, sans même toucher la blockchain.
La route vers eltoo
Avant que nous puissions implémenter eltoo, nous devons effectuer un changement mineur sur Bitcoin : l’introduction de SIGHASH_NOINPUT pour les signatures. Cela a été discuté il y a quelques mois dans le contexte des watchtowers destinées à sécuriser les canaux Lightning, mais n’a pas fait l’objet de proposition formalisée. Une telle proposition a été faite dans l’article sur eltoo.
Nous invitons la communauté à considérer notre proposition et à participer aux discussions. Nous espérons arriver à un consensus pour l’utilisation de SIGHASH_NOINPUT, afin qu’il puisse être accepté et inclus dans un soft fork à venir des Scripts Bitcoin. Cela nous mettra sur la bonne voie pour rendre Lightning plus fiable et plus simple, en incorporant un nouveau mécanisme de mise à jour qui pourra également être utilisé pour bien d’autres applications.