Tiga atribut inti dari blockchain adalah desentralisasi, keamanan, dan skalabilitas. Menurut teori trilema blockchain, sebuah arsitektur blockchain hanya dapat menerapkan dua di antaranya. Ethereum dirancang dengan memperhatikan desentralisasi dan keamanan dan oleh karena itu kurang baik dalam hal skalabilitas. Saat ini, Ethereum memproses lebih dari 1 juta transaksi per hari, yang dapat menyebabkan biaya transaksi tinggi dan meningkatkan kebutuhan akan solusi scaling Ethereum.
Ada beberapa jenis solusi scaling Ethereum yang berbeda, masing-masing dengan kompromi dan model keamanannya sendiri, termasuk sharding Layer 1, saluran keadaan Layer 2, Plasma, sidechain, Rollups, dan Validium. Karena teknologi sharding lambat berevolusi dan kompleks untuk diimplementasikan, serta sidechain dan Validium tidak dapat mewarisi keamanan dan ketersediaan data dari Ethereum. Secara ringkas, ekosistem Ethereum saat ini terutama menggunakan solusi scaling Rollups.
Sejauh ini, Beosin telah menjadi mitra keamanan dari Layer2 ETH seperti Manta Network dan StarkNet. Dalam audit sebelumnya, sejumlah blockchain terkemuka telah lulus audit keamanan rantai Beosin, termasuk Jaringan Ronin, Jaringan Manta, Rantai Merlin, Clover, Rantai Self, Jaringan Crust, dll. Beosin kini merilis solusi audit untuk ETH Layer2 untuk memberikan layanan audit keamanan komprehensif bagi ekosistem ETH Layer2.
ETH Layer2 menggunakan Rollups untuk mengemas ratusan transaksi menjadi satu pengiriman ke Ethereum mainnet, sehingga biaya transaksi akan dibagi ke semua pengguna Rollup, mengurangi biaya per pengguna. Data transaksi di Rollups dikirimkan ke Layer1, tetapi eksekusinya dilakukan secara independen oleh Rollups. Dengan mengirimkan data transaksi ke Layer1, Rollups dapat mewarisi keamanan Ethereum karena begitu data diunggah ke Layer1, pembatalan transaksi Rollups memerlukan data tersebut untuk dibatalkan di Layer1.
Saat ini, Rollups dapat diimplementasikan dengan dua cara utama:
Optimistic Rollups: Menggunakan insentif ekonomi dan teori permainan untuk memverifikasi transaksi, seperti Arbitrum, Base, OP, Blast, dll.
Zero-Knowledge Rollups: Gunakan bukti zero pengetahuan untuk keamanan dan privasi, seperti Scroll, Linea, zkSync, StarkNet, dll.
Optimistic Rollups adalah cara untuk melakukan skala Ethereum dengan memindahkan komputasi dan penyimpanan status di luar rantai. Ini menjalankan transaksi di luar rantai, tetapi mempublikasikan data transaksi ke mainnet sebagai calldata atau blob.
Optimistic Rollups mendeploy kontrak pintar di Ethereum, yang disebut kontrak Rollup, yang mengelola status Rollup, melacak saldo pengguna, dan menangani deposit, penarikan, dan pemulihan sengketa. Transaksi dikumpulkan dan diringkas di luar jaringan oleh pengurut dan beberapa transaksi dikemas ke dalam blok Rollup yang berisi ringkasan dan bukti kriptografi dari keadaan akun baru (Merkle root). Kemudian pengurut mengirimkan blok Rollup ke chain utama dengan memberikan Merkle root dan calldata.
Optimistic Rollups dianggap “optimistic” karena mereka mengasumsikan bahwa transaksi off-chain valid dan tidak mempublikasikan bukti keabsahan transaksi batch yang didorong on-chain. Sebaliknya, Optimistic Rollups mengandalkan skema bukti penipuan untuk mendeteksi kasus di mana transaksi dihitung dengan tidak benar. Setelah mengirimkan batch Rollup di Ethereum, ada jendela waktu (disebut periode tantangan) di mana siapa pun dapat menantang hasil transaksi Rollup dengan menghitung bukti penipuan. Bukti penipuan berisi rincian transaksi tertentu yang pemeriksa percayai sebagai penipuan.
Seperti yang ditunjukkan dalam gambar di bawah ini, saat ini periode tantangan untuk sebagian besar Optimistic Rollups adalah 7 hari, dan yang terpendek adalah 1 hari.
Selama periode tantangan, siapa pun dapat menantang hasil transaksi dengan menghitung bukti penipuan. Jika transaksi tidak valid, blok Rollup dibatalkan, penantang diberi hadiah, dan pengurut dihukum.
Jika batch Rollup tetap tidak ditantang setelah periode tantangan (yaitu semua transaksi telah dieksekusi dengan benar), maka dianggap valid dan diterima di Ethereum. Orang lain dapat terus memperluas blok Rollup yang belum dikonfirmasi, tetapi perlu diingat bahwa hasil transaksi akan dibalik jika transaksi dilakukan berdasarkan kesalahan yang sebelumnya dipublikasikan.
Akhirnya, pengguna harus mengirimkan permintaan penarikan ke kontrak Rollup untuk menarik dana dari Layer 2 ke Layer 1. Kontrak akan memverifikasi bahwa pengguna memiliki dana yang cukup di Rollup dan memperbarui saldo mereka di mainchain sesuai.
Dengan konstruksi ekologis dan airdrop, Arbitrum dengan cepat menjadi jaringan paling aktif di ETH Layer2, dengan TVL melebihi $2,7 miliar. Setelah airdrop besar-besaran, tim Arbitrum meluncurkan program Arbitrum Orbit: mendorong pengembang untuk membangun Layer3 menggunakan teknologi terkait Arbitrum. Beosin telah menyelesaikan audit keamanan ArbSwap, Arbipad untuk membantu pengembangan keamanan ekosistem Arbitrum.
Meskipun Optimism kurang aktif secara ekologis dibandingkan dengan Arbitrum, OP Stack, diluncurkan oleh Optimism pada tahun 2023, telah mendapatkan pengakuan luas di industri sebagai solusi lengkap dan layak untuk membangun Layer2 modular. Lebih dari 25 jaringan Layer2 telah dibangun menggunakan OP Stack, termasuk proyek-proyek unggulan seperti Base, Mantle, Manta, OP BNB, dan Celo. DIPX Finance dan Starnet yang dibangun di Optimism telah lolos dari audit keamanan Beosin.
Base adalah jaringan Layer2 yang berbasis pada OP Stack, yang hanya kedua setelah Arbitrum dalam hal aktivitas ekologi dan TVL. Sebelumnya, Beosin telah menganalisis arsitektur Base dan risiko keamanannya secara detail, dan memeriksa Surf Protocol dan EDA untuk membantu pemilik proyek dan pengguna menghindari risiko keamanan.
Blast, pada akhir kompetisi pengembang “Big Bang”-nya, telah melihat TVL-nya melonjak menjadi lebih dari $2 miliar, mengambil tempatnya di sirkuit Layer2. Beosin menganalisis keamanan jaringan Blast sebelum diluncurkan di mainnet. Karena Blast tidak menerapkan bukti penipuan, aset disimpan di dompet multisignature, bukan jembatan Rollup, yang memiliki risiko sentralisasi yang tinggi. Beosin telah mengaudit beberapa proyek ekologis Blast seperti Protokol Wand, Zest, Kalax.
OP Stack, kerangka kerja yang matang untuk Optimistic Rollups, pada dasarnya memecah proses kompleks membangun rantai Optimistic Rollups menjadi proses yang disederhanakan dengan menyediakan seperangkat lengkap komponen perangkat lunak, alat, dan kerangka kerja. Di sini kita mengambil kerangka Op stack sebagai contoh untuk menganalisis arsitektur khas dari Optimism Rollups.
● Node eksekusi: Op-geth adalah klien eksekusi yang diperluas untuk Ethereum yang menangani fungsi-fungsi khusus Layer2, seperti menerima deposit token dari Layer1. Lapisan ini mendefinisikan semua fungsi yang bertanggung jawab untuk melakukan variasi state. Di sini, transisi state dipicu berdasarkan input yang diterima dari node ringkasan (urutan dan validator) melalui API mesin.
● Node Rollup: termasuk sequencer dan validator. Collator bertanggung jawab untuk mengumpulkan transaksi yang diproses dari lapisan 2 dan mempublikasikannya ke Lapisan 1. Sequencer menentukan bagaimana transaksi di rantai Lapisan 2 dikumpulkan dan dipublikasikan. Validator/validator memeriksa validitas transaksi batch dan mengajukan bukti jika ada tindak penipuan yang terdeteksi.
● Bukti Penipuan: Cannon adalah versi yang ditingkatkan dari Geth dan bertanggung jawab untuk menjalankan EVM selama fase deteksi penipuan dan bukti. Pada dasarnya, ini adalah mesin perselisihan on-chain yang berkoordinasi dengan sequentiers dan validator melalui API untuk membuktikan transaksi palsu.
● Komit batch: Sequencers memproses semua transaksi yang telah diproses sekaligus, diverifikasi oleh verifier, dan Sequencers mengirimkan transaksi yang diproses dalam batch ke Layer1.
● Kontrak jembatan: Diterapkan pada Ethereum dan Layer2, memungkinkan pengguna untuk mengirim pesan dan mentransfer aset antara Layer1 dan Layer2.
Dalam arsitektur teknis Optimistic Rollup, penting untuk memastikan keamanan aset pengguna saat berpindah antara L1 dan L2. Berikut ini adalah rincian tentang bagaimana pengguna dapat mengakses aset antara kedua lapisan ini dan bagaimana sistem menjaga integritas dan keamanan transaksi ini.
● Penyeberangan aset ke Rollup: Pengguna menyetor dana ke kontrak jembatan rantai Rollup di Layer1. Kontrak jembatan rantai meneruskan transaksi ke Layer2, di mana jumlah aset yang sama dicetak dan dikirim ke alamat yang dipilih oleh pengguna dalam Optimistic Rollup.
Transaksi yang dihasilkan oleh pengguna, seperti deposit dari Layer1 ke Layer2, biasanya akan dimasukkan dalam antrian sampai siaran ulang mereka ke kontrak Rollup. Namun, untuk menjaga ketahanan terhadap sensor, Optimistic Rollup memungkinkan pengguna untuk mengirimkan transaksi secara langsung ke kontrak Rollup on-chain jika keterlambatan transaksi melebihi waktu maksimum yang diizinkan.
● Menarik aset dari Rollup: Karena mekanisme bukti penipuan, menarik uang dari Optimistic Rollup ke Ethereum lebih rumit. Jika pengguna memulai transaksi Layer2 ke Layer1 untuk menarik dana yang dikelola di Layer1, mereka perlu menunggu akhir periode tantangan, yang biasanya berlangsung sekitar 7 hari.
Ketika pengguna memulai permintaan penarikan di Rollup, transaksi tersebut dimasukkan dalam batch berikutnya dan aset pengguna di Rollup dihancurkan. Setelah batch dipublikasikan di Ethereum, pengguna dapat menghitung bukti Merkle untuk memverifikasi bahwa transaksi keluar mereka termasuk dalam blok. Langkah berikutnya adalah menunggu periode penundaan berakhir untuk menyelesaikan transaksi di Layer1 dan menarik dana ke mainnet.
Untuk menghindari menunggu seminggu sebelum menarik uang dari Ethereum, pengguna Optimistic Rollup dapat meminta uang muka dari penyedia likuiditas (LP), yang mengasumsikan kepemilikan penarikan tertunda dan membayar dana pengguna di Layer1 sebagai imbalan atas biaya. Penyedia likuiditas dapat memverifikasi validitas permintaan penarikan pengguna dengan memeriksa data on-chain sendiri sebelum melepaskan dana. Dengan cara ini, mereka dapat memastikan bahwa transaksi akhirnya akan dikonfirmasi, mencapai kepastian kepercayaan.
Layer2 adalah sistem blockchain lengkap, sehingga audit umum dari rantai publik juga berlaku untuk Optimistic Rollup, sebagaimana dijelaskan dalam lampiran di akhir artikel ini.
Selain itu, karena sifat khususnya, Optimistic Rollup membutuhkan sejumlah audit tambahan:
● Bukti ketersediaan data: Pastikan bahwa data transaksi Layer2 tersedia di Layer1 untuk mencegah kehilangan data.
● Mekanisme sinkronisasi data: Periksa apakah mekanisme sinkronisasi data antara Layer1 dan Layer2 baik dan dapat menangani situasi abnormal seperti pemisahan jaringan.
● Kontrak Bukti Penipuan: Verifikasi bahwa kontrak bukti penipuan diimplementasikan dengan benar.
● Mekanisme periode tantangan: Periksa apakah panjang periode tantangan wajar dan apakah bukti penipuan dapat diselesaikan dalam waktu yang ditentukan.
Proses pengajuan bukti penipuan: Periksa bahwa proses pengajuan bukti penipuan aman.
● Proses Deposit dan Penarikan: Periksa proses deposit dan penarikan dari Layer1 ke Layer2 dan dari Layer2 ke Layer1 untuk memastikan prosesnya aman.
● Pencetakan dan pembakaran aset: Periksa logika pembuatan dan penghancuran aset di Layer2 untuk memastikan korespondensi yang benar dengan aset Layer1.
● Mekanisme penyedia likuiditas: Jika ada mekanisme penyedia likuiditas (LP), perlu untuk memeriksa proses operasi LP dan keamanannya.
Zero-Knowledge (ZK) Rollup adalah Layer2 yang didasarkan pada bukti zero-knowledge. Ini terutama melakukan perhitungan kompleks dan generasi bukti di luar jaringan, memverifikasi bukti di jaringan, dan menyimpan sebagian data untuk memastikan ketersediaan data.
ZK Rollup adalah "solusi penskalaan hibrida" yang merupakan protokol off-chain yang berjalan secara independen tetapi mendapat keamanan dari Ethereum. Secara khusus, jaringan Ethereum memberlakukan validitas pembaruan status pada ZK Rollups dan menjamin ketersediaan data latar belakang setiap kali status Rollup diperbarui. Status Rollup dipertahankan oleh kontrak pintar yang digunakan di jaringan Ethereum. Untuk memperbarui status ini, node ZK Rollups harus menyerahkan bukti validitas untuk verifikasi. Bukti validitas adalah jaminan kriptografi bahwa perubahan keadaan yang diusulkan memang merupakan hasil dari pelaksanaan batch transaksi tertentu. Ini berarti bahwa ZK Rollups hanya perlu memberikan bukti validitas untuk menyelesaikan transaksi di Ethereum, tanpa harus mempublikasikan semua data transaksi.
Tidak ada keterlambatan dalam mentransfer dana dari ZK Rollups ke Ethereum, karena transaksi keluar dieksekusi begitu kontrak ZK Rollups telah memverifikasi bukti keabsahan. Sebaliknya, menarik dana dari Optimistic Rollups menimbulkan keterlambatan karena siapa pun dapat menggunakan bukti penipuan untuk menantang transaksi keluar.
zkSync, solusi L2 yang diluncurkan lima tahun lalu oleh tim Matter Labs, menggunakan teknologi bukti kebenaran nol untuk memungkinkan verifikasi transaksi yang efisien dan telah mengumpulkan lebih dari $200 juta. zkSync adalah salah satu jaringan Layer2 yang paling aktif secara ekologis yang menggunakan ZK Rollups, dan zkSync juga kontroversial. Beosin sebelumnya melakukan audit terhadap proyek DeFi unggulannya, SyncSwap, meliputi kualitas kode, logika kontrak dan keamanan, model operasional, dan lainnya.
StarkNet menggunakan ZK-STARK untuk membangun Layer2 guna meningkatkan kecepatan transaksi dan mengurangi biaya transaksi. StarkNet memiliki mesin virtual asli (Cairo VM) dan bahasa pengembangan Cairo untuk membantu pengembang menulis kontrak pintar dengan lebih aman dan mudah. Beosin telah menjadi mitra keamanan resmi StarkNet, menyelesaikan audit keamanan untuk Option Dance dan Reddio. Pada 13 Agustus 2024, Reddio menutup putaran pendanaan awal yang dipimpin oleh Paradigm untuk membangun jaringan EVM Layer2 paralel yang berkinerja tinggi.
Scroll ditingkatkan oleh teknologi bukti nol pengetahuan, dan perangkat keras mempercepat pembuatan dan verifikasi bukti nol pengetahuan, dengan tujuan mencapai kompatibilitas EVM tingkat bytecode. Ini berarti bahwa pengembang dapat langsung menggunakan alat pengembangan Solidity dan Ethereum terkait untuk membangun kontrak pintar.
Kerangka kerja umum untuk ZK Rollups termasuk kontrak Rollup dan Bridge, collator, aggregator, Repeater, dan jaringan Roller yang menghasilkan bukti nol pengetahuan. Arsitektur spesifik ditunjukkan dalam gambar berikut:
● Kontrak Rollup dan kontrak Jembatan:
Kontrak Rollup bertanggung jawab untuk menyediakan ketersediaan data untuk transaksi Rollup, memverifikasi bukti kebenaran zkEVM, dan memungkinkan pengguna mentransfer aset antara Ethereum dan Rollup. Ia menerima akar status Layer 2 dan blok dari pengumpul, akar status disimpan di dalam status Ethereum, dan data blok layer 2 disimpan sebagai calldata Ethereum.
Kontrak jembatan diterapkan di Ethereum dan Layer2, memungkinkan pengguna untuk mengirim pesan dan mentransfer aset antara Layer1 dan Layer2.
● Pemroses: Pemroses menyediakan antarmuka JSON-RPC dan menerima transaksi Layer2, secara berkala mengambil sekelompok transaksi dari memori pool untuk dieksekusi, menghasilkan blok Layer2 baru dan state roots. Implementasinya biasanya berdasarkan Go-Ethereum (Geth), memastikan kompatibilitas terbaik dan keamanan tertinggi.
● Koordinator: Koordinator akan mendapatkan pemberitahuan ketika kolator menghasilkan blok baru dan menerima jejak eksekusi dari blok tersebut dari kolator. Jejak eksekusi kemudian dikirimkan ke Roller yang dipilih secara acak di jaringan Roller, yang menghasilkan bukti keabsahan.
● Relayer: Pemancar memantau kontrak Rollup dan kontrak jembatan yang diterapkan pada Ethereum dan Layer2. Tanggung jawab utamanya adalah: 1) Melacak ketersediaan data dan validasi blok Layer2 dengan memantau kontrak Rollup; 2) Memantau acara deposit dan penarikan Ethereum dan keterlibatan jembatan Layer2 dan meneruskan pesan ke ujung lainnya.
● Jaringan Roller: Roller dalam jaringan Roller bertindak sebagai pembuktian dan bertanggung jawab atas pembuatan bukti keabsahan untuk ZK Rollup. Jejak eksekusi blok pertama diterima dari koordinator, diubah menjadi saksi sirkuit, kemudian bukti dibuat untuk setiap zkevm menggunakan percepatan hardware, dan akhirnya agregasi bukti digunakan untuk menggabungkan beberapa bukti menjadi satu bukti.
Dalam arsitektur teknis ZK Rollups, penting untuk memastikan keamanan aset pengguna selama transfer antara L1 dan L2. Berikut ini rincian cara pengguna dapat mengakses aset antara dua lapisan dan bagaimana sistem menjaga integritas dan keamanan transaksi ini.
● Asset bridging ke Rollup: Pengguna memasuki Rollup dengan mendepositkan token ke kontrak ZK Rollups yang diterapkan pada lapisan jaringan. Transaksi ini perlu diserahkan ke kontrak Rollup oleh pihak proyek.
Jika antrian deposit yang tertunda mulai penuh, operator ZK Rollups akan menerima transaksi deposit ini dan mengirimkannya ke kontrak Rollup. Setelah dana tersebut didepositkan di Rollup, pengguna dapat memulai pemrosesan transaksi.
Pengguna dapat memverifikasi saldo di Rollup dengan menghash akun mereka, mengirimkan nilai hash ke kontrak Rollup, dan memberikan bukti Merkle yang diverifikasi terhadap root state saat ini.
● Penarikan aset dari Rollup: Pengguna memulai transaksi keluar, mengirim aset mereka di Rollup ke akun yang ditentukan untuk dihancurkan. Jika operator menambahkan transaksi ke batch berikutnya, pengguna dapat mengajukan permintaan penarikan ke kontrak on-chain. Permintaan penarikan termasuk:
Bukti Merkle, yang membuktikan bahwa transaksi pengguna ditambahkan ke akun yang dihancurkan dalam batch transaksi
Data transaksi
Batch root
Alamat jaringan Layer1 untuk menerima dana deposit
Kontrak Rollup menghash data transaksi, memeriksa apakah batch root ada, dan menggunakan bukti Merkle untuk memeriksa apakah hash transaksi adalah bagian dari batch root. Kontrak mengeksekusi transaksi keluar dan mengirim dana ke alamat di jaringan Layer1 yang dipilih oleh pengguna.
Layer 2 adalah sistem blockchain lengkap, sehingga item audit umum untuk blockchain juga berlaku untuk ZK Rollup, seperti yang dijelaskan di lampiran pada akhir artikel ini.
Selain itu, karena sifat khususnya, ZK Rollup memerlukan beberapa audit tambahan untuk dilakukan:
● Bukti keamanan sistem: Periksa keamanan dan kebenaran dari skema bukti zero pengetahuan yang digunakan (misalnya Groth16, Plonk, Halo2, zk-STARK, dll).
● Keamanan sirkuit: Periksa kerentanan yang mungkin terdapat pada desain sirkuit dan implementasinya, terutama meliputi hal-hal berikut:
Rangkaian yang kurang terbatas
Sirkuit Terlalu Terbatas
Sirkuit Nondeterministik
Aritmatika Over/Under Flows Aritmatika over/under flows
Panjang Bit yang Tidak Cocok
Input Publik yang Tidak Digunakan Dioptimalkan
Frozen Heart: Pengecoran Bukti Nol Pengetahuan
Kebocoran Pengaturan Terpercaya
Assigned but not Constrained
Penggunaan Komponen yang Tidak Aman
Presisi Variabel
● Pembuatan dan validasi bukti: Tinjau proses pembuatan dan validasi bukti untuk memastikan efisiensi dan keamanannya.
● Bukti ketersediaan data: Pastikan bahwa data transaksi Layer2 tersedia di Layer1 untuk mencegah kehilangan data.
● Mekanisme sinkronisasi data: Periksa apakah mekanisme sinkronisasi data antara Layer1 dan Layer2 berfungsi dengan baik dan dapat mengatasi situasi abnormal seperti pemisahan jaringan.
Proses deposit dan penarikan: Periksa proses deposit dan penarikan dari Layer1 ke Layer2 dan dari Layer2 ke Layer1 untuk memastikan prosesnya aman.
● Pencetakan dan pembakaran aset: Periksa logika pencetakan dan penghancuran aset di Layer2 untuk memastikan korespondensi yang benar dengan aset Layer1.
● Memindai dependensi eksternal dan kerentanan yang diketahui: ZK Rollup sering sangat bergantung pada repositori kriptografi dan matematika atau alat pihak ketiga dan harus benar-benar memeriksa keamanan ketergantungan mereka untuk memindai dan memvalidasi kerentanan yang diketahui.
Audit item Umum Blockchain & Layer2:
● Overflow integer: Periksa overflow integer dan underflow integer
● Loop: Periksa loop dari program untuk melihat apakah kondisinya masuk akal
● Panggilan rekursif tak terbatas: Periksa apakah kondisi keluar dari panggilan rekursif programnya wajar
● Kondisi perlombaan: Memeriksa akses ke sumber daya bersama dalam keadaan konkuren
● Exception crash: Periksa kode pelemparan pengecualian yang menyebabkan program keluar secara aktif
● Bagi dengan 0 kerentanan: Periksa apakah ada kasus membagi dengan 0
● Konversi tipe: Periksa apakah konversi tipe sudah benar dan apakah informasi penting hilang selama konversi
● Array out of bounds: Memeriksa akses ke elemen di luar batas array
● Kerentanan Deserialisasi: Periksa masalah saat deserialisasi
● Keamanan implementasi fungsi: Periksa apakah implementasi antarmuka RPC memiliki risiko keamanan dan konsisten dengan desain fungsional antarmuka RPC
● Apakah Pengaturan Izin antarmuka RPC yang sensitif masuk akal: Periksa pengaturan izin akses antarmuka RPC yang sensitif
● Mekanisme transmisi terenkripsi: Periksa apakah protokol transmisi terenkripsi, seperti TLS, digunakan
● Meminta pemformatan data parsing: Memeriksa proses pemformatan data permintaan
● Serangan buka kunci dompet: Ketika sebuah node membuka dompetnya, ia diminta oleh RPC untuk mencuri dana
● Keamanan Web tradisional: Periksa kerentanan berikut: Cross-site scripting (XSS)/injeksi templat/kerentanan komponen pihak ketiga/kontaminasi parameter HTTP/injeksi SQL/Injeksi entitas XXE/kerentanan deserialisasi/kerentanan SSRF/Injeksi kode/penyertaan file lokal/Penyertaan file jarak jauh/injeksi eksekusi perintah dan kerentanan tradisional lainnya
● Mekanisme otentikasi dan identifikasi identitas node jaringan: periksa apakah ada mekanisme identifikasi identitas node, mekanisme identifikasi identitas node dapat dihindari
● Kontaminasi tabel routing: Periksa apakah tabel routing dapat dimasukkan atau ditimpa secara sembarangan
● Algoritma penemuan node: Periksa apakah algoritma penemuan node seimbang dan tidak dapat diprediksi, misalnya, algoritma jarak tidak seimbang
● Audit Penggunaan Koneksi: Periksa apakah batas dan pengelolaan jumlah node yang terhubung ke jaringan p2p masuk akal
● Serangan Gerhana Matahari: Menilai biaya dan bahaya dari serangan gerhana matahari, memberikan analisis kuantitatif jika diperlukan
● Serangan Sybil: Mengevaluasi mekanisme konsensus pemungutan suara dan menganalisis strategi pemeriksaan kelayakan pemilih
● Serangan menguping: Periksa apakah protokol komunikasi mengungkapkan privasi
● Serangan alien: Mengevaluasi apakah node dapat mengenali node rantai yang sama jenisnya
● Pembajakan waktu: Periksa mekanisme perhitungan waktu jaringan suatu node
● Serangan kelelahan memori: Periksa konsumsi memori yang besar
● Serangan kehabisan ruang hard disk: Periksa di mana file-file besar disimpan
● serangan tekanan soket: Periksa kebijakan batas jumlah tautan
● Serangan kelelahan penanganan kernel: Periksa keterbatasan pada pembuatan penanganan kernel, seperti penanganan file
● Kebocoran memori persisten: Periksa kebocoran memori
● Keamanan algoritma hash: Periksa keamanan tabrakan algoritma hash
● Keamanan algoritma tanda tangan digital: Periksa keamanan algoritma tanda tangan dan implementasi algoritma
● Keamanan algoritma enkripsi: Periksa keamanan algoritma enkripsi dan implementasi algoritma
● Keamanan generator angka acak: Periksa apakah algoritma pembangkitan angka acak kunci wajar
● Keamanan implementasi BFT: Mengevaluasi keamanan implementasi algoritma BFT
● Aturan seleksi fork: Periksa aturan seleksi fork untuk memastikan keamanan
● Uji tingkat sentralisasi: Identifikasi apakah ada desain yang terlalu terpusat dalam desain sistem
● Audit insentif: Menilai dampak insentif terhadap keamanan
● Serangan double-spending: Periksa apakah konsensus dapat melindungi dari serangan double-spending
● Audit Serangan MEV: Meneliti dampak MEV dari node paket blok pada keadilan rantai
● Audit proses sinkronisasi blok: Memeriksa masalah keamanan selama sinkronisasi
● Audit proses parsing format blok: Memeriksa masalah keamanan selama parsing format, seperti kesalahan parsing yang menyebabkan crash
● Audit Proses Generasi Blok: Periksa isu keamanan dalam proses generasi blok, termasuk apakah akar pohon Merkle dibangun dengan cara yang masuk akal
● Audit proses verifikasi blok: Periksa apakah item tanda tangan blok dan logika verifikasinya cukup
● Audit logika validasi blok: Periksa apakah algoritma dan implementasi validasi blok masuk akal
● Tabrakan hash blok: Periksa bagaimana tabrakan hash blok dibangun dan apakah tabrakan tersebut ditangani dengan wajar
● Batas sumber daya pemrosesan blok: Periksa apakah kolam blok yatim, komputasi verifikasi, pengalamatan hard disk, dan batasan sumber daya lainnya wajar
● Audit proses sinkronisasi transaksi: Memeriksa masalah keamanan dalam proses sinkronisasi
● Tandingan hash transaksi: Teliti bagaimana tandingan hash transaksi dibangun dan bagaimana mereka ditangani
● Penguraian format transaksi: Periksa masalah keamanan selama penguraian format, seperti kesalahan penguraian yang menyebabkan kerusakan
● Pengecekan validitas transaksi: Periksa apakah item tanda tangan dari setiap jenis transaksi dan logika verifikasi cukup
● Batas sumber daya pemrosesan transaksi: Periksa apakah batasan sumber daya seperti kolam transaksi, komputasi verifikasi, dan addressing hard disk adalah wajar
● Serangan kecacatan transaksi: Apakah transaksi dapat mengubah bidang internal (seperti ScriptSig) untuk mengubah hash transaksi tanpa mempengaruhi validitas transaksi
● Audit serangan replay transaksi: Memeriksa deteksi sistem replay transaksi
● Pemeriksaan bytecode kontrak: Periksa keamanan proses verifikasi kontrak mesin virtual, seperti integer overflow dan dead loop
● Eksekusi bytecode kontrak: Periksa keamanan proses eksekusi bytecode mesin virtual, seperti integer overflow, dead loop, dan sebagainya
● Model gas: Periksa apakah biaya untuk setiap operasi atom dari pemrosesan transaksi / pelaksanaan kontrak sebanding dengan konsumsi sumber daya
● Integritas log: Periksa apakah informasi kunci tercatat
● Keamanan log: Periksa apakah penanganan log yang tidak sesuai menyebabkan masalah keamanan, seperti overflow integer
● Log berisi informasi privasi: Periksa apakah log berisi informasi privasi seperti kunci
● Penyimpanan log: Periksa apakah terdapat konten berlebihan yang dicatat dalam log, yang menghabiskan sumber daya node
● Keamanan rantai pasokan kode Node: Periksa semua pustaka, komponen, dan versi kerangka rantai publik pihak ketiga untuk masalah yang diketahui
Tiga atribut inti dari blockchain adalah desentralisasi, keamanan, dan skalabilitas. Menurut teori trilema blockchain, sebuah arsitektur blockchain hanya dapat menerapkan dua di antaranya. Ethereum dirancang dengan memperhatikan desentralisasi dan keamanan dan oleh karena itu kurang baik dalam hal skalabilitas. Saat ini, Ethereum memproses lebih dari 1 juta transaksi per hari, yang dapat menyebabkan biaya transaksi tinggi dan meningkatkan kebutuhan akan solusi scaling Ethereum.
Ada beberapa jenis solusi scaling Ethereum yang berbeda, masing-masing dengan kompromi dan model keamanannya sendiri, termasuk sharding Layer 1, saluran keadaan Layer 2, Plasma, sidechain, Rollups, dan Validium. Karena teknologi sharding lambat berevolusi dan kompleks untuk diimplementasikan, serta sidechain dan Validium tidak dapat mewarisi keamanan dan ketersediaan data dari Ethereum. Secara ringkas, ekosistem Ethereum saat ini terutama menggunakan solusi scaling Rollups.
Sejauh ini, Beosin telah menjadi mitra keamanan dari Layer2 ETH seperti Manta Network dan StarkNet. Dalam audit sebelumnya, sejumlah blockchain terkemuka telah lulus audit keamanan rantai Beosin, termasuk Jaringan Ronin, Jaringan Manta, Rantai Merlin, Clover, Rantai Self, Jaringan Crust, dll. Beosin kini merilis solusi audit untuk ETH Layer2 untuk memberikan layanan audit keamanan komprehensif bagi ekosistem ETH Layer2.
ETH Layer2 menggunakan Rollups untuk mengemas ratusan transaksi menjadi satu pengiriman ke Ethereum mainnet, sehingga biaya transaksi akan dibagi ke semua pengguna Rollup, mengurangi biaya per pengguna. Data transaksi di Rollups dikirimkan ke Layer1, tetapi eksekusinya dilakukan secara independen oleh Rollups. Dengan mengirimkan data transaksi ke Layer1, Rollups dapat mewarisi keamanan Ethereum karena begitu data diunggah ke Layer1, pembatalan transaksi Rollups memerlukan data tersebut untuk dibatalkan di Layer1.
Saat ini, Rollups dapat diimplementasikan dengan dua cara utama:
Optimistic Rollups: Menggunakan insentif ekonomi dan teori permainan untuk memverifikasi transaksi, seperti Arbitrum, Base, OP, Blast, dll.
Zero-Knowledge Rollups: Gunakan bukti zero pengetahuan untuk keamanan dan privasi, seperti Scroll, Linea, zkSync, StarkNet, dll.
Optimistic Rollups adalah cara untuk melakukan skala Ethereum dengan memindahkan komputasi dan penyimpanan status di luar rantai. Ini menjalankan transaksi di luar rantai, tetapi mempublikasikan data transaksi ke mainnet sebagai calldata atau blob.
Optimistic Rollups mendeploy kontrak pintar di Ethereum, yang disebut kontrak Rollup, yang mengelola status Rollup, melacak saldo pengguna, dan menangani deposit, penarikan, dan pemulihan sengketa. Transaksi dikumpulkan dan diringkas di luar jaringan oleh pengurut dan beberapa transaksi dikemas ke dalam blok Rollup yang berisi ringkasan dan bukti kriptografi dari keadaan akun baru (Merkle root). Kemudian pengurut mengirimkan blok Rollup ke chain utama dengan memberikan Merkle root dan calldata.
Optimistic Rollups dianggap “optimistic” karena mereka mengasumsikan bahwa transaksi off-chain valid dan tidak mempublikasikan bukti keabsahan transaksi batch yang didorong on-chain. Sebaliknya, Optimistic Rollups mengandalkan skema bukti penipuan untuk mendeteksi kasus di mana transaksi dihitung dengan tidak benar. Setelah mengirimkan batch Rollup di Ethereum, ada jendela waktu (disebut periode tantangan) di mana siapa pun dapat menantang hasil transaksi Rollup dengan menghitung bukti penipuan. Bukti penipuan berisi rincian transaksi tertentu yang pemeriksa percayai sebagai penipuan.
Seperti yang ditunjukkan dalam gambar di bawah ini, saat ini periode tantangan untuk sebagian besar Optimistic Rollups adalah 7 hari, dan yang terpendek adalah 1 hari.
Selama periode tantangan, siapa pun dapat menantang hasil transaksi dengan menghitung bukti penipuan. Jika transaksi tidak valid, blok Rollup dibatalkan, penantang diberi hadiah, dan pengurut dihukum.
Jika batch Rollup tetap tidak ditantang setelah periode tantangan (yaitu semua transaksi telah dieksekusi dengan benar), maka dianggap valid dan diterima di Ethereum. Orang lain dapat terus memperluas blok Rollup yang belum dikonfirmasi, tetapi perlu diingat bahwa hasil transaksi akan dibalik jika transaksi dilakukan berdasarkan kesalahan yang sebelumnya dipublikasikan.
Akhirnya, pengguna harus mengirimkan permintaan penarikan ke kontrak Rollup untuk menarik dana dari Layer 2 ke Layer 1. Kontrak akan memverifikasi bahwa pengguna memiliki dana yang cukup di Rollup dan memperbarui saldo mereka di mainchain sesuai.
Dengan konstruksi ekologis dan airdrop, Arbitrum dengan cepat menjadi jaringan paling aktif di ETH Layer2, dengan TVL melebihi $2,7 miliar. Setelah airdrop besar-besaran, tim Arbitrum meluncurkan program Arbitrum Orbit: mendorong pengembang untuk membangun Layer3 menggunakan teknologi terkait Arbitrum. Beosin telah menyelesaikan audit keamanan ArbSwap, Arbipad untuk membantu pengembangan keamanan ekosistem Arbitrum.
Meskipun Optimism kurang aktif secara ekologis dibandingkan dengan Arbitrum, OP Stack, diluncurkan oleh Optimism pada tahun 2023, telah mendapatkan pengakuan luas di industri sebagai solusi lengkap dan layak untuk membangun Layer2 modular. Lebih dari 25 jaringan Layer2 telah dibangun menggunakan OP Stack, termasuk proyek-proyek unggulan seperti Base, Mantle, Manta, OP BNB, dan Celo. DIPX Finance dan Starnet yang dibangun di Optimism telah lolos dari audit keamanan Beosin.
Base adalah jaringan Layer2 yang berbasis pada OP Stack, yang hanya kedua setelah Arbitrum dalam hal aktivitas ekologi dan TVL. Sebelumnya, Beosin telah menganalisis arsitektur Base dan risiko keamanannya secara detail, dan memeriksa Surf Protocol dan EDA untuk membantu pemilik proyek dan pengguna menghindari risiko keamanan.
Blast, pada akhir kompetisi pengembang “Big Bang”-nya, telah melihat TVL-nya melonjak menjadi lebih dari $2 miliar, mengambil tempatnya di sirkuit Layer2. Beosin menganalisis keamanan jaringan Blast sebelum diluncurkan di mainnet. Karena Blast tidak menerapkan bukti penipuan, aset disimpan di dompet multisignature, bukan jembatan Rollup, yang memiliki risiko sentralisasi yang tinggi. Beosin telah mengaudit beberapa proyek ekologis Blast seperti Protokol Wand, Zest, Kalax.
OP Stack, kerangka kerja yang matang untuk Optimistic Rollups, pada dasarnya memecah proses kompleks membangun rantai Optimistic Rollups menjadi proses yang disederhanakan dengan menyediakan seperangkat lengkap komponen perangkat lunak, alat, dan kerangka kerja. Di sini kita mengambil kerangka Op stack sebagai contoh untuk menganalisis arsitektur khas dari Optimism Rollups.
● Node eksekusi: Op-geth adalah klien eksekusi yang diperluas untuk Ethereum yang menangani fungsi-fungsi khusus Layer2, seperti menerima deposit token dari Layer1. Lapisan ini mendefinisikan semua fungsi yang bertanggung jawab untuk melakukan variasi state. Di sini, transisi state dipicu berdasarkan input yang diterima dari node ringkasan (urutan dan validator) melalui API mesin.
● Node Rollup: termasuk sequencer dan validator. Collator bertanggung jawab untuk mengumpulkan transaksi yang diproses dari lapisan 2 dan mempublikasikannya ke Lapisan 1. Sequencer menentukan bagaimana transaksi di rantai Lapisan 2 dikumpulkan dan dipublikasikan. Validator/validator memeriksa validitas transaksi batch dan mengajukan bukti jika ada tindak penipuan yang terdeteksi.
● Bukti Penipuan: Cannon adalah versi yang ditingkatkan dari Geth dan bertanggung jawab untuk menjalankan EVM selama fase deteksi penipuan dan bukti. Pada dasarnya, ini adalah mesin perselisihan on-chain yang berkoordinasi dengan sequentiers dan validator melalui API untuk membuktikan transaksi palsu.
● Komit batch: Sequencers memproses semua transaksi yang telah diproses sekaligus, diverifikasi oleh verifier, dan Sequencers mengirimkan transaksi yang diproses dalam batch ke Layer1.
● Kontrak jembatan: Diterapkan pada Ethereum dan Layer2, memungkinkan pengguna untuk mengirim pesan dan mentransfer aset antara Layer1 dan Layer2.
Dalam arsitektur teknis Optimistic Rollup, penting untuk memastikan keamanan aset pengguna saat berpindah antara L1 dan L2. Berikut ini adalah rincian tentang bagaimana pengguna dapat mengakses aset antara kedua lapisan ini dan bagaimana sistem menjaga integritas dan keamanan transaksi ini.
● Penyeberangan aset ke Rollup: Pengguna menyetor dana ke kontrak jembatan rantai Rollup di Layer1. Kontrak jembatan rantai meneruskan transaksi ke Layer2, di mana jumlah aset yang sama dicetak dan dikirim ke alamat yang dipilih oleh pengguna dalam Optimistic Rollup.
Transaksi yang dihasilkan oleh pengguna, seperti deposit dari Layer1 ke Layer2, biasanya akan dimasukkan dalam antrian sampai siaran ulang mereka ke kontrak Rollup. Namun, untuk menjaga ketahanan terhadap sensor, Optimistic Rollup memungkinkan pengguna untuk mengirimkan transaksi secara langsung ke kontrak Rollup on-chain jika keterlambatan transaksi melebihi waktu maksimum yang diizinkan.
● Menarik aset dari Rollup: Karena mekanisme bukti penipuan, menarik uang dari Optimistic Rollup ke Ethereum lebih rumit. Jika pengguna memulai transaksi Layer2 ke Layer1 untuk menarik dana yang dikelola di Layer1, mereka perlu menunggu akhir periode tantangan, yang biasanya berlangsung sekitar 7 hari.
Ketika pengguna memulai permintaan penarikan di Rollup, transaksi tersebut dimasukkan dalam batch berikutnya dan aset pengguna di Rollup dihancurkan. Setelah batch dipublikasikan di Ethereum, pengguna dapat menghitung bukti Merkle untuk memverifikasi bahwa transaksi keluar mereka termasuk dalam blok. Langkah berikutnya adalah menunggu periode penundaan berakhir untuk menyelesaikan transaksi di Layer1 dan menarik dana ke mainnet.
Untuk menghindari menunggu seminggu sebelum menarik uang dari Ethereum, pengguna Optimistic Rollup dapat meminta uang muka dari penyedia likuiditas (LP), yang mengasumsikan kepemilikan penarikan tertunda dan membayar dana pengguna di Layer1 sebagai imbalan atas biaya. Penyedia likuiditas dapat memverifikasi validitas permintaan penarikan pengguna dengan memeriksa data on-chain sendiri sebelum melepaskan dana. Dengan cara ini, mereka dapat memastikan bahwa transaksi akhirnya akan dikonfirmasi, mencapai kepastian kepercayaan.
Layer2 adalah sistem blockchain lengkap, sehingga audit umum dari rantai publik juga berlaku untuk Optimistic Rollup, sebagaimana dijelaskan dalam lampiran di akhir artikel ini.
Selain itu, karena sifat khususnya, Optimistic Rollup membutuhkan sejumlah audit tambahan:
● Bukti ketersediaan data: Pastikan bahwa data transaksi Layer2 tersedia di Layer1 untuk mencegah kehilangan data.
● Mekanisme sinkronisasi data: Periksa apakah mekanisme sinkronisasi data antara Layer1 dan Layer2 baik dan dapat menangani situasi abnormal seperti pemisahan jaringan.
● Kontrak Bukti Penipuan: Verifikasi bahwa kontrak bukti penipuan diimplementasikan dengan benar.
● Mekanisme periode tantangan: Periksa apakah panjang periode tantangan wajar dan apakah bukti penipuan dapat diselesaikan dalam waktu yang ditentukan.
Proses pengajuan bukti penipuan: Periksa bahwa proses pengajuan bukti penipuan aman.
● Proses Deposit dan Penarikan: Periksa proses deposit dan penarikan dari Layer1 ke Layer2 dan dari Layer2 ke Layer1 untuk memastikan prosesnya aman.
● Pencetakan dan pembakaran aset: Periksa logika pembuatan dan penghancuran aset di Layer2 untuk memastikan korespondensi yang benar dengan aset Layer1.
● Mekanisme penyedia likuiditas: Jika ada mekanisme penyedia likuiditas (LP), perlu untuk memeriksa proses operasi LP dan keamanannya.
Zero-Knowledge (ZK) Rollup adalah Layer2 yang didasarkan pada bukti zero-knowledge. Ini terutama melakukan perhitungan kompleks dan generasi bukti di luar jaringan, memverifikasi bukti di jaringan, dan menyimpan sebagian data untuk memastikan ketersediaan data.
ZK Rollup adalah "solusi penskalaan hibrida" yang merupakan protokol off-chain yang berjalan secara independen tetapi mendapat keamanan dari Ethereum. Secara khusus, jaringan Ethereum memberlakukan validitas pembaruan status pada ZK Rollups dan menjamin ketersediaan data latar belakang setiap kali status Rollup diperbarui. Status Rollup dipertahankan oleh kontrak pintar yang digunakan di jaringan Ethereum. Untuk memperbarui status ini, node ZK Rollups harus menyerahkan bukti validitas untuk verifikasi. Bukti validitas adalah jaminan kriptografi bahwa perubahan keadaan yang diusulkan memang merupakan hasil dari pelaksanaan batch transaksi tertentu. Ini berarti bahwa ZK Rollups hanya perlu memberikan bukti validitas untuk menyelesaikan transaksi di Ethereum, tanpa harus mempublikasikan semua data transaksi.
Tidak ada keterlambatan dalam mentransfer dana dari ZK Rollups ke Ethereum, karena transaksi keluar dieksekusi begitu kontrak ZK Rollups telah memverifikasi bukti keabsahan. Sebaliknya, menarik dana dari Optimistic Rollups menimbulkan keterlambatan karena siapa pun dapat menggunakan bukti penipuan untuk menantang transaksi keluar.
zkSync, solusi L2 yang diluncurkan lima tahun lalu oleh tim Matter Labs, menggunakan teknologi bukti kebenaran nol untuk memungkinkan verifikasi transaksi yang efisien dan telah mengumpulkan lebih dari $200 juta. zkSync adalah salah satu jaringan Layer2 yang paling aktif secara ekologis yang menggunakan ZK Rollups, dan zkSync juga kontroversial. Beosin sebelumnya melakukan audit terhadap proyek DeFi unggulannya, SyncSwap, meliputi kualitas kode, logika kontrak dan keamanan, model operasional, dan lainnya.
StarkNet menggunakan ZK-STARK untuk membangun Layer2 guna meningkatkan kecepatan transaksi dan mengurangi biaya transaksi. StarkNet memiliki mesin virtual asli (Cairo VM) dan bahasa pengembangan Cairo untuk membantu pengembang menulis kontrak pintar dengan lebih aman dan mudah. Beosin telah menjadi mitra keamanan resmi StarkNet, menyelesaikan audit keamanan untuk Option Dance dan Reddio. Pada 13 Agustus 2024, Reddio menutup putaran pendanaan awal yang dipimpin oleh Paradigm untuk membangun jaringan EVM Layer2 paralel yang berkinerja tinggi.
Scroll ditingkatkan oleh teknologi bukti nol pengetahuan, dan perangkat keras mempercepat pembuatan dan verifikasi bukti nol pengetahuan, dengan tujuan mencapai kompatibilitas EVM tingkat bytecode. Ini berarti bahwa pengembang dapat langsung menggunakan alat pengembangan Solidity dan Ethereum terkait untuk membangun kontrak pintar.
Kerangka kerja umum untuk ZK Rollups termasuk kontrak Rollup dan Bridge, collator, aggregator, Repeater, dan jaringan Roller yang menghasilkan bukti nol pengetahuan. Arsitektur spesifik ditunjukkan dalam gambar berikut:
● Kontrak Rollup dan kontrak Jembatan:
Kontrak Rollup bertanggung jawab untuk menyediakan ketersediaan data untuk transaksi Rollup, memverifikasi bukti kebenaran zkEVM, dan memungkinkan pengguna mentransfer aset antara Ethereum dan Rollup. Ia menerima akar status Layer 2 dan blok dari pengumpul, akar status disimpan di dalam status Ethereum, dan data blok layer 2 disimpan sebagai calldata Ethereum.
Kontrak jembatan diterapkan di Ethereum dan Layer2, memungkinkan pengguna untuk mengirim pesan dan mentransfer aset antara Layer1 dan Layer2.
● Pemroses: Pemroses menyediakan antarmuka JSON-RPC dan menerima transaksi Layer2, secara berkala mengambil sekelompok transaksi dari memori pool untuk dieksekusi, menghasilkan blok Layer2 baru dan state roots. Implementasinya biasanya berdasarkan Go-Ethereum (Geth), memastikan kompatibilitas terbaik dan keamanan tertinggi.
● Koordinator: Koordinator akan mendapatkan pemberitahuan ketika kolator menghasilkan blok baru dan menerima jejak eksekusi dari blok tersebut dari kolator. Jejak eksekusi kemudian dikirimkan ke Roller yang dipilih secara acak di jaringan Roller, yang menghasilkan bukti keabsahan.
● Relayer: Pemancar memantau kontrak Rollup dan kontrak jembatan yang diterapkan pada Ethereum dan Layer2. Tanggung jawab utamanya adalah: 1) Melacak ketersediaan data dan validasi blok Layer2 dengan memantau kontrak Rollup; 2) Memantau acara deposit dan penarikan Ethereum dan keterlibatan jembatan Layer2 dan meneruskan pesan ke ujung lainnya.
● Jaringan Roller: Roller dalam jaringan Roller bertindak sebagai pembuktian dan bertanggung jawab atas pembuatan bukti keabsahan untuk ZK Rollup. Jejak eksekusi blok pertama diterima dari koordinator, diubah menjadi saksi sirkuit, kemudian bukti dibuat untuk setiap zkevm menggunakan percepatan hardware, dan akhirnya agregasi bukti digunakan untuk menggabungkan beberapa bukti menjadi satu bukti.
Dalam arsitektur teknis ZK Rollups, penting untuk memastikan keamanan aset pengguna selama transfer antara L1 dan L2. Berikut ini rincian cara pengguna dapat mengakses aset antara dua lapisan dan bagaimana sistem menjaga integritas dan keamanan transaksi ini.
● Asset bridging ke Rollup: Pengguna memasuki Rollup dengan mendepositkan token ke kontrak ZK Rollups yang diterapkan pada lapisan jaringan. Transaksi ini perlu diserahkan ke kontrak Rollup oleh pihak proyek.
Jika antrian deposit yang tertunda mulai penuh, operator ZK Rollups akan menerima transaksi deposit ini dan mengirimkannya ke kontrak Rollup. Setelah dana tersebut didepositkan di Rollup, pengguna dapat memulai pemrosesan transaksi.
Pengguna dapat memverifikasi saldo di Rollup dengan menghash akun mereka, mengirimkan nilai hash ke kontrak Rollup, dan memberikan bukti Merkle yang diverifikasi terhadap root state saat ini.
● Penarikan aset dari Rollup: Pengguna memulai transaksi keluar, mengirim aset mereka di Rollup ke akun yang ditentukan untuk dihancurkan. Jika operator menambahkan transaksi ke batch berikutnya, pengguna dapat mengajukan permintaan penarikan ke kontrak on-chain. Permintaan penarikan termasuk:
Bukti Merkle, yang membuktikan bahwa transaksi pengguna ditambahkan ke akun yang dihancurkan dalam batch transaksi
Data transaksi
Batch root
Alamat jaringan Layer1 untuk menerima dana deposit
Kontrak Rollup menghash data transaksi, memeriksa apakah batch root ada, dan menggunakan bukti Merkle untuk memeriksa apakah hash transaksi adalah bagian dari batch root. Kontrak mengeksekusi transaksi keluar dan mengirim dana ke alamat di jaringan Layer1 yang dipilih oleh pengguna.
Layer 2 adalah sistem blockchain lengkap, sehingga item audit umum untuk blockchain juga berlaku untuk ZK Rollup, seperti yang dijelaskan di lampiran pada akhir artikel ini.
Selain itu, karena sifat khususnya, ZK Rollup memerlukan beberapa audit tambahan untuk dilakukan:
● Bukti keamanan sistem: Periksa keamanan dan kebenaran dari skema bukti zero pengetahuan yang digunakan (misalnya Groth16, Plonk, Halo2, zk-STARK, dll).
● Keamanan sirkuit: Periksa kerentanan yang mungkin terdapat pada desain sirkuit dan implementasinya, terutama meliputi hal-hal berikut:
Rangkaian yang kurang terbatas
Sirkuit Terlalu Terbatas
Sirkuit Nondeterministik
Aritmatika Over/Under Flows Aritmatika over/under flows
Panjang Bit yang Tidak Cocok
Input Publik yang Tidak Digunakan Dioptimalkan
Frozen Heart: Pengecoran Bukti Nol Pengetahuan
Kebocoran Pengaturan Terpercaya
Assigned but not Constrained
Penggunaan Komponen yang Tidak Aman
Presisi Variabel
● Pembuatan dan validasi bukti: Tinjau proses pembuatan dan validasi bukti untuk memastikan efisiensi dan keamanannya.
● Bukti ketersediaan data: Pastikan bahwa data transaksi Layer2 tersedia di Layer1 untuk mencegah kehilangan data.
● Mekanisme sinkronisasi data: Periksa apakah mekanisme sinkronisasi data antara Layer1 dan Layer2 berfungsi dengan baik dan dapat mengatasi situasi abnormal seperti pemisahan jaringan.
Proses deposit dan penarikan: Periksa proses deposit dan penarikan dari Layer1 ke Layer2 dan dari Layer2 ke Layer1 untuk memastikan prosesnya aman.
● Pencetakan dan pembakaran aset: Periksa logika pencetakan dan penghancuran aset di Layer2 untuk memastikan korespondensi yang benar dengan aset Layer1.
● Memindai dependensi eksternal dan kerentanan yang diketahui: ZK Rollup sering sangat bergantung pada repositori kriptografi dan matematika atau alat pihak ketiga dan harus benar-benar memeriksa keamanan ketergantungan mereka untuk memindai dan memvalidasi kerentanan yang diketahui.
Audit item Umum Blockchain & Layer2:
● Overflow integer: Periksa overflow integer dan underflow integer
● Loop: Periksa loop dari program untuk melihat apakah kondisinya masuk akal
● Panggilan rekursif tak terbatas: Periksa apakah kondisi keluar dari panggilan rekursif programnya wajar
● Kondisi perlombaan: Memeriksa akses ke sumber daya bersama dalam keadaan konkuren
● Exception crash: Periksa kode pelemparan pengecualian yang menyebabkan program keluar secara aktif
● Bagi dengan 0 kerentanan: Periksa apakah ada kasus membagi dengan 0
● Konversi tipe: Periksa apakah konversi tipe sudah benar dan apakah informasi penting hilang selama konversi
● Array out of bounds: Memeriksa akses ke elemen di luar batas array
● Kerentanan Deserialisasi: Periksa masalah saat deserialisasi
● Keamanan implementasi fungsi: Periksa apakah implementasi antarmuka RPC memiliki risiko keamanan dan konsisten dengan desain fungsional antarmuka RPC
● Apakah Pengaturan Izin antarmuka RPC yang sensitif masuk akal: Periksa pengaturan izin akses antarmuka RPC yang sensitif
● Mekanisme transmisi terenkripsi: Periksa apakah protokol transmisi terenkripsi, seperti TLS, digunakan
● Meminta pemformatan data parsing: Memeriksa proses pemformatan data permintaan
● Serangan buka kunci dompet: Ketika sebuah node membuka dompetnya, ia diminta oleh RPC untuk mencuri dana
● Keamanan Web tradisional: Periksa kerentanan berikut: Cross-site scripting (XSS)/injeksi templat/kerentanan komponen pihak ketiga/kontaminasi parameter HTTP/injeksi SQL/Injeksi entitas XXE/kerentanan deserialisasi/kerentanan SSRF/Injeksi kode/penyertaan file lokal/Penyertaan file jarak jauh/injeksi eksekusi perintah dan kerentanan tradisional lainnya
● Mekanisme otentikasi dan identifikasi identitas node jaringan: periksa apakah ada mekanisme identifikasi identitas node, mekanisme identifikasi identitas node dapat dihindari
● Kontaminasi tabel routing: Periksa apakah tabel routing dapat dimasukkan atau ditimpa secara sembarangan
● Algoritma penemuan node: Periksa apakah algoritma penemuan node seimbang dan tidak dapat diprediksi, misalnya, algoritma jarak tidak seimbang
● Audit Penggunaan Koneksi: Periksa apakah batas dan pengelolaan jumlah node yang terhubung ke jaringan p2p masuk akal
● Serangan Gerhana Matahari: Menilai biaya dan bahaya dari serangan gerhana matahari, memberikan analisis kuantitatif jika diperlukan
● Serangan Sybil: Mengevaluasi mekanisme konsensus pemungutan suara dan menganalisis strategi pemeriksaan kelayakan pemilih
● Serangan menguping: Periksa apakah protokol komunikasi mengungkapkan privasi
● Serangan alien: Mengevaluasi apakah node dapat mengenali node rantai yang sama jenisnya
● Pembajakan waktu: Periksa mekanisme perhitungan waktu jaringan suatu node
● Serangan kelelahan memori: Periksa konsumsi memori yang besar
● Serangan kehabisan ruang hard disk: Periksa di mana file-file besar disimpan
● serangan tekanan soket: Periksa kebijakan batas jumlah tautan
● Serangan kelelahan penanganan kernel: Periksa keterbatasan pada pembuatan penanganan kernel, seperti penanganan file
● Kebocoran memori persisten: Periksa kebocoran memori
● Keamanan algoritma hash: Periksa keamanan tabrakan algoritma hash
● Keamanan algoritma tanda tangan digital: Periksa keamanan algoritma tanda tangan dan implementasi algoritma
● Keamanan algoritma enkripsi: Periksa keamanan algoritma enkripsi dan implementasi algoritma
● Keamanan generator angka acak: Periksa apakah algoritma pembangkitan angka acak kunci wajar
● Keamanan implementasi BFT: Mengevaluasi keamanan implementasi algoritma BFT
● Aturan seleksi fork: Periksa aturan seleksi fork untuk memastikan keamanan
● Uji tingkat sentralisasi: Identifikasi apakah ada desain yang terlalu terpusat dalam desain sistem
● Audit insentif: Menilai dampak insentif terhadap keamanan
● Serangan double-spending: Periksa apakah konsensus dapat melindungi dari serangan double-spending
● Audit Serangan MEV: Meneliti dampak MEV dari node paket blok pada keadilan rantai
● Audit proses sinkronisasi blok: Memeriksa masalah keamanan selama sinkronisasi
● Audit proses parsing format blok: Memeriksa masalah keamanan selama parsing format, seperti kesalahan parsing yang menyebabkan crash
● Audit Proses Generasi Blok: Periksa isu keamanan dalam proses generasi blok, termasuk apakah akar pohon Merkle dibangun dengan cara yang masuk akal
● Audit proses verifikasi blok: Periksa apakah item tanda tangan blok dan logika verifikasinya cukup
● Audit logika validasi blok: Periksa apakah algoritma dan implementasi validasi blok masuk akal
● Tabrakan hash blok: Periksa bagaimana tabrakan hash blok dibangun dan apakah tabrakan tersebut ditangani dengan wajar
● Batas sumber daya pemrosesan blok: Periksa apakah kolam blok yatim, komputasi verifikasi, pengalamatan hard disk, dan batasan sumber daya lainnya wajar
● Audit proses sinkronisasi transaksi: Memeriksa masalah keamanan dalam proses sinkronisasi
● Tandingan hash transaksi: Teliti bagaimana tandingan hash transaksi dibangun dan bagaimana mereka ditangani
● Penguraian format transaksi: Periksa masalah keamanan selama penguraian format, seperti kesalahan penguraian yang menyebabkan kerusakan
● Pengecekan validitas transaksi: Periksa apakah item tanda tangan dari setiap jenis transaksi dan logika verifikasi cukup
● Batas sumber daya pemrosesan transaksi: Periksa apakah batasan sumber daya seperti kolam transaksi, komputasi verifikasi, dan addressing hard disk adalah wajar
● Serangan kecacatan transaksi: Apakah transaksi dapat mengubah bidang internal (seperti ScriptSig) untuk mengubah hash transaksi tanpa mempengaruhi validitas transaksi
● Audit serangan replay transaksi: Memeriksa deteksi sistem replay transaksi
● Pemeriksaan bytecode kontrak: Periksa keamanan proses verifikasi kontrak mesin virtual, seperti integer overflow dan dead loop
● Eksekusi bytecode kontrak: Periksa keamanan proses eksekusi bytecode mesin virtual, seperti integer overflow, dead loop, dan sebagainya
● Model gas: Periksa apakah biaya untuk setiap operasi atom dari pemrosesan transaksi / pelaksanaan kontrak sebanding dengan konsumsi sumber daya
● Integritas log: Periksa apakah informasi kunci tercatat
● Keamanan log: Periksa apakah penanganan log yang tidak sesuai menyebabkan masalah keamanan, seperti overflow integer
● Log berisi informasi privasi: Periksa apakah log berisi informasi privasi seperti kunci
● Penyimpanan log: Periksa apakah terdapat konten berlebihan yang dicatat dalam log, yang menghabiskan sumber daya node
● Keamanan rantai pasokan kode Node: Periksa semua pustaka, komponen, dan versi kerangka rantai publik pihak ketiga untuk masalah yang diketahui