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: Tarih boyunca gerçekleştirilen her türlü işlem ve oluşturulan her türlü hesabın, tüm istemciler tarafından kalıcı olarak saklanması ve herhangi bir yeni istemci tarafından indirilmesi gerekir, böylece ağa tamamen senkronize olur. Bu durum, istemci yükünün 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 kod karmaşıklığının zamanla 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 bu arada, blockchain'i harika kılan temel özelliklerden birini de korumamız gerekiyor: kalıcılık. Bir NFT, bir ticaret çağrısı verisindeki aşk mektubu ya da 1 milyon dolar içeren bir akıllı sözleşmeyi zincire koyabilirsiniz, on yıl bir mağaraya girip çıktığınızda, onun 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 güncelleme anahtarlarını silmesi 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ıysak, bu iki talep arasında bir denge kurmak ve sürekliliği sağlarken aşırı büyüme, karmaşıklık ve gerilemeyi en aza indirmek veya tersine çevirmek kesinlikle mümkündür. Organizmalar bunu yapabilir: Çoğu organizma zamanla yaşlansa da, bazı şanslılar bunu başaramaz. Hatta sosyal sistemler de çok uzun ömürlü olabilir. Bazı durumlarda, Ethereum başarı elde etmiştir: İş kanıtı ortadan kalktı, SELFDESTRUCT opcode'un büyük kısmı kayboldu, 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 ulaşmak, Ethereum'un uzun vadeli ölçeklenebilirliği, teknolojik sürdürülebilirliği ve hatta güvenliği için nihai zorluktur.
The Purge: Ana hedef.
Müşteri depolama gereksinimlerini azaltmak için her bir düğümün tüm geçmiş kayıtları veya en son durumu kalıcı olarak saklama ihtiyacını azaltarak veya ortadan kaldırarak.
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
Tarih son kullanma
neyi çözüyor?
Bu makalenin yazıldığı tarihte, tamamen 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ına ihtiyaç vardır. Bunun büyük bir kısmı tarihsel verilerden oluşmaktadır: tarihsel bloklar, işlemler ve makbuzlarla ilgili veriler, bunların ç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 geliyor.
Bu nedir, nasıl çalışır?
Tarihsel depolama sorunlarının temel bir 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 konsensusa ulaşmanın yeterli olmasıdır. Ağın en son blok üzerinde fikir birliğine varması durumunda, 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, diğer herkesin doğruluğunu doğrulamasına olanak tanır. Konsensüs, N/2-of-N güven modelidir, oysa 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ığı yöntemdir: Ağ toplamda milyonlarca dosya depolayıp dağıtsa da, her katılımcı yalnızca bunlardan birkaçını depolar ve dağıtır. Belki de sezgiye aykırı olarak, bu yaklaşım veri dayanıklılığını mutlaka azaltmaz. Düğümlerin çalışmasını daha ekonomik hale getirerek, her bir düğümün rastgele %10'luk bir tarih kaydı depoladığı 100.000 düğümlü bir ağ kurabiliriz; böylece her veri 10.000 kez kopyalanır - bu, her düğümün her şeyi depoladığı 10.000 düğümlü bir ağın kopyalama faktörüyle tamamen aynıdır.
Artık Ethereum, tüm düğümlerin tüm geçmiş verileri kalıcı olarak sakladığı modelden kurtulmaya başladı. Konsensüs blokları (yani, hisse kanıtı konsensüsü ile ilgili kısım) yalnızca yaklaşık 6 ay saklanmaktadır. Blob yalnızca yaklaşık 18 gün saklanmaktadır. EIP-4444, tarih blokları ve makbuzlar için bir yıllık bir saklama süresi getirmeyi amaçlamaktadır. Uzun vadeli hedef, her düğümün tüm içeriği saklamakla sorumlu olduğu, bu süre zarfında (muhtemelen yaklaşık 18 gün) tek bir dönem oluşturmaktır ve ardından eski verileri dağıtık bir ağ şeklinde saklayacak 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 veri kullanılabilirliği örneklemesini desteklemek için silme kodları ile kodlanmış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 hangi bağlantılara sahip?
EIP-4444；
Torrentler ve EIP-4444；
Portallar Ağı;
Portal ağı ve EIP-4444;
Portal'daki SSZ nesnelerinin dağıtık depolama ve erişimi;
Gas limitini nasıl artırırsınız (Paradigm).
ne yapılması gerekiyor, neyi dengelememiz gerekiyor?
Kalan temel işler, en azından yürütme geçmişi için, ama nihayetinde konsensüs ve blob'u içerecek şekilde tarihleri saklamak için somut bir dağıtık çözüm oluşturmak ve entegre etmeyi içerir. En basit çözüm, (i) mevcut torrent kütüphanelerini basitçe tanıtmaktır ve (ii) Ethereum'a ait Portal ağı olarak adlandırılan bir çözümdür. Bunlardan herhangi biri tanıtıldığında, EIP-4444'ü açabiliriz. EIP-4444 kendisi sert bir çatal gerektirmez, ancak yeni bir ağ protokolü sürümü gerektirir. Bu nedenle, bunu tüm istemciler için aynı anda etkinleştirmek değerlidir; aksi takdirde, diğer düğümlere bağlanmayı beklerken tam geçmişi indirmesi gereken istemcilerin, aslında bunu almadığı için çökme riski vardır.
Ana denge, "eski" tarih verilerini sağlamak için nasıl çaba gösterdiğ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 dayanarak çoğaltmaktır. Bu kolaydır, ancak bu, Ethereum'un kalıcı bir kayıt yeri olarak konumunu zayıflatır. Daha zor ama daha güvenli bir yol, öncelikle eski verileri dağıtılmış bir şekilde depolamak için bir torrent ağı inşa etmek ve entegre etmektir. Burada, "ne kadar çaba sarf ediyoruz" iki boyuta sahiptir:
En büyük düğüm kümesinin gerçekten tüm verileri sakladığından nasıl emin oluyoruz?
Protokole entegre edilen tarihsel depolama derinliği ne kadar derin?
(1) için aşırı bir takıntılı yaklaşım, bir güvence kanıtı gerektirecektir: aslında her staking doğrulayıcısının belirli bir oranda geçmiş verileri depolamasını ve bunları düzenli olarak şifreli bir şekilde kontrol etmesini talep eder. Daha ılımlı bir yaklaşım, her istemci için depolanan geçmiş yüzdesi için gönüllü bir standart belirlemektir.
(2) için, temel uygulama yalnızca bugün tamamlanan işleri kapsamaktadır: Portal, tüm Ethereum tarihini içeren ERA dosyasını depolamıştır. Daha kapsamlı bir uygulama, bunu senkronizasyon sürecine bağlamayı gerektirecektir; 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, portal ağı üzerinden doğrudan senkronizasyon ile bunu gerçekleştirebilirler.
Diğer yol haritası bölümleriyle nasıl etkileşime giriyor?
Eğer düğümlerin çalıştırılmasını veya başlatılmasını son derece kolay hale getirmek istiyorsak, tarihsel depolama gereksinimlerini azaltmak, durumsuzluktan 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 tarih oldu. Sadece durumsuzluğu ve EIP-4444'ü gerçekleştirerek, akıllı saatlerde Ethereum düğümünü çalıştırma ve sadece birkaç dakika içinde ayarlarını yapma vizyonunu gerçekleştirebiliriz.
Geçmiş depolamanın sınırlandırılması, daha yeni Ethereum düğümlerinin daha uygulanabilir hale gelmesini sağlıyor; yalnızca protokolün en son sürümünü destekliyorlar, 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 tamamı silindiği için artık birçok kod satırını güvenle silebilirsiniz. Hisse kanıtına geçiş tarihi olduğuna göre, müşteriler iş kanıtıyla ilgili tüm kodları güvenle silebilirler.
Durum süresi dolumu
neyi çözüyor?
Müşterinin depolama geçmişini kaldırmış olsak bile, müşterinin depolama ihtiyacı her yıl yaklaşık 50 GB artmaya devam edecek çünkü durum sürekli büyüyor: hesap bakiyeleri ve rastgele sayılar, sözleşme kodları ve sözleşme depolaması. Kullanıcılar, mevcut ve gelecekteki Ethereum müşterilerini sonsuza kadar yükümlü kılacak tek seferlik bir ücret ödeyebilir.
Durumun "süresi dolmuş" olması, tarihten daha zor çünkü EVM temelde böyle bir varsayıma göre tasarlanmıştır: Bir durum nesnesi oluşturulduğunda, her zaman var olacağı ve herhangi bir işlem tarafından her zaman okunabileceği varsayılır. Eğer durumsuzluğu getirirsek, bazıları bu sorunun o kadar kötü olmayabileceğini düşünüyor: Sadece özel blok inşaatçı sınıflarının durumu gerçekten depolaması gerekiyor, diğer tüm düğümler (hatta liste oluşturmayı içeren!) durumsuz çalışabilir. Ancak, durumsuzluğa fazla bağımlı olmak istemediğimiz görüşü var; nihayetinde, Ethereum'un merkeziyetsizliğini korumak için durumu süresi dolmuş hale getirmek isteyebiliriz.
O nedir, nasıl çalışır?
Bugün, yeni bir durum nesnesi oluşturduğunuzda (bu üç yoldan biriyle gerçekleşebilir: (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 o durumda sonsuza dek kalır. Bunun yerine istediğimiz, nesnelerin zamanla otomatik olarak süresinin dolmasıdır. Ana 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: 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: Geliştiricilerin tamamen tanımadıkları bir düşünce modeline geçmeleri gerekmez. Ayrıca, şu anda katılaşmış ve güncellenmeyen uygulamaların normal şekilde çalışmaya devam etmesi gerekir.
Bu hedefleri karşılamamak sorunları kolayca çözmeyi sağlar. Örneğin, her durum nesnesinin bir son tarih sayacı da saklamasını sağlayabilirsiniz (son tarihi uzatmak için ETH yakarak, bu herhangi bir zamanda okuma veya yazma sırasında otomatik olarak gerçekleşebilir) ve son tarihleri silmek için durumu döngüsel olarak gözden geçiren bir süreç olabilir. Ancak bu, ek hesaplama (hatta depolama ihtiyacı) getirir ve kesinlikle kullanıcı dostu olma gereksinimlerini karşılayamaz. Geliştiricilerin, depolanan değerlerin bazen sıfıra sıfırlanmasını içeren kenar durumlarını anlaması da zordur. Sözleşme kapsamında 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ıya "aktarmayı" düşünmek zorundadır.
Bunlar, Ethereum çekirdek geliştirme topluluğunun yıllardır çözmeye çalıştığı sorunlar, "blok zinciri kiralaması" ve "yeniden doğuş" gibi önerileri 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 süresi dolmuş çözümü
Adres döngüsüne dayalı durum sona erme önerisi.
Kısmi durum süresi dolumu
Bazı durum sona erme teklifleri aynı ilkelere uyar. Durumu parçalara ayırıyoruz. Herkes "en üst harita"yı kalıcı olarak depolar.
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.
13 Likes
Reward
13
7
Repost
Share
Comment
0/400
Hash_Bandit
· 08-06 19:58
bunu daha önce gördüm... madencilik günlerinde düğüm senkronizasyonunu optimize ettiğimiz zamanlar gibi. eth'nin daha fazla hashrate tarzı verimliliğine ihtiyacı var açıkçası.
View OriginalReply0
ILCollector
· 08-04 07:11
Verilerinizi L2 ile paketlemenizi öneririm.
View OriginalReply0
TokenomicsTrapper
· 08-03 21:09
bu şişkinlik sorununu aylardır söyledim... klasik teknoloji borcu ölüm sarmalı geliyor
Vitalik, Ethereum'un gelecekteki gelişimini analiz ediyor: The Purge planının analizi
Vitalik: 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: Tarih boyunca gerçekleştirilen her türlü işlem ve oluşturulan her türlü hesabın, tüm istemciler tarafından kalıcı olarak saklanması ve herhangi bir yeni istemci tarafından indirilmesi gerekir, böylece ağa tamamen senkronize olur. Bu durum, istemci yükünün 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 kod karmaşıklığının zamanla 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 bu arada, blockchain'i harika kılan temel özelliklerden birini de korumamız gerekiyor: kalıcılık. Bir NFT, bir ticaret çağrısı verisindeki aşk mektubu ya da 1 milyon dolar içeren bir akıllı sözleşmeyi zincire koyabilirsiniz, on yıl bir mağaraya girip çıktığınızda, onun 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 güncelleme anahtarlarını silmesi 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ıysak, bu iki talep arasında bir denge kurmak ve sürekliliği sağlarken aşırı büyüme, karmaşıklık ve gerilemeyi en aza indirmek veya tersine çevirmek kesinlikle mümkündür. Organizmalar bunu yapabilir: Çoğu organizma zamanla yaşlansa da, bazı şanslılar bunu başaramaz. Hatta sosyal sistemler de çok uzun ömürlü olabilir. Bazı durumlarda, Ethereum başarı elde etmiştir: İş kanıtı ortadan kalktı, SELFDESTRUCT opcode'un büyük kısmı kayboldu, 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 ulaşmak, Ethereum'un uzun vadeli ölçeklenebilirliği, teknolojik sürdürülebilirliği ve hatta güvenliği için nihai zorluktur.
The Purge: Ana hedef.
Müşteri depolama gereksinimlerini azaltmak için her bir düğümün tüm geçmiş kayıtları veya en son durumu kalıcı olarak saklama ihtiyacını azaltarak veya ortadan kaldırarak.
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
Tarih son kullanma
neyi çözüyor?
Bu makalenin yazıldığı tarihte, tamamen 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ına ihtiyaç vardır. Bunun büyük bir kısmı tarihsel verilerden oluşmaktadır: tarihsel bloklar, işlemler ve makbuzlarla ilgili veriler, bunların ç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 geliyor.
Bu nedir, nasıl çalışır?
Tarihsel depolama sorunlarının temel bir 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 konsensusa ulaşmanın yeterli olmasıdır. Ağın en son blok üzerinde fikir birliğine varması durumunda, 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, diğer herkesin doğruluğunu doğrulamasına olanak tanır. Konsensüs, N/2-of-N güven modelidir, oysa 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ığı yöntemdir: Ağ toplamda milyonlarca dosya depolayıp dağıtsa da, her katılımcı yalnızca bunlardan birkaçını depolar ve dağıtır. Belki de sezgiye aykırı olarak, bu yaklaşım veri dayanıklılığını mutlaka azaltmaz. Düğümlerin çalışmasını daha ekonomik hale getirerek, her bir düğümün rastgele %10'luk bir tarih kaydı depoladığı 100.000 düğümlü bir ağ kurabiliriz; böylece her veri 10.000 kez kopyalanır - bu, her düğümün her şeyi depoladığı 10.000 düğümlü bir ağın kopyalama faktörüyle tamamen aynıdır.
Artık Ethereum, tüm düğümlerin tüm geçmiş verileri kalıcı olarak sakladığı modelden kurtulmaya başladı. Konsensüs blokları (yani, hisse kanıtı konsensüsü ile ilgili kısım) yalnızca yaklaşık 6 ay saklanmaktadır. Blob yalnızca yaklaşık 18 gün saklanmaktadır. EIP-4444, tarih blokları ve makbuzlar için bir yıllık bir saklama süresi getirmeyi amaçlamaktadır. Uzun vadeli hedef, her düğümün tüm içeriği saklamakla sorumlu olduğu, bu süre zarfında (muhtemelen yaklaşık 18 gün) tek bir dönem oluşturmaktır ve ardından eski verileri dağıtık bir ağ şeklinde saklayacak 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 veri kullanılabilirliği örneklemesini desteklemek için silme kodları ile kodlanmış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 hangi bağlantılara sahip?
EIP-4444；
Torrentler ve EIP-4444；
Portallar Ağı;
Portal ağı ve EIP-4444;
Portal'daki SSZ nesnelerinin dağıtık depolama ve erişimi;
Gas limitini nasıl artırırsınız (Paradigm).
ne yapılması gerekiyor, neyi dengelememiz gerekiyor?
Kalan temel işler, en azından yürütme geçmişi için, ama nihayetinde konsensüs ve blob'u içerecek şekilde tarihleri saklamak için somut bir dağıtık çözüm oluşturmak ve entegre etmeyi içerir. En basit çözüm, (i) mevcut torrent kütüphanelerini basitçe tanıtmaktır ve (ii) Ethereum'a ait Portal ağı olarak adlandırılan bir çözümdür. Bunlardan herhangi biri tanıtıldığında, EIP-4444'ü açabiliriz. EIP-4444 kendisi sert bir çatal gerektirmez, ancak yeni bir ağ protokolü sürümü gerektirir. Bu nedenle, bunu tüm istemciler için aynı anda etkinleştirmek değerlidir; aksi takdirde, diğer düğümlere bağlanmayı beklerken tam geçmişi indirmesi gereken istemcilerin, aslında bunu almadığı için çökme riski vardır.
Ana denge, "eski" tarih verilerini sağlamak için nasıl çaba gösterdiğ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 dayanarak çoğaltmaktır. Bu kolaydır, ancak bu, Ethereum'un kalıcı bir kayıt yeri olarak konumunu zayıflatır. Daha zor ama daha güvenli bir yol, öncelikle eski verileri dağıtılmış bir şekilde depolamak için bir torrent ağı inşa etmek ve entegre etmektir. Burada, "ne kadar çaba sarf ediyoruz" iki boyuta sahiptir:
En büyük düğüm kümesinin gerçekten tüm verileri sakladığından nasıl emin oluyoruz?
Protokole entegre edilen tarihsel depolama derinliği ne kadar derin?
(1) için aşırı bir takıntılı yaklaşım, bir güvence kanıtı gerektirecektir: aslında her staking doğrulayıcısının belirli bir oranda geçmiş verileri depolamasını ve bunları düzenli olarak şifreli bir şekilde kontrol etmesini talep eder. Daha ılımlı bir yaklaşım, her istemci için depolanan geçmiş yüzdesi için gönüllü bir standart belirlemektir.
(2) için, temel uygulama yalnızca bugün tamamlanan işleri kapsamaktadır: Portal, tüm Ethereum tarihini içeren ERA dosyasını depolamıştır. Daha kapsamlı bir uygulama, bunu senkronizasyon sürecine bağlamayı gerektirecektir; 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, portal ağı üzerinden doğrudan senkronizasyon ile bunu gerçekleştirebilirler.
Diğer yol haritası bölümleriyle nasıl etkileşime giriyor?
Eğer düğümlerin çalıştırılmasını veya başlatılmasını son derece kolay hale getirmek istiyorsak, tarihsel depolama gereksinimlerini azaltmak, durumsuzluktan 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 tarih oldu. Sadece durumsuzluğu ve EIP-4444'ü gerçekleştirerek, akıllı saatlerde Ethereum düğümünü çalıştırma ve sadece birkaç dakika içinde ayarlarını yapma vizyonunu gerçekleştirebiliriz.
Geçmiş depolamanın sınırlandırılması, daha yeni Ethereum düğümlerinin daha uygulanabilir hale gelmesini sağlıyor; yalnızca protokolün en son sürümünü destekliyorlar, 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 tamamı silindiği için artık birçok kod satırını güvenle silebilirsiniz. Hisse kanıtına geçiş tarihi olduğuna göre, müşteriler iş kanıtıyla ilgili tüm kodları güvenle silebilirler.
Durum süresi dolumu
neyi çözüyor?
Müşterinin depolama geçmişini kaldırmış olsak bile, müşterinin depolama ihtiyacı her yıl yaklaşık 50 GB artmaya devam edecek çünkü durum sürekli büyüyor: hesap bakiyeleri ve rastgele sayılar, sözleşme kodları ve sözleşme depolaması. Kullanıcılar, mevcut ve gelecekteki Ethereum müşterilerini sonsuza kadar yükümlü kılacak tek seferlik bir ücret ödeyebilir.
Durumun "süresi dolmuş" olması, tarihten daha zor çünkü EVM temelde böyle bir varsayıma göre tasarlanmıştır: Bir durum nesnesi oluşturulduğunda, her zaman var olacağı ve herhangi bir işlem tarafından her zaman okunabileceği varsayılır. Eğer durumsuzluğu getirirsek, bazıları bu sorunun o kadar kötü olmayabileceğini düşünüyor: Sadece özel blok inşaatçı sınıflarının durumu gerçekten depolaması gerekiyor, diğer tüm düğümler (hatta liste oluşturmayı içeren!) durumsuz çalışabilir. Ancak, durumsuzluğa fazla bağımlı olmak istemediğimiz görüşü var; nihayetinde, Ethereum'un merkeziyetsizliğini korumak için durumu süresi dolmuş hale getirmek isteyebiliriz.
O nedir, nasıl çalışır?
Bugün, yeni bir durum nesnesi oluşturduğunuzda (bu üç yoldan biriyle gerçekleşebilir: (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 o durumda sonsuza dek kalır. Bunun yerine istediğimiz, nesnelerin zamanla otomatik olarak süresinin dolmasıdır. Ana 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: 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: Geliştiricilerin tamamen tanımadıkları bir düşünce modeline geçmeleri gerekmez. Ayrıca, şu anda katılaşmış ve güncellenmeyen uygulamaların normal şekilde çalışmaya devam etmesi gerekir.
Bu hedefleri karşılamamak sorunları kolayca çözmeyi sağlar. Örneğin, her durum nesnesinin bir son tarih sayacı da saklamasını sağlayabilirsiniz (son tarihi uzatmak için ETH yakarak, bu herhangi bir zamanda okuma veya yazma sırasında otomatik olarak gerçekleşebilir) ve son tarihleri silmek için durumu döngüsel olarak gözden geçiren bir süreç olabilir. Ancak bu, ek hesaplama (hatta depolama ihtiyacı) getirir ve kesinlikle kullanıcı dostu olma gereksinimlerini karşılayamaz. Geliştiricilerin, depolanan değerlerin bazen sıfıra sıfırlanmasını içeren kenar durumlarını anlaması da zordur. Sözleşme kapsamında 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ıya "aktarmayı" düşünmek zorundadır.
Bunlar, Ethereum çekirdek geliştirme topluluğunun yıllardır çözmeye çalıştığı sorunlar, "blok zinciri kiralaması" ve "yeniden doğuş" gibi önerileri 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 süresi dolumu
Bazı durum sona erme teklifleri aynı ilkelere uyar. Durumu parçalara ayırıyoruz. Herkes "en üst harita"yı kalıcı olarak depolar.