Cointime

Uygulamayı indirmek için QR kodu tarayın
iOS & Android

Vitalik'in yeni çalışması: Ethereum'un Birleşme sonrası yol haritasının potansiyel teknik yolları

Validated Media

Orijinal başlık: " Ethereum protokolünün olası gelecekleri, bölüm 1: Birleşme "

Yazan: Vitalik Buterin

Derleyen: Tia, Techub Haberleri

Başlangıçta “Birleşme” Proof of Work'ten Proof of Stake'e geçişi ifade ediyordu. Bugün Ethereum, neredeyse iki yıldır bir hisse kanıtı sistemi olarak istikrarlı bir şekilde çalışıyor. İstikrar , performans ve merkezileşme risklerinden kaçınma açısından son derece iyi bir performans sergiledi. Bununla birlikte, hisse kanıtının iyileştirilmesi gereken alanlar hala vardır.

2023 yol haritam, artan kararlılık, performans ve küçük doğrulayıcılara erişilebilirlik gibi teknik özelliklerdeki iyileştirmelerin yanı sıra merkezileştirme risklerini ele alacak ekonomik değişikliklerden oluşuyor. Birincisi "Birleşme"nin bir parçası, ikincisi ise "Bela"nın bir parçası.

Bu makale "Birleştirme" kısmına odaklanacaktır: Proof of Stake'in teknik tasarımında başka neler geliştirilebilir ve bu iyileştirmeleri başarmanın yolları nelerdir?

Lütfen bunun bir fikir listesi olduğunu ve riskin kanıtı için yapılması gereken şeylerin kapsamlı bir listesi olmadığını unutmayın.

Tek slot kesinliği ve staking demokratikleşmesi

Hangi sorunu çözüyoruz?

Şu anda bir bloğun sonuçlandırılması 2-3 dönem (~15 dakika) sürüyor ve staker olabilmek için 32 ETH gerekiyor. Bu, üç hedef arasında bir denge kurma ihtiyacından dolayı bir uzlaşmadır:

  • Staking'e katılan doğrulayıcıların sayısını en üst düzeye çıkarın (bu doğrudan stake etmek için gereken minimum ETH miktarını en aza indirmek anlamına gelir)
  • Sonlandırma süresini en aza indirin
  • Çalışan düğümlerin yükünü en aza indirin

