À partir de la programmation d'applications Bitcoin, dix mille mots expliquent en détail la programmabilité de CKB

Le contenu suivant est reproduit du forum Nervos Talk, écrit par Ajian (rédacteur en chef de la plateforme de contenu Bitcoin BTC Study).

Résumé

Comprendre la programmabilité d'un système nous oblige à identifier les caractéristiques structurelles du système. L'exploration de la programmation d'applications basée sur le script Bitcoin nous aide à comprendre la structure de base de CKB Cell et son paradigme de programmation. Non seulement cela, mais il décompose les éléments de programmation de CKB en parties appropriées et nous aide à comprendre les gains de programmabilité apportés par chaque partie.

1. Introduction

La « programmabilité » est une dimension que les gens prennent souvent lorsqu'ils comparent les systèmes blockchain. Cependant, des désaccords sont fréquents sur la façon dont la programmabilité est décrite. Une expression courante est « XX blockchain prend en charge le langage de programmation Turing-complete » ou « XX blockchain prend en charge la programmation générale », ce qui signifie que « XX blockchain » a ici une puissante programmabilité. Il y a une part de vérité dans l'implication de ces déclarations : les systèmes qui prennent en charge la programmation complète de Turing sont généralement plus faciles à programmer que les systèmes qui ne le font pas. Cependant, les caractéristiques structurelles des systèmes de contrats intelligents comportent de nombreux aspects, et cette déclaration n'en aborde qu'un. Par conséquent, il ne suffit pas d'acquérir une compréhension suffisamment approfondie : les développeurs ne peuvent pas en tirer des conseils et les utilisateurs ordinaires ne peuvent pas faire la distinction. il à partir de là.

Les caractéristiques structurelles du système de contrat intelligent comprennent :

• La forme de base de l'expression d'état (contrat) (compte ou sortie de transaction)
• L'autorisation de programmer des calculs arbitraires (le terme "Turing complet" concerne cela aspect )
• Le processus d'exécution peut-il créer de nouvelles données, ou transmet-il simplement des valeurs booléennes ? (Calcul vs. Vérification)
• S'il est permis d'enregistrer des états supplémentaires dans le contrat
• Si un contrat peut accéder à l'état d'un autre contrat pendant l'exécution

Donc, en plus de "si des calculs arbitraires peuvent être programmés", au moins il y a quatre caractéristiques qui affectent la programmabilité d'un système de contrat intelligent. On peut même dire que ces autres caractéristiques sont plus importantes, car elles déterminent à un niveau plus profond ce qui est facile à mettre en œuvre et ce qui est difficile à mettre en œuvre ;

Par exemple, les gens prennent souvent Ethereum comme exemple de bonne programmabilité. Cependant, la forme de base d'expression d'état dans Ethereum est un compte, et il est difficile de programmer des contrats peer-to-peer (par exemple, des canaux de paiement, un). (contrats de paris un à un) ——Ce n'est pas absolument impossible à réaliser, c'est juste ingrat. Ce n’est pas que l’écosystème Ethereum n’ait jamais eu de projets visant à mettre en œuvre des canaux de paiement/canaux de statut. Il existe également de nombreuses discussions théoriques, mais ces projets semblent inactifs aujourd’hui – cela ne peut évidemment pas être attribué au manque d’efforts des développeurs. Ce n’est pas un hasard si les projets actifs aujourd’hui sur Ethereum prennent tous la forme de « pools de fonds » plutôt que de « contrats point à point ». De même, les gens peuvent être très satisfaits de la programmabilité d’Ethereum, mais lorsqu’il s’agit de réaliser « l’abstraction de compte » (qui peut également être comprise comme une généralisation du concept de portefeuille), le modèle de compte est intrinsèquement déficient.

De même, explorer la programmabilité de CKB nous oblige également à comprendre les caractéristiques structurelles du système de contrat intelligent CKB dans ces aspects. Ce que nous savons déjà, c'est que CKB permet la programmation de calculs arbitraires, permet l'enregistrement d'états supplémentaires dans les contrats et permet à un contrat d'accéder à l'état d'un autre contrat pendant l'exécution. Cependant, la forme de son contrat est le résultat de la transaction (appelé « Cellule »), ce qui le rend fondamentalement différent d’Ethereum. Par conséquent, comprendre le système de contrat intelligent Ethereum et les instances de contrat qu’il contient ne nous aide pas à comprendre comment CKB implémente ces fonctionnalités structurelles, ni à comprendre la programmabilité de CKB.

Heureusement, les contrats intelligents sur Bitcoin semblent nous fournir la meilleure base pour comprendre la programmabilité de CKB. Ce n'est pas seulement parce que la forme de base de l'expression d'état de Bitcoin est également le résultat d'une transaction (appelée « UTXO »), mais aussi parce qu'à l'aide d'un concept de « covenants » proposé par la communauté Bitcoin, nous pouvons comprendre que CKB possède les caractéristiques structurelles ci-dessus et le gain de programmabilité apporté en divisant de manière appropriée l'effet final en plusieurs parties et en les identifiant une par une.

2. CKB contre BTC : quoi de plus ?

Structure de base

En tant que forme de base de l'expression de l'état Bitcoin, l'UTXO (« Unspent Transaction Output ») de Bitcoin comporte deux champs :

• Amount, en Satoshi (Satoshi), indique que l'UTXO a la valeur de Bitcoin ;
La clé publique du script, également connue sous le nom de script de verrouillage, représente les conditions qui doivent être remplies pour dépenser les fonds, c'est-à-dire le programme de contrat intelligent qui fixe les conditions de déblocage des fonds.

Comparés aux systèmes de contrats intelligents apparus plus tard, les scripts Bitcoin sont assez limités :

