La prochaine décennie, partie 2: la route à venir

Nous commençons déjà à voir les graines de potentiel de deuxième couche se développer à partir des primitives de la couche de base qui ont été ajoutées ou optimisées au cours de la première décennie. La foudre, bien que soumise à des limites assez importantes, commence vraiment à prospérer. Et ce n’est que la première version limitée qui est actuellement spécifiée et déployée. Il y a maintenant des effectifs de divers types déployés: des chaînes liquides, RSK et même des jetons liées au bitcoin développé par CommerceBlock. Ce n’est que le début.

Schnorr et tapoot

Juste à l’horizon, nous avons la combinaison de Schnorr et Taproot. Du côté Schnorr, c’est beaucoup moins cher à vérifier le schéma de signature en lots, ainsi que le prochain grand saut dans l’optimisation de la construction de scripts multi-signatures dans Bitcoin. MultiSig a commencé comme un simple remplissage de toutes les touches publiques et du script pour le multisig dans une sortie de transaction à l’envoyer, et devoir inclure tout cela dans l’entrée pour le dépenser. P2SH a optimisé l’aspect de sortie, en incluant un hachage de longueur constant des clés publiques et des scripts du multigique, des frais d’économie pour quiconque envoie à une adresse multigique et ne laissant un coût accru que pour l’expéditeur. Segwit a sans doute «optimisé» davantage en rendant les dépenses multiples moins chères avec la remise des témoins. Schnorr prend toute cette optimisation incrémentielle à l’extrême. Vous combinez les clés publiques individuelles dans une seule clé, que tout le monde peut collaborer pour faire une seule signature, et vérifiez simplement cela. Cela crée des économies de coûts massives pour toute l’utilisation du multisig, y compris les secondes couches comme la foudre et les échecs fédérés, et crée une prestation de confidentialité également en rendant tous ces UTXOS multisigs indiscernables de celles de signature unique.

Maintenant, cela ne fait pas que tout comme par magie complètement privé. Les états (transactions) du canal Lightning nécessitent toujours des chemins clés distincts pour que leurs transactions de pénalité réagissent à la soumission des anciens États. Cela signifie que ceux-ci doivent être dans les scripts de sortie qui crée une empreinte digitale. La tapoot résout cela avec son crypto-magique vous permettant de commettre un arbre Merkle de différentes conditions de dépenses, qui ne nécessitent que la condition utilisée et la preuve de Merkle à la racine de Merkle à dépenser, à une clé publique Schnorr normale. Vous pouvez maintenant masquer ce chemin de script de pénalité avec une tapoot. Vous pouvez masquer n’importe quel chemin de script conditionnel avec une tapoot, enterré sous une clé Schnorr à l’aspect parfaitement normal qui permet à tous les participants de s’accorder sur quelque chose et de faire une transaction d’aspect parfaitement normal.

Sighash_anyprevoutput

Sighash_anyprevoutput (auparavant Sighash_Noinput) est, espérons-le, la prochaine nouvelle primitive pour descendre le pipeline. Il s’agit d’une nouvelle mise à niveau du drapeau de la clé publique / Sighash. Les drapeaux Sighash spécifient quelles parties d’une transaction à laquelle une signature s’engage. Cette fonctionnalité est là pour que vous puissiez faire quelque chose comme signer uniquement vos entrées et vos sorties, mais permettez à d’autres personnes d’ajouter leurs propres entrées et sorties à une transaction sans l’invalider. Mais actuellement, une signature doit s’engager dans un exact Utxo d’un exact transaction. Sighash_anyprevout, entre autres, permettrait Engager une signature à un seul script UTXOpas un utxo spécifique réel. Cela permet à une nouvelle façon (ELTOO) de construire des états de canaux Lightning qui ne nécessitent pas de pénalité ou de traiter avec d’anciens États en permettant à la partie trompée de confisquer tout l’argent. Au lieu de cela, l’état de canal actuel pourrait simplement dépenser l’ancien état de canal s’il perdait la race à double dépense, garantissant que tout le monde obtient son équilibre de canal actuel sur la chaîne par opposition à un équilibre préalable dépassé. Vous accomplissez cela en réutilisant simplement le même script au bon endroit et en utilisant Sighash_anyprevout.

