Kritik paling umum terhadap peningkatan batas Gas L1, selain kekhawatiran tentang keamanan jaringan, adalah bahwa ini akan membuat operasi node penuh menjadi lebih sulit. Terutama dalam konteks peta jalan yang berfokus pada "memisahkan node penuh", untuk menyelesaikan masalah ini, kita perlu terlebih dahulu memahami arti keberadaan node penuh.
Pandangan tradisional menganggap bahwa node penuh digunakan untuk memverifikasi data di blockchain. Jika ini adalah satu-satunya masalah, maka ZK-EVM dapat membuka kunci skalabilitas L1: satu-satunya batasan adalah menjaga biaya pembangunan blok dan pembuktian tetap cukup rendah, sehingga keduanya dapat mempertahankan ketahanan terhadap sensor 1 dari n dan membentuk pasar yang kompetitif.
Namun dalam kenyataannya, ini bukan satu-satunya pertimbangan. Faktor penting lainnya adalah: Menjalankan full node memungkinkan Anda memiliki server RPC lokal, sehingga dapat membaca data on-chain dengan cara yang tidak perlu mempercayai, tahan sensor, dan melindungi privasi. Artikel ini akan membahas cara menyesuaikan peta jalan perluasan L1 saat ini untuk mencapai tujuan ini.
1, Mengapa tidak puas dengan desentralisasi dan privasi yang dihasilkan oleh ZK-EVM+PIR?
Roadmap privasi yang saya rilis bulan lalu mengusulkan: dalam jangka pendek menggunakan solusi TEE + ORAM, dan dalam jangka panjang beralih ke teknologi PIR. Dengan menggabungkan Helios dan verifikasi ZK-EVM, pengguna dapat sepenuhnya yakin saat terhubung ke RPC eksternal: (i) bahwa data rantai yang diperoleh adalah benar, (ii) privasi data terlindungi. Ini menimbulkan pertanyaan: mengapa tidak berhenti di sini? Apakah solusi kriptografi canggih ini membuat node yang dikelola sendiri menjadi usang?
Saya memiliki beberapa tanggapan mengenai hal ini:
--Solusi kriptografi yang sepenuhnya tidak mempercayai (seperti PIR server tunggal) sangat mahal. Biaya saat ini terlalu tinggi untuk dianggap masuk akal, bahkan setelah beberapa optimasi efisiensi, masih mungkin tetap mahal.
--Masalah privasi metadata. Waktu permintaan alamat IP, pola permintaan, dan metadata lainnya dapat mengungkapkan banyak informasi pengguna.
--Pemeriksaan Kerentanan: Struktur pasar yang didominasi oleh beberapa penyedia RPC akan menghadapi tekanan larangan atau pemeriksaan pengguna yang kuat. Banyak penyedia RPC telah mulai sepenuhnya memblokir negara-negara tertentu.
Oleh karena itu, melanjutkan jaminan kenyamanan operasi node pribadi masih memiliki nilai.
2. Prioritas Jangka Pendek
Prioritaskan penyebaran EIP-4444 secara menyeluruh, untuk akhirnya mewujudkan setiap node hanya menyimpan data sekitar 36 hari. Ini akan secara signifikan mengurangi kebutuhan ruang hard disk—hambatan utama saat ini bagi orang untuk menjalankan node. Setelah itu, kebutuhan penyimpanan node hanya akan mencakup: (i) data status, (ii) cabang Merkle status, (iii)36 hari data historis.
Membangun solusi penyimpanan sejarah terdistribusi yang memungkinkan setiap node menyimpan sejumlah kecil data sejarah yang sudah kedaluwarsa. Maksimalkan keandalan melalui teknologi kode penghapusan. Dengan cara ini, kita dapat memastikan karakteristik "blokchain yang disimpan selamanya" tanpa bergantung pada penyedia terpusat atau membebani operator node.
Sesuaikan strategi penetapan Gas, tingkatkan biaya penyimpanan, dan kurangi biaya eksekusi. Fokuskan pada peningkatan biaya Gas untuk operasi berikut: (i) menjalankan SSTORE untuk slot penyimpanan baru (storage slot), (ii) membuat kode kontrak, (iii) mentransfer ETH ke akun dengan saldo nol/nilai nonce nol.
3, Tujuan Menengah: Verifikasi Tanpa Status
Setelah implementasi verifikasi tanpa status, menjalankan node yang mendukung RPC (yaitu node yang menyimpan status) tidak perlu menyimpan cabang Merkle status. Ini dapat mengurangi kebutuhan penyimpanan sekitar 50%.
4, Node Baru: Beberapa Node Tanpa Status
Konsep inovatif ini akan menjadi kunci untuk menjalankan node pribadi setelah peningkatan batas gas L1 sebanyak 10-100 kali.
Kami menambahkan jenis node baru: memverifikasi blok dengan cara tanpa status, melalui verifikasi tanpa status atau verifikasi ZK-EVM untuk seluruh rantai, tetapi hanya mempertahankan sebagian data status. Selama data yang diperlukan untuk permintaan RPC berada dalam subset status tersebut, node dapat merespons; permintaan lainnya akan gagal (atau perlu kembali ke solusi kriptografi yang dikelola secara eksternal - apakah akan kembali harus dipilih oleh pengguna).
Status yang dipelihara secara spesifik tergantung pada konfigurasi pengguna, misalnya:
--Kecualikan semua status di luar kontrak sampah yang diketahui.
--Status terkait semua akun EOA, SCW, serta token dan aplikasi ERC20/ERC721 yang umum digunakan.
--Status akun EOA/SCW yang aktif dalam dua tahun terakhir + status beberapa token ERC20 yang umum digunakan + status aplikasi swap/DeFi/privasi yang dipilih.
Konfigurasi dapat dikelola melalui kontrak di blockchain: Pengguna saat menjalankan node menggunakan parameter “--save_state_by_config 0x12345...67890”, alamat tersebut akan mendefinisikan daftar alamat yang perlu disimpan dan diperbarui secara real-time dalam bahasa tertentu, slot penyimpanan (storage slot), atau aturan filter status. Perhatikan bahwa pengguna tidak perlu menyimpan cabang Merkle, hanya perlu menyimpan nilai asli.
Node-node ini tidak hanya dapat memberikan keuntungan akses langsung lokal ke status kunci, tetapi juga memastikan privasi akses yang sepenuhnya.
Lihat Asli
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
Vitalik: Sebuah rencana pengoptimalan peta jalan skala yang berfokus pada node lokal
Penulis: Vitalik, pendiri Ethereum; Terjemahan: Jinse Caijing xiaozhou
Kritik paling umum terhadap peningkatan batas Gas L1, selain kekhawatiran tentang keamanan jaringan, adalah bahwa ini akan membuat operasi node penuh menjadi lebih sulit. Terutama dalam konteks peta jalan yang berfokus pada "memisahkan node penuh", untuk menyelesaikan masalah ini, kita perlu terlebih dahulu memahami arti keberadaan node penuh.
Pandangan tradisional menganggap bahwa node penuh digunakan untuk memverifikasi data di blockchain. Jika ini adalah satu-satunya masalah, maka ZK-EVM dapat membuka kunci skalabilitas L1: satu-satunya batasan adalah menjaga biaya pembangunan blok dan pembuktian tetap cukup rendah, sehingga keduanya dapat mempertahankan ketahanan terhadap sensor 1 dari n dan membentuk pasar yang kompetitif.
Namun dalam kenyataannya, ini bukan satu-satunya pertimbangan. Faktor penting lainnya adalah: Menjalankan full node memungkinkan Anda memiliki server RPC lokal, sehingga dapat membaca data on-chain dengan cara yang tidak perlu mempercayai, tahan sensor, dan melindungi privasi. Artikel ini akan membahas cara menyesuaikan peta jalan perluasan L1 saat ini untuk mencapai tujuan ini.
1, Mengapa tidak puas dengan desentralisasi dan privasi yang dihasilkan oleh ZK-EVM+PIR?
Roadmap privasi yang saya rilis bulan lalu mengusulkan: dalam jangka pendek menggunakan solusi TEE + ORAM, dan dalam jangka panjang beralih ke teknologi PIR. Dengan menggabungkan Helios dan verifikasi ZK-EVM, pengguna dapat sepenuhnya yakin saat terhubung ke RPC eksternal: (i) bahwa data rantai yang diperoleh adalah benar, (ii) privasi data terlindungi. Ini menimbulkan pertanyaan: mengapa tidak berhenti di sini? Apakah solusi kriptografi canggih ini membuat node yang dikelola sendiri menjadi usang?
Saya memiliki beberapa tanggapan mengenai hal ini:
--Solusi kriptografi yang sepenuhnya tidak mempercayai (seperti PIR server tunggal) sangat mahal. Biaya saat ini terlalu tinggi untuk dianggap masuk akal, bahkan setelah beberapa optimasi efisiensi, masih mungkin tetap mahal.
--Masalah privasi metadata. Waktu permintaan alamat IP, pola permintaan, dan metadata lainnya dapat mengungkapkan banyak informasi pengguna.
--Pemeriksaan Kerentanan: Struktur pasar yang didominasi oleh beberapa penyedia RPC akan menghadapi tekanan larangan atau pemeriksaan pengguna yang kuat. Banyak penyedia RPC telah mulai sepenuhnya memblokir negara-negara tertentu.
Oleh karena itu, melanjutkan jaminan kenyamanan operasi node pribadi masih memiliki nilai.
2. Prioritas Jangka Pendek
Prioritaskan penyebaran EIP-4444 secara menyeluruh, untuk akhirnya mewujudkan setiap node hanya menyimpan data sekitar 36 hari. Ini akan secara signifikan mengurangi kebutuhan ruang hard disk—hambatan utama saat ini bagi orang untuk menjalankan node. Setelah itu, kebutuhan penyimpanan node hanya akan mencakup: (i) data status, (ii) cabang Merkle status, (iii)36 hari data historis.
Membangun solusi penyimpanan sejarah terdistribusi yang memungkinkan setiap node menyimpan sejumlah kecil data sejarah yang sudah kedaluwarsa. Maksimalkan keandalan melalui teknologi kode penghapusan. Dengan cara ini, kita dapat memastikan karakteristik "blokchain yang disimpan selamanya" tanpa bergantung pada penyedia terpusat atau membebani operator node.
Sesuaikan strategi penetapan Gas, tingkatkan biaya penyimpanan, dan kurangi biaya eksekusi. Fokuskan pada peningkatan biaya Gas untuk operasi berikut: (i) menjalankan SSTORE untuk slot penyimpanan baru (storage slot), (ii) membuat kode kontrak, (iii) mentransfer ETH ke akun dengan saldo nol/nilai nonce nol.
3, Tujuan Menengah: Verifikasi Tanpa Status
Setelah implementasi verifikasi tanpa status, menjalankan node yang mendukung RPC (yaitu node yang menyimpan status) tidak perlu menyimpan cabang Merkle status. Ini dapat mengurangi kebutuhan penyimpanan sekitar 50%.
4, Node Baru: Beberapa Node Tanpa Status
Konsep inovatif ini akan menjadi kunci untuk menjalankan node pribadi setelah peningkatan batas gas L1 sebanyak 10-100 kali.
Kami menambahkan jenis node baru: memverifikasi blok dengan cara tanpa status, melalui verifikasi tanpa status atau verifikasi ZK-EVM untuk seluruh rantai, tetapi hanya mempertahankan sebagian data status. Selama data yang diperlukan untuk permintaan RPC berada dalam subset status tersebut, node dapat merespons; permintaan lainnya akan gagal (atau perlu kembali ke solusi kriptografi yang dikelola secara eksternal - apakah akan kembali harus dipilih oleh pengguna).
Status yang dipelihara secara spesifik tergantung pada konfigurasi pengguna, misalnya:
--Kecualikan semua status di luar kontrak sampah yang diketahui.
--Status terkait semua akun EOA, SCW, serta token dan aplikasi ERC20/ERC721 yang umum digunakan.
--Status akun EOA/SCW yang aktif dalam dua tahun terakhir + status beberapa token ERC20 yang umum digunakan + status aplikasi swap/DeFi/privasi yang dipilih.
Konfigurasi dapat dikelola melalui kontrak di blockchain: Pengguna saat menjalankan node menggunakan parameter “--save_state_by_config 0x12345...67890”, alamat tersebut akan mendefinisikan daftar alamat yang perlu disimpan dan diperbarui secara real-time dalam bahasa tertentu, slot penyimpanan (storage slot), atau aturan filter status. Perhatikan bahwa pengguna tidak perlu menyimpan cabang Merkle, hanya perlu menyimpan nilai asli.
Node-node ini tidak hanya dapat memberikan keuntungan akses langsung lokal ke status kunci, tetapi juga memastikan privasi akses yang sepenuhnya.