Bitcoin’in 2. Katman Ağının Kutsal Kasesi: Teftiş ve Sözleşmeler

Ethereum gibi Turing-komple blok zincirleriyle kıyaslandığında, Bitcoin’in komut dosyası dilinin önemli ölçüde sınırlı olduğu, yalnızca temel işlemleri yapabildiği ve hatta çarpma ve bölme işlevlerinden yoksun olduğu düşünülmektedir. Daha da önemlisi, blok zincirinin kendi verilerine komut dosyaları için neredeyse erişilemez, bu da esneklik ve programlanabilirlikte ciddi sınırlamalara yol açar. Sonuç olarak, insanlar uzun süredir Bitcoin komut dosyaları için iç gözlemi etkinleştirmenin yollarını aramaktadır.

İç Gözlem Bitcoin komut dosyalarının işlem verilerini inceleme ve kısıtlama yeteneğini ifade eder. Bu, komut dosyalarının belirli işlem ayrıntılarına dayalı olarak fon kullanımını kontrol etmesine olanak tanıyarak daha karmaşık işlevler sağlar. Şu anda, çoğu Bitcoin işlem kodu ya kullanıcı tarafından sağlanan verileri yığına itmekte ya da zaten yığında bulunan verileri manipüle etmektedir. Ancak introspection opcode’ları mevcut işlem verilerini (zaman damgaları, tutarlar ve işlem kimlikleri gibi) yığına aktarabilir ve UTXO harcamaları üzerinde daha ayrıntılı kontrol sağlayabilir.

Şu anda Bitcoin komut dosyalarında iç gözlemi destekleyen yalnızca üç ana işlem kodu bulunmaktadır: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY ve CHECKSIG. CHECKSIG’in CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG ve CHECKMULTISIGVERIFY dahil olmak üzere çeşitli varyantları vardır.

Sözleşmeler tokenlerin nasıl transfer edilebileceğine ilişkin kısıtlamalardır. Kullanıcılar UTXO’ların sözleşmeler aracılığıyla nasıl dağıtılacağını belirleyebilir ve bunların çoğu iç gözlem opcode’ları kullanılarak uygulanır. Şu anda Bitcoin Optech, iç gözlemi sözleşme girişleri altında kategorize etmektedir.

Bitcoin şu anda iki sözleşmeye sahiptir: CSV (CheckSequenceVerify) ve CLTV (CheckLockTimeVerify), her ikisi de zamana dayalı sözleşmelerdir ve Lightning Network gibi birçok ölçeklendirme çözümünün temelini oluşturur. Bu da Bitcoin’in ölçeklendirme çözümlerinin büyük ölçüde iç gözlem ve sözleşmelere dayandığını göstermektedir.

Token Transferlerine Nasıl Koşul Eklenir

Kripto dünyasında en yaygın yöntem, genellikle hash’ler kullanılarak uygulanan taahhütler yöntemidir. Transfer koşullarının karşılandığını kanıtlamak için doğrulama amacıyla imza mekanizmaları kullanılır. Bu nedenle, sözleşmeler hash ve imzalarda çok sayıda ayarlama içerir.

Aşağıdakiler yaygın olarak tartışılan antlaşma işlem kodu önerileridir:

CTV (CheckTemplateVerify) BIP-119

BIP-119‘da yer alan CTV (CheckTemplateVerify), çok tartışılan bir Bitcoin yükseltmesidir. CTV, çıktı komut dosyalarının nVersion, nLockTime, scriptSig hash, girdi sayısı, diziler hash, çıktı sayısı, çıktılar hash ve girdi dizini gibi alanlar dahil olmak üzere harcama işlemleri için şablonlar belirlemesine olanak tanır. Bu şablon kısıtlamaları bir hash taahhüdü aracılığıyla uygulanır ve gelecekteki harcama komut dosyaları, harcama işlemindeki belirtilen alanların hash değerlerinin girdi komut dosyasındakilerle eşleşip eşleşmediğini kontrol eder. Bu şablonlar esasen gelecekteki UTXO işlemlerinin zamanını, yöntemini ve miktarını tanımlar.

Özellikle, giriş TXID’si hash taahhüdünden hariç tutulur. Bu dışlama gereklidir çünkü ister Legacy ister Segwit işlemlerinde olsun, varsayılan SIGHASH_ALL imza türü kullanılırken TXID, scriptPubKey değerine bağlıdır. TXID’nin dahil edilmesi döngüsel bir bağımlılık yaratarak hash taahhüdünün oluşturulmasını imkansız hale getirir.

