Based Booster Rollup'ın derinlemesine analizi: arka plan, uygulama ve beklentiler

Orijinal yazar: jolestar (X: @jolestar )

Birkaç arkadaşımın Based Rollup hakkında konuştuğunu gördüm, çoğu bundan güvenlik perspektifinden bahsetmişti. L1 ve L2 arasındaki ilişki ve uygulamaların inşası perspektifinden Based Booster Rollup hakkındaki görüşlerimi konuşmak istiyorum.

Based Rollup fikri aslında çok basittir, yani kullanıcılar L2 işlemlerini doğrudan L1'e gönderir ve L1 tarafından sıralanır ve paketlenir. Ancak L1 işlemlerin geçerliliğini doğrulamaz, yalnızca işlemlerin sırasını ve kullanılabilirliğini garanti eder. L2, L1 üzerinde paketlenmiş L2 işlemlerini yürüten saf bir yürütücüdür. Bu size tanıdık geliyor mu? Bu Inscription modu değil mi? Evet, inscription'ın Indexer'ı burada L2 olarak anlaşılabilir. Bunu Inscription Bir Hata mı Yoksa Özellik mi? başlıklı makalede belirttim.

Booster Rollup başka bir bakış açısıyla başlar. L1'in durumunu L2'deki sözleşme aracılığıyla doğrudan nasıl okuyabiliriz? Fikir karmaşık değil. Based Rollup zaten L1'de L2 işlemlerini yürüttüğünden, neden L1 işlemlerini de yürütmeyelim? Bu şekilde, L1 ve L2'nin durumları büyük bir durum ağacındadır ve L2 sözleşmesi doğrudan L1'in durumunu okuyabilir.

Aynı şekilde Based Booster Rollup (BBR) adı verilen, Taiko gibi Based Rollup ile Booster Rollup'ı birleştiren projeler de var.

BBR'nin geçmişi

BBR önerildiği zamandan piyasanın dikkatini çektiği zamana kadar, ana arka plan Ethereum'un mevcut ana akım L2 çözümü, L1 ve L2 arasındaki bölünme ve L2 arasındaki bölünme tarafından ortaya çıkarılan bölünme sorunudur. Mevcut L2 çözümünün sağladığı işlevler, ister geliştirici perspektifinden ister kullanıcı perspektifinden olsun, bir Alt-L1'den çok da farklı değildir. L1 verilerini okumak hala Oracle'a bağlıdır, varlıklar hala bir köprüye ihtiyaç duyar ve cüzdanlar ağları değiştirmek zorundadır. Bu bölünme başka bir sorunu da beraberinde getirir. L1 ve L2 arasındaki bağ o kadar sıkı değildir. L2, bir Alt-L1 olmak, kendi başına durmak ve geliştiricileri ve kullanıcıları temelde habersiz kılmak için herhangi bir zamanda bir dizi fikir birliği mekanizması ekleyebilir. Mevcut ana bağlama ilişkisi, EF'lerin ortodoksluk üzerindeki kısıtlamalarından gelir: L2, L1'i DA olarak kullanmalıdır, ancak açıkçası bu kısıtlama güvenilir değildir.

Peki, tüm mevcut L2 çözümlerini Based Rollup çözümleriyle değiştirirsek sorun çözülür mü? Sanırım Optimism ve Arbitrum ortaya çıkıp, Based Rollup'a geçmek kolay değil mi diyecekler. Ana L2 çözümlerinde artık Force Inclusion mekanizmaları var. L2, Sequencer'ı doğrudan kaldırır ve kullanıcıların Force Inclusion aracılığıyla L1'e işlem göndermesine olanak tanır. Based Rollup uygulanmadı mı?

Ancak bu parçalanma sorununu çözebilir mi? Hayır. Arb ve Op her ikisi de işlemleri gerçek zamanlı olarak L1'e gönderse ve L1 paketleri ve bunları sıralasa da, her biri yalnızca kendi işlemlerini tanıdığı için yine de parçalanmış durumdadırlar. Bu noktada, herkes Based Rollup için parçalanma sorununu çözmenin anahtarının L2 arasında paylaşılabilen işlemlere veya verilere sahip olmak olduğunu anlamalıdır ve bu veri biçimi şunları gerektirir:

• Bir format olmalı kesinliklePlatformdan ve uygulamadan bağımsız olan L1'de ned. Farklı L2 hesapları ve sanal makineler farklıdır ve işlemleri doğrudan paylaşılamaz.

• L2'ler arasında fikir birliği ve birden fazla L2'nin desteği gerekiyor.

