Depuis la programmation d'applications Bitcoin, une explication détaillée de la programmabilité de CKB.

Le contenu suivant est reposté depuis le forum Nervos Talk, écrit par Ajian (éditeur en chef de la plateforme de contenu Bitcoin BTC Study).

Résumé

理解一个系统的可编程性要求我们辨识这个系统在结构上的特征。对基于BTC脚本的应用编程的探索，有助于我们理解 CKB Cell 的基本结构及其编程范式。不仅如此，它还能将 CKB 的编程元件分解为恰当的部分，并帮助我们理解每一部分所带来的可编程性增益。

一. 引言

"La « programmabilité » est souvent utilisée comme un critère de comparaison des systèmes blockchain. Cependant, il existe différentes façons de décrire la programmabilité. Une formulation courante est « la blockchain XX prend en charge un langage de programmation Turing complet » ou « la blockchain XX prend en charge une programmation générale », ce qui signifie que la blockchain XX est hautement programmable. Ces déclarations ont un certain fondement : les systèmes prenant en charge une programmation Turing complète sont généralement plus faciles à programmer que ceux qui ne le sont pas. Cependant, les caractéristiques structurelles des systèmes de contrats intelligents sont multiples et cette déclaration n'en couvre qu'un aspect, ce qui ne permet pas une compréhension approfondie : les développeurs n'ont pas de directives claires et les utilisateurs ordinaires ne peuvent pas distinguer les escroqueries avec cette seule information."

Le système de contrat intelligent présente les caractéristiques suivantes du point de vue de sa structure :

• La forme de base de l'expression de l'état (contrat) (compte vs sortie de transaction)
• La programmation permet-elle le calcul arbitraire (le concept de "Turing complet" est lié à cela)
• Le processus d'exécution crée-t-il de nouvelles données ou renvoie-t-il uniquement une valeur booléenne ? (Calcul vs Vérification)
• Autoriser l'enregistrement d'états supplémentaires dans le contrat.
• Lors de l'exécution d'un contrat, est-il possible d'accéder à l'état d'un autre contrat

Donc, en dehors de la "capacité à effectuer des calculs programmables", il y a au moins quatre autres caractéristiques qui influencent la programmabilité d'un système de smart contract. On peut même dire que ces autres caractéristiques sont plus importantes, car elles déterminent plus en profondeur ce qui est facile à réaliser, ce qui est difficile à réaliser, ce qui est économiquement réalisable et ce qui est inefficace.

Par exemple, Ethereum est souvent utilisé comme un bon exemple de programmabilité, mais la forme de base de l'expression de l'état d'Ethereum est un compte, ce qui rend difficile la programmation de contrats peer-to-peer tels que les canaux de paiement ou les contrats de paris un à un - ce n'est pas impossible, mais c'est difficile. L'écosystème Ethereum n'est pas dépourvu de projets visant à mettre en œuvre des canaux de paiement / des canaux d'état, et il y a également de nombreuses discussions théoriques à ce sujet, mais jusqu'à présent, ces projets semblent peu actifs - cela ne peut clairement pas être attribué à un manque d'effort de la part des développeurs. Aujourd'hui, les projets actifs sur Ethereum adoptent une forme de "pool de fonds" plutôt qu'une forme de "contrat peer-to-peer", et ce n'est pas un hasard. De même, les gens peuvent être satisfaits de la programmabilité d'Ethereum à l'heure actuelle, mais pour mettre en œuvre une "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 insuffisant.

De même, pour explorer la programmabilité de CKB, il est également nécessaire de comprendre les caractéristiques structurelles du système de contrats intelligents CKB dans ces domaines. Nous savons déjà que CKB permet la programmation de calculs arbitraires, autorise l'enregistrement d'états supplémentaires à l'intérieur des contrats, et permet à un contrat d'accéder à l'état d'un autre contrat lors de son exécution. Cependant, la forme de ses contrats est la sortie de la transaction (appelée "Cell"), ce qui le différencie fondamentalement d'Ethereum. Ainsi, la compréhension du système de contrats intelligents d'Ethereum et des exemples de contrats qui y sont présents ne nous aide pas à comprendre comment CKB met en œuvre ces caractéristiques structurelles, ni à reconnaître la programmabilité de CKB.

幸运的是，比特币上的智能合约，似乎为我们理解 CKB 的可编程性提供了最好的基础。这不仅是因为比特币的状态表达的基本形式也是交易的输出（称为 “UTXO”），更是因为，借助比特币社区提出的一个概念 “限制条款（covenants）”，我们可以理解 CKB 具备上述结构特性的原因，并将最终的效果恰当地分拆成几个部分、逐一辨识它们所带来的可编程性增益。

Deuxième. CKB contre BTC : Qu'est-ce qui a changé ?

Structure de base

作为比特币状态表达的基本形式，比特币的 UTXO（01928374656574839201）有两个字段：

• Quantité, exprimée en Satoshi, représentant la valeur en Bitcoin de cette UTXO ;
• La clé publique de script, également appelée script de verrouillage, représente les conditions requises pour dépenser ces fonds, c'est-à-dire le programme de contrat intelligent qui définit les conditions de déverrouillage de ces fonds.

与后来出现的Smart Contract系统相比，Bitcoin脚本是相当受限的：

