Fraud Proof

Apa Itu Fraud Proof?

Fraud proof adalah mekanisme blockchain yang menunjukkan bahwa transisi state, hasil transaksi, penarikan, atau komputasi off-chain yang diajukan tidak benar.

Fraud proof paling sering dikaitkan dengan optimistic rollup, yang memproses transaksi mata uang kripto di luar blockchain dasar lalu menerbitkan data terkompresi dan komitmen state ke blockchain tersebut.

Sistem optimistis menerima sementara hasil yang diajukan, alih-alih mewajibkan bukti validitas kriptografis untuk setiap batch transaksi.

Selama periode challenge yang ditentukan, peserta independen dapat membantah hasil yang salah dengan mengajukan bukti bahwa aturan sistem tidak diikuti.

Jika challenge berhasil, klaim yang tidak valid ditolak, state yang benar tetap berlaku, dan peserta yang tidak jujur atau melakukan kesalahan mungkin kehilangan jaminan finansial.

Dokumentasi Ethereum tentang optimistic rollup menjelaskan bahwa sistem tersebut menganggap transaksi off-chain valid, kecuali ada pihak yang menantangnya melalui proses pembuktian fraud.

Fraud proof tidak selalu membuktikan bahwa seseorang berniat melakukan penipuan karena hasil yang tidak valid juga dapat disebabkan oleh bug perangkat lunak, kesalahan konfigurasi, masalah perangkat keras, atau kekeliruan kalkulasi yang tidak disengaja.

Karena itu, banyak developer blockchain modern menggunakan istilah yang lebih luas, yaitu fault proof, alih-alih fraud proof.

Mengapa Fraud Proof Penting dalam Kripto?

Fraud proof memungkinkan sistem blockchain memindahkan komputasi yang mahal dari base layer tanpa mengharuskan pengguna sepenuhnya memercayai satu operator terpusat.

Blockchain dasar tidak perlu mengeksekusi setiap transaksi rollup saat transaksi tersebut berlangsung.

Blockchain dasar hanya perlu menyimpan informasi yang cukup untuk merekonstruksi state rollup dan menyelesaikan sengketa ketika ada pihak yang menyatakan bahwa hasil tidak valid telah diajukan.

Desain optimistis ini dapat mengurangi biaya transaksi karena verifikasi on-chain yang mahal terutama diperlukan ketika peserta berselisih.

Fraud proof juga mendukung self-custody dengan memberi pengguna cara untuk menantang penarikan atau klaim state yang tidak valid, tanpa hanya bergantung pada organisasi yang mengoperasikan rollup.

Mekanisme ini menjadikan blockchain dasar sebagai wasit netral yang memeriksa bukti berdasarkan aturan smart contract.

Sistem yang dirancang dengan baik dapat tetap aman selama setidaknya ada satu peserta yang jujur dan mampu memantau chain serta mengajukan challenge tepat waktu.

Model keamanan ini sering diringkas sebagai asumsi satu pihak jujur.

Bagaimana Cara Kerja Fraud Proof?

Sequencer rollup mengumpulkan transaksi pengguna, mengurutkannya, mengeksekusinya, lalu membuat versi baru state rollup.

Rollup kemudian menerbitkan data transaksi atau komitmen data serta klaim mengenai state yang dihasilkan ke blockchain penyelesaian.

Klaim ini dapat disebut assertion, output root, state root, komitmen state, atau checkpoint, bergantung pada protokolnya.

Kontrak penyelesaian tidak langsung menganggap klaim tersebut final secara permanen.

Kontrak memulai periode challenge agar validator atau pihak penantang dapat menghitung ulang secara mandiri.

Pihak penantang yang jujur membandingkan hasil yang diajukan dengan hasil dari eksekusi transaksi yang dipublikasikan berdasarkan aturan resmi rollup.

Jika kedua hasil cocok, fraud proof tidak diperlukan dan klaim dapat menjadi final setelah periode challenge berakhir.

Jika hasilnya berbeda, pihak penantang memulai sengketa melalui kontrak penyelesaian.

Proses sengketa mempersempit perbedaan sampai blockchain penyelesaian dapat memverifikasi langkah komputasi yang menyebabkan hasil kedua pihak berbeda.

Kontrak kemudian menentukan klaim mana yang mengikuti aturan protokol dan menolak klaim lainnya.

Contoh Fraud Proof Sederhana

Misalkan Alice memiliki 10 token dan Bob memiliki 2 token saat rollup dimulai.

Sebuah transaksi yang valid mentransfer 3 token dari Alice kepada Bob.

State akhir yang benar membuat Alice memiliki 7 token dan Bob memiliki 5 token.

Misalkan operator rollup keliru mengajukan komitmen state yang menunjukkan bahwa Alice memiliki 6 token dan Bob memiliki 6 token.

Validator independen memutar ulang transaksi tersebut dan menghitung saldo yang benar.

Validator menantang komitmen state operator karena hasil yang diajukan tidak sesuai dengan state sebelumnya dan transaksi yang valid.

Fraud proof mengidentifikasi langkah eksekusi yang disengketakan dan memberikan informasi yang diperlukan kontrak penyelesaian untuk memverifikasi aturan transfer.

Kontrak memastikan bahwa hanya 3 token yang seharusnya berpindah dan menolak komitmen state yang salah.

Contoh ini disederhanakan, tetapi sistem fraud proof nyata menerapkan prinsip yang sama pada eksekusi smart contract kompleks, kalkulasi gas, pembaruan penyimpanan, dan komitmen kriptografis.

Apa Itu Optimistic Rollup?

Optimistic rollup adalah sistem penskalaan Layer 2 yang mengeksekusi transaksi mata uang kripto di luar blockchain dasar, tetapi menggunakan blockchain tersebut untuk ketersediaan data, penyelesaian, dan resolusi sengketa.

Istilah “optimistis” berarti batch transaksi secara default dianggap valid, alih-alih langsung disertai bukti bahwa setiap komputasi benar.

Pengguna biasanya dapat memperoleh konfirmasi cepat di dalam rollup karena sequencer melaporkan hasil segera setelah transaksi diproses.

