genel bakış

Ethereum gibi Turing tamamlanmış blok zincirlerine kıyasla, Bitcoin yazılımı oldukça kısıtlayıcı olarak kabul edilir, sadece temel işlemleri gerçekleştirebilir ve hatta çarpma ve bölme işlemlerini desteklemez. Daha da önemlisi, blok zincirinin kendi verileri neredeyse betimlemelere erişilemez durumda olup, bu durum esneklik ve programlanabilirlik açısından önemli bir eksikliğe neden olur. Bu nedenle, Bitcoin yazılımlarının betimlemeyi gerçekleştirmesi için uzun süredir çaba harcanmaktadır.

Öz gözlem, bitcoin betiklerinin işlem verilerini denetlemesine ve kısıtlamasına olanak tanıyan yeteneğe atıfta bulunur. Bu, betiklerin belirli işlem ayrıntılarına dayalı olarak fon kullanımını kontrol etmesine ve daha karmaşık işlevsellikler sağlamasına olanak tanır. Şu anda, çoğu bitcoin opcode'u, kullanıcı tarafından sağlanan verileri yığına itmek veya mevcut verileri yığından manipüle etmektedir. Ancak, öz gözlem opcode'ları, mevcut işlemden (zaman damgaları, miktarlar, txid vb.) veri itebilir, bu da utxo harcamaları üzerinde daha ayrıntılı kontrol sağlar.

şu anda, bitcoin scriptleme içinde sadece üç temel opcode, yani checklocktimeverify, checksequenceverify ve checksig, bunun yanı sıra varyantları checksigverify, checksigadd, checkmultisig ve checkmultisigverify, destekleme işlevine sahiptir.

ahit, basitçe ifade etmek gerekirse, paraların nasıl transfer edileceğine dair kısıtlamaları ifade eder ve kullanıcılara utxoların nasıl dağıtılacağını belirtme imkanı tanır. birçok ahit, içgörü işletim kodları aracılığıyla uygulanır ve içgörüyle ilgili tartışmalar artık ahit konusu altında kategorize edilmiştir.Bitcoin optech.

bitcoin şu anda iki antlaşma olan csv (checksequenceverify) ve cltv (checklocktimeverify) ile, her ikisi de zaman tabanlı antlaşmalar olup, şimşek ağı gibi birçok ölçeklendirme çözümü için temel oluşturur. Bu, bitcoin'in ölçeklendirme çözümlerinin büyük ölçüde iç gözlem ve antlaşmalara dayandığını göstermektedir.

Paraların transferine nasıl koşullar ekleriz? Kripto alanında, en yaygın yöntemimiz sık ​​sık özetler aracılığıyla gerçekleştirilen taahhütlerle olur. Transfer gereksinimlerinin karşılandığını kanıtlamak için doğrulama için imza mekanizmaları da gereklidir. Bu nedenle, sözleşmeler içinde birçok özet ve imza ayarlaması bulunur.

Aşağıda, yaygın olarak tartışılan antlaşma opcode önerisini açıklayacağız.

ctv (checktemplateverify) bip-119

ctv (checktemplateverify), bip-119'da bulunan ve önemli topluluk dikkatini çeken bir bitcoin güncelleme önerisidir. ctv, işlemdeki fonları harcamak için bir şablon belirtmesine izin veren bir çıktı betiğini etkinleştirir. nversion, nlocktime, scriptsig hash, giriş sayısı, sequences hash, çıkış sayısı, çıkışlar hash, giriş indeksi gibi alanları içerir. Bu şablon kısıtlamaları bir hash taahhüdü aracılığıyla uygulanır ve fonlar harcandığında, betik belirtilen alanların hash değerlerinin harcama işlemindeki hash değerleriyle eşleşip eşleşmediğini kontrol eder. Bu, bu utxo'nun gelecekteki işlemlerinin zamanını, yöntemini ve miktarını etkili bir şekilde sınırlar.

Özellikle, giriş txid bu hash'ten hariç tutulur. Bu hariç tutma, eski ve segwit işlemlerinde txid'nin, varsayılan sighash_all imzalama türünü kullanırken scriptpubkey'deki değerlere bağlı olmasından dolayı gereklidir. Txid'nin dahil edilmesi, hash taahhüdünde döngüsel bir bağımlılığa yol açarak yapının oluşturulmasını imkansız hale getirir.