• Il n'autorise pas le calcul programmable arbitraire ; les calculs pratiques vérifiables sont limités à quelques types (vérification de signature, vérification d'image de hachage, vérification de temps)
• Il n'est pas autorisé d'enregistrer un état supplémentaire dans le contrat ; (par exemple, vous ne pouvez pas limiter le pourcentage/le montant des dépenses uniques à l'aide d'un script ; vous ne pouvez pas non plus y cacher un jeton)
• Il ne permet pas non plus d'accéder à l'état d'un autre contrat lors de l'exécution (chaque script est un univers indépendant et n'interdépend pas).

Cette version de script est limitée, mais elle ne manque pas de capacités à programmer des applications étonnantes, et c'est aussi la base de notre exploration de la programmabilité de CKB. La suite présentera deux exemples de programmation de script Bitcoin.

"Contrairement à cela, l'unité d'état de CKB est appelée «Cellule» et comporte quatre champs:"

• Capacité, similaire au montant UTXO, représente l'espace que cette Cellule peut occuper, en octets (Bytes).
• Lock, similaire à la clé publique UTXO, définit la propriété de cette Cellule ; seulement les données fournies peuvent être "mises à jour" lorsque Lock est utilisé sur cette Cellule (ou libère cette Cellule et utilise ces Capacités pour la création d'une nouvelle Cellule) ;
• Données, données, n'importe quelles données, leur volume est limité par la capacité ;
• Type, un script optionnel utilisé pour définir des conditions pour les mises à jour de Data.

此外，Lock 和 Type 还可以编程任意计算。你可以编程出任意的签名验证Algorithme ，也可以编程出任意一种哈希Algorithme 的原像检查，等等等等。

Les lecteurs peuvent facilement constater que Cell offre une amélioration en termes de programmabilité par rapport à UTXO.

• Cell peut être programmé pour effectuer n'importe quel calcul, plutôt que d'être limité à quelques calculs spécifiques ; sa validation de propriété sera plus flexible ;
• En raison des champs Data et Type, Cell peut enregistrer un état supplémentaire ; cela permet à Cell de transporter ce qu'on appelle un "jeton personnalisé par l'utilisateur (UDT)".

La combinaison de la structure "sortie de transaction" de Cell et des avantages qu'elle apporte est déjà énorme. Cependant, à partir de la description ci-dessus, nous ne savons pas encore comment Cell met en œuvre "l'accès à l'état d'un autre contrat lors de l'exécution d'un contrat". Pour cela, nous devons nous appuyer sur un concept discuté depuis longtemps dans la communauté Bitcoin : les "clauses restrictives".

Clause de restriction et d'introspection

Les termes de restriction sont destinés à limiter où l'argent peut être dépensé. Dans le cas du Bitcoin actuel (où aucune proposition de termes de restriction n'a encore été mise en œuvre), une fois que des fonds sont débloqués, ils peuvent être dépensés n'importe où (vers n'importe quelle clé publique de script). Mais l'idée des termes de restriction est de pouvoir restreindre les dépenses à certains endroits, par exemple, un UTXO ne pourrait être dépensé que par une seule transaction, donc même si quelqu'un peut fournir une signature pour cet UTXO, où il peut être dépensé est déjà déterminé par cette transaction. Cette fonctionnalité semble un peu étrange, mais elle peut avoir des applications intéressantes, qui seront abordées dans une section dédiée plus loin. Il est important de noter que cela est essentiel pour comprendre davantage la programmabilité de CKB.

Rusty Russell a souligné à juste titre que les termes de restriction peuvent être compris comme la capacité de "réflexion interne" des transactions, c'est-à-dire que lorsque un UTXO A est dépensé par une transaction B, le script de la transaction peut lire une partie (ou la totalité) de la transaction B, puis vérifier si elles correspondent aux paramètres requis par le script. Par exemple, le script de la première sortie de la transaction A est-il conforme à la clé publique requise par le script de l'UTXO A (c'est là l'origine de la notion de termes de restriction).

Les lecteurs attentifs remarqueront que, avec une capacité d'introspection complète, une entrée de transaction peut lire l'état d'une autre entrée de la même transaction, ce qui réalise la capacité que nous avons mentionnée précédemment, "un contrat accède à l'état d'un autre contrat pendant l'exécution". En fait, la cellule CKB est conçue de cette manière.

基于此，我们又可以将这种完全的内省能力分成四种情形： -> Sur cette base, nous pouvons également diviser cette capacité d'introspection complète en quatre cas.

• Verrouiller la lecture d'autres (entrées et sorties) de verrouillage.
• Verrouiller la lecture du type (et des données) d'entrée et de sortie
• Type Lire le verrouillage des autres (entrée et sortie)
• Lisez les autres types (entrées et sorties) de Type (et de données)

Ce qui nous permet d'analyser le rôle de chaque partie dans différents scénarios d'application, c'est-à-dire d'analyser les avantages de programmabilité que chaque partie nous apporte, dans certaines hypothèses (la répartition des fonctions de verrouillage et de type).

Dans les deux sections suivantes, nous examinerons respectivement la programmation de script Bitcoin actuelle (proposition de clause non limitative) et les fonctionnalités prévues de la proposition de clause limitative afin de comprendre concrètement comment programmer et améliorer les cellules CKB.

Trois. Programmation de script Bitcoin

Ce chapitre utilisera "canal Lightning / réseau Lightning" et "contrat de journal prudent (DLC)" comme exemples de programmation d'applications basées sur le script Bitcoin. Avant de commencer, nous devons d'abord comprendre deux concepts.

OP_IF et "transaction de promesse"

Le premier concept est l'opération de contrôle de flux dans le script Bitcoin, comme OP_IF, OP_ELSE. Ces opérations sont similaires à l'instruction IF en programmation informatique, elles permettent d'exécuter différentes instructions en fonction des différentes entrées. Dans le contexte du script Bitcoin, cela signifie que nous pouvons définir plusieurs chemins de déverrouillage des fonds ; combiné avec la fonctionnalité de verrouillage temporel, cela signifie que nous pouvons attribuer une priorité d'action.

