原文作者 |Vitalik

Derleme | Odaily Planet Günlük Nan Zhi

İyi bir blok zinciri kullanıcı deneyiminin önemli bir özelliği, hızlı işlem onay süresidir. Bugün, Ethereum, beş yıl öncesine göre önemli ölçüde gelişmiştir. EIP-1559 ve PoS'e (Birleşme) geçiş sayesinde istikrarlı blok süresi ile L1'de gönderilen işlemler genellikle 5-20 saniye içinde onaylanabilir ve kredi kartıyla ödeme yapmanın deneyimiyle aynıdır. Bununla birlikte, kullanıcı deneyimini daha da iyileştirmek değerlidir ve bazı uygulamalar yüzlerce milisaniye hatta daha kısa bir gecikme süresi gerektirebilir. Bu makale, Ethereum'un (işlem onay süresini iyileştirme) bazı pratik seçeneklerini ele alacaktır.

Mevcut Fikirler ve Teknolojilerin Özeti

Tek Yuva Nihai Durability

Şu anda Ethereum'un Gasper mutabakatı tek bir yuva (Slot) ve Epoch mimarisi kullanıyor. Her 12 saniyede bir yuva, bazı doğrulayıcılar zincirin başına oy verir ve 32 yuvada (6,4 dakika) tüm doğrulayıcılar bir kez oy kullanma şansına sahiptir. Bu oylar daha sonra PBFT benzeri bir mutabakat algoritmasındaki mesajlara dönüştürülür ve iki Epoch (12,8 dakika) sonra son derece güçlü bir ekonomik garanti olan bir şey olan finalite olarak verilir.

Son birkaç yılda mevcut yöntemimize giderek daha az memnunuz. Bu durumun başlıca nedenleri iki noktada yatmaktadır, ilk olarak bu yöntem çok karmaşıktır, yuva içi oylama mekanizması ve Epok içi nihai mekanizma arasında birçok etkileşim hatası bulunmaktadır, ikinci olarak 12.8 dakika çok uzun, kimse o kadar beklemek istemiyor.

Tek Yuvalı Finaty (SSF), Tendermint benzeri bir mekanizma kullanarak bu mimariyi değiştirir, burada blok N, blok N+1 oluşturulmadan önce nihai olarak belirlenir. Tendermint'ten ana farkımız, 'etkin olmayan sızıntı' mekanizmasını korumuş olmamızdır, bu da zincirin %33'ten fazla doğrulayıcı çevrimdışıyken çalışmaya devam etmesine ve kurtarmasına izin verir.

Tek yuvaltın en büyük zorluğu, bu her Ethereum stakeholder'ının her 12 saniyede iki mesaj yayınlaması gerektiği anlamına gelir, bu da zincir için büyük bir yük demektir. Bu sorunu hafifletmek için bazı akıllı fikirler var, bunlar arasında son zamanlarda sunulan Orbit SSF tasarısı da bulunuyor. Bu, 'en sonluk' sürecini belirgin bir şekilde hızlandırsa da, kullanıcıların 5-20 saniye beklemek zorunda olma gerçeğini değiştirmedi.

Rollup Ön Onay

Son birkaç yıl boyunca, Ethereum, rollup merkezli bir yol haritasını takip etti. Ethereum'un temel katmanı (L1) veri erişilebilirliğini ve diğer özellikleri desteklemek üzere tasarlanmıştır, ardından bu özellikler L2 protokolleri (rollups, validiums ve plazmalar gibi) tarafından kullanılabilir hale getirilir ve kullanıcılara Ethereum ile aynı düzeyde güvenlik sağlama imkanı sunar.

Bu, Ethereum ekosistemi içinde dikkat dağılımına neden oldu: Ethereum L1, sansür dirençli, güvenilir, istikrarlı ve belirli bir temel katmanın çekirdek işlevini koruma ve iyileştirme odaklıyken, L2, farklı kültürler ve teknolojiler aracılığıyla kullanıcılara daha doğrudan erişmeyi hedefliyor. Ancak bu yol izlendiğinde kaçınılmaz bir sorun ortaya çıkıyor: L2, kullanıcılara 5-20 saniyeden daha hızlı onaylama imkanı sunmayı umuyor.

