Vitalik: 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 yerde gerçekleşir:

Tarihsel veriler: Geçmişteki herhangi bir anda gerçekleştirilen her işlem ve oluşturulan her hesap, tüm istemciler tarafından kalıcı olarak saklanmalı ve herhangi bir yeni istemci tarafından indirilmeli, böylece ağa tamamen senkronize olmalıdır. Bu, istemci yükünün ve senkronizasyon süresinin zamanla sürekli artmasına neden olur, zincirin kapasitesi sabit kalsa bile.

Protokol Özelliği: Yeni özellikler eklemek, eski özellikleri silmekten çok daha kolaydır, bu da zamanla kod karmaşıklığının artmasına neden olur.

Ethereum'in 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 aynı zamanda, blok zincirini büyük kılan ana özelliklerden birini de korumalıyız: kalıcılık. Bir NFT'yi, bir işlem çağrı verisindeki bir aşk mektubunu veya 1 milyon dolarlık bir akıllı sözleşmeyi zincire koyabilirsiniz, on yıl bir mağaraya girip çıktığınızda, hala orada sizi okumak ve etkileşimde bulunmak için bekliyor. DApp'lerin tamamen merkeziyetsiz bir şekilde güvenle hareket edebilmesi ve yükseltme anahtarlarını silmesi için, bağımlılıklarının kendilerini yok edecek şekilde yükselmeyeceğinden emin olmaları gerekir - özellikle L1'in kendisi.

Eğer kararlı olursak, bu iki talep arasında denge kurmak ve sürekliliği korurken aşırılıklar, karmaşıklık ve çöküşü en aza indirmek veya tersine çevirmek kesinlikle mümkündür. Organizmalar bunu yapabilir: Çoğu organizma zamanla yaşlansa da, şanslı azınlıklar bunu başaramaz. Toplumsal sistemler bile çok uzun bir ö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ı ay boyunca eski verileri sakladı. Ethereum'a bu yolu daha genel bir şekilde bulmak ve uzun vadeli istikrarlı bir nihai sonuca ulaşmak, Ethereum'un uzun vadeli ölçeklenebilirliğinin, teknolojik sürdürülebilirliğinin ve hatta güvenliğinin nihai zorluğudur.

The Purge: Ana hedef.

İstemci depolama gereksinimlerini azaltmak için her düğümün tüm tarihsel kayıtları veya hatta nihai durumu kalıcı olarak saklama gereksinimini azaltarak veya ortadan kaldırarak.

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

Makale Dizini:

Geçmişin sona ermesi

State expiry（状态到期）

Özellik temizliği

Tarih sona erdi

Hangi sorunu çözüyor?

Bu makale 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ına ihtiyaç var. Bunun büyük çoğunluğu geçmişe aittir: tarihsel bloklar, işlemler ve makbuzlar hakkında veriler, bunların çoğu yıllardır mevcut. Bu, Gas sınırları 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?

Tarihi depolama sorununun temel bir basitleştirilmiş özelliği, her bloğun hash bağlantısı (ve diğer yapılar) aracılığıyla bir önceki bloğa işaret etmesi nedeniyle, mevcut konsensusa ulaşmanın tarihi konsensusa ulaşmak için yeterli olmasıdır. Ağ en son blok üzerinde konsensusa ulaştığı sürece, herhangi bir tarihsel 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 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 modeli iken, tarih N-of-N güven modelidir.

