Lompat ke konten
Financial Context Wiki

Light Client

Panduan sadar fork tentang bootstrap light client konsensus, sync committee, checkpoint weak subjectivity, header optimistis dan final, proof state eksekusi, penyedia RPC, ketersediaan data, dan privasi.

Diperbarui

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

Jawaban langsung

Light client adalah perangkat lunak verifikasi yang mengikuti blockchain dengan lebih sedikit eksekusi, state, dan riwayat lokal daripada node penuh. Light node adalah perangkat atau proses yang menjalankan perangkat lunak tersebut. Pada Ethereum proof-of-stake, light client konsensus melakukan bootstrap dari checkpoint final terbaru yang tepercaya, lalu memverifikasi pembaruan sync committee secara sadar fork untuk memelihara header optimistis dan header final. Light client tidak menjalankan ulang setiap transaksi EVM.

Tampilan konsensus terverifikasi itu baru merupakan jangkar kepercayaan pertama. Untuk memverifikasi nilai akun atau storage kontrak, client harus menghubungkan beacon header yang diautentikasi dengan execution payload header, memilih stateRoot miliknya, lalu memverifikasi proof akun atau storage terhadap root tersebut. Respons RPC biasa tanpa proof yang diperlukan tetap merupakan pernyataan penyedia. Tanda tangan konsensus tidak otomatis membuktikan riwayat transaksi, receipt, trace, ketersediaan data, perilaku aplikasi, atau keterambilan jangka panjang.

Cara kerja

  1. Tetapkan jaringan dan root kepercayaan: identitas chain, genesis validators root dan waktunya, jadwal fork dan preset, jam saat ini, versi client, serta checkpoint weak subjectivity terbaru yang tepercaya dan final. Cocokkan checkpoint melalui sumber independen yang diautentikasi; kesepakatan peer tidak dapat memperbaiki root awal yang berbahaya.
  2. Ambil LightClientBootstrap untuk trusted block root. Verifikasi bootstrap header, sync committee saat ini, dan Merkle branch-nya, lalu inisialisasi LightClientStore. Tolak chain, fork digest, generalized index, atau skema serialisasi yang tidak cocok dengan fork yang dikonfigurasi.
  3. Proses objek LightClientUpdate menurut periode sync committee. Sebelum merotasi committee, verifikasi slot, bit partisipasi, tanda tangan agregat BLS beserta domainnya, branch committee saat ini dan berikutnya, finality branch, serta monotonicity. Upgrade fork dapat mengubah field objek dan generalized index, jadi konstanta Altair bukan nilai universal permanen.
  4. Pelihara kebijakan terpisah untuk optimistic_header dan finalized_header. Pembaruan optimistis dapat memberi informasi yang lebih baru dengan eksposur reorganisasi atau withholding lebih besar; pembaruan final memiliki status konsensus lebih kuat tetapi dapat tertinggal. Aplikasi harus memilih header yang tepat secara eksplisit, bukan melabeli respons terbaru sebagai final.
  5. Jangkarkan data eksekusi. Verifikasi execution payload header dan branch yang dibawa oleh light-client header terautentikasi, lalu ikat setiap kueri akun atau storage ke execution stateRoot, hash blok, dan status finalitasnya. Pada Ethereum, eth_getProof dapat mengembalikan proof akun dan proof storage yang diminta; verifikasi node, path, nilai, dan nonexistence secara lokal.
  6. Inventarisasi setiap permukaan yang belum diverifikasi. Proof saldo tidak mengautentikasi receipt transaksi, kueri log, trace, simulasi call, mempool, label token, oracle, blob, rentang historis, atau klaim penyedia bahwa tidak ada hasil yang dihilangkan. Tetapkan proof, rekonstruksi independen, fallback node penuh, atau asumsi kepercayaan eksplisit untuk setiap objek yang dibutuhkan.
  7. Operasikan secara fail-closed. Catat checkpoint, fork, root optimistis dan final, blok eksekusi dan state root, node proof, penyedia, serta timestamp. Terapkan batas staleness, diversifikasikan penyedia dan jalur jaringan, lindungi privasi kueri, uji pemulihan dari eclipse dan outage, serta gunakan node penuh atau sistem verifikasi lain jika cakupan proof light client tidak memadai.

