"Arbitrum'un Eski Arbitrum Teknik Elçisi Tarafından Yorumlanan Bileşen Yapısı (Bölüm 1) " adlı önceki makalede, Arbitrum'daki sıralayıcı, doğrulayıcı, sıralayıcı gelen kutusu sözleşmesi, toplama bloğu dahil olmak üzere temel bileşenlerin rollerini tanıtmıştık. etkileşimli olmayan dolandırıcılık kanıtları. Bugünkü yazımızda Arbitrum'un temel bileşenlerinde çapraz zincir mesaj aktarımı ve sansür karşıtı işlemlere giriş ile ilgili bileşenleri açıklamaya odaklanacağız.

Ana Metin: Önceki yazılarımızda Sıralayıcı Gelen Kutusu sözleşmesinin, Katman 1'de sıralayıcı tarafından yayınlanan işlem veri yığınlarını almak için özel olarak tasarlandığından bahsetmiştik. Aynı zamanda Sıralayıcı Gelen Kutusu'nun “hızlı kutu” olarak da adlandırıldığını, bunun aksine “yavaş kutu” veya Gecikmeli Gelen Kutusu'nun (Gelen Kutusu olarak anılacaktır) bulunduğunu belirtmiştik. Aşağıda Gecikmeli Gelen Kutusu da dahil olmak üzere zincirler arası mesaj aktarımıyla ilgili bileşenlerin ayrıntılı bir yorumunu sunacağız.

Çapraz zincir ve köprüleme ilkesi

Zincirler arası işlemler, L1'den L2'ye (para yatırma) işlemler ve L2'den L1'e (para çekme) işlemlere bölünebilir. Buradaki "para yatırma" ve "çekme" terimlerinin mutlaka varlıkların zincirler arası transferini içermeyebileceğini unutmamak önemlidir; varlıkları doğrudan aktarmadan ileti aktarımına başvurabilirler. Bu nedenle, bu terimler yalnızca zincirler arası bağlantılı eylemlerin iki yönünü temsil eder.

Saf L2 işlemleriyle karşılaştırıldığında çapraz zincir işlemleri, iki farklı sistem (L1 ve L2) arasında bilgi alışverişini içerir ve bu da süreci daha karmaşık hale getirir.

Ek olarak, zincirler arası eylemlerden bahsettiğimizde, bu genellikle birleşik bir modelde zincirler arası bir köprü kullanarak tamamen ilgisiz iki ağ arasında geçiş anlamına gelir. Bu tür zincirler arası operasyonların güvenliği, zincirler arası köprünün operatörüne bağlıdır ve tarihsel olarak, tanık temelli çapraz zincirli köprülerde hırsızlık olayları sıklıkla yaşanmıştır.

Öte yandan, Rollup ile ETH ana ağı arasındaki zincirler arası eylemler, yukarıda bahsedilen zincirler arası işlemlerden temel olarak farklıdır. Bunun nedeni, Katman2'nin durumunun, Katman1'e kaydedilen veriler tarafından belirlenmesidir. Resmi Rollup çapraz zincir köprüsünü kullandığınız sürece, operasyonları yapısal olarak güvenlidir.

Bu, kullanıcının bakış açısından bağımsız bir zincir olarak görünen Rollup'ın özünü vurgular, ancak gerçekte "Katman2" olarak adlandırılan şey, Rollup tarafından kullanıcılara açılan hızlı bir görüntüleme penceresidir ve gerçek zincir benzeri yapısıdır. hala Katman1'e kayıtlıdır. Dolayısıyla L2'yi yarım zincir veya "Katman1'de oluşturulmuş bir zincir" olarak değerlendirebiliriz.

Yeniden denenebilir olanlar

Zincirler arası işlemlerin eşzamansız ve atomik olmadığını lütfen unutmayın. Zincirler arası işlemlerde, tek zincirdeki işlemlerden farklı olarak tek zincirde bir işlemin tamamlanması ve bir işlem sonrasında sonucun onaylanması mümkün değildir. Ayrıca karşı tarafta belirli bir zamanda belirli bir şeyin olacağının garantisi de yoktur. Bu nedenle zincirler arası işlemler bazı yumuşak sorunlar nedeniyle başarısız olabilir, ancak yeniden denenebilir biletler gibi uygun tekniklerin kullanılmasıyla fonların sıkışması gibi zor sorunlar yaşanmayacaktır.

Yeniden denenebilir biletler, hem ETH hem de ERC20 para yatırma işlemleri için geçerli olan, para yatırma sırasında Arbitrum resmi köprüsünde kullanılan temel araçlardır. Yaşam döngüsü üç adımdan oluşur:

