Orijinal başlığı 'hepimiz aynı şeyi inşa ediyoruz' ileriye doğru gönderin

giriş

bu gönderi aşağıdakileri analiz ediyor

• asenkron yürütme - neden yüksek performanslı entegre blockhain'ler (örneğin, SolanaveMonad) yürütmenin (sıralamanın) onayından ayrılmasını sağlayacaktır.
• tembel sıralama - nasıl tembel bir sıralama tasarlayacaklarını yansıtacaklar (örn. ,@astriaorg/hj6ccpp9t">astria).
• Ön onaylamalar - ethereum l1 ve tabanlı rollups üzerinde preconfs.
• temellere dayalı vs. temel olmayan - temellere dayalı rollup'lar + önceden yapılandırılmışlar ile temel olmayan rollup'lar + temel katman geriye düşmesi karşılaştırması.
• evrensel senkron kompozabilite - paylaşılan sıralayıcılardan atomik dahil etme + kriptografik güvenlik (örneğin, AggLayerve/veya gerçek zamanlı kanıt).
• hızlı tabanlı rollups - tabanlı rollups sadece hızlı bir tabana sahip olmalıdır.
• zamanlama oyunları - Zaman para demektirve bunun solana vs. ethereum arasındaki farklı son oyunlarına nasıl yattığı
• sansür dirençli merkezileşme - nasılattester-proposer ayrımıaracılığıylayürütme açık artırmalarıMerkezi olmayan doğrulayıcıları koruyabilir ki bunlar sansür direncini uygulayabilir.dahil etme listeleri.

son olarak ve en önemlisi, neden göreceğiz hepimiz aynı lanet şeyi inşa ediyoruzo zaman belki sadece...

durum makinesi replikasyonunu (smr) optimize etmek

Yüksek performanslı blok zincirlerinin son oyununu (örneğin, temellerden başlayarak oluşturacağız.Solana, Monad (Monad), @patrickogrady/ rys8mdl5p # önleme-stratejisi, geçersiz tps'leri en aza indirebilen kar maksimizasyonu sağlayan inşaatçılara olanak tanıyan (hypersdk) yaklaşımları ile benzerlik gösterir.tembel dizici (örn., @astriaorg/hj6ccpp9t">astria). daha sonra onları ethereum tabanlı rollups + preconfs ile karşılaştırmak için tam daireye geleceğiz.

Sıralama vs. Yürütme

block zincirleridir çoğaltılmış durum makineleri. merkezi olmayan düğümler, sistem durumunun kendi kopyasını tutar ve günceller. zinciri ilerletmek için düğümler, mevcut durum + yeni girişler (örneğin, yeni işlemler) üzerinde durum geçiş işlevini (stf) çalıştırır. bu yeni bir durum üretir.

Bu bölüm boyunca aşağıdaki terimleri kullanacağız:

• sözdizimsel olarak geçerli - işlem, uygun bir işlem yapısı ve imza ile iyi şekillendirilmiştir.
• sembantik olarak geçerli - işlem geçerli bir durum geçişi gerçekleştirir (ör. gerekli ücretleri öder).
• Sıra - verilerin sıralamasını ve dahil edilmesini belirler.
• yürütmek - verileri stf'ye uygun olarak yorumlamak ve ona göre hareket etmek.
• build - yerel olarak depolanan işlemlerden bir blok (veya kısmi blok parçası / shred) oluşturun.
• doğrulamak - bir bloğun (veya kısmi blok parçasının / shred'in) gereken sözdizimsel ve / veya anlamsal doğrulamasını yapmak.
• Başka doğrulayıcılara bir bloğu (veya kısmi blok parçası / parça) çoğaltmak / yaymak.

Dizilimi ve yürütme üzerine odaklanalım, çünkü bunlar zincirin durumunu hesaplamak için gereken temel alt görevlerdir:

Ayrıca, düğümler veriyi ağ üzerinde doğrular ve çoğaltır. Düğümler, zincirin tutarlı bir görünümünü korumak için uzlaşıya varırlar.

ancak, farklı zincir mimarileri, bu görevlerden kimin sorumlu olduğu ve ne zaman yaptığı konusunda anlamlı ölçüde farklılık gösterir (örneğin, blok oluşturma ve doğrulama, yürütümü içerebilir veya içermeyebilir). tamdurum makinesi replikasyonu (smr)Döngü, sistem gecikmesinin alt sınırlarını belirler. Farklı yapılar çok farklı süreler elde edebilir, bu yüzden verimli bir smr işlemiboru hatlarıBu görevler, düşük gecikme süresi ve yüksek verimlilik için gereklidir.

Aşağıdaki bölümlerde, etkili boru hattı oluşturmanın temel bir bilgeliği, yürütme sonuçlarından ziyade yürütme girişleri üzerinde fikir birliği sağlamaya odaklanmaktır. Bu, dahil edilebilecek işlemlerle ilgili belirli kısıtlamaların gevşetilmesini gerektirir. Ardından, sistemin kullanışlı ve saldırılara karşı dayanıklı kalmasını sağlamak için bazı zayıf kısıtlamaları tekrar tanıtmamız gerekecektir (örneğin, ücret ödemeyen işlemlerden kaynaklanan dos vektörlerini önlemek).

geleneksel smr

geleneksel smr (ör. ethereum), sıralamayı ve yürütümü sıkı bir şekilde birbirine bağlar. Tam düğümler sürekli olarak tüm temel katman işlemlerini sıralar ve yürütür - her ikisi de düğümlerin uzlaşmaya ulaşması için gereklidir. Blok verilerinin tamamının mevcut olduğunu (ve sıralandığını) doğrulamanın yanı sıra, düğümler bloğu yürütmek için de çalıştırmalıdır, böylece aşağıdakileri doğrulayabilirler:

• tüm işlemler sözdizimsel ve anlamsal olarak geçerlidir
• yeni hesaplanan durum lider tarafından sağlanan durumla eşleşiyor

Doğrulayıcılar, durumunu bağımsız olarak doğruladıktan sonra yalnızca bir blok için oy verirler ve üzerine inşa ederler. Bu, uzlaşıya varılabilmesi için en az iki kez yürütmenin gerçekleştiği anlamına gelir (yani, blok üreticisi inşa sırasında yürütür + alıcı doğrulamak için tekrar yürütür).

bu geleneksel modelde, hem inşa etme hem de doğrulama yürütme içerir.

kaynak: @patrickogrady/rys8mdl5p#decoupled state machine replication (DSMR) için argüman oluşturma: vryx

canlı akış smr

streaming smr (örneğin, solana) boru hattı işlemenin verimli bir şeklidirblok üreticileri sürekli olarak blok parçalarını 'akıtır'(adlandırılır parçalar veya parçaları) oluşturulduğu gibi yayınlayarak şeritleri (veya parçaları) ağa gönderir. Diğer düğümler bu şeritleri sürekli olarak alırlar ve doğrularlar (dahil olmak üzere yürütürler), hatta bloğun geri kalanı henüz oluşturulurken bile. Bu, bir sonraki liderin bloğu daha erken oluşturmaya başlamasına izin verir.

Kaynak: @patrickogrady/rys8mdl5p#decoupled-state-machine-replication-dsmr-i>vryx: decoupled state machine replication'i güçlendirme

Bu akış modelinde, hem inşa etme hem de doğrulama hala sıralama ve yürütme içerir. Bu, tüm dahil edilen işlemlerin hem anlamsal hem de sözdizimsel olarak geçerli olduğu herhangi bir kısıtlamayı gevşetmeksizin smr verimliliğini geleneksel smr'a göre artırır.

eşzamansız yürütme

entegre yaklaşım

Şimdi, bu kısıtlamaları gevşetirsek daha iyi bir performans elde edebilir miyiz?

asenkron yürütme, yürütmenin oluşumun sıcak yolundan çıkarmaktadır - düğümler sadece verilerin sıralaması konusunda önce veriyi yürütmeden uzlaşırlar. Bu daha verimlidir, bu yüzdenSolanaveMonadHer ikisi de asenkron yürütümü uygulamayı planlıyor.

lider, onu yürütmeye ihtiyaç duymadan bir blok (veya parçalar) inşa eder ve çoğaltır. ardından, diğer doğrulayıcılar da onu yürütmeksizin oy kullanır. düğümler yalnızca işlemlerin sıralanması ve erişilebilirliği konusunda uzlaşırlar. bu, deterministik bir stf verildiğinde herkesin sonunda aynı durumu hesaplayacağı için yeterlidir. yürütme uzlaşmayı bekletmek zorunda değildir - asenkron olarak çalışabilir. bu, düğümlere yürütme için daha fazla zaman harcamaları için bütçe açabilirken gerekli adımları (ve dolayısıyla zamanı) azaltabilir.

sipariş gerçeği belirler. yürütme sadece onu ortaya çıkarır. Verileri herkes sadece sıralaması tamamlandıktan sonra gerçeği ortaya çıkarmak için yürütebilir.

büyük olasılıkla bu yüzdenKeone, sonunda her blok zinciri asenkron yürütümü kullanacak inancındadır., ve bu önemli bir parçası Toly’nin Solana için son oyun vizyonu:

“eşzamanlı yürütme, oy kullanan ve blok oluşturan tüm düğümlerin herhangi bir bloktaki en kötü durum yürütme süresi için fazla kaynaklandırılmasını gerektirir… uzlaşma düğümleri oy vermeden önce daha az iş yapabilir. iş, toplanabilir ve toplu olarak yapılabilir, böylece önbellek hataları olmadan verimli bir şekilde yürütülür. hatta uzlaşma düğümlerinden veya liderlerden tamamen farklı bir makinede bile yürütülebilir. eşzamanlı yürütme isteyen kullanıcılar, ağın geri kalanını beklemek zorunda kalmadan her durum geçişini gerçek zamanlı olarak yürütmek için yeterli donanım kaynakları ayırabilir.

şu anda, geçerlendiriciler her blokta mümkün olduğunca hızlı bir şekilde tüm işlemleri tekrar oynatır ve yalnızca blok için tam durum hesaplandıktan sonra bir kez oy kullanır. bu önerinin amacı, bir çatalda oy vermeyi blok için tam durum geçişini hesaplamaktan ayırmaktır.

Bu arada, kullanıcıların gerçeğin kolayca ortaya çıkmasını da sağlamak istiyoruz ve bu da hafif istemcilere sağlam destek anlamına gelir. Uygulamanın yürütülmesini önemli ölçüde geciktiren bazı tasarımlar, bunu zorlaştırabilir (örneğin,Solana, sadece her dönem için bir kez gerektirmeyi düşünüyor.) vs. hypersdk'da olduğu gibi daha kısa bir gecikmeyle bir durum kökü sağlayan diğerleriyle karşılaştırıldığında.

modüler yaklaşım

Dizimleme ve yürütmenin ayrıştırılması, farklı görevlere uzmanlaşmış farklı katmanları karıştırma ve eşleştirme gibi çok tanıdık gelebilir. Dizimleme ve yürütmenin ayrıştırılması, tembellerin (örneğin, astria) ana tasarım prensibidir.

• Dizilime - dizi düğümleri sadece rollup verilerinin sıralanması ve kullanılabilirliği konusunda uzlaşmaya varır (yani, sıralama yaparlar ancak yürütme yapmazlar).
• yürütme - rollup düğümleri, ardından sıralayıcının ona taahhüt etmesinden sonra ilgili verilerini yürütür.

buradaki temel fark, entegre zincir düğümlerinin sıralamadan sonra çalışırken, tembel sıralayıcıların tamamen farklı ve çeşitli bir aktör kümesine itmesidir. Tembel sıralayıcılar rollup'ların durum makinelerine tamamen yabancıdır. Bu işlemleri asla gerçekleştirmezler. Rollup'lar asenkron yürütümü yönetir.

Entegre yaklaşım, yürütme ortamı kullanıcıları arasında daha sorunsuz bir etkileşim sağlar, ancak uygulama geliştiricileri için esnekliği yönlendiren faktörler (örneğin, özel sanal makineler, farklı yuva süreleri) azaltır.Consensus ile zorunlu hale getirilen uygulama özel işlem fiyatlandırma ve sıralama kuralları, vb.). modüler yaklaşım, geliştiricilere özelleştirilmiş alan adlarına sahip olma konusunda daha fazla esneklik ve egemenlik sağlar, ancak deneyimi birleştirmek daha zordur.

Her iki durumda da, veri siparişi için gerçekten büyük ve hızlı bir boruya ihtiyacımız var:

Ancak, teknik olarak hemen hemen her zinciri tembel bir sıralayıcı olarak kullanabileceğinizi unutmamalısınız. Ne de olsa günün sonunda bu sadece büyük bir veri borusu. Bir toplama, rastgele verilerini saf bir şekilde seçtiği temel katmana (Ethereum, Bitcoin, Monad, vb.) atarak dolaylı olarak sıralayıcı olarak kullanabilir. Toplama düğümleri daha sonra verileri zaman uyumsuz olarak yürütebilir.

Uygulamadaki fark, gerçekten "tembel sıralayıcılar" olarak adlandırdığımız zincirlerin, gerekli işlem tiplerini destekleme, kolay arabirimler sunma, mev altyapısını uygulama, hızlı slot süreleri, güvenilir işlem dahil etme, yüksek bant genişliği vb. görevler için özelleştirilmiş olmasıdır. Sonuç olarak, bütünleşik zincirler için düğümler, dahil ettikleri verilerin çoğunu sonunda yürütürken, tembel sıralayıcılar bunu öncelikle rollup'lara bırakır.

işte bu yüzden o kadar basit değil, "neden sadece solana'yı (veya herhangi başka bir zinciri, bu hiçbir zaman tasarım hedefi olmamışken) bir rollup dizisinde kullanmıyoruz?"

• rollup'lar için özel olarak tasarlanmış gerekli mev altyapısının eksikliği (örneğin, gereken pbs altyapısı, cross-chain etkileşim mekanizmaları, rollup kullanıcıları için temel katman gaz tokeninde ücret ödemelerini soyutlamak için besteci vb.)
• Rollup gönderi verileri için tasarlanmış yerel işlem türlerinden yoksundur.
• yerel yürütme ortamına karşı rekabet etmek (örneğin, açıkça verilen tüm veriyi tüketmek için tasarlanmıştır, daha az yer ve güvenilir işlem dahil etme vb. bırakarak).
• genel geliştirici desteği ve yükseltme öncelikleri için rekabet ediyor. Muhtemelen, rollup'ları başlatmanıza ve protokolünü özellikle sizin için tasarlamanıza yardımcı olan protokol ve ekibe gitmeye daha meyilli olursunuz. Topluluğun çoğunluğunun rollup'ların biraz aptalca olduğunu düşündüğü yerden değil.

güçlendirilmiş bağlantısız smr

şimdi, bu kısıtlamaları gevşeterek elde ettiğimiz sorunları ele alabilir miyiz? Kısacası, evet, saf uygulamalar geçersiz işlemlere izin vererek problemler ortaya çıkarabilir (saf bir şekilde uygulandığında dos vektörü olabilir), ancak bu tür sorunların ciddi sorunlar olmadığı şekilde ele alınabilir.

burada ayrıntılara fazla takılmayacağız, ancak şuraya bakabilirsiniz Patrick o’grady’sharika çalışma@patrickogrady/rys8mdl5p#Decoupled State Machine Replication (DSMR) için argüman oluşturma - Vryx, Toly'nin ayrıştırılmış SMR'ını güçlendirecekEşzamansız yürütme oyun sonu, ve Monad'ın taşıma masraflarını uygulamasıBu sorunları nasıl ele alınacağına dair. tekrar, bu sorunların çözümleri modüler tarafta ve entegre tarafta neredeyse aynı görünüyor şaşırtıcı bir şekilde.

özetle, senkron çalışma ve tam doğrulama ile karşılaştırıldığında çok daha zayıf kısıtlamalar ekleyebilir ve çoğu performans avantajlarını koruyabilirsiniz, ancak bir dizi saldırıyı da ortadan kaldırmaz.

protokol içi ve protokol dışı aktörler

Önemli olan, yukarıdaki süreçlerin safça sadece protokol içi aktörleri hesaba kattığını fark etmemiz gerektiğidir. Gerçekte, protokol dışı aktörler bu işlem tedarik zincirlerinde büyük bir rol oynarlar. Bu, geleneksel smr'deki (protokol içi) doğrulayıcılarda daha önce gördüğümüz şeydir:

kaynak: @patrickogrady/rys8mdl5p#making-the-case-for-decoupled-state-machine-replication-dsmr">vryx: decoupled state machine replication'ı güçlendirmek

ancak pratikte,nearly all ethereum validators outsource block building via mev-boostEn üstteki üç oluşturucu (beaver, titan ve rsync) neredeyse tüm bu blokları oluştururken. Beaver ve rsync, ofac işlemlerini sansürlerken, titan yapmaz.

kaynak: mevboost.pics

röleler, bu blokların ağın geri kalanına kopyalanmasını sağlar. Ayrıca, en üstteki dört işletici (ultra sound, bloxroute, agnostic ve flashbots), blokların büyük çoğunluğunu iletiyor. Bloxroute ve flashbots, ofac işlemlerini sansürlüyor, agnostic ve ultra sound ise yapmıyor.

kaynak: mevboost.pics

Daha önce tartıştığımız gibi, burada gecikme optimizasyonlarında çok benzer eğilimler görmemiz de şaşırtıcı olmamalıdır. Eğilim yönünde iyimser rölelerartık çoğaltmadan önce blok doğrulaması yapmayan, çünkü sadece daha hızlı olduğu için tembel sıralayıcılar teşvik edilmiş röle ağları olarak görülebilir.

bu örnekler, mev'nin bu sistemlerde kar teşviklerini nasıl çarpıttığını vurgulamaktadır. doğal olarak sıralanmış bloklara karşı sofistike yapımcılar daha fazla değer yakalayabileceğinden, doğrulayıcılar blok üretimini dış kaynak kullanımı yapmaktadır.

asenkron yürütme altında olsa bile, genellikle değeri en üst düzeye çıkarmak için protokol dışı blok üreticileri işlem yürütür. Örneğin, tembel sıralayıcıların bazı şekillerde kârı maksimize eden yapımcıları olması çok olasıdır. Bir dış blok üreticisinin her zaman bir bloğun değerini tam olarak yürütme ve optimize etme teşviki aslında async yürütme kısıtlamalarını gevşettiğimiz ortamlarda faydalı olabilir. Ancak, diğer doğrulayıcıların oy kullanmadan önce yeniden yürütmesine gerek olmayacaktır.

evrensel eşzamanlı bileşebilirlik

tanımlar

Şimdi, modüler zincirlerin sunduğu egemenliği ve esnekliği elde edebilir miyiz, ancak onları entegre bir zincir gibi hissettirmek için bir araya getirebilir miyiz? Hem pastamızı yiyebilir hem de onu yiyebilir miyiz, yoksa sadece ek adımlarla Solana'yı mı inşa ederiz?

rollup parçalanmasını düzeltmek hakkında insanların konuştuğunu duyduğunuzda, muhtemelen büyük bir heyecanla bahsedilen kelimeleri duymuşsunuzdur.Evrensel senkron birleştirilebilirlik (usc). Bununla birlikte, muhtemelen tepkiniz şu olmuştur:

Bu terimler farklı anlamlarla atılır ve bazı terimler sıklıkla yanlış bir şekilde birbirinin yerine kullanılır. Bazı somut tanımlar belirlememiz gerekiyor. Çapraz zincir uyumluluğu bağlamında aşağıdaki gerekli terimleri tanımlıyoruz.

Bu raporun geri kalanında 'rollup'ları tartışacağımızı unutmayın ancak bu kavramların birçoğu validiumlar gibi diğer 'l2' türlerine de eşit şekilde uygulanabilir.Yine bir L2 hakkında ne olduğu konusunda kavga etmek istemiyorum..

aşağıdaki örneklerde:

• r_bir = toplama a
• r_b = rollup b
• t_A1= r üzerinde işlem 1_bir
• t_b1r üzerindeki işlem 1_b
• b_a1 = blok 1 üzerinde r_bir
• b_b1 = r'deki blok 1_b
  

burada 'zamanı' 'yığıt yüksekliği' olarak tanımladığımıza dikkat edin. zaman sadece gözlemciye bağımlıdır. sahip olduğumuz tek nesnel zaman kavramı, bir paylaşılan gözlemci tarafından göreli bir sıralama ile ifade edilen paylaşılan bir uzlaşmadır (bu 'uzlaşma' tek bir aktör veya merkezi olmayan bir mekanizma olabilir).

Her iki rollup da sıralama sağlayan bir konsensüs mekanizmasına sahipse, şunu iddia edebiliriz:

• b_A1 b'den önce_A2
• b_b1b'den önce gelir_b2

ancak, iddia etmenin tek yolu:

• b_a1 aynı zamanda b'de_b1, ve bu nedenle
• t_a1ve t_b1eşzamanlı olarak gerçekleşmek, eğer
• Verilen yuva için paylaşılan bir uzlaşma tarafından sağlanan bir sırayı paylaşıyorlar.

Bu nedenle, çapraz zincir senkron bileşilebilirlik tanımı, o slot yüksekliği için paylaşılan bir sıralayıcı türü gerektirir. Biri olmayan zincirler sadece asenkron bileşilebilirliğe sahip olabilirler.

ancak, asenkron atomik bileşebilirliğe sahip olabileceğimize dikkat edin. Ne yazık ki, genellikle insanların "atomik" ve "eşzamanlı" terimlerini birbirinin yerine kullandığını fark ederim, ancak aslında farklı terimlerdir.

bu konuyu hallettikten sonra, modüler zincirlere senkron bileşilebilirliği tekrar tanıtabilir miyiz bakalım. Eğer yapabilirsek, bu entegre zincirlerin değerini Gate.io'nun azaldığı gibi görünebilir. İşte daha derinlemesine gireceğimiz özet:

• paylaşılan sıralama, kendi başına senkron atomik dahil olma sağlayabilir (ki bu, bileşebilirlikten çok daha zayıftır).
• paylaşılan bir sıralayıcıyı kriptografik güvenlik mekanizmasıyla eşleştirmek (ör. agglayer) bu dahil etme garantisiyi gerçek bileşime güçlendirebilir.
• Çapraz zincir güvenliği için agglayer tarafından sağlanan güvenlik garantileri ayrıca paylaşılan bir sıralayıcıya ihtiyaç duymadan da kullanılabilir (yani, asenkron ortamda).
• Görün bakalım, senkron bileşimliliğin etkilerini de simüle edebileceğimizi, ancak kriptoekonomi kullanarak (doğrudan çapraz zincir işlemlerine teminat vererek) daha az sermaye verimli bir şekilde yapabiliriz.

atomik dahil - paylaşılan sıralama

Paylaşılan sıralama, belirli bir slot yüksekliği için tek bir varlığın ("sıralayıcı" olarak da bilinen "önerici") birden fazla zincir için blokları sıralama (yani önerme) tekel hakkına sahip olduğu anlamına gelir. Tekrar etmek gerekirse, genellikle bahsettiğimiz bu paylaşılan sıralayıcılar, tembel diziciler. rollup verilerinin sıralaması ve kullanılabilirliği konusunda uzlaşırlar, ancak bunu yürütmezler. rollup'ların durum makinelerinden tamamen habersizler.

Daha önce yazdığım gibiBu, tembel paylaşılan sıralayıcıların çapraz zincir demetlerini (yani bir dizi işlem) dahil etmek için güvenilir bir taahhüt sağlayabileceği anlamına gelir.

• atomik olarak - ya tüm işlemler dahil edilecek ya da hiçbiri, ve
• eşzamanlı olarak - aynı anda (yuvaa yüksekliği)

Bu, daha verimli bir MEV çıkarma işlemine olanak tanır.süper yapımcılar(yani, cross-chain yapımcıları) çapraz zincir eylemlerini gerçekleştirirken artık çapraz zincir demetinin bir bacağının başarısız olma riskini fiyatlandırmak zorunda kalmazlar. buradaki eşzamanlılık, onlara örtülü bir şekilde atomisite sağlayabilmektedir.

çapraz zincir çözme

Şimdi, paylaşılan sıralayıcı için oluşturucuya ve/veya etkin önericiye tamamen güvenmeden bunu nasıl yapabiliriz? Eğer sadece iki bağımsız olarak imzalanmış işlem gönderirsek (t₁ve t₂) her bir rollup için, paylaşılan sıralayıcı yine de sadece birini veya diğerini dahil etmeye karar verebilir.

Örneğin, bugün EVM'de yerel bir paket formatı kavramı yoktur, bu nedenle arama yapanlar bunları ayrıştırmamaları için oluşturuculara/aktarıcılara tamamen güvenirler. Mevcut lider tarafından taahhüt edilmeden önce bağımsız olarak imzalanmış bir işlem paketi gören herkes bunları çözebilir. Bu genellikle iyidir, çünkü oluşturucular ve aktarıcılar itibarlarını korumaya ve arama paketlerini korumaya teşvik edilir, ancak bu güven bozulduğunda (veya dürüst olmayan katılımcılar tarafından işlemleri ifşa etmeleri için kandırıldıklarında), parçalama inanılmaz derecede karlı olabilir.

Gerçek çapraz zincir uyumluluğunu istiyorsak, burada çok daha güçlü bir güvenlik garantisi sağlamamız gerekiyor. Sadece bir araştırmacıdan biraz para almakla ilgilenmiyoruz. Çapraz zincir defi sözleşmeleri, çapraz zincir paketlerinin saygı göreceği varsayımına dayanarak kendilerini mimarlaştırırsa, ancak bu güven bozulursa, sonuçlar bu protokoller için felaket olur (örneğin, yakma ve basma çapraz zincir köprü paketinde yakmayı çıkartabilir, ancak diğer tarafta fonları basabilirsiniz).

Çapraz zincir etkileşimini uygulamak için sağlam güvenlik garantilerine ihtiyacımız var. Bu, çapraz zincir demeti içindeki birden çok işlemin birlikte dahil edildiğinden emin olacak bir işlem formatı tanımlamamız gerektiği anlamına gelir. Diğer dahil edilmeden biri dahil edilirse, dahil edilenin geçersiz olduğuna dair bir güvenlik garantisi gerekiyor.

bu, çapraz zincir demetleri için yeni bir işlem yapısı oluşturmanız gerektiği anlamına gelir, bunun yapılamayacağıaçılmamış. saf çözüm, rollup'lar için 'sadece bu rollup'lar için yeni bir işlem türü yapalım' demek, ama bu o kadar da kolay değil. Bu rollup'lar için vm değişiklikleri gerektirecek ve geriye dönük uyumluluğu kaybedecektir. Ayrıca rollup'ları birbirine sıkı sıkıya bağlayarak, her işlemin sadece diğerinin dahil edilmesiyle geçerli olacağı şekilde durum makinelerini değiştirmeniz gerekecektir.

Ancak, bunu yapmanın daha temiz bir yolu var.. her işlemi demet içinde de imzalatabilirsiniz, ardından özet hash'i ücretsiz işlem alanına (örneğin, evm'de çağrı verisi) ekleyebilirsiniz. rollup, türetilmiş boru hattını bunları kontrol etmek için değiştirmeli, ancak vm değişmeden kalabilir. Bu şekilde, rollup kullanıcıları, çapraz zincir demetleri gönderebilir ve bunların kesinlikle ayrılamayacağından emin olabilir. Bunu yapmaya çalışmak, onları geçersiz kılacaktır.

kaynak: Ben fisch

dahil etme garantileri vs. devlet garantileri

yukarıdakiler yerinde olduğunda, artık bir tembel paylaşılan sıralayıcıyı nasıl kurduğumuzu belirledik:

• çapraz zincir demetleri için atomik eşzamanlı dahil etme konusunda güvenilir bir taahhüt sağlayabilir (yani, tüm işlemlerin dahil edileceği veya hiçbirinin dahil edilmeyeceği)
• Böyle işlemlerin sonucunun dahil edilmesiyle ilgili olarak güvenilir bir taahhüt sağlanamaz (örneğin, her iki işlem de dahil edilebilir, ancak diğer bir işlem önce gelir ve geri döndürür).

Ne yazık ki, atomik katılım kendi başına çok daha zayıf bir garantidir. Atomik içermeye yönelik bu taahhüt, oluşturucunun, oluşturdukları çapraz toplama bloğunun, onaylanırsa istedikleri sonuç durumunu yaratacağına dair yüksek güvene sahip olması için yeterlidir. İnşaatçı, bloğun ortaya çıkan durumunu mutlaka bilir, çünkü onu inşa etmek için çalıştırdılar.

Ancak hala bir sorunumuz var - diğer herkes durumun kesin olarak ne olacağını nasıl biliyor?

bir örnek düşünün:

• Aynı tembel sıralayıcıyı paylaşan iki rollup (ra ve rb) var.
• Aynı anda ra'da yakar ve rb'de damgalama yapmak için bir yakma ve damgalama köprüsü kullanmak istiyorum.
• RB'deki para basma köprüsü sözleşmesi, RA'da (yakma) RB'de basıma durum geçişi garantisine ihtiyaç duyar, ancak sözleşme, Ra'nın durumuna erişimi olmadığı için tokenin yürütme sırasında gerçekten RA'da yakılıp yakılmadığını bilemez.

Eğer uygun bir demet gönderdikse, tembel sıralayıcı, yanma işleminin ra için işlem akışına dahil edildiğini garanti edebilir, ancak belki de onun önüne geçen başka bir işlemin onu geçersiz kıldığından emin değilsiniz (yani jetonların aslında yakılmadığı anlamına gelir).

Sadece tembel bir sıralayıcının paylaşılması, paket yürütme sırasında zincirlerin birbirlerinin durumlarına erişimini sağlamak için yetersizdir. Eşzamanlı kompozabilite, her bir zincirin durum makinesinin yürütme sırasında diğer zincirin durumuna erişebilme yeteneğini gerektirir (örneğin, rb üzerindeki köprü sözleşmesi, yürütme sırasında ra'nın durumunu bilmelidir). Bu yetenek, tam kompozabiliteyi tek bir entegre zincir içinde mümkün kılan tam olarak budur.

inşaatçı sözleşmelere sadece 'bana güven kardeşim, işler yoluna girecek' diyemez. atomik dahil etmenin arama yapanlar için güzel bir araç olduğunu görüyoruz, ancak çapraz zincir uyumluluğunu soyutlamak için yetersizdir.

Bunu düzeltmek için, paylaşılan sıralamaya ek olarak başka bir mekanizma eklememiz gerekiyor.

Bahsedildiği gibi, yapımcı bizzat paketin atomik olarak dahil edilmesi durumunda oluşacak durumu bilmektedir. Peki, işlemleri dahil edildiğinde oluşacak durum hakkında herkese inandırıcı bir taahhüt nasıl sağlayabilirler?

genellikle iki seçenekleri vardır:

• kripto-ekonomik - inşaatçı, çapraz zincir eylemlerini tamamen teminatlandırmak için büyük miktarda sermaye koyabilir.Bu genellikle verimsiz ve tartışmalı bir şekilde simüle edilmiş bir bileşiklik olarak kabul edilir., ancak işlevselliği göstermek için yararlı bir örnektir.
• kriptografik - istenen durumu üretecek olan işlemlerin kriptografik güvenceler sağlayan bir mekanizmaya sahip olabiliriz.

kripto-ekonomik güvenlik - inşaatçı tahvilleri

Kripto ekonominin senkron bileşebilirliğin etkilerini nasıl simüle edebileceğini görmek için bir örneği inceleyelim. Klasik olarak kullanılan örnek, birinin çapraz zincir flash kredisi. RA'da bir flaş kredi almak, bunu RB'de bir arbitraj için kullanmak ve aynı yuvada Ra'ya iade etmek istiyorum. Bu, buradaki DeFi protokollerinin her iki tarafta da "banka sözleşmeleri" olarak adlandıracağımız özelleştirilmiş zincirler arası işlevsellik dağıtması durumunda mümkündür:

şimdi o güvenlik sorunu için - ra ve rb üzerindeki sözleşmelerin bunu güvenli bir şekilde yapabilmek için birbirlerinin zincir durumlarını bilmesi gerekiyor, ancak buna yönelik hiçbir şey yapmadık. işte buradaki kriptoekonomik “çözüm” aslında oldukça vahşi bir güç kullanımı - süper yapımcının bir likidite sağlayıcı olarak hareket etmesine ve flash kredisinin tam değerini koymasına izin verirsiniz. eğer işlemler başarısız olursa, o zaman kredi protokolü yine de paylarını alır. bu nedenle bu en tatmin edici “çözüm” olmadığını görebilirsiniz.

şifreleme güvenliği - agglayer

ne olduğu

theAggLayerGate.io, üç ana fayda sağlayan merkezi olmayan bir protokoldür:

1. Hızlı zincirler arası birleştirilebilirlik için güvenlik - Aggchains'e eşzamansız veya eşzamanlı olarak çalışırken düşük gecikmede (yani Ethereum bloklarından daha hızlı) atomik zincirler arası birlikte çalışabilirlik için kriptografik güvenlik sağlayan ZK kanıtları üretir. Tasarım, herhangi bir yürütme ortamını destekleyebilmesi ve kanıtlayabilmesi için zincir hatalarını benzersiz bir şekilde izole eder.
2. çapraz zincir varlık değiştirilebilirliği - varlık değiştirilebilirliğini (yani, onu kullanan zincirler boyunca) sağlamak için paylaşılan bir köprüye sahiptir, böylece kullanıcılar sarılı varlıkların bir araya gelmesiyle sonuçlanmaz. köprü sözleşmesi ethereum üzerindedir ki bu dağyerleşim katmanı. (farklı zincirlerin hala uygulamaya bağlı olarak farklı güvenlik varsayımları olabileceğini unutmayın, bu daha aşağıda daha detaylı olarak ele alınmıştır.)
3. gaz optimizasyonu - AggreGate.io'ya katkıda bulunur. Agg zincirleri için sabit maliyetleri birçok zincirde yaymak için kanıtlar. Ayrıca paylaşılan depozito sözleşmesi, L1'e dokunmadan doğrudan L2'den L2'ye transferlere izin vererek gaz maliyetlerini optimize eder.

kaynak: Brendan çiftçi, Toplanmış blok zincirleri

agglayer hakkında yaygın yanlış anlamaları açıklamak için iki yaygın yanlış anlamayı ortadan kaldırmak:

• Agglayer, sadece aggreGate.io kanıtları için bir hizmet değil. - bu gerçekte aggreGate.io kanıtlarını toplar, ve şeyin isminde 'toplama' kelimesini kullanırlar, bu nedenle karışıklık yaratabilir. Ancak, agglayer'ın amacı zincirleri birleştirmektir. Bu gönderinin amacı açısından önemli olan ayrım, kanıt toplamanın yalnız başına burada ihtiyacımız olan güvenlik garantisine ulaşmak için hiçbir şey yapmadığıdır.
• Agglayer ve paylaşılan sıralayıcılar karşıt tasarımlar değildir- birlikte kullanılmaları gerekmez, aslında mükemmel tamamlayıcılardırfarklı garantiler sağlar. agglayer, aggchains'ın nasıl sıralandığı konusunda tamamen agnostiktir. Zincirler arasındaki iletişimi ele almaz, bu nedenle aslında zincirleri oluşturmak için serbest piyasa koordinasyon altyapısına (örneğin, röleler, yapımcılar, izole sıralayıcılar, paylaşılan sıralayıcılar vb.) açıkça güvenir.

Şimdi nasıl çalıştığına birlikte bakalım.

Köprüleme kötü.

Bugün rollup'lar arasında köprü kurmak çok zor. Diyelim ki iki Ethereum umutlu rollup'ı arasında ETH köprüsü kurmak istiyorsunuz._birve oru_b:

• yerel köprü aracılığıyla - pahalı ethereum l1 gaz ücretleri ödeyeceksiniz (yani, oru'dan köprüleme yapmak_bir→ ethereum + ethereum → oru_b), ve tur turu bir haftadan fazla sürebilir (hata kanıt penceresi nedeniyle).
• direct rollup → rollup - oru'da aldığınız sarılı eth_baslında yerli eth ile değiştirilemez olmazdı_bir. farklı köprülerden geçme yoluna bağımlılık, değiştirilebilirliği bozar. Örneğin, ORU_birköprü boşaltıldı, ardından orub'a köprülediğiniz sarılı eth desteklenmeyecek, orada bulunan yerli eth ise desteklenecek_biyi olurdu. Likidite parçalanması kötü, bu yani kullanıcıların istediği bir şey değil. Pratikte, kullanıcılar likidite sağlayıcıları aracılığıyla doğrudan köprü kurar. Birisi sana eth'i önden verecek_b ve paranızı ORU'da tutun_bir. Yerel köprü aracılığıyla çekebilirler ve bekleyebilirler, ancak risk ve yüksek sermaye maliyeti için pahalı ücretler alırlar.

Zk rollup'ların bunu doğru bir şekilde çözdüğünü düşünebilirsiniz, ancak aslında öyle değiller. Naif uygulamalar hala l1 işlemlerini göndermenizi gerektirir, bu da yine pahalı ve genellikle oldukça yavaştır (örneğin, ethereum kesinleşme süreleri, kanıt oluşturma süreleri, uygulamada ne sıklıkta kanıtların gönderildiği vb. nedeniyle).

Kullanıcılar bununla uğraşmak istemiyor. Sadece fonlara sahip olmak ve uygulamaları kullanmak istiyorlar. Köprüleme tamamen soyutlanmalıdır - varlıklar değiştirilebilir olmalı ve hızlı, ucuz ve güvenli bir şekilde hareket etmelidir.

Bu, bir köprü sözleşmesini paylaşmanın devreye girdiği yerdir. Paylaşılan bir köprü sözleşmesi, onu kullanan zincirler arasında l1'i ​​atlamadan doğrudan köprü kurma kapısını açar.

Token'lar sonuç olarak aggchain'ler arasında da değiştirilebilir. Eth'yi 'r'den köprüleme yaparak._bir → r_bveya r_c → r_baynı jetonu yakar ve basar. bu, bir kilit ve basılı bir varlık değildir. yerli eth'tır. bu, tüm varlıkların birlikte rehin alındığı ve birleşik köprü aracılığıyla yerleştirildiği için mümkündür. bu, bugün l2'ler için ele alınması gereken önemli bir sorun noktasıdır.

Ancak, R'de ETH tutan bir kullanıcının_birvs. r_bfarklı zincirler farklı doğrulayıcılar kullandığında (örneğin, güvenli bir zincirden devre hatalı bir zincire geçtiyseniz) farklı bir risk profiline sahip olabilir. risk profilleri, burada ortak standartlar kullanan zincirler arasında değişmez (ki bu pratikte bugün normdur). daha homojen standartlar ve resmi doğrulama, heterojen alanlar eklense bile zamanla bunu yalnızca iyileştirecektir.

karamsar kanıtlar

aggchains, durum güncellemelerini ve kanıtlarını düzenleyen agglayer yatırımlı düğümlere gönderir, tüm mesajlara taahhütler oluşturur ve özyinelemeli kanıtlar oluşturur. agglayer daha sonra tek bir aggreGate.iod zk kanıtı oluşturur (buna " diyorlar)karamsar kanıt") tüm aggchain'ler için ethereum'a yerleşmek için. Buradaki kanıt toplama, keyfi olarak birçok zincirde maliyetleri amorti ettiğinden, en kısa sürede hızlı ödeme için bunları Ethereum'a göndermek maliyet açısından pratiktir. Kötümser kanıt programı, normal pas koduyla yazılmıştır. Succinct'in zkvm sp1 geliştirme kolaylığı ve yüksek performans için.

bu pesimistik kanıtlar zorunlu kılar:

• interchain muhasebesi - tüm köprü sabitlerinin korunduğunu kanıtlar (yani, hiçbir zincir, üzerine yatırılan tokenlerden daha fazlasını çekemez).
• aggchain'lerin geçerliliği - her zincirin durumunu doğru şekilde güncellediğini, zincir eşdeğerlikleri veya geçersiz bloklar olmadan kanıtlar.
• çapraz zincir güvenliği - ethereum gecikmesinden daha düşük sürede gerçekleşen çapraz zincir işlemlerinin durum güncellemelerinin tutarlı olduğunu ve ethereum l1'e güvenli bir şekilde yerleştirilebileceğini kanıtlar. bu, çapraz zincir paketlerin hem senkron hem de asenkron olarak başarılı bir şekilde atomik olarak yürütülmesini içerir.

Bu sayede, agglayer yalnızca yukarıdaki koşulların karşılandığı durumlarda yerleşmenin Ethereum'da gerçekleşmesini sağlar. Koşullar karşılanmazsa ilgili zincirler yerleşemez. Bu nedenle, agglayer, düşük gecikme süresiyle bir koordinatörün (örneğin, paylaşılan bir sıralayıcı veya oluşturucu) bu koordinatöre güvenmelerine gerek olmadan zincirler arasında ileti iletmesine izin verebilir.

hızlı ve güvenli çapraz zincir etkileşimi

AGGCHAIN'ler, diğer toplamalara göre blok geçerliliği üzerindeki kısıtlamaları ifade etmek için hem asenkron hem de senkron birlikte çalışabilirlik ayarlarında burada sağlanan garantileri kullanabilir.

Bu, kullanıcıların her iki tarafta başarıyla atomik olarak gerçekleştirilmesi gereken çapraz zincir demetlerini göndermelerine olanak tanır. Sadece atomik dahil etme değil. Aslında, onların son durumunu başarılı olmalı şekilde zorluyorsunuz. Bu, paylaşılan bir sıralayıcının atomik dahil etme garantilerinde eksik olduğunu açıkça belirttiğimiz şeyi tamamlamak için mükemmel bir uygundur.

kaynak: Brendan çiftçi, Birleştirilmiş blok zincirleri

Örneğimizi önceki örneğimizden alıyoruz:

• iki adet rollup'a sahibiz (r_bir ve r_b) aynı tembel sıralayıcıyı ve agglayer'ı paylaşıyor
• eşzamanlı olarak eth yakmak için bir çapraz zincir paketi gönderiyorum_birve r üzerinde eth bas_b
• Süper bir yapımcı, bunu yaparak her iki zincir için bir blok inşa eder, bu da paylaşılan sıralayıcının taahhüdüdür
• r üzerindeki damga köprü sözleşmesi_b iyimser bir şekilde eth'yi r durumuna bağlı olarak basabilir_bir (bu durumda, ETH yakma işleminin başarıyla gerçekleştirilmesi)
• bu bloklar ve kanıtlar, hem bağımsız olarak hem de birbirleriyle ilgili olarak geçerli bir şekilde hareket ettiğini ve paylaşılan köprünün güvenli bir şekilde kullanıldığını kanıtlayan agglayer'a sunulur

Bu Ethereum'a başarıyla yerleşmesi için demetin her iki ayağı da uygun şekilde yürütülmüş olmalıdır. Herhangi bir taraf başarısız olursa, o zaman bloklar geçersiz olur ve yerleştirilemez. Bu, diyelim ki paylaşılan sıralayıcı bloğu imzaladığında eth'in r'de yakılmadığı bir durumda olduğunu söyler._aancak r üzerinde eth basıldı_bo blok yeniden düzenlenecektir. Bu, tüm zincirlerin güvenliğini sağlar ve sahtekarlık içeren zincirler arası işlemlerin çözülmesini önler.

Bu yeniden yapılanmalarla ilgili olarak akılda tutulması gereken iki nokta vardır:

• Çok kısa olacaklar çünkü hemen tespit edilecek ve kanıtlanacaklar.
• Sadece bağlı olduğunuz zincirin koordinatörü (örneğin, sıralayıcı ve/vaya oluşturucu) etkin bir şekilde kötü niyetli ise gerçekleşebilirler.

bu reorganizasyonlar, yukarıdaki nedenlerden dolayı son derece nadir ve minimal olmalıdır, ancak bu nedenle aggchain'ler atomik olarak hangi zincirlerle birleştirmek istediklerine ve hangi güven varsayımları altında olduklarına tam kontrol sahibi olacaklar. örneğin, r_birr'dan bir zincir durumunu kabul edebilir_bbirlikte çalışmak için kendi sıralama konsensüslerine dayalı olarak oluşturun, ancak r_cbelki de bir kanıt da sunmak isteyebilir ve r için_d Belki de tüm zincirler arası atomik bağımlılıkları kripto-ekonomik olarak güvence altına almalarını istiyorlar. Her zincir, düşük gecikme süresi ve canlılık için burada kendi özelleştirilebilir ödünleşimlerini yapabilir. AGGlayer, zincirlerin güvenli zincirler arası etkileşimlere sahip olması için maksimum düzeyde esnek ve minimum düzeyde inatçı bir temel sağlar.

Burada ayrıca böyle bir tasarımın pratikte neden hataya dayanıklı bir tasarımla uyumsuz olduğunu da görebilirsiniz. Teoride bunu yapabilirlerdi, ancak bu durumda inanılmaz derecede derin yeniden yapılanmalar yaşamak mümkün olurdu. Tüm zincirleri hızlı bir şekilde kanıtlamak ve çözmek, en kötü durumun çok kısa olmasını sağlar ve bu da herhangi bir kötü niyetli girişim için doğal bir caydırıcı görevi görür.

heterojen kanıtlar için hata izolasyonu

Önemli olan, agglayer'ın tamamen heterojen zincirleri benzersiz bir şekilde etkinleştirmesidir. Herhangi bir özel vm, kanıtlayıcı, da katmanları vb. ile birlikte bir köprüyü herkesle güvenli bir şekilde paylaşabilirsiniz.

Bu nasıl mümkün olabilir? Normalde kabul edilemez olmasının nedeni, tek bir hatalı katılımcının (örneğin, devre hatası olan biri) genellikle köprüyü kandırıp tüm fonları boşaltabilmesidir. İşte yukarıda bahsedilen zincirler arası muhasebe kanıtları devreye giriyor. Bu kanıtlar, köprü değişmezlerinin tamamının saygı gösterildiğinden emin olur, böylece sağlam olmayan bir ispatçının bile, etkilenen zincire yatırılan fonlar sadece boşaltılabilir. Hata tamamen izole edilmiştir.

güvenilir tarafsızlık

Bu tür altyapı, güvenilir tarafsızlık tarafından büyük ölçüde yararlanır, bu nedenle fully open-source code ifor agglayer, tarafsız bir bölge olarak hizmet vermektedir.Benzer bir ruhla, Agglayer, kanıt birleştirme için ücretleri ödemek için tek gaz jetonu olarak eth kullanacak.

Yine de kesinlikle mükemmel değil. Özellikle başlangıçta, tamamen güvenilir bir şekilde tarafsız olmayacak. Nihai değişmezliğe ve bir kamu malı olarak kutsanmaya giden yolda sözleşme yükseltilebilirliği olması muhtemeldir.

Bununla birlikte, tamamen güvenilir bir şekilde tarafsız olmak zorunda değildir, hiçbir şey değildir. (Bunu aşağıda temel toplamalarla tekrar göreceğiz.) Uygulamada, muhtemelen en zorlayıcı teknik rekabet vizyonunu sunar ve kilitlenme ve rant çıkarma konusunda kasıtlı olarak minimalist bir tutum sergiler. Amaç, AGGCHAIN'lerin mümkün olduğunca fazla egemenliği korumasına izin verirken, yine de güveni en aza indirilmiş zincirler arası birleştirilebilirliği soyutlayabilmektir.

aggchainlerin belirli bir vm, yürütme ortamı, sıralayıcı, da katmanı, staking tokenı, gaz tokenı veya ortak yönetim ihtiyacı yoktur. Zincirler istedikleri zaman ayrılabilir. Gelir paylaşımı gereksinimleri yoktur. Başka birinin zincirinde bir l3 olarak dağıtmanız gerekmez.

Genel l2lerin üzerinde l3'leri başlatmanın nedenleri çoğunlukla, benim görüşüme göre, agglayer'a benzer mimarilere inşa edilirken pansumanlar olmuştur. Ancak açık olmak gerekirse, bu, onları bugün başlatmanın tamamen geçerli bir nedenidir. V1 agglayer sadece basit bir paylaşılan köprü sözleşmesidir. Kanıt toplama ve güvenli düşük gecikmeli interop alabilme yeteneğine sahip V2 bile yayında değil. En hızlı dağıtımı elde edecek bir şeyi bugün göndermek için aciliyetleri varken yıllar boyunca beklemelerini bekleyemezsiniz.

gerçek zamanlı kanıtlama

düşük gecikme ayarlarında pratik olmaktan birkaç yıl uzak olsa da, gerçek zamanlı ispatın aynı zamanda paylaşılan sıralama ile birlikte çapraz zincir güvenliği için potansiyel olarak kullanılabileceğini belirtmek önemlidir. Ayrıca sadece harika olduğu için kısaca üzerinde duracağız. Daha spesifik olarak, "gerçek zamanlı" ispat, söz konusu zincirin yuva sürelerinden daha kısa olan ispat sürelerine atıfta bulunur. Çapraz zincir madeni para basma ve yakma köprü örneğini tekrar düşünelim:

• İki rollup'ımız var (r_bir ve r_b) aynı tembel sıralayıcıyı paylaşma
• Ra → Rb arasında bir yak ve bas köprüsü kullanmak istiyorum, aynı anda Ra'yı yakar ve Rb'de bastırır.
• süper inşaatçı, bu çapraz zincir işlemlerinin bir demetini içeren bir çapraz zincir bloğu oluşturur. blokların içinde, inşaatçı diğer rollup'ta yer alan durum geçişinin bir kanıtını içerir.

zaten paylaşılan dizgin garantisi olan senkron atomik paket dahil edilmesine sahiptik ve şimdi her bir sözleşme diğer zincirin durumunu doğrulayabilir ve başarılı bir şekilde yürütüleceğini bilebilir.

Gerçek zamanlı ispatlamada, ispatlama süresinin toplam slot süresinin küçük bir kısmı olmasını ideal olarak istiyoruz, böylece 'eşzaman penceresi'ni maksimize ediyoruz. Bu, çapraz zincir senkronize çalışan işlemleri işlemek için yeterli zamanı bütçelemeniz gerektiğinden, slot süresinin bir kısmıdır ve ispatı oluşturmak ve bloğa yerleştirmek için yeterli zamanı ayırmanız gerekmektedir.

kaynak: Justin drake, gerçek zamanlı kanıtlama

Dikkat edin ki, burada yapımcıları ve kanıtlayıcıları örtüştürme veya bir araya getirme konusunda ima yoluyla sonuçlanacağını unutmayın. Yapımcılar için kanıtlama hızlarını optimize etmek için açık bir teşvik var, böylece son saniyeye kadar inşa edebilir ve bloklarına mümkün olduğunca çok şey sığdırabilirler.

kaynak: Justin drake, gerçek zamanlı kanıtlama

Eğer bu gerçek zamanlı kanıtlama için yüksek teşvikler önümüzdeki yıllarda gerçekleşirse, bunun tabii ki merkezsiz kanıtlamaya hiç de dostane olmadığını da belirtmeliyiz. Kanıtlayıcılar, yapımcılarla birleşerek veya bir araya gelerek oldukça merkezi olmaları gerekecektir.

özet

Evrensel eşzamanlı uyumluluk gerçekten harika, ancak gerçekten ne kadar değerli olduğu belirsiz. İnternet tamamen zaman uyumsuzdur ve asla fark etmezsiniz. Çünkü hızlıdır ve karmaşıklık soyutlanmıştır. İşte tüm kullanıcıların istediği budur.

Bir şeyi kullanmanın değerinin büyük bir kısmının senkron ayarlama yapma şeklinde olmayacağını bekliyorum. Bunun yerine, bir tür çapraz rollup zincir soyutlaması olarak hareket edebilme özelliği önemli. Kullanıcı odaklı yönlerle birçok zincirin tek gibi hissetmesini sağlama (örneğin daha fazla değiştirilebilir yerli varlıklar, doğal çapraz zincir uygulama işlevselliği, hızlı uyumluluk vb.).

Eşzamanlı bileşim net bir şekilde finansal olarak değerlidir (örneğin, likidasyonlara izin vererek, daha verimli arbitraj yaparak, flaş krediler kullanarak daha verimli refinansman yaparak). Bununla birlikte, internetin eşzamanlı olmadığı ve yine de gayet iyi çalıştığı gibi, tabii ki tradfi de eşzamansızdır. Tradfi'den daha iyi olmayı istemek makul olsa da, evrensel eşzamanlılığın iyi bir yürütme için bir gereklilik olmadığını net bir şekilde belirtmeliyiz. Eşzamanlı altyapıyı inşa etmenin ve sunmanın gerçek bir maliyeti de var.

Şahsen, USC'ye ihtiyaç duymanın lehine en iyi argümanın, pratikte daha iyi UX ve Devex'e yol açması olduğunu düşünüyorum. Bunun Solana gibi ekosistemlere sağladığı devasa faydayı inkar etmek imkansız. Ancak, bu umarım daha çok bugün bir sorundur ve sonsuza kadar sürecek bir sorun değildir.

Mesele şu ki, şu anda herhangi birinin sebeplendirme yapması da biraz zor. Bu, kriptoda her şeyin senkron olduğu ya da her şeyin asenkron olduğu ikili bir durum değil. Bence temel olarak ikincisini çözmek ve ona doğru yönelmek zorunda kalacağız, ancak her ikisi de ad hoc bir temelde var olabilir.

ethereum tabanlı rollups

Tamam, şimdi toplamalarda parçalanmayı ele almak için çözüm alanı hakkında iyi bir fikre sahip olmalıyız. Bir sonraki soru, temel katmanı tüm bunlara nasıl dahil etmeliyiz? Ethereum'un buradaki rolü nedir?

aşağıdaki kısaltmaları kullanacağız:

• bl - temel katman
• br - tabanlı rollup
• preconfs - ön onaylamalar

Aksi belirtilmedikçe, tartışacağımız söz konusu BL Ethereum'dur ve BRS, Ethereum BRS'dir. Bununla birlikte, BRS'yi herhangi bir yerde başlatabileceğiniz için temel kavramlar geniş çapta geçerlidir.

vanilya tabanlı rollup'lar

birkaç yıl önce yapılan ilk rollup uygulamaları aslında planlanan brs olmak, ama oldular düşük gecikmeli ve yüksek verimlilik için merkezi sıralayıcıların lehine terk edildi. şu anda tabanlı dizilim dediğimiz şeyi vitalik " olarak adlandırdı.tam anarşi"o zamanlar, ethereum'un pbs altyapısının (uzman yapımcılarla) evrimleşmesinden önce oldukça pratik ve verimsizdi."

brs daha sonra 2023 mart ayında yeniden dikkat çekti,tanımlandığı gibi tanımlandıkları yer:

“Bir rollup, dizilimi temel l1 tarafından yönlendirildiğinde veya l1-sıralı olduğunda denir. Daha somut bir şekilde, temel rollup, bir sonraki l1 önericinin, l1 araştırmacıları ve oluşturucuları ile işbirliği yaparak, bir sonraki rollup bloğunu bir sonraki l1 bloğunun bir parçası olarak izinsiz olarak içerebileceği bir rollup'tır.”

şunları sunmalılar:

“bu rollup'ların dizilimi maksimum basitlikle gerçekleşir ve l1 canlılığını ve merkezi olmama özelliklerini devralır. Ayrıca, taban l1'leriyle özellikle ekonomik olarak uyumludurlar.”

Özellikle, ethereum'un gerçek zamanlı güvenliğini elde edersiniz:

"Sansür direncini ve Ethereum'un canlılığını miras alıyorsunuz. Yani sadece Ethereum'un uzlaşma garantilerine sahip değilsiniz, aynı zamanda sansür direncine, gerçek zamanlı sansür direncine de sahipsiniz, kaçış kapağında bildiğiniz gecikmeli değil, gerçek zamanlı olana."

Bir taban katman seçtikten sonra, temel bir rollup olmak mantıklı bir tasarımdır.:

“ethereum bu iki özellik için maksimize ediliyor, güvenlik ve güvenilir tarafsızlık, neredeyse bir rollup'un tanımı gibi ... bir rollup, ethereum'un güvenlik varsayımını zaten satın almış olanlardan biridir. yeni bir güvenlik varsayımı eklemiyorsunuz. en zayıf halkaya düşmüyorsunuz. mevcut güvenlik varsayımını yeniden kullanıyorsunuz. ve ikincisi, ethereum'u bir itibarlı tarafsız platform olarak zaten kabul etmişsinizdir, aksi takdirde başka bir zincir seçerdiniz. ve şimdi kendinize sorabilirsiniz, neden herkes sadece katman bir sıralama kullanmıyor? ”

En basit haliyle, brs kesinlikle yukarıdaki tasarım hedeflerine ulaşabilir. Eğer rollup kendi sıralayıcısını uygulamazsa, o zaman dolaylı olarak mevcut Ethereum önerici, her 12 saniyede (Ethereum'un slot zamanı) nelerin dahil edileceğine karar verir.

Bununla birlikte, tabanlı sıralama hala ödünleşimlerle birlikte gelir, ki bu tam olarak neden rollups genellikle kendi sıralayıcılarını uygular:

• Hızlı ön onaylar - rollup kullanıcıları Ethereum blokları için 12 sn'den fazla beklemek istemiyor.
• güvenli ön onaylar - bazen ethereum blokları yeniden düzenler, bu yüzden kullanıcıların güvende olması için daha da uzun süre beklemeleri gerekir, ki bu da kullanıcıların hoşuna gitmez. dizilimciler, finalleştirilmemiş ethereum bloklarına bağlı olmayan ve bu nedenle ethereum'un kısa süreli bir yeniden düzenleme yaşaması durumunda bile yeniden düzenleme gerektirmeyen ön onaylar verebilir.
• Verimli toplu gönderim - sıralayıcılar çok miktarda veriyi toplayabilir, sıkıştırabilir ve maliyet-optimizasyonlu bir şekilde belirli aralıklarla bl'ye gönderebilir (örneğin, tam blok kullanımını garanti ederek).

temel rollups + önyükleme konferansları

Yani, pastamızı hem alıp hem de yiyebilir miyiz? girintemellendirilmiş preconfs.

Burada temel preconfs mantığını brs + preconfs ile geleneksel rollup'larla karşılaştırabilmek için kısaca açıklayacağız. Daha sonra, genel olarak preconfları daha ayrıntılı bir şekilde analiz etmek için (yani, ethereum l1 işlemlerinde hem br preconfları hem de bl preconfları) geri döneceğiz.

Temel fikir, BR preconf'larının BL önerenlerden gelmesi gerektiğidir. Preconfs sağlamak için, bu teklif sahiplerinin bir miktar teminat koymaları (örneğin, restaking) ve ek slashing koşullarını (yani, sağladıkları preconf'ların gerçekten de söz verildiği gibi zincir üzerinde yapacağı) seçmeleri gerekir. Bunu yapmak isteyen herhangi bir teklif sahibi, bir BR sıralayıcısı olarak hareket edebilir ve preconfs sağlayabilir.

Not: Delegelerin (yani doğrulayıcıların) aslında daha uzmanlaşmış entiteler olarak bilinen “Gate.io yollarına” önceden yapılandırmalar sağlama rolünü üstlenmeleri beklenmektedir. Önceden yapılandırmaları dağıtmak, nispeten sofistike bir entite gerektirecek ve Ethereum, delegelerin sofistike olmamasını istemektedir.

ancak, mevcut rölelerin de bu rolü devralması bekleniyor. Gate.ioway, kullanıcı ve röle arasında sadece arayüz sağlayacaktır, bu yüzden başka bağımsız bir varlık eklemek sadece karmaşıklık ve gecikme ekler (ancak gecikme, birlikte yerleşimle de ele alınabilir). röle zaten yapımcılar ve önerenler tarafından güvenilen bir durumda olduğundan, burada kullanıcılardan onlara başka bir güven gereksinimi eklemiş olacağız.

not edin ki, şu anda doğrulayıcılar ethereum blok önerici olarak hizmet verse de, protokolün kendisi teklif haklarını doğrudan açık artırma yoluyla satma olasılığı da dikkate alınmaktadır.yürütme açık artırmaları. bu, sofistike kuruluşların öneri haklarını doğrudan satın almalarına olanak tanıyacaktır, bu da mevcut önericilerin (şu anda önerilenler) onlara burada düşünüldüğü gibi Gate.io'ya deleGate.io gerek duymadan.

her durumda, önemli olan nokta, herhangi bir önceden hızlı konsensüs olan ethereum'un konsensüsünden (12s) daha hızlı bir güvenilir üçüncü taraf (gütt) gerektirmesidir. gütt'nuzun yeniden kazanılmış bir doğrulayıcı, bahisliİcra Müzayedesi kazanan, deleGate.iod Gate.ioway veya başka bir şey - temelde gerçek zamanlı ethereum güvenliği sağlayamaz. Coinbase size ister Ethereum teklif sahibi olarak "tabanlı bir preconf" ister rollup sequencer olarak "geleneksel bir preconf" veriyor olsun - Coinbase'e güveniyorsunuz. Benzer şekilde bir miktar ETH tahvili koyabilirler, ancak her iki durumda da bu, Ethereum'un konsensüsünün güvenliğinden bağımsızdır.

Dolayısıyla herhangi bir tabanlı ön yapılandırma tasarımının, başlangıçta belirlediğimiz brs'nin (basitlik ve bl güvenliği) belirtilen amaçlarından sapmaması gerektiğini fark etmeliyiz.Tabanlı preconf'lar giderek daha karmaşık hale geliyor, ve ethereum'un gerçek zamanlı güvenlik garantilerini sağlayamazlar.

ancak, bu preconfer'ler çevrimdışı kalırsa veya sansür uygulamaya başlarsa, bir işlemi doğrudan bir bl işlemi yoluyla zorlama yeteneğini korumanız gerektiğini unutmamalısınız. bu garantiler, ethereum'dan daha da güçlü olmalı.dahil etme listeleriuygulanır.

for brs - ttps hızlı ön onaylar sağlar, ve bl nihai güvenlik sağlar.

temelli olmayan rollups + temelli geri dönüş

şimdi bir geleneksel (yani, temel alınmayan) rollup'ı düşünelim. Merkezi veya merkezi olmayan kendi sıralayıcısı hızlı ön onaylar verir. Daha sonra, kullanıcıları gecikmeli olarak tam Ethereum güvenliği elde eder. Bu, bazı türden gelen canlılık (defter büyümesi + sansür direnci) içerir.zorunlu dahil etmeveyaBL yedekmekanizma.

noted inRolluplar güvenlik miras alır mı?:

Rollup'lar, ana zincirleriyle eşdeğer güvenlik özelliklerini doğrulama kuralları sunma yeteneğine sahiptir. En iyi ihtimalle ana zincirlerinin fikir birliği hızında (ve uygulamada, rollup'ların ana zincire ne sıklıkla gönderi yaptığına bağlı olarak genellikle biraz daha yavaş) bu özellikleri alabilirler.

Rolluplar, daha iyi bir kullanıcı deneyimi için bir “mutlu yol” daha gevşek onay kuralı (yani, sıralayıcılar) sunabilir, ancak başarısızlık durumunda yedeklemeyi korurlar. Sıralayıcınız durursa, hareket etmeye devam edebilirsiniz.

not etmekzamanın sonunda güvenlikburada optimize etmek için anahtar değişken

Rollup kullanıcılarının ana zincirde olduğu gibi eşdeğer canlılığa geri dönebileceği varsayımı, rollup sıralayıcısının sansürlediğiniz durumda bir sonraki ethereum bloğunda işlem dahil etmeyi zorlayabileceğiniz şekilde ana zincir bloklarının hızında zorlama işlemi yapabileceğinizi varsayar.

Uygulamada genellikle kısa bir gecikme bulunur. Anında zorunlu dahil etmeye izin verirseniz, maruz kalabilirsiniz.karlı sansür mev diğer karmaşıklıklar arasında. ancak, vardır tasarımlar, yakın zamanda gerçek zamanlı canlılık garantileri sağlayabilirana zincir üzerinden (örneğin, belki birkaç ana zincir bloğunun hızında, bir blok yerine).

bu ruhla,Sovereign labs bir tasarıma sahipaşağıdakileri yapar:

• izinli sıralama - rollup'lar, işlemleri hemen işlenen izinli bir sıralayıcı ayarlar. çünkü rollup'ın durumunda yazma kilitleri olduğundan, bl blok zamanından daha hızlı güvenilir ön onaylar sağlayabilirler.
• Tabanlı Sıralama - Kullanıcılar işlemleri doğrudan BL'lerine de gönderebilirler, ancak bunlar bir N blok gecikmesiyle işlenir (burada n yeterince küçüktür). Bu, "nihai güvenliğe ulaşma süresini" büyük ölçüde azaltır ve aslında bu nedenle tasarıma "yumuşak onaylarla dayalı sıralama" bile diyorlar! (Bu brs tanımının daha önce sağladığımız tanımla çelişeceğini, yani bl teklif sahibinin br'yi sıralama veya onlar tarafından deleGate.iod olma hakkına sahip olması gerektiğini unutmayın.)

non-brs için - ttps hızlı ön onaylar sağlar ve bl olası güvenlik sağlar.

neden ki?

Gördüğümüz gibi, yukarıda tanımlanan her iki yol da aynı etkili sonucu üretir.

Bu br'ler artık Ethereum'un basitliğini veya gerçek zamanlı güvenliğini sağlamıyor. Peki şimdi tüm bunların anlamı nedir? Neden sadece “geleneksel” rollup'ların geri dönüşlerini sıkılaştırmıyoruz? Bu noktada bir “temel rollup” bile ne demek?

bu aslında benim geri dönmemle ilgiliYönetişim kanıtıgeçen yıl tartıştığım Ethereum özel restaking için temel kullanım durumlarını içeren bir gönderi:

1) teknik (teklif sahibi taahhütler) - bunun etrafından başka bir yol yok - eğer bir Ethereum bloğunun düzenlenmesine inandırıcı bir taahhüt istiyorsanız, bu Ethereum doğrulayıcılardan gelmeli.MEV-Boost++bu kovaya düşebilecek hipotetik bir uygulamanın bir örneği.

