Menjalankan Full Node memungkinkan Anda memiliki server RPC lokal, sehingga dapat membaca data on-chain dengan cara yang tidak memerlukan kepercayaan, tahan sensor, dan melindungi privasi.
Penulis: Vitalik, pendiri Ethereum
Kompilasi: Golden Finance xiaozhou
Kritik yang paling umum terhadap peningkatan batas Gas L1, selain kekhawatiran tentang keamanan jaringan, adalah bahwa ini akan membuat menjalankan Full Node menjadi lebih sulit. Terutama dalam konteks peta jalan yang berfokus pada "membebaskan Full Node", untuk menyelesaikan masalah ini, kita perlu terlebih dahulu memahami makna keberadaan Full Node.
Pandangan tradisional menganggap bahwa Full Node digunakan untuk memverifikasi data on-chain. Jika ini adalah satu-satunya masalah, maka ZK-EVM dapat membuka kunci perluasan L1: satu-satunya batasan adalah menjaga biaya pembangunan blok dan pembuktian 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 tanpa perlu mempercayai, anti-sensor, dan melindungi privasi. Artikel ini akan membahas bagaimana menyesuaikan peta jalan perluasan L1 saat ini untuk mencapai tujuan ini.
1, Mengapa tidak puas dengan implementasi desentralisasi dan privasi ZK-EVM+PIR?
Peta jalan privasi yang saya rilis bulan lalu mengusulkan: dalam jangka pendek menggunakan solusi TEEs+ORAM, dan dalam jangka panjang beralih ke teknologi PIR. Dengan memadukan verifikasi Helios dan ZK-EVM, pengguna dapat sepenuhnya yakin saat terhubung ke RPC eksternal: (i) data rantai yang diperoleh adalah benar, (ii) privasi data dilindungi. 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 tanpa kepercayaan (seperti PIR server tunggal) sangat mahal. Biaya saat ini terlalu tinggi untuk dianggap realistis, bahkan setelah beberapa optimisasi efisiensi, harga tetap bisa tinggi.
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 pengguna atau pemeriksaan yang kuat. Banyak penyedia RPC telah mulai sepenuhnya memblokir negara tertentu.
Oleh karena itu, melanjutkan jaminan kenyamanan operasi node pribadi tetap memiliki nilai.
2. Prioritas Jangka Pendek
Prioritaskan penerapan penuh EIP-4444 untuk mencapai hanya sekitar 36 hari penyimpanan data per node. Ini akan secara drastis mengurangi kebutuhan ruang hard disk, yang saat ini menjadi kendala nomor satu yang mencegah orang menjalankan node. Setelah itu, persyaratan penyimpanan node hanya akan terdiri dari: data negara bagian (i), cabang Merkle negara bagian (ii), (iii)36 hari data historis.
Membangun solusi penyimpanan sejarah terdistribusi, sehingga setiap Node menyimpan sejumlah kecil data sejarah yang sudah kedaluwarsa. Memaksimalkan keandalan melalui teknologi pengkodean penghapusan. Dengan cara ini, tidak hanya dapat menjamin karakteristik "blokchain yang disimpan selamanya", tetapi juga tidak perlu bergantung pada penyedia terpusat atau membebani operator Node.
Menyesuaikan strategi penetapan harga Gas, meningkatkan biaya penyimpanan, dan mengurangi biaya eksekusi. Fokus pada peningkatan biaya Gas untuk operasi berikut: (i) mengeksekusi SSTORE untuk slot penyimpanan yang baru, (ii) membuat kode kontrak, (iii) mentransfer ETH ke akun saldo nol / nonce nol.
3, Tujuan Menengah: Verifikasi Tanpa Status
Setelah mencapai 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% lagi.
4, Node Baru: Beberapa Node Tanpa Status
Inovasi ini akan menjadi kunci untuk menjaga operasi node pribadi setelah peningkatan batas gas L1 sebesar 10-100 kali.
Kami menambahkan jenis node baru: memverifikasi blok dengan cara tanpa status, memverifikasi seluruh rantai melalui verifikasi tanpa status atau ZK-EVM, 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 harus kembali ke solusi kriptografi yang dihosting secara eksternal—apakah harus kembali tergantung pada pilihan pengguna).
Status yang dipelihara secara spesifik tergantung pada konfigurasi pengguna, misalnya:
Mengeluarkan semua status di luar kontrak sampah yang diketahui.
Status yang terkait dengan semua akun EOA, SCW, dan token serta 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 on-chain: 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 penyaringan status. Perhatikan pengguna tidak perlu menyimpan cabang Merkle, hanya perlu menyimpan nilai asli.
Jenis node ini dapat memberikan keuntungan akses langsung lokal ke status kunci sekaligus memastikan privasi akses yang lengkap.
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 optimasi roadmap skala yang berfokus pada Node lokal
Penulis: Vitalik, pendiri Ethereum
Kompilasi: Golden Finance xiaozhou
Kritik yang paling umum terhadap peningkatan batas Gas L1, selain kekhawatiran tentang keamanan jaringan, adalah bahwa ini akan membuat menjalankan Full Node menjadi lebih sulit. Terutama dalam konteks peta jalan yang berfokus pada "membebaskan Full Node", untuk menyelesaikan masalah ini, kita perlu terlebih dahulu memahami makna keberadaan Full Node.
Pandangan tradisional menganggap bahwa Full Node digunakan untuk memverifikasi data on-chain. Jika ini adalah satu-satunya masalah, maka ZK-EVM dapat membuka kunci perluasan L1: satu-satunya batasan adalah menjaga biaya pembangunan blok dan pembuktian 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 tanpa perlu mempercayai, anti-sensor, dan melindungi privasi. Artikel ini akan membahas bagaimana menyesuaikan peta jalan perluasan L1 saat ini untuk mencapai tujuan ini.
1, Mengapa tidak puas dengan implementasi desentralisasi dan privasi ZK-EVM+PIR?
Peta jalan privasi yang saya rilis bulan lalu mengusulkan: dalam jangka pendek menggunakan solusi TEEs+ORAM, dan dalam jangka panjang beralih ke teknologi PIR. Dengan memadukan verifikasi Helios dan ZK-EVM, pengguna dapat sepenuhnya yakin saat terhubung ke RPC eksternal: (i) data rantai yang diperoleh adalah benar, (ii) privasi data dilindungi. 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:
Oleh karena itu, melanjutkan jaminan kenyamanan operasi node pribadi tetap memiliki nilai.
2. Prioritas Jangka Pendek
Prioritaskan penerapan penuh EIP-4444 untuk mencapai hanya sekitar 36 hari penyimpanan data per node. Ini akan secara drastis mengurangi kebutuhan ruang hard disk, yang saat ini menjadi kendala nomor satu yang mencegah orang menjalankan node. Setelah itu, persyaratan penyimpanan node hanya akan terdiri dari: data negara bagian (i), cabang Merkle negara bagian (ii), (iii)36 hari data historis.
Membangun solusi penyimpanan sejarah terdistribusi, sehingga setiap Node menyimpan sejumlah kecil data sejarah yang sudah kedaluwarsa. Memaksimalkan keandalan melalui teknologi pengkodean penghapusan. Dengan cara ini, tidak hanya dapat menjamin karakteristik "blokchain yang disimpan selamanya", tetapi juga tidak perlu bergantung pada penyedia terpusat atau membebani operator Node.
Menyesuaikan strategi penetapan harga Gas, meningkatkan biaya penyimpanan, dan mengurangi biaya eksekusi. Fokus pada peningkatan biaya Gas untuk operasi berikut: (i) mengeksekusi SSTORE untuk slot penyimpanan yang baru, (ii) membuat kode kontrak, (iii) mentransfer ETH ke akun saldo nol / nonce nol.
3, Tujuan Menengah: Verifikasi Tanpa Status
Setelah mencapai 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% lagi.
4, Node Baru: Beberapa Node Tanpa Status
Inovasi ini akan menjadi kunci untuk menjaga operasi node pribadi setelah peningkatan batas gas L1 sebesar 10-100 kali.
Kami menambahkan jenis node baru: memverifikasi blok dengan cara tanpa status, memverifikasi seluruh rantai melalui verifikasi tanpa status atau ZK-EVM, 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 harus kembali ke solusi kriptografi yang dihosting secara eksternal—apakah harus kembali tergantung pada pilihan pengguna).
Status yang dipelihara secara spesifik tergantung pada konfigurasi pengguna, misalnya:
Konfigurasi dapat dikelola melalui kontrak on-chain: 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 penyaringan status. Perhatikan pengguna tidak perlu menyimpan cabang Merkle, hanya perlu menyimpan nilai asli.
Jenis node ini dapat memberikan keuntungan akses langsung lokal ke status kunci sekaligus memastikan privasi akses yang lengkap.