Toplamaların kullanımı arttıkça ve ekosistemin uygulamalarını barındırdıkça, kullanıcılar için geçiş maliyetleri artacak ve merkezi sipariş verenler fiyatlandırma üzerinde tekelci bir etki kazanacak. Merkezi sipariş verenlerin denetleyicileri, kullanıcılardan hem doğrudan (ör. ücretler yoluyla) hem de dolaylı olarak (ör. önde çalışan işlemler, sandviç saldırıları vb. yoluyla) değer çıkarımını (MEV) en üst düzeye çıkarmakta haklıdır. — Espresso
Espresso ekibinin belirttiği gibi, merkezileştirilmiş Toplamalar eninde sonunda tekel fiyatlandırması ve MEV sorunlarıyla karşı karşıya kalacak. Ek olarak, merkezileştirilmiş Toplamalar doğal olarak şekillendirilebilirliği bozarak parçalanmış Toplamalara yol açar. **
Bununla birlikte, merkezi olmayan, izinsiz ve ölçeklenebilir bir Toplama oluşturmak son derece zor olduğundan, neredeyse tüm mevcut Toplamalar hala merkezileştirilmiştir. Diğer bir neden de, önce merkezileştirilmiş Toplamaların başlatılmasının ekosistemi geliştirmeye ve pazar payını kapmaya yardımcı olabilmesidir.
Ve merkezi olmayan Toplamaları, özellikle zkRollupları tartıştığımızda, iki düzeyde merkezileşme vardır. Birincisi, kanıtlayıcının ademi merkeziyetçiliği ve ikincisi, emir verenin ademi merkeziyetçiliğidir. Tam merkeziyetçilikten uzaklaşmak için siparişi veren ile ispatlayan arasındaki koordinasyon problemini çözmek de gereklidir.
Modülerleştirme eğilimi altında, şu anda merkezi olmayan Toplama'da üç ana katılımcı türü vardır. İlk kategori, tamamen merkezi olmayan Toplamalar elde etmeyi amaçlar ve eksiksiz bir çözüm önerir. İkinci kategori, kanıtlayıcı ağları çözmek için tasarlanmış protokollerdir. Son olarak, ayıklayıcıyı dağıtmak için çalışan çok sayıda çözüm var.
Toplamalar merkezi değil
zkRollups'ta, Polygon ve Starknet, Rollup'larını dağıtmak için çözümler buldu.
Çokgen
POE'nin (Verimlilik Kanıtı) kullanıma sunulmasından önce, Polygon zkEVM, POD'u (Bağış Kanıtı) benimsedi ve sıralayıcının bir sonraki toplu işlemi oluşturma fırsatı için teklif vermesini sağladı. Ancak bu, tek bir kötü niyetli tarafın en yüksek teklifi vererek tüm ağı kontrol edebilmesi sorununu yaratır.
POE'yi benimsedikten sonra, sipariş veren ve onaylayan, kendi donanım koşulları altında izinsiz ağa en verimli şekilde katılacaktır. Ekonomik açıdan mantıklı olduğu sürece herkes Polygon zkEVM'ye katılabilir.
Polygon zkEVM'de sıralayıcı, 16 GB RAM ve 4 çekirdekli bir CPU gerektirirken, prover, 1 TB RAM ve 128 çekirdekli bir CPU gerektirir. Ek olarak, L1 verilerini toplamaktan, kanıtlayıcıya göndermekten, kanıtı almaktan ve L1'e sunmaktan sorumlu toplayıcı adı verilen bir rol vardır. Toplayıcı ile kanıtlayıcıyı aynı konu olarak kabul edebiliriz, çünkü toplayıcı ile kanıtlayıcı arasındaki ilişki çok basittir ve toplayıcı, kanıtlayıcıya kanıtı üretmesi için ödeme yapar.
Bu mimari çok basittir: herhangi bir sipariş veren, işlemleri izinsiz olarak L1'deki önceki duruma göre paketleyebilir ve ilgili durumu güncelleyebilir. Aynı zamanda, herhangi bir toplayıcı, güncellenen durumu doğrulamak için bir kanıt sunabilir.
POE'de verimlilik, yalnızca birbirleriyle rekabet eden katılımcıların ağ verimliliğini değil, aynı zamanda sıralayıcının ekonomik verimliliğini ve kendini kanıtlamasını ifade eder. L2'de, sipariş veren ve kanıtlayıcı işlem ücretini paylaşır ve sipariş veren, kanıtı oluşturmak için toplayıcıya parti ücretini öder. Bu, katılımcıların ağ verimliliğine katkıda bulunmak için ekonomik olarak motive olmalarını sağlayarak daha sağlam ve sürdürülebilir bir ekosistemle sonuçlanır.
sıralayıcı
Gelir: L2 işlem ücretleri
Maliyet: toplu Ücret ($MATIC cinsinden hesaplanmıştır) + L1 işlem ücreti (sıralamaBatches yöntemini çağırın)
Toplayıcı (Prover)
Gelir: BatchFee ($MATIC cinsinden hesaplanır)
Maliyet: kanıtlama maliyeti + L1 işlem ücreti (verifyBatchesTrustedAggregator yöntemini çağırın)
Koordinatör: BatchFee
başlangıç parametreleri
partiÜcreti= 1 $MATIC
veryBatchTimeTarget = 30 dakika. Bu, doğrulama grubu için hedef zamandır. Protokol, bu hedef süreye ulaşmak için batchFee değişkenini güncelleyecektir.
çarpanBatchFee = 1002. Bu, 3 ondalık basamaklı, 1000 ila 1024 arasında değişen toplu ücret çarpanıdır.
Regülatör
diffBatches : toplu parti sayısı > 30 dakika eksi parti sayısı <= 30 dakika. Maksimum değer 12'dir.
Koordinasyon süreci
diffBatches > 0 olduğunda toplayıcıları teşvik etmek için toplama ödülünü artırın.
diffBatches < 0 olduğunda, toplayıcıyı bastırmak ve toplama sürecini yavaşlatmak için toplama ödülünü azaltın.
Starknet
Starknet ayrıca hızlı onay, izin gerektirmeyen ve ölçeklenebilir bir Toplama oluşturmayı hedefliyor. Merkezi olmayan çözüm için nihai spesifikasyona henüz ulaşılmamış olsa da, birkaç ay önce forumda bazı taslaklar yayınladılar.
Polygon zkEVM'nin basit mekanizmasıyla karşılaştırıldığında, Starknet'in planı daha karmaşıktır çünkü kanıt ağında L2 mutabakatı ve zincirleme protokol kanıtını içerir.
sıralayıcı
Starknet, sipariş veren katmanına basitçe bir mutabakat katmanı eklemek yerine, ikili bir defter mutabakat protokolü önerir. Bu protokolde L2 canlı protokol olarak hızlı yanıt verirken, L1 kontrol noktaları güvenli protokol olarak nihai doğrulama sağlar.
L2'nin canlı protokolü için, Tendermint veya DAG'ler gibi Sybil'e dayanıklı PoS sistemleri gibi çeşitli mutabakat mekanizmaları benimsenebilir. Öte yandan, L1'in güvenli protokolü, sırasıyla Hisse yönetimi, kanıt doğrulaması ve durum güncellemesini işleyen birden fazla sözleşmeyi içerir.
İkili defter mutabakat anlaşmasının tipik iş akışı aşağıdaki gibidir:
İlk olarak, kontrol edilmiş bir canlı defter oluşturmak için L2 canlı defterin çıktısını L1 güvenli defterin girişi olarak kullanın.
Ardından, kontrol edilen canlı defteri girdi olarak alın ve kontrol edilen canlı defterin her zaman canlı defterin öneki olmasını sağlamak için L2'nin saf mutabakat protokolüne tekrar girin.
Yukarıdaki işlemi tekrarlayın.
Çift defterli bir mutabakat protokolü oluştururken, maliyet ve gecikme arasında bir denge vardır. İdeal çözüm, hem düşük maliyetli hem de hızlı nihai onay almayı amaçlar.
Starknet, L2'deki gaz maliyetlerini azaltmak için kontrol noktalarını "dakika seviyesi" ve "saat seviyesi" olarak ayırır. "Dakika düzeyindeki" kontrol noktaları için, yalnızca durumun kendisi zincire bağlanırken, verilerin geri kalanı (geçerlilik kanıtları, veri kullanılabilirliği vb.) StarkNet L2 ağı üzerinden gönderilir. Bu veriler, StarkNet tam düğümleri tarafından saklanır ve doğrulanır. Öte yandan, "saatlik" kontrol noktaları L1'de genel olarak doğrulanır. Her iki kontrol noktası türü de aynı nihai onayı sağlar. "Dakika düzeyinde" kontrol noktaları için geçerlilik kanıtı, StarkNet tam düğümleri tarafından doğrulanır ve "dakika düzeyinde" kontrol noktalarına L1 kesinliği vermek için L1'deki herhangi bir düğüm tarafından verilebilir. Bu nedenle, kanıtlayıcının L2 ağında geniş çapta dağıtılması için küçük kanıtlar üretmesi gerekir.
Gecikmeyi daha da azaltmak için Starknet, lideri önceden belirlemek için bir lider seçim protokolü önerir. Temel mantık şu şekildedir: mevcut i döneminin lideri, stake edilen L1 miktarına ve biraz rastgeleliğe dayalı olarak önceden belirlenir. Spesifik olarak, epoch i-2'de, lider_seçim yöntemi, epoch i-3'teki taahhütlerin miktarına dayalı olarak sıralayıcıları sözlüksel olarak sıralar. Ardından, nonce'yi güncellemek ve rastgele bir nokta seçmek için bir işlem gönderin. Noktanın düştüğü konuma karşılık gelen sıralayıcı, epoch i'nin lideri olacaktır.
Onaylayıcı
POE modülü altında, katılımcılar arasında kazananın her şeyi aldığı durumuna yol açabilen açık bir rekabet vardır. Starknet, merkezileşme riski olmayan bir rekabet mekanizması sağlamaya çalışır. İşte birkaç seçenek:
Döndürme: Bu, merkezileştirme sorununu kısmen çözebilir, ancak işi kanıtlayacak en iyi kişiyi bulmak için teşvik sağlamayabilir.
Bahis bazlı: Sıralayıcı, bahis miktarına göre kanıtlayıcı olarak seçilme olasılığını belirler.
Taahhüt-Açıklama şeması: İlk taahhüdün kısa bir tekel fırsatı elde etmek için belirteçleri taahhüt etmesi ve ardından bu zaman penceresi içinde kanıtlar üretmesi gerekir. DDoS saldırılarından kaçınmak için, ilki zamanında kanıt üretemezse, ikincisinin ihtiyaç duyduğu teminat belirteçleri katlanarak artacaktır. Bu mekanizma altında ağ, en iyi performansa sahip makineyi kaybedebilir, ancak daha fazla ispatlayıcı yetiştirilebilir.
Protestocular arasındaki rekabete ek olarak, ağa daha fazla provacının katılabilmesi için giriş engeli düşürülmelidir. Starknet, zincirleme protokol kanıtları adı verilen özyinelemeli kanıtları kullanan karmaşık bir protokol önerir.
Zincir kanıtı protokollerinde, blok zincirinin kendisi birkaç farklı çatala bölünmüştür. Bu şekilde ispatlar sadece özyinelemeli olamaz, aynı zamanda ispat üretimi de eşzamanlı olabilir. Örneğin, 3 dallı bir düzende, 12 siyah blok, her sıra bir dalı temsil edecek şekilde 3 sıraya bölünmüştür. Her dalı, her bloğun bir önceki bloğa kanıtlaması gereken bir alt zincir olarak düşünebiliriz. Tüm zincirin bakış açısından, yuva n'nin yuva n-3'ü kanıtlaması gerekir. 3 blok aralığı, sipariş verenin provaları önceden hesaplaması ve satın alması için yeterli zamanı sağlar. Bu, bir saldırganın tüm provers ağını kontrol etmek için yalnızca bir dalı kontrol etmesi gereken parçalamaya biraz benzer.
Bu dalları bir araya getirmek için Starknet, işlemlerin meşruiyetini ortaklaşa doğrulamak ve işlem kayıtlarının tutarlılığını ve güvenilirliğini sağlamak için birden fazla düğümü birleştirebilen bir dokuma teknolojisi önermektedir.
Çözümlerden biri, her yuvanın aynı anda birkaç şubeyle birleştirilmesini zorunlu kılmaktır. Başka bir çözüm, her şubeyi dönüşümlü olarak diğer şubelerle birleştirmeyi denemek ve böylece kanıtlama iş yükünü azaltmaktır. Tabii ki bu da açık bir sorun ve gelecekte daha iyi çözümler olabilir.
Koordinasyon
Starknet, kanıtlayıcının yeterli kar alanına sahip olmasını etkin bir şekilde sağlamak için, EIP1559 şemasına başvurmak için bir yöntem önerir: taban ücreti, kanıtlayıcının kaynak fiyatının alt sınırı olarak belirleyin, aktif olarak fiyat keşfi yapın ve sıralayıcı ipuçlarını kullanabilir kanıtlayıcıyı motive etmek için. Bu şekilde, kanıtlayıcıya her zaman fazla ödeme yapılır ve yalnızca aşırı durumlar kanıt sürecini etkiler. Aksi takdirde, kanıtlayıcıya piyasa fiyatına yakın bir ödeme yapılırsa, hafif bir dalgalanma, kanıtlayıcının lokavtını tetikleyebilir.
Sertifika Merkezinden Ayrılma
Toplamalar açısından bakıldığında, kanıtlayıcının ademi merkeziyetçiliği elde etmesi, sıralayıcıya göre daha kolaydır. Ayrıca, mevcut kanıtlayıcı bir performans darboğazıdır ve sıralayıcının gruplama hızına ayak uydurması gerekir. Ayıklayıcının merkezden dağıtılması sorunu çözülmediğinde, merkezi olmayan kanıtlayıcı, merkezi sıralayıcı için de hizmet sağlayabilir.
Aslında, yalnızca Rollup'lar değil, zkBridge ve zkOracle da bir doğrulama ağına ihtiyaç duyar. Hepsi, güçlü bir dağıtılmış kanıtlama ağı gerektirir.
Uzun vadede, farklı bilgi işlem gücünü barındırabilen bir kanıtlayıcı ağ daha sürdürülebilirdir, aksi takdirde en iyi performans gösteren makineler piyasayı tekelleştirecektir.
Kanıt Pazarı
Bazı protokoller, sıralayıcı ve kanıtlayıcı arasındaki ilişkiyi koordine etmez, ancak koordinasyonu doğrudan bir kanıt pazarına soyutlar. Bu piyasada ispatlar ticari maldır, ispatlayıcılar ispatın üreticisidir ve protokoller ispatın tüketicisidir. Piyasa dengesi en çok "görünmez el"in etkisi altında etkindir.
Bana ait
Mina, Snark kanıtlarının alınıp satıldığı Snarketplace adlı bir kanıt pazarı kurdu. Buradaki en küçük birim, tek bir işlemin Snark kanıtıdır. Mina, Tarama Durumu adı verilen özyinelemeli bir durum ağacı kanıtı kullanır.
Tarama Durumu, her işlemin bir düğüm olduğu bir ikili ağaç ormanıdır. Ağacın tepesinde, ağaçtaki tüm işlemleri kanıtlayabilen tek bir kanıt oluşturulur. Kanıtlayıcının iki görevi vardır: Birincisi kanıtları üretmek, ikincisi ise kanıtları birleştirmek.
Prover işi tamamlayıp teklifini verdikten sonra Mina protokolünün blok üreticisi en düşük fiyatla teklif vereni seçecektir. Bu aynı zamanda denge fiyatıdır, çünkü teklif sahipleri kanıt maliyetinin üzerinde teklif vereceklerdir ve blok üreticileri paraya değmeyen kanıtları satın almayacaktır.
=Yok; Temel
Mina'nın kanıt pazarı kendi protokolü için tasarlanırken, =nil; Foundation tüm pazara hizmet verecek genel bir kanıt pazarı önerir.
Pazar hizmeti üç bileşenden oluşur: DROP DATABASE, zkLLVM ve Proof Market.
DROP DATABASE: DA katmanı olarak kabul edilebilecek bir veritabanı yönetim sistemi protokolüdür.
Proof Market: DROP DATABASE üzerinde çalışan, bazılarının zk geçirmez "merkezi olmayan borsa" dediği şeye benzer bir uygulamadır.
zkLLVM: Üst düzey programlama dillerini kanıtlanabilir bilgi işlem protokolleri için girdilere dönüştüren bir derleyicidir.
Her kanıt, farklı girişlerinden ve devrelerinden oluşur, dolayısıyla her kanıt benzersizdir. Bir devre, bir "işlem çiftinin" finansal terimlerle nasıl tanımlandığına benzer şekilde bir kanıt türü tanımlar. Ek olarak, farklı prova sistemleri daha fazla devre sunar.
İş akışı şu şekildedir: Kanıtın talep tarafı, yüksek seviyeli bir programlama dilinde kod yazabilir, ardından onu araç zinciri aracılığıyla =nil;zkLLVM'ye besleyerek piyasada benzersiz bir ticaret çifti haline gelecek tek bir devre oluşturabilir.
Kanıtlayıcı talep tarafı için, maliyet ve zaman arasında bir değiş tokuş yapabilirler. Provers ayrıca bilgi işlem güçlerini ve gelirlerini de dikkate alacaktır. Bu nedenle, piyasada farklı bilgi işlem gücü olacak, yüksek işlem gücü kanıtları daha hızlı, ancak daha yüksek maliyetle üretecek, düşük işlem gücü ise kanıtları daha yavaş ama daha ucuza üretecek.
İKİ ADIMLI TAAHHÜT
Son zamanlarda Opside, kanıtlayıcı ağını dağıtmak için iki adımlı bir taahhüt planı önerdi. Şema, en hızlı kanıtlayanın her zaman kazandığı durumdan kaçınmak için kanıt sunumunu iki aşamaya ayırır.
Adım: T-th bloğunun sıfır bilgi kanıtının karmasını gönderin
T+11 bloğundan itibaren, yeni kanıtlayıcıların artık hash göndermesine izin verilmemektedir.
Adım: Sıfır bilgi kanıtı gönderin
T+11. bloktan sonra, herhangi bir kanıtlayıcı sıfır bilgi kanıtı sunabilir. En az bir sıfır bilgi kanıtı doğrulamayı geçerse, gönderilen tüm sağlamaları doğrulamak için kullanılacak ve doğrulanan kanıtlayıcı, ipotek tutarıyla orantılı olarak karşılık gelen PoW ödüllerini alacaktır.
T+20. bloktan önce hiçbir sıfır bilgi kanıtı doğrulanmazsa, hash gönderen tüm kanıtlayıcılar cezalandırılacaktır. Ardından sıralayıcıyı yeniden açın, yeni bir hash gönderebilir, 1. adıma geri dönebilirsiniz.
Bu yöntem, farklı bilgi işlem gücünü barındırabilir. Bununla birlikte, gerekli teminat hala bir düzeyde merkezileşme getirmektedir.
Sıralayıcı Ademi Merkeziyetçilik
Sipariş verenlerin ademi merkeziyetçiliği, doğrulayıcılarınkinden daha karmaşıktır. Bunun nedeni, sıralayıcının işlemleri paketleme ve düzenleme gücüne sahip olmasıdır ve MEV ve gelir dağılımı gibi konuların dikkate alınması gerekir.
Ethereum'un duyarlılığa göre canlılığa öncelik vereceği göz önüne alındığında, L2 çözümleri, canlılığa göre yanıt vermeye öncelik vererek bu değiş tokuşu tamamlamalıdır. Bununla birlikte, merkezileştirilmiş ayrıştırıcılarla karşılaştırıldığında, merkezi olmayan ayrıştırıcılar doğal olarak yanıt verebilirlik açısından fedakarlık yapar. Bu nedenle, bu ikilemi çözmek için çeşitli optimizasyonların uygulanması gerekir.
Şu anda, üç farklı merkezi olmayan ayrıştırıcı önerisi var. İlk çözüm, mutabakat mekanizması optimize edilerek gerçekleştirilir. İkinci şema, paylaşılan sıralayıcılardan oluşan bir ağı içerir. Üçüncü şema, L1 doğrulayıcılarına dayanmaktadır.
uzlaşma
Mutabakat protokolü, işlemleri yürütmekten değil, sipariş vermekten ve bunların kullanılabilirliğini sağlamaktan birincil derecede sorumludur. Ancak, daha önce de belirtildiği gibi doğrudan başka bir mutabakat katmanı eklemek kolay bir çözüm değildir.
Yanıt verebilirliği iyileştirmek için yaygın bir yaklaşım, daha küçük bir doğrulayıcı grubuna güvenmektir. Örneğin, Algorand ve Polkadot toplu işlemler için rastgele örneklenmiş daha küçük komiteler kullanır. Tüm düğümler, bahis miktarlarıyla orantılı olarak belirli bir süre içinde bir komiteye dahil olma olasılığı ile rastgele işaretçiler ve doğrulanabilir bir rastgele işlev (VRF) kullanır.
Ağ trafiğini azaltmak için daha küçük Veri Kullanılabilirliği (DA) komiteleri kullanılabilir. Veya VID (Doğrulanabilir Bilgi Dağılımı) kullanın. VID, verilerin silme kodunu mutabakata katılan tüm düğümlere dağıtır, böylece yeterince yüksek taahhüt oranına sahip herhangi bir düğüm alt kümesi, verileri geri yüklemek için işbirliği yapabilir. Bu yaklaşımın takası, yayın karmaşıklığını azaltmak, ancak veri kurtarmanın karmaşıklığını artırmaktır.
Arbitrum, sıralayıcı komiteye katılmak üzere ConsenSys, Ethereum Foundation, L2BEAT, Mycelium, Offchain Labs, P2P, Quicknode, IFF'nin Distributed Ledger Research Center (DLRC) ve Unit 410 gibi saygın varlıkları doğrulayıcı setini oluşturmak üzere seçti. Bu yaklaşımdaki takas, ademi merkeziyetçiliğin kalitesini iyileştirerek nicelik eksikliğini telafi etmektir.
Paylaşılan Sıralayıcı Ağı
Sıralayıcılar, modüler blok zincirlerinde, özellikle Toplamalarda hayati bir rol oynar. Her Toplama, genellikle kendi sıralayıcı ağını oluşturur. Ancak, bu yaklaşım sadece artıklık sorunları yaratmakla kalmaz, aynı zamanda şekillendirilebilirliği de engeller. Bu sorunu çözmek için, bazı protokoller paylaşılan bir Toplama sıralayıcı ağı oluşturmayı önerir. Bu yaklaşım, kullanıcıların ve geliştiricilerin açık, izinsiz blok zincirlerinde umutsuzca ihtiyaç duyduğu özellikler olan atomiklik, birleştirilebilirlik ve birlikte çalışabilirlik elde etmenin karmaşıklığını azaltır. Ek olarak, sipariş veren ağ için ayrı bir hafif istemci ihtiyacını da ortadan kaldırır.
Astrya
Astria, Celestia'nın kendi dağıtılmış sipariş sağlayıcı koleksiyonunu içeren Rollup ekosistemi için bir ara yazılım blok zinciri geliştiriyor. Bu sipariş verenler grubu, birden çok Toplamadan gelen işlemleri kabul etmekten ve bunları yürütmeden temel katmana yazmaktan sorumludur.
Astria'nın rolü, temel olarak işlem sıralamasına odaklanır ve temel katman ile Toplama'dan bağımsız olarak çalışır. İşlem verileri temel katmanda (örn. Celestia) depolanırken, Toplama tam düğümleri durumu korur ve işlemleri yürütür. Bu, Astria'nın Toplama'dan ayrılmasını sağlar.
Son olarak, Astria iki düzeyde Taahhüt sağlar:
"Yumuşak taahhüt": Rollup'ın son kullanıcılarına hızlı blok onayları sağlamasını sağlar.
"Kesin taahhüt": Hız, temel katmanla aynıdır, daha yüksek güvenlik ve kesinlik sağlar.
Espresso
Espresso, sıfır bilgi teknolojisi alanında önemli bir katkı sağlamıştır. En son geliştirmeleri, Optimistic Rollups ve zkRollups'a uygulanabilen merkezi olmayan sıralayıcılar için kapsamlı bir çözümdür.
Merkezi olmayan sipariş ağı şunlardan oluşur:
HotShot Konsensüsü: Dinamik kullanılabilirliğe göre yüksek iş hacmine ve hızlı kesinliğe öncelik verin.
Espresso DA: Yüksek bant genişliğine sahip düğümlerin verileri diğer tüm düğümlere beslediği komite tabanlı DA çözümü ile VID'yi birleştirir. Her bir bloğun mevcudiyeti, rastgele seçilmiş küçük bir komite tarafından da desteklenir. VID'ler güvenilir ancak daha yavaş bir yedekleme sağlar ve tüm düğümlerin yeterince yüksek stake edilen ağırlık yüzdesinden ödün verilmediği sürece kullanılabilirliği garanti eder.
Toplama REST API'si: JSON-RPC ile uyumlu Ethereum.
Sıralayıcı sözleşmesi: HotShot mutabakatını doğrulayın (yani, hafif bir istemci olarak hareket edin) ve kontrol noktalarını kaydedin (yani, işleme kriptografik bir taahhütte bulunun) ve HotShot'ın taahhüt tablosunu yönetin.
P2P ağı: Dedikodu protokolü.
Astria ile karşılaştırıldığında, Espresso DA sunar. Bu nedenle, iş akışı aşağıdaki gibi biraz farklı olacaktır:
Kullanıcı, bir işlem oluşturur ve Toplama'ya gönderir.
İşlem, sipariş veren ağı aracılığıyla yayılır ve mempool'da tutulur.
HotShot taahhüt mekanizması aracılığıyla bir lider belirleyin, bir blok önerin ve bunu Rollup'ın yürütücülerine ve doğrulayıcılarına geri gönderin.
Lider, işlemi Veri Kullanılabilirliği Komitesine gönderir ve geri bildirim olarak bir DA sertifikası alır.
Lider ayrıca, sözleşmenin bloğu doğrulamak için kullandığı sertifikayla birlikte Katman 1 Sıralayıcı sözleşmesine bloğa bir taahhüt gönderir.
Espresso, daha esnek bir kullanıcı deneyimi sağlamak için provalar için Gossip protokolünü sunar. İşlem kesinliği için üç seçenek sunar:
Hızlı: Kullanıcılar, işlemi yürüten ve kanıtı oluşturan Toplama sunucusuna güvenebilir veya işlemi gerçekleştirmek için HotShot'ın düşük gecikme süresinden yararlanabilir.
Orta: Kullanıcı, kanıtın oluşturulması için bir süre bekleyip ardından kontrol edebilir.
Yavaş: Kullanıcılar, herhangi bir güven varsayımı veya hesaplaması olmadan güncellenmiş durumu almak için L1 onaylı durum güncellemelerini bekleyebilir.
Yukarıdaki optimizasyonlara ek olarak Espresso, tüm Ethereum doğrulayıcı setinin Espresso sipariş protokolünü çalıştırmaya katılmasını da planlıyor. Aynı doğrulayıcı setini kullanmak benzer bir güvenlik sağlayacak ve L1 doğrulayıcılarıyla değer paylaşmak daha güvenli olacaktır. Ayrıca Espresso, EigenLayer tarafından sağlanan ETH yeniden staking çözümünden de yararlanabilir.
Yarıçap
Radius, L2'deki MEV problemini çözmeye odaklanan, sıfır bilgi kanıtlarına dayalı, güvene dayalı olmayan bir paylaşımlı sıralama katmanı inşa ediyor çünkü L2'nin geliri esas olarak blok alanından geliyor. Dikkate alınması gereken denge, MEV ve L2 geliri arasındaki dengedir. Radius'un amacı, kullanıcılar için zararlı olan MEV'i ortadan kaldırmak ve iki katmanlı bir hizmet önermektedir.
Üst katman, normal kullanıcı işlemlerini hedefler ve zaman kilitli bulmacaların kullanımı yoluyla istenmeyen MEV'ye karşı kriptografik koruma sağlar. Spesifik olarak, RSA tabanlı zaman kilidi bulmacaları için 5 saniye içinde sıfır bilgi kanıtları üretecek olan Pratik Doğrulanabilir Gecikmeli Şifreleme (PVDE) teknolojisini kullanır. Bu yöntem, kullanıcıları zararlı MEV'lerden korumak için pratik bir çözüm sunar. Kısacası, sıralayıcı işlemlerin sırasını belirleyene kadar işlem içeriği bilinemez.
Altta yatan katman, blok oluşturucular için tasarlanmıştır ve MEV'nin olumsuz etkisini azaltırken onların gelir getirici faaliyetlere katılmalarına izin verir.
Temel Toplamalar
Tabanlı Toplama, kısa bir süre önce Justin Drake tarafından önerilen bir kavramdır; burada L1 bloğu öneren kişiler, izinsiz olarak bir sonraki L1 bloğuna toplama blokları dahil etmek için L1 araştırmacıları ve inşaatçıları ile işbirliği yapar. L1'de paylaşılan sıralayıcılardan oluşan bir ağ olarak görüntülenebilir. Tabanlı Toplama'nın avantajları ve dezavantajları açıktır.
Olumlu tarafı, Tabanlı Toplama, L1 tarafından sağlanan canlılık ve dağıtıklığın avantajlarından yararlanır ve uygulanması basit ve verimlidir. Tabanlı Toplama, L1 ile ekonomik olarak da tutarlıdır. Ancak bu, Tabanlı Toplama'nın egemenliğinden ödün verdiği anlamına gelmez. MEV, L1'e devredilmiş olsa da, Tabanlı Toplama yine de yönetişim belirteçlerine sahip olabilir ve taban ücretler alabilir. Hipoteze dayanarak, Tabanlı Toplama bu avantajlardan yararlanabilir, hakimiyet sağlayabilir ve nihayetinde getirileri en üst düzeye çıkarabilir.
Sonuç olarak
Sunulan önerilere bakıldığında, Rollup'ın merkeziyetçilikten uzaklaştırılması için kat edilmesi gereken daha çok yol olduğu görülüyor. Bu tekliflerden bazıları hala taslak aşamasındadır ve daha fazla tartışma gerektirirken, diğerleri yalnızca ön şartnameleri tamamlamıştır. Tüm bu senaryoların uygulanması ve titizlikle test edilmesi gerekir.
Bazı Toplamalar, karşılık gelen bir merkezi olmayan çözümü açıkça önermese de, genellikle merkezi sipariş verenlerden kaynaklanan tek hata noktalarını ele almak için kaçış mekanizmaları içerirler. Örneğin zkSync, kullanıcıların paralarını doğrudan L1'den çekmelerine olanak tanıyan bir FullExit yöntemi sağlar. Sistem çıkış moduna girdiğinde ve yeni blokları işleyemediğinde, kullanıcı bir para çekme işlemi başlatabilir.
Sansüre karşı direnç elde etmek için, bu Toplamalar genellikle kullanıcıların işlemleri doğrudan L1'de göndermelerine de izin verir. Örneğin, zkSync, L1'de gönderilen bu tür işlemler için bir öncelik sırası kullanır. Benzer şekilde, Polygon zkEVM, L1 sözleşmesinde zorunlu toplu iş yöntemi içerir. Bir hafta içinde toplama olmadığında, kullanıcı L1'de bu yöntemi çağırabilir ve kanıtlayıcıya işlemin bayt dizisini ve bathFee'yi sağlayabilir.
Kesin olan bir şey var ki, öngörülebilir gelecekte, Rollup'ın ademi merkeziyetçiliği, yukarıda belirtilen önemli çözümleri veya diğer bazı yenilikçi varyantları içerebilecek birleşik bir çözüm olacaktır.
View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
Merkezi Olmayan Toplamaları Tek Bir Makalede Anlamak
Orijinal başlık: "Merkezi Olmayan Toplamalar"
Toplamaların kullanımı arttıkça ve ekosistemin uygulamalarını barındırdıkça, kullanıcılar için geçiş maliyetleri artacak ve merkezi sipariş verenler fiyatlandırma üzerinde tekelci bir etki kazanacak. Merkezi sipariş verenlerin denetleyicileri, kullanıcılardan hem doğrudan (ör. ücretler yoluyla) hem de dolaylı olarak (ör. önde çalışan işlemler, sandviç saldırıları vb. yoluyla) değer çıkarımını (MEV) en üst düzeye çıkarmakta haklıdır. — Espresso
Espresso ekibinin belirttiği gibi, merkezileştirilmiş Toplamalar eninde sonunda tekel fiyatlandırması ve MEV sorunlarıyla karşı karşıya kalacak. Ek olarak, merkezileştirilmiş Toplamalar doğal olarak şekillendirilebilirliği bozarak parçalanmış Toplamalara yol açar. **
Bununla birlikte, merkezi olmayan, izinsiz ve ölçeklenebilir bir Toplama oluşturmak son derece zor olduğundan, neredeyse tüm mevcut Toplamalar hala merkezileştirilmiştir. Diğer bir neden de, önce merkezileştirilmiş Toplamaların başlatılmasının ekosistemi geliştirmeye ve pazar payını kapmaya yardımcı olabilmesidir.
Ve merkezi olmayan Toplamaları, özellikle zkRollupları tartıştığımızda, iki düzeyde merkezileşme vardır. Birincisi, kanıtlayıcının ademi merkeziyetçiliği ve ikincisi, emir verenin ademi merkeziyetçiliğidir. Tam merkeziyetçilikten uzaklaşmak için siparişi veren ile ispatlayan arasındaki koordinasyon problemini çözmek de gereklidir.
Modülerleştirme eğilimi altında, şu anda merkezi olmayan Toplama'da üç ana katılımcı türü vardır. İlk kategori, tamamen merkezi olmayan Toplamalar elde etmeyi amaçlar ve eksiksiz bir çözüm önerir. İkinci kategori, kanıtlayıcı ağları çözmek için tasarlanmış protokollerdir. Son olarak, ayıklayıcıyı dağıtmak için çalışan çok sayıda çözüm var.
Toplamalar merkezi değil
zkRollups'ta, Polygon ve Starknet, Rollup'larını dağıtmak için çözümler buldu.
Çokgen
POE'nin (Verimlilik Kanıtı) kullanıma sunulmasından önce, Polygon zkEVM, POD'u (Bağış Kanıtı) benimsedi ve sıralayıcının bir sonraki toplu işlemi oluşturma fırsatı için teklif vermesini sağladı. Ancak bu, tek bir kötü niyetli tarafın en yüksek teklifi vererek tüm ağı kontrol edebilmesi sorununu yaratır.
POE'yi benimsedikten sonra, sipariş veren ve onaylayan, kendi donanım koşulları altında izinsiz ağa en verimli şekilde katılacaktır. Ekonomik açıdan mantıklı olduğu sürece herkes Polygon zkEVM'ye katılabilir.
Polygon zkEVM'de sıralayıcı, 16 GB RAM ve 4 çekirdekli bir CPU gerektirirken, prover, 1 TB RAM ve 128 çekirdekli bir CPU gerektirir. Ek olarak, L1 verilerini toplamaktan, kanıtlayıcıya göndermekten, kanıtı almaktan ve L1'e sunmaktan sorumlu toplayıcı adı verilen bir rol vardır. Toplayıcı ile kanıtlayıcıyı aynı konu olarak kabul edebiliriz, çünkü toplayıcı ile kanıtlayıcı arasındaki ilişki çok basittir ve toplayıcı, kanıtlayıcıya kanıtı üretmesi için ödeme yapar.
Bu mimari çok basittir: herhangi bir sipariş veren, işlemleri izinsiz olarak L1'deki önceki duruma göre paketleyebilir ve ilgili durumu güncelleyebilir. Aynı zamanda, herhangi bir toplayıcı, güncellenen durumu doğrulamak için bir kanıt sunabilir.
POE'de verimlilik, yalnızca birbirleriyle rekabet eden katılımcıların ağ verimliliğini değil, aynı zamanda sıralayıcının ekonomik verimliliğini ve kendini kanıtlamasını ifade eder. L2'de, sipariş veren ve kanıtlayıcı işlem ücretini paylaşır ve sipariş veren, kanıtı oluşturmak için toplayıcıya parti ücretini öder. Bu, katılımcıların ağ verimliliğine katkıda bulunmak için ekonomik olarak motive olmalarını sağlayarak daha sağlam ve sürdürülebilir bir ekosistemle sonuçlanır.
sıralayıcı
Toplayıcı (Prover)
Koordinatör: BatchFee
Starknet
Starknet ayrıca hızlı onay, izin gerektirmeyen ve ölçeklenebilir bir Toplama oluşturmayı hedefliyor. Merkezi olmayan çözüm için nihai spesifikasyona henüz ulaşılmamış olsa da, birkaç ay önce forumda bazı taslaklar yayınladılar.
Polygon zkEVM'nin basit mekanizmasıyla karşılaştırıldığında, Starknet'in planı daha karmaşıktır çünkü kanıt ağında L2 mutabakatı ve zincirleme protokol kanıtını içerir.
sıralayıcı
Starknet, sipariş veren katmanına basitçe bir mutabakat katmanı eklemek yerine, ikili bir defter mutabakat protokolü önerir. Bu protokolde L2 canlı protokol olarak hızlı yanıt verirken, L1 kontrol noktaları güvenli protokol olarak nihai doğrulama sağlar.
L2'nin canlı protokolü için, Tendermint veya DAG'ler gibi Sybil'e dayanıklı PoS sistemleri gibi çeşitli mutabakat mekanizmaları benimsenebilir. Öte yandan, L1'in güvenli protokolü, sırasıyla Hisse yönetimi, kanıt doğrulaması ve durum güncellemesini işleyen birden fazla sözleşmeyi içerir.
İkili defter mutabakat anlaşmasının tipik iş akışı aşağıdaki gibidir:
İlk olarak, kontrol edilmiş bir canlı defter oluşturmak için L2 canlı defterin çıktısını L1 güvenli defterin girişi olarak kullanın.
Ardından, kontrol edilen canlı defteri girdi olarak alın ve kontrol edilen canlı defterin her zaman canlı defterin öneki olmasını sağlamak için L2'nin saf mutabakat protokolüne tekrar girin.
Yukarıdaki işlemi tekrarlayın.
Çift defterli bir mutabakat protokolü oluştururken, maliyet ve gecikme arasında bir denge vardır. İdeal çözüm, hem düşük maliyetli hem de hızlı nihai onay almayı amaçlar.
Starknet, L2'deki gaz maliyetlerini azaltmak için kontrol noktalarını "dakika seviyesi" ve "saat seviyesi" olarak ayırır. "Dakika düzeyindeki" kontrol noktaları için, yalnızca durumun kendisi zincire bağlanırken, verilerin geri kalanı (geçerlilik kanıtları, veri kullanılabilirliği vb.) StarkNet L2 ağı üzerinden gönderilir. Bu veriler, StarkNet tam düğümleri tarafından saklanır ve doğrulanır. Öte yandan, "saatlik" kontrol noktaları L1'de genel olarak doğrulanır. Her iki kontrol noktası türü de aynı nihai onayı sağlar. "Dakika düzeyinde" kontrol noktaları için geçerlilik kanıtı, StarkNet tam düğümleri tarafından doğrulanır ve "dakika düzeyinde" kontrol noktalarına L1 kesinliği vermek için L1'deki herhangi bir düğüm tarafından verilebilir. Bu nedenle, kanıtlayıcının L2 ağında geniş çapta dağıtılması için küçük kanıtlar üretmesi gerekir.
Gecikmeyi daha da azaltmak için Starknet, lideri önceden belirlemek için bir lider seçim protokolü önerir. Temel mantık şu şekildedir: mevcut i döneminin lideri, stake edilen L1 miktarına ve biraz rastgeleliğe dayalı olarak önceden belirlenir. Spesifik olarak, epoch i-2'de, lider_seçim yöntemi, epoch i-3'teki taahhütlerin miktarına dayalı olarak sıralayıcıları sözlüksel olarak sıralar. Ardından, nonce'yi güncellemek ve rastgele bir nokta seçmek için bir işlem gönderin. Noktanın düştüğü konuma karşılık gelen sıralayıcı, epoch i'nin lideri olacaktır.
Onaylayıcı
POE modülü altında, katılımcılar arasında kazananın her şeyi aldığı durumuna yol açabilen açık bir rekabet vardır. Starknet, merkezileşme riski olmayan bir rekabet mekanizması sağlamaya çalışır. İşte birkaç seçenek:
Protestocular arasındaki rekabete ek olarak, ağa daha fazla provacının katılabilmesi için giriş engeli düşürülmelidir. Starknet, zincirleme protokol kanıtları adı verilen özyinelemeli kanıtları kullanan karmaşık bir protokol önerir.
Zincir kanıtı protokollerinde, blok zincirinin kendisi birkaç farklı çatala bölünmüştür. Bu şekilde ispatlar sadece özyinelemeli olamaz, aynı zamanda ispat üretimi de eşzamanlı olabilir. Örneğin, 3 dallı bir düzende, 12 siyah blok, her sıra bir dalı temsil edecek şekilde 3 sıraya bölünmüştür. Her dalı, her bloğun bir önceki bloğa kanıtlaması gereken bir alt zincir olarak düşünebiliriz. Tüm zincirin bakış açısından, yuva n'nin yuva n-3'ü kanıtlaması gerekir. 3 blok aralığı, sipariş verenin provaları önceden hesaplaması ve satın alması için yeterli zamanı sağlar. Bu, bir saldırganın tüm provers ağını kontrol etmek için yalnızca bir dalı kontrol etmesi gereken parçalamaya biraz benzer.
Bu dalları bir araya getirmek için Starknet, işlemlerin meşruiyetini ortaklaşa doğrulamak ve işlem kayıtlarının tutarlılığını ve güvenilirliğini sağlamak için birden fazla düğümü birleştirebilen bir dokuma teknolojisi önermektedir.
Çözümlerden biri, her yuvanın aynı anda birkaç şubeyle birleştirilmesini zorunlu kılmaktır. Başka bir çözüm, her şubeyi dönüşümlü olarak diğer şubelerle birleştirmeyi denemek ve böylece kanıtlama iş yükünü azaltmaktır. Tabii ki bu da açık bir sorun ve gelecekte daha iyi çözümler olabilir.
Koordinasyon
Starknet, kanıtlayıcının yeterli kar alanına sahip olmasını etkin bir şekilde sağlamak için, EIP1559 şemasına başvurmak için bir yöntem önerir: taban ücreti, kanıtlayıcının kaynak fiyatının alt sınırı olarak belirleyin, aktif olarak fiyat keşfi yapın ve sıralayıcı ipuçlarını kullanabilir kanıtlayıcıyı motive etmek için. Bu şekilde, kanıtlayıcıya her zaman fazla ödeme yapılır ve yalnızca aşırı durumlar kanıt sürecini etkiler. Aksi takdirde, kanıtlayıcıya piyasa fiyatına yakın bir ödeme yapılırsa, hafif bir dalgalanma, kanıtlayıcının lokavtını tetikleyebilir.
Sertifika Merkezinden Ayrılma
Toplamalar açısından bakıldığında, kanıtlayıcının ademi merkeziyetçiliği elde etmesi, sıralayıcıya göre daha kolaydır. Ayrıca, mevcut kanıtlayıcı bir performans darboğazıdır ve sıralayıcının gruplama hızına ayak uydurması gerekir. Ayıklayıcının merkezden dağıtılması sorunu çözülmediğinde, merkezi olmayan kanıtlayıcı, merkezi sıralayıcı için de hizmet sağlayabilir.
Aslında, yalnızca Rollup'lar değil, zkBridge ve zkOracle da bir doğrulama ağına ihtiyaç duyar. Hepsi, güçlü bir dağıtılmış kanıtlama ağı gerektirir.
Uzun vadede, farklı bilgi işlem gücünü barındırabilen bir kanıtlayıcı ağ daha sürdürülebilirdir, aksi takdirde en iyi performans gösteren makineler piyasayı tekelleştirecektir.
Kanıt Pazarı
Bazı protokoller, sıralayıcı ve kanıtlayıcı arasındaki ilişkiyi koordine etmez, ancak koordinasyonu doğrudan bir kanıt pazarına soyutlar. Bu piyasada ispatlar ticari maldır, ispatlayıcılar ispatın üreticisidir ve protokoller ispatın tüketicisidir. Piyasa dengesi en çok "görünmez el"in etkisi altında etkindir.
Bana ait
Mina, Snark kanıtlarının alınıp satıldığı Snarketplace adlı bir kanıt pazarı kurdu. Buradaki en küçük birim, tek bir işlemin Snark kanıtıdır. Mina, Tarama Durumu adı verilen özyinelemeli bir durum ağacı kanıtı kullanır.
Tarama Durumu, her işlemin bir düğüm olduğu bir ikili ağaç ormanıdır. Ağacın tepesinde, ağaçtaki tüm işlemleri kanıtlayabilen tek bir kanıt oluşturulur. Kanıtlayıcının iki görevi vardır: Birincisi kanıtları üretmek, ikincisi ise kanıtları birleştirmek.
Prover işi tamamlayıp teklifini verdikten sonra Mina protokolünün blok üreticisi en düşük fiyatla teklif vereni seçecektir. Bu aynı zamanda denge fiyatıdır, çünkü teklif sahipleri kanıt maliyetinin üzerinde teklif vereceklerdir ve blok üreticileri paraya değmeyen kanıtları satın almayacaktır.
=Yok; Temel
Mina'nın kanıt pazarı kendi protokolü için tasarlanırken, =nil; Foundation tüm pazara hizmet verecek genel bir kanıt pazarı önerir.
Pazar hizmeti üç bileşenden oluşur: DROP DATABASE, zkLLVM ve Proof Market.
Her kanıt, farklı girişlerinden ve devrelerinden oluşur, dolayısıyla her kanıt benzersizdir. Bir devre, bir "işlem çiftinin" finansal terimlerle nasıl tanımlandığına benzer şekilde bir kanıt türü tanımlar. Ek olarak, farklı prova sistemleri daha fazla devre sunar.
İş akışı şu şekildedir: Kanıtın talep tarafı, yüksek seviyeli bir programlama dilinde kod yazabilir, ardından onu araç zinciri aracılığıyla =nil;zkLLVM'ye besleyerek piyasada benzersiz bir ticaret çifti haline gelecek tek bir devre oluşturabilir.
Kanıtlayıcı talep tarafı için, maliyet ve zaman arasında bir değiş tokuş yapabilirler. Provers ayrıca bilgi işlem güçlerini ve gelirlerini de dikkate alacaktır. Bu nedenle, piyasada farklı bilgi işlem gücü olacak, yüksek işlem gücü kanıtları daha hızlı, ancak daha yüksek maliyetle üretecek, düşük işlem gücü ise kanıtları daha yavaş ama daha ucuza üretecek.
İKİ ADIMLI TAAHHÜT
Son zamanlarda Opside, kanıtlayıcı ağını dağıtmak için iki adımlı bir taahhüt planı önerdi. Şema, en hızlı kanıtlayanın her zaman kazandığı durumdan kaçınmak için kanıt sunumunu iki aşamaya ayırır.
Bu yöntem, farklı bilgi işlem gücünü barındırabilir. Bununla birlikte, gerekli teminat hala bir düzeyde merkezileşme getirmektedir.
Sıralayıcı Ademi Merkeziyetçilik
Sipariş verenlerin ademi merkeziyetçiliği, doğrulayıcılarınkinden daha karmaşıktır. Bunun nedeni, sıralayıcının işlemleri paketleme ve düzenleme gücüne sahip olmasıdır ve MEV ve gelir dağılımı gibi konuların dikkate alınması gerekir.
Ethereum'un duyarlılığa göre canlılığa öncelik vereceği göz önüne alındığında, L2 çözümleri, canlılığa göre yanıt vermeye öncelik vererek bu değiş tokuşu tamamlamalıdır. Bununla birlikte, merkezileştirilmiş ayrıştırıcılarla karşılaştırıldığında, merkezi olmayan ayrıştırıcılar doğal olarak yanıt verebilirlik açısından fedakarlık yapar. Bu nedenle, bu ikilemi çözmek için çeşitli optimizasyonların uygulanması gerekir.
Şu anda, üç farklı merkezi olmayan ayrıştırıcı önerisi var. İlk çözüm, mutabakat mekanizması optimize edilerek gerçekleştirilir. İkinci şema, paylaşılan sıralayıcılardan oluşan bir ağı içerir. Üçüncü şema, L1 doğrulayıcılarına dayanmaktadır.
uzlaşma
Mutabakat protokolü, işlemleri yürütmekten değil, sipariş vermekten ve bunların kullanılabilirliğini sağlamaktan birincil derecede sorumludur. Ancak, daha önce de belirtildiği gibi doğrudan başka bir mutabakat katmanı eklemek kolay bir çözüm değildir.
Yanıt verebilirliği iyileştirmek için yaygın bir yaklaşım, daha küçük bir doğrulayıcı grubuna güvenmektir. Örneğin, Algorand ve Polkadot toplu işlemler için rastgele örneklenmiş daha küçük komiteler kullanır. Tüm düğümler, bahis miktarlarıyla orantılı olarak belirli bir süre içinde bir komiteye dahil olma olasılığı ile rastgele işaretçiler ve doğrulanabilir bir rastgele işlev (VRF) kullanır.
Ağ trafiğini azaltmak için daha küçük Veri Kullanılabilirliği (DA) komiteleri kullanılabilir. Veya VID (Doğrulanabilir Bilgi Dağılımı) kullanın. VID, verilerin silme kodunu mutabakata katılan tüm düğümlere dağıtır, böylece yeterince yüksek taahhüt oranına sahip herhangi bir düğüm alt kümesi, verileri geri yüklemek için işbirliği yapabilir. Bu yaklaşımın takası, yayın karmaşıklığını azaltmak, ancak veri kurtarmanın karmaşıklığını artırmaktır.
Arbitrum, sıralayıcı komiteye katılmak üzere ConsenSys, Ethereum Foundation, L2BEAT, Mycelium, Offchain Labs, P2P, Quicknode, IFF'nin Distributed Ledger Research Center (DLRC) ve Unit 410 gibi saygın varlıkları doğrulayıcı setini oluşturmak üzere seçti. Bu yaklaşımdaki takas, ademi merkeziyetçiliğin kalitesini iyileştirerek nicelik eksikliğini telafi etmektir.
Paylaşılan Sıralayıcı Ağı
Sıralayıcılar, modüler blok zincirlerinde, özellikle Toplamalarda hayati bir rol oynar. Her Toplama, genellikle kendi sıralayıcı ağını oluşturur. Ancak, bu yaklaşım sadece artıklık sorunları yaratmakla kalmaz, aynı zamanda şekillendirilebilirliği de engeller. Bu sorunu çözmek için, bazı protokoller paylaşılan bir Toplama sıralayıcı ağı oluşturmayı önerir. Bu yaklaşım, kullanıcıların ve geliştiricilerin açık, izinsiz blok zincirlerinde umutsuzca ihtiyaç duyduğu özellikler olan atomiklik, birleştirilebilirlik ve birlikte çalışabilirlik elde etmenin karmaşıklığını azaltır. Ek olarak, sipariş veren ağ için ayrı bir hafif istemci ihtiyacını da ortadan kaldırır.
Astrya
Astria, Celestia'nın kendi dağıtılmış sipariş sağlayıcı koleksiyonunu içeren Rollup ekosistemi için bir ara yazılım blok zinciri geliştiriyor. Bu sipariş verenler grubu, birden çok Toplamadan gelen işlemleri kabul etmekten ve bunları yürütmeden temel katmana yazmaktan sorumludur.
Astria'nın rolü, temel olarak işlem sıralamasına odaklanır ve temel katman ile Toplama'dan bağımsız olarak çalışır. İşlem verileri temel katmanda (örn. Celestia) depolanırken, Toplama tam düğümleri durumu korur ve işlemleri yürütür. Bu, Astria'nın Toplama'dan ayrılmasını sağlar.
Son olarak, Astria iki düzeyde Taahhüt sağlar:
Espresso
Espresso, sıfır bilgi teknolojisi alanında önemli bir katkı sağlamıştır. En son geliştirmeleri, Optimistic Rollups ve zkRollups'a uygulanabilen merkezi olmayan sıralayıcılar için kapsamlı bir çözümdür.
Merkezi olmayan sipariş ağı şunlardan oluşur:
Astria ile karşılaştırıldığında, Espresso DA sunar. Bu nedenle, iş akışı aşağıdaki gibi biraz farklı olacaktır:
Kullanıcı, bir işlem oluşturur ve Toplama'ya gönderir.
İşlem, sipariş veren ağı aracılığıyla yayılır ve mempool'da tutulur.
HotShot taahhüt mekanizması aracılığıyla bir lider belirleyin, bir blok önerin ve bunu Rollup'ın yürütücülerine ve doğrulayıcılarına geri gönderin.
Lider, işlemi Veri Kullanılabilirliği Komitesine gönderir ve geri bildirim olarak bir DA sertifikası alır.
Lider ayrıca, sözleşmenin bloğu doğrulamak için kullandığı sertifikayla birlikte Katman 1 Sıralayıcı sözleşmesine bloğa bir taahhüt gönderir.
Espresso, daha esnek bir kullanıcı deneyimi sağlamak için provalar için Gossip protokolünü sunar. İşlem kesinliği için üç seçenek sunar:
Yukarıdaki optimizasyonlara ek olarak Espresso, tüm Ethereum doğrulayıcı setinin Espresso sipariş protokolünü çalıştırmaya katılmasını da planlıyor. Aynı doğrulayıcı setini kullanmak benzer bir güvenlik sağlayacak ve L1 doğrulayıcılarıyla değer paylaşmak daha güvenli olacaktır. Ayrıca Espresso, EigenLayer tarafından sağlanan ETH yeniden staking çözümünden de yararlanabilir.
Yarıçap
Radius, L2'deki MEV problemini çözmeye odaklanan, sıfır bilgi kanıtlarına dayalı, güvene dayalı olmayan bir paylaşımlı sıralama katmanı inşa ediyor çünkü L2'nin geliri esas olarak blok alanından geliyor. Dikkate alınması gereken denge, MEV ve L2 geliri arasındaki dengedir. Radius'un amacı, kullanıcılar için zararlı olan MEV'i ortadan kaldırmak ve iki katmanlı bir hizmet önermektedir.
Üst katman, normal kullanıcı işlemlerini hedefler ve zaman kilitli bulmacaların kullanımı yoluyla istenmeyen MEV'ye karşı kriptografik koruma sağlar. Spesifik olarak, RSA tabanlı zaman kilidi bulmacaları için 5 saniye içinde sıfır bilgi kanıtları üretecek olan Pratik Doğrulanabilir Gecikmeli Şifreleme (PVDE) teknolojisini kullanır. Bu yöntem, kullanıcıları zararlı MEV'lerden korumak için pratik bir çözüm sunar. Kısacası, sıralayıcı işlemlerin sırasını belirleyene kadar işlem içeriği bilinemez.
Altta yatan katman, blok oluşturucular için tasarlanmıştır ve MEV'nin olumsuz etkisini azaltırken onların gelir getirici faaliyetlere katılmalarına izin verir.
Temel Toplamalar
Tabanlı Toplama, kısa bir süre önce Justin Drake tarafından önerilen bir kavramdır; burada L1 bloğu öneren kişiler, izinsiz olarak bir sonraki L1 bloğuna toplama blokları dahil etmek için L1 araştırmacıları ve inşaatçıları ile işbirliği yapar. L1'de paylaşılan sıralayıcılardan oluşan bir ağ olarak görüntülenebilir. Tabanlı Toplama'nın avantajları ve dezavantajları açıktır.
Olumlu tarafı, Tabanlı Toplama, L1 tarafından sağlanan canlılık ve dağıtıklığın avantajlarından yararlanır ve uygulanması basit ve verimlidir. Tabanlı Toplama, L1 ile ekonomik olarak da tutarlıdır. Ancak bu, Tabanlı Toplama'nın egemenliğinden ödün verdiği anlamına gelmez. MEV, L1'e devredilmiş olsa da, Tabanlı Toplama yine de yönetişim belirteçlerine sahip olabilir ve taban ücretler alabilir. Hipoteze dayanarak, Tabanlı Toplama bu avantajlardan yararlanabilir, hakimiyet sağlayabilir ve nihayetinde getirileri en üst düzeye çıkarabilir.
Sonuç olarak
Sunulan önerilere bakıldığında, Rollup'ın merkeziyetçilikten uzaklaştırılması için kat edilmesi gereken daha çok yol olduğu görülüyor. Bu tekliflerden bazıları hala taslak aşamasındadır ve daha fazla tartışma gerektirirken, diğerleri yalnızca ön şartnameleri tamamlamıştır. Tüm bu senaryoların uygulanması ve titizlikle test edilmesi gerekir.
Bazı Toplamalar, karşılık gelen bir merkezi olmayan çözümü açıkça önermese de, genellikle merkezi sipariş verenlerden kaynaklanan tek hata noktalarını ele almak için kaçış mekanizmaları içerirler. Örneğin zkSync, kullanıcıların paralarını doğrudan L1'den çekmelerine olanak tanıyan bir FullExit yöntemi sağlar. Sistem çıkış moduna girdiğinde ve yeni blokları işleyemediğinde, kullanıcı bir para çekme işlemi başlatabilir.
Sansüre karşı direnç elde etmek için, bu Toplamalar genellikle kullanıcıların işlemleri doğrudan L1'de göndermelerine de izin verir. Örneğin, zkSync, L1'de gönderilen bu tür işlemler için bir öncelik sırası kullanır. Benzer şekilde, Polygon zkEVM, L1 sözleşmesinde zorunlu toplu iş yöntemi içerir. Bir hafta içinde toplama olmadığında, kullanıcı L1'de bu yöntemi çağırabilir ve kanıtlayıcıya işlemin bayt dizisini ve bathFee'yi sağlayabilir.
Kesin olan bir şey var ki, öngörülebilir gelecekte, Rollup'ın ademi merkeziyetçiliği, yukarıda belirtilen önemli çözümleri veya diğer bazı yenilikçi varyantları içerebilecek birleşik bir çözüm olacaktır.