Ethereum'un Olası Geleceği: The Purge

Ethereum'in karşılaştığı zorluklardan biri, varsayılan olarak herhangi bir blockchain protokolünün genişlemesi ve karmaşıklığının zamanla artmasıdır. Bu, iki şekilde gerçekleşir: tarihsel veriler ve protokol işlevselliği. Ethereum'un uzun vadede sürdürülebilir olabilmesi için, bu iki eğilime güçlü bir ters baskı uygulamamız gerekiyor, zamanla karmaşıklığı ve genişlemeyi azaltmalıyız. Ancak aynı zamanda, blockchain'i harika yapan ana özelliklerden birini de korumamız gerekiyor: kalıcılık.

The Purge'ın ana hedefi şudur:

• İstemci depolama gereksinimlerini azaltarak, her düğümün tüm geçmiş kayıtları veya nihai durumu kalıcı olarak saklama gerekliliğini azaltma veya ortadan kaldırma yoluyla.
• Protokol karmaşıklığını azaltmak için gereksiz özelliklerin ortadan kaldırılması.

Tarih sona erdi

Hangi sorunu çözmektedir?

Makalenin yazıldığı tarihte, tamamen senkronize bir Ethereum düğümünün istemciyi çalıştırmak için yaklaşık 1.1 TB disk alanına ihtiyacı var, ayrıca konsensüs istemcisi için de yüzlerce GB disk alanı gerekiyor. Bunun büyük bir kısmı tarihsel veridir: tarihsel bloklar, işlemler ve makbuzlar hakkında veriler, bunların çoğu yıllardır mevcut. Bu, Gas sınırı hiç artmasa bile, düğüm boyutunun her yıl yüzlerce GB artmaya devam edeceği anlamına geliyor.

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

Tarihsel depolama probleminin temel basitleştirilmiş özelliği, her bloğun ( ve diğer yapılar ) aracılığıyla bir önceki bloğa hash ile bağlı olması nedeniyle, mevcut konsensüsün tarihsel konsensüsü sağlamak için yeterli olmasıdır. Ağ en son blok üzerinde konsensüse ulaştığı sürece, herhangi bir tarihsel blok veya işlem veya durum ( hesap bakiyesi, rastgele sayı, kod, depolama ) herhangi bir tek 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 olanak tanır. Konsensüs N/2-of-N güven modelidir, tarih ise N-of-N güven modelidir.

Bu, geçmiş kayıtları nasıl depolayabileceğimiz 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ığı yöntemdir: ağ toplamda milyonlarca dosya depolayıp dağıtsa da, her bir katılımcı yalnızca bunlardan birkaç dosyayı depolar ve dağıtır. Belki de sezgiye aykırı olarak, bu yöntem veri dayanıklılığını mutlaka azaltmaz. Düğümlerin daha ekonomik bir şekilde çalışmasını sağlayarak, her bir düğümün rastgele %10'luk bir geçmiş kaydını depoladığı 100.000 düğümlü bir ağ kurabiliyorsak, her veri 10.000 kez kopyalanacaktır - bu, her düğümün her şeyi depoladığı 10.000 düğümlü bir ağın kopyalama 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şlamıştır. Konsensüs bloğu (, hisse kanıtı konsensüsü ile ilgili olan bölüm ) yalnızca yaklaşık 6 ay depolanmaktadır. Blob yalnızca yaklaşık 18 gün depolanmaktadır. EIP-4444, tarihi bloklar ve makbuzlar için bir yıllık bir depolama süresi getirmeyi hedeflemektedir. Uzun vadeli hedef, ('in yaklaşık 18 gün olabileceği bir birleşik dönem oluşturmaktır; bu süre zarfında her düğüm her şeyi depolamakla sorumlu olacak ve ardından eski verileri dağıtılmış bir ağ yöntemiyle depolamak için Ethereum düğümlerinden oluşan bir eşler arası ağ kurulacaktır.

Erasure kodları, sağlamlığı artırmak için kullanılabilirken, aynı zamanda kopyalama faktörünü de sabit tutar. Aslında, Blob zaten veri kullanılabilirlik örneklemesi desteklemek için erasure kodları uygulamıştır. En basit çözüm muhtemelen bu erasure kodlarını yeniden kullanmak ve yürütme ile konsensüs blok verilerini de blob içine koymaktır.

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

) Daha ne yapmam gerekiyor, neyi dengelemem gerekiyor?

