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

Geçmiş veriler: Tarihsel olarak 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 indirilerek ağa tamamen senkronize edilmelidir. Bu, istemci yükünü ve senkronizasyon süresini zamanla sürekli artırır, 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şı baskı uygulamamız gerekiyor, zamanla karmaşıklığı ve genişlemeyi azaltmalıyız. Ancak aynı zamanda, blok zincirini harika kılan temel özelliklerden birini: kalıcılığı korumamız gerekiyor. 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ğaraya girip çıktığınızda, hala orada sizi okumak ve etkileşimde bulunmak için beklediğini görebilirsiniz. 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 edici bir şekilde güncellenmeyeceğinden emin olmaları gerekir - özellikle L1'in kendisi.

Eğer kararlıysak, bu iki ihtiyaç arasında bir denge kurmak ve sürekliliği korurken aşırı yük, karmaşıklık ve gerilemeyi en aza indirmek veya tersine çevirmek kesinlikle mümkündür. Organizmalarda bunu başarmak mümkündür: Çoğu organizma zamanla yaşlansa da, şanslı azınlıklar bunu yapamaz. Sosyal sistemler bile çok uzun ömürlü olabilir. Bazı durumlarda, Ethereum başarı elde etmiştir: İş kanıtı kayboldu, SELFDESTRUCT opcode'ları büyük ölçüde ortadan kalktı, beacon chain düğümleri en fazla altı aylık eski verileri depoladı. Ethereum'a daha genel bir şekilde bu yolu 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 için nihai bir meydan okumadır.

The Purge: Ana hedef.

İstemci depolama gereksinimlerini azaltmak için her bir düğümün tüm geçmiş kayıtları 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:

Tarih sona erme（历史记录到期）

Durum süresi doldu

Özellik temizliği

Geçmiş süresi

Hangi sorunu çözüyor?

Bu makalenin yazıldığı tarih itibarıyla, 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ı gerekmektedir. Bunun büyük bir kısmı geçmişe aittir: geçmiş bloklar, işlemler ve makbuzlarla ilgili veriler, bunların çoğu yıllar öncesine aittir. Bu, Gas sınırlaması 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 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 konsensüs sağlamak için tarihsel 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 sunulabilir ve bu kanıt, başkalarının 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 saklayabileceğimiz 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ı sakladığı bir ağdır. İşte tohum ağı bu şekilde on yıllardır çalışıyor: ağ toplamda milyonlarca dosyayı saklayıp dağıtsa da, her bir katılımcı yalnızca birkaç dosyayı saklayıp dağıtıyor. Belki de sezgisel olarak tersine, bu yöntem verilerin sağlamlığını azaltmak zorunda değil. Düğümlerin çalışmasını daha ekonomik hale getirerek, her bir düğümün rastgele %10'luk tarih kaydını sakladığı 100.000 düğümlü bir ağ oluşturabiliriz, böylece her veri 10.000 kez kopyalanmış olur - tamamen 10.000 düğümlü bir ağın kopyalama faktörü ile aynı - her bir düğüm her şeyi saklar.