CTV, yeni bir işlem kodu aracılığıyla belirtilen işlem bilgilerini doğrudan elde ederek, bunları hash ederek ve yığındaki taahhütle karşılaştırarak iç gözlemi gerçekleştirir. Bu yöntem daha az zincir içi alan tüketir ancak bazı esnekliklerden yoksundur.

Lightning Network gibi ikinci katman çözümlerinin temeli önceden imzalanmış işlemlerdir. Ön imzalama genellikle işlemlerin önceden üretilmesi ve imzalanması ancak belirli koşullar yerine getirilene kadar yayınlanmaması anlamına gelir. Esasen, CTV daha katı bir ön-imzalama işlevi uygulayarak, önceden imzalanmış taahhüdü doğrudan zincir üzerinde yayınlar ve yalnızca önceden tanımlanmış şablona göre işlemlere izin verir.

CTV başlangıçta Bitcoin tıkanıklığını hafifletmek için önerilmiştir ve tıkanıklık kontrolü olarak da adlandırılabilir. Yüksek tıkanıklık dönemlerinde, CTV tek bir işlem aracılığıyla gelecekteki birden fazla işlemi taahhüt edebilir, tıkanıklık sırasında birden fazla işlem yayınlama ihtiyacını ortadan kaldırır ve tıkanıklık hafifledikten sonra gerçek işlemleri tamamlar. Bu, değişim çalışmaları sırasında önemli ölçüde yardımcı olabilir. Ek olarak, şablonlar kasaları uygulamak için kullanılabilir ve fonların varış yeri önceden belirlendiği için bilgisayar korsanlarının saldırılarını önleyerek bilgisayar korsanlarının CTV komut dosyasını kullanarak UTXO’ları adreslerine göndermelerini imkansız hale getirir.

CTV, ikinci katman ağlarını önemli ölçüde geliştirebilir. Örneğin, Lightning Network’te Zaman Aşımı Ağaçları ve Kanal Fabrikalarının CTV kullanılarak uygulanması, tek bir UTXO’nun bir CTV ağacına genişlemesine ve yalnızca bir zincir içi işlem ve onay ile birden fazla durum kanalı açmasına olanak tanır. Ayrıca CTV, Ark protokolünde atomik işlemleri (ATLC) destekler.

APO (SIGHASH_ANYPREVOUT) BIP-118

BIP-118, daha esnek harcama mantığı yazmayı kolaylaştırmak için tapscript için SIGHASH_ANYPREVOUT adlı yeni bir imza hash bayrağı önermektedir. APO ve CTV birçok yönden benzerdir. APO’nun çözümü, scriptPubKeys ve TXID’ler arasındaki döngüsel bağımlılığı ele almak için ilgili girdi bilgilerini hariç tutmak ve yalnızca çıktıyı imzalayarak işlemlerin dinamik olarak farklı UTXO’lara bağlanmasına izin vermektir.

Mantıksal olarak, OP_CHECKSIG doğrulama işleminin (ve ilgili işlem kodlarının) üç işlevi vardır:

1. Harcama işleminin parçalarını bir araya getirin.
2. Bu parçaları temizle.
3. Hash’in verilen anahtar tarafından imzalanıp imzalanmadığını doğrular.

İmzanın spesifik içeriği önemli ölçüde ayarlanabilir ve hangi işlem alanlarının imzalanacağı SIGHASH bayrağı tarafından belirlenir. BIP 342 imza işlem kodlarının tanımına göre, SIGHASH bayrakları arasında SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE ve SIGHASH_ANYONECANPAY yer alır. SIGHASH_ANYONECANPAY girişi kontrol ederken, diğerleri çıkışı kontrol eder.

SIGHASH_ALL varsayılan SIGHASH bayrağıdır ve tüm çıktıları imzalar. SIGHASH_NONE hiçbir çıktıyı imzalamaz ve SIGHASH_SINGLE yalnızca belirtilen bir çıktıyı imzalar. SIGHASH_ANYONECANPAY diğer üç bayrakla birlikte ayarlanabilir ve ayarlanırsa, yalnızca belirtilen girdiyi imzalar; aksi takdirde, tüm girdiler imzalanmalıdır.

