Arbitrum'un Bileşen Yapısının Eski Arbitrum Teknik Elçisi Tarafından Yorumlanması (Bölüm 1)

Çin toplumunda özellikle Arbitrum ve OP Rollup için Layer2 protokolleriyle ilgili makale veya materyallerin profesyonel yorumlanması eksikliği olduğundan, bu makale Arbitrum'un çalışma mekanizmasını açıklayarak bu boşluğu doldurmayı amaçlamaktadır. Arbitrum'un karmaşıklığı nedeniyle tam metin mümkün olduğu kadar basitleştirildikten sonra bile 10.000 kelimeyi aşıyor. Bu nedenle iki parçaya bölünmüş olup, referans materyal olarak kaydedilip paylaşılması tavsiye edilmektedir.”

Toplama Sıralayıcısına Genel Bakış

Toplama ölçeklendirme ilkesi iki noktada özetlenebilir:

Maliyet Optimizasyonu: Hesaplama ve depolama görevlerinin çoğunu L1 altında çalıştırılan Katman 2'ye aktarın. L2 çoğunlukla sıralayıcı/operatör olarak adlandırılan ve ayrı bir zincir oluşturan tek bir sunucu üzerinde çalışır.

Sıralayıcı, algı açısından neredeyse merkezi bir sunucu gibi görünüyor ve TPS ve maliyette avantaj elde etmek için 'blok zincirinin imkansız üçlüsünde' merkeziyetsizliği terk ediyor. Kullanıcılar, Ethereum'daki işlemlere kıyasla çok daha düşük maliyetlerle, Ethereum yerine işlem talimatlarını işlemek için L2'yi kullanabilir.

(Kaynak: BNB Zinciri)

Güvenlik Güvencesi: L2'deki işlem içeriği ve işlem sonrası durum, Ethereum L1 ile senkronize edilir ve bunların geçerliliği, durum geçişi sözleşmeleri aracılığıyla doğrulanır. Aynı zamanda Ethereum, L2'nin geçmişini korur, böylece sıralayıcı kalıcı olarak çökse bile diğerleri, Ethereum kayıtları aracılığıyla L2'nin tüm durumunu yeniden oluşturabilir.

Temel olarak Rollup'ın güvenliği Ethereum'a dayanır. Sıralayıcı bir hesabın özel anahtarını bilmiyorsa, o hesap adına işlem başlatamaz veya hesabın varlık bakiyesini değiştiremez (denese bile hızlı bir şekilde tespit edilecektir).

Sıralayıcı, merkezi bir merkez olarak merkezi bir özelliğe sahipken, olgun Toplama çözümlerinde, merkezi sıralayıcı yalnızca işlem sansürü veya kötü niyetli çökmeler gibi yumuşak kötü niyetli faaliyetlerle meşgul olabilir. İdeal bir Toplama senaryosunda, bu tür eylemleri sınırlamak için zorunlu geri çekilmeler veya sansür karşıtı mekanizmalar için kanıtların sıralanması gibi karşılık gelen önlemler vardır.

