*Orijinal Başlık ‘Zamanlar ve yuvaların tamamı aşağıya: Ethereum kullanıcılarına daha hızlı işlem onay süreleri verme yolları'

İyi bir blockchain kullanıcı deneyiminin önemli özelliklerinden biri hızlı işlem onaylama süreleridir. Bugün, Ethereum, beş yıl öncesine göre çok daha iyi bir durumda. Bunun sebebi, EIP-1559ve sabit blok süreleri sonrası Birleşme, kullanıcılar tarafından gönderilen işlemler L1'de güvenilir bir şekilde 5-20 saniye içinde onaylanır. Bu, kredi kartı ile ödeme yapma deneyimiyle yaklaşık rekabet eder. Bununla birlikte, kullanıcı deneyimini daha da geliştirmenin bir değeri var ve bazı uygulamalar, yüzlerce milisaniye veya hatta daha az gecikmeleri kesin olarak gerektirir. Bu yazı, Ethereum'un sahip olduğu bazı pratik seçenekleri ele alacaktır.

Mevcut fikirlerin ve tekniklerin genel bir bakışı

Tek yuvalı kesinlik

Bugün, Ethereum'un Gasperkonsensüs, bir yuva ve dönem mimarisi kullanır. Her 12 saniyelik yuvada, doğrulayıcıların bir alt kümesi zincirin başıyla ilgili bir oy yayımlar ve 32 yuvanın (6.4 dakika) süresince, tüm doğrulayıcılar bir kez oy kullanma şansı elde eder. Bu oylar daha sonra belirsiz bir şekilde mesajlar olarak yeniden yorumlanır.PBFT benzeriKonsensüs algoritması, iki dönem (12.8 dakika) sonra sonluk olarak adlandırılan çok zor bir ekonomik güvence sağlar.

Son birkaç yıl boyunca, mevcut yaklaşıma giderek daha fazla rahatsız olduk. Ana nedenler şunlardır: (i) karmaşık ve slot-slot oylama mekanizması ile dönem-dönem nihaiyet mekanizması arasında birçok etkileşim hatası bulunmaktadır ve (ii) 12.8 dakika çok uzun bir süre ve kimse o kadar beklemek istemiyor.

Tek yuvalı kesinlik, bu mimariyi çok daha benzer bir mekanizma ile değiştirirTendermint uzlaşısı, N+1 bloğu yapılmadan önce N bloğu sonlandırılır. Tendermint'ten ana sapma, "etkinlik dışı sızıntı“ mekanizma, zincirin devam etmesine ve eğer doğrulayıcıların 1/3'ten fazlası çevrimdışı olursa kurtarılmasına izin verir.

Önde gelen önerilen bir diyagramtek yuvalı kesinlik tasarımı_

SSF ile ilgili temel zorluk, saf bir şekilde, her bir Ethereum staker'ın her 12 saniyede iki mesaj yayınlamasını gerektiği gibi görünüyor ki, bu da zincirin işlemesinde oldukça fazla yük olacaktır. akıllı fikirlerbunun nasıl hafifletileceği, son derece yakın zamanda dahilOrbit SSFAncak yine de, bu, "kesinlik" nin daha hızlı hale gelmesiyle UX'i önemli ölçüde geliştirirken, kullanıcıların 5-20 saniye beklemesi gerektiği gerçeğini değiştirmez.

Rollup ön onaylamaları

Son birkaç yıldır, Ethereum takip ediyor.rollup-merkezli yol haritası, Ethereum temel katmanını (L1) desteklemek üzerine tasarlamakveri erişilebilirliğive diğer işlevler, bu nedenle katman 2 protokolleri tarafından kullanılabilir.rolluplar (ancak aynı zamanda validiumsveplazmalar) kullanıcıların Ethereum kadar güvenlik düzeyi sunabilen, ancak çok daha yüksek ölçekte bir platform sağlayabilir.

Bu bir oluşturur.ayrıştırma konusuEthereum ekosistemi içinde: Ethereum L1, sansürsüz olmaya, güvenilir, istikrarlı olmaya ve belirli bir temel işlev çekirdeğini korumaya ve geliştirmeye odaklanabilirken, L2'ler daha doğrudan kullanıcılara ulaşmaya odaklanabilir - farklı yollarla.kültürelve teknolojik takaslar. Ama bu yolu izlerseniz, kaçınılmaz bir sorun ortaya çıkar: L2'ler, 5-20 saniyeden çok daha hızlı onaylar isteyen kullanıcılara hizmet etmek istiyor.

Şimdiye kadar, en azından retorik açısından, L2'lerin kendi “merkezi olmayan sıralama” ağlarını oluşturmaları gerekiyordu. Daha küçük bir grup doğrulayıcı, belki de her birkaç yüz milisaniyede bir bloğu onaylar ve bu bloklara “bahis” yaparlardı. Sonunda, bu L2 bloklarının başlıkları L1'e yayınlanır.