Bu nedenle, öncelikle bir protokol olmalı, öncelikle genel bir protokol ve veri formatı tasarlanmalı, yalnızca protokol tarafından zincirde gerekli olan veriler depolanmalı, zincir dışında yürütülmeli ve doğrulanmalı ve farklı L2'ler için destek çözümleri uygulanmalıdır. Ancak bu iki noktaya ulaşmak aslında oldukça zordur. Öncelikle, Ethereum ekosistemindeki geliştiriciler genellikle protokolleri akıllı sözleşmeler aracılığıyla tasarlar ve protokolleri doğrudan veri formatlarına dayalı olarak tasarlama alışkanlığına sahip değildir. Bu yöndeki ana girişim, yazıtlar son zamanlarda popüler olduğunda Ethscriptions'dı. İkinci nokta daha da zordur ve doğrulamak için pratik ve zaman gerektirir.

BBR'den BBSR'ye, Yığınlanabilir L2

Veri paylaşımı konusunu konuştuktan sonra, kullanıcı deneyiminden bahsedelim. Açıkçası, tüm işlemler kullanıcılar tarafından doğrudan L1'e gönderilirse, deneyim, ister Gas ister onay zamanı olsun, L1'i kullanmakla hemen hemen aynıdır. Bu yüzden bazı kişiler Based Rollup için bir ön onay protokolü tasarlamaya başladı, ancak ön onay protokolü gerçekten işe yarıyorsa, tüm işlemlerin önce ön onay protokolünden geçmesi gerekiyorsa, o zaman bu bir Sequencer değil midir? Bunu konuşmak zaman kaybı mıdır?

Bu çelişki, insanların birkaç işlem türünü birbirine karıştırmasından kaynaklanmaktadır:

1. Kullanıcılar tarafından doğrudan L1'e gönderilen ve L1 tarafından yürütülen ve doğrulanan işlemlere L1 işlemleri denir.

2. Kullanıcı doğrudan L1'e gönderir, ancak L1 doğrudan doğrulamaz ve yürütmez. L2 arasındaki paylaşımlı protokolün veri işlemi L1.5 işlemi olarak adlandırılabilir.

3. Kullanıcı, işlemi doğrudan L2 Sequencer'a gönderir ve bu işlem Sequencer tarafından önceden onaylanır ve yürütülür; bu, belirli bir L2'nin özel işlemidir.

Based Rollup sadece 1 ve 2 ile ilgilidir. 3, Sequencer Rollup'ın şu anki çalışma yöntemidir. İkisi birleştirilebilir.

Şöyle bir Rollup çözümü olduğunu varsayalım:

1. Sıralayıcı, tüm L1 (L1.5 dahil) işlemlerini otomatik olarak senkronize eder ve bunları L1 tarafından verilen sırayla yürütür.

2. Sequencer, L2 işlemlerini aynı anda alır, bunları L1 işlemleriyle birlikte sıralar ve yürütür.

1 ile, Based ve Booster'ı uygular ve 2 ile, kullanıcı deneyiminden ödün vermeden L2 işlemlerinin hızlı onayını gerçekleştirir. Önceki adlandırma şemasına göre, buna BBSR (Based Booster Sequencer Rollup) denmesi gerekirdi, ancak biraz uzun ve anlaşılması kolay değil, bu yüzden buna Stackable L2 diyorum. Adından da anlaşılacağı gibi, L2, L1 üzerine yığılmıştır ve L2, L1'in tüm işlemlerini ve durumlarını içerir. Bu çözümü @RoochNetwork .

L2 işlemlerinin DA'sı nasıl sağlanır? Rollup mu, Rollout mu?

Yukarıdaki çözüm benimsenirse, L2'nin kendi işlemlerini paketleyip tekrar L1'e göndermesi biraz garip olacaktır, çünkü L2 kendi işlemlerini paketleyen L1 işlemlerini okuyacak ve yeniden yürütecektir; bu da kendi çıktısının aynı zamanda kendi girdisi haline gelmesine benzer. Bu nedenle, Rooch'un çözümü Rollup yerine Rollout'tur. Çünkü uzun vadede L1'in blok alanı çok değerlidir ve L1'in alanını kaplayan birden fazla L2 işlemi bir rollout modudur. L1'in alanı L1 ve L1.5 işlemleri için bırakılmalıdır. L2 uygulama düzeyindeki işlemler daha ucuz blok alanı aramalı ve rollout yoluyla yeni blok alanını genişletmelidir; bu aynı zamanda tüm endüstri ekosisteminin gelişimine de elverişlidir.

