TL;DR

Tanıtım:

Bu makale, BitVM'nin yaklaşımını açıklayan BitVM whitepaper'ının bir yorumunu sunmaktadır: Verilerin başlangıçta zincir üzerinde olması gerekmez; sadece blok zincirinde saklanan bir Taahhüt ile zincir dışında yayınlanır ve saklanır.

İletilen Orijinal Makale Başlığı: BitVM'nin Basitleştirilmiş Bir Yorumu: BTC Blok Zincirinde Sahtekarlık Kanıtları Nasıl Doğrulanır (EVM veya Diğer VM Opcode'larını Yürütme)

Önsöz: Şu anda Bitcoin Katman 2 bir trend haline gelmiştir ve düzinelerce proje kendini "Bitcoin Katman 2" olarak tanımlamaktadır. Bunların birçoğu "Rollup" olduklarını iddia ederek BitVM whitepaper'ında önerilen yaklaşımı kullandıklarını ve BitVM'i Bitcoin ekosisteminin önemli bir parçası olarak konumlandırdıklarını belirtmektedir.

Bununla birlikte, BitVM hakkındaki mevcut literatürün çoğu, ilkelerini meslekten olmayanların terimleriyle açıklamamaktadır. Bu makale, 8 sayfalık BitVM whitepaper'ını okumamız ve Taproot, MAST ağaçları ve Bitcoin Script ile ilgili kaynaklara danışmamızın ardından basitleştirilmiş bir özet sunmaktadır. Anlaşılmasına yardımcı olmak için, okuyucunun Katman 2 hakkında biraz bilgisi olduğunu ve "sahtekarlık kanıtları" temel fikrini kavrayabildiğini varsayarak BitVM tanıtım belgesinde bulunan bazı ifadeleri değiştirdik.

BitVM'nin ön konsepti birkaç cümleyle özetlenebilir: zincir üzerindeki veri ihtiyacını ortadan kaldırır, başlangıçta verileri zincir dışında yayınlar ve depolar, yalnızca blok zincirinde depolanan bir Taahhüt ile. Zorluk veya sahtekarlık kanıtı durumlarında, blok zincirindeki Taahhüt ile ilişkisini göstermek için yalnızca gerekli veriler zincire getirilir. Daha sonra BTC ana ağı, zincir üzerindeki verileri herhangi bir sorun olup olmadığı ve veri üreticisinin (işlemleri gerçekleştiren düğüm) kötü niyetli faaliyetlerde bulunup bulunmadığı açısından doğrular. Bu yaklaşım Occam'ın Usturası ilkesine bağlıdır - "Varlıklar gereksiz yere çoğaltılmamalıdır" (zincir dışı olabiliyorsa, zincir dışı kalsın).

Ana Metin: Sözde BTC blok zinciri dolandırıcılık kanıtı doğrulama şeması, meslekten olmayanların terimleriyle BitVM'ye dayanmaktadır:

1.İlk olarak, bir bilgisayar/işlemci çok sayıda mantık kapısı devresinden oluşan bir giriş-çıkış sistemidir. BitVM'in temel fikirlerinden biri, mantık kapısı devrelerinin giriş-çıkış etkilerini simüle etmek için Bitcoin Script'i kullanmaktır. Mantık kapısı devreleri simüle edilebildiği sürece, teorik olarak, tüm hesaplanabilir görevleri tamamlayan bir Turing makinesi elde edilebilir. Bu, yeterli kaynağınız ve insan gücünüz varsa, önce ilkel Bitcoin Script kodunu kullanarak mantık kapısı devrelerini simüle etmek için bir mühendis ekibi toplayabileceğiniz ve ardından EVM veya WASM'ın işlevlerini uygulamak için çok sayıda mantık kapısı devresi kullanabileceğiniz anlamına gelir.

(Bu ekran görüntüsü bir eğitim oyunundan alınmıştır: "Turing Complete", temel içeriği, özellikle NAND kapıları gibi mantık kapısı devrelerini kullanarak eksiksiz bir CPU işlemcisi oluşturmaktır).

Bazıları BitVM'in yaklaşımını redstone devreleri kullanarak "Minecraft "ta bir M1 işlemci inşa etmeye benzetti. Ya da New York'taki Empire State Binası'nı LEGO bloklarıyla inşa etmeye benziyor.