2) sosyal - bugün çoğu yeniden bahis uygulaması için ethereum hizalamasını ana kullanım durumu olarak görüyorum, ekonomik güvenlik veya merkezsizleştirme havuzlaması değil. demek istemekbak, biz bir ethereum projesiyiz!" zincirlerin kendilerini Ethereum L2'ler olarak adlandırmaya devam etmelerinin nedeni de budur mimariden bağımsız olarak.

Bu, bir "br + preconfs" nin bir "geleneksel rollup + hızlı geri dönüş" üzerindeki değerini sorma bağlamında modernleştirebiliriz.

1) Teknik (teklif sahibi taahhütleri) - Preconfs'lu Ethereum BRS'nin temel bir teknik faydası vardır - mevcut Ethereum teklif sahibinden bir Ethereum bloğunun içeriğinin dahil edilmesi ve sıralanması konusunda güvenilir bir taahhüt alabilirler. Bu, potansiyel olarak bir dizi toplamanın bir sıralayıcıyı paylaşmasını istediğimiz aynı nedenlerden dolayı potansiyel olarak değerlidir. BL önereni aynı zamanda BR önereni (yani, sıralayıcı) ise, sıralayıcıyı paylaşan herhangi bir rollup arasında alabileceğiniz gibi BL ile aynı atomik inklüzyon garantilerini sağlayabilirler. Her iki zincirde de tekelleri var. Şimdi, bu ne kadar değerli? Buna birazdan geri döneceğiz.

