4D Ayrıntılı Paylaşılan Sıralayıcı: Çalışma Prensibi, Toplama Teorisi ve Dikey Entegrasyon

Bu makale, paylaşılan sıralayıcıların temel teknolojilerini analiz etmektedir: sansüre son derece dayanıklı, kurulumu kolay, birlikte çalışabilir, hızlı tespit ve anında. Toplama teorisi ona yeni bir bakış açısı sağlar ve dikey entegrasyon onun daha da geliştirilmesine rehberlik eder.

Orijinal başlık: "Paylaşılan Sıralayıcı"

Yazan: MAVEN11

Derleme: Kxp, BlockBeats

"Kutudan çıktığı haliyle" Rollup'ın yüksek derecede sansür direncine, konuşlandırma kolaylığına, birlikte çalışabilirliğe, hızlı kesinliğe, canlılığa ve MEV'nin demokratikleşmesine ulaşmasının nasıl bir şey olacağını hayal edin. Bu büyük bir hedef gibi görünebilir, ancak Paylaşımlı Sıralayıcı'nın gelişiyle, yakında gerçek olabilir. Ancak, tüm Toplamalar aynı değildir, bu nedenle ödülleri ve MEV'yi paylaşılan sıralayıcı ağında nasıl dağıtacağımızı düşünmeliyiz. Bu yazıda, paylaşılan sıralama ağlarının nasıl uygulandığını ve elde edilebilecek özellikleri keşfedeceğiz.

Shared Sequencer Networks öncelikle Alex Beckett tarafından, daha sonra Celestia ve Espresso ekiplerinden Evan Forbes (ve Radius) tarafından ve Jon Charbonneau'nun konuyu daha derinlemesine ele alan yeni bir makalesi tarafından tanıtıldı. Josh, Jordan ve Astria ekibi, üretime hazır ilk paylaşılan sıralayıcı ağını kuruyor. Astria'nın Paylaşılan Sipariş Ağı, Rollup'ın işlemlerini yürütmeden toplayan ve sipariş eden modüler bir blok zinciridir.

Astria'nın kurulumunda sıralayıcı, sıralı blokları DA katmanına ve ayrıca Toplama düğümlerine gönderir. Toplamalar, sipariş verenden yumuşak kesinlik garantileri ve DA katmanından (bloklar tamamlandıktan sonra) kesin kesinlik garantileri alır ve ardından geçerli işlemleri yürütürler.

Paylaşılan sıralayıcı ağı, adından da anlaşılacağı gibi, temelde bir Toplama uyumlu sıralayıcılar grubudur, farklı Toplamalar için hizmetler sağlayabilir. Bunun, daha sonra detaylandıracağımız çeşitli değiş tokuşları ve özellikleri vardır. İlk olarak, bir sıralayıcının (veya bir dizi sıralayıcının) en önemli özelliklerini açıklamalıyız. Toplama'da, bir sıralayıcı veya sıralayıcı grubu için temel gereksinim, sansür direnci veya canlılıktır (bazıları temel katmandan ve ayrıca güvenlikten gelir). Bu, sipariş verene gönderilen geçerli bir işlemin sınırlı bir süre (zaman aşımı parametresi) içinde zincire dahil edilmesi gerektiği anlamına gelir. Paylaşılan sipariş grubu, yalnızca işlemlerin bloklara (yani crLists) dahil edilmesini sağlamalıdır.

Modüler MEV Bölüm II'de özetlediğimiz gibi, sansür direncini ve aciliyeti aynı anda tatmin etmek oldukça zordur. Tendermint gibi bir mutabakat algoritmasında, bir saldırıdan sonra kurtarmayı sağlayabilirsiniz. Ancak, bir saldırı durumunda aciliyetinizi kaybedersiniz. Temel olarak, özel bir masternode seçmek yerine diğer tüm harmanlayıcıların bir bloğu imzalamasını istemek muhtemelen optimal değildir. Bu, sansür direncini artırırken, "merkezileştirme" ve MEV'nin tek bir ana düğüme çıkarılması pahasına gelir. Mevcut başka bir sıralama mekanizması, masternod olmayanların (veya sıralayıcıların) diğer işlemleri bloklara dahil etmesi için kullandıkları küçük araç olan Duality's Multiplicity ile karşılaştırılabilir. Genel olarak, çoğu konsensüs protokolünde sansüre karşı direnç ve bir saldırıdan sonra yakınlık elde etmek zordur.

Kullanılabilecek başka bir mutabakat algoritması, bir saldırı durumunda aciliyet sağlayan HotStuff 2'dir.

İzin verdiği şey, yeni bir masternode seçmek için sansür veya imzasızlık durumunda maksimum ağ gecikmesini (zaman aşımı) beklemekten kaçınmaktır. Merkezi olmayan bir emirciler grubu için ilginç bir konsensüs algoritması olabilmesinin nedeni, mutabakattaki aciliyet problemini fazladan bir aşama eklemeden çözmesidir. Masternode en yüksek kilidi (belirli bir çıktı üzerinde anlaşan en yüksek katılımcı sayısı) bilir ve dürüst tarafları ikna edebilirse, sorun çözülür. Değilse, belirli bir noktadan sonra dürüst bir masternode, bir sonraki masternode'a yardımcı olarak push'un sorumluluğunu üstlenebilir. Örneğin, bir Hotstuff düğümünün yeni bir yöneticiye bildirimde bulunmadan önce geçiş mesajını onaylamasına gerek yoktur, ancak doğrudan yeni bir görünüme geçebilir ve yeni yöneticiye bildirimde bulunabilir.

Tendermint ile arasındaki fark, her ikisi de iki fazlı olmasına rağmen (Hotstuff1'de üç, Hotstuff2'de iki tane vardır), Tendermint'in doğrusal iletişime sahip olmasına rağmen yanıt vermemesi, Hotstuff2'nin ise reaktif olmasıdır. Dürüst ana düğümler zinciri varsa, protokol olumlu yanıt verir, çünkü ilk ana düğümün önerisi dışındaki tüm adımlar bir önceki adımdan elde edilen bilgi miktarına bağlıdır. Paylaşılan bir sıralayıcı ayarında bu, protokolün en alt katmana geri düşmeden daha iyi yakınlık elde etmesini sağlarken, bu olasılığı iptal etmez.

Paylaşılan sıralayıcı gruplarının oluşturulması

Bir grup sipariş verenin, ödeme katmanına (Toplamanın bulunduğu katman) işlem göndermesine izin verilir. Belirli gereksinimlerin karşılanması ve gerekli sayıda blok üreticisine ulaşılmaması koşuluyla bu harmanlayıcı grubuna katılabilirsiniz. Bu, gecikmeyi, verimi ve daha fazlasını optimize eder. Bu gereksinimler, bir blok zincirinin doğrulayıcısı olmak için gerekenlere benzer. Örneğin, özellikle finansal koşullarla kesinlik sunmak istiyorsanız, belirli donanım gereksinimlerini karşılamanız ve ilk depozitoyu karşılamanız gerekir.

Paylaşılan bir sipariş grubu (veya herhangi bir merkezi olmayan sipariş grubu), işlemlerin doğru şekilde işlenmesini sağlamak için birlikte çalışan birkaç bileşenden oluşur:

1. Düğüme bir bellek havuzu olarak işlem gönderimi için (tam olmayan düğüm işleçleri için) her Toplama için JSON-RPC sağlayın ve ardından oluşturun ve sıralayın. Mempool'da, blokların verimli bir şekilde inşa edilmesini sağlamak için işlem seçim sürecinin yanı sıra sırayı belirlemek için bazı mekanizmalara ihtiyaç vardır.

2. Kuyruktaki işlemleri işlemekten ve bunları bloklara veya gruplara dönüştürmekten sorumlu blok/toplu yapı algoritması. Bu adım ayrıca ortaya çıkan blok boyutunu azaltmak için sıkıştırmayı da içerebilir (veri sıkıştırması olarak adlandırılır). Bahsedildiği gibi, bu Teklif Sahibinden, esas olarak PBS'den ayrı olmalıdır. Veriler çeşitli şekillerde sıkıştırılabilir, örneğin:

• RLP kodlaması yok - ancak bu, düğümler arasında veri aktarımını normalleştirmeye yardımcı olmak ve böylece yerden tasarruf etmek için merkezi olmayan bir harmanlayıcı seti gerektirebilir.
• Nonce'yi atlayın (belirli bir bloktaki verileri doğrulayan benzersiz sayı) - yürütme zamanında zincirin önceki durumuna bakılarak yeniden hesaplanabilir.
• Gaz fiyatı basitleştirme - gazı sabit bir fiyat aralığına göre ayarlayın.
• Gaz basitleştirme - Gaz fiyatına ek olarak, bir de gaz numaralandırma sistemi vardır.
• Adresi dizinle değiştir - Toplama, tam adresi depolamak yerine eşlenmiş bir adresin dizinini depolayabilir.
• Bilimsel gösterimde ifade edilen değerler - Ethereum işlemlerindeki değer alanları wei cinsindendir, bu nedenle değerler büyüktür. Sayısal alanları atlayamaz veya bunları sabit bir değerler grubuna indirgeyemezsiniz. Ancak, veri depolamayı optimize etmek için bilimsel gösterimde yazabilirsiniz:

