Ethereum'in 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 artmasıdır. Bu, iki şekilde gerçekleşir:

Tarih verileri: Tarih boyunca herhangi bir zamanda gerçekleştirilen herhangi bir işlem ve oluşturulan herhangi bir hesabın tüm istemciler tarafından kalıcı olarak saklanması ve yeni istemciler tarafından indirilmesi gerekmektedir, böylece tamamen ağa senkronize edilir. Bu, istemci yükünü ve senkronizasyon süresini zamanla artırır, zincirin kapasitesi sabit kalsa bile.

Protokol fonksiyonu: Yeni özellikler eklemek, eski özellikleri 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 ters etki uygulamamız gerekiyor, zamanla karmaşıklığı ve genişlemeyi azaltmalıyız. Ancak, aynı zamanda blok zincirini harika kılan anahtar özelliklerden birini de korumalıyız: kalıcılık. Bir NFT, bir işlem çağrısı verisindeki bir aşk mektubu veya 1 milyon dolarlık bir akıllı sözleşmeyi zincire koyabilirsiniz, on yıl bir mağarada kalıp çıktığınızda, hala okumanız ve etkileşimde bulunmanız için orada beklediğini görebilirsiniz. DApp'lerin tamamen merkeziyetsiz hale gelmelerini sağlamak ve yükseltme anahtarlarını kaldırmak için, bağımlılıklarının kendilerini yok edecek şekilde yükselmeyeceğinden emin olmaları gerekiyor - özellikle 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şlansa da, şanslı azınlık bunu başaramaz. Sosyal sistemler bile çok uzun bir ömre sahip olabilir. Bazı durumlarda, Ethereum başarı elde etmiştir: İş kanıtı ortadan kalktı, SELFDESTRUCT opcode’unun çoğu kayboldu ve beacon zinciri 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ği, teknik sürdürülebilirliği 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ı veya nihai durumu kalıcı olarak saklama gereksinimini azaltarak veya ortadan kaldırarak düşürmek.

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

Makale Dizini:

Geçmiş süresi doldu (历史记录到期)

Durum süresi doldu

Özellik temizliği

Tarih sonu

Hangi problemi çözüyor?

Bu makale yazılırken, tamamen senkronize bir Ethereum düğümünün istemciyi çalıştırmak için yaklaşık 1.1TB disk alanına ihtiyacı vardır, ayrıca konsensüs istemcisi için yüzlerce GB disk alanı gereklidir. Bunun büyük bir kısmı tarihe aittir: Tarihsel bloklar, işlemler ve makbuzlarla ilgili veriler, bunların büyük bir kısmı yıllardır mevcuttur. Bu, Gas sınırları 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 temel bir basitleştirilmiş özelliği, her blokun hash bağlantısı (ve diğer yapılar) aracılığıyla bir önceki bloğa işaret etmesi nedeniyle, mevcut konsensüse ulaşmanın tarihsel konsensüse ulaşmak için yeterli olmasıdır. Ağ, en son blok üzerinde bir konsensüse ulaştığı sürece, herhangi bir tarihsel blok veya işlem veya durum (hesap bakiyesi, rastgele sayı, kod, depolama) herhangi bir tek katılımcı tarafından sağlanabilir ve Merkle kanıtı ile desteklenebilir 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 sağlıyor. 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 onlarca yıl boyunca çalıştığı yoldur: 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 sezgiyle ters orantılı olarak, bu yöntem verilerin sağlamlığını bile azaltmayabilir. Düğümlerin çalışmasını daha ekonomik hale getirerek, her düğümün rastgele %10'luk bir tarih kaydını depoladığı 100,000 düğümlük bir ağ kurabiliriz; bu durumda her veri 10,000 kez kopyalanır - bu, her düğümün her şeyi depoladığı 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, tarih 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 ve ardından eski verileri dağıtık bir ağ biçiminde depolayan bir Ethereum düğümünden oluşan bir eşler arası ağ kurarak tek bir dönem oluşturmaktır.

Erasure kodları, çoğaltma faktörünü aynı tutarken sağlamlığı artırmak için kullanılabilir. Aslında, Blob veri kullanılabilirliği örneklemeyi desteklemek için hata düzeltme kodlarıyla 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ılar var?

EIP-4444；

Torrentler ve EIP-4444；

Kapı Ağı;

Portal Ağı ve EIP-4444;

Portal'daki SSZ nesnelerinin dağıtık depolama ve alma işlemi;

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

Ne yapılması gerekiyor, neyi dengelememiz gerekiyor?

Kalan ana iş, geçmişi depolamak için somut 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 uzlaşma ve blob'u da içermektedir. En basit çözüm, (i) mevcut torrent kütüphanesini tanıtmaktır ve (ii) Ethereum'un yerel çözümü olan Portal ağıdır. Bunlardan herhangi biri tanıtıldığında, EIP-4444'ü açabiliriz. EIP-4444'ün kendisi sert bir çatal gerektirmemektedir, ancak yeni bir ağ protokolü sürümü gerekmektedir. Bu nedenle, tüm istemciler için aynı anda etkinleştirmek değerlidir, aksi takdirde diğer nodlara bağlanarak tam geçmişi indirmek bekleyen istemcilerin aslında almadıkları için hata verme riski vardır.

Ana denge, "eski" tarih verilerini sunma çabamızla ilgilidir. En basit çözüm, yarın eski tarihi depolamayı durdurmak ve mevcut arşiv düğümleri ile çeşitli merkezi sağlayıcılara bağımlı kalmaktır. Bu kolaydır, ancak bu durum 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, böylece tarih kayıtlarını dağıtık bir şekilde depolamaktır. Burada, "ne kadar çaba sarf ettiğimiz" iki boyuta sahiptir:

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