Namun, perpindahan dari rollup kembali ke layer penyelesaian mungkin memerlukan waktu lebih lama karena klaim state harus melewati periode challenge.

Optimistic rollup berbeda dari sidechain biasa karena keamanannya dirancang agar sangat bergantung pada blockchain penyelesaian, bukan hanya kelompok validator independen.

Dokumentasi penskalaan Ethereum membedakan optimistic rollup, yang mengeksekusi komputasi sengketa melalui fraud proof, dari zero-knowledge rollup, yang mengirimkan validity proof.

Apa Itu State Root?

State root adalah komitmen kriptografis ringkas yang merepresentasikan keseluruhan state blockchain atau rollup pada waktu tertentu.

State dapat mencakup saldo akun, kode smart contract, nilai penyimpanan, nonce, dan informasi lain yang diperlukan untuk memproses transaksi berikutnya.

State root jauh lebih kecil daripada database lengkap yang mendasarinya.

Perubahan sekecil apa pun pada nilai yang relevan biasanya mengubah komitmen yang dihasilkan.

Pengaju rollup dapat menerbitkan state root tanpa memasukkan seluruh state ke dalam kontrak penyelesaian.

Peserta lain dapat merekonstruksi state dari data transaksi yang tersedia dan memeriksa apakah mereka memperoleh root yang sama.

Sengketa fraud proof sering dimulai karena dua pihak menghasilkan root berbeda dari state awal dan rangkaian transaksi yang seharusnya sama.

Apa Itu Transisi State?

Transisi state adalah proses mengubah state blockchain lama menjadi state baru dengan mengeksekusi satu atau lebih transaksi yang valid.

Rumus sederhananya adalah

.

Fungsi transisi state memuat aturan protokol yang mengatur tanda tangan, saldo, gas, eksekusi kontrak, penyimpanan, dan pengurutan transaksi.

Setiap peserta yang jujur dan menggunakan input serta versi protokol yang sama seharusnya menghitung hasil yang sama.

Fraud proof menunjukkan bahwa state baru yang diajukan tidak dihasilkan dengan benar dari state lama dan input yang dipublikasikan.

Eksekusi deterministik sangat penting karena sengketa tidak dapat diselesaikan secara andal jika komputer yang jujur dapat menghasilkan jawaban berbeda dari input yang sama.

Apa Itu Periode Challenge?

Periode challenge adalah waktu ketika hasil optimistis dapat disengketakan sebelum menjadi final untuk keperluan penyelesaian.

Banyak desain optimistic rollup menggunakan periode yang mendekati satu minggu, meskipun durasi tepatnya bergantung pada protokol dan dapat berubah melalui tata kelola atau peningkatan.

Masa tunggu memberi validator independen waktu untuk mengunduh data, menghitung ulang eksekusi, mendeteksi klaim yang tidak valid, memperoleh dana untuk biaya transaksi atau jaminan, dan mengajukan challenge.

Periode yang terlalu singkat dapat membuat keamanan sangat bergantung pada pemantauan terus-menerus, infrastruktur cepat, dan akses tanpa gangguan ke blockchain penyelesaian.

Periode yang terlalu lama dapat mengurangi efisiensi modal dan membuat penarikan standar menjadi tidak praktis.

Panduan ketersediaan data Ethereum menjelaskan bahwa optimistic rollup biasanya menyediakan jendela sengketa agar verifikator independen dapat memeriksa data yang dipublikasikan dan menantang transisi state yang salah.

Pengguna sebaiknya memeriksa aturan challenge dan finalisasi jaringan tertentu, bukan menganggap setiap optimistic rollup menggunakan waktu tepat tujuh hari.

Mengapa Penarikan Memerlukan Waktu?

Penarikan standar dari optimistic rollup mungkin tertunda karena kontrak penyelesaian harus memastikan aset tidak dilepas berdasarkan klaim state yang tidak valid.

Jika klaim palsu dapat langsung menjadi final, penyerang mungkin menciptakan saldo fiktif dan menarik aset yang terkunci di layer penyelesaian sebelum ada pihak yang dapat merespons.

Periode challenge memberi validator waktu untuk membuktikan bahwa penarikan bergantung pada state rollup yang tidak valid.

Setelah komitmen state terkait menjadi final, penarikan dapat diselesaikan sesuai aturan bridge protokol.

Pengguna mungkin dapat memperoleh akses lebih cepat melalui pengaturan likuiditas pihak ketiga, tetapi pengaturan tersebut menambahkan biaya terpisah, persyaratan likuiditas, risiko smart contract, dan asumsi pihak lawan.

Panduan Ethereum tentang zero-knowledge rollup menjelaskan bahwa penarikan optimistic ditunda agar challenge fraud proof dapat diajukan, sedangkan sistem validity proof dapat memfinalisasi penarikan setelah bukti diverifikasi.

Apa Itu Fraud Proof Interaktif?

Fraud proof interaktif menggunakan game sengketa bertahap antara pihak-pihak yang berbeda pendapat mengenai komputasi panjang.

Mengirimkan dan mengeksekusi ulang seluruh blok rollup secara langsung di blockchain penyelesaian dapat terlalu mahal atau melampaui batas transaksi.

Sebagai gantinya, pengaju dan pihak penantang membuat komitmen atas trace eksekusi yang berbeda, lalu berulang kali mempersempit bagian yang disengketakan.

Pendekatan yang umum membagi trace menjadi beberapa bagian lebih kecil melalui proses yang disebut bisection.

Setiap putaran mengidentifikasi bagian mana yang memuat perbedaan pertama.

Proses berlanjut sampai sengketa menyangkut satu instruksi mesin atau operasi kecil lain yang dapat diverifikasi langsung oleh kontrak penyelesaian.

Blockchain penyelesaian tidak perlu mengulang setiap langkah karena hanya memeriksa komitmen, langkah sengketa, dan instruksi terakhir yang disengketakan.

Dokumentasi resmi desain sengketa interaktif terkini menjelaskan cara sengketa dapat dipersempit menjadi bukti satu langkah yang diverifikasi blockchain induk.

