Yazar: Marshall Vyletel Jr. Kaynak: 1kx Çeviren: Şano Appa, Altın Finans

Tanıtım

ETH ağındaki rollup sayısı patlama yaptı. L2Beat verilerine göre, bu yazı yazılırken 91 L2 ve L3 yayına girdi ve 82'si yakında yayına girecek. Bu nedenle, Likidite, kullanıcı deneyimi ve geliştirici araçları açısından büyük bir fragmentasyon mevcuttur. Mevcut interoperabilite çözümleri henüz geliştirilmeyi bekliyor, çünkü bunlar üçüncü taraf köprüler, dış kaplama varlıklar ve niyet çerçevelerinin kombinasyonuna dayanıyor ve her çözümün kendi sorunları vardır.

1. Likidite köprüleri genellikle en büyük Kripto Varlık Hacker saldırılarının hedefi olur (örneğin 3.21 milyar dolarlık bir kusur köprü Hacker saldırısı).
2. Dış ambalajlı varlıklar genellikle hoş karşılanmaz, veriler gösteriyor ki insanlar mümkün olduğunca varlıkları orijinal formda tutmayı tercih ediyorlar (örneğin, L2Beat verilerine göre, köprü varlıkların değeri 220 milyar dolar iken dış ambalajlı varlıkların değeri sadece 30 milyar dolar).
3. Niyet çerçevesi üçüncü taraflara bağlıdır, bu üçüncü tarafların göz ardı edilemeyecek bir güvene ihtiyacı vardır ve Cross-Rollup etkinliklerini teşvik etmek için ek ücretler alırlar (örneğin, resmi köprü standart olmadığından, Degen zinciri kullanıcıları %80'den fazla Token kaybetmiştir). Merkeziyetçi niyet çerçevesi ayrıca düşük rekabet anlamına gelir, bu da fiyatlandırmaya ve performansa istenmeyen sonuçlar doğurabilir.

Bu makalede, dağıtılmış Rollup ekosistemleri arasındaki altı seviyeli etkileşim çözümlerini tanımlayarak ve tartışarak güvensiz etkileşim olasılığını araştırıyoruz.

Varsayılan durumdan başlayarak, kaynak rollup'tan L1'e asenkron olarak para çekme ve ardından hedef rollup'a manuel köprü kurarak tek bir işlemde rollup arasında birleştirilebilirlik varsayımıyla sona eren süreci ele alacağız. Her seviyedeki etkileşimin kullanıcı deneyimini, geliştirici deneyimini, MEV potansiyelini ve rollup'u kendisini (özellikle altyapı değişiklikleriyle ilgili olarak) nasıl etkileyeceğini tartışacağız.

Bu makalede, Ethereum ve L2 hakkında konuşulacak ve sadece takip et etmek için güven gerekmeyen bir etkileşimlilik üzerinde durulacak. Bu durumda 'güven gerekmeyen etkileşimlilik', protokol içindeki kanalları ifade eder ve iletişimi sağlamak için çoğu rollup'ın zaten gerektirdiği gerekli altyapıdan bağımsızdır.

Hazırlıklar

Tanım

Temelde, güven gerektirmeyen etkileşim için paylaşılan kaynaklara ihtiyaç vardır, etkileşimde bulunmak isteyen her iki protokolün de bu kaynaklara erişebilmesi gerekir. ETH Zinciri L1 durumunda, tüm akıllı sözleşmeler, paylaşılan ETH Zinciri tam durumu ortamında bulunur, bu nedenle her zaman en yüksek düzeyde etkileşime sahip olacaklardır. Ancak, L2 sadece ayrı köprü sözleşmeleri aracılığıyla hesaplama katmanını paylaşır, bu nedenle etkileşim büyük ölçüde kısıtlanmıştır.

Güvenilir olmayan etkileşim basamaklarında ilerlememizi sağlayan temel paylaşılan altyapı bileşenleri, paylaşılan sıralayıcı, süper inşaatçı ve paylaşılan Yerleşim'dir. Bu paylaşılan katmanların açtığı güvenceler ve yeni özellikler ilgili olsa da, temelde birbirinden bağımsızdır.

1. Paylaşılan Dizinleyici/Süper Yapıcı: Hızı ve kullanıcı deneyimini önemli ölçüde artırır.
2. Paylaşılan Yerleşim: Dış ambalaj veya protokol içi mesajlaşma gerektirmeyen varlık swapı.

İlk olarak, alıntıda bahsedilen altı güven gerektirmeyen etkileşim seviyesini tanımlayacağız:

1. L1 Asenkron: Yerleşim的 L1 进行手动资产转移，实现互操作性。
2. Atomlar şunları içerir: → Tüm işlemlerin, Rollup Paketi arasında yer alan her Rollup'ın bir sonraki bloğunda bulunacağı veya hiçbirinin bulunmayacağı garanti edilir.
3. 共享Yerleşim： Aynı köprü sözleşmesi aracılığıyla, birden fazla rollup L1'e bağlanır.
4. Atomik yürütme： → Tüm Rollup paketleri arasındaki işlemlerin bağlanma paketindeki her bir Rollup tarafından paket içindeki her bir sonraki Blokta yer alacağı ve başarılı bir şekilde yürütüleceği garanti edilir, aksi takdirde hiçbir işlem gerçekleştirilmez. Başarılı bir yürütme, her bir işlemin Geri Alım olmaksızın gerçekleştirilmesi ve her bir Rollup'ın güncelleme durumunda yansıtılması anlamına gelir.
5. Blok düzeyinde birleşebilirlik： → Gelecek Blok, Cross Rollup Bundle'ın bağımlı işlemleri içerebileceğini garanti eder (Rollup B'deki tx B, Rollup A'daki tx A'nın sonuçlarına bağlıdır)
6. İşlem düzeyi kombinasyonu: → Akıllı Sözleşme seviyesinde, çoklu rollup arasında durum değişikliklerine (bağlama olmadan) neden olan bir işlem yapmak yeterlidir. Herhangi bir rollup üzerinde herhangi bir protokol kullanmak, mantıksal olarak farklı Akıllı Sözleşmeler kullanmakla eşdeğerdir. Önemli olan, herhangi bir çağrıdan önceki durum değişikliklerinin geri döndürülebilir olduğudur.

