Status bukti penipuan di L2 Ethereum

1. Pengantar

1.1. Masa Depan Optimistic Rollup

Pada September 2024, Vitalik 强调 pentingnya meningkatkan standar Rollup dan menyatakan:

Saya sangat menghargai ini. Mulai tahun depan, saya hanya akan menyebutkan proyek L2 yang telah mencapai tahap 1 atau lebih di blog, pidato, dan acara publik lainnya, mungkin akan ada periode pengecualian singkat untuk beberapa proyek baru dan menarik.

Tidak peduli apakah saya berinvestasi atau apakah kamu adalah fren saya, harus mencapai tahap pertama, jika tidak, tidak akan dipertimbangkan.

Sistem "tahapan" Rollup adalah kerangka kerja untuk penilaian kasar tingkat keamanannya, dari Fase 0 hingga Fase 2. Di antara rollup arus utama hari ini, hanya Arbitrum dan Optimisme yang telah mencapai tahap 1, dan sebagian besar rollup optimis lainnya masih dalam tahap 0.

Dalam situasi ini, beberapa masalah muncul:

Mengapa belum ada proyek yang mencapai tahap 2 tertinggi sejak diluncurkan Optimistic Rollup selama tiga tahun?
Kapan kita bisa mengharapkan Optimistic Rollup mencapai Tahap 2?

Artikel ini bertujuan untuk menjawab pertanyaan-pertanyaan ini dengan menganalisis mekanisme bukti penipuan dan tantangan Optimistic Rollup, dan membahas bagaimana setiap proyek berusaha untuk mencapai Tahap 2. Selain itu, artikel ini juga akan melihat ke masa depan pengembangan Optimistic Rollup dan sistem bukti penipuan.

1.2. Perbandingan Optimistic Rollup dan ZK Rollup

Seperti yang kita ketahui, kecepatan Ethereum lambat dan Pencucian Uang tinggi. Para peneliti dan pengembang komunitas Ethereum telah berusaha keras untuk menyelesaikan masalah ini. Setelah menjelajahi solusi seperti Sharding dan plasma, komunitas akhirnya menetapkan Rollup sebagai pendekatan utama untuk meningkatkan skala. Oleh karena itu, Rollup seperti Arbitrum, Optimism, dan zkSync bermunculan. Menurut data L2Beat, saat ini sekitar 40 Rollup sedang berjalan, sementara beberapa solusi lain seperti Validium dan Optimium mengadopsi solusi alt-DA untuk mencapai skala yang lebih tinggi, dengan total sekitar 41. Selain itu, diperkirakan sekitar 80 Rollup baru akan diluncurkan.

Status saat ini L2 | Sumber:L2Beat）

Konsep inti dari Rollup adalah untuk mengeksekusi transaksi secara off-chain, hanya mengirimkan data transaksi dan status akar hasil ke jaringan Ethereum, sehingga memungkinkan skalabilitas. Pengguna dapat menyimpan dana ke dalam kontrak bridge khusus di jaringan Ethereum, mentransfer dana ke dalam Rollup, dan melakukan transaksi di dalam Rollup. Karena data transaksi akan diserahkan ke jaringan Ethereum, dan setelah dikonfirmasi tidak dapat diubah tanpa mengorbankan keamanan jaringan Ethereum, maka Rollup dianggap 'mewarisi keamanan jaringan Ethereum'.

Namun benarkah ini? Apa yang terjadi jika pengusul pemrosesan transaksi di dalam Rollup itu jahat? Pengusul jahat dapat memanipulasi saldo Alice, mentransfernya ke akun mereka sendiri, dan menariknya ke Ethereum, dengan efektif mencuri dana Alice.

Untuk mencegah situasi ini, tindakan keamanan tambahan diperlukan saat menarik dari Rollup ke Etherum. Dengan memberikan bukti kepada kontrak jembatan Etherum, transaksi penarikan harus diproses dengan benar dan disertakan dalam rantai L2 sebelum transaksi penarikan dapat diselesaikan.

Metode paling sederhana, juga digunakan oleh setiap Rollup, adalah membandingkan nilai hash transaksi penarikan dengan root status Rollup, untuk membuktikan bahwa transaksi penarikan tersebut sudah benar-benar terdapat dalam status Rollup. Ini memerlukan pengiriman transaksi penarikan dan root status ke kontrak jembatan Ethereum. Pengguna mengirimkan transaksi penarikan mereka, dan validator menghitung dan mengirimkan root status.

Namun, jika validator yang mengirimkan root state berbahaya dan mengirimkan root state yang salah, itu dapat membahayakan keamanan dana pengguna. Untuk risiko jatuh, dua mekanisme utama diusulkan, yang membuat rollup optimis berbeda dari rollup ZK.

**ZK Rollup **ZK Rollup tidak hanya meminta validator untuk mengirimkan root state, tetapi juga harus menyediakan bukti ZK untuk memverifikasi kebenaran perhitungan root state. Jika validator mengirimkan root state yang salah, bukti ZK tidak akan lolos verifikasi kontrak verifikasi L1, mencegah pengiriman root state jahat.
**Optimistic Rollup **Optimistic Rollup memungkinkan validator yang ditentukan untuk mengirimkan akar status tanpa jaminan tambahan, dengan asumsi bahwa pengiriman tersebut jujur. Namun, jika akar status yang dikirimkan tidak benar, siapa pun dapat mengajukan keraguan dan mencegah penggunaan akar status tersebut dalam proses penarikan. Pihak yang meragukan harus mengajukan bukti ke Ethereum untuk membuktikan bahwa akar status tersebut salah, yang disebut bukti penipuan (bukti penipuan).

Untuk memastikan penyelesaian yang aman terhadap serangan seperti serangan pemeriksaan L1, waktu penarikan untuk Optimistic Rollup biasanya akan ditunda selama sekitar satu minggu.

1.3. Mengapa perlu bukti penipuan?

Berbeda dengan ZK Rollup, validator pada Optimistic Rollup dapat mengirimkan root status yang salah dan mencoba memanipulasi transaksi penarikan. Bukti penipuan efektif mencegah hal ini dan memastikan keamanan dana di kontrak bridge.

Jika tidak ada mekanisme bukti penipuan yang kuat, Optimistic Rollup tidak dapat sepenuhnya mewarisi keamanan Ethereum. Misalnya, dalam sistem validator berlisensi Arbitrum saat ini, jika semua validator berkomplot, mereka mungkin mencuri semua dana dalam kontrak jembatan. Demikian pula, pada Rollup berbasis OP Stack seperti Base, karena Mainnet belum menerapkan mekanisme bukti kegagalan tanpa lisensi, satu validator jahat juga bisa mencuri dana.

Oleh karena itu, bukti penipuan memainkan peran kunci dalam keamanan Optimistic Rollup, dan setiap sistem yang tidak memiliki mekanisme bukti penipuan yang sempurna akan membahayakan aset pengguna.

Artikel ini akan mengevaluasi risiko yang dihadapi oleh berbagai rollup optimis dan memeriksa implementasi mekanisme bukti penipuan, serta kelebihan dan kekurangannya.

1.4. Menuju Tahap 2: "Menghapus Roda Bantu"

Sistem bukti penipuan memainkan peran kunci dalam membantu Optimistic Rollup mencapai proses 'Fase 2'. Kerangka fase yang diusulkan oleh Vitalik, saat ini dioperasikan oleh L2Beat, digunakan untuk mengevaluasi tingkat keamanan Rollup.

Dalam ekosistem ETH, kerangka tahap ini sering disebut sebagai belajar naik sepeda. Rollup Tahap 0 bergantung pada asumsi kepercayaan yang paling banyak, seperti tricycle dengan roda bantu, sedangkan Rollup Tahap 2 yang sepenuhnya mewarisi keamanan ETH disebut sebagai sepeda dua roda tanpa roda bantu.

Berikut adalah standar rinci dari tahap 0 hingga tahap 2:

Seperti yang disebutkan sebelumnya, penting untuk menerapkan mekanisme bukti penipuan dan tantangan yang sesuai untuk mencapai Tahap 1 atau Tahap 2 dari Optimistic Rollup. Dengan mempertimbangkan standar ini, sistem bukti penipuan yang memenuhi persyaratan Tahap 2 harus memiliki fitur berikut:

Sistem bekerja dengan baik, tidak memiliki cacat yang diketahui, dan memiliki karakteristik "1-of-N".
Ini adalah sistem tanpa lisensi, di mana siapa pun dapat mengajukan bukti.
Jika ada kerentanan dalam sistem bukti, harus dapat dibuktikan secara on-chain.

Di bagian kedua artikel ini, kami akan menjelajahi bagaimana berbagai protokol mencoba untuk menerapkan fungsi-fungsi ini.

2. bukti penipuan - 概念与误解

2.1. bukti penipuan是如何实施的？

bukti penipuan menyediakan bukti on-chain yang dapat diverifikasi bahwa akar status yang diajukan tidak benar, yang berarti bahwa fungsi transisi status tertentu di L2 tidak dilakukan dengan benar. Cara yang sederhana adalah dengan memulai dari akar status yang dikonfirmasi sebelumnya, melakukan pembuktian blok L2 untuk semua eksekusi, hingga akar status saat ini, untuk membuktikan ketidakbenaran akar status. Namun, metode ini mahal dan memakan waktu.

Oleh karena itu, ketika menghasilkan bukti penipuan yang valid, perlu dikurangi menjadi perubahan status yang tidak benar tertentu, dan kemudian bukti tersebut dihasilkan untuk bagian tersebut. Sebagian besar protokol bukti penipuan mengikuti metode ini.

bukti penipuan dan protokol yang dipertanyakan biasanya melibatkan langkah-langkah berikut:

validator (pengaju) secara rutin mengirimkan output (atau pernyataan) yang berisi root state L2 kepada ETH Network.
Jika validator (质疑者) tidak setuju dengan output tersebut, mereka akan mengajukan pertanyaan.
Penyaji dan pihak yang mempertanyakan mengidentifikasi bagian yang berbeda melalui proses yang disebut binary search atau dissecting, dan memperincinya hingga level instruksi atau level Blok (ZK Rollup).
Pihak yang meragukan akan mengajukan bukti penipuan pada on-chain untuk memperlihatkan bagian yang tidak benar. Biasanya protokol seperti Arbitrum dan Optimism akan melakukan instruksi yang mencurigakan pada on-chain untuk melakukan verifikasi.
Jika bukti penipuan diverifikasi, output yang tidak benar akan dihapus atau diganti. Berdasarkan protokol yang dipertanyakan, pengaju mungkin akan dihukum, sedangkan pihak yang mempertanyakan akan mendapatkan imbalan.

2.2. Kesalahpahaman Umum: bukti penipuan dan keraguan tidak akan Rollback rantai

Perlu diingat bahwa bahkan jika terjadi bukti penipuan dan keraguan, rantai tidak akan dirollback. Bukti penipuan memastikan bahwa "dana dalam kontrak jembatan tidak akan diekstraksi dengan jahat", dan tidak melibatkan rollback dari transisi status yang tidak benar.

Alasan utama untuk tidak melakukan Rollback adalah tidak perlu. Ketika terjadi transisi status yang tidak benar di Rollup, masalah inti adalah bahwa pelaku jahat dapat mencuri dana pengguna dari bridge. Untuk mencegah hal ini, cukup pastikan bahwa akar status yang diserahkan ke L1 benar. Proses ini tidak ada hubungannya dengan Rollback rantai, asalkan mencegah konfirmasi akar status jahat, bukti penipuan, dan mekanisme pertanyaan sudah cukup.

Selain itu, jika pengusul keadaan root dan pengurut pembuat blok L2 adalah entitas yang berbeda, maka mekanisme Rollback tidak perlu dilakukan.

Oleh karena itu, bahkan jika keraguan berhasil diselesaikan, rantai L2 tidak akan di-Rollback; hanya status root (output atau statement) yang diserahkan ke L1 yang akan dihapus atau digantikan. Jika bukti penipuan dan mekanisme keraguan berfungsi normal, keamanan dana yang di-bridge oleh pengguna dapat terjamin.

2.3. Studi Kasus: Tantangan Kroma pada April 2024

Melalui contoh kasus pertanyaan yang sebenarnya, dapat dilihat bahwa seluruh rangkaian Rollup tidak akan di-Rollback, hanya akar output yang akan diganti atau dihapus. Hingga saat ini, satu-satunya kasus pertanyaan yang berhasil diketahui terjadi pada Kroma pada bulan April 2024, yang merupakan Rollup campuran berbasis OP Stack menggunakan bukti kegagalan ZK di Mainnet.

Kroma adalah OP Stack berbasis Rollup, dengan sistem validator tanpa izin dan bukti kesalahan ZK sendiri. Pada 1 April 2024, ada masalah dengan sumber L1 sorter Kroma yang mengakibatkan Blok yang dihasilkan tidak benar. Selain itu, validator yang melihat situasi tersebut mengirimkan akar output yang salah. Tak lama setelah pengiriman akar output, 12 pihak yang meragukan output tersebut.

Salah satu penantang berhasil memanggil fungsi proveFault, dan menghapus output yang salah.

Penyelidik berhasil menjalankan fungsi proveFault | Sumber:etherscan

Ini adalah kasus pertanyaan pertama yang berhasil dalam sejarah ETH Rollup Mainnet. Ini juga merupakan kasus pertama yang berhasil memverifikasi dan mempertanyakan bukti kegagalan di lingkungan Mainnet sejak diluncurkannya Optimistic Rollup (Arbitrum) pada bulan Mei 2021 sekitar tiga tahun yang lalu. Untuk gambaran detail tentang pertanyaan ini, silakan lihat artikel yang ditulis oleh Kroma. Dalam kasus ini, jaringan Kroma tidak melakukan Rollback, hanya menghapus root output yang tidak benar.

Pernyataan Tanggung Jawab: Bukti penipuan atau bukti kerusakan?

