Salah satu tantangan yang dihadapi Ethereum adalah, secara default, ekspansi dan kompleksitas dari protokol blockchain mana pun akan meningkat seiring berjalannya waktu. Ini terjadi dalam dua aspek:
Data sejarah: Setiap transaksi yang dilakukan dan setiap akun yang dibuat pada waktu tertentu dalam sejarah perlu disimpan secara permanen oleh semua klien dan diunduh oleh setiap klien baru, sehingga sepenuhnya disinkronkan dengan jaringan. Ini akan menyebabkan beban klien dan waktu sinkronisasi terus meningkat seiring berjalannya waktu, bahkan jika kapasitas rantai tetap tidak berubah.
Fungsionalitas protokol: Menambahkan fitur baru jauh lebih mudah daripada menghapus fitur lama, yang menyebabkan kompleksitas kode meningkat seiring berjalannya waktu.
Agar Ethereum dapat bertahan dalam jangka panjang, kita perlu memberikan tekanan balik yang kuat terhadap kedua tren ini, mengurangi kompleksitas dan ekspansi seiring berjalannya waktu. Namun, pada saat yang sama, kita perlu mempertahankan salah satu sifat kunci yang membuat blockchain menjadi hebat: ketahanan. Anda bisa menempatkan NFT, sebuah surat cinta dalam data panggilan transaksi, atau kontrak pintar yang berisi 1 juta dolar di dalam rantai, masuk ke dalam gua selama sepuluh tahun, dan saat keluar, Anda akan menemukan bahwa itu masih ada di sana menunggu Anda untuk membaca dan berinteraksi. Agar DApp dapat sepenuhnya terdesentralisasi dengan tenang dan menghapus kunci upgrade, 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 dua kebutuhan ini, dan meminimalkan atau membalikkan pembengkakan, kompleksitas, dan penurunan sambil mempertahankan kontinuitas, itu benar-benar mungkin. Organisme dapat melakukan ini: meskipun sebagian besar organisme menua seiring waktu, sedikit yang beruntung tidak. Bahkan sistem sosial dapat memiliki umur yang sangat panjang. Dalam beberapa kasus, Ethereum telah berhasil: bukti kerja telah menghilang, opcode SELFDESTRUCT sebagian besar telah hilang, dan node rantai beacon telah menyimpan data lama selama maksimum enam bulan. Menemukan jalan ini untuk Ethereum dengan cara yang lebih umum dan menuju hasil akhir yang stabil dalam jangka panjang adalah tantangan utama untuk skalabilitas jangka panjang Ethereum, keberlanjutan teknologi, dan bahkan keamanan.
The Purge: Tujuan Utama
Mengurangi persyaratan penyimpanan klien dengan mengurangi atau menghilangkan kebutuhan setiap node untuk secara permanen menyimpan semua catatan sejarah bahkan status akhir.
Mengurangi kompleksitas protokol dengan menghilangkan fitur yang tidak diperlukan.
Kedaluwarsa sejarah
Apa masalah yang diselesaikan?
Pada saat penulisan ini, node Ethereum yang sepenuhnya disinkronkan memerlukan sekitar 1,1 TB ruang disk untuk menjalankan klien, ditambah ratusan GB ruang disk untuk klien konsensus. Sebagian besar adalah sejarah: data tentang blok sejarah, transaksi, dan bukti, di mana sebagian besar sudah berusia bertahun-tahun. Ini berarti bahwa bahkan jika batas Gas tidak meningkat sama sekali, ukuran node akan terus meningkat ratusan GB setiap tahun.
Apa itu, dan bagaimana cara kerjanya?
Salah satu fitur penyederhanaan kunci dari masalah penyimpanan sejarah adalah bahwa karena setiap blok terhubung ke blok sebelumnya melalui tautan hash (dan struktur lainnya), mencapai konsensus saat ini sudah cukup untuk mencapai konsensus sejarah. Selama jaringan mencapai konsensus pada blok terbaru, blok, transaksi, atau status sejarah (saldo akun, angka acak, kode, penyimpanan) mana pun dapat disediakan oleh peserta individu serta bukti Merkle, dan bukti tersebut memungkinkan orang lain untuk memverifikasi kebenarannya. Konsensus adalah model kepercayaan N/2-of-N, sementara 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 menyimpan dan mendistribusikan jutaan file, setiap peserta hanya menyimpan dan mendistribusikan beberapa file di antaranya. Mungkin bertentangan dengan intuisi, pendekatan ini bahkan tidak harus mengurangi ketahanan data. Jika dengan membuat node beroperasi 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 semuanya.
Saat ini, Ethereum telah mulai melepaskan semua node dari model penyimpanan permanen semua sejarah. Blok konsensus (yaitu bagian yang terkait dengan konsensus bukti kepemilikan) hanya menyimpan sekitar 6 bulan. Blob hanya menyimpan sekitar 18 hari. EIP-4444 bertujuan untuk memperkenalkan periode penyimpanan satu tahun untuk blok dan tanda terima sejarah. Tujuan jangka panjang adalah untuk membangun periode yang terpadu (mungkin sekitar 18 hari), selama mana setiap node bertanggung jawab untuk menyimpan semua konten, kemudian membangun jaringan peer-to-peer yang terdiri dari node Ethereum yang menyimpan data lama dengan cara terdistribusi.
Kode penghapusan dapat digunakan untuk meningkatkan ketahanan, sambil mempertahankan faktor duplikasi yang sama. Faktanya, Blob sudah menerapkan kode penghapusan untuk mendukung pengambilan data yang tersedia. Solusi yang paling sederhana kemungkinan adalah dengan menggunakan kembali kode penghapusan ini, dan juga memasukkan data blok eksekusi dan konsensus ke dalam blob.
memiliki hubungan dengan penelitian yang ada?
EIP-4444
Torrents dan EIP-4444
Jaringan Portal
Jaringan portal dan EIP-4444
Penyimpanan dan pengambilan objek SSZ yang terdistribusi di Portal
Bagaimana cara meningkatkan batas gas (Paradigm)
apa lagi yang perlu dilakukan, apa yang perlu dipertimbangkan?
Pekerjaan utama yang tersisa meliputi membangun dan mengintegrasikan solusi terdistribusi yang konkret untuk menyimpan catatan sejarah------setidaknya catatan eksekusi, tetapi akhirnya juga termasuk konsensus dan blob. Solusi yang paling sederhana adalah (i) dengan sederhana memperkenalkan pustaka torrent yang ada, serta (ii) yang disebut solusi asli Ethereum dari Portal Network. 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 untuk semua klien secara bersamaan adalah berharga, jika tidak ada risiko klien mengalami kegagalan karena terhubung ke node lain yang mengharapkan untuk mengunduh catatan sejarah lengkap tetapi sebenarnya tidak mendapatkan.
Perimbangan utama melibatkan bagaimana kita berusaha untuk menyediakan data sejarah "kuno". Solusi yang paling sederhana adalah berhenti menyimpan sejarah kuno besok dan mengandalkan node arsip yang ada serta berbagai penyedia terpusat untuk replikasi. Ini mudah, tetapi 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 kita berusaha memastikan bahwa kumpulan node terbesar benar-benar menyimpan semua data?
Seberapa dalam integrasi penyimpanan historis ke dalam protokol?
Salah satu metode yang sangat paranoid untuk (1) akan melibatkan bukti custodial: secara praktis mengharuskan setiap validator bukti kepemilikan untuk menyimpan proporsi tertentu dari catatan sejarah, dan secara berkala memeriksa secara kriptografi apakah mereka melakukannya. Metode yang lebih moderat adalah menetapkan standar sukarela untuk persentase sejarah yang disimpan oleh setiap klien.
Untuk (2), implementasi dasar hanya melibatkan pekerjaan yang telah diselesaikan hari ini: Portal telah menyimpan file ERA yang berisi 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, bahkan jika tidak ada node arsip lain yang online, mereka dapat mencapainya melalui sinkronisasi langsung dari jaringan portal.
Bagaimana itu berinteraksi dengan bagian lain dari peta jalan?
Jika kita ingin membuat operasi atau peluncuran node menjadi sangat mudah, maka mengurangi kebutuhan penyimpanan sejarah bisa dibilang lebih penting daripada tanpa status: dari 1,1 TB yang dibutuhkan node, sekitar 300 GB adalah status, dan sekitar 800 GB telah menjadi sejarah. Hanya dengan mencapai tanpa status dan EIP-4444, visi untuk menjalankan node Ethereum di smartwatch dan hanya memerlukan beberapa menit untuk diatur dapat terwujud.
Pembatasan penyimpanan sejarah juga membuat implementasi node Ethereum yang lebih baru menjadi lebih layak, 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 pada tahun 2016 telah dihapus sepenuhnya. Sekarang bahwa peralihan ke proof of stake telah menjadi sejarah, klien dapat dengan aman menghapus semua kode yang terkait dengan proof of work.
Masa kedaluwarsa negara
Apa masalah yang diselesaikan?
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, sehingga membebani klien Ethereum saat ini dan di masa depan selamanya.
Status lebih sulit "kedaluwarsa" daripada sejarah, karena EVM pada dasarnya dirancang berdasarkan asumsi ini: setelah objek status dibuat, ia 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 yang mencakup pembuatan daftar!) dapat berjalan tanpa status. Namun, ada pandangan bahwa kita tidak ingin terlalu bergantung pada tanpa status, dan akhirnya kita mungkin ingin membuat status kedaluwarsa untuk menjaga desentralisasi Ethereum.
Apa itu, dan bagaimana cara kerjanya
Hari ini, ketika Anda membuat objek status baru (yang 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 tersentuh), objek status tersebut akan selamanya berada dalam status tersebut. Sebaliknya, yang kami inginkan adalah objek tersebut secara otomatis kedaluwarsa seiring waktu. Tantangan kunci adalah melakukannya dengan cara yang memenuhi tiga tujuan:
Efisiensi: Tidak perlu banyak perhitungan tambahan untuk menjalankan proses kedaluwarsa.
Kemudahan Pengguna: Jika seseorang masuk ke dalam gua selama lima tahun dan kembali, mereka tidak seharusnya kehilangan akses ke posisi ETH, ERC20, NFT, CDP...
Ramah Pengembang: Pengembang tidak perlu beralih ke model pemikiran yang sepenuhnya tidak dikenal. Selain itu, aplikasi yang saat ini kaku dan tidak diperbarui harus dapat terus berjalan dengan normal.
Tidak memenuhi tujuan ini dapat membuat masalah mudah diselesaikan. Misalnya, Anda dapat membuat setiap objek status juga menyimpan penghitung tanggal kedaluwarsa (yang dapat diperpanjang dengan membakar Ether, yang mungkin secara otomatis terjadi kapan saja saat dibaca atau ditulis), dan memiliki proses yang melintasi status untuk menghapus objek status dengan tanggal kedaluwarsa. Namun, ini memperkenalkan perhitungan tambahan (bahkan kebutuhan penyimpanan), dan itu pasti tidak dapat memenuhi persyaratan ramah pengguna. Pengembang juga kesulitan untuk menyimpulkan kasus tepi yang melibatkan nilai penyimpanan yang kadang-kadang direset menjadi nol. Jika Anda mengatur penghitung kedaluwarsa dalam lingkup kontrak, secara teknis ini akan memudahkan hidup pengembang, 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 dan fokus pada dua kategori "solusi yang paling tidak buruk yang diketahui":
Solusi status sebagian kadaluarsa
Saran kedaluwarsa status berdasarkan periode alamat.
Masa kadaluarsa bagian status
Beberapa proposal status yang kedaluwarsa mengikuti prinsip yang sama. Kami membagi status menjadi blok. Setiap orang secara permanen menyimpan "peta teratas", di mana blok tersebut bisa kosong atau tidak kosong. Data dalam setiap blok hanya akan disimpan jika data tersebut baru-baru ini diakses. Ada mekanisme "kebangkitan", jika tidak lagi disimpan
Perbedaan utama antara proposal-proposal ini adalah: (i) bagaimana kita mendefinisikan "terakhir", dan (ii) saya
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.
13 Suka
Hadiah
13
5
Bagikan
Komentar
0/400
MidnightSnapHunter
· 9jam yang lalu
Apakah Vitalik Buterin akhirnya akan melakukan likuidasi?
Lihat AsliBalas0
PriceOracleFairy
· 07-24 21:24
bloat protokol ngl itu nyata... mimpi buruk skala membuatku terjaga sampai jam 3 pagi fr
Lihat AsliBalas0
WhaleWatcher
· 07-24 21:14
Vitalik Buterin tolong bantu saya hitung biaya penyimpanan ya
Vitalik membahas The Purge: jalan keberlanjutan jangka panjang Ethereum
Vitalik: Masa Depan Potensial Ethereum, The Purge
Salah satu tantangan yang dihadapi Ethereum adalah, secara default, ekspansi dan kompleksitas dari protokol blockchain mana pun akan meningkat seiring berjalannya waktu. Ini terjadi dalam dua aspek:
Data sejarah: Setiap transaksi yang dilakukan dan setiap akun yang dibuat pada waktu tertentu dalam sejarah perlu disimpan secara permanen oleh semua klien dan diunduh oleh setiap klien baru, sehingga sepenuhnya disinkronkan dengan jaringan. Ini akan menyebabkan beban klien dan waktu sinkronisasi terus meningkat seiring berjalannya waktu, bahkan jika kapasitas rantai tetap tidak berubah.
Fungsionalitas protokol: Menambahkan fitur baru jauh lebih mudah daripada menghapus fitur lama, yang menyebabkan kompleksitas kode meningkat seiring berjalannya waktu.
Agar Ethereum dapat bertahan dalam jangka panjang, kita perlu memberikan tekanan balik yang kuat terhadap kedua tren ini, mengurangi kompleksitas dan ekspansi seiring berjalannya waktu. Namun, pada saat yang sama, kita perlu mempertahankan salah satu sifat kunci yang membuat blockchain menjadi hebat: ketahanan. Anda bisa menempatkan NFT, sebuah surat cinta dalam data panggilan transaksi, atau kontrak pintar yang berisi 1 juta dolar di dalam rantai, masuk ke dalam gua selama sepuluh tahun, dan saat keluar, Anda akan menemukan bahwa itu masih ada di sana menunggu Anda untuk membaca dan berinteraksi. Agar DApp dapat sepenuhnya terdesentralisasi dengan tenang dan menghapus kunci upgrade, 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 dua kebutuhan ini, dan meminimalkan atau membalikkan pembengkakan, kompleksitas, dan penurunan sambil mempertahankan kontinuitas, itu benar-benar mungkin. Organisme dapat melakukan ini: meskipun sebagian besar organisme menua seiring waktu, sedikit yang beruntung tidak. Bahkan sistem sosial dapat memiliki umur yang sangat panjang. Dalam beberapa kasus, Ethereum telah berhasil: bukti kerja telah menghilang, opcode SELFDESTRUCT sebagian besar telah hilang, dan node rantai beacon telah menyimpan data lama selama maksimum enam bulan. Menemukan jalan ini untuk Ethereum dengan cara yang lebih umum dan menuju hasil akhir yang stabil dalam jangka panjang adalah tantangan utama untuk skalabilitas jangka panjang Ethereum, keberlanjutan teknologi, dan bahkan keamanan.
The Purge: Tujuan Utama
Mengurangi persyaratan penyimpanan klien dengan mengurangi atau menghilangkan kebutuhan setiap node untuk secara permanen menyimpan semua catatan sejarah bahkan status akhir.
Mengurangi kompleksitas protokol dengan menghilangkan fitur yang tidak diperlukan.
Kedaluwarsa sejarah
Apa masalah yang diselesaikan?
Pada saat penulisan ini, node Ethereum yang sepenuhnya disinkronkan memerlukan sekitar 1,1 TB ruang disk untuk menjalankan klien, ditambah ratusan GB ruang disk untuk klien konsensus. Sebagian besar adalah sejarah: data tentang blok sejarah, transaksi, dan bukti, di mana sebagian besar sudah berusia bertahun-tahun. Ini berarti bahwa bahkan jika batas Gas tidak meningkat sama sekali, ukuran node akan terus meningkat ratusan GB setiap tahun.
Apa itu, dan bagaimana cara kerjanya?
Salah satu fitur penyederhanaan kunci dari masalah penyimpanan sejarah adalah bahwa karena setiap blok terhubung ke blok sebelumnya melalui tautan hash (dan struktur lainnya), mencapai konsensus saat ini sudah cukup untuk mencapai konsensus sejarah. Selama jaringan mencapai konsensus pada blok terbaru, blok, transaksi, atau status sejarah (saldo akun, angka acak, kode, penyimpanan) mana pun dapat disediakan oleh peserta individu serta bukti Merkle, dan bukti tersebut memungkinkan orang lain untuk memverifikasi kebenarannya. Konsensus adalah model kepercayaan N/2-of-N, sementara 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 menyimpan dan mendistribusikan jutaan file, setiap peserta hanya menyimpan dan mendistribusikan beberapa file di antaranya. Mungkin bertentangan dengan intuisi, pendekatan ini bahkan tidak harus mengurangi ketahanan data. Jika dengan membuat node beroperasi 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 semuanya.
Saat ini, Ethereum telah mulai melepaskan semua node dari model penyimpanan permanen semua sejarah. Blok konsensus (yaitu bagian yang terkait dengan konsensus bukti kepemilikan) hanya menyimpan sekitar 6 bulan. Blob hanya menyimpan sekitar 18 hari. EIP-4444 bertujuan untuk memperkenalkan periode penyimpanan satu tahun untuk blok dan tanda terima sejarah. Tujuan jangka panjang adalah untuk membangun periode yang terpadu (mungkin sekitar 18 hari), selama mana setiap node bertanggung jawab untuk menyimpan semua konten, kemudian membangun jaringan peer-to-peer yang terdiri dari node Ethereum yang menyimpan data lama dengan cara terdistribusi.
Kode penghapusan dapat digunakan untuk meningkatkan ketahanan, sambil mempertahankan faktor duplikasi yang sama. Faktanya, Blob sudah menerapkan kode penghapusan untuk mendukung pengambilan data yang tersedia. Solusi yang paling sederhana kemungkinan adalah dengan menggunakan kembali kode penghapusan ini, dan juga memasukkan data blok eksekusi dan konsensus ke dalam blob.
memiliki hubungan dengan penelitian yang ada?
apa lagi yang perlu dilakukan, apa yang perlu dipertimbangkan?
Pekerjaan utama yang tersisa meliputi membangun dan mengintegrasikan solusi terdistribusi yang konkret untuk menyimpan catatan sejarah------setidaknya catatan eksekusi, tetapi akhirnya juga termasuk konsensus dan blob. Solusi yang paling sederhana adalah (i) dengan sederhana memperkenalkan pustaka torrent yang ada, serta (ii) yang disebut solusi asli Ethereum dari Portal Network. 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 untuk semua klien secara bersamaan adalah berharga, jika tidak ada risiko klien mengalami kegagalan karena terhubung ke node lain yang mengharapkan untuk mengunduh catatan sejarah lengkap tetapi sebenarnya tidak mendapatkan.
Perimbangan utama melibatkan bagaimana kita berusaha untuk menyediakan data sejarah "kuno". Solusi yang paling sederhana adalah berhenti menyimpan sejarah kuno besok dan mengandalkan node arsip yang ada serta berbagai penyedia terpusat untuk replikasi. Ini mudah, tetapi 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 kita berusaha memastikan bahwa kumpulan node terbesar benar-benar menyimpan semua data?
Seberapa dalam integrasi penyimpanan historis ke dalam protokol?
Salah satu metode yang sangat paranoid untuk (1) akan melibatkan bukti custodial: secara praktis mengharuskan setiap validator bukti kepemilikan untuk menyimpan proporsi tertentu dari catatan sejarah, dan secara berkala memeriksa secara kriptografi apakah mereka melakukannya. Metode yang lebih moderat adalah menetapkan standar sukarela untuk persentase sejarah yang disimpan oleh setiap klien.
Untuk (2), implementasi dasar hanya melibatkan pekerjaan yang telah diselesaikan hari ini: Portal telah menyimpan file ERA yang berisi 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, bahkan jika tidak ada node arsip lain yang online, mereka dapat mencapainya melalui sinkronisasi langsung dari jaringan portal.
Bagaimana itu berinteraksi dengan bagian lain dari peta jalan?
Jika kita ingin membuat operasi atau peluncuran node menjadi sangat mudah, maka mengurangi kebutuhan penyimpanan sejarah bisa dibilang lebih penting daripada tanpa status: dari 1,1 TB yang dibutuhkan node, sekitar 300 GB adalah status, dan sekitar 800 GB telah menjadi sejarah. Hanya dengan mencapai tanpa status dan EIP-4444, visi untuk menjalankan node Ethereum di smartwatch dan hanya memerlukan beberapa menit untuk diatur dapat terwujud.
Pembatasan penyimpanan sejarah juga membuat implementasi node Ethereum yang lebih baru menjadi lebih layak, 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 pada tahun 2016 telah dihapus sepenuhnya. Sekarang bahwa peralihan ke proof of stake telah menjadi sejarah, klien dapat dengan aman menghapus semua kode yang terkait dengan proof of work.
Masa kedaluwarsa negara
Apa masalah yang diselesaikan?
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, sehingga membebani klien Ethereum saat ini dan di masa depan selamanya.
Status lebih sulit "kedaluwarsa" daripada sejarah, karena EVM pada dasarnya dirancang berdasarkan asumsi ini: setelah objek status dibuat, ia 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 yang mencakup pembuatan daftar!) dapat berjalan tanpa status. Namun, ada pandangan bahwa kita tidak ingin terlalu bergantung pada tanpa status, dan akhirnya kita mungkin ingin membuat status kedaluwarsa untuk menjaga desentralisasi Ethereum.
Apa itu, dan bagaimana cara kerjanya
Hari ini, ketika Anda membuat objek status baru (yang 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 tersentuh), objek status tersebut akan selamanya berada dalam status tersebut. Sebaliknya, yang kami inginkan adalah objek tersebut secara otomatis kedaluwarsa seiring waktu. Tantangan kunci adalah melakukannya dengan cara yang memenuhi tiga tujuan:
Efisiensi: Tidak perlu banyak perhitungan tambahan untuk menjalankan proses kedaluwarsa.
Kemudahan Pengguna: Jika seseorang masuk ke dalam gua selama lima tahun dan kembali, mereka tidak seharusnya kehilangan akses ke posisi ETH, ERC20, NFT, CDP...
Ramah Pengembang: Pengembang tidak perlu beralih ke model pemikiran yang sepenuhnya tidak dikenal. Selain itu, aplikasi yang saat ini kaku dan tidak diperbarui harus dapat terus berjalan dengan normal.
Tidak memenuhi tujuan ini dapat membuat masalah mudah diselesaikan. Misalnya, Anda dapat membuat setiap objek status juga menyimpan penghitung tanggal kedaluwarsa (yang dapat diperpanjang dengan membakar Ether, yang mungkin secara otomatis terjadi kapan saja saat dibaca atau ditulis), dan memiliki proses yang melintasi status untuk menghapus objek status dengan tanggal kedaluwarsa. Namun, ini memperkenalkan perhitungan tambahan (bahkan kebutuhan penyimpanan), dan itu pasti tidak dapat memenuhi persyaratan ramah pengguna. Pengembang juga kesulitan untuk menyimpulkan kasus tepi yang melibatkan nilai penyimpanan yang kadang-kadang direset menjadi nol. Jika Anda mengatur penghitung kedaluwarsa dalam lingkup kontrak, secara teknis ini akan memudahkan hidup pengembang, 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 dan fokus pada dua kategori "solusi yang paling tidak buruk yang diketahui":
Masa kadaluarsa bagian status
Beberapa proposal status yang kedaluwarsa mengikuti prinsip yang sama. Kami membagi status menjadi blok. Setiap orang secara permanen menyimpan "peta teratas", di mana blok tersebut bisa kosong atau tidak kosong. Data dalam setiap blok hanya akan disimpan jika data tersebut baru-baru ini diakses. Ada mekanisme "kebangkitan", jika tidak lagi disimpan
Perbedaan utama antara proposal-proposal ini adalah: (i) bagaimana kita mendefinisikan "terakhir", dan (ii) saya