Ethereum'un Olası Geleceği: The Purge

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 artacak olmasıdır. Bu iki yerde gerçekleşir:

• Tarih verileri: Tarih boyunca herhangi bir zamanda yapılan her işlem ve oluşturulan her hesap, tüm istemciler tarafından kalıcı olarak saklanmalı ve herhangi bir yeni istemci tarafından indirilmelidir, böylece ağa tamamen senkronize olunmalıdır. Bu, istemci yükünü ve senkronizasyon süresini zamanla artıracak, 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'ın uzun vadede sürdürülebilir olabilmesi için bu iki eğilime güçlü bir karşı baskı uygulamamız gerekiyor; zamanla karmaşıklığı ve genişlemeyi azaltmalıyız. Ancak aynı zamanda, blok zincirini muhteşem kılan temel özelliklerden birini de korumalıyız: kalıcılık. Bir NFT, bir ticaret çağrısındaki aşk mektubu veya üzerinde 1.000.000 dolar bulunan bir akıllı sözleşmeyi zincire koyabilirsiniz, on yıl boyunca bir mağaraya girebilir ve sonra geri döndüğünüzde onun hala orada sizi okumak ve etkileşimde bulunmak için beklediğini görebilirsiniz. DApp'lerin tamamen merkeziyetsiz hale gelmesi ve güncelleme anahtarını kaldırması 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 kurmak ve sürekliliği korurken şişkinliği, karmaşıklığı ve gerilemeyi en aza indirmek veya tersine çevirmek kesinlikle mümkündür. Organizmalar bunu yapabilir: Çoğu organizma zamanla yaşlanırken, şanslı olan birkaçı bunu başaramaz. Hatta sosyal sistemler de çok uzun bir ömre sahip olabilir. Bazı durumlarda, Ethereum başarılı olmuştur: İş kanıtı ortadan kalktı, SELFDESTRUCT opcode'unun büyük bir kısmı 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ğinin, teknik sürdürülebilirliğinin ve hatta güvenliğinin nihai zorluğudur.

The Purge: Ana hedef.

• İstemci depolama gereksinimlerini, her düğümün tüm geçmiş kayıtlarını hatta nihai durumu kalıcı olarak saklama ihtiyacını azaltarak veya ortadan kaldırarak azaltın.

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

Makale İçeriği:

• Tarih sona erdi
• Durum süresi doldu
• Özellik temizliği

Tarih sona erme

hangi sorunu çözüyor?

Bu makalenin yazıldığı tarihte, tam 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ı gereklidir. Bunun büyük bir kısmı tarihe aittir: geçmiş bloklar, işlemler ve makbuzlar ile ilgili veriler, çoğu yıllardır mevcuttur. Bu, Gas limitleri hiç artmasa bile, düğümün boyutunun her yıl yüzlerce GB artmaya devam edeceği anlamına gelir.

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

Tarihsel depolama sorunlarının 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 uzlaşmanın yeterli olmasıdır. Ağ, en son blok üzerinde uzlaşmaya vardığı sürece, herhangi bir tarihsel blok, 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; bu kanıt, diğer herkesin doğruluğunu doğrulamasına olanak tanır. Uzlaşma 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ıştığı şekilde: ağ toplamda milyonlarca dosya depolar ve dağıtırken, her bir katılımcı yalnızca bunlardan birkaç dosya depolar ve dağıtır. Belki de sezgimizin tersine, bu yaklaşım veri dayanıklılığını bile azaltmak zorunda değildir. Düğümlerin çalıştırılmasını daha ekonomik hale getirerek, her düğümün rastgele %10'luk tarih kaydını depoladığı 100.000 düğümlü bir ağ kurabiliriz, bu durumda her bir veri 10.000 kez kopyalanacaktır - bu, her düğümün her şeyi depoladığı 10.000 düğümlü ağın kopyalama faktörüyle tam olarak 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ımlar) yalnızca yaklaşık 6 ay depolanır. Blob yalnızca yaklaşık 18 gün depolanır. EIP-4444, tarihi 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çeriği depolamakla sorumlu olduğu bir dönemi (muhtemelen yaklaşık 18 gün) oluşturmak 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ğ oluşturmaktır.

Erasure kodları, çoğaltma 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ı uygulamıştı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.

ile mevcut araştırmalar arasında ne tür bağlantılar var?

• EIP-4444；
• Torrentler ve EIP-4444;
• Portal Ağı;
• Portal ağı ve EIP-4444;
• Portal'daki SSZ nesnelerinin dağıtık depolama ve sorgulama;
• Gas limitini nasıl artırabilirim (Paradigm).

ayrıca ne yapmam gerekiyor, neyi dengelemem gerekiyor?

Kalan ana iş, geçmişi depolamak için belirli bir dağıtık çözüm inşa etmek ve entegre etmek, en azından yürütme geçmişi, ancak nihayetinde konsensüs ve blob'u da içermektedir. En basit çözüm, mevcut torrent kütüphanesini (i) basitçe tanıtmak ve (ii) Portal ağı olarak adlandırılan Ethereum yerel çözümüdür. 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, bunu tüm istemciler için aynı anda etkinleştirmek değerlidir, aksi takdirde istemcinin başka bir düğüme bağlanması durumunda tam geçmişi indirmeyi bekleyip aslında almadığı için çökme riski vardır.

