Lompat ke konten
Financial Context Wiki

Jaringan peer-to-peer

Jaringan peer-to-peer memberi setiap node sekumpulan peer langsung yang terbatas dan terus berubah untuk penemuan, penyebaran gossip, serta pertukaran permintaan dan respons; jaringan ini tidak menciptakan satu pandangan global atau mengubah penerimaan pesan menjadi konsensus.

Diperbarui

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

Jawaban langsung

Jaringan peer-to-peer memungkinkan setiap node menemukan dan memelihara sekumpulan peer langsung yang terbatas, bertukar pesan protokol terautentikasi, serta membangun pandangan lokalnya sendiri tanpa mengarahkan semua hal melalui satu server pusat. Ini bukan graf lengkap, mempool global, atau sumber kebenaran dengan sendirinya. Peer yang menerima, memvalidasi, atau meneruskan suatu objek tidak membuktikan bahwa setiap node melihatnya, sebuah blok memasukkannya, atau konsensus memfinalisasinya.

Ethereum pasca-Merge menggunakan dua jaringan P2P yang berbeda. Klien lapisan eksekusi menggunakan penemuan ditambah RLPx dan kapabilitas eth berversi untuk sinkronisasi serta pertukaran transaksi. Klien lapisan konsensus menggunakan discv5 untuk penemuan dan gossip libp2p beserta protokol permintaan-respons untuk blok beacon, atestasi, dan objek konsensus lainnya. Kedua klien berkoordinasi secara lokal melalui Engine API terautentikasi; dompet biasanya mengirim melalui JSON-RPC dan tidak serta-merta menjadi node penyebar gossip.

Cara kerjanya

  1. Tetapkan chain, jaringan, genesis, konfigurasi fork, versi klien eksekusi dan konsensus, identitas node, serta waktu pengamatan. Gambarkan klien eksekusi, klien konsensus, validator opsional, Engine API lokal, dan RPC untuk pengguna sebagai komponen terpisah.
  2. Periksa setiap jalur penemuan: bootnode bawaan, daftar DNS, peer statis atau tepercaya, identitas ENR atau enode, endpoint dan urutan yang diumumkan, kompatibilitas jaringan, NAT, serta keterjangkauan inbound. ENR bertanda tangan mengikat catatan pada kunci; hal itu tidak membuktikan kejujuran, sinkronisasi, atau keterjangkauan saat ini.
  3. Catat koneksi dan negosiasi protokol secara terpisah. Peer eksekusi membuat sesi RLPx dan menegosiasikan kapabilitas seperti eth; peer konsensus menegosiasikan transport libp2p, keamanan, dan ID protokol setelah penemuan discv5. Menemukan endpoint tidak berarti aplikasi kompatibel.
  4. Lacak setiap objek melalui jalur sebenarnya. Transaksi dapat bergerak dari pengiriman RPC ke validasi lokal dan mempool eksekusi, kemudian melalui pengumuman dan permintaan eth. Objek konsensus menggunakan validasi gossip khusus topik, sedangkan blok yang hilang dapat diambil melalui permintaan-respons.
  5. Terapkan decoding berbatas, deduplikasi, batas laju, serta pemeriksaan tanda tangan, sintaks, dan status sebelum penerimaan atau penerusan lokal. Catat hasil tidak valid, diabaikan, tidak tersedia, dan terbatas sumber daya; skor peer dan kebijakan pemutusan adalah keputusan implementasi lokal, bukan reputasi konsensus.
  6. Pisahkan penerimaan, validasi, penerusan, penyertaan transaksi, hasil eksekusi, pemilihan fork, justifikasi, dan finalitas sebagai status dan waktu yang berbeda. Bandingkan beberapa peer atau node ketika respons pool lokal, head, atau riwayat tidak lengkap, bertentangan, atau kedaluwarsa.
  7. Pantau keragaman peer inbound dan outbound, operator, prefiks IP, konsentrasi ASN, pergantian peer, latensi, kehilangan paket, bandwidth, antrean, lalu lintas tidak valid, kesehatan waktu, dan ketergantungan RPC. Latih kehilangan bootnode, kegagalan NAT, partisi, serangan eclipse, kelebihan beban, dan pemulihan tanpa mengklaim ketahanan absolut.

Penemuan peer, keamanan transport, dan validitas aplikasi menyelesaikan persoalan yang berbeda. Bootnode memperkenalkan kandidat, tetapi tidak meneruskan lalu lintas biasa atau memilih chain kanonis. Enkripsi melindungi isi dan autentikasi sesi, tetapi peer tetap mengetahui endpoint jaringan dan waktu; penyedia RPC jarak jauh juga dapat mengamati kueri, alamat, dan transaksi yang dikirim.

Propagasi berlangsung serentak dan bergantung pada topologi. Fanout, jalur duplikat, serialisasi bandwidth, CPU validasi, antrean, kehilangan paket, transmisi ulang, skor peer, dan aturan khusus objek menentukan distribusi serta ekor waktu kedatangan. Rumus seperti delay = hops * perHopTime hanyalah model pengajaran serial yang dinyatakan, bukan jaminan jaringan.