ctv, belirli işlem bilgilerini doğrudan çekerek iç gözlemi uygular ve bunu yığın üzerindeki taahhüt ile karşılaştırır. Bu iç gözlem yöntemi, zincir alanı üzerinde daha az talepkar olmasına rağmen bazı esneklik eksikliği gösterir.

Bitcoin'in lightning ağı gibi ikinci katman çözümlerinin temeli, önceden imzalanmış işlemlere dayanır. Ön imzalama genellikle işlemleri önceden oluşturup imzalamayı ve belirli koşullar karşılandığında yayınlamayı ifade eder. Temelde, ctv daha katı bir ön imzalama şeklini uygular, ön imzalamanın taahhüdünü zincirde yayınlamayı, önceden belirlenmiş şablona kısıtlı tutar.

ctv başlangıçta bitcoin'deki sıkışıklığı hafifletmek için önerildi ve ayrıca sıkışıklık kontrolü olarak da adlandırılabilir. Yüksek sıkışıklık zamanlarında ctv, tek bir işlem içinde birden fazla gelecekteki işlemi taahhüt edebilir, zirve zamanlarında birden fazla işlem yayınlama ihtiyacını ortadan kaldırarak ve sıkışıklık hafiflediğinde gerçek işlemleri tamamlayarak. Bu özellikle borsa banka koşuları sırasında yardımcı olabilir. Ayrıca, şablon ayrıca hacking saldırılarına karşı koruma amacıyla kasanın uygulanması için de kullanılabilir. Fonların yönü önceden belirlendiği için, hackerlar ctv komut dosyalarını kullanarak utxoları kendi adreslerine yönlendiremezler.

ctv, katman-iki ağları önemli ölçüde geliştirebilir. Örneğin, lightning ağındaki ctv, tek bir utxo'yu bir ctv ağacına genişleterek zaman ağaçları ve kanal fabrikalarının oluşturulmasını sağlayabilir, yalnızca bir işlem ve bir onay ile birden çok durum kanalını açabilir. Ayrıca, ctv ayrıca atlc aracılığıyla ark protokolünde atomic işlemleri de destekler.

apo (sighash_anyprevout) bip-118

bip-118, tapscript için daha esnek harcama mantığı olan sighash_anyprevout olarak bilinen yeni bir imza hash bayrağı türü tanıtıyor. apo ve ctv birçok benzerliği paylaşıyor. scriptpubkey'ler ve txid'ler arasındaki döngüsel sorunu ele alırken, apo'nun yaklaşımı ilgili giriş bilgilerini hariç tutmak ve yalnızca çıktıları imzalamaktır, bu da işlemlerin dinamik olarak farklı utxo'lara bağlanmasına olanak tanır.

mantıksal olarak, imza doğrulama işlemi op_checksig (ve türevleri) üç işlevi gerçekleştirir:

1. harcama işlemi parçalarını birleştirme.
2. onları karmak.
3. verinin belirli bir anahtar tarafından imzalandığını doğrulama.

imza ayrıntıları, imza hash bayrağı tarafından imzalanacak işlem alanlarının hangisine karar verilirse esneklik sağlar. bip 342'deki imza opkodlarının tanımına göre, imza hash bayrakları sighash_all, sighash_none, sighash_single ve sighash_anyonecanpay olarak bölünür. sighash_anyonecanpay girişleri kontrol ederken, diğerleri çıktıları kontrol eder.

sighash_all, tüm çıktıları imzalayan varsayılan imza bayrağıdır; sighash_none hiçbir çıktıyı imzalamaz; sighash_single belirli bir çıktıyı imzalar. İlk üç imza bayrağıyla sighash_anyonecanpay ayarlanabilir. sighash_anyonecanpay ayarlanmışsa, yalnızca belirtilen giriş imzalanır; aksi takdirde, tüm girişler imzalanmalıdır.

Açıkça, bu sighash bayrakları girişlerin etkisini ortadan kaldırmaz, hatta tek bir girişe bağlı kalan sighash_anyonecanpay bile.

