Ringkasan

• Tuntutan penyimpanan yang semakin meningkat menimbulkan tantangan signifikan bagi node Ethereum.
• Beberapa klien telah mulai memangkas data historis karena keterbatasan penyimpanan, menyebabkan perilaku penyimpanan yang tidak konsisten di antara node penuh dalam jaringan.
• Untuk memastikan keselarasan di semua klien, pemangkasan data historis sedang distandarisasi dalam EIP-4444 dan EIP-4844
• Oleh karena itu, pemulihan negara L1 atau L2 terbaru dengan memutar ulang data historis bergantung pada layanan terpusat di luar protokol, mendorong eksplorasi solusi yang lebih terdesentralisasi yang sejalan dengan Ethereum
• Jaringan Portal Ethereum adalah jaringan P2P ringan dan terdesentralisasi untuk semua jenis data Ethereum termasuk data historis. Dirancang untuk perangkat dengan sumber daya terbatas dan menyediakan layanan Ethereum JSON-RPC. Jaringan historis dan jaringan beacon hampir siap digunakan.
• Jaringan EthStorage adalah jaringan penyimpanan modular yang mendapat insentif untuk BLOB EIP-4844. Untuk menyimpan BLOB, pengguna memanggil kontrak penyimpanan L1 menempatkan()metode dengan hash BLOB dan biaya dalam ETH. Biaya akan secara bertahap didistribusikan ke penyedia penyimpanan setelah mengirimkan bukti penyimpanan yang valid dari BLOB off-chain dari waktu ke waktu. Testnet EthStorage berjalan di testnet Ethereum Sepolia dengan beberapa peserta komunitas yang berhasil membuktikan penyimpanan lokal mereka.
• Inisiatif masa depan termasuk pengembangan jaringan negara terdesentralisasi, implementasi bukti penyimpanan untuk data berukuran dinamis, dan akses terdesentralisasi langsung dari peramban.

Pengakuan: Terima kasih banyak kepada Piper Merriam dari EF, Karthik Raju dari Polychain, Qiang dari EthStorage atas masukan artikel ini.

Latar Belakang

Pada 22 Oktober 2023, Péter Szilágyi, pemimpin pengembang terkenal Go-Ethereum (Geth), menyatakan keprihatinannya yang mendalam di Twitter. Dia menunjukkan bahwa sementara klien Geth mempertahankan semua data historis, klien Ethereum lain seperti Nethermind dan Besu dapat dikonfigurasi untuk beroperasi tanpa beberapa data historis Ethereum, seperti badan blok historis dan header historis. Hal ini membuat semua klien tidak konsisten dan tidak adil bagi Geth. Ini memicu diskusi dan perdebatan intens seputar masalah Penyimpanan Ethereum dalam peta jalan Ethereum.

Tantangan Penyimpanan

Mengapa Nethermind dan Besu memutuskan untuk menghentikan penyimpanan data historis? Apa masalah yang mendasari keputusan ini? Dari pandangan saya, ada dua penyebab utama:

• Persyaratan penyimpanan untuk klien Ethereum semakin meningkat.
• Tidak ada insentif atau hukuman dalam protokol untuk menyimpan data historis Ethereum.

Alasan pertama berasal dari tuntutan penyimpanan yang meningkat dari menjalankan klien Ethereum. Untuk memahami persyaratan spesifik, diagram lingkaran berikut menggambarkan distribusi biaya penyimpanan untuk node Geth baru, pada blok 18.779.761 pada 13 Desember 2023.

Seperti yang terlihat pada gambar:

• Total kebutuhan penyimpanan: 925.39 GB
• Data historis (blok/kwitansi): Sekitar 628.69 GB
• Negara dalam Merkle Patricia Trie (MPT): Sekitar 269.74 GB

Alasan kedua adalah tidak adanya insentif atau hukuman dalam protokol untuk menyimpan blok historis. Sementara protokol mewajibkan node untuk menyimpan semua data historis, namun tidak memberikan mekanisme apapun untuk mendorong penyimpanan atau menghukum ketidakpatuhan. Menyimpan dan membagikan data historis oleh node menjadi murni altruistik, dan sebuah node bebas untuk memangkas semua data historis tanpa menghadapi konsekuensi negatif. Sebaliknya, validator, misalnya, harus mempertahankan status penuh terkini untuk menghindari mengajukan / memberikan suara untuk blok yang tidak valid, berisiko kehilangan insentif dalam kedua kasus.

Oleh karena itu, ketika biaya penyimpanan menjadi beban yang signifikan bagi sebuah node, tidak mengherankan bahwa beberapa operator node memilih untuk memangkas data historis. Memilih untuk berjalan tanpa data historis dapat menghasilkan penghematan biaya penyimpanan yang signifikan, menguranginya dari sekitar 1TB menjadi sekitar 300GB.

