Ethereum'in 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: Geçmişte herhangi bir zamanda yapılan herhangi bir işlem ve oluşturulan herhangi bir hesabın tüm istemciler tarafından kalıcı olarak saklanması ve herhangi bir yeni istemci tarafından indirilmesi gerekir, böylece ağa tamamen senkronize edilir. 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 ters etki uygulamamız gerekiyor; zamanla karmaşıklığı ve genişlemeyi azaltmalıyız. Ancak bu arada, blok zincirini harika kılan temel özelliklerden birini: kalıcılığı korumamız gerekiyor. Bir NFT, bir işlem çağrısı verisindeki aşk mektubu veya 1 milyon dolarlık bir akıllı sözleşmeyi zincire koyabilir, on yıl bir mağaraya girebilir ve çıktığınızda hala okumanız ve etkileşimde bulunmanız için beklediğini görebilirsiniz. DApp'lerin gönül rahatlığıyla tamamen merkeziyetsiz hale gelmesi ve güncelleme anahtarlarını kaldırması için, bağımlılıklarının kendilerini yok edecek şekilde güncellenmeyeceğinden emin olmaları gerekiyor - özellikle L1'in kendisi.

Eğer bu iki talep arasında bir denge kurmaya ve sürekliliği korurken şişkinliği, karmaşıklığı ve gerilemeyi en aza indirmeye veya tersine çevirmeye kararlıysak, bu kesinlikle mümkündür. Organizmalar bunu yapabilir: Çoğu organizma zamanla yaşlansa da, nadir şanslı olanlar bunu yaşamaz. Sosyal sistemler bile çok uzun bir ömre sahip olabilir. Bazı durumlarda, Ethereum başarılı olmuştur: İş kanıtı ortadan kalkmış, SELFDESTRUCT opcode'ları büyük ölçüde kaybolmuş ve işaret zinciri düğümleri en fazla altı ay boyunca eski verileri depolamıştır. Ethereum için bu yolu daha genel bir şekilde bulmak ve uzun vadeli istikrarlı bir nihai sonuca doğru ilerlemek, Ethereum'un uzun vadeli ölçeklenebilirliği, teknolojik 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ını veya hatta nihai durumunu kalıcı olarak saklama gereksinimini azaltarak veya ortadan kaldırarak istemci depolama gereksinimlerini azaltmak.

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

Makale içeriği:

Geçmiş son kullanma tarihi( tarih kaydı sona erdi)

Devlet süresi doluyor(durum süresi doluyor)

Özellik temizleme(特征清理)

Tarih sonu

Hangi sorunu çözüyor?

Bu makalenin yazıldığı itibariyle, tamamen senkronize bir Ethereum düğümünün istemcinin çalışması için yaklaşık 1.1 TB disk alanına ihtiyacı vardır, ayrıca konsensüs istemcisi için birkaç yüz GB disk alanına ihtiyaç vardır. Bunun büyük bir kısmı geçmişe aittir: Geçmiş bloklar, işlemler ve makbuzlar hakkında veriler, ç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 geliyor.

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

Tarihsel depolama sorunlarının bir anahtarı basitleştirilmiş özelliği, her bloğun ( ve diğer yapılar ) aracılığıyla bir önceki bloğa hash ile bağlanması nedeniyle, mevcut konsensüs sağlamak için tarihsel bir konsensüs sağlamak yeterli olmasıdır. Ağ, en son blok üzerinde konsensüs sağladığı sürece, herhangi bir tarihsel blok veya işlem veya durum ( hesap bakiyesi, rastgele sayı, kod, depolama ), herhangi bir tek bir katılımcı tarafından sağlanabilir ve Merkle kanıtı ile birlikte verilebilir ve bu kanıt, diğer herkesin doğruluğunu doğrulamasına izin verir. Konsensüs, N/2-of-N güven modelidir, oysa tarih N-of-N güven modelidir.

Bu, tarihsel verileri 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ıştığı şekildir: ağ toplamda milyonlarca dosyayı depolayıp dağıtsa da, her katılımcı yalnızca bunlardan birkaçını depolar ve dağıtır. Belki de sezgisel olarak beklenmedik bir şekilde, bu yaklaşım verinin sağlamlığını da mutlaka azaltmaz. Eğer düğümlerin daha ekonomik bir şekilde çalışmasını sağlarsak, her biri rastgele %10'luk bir tarihsel kayıt depolayan 100,000 düğümlük bir ağ kurabiliriz; bu durumda her veri 10,000 kez kopyalanacaktır - bu, her bir düğümün her şeyi depoladığı 10,000 düğümlük bir ağın kopya faktörüyle 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 bloğu (, stake proof konsensüsü ile ilgili olan kısım ) yalnızca yaklaşık 6 ay depolanır. Blob yalnızca yaklaşık 18 gün depolanır. EIP-4444, tarihi bloklar ve makbuzlar için bir yıl depolama süresi getirmeyi amaçlamaktadır. Uzun vadeli hedef, her düğümün her şeyi depolamakla sorumlu olduğu ve ardından eski verileri dağıtık bir ağ şeklinde depolayan Ethereum düğümlerinden oluşan bir eşler arası ağ kurmanın mümkün olacağı bir birleştirilmiş dönem oluşturmaktır; bu dönem ( yaklaşık 18 gün olabilir ).

