Nous commençons déjà à voir les prémices du potentiel de deuxième couche se développer à partir des primitives de la couche de base qui ont été ajoutées ou optimisées dans la première décennie. Lightning, bien qu'il soit encore soumis à de très grandes limitations, commence vraiment à prospérer. Et il s'agit là de la première version limitée actuellement spécifiée et déployée. Il y a maintenant des sidechains de divers types déployés : Liquid, RSK, et même des chaînes de jetons liées à Bitcoin développées par Commerceblock. Ce n'est que le début.
Schnorr and Taproot
Juste au-dessus de l’horizon, nous avons la combinaison de Schnorr et de Taproot. Du côté de Schnorr, il s’agit d’un schéma de signature beaucoup moins coûteux à vérifier par lots, ainsi que du prochain grand bond en avant dans l’optimisation de la construction de scripts multi-signatures dans Bitcoin. Multisig a commencé comme un simple bourrage de toutes les clés publiques et du script pour le multisig dans une sortie de transaction à envoyer, et devant inclure tout cela dans l’entrée pour le dépenser. P2SH a optimisé l’aspect de sortie, en incluant un hachage de longueur constante des clés publiques et des scripts du multisig, ce qui permet d’économiser des frais pour toute personne envoyant à une adresse multisig et de ne laisser un coût accru que pour l’expéditeur. SegWit a sans doute « optimisé » davantage en rendant les dépenses d’UTXO multisig moins chères avec la remise des témoins. Schnorr pousse toute cette optimisation incrémentale à l’extrême. Vous combinez les clés publiques individuelles en une seule clé, pour laquelle tout le monde peut collaborer pour faire une seule signature, et il suffit de le vérifier. Cela permet de réaliser des économies massives pour toutes les utilisations du multisig, y compris les couches secondaires comme Lightning et les sidechains fédérées, et crée également un avantage en matière de confidentialité en rendant tous ces UTXO multisig impossibles à distinguer des UTXO à signature unique.
Maintenant, cela ne rend pas magiquement tout complètement privé. Les états de canal Lightning (transactions) nécessitent toujours des chemins de clés séparés pour leurs transactions de pénalité afin de réagir à la soumission des anciens états. Cela signifie que ceux-ci doivent être dans les scripts de sortie, ce qui crée une empreinte digitale. Taproot résout cela avec sa cryptomagie en vous permettant de vous engager à un arbre de Merkle de différentes conditions de dépense, qui ne nécessitent que la condition utilisée et la preuve de Merkle à la racine de Merkle pour dépenser, à une clé publique Schnorr à l'aspect normal. Maintenant, vous pouvez masquer ce chemin de script de pénalité avec taproot. Vous pouvez masquer tout chemin de script conditionnel avec Taproot, enfoui sous une clé Schnorr à l'aspect parfaitement normal qui permet à tous les participants de s'accorder sur quelque chose et de réaliser une transaction à l'aspect parfaitement normal.
SIGHASH_ANYPREVOUTPUT
SIGHASH_ANYPREVOUTPUT (précédemment SIGHASH_NOINPUT) est espérons-le le prochain nouveau primitive à venir. Il s'agit d'une nouvelle format de clé publique/mise à niveau du drapeau sighash. Les drapeaux Sighash spécifient quelles parties d'une transaction une signature s'engage. Cette fonctionnalité est là pour que vous puissiez faire quelque chose comme signer simplement votre entrée et sorties, mais permettre à d'autres personnes d'ajouter leurs propres entrées et sorties à une transaction sans l'invalidation. Mais actuellement, une signature doit s'engager dans une UTXO exacte d'une transaction exacte. SIGHASH_ANYPREVOUT, entre autres, permettrait l'engagement d'une signature dans un script UTXO seulement, pas un UTXO spécifique réel. Cela permet une nouvelle manière (eltoo) de construire les états de canal Lightning qui ne nécessite pas de clé de pénalité ou de traiter avec des anciens états en permettant à la partie lésée de confisquer tout l'argent. Au lieu de cela, l'état actuel du canal pourrait simplement re-dépenser l'ancien état du canal s'il perdait la course de double dépense, garantissant que tout le monde obtient son solde de canal actuel sur la chaîne au lieu d'un solde obsolète antérieur. Vous y parvenez simplement en réutilisant le même script au bon endroit et en utilisant SIGHASH_ANYPREVOUT.
Cela élimine beaucoup de risques liés à la perte des états de canal actuels, ce qui entraîne une transaction de pénalité prenant vos fonds pour une erreur honnête. Cela permet également BEAUCOUP plus. Maintenant, nous pouvons avoir des canaux Lightning avec plus de 2 participants, et même empiler des "sous-canaux" au-dessus de ceux-ci. De plus, SIGHASH_ANYPREVOUT et eltoo permettent la création de Statechains, un type de construction de canal fédéré qui permet aux nouveaux participants d'entrer et de sortir complètement hors chaîne avec l'hypothèse de confiance selon laquelle la fédération ne colludera pas avec les anciens participants pour escroquer qui que ce soit. Cela ouvre beaucoup de potentiel pour ce que j'appelle à moi-même des "protocoles UTXO statiques multipartites."
OP_CHECKTEMPLATEVERIFY
OP_CTV est une proposition de Jeremy Rubin visant à permettre un type très basique de “pacte” sur Bitcoin. Un pacte est une restriction plus compliquée concernant la dépense d'une pièce au-delà des signatures de certaines clés. Le type de pacte que la proposition de Rubin mettrait en œuvre est un “modèle”. En gros, cela permet à un script UTXO d'exiger que des sorties exactes spécifiques soient créées par la transaction de dépense. Ainsi, une fois qu'un UTXO est créé en utilisant OP_CTV, il est imposé par consensus que l'UTXO doit être dépensé à des adresses spécifiques dans les montants spécifiques définis dans le script de cet UTXO. Vous pouvez même les chaîner ensemble de sorte que l'un de ces UTXO soit contraint d'en créer quelques-uns de plus, qui sont ensuite contraints d'en créer quelques-uns de plus, et ainsi de suite.
Cela a une énorme applicabilité générale partout. Dans les environnements à frais élevés, un seul UTXO peut être effectué par une entité dépositaire qui, 100% selon les règles de consensus, garantit que tous les fonds de ses clients se retrouveront sous le contrôle de ses clients, même s’ils n’y ont pas accès immédiatement sur le moment. Cela a beaucoup de synergie potentielle avec les canaux multipartites (channel factories), dans la mesure où un « retrait » de masse effectué de cette manière peut également créer et être utilisé simultanément comme une usine à canaux. OP_CTV peut être utilisé pour créer des canaux de paiement qui fonctionnent au moins de manière unidirectionnelle sans que le destinataire n’ait à participer ou à disposer d’une clé en ligne pour recevoir des paiements (and n’oubliez pas que vous pouvez empiler des canaux sur chaque other). Il peut même être utilisé pour permettre à un seul canal de traiter plus de HTLC à la fois en les regroupant avec la même astuce que le premier exemple avec les retraits dépositaires. Et pourrait même créer un certain potentiel pour de nouveaux types de coinjoins.
Mettre tout en œuvre
En supposant que toutes les propositions ci-dessus soient adoptées et incorporées dans Bitcoin, je pense vraiment qu'à part les développeurs travaillant réellement à la pointe de ces choses, les gens n'ont même pas la moindre idée des types de protocoles et de services qui seront construits en utilisant ces primitives. Ou les choses étranges où il n'y a pas de ligne de démarcation claire entre service ou protocole.
Ils permettront des canaux multipartites avec un nombre de participants théoriquement illimité, qui peuvent empiler des sous-canaux sur le dessus avec des sous-groupes plus petits des participants du canal de base. Les canaux peuvent être construits au-dessus de ces « usines à canaux » qui permettent aux gens de recevoir de l’argent sans avoir les clés en ligne pour un portefeuille chaud. Ces canaux multipartites peuvent eux-mêmes être empilés sur des canaux fédérés (statechains) qui permettent aux participants d’entrer ou de sortir sans aucune activité on-chain ! Et la construction de l’épissage des canaux permettra à la liquidité de se déplacer de manière relativement transparente entre les différents canaux d’une manière qui permettra toutes sortes de choses auxquelles les gens n’ont même pas vraiment commencé à penser.
Mon dernier mot dans cette section est le suivant : cela ne prend en compte que ce qui peut être fait avec ce que je considère comme des parties directes de la pile de protocoles Bitcoin elle-même. Vous pouvez en faire beaucoup plus si vous commencez à examiner les services de garde centralisés, et quelle sous-ensemble des propriétés de Bitcoin ceux-ci peuvent fournir en ignorant les barrières réglementaires ou légales à le faire.
Il s'agit simplement de la Partie 2 sur 4, lisez la prochaine partie demain
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
La prochaine décennie, partie 2 : La route à venir
Nous commençons déjà à voir les prémices du potentiel de deuxième couche se développer à partir des primitives de la couche de base qui ont été ajoutées ou optimisées dans la première décennie. Lightning, bien qu'il soit encore soumis à de très grandes limitations, commence vraiment à prospérer. Et il s'agit là de la première version limitée actuellement spécifiée et déployée. Il y a maintenant des sidechains de divers types déployés : Liquid, RSK, et même des chaînes de jetons liées à Bitcoin développées par Commerceblock. Ce n'est que le début.
Schnorr and Taproot
Juste au-dessus de l’horizon, nous avons la combinaison de Schnorr et de Taproot. Du côté de Schnorr, il s’agit d’un schéma de signature beaucoup moins coûteux à vérifier par lots, ainsi que du prochain grand bond en avant dans l’optimisation de la construction de scripts multi-signatures dans Bitcoin. Multisig a commencé comme un simple bourrage de toutes les clés publiques et du script pour le multisig dans une sortie de transaction à envoyer, et devant inclure tout cela dans l’entrée pour le dépenser. P2SH a optimisé l’aspect de sortie, en incluant un hachage de longueur constante des clés publiques et des scripts du multisig, ce qui permet d’économiser des frais pour toute personne envoyant à une adresse multisig et de ne laisser un coût accru que pour l’expéditeur. SegWit a sans doute « optimisé » davantage en rendant les dépenses d’UTXO multisig moins chères avec la remise des témoins. Schnorr pousse toute cette optimisation incrémentale à l’extrême. Vous combinez les clés publiques individuelles en une seule clé, pour laquelle tout le monde peut collaborer pour faire une seule signature, et il suffit de le vérifier. Cela permet de réaliser des économies massives pour toutes les utilisations du multisig, y compris les couches secondaires comme Lightning et les sidechains fédérées, et crée également un avantage en matière de confidentialité en rendant tous ces UTXO multisig impossibles à distinguer des UTXO à signature unique.
Maintenant, cela ne rend pas magiquement tout complètement privé. Les états de canal Lightning (transactions) nécessitent toujours des chemins de clés séparés pour leurs transactions de pénalité afin de réagir à la soumission des anciens états. Cela signifie que ceux-ci doivent être dans les scripts de sortie, ce qui crée une empreinte digitale. Taproot résout cela avec sa cryptomagie en vous permettant de vous engager à un arbre de Merkle de différentes conditions de dépense, qui ne nécessitent que la condition utilisée et la preuve de Merkle à la racine de Merkle pour dépenser, à une clé publique Schnorr à l'aspect normal. Maintenant, vous pouvez masquer ce chemin de script de pénalité avec taproot. Vous pouvez masquer tout chemin de script conditionnel avec Taproot, enfoui sous une clé Schnorr à l'aspect parfaitement normal qui permet à tous les participants de s'accorder sur quelque chose et de réaliser une transaction à l'aspect parfaitement normal.
SIGHASH_ANYPREVOUTPUT
SIGHASH_ANYPREVOUTPUT (précédemment SIGHASH_NOINPUT) est espérons-le le prochain nouveau primitive à venir. Il s'agit d'une nouvelle format de clé publique/mise à niveau du drapeau sighash. Les drapeaux Sighash spécifient quelles parties d'une transaction une signature s'engage. Cette fonctionnalité est là pour que vous puissiez faire quelque chose comme signer simplement votre entrée et sorties, mais permettre à d'autres personnes d'ajouter leurs propres entrées et sorties à une transaction sans l'invalidation. Mais actuellement, une signature doit s'engager dans une UTXO exacte d'une transaction exacte. SIGHASH_ANYPREVOUT, entre autres, permettrait l'engagement d'une signature dans un script UTXO seulement, pas un UTXO spécifique réel. Cela permet une nouvelle manière (eltoo) de construire les états de canal Lightning qui ne nécessite pas de clé de pénalité ou de traiter avec des anciens états en permettant à la partie lésée de confisquer tout l'argent. Au lieu de cela, l'état actuel du canal pourrait simplement re-dépenser l'ancien état du canal s'il perdait la course de double dépense, garantissant que tout le monde obtient son solde de canal actuel sur la chaîne au lieu d'un solde obsolète antérieur. Vous y parvenez simplement en réutilisant le même script au bon endroit et en utilisant SIGHASH_ANYPREVOUT.
Cela élimine beaucoup de risques liés à la perte des états de canal actuels, ce qui entraîne une transaction de pénalité prenant vos fonds pour une erreur honnête. Cela permet également BEAUCOUP plus. Maintenant, nous pouvons avoir des canaux Lightning avec plus de 2 participants, et même empiler des "sous-canaux" au-dessus de ceux-ci. De plus, SIGHASH_ANYPREVOUT et eltoo permettent la création de Statechains, un type de construction de canal fédéré qui permet aux nouveaux participants d'entrer et de sortir complètement hors chaîne avec l'hypothèse de confiance selon laquelle la fédération ne colludera pas avec les anciens participants pour escroquer qui que ce soit. Cela ouvre beaucoup de potentiel pour ce que j'appelle à moi-même des "protocoles UTXO statiques multipartites."
OP_CHECKTEMPLATEVERIFY
OP_CTV est une proposition de Jeremy Rubin visant à permettre un type très basique de “pacte” sur Bitcoin. Un pacte est une restriction plus compliquée concernant la dépense d'une pièce au-delà des signatures de certaines clés. Le type de pacte que la proposition de Rubin mettrait en œuvre est un “modèle”. En gros, cela permet à un script UTXO d'exiger que des sorties exactes spécifiques soient créées par la transaction de dépense. Ainsi, une fois qu'un UTXO est créé en utilisant OP_CTV, il est imposé par consensus que l'UTXO doit être dépensé à des adresses spécifiques dans les montants spécifiques définis dans le script de cet UTXO. Vous pouvez même les chaîner ensemble de sorte que l'un de ces UTXO soit contraint d'en créer quelques-uns de plus, qui sont ensuite contraints d'en créer quelques-uns de plus, et ainsi de suite.
Cela a une énorme applicabilité générale partout. Dans les environnements à frais élevés, un seul UTXO peut être effectué par une entité dépositaire qui, 100% selon les règles de consensus, garantit que tous les fonds de ses clients se retrouveront sous le contrôle de ses clients, même s’ils n’y ont pas accès immédiatement sur le moment. Cela a beaucoup de synergie potentielle avec les canaux multipartites (channel factories), dans la mesure où un « retrait » de masse effectué de cette manière peut également créer et être utilisé simultanément comme une usine à canaux. OP_CTV peut être utilisé pour créer des canaux de paiement qui fonctionnent au moins de manière unidirectionnelle sans que le destinataire n’ait à participer ou à disposer d’une clé en ligne pour recevoir des paiements (and n’oubliez pas que vous pouvez empiler des canaux sur chaque other). Il peut même être utilisé pour permettre à un seul canal de traiter plus de HTLC à la fois en les regroupant avec la même astuce que le premier exemple avec les retraits dépositaires. Et pourrait même créer un certain potentiel pour de nouveaux types de coinjoins.
Mettre tout en œuvre
En supposant que toutes les propositions ci-dessus soient adoptées et incorporées dans Bitcoin, je pense vraiment qu'à part les développeurs travaillant réellement à la pointe de ces choses, les gens n'ont même pas la moindre idée des types de protocoles et de services qui seront construits en utilisant ces primitives. Ou les choses étranges où il n'y a pas de ligne de démarcation claire entre service ou protocole.
Ils permettront des canaux multipartites avec un nombre de participants théoriquement illimité, qui peuvent empiler des sous-canaux sur le dessus avec des sous-groupes plus petits des participants du canal de base. Les canaux peuvent être construits au-dessus de ces « usines à canaux » qui permettent aux gens de recevoir de l’argent sans avoir les clés en ligne pour un portefeuille chaud. Ces canaux multipartites peuvent eux-mêmes être empilés sur des canaux fédérés (statechains) qui permettent aux participants d’entrer ou de sortir sans aucune activité on-chain ! Et la construction de l’épissage des canaux permettra à la liquidité de se déplacer de manière relativement transparente entre les différents canaux d’une manière qui permettra toutes sortes de choses auxquelles les gens n’ont même pas vraiment commencé à penser.
Mon dernier mot dans cette section est le suivant : cela ne prend en compte que ce qui peut être fait avec ce que je considère comme des parties directes de la pile de protocoles Bitcoin elle-même. Vous pouvez en faire beaucoup plus si vous commencez à examiner les services de garde centralisés, et quelle sous-ensemble des propriétés de Bitcoin ceux-ci peuvent fournir en ignorant les barrières réglementaires ou légales à le faire.
Il s'agit simplement de la Partie 2 sur 4, lisez la prochaine partie demain