À titre d'exemple, prenons le célèbre contrat de verrouillage temporel hashé (HTLC), ce script se traduit en langage clair par :

要么，Bob 可以揭晓某个哈希值 H 背后的原像，再给出自己的签名，即可花费这笔资金；

Soit Alice peut dépenser ces fonds après un certain temps T en utilisant sa propre signature.

Cette "soit ... soit ..." effet est réalisé en utilisant le code d'opération de contrôle de flux.

HTLC La caractéristique la plus remarquable est qu'elle peut regrouper plusieurs opérations et les rendre atomiques. Par exemple, Alice souhaite échanger des CKB avec Bob contre des BTC, alors Bob peut d'abord fournir une valeur de hachage et créer un HTLC sur le réseau Nervos ; ensuite, Alice crée un HTLC sur Bitcoin en utilisant la même valeur de hachage. Soit Bob récupère les BTC payés par Alice sur Bitcoin et révèle également l'image d'origine, ce qui permet à Alice de récupérer les CKB sur le réseau Nervos. Soit Bob ne révèle pas l'image d'origine, les deux contrats expirent et Alice et Bob peuvent récupérer leurs fonds respectifs.

Après l'activation de la bifurcation douce Taproot, cette caractéristique de multiples chemins de déverrouillage est renforcée grâce à l'introduction de MAST (Merkle Abstract Syntax Tree) : nous pouvons transformer un chemin de déverrouillage en une feuille de l'arbre de Merkle, chaque feuille étant indépendante, il n'est donc plus nécessaire d'utiliser ce type d'opcode de contrôle de flux ; de plus, comme la révélation d'un chemin n'expose pas les autres chemins, nous pouvons ajouter plus de chemins de déverrouillage à une sortie sans nous soucier des problèmes d'économie.

Le deuxième concept est celui des "transactions prometteuses". L'idée des transactions prometteuses est que, dans certaines circonstances, une transaction Bitcoin valide peut être considérée comme réelle et engageante, même si elle n'est pas confirmée par la blockchain.

Par exemple, Alice et Bob possèdent conjointement un UTXO, qui nécessite la signature des deux pour être dépensé. À ce moment, Alice crée une transaction pour le dépenser, transférant 60% de sa valeur à Bob et le reste à elle-même ; Alice signe la transaction et l'envoie à Bob. Ainsi, pour Bob, il n'est pas nécessaire de diffuser cette transaction sur le réseau Bitcoin ni de la faire confirmer par la blockchain. L'effet de paiement de cette transaction est réel et fiable. En effet, Alice ne peut pas dépenser seule cet UTXO (et donc ne peut pas le dépenser à nouveau), et sa signature est valide. Bob peut à tout moment ajouter sa propre signature et diffuser la transaction pour encaisser ce paiement. Ainsi, Alice fournit à Bob un "engagement fiable" à travers cette transaction valide (hors chaîne).

承诺交易是Bitcoin应用编程的核心概念。如前所述，Bitcoin的合同是基于验证的、无状态的、不允许交叉访问的；但是，如果合同不携带状态，那这些状态存放在哪里、合同如何安全推进（变更状态）？承诺交易给出了直截了当的答案：合同的状态可以用交易的形式来表达，从而，合同的参与者可以自己保存状态，而不必将它们展现在Bloc上；合同的状态变更问题，也可以转化成如何安全地更新承诺交易的问题；此外，如果我们担心进入一个合同会有危险（例如，进入一个要求双方都签名才能花费的合同，会面临对方不响应从而卡死的风险），那么，只需提前生成花费该合同的承诺交易并获得签名，就可以化解风险、消除对其他参与者的信任。

Lightning Channel and Lightning Network

Les canaux d'éclairage sont des contrats en tête-à-tête dans lesquels les deux parties peuvent effectuer des paiements réciproques à plusieurs reprises sans nécessiter une confirmation de la blockchain pour chaque paiement. Comme vous pouvez le deviner, cela utilise des transactions de promesse.

Dans la partie expliquant les "transactions de promesse", nous avons introduit un canal de paiement qui utilise uniquement un contrat à signature multiple 2 sur 2. Cependant, ce contrat ne permet de réaliser que des paiements unidirectionnels. Cela signifie soit qu'Alice paie toujours Bob, soit que Bob paie toujours Alice, jusqu'à épuisement de leur solde dans le contrat. Si les paiements sont bidirectionnels, cela signifie qu'après une mise à jour de l'état, le solde d'une partie peut être inférieur à ce qu'il était auparavant, mais elle possède toujours la transaction de promesse précédente signée par l'autre partie - comment empêcher cette partie de diffuser l'ancienne transaction de promesse et de ne diffuser que la plus récente ?

La solution à ce problème est appelée "LN-Penalty". Supposons maintenant qu'Alice et Bob possèdent chacun 5 BTC dans un canal, et qu'Alice veuille payer 1 BTC à Bob. Elle signe alors une telle transaction de promesse et l'envoie à Bob.

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

Sortie #0, 4 BTC: Alice single signature

Sortie #1, 6 BTC: soit Alice-Bob utilise la clé publique temporaire #1 pour une signature unique, soit Bob utilise T1 verrouillage temporel pour une signature unique.

Bob also signe un engagement (correspondant à la transaction ci-dessus) et l'envoie à Alice :

Entrée #0, 10 BTC : Sortie multi-signatures Alie-Bob 2-sur-2 (c'est-à-dire le contrat de canal)

Sortie de #0,6 BTC : Bob à signature unique

