Ethereum'in karşılaştığı bir zorluk, varsayılan olarak herhangi bir blockchain protokolünün genişlemesi ve karmaşıklığının zamanla artmasıdır. Bu iki şekilde gerçekleşir:
Tarihsel veriler: Tarih boyunca herhangi bir zamanda yapılan işlemler ve oluşturulan hesaplar, tüm istemciler tarafından kalıcı olarak saklanmalı ve herhangi bir yeni istemci 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 Fonksiyonu: 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 vadeli sürdürülebilirliğini sağlamak için, bu iki eğilime güçlü bir karşı baskı uygulamamız gerekiyor, zamanla karmaşıklığı ve genişlemeyi azaltmalıyız. Aynı zamanda, blockchain'i harika yapan anahtar özelliklerden birini: kalıcılığı korumalıyız. NFT'leri, işlem kayıtlarındaki aşk mektuplarını veya 1 milyon dolarlık akıllı sözleşmeleri zincire koyabilirsiniz, 10 yıl sonra hala orada sizi okumak ve etkileşimde bulunmak için bekliyor olacak. DApp'lerin tamamen merkeziyetsiz olmaya ve güncelleme anahtarlarını silmeye gönül rahatlığıyla gitmeleri için, bağımlılıklarının onları mahveden bir şekilde güncellenmeyeceğinden emin olmaları gerekiyor - özellikle L1'in kendisi.
Eğer kararlıyorsak, bu iki talep arasında bir denge kurmak ve sürekliliği korurken şişkinliği, karmaşıklığı ve gerilemeyi en aza indirmek veya tersine çevirmek kesinlikle mümkündür. Organizma bunu yapabilir: Çoğu organizma zamanla yaşlanırken, birkaç şanslı olan yaşlanmaz. Hatta sosyal sistemler de çok uzun bir yaşam süresine sahip olabilir. Bazı durumlarda, Ethereum bu başarıyı elde etti: iş kanıtı ortadan kalktı, SELFDESTRUCT opcode'un çoğu kayboldu ve beacon zinciri düğümleri en fazla altı ay boyunca eski verileri sakladı. Ethereum'un bu yolu daha genel bir şekilde bulması ve uzun vadeli istikrarlı bir nihai sonuca ulaşması, Ethereum'un uzun vadeli ölçeklenebilirliği, teknik sürdürülebilirliği ve hatta güvenliğinin nihai zorluğudur.
The Purge ana hedefi:
İstemci depolama gereksinimlerini azaltarak, her düğümün tüm geçmiş kayıtları hatta nihai durumu kalıcı olarak depolama gereğini azaltma veya ortadan kaldırma yoluyla.
Gereksiz işlevleri ortadan kaldırarak protokol karmaşıklığını azaltmak
Tarih sonu
neyi çözüyor?
Bu makalenin yazıldığı sırada, 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 yüzlerce GB daha disk alanına ihtiyaç vardır. Bunun büyük bir kısmı geçmiş verilerden oluşmaktadır: tarihi bloklar, işlemler ve makbuzlar hakkında 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 gelir.
Bu nedir, nasıl çalışır?
Tarihsel depolama sorunlarının bir anahtarı, her bloğun ( ve diğer yapılar ) aracılığıyla bir önceki bloğa hash bağlantısı ile işaret edilmesidir. Bu nedenle, mevcut konsensüs sağlamak, tarihsel konsensüs sağlamak için yeterlidir. Ağ, en son blok üzerinde konsensüse vardığı sürece, herhangi bir tarihsel blok veya işlem veya durum ( hesap bakiyeleri, rastgele sayılar, kod, depolama ) herhangi bir bireysel katılımcı tarafından ve Merkle kanıtları ile sağlanabilir ve bu kanıt diğer herkesin doğruluğunu doğrulamasına olanak tanır. Konsensüs, N/2-of-N güven modeli iken, tarih N-of-N güven modelidir.
Bu, tarih kayıtlarını nasıl depolayacağı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ıştığı yöntemdir: 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 sezginin tersine, bu yaklaşım verilerin dayanıklılığını azaltmayabilir. Düğümlerin daha ekonomik çalışmasını sağlarsak, her bir düğümün rastgele %10'luk bir tarih kaydını depoladığı 100,000 düğümlük bir ağ kurabiliriz; bu durumda her veri 10,000 kez kopyalanır - bu, her düğümün her şeyi depoladığı 10,000 düğümlük bir ağdaki kopya faktörü ile tamamen aynıdır.
Günümüzde, Ethereum artık tüm düğümlerin tüm geçmişi kalıcı olarak depoladığı modelden kurtulmaya başladı. Konsensüs bloğu (, hisse kanıtı konsensüsü ile ilgili olan kısım ) yalnızca yaklaşık 6 ay depolanmaktadır. Blob yalnızca yaklaşık 18 gün depolanmaktadır. EIP-4444, tarihsel bloklar ve makbuzlar için bir yıllık bir depolama süresi getirmeyi amaçlamaktadır. Uzun vadeli hedef, ( yaklaşık 18 gün olabilecek tek bir dönem oluşturmaktır, bu süre zarfında her düğüm tüm içeriği depolamakla sorumlu olacak ve ardından eski verileri dağıtılmış bir ağ biçiminde depolamak için Ethereum düğümlerinden oluşan bir eşler arası ağ kurulacaktır.
Erasure kodları, kopyalama faktörünü aynı tutarken sağlamlığı artırmak için kullanılabilir. Aslında, Blob zaten veri kullanılabilirlik örneklemesini desteklemek için erasure kodu 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 içine koymaktır.
) mevcut araştırmalarla hangi bağlantılara sahip?
EIP-4444
Torrentler ve EIP-4444
Portal Ağı
Portal ağı ve EIP-4444
Portal'daki SSZ nesnelerinin dağıtık depolanması ve sorgulanması
gas limit nasıl artırılır ### Paradigm (
) ne yapılması gerekiyor, neyi dengelemek gerekiyor?
Kalan ana iş, en azından yürütme geçmişini saklamak için somut bir dağıtılmış çözüm inşa etmek ve entegre etmek — nihayetinde konsensüs ve blob'u da içerecek şekilde. En basit çözüm, mevcut torrent kütüphanesini tanıtmak ve Portal ağı olarak adlandırılan Ethereum yerel çözümünü tanıtmaktır. Bunlardan herhangi biri tanıtıldığında, EIP-4444'ü açabiliriz. EIP-4444'ün kendisi sert bir çatal gerektirmiyor, ancak yeni bir ağ protokolü sürümüne ihtiyaç duyuyor. Bu nedenle, onu tüm istemciler için aynı anda etkinleştirmek değerlidir, aksi takdirde, diğer düğümlere bağlı olan istemcilerin tam geçmişi indirmeyi bekleyip aslında bunu alamamaları nedeniyle arıza riski vardır.
Ana denge, "eski" tarih verilerini sağlamaya nasıl çalıştığımızla ilgilidir. En basit çözüm, yarın eski tarih verilerini saklamayı durdurmak ve mevcut arşiv düğümleri ile çeşitli merkezi sağlayıcılara güvenmektir. Bu kolaydır, ancak Ethereum'un kalıcı bir kayıt yeri olarak konumunu zayıflatır. Daha zor ama daha güvenli bir yol, öncelikle dağıtılmış bir şekilde tarihleri saklamak için torrent ağını inşa etmek ve entegre etmektir. Burada, "ne kadar çok çaba harcıyoruz" iki boyuta sahiptir:
En büyük düğüm kümesinin gerçekten tüm verileri depoladığından nasıl emin oluyoruz?
Protokole entegre ettiğimiz tarihsel depolama derinliği ne kadar derin?
için aşırı bir parnoid yaklaşım, bir yönetim kanıtını içerecektir: aslında her stake proof doğrulayıcısının belirli bir oranında geçmiş kaydını saklamasını ve düzenli olarak bunları şifreli bir şekilde kontrol etmesini talep etmek. Daha ılımlı bir yaklaşım, her istemci tarafından saklanan geçmiş yüzdesi için isteğe bağlı bir standart belirlemektir.
(2) için, temel uygulama sadece bugün tamamlanan çalışmaları 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 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 yoluyla Portal ağından elde edebilirler.
( Diğer yol haritası bölümleriyle nasıl etkileşiyor?
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 azaltmak, durumsuzluktan daha önemli denebilir: düğümün ihtiyaç duyduğu 1.1 TB'da, yaklaşık 300 GB durum, geri kalan yaklaşık 800 GB ise geçmiş haline gelmiştir. Ancak durumsuzluk ve EIP-4444'ün gerçekleştirilmesi, akıllı saatlerde Ethereum düğümlerinin çalıştırılmasını ve sadece birkaç dakika içinde kurulabilmesini sağlama vizyonunu gerçekleştirebilir.
Tarihsel 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ü 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 birçok kod satırı artık güvenli bir şekilde silinebilir. Hisse kanıtına geçiş artık tarih olduğuna göre, müşteriler iş kanıtıyla ilgili tüm kodları güvenli bir şekilde silebilir.
![Vitalik: Ethereum'in Olası Geleceği, The Purge])https://img-cdn.gateio.im/webp-social/moments-b4e683a9e42e4b5bd6991a4cf6cf948e.webp(
Durum süresi dolma
) Ne tür bir sorunu çözüyor?
Müşterinin geçmişi saklama ihtiyacını ortadan kaldırmış olsak bile, müşterinin depolama ihtiyacı her yıl yaklaşık 50 GB artmaya devam edecek, çünkü durum sürekli olarak büyüyor: hesap bakiyeleri ve rastgele 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 "sona ermek" çünkü EVM, temelde böyle bir varsayıma göre 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 durumsuzluk getirirsek, bazıları bu sorunun o kadar kötü olmayabileceğini düşünüyor: yalnızca özel blok oluşturucu sınıflarının durumu gerçekten depolaması gerekiyor, diğer tüm düğümler ( hatta liste oluşturma içerir! ) durumsuz çalışabilir. Ancak, durumsuzluğa fazla bağımlı olmak istemediğimiz bir görüş var; sonuçta, Ethereum'un merkeziyetsizliğini korumak için durumu sona erdirmek isteyebiliriz.
O nedir, nasıl çalışır?
Bugün, yeni bir durum nesnesi oluşturduğunuzda ( aşağıdaki üç şekilde 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 alanını ayarlamak (, bu durum nesnesi her zaman o durumda kalır. Aksine, istediğimiz şey, nesnenin zamanla otomatik olarak süresi dolmasıdır. Ana zorluk, bunu üç hedefi gerçekleştirme şekliyle yapmaktır:
Verimlilik: Vade sürecini yürütmek için büyük miktarda ek hesaplamaya ihtiyaç yoktur.
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 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 sorunsuz bir şekilde çalışmaya devam etmelidir.
Bu hedeflere ulaşamamak, sorunları çözmeyi kolaylaştırır. Örneğin, her durum nesnesinin bir son kullanma tarihi sayacı da saklamasını sağlayabilirsiniz; ), son kullanma tarihini uzatmak için ETH yakılarak gerçekleştirilebilir. Bu, herhangi bir zamanda okunabilir veya yazılabilir ve son kullanma tarihine göre durum nesnelerini silmek için döngüyle geçiş yapan bir süreç olabilir. Ancak, bu ek hesaplama gereksinimleri getirir; (, hatta depolama gereksinimleri ) ve kesinlikle kullanıcı dostu olma gerekliliklerini karşılayamaz. Geliştiricilerin bazen sıfıra sıfırlanan depolama değerleriyle ilgili uç durumları anlaması da zordur. Sözleşme kapsamına bir son kullanma zamanlayıcısı ayarlarsanız, bu teknik olarak geliştiricinin yaşamını kolaylaştırır, ancak ekonomiyi daha zor hale getirir: Geliştiricilerin sürekli depolama maliyetlerini kullanıcıya "aktarmayı" düşünmesi gerekir.
Bunlar, Ethereum çekirdek geliştirme topluluğunun yıllardır çözmeye çalıştığı sorunlardır; "blok zinciri kirası" ve "yeniden doğuş" gibi öneriler de dahil. Sonunda, önerilerin en iyi kısımlarını birleştirdik ve iki tür "bilinen en az kötü çözüm" üzerine odaklandık:
Bazı durumların süresi dolmuş çözümü
Adres döngüsüne dayalı durum sona erme önerisi
( Kısmi durum sona ermesi
Bazı durum sona erme önerileri aynı prensiplere uyar. Durumu parçalara ayırıyoruz. Herkes, boş veya dolu olan parçaları içeren "üst düzey harita"yı kalıcı olarak saklar. Her parçada veri yalnızca en son erişilen veriler saklanır. Saklanmadığında bir "diriliş" mekanizması vardır.
Bu öneriler arasındaki temel farklar şunlardır: )i ) "son zamanlar"ı nasıl tanımladığımız ve (ii ) "blok"u nasıl tanımladığımız? Spesifik bir öneri EIP-7736'dır, bu da Verkle ağacı için tanıtılan "dal yaprağı" tasarımı üzerine inşa edilmiştir ( her ne kadar ikili ağaç gibi herhangi bir biçimde durumsuz durum ile uyumlu olsa da ). Bu tasarımda, birbiriyle komşu olan başlıklar, kodlar ve depolama alanları aynı "gövde" altında saklanır. Bir gövde altında saklanan veriler en fazla 256 * 31 = 7,936 bayt olabilir. Birçok durumda, bir hesabın tüm başlığı ve kodu ile birçok anahtar depolama alanı aynı gövde altında saklanacaktır. Belirli bir gövde altındaki veriler 6 ay boyunca okunmaz veya yazılmazsa, bu veri artık saklanmaz, yalnızca verinin 32 baytı saklanır.
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.
14 Likes
Reward
14
6
Share
Comment
0/400
LadderToolGuy
· 08-01 17:23
Tarih verilerini silmeye cesaret edebiliyorlar.
View OriginalReply0
Ser_APY_2000
· 08-01 13:46
v tanrısı gerçekten iş yapıyor
View OriginalReply0
TrustlessMaximalist
· 07-29 18:30
Vitalik Buterin'in konuşması hala çok sağlam.
View OriginalReply0
ConfusedWhale
· 07-29 18:27
v tanrısı hala bu kadar derin konuşuyor
View OriginalReply0
hodl_therapist
· 07-29 18:17
Eski V'nin söylediklerinde bir sorun yok.
View OriginalReply0
MetaverseLandlord
· 07-29 18:06
Depolama alanı çok pahalı, elinde tutmaktansa silmek daha iyi.
Ethereum The Purge: düşüş tarihsel depolama basitleştirilmiş protokol sürdürülebilirliği artırmak
Ethereum'in Olası Geleceği: The Purge
Yazar: Vitalik Buterin
Ethereum'in karşılaştığı bir zorluk, varsayılan olarak herhangi bir blockchain protokolünün genişlemesi ve karmaşıklığının zamanla artmasıdır. Bu iki şekilde gerçekleşir:
Tarihsel veriler: Tarih boyunca herhangi bir zamanda yapılan işlemler ve oluşturulan hesaplar, tüm istemciler tarafından kalıcı olarak saklanmalı ve herhangi bir yeni istemci 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 Fonksiyonu: 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 vadeli sürdürülebilirliğini sağlamak için, bu iki eğilime güçlü bir karşı baskı uygulamamız gerekiyor, zamanla karmaşıklığı ve genişlemeyi azaltmalıyız. Aynı zamanda, blockchain'i harika yapan anahtar özelliklerden birini: kalıcılığı korumalıyız. NFT'leri, işlem kayıtlarındaki aşk mektuplarını veya 1 milyon dolarlık akıllı sözleşmeleri zincire koyabilirsiniz, 10 yıl sonra hala orada sizi okumak ve etkileşimde bulunmak için bekliyor olacak. DApp'lerin tamamen merkeziyetsiz olmaya ve güncelleme anahtarlarını silmeye gönül rahatlığıyla gitmeleri için, bağımlılıklarının onları mahveden bir şekilde güncellenmeyeceğinden emin olmaları gerekiyor - özellikle L1'in kendisi.
Eğer kararlıyorsak, bu iki talep arasında bir denge kurmak ve sürekliliği korurken şişkinliği, karmaşıklığı ve gerilemeyi en aza indirmek veya tersine çevirmek kesinlikle mümkündür. Organizma bunu yapabilir: Çoğu organizma zamanla yaşlanırken, birkaç şanslı olan yaşlanmaz. Hatta sosyal sistemler de çok uzun bir yaşam süresine sahip olabilir. Bazı durumlarda, Ethereum bu başarıyı elde etti: iş kanıtı ortadan kalktı, SELFDESTRUCT opcode'un çoğu kayboldu ve beacon zinciri düğümleri en fazla altı ay boyunca eski verileri sakladı. Ethereum'un bu yolu daha genel bir şekilde bulması ve uzun vadeli istikrarlı bir nihai sonuca ulaşması, Ethereum'un uzun vadeli ölçeklenebilirliği, teknik sürdürülebilirliği ve hatta güvenliğinin nihai zorluğudur.
The Purge ana hedefi:
Tarih sonu
neyi çözüyor?
Bu makalenin yazıldığı sırada, 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 yüzlerce GB daha disk alanına ihtiyaç vardır. Bunun büyük bir kısmı geçmiş verilerden oluşmaktadır: tarihi bloklar, işlemler ve makbuzlar hakkında 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 gelir.
Bu nedir, nasıl çalışır?
Tarihsel depolama sorunlarının bir anahtarı, her bloğun ( ve diğer yapılar ) aracılığıyla bir önceki bloğa hash bağlantısı ile işaret edilmesidir. Bu nedenle, mevcut konsensüs sağlamak, tarihsel konsensüs sağlamak için yeterlidir. Ağ, en son blok üzerinde konsensüse vardığı sürece, herhangi bir tarihsel blok veya işlem veya durum ( hesap bakiyeleri, rastgele sayılar, kod, depolama ) herhangi bir bireysel katılımcı tarafından ve Merkle kanıtları ile sağlanabilir ve bu kanıt diğer herkesin doğruluğunu doğrulamasına olanak tanır. Konsensüs, N/2-of-N güven modeli iken, tarih N-of-N güven modelidir.
Bu, tarih kayıtlarını nasıl depolayacağı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ıştığı yöntemdir: 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 sezginin tersine, bu yaklaşım verilerin dayanıklılığını azaltmayabilir. Düğümlerin daha ekonomik çalışmasını sağlarsak, her bir düğümün rastgele %10'luk bir tarih kaydını depoladığı 100,000 düğümlük bir ağ kurabiliriz; bu durumda her veri 10,000 kez kopyalanır - bu, her düğümün her şeyi depoladığı 10,000 düğümlük bir ağdaki kopya faktörü ile tamamen aynıdır.
Günümüzde, Ethereum artık tüm düğümlerin tüm geçmişi kalıcı olarak depoladığı modelden kurtulmaya başladı. Konsensüs bloğu (, hisse kanıtı konsensüsü ile ilgili olan kısım ) yalnızca yaklaşık 6 ay depolanmaktadır. Blob yalnızca yaklaşık 18 gün depolanmaktadır. EIP-4444, tarihsel bloklar ve makbuzlar için bir yıllık bir depolama süresi getirmeyi amaçlamaktadır. Uzun vadeli hedef, ( yaklaşık 18 gün olabilecek tek bir dönem oluşturmaktır, bu süre zarfında her düğüm tüm içeriği depolamakla sorumlu olacak ve ardından eski verileri dağıtılmış bir ağ biçiminde depolamak için Ethereum düğümlerinden oluşan bir eşler arası ağ kurulacaktır.
Erasure kodları, kopyalama faktörünü aynı tutarken sağlamlığı artırmak için kullanılabilir. Aslında, Blob zaten veri kullanılabilirlik örneklemesini desteklemek için erasure kodu 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 içine koymaktır.
) mevcut araştırmalarla hangi bağlantılara sahip?
) ne yapılması gerekiyor, neyi dengelemek gerekiyor?
Kalan ana iş, en azından yürütme geçmişini saklamak için somut bir dağıtılmış çözüm inşa etmek ve entegre etmek — nihayetinde konsensüs ve blob'u da içerecek şekilde. En basit çözüm, mevcut torrent kütüphanesini tanıtmak ve Portal ağı olarak adlandırılan Ethereum yerel çözümünü tanıtmaktır. Bunlardan herhangi biri tanıtıldığında, EIP-4444'ü açabiliriz. EIP-4444'ün kendisi sert bir çatal gerektirmiyor, ancak yeni bir ağ protokolü sürümüne ihtiyaç duyuyor. Bu nedenle, onu tüm istemciler için aynı anda etkinleştirmek değerlidir, aksi takdirde, diğer düğümlere bağlı olan istemcilerin tam geçmişi indirmeyi bekleyip aslında bunu alamamaları nedeniyle arıza riski vardır.
Ana denge, "eski" tarih verilerini sağlamaya nasıl çalıştığımızla ilgilidir. En basit çözüm, yarın eski tarih verilerini saklamayı durdurmak ve mevcut arşiv düğümleri ile çeşitli merkezi sağlayıcılara güvenmektir. Bu kolaydır, ancak Ethereum'un kalıcı bir kayıt yeri olarak konumunu zayıflatır. Daha zor ama daha güvenli bir yol, öncelikle dağıtılmış bir şekilde tarihleri saklamak için torrent ağını inşa etmek ve entegre etmektir. Burada, "ne kadar çok çaba harcıyoruz" iki boyuta sahiptir:
En büyük düğüm kümesinin gerçekten tüm verileri depoladığından nasıl emin oluyoruz?
Protokole entegre ettiğimiz tarihsel depolama derinliği ne kadar derin?
için aşırı bir parnoid yaklaşım, bir yönetim kanıtını içerecektir: aslında her stake proof doğrulayıcısının belirli bir oranında geçmiş kaydını saklamasını ve düzenli olarak bunları şifreli bir şekilde kontrol etmesini talep etmek. Daha ılımlı bir yaklaşım, her istemci tarafından saklanan geçmiş yüzdesi için isteğe bağlı bir standart belirlemektir.
(2) için, temel uygulama sadece bugün tamamlanan çalışmaları 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 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 yoluyla Portal ağından elde edebilirler.
( Diğer yol haritası bölümleriyle nasıl etkileşiyor?
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 azaltmak, durumsuzluktan daha önemli denebilir: düğümün ihtiyaç duyduğu 1.1 TB'da, yaklaşık 300 GB durum, geri kalan yaklaşık 800 GB ise geçmiş haline gelmiştir. Ancak durumsuzluk ve EIP-4444'ün gerçekleştirilmesi, akıllı saatlerde Ethereum düğümlerinin çalıştırılmasını ve sadece birkaç dakika içinde kurulabilmesini sağlama vizyonunu gerçekleştirebilir.
Tarihsel 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ü 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 birçok kod satırı artık güvenli bir şekilde silinebilir. Hisse kanıtına geçiş artık tarih olduğuna göre, müşteriler iş kanıtıyla ilgili tüm kodları güvenli bir şekilde silebilir.
![Vitalik: Ethereum'in Olası Geleceği, The Purge])https://img-cdn.gateio.im/webp-social/moments-b4e683a9e42e4b5bd6991a4cf6cf948e.webp(
Durum süresi dolma
) Ne tür bir sorunu çözüyor?
Müşterinin geçmişi saklama ihtiyacını ortadan kaldırmış olsak bile, müşterinin depolama ihtiyacı her yıl yaklaşık 50 GB artmaya devam edecek, çünkü durum sürekli olarak büyüyor: hesap bakiyeleri ve rastgele 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 "sona ermek" çünkü EVM, temelde böyle bir varsayıma göre 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 durumsuzluk getirirsek, bazıları bu sorunun o kadar kötü olmayabileceğini düşünüyor: yalnızca özel blok oluşturucu sınıflarının durumu gerçekten depolaması gerekiyor, diğer tüm düğümler ( hatta liste oluşturma içerir! ) durumsuz çalışabilir. Ancak, durumsuzluğa fazla bağımlı olmak istemediğimiz bir görüş var; sonuçta, Ethereum'un merkeziyetsizliğini korumak için durumu sona erdirmek isteyebiliriz.
O nedir, nasıl çalışır?
Bugün, yeni bir durum nesnesi oluşturduğunuzda ( aşağıdaki üç şekilde 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 alanını ayarlamak (, bu durum nesnesi her zaman o durumda kalır. Aksine, istediğimiz şey, nesnenin zamanla otomatik olarak süresi dolmasıdır. Ana zorluk, bunu üç hedefi gerçekleştirme şekliyle yapmaktır:
Verimlilik: Vade sürecini yürütmek için büyük miktarda ek hesaplamaya ihtiyaç yoktur.
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 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 sorunsuz bir şekilde çalışmaya devam etmelidir.
Bu hedeflere ulaşamamak, sorunları çözmeyi kolaylaştırır. Örneğin, her durum nesnesinin bir son kullanma tarihi sayacı da saklamasını sağlayabilirsiniz; ), son kullanma tarihini uzatmak için ETH yakılarak gerçekleştirilebilir. Bu, herhangi bir zamanda okunabilir veya yazılabilir ve son kullanma tarihine göre durum nesnelerini silmek için döngüyle geçiş yapan bir süreç olabilir. Ancak, bu ek hesaplama gereksinimleri getirir; (, hatta depolama gereksinimleri ) ve kesinlikle kullanıcı dostu olma gerekliliklerini karşılayamaz. Geliştiricilerin bazen sıfıra sıfırlanan depolama değerleriyle ilgili uç durumları anlaması da zordur. Sözleşme kapsamına bir son kullanma zamanlayıcısı ayarlarsanız, bu teknik olarak geliştiricinin yaşamını kolaylaştırır, ancak ekonomiyi daha zor hale getirir: Geliştiricilerin sürekli depolama maliyetlerini kullanıcıya "aktarmayı" düşünmesi gerekir.
Bunlar, Ethereum çekirdek geliştirme topluluğunun yıllardır çözmeye çalıştığı sorunlardır; "blok zinciri kirası" ve "yeniden doğuş" gibi öneriler de dahil. Sonunda, önerilerin en iyi kısımlarını birleştirdik ve iki tür "bilinen en az kötü çözüm" üzerine odaklandık:
( Kısmi durum sona ermesi
Bazı durum sona erme önerileri aynı prensiplere uyar. Durumu parçalara ayırıyoruz. Herkes, boş veya dolu olan parçaları içeren "üst düzey harita"yı kalıcı olarak saklar. Her parçada veri yalnızca en son erişilen veriler saklanır. Saklanmadığında bir "diriliş" mekanizması vardır.
Bu öneriler arasındaki temel farklar şunlardır: )i ) "son zamanlar"ı nasıl tanımladığımız ve (ii ) "blok"u nasıl tanımladığımız? Spesifik bir öneri EIP-7736'dır, bu da Verkle ağacı için tanıtılan "dal yaprağı" tasarımı üzerine inşa edilmiştir ( her ne kadar ikili ağaç gibi herhangi bir biçimde durumsuz durum ile uyumlu olsa da ). Bu tasarımda, birbiriyle komşu olan başlıklar, kodlar ve depolama alanları aynı "gövde" altında saklanır. Bir gövde altında saklanan veriler en fazla 256 * 31 = 7,936 bayt olabilir. Birçok durumda, bir hesabın tüm başlığı ve kodu ile birçok anahtar depolama alanı aynı gövde altında saklanacaktır. Belirli bir gövde altındaki veriler 6 ay boyunca okunmaz veya yazılmazsa, bu veri artık saklanmaz, yalnızca verinin 32 baytı saklanır.