Bu, kayıtlarımızı nasıl saklayabileceğimiz konusunda birçok seçenek sunuyor. Doğal bir seçenek, her düğümün yalnızca verilerin küçük bir kısmını sakladığı bir ağdır. Bu, tohum ağlarının onlarca yıldır çalıştığı yoldur: ağ toplamda milyonlarca dosya saklayıp dağıtsa da, her katılımcı yalnızca birkaç dosyayı saklayıp dağıtır. Belki de sezgiye aykırı olarak, bu yöntem verilerin sağlamlığını azaltmak zorunda bile değildir. Düğümleri çalıştırmayı daha ekonomik hale getirerek, her biri rastgele %10'luk bir tarih kaydını saklayan 100.000 düğümlük bir ağ kurabiliriz; bu durumda her veri 10.000 kez kopyalanacaktır - bu, her düğümün her şeyi sakladığı 10.000 düğümlük 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şladı. Konsensüs blokları (yani, hisse kanıtı konsensüsü ile ilgili kısım) yalnızca yaklaşık 6 ay depolanır. Blob yalnızca yaklaşık 18 gün depolanı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 ve ardından eski verilerin dağıtılmış bir ağ biçiminde depolanacağı, Ethereum düğümlerinden oluşan merkezi olmayan bir ağ oluşturmaktır.

Erasure kodları, kopyalama faktörünü aynı tutarken sağlamlığı 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 ile konsensüs blok verilerini de blob içine koymaktır.

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

EIP-4444；

Torrents ve EIP-4444；

Portallar Ağı;

Portal Ağı ve EIP-4444;

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

Gas limitini nasıl artırırsınız (Paradigm).

ne yapmamız gerekiyor, neyi dengelememiz gerekiyor?

Kalan ana işler, en azından yürütme geçmişi için, ancak nihayetinde konsensüs ve blob'u da içeren, geçmişi saklamak için somut bir dağıtık çözüm inşa etmek ve entegre etmeyi içerir. En basit çözüm, mevcut torrent kütüphanesini (i) basitçe tanıtmak ve (ii) olarak adlandırılan Portal ağına Ethereum yerel çözümünü getirmektir. 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üne ihtiyaç duyar. Bu nedenle, tüm istemciler için aynı anda etkinleştirilmesi değerlidir, aksi takdirde, diğer düğümlere bağlanmayı bekleyen istemcilerin tam geçmişi indirmedikleri için başarısız olma riski vardır.

Ana dengeler, "eski" tarih verilerini sağlamaya yönelik çabalarımızla ilgilidir. En basit çözüm, yarın eski tarihleri depolamayı 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ı kayıt yeri olarak konumunu zayıflatır. Daha zor ama daha güvenli bir yol, önce torrent ağını inşa etmek ve entegre etmek, tarihi dağıtık bir şekilde depolamaktır. Burada, "ne kadar çaba gösteriyoruz" 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ğimiz ne kadar derin?

(1) için aşırı bir obsesif yaklaşım, bir güvence kanıtı gerektirecektir: temelde, her hisse kanıtı doğrulayıcısının belirli bir oranında geçmiş kayıtları saklaması ve bunları düzenli olarak şifreli bir şekilde kontrol etmesi gerekecektir. Daha ılımlı bir yaklaşım, her istemcinin depoladığı geçmiş yüzdesi için gönüllü bir standart belirlemektir.

(2) için, temel uygulama sadece bugün tamamlanan çalışmaları içeriyor: Portal, tüm Ethereum tarihini içeren ERA dosyasını depoladı. Daha kapsamlı bir uygulama, bunu senkronizasyon sürecine bağlamayı içerecektir; 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 yaparak 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, tarihsel depolama gereksinimlerinin azaltılması, durumsuzluktan daha önemli denebilir: Düğümün ihtiyaç duyduğu 1.1 TB'ın yaklaşık 300 GB'ı durum, geri kalan yaklaşık 800 GB'ı ise tarihsel veridir. Sadece durumsuzluğun sağlanması ve EIP-4444 ile akıllı saatlerde Ethereum düğümünü çalıştırmanın ve sadece birkaç dakikada ayar yapmanın vizyonunu gerçekleştirmek mümkündür.

Geçmiş depolamanın sınırlanması, daha yeni Ethereum düğümlerinin daha uygulanabilir hale gelmesini sağladı, sadece protokolün en son sürümünü destekler, bu da onları daha basit hale getirir. Örneğin, artık 2016'daki DoS saldırısı sırasında oluşturulan boş depolama yuvalarının tamamı silindiğinden, birçok kod satırını güvenli bir şekilde silebilirsiniz. Hisse kanıtına geçiş tarih oldu, müşteriler iş kanıtı ile ilgili tüm kodları güvenli bir şekilde silebilir.