2) sosyal (uyum / güvenilir tarafsızlık) - sevin ya da nefret et, Ethereum hizalamabr olmanın bir satış noktası. dürüst olmam gerekirse, taiko hakkında pek bir şey bilmiyorum, sadece 'br adamlar onlar' olarak biliyorum ve eğer br adamlar olmasalardı, onları tanıyamazdım. herkes iyi bir ortak pazarlama istiyor. burada ilk hareket eden olmanın değeri var, ancak bu kalıcı bir değer önerisi değil ve gelecekteki potansiyel br'lerle ilgili birçok şeye geçmiyor. benzer şekilde, ilk birkaç avs hakkında duyduk, ama şu anda olanların hepsini adlandırabilir misiniz? ben yapamam.

Daha yüksek bir seviyede, (varsayımsal) "Optimism Shared Sequencer" veya "Arbitrum Shared Sequencer"ı seçmek için tüm Ethereum rollup'larını alamazsınız. Yine de, hepsinin "Ethereum Shared Sequencer"ı seçmesini sağlamak için daha iyi bir şansınız var. Yeni bir belirteç yok, yeni bir marka yok, yeni bir fikir birliği yok. Tüm Ethereum L2'lerin sıralama konusunda birleşmesinin değerli olduğunu düşünüyorsanız, bu güvenilir tarafsızlık potansiyel olarak bu hedefe ulaşmak için en güçlü noktadır.

