Bir sistemin programlanabilirliğini anlamak, sistemin yapısal özelliklerini tanımlamamızı gerektirir. Bitcoin Script tabanlı uygulama programlamanın araştırılması, CKB Cell'in temel yapısını ve programlama paradigmasını anlamamıza yardımcı olur. Sadece bu da değil, aynı zamanda CKB'nin programlama bileşenlerini doğru parçalara ayırır ve her bir parçanın getirdiği programlanabilirlik kazanımlarını anlamamıza yardımcı olur.
I. Giriş
"Programlanabilirlik", insanların blok zinciri sistemlerini karşılaştırırken sıklıkla kullandıkları bir boyuttur. Bununla birlikte, programlanabilirliğin nasıl tanımlandığı konusunda genellikle anlaşmazlık vardır. Yaygın bir ifade, "XX blok zinciri, Turing-tam programlama dillerini destekler" veya "XX blok zinciri, genel amaçlı programlamayı destekler" şeklindedir ve bu, buradaki "XX blok zincirinin" güçlü programlanabilirliğe sahip olduğunu belirtmeyi amaçlamaktadır. Bu ifadelerin anlamlarında bazı gerçekler var: Turing-tam programlamayı destekleyen sistemlerin programlanması genellikle desteklemeyenlere göre daha kolaydır. Bununla birlikte, bir akıllı sözleşme sisteminin yapısal özelliklerinin birçok yönü vardır ve bu ifade bunlardan yalnızca birine değinir, bu nedenle geliştiricilerin onun tarafından yönlendirilmediği ve sıradan kullanıcılara güvenilemeyeceği gerçeğiyle yeterince derinlemesine anlaşılmak yeterli değildir.
Bir akıllı sözleşme sisteminin yapısal özellikleri şunları içerir:
Devlet ifadesinin temel biçimi (sözleşme) (hesap ve ticaret çıktısı)
Keyfi hesaplamanın programlanmasına izin verilip verilmediği ("Turing-complete" terimi bununla ilgilidir)
Yürütme süreci yeni veriler oluşturuyor mu, yoksa sadece boolean'ları mı dağıtıyor? (İşlem ve Doğrulama)
Sözleşmeye ek durumların kaydedilmesine izin verilip verilmeyeceği
Bir sözleşmenin yürütüldüğünde başka bir sözleşmenin durumuna erişiminin olup olmadığı
Bu nedenle, "programlanabilir keyfi hesaplamaya" ek olarak, bir akıllı sözleşme sisteminin programlanabilirliğini etkileyen en az dört özellik vardır. Hatta bu diğer özelliklerin daha önemli olduğu söylenebilir, çünkü neyin elde edilmesinin kolay ve neyin zor olduğunu daha derin bir düzeyde belirlerler; Daha ekonomik bir uygulama nedir ve daha az verimli bir uygulama nedir?
Örneğin, Ethereum genellikle iyi programlanabilirliğin bir örneği olarak gösterilir, ancak Ethereum'daki temel durum ifadesi biçimi, eşler arası sözleşmelerin (örneğin, ödeme ağ geçitleri, bire bir bahis sözleşmeleri) programlanmasını zorlaştıran bir hesaptır - kesinlikle imkansız değil, sadece nankör. Ethereum ekosisteminin bir ödeme kanalı/durum kanalı uygulamaya çalışması alışılmadık bir durum değil ve pek çok teorik tartışma yapıldı, ancak bu projeler artık aktif görünmüyor - ve bu açıkça geliştiricilerin çaba eksikliğinden sorumlu tutulamaz. Bugün Ethereum'da aktif olan projelerin "eşler arası sözleşmeler" yerine "havuzlar" şeklini alması tesadüf değildir. Benzer şekilde, insanlar Ethereum'un programlanabilirliğinden memnun olabilir, ancak hesap modeli, doğası gereği "hesap soyutlaması" (cüzdan kavramının bir genellemesi olarak da anlaşılabilir) elde etmede eksiktir.
Aynı şekilde, CKB'nin programlanabilirliğini araştırmak, CKB akıllı sözleşme sisteminin yapısal özelliklerini de bu yönlerden anlamamızı gerektirir. Zaten bildiğimiz şey, CKB'nin keyfi hesaplamaların programlanmasına izin verdiği, bir sözleşme içinde ek durumun kaydedilmesine izin verdiği ve bir sözleşmenin yürütüldüğünde başka bir sözleşmenin durumuna erişmesine izin verdiğidir. Bununla birlikte, sözleşmenin şekli, onu Ethereum'dan temelde farklı kılan bir işlemin ("hücre" olarak adlandırılır) çıktısıdır. Bu nedenle, Ethereum akıllı sözleşme sistemini ve içindeki sözleşme örneklerini anlamak, CKB'nin bu yapısal özellikleri nasıl uyguladığını anlamamıza veya CKB'nin programlanabilirliğini anlamamıza yardımcı olmaz.
Neyse ki, Bitcoin'deki akıllı sözleşmeler, CKB'nin programlanabilirliğini anlamak için en iyi temeli sağlıyor gibi görünüyor. Bunun nedeni, yalnızca Bitcoin'in durum temsilinin temel biçiminin aynı zamanda işlemlerin çıktısı ("UTXO'lar" olarak adlandırılır) olması değil, aynı zamanda Bitcoin topluluğu tarafından önerilen "sözleşmeler" adı verilen bir kavramın yardımıyla, CKB'nin neden bu yapısal özelliklere sahip olduğunu anlayabilmemiz ve her birinin getirdiği programlanabilirlik kazanımlarını tanımlayarak nihai etkiyi uygun şekilde birkaç parçaya ayırabilmemizdir.
II. CKB V.S. BTC: Daha Ne Var?
(1) Temel yapı
Bitcoin'in durum temsilinin temel biçimi olarak, Bitcoin'in UTXO'su ("Harcanmamış İşlem Çıktısı") iki alana sahiptir:
Satoshi'deki miktar, UTXO'nun sahip olduğu Bitcoin'in değerini gösterir;
Kilit komut dosyası olarak da bilinen komut dosyası açık anahtarı, fonları harcamak için yerine getirilmesi gereken koşulları, yani fonların kilidini açma koşullarını belirleyen akıllı sözleşme programını temsil eder.
Daha sonra gelen akıllı sözleşme sistemleriyle karşılaştırıldığında, Bitcoin Script oldukça sınırlıdır:
Keyfi hesaplamaların programlanmasına izin vermez; Doğrulama için kullanılabilecek yalnızca birkaç pratik hesaplama vardır (imza kontrolü, hash öncesi kontrol, zaman kontrolü)
Sözleşmeye ek durumların kaydedilmesine izin vermez; (Örneğin, bir seferde harcanan orantılı/maksimum para miktarını sınırlamak için bir komut dosyası kullanamazsınız; Ayrıca içinde bir jeton gizlemenin bir yolu yoktur)
Ayrıca, yürütme sırasında başka bir sözleşmenin durumuna erişime izin vermez (her komut dosyası ayrı bir evrendir ve birbirine bağlı değildir).
Bu tür komut dosyası oluşturma, sınırlı olsa da, harika uygulamaları programlama yeteneğinden yoksun değildir ve bu, CKB programlanabilirliğini keşfetmemizin temelidir. Daha sonra Bitcoin Script programlamanın iki örneğini tanıtacak bir bölüm olacak.
Buna karşılık, CKB'nin durum birimi "hücre" olarak adlandırılır ve dört alana sahiptir:
Kapasite, UTXO miktarına benzer şekilde, hücrenin kaplayabileceği alan miktarını bayt cinsinden ifade eder.
Kilit, UTXO komut dosyası genel anahtarına benzer şekilde, hücrenin sahipliğini tanımlar; Yalnızca sağlanan veriler kilitten geçebildiğinde hücre "güncellenebilir" (veya hücre serbest bırakılabilir ve kapasite yeni hücreler basmak için kullanılabilir);
Hacmi Kapasite ile sınırlı olan veri, veri, keyfi veriler;
Tür, Verileri güncellemek için koşulları ayarlayan isteğe bağlı bir komut dosyası.
Ek olarak, Kilit ve Tip, keyfi hesaplamalar için programlanabilir. Herhangi bir imza doğrulama algoritmasını programlayabilir, görüntü öncesi kontrol için herhangi bir karma algoritmayı programlayabilirsiniz vb.
Okuyucuların, programlanabilirlik Cell'in UTXO'lara göre nasıl geliştiğini görmesi kolaydır:
Hücreler, yalnızca birkaç özel hesaplama yerine rastgele hesaplamalarla programlanabilir; Sahiplik doğrulaması daha esnek olacaktır;
Veri ve Tür alanları nedeniyle, hücre ek durumlar kaydedebilir; Bu, hücrenin "UDT" (kullanıcı tanımlı belirteç) olarak bilinen şeyi taşımasına izin verir.
Hücrenin kendisinin "işlem çıktısı" yapısı ile birleştiğinde, bu iki noktanın kendi içlerindeki faydaları çok, çok önemlidir, ancak yalnızca yukarıdaki açıklamadan, hücrenin "bir sözleşmenin çalışma zamanında başka bir sözleşmenin durumuna eriştiğini" nasıl başardığını bilmiyoruz. Bunu yapmak için, Bitcoin topluluğunda uzun süredir tartışılan bir kavramdan yararlanmamız gerekiyor: "sözleşmeler".
(2) Sınırlamalar ve iç gözlem
Bir kısıtlama maddesinin asıl amacı, bir miktar paranın nereye harcanabileceğini sınırlamaktır. Mevcut Bitcoin'de (herhangi bir kısıtlama önerilmemiştir), kilidi açıldıktan sonra tek bir miktar para herhangi bir yerde harcanabilir (rastgele bir komut dosyası açık anahtarına ödenebilir). Ancak kısıtlama maddesinin fikri, onu belirli yerlerle sınırlayacak şekilde harcanabilmesidir, örneğin, belirli bir UTXO yalnızca belirli bir işlem tarafından harcanacaktır, böylece birisi UTXO için bir imza sağlasa bile, nerede harcanabileceği o işlem tarafından zaten belirlenmiştir. Bu biraz garip görünebilir, ancak daha sonra bir bölümde ele alınacak olan bazı ilginç uygulamalara yol açabilir. Daha da önemlisi, CKB programlanabilirliğini daha iyi anlamamızın anahtarıdır.
Rusty Russell haklı olarak, bir kısıtlamanın ticaret yapmak için bir "iç gözlem" yeteneği olarak anlaşılabileceğine işaret eder, yani bir UTXO A bir B işlemi tarafından harcandığında, bir komut dosyası operatörü B işleminin bir kısmını (veya tamamını) okuyabilir ve ardından komut dosyası tarafından önceden talep edilen parametrelerle eşleşip eşleşmediğini kontrol edebilir. Örneğin, A işleminin ilk çıktısı için komut dosyası ortak anahtarının UTXO A'nın komut dosyası genel anahtarı için gerekli olanla eşleşip eşleşmediği (kısıtlamanın başlangıçta anlamı budur).
Zeki okuyucu, tam bir iç gözlemle, bir işlemin girdisinin aynı işlemin başka bir girdisinin durumunu okuyabildiğini fark edecektir, bu da bir sözleşmenin çalışma zamanında başka bir sözleşmenin durumuna erişme yeteneğini sağlar. Aslında, CKB Cell tam olarak bu şekilde tasarlandı.
Buna dayanarak, bu tam iç gözlem kapasitesini dört senaryoya bölebiliriz:
Kilit, diğer (giriş ve çıkış) kilitleri okur
Kilit, diğerinin (giriş ve çıkış) Tipini (ve Verilerini) okur
Tip diğer (giriş ve çıkış) kilitleri okur
Tip, diğerinin Tipini (ve Verisini) okur (giriş ve çıkış)
Bu, belirli varsayımlar altında (işlevlerin Kilit ve Tip arasındaki bölünmesi), yani her bir parçanın bize getirdiği programlanabilirlik kazancı altında farklı kullanım durumlarında her bir parçanın iç gözlem yeteneklerinin rolünü analiz etmemizi sağlar.
Aşağıdaki iki bölümde, CKB Cell'in nasıl programlanabileceği ve daha iyi yapılabileceği konusunda somut bir anlayış sağlamak için Bitcoin Script'in mevcut (ve henüz önerilmemiş) programlamasına ve önerilen kısıtlamanın elde etmesi beklenen olası işlevselliğe bakacağız.
III. Bitcoin Komut Dosyası Programlama
Bu bölümde, Bitcoin Script tabanlı uygulama programlama örnekleri olarak "Lightning Channel/Lightning Network" ve "Caution Journal Contract (DLC)" kullanacağız. Buna girmeden önce, iki şeyi ele alalım.
(1) OP_IF ve "Taahhüt Anlaşmaları"
İlk konsept, Bitcoin Script'teki akış kontrolü işlem kodudur, örneğin: OP_IF, OP_ELSE. Bu işlem kodları, bilgisayar programlamadaki IF'den farklı değildir ve amaçları, farklı girdilere dayalı olarak farklı ifadeler yürütmektir. Bitcoin Script bağlamında bu, fonlar için birden fazla kilit açma yolu belirleyebileceğimiz anlamına gelir; Zaman kilidi özelliği ile birlikte bu, eylemlere öncelik atayabileceğimiz anlamına gelir.
Örnek olarak ünlü "Hash Timelock Contract (HTLC)"yi ele alalım, bu da yerel dile çevrilir:
Alternatif olarak, Bob bir hash H'nin arkasındaki ön görüntüyü ortaya çıkarabilir ve kendi imzasını verebilir, bu da paraya mal olur
Ya da Alice belli bir süre T kullandıktan sonra parayı kendi imzası ile harcayabilir.
Bu "ya da ... veya ..." Etki, süreç kontrolü işlem kodu aracılığıyla elde edilir.
HTLC'nin en belirgin avantajı, birden fazla işlemi bir araya getirebilmesi ve atomize edebilmesidir. Örneğin, Alice, Bob ile BTC'yi CKB ile değiştirmek isterse, Bob önce bir hash değeri verebilir ve Nervos Ağında bir HTLC oluşturabilir. Alice daha sonra Bitcoin'de aynı hash'i kullanan bir HTLC oluşturur. Alternatif olarak, Bob, Alice'in Bitcoin'de ödediği BTC'yi alırken, aynı zamanda ön görüntüyü ortaya çıkararak Alice'in Nervos Network'te CKB'yi çekmesine izin verir. Her iki durumda da, Bob orijinal görüntüyü açıklamaz, her iki sözleşme de sona erer ve hem Alice hem de Bob yatırdıkları parayı geri alabilirler.
Taproot soft fork'un etkinleştirilmesinden sonra, bu çoklu kilit açma yolu özelliği, MAST'ın (Merkle Soyut Sözdizimi Ağacı) kullanıma sunulmasıyla daha da geliştirilmiştir: Merkle ağacında bir kilit açma yolunu bir yaprağa dönüştürebiliriz, her yaprak bağımsızdır, bu nedenle artık böyle bir akış kontrolü işlem kodu kullanmaya gerek yoktur; Ayrıca, bir yol diğerlerini açığa çıkarmadan ortaya çıktığı için, ekonomi konusunda endişelenmek zorunda kalmadan bir çıktıya daha fazla sayıda kilit açma yolu ekleyebiliriz.
İkinci kavram "taahhüt ticareti" dir. Taahhüt edilen bir işlem fikri, bazı durumlarda, geçerli bir Bitcoin işleminin, blok zinciri tarafından onaylanmasa bile, aynı derecede gerçek ve bağlayıcı olmasıdır.
Örneğin, Alice ve Bob, her ikisinin de harcama yapmak için imza atmasını gerektiren bir UTXO'yu paylaşır. Bu noktada Alice, değerinin %60'ını Bob'a, geri kalanını kendisine aktararak harcamak için bir işlem oluşturur; Alice, işlem için kendi imzasını sağlar ve bu imza daha sonra Bob'a gönderilir. Bob'a göre, Bitcoin ağında yayınlanması gerekmiyor ve blok zinciri tarafından onaylanması gerekmiyor ve bu işlemin ödeme etkisi de gerçek ve güvenilir. Alice UTXO'yu kendi başına harcayamayacağından (ve dolayısıyla tekrar tekrar harcayamayacağından) ve Alice tarafından sağlanan imza geçerli olduğundan, Bob her zaman imzasını ekleyebilir ve ödemeyi yerine getirmek için işlemi yayınlayabilir. Başka bir deyişle, Alice, bu geçerli (zincir dışı) işlem aracılığıyla Bob'a "güvenilir bir taahhüt" sağladı.
Taahhüt edilen işlemler, Bitcoin uygulama programlamasının temel bir kavramıdır. Daha önce de belirtildiği gibi, Bitcoin'in sözleşmesi doğrulamaya dayalıdır, durumsuzdur ve çapraz erişime izin vermez; Bununla birlikte, sözleşme devletleri taşımıyorsa, bu devletler nerede saklanır ve sözleşme nasıl güvenli bir şekilde ilerleyebilir? Taahhüt işlemleri basit bir cevap verir: sözleşmenin durumu işlemler şeklinde ifade edilebilir, böylece sözleşmenin katılımcıları durumu blok zincirinde görüntülemek zorunda kalmadan kendileri kurtarabilir; Sözleşmenin durumunu değiştirme sorunu, taahhüt edilen işlemin güvenli bir şekilde nasıl güncelleneceği sorununa da dönüştürülebilir; Buna ek olarak, bir sözleşmeye girmenin tehlikelerinden endişe duyuyorsak (örneğin, her iki tarafın da harcama yapmak için imzalamasını gerektiren bir sözleşmeye girmek ve diğer tarafın yanıt vermeme ve takılma riski varsa), o zaman sadece sözleşmeye önceden mal olan bir taahhüt işlemi oluşturmak ve imza almak riski azaltabilir ve diğer katılımcılara olan güveni ortadan kaldırabilir.
(2) Yıldırım kanalı ve yıldırım ağı
Yıldırım kanalı, iki tarafın blok zinciri tarafından onaylanan herhangi bir ödeme olmadan birbirlerine sınırsız sayıda ödeme yapabileceği bire bir sözleşmedir. Tahmin edebileceğiniz gibi, taahhüt ticareti kullanır.
"Taahhütlü İşlemler" bölümünü açıklayan bölümde, zaten bir ödeme kanalı tanıttık. Ancak, yalnızca 2'nin 2'sinden yararlanan bu tür bir sözleşme, yalnızca tek yönlü ödemeleri mümkün kılabilir. Yani, ya Alice her zaman Bob'a ödeme yapar ya da Bob, sözleşmedeki bakiyesini kullanana kadar Alice'e her zaman ödeme yapar. Bu iki yönlü bir ödemeyse, bir durum güncellemesinden sonra bir tarafın öncekinden daha az bakiyesi olabileceği, ancak TA'nın diğer tarafça imzalanmış son taahhüt işlemine sahip olduğu anlamına gelir - TA'nın eski taahhüdü yayınlamasını ve TA'nın yalnızca en son taahhüt işleminden yayınlamasını durdurmak için ne yapılabilir?
Yıldırım kanalı ile ilgili bu sorunun çözümüne "LN-Cezası" denir. Şimdi, Alice ve Bob'un her birinin bir kanalda 5 BTC'si olduğunu varsayalım; Şimdi Alice, Bob'a 1 BTC ödemek istiyor, bu yüzden vaat edilen işlemi imzalıyor ve Bob'a gönderiyor:
#0 ve 10 BTC girin:
Alie-Bob 2'nin 2'si çoklu imza çıkışı (yani kanal sözleşmesi)
Çıktı #0 , 4 BTC:
Alice tek imzalı
Çıktı #1 , 6 BTC:
veya
Alice-Bob birleşik geçici açık anahtar #1 tek imza
veya
T 1 zaman kilidi, Bob tek imzalı
Bob ayrıca (yukarıdaki işleme karşılık gelen) bir taahhüt imzalar ve bunu Alice'e gönderir:
#0 ve 10 BTC girin:
Alie-Bob 2'nin 2'si çoklu imza çıkışı (yani kanal sözleşmesi)
Çıkışı #0 , 6 BTC:
Bob tek imzalı
Çıkışı #1 , 4 BTC:
veya
Bob-Alice birleşik geçici ortak anahtar #1 tek imza
veya
T 1 zaman kilidi, Alice tek imzalı
Buradaki püf noktası, kendi açık anahtarlarından biri ve diğer tarafça sağlanan bir açık anahtar kullanılarak oluşturulan bu "ortak geçici açık anahtar"da yatmaktadır, örneğin, Alice-Bob ortak geçici açık anahtarı, Alice tarafından kendi açık anahtarlarından biri ve Bob tarafından sağlanan bir açık anahtar kullanılarak elde edilen ve her birinin bir hash değeri ile çarpılması. Böyle bir genel anahtar oluşturulduğunda, hiç kimse özel anahtarını bilmez. Ancak, Bob Alice'e sağladığı ortak anahtarın özel anahtarını söylerse, Alice federasyon geçici ortak anahtarının özel anahtarını hesaplayabilir. - Bu, Yıldırım Kanalı'nın eski durumu "geri alabileceği" gerçeğinin anahtarıdır.
İki taraf bir dahaki sefere kanal durumunu güncellemek (bir ödeme başlatmak) istediğinde, iki taraf önceki turda birbirlerine verilen geçici açık anahtarın özel anahtarını değiştirir. Bu şekilde, katılımcılar artık aldıkları son vaat edilen işlemi yayınlamaya cesaret edemezler: kendi taraflarına değer atayan bu vaat edilen işlemin çıktısının iki yolu vardır ve geçici açık anahtar yolunun özel anahtarı karşı taraf tarafından zaten bilinmektedir; Bu nedenle, eski taahhüt işlemi yayınlandıktan sonra, diğer taraf bu çıktıdaki tüm fonları almak için bu ortak geçici özel anahtarı hemen kullanabilir. - "LN-Cezası"nın anlamı budur.
Spesifik olarak, etkileşim sırası şu şekildedir: ödemeyi başlatan taraf önce diğer taraftan yeni bir geçici açık anahtar talep eder ve ardından yeni bir taahhüt işlemi oluşturur ve diğer tarafa teslim eder; Vaat edilen işlemi alan taraf, bir önceki turda verdiği geçici açık anahtarın özel anahtarını karşı tarafa gösterdi. Bu etkileşim dizisi, katılımcıların önceki turda aldıkları taahhüt işlemini geçersiz kılmadan önce her zaman yeni bir taahhüt işlemi almalarını sağlar ve bu nedenle güvene dayalı değildir.
Özetle, yıldırım kanalının temel tasarımları şunlardır:
Her iki taraf da sözleşmedeki durumu ifade etmek için her zaman taahhüt işlemlerini kullanır ve ödemeyi ifade etmek için miktardaki değişiklik;
Taahhüt işlemleri her zaman aynı girdiye (her iki tarafın da aynı anda imza vermesini gerektiren girdi) mal olur, bu nedenle tüm taahhüt işlemleri birbiriyle rekabet eder ve blok zinciri tarafından yalnızca biri onaylanabilir.
İki katılımcı aynı taahhüt işlemini imzalamıyor (eşleştirilmiş olmalarına rağmen); Ve imzaladıkları şey her zaman kendileri için daha elverişli bir işlemdir, başka bir deyişle, katılımcıların aldıkları vaat edilen işlem her zaman kendileri için elverişsizdir;
Bunun dezavantajı, kendisine değer atayan çıktının iki kilit açma yoluna sahip olmasıdır: bir yolun kilidi kendi imzasıyla açılabilir, ancak bir süre beklemesi gerekir; Diğer yol, diğer tarafın ortak anahtarını kullanır ve bu anahtar, yalnızca geçici özel anahtarlarından biri açığa çıkmadığında korunur.
Her ödemede, her iki taraf da diğer tarafın önceki turda kullandığı geçici özel anahtarı yeni bir taahhüt işlemiyle değiştirir, böylece geçici özel anahtarı teslim eden taraf artık eski taahhüt işlemini yayınlamaya cesaret edemez, bu nedenle önceki taahhüt işlemini "iptal eder" ve sözleşmenin durumunu günceller; (Aslında vaat edilen bu işlemlerin hepsi geçerli işlemlerdir ve blok zincirine yayınlanabilir, ancak katılımcılar cezalandırılmaya zorlanır ve artık yayın yapmaya cesaret edemezler)
Taraflardan herhangi biri, diğer tarafça imzalanmış bir taahhütname ile istediği zaman sözleşmeden çekilebilir; Ancak, her iki taraf da işbirliği yapmaya istekliyse, her iki tarafın da paralarını hemen geri alabilmesi için yeni bir anlaşma imzalayabilirler.
Son olarak, HTLC taahhütlü bir işleme de yerleştirilebildiğinden, Lightning kanalı ödemeleri de iletebilir. Alice'in Daniel'e ulaşmak için önce ve sonra birbirine bağlanan yıldırım kanallarından oluşan bir yol bulabileceğini varsayarsak, Daniel ile bir kanal açmadan güvene dayalı olmayan çoklu atlamalı ödemeler elde edilebilir. Karşınızda Lightning Network var:
Alice -- HTLC --> Bob -- HTLC --> Carol -- HTLC --> Daniel
Alice < -- Öngörüntü -- Bob < -- Öngörüntü -- Carol < -- Öngörüntü -- Daniel
Alice böyle bir yol bulduğunda ve Daniel'e ödeme yapmak istediğinde, Daniel'den Bob için bir HTLC oluşturması için bir hash ister ve Bob'dan Carol'a bir mesaj iletmesini ve aynı HTLC'yi sağlamasını ister; Mesaj, Carol'dan mesajı Daniel'e iletmesini ve aynı HTLC'yi sağlamasını ister. Haber Daniel'e ulaştığında, Carol'a ön görüntüyü açıklar, bu da ona HTLC'nin değerini verir ve sözleşmenin durumunu günceller. Carol da aynısını yaptı, Bob'dan ödeme aldı ve kanal durumunu güncelledi; Son olarak, Bob ön görüntüyü Alice'e gösterir ve durumu günceller. HTLC'nin doğası gereği, bu ödeme zinciri ya birlikte başarılı ya da başarısız olur ve bu nedenle güvenilmezdir.
Lightning Network, her biri birbirinden bağımsız olan birbiri ardına gelen kanallardan oluşur. Bu, Alice'in diğer kişilerin kanallarında kaç etkileşim gerçekleştiğine, bu etkileşimlerin hangi para birimini kullandığına ve hatta kanalı gerçekten kullanıp kullanmadıklarına bakılmaksızın yalnızca Bob ile kanalında neler olup bittiğini bilmesi gerektiği anlamına gelir.
Lightning Network'ün ölçeklenebilirliği, yalnızca bir Lightning Kanalı içindeki ödeme hızının yalnızca her iki tarafın da donanım kaynaklarına yaptığı yatırımla sınırlı olduğu gerçeğine değil, aynı zamanda merkezi olmayan devlet depolaması nedeniyle tek bir düğümün en düşük maliyetle maksimum kaldıraçtan yararlanabilmesine de yansır.
(3) Yevmiye sözleşmelerine karşı dikkatli olun
Uyarıcı Günlük Sözleşmesi (DLC), Bitcoin Script'in dış olaylara bağlı finansal sözleşmeleri programlamasına izin veren "adaptör imzası" adı verilen bir şifreleme tekniği kullanır.
Bağdaştırıcı imzaları, bir imzanın yalnızca özel anahtar eklendikten sonra geçerli bir imza haline gelmesine izin verir. Schnorr imzasının standart biçiminin (R, s) olduğu bir Schnorr imzası örneğini ele alalım, burada:
R = r.G
İmza için kullanılan nonce değeri r, r'nin açık anahtarı olduğu da söylenebilecek eliptik eğri oluşturma noktası ile çarpılır.
s = r + Hash(R || m || P) * p
p imzalama özel anahtarıdır ve P ortak anahtardır
验证签名即验证 s.G = r.G + Hash(R || m || P) * p.G = R + Hash(R || m || P) * PK
Diyelim ki bir çift veri (R, s') veriyorum:
R = R 1 + R 2 = r 1.G + r 2.G
s' = r 1 + Hash(R || m || P) * p
Açıkçası, bu geçerli bir Schnorr imzası değildir ve doğrulama formülünü geçmez, ancak doğrulayıcıya sadece R 2, r 2'nin özel anahtarını bilerek geçerli bir imza olabileceğini kanıtlayabilirim:
s'. G + R 2 = R 1 + Hash(R || m || P) * P + R 2 = R + Karma(R || m || P) * P
Bağdaştırıcı imzaları, bir imzanın geçerliliğini gizli bir veriye bağımlı hale getirir ve doğrulanabilir. Peki bunun finansal sözleşmelerle ne ilgisi var?
Diyelim ki Alice ve Bob bir top oyununun sonucuna bahse girmek istiyorlar. Alice ve Bob, 1 BTC'lik bir bahisle sırasıyla Green Goblin ve Alina'nın kazanacağına bahse girer. Buna ek olarak, bir futbol inceleme sitesi olan Carol, maçın sonuçları açıklandığında sonuçların imzalı bir _c_i göndermek için bir nonce R_c kullanma sözü verdi.
Görülebileceği gibi, üç olası sonuç vardır (yani Carol'ın imzası için 3 olasılık vardır):
Green Goblin kazandı, Alice 1 BTC kazandı
Alina kazanır ve Bob 1 BTC kazanır
Beraberlik, ikisinin fonları aynı şekilde geri döner
Bunu yapmak için, ikisi her sonuç için bir taahhüt anlaşması oluşturur. Örneğin, ilk sonuç için oluşturdukları taahhüt işlemi şöyle görünür:
Ancak, (R, s) yerine, Alice ve Bob'un bu işlem için oluşturduğu imza bir bağdaştırıcı imzasıdır (R, s'); Başka bir deyişle, her iki tarafın birbirine verdiği imzalar, sözleşmenin kilidini açmak için doğrudan kullanılamaz, ancak gizli bir değeri ortaya çıkarmalıdır. Bu gizli değer, Carol'ın imzası olan s_c_ 1.G'nin ön görüntüsüdür! Carol'ın imzası olan nonce değeri belirlendiğinden (R_c), s_c_ 1.G oluşturulabilir (s_c_ 1.G = R_c + Hash(R_c ||). 'Green Goblin kazandı' || PK_c) * PK_c)。
Sonuçlar açıklandığında, Green Goblin'in kazandığını varsayarsak, Carol bir imza (R_c, s_c_ 1) yayınlayacak, böylece Alice veya Bob rakibin adaptör imzasını tamamlayabilir ve yukarıdaki işlemi geçerli bir işlem yapmak için kendi imzalarını ekleyebilir ve uzlaşma etkisini tetiklemek için ağa yayınlayabilir. Ancak Green Goblin kazanamazsa, Carol s_c_ 1'i göndermeyecek ve taahhüt anlaşması geçerli bir anlaşma olmayacak.
Ve benzeri, diğer iki esnaf gibi. Bu şekilde, Alice ve Bob, karşı tarafa güvenmek zorunda kalmadan sözleşmenin yürütülmesini dış olaylara (daha doğrusu, iddia makinesinin dış olayları imza şeklinde yayınlamasına) bağımlı hale getirir. Vadeli işlemler ve opsiyonlar gibi büyük ve küçük finansal sözleşmeler bu şekilde uygulanabilir.
Diğer uygulama biçimleriyle karşılaştırıldığında, ihtiyatlı günlük sözleşmesinin en önemli özelliği gizliliğidir: (1) Alice ve Bob'un Carol'a Carol'ın verilerini kullandıklarını söylemelerine gerek yoktur, bu da sözleşmenin yürütülmesini hiçbir şekilde etkilemez; (2) Zincir üstü gözlemciler (Carol dahil), Alice ve Bob'un sözleşme yürütmesi yoluyla hangi web sitesini kullandıklarını, hatta sözleşmelerinin bir bahis sözleşmesi (yıldırım kanalı değil) olduğunu belirleyemezler.
IV. Kısıtlamaların Uygulanmasına Giriş
(a) OP_CTV ve tıkanıklık kontrolü
Bitcoin topluluğunun geliştiricileri, kısıtlayıcı maddeler olarak sınıflandırılabilecek bir dizi teklifte bulundular. Şu anda, en iyi bilinen tekliflerden biri, basitliği ancak basit konseptiyle esnekliği nedeniyle Bitcoin topluluğu arasında popüler olan OP_CHECKTEMPLATEVERIFY (OP_CTV)'dir. OP_CTV fikri, fonların yalnızca bu hash tarafından temsil edilen işlemler tarafından harcanabileceğini kısıtlamak için komut dosyasında bir hash işlemektir; Bu hash, işlemin çıktısını ve alanların çoğunu vaat eder, ancak işlemin girdisini değil, yalnızca girdi sayısını vaat eder.
"Tıkanıklık Kontrolü", OP_CTV'nin nasıl gösterilebileceğine iyi bir örnektir. Temel kullanım durumu, çok sayıda kullanıcının bir borsadan (güven gerektiren bir ortam) bir havuza çıkmasına yardımcı olmaktır; Bu havuz, gelecekte nasıl harcanacağını planlamak için OP_CTV kullandığından, kullanıcıların havuzdan kimsenin yardımı olmadan güvenilir bir şekilde çıkabilmelerini garanti eder; Ve bu havuz yalnızca bir UTXO gibi davrandığından, zincir içi işlemlere olan talep yüksek olduğunda (n çıktıdan 1 çıktıya; ayrıca n işlemden 1 işleme düşürüldü). Havuzdaki kullanıcılar havuzdan çıkmak için fırsat bekleyebilir.
Diyelim ki Alice, Bob ve Carol borsadan sırasıyla 5 BTC, 3 BTC ve 2 BTC çekmek istiyor. Daha sonra borsa 3 OP_CTV şubesi ile 10 BTC'lik bir çıktı yapabilir. Diyelim ki Alice para çekmek istiyor, şube 1'i kullanabilir; Şubenin OP_CTV'si tarafından kullanılan hash değeri ile 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 çekmesine ve kalan 2 BTC'yi Carol'a göndermesine izin veren bir havuzdur.
Bob veya Carol para çekmek istediğinde de aynı şey olur. Para çekerken, yalnızca ilgili OP_CTV çekini geçebilecek işlemleri kullanabilecekler, yani yalnızca ilgili tutarı kendilerine ödeyebilecekler ve keyfi olarak para çekemeyecekler; Kalan fonlar OP_CTV kilitli bir havuza gidecek ve böylece kalan kullanıcıların çekilme sırasına bakılmaksızın havuzdan güvenilir bir şekilde çıkarılabilmelerini garanti edecektir.
Özet olarak, OP_CTV'ın buradaki rolü, sözleşme için sözleşmenin ömrünün sonuna kadar olan yolu planlamaktır, böylece buradaki havuz sözleşmesi, hangi yolu izlerse seçsin veya hangi duruma giderse gitsin güvene dayalı olmayan çıkış niteliğini koruyabilir.
Bu OP_CTV'nin çok ilginç bir kullanımı da var: "gizli ama açığa çıkmayan tek yönlü ödeme kanalı". Alice'in böyle bir fon havuzu oluşturduğunu ve fonların aşağıdaki komut dosyasıyla güvenilir bir şekilde bir çıktıya çekilebileceğini garanti ettiğini varsayalım:
ya da Alice ve Bob birlikte geçirirler
ya da bir süre sonra Alice kendi başına harcayabilir
Alice bunu Bob'a açıklamasaydı, Bob böyle bir çıktının var olduğunu bilemezdi; Alice bunu Bob'a açıkladığında, Bob çıktıyı zamana duyarlı, tek yönlü bir ödeme kanalı olarak kullanabilir ve Alice, blok zincirinden onay beklemek zorunda kalmadan Bob'a hemen ödeme yapmak için kullanabilir. Bob, Alice'ten taahhüt işlemini kendi başına harcamadan önce zincire koymasını ister.
(b) OP_Vault ve güvenli
OP_VAULT, "kasalar" inşa etmek için özel olarak tasarlanmış kısıtlayıcı bir madde önerisidir.
Vault sözleşmesi, daha güvenli ve gelişmiş bir kendi kendine saklama biçimi olacak şekilde tasarlanmıştır. Mevcut çoklu imza sözleşmesi, tek bir özel anahtar için tek bir hata noktasından kaçınabilse de, bir saldırgan eşik sayıda özel anahtar elde ederse, cüzdanın sahibi çaresizdir. Apps Kasası, fonlarınıza tek bir harcama limiti uygulamak istiyor; Aynı zamanda, normal rotayı kullanarak ondan para çekerken, para çekme işlemi bir bekleme süresi uygulayacaktır; Ve bekleme süresi boyunca, para çekme işlemi, cüzdanın acil kurtarma işlemi ile kesintiye uğrayabilir. Böyle bir sözleşme ihlal edilse bile, cüzdanın sahibi bir karşı işlem başlatabilir (acil durum kurtarma şubesini kullanarak).
Teorik olarak, OP _CTV böyle bir sözleşmeyi de programlayabilir, ancak birçok rahatsızlık vardır, bunlardan biri komisyondur: işlemi taahhüt ederken, işlemin ödeyeceği ücreti de vaat eder. Bu sözleşmenin amacı göz önüne alındığında, sözleşmenin kurulması ile para çekilmesi arasındaki zaman aralığı çok uzun olmalıdır, bu nedenle uygun komisyonu tahmin etmek neredeyse imkansızdır. OP_CTV girdileri sınırlamasa da, girdi artırılarak ücret artırılabilir, sağlanan girdilerin tümü komisyon haline gelecektir, bu nedenle gerçekçi değildir; Diğer bir yol ise, çekilen fonları harcayarak yeni işlemlerde komisyon sağlamak olan CPFP'dir. Ek olarak, OP_CTV kullanımı, böyle bir Vault sözleşmesinin toplu olarak geri çekilemeyeceği (ve kesinlikle toplu olarak geri yüklenemeyeceği) anlamına gelir.
OP_VAULT önerisi, yeni işlem kodları (OP_VAULT ve OP_UNVAULT) önererek bu sorunları ele almaya çalışır. OP_UNVAULT toplu iş dayanıklılığı için tasarlanmıştır, bu nedenle şimdilik bundan bahsetmeyeceğiz. OP_VAULT şu şekilde davranır: komut dosyası ağacının bir dalına koyduğumuzda, belirli parametreler olmadan kullanılabilir bir işlem koduna (örneğin OP_CTV) işlemek için kullanılabilir; Bu şubeyi harcarken, işlemler belirli parametrelerde geçirilebilir, ancak diğer şubelerde geçirilemez. Sonuç olarak, önceden belirlenmiş bir ücret belirlemesi gerekmez ve şube harcandığında ayarlanabilir; Dalın da bir zaman kilidi olduğunu varsayarsak, bir zaman kilidi uygulayacaktır; Son olarak, yalnızca bulunduğunuz dalı değiştirebileceğiniz ve yeni komut dosyası ağacının başka hiçbir dalı (acil durum kurtarma dalı dahil) değiştirilmeyeceğinden, bu tür para çekme işlemlerini kesintiye uğratmamıza izin verilir.
Ek olarak, iki noktadan bahsetmeye değer: (1) OP_VAULT işlem kodu başka bir kısıtlama önerisine benzer şekilde davranır: OP_TLUV; Jeremy Rubin haklı olarak bunun bir dereceye kadar "hesaplama" kavramına yol açtığına dikkat çekiyor: OP_TLUV/OP_VAULT ilk olarak, tüketicinin parametreleri işlem koduna yeni bir işlemle ileterek tüm komut dosyası ağacı yaprağını güncellemesine izin verecek bir işlem kodu vaat ediyor; Artık "gelen verileri belirli kriterlere göre doğrulamak" ile ilgili değil, etkinleştirebileceği hesaplama sınırlı olsa da "gelen verilere dayalı yeni anlamlı veriler üretmek" ile ilgili.
(2) Tam OP_VAULT teklifi, daha iyi sonuçlar elde etmek için mempool politikasındaki bazı tekliflerden (örneğin, v3 işlemleri) de yararlanır. Bu bize "programlamanın" anlamının düşündüğümüzden daha geniş olabileceğini hatırlatır. (Benzer bir örnek, Nervos Ağındaki Açık İşlem'dir.) ）
V. CKB'yi Anlamak
Yukarıdaki iki bölümde, ilginç uygulamaları daha kısıtlı bir yapıda (Bitcoin UTXO) nasıl yazabileceğimizi açıklıyoruz; Böyle bir yapıya iç gözlem eklemeye çalışmak için öneriler de sunuldu.
UTXO'lar bu uygulamaları programlama yeteneğine sahip olsa da, okuyucuların eksikliklerini veya optimize edilebilecek alanlarını tespit etmeleri kolaydır, örneğin:
LN-Ceza'da, kanal katılımcıları, rakibin bir depolama yükü oluşturan sahtekarlığıyla başa çıkmak için geçmişte yapılan her işlemi ve ilgili ceza gizli değerini kaydetmelidir. Yalnızca en son taahhüt işleminin yürürlüğe girmesini ve eski taahhüt işleminin yürürlüğe girmemesini sağlayan bir mekanizma varsa, bu yükü ortadan kaldırabilir ve ayrıca düğümlerin yanlışlıkla eski bir taahhüt işlemini zincire koyduğu için yanlışlıkla cezalandırılması sorununu da ortadan kaldırabilir.
DLC'de, etkinliğin birçok olası sonucu olduğu varsayılıyor ve her iki tarafın da önceden oluşturması ve birbirine teslim etmesi gereken birçok imza var, bu da büyük bir yük; Ek olarak, DLC sözleşmesinin geliri doğrudan açık anahtara bağlıdır, bu nedenle pozisyonunun aktarılması kolay değildir, sözleşmenin pozisyonunu aktarmanın bir yolu var mı?
Aslında, Bitcoin topluluğu, temelde bir Sighash önerisiyle (BIP-118 AnyPrevOut) ilgili bu soruların yanıtlarını buldu.
Bununla birlikte, CKB'de programlama yapıyor olsaydık, BIP-118 şu anda mevcut olurdu (bu tür Sighash etiketleri, imzaları içe dönük ve amaçlı olarak doğrulama yeteneği ile simüle edilebilir).
Bitcoin'i programlamayı öğrenerek, sadece "İşlem Çıktısı" (CKB'de ne programlanabilir) formatında programlanabileceklerini değil, aynı zamanda bu uygulamaları nasıl geliştireceğimizi de biliyoruz (ve CKB'de programlarsak bunları geliştirmek için CKB'nin yeteneklerini nasıl kullanabileceğimizi). CKB geliştiricileri için, Bitcoin Script tabanlı programlama bir öğrenme materyali, hatta bir kısayol olarak kullanılabilir.
Aşağıda, CKB programlamanın her bir modülünün programlanabilirliğini tek tek analiz edelim. Şimdilik iç gözlemi düşünmeyelim.
(1) Programlanabilir keyfi hesaplanan kilit
Yukarıda belirtildiği gibi, UTXO'lar keyfi olarak hesaplanacak şekilde programlanamaz. Öte yandan Lock, Lock'un yukarıda bahsedilen Lightning Channel ve DLC dahil ancak bunlarla sınırlı olmamak üzere UTXO'ya dayalı olarak her şeyi (kısıtlama dağıtımından önce) programlayabileceği anlamına gelir.
Ek olarak, rastgele hesaplamayı doğrulama yeteneği, Lock'u kimlik doğrulama yöntemleri açısından UTXO'dan daha esnek hale getirir. Örneğin, bir tarafın ECDSA'yı imzaladığı ve diğer tarafın RSA kullandığı CKB'ye bir yıldırım kanalı uygulayabiliriz.
Aslında bu, insanların CKB'de keşfetmeye başladığı ilk alanlardan biridir: "hesap soyutlama" olarak bilinen şeyi etkinleştirmek için kullanıcının kendi gözetiminde bu esnek kimlik doğrulama yeteneğini kullanmak - işlem geçerliliğinin yetkilendirilmesi ve kontrolün yeniden sağlanması çok esnek ve neredeyse sınırsızdır. Prensip olarak, bu "çoklu harcama dalları" ve "keyfi kimlik doğrulama yöntemlerinin" bir kombinasyonudur. Uygulama örnekleri şunlardır: joyid cüzdanı, UniPass.
Buna ek olarak, Lock, yalnızca en son taahhüt edilen işlemi tutması gereken bir yıldırım kanalını etkinleştirerek eltoo tekliflerini uygulayabilir (aslında, eltoo tüm eşler arası sözleşmeleri basitleştirebilir).
(2) Programlanabilir keyfi hesaplanan Tip
Yukarıda bahsedildiği gibi, Type'ın en büyük kullanımlarından biri UDT'leri programlamaktır. Lock ile birlikte bu, UDT tabanlı yıldırım kanallarını (ve diğer sözleşme türlerini) uygulayabileceğimiz anlamına gelir.
Aslında, Lock ve Type arasındaki ayrım bir güvenlik yükseltmesi olarak görülebilir: Lock, saklama yöntemlerinin veya sözleşmeye dayalı anlaşmaların uygulanmasına odaklanırken, Type, UDT'leri tanımlamaya odaklanır.
Ek olarak, UDT tanımlarına dayalı kontrollerin başlatılabilmesi, UDT'nin sözleşmelere CKB'ye benzer şekilde katılmasını da sağlar (UDT birinci sınıf vatandaştır).
Örneğin, yazar bir keresinde Bitcoin'de güvene dayalı olmayan NFT destekli borç vermeyi uygulamak için bir protokol önerdi. Böyle bir protokolün anahtarı, girdinin değerinin çıktının değerinden daha düşük olduğu (dolayısıyla henüz geçerli bir işlem olmadığı) taahhüt edilmiş bir işlemdir, ancak işlem için yeterli girdi sağlanabildiğinde, bu geçerli bir işlemdir: borç veren geri ödeyebildiğinde, borç veren stake edilen NFT'yi kendisi için alamaz. Bununla birlikte, bu taahhüt işleminin güvenilmezliği, girdi ve çıktı miktarını kontrol eden işleme dayanır, bu nedenle borç veren, krediyi geri ödemek için yalnızca Bitcoin'i kullanabilir - hem borç veren hem de borç veren başka bir para birimini kabul etmeye istekli olsa bile (RGB protokolü altında verilen USDT gibi), Bitcoin taahhüt işlemi, borç veren USDT'nin tamamını iade ettiği sürece borç verenin NFT'sini geri alacağını garanti etmez, çünkü Bitcoin işleminin USDT'nin durumu hakkında hiçbir fikri yoktur! (Revizyon: Başka bir deyişle, USDT geri ödemesine bağlı olarak taahhüt edilen bir işlem oluşturmak mümkün değildir.) ）
UDT'nin tanımına dayalı bir kontrol başlatabilirsek, borç verenin krediyi geri ödemek için USDT kullanmasına izin verecek başka bir taahhütlü işlem imzalamasını sağlayabiliriz. İşlem, girilen USDT miktarını ve çıkan USDT miktarını kontrol ederek kullanıcılara USDT ile güvene dayalı olmayan geri ödeme sağlar.
Değişiklik: Teminat olarak kullanılan NFT ile geri ödeme için kullanılan tokenin aynı protokol (RGB gibi) kullanılarak verildiğini varsayarsak, buradaki sorun çözülebilir ve RGB protokolüne göre bir taahhüt işlemi oluşturabiliriz, böylece NFT'nin durum geçişi ve geri ödemesi aynı anda gerçekleşebilir (RGB protokolü içindeki işlemlere iki durum geçişi bağlanır). Bununla birlikte, RGB işlemleri de Bitcoin işlemlerine dayandığından, burada taahhüt işlemlerinin inşası biraz zor olacaktır. Sonuç olarak, sorun çözülebilse de, Token birinci sınıf vatandaştır.
Sonra, iç gözlemi ele alalım.
(3) Kilit diğer kilitleri okur
Bu, önerilen kısıtlama uygulandıktan sonra Bitcoin UTXO'larında tüm programlama olanakları anlamına gelir. Bu, yukarıda bahsedilen Apps Kasası sözleşmelerinin yanı sıra OP_CTV tabanlı uygulamaları (ör. tıkanıklık kontrolü) içerir.
XueJie bir keresinde çok ilginç bir örnekten bahsetmişti: CKB'de bir tahsilat hesabı hücresi uygulayabilirsiniz, bu tür bir hücreyi işlemin girdisi olarak kullanırken, çıktı hücresi (aynı kilidi kullanan hücre) daha fazla kapasiteye sahipse, girdinin bir imza sağlaması gerekmez ve işlemin geçerliliğini etkilemez. Aslında, bu tür bir hücre, iç gözlem yeteneği olmadan mümkün olmazdı. Bu tahsilat hesap hücresi, fonları bir araya getirdiği ve iyi bir mahremiyet duygusuna sahip olmama dezavantajına sahip olduğu için kurumsal bir para alma yöntemi olarak idealdir.
(4) Kilit diğer türleri (ve verileri) okur
Bu yeteneğin ilginç bir uygulaması da stake token'lardır. Lock, diğer girdilerdeki jeton sayısına ve nerede harcanabileceğine bağlı olarak kendi kapasitesini kullanıp kullanamayacağına karar verecektir (iç gözlem kilidi yeteneği gerektirir).
(5) Tip diğer kilitleri okur
Emin değilim, ancak yararlı olduğu varsayılabilir. Örneğin, bir işlemin giriş ve çıkışlarının Kilitlerinin değişmeden kaldığını Tür'de kontrol edebilirsiniz.
(6) Type Scirpt diğer türleri (ve verileri) okur
Koleksiyon kartları? Daha büyük bir jeton karşılığında n jeton toplayın :)
VI. Sonuç
Ethereum gibi keyfi hesaplama ile programlanabilen önceki akıllı sözleşme sistemleriyle karşılaştırıldığında, Nervos Network farklı bir yapıya sahiptir; Sonuç olarak, geçmişin akıllı sözleşme sistemlerinin bilgisine dayanarak Nervos Network'ü anlamak genellikle zordur. Bu makale, CKB Hücresi, BTC UTXO'dan daha kısıtlı bir yapının uygulama programlamasından başlayarak CKB Hücresinin programlanabilirliğini anlamak için bir yöntem önermektedir. Ve hücrelerin "sözleşmeler arası erişim" yeteneklerini anlamak için "iç gözlem" kavramını kullanarak, iç gözlem yeteneklerinin kullanıldığı durumları bölebilir ve özel kullanımlarını belirleyebiliriz.
Düzeltme:
Hücrenin çapraz erişim yeteneklerinden (yani iç gözlem yeteneklerinden) bağımsız olarak, kilitler uç noktalara ulaşmış durum ve programlama yeteneklerine sahip Bitcoin olarak kabul edilebilir, böylece tüm Bitcoin tabanlı uygulamalar yalnızca bu temelde programlanabilir;
Hücrenin çapraz erişim kabiliyeti (yani iç gözlem kabiliyeti) ne olursa olsun, kilitler ve tipler arasındaki ayrım bir güvenlik yükseltmesi olarak kabul edilebilir: UDT'nin varlık tanımını ve saklama yöntemini ayırır; Ek olarak, maruz kalabilir durumun s tipi (ve verileri) UDT'nin etkisini elde etmek birinci sınıf vatandaştır.
Yukarıdaki iki nokta, "BTC + RGB" ile aynı paradigmaya sahip, ancak daha fazla programlama yeteneğine sahip bir şey ifade ediyor;
Cell'in iç gözlem yeteneği göz önüne alındığında, Cell, antlaşma sonrası BTC UTXO'dan daha güçlü programlama yetenekleri elde edebilir ve BTC + RGB ile elde edilmesi zor olan bir şeyi uygulayabilir (çünkü BTC, RGB'nin durumunu okuyamaz)
Bu kullanımların çok fazla spesifik örneği yoktur, ancak bu, yazarın CKB ekolojisini anlamamasından kaynaklanmaktadır. Zamanla, daha fazla hayal gücüne yatırım yapılacağına ve bugün hayal bile edilemeyen uygulamaların bir araya getirileceğine inanılıyor.
Teşekkür
Makalenin yazımı sırasındaki geri bildirimleri için Retric, Jan Xie ve Xue Jie'ye teşekkürler. Tabii ki, metindeki tüm hatalardan ben sorumluyum.
Referanslar
Hesaplar, Katı Erişim Listeleri ve UTXO'lar
Bitcoin'deki Kısıtlamalar: İnceleme için Taksonomi
Sözleşmeyi oluşturan bileşenler Bitcoin ile yükseltilir
Eltoo açıkladı
Taahhüt Edilen İşlemlere Dayalı NFT Teminatlı Borç Verme Sözleşmesi · btc-çalışması/OP_QUESTION · Tartışma #7
Orijinal makaleye bağlantı
View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Bitcoin uygulama programlamasından CKB'nin programlanabilirliğini anlayın
Orijinal yazar: Ajian
Özet
Bir sistemin programlanabilirliğini anlamak, sistemin yapısal özelliklerini tanımlamamızı gerektirir. Bitcoin Script tabanlı uygulama programlamanın araştırılması, CKB Cell'in temel yapısını ve programlama paradigmasını anlamamıza yardımcı olur. Sadece bu da değil, aynı zamanda CKB'nin programlama bileşenlerini doğru parçalara ayırır ve her bir parçanın getirdiği programlanabilirlik kazanımlarını anlamamıza yardımcı olur.
I. Giriş
"Programlanabilirlik", insanların blok zinciri sistemlerini karşılaştırırken sıklıkla kullandıkları bir boyuttur. Bununla birlikte, programlanabilirliğin nasıl tanımlandığı konusunda genellikle anlaşmazlık vardır. Yaygın bir ifade, "XX blok zinciri, Turing-tam programlama dillerini destekler" veya "XX blok zinciri, genel amaçlı programlamayı destekler" şeklindedir ve bu, buradaki "XX blok zincirinin" güçlü programlanabilirliğe sahip olduğunu belirtmeyi amaçlamaktadır. Bu ifadelerin anlamlarında bazı gerçekler var: Turing-tam programlamayı destekleyen sistemlerin programlanması genellikle desteklemeyenlere göre daha kolaydır. Bununla birlikte, bir akıllı sözleşme sisteminin yapısal özelliklerinin birçok yönü vardır ve bu ifade bunlardan yalnızca birine değinir, bu nedenle geliştiricilerin onun tarafından yönlendirilmediği ve sıradan kullanıcılara güvenilemeyeceği gerçeğiyle yeterince derinlemesine anlaşılmak yeterli değildir.
Bir akıllı sözleşme sisteminin yapısal özellikleri şunları içerir:
Bu nedenle, "programlanabilir keyfi hesaplamaya" ek olarak, bir akıllı sözleşme sisteminin programlanabilirliğini etkileyen en az dört özellik vardır. Hatta bu diğer özelliklerin daha önemli olduğu söylenebilir, çünkü neyin elde edilmesinin kolay ve neyin zor olduğunu daha derin bir düzeyde belirlerler; Daha ekonomik bir uygulama nedir ve daha az verimli bir uygulama nedir?
Örneğin, Ethereum genellikle iyi programlanabilirliğin bir örneği olarak gösterilir, ancak Ethereum'daki temel durum ifadesi biçimi, eşler arası sözleşmelerin (örneğin, ödeme ağ geçitleri, bire bir bahis sözleşmeleri) programlanmasını zorlaştıran bir hesaptır - kesinlikle imkansız değil, sadece nankör. Ethereum ekosisteminin bir ödeme kanalı/durum kanalı uygulamaya çalışması alışılmadık bir durum değil ve pek çok teorik tartışma yapıldı, ancak bu projeler artık aktif görünmüyor - ve bu açıkça geliştiricilerin çaba eksikliğinden sorumlu tutulamaz. Bugün Ethereum'da aktif olan projelerin "eşler arası sözleşmeler" yerine "havuzlar" şeklini alması tesadüf değildir. Benzer şekilde, insanlar Ethereum'un programlanabilirliğinden memnun olabilir, ancak hesap modeli, doğası gereği "hesap soyutlaması" (cüzdan kavramının bir genellemesi olarak da anlaşılabilir) elde etmede eksiktir.
Aynı şekilde, CKB'nin programlanabilirliğini araştırmak, CKB akıllı sözleşme sisteminin yapısal özelliklerini de bu yönlerden anlamamızı gerektirir. Zaten bildiğimiz şey, CKB'nin keyfi hesaplamaların programlanmasına izin verdiği, bir sözleşme içinde ek durumun kaydedilmesine izin verdiği ve bir sözleşmenin yürütüldüğünde başka bir sözleşmenin durumuna erişmesine izin verdiğidir. Bununla birlikte, sözleşmenin şekli, onu Ethereum'dan temelde farklı kılan bir işlemin ("hücre" olarak adlandırılır) çıktısıdır. Bu nedenle, Ethereum akıllı sözleşme sistemini ve içindeki sözleşme örneklerini anlamak, CKB'nin bu yapısal özellikleri nasıl uyguladığını anlamamıza veya CKB'nin programlanabilirliğini anlamamıza yardımcı olmaz.
Neyse ki, Bitcoin'deki akıllı sözleşmeler, CKB'nin programlanabilirliğini anlamak için en iyi temeli sağlıyor gibi görünüyor. Bunun nedeni, yalnızca Bitcoin'in durum temsilinin temel biçiminin aynı zamanda işlemlerin çıktısı ("UTXO'lar" olarak adlandırılır) olması değil, aynı zamanda Bitcoin topluluğu tarafından önerilen "sözleşmeler" adı verilen bir kavramın yardımıyla, CKB'nin neden bu yapısal özelliklere sahip olduğunu anlayabilmemiz ve her birinin getirdiği programlanabilirlik kazanımlarını tanımlayarak nihai etkiyi uygun şekilde birkaç parçaya ayırabilmemizdir.
II. CKB V.S. BTC: Daha Ne Var?
(1) Temel yapı
Bitcoin'in durum temsilinin temel biçimi olarak, Bitcoin'in UTXO'su ("Harcanmamış İşlem Çıktısı") iki alana sahiptir:
Daha sonra gelen akıllı sözleşme sistemleriyle karşılaştırıldığında, Bitcoin Script oldukça sınırlıdır:
Bu tür komut dosyası oluşturma, sınırlı olsa da, harika uygulamaları programlama yeteneğinden yoksun değildir ve bu, CKB programlanabilirliğini keşfetmemizin temelidir. Daha sonra Bitcoin Script programlamanın iki örneğini tanıtacak bir bölüm olacak.
Buna karşılık, CKB'nin durum birimi "hücre" olarak adlandırılır ve dört alana sahiptir:
Ek olarak, Kilit ve Tip, keyfi hesaplamalar için programlanabilir. Herhangi bir imza doğrulama algoritmasını programlayabilir, görüntü öncesi kontrol için herhangi bir karma algoritmayı programlayabilirsiniz vb.
Okuyucuların, programlanabilirlik Cell'in UTXO'lara göre nasıl geliştiğini görmesi kolaydır:
Hücrenin kendisinin "işlem çıktısı" yapısı ile birleştiğinde, bu iki noktanın kendi içlerindeki faydaları çok, çok önemlidir, ancak yalnızca yukarıdaki açıklamadan, hücrenin "bir sözleşmenin çalışma zamanında başka bir sözleşmenin durumuna eriştiğini" nasıl başardığını bilmiyoruz. Bunu yapmak için, Bitcoin topluluğunda uzun süredir tartışılan bir kavramdan yararlanmamız gerekiyor: "sözleşmeler".
(2) Sınırlamalar ve iç gözlem
Bir kısıtlama maddesinin asıl amacı, bir miktar paranın nereye harcanabileceğini sınırlamaktır. Mevcut Bitcoin'de (herhangi bir kısıtlama önerilmemiştir), kilidi açıldıktan sonra tek bir miktar para herhangi bir yerde harcanabilir (rastgele bir komut dosyası açık anahtarına ödenebilir). Ancak kısıtlama maddesinin fikri, onu belirli yerlerle sınırlayacak şekilde harcanabilmesidir, örneğin, belirli bir UTXO yalnızca belirli bir işlem tarafından harcanacaktır, böylece birisi UTXO için bir imza sağlasa bile, nerede harcanabileceği o işlem tarafından zaten belirlenmiştir. Bu biraz garip görünebilir, ancak daha sonra bir bölümde ele alınacak olan bazı ilginç uygulamalara yol açabilir. Daha da önemlisi, CKB programlanabilirliğini daha iyi anlamamızın anahtarıdır.
Rusty Russell haklı olarak, bir kısıtlamanın ticaret yapmak için bir "iç gözlem" yeteneği olarak anlaşılabileceğine işaret eder, yani bir UTXO A bir B işlemi tarafından harcandığında, bir komut dosyası operatörü B işleminin bir kısmını (veya tamamını) okuyabilir ve ardından komut dosyası tarafından önceden talep edilen parametrelerle eşleşip eşleşmediğini kontrol edebilir. Örneğin, A işleminin ilk çıktısı için komut dosyası ortak anahtarının UTXO A'nın komut dosyası genel anahtarı için gerekli olanla eşleşip eşleşmediği (kısıtlamanın başlangıçta anlamı budur).
Zeki okuyucu, tam bir iç gözlemle, bir işlemin girdisinin aynı işlemin başka bir girdisinin durumunu okuyabildiğini fark edecektir, bu da bir sözleşmenin çalışma zamanında başka bir sözleşmenin durumuna erişme yeteneğini sağlar. Aslında, CKB Cell tam olarak bu şekilde tasarlandı.
Buna dayanarak, bu tam iç gözlem kapasitesini dört senaryoya bölebiliriz:
Bu, belirli varsayımlar altında (işlevlerin Kilit ve Tip arasındaki bölünmesi), yani her bir parçanın bize getirdiği programlanabilirlik kazancı altında farklı kullanım durumlarında her bir parçanın iç gözlem yeteneklerinin rolünü analiz etmemizi sağlar.
Aşağıdaki iki bölümde, CKB Cell'in nasıl programlanabileceği ve daha iyi yapılabileceği konusunda somut bir anlayış sağlamak için Bitcoin Script'in mevcut (ve henüz önerilmemiş) programlamasına ve önerilen kısıtlamanın elde etmesi beklenen olası işlevselliğe bakacağız.
III. Bitcoin Komut Dosyası Programlama
Bu bölümde, Bitcoin Script tabanlı uygulama programlama örnekleri olarak "Lightning Channel/Lightning Network" ve "Caution Journal Contract (DLC)" kullanacağız. Buna girmeden önce, iki şeyi ele alalım.
(1) OP_IF ve "Taahhüt Anlaşmaları"
İlk konsept, Bitcoin Script'teki akış kontrolü işlem kodudur, örneğin: OP_IF, OP_ELSE. Bu işlem kodları, bilgisayar programlamadaki IF'den farklı değildir ve amaçları, farklı girdilere dayalı olarak farklı ifadeler yürütmektir. Bitcoin Script bağlamında bu, fonlar için birden fazla kilit açma yolu belirleyebileceğimiz anlamına gelir; Zaman kilidi özelliği ile birlikte bu, eylemlere öncelik atayabileceğimiz anlamına gelir.
Örnek olarak ünlü "Hash Timelock Contract (HTLC)"yi ele alalım, bu da yerel dile çevrilir:
Bu "ya da ... veya ..." Etki, süreç kontrolü işlem kodu aracılığıyla elde edilir.
Taproot soft fork'un etkinleştirilmesinden sonra, bu çoklu kilit açma yolu özelliği, MAST'ın (Merkle Soyut Sözdizimi Ağacı) kullanıma sunulmasıyla daha da geliştirilmiştir: Merkle ağacında bir kilit açma yolunu bir yaprağa dönüştürebiliriz, her yaprak bağımsızdır, bu nedenle artık böyle bir akış kontrolü işlem kodu kullanmaya gerek yoktur; Ayrıca, bir yol diğerlerini açığa çıkarmadan ortaya çıktığı için, ekonomi konusunda endişelenmek zorunda kalmadan bir çıktıya daha fazla sayıda kilit açma yolu ekleyebiliriz.
İkinci kavram "taahhüt ticareti" dir. Taahhüt edilen bir işlem fikri, bazı durumlarda, geçerli bir Bitcoin işleminin, blok zinciri tarafından onaylanmasa bile, aynı derecede gerçek ve bağlayıcı olmasıdır.
Örneğin, Alice ve Bob, her ikisinin de harcama yapmak için imza atmasını gerektiren bir UTXO'yu paylaşır. Bu noktada Alice, değerinin %60'ını Bob'a, geri kalanını kendisine aktararak harcamak için bir işlem oluşturur; Alice, işlem için kendi imzasını sağlar ve bu imza daha sonra Bob'a gönderilir. Bob'a göre, Bitcoin ağında yayınlanması gerekmiyor ve blok zinciri tarafından onaylanması gerekmiyor ve bu işlemin ödeme etkisi de gerçek ve güvenilir. Alice UTXO'yu kendi başına harcayamayacağından (ve dolayısıyla tekrar tekrar harcayamayacağından) ve Alice tarafından sağlanan imza geçerli olduğundan, Bob her zaman imzasını ekleyebilir ve ödemeyi yerine getirmek için işlemi yayınlayabilir. Başka bir deyişle, Alice, bu geçerli (zincir dışı) işlem aracılığıyla Bob'a "güvenilir bir taahhüt" sağladı.
Taahhüt edilen işlemler, Bitcoin uygulama programlamasının temel bir kavramıdır. Daha önce de belirtildiği gibi, Bitcoin'in sözleşmesi doğrulamaya dayalıdır, durumsuzdur ve çapraz erişime izin vermez; Bununla birlikte, sözleşme devletleri taşımıyorsa, bu devletler nerede saklanır ve sözleşme nasıl güvenli bir şekilde ilerleyebilir? Taahhüt işlemleri basit bir cevap verir: sözleşmenin durumu işlemler şeklinde ifade edilebilir, böylece sözleşmenin katılımcıları durumu blok zincirinde görüntülemek zorunda kalmadan kendileri kurtarabilir; Sözleşmenin durumunu değiştirme sorunu, taahhüt edilen işlemin güvenli bir şekilde nasıl güncelleneceği sorununa da dönüştürülebilir; Buna ek olarak, bir sözleşmeye girmenin tehlikelerinden endişe duyuyorsak (örneğin, her iki tarafın da harcama yapmak için imzalamasını gerektiren bir sözleşmeye girmek ve diğer tarafın yanıt vermeme ve takılma riski varsa), o zaman sadece sözleşmeye önceden mal olan bir taahhüt işlemi oluşturmak ve imza almak riski azaltabilir ve diğer katılımcılara olan güveni ortadan kaldırabilir.
(2) Yıldırım kanalı ve yıldırım ağı
Yıldırım kanalı, iki tarafın blok zinciri tarafından onaylanan herhangi bir ödeme olmadan birbirlerine sınırsız sayıda ödeme yapabileceği bire bir sözleşmedir. Tahmin edebileceğiniz gibi, taahhüt ticareti kullanır.
"Taahhütlü İşlemler" bölümünü açıklayan bölümde, zaten bir ödeme kanalı tanıttık. Ancak, yalnızca 2'nin 2'sinden yararlanan bu tür bir sözleşme, yalnızca tek yönlü ödemeleri mümkün kılabilir. Yani, ya Alice her zaman Bob'a ödeme yapar ya da Bob, sözleşmedeki bakiyesini kullanana kadar Alice'e her zaman ödeme yapar. Bu iki yönlü bir ödemeyse, bir durum güncellemesinden sonra bir tarafın öncekinden daha az bakiyesi olabileceği, ancak TA'nın diğer tarafça imzalanmış son taahhüt işlemine sahip olduğu anlamına gelir - TA'nın eski taahhüdü yayınlamasını ve TA'nın yalnızca en son taahhüt işleminden yayınlamasını durdurmak için ne yapılabilir?
Yıldırım kanalı ile ilgili bu sorunun çözümüne "LN-Cezası" denir. Şimdi, Alice ve Bob'un her birinin bir kanalda 5 BTC'si olduğunu varsayalım; Şimdi Alice, Bob'a 1 BTC ödemek istiyor, bu yüzden vaat edilen işlemi imzalıyor ve Bob'a gönderiyor:
Bob ayrıca (yukarıdaki işleme karşılık gelen) bir taahhüt imzalar ve bunu Alice'e gönderir:
Buradaki püf noktası, kendi açık anahtarlarından biri ve diğer tarafça sağlanan bir açık anahtar kullanılarak oluşturulan bu "ortak geçici açık anahtar"da yatmaktadır, örneğin, Alice-Bob ortak geçici açık anahtarı, Alice tarafından kendi açık anahtarlarından biri ve Bob tarafından sağlanan bir açık anahtar kullanılarak elde edilen ve her birinin bir hash değeri ile çarpılması. Böyle bir genel anahtar oluşturulduğunda, hiç kimse özel anahtarını bilmez. Ancak, Bob Alice'e sağladığı ortak anahtarın özel anahtarını söylerse, Alice federasyon geçici ortak anahtarının özel anahtarını hesaplayabilir. - Bu, Yıldırım Kanalı'nın eski durumu "geri alabileceği" gerçeğinin anahtarıdır.
İki taraf bir dahaki sefere kanal durumunu güncellemek (bir ödeme başlatmak) istediğinde, iki taraf önceki turda birbirlerine verilen geçici açık anahtarın özel anahtarını değiştirir. Bu şekilde, katılımcılar artık aldıkları son vaat edilen işlemi yayınlamaya cesaret edemezler: kendi taraflarına değer atayan bu vaat edilen işlemin çıktısının iki yolu vardır ve geçici açık anahtar yolunun özel anahtarı karşı taraf tarafından zaten bilinmektedir; Bu nedenle, eski taahhüt işlemi yayınlandıktan sonra, diğer taraf bu çıktıdaki tüm fonları almak için bu ortak geçici özel anahtarı hemen kullanabilir. - "LN-Cezası"nın anlamı budur.
Spesifik olarak, etkileşim sırası şu şekildedir: ödemeyi başlatan taraf önce diğer taraftan yeni bir geçici açık anahtar talep eder ve ardından yeni bir taahhüt işlemi oluşturur ve diğer tarafa teslim eder; Vaat edilen işlemi alan taraf, bir önceki turda verdiği geçici açık anahtarın özel anahtarını karşı tarafa gösterdi. Bu etkileşim dizisi, katılımcıların önceki turda aldıkları taahhüt işlemini geçersiz kılmadan önce her zaman yeni bir taahhüt işlemi almalarını sağlar ve bu nedenle güvene dayalı değildir.
Özetle, yıldırım kanalının temel tasarımları şunlardır:
Son olarak, HTLC taahhütlü bir işleme de yerleştirilebildiğinden, Lightning kanalı ödemeleri de iletebilir. Alice'in Daniel'e ulaşmak için önce ve sonra birbirine bağlanan yıldırım kanallarından oluşan bir yol bulabileceğini varsayarsak, Daniel ile bir kanal açmadan güvene dayalı olmayan çoklu atlamalı ödemeler elde edilebilir. Karşınızda Lightning Network var:
Alice böyle bir yol bulduğunda ve Daniel'e ödeme yapmak istediğinde, Daniel'den Bob için bir HTLC oluşturması için bir hash ister ve Bob'dan Carol'a bir mesaj iletmesini ve aynı HTLC'yi sağlamasını ister; Mesaj, Carol'dan mesajı Daniel'e iletmesini ve aynı HTLC'yi sağlamasını ister. Haber Daniel'e ulaştığında, Carol'a ön görüntüyü açıklar, bu da ona HTLC'nin değerini verir ve sözleşmenin durumunu günceller. Carol da aynısını yaptı, Bob'dan ödeme aldı ve kanal durumunu güncelledi; Son olarak, Bob ön görüntüyü Alice'e gösterir ve durumu günceller. HTLC'nin doğası gereği, bu ödeme zinciri ya birlikte başarılı ya da başarısız olur ve bu nedenle güvenilmezdir.
Lightning Network, her biri birbirinden bağımsız olan birbiri ardına gelen kanallardan oluşur. Bu, Alice'in diğer kişilerin kanallarında kaç etkileşim gerçekleştiğine, bu etkileşimlerin hangi para birimini kullandığına ve hatta kanalı gerçekten kullanıp kullanmadıklarına bakılmaksızın yalnızca Bob ile kanalında neler olup bittiğini bilmesi gerektiği anlamına gelir.
Lightning Network'ün ölçeklenebilirliği, yalnızca bir Lightning Kanalı içindeki ödeme hızının yalnızca her iki tarafın da donanım kaynaklarına yaptığı yatırımla sınırlı olduğu gerçeğine değil, aynı zamanda merkezi olmayan devlet depolaması nedeniyle tek bir düğümün en düşük maliyetle maksimum kaldıraçtan yararlanabilmesine de yansır.
(3) Yevmiye sözleşmelerine karşı dikkatli olun
Uyarıcı Günlük Sözleşmesi (DLC), Bitcoin Script'in dış olaylara bağlı finansal sözleşmeleri programlamasına izin veren "adaptör imzası" adı verilen bir şifreleme tekniği kullanır.
Bağdaştırıcı imzaları, bir imzanın yalnızca özel anahtar eklendikten sonra geçerli bir imza haline gelmesine izin verir. Schnorr imzasının standart biçiminin (R, s) olduğu bir Schnorr imzası örneğini ele alalım, burada:
Diyelim ki bir çift veri (R, s') veriyorum:
Açıkçası, bu geçerli bir Schnorr imzası değildir ve doğrulama formülünü geçmez, ancak doğrulayıcıya sadece R 2, r 2'nin özel anahtarını bilerek geçerli bir imza olabileceğini kanıtlayabilirim:
Bağdaştırıcı imzaları, bir imzanın geçerliliğini gizli bir veriye bağımlı hale getirir ve doğrulanabilir. Peki bunun finansal sözleşmelerle ne ilgisi var?
Diyelim ki Alice ve Bob bir top oyununun sonucuna bahse girmek istiyorlar. Alice ve Bob, 1 BTC'lik bir bahisle sırasıyla Green Goblin ve Alina'nın kazanacağına bahse girer. Buna ek olarak, bir futbol inceleme sitesi olan Carol, maçın sonuçları açıklandığında sonuçların imzalı bir _c_i göndermek için bir nonce R_c kullanma sözü verdi.
Görülebileceği gibi, üç olası sonuç vardır (yani Carol'ın imzası için 3 olasılık vardır):
Green Goblin kazandı, Alice 1 BTC kazandı
Alina kazanır ve Bob 1 BTC kazanır
Beraberlik, ikisinin fonları aynı şekilde geri döner
Bunu yapmak için, ikisi her sonuç için bir taahhüt anlaşması oluşturur. Örneğin, ilk sonuç için oluşturdukları taahhüt işlemi şöyle görünür:
Ancak, (R, s) yerine, Alice ve Bob'un bu işlem için oluşturduğu imza bir bağdaştırıcı imzasıdır (R, s'); Başka bir deyişle, her iki tarafın birbirine verdiği imzalar, sözleşmenin kilidini açmak için doğrudan kullanılamaz, ancak gizli bir değeri ortaya çıkarmalıdır. Bu gizli değer, Carol'ın imzası olan s_c_ 1.G'nin ön görüntüsüdür! Carol'ın imzası olan nonce değeri belirlendiğinden (R_c), s_c_ 1.G oluşturulabilir (s_c_ 1.G = R_c + Hash(R_c ||). 'Green Goblin kazandı' || PK_c) * PK_c)。
Sonuçlar açıklandığında, Green Goblin'in kazandığını varsayarsak, Carol bir imza (R_c, s_c_ 1) yayınlayacak, böylece Alice veya Bob rakibin adaptör imzasını tamamlayabilir ve yukarıdaki işlemi geçerli bir işlem yapmak için kendi imzalarını ekleyebilir ve uzlaşma etkisini tetiklemek için ağa yayınlayabilir. Ancak Green Goblin kazanamazsa, Carol s_c_ 1'i göndermeyecek ve taahhüt anlaşması geçerli bir anlaşma olmayacak.
Ve benzeri, diğer iki esnaf gibi. Bu şekilde, Alice ve Bob, karşı tarafa güvenmek zorunda kalmadan sözleşmenin yürütülmesini dış olaylara (daha doğrusu, iddia makinesinin dış olayları imza şeklinde yayınlamasına) bağımlı hale getirir. Vadeli işlemler ve opsiyonlar gibi büyük ve küçük finansal sözleşmeler bu şekilde uygulanabilir.
Diğer uygulama biçimleriyle karşılaştırıldığında, ihtiyatlı günlük sözleşmesinin en önemli özelliği gizliliğidir: (1) Alice ve Bob'un Carol'a Carol'ın verilerini kullandıklarını söylemelerine gerek yoktur, bu da sözleşmenin yürütülmesini hiçbir şekilde etkilemez; (2) Zincir üstü gözlemciler (Carol dahil), Alice ve Bob'un sözleşme yürütmesi yoluyla hangi web sitesini kullandıklarını, hatta sözleşmelerinin bir bahis sözleşmesi (yıldırım kanalı değil) olduğunu belirleyemezler.
IV. Kısıtlamaların Uygulanmasına Giriş
(a) OP_CTV ve tıkanıklık kontrolü
Bitcoin topluluğunun geliştiricileri, kısıtlayıcı maddeler olarak sınıflandırılabilecek bir dizi teklifte bulundular. Şu anda, en iyi bilinen tekliflerden biri, basitliği ancak basit konseptiyle esnekliği nedeniyle Bitcoin topluluğu arasında popüler olan OP_CHECKTEMPLATEVERIFY (OP_CTV)'dir. OP_CTV fikri, fonların yalnızca bu hash tarafından temsil edilen işlemler tarafından harcanabileceğini kısıtlamak için komut dosyasında bir hash işlemektir; Bu hash, işlemin çıktısını ve alanların çoğunu vaat eder, ancak işlemin girdisini değil, yalnızca girdi sayısını vaat eder.
"Tıkanıklık Kontrolü", OP_CTV'nin nasıl gösterilebileceğine iyi bir örnektir. Temel kullanım durumu, çok sayıda kullanıcının bir borsadan (güven gerektiren bir ortam) bir havuza çıkmasına yardımcı olmaktır; Bu havuz, gelecekte nasıl harcanacağını planlamak için OP_CTV kullandığından, kullanıcıların havuzdan kimsenin yardımı olmadan güvenilir bir şekilde çıkabilmelerini garanti eder; Ve bu havuz yalnızca bir UTXO gibi davrandığından, zincir içi işlemlere olan talep yüksek olduğunda (n çıktıdan 1 çıktıya; ayrıca n işlemden 1 işleme düşürüldü). Havuzdaki kullanıcılar havuzdan çıkmak için fırsat bekleyebilir.
Diyelim ki Alice, Bob ve Carol borsadan sırasıyla 5 BTC, 3 BTC ve 2 BTC çekmek istiyor. Daha sonra borsa 3 OP_CTV şubesi ile 10 BTC'lik bir çıktı yapabilir. Diyelim ki Alice para çekmek istiyor, şube 1'i kullanabilir; Şubenin OP_CTV'si tarafından kullanılan hash değeri ile 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 çekmesine ve kalan 2 BTC'yi Carol'a göndermesine izin veren bir havuzdur.
Bob veya Carol para çekmek istediğinde de aynı şey olur. Para çekerken, yalnızca ilgili OP_CTV çekini geçebilecek işlemleri kullanabilecekler, yani yalnızca ilgili tutarı kendilerine ödeyebilecekler ve keyfi olarak para çekemeyecekler; Kalan fonlar OP_CTV kilitli bir havuza gidecek ve böylece kalan kullanıcıların çekilme sırasına bakılmaksızın havuzdan güvenilir bir şekilde çıkarılabilmelerini garanti edecektir.
Özet olarak, OP_CTV'ın buradaki rolü, sözleşme için sözleşmenin ömrünün sonuna kadar olan yolu planlamaktır, böylece buradaki havuz sözleşmesi, hangi yolu izlerse seçsin veya hangi duruma giderse gitsin güvene dayalı olmayan çıkış niteliğini koruyabilir.
Bu OP_CTV'nin çok ilginç bir kullanımı da var: "gizli ama açığa çıkmayan tek yönlü ödeme kanalı". Alice'in böyle bir fon havuzu oluşturduğunu ve fonların aşağıdaki komut dosyasıyla güvenilir bir şekilde bir çıktıya çekilebileceğini garanti ettiğini varsayalım:
Alice bunu Bob'a açıklamasaydı, Bob böyle bir çıktının var olduğunu bilemezdi; Alice bunu Bob'a açıkladığında, Bob çıktıyı zamana duyarlı, tek yönlü bir ödeme kanalı olarak kullanabilir ve Alice, blok zincirinden onay beklemek zorunda kalmadan Bob'a hemen ödeme yapmak için kullanabilir. Bob, Alice'ten taahhüt işlemini kendi başına harcamadan önce zincire koymasını ister.
(b) OP_Vault ve güvenli
OP_VAULT, "kasalar" inşa etmek için özel olarak tasarlanmış kısıtlayıcı bir madde önerisidir.
Vault sözleşmesi, daha güvenli ve gelişmiş bir kendi kendine saklama biçimi olacak şekilde tasarlanmıştır. Mevcut çoklu imza sözleşmesi, tek bir özel anahtar için tek bir hata noktasından kaçınabilse de, bir saldırgan eşik sayıda özel anahtar elde ederse, cüzdanın sahibi çaresizdir. Apps Kasası, fonlarınıza tek bir harcama limiti uygulamak istiyor; Aynı zamanda, normal rotayı kullanarak ondan para çekerken, para çekme işlemi bir bekleme süresi uygulayacaktır; Ve bekleme süresi boyunca, para çekme işlemi, cüzdanın acil kurtarma işlemi ile kesintiye uğrayabilir. Böyle bir sözleşme ihlal edilse bile, cüzdanın sahibi bir karşı işlem başlatabilir (acil durum kurtarma şubesini kullanarak).
Teorik olarak, OP _CTV böyle bir sözleşmeyi de programlayabilir, ancak birçok rahatsızlık vardır, bunlardan biri komisyondur: işlemi taahhüt ederken, işlemin ödeyeceği ücreti de vaat eder. Bu sözleşmenin amacı göz önüne alındığında, sözleşmenin kurulması ile para çekilmesi arasındaki zaman aralığı çok uzun olmalıdır, bu nedenle uygun komisyonu tahmin etmek neredeyse imkansızdır. OP_CTV girdileri sınırlamasa da, girdi artırılarak ücret artırılabilir, sağlanan girdilerin tümü komisyon haline gelecektir, bu nedenle gerçekçi değildir; Diğer bir yol ise, çekilen fonları harcayarak yeni işlemlerde komisyon sağlamak olan CPFP'dir. Ek olarak, OP_CTV kullanımı, böyle bir Vault sözleşmesinin toplu olarak geri çekilemeyeceği (ve kesinlikle toplu olarak geri yüklenemeyeceği) anlamına gelir.
OP_VAULT önerisi, yeni işlem kodları (OP_VAULT ve OP_UNVAULT) önererek bu sorunları ele almaya çalışır. OP_UNVAULT toplu iş dayanıklılığı için tasarlanmıştır, bu nedenle şimdilik bundan bahsetmeyeceğiz. OP_VAULT şu şekilde davranır: komut dosyası ağacının bir dalına koyduğumuzda, belirli parametreler olmadan kullanılabilir bir işlem koduna (örneğin OP_CTV) işlemek için kullanılabilir; Bu şubeyi harcarken, işlemler belirli parametrelerde geçirilebilir, ancak diğer şubelerde geçirilemez. Sonuç olarak, önceden belirlenmiş bir ücret belirlemesi gerekmez ve şube harcandığında ayarlanabilir; Dalın da bir zaman kilidi olduğunu varsayarsak, bir zaman kilidi uygulayacaktır; Son olarak, yalnızca bulunduğunuz dalı değiştirebileceğiniz ve yeni komut dosyası ağacının başka hiçbir dalı (acil durum kurtarma dalı dahil) değiştirilmeyeceğinden, bu tür para çekme işlemlerini kesintiye uğratmamıza izin verilir.
Ek olarak, iki noktadan bahsetmeye değer: (1) OP_VAULT işlem kodu başka bir kısıtlama önerisine benzer şekilde davranır: OP_TLUV; Jeremy Rubin haklı olarak bunun bir dereceye kadar "hesaplama" kavramına yol açtığına dikkat çekiyor: OP_TLUV/OP_VAULT ilk olarak, tüketicinin parametreleri işlem koduna yeni bir işlemle ileterek tüm komut dosyası ağacı yaprağını güncellemesine izin verecek bir işlem kodu vaat ediyor; Artık "gelen verileri belirli kriterlere göre doğrulamak" ile ilgili değil, etkinleştirebileceği hesaplama sınırlı olsa da "gelen verilere dayalı yeni anlamlı veriler üretmek" ile ilgili.
(2) Tam OP_VAULT teklifi, daha iyi sonuçlar elde etmek için mempool politikasındaki bazı tekliflerden (örneğin, v3 işlemleri) de yararlanır. Bu bize "programlamanın" anlamının düşündüğümüzden daha geniş olabileceğini hatırlatır. (Benzer bir örnek, Nervos Ağındaki Açık İşlem'dir.) ）
V. CKB'yi Anlamak
Yukarıdaki iki bölümde, ilginç uygulamaları daha kısıtlı bir yapıda (Bitcoin UTXO) nasıl yazabileceğimizi açıklıyoruz; Böyle bir yapıya iç gözlem eklemeye çalışmak için öneriler de sunuldu.
UTXO'lar bu uygulamaları programlama yeteneğine sahip olsa da, okuyucuların eksikliklerini veya optimize edilebilecek alanlarını tespit etmeleri kolaydır, örneğin:
Aslında, Bitcoin topluluğu, temelde bir Sighash önerisiyle (BIP-118 AnyPrevOut) ilgili bu soruların yanıtlarını buldu.
Bununla birlikte, CKB'de programlama yapıyor olsaydık, BIP-118 şu anda mevcut olurdu (bu tür Sighash etiketleri, imzaları içe dönük ve amaçlı olarak doğrulama yeteneği ile simüle edilebilir).
Bitcoin'i programlamayı öğrenerek, sadece "İşlem Çıktısı" (CKB'de ne programlanabilir) formatında programlanabileceklerini değil, aynı zamanda bu uygulamaları nasıl geliştireceğimizi de biliyoruz (ve CKB'de programlarsak bunları geliştirmek için CKB'nin yeteneklerini nasıl kullanabileceğimizi). CKB geliştiricileri için, Bitcoin Script tabanlı programlama bir öğrenme materyali, hatta bir kısayol olarak kullanılabilir.
Aşağıda, CKB programlamanın her bir modülünün programlanabilirliğini tek tek analiz edelim. Şimdilik iç gözlemi düşünmeyelim.
(1) Programlanabilir keyfi hesaplanan kilit
Yukarıda belirtildiği gibi, UTXO'lar keyfi olarak hesaplanacak şekilde programlanamaz. Öte yandan Lock, Lock'un yukarıda bahsedilen Lightning Channel ve DLC dahil ancak bunlarla sınırlı olmamak üzere UTXO'ya dayalı olarak her şeyi (kısıtlama dağıtımından önce) programlayabileceği anlamına gelir.
Ek olarak, rastgele hesaplamayı doğrulama yeteneği, Lock'u kimlik doğrulama yöntemleri açısından UTXO'dan daha esnek hale getirir. Örneğin, bir tarafın ECDSA'yı imzaladığı ve diğer tarafın RSA kullandığı CKB'ye bir yıldırım kanalı uygulayabiliriz.
Aslında bu, insanların CKB'de keşfetmeye başladığı ilk alanlardan biridir: "hesap soyutlama" olarak bilinen şeyi etkinleştirmek için kullanıcının kendi gözetiminde bu esnek kimlik doğrulama yeteneğini kullanmak - işlem geçerliliğinin yetkilendirilmesi ve kontrolün yeniden sağlanması çok esnek ve neredeyse sınırsızdır. Prensip olarak, bu "çoklu harcama dalları" ve "keyfi kimlik doğrulama yöntemlerinin" bir kombinasyonudur. Uygulama örnekleri şunlardır: joyid cüzdanı, UniPass.
Buna ek olarak, Lock, yalnızca en son taahhüt edilen işlemi tutması gereken bir yıldırım kanalını etkinleştirerek eltoo tekliflerini uygulayabilir (aslında, eltoo tüm eşler arası sözleşmeleri basitleştirebilir).
(2) Programlanabilir keyfi hesaplanan Tip
Yukarıda bahsedildiği gibi, Type'ın en büyük kullanımlarından biri UDT'leri programlamaktır. Lock ile birlikte bu, UDT tabanlı yıldırım kanallarını (ve diğer sözleşme türlerini) uygulayabileceğimiz anlamına gelir.
Aslında, Lock ve Type arasındaki ayrım bir güvenlik yükseltmesi olarak görülebilir: Lock, saklama yöntemlerinin veya sözleşmeye dayalı anlaşmaların uygulanmasına odaklanırken, Type, UDT'leri tanımlamaya odaklanır.
Ek olarak, UDT tanımlarına dayalı kontrollerin başlatılabilmesi, UDT'nin sözleşmelere CKB'ye benzer şekilde katılmasını da sağlar (UDT birinci sınıf vatandaştır).
Örneğin, yazar bir keresinde Bitcoin'de güvene dayalı olmayan NFT destekli borç vermeyi uygulamak için bir protokol önerdi. Böyle bir protokolün anahtarı, girdinin değerinin çıktının değerinden daha düşük olduğu (dolayısıyla henüz geçerli bir işlem olmadığı) taahhüt edilmiş bir işlemdir, ancak işlem için yeterli girdi sağlanabildiğinde, bu geçerli bir işlemdir: borç veren geri ödeyebildiğinde, borç veren stake edilen NFT'yi kendisi için alamaz. Bununla birlikte, bu taahhüt işleminin güvenilmezliği, girdi ve çıktı miktarını kontrol eden işleme dayanır, bu nedenle borç veren, krediyi geri ödemek için yalnızca Bitcoin'i kullanabilir - hem borç veren hem de borç veren başka bir para birimini kabul etmeye istekli olsa bile (RGB protokolü altında verilen USDT gibi), Bitcoin taahhüt işlemi, borç veren USDT'nin tamamını iade ettiği sürece borç verenin NFT'sini geri alacağını garanti etmez, çünkü Bitcoin işleminin USDT'nin durumu hakkında hiçbir fikri yoktur! (Revizyon: Başka bir deyişle, USDT geri ödemesine bağlı olarak taahhüt edilen bir işlem oluşturmak mümkün değildir.) ）
UDT'nin tanımına dayalı bir kontrol başlatabilirsek, borç verenin krediyi geri ödemek için USDT kullanmasına izin verecek başka bir taahhütlü işlem imzalamasını sağlayabiliriz. İşlem, girilen USDT miktarını ve çıkan USDT miktarını kontrol ederek kullanıcılara USDT ile güvene dayalı olmayan geri ödeme sağlar.
Sonra, iç gözlemi ele alalım.
(3) Kilit diğer kilitleri okur
Bu, önerilen kısıtlama uygulandıktan sonra Bitcoin UTXO'larında tüm programlama olanakları anlamına gelir. Bu, yukarıda bahsedilen Apps Kasası sözleşmelerinin yanı sıra OP_CTV tabanlı uygulamaları (ör. tıkanıklık kontrolü) içerir.
XueJie bir keresinde çok ilginç bir örnekten bahsetmişti: CKB'de bir tahsilat hesabı hücresi uygulayabilirsiniz, bu tür bir hücreyi işlemin girdisi olarak kullanırken, çıktı hücresi (aynı kilidi kullanan hücre) daha fazla kapasiteye sahipse, girdinin bir imza sağlaması gerekmez ve işlemin geçerliliğini etkilemez. Aslında, bu tür bir hücre, iç gözlem yeteneği olmadan mümkün olmazdı. Bu tahsilat hesap hücresi, fonları bir araya getirdiği ve iyi bir mahremiyet duygusuna sahip olmama dezavantajına sahip olduğu için kurumsal bir para alma yöntemi olarak idealdir.
(4) Kilit diğer türleri (ve verileri) okur
Bu yeteneğin ilginç bir uygulaması da stake token'lardır. Lock, diğer girdilerdeki jeton sayısına ve nerede harcanabileceğine bağlı olarak kendi kapasitesini kullanıp kullanamayacağına karar verecektir (iç gözlem kilidi yeteneği gerektirir).
(5) Tip diğer kilitleri okur
Emin değilim, ancak yararlı olduğu varsayılabilir. Örneğin, bir işlemin giriş ve çıkışlarının Kilitlerinin değişmeden kaldığını Tür'de kontrol edebilirsiniz.
(6) Type Scirpt diğer türleri (ve verileri) okur
Koleksiyon kartları? Daha büyük bir jeton karşılığında n jeton toplayın :)
VI. Sonuç
Ethereum gibi keyfi hesaplama ile programlanabilen önceki akıllı sözleşme sistemleriyle karşılaştırıldığında, Nervos Network farklı bir yapıya sahiptir; Sonuç olarak, geçmişin akıllı sözleşme sistemlerinin bilgisine dayanarak Nervos Network'ü anlamak genellikle zordur. Bu makale, CKB Hücresi, BTC UTXO'dan daha kısıtlı bir yapının uygulama programlamasından başlayarak CKB Hücresinin programlanabilirliğini anlamak için bir yöntem önermektedir. Ve hücrelerin "sözleşmeler arası erişim" yeteneklerini anlamak için "iç gözlem" kavramını kullanarak, iç gözlem yeteneklerinin kullanıldığı durumları bölebilir ve özel kullanımlarını belirleyebiliriz.
Düzeltme:
Yukarıdaki iki nokta, "BTC + RGB" ile aynı paradigmaya sahip, ancak daha fazla programlama yeteneğine sahip bir şey ifade ediyor;
Bu kullanımların çok fazla spesifik örneği yoktur, ancak bu, yazarın CKB ekolojisini anlamamasından kaynaklanmaktadır. Zamanla, daha fazla hayal gücüne yatırım yapılacağına ve bugün hayal bile edilemeyen uygulamaların bir araya getirileceğine inanılıyor.
Teşekkür
Makalenin yazımı sırasındaki geri bildirimleri için Retric, Jan Xie ve Xue Jie'ye teşekkürler. Tabii ki, metindeki tüm hatalardan ben sorumluyum.
Referanslar
Hesaplar, Katı Erişim Listeleri ve UTXO'lar
Bitcoin'deki Kısıtlamalar: İnceleme için Taksonomi
Hücre Modeli
Özetle Nervos CKB
Bitcoin'in programlanabilirliği
Hesap Soyutlaması (2022)
Bitcoin Merkelleştirilmiş Soyut Sözdizimi Ağacı nedir?
BIP 345: OP_VAULT önerisi
TLUV kısıtlama işlem kodlarına giriş
Sözleşmeyi oluşturan bileşenler Bitcoin ile yükseltilir
Eltoo açıkladı
Taahhüt Edilen İşlemlere Dayalı NFT Teminatlı Borç Verme Sözleşmesi · btc-çalışması/OP_QUESTION · Tartışma #7
Orijinal makaleye bağlantı