从比特币应用编程出发，万字详解CKB的可编程性 -> Bitcoin uygulama programlamasından başlayarak, CKB'nin programlanabilirliğini detaylı bir şekilde açıklıyor

Aşağıdaki içerik, Nervos Talk forumundan alıntıdır, yazar Ajian (Bitcoin içerik platformu BTC Study editörü) tarafından yazılmıştır.

Özet

"İstemselliğin bir sistemi anlamak için, sistemin yapısal özelliklerini belirlememiz gerekmektedir. Bitcoin script tabanlı uygulama programlaması keşfi, CKB Hücresinin temel yapısını ve programlama paradigmalarını anlamamıza yardımcı olur. Bununla birlikte, CKB'nın programlama bileşenlerini uygun parçalara ayırabilir ve her bir parçanın getirdiği programlanabilirlik artışını anlamamıza yardımcı olabilir."

一. Giriş

"“Programlanabilirlik (programmability)” birçok insanın blok zincir sistemlerini karşılaştırırken kullandığı bir boyuttur. Ancak, programlanabilirlik hakkındaki açıklama yöntemleri genellikle farklılık gösterir. Yaygın bir ifade şekli, "XX blok zinciri Turing tamamlanmış bir programlama dilini destekler" veya "XX blok zinciri genel amaçlı programlamayı destekler" şeklinde olabilir, burada "XX blok zinciri"nin güçlü bir programlanabilirliğe sahip olduğunu ifade etmek amaçlanır. Bu ifadelerin ima ettiği bazı doğrulukları vardır: Turing tamamlanmış programlamayı destekleyen sistemler genellikle desteklemeyenlere göre daha kolay programlanabilir. Ancak, akıllı sözleşme sistemlerinin yapısal özellikleri çok yönlüdür, bu ifade sadece bir yönü kapsar, bu yüzden yeterince derin bir anlayışa sahip olmak için yeterli değildir: Geliştiriciler bu ifadeden yönlendirme alamaz, normal kullanıcılar da dolandırıcılığı ayırt edemez."

智能合约系统在结构上的特征包括：

• Hesap Durumu İfadesinin Temel Biçimi (Hesap vs. İşlem Çıkışı)
• Herhangi bir programlama hesaplamasına izin verilip verilmediği (Turing Tamamlandı ifadesi bu konuyla ilgilidir)
• 执行过程可以生成新数据，还是仅返回布尔值？（计算 vs. 验证）
• Sözleşme içinde ek durumların kaydedilmesine izin veriyor mu?
• Bir sözleşme yürütülürken, başka bir sözleşmenin durumuna erişilebilir mi?

Bu nedenle, "herhangi bir programlanabilir hesaplamanın mümkün olup olmadığı" dışında, bir akıllı sözleşme sisteminin programlanabilirliğini etkileyen en az dört özellik daha vardır. Hatta, bu diğer özellikler daha önemli olduğu söylenebilir, çünkü neyin kolayca gerçekleştirilebilir veya neyin zor gerçekleştirilebileceği; neyin daha ekonomik bir şekilde gerçekleştirilebileceği ve neyin daha verimsiz bir şekilde gerçekleştirilebileceği daha derin bir şekilde belirlenir.

Örnek vermek gerekirse, insanlar genellikle Ethereum'u iyi bir programlanabilirlik örneği olarak gösterirler, ancak Ethereum'un temel ifade biçimi hesap olan bir durum tablosudur, bu da noktadan noktaya sözleşme programlamayı zorlaştırır (örneğin, ödeme kanalları, birbirine karşı bahis sözleşmeleri) - mutlak olarak gerçekleştirilemeyecek bir durum değil, sadece zorlayıcı. Ethereum ekosistemi, ödeme kanalları / durum kanallarını gerçekleştirmek için denemelerin hiç olmadığı anlamına gelmez, teorik tartışmalar da mevcut olsa da, günümüzde bu tür projelerin etkin olmadığı görünüyor - bu açıkça geliştiricilerin çabalarına atfedilemez. Bugün Ethereum'da etkin olan projelerin çoğu "fon havuzu" biçimini benimsemiştir, "noktadan noktaya sözleşme" biçimi değil, bu tesadüfi değildir. Benzer şekilde, bugün insanlar belki de Ethereum'un programlanabilirliğinden memnun olabilirler, ancak "hesap soyutlama" (ayrıca cüzdan kavramının genelleştirilmesi olarak da anlaşılabilir) 'nı gerçekleştirmek istenirse, hesap modelinin doğuştan eksik olduğu söylenebilir.

Aynı şekilde, CKB'nın programlanabilirliğini araştırmak, CKB akıllı sözleşme sisteminin bu yönlerinin yapısal özelliklerini anlamamızı gerektirir. Bildiğimiz gibi, CKB, herhangi bir hesaplama için programlama izni verir, sözleşme içinde ek durumları kaydetmeye izin verir ve bir sözleşmenin bir başka sözleşmenin durumuna erişmesine izin verir. Ancak, sözleşmenin biçimi bir işlemin çıktısıdır (Cell olarak adlandırılır) ve bu, Ethereum ile temel bir fark yaratır. Bu nedenle, Ethereum akıllı sözleşme sistemi ve içindeki sözleşme örneklerini anlamak, CKB'nın bu yapısal özellikleri nasıl gerçekleştirdiğini anlamamıza veya CKB'nın programlanabilirliğini tanımamıza yardımcı olmaz.

幸运的是，Bitcoin üzerindeki akıllı sözleşmeler, CKB'nın programlanabilirliğini anlamamız için en iyi temeli sağlamaktadır. Bu, sadece Bitcoin'in durumunun temel bir şekilde işlemin çıktısı olduğu (UTXO olarak adlandırılır) gerçeği değil, aynı zamanda Bitcoin topluluğunun ortaya koyduğu bir kavram olan "sınırlayıcı maddeler (covenants)" sayesinde, CKB'nın bu yapısal özelliklere sahip olmasının nedenini anlamamıza ve sonucun programlanabilirlik kazancını uygun şekilde parçalara ayırmamıza olanak tanır.

İkinci. CKB v.s. BTC: long ne eklenmiş?

Temel Yapı

"作为比特币状态表达的基本形式，比特币的 UTXO（“未花费的交易输出”）有两个字段：" -> "Bitcoin'in durumunu ifade etmek için temel bir şekil olarak, Bitcoin'in UTXO ("Harcanmamış İşlem Çıktısı") iki alanı vardır:"