Bu üç hedef birbiriyle çelişiyor: Ekonomik nihailiğe ulaşmak için (yani bir saldırganın nihai bloğu geri almak için büyük miktarda ETH'yi yok etmesi gerekir), her doğrulayıcının kesinliğe her ulaşıldığında iki mesaj imzalaması gerekir. Dolayısıyla, çok sayıda doğrulayıcınız varsa, tüm imzaları işlemek uzun zaman alır ve bu da tüm imzaları aynı anda işlemek için çok güçlü bir düğüm performansı gerektirir.

Sonuçta hepsi bu amaca hizmet ediyor: Saldırganın başarılı olması büyük miktarda paraya mal oluyor. "Ekonomik kesinlik" terimiyle kastedilen budur. Bu hedef dikkate alınmazsa, her slotu tamamlamak için rastgele bir komite ( Algorand'ın yaptığı gibi) seçmemiz gerekir. Ancak bu yaklaşımdaki sorun şu ki, eğer bir saldırgan doğrulayıcıların %51'ini kontrol edebiliyorsa, çok düşük bir maliyetle saldırabilir (sonlandırılmış blokları iptal edebilir, sansürleyebilir veya sonlandırmayı geciktirebilir): yalnızca komitede yer alıyorsa Düğümlerin alt kümesi Saldırıya katıldığı tespit edilip, kesme veya az sayıda soft fork ile cezalandırılabilir. Bu, bir saldırganın zincire defalarca saldırabileceği anlamına gelir. Bu nedenle, eğer ekonomik bir sonuca ulaşmak istiyorsak, komiteye dayalı basit bir sistem işe yaramayacaktır.

İlk bakışta tüm doğrulayıcıların katılmasına ihtiyacımız var.

Ancak ideal olarak, aşağıdaki iki kısmı iyileştirirken yine de ekonomik sonuca ulaşabiliriz:

  1. Parçaları 15 dakika yerine bir slot içinde tamamlayın (ideal olarak mevcut süreyi 12 saniye olarak koruyun veya hatta azaltın).
  2. Doğrulayıcıların 1 ETH (başlangıçta 32 ETH) stake etmesine izin ver

Bu hedeflerin tümü "Ethereum'un performansını (daha merkezi) performans odaklı L1'e yaklaştırmak" olarak görülebilir.

Ancak yine de tüm Ethereum kullanıcılarının güvenliğini sağlamak için daha yüksek güvenlik garantilerine sahip bir sonlandırma mekanizması kullanacak. Günümüzde çoğu kullanıcı 15 dakika beklemek istemediği için bu düzeyde bir güvenliğe erişemiyor; Tek slotlu sonlandırma mekanizması sayesinde kullanıcılar, işlemi onayladıktan hemen sonra işlemin kesinleşmesine ulaşabiliyor. İkinci olarak, kullanıcıların ve uygulamaların zincir geri dönüşleri konusunda endişelenmelerine gerek kalmazsa, bu, protokolü ve çevresindeki altyapıyı basitleştirir ve protokol ve altyapının dikkate alınması gereken daha az faktöre sahip olmasını sağlar.

İkinci hedef ise solo stake yapanları desteklemektir (kullanıcılar kurumlara güvenmek yerine bağımsız olarak stake yaparlar). Daha fazla kişinin tek başına stake etmesini engelleyen temel faktör minimum 32 ETH limitidir. Minimum tutarı 1 ETH'ye düşürmek, bu sorunu, diğer sorunların bireysel stake etmeyi sınırlayan ana faktör haline geldiği noktaya kadar çözecektir.

Ancak bir zorluk var: Daha hızlı kesinlik ve daha demokratikleştirilmiş stake etme, genel giderlerin en aza indirilmesiyle çelişiyor. Bu nedenle ilk etapta Tek slot kesinliğini kullanmadık. Ancak son araştırmalar bu soruna bazı olası çözümler önermektedir.

Ancak bir zorluk var: Daha hızlı kesinlik ve daha demokratikleştirilmiş stake etme, genel giderlerin en aza indirilmesiyle çelişiyor. Bu nedenle ilk etapta Tek slot kesinliğini kullanmadık. Ancak son araştırmalar bu soruna bazı olası çözümler önermektedir.

Nedir ve nasıl çalışır?

Tek slot kesinliği, bir slot içindeki blokları sonlandıran konsensüs algoritmasını ifade eder. Bu, başlı başına ulaşılamayacak bir hedef değil: birçok algoritma (Tendermint konsensüsü gibi) bunu zaten optimum özelliklerle başarıyor. Ancak Tendermint'in Ethereum'a özgü " hareketsizlik sızıntısı " özelliği yoktur. Bu özellik, doğrulayıcılarının 1/3'ünden fazlası çevrimdışı olsa bile Ethereum'un çalışmaya devam etmesine ve sonunda iyileşmesine olanak tanır. Neyse ki, bu özelliği elde etmek için halihazırda çözümler mevcut: Tendermint tarzı fikir birliğini, hareketsizlik sızıntılarını telafi edecek şekilde değiştirmeye yönelik öneriler var .

Tek slotlu nihai teklif

En zor kısım, son derece 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. Şu anda birkaç çözüm var:

  • Seçenek 1: Kaba kuvvet - muhtemelen ZK-SNARK'ları kullanarak daha iyi bir imza toplama protokolü üzerinde çalışın; bu, aslında yuva başına milyonlarca doğrulayıcı imzasını işlememize olanak tanır.

Horn, toplamayı optimize etmeye yönelik protokol tasarımlarından biri.

  • Seçenek 2: Yörünge Komitesi , zincirin sonunu belirlemek için orta büyüklükte bir komiteyi rastgele seçen ancak aynı zamanda yüksek ekonomik saldırı maliyetleri gerektiren yeni bir mekanizma.

Orbit SSF hakkında düşünmenin bir yolu, Algorand tarzı bir komite gibi ekonomik olarak nihai olması gerekmeyen bir uzlaşma seçeneği açmasıdır, ancak aynı zamanda belirli bir dereceye kadar yüksek ekonomik saldırı maliyeti elde edebilir, böylece Ethereum'un hala Aşırı güvenliği sağlamak için yeterli ekonomik kesinlik, ancak aynı zamanda tek soltun verimliliğini de arttırır.

Orbit SSF hakkında düşünmenin bir yolu, Algorand tarzı bir komite gibi ekonomik olarak nihai olması gerekmeyen bir uzlaşma seçeneği açmasıdır, ancak aynı zamanda belirli bir dereceye kadar yüksek ekonomik saldırı maliyeti elde edebilir, böylece Ethereum'un hala Aşırı güvenliği sağlamak için yeterli ekonomik kesinlik, aynı zamanda tek soltun verimliliğini artırmak için.

Orbit, mümkün olduğu kadar ekonomik kesinlik elde etmek için doğrulayıcı mevduat boyutlarında önceden var olan heterojenlikten yararlanırken, küçük doğrulayıcılara da katılım rolü veriyor. Ek olarak Orbit, bitişik kurullar arasında yüksek derecede örtüşmeyi sağlamak için yavaş bir komite rotasyon mekanizması kullanıyor ve böylece komiteler dönüşümlü olduğunda ekonomik kesinliğinin hala geçerli olmasını sağlıyor.

  • Seçenek 3: Çift katmanlı rehin Bu mekanizma, teminat verenleri iki kategoriye ayırır; biri daha yüksek depozito gereksinimlerine sahip, diğeri daha düşük depozito gereksinimlerine sahiptir. Yalnızca daha yüksek para yatırma gereksinimleri olan stakerlar doğrudan ekonomik kesinliğe kavuşacaktır. Daha düşük seviyeli mevduat stakerlarından hangi hakların ve sorumlulukların gerekli olacağını belirlemek için bazı teklifler (örneğin, Rainbow staking gönderisine bakınız) olmuştur. Ortak fikirler arasında, her blok için katılım listeleri oluşturma hakkını onaylamak ve sonuçlandırmak için hisseleri daha yüksek seviyedeki hisse sahiplerine devretmek ve daha düşük seviyedeki hisse sahiplerini rastgele seçmek yer alıyor.
  • Hisse senedini daha yüksek seviyedeki hissedarlara devredin
  • Her bloğu onaylamak ve sonuçlandırmak için daha düşük seviyeli stakerlar rastgele seçilir
  • Dahil edilme listeleri oluşturma hakkı

Mevcut araştırmalarla bağlantılar nelerdir?

Başka ne yapılması gerekiyor? Takaslar nelerdir?

Aralarından seçim yapabileceğiniz dört yol vardır (karma bir yol da kullanabiliriz):

  1. statükoyu korumak
  2. Yörünge SSF
  3. Kaba kuvvet SSF
  4. İki katmanlı stake mekanizmalı 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 olması gerekenden daha kötü hale getirecektir.

  1. statükoyu korumak
  2. Yörünge SSF
  3. Kaba kuvvet SSF
  4. İki katmanlı stake mekanizmalı 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 olması gerekenden daha kötü hale getirecektir.

(2) "Yüksek teknolojiden" kaçının ve protokol varsayımlarını akıllıca yeniden düşünerek sorunu çözün: "ekonomik kesinlik" gerekliliğini gevşetiyoruz, böylece saldırıların pahalı olmasını şart koşuyoruz, ancak saldırıların maliyeti şu ana göre 10 kat daha düşük olabilir ( Örneğin saldırının maliyeti 25 milyar dolar değil, 2,5 milyar dolardı). Ethereum'un ekonomik olarak bugün olması gerekenden çok daha nihai olduğu ve ana güvenlik risklerinin başka yerlerde olduğu genel olarak kabul ediliyor, dolayısıyla bu muhtemelen kabul edilebilir bir fedakarlıktır.

Asıl iş, Orbit mekanizmasının güvenli olup olmadığını ve istediğimiz özelliklere sahip olup olmadığını doğrulamak ve ardından onu tamamen resmileştirip uygulamaktır. Ek olarak, EIP-7251 (Maksimum Geçerli Bakiyeyi Artır) , gönüllü doğrulayıcı bakiyelerinin Birleştirilmesine olanak tanır, bu da zincirin doğrulama yükünü anında azaltır ve Orbit'in kullanıma sunulması için etkili bir başlangıç ​​aşaması olarak hizmet eder.

(3) Sorunları güçlü bir şekilde çözmek için yüksek teknolojiyi kullanın. Bunun için çok kısa bir sürede (5-10 saniye) çok sayıda imzanın (1 milyondan fazla) toplanması gerekiyor.

(4) Mekanizmayı fazla düşünmeden veya yüksek teknoloji kullanmadan iki katmanlı bir stake sistemi oluşturulur ancak yine de merkezileşme riski taşır. Risk büyük ölçüde düşük stake katmanlarının edindiği belirli haklara bağlıdır. Örneğin:

  • Düşük seviyeli stakerların doğrulama haklarını yüksek seviyeli stakerlara devretmeleri gerekiyorsa, o zaman delegasyon merkezi hale gelebilir ve son derece merkezileştirilmiş iki stake katmanı elde edebiliriz.
  • Her bloğun onaylanması için alt katmanların rastgele örneklenmesi gerekiyorsa, saldırgan yalnızca çok az miktarda ETH harcayarak kesinliği önleyebilir.
  • Eğer düşük seviyeli stakerlar yalnızca dahil etme listeleri oluşturabilseydi, kanıt katmanı merkezi kalabilir ve kanıt katmanına yapılan %51'lik bir saldırı, dahil etme listesinin kendisini sansürleyebilir.

Birden fazla strateji birleştirilebilir, örneğin:

(1 + 2): Orbit ekleyin, ancak Tek yuva kesinliği gerçekleştirmeyin

(1 + 3): Tek slot sonlandırması olmadan minimum depozitoyu azaltmak için kaba kuvvet tekniklerini kullanın. Gereken polimerizasyon miktarı saf (3) duruma göre 64 kat daha azdır, dolayısıyla problem daha kolay hale gelir.

(2+3): Orbit SSF'yi ihtiyatlı parametrelerle (örneğin 8k veya 32k yerine 128k doğrulama komitesi) çalıştırın ve süper verimli hale getirmek için kaba kuvvet tekniklerini kullanın.

(1+4): Rainbow stake etme eklendi ancak tek slot sonlandırması yok

Yol haritasının diğer bölümleriyle nasıl etkileşime geçilir?

Diğer avantajların yanı sıra, Tek yuva kesinliği, belirli türdeki çok bloklu MEV saldırılarının riskini azaltır. Ayrıca, Tek yuva kesinliğinin olduğu bir dünyada, kanıtlayıcı-teklif eden ayırma tasarımının ve diğer protokol içi blok üretim mekanizmalarının farklı şekilde tasarlanması gerekir.

Hedeflerinize kaba kuvvetle ulaşmanın zayıf tarafı, zaman aralığının azaltılmasının daha zor hale gelmesidir.

tek gizli lider seçimi

Hangi sorunu çözüyoruz?

Artık hangi doğrulayıcının bir sonraki bloğu önereceği önceden bilinebiliyor. 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ılar bir blok önermek üzereyken onlara bir DoS saldırısı başlatabilir.

Nedir ve nasıl çalışır?

Artık hangi doğrulayıcının bir sonraki bloğu önereceği önceden bilinebiliyor. 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ılar bir blok önermek üzereyken onlara bir DoS saldırısı başlatabilir.

Nedir ve nasıl çalışır?

DoS sorununu çözmenin en iyi yolu, hangi doğrulayıcının bir sonraki bloğu oluşturacağına ilişkin bilgiyi gizlemektir (en azından blok gerçekten oluşturulana kadar). "Tek" gerekliliği dikkate alınmaksızın (bir sonraki bloğu yalnızca bir taraf oluşturur), çözümlerden biri herkesin bir sonraki bloğu oluşturmasına izin vermektir, ancak bu, randao'nun ortaya çıkmasının 2 (256) / N'den küçük olmasını gerektirir. Genellikle yalnızca bir doğrulayıcı bu gereksinimi karşılayabilir (ancak bazen iki veya daha fazla olabilir, bazen de hiçbiri olmayabilir). Dolayısıyla "gizlilik" şartının "birlik" şartıyla birleştirilmesi her zaman zor bir sorun olmuştur.

Tek gizli lider seçim protokolü, bazı kriptografik teknikleri kullanarak her doğrulayıcı için "kör" bir doğrulayıcı kimliği oluşturur ve ardından birçok teklif sahibine kör kimlik havuzunu karıştırma ve yeniden körleme fırsatı verir (bu, hibrit ağların çalışma şekline benzer) şekilde), böylece bu sorunu çözeriz. Her yuvada rastgele bir kör kimlik seçilir. Yalnızca kör kimliğin sahibi, bir blok önermek için geçerli bir kanıt oluşturabilir ancak kimse kör kimliğin hangi doğrulayıcıya karşılık geldiğini bilmiyor.

SSLE protokolünü çırpın

Mevcut araştırmalarla bağlantılar nelerdir?

Yapacak ne kaldı? Takaslar nelerdir?

Gerçekten geriye kalan tek şey, ana ağ üzerinde kolayca uygulayabilmemiz için yeterince basit bir protokol bulup uygulamaktır. Ethereum'un sadeliğine çok değer veriyoruz ve karmaşıklığın daha da artmasını istemiyoruz. Gördüğümüz SSLE uygulamaları yüzlerce satırlık spesifikasyon kodu ekliyor ve karmaşık şifrelemede yeni varsayımlar getiriyor. Yeterince etkili, kuantum dirençli bir SSLE uygulaması bulmak da açık bir sorundur.

SSLE'nin "marjinal ekstra karmaşıklığına" yalnızca riske girip başka nedenlerle (örneğin durum ağaçları, ZK-EVM) L1'deki Ethereum protokolünde evrensel sıfır bilgi kanıtları gerçekleştirecek bir mekanizma tanıtırsak elde edilebilir. seks" yeterince düşük bir seviyeye düşecektir.

Diğer bir seçenek ise SSLE'yi tamamen yok saymak ve bunun yerine DoS sorunlarını çözmek için protokol dışı azaltıcı önlemleri (p2p katmanı gibi) kullanmaktır.

Yol haritasının diğer bölümleriyle nasıl etkileşime giriyor?

Diğer bir seçenek ise SSLE'yi tamamen yok saymak ve bunun yerine DoS sorunlarını çözmek için protokol dışı azaltıcı önlemleri (p2p katmanı gibi) kullanmaktır.

Yol haritasının diğer bölümleriyle nasıl etkileşime giriyor?

Yürütme biletleri gibi bir kanıtlayıcı-teklifçi ayırma (APS) mekanizması eklersek, özel blok oluşturuculara güvenebileceğimiz için blokların (yani Ethereum işlemlerini içeren blokların) yürütülmesi SSLE gerektirmeyecektir. Ancak konsensüs blokları için (yani protokol mesajları içeren bloklar (örn. kanıtlar, muhtemelen listelerin parçaları vb.)) yine de SSLE'den faydalanacağız.

Daha hızlı işlem onayı

Hangi sorunu çözüyoruz?

Ethereum'un işlem onay süresini 12 saniyeden 4 saniyeye daha da düşürmek değerlidir. Bunu yapmak, defi protokolünü daha verimli hale getirirken L1 ve toplama tabanlı kullanıcı deneyimini önemli ölçüde iyileştirecektir. Aynı zamanda, çok sayıda L2 uygulamasının toplamalara dayalı olarak çalıştırılmasına olanak tanıyacağı ve böylece L2'nin kendi komite bazlı merkezi olmayan sıralamasını oluşturma ihtiyacını azaltacağı için L2'nin merkezi olmayan hale gelmesini de kolaylaştıracaktır.

Nedir ve nasıl çalışır?

Burada kabaca iki teknik var:

  1. Slot süresini örneğin 8 saniyeye veya 4 saniyeye düşürün. Bu mutlaka 4 saniyelik bir kesinlik anlamına gelmez: Kesinliğin kendisi üç iletişim turu gerektirir, böylece her bir iletişim turunu ayrı bir blok haline getirebiliriz, bu da en azından 4 saniye sonra ön onay alır.
  2. Teklif sahiplerinin zaman aralığı sırasında ön onaylar vermesine izin verin. Aşırı durumlarda, teklif verenler gördükleri işlemleri gerçek zamanlı olarak bloklarına dahil edebilir ve her işlem için hemen ön onay mesajları 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) hangisinin daha önce olduğuna oy vermek için tanıkları kullanmak.