L2 doğrulayıcı setleri hile yapabilir: önce blok B1'i imzalayabilirler ve sonra çelişen blok B2'yi daha sonra imzalayıp B1'den önce zincire taşıyabilirler. Ancak bunu yaparlarsa yakalanır ve mevduatlarını kaybederler. Uygulamada, bunun merkezi versiyonlarını gördük, ancak rollups'un merkezi olmayan sıralama ağlarını geliştirmesi yavaş oldu. Ve L2'lerin hepsinin merkezi olmayan sıralamayı yapmasını talep etmek haksız bir anlaşma olabilir: rollup'ların temelde tamamen yeni bir L1 oluşturmakla aynı işin çoğunu yapmalarını istiyoruz. Bu ve diğer nedenlerden dolayı Justin Drake, tüm L2'lere (ve L1'e) bir Ethereum genelinde ön onay mekanizmasına erişim sağlamanın bir yolunu teşvik etmektedir: tabanlı ön onaylar.

Ön doğrulamalara dayalı

Temel ön onay yaklaşımı, Ethereum önerenlerinin MEV ile ilgili nedenlerden dolayı son derece sofistike aktörler haline geleceğini varsayar (bkz.buradaMEV açıklamam için ve ayrıca bakın gerçekleştirme biletleriÖneri hattının (önerilerin bir satırı) temel ön onay yaklaşımı, bu karmaşıklıktan yararlanarak, bu karmaşık önerenlerin ön onay hizmeti sunma sorumluluğunu kabul etmelerini teşvik ederek faydalanır.

Temel fikir, bir kullanıcının bir sonraki bloğa dahil edileceğine dair anında bir garanti karşılığında ek bir ücret teklif edebileceği standartlaştırılmış bir protokol oluşturmaktır, muhtemelen bu işlemin yürütülmesiyle ilgili bir iddia ile birlikte. Teklif sahibi, herhangi bir kullanıcıya verdikleri herhangi bir sözü ihlal ederse, cezalandırılabilir.

Tarif edildiği gibi, önceden onaylama, L1 işlemlerine garanti sağlar. Eğer rollups"tabanlı", sonra tüm L2 blokları L1 işlemleri olduğundan, aynı mekanizma herhangi bir L2 için ön onaylar sağlamak için kullanılabilir.

Burada aslında neye bakıyoruz?

Varsayalım ki tek yuva kesinlik uygularız. Kullanırız Yörünge-benzeri teknikleri kullanarak, her yuva başına imzalayan doğrulayıcı sayısını azaltmak, ancak çok fazla değil, böylece 32 ETH staking minimumunu azaltma ana hedefinde de ilerleme kaydedebiliriz. Sonuç olarak, belki de yuva süresi yukarı doğru kayar, 16 sn'ye. Daha sonra kullanıcıların daha hızlı güvenceler almasını sağlamak için ya rollup ön onaylarını ya da temel ön onayları kullanırız. Şimdi ne var? Bir dönem ve yuva mimarisi.

"Aynı resim bunlar" mizahı artık oldukça fazla kullanılıyor, bu yüzden sadece yıllar önce çizdiğim Gasper'ın slot ve dönem mimarisini açıklamak için eski bir diyagramı ve L2 ön onaylarının bir diyagramını yan yana koyacağım ve umarım bu noktayı anlatacaktır.

Epoch ve yuva mimarilerinin neden kaçınılmaz göründüğüne dair derin bir felsefi neden var gibi gözüküyor: bir şey üzerinde yaklaşık bir anlaşmaya varmak, onun üzerinde maksimum derecede sertleşmiş "ekonomik nihaiyet" anlaşmasına varmaktan daha az zaman alır.

Eski doğrusal yapının nedeni, düğüm sayısının az olmasıdır.@VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735">decentralization / finality time / overhead tradeoff, hyper-optimize edilmiş BLS toplama ve yakın gelecekte ZK-STARK'lar nedeniyle şimdi daha hafif görünüyor, temel olarak hala doğrudur ki:

1. “Yaklaşık anlaşma”, sadece birkaç düğüm gerektirirken, ekonomik kesinlik tüm düğümlerin önemli bir kısmını gerektirir.
2. Bir düğüm sayısı belirli bir boyutun üzerine çıktığında, imzaları toplamak için daha fazla zaman harcamanız gerekir.

Ethereum'da bugün, 12 saniyelik bir slot üç alt slot'a bölünür, (i) blok yayını ve dağıtımı, (ii) onaylama ve (iii) onaylama toplama için. Eğer onaylayıcı sayısı çok daha düşükse, iki alt slot'a düşebilir ve 8 saniyelik bir slot süresine sahip olabiliriz. Başka, ve gerçekçi olarak daha büyük bir faktör, düğümlerin 'kalitesi'. Eğer yaklaşık anlaşmalarda profesyonelleşmiş bir alt küme düğümlere de güvenebilirsek (ve finalite için tam doğrulayıcı setini hala kullanabiliriz), muhtemelen bunu ~2 saniyeye düşürebilirdik.

Bu yüzden, bana öyle geliyor ki (i) yuva ve çağ mimarileri açıkça doğrudur, ancak (ii) tüm yuva ve çağ mimarilerinin eşit olmadığı ve tasarım alanını daha tamamen keşfetmenin değeri olduğu konusunda bir değer vardır. Özellikle, Gasper gibi sıkı bir şekilde birleştirilmemiş seçenekleri keşfetmek ve bunun yerine iki mekanizma arasında daha güçlü bir sorumluluk ayrımı olduğu durumları keşfetmek değerlidir.

L2'ler ne yapmalı?

Benim görüşüme göre, şu anda L2'lerin izleyebileceği üç makul strateji var:

1. Hem teknolojik hem de ruhsal olarak 'tabana dayalı' olun. Yani, Ethereum tabaka katmanının teknik özellikleri ve değerleri (yüksek merkezi olmayanlık, sansür direnci, vb.) için geçiş kanalları olmaya optimize ederler. En basit halleriyle, bu rollup'ları 'markalı parçalar' olarak düşünebilirsiniz, ancak bunlar bundan çok daha iddialı olabilir ve yeni sanal makine tasarımları ve diğer teknik iyileştirmelerle oldukça deneysel olabilirler.
2. Gururla bir “blokzincir iskeletli sunucu” olun ve en iyisini ortaya çıkarın. Eğer bir sunucudan başlarsanız ve ardından (i) sunucunun kuralları takip ettiğinden emin olmak için STARK geçerlilik kanıtları eklerseniz, (ii) kullanıcının çıkma veya işlemleri zorlama hakkını garanti altına alırsınız ve muhtemelen (iii) koordine edilmiş toplu çıkış veya sıralayıcıyı değiştirmek için oy kullanma yeteneği aracılığıyla kolektif seçim özgürlüğü, o zaman zaten onchain olmanın çoğu faydasını elde etmiş olursunuz, ancak sunucunun çoğu verimliliğini koruyarak.
3. Uzlaşma yaklaşımı: Ethereum'un ekstra iş birliği ve güvenlik sağladığı yüz düğümlü hızlı bir zincir. Bu, birçok L2 projesinin de-facto mevcut yol haritasıdır.

Bazı uygulamalar için (ör. ENS, anahtar depoları), bazı ödemeler), 12 saniyelik blok süresi yeterlidir. Bu tür uygulamalar için tek çözüm, bir yuva ve dönem mimarisidir. Üç durumda da, 'dönemler' Ethereum'un SSF'sidir (belki de bu akronimi 'tek yuva' yerine başka bir şeyi ifade etmek için kullanabiliriz, örneğin 'Güvenli Hızlı Kesinlik' olabilir). Ancak, yuvalar yukarıda belirtilen üç durumda farklıdır:

