Ethereum'in Olası Geleceği: The Purge

Ethereum 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 meydana gelir:

Tarihsel veriler: Tarih boyunca herhangi bir zamanda gerçekleştirilen her işlem ve oluşturulan her hesap, tüm istemciler tarafından kalıcı olarak depolanmalı ve herhangi bir yeni istemci tarafından indirilmelidir, böylece ağ ile tamamen senkronize olurlar. Bu, istemci yükü ve senkronizasyon süresinin zamanla 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 büyük kılan temel özelliklerden birini korumalıyız: kalıcılık. Bir NFT'yi, bir işlem çağrısı verisindeki bir aşk mektubunu veya 1 milyon dolarlık bir akıllı sözleşmeyi zincire koyabilirsiniz, on yıl boyunca bir mağaraya girebilir ve çıktığınızda hala sizi okumak ve etkileşimde bulunmak için bekliyor olduğunu görebilirsiniz. DApp'lerin tamamen merkeziyetsiz bir şekilde rahatça çalışabilmesi ve güncelleme anahtarını silmeleri için, bağımlılıklarının kendilerini yok edici bir şekilde güncellenmeyeceğinden emin olmaları gerekiyor - özellikle de L1'in kendisi.

Eğer kararlı olursak, bu iki talep arasında bir denge kurmayı ve sürekliliği korurken şişkinlik, karmaşıklık ve gerilemeyi en aza indirmeyi veya tersine çevirmeyi kesinlikle başarabiliriz. Organizma bunu yapabilir: Çoğu organizma zamanla yaşlansa da, birkaç şanslı olan bunu başaramaz. Sosyal sistemler bile çok uzun bir ömre sahip olabilir. Bazı durumlarda, Ethereum başarı elde etti: İş kanıtı ortadan kayboldu, SELFDESTRUCT opcode’unun çoğu kayboldu ve beacon chain düğümleri en fazla altı ay eski veriyi depoladı. Ethereum'a bu yolu daha genel bir şekilde bulmak ve uzun vadeli istikrarlı bir nihai sonuca ulaşmak, Ethereum'un uzun vadeli ölçeklenebilirliği, teknik sürdürülebilirliği ve hatta güvenliği için nihai bir meydan okumadır.

The Purge: Ana hedef.

İstemci depolama gereksinimlerini azaltmak için her bir düğümün tüm geçmiş kayıtları veya nihai durumu kalıcı olarak saklama gereğini azaltarak veya ortadan kaldırarak.

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

Makalelerin Dizini:

Geçmiş süresi doldu( geçmiş kayıtları süresi doldu)

Devlet son kullanma tarihi(durumu sona erdi)

Özellik temizliği(特征清理)

Geçmiş son kullanma tarihi

Hangi sorunu çözüyor?

Bu makale yazıldığı sırada, tamamen senkronize bir Ethereum düğümünün, istemcinin çalıştırılması 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ına ihtiyaç duyulmaktadır. Bunun büyük bir kısmı tarihsel verilerden oluşmaktadır: Tarihsel bloklar, işlemler ve makbuzlarla ilgili veriler, bunların çoğu yıllardır mevcuttur. Bu, Gas limitleri hiç artmasa bile, düğüm boyutunun her yıl yüzlerce GB artmaya devam edeceği anlamına gelir.

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