Bu SIGHASH bayraklarının hiçbiri girdilerin etkisini ortadan kaldıramaz. SIGHASH_ANYONECANPAY bile bir girdiye bağlılık gerektirir.

Bu nedenle, BIP 118 SIGHASH_ANYPREVOUT özelliğini getirmektedir. APO imzalarının harcanan giriş UTXO’sunu (PREVOUT olarak adlandırılır) taahhüt etmesi gerekmez, yalnızca çıktıyı imzalayarak Bitcoin kontrolünde daha yüksek esneklik sağlar. İşlemleri önceden oluşturarak ve karşılık gelen tek kullanımlık imzalar ve açık anahtarlar oluşturarak, bu açık anahtar adresine gönderilen varlıklar önceden oluşturulmuş işlem aracılığıyla harcanmalı ve sözleşmeye ulaşılmalıdır.

APO’nun esnekliği işlem onarımı için de kullanılabilir. Bir işlem düşük ücretler nedeniyle zincirde takılırsa, yeni imzalara gerek kalmadan ücreti artırmak için kolayca başka bir işlem oluşturulabilir. Ayrıca, çoklu imza cüzdanları için, harcanan girdiye bağlı olmayan imzalar işlemleri daha basit hale getirir.

APO, scriptPubKeys ve girdi TXID’leri arasındaki döngüsel bağımlılığı ortadan kaldırarak, tanığa çıktı verileri ekleyerek iç gözlem elde edebilir, ancak bu yine de ek tanık veri alanı gerektirir.

Lightning Network ve kasalar gibi zincir dışı protokoller için APO, ara durum depolama ihtiyacını azaltarak depolama gereksinimlerini ve karmaşıklığı önemli ölçüde düşürür. APO’nun en doğrudan kullanım alanı, kanal fabrikalarını basitleştiren, hafif ve ucuz gözetleme kuleleri inşa eden ve hatalı durumlar bırakmadan tek taraflı çıkışlara izin vererek Lightning Network’ün performansını artıran Eltoo’dur. APO, CTV’nin işlevselliğini simüle edebilir, ancak imzaların ve önceden imzalanmış işlemlerin kişisel olarak depolanmasını gerektirir, bu da onu CTV’den daha maliyetli ve daha az verimli hale getirir.

APO’nun ana eleştirisi, yeni bir anahtar sürümüne ihtiyaç duyulması ve bunun mevcut sistemlerle uyumsuz hale gelmesidir. Buna ek olarak, yeni imza hash türü potansiyel çift harcama riskleri doğurabilir. Kapsamlı topluluk tartışmalarının ardından, APO artık orijinal imzaya ek olarak sıradan bir imza gerektiriyor, güvenlik endişelerini hafifletiyor ve BIP-118 numarasını kazanıyor.

OP_VAULT BIP-345

BIP-345, CTV ile çalışmak ve belirtilen jetonların harcanmasında bir gecikme süresi uygulayan özel bir sözleşme uygulamak için OP_VAULT ve OP_VAULT_RECOVER olmak üzere iki yeni işlem kodu önermektedir; bu süre zarfında harcama bir kurtarma yolu aracılığıyla “iptal edilebilir”.

Kullanıcılar, MAST’a en az iki komut dosyası ekleyerek belirli bir Taproot adresi kurarak bir kasa oluşturabilir: beklenen para çekme işlemini kolaylaştırmak için bir OP_VAULT komut dosyası ve para çekme tamamlanmadan önce paraların kurtarılmasını sağlamak için bir OP_VAULT_RECOVER komut dosyası.

OP_VAULT kesintili zaman kilitli para çekme işlemlerini nasıl gerçekleştirir?

Basit bir ifadeyle, OP_VAULT işlem kodu, harcanan OP_VAULT kodunu belirtilen bir kodla değiştirir, MAST’taki tek bir yaprak düğümü güncellerken geri kalanını değiştirmez. Bu TLUV’ye benzer ancak dahili anahtar güncellemelerini desteklemez.

Kod güncellemeleri sırasında bir şablon getirilmesi ödeme etkilerini kısıtlayabilir. Zaman kilidi parametresi OP_VAULT tarafından belirtilirken, CTV işlem kodu tarafından getirilen şablon, bu komut dosyası yolu boyunca harcanan çıktılar kümesini kısıtlar.