(Birisinin "Minecraft "ta bir "işlemci" inşa etmek için bir yıl harcadığı söyleniyor).

1. Peki, EVM veya WASM'ı simüle etmek için neden Bitcoin Script kullanalım? Bu çok zahmetli değil mi? Bunun nedeni, çoğu Bitcoin Katman 2 çözümünün genellikle Solidity veya Move gibi üst düzey dilleri desteklemeyi seçmesi, şu anda doğrudan Bitcoin blok zincirinde çalışabilen tek dilin ise Bitcoin Script olmasıdır. Bu dil ilkeldir, bir grup benzersiz işlem kodundan oluşur ve Turing tam değildir.

(Bitcoin Script koduna bir örnek)

Bitcoin Layer 2, Ethereum'un Arbitrum gibi Layer 2 çözümleri gibi Layer 1'deki sahtekarlık kanıtlarını doğrulamayı hedefliyorsa, BTC'nin güvenliğini büyük ölçüde devralmak için BTC blok zincirinde "tartışmalı bir işlemi" veya "tartışmalı bir işlem kodunu" doğrudan doğrulaması gerekir. Bu, Katman 2 tarafından kullanılan Solidity dili / EVM işlem kodlarının Bitcoin blok zincirinde yeniden yürütülmesi gerektiği anlamına gelir. İşin özü şu:

EVM veya diğer sanal makinelerin etkilerini elde etmek için Bitcoin'in yerel ancak ilkel bir programlama dili olan Bitcoin Script'i kullanmak.

Bu nedenle, derleme ilkeleri açısından, BitVM yaklaşımı EVM / WASM / JavaScript işlem kodlarını Bitcoin Script işlem kodlarına çevirir ve mantık kapısı devreleri "EVM işlem kodları -> Bitcoin Script işlem kodları" arasında bir ara temsil (IR) olarak hizmet eder.

(BitVM teknik incelemesi, Bitcoin blok zincirinde belirli "ihtilaflı talimatların" yürütülmesine yönelik genel yaklaşımı ele almaktadır)

Her neyse, simüle edilen nihai etki, başlangıçta yalnızca EVM / WASM üzerinde işlenebilen talimatların doğrudan Bitcoin blok zincirinde işlenmesidir. Bu çözüm uygulanabilir olsa da, zorluk tüm EVM/WASM işlem kodlarını ifade etmek için çok sayıda mantık kapısı devresinin bir ara form olarak nasıl kullanılacağında yatmaktadır. Ayrıca, bazı son derece karmaşık işlem akışlarını doğrudan temsil etmek için mantık kapısı devrelerinin kombinasyonlarını kullanmak çok büyük bir iş yüküne neden olabilir.

1. BitVM whitepaper'ında bahsedilen bir diğer temel kavram olan ve Arbitrum tarafından kullanılanlara oldukça benzeyen "İnteraktif Sahtekarlık Kanıtları "nı tartışalım.

İnteraktif Dolandırıcılık Kanıtları, iddia olarak bilinen bir terimi içerir. Tipik olarak, Katman 2'yi teklif eden (genellikle bir sıralayıcı tarafından hareket edilir), Katman 1'de belirli işlem verilerinin ve durum geçiş sonuçlarının geçerli ve hatasız olduğunu beyan eden bir iddia yayınlar.

Birisi teklif sahibi tarafından sunulan iddianın sorunlu olduğuna inanırsa (ilişkili veriler yanlışsa), bir anlaşmazlık meydana gelir. Bu noktada, teklif eden ve meydan okuyan turlar halinde bilgi alışverişinde bulunur ve çok ince taneli bir işlem talimatını ve ilgili veri segmentini hızlı bir şekilde bulmak için ihtilaflı veriler üzerinde ikili bir arama yöntemi kullanır.

Bu tartışmalı işlem talimatı (OP Kodu) için, giriş parametreleriyle birlikte doğrudan Katman 1'de yürütülmesi ve çıktı sonucunun doğrulanması gerekir (Katman 1 düğümleri hesapladıkları çıktı sonucunu teklif sahibi tarafından daha önce yayınlanan çıktı sonucuyla karşılaştırır). Arbitrum'da bu, "Tek Adımlı Sahtekarlık Kanıtları" olarak bilinir. (Arbitrum'un etkileşimli sahtekarlık kanıtı protokolünde, tartışmalı talimatı ve yürütme sonucunu hızlı bir şekilde bulmak için ikili arama kullanılır ve ardından nihai doğrulama için Katman 1'e tek adımlı bir sahtekarlık kanıtı gönderilir).