Tarihi depolama sorununun bir ana basitleştirilmiş özelliği, her blok ( ve diğer yapılar ) ile bir önceki bloğa hash bağlantısıyla işaretlendiğinden, mevcut konsensusa ulaşmak için tarihe ulaşmak yeterlidir. Ağ, en son blok üzerinde konsensusa ulaştığı sürece, herhangi bir tarihi blok veya 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 gelir ve 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, tarihsel kayıtları 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 dosya depolayıp dağıtsa da, her katılımcı yalnızca bunlardan birkaçını depolar ve dağıtır. Belki de sezgilerle çelişen bir şekilde, bu yöntem verilerin sağlamlığını azaltmak zorunda bile değildir. Eğer düğümlerin çalıştırılmasını daha ekonomik hale getirerek 100.000 düğümlü bir ağ kurabilirsek ve her düğüm rastgele %10'luk bir tarihsel kaydı depoluyorsa, o zaman her veri 10.000 kez kopyalanacaktır - bu, her düğümün her şeyi depoladığı 10.000 düğümlü bir ağ ile tamamen aynı olan bir kopyalama faktörü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 (, hisse kanıtı konsensüsü ile ilgili kısımlarla birlikte, yalnızca yaklaşık 6 ay depolanmaktadır. Blob yalnızca yaklaşık 18 gün depolanmaktadır. EIP-4444, geçmiş 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 depoladığı ve ardından eski verileri dağıtık bir ağ biçiminde depolamak için Ethereum düğümlerinden oluşan bir eşler arası ağ kuracağı bir dönem oluşturmaktır; bu dönem ) yaklaşık 18 gün olabilir (.

![Vitalik: Ethereum'in olası geleceği, The Purge])ian/2024/10/27/images/f62684c615eed31373c7711933176f43.jpg(

Erasure kodları, kopyalama faktörünü aynı tutarken sağlamlığı artırmak için kullanılabilir. Aslında, Blob zaten 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 ve konsensüs blok verilerini de blob içine koymaktır.

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

EIP-4444;

Torrentler 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 (.

) ne yapılması gerekiyor, neyi dikkate almak gerekiyor?

Kalan ana işler, en azından yürütme geçmişini saklamak için belirli bir dağıtık çözüm inşa etmek ve entegre etmekten oluşmaktadır, ancak nihayetinde konsensüsü ve blob'u da içermektedir. En basit çözüm, mevcut torrent kütüphanesini ###i( basitçe dahil etmek ve )ii( Ethereum'un yerel çözümü olarak adlandırılan Portal ağıdır. Bunlardan herhangi birini dahil ettiğimizde, EIP-4444'ü açabiliriz. EIP-4444'ün kendisi sert bir hard fork gerektirmemektedir, ancak yeni bir ağ protokolü sürümüne ihtiyaç duymaktadır. Bu nedenle, tüm istemciler için aynı anda etkinleştirilmesi değerlidir, aksi takdirde, diğer düğümlere bağlanarak tam geçmişi indirmeyi bekleyen istemcilerin aslında alınmadığı için çökme riski bulunmaktadır.

Ana denge, "eski" tarih verilerini sağlamaya nasıl çalıştığımızla ilgilidir. En basit çözüm, yarın eski tarih verilerini depolamayı durdurmak ve mevcut arşiv düğümlerine ve çeşitli merkezi sağlayıcılara kopyalamak için güvenmektir. 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 ederek tarihi verileri dağıtık 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 tarih depolama derinliği ne kadar derin?

) için aşırı bir paranoya yöntemi, bir yönetim kanıtı gerektirecektir: aslında, her bir hisse kanıtı doğrulayıcısından belirli bir tarihsel kayıt oranını saklaması ve bunları düzenli olarak şifreli bir şekilde kontrol etmesi istenmektedir. Daha ılımlı bir yaklaşım, her bir istemci tarafından saklanan tarihsel yüzdelik 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 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 bulunuyor?

Eğer düğümlerin çalışmasını veya başlatılmasını son derece kolay hale getirmek istiyorsak, tarihsel depolama gereksinimlerini azaltmanın durumdan daha önemli olduğunu söyleyebiliriz: düğümün ihtiyaç duyduğu 1.1 TB'ın yaklaşık 300 GB'ı durum, geri kalan yaklaşık 800 GB'ı ise tarih haline gelmiştir. Durumsuzluğu ve EIP-4444'ü gerçekleştirmeden, akıllı saatlerde Ethereum düğümü çalıştırma ve sadece birkaç dakika içinde kurma vizyonunu gerçekleştirmek mümkün değildir.

Geçmiş depolama kısıtlaması, daha yeni Ethereum düğümlerinin daha uygulanabilir hale gelmesini sağlıyor, yalnızca protokolün en son sürümünü destekliyor ve 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 tamamen silinmiş olması nedeniyle birçok kod satırını güvenle silebiliriz. Hisse kanıtına geçiş tarihi olduğuna göre, istemciler iş kanıtı ile ilgili tüm kodları güvenle silebilir.