• Il ne permet pas la programmation de calculs arbitraires ; seuls quelques calculs pratiques peuvent être utilisés pour la vérification (vérification de signature, vérification de pré-image de hachage, vérification de l'heure)
• Il ne permet pas l'enregistrement d'états supplémentaires dans le contrat ; par exemple, il n'est pas possible d'utiliser un script pour limiter la proportion/montant d'une seule dépense ; il est également impossible d'y cacher un jeton)
• Il ne permet pas non plus d'accéder à l'état d'un autre contrat pendant l'exécution. (chaque script est un univers indépendant, et les uns les autres ne peuvent pas dépendre).

Bien que ce type de script soit limité, il ne manque pas de capacité à programmer des applications étonnantes, et c'est également la base pour nous d'explorer la programmabilité de CKB. Il y aura une section spéciale plus tard pour présenter deux exemples de programmation de scripts Bitcoin.

En revanche, l'unité d'état de CKB est appelée « Cellule » et comporte quatre champs :

• Capacité, qui est similaire à la quantité d'UTXO et exprime la taille de l'espace que la cellule peut occuper, en unité d'octets ;
• Lock Script, une clé publique de script similaire à UTXO, définit la propriété de la cellule uniquement lorsque les données fournies peuvent transmettre le script de verrouillage, la cellule peut être "mise à jour" (on peut également dire qu'elle libère la cellule et l'utilise). ces capacités de diffusion d'une nouvelle cellule) ;
• Données, données, toutes données, leur volume est limité par la capacité ;
• Type Script, script facultatif, utilisé pour définir les conditions de mise à jour des données.

De plus, Lock Script et Type Script peuvent également programmer des calculs arbitraires. Vous pouvez programmer n'importe quel algorithme de vérification de signature, vous pouvez également programmer n'importe quelle vérification de pré-image pour n'importe quel algorithme de hachage, et ainsi de suite.

Les lecteurs peuvent facilement constater l'amélioration de la programmabilité de Cell par rapport à UTXO :

• Cell peut programmer n'importe quel calcul, au lieu de programmer uniquement certains calculs ; sa vérification de propriété sera plus flexible ;
• Grâce aux champs Data et Type Script ; , la cellule peut enregistrer un statut supplémentaire ; cela lui permet de transporter ce que l'on appelle "UDT (User-Defined Token)".

Combinés à la propre structure de « sortie de transaction » de Cell, les avantages que ces deux points peuvent apporter sont déjà très, très énormes. Cependant, à partir de la seule description ci-dessus, nous ne savons toujours pas comment Cell implémente « l'accès à l'exécution d'un contrat ». "le statut d'un autre contrat". Pour ce faire, il faut se tourner vers un concept dont la communauté Bitcoin discute depuis longtemps : les « covenants ».

Restrictions et introspection

L'intention initiale des restrictions est de limiter où une somme d'argent peut être dépensée. Sur le Bitcoin actuel (qui n'a pas encore déployé de propositions de contraintes), une fois qu'un fonds est débloqué, il peut être dépensé n'importe où (payable sur n'importe quelle clé publique de script). Mais l'idée de la clause de restriction est qu'elle peut être limitée d'une manière ou d'une autre pour être dépensée uniquement à certains endroits. Par exemple, un certain UTXO ne peut être dépensé que par une certaine transaction, même si quelqu'un peut fournir une signature. pour cet UTXO, ce pour quoi il peut être dépensé a également été déterminé par l'accord. Cette fonction peut paraître un peu étrange, mais elle peut produire des applications intéressantes, qui seront présentées plus tard dans une section dédiée. Il est important de noter que c’est la clé de notre meilleure compréhension de la programmabilité de CKB.

