Ethereum'in Olası Geleceği: The Purge

Yazar: Vitalik Buterin

Ethereum'in 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 gerçekleşir:

Tarihî veriler: Tarih boyunca herhangi bir anda gerçekleştirilen herhangi bir işlem ve oluşturulan herhangi bir hesap, tüm istemciler tarafından kalıcı olarak saklanmalı ve herhangi bir yeni istemci tarafından indirilmelidir, böylece ağa tamamen senkronize olmalıdır. 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şıt baskı uygulamamız gerekiyor, zamanla karmaşıklığı ve genişlemeyi azaltmalıyız. Ancak aynı zamanda, blok zincirini harika kılan temel özelliklerden birini de korumalıyız: kalıcılık. Bir NFT'yi, bir işlem çağrısı verisi içindeki bir aşk mektubunu veya 1 milyon dolarlık bir akıllı sözleşmeyi zincire koyabilir, on yıl boyunca bir mağaraya girebilir ve çıktığınızda onun hâlâ orada sizi okumayı ve etkileşimde bulunmayı beklediğini görebilirsiniz. DApp'lerin tamamen merkeziyetsiz bir şekilde güvenle hareket edebilmesi ve güncelleme anahtarlarını silmesi için, bağımlılıklarının kendilerini yok etmeden güncellenmeyeceğinden emin olmaları gerekir - özellikle L1'in kendisi.

Eğer kararlı bir şekilde bu iki ihtiyaç arasında bir denge kurar ve sürekliliği korurken aşırı yük, karmaşıklık ve gerilemeyi en aza indirmeyi veya tersine çevirmeyi başarabilirsek, bu kesinlikle mümkündür. Organizma bunu yapabilir: Çoğu organizma zamanla yaşlansa da, şanslı birkaç tanesi bu duruma maruz kalmaz. Hatta sosyal sistemler de çok uzun bir ömre sahip olabilir. Bazı durumlarda, Ethereum başarılı olmuştur: İş kanıtı ortadan kalktı, SELFDESTRUCT opcode'un büyük bir kısmı kayboldu, beacon chain düğümleri en fazla altı ay boyunca eski verileri saklayabiliyor. 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ği açısından nihai bir zorluktur.

The Purge: Ana hedef.

Her bir düğümün tüm tarihsel kayıtları veya nihai durumu kalıcı olarak depolama gereğini azaltarak veya ortadan kaldırarak istemci depolama gereksinimlerini azaltmak.

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

Makale dizini:

Tarih sona erdi (历史记录到期)

Durum süresi doldu

Özellik temizleme

Tarih sonu

Hangi sorunu çözüyor?

Bu makalenin yazıldığı tarih itibarıyla, tam senkronize bir Ethereum düğümünün çalıştırılması için yaklaşık 1.1 TB disk alanına ihtiyaç vardır; ayrıca konsensüs istemcisi için de yüzlerce GB disk alanı gereklidir. Bunun büyük bir kısmı geçmişe aittir: geçmiş bloklara, işlemlere ve makbuzlara dair veriler, çoğu yıllardır mevcuttur. Bu, Gas sınırı 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?

Tarihsel depolama sorununun bir anahtarı, her bloğun bir hash bağlantısı (ve diğer yapılar) aracılığıyla bir önceki bloğa işaret etmesi nedeniyle, mevcut konsensüs için geçmişte bir 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 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, tarih kayıtlarını nasıl depolayacağımız konusunda birçok seçenek sunuyor. Doğal bir seçim, her 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ışma biçimidir: ağ toplamda milyonlarca dosya depolayıp dağıtsa da, her katılımcı yalnızca bunlardan birkaçını depolayıp dağıtır. Belki de sezginin aksine, bu yöntem verilerin sağlamlığını mutlaka azaltmaz. Eğer düğümlerin daha ekonomik çalışmasını sağlarsak, her bir düğümün rastgele %10 tarih kaydını depoladığı 100.000 düğümlü bir ağ kurabiliriz; bu durumda her veri 10.000 kez kopyalanacaktır - bu da her birinin her şeyi depoladığı 10.000 düğümlü ağ ile aynı 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 blokları (yani, hisse kanıtı konsensüsü ile ilgili kısımlar) 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ık bir ağ şeklinde depolanacağı bir eşler arası ağ oluşturmaktı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ı uygulanmış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 yerleştirmektir.

Mevcut araştırmalarla hangi bağlantılar var?

EIP-4444；

Torrents ve EIP-4444；

Portal Ağı;

Portal ağı ve EIP-4444;

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

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

Ne yapmamız gerekiyor, neyi dengelememiz gerekiyor?

Kalan ana işler, geçmişi depolamak için belirli bir dağıtık çözüm inşa etmek ve entegre etmekten oluşmaktadır------en azından yürütme geçmişi, 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'a özgü Portal ağı olarak adlandırılan bir çözümü de tanıtmaktı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ü versiyonuna ihtiyaç duyar. Bu nedenle, tüm istemciler için aynı anda etkinleştirilmesi değerlidir; aksi takdirde, diğer düğümlere bağlanma beklentisiyle tam geçmişi indirmeye çalışan istemcilerin başarısız olma riski vardır.

Ana denge, "eski" tarih verilerini sağlamaya yönelik çabalarımızı nasıl yönettiğimizle 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 kopyalama için güvenmektir. 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, öncelikle dağıtık bir şekilde tarih verilerini depolamak için bir torrent ağı inşa etmek ve entegre etmektir. Burada, "ne kadar çaba harcıyoruz"nun iki boyutu vardır:

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

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