Bu güvenilir tarafsızlık, ekosistemler arası kullanıcıları (örneğin, ENS gibi temel altyapıya sahip uygulamalar) çekmeye çalışan RollUp geliştiricileri için muhtemelen en değerlidir. Arbitrum kullanıcılarını yabancılaştıracaksa iyimserlik sıralayıcıyı kullanmakta tereddüt edebilirler veya tam tersi.

her birini aşağıda daha detaylı bir şekilde ele alacağız.

güvenilir tarafsızlık

Sosyal açıdan daha derinlemesine gidersek, br'ler genellikle maksimum olarak kabul edilir. Bu, herhangi bir br tasarımı için inandırıcı tarafsızlık derecesinin yüksek bir ön kabulünü dışarıda bırakarak, herhangi birinin değerlendirmesini yansıtmaz.

Vanilya durumunda, güvenilir bir tarafsız BR tasarlamak kolaydır, ancak kimse bunları gerçekten istemez. Bu nedenle, ön koşullar önerenin ek kesme koşullarına katılmasını gerektirir. Bu ek kesme koşulları, önerenin bazı ek sistemleri kullanmasını gerektirir (örneğin, potansiyel olarak eigenlayer tekrar bahis yapma, )Symbiotic, veya başka bir standart) taahhütte bulunmak için bir rollup seçebilir. soyut bir şekilde krediye uygun 'ethereum sıralayıcı'ya katılmaktan memnun olabilir, ancak muhtemelen krediye uygunluk, özel olarak finanse edilen projeleri kullanıyorsanız kaybolur, belki kendi tokenlarıyla bile.

