Çeşitli toplama çözümlerinin vizyonuna ve yol haritasına baktığımızda, hemen hemen tüm toplamaların nihai bir hedefi olduğunu görürüz: Bu hedef tek bir cümleye sığdırılırsa: bir teknoloji yığını oluşturmak, topluluğa sağlamak, blok zinciri ve nihayetinde teknoloji operasyonları ve yönetişim yığınının ademi merkeziyetçiliği. Bu, merkezi olmayan toparlama terimine yol açar.
Peki ademi merkeziyetçilik tam olarak nedir? Toplama sisteminin çeşitli bölümleri arasındaki işbölümü nedir? Ademi merkeziyetçilik, sistem operasyon katılımcılarını en üst düzeye çıkarmak anlamına mı geliyor? Merkezi bir sıralayıcının nasıl bir etkisi olacak? Paylaşılan sıralayıcı ve L2 yerel fikir birliği nasıl tasarlanmalıdır? ZK-Rollup'taki benzersiz kanıtlayıcının işlevi nedir? Açık, merkezi olmayan bir kanıtlayıcı ağı nasıl görünürdü? Neden zk donanım hızlandırmasına ihtiyacımız var? Veri kullanılabilirliği sorununun çözümü nedir? ....
Toplulukta merkezi olmayan Toplama hakkında sonu gelmeyen tartışmalar var, bu nedenle ECN "Merkezi Olmayan Toplama" temasıyla bir dizi podcast röportajının küratörlüğünü yaptı ve bu alandaki seçkin kurucuları ve araştırmacıları merkezi olmayan Toplama anlayışı hakkında konuşmaya davet etti.
Katman 2 platformuna giderek daha fazla likidite aktıkça, yalnızca genel amaçlı toplama çözümleri, uygulamaya özel toplama zincirleri değil, aynı zamanda hizmet olarak toplama platformları da dahil olmak üzere, giderek daha fazla toplama hizmeti sağlayıcısı ortaya çıkıyor. Bu nedenle, giderek daha fazla insan, neredeyse tüm toplamalarda çok kritik bir rol olan "sıralayıcının" hala merkezileştirilmiş olduğundan endişe duyuyor. Merkezi bir sıralayıcının riskleri nelerdir? Merkezi olmayan bir ayırıcı acil bir iş midir?
**İkinci bölümde AltLayer Network'ün kurucusu Yaoqi Jia'yı, Scroll araştırmacısı Toghrul Maharramov'u ve Starknet Keşif Lideri Abdelhamid Bakhta'yı merkezi olmayan ayırıcılar konusunda bir yuvarlak masa tartışması yürütmeye davet ettik, böylece izleyiciler ve okuyucular merkezi olmayan ayırıcıların mevcut bazı ilerlemelerini ve ikilemlerini anlayabilir. **
Bu sayının konukları:
AltLayer Network'ün kurucusu Yaoqi Jia, twitter @jiayaoqi
Starknet Keşif Lideri Abdelhamid Bakhta, twitter @dimahledba
Geçmiş
Sorun 1: Toplama nasıl dağıtılır?
Tahkim araştırmacısı Patrick McCorry
Ön izleme
Sorun 3: Prover ağı ve zk donanım hızlandırması
Ye Zhang, Scroll'un kurucu ortağı
Cysic'in kurucu ortağı Leo Fan
Sorun 4: Veri Kullanılabilirliği ve Merkezi Olmayan Depolama
Qi Zhou, EthStorage'ın kurucusu
Dinlemek
Daha fazla bilgi edinmek için podcast'e abone olmak için tıklayın:
Youtube:
Mikrokozmos:
zaman damgası
00:49 Yaoqi kendini tanıtır
01:37 Abdülhamid kendini tanıtır
02:50 Toghrul kendini tanıtır
04:03 Toplamada sıralayıcının rolü
08:37 Merkezi olmayan sipariş veren: Kullanıcı deneyimini iyileştirme ve canlılık ve sansür sorunlarını ele alma
19:43 Starknet ayıklayıcıyı nasıl dağıtacak
22:59 Scroll, sıralayıcıyı nasıl dağıtacak?
26:34 Optimistic toplama ve zkRollup bağlamında L2 fikir birliği arasındaki fark
32:28 zkRollup, sıralayıcıyı dağıtır ve kanıtlayıcıyı da dikkate alması gerekir
36:01 Temel toplama nedir?
40:53 Paylaşılan sıralayıcı ve tabanlı toplamanın dezavantajları ve bunların uygulama senaryoları
49:02 Merkezi olmayan bir sipariş verenin MEV üzerinde nasıl bir etkisi olacak?
Misafir tanıtımı
Yaoqi
AltLayer'ın kurucusuyum. AltLayer, geliştiricilerin yalnızca bazı düğmeleri tıklayıp parametreleri yapılandırdığı bir "Hizmet Olarak Toplama" platformu oluşturuyor. Başlatma rampamızı veya kontrol panelimizi kullanarak uygulamaya özel toplamaları dakikalar içinde hızla başlatabilirler. Geliştiricilere ortak bir yürütme ortamı ve işlevsellik sağlamak için şimdi yapmaya çalıştığımız şey bu. Ayrıca, geliştiricilerin aralarından seçim yapabileceği birden çok sıralayıcı, birden çok sanal makine sistemi ve çeşitli kanıtlama sistemleri sağlıyoruz.
Abdelhamid
Starkware'de çalışıyorum ve keşif ekibinin lideriyim. Bu grubun amacı temel olarak araştırma benzeri ancak mühendislik odaklı açık kaynaklı projeler başlatmaktır. Amacımız, toplulukla ve diğer ekosistemlerden insanlarla yakın işbirliği içinde açık kaynak projeleri üzerinde çalışmaktır. Böyle bir proje, aslında bir Starknet sıralayıcısı olan Madara'dır. Yalnızca Starknet genel ağı için bir aday değil, aynı zamanda Starknet uygulama zinciri ve Layer3 için bir sıralayıcıdır. Bu aynı zamanda bir önceki konuğun söyledikleriyle de bağlantılı, ayrıca bir hizmet işlevi olarak toplama sağlamayı düşünüyoruz, insanlar Starknet uygulama zincirlerini kullanıma sunabilir ve biraz modüler bir şekilde farklı veri kullanılabilirliği çözümleri seçebilirler. Bundan önce, esasen EIP-1559'un çalışmasından sorumlu olarak dört yıl Ethereum çekirdek geliştiricisi olarak çalıştım.
Seçenek
Scroll'da bir araştırmacıyım ve Scroll'daki ana sorumluluklarım protokol tasarımı, köprü tasarımı, ademi merkeziyetçilik, teşvikler, bu tür şeyler. Bu yüzden, etrafta tweet atmadığım zamanlarda, çoğu zaman sadece protokolün veya emir verenlerin, kanıtlayıcıların, bunun gibi şeylerin nasıl merkezileştirileceği üzerinde çalışıyorum. Starkware gibi, üzerinde çalıştığımız şeylerden biri de bir toplama SDK'sı. Böylece Scroll tabanlı bir rollup yayınlayabilir, farklı veri kullanılabilirlik seçeneklerini modüler olarak kullanabilirsiniz. Hala, Scroll SDK'ya dayalı toplamaların, her bir toplamanın yerelleştirmeyi kendi başına halletmesini gerektirmeden, yerelleştirmeye ulaşmalarına yardımcı olmak için Scroll'un sıralayıcısını kullanabilecekleri bir seçeneği düşünüyoruz. Tabii plan henüz kesinleşmedi. Ancak bu aynı zamanda üzerinde çalıştığımız yön.
Röportaj bölümü
birinci konu
Toplamanın sıralayıcısını açıklayın?
Abdelhamid
Sıralayıcı, katman2 mimarisinde çok önemli bir bileşendir, bu bileşen kullanıcılardan işlemleri alır, ardından bunları paketler ve bloklar halinde demetler, işlemleri yürütür vb. Katman2 aynı zamanda işlem bloklarına sahip bir blok zinciri olduğundan, bu çok kritiktir çünkü blok oluşturmaktan sorumlu bileşendir. Sipariş verenler bu blokları oluşturur ve kanıtlayıcılar bu blokları onaylar.
Yaoqi
Abdel'in belirttiği gibi, sipariş veren, blok zincirindeki birçok işlevin bir kombinasyonudur. Bu nedenle, sipariş verene artık tipik bir genel blok zincirine kıyasla çok fazla sorumluluk veriyor olabiliriz. Öncelikle kullanıcılardan gelen tüm işlemleri toplaması ve ardından bu işlemleri gaz fiyatına veya ilk gelen alır esasına göre sıralaması gerekir. Daha sonra sıralayıcının bu işlemleri yürütmesi gerekir. Şu anda olduğu gibi, bazı Layer2'ler EVM kullanıyor (Starware'in farklı bir sanal makinesi var), ancak temel olarak sıralayıcının işlemleri yürütmek ve durum oluşturmak için özel bir sanal makine kullanması gerekiyor. Ardından işlem bir ön onay aşamasına ulaşır; bu, bir veya iki saniyelik veya hatta saniyenin altında bir onay süresi görürseniz, bunun temelde sıralayıcı tarafından tamamlanan bir ön onay durumu olduğu anlamına gelir. Ardından, çoğu sıralayıcı için, L1'e kontrol noktaları veya durum karmaları yüklemeleri veya yayınlamaları gerekir. Bu, veri kullanılabilirliği dediğimiz L1 seviyesindeki onaydır. Yani sıralayıcı aslında toplama sisteminde birçok role sahiptir. Ama genel olarak rollup sisteminin en kritik bileşeni olduğunu düşünüyorum.
** Konu 2 **
Merkezi olmayan bir sıralayıcı neden önemlidir? Merkezi bir sıralayıcı kullanırsak, kullanıcılar ve sistem için gizli tehlikeler nelerdir?
Seçenek
Her şeyden önce, şu anki aşamada Fuel V1 dışında gerçek bir toplama olmadığını bilmemiz gerekiyor çünkü diğer toplamaların hala eğitim tekerlekleri var.
Ancak rollup olarak sınıflandırıldığında multi-sig'in kaldırıldığı anlamına geldiğini söyleyebiliriz. O zaman sıralayıcı ademi merkeziyetçilik sorunu, bir güvenlik sorunu değil, bir kullanıcı deneyimi sorunu haline gelir. Yani insanlar, diyelim ki, L1'in ademi merkezileştirilmesinden söz ettiğinde, sorun tamamen farklıdır. Çünkü L1, sipariş veren ve hafif müşteriler için garanti vermek zorundadır. Bu nedenle, hafif bir istemci durumun doğru olduğunu doğrulamak istiyorsa, L1 doğrulayıcılarına güvenmelidir. Toplama için durum böyle değil. Çünkü sıralayıcı yalnızca geçici sıralama sağlar ve bu daha sonra L1 tarafından sonlandırılır. Toplamaların sansüre dayanıklı olması da garanti edildiğinden, bunun gerçekleşmesi için merkezsizleşmeye ihtiyacımız yok.
Bu nedenle, merkezi olmayan bir sıralayıcıya ihtiyaç duymanızın birkaç nedeni vardır. İlk olarak, diyelim ki L1 sonlandırma yavaşsa (ya gönderdiğiniz geçerlilik kanıtlarının çok yavaş olması ya da iyimser toparlama dolandırıcılık kanıtlarının meydan okuma süresi mekanizması nedeniyle), hızlı işlem onayı elde etmek için bir şeye güvenmeniz gerekir. Hızlı onaylamanın bu aşamasında, Starkware veya Scroll'un sizi yanıltmayacağına güvenebilseniz de, blok onaylandıktan sonra yeniden düzenleme yapılmayacağını belirtirler. Bu bir güven varsayımıdır. Ve ademi merkeziyet bazı ekonomik garantiler ekleyebilir vb.
Ancak buna dayanarak, toplamanın da gerçek zamanlı kesinlik garantisi yoktur. Temel olarak, işlem paketlemesini L1 aracılığıyla zorlayabilirsiniz, ancak bu işlemi paketlemek saatler alır. Örneğin, güncellemeden sorumlu bir oracle varsa ve süre dalgalanıyorsa, temel olarak oracle bir saat veya daha fazla güncellenirse, rollup'taki uygulamalar kullanılamayacaktır. Temel olarak, ademi merkeziyetçilik, sansüre karşı daha güçlü, gerçek zamanlı garantiler sağlamamıza izin verir, çünkü o zaman bir düşmanın yalnızca bir veya bir avuç varlığı değil, tüm sipariş verenler ağını tehlikeye atması gerekir.
Bu nedenle, bizim için ademi merkeziyetçilik, daha çok kullanıcı deneyimini iyileştirmeye veya kehanet güncellemelerinin köşe durumunu düzeltmeye yönelik bir çözümdür. Temel güvenlik garantileri sağlamak yerine, L1'in yaptığı budur.
Abdelhamid
Evet, bahsettiğiniz merkezi olmayan sıralayıcı ile ilgili soru, çok önemli olduğunu düşündüğüm merkezi olmayan L1 ile tam olarak aynı değil. Çünkü bazı L1'lerin merkezi sıralayıcıları eleştirdiğini gördüğümüzde, merkezi sıralayıcıların yaptığı değiş tokuşlara düzgün bir şekilde bakmıyorlar.
Bu temelde, kullanıcı deneyimiyle ilgili, etkinlikle ilgili bir şeyler eklemek istiyorum. Çünkü yalnızca tek bir sıralayıcınız olduğunda, sıralayıcının çökme riski daha yüksektir. Bu nedenle, merkezi olmayan bir sipariş veren, ağdaki esnekliği ve canlılığı da artırır. Ancak merkezi bir bağlamda bile, güvenlik söz konusu olduğunda iyi bir güvenliğe sahibiz. Çünkü paket işlemlerini L1 üzerinden zorlayabildiğiniz zaman, ikisi arasındaki fark sadece zaman çizelgesidir. Toghrul'un da belirttiği gibi, merkezi olmayan bir sıralayıcıya sahip olmak, hızlı sansüre dayanıklı garantilere sahip olmanızı sağlar. Bu nedenle, canlılık için merkezi olmayan bir sipariş ağına sahip olmanın da önemli olduğunu eklemek istiyorum.
Yaoqi
Bir şey eklemek istiyorum. Etkinlik muhtemelen bu aşamada dikkate almamız gereken en önemli şeydir. Optimism ve Arbitrum gibi en popüler L2'lerdeki en son airdrop vakalarında bir aksama süresi yaşandı. Bu nedenle, bence çözmemiz gereken şey, yalnızca bir sıralayıcımız varken saniyede binlerce işlem talebini nasıl ele alacağız. Teoride bile, yalnızca bir düğümünüz varsa, aynı anda bu kadar çok isteği gerçekten karşılayamaz. Dolayısıyla, canlılıkla ilgili olarak, kesinlikle birden fazla ayırıcıya ihtiyacımız var. Tek hata noktası gerçek bir engeldir, sadece Web3 için değil, Web2 bile büyük bir problemdir.
Bunun ötesinde sansür meselesi var. Yalnızca bir koordinatörümüz varsa, bunun ekip tarafından yürütülebileceğini görsek bile, yine de ekibin işlemleri fiilen incelemeyeceğini kanıtlamanız gerekir. Bazen kötü niyetli tarafların belirli işlemleri kara listeye alması mümkün ve yeteneklidir. Bu, merkezi olmayan bir sipariş sistemidir, ayrıca diğer sipariş verenler aracılığıyla işlem göndermeyi deneyebilirler. Bu yüzden son zamanlarda tek sıralayıcılar hakkında çok fazla eleştiri alıyoruz.
Bunun ötesinde, MEV ve erken çalıştırma gibi başka sorunlar da var. Özellikle DeFi protokolleri için merkezi sıralayıcılara sahip bir sistemde mempool'u kolayca kontrol edebilirler. Muhtemelen bir lider şeklinde değiller, ancak ticareti takip etme ve tahkim etme şansları daha yüksek.
Bu sorunların birçoğu, çeşitli nedenlerle, L2'nin L1'den çok farklı olduğunu görmemize rağmen. Ancak nihayetinde, onu mümkün olduğunca merkezi olmayan hale getirmemiz gerekiyor. Bu nedenle, halka açık blok zincirleri veya L1 ile sahip olduğumuz benzer sorunlardan bazılarıyla yüzleşmek zorundayız.
Abdelhamid
Evet, merkezi olmayan bir sıralayıcının önemli olduğuna katılıyorum. Ama hepimizin bildiği gibi bunun kolay bir soru olmadığını da söylemek istiyorum.
Ayrıca **çünkü toparlamalar, birden fazla varlığa sahip çok özel bir mimariye sahiptir. Bahsettiğimiz tek bir sipariş veren var, ancak bir de kanıtlayıcı var ve ikisini de merkezileştirmemiz gerekiyor. **Ağı çalıştırmak için farklı faktörler gerektiğinden, bazı takaslar ve işlemlerin nasıl fiyatlandırılacağı konusunda bazı zorluklar olacaktır. Peki, anlaşmayı nasıl fiyatlandırıyorsunuz? Sıralayıcı ve kanıtlayıcının farklı donanım gereksinimleri vardır, kanıtlayıcının süper güçlü bir makineye ihtiyacı vardır vb. Bu nedenle, merkezi olmayan bir dünyada fiyatlandırma işlemleri de çok zor bir sorundur, bu nedenle yavaş yavaş ilerlemek için zamana ihtiyacımız var.
Yani hepimiz böyle bir değiş tokuşla karşı karşıya kalacağız.Hızlı bir şekilde ademi merkezileşmek istiyorsak, bazı eğitim çarkları alıp kademeli olarak ademi merkezileşmemiz gerekebilir, çünkü doğrudan mükemmel bir mimari istiyorsak, bu birkaç yıl alacaktır. Bu yüzden pragmatik bir yaklaşım benimseyeceğimizi ve kademeli olarak adem-i merkezileşmeye çalışacağımızı düşünüyorum. En azından şu anki planımız bu, örneğin basit bir BFT konsensüs mekanizmasıyla başlayıp kısa vadede başka bir konsensüs mekanizması falan eklemek gibi. Bu yüzden sadece söylemek istiyorum, bu kolay bir soru değil. Çünkü geliştirme hızı ile mimarinin merkezi olmayan bir ortama ne kadar uygulanabilir olduğu arasında açık bir denge vardır.
Konu 3
Sıralayıcı nasıl dağıtılır?
Abdelhamid
Dağıtmak istediğimiz birçok özellik var ve hepsinin farklı ödünleşimleri var.
Örneğin, ademi merkeziyetçilik yaparken, bir tür mutabakat mekanizması getirmek istiyorsunuz. Ancak mutabakat mekanizmasında birden çok kısım vardır. İlki lider seçimidir, yani blokları kimin oluşturacağının, belirli bir alanda veya belirli bir süre içinde blok oluşturmaktan kimin sorumlu olacağının nasıl seçileceği. **Starknet ekibinin yapmayı planladığı şey, katman 1'i mümkün olduğunca kullanmaktır. Yani lider seçim algoritmamızda 1. katmanda stake yapmak istiyoruz. Örneğin, jetonlarımız var ve rehin, lider seçim mekanizmasını belirlemek için kullanılan katman1 Ethereum'un akıllı sözleşmesinde gerçekleşecek. **Bu, L2 sipariş sahibinin kimin bir sonraki lider falan olacağını bilmek için Ethereum akıllı sözleşmesini sorgulayacağı bir etkileşim kurmamız gerektiği anlamına gelir. Yani belli ki bir tür rastgelelik ve başka şeylere ihtiyaç var. Yani basit bir soru değil. Ama bu ilk kısım. O zaman mutabakatın kendisi için bir mekanizmaya sahip olmanız gerekir. Birden fazla seçenek vardır: en uzun zincir mekanizması veya BFT veya ikisinin bir karışımı. Ethereum gibi, kesinlik için LMG Ghost ve Casper FFG'ye sahiptir.
Bu yüzden pragmatik bir yaklaşım benimseyebilir ve önce BFT ile başlayabiliriz. Neden? Layer2 ademi merkeziyetçiliği ele aldığında, hedefimiz Layer1 kadar büyük bir sorter ölçeğine sahip olmak değildir. Örneğin, Ethereum'da amaç, katılan milyonlarca doğrulayıcıya sahip olmaktır. Bu durumda sadece BFT mekanizmasını kullanamazsınız çünkü verim açısından çok kötü olur ve çok büyük sorunlara neden olur. Örneğin Bitcoin ağında bir sorun varsa, bu bir BFT mekanizmasıysa zincir tamamen durur. Ancak durum böyle değil, Bitcoin ağı bloklar oluşturmaya devam ediyor, sadece kesinlik mekanizması saldırıya uğruyor.
Ancak katman 2'de, hedef birkaç yüzden 1000'e kadar sıralayıcı ise, bir BFT mekanizmasıyla başlamak iyi olabilir. Yani, lider seçim mekanizmamız var, sonra mutabakat ve sonra iki bölüm daha var ama eklemeye devam etmeyi diğer konuklara bırakacağım. Ancak diğer iki bölüm, durum güncellemeleri ve kanıt oluşturmadır.
Seçenek
İlk olarak, L2'de, Abdel tarafından tanımlandığı gibi, ademi merkeziyetçilik çok yönlü bir sorundur. Özellikle zkRollup'ta kanıtlayıcılar ve sipariş verenler olduğu için aralarında koordinasyon sağlamalısınız, ikisini de dağıtmalısınız. Bu problem L1'den tamamen farklıdır.
Diğer bir fark ise, L2'de tüm tasarımınız, herhangi bir sayıda başka düğümü ikna etmek için değil, temeldeki köprüyü fikir birliğinin doğru olduğuna ikna etmektir. Elbette aynısını yapmalısınız, ancak asıl odak noktanız köprünün kendisi olmalıdır.
Şu anda iki farklı yönde çalışıyoruz. Birincisi, bence herkes gibi biz de bir BFT protokolü üzerinde çalışıyoruz. Bu çok verimli değil ve üzerinde çalışılması gereken bazı karışıklıklar var. Kabaca bir çözüm bulduk ama yine de optimal değil. Örneğin, sorulardan biri, ayıklayıcılar ve kanıtlayıcılar arasındaki teşvikleri nasıl dengeleyeceğinizdir. Siparişi veren MEV'yi kontrol ettiğinden ve kanıtlayıcının MEV'ye erişimi olmadığından, insanların kanıtlayıcı yerine siparişi vereni çalıştırması için bir teşvik vardır. Ama gerçekte, sipariş verenden çok kanıtlayıcıya ihtiyacımız var, o halde ikisi arasındaki teşvikleri nasıl dengelersiniz? Bu da o sorunlardan biri.
Üzerinde çalıştığımız ikinci çözüm başka bir yön. Unutmayın, işler değişebilir. Her gün yeni teklifler çıkıyor. Örneğin, son zamanlarda temel toplama ve sıralamayı nasıl tamamen L1'e yaptırabileceğiniz hakkında çok fazla konuşma yapıldı. İkinci yön, temel olarak sıralayıcıyı tamamen ortadan kaldırmak ve bazı harici oluşturucular kullanmaktır. Örneğin, ethereum oluşturucuları veya Flashbots SUAVE vb. sıralı bloklar önerir ve ardından kanıtlayıcı içinde fikir birliği yürütür. Buradaki avantaj, teşviklerle uğraşmak zorunda kalmamanızdır çünkü temelde PBS'yi protokol içinde kullanabilirsiniz ve daha basit bir protokol oluşturur. Ancak dezavantajı, çok sayıda kanıtlayıcıya ihtiyacımız olduğu için (çünkü paralel olarak kanıtlayabiliriz), bunlarla klasik bir BFT protokolünü çalıştırmak oldukça zordur. Öyleyse soru şu ki, mevcut bir BFT protokolünü yüzlerce, hatta binlerce kanıtlayıcı ile çalışacak şekilde nasıl optimize edersiniz? Ve bu cevaplaması kolay bir soru değil.
Merkezi olmayan bir sipariş veren için L2 mutabakatının getirilmesi gerekli midir?
Yaoqi
Bu soruyu kabaca cevaplayabilirim çünkü yakın zamanda böyle bir şeyi piyasaya sürdük.
Dolayısıyla fikir birliğini getirip getirmemek, isteyip istemediğimize bağlı değildir. Çok sayıda sipariş vereniniz veya hatta yalnızca düğümünüz olduğunda, onları kabul ettirmeniz gerekir. Bu gerçekten varsayımlarınıza bağlı. Bu bir Bizans varsayımıysa, BFT'yi veya mevcut herhangi bir Bizans konsensüs protokolünü kullanabiliriz. Bizans dışı bir kurulumsa, örneğin, bir düğümün yalnızca çevrimiçi ve çevrimdışı olabileceğini ve kötü niyetli davranamayacağını varsayarsak, o zaman Raft protokolünü veya daha hızlı başka bir mutabakat protokolünü kullanabiliriz. Ama her neyse, eğer bir emir veren veya ispatlayan grubumuz varsa, onları belirli bir süre boyunca bloklar üretmek için birlikte organize etmek istiyorsak, o zaman onlar etrafında bir fikir birliği protokolüne sahip olmanız gerekir.
Dolayısıyla, Toghrul ve Abdel'in az önce bahsettiği gibi, merkezi olmayan bir sıralama veya kanıtlama sistemini nasıl uygulayabileceğimize dair pek çok teklif ve araştırma konusu olduğuna inanıyorum. Bu nedenle, çok sıralayıcı toplama sistemi için bir test ağı başlattığımızdan (şu anda yalnızca Optimistic toplamalar için sahtekarlık kanıtlarını desteklemektedir), tasarım ve uygulama deneyimimize dayanarak, zorluklar hakkında paylaşabileceğim bazı şeyler var. Toghrul'un az önce bahsettiği gibi, zorluk mutabakat protokolünün kendisinde değil, asıl zorluk bundan başka, ispat kısmı gibi şeylerde yatıyor. Çünkü tek bir sıralayıcı ise çok sayıda düğüme ihtiyacınız yoktur. EVM yani sanal makine gibi düşünebiliriz. Yani, sadece işlemleri getirin ve yürütün, durum geçişleri yapın. Kanıtlayıcı, önceki işlem kümesinin durum geçişi için kanıtlar üretmekten sorumludur. Bununla birlikte, toplamada harmanlayıcı ve kanıtlayıcı için fikir birliği protokolünü çalıştırırsak, o zaman burada ek fikir birliği mantığı uygulamamız gerekir. Bunun da ötesinde, mutabakat protokolü için bir ispat sistemine de ihtiyacınız var. Bu nedenle, bu, ispat sisteminin üretmesi için çok fazla iş getirecektir. Ardından kanıtı oluşturduğunuzda, L1 Ethereum'da kolayca doğrulayabilirsiniz.
Bu nedenle, bir şekilde, ilk çok siparişli test ağını başlattığımızda, iyimser toplamanın bu açıdan bazı avantajları vardı. Genel olarak geçerlilik ispat kısmını dikkate almamak gibi bir çok şeyi basitleştirebilirsiniz. Bizim gibi temelde her şeyi WASM ile karşılaştırırız. Yani sonuçta bu bir WASM talimatı. Dolayısıyla, bu WASM talimatlarını doğrulayarak, Solidity kodunu kullanarak doğrulama yapmak nispeten kolaydır. Tüm WASM talimat yorumlarını Ethereum'da yeniden uygulasaydık.
Ancak genel olarak sorun tekil değildir. Buna bağlı olarak, soruna bir çözüm bulursak, aynı zamanda çözülmesi gereken başka bir takip çalışması olacaktır. Elbette MEV'i nasıl adil dağıtacağız gibi MEV sorunları olacak. Bir blok oluşturup oluşturmadıklarına veya bir bloğu doğrulayıp doğrulamadıklarına bağlı olarak tüm sipariş verenleri ve doğrulayıcıları atayabilirsiniz. Ama sonuçta, sadece teknik değil, aynı zamanda ekonomik teşvikler de dahil olmak üzere birçok sorunun bir kombinasyonu.
Ve gaz maliyetini önemli ölçüde azaltmak istediğimiz için L2'nin önerildiğini hatırlamamız gerekiyor. Yani çok fazla düğümümüz olamaz. Kanıt üretirken bile L2, L1'den daha pahalı olabilir. Bu nedenle, bu tür bir soruna gerçekten dengeli bir yaklaşım bulmalıyız.
Abdelhamid
Bir noktayı daha eklemek isterim. İlk olarak, şu anda iyimser toparlamalar için gerçek bir izinsiz dolandırıcılık kanıtı yok. Bunu her fırsatta vurgulamaya devam ediyorum çünkü karşılaştırma yaparken bu konuda dürüst olmak önemlidir. Yani hiç L2 değiller. İlk şey bu.
Sonra sıralama ve provalar arasındaki uyumsuzluk hakkında bir şeyler eklemek istiyorum, çünkü bu çok önemli. Dediğiniz gibi sıralamayı optimize etmek istiyoruz çünkü şu anda bu tüm çözümler için bir darboğaz. Ancak bu, merkezi bir sıralama bağlamında sorun değil, çünkü sıralayıcının yalnızca değer geçişleri üreteceğini biliyoruz ve bunları doğrulayabileceğiz. Ancak merkezi olmayan bir sıralama bağlamında daha zor olacaktır, çünkü belki de ayıklayıcınız doğrulanamayan bir şey üretebilir. O zaman bununla daha sonra ilgilenmen gerekecek.
Merkezi sıralama bağlamında, sıralamayı optimize etmek için, sıralama işlemi sırasında ispatlar oluşturmak zorunda olmadığımız için bunu yerel hızda yapmayı deneyebiliriz, yapmak istediğimiz de bu. Kahire'yi LLVM gibi düşük seviyeli bir makine diline çevirin ve sıralayıcıda süper hızlı çalışın. O zaman asenkron olarak kanıtlayabilirsiniz. Ve ispatlarla ilgili en harika şey, onları paralel olarak yapabilmenizdir. Özyinelemenin mümkün olduğunu kanıtlayarak büyük paralelleştirilebilirlik elde edilir. Bu yüzden sıralayıcının hızına yetişebileceğiz. Ancak merkezden dağıtıldığında bu zordur, çünkü sipariş verenin yalnızca geçerli durum geçişleri üretmesini sağlamamız gerekir.
Seçenek
Starknet'in burada ne yaptığından emin olmadığımı da ekleyeceğim. Ancak bizim için, sanırım her zkRollup'ın genel bir varsayımı, sıralayıcıyı dağıtırsanız, ispat sisteminizin geçersiz yığınları işleyebilmesi gerektiğidir. Dolayısıyla, temel olarak, diyelim ki, geçersiz bir imzayla bir parti gönderirseniz, ortaya çıkan durumun başlangıç durumuna eşdeğer olduğunu kanıtlayabilmeniz gerekir. Yani her iki şekilde de bir miktar ek yük olacak. Bu, bunun olma olasılığını nasıl en aza indirdiğinizle ilgilidir.
Abdelhamid
Evet bu doğru. Bu nedenle, her şeyi doğrulanabilir kılmak için Kahire 1'de Sierra'yı tanıttık. Bu ara temsil, bir geri alma işlemini dahil edebilmemiz için her Cairo 1 programının doğrulanabilir olmasını sağlayacaktır.
Tabanlı toplama nedir?
Yaoqi
Temel toplama, orijinal olarak Justin Drake'in Ethereum forumlarındaki bir blog gönderisinden geldi. Fikirlerinden biri, bazı Ethereum doğrulayıcılarını toparlama işlemlerini doğrulamak için yeniden kullanabileceğimiz, böylece farklı toparlama işlemlerini doğrulamak için ayrı bir düğüm grubuna ihtiyacımız olmaması. Özellikle gelecekte, genel amaçlı toplamalar ve uygulamaya özel birçok toplama dahil olmak üzere birçok toplamaya sahip olacağız. Dolayısıyla, bu durumda, bu işlemleri doğrulamak için Ethereum doğrulayıcı havuzu gibi ortak bir yer bulabilirsek harika olur.
Tabii ki, bu sadece bir fikir çünkü aynı zamanda pek çok teknik zorluk da getiriyor. Örneğin, teoride, Ethereum doğrulayıcılarının toparlama işlemlerini doğrulamasını isteyebiliriz, ancak toparlamaları doğrulama mantığını Ethereum protokolünün kendisine gömülü veya paket haline getirmek çok zordur. Buna Ethereum düğümlerinden oluşan bir hard fork gerektiren protokol içi doğrulama diyoruz. Tabii ki, bu durumda, bazı toplama işlemlerini doğrulayabiliriz. Ama yaparsak, sorunlar görürsünüz. Sanki L2'nin toparlamasının Ethereum'un baskısını paylaşmasını istiyor gibiyiz, ama sonunda yine de Ethereum onaylayıcılarından L2'ye yüklenen işlerin bir kısmını üstlenmelerini istiyoruz. Pek çok insan bunu nasıl yapabileceğimizden bahsediyor.
Daha sonra Ethereum Vakfı'nda şu anda PBS üzerinde çalışan bir araştırmacı olan Barnabe ile konuştuk. Bu, doğrulayıcıların görevini birden çok role, oluşturucuya ve teklifçiye bölmek olan Ethereum'un bir önerisidir. Artık PBS'de inşaatçı rolünü üstlenecek Flashbot'larımız var, tüm blokları oluşturuyorlar ve bunları Ethereum teklifçilerine gönderiyorlar. Dolayısıyla, bu bloklar Ethereum ağına paketlendiğinde, inşaatçılar da bazı ödüller alacak. Öyleyse bu durumda, bu doğrulayıcıları Ethereum ağından nasıl ödüllendirebiliriz? Toplama doğrulamasından da sorumludurlar.
Çözümlerden biri, EigenLayer veya diğer bazı protokollerden çok duymuş olabileceğiniz "yeniden alma" dır. Kullanıcılar, ETH'yi diğer sıralama ağlarında yeniden stake edebilir. Veya toplama için doğrulama işini yapmak üzere yazılımı gerçekten çalıştırdıkları için Ethereum doğrulayıcılarını ödüllendirin. Bu durumda, hem L2'den hem de yeniden staking protokolü aracılığıyla ödüllendirilebilirler. Bunun için şimdiye kadar birçok teklif geldi, ancak genel olarak bu, mevcut Ethereum doğrulayıcılarının nasıl yeniden tasarlanabileceğine dair bir fikir. Yeni bir toplama veya L2 sistemleri çağını başlatmak için mevcut ETH'yi nasıl yeniden kullanabiliriz? Yani temelde toplama projesi için pek çok şeyi basitleştirmeye çalışıyor. Toplama, yeni bir sıralayıcı istiyorsa, yeni bir teminat kaynağı istiyorsa, mevcut altyapıyı veya mevcut teminatı yeniden kullanabilir. Bu yüzden Ethereum üzerine inşa edilmiştir ve daha sonra daha fazla altyapı ve staking, toplama ve L2 için de yeniden kullanılabilir.
Paylaşılan sıralayıcı ve tabanlı toplamanın dezavantajları ve bunların uygulama senaryoları.
Seçenek
Bu tekliften şikayetçi olmak istiyorum, paylaşılan sıralayıcı ile ilgili teklife ikna olmadım. Tabii henüz emekleme aşamasındalar ve gelecekte bu tasarımlar gelişirse, onları desteklemem tamamen mümkün. Sadece şu anki form bana inandırıcı gelmiyor. Bir çok neden var.
İlk olarak, bana göre, paylaşılan bir sıralayıcının ana değer önerisi, kullanıcıların Scroll veya Starknet gibi genel amaçlı toparlamalar arasında atomik birleştirilebilirlik kazanmasına izin vermektir. Ancak sorun şu ki, atomik birleştirilebilirliğe sahipseniz, toplamanız, birleştirdiğiniz en yavaş toplama kadar nihaidir. Dolayısıyla, Scroll'un Optimistic Rollup ile birleştiğini varsayarsak, Scroll'un son hali yedi gün olacaktır. ZKRollup'ın ana değer önermesi, nispeten hızlı bir kesinlik elde etmek olsa da, kullanıcılar dakikalar içinde L1'e çekilebilir. Ve bu durumda, temelde bundan vazgeçin.
Diğer bir dezavantaj ise, zincir dışı kesinlik istiyorsanız, bir L2 düğümü çalıştırmanız gerekir ve zincire gönderilen veriler L1 tarafından sonlandırıldığı sürece, yerel olarak L2'de kesinlik elde edersiniz. Her bir birleştirilmiş L2, tam bir düğüm çalıştırmazsa, yerel sonlandırmaya ulaşmak pratik olarak imkansızdır. Bu, bu sistemi çalıştırmanın Solana gibi bir sistemi çalıştırmaktan daha pahalı olabileceği anlamına gelir, çünkü aynı anda çalışan birden fazla tam düğümünüz vardır, kendi ek yükleri vb.
Bu nedenlerden dolayı, L2 için mantıklı olduğunu düşünmüyorum. L3 için biraz farklı çünkü birisi uygulamaya özel bir zincir oluşturmak istiyorsa ve ademi merkeziyetçilikle uğraşmak istemiyorsa. Diyelim ki bir oyun yapıyorum ve sadece oyunu inşa etmekle uğraşmak istiyorum, o zaman merkezi olmayan işleri dışarıdan temin edebilirim. Ama şu anda L2 için mantıklı olduğunu düşünmüyorum.
Temel toplamaya gelince, benim de endişelerim var. Örneğin, MEV'in kârını kanıtlayıcılarla nasıl paylaşıyorsunuz? Çünkü tahsis sorunu dikkate alınmaz ise, temel olarak L1 tüm MEV karlarını elde edebilir. Başka bir küçük şey de, onay süresinin L1'in onay süresine eşit olması, ki bu daha hızlı olamaz, 12 dakikadır. Başka bir sorun da, izinsiz olduğu için, birden çok Arayıcının aynı anda toplu işlem gönderebilmesidir, bu da merkezi sonuçlarla sonuçlanabileceği anlamına gelir. Çünkü inşaatçılar, bir araştırmacı diğerlerinden daha kolay bağlanırsa işlemlerini dahil etmeye teşvik edilir. Bu nedenle, sonunda sadece bir Arayıcı'nın L2 için gruplar önermesiyle sonuçlanabilir, bu çok iyi bir çözüm değildir, çünkü bu olursa, temelde başa döneriz.
Yaoqi
İlginç bir şekilde, aslında geçen hafta Espresso'nun kurucusu Ben ile bir telefon görüşmesi yaptım. Paylaşılan sıralayıcılar konusunda bunu çok tartışıyoruz. Toghrul'un da belirttiği gibi, paylaşılan bir sipariş sistemi için kullanım senaryoları hakkında bazı belirsizlikler olduğunu düşünüyorum. Bunun başlıca nedeni, genel amaçlı bir L2 için verimlilik, karmaşıklık ve ekonomi nedeniyle genellikle çok sayıda ayırıcıya sahip olmamamızdır. Ve yine de, ister paylaşılan bir sıralayıcı, tabanlı toplama veya yeniden alma için olsun, en iyi kullanım durumunun çoğunlukla RAS (Hizmet Olarak Toplama) veya çok sayıda toplama sunabileceğimiz bu tür platformlar için olduğunu düşünüyorum. Çok fazla toplama yoksa, dürüst olmak gerekirse, büyük bir sıralama ağına gerçekten ihtiyacımız yok. Bu toplamaların zaten kendi sıralayıcı sistemleri vardır ve yalnızca bazı genel L2'ler olduğunda zaten kendi toplulukları veya ortakları vardır. Gerçekten ayrı ve üçüncü taraf bir ağa sahip olmaları gerekmez. Ayrıca, her L2 için özelleştirme yapmanız gerektiğinden ve her L2'nin farklı bir test yığını olduğundan, bu üçüncü taraf ağ üzerinde bir yüktür. Bu, kendi ağınızda birçok değişiklik gerektirir.
Ama aynı zamanda, Toghrul'un bahsettiği gibi, bazı özel kullanım durumları için. Örneğin, sıralayıcı düzeyinde biraz birlikte çalışabilirlik istiyorsak, paylaşılan sıralayıcılar potansiyel bir yol olabilir. Örneğin, birden çok toplama için aynı sıralayıcı kullanılır. Bu durumda, bu sıralayıcı, A, B ve C toplaması arasında zincirler arası atomikliği sağlamak için temel olarak bazı çapraz toplama işlemlerini işleyebilir.
Ama durumu anlattığımda sorunu burada da görebilirsiniz. Bu paylaşılan sıralayıcılardan gerçekten çok sayıda olsaydı, yine bir darboğaz ve yeni bir tek başarısızlık noktası haline gelirlerdi. Bu sözde ortak düzenleyicilere çok fazla güç veriyoruz. Birçok toplamayı kontrol eden bir ağ gibi hale geliyorlar. Son olarak, bu paylaşımlı sıralayıcıyı merkezileştirmenin bir yolunu tekrar bulmamız gerekiyor.
Ama yine de, bence insanların giderek daha fazla sorunu keşfetmesi ve daha fazla çözüm üretmesi iyi bir şey. Sonuç olarak, her gün bu alandaki yenilikleri görmek heyecan verici. Tüm bu yeni çözümlerle, en azından tüm toplama alanını gerçekten merkezden dağıtmak için doğru yoldayız.
Abdel
Evet, ikinize de katılıyorum. Layer3 ve Lisk için daha mantıklı olduğunu düşünüyorum çünkü artık merkezi olmayan bir ağı teşvik etme sorumluluğunu üstlenmek istemiyorlar ve sıralayıcılar gibi şeyleri başlatmak için ortaklar bulmaları gerekiyor. Bu yüzden Lisk için mantıklı olduğunu düşünüyorum. Ama Toghrul gibi, Layer2 için henüz pek bir anlam ifade ettiğini düşünmüyorum.
Konu 4
Merkezi olmayan bir sipariş verenin MEV üzerinde nasıl bir etkisi olur?
Abdel
Starknet için merkezileştirme bağlamında herhangi bir MEV yapmıyoruz ve ilk gelen alır modelini benimsiyoruz. Yani ademi merkeziyet bağlamında, elbette daha sonra daha fazla MEV getirilecek. Ancak hangi oranın olduğunu söylemek için henüz çok erken çünkü bu aynı zamanda fikir birliği mekanizmasının tasarımına ve diğer yönlere de bağlı.
Seçenek
Ama mesele şu ki, MEV yapmasanız bile, Starknet'te hala bir miktar MEV oluyor olabilir. Eh, ademi merkeziyetçilik tek başına MEV'yi gerçekten azaltmaz veya MEV'yi artırmaz. Elbette, örneğin bir tür adil sıralama protokolü veya eşik şifreleme uygularsanız, o zaman evet, MEV'yi en aza indirirsiniz. Ama tamamen ortadan kaldıramazsınız. Benim felsefem şudur: MEV ortadan kaldırılamaz. Ama diyelim ki sadece bir BFT konsensüsü oluşturuyorsunuz veya bir BFT konsensüsü üzerine bir şeyler inşa ediyorsunuz. Bu aslında MEV'yi hiç etkilemez. MEV hala var, bu MEV'yi çıkarmak için arayıcının sıralayıcı ile nasıl çalıştığı sorusu olmalıdır.
Yaoqi
Sorun şu ki, ilk gelen alır modelinin bile zor kısımları var. Mempool'u bazı arayanlara gösterdiğimizde, hala daha fazla oynama avantajına sahip oluyorlar. Örneğin sıralayıcılar için, ofisinizin kapısında beklemeye eşdeğerdir. Dolayısıyla bu durumda, bir kullanıcı bir işlem gönderir göndermez, yalnızca önden çalıştırma veya bir sandviç saldırısı ile ilgili değil, bir tür arbitraj fırsatı gördüklerinde, bunu hemen mempool'da görebilirler. Böylece, ticaretlerini hızla başkalarının önüne koyabilirler. Bu nedenle, diğer arama yapanlara göre bir avantajları vardır.
Ama ademi merkeziyetçiliğe geri dönecek olursak, bence bu, başta tartıştığımız gibi, çoğunlukla sansüre karşı direnişle ilgili. Sıralayıcılar ekip tarafından yönetilir. Ekip, herkese karşı adil davrandıklarını söyleyebilir. Ancak bu kodda engellenmez. Dolayısıyla, bir P2P ağımız olabilirse, bu düğümlerin işlemlerimi incelediğini ve ardından diğer düğümlere gönderebileceğimizi hissedersek harika olur. Yani, gerçekten L2'de işlemlerin işlenmesinin adaletiyle ilgili.
MEV'lere gelince, çünkü son zamanlarda tek bir toplama içinde üretilen MEV'lere ek olarak, köprüler arasında üretilen bazı MEV'ler var. Bu nispeten merkezi olmayan sıralama ağında, MEV'yi çıkarmak için daha fazla fırsatınız olacak. Paylaşılan bir sipariş ağımız olduğunu varsayarsak, paylaşılan sipariş vereni işlemleri yeniden sıralaması için bir şekilde etkileyebilirseniz, temelde diğer herkese göre büyük bir avantajınız olur.
Paylaşılan sıralayıcı ağının avantajları ve dezavantajları vardır. Artı tarafta, rütbe sistemini daha da dağıtabiliriz. Ancak diğer taraftan, herkesin sıralayıcı olma fırsatı vardır. Yani, temelde ne isterlerse yapabilirler ve yine karanlık bir orman. Bu yüzden ademi merkeziyetçiliği getirdik ve ardından Ethereum'da karşılaştığımız benzer sorunlarla yüzleşmek zorunda kaldık. Bu nedenle, Flashbots ve Ethereum Vakfı çalışanları, PBS, ayrı teklifçiler ve oluşturucular ile ilerlemek ve ardından oluşturucu tarafında tek bir çözüm bulmaya çalışmak istiyor.
Yani soruna baktığımızda tek bir sorun değil. Artık bire bir sorun değil, altıya bir ve daha fazlası.
View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
AltLayer, Scroll, Starknet ekipleriyle diyalog: Paylaşılan Sıralayıcı ve L2 Mutabakat
Giriiş
Çeşitli toplama çözümlerinin vizyonuna ve yol haritasına baktığımızda, hemen hemen tüm toplamaların nihai bir hedefi olduğunu görürüz: Bu hedef tek bir cümleye sığdırılırsa: bir teknoloji yığını oluşturmak, topluluğa sağlamak, blok zinciri ve nihayetinde teknoloji operasyonları ve yönetişim yığınının ademi merkeziyetçiliği. Bu, merkezi olmayan toparlama terimine yol açar.
Peki ademi merkeziyetçilik tam olarak nedir? Toplama sisteminin çeşitli bölümleri arasındaki işbölümü nedir? Ademi merkeziyetçilik, sistem operasyon katılımcılarını en üst düzeye çıkarmak anlamına mı geliyor? Merkezi bir sıralayıcının nasıl bir etkisi olacak? Paylaşılan sıralayıcı ve L2 yerel fikir birliği nasıl tasarlanmalıdır? ZK-Rollup'taki benzersiz kanıtlayıcının işlevi nedir? Açık, merkezi olmayan bir kanıtlayıcı ağı nasıl görünürdü? Neden zk donanım hızlandırmasına ihtiyacımız var? Veri kullanılabilirliği sorununun çözümü nedir? ....
Toplulukta merkezi olmayan Toplama hakkında sonu gelmeyen tartışmalar var, bu nedenle ECN "Merkezi Olmayan Toplama" temasıyla bir dizi podcast röportajının küratörlüğünü yaptı ve bu alandaki seçkin kurucuları ve araştırmacıları merkezi olmayan Toplama anlayışı hakkında konuşmaya davet etti.
Katman 2 platformuna giderek daha fazla likidite aktıkça, yalnızca genel amaçlı toplama çözümleri, uygulamaya özel toplama zincirleri değil, aynı zamanda hizmet olarak toplama platformları da dahil olmak üzere, giderek daha fazla toplama hizmeti sağlayıcısı ortaya çıkıyor. Bu nedenle, giderek daha fazla insan, neredeyse tüm toplamalarda çok kritik bir rol olan "sıralayıcının" hala merkezileştirilmiş olduğundan endişe duyuyor. Merkezi bir sıralayıcının riskleri nelerdir? Merkezi olmayan bir ayırıcı acil bir iş midir?
**İkinci bölümde AltLayer Network'ün kurucusu Yaoqi Jia'yı, Scroll araştırmacısı Toghrul Maharramov'u ve Starknet Keşif Lideri Abdelhamid Bakhta'yı merkezi olmayan ayırıcılar konusunda bir yuvarlak masa tartışması yürütmeye davet ettik, böylece izleyiciler ve okuyucular merkezi olmayan ayırıcıların mevcut bazı ilerlemelerini ve ikilemlerini anlayabilir. **
Bu sayının konukları:
Geçmiş
Sorun 1: Toplama nasıl dağıtılır?
Ön izleme
Sorun 3: Prover ağı ve zk donanım hızlandırması
Sorun 4: Veri Kullanılabilirliği ve Merkezi Olmayan Depolama
Dinlemek
Daha fazla bilgi edinmek için podcast'e abone olmak için tıklayın:
Youtube:
Mikrokozmos:
zaman damgası
00:49 Yaoqi kendini tanıtır
01:37 Abdülhamid kendini tanıtır
02:50 Toghrul kendini tanıtır
04:03 Toplamada sıralayıcının rolü
08:37 Merkezi olmayan sipariş veren: Kullanıcı deneyimini iyileştirme ve canlılık ve sansür sorunlarını ele alma
19:43 Starknet ayıklayıcıyı nasıl dağıtacak
22:59 Scroll, sıralayıcıyı nasıl dağıtacak?
26:34 Optimistic toplama ve zkRollup bağlamında L2 fikir birliği arasındaki fark
32:28 zkRollup, sıralayıcıyı dağıtır ve kanıtlayıcıyı da dikkate alması gerekir
36:01 Temel toplama nedir?
40:53 Paylaşılan sıralayıcı ve tabanlı toplamanın dezavantajları ve bunların uygulama senaryoları
49:02 Merkezi olmayan bir sipariş verenin MEV üzerinde nasıl bir etkisi olacak?
Misafir tanıtımı
Yaoqi
AltLayer'ın kurucusuyum. AltLayer, geliştiricilerin yalnızca bazı düğmeleri tıklayıp parametreleri yapılandırdığı bir "Hizmet Olarak Toplama" platformu oluşturuyor. Başlatma rampamızı veya kontrol panelimizi kullanarak uygulamaya özel toplamaları dakikalar içinde hızla başlatabilirler. Geliştiricilere ortak bir yürütme ortamı ve işlevsellik sağlamak için şimdi yapmaya çalıştığımız şey bu. Ayrıca, geliştiricilerin aralarından seçim yapabileceği birden çok sıralayıcı, birden çok sanal makine sistemi ve çeşitli kanıtlama sistemleri sağlıyoruz.
Abdelhamid
Starkware'de çalışıyorum ve keşif ekibinin lideriyim. Bu grubun amacı temel olarak araştırma benzeri ancak mühendislik odaklı açık kaynaklı projeler başlatmaktır. Amacımız, toplulukla ve diğer ekosistemlerden insanlarla yakın işbirliği içinde açık kaynak projeleri üzerinde çalışmaktır. Böyle bir proje, aslında bir Starknet sıralayıcısı olan Madara'dır. Yalnızca Starknet genel ağı için bir aday değil, aynı zamanda Starknet uygulama zinciri ve Layer3 için bir sıralayıcıdır. Bu aynı zamanda bir önceki konuğun söyledikleriyle de bağlantılı, ayrıca bir hizmet işlevi olarak toplama sağlamayı düşünüyoruz, insanlar Starknet uygulama zincirlerini kullanıma sunabilir ve biraz modüler bir şekilde farklı veri kullanılabilirliği çözümleri seçebilirler. Bundan önce, esasen EIP-1559'un çalışmasından sorumlu olarak dört yıl Ethereum çekirdek geliştiricisi olarak çalıştım.
Seçenek
Scroll'da bir araştırmacıyım ve Scroll'daki ana sorumluluklarım protokol tasarımı, köprü tasarımı, ademi merkeziyetçilik, teşvikler, bu tür şeyler. Bu yüzden, etrafta tweet atmadığım zamanlarda, çoğu zaman sadece protokolün veya emir verenlerin, kanıtlayıcıların, bunun gibi şeylerin nasıl merkezileştirileceği üzerinde çalışıyorum. Starkware gibi, üzerinde çalıştığımız şeylerden biri de bir toplama SDK'sı. Böylece Scroll tabanlı bir rollup yayınlayabilir, farklı veri kullanılabilirlik seçeneklerini modüler olarak kullanabilirsiniz. Hala, Scroll SDK'ya dayalı toplamaların, her bir toplamanın yerelleştirmeyi kendi başına halletmesini gerektirmeden, yerelleştirmeye ulaşmalarına yardımcı olmak için Scroll'un sıralayıcısını kullanabilecekleri bir seçeneği düşünüyoruz. Tabii plan henüz kesinleşmedi. Ancak bu aynı zamanda üzerinde çalıştığımız yön.
Röportaj bölümü
birinci konu
Toplamanın sıralayıcısını açıklayın?
Abdelhamid
Sıralayıcı, katman2 mimarisinde çok önemli bir bileşendir, bu bileşen kullanıcılardan işlemleri alır, ardından bunları paketler ve bloklar halinde demetler, işlemleri yürütür vb. Katman2 aynı zamanda işlem bloklarına sahip bir blok zinciri olduğundan, bu çok kritiktir çünkü blok oluşturmaktan sorumlu bileşendir. Sipariş verenler bu blokları oluşturur ve kanıtlayıcılar bu blokları onaylar.
Yaoqi
Abdel'in belirttiği gibi, sipariş veren, blok zincirindeki birçok işlevin bir kombinasyonudur. Bu nedenle, sipariş verene artık tipik bir genel blok zincirine kıyasla çok fazla sorumluluk veriyor olabiliriz. Öncelikle kullanıcılardan gelen tüm işlemleri toplaması ve ardından bu işlemleri gaz fiyatına veya ilk gelen alır esasına göre sıralaması gerekir. Daha sonra sıralayıcının bu işlemleri yürütmesi gerekir. Şu anda olduğu gibi, bazı Layer2'ler EVM kullanıyor (Starware'in farklı bir sanal makinesi var), ancak temel olarak sıralayıcının işlemleri yürütmek ve durum oluşturmak için özel bir sanal makine kullanması gerekiyor. Ardından işlem bir ön onay aşamasına ulaşır; bu, bir veya iki saniyelik veya hatta saniyenin altında bir onay süresi görürseniz, bunun temelde sıralayıcı tarafından tamamlanan bir ön onay durumu olduğu anlamına gelir. Ardından, çoğu sıralayıcı için, L1'e kontrol noktaları veya durum karmaları yüklemeleri veya yayınlamaları gerekir. Bu, veri kullanılabilirliği dediğimiz L1 seviyesindeki onaydır. Yani sıralayıcı aslında toplama sisteminde birçok role sahiptir. Ama genel olarak rollup sisteminin en kritik bileşeni olduğunu düşünüyorum.
** Konu 2 **
Merkezi olmayan bir sıralayıcı neden önemlidir? Merkezi bir sıralayıcı kullanırsak, kullanıcılar ve sistem için gizli tehlikeler nelerdir?
Seçenek
Her şeyden önce, şu anki aşamada Fuel V1 dışında gerçek bir toplama olmadığını bilmemiz gerekiyor çünkü diğer toplamaların hala eğitim tekerlekleri var.
Ancak rollup olarak sınıflandırıldığında multi-sig'in kaldırıldığı anlamına geldiğini söyleyebiliriz. O zaman sıralayıcı ademi merkeziyetçilik sorunu, bir güvenlik sorunu değil, bir kullanıcı deneyimi sorunu haline gelir. Yani insanlar, diyelim ki, L1'in ademi merkezileştirilmesinden söz ettiğinde, sorun tamamen farklıdır. Çünkü L1, sipariş veren ve hafif müşteriler için garanti vermek zorundadır. Bu nedenle, hafif bir istemci durumun doğru olduğunu doğrulamak istiyorsa, L1 doğrulayıcılarına güvenmelidir. Toplama için durum böyle değil. Çünkü sıralayıcı yalnızca geçici sıralama sağlar ve bu daha sonra L1 tarafından sonlandırılır. Toplamaların sansüre dayanıklı olması da garanti edildiğinden, bunun gerçekleşmesi için merkezsizleşmeye ihtiyacımız yok.
Bu nedenle, merkezi olmayan bir sıralayıcıya ihtiyaç duymanızın birkaç nedeni vardır. İlk olarak, diyelim ki L1 sonlandırma yavaşsa (ya gönderdiğiniz geçerlilik kanıtlarının çok yavaş olması ya da iyimser toparlama dolandırıcılık kanıtlarının meydan okuma süresi mekanizması nedeniyle), hızlı işlem onayı elde etmek için bir şeye güvenmeniz gerekir. Hızlı onaylamanın bu aşamasında, Starkware veya Scroll'un sizi yanıltmayacağına güvenebilseniz de, blok onaylandıktan sonra yeniden düzenleme yapılmayacağını belirtirler. Bu bir güven varsayımıdır. Ve ademi merkeziyet bazı ekonomik garantiler ekleyebilir vb.
Ancak buna dayanarak, toplamanın da gerçek zamanlı kesinlik garantisi yoktur. Temel olarak, işlem paketlemesini L1 aracılığıyla zorlayabilirsiniz, ancak bu işlemi paketlemek saatler alır. Örneğin, güncellemeden sorumlu bir oracle varsa ve süre dalgalanıyorsa, temel olarak oracle bir saat veya daha fazla güncellenirse, rollup'taki uygulamalar kullanılamayacaktır. Temel olarak, ademi merkeziyetçilik, sansüre karşı daha güçlü, gerçek zamanlı garantiler sağlamamıza izin verir, çünkü o zaman bir düşmanın yalnızca bir veya bir avuç varlığı değil, tüm sipariş verenler ağını tehlikeye atması gerekir.
Bu nedenle, bizim için ademi merkeziyetçilik, daha çok kullanıcı deneyimini iyileştirmeye veya kehanet güncellemelerinin köşe durumunu düzeltmeye yönelik bir çözümdür. Temel güvenlik garantileri sağlamak yerine, L1'in yaptığı budur.
Abdelhamid
Evet, bahsettiğiniz merkezi olmayan sıralayıcı ile ilgili soru, çok önemli olduğunu düşündüğüm merkezi olmayan L1 ile tam olarak aynı değil. Çünkü bazı L1'lerin merkezi sıralayıcıları eleştirdiğini gördüğümüzde, merkezi sıralayıcıların yaptığı değiş tokuşlara düzgün bir şekilde bakmıyorlar.
Bu temelde, kullanıcı deneyimiyle ilgili, etkinlikle ilgili bir şeyler eklemek istiyorum. Çünkü yalnızca tek bir sıralayıcınız olduğunda, sıralayıcının çökme riski daha yüksektir. Bu nedenle, merkezi olmayan bir sipariş veren, ağdaki esnekliği ve canlılığı da artırır. Ancak merkezi bir bağlamda bile, güvenlik söz konusu olduğunda iyi bir güvenliğe sahibiz. Çünkü paket işlemlerini L1 üzerinden zorlayabildiğiniz zaman, ikisi arasındaki fark sadece zaman çizelgesidir. Toghrul'un da belirttiği gibi, merkezi olmayan bir sıralayıcıya sahip olmak, hızlı sansüre dayanıklı garantilere sahip olmanızı sağlar. Bu nedenle, canlılık için merkezi olmayan bir sipariş ağına sahip olmanın da önemli olduğunu eklemek istiyorum.
Yaoqi
Bir şey eklemek istiyorum. Etkinlik muhtemelen bu aşamada dikkate almamız gereken en önemli şeydir. Optimism ve Arbitrum gibi en popüler L2'lerdeki en son airdrop vakalarında bir aksama süresi yaşandı. Bu nedenle, bence çözmemiz gereken şey, yalnızca bir sıralayıcımız varken saniyede binlerce işlem talebini nasıl ele alacağız. Teoride bile, yalnızca bir düğümünüz varsa, aynı anda bu kadar çok isteği gerçekten karşılayamaz. Dolayısıyla, canlılıkla ilgili olarak, kesinlikle birden fazla ayırıcıya ihtiyacımız var. Tek hata noktası gerçek bir engeldir, sadece Web3 için değil, Web2 bile büyük bir problemdir.
Bunun ötesinde sansür meselesi var. Yalnızca bir koordinatörümüz varsa, bunun ekip tarafından yürütülebileceğini görsek bile, yine de ekibin işlemleri fiilen incelemeyeceğini kanıtlamanız gerekir. Bazen kötü niyetli tarafların belirli işlemleri kara listeye alması mümkün ve yeteneklidir. Bu, merkezi olmayan bir sipariş sistemidir, ayrıca diğer sipariş verenler aracılığıyla işlem göndermeyi deneyebilirler. Bu yüzden son zamanlarda tek sıralayıcılar hakkında çok fazla eleştiri alıyoruz.
Bunun ötesinde, MEV ve erken çalıştırma gibi başka sorunlar da var. Özellikle DeFi protokolleri için merkezi sıralayıcılara sahip bir sistemde mempool'u kolayca kontrol edebilirler. Muhtemelen bir lider şeklinde değiller, ancak ticareti takip etme ve tahkim etme şansları daha yüksek.
Bu sorunların birçoğu, çeşitli nedenlerle, L2'nin L1'den çok farklı olduğunu görmemize rağmen. Ancak nihayetinde, onu mümkün olduğunca merkezi olmayan hale getirmemiz gerekiyor. Bu nedenle, halka açık blok zincirleri veya L1 ile sahip olduğumuz benzer sorunlardan bazılarıyla yüzleşmek zorundayız.
Abdelhamid
Evet, merkezi olmayan bir sıralayıcının önemli olduğuna katılıyorum. Ama hepimizin bildiği gibi bunun kolay bir soru olmadığını da söylemek istiyorum.
Ayrıca **çünkü toparlamalar, birden fazla varlığa sahip çok özel bir mimariye sahiptir. Bahsettiğimiz tek bir sipariş veren var, ancak bir de kanıtlayıcı var ve ikisini de merkezileştirmemiz gerekiyor. **Ağı çalıştırmak için farklı faktörler gerektiğinden, bazı takaslar ve işlemlerin nasıl fiyatlandırılacağı konusunda bazı zorluklar olacaktır. Peki, anlaşmayı nasıl fiyatlandırıyorsunuz? Sıralayıcı ve kanıtlayıcının farklı donanım gereksinimleri vardır, kanıtlayıcının süper güçlü bir makineye ihtiyacı vardır vb. Bu nedenle, merkezi olmayan bir dünyada fiyatlandırma işlemleri de çok zor bir sorundur, bu nedenle yavaş yavaş ilerlemek için zamana ihtiyacımız var.
Yani hepimiz böyle bir değiş tokuşla karşı karşıya kalacağız.Hızlı bir şekilde ademi merkezileşmek istiyorsak, bazı eğitim çarkları alıp kademeli olarak ademi merkezileşmemiz gerekebilir, çünkü doğrudan mükemmel bir mimari istiyorsak, bu birkaç yıl alacaktır. Bu yüzden pragmatik bir yaklaşım benimseyeceğimizi ve kademeli olarak adem-i merkezileşmeye çalışacağımızı düşünüyorum. En azından şu anki planımız bu, örneğin basit bir BFT konsensüs mekanizmasıyla başlayıp kısa vadede başka bir konsensüs mekanizması falan eklemek gibi. Bu yüzden sadece söylemek istiyorum, bu kolay bir soru değil. Çünkü geliştirme hızı ile mimarinin merkezi olmayan bir ortama ne kadar uygulanabilir olduğu arasında açık bir denge vardır.
Konu 3
Sıralayıcı nasıl dağıtılır?
Abdelhamid
Dağıtmak istediğimiz birçok özellik var ve hepsinin farklı ödünleşimleri var.
Örneğin, ademi merkeziyetçilik yaparken, bir tür mutabakat mekanizması getirmek istiyorsunuz. Ancak mutabakat mekanizmasında birden çok kısım vardır. İlki lider seçimidir, yani blokları kimin oluşturacağının, belirli bir alanda veya belirli bir süre içinde blok oluşturmaktan kimin sorumlu olacağının nasıl seçileceği. **Starknet ekibinin yapmayı planladığı şey, katman 1'i mümkün olduğunca kullanmaktır. Yani lider seçim algoritmamızda 1. katmanda stake yapmak istiyoruz. Örneğin, jetonlarımız var ve rehin, lider seçim mekanizmasını belirlemek için kullanılan katman1 Ethereum'un akıllı sözleşmesinde gerçekleşecek. **Bu, L2 sipariş sahibinin kimin bir sonraki lider falan olacağını bilmek için Ethereum akıllı sözleşmesini sorgulayacağı bir etkileşim kurmamız gerektiği anlamına gelir. Yani belli ki bir tür rastgelelik ve başka şeylere ihtiyaç var. Yani basit bir soru değil. Ama bu ilk kısım. O zaman mutabakatın kendisi için bir mekanizmaya sahip olmanız gerekir. Birden fazla seçenek vardır: en uzun zincir mekanizması veya BFT veya ikisinin bir karışımı. Ethereum gibi, kesinlik için LMG Ghost ve Casper FFG'ye sahiptir.
Bu yüzden pragmatik bir yaklaşım benimseyebilir ve önce BFT ile başlayabiliriz. Neden? Layer2 ademi merkeziyetçiliği ele aldığında, hedefimiz Layer1 kadar büyük bir sorter ölçeğine sahip olmak değildir. Örneğin, Ethereum'da amaç, katılan milyonlarca doğrulayıcıya sahip olmaktır. Bu durumda sadece BFT mekanizmasını kullanamazsınız çünkü verim açısından çok kötü olur ve çok büyük sorunlara neden olur. Örneğin Bitcoin ağında bir sorun varsa, bu bir BFT mekanizmasıysa zincir tamamen durur. Ancak durum böyle değil, Bitcoin ağı bloklar oluşturmaya devam ediyor, sadece kesinlik mekanizması saldırıya uğruyor.
Ancak katman 2'de, hedef birkaç yüzden 1000'e kadar sıralayıcı ise, bir BFT mekanizmasıyla başlamak iyi olabilir. Yani, lider seçim mekanizmamız var, sonra mutabakat ve sonra iki bölüm daha var ama eklemeye devam etmeyi diğer konuklara bırakacağım. Ancak diğer iki bölüm, durum güncellemeleri ve kanıt oluşturmadır.
Seçenek
İlk olarak, L2'de, Abdel tarafından tanımlandığı gibi, ademi merkeziyetçilik çok yönlü bir sorundur. Özellikle zkRollup'ta kanıtlayıcılar ve sipariş verenler olduğu için aralarında koordinasyon sağlamalısınız, ikisini de dağıtmalısınız. Bu problem L1'den tamamen farklıdır.
Diğer bir fark ise, L2'de tüm tasarımınız, herhangi bir sayıda başka düğümü ikna etmek için değil, temeldeki köprüyü fikir birliğinin doğru olduğuna ikna etmektir. Elbette aynısını yapmalısınız, ancak asıl odak noktanız köprünün kendisi olmalıdır.
Şu anda iki farklı yönde çalışıyoruz. Birincisi, bence herkes gibi biz de bir BFT protokolü üzerinde çalışıyoruz. Bu çok verimli değil ve üzerinde çalışılması gereken bazı karışıklıklar var. Kabaca bir çözüm bulduk ama yine de optimal değil. Örneğin, sorulardan biri, ayıklayıcılar ve kanıtlayıcılar arasındaki teşvikleri nasıl dengeleyeceğinizdir. Siparişi veren MEV'yi kontrol ettiğinden ve kanıtlayıcının MEV'ye erişimi olmadığından, insanların kanıtlayıcı yerine siparişi vereni çalıştırması için bir teşvik vardır. Ama gerçekte, sipariş verenden çok kanıtlayıcıya ihtiyacımız var, o halde ikisi arasındaki teşvikleri nasıl dengelersiniz? Bu da o sorunlardan biri.
Üzerinde çalıştığımız ikinci çözüm başka bir yön. Unutmayın, işler değişebilir. Her gün yeni teklifler çıkıyor. Örneğin, son zamanlarda temel toplama ve sıralamayı nasıl tamamen L1'e yaptırabileceğiniz hakkında çok fazla konuşma yapıldı. İkinci yön, temel olarak sıralayıcıyı tamamen ortadan kaldırmak ve bazı harici oluşturucular kullanmaktır. Örneğin, ethereum oluşturucuları veya Flashbots SUAVE vb. sıralı bloklar önerir ve ardından kanıtlayıcı içinde fikir birliği yürütür. Buradaki avantaj, teşviklerle uğraşmak zorunda kalmamanızdır çünkü temelde PBS'yi protokol içinde kullanabilirsiniz ve daha basit bir protokol oluşturur. Ancak dezavantajı, çok sayıda kanıtlayıcıya ihtiyacımız olduğu için (çünkü paralel olarak kanıtlayabiliriz), bunlarla klasik bir BFT protokolünü çalıştırmak oldukça zordur. Öyleyse soru şu ki, mevcut bir BFT protokolünü yüzlerce, hatta binlerce kanıtlayıcı ile çalışacak şekilde nasıl optimize edersiniz? Ve bu cevaplaması kolay bir soru değil.
Merkezi olmayan bir sipariş veren için L2 mutabakatının getirilmesi gerekli midir?
Yaoqi
Bu soruyu kabaca cevaplayabilirim çünkü yakın zamanda böyle bir şeyi piyasaya sürdük.
Dolayısıyla fikir birliğini getirip getirmemek, isteyip istemediğimize bağlı değildir. Çok sayıda sipariş vereniniz veya hatta yalnızca düğümünüz olduğunda, onları kabul ettirmeniz gerekir. Bu gerçekten varsayımlarınıza bağlı. Bu bir Bizans varsayımıysa, BFT'yi veya mevcut herhangi bir Bizans konsensüs protokolünü kullanabiliriz. Bizans dışı bir kurulumsa, örneğin, bir düğümün yalnızca çevrimiçi ve çevrimdışı olabileceğini ve kötü niyetli davranamayacağını varsayarsak, o zaman Raft protokolünü veya daha hızlı başka bir mutabakat protokolünü kullanabiliriz. Ama her neyse, eğer bir emir veren veya ispatlayan grubumuz varsa, onları belirli bir süre boyunca bloklar üretmek için birlikte organize etmek istiyorsak, o zaman onlar etrafında bir fikir birliği protokolüne sahip olmanız gerekir.
Dolayısıyla, Toghrul ve Abdel'in az önce bahsettiği gibi, merkezi olmayan bir sıralama veya kanıtlama sistemini nasıl uygulayabileceğimize dair pek çok teklif ve araştırma konusu olduğuna inanıyorum. Bu nedenle, çok sıralayıcı toplama sistemi için bir test ağı başlattığımızdan (şu anda yalnızca Optimistic toplamalar için sahtekarlık kanıtlarını desteklemektedir), tasarım ve uygulama deneyimimize dayanarak, zorluklar hakkında paylaşabileceğim bazı şeyler var. Toghrul'un az önce bahsettiği gibi, zorluk mutabakat protokolünün kendisinde değil, asıl zorluk bundan başka, ispat kısmı gibi şeylerde yatıyor. Çünkü tek bir sıralayıcı ise çok sayıda düğüme ihtiyacınız yoktur. EVM yani sanal makine gibi düşünebiliriz. Yani, sadece işlemleri getirin ve yürütün, durum geçişleri yapın. Kanıtlayıcı, önceki işlem kümesinin durum geçişi için kanıtlar üretmekten sorumludur. Bununla birlikte, toplamada harmanlayıcı ve kanıtlayıcı için fikir birliği protokolünü çalıştırırsak, o zaman burada ek fikir birliği mantığı uygulamamız gerekir. Bunun da ötesinde, mutabakat protokolü için bir ispat sistemine de ihtiyacınız var. Bu nedenle, bu, ispat sisteminin üretmesi için çok fazla iş getirecektir. Ardından kanıtı oluşturduğunuzda, L1 Ethereum'da kolayca doğrulayabilirsiniz.
Bu nedenle, bir şekilde, ilk çok siparişli test ağını başlattığımızda, iyimser toplamanın bu açıdan bazı avantajları vardı. Genel olarak geçerlilik ispat kısmını dikkate almamak gibi bir çok şeyi basitleştirebilirsiniz. Bizim gibi temelde her şeyi WASM ile karşılaştırırız. Yani sonuçta bu bir WASM talimatı. Dolayısıyla, bu WASM talimatlarını doğrulayarak, Solidity kodunu kullanarak doğrulama yapmak nispeten kolaydır. Tüm WASM talimat yorumlarını Ethereum'da yeniden uygulasaydık.
Ancak genel olarak sorun tekil değildir. Buna bağlı olarak, soruna bir çözüm bulursak, aynı zamanda çözülmesi gereken başka bir takip çalışması olacaktır. Elbette MEV'i nasıl adil dağıtacağız gibi MEV sorunları olacak. Bir blok oluşturup oluşturmadıklarına veya bir bloğu doğrulayıp doğrulamadıklarına bağlı olarak tüm sipariş verenleri ve doğrulayıcıları atayabilirsiniz. Ama sonuçta, sadece teknik değil, aynı zamanda ekonomik teşvikler de dahil olmak üzere birçok sorunun bir kombinasyonu.
Ve gaz maliyetini önemli ölçüde azaltmak istediğimiz için L2'nin önerildiğini hatırlamamız gerekiyor. Yani çok fazla düğümümüz olamaz. Kanıt üretirken bile L2, L1'den daha pahalı olabilir. Bu nedenle, bu tür bir soruna gerçekten dengeli bir yaklaşım bulmalıyız.
Abdelhamid
Bir noktayı daha eklemek isterim. İlk olarak, şu anda iyimser toparlamalar için gerçek bir izinsiz dolandırıcılık kanıtı yok. Bunu her fırsatta vurgulamaya devam ediyorum çünkü karşılaştırma yaparken bu konuda dürüst olmak önemlidir. Yani hiç L2 değiller. İlk şey bu.
Sonra sıralama ve provalar arasındaki uyumsuzluk hakkında bir şeyler eklemek istiyorum, çünkü bu çok önemli. Dediğiniz gibi sıralamayı optimize etmek istiyoruz çünkü şu anda bu tüm çözümler için bir darboğaz. Ancak bu, merkezi bir sıralama bağlamında sorun değil, çünkü sıralayıcının yalnızca değer geçişleri üreteceğini biliyoruz ve bunları doğrulayabileceğiz. Ancak merkezi olmayan bir sıralama bağlamında daha zor olacaktır, çünkü belki de ayıklayıcınız doğrulanamayan bir şey üretebilir. O zaman bununla daha sonra ilgilenmen gerekecek.
Merkezi sıralama bağlamında, sıralamayı optimize etmek için, sıralama işlemi sırasında ispatlar oluşturmak zorunda olmadığımız için bunu yerel hızda yapmayı deneyebiliriz, yapmak istediğimiz de bu. Kahire'yi LLVM gibi düşük seviyeli bir makine diline çevirin ve sıralayıcıda süper hızlı çalışın. O zaman asenkron olarak kanıtlayabilirsiniz. Ve ispatlarla ilgili en harika şey, onları paralel olarak yapabilmenizdir. Özyinelemenin mümkün olduğunu kanıtlayarak büyük paralelleştirilebilirlik elde edilir. Bu yüzden sıralayıcının hızına yetişebileceğiz. Ancak merkezden dağıtıldığında bu zordur, çünkü sipariş verenin yalnızca geçerli durum geçişleri üretmesini sağlamamız gerekir.
Seçenek
Starknet'in burada ne yaptığından emin olmadığımı da ekleyeceğim. Ancak bizim için, sanırım her zkRollup'ın genel bir varsayımı, sıralayıcıyı dağıtırsanız, ispat sisteminizin geçersiz yığınları işleyebilmesi gerektiğidir. Dolayısıyla, temel olarak, diyelim ki, geçersiz bir imzayla bir parti gönderirseniz, ortaya çıkan durumun başlangıç durumuna eşdeğer olduğunu kanıtlayabilmeniz gerekir. Yani her iki şekilde de bir miktar ek yük olacak. Bu, bunun olma olasılığını nasıl en aza indirdiğinizle ilgilidir.
Abdelhamid
Evet bu doğru. Bu nedenle, her şeyi doğrulanabilir kılmak için Kahire 1'de Sierra'yı tanıttık. Bu ara temsil, bir geri alma işlemini dahil edebilmemiz için her Cairo 1 programının doğrulanabilir olmasını sağlayacaktır.
Tabanlı toplama nedir?
Yaoqi
Temel toplama, orijinal olarak Justin Drake'in Ethereum forumlarındaki bir blog gönderisinden geldi. Fikirlerinden biri, bazı Ethereum doğrulayıcılarını toparlama işlemlerini doğrulamak için yeniden kullanabileceğimiz, böylece farklı toparlama işlemlerini doğrulamak için ayrı bir düğüm grubuna ihtiyacımız olmaması. Özellikle gelecekte, genel amaçlı toplamalar ve uygulamaya özel birçok toplama dahil olmak üzere birçok toplamaya sahip olacağız. Dolayısıyla, bu durumda, bu işlemleri doğrulamak için Ethereum doğrulayıcı havuzu gibi ortak bir yer bulabilirsek harika olur.
Tabii ki, bu sadece bir fikir çünkü aynı zamanda pek çok teknik zorluk da getiriyor. Örneğin, teoride, Ethereum doğrulayıcılarının toparlama işlemlerini doğrulamasını isteyebiliriz, ancak toparlamaları doğrulama mantığını Ethereum protokolünün kendisine gömülü veya paket haline getirmek çok zordur. Buna Ethereum düğümlerinden oluşan bir hard fork gerektiren protokol içi doğrulama diyoruz. Tabii ki, bu durumda, bazı toplama işlemlerini doğrulayabiliriz. Ama yaparsak, sorunlar görürsünüz. Sanki L2'nin toparlamasının Ethereum'un baskısını paylaşmasını istiyor gibiyiz, ama sonunda yine de Ethereum onaylayıcılarından L2'ye yüklenen işlerin bir kısmını üstlenmelerini istiyoruz. Pek çok insan bunu nasıl yapabileceğimizden bahsediyor.
Daha sonra Ethereum Vakfı'nda şu anda PBS üzerinde çalışan bir araştırmacı olan Barnabe ile konuştuk. Bu, doğrulayıcıların görevini birden çok role, oluşturucuya ve teklifçiye bölmek olan Ethereum'un bir önerisidir. Artık PBS'de inşaatçı rolünü üstlenecek Flashbot'larımız var, tüm blokları oluşturuyorlar ve bunları Ethereum teklifçilerine gönderiyorlar. Dolayısıyla, bu bloklar Ethereum ağına paketlendiğinde, inşaatçılar da bazı ödüller alacak. Öyleyse bu durumda, bu doğrulayıcıları Ethereum ağından nasıl ödüllendirebiliriz? Toplama doğrulamasından da sorumludurlar.
Çözümlerden biri, EigenLayer veya diğer bazı protokollerden çok duymuş olabileceğiniz "yeniden alma" dır. Kullanıcılar, ETH'yi diğer sıralama ağlarında yeniden stake edebilir. Veya toplama için doğrulama işini yapmak üzere yazılımı gerçekten çalıştırdıkları için Ethereum doğrulayıcılarını ödüllendirin. Bu durumda, hem L2'den hem de yeniden staking protokolü aracılığıyla ödüllendirilebilirler. Bunun için şimdiye kadar birçok teklif geldi, ancak genel olarak bu, mevcut Ethereum doğrulayıcılarının nasıl yeniden tasarlanabileceğine dair bir fikir. Yeni bir toplama veya L2 sistemleri çağını başlatmak için mevcut ETH'yi nasıl yeniden kullanabiliriz? Yani temelde toplama projesi için pek çok şeyi basitleştirmeye çalışıyor. Toplama, yeni bir sıralayıcı istiyorsa, yeni bir teminat kaynağı istiyorsa, mevcut altyapıyı veya mevcut teminatı yeniden kullanabilir. Bu yüzden Ethereum üzerine inşa edilmiştir ve daha sonra daha fazla altyapı ve staking, toplama ve L2 için de yeniden kullanılabilir.
Paylaşılan sıralayıcı ve tabanlı toplamanın dezavantajları ve bunların uygulama senaryoları.
Seçenek
Bu tekliften şikayetçi olmak istiyorum, paylaşılan sıralayıcı ile ilgili teklife ikna olmadım. Tabii henüz emekleme aşamasındalar ve gelecekte bu tasarımlar gelişirse, onları desteklemem tamamen mümkün. Sadece şu anki form bana inandırıcı gelmiyor. Bir çok neden var.
İlk olarak, bana göre, paylaşılan bir sıralayıcının ana değer önerisi, kullanıcıların Scroll veya Starknet gibi genel amaçlı toparlamalar arasında atomik birleştirilebilirlik kazanmasına izin vermektir. Ancak sorun şu ki, atomik birleştirilebilirliğe sahipseniz, toplamanız, birleştirdiğiniz en yavaş toplama kadar nihaidir. Dolayısıyla, Scroll'un Optimistic Rollup ile birleştiğini varsayarsak, Scroll'un son hali yedi gün olacaktır. ZKRollup'ın ana değer önermesi, nispeten hızlı bir kesinlik elde etmek olsa da, kullanıcılar dakikalar içinde L1'e çekilebilir. Ve bu durumda, temelde bundan vazgeçin.
Diğer bir dezavantaj ise, zincir dışı kesinlik istiyorsanız, bir L2 düğümü çalıştırmanız gerekir ve zincire gönderilen veriler L1 tarafından sonlandırıldığı sürece, yerel olarak L2'de kesinlik elde edersiniz. Her bir birleştirilmiş L2, tam bir düğüm çalıştırmazsa, yerel sonlandırmaya ulaşmak pratik olarak imkansızdır. Bu, bu sistemi çalıştırmanın Solana gibi bir sistemi çalıştırmaktan daha pahalı olabileceği anlamına gelir, çünkü aynı anda çalışan birden fazla tam düğümünüz vardır, kendi ek yükleri vb.
Bu nedenlerden dolayı, L2 için mantıklı olduğunu düşünmüyorum. L3 için biraz farklı çünkü birisi uygulamaya özel bir zincir oluşturmak istiyorsa ve ademi merkeziyetçilikle uğraşmak istemiyorsa. Diyelim ki bir oyun yapıyorum ve sadece oyunu inşa etmekle uğraşmak istiyorum, o zaman merkezi olmayan işleri dışarıdan temin edebilirim. Ama şu anda L2 için mantıklı olduğunu düşünmüyorum.
Temel toplamaya gelince, benim de endişelerim var. Örneğin, MEV'in kârını kanıtlayıcılarla nasıl paylaşıyorsunuz? Çünkü tahsis sorunu dikkate alınmaz ise, temel olarak L1 tüm MEV karlarını elde edebilir. Başka bir küçük şey de, onay süresinin L1'in onay süresine eşit olması, ki bu daha hızlı olamaz, 12 dakikadır. Başka bir sorun da, izinsiz olduğu için, birden çok Arayıcının aynı anda toplu işlem gönderebilmesidir, bu da merkezi sonuçlarla sonuçlanabileceği anlamına gelir. Çünkü inşaatçılar, bir araştırmacı diğerlerinden daha kolay bağlanırsa işlemlerini dahil etmeye teşvik edilir. Bu nedenle, sonunda sadece bir Arayıcı'nın L2 için gruplar önermesiyle sonuçlanabilir, bu çok iyi bir çözüm değildir, çünkü bu olursa, temelde başa döneriz.
Yaoqi
İlginç bir şekilde, aslında geçen hafta Espresso'nun kurucusu Ben ile bir telefon görüşmesi yaptım. Paylaşılan sıralayıcılar konusunda bunu çok tartışıyoruz. Toghrul'un da belirttiği gibi, paylaşılan bir sipariş sistemi için kullanım senaryoları hakkında bazı belirsizlikler olduğunu düşünüyorum. Bunun başlıca nedeni, genel amaçlı bir L2 için verimlilik, karmaşıklık ve ekonomi nedeniyle genellikle çok sayıda ayırıcıya sahip olmamamızdır. Ve yine de, ister paylaşılan bir sıralayıcı, tabanlı toplama veya yeniden alma için olsun, en iyi kullanım durumunun çoğunlukla RAS (Hizmet Olarak Toplama) veya çok sayıda toplama sunabileceğimiz bu tür platformlar için olduğunu düşünüyorum. Çok fazla toplama yoksa, dürüst olmak gerekirse, büyük bir sıralama ağına gerçekten ihtiyacımız yok. Bu toplamaların zaten kendi sıralayıcı sistemleri vardır ve yalnızca bazı genel L2'ler olduğunda zaten kendi toplulukları veya ortakları vardır. Gerçekten ayrı ve üçüncü taraf bir ağa sahip olmaları gerekmez. Ayrıca, her L2 için özelleştirme yapmanız gerektiğinden ve her L2'nin farklı bir test yığını olduğundan, bu üçüncü taraf ağ üzerinde bir yüktür. Bu, kendi ağınızda birçok değişiklik gerektirir.
Ama aynı zamanda, Toghrul'un bahsettiği gibi, bazı özel kullanım durumları için. Örneğin, sıralayıcı düzeyinde biraz birlikte çalışabilirlik istiyorsak, paylaşılan sıralayıcılar potansiyel bir yol olabilir. Örneğin, birden çok toplama için aynı sıralayıcı kullanılır. Bu durumda, bu sıralayıcı, A, B ve C toplaması arasında zincirler arası atomikliği sağlamak için temel olarak bazı çapraz toplama işlemlerini işleyebilir.
Ama durumu anlattığımda sorunu burada da görebilirsiniz. Bu paylaşılan sıralayıcılardan gerçekten çok sayıda olsaydı, yine bir darboğaz ve yeni bir tek başarısızlık noktası haline gelirlerdi. Bu sözde ortak düzenleyicilere çok fazla güç veriyoruz. Birçok toplamayı kontrol eden bir ağ gibi hale geliyorlar. Son olarak, bu paylaşımlı sıralayıcıyı merkezileştirmenin bir yolunu tekrar bulmamız gerekiyor.
Ama yine de, bence insanların giderek daha fazla sorunu keşfetmesi ve daha fazla çözüm üretmesi iyi bir şey. Sonuç olarak, her gün bu alandaki yenilikleri görmek heyecan verici. Tüm bu yeni çözümlerle, en azından tüm toplama alanını gerçekten merkezden dağıtmak için doğru yoldayız.
Abdel
Evet, ikinize de katılıyorum. Layer3 ve Lisk için daha mantıklı olduğunu düşünüyorum çünkü artık merkezi olmayan bir ağı teşvik etme sorumluluğunu üstlenmek istemiyorlar ve sıralayıcılar gibi şeyleri başlatmak için ortaklar bulmaları gerekiyor. Bu yüzden Lisk için mantıklı olduğunu düşünüyorum. Ama Toghrul gibi, Layer2 için henüz pek bir anlam ifade ettiğini düşünmüyorum.
Konu 4
Merkezi olmayan bir sipariş verenin MEV üzerinde nasıl bir etkisi olur?
Abdel
Starknet için merkezileştirme bağlamında herhangi bir MEV yapmıyoruz ve ilk gelen alır modelini benimsiyoruz. Yani ademi merkeziyet bağlamında, elbette daha sonra daha fazla MEV getirilecek. Ancak hangi oranın olduğunu söylemek için henüz çok erken çünkü bu aynı zamanda fikir birliği mekanizmasının tasarımına ve diğer yönlere de bağlı.
Seçenek
Ama mesele şu ki, MEV yapmasanız bile, Starknet'te hala bir miktar MEV oluyor olabilir. Eh, ademi merkeziyetçilik tek başına MEV'yi gerçekten azaltmaz veya MEV'yi artırmaz. Elbette, örneğin bir tür adil sıralama protokolü veya eşik şifreleme uygularsanız, o zaman evet, MEV'yi en aza indirirsiniz. Ama tamamen ortadan kaldıramazsınız. Benim felsefem şudur: MEV ortadan kaldırılamaz. Ama diyelim ki sadece bir BFT konsensüsü oluşturuyorsunuz veya bir BFT konsensüsü üzerine bir şeyler inşa ediyorsunuz. Bu aslında MEV'yi hiç etkilemez. MEV hala var, bu MEV'yi çıkarmak için arayıcının sıralayıcı ile nasıl çalıştığı sorusu olmalıdır.
Yaoqi
Sorun şu ki, ilk gelen alır modelinin bile zor kısımları var. Mempool'u bazı arayanlara gösterdiğimizde, hala daha fazla oynama avantajına sahip oluyorlar. Örneğin sıralayıcılar için, ofisinizin kapısında beklemeye eşdeğerdir. Dolayısıyla bu durumda, bir kullanıcı bir işlem gönderir göndermez, yalnızca önden çalıştırma veya bir sandviç saldırısı ile ilgili değil, bir tür arbitraj fırsatı gördüklerinde, bunu hemen mempool'da görebilirler. Böylece, ticaretlerini hızla başkalarının önüne koyabilirler. Bu nedenle, diğer arama yapanlara göre bir avantajları vardır.
Ama ademi merkeziyetçiliğe geri dönecek olursak, bence bu, başta tartıştığımız gibi, çoğunlukla sansüre karşı direnişle ilgili. Sıralayıcılar ekip tarafından yönetilir. Ekip, herkese karşı adil davrandıklarını söyleyebilir. Ancak bu kodda engellenmez. Dolayısıyla, bir P2P ağımız olabilirse, bu düğümlerin işlemlerimi incelediğini ve ardından diğer düğümlere gönderebileceğimizi hissedersek harika olur. Yani, gerçekten L2'de işlemlerin işlenmesinin adaletiyle ilgili.
MEV'lere gelince, çünkü son zamanlarda tek bir toplama içinde üretilen MEV'lere ek olarak, köprüler arasında üretilen bazı MEV'ler var. Bu nispeten merkezi olmayan sıralama ağında, MEV'yi çıkarmak için daha fazla fırsatınız olacak. Paylaşılan bir sipariş ağımız olduğunu varsayarsak, paylaşılan sipariş vereni işlemleri yeniden sıralaması için bir şekilde etkileyebilirseniz, temelde diğer herkese göre büyük bir avantajınız olur.
Paylaşılan sıralayıcı ağının avantajları ve dezavantajları vardır. Artı tarafta, rütbe sistemini daha da dağıtabiliriz. Ancak diğer taraftan, herkesin sıralayıcı olma fırsatı vardır. Yani, temelde ne isterlerse yapabilirler ve yine karanlık bir orman. Bu yüzden ademi merkeziyetçiliği getirdik ve ardından Ethereum'da karşılaştığımız benzer sorunlarla yüzleşmek zorunda kaldık. Bu nedenle, Flashbots ve Ethereum Vakfı çalışanları, PBS, ayrı teklifçiler ve oluşturucular ile ilerlemek ve ardından oluşturucu tarafında tek bir çözüm bulmaya çalışmak istiyor.
Yani soruna baktığımızda tek bir sorun değil. Artık bire bir sorun değil, altıya bir ve daha fazlası.