Celestia Araştırmacısı: 4 Yeni Toplama Şemasının Yorumlanması

Orijinal Yazar: NashQ, Celestia

Derleme: Bağlantı, "Geek web3"

Giriş: Bu makale, Celestia araştırmacısı NashQ'nun 4 yeni Rollup varyantını içeren Rollup modelinin analizi üzerine dağınık konuşmalarından oluşmaktadır. Daha önce Celestia Perspektifinden Toplama Analizi: Sansür Direnci ve 6 Varyasyonun Etkinliği başlıklı makalesinde 6 farklı Toplama modeli listeledi ve bu makale, bu Toplama modeline dayalı olarak yeni soyutladığı 4 kategoridir.

Daha önce NashQ, Sequencer'ı iki modüle ayırdı: toplayıcı + Başlık Üreticisi. İşlem talimatlarının yaşam döngüsünden başlayarak, Celestia'nın bağımsız Rollup'ının çalışma prensibini açıkladı, sansür önleme ve farklı Rollup varyantlarının etkinliği ile kullanıcı deneyimini tartıştı. • Güveni en aza indirme öncülündeki minimum yapılandırma (yani, Güvensizliğe ulaşmak için, Toplama kullanıcılarının en az hangi tür düğümleri çalıştırması gerekir).

Varyant 7: Tabanlı Toplama+Çoklu Başlık Üreticileri+"en yüksek Protokol MEV"

Bu Toplama varyantında, Toplama ağı kullanıcıları işlem verilerini doğrudan DA katman bloklarına yayınlar ve ardından İşlem sıralamasından Başlık Üreticisi sorumludur ve MEV onun tarafından çıkarılır. Açıkçası, Toplama Varyantı 7'nin işlem toplama/dahil etme süreci, daha önce tanıtılan DA katmanının sorumluluğunda olan Temel Toplama ile aynıdır (kullanıcılar işlemleri doğrudan DA katmanına gönderir), ancak işlem sıralaması Tabanlı Toplama'dan farklıdır. Toplama ve DA katman düğümleri sorumlu değildir Sıralama, HP'nin (Başlık Üreticisi) sorumluluğundadır.

Aşağıdakiler, birbiriyle rekabet eden ve "en yüksek Protokol MEV" olarak adlandırılan MEV tahsis protokolüne uyan üç HP olduğunu varsayar. Bu protokol, Cosmos ekosisteminin Atlama Protokolü tarafından önerilmiştir.Ethereum PBS şemasının aksine, Blok Oluşturucunun, blok zinciri ağının Doğrulayıcısına ek bir "bahşiş" ödemesi gerekir ve Oluşturucu tarafından en çok ipucu ile oluşturulan blok, Doğrulayıcılar tarafından kabul edilmelidir. Aynı zamanda, SKIP Protokolü, genel zincir ağındaki tüm Doğrulayıcıların ve toplulukların MEV'yi tahsis etme özerkliğine sahip olmalarına ve Ethereum PBS'deki Oluşturucuların giderek daha fazla hale gelmesi sorununu çözmelerine izin vermeyi amaçlayan "egemen MEV" kavramını önerdi. volan etkisi nedeniyle daha merkezi (ancak bu makalenin özü bu değil).

Bu makalede tanıtılan Toplama varyantında, farklı Başlık Üreticilerinin, kendileri tarafından oluşturulan Toplu Başlıkta bahşiş miktarını beyan etmeleri gerekir ve en fazla bahşişi ödeyen HP tarafından verilen Toplu Başlık, Toplama düğümleri tarafından (defter aracılığıyla) otomatik olarak kabul edilir. düğüm kodunda yazılı Çatal seçim algoritması otomatik olarak yapılır).

Ek olarak, HP tarafından yayınlanan Batch Header, DA katmanındaki tam toplu işlem Batch'ine karşılık gelebilmelidir.