Teminatla ilgili birkaç açık soru var burada:

Teminat boyutu

erken tasarımlar, öneren kişilerin kişisel olarak inanılmaz yüksek bir miktarda teminat koymaları gerektiğini varsaymıştır, yaklaşık 1000 eth. Sorun şudur ki, temelde bir öneren her zaman Delegate.io'ya sözünü tutmaktan vazgeçebilir ve kendisi bir blok inşa edebilir, önceden belirtilenlerde ikiyüzlülük yapabilir. Bu son derece değerli olabilir ve 1000 eth, mev-boost'un başlangıcından bu yana geçen en yüksek ödemelerin rahatlıkla üzerindedir. Dezavantajı, elbette ki bu, daha küçük önerenler için yüksek bir giriş engeli yaratırken, daha büyük olanlar (örneğin, coinbase) tüm bahis ağırlıklarından ödüller kazanırken 1000 eth koyması daha makul olabilir> Toplam eth miktarının %13'ü stake edildi) çünkü kaydedenler tüm doğrulayıcıları için tek bir teminat verebilirler. var.çok daha küçük bağlara sahip teklif sahiplerine izin verecek diğer fikirler, tabii ki dezavantajlarıyla birlikte gelirler. buradaki tasarım alanı sadece belirsiz.

değerli not etmek gerekir kiyürütme açık artırmalarıBu endişeyi hafifletebiliriz, çünkü tüm teklif verenlerin bunu kolayca başarabilecek kadar uzman oyuncular olduğunu varsayabiliriz.

kaynak: Barnabé monnot, mev-boost'tan epbs'ye aps'ye

Ancak, hatta büyük operatörler bile büyük miktarlar yatırmaktan çekiniyorlar, çünkü kesme sorunlarına neden olan potansiyel canlılık sorunları var (bir operatörün canlılık başarısızlığı, önceden onaylarımızı verip bloğa dahil etmeden önce düşmesi, kullanıcılar için yine de bir güvenlik başarısızlığıdır ve sert şekilde cezalandırılması gerekiyor).

teminat türü

vanilla eth bu durumda muhtemelen tek güvenilir tarafsız teminat. Bununla birlikte, daha sermaye verimli varlıkları kullanma isteği doğal olarak olacaktır (örneğin, steth). Bu dönüşümü bir sigortacının yönetmesi için bazı fikirler var, aşağıda açıklandığı gibi.mteamburada.

platform

Eğer “ethereum tabanlı preconfs” “eigenlayer tabanlı preconfs” veya “symbiotic tabanlı preconfs” gibi ise, bu çok “inanılır olmayacaktır.” Bu yöne gitmeyi planlayan takımlar var, ancak böyle bir platformu kullanmak katı bir zorunluluk değildir. Herkesin kullanabileceği genel ve tarafsız bir standart oluşturmak mümkündür ve böyle bir sistem genel kabul için daha iyi konumlandırılmış görünecektir.

Temel preconf tasarımlarının makul bir şekilde "güvenilir bir şekilde tarafsız" olması için kamu yararı standartlarının benimsenmesi gerekecektir.

ön onay

dahil etme vs. devlet önkoşulları

Şimdi önyüklemeleri daha detaylı bir şekilde ele alacağız. Daha önce belirli bir tür önyükleme konusunu tartışmış olsak da (durumda br önyüklemeler), onların tamamen genel bir kavram olduğunu belirtmek gerekir. BR'lerin yanı sıra BL işlemlerinde de önyüklemeler sunabilir ve farklı güçlerde önyüklemeler sunabilirsiniz:

• dahil preconfs - bir işlemin nihayetinde onchain'e dahil edileceğine dair daha zayıf bir taahhüt.
• state preconfs - bir işlemin nihayetinde onchain'de dahil edileceğine dair en güçlü taahhüt ve sonuç durumunun garantisidir.

Tabii ki, sonraki (devlet ön koşulları) kullanıcıların cüzdanlarına göstermek istedikleri şeydir:

0.0001 ETH ücret ödeyerek 1 ETH'yi 4000 $ USDC için takas ettim

Ön koşulsuz dahil değil:

1 eth karşılığında 4000 usdc takas etmeye çalışan işlemim ve en fazla 0.0001 eth ücret ödemeye çalışan işlemim sonunda onchain'de olacak, ama belki başarılı olur, belki başarısız olur, göreceğiz

