• İletilen orijinal başlık: Celestia araştırmacısı 6 Rollup varyantını analiz ediyor: Sıralayıcı = toplayıcı + Başlık oluşturucu

Not: Toplama modelinin anlaşılmasını ve analiz edilmesini kolaylaştırmak amacıyla Celestia araştırmacısı NashQ, Toplama Sıralayıcısını iki mantıksal varlığa ayırmıştır - Toplayıcı ve Başlık Üreticisi. Aynı zamanda, işlem sıralama sürecini üç mantıksal adıma ayırdı: dahil etme, sıralama ve yürütme.

Bu analitik düşüncenin rehberliğinde, Sovereign Rollup'ın altı ana varyantı daha net ve anlaşılması daha kolaydır. NashQ, farklı Rollup varyantlarının sansür direnci ve canlılığının yanı sıra güven minimizasyonu durumundaki her bir Rollup varyant düğümünün minimum konfigürasyonunu (yani, güvensiz bir duruma ulaşmak için, en azından Rollup kullanıcılarının ne tür düğümler çalıştırması gerektiğini) ayrıntılı olarak tartıştı.

Bu makale Rollup'ı Ethereum topluluğunun Rollup modelini analiz etme şeklinden farklı olarak Celestia perspektifinden analiz etse de, Ethereum Rollup ve Celestia Sovereign Rollup arasındaki birçok bağlantı ve Celestia'nın artan etkisi göz önüne alındığında, bu makale Ethereum meraklıları için de son derece okunmaya değerdir.

Toplama nedir?

Rollup'lar, işlem verilerini başka bir blok zincirine gönderen ve onun mutabakatını ve veri kullanılabilirliğini devralan blok zincirleridir.

Neden burada "blok" kelimesini "işlem verisi" olarak değiştiriyorum? Size bir rollup bloğu ile rollup verileri arasındaki farkı anlatayım ve ilk varyantımızla minimal rollup'ın yalnızca rollup verilerine ihtiyaç duyduğunu göstereyim.

Toplama bloğu, blok zincirini belirli bir yükseklikte temsil eden bir veri yapısıdır. Toplama verileri ve toplama başlığından oluşur. Toplama verileri ise ya bir işlem grubu ya da işlem grupları arasındaki durum farkıdır.

Varyant 1 : Kötümser Toplama Tabanlı

