Comment les praticiens de 2010 envisagent-ils la route de construction du BTC dix ans plus tard

Auteur : Shinobi, co-fondateur de BTC Podcast Block Digest ; traduction : Wuzhu, Jinse Finance

Cet article est un article écrit par Shinobi il y a dix ans, explorant à quoi ressemblait le BTC en 2020.

Le premier article de cette série peut être consulté en cliquant sur "Comment les praticiens de 2010 envisagent-ils l'écosystème BTC dix ans plus tard ?"

Nous commençons déjà à voir les graines du potentiel de la deuxième couche se développer à partir du langage de base de la première décennie. Le réseau Lightning, bien qu'il soit encore soumis à certaines limitations assez importantes, commence en effet à s'épanouir. Il s'agit simplement de la première version limitée actuellement désignée et déployée. Divers types de sidechains ont déjà été déployés : Liquid, RSK, et même une chaîne de jetons liée au BTC développée par Commerceblock. Ce n'est qu'un début.

###SCHNORR 和 TAPROT

Peu de temps après, nous avons eu la combinaison de Schnorr et de Taproot. Du point de vue de Schnorr, il s'agit d'un schéma de vérification de signature en masse, moins coûteux, et constitue le prochain grand bond en avant dans l'optimisation de la construction de scripts de signature multi-signatures BTC. Au départ, les multi-signatures consistaient simplement à insérer toutes les clés publiques et les scripts multi-signatures dans une transaction de sortie et à devoir les inclure tous dans l'entrée pour les utiliser. P2SH optimise la sortie en incluant une valeur de hachage de longueur constante des clés publiques et des scripts multi-signatures, économisant ainsi des frais pour quiconque envoie à une adresse multi-signatures, tout en augmentant les coûts pour l'expéditeur. On peut dire que SegWit rend encore moins cher la dépense des UTXO multi-signatures grâce à une remise sur les témoins, allant plus loin dans l'optimisation. Schnorr pousse toutes ces optimisations progressives à l'extrême. Vous combinez les clés publiques en une seule clé, que chacun peut collaborer à signer, puis vérifier. Cela permet d'économiser des coûts importants pour toutes les technologies utilisant des multi-signatures (y compris les réseaux Lightning et les sidechains comme (Lightning) et d'autres de deuxième couche), et en rendant tous ces UTXO multi-signatures indiscernables des UTXO à signature unique, apporte également des avantages en termes de confidentialité.

Maintenant, cela ne rend pas tout magiquement secret. Les états (transactions) des canaux Lightning nécessitent toujours des chemins de clés distincts pour réagir aux transactions de pénalité soumises à l'ancien état. Cela signifie qu'ils doivent être inclus dans les scripts de sortie qui créent les empreintes digitales. Taproot résout ce problème avec sa magie cryptographique, permettant de soumettre un arbre de Merkle avec des conditions de dépenses différentes, et il suffit d'utiliser les conditions et les preuves de Merkle jusqu'à la racine de Merkle pour dépenser, jusqu'à une clé publique Schnorr qui semble normale. Maintenant, vous pouvez masquer ce chemin de script de pénalité avec Taproot. Vous pouvez masquer n'importe quel chemin de script conditionnel avec Taproot sous une clé Schnorr qui semble tout à fait normale, cette clé permettant à tous les participants de parvenir à un consensus sur quelque chose et de réaliser des transactions qui semblent tout à fait normales.

###SIGHASH_ANYPREVOUTPUT

SIGHASH_ANYPREVOUTPUT (formerly SIGHASH_NOINPUT) is expected to become the next new primitive. It is a new public key format/sighash flag upgrade. The Sighash flag specifies which parts of the transaction the signature will commit to. The existence of this feature is to allow you to perform operations such as signing only your inputs and outputs, but allowing others to add their inputs and outputs to the transaction without invalidating it. However, currently, the signature must be committed to the exact UTXO from the exact transaction. Among other things, SIGHASH_ANYPREVOUT can submit the signature to the UTXO script, rather than to the actual specific UTXO. This allows a new way (eltoo) to build lightning channel states without the need for penalty keys or dealing with old states, allowing the deceived party to confiscate all funds. Instead, if the current channel state fails in a double-spending race, it can simply reuse the old channel state, ensuring that everyone can get their current channel balance on-chain, rather than the expired balance. You can achieve this by simply reusing the same script in the right place and using SIGHASH_ANYPREVOUT.

Cela élimine de nombreux risques, tels que la perte de l'état de canal actuel, ce qui entraîne la rétention des transactions de pénalité pour saisir vos fonds par inadvertance. Il peut également permettre davantage de fonctionnalités. Maintenant, nous pouvons avoir plus de 2 participants dans un canal Lightning et même empiler des "sous-canaux" sur ces canaux. De plus, SIGHASH_ANYPREVOUT et eltoo peuvent créer des Statechains, qui sont une construction de canal conjointe permettant aux nouveaux participants d'entrer et de sortir complètement hors chaîne, tout en supposant que l'alliance ne complotera pas avec les anciens participants pour tromper qui que ce soit. Cela ouvre beaucoup de potentiel pour ce que j'ai toujours appelé le protocole "multiparty static UTXO".

###OP_CHECKTEMPLATEVERIFY

OP_CTV est une proposition de Jeremy Rubin visant à mettre en œuvre un “contrat” très fondamental sur BTC. Le contrat représente des restrictions plus complexes sur l'utilisation d'un BTC, au-delà de simples signatures de clés. Le type de contrat que propose Rubin est un “modele”. En substance, cela permet à un script UTXO d'exiger que la transaction de dépense crée des sorties précises spécifiques. Ainsi, une fois qu'un UTXO a été créé avec OP_CTV, il est exécuté de manière coercitive par consensus pour dépenser l'UTXO vers une adresse spécifique, avec un montant défini dans le script de cet UTXO. Vous pouvez même les chaîner ensemble, de sorte qu'un UTXO soit contraint de générer plusieurs autres, qui sont à leur tour contraints d'en générer d'autres, et ainsi de suite.

Cela a une large applicabilité universelle partout. Dans un environnement où les frais sont élevés, une entité dépositaire peut créer un UTXO unique, qui garantit 100 % des fonds de ses clients, conformément aux règles consensuelles, selon lesquelles tous les fonds de ses clients seront en fin de compte contrôlés par le client, même s’il n’a pas actuellement un accès immédiat à ces fonds. Cela présente de grandes synergies potentielles avec le multicanal (channel factory), car des « retraits » à grande échelle comme celui-ci peuvent également être créés et utilisés en même temps comme channel factory. OP_CTV peut être utilisé pour créer des canaux de paiement qui fonctionnent dans au moins une direction, sans qu’il soit nécessaire d’impliquer le destinataire ou d’avoir une clé en ligne pour recevoir des paiements (rappelez-vous, vous pouvez empiler les canaux les uns sur les autres). Il peut même être utilisé pour permettre à un seul canal de traiter plusieurs HTLC à la fois en les regroupant, en utilisant les mêmes astuces que le premier exemple de retrait hébergé. Cela pourrait même créer un potentiel pour un nouveau type de coinjoin.

###Intégrer tous les éléments

Supposons que toutes les propositions susmentionnées soient adoptées et intégrées dans Bitcoin, je crois vraiment que, mis à part les développeurs qui travaillent réellement sur ces travaux de pointe, les gens ne savent même pas quels types de protocoles et de services seront construits en utilisant ces primitives. Ou des choses étranges où il n'y a pas de frontières claires entre les services ou les protocoles.

Ils permettront de créer des canaux multipartites théoriquement illimités en nombre de participants, qui peuvent être empilés au-dessus de sous-canaux plus petits des participants du canal de base. Des canaux peuvent être construits au-dessus de ces "usines de canaux", permettant aux gens de recevoir des paiements sans avoir besoin de clés de portefeuille chaud en ligne. Ces canaux multipartites peuvent eux-mêmes être empilés sur des canaux conjoints (chaînes d'état), permettant aux participants d'entrer ou de sortir d'une activité sur chaîne avec zéro frais ! La construction de canaux "interconnectés" permettra une mobilité relativement transparente de la liquidité entre les différents canaux, permettant la réalisation de diverses possibilités même avant que les gens n'aient vraiment commencé à les considérer.

Ma dernière phrase dans cette section est : il s'agit simplement de réfléchir à ce que l'on peut faire avec ce que je considère comme faisant directement partie de la pile de protocoles BTC. Si vous commencez à étudier les services de garde centralisés, ainsi que les sous-ensembles de BTC que ces services peuvent offrir, sans être affectés par la réglementation ou les obstacles juridiques, alors vous pouvez faire beaucoup plus.