(Loopring protokolü, kullanıcıların araması için L1'deki sözleşme kaynak kodunda zorunlu bir geri çekilme işlevi ayarlar)

Toplama sıralayıcıların kötü niyetli eylemlerini önlemeye yönelik durum doğrulama mekanizmaları iki kategoriye ayrılır: Sahtekarlığa Karşı Kanıt ve Geçerlilik Kanıtı. Fraud Proof'u kullanan Toplama çözümleri, OP Toplama (İyimser Toplama, OPR) olarak anılırken, Geçerlilik Kanıtı kullananlar, geçmiş bagaj nedeniyle Geçerlilik Toplama yerine genellikle ZK Toplama (Sıfır Bilgi Kanıtı Toplama, ZKR) olarak adlandırılır.

Arbitrum One, iyimser bir şekilde verilerin doğru olduğunu varsayarak, gönderilen verileri aktif olarak doğrulamayan sözleşmelerle L1'de konuşlandırılan tipik bir OPR'dir. Gönderilen verilerde bir hata varsa L2 doğrulayıcı düğümler aktif olarak bir sorgulama başlatacaktır.

Bu nedenle OPR bir güven varsayımını ima eder: herhangi bir zamanda en az bir dürüst L2 doğrulayıcı düğüm vardır. Öte yandan ZKR sözleşmeleri, sıralayıcı tarafından gönderilen verileri kriptografik hesaplamalar yoluyla aktif ve ucuz bir şekilde doğrular.

(İyimser Toplama işlemi yöntemi)

(ZK Toplama işlem yöntemi)

Bu makale, Optimistic Rollup'ın önde gelen projesi Arbitrum One'a tüm sistemi tüm yönleriyle kapsayan derinlemesine bir giriş sağlar. Dikkatlice okuduktan sonra Arbitrum ve İyimser Toplama/OPR hakkında derinlemesine bilgi sahibi olacaksınız.

Arbitrumun Temel Bileşenleri ve İş Akışı

Temel Sözleşmeler:

Arbitrum'daki en önemli sözleşmeler arasında SequencerInbox, DelayedInbox, L1 Ağ Geçitleri, L2 Ağ Geçitleri, Giden Kutusu, RollupCore, Bridge vb. yer alır. Bunlar aşağıdaki bölümlerde ayrıntılı olarak açıklanacaktır.

Sıralayıcı:

Sıralayıcı, kullanıcı işlemlerini alır, sıralar, işlem sonuçlarını hesaplar ve hızlı bir şekilde (genellikle <1s) makbuzları kullanıcılara geri gönderir. Kullanıcılar L2'deki işlemlerini genellikle birkaç saniye içinde görerek Web2 platformlarına benzer bir deneyim sağlar.

Eş zamanlı olarak sıralayıcı, Ethereum zincir dışı altında en son oluşturulan L2 Bloğunu anında yayınlar. Herhangi bir Layer2 düğümü bu L2 Bloklarını eşzamansız olarak alabilir. Ancak bu L2 Bloklarının bu noktada kesinliği yoktur ve sıralayıcı tarafından geri alınabilmektedir.

Her birkaç dakikada bir sıralayıcı, sıralanan L2 işlem verilerini sıkıştırır, gruplar halinde toplar ve verilerin kullanılabilirliğini ve Toplama protokolünün çalışmasını sağlamak için bunu Katman1'deki SequencerInbox sözleşmesine gönderir. Genellikle Katman1'e gönderilen L2 verileri geri alınamaz ve nihai determinizme sahip olabilir.

Yukarıdaki süreçten özetleyebiliriz: Layer2'nin kendi düğüm ağı vardır, ancak bu düğümlerin sayısı azdır ve genel olarak halka açık zincirler tarafından yaygın olarak kullanılan bir konsensüs protokolü bulunmadığından çok zayıf bir güvenlik sağlar. Veri yayınlamanın güvenilirliğini ve durum geçişlerinin etkinliğini sağlamak için Ethereum'a güvenmek zorundadır. seks.

Arbitrum Toplama Protokolü:

Bu, Toplama zincirinin RBlock bloğunun yapısını, zincirin devam yöntemini, RBlock'un serbest bırakılmasını ve meydan okuma modu sürecini tanımlayan bir dizi sözleşmedir. Burada bahsedilen Toplama zincirinin, herkesin anladığı Katman 2 defteri değil, sahtekarlığa karşı koruma mekanizmasını uygulamak için Arbitrum One tarafından bağımsız olarak kurulan soyut bir "zincir benzeri veri yapısı" olduğunu unutmayın.

Bir RBlock, birden fazla L2 bloğunun sonuçlarını içerebilir ve veriler de çok farklıdır. Veri varlığı RBlock, RollupCore'daki bir dizi sözleşmede depolanır. Bir RBlock ile ilgili bir sorun varsa Doğrulayıcı, RBlock'u gönderen kişiye itiraz edecektir.

Doğrulayıcı:

Arbitrum'un doğrulayıcı düğümleri aslında Katman 2 tam düğümlerinin özel bir alt kümesidir ve şu anda bir beyaz listeye erişime sahiptir.

Doğrulayıcı, sıralayıcı tarafından SequencerInbox sözleşmesine gönderilen işlem kümesini temel alarak yeni bir RBlock (Toplama bloğu, aynı zamanda iddia olarak da adlandırılır) oluşturur, ayrıca mevcut Toplama zincirinin durumunu izler ve sıralayıcı tarafından gönderilen yanlış verileri sorgular.

Active Validator'ın ETH zincirindeki varlıkları önceden stake etmesi gerekiyor. Bazen buna Staker da diyoruz. Stack yapmayan Layer 2 node’lar da Rollup’ın çalışma dinamiklerini takip edip kullanıcılara anormal alarmlar gönderebilseler de ETH zincirindeki sıralayıcının gönderdiği hata verilerine doğrudan müdahale edemiyorlar.

Meydan okumak:

Temel adımlar, birden fazla etkileşimli segmentasyon turu ve tek adımlı kanıt olarak özetlenebilir. Segmentasyon sürecinde, zorlu taraflar, sorunlu işlem kodu talimatlarını ayrıştırıp doğrulamayı gerçekleştirene kadar ilk önce sorunlu işlem verileri üzerinde birden fazla segmentasyon turu gerçekleştirir. "Birden fazla bölümleme turu - tek adımlı kanıt" paradigması, Arbitrum geliştiricileri tarafından sahtekarlığa karşı kanıtın en tasarruflu uygulaması olarak kabul edilir. Tüm bağlantılar sözleşme kontrolü altındadır ve hiçbir taraf hile yapamaz.

Mücadele dönemi:

OP Toplamasının iyimser doğasından dolayı, her RBlock zincire gönderildikten sonra sözleşme aktif olarak kontrol etmez ve doğrulayıcının sahtecilik yapması için bir pencere süresi bırakır. Bu pencere dönemi, Arbitrum One ana ağında 1 hafta süren sorgulama dönemidir. Mücadele süresi sona erdikten sonra RBlock nihayet onaylanacak. Yalnızca blok içerisinde L2'den L1'e iletilen ilgili mesajlar (resmi köprü üzerinden gerçekleştirilen para çekme işlemleri gibi) yayınlanabilir.

ArbOS, Geth, WAVM:

Arbitrum tarafından kullanılan sanal makineye Geth ve ArbOS'u içeren AVM adı verilir. Geth, Ethereum'da en yaygın kullanılan istemci yazılımıdır ve Arbitrum bu yazılımda hafif değişiklikler yapmıştır. ArbOS, ağ kaynağı yönetimi, L2 blokları oluşturma, EVM ile çalışma vb. gibi L2 ile ilgili tüm özel işlevlerden sorumludur. İkisinin birleşimini Arbitrum'un kullandığı sanal makine olan Native AVM olarak görüyoruz. WAVM, AVM kodunun Wasm'da derlenmesinin sonucudur. Arbitrum sınama sürecinde son "tek adımlı kanıt" WAVM talimatını doğrular.

Burada yukarıdaki bileşenler arasındaki ilişkiyi ve iş akışını temsil etmek için aşağıdaki şekli kullanabiliriz:

L2'de işlem yaşam döngüsü

L2'deki bir işlemin işlem akışı aşağıdaki gibidir:

1. Kullanıcılar işlem talimatlarını sıralayıcıya gönderir.

2. Sıralayıcı öncelikle dijital imzalara ve diğer verilere işlenecek işlemleri doğrular, geçersiz işlemleri ortadan kaldırır, sıralama ve hesaplamaları gerçekleştirir.

3. Sıralayıcı, işlem makbuzunu kullanıcıya (genellikle çok hızlı) gönderir; bu, yalnızca sıralayıcının ETH zinciri altında gerçekleştirdiği "ön işlemedir". Yumuşak Kesinlik durumundadır ve güvenilir değildir. Ancak sıralayıcıya güvenen kullanıcılar (çoğu kullanıcı), işlemin tamamlandığı ve geri alınmayacağı konusunda iyimser olabilirler.

4. Sıralayıcı, önceden işlenmiş orijinal işlem verilerini yüksek oranda sıkıştırır ve bunu bir Toplu İş içinde kapsüller.

5. Ara sıra (veri hacmi ve ETH tıkanıklığı gibi faktörlerden etkilenen) sıralayıcı, işlem gruplarını L1'deki Sıralayıcı Gelen Kutusu sözleşmesine yayınlayacaktır. Bu noktada işlemin Kesin Nihailiğe sahip olduğu düşünülebilir.

Sıralayıcı Gelen Kutusu Sözleşmesi

Sözleşme, veri kullanılabilirliğini sağlamak için sıralayıcı tarafından gönderilen işlem grubunu alacaktır. Buna daha derinden bakacak olursak, Sequencer Inbox'taki toplu veri, Layer2'nin işlem giriş bilgilerini tamamen kaydediyor. Sıralayıcı kalıcı olarak kapalı olsa bile, herkes toplu kayıtlara dayanarak Katman 2'nin mevcut durumunu geri yükleyebilir ve hatalı/çalışan sıralayıcıyı değiştirebilir.

Bunu fiziksel olarak anlamak için, gördüğümüz L2, SequencerInbox'taki partinin sadece projeksiyonudur ve ışık kaynağı STF'dir. Işık kaynağı STF kolayca değişmediğinden, gölgenin şekli yalnızca nesne gibi davranan parti tarafından belirlenir.

Sıralayıcı Gelen Kutusu sözleşmesine hızlı kutu denir. Sıralayıcı, önceden işlenmiş işlemleri kendisine özel olarak gönderir ve yalnızca sıralayıcı ona veri gönderebilir. İlgili hızlı kutu, yavaş kutu Geciktirici Gelen Kutusu'dur ve işlevi sonraki süreçte açıklanacaktır.

Doğrulayıcı, Sıralayıcı Gelen Kutusu sözleşmesini her zaman izleyecektir. Sıralayıcı sözleşmeye bir parti yayınladığında, zincir üzerinde bir olay üretilecektir. Doğrulayıcı bu olayın meydana geldiğini tespit ettikten sonra toplu verileri indirecektir. Yerel yürütmenin ardından, ETH zincirindeki Toplama protokol sözleşmesine RBlock verilecek.

Arbitrum'un köprü sözleşmesinde, yeni gönderilen L2 grubunun yanı sıra yavaş Gelen Kutusu'nda yeni alınan işlemlerin sayısını ve bilgilerini kaydeden, akümülatör adı verilen bir parametre bulunur.

（Sıralayıcı, partileri sürekli olarak Sıralayıcı Gelen Kutusu'na gönderir）

（Partinin spesifik bilgileri; veri alanı Toplu Veriye karşılık gelir. Verinin bu bölümünün boyutu çok büyük ve ekran görüntüsü tam olarak görüntülenmiyor.)

