Rollup'ın Celestia perspektifinden analizi: 6 varyantın direncini ve aktivitesini gözden geçirin

Yazar: NashQ, Celestia'da araştırmacı

Sıralayıcıları Yeniden Tanımlamak: Toplayıcıyı ve Başlık Yapımcısını Anlamak

Derleme: Faust, Geek Web3

Çevirmenin Notu: Toplama modelinin anlaşılmasını ve analiz edilmesini kolaylaştırmak amacıyla Celestia araştırmacısı NashQ**, Toplama'nın sıralayıcısını (Sequencer) iki mantıksal varlığa böldü: toplayıcı ve Başlık oluşturucu. Aynı zamanda, işlem siparişi sürecini üç mantıksal adıma ayırdı: dahil etme, sıralama ve yürütme. **

Bu analitik düşüncenin rehberliğinde, egemen Toplama'nın altı önemli çeşidi daha net ve anlaşılması daha kolaydır. **NashQ, farklı Rollup varyantlarının sansür direncini ve canlılığını ayrıntılı olarak ele aldı ve ayrıca güveni en aza indirilmiş durumda (yani, Güvensiz duruma ulaşmak için Rollup kullanıcılarının çalıştırması gerekenler) her bir Rollup varyantının düğümlerinin minimum yapılandırmasını tartıştı. en azından düğüm türü). **

Bu makale Rollup'ı, Ethereum topluluğunun Rollup modelini analiz etme şeklinden farklı olarak Celestia'nın perspektifinden analiz etse de, Ethereum Rollup ile Celestia egemen Rollup arasındaki birçok ara bağlantıyı ve ikincisinin artan etkisini göz önünde bulundurarak, Rollup için önemlidir. Ethereum meraklıları, bu makale de son derece okumaya değer.

Toplama nedir?

Toplama, "işlem verilerini" başka bir blok zincirinde yayınlayan ve mutabakatını ve veri kullanılabilirliğini devralan bir blok zinciridir.

Neden "bloke" yerine "işlem verileri" kelimesini kasten kullandım? Bu, aşağıdaki ilk değişken gibi yalnızca toplama verilerini gerektiren en kompakt toplamalarla, toplama blokları ve toplama verileri arasında bir ayrım içerir.

Toplama bloğu, blok zinciri defterini belirli bir blok yüksekliğinde temsil eden bir veri yapısıdır. Toplama bloğu, toplama verisi ve toplama başlığından oluşur. Bunların arasında Toplama verileri, bir toplu işlem veya bir toplu işlem arasındaki durum değişiklikleri olabilir.

1. Değişken: Karamsar Toplama / Temelli Toplama

