Vitalik Buterin: Ethereum PoS algoritmasının dinamik doğrulama düğüm problemi
Geleneksel fikir birliği algoritmalarında, ister senkron, ister kısmen asenkron veya tamamen asenkron ağ modelleri olsun, ister basit hata toleransı, Bizans hata toleransı veya genellikle bir protokol modelinde sorumluluk hatası toleransı ile tasarlandılar. Sabit katılımcılar da dahil olmak üzere, en azından bazı kısımlar kesinlikle sözleşmeye uygun olarak uygulanmaktadır.
Ancak eşitliğin kanıtında, doğrulama düğümleri var olabilir ve kaybolabilir ve hatta doğrulama düğümlerinin mutlak sayısı zamanla artar veya azalır. Bu sefer% 80 doğrulama düğümü seti, başka bir zaman ayarlanan% 20 doğrulama düğümünden daha az olabilir, bu nedenle sabit bir model çok belirsizdir, bu nedenle dinamik bir modelde, belki de bu olmamalıdır. Yani ne yapmalıyız?
Çözülmesi gereken ilk sorun, eşitliğin eşzamanlı kanıtı, yani geleneksel zincir özkaynaktır ve nihai sonucu içermemektedir. Bu tür algoritmanın kullanılması arasında Diancoin, NXT tipi algoritma, DPOS, Manuve teknik incelemesinde bahsedilen ilk algoritma ve şu anda faaliyette olan diğer projeler bulunur. Buradaki sorun çok basittir, çünkü "ekonomik hesaplama sonuçlarını" elde etmek veya sürdürmek imkansızdır; bunun yerine amaç çok basittir, yani bir çatal durumunda ana bloğu belirlemeye doğrulama düğümünü teşvik edebilecek pozitif bir geri bildirim mekanizması oluşturmaktır. Ve zamanla bu ana zincirdeki blokların otoritesini güçlendirin.
Sabit bir doğrulama düğümü ayarı ise, çatallanma kuralı basittir: en uzun zincir kazanır. Peki ya doğrulama düğümünün ayarı dinamikse? Daha sonra kaçınmamız gereken saldırılar aşağıdaki gibidir.
Bir zincirin öz sermaye olarak 10 milyon ETH'ye sahip olduğunu, ancak bunun 450.000'inin (% 4.5) saldırgan tarafından kontrol edildiğini varsayalım. Şimdi, bir saldırganın kendi özel zincirini belirli bir bloktan sürdürmeye başladığını varsayalım. Transfer geri çekme seçeneğini içermelerine rağmen, yeni doğrulama düğümlerinin zincirlerine girmesine izin vermezler. Zamanla, bu zincirdeki tek ipotek saldırgandır ve bazı istisnalar olabilir. Bu zincir çok daha az ETH öz sermaye teminatına sahip olmasına rağmen, çok daha yüksek kalitede görünmektedir, çünkü blok üreticileri zamanın% 90'ında görünecektir, ancak ana zincirdeki blok üreticileri açıkça kullanıcılardır ve Daha sık çevrimdışı olacak. Bu nedenle, en basit en uzun zincir modeli de bu tür saldırıya girecektir.
Bu sorunu çözmek için, iş ispatında aynı yöntemi kullanıyoruz: sadece en uzun zinciri değil, en yüksek zorluk ağırlığına sahip en uzun zinciri arıyoruz.Bu durumda, zorluk belirli bir andaki ile eşittir. Öz sermaye tarafından taahhüt edilen ETH miktarı.
Doğrulama düğümü ayarları artık istenildiği zaman girilebilir ve çıkılabilir ve hatta her blokla tamamen değiştirilebilir. Bu düğüm ayarlarına ne olursa olsun, ekonomik ortam hala aynı şekilde işliyor ve en olası sonuçları elde etmek için teşvikler yaratıyor Daha fazla ETH'ye sahip olan zincir, daha az ETH'ye sahip olan zincirden kazanacak.
Yukarıdaki durumun nispeten basit olmasının nedeni, hissenin ispatı yapısının her bir bilgiyi bağımsız olarak değerlendirecek ve hataları cezalandıracak olmasıdır, bu nedenle katılımcıların kimlikleri her milisaniyede bir değiştirilse bile, ekonomik model değişmeyecektir, çünkü geçmişleri ne olursa olsun Durum ne olursa olsun, herkesin teşvikleri aynı. Ethereum'un son Casper tasarımı ise bu belirsizliği cezalandıracak, bu da doğrulama düğümünün iki çelişkili mesaj gönderdiği anlamına geliyor.
Bu modelde, doğrulama düğümü ayarlarının değiştirildiği durumla başa çıkmak zordur, çünkü güvenlik kimlik doğrulaması, doğrulama düğümü ayarlarının değişmediği, ancak gerçek durumun değiştiği varsayımınıza dayanır.
Bir olasılık, her 33 döngüde bir yeni blok tamamlanabildiği sürece, belirli bir güvenlik derecesini koruyabilmeniz için düğüm ayarlarının bir seferde% 1'den daha az değişmesini sağlamaktır. Bu aslında mümkün. Ancak bu çözüm pek tatmin edici değil ve sorunu daha kapsamlı bir şekilde analiz ettikten sonra daha iyi sonuçlar çıkarabiliriz.
Birisi içgüdüsel olarak başka bir fikir düşünebilir, "Sürdürülebilirliği korumak için, doğrulayıcı A'nın doğrulayıcı B'yi onaylamasını bekleyebilir ve ardından doğrulayıcı B'nin oradan başlamasına izin verebiliriz." Bunun nasıl çalıştığını anlamak için aşağıdakileri düşünün. Algoritma:
Her blok, bir sonraki blok doğrulama düğümünün hash değerini içermelidir.
Bloğun geçerli olması için, geçerli bir ana bloğu belirtmesi ve (örneğin, aynı seri numarasına sahip yeterli sayıda COMMIT vardır) üst bloğun tamamlandığını kanıtlaması gerekir. Diğer bir deyişle, her bloğun tamamlanması gerekir.
Burada bloklar arasında meydana gelen fikir birliğine dikkat etmeliyiz, yani "Blok 1, Blok 1, Blok 2, Komple Blok 2 ..." olacaktır. Bu sıra diğer algoritmalarımızı istemiyor , Önceki blok konsensüsünün tamamlanmasından önce bile, yeni bloklar oluşturulacaktır. Bu durumda, bir çatalın oluşması için blokları belirli bir blok yüksekliğinde dağıtmak gerekir, böylece bu blok yüksekliğinin 1 / 3'lük doğrulama düğümlerinin azaltılabileceğini göstermek için güvenlik kimlik doğrulama yöntemimizi kullanabiliriz.
Ancak bunu "interlaced consensus" modeline uygulamaya çalışırsak, yeni bloklar oluşturmak ve eski blokları tamamlamak aynı anda tamamlanabilir.Bu Casper'ın son sürümünde de bir durum, ancak bir zorluk var. Her döngüde fikir birliğine varılacağı% 100 kesin olmadığından, N. turdaki bloğu N + 1'inci turun doğrulama düğümü haline getiremeyiz; N'inci tur nihayet tamamlanamazsa, o zaman N turu olacaktır. İki rakip aday var ve iki bağlantısız doğrulama düğümü tarafından tamamlanan iki çakışan zincirle karşılaşacaksınız.
Dolayısıyla, bu sorunu çözmek için (N + 1) * 50 doğrulama düğümünü belirlemek için N * 50. turu kullanırsak ve her zaman en az her 50 turda bir tamamladığınızı umuyoruz. Ancak bu aynı zamanda sorunlu da olabilir:
Öyleyse fikir birliğine varmak istiyorsak, başka ne yapmamız gerekir? Her şeyden önce, durum transfer fonksiyonunun aslında belirli bir bloğun tamamlanıp tamamlanmadığına ilişkin bilginin bir parçası olduğuna dikkat edilmelidir: eğer bir blok tamamlanmışsa, o zaman kanıt zincire zamanında yüklenebilir veya olmayabilir, ancak bir blok ise Tamamlanmazsa, kanıtlar asla yüklenmeyecektir. Bu "evet veya olası" tahminini tamamlayabiliriz.
Bu özellikten yararlanalım. Oracle mümkün olduğunu söylüyorsa, doğrulama düğümü ayarlarını değiştirmeyiz; evet diyorsa değiştiririz.
Ne yazık ki işler o kadar basit değil.
Buradaki sorun şu ki, bir fikir birliği olup olmadığı konusunda hemen bir fikir birliğine varamıyoruz, böylece biri iki farklı doğrulama düğümü ayarı aracılığıyla bir ebeveyn-çocuk bloğu oluşturabilir.
Böylece bundan çözümümüzü alabiliriz. Yukarıdaki yapıyı koruyacağız, ancak cümle ekleyeceğiz ve her blok aynı anda önceki ve yeni kimlik doğrulama düğümleri tarafından tamamlanmalıdır. Başka bir deyişle, her durumda, aktif onaylayıcı düğümlerin 2 / 3'ünden bir tür bilgi almamız gerekecek Şimdi, eski onaylayıcı kümesinin ve yeni doğrulayıcı düzeneğinin yaklaşık 2 / 3'üne ihtiyacımız var. Bu haberi 2 / 3'te aldım
Şimdi, belirli bir bloğun tamamlanıp tamamlanmadığına dair bir anlaşmazlık olup olmadığını görelim.
Bunun işe yaradığını kanıtlamak kolaydır. Herhangi bir ana blok verildiğinde, bir alt blok yalnızca iki olası doğrulama düğümüne sahip olabilir: ebeveyn bloğun kendisinin doğrulama düğümü ve bu bloğa hizmet etmek için ana bloğun katıldığı doğrulama düğümü. 2 alt blok varsa ve her ikisi de tamamlanırsa, ana bloktaki doğrulama düğümlerinin 1 / 3'ü azalacaktır. Alt bloklardan biri tamamlanmadıysa, herhangi bir alt bloktaki doğrulama düğümü değişmeyecektir, bu nedenle kanıtlama mantığı, doğrulamayı tamamlamış herhangi bir türev zincirine aktarılır.
Bunu daha önce bahsedilen çeşitli fikir birliği ve çatal seçim mekanizmaları dahil olmak üzere diğer fikir birliği mekanizmalarıyla nasıl birleştirebiliriz? Yukarıda bahsedilen mekanizma, doğrulamanın doğrudan birbirini takip etmesine veya aralarında bir blok olup olmadığına bakılmaksızın, zincir üzerinde doğrulama olan herhangi bir modelde çalıştırılabilir. Dolayısıyla sorun şu ki, bir kontrol noktası verildiğinde, kontrol noktası denetimi tamamlarsa, tamamlanıp tamamlanmadığını yansıtmak için alt kontrol noktaları oluşturabilir.
Çatal seçimi ilkesi için, tek bir doğrulama düğümünü hesaplamıyoruz, ancak önceki doğrulama düğümünün minimum kaydını ve güncelleme doğrulama düğümünün kaydını seçiyoruz. İhtiyacımız olan tüm kaynaklar bu.
Orijinal: https://medium.com/@VitalikButerin/safety-under-dynamic-validator-sets-ef0c3bbdf9f6
Yazar: Vitalik Buterin
Derleme: nuszjj
Makale kaynağı (çeviri): Babbitt Information ( Telif Hakkı Beyanı:
Yazar hakkını saklı tutar. Makale, yazarın bağımsız bakış açısıdır ve Babbitt'in görüşünü temsil etmez.