böylece, bip 118, sighash_anyprevout önerir. apo imzası, harcanan giriş utxo'ya (prevout olarak bilinir) taahhüt etmek zorunda değildir, sadece çıktıları imzalamak için gereklidir, bu da bitcoin kontrolünde daha fazla esneklik sağlar. işlemleri önceden oluşturarak ve buna karşılık gelen tek kullanımlık imzalar ve açık anahtarlar oluşturarak, o açık anahtar adresine gönderilen varlıklar önceden oluşturulan işlem aracılığıyla harcanmak zorundadır, böylece bir antlaşma uygulanır. apo'nun esnekliği ayrıca işlem onarımı için de kullanılabilir; bir işlem düşük ücretler nedeniyle zincire takılı kaldığında, yeni bir imza gerektirmeden ücreti artırmak için kolayca yeni bir işlem oluşturulabilir. Dahası, çok imzalı cüzdanlar için, harcanan girişlere bağlı olmamak işlemleri daha kullanışlı hale getirir.

çünkü scriptpubkeys ve giriş txid'leri arasındaki döngüyü ortadan kaldırır, apo, şahit içine çıkış verilerini ekleyerek keşif yapabilir, ancak bu hala ek şahit alan tüketimi gerektirir.

Işlem dışı protokoller için, örneğin yıldırım ağı ve kasalar için, apo ara durumları kaydetme ihtiyacını azaltarak depolama gereksinimlerini ve karmaşıklığı büyük ölçüde azaltır. Apo'nun en doğrudan kullanım durumu eltoo'dur, bu da kanal fabrikalarını basitleştirir, hafif ve ucuz izleme kuleleri oluşturur ve yanlış durumlar bırakmadan tek taraflı çıkışlara izin verir, yıldırım ağının performansını birçok yönden arttırır. Ayrıca, ctv işlevlerini simüle etmek için de apo kullanılabilir, ancak bireylerin imzaları ve önceden imzalanmış işlemleri saklamaları gerektiğinden, ctv'den daha maliyetli ve daha az verimlidir.

apo'nun başlıca eleştirisi, yeni bir anahtar versiyonuna ihtiyaç duymasıdır, bu sadece geriye dönük uyumlu olmakla uygulanamaz. Ayrıca, yeni imza hash türü çift harcama potansiyel risklerini ortaya çıkarabilir. Kapsamlı topluluk tartışmalarının ardından, apo, güvenlik endişelerini hafifletmek için orijinal imzalama mekanizmasının üzerine düzenli imzalar ekledi ve böylece bip-118 kodunu kazandı.

op_vault bip-345

bip-345, op_vault ve op_vault_recover adında iki yeni opcode'un eklenmesini öneriyor. Bu, ctv ile birleştirildiğinde, belirli paraların harcanmasında gecikme uygulamak için özelleştirilmiş bir antlaşma uygulayan bir covenant'ı uygular. Bu gecikme süresince, önceden yapılmış bir işlem kurtarma yoluyla 'geri alınabilir'.

Kullanıcılar, beklenen çekim sürecini kolaylaştırmak için op_vault opcode'a sahip bir betik ve çekim tamamlanmadan önce herhangi bir zamanda coinlerin kurtarılmasını sağlamak için op_vault_recover opcode'a sahip en az iki betik içermesi gereken özel bir taproot adresi oluşturarak bir kasayı oluşturabilirler.

op_vault, kesintiye uğrayabilir zaman kilitli çekilmeleri nasıl gerçekleştiriyor? op_vault bunu harcanmış op_vault betiği belirli bir betikle değiştirerek başarıyor, bu da tluv'a benzer bir tasarım olmasına rağmen op_vault'un iç anahtarlarına güncelleme desteği sunmaması dışında tek yapraklı ağaç yapraklarının geri kalanını değiştirmeden etkili bir şekilde güncelliyor.

betim güncelleme süreci sırasında bir şablon tanıtılarak ödemeler sınırlandırılabilir. zaman kilidi parametresi op_vault tarafından belirtilir ve ctv opcode'unun şablonu bu betik yolundan harcanabilecek çıktıların setini sınırlar.

bip-345 özellikle kasanlar için tasarlanmış olup, op_vault ve op_vault_recover'ı kullanarak kullanıcılara yüksek güvenlikli bir anahtar (örneğin kağıt cüzdan veya dağıtılmış bir çoklu imza) olarak kurtarma yolu olarak kullanmalarını sağlar, aynı zamanda düzenli ödemeler için belirli bir gecikme ayarlar. Kullanıcı cihazları, kasadan yapılan harcamaları sürekli olarak izler ve beklenmedik bir transfer gerçekleşirse, kullanıcılar kurtarma işlemini başlatabilir.

