Lompat ke konten
Financial Context Wiki

Node Penuh

Panduan berfokus verifikasi tentang node penuh, execution client dan consensus client Ethereum, checkpoint sinkronisasi, state kini dan historis, pruning, privasi RPC, finalitas, serta perencanaan sumber daya operasional.

Diperbarui

Hanya untuk tujuan edukasi; bukan merupakan nasihat investasi atau rekomendasi investasi. Investasi dapat mengakibatkan kerugian.

Jawaban langsung

Node penuh mengunduh data yang diwajibkan protokolnya, memverifikasi blok dan transisi state berdasarkan aturan konsensus dan eksekusi lokal, mengikuti chain yang dipilih aturan tersebut, serta dapat menolak data peer yang tidak valid tanpa menyerahkan keputusan itu kepada penyedia RPC. Istilah “penuh” menjelaskan tanggung jawab verifikasi, bukan penyimpanan permanen setiap state historis, produksi blok, staking, layanan API publik, atau kekebalan dari kesalahan perangkat lunak dan konfigurasi.

Pada Ethereum proof-of-stake, node penuh yang dapat digunakan memasangkan execution client dengan consensus client. Execution client memvalidasi transaksi dan execution payload, memelihara state eksekusi kini, serta menyediakan JSON-RPC; consensus client memvalidasi objek konsensus, menerapkan fork choice, dan melacak justification serta finalization. Validator client bersifat opsional dan hanya diperlukan untuk mengusulkan blok dan membuat attestation dengan validator yang melakukan staking.

Cara kerjanya

  1. Tetapkan tujuan verifikasi dan snapshot jaringan: protokol, identitas chain dan genesis, jadwal fork, chainId yang diharapkan, hash blok terkini dan final, versi client, mode sinkronisasi, sumber checkpoint, mode pruning, metode RPC, cakupan state historis, dan uptime yang dibutuhkan. Istilah node penuh memiliki persyaratan khusus tiap chain.
  2. Pasang rilis client yang diperoleh dan diverifikasi secara independen, lalu pasangkan komponen yang diwajibkan. Pada Ethereum kini, hubungkan satu execution client dengan satu consensus client melalui Engine API lokal yang diautentikasi; tambahkan validator hanya bila melakukan staking. Pisahkan direktori data, port P2P, eksposur RPC, serta kunci signer atau validator.
  3. Mulai dari trust anchor yang dimaksud. Full sync dari genesis memvalidasi maju sejak genesis; strategi snap atau checkpoint dimulai dari state baru yang diautentikasi atau weak-subjectivity checkpoint, lalu memvalidasi blok berikutnya. Bandingkan genesis, checkpoint root, chain ID, fork digest, dan finalized head melalui kanal independen sebelum memercayai database.
  4. Pantau kedua pipeline. Konfirmasikan peer eksekusi dan konsensus, keterlambatan head dan finalized block, kesehatan Engine API, kesesuaian state root, sinkronisasi clock, pertumbuhan disk, input/output, memori, CPU, kesalahan database, dan kesiapan fork. Status “tersinkronisasi” harus berarti client yang diwajibkan menyepakati chain tujuan dan terus mengimpor data valid.
  5. Sesuaikan retensi dengan kebutuhan query. Node penuh yang di-prune menyimpan state kini dan data blok, receipt, serta snapshot yang memadai untuk verifikasi, tetapi mungkin meregenerasi atau menolak query state lama. Konfigurasi archive mematerialisasi state historis agar query titik waktu cepat. Light client memverifikasi jalur commitment yang lebih sempit dan meminta data tambahan; bukan sekadar node penuh kecil.
  6. Ekspos permukaan RPC minimum yang diperlukan. Bind API administratif dan Engine secara lokal, autentikasi client, pasang firewall host, batasi laju RPC aplikasi, dan jangan publikasikan metode debug, trace, account, atau transaction pool tanpa kontrol. Uji tag latest, safe, dan finalized, historical call, log, serta pengiriman transaksi pada node tujuan; failover hanya ke endpoint yang telah diperiksa secara independen.
  7. Rekonsiliasi dan pulihkan. Bandingkan hash blok, state root, serta finalized checkpoint dengan client kedua atau node independen; latih clean shutdown, snapshot dan restore, pembangunan ulang database, upgrade client, aktivasi fork, penggantian disk, kehilangan peer, dan failover RPC. Simpan log dan konfigurasi sambil memisahkan output yang diverifikasi node dari klaim frontend, oracle, bridge, dan aplikasi.

