Lompat ke konten
Financial Context Wiki

ZK rollup

Panduan verifikasi batch, validity proof, ketersediaan data, status settlement, biaya, penarikan, dan risiko spesifik deployment ZK rollup.

Diperbarui

Hanya untuk edukasi; bukan saran investasi, bridge, atau keamanan. Keandalan ZK rollup bergantung pada program yang dibuktikan, input publik, jalur ketersediaan data, kontrak, operator, tata kelola, dan chain settlement.

Jawaban langsung

ZK rollup, lebih tepatnya validity rollup, mengeksekusi transaksi di luar chain settlement, mengelompokkannya, lalu mengirim komitmen data, klaim state, dan validity proof ke kontrak di chain tersebut. Verifier memeriksa aturan transisi tanpa mengeksekusi ulang semua transaksi, sehingga biaya publikasi dan verifikasi dibagi ke banyak transaksi.

Jaminannya spesifik, bukan mutlak. Proof terverifikasi hanya mendukung pernyataan dalam program yang di-deploy dan terikat input publik. Ia tidak membuktikan data dapat diambil, sequencer aktif atau adil, blok final, bridge benar, atau upgrade aman. “ZK” juga tidak otomatis privat; banyak rollup memublikasikan transaksi atau state diff.

1
Menjalankan

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

Cara kerja

  1. Pastikan deployment: chain ID L1/L2, kontrak rollup dan bridge, verifier dan versi key, program atau circuit, format batch, mode DA, sequencer, prover, admin, hak pause, dan blok observasi. Nama stack bukan bukti jaminan setiap deployment.
  2. Pisahkan pengurutan dan proof. Sequencer dapat memberi receipt dan blok L2 sebelum komitmen atau proof tiba di L1. Catat batch tepatnya dan bedakan sequenced, committed, proved, accepted, settlement-safe, settlement-finalized, dan withdrawal-complete.
  3. Rekonstruksi batch. Ambil transaksi, state diff, blob sidecar, atau payload wajib; periksa urutan dan komitmen; turunkan state root awal/akhir, root penarikan/pesan, serta input publik. Proof untuk chain, batch, atau root yang salah membuktikan klaim yang salah.
  4. Verifikasi jalur proof. Pastikan transaksi settlement memanggil verifier yang benar dengan proof, key, dan input yang tepat, berhasil, memancarkan event, dan mengubah slot yang benar. Reproduksi dengan perangkat lunak independen bila memungkinkan.
  5. Audit ketersediaan data terpisah. Blob Ethereum memberi ketersediaan selama jendela protokol dan komitmen, bukan arsip permanen. Komite eksternal atau DA alternatif menambah asumsi. Proof valid tidak memulihkan data hilang untuk rekonstruksi atau exit.
  6. Lacak deposit dan penarikan ujung ke ujung. Cocokkan token dan messenger kanonis, jumlah, tujuan, nonce, inclusion root, proof, aturan finalitas, dan perubahan saldo. Bridge cepat hanya memajukan likuiditas dengan harga, rute, dan risiko lawan transaksi sendiri.
  7. Pantau liveness dan kontrol. Ukur backlog batch/proof, forced inclusion dan escape, keragaman prover, upgrade, timelock, guardian, dan mode darurat. Ulangi setelah perubahan kontrak, circuit, key, DA, atau protokol.

Contoh hitungan

  • Kompresi. Batch contoh berisi 10,000 transactions; input 1,200 KB menjadi 300 KB. Rasio 1,200 / 300 = 4.0x, pengurangan 1 - 300 / 1,200 = 75%, rata-rata 300,000 / 10,000 = 30 bytes/transaction. Ini bukan ukuran soundness, pertumbuhan state, atau arsip.
  • Alokasi biaya. Pengguna membayar 3.0 ETH; data L1 1.4 ETH, verifikasi 0.4 ETH, eksekusi L2 0.2 ETH. Sisa 3.0 - 1.4 - 0.4 - 0.2 = 1.0 ETH dan rata-rata 3.0 / 10,000 = 0.0003 ETH/transaction. Bukan laba bersih karena prover, hardware, kegagalan, bridge, modal, dan pajak belum dihitung.
  • Siklus. Receipt pada minute 0, komitmen L1 minute 12, proof diterima minute 50, kebijakan finalitas terpenuhi minute 64, penarikan kanonis minute 70. Total 12 + 38 + 14 + 6 = 70 minutes. Tahap sebelumnya bukan penarikan selesai.

Risiko

  • Chain, deployment, kontrak, batch, root, verifier, key, atau circuit salah.
  • Program tidak lengkap atau salah yang dibuktikan dengan benar.
  • Input publik, domain, pesan, atau parameter hilang atau salah encoding.
  • Kerentanan verifier, precompile, bridge, messenger, atau kontrak state.
  • Materi setup bocor atau asumsi kriptografi runtuh.
  • Sensor, pengurutan ulang, equivocation, downtime, atau publikasi terlambat.
  • Prover mati, terpusat, menyensor, kekurangan kapasitas, atau backlog.
  • Transaksi, state diff, atau blob sidecar hilang, rusak, atau tidak diarsipkan.
  • Menganggap komitmen atau tanda tangan komite sebagai bukti data tersedia kini.
  • Reorg L1 atau terlalu dini memercayai settlement yang belum aman.
  • Upgrade istimewa, timelock singkat, penggantian, pause, atau bypass darurat.
  • Forced inclusion, recovery, atau escape tidak ada, mati, atau tak dapat dipakai.
  • Bug bridge kanonis, mapping token, replay, pesan, atau withdrawal proof.
  • Risiko likuiditas, harga, rute, insolvensi, dan lawan transaksi bridge cepat.
  • Estimasi tanpa biaya data L1, proof, bridge, kemacetan, atau transaksi gagal.
  • Menerapkan kompatibilitas EVM, finalitas, privasi, atau keamanan rollup lain.

Kesalahpahaman umum

  • Semua ZK rollup menyembunyikan jumlah, alamat, dan aktivitas aplikasi.
  • Proof valid menjamin ketersediaan data dan rekonstruksi state.
  • Receipt sequencer sama dengan proof L1 atau penarikan final.
  • Validity proof menghapus risiko sequencer, prover, governance, upgrade, dan bridge.
  • Sistem proof termurah atau tercepat otomatis paling aman.

Topik terkait

Sumber

Navigasi

Cari di wiki...