Bugün, Ethereum artık tüm düğümlerin tüm geçmişi kalıcı olarak depoladığı modelden kurtulmaya başladı. Konsensüs blokları (yani, hisse ispatı 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 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 saklandığı 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ı kullanmıştır. En basit çözüm, muhtemelen bu tür Erasure kodlarını yeniden kullanmak ve yürütme ve konsensüs blok verilerini de blob içine koymaktır.

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

EIP-4444；

Torrents ve EIP-4444；

Portallar Ağı;

Portallar Ağı ve EIP-4444;

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

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

Ne yapılması gerekiyor, neyi dengelemeniz gerekiyor?

Kalan ana iş, tarihleri depolamak için somut bir dağıtık çözüm inşa etmek ve entegre etmeyi içeriyor------en azından yürütme tarihleri, ancak nihayetinde uzlaşma ve blob da dahil. En basit çözüm, (i) mevcut torrent kütüphanesini basitçe tanıtmaktır; ayrıca (ii) Ethereum'a özgü Portal ağı olarak adlandırılan bir çözüm. Bunlardan herhangi biri tanıtıldığında, EIP-4444'ü açabiliriz. EIP-4444'ün kendisi sert bir hard fork gerektirmiyor, ancak yeni bir ağ protokolü sürümüne ihtiyaç duyuyor. Bu nedenle, tüm istemciler için aynı anda etkinleştirmek değerlidir; aksi takdirde, istemcilerin diğer düğümlere bağlanarak tam tarihleri indirmeyi beklemesi ancak aslında bunu elde edememesi nedeniyle başarısız olma riski vardır.

Ana denge, "eski" tarih verilerini sağlama çabamı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ı bir kayıt yeri olarak konumunu zayıflatır. Daha zor ama daha güvenli bir yol, öncelikle tarihi verileri dağıtılmış bir şekilde depolamak için torrent ağını inşa edip entegre etmektir. Burada, "ne kadar çaba sarf ediyoruz" iki boyut vardır:

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

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

(1) için aşırı bir takıntılı yaklaşım, güvence kanıtını içerecektir: aslında her bir teminat kanıtı doğrulayıcısının belirli bir oranını tarihsel kayıtları saklamasını ve bunları düzenli olarak şifreli bir şekilde kontrol etmesini şart koşmaktadır. Daha ılımlı bir yaklaşım, her istemcinin sakladığı tarihsel yüzdelik 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, bunu senkronizasyon sürecine bağlamakla ilgili olacaktır; böylece, eğer birisi 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ğından bunu gerçekleştirebilir.

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

Eğer düğümlerin çalıştırılmasını veya başlatılmasını son derece kolay hale getirmek istiyorsak, tarihsel depolama gereksinimlerini azaltmak, durumsuz olmaktan 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 tarihe aittir. Sadece durumsuzluk ve EIP-4444'ün gerçekleştirilmesi, akıllı saatlerde Ethereum düğümünü çalıştırma ve sadece birkaç dakikada kurulumunu sağlama vizyonunu gerçekleştirebilir.

Geçmiş depolamanın kısıtlanması, daha yeni Ethereum düğümlerinin daha uygulanabilir hale gelmesini sağlar, yalnızca protokolün en son sürümünü destekler, bu da onları daha basit hale getirir. Örneğin, 2016'daki DoS saldırısı sırasında oluşturulan boş depolama yuvalarının tamamen silinmiş olması nedeniyle şimdi birçok kod satırını güvenle silebilirsiniz. Hisse kanıtına geçiş artık tarih olduğuna göre, müşteriler iş kanıtı ile ilgili tüm kodları güvenle kaldırabilir.

Eyalet süresi doldu

Hangi sorunu çözüyor?

Müşterinin depolama geçmişini ortadan kaldırsak bile, her yıl yaklaşık 50 GB kadar artan depolama ihtiyacı devam edecektir, çünkü durum sürekli olarak büyümektedir: hesap bakiyeleri ve rasgele sayılar, sözleşme kodları ve sözleşme depolama. 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 "sona erer", çü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 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 durumu gerçekten depolaması gerekirken, diğer tüm düğümler (hatta liste oluşturmayı 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 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 erişilmemiş bir depolama slotu ayarlamak), bu durum nesnesi o durumda sonsuza dek kalır. Aksine, istediğimiz şey, nesnelerin zamanla otomatik olarak süresinin dolmasıdır. Temel zorluk, bunu üç hedefe ulaşacak şekilde gerçekleştirmektir:

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

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

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

Bu hedefleri karşılamamak sorunları çözmeyi kolaylaştırır. Örneğin, her durum nesnesinin bir de süresi dolma tarihi sayacı saklamasını sağlayabilirsiniz (süresi dolma tarihini uzatmak için ETH yakarak, bu her an okuma veya yazma sırasında otomatik olarak gerçekleşebilir) ve süresi dolmuş tarihlerin durum nesnelerini silmek için bir döngü oluşturabilirsiniz. Ancak, bu ek hesaplama (hatta depolama gereksinimleri) getirir ve kesinlikle kullanıcı dostu olma gereksinimlerini karşılayamaz. Geliştiriciler, bazen sıfıra sıfırlanan depolama değerleri ile ilgili kenar durumlarını çıkarmakta da zorluk çekiyor. Eğer sözleşme kapsamı içinde bir süresi dolma 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ıya nasıl "aktaracaklarını" düşünmek zorundadır.

Bunlar, Ethereum çekirdek geliştirici topluluğunun yıllardır çözmeye çalıştığı sorunlardır; "blok zinciri kirası" ve "yeniden doğuş" gibi öneriler de dahil. Nihayetinde, önerilerin en iyi kısımlarını bir araya getirdik ve iki tür "bilinen en kötü olmayan çözümler" üzerine yoğunlaştı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ı durum süresi dolmuş teklifler aynı ilkelere uyar. Durumları parçalara ayırıyoruz. Herkes "üst düzey harita"yı kalıcı olarak depolar, burada parçalar boş veya dolu olabilir. Her bir parçadaki veriler yalnızca bu verilere en son erişildiğinde depolanır. Artık depolanmadığında bir "diriltme" mekanizması vardır.

Bu tekliflerin arasındaki temel fark şudur: (i) "son zamanlarda" terimini nasıl tanımlıyoruz,