Yazan: Chakra Research
Genel Bakış
Ethereum gibi Turing-tamamlanmış blok zincirleriyle karşılaştırıldığında, Bitcoin üzerindeki komut dosyalarının çok sınırlı olduğu ve yalnızca temel işlemleri gerçekleştirebildiği ve hatta çarpma ve bölmeyi desteklemediği düşünülmektedir. Daha da önemlisi, blockchain verilerinin komut dosyaları tarafından okunması neredeyse imkansızdır, bu da ciddi bir esneklik eksikliğine ve düşük programlanabilirliğe neden olur. Bu nedenle insanlar uzun süredir Bitcoin Scriptlerini içe dönük hale getirmenin yollarını bulmaya çalışıyorlar.
İç gözlem, Bitcoin komut dosyalarının işlem verilerini incelemesine ve kısıtlamasına izin verme yeteneğini ifade eder. Bu, komut dosyalarının bir işlemin belirli ayrıntılarına göre fon kullanımını kontrol etmesine olanak tanıyarak daha karmaşık işlevsellik sağlar. Mevcut Bitcoin işlem kodlarının (Opcode'lar) çoğunun yalnızca iki işlevi vardır: kullanıcı tarafından sağlanan verileri yığına itmek veya yığındaki mevcut veriler üzerinde işlem yapmak. İç gözlem işlem kodu, UTXO'nun nasıl harcandığı üzerinde daha ayrıntılı kontrol sağlamak için mevcut işlem verilerini (zaman damgası, tutar, işlem kimliği vb.) yığına gönderebilir.
Şu anda, Bitcoin Script'te yalnızca üç ana işlem kodu iç gözlemi desteklemektedir: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY ve CHECKSIG; CHECKSIG'in ayrıca CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG ve CHECKMULTISIGVERIFY gibi çeşitleri vardır.
Basitçe söylemek gerekirse, sözleşme, tokenlerin nasıl aktarılabileceğine ilişkin bir kısıtlamadır. Kullanıcılar, sözleşme aracılığıyla UTXO'nun dağıtım yöntemini belirleyebilirler. Birçok sözleşme iç gözlem işlem kodları aracılığıyla uygulanır ve iç gözlem artık Bitcoin Optech'teki sözleşme girişleri altında tartışılmaktadır.
Bitcoin'in şu anda CSV (CheckSequenceVerify) ve CLTV (CheckLockTimeVerify) olmak üzere iki sözleşmesi vardır ve bunların her ikisi de Lightning Network gibi birçok genişleme planının temelini oluşturan zaman sözleşmeleridir. Bundan ayrıca Bitcoin'in genişleme planının büyük ölçüde iç gözlem ve sözleşmelere dayandığını da görebiliriz.
Token transferine kısıtlamalar nasıl eklenir? Şifreleme dünyasında en sık kullanılan yöntem, çoğunlukla hash yoluyla uygulanan taahhüttür. Transfer şartlarını yerine getirdiğimizi kanıtlamak için bunu bir imza mekanizması aracılığıyla doğrulamamız gerekiyor. Bu nedenle sözleşmede hash ve imzalarda birçok düzenleme bulunmaktadır.
Aşağıda geniş çapta tartışılan sözleşme işlem kodu teklifini açıklıyoruz.
CTV (CheckTemplateVerify) BIP-119
CTV (CheckTemplateVerify), topluluk tarafından hararetle tartışılan ve BIP-119'a dahil edilen bir Bitcoin yükseltmesidir. CTV, çıkış komut dosyasının, nVersion, nLockTime, scriptSig hash, giriş sayısı, dizi karması, çıkış sayısı, çıkış karması, giriş indeksi ve işlemin diğer alanları dahil olmak üzere harcama işlemindeki fonları kullanmak için şablonu belirlemesine olanak tanır. kısıtlamalar bir karma üzerinden geçirilir Bunu başarmak için, gelecekteki harcama komut dosyası, harcama işlemindeki belirtilen alanın karma değerinin giriş komut dosyasındaki karma değerle eşleşip eşleşmediğini kontrol edecektir. Bu şablonlar aslında süreyi, yöntemi, tutarı ve diğer ayrıntıları sınırlar. UTXO'nun gelecekteki harcama işleminin.
TXID girişinin karma vaadinin dışında tutulduğunu belirtmekte fayda var. Bu hariç tutma, ister Legacy ister Segwit işlemlerinde olsun, varsayılan SIGHASH_ALL imza türünde gereklidir, TXID'nin scriptPubKey değerine göre oluşturulması gerekir. Bu nedenle, TXID'nin dahil edilmesi hash vaadinde başarılı bir şekilde oluşturulamayan bir döngüye neden olacaktır.
CTV'nin iç gözlemi uygulama şekli, işlemin belirtilen bilgisini yeni bir işlem kodu aracılığıyla doğrudan elde etmek, karma hale getirmek ve bunu yığındaki taahhütle karşılaştırmaktır. Bu iç gözlem yöntemi zincirde daha az yer kaplar ancak belirli bir esneklikten yoksundur.
Bitcoin'in Lightning Network gibi ikinci katman çözümlerinin temeli önceden imzalanmış işlemlerdir. Ön imzalama genellikle işlemlerin önceden oluşturulup imzalanması ancak belirli koşullar karşılanana kadar bunların ağa yayınlanmaması anlamına gelir. Temelde CTV, önceden imzalanmış taahhüdü doğrudan zincirde yayınlayarak daha katı bir imzalama öncesi işlevi uygular ve işlemler yalnızca ön şablona göre gerçekleştirilebilir.
CTV başlangıçta, tıkanıklık kontrolü olarak da adlandırılabilecek Bitcoin tıkanıklığını hafifletmek için önerildi. Bitcoin nispeten sıkışık olduğunda, CTV, tıkanıklık sırasında birden fazla işlemi yayınlamak zorunda kalmadan tek bir işlem aracılığıyla gelecekteki birden fazla işlemi gerçekleştirmek ve ardından blok sıkışıklığı hafifledikten sonra gerçek işlemi tamamlamak için kullanılabilir. Bir borsada bir sorun yaşandığında tıkanıklık kontrolü çok faydalı olabilir. Ayrıca şablonlar, bilgisayar korsanlarının saldırılarını önlemek amacıyla kasaları uygulamak için de kullanılabilir. Fonların varış yeri belirlendiğinden hacker, CTV betiğini kullanarak UTXO’yu kendi adresine gönderemez.
CTV, katman 2 ağlarına büyük iyileştirmeler getirebilir. Örneğin, Lightning Network'te Zaman Aşımı Ağaçları ve kanal fabrikalarının CTV aracılığıyla uygulanması için tek bir UTXO, bir CTV ağacına genişletilebilir ve aynı anda birden fazla durum kanalı açılabilirken, yalnızca bir işlem ve bir onay vardır. zincir üzerinde. Ayrıca CTV, Ark protokolünde ATLC atom işlemlerine de destek sağlar.
APO (SIGHASH_ANYPREVOUT) BIP-118
BIP-118, daha esnek harcama mantığı yazmayı kolaylaştırmak amacıyla tapscript için SIGHASH_ANYPREVOUT adı verilen yeni bir tür imzalı karma bayrağı önerir. APO ve CTV birçok açıdan benzerdir. scriptPubKeys ve TXID arasındaki döngü sorunuyla karşı karşıya kalan APO'nun çözümü, girişle ilgili bilgileri hariç tutmak ve yalnızca çıktıyı imzalamaktır, böylece işlemler dinamik olarak farklı UTXO'ya bağlanabilir.
Mantıksal olarak bölünmüş imza doğrulama işlemi OP_CHECKSIG (ve benzer işlem kodları) üç işleve sahiptir:
Bir harcama işleminin çeşitli bölümlerini bir araya getirmek
Vuruldu.
Karmanın verilen anahtar tarafından imzalandığını doğrulayın.
İmzanın özel içeriğinin ayarlanması için geniş bir alan vardır. Hangi işlem alanlarının imza için bir araya getirileceği SIGHASH bayrağıyla belirlenir. BIP 342 imza işlem kodunun tanımına göre, SIGHASH bayrakları SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, SIGHASH_ANYONECANPAY vb.'ye bölünmüştür; bunların arasında SIGHASH_ANYONECANPAY girişi kontrol eder ve geri kalanı kontrol çıkışını oluşturur.
SIGHASH_ALL, tüm çıktıları imzalayan varsayılan SIGHASH bayrağıdır; SIGHASH_NONE herhangi bir çıktıyı imzalamaz; SIGHASH_SINGLE belirli bir çıktıyı imzalamaz. SIGHASH_ANYONECANPAY, ilk üç SIGHASH bayrağıyla birlikte ayarlanabilir. SIGHASH_ANYONECANPAY ayarlanırsa yalnızca belirtilen giriş imzalanır, aksi takdirde tüm girişlerin imzalanması gerekir.
Açıkçası, bu SIGHASH işaretlerinin hiçbiri girdinin etkisini ortadan kaldıramaz. SIGHASH_ANYONECANPAY bile bir girdi taahhüdünü gerektirir.
Bu nedenle BIP 118 SIGHASH_ANYPREVOUT'u önerir. APO imzaları, UTXO girişinin (PRVOUT olarak adlandırılır) harcanmasını gerektirmez, yalnızca çıktının harcanmasını gerektirir, bu da Bitcoin kontrolü için daha fazla esneklik sağlar. İşlemin önceden oluşturulması ve ilgili tek kullanımlık imzanın ve genel anahtarın oluşturulmasıyla, genel anahtar adresine gönderilen varlıkların, sözleşmenin uygulanması için önceden oluşturulan işlem aracılığıyla harcanması gerekir. APO'nun esnekliği işlem onarımı için de kullanılabilir. Bir işlem düşük ücretler nedeniyle zincirde takılı kalırsa, yeni imzalara gerek kalmadan daha yüksek ücretlerle başka bir işlem kolayca oluşturulabilir. Ayrıca çoklu imzalı cüzdanlarda imzalar harcanan girdilere dayanmaz, bu da işlemi kolaylaştırır.
scriptPubKeys ile TXID girişi arasındaki döngü ortadan kaldırıldığı için. APO, tanığa (Witness) çıktı verileri ekleyerek iç gözlemi uygulayabilir. Elbette bu yine de ek tanık veri alanı tüketimini gerektirir.
Lightning Network ve Vault gibi zincir dışı protokoller için APO, kaydedilmesi gereken ara durumu azaltarak depolama gereksinimlerini ve karmaşıklığı büyük ölçüde azaltır. APO'nun en doğrudan kullanım örneği, kanal fabrikasını basitleştiren, hafif ve ucuz bir gözetleme kulesi inşa eden ve hata durumundan ayrılmadan tek taraflı çıkışa izin vererek Lightning Network'ün performansını her açıdan artıran Eltoo'dur. APO aynı zamanda CTV'nin işlevlerini simüle etmek için de kullanılabilir, ancak bireylerin imzaları ve önceden imzalanmış işlemleri saklamasını gerektirir; bu da daha maliyetlidir ve CTV kadar verimli değildir.
APO'ya yönelik ana eleştiri, tamamen geriye dönük uyumluluk yoluyla elde edilemeyecek yeni bir anahtar sürüm gerektirmesidir. Ayrıca yeni imza karma türleri potansiyel çift harcama risklerini de beraberinde getirebilir. Toplulukta yapılan yoğun tartışmaların ardından APO, orijinal imzaya ek olarak ortak bir imzanın eklenmesini talep etti ve güvenlik sorunu hafifletildi ve APO, BIP-118 numarasını aldı.
OP_VAULT BIP-345
BIP-345, kullanıcıların belirli belirteçlerin harcaması için bir gecikme süresi zorlamasına olanak tanıyan özel bir sözleşme uygulamak üzere CTV ile birleştirilecek iki yeni işlem kodu (OP_VAULT ve OP_VAULT_RECOVER) eklemeyi önerir. Gecikme süresi boyunca önceki veriler geri yüklenebilir. kurtarma yolu aracılığıyla "Geri Al" harcayın.
Kullanıcılar belirli bir Taproot adresi oluşturarak bir kasa oluşturabilir. MAST'ın en az iki komut dosyası, beklenen para çekme işlemini kolaylaştırmak için bir OP_VAULT komut dosyası ve para çekme işlemi tamamlanmadan herhangi bir zamanda yapılmasını sağlamak için başka bir OP_VAULT_RECOVER komut dosyası içermesi gerekir. restore edilecek.
OP_VAULT Kesintili, zaman kilitli para çekme işlemleri nasıl uygulanır? Basitçe söylemek gerekirse, OP_VAULT işlem kodu tek bir şeyi başarır: harcanan OP_VAULT komut dosyasını belirtilen komut dosyasıyla değiştirir, aslında MAST'ın tek bir yaprak düğümünün güncellenmesini tamamlar ve kalan yaprak düğümleri değiştirmeden bırakır. Tasarım, OP_VAULT'un dahili anahtar güncellemelerini desteklememesi dışında TLUV'ye benzer.
Komut dosyası güncelleme işlemi sırasında şablonların tanıtılması, ödemelerin sınırlandırılması etkisini sağlayabilir. Bunların arasında, zaman kilidi parametresi OP_VAULT tarafından belirtilir ve CTV opcode'un getirdiği şablon, bu komut dosyası yolu üzerinden harcanan çıktı kümesini sınırlar.
BIP-345, kasalar için doğmuştur. OP_VAULT ve OP_VAULT_RECOVER ile kullanıcılar, kurtarma yolu olarak yüksek güvenlikli bir anahtarla (kağıt cüzdan, dağıtılmış çoklu imza) güvenli bir saklama yöntemine ve günlük ödeme yapılandırmasının geri kalanına sahip olabilir. gecikmiş. Kullanıcının cihazı kasanın harcamalarını sürekli olarak izler ve beklenmedik bir aktarım meydana gelirse kullanıcı bunu geri yükleyebilir.
BIP-345, kasaları uygularken, özellikle de işlemleri geri yüklerken maliyet hususlarının dikkate alınmasını gerektirir. Olası çözümler arasında CPFP, geçici bağlantı noktaları ve SIGHASH_GROUP gibi yeni imza karma bayrakları yer alır.
TLUV (TapleafUpdateVerify)
TLUV çözümü Taproot temel alınarak oluşturulmuştur ve paylaşılan UTXO'dan verimli bir şekilde çıkış sorununu çözmeyi amaçlamaktadır. Yol gösterici fikir, bir Taproot çıktısı harcandığında, TLUV betiğinde açıklanan güncelleme adımlarına göre Taproot adresinin iç yapısını ve kriptografik dönüşümünü kullanarak dahili anahtarı ve MAST'ı kısmen güncelleyebiliriz, böylece sözleşme işlevini gerçekleştirebiliriz. .
TLUV çözümünün fikri, yeni bir TAPLEAF_UPDATE_VERIFY işlem kodu aracılığıyla, aşağıdaki işlemlerden bir veya daha fazlasını gerçekleştirerek mevcut tüketim girişine dayalı yeni bir Taproot adresi oluşturabilmenizdir:
Dahili ortak anahtarı güncelle
merkle yolunu kırpma
Şu anda yürütülen yaprak düğümü kaldırın
Merkle yolunun sonuna yeni bir yaprak düğümü ekleyin
TLUV özellikle üç girdi alır:
Bunlardan biri dahili ortak anahtarın nasıl güncelleneceğini belirtir
Biri Merkle yolu için yeni bir yaprak düğümü belirtir
Bunlardan biri mevcut yaprak düğümün kaldırılıp kaldırılmayacağını ve/veya kaç tane Merkle yolu yaprak düğümünün kaldırılacağını belirtir
TLUV işlem kodu, güncellenen scriptPubKey'i hesaplar ve geçerli girişe karşılık gelen çıktının bu scriptPubKey'i tükettiğini doğrular.
TLUV'un ilham verici senaryosu CoinPool'dur. Bugün yalnızca önceden imzalanmış işlemleri kullanarak birleştirilmiş bir havuz oluşturmak mümkündür, ancak izinsiz bir çıkış elde etmek istiyorsanız katlanarak daha fazla sayıda imza oluşturmanız gerekir; TLUV ise herhangi bir ön imzalama olmadan izinsiz bir çıkışa olanak tanır. Örneğin, bir grup iş ortağı, birbirlerinin fonlarını bir havuzda toplayan paylaşılan bir UTXO oluşturmak için Taproot'u kullandı. Fonları dahili olarak taşımak için Taproot anahtarlarını kullanabilirler ve ayrıca ödemeleri harici olarak başlatmak için birlikte imza atabilirler. Bireyler, istedikleri zaman paylaşılan fon havuzundan çıkabilir ve kendi ödeme yollarını silebilir. Diğerleri, ödemeleri orijinal yoldan tamamlamaya devam edebilir. Aynı zamanda, bireyin çıkışı, içerideki diğer kişiler hakkında ek bilgileri açığa çıkarmaz. Havuzlanmayan işlemlerle karşılaştırıldığında bu yöntem daha verimli ve özeldir.
TLUV işlem kodu, orijinal MAST'ı güncelleyerek kısmi harcama kısıtlamaları uygular, ancak çıktı miktarının iç gözlemini uygulamaz. Bu nedenle, iki veri parçasını yığına iten yeni bir IN_OUT_AMOUNT işlem kodunu da eklemeniz gerekir: UTXO girişinin miktarı ve karşılık gelen çıktının miktarı ve ardından TLUV kullanan kişinin fonların doğrulandığını doğrulamak için matematiksel operatörler kullanmasını bekler. güncellenmiş scriptPubKey'de uygun şekilde ayrılmıştır.
Çıktı miktarının iç gözlemi, Bitcoin miktarının satoshi'de temsil edilmesi için en fazla 51 bit gerektirdiğinden, başka bir karmaşıklık katmanı ekler, ancak komut dosyası yalnızca 32 bitlik matematik işlemlerine izin verir ve işlem kodu davranış operatörünü yeniden tanımlayarak komut dosyasında yükseltilmesi gerekir. veya IN_OUT_AMOUNT yerine SIGHASH_GROUP kullanın.
TLUV'un merkezi olmayan Katman 2 fon havuzları için bir çözüm sunması bekleniyor. Tabii ki Taproot genel anahtar ayarlarının güvenilirliği henüz doğrulanmadı.
MAT
MATT (Merkleize All The Things) üç hedefe ulaşmaya çalışır: Merkle tabanlı durum, Merkle tabanlı komut dosyaları ve Merkle tabanlı yürütme ve ardından evrensel akıllı sözleşmeleri gerçekleştirir.
Merkle durumu: Her yaprak düğümün durumun karma değeri olduğu ve Merkle Kökünün tüm sözleşmenin durumunu temsil ettiği bir Merkle Trie oluşturun.
Merkle betiği: yani Tapscript'ten oluşan MAST. Her yaprak düğümü olası bir durum geçiş yoludur.
Merkle yürütmesi: Merkle yürütmesi, şifrelenmiş taahhüt ve dolandırıcılık mücadele mekanizmaları aracılığıyla gerçekleştirilir. Herhangi bir hesaplama işlevi için, katılımcılar zincir dışı hesaplama yapabilir ve ardından f(x)=y taahhüdünü serbest bırakabilir ve diğer katılımcılar hesaplama sonucunun yanlış olduğunu bulabilir. (x)= z, İyimser Toplama ile aynı prensip olan dikotomi yöntemini kullanarak meydan okuyabilir ve hakemlik yapabilirsiniz.
Merkle'nin etkin olduğu dolandırıcılık zorlukları
MATT'ı uygulamak için Bitcoin programlama komut dosyalarının aşağıdaki işlevselliğe sahip olması gerekir:
Bir çıktıyı belirli komut dosyalarına (ve bunların miktarlarına) sahip olmaya zorlayın
Bir çıktıya bir veri parçası ekleme
Geçerli girişten (veya diğer girişten) verileri okuyun
İkinci nokta çok önemlidir, dinamik veriler, durumun tüketici tarafından sağlanan giriş verilerinden hesaplanabileceği anlamına gelir, çünkü bu, durum makinesinin bir simülasyonunu sağlar ve ek verilerle bir sonraki durumu belirleyebilir. MATT çözümü, orijinal olarak önerilen OP_CHECKOUTPUTCONTRACTVERIFY ve OP_CHECKINPUTCONTRACTVERIFY işlem kodlarının bir birleşimi olan OP_CHECKCONTRACTVERIFY (OP_CCV) işlem kodunun önerilmesiyle uygulanır ve işlemin nesnesini belirtmek için ek bir flags parametresi kullanır.
Çıktı miktarının kontrolü: En doğrudan yol, doğrudan iç gözlemdir. Ancak çıktı miktarı 64 bitlik bir sayıdır ve 64 bitlik işlemler gerektirir; bu, Bitcoin komut dosyalarının uygulanmasında oldukça karmaşıktır. CCV, OP_VAULT'a benzer bir gecikmeli kontrol yöntemini benimser. Aynı çıkışa CCV'li tüm girişlerin giriş miktarları, çıkış miktarının alt sınırı olarak toplanır. Gecikme, kontrolün girilen betiğin değerlendirilmesi sırasında değil, işlem sırasında yapılmasından kaynaklanmaktadır.
Dolandırıcılığa karşı korumanın genelliği göz önüne alındığında, MATT sözleşmesinin bazı çeşitleri her türlü akıllı sözleşmeyi veya ikinci katman yapıyı mümkün kılmalıdır; ancak ek gerekliliklerin (sermaye kilitleme ve sorgulama süresi gecikmeleri gibi) doğru bir şekilde değerlendirilmesi gerekmektedir; Hangi Uygulamanın kabul edilebilir bir işlem olduğunu değerlendirmek. Örneğin, Bitcoin'de güvenilir Toplama uygulamak için OP_ZK_VERIFY işlevini simüle etmek için kriptografik taahhüt ve sahtekarlığa karşı mücadele mekanizması kullanılır.
Aslında bu zaten oluyor. Johan Torås Halseth, Bitcoin zincirinde RISC-V derlemesini destekleyen tüm programları doğrulayabilen, sözleşme anlaşmasındaki bir tarafın sözleşme aracılığıyla fon almasına olanak tanıyan ve bir köprü elde eden MATT yumuşak çatal teklifindeki OP_CHECKCONTRACTVERIFY işlem kodunu kullanarak elftrace'i uyguladı. Bitcoin'in yerel doğrulamasına.
CSFS (OP_CHECKSIGFROMSTACK)
APO işlem kodunun tanıtılmasından itibaren OP_CHECKSIG'in (ve ilgili işlemlerinin) işlemlerin bir araya getirilmesinden, karma işleminden ve imzaların doğrulanmasından sorumlu olduğunu öğrendik. Ancak doğruladığı mesaj, bu işlem kodunu kullanarak işlemin serileştirilmesiyle elde edilir ve başka hiçbir mesajın belirtilmesine izin verilmez. Basitçe söylemek gerekirse, OP_CHECKSIG (ve ilgili işlemleri), işlem girişi olarak UTXO girişinin imza sahibi tarafından harcanmaya yetkili olup olmadığını doğrulamak için imza mekanizmasını kullanır ve böylece Bitcoin'in güvenliğini korur.
CSFS, adından da anlaşılacağı gibi yığındaki imzaları kontrol eder. CSFS işlem kodu yığından üç parametre alır: bir imza, bir mesaj ve bir genel anahtar ve imzanın geçerliliğini doğrular. Bu, kişinin tanık verileri aracılığıyla yığına rastgele mesajlar iletebileceği ve bunun CSFS tarafından doğrulanmasını sağlayabileceği anlamına gelir. Bu da biraz para birimi üzerinde bazı yeniliklerin mümkün olmasını sağlıyor.
CSFS'nin esnek özellikleri, ödeme imzaları, yetki devri, oracle sözleşmeleri, çift harcama koruma tahvilleri gibi birden fazla mekanizmayı uygulamaya olanak tanır ve daha da önemlisi, işlem iç gözlemini mümkün kılar. İşlem iç gözlemi için CSFS'yi kullanma ilkesi çok basittir. OP_CHECKSIG tarafından kullanılan işlem içeriği tanık aracılığıyla yığına gönderilirse, içeriği hem CSFS hem de OP_CHECKSIG ile doğrulamak için aynı genel anahtar ve imza kullanılır. , CSFS'ye iletilen herhangi bir mesajın içeriği, OP_CHECKSIG için örtülü olarak kullanılan serileştirilmiş harcama işlemiyle (ve diğer verilerle) aynıdır. Yığındaki işlem verilerini doğruladık ve harcama işlemine diğer işlem kodlarını uygulayabiliriz.
CSFS genellikle OP_CAT ile birlikte görünür, çünkü OP_CAT serileştirmeyi tamamlamak için işlemin farklı alanlarını birbirine bağlayabilir ve iç gözlemlenmesi gereken işlem alanlarını daha doğru bir şekilde seçebilir. OP_CAT olmadan, komut dosyası ayrı ayrı kontrol edilebilecek verilerden hash'i yeniden hesaplayamaz, dolayısıyla gerçekten yapabileceği tek şey, hash'in belirli bir değere eşit olup olmadığını kontrol etmektir; bu, coinin yalnızca tek bir belirli işlem yoluyla harcanabileceği anlamına gelir.
CSFS, CLTV, CSV, CTV, APO ve diğer işlem kodlarını uygulayabilir. Bu, genel bir iç gözlem işlem kodudur, dolayısıyla Bitcoin Layer 2 genişletme planına da yardımcı olabilir. Dezavantajı ise imzalanan işlemin tam bir kopyasının yığına eklenmesi gerekmesidir; bu da CSFS ile iç gözlem yapmak istediğiniz işlemlerin boyutunu önemli ölçüde artırabilir. Karşılaştırıldığında, CLTV ve CSV gibi tek amaçlı iç gözlem işlem kodları minimum düzeyde ek yük kullanır, ancak her yeni özel iç gözlem işlem kodunun eklenmesi bir fikir birliği değişikliği gerektirir.
TXHASH (OP_TXHASH)
OP_TXHASH, operatörün yığına aktarılacak alanın karma değerini seçmesine olanak tanıyan çok basit bir iç gözlem işlem kodudur. Spesifik olarak, OP_TXHASH yığından bir txhash bayrağı çıkaracak, bu bayrağa dayalı (etiketli) bir txhash hesaplayacak ve elde edilen karmayı yığına itecektir.
TXHASH ve CTV arasındaki benzerlik nedeniyle toplumda ikisi hakkında pek çok tartışma yaşandı.
TXHASH, CTV'ye yönelik genel bir yükseltme olarak görülebilir; kullanıcıların bir işlemin bir kısmını açıkça harcamasına olanak tanıyan ve işlem ücretleriyle ilgili birçok sorunu çözen daha gelişmiş bir işlem şablonu sağlar. Diğer sözleşme işlem kodlarıyla karşılaştırıldığında, TXHASH'in tanıkta gerekli verilerin bir kopyasını sağlamasına gerek yoktur, bu da depolama ihtiyacını daha da azaltır; CTV'den farklı olarak TXHASH, NOP uyumlu değildir ve yalnızca TXHASH ve tapscript kombinasyonunda uygulanabilir; CSFS, CTV ve APO'ya alternatif olarak düşünülebilir.
Sözleşmenin oluşturulma şekli açısından bakıldığında, TXHASH, sabitlemek istediğiniz işlem verilerinin tüm parçalarını yığına iterek, hepsini bir araya toplayarak ve ortaya çıkan karmanın doğrulandığını doğrulayarak bir "ek sözleşme" uygulamayı kolaylaştırır. sabit değerle eşleşir; CTV Serbest tutmak istediğiniz işlem verilerinin tüm bölümlerini yığına aktararak "çıkarıcı sözleşmeler" uygulamak daha kolaydır. Daha sonra, işlem karma verilerinin önekini taahhüt eden sabit bir ara durumdan başlamak için yuvarlanan OP_SHA256'yı kullanın. Serbest kısım bu ara duruma dönüştürülür.
TXHASH spesifikasyonunda tanımlanan TxFieldSelector alanının OP_TX gibi diğer işlem kodlarını da kapsayacak şekilde genişletilmesi bekleniyor.
TXHASH ile ilgili BIP şu anda Github'da Taslak durumundadır ve henüz numaralandırılmamıştır.
OP_CAT
OP_CAT oldukça gizemli bir işlem kodudur. Güvenlik sorunları nedeniyle Satoshi Nakamoto tarafından terk edilmiştir. Son zamanlarda Bitcoin çekirdek geliştiricileri arasında çok sayıda tartışmaya neden olmuş ve hatta internette bir Meme kültürünü tetiklemiştir. Sonunda OP_CAT tarafından onaylanmıştır. BIP-347 ve birçok kişi buna yakın gelecekte kabul edilmesi muhtemel olan BIP teklifi diyor.
Aslında OP_CAT yığındaki iki öğeyi tek bir öğede birleştirerek çok basit davranır. Sözleşme işlevi nasıl uygulanır?
Aslında iki öğeyi birleştirme işlevi, güçlü bir kriptografik veri yapısına, Merkle Trie'ye karşılık gelir. Merkle Trie'nin yapım süreci yalnızca iki işlem gerektirir: ekleme ve karma ve Bitcoin komut dosyalarında karma işlevleri mevcuttur. Dolayısıyla OP_CAT ile blockchainde en sık kullanılan hafif doğrulama yöntemi olan Merkle Proof'u Bitcoin scriptinde teorik olarak doğrulayabiliyoruz.
Daha önce de belirtildiği gibi CSFS, OP_CAT'ın yardımıyla ortak bir sözleşme şeması uygulayabilmektedir. Aslında OP_CAT, Schnorr imzalarının yapısından yararlanarak CSFS olmadan işlem iç gözlemini uygulayabilir.
Schnorr imzasında imzalanması gereken mesaj aşağıdaki alanlardan oluşur:
Bu alanlar işlemin ana unsurlarını içerir. Bunları bir scriptPubKey veya tanığın içine yerleştirerek OP_CAT ve OP_SHA256'yı kullanarak bir Schnorr imzası oluşturabilir ve bunu OP_CHECKSIG kullanarak kontrol edebiliriz. Doğrulama başarılı olursa, doğrulanmış işlem verileri yığında tutulur ve işlemin girdileri, çıktıları, hedef adresi veya Bitcoin miktarı gibi çeşitli bölümlerini çıkarma ve "inceleme" yeteneği ile işlemin iç gözlemi sağlanır. dahil olmuş.
Belirli şifreleme ilkeleri için lütfen Andrew Poelstra tarafından yayınlanan CAT ve Schnorr Tricks makalesine bakın.
Özetle, OP_CAT'in esnekliği neredeyse tüm sözleşme işlem kodlarını taklit etmesine olanak tanır ve çok sayıda sözleşme işlem kodu OP_CAT'in işlevselliğine dayanır, bu da onu birleştirme listesinde önemli ölçüde öne geçirir. Teorik olarak, yalnızca OP_CAT ve mevcut Bitcoin işlem kodlarına dayanarak, güveni en aza indirilmiş bir BTC ZK Toplama oluşturmayı umabiliriz ve Starknet, Chakra ve diğer ekolojik ortaklar bunu aktif olarak desteklemektedir.
Çözüm
Bitcoin'i ölçeklendirmek ve programlanabilirliğini artırmak için birden fazla strateji araştırdıkça, ileriye giden yolun yerel iyileştirmeler, zincir dışı hesaplama ve gelişmiş komut dosyası oluşturma yeteneklerinin bir kombinasyonunu içerdiği açıktır.
Esnek bir temel katman olmadan daha esnek bir ikinci katman oluşturamazsınız.
Gelecek zincir dışı hesaplamanın genişlemesidir, ancak genişlemeyi daha iyi desteklemek ve gerçek dünya para birimi haline gelmek için Bitcoin'in programlanabilirliğinde bir atılım olması gerekiyor.
Bununla birlikte, Bitcoin ve Ethereum'un hesaplamaları aslında temelde farklıdır. Bitcoin, bir hesaplama biçimi olarak yalnızca "doğrulamayı" destekler ve genel hesaplamaları gerçekleştiremez; Ethereum ise doğası gereği hesaplamaya dayalıdır ve doğrulama, hesaplamanın bir yan ürünüdür. Bu fark bir noktadan anlaşılıyor: Ethereum, başarısız işlemler için Gas şeklinde bir ücret alırken, Bitcoin bunu yapmıyor.
Sözleşme, hesaplama yerine doğrulamaya dayalı bir akıllı sözleşme biçimi uygular. Sözleşmelere gelince, bir avuç Satoshi köktencisi dışında herkes sözleşmelerin Bitcoin'i geliştirmek için iyi bir seçenek olduğunu düşünüyor gibi görünüyor. Ancak topluluk, sözleşmenin uygulanması için hangi yöntemin kullanılması gerektiği konusunda tartışmayı sürdürüyor.
APO, OP_VAULT ve TLUV, doğrudan uygulamalara karşı daha önyargılıdır ve bunların seçilmesi, belirli uygulamaların daha ucuz ve daha verimli bir şekilde uygulanmasını sağlayabilir. Lightning Network meraklıları, LN-Simetriyi uygulayabildiği için APO'yu tercih edecektir; bir kasa uygulamak istiyorsanız, CoinPool'u oluşturmak için OP_VAULT'u kullanmak en iyisidir; daha fazla gizlilik ve verimlilik için TLUV'yi kullanın. OP_CAT ve TXHASH daha çok yönlüdür ve güvenlik açıklarına sahip olma olasılıkları daha düşüktür. Diğer işlem kodlarıyla birleştirilerek daha fazla kullanım durumu elde edilebilir, ancak elbette betiğin karmaşıklığı için ödeme yapmaları gerekebilir. CTV ve CSFS, blockchain işleme sürecinde ayarlamalar yaptı ve CTV gecikmeli çıktıyı, CSFS ise gecikmeli imzaları uyguladı. MATT, iyimser yürütme ve dolandırıcılık kanıtı fikirlerini kullanan ve evrensel akıllı sözleşmeleri uygulamak için Merkle Trie'nin yapısını kullanan nispeten benzersizdir, ancak yine de iç gözlem işlevlerini getirmek için yeni işlem kodlarına ihtiyacı vardır.
Bitcoin topluluğunun, Bitcoin'in soft fork yoluyla sözleşme almasına izin verme olasılığını zaten yoğun bir şekilde tartıştığını gördük. Starknet, Bitcoin ekosistemine girdiğini resmi olarak duyurdu ve OP_CAT birleşmesinden sonraki altı ay içinde Bitcoin ağında uzlaşmayı uygulamayı planlıyor. Chakra, Bitcoin ekosistemindeki en son trendlere dikkat etmeye, OP_CAT yumuşak çatallarının birleşmesini teşvik etmeye ve daha güvenli ve verimli bir Bitcoin ödeme katmanı oluşturmak için iç gözlem ve sözleşmelerin getirdiği programlanabilirliği kullanmaya devam edecek.
Bu makaleyle ilgili incelemeleri ve önerileri için Jeffrey, Ben, Mutourend ve Lynndell'e teşekkürler