BIP-345 kasalar için tasarlanmıştır ve kullanıcıların rutin ödemeler için bir harcama gecikmesi yapılandırırken son derece güvenli bir kurtarma yoluna (kağıt cüzdan, dağıtılmış çoklu imza) sahip olmalarını sağlar. Kullanıcının cihazı, kasanın harcamalarını sürekli olarak izler ve yetkisiz bir transfer gerçekleşirse kurtarmaya izin verir.

Kasaların BIP-345 ile uygulanması, özellikle kurtarma işlemleri için ücret konularının dikkate alınmasını gerektirir. Olası çözümler arasında CPFP (Child Pays for Parent), geçici ankrajlar ve SIGHASH_GROUP gibi yeni imza hash bayrakları bulunmaktadır.

TLUV (TapleafUpdateVerify)

TLUV şeması Taproot etrafında inşa edilmiştir ve paylaşılan UTXO’lardan verimli çıkış sorununu çözmeyi amaçlamaktadır. Kılavuz ilke, bir Taproot çıktısı harcandığında, TLUV komut dosyası tarafından açıklanan güncelleme adımlarına göre dahili anahtarı ve MAST’ı kısmen güncellemek için Taproot adresinin iç yapısını ve kriptografik dönüşümleri kullanabilmemiz ve böylece sözleşme işlevselliğini elde edebilmemizdir.

TLUV şemasının fikri, aşağıdaki işlemlerden birini veya daha fazlasını gerçekleştirebilen yeni bir işlem kodu TAPLEAF_UPDATE_VERIFY aracılığıyla mevcut harcama girdisine dayalı olarak yeni bir Taproot adresi oluşturmaktır:

• Dahili genel anahtarı güncelleyin
• Merkle yolunu kırpın
• Şu anda yürütülmekte olan yaprak düğümü kaldırın
• Merkle yolunun sonuna yeni bir yaprak düğüm ekleyin

Özellikle, TLUV üç girdi alır:

1. Dahili açık anahtarın nasıl güncelleneceğine ilişkin bir spesifikasyon
2. Merkle yolu için yeni bir yaprak düğüm
3. Mevcut yaprak düğümün kaldırılıp kaldırılmayacağına ve/veya kaç Merkle yolu yaprak düğümünün kaldırılacağına ilişkin bir belirtim

TLUV işlem kodu güncellenmiş scriptPubKey’i hesaplar ve geçerli girdiye karşılık gelen çıktının bu scriptPubKey’e harcanıp harcanmadığını doğrular.

TLUV’nin ilham kaynağı madeni para havuzlarıdır. Günümüzde, ortak havuzlar önceden imzalanmış işlemler kullanılarak oluşturulabilir, ancak izinsiz çıkışlar elde etmek istiyorsanız, katlanarak artan sayıda imza oluşturmanız gerekir. TLUV, önceden imzalanmış herhangi bir işlem olmadan izinsiz çıkışlara olanak tanır. Örneğin, bir grup ortak Taproot’u kullanarak ortak bir UTXO oluşturur ve fonlarını bir havuzda toplar. Taproot anahtarını kullanarak fonları dahili olarak taşıyabilir veya harici ödemeler yapmak için ortaklaşa imzalayabilirler. Bireyler istedikleri zaman paylaşılan havuzdan çıkarak ödeme yollarını kaldırabilirken, diğerleri kalan üyeler hakkında ek bilgileri ifşa etmeden orijinal yol üzerinden ödemeleri tamamlamaya devam edebilir. Bu yöntem, havuzsuz işlemlere kıyasla daha verimli ve gizlidir.

TLUV işlem kodu, orijinal MAST’ı güncelleyerek kısmi harcama kısıtlamaları sağlar. Ancak, çıktı miktarlarının iç gözlemini sağlamaz. Bu nedenle, yığına iki veri parçası iten yeni bir IN_OUT_AMOUNT işlem koduna ihtiyaç vardır: bu girdinin UTXO miktarı ve karşılık gelen çıktı miktarı. TLUV kullanan kişinin daha sonra fonların güncellenmiş scriptPubKey’de düzgün bir şekilde korunup korunmadığını doğrulamak için matematiksel operatörleri kullanması beklenir.