Apa Itu Bukti Satu Langkah?

Bukti satu langkah memberikan informasi yang cukup agar kontrak penyelesaian dapat memverifikasi satu instruksi yang disengketakan dalam trace eksekusi rollup.

Bukti tersebut mengidentifikasi state mesin sebelum instruksi, instruksi itu sendiri, data input yang diperlukan, dan state yang diklaim setelah eksekusi.

Kontrak penyelesaian menerapkan aturan instruksi dan menghitung state berikutnya yang benar.

Jika hasilnya cocok dengan klaim pihak penantang, bukan klaim pengaju, pihak penantang memenangkan sengketa.

Verifikasi satu langkah membuat komputasi off-chain yang besar dapat ditegakkan tanpa blockchain penyelesaian harus menjalankan seluruh program rollup secara rutin.

Mesin virtual yang digunakan untuk eksekusi bukti harus deterministik dan secara akurat merepresentasikan aturan konsensus rollup.

Apa Itu Fraud Proof Noninteraktif?

Fraud proof noninteraktif berupaya menyediakan seluruh bukti yang diperlukan untuk menunjukkan transisi yang tidak valid melalui satu pengajuan atau proses verifikasi terbatas.

Desain ini dapat mengurangi kebutuhan akan respons berulang antara pengaju dan pihak penantang.

Bukti tersebut mungkin perlu memuat lebih banyak data atau menggunakan metode khusus untuk mengisolasi komputasi yang salah.

Sistem interaktif dapat mengurangi pekerjaan on-chain dengan mempersempit sengketa selama beberapa putaran, sedangkan sistem noninteraktif mungkin mempercepat penyelesaian dan mengurangi ketergantungan pada kelancaran proses selama sengketa.

Desain terbaik bergantung pada kompleksitas eksekusi, biaya layer penyelesaian, ukuran bukti, keamanan implementasi, dan jenis kegagalan yang harus ditangani protokol.

Fraud Proof vs. Fault Proof

Fraud proof dan fault proof sering digunakan untuk menyebut mekanisme sengketa optimistis yang sama secara umum.

Istilah fraud proof secara historis umum digunakan karena menggambarkan bukti untuk menantang tindakan tidak jujur.

Istilah fault proof lebih tepat karena mekanisme tersebut memeriksa apakah hasilnya salah, bukan menentukan niat operator.

Output yang salah dapat disebabkan manipulasi berbahaya, perangkat lunak usang, konfigurasi keliru, database rusak, atau kesalahan pemrograman biasa.

Dokumentasi protokol saat ini semakin sering menggunakan istilah fault proof untuk menjelaskan sistem sengketa yang beroperasi.

Dokumentasi resmi sistem fault proof menjelaskan arsitektur modular yang mencakup program fault proof, mesin virtual fault proof, dan protokol game sengketa.

Fraud Proof vs. Validity Proof

Fraud proof menunjukkan bahwa hasil yang diajukan salah setelah ada pihak yang menantangnya.

Validity proof menunjukkan bahwa transisi state yang diajukan benar sebelum kontrak penyelesaian menerimanya.

Optimistic rollup umumnya menerbitkan klaim state tanpa validity proof dan bergantung pada jendela challenge.

Validity rollup menghasilkan bukti kriptografis, sering kali menggunakan teknologi zero-knowledge proof, untuk batch komputasi off-chain.

Verifier validity proof dapat langsung menolak batch yang salah karena penyerang seharusnya tidak mampu membuat bukti valid untuk transisi yang tidak valid.

Sistem fraud proof dapat memerlukan lebih sedikit komputasi selama operasi normal karena tidak perlu menghitung sengketa jika semua klaim benar.

Sistem validity proof dapat menawarkan penyelesaian lebih cepat setelah bukti dibuat, tetapi mungkin memerlukan infrastruktur proving yang kompleks dan kriptografi khusus.

Kedua desain tidak otomatis lebih unggul karena keamanan juga bergantung pada ketersediaan data, kualitas implementasi, wewenang tata kelola, kontrol peningkatan, dan layer penyelesaian.

Fraud Proof vs. Zero-Knowledge Proof

Zero-knowledge proof memungkinkan satu pihak membuktikan bahwa suatu pernyataan benar tanpa mengungkap setiap input privat yang digunakan untuk membuktikannya.

Banyak sistem validity blockchain menggunakan bukti ringkas zero-knowledge meskipun data transaksi tetap tersedia secara publik untuk rekonstruksi state.

Fraud proof biasanya bersifat reaktif karena dibuat setelah hasil yang salah diajukan.

Validity proof zero-knowledge biasanya bersifat proaktif karena menyertai atau mendahului penerimaan state baru.

Fraud proof bergantung pada adanya kesempatan bagi pihak yang jujur untuk mengetahui dan menantang kesalahan.

Validity proof bergantung pada soundness kriptografis dan implementasi verifier yang benar.

Arsitektur rollup mendatang mungkin menggabungkan fault proof, validity proof, attestasi, dan beberapa implementasi independen untuk mengurangi ketergantungan pada satu sistem.

Fraud Proof vs. Merkle Proof

Merkle proof menunjukkan bahwa item tertentu termasuk dalam dataset yang direpresentasikan oleh Merkle root.

Contohnya, bukti tersebut dapat menunjukkan bahwa saldo akun, transaksi, atau pesan penarikan tercakup dalam pohon yang dikomitmenkan.

Fraud proof menunjukkan bahwa komputasi atau transisi state yang diklaim tidak valid.

Fraud proof sering memuat Merkle proof agar kontrak penyelesaian dapat mengakses hanya bagian kecil state yang diperlukan untuk memverifikasi langkah yang disengketakan.

Merkle proof dapat membuktikan inklusi tanpa membuktikan bahwa transaksi yang tercakup dieksekusi dengan benar.

Karena itu, kedua jenis bukti memiliki fungsi berbeda, tetapi sering digunakan bersama.

Peran Ketersediaan Data

Fraud proof tidak dapat melindungi rollup jika pihak penantang tidak memiliki data yang diperlukan untuk merekonstruksi state dan mengidentifikasi eksekusi yang salah.