Ilustrasi: Konfigurasi Nethermined untuk menjalankan node tanpa data historis blok - menghemat biaya penyimpanan ~460GB untuk saat ini.

Tantangan penyimpanan diperkirakan akan semakin intensif dengan peningkatan Data Availability (DA) Ethereum yang akan datang. jalurmenuju penskalaan penuh Ethereum DA dimulai dengan EIP-4844 di DenCun, memperkenalkan objek besar biner (BLOB) berukuran tetap yang disertai dengan model biaya independen yang dikenal sebagai blobGasPrice. Setiap BLOB diatur pada 128KB, dan EIP-4844 mengizinkan setiap blok berisi hingga 6 BLOB. Untuk meningkatkan skalabilitas data, rencana ini melibatkan implementasi kode Reed-Solomon 1D, memungkinkan 32 BLOB per blok pada awalnya dan akhirnya mencapai 256 BLOB per blok saat penskalaan penuh.

Dengan Ethereum DA beroperasi pada kapasitas data penuh dengan 256 BLOB per blok, satu tahun jaringan Ethereum DA diproyeksikan menerima sekitar 80 TB data, melampaui kapasitas penyimpanan sebagian besar node Ethereum.

Rencana Penyimpanan Ethereum dan Konsekuensinya

Vitalik’stweetdari peta jalan Ethereum, di mana Pembersihan terutama menangani penyimpanan.

Biaya penyimpanan yang meningkat telah menarik perhatian dari para peneliti di dalam ekosistem Ethereum. Untuk mengatasi hal ini dan memastikan keselarasan di antara semua klien, beberapa proposal sedang dalam pengembangan untuk secara eksplisit memangkas penyimpanan. Dua proposal utama adalah:

1. EIP-4444: Data Historis Terikat dalam Klien Eksekusi: Usulan ini memungkinkan klien untuk memangkas blok historis yang lebih tua dari satu tahun. Dengan asumsi ukuran blok rata-rata sebesar 100K, data blok historis dibatasi hingga sekitar 250 GB (100K (3600 24 * 365) / 12, diberikan waktu blok = 12s).
2. EIP-4844: Transaksi BLOB Shard: EIP-4844 menolak BLOB yang lebih lama dari 18 hari. Ini adalah pendekatan yang lebih agresif dibandingkan EIP-4444, membatasi ukuran BLOB historis sekitar 100 GB ((183600 24) 128K 6 / 12, diberikan waktu blok = 12s).

Apa konsekuensi dari pemangkasan data historis dari semua klien? Yang utama adalah bahwa node baru tidak dapat disinkronkan ke keadaan terbaru melalui “sinkronisasi penuh” - sinkronisasi untuk memutar ulang transaksi dari blok genesis ke blok terbaru. Sebagai gantinya, kita harus beralih ke “sinkronisasi instan” atau “sinkronisasi status” untuk menyinkronkan status terbaru dari rekan-rekan Ethereum. Pendekatan ini sudah diimplementasikan dalam Geth dan berjalan sebagai sinkronisasi default.

Demikian pula, konsekuensi ini juga berlaku untuk semua L2, yaitu, sebuah simpul baru dari L2 tidak dapat sepenuhnya memutar ulang keadaan terbaru dari L2 genesis dari Ethereum dengan memutar ulang blok L2 dari L2 genesis. Selain itu, karena simpul L1 tidak mempertahankan keadaan L2, pendekatan "sinkronisasi instan" untuk L2 tidak dapat mendapatkan keadaan L2 terbaru dari L1 - melanggar asumsi penting L2 mengenai mewarisi jaminan keamanan Ethereum. Solusi yang diproyeksikan akan bergantung pada layanan pihak ketiga seperti Infura / Etherscan / proyek L2 sendiri untuk menyimpan salinan data atau keadaan historis L2, yang terpusat dengan insentif tidak langsung di luar protokol.

Pertanyaan inti yang kami ajukan adalah

• Dapatkah kita memiliki solusi terdesentralisasi yang lebih baik, baik dalam hal penyimpanan maupun akses, terhadap masalah ini?
• Mungkinkah untuk membangun solusi terdesentralisasi yang sejalan dengan Ethereum (misalnya, di atas kontrak L1) dengan solusi insentif langsung?
• Dengan semua ini, bisakah kita membuka jalan menuju solusi insentif langsung di dalam protokol untuk penyimpanan Ethereum dan mengaksesnya dengan cara yang sepenuhnya terdesentralisasi dalam peta jalan Ethereum?

Solusi

Solusi 1: Jaringan Portal Ethereum

