Ethereum'in Olası Geleceği: The Purge

14 Ekim'den itibaren, Ethereum'un kurucusu Vitalik Buterin, Ethereum'un gelecekteki gelişimi hakkında bir dizi tartışma makalesi yayımladı; "The Merge"dan en son "The Purge"a kadar, Ethereum ana ağının gelecekteki gelişimi konusundaki görüşlerini ve mevcut sorunları çözme önerilerini sergiliyor.

"The Purge" makalesi, Ethereum'un uzun vadede karmaşıklığı ve depolama gereksinimlerini nasıl azaltabileceğini, aynı zamanda zincirin sürekliliğini ve merkeziyetsizliğini koruyabileceğini incelemektedir. Ana önlemler, "tarihsel sona erme" ve "durum sona erme" aracılığıyla istemci depolama yükünü azaltmak ve "özellik temizliği" ile protokolü basitleştirerek ağın sürdürülebilirliğini ve ölçeklenebilirliğini sağlamak üzerinedir.

Tarih sona erme tarih kayıtları

neyi çözüyor?

Şu anda tam senkronize bir Ethereum düğümünün istemciyi çalıştırmak için yaklaşık 1.1TB disk alanına ihtiyacı var, ayrıca konsensüs istemcisi için de yüzlerce GB gerekmektedir. Bunun büyük kısmı tarihi verilerdir; Gas limiti değişmese bile, düğüm boyutu her yıl yüzlerce GB artacaktır.

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

Tarihsel depolamanın bir ana özelliği, mevcut konsensüsün tarihsel konsensüsü sağlamak için yeterli olmasıdır. Bu, her bir düğümün yalnızca bir kısmını depoladığı bir ağ gibi tarih kayıtlarını depolamak için çeşitli seçenekler sunar.

Ethereum, tüm düğümlerin tüm geçmişi kalıcı olarak depolama modelinden kurtulmaya başladı. Konsensüs blokları yaklaşık 6 ay, Blob'lar ise yaklaşık 18 gün depolanıyor. EIP-4444, tarih blokları ve makbuzlar için bir yıllık depolama süresi getirmeyi amaçlıyor. Uzun vadeli hedef, yaklaşık 18 günlük bir birleşik depolama süresi oluşturmak ve ardından eski verileri dağıtılmış şekilde depolamak için Ethereum düğümlerinden oluşan bir P2P ağı kurmaktır.

Erasure kodları, aynı kopyalama faktörünü korurken sağlamlığı artırmak için kullanılabilir. En basit çözüm, Blob'un mevcut silme kodunu yeniden kullanmak ve yürütme ile konsensüs blok verilerini de blob'a koymak olabilir.

Ne yapmamız gerekiyor, neyi dengelememiz gerekiyor?

Ana çalışmalar, geçmişi depolamak için belirli bir dağıtık çözümün inşası ve entegrasyonunu içermektedir. En basit çözüm, mevcut torrent kütüphanesini veya Portal ağı olarak adlandırılan Ethereum yerel çözümünü tanıtmaktır.

Ana denge, "eski" tarih verilerini sağlama çabasıyla ilgilidir. En basit çözüm, eski tarihlerin depolanmasını hemen durdurmak ve mevcut arşiv düğümlerine güvenmektir. Daha güvenli ama daha zor bir çözüm ise öncelikle bir torrent ağı inşa etmek ve entegre etmektir.

ile yol haritasının diğer kısımları arasındaki etkileşim

Geçmiş depolama gereksinimlerini azaltmak, düğümlerin çalıştırılmasını son derece kolay hale getirmek için kritik öneme sahiptir. Sadece durumsuzluk ve EIP-4444'ün gerçekleştirilmesi, akıllı saatlerde Ethereum düğümü çalıştırma vizyonunu gerçekleştirebilir.

Tarihsel depolama kısıtlaması, yalnızca en son protokol sürümünü destekleyen yeni Ethereum düğümlerinin daha uygulanabilir hale gelmesini sağladığından, istemciyi basitleştirir.

Durum süresi doldu

hangi sorunu çözüyor?

Geçmiş kayıt depolama gereksinimi ortadan kaldırıldığında bile, istemci depolama gereksinimi her yıl yaklaşık 50GB artmaya devam edecek, çünkü durum ( hesap bakiyesi, sözleşme kodu vb. ) sürekli olarak artacaktır. Kullanıcılar tek seferlik bir ödeme yapabilir, bu da mevcut ve gelecekteki müşterilere kalıcı bir yük getirecektir.

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