Bitcoin tutarları satoshi cinsinden temsil edildiğinden ve 51 bite kadar gerektirdiğinden, ancak komut dosyaları yalnızca 32 bit matematiksel işlemlere izin verdiğinden, çıktı tutarlarının incelenmesi başka bir karmaşıklık ekler. Bu, işlem kodu davranışını yeniden tanımlayarak veya IN_OUT_AMOUNT yerine SIGHASH_GROUP kullanarak koddaki operatörleri yükseltmeyi gerektirir.

TLUV’nin merkezi olmayan Katman 2 madeni para havuzları için çözümler sunması beklenmektedir, ancak Taproot genel anahtarlarının değiştirilmesi açısından güvenilirliğin daha fazla onaylanması gerekmektedir.

MATT

MATT (Merkleize All The Things) üç hedefe ulaşmayı amaçlamaktadır: Merkleizing state, Merkleizing scripts ve Merkleizing execution, böylece genel akıllı sözleşmeler elde etmek.

• Merkleizing State: Her yaprak düğümün durumun bir karması olduğu ve Merkle Kökünün tüm sözleşme durumunu temsil ettiği bir Merkle Trie oluşturun.
• Merkleizing Komut Dosyaları: Her yaprak düğümünün olası bir durum geçiş yolu olduğu Tapscript’ten oluşturulmuş bir MAST.
• Merkleizing Yürütme: Kriptografik taahhütler ve sahtekarlık meydan okuma mekanizmaları aracılığıyla elde edilir. Herhangi bir hesaplama fonksiyonu için katılımcılar zincir dışı hesaplama yapabilir ve f(x)=y taahhütlerini yayınlayabilir. Diğer katılımcılar f(x)=z sonucunu bulurlarsa, buna itiraz edebilirler ve Optimistic Rollup prensibine benzer şekilde ikili arama yoluyla tahkim gerçekleştirilir.

MATT’a ulaşmak için Bitcoin programlama komut dosyalarının aşağıdaki işlevlere sahip olması gerekir:

1. Bir çıktı (ve miktarları) üzerinde belirli bir komut dosyası uygulayın
2. Bir çıktıya veri ekleme
3. Geçerli girişten (veya diğer girişlerden) veri okuma

Dinamik veriler, harcayıcı tarafından sağlanan giriş verileri aracılığıyla durum hesaplamasına, bir durum makinesini simüle etmeye ve bir sonraki duruma ve bağlı verilere karar vermeye izin verdiği için ikinci nokta çok önemlidir. MATT, daha önce önerilen OP_CHECKOUTPUTCONTRACTVERIFY ve OP_CHECKINPUTCONTRACTVERIFY işlem kodlarının bir kombinasyonu olan OP_CHECKCONTRACTVERIFY (OP_CCV) işlem kodunu, işlemin hedefini belirtmek için ek bir bayrak parametresi ile önermektedir.

Çıktı Miktarlarının Kontrolü: En doğrudan yol doğrudan iç gözlemdir. Ancak çıktı tutarları 64 bitlik sayılardır ve 64 bitlik işlemler gerektirir, bu da Bitcoin komut dosyası uygulamasına karmaşıklık katar. CCV, OP_VAULT’a benzer gecikmeli bir kontrol benimser ve tüm girdiler için girdi tutarlarını, bu çıktı tutarının alt sınırı olarak CCV ile aynı çıktıya toplar. Kontrol, girdi komut dosyası değerlendirmesi yerine işlem sürecine ertelenir.

Sahtekarlık kanıtlarının genelliği göz önüne alındığında, MATT sözleşmelerinin bazı varyantları her tür akıllı sözleşmeye veya Katman 2 yapısına ulaşmalıdır, ancak ek gereksinimlerin (sermaye kilitlenmesi ve meydan okuma süresi gecikmeleri gibi) doğru bir şekilde değerlendirilmesi gerekir. Hangi uygulamaların kabul edilebilir işlemler olduğunu değerlendirmek için daha fazla araştırma yapılması gerekmektedir. Örneğin, OP_ZK_VERIFY işlevlerini simüle etmek için kriptografik taahhütler ve sahtekarlık meydan okuma mekanizmaları kullanarak Bitcoin’de güvenilir olmayan Rollup’lar elde etmek.

Pratikte, işler zaten gerçekleşiyor. Johan Torås Halseth, MATT soft fork önerisindeki OP_CHECKCONTRACTVERIFY opcode’unu kullanarak elftrace’i uyguladı ve RISC-V derlemesi tarafından desteklenen tüm programların Bitcoin zincirinde doğrulanmasına olanak tanıyarak sözleşme protokolleri için yerel Bitcoin doğrulama köprülerini mümkün kıldı.