Bunu takip ediyorum:

1. Süreç interaktiftir ve her iki taraf da sırayla hareket eder. Taraflardan biri bir Toplama Bloğunda yer alan geçmiş verileri segmentlere ayırır ve diğer taraf hangi veri segmentinin sorunlu olduğunu belirtir. Bu, ikili bir yönteme benzer (gerçekte, N/K aralığını aşamalı olarak daraltma süreci).

2. Daha sonra, hangi işlemin ve sonucun sorunlu olduğunu daha fazla tespit etmek ve ardından bu işlem içinde tartışmalı olan belirli bir makine talimatına kadar daraltmak mümkündür.

3. ChallengeManager sözleşmesi yalnızca orijinal verinin alt bölümlere ayrılmasıyla üretilen "veri segmentinin" geçerli olup olmadığını kontrol eder.

4. Meydan okuyan ve meydan okunan, meydan okunacak makine komutunu bulduktan sonra, meydan okuyan oneStepProveExecution() işlevini çağırarak bu makine komutunun yürütme sonucuyla ilgili bir sorun olduğunu göstermek için tek adımlı bir sahtekarlık kanıtı gönderir.

(Arbitrum'un interaktif sahtekarlık kanıt protokolünde, süreç, Teklif Sahibi tarafından yayınlanan verilerden ihtilaflı talimatı ve yürütme sonucunu hızlı bir şekilde bulmak için ikili aramanın kullanılmasını içerir. Tartışmalı veri parçası veya işlem kodu belirlendikten sonra, son doğrulama için Katman 1'e tek adımlı bir sahtekarlık kanıtı gönderilir).

Referanslar:

Eski Arbitrum teknik elçisi Arbitrum'un bileşen yapısını açıklıyor (Bölüm 1)