Jika tidak, operator berbahaya dapat menerbitkan komitmen state sambil menahan transaksi yang mendasarinya.

Validator independen akan mengetahui bahwa mereka tidak dapat menghitung ulang hasilnya, tetapi mungkin tidak mampu membuat bukti tepat atas kesalahan tersebut.

Optimistic rollup mengatasi masalah ini dengan menerbitkan data transaksi terkompresi atau komitmen data yang diakui protokol melalui layer penyelesaian.

Rollup Ethereum dapat menerbitkan data melalui calldata transaksi biasa atau melalui transaksi blob yang dirancang untuk data rollup.

Spesifikasi EIP-4844 memperkenalkan transaksi yang memuat blob agar rollup dapat menerbitkan data sementara dengan biaya lebih rendah dibandingkan calldata eksekusi permanen.

Karena data blob hanya disimpan protokol dalam waktu terbatas, sistem pemantauan harus mengambil dan menyimpan informasi yang diperlukan selama periode challenge.

Karena itu, ketersediaan data merupakan bagian inti keamanan fraud proof, bukan fitur opsional yang terpisah.

Peran Blockchain Penyelesaian

Blockchain penyelesaian menyimpan komitmen rollup, menerima transaksi sengketa, mengelola jaminan peserta, dan menjalankan logika verifikasi akhir.

Blockchain ini bertindak sebagai wasit netral karena aturan konsensusnya menentukan langkah sengketa dan bukti yang valid.

Rollup mewarisi sebagian keamanannya dari finalitas, ketahanan terhadap sensor, eksekusi smart contract, dan ketersediaan data pada layer penyelesaian.

Jika blockchain penyelesaian berhenti memfinalisasi blok, klaim dan penarikan rollup juga dapat berhenti diproses.

Jika penyerang dapat menyensor setiap challenge yang jujur selama seluruh periode sengketa, klaim yang tidak valid akan sulit dihentikan.

Karena itu, keamanan fraud proof bergantung pada ketersediaan dan ketahanan rollup serta blockchain penyelesaian terhadap sensor berkepanjangan.

Peran Sequencer

Sequencer menerima transaksi pengguna, memilih urutannya, mengeksekusi blok rollup, serta menerbitkan batch atau komitmen transaksi.

Sequencer terpusat dapat memberikan konfirmasi cepat, tetapi mungkin menunda, mengurutkan ulang, atau menyensor transaksi.

Fraud proof melindungi dari eksekusi yang tidak valid, tetapi tidak otomatis mencegah semua bentuk sensor transaksi atau pengurutan yang merugikan.

Sequencer dapat menerbitkan state valid yang mengikuti aturan protokol, tetapi tetap mengecualikan sementara transaksi pengguna.

Sistem rollup dapat menyediakan jalur forced inclusion yang memungkinkan pengguna mengirim transaksi melalui layer penyelesaian ketika sequencer menolaknya.

Pengguna sebaiknya membedakan kebenaran eksekusi, yang ditangani fraud proof, dari keadilan pengurutan dan kelancaran operasi, yang memerlukan mekanisme tambahan.

Peran Pihak Penantang

Pihak penantang adalah peserta atau layanan otomatis yang memantau state rollup yang diajukan dan menyengketakan klaim yang tidak valid.

Pihak penantang menjalankan perangkat lunak node yang kompatibel dan mereproduksi eksekusi rollup berdasarkan data dari layer penyelesaian.

Pihak tersebut harus tetap online, mengikuti peningkatan protokol, menyimpan informasi historis yang diperlukan, dan mengirim transaksi sebelum tenggat terkait.

Pihak penantang mungkin memerlukan mata uang kripto untuk biaya gas layer penyelesaian dan jaminan finansial.

Perangkat lunak pihak penantang terkini dapat memantau sengketa, membela proposal yang valid, menantang proposal yang tidak valid, dan mengklaim jaminan setelah menang.

Dokumentasi resmi pihak penantang menjelaskan layanan produksi yang bergantung pada node rollup tersinkronisasi dan penyedia trace deterministik.

Partisipasi permissionless paling berarti jika pihak independen secara teknis dapat menjalankan layanan penantang tanpa persetujuan organisasi terpusat.

Mengapa Jaminan Digunakan?

Jaminan adalah mata uang kripto yang dikunci peserta saat mengajukan klaim atau melakukan langkah tertentu dalam sengketa.

Jaminan menghalangi penyerang membuat klaim palsu tanpa batas atau memaksa validator jujur menghabiskan sumber daya tanpa konsekuensi finansial.

Peserta yang mendukung klaim keliru dapat kehilangan sebagian atau seluruh jaminan terkait.

Pihak penantang yang berhasil dapat memperoleh kembali jaminannya dan menerima reward ekonomi, bergantung pada protokol.

Jumlah jaminan harus cukup besar untuk mencegah penyalahgunaan, tetapi tidak boleh terlalu besar sehingga hanya organisasi kaya yang dapat berpartisipasi.

Jaminan yang terlalu tinggi dapat membuat sistem fraud proof yang secara teori permissionless menjadi sulit diakses dalam praktik.

Jaminan yang terlalu rendah dapat mendorong spam, gangguan, dan serangan penundaan.

Desain jaminan harus mempertimbangkan biaya layer penyelesaian, volatilitas aset, durasi sengketa, biaya peluang modal, dan nilai yang dipertaruhkan.

Fraud Proof Permissionless vs. Permissioned

Sistem fraud proof permissionless mengizinkan peserta mana pun yang memenuhi persyaratan teknis dan ekonomi yang diumumkan untuk mengajukan atau menantang klaim state.

Sistem permissioned membatasi pengajuan, challenge, atau keduanya hanya kepada alamat atau organisasi yang disetujui.

Validasi permissioned dapat mengurangi spam dan ketidakpastian operasional selama tahap awal pengembangan.

Namun, sistem ini menimbulkan asumsi kepercayaan karena pengguna bergantung pada validator yang disetujui agar tetap jujur, tersedia, dan independen.