bukti penipuan juga dikenal sebagai bukti kegagalan. Terutama dalam jaringan Optimism dan OP Stack, istilah yang digunakan adalah 'bukti kegagalan', sementara dalam proyek-proyek seperti Arbitrum, Cartesi, L2Beat, istilah yang digunakan adalah 'bukti penipuan'.

Dengan mempertimbangkan kasus keraguan Kroma di atas, dapat disimpulkan bahwa keraguan seringkali berasal dari 'kesalahan', bukan dari upaya jahat untuk memanipulasi penarikan. Dalam kasus tersebut, alasan utamanya adalah keanehan pada klien L1 yang diamati oleh validator Kroma. Dengan kata lain, keraguan kadang-kadang hanya disebabkan oleh kesalahan validator atau pemasangan patch yang tidak tepat. Dalam situasi seperti ini, istilah 'bukti kegagalan' mungkin lebih sesuai.

Namun, istilah yang lebih mencerminkan tujuannya adalah "bukti penipuan". Semua mekanisme yang diperkenalkan sejauh ini, dan mekanisme yang akan diperkenalkan di masa depan, bertujuan untuk memverifikasi tindakan penipuan yang mencoba mencuri dana di dalam jembatan melalui output jahat.

Yang penting, meskipun tujuannya adalah mencegah penipuan, namun keraguan sebenarnya dapat timbul akibat kesalahan. Dalam artikel ini, saya akan menggunakan istilah "bukti penipuan", yang lebih umum digunakan dalam ekosistem.

3. Serangan Hacker! - Memanfaatkan mekanisme bukti penipuan

3.1. Desain Ekonomi Konflik protokol

Setiap Optimistic Rollup menerapkan mekanisme bukti penipuan dan pertanyaan mereka sendiri untuk melindungi dana pengguna. Tujuan bersama dari mekanisme ini adalah “memastikan keamanan protokol selama setidaknya satu partisipan jujur ada”. Bukti penipuan adalah bukti bahwa fungsi peralihan status yang telah dijadwalkan telah dieksekusi dengan benar, dan melalui proses verifikasi, akhirnya akan menghasilkan kemenangan bagi partisipan yang jujur.

Namun demikian, hal ini tidak selalu terjadi. Bahkan, meskipun ada partisipan yang jujur, bisa jadi protokol berada dalam situasi berbahaya. Misalnya, karena bukti penipuan sangat kompleks, dapat terjadi kerentanan yang tidak terduga, dan partisipan jahat mungkin mendapatkan keuntungan ekonomi yang lebih besar daripada partisipan jujur karena insentif tidak sejalan, menyebabkan penarikan dana yang signifikan atau pencurian dana.

Oleh karena itu, merancang bukti penipuan dan mekanisme pertanyaan adalah tugas yang sangat sulit. Terutama, untuk menjadi Rollup tahap 2, mekanisme pertanyaan harus sempurna, dan harus memiliki strategi untuk menghadapi berbagai Attack Vector dan kerentanan.

Dengan kata lain, setiap bukti penipuan dan mekanisme pertanyaan perlu mempertimbangkan bagaimana menghadapi Attack Vector. Jika tidak memahami setiap Attack Vector, maka tidak akan memahami mengapa protokol harus dirancang dengan cara ini.

Oleh karena itu, dalam bagian ini, kita akan pertama-tama mempelajari Attack Vector berikut dan mengeksplorasi bagaimana setiap protokol menangani serangan-serangan ini:

karena serangan yang dihasilkan oleh kerentanan dalam game yang kontroversial;
Serangan latensi, memperpanjang waktu penarikan lebih dari 7 hari;
Serangan Sybil yang menghabiskan dana dan sumber daya peserta jujur.
Serangan yang dipicu oleh pemeriksa L1 validator;
Melakukan serangan yang memanfaatkan kerentanan dalam Virtual Machinebukti penipuan.

Perhatian: Semua Attack Vector yang dibahas di atas adalah yang telah diketahui secara publik dan tidak akan mempengaruhi keamanan Mainnet mana pun.

Berikut adalah analisis dari setiap protokol dan karakteristik masing-masing dalam bab berikutnya:

3.2. Vektor Serangan #1: Memanfaatkan Permainan Sengketa Ekonomi

Sebagian besar Optimistic Rollup yang menerapkan mekanisme bukti penipuan memerlukan pembagian dua untuk menemukan titik pertama yang tidak sesuai. Protokol harus memberikan insentif untuk mendorong peserta agar bertindak jujur, ini sangat penting.

Salah satu cara termudah untuk mencapai tujuan ini adalah dengan meminta peserta untuk menggadaikan sejumlah dana saat mengambil tindakan (Margin), jika mereka dianggap melakukan tindakan jahat, maka akan di-slashMargin.

Dalam perspektif teori permainan, protokol harus memastikan bahwa biaya yang dikeluarkan oleh penyerang yang jahat untuk melakukan serangan lebih besar dari biaya yang dikeluarkan oleh peserta yang jujur untuk melakukan pertahanan. Namun, hal ini sangat sulit untuk dicapai.

Alasan kunci di sini adalah, dalam lingkungan permainan, tidak mungkin untuk mengetahui sebelumnya siapa yang merupakan peserta jahat sebelum keraguan diselesaikan. Dengan kata lain, pihak yang mengajukan klaim keluaran mungkin jahat, dan pihak yang meragukan keluaran juga mungkin jahat. Oleh karena itu, protokol harus dirancang dengan asumsi bahwa salah satu pihak mungkin jahat. Selain itu, karena mungkin ada berbagai Vektor Serangan, merancang protokol menjadi sangat kompleks.

Karena setiap protokol menggunakan mekanisme yang berbeda, maka perlu didefinisikan Attack Vector dan model insentif penyerang yang sesuai dengan setiap metode. Selain itu, perlu dirancang model keamanan ekonomi untuk memastikan keamanan tetap terjaga bahkan ketika model-model ini digabungkan.

Topik ini masih dalam pembahasan yang berkelanjutan. Di bagian ini, kami akan menganalisis Attack Vector yang mungkin terjadi secara umum, serta insentif peserta dalam skenario tersebut. Selain itu, kami akan membahas bagaimana setiap protokol mengatasi serangan ini dan sejauh mana mereka membatasi insentif semacam itu.

3.2.1. Serangan Vektor #1-1：latensi攻击

Serangan latensi merujuk pada entitas jahat yang tidak bermaksud mencuri dana Rollup, tetapi menghalangi atau menunda konfirmasi yang keluar di L1. Serangan ini dapat terjadi dalam sebagian besar Optimistic Rollup saat ini, menambahkan latensi tambahan pada penarikan, sehingga pengguna harus menunggu lebih dari seminggu untuk menarik dana dari L1.

Ini sedikit berbeda dengan serangan yang disebabkan oleh validasi L1, yang akan dibahas nanti. Validasi mencegah peserta yang jujur untuk melakukan tindakan apa pun di atas kontrak pintar ETH, memungkinkan akar status yang jahat dikonfirmasi akhir. Di sisi lain, serangan latensi bahkan dapat mengkonfirmasi akar status yang jahat meskipun peserta yang jujur aktif terlibat dalam proses tersebut. Dalam hal ini, penarikan dana pengguna mungkin tidak hanya tertunda, tetapi juga menyebabkan akar status yang jahat dikonfirmasi akhir jika dana penyerang lebih besar dari pembela, sehingga mengakibatkan pencurian dana pengguna.

Salah satu cara paling sederhana untuk mencegah serangan latensi adalah dengan meminta peserta dalam sistem untuk mengamankan sejumlah dana atau Margin, yang dapat digunakan untuk memotongnya jika mereka dianggap menyebabkan latensi.

Namun, ada beberapa faktor yang perlu dipertimbangkan. Jika penyerang tidak takut dikenai slashing dan masih mencoba melakukan serangan latensi, apa yang harus dilakukan?

Attack Vector ini sangat rumit. Itulah mengapa sistem bukti penipuan Arbitrum saat ini berjalan dalam struktur izin.

Mekanisme bukti penipuan yang digunakan dalam Arbitrum One dan Arbitrum Classic mengadopsi model fork. Daripada hanya memungkinkan peserta mempertanyakan pernyataan yang salah, lebih baik setiap peserta mengajukan pernyataan yang mereka anggap benar dan melampirkan sejumlah dana sebagai "fork" dari rantai tersebut. Pernyataan juga dapat dianggap sebagai titik pemeriksaan pada status rantai.

Model cabang Arbitrum

Di Arbitrum Classic, peserta akan mengajukan klaim dan cabang rantai yang mereka anggap benar, dengan bertanya secara bertahap menghapus cabang rantai yang tidak benar, dan akhirnya mengkonfirmasi klaim yang benar.

Namun, satu kali keraguan tidak dapat menentukan siapa yang benar. Dua peserta jahat dapat menggunakan binary search dengan cara yang salah, mendefinisikan titik-titik yang tidak relevan sebagai titik tidak konsisten, sehingga mengesampingkan pernyataan yang benar. Oleh karena itu, Arbitrum memastikan keraguan terus berlanjut sampai tidak ada peserta yang mempertaruhkan uang pada pernyataan tertentu, memastikan bahwa jika setidaknya satu peserta jujur, keraguan dapat berhasil diselesaikan.

Ini dapat disalahgunakan untuk melakukan serangan latensi. Misalkan ada peserta jujur dan N-1 penyerang jahat yang mengiklankan dengan benar dan menempatkan dana jaminan, sedangkan satu penyerang menempatkan dana jaminan pada iklan yang salah. Jika penyerang dapat selalu mengirimkan transaksi mereka sebelum peserta jujur, mereka dapat memulai pertanyaan pertama. Dalam kasus terburuk, jika mereka salah membagi, membagi bagian yang disetujui mereka alih-alih bagian yang tidak disetujui, mereka dapat mengirimkan bukti penipuan pada bagian yang salah. Tentu saja, ini akan lulus, menyebabkan kegagalan pada pihak yang menempatkan jaminan di iklan yang benar.

Karena setiap pertanyaan mungkin memerlukan waktu hingga 7 hari, penyerang dapat memperpanjang waktu latensi protokol menjadi 7 * (N-1) hari.

Serangan latensi Arbitrum Classic | Sumber: L2Beat Medium

Masalah dari mekanisme ini adalah bahwa biaya serangan latensi berbanding lurus dengan waktu latensi protokol. Jika penyerang menemukan bahwa serangan ini menguntungkan, mereka akan mencoba memperpanjang waktu latensi protokol sepanjang mungkin, dan total waktu latensi akan sebanding dengan total dana yang dimiliki penyerang, yang dapat menyebabkan waktu latensi penarikan yang sangat lama bagi pengguna.

Secara keseluruhan, sebuah protokol bukti penipuan yang mampu efektif melindungi dari serangan latensi, harus dirancang sedemikian rupa sehingga waktu latensi maksimum dibatasi dalam rentang tertentu, atau mekanisme pelaksanaan latensi mengikuti mekanisme naik eksponensial dari waktu ke waktu, sehingga biaya pelaksanaan serangan lebih besar dari insentif serangan.

3.2.2. Vektor Serangan #1-2: Serangan Sybil (Serangan Eksaustif Sumber Daya)

Attack Vector lainnya adalah serangan Sybil (serangan kehabisan sumber daya, serangan Whale). Ketika dana atau sumber daya komputasi penyerang melebihi yang dipertahankan, situasi ini akan terjadi. Penyerang dapat terus-menerus mengirimkan output root yang salah atau membuat pertanyaan yang tidak bermakna, menghabiskan dana atau sumber daya komputasi yang dipertahankan. Pada suatu saat, pihak yang dipertahankan akan kehabisan dana atau sumber daya komputasi yang tidak terpakai, sehingga tidak dapat melakukan pertahanan, sementara penyerang akhirnya akan memverifikasi output root yang salah dan mencuri dana.

Biasanya, Attack Vector di atas dapat terjadi dalam dua cara berikut di sistem tanpa izin:

Terus-menerus mengirimkan output yang salah. Anggaplah bahwa dana penyerang Bob melebihi total dana peserta yang jujur (pembela) Alice, Charlie, dan David. Dalam kasus ini, Bob terus-menerus mengirimkan output root yang salah. Peserta jujur Alice, Charlie, dan David akan menghadapinya dengan membayar biaya gas dan deposit, dan pada suatu ambang batas, dana peserta jujur akan habis lebih dulu daripada Bob. Pada saat ini, Bob mengirimkan output salah lainnya, karena tidak ada lagi peserta jujur dengan sisa dana di jaringan, output tersebut akhirnya akan ditetapkan tanpa dipertanyakan. Dengan cara ini, Bob dapat mencuri dana dari rollup optimistik.
Mengirimkan banyak pertanyaan kejujuran. Sebaliknya, peserta yang jahat dapat menyerang peserta yang jujur dengan mengirimkan banyak pertanyaan. Serangan akan terus berlanjut hingga peserta jujur kehabisan dana untuk biaya gas dan deposit, kemudian penyerang jahat akan mengirimkan output yang salah dan mencuri dana pengguna dari jembatan.

Untuk mencegah serangan semacam ini, penting untuk merancang keunggulan pertahanan terhadap penyerang dengan bijaksana. Dalam semua situasi, pihak yang bertahan harus memiliki keunggulan yang cukup terhadap penyerang. Salah satu cara untuk mencapai hal ini adalah dengan merancang jaminan dengan cermat; karena serangan Sybil terkait dengan total dana yang tersedia untuk setiap peserta, jika jaminan diatur dengan benar, seharusnya dapat dipastikan bahwa 'sistem aman jika total dana penyerang tidak melebihi N kali total dana pihak yang bertahan'.

Metode lain yang diketahui untuk mencegah serangan Sybil adalah melaksanakan protokol yang tahan terhadap Sybil. Pada bagian berikutnya, kami akan memperkenalkan lebih lanjut Cartesi Dave.

Mari kita lihat bagaimana setiap protokol menghadapi latensi dan serangan Sybil melalui desain mereka masing-masing.

3.3. Solusi #1: Permainan sengketa yang ekonomis sehat