Şu ana kadar, en azından teorik olarak, kendi 'Merkeziyetsiz Sıralayıcı' ağını oluşturmak, L2'nin sorumluluğundadır. Birkaç doğrulayıcı, her birkaç yüz milisaniyede bir blok için imza atabilir ve bu blokların arkasına yatırımlarını yapabilir. Sonunda, bu L2 bloklarının başlıkları L1'e yayınlanacaktır.

Ancak L2 doğrulayıcı seti "aldatılabilir": Çakışan bir B2 Blok imzalamadan ve B1'den önce on-chain göndermeden önce B1 Blok imzalayabilirler. Ancak bunu yaparlarsa, tespit edilecekler ve Stake varlıklarını kaybedecekler. Aslında, merkezi versiyonların gerçek örneklerini gördük, ancak diğer yandan rollups ademi merkeziyetçilik sipariş ağlarını geliştirmekte yavaş kaldılar. Tüm L2'lerin ademi merkeziyetçilik sıralamasına sahip olmasını istemenin haksızlık olduğunu iddia edebilirsiniz: rollups yepyeni bir L1 oluşturmakla hemen hemen aynı işi yapmalarını istiyoruz. Sonuç olarak, Justin Drake, tüm L2'lerin (ve L1'lerin) Ethereum çapında paylaşılan bir ön onay mekanizması kullanmasına izin verecek bir yaklaşımı teşvik ediyor: temel ön onay.

Temel Onay

Temel ön onaylama yöntemi, Ethereum önericilerinin MEV ile ilgili son derece karmaşık katılımcılar olduğunu varsayar. Ön onaylama tabanlı yöntem, bu karmaşıklığı kullanarak, bu önericilerin, ön onaylama hizmeti sağlama sorumluluğunu kabul etmeleri için teşvik edilir.

Bu yöntemin temel fikri, kullanıcıların işlemin bir sonraki bloğa dahil edileceğini hemen garanti altına almak için ek ücret sağlayabileceği standartlaştırılmış bir protokol oluşturmaktır ve işlemin sonuçlarını gerçekleştirmek için beyanda bulunmaktır. Öneren, herhangi bir kullanıcıya yaptığı herhangi bir taahhüdü ihlal ederse cezalandırılabilir.

Belirtilen gibi, L1 işlemlerini önceden onaylamak için garanti sağlamaya dayalı. Eğer rollups 'temel' ise, o zaman tüm L2 blokları L1 işlemleridir, bu nedenle aynı mekanizma herhangi bir L2 için önceden onay sağlamak için kullanılabilir.

Aslında ne görüyoruz?

Varsayalım ki tek slot nihai oluşurduk. Orbit gibi bir teknoloji kullanarak her slot için imzalayan doğrulayıcı sayısını azaltırız, ancak çok azaltmayız, böylece 32 ETH'lik en düşük stake sınırlamasını azaltma hedefinde ilerleyebiliriz. Slot süresi 16 saniyeye kadar artabilir, ardından rollup önceden onay veya temel önceden onay kullanarak kullanıcılara daha hızlı onay sağlarız. Sonuçta ne elde ederiz: bir dönem-slot yapısı.

Çağ ve yuva mimarisinden kaçınmanın bu kadar zor görünmesinin derin bir felsefi nedeni var: Bir şey üzerinde kaba bir anlaşmaya varmak, bir şey üzerinde kaba bir anlaşmaya varmak için gerekenden daha az zaman alır, maksimum "ekonomik kesinlik" protokol ulaşmaktan daha az zaman alır.

Birincil sebep, düğüm sayısıdır. BLS toplama ve yakında çıkacak olan ZK-STARK'lar sayesinde eski lineer merkeziyetsizlik/sonluk zamanı/maliyet dengesi şimdi daha ılımlı görünse de, aşağıdaki nedenler göz ardı edilemez:

• "Yaklaşık konsensüs", sadece birkaç düğüm gerektirirken, ekonomik finalite çoğu düğüm gerektirir.
• Bir kez düğüm sayısı belirli bir ölçeği aştığında, imzaları toplamak için daha fazla zaman harcamanız gerekebilir.