Bitcoin Ekosisteminde BBSR/Yığınlanabilir L2 Uygulaması

Önceki açıklamaların hepsi Ethereum perspektifindendir. Rooch, Bitcoin'in ilk BBSR veya Stackable L2 uygulaması olduğundan, Bitcoin ekosistemindeki farklılıklardan bahsedelim.

Bitcoin L2'de Turing-complete akıllı sözleşmesi yoktur, bu da Based Rollup modunda bir avantaj haline gelir. Based Rollup'ın işlemleri yürütmek ve doğrulamak için L1'e ihtiyacı olmadığından, yalnızca Permission Less ve DA'yı sağlaması gerekir. Bu ayrıca Bitcoin ekosistemindeki projeleri uzun zaman önceki veri yapılarını temel alan protokoller tasarlamaya zorladı. İster renkli paralar, ister daha sonraki RGB, Taproot Assets, Ordinals Inscription, Atomicals, Runs, vb. olsun, hepsi bu kategorideki girişimlerdir ve CSV (İstemci Tarafı Doğrulama) protokolünün geniş konseptine dahil edilebilir. İşlemleri tipik L1.5 işlemleridir. Ethereum ekosistemindeki projeler Based L2 uygulamak ve birden fazla L2 arasında paylaşılan bir protokol tasarlamak isterlerse, yukarıdaki protokolle aşağı yukarı aynı olacaktır.

Bitcoin'de BBSR'nin çalışma modunu açıklamak için Rooch'u örnek alalım:

1. Kullanıcılar L1 ve L1.5 işlemlerini doğrudan Bitcoin'e gönderecekler. Protokol herkese açık olduğundan, giriş noktası herhangi bir uygulama olabilir.

2. Rooch tüm L1 işlemlerini senkronize edecek, içlerindeki UTXO'ları işleyecek ve ek protokol bilgisi olup olmadığını bulacak ve ardından işlemek için karşılık gelen Move modülünü kullanacaktır. Örneğin, Inscription olarak tanımlanan işlemler ord modülü tarafından işlenirken, Babylon Staking işlemleri bbn modülü tarafından işlenecektir.

3. Kullanıcılar L2 işlemlerini doğrudan işlenmek üzere Roochs Sequencer düğümüne gönderir. Yukarıdaki üç işlemin yürütme sonuçları tam bir durum ağacı oluşturacaktır ve uygulama sözleşmesi L1 ve L1.5 işlemleri tarafından oluşturulan durumları tam olarak kullanabilir.

Bu moddaki uygulamalar iki tür işlem tasarlayabilir, biri genel protokol işlemidir (Based part, on L1) ve diğeri uygulama işlemidir (Sequencer tarafından sıralanır). İkisi, Permission Less'i garanti altına alırken aynı zamanda kullanıcı deneyimini de garanti altına almak için Booster modu aracılığıyla birbirleriyle işbirliği yapabilir.

Daha önce de belirtildiği gibi, kamu protokollerinin tasarımı, doğrulama ve fikir birliğine varma için zaman ve pratik gerektirir ve Rooch, böylesine kullanışlı bir deneysel ortam sağlayabilir: Bitcoin üzerinde yeni bir uygulama veya varlık protokolü tasarlamak istiyorsanız, yalnızca protokol formatını tanımlamanız ve ardından işlemek için karşılık gelen bir Move sözleşme modülünü dağıtmanız gerekir ve ardından uygulama senaryoları oluşturarak deneyler yapabilirsiniz.

Elbette Bitcoin ekosistemi bu yolda bazı zorluklarla da karşı karşıya:

1. Bitcoin ilk tasarlandığında, bu DA senaryosu için genişlemeye yetecek kadar alan bırakmamıştı. Bu nedenle, Bitcoin'e veri yazmanın nasıl yapılacağı, çeşitli protokollerin keşfetmeye çalıştığı yönlerden biriydi, örneğin OP_RETURN'e, Witness aracılığıyla ve hatta imzalar aracılığıyla veri yerleştirmek gibi. Şu anda, hala standartlaştırılmış çözümlerden yoksun.

2. Bitcoin ekosistemi, zincirdeki gömülü verilerin değeri konusunda geniş bir fikir birliğine varamadı. Son yazıt çılgınlığından beri çağrıda bulunduğum şey buydu. Bitcoin ekosistemi, Bitcoin'in küresel bir kamu veri yolu olarak değerine önem vermelidir.