Bir toparlama oluşturmanın en basit yolu, bir kullanıcının başka bir blok zincirine işlem göndermesiyle başlar. Bu blok zincirini mutabakat ve veri kullanılabilirliği katmanı olarak adlandıracağız, ancak aşağıdaki tüm diyagramlarda bunu DA-Layer olarak kısaltacağım. (Not: Ethereum topluluğunda sıklıkla atıfta bulunulan Layer1'e benzer).

İlk varyantımızda her toparlama düğümü en yeni durumu kontrol etmek için blok zincirindeki tüm işlemleri tekrar oynatmalıdır. Az önce kötümser bir Rollup oluşturduk!

Kötümser bir toparlama, yalnızca geçerliliğini kontrol etmek için toparlamadaki tüm işlemleri yeniden oynatan tam düğümleri destekleyen bir toparlamadır.

Ancak bu durumda sıralayıcı kimdir? Toplama tam düğümlerinin kendileri dışında hiçbir varlık aslında işlemleri yürütmemektedir. Genellikle bir sıralayıcı işlemleri toplar ve bir toparlama başlığı üretir, ancak bu durumda başlık yoktur!

Tartışmayı kolaylaştırmak için, sıralayıcıyı iki mantıksal varlığa ayırdık: toplayıcı ve başlık üreticisi onu farklılaştırır. Bir varlık durumun farkında olmalıdır (yani, başlığı hesaplamak için durumu yürütmelidir), ancak toplayıcının durumu toplayabilmesi için durumu anlaması gerekmez.

Sıralama, toplama ve başlık üretim sürecidir.

Birleştirme, işlemlerin tek bir parti halinde toplanması işlemidir. Bir işlem grubu bir veya daha fazla işlemden oluşur. (Not: Toplu İş, Başlık hariç Toplama bloğundaki verilerin bir kısmıdır).

Başlık üretimi, rollup başlığının oluşturulması sürecidir.

Rollup Header, blokla ilgili meta verilerdir ve en azından bu bloktaki işlemlere ilişkin bir taahhüt içerir. (Not: Buradaki taahhüt, işlem işleme sonuçlarının doğruluğuna ilişkin taahhüdü ifade eder).

Yukarıdaki bakış açısıyla, Rollup'ın her bir bileşeninin rolünü kimin oynadığını görebiliriz. Önce toplayıcı kısmına bakalım. Daha önce bahsedilen kötümser toparlanmanın başlık üretme süreci yoktur ve kullanıcılar işlemleri doğrudan DA-Katmanına yayınlar, bu da DA-Katmanı ağının esasen bir toplayıcı olarak hareket ettiği anlamına gelir.

Kötümser Toplama, toplama adımını DA-Katmanına devreden bir Toplama çeşididir. Bir sıralayıcıya sahip değildir. Bazen bu tür bir toplama "temelli toplama" olarak adlandırılır.

Based Rollup, DA-Layer ile aynı sansür direncine ve canlılığa sahiptir (etkinlik, sistemin kullanıcı isteklerine yanıt verme hızını ölçer). Bu tür bir Toplama kullanıcıları minimum güven durumuna (Trustless'a en yakın) ulaşmak istiyorlarsa, en azından bir DA-Layer hafif düğümü ve bir toplama tam düğümü çalıştırmalıdırlar.

Varyant 2: Paylaşılan Toplayıcı kullanarak Kötümser Toplama

Paylaşılan toplayıcıları 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 önerilmiştir. 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çıklamaktadır:

"Web2 eşdeğeri bir kullanıcı deneyiminin kilidini açmak için, paylaşılan sıralayıcılar [...] hızlı yumuşak taahhütler sağlayabilir (not: çok güvenilir bir garanti değil). Bu yumuşak taahhütler, işlemlerin nihai sıralamasına ilişkin bazı keyfi vaatler sağlar (yani, işlem sırasının değişmeyeceğini vaat ederler) ve durumun zamanından önce güncellenmiş sürümlerini oluşturmak için kullanılabilir (ancak şu anda sonlandırma henüz tamamlanmamıştır).

Blok verinin taban katmanında (DAlayer'a atıfta bulunan s/b) yayınlandığı teyit edilir edilmez, durum nihai olarak kabul edilebilir."

Hala kötümser bir toparlama yaptığımız için, yalnızca tam toparlama düğümlerimiz var ve hafif düğümlerimiz yok. Her düğümün geçerliliği garanti etmek için tüm işlemleri yürütmesi gerekir. Bu sistemde ışık düğümleri yoktur, bu nedenle başlık üreticisi olarak da bilinen bir toparlayıcı başlığa gerek yoktur. (Not: Genel olarak, bir blok zincirinin hafif düğümünün tüm blokları senkronize etmesi gerekmez, yalnızca blok başlıklarını alır)

Toplama Üstbilgi üretim adımı olmadığından, yukarıda bahsedilen Toplama paylaşımlı sıralayıcının durum güncellemeleri için işlemleri yürütmesine gerek yoktur (Üstbilgi üretimi için bir ön koşul), ancak yalnızca işlem verilerini toplama işlemini içerir. Bu yüzden ben buna paylaşımlı toplayıcı demeyi tercih ediyorum.

Bu varyantta, Rollup kullanıcılarının en azından aşağıdakileri güven minimize edilmiş bir durumda çalıştırması gerekir:

DA-Layer ışık düğümü + paylaşılan toplayıcı ağın ışık düğümü + Toplama tam düğümü.

Şu anda, paylaşılan toplayıcı ağının ışık düğümü aracılığıyla yayınlanan toplayıcı başlığını (Toplama Başlığına atıfta bulunmadan) doğrulamak gerekir. Yukarıda belirtildiği gibi, paylaşılan toplayıcı işlem sıralama görevini üstlenir. Yayınlanan toplayıcı başlığında, DA-Katmanında yayınladığı Toplu İşe karşılık gelen bir kriptografik taahhüt içerir.

Bu şekilde, Toplama düğümünün operatörü DA-Katmanından alınan Partinin başkaları tarafından değil, paylaşılan toplayıcı tarafından oluşturulduğunu doğrulayabilir.

(Yukarıda yer alan içerik nispeten belirsiz olduğu için diyagramı tekrar okuyabilirsiniz)

Dahil etme, bir işlemin blok zincirine kabul edildiği süreçtir.

Sıralama, işlemlerin blok zincirinde belirli bir sıraya göre düzenlenmesi sürecidir.

Yürütme, blok zincirindeki işlemlerin işlendiği ve bunların etkilerinin blok zincirinin durumuna uygulandığı süreçtir.

Paylaşılan toplayıcı dahil etme ve sıralamayı kontrol ettiğinden, sansür direncini miras alıyoruz.

L_ss'nin paylaşılan toplayıcının canlılığı ve L_da'nın DA-Katmanının canlılığı olduğunu varsayarsak, bu şemanın canlılığı L = L_da && L_ss olur. Başka bir deyişle, sistemlerden birinde canlılık hatası varsa, toplama işleminde de canlılık hatası vardır.

Basit olması için canlılığı bir boolean olarak kullanacağım. Paylaşılan toplayıcı başarısız olursa, toplama işlemine devam edemeyiz. DA-Katmanı başarısız olursa, paylaşılan toplayıcının yumuşak taahhütleri ile devam edebiliriz. Yine de, paylaşılan toplayıcının mutabakatına ve veri kullanılabilirliğine güveniyor olacağız ki bu da orijinal DA-Layer'dan daha kötü olacaktır.

Yukarıdaki Rollup çözümünün sansüre karşı direncini keşfetmeye devam edelim:

Bu şemada, DA Katmanı belirli işlemleri sansürleyemez. (Not: İşlem incelemesi genellikle belirli işlemlerin zincire yüklenmesine izin vermeyebilir). Yalnızca paylaşılan toplayıcının zaten topladığı tüm toplama gruplarını sansürleyebilir. (DA-Katmanına dahil edilecek bir partinin reddedilmesi).

Ancak, Toplama iş akışına göre, paylaşım toplayıcısı işlem grubunu DA-Katmanına gönderdiğinde, işlem sıralamasını zaten tamamlamıştır ve farklı gruplar arasındaki sıra da belirlenmiştir. Dolayısıyla DA-Katmanı tarafından yapılan bu tür bir işlem incelemesinin Rollup'ın defterinin kesinleşmesini geciktirmekten başka bir etkisi yoktur.

Özetle, sansüre direncin odak noktasının, sistem içindeki bilgi akışını hiçbir varlığın kontrol edememesini veya manipüle edememesini sağlamak olduğuna inanıyorum; canlılık ise ağ kesintileri ve düşmanca eylemlerin varlığında bile sistemin işlevselliğini ve kullanılabilirliğini sürdürmeyi içerir. Bu her ne kadar mevcut ana akım akademik tanımla çelişse de ben yine de kavramın belirttiğim tanımını kullanacağım.

Varyant 3: Tabanlı ve Paylaşılan Toplama ile Kötümser Toplama

Topluluk paylaşılan bir toplayıcının avantajlarından yararlansa da, buna bağlı kalmaktan kaçınmak ve DA-Katmanına geri dönüş yapmak istiyoruz. Siparişleri birleştireceğiz ve kullanıcıların işlemleri doğrudan DA-Layer'a göndermelerine izin vereceğiz. Tabanlı ve paylaşımlı toplamayı birleştirir.

Nihai sıralamanın, paylaşılan toplayıcı tarafından sıralanan tüm işlemler ve ardından DA Katmanı bloğu başına bundan sonraki tüm temel işlemler olarak yorumlanacağını varsayıyoruz. Biz buna çatal seçim kuralı diyoruz.

Burada birleştirme iki aşamalı bir süreçtir. İlk olarak, paylaşılan toplayıcı bazı işlemleri bir araya getirerek liderliği üstlenir. Daha sonra DA Katmanı, kullanıcının doğrudan gönderdiği halihazırda sipariş edilmiş partileri ve işlemleri bir araya getirir.

Sansüre direnç analizi artık daha karmaşık. DA-Katmanı ağ düğümü, bir sonraki DA-Katmanı bloğu üretilmeden önce paylaşılan toplayıcı tarafından gönderilen Partiyi gözden geçirebilir. Yığın içindeki işlem verilerini öğrendikten sonra, DA-Katmanı düğümü MEV değerini çıkarabilir, Toplama ağındaki hesabıyla önden çalışan bir işlem başlatabilir ve Toplama paylaşımlı toplayıcı tarafından gönderilen Yığını dahil etmeden önce bunu DA-Katmanı bloğuna dahil edebilir.

Görünüşe göre, üçüncü tip Toplama varyantının yumuşak taahhüdü tarafından garanti edilen işlem sırası kesinliği, yukarıda bahsedilen ikinci tip Toplama varyantından daha kırılgandır. Bu durumda, paylaşılan toplayıcı MEV değerini DA Katmanı düğümüne iletir. Bununla ilgili olarak, okuyuculara MEV'in kârlı sansürü hakkındaki dersi izlemelerini öneririm.

Şu anda, DA-Katmanı ağ düğümlerinin bu tür MEV işlemlerini yürütme kabiliyetini azaltmak için, Toplama ağı kullanıcıları tarafından doğrudan DA-Katmanına gönderilen işlemleri geciktirecek olan "yeniden düzenleme penceresi süresi" işlevi gibi bazı tasarım çözümleri ortaya çıkmıştır. Sovereign Labs, "tercih edilen sıralayıcı" kavramının önerildiği Yumuşak Onaylarla Tabanlı Sıralama adlı tasarım teklifinde bunu detaylandırmıştır.

MEV, seçtiğiniz toplayıcı şemasına ve toplamanın çatal seçim kuralına bağlı olduğundan, bazıları hiç sızıntı yapmayacak, bazıları ise MEV'in bir kısmını veya tamamını DA Katmanına sızdıracaktır, ancak bu başka bir günün konusu.

Canlılık açısından, bu rollup tasarımı sadece paylaşılan bir toplayıcıya sahip olmaktan daha avantajlıdır. Paylaşılan toplayıcıda bir canlılık hatası varsa, kullanıcı yine de DA Katmanına işlem gönderebilir.

Son olarak, güven minimize edilmiş en küçük kurulumdan bahsedelim: bir DA-Layer ışık düğümü + paylaşılan toplayıcı ışık düğümü + toparlayıcı tam düğüm.

Şu anda, çatal seçim kuralı için işlem gruplarını ayırt edebilmek amacıyla, toparlama tam düğümümüz için paylaşılan toplayıcının başlıklarını doğrulamamız gerekmektedir.

Varyant 4: Merkezi Üstbilgi Üreticisi ile Tabanlı İyimser Toplama

Merkezi bir başlık üreticisi ile temelli iyimser toplama adı verilen bir varyant kullanarak bazı hafif düğümleri pişirmeye başlayalım. Bu tasarım, işlemleri toplamak için DA Katmanını kullanır, ancak hafif düğümlerin toplanmasını sağlamak için merkezi bir başlık üreticisi sunuyoruz.

Rollup light düğümleri, tek bir dolandırıcılık kanıtı turu aracılığıyla dolaylı olarak Rollup işlemlerinin geçerliliğini doğrulayabilir. Işık düğümü, Toplama Üstbilgisi üreticisine karşı iyimser bir tavır takınacak ve sahtekarlık kanıt penceresi süresi sona erdikten sonra nihai bir onaylama yapacaktır. Diğer bir olasılık ise, Başlık üreticisinin yanlış veri gönderdiğini bilen dürüst bir tam düğümden bir sahtekarlık kanıtı almasıdır.

Bu makalenin kapsamını aşacağı için tek turlu sahtekarlık kanıtlarının nasıl çalıştığına dair ayrıntılara girmeyeceğim. Buradaki fayda, dolandırıcılığı kanıtlama penceresi süresini 7 günden henüz belirlenmemiş ancak çok daha küçük bir miktara indirebilmenizdir. Işık düğümleri, her şey tek bir kanıtta yakalandığından, bir anlaşmazlığı beklemeye gerek kalmadan p2p katmanı aracılığıyla dolandırıcılık kanıtlarını alabilir.

Sansür direncini miras alan toplayıcı olarak DA-Katmanını kullanıyoruz. Dahil etme ve sipariş verme işlemlerini yapar. Merkezi başlık üreticisi DA-Katmanından kanonik sıralamayı okuyacak ve bundan geçerli bir başlık oluşturabilecektir. Merkezi başlık üreticisi, başlık ve durum köklerini DA-Katmanına gönderecektir. Bu devlet kökleri, bu taahhüde karşı bir dolandırıcılık kanıtı oluşturmak için gereklidir. Başlık üreticisi yürütme işlemini gerçekleştirirken, toplayıcı dahil etme ve sıralama işlemlerini yapar.

DA-Katmanının (şu anda Rollup'ın toplayıcısı olarak da görev yapmaktadır) yeterince merkezi olmadığı ve sansüre karşı iyi bir dirence sahip olduğu varsayılmaktadır. Ayrıca Üstbilgi üreticisi, toplayıcı tarafından yayınlanan Toplama işlem sırasını değiştiremez. Şimdi, eğer Başlık üreticisi merkezi değilse, tek fayda daha iyi canlılıktır, ancak Toplama'nın diğer özellikleri ilk varyant olan Tabanlı Toplama ile aynıdır.

Başlık üreticisinde canlılık hatası varsa, toplama işleminde de canlılık hatası vardır. Hafif düğüm zinciri takip edemezken, tam düğümler istenirse yine de zinciri takip edebilir ve varyant 1'de açıklandığı gibi temelli kötümser bir toplamaya geri dönebilir. Açıkçası, varyant 4'te açıklanan güven minimizasyonu için minimum konfigürasyon şudur:

DA-Layer ışık düğümü + Rollup ışık düğümü.

Varyant 5: Merkezi Olmayan Prover Piyasası ile ZK-Rollup Tabanlı

Kötümser Toplama (Tabanlı Toplama) ve İyimser Toplama konularını ele aldık, şimdi sıra ZK-Toplama konusuna geldi. Yakın zamanda Toghrul, toplayıcı (Sequencer) ve başlık üreticisinin (Prover) ayrılması üzerine bir sunum yaptı (Sequencer-Prover Separation in Zero-Knowledge Rollups). Bu modelde, işlemleri State Diff yerine Rollup verileri olarak yayınlamak daha kolaydır, bu nedenle birincisine odaklanacağım. Varyant 5, merkezi olmayan bir prover piyasasına sahip temel bir zk-rollup'tır.

Şimdiye kadar, temelli toplamanın ne yaptığını biliyor olmalısınız. Varyant 5, toplayıcı rolünü, dahil etme ve sıralama işini gerçekleştiren DA-Layer düğümlerine devreder. Tasarımlarının yaşam döngüsünü açıklamak için harika bir iş çıkaran Sovereign-Labs'ın dokümanından alıntı yapacağım. Varyant 5'e uyması için biraz uyarlayacağım.

Kullanıcılar L1 zincirine yeni bir veri bloğu gönderir. Blob L1 üzerinde sonlandırılır sonlandırılmaz, mantıksal olarak sonlandırılmış olur. L1 bloğu sonlandırıldıktan hemen sonra, toplamanın tüm düğümleri bunu tarar ve ilgili tüm veri bloblarını göründükleri sırayla işleyerek yeni bir toplama durumu kökü oluşturur. Bu noktada blok, tüm tam düğümlerin bakış açısından öznel olarak sonlandırılır.

Bu tasarımdaki başlık üreticimiz merkezi olmayan prover pazarıdır.

Kanıtlayıcı düğümler (bir ZKVM içinde çalışan tam düğümler), DA bloğunu taramak ve tüm grupları sırayla işlemek - kanıtlar üretmek ve bunları zincire göndermek gibi tam düğümlerle kabaca aynı işlemi gerçekleştirir. (Rollup kanıtlayıcıları teşvik etmek istiyorsa, kanıtların zincirde yayınlanması gerekir - aksi takdirde, hangi kanıtlayıcının belirli bir partiyi ilk işleyen olduğunu söylemek imkansızdır). Belirli bir grup için bir kanıt zincirde yayınlandıktan sonra, grup hafif düğümler de dahil olmak üzere tüm düğümler için öznel olarak nihaidir.

(Birçok kavram söz konusu olduğu için şematik diyagrama tekrar bakabilirsiniz)

Varyant 5, DA Katmanı ile aynı sansür direncine sahiptir. Merkezi olmayan prover piyasası işlemleri sansürleyemez çünkü DA Katmanı kanonik sıralamayı belirler. Başlık üreticisini yalnızca daha iyi canlılık ve teşvik edici bir pazar oluşturmak için merkezsizleştirdik. Buradaki canlılık L = L_da && L_pm (prover market) şeklindedir. Eğer kanıtlayıcı piyasasının teşvikleri yanlış hizalanmışsa ya da bir canlılık hatası varsa, hafif düğümler zinciri takip edemeyecektir, ancak tam düğümler istenirse zinciri takip edebilir ve temelli kötümser bir toparlanmaya geri dönebilir. En küçük güven minimize edilmiş kurulum burada, tıpkı iyimser durumda olduğu gibi bir DA-Layer ışık düğümü + bir rollup ışık düğümüdür.

Varyant 6 : Merkezi İyimser Başlık Üreticisi ve Merkezi Olmayan İspatlayıcı ile Tabanlı Hibrit Toplama

DA-Layer düğümlerinin Toplama için toplayıcı olarak hareket etmesine izin veriyoruz ve işlemlerin dahil edilmesi ve sıralanması için onları görevlendiriyoruz.

Aşağıdaki şekilde görebileceğiniz gibi, hem ZK Toplama hem de İyimser Toplama, Toplama defterinin kaynağı olarak DA Katmanındaki aynı sıralı işlem gruplarını kullanır. Bu nedenle iki ispat sistemini aynı anda kullanabiliriz: DA-Katmanındaki sıralı işlem partileri ispat sisteminin kendisinden etkilenmez.

Kesinlik hakkında konuşalım. Toplama tam düğümü açısından bakıldığında, DA Katmanı nihai olduğunda toplama nihaidir, çünkü sadece bu varyant için işlemleri yürütmesi gerekir. Ancak biz ışık düğümünün son halini daha çok önemsiyoruz. Merkezi başlık üreticisinin bir miktar bahis koyduğunu, bir başlık imzaladığını ve hesaplanan durum köklerini DA-Katmanına gönderdiğini varsayalım.

Önceki varyant 4'te olduğu gibi, hafif düğümler iyimser bir şekilde yürütmeye güvenecek ve dürüst bir tam düğümden başlık üreticisinin sahtekarlık yaptığını gösteren bir sahtekarlık kanıtı bekleyecektir. Dolandırıcılık kanıt penceresi bittikten sonra, toparlama bloğu bir toparlama ışık düğümü perspektifinden son halini alır.

Kilit nokta, eğer bir ZK kanıtı elde edebilirsek, artık sahtekarlık kanıt penceresinin bitmesini beklemek zorunda kalmayacağımızdır. Tek turlu sahtekarlık kanıtlarına ek olarak, sahtekarlık kanıtlarını ZK kanıtları ile değiştirebilir ve iyimser başlık üreticisinden üretilen herhangi bir kötü niyetli başlığı reddedebiliriz!

Işık düğümü belirli bir Toplama işlemi grubuna karşılık gelen ZK sertifikasını aldığında, grup sonlandırılacaktır.

Şimdi hızlı bir yumuşak taahhüdümüz ve hızlı bir kesinliğimiz var.

Varyant 6, temel aldığı DA-Layer ile aynı sansür direncine sahiptir. Canlılık için, L = L_da && (L_op || L_pm ) olacaktır, bu da canlılık garantimizi artırdığımız anlamına gelir. Eğer merkezi başlık üreticisi ya da kanıtlayıcı pazarında bir canlılık hatası olursa, diğer şemaya geri dönebiliriz.

En küçük güven minimize edilmiş kurulum bir DA-Layer ışık düğümü + bir rollup ışık düğümüdür.

Özet:

1. Sıralayıcıyı iki mantıksal varlığa ayırıyoruz: toplayıcı ve başlık üreticisi

2. Sıralayıcıyı üç mantıksal sürece ayırıyoruz: dahil etme, sıralama ve yürütme.

3. Kötümser toparlamalar ve temelli toparlamalar bir şeydir

4. İhtiyaçlarınıza bağlı olarak, toplayıcıları ve başlık üreticilerini takıp çalıştırabilirsiniz.

5. Bu makaledeki her bir Rollup çeşidi bu tasarım modelini izlemiştir:
   

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

• Klasik rulolar buna nasıl uyuyor? (Ethereum Rollup'a atıfta bulunarak)
• Tüm varyantlarda, yalnızca toplayıcıya dahil etme + sıralama ve başlık üreticisine yürütme yaptırdık. Toplayıcı sadece dahil etme işlemini, başlık üreticisi ise sıralama ve yürütme işlemlerini yaparsa ne olur? Zincir üstü açık artırmaları düşünün. Üçünü de ayırabilir miyiz?
• Ortak başlık üreticisi / başlık üreticisi pazarı nedir?
• MEV'i kim alacak? Ve onu geri alabilir miyiz?

Sorumluluk Reddi：

1. Bu makale[Geek Web3], Forward Orijinal Başlığı'Celestia araştırmacısı 6 Rollup varyantını analiz ediyor'dan yeniden basılmıştır: Sequencer = aggregator + Header generator',Tüm telif hakları orijinal yazara aittir[NashQ, Celestia Araştırmacısı]. Bu baskıya itirazınız varsa, lütfen Gate Learn ekibiyle iletişime geçin, onlar bu konuyu derhal ele alacaklardır.
2. Sorumluluk Reddi: Bu makalede ifade edilen görüş ve fikirler yalnızca yazara aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirisi Gate Learn ekibi tarafından yapılmaktadır. Belirtilmediği sürece, çevrilen makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.