Vitalik: Ethereum'un Olası Geleceği, The Purge

Ethereum'in karşılaştığı zorluklardan biri, varsayılan olarak, herhangi bir blok zinciri protokolünün genişlemesi ve karmaşıklığının zamanla artmasıdır. Bu iki yerde gerçekleşir:

Geçmiş veriler: Tarih boyunca herhangi bir zamanda gerçekleştirilen herhangi bir işlem ve oluşturulan herhangi bir hesap, tüm istemciler tarafından kalıcı olarak saklanmalı ve yeni istemciler tarafından indirilmelidir, böylece ağa tamamen senkronize olurlar. Bu, istemci yükünün ve senkronizasyon süresinin zamanla sürekli artmasına neden olur, zincirin kapasitesi sabit kalsa bile.

Protokol işlevi: Yeni işlevler eklemek, eski işlevleri silmekten çok daha kolaydır, bu da zamanla kod karmaşıklığının artmasına neden olur.

Ethereum'un uzun vadede sürdürülebilir olabilmesi için, bu iki trende güçlü bir karşı baskı uygulamamız gerekiyor; zamanla karmaşıklığı ve genişlemeyi azaltmalıyız. Ancak aynı zamanda, blok zincirini harika kılan temel özelliklerden birini de korumamız gerekiyor: kalıcılık. Bir NFT, bir ticaret telefon görüşmesindeki aşk mektubu ya da 1 milyon dolar içeren bir akıllı sözleşmeyi zincire koyabilirsiniz; on yıl boyunca bir mağaraya girdiğinizde, çıktığınızda hâlâ okumak ve etkileşimde bulunmak için orada beklediğini görebilirsiniz. DApp'lerin tamamen merkeziyetsiz bir şekilde gönül rahatlığıyla yükseltme anahtarlarını silmeleri için, bağımlılıklarının kendilerini yok edecek şekilde yükselmeyeceğinden emin olmaları gerekiyor - özellikle L1'in kendisi.

Eğer kararlıysak, bu iki talep arasında bir denge kurmak ve sürekliliği korurken şişkinlik, karmaşıklık ve gerilemeyi en aza indirmek veya tersine çevirmek kesinlikle mümkündür. Organizmalar bunu yapabilir: Çoğu organizma zamanla yaşlansa da, bir avuç şanslı olan yaşlanmaz. Hatta sosyal sistemler de çok uzun bir ömre sahip olabilir. Bazı durumlarda Ethereum başarılı olmuştur: İş kanıtı ortadan kalktı, SELFDESTRUCT işlem kodu büyük ölçüde kayboldu, beacon chain düğümleri en fazla altı ay boyunca eski verileri depoladı. Ethereum için bu yolu daha genel bir şekilde bulmak ve uzun vadeli istikrarlı bir nihai sonuca yönelmek, Ethereum'un uzun vadeli ölçeklenebilirliği, teknik sürdürülebilirliği ve hatta güvenliğinin nihai zorluğudur.

The Purge: Ana hedef.

Her bir düğümün tüm geçmiş kayıtları veya hatta nihai durumu kalıcı olarak depolama gereksinimini azaltarak veya ortadan kaldırarak istemci depolama gereksinimlerini azaltma.

Protokol karmaşıklığını azaltmak için gereksiz işlevleri ortadan kaldırarak.

Makale Dizini:

Geçmiş süresi doldu

Durum süresi doldu

Özellik temizliği

Tarih sonu

hangi sorunu çözüyor?

Bu makalenin yazıldığı tarihte, tam senkronize bir Ethereum düğümünün çalıştırılması için yaklaşık 1,1 TB disk alanına ihtiyacı vardır; ayrıca konsensüs istemcisi için yüzlerce GB disk alanına da ihtiyaç vardır. Bunun büyük çoğunluğu geçmişe aittir: geçmiş bloklar, işlemler ve makbuzlar ile ilgili veriler, bunların çoğu yıllardır mevcuttur. Bu, Gas sınırı hiç artmasa bile, düğüm boyutunun her yıl yüzlerce GB artmaya devam edeceği anlamına gelir.