1) Arbitrum BoLD

BoLD memperkenalkan tiga elemen berikut pada model cabang di Arbitrum Classic untuk mencegah serangan latensi:

Semua pertanyaan terhadap mekanisme Penantang Semua. Di BoLD, pertanyaan tidak lagi dilakukan secara satu lawan satu, tetapi menggunakan sistem semua terhadap semua yang bersama-sama mengamankan dana di cabang yang mereka sepakati. Ini mencegah latensiAttack Vector yang dihasilkan sebelumnya dari pertanyaan satu lawan satu, dan memastikan bahwa tidak ada pertanyaan independen yang dapat terjadi pada sengketa yang sama.
Bukti Komputasi Status yang Benar untuk Mencegah Pembagian Ganda Berusila (Komitmen Sejarah). Masalahnya di Arbitrum Classic adalah bahwa peserta jahat dapat membagi ganda dengan cara yang salah, sengaja menyebabkan laten, dan menandai bagian yang tidak dipersengketakan sebagai titik persengketaan. Oleh karena itu, BoLD meminta bukti yang diajukan bersama dengan akar status, memverifikasi bahwa akar status dihitung dengan benar selama proses pembagian ganda, memastikan bahwa tidak ada pembagian ganda yang jahat terjadi.

Di BoLD, peserta harus mengirimkan bukti dan akar status selama proses dua fase. Bukti ini memverifikasi apakah akar status saat ini dihitung dengan benar berdasarkan akar status sebelumnya yang dikirim. Jika peserta jahat mencoba mengirimkan akar acak yang tidak terkait dengan akar status sebelumnya selama proses dua fase, verifikasi bukti akan gagal, menyebabkan kegagalan transaksi dua fase. Ini efektif memastikan bahwa setiap klaim hanya dapat mengalami satu jenis dua fase.

Oleh karena itu, jika penyerang ingin melakukan pembagian ganda pada pernyataan jujur dalam BoLD, mereka harus mengirimkan beberapa pernyataan.

Namun, menghasilkan bukti ini memerlukan validator menggunakan sumber daya komputasi yang cukup besar. Secara internal, menghasilkan bukti ini memerlukan hash untuk menghasilkan semua status dalam pembagian dua, yang biasanya diperkirakan memerlukan sekitar 270 hash (sekitar 1.18 x 10²¹) dalam Arbitrum. Untuk mengatasi masalah ini, BoLD membagi pertanyaan menjadi tiga tingkat, mengurangi jumlah hash yang perlu dihitung menjadi 226 (sekitar 6.71 x 10⁷).

(Gambar ini mengasumsikan total ada 269 perintah, data aktual mungkin berbeda)

Membatasi waktu stake melalui mekanisme jam catur.

Dalam Arbitrum Classic sebelumnya, durasi sengketa tidak terbatas, memungkinkan peserta jahat untuk berlatensi protokol tanpa batas selama memiliki dana yang cukup. BoLD memperkenalkan mekanisme jam catur yang efektif membatasi durasi sengketa.

Asumsikan ada dua peserta yang mengajukan pernyataan yang berbeda. Setiap peserta memiliki jam (jam catur) dengan waktu 6,4 hari. Ketika giliran peserta untuk mengajukan pembuktian atau bukti, jam akan mulai menghitung mundur dan berhenti setelah peserta menyelesaikan tugas.

Karena setiap peserta memiliki waktu selama 6,4 hari, maka waktu maksimum yang bisa ditunda oleh satu peserta adalah 6,4 hari. Oleh karena itu, dalam BoLD, waktu tahanan maksimum untuk pertanyaan adalah 12,8 hari (dalam beberapa kasus, ketika komite keamanan terlibat, ditambahkan 2 hari tambahan).

Dengan mekanisme ini, Arbitrum BoLD secara efektif membatasi latensi yang disebabkan oleh keraguan. Durasi maksimum keraguan adalah dua minggu, dan latensi tambahan maksimum yang mungkin dialami pengguna adalah sekitar satu minggu.

Namun, ini dapat dimanfaatkan untuk melakukan serangan latensi. Penyerta jahat dapat membuat keraguan dan berkomplot dengan validator L1, memeriksa validator jujur di Arbitrum, sehingga menunda penarikan pengguna Arbitrum selama seminggu. Dalam kasus ini, pengguna yang meminta penarikan selama periode ini mungkin menghadapi biaya kesempatan karena dana mereka terkunci. Meskipun ini bukan serangan di mana penyerang secara langsung menguntungkan dari dana, namun karena menimbulkan biaya kesempatan bagi pengguna, hal ini tetap harus dihindari. Arbitrum BoLD sedang menangani masalah ini dengan mengatur jaminan yang diperlukan untuk membuat keraguan menjadi cukup tinggi, untuk mencegah serangan semacam ini.

Arbitrum menghitung jumlah ini dalam dokumen ekonomi yang dicetak tebal di sini. Alasan utama protokol latensi adalah pemeriksaan validator L1. Dalam kasus serangan latensi, skenario akan berkembang seperti berikut: 01928374656574839201

Penyerang mengirimkan pernyataan N' yang tidak sesuai dengan pernyataan N yang telah ada di Arbitrum sebelumnya.
Pembela mencoba mengirim transaksi biner, tetapi karena validator L1 sedang memeriksa transaksi keraguan pembela, operasi ini gagal.
Karena asumsi pemeriksaan BoLD tidak dapat berlangsung lebih dari 7 hari, ini dapat menyebabkan konfirmasi akhir dari klaim N dengan latensi maksimal satu minggu.

Keuntungan penyerang berasal dari biaya kesempatan yang ditanggung oleh pengguna yang mempertanyakan permintaan penarikan keluar. Dalam skenario terburuk, semua dana dalam Arbitrum ditarik keluar dalam satu permintaan penarikan keluar, dan biaya kesempatan yang ditanggung oleh pengguna dapat dihitung sebagai berikut, dengan asumsi TVL Arbitrum One adalah 15,4 miliar USD dengan APY 5%:

Biaya kesempatan=15,400,000 x (1.051/52 - 1) = $14,722,400

Karena biaya kesempatan yang tinggi yang mungkin timbul akibat pengajuan pernyataan yang tidak benar, pengaju pernyataan di BoLD diminta untuk mengajukan jaminan sebesar jumlah yang sama. Saat ini, jaminan yang diperlukan untuk pengajuan pernyataan di BoLD adalah 3600 ETH, setara dengan sekitar 9,4 juta dolar.

Ini dilakukan untuk mencegah penyerang menyebabkan kerugian besar pada sistem melalui latensi. Karena penyerang akan kehilangan depositnya dalam pertanyaan, mereka dapat menyebabkan biaya kesempatan hingga $1470 juta, tetapi akan kehilangan sekitar $940 juta. Oleh karena itu, BoLD menekan serangan latensi dengan meminta deposit yang setara dengan biaya kesempatan dalam skenario terburuk.

Namun, jaminan margin sebesar 3600 ETH tidak ditetapkan hanya karena serangan latensi. Untuk melindungi dari serangan Sybil, Arbitrum BoLD dapat memastikan sistem tetap aman sebelum total dana penyerang mencapai 6,5 kali total dana pembela, itulah dasar penetapan jaminan margin sebesar 3600 ETH.

Dari sudut pandang serangan Sybil, skenario serangan berikut mungkin terjadi di Arbitrum BoLD. Sistem pertanyaan BoLD terdiri dari tiga tingkat, di mana pengguna harus mengunci dana untuk mengajukan pernyataan yang mereka anggap benar.

Misalkan peserta jujur Alice mengirimkan klaim yang valid dengan jumlah X ETH. Peserta jahat Bob yang memiliki 3600 ETH dapat membuat beberapa klaim jahat. Pada saat ini, Alice perlu mengunci Y ETH pada setiap klaim Bob di lapisan rendah.

Dalam model cabang Arbitrum, mengunci dana berarti setuju pada status rantai dari genesis hingga deklarasi. Fitur ini memungkinkan peserta untuk memindahkan dana yang mereka gadai dari deklarasi A ke deklarasi anak A' dan A''. Oleh karena itu, Alice memindahkan X ETH yang ia pertama kali gadai ke lapisan yang lebih rendah dan mengunci Y ETH untuk setiap deklarasi jahat Bob.

Jika Bob memiliki dana yang jauh lebih banyak dari Alice, apa yang akan terjadi? Bob dapat membuat klaim jahat tanpa henti sampai dana Alice habis dan tidak dapat terus terkunci. Pada saat ini, Alice tidak akan bisa melanjutkan perpecahan, sehingga memungkinkan Bob mengkonfirmasi klaim yang salah.

Pada akhirnya, masalah ini dapat disimpulkan bahwa pertahanan harus lebih unggul daripada serangan dalam permainan.

Arbitrum mengacu pada indikator ini sebagai rasio sumber daya. Ini menunjukkan seberapa unggulnya peserta yang jujur dibandingkan dengan peserta yang jahat. Rasio ini diwakili oleh rasio biaya gas (G) dan jumlah jaminan (S) yang harus dibayarkan oleh setiap peserta, seperti yang ditunjukkan di bawah ini:

Sistem pertanyaan BoLD terdiri dari tiga tingkat, dengan mempertahankan rasio sumber daya ini di setiap tingkat, memastikan bahwa pembela selalu memiliki keunggulan N kali lipat dibandingkan penyerang dalam seluruh sistem. Arbitrum menghitung jumlah margin atas yang diperlukan untuk tingkat atas berdasarkan rasio sumber daya ini dan menggambarkannya dalam grafik.

(Biaya Gadai Kontroversial Lapisan Atas dan Rasio Sumber Daya Arbitrum BoLD | Sumber:Desmos）

Berdasarkan grafik tersebut, ketika rasio sumber daya mencapai 100 kali, jumlah deposit yang dibutuhkan oleh lapisan atas melebihi 1 juta ETH (lebih dari 4 triliun dolar). Meskipun rasio sumber daya yang lebih tinggi membuat sistem lebih aman dalam mencegah serangan Sybil, namun jumlah deposit menjadi sangat tinggi, sehingga hampir tidak ada orang yang dapat ikut serta dalam sistem ini, sehingga membuatnya tidak berbeda dengan sistem terpusat yang hanya memiliki satu validator untuk mengajukan klaim.

Oleh karena itu, dalam BoLD, rasio aset ditetapkan sebagai 6,5 kali, membuat jaminan tingkat atas menjadi 3600 ETH, jaminan tingkat satu dan dua masing-masing ditetapkan sebagai 555 ETH dan 79 ETH.

Secara singkat, BoLD memastikan bahwa pembela memiliki keunggulan 6,5 kali lipat dari penyerang dengan menghitung rasio sumber daya dan menetapkan jumlah jaminan untuk mencegah serangan Sybil.

2) Cartesi Dave

Dave dari Cartesi pertama kali mengusulkan ini pada bulan Desember 2022 dalam sebuah makalah yang berjudul "Non-Permissioned Audit Championship", lebih awal dari White Paper pertama BoLD. Ini bertujuan untuk mempertahankan keunggulan sumber daya komputasi dan dana peserta jujur daripada penyerang. Struktur Dave mirip dengan BoLD, memiliki dua fitur kunci:

Menghitung bukti keadaan yang benar (janji masa lalu) untuk mencegah pemecahan dua yang jahat.

Sama seperti BoLD, Dave meminta peserta untuk menghasilkan bukti selama proses pembagian untuk menunjukkan bahwa mereka melakukan perhitungan dengan benar, sehingga mencegah pembagian yang bersifat jahat. Oleh karena itu, sistem peradilan Dave juga terbagi menjadi beberapa tingkat untuk menghemat sumber daya validator.

Dalam struktur turnamen, digunakan mekanisme pertanyaan satu lawan satu.

Ketidakpercayaan Dave tidak dilakukan satu kali, tetapi dilakukan dalam bentuk turnamen seperti yang ditunjukkan dalam gambar di bawah ini.

Grafik di atas menunjukkan bagaimana keraguan dilakukan ketika penyerang jahat mengajukan tujuh pernyataan yang salah terhadap jaringan. Karena sifat komitmen sejarah, peserta jujur yang mendukung pernyataan yang benar (ditunjukkan dengan warna hijau) berkumpul bersama membentuk tim. Di Dave, mereka diatur dalam bentuk turnamen dan disusun secara visual, di mana setiap peserta melakukan keraguan satu lawan satu. Keraguan pada tahap yang sama dilakukan secara paralel, dan setelah seminggu, setelah keraguan selesai, pemenangnya akan masuk ke tahap berikutnya. Dalam grafik, tim peserta jujur harus melewati tiga putaran keraguan untuk memenangkan turnamen.

Fitur ini sangat efektif dalam mencegah serangan Sybil. Pertama, penyerang harus membuat banyak pernyataan untuk melakukan serangan Sybil, setiap pernyataan akan menghabiskan sumber daya komputasi dan dana yang signifikan bagi penyerang.

Bukti keberhasilan Cartesi adalah bahwa dalam semua situasi, pembela selalu memiliki keunggulan eksponensial terhadap penyerang. Dengan kata lain, Dave memastikan bahwa ia dapat mempertahankan serangan Sybil menggunakan sumber daya logaritma jumlah penyerang. Ini membuat melancarkan serangan Sybil pada Dave menjadi sangat sulit, sehingga jumlah jaminan Dave ditetapkan pada 1 ETH, jauh lebih rendah dari jumlah dalam BoLD.

Namun, Dave rentan terhadap serangan latensi. Setiap tahap turnamen menghabiskan satu unit waktu keraguan (satu minggu), sehingga semakin banyak pernyataan jahat, maka semakin lama protokol latensi. Waktu yang diperlukan Dave untuk sepenuhnya memecahkan keraguan dapat dihitung dengan rumus berikut:

Td = 7 x log2(1 + NA)(days)