Bununla birlikte, çekişmeli olmayan bir durumda gerçekleştirilen kullanıcı eylemleri durumunda (örneğin, yalnızca kullanıcının kendisinin işlemi geçersiz kılabileceği basit transferler) dahil etme ön yapılandırmalarının durum ön yapılandırmaları ile etkili bir şekilde değiştirilebilir olduğunu unutmamalıyız. Bu durumda, örneğin "Alice'in Bob'a USDC transferi sonraki birkaç bloğa dahil edilecek" vaadi, bir cüzdanın kullanıcıya "USDC'nizi Bob'a gönderdiniz" göstermesi için yeterince iyidir.

Beklenildiği gibi, daha güçlü taahhütler (devlet ön konferansları) elde etmek daha zordur. Temel olarak, bunlar gerektirirler: güvenilir taahhütşu anda blokları önerme konusunda tekeli olan varlık (yani, zincir durumu üzerinde yazma kilidi). ethereum l1 önseçimleri durumunda, bu her zaman mevcut ethereum l1 önerici. br önseçimleri durumunda, bu muhtemelen br'nin ileriye bakışında sonraki ethereum l1 önerici olacak (böylece onları br için mevcut önerici yapacak), aşağıda göreceğimiz gibi. önerici ve sıralayıcı genellikle değiştirilebilir terimlerdir, ilk terim genellikle l1 bağlamında daha sık kullanılırken, ikincisi l2 bağlamında kullanılır.

fiyatlandırma ön koşulları

Yapmamız gereken bir diğer büyük ayrım, bu preconf'ların ne tür bir devlete dokunduğudur:

• tartışmasız durum - başka kimse bu duruma erişim gerektirmiyor (örneğin, alice usdc'yi bob'a transfer etmek istiyor)
• tartışmalı durum - diğerleri bu duruma erişmek istiyor (ör. eth/usdc amm havuzunda takaslar)

Preconf'ler, sonuçta üretilebilecek blok üzerinde kısıtlamalardır. Diğer her şey eşitken, yapımcılar için arama alanını kısıtlamak, doğal olarak sadece onların sıralamasından elde edebilecekleri potansiyel değeri azaltabilir. Bu, daha az değerin önerene geri döneceği anlamına gelir. Bu, teşvik uyumlu hale getirmek için, Gate.io'nun sonuca kısıtlama getirmekten kaybedilen potansiyel MEV'den büyük veya eşit bir preconf ücreti alması gerektiği anlamına gelir.

Mev kaybı ~0 olduğunda (örneğin, bir usdc transferinde olduğu gibi) bu yeterince basittir. Bu senaryoda, bazı nominal sabit ücretler talep etmek makul olabilir. Ancak büyük bir sorunumuz var - tartışmalı durumlar için önceden fiyatlandırma nasıl yapılır? Ön ödeme yapmak yerine hazırda beklemek ve doğru fiyatlandırmak daha az ödeme yapacak gibi görünüyor. Diğer her şey eşit olduğunda, bir inşaatçı için en karlı seçenek, mev'yi yakalamak ve doğru fiyatlandırmak için mümkün olduğunca son saniyeye kadar beklemektir.

Ancak, çekişmeli durumlar için hızlı ön onay talebi olduğunu varsayalım (hem sofistike araştırmacıları hem de normie kullanıcıları düşünerek), böylece herkes için faydalı bir temizleme fiyatı olacaktır. Peki, çekişmeli bir durumda bir işlem için ön onay fiyatını nasıl belirlersiniz? Bu durumda, gelecek 12 saniye içinde herhangi bir zamanda dahil edebileceğiniz kârlı fırsatları kaçırma ihtimaliniz olabilir mi?

Çekişmeli durumun yayınlanan blokta ön incelemelerin yapılması, blok oluşturanların nasıl oluşturduğuyla çelişir. Ön incelemelerin doğru bir şekilde fiyatlandırılması, onu şimdi dahil etmenin miyop etkisini gerçek zamanlı olarak tahmin etmeyi gerektirir, bunun için olası sonuçları yürütmek ve simüle etmek gerekir. Bu da Gate.io'nun şimdi son derece sofistike bir arayıcı/oluşturucu olması gerektiği anlamına gelir.

Gate.ioway ve relay'in birleşeceğini zaten varsaymıştık. Eğer sürekli fiyat ön onaylarına ihtiyaçları varsa, o zaman inşaatçıyla da birleşecekler. Ayrıca USC'nin inşaatçı ve doğrulayıcıyı birleştirmeyi hızlandıracağını da kabul ettik. Ayrıca, görünüşe göre...yürütme açık artırmaları teklif haklarını doğrudan onları fiyatlandırabilecek sofistike aktörlere (muhtemelen inşaatçılara) satacaktır.

Bu, Ethereum L1 ve BR işlem tedarik zincirinin tamamını, o dönem için tüm zincirlerin durumu üzerinde tekel yazma kilidine sahip tek bir kutuya koyar.

Ön yapılandırma hizmetinin sipariş politikaları belirsizdir (örneğin, her zaman fcfs çalıştırırlar mı yoksa başka bir şekilde sıralarlar mı). Ayrıca, Gate.ioway'ın tüm ön yapılandırmalar üzerinde bir açık artırma yapması da mümkündür (örneğin, araştırmacıların ön yapılandırmalara teklif vermesine izin vererek), ancak böyle bir tasarımın nasıl olacağı net değil ve bu necessarily daha yüksek gecikme anlamına gelecektir.

Adil Değişim Sorunu

Gate.io'nun gerçekte preconf'ı serbest bırakması için doğrudan bir teşvik olmadığı bir adil takas sorunu var.

aşağıdaki örneği düşünün:

• şu anki Gate.io, 12 saniyelik bir tekel durumunda
• Bir kullanıcı, yuvasının başlangıcında (t = 0) bir ön onay işlem isteği gönderir.
• Gate.ioway, t = 11.5'te tüm önceden yapılan ön onayları bloğa dahil etmek için 500 ms tampon bırakarak, yuvalarında bekler. O zaman karlı olanları dahil etmek ve hariç tutmak için hangi ön onayları dahil edeceklerine karar verebilirler.

Bu senaryoda, kullanıcı, yuvasının sonunda almasına rağmen önceden yapılandırma için ödeme yapabilir. Gate.ioway, dahil etmek karlı olmadığına karar verirse, bunu yuvasının sonunda bırakabilir. Gate.ioway tarafından yapılan bu tutma, nesnel olarak atfedilebilir bir hata değildir.ancak bu nesnel olarak atfedilebilir olabilir).

Aslında, Gate.io'nun ön onayları sona kadar tutmak için bir teşvik var.Bilgi asimetrisinin olduğu yerde, mev vardır. İşlemleri gizli tutmak, bir inşaatçının dünyanın durumu hakkında daha güncel bir görüşe sahip olmasına olanak tanıyarak daha iyi fiyat riski almasına ve MEV'yi yakalamasına olanak tanır. Kullanıcılara verilen ön itiraflar konusunda bir fikir birliği yoktur, bu nedenle Gate.ioway burada sorumlu tutulamaz.

Yerleşik standartlara ihtiyaç duyulacaktıve beklentiler, ön onaylayıcının tüm ön onayları derhal halka açık bir şekilde söylentilere dönüştürmesini bekliyor. Bu, kullanıcılara istediklerini hemen verir ve diğerlerinin bir Gate.ioway'ın beklenen hizmetleri sağladığını görmesine olanak tanır. Gelecekte bunu yapamazlarsa, kullanıcılar onlara güvenmeyecek ve ön onaylar için ödeme yapmayacaklar. Gate.ioway'ın itibarı değerlidir. Bununla birlikte, aynı zamanda olabilir.son derece değerliburada dürüst olmak ve önyargılara geri dönmek

L1 Taban Katmanı Preconfs

Genel prekonf noktalarının dışında, şimdi l1 ön konferansların inceliklerini tartışacağız. Daha önce bahsetmesek de, bunları inşa eden projeler var ve onların br ön konferanslarla etkileşimi önemli olacak.

örneğin,Cıvata Ethereum teklif sahiplerinin blok içerikleri hakkında güvenilir taahhütlerde bulunmalarını sağlamak isteyen böyle bir protokoldür. Kayıtlı teklif sahipleri, kullanıcılardan preconf istekleri almak için bolt sepetini çalıştırabilir, bunları onaylayabilir, ardından bu bilgileri, bu kısıtlamalara uyan blokları döndürebilecek aktarıcılara ve oluşturuculara gönderebilir (yani, teklif sahibinin preconfs verdiği işlemleri içeren bir blok döndürürler).

burada dikkat etmek önemlidir kiBolt v1 Burada açıklanan, yalnızca kullanıcının ön yapılandırmayı geçersiz kılabileceği çekişmeli olmayan durum için basit işlem dahil etme ön yapılandırmalarını destekler. Daha önce tartıştığımız gibi, bunlar sağlanması gereken en basit ve en zayıf taahhütlerdir.

Tüm bu ön konferans ekiplerinin daha büyük hedefleri var (örneğin, devlet öncesi konferanslar, kısmi blok açık artırmaları, slot veya kısmi slot açık artırmaları), peki onları geri tutan nedir?

• sorumluluk - taahhüt ihlalleri, nesnel kesinti için onchain olarak kanıtlanmalıdır. İşlem dahil edilebilirliğini kanıtlamak nispeten kolaydır, ancak slot açık artırmaları gibi diğer taahhütleri nasıl zorlayacağınız net değildir.
• Sermaye gereksinimleri - keyfi taahhütlerde bulunmak, bir taahhüdü ihlal etmenin değerinin keyfi olarak yüksek olabileceği anlamına gelir. Gate.ioways, bunları sağlamak için muhtemelen büyük miktarlarda (örneğin binlerce eth) stake etmeye ihtiyaç duyacaktır. Bunlar pekala bir havuzda toplanabilir, en büyük kuruluşlara (örneğin, büyük ticaret firmaları veya Coinbase) fayda sağlayabilir ve daha küçük kuruluşları dışarıda bırakabilir.
• fiyatlandırma - sürekli akış halindeki durum ön ayarları gibi bir şeyi nasıl fiyatlandıracağımız hakkında birçok açık soru var, hatta bunun mümkün ve değerli olduğuna karar versek bile.
• Ağ katılımı - bu belki de en önemli ve temel noktadır. Bahsettiğimiz gibi, yalnızca durum üzerinde yazma kilidi olan mevcut teklif sahibi, durum ön itirafları gibi taahhütler sağlayabilir. Teorik olarak, teklif verenlerin %100'ü bu sistemi seçebilir ve bunu taklit edebilir. Pratikte bu olmayacak.

yıllık bir takip kaydına sahip olan ve işletmek için son derece karlı olan, daha basit bir ürün olan mev-boost,>92% katılımkontekst için (muhtemelen bu, bunu hesaba katmaz çünkü biraz daha yüksek olabilir)min-bid. yeni bir ön yapılandırma hizmeti kesinlikle çok daha düşük bir katılım oranına sahip olacaktı. Ancak% ~90'a kadar çıkabilseler bile, bu normal kullanıcılar için kullanışlı bir ürün gibi görünmüyor. Kullanıcılara zamanın%10'unda"üzgünüm şu anda ön yapılandırmalar mevcut değil, biraz sonra tekrar kontrol edin." diyemezsiniz.

En iyi ihtimalle, bu durumda durum, sadece sofistike araştırmacılar ve tüccarlar için isteğe bağlı bir araç olacağını hissettiriyor. Belki de o yuva bir teklif veren kişi tarafından seçildiğinde, o yuva için bir taahhüt daha erken almak isteyebilirler. Bu değerli olabilir, ancak burada parçalanma veya kullanıcı deneyimi kilidi yok.

l2 tabanlı rollup öncesi yapılandırmalar

br preconfs, bl önericilerden gelmelidir (bu yüzden "temel" oldukları için). Bu, bazı teminat koymalarını ve ek kesme koşullarına katılmalarını gerektirir (yani, verdikleri br önerilerinin vaat edildiği gibi zincire gireceğine dair). Bunu yapmaya istekli herhangi bir önerici, br sıralayıcı olarak hareket edebilir ve br önceden onaylar sağlayabilir.

Önemli olan, bu br önkoşulları sadece dahil edilme önkoşulları değil, aynı zamanda durum önkoşullarıdır. Bu, br'lerin, Gate.ioways olmak için kaydolan bl önericilere dönen bir sıra belirleme tekelini veren bir tasarıma katıldıkları için mümkündür.

