Lompat ke konten
Financial Context Wiki

Optimistic rollup

Panduan khusus deployment tentang receipt sequencer, data derivasi L1, head unsafe/safe/finalized, permainan fault proof, penarikan kanonis, tata kelola, dan fast exit.

Diperbarui

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

Jawaban langsung

Optimistic rollup mengeksekusi arus transaksi terurut dan menerbitkan data derivasi serta klaim state yang ditentukan protokol tanpa melampirkan bukti validitas pada setiap batch. “Optimistic” berarti klaim yang memenuhi syarat dapat berlanjut menurut aturan deployment kecuali sengketa fault proof yang berhasil menetapkan bahwa klaim itu salah. Istilah ini tidak berarti pesan sequencer membuktikan kebenaran, dan tidak berarti semua implementasi memiliki tantangan permissionless atau penundaan penarikan yang sama.

Node rollup secara independen menurunkan blok L2 dari input L1 kanonis dan konfigurasi protokol yang tepat. Karena itu, jalur keamanan mencakup ketersediaan data, derivasi dan eksekusi yang benar, sistem fault proof yang aktif dan andal, akses serta finalitas L1, tata kelola, dan kontrak bridge. State root saja tidak cukup untuk merekonstruksi chain atau menantang transisi yang tidak valid.

1
Urutan

Sequencer memesan transaksi L2 dan menerbitkan data transaksi atau komitmen.

Cara kerjanya

  1. Tetapkan deployment: chain ID L1 dan L2, konfigurasi dan fork rollup, kontrak inbox dan bridge, format batch dan mode DA, kontrak klaim state dan permainan sengketa, versi portal, administrator, guardian, serta blok observasi. Dokumentasi stack bukan bukti bahwa setiap fitur aktif pada chain tertentu.
  2. Klasifikasikan state yang diamati. Receipt sequencer atau blok unsafe adalah komitmen pengurutan lokal yang cepat; batch yang diterbitkan di L1 dapat mendukung head yang diturunkan secara safe; finalitas L1 dapat mendukung head turunan finalized. Klaim state atau output, sengketa yang terselesaikan, dan penarikan yang dapat dieksekusi merupakan objek dan jam yang terpisah.
  3. Rekonstruksi pipeline derivasi L1-ke-L2. Verifikasi deposit dan input terurut, channel dan batch, origin L1, perubahan konfigurasi, serta transisi state dari data L1 kanonis. Untuk data berbasis blob, bedakan ketersediaan dalam jendela protokol dari pengambilan arsip di kemudian hari.
  4. Petakan liveness dan kendali. Pisahkan sequencer, batcher, proposer, challenger, relayer, guardian, dan otoritas upgrade; verifikasi keberadaan jalur forced inclusion atau delayed inbox, penundaan dan kondisi pause-nya, serta apakah pengguna biasa memiliki perangkat lunak yang berfungsi untuk memakainya.
  5. Verifikasi jalur fault proof yang benar-benar diterapkan. Catat game type yang dihormati, izin proposer dan challenger, bond, absolute prestate, program bukti dan VM, preimage oracle, kedalaman klaim, jam dan perpanjangan, aturan resolusi, kewenangan blacklist atau pause, serta penundaan upgrade. Jangan memindahkan mekanisme OP Stack ke Arbitrum atau rollup lain.
  6. Telusuri penarikan dan ekonominya secara terpisah. Ikuti inisiasi L2, bukti L1, ketergantungan klaim atau permainan, penundaan maturity dan finality, pembuktian ulang, pemeriksaan portal, dan eksekusi L1. Perlakukan fast exit sebagai transaksi likuiditas atau kredit berharga dengan pihak lawan terpisah, bukan sebagai jam tantangan kanonis yang lebih singkat.
  7. Rekonsiliasi terus-menerus. Cocokkan hash blok unsafe, safe, dan finalized, transaksi batch L1, klaim state, hasil permainan, pesan bridge, receipt, kontrak token, serta saldo akhir. Buka kembali analisis setelah reorganisasi L1 atau L2, batch hilang, sengketa, pause, upgrade kontrak, atau migrasi DA.