SequencerInbox sözleşmesinin iki ana işlevi vardır:

Origin()'den Sıralayıcı L2Batch'i ekleyin

Sıralayıcı, Toplu verileri Sıralayıcı Inox sözleşmesine göndermek için her seferinde bu işlevi çağıracaktır.

Dahil Etmeyi Zorla()

Bu işlev herkes tarafından çağrılabilir ve sansüre dayanıklı işlemleri uygulamak için kullanılır. Bu işlevin nasıl etki gösterdiği daha sonra Gecikmeli Gelen Kutusu sözleşmesinden bahsettiğimizde ayrıntılı olarak açıklanacaktır.

Yukarıdaki iki işlev, köprü sözleşmesindeki akümülatör parametresini güncellemek için 'bridge.enqueueSequencerMessage()' öğesini çağıracaktır.

Gaz fiyatlandırması

Açıkçası L2 işlemleri ücretsiz olamaz çünkü bu DoS saldırılarına yol açacaktır. Buna ek olarak, L2 sıralayıcısının işletme maliyetleri vardır ve L1'e veri göndermenin ek yükü olacaktır. Kullanıcı Layer 2 ağı içerisinde bir işlem başlattığında gas ücret yapısı şu şekilde olacaktır:

Layer1 kaynaklarının kullanılmasından kaynaklanan veri yayınlama maliyetleri

