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:

Tarihsel veriler: Tarih boyunca herhangi bir zamanda gerçekleştirilen herhangi bir işlem ve oluşturulan herhangi bir hesap, tüm istemciler tarafından kalıcı olarak saklanmalı ve herhangi bir yeni istemci tarafından indirilmelidir, böylece ağa tamamen senkronize olur. Bu, istemci yükünün ve senkronizasyon süresinin zamanla sürekli 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 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, aynı zamanda blok zincirini harika yapan temel özelliklerden birini de korumalıyız: kalıcılık. Bir NFT, bir ticaret görüşmesindeki bir aşk mektubu ya da 1 milyon dolar içeren bir akıllı sözleşmeyi zincir üzerine koyabilirsiniz, on yıl bir mağaraya girebilir ve çıktığınızda hala okunmayı ve etkileşimde bulunmayı beklediğini görebilirsiniz. DApp'lerin tamamen merkeziyetsiz bir şekilde güvenle hareket etmeleri ve güncelleme anahtarlarını silmeleri için, bağımlılıklarının kendilerini yok edecek şekilde güncellenmeyeceğinden emin olmaları gerekir - özellikle L1'in kendisi.

Eğer bu iki talep arasında bir denge sağlamaya ve sürekliliği korurken şişkinliği, karmaşıklığı ve gerilemeyi en aza indirmeye veya tersine çevirmeye kararlıysak, bu kesinlikle mümkündür. Organizmalar bunu başarabilir: Çoğu organizma zamanla yaşlansa da, bazı şanslılar bunu başaramaz. Hatta toplumsal sistemler de çok uzun bir ömre sahip olabilir. Bazı durumlarda, Ethereum başarı elde etmiştir: İş kanıtı kaybolmuş, SELFDESTRUCT işlem kodu büyük ölçüde ortadan kalkmış ve işaret zinciri düğümleri en fazla altı ay boyunca eski verileri depolamıştır. Ethereum için bu yolu daha genel bir şekilde bulmak ve uzun vadeli istikrarlı bir sonuca doğru ilerlemek, Ethereum'un uzun vadeli ölçeklenebilirliğinin, teknik sürdürülebilirliğinin ve hatta güvenliğinin nihai zorluğudur.

The Purge: Ana Hedef.

Her bir düğümün tüm geçmiş kayıtları veya nihai durumu kalıcı olarak depolama gereksinimini azaltarak veya ortadan kaldırarak istemci depolama gereksinimlerini azaltmak.

Protokol karmaşıklığını azaltmak için gereksiz işlevleri ortadan kaldırarak.

Makalelerin dizini:

Tarih sona erme（历史记录到期）

Durum süresi doldu

Özellik temizliği

Tarih sona erme

hangi sorunu çözüyor?

Bu yazının 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 yüzlerce GB disk alanına ihtiyaç var. Bunun büyük bir kısmı geçmişe ait: geçmiş bloklar, işlemler ve makbuzlarla ilgili veriler, bunların çoğu yıllardır mevcut. Bu, Gas sınırı artmasa bile, düğüm boyutunun her yıl yüzlerce GB artmaya devam edeceği anlamına geliyor.

O nedir, nasıl çalışır?