Her bir seviyeyi daha iyi anlamak için, her seviyenin işlevlerini ve kullanıcılar, geliştiriciler, toplayıcılar ve MEV arayıcıları üzerindeki etkilerini göstermek için aşağıdaki ana kullanımları tanıtacağız.

Örnek:

1. Aynı Token transferi → Kendinize gönderin: Eth'i iki Rollup arasında Eth'e veya ERC-20'ye ERC-20'ye dönüştürün
2. Token satın alma → Cross Rollup limit order: Buy different ERC-20 tokens from DEX on Rollup B using Eth/ERC-20 on Rollup A, and (optional) send them back to Rollup A

Anlamı:

Ayrıca, herhangi bir topluluk ekosistemi üzerindeki ana paydaşların etkisini daha iyi anlamak için aşağıdaki soruları da yanıtlayacağız.

1. Kullanıcı deneyimi Bu tür bir etkileşim düzeyini gerçekleştirmekle, kullanıcı deneyiminde nasıl bir değişiklik olur?
2. Geliştirici Deneyimi Bu seviyedeki etkileşim kabiliyeti gerçekleştirildiğinde, geliştiricilerin deneyimi nasıl değişecek?
3. MEV potansiyeli Eğer bu düzeyde bir etkileşim sağlarsak, yeni MEV fırsatları ortaya çıkabilir mi?
4. Rollup'un etkisi Rollup bunu gerçekleştirmek için herhangi yeni bir altyapıya katılmak zorunda mıdır? Rollup'un ücret yapısı hangi değişikliklere sahiptir? Rollup altyapısına katılmak hangi potansiyel faydaları getirebilir?

Gelişmiş Genel Bakış

Güvensiz İşbirliği İnteroperabilitesine Doğru Altı Aşama

1. L1 Asenkron

Gerekli Altyapı:

Uygulanamaz

Tanımına göre, bu, mevcut varsayılan güvensiz etkileşimli modu ifade eder. Tüm rollup'lar böyle tanımlanır çünkü bunlar L1 üzerinde yerleşim katmanı olarak inşa edilir ve yalnızca köprü sözleşmesi aracılığıyla L1'e erişilebilirler, ağın korunması için düzenli olarak durum güncellemeleri yayınlarlar.

Bu durumda, güven gerektirmeyen herhangi bir Rollup ötesi etkinliği gerçekleştirmenin tek standart yöntemi, kaynak Rollup'tan varlıkları köprü aracılığıyla çekmek ve L1 üzerinde kullanılabilir hale geldikten sonra manuel olarak hedef Rollup'a yatırmaktır.

Optimistik Rollup için, hata düzeltme penceresi göz önüne alındığında, çekilme işlemlerinin gecikme süresi yaklaşık 7 gün olabilir. ZK Rollup'ta, çekilme işlemlerinin gecikme süresi belirsizdir, ancak 15 dakika ile tam bir gün arasında olabilir, ZkSync bu duruma örnek olarak verilebilir.

Ayrıca, noktadan noktaya atomik takas için Akıllı Sözleşme kullanmak da mümkündür, ancak bu daha küçük bir kullanım durumu ve etkin bir şekilde genişletilemez.

Şu anda mevcut olan üçüncü taraf çözümün dikkatlice incelenmesi gerekmektedir：

1. Likidite Köprüsü
2. Niyet Çerçevesi

Her iki örneğimiz de yardım için üçüncü taraf çözüm gerektiriyor.

Kendine gönder:

1. Standart uygulama: Rollup A'dan varlık çek →Manuel Olarak Rollup B'ye Yatırın
2. Üçüncü taraf: → Likidite桥梁 / 求解器网络

Çapraz Kaydırma Limit Emri

1. Standard: Rollup A'dan varlık çek →Manuel olarak Rollup B'ye yatırın → Gerçekleştir Sınırlı Emir → Geri göndermek için hedef ERC-20'yi dış paketlemeye tabi tutmanız gerekiyor
2. Üçüncü taraf Yeni bir çözüm alanı: çapraz fiyatlı emirlerin birleştirilmesi → Açık bir tasarım, kullanım niyetini teşvik etmek için odaklanmıştır

Bu varsayılan olduğundan, UX, DevEx, MEV ve toplu değişiklikler hakkında konuşmaya gerek yoktur.

2. Atom İçerir

Gerekli Altyapı

Paylaşılan Serileştirici *

Atom sadece gelecek blokta kümelenmiş bağlantı içereceğini garanti eder.