Mevcut araştırmalarla bağlantılar nelerdir?

Yapacak ne kaldı? Takaslar nelerdir?

Slot süresini kısaltmanın mümkün olup olmadığı belirsizdir. Bugün bile dünyanın birçok yerindeki stakerlar kanıtları yeterince hızlı elde etmek için mücadele ediyor. 4 saniyelik bir zaman aralığı denemesi, doğrulayıcı setinin merkezileştirilmesi riskini taşır ve gecikme nedeniyle birkaç ayrıcalıklı alan dışında doğrulayıcı olmayı pratik hale getirmez.

Teklif sahibi ön onay yönteminin zayıflığı, ortalama vaka ekleme süresini büyük ölçüde iyileştirmesidir, ancak en kötü durum değil: Mevcut teklif sahibi iyi çalışıyorsa, işleminiz (ortalama olarak) 6 saniye yerine 0,5 saniyede ön onaylanır, ancak mevcut teklif sahibi çevrimdışıysa veya iyi performans göstermiyorsa, bir sonraki aşamaya başlamadan ve yeni bir teklif sahibi sağlamadan önce yine de tam 12 saniye beklemeniz gerekir.

Teklif sahibi ön onay yönteminin zayıflığı, ortalama vaka ekleme süresini büyük ölçüde iyileştirmesidir, ancak en kötü durum değil: Mevcut teklif sahibi iyi çalışıyorsa, işleminiz (ortalama olarak) 6 saniye yerine 0,5 saniyede ön onaylanır, ancak en kötü durum bu değildir. mevcut teklif sahibi çevrimdışıysa veya iyi performans göstermiyorsa, bir sonraki aşamaya başlamadan ve yeni bir teklif sahibi sağlamadan önce yine de tam 12 saniye beklemeniz gerekir.