Sortie #1, 4 BTC : Soit Bob-Alice utilise une clé publique temporaire #1 pour une signature unique, soit utilise un verrouillage temporel T1, et Alice utilise une signature unique.

Ici, le truc réside dans cette "clé publique temporaire commune", qui est générée en utilisant une clé publique de notre côté et une clé publique fournie par l'autre partie. Par exemple, la clé publique temporaire commune Alice-Bob est obtenue en multipliant respectivement la clé publique d'Alice et la clé publique fournie par Bob par une valeur de hachage, puis en les additionnant. Ainsi, lors de la génération de cette clé publique, personne ne connaît sa clé privée. Cependant, si Bob révèle la clé privée de la clé publique qu'il a fournie, Alice peut calculer la clé privée de cette clé publique temporaire commune. C'est la clé pour "annuler" l'ancien état dans le canal Lightning.

Lorsque les deux parties doivent mettre à jour l'état du canal lors du prochain paiement, elles échangent la clé privée correspondante à la clé publique temporaire transmise précédemment. De cette façon, les participants n'osent plus diffuser la transaction de promesse précédente qu'ils ont reçue : cette transaction de promesse a deux chemins pour allouer la sortie de valeur, et la clé privée du chemin de la clé publique temporaire est maintenant connue par l'autre partie. Donc, si une ancienne transaction de promesse est diffusée, l'autre partie peut immédiatement utiliser cette clé privée temporaire conjointe pour vider tous les fonds de cette sortie. Cela explique la signification de "LN-Penalty".

具体来说，交互的顺序是：发起支付的一方先向对方请求新的临时公钥，然后构造一笔新的承诺交易并交给对方；得到了承诺交易的一方向对方曝光自己在上一轮给出的临时公钥的私钥。这样的交互顺序保证了参与者总是先得到新的承诺交易，然后才作废自己在上一轮中得到的承诺交易，因此是免信任的。

综上，闪电通道的关键设计有：

双方总是使用承诺交易来表达合约内部的状态，并以数额的变化来表示支付；

Les transactions d'engagement nécessitent toujours une seule entrée (qui nécessite la signature des deux parties), ce qui signifie que toutes les transactions d'engagement sont en concurrence les unes avec les autres et qu'à la fin, une seule peut être confirmée sur la blockchain.

两 signataires ne signent pas la même transaction d'engagement (bien qu'elles soient appariées); ils signent toujours la transaction qui leur est plus avantageuse, ce qui signifie que les engagements reçus sont toujours défavorables pour eux-mêmes;

这种不利体现在，为自己分配价值的输出带有两个解锁路径：一条路径可以凭自己的签名解锁，却需要等待一段时间；而另一条路径则用到了对方的公钥，仅当自己的一个临时私钥不暴露，才受到保护；

Dans chaque paiement, les deux parties échangent une nouvelle transaction de promesse pour échanger la clé privée temporaire utilisée dans le tour précédent. Ainsi, la partie qui remet la clé privée temporaire n'ose plus diffuser l'ancienne transaction de promesse, ce qui "révoque" la transaction de promesse précédente et met à jour l'état du contrat. (En réalité, ces transactions de promesse sont toutes valides et peuvent être diffusées sur la blockchain, mais les participants n'osent plus le faire en raison de sanctions.)

任何一方随时都可以拿对方签过名的承诺交易退出合约；但是，如果双方愿意合作，他们可以签名一笔新的交易，让双方都可以立即拿回属于自己的钱。

最后，因为承诺交易中也可置入 HTLC，所以，闪电通道也可以转发支付。假定 Alice 可以找出一条由闪电通道前后相接所组成的路径、触达 Daniel，那么无需跟 Daniel 开设通道就可以实现免信任的long跳支付。这便是闪电网络：

Alice -- HTLC --\u003e Bob -- HTLC --\u003e Carol -- HTLC --\u003e Daniel

Alice \u003c-- image originale -- Bob \u003c-- image originale -- Carol \u003c-- image originale -- Daniel

Lorsque Alice trouve un tel chemin et souhaite payer à Daniel, elle demande à Daniel une valeur de hachage pour construire un HTLC à Bob et demande à Bob de transmettre un message à Carol avec le même HTLC. Le message demande ensuite à Carol de transmettre le message à Daniel avec le même HTLC. Lorsque le message parvient à Daniel, il révèle l'image d'origine à Carol, ce qui lui permet de récupérer la valeur du HTLC et de mettre à jour l'état du contrat. Carol fait de même, récupère le paiement de Bob et met à jour l'état du canal. Enfin, Bob révèle l'image d'origine à Alice et met à jour l'état. En raison des caractéristiques de HTLC, ces paiements en chaîne réussissent tous ensemble ou échouent tous ensemble, ce qui les rend sans nécessité de confiance.

闪电网络 est composé de multiples canaux, chaque canal (contrat) étant indépendant. Cela signifie qu'Alice n'a besoin de connaître que ce qui se passe dans son propre canal avec Bob, sans se soucier des interactions dans les canaux des autres personnes, ni du type de monnaie utilisé dans ces interactions, voire même si ces canaux sont réellement utilisés).

La scalabilité du réseau Lightning ne se manifeste pas seulement par la vitesse de paiement à l'intérieur d'un canal Lightning, qui est limitée uniquement par les ressources matérielles des deux parties, mais également par le fait qu'en raison du stockage décentralisé de l'état, un seul nœud peut exercer le maximum de levier avec le coût le plus bas.

Contrat de journalisation prudent

Les contrats de journal prudent (DLC) utilisent une technique cryptographique appelée "signature d'adaptateur" pour permettre aux scripts Bitcoin de programmer des contrats financiers dépendant d'événements externes.