Protokole entegre ettiğimiz tarihsel depolama derinliği ne kadar derin?

(1) için aşırı bir takıntılı yaklaşım, bir saklama kanıtı gerektirecektir: aslında her staking doğrulayıcısının belirli bir oranda geçmiş kayıtları saklamasını ve düzenli olarak bunları şifreli bir şekilde kontrol etmesini talep eder. Daha ılımlı bir yaklaşım, her istemci tarafından saklanan tarihsel yüzdelere gönüllü bir standart belirlemektir.

(2) için, temel uygulama yalnızca 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ı gerektirecektir; böylece, eğer birisi tam tarih kayıtlarını depolayan bir düğümü 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?

Düğümlerin çalıştırılması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ş olmuştur. Sadece durumsuzluk ve EIP-4444'ün gerçekleştirilmesi, akıllı saatlerde Ethereum düğümlerinin çalıştırılabilmesi ve sadece birkaç dakika içinde kurulabilmesi vizyonunu gerçekleştirebilir.

Geçmiş depolamanın kısıtlanması, daha yeni Ethereum düğümlerinin uygulanmasını daha mümkün kı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 tamamı silindiği için birçok kod satırını güvenli bir şekilde kaldırmak mümkün. Hemen hemen, hisse kanıtına geçiş tarihe karıştığında, kullanıcılar çalışma kanıtı ile ilgili tüm kodları güvenle silebilir.

Devletin sona ermesi

Hangi problemi çözüyor?

Müşteri tarafında geçmiş kayıtları saklama gereğini ortadan kaldırmış olsak bile, müşteri depolama ihtiyaçları yılda yaklaşık 50 GB büyümeye devam edecek, çünkü durum sürekli artmaktadır: hesap bakiyeleri ve rastgele sayılar, sözleşme kodları ve sözleşme depolamaları. Kullanıcılar, mevcut ve gelecekteki Ethereum müşterilerine sonsuza dek yük getirecek tek seferlik bir ücret ödeyebilirler.

"Durumlar, tarihsel olarak daha zor 'sona ermek' çünkü EVM esasen şu 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 zaman okunabilir. Eğer durumdan bağımsızlık getirirsek, bazıları bu sorunun o kadar kötü olmadığını düşünebilir: Sadece özel blok inşaatı sınıflarının durumu gerçek anlamda depolaması gerekirken, diğer tüm düğümler (hatta liste oluşturmayı da içeren!) durumsuz çalışabilir. Ancak, aşırı derecede durumsuzluğa güvenmek istemediğimiz görüşü var; nihayetinde durumu sona erdirmek isteyebiliriz, böylece Ethereum'un merkezsizlik ilkesini koruyabiliriz.

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

Bugün, yeni bir durum nesnesi oluşturduğunuzda (bu, şu üç yöntemden biriyle gerçekleşebilir: (i) ETH'yi yeni bir hesaba göndermek, (ii) kod kullanarak yeni bir hesap oluşturmak, (iii) daha önce kullanılmamış bir depolama alanı ayarlamak), bu durum nesnesi o durumda sonsuza dek kalır. Aksine, istediğimiz şey nesnelerin zamanla otomatik olarak süresinin dolmasıdır. Anahtar 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 olma: Eğer biri beş yıl boyunca bir mağarada kalır ve 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ı ve güncellenmeyen uygulamaların normal şekilde çalışmaya devam etmesi gerekmektedir.

Bu hedeflere ulaşmamak sorunları kolayca çözebilir. Örneğin, her durum nesnesinin bir geçerlilik süresi sayacı da saklamasını sağlayabilirsiniz (bu, geçerlilik süresini uzatmak için ETH yakılarak yapılabilir ve bu, her okuma veya yazma esnasında otomatik olarak gerçekleşebilir) ve geçerlilik süresi dolmuş durum nesnelerini silmek için durumları döngü ile geçiren bir süreç oluşturabilirsiniz. Ancak bu, ek hesaplama (hatta depolama ihtiyacı) getirir ve kesinlikle kullanıcı dostu olma gereksinimlerini karşılayamaz. Geliştiricilerin, depolama değerlerinin bazen sıfıra sıfırlanmasını içeren kenar durumlarını anlaması da zordur. Eğer sözleşme kapsamına bir geçerlilik süresi sayacı koyarsanız, bu teknik olarak geliştiricilerin işini kolaylaştırır, ancak ekonomiyi daha karmaşık hale getirir: geliştiricilerin sürekli depolama maliyetlerini "kullanıcılara yansıtma" yollarını düşünmesi gerekir.

Bunlar, Ethereum çekirdek geliştirici topluluğunun yıllardır çözmeye çalıştığı sorunlardır; "blok zinciri kiralama" ve "yenilenme" gibi önerileri içermektedir. Sonunda, önerilerin en iyi kısımlarını bir araya getirdik ve "bilinen en kötü çözümler" olarak iki kategoriye 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 önerileri aynı ilkelere uyar. Durumları bloklara ayırıyoruz. Herkes "üst düzey haritalama"yı kalıcı olarak saklar, burada bloklar boş veya dolu olabilir. Her bloktaki veriler yalnızca veriye en son erişildiğinde saklanır. Artık saklanmıyorsa bir "yeniden canlandırma" mekanizması vardır.

Bu öneriler arasındaki ana farklar şunlardır: (i) "son"u nasıl tanımladığımız ve (ii) nasıl