Sistem permissionless meningkatkan keterbukaan, tetapi memerlukan perlindungan kuat dari gangguan, serangan penundaan, manipulasi jaminan, dan eksploitasi perangkat lunak.

Jaringan dapat menjalankan game sengketa permissionless sambil tetap mempertahankan dewan darurat atau wewenang peningkatan yang dapat menjeda atau mengganti bagian sistem.

Pengguna sebaiknya memeriksa keseluruhan model keamanan dan tidak berasumsi bahwa jalur challenge permissionless menghapus semua wewenang administratif.

Perkembangan Fraud Proof Saat Ini

Per Juli 2026, sistem fault proof produksi terus berkembang melalui klien baru, mesin virtual yang ditingkatkan, protokol sengketa yang disempurnakan, dan partisipasi permissionless yang lebih luas.

Dokumentasi resmi OP Stack menjelaskan challenge permissionless dan transisi pada 2026 ke klien fault proof yang lebih baru, yang menunjukkan bahwa operator pihak penantang harus menggunakan perangkat lunak terbaru dan absolute prestate yang berlaku.

Pemberitahuan resmi migrasi klien fault proof 2026 menjelaskan bahwa perangkat lunak proof lama telah mencapai akhir masa dukungan dan operator chain harus bermigrasi ke implementasi penggantinya.

Dokumentasi resmi Arbitrum menjelaskan BoLD sebagai desain sengketa berbatas waktu yang mendukung validasi permissionless dan membatasi kemampuan pihak berbahaya untuk memperpanjang sengketa tanpa batas.

Ikhtisar BoLD 2026 menjelaskan bagaimana fraud proof interaktif dapat memungkinkan challenge terbuka sekaligus membatasi durasi sengketa.

Perkembangan ini menunjukkan bahwa fraud proof merupakan sistem keamanan produksi yang aktif, bukan sekadar gagasan blockchain teoretis.

Perkembangan tersebut juga menunjukkan bahwa sistem proof memerlukan audit berkelanjutan, pemeliharaan klien, koordinasi peningkatan, pemantauan, dan respons insiden.

Fraud Proof dan Peningkatan Perangkat Lunak

Program fault proof harus menjalankan aturan konsensus yang sama dengan versi rollup yang statenya sedang disengketakan.

Peningkatan protokol dapat mengubah eksekusi transaksi, biaya gas, precompile, aturan blok, kontrak sistem, atau interpretasi data.

Perangkat lunak pihak penantang yang menggunakan aturan usang dapat keliru mengklasifikasikan klaim valid sebagai tidak valid atau gagal menantang klaim yang benar-benar tidak valid.

Sistem proof sering menggunakan absolute prestate yang mengikat kondisi awal mesin virtual proof.

Perubahan pada program proof atau aturan konsensus dapat memerlukan prestate baru dan kontrak on-chain yang diperbarui.

Operator harus mengoordinasikan peningkatan dengan cermat agar sengketa lama dan baru dapat diselesaikan berdasarkan aturan yang benar.

Kompleksitas ini merupakan salah satu alasan beberapa implementasi proof independen dianggap penting bagi keamanan jangka panjang.

Apa Itu Serangan Penundaan?

Serangan penundaan berupaya memperpanjang penyelesaian sengketa atau mencegah state valid menjadi final tanpa berhasil membuktikan bahwa state tersebut tidak valid.

Penyerang dapat membuat klaim yang bertentangan, memaksa putaran challenge berulang, mengeksploitasi aturan waktu, atau mengunci modal peserta yang jujur.

Desain interaktif yang lebih lama dapat memungkinkan penyerang memulai sengketa berurutan sehingga penarikan terus tertunda.

Desain sengketa berbatas waktu bertujuan memastikan banyak klaim berbahaya dapat diselesaikan dalam jangka maksimum yang dapat diprediksi.

Jaminan finansial membuat serangan penundaan lebih mahal, tetapi aturan waktu dan game yang baik tetap diperlukan.

Sistem harus melindungi safety, yaitu klaim yang tidak valid tidak menjadi final, sekaligus melindungi liveness, yaitu klaim valid pada akhirnya menjadi final.

Safety vs. Liveness

Safety berarti sistem fraud proof tidak menerima state yang tidak valid atau mengizinkan penarikan tanpa otorisasi.

Liveness berarti transaksi, klaim state, dan penarikan yang jujur pada akhirnya dapat diproses hingga selesai.

Sistem dapat mempertahankan safety dengan menjeda semua penarikan selama terjadi ketidakpastian, tetapi tindakan tersebut merugikan liveness.

Sistem dapat meningkatkan liveness dengan memfinalisasi klaim secara cepat, tetapi periode challenge yang terlalu singkat dapat melemahkan safety.

Kontrol darurat, batas waktu sengketa, jaminan, periode challenge, dan aturan izin menyeimbangkan kedua tujuan tersebut.

Pengguna yang menilai suatu rollup sebaiknya mempertimbangkan apakah dana dapat dicuri dan apakah dana dapat tidak tersedia dalam waktu lama.

Asumsi Keamanan Utama Fraud Proof

Rollup fraud proof umumnya mengasumsikan setidaknya ada satu pihak jujur yang dapat merekonstruksi state rollup dan menantang klaim yang tidak valid.

Data transaksi yang diperlukan harus tetap tersedia cukup lama agar pihak tersebut dapat melakukan verifikasi.

Blockchain penyelesaian harus terus memproses transaksi dan tidak boleh menyensor semua challenge yang jujur sepanjang periode sengketa.

Fungsi transisi state rollup dan mesin virtual proof harus menerapkan aturan yang dimaksud dengan benar.

Kontrak sengketa on-chain harus mengevaluasi langkah, tenggat, jaminan, komitmen, dan bukti akhir dengan benar.

Pihak penantang yang jujur harus menggunakan perangkat lunak terkini, sumber daya komputasi yang memadai, sumber data andal, serta dana yang cukup untuk gas dan jaminan.

Kunci peningkatan, guardian, dewan keamanan, dan kontrak tata kelola tidak boleh menyalahgunakan wewenang apa pun yang dapat mengesampingkan atau mengganti sistem proof.