CSFS (OP_CHECKSIGFROMSTACK)

APO işlem kodunun tanıtımından, OP_CHECKSIG’in (ve ilgili işlemlerin) işlemlerin birleştirilmesinden, hashing’den ve imza doğrulamasından sorumlu olduğunu biliyoruz. Ancak, doğruladığı mesaj, bu işlem kodunu kullanan işlem serileştirmesinden türetilir ve başka mesajların belirtilmesine izin vermez. Basit bir ifadeyle, OP_CHECKSIG (ve ilgili işlemler) bir işlem girdisi olarak UTXO’nun imza sahibi tarafından harcanmaya yetkili olduğunu doğrulamaya hizmet eder ve böylece Bitcoin’in güvenliğini korur.

CSFS, adından da anlaşılacağı gibi, imzaları yığından kontrol eder. CSFS işlem kodu yığından üç parametre alır: bir imza, bir mesaj ve bir açık anahtar ve imzanın geçerliliğini doğrular. Bu, herhangi bir mesajın tanık verileri aracılığıyla yığına aktarılabileceği ve CSFS tarafından doğrulanabileceği anlamına gelir ve Bitcoin’de bazı yeniliklere olanak tanır.

CSFS’nin esnekliği, ödeme imzaları, yetki devri, oracle sözleşmeleri ve çift harcama koruma tahvilleri gibi çeşitli mekanizmaları ve daha da önemlisi işlem iç gözlemini uygulamasına olanak tanır. CSFS kullanarak işlem iç gözleminin prensibi çok basittir. OP_CHECKSIG tarafından kullanılan işlem içeriği tanık aracılığıyla yığına itilirse ve aynı açık anahtar ve imza hem CSFS hem de OP_CHECKSIG ile doğrulamak için kullanılırsa, her ikisi de geçerse, CSFS’ye iletilen herhangi bir mesajın içeriği OP_CHECKSIG tarafından dolaylı olarak kullanılan serileştirilmiş harcama işlemiyle (ve diğer verilerle) aynıdır. Daha sonra yığın üzerinde doğrulanmış işlem verilerini elde ederiz, bu veriler harcama işlemine diğer opcode’larla kısıtlamalar uygulamak için kullanılabilir.

CSFS genellikle OP_CAT ile birlikte görünür çünkü OP_CAT serileştirmeyi tamamlamak için işlemin farklı alanlarını birleştirebilir ve iç gözlem için işlem alanlarının daha hassas bir şekilde seçilmesine olanak tanır. OP_CAT olmadan, komut dosyası ayrı ayrı kontrol edilebilir verilerden hash’leri yeniden hesaplayamaz, bu nedenle yalnızca bir hash’in belirli bir değerle eşleşip eşleşmediğini kontrol edebilir, yani madeni paralar yalnızca tek bir belirli işlem aracılığıyla harcanabilir.

CSFS CLTV, CSV, CTV, APO gibi işlem kodlarına ulaşabilir ve genel bir iç gözlem işlem kodudur, böylece Bitcoin için Katman 2 ölçeklendirme çözümlerine de yardımcı olur. Dezavantajı, imzalı işlemin tam bir kopyasını yığına eklemeyi gerektirmesidir, bu da CSFS’yi iç gözlem için kullanmak isteyen işlemlerin boyutunu önemli ölçüde artırabilir. Buna karşılık, CLTV ve CSV gibi tek amaçlı iç gözlem işlem kodları en az ek yüke sahiptir, ancak her yeni özel iç gözlem işlem kodunun eklenmesi mutabakat değişiklikleri gerektirir.

TXHASH (OP_TXHASH)

OP_TXHASH, operatörün bir alanın hash’ini seçmesini ve yığına itmesini sağlayan çok basit bir iç gözlem işlem kodudur. Özellikle, OP_TXHASH yığından bir txhash bayrağı alır, bayrağa dayalı olarak (bayraklı) bir txhash hesaplar ve elde edilen hash’i yığına iter.

TXHASH ve CTV arasındaki benzerlik nedeniyle, toplulukta bu ikisi hakkında kapsamlı tartışmalar olmuştur.