Rusty Russell a souligné à juste titre que la clause de restriction peut être comprise comme la capacité « d'introspection » de la transaction, c'est-à-dire que lorsqu'un UTXO A est dépensé par une transaction B, l'opérateur de script peut lire une partie (ou la totalité) du transaction B , puis vérifiez s'ils sont cohérents avec les paramètres pré-requis par le script. Par exemple, si la clé publique de script de la première sortie de la transaction A est cohérente avec la clé publique de script de l'UTXO A (c'est le sens original de la clause de restriction).

Les lecteurs fidèles se rendront compte que si vous disposez de capacités d'introspection complètes, alors l'entrée d'une transaction peut lire l'état d'une autre entrée de la même transaction, ce qui réalise ce que nous avons dit plus tôt "un contrat est en cours d'exécution au moment de l'exécution". La possibilité d'accéder l'état d'un autre contrat. En fait, CKB Cell est conçu exactement de cette façon.

Sur cette base, nous pouvons diviser cette capacité d'introspection complète en quatre situations :

• Lock Script lit d'autres (entrée et sortie) Lock Script
• Lock Script lit d'autres (entrée et sortie) Type Script (et données)
• Type Script lit d'autres (entrée et sortie) Lock Script
• Type Script lit d'autres (entrée et sortie) Type Script (et données)

Cela nous permet de sous l'hypothèse (la division fonctionnelle de Lock Script et Type Script), nous analysons le rôle de la capacité d'introspection de chaque pièce dans différents scénarios d'application, c'est-à-dire analysons les gains de programmabilité que chaque pièce nous apporte.

Dans les deux chapitres suivants, nous examinerons la programmation de script Bitcoin actuelle (pas encore de proposition de clause contrainte) et la fonctionnalité que la proposition de clause contrainte devrait implémenter, pour comprendre spécifiquement comment CKB Cell peut être programmé pour faire mieux.

3. Programmation de script Bitcoin

Cette section utilisera « Lightning Channel/Lightning Network » et « Discreet Log Contract (DLC) » comme exemples de programmation d'application basée sur Bitcoin Script. Avant de continuer, nous devons comprendre deux concepts.

OP_IF et "Commitment Transaction"

Le premier concept est l'opcode de contrôle de processus dans le script Bitcoin, tel que : OP_IF, OP_ELSE. Ces opcodes ne sont pas différents des IF en programmation informatique. Leur fonction est d'exécuter différentes instructions basées sur différentes entrées. Dans le contexte des scripts Bitcoin, cela signifie que nous pouvons configurer plusieurs chemins de déverrouillage des fonds, associés à la fonction timelock, cela signifie que nous pouvons attribuer une priorité aux actions.

Prenons l'exemple du fameux "Hash Time Lock Contract (HTLC)". Ce script est traduit dans la langue vernaculaire par :

Ou, Bob peut révéler l'image originale derrière une certaine valeur de hachage H, puis donner son propre signe. pour dépenser les fonds

Alternativement, Alice peut dépenser les fonds avec sa signature après une période de temps T.

Cet effet "soit... soit..." est obtenu grâce aux opcodes de contrôle de processus.

L'avantage le plus important de HTLC est qu'il peut regrouper plusieurs opérations ensemble et atteindre l'atomicité. Par exemple, si Alice souhaite échanger BTC contre CKB avec Bob, Bob peut d'abord donner une valeur de hachage et créer un HTLC sur le réseau Nervos, puis Alice crée un HTLC sur Bitcoin en utilisant la même valeur de hachage ; Alternativement, Bob prend le BTC payé par Alice sur Bitcoin et révèle également l'image originale, permettant à Alice de prendre CKB sur le réseau Nervos. Ou, si Bob ne révèle pas l'image originale, les deux contrats expireront et Alice et Bob pourront récupérer les fonds qu'ils ont investis.

Après l'activation du soft fork Taproot, cette fonctionnalité de plusieurs chemins de déverrouillage a été encore renforcée par l'introduction du MAST (Merkle Abstract Syntax Tree) : on peut transformer un chemin de déverrouillage en chemin de déverrouillage sur l'arbre Merkle Chaque feuille est indépendante , il n'est donc pas nécessaire d'utiliser de tels opcodes de contrôle de flux ; et, comme la révélation d'un chemin ne nécessite pas d'exposer d'autres chemins, nous pouvons ajouter un plus grand nombre de chemins déverrouillés à une sortie sans nous soucier des problèmes économiques.

Le deuxième concept est « transaction d'engagement ». L'idée d'une transaction validée est que, dans certaines circonstances, une transaction Bitcoin valide est toujours vraie et contraignante même si elle n'est pas confirmée par la blockchain.

Par exemple, Alice et Bob possèdent conjointement un UTXO, et cet UTXO nécessite que leurs deux signatures soient dépensées. À ce stade, Alice construit une transaction pour la dépenser, transférant 60 % de la valeur à Bob et la valeur restante à elle-même ; Alice fournit sa propre signature pour la transaction et l'envoie à Bob. Ensuite, pour Bob, il n’est pas nécessaire de diffuser la transaction sur le réseau Bitcoin ni de la faire confirmer par la blockchain. L’effet de paiement de la transaction est également réel et crédible. Parce qu'Alice ne peut pas dépenser cet UTXO seule (et donc ne peut pas le dépenser à nouveau), et parce que la signature fournie par Alice est valide, Bob peut ajouter sa propre signature à tout moment puis diffuser la transaction, encaissant ainsi le paiement. En d'autres termes, Alice fournit à Bob un « engagement crédible » grâce à cette transaction valide (non en chaîne).

Les transactions d'engagement sont le concept central de la programmation d'applications Bitcoin. Comme mentionné précédemment, les contrats de Bitcoin sont basés sur la vérification, sans état et ne permettent pas d'accès croisé. Toutefois, si le contrat ne comporte pas d'état, où ces états sont-ils stockés et comment le contrat peut-il être avancé en toute sécurité (changement d'état) ? Les transactions d'engagement donnent une réponse simple : l'état du contrat peut être exprimé sous forme de transactions, de sorte que les participants au contrat peuvent sauvegarder eux-mêmes les états sans avoir à les montrer sur la blockchain. Le problème des changements d'état du contrat peut également être transformé en ; le problème de la mise à jour en toute sécurité des transactions engagées ; de plus, si nous nous inquiétons du danger de conclure un contrat (par exemple, conclure un contrat qui exige que les deux parties signent avant de dépenser, nous courrons le risque que l'autre partie ne répondre et rester bloqué), puis, le simple fait de générer et de signer des transactions d'engagement qui passent le contrat à l'avance élimine les risques et élimine la confiance dans les autres participants.

Lightning Channel et Lightning Network

Lightning Channel est un contrat individuel dans lequel deux parties peuvent se payer un nombre illimité de fois sans qu'aucun paiement ne soit confirmé par la blockchain. Comme vous vous en doutez, il utilise des transactions de promesse.

Dans la section expliquant les « Transactions d'engagement », nous avons introduit un canal de paiement. Cependant, ce contrat, qui n'utilise que 2 signatures multiples sur 2, ne permet que des paiements unidirectionnels. Autrement dit, soit Alice paie toujours Bob, soit Bob paie Alice jusqu'à ce que son solde dans le contrat soit épuisé. S'il s'agit d'un paiement bidirectionnel, cela signifie qu'après une certaine mise à jour du statut, le solde d'une partie peut devenir inférieur à celui d'avant, mais la dernière transaction engagée a été signée par l'autre partie. Existe-t-il un moyen de l'arrêter ? diffuser l'ancienne transaction d'engagement pour que TA ne puisse diffuser que la dernière transaction d'engagement ?

La solution de Lightning Channel à ce problème s’appelle « LN-Penalty ». Supposons maintenant qu'Alice et Bob aient chacun 5 BTC dans un canal ; maintenant Alice veut payer 1 BTC à Bob, elle signe donc une transaction d'engagement comme celle-ci et l'envoie à Bob :

Entrez #0, 10 BTC : Alie-Bob Sortie multi-signature 2 sur 2 (c'est-à-dire contrat de canal)

Sortie n°0, 4 BTC : signature unique Alice

Sortie n°1, 6 BTC : Soit la clé publique temporaire conjointe Alice-Bob n°1 signature unique ou le time lock T1, signature unique Bob

Bob signe également une transaction d'engagement (correspondant à la transaction ci-dessus) et l'envoie à Alice :

Entrée n°0, 10 BTC : sortie multi-signature Alie-Bob 2 sur 2 (c'est-à-dire contrat de canal)

Sortie n°0, 6 BTC : signature unique de Bob

Sortie n°1, 4 BTC : ou Bob -Alice clé publique temporaire commune #1 signature unique ou verrouillage temporel T1, signature unique Alice

L'astuce réside ici dans cette "clé publique temporaire commune", qui est générée à l'aide d'une clé publique de l'un et d'une clé publique fournie par l'autre partie Par exemple, la clé publique temporaire commune Alice-Bob est obtenue en utilisant l'une des propres clés publiques d'Alice et une clé publique fournie par Bob, en multipliant chacune par une valeur de hachage, puis en les additionnant. Lorsqu’une telle clé publique est générée, personne ne connaît sa clé privée. Cependant, si Bob indique à Alice la clé privée de la clé publique qu'il a fournie, Alice peut calculer la clé privée de la clé publique temporaire commune. ——C'est la clé de la manière dont Lightning Channel peut « annuler » l'ancien état.

La prochaine fois que les deux parties souhaiteront mettre à jour le statut de la chaîne (initier le paiement), les deux parties échangeront la clé privée de la clé publique temporaire donnée à l'autre partie lors du tour précédent. De cette façon, les participants n'osent plus diffuser la dernière transaction d'engagement qu'ils ont reçue : le résultat de cette transaction d'engagement s'attribue de la valeur a deux chemins, et la clé privée du chemin de clé publique temporaire est déjà connue de l'autre partie ; Une fois l'ancienne transaction d'engagement diffusée, l'autre partie peut immédiatement utiliser cette clé privée temporaire commune pour retirer tous les fonds de cette sortie. – C’est ce que signifie « LN-Penalty ».

Plus précisément, la séquence d'interaction est la suivante : la partie qui initie le paiement demande d'abord une nouvelle clé publique temporaire à l'autre partie, puis construit une nouvelle transaction validée et la remet à l'autre partie qui obtient la transaction validée ; lui-même à l'autre partie. Autour de la clé privée étant donné la clé publique temporaire. Cette séquence d'interaction garantit que les participants obtiennent toujours en premier les nouvelles transactions d'engagement, puis invalident les transactions d'engagement qu'ils ont obtenues lors du cycle précédent, ce qui est donc sans confiance.

En résumé, les principales conceptions du canal Lightning sont :

Les deux parties utilisent toujours des transactions d'engagement pour exprimer le statut interne du contrat, et utilisent les changements de montants pour représenter les paiements ;

Les transactions d'engagement coûtent toujours le même prix d'entrée ; les deux parties doivent le faire en même temps (Fournir une entrée signée), de sorte que toutes les transactions d'engagement se font concurrence, et une seule peut finalement être confirmée par la blockchain

Les signatures des deux participants ne sont pas la même transaction d'engagement ( bien qu'ils soient appariés) ; Et les transactions qu'ils signent sont toujours plus bénéfiques pour eux-mêmes. Autrement dit, les transactions engagées reçues par les participants sont toujours préjudiciables à eux-mêmes

Ce désavantage se reflète dans le résultat qui s'attribue de la valeur à lui-même. chemins de déverrouillage : un chemin peut être déverrouillé avec votre propre signature, mais vous devez attendre un moment ; tandis que l'autre chemin utilise la clé publique de l'autre partie et n'est protégé que si l'une de vos propres clés privées temporaires n'est pas exposée

 ; À chaque paiement, les deux parties échangent une nouvelle transaction d'engagement contre la clé privée temporaire utilisée par l'autre partie lors du tour précédent. Par conséquent, la partie qui a remis la clé privée temporaire n'ose plus diffuser l'ancienne transaction d'engagement. , la dernière transaction validée est « annulée » et le statut du contrat est mis à jour (En fait, ces transactions validées sont toutes des transactions valides et peuvent être diffusées sur la blockchain, mais les participants sont obligés de les punir. Osez diffuser à nouveau)

L'une ou l'autre partie peut résilier le contrat à tout moment avec la transaction promise signée par l'autre partie ; cependant, si les deux parties sont disposées à coopérer, elles peuvent signer une nouvelle transaction afin que les deux parties puissent immédiatement récupérer leur argent.

Enfin, comme le HTLC peut également être placé dans la transaction d'engagement, le canal Lightning peut également transférer les paiements. En supposant qu'Alice puisse trouver un chemin composé de canaux éclair se connectant d'avant en arrière et atteindre Daniel, alors un paiement multi-sauts sans confiance peut être réalisé sans ouvrir de canal avec Daniel. Voici le réseau Lightning :

Alice -- HTLC --- Bob -- HTLC ---> Carol -- HTLC --->Alice

Quand Alice découvre un tel chemin et veut payer Daniel, elle demande une valeur de hachage à Daniel, sur la base de laquelle elle construit un HTLC et la donne à Bob, et invite Bob à transmettre un message à Carol et à fournir le même HTLC ; le message invite Carol à transmettre un message à Daniel et à fournir le même HTLC. Lorsque la nouvelle parvient à Daniel, il révèle l'image originale à Carol, obtenant ainsi la valeur de HTLC et mettant à jour le statut du contrat ; Carol fait de même, obtient le paiement de Bob et met à jour le statut de la chaîne. Enfin, Bob révèle l'image originale et met à jour le statut ; statut à Alice. En raison des caractéristiques de HTLC, cette série de paiements réussit ou échoue ensemble, elle est donc sans confiance.

Le Lightning Network est composé de canaux les uns après les autres, et chaque canal (contrat) est indépendant les uns des autres. Cela signifie qu'Alice a seulement besoin de savoir ce qui s'est passé dans sa propre chaîne avec Bob, et n'a pas besoin de se soucier du nombre d'interactions qui ont eu lieu dans les chaînes d'autres personnes, ni de la devise utilisée par ces interactions, ou même de savoir si elles utilisent des chaînes réelles. .

L'évolutivité du réseau Lightning se reflète non seulement dans le fait que la vitesse de paiement au sein d'un canal Lightning n'est limitée que par l'investissement en ressources matérielles des deux parties, mais aussi dans le fait qu'en raison du stockage décentralisé de l'état, un seul nœud peut exploiter le plus grand effet de levier au moindre coût.

Drudent Log Contract

Le Prudent Log Contract (DLC) utilise une technique cryptographique appelée « signature d'adaptateur » pour permettre aux scripts Bitcoin de programmer des contrats financiers qui dépendent d'événements externes.

La signature de l'adaptateur permet à une signature de devenir une signature valide uniquement après l'ajout d'une clé privée. En prenant la signature Schnorr comme exemple, la forme standard de la signature Schnorr est (R, s), où :

R = r.G # La valeur occasionnelle r utilisée dans la signature est multipliée par le point de génération de courbe elliptique, qui peut également être considéré comme la clé publique de r

s = r + Hash(R || m || P) * p # p est la clé privée de signature, P est la clé publique

Vérifier la signature signifie vérifier s.G = r.G + Hash(R || m || P) * p.G = R + Hash(R || m || P) * PK

Supposons qu'on me donne une paire de données (R, s'), où :

R = R1 + R2 = r1.G + r2.G

s ' = r1 + Hash(R || m || P) * p

Évidemment, ce n'est pas une signature Schnorr valide. Elle ne peut pas passer la formule de vérification de signature. . Cependant, je peux le prouver au vérificateur, tant que TA sait que la clé privée r2 de R2 peut en faire une signature valide :

s'.G + R2 = R1 + Hash(R || m || P) * P. + R2 = R + Hash(R || m || P) * P

La signature de l'adaptateur permet à la validité d'une signature de dépendre d'une donnée secrète et d'être vérifiable. Mais qu’est-ce que cela a à voir avec les contrats financiers ?

Supposons qu'Alice et Bob veuillent parier sur le résultat d'un match de football. Alice et Bob ont parié respectivement 1 BTC sur Green Goblin et Alina. De plus, le site de commentaires de football Carol promet d'utiliser un nom occasionnel R_c pour publier la signature s_c_i du résultat lors de l'annonce du résultat du match de football.

On voit qu'il y a trois résultats possibles (donc la signature de Carol a 3 possibilités) :

• Le Bouffon Vert gagne, Alice gagne 1 BTC
• Alina gagne, Bob gagne 1 BTC
• Un tirage au sort, Les deux personnes les fonds sont restitués de la même manière

Pour ce faire, les deux personnes créent une transaction d'engagement pour chaque résultat. Par exemple, la transaction d'engagement qu'ils ont créée pour le premier résultat ressemble à ceci :

Entrée #0, 2 BTC : sortie multi-signature Alie-Bob 2 sur 2 (c'est-à-dire le contrat de pari)

Sortie #0, 2 BTC : la signature unique d'Alice

Cependant, les signatures créées par Alice et Bob pour cette transaction ne sont pas des (R, s), mais des signatures d'adaptateur (R, s') ; être utilisé directement. Pour débloquer ce contrat, une valeur secrète doit être révélée. Cette valeur secrète est exactement l'image originale de s_c_1.G, qui est la signature de Carol ! Parce que la valeur occasionnelle de la signature de Carol a été déterminée (c'est R_c), s_c_1.G peut être construit (s_c_1.G = R_c + Hash(R_c || 'Le Bouffon Vert gagne' || PK_c) * PK_c).