• UTXO'nun sahip olduğu Bitcoin değerini temsil eden miktar, Satoshi birimiyle ifade edilir.
• Script public key, also known as the locking script, represents the conditions that need to be met to spend these funds, which is the smart contract program that sets the conditions to unlock these funds.

与后来出现的akıllı sözleşme系统相比，比特币脚本是相当受限的：

• Programlama dışında herhangi bir hesaplama yapmaya izin vermez; doğrulanabilir kullanışlı hesaplamalar sadece birkaç tanedir (imza kontrolü, kripto-analiz, zaman kontrolü).
• Sözleşme içinde ek durum kaydetmeye izin vermez; (örneğin, bir işlemde harcama oranını/limitini sınırlamak için betik kullanamazsınız veya içine gizli bir jeton yerleştiremezsiniz)
• Ayrıca, yürütme sırasında başka bir sözleşmenin durumuna erişime izin vermez (her bir komut dosyası bağımsız bir evren olarak hareket eder ve birbirine bağımlı değildir).

Bu script sınırlı olabilir, ancak etkileyici uygulamaları programlama yeteneği eksik değildir ve aynı zamanda CKB'nin programlanabilirliğini keşfetmek için temel teşkil etmektedir. İleride, Bitcoin script programlamasının iki örneğini tanıtmak için özel bir bölüm olacak.

CKB'nın karşısında, durum birimi "Hücre" olarak adlandırılır ve dört alanı vardır.

• Kapasite, UTXO'nun miktarına benzer şekilde, Bu Hücrenin kaplayabileceği alanın boyutunu ifade eder, Byte cinsinden;
• Lock , bir UTXO betiği gibi hücrenin sahipliğini tanımlayan bir genel anahtar; Sadece Lock tarafından sağlanan verilerle bu Hücre "güncellenebilir" (yani bu Hücre serbest bırakılabilir ve bu Kapasite ile yeni bir Hücre mintlenebilir).
• Veri, veri, herhangi bir veri, hacmi Kapasite tarafından sınırlanan veri;
• Type, Data'nın güncellenmesi için koşullar belirlemek için kullanılan isteğe bağlı bir betiktir.

Bu arada, Lock ve Type herhangi bir hesaplama için programlanabilir. Herhangi bir imza doğrulama algoritması veya herhangi bir karma algoritmasının öncüllük kontrolünü programlayabilirsiniz ve benzeri.

Ok, I translated the text from Chinese Simplified to Turkish: "Okuyucu, UTXO'ya kıyasla Cell'in programlanabilirlik açısından geliştiğini kolayca görebilir."

• Cell herhangi bir hesaplamayı programlayabilir, yalnızca belirli hesaplamaları değil; mülkiyet doğrulaması daha esnek olacaktır;
• Data ve Type alanları sayesinde, Cell ekstra durumları kaydedebilir; bu da Cell'in "Kullanıcı Tanımlı Token (UDT)" olarak adlandırılan şeyi taşımasına izin verir.

结合 Cell 本身的 "交易输出" 结构，这两点本身能带来的好处已然非常非常巨大，但是，仅从上面的描述，我们尚不知晓 Cell 是如何实现 "一个合约在运行时访问另一个合约的状态" 的。为此，我们需要借助比特币社区探讨了很长时间的一个概念："限制条款（covenants）"。

Sınırlama Şartları ve İç Gözlem

限i̇ti̇ş şartlarının amacı, bir paranın nereye harcanabileceğini sınırlamaktır. Mevcut Bitcoin'de (henüz herhangi bir kısıtlama şartı önerisi uygulanmadı), bir fon bir kez kilidini açtıktan sonra herhangi bir yere (herhangi bir senaryo açık anahtarına ödeme yapabilir) harcanabilir. Ancak kısıtlama şartı fikriyle, onu sadece belirli bir yere harcamak için bir şekilde sınırlayabiliriz. Örneğin, belirli bir UTXO sadece belirli bir işlem tarafından harcanabilir. Bu durumda, biri bu UTXO için imza sağlayabiliyor olsa bile, harcanabileceği yer bu işlem tarafından belirlenmiştir. Bu özellik biraz garip görünebilir, ancak ilginç uygulamalara yol açabilir, daha sonra özel bir bölümde açıklanacaktır. Önemli olan, CKB'nın programlanabilirliğini daha iyi anlamamıza yardımcı olan bir özelliktir.

Rusty Russell doğru bir şekilde belirtmiştir ki, sınırlama maddesi bir işlemin "iç denetim" yeteneği olarak anlaşılabilir. Yani bir UTXO A, bir işlem B tarafından harcandığında, komut dosyası çalıştırma programı işlem B'nin bir kısmını (veya tamamını) okuyabilir ve daha sonra onların komut dosyasının önceden istediği parametrelerle uyumlu olup olmadığını kontrol edebilir. Örneğin, işlem A'nın ilk çıktısının komut dosyası açık anahtarı, UTXO A'nın komut dosyası açık anahtarının istenenle uyumlu olup olmadığı (bu, sınırlama maddesinin ilk anlamıdır) kontrol edilebilir.

Eğer tam bir içgörü yeteneğine sahipseniz, bir işlemin girişi, aynı işlemin başka bir girişinin durumunu okuyabilir, bu da "bir sözleşmenin çalışma zamanında başka bir sözleşmenin durumuna erişme" yeteneğini gerçekleştirir. Aslında, CKB Hücresi tam olarak böyle tasarlanmıştır.

基于此，我们又可以将这种完全的内省能力分成四种情形：

• Diğer (giriş ve çıkış) Lock'ları oku
• Lock 读取其它（输入和输出）的类型（以及数据）
• Diğer (giriş ve çıkış) kilitlerini oku
• Diğerlerini (giriş ve çıkış) okuyun Type (ve Veri)

Bu, bize farklı uygulama senaryolarında her bir bileşenin içgörü yeteneğini analiz etme izni verir (Lock ve Type işlev ayrımı altında) ve her bir bileşenin sağladığı programlanabilirlik artışını analiz etme izni verir.

Aşağıdaki iki bölümde, mevcut (henüz sınırlama önerileri olmayan) Bitcoin script programlama ve sınırlama önerilerinin beklendiği işlevselliği ayrı ayrı anlayacağız, böylece CKB Hücresinin nasıl programlanabileceğini ve daha iyi yapılacağını daha net anlayacağız.

Üç. Bitcoin Script Programlama

Bu bölümde, Bitcoin betik tabanlı uygulama programlamasının bir örneği olarak "Lighting Ağı" ve "Dikkatli Günlük Sözleşmesi (DLC)" kullanılacaktır. Başlamadan önce, önceki iki kavramı anlamamız gerekmektedir.