Bisakah Satu Pihak Penantang Jujur Melindungi Semua Pengguna?

Secara teori, satu pihak penantang yang jujur dapat mencegah klaim state tidak valid menjadi final jika protokolnya permissionless dan seluruh asumsi yang diperlukan terpenuhi.

Pihak penantang tidak memerlukan dukungan dari mayoritas pengguna rollup karena kontrak penyelesaian memutuskan sengketa berdasarkan aturan eksekusi objektif.

Namun, pihak yang jujur tersebut harus mendeteksi kesalahan, memiliki data yang diperlukan, tetap online, mampu membiayai partisipasi, dan tidak terkena sensor.

Sistem yang secara teknis hanya memerlukan satu pihak penantang akan lebih kuat jika beberapa pihak independen menggunakan infrastruktur dan implementasi perangkat lunak yang berbeda.

Keberagaman mengurangi risiko bahwa satu bug, gangguan layanan, pembatasan hukum, atau kegagalan cloud melumpuhkan semua pemantau secara bersamaan.

Bisakah Fraud Proof Menghentikan Setiap Serangan Rollup?

Fraud proof dapat menolak transisi state yang tidak valid, tetapi tidak menyelesaikan setiap masalah keamanan yang memengaruhi rollup.

Fraud proof tidak otomatis mencegah sensor sequencer, pencurian kunci pengguna, kontrak aplikasi berbahaya, phishing, manipulasi oracle, atau serangan tata kelola.

Fraud proof mungkin tidak melindungi pengguna jika data disimpan di luar layer penyelesaian dengan asumsi ketersediaan yang lebih lemah.

Fraud proof juga tidak dapat membantu jika sistemnya sendiri memiliki bug serius yang sama-sama membuat peserta jujur dan tidak jujur menghitung hasil yang salah.

Rollup yang aman memerlukan fraud proof beserta ketersediaan data yang kuat, kontrak bridge yang diaudit, prosedur peningkatan yang aman, node andal, dan tata kelola transparan.

Fraud Proof dalam Plasma

Sistem Plasma menggunakan blockchain induk untuk menyelesaikan sengketa terkait aktivitas di child chain terpisah.

Pengguna dapat mengajukan fraud proof ketika operator berusaha memfinalisasi transaksi atau state yang tidak valid.

Desain Plasma tradisional umumnya menyimpan sebagian besar data transaksinya di luar blockchain induk.

Struktur ini menimbulkan masalah penahanan data karena pengguna mungkin tidak dapat membuat fraud proof jika operator menolak memberikan informasi yang diperlukan.

Dokumentasi Plasma Ethereum menjelaskan bahwa rollup meningkatkan model keamanan ini dengan menerbitkan data transaksi melalui layer penyelesaian.

Fraud proof digunakan di Plasma maupun optimistic rollup, tetapi jaminan ketersediaan data di sekitarnya berbeda.

Fraud Proof dalam State Channel

State channel memungkinkan sekelompok peserta tertentu bertukar pembaruan state bertanda tangan di luar blockchain.

Peserta biasanya menggunakan blockchain hanya untuk membuka channel, menyelesaikan state akhir, atau menyelesaikan sengketa.

Peserta yang tidak jujur mungkin mencoba menutup channel menggunakan state lama yang memberikan saldo lebih menguntungkan baginya.

Peserta yang jujur dapat merespons selama jendela sengketa dengan menunjukkan state bertanda tangan yang lebih baru dan benar.

Bukti ini berfungsi sebagai fraud proof karena menunjukkan bahwa penyelesaian yang diajukan sudah kedaluwarsa atau tidak valid.

Panduan state channel Ethereum menjelaskan cara arbitrase sengketa melindungi pengguna saat state yang tidak valid atau sudah kedaluwarsa diajukan.

Pengaruh Fraud Proof terhadap Pengguna Kripto

Sebagian besar pengguna rollup tidak mengajukan fraud proof sendiri karena validator dan layanan pemantauan khusus melakukan verifikasi terus-menerus.

Namun, pengguna tetap bergantung pada mekanisme tersebut saat menyimpan aset, menggunakan aplikasi, atau menarik dana melalui bridge kanonis optimistic rollup.

Pengguna mungkin melihat transaksi terkonfirmasi dengan cepat di rollup, sementara finalitas pada layer penyelesaian masih menunggu.

Challenge yang berhasil dapat membatalkan hasil yang belum final dan dibangun di atas klaim state tidak valid.

Wallet dan aplikasi sebaiknya menjelaskan perbedaan antara konfirmasi sequencer, konfirmasi penyelesaian, dan finalitas penarikan yang sudah selesai.

Pengguna juga sebaiknya memahami apakah fraud proof jaringan sudah aktif, bersifat permissionless, dapat ditingkatkan, atau didukung kontrol administratif darurat.

Cara Developer Merancang Sistem dengan Fraud Proof

Developer rollup harus memastikan bahwa setiap operasi yang relevan bagi konsensus dapat direproduksi secara deterministik di lingkungan proof.

Developer sebaiknya menghindari ketergantungan pada waktu lokal, perilaku acak sistem operasi, layanan eksternal yang tidak terdokumentasi, atau hasil spesifik perangkat keras.

Kode proof, kode node, dan kontrak verifikasi on-chain harus menyepakati semantik instruksi dan format data.

Developer sebaiknya menguji output yang tidak valid, respons tertunda, klaim yang bertentangan, data hilang, kehabisan jaminan, dan peningkatan protokol.

Developer harus menyediakan prosedur yang jelas untuk menjalankan pihak penantang serta memverifikasi prestate dan alamat kontrak yang diperlukan.

Audit keamanan harus memeriksa jalur eksekusi rollup normal maupun jalur sengketa yang jarang digunakan.

Sistem sengketa yang tidak pernah diuji dalam kondisi adversarial yang realistis mungkin gagal saat akhirnya diperlukan.

Cara Menilai Sistem Fraud Proof

Pastikan terlebih dahulu apakah jaringan tersebut benar-benar memiliki sistem fraud proof aktif, bukan hanya roadmap atau desain yang direncanakan.