Durum, tarihten daha zor olan "sona erme"dir, çünkü EVM durum nesnelerinin bir kez oluşturulduktan sonra sonsuza kadar var olduğunu varsayar. Amaç, nesnelerin zamanla otomatik olarak sona ermesini sağlarken verimliliği, kullanıcı dostuluğunu ve geliştirici dostuluğunu korumaktır.

Başlıca iki tür çözüm vardır:

1. Kısmi durum süresi doldu: Durumu parçalara ayırın, yalnızca en son erişilen verileri saklayın. EIP-7736, Verkle ağacı temelli bir çözümü öneriyor, 6 ay boyunca erişilmeyen veriler yalnızca 32 baytlık bir kök saklar.

2. Adres döngüsüne dayalı durum sona ermesi: Sürekli büyüyen durum ağacı listesini kullanarak her yıl yeni boş ağaç eklenir. Tam düğümler yalnızca en son iki ağacı tutar. Süresi dolmuş verilerin okunması ve yazılması için kanıt sağlanması gerekir.

ne yapmam gerekiyor, neyi dengelemem gerekiyor?

Gelecekteki olası yollar şunlardır:

1. Durumsuzluğu sağlamak, durumu süre sonunda tanıtmamak. Durum sürekli artar ancak yalnızca özel kullanıcıların depolamasına ihtiyaç vardır.

2. Kısmi durumun sona ermesini sağlamak, daha düşük ama sıfır olmayan kalıcı durum büyüme oranını kabul etmek.

3. Adres alanı genişletmesi ile durumun süresinin dolması sağlanır. Adres formatı dönüşümünün güvenli ve etkili bir şekilde sağlanması için yıllar süren bir süreç gereklidir.

4. Adres alanı daraltması yoluyla durumun süresinin dolması sağlanır. Tüm güvenlik risklerinin çözülmesini sağlamak için yıllar süren bir süreç gereklidir.

Hangi çözümün benimsenirse benimsensin, adres alanının genişletilmesi ve daraltılması sorununu çözmek gerekecek, çünkü gelecekte adres çakışması saldırıları daha kolay hale gelecektir.

Özellik temizliği

hangi sorunu çözüyor?

Protokolün basitliği güvenlik, erişilebilirlik ve güvenilir tarafsızlık için anahtardır. Ancak protokoller zamanla karmaşık hale gelme eğilimindedir. Fonksiyonları kaldırabilme ve karmaşıklığı azaltabilme yeteneğine ihtiyacımız var.

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

Protokol karmaşıklığını azaltacak tek bir büyük düzeltme yoktur, bunun yerine birçok küçük çözüm gereklidir. Bazı önemli örnekler şunlardır:

• RLP → SSZ dönüşümü: Daha iyi bir SSZ ile RLP kodlamasını değiştir
• Eski işlem türünü sil
• LOG reformu: Kullanılmayan Bloom filtreleri gibi işlevlerin silinmesi
• Beacon Chain Senkronizasyon Komitesi mekanizmasını kaldır
• Veri formatı birleştirildi
• Beacon Chain Komitesini Sil
• Karmaşık bayt sırasını kaldır

EVM'deki bazı örnekler:

• Gas mekanizması basitleştirildi
• Önceden derlenmişi sil
• gaz gözlemliliğini kaldır
• Statik analiz iyileştirmesi: dinamik atlamaları kaldır

Daha ne yapmamız gerekiyor, neyi dengelememiz gerekiyor?

Ana denge, basitlik ve hız ile geriye dönük uyumluluk arasındadır. Acil olmayan geriye dönük uyumluluk bozucu değişiklikler için etki analizini, resmi EIP kullanım dışı bırakmayı, son silmeyi vb. adımları içeren standart bir süreç oluşturulması gerekmektedir.

EVM nesne formatı ( EOF ) bir dizi EVM değişikliği önerdi, hedef daha fazla yükseltmeye izin vermektir. Artan karmaşıklık ile tüm EVM'yi basitleştirme hedefi arasında dengelenmesi gerekiyor.

Daha radikal bir yaklaşım, protokolün çoğu içeriğini sözleşme koduna dönüştürmektir; örneğin EVM'yi toplulaştırmak veya EVM yerine yeni bir VM kullanmaktır. Bu, protokolü büyük ölçüde basitleştirebilir, ancak uyumluluk açısından bir denge sağlanması gerekir.