OP_IF ve "Sözleşmeli İşlemler"

İlk kavram, Bitcoin betiği içindeki işlem kontrol işaretleridir, örneğin: OP_IF, OP_ELSE. Bu işlem kodları, bilgisayar programlamadaki IF ile benzerlik gösterir ve farklı girişlere göre farklı ifadelerin çalıştırılmasını sağlar. Bitcoin betiği bağlamında, bu, birden fazla fon kilidini ayarlayabileceğimiz anlamına gelir; zaman kilidi özelliği ile birleştirildiğinde, eylemlerin önceliklendirilmesini sağlayabiliriz.

以著名的 “Karma TimeLock Sözleşmesi (HTLC)” örneği olarak, bu tür bir betik basit bir dille şöyle çevrilebilir:

Ya da, Bob bu fonları harcamak için H hash değerinin arkasındaki orijinal görüntüyü ortaya çıkarabilir ve kendi imzasını verebilir.

Ya da, Alice bu fonları kendi imzasıyla T süresinden sonra harcayabilir.

Bu "ya ... ya ..." etkisi, işlem kodu ile akış kontrolü yoluyla gerçekleştirilir.

HTLC'nin en önemli avantajı, birden fazla işlemi bir araya getirebilmesi ve atomik bir şekilde gerçekleştirebilmesidir. Örneğin, Alice, Bob ile CKB için BTC ile takas yapmak istiyor. Bob, önce bir karma değeri verip Nervos Network üzerinde bir HTLC oluşturabilir; ardından Alice, aynı karma değerini kullanan bir HTLC oluşturabilir. Ya Bob, Alice'in ödediği BTC'yi alır ve aynı zamanda orijinali ortaya çıkararak Alice'in CKB'yi Nervos Network üzerinden almasına izin verir. Ya da Bob, orijinali açıklamaz, her iki sözleşme de süresi dolarsa, Alice ve Bob kendi yatırdıkları fonları geri alabilirler.

Taproot yazılımsal çatal etkinleştikten sonra, bu çoklu kilitleme yolu özelliği MAST (Merkle Abstract Syntax Tree) 'nin tanıtılmasıyla daha da güçlendirilir: Bir kilitleme yolunu Merkle ağacındaki bir yaprak olarak görüntüleyebiliriz, her yaprak bağımsızdır, bu nedenle bu tür işlem kontrol opcode'larına ihtiyaç duyulmaz; ayrıca, bir yolun ifşa edilmesi gerekmediğinde diğer yolları ortaya çıkarmak zorunda olmadığımız için, bir çıktıya daha fazla sayıda kilitleme yolunu ekleyebiliriz ve ekonomik sorunlarla ilgilenmemiz gerekmez.

İkinci kavram "sözleşmeli işlem"dir. Sözleşmeli işlemin fikri, bazı durumlarda, bir Bitcoin işleminin blok zinciri onayını almasa bile, hala gerçek ve bağlayıcı olduğudur.

Örneğin, Alice ve Bob'un ortak sahip olduğu bir UTXO var, bu UTXO'nun harcanabilmesi için her ikisinin de imzası gerekiyor. Bu durumda, Alice harcamak için bir işlem oluşturur, değerin 60%'ını Bob'a transfer eder, kalan değeri kendine aktarır; Alice bu işlem için kendi imzasını sağlar ve ardından Bob'a gönderir. Dolayısıyla Bob için, bu işlemi Bitcoin ağına yayınlaması gerekmez ve bu işlemin blok zincirinde onaylanmasına gerek yoktur; bu işlemin ödeme etkisi gerçektir ve güvenilirdir. Çünkü Alice, bu UTXO'yu tek başına harcayamaz (bu nedenle tekrar harcayamaz) ve Alice'in sağladığı imza geçerlidir, böylece Bob istediği zaman kendi imzasını ekleyebilir ve bu ödemeyi gerçekleştirebilir. Yani Alice, bu geçerli (zincir üstü olmayan) işlem aracılığıyla Bob'a "güvenilir bir taahhüt" sağlamış olur.

承诺 işlemleri, Bitcoin uygulama programlamasının temel bir kavramıdır. Yukarıda belirtildiği gibi, Bitcoin kontratları doğrulamaya dayalı, durumsuz ve çapraz erişime izin vermez; ancak, eğer kontrat durum taşımıyorsa, bu durumlar nerede saklanır ve kontrat nasıl güvenli bir şekilde ilerler (durumu değiştirir)? Taahhüt işlemleri açık bir şekilde cevap verir: Kontratın durumu, işlemin biçiminde ifade edilebilir, böylece kontratın katılımcıları durumu kendileri saklayabilir ve blok zincirinde göstermeleri gerekmez; kontratın durum değişikliği sorunu, taahhüt işleminin nasıl güvenli bir şekilde güncelleneceğine dönüştürülebilir; Ayrıca, bir kontrata girmenin tehlikeli olabileceğinden endişe duyarsak (örneğin, her iki tarafın da imzalaması gereken bir kontrata girme riski, karşı tarafın cevap vermeme durumuyla karşı karşıya kalabilir), o zaman kontratı harcamak için önceden taahhüt işlemlerini oluşturup imzalamak riski azaltabilir ve diğer katılımcılara olan güveni ortadan kaldırabilir.

Lighting Ağı Kanalı ve Lighting Ağı

闪电 kanalı, iki tarafın karşılıklı olarak sınırsız sayıda ödeme yapabileceği bir birbirine karşı kontrattır ve herhangi bir ödemenin blok zinciri onayını alması gerekmez. Beklendiği gibi, sözleşmeli işlemler kullanılır.

“Vaad işlemleri” bölümünü açıklarken bir ödeme kanalı tanıttık. Ancak sadece 2-of-2 uzun imzalı sözleşmeyi kullanan bu tek yönlü ödemeleri gerçekleştirebilir. Yani ya hep Alice'ten Bob'a ödeme yapılır ya da tam tersi, ta ki sözleşmedeki bakiye tükenene kadar. Çift yönlü ödemeler ise, bir durum güncellemesinden sonra bir tarafın bakiyesinin öncekinden daha az olabileceği anlamına gelirken, O kişi diğer tarafın imzaladığı önceki bir vaad işlemine sahip olabilir - Eski vaad işleminin yayınlanmasını engellemek ve sadece en son vaad işlemini yayınlamasını nasıl önleyebiliriz?