Bu nedir, nasıl çalışır?

Tarihsel depolama probleminin bir anahtarı, her bloğun hash bağlantıları (ve diğer yapılar) aracılığıyla önceki bloğa işaret etmesi nedeniyle, mevcut konsensüse ulaşmanın tarihsel konsensüse ulaşmak için yeterli olmasıdır. Ağ, en son bloğa konsensüse ulaştığı sürece, herhangi bir tarihsel blok, işlem veya durum (hesap bakiyesi, rastgele sayı, kod, depolama) herhangi bir bireysel katılımcı tarafından sağlanabilir ve Merkle kanıtı ile birlikte verilir; bu kanıt, diğer herkesin doğruluğunu doğrulamasına olanak tanır. Konsensüs N/2-of-N güven modeli iken, tarih N-of-N güven modelidir.

Bu, tarih kayıtlarını nasıl depolayacağımız konusunda birçok seçenek sunuyor. Doğal bir seçim, her bir düğümün yalnızca küçük bir veri parçasını depoladığı bir ağdır. Bu, tohum ağlarının on yıllardır çalışma şeklidir: ağ toplamda milyonlarca dosyayı depolayıp dağıtsa da, her katılımcı yalnızca bunların birkaçını depolayıp dağıtır. Belki de sezgiye aykırı olarak, bu yöntem veri sağlamlığını azaltmak zorunda bile değildir. Düğümlerin çalıştırılmasını daha ekonomik hale getirerek, her bir düğümün rastgele %10'luk bir tarih kaydını depoladığı 100,000 düğümlü bir ağ kurabiliriz; bu durumda her veri 10,000 kez kopyalanır - bu, her bir düğümün her şeyi depoladığı 10,000 düğümlü bir ağdaki kopyalama faktörü ile tamamen aynıdır.

Artık Ethereum, tüm düğümlerin tüm geçmişi kalıcı olarak depoladığı modelden kurtulmaya başladı. Konsensüs blokları (yani, hisse kanıtı konsensüsü ile ilgili kısım) yalnızca yaklaşık 6 ay boyunca depolanır. Blob yalnızca yaklaşık 18 gün boyunca depolanır. EIP-4444, tarih blokları ve makbuzlar için bir yıllık bir depolama süresi getirmeyi amaçlamaktadır. Uzun vadeli hedef, her düğümün her şeyi depolamakla sorumlu olduğu tek bir dönem (muhtemelen yaklaşık 18 gün) oluşturmaktır; ardından eski verilerin dağıtık bir ağ şeklinde saklanacağı Ethereum düğümlerinden oluşan bir eşler arası ağ oluşturulacaktır.

Erasure kodları, kopya faktörünü aynı tutarken sağlamlığı artırmak için kullanılabilir. Aslında, Blob veri kullanılabilirliği örneklemesini desteklemek için hata düzeltme kodları kullanmıştır. En basit çözüm muhtemelen bu Erasure kodlarını yeniden kullanmak ve yürütme ile konsensüs blok verilerini de blob'a koymak olacaktır.

mevcut araştırmalarla hangi bağlantılara sahip?

EIP-4444；

Torrents ve EIP-4444；

Ağ geçidi

Portallar Ağı ve EIP-4444;

Portal'daki SSZ nesnelerinin dağıtık depolanması ve sorgulanması;

Gas limitini nasıl artırabilirim (Paradigm).

Ne yapmamız gerekiyor, neyi dengelemeliyiz?

Kalan ana işler, en azından yürütme geçmişi olmak üzere, geçmişi saklamak için somut bir dağıtık çözüm inşa etmek ve entegre etmekten oluşmaktadır, ancak nihayetinde uzlaşma ve blob'u da içermektedir. En basit çözüm, mevcut torrent kütüphanelerini (i) tanıtmaktır ve (ii) adı verilen Ethereum yerel çözümüdür. Bunlardan herhangi biri tanıtıldığında, EIP-4444'ü açabiliriz. EIP-4444'ün kendisi sert bir çatal gerektirmez, ancak yeni bir ağ protokolü sürümüne ihtiyaç duyar. Bu nedenle, tüm istemciler için aynı anda etkinleştirmek değerlidir, aksi takdirde, diğer düğümlere bağlanıp tam geçmişi indirmeyi bekleyen istemcilerin, aslında almadıkları için çökme riski vardır.