BIP-345 aracılığıyla kasa uygulamasının uygulanması, özellikle kurtarma işlemleri için maliyet konularının dikkate alınmasını gerektirir. Olası çözümler, cpfp (çocuk öder ebeveyn), geçici çengeller ve yeni sighash_group imza karmaşası bayrakları içerir.

tluv (tapleafupdateverify)

tluv şeması, taproot etrafında inşa edilmiştir ve paylaşılan utxo'lardan çıkma sorununa verimli bir şekilde çözüm sağlamayı amaçlar. Yönlendirici ilke, bir taproot çıktısı harcanırken, kriptografik dönüşümler vasıtasıyla iç anahtar ve mast (tapscript trie) üzerinde kısmi güncellemeler yapılabilir ve tluv betiği tarafından tanımlanan taproot adresinin dahili yapısı aracılığıyla gerçekleştirilebilir. Bu, sözleşme işlevlerinin uygulanmasına olanak tanır.

tluv şemasının kavramı, mevcut harcama girişine dayalı olarak yeni bir taproot adresi oluşturmak için yeni bir opcode olan tapleaf_update_verify tanıtarak elde edilebilir. Bunun gerçekleştirilmesi için aşağıdaki işlemlerden birini veya daha fazlasını gerçekleştirebilirsiniz:

1. içsel genel anahtarı güncelle
2. merkle yolunu kısalt
3. şu anda yürütülen betiği kaldırın
4. merkle yolunun sonuna yeni bir adım ekleyin

Özellikle, tluv üç girdi kabul eder:

1. Dahili genel anahtarın nasıl güncelleneceğini belirleyen bir tane.
2. merkle yoluna yeni bir adım belirleyen.
3. şu anki betiği kaldırıp kaldırmama ve/veya merkle yolunun kaç adımının kırpılacağını belirleyen bir adet

tluv opcode, güncellenmiş scriptpubkey'i hesaplar ve mevcut girişe karşılık gelen çıktının bu scriptpubkey'e harcandığını doğrular.

tluv, coinpool kavramından ilham almaktadır. Bugün, ortak havuzlar yalnızca önceden imzalanmış işlemler kullanılarak oluşturulabilir, ancak izinsiz çıkışların gerçekleştirilmesi durumunda, üssel olarak artan sayıda imza oluşturulması gerekecektir. Ancak tluv, herhangi bir önceden imza olmaksızın izinsiz çıkışlara izin verir. Örneğin, bir grup ortak taproot'u kullanarak paylaşılan bir utxo oluşturabilir, fonlarını bir araya toplayabilir. Taproot anahtarını kullanarak içerideki fondan fonları hareket ettirebilir veya ortak olarak ödemeleri başlatmak için imzalayabilirler. Bireyler, ödeme yollarını kaldırarak herhangi bir zamanda paylaşılan fon havuzundan çıkabilirken, diğerleri hala orijinal yollarla ödemeleri tamamlayabilir ve bireyin çıkışı içerideki diğerleri hakkında ek bilgi açığa çıkarmaz. Bu mod, havuzlanmamış işlemlere göre daha verimli ve özel bir şekilde çalışır.

tluv opcode, orijinal taproot trie'yi güncelleyerek kısmi harcama kısıtlamalarını gerçekleştirir, ancak çıktı miktarının iç gözlemesini uygulamaz. Bu nedenle, yeni bir opcode olan in_out_amount da gereklidir. Bu opcode, bu giriş için utxo'nun miktarını ve ilgili çıktı için miktarı yığına iteler, ardından tluv kullananların güncellenmiş scriptpubkey'de fonların uygun şekilde korunduğunu doğrulamak için matematiksel operatörler kullanması beklenir.

Çıkış miktarlarının içgörüsü, satoshilerde miktarların temsil edilmesi için 51 bit kadar gerektirdiğinden karmaşıklık ekler, ancak komut dosyaları yalnızca 32 bitlik matematiksel işlemlere izin verir. Bu, komut dosyalarındaki operatörleri yükseltmek için opcode davranışını yeniden tanımlamayı veya in_out_amount'ı değiştirmek için sighash_group'u kullanmayı gerektirir.