Ana denge, "eski" tarih verilerini sağlamaya nasıl çabaladığımızla ilgilidir. En basit çözüm, yarın eski tarihi depolamayı durdurmak ve mevcut arşiv düğümlerine ve çeşitli merkezi sağlayıcılara dayanarak kopyalamaktır. Bu kolaydır ama Ethereum'un kalıcı bir 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 çabalıyoruz" iki boyuta sahiptir:

1. En büyük düğüm kümesinin gerçekten tüm verileri depoladığından nasıl emin olmaya çalışıyoruz?

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

(1) için aşırı bir takıntılı yaklaşım, doğrulama kanıtı içerecektir: aslında her doğrulama kanıtı doğrulayıcısının belirli bir oranında geçmiş kayıtları saklamasını ve bunları düzenli olarak şifreli bir şekilde kontrol etmesini talep etmektedir. Daha ılımlı bir yaklaşım ise her istemcinin sakladığı geçmişin 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, bunun senkronizasyon sürecine gerçek bir şekilde bağlanmasını gerektirecektir, böylece biri, diğer arşiv düğümleri çevrimiçi olmasa bile, tam tarih depolama düğümünü veya arşiv düğümünü senkronize etmek isterse, doğrudan senkronizasyonla Portal ağı üzerinden bunu gerçekleştirebilir.

Diğer yol haritası bölümleriyle nasıl etkileş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 içinde yaklaşık 300 GB durum, geri kalan yaklaşık 800 GB ise geçmişte kalmıştır. Sadece durumsuzluğun sağlanması ve EIP-4444 ile, akıllı saatlerde Ethereum düğümünün çalıştırılmasını ve yalnızca birkaç dakikada ayarlanmasını sağlayacak vizyon gerçeğe dönüşebilir.

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ü destekliyor, bu da onları daha basit hale getiriyor. Örneğin, artık 2016'daki DoS saldırısı sırasında oluşturulan boş depolama alanlarının tamamen silinmesi nedeniyle birçok kod satırını güvenle kaldırmak mümkün. Hisse kanıtına geçiş tarih haline geldiğinden, kullanıcılar iş kanıtıyla ilgili tüm kodları güvenle kaldırabilirler.

Durum süresi

hangi sorunu çözüyor?

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

Durum, tarihten daha zor "sona ermek"tir, çünkü EVM esasen böyle bir varsayım etrafında tasarlanmıştır: Bir durum nesnesi oluşturulduğunda, daima var olacak ve herhangi bir işlem tarafından her an okunabilecektir. Eğer durumsuzluğu devreye alırsak, bazıları bu sorunun belki de o kadar kötü olmadığını düşünüyor: Sadece özel blok oluşturucu sınıflarının durumu gerçek bir şekilde saklaması gerekiyor, diğer tüm düğümler (hatta liste oluşturmayı içerenler bile!) durumsuz çalışabilir. Bununla birlikte, aşırı derecede durumsuzluğa bağımlı olmak istemediğimiz yönünde bir görüş var; nihayetinde, Ethereum'un merkeziyetsizliğini korumak için durumu sona erdirmek 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 hiç dokunulmamış bir depolama slotu ayarlamak), bu durum nesnesi o durumda sonsuza dek kalır. Bunun yerine, istediğimiz şey nesnenin zamanla otomatik olarak süresinin dolmasıdır. Ana zorluk, bunu üç hedefi gerçekleştirecek şekilde yapmaktır:

1. Verimlilik: Vade sürecini yürütmek için büyük miktarda ek hesaplama gerektirmez.

2. Kullanıcı dostu olma durumu: Eğer biri beş yıl boyunca mağaraya girip geri dönerse, ETH, ERC20, NFT, CDP pozisyonlarına erişim hakkını kaybetmemelidir...

3. Geliştirici dostu olma: 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 gerekiyor.

Bu hedeflere ulaşılmadığında sorunları çözmek oldukça kolay hale gelir. Örneğin, her durum nesnesinin ayrıca bir son kullanma tarihi sayacı saklamasını sağlayabilirsiniz (son kullanma tarihini uzatmak için ETH yakarak, bu herhangi bir zamanda okumada veya yazmada otomatik olarak gerçekleşebilir) ve son kullanma tarihlerini silen bir süreç durum nesnelerini döngü ile geçirebilirsiniz. Ancak bu, ek hesaplama (hatta depolama gereksinimleri) getirmekte ve kesinlikle kullanıcı dostu olma gereksinimlerini karşılamamaktadır. Geliştiricilerin, bazen sıfıra sıfırlanan depolama değerlerini içeren kenar durumlarını anlaması da zor olmaktadır. Sözleşme kapsamındaki bir son kullanma sayacı ayarlarsanız, bu teknik olarak geliştiricilerin yaşamını kolaylaştırır, ancak ekonomik olarak daha zor hale getirir: geliştiricilerin sürekli depolama maliyetlerini kullanıcıya nasıl "aktarmak" gerektiğini düşünmeleri 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 "bilinen en kötü olmayan çözümler" olmak üzere iki kategoriye odaklandık:

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

Kısmi durum süresi dolumu

Bazı durum süresi dolmuş teklifleri aynı ilkelere uyar. Durumu bloklara ayırıyoruz. Herkes "üst düzey haritalama"yı kalıcı olarak depolar; burada bloklar boş veya dolu olabilir. Her bloktaki veriler yalnızca bu verilere en son erişildiğinde depolanacaktır. Eğer artık depolanmıyorsa bir "yeniden canlandırma" mekanizması vardır.