Bugünün Ethereum'unda, 12 saniye yuvası üç alt yuvasa ayrılır: Blok yayını ve dağıtımı, kanıt, kanıt birleşimi. Kanıtlayıcı sayısı önemli ölçüde azalırsa, iki alt yuvaya düşürüp 8 saniye yuva süresini kullanabiliriz. Diğer bir, daha pratik ve daha büyük faktör, düğümün "kalitesi"dir. Başka bir büyük faktör de düğümün "kalitesi"dir. Yaklaşık bir protokol sağlamak için uzmanlaşmış düğüm alt kümesine de güvenebilirsek (ve nihai olarak belirleme yapmak için tam doğrulayıcı kümesini kullanmaya devam edersek), bunu yaklaşık 2 saniyeye indirebiliriz.

Bu nedenle, benim görüşüme göre, epoch-and-slot mimarisi açıkça doğrudur, ancak tüm epoch-and-slot yapıları eşit değildir, tasarım alanının daha kapsamlı bir şekilde keşfedilmesi değerlidir. Derinlemesine araştırılmaya değer olan bir yönelim, Gasper gibi sıkı bir şekilde entegre edilmek yerine, iki mekanizma arasında daha güçlü bir odak ayrımı bulunmaktadır.

L2 nasıl yapılmalı?

Benim görüşüme göre, L2 şu anda üç mantıklı stratejiye sahip:

• Teknik olarak ve ruhsal olarak 'temellidir'. Yani, Ethereum'un temel katman teknoloji özelliklerini ve değerlerini (yüksek derecede merkeziyetsizlik, sansüre karşı vb.) optimize etmektedirler. En basit şekilde, bu rollup'ları 'marka parçacıkları' olarak düşünebilirsiniz, ancak aynı zamanda yeni bir sanal makine tasarımında ve diğer teknoloji iyileştirmelerinde büyük ölçüde deney yapabilirler.
• Bir 'blok zinciri iskelesi ile donatılmış sunucu' haline gelin ve onu tamamen kullanın. Sunucudan başlayıp STARK geçerlilik kanıtı ekleyerek sunucunun kurallara uygunluğunu sağlayın; kullanıcının çıkma veya zorla işlem yapma hakkını garanti edin; koordinasyonlu büyük çıkışlar veya sıralama oylarını değiştirerek özgür seçim hakkını koruyun, böylece çoğu blockchain faydasını elde etmiş olursunuz, aynı zamanda sunucunun çoğu verimliliğini de korursunuz.
• Kompromis yöntemi: Ethereum, 100 düğüm içeren hızlı bir zincirleme, ek etkileşim ve güvenlik sağlar. Bu, birçok L2 projesinin mevcut yol haritasıdır.

Bazı uygulamalar için (örneğin ENS, Gizli Anahtar Depolama, bazı ödeme protokolleri), 12 saniyelik blok süresi yeterli olacaktır. Uygulanamayan uygulamalar için tek çözüm, epoch-and-slot mimarisidir. Üç durumda da 'epoch', Ethereum'un SSF'sidir, ancak slot yukarıdaki üç durumda farklıdır:

• Bir Ethereum doğal epoch-and-slot mimarisi
• Sunucu önceden onaylandı
• Komite önceden onayladı

Bir kilit sorun, 1. sınıfta ne kadar iyi yapabileceğimizdir? Özellikle, eğer çok iyi hale gelirse, o zaman 3. sınıfın anlamı o kadar büyük olmayacaktır. Çünkü tüm "tabanlı" çözümler, plazma ve validium gibi off-chain verileri L2 gibi uygulanamaz, bu nedenle 2. sınıf sonsuza dek var olacaktır. Bir Ethereum doğal epok ve slot mimarisi, slot zamanını 1 saniyeye düşürebilirse, o zaman 3. sınıfın alanı çok daha küçük hale gelecektir.

Bugün, bu soruların son cevabına hala çok uzaktayız. Bir kilit soru şudur: Blok önerenlerinin ne kadar karmaşık hale geleceği, hala oldukça belirsiz bir alan olmaya devam ediyor. Orbit SSF gibi tasarımlar çok yenilikçi olduğundan, örneğin Orbit SSF'i epoch-and-slot içindeki epoch gibi bir tasarım alanı olarak kullanmak hala tam olarak keşfedilmeye değerdir. Sahip olduğumuz seçenekler ne kadar fazlaysa, L1 ve L2 kullanıcıları için o kadar iyi yapabiliriz, L2 geliştiricilerinin işini basitleştirebiliriz.