tluv, merkezi olmayan katman 2 finansman havuzları için bir çözüm olarak potansiyel taşır, ancak hala taproot trie'yi ayarlama güvenilirliği doğrulanması gerekmektedir.

matt

matt (her şeyi merkleleştir) üç amaç başarmayı hedefliyor: durumu merkleleştirmek, betiği merkleleştirmek ve yürütme işlemini merkleleştirmek, böylece evrensel akıllı sözleşmeleri mümkün kılmak.

1. devletin merkleleştirilmesi: bu, her yaprak düğümünün bir devletin karmasını temsil ettiği bir merkle ağacı oluşturmayı içerir, merkle kökü ise sözleşmenin genel durumunu temsil eder.
2. script'in merklelaştırılması: bu, her bir yaprak düğümünün bir olası durum geçiş yolunu temsil ettiği tapscript kullanılarak bir mast oluşturulması anlamına gelir.
3. merkleizing yürütme: yürütme, kriptografik taahhütler ve bir hile meydan okuma mekanizması aracılığıyla merkleized edilir. Herhangi bir hesaplama işlevi için katılımcılar, zincir dışında hesaplama yapabilir ve ardından bir taahhüt yayınlayabilir, f(x)=y. Diğer katılımcılar hatalı bir sonuç bulurlarsa, f(x)=z, bir meydan okuma başlatabilirler. Hakemlik, iyimser rollup prensibine benzer şekilde ikili arama ile yapılır.

İnfazı merkleleştirme

matt'i uygulamak için, bitcoin betik dili aşağıdaki işlevlere sahip olmalıdır:

1. belirli bir komut dosyasına sahip bir çıktı zorlamak (ve miktarları)
2. bir veri parçasını bir çıktıya ekleyin
3. Mevcut girdiden (veya başka bir yerden) verileri okuyun

İkinci nokta kritiktir: dinamik veri, harcayan tarafından sağlanan giriş verileri aracılığıyla durumun hesaplanabileceği anlamına gelir, çünkü bu, bir durum makinesinin simülasyonuna olanak tanır, sonraki durumu ve ek verileri belirleyebilen bir durum makinesinin simülasyonuna olanak tanır. matt şeması, bu işlem için op_checkcontractverify (op_ccv) kodunu ve önceki olarak önerilen op_checkoutputcontractverify ve op_checkinputcontractverify kodlarının birleştirilmesini, işlemin hedefini belirtmek için ek bir bayrak parametresini kullanarak uygular.

çıktı miktarları üzerinde kontrol: en basit yöntem doğrudan denetime tabi olmaktır; ancak, çıktı miktarları 64 bit sayıları gerektirdiğinden, 64 bit aritmetiği gerektirir, bu da bitcoin scriptleme sürecinde önemli bir karmaşıklık oluşturur. op_ccv, op_vault gibi ertelenmiş bir kontrol yaklaşımı benimser, burada aynı ccv'ye sahip tüm çıktıların tüm giriş miktarları toplanır ve bu, o çıktının miktarı için bir alt sınır olarak hizmet eder. erteleme, bu kontrolün girişlerin betimlemesi sırasında değil, işlem süreci sırasında gerçekleştiği için yapılır.

Dolandırıcılık kanıtlarının evrenselliği göz önüne alındığında, matt sözleşmesinin belirli varyantları tüm akıllı sözleşme türlerini veya 2. katman yapılarını uygulayabilecek şekilde olmalıdır, ancak sermaye kilitlenmesi ve meydan okuma süresi gecikmeleri gibi ek gerekliliklerin doğru bir şekilde değerlendirilmesi gerekmektedir; işlemler için hangi uygulamaların kabul edilebilir olduğunu değerlendirmek için daha fazla araştırmaya ihtiyaç vardır. Örneğin, op_zk_verify işlevini taklit etmek için kriptografik taahhütler ve dolandırıcılık meydan okuma mekanizmalarını kullanarak, bitcoin üzerinde güvenilir olmayan rollup'lar gerçekleştirme.

