Ethereum'in 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 yerde 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 büyük yapan temel özelliklerden birini: kalıcılığı korumamız gerekiyor.

The Purge'un ana hedefi:

• Müşteri depolama gereksinimlerini azaltarak veya her düğümün tüm geçmiş kayıtları veya nihai durumu kalıcı olarak depolama gereksinimini ortadan kaldırarak.
• Protokol karmaşıklığını azaltmak için gereksiz işlevleri ortadan kaldırarak.

Geçmiş süresi

Ne tür bir problemi çözüyor?

Yazının 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ı geçmişe ait: geçmiş 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.

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

Tarihsel depolama sorunlarının temel bir basitleştirilmiş özelliği, her bloğun ( ve diğer yapıların ) aracılığıyla bir önceki bloğa hash ile bağlantılı olması nedeniyle, mevcut uzlaşma için tarihsel uzlaşmanın yeterli olmasıdır. Ağ, en son blok üzerinde uzlaşmaya vardığında, herhangi bir tarihi blok veya işlem veya durum ( hesap bakiyeleri, rastgele sayılar, kod, depolama ) herhangi bir bireysel katılımcı tarafından sağlanabilir ve Merkle kanıtı ile birlikte sunulabilir ve bu kanıt, diğer herkesin doğruluğunu doğrulamasına izin verir. Uzlaşma, N/2-of-N güven modeli iken, tarihsel N-of-N güven modelidir.

Bu, tarih kayıtlarını nasıl depolayacağımız konusunda bize birçok seçenek sunuyor. Doğal bir seçim, her düğümün yalnızca verilerin küçük bir kısmı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 bunlardan birkaçını depolayıp dağıtır. Belki de sezgiyle ters orantılı olarak, bu yöntem verilerin sağlamlığını azaltmak zorunda değildir. Düğümlerin çalışmasını daha ekonomik hale getirerek, her biri rastgele %10'luk bir tarih kaydını depolayan 100.000 düğümlü bir ağ kurabilirse, her veri 10.000 kez kopyalanacaktır - 10.000 düğümlü bir ağın kopyalama faktörüyle tamamen aynı - her düğümün her şeyi depoladığı bir ağ.

Artık Ethereum, tüm düğümlerin tüm geçmişi kalıcı olarak depoladığı modelden kurtulmaya başladı. Konsensüs bloğu (, staking konsensüsü ile ilgili kısım ) yalnızca yaklaşık 6 ay depolanmaktadır. Blob yalnızca yaklaşık 18 gün depolanmaktadır. EIP-4444, tarihsel bloklar ve makbuzlar için bir yıllık bir depolama süresi getirmeyi amaçlamaktadır. Uzun vadeli hedef, her düğümün tüm içerikleri depolamakla sorumlu olduğu, ardından Ethereum düğümlerinden oluşan bir eşler arası ağın oluşturulacağı bir birleşik dönem ( muhtemelen yaklaşık 18 gün ) içinde oluşturmaktır.

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ı kullanmaktadı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.

başka ne yapmamız gerekiyor, neyi dengelememiz gerekiyor?

Kalan ana işler, en azından yürütme geçmişini depolamak için belirli bir dağıtık çözüm inşa etmek ve entegre etmek, ancak nihayetinde konsensüs ve blob'u da içermektedir. En basit çözüm, (i) mevcut torrent kütüphanesini basitçe tanıtmaktır ve (ii) Ethereum yerel çözümü olarak adlandırılan Portal ağı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ü gerektirir. Bu nedenle, tüm istemciler için aynı anda etkinleştirilmesi değerlidir, aksi takdirde istemcilerin diğer düğümlere bağlandıklarında tam geçmişi indirmeyi bekleyip aslında almadıkları için başarısız olma riski vardır.

Ana denge, "eski" tarih verilerini sağlama çabamızla ilgilidir. En basit çözüm, yarın eski tarihleri ​​saklamayı durdurmak ve mevcut arşiv düğümleri ile çeşitli merkezi sağlayıcılara dayanarak kopyalamaktı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, öncelikle dağıtık bir şekilde tarihleri ​​saklamak için bir torrent ağı inşa etmek ve entegre etmektir. Burada, "ne kadar çaba gösteriyoruz" iki boyuta sahiptir:

1. En büyük düğüm kümesinin gerçekten tüm verileri depoladığını nasıl garanti ediyoruz?

2. Protokole entegre edilen tarihsel depolama derinliğimiz ne kadar derin?

( için aşırı bir paranoyak yaklaşım, yönetim kanıtını içerecektir: aslında, her bir stake doğrulayıcısının belirli bir oranda tarihsel kayıt saklamasını ve bunları düzenli olarak şifreli bir şekilde kontrol etmesini talep eder. Daha ılımlı bir yaklaşım, her istemci için saklanan tarihsel yüzdesi için gönüllü bir standart belirlemektir.

)2( için, temel uygulama yalnızca bugün tamamlanan çalışmaları içermektedir: 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 kaydını depolayan bir düğüm veya arşiv düğümünü senkronize etmek isterse, diğer arşiv düğümleri çevrimiçi olmasa bile, doğrudan senkronizasyon yoluyla bunu Portal ağı üzerinden gerçekleştirebilir.

) Harita'nın diğer bölümleriyle nasıl etkileşime giriyor?

Eğer düğümlerin çalıştırılması veya başlatılması son derece kolay hale getirmek istiyorsak, tarih depolama gereksinimlerini azaltmak, durumsuzluktan daha önemli denebilir: Düğümün ihtiyaç duyduğu 1.1 TB'da, yaklaşık 300 GB durum, geri kalan yaklaşık 800 GB ise tarihe dönüşmüştür. Ancak durumsuzluk ve EIP-4444'ü gerçekleştirerek, akıllı saatlerde Ethereum düğümü çalıştırma ve yalnızca birkaç dakikada kurulum yapma vizyonunu gerçekleştirebiliriz.

Geçmiş depolamanın kısıtlanması, daha yeni Ethereum düğümlerinin uygulanabilirliğini artırır; yalnızca protokolün en son sürümünü desteklerler ve bu da onları daha basit hale getirir. Örneğin, 2016 yılındaki DoS saldırısı sırasında oluşturulan boş depolama boşluklarının tamamı silindiği için birçok kod satırını güvenle kaldırmak mümkün. Hisse kanıtına geçiş artık tarih olduğuna göre, müşteriler iş kanıtı ile ilgili tüm kodları güvenle silebilir.

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

Durum süresi

) neyi çözüyor?

İstemci depolama geçmişi gereksinimlerini ortadan kaldırmış olsak bile, istemcinin depolama ihtiyaçları her yıl yaklaşık 50 GB kadar artmaya devam edecek, çü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, bir kerelik bir ücret ödeyerek hem mevcut hem de gelecekteki Ethereum istemcilerine kalıcı bir yük getirebilirler.

Durum, geçmişten daha zor "sona erme" olarak kabul edilmektedir, çünkü EVM esasen şu 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 an okunabilir. Eğer durumsuzluğu getirirsek, bazıları bu sorunun o kadar kötü olmadığını düşünebilir: yalnızca özel blok oluşturucu sınıflarının durumu gerçek anlamda saklaması gerekirken, diğer tüm düğümler ### hatta liste oluşturma dahil! ( 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 durumu sona erdirmek isteyebiliriz.

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

Bugün, yeni bir durum nesnesi oluşturduğunuzda ### aşağıdaki üç yöntemden biriyle gerçekleşebilir: (i ( yeni hesaba ETH göndermek, )ii ( kod kullanarak yeni hesap oluşturmak, )iii ( daha önce hiç dokunulmamış bir depolama alanını ayarlamak ) , bu durum nesnesi o durumda sonsuza kadar kalır. Aksine, istediğimiz şey nesnenin zamanla otomatik olarak süresinin dolmasıdır. Temel zorluk, bunu üç hedefi gerçekleştirecek şekilde yapmaktı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 bir mağarada kalır ve geri dönerse, ETH, ERC20, NFT, CDP pozisyonlarına erişimlerini kaybetmemelidir...

• Geliştirici dostu: Geliştiricilerin tamamen tanımadıkları bir 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 gerekmektedir.

