Covenants Bitcoin : CheckTempPeolify (BIP 119)

Le premier article est profondément plongé dans les propositions individuelles de l’alliance qui ont atteint un point de maturité méritant une ventilation approfondie.

Vérifier (CTV), mis en avant par Jeremy Rubin avec BIP 119, est la proposition d’alliance la plus mature et entièrement étoffée, non seulement parmi les propositions que nous couvrirons, mais sur toutes les propositions d’alliance dans leur intégralité. Comme je l’ai mentionné dans l’article d’introduction à cette série, il y a de nombreuses préoccupations dans l’écosystème concernant les alliances qui sont trop flexibles, ce qui permet de finir par avoir des conséquences très préjudiciables pour Bitcoin.

CTV a été conçu spécifiquement pour contraindre ses capacités suffisamment étroitement pour éviter l’une de ces préoccupations. Pour comprendre d’abord comment fonctionne CTV, nous devons comprendre les parties individuelles d’une transaction Bitcoin.

Il s’agit d’une vue de niveau très élevé d’une transaction Bitcoin. Il a des entrées ou des pièces non dépensées (€), et les sorties, les nouvelles pièces non dépensées que la transaction créera lorsqu’elle sera confirmée dans un bloc. Il y a beaucoup plus de pièces que nous allons traverser, mais c’est la vue de plus haut niveau de la structure d’une transaction.

Chaque transaction a également un champ de numéro de version pour l’ensemble de la transaction, indiquant l’applicabilité de nouvelles versions de règles ou de fonctionnalités. Il y a aussi le marqueur et l’indicateur, qui sont définis sur des valeurs spécifiques pour indiquer que la transaction utilise segwit. Après le nombre d’entrées, le nombre d’entrées dans la transaction. Viennent ensuite les entrées réelles.

Chaque entrée contient un TXID de la transaction qui a créé la pièce non dépensée dépensée, un Vout qui marque la sortie de cette transaction dépensée, la taille du scriptsig, et le scriptsig, qui est le script de déverrouillage prouvant que l’entrée dépensée est autorisée par ses règles de script de verrouillage, et enfin un numéro de séquence qui est utilisé pour assurer que l’entrée est dépensée est de suivre les règles de timelocks relatives. c’est-à-dire que l’entrée a existé pour un certain nombre de blocs ou de durée depuis sa création.

Le nombre de sorties est le prochain élément de données, le nombre de sorties dans la transaction. Après cela, les sorties réelles contiennent une quantité de satoshis attribuée à cette sortie, la taille ScriptPubKey et le scriptpubkey réel, qui est le script de verrouillage pour cette sortie. Enfin, le champ Nlocktime applique une valeur TimeLock dans l’horodatage ou la hauteur de blocs qui s’applique à l’ensemble de la transaction.

Chaque transaction SEGWIT contient également une section de témoin, où chaque entrée a un témoin correspondant contenant un nombre d’éléments de pile, le nombre de choses qui seront placées sur la pile de script, un champ de taille pour chaque élément et l’élément de données réel pour aller sur la pile.

Comment fonctionne CTV

CTV est un opcode qui permet la forme la plus élémentaire d’introspection et de données directes effectuant toutes les propositions d’alliance. Il permet à un script de prendre un hachage prédéfini de 32 octets et de comparer cela avec un hachage de la plupart des champs de la transaction de dépenses. Si le hachage dérivé de la transaction de dépenses réelle ne correspond pas au hachage prédéfini, la transaction n’est pas valide.

Les champs auxquels il s’engage sont:

• nursion
• nlocktime
• Comptage des entrées
• Un hachage de tous les champs de la séquence
• Nombre de sorties
• Un hachage de toutes les sorties
• Index d’entrée (le lieu de l’entrée dans la transaction, la 1ère entrée, 2e, etc.)

Ce sont tous les champs engagés par le hachage CTV, dans leur intégralité, et sans capacité à choisir. Il s’agit du degré d’introspection que CTV permet: «Le hachage de ces champs dans la transaction de dépenses correspond-il au hachage dans le script de verrouillage de l’entrée dépensée», c’est tout. Le hachage s’engage essentiellement à l’ensemble de la transaction, à l’exception des entrées réelles. Il y a une raison pour laquelle le hachage n’inclut pas les entrées. Afin de verrouiller une sortie sur un hachage de 32 octets avec CTV, vous devez connaître le hachage de la transaction que vous assurez est le seul moyen de dépensier. L’entrée verrouillée avec CTV dépensée devra inclure ce hachage afin d’être vérifié contre CTV. Cela nécessite d’avoir le hachage de cette transaction avant vous créez la transaction complète. Ce n’est pas possible.