(1) için aşırı bir takıntılı yaklaşım, yönetilen kanıtı içerecektir: aslında her hisse kanıtı doğrulayıcısının belirli bir oranında tarihsel kayıt saklamasını ve bunu düzenli olarak şifreli bir şekilde kontrol etmesini gerektirir. Daha ılımlı bir yaklaşım, her istemci için saklanan tarihsel yüzdelik için gönüllü bir standart belirlemektir.

(2) için temel uygulama, bugün tamamlanan çalışmaları içermektedir: Portal, tüm Ethereum tarihini içeren ERA dosyasını zaten depoladı. Daha kapsamlı bir uygulama, bunu senkronizasyon sürecine bağlamayı içerecektir; böylece, eğer biri tam tarih kaydı depolama 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 bunu gerçekleştirebilirler.

Diğer yol haritası bölümleriyle nasıl etkileşimde bulunur?

Eğer düğümlerin çalıştırılmasını veya başlatılmasını son derece kolay hale getirmek istiyorsak, geçmiş depolama gereksinimlerini azaltmanın, durumsuzluktan daha önemli olduğunu söyleyebiliriz: Düğümün ihtiyaç duyduğu 1.1 TB'lık alanın yaklaşık 300 GB'ı durum, geri kalan yaklaşık 800 GB'ı ise geçmiş olmuştur. Durumsuzluk ve EIP-4444'ün gerçekleştirilmesiyle, akıllı saatlerde Ethereum düğümü çalıştırma ve yalnızca birkaç dakikada kurma vizyonunu gerçekleştirmek mümkündür.

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, bu da onları daha basit hale getiriyor. Örneğin, 2016 yılındaki DoS saldırısı sırasında oluşturulan boş depolama alanlarının tamamı silindiği için artık güvenli bir şekilde birçok kod satırı silinebilir. Hisse kanıtına geçiş tarih olmuşken, müşteriler iş kanıtı ile ilgili tüm kodları güvenle silebilir.

Devlet süresi

Hangi sorunu çözüyor?

Müşterinin depolama geçmişi gereksinimini ortadan kaldırmış olsak bile, müşterinin depolama ihtiyacı her yıl yaklaşık 50 GB artmaya devam edecek çünkü durum sürekli büyümekte: hesap bakiyeleri ve rasgele sayılar, sözleşme kodları ve sözleşme depolaması. Kullanıcılar, mevcut ve gelecekteki Ethereum müşterilerine kalıcı bir yük getirmek için tek seferlik bir ücret ödeyebilirler.

Durum, tarihten daha zor bir şekilde "sona erer", çünkü EVM esasen şöyle bir 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 tanıtırsak, bazıları bu sorunun o kadar da kötü olmadığını düşünebilir: yalnızca özel blok oluşturucu sınıflarının gerçekten durumu saklaması gerekirken, diğer tüm düğümler (hatta liste oluşturmaları içerenler!) durumsuz çalışabilir. Ancak, durumsuzluğa aşırı bağımlı olmak istemediğimiz görüşü de var; nihayetinde durumu sona erdirmek, Ethereum'un merkeziyetsizliğini korumak için isteyebileceğimiz bir şey olabilir.

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

Bugün, yeni bir durum nesnesi oluşturduğunuzda (bu aşağıdaki üç şekilde olabilir: (i) yeni bir hesaba ETH göndermek, (ii) kod kullanarak yeni bir hesap oluşturmak, (iii) daha önce dokunulmamış bir depolama slotu ayarlamak), bu durum nesnesi bu durumda sonsuza kadar kalır. Aksine, istediğimiz şey nesnenin zamanla otomatik olarak süresinin dolmasıdır. Ana zorluk, bunu üç hedefi gerçekleştirecek şekilde yapmaktır:

Verimlilik: Vade sürecini çalıştırmak 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şimlerini kaybetmemelidir...

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

Bu hedeflere ulaşamamak sorunları kolayca çözebilir. Örneğin, her durum nesnesinin bir son tarih sayacı da saklamasını sağlayabilirsiniz (son tarihi uzatmak için ETH yakılarak bu, herhangi bir zamanda okunduğunda veya yazıldığında otomatik olarak gerçekleşebilir) ve süresi dolmuş tarihleri silmek için durumları döngüyle kontrol eden bir süreç oluşturabilirsiniz. Ancak bu ek hesaplama (hatta depolama gereksinimi) getirmekte ve kullanıcı dostu olma gereksinimlerini kesinlikle karşılayamaz. Geliştiricilerin, depolama değerlerinin bazen sıfıra sıfırlanmasıyla ilgili kenar durumlarını anlaması da zordur. Sözleşme kapsamına 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ştiriciler, sürekli depolama maliyetlerini "kullanıcılara aktarmayı" düşünmek zorundadır.

Bunlar, Ethereum çekirdek geliştirme topluluğunun yıllardır çözmeye çalıştığı sorunlardır. "Blok zinciri kira" ve "yeniden üretim" gibi önerileri de içermektedir. Sonunda, önerilerin en iyi kısımlarını birleştirdik ve iki tür "bilinen en kötü olmayan çözümler" üzerine odaklandık:

• Kısmi durum geçerlilik süresi çözümleri
• Adres döngüsüne dayalı durum süresi önerisi.

Kısmi durum süresi dolması

Bazı durum sona erme teklifleri aynı prensiplere uyar. Durumları bloklara ayırıyoruz. Herkes "üst düzey harita"yı kalıcı olarak saklar; burada bloklar boş veya dolu olabilir. Veriler yalnızca o bloktaki verilere en son erişildiğinde saklanır. Artık saklanmıyorsa, bir "diriltme" mekanizması vardır.

Bu öneriler arasındaki temel fark şudur: (i) Biz şöyle