L'adaptateur de signature permet de rendre une signature valide uniquement après l'ajout d'une clé privée. Prenons l'exemple de la signature Schnorr, la forme standard de la signature Schnorr est (R, s), où :

R = r.G # Clé publique de nonce utilisée pour la signature r multipliée par le point de génération de la courbe elliptique, aussi connue 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

验证签名即验证 s.G = r.G + Hash(R || m || P) \* p.G = R + Hash(R || m || P) \* PK

假设我给出了一对数据(R, s')，其中：

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, mais je peux prouver aux validateurs que, tant que TA connaît la clé privée r2 de R2, elle peut être transformée en une signature valide.

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

Les signatures d'adaptateur rendent la validité d'une signature dépendante des données secrètes et vérifiables. Mais quel est le lien avec les contrats financiers ?

假设 Alice et Bob veulent parier sur le résultat d'un match de football. Alice parie sur la victoire des Green Devils et Bob parie sur la victoire d'Arlina. La mise est de 1 BTC. De plus, le site de notation des matchs, Carol, s'engage à publier une signature s\_c\_i sur le résultat à l'aide d'un nonce R\_c lorsque le résultat du match sera annoncé.

On peut voir qu'il y a trois résultats possibles au total (donc il y a trois possibilités de signature pour Carol).

• Le Green Magic l'emporte, Alice gagne 1 BTC
• Arinna wins, Bob wins 1 BTC
• Match nul, les fonds des deux parties sont remboursés.

为此，两人为每一种结果创建一笔承诺交易。例如，他们为第一种结果创建的承诺交易是这样的： -> Pour ce faire, les deux parties créent une transaction d'engagement pour chaque résultat. Par exemple, la transaction d'engagement créée pour le premier résultat est la suivante :

Entrée #0,2 BTC: Sortie multisécurisée Alie-Bob 2-of-2 (c'est-à-dire un contrat de pari)

Sortie #0, 2 BTC : Alice signature unique

Mais les signatures créées par Alice et Bob pour cette transaction ne sont pas (R, s), mais plutôt les signatures d'adaptateur (R, s') ; c'est-à-dire que les signatures remises à l'autre partie ne peuvent pas être utilisées directement pour déverrouiller ce contrat, mais doivent révéler une valeur secrète. Cette valeur secrète est précisément l'image inverse de s_c_1.G, c'est-à-dire la signature de Carol ! Étant donné que la valeur nonce de la signature de Carol est déjà déterminée (elle est R_c), s_c_1.G peut donc être construit (s_c_1.G = R_c + Hash(R_c || '绿魔胜出' || PK_c) * PK_c).

Lorsque le résultat est annoncé et que Green Magic remporte, Carol publiera la signature (R_c, s_c_1). Ainsi, que ce soit Alice ou Bob, ils pourront compléter la signature de l'adaptateur de leur adversaire, ajouter leur propre signature, et rendre la transaction susmentionnée valide, la diffuser sur le réseau et déclencher l'effet de règlement. Cependant, si Green Magic ne gagne pas, Carol ne publiera pas s_c_1, et cette transaction de promesse ne pourra pas devenir une transaction valide.