Contoh terhitung

  • Payload derivasi. Sebuah batch memuat 10,000 transaksi, 1,200 KB input protokol mentah, dan 300 KB setelah kompresi. Rasionya adalah 1,200 / 300 = 4.0x, pengurangannya 1 - 300 / 1,200 = 75%, dan rata-rata desimalnya 300,000 / 10,000 = 30 bytes/tx. Angka ini hanya menggambarkan payload input terenkode, bukan gas L1, kebenaran eksekusi, ukuran state, atau jaminan arsip.
  • Kontribusi sebelum biaya yang diabaikan. Pengguna membayar 2.4 ETH; eksekusi L2 terukur 0.3 ETH; DA L1 1.2 ETH. Residunya 2.4 - 0.3 - 1.2 = 0.9 ETH, atau 0.9 / 10,000 = 0.00009 ETH/tx. Ini bukan laba bersih karena infrastruktur operator, eksekusi L1, permainan bukti, refund, modal, kegagalan, dan pajak belum dihitung.
  • Lokalisasi sengketa. Trace eksekusi pembelajaran memiliki 2^20 = 1,048,576 langkah. Penyempitan biner ideal memerlukan log2(2^20) = 20 pilihan untuk mengisolasi satu langkah. Jika setiap putaran pembelajaran memiliki maksimum terpisah 3-hour, batas serial naifnya 20 * 3 = 60 hours; protokol sebenarnya memakai chess clock, konkurensi, perpanjangan, dan jadwal transaksi masing-masing.
  • Jam penarikan dan likuiditas cepat. Batch pembelajaran mencapai L1 setelah 10 minutes, klaim yang diakui setelah 30 minutes lagi, lalu periode tantangan hipotetis berlangsung 7 days, dan relay akhir membutuhkan 2 hours. Waktu berurutan adalah 10 + 30 + 10,080 + 120 = 10,240 minutes = 7 days 2 hours 40 minutes. Bridge likuiditas yang membayar di muka 4.97 ETH atas klaim 5 ETH mengenakan 0.03 ETH, atau 0.03 / 5 = 0.6%, sedangkan klaim kanonis tetap tunduk pada jam dan risikonya semula.

Risiko

  • L1, L2, chain ID, konfigurasi rollup, atau deployment kontrak yang salah.
  • Menganggap receipt sequencer unsafe sebagai safe atau final.
  • Sequencer memberi informasi berbeda, menyensor, mengubah urutan, atau berhenti.
  • Penerbitan batch L1 terlambat, hilang, salah format, atau tidak valid.
  • Data blob atau DA alternatif menjadi tidak tersedia atau tidak diarsipkan.
  • Ketidakcocokan client derivasi, konfigurasi, atau fork.
  • Reorganisasi L1 membatalkan input derivasi yang sebelumnya safe.
  • Batcher, proposer state, atau peserta pembuktian berhenti.
  • Jalur forced inclusion atau delayed inbox tidak ada, dipause, atau disalahpahami.
  • Fault proof belum diterapkan, tidak aktif, atau terikat pada game type yang salah.
  • Peran proposer atau challenger permissioned atau dibatasi allowlist.
  • Challenger offline, tersensor, kekurangan dana, atau melewati tenggat.
  • Bug pada program bukti, VM, absolute prestate, oracle, atau verifier.
  • Kesalahan jam, perpanjangan, posisi klaim, bond, atau akuntansi resolusi.
  • Intervensi guardian, security council, pause, atau blacklist.
  • Upgrade langsung, timelock singkat, atau kunci administrator diretas.
  • Kerentanan canonical bridge, messenger, replay, atau pemetaan aset.
  • Kegagalan bukti penarikan, maturity, pembuktian ulang, finalisasi, atau relay.
  • Risiko likuiditas, harga, routing, insolvensi, atau pihak lawan fast exit.
  • Mencampur finalitas L1, finalitas turunan L2, resolusi klaim, dan penerimaan aset.

Kesalahpahaman umum

  • Optimistic berarti pengguna tanpa syarat memercayai hasil yang ditampilkan sequencer.
  • Menerbitkan state root saja menyediakan ketersediaan data dan derivasi independen.
  • Semua optimistic rollup memiliki fault proof permissionless aktif dan jam universal tujuh hari.
  • Blok L2 safe atau finalized berarti penarikan L2-ke-L1 sudah dapat dieksekusi.
  • Fast bridge memperpendek periode tantangan kanonis atau hanya membawa risiko rollup.

Topik terkait

Sumber

Navigasi

Cari di wiki...