Jaringan Portal Ethereum berfungsi sebagai jaringan akses terdesentralisasi yang ringan ke protokol Ethereum. Menawarkan antarmuka JSON-RPC Ethereum seperti eth_call, eth_getBlockByNumber, jaringan ini menerjemahkan permintaan JSON-RPC menjadi permintaan P2P ke tabel hash terdistribusi, mirip dengan jaringan IPFS. Tidak seperti IPFS, yang memungkinkan penyimpanan berbagai jenis data dan rentan terhadap spam, jaringan P2P Portal secara eksklusif menyimpan data Ethereum, seperti header dan badan historis. Ini dicapai melalui teknik verifikasi light-client bawaan dalam jaringan Portal.

Sebuah fitur penting dari jaringan Portal adalah desainnya untuk operasi ringan dan kompatibilitas dengan perangkat yang terbatas sumber dayanya. Ini dapat berjalan di atas sebuah node dengan beberapa megabita penyimpanan dan memori rendah, mempromosikan desentralisasi. Bahkan sebuah ponsel atau perangkat Raspberry Pi pun berpotensi untuk bergabung dengan jaringan dan berkontribusi terhadap ketersediaan data Ethereum.

Pengembangan jaringan Portal sejalan dengan filosofi keberagaman klien Ethereum, dengan klien yang ditulis dalam Rust, JavaScript, Nim, dan Go. Jaringan beacon dan jaringan sejarah siap digunakan, sementara jaringan status sedang aktif dikembangkan. Perlu dicatat, jaringan Portal tidak memberikan insentif langsung untuk penyimpanan data—semua node dalam jaringan beroperasi secara altruistik.

Ilustrasi: Menjalankan jaringan Portal (Trin) dengan batas penyimpanan 100MB.

Solusi 2: Jaringan EthStorage

Jaringan EthStorage adalah jaringan penyimpanan terdesentralisasi yang diincentivasi khususnya dirancang untuk menyimpan BLOB EIP-4844, didukung oleh hibah dari program ESP.

• Minimal Trust: Tidak seperti solusi-solusi yang ada yang membutuhkan jembatan data terpusat, EthStorage mengandalkan konsensus Ethereum dan model kepercayaan $1/m$ dari penyedia penyimpanan EthStorage tanpa izin. Prosedur penyimpanan BLOB adalah sebagai berikut: pengguna menandatangani transaksi yang membawa BLOB yang memanggil metode _put(key, blob_idx)_ dari kontrak penyimpanan. Kontrak penyimpanan kemudian akan mencatat hash BLOB dan memberitahukan penyedia penyimpanan dengan suatu acara. Penyedia penyimpanan, setelah menerima acara tersebut, kemudian akan mengunduh dan menyimpan BLOB langsung dari jaringan DA Ethereum, menghindari masalah jembatan data.
• Menyelaraskan Biaya Penyimpanan dengan Insentif: Saat memanggilput()metode, biaya penyimpanan harus dikirim (melalui msg.value) dan disimpan di kontrak. Biaya penyimpanan ini secara bertahap didistribusikan ke penyedia penyimpanan dari waktu ke waktu setelah pengajuan berhasil dan verifikasi bukti penyimpanan. Dibandingkan dengan model biaya penyimpanan Ethereum saat ini yang membayar biaya penyimpanan sekali bayar kepada pengusul, biaya penyimpanan yang dibayarkan dari waktu ke waktu mengikuti model aliran kas diskon - dengan asumsi biaya penyimpanan menurun dibandingkan dengan ETH dari waktu ke waktu. Inovasi signifikan ini yang diperkenalkan oleh EthStorage menyelaraskan biaya yang dibayarkan oleh pengguna dan kontribusi penyedia penyimpanan dari waktu ke waktu.
• Bukti Penyimpanan: Bukti penyimpanan terinspirasi oleh pengambilan data yang tersedia, sementara pengambilan sampel di EthStorage dilakukan terhadap BLOB dari waktu ke waktu alih-alih yang dari blok yang diusulkan. Untuk memverifikasi pengambilan sampel secara efisien di rantai, EthStorage sangat mengandalkan kontrak pintar dan perkembangan terbaru dalam teknologi SNARK.
• Jaringan Tanpa Izin: Setiap node di EthStorage dapat dibayar sebagai penyedia penyimpanan selama menyimpan data dan secara berkala mengirimkan bukti penyimpanan on-chain.

Dari perspektif modularitas blockchain, EthStorage berfungsi sebagai Ethereum Layer 2, tetapi mengumpulkan biaya penyimpanan alih-alih biaya transaksi. Dengan mengindeks hash BLOB on-chain, EthStorage adalah lapisan penyimpanan modular Ethereum dengan skalabilitas penyimpanan yang signifikan dan penghematan biaya - menargetkan sekitar 1000x.