闪电 ağı bu sorunu çözmek için "LN-Penalty" adı verilen bir yöntem kullanır. Şimdi, Alice ve Bob'un her birinin 5 BTC olduğunu varsayalım; şimdi Alice Bob'a 1 BTC ödemek istiyor, bu yüzden böyle bir taahhüdü imzalar ve Bob'a gönderir:

输入 #0，10 BTC： Alie-Bob 2-of-2 多签名输出（即通道合约）

Çıktı #0, 4 BTC: Alice tek imzalama.

Çıktı #1, 6 BTC: Ya Alice-Bob geçici anahtar #1 ile tek imzalı işlem yapar ya da T1 zaman kilitli işlemiyle Bob tek imzalı işlem yapar.

Bob aynı zamanda (yukarıdaki işlemle eşleşen) taahhüt işlemine de imza atar ve Alice'e gönderir:

Alie-Bob 2-of-2 multisig output (i.e., channel contract) with input #0, 10 BTC:

Çıktı #0,6 BTC: Bob tek imzalı

Çıktı #1, 4 BTC: Ya Bob-Alice geçici açık anahtar #1 ile imzalı ya da T1 zaman kilidi, Alice tek imzalı

Bu noktanın sırrı, "ortak geçici açık anahtar"da yatıyor, bu, kendi bir açık anahtarınızı ve karşı tarafın sağladığı bir açık anahtarı kullanılarak oluşturulur, örneğin, Alice-Bob ortak geçici açık anahtarı, Alice'ın kendi bir açık anahtarını ve Bob'un sağladığı bir açık anahtarı kullanarak her birinin bir kripto para birimiyle çarpılarak toplanmasıyla elde edilir. Bu şekilde oluşturulan bir açık anahtar, oluşturulduğunda hiç kimsenin onun özel anahtarını bilmediği bir şeydir. Ancak, Bob kendi sağladığı açık anahtarın özel anahtarını Alice'e söylerse, Alice bu ortak geçici açık anahtarın özel anahtarını hesaplayabilir. - Bu, Lightning Network'ün eski durumu "iptal etme" yeteneğinin temelidir.

在下一次双方要更新通道状态（发起支付）时，双方就交换上一轮中交给对方的临时公钥的私钥。如此一来，参与者就再也不敢广播自己得到的上一笔承诺交易：这笔承诺交易为己方分配价值的输出有两个路径，而临时公钥路径的私钥已被对方知道；所以一旦广播旧的承诺交易，对方就可以立即动用这个联合临时私钥，从而将这个输出中的资金全部拿走。—— 这就是 “LN-Penalty” 的含义。

Açıklamak gerekirse, etkileşim sırası şöyledir: ödeme başlatan taraf, diğer tarafa yeni geçici bir açık anahtar isteği gönderir, ardından yeni bir taahhüt işlemi oluşturur ve diğer tarafa teslim eder; taahhüt işlemine sahip olan taraf, önceki turda verdiği geçici açık anahtarın özel anahtarını diğer tarafa açıklar. Bu etkileşim sırası, katılımcıların her zaman önce yeni bir taahhüt işlemi almasını ve sonra önceki turda aldıkları taahhüt işlemini iptal etmelerini sağlar, bu nedenle güven gerektirmez.

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

İki taraf da sözleşme içindeki durumu ifade etmek için taahhüt işlemlerini kullanır ve ödemeyi miktar değişikliğiyle gösterir.

承诺交易总是花费同一个输入（需要双方同时提供签名的输入），因此所有承诺交易都是相互竞争的，最终只有一笔能够得到区块链的确认；

参与者签名的不是同一笔承诺交易（虽然它们是成对的）;而他们所签名的总是对自己更有利的交易，换句话说，参与者收到的承诺交易，总是对自己不利的;

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

在每一次支付中，双方都以新的一笔承诺交易来交换对方在上一轮使用的临时私钥，从而，交出了临时私钥的一方就不再敢广播旧的一笔承诺交易，因此，就 “撤销” 了上一笔承诺交易、更新了合约的状态；（实际上，这些承诺交易都是有效的交易，都是可以广播到区块链上的，只是参与者迫于惩罚，不敢再广播了）

Her iki tarafın da, karşı tarafın imzaladığı taahhüt işlemiyle sözleşmeden çıkabileceği bir anlaşma yapabilir; ancak, eğer taraflar işbirliği yapmak istiyorlarsa, yeni bir işlem imzalayabilir ve her iki taraf da hemen kendi paralarını geri alabilir.

Son olarak, taahhüt işlemlerine de HTLC yerleştirilebildiği için, Lightning ağı ödemeleri de iletebilir. Diyelim ki Alice, Lightning ağından oluşan bir yol bulup Daniel'e ulaşabilir, o zaman Daniel ile kanal açmadan güvenilir olmayan çoklu ödeme gerçekleştirebilir. İşte bu Lightning ağıdır.

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

Alice <-- pre-image -- Bob <-- pre-image -- Carol <-- pre-image -- Daniel

Alice, bu tür bir yol bulduğunda ve Daniel'a ödeme yapmak istediğinde, Daniel'dan bir kripto hash talep eder. Bu hash'i kullanarak Bob'a bir HTLC oluşturur ve Bob'u Carol'e bir mesaj iletecek ve aynı HTLC'yi sağlayacak şekilde uyarır. Mesajda Carol'e Daniel'a bir mesaj iletmesini ve aynı HTLC'yi sağlamasını söyler. Mesaj Daniel'a ulaştığında, Carol'a gerçek değeri açıklar ve böylece HTLC'nin değerini alır ve sözleşme durumunu günceller. Carol da aynı şekilde yapar, Bob'dan ödemesini alır ve kanal durumunu günceller. Son olarak, Bob, Alice'e gerçek değeri açıklar ve durumu günceller. HTLC'nin özelliği sayesinde, bu ödeme dizisi ya tamamen başarılı olur ya da tamamen başarısız olur, bu yüzden güven gerektirmez.

Lighting Ağı, birbirine bağlı bir dizi kanaldan oluşur; her kanal (sözleşme) birbirinden bağımsızdır. Bu, Alice'ın sadece kendi ve Bob'un kanalındaki olayları bilmesi gerektiği anlamına gelir, diğer insanların kanallarındaki etkileşimlerin sayısıyla ilgilenmesine, bu etkileşimlerin hangi para birimiyle yapıldığına veya gerçekten kanalı kullandıklarını bilmesine gerek yoktur.