Ainsi de suite, les deux autres transactions sont similaires. Ainsi, Alice et Bob font en sorte que l'exécution de ce contrat dépende d'événements externes (plus précisément, de la diffusion d'événements externes par un oracle sous forme de signature), sans avoir besoin de faire confiance à l'autre partie. Cette méthode peut être utilisée pour mettre en œuvre des contrats financiers de toutes tailles, tels que les contrats à terme et les options.

与其它形式的实现相比，谨慎日志合约最大的特点在于其隐私性：（1）Alice 和 Bob 不需要告知 Carol 自己正在使用 Carol 的数据，这完全不影响合约的执行；（2）off-chain 观察者（也包括 Carol 在内），也无法通过 Alice 和 Bob 的合约执行交易来判定他们正在使用哪个网站的服务，甚至无法断定他们的合约是一个打赌合约（而不是一个闪电通道）。

Quatre. Introduction à l'application des clauses restrictives

OP_CTV et le contrôle de la congestion

La communauté des développeurs de Bitcoin a proposé plusieurs propositions qui pourraient être classées comme des clauses restrictives. À l'heure actuelle, la proposition la plus célèbre est celle d'OP_CHECKTEMPLATEVERIFY (OP_CTV), qui est conceptuellement simple mais offre une grande flexibilité, ce qui en fait une proposition populaire auprès de la communauté Bitcoin qui prône la simplicité. L'idée d'OP_CTV est de promettre une valeur de hachage dans le script pour contraindre les fonds à être dépensés uniquement par une transaction représentée par cette valeur de hachage ; cette valeur de hachage promet les sorties de transaction ainsi que la plupart des champs, mais pas les entrées de transaction, seulement la quantité d'entrées.

"La 'gestion de la congestion' est un bon exemple qui illustre les caractéristiques d'OP_CTV. Son scénario d'application de base est d'aider un grand nombre d'utilisateurs à sortir d'une plateforme d'échange (un environnement de confiance) vers un pool de liquidités. Étant donné que ce pool de liquidités utilise OP_CTV pour planifier les dépenses futures, il peut garantir aux utilisateurs de sortir du pool sans avoir à faire confiance à qui que ce soit et sans avoir besoin d'aide. De plus, étant donné que ce pool de liquidités est représenté par une UTXO, il évite de payer des frais de transaction élevés lorsque la demande de transactions sur la chaîne augmente (passant de n sorties à une seule sortie et de n transactions à une seule transaction). Les utilisateurs du pool peuvent ensuite choisir le moment opportun pour sortir du pool."

Disons qu’Alice, Bob et Carol veulent retirer 5 BTC, 3 BTC et 2 BTC des échanges, respectivement. Ensuite, plateforme d'échange pouvez 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, et la transaction représentée par la valeur hash utilisée par le OP_CTV de cette 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 ne retirer que 3 BTC et d’envoyer les 2 BTC restantes à Carol.

Bob ou Carol veut retirer de l'argent, c'est la même chose. Lorsqu'ils retirent de l'argent, ils ne pourront utiliser que des transactions qui passent la vérification OP_CTV correspondante, c'est-à-dire qu'ils ne pourront se payer que le montant approprié et non retirer de l'argent à volonté ; les fonds restants retourneront dans un pool de fonds verrouillé par OP_CTV, garantissant ainsi que, quelle que soit l'ordre de retrait des utilisateurs, les utilisateurs restants pourront retirer de manière non confidentielle du pool.

En termes abstraits, le rôle de OP_CTV ici est de planifier le chemin vers la fin de vie du contrat, de sorte que le contrat de pool de fonds ici puisse maintenir sa propriété de sortie sans confiance, quelle que soit la voie empruntée ou l'état atteint.

Cette OP_CTV a une autre utilisation très intéressante : un "circuit de paiement unidirectionnel non divulgué". Supposons qu'Alice forme une telle piscine de fonds et garantit que les fonds peuvent être retirés sans confiance vers une sortie avec le script suivant :

要么， Alice 和 Bob 一起花费它要么，一段时间后，Alice 可以独自花费01928374656574839201

Si Alice ne révèle pas à Bob, Bob ne saura pas que cette sortie existe ; une fois qu'Alice l'a révélé à Bob, Bob peut considérer cette sortie comme un canal de paiement unidirectionnel à durée limitée, et Alice peut payer immédiatement Bob avec les fonds qu'elle contient, sans attendre la confirmation de la blockchain. Bob n'a qu'à faire en sorte qu'Alice mette la transaction de promesse sur la chaîne avant qu'elle ne puisse la dépenser seule.

OP_Vault et Coffre-fort

OP_VAULT est une proposition de clause restrictive conçue spécifiquement pour la construction de contrats de "coffres-forts" (vaults).

Le contrat de coffre-fort vise à être une forme de conservation autonome plus sécurisée et plus avancée. Bien que les contrats multi-signatures actuels éliminent les défaillances ponctuelles des clés privées individuelles, le propriétaire du portefeuille est impuissant si un attaquant parvient réellement à obtenir un nombre seuil de clés privées. Le coffre-fort vise à imposer une limite de dépenses unique pour les fonds ; en même temps, lorsqu'un retrait est effectué par un chemin régulier, l'opération de retrait sera soumise à une période d'attente obligatoire ; pendant cette période d'attente, l'opération de retrait peut être interrompue par une opération de récupération d'urgence du portefeuille. Avec un tel contrat, même s'il est compromis, le propriétaire du portefeuille peut lancer des contre-mesures en utilisant la branche de récupération d'urgence.

理论上，OP_CTV peut également programmer un contrat de cette manière, mais il y a beaucoup d'inconvénients, dont l'un est les frais : en plus de la transaction promise, il promet également les frais de transaction à payer. Étant donné l'utilisation de ce contrat, l'intervalle de temps entre la configuration du contrat et le retrait doit être très long, il est donc presque impossible de prédire les frais appropriés. Bien que OP_CTV n'impose aucune restriction sur les entrées, il est donc possible d'augmenter les frais en ajoutant des entrées, mais les entrées fournies deviendront toutes des frais, ce qui est irréaliste ; une autre méthode est CPFP, c'est-à-dire fournir des frais dans une nouvelle transaction en dépensant les fonds retirés. De plus, l'utilisation d'OP_CTV signifie également que ce type de contrat de coffre-fort ne peut pas effectuer de retraits en lot (bien sûr, il ne peut pas non plus être restauré en lot).

OP_VAULT propose de résoudre ces problèmes en proposant de nouveaux opcodes (OP_VAULT et OP_UNVAULT). OP_UNVAULT est conçu spécifiquement pour la récupération en vrac, mais nous n'en parlons pas pour le moment. L'action de OP_VAULT est la suivante : lorsque nous l'ajoutons à une branche de l'arbre de script, il peut être utilisé pour promettre un opcode utilisable (par exemple, OP_CTV) sans spécifier de paramètres spécifiques ; lors de l'utilisation de cette branche, la transaction peut inclure des paramètres spécifiques, mais ne peut pas modifier les autres branches. Ainsi, il n'est pas nécessaire de définir des frais de transaction à l'avance, ils peuvent être définis au moment de l'utilisation de cette branche ; si cette branche est également soumise à un verrouillage temporel, cela forcera l'exécution d'un verrouillage temporel ; enfin, comme il ne peut modifier que la branche sur laquelle il se trouve, les autres branches de l'arbre de script (y compris la branche de récupération d'urgence) ne seront pas modifiées, ce qui nous permet d'interrompre ce type d'opération de retrait.

Ce qui mérite également d'être mentionné est le suivant : (1) L'action du code OP_VAULT est similaire à une autre proposition de clause de restriction : OP_TLUV ; Jeremy Rubin a correctement souligné que cela a déjà introduit dans une certaine mesure le concept de "calcul" : OP_TLUV/OP_VAULT s'engage d'abord avec un code d'action pour permettre à l'utilisateur de passer des paramètres à ce code d'action via une nouvelle transaction, mettant ainsi à jour tout l'arbre de script ; cela n'est plus "vérifier les données entrantes en fonction de certaines conditions", mais plutôt "générer de nouvelles données significatives en fonction des données entrantes", bien que la portée du calcul qu'il peut activer soit limitée.

