Lompat ke konten
Financial Context Wiki

Bukti validitas

Panduan berbasis verifikasi tentang bukti validitas, input publik, saksi, asumsi sistem pembuktian, transisi state rollup, ketersediaan data, finalitas, dan kegagalan operasional.

Diperbarui

Hanya untuk tujuan edukasi; bukan nasihat investasi atau keamanan. Keandalan bukti validitas bergantung pada pernyataan, pengikatan input publik, sistem pembuktian, verifikator, jalur ketersediaan data, kontrak, operator, tata kelola, dan rantai penyelesaian.

Jawaban langsung

Bukti validitas adalah bukti kriptografis bahwa komputasi yang diklaim memenuhi relasi yang didefinisikan secara tepat. Verifikator memeriksa bukti terhadap kunci verifikasi dan input publik. Pada rollup, input tersebut biasanya mengikat akar state sebelumnya, akar baru yang diusulkan, dan komitmen batch transaksi. Jika verifikasi berhasil, kontrak penyelesaian dapat menerima akar baru tanpa menjalankan ulang setiap transaksi.

Jaminannya lebih sempit daripada “sistem ini benar”. Jaminan bergantung pada kriptografi yang kuat, program atau sirkuit yang dimaksud, pengodean input yang benar, kunci autentik, serta kontrak verifikator dan pembaruan state yang benar. Verifikasi saja tidak membuktikan data dapat diambil, prover tetap aktif, blok sudah final, upgrade aman, atau penarikan berfungsi. Bukti dapat memakai zero-knowledge, tetapi validitas tidak otomatis berarti privasi.

1
Menjalankan

Pembukti menjalankan batch atau komputasi dan mencatat transisi keadaan yang dihasilkan.

Cara kerja

  1. Tetapkan deployment secara tepat: ID rantai L1 dan L2, versi rollup, kontrak pembaruan, alamat dan bytecode verifikator, hash kunci, sistem pembuktian, versi sirkuit atau program, mode data, kuasa admin, status jeda, dan kebijakan finalitas. validity proof bukan spesifikasi lintas sistem.
  2. Definisikan relasi yang dibuktikan sebelum menafsirkan hasil. Dengan asumsi soundness, Verify(vk, x, proof) = 1 harus menyiratkan adanya saksi w sehingga R(x, w) = 1. vk adalah kunci, x input publik lengkap, dan R aturan yang dikodekan. Bukti hanya mencakup relasi itu.
  3. Rekonstruksi input publik secara independen. Pastikan akar lama adalah akar yang diterima kontrak; turunkan komitmen batch atau data, ID, akar baru, akar pesan atau penarikan, dan parameter dari data kanonis. Bukti valid yang terikat ke objek salah membuktikan klaim yang salah.
  4. Verifikasi bukti dan jalur kontrak. Jalankan verifikator independen, lalu periksa panggilan onchain, receipt, event, nomor batch, dan perubahan storage. Pastikan kontrak memakai verifikator yang dimaksud tanpa bypass, simulasi, atau penggantian melalui upgrade maupun hak istimewa.
  5. Verifikasi ketersediaan data secara terpisah. Ambil transaksi, selisih state, blob sidecar, atau data yang disahkan komite; periksa komitmen dan reproduksi transisi atau saksi keluar. Bukti valid dapat berdampingan dengan data tidak tersedia, terutama pada validium.
  6. Pisahkan status: dibuat, dikirim, disertakan, bukti diverifikasi, state diterima, penyelesaian aman, final, dan penarikan selesai. Ukur antrean, biaya, liveness, penyertaan L1, reorganisasi, penundaan bridge, forced inclusion, dan prosedur keluar.
  7. Simpan bukti yang dapat direproduksi: alamat dan hash kode, hash kunci dan program, input lengkap, byte bukti atau referensi tetap, data batch, perintah dan versi software, receipt, blok final, serta uji keluar. Periksa kembali setelah upgrade.

Contoh perhitungan

  • Klaim batch. Rollup memproses 8,192 transfers. Bukti mengikat R0, R1, dan B7. Verifikasi mendukung adanya saksi dari R0 ke R1 untuk B7; bukan ketersediaan byte B7, penyertaan semua transaksi, atau finalitas R1.
  • Agregasi rekursif. Agregator memverifikasi 16 child proofs dalam sirkuit induk dan mengirim satu bukti induk. Setiap anak, urutan, dan pemetaan input tetap harus diperiksa; jumlah bukti tidak menciptakan pengikatan itu.
  • Buku gas hipotetis. Eksekusi ulang memakai 24,000,000 gas, verifikasi 600,000 gas, dan publikasi data 180,000 gas. Total 600,000 + 180,000 = 780,000 gas, penurunan model (24,000,000 - 780,000) / 24,000,000 = 96.75%. Hardware, agregasi, kegagalan, storage, bridge, dan retensi tidak termasuk.

Risiko

  • Memeriksa rantai, deployment, batch, verifikator, kunci, atau sirkuit yang salah.
  • Sistem yang sound membuktikan sirkuit tidak lengkap atau keliru dengan setia.
  • Input publik menghilangkan atau salah mengodekan ID, akar, batch, domain, atau parameter.
  • Bug verifikator, precompile, pustaka tidak aman, atau implementasi tidak kompatibel.
  • Materi setup bocor atau asumsi kriptografi dilanggar.
  • Kontrak upgradeable atau tata kelola mengganti verifikator, kunci, program, atau aturan.
  • Bypass istimewa, mode darurat, jeda, atau allowlist melemahkan jalur.
  • Bug pembuatan, nondeterminisme, atau saksi berbeda antar-klien.
  • Sentralisasi, sensor, gangguan, antrean, atau hardware prover menghentikan pembaruan.
  • Transaksi, selisih state, blob, preimage, atau arsip hilang.
  • Menganggap tanda tangan komite atau komitmen sebagai bukti data kini dapat diambil.
  • Menerima bukti dari blok tidak aman, direorganisasi, atau nonkanonis.
  • Menganggap penerimaan bukti sebagai penarikan langsung atau finalitas ekonomi.
  • Gagal mereproduksi transisi, saldo, pesan, atau saksi keluar.
  • Meremehkan gas, biaya data, latensi, penundaan bridge, atau pemulihan.
  • Menerapkan model satu rollup ke deployment lain.

Kesalahpahaman umum

  • Bukti yang lolos memverifikasi semua detail dan saldo tampilan.
  • Setiap bukti validitas bersifat zero-knowledge dan menyembunyikan transaksi.
  • Bukti menghapus risiko data, liveness sequencer, dan sensor.
  • Verifikasi membuat penyelesaian langsung final dan dapat ditarik.
  • Bukti lebih kecil atau verifikator lebih cepat otomatis lebih aman atau murah.

Topik terkait

Sumber

Navigasi

Cari di wiki...