![Vitalik: Ethereum'in Olası Geleceği, The Purge])ian/2024/10/27/images/b3e2c5d4e7e1d40234643b84b51b43c1.jpg###

Durum süresi

( neyi çözüyor?

Müşteri tarafında kayıt geçmişini saklama gereğini ortadan kaldırmış olsak bile, müşteri tarafındaki depolama ihtiyacı her yıl yaklaşık 50 GB artmaya devam edecek, çünkü durum sürekli büyüyor: 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ı olarak yük getirmek için tek seferlik bir ücret ödeyebilirler.

Durum, tarihten daha zor "sona ermek" çünkü EVM esasen böyle bir varsayım etrafında tasarlandı: bir durum nesnesi oluşturulduğunda, her zaman var olacaktır ve herhangi bir işlem tarafından her zaman okunabilir. Eğer süresiz durumu getirirsek, bazıları bu sorunun o kadar kötü olmayabileceğini düşünüyor: yalnızca özel blok inşa edici türleri gerçekten durumu depolamak zorunda, diğer tüm düğümler ) hatta liste üretimini içeren! ### durumsuz çalışabilir. Ancak, aşırı durumsuzluğa bağımlı olmamak istemediğimiz görüşü var; sonunda, 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 üç yoldan biriyle gerçekleşebilir: ###i ( yeni bir hesaba ETH göndermek, (ii ) kod kullanarak yeni bir hesap oluşturmak, (iii ) daha önce hiç dokunulmamış bir depolama alanını ayarlamak (, bu durum nesnesi her zaman o durumda kalır. Aksine, istediğimiz nesnenin zamanla otomatik olarak süresi dolmasıdır. Ana 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ğaraya girip geri dönerse, ETH, ERC20, NFT, CDP pozisyonlarına erişim hakkını kaybetmemelidir...

Geliştirici dostluğu: Geliştiricilerin tamamen aşina olmadıkları düşünce modellerine geçmeleri gerekmiyor. Ayrıca, şu anda katılaşmış ve güncellenmeyen uygulamaların normal çalışmaya devam etmesi gerekir.

Bu hedeflere ulaşmamak, sorunları çözmeyi kolaylaştırır. Örneğin, her durum nesnesinin bir son kullanma tarihi sayacını da saklamasını sağlayabilirsiniz; ), son kullanma tarihini uzatmak için ETH yakılarak yapılabilir, bu, 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ü ile geçiren bir süreç olabilir. Ancak bu, ek hesaplama ( ve hatta depolama gereksinimlerini ) beraberinde getirir 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ı akıl yürütmesi de zor olabilir. Sözleşme kapsamındaki bir son kullanma sayacı ayarladığınızda, bu teknik olarak geliştiricilerin hayatını kolaylaştırır, ancak ekonomiyi daha da zorlaştırır: geliştiricilerin sürekli depolama maliyetlerini "kullanıcılara aktarmayı" düşünmesi gerekir.

Bunlar, Ethereum çekirdek geliştirme topluluğunun yıllardır çözmeye çalıştığı sorunlardır; "blok zinciri kirası" ve "yeniden doğuş" gibi öneriler de dahil. Sonunda, önerilerin en iyi kısımlarını birleştirdik ve iki tür "en az kötü bilinen çözümler" üzerinde yoğunlaştık:

• Kısmi durum süresi dolmuş çözümü
• Adres döngüsüne dayalı durum sonlandırma önerisi.

( Kısmi durum süresi dolması

Bazı durum sona erme teklifleri aynı ilkelere uyar. Durumu bloklara ayırıyoruz. Herkes "üst düzey harita"yı kalıcı olarak saklar, burada bloklar boş veya dolu olabilir. Veriler yalnızca en son erişilmişse her blokta saklanır. Artık saklanmadığında bir "diriltme" mekanizması vardır.

![Vitalik: Ethereum'in Olası Geleceği, The Purge])