Di mana NAN_ANA mewakili jumlah pernyataan jahat yang diberikan. Namun, keraguan Dave dapat terdiri dari beberapa tingkat untuk efektif menghasilkan komitmen sejarah. Di sini, peserta jahat dapat menghasilkan NAN_ANA pernyataan jahat pada setiap tingkat keraguan, yang akan meningkatkan total waktu latensi seperti yang ditunjukkan di bawah ini:

Td = 7 x [log2(1 + NA)]L(天数)

LLL mengindikasikan jumlah level dalam setiap pertanyaan. Jika seperti yang ditunjukkan dalam gambar di atas, ada tujuh pernyataan jahat dan L=2, maka menyelesaikan pertanyaan sepenuhnya mungkin memakan waktu hingga 9 minggu, dan pengguna akan mengalami keterlambatan penarikan selama 2 bulan. Jika jumlah level atau jumlah pernyataan jahat meningkat, latensi dapat diperpanjang menjadi beberapa bulan.

Cartesi bertujuan untuk menggunakan Zero-Knowledge Proof (ZK) untuk mengatasi masalah ini, pembahasan rinci akan dilakukan dalam bagian 4 'Perbaikan yang Layak'.

3）证明乐观故障（Optimism Fault Proof, OPFP)

OPFP adalah protokol non-permintaan izin yang dipertanyakan, saat ini digunakan dalam aplikasi OP Mainnet, dengan fitur-fitur berikut:

Semua mekanisme pertanyaan serentak untuk semua pohon permainan

OPFP memungkinkan siapa saja untuk mengirimkan output (klaim akar) kapan saja. Validator yang tidak setuju dengan output yang diserahkan dapat mempertanyakan melalui proses bipartit.

Arsitektur Pohon Permainan OPFP dan Proses Pembagian Dua | Sumber: Dokumen Optimism

Proses pembagian dilakukan secara bersamaan pada pohon permainan yang ditunjukkan pada gambar di atas. Daun pohon mewakili status L2, setiap node dalam pohon sesuai dengan satu status L2, dan daun paling kanan mewakili status L2 terbaru. Misalnya, menyampaikan pernyataan di Node 1 sama dengan menyampaikan status di Node 31.

Struktur ini memungkinkan representasi biner. Misalnya, jika validator tidak setuju dengan deklarasi root (Node 1), mereka akan mengirimkan deklarasi pada Node 2, Node 2 sesuai dengan Node 23 dalam pohon karena itu adalah titik tengah antara Node 16 dan Node 31. Pengirim Node 1 kemudian akan memeriksa status L2 Node 23, jika setuju, maka Node 6 (Node 27) akan dikirimkan; jika tidak setuju, maka Node 4 (Node 19) akan dikirimkan, dan proses ini akan berlanjut sampai menemukan percabangan.

Meskipun ada beberapa arah biner dalam permainan, mereka dapat dilakukan secara bersamaan dan siapa pun dapat ikut serta dalam proses biner, bukan hanya pengirim output.

Arsitektur lengkap Pohon Permainan OPFP | Sumber: Optimism File

Pohon permainan yang digunakan dalam OPFP adalah struktur bertingkat, pohon tingkat atas mengolah pemilihan biner tingkat Blok, sedangkan anak pohon tingkat bawah mengolah pemilihan biner tingkat instruksi.

Berbeda dengan BoLD atau Dave, OPFP tidak menerapkan pembagian yang benar secara paksa melalui janji-janji historis, karena biaya off-chain/on-chain yang tinggi untuk menghasilkan dan mengirimkan janji-janji semacam itu.

Game sengketa yang dapat disesuaikan berdasarkan modular Saat ini, OP Mainnet hanya meluncurkan dua jenis permainan perselisihan (izin/tanpa izin). Optimism bertujuan untuk akhirnya memperkenalkan berbagai jenis permainan perselisihan dan telah mencapai antarmuka minimum yang mendukung tujuan ini. Dengan mengikuti nama fungsi dan parameter yang ditentukan, Anda dapat membuat permainan perselisihan kustom.
Batasi waktu pertanyaan dengan jam catur

Dalam OPFP, ketika ada keraguan, pengaju dan penggugat akan diberikan jam, yang dialokasikan untuk waktu bertaruh. Setiap kali pernyataan diajukan, jam akan mulai menghitung waktu lawan. Optimisme menyebutnya sebagai "mewarisi jam kakek".

Yang menarik adalah setiap peserta diberikan waktu 3,5 hari bukan 7 hari, yang berarti jika tidak ada yang mempertanyakan output, output tersebut akan diputuskan dalam waktu 3,5 hari.

Namun, ini tidak memungkinkan untuk penarikan segera. Setelah output akhir ditentukan, OPFP memiliki periode penjagaan selama 3,5 hari di mana komite keamanan dapat campur tangan dan membuat output yang salah tidak valid jika diperlukan.

Proses penarikan pengguna di 'Jalur Bahagia' | Sumber: OP Labs Blog

Dengan mekanisme ini, OPFP dan rollups optimis lainnya, memastikan pengguna dapat menarik dana setidaknya 7 hari setelah mengirimkan. Namun, jika ada keraguan, pengguna mungkin perlu lebih dari 7 hari untuk menarik dana melalui output tersebut. Model waktu catur OPFP membatasi waktu yang dapat dihabiskan setiap peserta dalam proses pembagian dua, tetapi tidak membatasi secara ketat total waktu sebelum keraguan terselesaikan.

Ini mengarah pada sebuah pertanyaan: Jika ada keraguan atas OPFP, apakah penarikan dana pengguna mungkin mengalami keterlambatan selama lebih dari seminggu, mirip dengan situasi BoLD? Jawabannya adalah "ya". Berbeda dengan BoLD atau Dave, Optimism memberikan opsi bagi pengguna untuk menghadapi situasi keraguan ini, yang didasarkan pada karakteristik protokol yang unik.

OPFP beroperasi dengan asumsi bahwa "peserta yang mengajukan klaim yang tidak benar akan kehilangan Margin mereka". Namun, OPFP memiliki kasus kejadian yang mematahkan asumsi ini, yang dikenal sebagai "klaim naik sepeda". Keadaan ini mungkin terjadi dalam situasi berikut:

Alice mengirimkan pernyataan yang benar tentang root state.
Bob mengajukan pernyataan balik, sementara Alice mengambil tindakan untuk mempertahankan pernyataan aslinya.
Bob menunggu hampir habis waktunya (3,5 hari) sebelum mempertanyakan pernyataannya sendiri.

Pada saat ini, Alice seharusnya merespons dan mengklaim Margin Bob, tetapi dia mewarisi waktu yang tersisa dari jam Bob, yang mungkin tidak cukup baginya untuk menyangkal pernyataannya. Oleh karena itu, Bob mungkin dapat menghindari kehilangan Margin dengan mengajukan klaim 'hitchhiking'.

Pernyataan Ikut-ikutan dalam Optimism Fault Proof | Sumber: L2Beat

Meskipun ini tidak menghalangi penyelesaian yang benar dari keraguan, namun memang mewakili suatu situasi di mana "mengajukan pernyataan yang tidak benar dan tidak slashingMargin", dari sudut pandang insentif, situasi seperti ini seharusnya dihindari.

Oleh karena itu, jika waktu tersisa dari pengusul atau penantang kurang dari 3 jam, OPFP akan memperbaiki masalah ini dengan mengatur ulang jam menjadi 3 jam. Ini memastikan ada cukup waktu untuk membantah pernyataan mengambil untung dari orang lain. Namun, jika dalam dua periode berikutnya tidak ada tindakan yang diambil selama lebih dari 3 jam, pertanyaan akan berakhir.

Kita dapat membayangkan sebuah skenario di mana mekanisme ini digunakan untuk melakukan serangan latensi. Misalkan peserta jujur Alice mengirimkan output yang benar, dan sejak saat itu, penghitung waktu penantang mulai berjalan. Peserta jahat Bob menunggu sampai satu detik sebelum penghitung waktu penantang berakhir untuk mengirimkan output yang salah. Pada saat itu, aturan OPFP akan memperpanjang waktu Bob menjadi 3 jam. Alice akan merespons, sementara Bob akan terus menggunakan tambahan 3 jam untuk setiap pembagian.

Ini mungkin menjadi solusi yang mempertanyakan latensi. Bob dapat memiliki waktu latensi tertinggi selama 3,5 hari + 3 jam × jumlah maksimum iterasi biner. MAX_GAME_DEPTH OPFP adalah 73, yang berarti Bob dapat memiliki proses latensi selama 3,5 hari + 3 jam × 36 = 8 hari. Jika Alice juga mengambil langkah serupa untuk mempertanyakan latensi, proses biner mungkin akan membutuhkan waktu 16 hari.

Apakah ini berarti pengguna tidak dapat menarik dana dalam waktu 16 hari? Sebenarnya tidak demikian, karena logika penarikan dana Optimism membuat hal itu tidak berlaku. Berbeda dengan Arbitrum yang mengharuskan penarikan dana untuk membuktikan termasuk dalam Blok L2 tertentu, OP Stack menggunakan mekanisme penyimpanan bukti dan permintaan penarikan dicatat dalam kontrak L2ToL1MessagePasser di L2. Ini berarti bahwa bahkan jika ada penundaan waktu yang lama untuk Blok penarikan tertentu, pengguna masih bisa menunggu selesai Blok berikutnya dan menarik dana berdasarkan root penyimpanan kontrak yang terkandung dalam Blok tersebut. Oleh karena itu, meskipun Blok penarikan yang diminta dipertanyakan, pengguna tidak perlu mengalami latensi yang lama karena mereka dapat menggunakan Blok output berikutnya.

Namun semua ini hanya berlaku jika pengguna bertindak cepat. Dalam kebanyakan kasus, pengguna mungkin masih akan mengalami latensi selama beberapa hari. Ini dapat disebabkan oleh proses penarikan dalam Stack OP, yang terdiri dari tiga langkah utama berikut:

Mulai penarikan di L2 (initiateWithdrawal).
Di L1, buktikan transaksi penarikan (proveWithdrawalTransaction), yang meliputi output penarikan.
Tunggu hingga bukti matang latensi selama seminggu, lalu akhiri transaksi penarikan (finalizeWithdrawalTransaction).

Titik kunci di sini adalah bahwa pengguna harus menunggu satu minggu dari bukti penarikan hingga penarikan selesai. Jika Alice membuktikan penarikannya di output B dan ada sengketa, dia dapat mengirimkan bukti lain untuk output C dan menyelesaikan penarikan satu minggu kemudian. Dalam kasus ini, Alice hanya akan mengalami keterlambatan antara output B dan output C.

Oleh karena itu, pengguna yang tidak menyadari keraguan yang dibuat atau merespons terlambat mungkin mengalami penundaan penarikan hingga 9 hari.

Selain itu, OPFP juga memiliki Attack Vector latensi tambahan, yaitu setiap output dipertanyakan secara berkelanjutan. Dalam kasus ini, pengguna tidak dapat menghindari latensi dengan membuktikan pada output berikutnya, yang mengakibatkan seluruh protokol terkena latensi. OPFP mengatasi hal ini dengan meminta peserta untuk melakukan stakeMargin pada setiap tingkat biner, di mana jumlah Margin meningkat secara eksponensial seperti yang ditunjukkan dalam gambar di bawah ini.

Jumlah Margin OPFP | Sumber: Dokumen Optimism

Dengan kata lain, semakin lama waktu yang dibutuhkan untuk mengatasi latensi yang dipertanyakan dalam OPFP, semakin tinggi biaya Margin yang diperlukan, karena persyaratan Margin meningkat secara eksponensial, yang mengurangi insentif untuk melakukan serangan latensi seiring waktu. Selain itu, karena output dalam OPFP dapat diserahkan kapan saja, sulit bagi penyerang untuk memperkirakan sumber daya yang dibutuhkan untuk melakukan serangan latensi. Margin awal ditetapkan pada 0,08 ETH, sementara total Margin yang harus diserahkan saat mempertanyakan secara menyeluruh mencapai sekitar 700 ETH.

Secara keseluruhan, OPFP dalam situasi pertanyaan tunggal akan membiarkan pengguna menentukan durasi latensi, dan menggunakan persyaratan Margin tipe eksponensial untuk menetralkan serangan latensi yang dihasilkan dari pertanyaan berkelanjutan. Namun, OPFP rentan terhadap serangan Sybil. Dalam OPFP, jika penyerang memiliki lebih banyak dana daripada pembela, maka serangan Sybil dapat terjadi.

Dalam OPFP, mungkin ada Attack Vector Sybil berikut, semuanya dapat mengakibatkan pencurian dana pengguna:

Penyerang membuat banyak keraguan, menyebabkan pembelaan mengalihkan semua dana ke Margin dan biaya Gas.
Penyerang terus-menerus mengirimkan output yang salah, memaksa pembela untuk merespons hingga mereka kehabisan dana Margin dan biaya Gas mereka.

Ini mungkin terjadi di OPFP, karena selama proses pertanyaan, jumlah Margin total yang dibutuhkan oleh penyerang dan pembela hampir sama, dan sumber daya yang digunakan oleh pembela (misalnya, biaya Gas atau Daya Komputasi) tidak jauh lebih sedikit daripada penyerang.

Namun, ini tidak berarti dana pengguna dalam OP Mainnet saat ini berisiko. OPFP masih berada dalam tahap 1, dan Komite Keamanan memiliki wewenang untuk memperbaiki hasil yang tidak pantas. Oleh karena itu, bahkan jika serangan semacam itu terjadi, Komite Keamanan dapat campur tangan untuk melindungi dana pengguna di jembatan OP Mainnet.

Namun, untuk memindahkan OPFP ke Tahap 2, Optimism harus memodifikasi mekanisme untuk memastikan bahwa pembela memiliki keunggulan yang lebih besar daripada penyerang. Optimism sedang mempersiapkan Game Kontroversi V2 untuk mengatasi masalah ini, detail lebih lanjut akan dijelaskan dalam Bagian 4 'Peningkatan yang Layak'.

4) Bukti Kerusakan Kroma ZK (Kroma ZKFP)