• Veri alanlarının çıkarılması: Veri alanları basit transferler için gerekli değildir, ancak daha karmaşık işlemler için gereklidir.

• Bireysel imzaları BLS toplu imzalarıyla değiştirin: İmzalar, Ethereum işlemlerinin en büyük bileşenidir. Her bir imzayı depolamak yerine, belirli sayıda işlem için BLS toplu imzalarını depolayabilirsiniz. Geçerliliğini sağlamak için BLS toplu imzasını mesaj seti ve gönderen seti ile de kontrol edebilirsiniz.

• Kimden alanını dizin olarak kullanın: Kime alanı gibi, Kimden alanını da eşleme için bir dizin olarak kullanabilirsiniz.

• "Modüler" tasarımın ilginç bir konsepti, Rollup'ınız için çalışmasını sağlamak için gerektiği gibi ayarlamalar ve takaslar yapabilmenizdir.

3. Eşler arası katman, sipariş verenlerin diğer sipariş verenlerden işlem almasına ve inşaattan sonra blokları yaymasına izin verecektir. Bu adım, paylaşılan sıralayıcının birden çok toplamada verimli bir şekilde çalışmasını sağlamak için kritik öneme sahiptir.

4. Paylaşılan sipariş kümeleri için ana rotasyon algoritması (tek ana seçim durumunda fikir birliği gerekmez). Yalnızca ana düğüm döndürme algoritmasını ayarlamayı veya Duality tarafından önerilen çoklu eşzamanlı blok üreticisi yolunu kullanmayı seçebilirsiniz.

5. Daha önce bahsedilen Tendermint veya Hotstuff2 gibi konsensüs algoritmaları, Toplama düğümlerinin defter tarafından önerilen sıra ile aynı fikirde olmasını sağlayabilir.

6. Blokların/grupların temel DA+ konsensüs katmanına gönderilmesi için RPC istemcisi, böylece blokların/grupların DA katmanına güvenli bir şekilde eklenebilmesi, "nihai" kesinliğin sağlanması ve tüm işlem verilerinin zincir üzerinde kullanılabilir hale getirilmesi.

7. Adalet ve tutarlılığı sağlamak ve MEV hırsızlığını önlemek için inşaatçıların ve blok üreticilerinin rollerini ayırın. Verimliliği optimize etmek, PGA'yı azaltmak ve CR'yi artırmak için önemli olan gerçekleştirilen sıralamayı da kaldırır.

*Toplama düğümleri, yumuşak gönderim için sıralayıcıdan sıralı bloklar alır ve kesin gönderim için sıralı DA katman bloklarını alır. *

Calldata ilk olarak, kullanıcı ve Toplama işlemlerini garanti altına almak için mutabakatın çalıştırıldığı temel ağda yayınlanır. Ardından, Toplama düğümü işlemi yürütür ve kurallı Toplama zincirine bir durum geçiş işlevi gönderir. Paylaşılan sipariş verenlerden oluşan bir ağ, Rollup'a aciliyet ve sansür direnci sağlar. Toplamalar, tüm işlem verileri temel katmanda depolandığı için egemenliklerini korurlar, bu da onların herhangi bir zamanda paylaşılan düzenleyiciden ayrılmalarına izin verir. Toplama durumu geçiş işlevinin (STF) durum kökü, paylaşılan düzenleyiciden DA katmanına gönderilen işlem köklerinden (girişler) hesaplanır. Celestia'da, zincire veri eklendiğinde ve fikir birliğine varıldığında durum kökleri oluşturulur. İşlem köküne (ve mevcut tüm verilere) zaten sahip olduğunuz için Celestia, küçük bir dahil etme kanıtıyla hafif istemciler (Celestia üzerinde çalışan Toplama düğümleri) sağlayabilir.

Kullanıcıların beklediği kullanıcı deneyimini sağlamak için, Toplama düğümleri (DA katmanına da gönderilen) sıralı bloklar alır. Bu, Rollup'a yumuşak deterministik garantiler sağlayabilir - blokların sonunda DA katmanında sıralanacağını garanti eder; bu noktada Rollup düğümleri işlemleri yürütür ve yeni durum kökleri sağlar.

Blok Oluşturma ve Slot

Blok oluşturma zamanını belirlemek için sıralayıcının slotu ayarlaması gerekir. Sıralayıcı, partileri sabit aralıklarla (tipik olarak X saniye) göndermelidir; burada X, aralık süresidir. Bu, işlemlerin hızlı ve verimli bir şekilde işlenmesini sağlar, çünkü aksi takdirde belirli bir yuva için masternode zaman aşımına uğrar ve imzalama ödülünü (ve yürütme ödülünü) kaybeder. Örneğin, Celestia'nın engelleme süresi (GitHub özelliklerine göre) yaklaşık 15 saniyedir. Bu bilindiği için, paylaşılan ortak kümeden DA katmanına kadar kaç tane "yuva/blok" sahibi olabileceğimize ve Toplama düğümlerinin sonlandırılmış bloklara yüklendiğine dair bazı varsayımlarda bulunabiliriz. Bu bağlamda, optimize edilmiş Tendermint veya Hotstuff2'ye başvurabiliriz.

Tasarımın, bunları tek bir blokta (bu zaman aralığı ve zaman aşımı parametreleri içinde) verimli bir şekilde işlemek için Tam düğümleri Topla'ya yönelik mekanizmalar içermesi koşuluyla, aynı yuva içinde birden fazla işlem grubu gönderebiliriz. Bu, blok oluşturmayı daha da optimize etmeye yardımcı olur ve işlemlerin hızlı bir şekilde işlenmesini sağlar. Ek olarak, sıralayıcı ana düğümlerinin seçimini kolaylaştırmak için yuvalar da kullanılabilir. Örneğin, bahis ağırlığına dayalı olarak bahis havuzundan rastgele bir slot ana düğümü seçebilirsiniz. Bunu gizliliği koruyacak şekilde yapmak ve sansürü en aza indirmek için gizli lider seçimi gibi bir şey kullanmak en iyi seçenektir; hatta Obol/SSV gibi çözümler gibi dağıtılmış doğrulayıcı teknoloji kurulumu. Gecikme ve slot süresi, protokole yapılan blok gönderimleri ve derlemeler üzerinde büyük bir etkiye sahiptir. Dolayısıyla bunun sistemi nasıl etkilediğine bakmamız gerekiyor. Bloxroute, özellikle Ethereum hakkında bazı harika araştırma ve veri noktalarına sahiptir. MEV-Boost'ta, katılan blok üreticileri (Toplama durumunda doğrulayıcılar veya sıralayıcılar) röleden GetHeader ister. Bu onlara belirli bir bloğun değeri olan blok teklif değerini verir. Bu, her seferinde alınan en yüksek değerli blok olabilir. Doğrulayıcılar her yuva için genellikle yuva başladıktan yaklaşık 400 ms sonra GetHeader'ı ister - çok sayıda doğrulayıcı nedeniyle, rölelerin genellikle çok sayıda istek göndermesi gerekir. Bu aynı zamanda büyük paylaşımlı sıralayıcı gruplarında da olabilir. Bu, bu süreci kolaylaştırmak için altyapıya ihtiyacınız olduğu anlamına gelir.

Röleler ayrıca inşaatçıların ve blok üreticilerinin ayrılmasını kolaylaştırmaya yardımcı olurken aynı zamanda inşaatçıların doğru blokları inşa ettiğini doğrular. Ayrıca ücretlerin doğru bir şekilde ödenip ödenmediğini de kontrol ederler ve DoS koruması görevi görürler. Ayrıca, temel olarak blokların bekçileridir ve doğrulayıcıların kaydını yürütürler. Kimin katılıp kimin katılmadığını (örneğin, daha önce tartışılan senkronizasyon katmanı) takip etmeniz gerektiğinden, bu özellikle sınırsız bir sıralayıcının mimarisinde önemlidir.

Blok süreleriyle ilgili olarak (yani yaratıcılar tarafından gönderilen bloklar), genellikle 200 milisaniye civarında gerçekleşir. Çoğunlukla yaklaşık 200 ms'den önce/sonra çalışmaya başlarlar, ancak GetHeader gibi önemli farklılıklar vardır. Oluşturucu bloğu birden fazla aktarmaya gönderirse, bu önemli ölçüde gecikmeye neden olur. Bloxroute, bloklar birden çok aktarıcıya gönderildiğinde ne olduğuna da baktı. Tahmin edebileceğiniz gibi, bloğun daha fazla röleye yayılması için gecikme daha büyük olacaktır. Ortalama olarak, bloğu harcamak için ikinci röle 99 milisaniye, üçüncü 122 milisaniye ve dördüncü 342 milisaniye sürdü.