Vous pouvez également nidiquer les scripts CTV, c’est-à-dire que le script CTV initial engage une transaction avec des sorties qui incluent également les scripts CTV. C’est ce qui permet à CTV de «transporter» les données. Tout ce qu’il fait avancer dans la pratique, ce sont les données contenues dans la chaîne de transactions. Vous pouvez le faire en théorie à une profondeur infinie, mais vous êtes limité en pratique à une profondeur finie car la nidification doit être générée à l’arrière à partir de la fin. En effet, chaque niveau, ou «hop», doit avoir le hachage de la transaction passant à la suivante, sinon vous ne pouvez pas créer le script de verrouillage en premier lieu. Si vous ne connaissez pas déjà la prochaine transaction, vous ne pouvez pas générer la précédente.

Qu’est-ce que CTV est utile pour

CTV vous permet de restreindre une sortie afin qu’elle ne puisse être dépensée, selon les règles du consensus, par une transaction prédéfinie exacte. Certains d’entre vous pourraient demander quel est le problème, nous pouvons déjà pré-séparer les transactions. Si le niveau d’introspection est si limité qu’il ne peut accomplir que quelque chose que nous pouvons déjà faire juste une pré-signature, quelle est la valeur ajoutée?

Premièrement, les transactions pré-signées laissent toujours ouverte la possibilité que le ou les détenteurs de clés de signature de nouvelles transactions et de dépenser ces pièces de monnaie d’une manière différente. Vous devez croire que le porte-clé ne le fera pas, ou supprimera la clé nécessaire pour signer (sur laquelle vous devez également leur faire confiance). CTV supprime entièrement cette confiance. Une fois la transaction de dépenses définie et la sortie verrouillée sur ce hachage CTV créé, il n’y a aucune possibilité d’être dépensé d’une autre manière, appliquée par un consensus.

Actuellement, le seul moyen de contourner cette confiance est d’être impliqué dans des transactions pré-signalées vous-même en utilisant Multisig. Ensuite, vous pouvez être tout à fait certain qu’à moins que vous ne choisissiez d’en signer vous-même, aucune autre transaction valide, dépensant une pièce d’une manière différente ne peut être créée. Le problème est que plus les personnes sont impliquées, plus la coordination de chacun est difficile et peu fiable pour pré-signaler une transaction en même temps. Passées de petites tailles, il devient un problème totalement impraticable pour résoudre de manière fiable.

CTV donne un moyen aux gens de savoir qu’un ensemble de transactions est engagé sans que tout le monde ne se connecte en même temps pour les signer. Cela simplifie considérablement le processus de coordination en permettant à chacun d’obtenir les informations nécessaires à quelqu’un d’autre chaque fois qu’il le peut, et une fois que cette personne a les informations de tout le monde, il peut créer la chaîne de transactions CTV sans l’implication de quelqu’un d’autre, et tout le monde peut vérifier et être certain que le résultat correct est le seul possible.

C’est incroyablement précieux en soi, mais CTV peut également permettre des choses encore plus précieuses en combinaison avec d’autres opcodes, que nous verrons dans le prochain article.

Réflexions de clôture

CTV est une alliance étroitement restreinte qui permet un degré d’introspection et de données de données à terme qui sont si limitées qu’elle ne dépasse pas la fonctionnalité réelle de tout ce qui peut être effectué avec les transactions pré-signées. La proposition de valeur ne consiste pas à permettre de nouvelles fonctionnalités à part entière, mais à améliorer considérablement l’efficacité, l’évolutivité et les garanties de sécurité de ce qui peut être construit actuellement à l’aide de transactions pré-signées. Cela seul est un avantage massif pour presque tous les protocoles actuellement déployés à l’aide de transactions pré-signées.

Voici quelques-uns des projets démontrant à quel point le rythme est étoffé et exploré cette alliance particulière est comparée aux autres:

• Un pool de paiement de base exemple par bégayer.
• Un coffre-fort CTV mise en Å“uvre par James O’Beirne qui a ensuite proposé OP_VAULT (qui utilise toujours CTV).
• Un port de preuve de concept de l’implémentation ARK basée sur les transactions pré-signatée à partir de Steven Roose pour utiliser CTV à la place.
• Le Langue sapio par Jeremy Rubin lui-même, un langage de niveau supérieur pour la création de contrats avec CTV (soutenant également l’utilisation de transactions pré-signées à la place).
• Timeout Trees, une proposition pour une conception de Coinpool très basique par John Law.
• De nombreux autres protocoles possibles tels que les contrats de journal discret optimisé (DLC), les canaux de foudre non interactifs qu’une partie pourrait ouvrir sans l’autre, et même des moyens décentralisés pour les mineurs de se mettre ensemble.

CTV est une proposition incroyablement mature à ce stade, avec un ajout de grande valeur, et aucun risque de permettre à quelque chose qui stimule les préoccupations concernant les alliances. Cela devrait non seulement être très sérieusement considéré, mais à mon avis personnel aurait dû être activé il y a des années.