Bu maliyet esas olarak sıralayıcı tarafından gönderilen partilerden gelir (her partinin birçok kullanıcı işlemi vardır) ve maliyet sonuçta işlem başlatıcıları arasında eşit olarak paylaşılır. Veri sürümü tarafından oluşturulan ücret fiyatlandırma algoritması dinamiktir ve sıralayıcı, son kar ve zarar durumuna, parti büyüklüğüne ve mevcut Ethereum gas fiyatına göre fiyatlandıracaktır.

Katman 2 kaynaklarını kullanan kullanıcıların maruz kaldığı maliyet

Sistemin stabil çalışmasını sağlamak amacıyla TPS için bir gaz limiti oluşturulmuştur (şu anda Arbitrum One'da 7 milyon). Hem L1 hem de L2 için gaz yönlendirme fiyatları ArbOS tarafından izlenmekte ve ayarlanmaktadır ve formül şimdilik burada ayrıntılı olarak açıklanmamaktadır.

Spesifik gas fiyatı hesaplama süreci nispeten karmaşık olsa da kullanıcıların bu ayrıntıları bilmesine gerek yok ve Toplama işlem ücretlerinin ETH ana ağına göre çok daha ucuz olduğunu açıkça hissedebiliyorlar.

İyimser dolandırıcılık kanıtı

Yukarıdakileri hatırlayacak olursak, L2 aslında sıralayıcı tarafından hızlı kutuya gönderilen işlem girişi grubunun yalnızca projeksiyonudur, yani:

İşlem Girişleri -> STF -> Durum Çıkışları. Giriş belirlendi ve STF değişmedi, dolayısıyla çıkış sonucu da belirlendi. Dolandırıcılık önleme sistemi ve Arbitrum Rollup protokolü, çıkış durumu kökünü RBlock (diğer adıyla iddia) biçiminde L1'e yayınlayan ve bunun üzerinde iyimser kanıt gerçekleştiren bir sistemdir.

L1'de sıralayıcı tarafından yayınlanan giriş verileri ve doğrulayıcı tarafından yayınlanan çıkış durumu vardır. Dikkatlice düşünelim: Layer 2'nin durumunu zincire yayınlamak gerekli mi?

Girdi, çıktıyı tamamen belirlediğinden ve girdi verileri herkes tarafından görülebildiğinden, çıktı sonuç durumunu göndermek gereksiz mi görünüyor? Ancak bu fikir, L1 ve L2 sistemleri arasındaki gerçek durum çözümü ihtiyacını göz ardı eder, yani L2'den L1'e çekilme davranışı durumun kanıtını gerektirir.

Toplama oluştururken temel fikirlerden biri, L1'in yüksek maliyetinden kaçınmak için bilgi işlem ve depolamanın çoğunu L2'ye koymaktır. Bu, L1'in L2'nin durumunu bilmediği, yalnızca L2'ye yardımcı olduğu anlamına gelir. Sıralayıcı, tüm işlemlerin giriş verilerini yayınlar ancak L2'nin durumunun hesaplanmasından sorumlu değildir.

Para çekme davranışı esasen L1 sözleşmesinden ilgili fonların kilidini açmak, bunu kullanıcının L1 hesabına aktarmak veya L2 tarafından verilen çapraz zincir mesajını takip ederek diğer şeyleri tamamlamaktır.

Bu noktada Layer1 sözleşmesi şu soruyu soracaktır: Layer 2'deki durumunuz nedir ve devredileceğini beyan ettiğiniz varlıkların gerçekten size ait olduğunu nasıl kanıtlayabilirsiniz? Şu anda kullanıcının ilgili Merkle Kanıtı vb.'ni sağlaması gerekir.

Dolayısıyla, eğer geri çekme fonksiyonu olmayan bir Rollup kurarsak, teorik olarak L1'e durumu senkronize etmemek mümkündür ve sahtekarlık kanıtı gibi durum geçirmez bir sisteme gerek yoktur (her ne kadar başka sorunlara neden olsa da). Ancak gerçek uygulamalarda bunun mümkün olmadığı açıktır.

İyimser kanıt olarak adlandırılan yöntemde sözleşme, L1'e sunulan çıktı durumunun doğru olup olmadığını kontrol etmez, ancak iyimser bir şekilde her şeyin doğru olduğuna inanır. İyimser kanıt sistemi, herhangi bir zamanda en az bir dürüst Doğrulayıcının bulunduğunu varsayar. Yanlış bir durum ortaya çıkarsa, sahtekarlık kanıtı yoluyla bu duruma itiraz edilecektir.

Bu tasarımın avantajı, gaz israfını önlemek için L1'e verilen her RBlock'un aktif olarak doğrulanmasına gerek olmamasıdır. Aslında OPR için her iddiayı doğrulamak gerçekçi değildir çünkü her Rblock bir veya daha fazla L2 bloğu içerir ve her işlemin L1 üzerinde yeniden yürütülmesi gerekir. L2 işlemlerinin doğrudan L1 üzerinde yürütülmesinden hiçbir farkı yoktur, bu da Layer 2 genişlemesini anlamsız hale getirir.

ZK Proof'un kısa olması nedeniyle ZKR'de bu sorun yoktur. Yalnızca çok küçük bir Kanıtı doğrulaması gerekir ve Kanıta karşılık gelen çok sayıda işlemin yürütülmesine aslında gerek yoktur. Bu nedenle ZKR iyimser çalışmıyor. Durum her açıklandığında, matematiksel doğrulama için bir Doğrulayıcı sözleşmesi olacaktır.

Dolandırıcılık kanıtı, sıfır bilgi kanıtı kadar özlü olamasa da Arbitrum, "çok aşamalı segmentasyon-tek adımlı kanıt" sıra tabanlı etkileşimli bir süreç kullanır. Sonuçta kanıtlanması gereken yalnızca tek bir sanal makine işlem kodudur ve maliyeti nispeten düşüktür.

Toplama protokolü

Challengeları başlatmak ve ispatları başlatmak için öncelikle giriş kısmına yani Rollup protokolünün nasıl çalıştığına bir göz atalım.

Rollup protokolünün temel sözleşmesi RollupProxy.sol'dur, veri yapısının tutarlı olmasını sağlarken nadir bir ikili aracı yapısı kullanır. Bir aracı, Scan gibi araçlar tarafından iyi bir şekilde ayrıştırılamayan RollupUserLogic.sol ve RollupAdminLogic.sol'un iki uygulamasına karşılık gelir.

Ayrıca, ChallengeManager.sol sözleşmesi zorlukların yönetilmesinden sorumludur ve OneStepProver serisi sözleşmeler sahtekarlık kanıtlarını belirlemek için kullanılır.

(Kaynak: L2BEAT resmi web sitesi)

Bu, RollupProxy'de, aşağıdaki şekildeki kutular olan farklı Doğrulayıcılar tarafından gönderilen bir dizi RBlock'un (diğer adıyla iddiaların) kaydedilmesini gösterir: Yeşil onaylı, mavi onaylanmamış, sarı sahte.

RBlock, son RBlock'tan bu yana bir veya daha fazla L2 bloğunun yürütülmesinden sonraki son durumu içerir. Bu RBlock'lar resmi bir Toplama Zinciri oluşturur (L2 defterinin kendisinin farklı olduğunu unutmayın). İyimser koşullar altında, bu Toplama Zincirinin çatalları olmamalıdır çünkü çatal, Doğrulayıcının çakışan Toplama Blokları gönderdiği anlamına gelir.

Bir iddiayı önermek veya kabul etmek için, doğrulayıcının öncelikle iddia için belirli bir miktarda ETH stake etmesi ve Staker olması gerekir. Bu şekilde, bir itiraz/sahtekarlık kanıtı ortaya çıktığında, kaybeden tarafın teminatı kesilecektir. Doğrulayıcının dürüst davranışını sağlamanın ekonomik temeli budur.

Resmin sağ alt köşesindeki 111 numaralı mavi blok, 104 numaralı ana blok (sarı) yanlış olduğundan eninde sonunda kesilecektir.

Ek olarak, doğrulayıcı A, 106 No'lu Toplama Bloğu'nu önerdi, ancak B buna karşı çıktı ve itiraz etti.

B, mücadeleyi başlattıktan sonra ChallengeManager sözleşmesi, mücadele adımlarının segmentasyonunun doğrulanmasından sorumlu olacaktır:

1. Segmentasyon, her iki tarafın da sırayla etkileşimde bulunduğu bir süreçtir. Bir taraf, belirli bir Toplama Blokunda yer alan geçmiş verileri bölümlere ayırır ve diğer taraf, veri parçasının hangi bölümünün sorunlu olduğuna işaret eder; bu, kapsamı sürekli ve kademeli olarak daraltan ikilemi (aslında N/K) benzer bir süreçtir.

2. Bundan sonra, sorunlu işlemi ve sonucu bulmaya devam edebilir ve ardından bunu işlemdeki tartışmalı makine talimatına göre daha da alt bölümlere ayırabilirsiniz.

3. ChallengeManager sözleşmesi yalnızca orijinal verileri bölümlere ayırdıktan sonra oluşturulan "veri parçalarının" geçerli olup olmadığını kontrol eder.

4. Meydan okuyan ve sorgulanan taraf, sorgulanacak makine talimatını bulduğunda, meydan okuyan kişi 'oneStepProveExecution()' işlevini çağırır ve bu makine komutunun yürütme sonucuyla ilgili bir sorun olduğunu kanıtlamak için tek adımlı bir sahtekarlık kanıtı gönderir.

Tek adımlı kanıt

Tek adımlı kanıt, tüm Arbitrum dolandırıcılık kanıtının özüdür. Tek adımlı kanıtın özellikle neyi kanıtladığına bir göz atalım.

Bu öncelikle WAVM'yi anlamayı gerektirir. Wasm Arbitrum Sanal Makinesi, ArbOS modülü ve Geth (Ethereum istemcisi) çekirdek modülü tarafından derlenen bir sanal makinedir. L2, L1'den çok farklı olduğundan orijinal Geth çekirdeğinin hafifçe değiştirilmesi ve ArbOS ile çalışması gerekiyordu.

Dolayısıyla L2'deki durum geçişi aslında ArbOS+Geth Core'un ortak çalışmasıdır.

Arbitrum'un düğüm istemcisi (sıralayıcı, doğrulayıcı, tam düğüm vb.), yukarıda bahsedilen ArbOS+Geth Core işleme programını, düğüm ana bilgisayarının doğrudan işleyebileceği yerel makine kodunda derler (x86/ARM/PC/Mac/vb. için).

Derlemeden sonra elde edilen hedef dili Wasm olarak değiştirirseniz, dolandırıcılık kanıtları oluştururken doğrulayıcı tarafından kullanılan WAVM'yi alırsınız ve tek adımlı kanıtı doğrulamaya yönelik sözleşme aynı zamanda WAVM sanal makinesinin işlevlerini de simüle eder.

Peki dolandırıcılık kanıtları oluştururken neden Wasm bayt kodunda derlenmesi gerekiyor? Bunun ana nedeni, tek adımlı dolandırıcılık kanıtı sözleşmesini doğrulamak için, belirli bir talimat setlerini işleyebilen bir sanal makine VM'sini simüle etmek için Ethereum akıllı sözleşmesinin kullanılmasının gerekli olmasıdır ve WASM'nin simülasyonu uygulamanın kolay olmasıdır. sözleşme.

Ancak WASM, Yerel makine kodundan biraz daha yavaş çalışır, dolayısıyla Arbitrum'un düğümleri/sözleşmeleri WAVM'yi yalnızca dolandırıcılık kanıtlarını oluştururken ve doğrularken kullanacaktır.

Etkileşimli segmentasyonların önceki turlarından sonra, tek adımlı kanıt nihayet WAVM komut setindeki tek adımlı talimatı kanıtladı.

Aşağıdaki kodda görüldüğü gibi OneStepProofEntry öncelikle ispatlanacak komutun işlem kodunun hangi kategoriye ait olduğunu belirler ve daha sonra tek adımlı talimatın programa geçmesi için ilgili Mem, Math vb. kanıtlayıcıları çağırır. kanıt sözleşmesi.

Hash'tan sonraki nihai sonuç ChallengeManager'a döndürülecektir. Eğer karma, Toplama Bloğunda kaydedilen talimat işleminden sonraki karma ile tutarsızsa, meydan okuma başarılı olur. Tutarlı olmaları, Toplama Bloğunda kaydedilen bu talimatın yürütme sonucunda herhangi bir sorun olmadığı ve sorgulamanın başarısız olduğu anlamına gelir.

2. bölümde, Arbitrum'u ve hatta Katman2 ile Katman1 arasında zincirler arası mesajlaşma/köprü oluşturma işlevlerini yöneten sözleşme modülünü analiz edeceğiz ve gerçek bir Katman2'nin sansüre karşı direnci nasıl elde etmesi gerektiğini daha da açıklığa kavuşturacağız.

Yasal Uyarı:

1. Bu makale [WeChat]'ten yeniden basılmıştır. Tüm telif hakları orijinal yazara [Luo Benben] aittir. Bu yeniden basıma itirazlarınız varsa lütfen Gate Learn ekibiyle iletişime geçin; onlar konuyu hemen halledeceklerdir.
2. Sorumluluk Reddi: Bu makalede ifade edilen görüş ve görüşler yalnızca yazara aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirileri Gate Learn ekibi tarafından yapılır. Aksi belirtilmedikçe tercüme edilen makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.