Muhtemelen son birkaç ayda öğrendiğimiz şey, RPC'nin blok zincirleri için çok önemli olduğudur. Uygun altyapı olmadan bu çok büyük bir yüktür ve uygun bir RPC seçeneğine sahip olmak da çok önemlidir. Bu durumda, işlemlerini RPC'ye (ve genel mempool'a) gönderen bireysel yatırımcılar için RPC önemlidir. Bloxroute, çeşitli RPC'lere gönderilen 20 işlemlik küçük bir test yaptı ve her işlemin bir bloğa dahil edilmesi için geçen süreyi ölçtü.

Kaynak: Bloxroute Labs

İlginç bir şekilde, bazı RPC'ler, bir sonraki blokta hangi oluşturucunun kazandığına bağlı olarak birkaç blok sonrasına kadar işlemleri içermez. RPC, işlemi daha fazla oluşturucuya gönderirse, hızlı dahil etme olasılığı daha yüksektir. İşlem oluşturucuların, akışı belirli oluşturucuları hedeflemek ve hatta kendi bloklarını oluşturmak için benzersiz konumlarından yararlanmaları mümkün olsa da.

Performansları, Ethereum'un röle performans istatistiklerinde de ilginç. Bu, PBS'nin birden çok doğrulayıcı/oluşturucu/geçiş dünyasında nasıl çalıştığına dair daha derin bir anlayış kazanmamıza yardımcı olur; Toplama yükseltmesiyle başarmayı umduğumuz şey de budur. Metrika'nın bu konuda bazı harika istatistikleri var ve tüm veri noktaları bunlara bağlı.

Kaçırılan tekliflerin, bir aktarıcının teklif vermesi beklendiği halde teklif vermediğinde meydana geldiğine dikkat etmek önemlidir. Hedef beklentiler, herhangi bir yuva için belirli bir geçişe kayıtlı doğrulayıcılardan gelir. Bu kendi başına bir geçiş hatası değildir ve protokol düzeyinde bu şekilde ele alınmaz.

Kaynak: app.metrika.co

Bir arıza meydana gelirse (geçersiz bir bloğa hizmet veren bir röle gibi) ve bundan sorumluysa, arıza olarak sayılır. Bunlar genellikle seyrek görülür ve çoğunlukla kayıt tercihi başarısızlıklarıdır (yani, belirli bir doğrulayıcı için kayıtlarla eşleşmeyen gaz limitleri veya ücretler). Daha da nadir görülen durumlar, yanlış yuvalar veya önceki blokla hizalanmayan ana hash'ler gibi Ethereum mutabakat katmanı kurallarıyla tutarsız olan mutabakat katmanı hatalarıdır.

Gecikme açısından (bir doğrulayıcının bir oluşturucu tarafından oluşturulan bir blok başlığını alması için geçen süre gibi), veriler oldukça tutarlıdır. İstenen geçişin seçilen doğrulayıcıdan farklı bir coğrafi konumda olması gibi bazı aykırı değerler olsa da.

Kaynak: app.metrika.co

İnşaatçılar ile ilgili olarak, MEV-boost'taki toplam inşaatçı sayısı yaklaşık 84'tür ve ilk üç inşaatçı inşa edilen blokların yaklaşık %65'ini inşa eder. Bunlar aynı zamanda en uzun süredir çalışan inşaatçılar olduğu için bu biraz yanıltıcı olabilir. Zaman çerçevesi azaltılırsa sonuçlar benzerdir. Gerçek aktif inşaatçıların sayısı çok daha düşük, son 30 günde 35 ve geçen hafta 24. Rekabet şiddetlidir ve genellikle en güçlü inşaatçı kazanır. Durumu yalnızca daha da kötüleştirecek özel bir sipariş akışı zaten mevcut olabilir. Kurulumda büyük değişiklikler yapmadığımız sürece, inşaatçıların dağıtımının nispeten merkezi kalmasını bekliyoruz (çünkü bu, optimum sipariş akışı ve donanım optimizasyonu için bir yarış). Temel bir sorun olmasa da, yığında hala merkezileştirici bir güç ve burada statükoya nasıl meydan okunacağına dair fikirleri duymak isteriz. Bu (ciddi) sorunu daha derine inmekle ilgileniyorsanız, Quintus'un sipariş akışı, açık artırmalar ve merkezileştirme hakkındaki makalelerini okumanızı önemle tavsiye ederiz.

Gelecekteki modülerlik yığınındaki Oluşturucu rolü için, (en azından Cosmos SDK kurulumunda) bir Atlama/Mekatek benzeri Oluşturucu Modülleri kurulumu göreceğimizden oldukça eminiz. Başka bir çözüm, PBS'yi sağlamak için herhangi bir sayıda zincire blok oluşturma ve teklif tercihi hizmetleri sağlayan belirli bir küresel oluşturucu zinciri gibi SUAVE tipi bir kurulumdur. Bu çözümü daha sonra daha derinlemesine inceleyeceğiz ve burada ele alınmayan bazı sorulara yanıtlar vereceğiz.

Geçişlerle ilgili olarak, Frontier Research'ten Ankit Chiplunkar ve Ethereum Vakfı'ndan Mike Neuder tarafından kaleme alınan Optimist röleler ve bunların nerede bulunacağı başlıklı makaleyi okumanızı önemle tavsiye ederiz. Bu gönderi, MEV-boost'taki rölelerin nasıl çalıştığını, mevcut dengelerini ve işletme maliyetlerini ve verimliliği artırabilecek bazı değişiklikleri ayrıntılarıyla anlatıyor. İlginç bir şekilde, Flashbot tahminlerine göre MEV-Boost'ta bir geçiş çalıştırmanın maliyeti şu anda yaklaşık 100.000$/yıl'a mal oluyor.

Deterministik

Modüler blok zincirlerin (şu anda göründükleri şekliyle) determinizminden bahsetmeden önce, bir önceki “Modüler MEV” makalemize bir göz atalım. Bunun "resmi" veya kapsamlı bir kesinlik görüşü olmadığını unutmayın, ancak anlama kolaylığı için Toplama kesinliğinin nüanslarını en doğru şekilde temsil ettiğine inanıyoruz.

Pending_On_L2: Toplama sıralayıcısı, bir kullanıcının işleminin sonunda güvenliğinin temel katmanında gerçekleştirileceğine ve sonlandırılacağına dair yumuşak bir taahhüdü temsil eder.

Finality_On_L2: Sıralayıcı, Toplamanın durum geçiş işlevini taahhüt etti ve blok, Toplamanın standart zincirine eklendi.

Pending_On_L1: İşlemin giriş veya çıkış/durum geçiş işlevi L1'de yayınlandı, ancak geçerlilik kanıtı henüz yayınlanmadı veya tahkim süresi henüz sona ermedi - bu, birbirini izleyen iki dönem için Ethereum gerektirir. Bu, çoğu İyimser Özetlemenin kesinliğe ulaştıklarını söylediği noktadır, ancak bu noktada spesifik zincirler arası köprüye göre hala keyfi bir 7 günlük meydan okuma süresi vardır.

Kesinlik_On_L1: Bir İyimser Toplama için, tahkim süresi sona erdi veya yayınlanmış ve doğrulanmış bir geçerlilik kanıtı, birbirini izleyen iki dönemde üstün çoğunluk tarafından onaylandı.

Şimdi, Egemen Paylaşımlı Sıralama Toplamasında bu biraz farklı görünüyor, bunu bir diyagramla açıklamaya çalışalım:

Bu durumda teorik olarak L1'de L2'den önce determinizm elde edebiliriz, vb.? Evet, bu durumda L2 sonuçta egemendir. Bu, dolandırıcılık kanıtları ve meydan okuma dönemleri olmadığını veya geçerlilik kanıtı kullandığınızı varsayar.

Peki bu kesinlik seviyelerine nasıl ulaşacağız? Blok kesinliği, kanonik zincire geri alınamayan bir blok eklendiğinde elde edilir. Bununla birlikte, tam veya hafif düğümlere bağlı olarak burada bazı nüanslar vardır. Sıralı bir blok söz konusu olduğunda, bir DA katman bloğuna dahil edildiğinde deterministiktir. Bloklar (durum kökleri olan), onlara temel katmanın sıralı bloklarından türetilen geçerli bir durum kökü garantisi veren Toplama tam düğümleri/doğrulayıcıları tarafından uygulanır. Tam düğümlerin ötesindeki determinizm için (hafif istemciler veya zincirler arası köprüler gibi), bu durum kökünün geçerliliğinden emin olmalısınız. Burada, aşağıda açıklanan yöntemlerden birini kullanabilirsiniz. Ayrıca, başka bir yaklaşım, doğrulayıcıları, bir bono ve müteakip dolandırıcılık kanıtı aracılığıyla durum kökünün (İyimser yol) doğru kanıtlanmasından sorumlu kılmaktır. Ek olarak, bir geçerlilik kanıtı (ZK) sağlayabilirsiniz.

Blok kesinliğini elde etmenin farklı yolları:

1. Proof of Work (PoW), LMD+Ghost, Goldfish, Ouroboros (PoS) ve diğer olasılıksal yöntemlerle.

2. Blokları imzalayan yeterli sayıda komite üyesi aracılığıyla kanıtlanabilir bir yöntem. (örn. Tendermint 2/3, Hotshot2 veya diğer PBFT türleri)

3. DA katmanındaki işlemlerin/blokların sıralamasına ve kurallarına, yani kanonik zincir ve çatal seçim kurallarına bağlıdır.

Farklı mekanizmalar aracılığıyla farklı türden kesinliklere ulaşabiliriz.

Kesinliğin bir türü, tek bir lider seçimiyle elde edilebilen "geçici kesinliktir" (beklemede gibi). Bu durumda, her yuvada yalnızca bir veya sıfır blok olacaktır (işlenmiş olsun veya olmasın) ve senkronizasyon katmanı bu bloklardaki işlem sırasını güvenli bir şekilde üstlenebilir.

Başka bir kesinlik türü, yumuşak kesinlikten daha güçlü garantiler (esasen nihai) sağlayan "kanıtlanabilir kesinliktir". Kanıtlanabilir kesinlik elde etmek için, sipariş verenlerin çoğunluğunun bir bloğu imzalaması ve böylece bloğun kanonik olduğu konusundaki anlaşmalarını ifade etmesi gerekir. Bu yaklaşım güzel olsa da, esasen blok sıralamasını garanti ettiği için tek bir lider seçimi uygulanmışsa gerekli olmayabilir. Açıkçası, bu, uygulanan belirli lider seçim algoritmasına bağlıdır. Örneğin, %51'lik bir uygulama mı, %66'lık bir uygulama mı, yoksa tek bir lider mi (tercihen rastgele (VRF) ve gizli seçim). Ethereum'daki determinizm hakkında daha fazla bilgi edinmek istiyorsanız, şiddetle tavsiye ettiğimiz bu makaleyi ve daha sonra sınırsız sıralayıcı kümeler için önereceğimiz makaleyi okuyun.

lisanslı, yarı lisanslı veya izinsiz

Muhtemel DoS saldırılarını önlemek için, emir veren grubuna katılmak ve emir veren katmanına işlem göndermek için ekonomik engeller konulmalıdır. Sınırlı (sonlu sayıda sıralayıcı) ve sınırsız (sınırsız sayıda sıralayıcı) gruplarda, senkronizasyon katmanının (sıralayıcılar arasında yayılan bloklar) yavaşlamasını veya DDoS saldırısı altında kalmasını önlemek için partileri DA katmanına göndermek için ekonomik engeller konulmalıdır. . Bununla birlikte, DA katmanının kendisi de bir miktar koruma sağlar, çünkü ona veri göndermek bir maliyet (da_fee) gerektirir. Sınırsız gruba katılmak için gereken güvenlik teminatı, senkronizasyon katmanının istenmeyen e-posta gönderilmesini önlemek için gerekli tüm ek maliyetleri karşılamalıdır. Öte yandan, sınırlı bir gruba katılmak için gereken marj talebe bağlı olacaktır (maliyet/gelir açısından dengelenmiş).

Sınırsız bir sıralayıcı grubu için, sıralayıcı katmanında kanıtlanabilir kesinlik elde edemeyiz (çünkü tam olarak kaç aktif seçmen/imzalayan olduğunu hiçbir zaman bilemeyiz). Öte yandan, sınırlı bir yardımcılar grubunda, kanıtlanabilir kesinlik, blokları imzalayan yardımcıların çoğunluğunun elde etmesiyle elde edilebilir. Bu, senkronizasyon katmanının sıralayıcı katmanından ve herhangi bir zamanda kaç tane sıralayıcının aktif olduğundan haberdar olmasını gerektirir ki bu da bir miktar ek yüktür. Sınırlı bir sıralayıcı setinde (örneğin 100'e kadar), ademi merkeziyetçilik ve sansür direnci pahasına olsa da, "performansı" iyileştirmek için sıralayıcı sayısını da optimize edebilirsiniz. "Hızlı" kanıtlanabilir kesinlik sağlamak için sınırlı grupların ve ekonomik garantilerin önemi de belirleyicidir.

Sınırsız sıralayıcı ve sınırlanmış sıralayıcı türleri de geleneksel blok zincirlerine yansıtılır.Örneğin, Ethereum'daki PoS (Casper+LMD-GHOST) sınırsız türü benimserken, Cosmos SDK/Tendermint tabanlı zincir sınırlı türü benimser. İlginç bir düşünce, ortak emirler etrafında topluluktan hisse ispatı benzeri ekonomi ve seçenekler görmeyi bekliyor muyuz? Bu bağlamda, bazı varlıkların merkezileştirilmesine yönelik bir hareket gördük (bu nedenle, zaten bazı büyük proof-of-stake sağlayıcılarınız/havuzlarınız varsa, unbounded gerçekten önemli değil). Merkezileştirmeyi "gizlemelerine" rağmen, yine de isterseniz madencilik yapabilirsiniz. İdeolojik bir bakış açısından, seçenekler neredeyse her zaman sınırsız olmalıdır - ancak ekonomik ilkelerin onları her halükarda çok benzer kıldığını unutmayın. Katılımcılar kim olursa olsun, DA maliyeti ve donanım maliyeti gibi ödediğiniz tutarın ekonomisi aynı olmalıdır (yine de bu, tahsis ettiğiniz ve deneyimlediğiniz hisse kanıtlarının sayısı ve verimli bir şekilde azaltılabilir). altyapının işletilmesi). Sınırlı PoS dünyasında bile, bir grup altyapı sağlayıcısının neredeyse tüm zincirlerde en büyük ve en yaygın doğrulayıcılar haline geldiğini gördük. Çoğu Cosmos zincirinde, doğrulayıcılar arasındaki bağımlılıklar zaten çok büyük ve bu kesinlikle söz konusu zincirlerin ademi merkeziyetçiliği ve sansür direnci için bir tehlike oluşturuyor. Yine de çok farklı bir gerçek şu ki, herhangi bir bireysel yatırımcı, seçtikleri herhangi bir doğrulayıcı ile herhangi bir miktarda stake yapabilir. Ne yazık ki, bu genellikle listenin başına atanır ve hayat devam eder. Tekrar soruyoruz: modüler bir dünyada benzer bir ekonomik model bekliyor muyuz? Keşke böyle olmasaydı, ancak uzmanlıkla genellikle en uygun olana ihtiyaç duyarsınız - ve bunlar genellikle profesyonel hisse ispatı sağlayıcılarıdır. Bu ekonomik konuları daha sonra ayrı bir bölümde ele alacağız.

Ancak, tüm bu konularda unutulmaması gereken en önemli şey, hafif istemciler ve DAS piramidi aracılığıyla nerede olurlarsa olsunlar (Gize'de bile) herkesin kullanımına açık olan son kullanıcı kimlik doğrulamasıdır.

Kaynak: @JosephALChami

Sınırlı ve sınırsız ayırıcıların ödünleşimleri ve avantajları şunlardır:

Sınırsız sıralayıcı seti:

*Yeterli tahvili/staking'i olan herkes sıralayıcı olabilir = yüksek derecede ademi merkeziyetçilik

• Sıralayıcı özünde sonsuz olduğu için tek bir lider seçimine sahip olmak mümkün değildir.
• VRF ile tek olmayan lider seçimi mümkündür, ancak kaç tane siparişçi olacağı bilinmediği için VRF parametrelerini belirlemek zordur. DoS saldırılarından kaçınmak için mümkünse bu aynı zamanda gizli bir lider seçimi olmalıdır.
• Lider seçimi yok = kaynak israfı Sorun: Blok inşası aslında ücretsiz bir yarışmadır, ilk geçerli bloğu/partiyi gönderen kazanır ve diğer herkes kaybeder. · · · Sipariş veren düzeyinde kanıtlanabilir bir kesinlik yoktur, yalnızca olasılıksaldır: örneğin LMD Ghost+Casper
• Kesinlik, yalnızca partiler DA katmanına yazıldıktan sonra elde edilir (yalnızca temel blok süresiyle sınırlıdır, Celestia'nın durumunda 15 saniye).
• Sınırsız kümeler, sınırlı kümelere göre sansüre "daha iyi" dayanıklıdır.

Sınırlı sıralayıcı seti:

Bu, Ethereum'un tek slot determinizmi ve süper "çoğunluk" komitesine sahip olma çözümlerinden biridir.

• Herhangi bir zamanda izin verilen sıralayıcı sayısında bir sınır vardır.
• Sınırlı kümeler, sınırsız kümelerden daha karmaşıktır.
• Sıralayıcı katmanı için güçlü bir deterministik garanti sağlayan tek bir lider seçimi uygulanabilir.
• Senkronizasyon katmanının, hangi blokların geçerli olduğunu belirlemek için sıralayıcılar kümesini anlaması gerekir.
• DA katmanına yazılan yerleşim katmanı bloklarına (fork seçim kuralları gibi) sorter setlerinin (veya set değişikliklerinin) yazılması, senkronizasyon katmanının sorter setini bağımsız olarak belirlemesini sağlar. Örneğin, Sovereign Labs' Rollup'ın yaptığı budur, koleksiyon değişiklikleri DA katmanında yayınlanan bir geçerlilik kanıtına yazılır.
• Düzenleyici katmanın güçlü kesinlik garantileri, DA katmanı yeterince hızlıysa gerekli olmayabilir (ancak, mevcut optimize edilmemiş yerleşim katmanı kurulumlarının çoğu en az 10+ saniye blok süresine sahiptir).

Bu sıralayıcı setlerin nasıl izlendiği ve yeni üyelerin nasıl eklendiği veya çıkarıldığı konusunda önemli bir tasarım alanı vardır. Örneğin, bu, Token Sahibi Yönetimi aracılığıyla mı sağlanacak (o zaman koleksiyonları kullanan birçok farklı Token ve Toplamaya ne dersiniz?). Bu, sosyal mutabakat yoluyla zincir dışı sinyal değişikliklerinin mümkün olabileceği anlamına gelir (örneğin, Ethereum'u örnek olarak alın). Bununla birlikte, gerçek zincir üstü konsensüsün açıkça belirlendiğini ve konsensüs kurallarını ihlal etmenin cezalarının zaten mevcut olduğunu unutmayın.

Paylaşılan Ayıklayıcılar İçin Ekonomik Mekanizma

Bir sıralayıcı ağını paylaşmanın ekonomisi, bazı ilginç seçeneklere izin verir. Daha önce tartıştığımız gibi, paylaşılan bir sipariş ağındaki doğrulayıcılar, tipik L1 doğrulayıcılarından çok farklı değildir. Katıldığı ağ, niyetleri (eski adıyla PBS) almak ve bu nedenle işlemleri teklif etmek ve sipariş etmek olan tek bir görevi gerçekleştirmek için daha optimize edilmiştir. Tıpkı "normal" doğrulayıcılar gibi, gelir ve maliyet bileşenleri vardır. Denklemin her iki tarafında da, normal L1'e benzer şekilde doğrulayıcıların katıldığı ağlarda çok fazla esneklik vardır.

Gelir, paylaşılan sıralayıcıyı kullanmak için belirli bir ücret ödeyerek nihai olarak etkileşimde bulunmak istedikleri kullanıcılardan veya Toplamalardan gelir. Bu ücret, çekilen MEV'nin bir yüzdesi (sayıları girmek tahmin etmek zor olabilir), zincirler arası değer transferleri, Gaz veya etkileşim başına sabit bir ücret olabilir. En uygun gelir çözümü, paylaşılan sipariş verene, paylaşılan güvenlik ve likiditenin faydalarıyla birlikte Toplama paylaşılan sipariş veren aracılığıyla kazanılan ek değerden daha az değer ödemek olabilir. Ancak bunun dezavantajı, yığının başka bir bölümünün ademi merkeziyetçilik faydalarını ölçmenin zor olmasıdır. Ancak, paylaşılan sipariş veren ağı kendi ekosistemi içinde büyüdükçe, ücret alma yeteneği artabilir. Bu, büyük ölçüde, belirli ölçek ekonomileri ile kolayca bir araya gelme yeteneklerinden kaynaklanmaktadır. Ağa daha fazla Toplama ve uygulama katıldıkça, daha fazla etki alanları arası MEV ayıklayabilecektir.

Maliyet açısından, paylaşılan sipariş ağlarının da rekabet eden seçenekleri vardır. DA katmanında yayınlama maliyetini veya hatta Rollup'taki uygulamalarla etkileşim kurma maliyetini finanse ederek ağ kullanımlarını kolayca finanse edebilirler. Bu, Web 2.0 şirketleri tarafından kullanılan stratejiye benzer; burada, kullanıcı edinme (veya toplama) üzerindeki ilk kaybı, uzun vadeli gelirlerinin ücretlerden daha ağır basacağını umarsınız. Başka bir yeni veya Kripto-yerel yöntem, Rollup'ın yerel Token ile DA ücretlerini ödemesine izin vermektir. Burada paylaşılan sıralayıcı katmanı, DA katmanında veri yayınlamak için gerekli olan Token ile Rollup'ın yerel Token'ı arasındaki fiyatlandırma riskini taşır. Özünde, hala paylaşılan bir sıralayıcı ön maliyetidir, ancak "tedarikçinin" Simgesini (yani Toplama) elde ederek ekosistem tutarlılığı yaratır. Bu, AppChain makalesinde açıkladığımız depo yapısına biraz benzer ve maliyetleri azaltmak için farklı DA biçimleri kullanılabilir. Farklı DA katmanları, kullanıma, kullanıcıların hafif bir istemci aracılığıyla kolayca doğrulama yapma veya yalnızca farklı blok boyutu seçimleri yapma becerisine bağlı olarak farklı fiyatlandırma sunacaktır. Son olarak, paylaşılan sipariş veren, DA katmanına yayınlamadan önce işlemleri de toplu hale getirebilir. ZKR söz konusu olduğunda, bu, belirli sayıda işlem bakiyesi aracılığıyla işlem maliyetlerini azaltabilir ve ORU açısından, şu anda çeşitli Toplamalarda görebildiğimiz çeşitli toplu işleme Gazı optimizasyonları gerçekleştirebilirsiniz. Bu, DA katmanına yayınlanması gereken veri miktarını azaltacak, böylece paylaşılan sıralayıcı ağının maliyetini düşürecek ve tüm ağın karlılığını artıracaktır. Bu, birlikte çalışabilirliği sınırlamak ve blok kesinlik sürelerini değiştirmek pahasına olacaktır (daha önce bahsedildiği gibi L1'de determinizm).

Genel olarak, bir sıralayıcı ağını paylaşmanın ekonomisi, bazı ilginç deneylere ve önyükleme stratejilerine izin verir. Temel farkın ekosistemin boyutu olacağını tahmin ediyoruz, bu nedenle etki alanları arası MEV'lerin sayısı maliyet açısından daha fazladır. Ayrıca, Espresso ekibinin paylaşımlı sipariş verenlerle ilgili blog gönderisine göz atmanızı şiddetle tavsiye ederiz, bu tür ağların ekonomik ödünleşimlerini (ve olumlu yanlarını) da kapsarlar. Rollup'ın neden paylaşılan ayırıcılardan (ekonominin yanı sıra) yararlanma konusunda motive olduğunu göstermek için, bunu bir toplama teorisi perspektifinden değerlendirebiliriz.

Toplama Teorisi ve Paylaşılan Sıralayıcılar

Paylaşılan ayıklayıcıların getirdiği özellikleri tanımlamanın başka bir yolu, toplama teorisinin merceğinden geçer. Toplama teorisi, bir platformun veya toplayıcının diğer platformları ve kullanıcılarını, önemli ölçüde kullanıcı dikkatini çekmek için sistematik bir şekilde nasıl entegre ettiği kavramını ifade eder. Esasen oyunu kıt bir kaynağın (örneğin, blok alanı) tahsisinden bol bir kaynağı kontrol etme ihtiyacına (yine, blok alanı bu örnekte anlamlıdır) kaydırıyorsunuz. Toplama Teorisi, toplu kullanıcı tabanına hizmet etmek için aslında tedarikçileri ve ürünleri (yani Rollup ve Blockspace) bir süper kullanıcı deneyiminde bir araya getirir. Bu toplayıcıların ağ etkisi büyüdükçe, bu ilişki giderek daha özel hale gelir. Bu olurken, kullanıcı deneyimi benzer kurulumlar arasında önemli bir farklılaştırıcı haline gelir. Yeni kullanıcıları çekmek için teşvikler varsa (iyi bir kullanıcı deneyimi ve daha iyi birlikte çalışabilirlik gibi), ağ etkileri yeni tedarikçileri yönlendirdiğinden ve Yeni kullanıcılar katıldığından, Rollup'ın kendi ağına veya farklı bir kuruluma geçmesi olası değildir. Bu, yalnızca sağlayıcı ve kullanıcı açısından değil, aynı zamanda toplu sansüre dirençli bir bakış açısıyla da bir volan etkisi yaratır.

Kaynak: Toplama Teorisi 2015, Ben Thompson

Paylaşılan sıralayıcılar alanında, Toplama Teorisi, tümü yığının benzer dikeylerini kullanan çeşitli Toplamaların "kombinasyonları" ve federasyonları olarak görülebilir - kullanıcıların aynı deneyimi elde etmesine izin verirken kendilerini ve diğerlerini güçlendirir.

Sağlayıcılar (Toplamalar gibi) teorik olarak paylaşılan yardımcı kümeye özel değildir, ancak pratikte paylaşılan yardımcı küme, toplamaları ve kullanıcılar, bu toplamaların artan kullanımına yol açan bir dizi ağ etkisi döngüsünden yararlanır. Bu avantajlar, Toplamaların ve kullanıcıların, katılmazlarsa kaybedecekleri daha çok şey olduğundan, paylaşılan bir yığına entegre olmalarını kolaylaştırır. Tek bir sıralayıcı setini paylaşan yalnızca iki Toplamanız olduğunda bu avantajları görmek zor olsa da, denkleme daha fazla Toplama ve Kullanıcı ekledikçe bunlar daha net hale gelir. Paylaşılan sıralayıcı kümelerinin, kullanıcılar kendileriyle etkileşimde bulunduklarını bilmeseler bile, işlemlerini sipariş ederken kullanıcılarla doğrudan bir ilişkisi vardır, çünkü onların bakış açısından, yalnızca etkileşimde bulunmak için bir nedenleri olan Toplamaları kullanırlar ( Bu, sıralamanın/sıralayıcıların özel hale geldiği anlamına gelir). Bu sıralayıcıların tek maliyeti, blok alanı ve onu güvence altına alan belirteçler son kullanıcı için değerli olduğu sürece, gerçekten onları çalıştırmanın donanım maliyetidir. İşlem ücretleri dijitalleştirilir, kullanıcıların cüzdanlarından ödenir ve belki gelecekte, hesap soyutlamadaki ödeme ana bilgisayarları gibi ilerlemeler yoluyla soyutlanabilir (ancak, birisinin DA, sipariş verme ve yürütme masraflarını üstlenmesi gerekecektir).

Bu, Josh ve Jordan'ın Astria'daki eski şirketi Google'ı düşündüğümüzde daha mantıklı. Başlangıcından bu yana Google ürünleri, özellikle tek tek sayfaları ve makaleleri modüler hale getirerek oluşturulan ve bunların küresel arama penceresinden doğrudan erişilebilir olmasını sağlayan Google Arama'da AT fikrinden ilham almıştır.

Paylaşılan bir ayıklayıcı seti söz konusu olduğunda, Toplamaları kullanan kullanıcılar (bir ayıklayıcı setini paylaşanlar), daha düşük ve daha düşük satın alma maliyetlerine sahiptir, çünkü tedarikçilerin (Toplama) sayısı arttıkça sete ilgi duymaları muhtemeldir. . Bu, çoğu durumda bir toplayıcının (veya çoklu toplayıcının) olası bir kazan-kazan etkisi olduğu anlamına gelir, çünkü bir toplayıcının değeri tedarikçilerin sayısıyla birlikte artar (elbette kullanıcı deneyimi iyi olduğu sürece). Bunun aksine, tek bir seri ağda, müşteri kazanımı tek bir ağ ve onun uygulamalarıyla sınırlıdır. Kullanıcılar, Toplama uygulamasını farklı bir Toplamada kullanmak isterse, (mevcut sınırlamalar dahilinde) ağdan tamamen çıkış yapmaları gerekir. Bu, kullanıcı bağlılığının ve değerinin çok yüksek olmadığı anlamına gelir ve aynı zamanda, başka bir Rollup ekosisteminin yüksek değerde olması (veya daha fazla teşviğe sahip olması) durumunda, sermayenin her an kaybedilebileceği anlamına gelir.

Nitelikler ve Ödevler Özeti

Öznitellikler

Paylaşılan sıralayıcı kümesi, birden çok toplama için işlemleri toplayan ve sıralayan bir toplama ağıdır. Bu Toplamalar aynı sıralayıcıyı paylaşır. Kaynakların bu şekilde birleştirilmesi, Toplamaların daha güçlü ekonomik güvenlik ve anti-sansür yetenekleri kazanması anlamına gelir, bu da hızlı yumuşak deterministik garantiler ve koşullu çapraz Toplama işlemleri sağlayabilir.

Şu anda, aynı sıralayıcı setini paylaşan Toplamalar arasında atomiklik hakkında çok fazla gürültü var, çoğunlukla varsayılan olarak atomik olup olmadığı - ki değil. Bununla birlikte, söz konusu Toplamalar, koşullu işlemleri içeren, aralarında bağımlılıklar olarak birbirlerinin durum geçiş işlevlerini (STF'ler) uygularsa, o zaman gerçekten de aralarında atomiklik elde edebilirler - yuva/blok zamanı Hizalamaları olduğu sürece (paylaşılan sıralayıcı kümelerinde olduğu gibi). Bu durumda, atomik birlikte çalışabilirlik elde etmek için, gerçekten yalnızca A zincirinde B zincirinin hafif bir istemcisini çalıştırmanız gerekir ve bunun tersi de geçerlidir (IBC'nin nasıl çalıştığına benzer). Güvenlik önlemlerinin birlikte çalışabilirliğini daha da güçlendirmek için (hafif düğüm olarak tek bir tam düğüme güvenmenin ötesinde), durum doğruluğunu sağlama "kehanet sorununu" çözmek için ZKP'yi (Devlet Kanıtı) uygulayabilirsiniz. Bu, koşullu bir işlemin veya buna benzer bir şeyin aralarında kanonik bir zincirler arası köprüye çarpıp çarpmadığını görmeyi daha net hale getirecektir. Dolandırıcılık kanıtları da bir olasılıktır, ancak açıkça bir meydan okuma dönemi bırakacaktır (bu, bu riskin maliyetini karşılamak için üçüncü bir tarafın geleceği anlamına gelir). Ayrıca, hafif istemciler söz konusu olduğunda (tam düğümler yerine), imza üstbilgisini beklemek + dolandırıcılık önleme penceresi (varsa) nedeniyle en az bir blok geride olacaktır.

"Zincirler arası köprü" sorununun büyük olasılıkla hafif istemciler ve sıfır bilgi kanıtları ile çözüleceğine inanıyoruz. Bu durumda hafif bir istemci (akıllı sözleşme yerine) kullanmanın zorluğu, Toplama düğümü tarafındaki sert çatalların (yükseltmeler, vb.) köprülerini çalışır durumda tutmak için birbirleriyle koordine olması gerektiğidir (tıpkı IBC'nin etkinleştirmesi gerektiği gibi) aynı durum modülü). Bu belirli konuya (ve bununla nasıl başa çıkılacağına) daha derin bir dalış yapmak istiyorsanız, bu sunuma göz atmanızı önemle tavsiye ederiz.

Paylaşılan sipariş verenlerin bu kadar iyi ölçeklenmesinin nedeni, herhangi bir durumu yürütmemesi ve saklamamasıdır (günümüzde merkezi sipariş verenlerin yaptığı gibi). Aynısı, Toplama düğümlerinin kendileri için de geçerlidir (kendi aralarında atomiklik istemedikçe - örneğin, hafif istemci/durum kanıtı). Bu düğümler, yalnızca Toplamaları için geçerli olan işlemleri ve kendileri için geçerli olan tüm koşullu etki alanları arası işlemleri yürütür. Bir Toplama düğümünün birden fazla Toplama için durum yürütmesi ve depolaması gerekiyorsa, ölçeklenebilirliği engeller ve merkezi olmayanlığı (ve dolayısıyla sansür direncini) azaltır. Bu aynı zamanda blok üreticisi-kurucu ayrımı (PBS) kavramını da güçlendirir. Yine de inşaatçıları tamamen ayırmamız ve üreticileri engellememiz gerekiyor. Mevcut kurulumda, sipariş verenler esasen bir oluşturucu ve blok üreticisidir (işlemleri yürütmemelerine rağmen). İdeal bir kurulum, sipariş verenin yalnızca yüksek düzeyde optimize edilmiş bir oluşturucu kurulumundan gelen blokları körü körüne imzalamak ve blokların doğru bir şekilde uygulanmasını sağlamak için var olduğu bir kurulum olabilir (bu sertifikaya yüksek derecede ekonomik kesinlik ve sansür direnci sağlarken). Bu şekilde, Rollup düğümlerine yumuşak kesinliği garanti etmek için yüksek derecede güvenlik ve taahhüt sağlayabilirler.

Çapraz toplama koşullu işlemleri için, toplama düğümlerinin (yürütücüler) ara durum kökleri sağlamasına yardımcı olmak ve toplamalar arasında atomikliği sağlamak için de mevcutturlar.

Pazarlıksız

Yukarıda belirtilen zaman aşımı parametresinin, sipariş veren setinin ana düğüm/konsensüs mekanizmasına bağlı olarak MEV ve işlem dahil etme üzerinde bazı ilginç etkileri vardır. Örneğin, zaman aşımı parametresi, uygulamaya özel zincir belgemizde nispeten kısa olarak tanımlanırsa, merkezi olmayan bir sipariş veren kümesinin blok üreticilerinin verileri olabildiğince hızlı yayınlaması kritik önem taşır. Böyle bir dünyada, ana düğümler olmak için rekabet eden ve artık karlı olmayana kadar blok alanı için DA katmanında teklif veren "doğrulayıcılar" arasındaki rekabeti görebilirsiniz.

Evan'ın Celestia forumlarındaki orijinal tembel sipariş gönderisinde bahsettiği gibi, işlemleri gerçekleştirmeden önce temel katmanda (bu durumda Celestia) yayınlanmasını beklemek çok verimsiz. Şu andan itibaren, kullanıcı deneyimini beklemek için çok uzun olan temel katmanın engelleme süresiyle sınırlısınız. Daha iyi bir kullanıcı deneyimi için, paylaşılan sipariş veren, Rollup'lara yumuşak deterministik taahhütler (daha önce açıklandığı gibi) sağlar; bu taahhütler, kullanıcılara mevcut merkezi Rollup'larda alışık oldukları kullanıcı deneyimini sağlar (bir yandan da merkeziyetçiliği ve yüksek sansür direncini korurken). Yumuşak taahhütler, esasen yalnızca nihai işlem sırasına yönelik taahhütlerdir, ancak ağır ekonomik garantiler ve bir kez yayınlandıktan sonra hızlı sonuçlandırma ile desteklenir. Bu aynı zamanda dolandırıcılık kanıtları kapsamındadır (girişte belirtildiği gibi). Gerçek kesin kesinlik, tüm işlem verileri temel katmanda yayınlandıktan sonra elde edilir (yani, L1 aslında daha hızlı kesinlik elde eder). Rollup'ın, Rollup'ta gerçekleşen egemenlik kanıtı doğrulaması için sahtekarlık kanıtları mı yoksa sıfır bilgi kanıtları mı kullandığına bağlıdır. Bu ayrımın istenmesinin nedeni, sıralayıcıdan durum geçişlerinin devasa darboğazını ortadan kaldırmaktır. Bunun yerine, Toplama düğümleri yalnızca kendileri için geçerli olan düğümlerle ilgilenir (yani, uygun birlikte çalışabilirlik için koşullu işlemler, durum kanıtı veya hafif düğüm doğrulaması eklememiz gerekir). Katı determinizm hala temel katmana bağlıdır (ancak bu, Celestia'da 15 saniyeye ulaşabilir ve ayrıca Tendermint altında deterministiktir), bu da bize Rollup'ta nispeten hızlı sabit determinizm garantileri verir.

Doğrulamayı, işlem boyutunu optimize etmek için ağ içindeki sıfır bilgi kanıtlarını kullanın (örneğin, yalnızca durum farklılıklarını yayınlayın - ancak bu, ZKP yayınlanana kadar daha yüksek bir güven düzeyi ekler). Daha önce bahsedildiği gibi, bu durum kanıtları, bağlı zincirlerin/toplamaların daha kolay ve daha hızlı birlikte çalışabilirliğe sahip olmasını sağlamak için kullanılabilir (sınama pencerelerini beklemeden).

Bu koşullu işlemlerin bir dezavantajı, muhtemelen daha pahalı olmaları, daha yüksek doğrulama ve düzenleme maliyetleri gerektirmesi (Cosmos zinciri tarafından sübvanse edilen Tendermint blok başlık doğrulamasının maliyeti gibi) ve sisteme biraz gecikme eklemesidir ( ancak yine de İzole Toplamalardan daha hızlıdır). Dikey olarak paylaşılan entegrasyonla elde edilen atomiklik, bu sorunları telafi edebilir.

Yeni bir toplamanın önyükleme aşamasında, paylaşılan bir harmanlayıcı seti kullanmak çok mantıklıdır ve bir sağlayıcı olarak elde edeceğiniz avantajlar, muhtemelen hendek seviyesinde yapmaya "zorlanabileceğiniz" bazı ödünleşimlerden daha ağır basacaktır. Bununla birlikte, çok sayıda işlem ve ekonomik faaliyetin olduğu zaten olgunlaşmış bir Toplama için, hendeğin bir kısmından vazgeçmek muhtemelen mantıklı değil.

Bu, halihazırda olgunlaşmış Toplamaları paylaşılan sete katılmaya teşvik etmek veya hatta son derece olgun Toplamaları kendi ağını oluşturmaktan alıkoymak için çıkarılan MEV'nin benzer ekonomik/işlemsel (Toplama başına) ağırlıklı yeniden dağıtımına ihtiyacımız olup olmadığı sorusunu gündeme getiriyor. Bunların hepsi oldukça teorik, ancak şüphesiz, paylaşılan dikey dünyalardaki MEV'lerin farklı etkinlik seviyelerine sahip birçok Toplama arasında nasıl temsil edileceğine ilişkin ilginç bir düşünce süreci. Örneğin, değeri yönlendiren benzersiz bir Toplama, bu kârların bir kısmını Sıralayıcı Kümesi aracılığıyla başkalarıyla paylaşıyorsa (muhtemelen fazla "değer" getirmiyor), o zaman kendi silo sistemlerine geçmeleri için daha fazla neden olmalıdır. EigenLayr'dan Sreeram'ın da bu konuda okumanızı tavsiye ettiğimiz bazı düşünceleri var.

Arama yapanların yeni zincirler geliştirmesinin önemli bir teknik maliyeti olduğu düşünüldüğünde, bu giderek daha önemli hale geliyor, bu nedenle standartlaştırma ve "kendi" MEV'leri üzerinde bir miktar egemenlik sağlama, başlamak için iyi bir yer olabilir. Uygulamada, MEV'de baskın arayüz (veya yazılım) galip gelebilir, ancak aslında altyapının kritik parçalarını çalıştırarak bu yazılımdan para kazanmak çok zordur (merkezileşmeye yol açar). Pazar düzeyinde, paylaşılan bir sipariş verenin sağladığı şey, temel olarak, daha sağlıklı rekabete yol açabilecek merkezi bir müzayede ile birden fazla sağlayıcı için ortak bir mempool'dur.

Buradaki bir endişe, iki Toplama'nın paylaşılan kümede sıralayıcılar çalıştırması durumunda, "daha az ekonomik" değere (A) sahip bir Toplama'nın, Toplama (B) bloklarından yüksek miktarda MEV + ücret içeren bir toplama önermek için seçilebilmesidir. . Toplama B'nin bakış açısına göre, yalıtılmış yaklaşımda kendileri için saklayacakları bazı değerleri esasen kaçırırlar.

Birlikte çalışabilirlik ödünleşimlerini ele alma

Birlikte çalışabilirlik tarafından sunulan değiş tokuşlar ve bazı sorunları çözmenin başka bir yolu hakkında bir başka not aşağıdadır:

Paylaşılan sipariş ağının amacı, bu durumda açıkça büyük bir avantaj olan çoklu zincirler için kanonik bir garanti sağlamaktır. Bu, Toplamalar arasında verimli durum geçişlerini garanti eden bir mekanizma ile birleştirilebilir. Bu, komite tabanlı bir yaklaşım (ör. PoS), güvenli kanıtlar (İyimser yaklaşım) veya bizim tercih ettiğimiz, komite imzalarıyla desteklenen bir ZKP olabilir. Paylaşılan sıralayıcılar "tembel" olduğundan, yalnızca birden çok Toplamanın işlemlerini sıralamak için süper bloklar oluştururlar ve belirli işlem yürütme, belirli bir Toplamaya bırakılır. Durum kanıtları (yani, Lagrange, Axiom veya Herodotus, vb.), egemen toplamalar genelinde kesinlik kanıtlarını potansiyel olarak elde etmek için tüm olası çözümlerdir. Staking havuzları, EigenLayr, vb. gibi şeyler aracılığıyla ekonomik olarak garantili kesinlik kanıtları bile ekleyebilirsiniz. Temel fikir, paylaşılan bir sıralayıcının ekonomik bir sıralama garantisi sağlaması ve bu sıralamadan üretilen geçerlilik kanıtlarının belirleyici olmasıdır. Temel fikir, Toplamaların işlemleri birbiriyle senkronize olarak yürütebilmesidir. Örneğin, iki Toplama düğümünden oluşan bir ağ, ZKP ve mevcut veriler (verimli bir DA katmanına yayınlanan veriler) aracılığıyla her iki Toplama geçmişinin de geçerli olduğunu koşullu olarak bilebilir. Bir Toplama düğümü, hem A hem de B ağlarından tek bir Toplama bloğu ön eki yayınlayarak, iki Toplama'yı aynı anda halledebilir. Belirtilmesi gereken bir nokta, koşullu çapraz toplama işlemlerinin paylaşılan yürütme yoluyla iki ayrı sistemden kaynak tüketmesidir, bu nedenle çapraz toplama atomik (veya senkronize) işlemler muhtemelen tek toplamalı iç işlemlerden daha pahalı olacaktır.

Özlü ayrıca, burada görüntülenebilen Optimism hiper zincir ekosisteminde paylaşılan sipariş verenler (ve paylaşılan dolandırıcılık kanıtlayıcıları) ile Toplamalar arasındaki zincirler arası "atomik" işlemleri de kapsıyordu. Ayrıca, Polymer'den Bo Du'nun da belirttiği gibi: "Çapraz zincir atomik işlemler, yazarken veritabanı parçaları arasında kilitler edinmeye benzer".

Dikey Entegrasyonun Geleceği

SUAVE zincirlerinin olası iç işleyişi, Jon Charbonneau ve diğerleri tarafından zaten derinlemesine araştırıldı, bu yüzden çok fazla ayrıntıya girmeyeceğiz. Daha ayrıntılı bir açıklama istiyorsanız, makalesine göz atabilirsiniz. Bununla birlikte, hem ne kadar modüler olabileceğimizi (ve nedenini) vurgulamak hem de dikey entegrasyonla ilgili bazı sorun ve endişeleri ortaya koymak için dikey entegrasyonun ayrı bir girişi hak ettiğini düşünüyoruz.

Astria, Espresso ve Radius'un şu anki paylaşımlı sipariş veren planı çok modüler olsa da, sipariş verenler hala oluşturucu ve blok üreticisi olarak hareket ediyor (ancak Astria'nın durumunda işlemleri gerçekleştirmiyorlar). Astria ayrıca en başından beri aktif olarak PBS'yi mimarisine dahil ediyor.

PBS protokolde yerleşik değilse, PBS'yi uygulamanın birkaç yolu vardır (değişken derecelerde merkeziyetsizlik olsa da). SUAVE gibi ürünler, MEV-Boost gibi çevrimdışı modelleri kullanır veya Mekatek ve Skip tarafından oluşturulan Cosmos SDK modülleri gibi oluşturucu modülleri uygular.

Bu yöntemlerin hiçbirinin birbirini dışlamadığını belirtmekte fayda var. Birkaç farklı yöntem kullanma ve herkesin tercihini ifade etmesine izin verme esnekliğine sahipsiniz. Bu şekilde, bu boşlukları doldurmak için yarışan uygulayıcılara sahip olabilirsiniz. Daha fazla seçenek eklemek her zaman iyidir (ve modülerliğe olan inancımızla tutarlıdır). Yine de, farklı uygulamaların farklı ödünleşimleri olacaktır. Örneğin, SUAVE gibi bir durumda, tamamen güvenilir bir merkezi PBS oluşturucuya güvenmek yerine, SGX veya Crypto teknolojisi aracılığıyla gizlilik koruması ekleyebilir ve gerçeğe Crypto ekonomik güvenliğini ekleyebilirsiniz. (Buradaki geri bildirimi için Jon Charbonneau'ya teşekkürler).

Oluşturucu zincirine dikey entegrasyon, kestirme yollara başvurmadan, gecikme eklemeden ve performansı düşürmeden adalet sağlar. Bu nedenle, oluşturucu zincirinin yüksek düzeyde optimize edilmesi gerekir ve pahalı ve güçlü donanım gerektirebilir (merkezileştirmeye yol açar). Bu, son kullanıcı doğrulaması almak için muhtemelen bir çeşit hafif düğüme ihtiyacımız olacağı (bunların tam düğümlere güvenmeleri gerekmesine rağmen) veya zincirin ve kullanıcıların teklif tercihlerinin doğru olduğuna dair kanıta sahip olmasını sağlamak için bir durum kanıtı türü kurulum kullanacağımız anlamına gelir. doldurulmuştur ve bloklar doğru Yapıdır.

Bunun gibi bir zincir, durumu çok ağır olabilir (bundan kaçınmak istiyoruz), ancak bu durum ağır işlemlere akıllı sözleşmeler aracılığıyla öncelik verilecektir. Öncelikli teklif durumunda, teklifler tercihe bağlı olarak genellikle yalnızca kısa bir süre için geçerli olduğundan, ya doldurulur ya da doldurulmaz (kısa bir süre için). Bu, teklifler için çok verimli (ve erken) durum son kullanma tarihi uygulayabileceğimiz anlamına gelir - bu da verileri budamamıza ve zinciri "temiz" tutmamıza olanak tanır. Bu sona erme tarihinin, önce tekliflerin doldurulmasına izin verecek kadar uzun olması gerekir, ancak çok fazla düşürmek, ileriye dönük blok uzay vadeli işlemlerine ulaşmayı neredeyse imkansız hale getirir. Sonsuza dek var olmaları gerekmediğinden (uygulamaların aksine) süresi dolmuş teklif sözleşmelerini güncellememiz ve almamız gerekmez - bu, teklifler doldurulduğunda durum/depolama kanıtları sağlayarak veya DAS depolama çözümleri (önerilenler gibi) ile yapılabilir. Joachim Neu çözümü) daha "güvenli" ve güvenilir hale getirmek için.

Daha önce belirtildiği gibi, SUAVE'nin "özgünlüğünü" doğrulama ihtiyacı, platformun "jusha"sı (ileri düzey kullanıcılar) ile sınırlı olabilir, çünkü SUAVE'nin çoğu kullanıcısı ve müşterisi bundan yüksek ekonomik faydalar elde edebilir. Bu, insanların yalnızca doğrulamak istiyorlarsa tam düğümleri çalıştırmasına izin vermemize neden olabilir - ancak bu, insanların büyük çoğunluğunu hariç tutar (doğrulamalarına gerek olmadığını söyleyebilirsiniz). Bu (bize göre) durum kanıtları veya hafif müşteri dostu uygulamalar aracılığıyla "güvenilir olmayan" SUAVE doğrulamasını uygulamayı tercih ettiğimiz Crypto'nun tam tersidir.

Bunun gerekli olmasının nedeni, teklif önceliğinizin doğru bir şekilde doldurulduğunu ve ödeme yaparken bloğun doğru bilgilerle doldurulduğunu doğrulamak istemenizdir (yeniden gruplama ve diğer hataları önlemek için). Bu esasen bir kehanet problemidir - aslında bir durum ispatı ile çözülebilir (tüm SUAVE'lerde olduğu gibi). Ancak bu durum ispatları, zincirleri geçerken başka bir sorunu gündeme getiriyor, bu bilgi zincirler arasında kurcalanmamış veya gizlenmemiş bir şekilde nasıl aktarılacak? Bu, güçlü bir ekonomik kesinlikten (Lagrangian tarafından önerilen gibi) geçmeyi gerektirebilir; bu durumda, zincirin kesinliğini ve gerçekliğini kanıtlamak için EigenLayr'ın yeniden değerlendirme doğrulayıcılarını kullanabilirsiniz ve çok Güçlü ekonomik kısıtlamalara sahip olursunuz. Bu, daha sonra başka bir sorunu gündeme getirir (örneğin, ihale sözleşmesi, "oracle makinesinin" - bu durumda yeniden taahhüt edenin - taahhüt edilen Token'ı belirlediğini ve ekonomik bağlayıcılık sağladığını şart koşuyor - ancak bunu Dış kesme arasında nasıl bir fikir birliğine varabiliriz? kesme kriterleri yazabilirsiniz, bu fikir birliği içinde değil, bu da sosyal kesmenin akıllı sözleşmeler yoluyla kullanılacağı anlamına gelir (ki bu neredeyse hiçbir zaman "adil" değildir ve sorunlara neden olabilir. Bu şu anda EigenLayr'da geçerli Forfaiting ile ilgili en büyük sorunlardan biri .

Peki, bu bizi nereye bırakıyor? Muhtemelen, biz fikir birliğinin ötesinde zincir üzerinde "güvenilmez" kesme yapana kadar SUAVE gibi zincirler, teklif tercihlerini kanıtlamak ve blok kesinliği oluşturmak için kendi fikir birliği algoritmalarına ve Kriptoekonomik güvenliğe ihtiyaç duyabilir— Ancak bu, daha fazla kriptoekonomik saldırı vektörü eklemek anlamına gelir; yapı taşlarının değeri, kendi kripto ekonomik güvenliğinden çok daha yüksektir.

Ek olarak, SUAVE tipi zincirlerde ve etki alanları arası MEV'lerde hala çok fazla tasarım alanı var.İşte bazı olası araştırma yönleri:

• Amaç eşleştirme ve niyet tabanlı sistemler
• Çok varlıklı ticarette dışbükey optimizasyon
• ADSL
• MEV yeniden tahsisi
• Gecikmeli savaş
• Tek bir oyuncu grubuyla ölçeklendirme sorunu, ancak birden çok Toplama durumu makinesi için oluşturulması gerekiyor
• Tercih ifadesi

Tercih ifadesiyle ilgili olarak, EVM'de bir akıllı sözleşme ile etkileşim kurmak için yürütme talimatını içeren konuşlandırılmış kodun adresindeki belirli bir işleve bir sözleşme çağrısı (mesaj) göndermek gerekir. Kullanıcılar girdi sağlarken, olası durum bilgisi nedeniyle çıktı üzerinde kontrole sahip olmayabilirler.

Bunun aksine, tercih ifadesi tasarım sistemleri (SUAVE ve Anoma gibi) yalnızca kullanıcıların tercihleri bir teminatla imzalamasını gerektirir; bu, araştırmacının tercihleri karşılanırsa oluşturuculara ve blok üreticilerine ödenir. MEV araştırıcıları ve oluşturucuları için işlem dizileri gibi karmaşık kombinatoryal mantık için farklı dillerin ve sanal makinelerin uygulanması gerekebilir. Bu, özellikle Anoma mimarisi olmak üzere son zamanlarda çok ilgi gören yeni bir tasarım alanıdır. Ayrıca, bu kısa makaleyi şiddetle tavsiye ediyoruz.