Lighting Ağı'nın ölçeklenebilirliği sadece bir Lighting kanalının içinde ödeme hızının sadece tarafların donanım kaynaklarına bağlı olmamasında değil, aynı zamanda durumun dağınık depolanmasından dolayı, bireysel düğümün en düşük maliyetle en büyük kaldırayı kaldırabilmesinde de görülmektedir.

Dikkatli Günlük Sözleşmesi

DLC, İngilizce "Discreet Log Contract" (Gizli Günlük Sözleşmesi) kelimelerinin kısaltmasıdır. Bu Bitcoin betiği, dış olaylara bağlı finansal sözleşmeleri programlamak için "adaptor imzası" adı verilen bir kriptografik teknik kullanır.

适配器签名可以让一个签名仅在加入一个Özel Anahtar之后，才会变成有效的签名。以 Schnorr 签名为例，Schnorr 签名的标准形式是(R, s)，其中：

R = r.G # nonce value used for signature r multiplied by elliptic curve generated point, also known as the public key of r

s = r + Hash(R || m || P) \* p # p即为签名私钥，P为公钥

验证签名即验证 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

Açıkça, bu geçerli bir Schnorr imzası değil, doğrulama formülünden geçemiyor, ancak doğrulayıcılara sadece R2'nin özel anahtarı r2'nin bilinmesi durumunda geçerli bir imza haline getirebileceğimi kanıtlayabilirim.

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

Adaptör imzası, bir imzanın bir gizli veriye bağımlı olarak geçerliliğini ve doğrulanabilirliğini sağlar. Ancak, bu finansal sözleşmelerle ne ilgisi var?

假设 Alice ve Bob, bir futbol maçının sonucuna bahis oynamak istiyor. Alice ve Bob sırasıyla Yeşil Canavar ve Arlina'nın galibiyetine bahis yaparlar, bahis miktarı 1 BTC'dir. Ayrıca, spor yayın sitesi Carol, maçın sonucu açıklandığında sonucun imzasını s_c_i ile bir nonce R_c kullanarak yayınlamayı taahhüt eder.

Bununla ilgili olarak, üç olası sonuç bulunmaktadır (bu nedenle Carol'ın imzası üç farklı olasılığa sahiptir):

• Yeşil Büyü kazandı, Alice 1 BTC kazandı.
• Arinna wins, Bob wins 1 BTC
• Berabere, iki kişinin fonları iade edilir

为此，两人为每一种结果创建一笔承诺交易。例如，他们为第一种结果创建的承诺交易是这样的：

Girdi #0,2 BTC: Alie-Bob 2-of-2 çok imzalı çıktı (yani bahis sözleşmesi)

Çıktı #0,2 BTC: Alice tek imzalı

Ancak, Alice ve Bob'un bu işlem için oluşturdukları imza (R, s) değil, adaptör imzası (R, s')dir. Yani, her iki tarafın da birbirlerine verdiği imzalar doğrudan bu sözleşmenin kilidini açmak için kullanılamaz, ancak bir gizli değer açıklanmalıdır. Bu gizli değer, s_c_1.G'nin özgül değeridir, yani Carol'ün imzası! Carol'ün imzasının nonce değeri zaten belirlendiğinden (R_c'dir), s_c_1.G oluşturulabilir (s_c_1.G = R_c + Hash(R_c || '绿魔胜出' || PK_c) * PK_c).

Sonuç açıklandığında, yeşil büyü kazanırsa Carol, imza (R_c, s_c_1) yayınlayacak, bu durumda Alice veya Bob, rakibin adaptör imzasını tamamlayarak kendi imzasını ekleyebilir ve yukarıdaki işlemi geçerli bir işlem haline getirebilir, ayrıca ağa yayabilir ve yerleşim etkisini tetikleyebilir. Ancak eğer yeşil büyü kazanmazsa, Carol s_c_1 yayınlamayacak ve bu taahhüt işlemi geçerli bir işlem olamayacaktır.

Bu şekilde, diğer iki işlem de aynıdır. Alice ve Bob, bu sözleşmenin dış olaylara (daha doğrusu bir imza şeklindeki bir bildirim aracılığıyla dış olaylara dayalı olarak) bağlı olarak yürütülmesini sağlarlar ve karşı tarafa güven gerekmez. Vadeli işlemler, opsiyonlar gibi çeşitli finansal sözleşmeler bu yöntemle uygulanabilir.

Diğer uygulama biçimlerine kıyasla, dikkatli günlük akdi sözleşmesinin en büyük özelliği gizliliktir: (1) Alice ve Bob, Carol'a kendi verilerini kullandıklarını bildirmek zorunda değillerdir, bu sözleşmenin yürütülmesini hiç etkilemez; (2) On-chain gözlemciler (Carol dahil), Alice ve Bob'un sözleşme yürütme işlemleri aracılığıyla hangi web sitesinin hizmetini kullandıklarını veya sözleşmelerinin bir bahis sözleşmesi olduğunu (bir lightning kanalı olmadığını) bilemeyeceklerdir.

4. Kısıtlama Koşulları Uygulama Kılavuzu

OP_CTV ve Trafik Kontrolü

Bitcoin topluluğunun geliştiricileri tarafından, kısıtlama maddeleri olarak sınıflandırılabilecek çeşitli öneriler sunulmuştur. Şu anda, en ünlü önerilerden biri OP_CHECKTEMPLATEVERIFY (OP_CTV) olarak kabul edilir. Bu öneri, oldukça basit bir kavramı korurken, büyük bir esneklik sağladığı için sadece Bitcoin topluluğu tarafından değil, aynı zamanda sadeliği savunan birçok kişi tarafından da benimsenmiştir. OP_CTV'nin fikri, bir kriptoğrafik hash değeri taahhüt etmek suretiyle bir senaryo içinde fonların yalnızca bu hash değerini kullanan bir işlem tarafından harcanabileceğini belirtmektir; bu hash değeri, işlem çıktılarını ve çoğu alanını taahhüt ederken, işlemin girişlerini taahhüt etmez, yalnızca giriş miktarını taahhüt eder.

""Trafik kontrolü", OP\_CTV özelliğini yansıtabilen iyi bir örnektir. Temel uygulama senaryosu, birçok kullanıcının bir borsadan (güven gerektiren bir ortam) fon havuzuna çıkış yapmasına yardımcı olmaktır; çünkü bu fon havuzu, gelecekteki harcama şeklini OP\_CTV ile planladığı için, kullanıcıların herhangi bir yardım olmaksızın güvensiz bir şekilde bu fon havuzundan çıkış yapabileceğini garanti eder; ayrıca bu fon havuzu sadece bir UTXO olarak göründüğü için, yüksek talep olduğunda (n adet çıkıştan tek bir çıkışa; ve n adet işlem yerine tek bir işlem) büyük miktarda işlem ücreti ödemekten kaçınır. Havuzdaki kullanıcılar daha sonra havuzdan çıkabilirler."

