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 yönde gerçekleşir:
Geçmiş veriler: Herhangi bir zamanda yapılan işlemler ve oluşturulan hesaplar, tüm istemciler tarafından kalıcı olarak saklanmalı ve yeni istemciler tarafından tamamen ağa senkronize edilmek üzere indirilmelidir. Bu, istemci yükünü ve senkronizasyon süresini sürekli olarak artırır, 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'ın 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ığı korumalıyız. NFT'leri, aşk mektuplarını veya içinde 1.000.000 dolar bulunan akıllı sözleşmeleri zincire koyabilir, on yıl boyunca bir mağaraya girebilir ve çıktığınızda hala orada beklediğini görürsünüz. DApp'lerin tamamen merkeziyetsiz olmasına ve güncelleme anahtarlarını kaldırmasına izin vermek 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ıysak, bu iki talep arasında bir denge kurabilir ve sürekliliği korurken aşırılığı, karmaşıklığı ve gerilemeyi en aza indirip tersine çevirebiliriz. Organizmalara bunu yapabilir: Çoğu organizma zamanla yaşlansa da, birkaç şanslı olan yaşlanmaz. Sosyal sistemler bile çok uzun ömürlü olabilir. Bazı durumlarda, Ethereum başarı elde etti: İş kanıtı ortadan kalktı, SELFDESTRUCT opcode'unun çoğu kayboldu, beacon chain düğümleri en fazla altı ay boyunca 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ğinin nihai meydan okumasıdır.
The Purge: Ana hedef.
İstemci depolama gereksinimlerini, her düğümün tüm geçmiş kayıtları veya nihai durumu kalıcı olarak depolama gereğini azaltarak veya ortadan kaldırarak düşürmek.
Protokol karmaşıklığını gereksiz işlevleri ortadan kaldırarak azaltın.
Makale Dizini:
Geçmiş süresi doldu( tarih kayıtları süresi doldu)
Durum süresi doldu ( durum süresi doldu )
Özellik temizliği(特征清理)
Geçmiş son tarihi
Hangi sorunu çözüyor?
Bu makalenin yazıldığı tarihte, tamamen senkronize bir Ethereum düğümünün çalıştırılması 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ı gerekiyor. Bunun büyük bir kısmı geçmişe aittir: geçmiş bloklar, işlemler ve makbuzlar hakkında veriler, bunların büyük bir kısmı yıllardır mevcut. Bu, Gas sınırları hiç artmasa bile, düğümün 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 bir anahtar basitleştirilmiş özelliği, her bloğun ( ve diğer yapılar ) aracılığıyla bir önceki bloğa hash ile bağlı olması nedeniyle, mevcut uzlaşmaya ulaşmak için tarihe uzlaşmaya ulaşmanın yeterli olmasıdır. Ağ, en son blok üzerinde uzlaşıya 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 doğrulanabilir ve bu kanıt başkalarının doğruluğunu kontrol etmesine izin verir. Uzlaşma N/2-of-N güven modeli iken, tarih N-of-N güven modelidir.
Bu, tarih kayıtlarını nasıl depolayacağımıza birçok seçenek sunar. 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ıştığı şekildir: ağ toplamda milyonlarca dosya depolayıp dağıtsa da, her bir katılımcı yalnızca bunlardan birkaçını depolar ve dağıtır. Belki de sezgiye aykırı olarak, bu yöntem verilerin sağlamlığını azaltmak zorunda değildir. Düğümlerin çalıştırılmasını daha ekonomik hale getirerek, her bir düğümün rastgele %10'luk bir tarih kaydını depoladığı 100.000 düğümlük bir ağ kurabiliyorsak, o zaman 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 sakladığı modelden kurtulmaya başladı. Konsensüs bloğu (, 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, tarihi bloklar ve makbuzlar için bir yıllık saklama süresi getirmeyi amaçlamaktadır. Uzun vadeli hedef, her düğümün her şeyi saklamaktan sorumlu olduğu ve ardından eski verilerin dağıtık bir ağ şeklinde saklandığı Ethereum düğümlerinden oluşan merkezi olmayan bir ağ kurmayı içeren birleşik bir dönem oluşturmak olabilir; bu dönem ( yaklaşık 18 gün olabilir ).
Erasure kodları, kopya faktörünü aynı tutarken dayanıklılığı 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 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;
Portal Ağı;
Portallar Ağı ve EIP-4444;
Portal'daki SSZ nesnelerinin dağıtık depolaması ve sorgulanması;
Gas limit nasıl artırılır ( Paradigm ).
Daha ne yapmamız gerekiyor, neyi dengelememiz gerekiyor?
Kalan ana işler, geçmiş verileri depolamak için belirli bir dağıtılmış çözümün inşasını ve entegrasyonunu içerir ------ en azından işlem geçmişi, ancak nihayetinde konsensüs ve blob da dahil olacaktır. En basit çözüm, mevcut torrent kütüphanelerini (i) basit bir şekilde dahil etmek ve (ii) Ethereum'un yerel çözümü olan Portal ağıdır. Bunlardan herhangi biri dahil edildikten sonra, EIP-4444'ü açabiliriz. EIP-4444 kendisi 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ştirmek değerlidir, aksi takdirde diğer düğümlere bağlanarak tam geçmişi indirmeyi bekleyen istemcilerin 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 tarihlerin depolanmasını durdurmak ve mevcut arşiv düğümlerine ve çeşitli merkezi sağlayıcılara kopyalama için güvenmektir. 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 ise önce bir torrent ağı inşa etmek ve entegre etmek, tarihi verileri dağıtık bir şekilde depolamaktır. Burada, "ne kadar çabalıyoruz" 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ğimiz ne kadar derin?
( için aşırı bir paranoyak yaklaşım, bir güvence kanıtı gerektirecektir: aslında her bir stake doğrulayıcısının belirli bir oranında geçmiş kayıtları saklamasını ve düzenli olarak bunları şifreli bir şekilde kontrol etmesini istemektedir. Daha ılımlı bir yaklaşım, her istemci için saklanan geçmiş yüzdesi için gönüllü bir standart belirlemektir.
) 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, eğer birisi tam tarih kaydı depolama 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 ile Portal ağından elde edebilirler.
(# Diğer yol haritası bölümleriyle nasıl etkileşimde bulunur?
Eğer düğümlerin çalıştırılmasını veya başlatılmasını son derece kolay hale getirmek istiyorsak, o zaman geçmiş depolama gereksinimlerini azaltmanın, durumsuzluktan daha önemli olduğunu söyleyebiliriz: Düğümün ihtiyaç duyduğu 1.1 TB'nın yaklaşık 300 GB'ı durum, geri kalan yaklaşık 800 GB'ı ise geçmiş olmuştur. Sadece durumsuzluğu ve EIP-4444'ü gerçekleştirerek, akıllı saatlerde Ethereum düğümlerinin çalıştırılmasına ve sadece birkaç dakika içinde ayarlanmasına yönelik vizyonu gerçekleştirebiliriz.
Geçmiş depolamanın kısıtlanması, daha yeni Ethereum düğümlerinin uygulanmasını daha mümkün hale getiriyor, yalnızca protokolün en son sürümünü destekliyor, 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 silinmiş olması nedeniyle artık birçok kod satırını güvenle kaldırmak mümkün. Hisse kanıtına geçiş tarih haline geldiğinden, müşteriler iş kanıtıyla ilgili tüm kodları güvenle kaldırabilir.
) Devlet süresi
Hangi sorunu çözüyor?
Müşteri tarafında geçmiş kayıtları saklama gereğini ortadan kaldırmış olsak bile, müşteri depolama ihtiyacı her yıl yaklaşık 50 GB artarak devam edecek, çünkü durum sürekli 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üşterilerine kalıcı bir yük getirmek için tek seferlik bir ücret ödeyebilir.
Durum, tarihten daha zor "son kullanma tarihi"dir, çü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 getirecek olursak, bazıları bu sorunun belki de o kadar kötü olmadığını düşünüyor: yalnızca özel blok inşaatçı sınıfları durumları gerçek anlamda saklamak zorunda kalacak ve diğer tüm düğümler ### hatta liste oluşturma içerir! ### durumsuz çalışabilir. Ancak, fazla durumsuzluğa bağımlı olmak istemediğimiz görüşü var, nihayetinde Ethereum'un merkeziyetsizliğini korumak için durumu geçersiz kılmayı umabiliriz.
(# Bu nedir, nasıl çalışır?
Bugün, yeni bir durum nesnesi oluşturduğunuzda ) aşağıdaki üç şekilde birine gerçekleşebilir: ### i ( yeni hesaba ETH göndermek, ( ii ) kod kullanarak yeni hesap oluşturmak, ( iii ) daha önce erişilmemiş bir depolama alanını ayarlamak, ( bu durum nesnesi her zaman bu durumda kalır. Aksine, istediğimiz nesnenin zamanla otomatik olarak sona ermesidir. Ana zorluk, bunu üç hedefi gerçekleştirecek şekilde yapmaktır:
Verimlilik: Vade sürecini çalıştırmak 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şimlerini kaybetmemelidir...
Geliştirici dostluğu: Geliştiricilerin tamamen tanımadıkları bir düşünce modeline geçmeleri gerekmez. Ayrıca, şu anda katılaşmış ve güncellenmeyen uygulamalar normal bir şekilde çalışmaya devam edebilmelidir.
Bu hedeflere ulaşmamak, sorunları çözmeyi kolaylaştırır. Örneğin, her durum nesnesinin bir son kullanma tarihi sayacı ) depolamasını sağlayabilirsiniz; bu sayacı ETH yakarak uzatmak mümkündür ve bu, herhangi bir zamanda okuma veya yazma işlemi sırasında otomatik olarak gerçekleşebilir ) ve son kullanma tarihini kaldırmak için durum nesnelerini döngü ile işleyen bir süreç vardır. Ancak bu, ek hesaplama ( ve hatta depolama gereksinimleri ) getirir ve kesinlikle kullanıcı dostu olma gereksinimlerini karşılamaz. Geliştiriciler, bazen sıfıra sıfırlanan depolama değerleriyle ilgili kenar durumlarını anlamakta zorlanıyorlar. Eğer sözleşme kapsamına bir son kullanma sayacı ayarlarsanız, bu teknik olarak geliştiricilerin hayatını kolaylaştırır, ancak ekonomiyi daha da zorlaştırır: Geliştiriciler, sürekli depolama maliyetlerini kullanıcıya nasıl "aktarmaları" gerektiğini düşünmek zorundadır.
Bunlar, Ethereum çekirdek geliştirme topluluğunun yıllardır çözmeye çalıştığı sorunlardır; "blok zinciri kirası" ve "yenilenme" gibi öneriler de dahil. Sonunda, önerilerin en iyi kısımlarını bir araya getirdik ve iki tür "bilinen en az kötü çözüm" üzerine odaklandık:
Kısmi durum sona ermiş çö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 harita"yı kalıcı olarak depolar, burada bloklar boş veya doludur. Her bloktaki veriler yalnızca en son erişilen veriler depolanır. Eğer artık depolanmazsa, bir "yeniden canlandırma" mekanizması vardır.
Bu öneriler arasındaki temel farklar şunlardır: )i ### "son zamanlar"ı nasıl tanımlıyoruz ve (ii ) "blok"u nasıl tanımlıyoruz? Belirli bir öneri EIP-7736'dır, bu öneri Verkle ağaçları için getirilen "dal yaprağı" tasarımına dayanmaktadır ( her ne kadar ikili ağaçlar gibi herhangi bir biçimde durumsuz durumlarla uyumlu olsa da ). Bu tasarımda, yan yana olan başlıklar, kodlar ve depolama slotları aynı "gövde" altında saklanmaktadır. Bir dal altında saklanan veriler en fazla 256 * 31 = 7,936 olabilir.
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: Uzun Vadeli Sürdürülebilir Bir Blok Zinciri Ekosistemi Oluşturma
Ethereum'in 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 yönde gerçekleşir:
Geçmiş veriler: Herhangi bir zamanda yapılan işlemler ve oluşturulan hesaplar, tüm istemciler tarafından kalıcı olarak saklanmalı ve yeni istemciler tarafından tamamen ağa senkronize edilmek üzere indirilmelidir. Bu, istemci yükünü ve senkronizasyon süresini sürekli olarak artırır, 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'ın 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ığı korumalıyız. NFT'leri, aşk mektuplarını veya içinde 1.000.000 dolar bulunan akıllı sözleşmeleri zincire koyabilir, on yıl boyunca bir mağaraya girebilir ve çıktığınızda hala orada beklediğini görürsünüz. DApp'lerin tamamen merkeziyetsiz olmasına ve güncelleme anahtarlarını kaldırmasına izin vermek 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ıysak, bu iki talep arasında bir denge kurabilir ve sürekliliği korurken aşırılığı, karmaşıklığı ve gerilemeyi en aza indirip tersine çevirebiliriz. Organizmalara bunu yapabilir: Çoğu organizma zamanla yaşlansa da, birkaç şanslı olan yaşlanmaz. Sosyal sistemler bile çok uzun ömürlü olabilir. Bazı durumlarda, Ethereum başarı elde etti: İş kanıtı ortadan kalktı, SELFDESTRUCT opcode'unun çoğu kayboldu, beacon chain düğümleri en fazla altı ay boyunca 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ğinin nihai meydan okumasıdır.
The Purge: Ana hedef.
İstemci depolama gereksinimlerini, her düğümün tüm geçmiş kayıtları veya nihai durumu kalıcı olarak depolama gereğini azaltarak veya ortadan kaldırarak düşürmek.
Protokol karmaşıklığını gereksiz işlevleri ortadan kaldırarak azaltın.
Makale Dizini:
Geçmiş süresi doldu( tarih kayıtları süresi doldu) Durum süresi doldu ( durum süresi doldu ) Özellik temizliği(特征清理)
Geçmiş son tarihi
Hangi sorunu çözüyor?
Bu makalenin yazıldığı tarihte, tamamen senkronize bir Ethereum düğümünün çalıştırılması 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ı gerekiyor. Bunun büyük bir kısmı geçmişe aittir: geçmiş bloklar, işlemler ve makbuzlar hakkında veriler, bunların büyük bir kısmı yıllardır mevcut. Bu, Gas sınırları hiç artmasa bile, düğümün 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 bir anahtar basitleştirilmiş özelliği, her bloğun ( ve diğer yapılar ) aracılığıyla bir önceki bloğa hash ile bağlı olması nedeniyle, mevcut uzlaşmaya ulaşmak için tarihe uzlaşmaya ulaşmanın yeterli olmasıdır. Ağ, en son blok üzerinde uzlaşıya 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 doğrulanabilir ve bu kanıt başkalarının doğruluğunu kontrol etmesine izin verir. Uzlaşma N/2-of-N güven modeli iken, tarih N-of-N güven modelidir.
Bu, tarih kayıtlarını nasıl depolayacağımıza birçok seçenek sunar. 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ıştığı şekildir: ağ toplamda milyonlarca dosya depolayıp dağıtsa da, her bir katılımcı yalnızca bunlardan birkaçını depolar ve dağıtır. Belki de sezgiye aykırı olarak, bu yöntem verilerin sağlamlığını azaltmak zorunda değildir. Düğümlerin çalıştırılmasını daha ekonomik hale getirerek, her bir düğümün rastgele %10'luk bir tarih kaydını depoladığı 100.000 düğümlük bir ağ kurabiliyorsak, o zaman 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 sakladığı modelden kurtulmaya başladı. Konsensüs bloğu (, 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, tarihi bloklar ve makbuzlar için bir yıllık saklama süresi getirmeyi amaçlamaktadır. Uzun vadeli hedef, her düğümün her şeyi saklamaktan sorumlu olduğu ve ardından eski verilerin dağıtık bir ağ şeklinde saklandığı Ethereum düğümlerinden oluşan merkezi olmayan bir ağ kurmayı içeren birleşik bir dönem oluşturmak olabilir; bu dönem ( yaklaşık 18 gün olabilir ).
Erasure kodları, kopya faktörünü aynı tutarken dayanıklılığı 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 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;
Portal Ağı;
Portallar Ağı ve EIP-4444;
Portal'daki SSZ nesnelerinin dağıtık depolaması ve sorgulanması;
Gas limit nasıl artırılır ( Paradigm ).
Daha ne yapmamız gerekiyor, neyi dengelememiz gerekiyor?
Kalan ana işler, geçmiş verileri depolamak için belirli bir dağıtılmış çözümün inşasını ve entegrasyonunu içerir ------ en azından işlem geçmişi, ancak nihayetinde konsensüs ve blob da dahil olacaktır. En basit çözüm, mevcut torrent kütüphanelerini (i) basit bir şekilde dahil etmek ve (ii) Ethereum'un yerel çözümü olan Portal ağıdır. Bunlardan herhangi biri dahil edildikten sonra, EIP-4444'ü açabiliriz. EIP-4444 kendisi 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ştirmek değerlidir, aksi takdirde diğer düğümlere bağlanarak tam geçmişi indirmeyi bekleyen istemcilerin 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 tarihlerin depolanmasını durdurmak ve mevcut arşiv düğümlerine ve çeşitli merkezi sağlayıcılara kopyalama için güvenmektir. 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 ise önce bir torrent ağı inşa etmek ve entegre etmek, tarihi verileri dağıtık bir şekilde depolamaktır. Burada, "ne kadar çabalıyoruz" 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ğimiz ne kadar derin?
( için aşırı bir paranoyak yaklaşım, bir güvence kanıtı gerektirecektir: aslında her bir stake doğrulayıcısının belirli bir oranında geçmiş kayıtları saklamasını ve düzenli olarak bunları şifreli bir şekilde kontrol etmesini istemektedir. Daha ılımlı bir yaklaşım, her istemci için saklanan geçmiş yüzdesi için gönüllü bir standart belirlemektir.
) 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, eğer birisi tam tarih kaydı depolama 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 ile Portal ağından elde edebilirler.
(# Diğer yol haritası bölümleriyle nasıl etkileşimde bulunur?
Eğer düğümlerin çalıştırılmasını veya başlatılmasını son derece kolay hale getirmek istiyorsak, o zaman geçmiş depolama gereksinimlerini azaltmanın, durumsuzluktan daha önemli olduğunu söyleyebiliriz: Düğümün ihtiyaç duyduğu 1.1 TB'nın yaklaşık 300 GB'ı durum, geri kalan yaklaşık 800 GB'ı ise geçmiş olmuştur. Sadece durumsuzluğu ve EIP-4444'ü gerçekleştirerek, akıllı saatlerde Ethereum düğümlerinin çalıştırılmasına ve sadece birkaç dakika içinde ayarlanmasına yönelik vizyonu gerçekleştirebiliriz.
Geçmiş depolamanın kısıtlanması, daha yeni Ethereum düğümlerinin uygulanmasını daha mümkün hale getiriyor, yalnızca protokolün en son sürümünü destekliyor, 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 silinmiş olması nedeniyle artık birçok kod satırını güvenle kaldırmak mümkün. Hisse kanıtına geçiş tarih haline geldiğinden, müşteriler iş kanıtıyla ilgili tüm kodları güvenle kaldırabilir.
) Devlet süresi
Hangi sorunu çözüyor?
Müşteri tarafında geçmiş kayıtları saklama gereğini ortadan kaldırmış olsak bile, müşteri depolama ihtiyacı her yıl yaklaşık 50 GB artarak devam edecek, çünkü durum sürekli 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üşterilerine kalıcı bir yük getirmek için tek seferlik bir ücret ödeyebilir.
Durum, tarihten daha zor "son kullanma tarihi"dir, çü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 getirecek olursak, bazıları bu sorunun belki de o kadar kötü olmadığını düşünüyor: yalnızca özel blok inşaatçı sınıfları durumları gerçek anlamda saklamak zorunda kalacak ve diğer tüm düğümler ### hatta liste oluşturma içerir! ### durumsuz çalışabilir. Ancak, fazla durumsuzluğa bağımlı olmak istemediğimiz görüşü var, nihayetinde Ethereum'un merkeziyetsizliğini korumak için durumu geçersiz kılmayı umabiliriz.
(# Bu nedir, nasıl çalışır?
Bugün, yeni bir durum nesnesi oluşturduğunuzda ) aşağıdaki üç şekilde birine gerçekleşebilir: ### i ( yeni hesaba ETH göndermek, ( ii ) kod kullanarak yeni hesap oluşturmak, ( iii ) daha önce erişilmemiş bir depolama alanını ayarlamak, ( bu durum nesnesi her zaman bu durumda kalır. Aksine, istediğimiz nesnenin zamanla otomatik olarak sona ermesidir. Ana zorluk, bunu üç hedefi gerçekleştirecek şekilde yapmaktır:
Verimlilik: Vade sürecini çalıştırmak 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şimlerini kaybetmemelidir...
Geliştirici dostluğu: Geliştiricilerin tamamen tanımadıkları bir düşünce modeline geçmeleri gerekmez. Ayrıca, şu anda katılaşmış ve güncellenmeyen uygulamalar normal bir şekilde çalışmaya devam edebilmelidir.
Bu hedeflere ulaşmamak, sorunları çözmeyi kolaylaştırır. Örneğin, her durum nesnesinin bir son kullanma tarihi sayacı ) depolamasını sağlayabilirsiniz; bu sayacı ETH yakarak uzatmak mümkündür ve bu, herhangi bir zamanda okuma veya yazma işlemi sırasında otomatik olarak gerçekleşebilir ) ve son kullanma tarihini kaldırmak için durum nesnelerini döngü ile işleyen bir süreç vardır. Ancak bu, ek hesaplama ( ve hatta depolama gereksinimleri ) getirir ve kesinlikle kullanıcı dostu olma gereksinimlerini karşılamaz. Geliştiriciler, bazen sıfıra sıfırlanan depolama değerleriyle ilgili kenar durumlarını anlamakta zorlanıyorlar. Eğer sözleşme kapsamına bir son kullanma sayacı ayarlarsanız, bu teknik olarak geliştiricilerin hayatını kolaylaştırır, ancak ekonomiyi daha da zorlaştırır: Geliştiriciler, sürekli depolama maliyetlerini kullanıcıya nasıl "aktarmaları" gerektiğini düşünmek zorundadır.
Bunlar, Ethereum çekirdek geliştirme topluluğunun yıllardır çözmeye çalıştığı sorunlardır; "blok zinciri kirası" ve "yenilenme" gibi öneriler de dahil. Sonunda, önerilerin en iyi kısımlarını bir araya getirdik ve iki tür "bilinen en az kötü çözüm" üzerine odaklandık:
(# Kısmi durum süresi dolması
Bazı durum sona erme önerileri aynı ilkelere uyar. Durumları bloklara ayırıyoruz. Herkes "üst düzey harita"yı kalıcı olarak depolar, burada bloklar boş veya doludur. Her bloktaki veriler yalnızca en son erişilen veriler depolanır. Eğer artık depolanmazsa, bir "yeniden canlandırma" mekanizması vardır.
Bu öneriler arasındaki temel farklar şunlardır: )i ### "son zamanlar"ı nasıl tanımlıyoruz ve (ii ) "blok"u nasıl tanımlıyoruz? Belirli bir öneri EIP-7736'dır, bu öneri Verkle ağaçları için getirilen "dal yaprağı" tasarımına dayanmaktadır ( her ne kadar ikili ağaçlar gibi herhangi bir biçimde durumsuz durumlarla uyumlu olsa da ). Bu tasarımda, yan yana olan başlıklar, kodlar ve depolama slotları aynı "gövde" altında saklanmaktadır. Bir dal altında saklanan veriler en fazla 256 * 31 = 7,936 olabilir.