Lompat ke konten
Financial Context Wiki

Ketersediaan data

Panduan yang mengutamakan verifikasi untuk publikasi dan keterambilan data, commitment, validitas, finality, sampling, retensi, arsip, derivasi rollup, dan pemulihan yang dapat dieksekusi.

Diperbarui

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

Jawaban langsung

Ketersediaan data berarti data yang ditentukan protokol dalam jumlah memadai dipublikasikan dan dapat diperoleh dalam jendela yang diwajibkan agar peserta sasaran dapat memverifikasi, menderivasi, atau merekonstruksi state terkait. Objek yang diperlukan dapat berupa input transaksi, selisih state, share terenkode, atau format batch lain yang ditetapkan; ini bukan sekadar situs, endpoint RPC, atau API proyek yang sedang online.

Empat klaim harus dipisahkan. Ketersediaan menyangkut publikasi tepat waktu kepada konsumen protokol. Keterambilan menyangkut kemampuan pihak tertentu mengambil byte sekarang atau nanti. Validitas menyangkut apakah transisi state mengikuti aturan atau batasan proof. Finality menyangkut apakah konsensus masih dapat mengganti commitment melalui operasi protokol normal. Commitment yang mengikat, proof KZG, proof validitas, atau inclusion yang telah final tidak dengan sendirinya membuktikan keempat klaim, dan ketersediaan sementara bukan pengarsipan permanen.

Cara kerja

  1. Definisikan klaim sebelum mengukurnya: batch, blob, namespace, atau objek data terenkode yang tepat; protokol dan versi; konsumen sasaran; tugas derivasi, verifikasi, atau exit; serta jendela ketersediaan, challenge, dan pemulihan. Data lengkap berarti cukup menurut protokol tersebut, bukan salinan setiap transaksi yang tidak terdefinisi.
  2. Kunci jalur dan bukti publikasi: chain settlement, chain DA khusus, calldata, blob sidecar, commitment eksternal, atau sertifikat komite; ID blok, slot, dan batch; encoding dan kompresi; commitment; serta kontrak atau bridge yang mengonsumsinya. Publikasi di satu tempat tidak membuktikan verifier lain memeriksanya.
  3. Uji pengikatan dan rekonstruksi secara independen. Ambil byte tanpa API proyek, verifikasi hash, KZG, atau commitment lain beserta referensi inclusion, validasi framing dan erasure coding, dekode batch, dan reproduksi input untuk derivasi state. Commitment valid tanpa byte bukan rekonstruksi yang berhasil.
  4. Petakan model penerimaan. Catat apakah full node mengunduh objek, light node mengambil sampel share terautentikasi, validator memiliki tugas custody, atau komite ketersediaan data menandatangani sertifikat threshold. Nyatakan asumsi sampling, erasure, independensi peer, threshold, stake, key, dan eclipse, serta objek yang benar-benar diverifikasi kontrak settlement atau bridge.
  5. Lacak state dan waktu secara terpisah: submitted, included, available dalam jendela protokol, retrievable oleh klien independen, decoded atau derived, execution-valid, safe, finalized, dan archived. Proof validitas dapat membuktikan komputasi terbatas meski data untuk derivasi atau operasi independen tetap tidak tersedia.
  6. Ukur retensi, bootstrap, dan ekonomi. Catat minimum layanan protokol, perilaku pruning, penyedia arsip dan snapshot, kebutuhan node baru, byte mentah dan terenkode, overhead, harga satuan, biaya proof dan transaksi, batas kapasitas, subsidi, serta biaya fallback. Pengambilan jangka panjang menjadi dependensi tambahan setelah DA sementara berakhir.
  7. Latih skenario kegagalan. Uji withholding, selective serving, sampel berkorelasi atau terkena eclipse, hilangnya komite, DA halt atau fork, reorganisasi settlement, frame hilang, arsip hilang, sensor sequencer, dan lonjakan biaya. Verifikasi safe halt, forced inclusion, retry, fallback, rekonstruksi, dan exit dengan perangkat lunak, data, dan gas aktual; kemudian simpan commitment, receipt, dan bukti arsip independen.