uygulamada, şeyler zaten oluyor. johan torås halseth, matt soft fork teklifinden op_checkcontractverify opcode'yi kullanarak uygulamaya geçirmiştir elftraceBu, RISC-V derlemesini destekleyen herhangi bir programın Bitcoin blok zincirinde doğrulanmasına izin vererek, bir sözleşme protokolü içindeki bir tarafın sözleşme doğrulaması yoluyla fonlara erişmesini sağlar ve böylece Bitcoin yerel doğrulaması arasında köprü kurar.

csfs (op_checksigfromstack)

apo opcode'nun tanıtımından, op_checksig'in (ve onunla ilgili işlemlerin) işlemleri birleştirme, karma işlemleri ve imzaları doğrulama işlemlerinden sorumlu olduğunu öğrendik. Bununla birlikte, bu işlemlerle doğrulanan mesaj, opcode kullanarak işlemin serileştirilmesinden türetilir ve başka herhangi bir mesaj belirtmeye izin vermez. Basit bir ifadeyle, op_checksig (ve onunla ilgili işlemler), imza mekanizması aracılığıyla, bir işlem girişi olarak harcanacak olan utxo'nun imza sahibi tarafından harcamaya yetkilendirilip yetkilendirilmediğini doğrulamak için hizmet eder, böylece Bitcoin'in güvenliğini korur.

csfs, adı üstünde olduğu gibi, imzayı yığından kontrol eder. csfs opcode, yığından üç parametre alır: bir imza, bir mesaj ve bir genel anahtar, ve imzanın geçerliliğini doğrular. Bu, insanların şahit aracılığıyla yığına herhangi bir mesajı iletebileceği ve bu mesajı csfs aracılığıyla doğrulayabileceği anlamına gelir, bu da Bitcoin üzerinde bazı yenilikleri mümkün kılar.

csfs'ın esnekliği, ödeme imzaları, yetkilendirme delegasyonu, oracle kontratları, çift harcama koruma bağları ve daha da önemlisi, işlem içgörüsü gibi mekanizmaları uygulamak için izin verir. csfs'nin işlem içgörüsü için kullanma prensibi oldukça basittir: op_checksig tarafından kullanılan işlem içeriği tanık aracılığıyla yığına itilir ve aynı genel anahtar ve imza hem op_csfs hem de op_checksig ile doğrulanırsa ve her iki doğrulama da başarılı bir şekilde geçerse, o zaman op_csfs'ye iletilen keyfi mesaj içeriği, op_checksig tarafından örtük olarak kullanılan serileştirilmiş harcama işlemiyle (ve diğer verilerle) aynıdır. Ardından yığında doğrulanmış işlem verilerini elde ederiz, bu veriler diğer opcode'lerle harcama işlemlerine 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 inceleme için gereken işlem alanlarını daha hassas bir şekilde seçebilir. op_cat olmadan, komut dosyası ayrı ayrı kontrol edilebilen verilerden hash'i yeniden hesaplayamaz, bu yüzden yapabileceği gerçek şey, hash'in belirli bir değere karşılık gelip gelmediğini kontrol etmektir, bu da paraların yalnızca tek bir belirli işlem aracılığıyla harcanabileceği anlamına gelir.

CSFS, CLTV, CSV, CTV, APO vb. gibi işlem kodlarını uygulayabilir ve bu da onu çok yönlü bir iç gözlem işlem kodu haline getirir. Böylece, Bitcoin Layer2 için ölçeklenebilirlik çözümlerine de yardımcı olur. Dezavantajı ise, imzalanan işlemin tam bir kopyasının yığına eklenmesini gerektirmesidir, bu da CSFS kullanılarak iç gözleme yönelik 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ının minimum ek yükü vardır, ancak her yeni özel iç gözlem işlem kodunun eklenmesi fikir birliği değişiklikleri gerektirir.

txhash (op_txhash)

op_txhash, operatörün belirli bir alanın hash'ini seçmesine ve yığın üzerine itmesine olanak tanıyan doğrudan denetim etkinleştirilmiş bir işlem kodudur. Özellikle, op_txhash, yığınından bir txhash bayrağı çıkarır ve bu bayrağa dayalı bir (etiketli) txhash hesaplar, ardından elde edilen hash'i tekrar yığına iter.

txhash ve ctv arasındaki benzerlikler nedeniyle, topluluk içinde bu ikisi hakkında önemli bir tartışma ortaya çıkmıştır.