(Arbitrum'un interaktif dolandırıcılık kanıt akış şeması, açıklama nispeten kabadır)

Bu noktada, tek adımlı sahtekarlık kanıtları kavramı oldukça basit hale gelir: Katman 2'de gerçekleşen işlem talimatlarının büyük çoğunluğunun BTC blok zincirinde yeniden doğrulanması gerekmez. Ancak, belirli bir ihtilaflı veri segmentine/opcode'a itiraz edilirse, Katman 1'de yeniden oynatılması gerekir.

Doğrulama sonucu, Teklif Sahibi tarafından daha önce yayınlanan verilerin sorunlu olduğunu gösterirse, Teklif Sahibinin bahisli varlıkları kesilir. Challenger'ın hatalı olduğu tespit edilirse, Challenger'ın hisseli varlıkları kesilir. Zorluklara zamanında yanıt vermeyen tedarikçiler de kesintiye uğrayabilir.

Arbitrum, yukarıda bahsedilen etkileri Ethereum üzerindeki sözleşmeler aracılığıyla uygularken, BitVM, zaman kilitleri, multisig ve diğer özellikleri uygulamak için Bitcoin Script kullanarak benzer işlevselliği elde etmeyi amaçlamaktadır.

4. "Etkileşimli Sahtekarlık Kanıtları" ve "Tek Adımlı Sahtekarlık Kanıtları "nı tartıştıktan sonra, MAST ağaçları ve Merkle Kanıtları hakkında konuşacağız. Daha önce, BitVM çözümünde, Katman 2'de zincir dışında işlenen büyük miktarda işlem verisinin ve mantık kapısı devrelerinin doğrudan zincir üzerine yerleştirilmediğinden bahsetmiştik. Gerektiğinde yalnızca minimum miktarda veri/mantık kapısı devresi zincire eklenir. Ancak, başlangıçta zincir dışı olan ve şimdi zincire eklenmesi gereken bu verilerin uydurma olmadığını kanıtlamak için bir yola ihtiyacımız var. Kriptografide Taahhüt kavramı burada devreye girmektedir ve Merkle Kanıtı bu tür bir Taahhüdün bir şeklidir.

Öncelikle MAST ağaçları hakkında konuşalım. MAST'ın tam adı Merkelized Abstract Syntax Trees olup AST'nin (Soyut Sözdizimi Ağaçları) derleyici ilkeleri alanından Merkle Ağaçlarına dönüştürülmesidir. Peki, AST nedir? Basit bir ifadeyle, karmaşık bir komutu sözcüksel analiz yoluyla bir grup temel işlem birimine ayıran ağaç benzeri bir veri yapısıdır.

(AST ağacına örnek olarak "x=2, y=x*3" gibi basit hesaplamaların altta yatan işlem kodlarına ve verilere ayrılması verilebilir. )

O halde MAST ağacı, Merkle Kanıtlarını destekleyen bir AST ağacına Merkleizasyon uygulanmasının sonucudur. Merkle ağaçlarının bir avantajı, verileri verimli bir şekilde "sıkıştırma" yeteneğidir. Örneğin, gerektiğinde Merkle ağacından bir veri segmentini BTC blok zincirinde yayınlamak ve aynı zamanda bu veri segmentinin Merkle ağacında gerçekten var olduğunu ve keyfi olarak seçilmediğini inandırıcı kılmak istiyorsanız ne yaparsınız?

Merkle ağacının Kökünü blok zincirine önceden kaydetmeniz yeterlidir. Gelecekte, Kök'e karşılık gelen Merkle ağacında bir veri parçasının bulunduğunu kanıtlayan bir Merkle Kanıtı sunmak yeterli olacaktır.

(Merkle Proof/Branch ve Root arasındaki ilişki)

Bu nedenle, MAST ağacının tamamını BTC blok zincirinde saklamaya gerek yoktur; Kökünü önceden bir Taahhüt olarak ifşa etmek yeterlidir. Gerektiğinde, veri segmenti + Merkle Proof/Branch'ın sunulması yeterlidir. Bu, zincir üzerindeki veri miktarını büyük ölçüde azaltırken zincir üzerindeki verilerin MAST ağacında gerçekten var olmasını sağlar. Ayrıca, tüm veriler yerine BTC blok zincirindeki veri segmentlerinin + Merkle Proof'un yalnızca küçük bir bölümünün ifşa edilmesi, gizlilik korumasını önemli ölçüde artırabilir.

Referanslar:Veri Stopajı ve SahtekarlıkKanıtı:Plasma Neden Akıllı Sözleşmeleri Desteklemiyor?

(MAST ağacı örneği)

BitVM'in çözümünde, tüm mantık kapısı devreleri, devasa bir MAST ağacında düzenlenen Bitcoin komut dosyaları kullanılarak ifade edilir. Diyagramda İçerik olarak gösterilen bu ağacın alt yaprakları, Bitcoin komut dosyasında uygulanan mantık kapısı devrelerine karşılık gelir. Katman 2'nin Teklif Sahibi, MAST ağacının kökünü BTC blok zincirinde sık sık yayınlar ve her MAST ağacı, tüm giriş parametrelerini / işlem kodlarını / mantıksal kapı devrelerini içeren bir işlemle ilişkilendirilir. Bu, Arbitrum'un Proposer'ının Ethereum blok zincirinde Toplama Blokları yayınlamasına biraz benziyor.

Bir anlaşmazlık ortaya çıktığında, bir meydan okuyucu BTC blok zincirinde hangi Köke meydan okumak istediğini beyan eder ve ardından Teklif Sahibinden Köke karşılık gelen belirli bir veri segmentini açıklamasını ister. Daha sonra, Teklif Sahibi bir Merkle İspatı sunarak, ihtilaflı mantık kapısı devresi meydan okuyan ile birlikte bulunana kadar MAST ağacının zincir üzerindeki verilerinin küçük bölümlerini sürekli olarak ifşa eder. Bundan sonra bir Eğik Çizgi uygulanabilir.

(Kaynak:https://medium.com/crypto-garage/deep-dive-into-bitvm-computing-paradigm-to-express-turing-complete-bitcoin-contracts-1c6cb05edfca）

1. Bu noktaya kadar, BitVM çözümünün en önemli yönleri büyük ölçüde ele alındı. Bazı ayrıntılar hala biraz belirsiz olsa da, okuyucuların BitVM'nin özünü ve ana noktalarını kavrayabileceklerine inanılmaktadır. Beyaz bülteninde bahsedilen "bit değeri taahhüdü" ile ilgili olarak, bir Teklif Sahibinin sorgulandığında ve mantık geçidi devresini zincir üzerinde doğrulamaya zorlandığında bir mantık geçidinin giriş değerlerine hem 0 hem de 1 atamasını ve böylece belirsizlik ve karışıklık yaratmasını önlemek için tasarlanmıştır.

Özetle, BitVM şeması, mantık kapısı devrelerini ifade etmek için Bitcoin komut dosyasını kullanarak başlar, daha sonra bu devreleri EVM / diğer VM'lerin işlem kodlarını ifade etmek için kullanır, bunlar da herhangi bir işlem talimatının işlem akışını ifade eder ve son olarak bunları bir Merkle ağacı / MAST ağacı şeklinde düzenler. Böyle bir ağaç tarafından temsil edilen işlem işleme akışı çok karmaşıksa, 100 milyon yaprağı kolayca aşabilir, bu nedenle taahhütler tarafından işgal edilen blok alanını ve sahtekarlık kanıtlarından etkilenen kapsamı en aza indirmek çok önemlidir.

Tek adımlı bir sahtekarlık kanıtı yalnızca çok az miktarda veri ve zincir üzerinde bir mantık kapısı komut dosyası gerektirse de, Merkle Ağacının tamamı uzun bir süre zincir dışında saklanmalıdır, böylece birisi itiraz ederse herhangi bir zamanda zincir üzerinde erişilebilir. Katman 2'deki her bir işlem büyük bir Merkle Ağacı oluşturur ve düğümler üzerindeki hesaplama ve depolama baskısı tahmin edilebilir. Çoğu kişi düğümleri çalıştırmak istemeyebilir (ancak, bu tür geçmiş veriler aşamalı olarak kaldırılabilir ve B^2 ağı, depolama düğümlerini geçmiş verileri uzun vadeli olarak korumaya teşvik etmek için Filecoin'e benzer zk depolama kanıtlarını özellikle sunar).

Ancak, sahtekarlık kanıtlarına dayalı iyimser Toparlamalar çok fazla düğüme ihtiyaç duymaz çünkü güven modelleri 1/N'dir, yani N düğümden biri dürüst olduğu ve kritik bir anda bir sahtekarlık kanıtı başlatabildiği sürece, Katman 2 ağı güvenlidir.

Bununla birlikte, BitVM tabanlı Katman 2 çözümlerinin tasarımında, aşağıdakiler gibi birçok zorluk bulunmaktadır:

1) Teorik olarak, verileri daha fazla sıkıştırmak için, işlem kodlarını doğrudan Katman 1 üzerinde doğrulamak gerekli değildir. İşlem kodlarının işlem akışı daha da sıkıştırılarak bir zk-proof haline getirilebilir ve meydan okuyucuların zk-proof'un doğrulama adımlarına meydan okumasına olanak tanır. Bu, zincir üzerindeki veri miktarını önemli ölçüde azaltabilir. Ancak, spesifik geliştirme detayları çok karmaşık olabilir.

2) Teklif Sahipleri ve Meydan Okuyucular zincir dışı etkileşimleri tekrar tekrar oluşturmalıdır. Protokolün nasıl tasarlanması gerektiği ve taahhüt ve meydan okuma sürecinin işlem akışında nasıl daha da optimize edilmesi gerektiği, çok fazla entelektüel çaba gerektirecektir.

Sorumluluk Reddi：

1. Bu makale[Geek Web3] adresinden yeniden basılmıştır, Orijinal Başlık "BitVM'nin minimalist bir yorumu: BTC zincirinde dolandırıcılık kanıtı nasıl doğrulanır (EVM veya diğer VM'nin işlem kodunu çalıştırın)", telif hakkı orijinal yazara aittir [Faust & Misty Moon]
   . Bu baskıya itirazınız varsa, lütfen Gate Learn ekibiyle iletişime geçin, onlar bu konuyu derhal ele alacaklardır.
2. Sorumluluk Reddi: Bu makalede ifade edilen görüş ve fikirler yalnızca yazara aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirisi Gate Learn ekibi tarafından yapılmaktadır. Belirtilmediği sürece, çevrilen makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.