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

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

Tarih verileri: Tarih boyunca herhangi bir anda gerçekleştirilen her işlem ve oluşturulan her 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 olur. 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 kaldırmaktan ç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, bu sırada, blok zincirini harika kılan temel özelliklerden birini korumamız gerekiyor: kalıcılık. Bir NFT, bir işlem çağrısı verisindeki bir aşk mektubu veya 1 milyon dolar içeren bir akıllı sözleşmeyi zincire koyup on yıl boyunca bir mağaraya girebilir ve çıktığınızda onun hala sizi okumaya ve etkileşimde bulunmaya beklediğini görebilirsiniz. DApp'lerin tamamen merkeziyetsiz bir şekilde rahatça hareket edebilmesi ve güncelleme anahtarlarını kaldırabilmeleri için, bağımlılıklarının kendilerini yok etmeden güncellenmeyeceğinden emin olmaları gerekiyor - özellikle de L1'in kendisi.

Eğer kararlıysak, bu iki talep arasında dengeyi sağlamak ve sürekliliği korurken şişkinlik, karmaşıklık ve gerilemeyi en aza indirmek veya tersine çevirmek kesinlikle mümkündür. Canlılar bunu yapabilir: Çoğu canlı zamanla yaşlansa da, birkaç şanslı olan yaşlanmaz. Hatta sosyal sistemler de çok uzun ömre sahip olabilir. Bazı durumlarda Ethereum başarı elde etmiştir: İş kanıtı ortadan kalktı, SELFDESTRUCT opcode'ları çoğunlukla kayboldu, beacon chain düğümleri en fazla altı aylık eski verileri depoladı. Ethereum için 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ğinin nihai zorluğudur.

The Purge: Ana hedef.

Müşteri depolama gereksinimlerini azaltmak için her bir düğümün tüm geçmiş kayıtları veya hatta nihai durumu kalıcı olarak saklama ihtiyacını azaltmak veya ortadan kaldırmak.

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

Makale Dizini:

History expiry（历史记录到期）

Durum süresi doldu

Özellik temizliği

Geçerlilik süresi

neyi çözüyor?

Bu makalenin yazıldığı tarihte, tamamen senkronize bir Ethereum düğümü, istemciyi çalıştırmak için yaklaşık 1.1 TB disk alanına ihtiyaç duymaktadır, ayrıca konsensüs istemcisi için de yüzlerce GB disk alanı gerekmektedir. Bunun büyük bir kısmı tarihe dayanmaktadır: Tarihi bloklar, işlemler ve makbuzlarla ilgili veriler, bunların çoğu yıllar öncesine dayanıyor. Bu, Gas sınırı hiç artmasa bile, düğümün boyutunun her yıl yüzlerce GB artmaya devam edeceği anlamına geliyor.

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

