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:
Geçmiş veriler: Tarih boyunca herhangi bir zamanda gerçekleştirilen herhangi bir işlem ve oluşturulan herhangi bir hesap, tüm istemciler tarafından kalıcı olarak depolanmalı ve herhangi bir yeni istemci tarafından indirilmelidir, böylece tamamen ağa senkronize edilir. Bu, istemci yükünün ve senkronizasyon süresinin zamanla artmasına neden olur, hatta 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 yol açar.
Ethereum'un uzun vadede sürdürülebilir olabilmesi için bu iki trende güçlü bir ters baskı uygulamamız gerekiyor, zamanla karmaşıklığı ve genişlemeyi azaltmalıyız. Ancak aynı zamanda, blok zincirini harika kılan temel özelliklerden birini korumamız gerekiyor: kalıcılık. Bir NFT, bir işlem çağrı verisindeki aşk mektubu veya 1 milyon dolar içeren bir akıllı sözleşmeyi zincire koyabilir, on yıl bir mağaraya girebilir ve çıktığınızda hala orada sizi beklediğini görebilirsiniz. DApp'lerin tamamen merkeziyetsiz bir şekilde rahatça hareket edebilmesi ve güncelleme anahtarlarını kaldırabilmesi için, bağımlılıklarının kendilerini yok edecek şekilde güncellenmeyeceğinden emin olmaları gerekiyor - özellikle L1'in kendisi.
Eğer kararlıyız ve bu iki talep arasında bir denge kurarak sürekliliği sağlarken aşırılığı, karmaşıklığı ve gerilemeyi en aza indirmeyi veya tersine çevirmeyi başarabiliriz, bu kesinlikle mümkündür. Organizmalar bunu yapabilir: Çoğu organizma zamanla yaşlansa da, şanslı birkaç tanesi yaşlanmaz. Sosyal sistemler de çok uzun ömürlü olabilir. Bazı durumlarda, Ethereum başarı elde etmiştir: İş kanıtı ortadan kalktı, SELFDESTRUCT opcode'unun çoğu kayboldu ve beacon chain düğümleri en fazla altı ay boyunca eski verileri depoladı. Ethereum için bu yolu daha genel bir şekilde bulmak ve uzun vadeli istikrarlı bir nihai sonuca yönelmek, Ethereum'un uzun vadeli ölçeklenebilirliği, teknik sürdürülebilirliği ve hatta güvenliği açısından nihai zorluktur.
The Purge: Ana hedef.
İstemci depolama gereksinimlerini azaltmak için her düğümün tüm geçmiş kayıtları veya hatta nihai durumu kalıcı olarak depolama gereksinimini azaltarak veya ortadan kaldırarak.
Protokolün karmaşıklığını azaltmak için gereksiz işlevleri ortadan kaldırarak.
Makale dizini:
Tarih sona erme（历史记录到期）
State expiry（状态到期）
Özellik temizliği (特征清理)
Tarih sonu
Hangi sorunu çözüyor?
Bu makale yazıldığı sırada, tamamen senkronize bir Ethereum düğümü, istemcinin çalıştırılması için yaklaşık 1.1 TB disk alanına ihtiyaç duymaktadır; ayrıca konsensüs istemcisi için yüzlerce GB disk alanına ihtiyaç vardır. Bunun büyük bir kısmı tarihe dayanıyor: Tarihsel bloklar, işlemler ve makbuzlar hakkında veriler, bunların çoğu yıllardır mevcut. Bu, Gas sınırı hiç artmasa bile, düğüm boyutunun her yıl yüzlerce GB artmaya devam edeceği anlamına geliyor.
O nedir, nasıl çalışır?
Tarihsel depolama sorunlarının bir anahtarı, 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şma sağlamak için tarihe uzlaşmanın yeterli olmasıdır. Ağ en son blok üzerinde uzlaşmaya vardığı 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. Uzlaşma N/2-of-N güven modeli iken, tarih N-of-N güven modelidir.
Bu, tarih kayıtlarını nasıl saklayacağımız konusunda birçok seçenek sunuyor. Doğal bir seçim, her bir düğümün yalnızca küçük bir veri parçasını sakladığı bir ağdır. Bu, tohum ağlarının yıllardır işleyiş şeklidir: ağ toplamda milyonlarca dosyayı saklayıp dağıtsa da, her katılımcı yalnızca bunlardan birkaçını saklayıp dağıtır. Belki de sezgiye ters olarak, bu yaklaşım veri sağlamlığını bile azaltmaz. Düğümlerin çalıştırılmasını daha ekonomik hale getirerek, her bir düğümün rastgele %10 tarih kaydını sakladığı 100.000 düğümlü bir ağ kurabiliriz; bu durumda her veri 10.000 kez kopyalanır - 10.000 düğümlü bir ağ ile tamamen aynı kopyalama faktörü - her düğümün her şeyi sakladığı bir ağ.
Günümüzde, Ethereum tüm düğümlerin tüm geçmişi kalıcı olarak depolama modelinden 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ık bir ağ biçiminde depolanacağı bir Ethereum düğümlerinden oluşan bir eşler arası ağ kurmaktır.
Erasure kodları, kopyalama 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 silme 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 koymaktır.
Mevcut araştırmalarla 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 depolanması ve sorgulanması;
Gas sınırını nasıl artırabilirim (Paradigm).
Ne yapmamız gerekiyor, neyi dengelememiz gerekiyor?
Kalan ana görevler, en azından yürütme geçmişi olmak üzere, tarihleri depolamak için belirli bir dağıtık çözüm inşa etmek ve entegre etmeyi içerir, ancak nihayetinde konsensüs ve blob'u da kapsar. En basit çözüm, (i) mevcut torrent kütüphanesini basitçe dahil etmek ve (ii) Portal ağı olarak adlandırılan Ethereum yerel çözümünü entegre etmektir. Bunlardan herhangi biri dahil edildiğinde, EIP-4444'ü açabiliriz. EIP-4444 kendisi sert bir hard fork gerektirmez, ancak yeni bir ağ protokolü sürümüne ihtiyaç duyar. Bu nedenle, tüm istemciler için bunu etkinleştirmek değerlidir; aksi takdirde, diğer düğümlere bağlanırken tam geçmişi indirmesini bekleyen istemcilerin aslında almadan hata verme riski vardır.
Ana denge, "antik" tarih verilerini sağlama çabamızla ilgilidir. En basit çözüm, yarın antik tarihleri depolamayı bırakmak ve mevcut arşiv nodları ile çeşitli merkezi sağlayıcılara güvenmektir. Bu kolaydır, ancak Ethereum'un kalıcı bir kayıt yeri olarak statüsünü 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"nun iki boyutu vardır:
En büyük düğüm kümesinin gerçekten tüm verileri sakladığından nasıl emin oluyoruz?
Protokole entegre edilen tarihsel veri depolamanın derinliği ne kadar derin?
(1) için aşırı bir tutucu yaklaşım, tutma kanıtını içerecektir: aslında her bir stake doğrulayıcısının belirli bir oranı geçmiş kayıtları saklamasını ve bunları düzenli olarak şifreli bir şekilde kontrol etmesini talep etmek. Daha ılımlı bir yaklaşım, her istemci tarafından saklanan 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ı kapsamaktadır: 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 saklama 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şir?
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'lik alanın 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 yalnızca birkaç dakikada ayarlanabilmesi vizyonunu gerçekleştirebilir.
Geçmiş depolamanın kısıtlanması, daha yeni Ethereum düğümlerinin daha uygulanabilir hale gelmesini sağladı; yalnızca protokolün en son sürümünü destekliyorlar ve bu da onları daha basit hale getiriyor. Örneğin, 2016'daki DoS saldırısı sırasında oluşturulan boş depolama alanlarının tamamen silinmesi nedeniyle artık birçok kod satırını güvenle silebilirsiniz. Hisse ispatına geçiş tarihe karıştığına göre, müşteriler iş kanıtı ile ilgili tüm kodları güvenle silebilirler.
Eyalet süresi doldu
Hangi sorunu çözüyor?
Müşteri tarafında depolama geçmişinin gerekliliğini ortadan kaldırmış olsak bile, müşteri depolama ihtiyacı her yıl yaklaşık 50 GB artmaya devam edecek, çünkü durum sürekli olarak büyüyor: hesap bakiyeleri ve rasgele sayılar, sözleşme kodları ve sözleşme depolama. Kullanıcılar, şu anki ve gelecekteki Ethereum müşterileri için kalıcı bir yük oluşturmak amacıyla tek seferlik bir ücret ödeyebilirler.
Durum, tarihten daha zor "sona ermek" çünkü EVM temelde böyle bir varsayım etrafında tasarlanmıştır: Bir kez durum nesnesi oluşturulduğunda, her zaman var olacaktır ve herhangi bir işlem tarafından her zaman okunabilir. Eğer durumsuzluğu getirirsek, bazıları bu sorunun o kadar kötü olmadığını düşünebilir: Sadece özel blok oluşturucu sınıflarının durumu gerçekten saklaması gerekirken, diğer tüm düğümler (hatta liste oluşturmayı içerenler!) durumsuz çalışabilir. Ancak, durumsuzluğa fazla bağımlı olmak istemediğimiz görüşü var; nihayetinde, Ethereum'un merkeziyetsizliğini korumak için durumu sona erdirmeyi umuyor olabiliriz.
O nedir, nasıl çalışır?
Bugün, yeni bir durum nesnesi oluşturduğunuzda (aşağıdaki üç yöntemden biriyle olabilir: (i) yeni bir hesaba ETH göndermek, (ii) kod kullanarak yeni bir hesap oluşturmak, (iii) daha önce hiç dokunulmamış bir depolama slotunu ayarlamak), bu durum nesnesi o durumda sonsuza kadar kalır. Aksine, istediğimiz şey nesnelerin zamanla otomatik olarak süresinin dolmasıdır. Ana zorluk, bunu üç hedefi gerçekleştirecek bir şekilde yapmaktır:
Verimlilik: Vadesi dolma sürecini işletmek 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şim hakkını kaybetmemelidir...
Geliştirici dostu olma: Geliştiricilerin tamamen tanıdık olmayan bir düşünce modeline geçmeleri gerekmez. 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ı kolayca çözebilir. Örneğin, her durum nesnesinin ayrıca bir son kullanma tarihi sayacı saklamasını sağlayabilirsiniz (bu, son kullanma tarihini uzatmak için ETH yakılarak yapılabilir ve bu, herhangi bir zamanda okunma veya yazılma sırasında otomatik olarak gerçekleşebilir) ve son kullanma tarihine sahip durum nesnelerini silmek için bir döngü oluşturabilirsiniz. Ancak bu ek hesaplama (hatta depolama ihtiyacı) getirir ve kullanıcı dostu olma gereksinimlerini kesinlikle karşılayamaz. Geliştiricilerin, depolama değerlerinin bazen sıfıra sıfırlanmasını içeren kenar durumlarını çıkarması da zor. Sözleşme kapsamına bir son kullanma sayacı ayarlarsanız, bu teknik olarak geliştiricilerin yaşamını kolaylaştırır, ancak ekonomiyi daha da karmaşık hale getirir: geliştiricilerin sürekli depolama maliyetini kullanıcıya "aktarmayı" düşünmeleri gerekir.
Bunlar, Ethereum çekirdek geliştirme topluluğunun yıllardır çözmeye çalıştığı sorunlardır, "blok zincir kira" ve "yeniden doğuş" gibi öneriler dahil. Sonunda, önerilerin en iyi kısımlarını bir araya getirdik ve "bilinen en kötü olmayan çözümler" 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 doldu
Bazı durum süresi dolmuş teklifleri aynı ilkelere uyar. Durumları bloklara ayırıyoruz. Herkes "üst düzey harita"yı kalıcı olarak saklar, burada bloklar boştur.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Ethereum The Purge: Karmaşıklığı Azaltma, Sürdürülebilirlik ve Güvenliği Artırma
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:
Geçmiş veriler: Tarih boyunca herhangi bir zamanda gerçekleştirilen herhangi bir işlem ve oluşturulan herhangi bir hesap, tüm istemciler tarafından kalıcı olarak depolanmalı ve herhangi bir yeni istemci tarafından indirilmelidir, böylece tamamen ağa senkronize edilir. Bu, istemci yükünün ve senkronizasyon süresinin zamanla artmasına neden olur, hatta 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 yol açar.
Ethereum'un uzun vadede sürdürülebilir olabilmesi için bu iki trende güçlü bir ters baskı uygulamamız gerekiyor, zamanla karmaşıklığı ve genişlemeyi azaltmalıyız. Ancak aynı zamanda, blok zincirini harika kılan temel özelliklerden birini korumamız gerekiyor: kalıcılık. Bir NFT, bir işlem çağrı verisindeki aşk mektubu veya 1 milyon dolar içeren bir akıllı sözleşmeyi zincire koyabilir, on yıl bir mağaraya girebilir ve çıktığınızda hala orada sizi beklediğini görebilirsiniz. DApp'lerin tamamen merkeziyetsiz bir şekilde rahatça hareket edebilmesi ve güncelleme anahtarlarını kaldırabilmesi için, bağımlılıklarının kendilerini yok edecek şekilde güncellenmeyeceğinden emin olmaları gerekiyor - özellikle L1'in kendisi.
Eğer kararlıyız ve bu iki talep arasında bir denge kurarak sürekliliği sağlarken aşırılığı, karmaşıklığı ve gerilemeyi en aza indirmeyi veya tersine çevirmeyi başarabiliriz, bu kesinlikle mümkündür. Organizmalar bunu yapabilir: Çoğu organizma zamanla yaşlansa da, şanslı birkaç tanesi yaşlanmaz. Sosyal sistemler de çok uzun ömürlü olabilir. Bazı durumlarda, Ethereum başarı elde etmiştir: İş kanıtı ortadan kalktı, SELFDESTRUCT opcode'unun çoğu kayboldu ve beacon chain düğümleri en fazla altı ay boyunca eski verileri depoladı. Ethereum için bu yolu daha genel bir şekilde bulmak ve uzun vadeli istikrarlı bir nihai sonuca yönelmek, Ethereum'un uzun vadeli ölçeklenebilirliği, teknik sürdürülebilirliği ve hatta güvenliği açısından nihai zorluktur.
The Purge: Ana hedef.
İstemci depolama gereksinimlerini azaltmak için her düğümün tüm geçmiş kayıtları veya hatta nihai durumu kalıcı olarak depolama gereksinimini azaltarak veya ortadan kaldırarak.
Protokolün karmaşıklığını azaltmak için gereksiz işlevleri ortadan kaldırarak.
Makale dizini:
Tarih sona erme（历史记录到期）
State expiry（状态到期）
Özellik temizliği (特征清理)
Tarih sonu
Hangi sorunu çözüyor?
Bu makale yazıldığı sırada, tamamen senkronize bir Ethereum düğümü, istemcinin çalıştırılması için yaklaşık 1.1 TB disk alanına ihtiyaç duymaktadır; ayrıca konsensüs istemcisi için yüzlerce GB disk alanına ihtiyaç vardır. Bunun büyük bir kısmı tarihe dayanıyor: Tarihsel bloklar, işlemler ve makbuzlar hakkında veriler, bunların çoğu yıllardır mevcut. Bu, Gas sınırı hiç artmasa bile, düğüm boyutunun her yıl yüzlerce GB artmaya devam edeceği anlamına geliyor.
O nedir, nasıl çalışır?
Tarihsel depolama sorunlarının bir anahtarı, 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şma sağlamak için tarihe uzlaşmanın yeterli olmasıdır. Ağ en son blok üzerinde uzlaşmaya vardığı 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. Uzlaşma N/2-of-N güven modeli iken, tarih N-of-N güven modelidir.
Bu, tarih kayıtlarını nasıl saklayacağımız konusunda birçok seçenek sunuyor. Doğal bir seçim, her bir düğümün yalnızca küçük bir veri parçasını sakladığı bir ağdır. Bu, tohum ağlarının yıllardır işleyiş şeklidir: ağ toplamda milyonlarca dosyayı saklayıp dağıtsa da, her katılımcı yalnızca bunlardan birkaçını saklayıp dağıtır. Belki de sezgiye ters olarak, bu yaklaşım veri sağlamlığını bile azaltmaz. Düğümlerin çalıştırılmasını daha ekonomik hale getirerek, her bir düğümün rastgele %10 tarih kaydını sakladığı 100.000 düğümlü bir ağ kurabiliriz; bu durumda her veri 10.000 kez kopyalanır - 10.000 düğümlü bir ağ ile tamamen aynı kopyalama faktörü - her düğümün her şeyi sakladığı bir ağ.
Günümüzde, Ethereum tüm düğümlerin tüm geçmişi kalıcı olarak depolama modelinden 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ık bir ağ biçiminde depolanacağı bir Ethereum düğümlerinden oluşan bir eşler arası ağ kurmaktır.
Erasure kodları, kopyalama 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 silme 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 koymaktır.
Mevcut araştırmalarla 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 depolanması ve sorgulanması;
Gas sınırını nasıl artırabilirim (Paradigm).
Ne yapmamız gerekiyor, neyi dengelememiz gerekiyor?
Kalan ana görevler, en azından yürütme geçmişi olmak üzere, tarihleri depolamak için belirli bir dağıtık çözüm inşa etmek ve entegre etmeyi içerir, ancak nihayetinde konsensüs ve blob'u da kapsar. En basit çözüm, (i) mevcut torrent kütüphanesini basitçe dahil etmek ve (ii) Portal ağı olarak adlandırılan Ethereum yerel çözümünü entegre etmektir. Bunlardan herhangi biri dahil edildiğinde, EIP-4444'ü açabiliriz. EIP-4444 kendisi sert bir hard fork gerektirmez, ancak yeni bir ağ protokolü sürümüne ihtiyaç duyar. Bu nedenle, tüm istemciler için bunu etkinleştirmek değerlidir; aksi takdirde, diğer düğümlere bağlanırken tam geçmişi indirmesini bekleyen istemcilerin aslında almadan hata verme riski vardır.
Ana denge, "antik" tarih verilerini sağlama çabamızla ilgilidir. En basit çözüm, yarın antik tarihleri depolamayı bırakmak ve mevcut arşiv nodları ile çeşitli merkezi sağlayıcılara güvenmektir. Bu kolaydır, ancak Ethereum'un kalıcı bir kayıt yeri olarak statüsünü 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"nun iki boyutu vardır:
En büyük düğüm kümesinin gerçekten tüm verileri sakladığından nasıl emin oluyoruz?
Protokole entegre edilen tarihsel veri depolamanın derinliği ne kadar derin?
(1) için aşırı bir tutucu yaklaşım, tutma kanıtını içerecektir: aslında her bir stake doğrulayıcısının belirli bir oranı geçmiş kayıtları saklamasını ve bunları düzenli olarak şifreli bir şekilde kontrol etmesini talep etmek. Daha ılımlı bir yaklaşım, her istemci tarafından saklanan 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ı kapsamaktadır: 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 saklama 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şir?
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'lik alanın 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 yalnızca birkaç dakikada ayarlanabilmesi vizyonunu gerçekleştirebilir.
Geçmiş depolamanın kısıtlanması, daha yeni Ethereum düğümlerinin daha uygulanabilir hale gelmesini sağladı; yalnızca protokolün en son sürümünü destekliyorlar ve bu da onları daha basit hale getiriyor. Örneğin, 2016'daki DoS saldırısı sırasında oluşturulan boş depolama alanlarının tamamen silinmesi nedeniyle artık birçok kod satırını güvenle silebilirsiniz. Hisse ispatına geçiş tarihe karıştığına göre, müşteriler iş kanıtı ile ilgili tüm kodları güvenle silebilirler.
Eyalet süresi doldu
Hangi sorunu çözüyor?
Müşteri tarafında depolama geçmişinin gerekliliğini ortadan kaldırmış olsak bile, müşteri depolama ihtiyacı her yıl yaklaşık 50 GB artmaya devam edecek, çünkü durum sürekli olarak büyüyor: hesap bakiyeleri ve rasgele sayılar, sözleşme kodları ve sözleşme depolama. Kullanıcılar, şu anki ve gelecekteki Ethereum müşterileri için kalıcı bir yük oluşturmak amacıyla tek seferlik bir ücret ödeyebilirler.
Durum, tarihten daha zor "sona ermek" çünkü EVM temelde böyle bir varsayım etrafında tasarlanmıştır: Bir kez durum nesnesi oluşturulduğunda, her zaman var olacaktır ve herhangi bir işlem tarafından her zaman okunabilir. Eğer durumsuzluğu getirirsek, bazıları bu sorunun o kadar kötü olmadığını düşünebilir: Sadece özel blok oluşturucu sınıflarının durumu gerçekten saklaması gerekirken, diğer tüm düğümler (hatta liste oluşturmayı içerenler!) durumsuz çalışabilir. Ancak, durumsuzluğa fazla bağımlı olmak istemediğimiz görüşü var; nihayetinde, Ethereum'un merkeziyetsizliğini korumak için durumu sona erdirmeyi umuyor olabiliriz.
O nedir, nasıl çalışır?
Bugün, yeni bir durum nesnesi oluşturduğunuzda (aşağıdaki üç yöntemden biriyle olabilir: (i) yeni bir hesaba ETH göndermek, (ii) kod kullanarak yeni bir hesap oluşturmak, (iii) daha önce hiç dokunulmamış bir depolama slotunu ayarlamak), bu durum nesnesi o durumda sonsuza kadar kalır. Aksine, istediğimiz şey nesnelerin zamanla otomatik olarak süresinin dolmasıdır. Ana zorluk, bunu üç hedefi gerçekleştirecek bir şekilde yapmaktır:
Verimlilik: Vadesi dolma sürecini işletmek 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şim hakkını kaybetmemelidir...
Geliştirici dostu olma: Geliştiricilerin tamamen tanıdık olmayan bir düşünce modeline geçmeleri gerekmez. 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ı kolayca çözebilir. Örneğin, her durum nesnesinin ayrıca bir son kullanma tarihi sayacı saklamasını sağlayabilirsiniz (bu, son kullanma tarihini uzatmak için ETH yakılarak yapılabilir ve bu, herhangi bir zamanda okunma veya yazılma sırasında otomatik olarak gerçekleşebilir) ve son kullanma tarihine sahip durum nesnelerini silmek için bir döngü oluşturabilirsiniz. Ancak bu ek hesaplama (hatta depolama ihtiyacı) getirir ve kullanıcı dostu olma gereksinimlerini kesinlikle karşılayamaz. Geliştiricilerin, depolama değerlerinin bazen sıfıra sıfırlanmasını içeren kenar durumlarını çıkarması da zor. Sözleşme kapsamına bir son kullanma sayacı ayarlarsanız, bu teknik olarak geliştiricilerin yaşamını kolaylaştırır, ancak ekonomiyi daha da karmaşık hale getirir: geliştiricilerin sürekli depolama maliyetini kullanıcıya "aktarmayı" düşünmeleri gerekir.
Bunlar, Ethereum çekirdek geliştirme topluluğunun yıllardır çözmeye çalıştığı sorunlardır, "blok zincir kira" ve "yeniden doğuş" gibi öneriler dahil. Sonunda, önerilerin en iyi kısımlarını bir araya getirdik ve "bilinen en kötü olmayan çözümler" olarak iki kategoriye odaklandık:
Kısmi durum süresi doldu
Bazı durum süresi dolmuş teklifleri aynı ilkelere uyar. Durumları bloklara ayırıyoruz. Herkes "üst düzey harita"yı kalıcı olarak saklar, burada bloklar boştur.