Lorsque le résultat est annoncé, en supposant que le Bouffon Vert gagne, Carol émettra la signature (R_c, s_c_1). Ensuite, Alice et Bob pourront compléter la signature de l'adaptateur de l'adversaire, plus leur propre signature, faisant de la transaction ci-dessus une transaction valide. est diffusé sur le réseau et déclenche l'effet de règlement. Mais si le Bouffon Vert n'avait pas gagné, Carol n'aurait pas publié s_c_1, et l'accord conclu n'aurait pas été un accord valide.

Il en va de même pour les deux autres transactions. Ainsi, Alice et Bob font dépendre l'exécution de ce contrat d'événements extérieurs (pour être précis, s'appuyant sur la diffusion d'événements extérieurs par la machine d'assertion sous forme de signature) sans faire confiance à la contrepartie. Les contrats financiers, petits et grands, tels que les contrats à terme et les options, peuvent être mis en œuvre de cette manière.

Par rapport à d'autres formes de mise en œuvre, la plus grande caractéristique du contrat de journal prudent est sa confidentialité : (1) Alice et Bob n'ont pas besoin de dire à Carol qu'ils utilisent les données de Carol, ce qui n'affecte pas l'exécution du contrat à tous ; (2) Les observateurs de la chaîne (y compris Carol) ne peuvent pas déterminer quels services de site Web ils utilisent en exécutant des transactions via les contrats d'Alice et Bob, ni même déterminer que leur contrat est un contrat de pari (plutôt qu'un canal éclair).

4. Introduction à l'application des clauses restrictives

OP_CTV et contrôle de la congestion

Les développeurs de la communauté Bitcoin ont proposé une variété de propositions qui peuvent être classées comme clauses restrictives. Du point de vue actuel, la proposition la plus connue est OP_CHECKTEMPLATEVERIFY (OP_CTV). Son concept est relativement simple, mais elle conserve une flexibilité considérable, elle est donc bien accueillie par la communauté Bitcoin qui prône la simplicité. L'idée de OP_CTV est de valider une valeur de hachage dans le script pour contraindre que les fonds ne peuvent être dépensés que par la transaction représentée par la valeur de hachage ; cette valeur de hachage valide la sortie de la transaction et la plupart des champs, mais ne valide pas. L’entrée de la transaction n’engage que sur la quantité entrée.

"Congestion Control" est un bon exemple qui peut refléter les caractéristiques d'OP_CTV. Son scénario d'application de base est d'aider un grand nombre d'utilisateurs à se retirer de l'échange (un environnement qui nécessite de la confiance) dans un pool de fonds puisque ce pool de fonds utilise OP_CTV pour planifier les futures méthodes de dépenses, il peut garantir que les utilisateurs peuvent se retirer de cette confiance ; -free Le pool de fonds ne nécessite l'aide de personne ; et comme ce pool de fonds n'apparaît que comme un UTXO, il évite de payer des frais de traitement importants lorsque la demande de transactions en chaîne est élevée (réduite de n sorties à 1 sortie ; également à partir de n transactions Transactions réduites à 1 transaction). Les utilisateurs du pool peuvent attendre une opportunité puis se retirer du pool.

Supposons qu'Alice, Bob et Carol souhaitent retirer respectivement 5 BTC, 3 BTC et 2 BTC de l'échange. Ensuite, l'échange peut effectuer une sortie avec 3 succursales OP_CTV d'un montant de 10 BTC. Supposons qu'Alice veuille retirer de l'argent, elle peut utiliser la branche 1 ; la transaction représentée par la valeur de hachage utilisée par l'OP_CTV de cette branche formera deux sorties, une sortie consiste à allouer 5 BTC à Alice ; Utilisez également OP_CTV pour valider une transaction qui permet uniquement à Bob de retirer 3 BTC et d'envoyer les 2 BTC restants à Carol.

Il en va de même si Bob ou Carol souhaitent retirer de l'argent. Lorsqu'ils retirent de l'argent, ils ne pourront utiliser que les transactions qui peuvent passer le contrôle OP_CTV correspondant, c'est-à-dire qu'ils ne pourront se payer que le montant correspondant et ne pourront pas retirer d'argent à volonté ; les fonds restants entreront dans un pool de fonds verrouillé à l'aide ; OP_CTV, garantissant ainsi que quel que soit l'ordre dans lequel les utilisateurs retirent leurs fonds, les utilisateurs restants peuvent se retirer du pool en toute confiance.

Abstraitement, le rôle de OP_CTV ici est de planifier le chemin du contrat jusqu'à la fin de sa vie, afin que le contrat de pool de capitaux ici puisse conserver l'attribut de sortie sans confiance, quel que soit le chemin qu'il emprunte ou l'état. cela atteint.

Ce type d'OP_CTV a également un usage très intéressant : "canal de paiement unidirectionnel caché". Supposons qu'Alice forme un tel pool et garantisse que les fonds peuvent être retirés en toute confiance dans une sortie avec un script comme celui-ci :

Soit Alice et Bob le dépensent ensemble, soit, après un certain temps, Alice peut le dépenser seule

Si Alice le fait ne le révèle pas à Bob, Bob ne saura pas qu'un tel résultat existe ; une fois qu'Alice l'a révélé à Bob, Bob peut utiliser ce résultat comme canal de paiement unidirectionnel urgent, et Alice peut immédiatement utiliser les fonds pour Bob Payer sans devoir attendre la confirmation sur la blockchain. Bob a juste besoin de laisser Alice mettre en chaîne sa transaction engagée avant qu'Alice puisse la dépenser seule.

OP_Vault et Vaults

OP_VAULT est une proposition de clause de restriction spécialement proposée pour la construction de "vaults".

Les contrats Vault sont conçus pour être une forme d'auto-garde plus sûre et plus avancée. Bien que le contrat multi-signature actuel puisse éviter le point de défaillance unique d’une clé privée unique, si un attaquant obtient un nombre seuil de clés privées, le propriétaire du portefeuille ne pourra rien faire. Le Vault espère imposer une limite de dépenses unique sur les fonds ; en même temps, lors d'un retrait via des itinéraires réguliers, l'opération de retrait imposera une période d'attente pendant la période d'attente, l'opération de retrait pouvant être interrompue par un portefeuille d'urgence ; opération de récupération. Même si un tel contrat est rompu, le propriétaire du portefeuille peut prendre des contre-mesures (en utilisant la branche de récupération d'urgence).

Théoriquement, OP_CTV peut aussi programmer un tel contrat, mais il présente de nombreux inconvénients, dont l'un est les frais de traitement : en s'engageant dans une transaction, il s'engage également sur les frais de traitement qui seront payés pour la transaction. Compte tenu de l’objectif d’un tel contrat, le délai entre la mise en place du contrat et le retrait de l’argent doit être très long, ce qui rend presque impossible la prévision d’un montant approprié. Bien que OP_CTV ne limite pas les intrants, les frais de traitement peuvent être augmentés en augmentant les intrants, mais tous les intrants fournis deviendront des frais de traitement, il est donc irréaliste d'utiliser le CPFP, c'est-à-dire de dépenser les fonds retirés en frais ; sont fournis sur les nouvelles transactions. De plus, l'utilisation d'OP_CTV signifie également qu'un contrat aussi sûr ne peut pas être retiré par lots (et bien sûr pas restauré par lots). La proposition

OP_VAULT tente de résoudre ces problèmes en proposant de nouveaux opcodes (OP_VAULT et OP_UNVAULT). OP_UNVAULT est conçu pour la récupération par lots, nous n'en parlerons donc pas pour l'instant. L'action de OP_VAULT est la suivante : lorsque nous le plaçons sur une branche de l'arborescence de scripts, il peut être utilisé pour promettre un opcode exploitable (comme OP_CTV) sans paramètres spécifiques lors de la dépense de cette branche, les transactions peuvent passer dans des paramètres spécifiques, mais les autres branches ne peuvent pas être modifiées. Par conséquent, il n'a pas besoin de fixer des frais de traitement et peut définir les frais de traitement lors de la dépense de cette succursale ; en supposant que cette succursale dispose également d'un verrouillage temporel, elle appliquera finalement un verrouillage temporel, car elle ne peut modifier que l'emplacement ; là où se trouve Branch, les autres branches de la nouvelle arborescence de script (y compris la branche de récupération d'urgence) ne seront pas modifiées, nous permettant ainsi d'interrompre une telle opération de retrait.