Bugün, her bir slot için bir ethereum doğrulayıcısı önerici olarak hizmet veriyor ve önerici programı her zaman mevcut epok ve takip eden epok için bilinir. Bir epok 32 slot'tan oluşur, bu nedenle her zaman verilen bir zamanda sonraki 32-64 önericiyi biliyoruz. Tasarım, ön yapılandırılmış bu sistemde yer alan br'lerin işlem sıralamalarını düzenleme yetkisini gelecekteki aktif sıralayıcıya (yani, lookahead'teki sonraki sıralayıcıya) vererek çalışır. Gate.io yolları, br zincirlerinin durumunu ilerletmek için imzalamalıdır.

her bir önerici (Gate.io yoluna girmeyi tercih etmemiş olanlar bile) önceden onaylanmış işlemleri içermek için hakka sahiptir ancak zorunluluğu yoktur (yani, Gate.io yoluna girmeyi tercih etmiş olan önericiler). Zaman içinde önceden onaylanmış işlemlerin tam listesine sahip oldukları sürece bir dahil edici olarak hareket edebilirler (önerici, br işlemi olan bir bl veri yığını oluşturabilir ve onları yayabilir).

kaynak: Ethereum sıralaması, justin drake

işlem akışı aşağıdaki gibi çalışır:

1. br kullanıcı, işlemini aşağıdaki görüntüdeki (slot n+1 önerici) bir sonraki sıralayıcıya gönderir.
2. dizgici hemen sonuç durumu için önceden onay sağlar (örneğin, kullanıcı br üzerinde 1 eth karşılığında 4000 abd doları usdc takas etti ve 0.0001 eth ücret ödedi)
3. Bu noktada, herhangi bir Includer, sıralı işlemi içerebilir (Slot N teklif sahibi bunu aşağıdaki resimde yapar)

kaynak: Ethereum sıralama, justin drake

eğer diğer dahil edenler önceden yapılandırmaları dahil etmezse, onları veren sıra dışı olduğunda sıradaki sıralayıcı olarak onları zincir üzerinde basitçe dahil edebilir. Örneğin, yukarıdaki resimde, n yuvası dahil edici, n+1 yuvası sıralayıcının verdiği ön yapılandırmaları dahil etmeme kararı aldıysa, n+1 yuvası sıralayıcısı, n ve n+1 yuvası boyunca verdiği tüm ön yapılandırmalardan sorumlu olacaktır ve n+1 için bl bloğunu gönderdiğinde onları dahil edecektir. Bu, sıralayıcının, aralarında ve son sıralayıcının kim olduğuna bağlı olarak tam süre boyunca ön yapılandırmaları güvenle vermesine olanak tanır.

Yukarıdaki açıklamaları basitleştirmek için, L1 teklif sahibinin bu ön sağlayıcı rolünü yerine getireceğini varsaydık. Daha önce açıklandığı gibi, durumun böyle olması muhtemel değildir. Preconf'ları fiyatlandırmak, tüm BR'ler için tam düğümler çalıştırmak, DOS korumasına ve tüm BR işlemleri için yeterli bant genişliğine sahip olmak vb. için sofistike bir varlık gerektirecektir. Ethereum, doğrulayıcıları çok karmaşık tutmak istiyor, bu nedenle teklif verenler muhtemelen bugün MEV-Boost aracılığıyla tam L1 blok üretimini dış kaynak olarak kullandıkları gibi, Preconf'ları başka bir varlığa dış kaynak olarak kullanacaklar.

Teklif edenler, deleGate.io'yu Gate.ioways'e hem onchain hem de offchain mekanizmaları aracılığıyla devredebilirler ve bunu yalnızca yuvalarından hemen önceye kadar yapabilirler. Daha önce belirtildiği gibi, bu rolün pratikte büyük olasılıkla röleler tarafından devralınması muhtemeldir. Ayrıca, muhtemelen yapımcılarla birleşmeleri gerekebilir.

kaynak: Tabanlı dizilim, justin drake

daha önce açıklandığı gibi, sadece bir varlık Gate.io olabilir. Bir verilen zamanda Gate.io olacak şekilde deleGate.iod. bu güvenilir durum preconfs sağlamak için gereklidir. uis (örneğin, metamask gibi cüzdanlar) sonraki Gate.io kim olduğuna bakar ve kullanıcı işlemlerini oraya gönderir.

ethereum rollups - ne kadar dayanacaklar?

Yeterli arka plan şimdi yerinde - Ethereum rollups tabanlı olmalı mı? Gerçekten burada iki gömülü soru var:

1. birçok Ethereum rollup'ı bir sıralayıcıyı paylaşmalı mı?
2. evet ise, temel bir sıralayıcı olmalı mı (yani, ethereum bl önerenleri ve çevre mev altyapısını içeren)?

Öncelikle, bir dizi paylaşabileceğiniz bir diziyle ilgili olarak dikkate almanız gereken önemli bir nokta vardır. Örneğin, Ethereum önereni en yüksek teklifi verirse bir blok sıralayabilir, ardından başka bir BFT uzlaşısı en yüksek teklifi verirse bir sonraki bloğunuzu sıralayabilir. Bununla birlikte, bu hala tamamen bu diğer zincirlerle senkronize bir şekilde çalışabilen bu ortak açık artırmaya katılan bir zincir gerektirir, bu nedenle kontrol ve esneklikle ilgili bazı ticaret kapıları hala mevcuttur (örneğin, paylaşılan blok süreleri). Sadece kazanan dizinleme varlık kayabilir.

neyse, sadece koşul 1'in sağlandığını varsayalım. Bu noktada, merkezi olmayan bir paylaşımlı sıralayıcıyı kullanmak için yeterli talebin var olduğuna dair ikna edici kanıtlarımız olduğunu düşünüyorum. 'Paylaşımlı yönü' hakkında daha az endişe duyuyor olsalar bile, hazırda satın alınabilen merkezi olmayan bir sıralayıcı hizmetinin inanılmaz bir değeri olduğunu düşünüyorum (aslında burada en büyük değerin bu olduğunu düşünüyorum).

Şimdi, bu paylaşılan sıralayıcı bir Ethereum tabanlı sıralayıcı mı olmalı?

teknik (teklif sahibi taahhütleri)

Ethereum tabanlı bir sıralayıcı kullanmak için güçlü bir teknik argüman görmüyorum. BRS ve Ethereum L1 arasındaki herhangi bir birlikte çalışabilirlik, L1'e karşı güvenilir bir şekilde yürütülememesi (yani, L1 durumunda sürekli olarak bir yazma kilidine sahip olmamak), uzun blok süreleri (12'ler) ve L1 ile etkileşime girmek isteyen BR işlemlerinin daha sonra onunla birlikte yeniden düzenlenmesi gerektiği gerçeği nedeniyle inanılmaz derecede sınırlı olacaktır. Burada bedava öğle yemeği yok. Bu, kullanıcıya yönelik değerli ürünlerin ve diğer harici paylaşılan sıralayıcıların kilidini açmaz.

Benim gördüğüm birincil değer, Ethereum l1'in bu daha büyük kombinasyonel açık artırmaya eklenmesinin, daha yüksek bir toplam değer yaratılmasına neden olabileceği.L1'in daha fazla değer yakalamasına izin verinBu mantığı uç noktaya taşıyarak, muhtemelen dünyadaki her şeyi aynı açık artırmaya koymalıyız. Bu evrensel açık artırma aynı zamanda Taylor Swift konser biletlerini sıralamalı. Henüz tam olarak orada değilim.

Bu, gerçek bir teknik ve sosyal karmaşıklığın olduğunu ve herkesi bu paylaşılan açık artırmaya katmanın gerçek bir maliyetinin olduğunu vurgulamak için sadece bir örnektir. Bence burada yaratılan teorik ek değeri aşan bir maliyeti vardır. Bu amaca yönelik basit ve hızlı bir farklı bir teknik tasarımı kolayca oluşturabilirsiniz (örneğin, sadece bu amaç için oluşturulmuş basit bir hızlı fikir birliği mekanizması bulundurun) ve ethereum l1'in üzerine bağlamaya çalışmıyorsanız. Ayrıca, böyle bir kombinasyonel açık artırma karmaşıklıkta üstel bir artış yaratır.

Uygulamada, bu temel ön yapı gibi görünen preconf mimarisi, ethereum için gerçekten ciddi bir risk oluşturabilir ve mevcut tedarik zinciri biraz kırılgan olduğunda bu potansiyel olarak hızlandırıcı olabilir. Bu, ağın merkezsizleşmesini ve sansür direncini tehlikeye atar - başlangıçta değerli kılan şeylerdir.

sosyal (inandırıcı tarafsızlık)

Ethereum tabanlı bir sıralayıcı için geçerli bir sosyal argüman görüyorum.

Daha önce de belirtildiği gibi, "hizalamanın" ilk BRS için bir satış olduğuna şüphe yok. Sorun değil, ama bunun süreceğini sanmıyorum. İlk BR olmak harika, 8. olmak havalı değil. Başka bir katma değer olması gerekiyor.

Bence, bir Ethereum tabanlı sıralayıcının inandırıcı tarafsızlığı potansiyel olarak o değere sahip. Bu en azından böyle bir tasarım lehine en güçlü argüman olabilir. Merkezi olmayan bir sıralayıcıyı hazırda bekleyen birçok zincir var. Eğer zamanla bu şeyin üstünde yeterli altyapıyı tasarlayabilirsek ve bu, çapraz zincir kullanıcı deneyimini iyileştirirse, o zaman daha da iyi olur. Böyle bir tasarım isteyen projeler arasında, üçüncü taraf protokolüyle herhangi bir tarafı seçmek istemeyen birçokları olduğunu hayal ediyorum. Daha önce belirtildiği gibi, temel bir genel altyapıya sahip bir uygulama zinciri gibi düşünün ve bir rollup istediğinizi varsayalım. (Hayali) arbitrum paylaşılan sıralayıcıyı seçmek ve optimism kalabalığını kapatmak istemezsiniz ya da tam tersi.

Sosyal koordinasyon problemine çözüm olabilecek tek çözümün, Ethereum'un açıkça en güçlü aday olduğu itibarlı tarafsız bir paylaşılan sıralayıcıya sahip olmak olduğuna dikkat edin. Bu hizmetin temel değer katkısı ise itibarlı tarafsızlıkla ilgili yaptığım önceden belirttiğim noktalara daha da fazla vurgu yapılması gerektiğine dikkat edin. Eğer bu hizmetin temel değer katkısı ise, o zaman bu, onu oluştururken inanılmaz derecede yüksek öncelikli bir tasarım hedefi olmalıdır. Kendi kar elde etme amaçlı üçüncü taraf bir protokolün evcil projesi gibi görünürse işe yaramaz. Ethereum paylaşılan sıralayıcısı gerçekten olmalıdır.

Değerli not düşmek gerekir ki, burada "tarafsız" kelimesi "ethereum" için kod olduğu eleştirisi de makul bir eleştiridir. Yani, ana motivasyonu ethereum ve doğal çevresel altyapısına yarar sağlamaktır. Elbette, böyle bir sistem bu taraflara yarar sağlayacaktır. Bu, Eth varlığı için daha fazla değer kazanımı ve Ethereum yapımcıları, röleleri ve arayanları için daha fazla karlılık anlamına gelir.

hızlı tabanlı rollups

hızlı temel katmanlar

Artık Ethereum gibi yavaş bir blok zincirinde BRS'ye sahip olabileceğinizi anlamalıyız, daha hızlı kullanıcı deneyimi için güvenilir ön onaylar ekleyebilirsiniz ve kriptoekonomik veya kriptografik garantiler aracılığıyla zincirler arasında hareket ederken güvenliği bile sağlayabilirsiniz.

Ancak belirtilen gibi, bu şeyi sıfırdan tasarlasak ne olurdu? Mevcut bir zincirin teknoloji borcunun ve kararlarının işlemesi olmadan. Şeyi inşa etmek için açık bir yol nedir…

Daha önce, bir bl için bir br olmanın (örneğin, ethereum gibi) tek teknik nedeninin, önerenin bl ile senkronik atomik dahil olma konusunda zaman zaman inandırıcı taahhütlerde bulunabilmesi olduğunu tartışmıştık.

Ancak, önkoşulsuz bir br olma yeteneğini ciddi bir şekilde tartışmadık. Temelde bunu göz ardı ettik çünkü Ethereum yavaş ve kullanıcılar sabırsız.

o zaman neden hızlı bir bl kullanmıyoruz?

bu, önceden sahip olduğumuz tüm karmaşık kenar durumlarını ve endişelerini neredeyse tamamen çözer. Gate.io'nun canlılık başarısızlıklarına (burada güvenlik başarısızlıkları ile aynı sonucu veren) garip kenar durumlar istemiyoruz, onların vaat edilen önceden yapılandırmalarından geri adım atmalarını (yani, güvenlik başarısızlıklarını) istemiyoruz ve ethereum geri dönüşlerini istemiyoruz. İşte tam olarak bu nedenle fikir birliği var.

da katmanları öldü, sıralama katmanları yaşasın!

tembel dizicilerle ilgili konuşmaların çoğu, onları başka bir veri katmanına aktaran bir rollup dizicisi olarak ele alır. Örneğin, Astria'nın ilk iki rollup'ı,FormaveAlev) astria, rollup'ların verilerini celestia'ya aktaracak olan konsensüs olarak kullanacak.

Bu kombinasyon özellikle güzel bir kombinasyon çünkü Astria tüm sıralama altyapısını sağlarken, Celestia güven-minimized doğrulama sağlar.Veri Kullanılabilirliği Örneklemesi (DAS).

Ancak Astria aynı şekilde Ethereum, Bitcoin, Solana veya istediğiniz başka bir şeyin özgü bir rollup'ını sıralamak için kullanılabilir. Örneğin, Ethereum için bir öncü olarak kullanılmak üzere kurulabilir.

Ancak açık olmak gerekirse, her zincir bir da katmanıdır. Tam düğümler her zaman da için kontrol edebilirler. Verilerin mevcut olduğu her zincirin geçerlilik koşullarının bir parçası olduğundan, uzlaşma her zaman verilerin mevcut olduğunu onaylar. Hafif düğümler, onaylarını kontrol ederken dürüst bir çoğunluğa dayanır. Tek fark, zincirin hafif istemcilerin onaylarını sormak yerine doğrudan da örneklemesi için başka bir seçenek sunup sunmadığıdır.