1. Biletin L1'e gönderilmesi: Bir para yatırma bileti oluşturmak ve göndermek için Gecikmeli Gelen Kutusu sözleşmesindeki 'createRetryableTicket()' yöntemini kullanın.
2. L2'de otomatik ödeme: Çoğu durumda sıralayıcı, ek manuel işlemlere gerek kalmadan kullanıcı için bileti otomatik olarak kullanabilir.
3. L2'de manuel yakıt kullanımı: L2'de gaz fiyatlarında ani artış olması gibi bazı ekstrem durumlarda, biletteki ön ödemeli yakıt yetersizse otomatik kullanım gerçekleşemez. Bu senaryoda kullanıcının manuel müdahalesi gereklidir. Otomatik ödeme başarısız olursa kullanıcının bileti 7 gün içinde manuel olarak kullanması gerektiğini unutmamak önemlidir; aksi takdirde bilet ya silinir (kalıcı para kaybına yol açar) ya da kullanıcının, biletin depolama alanını yenilemek için belirli bir ücret ödemesi gerekir.

Ayrıca Arbitrum resmi köprüsündeki para çekme işlemiyle ilgili olarak, para yatırma işlemiyle karşılaştırıldığında süreçte belirli bir simetrik benzerlik olsa da yeniden denenebilir bilet kavramı yoktur. Bu, Toplama protokolünün perspektifinden anlaşılabilir ve bazı farklılıklar vurgulanabilir:

• EVM'de zamanlayıcı veya otomasyon bulunmadığından para çekme işlemi sırasında otomatik ödeme yapılmaz. L2'de otomatik ödeme uygulanabilir ve sıralayıcı tarafından kolaylaştırılır. Bu nedenle, L1'deki kullanıcıların varlıklarını geri talep etmek için Giden Kutusu sözleşmesiyle manuel olarak etkileşimde bulunmaları gerekir.
• Para çekme işlemleri sırasında bilet kullanım süresinin dolması sorunu yaşanmaz. İtiraz süresi geçtiği sürece kullanıcılar, varlıklarını istedikleri zaman talep edebilir.

ERC-20 Varlıkları için Çapraz Zincir Ağ Geçidi

ERC-20 varlıklarının çapraz zincirlenmesi karmaşıktır. Birkaç soru üzerinde düşünebiliriz:

• L1'de konuşlandırılan bir jetonun L2'de nasıl dağıtılacağı?
• L2'ye karşılık gelen sözleşmenin önceden manuel olarak dağıtılması gerekiyor mu, yoksa sistem, geçiş yapmış ancak henüz bir sözleşme dağıtmamış tokenler için varlık sözleşmelerini otomatik olarak dağıtabilir mi?
• L1'deki ERC-20 varlıkları için L2'deki ilgili sözleşme adresi nedir? L1 ile tutarlı olmalı mı?
• L2'de yerel olarak verilen tokenlar L1'e nasıl çapraz zincirlenebilir?
• Ayarlanabilir miktarlara sahip yeniden temel tokenlar ve kendi kendine büyüyen faiz getiren tokenlar gibi özel işlevlere sahip tokenlar nasıl çapraz zincirlenebilir?

Bu soruların hepsine cevap vermeyeceğiz çünkü bunlar açıklanamayacak kadar karmaşık. Bu sorular yalnızca ERC20 çapraz zincirinin karmaşıklığını göstermek için kullanılır.

Şu anda birçok ölçeklendirme çözümü, çeşitli karmaşık sorunları ve sınır koşullarını önlemek için beyaz liste ve manuel liste çözümlerini kullanıyor.

Arbitrum, ERC20 çapraz zincirinin yapışma sorunlarının çoğunu çözmek için Gateway sistemini kullanıyor. Aşağıdaki özelliklere sahiptir:

• Ağ geçidi bileşenleri L1 ve L2'de çiftler halinde görünür.
• Ağ Geçidi Yönlendiricisi, Token L1<->Token L2 arasındaki adres eşlemesinin sürdürülmesinden sorumludur. Ayrıca, bazı belirteçler<->bazı ağ geçitleri arasındaki eşleme.
• Ağ Geçidinin kendisi, ERC20 köprüleme sorunlarının farklı türlerini ve işlevlerini çözmek için Standart ERC20 ağ geçidi, Genel-özel ağ geçidi, Özel ağ geçidi vb. olarak bölünebilir.