1. Ethereum'e özgü bir yuva ve dönem mimarisi
2. Sunucu ön onaylamaları
3. Komite ön onayları

Önemli bir soru, kategori (1)'de bir şeyi ne kadar iyi yapabiliriz? Özellikle, eğer gerçekten iyi olursa, o zaman kategori (3) eskisi kadar anlam ifade etmiyormuş gibi geliyor. Kategori (2) her zaman var olacaktır, çünkü en azından "tabanlı" olan herhangi bir şey, plazmalar ve validiumlar gibi zincir dışı veri L2'leri için çalışmaz. Ancak, Ethereum'a özgü bir slot ve epoch mimarisi 1 saniyelik "slot" (yani ön onay) sürelerine inebilirse, kategori (3) için alan biraz daha küçülür.

Bugün, bu soruların kesin cevaplarına sahip olmaktan oldukça uzaktayız. Ana soru - blok önerenler ne kadar sofistike olacak - hala oldukça belirsiz bir alan olarak kalmaktadır. gibi tasarımlarOrbit SSFçok yeni olduğundan, Orbit SSF gibi bir şeyin dönem olduğu yuva ve dönem tasarımlarının tasarım alanı hala oldukça keşfedilmemiş görünüyor. Sahip olduğumuz daha fazla seçenek, hem L1 hem de L2 kullanıcıları için daha iyi yapabileceğimiz anlamına gelir ve L2 geliştiricilerinin işini daha da basitleştirebiliriz.

Disclaimer:

1. Bu makale [den alınmıştırvitalik]. Özgün Başlık 'Epochs ve slotlar tamamen aşağıya doğru: Ethereum kullanıcılarına daha hızlı işlem onaylama süreleri sunmanın yolları'. Tüm telif hakları özgün yazarın [adına aittir.vitalik*]. Bu yeniden baskıya itirazlar varsa, lütfen Gate Öğrenekip, ve onlar hızla halledecek.
2. Sorumluluk Reddi: Bu makalede yer alan görüşler yalnızca yazarına aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirileri Gate Learn ekibi tarafından yapılır. Belirtilmedikçe, çevrilen makalelerin kopyalanması, dağıtılması veya kopyalanması yasaktır.