Diyelim ki Alice, Bob, Carol borsalardan sırasıyla 5 BTC, 3 BTC ve 2 BTC çekmek istiyor. Daha sonra borsa 3 OP_CTV dal ile 10 BTC çıktı yapabilirsiniz. Diyelim ki Alice para çekmek istiyor, şube 1'i kullanabilir ve bu dalın OP_CTV'u tarafından kullanılan hash değerle temsil edilen işlem, biri Alice'e 5 BTC tahsis etmek olan iki çıktı oluşturacaktır; Diğer çıktı ise, bir işlemi taahhüt etmek için OP_CTV kullanan ve Bob'un yalnızca 3 BTC çıkarmasına ve kalan 2 BTC Carol'a göndermesine izin veren bir havuzdur.

Bob ya da Carol para çekmek istediğinde aynı prensip geçerlidir. Para çekerken, sadece ilgili OP_CTV kontrolünü geçebilen işlemleri kullanabilirler, yani yalnızca kendilerine belirli bir miktar ödeme yapabilirler, istedikleri miktarda para çekemezler; kalan fonlar, OP_CTV kilidi kullanan bir fon havuzuna geri dönecektir, böylece kullanıcıların para çekme sırası ne olursa olsun, kalan kullanıcılar havuzdan güvensiz bir şekilde çıkabilir.

OP_CTV'nin soyut anlamıyla, buradaki rolü, bu fon havuzu sözleşmesinin hangi yolunu takip ettiğini, hangi duruma geldiğini önemsemeden sözleşmenin yaşam döngüsünün sonuna giden yolu planlamaktır, böylece güvene dayalı çıkış özelliğini koruyabilir.

这 OP_CTV'nin çok ilginç bir kullanımı daha vardır: "gizli ve açılmayan tek yönlü ödeme kanalı". Diyelim ki Alice böyle bir fon havuzu oluşturdu ve fonların aşağıdaki komut dosyasıyla bir çıktıya güvensiz bir şekilde çıkabileceğinden emin oldu:

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

Alice, Bob'a açıklamazsa, Bob böyle bir çıktının varlığını bilemez; ancak Alice, Bob'a açıkladığında, Bob bu çıktıyı zamanla sınırlı tek yönlü bir ödeme kanalı olarak kullanabilir. Alice hemen bu fonları Bob'a ödemek için beklemesi gerekmez, blok zincirinin onaylanmasını beklemesi gerekmez. Bob, Alice'in ona söz verdiği işlemi zincire kaydetmesi yeterli olduğunda, Alice'in bunu tek başına harcamasına izin verir.

OP_Vault ve 01928374656574839201

OP_VAULT, "Vaults" için özel olarak oluşturulan bir sigorta kasası sözleşmesi yapısını oluşturmak için önerilen bir sınırlama teklifidir.

保险柜合约, daha güvenli ve daha üst düzeyde bir özgün saklama şekli olmayı amaçlamaktadır. Mevcut çoklu imza sözleşmeleri tek bir özel anahtarın tek nokta arızasından kurtulabilir, ancak saldırganlar eşik değerindeki özel anahtarları gerçekten elde ederse, cüzdan sahibinin yapabileceği bir şey yoktur. Sigorta kabini, fonlara tek seferlik harcama sınırlaması uygulamayı umuyor; aynı zamanda normal yoldan para çekme işlemi yapılırken, çekme işlemi bir bekleme süresi zorunlu olarak uygulanacak; ve bekleme süresi içinde, çekme işlemi acil durumda cüzdanın işlemini kesintiye uğratabilir. Bu tür bir sözleşme, hatta ele geçirilse bile cüzdan sahibi (acil kurtarma dalı kullanarak) karşı saldırı başlatabilir.

Teorik olarak, OP_CTV de bu tür bir akıllı sözleşmeyi programlayabilir, ancak birçok dezavantajı vardır, bunlardan biri de işlem ücretidir: taahhüt edilen işlemle birlikte, işlemin ödeyeceği ücreti de taahhüt eder. Bu tür bir sözleşmenin kullanımını düşünürsek, sözleşme ve çekim arasındaki süre uzun olmalıdır, bu nedenle uygun bir ücreti tahmin etmek neredeyse imkansızdır. OP_CTV'nin girişleri sınırlamadığı göz önüne alındığında, girişi artırarak ücreti artırabilirsiniz, ancak sağlanan girişlerin tamamı ücrete dönüşeceğinden bu pratik değildir; diğer bir seçenek de CPFP'dir, yani çıkarılan fonlarla yeni bir işlemde ücret sağlamaktır. Ayrıca, OP_CTV'nin kullanılması, bu tür bir sigorta kasası sözleşmesinin toplu çekim yapamayacağı anlamına gelir (tabii ki toplu olarak geri de yüklenemez).

OP_VAULT önerisi, bu sorunları çözmek için yeni bir işlem kodu (OP_VAULT ve OP_UNVAULT) önermeyi denemektedir. OP_UNVAULT, toplu geri alma için tasarlanmıştır, şu anda bunu sunmuyoruz. OP_VAULT'un işlevi şöyledir: Bir script ağacının bir dalına yerleştirdiğimizde, belirli bir parametre olmadan bir işlem kodu (örneğin OP_CTV) taahhüt edebilir; bu dalı harcarken, işlem belirli parametreleri alabilir, ancak diğer dalları değiştiremez. Bu nedenle, önceden bir ücret belirlemesi yapmak zorunda değildir, bu dalı harcamak için bir ücret belirleyebilir; bu dalın bir zaman kilidi de varsa, bir zaman kilidini zorunlu kılar; son olarak, sadece kendi dalını değiştirebileceği için, yeni bir script ağacındaki diğer dallar (acil kurtarma dalı dahil) değiştirilmez, bu nedenle böyle bir para çekme işlemini durdurabilmemize olanak tanır.