Ağ geçidini özelleştirmenin gerekliliğini göstermek için örnek olarak nispeten basit WETH çapraz zincirini ele alalım.

WETH, ETH'nin ERC20 eşdeğeridir. Ana para birimi olarak Ether, birçok dApp'te karmaşık işlevleri uygulayamaz, bu nedenle bir ERC20 eşdeğerine ihtiyaç vardır. Bir miktar ETH'yi WETH sözleşmesine aktarın, bunlar sözleşmede kilitlenecek ve aynı miktarda WETH üretilecektir.

Aynı şekilde WETH de yakılıp ETH çekilebilir. Açıkçası dolaşımdaki WETH ile kilitli ETH'nin oranı her zaman 1:1'dir.

Şimdi WETH'yi doğrudan L2'ye çapraz zincirlersek bazı garip sorunlarla karşılaşacağız:

• WETH'yi L2'de ETH'ye açmak imkansızdır çünkü L2'de kilitlemeye karşılık gelen bir ETH yoktur.
• Sarma işlevi kullanılabilir, ancak bu yeni oluşturulan WETH, L1'e geri çaprazlanırsa, L1 ve L2'deki WETH sözleşmeleri "simetrik" olmadığından L1'de ETH'ye ayrıştırılamazlar.

Açıkçası bu WETH'in tasarım ilkelerini ihlal ediyor. Bu nedenle, WETH çapraz zincirlendiğinde, ister yatırma ister çekme olsun, önce ETH'ye sarılmalı, sonra diğer tarafa geçilmeli ve daha sonra WETH'e sarılmalıdır. WETH Ağ Geçidinin rolü budur.

Aynı şey, zincirler arası bir ortamda düzgün çalışması için daha karmaşık ve dikkatli bir şekilde tasarlanmış bir Ağ Geçidi gerektiren, daha karmaşık mantığa sahip diğer tokenler için de geçerlidir. Arbitrum'un özel Ağ Geçidi, sıradan Ağ Geçidinin zincirler arası iletişim mantığını devralır ve geliştiricilerin, çoğu ihtiyacı karşılayabilecek şekilde token mantığıyla ilgili zincirler arası davranışı özelleştirmesine olanak tanır.

Gecikmeli Gelen Kutusu

Sıralayıcı Gelen Kutusu olarak bilinen hızlı gelen kutusunun karşılığı, yavaş gelen kutusudur (tam adı Gecikmeli Gelen Kutusu). Neden hızlı ve yavaş arasında ayrım yapmalısınız? Bunun nedeni, hızlı gelen kutusunun, sıralayıcı tarafından yayınlanan L2 işlem gruplarını almaya ayrılmış olması ve sıralayıcı tarafından L2 ağı içerisinde önceden işlenmeyen herhangi bir işlemin, hızlı gelen kutusu sözleşmesinde görünmemesidir.

Yavaş gelen kutusunun ilk işlevi L1'den L2'ye para yatırma sürecini yönetmektir. Kullanıcılar yavaş gelen kutusu aracılığıyla para yatırma işlemini başlatır ve sıralayıcı bunu gözlemlediğinde L2'ye yansır. Sonunda, bu yatırma kaydı sıralayıcı tarafından L2 işlem dizisine dahil edilir ve hızlı gelen kutusu sözleşmesine (Sıralayıcı Gelen Kutusu) gönderilir.

Bu senaryoda, kullanıcıların para yatırma işlemlerini doğrudan hızlı gelen kutusuna (Sıralayıcı Gelen Kutusu) göndermeleri uygun değildir çünkü hızlı gelen kutusuna gönderilen işlemler, Katman2'deki normal işlem sıralamasını bozabilir, dolayısıyla sıralayıcının çalışmasını etkileyebilir.

Yavaş gelen kutusunun ikinci işlevi sansüre dayanıklıdır. Yavaş gelen kutusu sözleşmesine doğrudan gönderilen işlemler genellikle sıralayıcı tarafından 10 dakika içinde hızlı gelen kutusuna toplanır. Ancak sıralayıcı isteğinizi kötü niyetli bir şekilde görmezden gelirse, yavaş gelen kutusunun zorunlu bir ekleme özelliği vardır:

Bir işlem Gecikmeli Gelen Kutusu'na gönderilirse ve 24 saat sonra sıralayıcı tarafından işlem sırasına dahil edilmezse kullanıcılar, Katman1'de zorla dahil etme işlevini manuel olarak tetikleyebilir. Bu eylem, sıralayıcı tarafından göz ardı edilen işlemlerin hızlı gelen kutusunda (Sıralayıcı Gelen Kutusu) zorla toplanmasına neden olur. Daha sonra tüm Arbitrum One düğümleri tarafından tespit edilecekler ve Layer2 işlem sırasına zorla dahil edilecekler.