Erasure kodları, çoğaltma faktörünü aynı tutarken dayanıklılığı artırmak için kullanılabilir. Aslında, Blob veri kullanılabilirliği örneklemesini desteklemek için hata düzeltme kodları ile işlenmiştir. En basit çözüm muhtemelen bu Erasure kodlarını yeniden kullanmak ve yürütme ve konsensüs blok verilerini de blob içinde yerleştirmektir.

Mevcut araştırmalarla ne bağlantıları var?

EIP-4444;

Torrents ve EIP-4444;

Portallar Ağı;

Portal ağı ve EIP-4444;

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

Gas limit nasıl artırılır ( Paradigm ).

Daha ne yapmamız gerekiyor, neyi dengelememiz gerekiyor?

Kalan ana işler, en azından yürütme geçmişini saklamak için somut bir dağıtık çözüm inşa etmek ve entegre etmek, ancak nihayetinde uzlaşma ve blob'u da içermektedir. En basit çözüm, mevcut torrent kütüphanelerini (i) tanıtmaktır, ayrıca (ii) Portal ağı olarak adlandırılan Ethereum yerel çözümüdür. Bunlardan herhangi biri tanıtıldığında, EIP-4444'ü açabiliriz. EIP-4444'ün kendisi sert bir hard fork gerektirmez, ancak yeni bir ağ protokolü sürümü gerektirir. Bu nedenle, tüm istemciler için aynı anda etkinleştirmek değerlidir, aksi takdirde diğer düğümlere bağlanarak tam geçmişi indirmeyi bekleyen istemcilerin, aslında alamadıkları için çökme riski vardır.

Ana denge, "eski" tarih verilerini nasıl sağlamaya çalıştığımızla ilgilidir. En basit çözüm, yarın eski tarihleri saklamayı durdurmak ve mevcut arşiv düğümlerine ve çeşitli merkezi sağlayıcılara kopyalama yapmak olacaktır. Bu kolaydır, ancak bu, Ethereum'un kalıcı bir kayıt yeri olarak konumunu zayıflatır. Daha zor ama daha güvenli bir yol, önce bir torrent ağı inşa etmek ve entegre etmek, tarihi kayıtları dağıtık bir şekilde saklamaktır. Burada, "ne kadar çaba sarf ediyoruz" iki boyuta sahiptir:

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

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

( için aşırı bir takıntılı yaklaşım, teminat kanıtını içerecektir: aslında her stake doğrulayıcısının belirli bir oranında geçmişi depolamasını ve bunu düzenli olarak kriptografik olarak kontrol etmesini gerektiren bir yaklaşım. Daha ılımlı bir yöntem, her istemci için depolanan geçmiş yüzdesi için gönüllü bir standart belirlemektir.

)2( için temel uygulama, bugün tamamlanan çalışmaları içermektedir: Portal, tüm Ethereum tarihini içeren ERA dosyasını depolamıştır. Daha kapsamlı bir uygulama, bunun senkronizasyon sürecine bağlanmasını gerektirecektir; böylece, eğer biri tam tarih kayıtlarını depolayan bir düğüm veya arşiv düğümü senkronize etmek isterse, diğer arşiv düğümleri çevrimiçi olmasa bile, doğrudan senkronizasyon yoluyla Portal ağından elde edebilir.

)# Diğer yol haritası bölümleriyle nasıl etkileşime giriyor?

Eğer düğümlerin çalıştırılmasını veya başlatılmasını son derece kolay hale getirmek istiyorsak, o zaman tarihsel depolama gereksinimlerini azaltmak, durumsuzluktan daha önemli olabilir: düğümün ihtiyaç duyduğu 1.1 TB'ın yaklaşık 300 GB'ı durumdur, geri kalan yaklaşık 800 GB ise tarihe aittir. Sadece durumsuzluğun ve EIP-4444'ün gerçekleştirilmesi, akıllı saatlerde Ethereum düğümünün çalıştırılmasını ve yalnızca birkaç dakikada ayarlanabilme vizyonunu mümkün kılacaktır.