OP_VAULT işlem kodunun, OP_TLUV gibi başka bir kısıtlama önerisine benzer şekilde hareket ettiği iki önemli nokta da vardır: (1) Jeremy Rubin doğru bir şekilde belirttiği gibi, OP_TLUV/OP_VAULT bir işlem kodunu taahhüt eder ve bu işlem kodunun yeni bir işlem aracılığıyla parametre olarak iletilmesine izin vererek tüm script ağacı yapraklarını günceller; bu artık "gelen verileri belirli bir koşula göre doğrulama" değil, "gelen verilerden anlamlı yeni veriler üretme" anlamına gelir, ancak bununla yapabileceğimiz hesaplamalar sınırlıdır.

完整的 OP_VAULT 提议也利用了一些交易池策略（mempool policy）上的提议（比如 v3 格式的交易）以取得更好的效果。这提醒了我们 “编程” 的含义可以比我们想象的更为广泛。（一个相似的例子是 Nervos Network 里面的 Open Transaction。）

5. CKB'nın Anlaşılması

上述 iki bölümde, Bitcoin UTXO yapıları gibi daha kısıtlı bir yapı üzerinde, ilginç uygulamaları nasıl betik programlama ile oluşturabileceğimizi ve bu yapıya içgörü yeteneği eklemeye yönelik önerileri tanıttık.

UTXO, birçok uygulamayı programlama yeteneğine sahip olsa da, okuyucuların bunların dezavantajlarını veya optimize edilebilecek alanları fark etmeleri kolaydır, örneğin:

• LN-Penalty'de, kanal katılımcıları, dolandırıcılığa karşı önlem almak için her bir taahhüt işlemini ve ilgili ceza sırrı değerini kaydetmek zorundadır, bu da bir depolama yükü oluşturur. Eğer sadece en son taahhüt işlemi geçerli olacak ve eski taahhüt işlemleri geçerli olmayacak şekilde bir mekanizma varsa, bu yükten kurtulmak mümkün olur ve ayrıca düğümün arızalanması nedeniyle yanlışlıkla eski taahhüt işlemlerini zincire eklemesiyle ilgili sorunlar da ortadan kalkar.
• DLC'de, bir olayın olası sonuçları çoktur ve tarafların birbirlerine önceden ürettikleri ve teslim ettikleri imzalar da çoktur, bu da büyük bir yük oluşturur; bunun yanı sıra, DLC sözleşmesinin getirisi doğrudan açık anahtarla bağlantılıdır, bu nedenle pozisyonu transfer etmek zordur, sözleşmenin pozisyonunu transfer etmek için bir yol var mıdır?

实际上，比特币社区已经为这些问题提出了答案，基本上跟一种 Sighash 提议（BIP-118 AnyPrevOut）有关。

Ancak, eğer CKB üzerinde programlama yapıyorsak, BIP-118 şu anda kullanılabilir durumda (bu tür Sighash etiketlerini içselleme ve hedefe yönelik doğrulama imkanıyla taklit edilebilir).

Bitcoin programlama öğrenerek, hem "işlem çıktısı" formatında nasıl programlanabileceğimizi (CKB'nin neyi programlayabileceğini) öğrendik, hem de bu uygulamaların nasıl geliştirilebileceği konusunda bilgi sahibi olduk (bu uygulamaları CKB üzerinde nasıl programlayarak CKB'nin yeteneklerini nasıl kullanabileceğimizi). CKB geliştiricileri için, Bitcoin betik tabanlı programlamayı bir öğrenme kaynağı, hatta bir kısayol olarak kullanabiliriz.

Aşağıda, CKB programlamasının farklı modüllerinin programlanabilirliğini ayrı ayrı analiz edelim. İç gözlem yeteneğini şimdilik göz ardı edelim.

Programlanabilir isteğe bağlı hesaplama kiliti

如上所述，UTXO 是不能编程任意计算的。而 Lock 可以，这就意味着 Lock 可以编程出（限制条款部署前）基于 UTXO 编程的所有东西，包括但不限于上文所述的闪电通道和 DLC。

Bu yetenek ayrıca Lock'un UTXO'dan daha fazla ve daha esnek kimlik doğrulama yöntemleri kullanabilmesini sağlar. Örneğin, CKB üzerinde bir tarafın ECDSA imzası kullanması, diğer tarafın RSA imzası kullanmasıyla bir şimşek kanalı uygulayabiliriz.

Aslında, bu, CKB üzerinde insanların keşfetmeye başladığı alanlardan biri olan, bu esnek kimlik doğrulama yeteneğini kullanarak kullanıcıların kendi hesaplarında kullanılmasıdır, böylece "hesap soyutlama" olarak adlandırılan şey gerçekleştirilir - işlemin geçerliliğini yetkilendirme ve kontrol yetkisinin geri alınması son derece esnek ve neredeyse sınırsızdır. İlkeler açısından, bu "çoklu harcama dalı" ve "herhangi bir kimlik doğrulama yöntemi" nin birleşimidir. Örnekler arasında JoyID Cüzdanı, UniPass bulunur.

此外, Lock ayrıca eltoo teklifini gerçekleştirebilir, böylece yalnızca en son taahhüt işlemini içeren bir şimşek kanalı korunabilir (aslında, eltoo tüm noktadan noktaya sözleşmeleri basitleştirebilir).

**Programlanabilirlik Özelliğine Sahip Type **

Yukarıda belirtildiği gibi, Type'ın büyük bir kullanımı UDT'nin programlanmasıdır. Lock ile birleştirildiğinde, bu UDT'ye dayalı bir şimşek kanalının (ve diğer türdeki sözleşmelerin) gerçekleştirilebileceği anlamına gelir.

实际上，Lock 和 Type 的分割可以视为一种安全性升级：Lock 专注于实现保管方法或者合约式协议，而 Type 专注于 UDT 的定义。

UDT'nin tanım başlatma kontrolüne dayalı olması, UDT'nin CKB gibi bir şekilde sözleşmelere katılmasını sağlar.

"Örnek vermek gerekirse: Yazarın daha önce sunmuş olduğu bir protokol, Bitcoin üzerinde güveni olmayan NFT teminatlı borç verme gerçekleştirmek için tasarlanmıştır. Bu protokolün temelinde, değeri giriş değerinden daha düşük olan bir taahhüt işlemi bulunmaktadır (bu nedenle henüz geçerli bir işlem olarak kabul edilmemektedir), ancak bu işlem için yeterli miktarda giriş sağlanır sağlanmaz, işlem geçerli hale gelir: Borç veren, borçlunun borcunu ödeyebilmesi durumunda, teminat olarak verilen NFT'yi elinde tutamaz. Ancak bu güveni olmayan taahhüt işleminin temelinde, işlemin giriş ve çıkış miktarlarının kontrolü bulunmaktadır, bu nedenle borçlu yalnızca Bitcoin kullanarak borcunu ödeyebilir - borçlu ve borç veren başka bir para birimini (örneğin RGB protokolüyle çıkarılan USDT) kabul etmek istese bile, Bitcoin taahhüt işlemi, borçlu yeterli miktarda USDT ödemesini yapmış olsa bile kendi NFT'sini geri almanın garantisini sağlayamaz çünkü Bitcoin işlemi USDT'nin durumunu hiç bilemez! (Düzeltme: Başka bir deyişle, USDT ödemesi koşuluyla bir taahhüt işlemi oluşturulamaz.)"