Kroma adalah L2 yang berbasis pada OP Stack, sebelum diperkenalkannya OPFP. Pada September 2023, Kroma meluncurkan sistem bukti kegagalan ZK tanpa izin di Mainnet-nya. Kroma ZKFP memiliki fitur yang mirip dengan OPFP, tetapi keistimewaannya terletak pada penggunaan ZK untuk menghasilkan bukti pada tingkat blok dan memanfaatkan faktorisasi daripada binary search, yang secara signifikan mengurangi jumlah interaksi yang diperlukan selama proses tantangan. Fitur utama dari Kroma ZKFP dapat dirangkum sebagai berikut:

Mengurangi frekuensi interaksi melalui ZK dan dekomposisi

Kroma ZKFP memungkinkan peserta menemukan titik perbedaan dalam empat interaksi. Ketika memulai pertanyaan, Kroma ZKFP memproses pertanyaan pada 1.800 Blok, dari keluaran sebelumnya hingga keluaran saat ini. Berbeda dengan metode biner yang membagi rentang menjadi dua, dalam dekomposisi, proposer dan penanya membagi rentang menjadi N bagian. Proses ini sebagai berikut:

Setelah setiap peserta mengirimkan dua transaksi, mereka akan menentukan Blok di mana mereka memiliki perselisihan, penentang dapat menghasilkan bukti kegagalan ZK untuk menunjukkan bahwa klaim pengusul salah. Dalam Kroma ZKFP, waktu tunggu dibagi menjadi dua jam, sementara waktu tunggu untuk menghasilkan bukti ZK adalah delapan jam.

Melalui mekanisme insentif untuk mencapai Desentralisasi validator

Baik BoLD maupun OPFP memberikan insentif kepada pemenang perdebatan, tetapi tidak memberikan insentif konkret kepada pengirim output. Sebenarnya, siapa pun yang ingin menarik dana dapat mengirimkan output dan menjadi validator. Namun, bagi pengguna yang ingin mencairkan dana, mengoperasikan klien validator secara mandiri tidaklah realistis, dan seseorang harus secara teratur mengirimkan output untuk menjaga keaktifan. Karena ini adalah tugas yang membutuhkan sumber daya yang intensif, biaya gas harus dibayar untuk mengirimkan output dan mengoperasikan klien validator. Oleh karena itu, tanpa insentif yang tepat, hanya sedikit orang yang mungkin terlibat sebagai validator, yang dapat menyebabkan sentralisasi dan kurangnya respons dalam skenario kegagalan.

Untuk ini, Kroma memodifikasi OP Stack dan membagi separuh biaya Gas yang dihasilkan on-chain kepada validator yang mengirimkan output. Selain itu, Kroma berencana untuk mentransisi mekanisme insentif ini ke token asli mereka, KRO, setelah TGE dan bermaksud untuk memperkenalkan sistem validator mirip DPoS, sehingga pengguna biasa dapat berkontribusi pada keamanan dan aktivitas jaringan tanpa menjalankan klien mereka sendiri.

Jumlah Margin dalam Kroma saat ini diatur sebagai 0.2 ETH, memastikan bahwa itu melebihi biaya pembuatan bukti ZK dan biaya pembagian. Margin ini akan berubah menjadi staking KRO di sistem validator masa depan.

Sistem Tantangan 1 lawan 1 yang Berkepanjangan

Untuk memastikan distribusi insentif yang adil dan konsisten, Kroma mengatur interval pengajuan keluar tetap selama 1 jam, dan secara acak memilih validator dari kumpulan validator yang telah mendaftar sebagai proposer. Ini mencegah kompetisi berlebih yang dapat menyebabkan pemborosan biaya Gas, dan menghindari monopoli pembangun Blok yang memiliki hak pengurutan transaksi atas penghargaan.

Dengan mekanisme ini, Kroma ZKFP menjalankan sistem tanya jawab 1 lawan 1 yang berjalan sejajar. Ketika validator yang dipilih secara acak mengajukan output, siapa pun dapat memulai pertanyaan, hanya terjadi pemisahan antara pengirim output dan pengajuan pertanyaan. Beberapa pertanyaan dapat dilakukan secara bersamaan, orang yang pertama kali mengajukan bukti ZK yang valid akan memenangkan pertanyaan.

Timeout yang ketat berarti bahwa bahkan penanya jahat yang mencoba melakukan serangan latensi harus menyelesaikan semua pemisahan dan pembuatan bukti dalam waktu 10 jam. Selain itu, karena penanya dipaksa untuk menyelesaikan semua operasi dalam waktu 6 hari (tidak termasuk periode pengawasan selama 1 hari), serangan latensi umum tidak mungkin dilakukan di Kroma.

Namun, jika dana penyerang melebihi dari pembela, Kroma ZKFP masih rentan terhadap serangan Sybil, mirip dengan OPFP. Dalam Kroma ZKFP, skenario serangan Sybil mungkin seperti yang ditunjukkan di bawah ini:

Penyerang terus-menerus meragukan output yang valid, sampai dana pengirim output habis, saat itu penyerang mengirimkan bukti ZK untuk memenangkan keraguan.

Mirip dengan OPFP, Kroma ZKFP akan menghapus output yang sesuai setelah berhasil mempertanyakan keabsahannya. Oleh karena itu, jika serangan semacam itu terjadi, output tersebut mungkin akan dihapus, menyebabkan latensi penarikan dana pengguna mencapai 1 jam. Jika serangan terus berlanjut, semua validator jujur dapat menghabiskan dana mereka, menyebabkan output yang salah akhirnya dikonfirmasi, sehingga memungkinkan penyerang mencuri dana pengguna.

Selain itu, Kroma ZKFP masih berada di tahap 0, sistem verifikasinya belum sempurna, dengan alasan sebagai berikut:

Titik awal pemecahan didasarkan pada output terakhir yang dikirimkan, bukan output yang terakhir dikonfirmasi.

Dalam OPFP, titik awal pembagian biasanya adalah output konfirmasi terakhir sekitar seminggu yang lalu. Namun, dalam Kroma ZKFP, titik awalnya adalah output yang terakhir dikirimkan sekitar 1 jam yang lalu, proses pembagian dilakukan pada 1.800 Blok.

Ini mungkin membuat penanya memenangkan pertanyaan jika sebelumnya outputnya telah dihapus karena dipertanyakan. Dalam hal ini, pembagian akan didasarkan pada informasi output sebelumnya yang diajukan oleh penanya, jika penanya dengan sengaja memanipulasi informasi ini, mereka mungkin memenangkan pertanyaan.

Tidak ada verifikasi apakah setiap validator mempertanyakan data batch yang benar.

Meskipun Kroma ZKFP menggunakan ZK untuk memastikan bahwa jika sirkuit ZK tidak bocor, maka tidak mungkin untuk mengonfirmasi kesalahan status transisi akhir, namun Kroma ZKFP belum memverifikasi apakah pembuatan bukti ZK didasarkan pada data batch yang benar. Ini berarti bahwa meskipun beberapa transaksi dikecualikan atau transaksi yang salah dimasukkan ke dalam batch, bukti ZK masih mungkin lolos verifikasi.

Oleh karena itu, mungkin memenangkan keraguan dengan menggunakan bukti ZK berdasarkan data yang salah, dan jika transaksi penarikan pengguna dikecualikan dari batch, penarikan mereka bisa terlambat.

Namun, dalam praktiknya, komite keamanan dapat campur tangan untuk menarik kembali hasil keraguan yang salah atau menghapus output yang tidak valid, sehingga Attack Vector ini tidak akan memengaruhi dana pengguna Kroma Mainnet. Namun, untuk mencapai tahap 2, Kroma ZKFP harus menerapkan mekanisme pertahanan terhadap kerentanan ini. Kroma telah mengusulkan perbaikan untuk masalah ini, yang akan dijelaskan secara detail dalam bagian 4 'Perbaikan yang Memungkinkan'.

3.4 Vektor Serangan #2: Pemeriksaan L1

Sebelumnya kita menyebutkan bahwa Rollup mewarisi keamanan Ethereum. Ini berarti jika keamanan Ethereum terganggu, Rollup juga akan terpengaruh.

Ada dua situasi di mana keadaan Ethereum dapat mempengaruhi keamanan Rollup:

Pemeriksa validator ETH untuk transaksi bukti penipuan Rollup. **Jika validator atau pembangun Ethereum bersatu, dan mengirimkan root output jahat dalam Optimistic Rollup, sambil memeriksa semua transaksi yang terkait dengan bukti penipuan, apa yang akan terjadi? Keraguan tidak akan dapat diselesaikan dalam batas waktu yang ditentukan, output akan dikonfirmasi, dan dana pengguna mungkin berisiko. Ini disebut sebagai pengawasan yang lemah. Dalam kasus Optimistic Rollup, jika pengawasan ini berlangsung lebih dari waktu yang ditentukan (biasanya 7 hari), dana pengguna mungkin menghadapi risiko.
**Ethereum mengalami serangan 51%, menyebabkan semua transaksi bukti penipuan ditinjau ulang. **Situasi ini melibatkan dua jalur serangan yang mungkin:

Pertama, sebuah entitas dapat memperoleh lebih dari 2/3 dari total staking Ethereum, yang akan memungkinkan mereka untuk dengan bebas mengonfirmasi Blok. Dalam situasi seperti ini, penyerang dapat memeriksa transaksi penipuan, bahkan dengan bebas menghasilkan transaksi tersebut.
Metode kedua melibatkan peserta dengan stake total ETH Blok lebih dari 1/3 untuk melakukan serangan 'censorship' yang 'tidak dapat diatribusikan'. Ini dijelaskan dalam penelitian "Serangan Censorship yang Tidak Dapat Diatribusikan pada protokol L2 berbasis bukti penipuan". Dalam kasus ini, penyerang dengan stake ETH Blok 1/3 dapat mencegah konfirmasi Blok apa pun yang mereka tidak sukai. Jika penyerang terus memilih Blok biasa sambil tetap diam pada Blok yang mengandung bukti penipuan, mereka mungkin akan mengkonfirmasi root output jahat, sehingga mencuri dana dari Optimistic Rollup. Ini disebut sebagai serangan censor yang tidak dapat diatribusikan pada L2 berbasis bukti penipuan. Serangan ini lebih sulit dideteksi daripada hanya mendapatkan lebih dari 2/3 stake dan mengendalikan semua Blok ETH.

Serangan berbasis pengawasan ini sulit ditangani pada tingkat Rollup, karena terjadi pada layer protokol Ethereum dan memerlukan peningkatan pada Ethereum itu sendiri. Namun, Rollup dapat mengadopsi beberapa strategi selama periode ini.

3.5 Solusi #2: Pemulihan penarikan dalam 7 hari dan serangan 51% semi otomatis latensi

Untuk menghadapi Attack Vector ini, Optimistic Rollup saat ini menerapkan latensi penarikan selama 7 hari. Periode 7 hari ini awalnya diusulkan oleh Vitalik, berdasarkan ide bahwa 7 hari cukup untuk melawan serangan audit.

Mari kita analisis apakah periode 7 hari pertanyaan Optimistic Rollup cukup untuk melawan serangan audit, akan mempertimbangkan dua jenis serangan audit: serangan audit lemah dan kuat.

Untuk jenis kelemahan pemeriksaan pertama, kita dapat menggunakan perhitungan probabilitas untuk melihat apakah 7 hari waktu memberikan Optimistic Rollup kemampuan untuk melawan serangan pemeriksaan. Ini melibatkan perhitungan probabilitas keberhasilan dalam mempertanyakan penipuan ketika validator tertentu mempertanyakan transaksi Rollup.

Di sini, perlu mempertimbangkan dua faktor:

Untuk berhasil mempertanyakan dalam waktu 7 hari, beberapa transaksi harus berhasil dilakukan.

Dalam kebanyakan protokol, jika hanya satu transaksi dari peserta yang jujur dimasukkan dalam satu minggu, keraguan tidak akan berhasil. Oleh karena itu, kita perlu menghitung probabilitas semua transaksi yang diperlukan untuk mengajukan bukti penipuan dalam 7 hari.

Harus mengasumsikan dengan wajar proporsi validator yang terlibat dalam pemeriksaan. Saat ini, sebagian besar pembangun blok rantai ETH (dikenal sebagai terpusat) tidak melalui pemeriksaan, mengingat proporsi staker individu di ETH, peluang kolusi validator untuk melakukan pemeriksaan hampir nol (misalnya, 99,9%).

Peninjau Blok utama Ethereum (ETH) | Sumber: Tweet Justin Drake

Mempertimbangkan dua hal ini, jika kita berasumsi 99,5% validator (yang masih merupakan asumsi yang terlalu ekstrem) berpartisipasi dalam audit, dan menghitung probabilitas keberhasilan peserta yang jujur mengirim 30 hingga 40 pertukaran yang dipertanyakan pada protokol (seperti BoLD atau OPFP), maka dalam semua kasus, probabilitas keberhasilan mendekati 100%. Selain itu, dengan munculnya solusi masa depan (seperti daftar yang disertakan atau beberapa pengusul bersama seperti BRAID, APS + FOCIL), kemampuan untuk melawan audit mungkin semakin ditingkatkan, sehingga mengurangi risiko kehilangan dana pengguna oleh Drop Optimistic Rollup karena audit yang lemah.

Jadi, apakah 7 hari cukup dalam kasus pemeriksaan yang ketat? Serangan 51% yang disebutkan sebelumnya hanya dapat diselesaikan melalui fork sosial. Serangan yang tidak dapat diatribusikan, terutama sulit dideteksi, dan tidak dapat dicegah melalui solusi yang dirancang untuk pemeriksaan lemah (seperti penyertaan dalam daftar).

Ada proposal untuk mengembangkan alat pemulihan serangan 51% yang semi-otomatis di dalam perangkat lunak klien, yang didasarkan pada struktur yang diusulkan oleh Vitalik. Para peneliti Ethereum juga mengembangkan solusi deteksi review ini dalam dua tahap:

light client memantau memori kolam transaksi, mendeteksi apakah waktu tidak terlalu lama untuk beberapa transaksi yang tidak termasuk dalam Blok.
Jika transaksi tertentu tinggal di memory pool selama satu hari tanpa dimasukkan ke Blok, maka akan memicu tombol "Apakah Anda setuju untuk melakukan fork sosial?" untuk memungkinkan komunitas melakukan hard fork berdasarkan Konsensus ini.

Jika alat tersebut mendeteksi serangan 51%, langkah selanjutnya akan melakukan fork sosial ke on-chain baru, sehingga membuat dana penyerang menjadi tidak valid.

Dalam situasi ini, dana yang terpengaruh oleh serangan 51% harus tetap terkunci sampai fork sosial selesai dilaksanakan. Hal serupa terjadi selama Hard Fork DAO, di mana dana Hacker terkunci di dalam Sub-DAO selama 27 hari sampai mereka dapat menariknya. Selama periode ini, komunitas Ethereum berhasil melakukan Hard Fork yang mencegah Hacker menguangkan dana (untuk lebih banyak detail, lihat postingan Vitalik di Reddit)

Dengan kata lain, bahkan jika terjadi serangan 51%, dana perlu tetap dikunci hingga terjadi fork sosial. Dalam kasus ini, periode penarikan 7 hari dalam Optimistic Rollup bertindak sebagai area buffer. Jika tidak ada fork sosial dalam seminggu, dana pengguna dalam Optimistic Rollup mungkin akan dicuri, atau dapat ditarik ke pertukaran terpusat, atau dicampur melalui Tornado Cash, sehingga hampir tidak mungkin untuk mengembalikan dana kepada pengguna setelah fork sosial terjadi.

Secara keseluruhan, meskipun periode penarikan selama 7 hari dalam Optimistic Rollup awalnya dirancang untuk mengatasi pengawasan yang lemah, namun kemungkinan terjadinya pengawasan yang lemah sangat kecil, dan periode 7 hari ini berfungsi sebagai waktu penundaan dalam kasus pengawasan yang kuat memerlukan fork sosial.

Dari sudut pandang ini, ada kritik terhadap OPFP karena memperpendek batas waktu ini menjadi 3.5 hari, membuatnya lebih rentan terhadap serangan pemeriksaan yang kuat. Namun, kritik ini tidak beralasan. Karena Optimism masih berada di tahap 1, penjaga memiliki periode buffer yang cukup untuk memverifikasi kebenaran status root, dan penarikan hanya dapat dilakukan setelah periode penjaga tambahan 3.5 hari berakhir. Oleh karena itu, bahkan jika terjadi serangan pemeriksaan yang kuat, penyerang masih harus menunggu 7 hari untuk menarik dana. Selain itu, penyerang juga harus memeriksa semua transaksi yang terkait dengan keraguan selama seminggu penuh untuk berhasil, karena penjaga juga perlu diperiksa untuk mencegah mereka membatalkan konfirmasi output jahat.

Namun, kunci utamanya adalah bahwa Ether harus memastikan bahwa mereka dapat menangani fork sosial dalam waktu 7 hari. Ini berarti bahwa alat-alat untuk mendeteksi serangan 51% harus siap dan memerlukan penelitian dan simulasi yang cukup untuk memastikan apakah fork sosial dapat dilaksanakan dalam waktu 7 hari. Hanya dalam kasus ini, latensi pencairan 7 hari dalam Optimistic Rollup dapat dianggap sebagai jaminan yang efektif.

3.6 Attack Vector #3：Memanfaatkan kerentanan dalam sistem Attack Vector

Sebagian besar keraguan protokol melalui membuat peserta menemukan titik tertentu (instruksi atau Blok), di mana mereka tidak setuju, kemudian menghasilkan bukti bahwa klaim peserta lain salah. Virtual Machine yang digunakan untuk menghasilkan bukti ini disebut Virtual Machine Bukti Penipuan (Fraud Proof VM), sedangkan perangkat lunak yang digunakan di atas Virtual Machine ini untuk menghasilkan bukti disebut program. Setiap protokol menggunakan VM dan program Bukti Penipuan yang berbeda, seperti yang ditunjukkan di bawah ini:

Setiap sistem bukti penipuan dimaksudkan untuk membuktikan bahwa hasil eksekusi tertentu di EVM adalah benar di on-chain. Tetapi, apa yang terjadi jika sistem tersebut (baik itu Virtual Machine atau program) memiliki kerentanan?

Masalah ini dapat dibahas melalui Attack Vector [yang ditemukan di OVM] oleh Yoav Weiss (https://medium.com/infinitism/optimistic-time-travel-6680567f1864). Karena kerentanan Rollback dalam OVM, serangan menjadi mungkin, tetapi menciptakan transaksi penipuan menjadi kondisi penting untuk melaksanakan serangan. Transaksi penipuan adalah transaksi yang dieksekusi saat diproses secara normal di Rollup, tetapi menghasilkan hasil yang berbeda saat dipertanyakan menggunakan Virtual Machine dan program bukti penipuan. Karena sistem bukti penipuan harus menghasilkan hasil yang sama dengan EVM, kemampuan untuk menciptakan transaksi penipuan berarti bahwa ada kerentanan dalam sistem bukti penipuan.

Yoav menemukan beberapa kerentanan dalam sistem bukti penipuan OVM dan dapat mensimulasikan serangan ini dengan menghasilkan transaksi penipuan. Contoh serangan sederhana yang ditemukan olehnya adalah: dalam StateManager OVM, biaya gas untuk Kode Operasi SSTORE dan SLOAD (digunakan untuk menyimpan dan membaca status) dicatat dengan salah. Ini berarti bahwa setiap transaksi yang menyimpan atau membaca nilai di kontrak (hampir semua transaksi kecuali transfer ETH sederhana) akan ditandai sebagai transaksi penipuan selama proses penyelidikan, meskipun itu dieksekusi dengan benar di Rollup.

Singkatnya, jika ada kerentanan dalam sistem, perubahan status yang dilakukan dengan benar dapat salah dicap sebagai tidak valid selama periode peninjauan, menyebabkan output yang diserahkan oleh peserta yang jujur dicap sebagai salah.

Ini juga salah satu alasan mengapa OP Mainnet baru-baru ini mengubah sistem pembuktian kegagalan dari mode tak berizin menjadi mode hanya untuk pihak yang berwenang. Setelah aplikasi OPFP diterapkan pada Mainnet, audit keamanan mengungkap beberapa kerentanan dalam sistem bukti penipuan (Cannon dan op-program) serta protokol tantangan permainan yang kontroversial. Untuk mencegah penyalahgunaan sistem, Optimism mengumumkan pada tanggal 17 Agustus bahwa mereka akan beralih ke sistem berwenang.

Tentu saja, memanfaatkan kerentanan Mesin Virtual terhadap Rollup yang berada pada tahap 0 atau tahap 1 mungkin tidak memiliki dampak besar, karena komite keamanan dapat sewaktu-waktu terlibat untuk memperbaiki hasil yang dipertanyakan. Ini adalah pandangan yang diajukan sebelumnya oleh OP Labs. Sebenarnya, OP Labs berbagi kerangka audit mereka di forum Optimism, merangkum standar kapan audit eksternal diperlukan.

(Kerangka Audit OP Labs | Sumber: Forum Optimisme)

Dalam kerangka ini, situasi terbaru termasuk dalam kuadran IV: "Bukti Kegagalan Tahap Bantuan". Meskipun situasi ini terkait dengan keamanan rantai, namun tidak langsung memengaruhi dana pengguna, sehingga tidak termasuk dalam cakupan audit. Ini berarti bahwa meskipun kerentanan dieksploitasi, komite keamanan masih dapat memperbaiki hasilnya.

Namun, setelah kelemahan diidentifikasi, perlu untuk menyelesaikan masalah-masalah ini. Optimism telah memperbaiki masalah-masalah ini dalam upgrade jaringan Granite-nya, memungkinkan OP Mainnet pulih ke Tahap 1.

Di sisi lain, kerentanan dalam sistem mungkin fatal dalam Rollup tahap 2. Pada tahap 2, komite keamanan hanya dapat campur tangan jika ada bukti on-chain tentang kerentanan. Karena hampir tidak mungkin untuk membuktikan 'hasil penolakan salah karena kerentanan sistem' secara on-chain, maka jika terjadi kerentanan dalam Rollup tahap 2, dana pengguna mungkin berisiko.

3.7 Solusi #3: Bukti Multi

Untuk mencegah masalah semacam ini, audit menyeluruh sebelum kode masuk produksi sangat penting. Namun, bukti penipuanVirtual Machine dan program adalah sistem perangkat lunak yang kompleks, semakin kompleks sistem, semakin besar kemungkinan terjadinya kerentanan. Oleh karena itu, meskipun telah melalui audit yang ketat, kerentanan masih dapat muncul. Kita perlu mengeksplorasi strategi tambahan di luar audit.

Salah satu metode adalah menggunakan beberapa sistem bukti dalam satu sistem. Selama proses peninjauan, sistem tidak hanya menggunakan satu sistem untuk menghasilkan bukti penipuan, tetapi juga dapat menggunakan Virtual Machine dan program yang berbeda secara bersamaan untuk menghasilkan beberapa bukti penipuan kemudian membandingkan hasilnya. Ini akan menciptakan sistem yang tetap aman bahkan ketika terjadi kerentanan.

Misalnya, bayangkan sebuah sistem bukti ganda yang menggunakan Cannon Optimism dan Virtual Machine dengan bukti kegagalan asterisc ZK (menggunakan Risc-V). Dalam situasi yang dipertanyakan, hal-hal berikut akan terjadi:

Jika kesalahan output terdeteksi, penggugat akan menghasilkan gugatan dan memulai metode pembagian dua.
Begitu Blok perbedaan ditemukan melalui metode pembagian dua, dua sub-permainan akan terjadi secara bersamaan:

Subgame Cannon dari Cannon yang menggunakan metode OPFP tradisional. Menggunakan asterisc untuk menghasilkan subgame bukti kegagalan ZK.

Setelah menyelesaikan dua permainan, akan diverifikasi dua bukti penipuan yang berbeda.

Jika kedua bukti lulus dalam verifikasi, maka penantang akan menang; jika kedua bukti tidak lulus, maka penantang akan kalah. Namun, jika satu lulus dan satu tidak, ini menunjukkan bahwa ada kerentanan yang tidak terduga dalam proses pembuatan bukti oleh Mesin Virtual atau program.

Dalam situasi ini, entitas seperti Komite Keamanan akan ikut campur untuk menyesuaikan hasil pertanyaan. Hal ini memastikan sistem tetap tertutup rapat dan tidak melanggar kondisi 'Komite Keamanan hanya dapat campur tangan dalam kasus kerentanan yang dapat dibuktikan secara on-chain'.

Ini adalah salah satu upaya berkelanjutan untuk mencapai Fase 2 Optimism. Untuk mendukung hal ini, permainan kontroversial OPFP melibatkan sistem bukti penipuan modular yang memungkinkan implementasi bebas dari banyak sistem, serta mendefinisikan antarmuka minimum untuk mendukung hal ini.

4. Perbaikan yang Memungkinkan

Dalam bab-bab sebelumnya, kita telah membahas desain dari Optimistic Rollup protokol dan kemungkinan kerentanan yang mungkin muncul dalam proses verifikasi dan bukti penipuan. Bagian ini akan membahas masalah dan solusi dari setiap protokol, serta sistem bukti penipuan dan prospek masa depan dari Optimistic Rollup.

4.1 Ruang Peningkatan untuk Setiap Protokol

1) Arbitrum BoLD

BoLD memiliki protokol ekonomi yang kuat karena membatasi latensi protokol maksimum menjadi satu minggu dan memastikan dapat mencegah Serangan Sybil secara efektif sebelum dana penyerang melampaui 6,5 kali dari pertahanan. Namun, BoLD memiliki dua masalah yang signifikan:

Rasio sumber 6.5 kali terlalu kecil untuk keunggulan pembela.
Jaminan deposit untuk submit root statement adalah 3,600 ETH, jumlah ini terlalu besar.

Masalah pertama dapat diselesaikan dengan menggunakan teknologi ZK. BoLD membagi pertanyaan menjadi beberapa tingkat untuk mengurangi sumber daya yang dibutuhkan untuk menghitung janji masa lalu. Dengan menggunakan ZK, ini dapat dikurangi menjadi satu tingkat saja.

Konsep ini mirip dengan proposal BoLD++ yang diajukan oleh Gabriel dari Cartesi. Ketika keraguan dibagi menjadi beberapa tingkat, peningkatan proporsi sumber daya akan menyebabkan skala deposito tingkat tertinggi meningkat secara eksponensial. Namun, ketika menggunakan tingkat tunggal, proporsi sumber daya dapat lebih mudah ditingkatkan, sehingga protokol lebih tahan terhadap serangan Sybil.

Masalah kedua, yaitu membutuhkan deposito ETH sebesar 3.600, lebih sulit untuk diatasi. Skala deposito BoLD tidak hanya untuk menghadapi serangan Sybil, tetapi juga untuk menakuti serangan latensi. Skala deposito adalah fungsi TVL (Total Nilai Kunci) dan bahkan dengan menggunakan ZK, tidak dapat secara signifikan menurunkannya. Untuk mengatasi masalah ini, BoLD sedang menerapkan mekanisme deposito yang di-pool, yang memungkinkan beberapa peserta untuk bersama-sama menanggung deposito tersebut.

2) Cartesi Dave

Dave secara efektif mengatasi serangan Sybil melalui struktur turnamennya, tetapi seperti yang telah disebutkan sebelumnya, mudah diserang oleh serangan latensi. Waktu latensi maksimum adalah fungsi dari jumlah klaim jahat NA dan jumlah tingkat staking L, dengan rumus perhitungan sebagai berikut: Td = 7 x [log2(1 + NA)]L(天数)

Jika NA = 7 dan L = 3, protokol dapat menghadapi latensi selama empat bulan yang signifikan mengganggu dan merugikan pengguna karena penarikan akan mengalami latensi.