Contoh perhitungan

  • Satuan biaya data yang benar. Batch berisi 400,000 bytes, mencakup 2,000 transactions, dan berharga $0.00002 per byte. Biaya data DA adalah 400,000 * $0.00002 = $8 per batch, atau $8 / 2,000 = $0.004 per transaction. Jika harga satuan naik sepuluh kali menjadi $0.00020 per byte, biaya menjadi $80 per batch dan $0.040 per transaction, bukan $0.04 per batch. Eksekusi, proof, overhead transaksi, pengarsipan, dan margin tidak termasuk.
  • Jendela layanan protokol bukan janji arsip. Jendela permintaan minimum EIP-4844 adalah 4,096 epochs; dengan 32 slots per epoch dan 12 seconds per slot, hasilnya 4,096 * 32 * 12 = 1,572,864 seconds, atau 1,572,864 / 86,400 = 18.2044444444 days. Ini minimum protokol dalam model ini, bukan jaminan satu penyedia menyimpan blob tertentu selamanya.
  • Probabilitas sampling sederhana. Hanya untuk model ilustratif, asumsikan penyerang menahan 50% share yang telah diperluas dan disampel seragam, sedangkan 30 sampel terautentikasi bersifat independen dan diambil dengan pengembalian. Probabilitas semua sampel meleset dari area yang ditahan adalah 0.5^30 = 0.0000000009313225746, sehingga probabilitas deteksi 99.9999999069%. Ini bukan jaminan layanan PeerDAS live atau jaringan lain; peer berkorelasi, sampling bias, parameter coding, dan serangan adaptif mengubah hasilnya.
  • Threshold komite tidak sama dengan keterambilan saat ini. Komite DA hipotetis memerlukan 5-of-7 tanda tangan. Jika tiga anggota tidak tersedia, hanya 4 tersisa, sehingga sertifikat threshold baru tidak dapat dibentuk. Sertifikat lama dengan 5 signatures membuktikan threshold memberi attestasi menurut aturannya; bukan bukti pengguna tertentu dapat mengambil byte sekarang, eksekusi valid, atau settlement final.

Risiko

  • Memeriksa chain, batch, blob, namespace, atau versi protokol yang salah.
  • Menyamakan commitment atau sertifikat dengan byte dasarnya.
  • Menganggap pengambilan dari satu endpoint sebagai ketersediaan seluruh protokol.
  • Menganggap ketersediaan data sebagai bukti validitas eksekusi.
  • Menganggap ketersediaan atau validitas sebagai finality konsensus.
  • Merujuk blok settlement yang usang, belum aman, atau direorganisasi.
  • Melewatkan jendela retensi protokol sebelum mengambil data.
  • Bergantung pada satu arsip, snapshot, indexer, atau API proyek.
  • Menerima framing, kompresi, atau erasure coding yang cacat.
  • Tidak memverifikasi hash, KZG, atau commitment lainnya.
  • Mengambil terlalu sedikit share untuk model ancaman yang dinyatakan.
  • Menganggap sampel, peer, atau kelompok custody independen saat berkorelasi.
  • Mengalami eclipse attack, pemilihan peer bias, atau selective serving.
  • Memakai parameter erasure atau threshold rekonstruksi yang tidak sesuai verifier.
  • Bergantung pada komite DA yang berkolusi atau tidak tersedia.
  • Membiarkan kontrak bridge atau settlement menerima objek lebih lemah dari perkiraan pengguna.
  • Kehilangan data karena withholding sequencer, sensor, atau frame batch yang hilang.
  • Menghadapi DA halt, fork, reorganisasi, atau upgrade klien yang tidak kompatibel.
  • Menemukan forced inclusion, fallback, pemulihan, atau exit tidak dapat dieksekusi.
  • Meremehkan kapasitas, lonjakan biaya, overhead, biaya arsip, atau berakhirnya subsidi.

Kesalahpahaman umum

  • Proof validitas menghapus kebutuhan akan ketersediaan data.
  • Commitment atau proof KZG membuktikan byte lengkap dapat diperoleh.
  • Inclusion yang telah final berarti data tetap dapat diambil selamanya.
  • Label on-chain, blob, DA khusus, atau sampling otomatis memberi keamanan yang sama.
  • Lebih banyak sampel atau biaya lebih rendah saja membuktikan desain DA lebih unggul.

Topik terkait

Sumber

Navigasi

Cari di wiki...