TXHASH, CTV’ye genel bir yükseltme olarak görülebilir ve kullanıcıların harcama işleminin bölümlerini belirtmelerine olanak tanıyan daha gelişmiş bir işlem şablonu sağlayarak işlem ücretleriyle ilgili birçok sorunu çözer. Diğer sözleşme işlem kodlarının aksine TXHASH, gerekli verilerin bir kopyasının tanık olarak sunulmasını gerektirmez ve depolama ihtiyaçlarını daha da azaltır. CTV’nin aksine, TXHASH NOP uyumlu değildir ve yalnızca tapscript’te uygulanabilir. TXHASH ve CSFS kombinasyonu, CTV ve APO’ya bir alternatif olarak düşünülebilir.

Sözleşmelerin oluşturulması açısından TXHASH, sabitlemek istediğiniz işlem verilerinin tüm parçalarını yığına iterek, bunları bir araya getirerek ve sonucun sabit bir değerle eşleşip eşleşmediğini doğrulayarak “eklemeli sözleşmeler” elde etmek daha kolaydır. CTV, işlem verilerinin serbest kalmasını istediğiniz tüm bölümlerini yığına iterek “eksiltici sözleşmeler” elde etmeyi kolaylaştırır. Ardından, yuvarlanan OP_SHA256 kullanarak, sabit bir ara durumdan başlayarak, bu ara durum işlem hash veri önekini işler. Serbest kalan kısımlar bu ara duruma hashlenir.

TXHASH spesifikasyonunda tanımlanan TxFieldSelector alanının OP_TX gibi diğer opcode’lara genişlemesi beklenmektedir.

TXHASH ile ilgili BIP şu anda Github’da taslak durumundadır ve henüz bir numara atanmamıştır.

OP_CAT

OP_CAT, Satoshi Nakamoto tarafından güvenlik endişeleri nedeniyle kullanımdan kaldırılan biraz gizemli bir işlem kodudur. Bununla birlikte, son zamanlarda Bitcoin çekirdek geliştiricileri arasında kapsamlı tartışmalara yol açmış, hatta çevrimiçi toplulukta bir meme haline gelmiştir. Nihayetinde OP_CAT, BIP-347 olarak onaylandı ve birçok kişi bunu yakın gelecekte geçmesi en muhtemel BIP teklifi olarak nitelendirdi.

Gerçekte OP_CAT’in davranışı çok basittir: yığındaki iki öğeyi birleştirerek tek bir öğe haline getirir. Ancak bu, sözleşme işlevselliğini nasıl sağlar?

İki öğeyi birleştirme işlevi, Merkle Trie olarak bilinen güçlü bir kriptografik veri yapısına karşılık gelir. Bir Merkle Trie’nin oluşturulması yalnızca birleştirme ve hash işlemlerini gerektirir ve bunların her ikisi de Bitcoin betiklerinde mevcuttur. Bu nedenle, OP_CAT ile teorik olarak Bitcoin betiklerinde Merkle Kanıtlarını doğrulayabiliriz, ki bu da blok zincirlerindeki en yaygın hafif doğrulama yöntemidir.

Daha önce de belirtildiği gibi, CSFS genel bir sözleşme şeması elde etmek için OP_CAT’i kullanabilir. Aslında, CSFS olmadan bile, Schnorr imzalarının yapısı OP_CAT’in kendisinin işlem iç gözlemine ulaşmasına izin verir.

Bir Schnorr imzasında, imzalanacak mesaj aşağıdaki alanlardan oluşur:

• Versiyon
• Kilitlenme Zamanı
• Girdi sayısı
• Çıktı sayısı
• Girdilerin listesi (her biri önceki işlem karması, dizin, komut dosyası uzunluğu, komut dosyası, sıra dahil)
• Çıktıların listesi (her biri değer, komut dosyası uzunluğu, komut dosyası dahil)

Bu alanlar bir işlemin ana unsurlarını içerir. Bunları scriptPubKey veya witness içine yerleştirerek ve OP_CAT ve OP_SHA256 kullanarak bir Schnorr imzası oluşturabilir ve OP_CHECKSIG ile doğrulayabiliriz. Doğrulama geçerse, yığın doğrulanmış işlem verilerini saklar ve işlem iç gözlemini mümkün kılar. Bu, işlemin girdileri, çıktıları, hedef adresleri veya ilgili Bitcoin miktarları gibi çeşitli kısımlarını çıkarmamıza ve “incelememize” olanak tanır.