ZK dapat membantu mengurangi masalah ini. Dengan memperbaiki level L menjadi 1 (seperti baris dalam BoLD++), waktu latensi maksimum dapat dikurangi menjadi: Td = 7 x log2(1 + NA)(days)

Menurut laporan, Cartesi sedang melakukan perbaikan ini dengan menggunakan teknologi ZK dari RISC Zero. Namun, masih ada kekhawatiran apakah perbaikan ini cukup untuk mencegah serangan latensi sepenuhnya. Jika NA = 7, protokol masih dapat menghadapi latensi tambahan hingga dua minggu, sementara biaya bagi penyerang hanya sebesar deposit 7 ETH ditambah biaya Gas dan biaya komitmen sejarah di luar rantai. Untuk rantai yang memiliki nilai Posisi Lock-up yang tinggi, hukuman semacam itu mungkin tidak cukup untuk mencegah serangan latensi.

(Dave: Mekanisme sub-pertanyaan dengan gaya BoLD | Sumber: L2Beat Medium)

Ada saran untuk Dave menggunakan mekanisme pertanyaan gaya BoLD, dengan 8 peserta dalam setiap putaran kompetisi, bukan pertandingan satu lawan satu, mirip dengan turnamen tradisional. Dalam hal ini, rumus perhitungan latensi adalah:

Td = 7 x log8(1 + NA)(天数)

Dalam struktur ini, penyerang harus menyediakan setidaknya 64 ETH Margin untuk mempertanyakan latensi selama lebih dari dua minggu, total kebutuhan Margin adalah 64 ETH, dan harus menanggung biaya on-chain dan off-chain yang besar.

Namun, kekurangan metode ini adalah melemahkan keunggulan pembela dalam menghadapi serangan Sybil. Meskipun BoLD memberikan struktur di mana pembela memiliki keunggulan N kali lipat daripada penyerang, Dave menciptakan struktur di mana pembela memiliki keunggulan eksponensial yang jauh melebihi penyerang.

Secara keseluruhan, Dave dapat membatasi vektor serangan latensi dengan efektif menggunakan bukti penipuan ZK. Meskipun struktur yang mirip dengan BoLD dapat meningkatkan kemampuan melawan serangan latensi, namun hal ini dapat mengakibatkan kelemahan dalam menghadapi serangan Sybil.

3）Optimism Fault Proof (OPFP)

Kelemahan OPFP adalah rentan terhadap serangan Sybil karena biaya serangan dan pertahanan sama besar. OP Labs mengusulkan solusi untuk masalah ini dalam Permainan Kontroversial V2.

Berbeda dengan OPFP asli, yang mengharuskan Margin dikirim setiap kali pembagian dua, permainan kontroversial V2 hanya meminta peserta untuk mengirimkan Margin pada awal pembagian dua. Selain itu, permainan kontroversial V2 memperkenalkan pembagian dua, yang memungkinkan peserta untuk mengirimkan beberapa permintaan pada saat titik cabang, sehingga dalam kebanyakan kasus mengurangi jumlah interaksi.

Pernyataan cabang dalam (Game Kontroversial V2 | Sumber: Optimism Specs GitHub)

Dalam OPFP sebelumnya, vektor serangan Sybil termasuk:

Membuat sejumlah besar keraguan untuk menghabiskan dana Margin dan biaya Gas dari para pembela.
Terus-menerus mengirimkan output palsu, membuat pihak yang bertahan harus merespons dan habiskan sumber dayanya.

Pengenalan pernyataan cabang telah menyelesaikan dua masalah vektor ini. Pertama, peserta jujur tidak perlu mengirimkan Margin tambahan selama proses pembagian, sementara penyangkal jahat harus mendepositkan jaminan untuk setiap penyangkalan baru yang mereka buat. Jika jumlah jaminan diatur dengan benar, serangan yang menciptakan banyak penyangkalan menjadi tidak berkelanjutan.

Selanjutnya, dalam permainan kontroversial V2, jumlah Margin tingkat yang lebih tinggi lebih besar, sehingga biaya terus-menerus mengirimkan output palsu bagi penyerang lebih tinggi daripada bagi pembela.

Oleh karena itu, OPFP dapat efektif menghadapi serangan Sybil dengan memperkenalkan pernyataan cabang dalam game kontroversial V2.

4) Kroma ZK Bukti Kesalahan (Kroma ZKFP)

Kroma ZKFP menghadapi dua tantangan yaitu kerentanan terhadap serangan Sybil dan sistem bukti yang tidak sempurna. Untuk maju ke tahap 1, Kroma ZKFP perlu menyelesaikan dua masalah berikut ini:

Titik awal metode biner didasarkan pada output terakhir yang disampaikan, bukan output yang terakhir dikonfirmasi.
validator tidak memeriksa apakah keraguan tentang kebenaran data batch yang benar.

Kroma berencana beralih dari Halo2 zkEVM Scroll ke Succinct SP1 zkVM untuk mengatasi kedua masalah tersebut dan mendorong ke tahap 1.

Kroma diperkirakan akan mengubah proses perselisihan untuk sejalan dengan antarmuka permainan sengketa Optimism. Penyesuaian ini dijelaskan secara rinci dalam standar Kroma, yang akan memungkinkan pergeseran titik awal dua bagian menjadi output terakhir yang ditentukan seminggu sebelumnya, untuk memecahkan masalah pertama.

Untuk pertanyaan kedua, Kroma akan menggunakan deduksi tidak dipercaya berbasis ZK. Cara kerjanya adalah sebagai berikut:

(Menggunakan ZK deduksi tanpa kepercayaan | Sumber: Lightscale Notion)

Bayangkan, kita ingin membuktikan bahwa Blok T L2 tertentu dieksekusi dengan benar. Sebelum menghasilkan bukti ZK, kita harus memverifikasi apakah data transaksi Blok T dibangun dengan benar berdasarkan data batch L1.

Di sini, Kroma bermaksud untuk memverifikasi data dalam jumlah besar melalui ZK apakah diekstraksi dengan benar dari L1. Jika data hanya diakses melalui RPC terpercaya di luar program ZK, maka tidak mungkin untuk memastikan apakah data dalam jumlah besar telah dimanipulasi. Anda dapat memverifikasi apakah program mengakses Blok yang benar dan mengekstraksi data dalam jumlah besar melalui bukti ZK keterhubungan Blokhash, yang mencakup Blok dari Blok O (sumber L1 dari Blok T L2) hingga Blok C (L1 Blok saat keraguan dibuat). Jika pihak yang meragukan membangun Blok T L2 berdasarkan data dalam jumlah besar yang salah, maka Blokhash L1 yang diacu oleh pihak yang meragukan untuk mengekstraksi data dalam jumlah besar akan berbeda dengan Blokhash L1 yang sebenarnya yang berisi data dalam jumlah besar (termasuk T1), dan tidak akan terhubung dengan Blok C. Oleh karena itu, selama tidak ada konflik hash, memverifikasi keterhubungan L1 Blok melalui ZK dapat membuktikan bahwa pihak yang meragukan telah membangun Blok L2 dari data dalam jumlah besar yang benar.

Kroma berencana menggunakan ZK untuk memverifikasi keakuratan data dalam jumlah besar, yang dapat memeriksa keterhubungan Blokhash dari L1 Blok O ke C. Jika seseorang mempertanyakan dan mengkonstruksi L2 Blok T berdasarkan data dalam jumlah besar yang salah, maka Blokhash L1 yang mereka gunakan akan berbeda dengan Blok L1 yang benar yang memuat data dalam jumlah besar, dan tidak akan terhubung ke Blok C. Karena tidak ada konflik hash, proses pertanyaan dapat menggunakan metode ini untuk memverifikasi data dalam jumlah besar yang benar.

Dengan perbaikan ini, Kroma ZKFP akan dapat memasuki tahap 1. Namun, untuk mencapai tahap 2, Kroma memerlukan solusi tambahan untuk melawan serangan Sybil, termasuk mengubah protokol pertanyaan menjadi semua terhadap semua (All-vs-All) dan mendesain ulang mekanisme Margin.

4.2. Summary

5. Masa Depan Bukti Penipuan

5.1. Rollup Tahap 2 - Dana Anda Aman

Seperti yang telah disebutkan sebelumnya, Optimistic Rollups sedang berkembang menuju tahap 2. Arbitrum sedang berusaha untuk mencapai tahap 2 berdasarkan BoLD. Rencana implementasi BoLD telah diterbitkan di forum governance dan mendapatkan banyak dukungan, saat ini telah dideploy di jaringan uji. Jika tidak ada masalah keamanan yang signifikan ditemukan, Arbitrum kemungkinan besar akan mencapai tahap 2 melalui BoLD sebelum akhir tahun ini.

Optimism juga sedang berusaha untuk mencapai Tahap 2. Untuk mencapai Tahap 2 Mainnet OP, kita harus menyelesaikan game sengketa V2 dan membutuhkan berbagai mekanisme bukti untuk mendukung bukti ganda. Meskipun standarnya masih dalam pengembangan, game sengketa V2 secara efektif mengatasi kelemahan OPFP yang ada, memberikan perlindungan yang kuat untuk melawan serangan Sybil, sehingga mendekatkannya pada tahap 2. Selain itu, berbagai tim, termasuk OP Labs, Succinct, Kroma, dan Kakarot, sedang aktif mengembangkan bukti ganda, dan telah mengalokasikan sumber daya riset yang besar untuk menciptakan beragam cara bukti tumpukan OP. Oleh karena itu, kecuali terjadi masalah besar, Optimism juga diharapkan akan menuju ke Tahap 2 pada paruh pertama tahun depan.

Transisi kedua Rollup ini ke Tahap 2 mungkin memiliki dampak besar pada ekosistem Rollup. Arbitrum dan Optimism masing-masing memiliki kerangka Rollup mereka sendiri, yaitu Arbitrum Orbit dan OP Stack. Transisi Tahap 2 mereka berarti semua Rollup yang menggunakan kerangka ini juga dapat beralih ke Tahap 2.

Oleh karena itu, dari akhir tahun ini hingga tahun depan, Rollup utama dengan basis pengguna yang besar, seperti Arbitrum, OP Mainnet, dan Base, diperkirakan akan beralih ke tahap 2, mewarisi keamanan lengkap dari Ethereum. Ini kemungkinan besar akan meredakan kritik seperti “Rollup hanyalah multi-tanda tangan” atau “Rollup dapat mengambil dana Anda kapan saja”.

5.2. ZK bukti penipuan adalah masa depan

Sebagian besar protokol yang dibahas dapat menguntungkan dengan menerapkan ZK bukti penipuan. Misalnya, menerapkan ZK pada Arbitrum BoLD dapat meningkatkan rasio sumber daya sehingga lebih tahan terhadap serangan Sybil, sementara Cartesi Dave dapat membuatnya lebih tidak rentan terhadap serangan latensi. OPFP juga sedang mengembangkan ZK untuk mendukung sistem bukti ganda, yang dapat mengurangi jumlah Margin dan meningkatkan keamanan protokol.

Perlu diperhatikan bahwa ZK bukti penipuan tidak hanya berarti mengurangi interaksi antara validator. Kurangnya interaksi berarti sumber daya yang dibutuhkan validator secara signifikan berkurang, sehingga DropMargin jumlah, memungkinkan lebih banyak peserta untuk bergabung dengan protokol. Selain itu, ini juga mengurangi latensi maksimum yang mungkin terjadi, meningkatkan keamanan protokol secara keseluruhan.

通过这种方式，ZK bukti penipuan在 Optimistic Rollup 的安全性和Desentralisasi方面发挥着关键作用。

5.3. Bagaimana Kinerja ZK Rollup? Apakah bukti penipuan akan melemah?

Pada saat ini, beberapa pembaca mungkin bertanya: Jika bukti penipuan dan mekanisme keraguan begitu rumit, apakah ZK Rollups akan menjadi pilihan yang lebih baik? Secara beberapa hal, ini benar. Dalam Rollups ZK, mencapai tahap 2 tidak memerlukan pertimbangan faktor ekonomi yang kompleks, dan dana pengguna tidak akan menghadapi risiko pencurian dalam kejadian audit L1, dan pengguna dapat menarik dana mereka dalam beberapa jam.

Transisi dari Optimistic Rollups ke ZK Rollups mungkin akan lebih cepat dari yang diharapkan. Ini karena kekurangan utama ZK Rollups - biaya dan waktu pembuatan bukti yang sangat tinggi - sedang cepat membaik. Baru-baru ini, Succinct Labs meluncurkan OP Succinct, yang merupakan versi ZK berbasis OP Stack dan menyediakan kerangka kerja yang mudah untuk memulai ZK Rollups.

OP Succinct Pengantar | Sumber: Blog Succinct

Namun, masih ada beberapa faktor yang perlu dipertimbangkan. Pertama adalah biaya. Dalam OP Succinct, biaya untuk menghasilkan Bukti Blok sekitar $0.005-$0.01, sementara perkiraan biaya bulanan untuk menjalankan pemroses adalah antara $6,480 hingga $12,960. Jika jumlah transaksi per detik (TPS) pada rantai tinggi, biaya ini mungkin akan semakin meningkat.

(Biaya bukti jaringan masing-masing Benchmark | Sumber: Blog Singkat )

Misalnya, di jaringan Base OP Succinct, biaya rata-rata pembuatan bukti setiap Blok sekitar $0,62. Berdasarkan angka ini, biaya bulanan akan mencapai $803.520. Ini adalah biaya tambahan yang tidak dimiliki oleh Optimistic Rollups, bahkan jika biaya ZK Drop, biaya operasional ZK Rollups akan selalu lebih tinggi daripada Optimistic Rollups.