ancak, belirttiğim gibiRollup'lar güvenlik miras alır mı?, Astria gibi hızlı zincirler teknik olarak DA'lar için yavaş bir yol ekleyebilir (doğrulanabilirliği artırmak için) ve Celestia gibi yavaş zincirler, sıralama için hızlı bir yol ekleyebilir (çoğunluk güven varsayımı ile ve DA'lar olmadan), sözde "hızlı bloklar yavaş kareler”

Özel katmanları (örneğin sıralama veya das) dikey olarak entegre etmek, modüler ve entegre blok zincirleri arasındaki farkı daha da daraltacaktır. Bu, dikey entegrasyon için benzer şekilde geçerlidir.yerleşim katmanıekleyerekZK doğrulayıcı hesapları Celestia'nın temel katmanına.

Ancak, bunları birleştirmek yerine ayrı tutmakta anlamlı bir değer bulunmaktadır. Bu, rollup'ların raflardan hangi özellikleri istediklerini seçmelerine izin veren modüler yaklaşımdır (örneğin, hızlı bloklarla merkezsizleştirilmiş sıralama satın almak istiyorum, ancak das için ödemek istemiyorum veya tam tersi). Araştırmacılar das istiyorlar, ancak kullanıcılar şimdiye kadar sadece hızlı bloklar istemişlerdir.

“bundling hizmetleri olarakhızlı bloklar yavaş kareler“çok düşünceye sahip ve entegre olacak. bu kaçınılmaz olarak karmaşıklık ve maliyet ekleyecektir. yuva uzunluğunun etkisi üzerindeZamanlama oyunları(ve dolayısıyla potansiyel olarak merkezi olmayan) şu anda ethereum üzerinde yaygın olan bir düşünce de dikkate alınmalıdır.

hızlı tabaka katmanı vs yavaş + önceden yapılandırmalar

ancak aynı zamanda sadece astria'yı rollup'lar için bl olarak da kullanabilirsiniz. paylaşılan sıralayıcılar, kendi başlarına brs için optimize edilmiş bls olarak düşünülebilir.

BL'niz hızlı olduğunda, BR'niz ön onaylara ihtiyaç duymaz çünkü kutudan hızlı onaylar alır! Ardından rollup, BR'ler + ön onaylarla zorunlu olarak kaybettikleri BL'nizin gerçek zamanlı güvenliğini alır.

Ön onay olmadan brs aslında bir rollup inşa etmenin en mantıklı yoludur. İşte bu yüzden bugünkü rollup'lar hepsi orada başladı:

Hızlı bloklara sahip bir bl'nin, 'temel rolluplar + önceden onaylar' konusundaki sorunlarımızın çoğunu çözdüğü açıktır. Paylaşılan sıralayıcılar doğal olarak, 'uygulama geliştiricileri sadece hızlı, güvenilir ve merkezsiz bir zincir başlatmak istiyor - onlara nasıl verebilirim?' ilkelerine dayalı bir yaklaşımdan daha fazla oluşturulur. Ethereum gibi daha yavaş bir temel katmana sonradan önceden onaylar eklemeye çalışmak, yukarıda açıkladığımız karmaşıklıklara neden olur.

hepimiz aynı şeyi inşa ediyoruz

modülerlik kaçınılmazdır

Yani, nasıl aggreGate.io modüler zincirlerini bir araya getirebileceğimizi gördük, evrensel eşzamanlı bileşilebilirlik (usc) sağlayarak. Elbette bazı takaslar var, ancak tek bir durum makinesi kullanmaktan çok daha esnekliği koruyarak anlamlı bir birlik derecesini yeniden tanıtıyorlar. Bana göre, büyük çoğunluğu için asenkron bileşilebilirliğin ihtiyacımız olan tek şey olduğu çok çekici bir durum da var. Düşük gecikme süresine, performansa ve iyi bir kullanıcı deneyimine ihtiyacımız var. İnternet asenkron ve bu tüm bunları soyutlama konusunda oldukça harika çalışıyor. Bileşilebilirlik, kriptonun büyük bir değer katkısıdır, ancak bileşilebilirlik ≠ eşzamanlılık.

Esneklik ve egemenlik faydaları bir yana, çoğu insan ölçek için sonunda zaten birçok zincire ihtiyacımız olacağı konusunda hemfikir olacaktır. Bu, birleştirmemiz gereken birçok sisteme sahip olacağımız anlamına gelir, bu nedenle modüler yönlendirme burada kaçınılmazdır.

ethereum + preconfs → solana?

şimdi, buradaki son oyunları karşılaştıralım. özellikle, solana'nın son oyununu ethereum'un son oyunuyla karşılaştıracağız, eğer bu birleşimi ve kullanıcı deneyimini en üst düzeye çıkaran yolunu seçerse temel rollup'lar + ön yapılandırmalar ile.

Bu vizyonda, Ethereum tabanlı sıralayıcıyı kullanan bir grup BR'imiz var. Gate.io yolları, kullanıcılara düşük gecikme ile sürekli olarak öneren-vaad eden (yani, herhangi bir fikir birliği ağırlığı olmadan) önceden yapılandırmaları akıtıyor, sonra Ethereum önericileri bunları ara sıra tam bir blok haline getiriyor. Bu, shred akışı ile solana için önceden açıkladığımız şeye oldukça benziyor!

Yani, bu sadece daha karmaşık bir Solana mı? Buradaki büyük fark yuva zamanlarında.

Ethereum, bunu yavaş bir zincirin üstüne eklemeye çalışmak açıkça ilk bakışta sorunlar ortaya koyuyor:

• Ethereum'un uzlaşısı kullanıcılar için çok yavaş, bu yüzden güvenilir bir hızlı kullanıcı deneyimi elde etmenin tek yolu, isteğe bağlı olarak teklif verenin vaat ettiği önceden yapılandırmalarla. Bugünün ana engeli, devasa doğrulayıcı seti nedeniyle imza birleştirme işlemidir.MaxEBve geliştirilmiş imza birleştirme burada yardımcı olabilir).
• Bu, çok daha uzun teklif veren tekellerle sonuçlanır, daha yüksek teşvikler ve dürüst olmayan bir şekilde hareket ederek daha fazla MEV'yi ele geçirme özgürlüğü sağlar (örneğin, ön itirafları durdurmak).
• Eğer Gate.io başlamaya gecikirse veya önceden onayları tutarsa, o zaman kullanıcılar için en kötü senaryo, Ethereum slot sürelerine bağımlı olmaktır. Hatta Solana blok üreticileri, ayrılmış tekel alanları içinde sürekli blok oluşturmayı ve yayınlamayı durdurmuş olsa bile.Aynı tam nedenle bazı derecede yapmak akıllıca olabilir.), en kötü durumda hızlı dönen bir uzlaşıya güvenerek geri dönülür.Ağ güvenilirliği için bugün dört yuvalı tekel gereklidir..
• Uygulamada, en azından başlangıçta, solana gibi zincirlere kıyasla daha merkezi bir işletmeci seti sağlayan inanılmaz derecede az Gate.io yolu olması muhtemeldir.
• Önericiler için potansiyel olarak inanılmaz derecede yüksek teminat gereksinimleri (tasarım alanının hala bir çalışma aşaması olduğuna dikkat edin).
• Burada canlılık sorunlarıyla ilgili endişelerin son derece maliyetli olduğundan endişe duyuluyor (çünkü operatör canlılık sorunları, düşürülen ön onay miktarına yol açarak kullanıcılar için güvenlik başarısızlıklarına neden olur ve bu nedenle ağır bir şekilde kesilebilir).

Tüm bunlar hızlı bir fikir birliği ile çözülür. Tüm bu sistemler, BFT sistemlerini ilk kez yapmamızın nedenidir. Öyleyse Ethereum'un fikir birliğini neden daha hızlı yapmamalı? Süper düşük gecikmeli taban katman blok süreleri ile bazı daha az açık tradeoff'lar var mı?

Neyse ki, daha iyi yapacak bir şeyim olmadığından, daha kısa blok sürelerinin iyi olup olmadığına dair bir makale yazmak için zamanım var. Kısa yuva süreleri ile ilgili büyük endişe, doğrulayıcı ve işletmeci merkezileştirilmesi ile ilgilidir. Özellikle, kısa yuva sürelerinin etkileşimi ile ilgili endişeler vardır.zamanlama oyunları:

Zamanlama oyunlarının zaten Ethereum'da ilerlediğini görüyoruz. Teklif verenler daha sonra slotlarında bloklar öneriyor ve başkalarının pahasına daha fazla para kazanıyorlar. röleler de sunuyor "hizmet olarak zamanlama oyunları“ burada da blokları slotun sonraki aşamasında benzer şekilde geciktiriyorlar:

kaynak: Veri her zaman

zamanlama oyunları, biraz ün kazanmış bir konu üzerinde büyük bir tartışma konusu oldu.Justin vs. toly bankless podcastbirkaç hafta önce:

örnek olarak diyelim ki herkesten 100ms daha hızlısın

1s yuvalarınız varsa, herkesten %10 daha fazla kazanabilirsiniz

Eğer 10 saniyelik yuvalarınız varsa, herkesden %1 daha fazla kazanabilirsiniz

— Jon Charbonneau (@jon_charb)4 Haziran 2024

Justin çoğunlukla zamanlama oyunlarının bir sorun olacağını ve artımlı ödüllerin her zaman ilgili olacağını iddia etti. Toly çoğunlukla zamanlama oyunlarının bir sorun olmayacağını ve ek MEV çıkarılmasından elde edilen artımlı ödüllerin endişe edilecek kadar yeterli olmadığını iddia etti.

Ben kişisel olarak burada oyunların zamanlamasının önemini görmezden gelmeyi zor buluyorum:

• Bugün Ethereum'da uygulamada gördüğümüz gibi, onları zaten görüyoruz.Solana tartışmasıbu sadece ethereum'da mev'nin sosyal olarak normalleştiği için oluyor, ancak bu, zaten olduğunda ikna edici değilzamanlama oyunlarına karşı güçlü bir kamu tepkisio zamandan beri kabul görmüş durumdabu yeni gerçekliğin etrafında tasarlanması gerekiyor.
• mev ödülleri önemlidir - zaten bahsediyoruz milyarlarca dolarlık mev ödemeleri burada, kanepe minderinin altındaki kuruşlar değil. Bundan "sadece yüzde birkaç daha fazla" yapmak bile çok büyük bir para.
• Hatta stakerların marjinal olarak yeterince getiriye hassas olmadığına inanmasanız bile, gerçek operatörler işletmeleri yürütüyorve bu da doğrudan onların gelirlerine gider.
• Solana için daha kolaydır, fedakar büyük paydaşlara güvenmek.ancak (örneğin, vakfı ve büyük yatırımcıları) yaşam döngüsünün daha erken bir aşamasında destekleyen bir ölçekte büyüdü.bu, ağ daha da merkezi olmadıkça sürdürülemez.

Kesinlikle Solana ve Ethereum'un izlediği yönde büyük bir değer olduğunu düşünüyorum. En azından, her şeyin pratiğinde nasıl oynandığını görmek için hepsini izleyeceğiz. Stratejik olarak, Ethereum'un burada farklı kılan şeye odaklanması mantıklı geliyor. Sansüre karşı direnç elde etmek için merkeziyetsizleşmeyi maksimuma çıkarmak. Ethereum, uzun vadeli oyun için bir gereklilik olduğu için son derece merkeziyetsiz bir protokolü korumak için birçok fedakarlık yapmıştır. Eşsiz müşteri çeşitliliği, ağ sahipliği dağılımı, ekosistem paydaşları, operatör merkeziyetsizleşmesi ve daha fazlasına sahiptir. Gelecekte (ve muhtemelen ne zaman) Solana ciddi sansür baskısıyla karşılaştığında, Ethereum'un bu kararları neden verdiği giderek daha da açık hale gelecektir.

preconf.wtf geçen hafta Zuberlin'de olanları oldu ve belki de şaşırtıcı olmayan bir şekilde herkes preconfs ve temel rollups hakkında konuşuyordu. ve bu gerçekten de harikaydı. ama ben kişisel olarak buldum Vitalik'in konuşmasıüzerindedüğüm başına bir bitli dahil edici listelerve barnabé'nin konuşmasıYürütme teklifini aşırı yükleyin (mev-boost'tan epbs'ye)ethereum'ın geleceği için en önemli olmak.

kaynak: Barnabé monnot, Mev-boost'tan epbs'ye ve aps'ye

ön konferans ve tabanlı rollup konuşmaları son zamanlarda hız kazanmaya başladı ve ben kesinlikle daha temkinli tarafında kalıyorum. Vitalik ünlü aşağıdaki gibi belirtti.Son Oyun:

Ancak, daha güçlü sansür korumaları olan dahil etme listeleri gibi önlemleri henüz uygulamamış olsak da, merkezi üretim"e oldukça derinlemesine geçtik. Temelde Ethereum bu resmin altındaki alt sıranın yarısında. (Yarısını diyorum çünkü sansür aslında siyah beyaz değil ve Ethereum'un sadece "zayıf sansür"ü var, yani çoğu ama tüm bloklar sansürlenmiyor, bu yüzden biraz bekleyebilirsiniz, ancak sonra dahil edileceksiniz):

kaynak: Yönetim kanıtı

Deneysel olarak, ethereum l1 mev tedarik zinciri şu anda merkezi sıralayıcılarla herhangi bir l2'den daha fazla bloğu gerçek zamanlı olarak sansürlüyor.

l2'ler zaten tabanı olmadan l1'in sonunda cr'sini (ki hala çok iyi) alabilir. Tabana dayalı ön yapılandırmalar, ethereum protokolünün gerçek zamanlı güvenliğini değil, etrafındaki nispeten merkezi altyapı sağlayıcılarının küçük bir avuçluk gerçek zamanlı güvenliğini alırlar. Daha iyi gerçek zamanlı cr için en iyi seçenek, muhtemelen basit bir bft uzlaşması çalıştıran bir tür merkezi olmayan sıralayıcıya sıralama dış kaynak kullanmaktır. Bu, birçok zinciri şu anda nispeten merkezi bir darboğaza merkezileştirmekten çok daha sağlam olacaktır. Bu durum, yürütme müzayedeleri ve dahil etme listeleri gibi değişikliklerle iyileşebilir, ancak bu tam olarak köşede değil.

Tüm bunlar göz önüne alındığında, bana göre ethereum l1'in mev altyapısına olan bağımlılığın genişletilmesi ve ardından l2'ler için bu altyapının pekiştirilmesi, çoğu ethereum bloğunu inşa eden ve ileten bir avuç insan olduğunda, çoğu ethereum'un sansürsüz blokları bugün tek bir inşaatçıya (titan) dayanmaktadır ve henüz hiçbir cr aracı protokole uygulanmamıştır. Bu durum kırılgan bir noktada agresif bir ivmelenme hissi veriyor. Ethereum kesinlikle l2'lerin kullanıcı deneyimini iyileştirmek için çalışmalı, ancak ilk etapta istediğimiz tüm temel özelliklerin maliyeti olarak değil.

sonuç

hepimiz aynı şeyi inşa ediyoruz.

Evet, bir bakıma. Açıkçası, bu şeyler tam anlamıyla aynı şey değil. Bu sistemler arasında her zaman pratik farklılıklar olacaktır. Ancak, kripto para birimlerinde genel eğilim açık bir şekilde giderek benzer mimarilere yaklaştığımızdır.

Aradaki incelikli teknik farklılıkların pratikte nereye gittiklerinin anlamlı sonuçları olabilir ve bu sistemlerin benzer son oyunlara doğru yaklaşırken bile yol bağımlılığının ne kadar büyük bir rol oynadığını küçümseyemeyiz.

Ayrıca, bazı şeyler hakkında neredeyse lanet olası bir şekilde mantıklı düşünmek imkansız.Vitalik'in söylediği gibi:

“Aps için bir not olarak, teknik açıdan bakıldığında aslında oldukça hafif olduğunu ve teknik hata olasılığının oldukça düşük olduğunu düşünüyorum... ancak ekonomik açıdan bakıldığında yanlış gidebilecek çok daha fazla fırsat olduğunu düşünüyorum...

Eip-1559 gibi, teorik olarak çözebildik. Bazı güzel ekonomi konferanslarına gittik ve ilk fiyat açık artırmalarının tehlikelerini ve nasıl kötü olduklarını öğrendik, ikinci fiyat açık artırmaların inandırıcı olmadığını ve sonra keşfettik, hey, her blok içinde yerelleştirilmiş sabit fiyat mekanizmasını kullanalım ve mikroekonomi ile birçok şey yapabildik.

ancak aps öyle değil, değil mi? Ve aps'nin citadel veya jane street veya justin sun ya da herhangi birinin tüm ethereum bloklarının %1'ini mi yoksa %99'unu mu üreteceği sorusu, birinci prensiplerden çok çok zor, belki de imkansız bir şekilde anlaşılamaz.

Benim bu noktada görmek istediğim şey canlı deneyimdir… Benim için, bugün ve gerçekten aps konusunda derinlemesine rahat hissetmem arasındaki fark, bir Ethereum l2 üzerinde başarılı bir şekilde çalışan aps'lerin, orta düzeyde bir değere, etkinliğe, topluluğa ve gerçek bir çekişmeye sahip olması ve bunun bir yıl boyunca devam etmesi, belki daha uzun bir süre için, ve bizim gerçekten bazı canlı sonuçları görebilmemizdir.

Yani evet, ben de ne olacağını bilmiyorum. Bekleyip görmemiz gerekecek. Her halükarda, hepimiz bu oyunsonu ne olursa olsun yakınlaşırken, olmamasından çok daha fazla ortak noktamız var, bu yüzden lütfen emin olalım...

feragatname:

1. Bu makale şu adresten yeniden basılmıştır: [Veritabanı Yöneticisi]. orijinal başlığı 'hepimiz aynı şeyi inşa ediyoruz' olan metni iletiliyor. Tüm telif hakları orijinal yazar [jon charbonneau]'a aittir. Bu yeniden baskıya itirazlar varsa, lütfen Gate.io öğrenekip, ve onlar hızla halledecekler.
2. sorumluluk reddi: bu makalede ifade edilen görüşler yalnızca yazarın kişisel görüşleridir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirileri, Gate.io öğrenme ekibi tarafından yapılır. Belirtilmedikçe, çevrilmiş makaleleri kopyalamak, dağıtmak veya kopyalamak yasaktır.