Bu hedeflere ulaşamamak sorunları kolayca çözebilir. Örneğin, her durum nesnesinin bir de son kullanma tarihi sayacını saklamasını sağlayabilirsiniz. ), son kullanma tarihini uzatmak için ETH'yi yakarak yapılabilir, bu herhangi bir zamanda okunabilir veya yazılabilir şekilde otomatik olarak gerçekleşebilir. ( ve son kullanma tarihini silmek için durum nesnelerini döngü ile geçiren bir süreç de olabilir. Ancak bu, ek hesaplama gereksinimlerini ) hatta depolama gereksinimlerini getirir. ( ve kesinlikle kullanıcı dostu olma gereksinimlerini karşılayamaz. Geliştiricilerin değeri sıfıra sıfırlanan kenar durumlarını içeren durumları anlaması da zordur. Eğer sözleşme kapsamında bir son kullanma zamanlayıcısı kurarsanız, bu teknik olarak geliştiricilerin hayatını kolaylaştırır, ancak ekonomik olarak daha zor hale getirir: Geliştiriciler sürekli depolama maliyetlerini kullanıcıya "aktar" etmeyi düşünmek zorundadır.

Bunlar, Ethereum çekirdek geliştirme topluluğunun yıllardır çözmeye çalıştığı sorunlardır; "blok zinciri kirası" ve "yenilenme" gibi önerileri de içerir. Sonunda, önerilerin en iyi kısımlarını birleştirdik ve "bilinen en az kötü çözümler" üzerinde iki kategoriye odaklandık:

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

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

)# Kısmi durum süresi dolması

Bazı durumların süresi dolmuş önerileri aynı prensipleri takip eder. Durumu parçalara ayırıyoruz. Herkes "en üst harita"yı kalıcı olarak depolar, bu harita boş veya dolu olabilir. Her bir parçadaki veriler yalnızca bu verilere en son erişildiğinde depolanır. Artık depolanmadığında bir "canlandırma" mekanizması vardır.

Bu öneriler arasındaki temel farklar şunlardır: ###i ("son zamanlar"ı nasıl tanımladığımız ve )ii ("blok"u nasıl tanımladığımız? Spesifik bir öneri EIP-7736'dır, bu öneri Verkle ağaçlarına tanıtılan "dal yaprağı" tasarımına dayanmaktadır )herhangi bir biçimde durum olmadan uyumlu olmasına rağmen, örneğin ikili ağaç (. Bu tasarımda, birbirine bitişik başlıklar, kodlar ve depolama alanları aynı "ana gövde" altında saklanır. Bir dal altında saklanan verilerin en fazla 256 * 31 = 7.936 bayt olabilir. Birçok durumda, bir hesabın tüm başlığı ve kodu ile birçok anahtar depolama alanı aynı ana gövde altında saklanacaktır. Verilen ana gövde altındaki veriler 6 ay içinde okunmaz veya yazılmazsa, bu veriler artık saklanmaz, yalnızca bu verilerin 32 baytlık taahhüdü )"stub" (saklanır. Gelecekte bu verilere erişim sağlayan işlemler "veriyi diriltmek" zorunda kalacak ve stub'a göre kontrol etmek için bir kanıt sunacaktır.

Benzer fikirleri gerçekleştirmek için başka yöntemler de vardır. Örneğin, hesap seviyesi granülasyonu yeterli değilse, ağacın her 1/232 parçasının benzer bir sap yaprağı mekanizması tarafından kontrol edildiği bir plan oluşturabiliriz.

Teşvik faktörleri nedeniyle, bu daha karmaşık hale geliyor: Saldırganlar, bir alt ağa büyük miktarda veri koyarak ve her yıl tek bir işlem göndererek "ağacı güncelleyebilirler", bu da istemcinin büyük miktarda durumu kalıcı olarak depolamasını zorlar. Eğer yenileme maliyetini ağaç boyutu ile orantılı ) veya yenileme süresini ters orantılı ( hale getirirseniz, o zaman birisi, büyük miktarda veriyi kendi alt ağacına koyarak diğer kullanıcıları zarar verebilir. İnsanlar, alt ağaç boyutuna göre dinamikleştirerek bu iki sorunu sınırlamaya çalışabilirler: örneğin, her ardışık 216= 65536 durum nesnesi bir "grup" olarak düşünülebilir. Ancak, bu fikirler daha karmaşıktır; dal tabanlı yöntem basittir ve teşvikleri ayarlamak mümkündür, çünkü genellikle dal.