Geçmiş depolamanın kısıtlanması, daha yeni Ethereum düğümlerinin uygulanmasını daha mümkün hale getiriyor; sadece protokolün en son sürümünü destekliyorlar, 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 silebiliriz. Hisse kanıtına geçiş tarihe karıştığına göre, müşteriler iş kanıtıyla ilgili tüm kodları güvenle silebilirler.

Durum süresi doldu

Hangi sorunu çözüyor?

Müşteri tarafında geçmiş kayıtları depolama gereksinimini ortadan kaldırmış olsak bile, müşteri depolama ihtiyacı her yıl yaklaşık 50 GB artmaya devam edecektir, çünkü durum sürekli büyümektedir: hesap bakiyeleri ve rastgele sayılar, sözleşme kodları ve sözleşme depolama. Kullanıcılar, hem mevcut hem de gelecekteki Ethereum müşterilerine kalıcı bir yük getirmek için tek seferlik bir ücret ödeyebilirler.

Durum, tarihten daha zor "sona erdirilmiştir", çünkü EVM temelde böyle bir varsayım etrafında tasarlanmıştır: bir durum nesnesi oluşturulduğunda, her zaman var olacak ve herhangi bir işlem tarafından her zaman okunabilir olacaktır. Eğer durumsuzluğu getirirsek, bazıları bu sorunun o kadar kötü olmayabileceğini düşünüyor: yalnızca özel blok oluşturucu sınıflarının durumu gerçekten depolaması gerekirken, diğer tüm düğümler ### hatta liste oluşturma dahil! ( durumsuz çalışabilir. Ancak, aşırı durumsuzluğa bağımlı olmak istemediğimiz yönünde bir görüş var; nihayetinde Ethereum'un merkeziyetsizliğini korumak için durumu sona erdirmek isteyebiliriz.

![Vitalik: Ethereum'in Olası Geleceği, The Purge])https://img-cdn.gateio.im/webp-social/moments-a97b8c7f7927e17a3ec0fa46a48c9f24.webp(

)# O nedir, nasıl çalışır?

Bugün, yeni bir durum nesnesi oluşturduğunuzda ### aşağıdaki üç yoldan biriyle gerçekleşebilir: (i ( yeni bir hesaba ETH göndermek, )ii ( kodu kullanarak yeni bir hesap oluşturmak, )iii ( daha önce hiç dokunulmamış bir depolama slotunu ayarlamak ), bu durum nesnesi her zaman o durumda kalır. Bunun yerine, istediğimiz şey, nesnenin zamanla otomatik olarak sona ermesidir. Ana zorluk, bunu üç hedefi gerçekleştirecek şekilde yapmaktır:

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

Kullanıcı dostu: 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 dostluğu: Geliştiricilerin tamamen tanımadıkları düşünce modeline geçmeleri gerekmiyor. Ayrıca, şu anda katılaşmış ve güncellenmeyen uygulamaların normal bir şekilde çalışmaya devam etmesi gerekiyor.

Bu hedeflere ulaşmamak sorunları kolayca çözebilir. Örneğin, her durum nesnesinin bir geçerlilik tarihi sayacı da saklamasını sağlayabilirsiniz. ), geçerlilik tarihini uzatmak için ETH yakarak uzatılabilir, bu da okuma veya yazma sırasında otomatik olarak gerçekleşebilir. ( ve geçerlilik tarihini silmek için bir döngü ile durumları gezmek gerekecektir. Ancak bu, ek hesaplama gereksinimleri getirmektedir. ) ve kesinlikle kullanıcı dostu olma gereksinimlerini karşılayamaz. Geliştiriciler, bazen sıfıra sıfırlanan depolama değerlerini içeren kenar durumlarını anlamakta da zorlanıyorlar. Sözleşme kapsamına bir geçerlilik sayacı ayarlarsanız, bu teknik olarak geliştiricinin hayatını kolaylaştırır, ancak ekonomiyi daha da zorlaştırır: geliştirici, sürekli depolama maliyetlerini nasıl "aktarıp" kullanıcıya yansıtacağını düşünmek zorundadır.

Bunlar, Ethereum çekirdek geliştirme topluluğunun yıllardır çözmeye çalıştığı sorunlardır; "blok zinciri kirası" ve "yeniden doğuş" gibi önerileri içermektedir. Sonuç olarak, önerilerin en iyi kısımlarını bir araya getirdik ve "bilinen en kötü olmayan çözümler" kategorilerinde yoğunlaştık:

• Bazı durumların süresi dolmuş çözümü
• Adres döngüsüne dayalı durum sona erme önerisi.

(# Kısmi durum süresi dolmuş

Bazı durum sona erme teklifleri aynı ilkelere uyar. Durumu bloklara ayırıyoruz. Herkes kalıcı olarak "üst düzey harita"yı depolar, burada bloklar boş veya dolu olabilir. Sadece en