De plus, il y a deux points qui méritent d'être mentionnés : (1) L'action de l'opcode OP_VAULT est similaire à une autre proposition de restriction : OP_TLUV ; Jeremy Rubin a souligné à juste titre que cela a déjà donné naissance au concept de "calcul" dans un certain domaine. étendue : OP_TLUV /OP_VAULT promet d'abord un opcode pour permettre à l'utilisateur de transmettre des paramètres à l'opcode via une nouvelle transaction, mettant ainsi à jour toute la feuille de l'arborescence de script ; il ne s'agit plus de "vérifier les données entrantes en fonction de certaines conditions", mais " génère de nouvelles données significatives basées sur les données entrantes", bien que les calculs qu'il peut permettre soient relativement limités.

La proposition OP_VAULT complète utilise également certaines propositions sur la politique mempool (telles que les transactions au format v3) pour obtenir de meilleurs résultats. Cela nous rappelle que le terme « programmation » peut signifier bien plus que nous ne le pensons. (Un exemple similaire est Open Transaction dans Nervos Network.)

5. Comprendre CKB

Dans les deux chapitres ci-dessus, nous avons présenté comment nous utilisons CKB sur une structure plus restreinte (Bitcoin UTXO). Les scripts mènent à des propositions d'applications intéressantes à essayer ; pour ajouter des capacités d'introspection à cette structure sont également introduits.

