Pour comprendre la programmabilité d’un système, il faut identifier les caractéristiques structurelles du système. L’exploration de la programmation d’applications basée sur Bitcoin Script nous aide à comprendre la structure de base de CKB Cell et son paradigme de programmation. Non seulement cela, mais il décompose les composants de programmation du CKB en bons morceaux et nous aide à comprendre les gains de programmabilité que chaque partie apporte.
I. Préambule
La « programmabilité » est une dimension que les gens prennent souvent lorsqu’ils comparent des systèmes blockchain. Cependant, il y a souvent un désaccord sur la façon dont la programmabilité est décrite. Une expression courante est « La blockchain XX prend en charge les langages de programmation Turing-complets », ou « La blockchain XX prend en charge la programmation à usage général », ce qui est destiné à indiquer que la « blockchain XX » a ici une forte programmabilité. Il y a une part de vérité dans l’implication de ces affirmations : les systèmes qui prennent en charge la programmation Turing-complète sont généralement plus faciles à programmer que ceux qui ne le font pas. Cependant, les caractéristiques structurelles d’un système de contrats intelligents comportent de nombreux aspects, et cette déclaration ne touche qu’à l’un d’entre eux, de sorte qu’il ne suffit pas de le comprendre suffisamment en profondeur en raison du fait que les développeurs ne sont pas guidés par celui-ci et que l’on ne peut pas compter sur les utilisateurs ordinaires pour distinguer la fraude.
Les caractéristiques structurelles d’un système de contrat intelligent sont les suivantes :
La forme de base de l’expression de l’état (contrat) (compte par rapport à la production commerciale)
Si le calcul arbitraire est autorisé ou non à être programmé (c’est ce que signifie le terme « Turing-complet »)
Le processus d’exécution crée-t-il de nouvelles données, ou se contente-t-il de transmettre des booléens ? (Calcul et validation)
Autoriser ou non l’enregistrement d’états supplémentaires dans le contrat
Si un contrat a accès à l’état d’un autre contrat lors de son exécution
Par conséquent, en plus du « calcul arbitraire programmable », il existe au moins 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 à réaliser et ce qui est difficile à réaliser ; Qu’est-ce qu’une mise en œuvre plus économique et qu’est-ce qu’une mise en œuvre moins efficace ?
Par exemple, Ethereum est souvent cité comme un exemple de bonne programmabilité, mais la forme de base de l’expression d’état sur Ethereum est un compte, ce qui rend difficile la programmation de contrats peer-to-peer (par exemple, les passerelles de paiement, les contrats de paris en tête-à-tête) – pas absolument impossible, juste ingrat. Il n’est pas rare que l’écosystème Ethereum essaie de mettre en œuvre un canal de paiement/canal d’État, et il y a eu beaucoup de discussions théoriques, mais ces projets ne semblent plus être actifs – et cela ne peut évidemment pas être imputé au manque d’efforts de la part des développeurs. Ce n’est pas un hasard si les projets actifs sur Ethereum prennent aujourd’hui la forme de « pools » plutôt que de « contrats peer-to-peer ». De même, les gens peuvent être satisfaits de la programmabilité d’Ethereum, mais le modèle de compte est intrinsèquement déficient pour réaliser « l’abstraction de compte » (ce qui peut également être compris comme une généralisation du concept de portefeuille).
De la même manière, l’exploration de la programmabilité de CKB nécessite également de 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 de programmer des calculs arbitraires, d’enregistrer un état supplémentaire dans un contrat et de permettre à un contrat d’accéder à l’état d’un autre contrat lorsqu’il est exécuté. Cependant, la forme du contrat est le résultat d’une transaction (appelée « cellule »), ce qui le rend fondamentalement différent d’Ethereum. Par conséquent, une compréhension du système de contrats intelligents Ethereum et des instances de contrat qu’il contient ne nous aide pas à comprendre comment CKB implémente ces caractéristiques structurelles, ni à comprendre la programmabilité de CKB.
Heureusement, les contrats intelligents sur Bitcoin semblent fournir la meilleure base pour comprendre la programmabilité de CKB. Ce n’est pas seulement parce que la forme de base de la représentation de l’état de Bitcoin est également la sortie de transactions (appelées « UTXO »), mais aussi parce que, à l’aide d’un concept proposé par la communauté Bitcoin appelé « covenants », nous pouvons comprendre pourquoi CKB a ces caractéristiques structurelles, et décomposer de manière appropriée l’effet final en plusieurs parties, en identifiant les gains de programmabilité que chacune d’entre elles apporte.
II. CKB v.s. BTC : Quoi de plus ?
(1) Structure de base
En tant que forme de base de la représentation de l’état de Bitcoin, l’UTXO (« Unspent Transaction Output ») de Bitcoin comporte deux champs :
Le montant, en Satoshi, indique la valeur du Bitcoin possédé par l’UTXO ;
La clé publique de 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 définit les conditions de déverrouillage des fonds.
Comparé aux systèmes de contrats intelligents qui sont venus plus tard, Bitcoin Script est assez limité :
Il ne permet pas de programmer des calculs arbitraires ; Il n’y a que quelques calculs pratiques qui peuvent être utilisés pour la vérification (vérification de signature, vérification de pré-hachage, vérification de l’heure)
Il ne permet pas d’enregistrer des états supplémentaires dans le contrat ; (Par exemple, vous ne pouvez pas utiliser un script pour limiter le montant proportionnel/maximum dépensé à un moment donné ; Il n’y a pas non plus moyen d’y cacher un jeton)
Il ne permet pas non plus d’accéder à l’état d’un autre contrat au moment de l’exécution (chaque script est un univers séparé et ne dépend pas de l’autre).
Ce type de script, bien que limité, ne manque pas de capacité à programmer des applications étonnantes, et c’est la base de notre exploration de la programmabilité CKB. Il y aura une section plus tard qui présentera deux exemples de programmation Bitcoin Script.
En revanche, l’unité d’état du CKB est appelée « cellule » et comporte quatre champs :
La capacité, similaire à la quantité d’UTXO, exprime la quantité d’espace que la cellule peut occuper, mesurée en octets.
Lock, similaire à la clé publique du script UTXO, définit la propriété de la cellule ; Ce n’est que lorsque les données fournies peuvent passer à travers le verrou que la cellule peut être « mise à jour » (ou que la cellule peut être libérée et que la capacité peut être utilisée pour créer de nouvelles cellules) ;
Des données, des données, des données arbitraires, dont le volume est limité par la capacité ;
Type, un script facultatif qui définit les conditions de mise à jour des données.
De plus, Lock et Type peuvent être programmés pour des calculs arbitraires. Vous pouvez programmer n’importe quel algorithme de vérification de signature, vous pouvez programmer n’importe quel algorithme de hachage pour la vérification de la préimage, etc.
Il est facile pour les lecteurs de voir comment la programmabilité de Cell s’améliore par rapport aux UTXO :
Les cellules peuvent être programmées avec des calculs arbitraires, plutôt qu’avec quelques calculs spécifiques ; La vérification de la propriété sera plus souple ;
En raison des champs Data (Données) et Type (Type), la cellule peut enregistrer des états supplémentaires ; Cela permet à la cellule de transporter ce que l’on appelle un « UDT » (jeton défini par l’utilisateur).
Combinés à la structure de « sortie de transaction » de la cellule elle-même, les avantages de ces deux points en eux-mêmes sont très, très significatifs, mais à partir de la seule description ci-dessus, nous ne savons pas comment la cellule atteint « un contrat accède à l’état d’un autre contrat au moment de l’exécution ». Pour ce faire, nous devons nous inspirer d’un concept qui fait l’objet de discussions de longue date dans la communauté Bitcoin : les « covenants ».
(2) Limites et introspection
L’objectif initial d’une clause de restriction est de limiter les endroits où une somme d’argent peut être dépensée. Sur Bitcoin actuel (où aucune restriction n’a été proposée), une seule somme d’argent, une fois débloquée, peut être dépensée n’importe où (elle peut être payée à une clé publique de script arbitraire). Mais l’idée de la clause de restriction est qu’il peut être dépensé d’une manière qui le limite à certains endroits, par exemple, un certain UTXO ne sera dépensé que par une certaine transaction, de sorte que même si quelqu’un peut fournir une signature pour l’UTXO, l’endroit où il peut être dépensé a déjà été déterminé par cette transaction. Cela peut sembler un peu étrange, mais cela peut conduire à des applications intéressantes, qui seront abordées dans une section plus tard. Il est important de noter qu’il s’agit d’un élément clé pour mieux comprendre la programmabilité de CKB.
Rusty Russell souligne à juste titre qu’une restriction peut être comprise comme une capacité d’introspection à trader, c’est-à-dire que lorsqu’un UTXO A est dépensé par une transaction B, un opérateur de script peut lire une partie (ou la totalité) de la transaction B et ensuite vérifier qu’ils correspondent aux paramètres pré-demandés par le script. Par exemple, si la clé publique de script pour la première sortie de la transaction A correspond à ce qui est requis par la clé publique de script d’UTXO A (c’est ce que la restriction signifiait à l’origine).
Le lecteur astucieux se rendra compte qu’avec une introspection complète, l’entrée d’une transaction peut lire l’état d’une autre entrée de la même transaction, ce qui permet à un contrat d’accéder à l’état d’un autre contrat au moment de l’exécution. En fait, c’est exactement comme cela que CKB Cell a été conçu.
Sur cette base, nous pouvons diviser cette capacité introspective complète en quatre scénarios :
Le verrou lit les autres verrous (d’entrée et de sortie)
Lock lit le type (ainsi que les données) de l’autre (entrée et sortie)
Le type lit d’autres verrous (d’entrée et de sortie)
Type lit le Type (et les Données) de l’autre (entrée et sortie)
Cela nous permet d’analyser le rôle des capacités introspectives de chaque pièce dans différents cas d’utilisation sous certaines hypothèses (la division des fonctions entre Lock et Type), c’est-à-dire le gain de programmabilité que chaque partie nous apporte.
Dans les deux sections suivantes, nous examinerons la programmation actuelle (et pas encore proposée) de Bitcoin Script, et les fonctionnalités probables que la restriction proposée devrait atteindre, afin de donner une compréhension concrète de la façon dont CKB Cell peut être programmé et amélioré.
III. Programmation de scripts Bitcoin
Dans cette section, nous utiliserons « Lightning Channel/Lightning Network » et « Caution Journal Contract (DLC) » comme exemples de programmation d’applications basées sur Bitcoin Script. Avant d’entrer dans le vif du sujet, prenons deux choses en considération.
(1) OP_IF et « Accords d’engagement »
Le premier concept est l’opcode de contrôle de flux en Bitcoin Script, tel que : OP_IF, OP_ELSE. Ces opcodes ne sont pas différents de IF en programmation informatique, et leur but est d’exécuter différentes instructions basées sur différentes entrées. Dans le contexte de Bitcoin Script, cela signifie que nous pouvons définir plusieurs chemins de déverrouillage pour les fonds ; Combiné à la fonction de verrouillage du temps, cela signifie que nous pouvons attribuer une priorité aux actions.
Prenons l’exemple du fameux « Hash Timelock Contract (HTLC) », qui se traduit en langue vernaculaire :
Alternativement, Bob pourrait révéler la préimage derrière un H de hachage et donner sa propre signature, ce qui coûterait de l’argent
Ou bien, Alice peut dépenser l’argent avec sa propre signature après une certaine période de T
Ce « ou ... ou ... L’effet est obtenu grâce à l’opcode de contrôle de processus.
L’avantage le plus important de > HTLC est qu’il peut regrouper plusieurs opérations et les atomiser. Par exemple, si Alice veut échanger des BTC contre des CKB avec Bob, Bob peut d’abord donner une valeur de hachage et créer un HTLC sur le réseau Nervos. Alice crée ensuite un HTLC sur Bitcoin qui utilise le même hachage. Alternativement, Bob prend les BTC payés par Alice sur Bitcoin, tout en révélant la préimage, permettant à Alice de retirer des CKB sur le réseau Nervos. Quoi qu’il en soit, Bob ne révèle pas l’image originale, les deux contrats expirent et Alice et Bob peuvent récupérer l’argent qu’ils ont investi.
Après l’activation du soft fork de Taproot, cette fonctionnalité de chemin multi-déverrouillé est encore améliorée par l’introduction de MAST (Merkle Abstract Syntax Tree) : nous pouvons transformer un chemin de déverrouillage en une feuille sur l’arbre de Merkle, chaque feuille est indépendante, il n’est donc plus nécessaire d’utiliser un tel opcode de contrôle de flux ; De plus, comme un chemin est révélé sans exposer les autres, nous pouvons ajouter un plus grand nombre de chemins de déverrouillage à une sortie sans avoir à nous soucier de l’économie.
Le deuxième concept est le « trading d’engagement ». L’idée d’une transaction engagée est que, dans certains cas, une transaction Bitcoin valide, même si elle n’est pas confirmée par la blockchain, est tout aussi réelle et contraignante.
Par exemple, Alice et Bob partagent un UTXO qui nécessite qu’ils soient tous les deux signés pour dépenser. À ce stade, Alice construit une transaction pour le dépenser, transférant 60% de sa valeur à Bob et le reste à elle-même ; Alice fournit sa propre signature pour la transaction, qui est ensuite envoyée à Bob. Eh bien, pour Bob, il n’est pas nécessaire qu’il soit diffusé sur le réseau Bitcoin, et il n’a pas besoin d’être confirmé par la blockchain, et l’effet de paiement de cette transaction est également réel et crédible. Parce qu’Alice ne peut pas dépenser l’UTXO seule (et ne peut donc pas le dépenser à plusieurs reprises), et parce que la signature fournie par Alice est valide, Bob peut toujours ajouter sa signature et diffuser la transaction pour honorer le paiement. En d’autres termes, Alice a fourni à Bob un « engagement crédible » par le biais de cette transaction valide (hors chaîne).
Les transactions engagées sont un concept central de la programmation d’applications Bitcoin. Comme mentionné précédemment, le contrat de Bitcoin est basé sur la vérification, apatride et ne permet pas l’accès croisé ; Cependant, si le contrat ne comporte pas d’États, où ces États sont-ils stockés, et comment le contrat peut-il aller de l’avant en toute sécurité (changer 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 enregistrer eux-mêmes l’état sans avoir à l’afficher sur la blockchain ; Le problème de la modification de l’état du contrat peut également être transformé en problème de la mise à jour en toute sécurité de la transaction validée ; De plus, si nous sommes préoccupés par les dangers de la conclusion d’un contrat (par exemple, la conclusion d’un contrat qui exige que les deux parties signent pour dépenser, et qu’il y ait un risque que l’autre partie ne réponde pas et reste coincée), alors le simple fait de générer une transaction d’engagement qui coûte le contrat à l’avance et d’obtenir une signature peut atténuer le risque et éliminer la confiance dans les autres participants.
(2) Canal Lightning et réseau Lightning
Un canal Lightning est un contrat one-to-one dans lequel deux parties peuvent se payer un nombre illimité de fois sans qu’aucun paiement ne soit confirmé par la blockchain. Comme vous pouvez vous y attendre, il utilise le trading d’engagement.
Dans la section expliquant « Transactions validées », nous avons déjà introduit un canal de paiement. Cependant, ce type de contrat, qui ne s’appuie que sur le multisig 2 sur 2, ne peut permettre que des paiements aller simple. C’est-à-dire que soit Alice paie toujours Bob, soit Bob paie toujours Alice jusqu’à ce qu’il utilise son solde dans le contrat. S’il s’agit d’un paiement bidirectionnel, cela signifie qu’après une mise à jour de statut, l’une des parties peut avoir moins de solde qu’auparavant, mais que l’AT a la dernière transaction engagée signée par l’autre partie - que peut-on faire pour empêcher l’AT de diffuser l’ancienne promesse et l’AT uniquement la transaction d’engagement la plus récente ?
La solution à ce problème avec le canal de foudre s’appelle « LN-Penalty ». Maintenant, disons qu’Alice et Bob ont chacun 5 BTC dans un canal ; Maintenant, Alice veut payer 1 BTC à Bob, alors elle signe la transaction promise et l’envoie à Bob :
Entrez #0 et 10 BTC :
Sortie multi-signature Alie-Bob 2 sur 2 (c’est-à-dire contrat de canal)
Sortie #0 , 4 BTC :
Alice mono-signature
Sortie #1 , 6 BTC :
ou
Clé publique éphémère fédérée Alice-Bob #1 à signature unique
ou
T 1 timelock, Bob signé à l’unité
Bob signe également un engagement (qui correspond à la transaction ci-dessus) et l’envoie à Alice :
Entrez #0 et 10 BTC :
Sortie multi-signature Alie-Bob 2 sur 2 (c’est-à-dire contrat de canal)
Sortie #0 , 6 BTC :
Bob signé à l’unité
Sortie #1 , 4 BTC :
ou
Clé publique éphémère fédérée Bob-Alice #1 à signature unique
ou
T 1 timelock, Alice signée à l’unité
L’astuce ici réside dans cette « clé publique temporaire conjointe », qui est générée à l’aide de l’une de ses propres clés publiques et d’une clé publique fournie par l’autre partie, par exemple, la clé publique temporaire conjointe Alice-Bob, qui est obtenue par Alice à l’aide de l’une de ses propres clés publiques et d’une clé publique fournie par Bob, en multipliant chacune par une valeur de hachage. Lorsqu’une telle clé publique est générée, personne ne connaît sa clé privée. Toutefois, 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 fédérée. - C’est la clé du fait que le Lightning Channel peut « annuler » l’ancien état.
La prochaine fois que les deux parties voudront mettre à jour le statut de la chaîne (initier un paiement), les deux parties échangeront la clé privée de la clé publique temporaire qui leur a été donnée lors du tour précédent. De cette façon, les participants n’osent plus diffuser la dernière transaction promise qu’ils ont reçue : la sortie de cette transaction promise attribuant de la valeur à leur propre partie a deux chemins, et la clé privée du chemin de clé publique temporaire est déjà connue de l’autre partie ; Ainsi, une fois que l’ancienne transaction d’engagement est diffusée, l’autre partie peut immédiatement utiliser cette clé privée temporaire conjointe pour prendre tous les fonds de cette sortie. - C’est ce que signifie « LN-Pénalité ».
Plus précisément, l’ordre d’interaction est le suivant : la partie qui initie le paiement demande d’abord une nouvelle clé publique temporaire à l’autre partie, puis construit une nouvelle transaction d’engagement et la remet à l’autre partie ; La partie qui a obtenu la transaction promise a révélé à l’autre partie la clé privée de la clé publique temporaire qu’elle avait donnée au tour précédent. Cette séquence d’interactions garantit que les participants obtiennent toujours une nouvelle transaction d’engagement avant d’invalider la transaction d’engagement qu’ils ont reçue lors du tour précédent, et est donc sans confiance.
En résumé, les principales conceptions du canal de foudre sont les suivantes :
Les deux parties utilisent toujours des transactions d’engagement pour exprimer l’état dans le contrat, et la modification du montant pour exprimer le paiement ;
Les transactions d’engagement coûtent toujours la même entrée (entrée qui nécessite que les deux parties fournissent des signatures en même temps), de sorte que toutes les transactions d’engagement sont en concurrence les unes avec les autres, et qu’une seule peut être confirmée par la blockchain.
Les deux participants ne signent pas la même transaction d’engagement (bien qu’ils soient jumelés) ; Et ce qu’ils signent est toujours une transaction qui leur est plus favorable, c’est-à-dire que la transaction promise que les participants reçoivent est toujours défavorable à eux-mêmes ;
L’inconvénient est que la sortie qui s’attribue une valeur a deux chemins de déverrouillage : un chemin peut être déverrouillé avec sa propre signature, mais il doit attendre un certain temps ; L’autre chemin utilise la clé publique de l’autre partie, qui n’est protégée que si l’une de ses clés privées temporaires n’est pas exposée.
Lors de chaque paiement, les deux parties échangent la clé privée temporaire utilisée par l’autre partie lors du cycle précédent avec une nouvelle transaction d’engagement, de sorte que la partie qui a remis la clé privée temporaire n’ose plus diffuser l’ancienne transaction d’engagement, de sorte qu’elle « annule » la transaction d’engagement précédente et met à jour le statut du contrat ; (En fait, ces transactions promises sont toutes des transactions valides et peuvent être diffusées sur la blockchain, mais les participants sont contraints d’être punis et n’osent plus diffuser)
L’une ou l’autre des parties peut résilier le contrat à tout moment avec un engagement signé par l’autre partie ; Cependant, si les deux parties sont disposées à coopérer, elles peuvent signer un nouvel accord afin que les deux parties puissent récupérer leur argent immédiatement.
Enfin, étant donné que HTLC peut également être placé dans une transaction validée, le canal Lightning peut également transférer des paiements. En supposant qu’Alice puisse trouver un chemin composé de canaux Lightning se connectant avant et après pour atteindre Daniel, alors des paiements multi-sauts sans confiance peuvent être réalisés sans ouvrir de canal avec Daniel. Il s’agit du Lightning Network :
Alice -- HTLC --> Bob -- HTLC --> Carol -- HTLC --> Daniel
Alice < -- Préimage -- Bob < -- Préimage -- Carol < -- Préimage -- Daniel
Quand Alice trouve un tel chemin et veut payer Daniel, elle demande à Daniel un hachage pour construire un HTLC pour Bob, et demande à Bob de transmettre un message à Carol et de fournir le même HTLC ; Le message invite Carol à transférer le message à Daniel et à fournir le même HTLC. Lorsque la nouvelle parvient à Daniel, il révèle la préimage à Carol, ce qui lui donne la valeur de HTLC et met à jour l’état du contrat. Carol a fait de même, en se faisant payer par Bob et en mettant à jour le statut de la chaîne. Finalement, Bob révèle la préimage à Alice et met à jour le statut. En raison de la nature de HTLC, cette chaîne de paiements réussit ou échoue ensemble et, en tant que telle, elle n’est pas fiable.
Le Lightning Network est composé d’un canal après l’autre, chacun d’entre eux étant indépendant l’un de l’autre. Cela signifie qu’Alice n’a besoin que de savoir ce qui se passe dans sa chaîne avec Bob, quel que soit le nombre d’interactions qui ont eu lieu dans les chaînes d’autres personnes, la devise utilisée par ces interactions, ou même si elles utilisent réellement la chaîne.
L’évolutivité du réseau Lightning ne se reflète pas seulement dans le fait que la vitesse de paiement au sein d’un canal Lightning n’est limitée que par l’investissement de ressources matérielles par les deux parties, mais aussi par le fait qu’en raison du stockage décentralisé de l’état, un seul nœud peut tirer parti de l’effet de levier maximal au coût le plus bas.
(3) Méfiez-vous des contrats de journaux
Le contrat DLC (Cautionary Journaling Contract) utilise une technique cryptographique appelée « signature d’adaptateur » qui permet à Bitcoin Script de programmer des contrats financiers qui dépendent d’événements externes.
Les signatures d’adaptateur permettent à une signature de devenir une signature valide uniquement après l’ajout d’une clé privée. Prenons l’exemple d’une signature de Schnorr, où la forme standard d’une signature de Schnorr est (R, s), où :
R = r.G
La valeur de nonce r utilisée pour la signature est multipliée par le point de génération de la courbe elliptique, qui peut également être considéré comme la clé publique de r
s = r + Hachage(R || m || P) * p
p est la clé privée de signature et P est la clé publique
验证签名即验证 s.G = r.G + Hash(R || m || P) * p.G = R + Hachage(R || m || P) * PK
Supposons que je donne une paire de données (R, s') où :
R = R 1 + R 2 = r 1.G + r 2.G
s'= r 1 + Hash(R || m || P) * p
Évidemment, ce n’est pas une signature Schnorr valide, et elle ne passe pas la formule de validation, mais je peux prouver au vérificateur qu’elle peut être une signature valide en connaissant simplement la clé privée de R 2, r 2 :
s'. G + R 2 = R 1 + Hachage(R || m || P) * P + R 2 = R + Hachage(R || m || P) * P
Les signatures d’adaptateur font dépendre la validité d’une signature d’une donnée secrète et sont vérifiables. 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 baseball. Alice et Bob ont parié sur la victoire du Bouffon Vert et d’Alina, respectivement, avec un pari de 1 BTC. De plus, Carol, un site Web de critiques de football, a promis d’utiliser un nonce R_c pour publier un s_c_i signé des résultats lorsque les résultats du match ont été annoncés.
Comme on peut le voir, il y a trois issues possibles (il y a donc 3 possibilités pour la signature de Carol) :
Le Bouffon Vert gagne, Alice gagne 1 BTC
Alina gagne, et Bob gagne 1 BTC
Égalité, les fonds des deux rapportent de la même manière
Pour ce faire, les deux créent un accord d’engagement pour chaque résultat. Par exemple, la transaction d’engagement qu’ils ont créée pour le premier résultat ressemblerait à ceci :
Entrez #0 , 2 BTC :
Sortie multi-signature Alie-Bob 2 sur 2 (c’est-à-dire le contrat de pari)
Sortie #0 , 2 BTC :
Alice mono-signature
Cependant, au lieu de (R, s), la signature qu’Alice et Bob ont créée pour cette transaction est une signature d’adaptateur (R, s') ; En d’autres termes, les signatures données par les deux parties ne peuvent pas être utilisées directement pour débloquer le contrat, mais doivent révéler une valeur secrète. Cette valeur secrète est la préimage de s_c_ 1.G, qui est la signature de Carol ! Puisque la valeur de nonce de signature de Carol a été déterminée (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 les résultats sont révélés, en supposant que le Bouffon Vert gagne, Carol émettra une signature (R_c, s_c_ 1), afin qu’Alice ou Bob puissent compléter la signature de l’adaptateur de l’adversaire et ajouter leur propre signature pour faire de la transaction ci-dessus une transaction valide, et la diffuser sur le réseau pour déclencher l’effet de règlement. Mais si le Bouffon Vert ne gagne pas, Carol ne postera pas s_c_ 1, et l’accord d’engagement ne sera pas un accord valide.
Et ainsi de suite, comme le sont les deux autres métiers. De cette façon, Alice et Bob font dépendre l’exécution du contrat d’événements extérieurs (pour être précis, de la diffusion d’événements externes par la machine assertor, sous la forme d’une signature) sans avoir à faire confiance à la contrepartie. Les grands et les petits contrats financiers, 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 caractéristique la plus importante 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 en rien l’exécution du contrat ; (2) Les observateurs on-chain (y compris Carol) ne seront pas en mesure de déterminer quel site Web ils utilisent grâce à l’exécution du contrat d’Alice et Bob, ou même si leur contrat est un contrat de pari (et non un canal éclair).
IV. Introduction à l’application des restrictions
(a) OP_CTV et contrôle de la congestion
Les développeurs de la communauté Bitcoin ont fait un certain nombre de propositions qui peuvent être classées comme des clauses restrictives. À l’heure actuelle, l’une des propositions les plus connues est OP_CHECKTEMPLATEVERIFY (OP_CTV), qui est populaire auprès de la communauté Bitcoin pour sa simplicité mais sa flexibilité avec son concept simple. L’idée de OP_CTV est de valider un hachage dans le script pour contraindre que les fonds ne peuvent être dépensés que par les transactions représentées par ce hachage ; Ce hachage promet la sortie de la transaction et la plupart des champs, mais pas l’entrée de la transaction, seulement le nombre d’entrées.
Le « contrôle de la congestion » est un bon exemple de la façon dont l’OP_CTV peut être démontré. Son cas d’utilisation de base est d’aider un grand nombre d’utilisateurs à sortir d’un échange (un environnement qui nécessite la confiance) dans un pool ; Étant donné que ce pool utilise OP_CTV pour planifier la façon dont il sera dépensé à l’avenir, il garantit que les utilisateurs peuvent quitter le pool sans confiance, sans l’aide de personne ; Et comme ce pool ne se comporte que comme un UTXO, il évite de payer beaucoup de frais lorsque la demande de transactions on-chain est élevée (de n sorties à 1 sortie ; également réduit de n transactions à 1 transaction). Les utilisateurs du pool peuvent attendre une opportunité pour sortir du pool.
Supposons qu’Alice, Bob et Carol veuillent retirer respectivement 5 BTC, 3 BTC et 2 BTC de l’échange. Ensuite, l’échange peut faire une sortie de 10 BTC avec 3 branches OP_CTV. 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 la branche formera deux sorties, dont l’une consiste à allouer 5 BTC à Alice ; L’autre sortie, à son tour, est un pool, qui utilise également OP_CTV pour s’engager dans une transaction, ce qui permet à Bob de retirer seulement 3 BTC et d’envoyer les 2 BTC restants à Carol.
C’est la même chose si Bob ou Carol veut retirer de l’argent. Lors du retrait d’argent, ils ne pourront utiliser que des transactions qui peuvent passer le contrôle OP_CTV correspondant, c’est-à-dire qu’ils ne pourront se payer qu’eux-mêmes le montant correspondant et ne pourront pas retirer de l’argent arbitrairement ; Les fonds restants iront dans un pool avec un verrou OP_CTV, garantissant ainsi que les utilisateurs restants peuvent être placés hors du pool sans confiance, quel que soit l’ordre dans lequel ils sont retirés.
Dans l’abstrait, le rôle d’OP_CTV ici est de planifier le chemin jusqu’à la fin de la vie du contrat pour le contrat, de sorte que le contrat de pool ici puisse maintenir l’attribut de sortie sans confiance, quel que soit le chemin qu’il emprunte ou l’état dans lequel il se trouve.
Il y a aussi une utilisation très intéressante de cette _CTV OP\ : « canal de paiement à sens unique qui est caché mais pas révélé ». Supposons qu’Alice forme un tel pool de fonds et garantisse que les fonds peuvent être retirés sans confiance dans une sortie avec le script suivant :
ou, Alice et Bob le passent ensemble
ou, au bout d’un certain temps, Alice peut le dépenser seule
Si Alice ne l’avait pas révélé à Bob, Bob n’aurait pas su qu’une telle sortie existait ; Une fois qu’Alice l’a révélé à Bob, Bob peut utiliser la sortie comme un canal de paiement unidirectionnel sensible au temps qu’Alice peut utiliser pour payer Bob immédiatement sans avoir à attendre la confirmation de la blockchain. Bob demande simplement à Alice de mettre sa transaction d’engagement sur la chaîne avant qu’Alice ne puisse la dépenser elle-même.
(b) OP_Vault et sûr
OP_VAULT est une proposition de clause restrictive spécifiquement conçue pour construire des « coffres-forts ».
Le contrat Vault est conçu pour être une forme plus sûre et plus avancée d’auto-garde. Bien que le contrat multi-signature actuel puisse éviter un point de défaillance unique pour une seule clé privée, si un attaquant obtient un nombre seuil de clés privées, le propriétaire du portefeuille est impuissant. Vault souhaite imposer une limite de dépense unique à vos fonds. Dans le même temps, lors d’un retrait d’argent par la voie normale, l’opération de retrait imposera un délai d’attente ; Et pendant la période d’attente, l’opération de retrait peut être interrompue par l’opération de récupération d’urgence du portefeuille. Même en cas de violation d’un tel contrat, le propriétaire du portefeuille peut lancer une contre-opération (en utilisant la branche de récupération d’urgence).
Théoriquement, OP_CTV\ peut également programmer un tel contrat, mais il y a de nombreux inconvénients, dont l’un est la commission : tout en s’engageant dans la transaction, il promet également les frais que la transaction paiera. Compte tenu de l’objet de ce contrat, l’intervalle de temps entre la mise en place du contrat et le retrait de l’argent doit être très long, il est donc presque impossible de prédire la commission appropriée. Bien que l’OP_CTV ne limite pas les intrants, de sorte que les frais peuvent être augmentés en augmentant les intrants, les intrants fournis deviendront tous la commission, ce qui est irréaliste ; Une autre façon est le CPFP, qui consiste à fournir une commission sur les nouvelles transactions en dépensant les fonds retirés. De plus, l’utilisation d’OP_CTV signifie qu’un tel contrat Vault ne peut pas être retiré en bloc (et ne peut certainement pas être restauré en bloc).
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ésilience par lots, nous ne le mentionnerons donc pas pour l’instant. OP_VAULT se comporte comme suit : lorsque nous le plaçons sur une branche de l’arborescence de scripts, il peut être utilisé pour s’engager dans un opcode utilisable (par exemple OP_CTV) sans paramètres spécifiques ; Lors de l’utilisation de cette branche, les transactions peuvent être transmises dans des paramètres spécifiques, mais pas dans d’autres branches. Par conséquent, il n’est pas nécessaire de fixer des frais prédéfinis et ceux-ci peuvent être définis lorsque la succursale est dépensée ; En supposant que la branche dispose également d’un verrou temporel, elle appliquera un verrou temporel ; Enfin, étant donné que vous ne pouvez modifier que la branche sur laquelle vous vous trouvez, et qu’aucune autre branche de la nouvelle arborescence de script (y compris la branche de récupération d’urgence) ne sera modifiée, nous sommes autorisés à interrompre ces retraits.
De plus, deux points méritent d’être mentionnés : (1) l’opcode OP_VAULT se comporte de la même manière qu’une autre proposition de restriction : OP_TLUV ; Jeremy Rubin souligne à juste titre que cela a donné naissance au concept de « calcul » dans une certaine mesure : OP_TLUV/OP_VAULT promet d’abord un opcode pour permettre au consommateur de mettre à jour l’ensemble de l’arborescence du script en passant des paramètres à l’opcode avec une nouvelle transaction ; Il ne s’agit plus de « valider les données entrantes en fonction de certains critères », mais de « générer de nouvelles données significatives à partir des données entrantes », bien que le calcul qu’il peut permettre soit limité.
(2) La proposition complète de l’OP_VAULT utilise également certaines des propositions sur la politique mempool (par exemple, les transactions v3) pour obtenir de meilleurs résultats. Cela nous rappelle que le sens de la « programmation » peut être plus large que nous ne le pensons. (Un exemple similaire est Open Transaction dans le réseau Nervos.) ）
V. Comprendre le CKB
Dans les deux sections ci-dessus, nous décrivons comment nous pouvons scripter des applications intéressantes sur une structure plus contrainte (Bitcoin UTXO) ; Des propositions visant à ajouter de l’introspection à une telle structure ont également été présentées.
Bien que les UTXO aient la capacité de programmer ces applications, il est facile pour les lecteurs de repérer leurs lacunes ou les domaines qui peuvent être optimisés, tels que :
Dans LN-Punishment, les participants au canal doivent enregistrer chaque transaction passée et la valeur secrète de pénalité correspondante afin de faire face à la fraude de l’adversaire, qui constitue une charge de stockage. S’il existe un mécanisme qui garantit que seule la transaction d’engagement la plus récente prendra effet, et que l’ancienne transaction d’engagement ne le sera pas, cela peut éliminer ce fardeau, et cela peut également éliminer le problème des nœuds qui sont accidentellement pénalisés pour avoir mis par erreur une transaction d’engagement plus ancienne sur la chaîne.
Dans le DLC, il est supposé qu’il y a de nombreux résultats possibles de l’événement, et qu’il y a beaucoup de signatures que les deux parties doivent générer et se remettre à l’avance à l’autre, ce qui est également un énorme fardeau ; De plus, les revenus du contrat DLC sont directement liés à la clé publique, donc sa position n’est pas facile à transférer, y a-t-il un moyen de transférer la position du contrat ?
En fait, la communauté Bitcoin a trouvé des réponses à ces questions, essentiellement liées à une proposition de Sighash (BIP-118 AnyPrevOut).
Cependant, si nous programmions sur CKB, BIP-118 serait disponible dès maintenant (de telles balises Sighash pourraient être simulées avec la possibilité de vérifier les signatures de manière introspective et ciblée).
En apprenant à programmer Bitcoin, nous savons non seulement comment ils peuvent être programmés au format « Transaction Output » (ce qui peut être programmé dans CKB), mais aussi comment améliorer ces applications (et comment nous pouvons utiliser les capacités de CKB pour les améliorer si nous les programmons sur CKB). Pour les développeurs de CKB, la programmation basée sur Bitcoin Script peut être utilisée comme matériel d’apprentissage, ou même comme raccourci.
Ci-dessous, analysons la programmabilité de chaque module de programmation CKB un par un. Ne considérons pas l’introspection pour l’instant.
(1) Serrure programmable calculée arbitrairement
Comme mentionné ci-dessus, les UTXO ne peuvent pas être programmés pour calculer arbitrairement. Lock, d’autre part, signifie que Lock peut tout programmer (avant le déploiement de la restriction) basé sur UTXO, y compris, mais sans s’y limiter, le Lightning Channel et le DLC mentionnés ci-dessus.
De plus, cette capacité à vérifier les calculs arbitraires rend également Lock plus flexible qu’UTXO en termes de méthodes d’authentification. Par exemple, nous pouvons mettre en œuvre un canal Lightning sur le CKB où une partie signe ECDSA et l’autre partie utilise RSA.
En fait, c’est l’un des premiers domaines que les gens ont commencé à explorer chez CKB : l’utilisation de cette capacité d’authentification flexible dans l’auto-garde de l’utilisateur pour permettre ce que l’on appelle « l’abstraction du compte » – l’autorisation de la validité de la transaction et la restauration du contrôle sont très flexibles et presque illimitées. En principe, il s’agit d’une combinaison de « succursales de dépenses multiples » et de « méthodes d’authentification arbitraires ». Exemples d’implémentations : joyid wallet, UniPass.
De plus, Lock peut mettre en œuvre des propositions eltoo, ce qui permet d’activer un canal Lightning qui n’a besoin que de conserver la dernière transaction validée (en fait, eltoo peut simplifier tous les contrats peer-to-peer).
(2) Type programmable calculé arbitrairement
Comme mentionné ci-dessus, l’une des principales utilisations de Type est de programmer des UDT. Combiné avec Lock, cela signifie que nous pouvons mettre en œuvre des canaux de foudre basés sur UDT (et d’autres types de contrats).
En fait, la scission entre Lock et Type peut être considérée comme une mise à niveau de la sécurité : Lock se concentre sur la mise en œuvre de méthodes de conservation ou d’accords contractuels, tandis que Type se concentre sur la définition des UDT.
De plus, la possibilité de lancer des vérifications basées 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 première classe).
Par exemple, l’auteur a déjà proposé un protocole pour mettre en œuvre des prêts sans confiance adossés à des NFT sur Bitcoin. La clé d’un tel protocole est une transaction engagée où la valeur de l’entrée est inférieure à la valeur de la sortie (il ne s’agit donc pas encore d’une transaction valide), mais une fois qu’une entrée suffisante peut être fournie pour la transaction, il s’agit d’une transaction valide : une fois que le prêteur est en mesure de rembourser, le prêteur ne peut pas prendre le NFT mis en jeu pour lui-même. Cependant, l’absence de confiance de cette transaction d’engagement est basée sur la vérification de la quantité d’entrée et de sortie de la transaction, de sorte que le prêteur ne peut utiliser Bitcoin que pour rembourser le prêt - même si le prêteur et le prêteur sont prêts à accepter une autre devise (comme l’USDT émis sous le protocole RVB), la transaction d’engagement Bitcoin ne garantit pas que le prêteur récupérera son NFT tant que le prêteur retourne le montant total de l’USDT, car la transaction Bitcoin n’a aucune idée du statut de l’USDT ! (Révision : En d’autres termes, il n’est pas possible de construire une transaction engagée sous réserve du remboursement de l’USDT.) ）
Si nous sommes en mesure d’initier un chèque basé sur la définition de l’UDT, nous serons en mesure d’obtenir du prêteur qu’il signe une autre transaction engagée qui lui permettra d’utiliser l’USDT pour rembourser le prêt. La transaction vérifiera le montant d’USDT saisi et le montant d’USDT sortant, offrant aux utilisateurs un remboursement sans confiance avec USDT.
Amendement : En supposant que le NFT utilisé comme garantie et le jeton utilisé pour le remboursement sont émis en utilisant le même protocole (tel que RVB), alors le problème ici peut être résolu, et nous pouvons construire une transaction d’engagement selon le protocole RVB, de sorte que la transition d’état et le remboursement du NFT puissent se produire simultanément (deux transitions d’état sont liées à des transactions dans le protocole RVB). Cependant, étant donné que les transactions RVB reposent également sur des transactions Bitcoin, la construction de transactions d’engagement ici sera quelque peu difficile. Dans l’ensemble, bien que le problème puisse être résolu, cela ne peut pas être fait Token est un citoyen de première classe.
Ensuite, considérons l’introspection.
(3) Le verrou lit les autres verrous
Cela signifie que toute la gamme des possibilités de programmation sur les UTXO Bitcoin après la mise en œuvre de la restriction proposée est mise en œuvre. Cela inclut les contrats Vault mentionnés ci-dessus, ainsi que les applications basées sur OP_CTV (par exemple, le contrôle de congestion).
XueJie a mentionné une fois un exemple très intéressant : vous pouvez implémenter une cellule de compte de recouvrement sur CKB, lorsque vous utilisez ce type de cellule comme entrée de la transaction, si la cellule de sortie (la cellule utilisant le même verrou) a plus de capacité, alors l’entrée n’a pas besoin de fournir de signature et n’affecte pas la validité de la transaction. En fait, ce type de cellule ne serait pas possible sans la capacité d’introspection. Cette cellule de compte de recouvrement est idéale comme méthode institutionnelle pour recevoir de l’argent car elle mutualise les fonds et présente l’inconvénient de ne pas avoir un bon sens de la vie privée.
(4) Le verrou lit d’autres types (et données)
Une application intéressante de cette fonctionnalité est celle des tokens de stake. Lock décidera s’il peut utiliser sa propre capacité en fonction du nombre de jetons dans les autres entrées, et où il peut être dépensé (nécessite la possibilité de verrouiller l’introspection).
(5) Le type lit les autres verrous
Je ne sais pas, mais on peut supposer qu’il est utile. Par exemple, vous pouvez vérifier dans Type que les verrous des entrées et sorties d’une transaction restent inchangés.
(6) Le type Scirpt lit les autres types (et données)
Des cartes à collectionner ? Collectez n jetons en échange d’un jeton plus important :)
VI. En conclusion
Par rapport aux systèmes de contrats intelligents précédents qui peuvent être programmés avec des calculs arbitraires, tels qu’Ethereum, Nervos Network adopte une structure différente ; Par conséquent, il est souvent difficile de comprendre le réseau Nervos sur la base de la connaissance des systèmes de contrats intelligents du passé. 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. Et, en utilisant le concept d'« introspection » pour comprendre les capacités d'« accès aux contrats croisés » des cellules, nous pouvons diviser les situations dans lesquelles les capacités d’introspection sont utilisées et déterminer leurs utilisations spécifiques.
Recension :
Quelles que soient les capacités d’accès croisé de la cellule (c’est-à-dire les capacités d’introspection), les verrous peuvent être considérés comme des bitcoins avec des capacités d’état et de programmation qui ont atteint l’extrême, de sorte que toutes les applications basées sur Bitcoin peuvent être programmées sur cette seule base ;
Quelle que soit la capacité d’accès croisé (c’est-à-dire la capacité d’introspection) de la cellule, la distinction entre les verrous et les types peut être considérée comme une mise à niveau de la sécurité : elle sépare la définition des actifs et la méthode de conservation de l’UDT ; De plus, le type s (et les données) de l’état exposable atteignent l’effet de l’UDT est un citoyen de première classe.
Les deux points ci-dessus signifient quelque chose avec le même paradigme que « BTC + RGB » mais avec plus de capacités de programmation ;
Compte tenu de la capacité introspective de Cell, Cell peut obtenir des capacités de programmation plus fortes que les BTC UTXO post-covenants et mettre en œuvre quelque chose qui est difficile à réaliser avec BTC + RGB (car BTC ne peut pas lire l’état de RGB)
Il n’y a pas beaucoup d’exemples précis de ces utilisations, mais cela est dû au manque de compréhension de l’auteur de l’écologie du CKB. Au fil du temps, on pense que de plus en plus d’imagination sera investie dans ce domaine, et que des applications inimaginables aujourd’hui seront mises en place.
Remerciements
Merci à Retric, Jan Xie et Xue Jie pour leurs commentaires lors de la rédaction de l’article. Bien sûr, je suis responsable de toutes les erreurs dans le texte.
Les composants qui construisent le contrat sont mis à niveau avec Bitcoin
Eltoo a expliqué
Un contrat de prêt garanti NFT basé sur des transactions engagées · btc-study/OP_QUESTION · Discussion #7
Lien vers l’article original
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Comprendre la programmabilité de CKB à partir de la programmation d’applications Bitcoin
Auteur original : Ajian
Résumé
Pour comprendre la programmabilité d’un système, il faut identifier les caractéristiques structurelles du système. L’exploration de la programmation d’applications basée sur Bitcoin Script nous aide à comprendre la structure de base de CKB Cell et son paradigme de programmation. Non seulement cela, mais il décompose les composants de programmation du CKB en bons morceaux et nous aide à comprendre les gains de programmabilité que chaque partie apporte.
I. Préambule
La « programmabilité » est une dimension que les gens prennent souvent lorsqu’ils comparent des systèmes blockchain. Cependant, il y a souvent un désaccord sur la façon dont la programmabilité est décrite. Une expression courante est « La blockchain XX prend en charge les langages de programmation Turing-complets », ou « La blockchain XX prend en charge la programmation à usage général », ce qui est destiné à indiquer que la « blockchain XX » a ici une forte programmabilité. Il y a une part de vérité dans l’implication de ces affirmations : les systèmes qui prennent en charge la programmation Turing-complète sont généralement plus faciles à programmer que ceux qui ne le font pas. Cependant, les caractéristiques structurelles d’un système de contrats intelligents comportent de nombreux aspects, et cette déclaration ne touche qu’à l’un d’entre eux, de sorte qu’il ne suffit pas de le comprendre suffisamment en profondeur en raison du fait que les développeurs ne sont pas guidés par celui-ci et que l’on ne peut pas compter sur les utilisateurs ordinaires pour distinguer la fraude.
Les caractéristiques structurelles d’un système de contrat intelligent sont les suivantes :
Par conséquent, en plus du « calcul arbitraire programmable », il existe au moins 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 à réaliser et ce qui est difficile à réaliser ; Qu’est-ce qu’une mise en œuvre plus économique et qu’est-ce qu’une mise en œuvre moins efficace ?
Par exemple, Ethereum est souvent cité comme un exemple de bonne programmabilité, mais la forme de base de l’expression d’état sur Ethereum est un compte, ce qui rend difficile la programmation de contrats peer-to-peer (par exemple, les passerelles de paiement, les contrats de paris en tête-à-tête) – pas absolument impossible, juste ingrat. Il n’est pas rare que l’écosystème Ethereum essaie de mettre en œuvre un canal de paiement/canal d’État, et il y a eu beaucoup de discussions théoriques, mais ces projets ne semblent plus être actifs – et cela ne peut évidemment pas être imputé au manque d’efforts de la part des développeurs. Ce n’est pas un hasard si les projets actifs sur Ethereum prennent aujourd’hui la forme de « pools » plutôt que de « contrats peer-to-peer ». De même, les gens peuvent être satisfaits de la programmabilité d’Ethereum, mais le modèle de compte est intrinsèquement déficient pour réaliser « l’abstraction de compte » (ce qui peut également être compris comme une généralisation du concept de portefeuille).
De la même manière, l’exploration de la programmabilité de CKB nécessite également de 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 de programmer des calculs arbitraires, d’enregistrer un état supplémentaire dans un contrat et de permettre à un contrat d’accéder à l’état d’un autre contrat lorsqu’il est exécuté. Cependant, la forme du contrat est le résultat d’une transaction (appelée « cellule »), ce qui le rend fondamentalement différent d’Ethereum. Par conséquent, une compréhension du système de contrats intelligents Ethereum et des instances de contrat qu’il contient ne nous aide pas à comprendre comment CKB implémente ces caractéristiques structurelles, ni à comprendre la programmabilité de CKB.
Heureusement, les contrats intelligents sur Bitcoin semblent fournir la meilleure base pour comprendre la programmabilité de CKB. Ce n’est pas seulement parce que la forme de base de la représentation de l’état de Bitcoin est également la sortie de transactions (appelées « UTXO »), mais aussi parce que, à l’aide d’un concept proposé par la communauté Bitcoin appelé « covenants », nous pouvons comprendre pourquoi CKB a ces caractéristiques structurelles, et décomposer de manière appropriée l’effet final en plusieurs parties, en identifiant les gains de programmabilité que chacune d’entre elles apporte.
II. CKB v.s. BTC : Quoi de plus ?
(1) Structure de base
En tant que forme de base de la représentation de l’état de Bitcoin, l’UTXO (« Unspent Transaction Output ») de Bitcoin comporte deux champs :
Comparé aux systèmes de contrats intelligents qui sont venus plus tard, Bitcoin Script est assez limité :
Ce type de script, bien que limité, ne manque pas de capacité à programmer des applications étonnantes, et c’est la base de notre exploration de la programmabilité CKB. Il y aura une section plus tard qui présentera deux exemples de programmation Bitcoin Script.
En revanche, l’unité d’état du CKB est appelée « cellule » et comporte quatre champs :
De plus, Lock et Type peuvent être programmés pour des calculs arbitraires. Vous pouvez programmer n’importe quel algorithme de vérification de signature, vous pouvez programmer n’importe quel algorithme de hachage pour la vérification de la préimage, etc.
Il est facile pour les lecteurs de voir comment la programmabilité de Cell s’améliore par rapport aux UTXO :
Combinés à la structure de « sortie de transaction » de la cellule elle-même, les avantages de ces deux points en eux-mêmes sont très, très significatifs, mais à partir de la seule description ci-dessus, nous ne savons pas comment la cellule atteint « un contrat accède à l’état d’un autre contrat au moment de l’exécution ». Pour ce faire, nous devons nous inspirer d’un concept qui fait l’objet de discussions de longue date dans la communauté Bitcoin : les « covenants ».
(2) Limites et introspection
L’objectif initial d’une clause de restriction est de limiter les endroits où une somme d’argent peut être dépensée. Sur Bitcoin actuel (où aucune restriction n’a été proposée), une seule somme d’argent, une fois débloquée, peut être dépensée n’importe où (elle peut être payée à une clé publique de script arbitraire). Mais l’idée de la clause de restriction est qu’il peut être dépensé d’une manière qui le limite à certains endroits, par exemple, un certain UTXO ne sera dépensé que par une certaine transaction, de sorte que même si quelqu’un peut fournir une signature pour l’UTXO, l’endroit où il peut être dépensé a déjà été déterminé par cette transaction. Cela peut sembler un peu étrange, mais cela peut conduire à des applications intéressantes, qui seront abordées dans une section plus tard. Il est important de noter qu’il s’agit d’un élément clé pour mieux comprendre la programmabilité de CKB.
Rusty Russell souligne à juste titre qu’une restriction peut être comprise comme une capacité d’introspection à trader, c’est-à-dire que lorsqu’un UTXO A est dépensé par une transaction B, un opérateur de script peut lire une partie (ou la totalité) de la transaction B et ensuite vérifier qu’ils correspondent aux paramètres pré-demandés par le script. Par exemple, si la clé publique de script pour la première sortie de la transaction A correspond à ce qui est requis par la clé publique de script d’UTXO A (c’est ce que la restriction signifiait à l’origine).
Le lecteur astucieux se rendra compte qu’avec une introspection complète, l’entrée d’une transaction peut lire l’état d’une autre entrée de la même transaction, ce qui permet à un contrat d’accéder à l’état d’un autre contrat au moment de l’exécution. En fait, c’est exactement comme cela que CKB Cell a été conçu.
Sur cette base, nous pouvons diviser cette capacité introspective complète en quatre scénarios :
Cela nous permet d’analyser le rôle des capacités introspectives de chaque pièce dans différents cas d’utilisation sous certaines hypothèses (la division des fonctions entre Lock et Type), c’est-à-dire le gain de programmabilité que chaque partie nous apporte.
Dans les deux sections suivantes, nous examinerons la programmation actuelle (et pas encore proposée) de Bitcoin Script, et les fonctionnalités probables que la restriction proposée devrait atteindre, afin de donner une compréhension concrète de la façon dont CKB Cell peut être programmé et amélioré.
III. Programmation de scripts Bitcoin
Dans cette section, nous utiliserons « Lightning Channel/Lightning Network » et « Caution Journal Contract (DLC) » comme exemples de programmation d’applications basées sur Bitcoin Script. Avant d’entrer dans le vif du sujet, prenons deux choses en considération.
(1) OP_IF et « Accords d’engagement »
Le premier concept est l’opcode de contrôle de flux en Bitcoin Script, tel que : OP_IF, OP_ELSE. Ces opcodes ne sont pas différents de IF en programmation informatique, et leur but est d’exécuter différentes instructions basées sur différentes entrées. Dans le contexte de Bitcoin Script, cela signifie que nous pouvons définir plusieurs chemins de déverrouillage pour les fonds ; Combiné à la fonction de verrouillage du temps, cela signifie que nous pouvons attribuer une priorité aux actions.
Prenons l’exemple du fameux « Hash Timelock Contract (HTLC) », qui se traduit en langue vernaculaire :
Ce « ou ... ou ... L’effet est obtenu grâce à l’opcode de contrôle de processus.
L’avantage le plus important de > HTLC est qu’il peut regrouper plusieurs opérations et les atomiser. Par exemple, si Alice veut échanger des BTC contre des CKB avec Bob, Bob peut d’abord donner une valeur de hachage et créer un HTLC sur le réseau Nervos. Alice crée ensuite un HTLC sur Bitcoin qui utilise le même hachage. Alternativement, Bob prend les BTC payés par Alice sur Bitcoin, tout en révélant la préimage, permettant à Alice de retirer des CKB sur le réseau Nervos. Quoi qu’il en soit, Bob ne révèle pas l’image originale, les deux contrats expirent et Alice et Bob peuvent récupérer l’argent qu’ils ont investi.
Après l’activation du soft fork de Taproot, cette fonctionnalité de chemin multi-déverrouillé est encore améliorée par l’introduction de MAST (Merkle Abstract Syntax Tree) : nous pouvons transformer un chemin de déverrouillage en une feuille sur l’arbre de Merkle, chaque feuille est indépendante, il n’est donc plus nécessaire d’utiliser un tel opcode de contrôle de flux ; De plus, comme un chemin est révélé sans exposer les autres, nous pouvons ajouter un plus grand nombre de chemins de déverrouillage à une sortie sans avoir à nous soucier de l’économie.
Le deuxième concept est le « trading d’engagement ». L’idée d’une transaction engagée est que, dans certains cas, une transaction Bitcoin valide, même si elle n’est pas confirmée par la blockchain, est tout aussi réelle et contraignante.
Par exemple, Alice et Bob partagent un UTXO qui nécessite qu’ils soient tous les deux signés pour dépenser. À ce stade, Alice construit une transaction pour le dépenser, transférant 60% de sa valeur à Bob et le reste à elle-même ; Alice fournit sa propre signature pour la transaction, qui est ensuite envoyée à Bob. Eh bien, pour Bob, il n’est pas nécessaire qu’il soit diffusé sur le réseau Bitcoin, et il n’a pas besoin d’être confirmé par la blockchain, et l’effet de paiement de cette transaction est également réel et crédible. Parce qu’Alice ne peut pas dépenser l’UTXO seule (et ne peut donc pas le dépenser à plusieurs reprises), et parce que la signature fournie par Alice est valide, Bob peut toujours ajouter sa signature et diffuser la transaction pour honorer le paiement. En d’autres termes, Alice a fourni à Bob un « engagement crédible » par le biais de cette transaction valide (hors chaîne).
Les transactions engagées sont un concept central de la programmation d’applications Bitcoin. Comme mentionné précédemment, le contrat de Bitcoin est basé sur la vérification, apatride et ne permet pas l’accès croisé ; Cependant, si le contrat ne comporte pas d’États, où ces États sont-ils stockés, et comment le contrat peut-il aller de l’avant en toute sécurité (changer 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 enregistrer eux-mêmes l’état sans avoir à l’afficher sur la blockchain ; Le problème de la modification de l’état du contrat peut également être transformé en problème de la mise à jour en toute sécurité de la transaction validée ; De plus, si nous sommes préoccupés par les dangers de la conclusion d’un contrat (par exemple, la conclusion d’un contrat qui exige que les deux parties signent pour dépenser, et qu’il y ait un risque que l’autre partie ne réponde pas et reste coincée), alors le simple fait de générer une transaction d’engagement qui coûte le contrat à l’avance et d’obtenir une signature peut atténuer le risque et éliminer la confiance dans les autres participants.
(2) Canal Lightning et réseau Lightning
Un canal Lightning est un contrat one-to-one dans lequel deux parties peuvent se payer un nombre illimité de fois sans qu’aucun paiement ne soit confirmé par la blockchain. Comme vous pouvez vous y attendre, il utilise le trading d’engagement.
Dans la section expliquant « Transactions validées », nous avons déjà introduit un canal de paiement. Cependant, ce type de contrat, qui ne s’appuie que sur le multisig 2 sur 2, ne peut permettre que des paiements aller simple. C’est-à-dire que soit Alice paie toujours Bob, soit Bob paie toujours Alice jusqu’à ce qu’il utilise son solde dans le contrat. S’il s’agit d’un paiement bidirectionnel, cela signifie qu’après une mise à jour de statut, l’une des parties peut avoir moins de solde qu’auparavant, mais que l’AT a la dernière transaction engagée signée par l’autre partie - que peut-on faire pour empêcher l’AT de diffuser l’ancienne promesse et l’AT uniquement la transaction d’engagement la plus récente ?
La solution à ce problème avec le canal de foudre s’appelle « LN-Penalty ». Maintenant, disons qu’Alice et Bob ont chacun 5 BTC dans un canal ; Maintenant, Alice veut payer 1 BTC à Bob, alors elle signe la transaction promise et l’envoie à Bob :
Bob signe également un engagement (qui correspond à la transaction ci-dessus) et l’envoie à Alice :
L’astuce ici réside dans cette « clé publique temporaire conjointe », qui est générée à l’aide de l’une de ses propres clés publiques et d’une clé publique fournie par l’autre partie, par exemple, la clé publique temporaire conjointe Alice-Bob, qui est obtenue par Alice à l’aide de l’une de ses propres clés publiques et d’une clé publique fournie par Bob, en multipliant chacune par une valeur de hachage. Lorsqu’une telle clé publique est générée, personne ne connaît sa clé privée. Toutefois, 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 fédérée. - C’est la clé du fait que le Lightning Channel peut « annuler » l’ancien état.
La prochaine fois que les deux parties voudront mettre à jour le statut de la chaîne (initier un paiement), les deux parties échangeront la clé privée de la clé publique temporaire qui leur a été donnée lors du tour précédent. De cette façon, les participants n’osent plus diffuser la dernière transaction promise qu’ils ont reçue : la sortie de cette transaction promise attribuant de la valeur à leur propre partie a deux chemins, et la clé privée du chemin de clé publique temporaire est déjà connue de l’autre partie ; Ainsi, une fois que l’ancienne transaction d’engagement est diffusée, l’autre partie peut immédiatement utiliser cette clé privée temporaire conjointe pour prendre tous les fonds de cette sortie. - C’est ce que signifie « LN-Pénalité ».
Plus précisément, l’ordre d’interaction est le suivant : la partie qui initie le paiement demande d’abord une nouvelle clé publique temporaire à l’autre partie, puis construit une nouvelle transaction d’engagement et la remet à l’autre partie ; La partie qui a obtenu la transaction promise a révélé à l’autre partie la clé privée de la clé publique temporaire qu’elle avait donnée au tour précédent. Cette séquence d’interactions garantit que les participants obtiennent toujours une nouvelle transaction d’engagement avant d’invalider la transaction d’engagement qu’ils ont reçue lors du tour précédent, et est donc sans confiance.
En résumé, les principales conceptions du canal de foudre sont les suivantes :
Enfin, étant donné que HTLC peut également être placé dans une transaction validée, le canal Lightning peut également transférer des paiements. En supposant qu’Alice puisse trouver un chemin composé de canaux Lightning se connectant avant et après pour atteindre Daniel, alors des paiements multi-sauts sans confiance peuvent être réalisés sans ouvrir de canal avec Daniel. Il s’agit du Lightning Network :
Quand Alice trouve un tel chemin et veut payer Daniel, elle demande à Daniel un hachage pour construire un HTLC pour Bob, et demande à Bob de transmettre un message à Carol et de fournir le même HTLC ; Le message invite Carol à transférer le message à Daniel et à fournir le même HTLC. Lorsque la nouvelle parvient à Daniel, il révèle la préimage à Carol, ce qui lui donne la valeur de HTLC et met à jour l’état du contrat. Carol a fait de même, en se faisant payer par Bob et en mettant à jour le statut de la chaîne. Finalement, Bob révèle la préimage à Alice et met à jour le statut. En raison de la nature de HTLC, cette chaîne de paiements réussit ou échoue ensemble et, en tant que telle, elle n’est pas fiable.
Le Lightning Network est composé d’un canal après l’autre, chacun d’entre eux étant indépendant l’un de l’autre. Cela signifie qu’Alice n’a besoin que de savoir ce qui se passe dans sa chaîne avec Bob, quel que soit le nombre d’interactions qui ont eu lieu dans les chaînes d’autres personnes, la devise utilisée par ces interactions, ou même si elles utilisent réellement la chaîne.
L’évolutivité du réseau Lightning ne se reflète pas seulement dans le fait que la vitesse de paiement au sein d’un canal Lightning n’est limitée que par l’investissement de ressources matérielles par les deux parties, mais aussi par le fait qu’en raison du stockage décentralisé de l’état, un seul nœud peut tirer parti de l’effet de levier maximal au coût le plus bas.
(3) Méfiez-vous des contrats de journaux
Le contrat DLC (Cautionary Journaling Contract) utilise une technique cryptographique appelée « signature d’adaptateur » qui permet à Bitcoin Script de programmer des contrats financiers qui dépendent d’événements externes.
Les signatures d’adaptateur permettent à une signature de devenir une signature valide uniquement après l’ajout d’une clé privée. Prenons l’exemple d’une signature de Schnorr, où la forme standard d’une signature de Schnorr est (R, s), où :
Supposons que je donne une paire de données (R, s') où :
Évidemment, ce n’est pas une signature Schnorr valide, et elle ne passe pas la formule de validation, mais je peux prouver au vérificateur qu’elle peut être une signature valide en connaissant simplement la clé privée de R 2, r 2 :
Les signatures d’adaptateur font dépendre la validité d’une signature d’une donnée secrète et sont vérifiables. 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 baseball. Alice et Bob ont parié sur la victoire du Bouffon Vert et d’Alina, respectivement, avec un pari de 1 BTC. De plus, Carol, un site Web de critiques de football, a promis d’utiliser un nonce R_c pour publier un s_c_i signé des résultats lorsque les résultats du match ont été annoncés.
Comme on peut le voir, il y a trois issues possibles (il y a donc 3 possibilités pour la signature de Carol) :
Le Bouffon Vert gagne, Alice gagne 1 BTC
Alina gagne, et Bob gagne 1 BTC
Égalité, les fonds des deux rapportent de la même manière
Pour ce faire, les deux créent un accord d’engagement pour chaque résultat. Par exemple, la transaction d’engagement qu’ils ont créée pour le premier résultat ressemblerait à ceci :
Cependant, au lieu de (R, s), la signature qu’Alice et Bob ont créée pour cette transaction est une signature d’adaptateur (R, s') ; En d’autres termes, les signatures données par les deux parties ne peuvent pas être utilisées directement pour débloquer le contrat, mais doivent révéler une valeur secrète. Cette valeur secrète est la préimage de s_c_ 1.G, qui est la signature de Carol ! Puisque la valeur de nonce de signature de Carol a été déterminée (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 les résultats sont révélés, en supposant que le Bouffon Vert gagne, Carol émettra une signature (R_c, s_c_ 1), afin qu’Alice ou Bob puissent compléter la signature de l’adaptateur de l’adversaire et ajouter leur propre signature pour faire de la transaction ci-dessus une transaction valide, et la diffuser sur le réseau pour déclencher l’effet de règlement. Mais si le Bouffon Vert ne gagne pas, Carol ne postera pas s_c_ 1, et l’accord d’engagement ne sera pas un accord valide.
Et ainsi de suite, comme le sont les deux autres métiers. De cette façon, Alice et Bob font dépendre l’exécution du contrat d’événements extérieurs (pour être précis, de la diffusion d’événements externes par la machine assertor, sous la forme d’une signature) sans avoir à faire confiance à la contrepartie. Les grands et les petits contrats financiers, 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 caractéristique la plus importante 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 en rien l’exécution du contrat ; (2) Les observateurs on-chain (y compris Carol) ne seront pas en mesure de déterminer quel site Web ils utilisent grâce à l’exécution du contrat d’Alice et Bob, ou même si leur contrat est un contrat de pari (et non un canal éclair).
IV. Introduction à l’application des restrictions
(a) OP_CTV et contrôle de la congestion
Les développeurs de la communauté Bitcoin ont fait un certain nombre de propositions qui peuvent être classées comme des clauses restrictives. À l’heure actuelle, l’une des propositions les plus connues est OP_CHECKTEMPLATEVERIFY (OP_CTV), qui est populaire auprès de la communauté Bitcoin pour sa simplicité mais sa flexibilité avec son concept simple. L’idée de OP_CTV est de valider un hachage dans le script pour contraindre que les fonds ne peuvent être dépensés que par les transactions représentées par ce hachage ; Ce hachage promet la sortie de la transaction et la plupart des champs, mais pas l’entrée de la transaction, seulement le nombre d’entrées.
Le « contrôle de la congestion » est un bon exemple de la façon dont l’OP_CTV peut être démontré. Son cas d’utilisation de base est d’aider un grand nombre d’utilisateurs à sortir d’un échange (un environnement qui nécessite la confiance) dans un pool ; Étant donné que ce pool utilise OP_CTV pour planifier la façon dont il sera dépensé à l’avenir, il garantit que les utilisateurs peuvent quitter le pool sans confiance, sans l’aide de personne ; Et comme ce pool ne se comporte que comme un UTXO, il évite de payer beaucoup de frais lorsque la demande de transactions on-chain est élevée (de n sorties à 1 sortie ; également réduit de n transactions à 1 transaction). Les utilisateurs du pool peuvent attendre une opportunité pour sortir du pool.
Supposons qu’Alice, Bob et Carol veuillent retirer respectivement 5 BTC, 3 BTC et 2 BTC de l’échange. Ensuite, l’échange peut faire une sortie de 10 BTC avec 3 branches OP_CTV. 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 la branche formera deux sorties, dont l’une consiste à allouer 5 BTC à Alice ; L’autre sortie, à son tour, est un pool, qui utilise également OP_CTV pour s’engager dans une transaction, ce qui permet à Bob de retirer seulement 3 BTC et d’envoyer les 2 BTC restants à Carol.
C’est la même chose si Bob ou Carol veut retirer de l’argent. Lors du retrait d’argent, ils ne pourront utiliser que des transactions qui peuvent passer le contrôle OP_CTV correspondant, c’est-à-dire qu’ils ne pourront se payer qu’eux-mêmes le montant correspondant et ne pourront pas retirer de l’argent arbitrairement ; Les fonds restants iront dans un pool avec un verrou OP_CTV, garantissant ainsi que les utilisateurs restants peuvent être placés hors du pool sans confiance, quel que soit l’ordre dans lequel ils sont retirés.
Dans l’abstrait, le rôle d’OP_CTV ici est de planifier le chemin jusqu’à la fin de la vie du contrat pour le contrat, de sorte que le contrat de pool ici puisse maintenir l’attribut de sortie sans confiance, quel que soit le chemin qu’il emprunte ou l’état dans lequel il se trouve.
Il y a aussi une utilisation très intéressante de cette _CTV OP\ : « canal de paiement à sens unique qui est caché mais pas révélé ». Supposons qu’Alice forme un tel pool de fonds et garantisse que les fonds peuvent être retirés sans confiance dans une sortie avec le script suivant :
Si Alice ne l’avait pas révélé à Bob, Bob n’aurait pas su qu’une telle sortie existait ; Une fois qu’Alice l’a révélé à Bob, Bob peut utiliser la sortie comme un canal de paiement unidirectionnel sensible au temps qu’Alice peut utiliser pour payer Bob immédiatement sans avoir à attendre la confirmation de la blockchain. Bob demande simplement à Alice de mettre sa transaction d’engagement sur la chaîne avant qu’Alice ne puisse la dépenser elle-même.
(b) OP_Vault et sûr
OP_VAULT est une proposition de clause restrictive spécifiquement conçue pour construire des « coffres-forts ».
Le contrat Vault est conçu pour être une forme plus sûre et plus avancée d’auto-garde. Bien que le contrat multi-signature actuel puisse éviter un point de défaillance unique pour une seule clé privée, si un attaquant obtient un nombre seuil de clés privées, le propriétaire du portefeuille est impuissant. Vault souhaite imposer une limite de dépense unique à vos fonds. Dans le même temps, lors d’un retrait d’argent par la voie normale, l’opération de retrait imposera un délai d’attente ; Et pendant la période d’attente, l’opération de retrait peut être interrompue par l’opération de récupération d’urgence du portefeuille. Même en cas de violation d’un tel contrat, le propriétaire du portefeuille peut lancer une contre-opération (en utilisant la branche de récupération d’urgence).
Théoriquement, OP_CTV\ peut également programmer un tel contrat, mais il y a de nombreux inconvénients, dont l’un est la commission : tout en s’engageant dans la transaction, il promet également les frais que la transaction paiera. Compte tenu de l’objet de ce contrat, l’intervalle de temps entre la mise en place du contrat et le retrait de l’argent doit être très long, il est donc presque impossible de prédire la commission appropriée. Bien que l’OP_CTV ne limite pas les intrants, de sorte que les frais peuvent être augmentés en augmentant les intrants, les intrants fournis deviendront tous la commission, ce qui est irréaliste ; Une autre façon est le CPFP, qui consiste à fournir une commission sur les nouvelles transactions en dépensant les fonds retirés. De plus, l’utilisation d’OP_CTV signifie qu’un tel contrat Vault ne peut pas être retiré en bloc (et ne peut certainement pas être restauré en bloc).
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ésilience par lots, nous ne le mentionnerons donc pas pour l’instant. OP_VAULT se comporte comme suit : lorsque nous le plaçons sur une branche de l’arborescence de scripts, il peut être utilisé pour s’engager dans un opcode utilisable (par exemple OP_CTV) sans paramètres spécifiques ; Lors de l’utilisation de cette branche, les transactions peuvent être transmises dans des paramètres spécifiques, mais pas dans d’autres branches. Par conséquent, il n’est pas nécessaire de fixer des frais prédéfinis et ceux-ci peuvent être définis lorsque la succursale est dépensée ; En supposant que la branche dispose également d’un verrou temporel, elle appliquera un verrou temporel ; Enfin, étant donné que vous ne pouvez modifier que la branche sur laquelle vous vous trouvez, et qu’aucune autre branche de la nouvelle arborescence de script (y compris la branche de récupération d’urgence) ne sera modifiée, nous sommes autorisés à interrompre ces retraits.
De plus, deux points méritent d’être mentionnés : (1) l’opcode OP_VAULT se comporte de la même manière qu’une autre proposition de restriction : OP_TLUV ; Jeremy Rubin souligne à juste titre que cela a donné naissance au concept de « calcul » dans une certaine mesure : OP_TLUV/OP_VAULT promet d’abord un opcode pour permettre au consommateur de mettre à jour l’ensemble de l’arborescence du script en passant des paramètres à l’opcode avec une nouvelle transaction ; Il ne s’agit plus de « valider les données entrantes en fonction de certains critères », mais de « générer de nouvelles données significatives à partir des données entrantes », bien que le calcul qu’il peut permettre soit limité.
(2) La proposition complète de l’OP_VAULT utilise également certaines des propositions sur la politique mempool (par exemple, les transactions v3) pour obtenir de meilleurs résultats. Cela nous rappelle que le sens de la « programmation » peut être plus large que nous ne le pensons. (Un exemple similaire est Open Transaction dans le réseau Nervos.) ）
V. Comprendre le CKB
Dans les deux sections ci-dessus, nous décrivons comment nous pouvons scripter des applications intéressantes sur une structure plus contrainte (Bitcoin UTXO) ; Des propositions visant à ajouter de l’introspection à une telle structure ont également été présentées.
Bien que les UTXO aient la capacité de programmer ces applications, il est facile pour les lecteurs de repérer leurs lacunes ou les domaines qui peuvent être optimisés, tels que :
En fait, la communauté Bitcoin a trouvé des réponses à ces questions, essentiellement liées à une proposition de Sighash (BIP-118 AnyPrevOut).
Cependant, si nous programmions sur CKB, BIP-118 serait disponible dès maintenant (de telles balises Sighash pourraient être simulées avec la possibilité de vérifier les signatures de manière introspective et ciblée).
En apprenant à programmer Bitcoin, nous savons non seulement comment ils peuvent être programmés au format « Transaction Output » (ce qui peut être programmé dans CKB), mais aussi comment améliorer ces applications (et comment nous pouvons utiliser les capacités de CKB pour les améliorer si nous les programmons sur CKB). Pour les développeurs de CKB, la programmation basée sur Bitcoin Script peut être utilisée comme matériel d’apprentissage, ou même comme raccourci.
Ci-dessous, analysons la programmabilité de chaque module de programmation CKB un par un. Ne considérons pas l’introspection pour l’instant.
(1) Serrure programmable calculée arbitrairement
Comme mentionné ci-dessus, les UTXO ne peuvent pas être programmés pour calculer arbitrairement. Lock, d’autre part, signifie que Lock peut tout programmer (avant le déploiement de la restriction) basé sur UTXO, y compris, mais sans s’y limiter, le Lightning Channel et le DLC mentionnés ci-dessus.
De plus, cette capacité à vérifier les calculs arbitraires rend également Lock plus flexible qu’UTXO en termes de méthodes d’authentification. Par exemple, nous pouvons mettre en œuvre un canal Lightning sur le CKB où une partie signe ECDSA et l’autre partie utilise RSA.
En fait, c’est l’un des premiers domaines que les gens ont commencé à explorer chez CKB : l’utilisation de cette capacité d’authentification flexible dans l’auto-garde de l’utilisateur pour permettre ce que l’on appelle « l’abstraction du compte » – l’autorisation de la validité de la transaction et la restauration du contrôle sont très flexibles et presque illimitées. En principe, il s’agit d’une combinaison de « succursales de dépenses multiples » et de « méthodes d’authentification arbitraires ». Exemples d’implémentations : joyid wallet, UniPass.
De plus, Lock peut mettre en œuvre des propositions eltoo, ce qui permet d’activer un canal Lightning qui n’a besoin que de conserver la dernière transaction validée (en fait, eltoo peut simplifier tous les contrats peer-to-peer).
(2) Type programmable calculé arbitrairement
Comme mentionné ci-dessus, l’une des principales utilisations de Type est de programmer des UDT. Combiné avec Lock, cela signifie que nous pouvons mettre en œuvre des canaux de foudre basés sur UDT (et d’autres types de contrats).
En fait, la scission entre Lock et Type peut être considérée comme une mise à niveau de la sécurité : Lock se concentre sur la mise en œuvre de méthodes de conservation ou d’accords contractuels, tandis que Type se concentre sur la définition des UDT.
De plus, la possibilité de lancer des vérifications basées 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 première classe).
Par exemple, l’auteur a déjà proposé un protocole pour mettre en œuvre des prêts sans confiance adossés à des NFT sur Bitcoin. La clé d’un tel protocole est une transaction engagée où la valeur de l’entrée est inférieure à la valeur de la sortie (il ne s’agit donc pas encore d’une transaction valide), mais une fois qu’une entrée suffisante peut être fournie pour la transaction, il s’agit d’une transaction valide : une fois que le prêteur est en mesure de rembourser, le prêteur ne peut pas prendre le NFT mis en jeu pour lui-même. Cependant, l’absence de confiance de cette transaction d’engagement est basée sur la vérification de la quantité d’entrée et de sortie de la transaction, de sorte que le prêteur ne peut utiliser Bitcoin que pour rembourser le prêt - même si le prêteur et le prêteur sont prêts à accepter une autre devise (comme l’USDT émis sous le protocole RVB), la transaction d’engagement Bitcoin ne garantit pas que le prêteur récupérera son NFT tant que le prêteur retourne le montant total de l’USDT, car la transaction Bitcoin n’a aucune idée du statut de l’USDT ! (Révision : En d’autres termes, il n’est pas possible de construire une transaction engagée sous réserve du remboursement de l’USDT.) ）
Si nous sommes en mesure d’initier un chèque basé sur la définition de l’UDT, nous serons en mesure d’obtenir du prêteur qu’il signe une autre transaction engagée qui lui permettra d’utiliser l’USDT pour rembourser le prêt. La transaction vérifiera le montant d’USDT saisi et le montant d’USDT sortant, offrant aux utilisateurs un remboursement sans confiance avec USDT.
Ensuite, considérons l’introspection.
(3) Le verrou lit les autres verrous
Cela signifie que toute la gamme des possibilités de programmation sur les UTXO Bitcoin après la mise en œuvre de la restriction proposée est mise en œuvre. Cela inclut les contrats Vault mentionnés ci-dessus, ainsi que les applications basées sur OP_CTV (par exemple, le contrôle de congestion).
XueJie a mentionné une fois un exemple très intéressant : vous pouvez implémenter une cellule de compte de recouvrement sur CKB, lorsque vous utilisez ce type de cellule comme entrée de la transaction, si la cellule de sortie (la cellule utilisant le même verrou) a plus de capacité, alors l’entrée n’a pas besoin de fournir de signature et n’affecte pas la validité de la transaction. En fait, ce type de cellule ne serait pas possible sans la capacité d’introspection. Cette cellule de compte de recouvrement est idéale comme méthode institutionnelle pour recevoir de l’argent car elle mutualise les fonds et présente l’inconvénient de ne pas avoir un bon sens de la vie privée.
(4) Le verrou lit d’autres types (et données)
Une application intéressante de cette fonctionnalité est celle des tokens de stake. Lock décidera s’il peut utiliser sa propre capacité en fonction du nombre de jetons dans les autres entrées, et où il peut être dépensé (nécessite la possibilité de verrouiller l’introspection).
(5) Le type lit les autres verrous
Je ne sais pas, mais on peut supposer qu’il est utile. Par exemple, vous pouvez vérifier dans Type que les verrous des entrées et sorties d’une transaction restent inchangés.
(6) Le type Scirpt lit les autres types (et données)
Des cartes à collectionner ? Collectez n jetons en échange d’un jeton plus important :)
VI. En conclusion
Par rapport aux systèmes de contrats intelligents précédents qui peuvent être programmés avec des calculs arbitraires, tels qu’Ethereum, Nervos Network adopte une structure différente ; Par conséquent, il est souvent difficile de comprendre le réseau Nervos sur la base de la connaissance des systèmes de contrats intelligents du passé. 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. Et, en utilisant le concept d'« introspection » pour comprendre les capacités d'« accès aux contrats croisés » des cellules, nous pouvons diviser les situations dans lesquelles les capacités d’introspection sont utilisées et déterminer leurs utilisations spécifiques.
Recension :
Les deux points ci-dessus signifient quelque chose avec le même paradigme que « BTC + RGB » mais avec plus de capacités de programmation ;
Il n’y a pas beaucoup d’exemples précis de ces utilisations, mais cela est dû au manque de compréhension de l’auteur de l’écologie du CKB. Au fil du temps, on pense que de plus en plus d’imagination sera investie dans ce domaine, et que des applications inimaginables aujourd’hui seront mises en place.
Remerciements
Merci à Retric, Jan Xie et Xue Jie pour leurs commentaires lors de la rédaction de l’article. Bien sûr, je suis responsable de toutes les erreurs dans le texte.
Références
Comptes, listes d’accès strictes et UTXO
Restrictions dans Bitcoin : taxonomie pour examen
Modèle de cellule
Nervos CKB en bref
Programmabilité de Bitcoin
Abstraction de compte (2022)
Qu’est-ce qu’un arbre syntaxique abstrait Bitcoin Merkelisé ?
BIP 345 : Proposition OP_VAULT
Introduction aux opcodes de restriction TLUV
Les composants qui construisent le contrat sont mis à niveau avec Bitcoin
Eltoo a expliqué
Un contrat de prêt garanti NFT basé sur des transactions engagées · btc-study/OP_QUESTION · Discussion #7
Lien vers l’article original