Cela supprime de nombreux risques concernant la perte des états de canal actuels, ce qui a entraîné une transaction de pénalité prenant vos fonds pour une erreur honnête. Cela permet également beaucoup plus. Maintenant, nous pouvons avoir des canaux de foudre avec plus de 2 participants, et nous pouvons même empiler des «sous-canaux» en plus de ceux-ci. En outre, Sighash_anyprevout et Eltoo permettent la création de Statechains, un type de construction de canal fédérée qui permet aux nouveaux participants d’entrer et de quitter complètement la chaîne avec l’hypothèse de confiance que la fédération ne se terminera pas avec les participants antérieurs pour frauder qui que ce soit. Cela ouvre beaucoup de potentiel pour ce que j’ai appelé à moi-même «protocoles UTXO statiques multipartites».

OP_CHECKTEMPATEIFIE

OP_CTV est une proposition de Jeremy Rubin pour permettre un type très basique d ‘«alliance» sur Bitcoin. Une alliance est des restrictions plus compliquées pour dépenser une pièce au-delà des signatures de certaines clés. Le type de proposition de l’alliance Rubin implémenterait est un «modèle». Essentiellement, cela permet à un script UTXO de nécessiter des sorties exactes spécifiques à créer par la transaction de dépenses. Ainsi, une fois qu’un UTXO est créé à l’aide d’OP_CTV, il est appliqué par consensus que l’UTXO doit être dépensé à des adresses spécifiques dans les quantités spécifiques définies dans le script de UTXO. Vous pouvez même les enchaîner ensemble pour que l’un de ces UTXO soit obligé d’en faire quelques autres, qui sont ensuite obligés d’en faire quelques autres, encore et encore.

Cela a une énorme applicabilité générale partout. Dans des environnements à frais élevés, un seul UTXO peut être fait par une entité gardée 100% en vertu des règles de consensus Garanties Tous leurs fonds de leurs clients se termineront sous le contrôle de leurs clients, même s’ils n’en ont pas immédiatement accès dans l’instant. Cela a beaucoup de synergie potentielle avec les canaux multipartites (usines de canaux), en ce sens qu’un «retrait» de masse effectué comme celui-ci peut également créer et être utilisés simultanément comme usine de canaux. OP_CTV peut être utilisé pour créer canaux de paiement qui fonctionnent au moins de manière unidirectionnelle sans la fin de réception devoir participer ou avoir une clé en ligne pour recevoir les paiements (et rappelez-vous que vous pouvez empiler les canaux les uns sur les autres). 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 utilisations de retrait de garde. Et pourrait même créer un certain potentiel pour de nouveaux types de coinjoins.

Tout rassembler

En supposant que toutes les propositions ci-dessus sont adoptées et incorporées dans Bitcoin, je pense vraiment qu’en plus des développeurs qui travaillent réellement sur la pointe de ces choses, les gens n’ont même pas la moindre indice quels types de protocoles et de services seront construits en utilisant ces derniers primitives. Ou les choses étranges où il n’y a pas de ligne de division claire entre le service ou le protocole.

Ils permettront des canaux multipartites avec des numéros de participants non liés théoriquement, qui peuvent empiler des sous-canaux sur les sous-groupes plus petits des participants du canal de base. Les canaux peuvent être construits au-dessus de ces «usines de canaux» qui permettent aux gens de recevoir de l’argent sans avoir des clés en ligne pour un portefeuille chaud. Ces canaux multipartites peuvent eux-mêmes être empilés sur les canaux fédérés (Statechains) qui permettent aux participants d’entrer ou de sortir avec Activité zéro en chaîne! Et la construction de «l’épissage» du canal 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: cela ne considère que ce qui peut être fait avec des choses que je considère des parties directes de la pile de protocole Bitcoin elle-même. Vous pouvez faire beaucoup plus si vous commencez à regarder des services de garde centralisés et quel sous-ensemble des propriétés de Bitcoin, ceux-ci peuvent fournir des obstacles réglementaires ou juridiques à le faire.

Ce n’est que la partie 2 de 4, lisez la prochaine partie demain.