L1'in küresel ortak veri yolu olarak değeri

DeFi yazından beri, tüm Kripto alanı DeFi ötesinde yeni uygulamaları araştırıyor. İster Bitcoin yazıt çılgınlığı olsun, ister son zamanlardaki Based Rollup sıcak tartışması olsun, bu L1'in bir veri yolu olarak değerinin yeniden keşfi olarak anlaşılabilir. Dağıtılmış sistemler perspektifinden, sistemler arasındaki ayrıştırma veri yolu aracılığıyla sağlanabilir ve sistemler arasındaki ayrıştırma, daha az izin elde etmek için temel ön koşullardan biridir. Örneğin, Kripto ekosistemindeki merkezi olmayan borsa, geleneksel finansal sistemde doğrudan elde edilmesi zor olan merkezi olmayan yerleştirmeyi elde etmek için Veri Yolu olarak blok zincirini tam olarak kullanmıştır. Daha karmaşık uygulamaları desteklemek istiyorsanız, uygulama düzeyinde daha az izin elde etmek için basit transfer işlemlerini uygulama protokolü işlemlerine yükseltmeniz yeterlidir ve bu yöntem mevcut uygulamalar için en az müdahaleci olanıdır.

Bu makale BBR'yi esas olarak ekoloji ve uygulama perspektifinden ele almaktadır. BBR modunun güvenliği ve BBR modu altında L1, L1.5 ve L2 durumlarının birlikte çalışabilirliği daha sonraki makalelerde ayrıntılı olarak ele alınacaktır. Bazı ilgili bağlantılar, tarihsel makalelerim ve Twitter arkadaşlarım tarafından farklı perspektiflerden Based Rollup'ın açıklamaları dahil olmak üzere sonuna eklenmiştir.

İlgili Bağlantılar:
1. Yığınlanabilir L2 — Yeni bir blok zinciri genişletme çözümü https://rooch.network/zh-CN/blog/stackable-l2

2. Bitcoin'in 2. katmanı nasıl yapılmalı? https://x.com/jolestar/status/1717358817992995120 İlk planı L2'nin Bitcoin L1'deki durumu ve verileri nasıl kullandığına dayanarak tasarladım. Bir arkadaşım yorumlarda Booster çözümünden bahsetti ve sonunda Booster çözümünü pratikte benimsedi.

3. Yazıt bir hata mı yoksa bir özellik mi? https://x.com/jolestar/status/1732711942563959185 Bu makale, L2'nin nasıl oluşturulduğu perspektifinden yazıtların değerini, L1 ve L2 arasındaki teşvik uyumluluğu sorunu da dahil olmak üzere açıklamaktadır.

4. Çıkarma teorisi perspektifinden Tabanlı Toplama üzerine tartışma @kerne l1 983 https://web3 caff.com/zh/archives/108241

5. @jason_chen 998'in Based Rollup'taki makalesi https://x.com/jason_chen998/status/1799692331635048697

6. Tabanlı Toplama İzleme Araştırma Raporu https://research.web3 caff.com/zh/archives/22719

Orijinal bağlantı

Bu makale internetten alınmıştır: Based Booster Rollup'ın derinlemesine analizi: arka plan, uygulama ve beklentiler

İlgili: Ödeme devriminde PayFi'nin güvenli parolaları Web3 finansının özünü koruyor

Bu makale Hash (SHA 1): 8656ff83d95af1de9dab2b925597cf72c6f63c66 No.: Lianyuan Güvenlik Bilgisi No.032 Blockchain teknolojisinin sürekli gelişmesiyle birlikte, finans sektörü benzeri görülmemiş bir dönüşümden geçiyor. Bu bağlamda, ortaya çıkan yeni bir kavram yavaş yavaş ortaya çıktı: PayFi (Ödeme Finansı). Bu terim ilk olarak Solana Vakfı Başkanı Lily Liu tarafından 2024 EthCC konferansında yenilikçi bir ödeme ve finans modeli keşfetmek için önerildi. PayFi'nin vizyonu yalnızca kriptopara birimidir, ancak aynı zamanda merkezi olmayan teknoloji ile para biriminin zaman değerini birleştirerek kullanıcılara daha güvenli, daha hızlı ve daha düşük maliyetli finansal hizmetler sunmayı umuyor. 1. PayFi'nin temel konsepti: paranın zaman değeri ve merkezi olmayan finans PayFi nedir Lily Liu, PayFi'nin temel motivasyonunun Bitcoin'in orijinal vizyonunu gerçekleştirmek olduğunu belirtti…