Hızlı gelen kutusundaki verilerin L2'nin geçmiş veri varlığını temsil ettiğinden az önce bahsetmiştik. Bu nedenle, kötü niyetli sansür durumlarında, yavaş gelen kutusunun kullanılması, işlem talimatlarının en sonunda L2 defterine dahil edilmesini sağlar ve Katman2'den kaçmak için zorla para çekme gibi senaryoları kapsar.

Bundan, herhangi bir işlem yönü ve seviyesi için sıralayıcının sizi kalıcı olarak sansürleyemeyeceği görülebilir.

Yavaş gelen kutusunun (Gelen Kutusu) birkaç temel işlevi:

• mevduatETH(): ETH yatırmanın en basit işlevi.
• createRetryableTicket(): ETH, ERC20 ve mesajları yatırmak için kullanılır. DepozitoETH()'ye kıyasla daha fazla esneklik sunar ve para yatırma işleminden sonra L2'deki alıcı adresi gibi spesifikasyonlara izin verir.
• ForceInclusion(): Zorla dahil etme özelliği olan bu işlev herkes tarafından çağrılabilir. İşlev, yavaş gelen kutusu sözleşmesine gönderilen bir işlemin 24 saat sonra işlenip işlenmediğini doğrular. Koşullar karşılanırsa, mesajı güçlü bir şekilde içerir.

Ancak zorla dahil etme fonksiyonunun aslında hızlı gelen kutusu sözleşmesinde yer aldığını unutmamak önemlidir. Anlaşılması kolay olsun diye yavaş gelen kutusuyla birlikte anlattık.

Giden kutusu

Giden kutusu yalnızca para çekme işlemleriyle ilgilidir ve para çekme davranışlarına yönelik bir kayıt ve yönetim sistemi olarak anlaşılabilir:

• Arbitrum resmi köprüsündeki para çekme işlemlerinin, itiraz süresinin sona ermesi için yaklaşık 7 gün beklemesi gerektiğini ve geri çekme işleminin ancak Toplama Bloku tamamlandıktan sonra uygulanabileceğini biliyoruz. Mücadele dönemi sona erdikten sonra kullanıcı, ilgili Merkle Kanıtını Katman1'deki Giden Kutusu sözleşmesine gönderir; bu sözleşme daha sonra diğer işlevler için sözleşmelerle iletişim kurar (diğer sözleşmelerde kilitli varlıkların kilidini açmak gibi) ve sonunda çekilme işlemini tamamlar.
• OutBox sözleşmesi, birinin tekrar tekrar para çekme talepleri göndermesini önlemek için L2'den L1'e hangi zincirler arası mesajların işlendiğini kaydedecektir. 'mapping(uint256 => bytes32) kamu harcaması'nı kullanarak harcama Endeksi ile para çekme talebi bilgileri arasındaki yazışmaları kaydeder. eşleme[spentIndex] != bytes32(0) ise istek geri çekilmiştir. Prensip, tekrar saldırılarını önlemek için Nonce işlem sayacına benzer.

Aşağıda para yatırma ve çekme sürecini tam olarak açıklamak için ETH'yi örnek olarak alacağız. ERC20 ile ETH arasındaki tek fark, eskisinin Gateway kullanmasıdır. Bunu ayrıntılı olarak açıklamayacağız.

ETH Yatırma

1. Kullanıcı yavaş kutunun mevduatETH() fonksiyonunu çağırır.

2. Bu işlev 'bridge.enqueueDelayedMessage()'ı çağırmaya devam edecek, Mesajı köprü sözleşmesine kaydedin ve ETH'yi köprü sözleşmesine gönderin. Tüm ETH mevduat fonları, mevduat adresine eşdeğer olan köprü sözleşmesinde tutulur.

3. Sıralayıcı, yavaş kutudaki yatırma mesajlarını izler ve yatırma işlemini L2 veritabanına yansıtır. Kullanıcılar L2 ağına yatırdıkları varlıkları görebilirler.

4. Sıralayıcı, yatırma kaydını işlem kümesine dahil eder ve bunu L1'deki hızlı kutu sözleşmesine gönderir.

ETH çekilmesi

1. Kullanıcı L2'de ArbSys sözleşmesinin pullEth() işlevini çağırır ve karşılık gelen ET sayısı L2'ye yazılır.

