Salah satu tantangan yang dihadapi Ethereum adalah, secara default, pembengkakan dan kompleksitas dari protokol blockchain mana pun akan meningkat seiring berjalannya waktu. Ini terjadi dalam dua aspek:
Data Historis: Semua transaksi dan akun yang dibuat pada setiap momen dalam sejarah perlu disimpan secara permanen oleh semua klien, dan diunduh oleh klien baru untuk sepenuhnya disinkronkan dengan jaringan. Ini menyebabkan beban klien dan waktu sinkronisasi terus meningkat, meskipun kapasitas rantai tetap tidak berubah.
Fungsi protokol: Menambahkan fitur baru jauh lebih mudah daripada menghapus fitur lama, menyebabkan kompleksitas kode meningkat seiring waktu.
Untuk menjaga agar Ethereum dapat bertahan dalam jangka panjang, kita perlu memberikan tekanan yang kuat terhadap dua tren ini, mengurangi kompleksitas dan inflasi seiring waktu. Sementara itu, kita perlu mempertahankan salah satu atribut kunci yang membuat blockchain menjadi hebat: ketahanan. Anda dapat menempatkan NFT, surat cinta dalam catatan transaksi, atau kontrak pintar yang berisi 1 juta dolar di dalam rantai, dan 10 tahun kemudian itu masih ada menunggu Anda untuk dibaca dan diinteraksi. Agar DApp dapat sepenuhnya terdesentralisasi dan menghapus kunci upgrade dengan aman, mereka perlu yakin bahwa ketergantungan mereka tidak akan diupgrade dengan cara yang merusak mereka - terutama L1 itu sendiri.
Jika kita bertekad untuk mencapai keseimbangan antara kedua kebutuhan ini, dan meminimalkan atau membalikkan pembengkakan, kompleksitas, dan penurunan sambil menjaga kontinuitas, itu sangat mungkin. Organisme dapat melakukannya: meskipun sebagian besar organisme menua seiring waktu, beberapa yang beruntung tidak. Bahkan sistem sosial pun dapat memiliki umur yang sangat panjang. Dalam beberapa kasus, Ethereum telah berhasil: bukti kerja menghilang, opcode SELFDESTRUCT sebagian besar hilang, dan node beacon chain telah menyimpan data lama selama maksimal enam bulan. Menemukan jalan ini untuk Ethereum dengan cara yang lebih umum dan menuju hasil akhir yang stabil dalam jangka panjang adalah tantangan utama bagi skalabilitas jangka panjang Ethereum, keberlanjutan teknologi, bahkan keamanan.
Tujuan utama The Purge:
Mengurangi persyaratan penyimpanan klien dengan mengurangi atau menghilangkan kebutuhan untuk menyimpan semua riwayat atau bahkan status akhir secara permanen di setiap node.
Mengurangi kompleksitas protokol dengan menghilangkan fungsi yang tidak diperlukan
Masa berlaku sejarah
Apa masalah yang diselesaikan?
Hingga saat penulisan ini, node Ethereum yang sepenuhnya disinkronkan membutuhkan sekitar 1,1 TB ruang disk untuk menjalankan klien, ditambah lagi beberapa ratus GB ruang disk untuk klien konsensus. Sebagian besar dari ini adalah sejarah: data tentang blok, transaksi, dan bukti sejarah, yang sebagian besar sudah berusia bertahun-tahun. Ini berarti bahwa bahkan jika batas Gas tidak meningkat sama sekali, ukuran node akan terus meningkat beberapa ratus GB setiap tahun.
Apa itu, bagaimana cara kerjanya?
Salah satu fitur penyederhanaan kunci dari masalah penyimpanan sejarah adalah, karena setiap blok terhubung dengan hash ( dan struktur lain ) yang menunjuk ke blok sebelumnya, maka konsensus saat ini sudah cukup untuk mencapai konsensus sejarah. Selama jaringan mencapai konsensus pada blok terbaru, blok atau transaksi atau status sejarah ( saldo akun, angka acak, kode, penyimpanan ) dapat disediakan oleh peserta tunggal mana pun serta bukti Merkle, dan bukti tersebut memungkinkan orang lain untuk memverifikasi kebenarannya. Konsensus adalah model kepercayaan N/2-of-N, sedangkan sejarah adalah model kepercayaan N-of-N.
Ini memberikan banyak pilihan tentang bagaimana kita menyimpan catatan sejarah. Salah satu pilihan yang alami adalah jaringan di mana setiap node hanya menyimpan sebagian kecil data. Inilah cara kerja jaringan benih selama beberapa dekade: meskipun jaringan secara total menyimpan dan mendistribusikan jutaan file, setiap peserta hanya menyimpan dan mendistribusikan beberapa file di antaranya. Mungkin bertentangan dengan intuisi, pendekatan ini bahkan tidak selalu mengurangi ketahanan data. Jika dengan membuat node berjalan lebih ekonomis, kita dapat membangun jaringan dengan 100.000 node, di mana setiap node menyimpan 10% catatan sejarah secara acak, maka setiap data akan disalin 10.000 kali - sama persis dengan faktor salinan dari jaringan 10.000 node, di mana setiap node menyimpan semua konten.
Saat ini, Ethereum telah mulai melepaskan model di mana semua node menyimpan semua sejarah secara permanen. Konsensus blok ( terkait dengan bagian konsensus bukti kepemilikan yang hanya menyimpan sekitar 6 bulan. Blob hanya menyimpan sekitar 18 hari. EIP-4444 bertujuan untuk memperkenalkan periode penyimpanan satu tahun untuk blok dan penerimaan sejarah. Tujuan jangka panjang adalah untuk membangun periode yang seragam ) mungkin sekitar 18 hari (, di mana setiap node bertanggung jawab untuk menyimpan semua konten, dan kemudian membangun jaringan peer-to-peer yang terdiri dari node Ethereum untuk menyimpan data lama dengan cara terdistribusi.
Kode penghapusan dapat digunakan untuk meningkatkan ketahanan, sambil mempertahankan faktor replikasi yang sama. Faktanya, Blob telah menggunakan kode penghapusan untuk mendukung pengambilan ketersediaan data. Solusi yang paling sederhana kemungkinan adalah menggunakan kembali kode penghapusan ini, dan juga memasukkan data blok eksekusi dan konsensus ke dalam blob.
) apa hubungan dengan penelitian yang ada?
EIP-4444
Torrents dan EIP-4444
Jaringan Portal
Jaringan portal dan EIP-4444
Penyimpanan dan pengambilan terdistribusi objek SSZ di Portal
Bagaimana cara meningkatkan batas gas###Paradigm(
) apa lagi yang perlu dilakukan, apa yang perlu dipertimbangkan?
Pekerjaan utama yang tersisa mencakup pembangunan dan integrasi solusi terdistribusi spesifik untuk menyimpan riwayat—setidaknya riwayat eksekusi, tetapi pada akhirnya juga mencakup konsensus dan blob. Solusi paling sederhana adalah ###i( dengan sederhana memperkenalkan perpustakaan torrent yang ada, serta )ii( solusi asli Ethereum yang disebut jaringan Portal. Setelah salah satu dari ini diperkenalkan, kita dapat membuka EIP-4444. EIP-4444 itu sendiri tidak memerlukan hard fork, tetapi memang memerlukan versi protokol jaringan yang baru. Oleh karena itu, mengaktifkannya secara bersamaan untuk semua klien adalah berharga, jika tidak ada risiko klien mengalami kegagalan karena terhubung ke node lain yang mengharapkan untuk mengunduh riwayat lengkap tetapi sebenarnya tidak diperoleh.
Pertimbangan utama melibatkan bagaimana kita berusaha untuk menyediakan data sejarah "kuno". Solusi termudah adalah berhenti menyimpan sejarah kuno besok, dan mengandalkan node arsip yang ada dan berbagai penyedia terpusat untuk replikasi. Ini mudah, tetapi ini melemahkan posisi Ethereum sebagai tempat catatan permanen. Cara yang lebih sulit tetapi lebih aman adalah dengan terlebih dahulu membangun dan mengintegrasikan jaringan torrent untuk menyimpan catatan secara terdistribusi. Di sini, "seberapa keras kita berusaha" memiliki dua dimensi:
Bagaimana kami berusaha memastikan bahwa kumpulan node terbesar benar-benar menyimpan semua data?
Seberapa dalam kita mengintegrasikan penyimpanan sejarah ke dalam protokol?
Sebuah metode ekstrem yang paranoid untuk ) akan melibatkan bukti kustodian: pada dasarnya meminta setiap validator bukti kepemilikan untuk menyimpan proporsi tertentu dari riwayat, dan secara berkala memeriksa dengan cara yang terenkripsi apakah mereka melakukan hal tersebut. Metode yang lebih moderat adalah menetapkan standar sukarela untuk persentase riwayat yang disimpan oleh setiap klien.
Untuk (2), implementasi dasar hanya melibatkan pekerjaan yang telah diselesaikan hari ini: Portal telah menyimpan file ERA yang mencakup seluruh sejarah Ethereum. Implementasi yang lebih menyeluruh akan melibatkan penghubungan sebenarnya ke proses sinkronisasi, sehingga, jika seseorang ingin menyinkronkan node penyimpanan sejarah lengkap atau node arsip, meskipun tidak ada node arsip lain yang online, mereka dapat mencapainya dengan langsung menyinkronkan dari jaringan portal.
( Bagaimana itu berinteraksi dengan bagian lain dari peta jalan?
Jika kita ingin membuat menjalankan atau memulai node menjadi sangat mudah, maka mengurangi kebutuhan penyimpanan sejarah bisa dibilang lebih penting daripada tanpa status: dari 1,1 TB yang diperlukan node, sekitar 300 GB adalah status, sementara sekitar 800 GB telah menjadi sejarah. Hanya dengan mencapai tanpa status dan EIP-4444, visi untuk menjalankan node Ethereum di jam tangan pintar dan hanya membutuhkan beberapa menit untuk diatur dapat terwujud.
Pembatasan penyimpanan sejarah juga membuat implementasi node Ethereum yang lebih baru menjadi lebih praktis, hanya mendukung versi terbaru dari protokol, yang membuatnya menjadi lebih sederhana. Misalnya, sekarang banyak baris kode dapat dihapus dengan aman, karena slot penyimpanan kosong yang dibuat selama serangan DoS tahun 2016 telah sepenuhnya dihapus. Sekarang setelah peralihan ke bukti kepemilikan telah menjadi sejarah, klien dapat dengan aman menghapus semua kode yang terkait dengan bukti kerja.
![Vitalik: Masa Depan Potensial Ethereum, The Purge])https://img-cdn.gateio.im/webp-social/moments-b4e683a9e42e4b5bd6991a4cf6cf948e.webp###
Kadaluarsa negara
( Apa yang menjadi solusi?
Meskipun kami menghilangkan kebutuhan untuk menyimpan riwayat di klien, kebutuhan penyimpanan klien akan terus tumbuh, sekitar 50 GB per tahun, karena status terus berkembang: saldo akun dan angka acak, kode kontrak dan penyimpanan kontrak. Pengguna dapat membayar biaya sekali saja, sehingga selamanya membebani klien Ethereum saat ini dan di masa depan.
Status lebih sulit "kedaluwarsa" dibandingkan sejarah, karena EVM pada dasarnya dirancang dengan asumsi bahwa: setelah objek status dibuat, itu akan selalu ada dan dapat dibaca kapan saja oleh transaksi mana pun. Jika kita memperkenalkan tanpa status, beberapa orang berpendapat bahwa masalah ini mungkin tidak seburuk itu: hanya kelas pembangun blok khusus yang perlu benar-benar menyimpan status, sementara semua node lainnya ) bahkan termasuk daftar menghasilkan! ### dapat berjalan tanpa status. Namun, ada pandangan bahwa kita tidak ingin terlalu bergantung pada tanpa status, pada akhirnya kita mungkin ingin membuat status kedaluwarsa untuk menjaga desentralisasi Ethereum.
( Apa itu, bagaimana cara kerjanya
Hari ini, ketika Anda membuat objek status baru, ) dapat terjadi melalui salah satu dari tiga cara berikut: ###i ( mengirim ETH ke akun baru, (ii ) membuat akun baru menggunakan kode, (iii ) mengatur slot penyimpanan yang sebelumnya tidak terjangkau (, objek status ini akan selalu berada dalam keadaan tersebut. Sebaliknya, yang kita inginkan adalah objek yang secara otomatis kedaluwarsa seiring waktu. Tantangan kuncinya adalah melakukannya dengan cara yang memenuhi tiga tujuan.
Efisiensi: tidak memerlukan perhitungan tambahan yang besar untuk menjalankan proses kedaluwarsa.
Kemudahan Pengguna: Jika seseorang masuk ke dalam gua selama lima tahun dan kembali, mereka seharusnya tidak kehilangan akses ke ETH, ERC20, NFT, posisi CDP......
Ramah bagi Pengembang: Pengembang tidak perlu beralih ke model pemikiran yang sepenuhnya tidak dikenal. Selain itu, aplikasi yang saat ini sudah kaku dan tidak diperbarui seharusnya dapat terus berfungsi dengan baik.
Tidak memenuhi tujuan ini sangat mudah untuk menyelesaikan masalah. Misalnya, Anda dapat membuat setiap objek status juga menyimpan penghitung tanggal kedaluwarsa ) yang dapat diperpanjang dengan membakar ETH, yang mungkin secara otomatis terjadi kapan saja saat dibaca atau ditulis ), dan memiliki proses yang melintasi status untuk menghapus objek status tanggal kedaluwarsa. Namun, ini memperkenalkan kebutuhan komputasi tambahan ( bahkan kebutuhan penyimpanan ), dan pasti tidak dapat memenuhi tuntutan ramah pengguna. Pengembang juga kesulitan untuk menyimpulkan situasi tepi yang melibatkan nilai penyimpanan yang kadang-kadang direset menjadi nol. Jika Anda mengatur penghitung kedaluwarsa dalam ruang lingkup kontrak, ini secara teknis akan membuat hidup pengembang lebih mudah, tetapi akan membuat ekonomi menjadi lebih sulit: pengembang harus mempertimbangkan bagaimana "mengalihkan" biaya penyimpanan yang berkelanjutan kepada pengguna.
Ini semua adalah masalah yang telah diupayakan oleh komunitas pengembang inti Ethereum selama bertahun-tahun, termasuk proposal seperti "sewa blockchain" dan "regenerasi". Akhirnya, kami menggabungkan bagian terbaik dari proposal tersebut dan fokus pada dua kategori "solusi yang paling tidak buruk yang diketahui":
Solusi untuk status yang telah kedaluwarsa
Saran kedaluwarsa status berbasis siklus alamat
( Masa kedaluwarsa sebagian dari status
Beberapa proposal status yang kadaluarsa mengikuti prinsip yang sama. Kami membagi status menjadi blok. Setiap orang secara permanen menyimpan "peta teratas", di mana blok tersebut kosong atau tidak kosong. Data dalam setiap blok hanya akan disimpan jika data tersebut baru saja diakses. Ada mekanisme "kebangkitan" yang jika tidak lagi disimpan
Perbedaan utama antara proposal ini adalah: )i### bagaimana kita mendefinisikan "terbaru", dan (ii) bagaimana kita mendefinisikan "blok"? Salah satu proposal khusus adalah EIP-7736, yang dibangun di atas "batang dan daun" yang diperkenalkan untuk pohon Verkle desain ( meskipun kompatibilitas dengan segala bentuk status stateless, seperti ) pohon biner. Dalam desain ini, header, kode, dan slot yang berdekatan satu sama lain disimpan di bawah "tulang punggung" yang sama. Data yang disimpan di bawah satu batang dapat mencapai 256 * 31 = 7.936 byte. Dalam banyak kasus, seluruh header dan kode akun, serta banyak slot kunci, akan disimpan di bawah tulang punggung yang sama. Jika data di bawah tulang punggung tertentu belum dibaca atau ditulis dalam waktu 6 bulan, data tidak lagi disimpan, tetapi hanya 32 byte dari data tersebut yang disimpan
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
14 Suka
Hadiah
14
6
Bagikan
Komentar
0/400
LadderToolGuy
· 08-01 17:23
Data sejarah bahkan berani dihapus
Lihat AsliBalas0
Ser_APY_2000
· 08-01 13:46
v神 benar-benar bisa membuat masalah
Lihat AsliBalas0
TrustlessMaximalist
· 07-29 18:30
Vitalik Buterin berbicara masih sangat solid.
Lihat AsliBalas0
ConfusedWhale
· 07-29 18:27
v神 masih berbicara dengan cara yang sangat mendalam
Lihat AsliBalas0
hodl_therapist
· 07-29 18:17
Apa yang dikatakan Lao V tidak salah
Lihat AsliBalas0
MetaverseLandlord
· 07-29 18:06
Ruang penyimpanan terlalu mahal, lebih baik dibersihkan daripada disimpan.
Ethereum The Purge: Drop penyimpanan sejarah Sederhanakan protokol Tingkatkan keberlanjutan
Masa Depan Ethereum yang Mungkin: The Purge
Penulis: Vitalik Buterin
Salah satu tantangan yang dihadapi Ethereum adalah, secara default, pembengkakan dan kompleksitas dari protokol blockchain mana pun akan meningkat seiring berjalannya waktu. Ini terjadi dalam dua aspek:
Data Historis: Semua transaksi dan akun yang dibuat pada setiap momen dalam sejarah perlu disimpan secara permanen oleh semua klien, dan diunduh oleh klien baru untuk sepenuhnya disinkronkan dengan jaringan. Ini menyebabkan beban klien dan waktu sinkronisasi terus meningkat, meskipun kapasitas rantai tetap tidak berubah.
Fungsi protokol: Menambahkan fitur baru jauh lebih mudah daripada menghapus fitur lama, menyebabkan kompleksitas kode meningkat seiring waktu.
Untuk menjaga agar Ethereum dapat bertahan dalam jangka panjang, kita perlu memberikan tekanan yang kuat terhadap dua tren ini, mengurangi kompleksitas dan inflasi seiring waktu. Sementara itu, kita perlu mempertahankan salah satu atribut kunci yang membuat blockchain menjadi hebat: ketahanan. Anda dapat menempatkan NFT, surat cinta dalam catatan transaksi, atau kontrak pintar yang berisi 1 juta dolar di dalam rantai, dan 10 tahun kemudian itu masih ada menunggu Anda untuk dibaca dan diinteraksi. Agar DApp dapat sepenuhnya terdesentralisasi dan menghapus kunci upgrade dengan aman, mereka perlu yakin bahwa ketergantungan mereka tidak akan diupgrade dengan cara yang merusak mereka - terutama L1 itu sendiri.
Jika kita bertekad untuk mencapai keseimbangan antara kedua kebutuhan ini, dan meminimalkan atau membalikkan pembengkakan, kompleksitas, dan penurunan sambil menjaga kontinuitas, itu sangat mungkin. Organisme dapat melakukannya: meskipun sebagian besar organisme menua seiring waktu, beberapa yang beruntung tidak. Bahkan sistem sosial pun dapat memiliki umur yang sangat panjang. Dalam beberapa kasus, Ethereum telah berhasil: bukti kerja menghilang, opcode SELFDESTRUCT sebagian besar hilang, dan node beacon chain telah menyimpan data lama selama maksimal enam bulan. Menemukan jalan ini untuk Ethereum dengan cara yang lebih umum dan menuju hasil akhir yang stabil dalam jangka panjang adalah tantangan utama bagi skalabilitas jangka panjang Ethereum, keberlanjutan teknologi, bahkan keamanan.
Tujuan utama The Purge:
Masa berlaku sejarah
Apa masalah yang diselesaikan?
Hingga saat penulisan ini, node Ethereum yang sepenuhnya disinkronkan membutuhkan sekitar 1,1 TB ruang disk untuk menjalankan klien, ditambah lagi beberapa ratus GB ruang disk untuk klien konsensus. Sebagian besar dari ini adalah sejarah: data tentang blok, transaksi, dan bukti sejarah, yang sebagian besar sudah berusia bertahun-tahun. Ini berarti bahwa bahkan jika batas Gas tidak meningkat sama sekali, ukuran node akan terus meningkat beberapa ratus GB setiap tahun.
Apa itu, bagaimana cara kerjanya?
Salah satu fitur penyederhanaan kunci dari masalah penyimpanan sejarah adalah, karena setiap blok terhubung dengan hash ( dan struktur lain ) yang menunjuk ke blok sebelumnya, maka konsensus saat ini sudah cukup untuk mencapai konsensus sejarah. Selama jaringan mencapai konsensus pada blok terbaru, blok atau transaksi atau status sejarah ( saldo akun, angka acak, kode, penyimpanan ) dapat disediakan oleh peserta tunggal mana pun serta bukti Merkle, dan bukti tersebut memungkinkan orang lain untuk memverifikasi kebenarannya. Konsensus adalah model kepercayaan N/2-of-N, sedangkan sejarah adalah model kepercayaan N-of-N.
Ini memberikan banyak pilihan tentang bagaimana kita menyimpan catatan sejarah. Salah satu pilihan yang alami adalah jaringan di mana setiap node hanya menyimpan sebagian kecil data. Inilah cara kerja jaringan benih selama beberapa dekade: meskipun jaringan secara total menyimpan dan mendistribusikan jutaan file, setiap peserta hanya menyimpan dan mendistribusikan beberapa file di antaranya. Mungkin bertentangan dengan intuisi, pendekatan ini bahkan tidak selalu mengurangi ketahanan data. Jika dengan membuat node berjalan lebih ekonomis, kita dapat membangun jaringan dengan 100.000 node, di mana setiap node menyimpan 10% catatan sejarah secara acak, maka setiap data akan disalin 10.000 kali - sama persis dengan faktor salinan dari jaringan 10.000 node, di mana setiap node menyimpan semua konten.
Saat ini, Ethereum telah mulai melepaskan model di mana semua node menyimpan semua sejarah secara permanen. Konsensus blok ( terkait dengan bagian konsensus bukti kepemilikan yang hanya menyimpan sekitar 6 bulan. Blob hanya menyimpan sekitar 18 hari. EIP-4444 bertujuan untuk memperkenalkan periode penyimpanan satu tahun untuk blok dan penerimaan sejarah. Tujuan jangka panjang adalah untuk membangun periode yang seragam ) mungkin sekitar 18 hari (, di mana setiap node bertanggung jawab untuk menyimpan semua konten, dan kemudian membangun jaringan peer-to-peer yang terdiri dari node Ethereum untuk menyimpan data lama dengan cara terdistribusi.
Kode penghapusan dapat digunakan untuk meningkatkan ketahanan, sambil mempertahankan faktor replikasi yang sama. Faktanya, Blob telah menggunakan kode penghapusan untuk mendukung pengambilan ketersediaan data. Solusi yang paling sederhana kemungkinan adalah menggunakan kembali kode penghapusan ini, dan juga memasukkan data blok eksekusi dan konsensus ke dalam blob.
) apa hubungan dengan penelitian yang ada?
) apa lagi yang perlu dilakukan, apa yang perlu dipertimbangkan?
Pekerjaan utama yang tersisa mencakup pembangunan dan integrasi solusi terdistribusi spesifik untuk menyimpan riwayat—setidaknya riwayat eksekusi, tetapi pada akhirnya juga mencakup konsensus dan blob. Solusi paling sederhana adalah ###i( dengan sederhana memperkenalkan perpustakaan torrent yang ada, serta )ii( solusi asli Ethereum yang disebut jaringan Portal. Setelah salah satu dari ini diperkenalkan, kita dapat membuka EIP-4444. EIP-4444 itu sendiri tidak memerlukan hard fork, tetapi memang memerlukan versi protokol jaringan yang baru. Oleh karena itu, mengaktifkannya secara bersamaan untuk semua klien adalah berharga, jika tidak ada risiko klien mengalami kegagalan karena terhubung ke node lain yang mengharapkan untuk mengunduh riwayat lengkap tetapi sebenarnya tidak diperoleh.
Pertimbangan utama melibatkan bagaimana kita berusaha untuk menyediakan data sejarah "kuno". Solusi termudah adalah berhenti menyimpan sejarah kuno besok, dan mengandalkan node arsip yang ada dan berbagai penyedia terpusat untuk replikasi. Ini mudah, tetapi ini melemahkan posisi Ethereum sebagai tempat catatan permanen. Cara yang lebih sulit tetapi lebih aman adalah dengan terlebih dahulu membangun dan mengintegrasikan jaringan torrent untuk menyimpan catatan secara terdistribusi. Di sini, "seberapa keras kita berusaha" memiliki dua dimensi:
Bagaimana kami berusaha memastikan bahwa kumpulan node terbesar benar-benar menyimpan semua data?
Seberapa dalam kita mengintegrasikan penyimpanan sejarah ke dalam protokol?
Sebuah metode ekstrem yang paranoid untuk ) akan melibatkan bukti kustodian: pada dasarnya meminta setiap validator bukti kepemilikan untuk menyimpan proporsi tertentu dari riwayat, dan secara berkala memeriksa dengan cara yang terenkripsi apakah mereka melakukan hal tersebut. Metode yang lebih moderat adalah menetapkan standar sukarela untuk persentase riwayat yang disimpan oleh setiap klien.
Untuk (2), implementasi dasar hanya melibatkan pekerjaan yang telah diselesaikan hari ini: Portal telah menyimpan file ERA yang mencakup seluruh sejarah Ethereum. Implementasi yang lebih menyeluruh akan melibatkan penghubungan sebenarnya ke proses sinkronisasi, sehingga, jika seseorang ingin menyinkronkan node penyimpanan sejarah lengkap atau node arsip, meskipun tidak ada node arsip lain yang online, mereka dapat mencapainya dengan langsung menyinkronkan dari jaringan portal.
( Bagaimana itu berinteraksi dengan bagian lain dari peta jalan?
Jika kita ingin membuat menjalankan atau memulai node menjadi sangat mudah, maka mengurangi kebutuhan penyimpanan sejarah bisa dibilang lebih penting daripada tanpa status: dari 1,1 TB yang diperlukan node, sekitar 300 GB adalah status, sementara sekitar 800 GB telah menjadi sejarah. Hanya dengan mencapai tanpa status dan EIP-4444, visi untuk menjalankan node Ethereum di jam tangan pintar dan hanya membutuhkan beberapa menit untuk diatur dapat terwujud.
Pembatasan penyimpanan sejarah juga membuat implementasi node Ethereum yang lebih baru menjadi lebih praktis, hanya mendukung versi terbaru dari protokol, yang membuatnya menjadi lebih sederhana. Misalnya, sekarang banyak baris kode dapat dihapus dengan aman, karena slot penyimpanan kosong yang dibuat selama serangan DoS tahun 2016 telah sepenuhnya dihapus. Sekarang setelah peralihan ke bukti kepemilikan telah menjadi sejarah, klien dapat dengan aman menghapus semua kode yang terkait dengan bukti kerja.
![Vitalik: Masa Depan Potensial Ethereum, The Purge])https://img-cdn.gateio.im/webp-social/moments-b4e683a9e42e4b5bd6991a4cf6cf948e.webp###
Kadaluarsa negara
( Apa yang menjadi solusi?
Meskipun kami menghilangkan kebutuhan untuk menyimpan riwayat di klien, kebutuhan penyimpanan klien akan terus tumbuh, sekitar 50 GB per tahun, karena status terus berkembang: saldo akun dan angka acak, kode kontrak dan penyimpanan kontrak. Pengguna dapat membayar biaya sekali saja, sehingga selamanya membebani klien Ethereum saat ini dan di masa depan.
Status lebih sulit "kedaluwarsa" dibandingkan sejarah, karena EVM pada dasarnya dirancang dengan asumsi bahwa: setelah objek status dibuat, itu akan selalu ada dan dapat dibaca kapan saja oleh transaksi mana pun. Jika kita memperkenalkan tanpa status, beberapa orang berpendapat bahwa masalah ini mungkin tidak seburuk itu: hanya kelas pembangun blok khusus yang perlu benar-benar menyimpan status, sementara semua node lainnya ) bahkan termasuk daftar menghasilkan! ### dapat berjalan tanpa status. Namun, ada pandangan bahwa kita tidak ingin terlalu bergantung pada tanpa status, pada akhirnya kita mungkin ingin membuat status kedaluwarsa untuk menjaga desentralisasi Ethereum.
( Apa itu, bagaimana cara kerjanya
Hari ini, ketika Anda membuat objek status baru, ) dapat terjadi melalui salah satu dari tiga cara berikut: ###i ( mengirim ETH ke akun baru, (ii ) membuat akun baru menggunakan kode, (iii ) mengatur slot penyimpanan yang sebelumnya tidak terjangkau (, objek status ini akan selalu berada dalam keadaan tersebut. Sebaliknya, yang kita inginkan adalah objek yang secara otomatis kedaluwarsa seiring waktu. Tantangan kuncinya adalah melakukannya dengan cara yang memenuhi tiga tujuan.
Efisiensi: tidak memerlukan perhitungan tambahan yang besar untuk menjalankan proses kedaluwarsa.
Kemudahan Pengguna: Jika seseorang masuk ke dalam gua selama lima tahun dan kembali, mereka seharusnya tidak kehilangan akses ke ETH, ERC20, NFT, posisi CDP......
Ramah bagi Pengembang: Pengembang tidak perlu beralih ke model pemikiran yang sepenuhnya tidak dikenal. Selain itu, aplikasi yang saat ini sudah kaku dan tidak diperbarui seharusnya dapat terus berfungsi dengan baik.
Tidak memenuhi tujuan ini sangat mudah untuk menyelesaikan masalah. Misalnya, Anda dapat membuat setiap objek status juga menyimpan penghitung tanggal kedaluwarsa ) yang dapat diperpanjang dengan membakar ETH, yang mungkin secara otomatis terjadi kapan saja saat dibaca atau ditulis ), dan memiliki proses yang melintasi status untuk menghapus objek status tanggal kedaluwarsa. Namun, ini memperkenalkan kebutuhan komputasi tambahan ( bahkan kebutuhan penyimpanan ), dan pasti tidak dapat memenuhi tuntutan ramah pengguna. Pengembang juga kesulitan untuk menyimpulkan situasi tepi yang melibatkan nilai penyimpanan yang kadang-kadang direset menjadi nol. Jika Anda mengatur penghitung kedaluwarsa dalam ruang lingkup kontrak, ini secara teknis akan membuat hidup pengembang lebih mudah, tetapi akan membuat ekonomi menjadi lebih sulit: pengembang harus mempertimbangkan bagaimana "mengalihkan" biaya penyimpanan yang berkelanjutan kepada pengguna.
Ini semua adalah masalah yang telah diupayakan oleh komunitas pengembang inti Ethereum selama bertahun-tahun, termasuk proposal seperti "sewa blockchain" dan "regenerasi". Akhirnya, kami menggabungkan bagian terbaik dari proposal tersebut dan fokus pada dua kategori "solusi yang paling tidak buruk yang diketahui":
( Masa kedaluwarsa sebagian dari status
Beberapa proposal status yang kadaluarsa mengikuti prinsip yang sama. Kami membagi status menjadi blok. Setiap orang secara permanen menyimpan "peta teratas", di mana blok tersebut kosong atau tidak kosong. Data dalam setiap blok hanya akan disimpan jika data tersebut baru saja diakses. Ada mekanisme "kebangkitan" yang jika tidak lagi disimpan
Perbedaan utama antara proposal ini adalah: )i### bagaimana kita mendefinisikan "terbaru", dan (ii) bagaimana kita mendefinisikan "blok"? Salah satu proposal khusus adalah EIP-7736, yang dibangun di atas "batang dan daun" yang diperkenalkan untuk pohon Verkle desain ( meskipun kompatibilitas dengan segala bentuk status stateless, seperti ) pohon biner. Dalam desain ini, header, kode, dan slot yang berdekatan satu sama lain disimpan di bawah "tulang punggung" yang sama. Data yang disimpan di bawah satu batang dapat mencapai 256 * 31 = 7.936 byte. Dalam banyak kasus, seluruh header dan kode akun, serta banyak slot kunci, akan disimpan di bawah tulang punggung yang sama. Jika data di bawah tulang punggung tertentu belum dibaca atau ditulis dalam waktu 6 bulan, data tidak lagi disimpan, tetapi hanya 32 byte dari data tersebut yang disimpan