Contoh terhitung

  • Model bandwidth. Asumsikan chain menghasilkan satu blok setiap 12 seconds dan rata-rata block body yang diunduh beserta side data yang diperlukan adalah 150 kB. Node memproses 86,400 / 12 = 7,200 blocks/day dan mengunduh 7,200 * 150 kB = 1,080,000 kB = 1.08 GB/day dalam unit desimal, sebelum overhead P2P, percobaan ulang, traffic konsensus, snapshot, atau upload. Ini asumsi perencanaan, bukan konstanta Ethereum langsung.
  • Ruang cadangan disk. Node yang di-prune dimulai pada 1.20 TB dan database terukurnya tumbuh 18 GB/month. Selama 30 months, penggunaan model adalah 1,200 + 18 * 30 = 1,740 GB. Cadangan 25% di atas proyeksi memerlukan 1,740 * 1.25 = 2,175 GB, atau 2.175 TB dalam unit desimal. Perubahan client, pruning, dan fork dapat membatalkan model linear.
  • Ketersediaan operasional. Selama 30 days = 720 hours, pemeliharaan execution client memakan 2 hours, kegagalan consensus client 3 hours, dan pemadaman listrik bersama 1 hour, tanpa tumpang tindih. Downtime adalah 6 hours; ketersediaan teramati adalah (720 - 6) / 720 = 99.1666666667%. Proses node dapat berjalan tetapi tertinggal, terpartisi, atau berada di chain salah, sehingga uptime proses saja tidak memadai.
  • Regenerasi state historis. Client yang di-prune mempunyai snapshot terpakai pada blok 18,000,000 dan membutuhkan state pada blok 18,250,000. Client harus memutar ulang 250,000 blocks. Pada laju terukur 500 blocks/second, waktu komputasi ideal adalah 250,000 / 500 = 500 seconds = 8.3333333333 minutes, tanpa state read, receipt, penanganan reorg, dan cache miss. Archive node menukar penyimpanan tambahan dengan akses langsung state historis yang lebih cepat.

Risiko

  • Terhubung ke chain, genesis, jadwal fork, atau chainId yang salah.
  • Memercayai checkpoint sinkronisasi berbahaya, usang, atau kurang diverifikasi silang.
  • Menjalankan client usang ketika jaringan mengalami upgrade.
  • Consensus client dan execution client tidak sepakat atau kehilangan koneksi Engine API.
  • Bug implementasi client menerima, menolak, atau menyajikan data salah.
  • Monokultur client mengekspos node dan jaringan pada kegagalan berkorelasi.
  • Peer terlalu sedikit, terkena eclipse, berbahaya, atau kurang beragam.
  • Clock drift merusak tugas konsensus, timestamp, atau perilaku peer.
  • Disk penuh, storage lambat, filesystem gagal, atau database rusak.
  • Menganggap uptime proses sebagai operasi yang tersinkronisasi, canonical, dan final.
  • Mencampuradukkan state head, safe, dan finalized selama reorganisasi.
  • Menganggap node penuh yang di-prune dapat langsung menjawab setiap query state historis.
  • Menganggap archive node menyimpan setiap indeks off-chain, trace, atau label aplikasi.
  • Mengekspos API Engine, admin, debug, trace, atau transaction pool tanpa autentikasi.
  • Membocorkan alamat wallet, query, metadata, atau niat transaksi melalui log RPC.
  • Beban RPC berlebih, query tak terbatas, atau denial of service mengurangi sumber daya validasi blok.
  • Restore backup atau snapshot menghasilkan data usang atau tidak konsisten secara internal.
  • Kehilangan kunci validator atau signer karena menempatkannya sembarangan bersama layanan node.
  • Menganggap data chain yang diverifikasi lokal membuktikan frontend, oracle, atau bridge jujur.
  • Menerapkan model dua-client, pruning, atau weak subjectivity Ethereum pada chain lain.

Kesalahpahaman umum

  • Setiap node penuh adalah archive node yang menyimpan semua state historis selamanya.
  • Menjalankan node penuh otomatis menjadikan operator validator atau produsen blok.
  • Node yang melaporkan “tersinkronisasi” pasti berada pada chain canonical dan finalized yang dimaksud.
  • Self-hosted RPC menghapus semua risiko trust, privasi, perangkat lunak, dan operasional.
  • Disk, peer, atau uptime yang lebih besar saja membuktikan verifikasi benar dan keamanan jaringan.

Topik terkait

Sumber

Navigasi

Cari di wiki...