Ana denge, "eski" tarih verilerini sağlama çabamızla ilgilidir. En basit çözüm, yarın eski tarihleri depolamayı durdurmak ve mevcut arşiv düğümleri ile çeşitli merkezi sağlayıcılara dayanarak kopyalama yapmaktır. Bu kolaydır, ancak Ethereum'un kalıcı bir kayıt yeri olarak konumunu zayıflatır. Daha zor ama daha güvenli bir yol, öncelikle dağıtık bir şekilde tarihleri depolamak için torrent ağını inşa etmek ve entegre etmektir. Burada, "ne kadar çaba gösteriyoruz" iki boyuta sahiptir:

En büyük düğüm kümesinin gerçekten tüm verileri sakladığından nasıl emin oluruz?

Protokole entegre edilen tarihsel depolama derinliği ne kadar derin?

(1) için aşırı bir takıntılı yaklaşım, yönetim kanıtını içerecektir: pratikte, her bir stake doğrulayıcısının belirli bir oranda geçmiş kayıtları saklaması ve bunları düzenli olarak şifreli bir şekilde kontrol etmesi gerekmektedir. Daha ılımlı bir yaklaşım, her istemci için saklanan geçmişin yüzdesi için gönüllü bir standart belirlemektir.

(2) için temel uygulama, bugün tamamlanan çalışmaları içerir: Portal, tüm Ethereum tarihini içeren ERA dosyasını depolamıştır. Daha kapsamlı bir uygulama, bunu senkronizasyon sürecine bağlamayı içerecektir; böylece, eğer birisi tam tarih kayıt düğümünü veya arşiv düğümünü senkronize etmek isterse, başka arşiv düğümleri çevrimiçi olmasa bile, doğrudan senkronizasyon yoluyla Portal ağından bunu gerçekleştirebilir.

Diğer yol haritası parçalarıyla nasıl etkileşime giriyor?

Eğer düğümlerin çalışmasını veya başlatılmasını son derece kolay hale getirmek istiyorsak, tarihsel depolama gereksinimlerini azaltmanın, durumsuzluktan daha önemli olduğu söylenebilir: Düğümün ihtiyaç duyduğu 1.1 TB'nın yaklaşık 300 GB'ı durum, geri kalan yaklaşık 800 GB'ı ise tarih oldu. Sadece durumsuzluk ve EIP-4444'ün gerçekleştirilmesi, akıllı saatlerde Ethereum düğümünü çalıştırma ve sadece birkaç dakikada kurulum yapma vizyonunu gerçekleştirebilir.

Geçmiş depolamanın kısıtlanması, daha yeni Ethereum düğümlerinin daha uygulanabilir hale gelmesini sağlıyor, yalnızca protokolün en son sürümünü destekliyor, bu da onları daha basit hale getiriyor. Örneğin, 2016'daki DoS saldırısı sırasında oluşturulan boş depolama alanlarının tamamı silindiği için artık birçok kod satırını güvenle silebilirsiniz. Hisse kanıtına geçiş tarih olmuşken, müşteriler iş kanıtıyla ilgili tüm kodları güvenle silebilir.

Durum süresi

hangi sorunu çözüyor?

İstemci depolama geçmişine olan ihtiyacı ortadan kaldırmış olsak bile, istemcinin depolama ihtiyacı her yıl yaklaşık 50 GB artmaya devam edecek, çünkü durum sürekli olarak büyüyor: hesap bakiyeleri ve rastgele sayılar, sözleşme kodları ve sözleşme depolama. Kullanıcılar bir kerelik bir ücret ödeyerek, hem mevcut hem de gelecekteki Ethereum istemcilerine sürekli bir yük getirebilirler.