Tarihsel depolama probleminin bir anahtar basitleştirilmiş özelliği, her bloğun hash bağlantıları (ve diğer yapılar) aracılığıyla bir önceki bloğa işaret etmesi nedeniyle, mevcut konsensüsün sağlanmasının tarihsel konsensüsün sağlanması için yeterli olmasıdır. Ağ, en son blok üzerinde konsensüse ulaştığı sürece, herhangi bir tarihsel blok ya da işlem ya da durum (hesap bakiyesi, rastgele sayı, 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 onun doğruluğunu doğrulamasını sağlar. 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 verilerin küçük bir kısmını depoladığı bir ağdır. İşte bu, tohum ağlarının on yıllardır çalıştığı yöntemdir: ağ toplamda milyonlarca dosyayı depolayıp dağıtsa da, her bir katılımcı yalnızca bunlardan birkaç dosyayı depolayıp dağıtır. Belki de sezgilerimize aykırı olarak, bu yöntem veri sağlamlığını azaltmak zorunda bile değil. Düğümlerin çalışmasını daha ekonomik hale getirerek, her biri rastgele %10'luk bir tarih kaydını depolayan 100.000 düğümlük bir ağ kurabiliriz; bu durumda her veri 10.000 kez kopyalanmış olur - bu, her düğümün her şeyi depoladığı 10.000 düğümlük bir ağın kopyalama faktörü ile tam olarak aynıdır.

Günümüzde, Ethereum tüm düğümlerin tüm geçmişi kalıcı olarak depolama modelinden kurtulmaya başladı. Konsensüs blokları (yani, hisse kanıtı konsensüsü ile ilgili kısımlar) yalnızca yaklaşık 6 ay süreyle depolanmaktadır. Blob yalnızca yaklaşık 18 gün süreyle 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 her şeyi depolamakla sorumlu olduğu, muhtemelen yaklaşık 18 gün süren birleşik bir dönem oluşturmaktır, ardından eski verilerin dağıtık bir ağ şeklinde depolanacağı Ethereum düğümlerinden oluşan bir eşler arası ağ oluşturulacaktır.

Erasure kodları, kopyalama 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 zaten işlenmiştir. En basit çözüm muhtemelen bu Erasure kodlarını yeniden kullanmak ve yürütme ile konsensüs blok verilerini de blob'a koymaktır.

ile mevcut araştırmalar arasında hangi bağlantılar var?

EIP-4444；

Torrentler ve EIP-4444；

Portallar Ağı;

Portal Ağı ve EIP-4444;

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

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

Ne yapmamız gerekiyor, neyi dengelememiz gerekiyor?

Kalan ana işler, geçmişi depolamak için somut bir dağıtık çözüm inşa etmek ve entegre etmekten ibarettir------en azından yürütme geçmişi, ancak nihayetinde mutabakat ve blob da dahil olacaktır. En basit çözüm, (i) mevcut torrent kütüphanelerinin basitçe dahil edilmesi ve (ii) Portal ağı olarak adlandırılan Ethereum yerel çözümüdür. Bunlardan herhangi biri dahil edildiğinde, EIP-4444'ü açabiliriz. EIP-4444 kendisi sert çatallaşma gerektirmiyor, ancak yeni bir ağ protokolü sürümü gerektiriyor. 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 almamış olmaları nedeniyle başarısız olma riski vardır.

Ana dengeler, "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 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 verileri dağıtık bir şekilde saklamaktır. Burada, "ne kadar çaba gösteriyoruz" iki boyuta sahiptir:

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

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

(1) için aşırı bir takıntılı yaklaşım, her bir hisse kanıtı doğrulayıcısının belirli bir oranda geçmiş verileri saklamasını ve bunları düzenli olarak şifreli bir şekilde kontrol etmesini gerektiren bir yönetim kanıtı içerecektir. Daha ılımlı bir yaklaşım, her istemcinin sakladığı geçmiş yüzdesi için gönüllü bir standart belirlemektir.

(2) için, temel uygulama yalnızca bugün tamamlanan işleri içeriyor: Portal, tüm Ethereum tarihini içeren ERA dosyasını depoladı. 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ğı üzerinden bunu gerçekleştirebilir.

Diğer yol haritası bölümleriyle nasıl etkileşime geçiyor?

Eğer düğümlerin çalışmasını veya başlatılmasını son derece kolay hale getirmek istiyorsak, geçmiş depolama gereksinimlerini azaltmak, durumsuzluktan daha önemli denebilir: Düğümün ihtiyaç duyduğu 1.1 TB'nın yaklaşık 300 GB'ı durum, geri kalan yaklaşık 800 GB'ı ise geçmiş olmuştur. Sadece durumsuzluğun ve EIP-4444'ün gerçekleştirilmesi, akıllı saatlerde Ethereum düğümü çalıştırma ve sadece birkaç dakika içinde ayarlama 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ü destekliyorlar, bu da onları daha basit hale getiriyor. Örneğin, artık 2016'daki DoS saldırısı sırasında oluşturulan boş depolama slotlarının tamamen silinmesi sayesinde birçok kod satırını güvenle kaldırmak mümkün. Hisse ispatına geçiş tarihsel bir hal aldığından, müşteriler iş kanıtı ile ilgili tüm kodları güvenle silebilir.

Durum sona erme

neyi çözüyor?

Müşteri tarafında geçmişi saklama ihtiyacını ortadan kaldırsak bile, müşteri depolama gereksinimleri 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, şu anki ve gelecekteki Ethereum müşterilerine kalıcı bir yük getirmek için bir defaya mahsus bir ücret ödeyebilirler.

Geçmişten daha zor olan "son tarih", EVM'nin temelde şu varsayıma göre tasarlandığı gerçeğidir: 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 kötü olmayabileceğini düşünüyor: Sadece özel blok oluşturucu sınıflarının durumu gerçekten saklaması gerekiyor, diğer tüm düğümler (hatta liste oluşturmayı da içeren!) durumsuz ç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 geçersiz kılmayı umabiliriz.

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

Bugün, yeni bir durum nesnesi oluşturduğunuzda (bu 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 erişilmemiş bir depolama slotu ayarlamak), bu durum nesnesi o durumda sonsuza dek kalır. Bunun yerine, istediğimiz şey nesnelerin zamanla otomatik olarak süresinin 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 gerekmez.

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 dostu: 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 şekilde çalışmaya devam edebilmesi gerekir.

Bu hedefleri karşılamamak, sorunları çözmeyi kolaylaştırır. Örneğin, her durum nesnesinin bir son tarih sayacı saklamasını sağlayabilirsiniz (son tarihi uzatmak için ETH yakarak, bu herhangi bir zamanda okuma veya yazma sırasında otomatik olarak gerçekleşebilir) ve son tarihleri silmek için durumları döngü içinde geçiren bir süreç olmalıdır. Ancak bu, ek hesaplama (hatta depolama gereksinimleri) getirir ve kesinlikle kullanıcı dostu olma gereksinimlerini karşılayamaz. Geliştiricilerin, depolanan değerlerin bazen sıfıra sıfırlanmasını içeren kenar durumlarını anlaması da zordur. Eğer sözleşme kapsamı içinde bir son tarih sayacı ayarlarsanız, bu teknik olarak geliştiricilerin hayatını kolaylaştırır, ancak ekonomiyi daha karmaşık hale getirir: Geliştiricilerin sürekli depolama maliyetlerini kullanıcıya "aktarmayı" düşünmeleri gerekir.

Bunlar, Ethereum çekirdek geliştirme topluluğunun yıllardır çözmeye çalıştığı sorunlar, "blok zinciri kirası" ve "yenilenme" gibi önerileri içeriyor. Sonunda, önerilerin en iyi kısımlarını bir araya getirdik ve iki tür "bilinen en kötü çözüm" üzerine odaklandık:

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

Kısmi durum süresi dolması

Bazı durum sona erme teklifleri aynı ilkeleri takip eder. Durumu parçalara ayırıyoruz. Herkes "üst düzey harita"yı kalıcı olarak depolar, burada parçalar boş veya dolu olabilir. Her parçada veriler yalnızca en son erişilen veriler depolanır. Artık depolanmadığında bir "diriltme" mekanizması vardır.

![Vitalik: Ethereum'un olası geleceği, The Purge](https://