Periksa apakah siapa pun dapat mengajukan challenge atau apakah partisipasi dikendalikan oleh allowlist.

Identifikasi periode challenge, penundaan penarikan, persyaratan jaminan, tenggat sengketa, dan perkiraan waktu penyelesaian maksimum.

Pastikan di mana data transaksi diterbitkan dan apakah pengguna dapat merekonstruksi state rollup secara mandiri.

Tinjau apakah guardian darurat, dewan keamanan, administrator, atau kontrak tata kelola dapat mengesampingkan hasil yang telah final.

Carilah beberapa operator pihak penantang, perangkat lunak node publik, build yang dapat direproduksi, audit, pengungkapan kerentanan, dan program bug bounty.

Pastikan cara sistem proof menangani peningkatan protokol dan sengketa yang dimulai dengan versi perangkat lunak lama.

Penjelasan keamanan yang kuat seharusnya menguraikan keterbatasan dan asumsi kepercayaan, bukan sekadar menyatakan bahwa rollup mewarisi seluruh keamanan base layer.

Kesalahpahaman Umum tentang Fraud Proof

Kesalahpahaman yang umum adalah bahwa setiap transaksi rollup disertai fraud proof.

Fraud proof umumnya hanya dibuat ketika seseorang menantang hasil yang disengketakan.

Kesalahpahaman lainnya adalah bahwa fraud proof membuktikan adanya niat kriminal atau tidak jujur.

Mekanisme ini membuktikan adanya komputasi atau klaim yang salah, sedangkan niat secara hukum merupakan persoalan terpisah.

Sebagian pengguna mengira penundaan penarikan selama seminggu berarti transaksi rollup itu sendiri memerlukan waktu seminggu untuk dieksekusi.

Transaksi rollup mungkin dieksekusi dalam hitungan detik, sedangkan periode yang lebih lama berlaku untuk keamanan penyelesaian dan penarikan kanonis.

Kesalahan lainnya adalah menganggap fraud proof permissionless menghapus semua kontrol terpusat.

Rollup dapat memiliki challenge terbuka, tetapi tetap menggunakan sequencing terpusat, kunci peningkatan, guardian, atau wewenang jeda darurat.

Risiko Fraud Proof

Risiko implementasi muncul jika program proof, mesin virtual, atau smart contract mengandung bug.

Risiko ketersediaan data muncul jika pihak penantang tidak dapat memperoleh informasi yang diperlukan untuk merekonstruksi state yang disengketakan.

Risiko sensor muncul jika transaksi fraud proof yang jujur tidak dapat mencapai blockchain penyelesaian sebelum tenggat.

Risiko liveness muncul jika klaim berbahaya atau kegagalan perangkat lunak menunda penarikan yang valid.

Risiko ekonomi muncul jika harga gas atau persyaratan jaminan membuat challenge terlalu mahal.

Risiko peningkatan muncul jika node, program proof, kontrak, dan prestate tidak mengikuti versi protokol yang sama.

Risiko tata kelola muncul jika pihak istimewa dapat menjeda, mengganti, atau mengesampingkan sistem sengketa.

Risiko operasional muncul jika semua pihak penantang bergantung pada penyedia cloud, basis kode, database, atau layanan pemantauan yang sama.

FAQ

Apa itu fraud proof secara sederhana?

Fraud proof adalah bukti bahwa hasil blockchain atau rollup yang diajukan dihitung secara keliru.

Mengapa fraud proof digunakan dalam kripto?

Fraud proof memungkinkan komputasi off-chain meningkatkan skalabilitas blockchain sekaligus memberi peserta independen cara untuk menolak hasil yang tidak valid.

Apa perbedaan fraud proof dan fault proof?

Kedua istilah tersebut biasanya merujuk pada mekanisme yang sama, tetapi fault proof tidak menyiratkan bahwa setiap hasil yang salah merupakan tindakan yang sengaja menipu.

Sistem kripto apa yang menggunakan fraud proof?

Fraud proof terutama digunakan dalam optimistic rollup, meskipun mekanisme sengketa terkait juga terdapat pada sistem Plasma dan state channel.

Apakah setiap transaksi optimistic rollup menghasilkan fraud proof?

Tidak. Fraud proof biasanya hanya dibuat ketika peserta menyengketakan klaim state yang salah.

Siapa yang dapat mengajukan fraud proof?

Siapa pun dapat mengajukannya dalam sistem yang sepenuhnya permissionless, sedangkan sistem permissioned membatasi challenge kepada peserta yang disetujui.

Apa itu pihak penantang?

Pihak penantang adalah peserta atau layanan otomatis yang memeriksa klaim state rollup dan menyengketakan klaim yang tidak mengikuti aturan protokol.

Apa itu periode challenge?

Periode challenge adalah waktu ketika state optimistis yang diajukan dapat disengketakan sebelum menjadi final.

Berapa lama periode challenge fraud proof?

Durasi bergantung pada protokol, meskipun periode yang mendekati satu minggu umum digunakan dalam optimistic rollup produksi.

Mengapa penarikan optimistic rollup memerlukan beberapa hari?

Penundaan tersebut memberi pihak penantang waktu untuk menghentikan penarikan berdasarkan state rollup yang tidak valid atau direkayasa.

Dapatkah fraud proof membatalkan transaksi?

Fraud proof dapat membatalkan klaim state yang belum final dan hasil yang dibangun di atasnya, sesuai aturan sengketa dan pemulihan rollup.

Apa itu fraud proof interaktif?

Fraud proof interaktif menggunakan beberapa putaran sengketa untuk mempersempit komputasi panjang menjadi satu langkah kecil yang dapat diperiksa secara on-chain.

Apa itu bisection dalam fraud proof?

Bisection berulang kali membagi trace eksekusi agar pihak yang bersengketa dapat mengisolasi titik pertama ketika hasil mereka berbeda.

Apa itu bukti satu langkah?

Bukti satu langkah memungkinkan kontrak penyelesaian memverifikasi satu instruksi mesin yang disengketakan dan menentukan peserta mana yang menghitungnya dengan benar.