Dalam hal pengembangan, EthStorage sudah terintegrasi dengan EIP-4844 pada testnet Ethereum Sepolia. Uji stres pada EthStorage dan testnet Ethereum Sepolia telah dilakukan, melibatkan penulisan sekitar ratusan Gigabyte BLOB ke EthStorage. Lebih dari 50 peserta komunitas bergabung dengan jaringan dan berhasil membuktikan penyimpanan lokal mereka.

Keuntungan utama jaringan EthStorage terletak pada memberikan insentif langsung terdesentralisasi di atas Ethereum—fitur terdepan, sejauh pengetahuan kami saat ini mencapai. Namun, keterbatasan jaringan adalah bahwa jaringan tersebut dirancang khusus untuk BLOB berukuran tetap.

Dasbor EthStorage di Ethereum Devnet

Memproyeksikan Masa Depan

Penyimpanan Ethereum, meskipun kurang diperhatikan, memiliki kepentingan yang signifikan dalam ekosistem Ethereum. Saat jaringan Ethereum mengalami pertumbuhan yang pesat, penyimpanan dan aksesibilitas data Ethereum muncul sebagai tantangan kritis. Sementara jaringan Portal dan jaringan EthStorage berada dalam tahap awal, kami membayangkan beberapa arah menarik untuk jangka panjang:

• Akses Terdesentralisasi Rendah-Latensi ke Ethereum State. Mengakses status Ethereum dengan cara yang terdesentralisasi dan dapat diverifikasi merupakan tugas yang krusial namun menantang. Dalam pengaturan DHT tradisional, mengambil data dari sebuah akun biasanya memerlukan beberapa permintaan kepada simpul trie internal yang disimpan di berbagai simpul P2P yang berbeda. Hal ini seringkali mengakibatkan latensi yang cukup lama. Cara untuk menggunakan struktur pohon status untuk mempercepat akses merupakan kunci, seperti yang sedang diatasi oleh jaringan status yang akan datang dari jaringan Portal Ethereum.
• Integrasi Antara Jaringan Portal dan Jaringan EthStorage: Jaringan Portal dapat dengan lancar memperluas dukungannya untuk menyertakan BLOBs dalam jaringan, langkah yang sudah sebagian diambil oleh tim EthStorage. Progres alami akan menyatukan jaringan ini untuk menawarkan jaringan JSON-RPC terdesentralisasi yang mampu memanggil kontrak dengan akses ke BLOBs. Dengan menggabungkan logika aplikasi dalam kontrak dan penyimpanan BLOB yang diperbesar oleh EthStorage, kami memungkinkan dApps baru di Ethereum seperti situs web terdesentralisasi dinamis (misalnya, twitter/youtube/wikipedia terdesentralisasi).
• Akses Terdesentralisasi dari Peramban: Serupa dengan protokol ipfs:// yang digunakan untuk mengakses data dalam jaringan IPFS, ada kebutuhan yang berkembang untuk protokol akses Ethereum-native dari peramban untuk membuka potensi besar data kaya Ethereum. Data ini mencakup spektrum luas, mulai dari kepemilikan token dan saldo hingga gambar NFT dan situs web terdesentralisasi dinamis, semua dimungkinkan oleh kemampuan kontrak pintar dan penyimpanan Ethereum masa depan. Di ranah ini, protokol web3://, seperti yang ditentukan dalam ERC-4804/6860, saat ini sedang mengalami perkembangan aktif untuk memenuhi tujuan ini.
• Bukti Penyimpanan Lanjutan untuk Data Berukuran Dinamis: Melampaui BLOB tetap, menjelajahi bukti penyimpanan lanjutan menjadi penting untuk mengatasi data berukuran dinamis, seperti blok historis atau bahkan objek status. Mengembangkan algoritma yang canggih dapat meningkatkan adaptabilitas solusi penyimpanan.

Dalam perjalanan kami, kami bercita-cita agar upaya-upaya ini secara kolektif memberikan kontribusi pada peta jalan Ethereum, membentuk dasar bagi solusi penyimpanan terdesentralisasi di dalam ekosistem Ethereum di masa depan.

pernyataan:

1. Artikel ini direproduksi dari [arus teknologi yang dalam] , judul aslinya adalah “Ethereum Storage Roadmap: Tantangan dan Peluang”, hak cipta milik penulis asli [EthStorage], jika Anda keberatan dengan penayangan ulang, silakan hubungi Tim Pembelajaran Gate, tim akan menanganinya sesegera mungkin sesuai dengan prosedur yang relevan.

2. Penafian: Pandangan dan opini yang diungkapkan dalam artikel ini hanya mewakili pandangan pribadi penulis dan tidak merupakan saran investasi apa pun.

3. Versi bahasa lain dari artikel diterjemahkan oleh tim Gate Learn, tidak disebutkan di Gate.io, artikel yang diterjemahkan tidak boleh direproduksi, didistribusikan, atau diplagiat.