UTXO Bien que la capacité de programmer ces applications ne manque pas, les lecteurs peuvent facilement détecter leurs lacunes, ou les domaines qui peuvent être optimisés, tels que :

• Dans LN-Penalty, les participants au canal doivent sauvegarder chaque transaction passée Une transaction d'engagement et la valeur secrète de pénalité correspondante en réponse à une fraude d'un adversaire constitue une charge de stockage. S'il existe un mécanisme garantissant que seule la dernière transaction d'engagement prendra effet et que l'ancienne transaction d'engagement ne prendra pas effet, alors ce fardeau peut être éliminé, et il peut également éliminer la possibilité que les nœuds se trompent sur des engagements plus anciens en raison d'échecs. . Le problème des transactions en chaîne et donc sanctionnées de manière inattendue.
• Dans le DLC, on suppose qu'il y a de nombreux résultats possibles de l'événement, et les deux parties doivent générer de nombreuses signatures à l'avance et se les remettre, ce qui représente également un énorme fardeau en plus des revenus de l'événement ; Le contrat DLC est directement lié à la clé publique. Par conséquent, sa position n'est pas facile à transférer. Existe-t-il un moyen de transférer la position du contrat ?

En fait, la communauté Bitcoin a apporté des réponses à ces questions, essentiellement liées à une proposition Sighash (BIP-118 AnyPrevOut).