Apa itu output root?

Output root adalah komitmen kriptografis terhadap state rollup dan informasi terkait pada blok tertentu.

Apa itu asumsi satu pihak jujur?

Asumsi ini menyatakan bahwa setidaknya satu peserta yang mampu akan mendeteksi dan menantang state tidak valid sebelum tenggat.

Apakah sistem fraud proof memerlukan banyak validator?

Secara teori, satu pihak penantang yang jujur mungkin cukup, tetapi beberapa pihak penantang independen memberikan ketahanan operasional yang lebih kuat.

Mengapa ketersediaan data diperlukan?

Pihak penantang memerlukan data transaksi untuk merekonstruksi state rollup dan menunjukkan dengan tepat bagian transisi yang salah.

Bisakah fraud proof berfungsi jika data transaksi disembunyikan?

Fraud proof mungkin gagal jika data tersembunyi diperlukan untuk mereproduksi eksekusi dan protokol tidak menyediakan bukti terpisah atas ketersediaan data.

Apa perbedaan fraud proof dan validity proof?

Fraud proof menunjukkan bahwa hasil salah setelah challenge, sedangkan validity proof menunjukkan bahwa hasil benar sebelum diterima.

Apakah fraud proof merupakan zero-knowledge proof?

Bukan. Fraud proof umumnya merupakan mekanisme sengketa optimistis, meskipun sistem canggih dapat menggabungkan fault proof dengan teknologi zero-knowledge.

Apakah Merkle proof sama dengan fraud proof?

Tidak. Merkle proof membuktikan inklusi dalam dataset yang dikomitmenkan, sedangkan fraud proof menunjukkan komputasi atau transisi state yang salah.

Apa yang terjadi jika fraud proof berhasil?

Klaim yang tidak valid ditolak, state yang benar dipertahankan, dan peserta yang kalah mungkin kehilangan jaminan.

Apa yang terjadi jika challenge gagal?

Klaim yang ditantang dapat terus menuju finalisasi dan pihak penantang yang gagal mungkin kehilangan sebagian dana jaminannya.

Mengapa jaminan diperlukan?

Jaminan mencegah klaim palsu, spam, dan sengketa yang tidak perlu dengan membuat partisipasi yang tidak jujur atau ceroboh menimbulkan biaya finansial.

Bisakah fraud proof menghentikan sensor sequencer?

Tidak. Fraud proof memverifikasi kebenaran eksekusi, sedangkan ketahanan terhadap sensor biasanya memerlukan jalur forced inclusion dan fitur protokol lainnya.

Bisakah fraud proof mencegah peretasan smart contract?

Tidak. Transaksi aplikasi berbahaya atau rentan yang dieksekusi dengan benar tetap dapat dianggap valid berdasarkan aturan transisi state rollup.

Bisakah kontrak fraud proof mengandung bug?

Ya. Program proof, mesin virtual, kontrak sengketa, dan perangkat lunak pihak penantang dapat mengandung kerentanan implementasi.

Apa itu serangan penundaan?

Serangan penundaan berupaya memperpanjang penyelesaian sengketa atau menghalangi finalisasi yang valid tanpa berhasil membuktikan state yang salah.

Apa itu sengketa berbatas waktu?

Sengketa berbatas waktu dirancang untuk mencapai penyelesaian dalam jangka maksimum yang dapat diprediksi, bahkan ketika banyak klaim berbahaya diajukan.

Apakah semua sistem fraud proof bersifat permissionless?

Tidak. Sebagian jaringan membatasi validator atau pihak penantang, sedangkan jaringan lain mengizinkan partisipasi publik dengan persyaratan teknis dan jaminan.

Apakah sistem fraud proof permissionless masih dapat memiliki administrator?

Ya. Guardian darurat, otoritas peningkatan, badan tata kelola, atau dewan keamanan mungkin tetap memiliki wewenang penting.

Apakah pengguna perlu menjalankan perangkat lunak pihak penantang?

Pengguna biasa biasanya mengandalkan validator independen, meskipun menjalankan perangkat lunak verifikasi dapat mengurangi ketergantungan pada peserta lain.

Apa yang perlu diperiksa sebelum menggunakan optimistic rollup?

Pengguna sebaiknya memeriksa apakah fraud proof aktif, siapa yang dapat mengajukan challenge, di mana data disimpan, berapa lama penarikan berlangsung, dan pihak mana yang memiliki wewenang darurat.

Kesimpulan

Fraud proof adalah mekanisme sengketa yang menunjukkan bahwa batch transaksi mata uang kripto, transisi state, output root, atau klaim penarikan dihitung secara keliru.

Fraud proof merupakan komponen keamanan utama optimistic rollup karena sistem ini sementara menerima hasil off-chain tanpa mewajibkan validity proof langsung.

Pihak penantang independen mereproduksi eksekusi dan menyengketakan klaim yang salah selama periode challenge yang ditentukan.

Game sengketa interaktif dapat mempersempit jutaan langkah komputasi menjadi satu instruksi yang diverifikasi langsung oleh blockchain penyelesaian.

Ketersediaan data sangat penting karena pihak penantang tidak dapat membuktikan kesalahan jika tidak dapat mengakses transaksi di balik komitmen state.

Jaminan finansial mencegah klaim palsu dan mengompensasi sebagian biaya untuk mempertahankan sistem.

Fraud proof permissionless mengurangi ketergantungan pada validator yang disetujui, tetapi tidak menghilangkan seluruh asumsi kepercayaan terkait tata kelola, peningkatan, sequencing, atau operasional.

Fraud proof berbeda dari validity proof karena fraud proof menolak hasil yang salah setelah challenge, bukan membuktikan setiap hasil benar sebelum diterima.

Sistem fault proof produksi terus berkembang pada 2026 melalui klien proof yang diperbarui, protokol sengketa berbatas waktu, dan partisipasi permissionless yang lebih luas.

Memahami fraud proof membantu pengguna kripto menilai keamanan rollup, penundaan penarikan, ketersediaan data, asumsi terkait pihak penantang, dan keterbatasan nyata penskalaan blockchain optimistis.