Ethereum'in Olası Geleceği: The Purge

Yazar: Vitalik Buterin

Derleme: Nasıl

Özellikle Justin Drake, Tim Beiko, Matt Garnett, Piper Merriam, Marius van der Wijden ve Tomasz Stanczak'ın geri bildirimleri ve incelemeleri için teşekkür ederim.

Ethereum'in karşılaştığı zorluklardan biri, varsayılan olarak herhangi bir blockchain 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 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 indirilmelidir, böylece tamamen ağa senkronize edilir. Bu, istemci yükünün ve senkronizasyon süresinin zamanla sürekli artmasına yol açar, 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 yol açar.

Ethereum'un uzun vadede sürdürülebilir olabilmesi için, bu iki trende güçlü bir ters etki uygulamamız gerekiyor, zamanla karmaşıklığı ve genişlemeyi azaltmalıyız. Ancak aynı zamanda, blok zincirini harika kılan temel özelliklerden birini de korumalıyız: kalıcılık. Bir NFT, bir işlem çağrısı verisindeki bir aşk mektubu veya 1 milyon dolarlık bir akıllı sözleşmeyi zincire koyabilirsiniz, bir mağaraya girip on yıl sonra çıktığınızda, hala okumanız ve etkileşimde bulunmanız için orada beklediğini görebilirsiniz. DApp'lerin tamamen merkeziyetsiz bir şekilde upgrade anahtarını güvenle silmeleri için, bağımlılıklarının kendilerini yok edecek şekilde yükselmeyeceğinden emin olmaları gerekir - özellikle L1'in kendisi.

Eğer kararlıysak, 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. Organizmalar bunu yapabilir: Çoğu organizma zamanla yaşlansa da, şanslı bir avuç kişi yaşlanmaz. Sosyal sistemler bile çok uzun bir yaşam süresine sahip olabilir. Bazı durumlarda, Ethereum başarı elde etmiştir: İş kanıtı kayboldu, SELFDESTRUCT opcode'ları büyük ölçüde kayboldu, beacon zinciri düğümleri en fazla altı aylık eski verileri sakladı. 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, teknolojik sürdürülebilirliği ve hatta güvenliğinin nihai zorluğudur.

The Purge: Ana hedefler.

İstemci depolama gereksinimlerini azaltmak için, her düğümün tüm geçmiş kayıtları hatta nihai durumu kalıcı olarak depolama gereksinimini azaltmak veya ortadan kaldırmak.

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

Makale Dizini:

Geçmiş süresi doldu

Durumun sona ermesi

Özellik temizliği

Geçmiş süresi

Hangi sorunu çözüyor?

Bu yazının kaleme alındığı sırada, tamamen senkronize bir Ethereum düğümünün istemcinin çalıştırılması için yaklaşık 1.1 TB disk alanına ihtiyaç duyduğu ve ayrıca konsensüs istemcisi için yüzlerce GB disk alanına ihtiyaç duyduğu belirtilmektedir. Bunun büyük bir kısmı tarihe aittir: 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ün boyutunun her yıl yüzlerce GB artmaya devam edeceği anlamına gelmektedir.

Bu 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 veya durum (hesap bakiyesi, rastgele sayı, kod, depolama) herhangi bir bireysel katılımcı tarafından sağlanabilir ve Merkle kanıtı ile desteklenebilir 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, tarihsel kayıtları nasıl depolayacağımız konusunda birçok seçenek sunuyor. Doğal bir seçim, her düğümün yalnızca verilerin küçük bir kısmını depoladığı bir ağdır. İşte bu, tohum ağlarının on yıllardır çalışma şeklidir: Ağ toplamda milyonlarca dosya depolayıp dağıtsa da, her katılımcı yalnızca bunların birkaçını depolar ve dağıtır. Belki de sezgiye ters olarak, bu yöntem verilerin dayanıklılığını mutlaka azaltmaz. Düğümlerin çalıştırılmasını daha ekonomik hale getirerek, her düğümün rastgele %10'luk tarihsel kaydı depoladığı 100.000 düğümlük bir ağ kurabiliriz; bu durumda, her veri 10.000 kez kopyalanmış olur - bu, her düğümün her şeyi depoladığı 10.000 düğümlü bir ağa kıyasla tam olarak 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 her şeyi depolamakla sorumlu olduğu ve ardından eski verilerin dağıtılmış bir ağ şeklinde depolandığı, Ethereum düğümlerinden oluşan merkeziyetsiz bir 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ılabilirlik örneklemesini desteklemek için hata düzeltme kodları (Erasure 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 araştırmalarla hangi bağlantılar var?

EIP-4444；

Torrents ve EIP-4444；

Portal Ağı;

Portal Ağı ve EIP-4444;

Portal'daki SSZ nesnelerinin dağıtık depolama ve sorgulama;

Gas limitini nasıl artırırım (Paradigm).

Ne yapmamız gerekiyor, neyi dengelemeliyiz?