"Durumun geçmişten daha zor "sona ermesi", çünkü EVM temelde böyle bir varsayıma dayanarak tasarlanmıştır: bir durum nesnesi oluşturulduğunda, her zaman var olacaktır ve herhangi bir işlem tarafından her zaman okunabilir. Eğer durumsuzluğu getirirsek, bazıları bu sorunun o kadar da kötü olmadığını düşünebilir: yalnızca özel blok oluşturucu türleri gerçekten durumu depolamak zorundadır ve tüm diğer düğümler (hatta liste oluşturmayı içeren!) durumsuz çalışabilir. Ancak, durumsuzluğa fazla bağımlı olmak istemediğimiz görüşü var; nihayetinde, Ethereum'un merkeziyetsizliğini korumak için durumu sona erdirmek isteyebiliriz.

Bu nedir, nasıl çalışır?

Bugün, yeni bir durum nesnesi oluşturduğunuzda (bu üç yoldan biriyle gerçekleşebilir: (i) yeni bir hesaba ETH göndermek, (ii) kod kullanarak yeni bir hesap oluşturmak, (iii) daha önce dokunulmamış bir depolama slotu ayarlamak), bu durum nesnesi sonsuza dek o durumda kalır. Aksine, istediğimiz şey nesnenin zamanla otomatik olarak süresinin dolmasıdır. Ana zorluk, bunu üç hedefi gerçekleştirmenin bir yolu olarak yapmaktır:

Verimlilik: Vade sürecini yürütmek için büyük miktarda ek hesaplama gerektirmez.

Kullanıcı dostu olma: Eğer biri beş yıl boyunca bir mağarada kalır ve geri dönerse, ETH, ERC20, NFT, CDP pozisyonlarına erişimlerini kaybetmemelidir...

Geliştirici dostu olma: Geliştiricilerin tamamen tanımadıkları bir düşünce modeline geçmeleri gerekmemektedir. Ayrıca, şu anda katı ve güncellenmeyen uygulamaların normal bir şekilde çalışmaya devam etmesi gerekmektedir.

Bu hedefleri karşılamamak, sorunları çözmeyi kolaylaştırır. Örneğin, her durum nesnesinin bir son kullanma tarihi sayacı saklamasını sağlayabilirsiniz (son kullanma tarihini uzatmak için ETH yakılarak, bu herhangi bir zamanda okuma veya yazma sırasında otomatik olarak gerçekleşebilir) ve son kullanma tarihini silmek için durumları döngüsel olarak geçiren bir süreç vardır. Ancak bu, ek hesaplama (hatta depolama gereksinimleri) getirir ve kesinlikle kullanıcı dostu olma gereksinimlerini karşılayamaz. Geliştiricilerin, depolama değerlerinin bazen sıfıra sıfırlanmasıyla ilgili kenar durumlarını anlaması da zordur. Sözleşme kapsamında bir son kullanma sayacı ayarlarsanız, bu teknik olarak geliştiricilerin yaşamını kolaylaştırabilir, ancak ekonomiyi daha da zorlaştırır: Geliştiricilerin sürekli depolama maliyetlerini "kullanıcılara devretmeyi" düşünmeleri gerekir.

Bunlar, Ethereum çekirdek geliştirici topluluğunun yıllardır çözmeye çalıştığı sorunlar arasında yer alıyor; "blok zinciri kirası" ve "yeniden üretim" gibi öneriler de dahil. Sonunda, önerilerin en iyi kısımlarını bir araya getirdik ve iki tür "bilinen en kötü çözümler" üzerine odaklandık:

Kısmi durum geçerliliği sona ermiş çözümleri Adres döngüsüne dayalı durum sona erme önerisi.

Kısmi durum süresi sona erdi

Bazı durum süresi dolan tekliflerin hepsi aynı ilkelere uyar. Durumu parçalara ayırıyoruz. Herkes "en üst harita"yı kalıcı olarak depoluyor, burada parçalar boş veya dolu. Her parçada veri, yalnızca en son erişilmişse depolanır. Artık depolanmadığında bir "canlandırma" mekanizması vardır.

Bu öneriler arasındaki temel fark şudur: (i) "son"u nasıl tanımlıyoruz,