Ek olarak, ön onayın nasıl teşvik edileceğine dair açık bir soru var. Teklif sahiplerinin, mümkün olduğu kadar uzun bir süre boyunca isteğe bağlılıklarını en üst düzeye çıkarma teşviki vardır. Tanık, ön onayın zamanında olduğunu imzalarsa, işlemi gönderen, ücretin bir kısmını anında ön onaya şart koşabilir ancak bu, tanığa ek bir yük getirecek ve tanığın devam etmesini zorlaştırabilecektir. tarafsız bir "aptal" boru hattı görevi görmek.

Öte yandan, eğer bunu yapmaya çalışmaz ve sonuçlandırma süresini 12 saniyede (veya daha fazla) tutmazsak, ekosistem L2'nin ön onaylama mekanizmasına daha fazla önem verecek ve L2 genelindeki 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.

Diğer araştırma alanları

%51 saldırı kurtarma

Genel olarak %51 saldırısı durumunda (sansür gibi kriptografik olarak kanıtlanamayan saldırılar dahil), topluluğun bir azınlık yumuşak çatalı uygulamak için bir araya gelerek iyi adamların kazanmasını ve kötü adamların mağlup olmasını sağlayacağına inanılır. hareketsizlik nedeniyle sızdırılmış veya kesilmiş. Ancak sosyal katmana bu düzeyde 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 imkansızdır çünkü bu, >%50 hata toleransına sahip bir fikir birliği algoritmasına eşdeğer olacaktır 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, eğer bir müşteri, müşterinin uzun süredir gördüğü bir işlemi inceliyorsa, otomatik olarak bir zinciri nihai olarak kabul etmeyi reddedebilir, hatta onu bir çatal seçiminin başı olarak kabul etmeyi bile reddedebilir. . Temel amaç, saldırganın en azından hızlı ve doğrudan bir zafer elde edememesini sağlamaktır.