Pertimbangan kedua adalah dampak Desentralisasi. Pada ZK Rollups, validator perlu menjalankan bukti penipuan, yang lebih sulit dan mahal daripada menjalankan program bukti penipuan pada Optimistic Rollups. Selain itu, karena waktu pembuatan bukti dalam sistem ZK lambat, pengguna tidak dapat memverifikasi transaksi secara real-time. Meskipun standar perangkat keras yang lebih tinggi dapat meningkatkan kecepatan pembuatan bukti untuk sesuai dengan kecepatan eksekusi transaksi, namun hal ini berarti menjalankan validator memerlukan lingkungan komputasi yang tinggi. Idealnya, siapa pun harus dapat menjalankan Node untuk memastikan keamanan rantai, namun saat ini ZK belum mencapai tingkat ini.

Terakhir, ZK Rollups didasarkan pada matematika dan kriptografi yang sangat kompleks, kompleksitas ini melebihi cakupan bukti penipuan dan pertanyaan protokol. Oleh karena itu, sebelum dapat digunakan secara aman untuk produksi, sistem ZK perlu diuji secara luas.

Arbitrum sedang mengejar protokol hibrida yang menggabungkan metode ZK dan Optimistic sebagai tujuan akhirnya. Protokol ini beroperasi terutama sebagai Optimistic Rollup, hanya menghasilkan bukti ZK ketika penarikan cepat diperlukan. Ini sangat berguna untuk skenario di mana dana perlu segera diseimbangkan di antara pertukaran atau cross-chain bridges, dan juga membantu mencapai interoperabilitas antar rantai.

Secara keseluruhan, saat ini metode Optimistic Rollup tampaknya efektif, sambil mengadopsi ZK sebagai solusi campuran. Namun, dengan terus meningkatnya biaya dan kecepatan pembuatan bukti ZK, lebih banyak Optimistic Rollups di masa depan mungkin akan mempertimbangkan beralih ke ZK dengan serius.

5.4. Apakah bukti penipuan hanya berlaku untuk Rollup?

Kami telah mempelajari Optimistic Rollups Ethereum dan mekanisme bukti penipuan. Jadi, apa lagi aplikasi lain dari bukti penipuan ini?

Stakeprotokol lagi bukti penipuan dapat digunakan secara aktif dalam protokol stake. Kami menggunakan Eigenlayer sebagai contoh, ini adalah layanan stake yang representatif di jaringan Ether.

Eigenlayer adalah layanan yang memungkinkan keamanan jaringan Ethereum dengan staking ETH. Dalam Eigenlayer, operator dapat menyimpan ETH atau LST pengguna melalui kontrak delegasi di dalam Eigenlayer dan berpartisipasi dalam verifikasi dengan memilih beberapa AVS (Active Verification Service). Melalui Eigenlayer, protokol dapat dengan mudah membangun AVS dan mengurangi biaya awal untuk mempertahankan validator.

Seperti blockchain lainnya, AVS akan memberikan imbalan kepada operator yang berhasil diverifikasi dan harus menghukum mereka ketika melakukan tindakan jahat. Inilah tempat di mana bukti penipuan dapat digunakan dalam proses slashing.

Contoh pemotongan AVS dari Eigenlayer GitHub (https://github.com/Layr-Labs/eigenlayer-contracts/blob/d3730b5dd1b94d5e676e0c7a00a031574263c2c3/docs/experimental/AVS-Guide.md)

Sebagai contoh, menggunakan AVS jembatan. Prasyarat dari AVS jembatan adalah bahwa dana pengguna harus dipindahkan dengan benar ke rantai sasaran, dan operator yang memanipulasi transaksi dengan jahat harus mengalami slashing. Jika manipulasi semacam itu terjadi, penantang yang menemukan perilaku yang tidak pantas dapat membuat penantangan dengan bukti penipuan dalam kontrak penyelesaian sengketa, mengklaim bahwa operator melakukan tindakan yang tidak pantas selama operasi jembatan. Jika bukti penipuan dianggap valid, AVS dapat memanggil kontrak slashing di Eigenlayer, dan menghentikan semua insentif operator untuk sementara.

Meskipun fitur slashing ini belum diimplementasikan di Eigenlayer, mereka baru-baru ini mengumumkan model keamanan bersama, yang direncanakan akan disertakan dalam versi berikutnya. Ini akan memungkinkan bukti penipuan untuk digunakan dalam slashing.

Lapisan Ketersediaan Data** **bukti penipuan juga dapat digunakan untuk lapisan Ketersediaan Data (DA). Salah satu contoh representatif adalah bukti penipuan yang diajukan dan diimplementasikan oleh Celestia. Celestia memiliki teknologi yang memungkinkan light node untuk memverifikasi apakah data disimpan dengan benar berdasarkan sampel ketersediaan data. Mari kita memahami konsep ini dengan seksama.

light client seharusnya dapat memverifikasi suatu Blok tanpa harus mengunduh semua data light client dan memeriksa apakah Blok tersebut mendapat pengakuan dari sebagian besar (lebih dari 67%) validator. Namun, light client sulit untuk memverifikasi tanda tangan semua validator untuk setiap Blok, dan hal ini hampir tidak mungkin seiring dengan peningkatan jumlah validator.

Dalam hal ini, Celestia mengusulkan konsep menarik. Di Celestia, bahkan jika sebagian besar validator bersifat jahat, ia mengusulkan metode yang memungkinkan Full Node jujur tunggal memberitahukan light client untuk menolak Blok yang cacat. Full Node jujur tunggal ini dapat menjamin 'kejujuran'nya melalui bukti penipuan.

Di Celestia, bukti penipuan memiliki dua jenis:

Bukti penipuan perubahan status

Pertama-tama, prinsip kerja bukti penipuan data adalah sebagai berikut: Celestia memungkinkan light node untuk memverifikasi validator tanpa harus langsung mengunduh semua data di dalam blok. Untuk mencapai hal ini, Celestia menggunakan teknologi yang disebut Data Availability Sampling (DAS).

Sampel Ketersediaan Data Celestia | Sumber: Dokumen Celestia

Validator Celestia mengorganisir struktur data transaksi menjadi matriks k x k, kemudian memperluasnya menjadi matriks 2k x 2k menggunakan teknik yang disebut 2D Reed-Solomon encoding. Mereka kemudian menghitung total 4k Merkle Root dari setiap baris dan kolom, dan hasil hash dari Merkle Root ini dimasukkan ke dalam Header Blok dan disebarluaskan.

Hanya dengan informasi Merkle Root di Header Blok, light node dapat memverifikasi apakah validator Celestia memiliki data yang benar. light node meminta data dari titik acak dalam matriks 2k x 2k, sambil mendapatkan Merkle Root dari baris dan kolom yang sesuai dari validator. Jika data ini dapat diverifikasi dengan nilai di Header Blok, maka dapat dipercayai bahwa validator ini memiliki data yang benar.

Namun, ada faktor pertimbangan penting: apa yang terjadi jika validator dengan sengaja melakukan encoding Reed-Solomon yang buruk? Celestia mengatasi masalah ini dengan menerapkan mekanisme yang disebut 'bukti penipuan' (proof of fraud). Jika Full Node Celestia menemukan encoding yang salah selama proses pemulihan Blok, maka akan menghasilkan bukti penipuan yang berisi tinggi Blok, bagian encoding yang salah, dan bukti kegagalan, serta menyebarkannya ke light node. Light node akan memverifikasi bukti tersebut untuk mengkonfirmasi bahwa data benar-benar terjadi kesalahan encoding, sehingga menghentikan penggunaan data yang salah.

Selain itu, Celestia juga mengusulkan mekanisme bukti penipuan transisi status.

Arsitektur Celestia Blok | Sumber: Contribution DAO Blog

Struktur Blok Celestia mencakup data pelacakan transaksi pada interval waktu tertentu. Hal ini memungkinkan Full Node untuk dengan mudah membangun bukti penipuan, sementara light node dapat mendeteksi transisi status yang tidak benar tanpa harus mengeksekusi seluruh Blok. Namun, karena masalah kompleksitas, mekanisme ini belum diimplementasikan di Celestia Mainnet.

Mengingatkan bahwa bukti penipuan dalam lapisan ketersediaan data dapat menyaring data yang tidak benar dan transisi status tanpa bergantung pada Konsensus.

Pembelajaran Mesin Kecerdasan buatan dan blockchain menjadi topik populer pada tahun 2024, dengan banyak penelitian dan pengembangan di bidang ini. Salah satu aspek yang paling mencolok adalah penggabungan blockchain dengan pembelajaran mesin.

Alasan utama mengapa pembelajaran mesin diterapkan pada blockchain adalah sebagai berikut:

Keandalan Data：Blokchain mengelola data secara Desentralisasi, semua transaksi tercatat secara terbuka dan transparan. Jika model pembelajaran mesin belajar dari data Blokchain, sumber datanya dapat diandalkan dan mengurangi kemungkinan pemalsuan.
Keterbukaan dan Verifikasi Model：Ketika model pembelajaran mesin dijalankan di Blok-on-chain, pembaruan dan hasil model akan dicatat on-chain, sehingga dapat diverifikasi. Ini mencegah manipulasi atau bias hasil yang mungkin terjadi di lingkungan terpusat.

Faktor kunci di sini adalah memverifikasi apakah model pembelajaran mesin telah dilatih dengan benar. Namun, komputasi pembelajaran mesin sangatlah padat, yang membuatnya hampir tidak mungkin untuk sepenuhnya melaksanakan komputasi ini di lingkungan on-chain Blok. Oleh karena itu, muncul kerangka seperti opML dan zkML untuk efektif memverifikasi pelatihan model pembelajaran mesin di lingkungan Blok. opML mengadopsi pendekatan optimis untuk pelatihan model, mencatat hasilnya on-chain Blok, dan memperbaiki kesalahan melalui mekanisme pertanyaan.

Mari kita teliti lebih detail metode yang diusulkan oleh ORA, sebuah proyek yang menyediakan infrastruktur kecerdasan buatan di blockchain. Proses tantangan opML mirip dengan tantangan rollup, terdiri dari tiga komponen kunci berikut:

bukti penipuanVirtual Machine（Fraud Proof VM）：Virtual Machine ini melakukan inferensi pembelajaran mesin, fungsinya mirip dengan WAVM di Arbitrum atau Cannon di Optimism.
opML Smart Contract: Kontrak ini memvalidasi bukti penipuan, mirip dengan kontrak MIPS.sol di Optimism.
Permainan Verifikasi: Validator yang mempertanyakan berinteraksi dengan server menggunakan metode biner untuk mengidentifikasi langkah kesalahan tunggal di dalam Mesin Virtual, kemudian menghasilkan bukti penipuan untuk langkah tersebut dan mengirimkannya ke kontrak opML.

Permainan Verifikasi di ORA opML | Sumber: Dokumen ORA

Dengan mekanisme ini bukti penipuan, opML menggunakan keamanan dan kepercayaan blockchain, sambil menyediakan lingkungan yang efisien biaya untuk pelatihan dan validasi model pembelajaran mesin.

6. Kesimpulan

Optimistic Rollup berupaya keras untuk meningkatkan bukti penipuan dan mempertanyakan protokol untuk mewarisi lebih banyak keamanan Ethereum dan menciptakan rantai dengan kepercayaan yang lebih sedikit. Arbitrum diperkirakan akan mencapai Fase 2 melalui BoLD pada akhir tahun ini, dan Optimisme juga bekerja menuju Fase 2, mengandalkan game V2 yang kontroversial dan mekanisme multi-bukti. Pada tahun depan, pengguna Optimistic Rollup akan dapat berinteraksi dengan jaringan dengan keamanan yang lebih besar tanpa khawatir bahwa "Rollup dapat mengambil dana mereka." Selain itu, Vitalik menyebutkan di blognya bahwa jumlah rollup di Fase 1 ke atas diperkirakan akan meningkat juga.

Namun, setiap protokol masih memiliki ruang untuk perbaikan, banyak aspek yang dapat ditingkatkan dengan bukti penipuan ZK. Kroma telah memperkuat protokolnya dengan bukti penipuan ZK, sementara protokol lain seperti Arbitrum, Optimism, dan Cartesi juga dapat mempertahankan cara yang lebih aman dan terdesentralisasi dengan memanfaatkan bukti penipuan ZK.

Dalam bidang bukti penipuan, tidak hanya Rollup tetapi juga protokol lain sedang mengalokasikan sumber daya penelitian yang besar. Dalam kombinasi dengan ZK, bukti penipuan dapat membantu membangun arsitektur Blockchain dengan kepercayaan minimal yang membutuhkan 'hanya satu partisipan yang jujur', dan dampaknya akan menjadi kenyataan yang kita rasakan.

7. Referensi

(https://l2beat.com/scaling/summary)[L2Beat]

bukti penipuan战争 | Luca Donnoh di L2Beat

Dokumen Optimism 文

BoLD: Penyelesaian Sengketa Cepat dan Biaya Rendah

BoLD 的经济学

Mengapa periode tantangan Rollup optimis adalah 7 hari? | Kelvin Fichter di OP Labs

bukti penipuan已崩溃 | Gabriel Coutinho de Paula di Cartesi

Perjalanan Waktu Optimis | Yoav Weiss

Pengantar Tentang Tantangan Pertama yang Berhasil di Kroma Mainnet

Memahami Kemajuan Desentralisasi Baseline | OP Labs

Serangan sensor yang tidak dapat diatribusikan terhadap protokol Layer2 berbasis bukti penipuan

Kerangka Audit OP Labs

无信任的推导 | Kroma

介绍 OP Succinct: bukti validitas lengkap di atas tumpukan OP | Succinct

Pernyataan:

Artikel ini adalah reprinted dari [research.2077], semua hak cipta dimiliki oleh pemilik asli [sm-stack dan BTC Penguin]. Jika Anda memiliki keberatan terhadap penggandaan ini, silakan hubungi tim Gate Learn, mereka akan menanganinya dengan segera.
Pernyataan Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini hanya mewakili pandangan pribadi penulis dan tidak merupakan saran investasi apa pun.
Tim Gate Learn akan menerjemahkan artikel ke dalam bahasa lain. Kecuali ada instruksi lain, dilarang menyalin, mendistribusikan, atau menjiplak artikel terjemahan.