Daha ayrıntılı kriptografik ilkeler için Andrew Poelstra’nın “CAT ve Schnorr Hileleri” makalesine bakınız.

Özetle, OP_CAT’in esnekliği neredeyse tüm sözleşme işlem kodlarını taklit edebilmesini sağlar ve birçok sözleşme işlem kodu onun işlevselliğine bağlıdır. Bu da birleştirme listesindeki konumunu önemli ölçüde ilerletmektedir. Teorik olarak, yalnızca OP_CAT ve mevcut Bitcoin işlem kodlarıyla, güven minimize edilmiş bir BTC ZK Rollup oluşturabiliriz. Starknet, Chakra ve diğer ekosistem ortakları bunun gerçekleşmesi için aktif olarak çalışmaktadır.

Sonuç

Bitcoin’i genişletmek ve programlanabilirliğini artırmak için çeşitli stratejiler keşfettikçe, ileriye giden yolun yerel iyileştirmeler, zincir dışı hesaplama ve karmaşık komut dosyası işlevlerinin bir kombinasyonunu içerdiği ortaya çıkıyor.

Esnek bir temel katman olmadan, daha esnek bir ikinci katman oluşturmak mümkün değildir.

Zincir dışı hesaplama ölçeklenebilirliği gelecek, ancak Bitcoin’in programlanabilirliği, ölçeklendirmeyi daha iyi desteklemek ve gerçek bir dünya para birimi olmak için kırılmalıdır.

Ancak Bitcoin hesaplaması Ethereum hesaplamasından temelde farklıdır. Bitcoin bir hesaplama biçimi olarak yalnızca “doğrulamayı” desteklerken, Ethereum temelde hesaplamaya dayalıdır ve doğrulama bir yan üründür. Bu fark, Ethereum’un başarısız işlemler için gaz ücreti alması, Bitcoin’in ise almaması gerçeğinde açıkça görülmektedir.

Sözleşmeler, hesaplamadan ziyade doğrulamaya dayalı bir akıllı sözleşme biçimine ulaşır. Sözleşmelerle ilgili olarak, birkaç katı Satoshi köktencisi dışında, çoğu insan sözleşmelerin Bitcoin’i geliştirmek için iyi bir seçim olduğuna inanmaktadır. Ancak, topluluk sürekli olarak sözleşmeleri uygulamak için hangi şemanın kullanılacağını tartışmaktadır.

APO, OP_VAULT ve TLUV doğrudan uygulamalara yönelir. Bunları seçmek, belirli uygulamaları daha ucuz ve verimli bir şekilde uygulayabilir. Lightning Network meraklıları APO’yu tercih eder çünkü LN-Simetrisi sağlar; bir kasa oluşturmak istiyorsanız OP_VAULT kullanmak en iyisidir; bir CoinPool oluşturmak için TLUV daha özel ve verimlidir. OP_CAT ve TXHASH daha geneldir, daha az güvenlik açığı vardır ve potansiyel olarak komut dosyası karmaşıklığı pahasına da olsa diğer işlem kodlarıyla kombinasyonlar yoluyla daha fazla kullanım durumu elde edebilir. CTV ve CSFS blok zinciri işleme yaklaşımını ayarlamıştır: CTV gecikmeli çıktılar uygularken CSFS gecikmeli imzalar uygular. MATT, iyimser yürütme ve sahtekarlık kanıtlarını kullanarak nispeten benzersizdir ve genel akıllı sözleşmeler elde etmek için Merkle Trie yapısına dayanır, ancak yine de iç gözlem yetenekleri sağlamak için yeni işlem kodları gerektirir.

Bitcoin topluluğunun, yumuşak bir çatallanma yoluyla sözleşmeleri uygulamaya koyma olasılığını şimdiden yoğun bir şekilde tartıştığını görüyoruz. Starknet, OP_CAT birleşmesinden sonraki altı ay içinde Bitcoin ağında mutabakat uygulamayı planlayarak Bitcoin ekosistemine girişini resmen duyurdu. Chakra, Bitcoin ekosistemindeki son gelişmeleri izlemeye, OP_CAT soft fork birleşmesini desteklemeye ve daha güvenli ve verimli bir Bitcoin yerleşim katmanı oluşturmak için iç gözlem ve sözleşmelerin getirdiği programlanabilirliği kullanmaya devam edecektir.