Ethereum'in karşılaştığı bir zorluk, varsayılan olarak, herhangi bir blok zinciri protokolünün genişlemesi ve karmaşıklığının zamanla artmasıdır. Bu, iki alanda gerçekleşir:
Tarihsel veriler: Tarihte 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ün ve senkronizasyon süresinin zamanla artmasına yol açar, zincirin kapasitesi sabit kalsa bile.
Protokol İş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 bu arada, blok zincirini harika yapan temel özelliklerden birini: kalıcılığı korumalıyız. Bir NFT, bir işlem çağrısı verilerinde bir aşk mektubu veya 1 milyon doları içeren bir akıllı sözleşmeyi zincire koyabilir, bir mağaraya on yıl girebilir ve çıktığınızda hala okuyup etkileşimde bulunmanız için orada beklediğini görebilirsiniz. DApp'lerin gönül rahatlığıyla tamamen merkeziyetsiz hale gelmesi ve güncelleme anahtarlarını kaldırması için, bağımlılıklarının kendilerini yok edecek şekilde güncellenmeyeceğinden emin olmaları gerekir - özellikle L1'in kendisi.
Eğer kararlıysek, bu iki talep arasında bir denge sağlamak 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, bazı şanslılar bunu başaramaz. Sosyal sistemler bile çok uzun bir ömre sahip olabilir. Bazı durumlarda, Ethereum başarı elde etti: İş kanıtı ortadan kalktı, SELFDESTRUCT opcode'ları çoğunlukla 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, teknik sürdürülebilirliği ve hatta güvenliği açısından nihai bir meydan okumadır.
The Purge: Ana Hedefler
Müşteri depolama gereksinimlerini azaltarak veya her düğümün tüm geçmiş kayıtlarını veya en son durumu kalıcı olarak depolama gereksinimini ortadan kaldırarak.
Protokol karmaşıklığını azaltmak için gereksiz işlevleri ortadan kaldırarak.
Tarih sonu
neyi çözüyor?
Makalenin yazıldığı tarihte, tamamen senkronize edilmiş Ethereum düğümleri, istemciyi çalıştırmak için yaklaşık 1.1 TB disk alanına ihtiyaç duyar ve ayrıca konsensüs istemcisi için yüzlerce GB disk alanı gereklidir. Bunun büyük bir kısmı tarihle ilgilidir: Tarihi bloklar, işlemler ve makbuzlarla ilgili veriler, çoğu birkaç yıl öncesine aittir. Bu, Gas sınırı hiç artmasa bile, düğüm boyutunun her yıl yüzlerce GB artmaya devam edeceği anlamına gelir.
Bu nedir, nasıl çalışır?
Tarihsel depolama sorununun bir anahtar basitleştirilmiş özelliği, her bloğun bir hash bağlantısı (ve diğer yapılar) aracılığıyla bir önceki bloğa işaret etmesi nedeniyle, mevcut konsensusa ulaşmanın tarihsel konsensusa ulaşmak için yeterli olmasıdır. Ağ, en son blok üzerinde konsensusa 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 birlikte verilebilir 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, tarihte ise 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ı depoladığı bir ağdır. Bu, tohum ağlarının on yıllardır çalışma şeklidir: ağ toplamda milyonlarca dosyayı depolayıp dağıtsa da, her katılımcı yalnızca bunlardan birkaç dosyayı saklayıp dağıtır. Belki de sezgilere ters düşecek şekilde, bu yöntem veri sağlamlığını mutlaka azaltmaz. Düğümlerin çalışma maliyetini daha ekonomik hale getirerek, her bir düğümün rastgele %10'luk bir tarih kaydını sakladığı 100.000 düğümlük bir ağ kurarsak, her veri 10.000 kez kopyalanacaktır - bu, her düğümün her şeyi sakladığı 10.000 düğümlük bir ağ ile tamamen aynı kopyalama faktörü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, 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 tüm içerikleri depolamakla sorumlu olduğu ve ardından eski verilerin dağıtık bir ağ yöntemiyle depolandığı 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 düzeltme kodları kullanmaktadı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 çalışmalarla 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 limit nasıl artırılır (Paradigm)
ne yapılması gerekiyor, neyi dengelememiz gerekiyor?
Kalan ana işler, en azından uygulama geçmişini saklamak için bir somut dağıtık çözüm inşa etmek ve entegre etmek, ama nihayetinde konsensüs ve blob'u da içermektedir. En basit çözüm, mevcut torrent kütüphanesini (i) basitçe entegre etmek ve (ii) Portal Ağı olarak adlandırılan Ethereum yerel çözümünü kullanmaktır. Bunlardan herhangi biri entegre edildiğinde, EIP-4444'ü açabiliriz. EIP-4444'ün kendisi sert bir hard fork gerektirmemektedir, ancak yeni bir ağ protokolü sürümüne ihtiyaç duymaktadır. Bu nedenle, tüm istemciler için aynı anda etkinleştirilmesi değerlidir, aksi takdirde diğer düğümlere bağlanıp tam geçmişi indirmeyi bekleyen istemcilerin aslında almaması durumunda çökme riski vardır.
Ana ticaret, "eski" tarih verilerini sağlama çabamızla ilgilidir. En basit çözüm, yarın eski tarihi saklamayı durdurmak ve mevcut arşiv düğümleri ile çeşitli merkezi sağlayıcılara dayanarak kopyalamaktır. Bu kolaydır, ancak bu, 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, böylece tarihleri dağıtık bir şekilde saklamaktır. Burada, "ne kadar çaba gösteriyoruz" iki boyuta sahiptir:
En büyük düğüm kümesinin gerçekten tüm verileri depoladığından nasıl emin oluyoruz?
Protokole entegre edilen tarihsel depolama derinliğimiz ne kadar derin?
(1) için aşırı bir takıntılı yaklaşım, proof of stake mekanizmasını içerecektir: aslında her stake doğrulayıcısının belirli bir oranda geçmiş kayıtları saklamasını ve bunların bu şekilde yapılıp yapılmadığını düzenli olarak şifreli bir şekilde kontrol etmesini gerektirir. Daha ılımlı bir yaklaşım, her istemci için saklanan geçmiş 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, bunu senkronizasyon sürecine bağlamayı gerektirecektir; böylece, biri 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 elde edebilir.
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, geçmiş depolama gereksinimlerini azaltmak, durumsuzluktan daha önemli denilebilir: Düğümün ihtiyaç duyduğu 1.1 TB'ın yaklaşık 300 GB'ı durum, geri kalan yaklaşık 800 GB'ı ise geçmiş. Sadece durumsuzluğun ve EIP-4444'ün sağlanması, akıllı saatlerde Ethereum düğümü çalıştırmanın ve sadece birkaç dakikada ayarlamanın hayalini gerçekleştirebilir.
Geçmiş depolamanın sınırlanması, daha yeni Ethereum düğümlerinin daha uygulanabilir hale gelmesini sağladı; 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ı tamamen silindiği için artık birçok kod satırını güvenle silebilirsiniz. Hisse kanıtına geçiş tarih haline geldiğinden, istemciler iş kanıtı ile ilgili tüm kodları güvenle silebilirler.
Eyalet süresi dolması
neyi çözüyor?
Müşteri tarafında depolama geçmişinin gereksinimlerini ortadan kaldırmış olsak bile, müşteri depolama ihtiyacı her yıl yaklaşık 50 GB artmaya devam edecek, çünkü durum sürekli büyümekte: hesap bakiyeleri ve rastgele sayılar, sözleşme kodları ve sözleşme depolama. Kullanıcılar, hem mevcut hem de gelecekteki Ethereum müşterilerine kalıcı bir yük getirecek tek seferlik bir ücret ödeyebilir.
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 getirirsek, bazıları bu sorunun o kadar da kötü olmayabileceğini düşünüyor: Sadece özel blok inşaatçı sınıflarının durumu gerçekten depolaması gerekiyor, tüm diğer düğümler (hatta liste üretimini 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 erdirmeyi umabiliriz.
Bu nedir, nasıl çalışır?
Bugün, yeni bir durum nesnesi oluşturduğunuzda (bu, aşağıdaki üç yöntemden biriyle gerçekleşebilir: (i) ETH'yi yeni hesaba göndermek, (ii) kod kullanarak yeni bir hesap oluşturmak, (iii) daha önce dokunulmamış bir depolama slotunu ayarlamak), bu durum nesnesi o durumda sonsuza dek kalır. Aksine, istediğimiz şey nesnelerin zamanla otomatik olarak süresi dolmasıdır. Ana zorluk, bunu üç hedefi gerçekleştirecek bir şekilde yapmaktır:
Verimlilik: Vade sürecini yürütmek için büyük miktarda ek hesaplama gerekmez.
Kullanıcı dostu olma durumu: 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 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 kolaydır. Örneğin, her durum nesnesinin bir son tarih sayacını da saklamasını sağlayabilirsiniz (son tarihi uzatmak için ETH yakarak, bu herhangi bir zamanda okuma veya yazma işlemi sırasında otomatik olarak gerçekleşebilir) ve son tarihi geçen durum nesnelerini silmek için durumları döngü ile kontrol eden bir süreç oluşturabilirsiniz. Ancak bu ek hesaplama (hatta depolama gereksinimi) getirir ve kesinlikle kullanıcı dostu olma gereksinimlerini karşılayamaz. Geliştiricilerin sıfıra sıfırlanan depolama değerlerini içeren kenar durumları üzerinde mantık yürütmesi de zordur. Sözleşme kapsamına bir son tarih sayacı ayarladığınızda, bu teknik olarak geliştiricilerin işini kolaylaştırır, ancak ekonomiyi daha da zorlaştırır: geliştiricilerin sürekli depolama maliyetlerini "kullanıcılara aktar" nasıl yapacaklarını düşünmeleri gerekir.
Bunlar, Ethereum çekirdek geliştirme topluluğunun yıllardır çözmeye çalıştığı sorunlar arasında yer alıyor, "blok zinciri kira" ve "yeniden doğuş" gibi önerileri de kapsıyor. Sonunda, önerilerin en iyi kısımlarını birleştirdik ve iki tür "bilinen en kötü çö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ı durumların süresi dolan teklifleri aynı ilkelere uyar. Durumu bloklara ayırıyoruz. Herkes "en üst harita"yı kalıcı olarak saklar, burada bloklar boş veya dolu olabilir. Her bloktaki veriler, yalnızca o verilere en son erişildiğinde saklanır. Artık saklanmadığında bir "diriltme" mekanizması vardır.
Bu öneriler arasındaki ana farklar şunlardır: (i) "son" ifadesini nasıl tanımladığımız ve (ii) ben
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.
15 Likes
Reward
15
6
Share
Comment
0/400
OnchainGossiper
· 6h ago
İstemci senkronizasyonu gerçekten çok yavaş, kusacak gibi oldum.
Vitalik, The Purge hakkında konuşuyor: Ethereum'un uzun vadeli sürdürülebilirlik yolu
Vitalik: Ethereum'un Olası Geleceği, The Purge
Ethereum'in karşılaştığı bir zorluk, varsayılan olarak, herhangi bir blok zinciri protokolünün genişlemesi ve karmaşıklığının zamanla artmasıdır. Bu, iki alanda gerçekleşir:
Tarihsel veriler: Tarihte 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ün ve senkronizasyon süresinin zamanla artmasına yol açar, zincirin kapasitesi sabit kalsa bile.
Protokol İş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 bu arada, blok zincirini harika yapan temel özelliklerden birini: kalıcılığı korumalıyız. Bir NFT, bir işlem çağrısı verilerinde bir aşk mektubu veya 1 milyon doları içeren bir akıllı sözleşmeyi zincire koyabilir, bir mağaraya on yıl girebilir ve çıktığınızda hala okuyup etkileşimde bulunmanız için orada beklediğini görebilirsiniz. DApp'lerin gönül rahatlığıyla tamamen merkeziyetsiz hale gelmesi ve güncelleme anahtarlarını kaldırması için, bağımlılıklarının kendilerini yok edecek şekilde güncellenmeyeceğinden emin olmaları gerekir - özellikle L1'in kendisi.
Eğer kararlıysek, bu iki talep arasında bir denge sağlamak 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, bazı şanslılar bunu başaramaz. Sosyal sistemler bile çok uzun bir ömre sahip olabilir. Bazı durumlarda, Ethereum başarı elde etti: İş kanıtı ortadan kalktı, SELFDESTRUCT opcode'ları çoğunlukla 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, teknik sürdürülebilirliği ve hatta güvenliği açısından nihai bir meydan okumadır.
The Purge: Ana Hedefler
Müşteri depolama gereksinimlerini azaltarak veya her düğümün tüm geçmiş kayıtlarını veya en son durumu kalıcı olarak depolama gereksinimini ortadan kaldırarak.
Protokol karmaşıklığını azaltmak için gereksiz işlevleri ortadan kaldırarak.
Tarih sonu
neyi çözüyor?
Makalenin yazıldığı tarihte, tamamen senkronize edilmiş Ethereum düğümleri, istemciyi çalıştırmak için yaklaşık 1.1 TB disk alanına ihtiyaç duyar ve ayrıca konsensüs istemcisi için yüzlerce GB disk alanı gereklidir. Bunun büyük bir kısmı tarihle ilgilidir: Tarihi bloklar, işlemler ve makbuzlarla ilgili veriler, çoğu birkaç yıl öncesine aittir. Bu, Gas sınırı hiç artmasa bile, düğüm boyutunun her yıl yüzlerce GB artmaya devam edeceği anlamına gelir.
Bu nedir, nasıl çalışır?
Tarihsel depolama sorununun bir anahtar basitleştirilmiş özelliği, her bloğun bir hash bağlantısı (ve diğer yapılar) aracılığıyla bir önceki bloğa işaret etmesi nedeniyle, mevcut konsensusa ulaşmanın tarihsel konsensusa ulaşmak için yeterli olmasıdır. Ağ, en son blok üzerinde konsensusa 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 birlikte verilebilir 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, tarihte ise 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ı depoladığı bir ağdır. Bu, tohum ağlarının on yıllardır çalışma şeklidir: ağ toplamda milyonlarca dosyayı depolayıp dağıtsa da, her katılımcı yalnızca bunlardan birkaç dosyayı saklayıp dağıtır. Belki de sezgilere ters düşecek şekilde, bu yöntem veri sağlamlığını mutlaka azaltmaz. Düğümlerin çalışma maliyetini daha ekonomik hale getirerek, her bir düğümün rastgele %10'luk bir tarih kaydını sakladığı 100.000 düğümlük bir ağ kurarsak, her veri 10.000 kez kopyalanacaktır - bu, her düğümün her şeyi sakladığı 10.000 düğümlük bir ağ ile tamamen aynı kopyalama faktörü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, 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 tüm içerikleri depolamakla sorumlu olduğu ve ardından eski verilerin dağıtık bir ağ yöntemiyle depolandığı 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 düzeltme kodları kullanmaktadı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 çalışmalarla ne tür bağlantılar var?
ne yapılması gerekiyor, neyi dengelememiz gerekiyor?
Kalan ana işler, en azından uygulama geçmişini saklamak için bir somut dağıtık çözüm inşa etmek ve entegre etmek, ama nihayetinde konsensüs ve blob'u da içermektedir. En basit çözüm, mevcut torrent kütüphanesini (i) basitçe entegre etmek ve (ii) Portal Ağı olarak adlandırılan Ethereum yerel çözümünü kullanmaktır. Bunlardan herhangi biri entegre edildiğinde, EIP-4444'ü açabiliriz. EIP-4444'ün kendisi sert bir hard fork gerektirmemektedir, ancak yeni bir ağ protokolü sürümüne ihtiyaç duymaktadır. Bu nedenle, tüm istemciler için aynı anda etkinleştirilmesi değerlidir, aksi takdirde diğer düğümlere bağlanıp tam geçmişi indirmeyi bekleyen istemcilerin aslında almaması durumunda çökme riski vardır.
Ana ticaret, "eski" tarih verilerini sağlama çabamızla ilgilidir. En basit çözüm, yarın eski tarihi saklamayı durdurmak ve mevcut arşiv düğümleri ile çeşitli merkezi sağlayıcılara dayanarak kopyalamaktır. Bu kolaydır, ancak bu, 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, böylece tarihleri dağıtık bir şekilde saklamaktır. Burada, "ne kadar çaba gösteriyoruz" iki boyuta sahiptir:
En büyük düğüm kümesinin gerçekten tüm verileri depoladığından nasıl emin oluyoruz?
Protokole entegre edilen tarihsel depolama derinliğimiz ne kadar derin?
(1) için aşırı bir takıntılı yaklaşım, proof of stake mekanizmasını içerecektir: aslında her stake doğrulayıcısının belirli bir oranda geçmiş kayıtları saklamasını ve bunların bu şekilde yapılıp yapılmadığını düzenli olarak şifreli bir şekilde kontrol etmesini gerektirir. Daha ılımlı bir yaklaşım, her istemci için saklanan geçmiş 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, bunu senkronizasyon sürecine bağlamayı gerektirecektir; böylece, biri 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 elde edebilir.
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, geçmiş depolama gereksinimlerini azaltmak, durumsuzluktan daha önemli denilebilir: Düğümün ihtiyaç duyduğu 1.1 TB'ın yaklaşık 300 GB'ı durum, geri kalan yaklaşık 800 GB'ı ise geçmiş. Sadece durumsuzluğun ve EIP-4444'ün sağlanması, akıllı saatlerde Ethereum düğümü çalıştırmanın ve sadece birkaç dakikada ayarlamanın hayalini gerçekleştirebilir.
Geçmiş depolamanın sınırlanması, daha yeni Ethereum düğümlerinin daha uygulanabilir hale gelmesini sağladı; 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ı tamamen silindiği için artık birçok kod satırını güvenle silebilirsiniz. Hisse kanıtına geçiş tarih haline geldiğinden, istemciler iş kanıtı ile ilgili tüm kodları güvenle silebilirler.
Eyalet süresi dolması
neyi çözüyor?
Müşteri tarafında depolama geçmişinin gereksinimlerini ortadan kaldırmış olsak bile, müşteri depolama ihtiyacı her yıl yaklaşık 50 GB artmaya devam edecek, çünkü durum sürekli büyümekte: hesap bakiyeleri ve rastgele sayılar, sözleşme kodları ve sözleşme depolama. Kullanıcılar, hem mevcut hem de gelecekteki Ethereum müşterilerine kalıcı bir yük getirecek tek seferlik bir ücret ödeyebilir.
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 getirirsek, bazıları bu sorunun o kadar da kötü olmayabileceğini düşünüyor: Sadece özel blok inşaatçı sınıflarının durumu gerçekten depolaması gerekiyor, tüm diğer düğümler (hatta liste üretimini 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 erdirmeyi umabiliriz.
Bu nedir, nasıl çalışır?
Bugün, yeni bir durum nesnesi oluşturduğunuzda (bu, aşağıdaki üç yöntemden biriyle gerçekleşebilir: (i) ETH'yi yeni hesaba göndermek, (ii) kod kullanarak yeni bir hesap oluşturmak, (iii) daha önce dokunulmamış bir depolama slotunu ayarlamak), bu durum nesnesi o durumda sonsuza dek kalır. Aksine, istediğimiz şey nesnelerin zamanla otomatik olarak süresi dolmasıdır. Ana zorluk, bunu üç hedefi gerçekleştirecek bir şekilde yapmaktır:
Verimlilik: Vade sürecini yürütmek için büyük miktarda ek hesaplama gerekmez.
Kullanıcı dostu olma durumu: 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 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 kolaydır. Örneğin, her durum nesnesinin bir son tarih sayacını da saklamasını sağlayabilirsiniz (son tarihi uzatmak için ETH yakarak, bu herhangi bir zamanda okuma veya yazma işlemi sırasında otomatik olarak gerçekleşebilir) ve son tarihi geçen durum nesnelerini silmek için durumları döngü ile kontrol eden bir süreç oluşturabilirsiniz. Ancak bu ek hesaplama (hatta depolama gereksinimi) getirir ve kesinlikle kullanıcı dostu olma gereksinimlerini karşılayamaz. Geliştiricilerin sıfıra sıfırlanan depolama değerlerini içeren kenar durumları üzerinde mantık yürütmesi de zordur. Sözleşme kapsamına bir son tarih sayacı ayarladığınızda, bu teknik olarak geliştiricilerin işini kolaylaştırır, ancak ekonomiyi daha da zorlaştırır: geliştiricilerin sürekli depolama maliyetlerini "kullanıcılara aktar" nasıl yapacaklarını düşünmeleri gerekir.
Bunlar, Ethereum çekirdek geliştirme topluluğunun yıllardır çözmeye çalıştığı sorunlar arasında yer alıyor, "blok zinciri kira" ve "yeniden doğuş" gibi önerileri de kapsıyor. Sonunda, önerilerin en iyi kısımlarını birleştirdik ve iki tür "bilinen en kötü çözümler" üzerine yoğunlaştık:
Kısmi durum süresi dolumu
Bazı durumların süresi dolan teklifleri aynı ilkelere uyar. Durumu bloklara ayırıyoruz. Herkes "en üst harita"yı kalıcı olarak saklar, burada bloklar boş veya dolu olabilir. Her bloktaki veriler, yalnızca o verilere en son erişildiğinde saklanır. Artık saklanmadığında bir "diriltme" mekanizması vardır.
Bu öneriler arasındaki ana farklar şunlardır: (i) "son" ifadesini nasıl tanımladığımız ve (ii) ben