txhash, ctv'nin evrensel bir yükseltmesi olarak düşünülebilir ve kullanıcılara işlem ücretleri ile ilgili birçok sorunu ele alan daha gelişmiş bir işlem şablonu belirlemelerine izin verir. Diğer sözleşme opcode'larının aksine, txhash tanıkta gerekli verinin bir kopyasını gerektirmez, böylece depolama gereksinimlerini daha da azaltır; ctv'nin aksine, txhash nop-uyumlu değildir ve yalnızca tapscript'te uygulanabilir; txhash ve csfs'nin birleşimi ctv ve apo'nun alternatifi olarak hizmet verebilir.

Sözleşmeler oluşturma perspektifinden bakıldığında, Txhash, düzeltmek istediğiniz işlem verilerinin tüm bölümlerinin yığına itildiği, birlikte hash edildiği ve ortaya çıkan hash'in sabit bir değerle eşleştiğinin doğrulandığı "ek sözleşmeler" oluşturmaya daha elverişlidir; CTV, serbest tutmak istediğiniz işlem verilerinin tüm bölümlerinin yığına itildiği "eksiltici sözleşmeler" oluşturmak için daha uygundur. Ardından, sıralı bir SHA256 işlem kodu kullanılarak hashing, işlem hash verilerinin ön ekini taahhüt eden sabit bir ara durumdan başlar. Serbest parçalar bu ara duruma hash edilir.

txhash özelliklerinde tanımlanan txfieldselector alanının, op_tx gibi diğer işlem kodlarına genişletilmesi beklenmektedir.

txhash ile ilgili bip şu anda github'da taslak durumunda ve bir numara atanmamıştır.

op_cat

op_cat, güvenlik endişeleri nedeniyle aslen Satoshi Nakamoto tarafından terk edilen gizemle çevrili bir opcode'dur. Son zamanlarda çekirdek bitcoin geliştiricileri arasında yoğun tartışmaları başlattı ve hatta internet üzerinde meme kültürünü tetikledi. Sonuçta, op_cat, bip-347 altında onaylandı ve son zamanlarda geçmesi en muhtemel bip önerisi olarak adlandırıldı.

Aslında, op_cat davranışı oldukça basittir: yığından iki öğe birleştirir. Peki, bunun bağlaşık işlevselliğini nasıl etkinleştirdiği?

gerçekten, iki öğeyi birleştirmek yeteneği, güçlü bir şifreleme veri yapısı olan merkle trie'ye karşılık gelir. Bir merkle trie oluşturmak için yalnızca birleştirme ve karma işlemleri gereklidir ve karma işlevleri bitcoin komut dosyalarında mevcuttur. Bu nedenle, op_cat ile teorik olarak bitcoin komut dosyaları içinde merkle ispatlarını doğrulayabiliriz, bu da blok zincir teknolojisinde en yaygın hafif doğrulama yöntemlerinden biridir.

Daha önce belirtildiği gibi, op_cat'in yardımıyla CSFS, evrensel bir sözleşme şeması uygulayabilir. Aslında, CSFS olmadan, Schnorr imzalarının yapısı kullanılarak op_cat kendisi işlem içgörüsü elde edebilir.

schnorr imzalarında, imzalanması gereken mesaj aşağıdaki alanlardan oluşur:

bu alanlar bir işlemin ana unsurlarını içerir. Onları scriptpubkey veya şahit içine yerleştirerek ve op_cat ile op_sha256 kullanarak, schnorr imzası oluşturabilir ve op_checksig kullanarak doğrulayabiliriz. doğrulama başarılı olursa, yığın doğrulanmış işlem verilerini korur ve işlem içgörüsü elde eder. Bu, işlemin girişleri, çıkışları, hedef adresleri veya ilgili Bitcoin miktarları gibi çeşitli parçalarını çıkarmamıza ve "kontrol" etmemize olanak tanır.

Belirli kriptografik ilkeler için Andrew Poelstra'nın "Cat and Schnorr Tricks" makalesine bakılabilir.

özetle, op_cat'in çok yönlülüğü neredeyse herhangi bir antlaşma opcode'unu taklit etmesine olanak tanır. Birçok antlaşma opcode'unun op_cat'in işlevselliğine dayandığı, bu da onu birleştirme listesindeki pozisyonunu önemli ölçüde ilerletmektedir. Teorik olarak, yalnızca op_cat'e ve mevcut bitcoin opcode'larına dayanarak, güvene dayalı bir btc zk rollup inşa etmeyi umut ediyoruz. Starknet, chakra ve diğer ekosistem ortakları bunun gerçekleşmesi için aktif olarak çalışmaktadır.