Kalan ana işler, en azından yürütme geçmişini depolamak için tarihçe ile ilgili bir dağıtık çözüm inşa etmek ve entegre etmekti, ancak sonunda konsensüs ve blob'u da içerecektir. En basit çözüm, mevcut torrent kütüphanelerini ###i( basitçe tanıtmaktır ve )ii( adı verilen Portal ağına özgü Ethereum çözümünü tanıtmaktır. Bunlardan herhangi biri tanıtıldığında, EIP-4444'ü açabiliriz. EIP-4444'ün kendisi sert çatal gerektirmiyor, ancak yeni bir ağ protokolü sürümüne ihtiyaç duyuyor. 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 elde edememesi nedeniyle başarısız olma riski vardır.

Ana denge, "eski" tarih verilerini sunma çabamızla ilgilidir. En basit çözüm, yarın eski tarih verilerini depolamayı durdurmak ve mevcut arşiv düğümleri ile çeşitli merkezi sağlayıcılara bağımlı kalmaktı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, önce bir torrent ağı inşa etmek ve entegre etmek, tarihleri dağıtılmış bir şekilde depolamaktır. Burada, "ne kadar çaba sarf ediyoruz" iki boyuta sahiptir:

• En büyük düğüm kümesinin gerçekten tüm verileri sakladığından nasıl emin oluyoruz?
• Protokole entegre edilen tarihsel depolama derinliği ne kadar derin?

) için aşırı bir tutuculuk yaklaşımı, yönetim kanıtını içerecektir: aslında her bir hisse kanıtı doğrulayıcısının belirli bir oranda geçmişi depolamasını ve bunu düzenli olarak şifreli bir şekilde kontrol etmesini talep eder. Daha ılımlı bir yaklaşım, 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çerir: Portal, tüm Ethereum tarihini içeren ERA dosyasını depolamıştır. Daha kapsamlı bir uygulama, bunu senkronizasyon sürecine bağlamayı gerektirecektir; böylece, eğer biri tam tarih kayıt düğümünü veya arşiv düğümünü 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şimde bulunur?

Eğer düğümlerin çalıştırılması veya başlatılmasını son derece kolay hale getirmek istiyorsak, geçmiş depolama gereksinimlerini azaltmanın durumsuzluktan daha önemli olduğu söylenebilir: düğümün ihtiyaç duyduğu 1.1 TB'ın yaklaşık 300 GB'ı durum, geri kalan yaklaşık 800 GB'ı ise geçmiş olarak kalmıştır. Ancak durumsuzluk ve EIP-4444'ün gerçekleştirilmesi, akıllı saatlerde Ethereum düğümlerinin çalıştırılmasını ve sadece birkaç dakikada kurulmasını mümkün kılacak vizyonu gerçekleştirebilir.

Tarihsel depolamanın sınırlandırılması, daha yeni Ethereum düğümlerinin uygulanmasını daha mümkün kı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 şimdi birçok kod satırını güvenle kaldırmak mümkün. Hisse ispatına geçiş tarih haline geldiğinden, istemciler iş kanıtı ile ilgili tüm kodları güvenle kaldırabilir.

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

Durumun süresi dolması

( neyi çözüyor?

Müşteri tarafında geçmiş kayıtları saklama gereğini ortadan kaldırmış olsak bile, her yıl yaklaşık 50 GB kadar artarak devam edecek olan müşteri depolama ihtiyacı, durumun sürekli olarak büyümesi nedeniyle artacaktır: 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 bir defalık ücret ödeyebilirler.

Durum, tarihten daha zor "sona eriyor", çünkü EVM temelde şu varsayım etrafında 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 durumsuzluk getirirsek, bazıları bu sorunun o kadar da kötü olmadığını düşünebilir: yalnızca özel blok inşa edici sınıflar durumları gerçekten saklamak zorundadır, diğer tüm düğümler ) hatta liste oluşturan! ### durumsuz bir şekilde çalışabilir. Ancak, durumsuzluğa fazla bağımlı olmak istemediğimiz yönünde bir görüş var; nihayetinde, Ethereum'un merkeziyetsizliğini korumak için durumun sona ermesini sağlamak isteyebiliriz.

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