HP tarafından yayınlanan Başlıkta bir hata varsa, örneğin, işlem yürütme sonucu Stateroot yanlışsa veya gruptaki bir işlem dahil edilmemişse (kayıp işlem), dürüst Toplama tam düğümü, ışık düğümüne Dolandırıcılık kanıtı yayınlayacaktır. . Ancak genellikle (iyimser olarak), hafif düğümler HP tarafından verilen Başlığı kabul edebilir ve bununla ilgili bir sorun olmadığına inanabilir.

Sansüre dayanıklılık analizi: Bu Özette, işlem incelemesi yapabilen 2 nokta vardır. İlki, işlem içeriğini sansürleyebilen ve belirli kullanıcıları içeren işlemleri reddedebilen DA katmanında bulunur. İkinci sıra, HP tarafından gönderilen başlığı inceleyebilen ve belirli bir başlığı eklemeyi reddedebilen DA katmanında hala mevcuttur, böylece inceleme saldırıları yoluyla MEV'yi tekeline almak için başlıkla işbirliği yapabilir.

Aynı zamanda, işlemlerin sıralanmasından HP sorumludur.Dolandırıcılık kanıtlarının varlığı nedeniyle (HP'nin işlemleri kaybettiği durumda hedef alınabilir), HP'nin kendisi genellikle sansür saldırıları başlatmaz, ancak düğümlere rüşvet verebilir. Bunu yapmak için DA katmanının (veya bazı DA katmanlarını kendi başına çalıştır) düğümü). Bunun çözümü, Rollup işlem dizisinin sonuçlandırılması için pencere periyodunu uzatmaktır, böylece kötü niyetli DA katmanı düğümleri tarafından reddedilen Header, pencere süresi bitmeden dürüst DA katman düğümleri tarafından zincire dahil edilebilir ve böylece artan DA katman düğümü incelemesi Saldırının zorluğu.

**Etkinlik:**L = L_da && ( L_hp1 || L_hp2 || L_hp3 )

DA katmanında bir canlılık hatası varsa, Toplamada da bir canlılık hatası olacaktır. Buna dayanarak, Toplama, yalnızca tüm HP'ler canlılıkta başarısız olduğunda canlılıkta başarısız olur.

Varyant 8: Paylaşılan Toplayıcının ZK Toplaması + Merkezi Olmayan Kanıtlayıcı

Varyant 8, işlem dahil etme + sıralama için paylaşılan toplayıcıyı (SA) kullanır.SA, DA katmanına toplu işlem dizisi yayınlar.İşlem dizisi DA katmanına gönderildikten sonra, işlem sırası teorik olarak değişmez.

Yığın DA katmanına gönderilmeden önce, paylaşılan toplayıcı SA ilk olarak Yığın+ SA Başlığını tam düğüme ve Prover'a yayınlayabilir ve SA Başlığını hafif düğüme yayınlayabilir, ancak DA katmanında olmayan Yığın şu anda hala kararsız ve herhangi bir zamanda bloke olabilir. değiştirin.

Paylaşılan toplayıcı SA tarafından verilen başlığın, HP tarafından verilen toplu iş başlığı ile aynı olmadığına dikkat edilmelidir. SA Başlığı, DA katmanından Toplama düğümü tarafından okunan Batch'in gerçekten SA tarafından üretildiğinden ve başkaları tarafından taklit edilmediğinden emin olmak için kriptografik kanıtlar içerir.

Prover, DA katmanından işlem toplu Toplu İşini okur (ayrıca paylaşılan toplayıcıyla doğrudan senkronize edilebilir), bir ZK Prova+Batch Header oluşturur ve bunu DA katmanında yayınlar. Açıkçası Prover, HP rolünü oynadı.

