Un chant courant de la part de nombreuses personnes dans cet espace ces jours-ci en réponse à toute discussion sur les modifications apportées au protocole Bitcoin est « Ne plaisantez pas avec la couche 1 ! Vous pouvez simplement le construire sur la couche 2 ! » Cela semble être une chose très logique à faire, non ? Pourquoi risquer la sécurité et la stabilité de L1 alors que vous pouvez simplement construire dessus ? Le problème est que cela ne parvient fondamentalement pas à comprendre la relation entre la couche 1 et la couche 2.
Un protocole L2 est une extension du L1. Tout ce pour quoi un L2 est conçu doit en fin de compte se réduire à ce dont le L1 est capable. La déclaration générale « fais-le sur L2 ! » obscurcit de nombreuses réalités implicites sur ce qui peut ou ne peut pas être fait sur un L2 étant donné l’état actuel de la couche de base. Par exemple, imaginez essayer de créer le réseau Lightning sans l’existence de scripts multisignatures. Vous ne pouviez pas. Il ne serait pas possible de partager le contrôle entre plusieurs personnes, et le concept même de canal de paiement ne serait pas possible.
L’évolution des canaux de paiement
La raison pour laquelle les canaux de paiement peuvent exister est en premier lieu due au fait que L1 de Bitcoin prend en charge la possibilité pour plusieurs personnes de partager le contrôle d’un UTXO avec un script multisig. Ce qui est possible sur une L2 est intrinsèquement limité par ce qui est possible sur une L1 ; oui, bien sûr, il est possible de faire des choses sur L2 qui ne sont pas possibles sur L1, mais le facteur limitant en fin de compte de ce que vous pouvez faire hors chaîne est ce qui est possible en chaîne. Une confirmation de paiement plus rapide dans un canal de paiement n’est possible que parce que la garde en chaîne peut être partagée entre plusieurs personnes.
Même cela ne suffit pas pour un canal de paiement sécurisé. Le canal de paiement d’origine avait une transaction pré-signée utilisant un timelock nLocktime qui restitue au bailleur de fonds son argent après tant de blocages, et ne prenait en charge les canaux de paiement que dans une seule direction. La malléabilité des transactions rendait l’utilisation de ces canaux de paiement originaux peu sûrs. Si la transaction de financement était malmenée par quelqu’un avant d’être confirmée, la transaction de remboursement serait alors invalidée et le bailleur de fonds n’aurait aucun moyen de réclamer son argent. L’autre partie dans le canal pourrait effectivement garder son argent en otage.
CHECKLOCKTIMEVERIFY, l’opcode timelock absolu, était la solution. CLTV vous permet de rendre une pièce inutilisable jusqu’à une certaine hauteur de bloc ou une certaine heure dans le futur. Ceci, combiné à la possibilité de créer des scripts pouvant être dépensés de plusieurs manières, a permis à l’UTXO multisig de disposer d’un chemin de script permettant au bailleur de fonds de dépenser lui-même tous les fonds après un délai. Cela garantissait que le bailleur de fonds serait en mesure de réclamer l’argent dans le pire des cas, même si la transaction de financement était malléable. Cependant, le canal ne pouvait encore faciliter que les paiements unidirectionnels.
Afin de faciliter les paiements bidirectionnels, une solution appropriée à la malléabilité des transactions était nécessaire. Cela a été une énorme motivation pour Segregated Witness. Un timelock est tout ce qui était nécessaire pour un canal à sens unique, car l’argent seulement augmenté dans une direction. Le seul risque pour l’expéditeur était que l’autre partie ne réclamerait jamais ce qui lui avait déjà été envoyé en chaîne, laissant le reste de l’argent de l’expéditeur piégé. Le remboursement du timelock a incité le destinataire à réclamer des fonds en chaîne avant le timelock, lorsqu’il perdrait tous les fonds qui avaient déjà été envoyés, et à l’expéditeur un recours dans le pire des cas au cas où quelque chose se produirait pour mettre définitivement le destinataire hors ligne. . Script ne prend pas en charge l’application de certains montants à certains scripts futurs, donc une transaction pré-signée est le seul mécanisme de remboursement initial viable si les paiements doivent circuler dans les deux sens. Cela a rouvert le risque que les fonds soient retenus en otage.
Avec la mise à niveau vers Segwit, ce problème a été résolu. À la place du remboursement par timelock incitant à un comportement honnête, la clé de pénalité a été introduite. Étant donné que les fonds dans un canal bidirectionnel peuvent circuler dans chaque direction, il y aura inévitablement un cas où les deux parties disposaient de plus d’argent dans un état antérieur du canal que dans l’état actuel. En établissant une branche dans la transaction pré-signée de chaque état du canal à l’aide d’une clé de pénalité, les utilisateurs peuvent les échanger après avoir signé le nouvel état et savoir si l’autre partie essaie d’utiliser une ancienne transaction, ils peuvent réclamer 100 % des fonds du canal. Les timelocks sont utilisés pour garantir que le chemin de dépenses normal où les utilisateurs prennent leurs soldes respectifs n’est pas valide pendant un certain temps afin de donner aux parties de la chaîne la possibilité d’utiliser la clé de pénalité si nécessaire. Il y a cependant un problème avec cela, l’utilisation de CLTV signifie qu’à un moment donné dans le futur, la chaîne a fermer, sinon le délai expirera et vous ne disposerez plus de cette période de sécurité pour pénaliser la partie malhonnête.
Les canaux de paiement bidirectionnels nécessitaient également CHECKSEQUENCEVERIFY, ou des timelocks relatifs, afin de résoudre ce problème. Contrairement à CLTV, qui spécifie une heure ou une hauteur de bloc spécifique dans le futur, CSV spécifie une durée relative ou un nombre de blocs à partir du moment ou du bloc auquel l’UTXO utilisant CSV dans le script est confirmé dans la blockchain. Cela a permis à la période de sécurité de fonctionner pour l’utilisation de clés de pénalité sans obliger les canaux à se fermer en chaîne à un moment prédéterminé.
Même cela ne nous donne pas le Lightning Network. Il n’existe toujours aucun moyen d’acheminer un paiement sur plusieurs canaux de paiement. Ils peuvent effectuer des paiements dans les deux sens, mais uniquement entre les deux personnes impliquées dans le canal. Afin d’acheminer les paiements sur plusieurs canaux, vous avez besoin, vous l’aurez deviné, d’autres fonctionnalités du L1. Les contrats Hash Time Locked permettent d’y parvenir, et ils nécessitent à la fois CLTV et hashlocks. Les Hashlocks nécessitent de fournir la pré-image d’un hachage afin de dépenser les pièces. C’est comme une signature, sauf que vous révélez simplement la « clé privée » au lieu de signer avec elle. Cela permet au destinataire d’un paiement Lightning de fournir un hashlock, et chaque canal intermédiaire entre l’expéditeur et le destinataire crée un script qui permet de dépenser immédiatement avec la pré-image de hachage, ou de rembourser l’argent en arrière après un timelock. Si le destinataire révèle le hashlock, tout le monde peut réclamer l’argent pour transférer le paiement, sinon, l’argent peut être réclamé en arrière et inversé sans le finaliser.
Ainsi, le Lightning Network tel qu’il existe aujourd’hui dépend entièrement de cinq les fonctionnalités étant possibles sur la couche de base de Bitcoin. Scripts multisignatures, timelocks absolus, timelocks relatifs, Segregated Witness et hashlocks. Sans l’une de ces fonctionnalités existant sur L1, Lightning tel que nous le connaissons aujourd’hui ne serait pas un L2 possible que nous pourrions construire. Son existence en tant que L2 dépend entièrement de la capacité du L1 à faire certaines choses. Donc, si vous le faisiez, dans un monde avec un Bitcoin qui ne prenait pas en charge les hashlocks, les timelocks dans les scripts et aucun correctif de malléabilité, dites simplement « Construisez simplement un système de canal de paiement multi-sauts bidirectionnel sur la couche 2 ! Nous ne devrions pas jouer avec la couche 1 », ce serait une déclaration complètement incohérente.
La prise
Cela dit, d’un point de vue strictement technique, il aurait toujours été possible de construire ce système de canaux de paiement multi-sauts bidirectionnels dans ce monde sans ces trois fonctionnalités sur L1. À massif coût en termes d’instauration de la confiance chez les autres pour qu’ils ne volent pas votre argent lorsqu’ils en sont capables. Une sidechain fédérée. Tout le monde aurait pu simplement créer une chaîne fédérée comme Liquid ou Rootstock et ajouter ces fonctionnalités à la sidechain, construisant ainsi le réseau Lightning là-bas plutôt que sur la chaîne principale. Le problème, c’est que ce n’est pas la même chose. Sur le plan technique, le réseau fonctionnerait exactement de la même manière, mais personne ne l’utilisant n’aurait le même degré de contrôle sur ses pièces.
Lorsqu’ils fermaient un canal Lightning, cela s’installerait sur une sidechain soutenue par une fédération, c’est-à-dire qu’il s’agirait simplement d’une écriture comptable au-dessus du portefeuille multisig de quelqu’un d’autre où vous n’avez aucune possibilité de contrôler ces pièces sur L1. Il suffit de faire confiance au groupe distribué qui gère la fédération pour ne pas embêter tout le monde. Même les chaînes de transmission (qui, ironiquement, nécessitent elles-mêmes la création de nouvelles fonctionnalités L1) ne sont qu’une autre forme de fédération en fin de compte, avec quelques restrictions supplémentaires ajoutées au processus de retrait. La fédération n’est composée que de mineurs et non de personnes détenant des clés privées.
C’est la réalité implicite, qu’ils la comprennent ou non, qui sous-tend la réaction « il suffit de le construire sur L2 ! » chaque fois que quelqu’un discute des améliorations de la L1. Il y a la portée de ce qui est déjà possible de construire sur L2, qui est plutôt limitée et restreinte par ses propres limitations d’échelle, et puis il y a la portée de ce qui n’est pas déjà possible. Tout ce qui entre dans cette dernière catégorie est impossible à construire sans l’intervention d’une entité de confiance ou d’un groupe d’entités qui contrôle en fin de compte les fonds des utilisateurs pour leur compte.
À quoi ça sert?
La « couche 2 » n’est pas une incantation magique. Vous ne pouvez pas simplement agiter une baguette magique et chanter les mots, et tout devient magiquement possible. Il existe des limites strictes et incontournables à ce qu’un L2 peut accomplir, et ces limitations sont ce que le L1 peut accomplir. Il s’agit simplement d’un fait inhérent à la réalité technique lorsqu’on examine un système comme Bitcoin. Vous ne pouvez en aucun cas y échapper, sauf en dégradant de plus en plus les hypothèses de confiance à mesure que vous construisez une L2 plus flexible au-delà des capacités de la L1.
Ainsi, lorsque des discussions ont lieu autour de ces questions, par exemple sur les améliorations qui peuvent être apportées à la L1, deux choses sont de la plus haute importance. Premièrement, ces améliorations apportées au L1 visent presque entièrement à permettre la construction de L2 plus flexibles et évolutifs. Deuxièmement, les L2 ne peuvent pas tout activer comme par magie. Les L2 ont leurs propres limites basées sur celles de la L1, et avoir une discussion sur les modifications apportées à la L1 sans reconnaître que le seul moyen de contourner ces limitations est d’introduire des entités de confiance n’est pas une conversation honnête.
Il est temps de commencer à reconnaître la réalité si nous voulons discuter de ce qu’il faut faire avec Bitcoin à l’avenir, sinon rien ne se passe à part le déni de la réalité et le gaslighting. Et ce n’est pas productif.