Tarihsel depolama sorunlarının bir anahtarı, her bloğun hash bağlantıları (ve diğer yapılar) aracılığıyla bir önceki bloğa işaret etmesi nedeniyle, mevcut 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 ya da durum (hesap bakiyesi, rastgele sayı, kod, depolama) herhangi bir bireysel katılımcı tarafından sağlanabilir ve Merkle kanıtı ile desteklenebilir; bu kanıt, diğer herkesin doğru olduğunu doğrulamasını sağlar. 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 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 katılımcı yalnızca bunlardan birkaçını depolayıp dağıtır. Belki de sezgimize ters olarak, bu yaklaşım veri sağlamlığını azaltmak zorunda bile değildir. Düğümlerin çalışmasını daha ekonomik hale getirerek, her 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 kopyalanmış olur - 10.000 düğümlük bir ağda, her düğümün her şeyi depoladığı kopya 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 blokları (yani, hisse kanıtı konsensüsü ile ilgili kısım) yalnızca yaklaşık 6 ay saklanır. Blob yalnızca yaklaşık 18 gün saklanır. EIP-4444, tarihsel bloklar ve makbuzlar için bir yıllık saklama süresi getirmeyi amaçlamaktadır. Uzun vadeli hedef, her düğümün tüm içeriği saklamaktan sorumlu olduğu, ardından eski verilerin dağıtılmış bir ağ biçiminde saklandığı Ethereum düğümlerinden oluşan bir eşler arası ağ oluşturmak için yaklaşık 18 gün sürecek tek bir dönem kurmaktır.

Erasure kodları, çoğaltma faktörünü aynı tutarken dayanıklılığı artırmak için kullanılabilir. Aslında, Blob zaten veri kullanılabilirliği örneklemesini desteklemek için hata düzeltme kodları içermektedir. En basit çözüm muhtemelen bu Erasure kodlarını yeniden kullanmak ve işlemleri ve konsensüs blok verilerini de blob'a koymaktır.

mevcut araştırmalarla hangi bağlantılara sahip?

EIP-4444；

Torrents ve EIP-4444；

Portal Ağı;

Portal Ağı ve EIP-4444;

Portal'daki SSZ nesnelerinin dağıtık depolama ve alma işlemleri;

Gas limitini nasıl artırabilirim (Paradigm).

Hala ne yapmamız gerekiyor, neyi dengelememiz gerekiyor?

Kalan ana işler, en azından yürütme geçmişi için bir dağıtık çözüm oluşturmak ve entegre etmek, ancak nihayetinde konsensüs ve blob'u da içerecek şekilde tarihleri depolamak için bir çözüm inşa etmeyi içeriyor. En basit çözüm, mevcut torrent kütüphanelerini (i) basitçe tanıtmak ve (ii) adı verilen Ethereum'a özgü bir çözüm olan Portal ağını tanıtmaktır. Bu ikisinden birini tanıttığımızda, 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, tüm istemciler için aynı anda etkinleştirilmesi değerlidir, aksi takdirde istemcilerin diğer düğümlere bağlanarak tam geçmişi indirmeyi bekleyip aslında alamadıkları durumlarda arızalanma riski vardır.

Ana ticaret, "eski" tarih verilerini sağlamak için ne kadar çaba sarf ettiğimizle ilgilidir. En basit çözüm, yarın eski tarihi depolamayı durdurmak ve mevcut arşiv düğümleri ile çeşitli merkezi sağlayıcılara dayanarak çoğaltmaktır. Bu kolaydır ama Ethereum'un kalıcı bir kayıt yeri olarak konumunu zayıflatır. Daha zor ama daha güvenli bir yol, önce torrent ağını inşa edip entegre ederek tarihleri dağıtık bir şekilde depolamaktır. Burada, "ne kadar çaba sarf ediyoruz" iki boyuta sahiptir:

En büyük düğüm kümesinin gerçekten tüm verileri sakladığından emin olmak için ne yapıyoruz?

Protokole entegre edilen tarihsel depolama derinliği ne kadar derin?

(1) için aşırı bir takıntılı yaklaşım, yönetim kanıtını içerecektir: aslında her bir stake doğrulayıcısının belirli bir oranda geçmiş verileri depolamasını ve bunu düzenli olarak şifreli bir şekilde kontrol etmesini talep etmektedir. 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 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ı içerecektir; böylece, eğer 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 ile Portal ağından gerçekleştirebilir.

Diğer yol haritası bölümleriyle nasıl etkileşimde bulunur?