son

Bitcoin'in ölçeklendirilmesi ve programlanabilirliğini artırmak için çeşitli stratejileri keşfettiğimizde, ileriye dönük yolun, yerel iyileştirmelerin, zincir dışı hesaplamaların ve sofistike komut dosyası yeteneklerinin bir karışımını içerdiği açık hale gelir.

Esnek bir taban katman olmadan, daha esnek bir ikinci katman inşa etmek imkansızdır.

Off-chain hesaplama ölçeklendirmesi gelecektir, ancak Bitcoin'in programlanabilirliği bu ölçeklenebilirliği desteklemek ve gerçek bir küresel para birimi olmak için aşması gerekmektedir.

Bununla birlikte, Bitcoin'deki hesaplamanın doğası, Ethereum'dakinden temelde farklıdır. Bitcoin, bir hesaplama biçimi olarak yalnızca "doğrulamayı" destekler ve genel hesaplamalar yapamazken, Ethereum doğası gereği hesaplamalıdır ve doğrulama, hesaplamanın bir yan ürünüdür. Bu fark bir noktadan belirgindir: Ethereum, gerçekleştirilemeyen işlemler için bir gaz ücreti alırken, Bitcoin bunu yapmaz.

Antlaşmalar, hesaplama yerine doğrulamaya dayalı akıllı bir sözleşme türünü temsil eder. Birkaç Satoshi fundamentalizmi dışında, herkesin antlaşmaları iyileştirmek için iyi bir seçenek olarak gördüğü görünüyor. Bununla birlikte, topluluk antlaşmaların uygulanması için hangi yaklaşımın kullanılması gerektiği konusunda şiddetli bir şekilde tartışmaya devam ediyor.

apo, op_vault ve tluv doğrudan uygulamalara yönelir ve onları seçmek belirli uygulamaların daha ucuz ve daha verimli bir şekilde gerçekleştirilmesini sağlayabilir. Lightning network hayranları, ln-simetrisi elde etmek için apo'yu tercih ederler; bir kasa uygulamak isteyenler en iyi şekilde op_vault ile hizmet alabilir; coinpool oluşturmak için tluv daha fazla gizlilik ve verimlilik sunar. op_cat ve txhash daha esnek olup, daha küçük güvenlik açıkları olasılığına sahiptir ve diğer opcodes'lerle birleştirildiğinde daha fazla kullanım durumu uygulayabilir, belki de script karmaşıklığı maliyetiyle. Ctv ve csfs, blockchain işlemeyi ayarladı, ctv gecikmeli çıktıları uygularken csfs gecikmeli imzaları uygular. Matt, üniversal akıllı kontratları uygulamak için merkle trie yapısını kullanarak, iyimser yürütme ve dolandırıcılık kanıtları stratejisi ile öne çıkar, ancak hala içgörülü yetenekleri için yeni opcodes'ler gerektirir.

bitcoin topluluğunun, covenants elde etme olasılığını tartıştığını görüyoruz. starknet, resmi olarak bitcoin ekosistemine girişini duyurdu ve op_cat birleşmesinden sonra altı ay içinde bitcoin ağı üzerinde yerleşimleri uygulamayı planlıyor. chakra, op_cat soft fork'un birleştirilmesini teşvik etmek ve covenants'ın getirdiği programlanabilirliği kullanarak daha güvenli ve verimli bir bitcoin yerleşim katmanı oluşturmak için bitcoin ekosistemindeki en son gelişmeleri takip edecektir.

istisna:

1. bu makale [den alıntılanmıştırAyna]. tüm telif hakları orijinal yazarına aittir [ chakra]. eğer bu yeniden basım ile ilgili itirazınız varsa, lütfen iletişime geçinGate öğrenekip ve sorunu derhal ele alacaklar.
2. sorumluluk reddi: bu makalede ifade edilen görüşler yalnızca yazarına aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Diğer dillerde makalenin çevirileri, Gate.io öğrenme ekibi tarafından yapılır. Belirtilmedikçe, çevrilen makalelerin kopyalanması, dağıtılması veya kopyalanması yasaktır.