Cependant, si nous programmons sur CKB, BIP-118 est disponible dès maintenant (cette balise Sighash peut être simulée avec la possibilité d'introspecter et de vérifier spécifiquement les signatures).

En apprenant la programmation Bitcoin, nous savons non seulement comment programmer le format "sortie de transaction" (que peut programmer CKB), mais aussi comment améliorer ces applications (que pouvons-nous faire si nous programmons ces applications sur CKB Utiliser les capacités de CKB pour les améliorer). Pour les développeurs CKB, la programmation basée sur le script Bitcoin peut être considérée comme un manuel d’apprentissage ou même un raccourci.

Ci-dessous, nous analysons la programmabilité de chaque module de programmation CKB un par un. Ne considérons pas pour l’instant les capacités introspectives.

Script de verrouillage pouvant être programmé pour des calculs arbitraires

Comme mentionné ci-dessus, UTXO ne peut pas être programmé pour des calculs arbitraires. Lock Script le peut, ce qui signifie que Lock Script peut programmer (avant le déploiement des restrictions) tout ce qui est basé sur la programmation UTXO, y compris, mais sans s'y limiter, le canal Lightning et le DLC mentionnés ci-dessus.

De plus, cette capacité de vérifier n'importe quel calcul permet également à Lock Script d'utiliser davantage de méthodes d'authentification et est plus flexible qu'UTXO. Par exemple, nous pouvons implémenter un canal Lightning sur CKB où une partie utilise la signature ECDSA et l'autre partie utilise la signature RSA.

En fait, c'est l'un des premiers domaines que les gens ont commencé à explorer sur CKB : utiliser cette capacité flexible de vérification d'identité dans la garde autonome des utilisateurs pour réaliser ce que l'on appelle « l'abstraction du compte » - la validité des transactions. L'autorisation et la restauration du contrôle sont toutes deux flexible et pratiquement illimité. En principe, il s’agit d’une combinaison de « plusieurs branches de dépenses » et de « n’importe quelle méthode d’authentification ». Des exemples d'implémentations incluent : JoyID Wallet, UniPass.

De plus, Lock Script peut également implémenter la proposition eltoo, réalisant ainsi un canal éclair qui n'a besoin que de conserver la dernière transaction validée (en fait, eltoo peut simplifier tous les contrats point à point).

Type Script capable de programmer des calculs arbitraires

Comme mentionné ci-dessus, l'une des principales utilisations de Type Script est de programmer UDT. Combiné avec Lock Script, cela signifie que nous pouvons implémenter des canaux Lightning basés sur UDT (ainsi que d'autres types de contrats).