Bir Toplama oluşturmanın en kolay yolu, kullanıcıların işlemleri başka bir blok zincirinde yayınlamasına izin vermektir, buna mutabakat ve veri kullanılabilirlik katmanı (DA-Katmanı) diyeceğiz ve ben buna basitçe aşağıdaki DA-katmanı diyeceğim (Çevirmenin Notu: Ethereum topluluğunda sıklıkla söylenen Katman 1'e benzer).

Tanıtacağım ilk Toplama varyantında, Toplama ağının düğümleri, defterin son durumunu kontrol etmek için DA katmanında bulunan Toplama işlemlerini yeniden yürütmek zorundadır. Bu karamsar bir Toplama!

Karamsar Toplama, yalnızca tam düğümleri destekleyen bir Toplamadır ve bu tam düğümlerin, geçerliliklerini kontrol etmek için Toplama defterinde yer alan tüm işlemleri yeniden yürütmesi gerekir.

Ancak bu durumda, Toplamanın Sıralayıcısı olarak kim hareket eder? Aslında, Toplama'nın tam düğümleri dışında, hiçbir varlık Toplama defterinde yer alan işlemleri gerçekleştirmedi. Genel olarak, sıralayıcı işlem verilerini toplar ve bir Toplama başlığı oluşturur. Ancak yukarıda bahsedilen karamsar Toplama'nın Toplama başlığı yok!

Tartışma kolaylığı için sıralayıcıyı iki mantıksal varlığa ayırabiliriz: Toplayıcı Toplayıcı ve Başlık Oluşturucu. Bir Toplama Başlığı oluşturmak için önce işlemi gerçekleştirmeniz, durum geçişini tamamlamanız ve ardından ilgili Başlığı hesaplamanız gerekir. Ancak bir toplayıcı için, toplama adımına devam etmek için bir durum geçişini tamamlaması gerekmez.

Sıralama Sıralama, "toplama + Toplama Başlığı oluşturma" işlemidir.

Toplama, işlem verilerini bir toplu iş haline getirme adımıdır. Bir toplu iş genellikle birçok işlem içerir (Çevirmenin Notu: Toplu iş, Toplama bloğundaki Başlık dışındaki verilerin parçasıdır).

Başlık oluşturma adımı, bir Toplama Başlığı oluşturma işlemidir. Rollup Header, Rollup bloğu ile ilgili en azından bloktaki işlem verilerinin taahhüdünü içeren meta verilerdir (Çevirmenin Notu: Burada bahsedilen taahhüt, işlem işleme sonuçlarının doğruluğuna dair taahhüdü ifade eder).

Yukarıdaki bakış açısıyla, Toplama'nın her bir bölümünden kimin sorumlu olduğu görülebilir. İlk önce toplayıcı Toplayıcı kısmına bakın. Yukarıda belirtilen karamsar Toplama, Başlık oluşturma işlemine sahip değildir ve kullanıcılar işlemleri doğrudan DA katmanında yayınlar; bu, DA katmanı ağının temelde bir toplayıcı görevi gördüğü anlamına gelir.

Bu nedenle, kötümser Toplama, toplama adımını sıralayıcı Sıralayıcısı olmayan DA katmanına devreden bir Toplama çeşididir. Bazen bu tür toplamaya "tabanlı toplama" denir.

Tabanlı Toplama, DA katmanıyla aynı sansür direncine ve etkinliğe sahiptir (etkinlik, sistemin kullanıcı isteklerine geri bildirim hızını ölçer). Bu tür Toplama kullanıcıları, minimum güven durumuna (Güvensiz'e en yakın) ulaşmak istiyorlarsa, DA katmanı ağının en az bir hafif düğümünü ve Toplama ağının tam bir düğümünü çalıştırmaları gerekir.

2. Değişken: Paylaşılan bir toplayıcı kullanarak kötümser toplama

Paylaşılan bir toplayıcı kullanarak kötümser toplamayı tartışalım. Bu fikir Evan Forbes tarafından paylaşılan sıralayıcı tasarımı hakkındaki forum gönderisinde önerildi. Temel varsayımı, paylaşılan bir sıralayıcının işlemleri sıralamanın tek resmi yolu olduğudur. Evan, paylaşılan sıralayıcıların faydalarını şu şekilde açıklıyor:**

"Web2'ye eşdeğer bir kullanıcı deneyimi elde etmek için, paylaşılan sıralayıcı hızlı nesil Esnek Taahhüt sağlayabilir (çok güvenilir bir garanti değildir). Bu Esnek Taahhüt, nihai işlem emri hakkında bazı garantiler sağlar (yani, taahhüt işlem emri değişiklik) ve Toplu defter durumunun güncellenmesi adımları önceden gerçekleştirilebilir (ancak Sonlandırma henüz tamamlanmamıştır).

Toplama bloğu verileri onaylandıktan ve temel katman Temel Katmanına (burada DA katmanına atıfta bulunmalıdır) yayınlandıktan sonra, Toplama defterinin durum güncellemesi sonlandırılır ve sonlandırılır. "

Yukarıda bahsedilen Toplama değişkeni, yine de kötümser Toplama kategorisine aittir, çünkü bu tür Toplama sisteminde yalnızca tam düğümler vardır ve hafif düğümler yoktur. Her Toplama düğümü, genel muhasebe durum güncellemesinin geçerliliğini sağlamak için tüm işlemleri yürütmelidir. Bu tür Toplamanın hafif düğümü olmadığından, bir Toplama Başlığına veya bir Başlık üretecine ihtiyacı yoktur. (Çevirmenin Notu: Genel olarak, bir blok zincirinin hafif düğümlerinin tam blokları senkronize etmesi gerekmez, sadece blok başlıklarını alır)

Toplama Başlığı oluşturma adımı olmadığından, yukarıda belirtilen Toplama paylaşımlı sıralayıcının durum güncellemeleri için işlemleri yürütmesi gerekmez (Başlıklar oluşturmak için bir ön koşul), ancak yalnızca işlem verilerini toplama sürecini içerir. Bu yüzden ona paylaşılan toplayıcı, paylaşılan toplayıcı demeyi tercih ediyorum.

Bu değişkende, Toplama kullanıcılarının en azından güven düzeyi en aza indirilmiş bir durumda DA katmanı hafif düğümleri + paylaşılan toplayıcı ağının hafif düğümleri + Toplama tam düğümlerini çalıştırması gerekir.

Bu noktada, yayınlanan toplayıcı başlığının (burada Toplama Başlığı değil) toplayıcı ağını paylaşan hafif düğümler tarafından doğrulanması gerekir. Yukarıda bahsedildiği gibi paylaşımlı toplayıcı, işlemlerin sıralama işini üstlenir.Yayınlanan toplayıcı başlığında, DA katmanında yayınladığı Batch'e karşılık gelen bir kriptografik taahhüt içerir.

Bu şekilde Toplama düğümü operatörü, DA katmanından alınan toplu Toplu İş'in başkaları tarafından değil, paylaşılan toplayıcı tarafından oluşturulduğunu doğrulayabilir.

• Dahil etme, işlemleri blok zincirine dahil etme işlemidir.
• Sıralama Sıralaması, blok zincirindeki işlemlerin belirli bir sırayla düzenlenmesi sürecini ifade eder.
• Yürütme, blok zincirindeki işlemlerin işlenmesi ve durum güncellemelerinin tamamlanması sürecini ifade eder.

Paylaşılan toplayıcı, dahil etme ve sıralama işlemlerini üstlendiğinden, Rollup'ın sansür direnci buna bağlıdır.

L_ss'nin paylaşılan toplayıcının etkinliği ve L_da'nın DA-Katmanının etkinliği olduğu varsayılırsa Toplama modelinin etkinliği L = L_da && L_ss olur. Başka bir deyişle, iki parçadan herhangi birinde bir canlılık hatası varsa, Toplama'da da bir canlılık hatası vardır.

Kolaylık olsun diye canlılığa bir bool değeri olarak bakacağım. Paylaşılan toplayıcı başarısız olursa Toplama çalışmaya devam edemez. DA katmanı ağı başarısız olursa, paylaşılan toplayıcı, Toplama blokları için Esnek Taahhüt sağlamaya devam edebilir. Ancak şu anda, Toplama'nın öznitelikleri tamamen paylaşılan toplayıcı ağına bağlı olacaktır ve ikincisinin öznitelikleri genellikle orijinal DA katmanından çok daha düşüktür.

Yukarıdaki Toplama planının sansür direncini keşfetmeye devam edelim:

Bu şemada, DA katmanı bazı belirli işlemleri inceleyemez (Çevirmenin Notu: İşlem incelemesi genellikle belirli işlemlerin zincire yüklenmesine izin vermeyi reddedebilir), yalnızca paylaşılan toplayıcı tarafından gönderilen tüm işlem grubu için başlayabilir İşlem incelemesi (Bir Partinin DA katmanına dahil edilmesine izin vermeyi reddetti).

Bununla birlikte, Toplama iş akışına göre, paylaşılan toplayıcı, işlem grubu Yığını DA katmanına gönderdiğinde, işlem sıralamasını zaten tamamlamış ve farklı yığınlar arasındaki sıra da belirlenmiştir. Bu nedenle, DA katmanındaki bu tür bir işlem incelemesinin, Toplama defterinin nihai onayını geciktirmek dışında başka bir etkisi yoktur.

Özetle, sansüre karşı koymanın amacının tek bir varlığın sistem içindeki bilgi akışını kontrol edememesini veya manipüle edememesini sağlamak olduğuna inanıyorum. yüzleşme davranışı. Bu, mevcut ana akım akademik tanımla çelişse de, yine de kavramın ifade ettiğim tanımını kullanacağım.

Varyant 3: Temel Toplama ve Paylaşılan Toplayıcıya dayalı Kötümser Toplama

Paylaşılan toplayıcı, kullanıcılara ve topluluğa fayda sağlasa da, ona aşırı güvenmekten kaçınmalı ve kullanıcıların paylaşılan toplayıcıdan DA katmanına çekilmesine izin vermeliyiz. Daha önce tanıtılan iki Toplama varyantını birleştirerek, kullanıcıların paylaşılan bir toplayıcı kullanırken işlemleri doğrudan DA katmanına göndermesine izin verebiliriz. **

Nihai Toplama işlem sırasının, paylaşılan toplayıcı tarafından gönderilen işlem sırasına ve kullanıcılar tarafından doğrudan DA katman bloğunda gönderilen Toplama işlemlerine bağlı olduğunu varsayıyoruz. Buna Rollup'ın çatal seçim kuralı diyoruz.

Toplama burada iki adıma ayrılmıştır. İlk olarak, bazı işlemleri toplayan paylaşılan bir toplayıcı devreye girer. Daha sonra DA katmanı, paylaşılan toplayıcı tarafından gönderilen Partiyi ve doğrudan kullanıcı tarafından gönderilen işlemleri toplayabilir.

**Sansüre dayanıklılık analizi bu noktada biraz daha karmaşıktır. **DA katmanı ağ düğümleri, bir sonraki DA katmanı bloğu üretilmeden önce paylaşılan toplayıcı tarafından gönderilen Toplu İşi gözden geçirebilir. Toplu İşlemdeki işlem verilerini öğrendikten sonra, DA katmanı düğümleri MEV değerini çıkarabilir. Ağdaki hesaplar ön- çalışan işlemleri ve bunları önce DA katman bloğuna dahil edin ve ardından Toplama paylaşımlı toplayıcı tarafından gönderilen toplu işi dahil edin.

Açıkçası, üçüncü tip Toplama varyantının yumuşak taahhüdü ile garanti edilen işlem emrinin kesinliği, yukarıda belirtilen ikinci tip Toplama varyantından daha kırılgandır. Bu durumda, paylaşılan toplayıcı, MEV değerini DA katman düğümlerine teslim etti. Bu bağlamda, okuyucuların karlı sansürlü MEV'den yararlanma konusundaki araştırma dersini izlemelerini tavsiye ederim.

Şu anda, DA katmanı ağ düğümlerinin bu tür MEV işlemlerini yürütme yeteneğini azaltmak için, Rollup ağ kullanıcıları tarafından doğrudan DA katmanına gönderilen işlemlerin yürütülmesini geciktirecek olan "yeniden düzenleme penceresi dönemi" işlevi gibi bazı tasarım şemaları ortaya çıkmıştır. . Sovereign Labs, "tercih edilen sıralayıcı" kavramını tanıtan, Yumuşak Onaylı Temel Sıralama adlı tasarım teklifinde bunu ayrıntılı olarak açıklamaktadır.

MEV sorunu, Rollup tarafından seçilen toplayıcı şemaya ve toplama çatalı seçim kurallarına bağlı olduğundan, bazı şemalar MEV'yi DA katmanına sızdırmayacak ve bazı şemalar MEV'nin bir kısmını veya tamamını DA katmanına sızdıracaktır, ancak bu başka bir konu.

Canlılığa gelince, bu toplama planının, yalnızca paylaşılan toplayıcıların işlemleri DA katmanına göndermesine izin veren şemalara göre avantajları vardır. Paylaşılan bir toplayıcıda canlılık hatası olması durumunda, kullanıcılar yine de işlemleri DA katmanına gönderebilir.

Son olarak, güven minimizasyonu altındaki Rollup kullanıcılarının minimum yapılandırmasından bahsedelim:

En azından DA katmanı hafif düğümü + paylaşılan toplayıcı hafif düğümü + Toplama tam düğümü çalıştırın.

Bu noktada, paylaşılan toplayıcı tarafından yayınlanan toplayıcı başlığını doğrulamak gerekir, böylece toplama tam düğümü çatal seçim kurallarına göre işlem gruplarını ayırt edebilir.

Varyant 4: İyimser Temelli Toplama ve Merkezi Başlık Oluşturucu

Tabanlı İyimser Toplama adlı bir varyantı ve merkezi bir başlık oluşturucuyu tartışalım. **Bu çözüm, Toplama işlemlerini toplamak için DA katmanını kullanır, ancak Toplama hafif düğümlerini etkinleştirmek için Toplama Başlıkları oluşturmak üzere merkezi bir Başlık oluşturucu sunar. **

Toplama ışık düğümleri, tek bir dolandırıcılık kanıtı turu aracılığıyla Toplama işlemlerinin geçerliliğini dolaylı olarak kontrol edebilir. Light node, Toplama Başlığının oluşturucusu konusunda iyimser olacak ve son onayı dolandırıcılığa karşı korumalı pencere dönemi sona erdikten sonra yapacak. Başka bir olasılık da, dürüst bir tam düğümden başlık oluşturucunun hatalı veriler gönderdiğine dair bir sahtekarlık kanıtı almasıdır.

Bu makalenin kapsamı dışında olduğu için burada tek turlu bir dolandırıcılık kanıtının nasıl çalıştığına dair ayrıntılara girmeyeceğim. Tek turlu dolandırıcılık kanıtının avantajı, dolandırıcılık kanıtı penceresi süresini 7 günden belirli bir dereceye kadar kısaltabilmesidir.Spesifik değer henüz belirlenmedi, ancak büyüklük sırası geleneksel iyimser toparlamadan daha küçük. Light node'lar, bir sonraki anlaşmazlık sürecini beklemeden Rollup full node'lardan oluşan P2P ağı üzerinden dolandırıcılık kanıtları elde edebilir, çünkü tüm kriterler tek bir dolandırıcılık kanıtında eksiksiz olarak sağlanır.

Yukarıdaki Toplama modeli, DA katmanını bir toplayıcı olarak kullanır ve sansür direncini devralır. Bu noktada DA katmanı, işlemleri içermek ve sıralamaktan sorumludur. Merkezi Başlık oluşturucu, DA katmanından Toplama işlem sırasını okuyacak ve buna göre karşılık gelen Toplama Başlığını oluşturacaktır. Header oluşturucu, Header ve Stateroot'u DA katmanına yayınlayacaktır. Bu Stateroots, dolandırıcılık kanıtları oluştururken gereklidir. **Kısacası, toplayıcı işlemlerin dahil edilmesinden ve sıralanmasından sorumludur ve Başlık oluşturucu, Stateroot'u almak üzere durumu güncellemek için işlemi yürütecektir. **

DA katmanının (bu noktada Toplama için bir toplayıcı görevi de görür) yeterince merkezi olmayan ve sansüre dayanıklı olduğunu varsayalım. Ek olarak, başlık oluşturucu, toplayıcı tarafından yayınlanan Toplama işlemlerinin sırasını değiştiremez. Şimdi, Header oluşturucu dağıtılmışsa, tek faydası daha iyi canlılıktır, ancak Toplama'nın diğer özellikleri, ilk varyant Tabanlı Toplama ile aynıdır.

Başlık oluşturucu canlılıkta başarısız olursa, toplama da canlılıkta başarısız olur. Hafif düğümler Toplama defterinin ilerlemesini takip edemez, ancak tam düğümler takip edebilir. Bu noktada, Varyant 4'te açıklanan Toplama, Varyant 1'de açıklanan Temel Toplama'ya dönüşür. Görünüşe göre, Varyant 4 tarafından açıklanan güveni en aza indirilmiş minimum yapılandırma şöyledir:

**DA katmanı ışık düğümü + Toplama ışık düğümü. **

Varyant 5: Tabanlı ZK-Toplama ve Merkezi Olmayan Prover Pazarı

Kötümser Toplama (Temelli Toplama) ve İyimser Toplama'yı tartıştık, şimdi ZK-Toplama'yı düşünmenin zamanı geldi. Geçenlerde Toghrul, toplayıcı (Sequencer) ve Header generator (Prover) (Sequencer-Prover Separation in Zero-Knowledge Rollups) ayrımı üzerine bir konuşma yaptı. Bu modelde, yayınlama işlemlerini Durum Farkından ziyade Toplama verisi olarak ele almak daha kolaydır, bu yüzden öncekine odaklanacağım. **Varyant 5, zk-toplamaya dayalı merkezi olmayan bir Prover Market'tir. **

Şimdiye kadar, Toplama'nın nasıl çalıştığını biliyor olmalısınız. Varyant 5, toplayıcı rolünü, işlemleri dahil etme ve sıralama işini yapan DA katmanı düğümlerine devreder. Varyant 5'teki bir işlemin yaşam döngüsüne ilişkin iyi bir açıklama içeren Sovereign-Labs belgelerinden alıntı yapacağım:

Kullanıcı, L1 zincirine (DA katmanı) yeni bir veri bloğu yayınlar. Bu veri blokları L1 zincirinde sonlandırıldığında mantıksal olarak nihaidir (değiştirilemez). L1 zincirinin blokları sonlandırma aşamasına girdikten sonra (yani geri alınamazlar), Rollup'ın tam düğümleri bu blokları tarar, Rollup ile ilgili tüm veri bloklarını sırayla işler ve en son Rollup durum kökü Stateroot'u oluşturur. . Bu noktada, Toplama tam düğümleri açısından, bu veri blokları son haline getirilmiştir.

Bu modelde Header oluşturucu, merkezi olmayan Prover Market tarafından hareket ettirilir.

Prover prover düğümünün (ZKVM'de çalışan tam bir düğüm) çalışma süreci, karşılık gelen sıfır bilgi Kanıtını oluşturmak ve yayınlamak için DA katmanı blok zincirini tarayan ve tüm Toplama işlem gruplarını sırayla işleyen normal bir Toplama tam düğümününkine benzer. DA katman zincirinde. (Toplama sistemi kanıtlayıcıyı motive etmek istiyorsa, kanıtlayıcının oluşturulan ZK kanıtını DA katman zincirine göndermesi gerekir, aksi takdirde hangi kanıtlayıcının önce ZK kanıtını gönderdiğini belirlemek mümkün olmayacaktır). Belirli bir işlem grubuna karşılık gelen ZK kanıtı zincire serbest bırakıldığında, işlem grubu tüm Rolup düğümlerinin (hafif düğümler dahil) gözünde sonlandırılır.

Varyant 5, DA katmanıyla aynı sansür direncine sahiptir. Merkezi olmayan Prover Market, Toplama işlemlerini inceleyemez, çünkü DA katmanı yalnızca daha iyi aktivite elde etmek ve teşvik edici bir pazar oluşturmak için standart işlem sırasını zaten belirlemiştir, bu nedenle Başlık oluşturucu (burada Prover'a atıfta bulunulmaktadır) merkezi olmayan değişikliktir.

Buradaki etkinlik L = L_da && L_pm'dir (Prover'ın etkinliği). Prover Market'in teşvikleri tutarsızsa veya aktif bir arıza varsa, Toplama hafif düğümü blok zincirinin ilerlemesini senkronize edemez, ancak Toplama tam düğümü bunu yapabilir. Tam düğüm için bu yalnızca bir geri dönüştür Temel Toplama/Kötümser Toplama'ya. Buradaki güven minimizasyonu için minimum yapılandırma, iyimser Toplama durumundakiyle aynıdır, yani

DA katmanı ışık düğümü + Toplama ışık düğümü.

Varyant 6: Hibrit Tabanlı Toplama + Merkezi İyimser Başlık Oluşturucu + Merkezi Olmayan Kanıtlayıcı

DA katmanı düğümlerinin Toplama toplayıcıları olarak hareket etmesine ve işlemleri dahil etme ve sıralama işini onlara devretmesine izin veriyoruz.

Aşağıdaki şekilden de görebileceğiniz gibi, hem ZK Toplama hem de İyimser Toplama, Toplama defterinin kaynağı olarak DA katmanında aynı sıralı işlem grubunu kullanır. Bu, her iki kanıt sistemini aynı anda kullanabilmemizin nedenidir: DA katmanındaki sıralı işlem grubu, kanıt sisteminden etkilenmez.

Önce kesinlik hakkında konuşalım. Rollup full node açısından bakıldığında, DA katmanının bloğu sonlandırıldığında, içerdiği Rollup işlem toplu işlemi sonlandırılır ve değiştirilemez. Ancak, ışık düğümleri açısından kesinliği daha çok önemsiyoruz. Merkezi Başlık oluşturucunun bazı varlıkları ipotek ettiğini, oluşturulan Toplama Başlığını imzaladığını ve hesaplanan Stateroot'u DA katmanına gönderdiğini varsayalım.

Önceki varyant 4 gibi, hafif düğüm iyimser bir şekilde başlık oluşturucuya güvenecek, verdiği başlığın doğru olduğuna inanacak ve tam düğüm ağından dolandırıcılık kanıtı bekleyecektir. Dolandırıcılık kanıtının pencere dönemi sona ermişse ve tam düğüm ağı dolandırıcılık kanıtını yayınlamamışsa, Toplama ışık düğümü açısından, Toplama bloğu sonlandırılır.

Kilit nokta şu ki, bir ZK kanıtı alabilirsek, dolandırıcılık kanıtı penceresinin bitmesini beklememize gerek kalmaz. Tek turlu dolandırıcılık kanıtlarına ek olarak, dolandırıcılık kanıtlarını ZK kanıtlarıyla değiştirebilir ve kötü niyetli başlık üreteçleri tarafından üretilen yanlış başlıkları atabiliriz!

Hafif düğümler, bir Toplama işlemi grubu için bir ZK kanıtı aldığında, toplu işlem sonlandırılır.

Artık hızlı Esnek Taahhüdümüz ve hızlı kesinliğimiz var.

Varyant 6, DA katmanına dayandığından, DA katmanıyla aynı sansür direncine sahiptir. Canlılık için, L = L_da && (L_op || L_pm) olacak, yani canlılık garantileri ekleyeceğiz. Merkezi Header oluşturucuda veya merkezi olmayan Prover Market'te bir canlılık hatası varsa, ikisinden diğerine dejenere olabiliriz.

Bu değişkende, kullanıcı güvenini en aza indirme için minimum yapılandırma şöyledir:

**Bir DA katmanı ışık düğümü + bir Toplama ışık düğümü. **

Özet:

1. Toplama - Sıralayıcı'nın kilit rolünü iki mantıksal bileşene ayırdık:

Toplayıcılar ve Başlık üreteçleri.

2. Sequencer'ın çalışmasını üç mantıksal sürece ayırıyoruz: çevreleme, sıralama ve yürütme.

3. Kötümser toplama ve temel toplama bir şeydir.

4. İhtiyaçlarınıza göre farklı toplayıcı ve başlık oluşturucu çözümleri seçebilirsiniz.

5. Bu gönderide tanıtılan her Toplama varyantı, aynı tasarım modelini izler:

Son olarak bazı düşüncelerim var. Lütfen şunları düşünün:

• Klasik Toplama (Ethereum Toplamasına atıfta bulunur) yukarıdaki varyantlara göre nasıl sınıflandırılır?
• Tüm varyantlarda, toplayıcının yalnızca dahil etme + sıralamadan ve Başlık oluşturucunun işlemi gerçekleştirmesinden sorumlu olmasına izin veriyoruz. Toplayıcı yalnızca işlemleri dahil etmekten sorumluysa ve başlık oluşturucu işlemleri sıralamaktan ve yürütmekten sorumluysa ne olur? On-chain müzayede adımının girişini göz önünde bulundurursak, bu üç adımı tamamen ayırabilir miyiz?
• Paylaşılan Başlık Üreticisi/Başlık Üretici Pazarı nedir?
• MEV değerini kim yakalar? Kullanıcı geri alabilir mi?