Kalan ana iş, geçmişi saklamak için belirli bir dağıtık çözüm inşa etmek ve entegre etmekten oluşmaktadır ------ en azından yürütme geçmişi, ancak nihayetinde konsensüs ve blob'u da içermektedir. En basit çözüm, (i) mevcut torrent kütüphanelerini basitçe tanıtmaktır ve (ii) olarak adlandırılan Portal ağına Ethereum yerel çözümünü de dahil etmektedir. Bunlardan herhangi biri tanıtıldığında, EIP-4444'ü açabiliriz. EIP-4444 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ırken tam geçmişi indirmeyi bekleyen istemcilerin başarısız olma riski bulunmaktadır.

Ana denge, "eski" tarih verilerini sağlama çabamızla ilgilidir. En basit çözüm, yarın eski tarihleri depolamayı durdurmak ve mevcut arşiv düğümleri ile çeşitli merkezi sağlayıcılara güvenerek kopyalama yapmaktı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, önce torrent ağını inşa etmek ve entegre etmek, tarihi 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 depoladığından nasıl emin oluyoruz?

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

(1) için aşırı bir saplantılı yaklaşım, bir yönetim kanıtını içerecektir: aslında her bir hisse kanıtı doğrulayıcısının belirli bir oranda geçmiş verileri saklamasını ve düzenli olarak bunları şifreli bir şekilde kontrol etmesini gerektirir. Daha ılımlı bir yaklaşım, her istemcinin sakladığı geçmiş yüzdesi için gönüllü bir standart belirlemektir.

(2) için, temel uygulama sadece bugün tamamlanan çalışmaları içermektedir: Portal, tüm Ethereum tarihini içeren ERA dosyasını zaten depoladı. Daha kapsamlı bir uygulama, onu senkronizasyon sürecine gerçek anlamda 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 elde edebilirler.

Diğer yol haritası kısımlarıyla nasıl etkileşir?

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 haline gelmiştir. Durumsuzluğun ve EIP-4444'ün sağlanması, akıllı saatlerde Ethereum düğümlerinin çalıştırılmasını ve sadece birkaç dakika içinde kurulabilmesini sağlama vizyonunu gerçekleştirebilir.

Geçmiş depolamanın sınırlanması, daha yeni Ethereum düğümlerinin uygulanmasını daha mümkün kılmakta, yalnızca protokolün en son sürümünü desteklemekte ve bu da onları daha basit hale getirmektedir. Örneğin, 2016'daki DoS saldırısı sırasında oluşturulan boş depolama alanlarının tamamı silindiği için şimdi 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.

Durum süresi doldu

Hangi sorunu çözüyor?

Müşterinin depolama geçmişini elimine etsek 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 rasgele 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 getirmek için tek seferlik bir ücret ödeyebilir.

Durumun "sona ermesi" tarihi olmaktan daha zor, çünkü EVM temelde şu 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 durumsuzluk getirirsek, bazıları bu sorunun çok da kötü olmadığı düşünüyor: Sadece özel blok inşaatçı sınıflarının durumu gerçekten saklaması gerekirken, tüm diğer düğümler (hatta liste üretimi de dahil!) durumsuz olarak çalışabilir. Ancak, durumsuzluğa fazla bağımlı olmak istemediğimiz yönünde bir görüş var; nihayetinde, Ethereum'un merkezsizliğini korumak için durumu sona erdirmek isteyebiliriz.

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

Bugün, yeni bir durum nesnesi oluşturduğunuzda (bu, aşağıdaki üç yoldan biriyle gerçekleşebilir: (i) yeni bir hesaba ETH göndermek, (ii) kod kullanarak yeni bir hesap oluşturmak, (iii) daha önce hiç dokunulmayan bir depolama yuvası ayarlamak), bu durum nesnesi o durumda sonsuza dek kalır. Aksine, istediğimiz şey nesnelerin zamanla otomatik olarak süresinin dolmasıdır. Temel zorluk, bunu üç hedefi gerçekleştirecek şekilde yapmaktır:

Verimlilik: Vadesi dolma 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ğ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 şekilde çalışmaya devam etmesi gerekir.

Bu hedeflere ulaşmamak, sorunları çözmeyi kolaylaştırır. Örneğin, her durum nesnesinin bir sona erme tarihi sayacı da depolamasını sağlayabilirsiniz (bu süreyi uzatmak için ETH yakılarak, bu herhangi bir okuma veya yazma işlemi sırasında otomatik olarak gerçekleşebilir) ve sona erme tarihini silmek için durumu döngüsel olarak tarayan bir süreç olabilir. 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ı ile ilgili köşe durumlarını anlaması da zordur. Sözleşme kapsamındaki bir sona erme sayacı ayarlarsanız, bu teknik olarak geliştiricilerin yaşamını kolaylaştırır, ancak ekonomiyi daha karmaşık hale getirir: geliştiriciler sürekli depolama maliyetini 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 "yeniden doğuş" gibi öneriler de dahil. Sonunda, önerilerin en iyi kısımlarını bir araya getirdik ve "bilinen en az kötü çözümler" olarak iki kategoriye odaklandı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 "üst düzey harita"yı kalıcı olarak depolar, bunun içinde