2. Sıralayıcı, para çekme talebini ekspres kutuya gönderir.

3. Doğrulayıcı düğüm, hızlı kutudaki işlem sırasını temel alarak yukarıdaki para çekme işlemlerini içerecek yeni bir Toplama Bloğu oluşturur.

4. Toplama Bloğu, yine onaylanan sorgulama döneminden geçtikten sonra, kullanıcı, parametrelerin yukarıda bahsedilen ArbSys sözleşmesi tarafından verildiğini kanıtlamak için L1'deki Outbox.execute Transaction() işlevini çağırabilir.

5. Giden Kutusu sözleşmesinin doğru olduğu onaylandıktan sonra köprüdeki karşılık gelen ETH miktarının kilidi açılacak ve kullanıcıya gönderilecektir.

Hızlı nakit çekme

Nakit çekmek için Optimistic Rollup resmi köprüsünü kullanırken, meydan okuma süresini bekleme sorunu yaşanacaktır. Bu sorunu ortadan kaldırmak için özel bir üçüncü taraf zincirler arası köprü kullanabiliriz:

• Atomik kilit değişimi. Bu yöntem yalnızca kendi zincirlerindeki iki taraf arasında varlık alışverişinde bulunur ve atomiktir. Bir taraf Preimage'i sağladığı sürece her iki taraf da kesinlikle hak ettiği varlıkları alacaktır. Ancak sorun, likiditenin nispeten az olması ve eşler arası yöntemi kullanan karşı tarafları bulmanız gerekmesidir.F
• Görgü tanıkları zincirli köprüyü geçiyor. Çapraz zincirli köprülerin genel türleri tanık köprülerdir. Kullanıcılar kendi para çekme taleplerini ve para çekme hedef noktalarını üçüncü taraf köprünün veya likidite havuzunun operatörüne iletirler. Tanık, zincirler arası işlemin L1 hızlı kutu sözleşmesine sunulduğunu keşfettikten sonra L1 tarafındaki kullanıcıya doğrudan para aktarabilir. Bu yaklaşım aslında Katman 2'yi izlemek ve Katman 1'e gönderdiği verilere göre çalışmak için başka bir konsensüs sistemi kullanır. Sorun, bu moddaki güvenlik seviyesinin resmi Toplama köprüsü kadar yüksek olmamasıdır. \

Zorla geri çekilme

Force Inclusion() işlevi, sıralayıcının sansürüne direnmek için kullanılır. Bu fonksiyon kullanılarak herhangi bir L2 yerel işlemi, L1'den L2'ye işlem ve L2'den L1'e işlem gerçekleştirilebilir. Sıralayıcının kötü niyetli sansürü, işlem deneyimini ciddi şekilde etkiler. Çoğu durumda parayı çekmeyi ve L2'den ayrılmayı seçeceğiz. Bu nedenle, aşağıda,forceInclusion kullanımını tanıtmak için örnek olarak zorla geri çekilme kullanılmaktadır.

ETH çekme adımlarına dönüp baktığımızda, yalnızca 1. ve 2. adımların sıralayıcı sansürünü içerdiğini, dolayısıyla yalnızca bu iki adımın değiştirilmesi gerektiğini görüyoruz:

• L1'deki yavaş kutu sözleşmesinde 'inbox.sendL2Message()' çağrılırken, giriş parametreleri, L2'de pullEth() çağrılırken girilmesi gereken parametrelerdir. Bu mesaj L1'deki köprü sözleşmesiyle paylaşılacaktır.
• 24 saatlik zorunlu ekleme bekleme süresinden sonra, zorunlu eklemeyi gerçekleştirmek için hızlı kutudaki Force Inclusion() çağrılır. Hızlı kutu sözleşmesi köprüde ilgili mesajın olup olmadığını kontrol edecektir.

Son kullanıcılar Giden Kutusu'ndan para çekebilir ve geri kalan adımlar normal para çekme işlemleriyle aynıdır.

Ayrıca, kullanıcılara L2 yerel işlemlerinin ve ForceInclusion() işlevi aracılığıyla L2'den L1'e işlemlerin nasıl gerçekleştirileceği konusunda rehberlik etmek amacıyla arbitrum eğitimlerinde Arb SDK'nın kullanımına ilişkin ayrıntılı eğitimler de bulunmaktadır.

Yasal Uyarı:

1. Bu makale [极客Web3]'ten yeniden basılmıştır. Tüm telif hakları orijinal yazara aittir [极客Web3]. 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.