UDT tanımına göre bir kontrol başlatabilirsek, borç verenin USDT ile ödeme yapmasına izin vermek için bir taahhüt işlemi daha imzalamasını sağlayabiliriz. İşlem, girişteki USDT miktarını ve çıkıştaki USDT miktarını kontrol ederek kullanıcıya USDT kullanarak ödeme yapma yetkisi sağlar.

修订: Burada teminat olarak kullanılan NFT ve geri ödeme için kullanılan jetonun aynı protokol (örneğin RGB) tarafından çıkarıldığı varsayılırsa, buradaki sorun RGB protokolüne dayalı bir taahhüt işlemi oluşturarak çözülebilir. Bu işlem, NFT'nin durum geçişini ve geri ödemeyi senkronize bir şekilde gerçekleştirmek için (iki durum geçişiyle bağlantılı olarak) kullanılabilir. Ancak RGB işlemleri de Bitcoin işlemlerine dayandığı için, bu taahhüt işleminin oluşturulması belirli bir zorlukla karşılaşabilir. Sonuç olarak, sorun çözülebilir, ancak jeton birinci sınıf bir varlık olamaz.

Sonraki adımızda içgörü yeteneğini düşünelim.

锁定 读取其他锁定

Bu, önerilen sınırlama koşullarının uygulanmasının, Bitcoin UTXO'daki tüm programlama olasılıklarını kapsadığı anlamına gelir. Bu, önceki bölümde bahsedilen kasaya benzer sözleşmeleri ve OP_CTV'ye dayalı uygulamaları (örneğin, tıkanıklık kontrolü) içerir.

XueJie daha önce çok ilginç bir örnek vermişti: CKB üzerinde bir alıcı hesap hücresi oluşturabilirsiniz; bu tür bir hücreyi bir işlemin girdisi olarak kullandığınızda, çıkış hücresi (aynı kilit kullanılarak) daha fazla kapasiteye sahipse, bu girişin imzasını sağlamanıza gerek kalmaz ve işlemin geçerliliğini etkilemez. Aslında, bu tür bir hücre iç denetim olmadan gerçekleştirilemez. Bu tür bir alıcı hesap hücresi, kurumların alım şekli olarak çok uygundur çünkü fonları toplayabilir, ancak mahremiyet açısından dezavantajlıdır.

Kilit 01928374656574839201其它 Tür s（以及 Veri）

Bu yeteneğin ilginç bir uygulaması, hisse senedi Token'ıdır. Lock, kendi Kapasitesini kullanıp kullanamayacağını ve bu Kapasitenin nereye harcanabileceğini (Lock'un kendi yeteneklerini içeren diğer girişlere bakarak) belirlemek için Token miktarına göre karar verecektir.

Diğer Kilitleri Oku Türkçe

Belirsiz, ancak faydalı olabileceğini varsayabiliriz. Örneğin, işlemin giriş ve çıkışının Kilit s değerlerini Type içinde kontrol edebilirsiniz ve aynı tutabilirsiniz.

Type Scirpt 读取其它 Type s（以及 Data）

集换卡？集齐 n 个 token 可以换取更大的一个 token : ) -> Takas kartı mı? n adet jeton toplayarak daha büyük bir jeton alabilirsiniz : )

Altı. Sonuç

与此前出现的可编程任意计算的akıllı sözleşme sistemleri (örneğin Ethereum) karşılaştırıldığında, Nervos Network farklı bir yapı benimsemiştir; bu nedenle, geçmişteki akıllı sözleşme sistemlerine olan anlayış, genellikle Nervos Network'ün anlaşılmasında temel oluşturamamaktadır. Bu makale, CKB Hücresi'nden daha sınırlı bir yapı olan BTC UTXO'nun uygulama programlama yoluyla CKB Hücresi'nin programlanabilirliğini anlama yöntemi sunmaktadır. Ayrıca, Hücre'nin "sözleşme ötesi erişim" yeteneğini anlamak için "özgünleme" kavramını kullanarak, özgünleme yeteneği kullanılan durumları ayırabilir ve onlar için belirli amaçlar belirleyebiliriz.

Revizyon:

1. Cross-access capability of Cell is not considered (i.e. introspection capability). Lock s can be considered as a stateful and highly programmable Bitcoin, so based on this point alone, it can be used to program all applications based on Bitcoin.

2. 01928374656574839201。01928374656574839201 Cell 01928374656574839201 交叉访问能力（即内省能力），lock s 和 type s 01928374656574839201 认为是一种安全性升级：它切分了 UDT 的 01928374656574839201 与 保管方法；此外，可暴露状态的 type s（以及 Data）实现了 UDT is first-class citizen 的效果。

Yukarıdaki iki nokta, "BTC + RGB" ile aynı paradigmaya sahip, ancak daha güçlü bir programlama yeteneği olduğu anlamına gelir.

3. Cell'ın öz denetim yeteneklerini düşünerek, Cell post-kovent BTC UTXO'dan daha güçlü programlama yetenekleri elde edebilir ve BTC + RGB'nin gerçekleştirmesinin zor olduğu bazı şeyleri gerçekleştirebilir (çünkü BTC RGB'nin durumunu okuyamaz).

Bu kullanımlar hakkında, bu makalede çok sayıda belirli örnek veremiyoruz, ancak bu, yazarın CKB ekosistemi hakkında yeterli bilgiye sahip olmamasından kaynaklanmaktadır. Zamanla, insanların bunlara giderek daha fazla hayal gücü katıp bugün hayal edilemeyecek uygulamaları bir araya getireceklerine inanıyoruz.

Teşekkürler

Teşekkürler Retric, Jan Xie ve Xue Jie, yazı yazma sürecinde sağladıkları geri bildirim için. Tabii ki, tüm hatalar bana aittir.

参考文献：

5._07_05_giriş_ckb_programlama_doğrulama_modeli/

6.（二）DLC（谨慎日志合约）

13._SORU/tartışmalar/7