Toplama'nın hafif düğümleri için, ZKProof'u aldıktan sonra, bu Grupta yer alan işlem dizisi nihayet onaylanır. Tabii ki Prover, hafif düğümler tarafından daha hızlı alınabilmesi için DA katman zinciri altındaki Rollup p2p ağı üzerinden ZKP'yi de yayınlayabilir, ancak şu anda ZKP DA katmanına gönderilmedi ve " kesinlik".

• **Sansüre dayanıklılık: **Varyant 8'de, DA katmanı belirli belirli işlemler üzerinde sansür saldırıları gerçekleştiremez, ancak yalnızca paylaşılan toplayıcı tarafından gönderilen tüm işlem grubu üzerinde inceleme saldırıları gerçekleştirebilir. Aynı zamanda, paylaşılan toplayıcılar belirli kullanıcıların işlemlerini paketlemeyi reddedebilir.
• **Etkinlik: **L = L_da && L_sa && L_pm. Bu değişkende, herhangi bir parçada bir canlılık hatası varsa, Toplama'da bir canlılık hatası olacaktır. Prover başarısız olursa, hafif düğümler Toplama defterinin ilerlemesini etkili bir şekilde senkronize edemez. Bununla birlikte, tam düğüm, tüm işlem dizisi gruplarını senkronize ettiğinden, defterin ilerlemesine ayak uydurabilir. Şu anda, tüm düğümler etkilenmeyecek ve daha önce tanıtılan bir paylaşılan toplayıcı kullanan Tabanlı Toplama durumuna eşdeğer olan tüm hafif düğümler başarısız olacaktır.
• **Güven minimizasyonu için minimum yapılandırma: **DA katmanı hafif düğümü + paylaşılan toplayıcı ağ ışığı düğümü + Toplu ışık düğümü

Varyant 9: Paylaşılan toplayıcı + merkezi olmayan Prover + birden çok DA'lı ZK-Toplaması

Varyant 9, aslında yukarıdaki varyant 8'i temel alır, ancak birden fazla DA katmanına sahiptir ve bu, Toplama etkinliğini etkili bir şekilde geliştirebilir. Varyant 9'da, paylaşılan toplayıcı SA, Batch işlem dizisini herhangi bir DA katmanında yayınlayabilir ve kendi ihtiyaçlarına göre verileri yayınlamak için farklı DA katmanları seçebilir, böylece Rollup'ın ilgili parametrelerini dinamik olarak optimize edebilir, örneğin: veri maliyeti , güvenlik, canlılık, işlem gecikmesi ve kesinlik.