Bu, paylaşılan bir sıralayıcı gerektirir, ancak teorik olarak, iki verilen rollup üzerindeki sıralayıcılar maksimum işlem kapasitesine ulaşmadıysa manuel olarak uygulanabilir (her bir rollup'a sadece iki işlem göndermek yeterlidir). Bu, yıldız eklediğimiz altyapı gerekliliğimizdir.

Ancak, paylaşılan sıralayıcının her bağlantının rollup'ının tam Düğümünü çalıştırdığını varsaymıyoruz, bu nedenle bir işlem grubunun başarılı bir şekilde yürütüleceğinin garantisi yoktur. Bu durumda, paylaşılan sıralayıcı yalnızca işlem formatının doğru olduğunu ve bir sonraki Blok'ta yer alacağını garanti edebilir, ancak başarılı bir şekilde yürütüleceği garanti edilemez.

Herhangi bir programlama yoluyla atom içerik kullanmadan, bir işlem iptal riski olmadan hiçbir anlamlı şekilde yürütme garantisi olmadığından, temelde L1 Async ile tamamen aynı durumdayız.

Yalnızca atomik kapsam garantili basit bir çapraz toplam değişim başlatmayı düşünün:

1. Paketleri toplamalar arasında değiştirin
   → Tx 1: Token kilitleme / yok etme kaynak Rollup'da → Tx 2: Hedef Rollup üzerindeki kullanıcının Adresine Token mintleme

Bizim belki de atomik dahil olma garantisi var, yani iki işlem aslında her bir toplu işlemde yer alır, ancak ilk işlem Geri Alım yaparken ikinci işlem Geri Alım yapmazsa, kullanıcı kaynak on-chain'de bunları kilitlemek veya yakmak zorunda kalmadan hedef on-chain'de yanlışlıkla fonlar tahsis eder, bu durumda Çifte Harcama sorunuyla karşılaşırız.

Herhangi bir etkileşimli çözüm, likidite köprüsü, niyet çerçevesi veya xERC-20 takası olsun, bu riskten etkilenme olasılığı yüksektir ve bu riski hafifletmek mümkün değildir. Bu riskin varlığı nedeniyle, mevcut çözüm, bir işlem başlatmanın, başarıyla gerçekleştirilmiş olması ve kaynak on-chain Blok içermesi gerektiğini ve ardından mesajı geçirmek ve hedef on-chain'de ikinci bir işlemi gerçekleştirmek için bir röle kullanmanın gerektiğini gerektirir.

Önemli ipuçları: Atomik swap, iş birliği potansiyeline büyük ölçüde katkıda bulunmayacaktır.

3. Paylaşılan Yerleşim

Gerekli Altyapı:

Proof aggregation layer//Shared bridge contract

İşlerin daha da ilginç hale geldiği yer burasıdır. Paylaşılan köprü sözleşmesinin varlığı sayesinde, rollup ekosistemi içine L1'den yatırılan tüm Likidite, tüm bağlantılı rollup'lar arasında serbestçe hareket edebilir. Bundan önce, rollup'lar arasında takas yapmak için standart kanallardan, dış ambalajlı varlıklardan veya üçüncü taraf çözümlerden geçmeden yapamıyorduk.

Neden paylaşılan köprü sözleşmesi kurmalıyız? Neden paylaşılan köprü sözleşmesinin bize güvensiz bir şekilde Rollup üzerinden varlıkları transfer etmemize izin verebileceğini anlamak için öncelikle şunu düşünün: Rollup A'da Eth'e sahip olabilir ve onu imha edebiliriz, ardından Layer1'de paylaşılan köprü sözleşmesi kurmadan Rollup B'de doğal olarak mintleyebiliriz.

Gördüğümüz gibi, her rollup Ana Ağ'daki köprü sözleşmesiyle senkronize değil. Rollup B köprü sözleşmesi hala 50 Eth'e sahip olduğundan, kullanıcı bunlardan 1 Eth'i L1'e çekemez.

Bu sorunu çözmek için, dış varlık paketleme protokolü oluşturduk ve protokol aracılığıyla ağın başka yerlerindeki asıl versiyonlarını temsil eden Token'ları üretiyoruz.

Paylaşılan hesaplama katmanı olduğunda, durum farklı hale gelir. Her bağlı rollup'un tüm Likidite'si aynı köprü sözleşmesine kilitlendiği için insanlar rollup'lar arasında serbestçe hareket edebilir çünkü köprü sözleşmesindeki toplam değer sabit kalır ve her zaman çekilebilir.

Gerçekten de, Likidite nerede olduğunu anlamak için L1 sözleşme düzeyinde güncelleme yapılması gerekiyor, böylece kullanıcıların herhangi bir yerden para çekmesine izin verilir, ancak bu çok basit, çünkü tüm bağlantılı toplamlar paylaşılan sözleşmelerde okunabilir/yazılabilir.

Paylaşılan bir hesaplama katmanı kullanarak, kendinize göndermek için basit bir durumda, işlem aşağıdaki gibi görünebilir.

Kendine gönder:

1. Kullanıcı ilk işlemi oluşturur: → Tx 1: Eth çıkarma (ve rollup B'de mintleme) rollup A üzerinde → İşlemler L1 sözleşmesine ayrı ayrı gönderiliyor. →Onun tüm paylaşılan Yerleşim rollup gruplarını içeren işlem köküne toplandı.
2. Rollup B bu işlem kökünü içeri aktarır
3. 交换机将交易提交给铸币厂，并将 Merkle 证明提交给 rollup B
4. Rollup B, Merkle Proof ve işlem kökü kullanarak yok etme işlemini doğrular.
5. Kullanıcı Rollup B'de Eth mintledi
6. Rollup B L1'e kanıt sunuyor

Bu süreci, paylaşılan Yerleşim ekosistemi içinde tüm toplama sözleşmesine sahip herhangi bir ERC-20 tokenine genişletebiliriz.

Paylaşılan köprü sözleşmesini, bağlantıların protokol içindeki tüm iletişim katmanı olarak düşünebiliriz, bu nedenle teorik olarak bu sürecin herhangi bir iletişim standartına genişletilebileceği söylenebilir.

Bu, bizi kombinasyona daha yakınlaştırıyor, ancak durum değişikliklerinin yalnızca L1'de yansıtılmasının ardından toplama kanıt ve iletişim gerektirmesi nedeniyle gecikme süresi yüksektir (ancak açıkça L1 asenkron durumundan daha düşüktür). Ayrıca, herhangi bir karmaşık Rollup etkinliği (örneğin, Rollup A'daki varlıklardan Rollup B'deki DEX kullanarak karma Rollup limit emirleri oluşturma) hala kullanıcılar için zahmetli bir süreçtir, çünkü hala kendi kendilerine varlık göndermeli ve hedef Rollup'ta varlıkları manuel olarak takas etmelidirler. Bu durumda, atomik karma Rollup paketleri oluşturulamaz.

Yerleşim的另一个重要好处是，对于在多个环境中执行订单的Likidite提供者或解决者来说，摩擦更小。由于他们跨所有连接的 Rollup 的Likidite都反映在同一个过桥合约中，因此他们不必等待完整的提款窗口来管理跨 Rollup Likidite。

Paydaşlar Üzerindeki Etkisi:

1. Kullanıcı: Varlık transferi artık yerel olarak gerçekleştirilebilir, L1 çekme süresine gerek kalmaz
2. Geliştiriciler: Değişiklik sadece Token üreticilerine özgüdür, şimdi protokol içi mesajlaşma kullanarak bağlı tüm Rollup'larda üretim ERC-20'nin asıl sürümünü üretebilirler.
3. MEV Arayıcısı: Bu durum her rollup'un birden fazla Blok'unda gerçekleştiği için yeni bir MEV potansiyeli yoktur.
4. Rollups: Rollups, paylaşılan köprü akıllı sözleşmesi kullanmak zorunda ve muhtemelen Rollup mesajlarını işlemek için önceden derlenmişleri eklemelidir.

Önemli ipucu: Paylaşılan Yerleşim, paylaşılan köprüleme sözleşmesi ve kanıt birleştirme katmanında dış ambalaj olmadan varlık transferi ve herhangi bir mesaj iletimine izin verir, ancak ihmal edilemeyecek gecikme süresi olacaktır (L1 Async'ten çok daha kısa olsa da) ve çapraz toplam atom demeti oluşturulamaz.

4. Atomik Yürütme

Gerekli Altyapı:

Paylaşılan sıralayıcı // Süper Yapımcı

Atomik yürütme, çapraz rulo bağlama paketinin başarılı yürütülmesini garanti etmemizi sağlar, ancak göreceğimiz gibi, bağımlılık olmayan çapraz rulo bağlama paketlerinin kullanım örnekleri, önceden tahmin edilenden daha azdır.

Eğer bir işleme dayalı bir grup işlemin herhangi biri iptal edilirse, diğer tüm işlemler geçersiz hale gelir ve iptal edilmek zorundadır, tam olarak rollup silme ve Token üretme durumu gibi. Hedef rollup'ta Token üretme, kaynak rollup'ta zaten silinmiş veya kilitlenmiş olup olmadıklarına bağlıdır, bu nedenle bir grup silme ve üretme işlemi bir dizi işleme dayalı bir gruptur.

Bu paketi oluşturmak için hedef işlemi yapabilen bir aracı olmadan (örneğin süper yapıcı) mümkün değildir.

Kullanıcı dışında başka tarafların katılmadığı bir durumda, Rollup'lar arası token paketi oluşturmanın hangi koşulları sağlaması gerektiğini düşünün. Varlık kaynak Rollup'ta kilitlenerek / işlenerek bir token paketi oluşturulmalı ve hedef Rollup'ta tokenler mintlenmelidir, ancak karşılaştığımız bir sorun var:

1. Kaynak rollup'taki sözleşmeler, yalnızca orijinal kaynak varlıkların kilitlenmesi/silinmesi sırasında mesaj gönderebilir, hedef rollup'ta işlem çağıramaz veya oluşturamazlar. → Bu, mesaj protokolü ve Röle ağının varoluş nedenidir. → Haberleşme, çağrının hedefte oluşturulması gerekenin ne olduğunu belirlemek için kullanılabilir, ancak aslında işlemi oluşturamaz.
2. Mintleme yapmak için hedef rollup üzerinde ikinci bir işlem oluşturun: → Kullanıcılar, rollup B üzerinde Token'ın döküm hakları olmadığı için bu işlemi kendileri oluşturamazlar → yani) Hedef zincirin, Token'ın kaynak zincirde imha edildiğini / kilitlendiğini kanıtlaması gerekir, ancak bu kanıt yalnızca başlangıç işleminden sonra kullanılabilir, bu da atomisite gereksinimimizi bozacaktır. → Teorik olarak, diğer herhangi bir şey Mint yetkisine sahip ikinci bir işlemi oluşturan taraf, kaynak on-chain'de önce 'yakma' veya kilitlenme işlemi oluşturmadan herhangi bir zamanda hedef on-chain'de 'mint' işlemi oluşturabilir, bu büyük bir güvenlik açığıdır.

Görebiliyoruz ki, değerli varlıkların aktarılmasında öncelikle nasıl oluşturacaklarımızda zorluklarla karşılaşıyoruz, bundan dolayı çapraz toplam bağ paketlerinin yürütülmesini garanti edebilsek bile.

Ancak, hala cross-rollup demetlerine bağlı olmayan bazı atomik yürütme durumları var. Bunlardan biri, cross-rollup Arbitraj.

Bu işlemler arasında sıkı bir bağımlılık olmadığı için, herhangi bir kişi bu atomik paketi oluşturabilir ve bunu atomik yürütme garantisi olan paylaşılan bir sıralayıcıya gönderebilir.

Ancak, atomik yürütme garantisi almak için öncelikle paylaşılan bir sıralama ve süper bir oluşturucu seçmelidir rollup, bu nedenle atomik yürütmeden Blok seviyesine kadar olan adım çok küçüktür ve tüm paylaşılan sıralama çözümleri bunu yapar. Tek gereken değişiklik, Blok oluşturucu veya diğer üçüncü tarafın, bağımlı cross rollup paketini tamamlamak için kullanıcı adına işlem oluşturabilmesidir.

Yalnızca atomik yürütme izin veren ve daha fazla bileşebilme sağlamayan bir altyapı oluşturmak mümkün değildir. Altyapının zaten atomik yürütme yeteneğine sahip olduğu göz önüne alındığında, tamamen blok düzeyinde bileşebilme sağlama konusundaki fayda, bu hedefi gerçekleştirme zorluğundan çok daha yüksektir.

Paydaşlar Üzerindeki Etkisi:

1. Kullanıcı: Muhtemelen değişiklik olmayacak, üçüncü tarafın niyet gibi çözümler sunabileceği, ancak nasıl uygulanacağı henüz net değil.
2. Geliştirici: Muhtemelen değişmez
3. MEV Arayıcısı: Dikkate alındığında atomik yürütme, cross rollup Arbitraj daha güvenli hale gelir
4. Rollup: Rollup, her bir Rollup'un birbirleriyle etkileşimde bulunmasını uman işlemleri içeren Blok'ları kullanarak paylaşımlı bir sıralayıcı/süper inşaatçı seçmek zorundadır. Bu, Rollup'un gelir yapısını değiştirebilir, ancak nasıl değişeceği henüz net değil. Sıralama pazarı, Rollup gelirini artırmak için olgun geliştiricilere ToB alanı satın alma izni vererek oluşturulabilir.

Önemli ipuçları: Rollup çapraz bağlantıları garanti altına alırken, paketin bir kısmını oluşturmayan süper yapılandırıcıların, paketlerin nasıl oluşturulacağı belirsizdir, bu nedenle atomik yürütme kendisi muhtemelen etkileşimliği etkilemeyecektir. Varsayılan olarak, paylaşılan diziler/süper yapılandırıcılar blok düzeyinde birleşebilirlik oluşturmalıdır.

5. Blok düzeyinde bileşenler

Gerekli Altyapı:

Paylaşılan Sıralayıcı // Süper Oluşturucu // Kanıt Birleştirme Katmanı* // Paylaşılan Köprü Sözleşmesi*

（* = İsteğe bağlı）

Paylaşılan diziler ve paylaşılan hesaplama katmanı ile ilgili çoğu tartışmada, bu seviye etkileşilebilirlik için genellikle kullanılan terim 'senkron bileşebilirlik' olarak tanımlanmaktadır.

Terimi daha açıklayıcı hale getirmek için biraz değiştirdik. "Blok seviyesinde birleştirilebilirlik" terimini güncellemek, farklı rollup'lar arasında birleştirilebilir çapraz rollup işlemleri paketleri oluşturmayı ve bu işlemlerin bir sonraki Blok'ta başarıyla yer almasını sağlamayı mümkün kılar. Senkronize edilebilirlik, işlem seviyesinde birleştirilebilirlikle karıştırılabilir, ancak bunu bir sonraki bölümde ele alacağız. Önemli olan, bu, bağımlı işlem paketlerinin yürütücüsü ve yaratıcısı olabilecek bir ara kişiye (paylaşılan bir sıralama altyapısı) ihtiyaç duyar.

Bu seviyede, Rollup'lar arasındaki gerçek kombinasyonu görmeye başlıyoruz, sadece başka bir Rollup üzerinde yer almak için kendimize gönderme konusundan daha fazlası.

Paylaşılan bir dizgeleyici ekleyerek işlem oluşturma yeteneği sağladığımız için, artık özet paketler oluşturabiliriz ve geliştiriciler bunu programlama yoluyla kullanabilirler.

İki durumu göz önünde bulundurmanız gerekiyor:

1. Blok düzeyinde birleştirilebilirlik
2. Blok seviyesi birleştirilebilirlik + paylaşılan yerleşim katmanı

Bu iki durumda da, daha karmaşık etkinlikler için çapraz özetleme paketleri oluşturabiliriz, ancak ikinci durumda, Yerleşim paylaşarak, örneğin yerel varlıkları kullanabiliriz, bu çapraz özetleme DEX etkinlikleri için daha iyi bir fiyat etkisi oluşturabilir.

Yığın düzeyinde bileşebilirlik sayesinde, hem atomik yürütmenin avantajına sahibiz hem de bağımlı işlem paketlerini oluşturma yeteneğine sahibiz. İki açıklayıcı örneklerimize bir göz atalım.

xERC-20 ile aynı Token transferi yapın (paylaşılan Yerleşim yok):

1. Kullanıcı ERC-20 sahibi
2. Kullanıcı bir dApp aracılığıyla bir TX oluşturur:
   ERC-20'yi xERC-20 kilidine yatırın, xERC-20 paket sürümünü almak için → xERC-20'i yok et → Bir mesaj göndererek paylaşılan sıralama altyapısının başlatıldığını ve verilerin değişimi kolaylaştırmak için ilgili verilerin eklenildiğini bildirin
3. Superbuilder, işlemi alır ve Rollup ötesi bağlantı oluşturur. → Tx 1: Yukarıdaki ambalajlama ve imha işlemi → Tx 2: Rollup B'de xERC-20'yi mintleme
4. Superbuilder bu çapraz rollup'ı paylaşılan sıralayıcıya gönderir. → Superbuilder, iki birbirine bağlı rollup'un tam Düğümünü çalıştırdığı için, bunlar başarılı bir şekilde tamamlanması için kağıt trade edilecektir. Herhangi bir işlem geri alınırsa, tüm paket geri alınacaktır.
5. Paylaşılan sıralayıcı, DA katmanına iki işlemin Blok'unu sunacak ve durum değişikliklerini yürütecek Düğüm
6. xERC-20 Rollup B'de kullanıcılara mintleme

Paylaşılan bir hesaplaşma katmanı olduğunda, işlem daha da basitleştirilir çünkü ERC-20'yi önce xERC-20'ye dönüştürmek için takas yapmanıza gerek yoktur.

Şimdi Rollup A'da başlangıç (farklı) ERC-20 ile Rollup B üzerinde bir geçiş Rollup limit fiyatlı emri görelim ve oluşturulan ERC-20'yi Rollup A'ya gönderelim. Bu durumda, bir paylaşılan yerleşim katmanımız olduğunu varsaymıyoruz, ancak paylaşılan bir yerleşim katmanı olduğunda benzer bir işlem mevcuttur. Tek fark, varlıkları harici olarak sarmaya gerek olmamasıdır.

Bu örnek için gereken işlemler şunlardır:

1. ERC-20'yi A üzerinde paketle ve imha et
2. B üzerinde Mint xERC-20
3. Başlangıçta xERC-20'i B üzerinde hedef ERC-20 ile değiştirin
4. Hedef ERC-20'yi B'de paketleyin ve imha edin
5. Bir 上的Mint xERC-20

Aşağıda olası iş akışı şunlardır:

Hareket:

1. Kullanıcı ilk işlemi başlatır: →xERC-20'i paketleyin ve imha edin, değişim parametrelerini belirtmek için ileti gönderin (hedef zincir, DEX Adresi, değiştirilecek ERC-20, limitli sipariş fiyatı, geri gönderilsin mi boolean değeri)
2. Süper yapımcı, işlemi görür ve bir paket oluşturur: → Tx 1: Kullanıcı yukarıdaki işlemi oluşturur → Tx 2: Hedefte mintle xERC-20 (Süper Yapıcı'nın mintleme izni olmalıdır) → Tx 3: Sınırlı emir için tx 1'den gelen verileri kullanma → Tx 4: ERC-20 paketlenir ve B üzerinde imha edilir, limit emri tamamen yerine getirildiğinde ve kaynak zincirinde mesaj gönderilerek mintleme → Tx 5: Kaynak zincirindeki takas çıktısından mint hedefi xERC-20

Süper yapılandırıcı, Blok oluşturur ve işlemleri sıralar, bu nedenle her işlemi simüle edebilir ve herhangi bir işlem iptal edildiğinde paketi atlayabilir. Örneğin, bir kullanıcının limitli emirlerini tam olarak yerine getiremediği tespit edilirse, Blok gerçekleştirilmeden önce paket atlanır.

Paylaşılan Yerleşim katmanı olmadan paylaşılan sıralama altyapısı durumunda, dışarıdan sarılı Eth ve xERC-20'nin sürümünü kullanmak gerekebilir, bu da DEX'in pazar durumunun kötüleşmesine neden olabilir çünkü sargılanmış varlık likidite havuzları seyreltebilir. Bu durumda kullanıcılar daha esnek sınırlamalar kullanmak zorunda kalabilir, Slipaj toleransı daha yüksek olabilir ve alt-optimal fiyatlar alabilirler. USDC ile ilgili bir istisna var. Paylaşılan Yerleşim olmayan paylaşılan sıralayıcı, Circle ile çalışarak, cross rollup USDC sözleşmesinin özel haklarını elde edebilir ve cross rollup doğal USDC transferi ve değişimini teşvik etmek için.

Paylaşılan bir hesaplama katmanı olduğunda, bu tür harici ambalaja ihtiyaç yoktur ve yerleşik varlık swap havuzunun daha derin olması nedeniyle daha iyi fiyatlar sunabileceği olasılığı vardır, ancak işlem süreci temel olarak aynıdır.

Optimistically Trust Sequencer

Rollup, etkin bir şekilde Rollup demetleri oluşturmak için paylaşılan bir sıralayıcı/süper inşaatçıya iyimser bir şekilde güvenmek zorundadır. Bunun temel nedeni, bu Rollup demetinin, bağımlı işlemleri içermesi ve her bir Rollup'ın bu işlemleri L1 üzerindeki yerleşim katmanına on-chain eklemesi ve birleştirmesi gerektiği için farklı Rollup'lar bu işlemleri doğrulayamaz. Bir örnek, kaynaktan hedefe ETH'nin başlangıçta Blok üzerinde yok edilmesi ve mintlenmesidir. Hayati önem taşıyan bir nokta, ETH'nin kaynak on-chain'de gerçekten yok edilmesi ve ardından hedef on-chain'de mintlenmesidir; aksi takdirde Çifte Harcama oluşabilir.

Ancak, bu tam paketi bir Blok içinde gerçekleştirmek için, tüm işlemlerin o Blok içinde bulunması gerekmektedir, hatta işlemler Blok'un kendisinden önce geçersiz olan bir durumu temsil ederse bile (örneğin, kullanıcının Blok öncesi Eth'si olmadığı durumda, hedef on-chain'de Eth'e sahip olması gerekiyor). Bu nedenle, sıralayıcının gerçekten geçerli bağımlılıkları içeren bir özet paketi üzerinde çalıştığına inanmamız gerekiyor. Her işlemin geçerliliğini kanıtlamak için sonradan kanıt sunulabilir.

Ancak, varlık paketleri kullanıldığında, bu önemli değil, çünkü bunlar L1'de depolanan yerel Likidite'yi etkilemez, ancak hala kötü niyetli sıralayıcıları veya kodlardaki hataları dengelemek için bir geri alma mekanizmasına sahip olmalıdırlar, bu hatalar işlem demetlerinin geri döndürülen bağımlı işlemlerle birlikte yürütülmesine izin verir.

Paydaşlar Üzerindeki Etkisi:

1. Kullanıcı Kullanıcı deneyimini büyük ölçüde geliştirdik ve tek bir Blok içinde çapraz toplam sınırlı emirler yapmanıza izin verdik.
2. Geliştiriciler Cross-rollup aktivitelere karşı cross-rollup farkındalığa ihtiyaç duyulabilir ve özel ön derlemeler kullanılabilir. Geliştiriciler, işlemlerden daha çok demetin perspektifinden düşünmek zorundadır, ancak süper oluşturucu ve özel Rollup altyapısı, çoğu geliştirici için karmaşıklığı ortadan kaldırabilir.
3. MEV Arayıcı MEV arayıcıları, L1 stratejisini kullanan cross-rollup paketlerindeki fırsatları temelde aynıdır, ancak bu, PBS (proposer-builder separation) uygulama şekline bağlıdır. → Cross-asset bundle is essentially regarded as a single transaction, so MEV can be found by front-running or sandwiching these bundles, as long as they do not cause the price to exceed the tolerable Slipaj amount (because then the entire bundle will revert and the MEV attempt will fail)
4. Rolluplar Paylaşılan hesaplama katmanına erişime izin vermek için paylaşılan sıralayıcıdaki Eth imha/mintini seçmeniz gerekmektedir (süper inşaatçı dahil) ve paylaşılan hesaplama altyapısına katılmanız gerekmektedir. → MEV'yi içselleştirmek için Blok alanını inşaatçıya satarak

6. İşlem düzeyinde birleşebilirlik

Gerekli Altyapı:

VM seviyesi değişikliği // Paylaşılan Yerleşim // Süper Yapımcı

İşlem seviye kombinasyonu, bir EVM on-chain akıllı sözleşmesinin paylaştığı aynı seviyedeki işlevselliği ifade eder. Bu durumda, tek bir işlem, birden çok rollup'ın durumunu aynı anda güncelleyebilir ve çağrı başarısız olursa, herhangi bir çağrıdan önceki tüm durum değişikliklerini geri yükleyebilir. Aslında, blok düzeyindeki kombinasyonlu ortamda, atomik işlem paketi, tek bir rollup ve VM arasında gerçekleştirilebilir. Bu, yerleşim katmanını ve süper yapıyı paylaşmanın yanı sıra, tüm bağlı rollup'lara VM düzeyinde değişiklik yapmayı gerektirir.

Potansiyel bir mekanizmayı yüksek seviyede tanımladığımız yer burasıdır. (Bu yapının Espresso ekibi tarafından geliştirildiği bilinmektedir). İlk olarak, kullanıcı, tüm durumları değiştiren işlemleri içeren rollup'lara veya blok oluşturabilen süper yapılandırıcılara kağıt trade gönderir. Süper yapılandırıcı, her ilgili rollup için bir giriş/çıkış çifti listesi oluşturur ve işlemde gerekli ve beklenen çapraz rollup mesajlarını belirtir. (Süper yapılandırıcı, tüm ilgili rollup'lara güvenli bir sıralama hakkına sahip olduğu bir süre içinde bunu yapabilir). Daha sonra, süper yapılandırıcı, her rollup'un önericisine sahte blok ile beklenen giriş/çıkış çifti listeleriyle birlikte gönderir. Yürütme sırasında, her rollup, çapraz rollup işlemleri listesinden gelen girdilerin doğru olduğunu varsayarak kendi durum geçiş işlevini normal şekilde çalıştırır. Yerleşim sırasında, giriş/çıkış listeleri, güvenli bir şekilde paylaşılan yerleşim katmanında toplanır ve çapraz karşılaştırma yapılır. Özellikle, bir çapraz rollup işlemindeki herhangi bir beklenen giriş, başka bir rollup tarafından belirtilen çıkışla eşleşmiyorsa, yerleşim süreci tüm çapraz rollup işlemini reddeder.

Flaş Krediler dışında, işlem seviyesindeki kompozitlik tarafından kilidi açılan yeni özellikler sınırlı olsa da, geliştiriciler Rollup dışı uygulamalar oluşturma deneyiminden büyük ölçüde yararlanabilirler. Tüm bağlı zincirlerle etkileşimli dapp'ler oluşturma yeteneği, Rollup demetlerini düşünmek zorunda kalmadan, çoklu Rollup ortamında yenilik yapmayı çok daha kolay hale getirecektir. Ayrıca, yeni kullanım durumları ve davranışlar ortaya çıkabilir.

İşlem düzeyinde birleştirilebilirlikte çözülmemiş bir dizi tasarım sorunu vardır. Öncelikle, geliştiricilerin Akıllı Sözleşme'nin çapraz toplama çağrılarını nasıl etkinleştirebileceklerini veya devre dışı bırakabileceklerini dikkatlice düşünmeniz gerekir. Kısıtlama olmaksızın rastgele birleştirilebilirliğe izin vermek, tek bir toplamaya geri döndüğümüz anlamına gelir. Buradaki cevabın, geliştiricilerin sözleşmelerinde çapraz rollup birleştirilebilirliğinin nerede gerekli olduğunu açıkça belirtmeleri olduğunu düşünüyoruz, örneğin bir sözleşmenin belirli giriş noktalarını "composable" gibi Solidity değiştiricileri aracılığıyla çağrılabilir çapraz rollup'lar olarak işaretlemek gibi.

Paydaşların Etkisi

1. Kullanıcı: Bloklar arası bileşebilirlik anlamına sahip olup, Flaş Krediler gibi diğer gelişmiş özelliklere sahiptir. → UX ve seçilen dapp'ın kullanımı neredeyse aynı bir zincir üzerinde
2. Geliştiriciler: dapp geliştiricileri, yerel olarak akıllı sözleşme çapraz toplama çağrılarını yapabilir ve bu çağrıların çıktılarını kullanabilir (tekli toplama çağrısı gibi), bu nedenle Geliştiricilerin deneyimi büyük ölçüde iyileşti 改善→ Superbuilder/Sequencer infra 仍然必须将交易放置在受交叉汇总调用影响的汇总的块中，但不必像块级可组合性那样构建相同的捆绑包。
3. MEV Arayıcısı: Rollup demeti artık temel olarak bir on-chain tek işlem gibi, bu nedenle MEV potansiyeli çok yüksek
4. Rollups: Sanal Makine级别的更改需要，以及选择共享排序器和共享Yerleşim层 → Diğer rollups'ların girdi ve çıktılarına güvenmek, durumu doğrulama kanıtıyla doğrulayabilene kadar ek güven varsayımlarını gerektirir, ancak kesme mekanizması güven yükünü hafifletebilir.

Özet ve Ekosistem Grafiği

Bu burada tanımlanan her etkileşim düzeyinin teknik ayrıntılarını anladıktan sonra, özetleyebiliriz:

1. 共享Yerleşim允许跨 rollup 交换而无需外部包装资产，并在所有连接的 rollup 之间创建protokol内消息传递路径
2. Paylaşılan sıralama/Superbuilders, bir sonraki Blok yürütme garantisi sağlamak için rollup demetlerinin ötesinde çalışmasına izin verir
3. 区块级可组合性允许创建复杂、快速、相互依赖的跨 Rollup 捆绑包，从而实现近乎akıllı sözleşmeler到akıllı sözleşmeler级别的可组合生态系统。 → Bu cross Rollup paketlerini oluşturmak için dış ambalaj varlıklarını kullanmadan paylaşılan Yerleşim ekleyerek
4. Ticaret seviyesinde birleştirilebilirlik mümkündür; yeni açılan kullanım durumları daha karmaşık kullanıcılara yönelik olabilir, ancak toplama geçiş geliştirme deneyimini büyük ölçüde yükseltebilir.

Şu anda, birçok proje ortaya çıkıyor ve bu orijinal birbirleriyle etkileşimli ekosistemleri oluşturmayı amaçlıyor. Aşağıda bu alandaki yüksek düzeyli bir genel bakış bulunmaktadır:

Ekosistem Haritası

Ekosistem haritası

Kapanış

Bu makalede listelenen çerçevelerle ilgili teknik detaylar hala belirsizdir. Örneğin, blok düzeyinde birleştirilebilir ekosistemde cross-aggregate limit orders için bundle oluşturmak, kısmi gerçekleşmeleri ve piyasa emirlerini Slippage toleransı durumunu ele almak için daha detaylı bir tasarım gerektirebilir. Burada potansiyel bir çözüm sunuyoruz, eğer emir tamamlanmamışsa cross-aggregate limit order bundle'ı geri yüklenebilir, ancak tasarım alanı açıktır.

Ayrıca, değinilmesi gereken bir diğer nokta, bu durumun mevcut AppChain alanındaki artan düşünce paylaşımıyla ilgili olmasıdır. AppChain, uzun kuyruklu L2'ye göre genellikle yükselen veya izinli olacak şekilde belirli ilgili protokolleri bir L2'de izole etmeyi amaçlar. Blok düzeyinde birleştirilebilirliğe ulaştığımızda, muhtemelen tüm bağlantı ağları arasında yerel birleştirilebilirlik olduğundan AppChain ortamının önemli ölçüde çekici hale gelmeye başladığını da göreceğiz.

Şu anda, bu uygulama zincirleri için Likidite'nin entegre edilmesi hala zor olsa da, daha büyük bir zincir, birbirleriyle etkileşimli bir ortam olarak entegre olduğunda, paylaşılan altyapı etrafında duvar bahçesi ekosistemini görmemiz muhtemeldir.

Başka bir önemli belirsizlik konusu da Süper Yapımcılar çevresindeki tasarım alanının nasıl ele alınacağıdır. Bu alandaki gelişmeler henüz başlangıç aşamasında ve şu anda karma toplam paketler oluşturabilen karmaşık bir yapımcı ağı oluşturmanın en etkili yolunun ne olduğu belirsizdir. Bu karma toplam paketlerin Blok içinde en iyi şekilde nasıl yer alacağı ve toplam gelire etkisi hala belirsizdir ve birçok ekip farklı stratejileri keşfediyor.

Sonunda, gelecek, herkes için daha iyi bir birlikte çalışabilirlik süreci sağlamak için birlikte çalışacak protokol dahili ve protokol harici köprüleme çözümlerinin bir kombinasyonunu içerebilir. Bu makalede tanımlanan ilerlemenin, son kullanıcılar için daha sorunsuz çapraz toplama birlikte çalışabilirliği sağlamaya odaklanan geliştiriciler ve oluşturucular için bir kılavuz görevi görebileceğine inanıyoruz.