Contoh

  • Jalur serial dan pipeline. Pada satu jalur ilustratif dengan 4 hops, setiap hop memiliki waktu jaringan 80 ms dan waktu validasi 20 ms. Pemrosesan sepenuhnya serial menghasilkan 4 * (80 + 20) = 400 ms. Jika validasi bertumpang tindih dengan transmisi berikutnya, batas bawah sederhana adalah 4 * 80 + 20 = 340 ms. Keduanya bukan waktu propagasi seluruh jaringan.
  • Pengumuman dan pengambilan transaksi. Node menerima 20 hash transaksi dan sudah memiliki 6, sehingga 20 - 6 = 14 body belum tersedia. Jika satu permintaan ilustratif membawa paling banyak 8, diperlukan ceil(14 / 8) = 2 batches. Dengan waktu pulang-pergi 120 ms ditambah validasi 30 ms per batch, penyelesaian serial adalah 2 * (120 + 30) = 300 ms; penyelesaian paralel ideal 150 ms. Batas sebenarnya bergantung pada versi eth yang dinegosiasikan dan klien.
  • Probabilitas eclipse yang disederhanakan. Jika masing-masing dari 8 peer outbound dipilih secara independen dan kandidat jahat berjumlah 25%, probabilitas semuanya jahat adalah 0.25^8 = 0.0000152587890625 = 0.00152587890625%. Bias penemuan, identitas Sybil, korelasi IP dan ASN, serta retensi peer melanggar asumsi independensi, sehingga angka ini bukan jaminan keamanan.
  • Kelebihan beban validasi. Gossip inbound adalah 900 messages/s; 4 worker masing-masing memvalidasi 250 messages/s, sehingga kapasitas 1,000 messages/s, kapasitas sisa 100 messages/s, dan utilisasi 90%. Serangan pada 1,400 messages/s membuat backlog 400 messages/s dan 6,000 messages dalam 15 seconds. Antrean 5,000-message penuh dalam 5,000 / 400 = 12.5 seconds sebelum pesan dibuang atau laju dibatasi, dengan mengabaikan variasi waktu layanan.

Risiko

  • Konfigurasi chain, genesis, atau fork yang salah
  • Ketidakcocokan klien eksekusi, klien konsensus, atau Engine API
  • Penemuan bootnode dan DNS terkonsentrasi atau dibajak
  • Metadata endpoint kedaluwarsa, dipalsukan, atau tidak terjangkau
  • NAT, firewall, atau konfigurasi port menghalangi keterjangkauan yang diharapkan
  • Serangan eclipse yang menyaring pandangan lokal node
  • Identitas Sybil dan konsentrasi IP, ASN, operator, atau cloud
  • Ketergantungan berlebihan pada peer statis atau tepercaya
  • Penyensoran transaksi atau relay selektif
  • Perbedaan aliran order publik dan privat
  • Perbedaan penerimaan, penggantian, dan penggusuran mempool lokal
  • Gossip tidak valid menghabiskan CPU validasi
  • Permintaan besar, dekompresi, bandwidth, memori, atau disk menghabiskan sumber daya
  • Manipulasi skor peer atau penalti palsu
  • Tekanan balik antrean membuang pesan yang peka waktu
  • Latensi, kehilangan, atau pergeseran waktu menyebabkan perbedaan head sementara
  • Ketidakcocokan versi protokol atau fork digest
  • Riwayat terpangkas atau respons sumber daya tidak tersedia disalahartikan sebagai ketiadaan
  • Kebocoran privasi IP, waktu, kueri, dan asal transaksi
  • RPC terpusat atau terekspos menyebabkan pelacakan, pandangan kedaluwarsa, penyensoran, atau kompromi

Kesalahpahaman umum

  • Setiap node terhubung langsung ke semua node lainnya. Setiap node mempunyai peer lokal yang terbatas dan berubah, sehingga node berbeda dapat melihat pesan dan head berbeda untuk sementara.
  • Bootnode adalah sumber blok tepercaya atau peserta konsensus. Peran normalnya adalah memperkenalkan peer pada awal proses; validitas chain dan pemilihan fork diverifikasi di tempat lain.
  • Transaksi yang diterima satu peer disiarkan secara global dan pasti disertakan. Penerimaan dan relay bersifat lokal, sedangkan builder atau proposer dapat mengabaikannya.
  • Validasi gossip berarti konsensus dan finalitas. Ini hanyalah gerbang jaringan lokal awal; pemilihan fork, justifikasi, dan finalitas adalah mesin status terpisah.
  • Lebih banyak peer atau transport terenkripsi otomatis memberi anonimitas dan ketahanan terhadap eclipse. Keragaman dan pemilihan tetap penting, sedangkan peer dan penyedia RPC masih dapat mengorelasikan endpoint, waktu, dan aktivitas.

Topik terkait

Sumber

Navigasi

Cari di wiki...