Yazan: Vitalik Buterin
Derleyen: Alex Liu, Öngörü Haberleri
Geri bildirimleri ve değerlendirmeleri için Justin Drake, Hsiao-wei Wang, @antonttc, Anders Elowsson ve Francesco'ya özellikle teşekkür ederiz.
Başlangıçta "Birleşme", Ethereum protokolünün tarihindeki lansmanından bu yana en önemli olayı ifade ediyordu: Uzun zamandır beklenen ve zor kazanılan Proof of Work'ten (PoW) Proof of Stake'e (PoS) geçiş. Bugün, Ethereum neredeyse iki yıldır istikrarlı ve işleyen bir hisse kanıtı sistemi olmuştur ve bu hisse kanıtı sistemi istikrar , performans ve merkezileşme risklerinden kaçınma açısından son derece iyi performans göstermiştir. Bununla birlikte, hisse senedinin kanıtlanmasının iyileştirilmesi gereken bazı önemli alanlar hala vardır.
2023 yol haritam onu birkaç parçaya ayırıyor: kararlılık, performans ve küçük doğrulayıcılar için erişilebilirlik gibi teknik özelliklerde iyileştirmelerin yanı sıra merkezileşmenin risklerini ele alan ekonomik değişiklikler. Birincisi "Birleşme" unvanını devraldı ve ikincisi "Musibet" in bir parçası oldu.
Bu makale “Birleştirme” kısmına odaklanacaktır: Proof of Stake'in teknik tasarımı başka nerede geliştirilebilir ve bu hedefe ulaşmanın yolları nelerdir?
Bu, Proof of stake'in yapabileceği şeylerin kapsamlı bir listesi değildir; daha ziyade aktif olarak değerlendirilen fikirlerin bir listesidir.
Tek Slot kesinliği ve staking demokratikleşmesi
Hangi sorunu çözmeye çalışıyoruz?
Günümüzde bir bloğu tamamlamak 2-3 dönem (~15 dakika) sürüyor ve staker olabilmek için 32 ETH gerekiyor. Bu başlangıçta üç hedefi dengelemek için yapılan bir uzlaşmaydı:
- Staking'e katılabilecek doğrulayıcıların sayısını en üst düzeye çıkarın (bu, doğrudan stake etmek için gereken minimum ETH'nin en aza indirilmesi anlamına gelir)
- Sonlandırma süresini en aza indirin
- Bir düğüm çalıştırmanın ek yükünü (bu durumda diğer tüm doğrulayıcı imzalarını indirme, doğrulama ve yeniden yayınlama maliyetini) en aza indirin
Bu üç hedef birbiriyle çelişiyor: Ekonomik kesinliği mümkün kılmak için (yani bir saldırganın sonlandırılmış bir bloğu tersine çevirmek için çok fazla ETH yakması gerekir), sonlandırma gerçekleştiğinde her doğrulayıcıya ihtiyacınız var. Her iki mesajı da imzalayın. Yani çok sayıda doğrulayıcınız varsa ya tüm imzaları işlemek için uzun bir zamana ihtiyacınız vardır ya da tüm imzaları aynı anda işlemek için çok güçlü düğümlere ihtiyacınız vardır.
Bu üç hedef birbiriyle çelişiyor: Ekonomik kesinliği mümkün kılmak için (yani bir saldırganın sonlandırılmış bir bloğu tersine çevirmek için çok fazla ETH yakması gerekir), sonlandırma gerçekleştiğinde her doğrulayıcıya ihtiyacınız var. Her iki mesajı da imzalayın. Yani çok sayıda doğrulayıcınız varsa ya tüm imzaları işlemek için uzun bir zamana ihtiyacınız vardır ya da tüm imzaları aynı anda işlemek için çok güçlü düğümlere ihtiyacınız vardır.
Bu üç hedef birbiriyle çelişiyor: Ekonomik kesinliği mümkün kılmak için (yani bir saldırganın sonlandırılmış blokları kurcalamak için çok fazla ETH yakması gerekir), sonlandırma gerçekleştiğinde her doğrulayıcıya ihtiyacınız var. Her iki mesajı da imzalayın. Yani çok sayıda doğrulayıcınız varsa ya tüm imzaları işlemek için uzun bir zamana ihtiyacınız vardır ya da tüm imzaları aynı anda işlemek için çok güçlü düğümlere ihtiyacınız vardır.
Tüm bunların Ethereum'un temel amacına bağlı olduğunu unutmayın: Başarılı saldırıların bile saldırgana yüksek maliyetler getirmesini sağlamak. "Ekonomik kesinlik" terimiyle kastedilen budur. Eğer bu hedefimiz yoksa, her bloğu sonlandıracak bir komiteyi rastgele seçerek bu sorunu çözebiliriz. Algorand gibi ekonomik sonuca ulaşmaya çalışmayan zincirler genellikle bunu yapar . Ancak bu yaklaşımdaki sorun, eğer bir saldırgan doğrulayıcıların %51'ini kontrol ederse, saldırıyı çok düşük bir maliyetle gerçekleştirebilir (sonlandırılmış blokları kurtarabilir, sansürleyebilir veya sonlandırmayı geciktirebilir): sadece . Komite içerisinde bir kişi bir saldırıya katıldığı için tespit edilebilir ve ister kesme yoluyla ister sosyal olarak koordine edilen yumuşak çatal yoluyla cezalandırılabilir. Bu, bir saldırganın zincire defalarca saldırabileceği ve her saldırı sırasında hisselerinin yalnızca küçük bir kısmını kaybedebileceği anlamına gelir. Bu nedenle, eğer ekonomik bir kesinlik istiyorsak, komiteye dayalı basit bir yaklaşım işe yaramayacaktır ve ilk bakışta doğrulayıcının tam katılımına ihtiyacımız var.
İdeal olarak, iki alanda statükoyu iyileştirirken ekonomik kesinliği korumak istiyoruz:
- Blokları 15 dakika yerine tek bir slotta tamamlayın (ideal olarak mevcut süreyi 12 saniye olarak koruyun veya hatta azaltın).
- Doğrulayıcıların 1 ETH ile stake etmesine izin ver (32 ETH'den düştü)
İlk hedefin iki hedefi var ve bunların her ikisi de "Ethereum'un özelliklerini (daha merkezi) performans odaklı L1 zincirlerinin özellikleriyle hizalamak" olarak görülebilir.
Birincisi, tüm Ethereum kullanıcılarının kesinlik mekanizması aracılığıyla elde edilen daha yüksek düzeyde güvenlik garantilerinden gerçekten faydalanmasını sağlar. Günümüzde çoğu kullanıcı, 15 dakika beklemek istemedikleri için bunu yapmıyor; tek slotlu sonlandırmada kullanıcılar, neredeyse işlem onaylanır onaylanmaz işlemlerinin tamamlandığını görüyor. İkincisi, kullanıcıların ve uygulamaların zincirin tersine çevrilmesi olasılığı konusunda endişelenmesine gerek kalmaması durumunda protokolü ve çevreleyen altyapıyı basitleştirir (nispeten nadir görülen hareketsizlik sızıntısı durumu hariç).
İkinci hedef ise solo stakerları destekleme arzusundan kaynaklanmaktadır. Art arda yapılan anketler, daha fazla insanın tek başına stake etmesini engelleyen ana faktörün minimum 32 ETH olduğunu defalarca gösteriyor. Minimum miktarın 1 ETH'ye düşürülmesi bu sorunu çözecek ve diğer sorunlar bireysel stake etmeyi sınırlayan baskın faktör haline gelecektir.
İkinci hedef ise solo stakerları destekleme arzusundan kaynaklanmaktadır. Art arda yapılan anketler, daha fazla insanın tek başına stake etmesini engelleyen ana faktörün minimum 32 ETH olduğunu defalarca gösteriyor. Minimum miktarın 1 ETH'ye düşürülmesi bu sorunu çözecek ve diğer sorunlar bireysel stake etmeyi sınırlayan baskın faktör haline gelecektir.
Bir zorluk var: Daha hızlı sonuçlandırma ve daha demokratikleştirilmiş stake etme hedefleri, genel giderleri en aza indirme hedefiyle çelişiyor. Aslında tek slot kesinliğiyle başlamamamızın tek nedeni bu gerçektir. Ancak son araştırmalar bu sorunu çözmenin bazı olası yollarını önermektedir.
Nedir ve nasıl çalışır?
Tek yuvalı kesinlik, bir yuvadaki blokları sonlandırmak için bir konsensüs algoritmasının kullanılmasını içerir. Bu kendi başına zor bir hedef değil: Tendermint fikir birliği gibi birçok algoritma bunu zaten başarıyor. Tendermint'in desteklemediği, Ethereum'a özgü zorunlu bir özellik, hareketsizlik sızıntısıdır ; bu, doğrulayıcıların 1/3'ünden fazlası çevrimdışı olsa bile zincirin çalışmaya devam etmesine ve sonunda iyileşmesine olanak tanır. Neyse ki bu sorun çözüldü: Tendermint tarzı fikir birliğini hareketsizlik sızıntılarına uyum sağlayacak şekilde değiştirmeye yönelik öneriler zaten mevcut .
Önde gelen tek slotlu nihai teklif
Sorunun en zor kısmı, çok yüksek düğüm operatörü yüküne yol açmadan, çok yüksek doğrulayıcı sayımlarıyla tek yuva kesinliğinin nasıl çalışacağını bulmaktır. Bunun için bazı önde gelen çözümler var:
- Seçenek 1: Kaba kuvvet - muhtemelen ZK-SNARK kullanarak daha iyi bir imza toplama protokolü üzerinde çalışın; bu, aslında yuva başına milyonlarca doğrulayıcının imzalarını işlememize olanak tanır.
Daha iyi toplama protokolleri için önerilen tasarımlardan biri olan Horn
Seçenek 2: Yörünge komiteleri — Aradığımız saldırı maliyeti özelliklerini koruyacak şekilde, rastgele seçilen orta büyüklükteki komitelerin zincirin sonlandırılmasından sorumlu olmasına olanak tanıyan yeni bir mekanizma.
Orbit SSF hakkında düşünmenin bir yolu, x=0'dan (Algorand tarzı komite, ekonomik kesinlik yok) x=1'e (Ethereum'un statükosu) kadar iki seçenek arasında bir uzlaşma alanı açmasıdır ve ortada bir şey vardır. "Ethereum hala çok güvenli olmak için yeterli ekonomik kesinliğe sahip, ancak aynı zamanda verimlilik avantajları elde etmek için her yuvaya katılmak için yalnızca orta büyüklükte rastgele bir doğrulayıcı örneğine ihtiyacımız var."
Orbit, küçük doğrulayıcılara bir rol verirken mümkün olduğu kadar ekonomik kesinlik elde etmek için doğrulayıcı mevduat boyutlarında önceden var olan heterojenlikten yararlanır. Ek olarak Orbit, bitişik kurullar arasında yüksek derecede örtüşmeyi sağlamak için yavaş komite rotasyonunu kullanıyor, böylece ekonomik nihailiğinin komite değişimi sınırları içinde kalmasını sağlıyor.
- Seçenek 3: İki seviyeli stake etme - Biri daha yüksek para yatırma gereksinimlerine sahip, diğeri daha düşük para yatırma gereksinimlerine sahip olmak üzere iki tür rehin verenin bulunduğu bir mekanizma. Ekonomik kesinliğin sağlanmasında yalnızca daha yüksek mevduat katmanları doğrudan rol oynar. Alt para yatırma katmanlarının hak ve sorumluluklarının tam olarak ne olduğuna dair çeşitli öneriler var (örneğin Rainbow staking gönderisine bakın). Ortak fikirler şunları içerir:
- Staking'i daha yüksek seviyedeki bir staker'a devretme hakkı
- Her bloğu onaylamak ve sonuçlandırmak için bazı rastgele düşük seviyeli stakerlar gerekir
- Dahil edilme listeleri oluşturma hakkı
Mevcut araştırmalarla bağlantılar nelerdir?
- Tek slot kesinliğine giden yollar (2022): https://notes.ethereum.org/@vbuterin/single_slot_finality Tek slot kesinliğine doğru yollar (2022)
- Ethereum (2023) için tek slot kesinlik protokolü için somut bir öneri: https://eprint.iacr.org/2023/280 Ethereum tek slot kesinliği
- Yörünge SSF: https://ethresear.ch/t/orbit-ssf-solo-staking-friends-validator-set-management-for-ssf/19928
- Orbit tarzı mekanizmalar hakkında daha fazla analiz: https://ethresear.ch/t/vorbit-ssf-with-circular-and-spiral-finality-validator-selection-and-distribution/20464 Orbit tarzı mekanizmalar hakkında daha fazla analiz
- Horn, imza toplama protokolü (2022): https://ethresear.ch/t/horn-collecting-signatures-for-faster-finality/14219 Horn, imza toplama protokolü (2022)
- Büyük ölçekli fikir birliği için imza birleştirme (2023): https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386?u=asn Büyük ölçekli fikir birliği için imza birleştirme (2023)
- Khovratovich ve diğerleri tarafından önerilen imza toplama protokolü: https://hackmd.io/@7dpNYqjKQGeYC7wMlPxHtQ/BykM3ggu0#/ Khovratovich ve diğerleri tarafından önerilen imza toplama protokolü
- STARK tabanlı imza toplama (2022): https://hackmd.io/@vbuterin/stark_aggregation STARK tabanlı imza toplama (2022)
- Rainbow Staking: https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683 Rainbow Staking
Başka ne yapılması gerekiyor, ne gibi tavizler verilmesi gerekiyor?
Aralarından seçim yapabileceğiniz dört ana yol vardır (karma bir yol da kullanabiliriz):
- statükoyu korumak
- Şiddetli SSF
- Yörünge SSF
- İki seviyeli stake etme özelliğine sahip SSF
(1) hiçbir iş yapmamak ve olduğu gibi bırakmak anlamına gelir, ancak bu, Ethereum'un güvenlik deneyimini ve stake merkezileştirme özelliklerini daha da kötüleştirir.
(2) Sorunları şiddetle çözmek için ileri teknolojiyi kullanın. Bunu başarmak için çok sayıda imzanın (1 milyondan fazla) çok kısa bir sürede (5-10 saniye) toplanması gerekir. Bu yaklaşımı düşünmenin bir yolu , kapsüllemenin karmaşıklığını tamamen benimseyerek sistem karmaşıklığını en aza indirmeyi içermesidir.
(3) "İleri tekniklerden" kaçının ve protokol varsayımları etrafında akıllıca yeniden düşünerek sorunları çözün: "Ekonomik kesinlik" gerekliliğini gevşeterek saldırıları maliyetli hale getirmeye çalıştık, ancak saldırıların maliyetinin bugünkü maliyetin 10 katından daha düşük olabileceğini de kabul ettik. (örneğin, saldırının maliyeti 25 milyar dolar yerine 2,5 milyar dolardı). Ethereum'un bugün ihtiyaç duyduğundan çok daha fazla ekonomik sonuca sahip olduğu ve ana güvenlik risklerinin başka yerlerde olduğu genel olarak kabul ediliyor, dolayısıyla bunun kabul edilebilir bir fedakarlık olduğu tartışılabilir.
Asıl iş, Orbit mekanizmasının güvenli olduğunu ve istediğimiz özelliklere sahip olduğunu doğrulamak ve ardından onu tamamen resmileştirip uygulamaktır. Ek olarak, EIP-7251 (Maksimum Etkin Bakiyeyi Artır) , gönüllü doğrulayıcı bakiye konsolidasyonuna izin verir; bu, zincir doğrulama yükünü anında bir dereceye kadar azaltır ve Orbit'in kullanıma sunulmasının ilk aşaması olarak etkili bir şekilde hizmet eder.
(4) Akıllıca düşünmeyi ve ileri teknolojiyi önler, ancak yine de merkezileşme riskini taşıyan iki seviyeli bir stake sistemi oluşturur. Risk büyük ölçüde daha düşük stake seviyelerinde edinilen belirli haklara bağlıdır. Örneğin:
- Daha düşük seviyeli stakerların onaylama haklarını daha yüksek seviyeli stakerlara devretmesi gerekiyorsa, o zaman delegasyon merkezileştirilebilir, böylece son derece merkezileştirilmiş iki stake katmanı elde ederiz.
- Her bloğun onaylanması için alt katmanlardan rastgele bir örnek alınması gerekiyorsa, saldırgan kesinliği önlemek için çok küçük miktarda ETH harcayabilir.
- Eğer düşük seviyeli stakerlar yalnızca dahil etme listeleri oluşturabilseydi, kanıt katmanı merkezi kalabilirdi; bu noktada, kanıt katmanına yapılan %51'lik bir saldırı, dahil etme listelerinin kendisini sansürleyebilirdi.
Birden fazla strateji birleştirilebilir, örneğin:
1 + 2): Tek slot sonlandırması olmadan Orbit ekleyin
(1 + 3): Tek slot sonlandırması olmadan minimum para yatırma boyutunu azaltmak için kaba kuvvet tekniklerini kullanın. Gereken polimerizasyon miktarı saf (3) duruma göre 64 kat daha azdır, dolayısıyla sorun daha kolay hale gelir.
(2 + 3): Orbit SSF için muhafazakar parametreler (8k veya 32k yerine 128k doğrulama komitesi gibi) kullanın ve onu süper verimli hale getirmek için teknolojiyi kullanın.
(1 + 4): Tek slot sonlandırması olmadan gökkuşağı stake etme ekleyin
Yol haritasının diğer bölümleriyle nasıl etkileşime giriyor?
Diğer avantajların yanı sıra, tek yuvalı kesinlik, belirli türdeki çoklu bloklu MEV saldırılarının riskini azaltır. Ayrıca, tek slotlu kesinlik dünyasında, kanıtlayan-teklif veren ayırma tasarımı ve diğer protokol içi blok üretim hatları farklı tasarımlar gerektirir.
Kaba kuvvet stratejilerinin zayıflığı slot süresini azaltmayı zorlaştırmasıdır.
Tek gizli lider seçimi ( Tek gizli lider seçimi )
Hangi sorunu çözmeye çalışıyoruz?
Bugün hangi doğrulayıcının bir sonraki bloğu önereceği önceden biliniyor. Bu bir güvenlik açığı yaratır: Bir saldırgan ağı izleyebilir, hangi doğrulayıcıların hangi IP adreslerine karşılık geldiğini belirleyebilir ve doğrulayıcı bir blok önermek üzereyken her doğrulayıcıya bir DoS saldırısı gerçekleştirebilir.
Nedir ve nasıl çalışır?
Bugün hangi doğrulayıcının bir sonraki bloğu önereceği önceden biliniyor. Bu bir güvenlik açığı yaratır: Saldırgan ağı izleyebilir, hangi doğrulayıcıların hangi IP adreslerine karşılık geldiğini belirleyebilir ve doğrulayıcı bir blok önermek üzereyken her doğrulayıcıya bir DoS saldırısı gerçekleştirebilir.
Nedir ve nasıl çalışır?
DoS sorununu çözmenin en iyi yolu, en azından blok gerçekten oluşturulana kadar hangi doğrulayıcının bir sonraki bloğu oluşturacağına ilişkin bilgiyi gizlemektir. "Tek" gereksinimini kaldırırsak bunun kolay olacağını unutmayın: çözümlerden biri , herkesin bir sonraki bloğu oluşturmasına izin vermek, ancak randao Reveal'ın 2 (256) / N'den az olmasını gerektirmektir. Ortalama olarak yalnızca bir doğrulayıcı bu gereksinimi karşılar; ancak bazen iki veya daha fazla, bazen de sıfır olabilir. "Gizlilik" gerekliliklerini "birlik" gereklilikleri ile birleştirmek her zaman zor bir sorun olmuştur.
Tek gizli lider seçim protokolü, her doğrulayıcı için "kör" bir doğrulayıcı kimliği oluşturmak üzere bazı kriptografik teknikler kullanarak ve ardından birçok teklif sahibine kör kimlik havuzunu ( karışık ağ yöntemine benzer şekilde) karıştırma fırsatı sağlayarak bu sorunu çözer. Her slot sırasında rastgele bir kör kimlik seçilir. Yalnızca körleştirilmiş kimliğin sahibi, bloğu önermek için geçerli bir kanıt oluşturabilir, ancak başka hiç kimse körleştirilmiş kimliğin hangi doğrulayıcıya karşılık geldiğini bilmez.
Mevcut araştırmalarla bağlantılar nelerdir?
- Dan Boneh'nin makalesi (2020): https://eprint.iacr.org/2020/025.pdf Dan Boneh'in makalesi (2020)
- Whisk (Ethereum için somut öneri, 2022): https://ethresear.ch/t/whisk-a-practical-shuffle- Based-ssle-protocol-for-ethereum/11763 Whisk (Ethereum için somut öneri, 2022)
- Ethresear.ch'ta tek gizli lider seçim etiketi: https://ethresear.ch/tag/single-secret-leader-election ethresear.ch'de tek gizli lider seçim etiketi
- Halka imzaları kullanan basitleştirilmiş SSLE: https://ethresear.ch/t/simplified-ssle/12315 Halka imzaları kullanan basitleştirilmiş SSLE
Başka ne yapılması gerekiyor, ne gibi tavizler verilmesi gerekiyor?
Gerçekten geriye kalan tek şey, ana ağ üzerinde kolayca uygulayabilmemiz için yeterince basit bir protokol bulup uygulamaktır. Oldukça basit bir protokol olarak Ethereum'a çok değer veriyoruz ve karmaşıklığın daha da artmasını istemiyoruz. Gördüğümüz SSLE uygulamaları yüzlerce satır kanonik kod ekledi ve karmaşık kriptografiye yeni varsayımlar getirdi. Yeterince etkili kuantum dirençli SSLE uygulamaları bulmak da açık bir sorundur.
Sonuç olarak durum şu olabilir; riske girip L1'deki Ethereum protokolünde (örn. durum ağaçları, ZK-EVM) evrensel sıfır bilgi kanıtları için mekanizmalar sunduğumuzda, SSLE'nin getirdiği ek karmaşıklık azalacaktır. yeterli.
Diğer bir seçenek ise SSLE'yi hiç dikkate almamak ve DoS sorununu çözmek için protokol dışı azaltıcı önlemleri (örneğin, p2p katmanında) kullanmaktır.
Yol haritasının diğer bölümleriyle nasıl etkileşime giriyor?
Diğer bir seçenek ise SSLE'yi hiç dikkate almamak ve DoS sorununu çözmek için protokol dışı azaltıcı önlemleri (örneğin, p2p katmanında) kullanmaktır.
Yol haritasının diğer bölümleriyle nasıl etkileşime giriyor?
Örneğin kanıtlayıcı-önerici ayrımı (APS) mekanizmasını eklersek. yürütme biletleri , ardından blokların (yani Ethereum işlemlerini içeren blokların) yürütülmesi, özel blok oluşturuculara güvenebileceğimiz için SSLE gerektirmeyecektir. Bununla birlikte, yine de SSLE'nin fikir birliği bloklarından (yani, onaylar gibi protokol mesajlarını içeren bloklar, belki de liste içeren parçalar vb.) faydalanabiliriz.
Daha hızlı işlem onayı
Hangi sorunu çözmeye çalışıyoruz?
Ethereum'un işlem onay süresini 12 saniyeden örneğin 4 saniyeye düşürmek değerli olacaktır. Bunu yapmak, L1 ve Tabanlı Toplamaların kullanıcı deneyimini geliştirirken defi protokolünü daha verimli hale getirecektir. Aynı zamanda L2'nin merkezileşmesini de kolaylaştıracak, çünkü L2 uygulamalarının geniş bir sınıfının Tabanlı Toplamalar üzerinde çalışmasına olanak tanıyacak ve böylece L2'nin kendi komite bazlı merkezi olmayan sıralamasını oluşturma ihtiyacını azaltacaktır.
Nedir ve nasıl çalışır?
Slot süresini 8 saniye veya 4 saniye gibi azaltın. Bu, sonuçlandırma için mutlaka 4 saniye gerektiği anlamına gelmez: sonlandırma esasen üç iletişim turu gerektirir, böylece her bir iletişim turunu ayrı bir blok haline getirebiliriz, bu da en azından geçici olarak 4 saniye sonra onaylanır.
Teklif sahiplerinin slot süreci sırasında ön onaylar vermesine izin verin. Olağanüstü bir durumda, teklif sahibi gerçek zamanlı olarak gördüğü işlemleri kendi bloğuna ekleyebilir ve her işlem için hemen bir ön onay mesajı yayınlayabilir ("İlk işlemim 0x1234...", "İkinci işlemim 0×5678) ..."). Teklif sahibinin birbiriyle çelişen iki onay vermesi durumu iki şekilde ele alınabilir: (i) teklif sahibini kesmek veya (ii) önceki onay için oy vermek üzere kanıtlayıcıyı kullanmak.
Mevcut araştırmalarla bağlantılar nelerdir?
- Temelli ön onaylar: https://ethresear.ch/t/ Based-preconfirmations/17353
- Protokolle zorlanan teklif sahibi taahhütleri (PEPC): https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879 Protokolle zorlanan teklif sahibi taahhütleri (PEPC)
- Paralel zincirler boyunca kademeli dönemler (düşük gecikme süresi elde etmek için 2018 dönemi fikri): https://ethresear.ch/t/staggered-periods/1793 Paralel zincirler boyunca kademeli dönemler (düşük gecikme süresi elde etmek için 2018 dönemi fikri)
Başka ne yapılması gerekiyor, ne gibi tavizler verilmesi gerekiyor?
Aralık süresini azaltmanın pratik olup olmadığı açık değildir. Bugün bile dünyanın pek çok yerindeki stakerlar kanıtları yeterince hızlı bir şekilde elde etmekte zorlanıyor. 4 saniyelik zaman aralığı denemesi, doğrulayıcının merkezileştirilmesi riskini taşır ve gecikme nedeniyle birkaç gelişmiş bölgenin dışında doğrulayıcı olmayı pratik hale getirir. Özellikle, 4 saniyelik zaman aralıklarına geçiş, ağ gecikme ("delta") sınırının iki saniyeye düşürülmesini gerektirir.
Teklif sahibi ön onay yönteminin dezavantajı, ortalama durumda dahil etme süresini büyük ölçüde iyileştirmesidir, ancak en kötü durumda bu geçerli değildir: mevcut teklif sahibi iyi çalışıyorsa, işlem 6 yerine 0,5 saniyede ön onaylanacaktır. saniye dahildir (ortalama olarak), ancak mevcut teklif sahibi çevrimdışıysa veya iyi performans göstermiyorsa, bir sonraki zaman dilimi başlatılıp yeni bir teklif sahibi sunulmadan önce yine de tam 12 saniye beklemeniz gerekir.
Ayrıca ön onayın nasıl teşvik edileceği de açık bir sorudur. Teklif verenlerin seçeneklerini mümkün olduğu kadar uzun süre maksimuma çıkarma teşviki vardır. Kanıtlayıcının zamanında olması için bir ön onay imzalaması durumunda, işlemi gönderen, ücretin bir kısmını hemen ön onaya şart koşabilir ancak bu, kanıtlayıcıya ek bir yük getirecek ve kanıtlayıcının devam etmesini zorlaştırabilecektir. Nötr "aptal boru" olarak çalışıyor.
Öte yandan, eğer bunu yapmaya çalışmaz ve sonuçlandırma süresini 12 saniyede (veya daha uzun) tutmazsak, ekosistem L2'nin ön onaylama mekanizmasına daha fazla önem verecek ve L2'ler arası etkileşimler daha uzun sürecektir.
Yol haritasının diğer bölümleriyle nasıl etkileşime giriyor?
Öte yandan, eğer bunu yapmaya çalışmaz ve sonuçlandırma süresini 12 saniyede (veya daha uzun) tutmazsak, ekosistem L2'nin ön onaylama mekanizmasına daha fazla önem verecek ve L2'ler arası etkileşimler daha uzun sürecektir.
Yol haritasının diğer bölümleriyle nasıl etkileşime giriyor?
Teklif sahibi tabanlı ön teyit aslında yürütme biletleri gibi kanıtlayıcı-teklif sahibi ayırma (APS) mekanizmalarına dayanır. Aksi takdirde, düzenli doğrulayıcılar üzerindeki gerçek zamanlı ön doğrulama sağlama baskısı çok yoğun olabilir.
Slot süresinin ne kadar kısa olabileceği, büyük ölçüde nihai olarak uyguladığımız APS sürümüne, dahil etme listesine vb. bağlı olan slot yapısına bağlıdır. Bazı slot yapıları daha az tur içerir ve bu nedenle kısa slot sürelerine daha uygundur, ancak başka yerlerde ödünleşimleri vardır.
Diğer araştırma alanları
%51 saldırı kurtarma
Genellikle %51 saldırısı durumunda (sansür gibi kriptografik olarak kanıtlanamayan saldırılar dahil), iyi adamların kazanmasını ve kötü adamların kazanmasını sağlamak için topluluğun bir azınlık yumuşak çatalı uygulamak üzere bir araya geleceği varsayılır. hareketsizlik sızdırılmış veya kesilmiş. Ancak sosyal boyuta aşırı güvenmenin sağlıksız olduğu tartışmasız. İyileşme sürecini mümkün olduğunca otomatikleştirerek sosyal katmana olan bağımlılığı azaltmaya çalışabiliriz.
Tam otomasyon mümkün değildir çünkü öyle olsaydı bu, %50'den fazla hataya dayanıklı bir konsensüs algoritması olarak kabul edilirdi ve bu tür algoritmaların (çok katı) matematiksel olarak kanıtlanabilir sınırlamalarını zaten biliyoruz. Ancak kısmi otomasyona ulaşabiliriz: örneğin, müşteri yeterince uzun bir işlem gördüyse, müşteri otomatik olarak sonlandırılmış zinciri veya çatalla seçilen başlığı kabul etmeyi reddedebilir. Temel amaç, saldırıdaki kötü adamların en azından hızlı ve temiz bir zafer elde edememelerini sağlamaktır.
Yeter sayı eşiğini artırın
Bugün hisselerin yüzde 67'sine sahip olanlar destek verirse blok kesinleşecek. Bazıları bunun çok radikal olduğunu düşünüyor. Ethereum'un tüm tarihi boyunca yalnızca bir (çok kısa) kesinlik hatası meydana geldi. Bu yüzde örneğin %80'e yükselirse, eklenen kesin olmayan aşamaların sayısı nispeten düşük olacaktır, ancak Ethereum güvenlik özellikleri kazanacaktır: özellikle daha tartışmalı durumların çoğu, kesinliğin geçici olarak askıya alınmasına yol açacaktır. Bu, "yanlış tarafın" hemen kazanmasından çok daha sağlıklı görünüyor, ister yanlış taraf ister saldırgan olsun, ister hatalı bir müşteriye sahip olsun.
Bu aynı zamanda "Ayrı bir rehin verenin önemi nedir?" sorusunu da yanıtlıyor. Günümüzde çoğu staker madencilik havuzları aracılığıyla stake ediyor ve tek bir stakerın stake edilen ETH'nin %51'ini alması pek mümkün görünmüyor. Bununla birlikte, çok çalışırsak, bireysel stakerların azınlığı bloke etmek için bir yeter sayıya ulaşmasını sağlamak, özellikle de çoğunluk %80 ise (yani azınlığı engellemek için yalnızca %21'lik bir yeter sayıya ihtiyaç vardır) ulaşılabilir görünüyor. Bireysel stakerlar %51 saldırısına katılmadıkları sürece (kesinlik iyileşmesi veya incelemesi olsun), böyle bir saldırı "temiz bir zafer" elde etmeyecek ve bireysel stakerlar bir azınlık yumuşak çatalının organize edilmesine yardımcı olma konusunda teşvike sahip olacaklar.
Yeterli çoğunluk eşiği ile Orbit mekanizması arasında bir etkileşim olduğunu unutmayın: Eğer Orbit'i kullanırsak, o zaman "stake yapanların %21'inin" tam olarak ne anlama geldiği daha karmaşık bir soru olacak ve kısmen doğrulayıcıların dağılımına bağlı olacaktır.
kuantum direnci
Scott Aaronson gibi kuantum hesaplama uzmanları da son zamanlarda kuantum bilgisayarların orta vadede etkili bir şekilde çalışma olasılığını daha ciddiye almaya başladı. Bunun Ethereum yol haritasının tamamı için sonuçları var: Bu, Ethereum protokolünün şu anda eliptik eğrilere dayanan her parçasının, karma tabanlı veya başka bir kuantum dirençli değişime ihtiyaç duyacağı anlamına geliyor. Özellikle bu, büyük doğrulayıcı kümelerinden gelen imzaları işlemek için BLS toplamanın üstün özelliklerine güvenebileceğimizi varsayamayacağımız anlamına gelir. Bu, hisse kanıtı tasarım performansını çevreleyen varsayımların muhafazakarlığını haklı çıkarır ve kuantum dirençli alternatifler geliştirmede daha proaktif olmanın bir nedenidir.
Tüm Yorumlar