La proposition OP_VAULT complète utilise également des propositions de stratégies de pool de transactions (politique mempool), telles que des transactions au format v3, pour obtenir de meilleurs résultats. Cela nous rappelle que la notion de "programmation" peut être plus large que ce que nous imaginons. (Un exemple similaire est la transaction ouverte dans le réseau Nervos Network.)

五. Comprendre CKB

Dans les deux sections précédentes, nous avons présenté comment nous avons programmé des applications intéressantes sur une structure plus restreinte (Bitcoin UTXO) en utilisant des scripts ; nous avons également présenté des propositions visant à ajouter des capacités d'introspection à cette structure.

UTXO, bien que capable de programmer ces applications, les lecteurs remarqueront facilement leurs inconvénients ou les domaines pouvant être optimisés, par exemple :

• Dans LN-Penalty, les participants du canal doivent conserver chaque transaction d'engagement passée ainsi que la valeur secrète de sanction correspondante pour se prémunir contre la fraude de l'adversaire, ce qui représente un fardeau de stockage. S'il existe un mécanisme qui garantit que seule la transaction d'engagement la plus récente est valide et que les anciennes transactions d'engagement ne sont pas valides, cela permettrait de se débarrasser de ce fardeau et d'éliminer également le problème des nœuds qui, en raison d'une défaillance, envoient accidentellement d'anciennes transactions d'engagement sur la chaîne et sont donc sanctionnés par inadvertance.
• Dans le DLC, supposons qu'il y ait de nombreux résultats possibles pour un événement, ce qui signifie qu'il y a aussi de nombreux signatures à générer et à remettre à l'autre partie à l'avance, ce qui est également un fardeau considérable ; De plus, les bénéfices du contrat DLC sont directement liés à la clé publique, il est donc difficile de transférer la position du contrat. Existe-t-il un moyen de transférer la position du contrat ?

En réalité, la communauté Bitcoin a déjà proposé des réponses à ces problèmes, qui sont essentiellement liées à une proposition de Sighash (BIP-118 AnyPrevOut).

但, si nous programmons sur CKB, BIP-118 est disponible dès maintenant (capable de simuler ces étiquettes Sighash en utilisant des capacités d'introspection et de vérification de signature ciblée).

通过学习Bitcoin编程，我们不仅知道了“交易输出”这种格式下可以如何编程（CKB能编程什么），还能知道这些应用的改进方法（如果我们在CKB上编程这些应用，可以如何运用CKB的能力来改进它们）。对于CKB开发者来说，简直可以将基于Bitcoin脚本的编程当成一种学习的教材，甚至是捷径。

Ci-dessous, nous analyserons un par un la programmabilité des différents modules de programmation de CKB. Nous ne tiendrons pas compte de la capacité d'introspection pour le moment.

Programmabilité Calcul verrouillé programmable

Comme mentionné précédemment, UTXO ne peut pas être programmé pour effectuer des calculs arbitraires. En revanche, Lock le peut, ce qui signifie que Lock peut programmer tout ce qui est basé sur UTXO (avant le déploiement des termes de restriction), y compris, mais sans s'y limiter, les canaux d'éclair et les DLC mentionnés ci-dessus.

此外，cette capacité de calcul vérifiable permet également à Lock d'utiliser plus de moyens d'authentification que UTXO, ce qui le rend plus flexible. Par exemple, nous pouvons mettre en place sur CKB un canal d'éclair avec une signature ECDSA d'une partie et une signature RSA de l'autre.

实ite, il s'agit en fait d'un des premiers domaines explorés sur CKB : l'utilisation de cette capacité d'authentification flexible pour l'auto-conservation des utilisateurs, permettant ainsi de réaliser ce qu'on appelle "l'abstraction de compte" - l'autorisation de validité des transactions et la reprise du contrôle sont très flexibles, presque sans aucune restriction. En principe, il s'agit de la combinaison de "multiples branches de dépenses" et de "moyens d'authentification arbitraires". Des exemples de réalisations incluent : JoyID Wallet, UniPass.

De plus, Lock peut également mettre en œuvre la proposition eltoo, ce qui permet de ne conserver que la dernière transaction engageante d'un canal Lightning (en fait, eltoo peut simplifier tous les contrats pair-à-pair).

**Programmabilité de calcul arbitraire de type **

Comme mentionné ci-dessus, l'un des principaux usages de Type est la programmation UDT. En combinaison avec Lock, cela signifie que nous pouvons mettre en place des canaux Lightning basés sur UDT (ainsi que d'autres types de contrats).

En réalité, la division entre Lock et Type peut être considérée comme une amélioration de la sécurité : Lock se concentre sur la mise en œuvre de méthodes de garde ou de protocoles contractuels, tandis que Type se concentre sur la définition de UDT.

De plus, la capacité de lancer des vérifications basées sur la définition de l'UDT permet à l'UDT de participer aux contrats de manière similaire au CKB (UDT est un citoyen de première classe).

举个例子：笔者曾经提出过一种在BTC上实现免信任NFT担保借贷的protocole。这种protocole的关键是一种承诺交易，其输入的价值是小于输出的价值的（因此它还不算是一笔有效的交易），但是，一旦能够为这笔交易提供足额的输入，它就是一笔有效的交易：一旦贷款人能够还款，放贷者就不能将质押的NFT据为己有。但是，这个承诺交易的免信任性基于交易对输入和输出的数额的检查，所以贷款人只能使用比特币来还款 —— 即使贷款人和放贷者都愿意接受另一种货币（比如以 RGB 协议发行的USDT），比特币的承诺交易也无法保证只要贷款人归还了足额的USDT就能拿回自己的NFT，因为比特币交易根本不知道USDT的状态！（修订：换言之，无法构造出以USDT还款为条件的承诺交易。）

