Yazar: mutourend & lynndell, Bitlayer Labs
Orijinal başlık: "Bitcoin Layer2 Ölçeklendirme Tekniklerinin Analizi: Geçerlilik Kanıtları ve Sahtekarlık Kanıtları"
Orijinal bağlantı: https://blog.bitlayer.org/Analytics_of_Bitcoin_Layer2_Scaling_Techniques_Validity_Proofs_and_Fraud_Proofs/
Belirli bir f algoritması için birbirlerine güvenmeyen iki katılımcı Alice ve Bob aşağıdaki yollarla güven kurabilirler:
- Alice x'i girer, f algoritmasını çalıştırır ve y sonucunu elde eder. Bob ayrıca aynı x girdisine dayalı olarak f algoritmasını çalıştırır ve sonuç y' olur. Eğer y = y′ ise Bob, Alice tarafından sağlanan x girişini ve y çıkışını kabul eder. Bu, blockchain fikir birliğinde yaygın olarak kullanılan özel bir geçerlilik kanıtlama mekanizmasıdır. Bunlar arasında Alice bloğu paketleyen düğümdür ve Bob ise konsensüse katılan düğümdür.
- Alice x'i girer, zk.prove programını f algoritmasında çalıştırır ve y sonucunu ve kanıtı elde eder. Bob zk.verify programını f, y ve kanıta dayalı olarak çalıştırır. Sonuç doğruysa Bob, Alice'in y sonucunu onaylar; sonuç yanlışsa Bob, Alice'in y sonucunu onaylamaz. Bu etkililiğin kanıtıdır. Bunların arasında Bob, zincir üstü bir sözleşme olabilir.
- Alice x'i girer, f algoritmasını çalıştırır ve y sonucunu elde eder. Bob ayrıca aynı x girdisine dayalı olarak f algoritmasını çalıştırır ve sonuç y' olur. Eğer y = y′, hiçbir şey yapmayın; eğer y ≠ y′ ise Bob, Alice'e meydan okur ve sorgulanan program f'tir. Alice ve Bob arasındaki etkileşimlerin sayısı bir veya daha fazla olabilir. Tahkim, itiraz yanıt sürecine dayalı olarak uygulanır. Bu dolandırıcılığın kanıtıdır. Bunların arasında Bob, zinciri izleyen ve zincire meydan okuyan, meydan okuyan kişidir.
- Alice x'i girer, zk.prove programını f algoritmasında çalıştırır ve y sonucunu ve kanıtı elde eder. Bob zk.verify programını f, y ve kanıta dayalı olarak çalıştırır. Sonuç doğruysa hiçbir şey yapmayın; sonuç yanlışsa Bob, Alice'e meydan okur ve sorgulanan program zk.verify'dır. Alice ve Bob arasındaki etkileşimlerin sayısı bir veya daha fazla olabilir. Alice ve Bob arasındaki etkileşimlerin sayısı bir veya daha fazla olabilir. Tahkim, itiraz yanıt sürecine dayalı olarak uygulanır. Bu dolandırıcılığın kanıtıdır. Bunların arasında Bob, zinciri izleyen ve zincire meydan okuyan, meydan okuyan kişidir.
Yukarıdaki 2,3,4 için x, Layer2 işlemi ve başlangıç durumu olsun, f, Layer2 konsensüs programı olsun ve y, blockchain Layer2 genişletme planına karşılık gelen işlem bitiş durumu olsun. içinde:
Yukarıdaki 2,3,4 için x, Layer2 işlemi ve başlangıç durumu olsun, f, Layer2 konsensüs programı olsun ve y, blockchain Layer2 genişletme planına karşılık gelen işlem bitiş durumu olsun. içinde:
- Geçerlilik Kanıtı: Kötümser varsayımlara dayanarak, kabul edilmeden önce etkili olduğu kanıtlanmalıdır ve hemen yürürlüğe girecektir. Geçerlilik kanıtında, dünyaya kötümser bir bakış açısını yansıtan L2 durum geçişinin doğru olduğuna dair kanıt sunmak gerekir - bir durum ancak ve ancak doğru olduğu kanıtlanırsa kabul edilecektir.
- Dolandırıcılık Kanıtı: İyimser varsayımlara dayanarak, varsayılan olarak kabul edilir ve birisi bunun yanlış olduğunu kanıtlamadığı sürece reddedilir. Bir sorgulama penceresi dönemi vardır ve bu, sorgulama penceresi dönemi sonrasına kadar geçerli olmayacaktır. Dolandırıcılık kanıtında, dünyaya iyimser bir bakış açısıyla L2 durum geçişinin yanlış olduğuna dair kanıt gereklidir - yanlış olduğu kanıtlanmadıkça belirli bir durum geçişi varsayılan olarak doğrudur.
Tablo 1: Güven nasıl oluşturulur?
Ayrıca şunu da unutmayın:
- Dolandırıcılık kanıtlarını geçerlilik kanıtlarından ayırmanın anahtarı, SNARK/STARK gibi ZK kanıt sistemlerinin kullanılıp kullanılmadığını belirlemek değildir. ZK ispat sistemi kullanılan ispat yöntemini ifade ederken, sahtekarlık veya geçerlilik ispatın içeriğini temsil etmektedir. Bu nedenle Tablo 1'deki Senaryo 1'in etkililiğin bir kanıtı olduğu söyleniyor.
- Geçerlilik kanıtının zamanlaması daha iyidir, ancak zincir üstü doğrulamanın karmaşıklığı nispeten yüksektir; dolandırıcılık kanıtının zincir üstü doğrulamanın karmaşıklığı daha düşüktür, ancak zamanlaması nispeten zayıftır.
- Tablo 1'deki 2. ve 4. durumlar için, ZK yineleme ve kombinasyon teknolojisinin yardımıyla birden fazla f hesaplanabilir ve sıkıştırılabilir, böylece zincirdeki zincir dışı hesaplamaların doğrulama maliyeti önemli ölçüde amorti edilir ve azaltılır.
Şu anda, sağlamlık Turing-complete akıllı sözleşmelerden yararlanan, sahtekarlığa dayanıklı ve geçerliliğe dayanıklı teknolojiler, Ethereum Layer 2 genişletmesinde yaygın olarak kullanılmaktadır. Ancak Bitcoin paradigması altında bu teknik uygulamalar, Bitcoin'in sınırlı işlem kodu işlevleri ve 1.000 yığın öğesi gibi sınırlamalar nedeniyle hala keşif aşamasındadır. Bitcoin Layer 2 genişleme senaryosunu göz önünde bulundurarak bu makale, Bitcoin paradigması altındaki sınırlamaları ve çığır açan teknolojileri özetlemekte, geçerlilik kanıtı ve sahtekarlığa karşı koruma teknolojisi üzerinde çalışmakta ve Bitcoin paradigması altındaki benzersiz komut dosyası bölümleme teknolojisini sıralamaktadır.
Bitcoin paradigması altında pek çok sınırlama vardır ancak bu sınırlamaları aşmak için çeşitli akıllı yöntemler veya teknolojiler kullanılabilir. Örneğin, bit taahhüdü UTXO durum bilgisi olmayan sınırı aşabilir, taproot komut dosyası alanı sınırını aşabilir, bağlayıcı çıkışı UTXO harcama yöntemi sınırını aşabilir ve sözleşmeler imzalama öncesi sınırını aşabilir.
Bitcoin, UTXO modelini benimser ve her UTXO, UTXO'yu harcamak için yerine getirilmesi gereken koşulları tanımlayan bir kilitleme komut dosyasında kilitlenir. Bitcoin Script'in aşağıdaki sınırlamaları vardır:
- Bitcoin komut dosyaları durum bilgisine sahip değildir;
- P2TR çıkış tipi için, tek bir işlemde barındırılabilecek maksimum toplam işlem kodu sayısı yaklaşık 4 milyondur ve bu da tüm bloğu dolduracaktır; diğer çıkış türleri için ise yalnızca 10.000 işlem kodu vardır;
- Tek bir UTXO'nun harcama yöntemleri sınırlıdır ve birleşik harcama yöntemlerinin araştırılmasında eksiklik vardır;
- Esnek sözleşme işlevlerini desteklemez;
- Yığın boyutu maksimum 1000 öğeyle (alt yığın + yığın) sınırlıdır ve tek bir öğenin maksimum boyutu 520 bayttır;
- Aritmetik işlemler (toplama, çıkarma gibi) 4 baytlık öğelerle sınırlıdır. 20 bayt veya daha büyük gibi uzun öğelere değiştirilemez ancak kriptografik işlemler için gereklidir;
- OP_MUL ve OP_CAT gibi işlem kodları devre dışı bırakıldı. Simülasyon için mevcut işlem kodlarını kullanırsanız, maliyet son derece yüksektir. Örneğin, tek yönlü BLAKE3 karmasını simüle etmek için komut dosyası boyutu yaklaşık 75K'dır.
Mevcut Bitcoin komut dosyaları tamamen durum bilgisizdir. Bitcoin komut dosyalarını çalıştırırken, yürütme ortamları her komut dosyasından sonra sıfırlanır. Bu, Bitcoin Script'in kısıtlama komut dosyası 1 ve komut dosyası 2'nin aynı x değerine sahip olmasını yerel olarak destekleyememesiyle sonuçlanır. Ancak bu sorunu çözmenin yolları var; temel fikir bir şekilde bir değere imza atmak. Bir değer üzerinde imza oluşturabiliyorsanız, durum bilgisi olan Bitcoin komut dosyalarını uygulayabilirsiniz. Yani, Komut Dosyası 1 ve Komut Dosyası 2'deki x değerinin imzasını kontrol ederek Komut Dosyası 1 ve Komut Dosyası 2'de aynı x değerini zorlayabilirsiniz. Çakışan imzalar varsa bu durum cezalandırılabilir; yani aynı x değişkeni 2 farklı değerle imzalanmıştır. Çözüm biraz bağlılıktır.
Bit taahhüdünün ilkesi nispeten basittir. Bit olarak adlandırılan şey, imza mesajındaki her bit için hash0 ve hash1 olmak üzere iki farklı hash değerinin ayarlanması anlamına gelir. İmzalanması gereken bit değeri 0 ise hash0'ın ön görüntüsü0 ortaya çıkar; imzalanması gereken bit değeri 1 ise hash1'in ön görüntüsü1 ortaya çıkar.
Örnek olarak tek bitlik m ∈ {0,1} mesajını ele alırsak, karşılık gelen bit taahhüdü kilit açma komut dosyası yalnızca bazı ön görüntülerdir: bit değeri 0 ise karşılık gelen kilit açma komut dosyası preimage0'dır - "0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140"; 1'de karşılık gelen kilit açma komut dosyası preimage1——"0x47c31e611a3bd2f3a7a42207613046703fa27496"dır. Bu nedenle, bit taahhüdü yardımıyla UTXO'nun durum bilgisi olmayan sınırlaması kırılabilir ve durum bilgisi olan Bitcoin komut dosyaları uygulanabilir, böylece çeşitli ilginç yeni özellikler mümkün hale gelir.
OP_HASH160
OP_DUP
<0xf592e757267b7f307324f1e78b34472f8b6f46f3> // Bu hash1'dir
OP_EQUAL
OP_DUP
OP_ROT
<0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // Bu hash0'dır
OP_EQUAL
OP_BOOLOR
OP_VERIFY
// Artık bit taahhüdünün değeri yığında ya “0” ya da “1”.
Bit Taahhüdünün şu anda iki uygulama yöntemi vardır:
- Lamport tek seferlik imza : Prensip nispeten basittir ve yalnızca karma işlevinin kullanılmasını gerektirir, dolayısıyla Bitcoin dostudur. Mesajdaki her bit için 2 hash değerinin işlenmesi gerekir, bu da nispeten büyük bir imza verisine neden olur. Başka bir deyişle, v bit uzunluğundaki bir mesaj için genel anahtar uzunluğu 2v bit ve imza uzunluğu v bittir.
- Winternitz tek seferlik imza : Lamport imzasıyla karşılaştırıldığında imzanın ve genel anahtarın uzunluğunu önemli ölçüde azaltabilir, ancak imzalama ve doğrulamanın karmaşıklığını artırır. Bu çözüm, uzunluk ve karmaşıklık arasında bir denge kurmak için farklı karma zincir uzunluğu d değerlerini esnek bir şekilde ayarlayabilir. Örneğin d=15 ayarlandığında genel anahtarın uzunluğu ve imzanın uzunluğu yaklaşık 4 kat kısalacak ancak imza doğrulama karmaşıklığı 4 kat artacaktır. Bu aslında Bitcoin yığın alanı ile komut dosyası boyutu arasındaki bir değiş tokuştur. Lamport imzası, d =1 olduğunda Winternitz imzasının özel bir durumu olarak kabul edilebilir.
Şu anda BitVM2 kütüphanesinde Blake3'ü temel alan karma işlevi Winternitz imzasını uyguluyor. Tek bir bit'e karşılık gelen imza uzunluğu yaklaşık 26 bayttır. Bit taahhüdü yoluyla statü kazandırmanın maliyetinin pahalı olduğu görülebilir. Bu nedenle, BitVM2 proje uygulamasında, mesaja önce 256 bitlik bir hash değeri elde etmek için hash işlemi uygulanır ve ardından hash değeri üzerinde bir bit taahhüdü gerçekleştirilir, böylece hash işleminin her bir biti üzerinde doğrudan hash işlemi gerçekleştirmek yerine ek yükten tasarruf edilir. orijinal daha uzun mesaj.
Kasım 2021'den bu yana etkinleştirilen Bitcoin Taproot yumuşak çatal yükseltmesi 3 teklif içeriyor: Schnorr imzası (BIP 340) , Taproot (BIP 341) ve TapScript (BIP 342). Yeni bir işlem türü tanıtıldı: Taproot'a Ödeme (P2TR) işlemleri. P2TR işlemleri Taproot, MAST (Merkle Abstract Syntax Tree) ve Schnorr imzalarının avantajlarını birleştirerek daha özel, esnek ve ölçeklenebilir bir işlem formatı oluşturabilir.
P2TR iki harcama yöntemini destekler: anahtar yoluna veya komut dosyası yoluna dayalı harcama.
Taproot'taki (BIP 341) düzenlemelere göre, script yoluyla harcama yapılırken ilgili Merkle yolunun maksimum uzunluğu 128'i geçmiyor. Bu, taptree'deki tapleaf sayısının 2128'i geçmediği anlamına gelir. 2017'deki segwit yükseltmesinden bu yana, Bitcoin ağı, maksimum 4 milyon ağırlık birimi (yani yaklaşık 4 MB) desteğiyle blok boyutunu ağırlık birimleri cinsinden ölçer. Bir P2TR çıktısı komut dosyası yolu aracılığıyla harcandığında, yalnızca tek bir tapleaf komut dosyasının açığa çıkarılması gerekir, yani blok tek bir tapleaf komut dosyasıyla paketlenir. Bu, P2TR işlemleri için her tapleaf'e karşılık gelen maksimum kod boyutunun yaklaşık 4 MB olduğu anlamına gelir. Ancak Bitcoin'in varsayılan stratejisinde, birçok düğüm yalnızca 400K'dan küçük işlemleri iletir. Daha büyük işlemler paketlenmek istiyorsa, madencilerle işbirliği yapmaları gerekir.
Taproot'un getirdiği komut dosyası alanı avantajı, çarpma ve karma oluşturma gibi kriptografik işlemleri simüle etmek için mevcut işlem kodlarının kullanılmasını daha değerli hale getiriyor.
P2TR'ye dayalı doğrulanabilir bir hesaplama oluştururken, karşılık gelen komut dosyası boyutu artık 4 MB ile sınırlı değildir. Bunun yerine, hesaplama birden fazla alt fonksiyona bölünebilir ve birden fazla tapleaf'e dağıtılabilir, böylece 4 MB komut dosyası boyutundaki Alan sınırlamaları aşılabilir. Aslında şu anda BitVM2'de uygulanan Groth16 doğrulama algoritmasının boyutu 2 GB kadar yüksek. Bununla birlikte, yaklaşık 1000 tapleaf'e bölünebilir ve dağıtılabilir, bit taahhüdüyle birleştirilerek, tüm hesaplamanın bütünlüğü ve doğruluğu, her bir alt fonksiyonun girişi ve çıkışı arasındaki tutarlılık kısıtlanarak kısıtlanabilir.
Bitcoin şu anda tek bir UTXO için yerel harcama yöntemleri sağlıyor: komut dosyasıyla harcama veya genel anahtarla harcama. Bu nedenle, karşılık gelen doğru ortak anahtar imzası sağlandığı veya komut dosyası koşulları karşılandığı sürece UTXO harcanabilir. İki UTXO bağımsız olarak harcanabilir ve iki UTXO'yu kısıtlamak için kısıtlamalar eklenemez, dolayısıyla bunların harcanabilmesi için bazı ek koşulların karşılanması gerekir.
Ancak Ark protokolünün kurucusu Burak, SIGHASH bayrağını akıllıca kullanarak konnektör çıkışını gerçekleştirdi. Özellikle Alice, BTC'sini Bob'a göndermek için bir imza oluşturabilir. Ancak imzalar birden fazla Giriş gerçekleştirebildiği için Alice imzasını koşullu olacak şekilde ayarlayabilir: İmza, Take_tx işlemi için ancak ve ancak işlem ikinci girişi tüketiyorsa geçerlidir. İkinci girişe UTXO A ve UTXO B'yi bağlayan konektör adı verilir. Başka bir deyişle Take_tx işlemi ancak ve ancak UTXO B'nin Challenge_tx tarafından harcanmamış olması durumunda geçerlidir. Bu nedenle konnektör çıkışı yok edilerek Take_tx işleminin etkili olması engellenebilir.
Şekil 1: Konektör çıkış şeması
BitVM2 protokolünde konnektör çıkışı if...else işlevi görür. Bir bağlayıcı çıkışı bir işlem tarafından harcandığında, ayrıcalıklı olmasını sağlamak için başka bir işlem tarafından harcanamaz. Gerçek dağıtımda, sorgulama yanıt süresini ayırmak için zaman kilitli UTXO ek olarak sunulur. Ek olarak, karşılık gelen konnektör çıkışı ihtiyaca göre farklı harcama stratejilerini de ayarlayabilir. Örneğin, meydan okuma işlemi herkes tarafından harcanabilecek şekilde ayarlanabilirken, yanıt işlemi yalnızca operatörün harcayabileceği veya vade bitiminden sonra herkesin harcayabileceği şekilde ayarlanabilir. .
Mevcut Bitcoin betiği temel olarak kilit açma koşullarını sınırlıyor ancak UTXO'nun daha fazla nasıl harcanabileceğini sınırlamaz. Bunun nedeni, Bitcoin betiğinin işlemin içeriğini okuyamaması, yani işlem iç gözlemini uygulayamamasıdır. Bitcoin betiği işlemin herhangi bir içeriğini (çıktı dahil) kontrol edebiliyorsa, sözleşme işlevi gerçekleştirilebilir.
Mevcut sözleşme uygulama yöntemleri iki kategoriye ayrılabilir:
- Ön imzalama: Mevcut Bitcoin komut dosyası oluşturma yeteneklerine dayanarak, ön imzalama, sınırlı işlevselliğe sahip önceden belirlenmiş sözleşmeler oluşturur. Yani, gelecekteki tüm olası işlemler önceden tasarlanıp imzalanarak katılımcıları belirli özel anahtarlara ve fiyatlara kilitler. Bazı planlar, tarafların tüm önceden imzalanmış işlemler için kısa ömürlü özel anahtarlar oluşturmasını bile gerektirir. Ön imzalama tamamlandığında bu kısa vadeli özel anahtarlar güvenli bir şekilde silinir, böylece saldırganlar kısa vadeli özel anahtarları ele geçiremez ve fonları çalamaz. Ancak her yeni katılımcı eklendiğinde veya operasyon güncellendiğinde yukarıdaki sürecin tekrarlanması gerekir ve bu da ağır bakım maliyetlerine neden olur. Örneğin, Lightning Network, ön imzalama yoluyla 2 taraflı bir sözleşme uygular ve birden fazla 2 taraflı sözleşmenin yönlendirme işlevini uygulamak için Hash Time Lock (HTLC) teknolojisini kullanır, böylece güveni en aza indirilmiş bir genişleme stratejisi elde eder. Bununla birlikte, Lightning Network'ün birden fazla işlemi önceden imzalaması gerekir ve iki tarafla sınırlıdır; bu biraz zahmetlidir; BitVM1'de her başlatıldığında yüzlerce işlemin önceden imzalanması gerekir; optimize edilmiş BitVM2'de ise Her başlatıldığında önceden imzalanması gerekiyor. Önceden imzalanan işlemlerin sayısı da onlarcaya ulaştı. İster BitVM1 ister BitVM2 olsun, yalnızca ön imzalamaya katılan operatörler geri ödeme almaya hak kazanır. Ön imzalamaya katılan n katılımcı varsa ve her katılımcının m işlemi önceden imzalaması gerekiyorsa, her katılımcının imzalama öncesi karmaşıklığı n ∗ m olacaktır.
- Sözleşme işlem kodlarının tanıtılması: Yeni sözleşme işlevi işlem kodlarının tanıtılması, sözleşme katılımcıları arasındaki iletişim karmaşıklığını ve bakım maliyetlerini önemli ölçüde azaltabilir, böylece Bitcoin'e daha esnek bir sözleşme uygulama yöntemi sunabilir. Örneğin OP_CAT: bayt dizelerini birleştirmek için kullanılır. İşlevi çok basit olmasına rağmen çok güçlüdür ve BitVM'nin karmaşıklığını önemli ölçüde azaltabilir; OP_TXHASH: sözleşme içindeki eylemleri daha iyi ayrıntı düzeyiyle kontrol edebilir. BitVM'de kullanıldığında daha geniş bir operatör kümesini destekleyebilir, böylece BitVM'nin güvenlik varsayımları büyük ölçüde iyileştirilir ve güven en aza indirilir. Ayrıca ön imzalama yöntemi, operatörün sadece avans geri ödeme sürecini kullanabileceği ve fon kullanım verimliliğinin düşük olduğu BitVM tasarımını öngörmüş olup, yeni sözleşme işlem kodu ile doğrudan kasadan kullanıcıya ödeme yapılabilmektedir. Sabit fon havuzu, Sermaye verimliliğini daha da artırın. Bu nedenle esnek sözleşme modeli, geleneksel imza öncesi kısıtlamaları etkili bir şekilde aşacaktır.
Bitcoin L2 genişletmesi için hem geçerlilik kanıtı hem de sahtekarlık kanıtı kullanılabilir. İkisi arasındaki temel farklar Tablo 2'de gösterilmektedir.
Bitcoin L2 genişletmesi için hem geçerlilik kanıtı hem de sahtekarlık kanıtı kullanılabilir. İkisi arasındaki temel farklar Tablo 2'de gösterilmektedir.
Tablo 2: Geçerlilik Kanıtı ve Sahtekarlık Kanıtı
Bit taahhüdü, taproot, ön imzalama ve bağlayıcı çıkışına dayalı olarak Bitcoin tabanlı dolandırıcılık kanıtları oluşturulabilir. Taproot'a dayalı olarak ve OP_CAT gibi sözleşme işlem kodlarının tanıtılmasıyla Bitcoin tabanlı bir geçerlilik sertifikası oluşturulabilir. Ayrıca Bob'un bir erişim sistemine sahip olup olmadığına bağlı olarak dolandırıcılık kanıtları, izinli dolandırıcılık kanıtları ve izinsiz dolandırıcılık kanıtları olarak ikiye ayrılabilir. Bunların arasında, izinli dolandırıcılık kanıtında yalnızca belirli bir grup Bob olarak itiraz edebilirken, izinsiz dolandırıcılık kanıtında herhangi bir üçüncü taraf Bob olarak itiraz edebilir. İzinsiz sistemin güvenliği, izinli sistemden daha iyidir; bu, izin verilen her katılımcının kötü eylemlerde bulunması riskini azaltabilir.
Alice ve Bob arasındaki sorgulama yanıtı etkileşimlerinin sayısına göre, sahtekarlık kanıtı, Şekil 2'de gösterildiği gibi bir tur sahtekarlık kanıtı ve birden fazla sahtekarlık kanıtı turuna bölünebilir.
Tablo 3'te gösterildiği gibi, tek yönlü etkileşim modeli ve çok yönlü etkileşim modeli dahil olmak üzere farklı etkileşim modelleri aracılığıyla sahtekarlığa karşı kanıt elde edilebilir.
Bitcoin Layer 2 genişleme paradigması altında, BitVM1 çok yönlü sahtekarlığa karşı koruma mekanizması kullanır, BitVM2 tek yönlü sahtekarlığa karşı koruma mekanizması kullanır ve bitcoincircle stark geçerlilik kanıtını kullanır. Bunların arasında BitVM1 ve BitVM2, Bitcoin protokolünde herhangi bir değişiklik yapılmadan uygulanabilirken, bitcoin-circle stark yeni bir OP_CAT işlem kodunun eklenmesini gerektirir.
Çoğu bilgi işlem görevi için, Bitcoin mühürü, test ağı ve ana ağ, 4 MB'lık bir komut dosyasıyla tam olarak temsil edilemez. Komut Dosyası Bölme teknolojisinin kullanılması gerekir; yani, hesaplamanın tamamını ifade eden komut dosyası, 4 MB'tan küçük parçalara bölünür ve her tapleaf'e dağıtılır. .
Tablo 3'te gösterildiği gibi çok yönlü dolandırıcılık kanıtı, zincir içi tahkim hesaplamalarının miktarını azaltmak istediğiniz ve/veya sorunlu hesaplama parçasını tek adımda bulmanın imkansız olduğu senaryolar için uygundur. Çok yönlü dolandırıcılık kanıtı, adından da anlaşılacağı gibi, sorunlu hesaplama parçalarını tespit etmek ve ardından bulunan hesaplama parçalarına dayalı olarak tahkim yürütmek için kanıtlayıcı ile doğrulayıcı arasında birden fazla etkileşim turu gerektirir.
Tablo 3'te gösterildiği gibi çok yönlü dolandırıcılık kanıtı, zincir içi tahkim hesaplamalarının miktarını azaltmak istediğiniz ve/veya sorunlu hesaplama parçasını tek adımda bulmanın imkansız olduğu senaryolar için uygundur. Çok yönlü dolandırıcılık kanıtı, adından da anlaşılacağı gibi, sorunlu hesaplama parçalarını tespit etmek ve ardından bulunan hesaplama parçalarına dayalı olarak tahkim yürütmek için kanıtlayıcı ile doğrulayıcı arasında birden fazla etkileşim turu gerektirir.
Robin Linus'un ilk BitVM teknik incelemesinde (genellikle BitVM1 olarak anılır) birden fazla dolandırıcılık kanıtı turu kullanıldı. Her turun sorgulama süresinin bir hafta olduğu ve problem hesaplama parçasını bulmak için ikili arama yönteminin kullanıldığı varsayılırsa, Groth16 Doğrulayıcı için zincir üstü sorgulama yanıt süresi 30 hafta kadar uzun olacaktır; bu da zamanlama açısından son derece zayıftır. . Her ne kadar şu anda ikili yöntemden daha verimli olan N'li bir arama yöntemi üzerinde çalışan ekipler bulunsa da, dolandırıcılık önleme turundaki güncelliği hala 2 haftalık döngüden çok daha düşük.
Şu anda, Bitcoin paradigması kapsamındaki birden fazla sahtekarlık kanıtı turu, izin verilen meydan okumaları kullanırken, bir tur dolandırıcılık kanıtı, katılımcılar arasındaki gizli anlaşma riskini azaltan ve daha yüksek güvenlikle sonuçlanan, izinsiz bir meydan okuma yöntemini uyguluyor. Bu amaçla Robin Linus, BitVM1'i optimize etmek için taproot'un tüm avantajlarından yararlandı. Yalnızca etkileşim turlarının sayısını bire düşürmekle kalmıyor, aynı zamanda meydan okuma yöntemini izin gerektirmeyen bir yönteme de genişletiyor, ancak bu, zincir içi tahkim hesaplamalarının miktarını artırma pahasına.
Doğrulama sahtekarlığının kanıtı, kanıtlayıcı ile doğrulayıcı arasında yalnızca tek bir etkileşimle tamamlanabilir. Bu modelde, doğrulayıcının yalnızca bir kez sorgulama başlatması ve kanıtlayıcının yalnızca bir kez yanıt vermesi gerekir. Bu yanıtta kanıtlayıcının hesaplamanın doğru olduğunu iddia eden bir kanıt sunması gerekir. Doğrulayıcı bu kanıttaki tutarsızlığı bulabilirse, meydan okuma başarılı olur, aksi takdirde meydan okuma başarısız olur. Bir tur etkileşimli dolandırıcılık kanıtının özellikleri Tablo 3'te gösterilmektedir.
Robin Linus, 15 Ağustos 2024'te BitVM2: Bitcoin'i İkinci Katmanlara Köprülemek teknik incelemesini yayınladı ve bir BitVM2 çapraz zincir köprüsünü bir tur sahtekarlığa karşı kanıtlamak için Şekil 3'e benzer bir yöntem kullandı.
OP_CAT, Bitcoin ilk piyasaya sürüldüğünde kodlama dilinin bir parçasıydı ve 2010 yılında güvenlik açıkları nedeniyle devre dışı bırakıldı. Ancak Bitcoin topluluğu birkaç yıldır onu etkinleştirmeyi tartışıyor. Şu anda OP_CAT'a 347 numarası atanmıştır ve Bitcoin mühüründe etkinleştirilmiştir.
OP_CAT'in ana işlevi yığındaki iki öğeyi birleştirmek ve birleştirilen sonucu yığına geri göndermektir. Bu özellik, Bitcoin'de sözleşmeleri ve STARK Doğrulayıcıyı etkinleştirir:
- Sözleşme: Andrew Poelstra, Bitcoin üzerinde sözleşmeleri uygulamak için OP_CAT ve Schnorr tekniklerini kullanarak CAT ve Schnorr Tricks I'i önerdi. Bunların arasında Schnorr algoritması P2TR çıkış tipinin dijital imzasıdır; diğer çıkış tipleri için benzer ECDSA teknikleri kullanılabilir, bkz . CAT ve ECDSA ile Anlaşmalar . OP_CAT sözleşmesinin yardımıyla, STARK Doğrulayıcı algoritmasının birden fazla işleme bölünmesine ve tüm STARK kanıtının kademeli olarak doğrulanmasına yardımcı olabilir.
- STARK Doğrulayıcı: STARK Doğrulayıcı esasen verileri birleştirir ve karma hale getirir. Cebirsel işlemlerden farklı olarak karma, çok fazla masraftan tasarruf sağlayan yerel bir Bitcoin komut dosyası işlemidir. Örnek olarak OP_SHA256'yı ele alırsak, yerel mod yalnızca bir işlem kodu gerektirirken simüle edilmiş mod yüzlerce K işlem kodu gerektirir. STARK'taki ana hash işlemleri Merkle yol doğrulaması ve Fiat-Shamir dönüşümüdür. Bu nedenle OP_CAT, STARK Doğrulayıcı algoritmasına çok uygundur.
SNARK/STARK tarafından kanıtlandıktan sonra, kanıtı doğrulamak amacıyla karşılık gelen doğrulama algoritmasını çalıştırmak için gereken hesaplama miktarı, orijinal hesaplamayı doğrudan çalıştırmak için gereken hesaplama miktarından çok daha azdır f. Bununla birlikte, bunu Bitcoin betiğinde doğrulama algoritmasının uygulanmasına dönüştürdüğümüzde, gerekli olan betik miktarı hala çok büyük. Şu anda, mevcut Bitcoin işlem koduna göre, optimizasyondan sonra, gerçekleştirilen Groth16 doğrulayıcı komut dosyası boyutu ve Fflonk doğrulayıcı komut dosyası boyutu hala 2 GB'tan büyük. Ancak tek bir Bitcoin bloğunun boyutu yalnızca 4 MB'tır ve doğrulama komut dosyasının tamamını tek bir blokta çalıştırmak imkansızdır. Bununla birlikte, taproot yükseltmesinden sonra Bitcoin, komut dosyalarının tapleaf yoluyla yürütülmesini destekler. Doğrulayıcı betiği birden fazla parçaya bölünebilir ve daha sonra her parça, bir taptree oluşturmak için bir tapleaf olarak kullanılır. Her parça arasında, parçalar arasındaki değerlerin tutarlılığını sağlamak için bit taahhüdü kullanılır.
OP_CAT sözleşmesiyle STARK Doğrulayıcı, 400 KB'tan küçük birden fazla standart işleme bölünebilir, böylece tüm STARK geçerlilik sertifikasının doğrulaması, madenciler ile işbirliği yapmaya gerek kalmadan tamamlanabilir.
Bu bölümde, mevcut durumları etkinleştirmek için herhangi bir yeni işlem kodu eklemeden, Bitcoin komut dosyalarının ilgili Split teknolojisine odaklanıyoruz.
Komut dosyalarını bölümlere ayırırken aşağıdaki boyutsal bilgilerin dengelenmesi gerekir:
- Tek parça komut dosyasının boyutu 4 MB'ı aşmaz ve giriş biti taahhüt komut dosyaları, işlem imzaları vb. için alan içermelidir.
- Tek bir yığın yığınının maksimum boyutu 1.000'i aşmaz. Bu nedenle, her yığın yığınında yalnızca gerekli öğeler tutulmalı, böylece komut dosyası boyutu optimizasyonuna hizmet etmek için yeterli yığın alanı ayrılmalıdır. Çünkü Bitcoin işlem ücretleri kullanılan yığın boyutuna bağlı değildir.
- Bitcoin'e ilişkin bit taahhütleri pahalıdır. Bu nedenle, şu anda 1 bit 26 bayta karşılık gelmektedir ve iki bitişik parça arasındaki giriş ve çıkış bitlerinin sayısı en aza indirilmelidir.
- Denetimi kolaylaştırmak için her bir parçanın işlevi mümkün olduğunca açık olmalıdır.
Şu anda, komut dosyası bölümlendirme yöntemleri temel olarak aşağıdaki üç kategoriye ayrılmıştır:
Şu anda, komut dosyası bölümlendirme yöntemleri temel olarak aşağıdaki üç kategoriye ayrılmıştır:
- Otomatik segmentasyon: Yığın boyutuna ve komut dosyası boyutuna bağlı olarak, yaklaşık 3 MB komut dosyası boyutuna ve minimum yığın boyutuna sahip bir segmentasyon yöntemi bulun. Bu yaklaşımın avantajı, belirli doğrulama algoritmasıyla hiçbir ilgisinin olmaması ve hesaplanan herhangi bir komut dosyası bölümlendirmesine genişletilebilmesidir. Dezavantajları şunlardır: (1) Mantık parçasının tamamının ayrı ayrı işaretlenmesi gerekir. Örneğin, OP_IF kod bloğu bölünemez, aksi takdirde bölünmüş komut dosyası yürütme sonucu yanlış olur (2) Parça yürütme sonucu birden fazla değere karşılık gelebilir; gerçek hesaplama mantığına göre bit taahhüdünün uygulanması gereken yığın öğelerinin sayısını işaretlemeyi gerektirir; (3) Her bir yığın komut dosyası tarafından uygulanan mantık işlevi zayıf bir şekilde okunabilir ve denetime elverişli değildir (4); ) Yığın, bir sonraki yığın için gerekli olmayan öğeleri içerebilir, bu da yığın alanı israfına neden olur.
- Fonksiyonel segmentasyon: Hesaplamada her bir fonksiyonel alt fonksiyona göre bölünür. Alt fonksiyonun giriş ve çıkış değerleri açıktır ve script segmentlere ayrılırken her bir parça için gereken bit taahhüt scripti de uygulanır, böylece. son yığın toplam komut dosyası: Boyut 4 MB'tan az ve yığın boyutu 1000'den az. Avantajları şunlardır: net işlevler, tek bir parçanın net mantığı, iyi okunabilirlik ve kolay denetim. Dezavantajı, orijinal hesaplama mantığının ifadesinin kod düzeyindeki mantığın ifadesiyle eşleşmemesidir. Orijinal hesaplama alt işlevi optimal olabilir ancak bu, kod düzeyinde optimal olduğu anlamına gelmez.
- Manüel segmentasyon: Komut dosyası segmentasyon noktası, işlevsel alt işlevlerde bulunmaz ancak manüel olarak ayarlanır. Tek bir alt işlevin boyutunun 4 MB'tan büyük olduğu durumlar için özellikle uygundur. Avantajı, Fq12 ile ilgili hesaplama alt işlevleri gibi ağır komut dosyası boyutundaki alt işlevlerin manuel olarak bölünebilmesidir; tek bir yığının açık bir mantığı, iyi okunabilirliği vardır ve denetlenmesi kolaydır. Dezavantajı ise şudur: manuel ayarlama yetenekleriyle sınırlıdır; genel komut dosyası optimize edildiğinde, önceden ayarlanmış manuel bölümleme noktaları optimal olmayabilir ve yeniden ayarlanması gerekebilir.
Örneğin, birden fazla optimizasyon turundan sonra Groth16 doğrulayıcı, komut dosyası boyutunu yaklaşık 7 GB'tan yaklaşık 1,26 GB'a düşürdü. Bu genel hesaplama optimizasyonuna ek olarak, yığın alanının tam olarak kullanılması için her bir parça ayrı ayrı optimize edilebilir. Örneğin , arama tablosunu temel alan daha iyi bir algoritma sunarak ve arama tablosunu dinamik olarak yükleyip boşaltarak , her bir parçanın komut dosyası boyutu daha da azaltılabilir.
web2 programlama dilinin hesaplama maliyeti ve çalışma ortamı, Bitcoin betiğinin maliyeti ve çalışma ortamından tamamen farklıdır, dolayısıyla çeşitli algoritmaların Bitcoin betiğinin uygulanması için, yalnızca mevcut uygulamanın çevrilmesi işe yaramayacaktır. Bu nedenle Bitcoin senaryosu için aşağıdaki optimizasyonların dikkate alınması gerekir:
- Hesaplamanın bir kısmı feda edilse bile, optimum bellek konumuna sahip bir algoritma bulmak, parçalar arasındaki giriş ve çıkış bitlerinin sayısını azaltabilir, böylece BitVM2 tasarımındaassertTx işlemi tarafından işlenen veri miktarını azaltabilir.
- İlgili işlemlerin (mantıksal işlemler gibi) değişme özelliğinden yararlanarak x&y = y&x, arama tablosunun neredeyse yarısını kurtarır.
- Şu anda, Fq12 işlemine karşılık gelen komut dosyası miktarı büyüktür. Fq12 genişletilmiş etki alanı işleminin hesaplama karmaşıklığını önemli ölçüde azaltmak için Fiat-Shamir, Schwartz-Zipple ve polinom taahhüt şemalarını kullanmayı düşünün .
Bu makale ilk olarak Bitcoin komut dosyalarının sınırlamalarını tanıtıyor ve UTXO durum bilgisi olmayan sınırlamaları aşmak için Bitcoin vaatlerinin kullanımını, komut dosyası alanı sınırlamalarını aşmak için Taproot kullanımını, UTXO harcama yöntemi kısıtlamalarını aşmak için bağlayıcı çıkışının kullanımını ve UTXO harcama yöntemi kısıtlamalarını aşmak için bağlayıcı çıkışının kullanımını tanıtıyor. İmza öncesi kısıtlamaları aşmak için sözleşmelerin kullanılması. Daha sonra, dolandırıcılık kanıtı ve geçerlilik kanıtının özellikleri, izinli dolandırıcılık kanıtı ve izinsiz dolandırıcılık kanıtının özellikleri, bir tur dolandırıcılık kanıtı ve çoklu tur dolandırıcılık kanıtının özellikleri ve Bitcoin komut dosyası segmentasyon teknolojisi kapsamlı bir şekilde sıralandı ve özetlendi.
- OP_EĞER , OP_CAT , OP_SHA256
- Lamport tek seferlik imza
- Winternitz tek seferlik imza
- BitVM: Bitcoin'de Her Şeyi Hesaplayın
- BitVM2: Bitcoin'i İkinci Katmanlara Köprülemek
- CAT ve Schnorr Hileleri I
- CAT ve ECDSA ile yapılan sözleşmeler
- Bitcoin'de Geçerlilik Toplamaları
- StarkWare, Geçerlilik Kanıtları ve Sahtekarlık Kanıtları, 2019.01.23
- StarkWare, Geçerlilik Kanıtları ve Sahtekarlık Kanıtları, 2024.05.09
- StarkWare, Bitcoin'de genel hesaplamaya giden yol, 2024.07.24
- BitVMX, Bitcoin Script için Algoritmaları Optimize Etme, 2024.06.27
- Alchemy, İyimser Toplamalar Nasıl Çalışır (Tam Kılavuz), 2023.08.09
- Ethereum, İyimser Toplamalar Sahtekarlığı kanıtlıyor, 2024.07.17
Tüm Yorumlar