En fait, la séparation de Lock Script et Type Script peut être considérée comme une mise à niveau de sécurité : Lock Script se concentre sur la mise en œuvre de méthodes de garde ou de protocoles contractuels, tandis que Type Script se concentre sur la définition de l'UDT.

De plus, la possibilité d'initier des contrôles basés sur les définitions de l'UDT permet également à l'UDT de participer aux contrats de la même manière que CKB (l'UDT est un citoyen de premier ordre).

Par exemple : l'auteur a proposé un jour un protocole pour mettre en œuvre des prêts sécurisés NFT sans confiance sur Bitcoin. La clé de ce protocole est une transaction d'engagement dans laquelle la valeur de l'entrée est inférieure à la valeur de la sortie (ce n'est donc pas encore une transaction valide). Cependant, une fois qu'une entrée suffisante peut être fournie pour cette transaction, elle est A). transaction valide : une fois que le prêteur est en mesure de rembourser, le prêteur ne peut pas conserver le NFT promis comme sien. Cependant, la nature sans confiance de cette transaction d'engagement est basée sur la vérification des montants des entrées et des sorties, de sorte que le prêteur ne peut rembourser le prêt qu'en Bitcoin - même si le prêteur et le prêteur sont tous deux prêts à accepter une autre devise (telle que dans RGB USDT émis par le protocole), la transaction d'engagement de Bitcoin ne peut pas garantir que tant que le prêteur restitue le montant suffisant d'USDT, il pourra récupérer son NFT, car la transaction Bitcoin ne connaît pas du tout le statut de l'USDT ! (Révision : En d'autres termes, il est impossible de construire une transaction d'engagement conditionnelle au remboursement de l'USDT.)

Si nous pouvons lancer un contrôle basé sur la définition de l'UDT, il sera possible pour le prêteur de signer une autre transaction d'engagement. , permettant au prêteur d'utiliser l'USDT pour rembourser le paiement. La transaction vérifiera le montant de l'USDT entré et le montant de la sortie de l'USDT, offrant ainsi aux utilisateurs un remboursement sans confiance à l'aide de l'USDT.

Révision : en supposant que le NFT utilisé comme garantie et le jeton utilisé pour le remboursement soient émis en utilisant le même protocole (tel que RGB), alors le problème ici peut être résolu. Nous pouvons donc construire une transaction d'engagement basée sur le protocole RGB. que la transition d'état et le remboursement du NFT peuvent se produire simultanément (deux transitions d'état sont liées aux transactions au sein du protocole RGB). Cependant, comme les transactions RVB reposent également sur les transactions Bitcoin, la construction de la transaction d'engagement sera ici quelque peu difficile. Dans l’ensemble, même si le problème peut être résolu, le jeton est un citoyen de première classe.

Ensuite, nous examinerons la capacité d'introspection.

Lock Script lit d'autres Lock Scripts

Cela signifie des possibilités de programmation complètes sur les UTXO Bitcoin une fois les restrictions proposées mises en œuvre. Y compris le contrat de sécurité mentionné ci-dessus, ainsi que les applications basées sur OP_CTV (comme le contrôle de congestion).

XueJie a mentionné un exemple très intéressant : vous pouvez implémenter une cellule de compte de collecte sur CKB lorsque vous utilisez cette cellule comme entrée d'une transaction, si la cellule qu'elle génère (cellule utilisant le même script de verrouillage) a plus de capacité, alors ceci. la saisie ne nécessite pas de signature et n’affectera pas la validité de la transaction. En fait, une telle cellule ne serait pas possible sans la capacité d’introspection. Ce type de compte de collecte Cell est très approprié comme méthode de collecte pour les institutions car il peut mettre en commun des fonds. L'inconvénient est qu'il offre une mauvaise confidentialité.

Lock Script lit d'autres scripts de type (et données)

Une application intéressante de cette capacité est les jetons d'équité. Le script de verrouillage décidera s'il peut utiliser sa propre capacité en fonction du nombre de jetons dans d'autres entrées et où la capacité peut être dépensée (nécessite la capacité d'introspecter le script de verrouillage).

Type Script lit d'autres scripts de verrouillage

Pas sûr, mais on peut supposer qu'il est utile. Par exemple, les scripts de verrouillage qui peuvent vérifier les entrées et sorties d'une transaction dans Type Script restent inchangés.

Type Script lit d'autres types de scripts (et données)

Cartes à collectionner ? La collecte de n jetons peut être échangée contre un jeton plus grand : )

6. Conclusion

Par rapport aux précédents systèmes de contrats intelligents programmables pour des calculs arbitraires (tels que Ethereum), Nervos Network adopte donc une structure différente, La compréhension des smart précédents ; Les systèmes contractuels sont souvent difficiles à constituer la base de la compréhension du réseau Nervos. Cet article propose une méthode pour comprendre la programmabilité de CKB Cell à partir de la programmation applicative d'une structure plus restreinte que CKB Cell - BTC UTXO. De plus, en utilisant le concept d'« introspection » pour comprendre la capacité « d'accès croisé » de Cell, nous pouvons diviser les situations dans lesquelles les capacités d'introspection sont utilisées et en déterminer des utilisations spécifiques.

Révision : 

1. Quelle que soit la capacité d'accès croisé de Cell (c'est-à-dire la capacité d'introspection), les scripts de verrouillage peuvent être considérés comme des scripts Bitcoin avec des capacités de programmation d'état et extrêmes. Par conséquent, tous les programmes basés sur Bitcoin peuvent être programmés sur cette base. seul. Application du script ;

2. Quelle que soit la capacité d'accès croisé de Cell (c'est-à-dire la capacité d'introspection), la distinction entre les scripts de verrouillage et les scripts de type peut être considérée comme une mise à niveau de sécurité : elle sépare la définition des actifs et les méthodes de stockage de l'UDT ; De plus, les scripts de type (ainsi que les données) qui peuvent exposer l'état implémentent l'effet selon lequel les UDT sont des citoyens de première classe.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!