Rollup proje tarafının ihtiyacına göre en ucuz, en güvenli, en aktif ve yerleşim hızı Rollup özelleştirilebilir ve en yüksek verime sahip DA katmanı seçilebilir. Genel olarak konuşursak, belirli bir Toplama bloğu yüksekliğine (10.000'inci gibi) sahip Yığınların aynı anda farklı DA katmanlarında bulunması gerekmez, ancak varsa içeriklerinin tutarlı olması gerekir. Farklı DA katmanlarında aynı yüksekliğe ve farklı içeriğe sahip iki grup görünüyorsa, bu paylaşılan toplayıcının defteri kasten çatalladığı anlamına gelir.

Burada, Prover'ın Header Producer olarak hareket ettiği ve Batch Header ve ZKProof'u yayınladığı Variant 8 ile aynı merkezi olmayan Prover Market'i seçiyoruz. Bu noktada Prover'ın Varyant 7'de belirtilen (SKIP Protokolü tarafından önerilen) bahşiş açık artırma mekanizmasıyla rekabet etmesi gerekir.

Varyant 9'un işlem yerleşim hızı (son onay hızı), en hızlı blok üretimine sahip DA katmanından etkilenir.

Sansüre karşı direnç: Paylaşılan toplayıcılar sansür saldırılarına girişebilir, ancak daha fazla isteğe bağlı DA katmanıyla DA katmanlarıyla ilgili sansür saldırıları olasılığı azalır.

**活性：**L = ( L_da1 || L_da2) && L_sa && L_pm。

Varyant 9, önceki varyanttan daha aktifti. Tüm DA katmanı ağları canlı arızalar yaşamadığı sürece her şey yolunda gidecektir.

Güven minimizasyonu için minimum yapılandırma: farklı DA katmanlarının hafif düğümleri + paylaşılan toplayıcı ağ ışık düğümleri + Toplama ışık düğümleri.

Açıkçası, ne kadar çok DA katmanı benimsersek, o kadar çok hafif düğüm çalıştırmamız gerekir. Ancak bunu yapmanın faydaları, maliyetlerinden daha ağır basabilir.

Varyant 10: Her biri zincir üzerinde hafif bir düğüme sahip iki ZK Toplama + merkezi olmayan Prover (köprü kurulabilir)

Varyant 10, birbiriyle köprü kurabilen 2 ZK Toplama oluşturmak için Varyant 5'in bir uzantısıdır. Varyant 5 (Tabanlı Toplama+ZKP+Merkezi Olmayan Prover) ile karşılaştırıldığında, Varyant 10, Batch Header+ZK-Proof'u bir işleme dönüştüren ek bir aktarıcı rolüne sahiptir. Bu işlem, Rollup2 üzerinde çalışan Rollup1 light node'a gönderildiği sürece, Batch'in belirli bir yüksekliğinin geçerli olduğunu kanıtlayabilir. Elbette, Rollup2 ayrıca DA katmanını çalıştıran hafif düğümler gerektirir.

Bu, zincir köprüler arasındaki güveni minimumda tutmak için bir ön koşuldur. Ancak Ethereum Rollup'tan (akıllı sözleşmeye dayalı SC Rollup) Ethereum'a çapraz zincir ise, Rollup'ın DA katmanı hafif düğümünü çalıştırmaya gerek yoktur, çünkü DA katmanı Ethereum'un kendisidir. Bu, Celestia'nın, Toplamaları birbirine yayılan ve diğer tarafın DA katmanının hafif düğümlerini çalıştırması gereken bağımsız Toplamasından çok farklıdır.

Relayer bir zincirler arası işlem gönderdiğinde, Rollup2'nin Toplayıcı 2 ve HP2 tarafından işlenecektir. Rollup2'nin düğümlerinin Rollup'lar genelinde işlemleri nasıl işlediğini anlamak için her ikisini de grafiğe ekliyoruz.

Rollup2 Relayer, Rollup 2'nin Parti Başlığını ve ZKP'sini alacak ve onları Rollup1'e geri gönderecektir. Toplama 1 ayrıca bir Toplama 2 ışık düğümüne ve bir DA katmanı ışık düğümüne sahiptir.

Modeli daha basit hale getirebiliriz. İki Toplamanın aynı paylaşılan toplayıcıyı ve Başlık Üreticisini kullandığını, başka bir deyişle kullandıkları DA katmanlarının çakıştığını varsayalım.

Bu durumda, Aktarıcı doğrudan yasaklanabilir. Toplu İş Başlığı ve ZK Kanıtı, HP tarafından aynı DA katmanında yayınlandığından, başka bir Toplamanın Üstbilgisi ve ZKP'si gibi veriler doğrudan DA katmanında okunabilir ve artık paylaşılan toplayıcıya iletilmesi gerekmez. Röle.

Açıkçası, aynı DA katmanını kullanan Toplama, Relayer'a bağlı olmak zorunda değildir (birçok zincirler arası köprü, röle düğümlerine dayanır). Bu, zincirler arası köprünün güvenlik sorununu çözebilir (bu bakış açısından, SC Rollups of Ethereum arasındaki çapraz açıklık, farklı genel zincirler arasındaki çapraz zincirden daha güvenlidir).

Şu anda, **güven minimizasyonunun minimum yapılandırması: **DA katmanı ışık düğümü + Toplama ışık düğümü.