Eğer düğümlerin çalışmasını veya başlatılmasını son derece kolay hale getirmek istiyorsak, geçmiş depolama gereksinimlerini azaltmak, durumsuzluktan daha önemli denebilir: Düğümün ihtiyaç duyduğu 1.1 TB'ın yaklaşık 300 GB'ı durum, geri kalan yaklaşık 800 GB ise geçmişte kalmıştır. Ancak durumsuzluğun ve EIP-4444'ün gerçekleştirilmesi, akıllı saatlerde Ethereum düğümünü çalıştırma ve sadece birkaç dakika içinde kurulum yapma vizyonunu 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ü destekliyor, bu da onları daha basit hale getiriyor. Örneğin, 2016 yılında gerçekleşen DoS saldırısı sırasında oluşturulan boş depolama alanlarının tamamen silinmesi nedeniyle birçok kod satırını güvenle kaldırmak mümkün. Hisse ispatına geçiş artık tarih olduğuna göre, kullanıcılar iş kanıtı ile ilgili tüm kodları güvenle kaldırabilirler.

Durum süresi

hangi sorunu çözüyor?

Müşteri tarafında tarih kaydını tutma ihtiyacını ortadan kaldırmış olsak bile, müşteri tarafındaki 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, mevcut ve gelecekteki Ethereum istemcilerine kalıcı bir yük getirmek için tek seferlik bir ücret ödeyebilir.

Durum, tarihten daha zor "sona ermek" çünkü EVM temelde şöyle bir varsayıma dayanarak 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 yapılandırıcı sınıflarının durumu gerçekten saklaması gerekirken, diğer tüm düğümler (hatta liste oluşturma dahil!) 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 erdirmek isteyebiliriz.

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) yeni bir hesaba ETH göndermek, (ii) kod kullanarak yeni bir hesap oluşturmak, (iii) daha önce kullanılmamış bir depolama yuvası ayarlamak), bu durum nesnesi o durumda sonsuza kadar kalır. Bunun yerine, istediğimiz şey, nesnelerin zamanla otomatik olarak süresinin dolmasıdır. Temel zorluk, bunu üç hedefle uyumlu bir şekilde başarmaktır:

Verimlilik: Vade sürecini işletmek için büyük miktarda ek hesaplama gerektirmez.

Kullanıcı dostu: Eğer biri beş yıl boyunca bir mağaraya girip geri dönerse, ETH, ERC20, NFT, CDP pozisyonlarına erişimlerini kaybetmemelidir...

Geliştirici dostu olma: 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 bir şekilde çalışmaya devam etmesi gerekir.

Bu hedefleri karşılamıyorsanız, sorunları çözmek oldukça kolaydır. Örneğin, her durum nesnesinin ayrıca bir son kullanma tarihi sayacı saklamasını sağlayabilirsiniz (son kullanma tarihini uzatmak için ETH yakarak, bu herhangi bir zamanda okuma veya yazma sırasında otomatik olarak gerçekleşebilir) ve son kullanma tarihi olan durum nesnelerini silmek için durumları döngü ile geçiren bir süreç oluşturabilirsiniz. Ancak bu, ek hesaplama (hatta depolama gereksinimleri) 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ı içinde bir son kullanma zamanlayıcısı belirlerseniz, bu teknik olarak geliştiricilerin hayatını kolaylaştırır, ancak ekonomiyi daha karmaşık hale getirir: geliştiricilerin sürekli depolama maliyetlerini "kullanıcılara" nasıl aktaracaklarını düşünmeleri gerekir.

Bunlar, Ethereum çekirdek geliştirme topluluğunun yıllardır çözmeye çalıştığı sorunlardır; bunlar arasında "blok zinciri kirası" ve "yeniden doğma" gibi öneriler bulunmaktadır. Sonuç olarak, önerilerin en iyi kısımlarını birleştirdik ve "bilinen en kötü olmayan çözümler" kategorisi üzerinde yoğunlaştık:

• Bazı durumların 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 kalıcı olarak "üst düzey harita"yı depolar,