Bugün, yeni bir durum nesnesi oluşturduğunuzda ) aşağıdaki üç şekilde 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 alanını ayarlamak (, bu durum nesnesi o durumda sonsuza dek kalır. Aksine, istediğimiz nesnenin zamanla otomatik olarak süresi dolmasıdır. Ana zorluk, bunu üç hedefi gerçekleştirecek şekilde başarmaktır:

• Verimlilik: Vade sürecini yürütmek için büyük miktarda ek hesaplama gerektirmez.
• Kullanıcı dostu: Eğer biri beş yıl boyunca mağaraya girip çıkarsa, ETH, ERC20, NFT, CDP pozisyonlarına erişimlerini kaybetmemelidir...
• Geliştirici dostu: Geliştiricilerin tamamen yabancı bir düşünce modeline geçiş yapmasına gerek yoktur. Ayrıca, şu anda katılaşmış ve güncellenmeyen uygulamalar normal bir şekilde çalışmaya devam etmelidir.

Bu hedeflere ulaşmamak sorunları kolayca çözebilir. Örneğin, her durum nesnesinin bir son kullanma tarihi sayacı da saklamasını sağlayabilirsiniz; ), ETH yakılarak son kullanma tarihini uzatabilir, bu da herhangi bir zamanda okuma veya yazma sırasında otomatik olarak gerçekleşebilir ) ve son kullanma tarihini silmek için durum nesnelerini döngüsel olarak gözden geçiren bir süreç ile birlikte gelir. Ancak, bu ek hesaplama gereksinimleri getirir ( hatta depolama gereksinimleri ) ve kesinlikle kullanıcı dostu olma gereksinimlerini karşılayamaz. Geliştiricilerin, bazen sıfıra sıfırlanan depolama değerlerini içeren kenar durumlarını anlaması da zorlayıcıdır. Sözleşme kapsamına bir son kullanma sayacı ayarlarsanız, bu teknik olarak geliştiricilerin hayatını kolaylaştırabilir, ancak ekonomiyi daha da zorlaştırır: Geliştiricilerin sürekli depolama maliyetlerini "kullanıcılara aktarmayı" düşünmeleri gerekir.

Bunlar, Ethereum çekirdek geliştirme topluluğunun yıllardır çözmeye çalıştığı sorunlardır, "blok zinciri kira" ve "yenilenme" gibi önerileri içermektedir. Nihayetinde, önerilerin en iyi kısımlarını bir araya getirdik ve iki tür "bilinen en az kötü çözüm" üzerine yoğunlaştık:

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

(# Kısmi durum sona ermesi

Bazı durumların süresi dolmuş teklifleri aynı prensiplere uyar. Durumları parçalara ayırıyoruz. Herkes "en üst harita"yı kalıcı olarak saklar; bu, parçanın boş veya dolu olduğunu gösterir. Her parçada veri yalnızca en son erişildiğinde saklanır. Artık saklanmadığında bir "canlandırma" mekanizması vardır.

Bu öneriler arasındaki ana farklar şunlardır: )i ### "son zamanlar"ı nasıl tanımlıyoruz ve (ii ) "blok"u nasıl tanımlıyoruz? Belirli bir öneri EIP-7736'dır, bu öneri Verkle ağacı için getirilen "dal yaprağı" tasarımına dayanmaktadır (, herhangi bir biçimdeki durumsuz durumla uyumludur, örneğin ikili ağaç ). Bu tasarımda, birbirine bitişik başlıklar, kodlar ve depolama alanları aynı "gövde" altında saklanır. Bir dal altında saklanan veriler en fazla 256 * 31 = 7,936 bayt olabilir. Birçok durumda, bir hesabın tüm başlığı ve kodu ile pek çok anahtar depolama alanı aynı gövde altında saklanacaktır. Verilen gövde altındaki veriler 6 ay içinde okunmaz veya yazılmazsa, bu veriler daha fazla saklanmayacak, yalnızca bu verilerin 32 baytlık taahhüdü ( "kök" ) saklanacaktır. Gelecekte bu verilere erişim sağlayacak işlemler, verileri "diriltmek" ve kök üzerinden kontrol sağlamak için kanıt sunmak zorunda olacaktır.

Benzer fikirleri gerçekleştirmek için başka yöntemler de vardır. Örneğin, hesap düzeyinde granülasyon yeterli değilse, ağacın her 1/232 kısmının benzer bir sap yapısı mekanizması tarafından kontrol edileceği bir plan geliştirebiliriz.

Teşvik unsurları nedeniyle, bu daha karmaşık hale geliyor: Saldırganlar, büyük miktarda veriyi tek bir alt ağa yerleştirerek ve her yıl tek bir işlem göndererek "ağacı güncelleyebilir", böylece istemcinin büyük miktarda durumu kalıcı olarak depolamasını zorlayabilir. Yenileme maliyetini ağaç boyutuyla orantılı ( veya yenileme süresini ters orantılı ) yaparsanız, o zaman birileri, kendi alt ağaçlarıyla aynı olan bir alt ağa büyük miktarda veri yerleştirerek diğer kullanıcıları zarar verebilir. İnsanlar, alt ağaç boyutuna göre granülleri dinamik hale getirerek bu iki sorunu sınırlamaya çalışabilir: örneğin, her ardışık 216= 65536 durum nesnesi bir "grup" olarak değerlendirilebilir. Ancak, bu fikirler daha karmaşık; sap temelindeki yöntem basit ve teşvikleri ayarlamak mümkündür, çünkü genellikle sap altındaki.