Durum süresi dolma

hangi sorunu çözüyor?

Müşteri tarafında geçmiş kayıtları saklama gerekliliğini ortadan kaldırmış olsak bile, müşteri depolama ihtiyaçları 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 tek seferlik bir ücret ödeyerek mevcut ve gelecekteki Ethereum müşterilerine kalıcı bir yük getirebilirler.

Durum, tarihten daha "geçmiş" olmakta zor, çünkü EVM temelde böyle bir 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 kötü olmadığını düşünebilir: 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 olarak çalışabilir. Ancak, durumsuzluğa fazla bağımlı olmak istemediğimiz görüşü var; nihayetinde, Ethereum'un merkeziyetsizliğini korumak için durumu geçersiz kılmak isteyebiliriz.

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

Bugün, yeni bir durum nesnesi oluşturduğunuzda (bu, 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 erişilmemiş bir depolama yuvası ayarlamak), bu durum nesnesi o durumda sonsuza dek kalır. Aksine, istediğimiz şey nesnenin zamanla otomatik olarak süresinin dolmasıdır. Temel zorluk, bunu üç hedefe ulaşacak şekilde yapmaktır:

Verimlilik: Vade sürecini işletmek için büyük miktarda ek hesaplama gerektirmiyor.

Kullanıcı dostu: Eğer biri beş yıl boyunca bir mağarada kalırsa ve geri dönerse, ETH, ERC20, NFT, CDP pozisyonlarına erişimini kaybetmemelidir...

Geliştirici dostu: Geliştiricilerin tamamen tanıdık olmayan bir düşünce modeline geçmeleri gerekmiyor. Ayrıca, şu anda katı ve güncellenmeyen uygulamaların normal bir şekilde çalışmaya devam etmesi gerekiyor.

Bu hedefleri karşılamamak sorunları kolayca çözmeyi sağlar. Örneğin, her durum nesnesinin bir sona erme tarihini depolayan bir sayıcı da bulundurmasını sağlayabilirsiniz (sona erme tarihini uzatmak için ETH yakarak, bu otomatik olarak okuma veya yazma sırasında gerçekleşebilir) ve sona erme tarihi olan durum nesnelerini silmek için durumları döngüsel olarak gözden geçiren bir süreç oluşturabilirsiniz. Ancak bu, ek hesaplama (hatta depolama gereksinimleri) getirir ve kesinlikle kullanıcı dostu olma gereksinimlerini karşılamaz. Geliştiricilerin bazen sıfıra sıfırlanan depolama değerlerini içeren kenar durumlarını anlaması da zor. Sözleşme kapsamı içinde bir sona erme sayacı ayarlarsanız, bu teknik olarak geliştiricilerin yaşamını kolaylaştırır, ancak ekonomiyi daha da zorlaştırır: Geliştiricilerin sürekli depolama maliyetlerini kullanıcıya nasıl "aktarması" gerektiğini düşünmesi gerekir.

Bunlar, Ethereum çekirdek geliştirme topluluğunun yıllardır çözmeye çalıştığı sorunlardır. "Blockchain kirası" ve "yenilenme" gibi önerileri de içermektedir. Sonunda, önerilerin en iyi kısımlarını bir araya getirdik ve "bilinen en az kötü çözüm" olarak iki kategoriye odaklandık:

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

Kısmi durum süresi dolumu

Bazı durumların süresi dolmuş teklifleri aynı ilkelere uyar. Durumu bloklara ayırıyoruz. Herkes "en üst harita"yı kalıcı olarak depolar, burada blok boş veya dolu olabilir. Veriler, yalnızca o veriye en son erişildiğinde her blokta depolanır. Bir "diriltme" mekanizması vardır, eğer artık depolanmıyorsa.

Bu öneriler arasındaki ana fark şudur: (i) "nasıl tanımlıyoruz