Si nous pouvons initier une vérification selon la définition de UDT, les prêteurs pourront signer une autre transaction d'engagement permettant à l'emprunteur d'utiliser USDT pour rembourser le prêt. La transaction vérifiera la quantité de USDT en entrée et en sortie, ce qui conférera une non-exigence de confiance à l'utilisateur pour le remboursement en USDT.

修订：Supposons que les NFT utilisés comme garantie et les jetons utilisés pour le remboursement soient émis selon le même protocole (comme RGB), alors le problème ici peut être résolu. Nous pouvons construire une transaction de promesse basée sur le protocole RGB, de sorte que la transition d'état du NFT et le remboursement puissent se produire simultanément (en liant les deux transitions d'état dans la transaction RGB). Cependant, la construction de cette transaction de promesse sera quelque peu difficile car les transactions RGB dépendent également des transactions Bitcoin. En résumé, bien que le problème puisse être résolu, il n'est pas possible de considérer le jeton comme un citoyen de première classe.

Ensuite, nous allons considérer à nouveau la capacité d'introspection.

Lock 读取其它 Lock s

Cela signifie que toutes les possibilités de programmation sur les UTXO de Bitcoin pourraient être limitées après la mise en œuvre de la proposition de termes restrictifs. Cela comprend les contrats de coffre-fort mentionnés précédemment, ainsi que les applications basées sur OP_CTV (telles que le contrôle de congestion).

XueJie a mentionné un exemple très intéressant: vous pouvez mettre en œuvre un compte de réception Cell sur CKB. Lorsque vous utilisez ce Cell comme entrée de transaction, si le Cell de sortie (utilisant le même verrouillage) a une capacité supérieure, cette entrée n'a pas besoin de fournir de signature et n'affectera pas la validité de la transaction. En fait, sans la capacité d'introspection, ce Cell ne peut pas être réalisé. Ce compte de réception Cell est très adapté comme moyen de réception pour les institutions, car il peut collecter des fonds, mais il a le désavantage d'une faible confidentialité.

Verrouiller la lecture d'autres types s (ainsi que les données)

Cette capacité a une application intéressante avec les tokens de participation. Lock détermine s'il peut utiliser sa propre capacité en fonction de la quantité de tokens dans d'autres entrées, ainsi que où cette capacité peut être dépensée (nécessitant la capacité d'introspection de Lock).

Type 读取其它 Lock s

不 certain, mais on peut supposer que c'est utile. Par exemple, on peut vérifier que les Lock s des entrées et sorties de la transaction restent inchangés dans le Type.

Lire d'autres types de script (et de données) en TypeScript

集换卡？集齐 n 个 token 可以换取更大的一个 token : )

Six. Conclusion

与此前出现的可编程任意计算的智能合约系统（如以太坊）相比，Nervos Network 采取了不同的结构；因此，对以往那些智能合约系统的了解，往往难以成为理解 Nervos Network 的基础。本文从一种比 CKB Cell 更为受限的结构 —— BTC UTXO —— 的应用编程出发，提出了一种理解 CKB Cell 可编程性的方法。并且，运用 “内省” 的概念来理解 Cell 的 “跨合约访问” 的能力，我们可以划分运用内省能力的情形，并为它们确定具体的用途。

修订：Révision :

1. Sans tenir compte de la capacité de visite croisée de Cell (c'est-à-dire la capacité d'auto-examen), le verrouillage s peut être considéré comme un Bitcoin doté d'un état et d'une capacité de programmation poussés à l'extrême, de sorte qu'il peut être programmé pour toutes les applications basées sur Bitcoin.

2. Sans tenir compte de la capacité de croisement d'accès aux cellules (c'est-à-dire la capacité d'introspection), la distinction entre le verrouillage de s et le type de s peut être considérée comme une amélioration de la sécurité : elle sépare la définition des actifs UDT et les méthodes de conservation ; De plus, le type s exposant l'état (ainsi que les données) met en œuvre l'effet UDT est un citoyen de première classe.

La traduction en français du texte "以上两点意味着一种跟 “BTC + RGB” 相同范式但编程能力更强的东西" est "Cela signifie quelque chose avec un paradigme similaire à "BTC + RGB" mais avec une capacité de programmation plus puissante."

3. En tenant compte de la capacité d'introspection de Cell, Cell peut obtenir une capacité de programmation plus puissante que les UTXO BTC post-covenants et réaliser des choses que BTC + RGB a du mal à réaliser (car BTC ne peut pas lire l'état de RGB).

À propos de ces utilisations, cet article ne peut pas fournir de nombreux exemples concrets, mais cela est dû au manque de compréhension de l'écosystème de CKB par l'auteur. Avec le temps, on peut imaginer que les gens investiront de plus en plus d'imagination pour créer des applications aujourd'hui inimaginables.

致谢

Merci à Retric, Jan Xie et Xue Jie pour leurs commentaires tout au long du processus de rédaction de l'article. Bien sûr, je suis entièrement responsable de toutes les erreurs contenues dans le texte.

参考文献： -> Références:

5.\_07\_05\_introduction\_to\ckb\\_programming\_validation\_model/

6.（二）Contrat de journalisation prudent (DLC)

13.\_QUESTION/discussions/7