Contoh terhitung

  • Batas integer sync committee. Untuk committee beranggotakan 512, pengujian supermajority pada spesifikasi adalah participants * 3 >= 512 * 2. Dengan 341 peserta, 341 / 512 = 66.6015625% dan 1,023 < 1,024, sehingga pengujian gagal. Dengan 342, 342 / 512 = 66.796875% dan 1,026 >= 1,024, sehingga lolos. Ini memverifikasi aturan pembaruan yang dikonfigurasi, bukan membuktikan bahwa setiap anggota committee atau implementasi jujur.
  • Waktu header. Checkpoint ilustratif berada pada slot 10,000, attested header pada 10,064, dan finalized header-nya pada 10,032. Dengan 12 seconds/slot, attested header muncul 64 * 12 = 768 seconds = 12 minutes 48 seconds setelah checkpoint, sedangkan finalitas tertinggal dari attested header sebesar 32 * 12 = 384 seconds = 6 minutes 24 seconds. Waktu slot tidak menjamin pengiriman jaringan atau finalitas dengan SLA waktu tetap.
  • Branch ringkas, klaim sempit. Dalam tree ideal seimbang dengan 2^20 leaf, branch untuk satu leaf memiliki 20 sibling hash. Dengan 32 bytes/hash, ukurannya 640 bytes; dibandingkan objek 8 MiB = 8,388,608 bytes, branch hanya 0.00762939453125% dari ukuran tersebut, atau pengurangan 99.99237060546875%. Branch hanya membuktikan hubungan leaf ke root, bukan ketersediaan byte lainnya.
  • Proof versus RPC tanpa proof. Pada execution stateRoot yang final, proof akun terverifikasi menghasilkan 3.25 ETH, sedangkan respons RPC tanpa proof menyatakan 3.30 ETH. Selisihnya 0.05 ETH, dan respons tanpa proof lebih tinggi 0.05 / 3.30 = 1.5151515152%. Terima nilai yang dibuktikan di bawah root terpilih, tetapi jangan menyimpulkan saldo yang lebih baru, receipt, hasil historis, atau identitas token dari proof tersebut.

Risiko

  • Mengonfigurasi chain, genesis validators root, genesis time, atau preset yang salah.
  • Melakukan bootstrap dari checkpoint berbahaya, stale, atau belum final.
  • Menggunakan satu sumber checkpoint tanpa autentikasi atau menerima long-range fork.
  • Penyimpangan jam lokal yang menghasilkan slot, periode, domain, atau keputusan staleness yang salah.
  • Menjalankan jadwal fork, skema objek, atau generalized index yang usang.
  • Gagal memvalidasi partisipasi sync committee, tanda tangan BLS, atau domain.
  • Melewatkan rotasi committee atau menerima committee saat ini maupun berikutnya yang tidak valid.
  • Memperlakukan header optimistis sebagai header final.
  • Menghubungkan beacon header, execution payload, atau hash blok eksekusi yang salah.
  • Memverifikasi proof akun atau storage terhadap stateRoot yang salah.
  • Menerima node trie, path, encoding, atau nonexistence proof yang malformed.
  • Memperlakukan metode RPC yang tidak didukung atau tanpa proof sebagai terverifikasi.
  • Menerima respons penyedia yang stale, disensor, tidak lengkap, atau direkayasa.
  • Serangan eclipse, Sybil, atau kegagalan kendali bersama pada penyedia yang tampak berbeda.
  • Kehilangan liveness ketika node penuh pemberi proof melakukan pruning atau berhenti melayani data.
  • Mengacaukan validitas konsensus dengan replay eksekusi atau kebenaran aplikasi.
  • Mengacaukan proof valid dengan ketersediaan data atau keterambilan permanen.
  • Tidak memiliki receipt, log, trace, body, atau riwayat yang diperlukan aplikasi.
  • Kegagalan implementasi client, dependensi, binary, atau upgrade fork.
  • Kebocoran privasi kueri, IP, akun, dan transaksi kepada penyedia atau peer.

Kesalahpahaman umum

  • Light client hanyalah node penuh yang lebih kecil atau nama lain untuk endpoint RPC jarak jauh.
  • Sync-committee header yang terverifikasi membuat setiap respons RPC dapat dipercaya.
  • Header optimistis terbaru setara dengan header final.
  • Merkle proof atau tanda tangan konsensus membuktikan ketersediaan data dan riwayat yang lengkap.
  • Menggunakan light client otomatis memberi privasi, liveness, dan ketahanan sensor setara node penuh.

Topik terkait

Sumber

Navigasi

Cari di wiki...