Yeterli çoğunluk eşiğini yükselt

Bugün, stakerların %67'si desteklediği sürece bir blok sonlandırılacak. Bazıları bu yaklaşımın çok radikal olduğunu düşünüyor. Ethereum'un tüm tarihi boyunca yalnızca bir (çok kısa) kesinlik başarısızlığı yaşandı. Bu oran %80'e çıkarılırsa, artan kesinlik dışı dönemlerin sayısı nispeten düşük olacaktır, ancak Ethereum güvenlik 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ı, ister yanlış tarafın saldırgan olması, ister müşteri tarafında bir hata olması durumundan daha sağlıklı bir durum gibi görünüyor.

Bu aynı zamanda "Yalnız stakerların amacı nedir?" sorusunu da yanıtlıyor. Günümüzde çoğu stakerın staking havuzları üzerinden stake yaptığı göz önüne alındığında, tek bir stakerın ETH stake etme oranının %51'ine ulaşması ihtimali zayıf görünüyor. Bununla birlikte, bireysel stakerların bir azınlığı bloke etmek için gerekli yeterli sayıya ulaşması, eğer çok çalışırsak, özellikle de çoğunluk %80 ise (bu nedenle bir azınlığı bloke etmek için yeterli çoğunluk yalnızca %21 gerektirir) mümkün görünüyor. Yalnız stakerlar %51 saldırısına katılmadıkları sürece (kesinliğin tersine çevrilmesi veya sansür olsun), bu saldırı için "temiz bir zafer" olmayacak ve yalnız stakerlar bir azınlık yumuşak çatalının organize edilmesine yardımcı olma teşvikine sahip olacaklar.

Kuantum saldırılarına karşı dayanıklı

Metaculus şu anda, büyük hata paylarıyla da olsa, kuantum bilgisayarların 2030'larda kriptografiyi kırmaya başlayabileceğine inanıyor :

Scott Aaronson gibi kuantum hesaplama uzmanları da son zamanlarda kuantum bilgisayarların orta vadede gerçekten çalışabileceği ihtimalini daha ciddi bir şekilde düşünmeye başladı . Bunun Ethereum yol haritasının tamamı için sonuçları olacak: Bu, Ethereum protokolünün şu anda eliptik eğrilere dayanan her parçasının bir tür hash tabanlı veya kuantum dirençli başka bir alternatife ihtiyaç duyacağı anlamına geliyor. Bu özellikle, büyük doğrulayıcı kümelerinden gelen imzaları işlemek için BLS toplamanın üstün performansına güvenebileceğimizi varsayamayacağımız anlamına gelir. Bu, hisse kanıtı tasarım performansı varsayımlarında muhafazakarlığı haklı çıkarır ve kuantum dirençli alternatifleri daha agresif bir şekilde geliştirmenin bir nedenidir.

Yorumlar

Tüm Yorumlar

Önerilen okuma