Vitalik: Sebuah rencana pengoptimalan skema peningkatan kapasitas yang berfokus pada Node lokal

Karya: Vitalik, pendiri Ethereum

Kompilasi: Golden Finance xiaozhou

Kritik paling umum terhadap peningkatan batas L1 Gas, selain kekhawatiran tentang keamanan jaringan, adalah bahwa ini akan membuat pengoperasian node penuh menjadi lebih sulit. Terutama dalam konteks peta jalan yang berfokus pada "melepaskan node penuh", untuk menyelesaikan masalah ini perlu memahami makna 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 perluasan L1: satu-satunya batasan adalah menjaga biaya pembangunan blok dan pembuktian tetap cukup rendah, sehingga keduanya dapat mempertahankan sifat anti-sensor 1 dari n dan membentuk pasar yang kompetitif.

Namun dalam kenyataannya, ini bukan satu-satunya pertimbangan. Faktor penting lainnya adalah: menjalankan node penuh memungkinkan Anda memiliki server RPC lokal, sehingga Anda dapat membaca data di blockchain dengan cara yang tanpa kepercayaan, tahan sensor, dan melindungi privasi. Artikel ini akan membahas bagaimana menyesuaikan peta jalan ekspansi L1 saat ini untuk mencapai tujuan ini.

  1. Mengapa tidak puas dengan desentralisasi dan privasi yang dicapai oleh ZK-EVM+PIR?

Peta jalan privasi yang saya rilis bulan lalu menganjurkan adopsi TEEs+ORAM dalam jangka pendek dan pergeseran ke teknologi PIR dalam jangka panjang. Dikombinasikan dengan validasi Helios dan ZK-EVM, pengguna dapat terhubung ke RPC eksternal dengan keyakinan penuh bahwa (i) mendapatkan data rantai yang benar dan privasi data (ii) dilindungi. Ini menimbulkan pertanyaan: mengapa tidak berhenti di situ? Apakah skema kriptografi canggih ini membuat node yang dihosting sendiri menjadi usang?

Saya memiliki beberapa tanggapan tentang hal ini:

Skema kriptografi yang sepenuhnya tanpa kepercayaan (seperti PIR server tunggal) sangat mahal. Biaya saat ini terlalu tinggi untuk menjadi realistis, bahkan setelah beberapa optimasi efisiensi, harga tetap mungkin tinggi.

Masalah privasi metadata. Waktu permintaan alamat IP, pola permintaan, dan metadata lainnya sudah dapat mengungkapkan banyak informasi pengguna.

Pemeriksaan kerentanan: Struktur pasar yang didominasi oleh sejumlah pemasok RPC akan menghadapi tekanan pemblokiran atau pemeriksaan pengguna yang kuat. Banyak penyedia RPC mulai sepenuhnya memblokir negara tertentu.

Oleh karena itu, melanjutkan jaminan kemudahan operasional node pribadi masih memiliki nilai.

  1. Prioritas Jangka Pendek

Prioritaskan penerapan EIP-4444 secara menyeluruh, untuk akhirnya mewujudkan bahwa setiap node hanya menyimpan data selama sekitar 36 hari. Ini akan secara signifikan mengurangi kebutuhan ruang hard disk—halangan utama yang menghambat orang untuk menjalankan node. Setelah itu, kebutuhan penyimpanan node hanya akan mencakup: (i) data status, (ii) cabang Merkle status, (iii) data historis selama 36 hari.

Membangun solusi penyimpanan sejarah terdistribusi, agar setiap node menyimpan sejumlah kecil data sejarah yang sudah kedaluwarsa. Memaksimalkan keandalan melalui teknologi kode penghapusan. Dengan cara ini, dapat menjamin karakteristik "penyimpanan permanen blockchain", tanpa bergantung pada penyedia terpusat atau membebani operator node.

Mengatur strategi penetapan Gas, meningkatkan biaya penyimpanan, dan mengurangi biaya eksekusi. Fokus pada peningkatan biaya Gas untuk operasi berikut: (i) mengeksekusi SSTORE untuk slot penyimpanan baru, (ii) membuat kode kontrak, (iii) mentransfer ETH ke akun dengan saldo nol / nonce nol.

3, Tujuan Menengah: Verifikasi Tanpa Status

Setelah mencapai verifikasi tanpa status, 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

Inovasi ini akan menjadi kunci untuk menjaga operasi node pribadi bahkan setelah peningkatan batas gas L1 sebesar 10-100 kali.

Kami menambahkan jenis node baru: memvalidasi blok dengan cara tanpa status, memvalidasi 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 perlu kembali ke solusi kriptografi yang dikelola secara eksternal—apakah harus kembali tergantung pada pilihan pengguna).

Status yang dipelihara secara spesifik tergantung pada konfigurasi pengguna, misalnya:

Kecualikan semua status di luar kontrak sampah yang diketahui.

Status yang terkait dengan 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 menjalankan node dengan menggunakan parameter "--save_state_by_config 0x12345...67890", alamat ini akan mendefinisikan daftar alamat yang perlu disimpan dan diperbarui secara real-time dalam bahasa tertentu, slot penyimpanan (storage slot) atau aturan penyaringan status. Perlu dicatat bahwa pengguna tidak perlu menyimpan cabang Merkle, hanya perlu menyimpan nilai asli.

Node-node ini tidak hanya dapat menyediakan keuntungan akses langsung lokal ke status kunci, tetapi juga dapat memastikan privasi akses yang sepenuhnya.

Lihat Asli
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.
  • Hadiah
  • Komentar
  • Bagikan
Komentar
0/400
Tidak ada komentar
  • Sematkan
Perdagangkan Kripto Di Mana Saja Kapan Saja
qrCode
Pindai untuk mengunduh aplikasi Gate
Komunitas
Bahasa Indonesia
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)