Orijinal yazar: EthStorage
Orijinal kaynak: Geek Web3
Özet:
· EIP-4844'ten bu yana, Ethereum ağının veri çıkışı ve depolama baskısı her geçen gün artıyor. Artan depolama gereksinimleri, Ethereum düğümlerine büyük zorluklar getirdi. Depolama baskısını azaltmak için bazı Ethereum istemcileri, yerel olarak depolanan Ethereum geçmiş verilerini siler ve farklı tam düğümlerin depolama davranışındaki tutarlılık yavaş yavaş bozulur.
· Tüm Ethereum istemcilerinin davranış konusunda fikir birliğine varmalarını sağlamak için, EIP-4444 ve EIP-4844, geçmiş veri silme davranışını standartlaştırmıştır ve gelecekte Ethereum düğümlerinin standart konfigürasyonu haline gelecektir.
· Bu nedenle, en son Katman1 veya Katman2 durumunu geri yüklemek için geçmiş verileri yeniden oynatmak istiyorsanız, Ethereum protokolü dışındaki merkezi hizmet tesislerine güvenmelisiniz, bu da insanları Ethereum çözümüyle tutarlı daha merkezi olmayan depolamayı keşfetmeye teşvik eder.
· Ethereum Portal ağı, geçmiş veriler de dahil olmak üzere her türlü Ethereum verisine uygun, hafif, merkezi olmayan bir P2P ağıdır. Kaynakları kısıtlı cihazlar için tasarlanmıştır ve Ethereum JSON-RPC hizmetleri sağlar. Tarih Ağı ve Beacon Zinciri Ağı neredeyse hazır.
· EthStorage, EIP-4844 BLOB verileri için teşvik edilmiş bir modüler depolama ağıdır. BLOB'u depolamak için kullanıcılar L1'deki depolama sözleşmesini çağırabilir, depolama ücreti olarak ETH'yi kullanabilir ve BLOB'un hash değerini zincire kaydedebilir. Zamanla, depolama ücretleri, zincir dışı BLOB depolamanın kanıtını sağlayan depolama hizmeti sağlayıcılarına kademeli olarak dağıtılacaktır.
· EthStorage test ağı şu anda Ethereum Sepolia test ağında çalışıyor ve birden fazla topluluk katılımcısı yerel depolama durumlarını başarıyla kanıtladı. Gelecek planları arasında merkezi olmayan bir Ethereum durum ağının geliştirilmesi, dinamik olarak boyutlandırılmış veriler için depolama kanıtının etkinleştirilmesi ve EthStorage ağına doğrudan tarayıcıdan merkezi olmayan erişimin sağlanması yer alıyor.
Teşekkür: Bu makale hakkında geri bildirimde bulunan Ethereum Vakfı'ndan Piper Merriam'a, Polychain'den Karthik Raju'ya ve EthStorage'dan Qiang Zhu'ya teşekkür ederiz.
Arka plan
arka plan:
22 Ekim 2023'te, Go-Ethereum'un (Geth) tanınmış geliştirme lideri Péter Szilágyi, Ethereum'un veri depolama çözümü hakkındaki endişelerini Twitter'da dile getirdi. Geth istemcisinin tüm geçmiş verileri korurken Nethermind ve Besu gibi diğer Ethereum istemci türlerinin belirli Ethereum geçmiş verilerini (geçmiş blokları gibi) silmek üzere yapılandırılabileceğini belirtti. Bu, bazı istemci düğümlerinin diğer istemcilerle tutarsız davranmasına neden olur ve bu da Geth istemci operatörlerine haksızlık olur. Yukarıdaki konu, Ethereum yol haritasındaki depolama çözümü hakkında hararetli bir tartışmayı hemen tetikledi.
Depolama Zorluğu
Depolama zorlukları
Nethermind ve Besu neden müşteri operatörlerinin yerel geçmiş verilerini silmesine izin veriyor? Bu karar hangi konuları yansıtıyor? Bizim açımızdan bunun iki temel nedeni var:
Ethereum istemcilerinin depolama gereksinimleri giderek daha zorlu hale geliyor.
Ethereum geçmiş verilerini depolamak için protokol içi teşvikler veya cezalar yoktur.
İlk neden, Ethereum istemcilerinin artan depolama ihtiyaçlarından kaynaklanıyor. Aşağıdaki pasta grafiği, 13 Aralık 2023 itibarıyla 18.779.761 blok yüksekliğine sahip yeni bir Geth düğümünün depolama dağılımını göstermektedir.
resimde gösterildiği gibi:
Toplam depolama boyutu: 925,39 GB
Geçmiş veriler (blok/işlem makbuzları): ~628,69 GB
Merkle Patricia Trie'deki (MPT) durum verileri: ~269,74 GB
İkinci neden ise Ethereum düğümlerinin tarihi blokları depolamak için protokol içi teşvik veya cezalardan yoksun olmasıdır. Protokol, düğümleri tüm geçmiş verileri depolamaya teşvik etse de, depolamayı teşvik edecek veya ihlalleri cezalandıracak herhangi bir mekanizma sağlayamıyor. Düğümler, teşviklerden ziyade fedakarlık nedeniyle tarihsel verileri depolamaya ve bunlara harici erişim sağlamaya isteklidir.
Elbette müşteri operatörleri tüm geçmiş verileri ceza ödemeden silmekte veya değiştirmekte özgürdür. Buna karşılık, Doğrulayıcı düğümlerin geçersiz bloklar önermek/oylamak nedeniyle kesintiye uğramasını önlemek için tam durumu yerel olarak koruması ve güncellemesi gerekir. Bu nedenle, bazı düğüm operatörlerinin, depolama maliyetleri düğümler üzerinde önemli bir yük haline geldiğinde geçmiş verileri silmeyi seçmeleri şaşırtıcı değildir. Geçmiş veriler olmadan, düğüm istemcisi depolama maliyetlerini önemli ölçüde azaltabilir ve kaplanan depolama alanını yaklaşık 1 TB'tan yaklaşık 300 GB'a düşürebilir.
Grafik: Nethermined, düğümleri geçmiş bloklar olmadan çalıştıracak şekilde yapılandırılmıştır - şu anda depolama maliyetlerinde ~460 GB tasarruf sağlanmaktadır
Depolama zorlukları, yaklaşan Ethereum Veri Kullanılabilirliği (DA) yükseltmesiyle daha da yoğunlaşacak. Ethereum DA'yı tamamen ölçeklendirmenin yolu, sabit boyutlu bir ikili büyük nesne (BLOB) ve blobGasPrice adı verilen bağımsız bir ücret modeli sunan DenCun yükseltmesindeki EIP-4844 ile başlar. Her BLOB 128KB olarak ayarlanır. EIP-4844 uygulandıktan sonra her blok en fazla 6 BLOB içerir. Ethereum, veri akışını genişletmek için başlangıçta blok başına 32 BLOB'a izin veren ve tamamen genişletildiğinde blok başına 256 BLOB seviyesine ulaşan 1D Reed-Solomon silme kodlamasını kullanmayı planlıyor.
Ethereum DA tam kapasitede çalışıyorsa (blok başına 256 BLOB), Ethereum DA ağının yılda yaklaşık 80 TB DA verisi alması bekleniyor; bu, çoğu düğümün depolama yeteneklerini çok aşan bir rakam.
Ethereum Depolama Yol Haritası ve Sonuçları
Vitalik'in Ethereum yol haritası tweet'inde Purge'un esas olarak depolamayı içerdiği belirtildi.
Artan depolama maliyetleri Ethereum ekosistemindeki araştırmacıların dikkatini çekti. Bu sorunu çözmek ve tüm müşteriler arasında tutarlılığı sağlamak için araştırmacılar, Ethereum istemcilerinin geçmiş verilerini açıkça silmeye yönelik öneriler üzerinde çalışıyor. İki ana öneri şunlardır:
· EIP-4444: Yürütme istemcilerindeki geçmiş verileri sınırlayın: Bu teklif, istemcilerin bir yıldan daha eski blokları silmesine olanak tanır. Ortalama blok boyutunun 100K olduğu varsayıldığında, geçmiş blok veri sınırı yaklaşık 250 GB'dir (100K * (3600 * 24 * 365) / 12, blok süresinin = 12 saniye olduğu varsayılarak).
· EIP-4844: Parçalanmış BLOB işlemleri: 18 günden eski BLOB verilerini atın. EIP-4444 ile karşılaştırıldığında bu daha agresif bir yaklaşımdır ve tarihsel BLOB boyutunu yaklaşık 100 GB ((18 * 3600 * 24) * 128K * 6/12, blok süresinin = 12 saniye olduğu varsayılarak) ile sınırlandırır.
Tüm müşteri geçmişi verilerinin silinmesinin sonuçları nelerdir? Ana sorunlardan biri, yeni düğümlerin "tam senkronizasyon" modu aracılığıyla en son duruma senkronize edilememesidir. "Tam senkronizasyon", geçmiş verileri yeniden oynatan ve oluşum bloğundan en son bloğa senkronize olan bir veri senkronizasyon şemasıdır. Buna göre, Ethereum düğümünün en son durumunu doğrudan senkronize etmek için "snap senkronizasyonu" veya "durum senkronizasyonu" almalıyız. Bu yaklaşım, eşzamanlı çalışmanın varsayılan yolu olarak Geth'de uygulanmıştır.
Ethereum ana ağının geçmiş verilerinin bir düğüm tarafından silinmesi Ethereum L2'de de sorunlara neden olacaktır, yani yeni eklenen Layer2 düğümleri, Layer2'nin tüm geçmiş verilerini tekrar oynatarak en son duruma senkronize olamaz. Ek olarak, L1 düğümleri L2 durumunu korumadığından, L2'nin "anlık senkronizasyon" yöntemi, Katman1 bloklarına dayalı olarak en son Katman2 durumunu doğrudan türetemez; bu, Katman2'nin Ethereum güvenliğini devralması için gereken önemli bir varsayımı ihlal eder.
Beklenen çözüm, protokol dışı, dolaylı teşvikler yoluyla elde edilen merkezi bir çözüm olan, Katman 2 geçmiş verilerini veya durum kopyalarını depolamak için Infura/Etherscan/L2 projesinin üçüncü taraf hizmetlerine dayanacaktır.
Araştırmak istediğimiz temel sorular şunlardır:
Depolama ve erişim için daha iyi merkezi olmayan çözümler bulabilir miyiz?
Düğümlere doğrudan teşvik veren ve Ethereum ağının kendisi tarafından garanti edilen (örneğin L1 sözleşmeleri yoluyla) bir çözüm bulmak mümkün müdür?
Tüm bunlara dayanarak, Ethereum depolama rotası protokolü kapsamında tamamen merkezi olmayan, doğrudan teşvik edilen bir çözüm sağlayabilir miyiz?
Çözüm 1: Ethereum Portal Ağı
Ethereum Portal Ağı, Ethereum protokolüne bağlanmak için hafif, merkezi olmayan bir ağdır. JSON-RPC isteklerini IPFS ağına benzer şekilde dağıtılmış karma tabloları (DHT) için P2P isteklerine dönüştüren eth_call, eth_getBlockByNumber vb. gibi Ethereum JSON-RPC arayüzleri sağlar. Her türlü verinin depolanmasına izin veren ve önemsiz verilere duyarlı IPFS'den farklı olarak Portal P2P ağı, Portal ağında yerleşik hafif istemci doğrulama teknolojisi aracılığıyla yalnızca geçmiş blok başlıkları ve işlem verileri gibi Ethereum verilerini barındırır.
Portal ağının önemli bir özelliği. Hafif operasyonel tasarımı ve kaynakları kısıtlı cihazlarla uyumluluğu. Birkaç MB depolama alanına ve düşük belleğe sahip düğümlerde çalışabilir, böylece merkeziyetsizliği teşvik eder. Bir cep telefonu veya Raspberry Pi cihazı bile ağa katılarak Ethereum DA sorununun çözümüne katkı sağlama potansiyeline sahiptir.
Portal ağı, Rust, JavaScript ve Nim ile yazılmış istemcilerle Ethereum istemci çeşitliliği felsefesi doğrultusunda geliştirildi. Beacon Ağı ve Tarih Ağı halihazırda mevcuttur, Devlet Ağı ise aktif olarak geliştirilme aşamasındadır. Portal ağının veri depolama için doğrudan teşvik sağlamadığını belirtmekte fayda var.
Resim: Portal ağı Rust istemcisi (Trin) 100 MB depolama sınırıyla çalışıyor
2. Çözüm: EthStorage Ağı
EthStorage ağı, EIP-4844 BLOB'ları depolamaya adanmış merkezi olmayan, teşvik edilmiş bir depolama ağıdır ve ESP projesi tarafından finanse edilmektedir.
· Minimum Güven: Merkezi bir veri köprüsü gerektiren mevcut çözümlerin aksine, EthStorage, Ethereum'un fikir birliğine ve EthStorage depolama düğümleri için izinsiz 1/m güven modeline dayanır. BLOB'u saklama süreci şu şekildedir: Kullanıcı BLOB'u taşıyan bir işlemi imzalar ve depolama sözleşmesinin put(key, blob_idx) yöntemini çağırır. Depolama sözleşmesi daha sonra zincirdeki BLOB karmasını kaydedecektir. Depolama sağlayıcısı daha sonra BLOB'u doğrudan Ethereum DA ağından indirip saklayacak, böylece veri köprüsü sorununu atlayacaktır.
· Depolama maliyetleri teşviklerle uyumludur: put() yöntemi çağrıldığında, işlemin depolama ücretini (msg.value aracılığıyla) göndermesi ve bunu sözleşmeye yatırması gerekir. Başarılı bir zincir dışı depolama düğümü depolama kanıtını gönderip doğruladıktan sonra, bu depolama ücreti zaman içinde depolama düğümüne kademeli olarak dağıtılacaktır. Blok üreticisine (teklif sahibine) tek seferlik bir depolama ücreti ödeyen mevcut Ethereum depolama ücreti modeliyle karşılaştırıldığında, zaman içinde ödenen depolama ücreti indirimli bir nakit akışı modelini takip eder; ETH'nin fiyatı. EthStorage tarafından sunulan bu büyük yenilik, depolama düğümlerinin ücretlerini ve depolama katkılarını uyumlu hale getiriyor.
· Depolama kanıtı: Depolama kanıtı, veri kullanılabilirliği örneklemesinden ilham alır ve EthStorage'daki örnekleme, belirli bir süre boyunca kaydedilen BLOB'lar içindir. Zincir içi örneklemeyi etkili bir şekilde doğrulamak için EthStorage, akıllı sözleşmelerden ve en son SNARK teknolojisi gelişmelerinden tam olarak yararlanır.
· İzinsiz işlem: EthStorage'daki herhangi bir depolama düğümü, verileri depoladığı ve zincire düzenli olarak depolama sertifikaları gönderdiği sürece ödül kazanabilir.
Modüler blockchain perspektifinden bakıldığında EthStorage, Ethereum depolama L2 görevi görür ancak işlem ücreti yerine depolama ücreti alır. EthStorage, Ethereum için depolama ölçeklenebilirliğini artıran ve zincirdeki BLOB hash'lerini indeksleyerek maliyetleri azaltan (~1000x hedefleme) modüler bir depolama katmanıdır.
Geliştirme tarafında, EthStorage, Ethereum Sepolia test ağında EIP-4844 ile entegre edilmiştir. EthStorage'a yaklaşık yüzlerce GB BLOB yazmak da dahil olmak üzere, EthStorage ve Ethereum Sepolia test ağına stres testi uyguladık. 100'den fazla topluluk katılımcısı ağa katıldı ve yerel depolamalarını başarıyla sergiledi.
EthStorage ağının birincil faydası, mevcut bilgilerimize göre çığır açan bir özellik olan Ethereum'un yanı sıra merkezi olmayan doğrudan teşvikler sağlamasıdır. Ancak bu ağın bir sınırlaması, sabit boyutlu BLOB'lar için özel olarak tasarlanmış olmasıdır.
EthStorage'da Ethereum Sepolia test ağı için bir kontrol paneli
Geleceğe bakmak
Ethereum depolaması çok fazla ilgi görmese de Ethereum ekosisteminde büyük öneme sahiptir. Ethereum ağı hızla büyüdükçe, Ethereum verilerinin depolanması ve erişilebilirliği önemli zorluklar haline geliyor. Portal Ağı ve EthStorage Ağı hâlâ başlangıç aşamasındadır ve odaklanılması gereken birçok önemli uzun vadeli geliştirme yönü vardır:
Düşük Gecikmeli Erişim için Merkezi Olmayan Ethereum Durum Veri Ağı: Ethereum durumuna merkezi olmayan ve doğrulanabilir bir şekilde erişmek kritik ama zorlu bir iştir. Geleneksel DHT ağ modelini kullanarak, hesap bilgilerinin sorgulanması genellikle farklı P2P düğümlerinde depolanan dahili bir düğüm grubuna birden fazla sorgu yapılmasını gerektirir. Bu genellikle önemli gecikmelere neden olur. Erişimi hızlandırmak için durum ağacının yapısının nasıl kullanılacağı anahtardır. Ethereum Portal Network'ün yakında kurulacak olan durum ağı bu sorunu çözmeyi amaçlıyor
Portal ağının EthStorage ağı ile entegrasyonu: Portal ağı, BLOB verilerini destekleyecek şekilde sorunsuz bir şekilde genişletilebilir. EthStorage ekibi bu işlevselliği kısmen uyguladı. Bir sonraki adım, bu ağları birleştirmek ve sözleşmeler yoluyla BLOB'lara programlanabilir erişim sağlayabilecek merkezi olmayan bir JSON-RPC ağı sağlamaktır. Sözleşmelerdeki uygulama mantığını EthStorage tarafından sağlanan ölçeklendirilmiş BLOB depolama alanıyla birleştirerek, dinamik merkezi olmayan web siteleri (merkezi olmayan Twitter/YouTube/Wikipedia vb.) gibi Ethereum üzerinde yeni dApp'leri etkinleştirebiliriz.
Tarayıcılar tarafından merkezi olmayan erişim: IPFS ağındaki verilere erişim için ipfs:// protokolüne benzer şekilde, web3 endüstrisi, Ethereum'un zengin verilerinin büyük potansiyelinin kilidini açmak için doğrudan tarayıcı erişimini desteklemek üzere bir Ethereum-yerel erişim protokolüne ihtiyaç duyar. Veriler, token sahipliği ve hesap bakiyelerinden NFT görüntülerine ve dinamik merkezi olmayan web sitelerine kadar geniş bir yelpazedeki alanları kapsıyor; bunların tümü akıllı sözleşmelerin ve gelecekteki Ethereum depolamanın yetenekleriyle mümkün kılınıyor. Bu alanda, ERC-4804/6860 tarafından tanımlanan web3:// protokolü şu anda bu hedefe ulaşmak için aktif olarak geliştirilmekte ve tanıtılmaktadır.
Dinamik olarak boyutlandırılmış veriler için gelişmiş depolama kanıtı: Sabit BLOB'lara ek olarak, geçmiş bloklar ve hatta durum nesneleri gibi dinamik olarak boyutlandırılmış verileri çözmek için gelişmiş depolama kanıtını keşfetmek de zorunludur. Gelişmiş algoritmalar geliştirmek, depolama çözümlerinin uyarlanabilirliğini artırabilir.
Bu çabalarımızla, Ethereum yol haritasına ortaklaşa katkıda bulunacağımızı ve Ethereum ekosistemi için gelecekteki merkezi olmayan depolama çözümlerinin temelini oluşturacağımızı umuyoruz.
