Terima kasih khusus kepada Jon Charbonneau dan Conor McMenamin yang telah mengulas artikel ini.

Pada titik ini kita semua harus tahu bahwa aturan konfirmasi memiliki keamanan, bukan rollup itu sendiri. Ketika kami mengatakan bahwa rollup mewarisi “keamanan Ethereum” atau bahwa mereka “diminimalkan kepercayaan”, yang sebenarnya kami maksud adalah bahwa pada rollup, aturan konfirmasi dapat digunakan yang memiliki keamanan yang kurang lebih sama dengan aturan konfirmasi Ethereum. Namun penjelajah blok, sebagian besar peduli untuk menampilkan lencana hijau tanpa merinci aturan konfirmasi mana yang mereka maksud atau properti keamanan apa yang mereka berikan.

Di L2BEAT kami ingin mengatasi masalah ini dan membuatnya dapat diakses oleh semua orang. Secara khusus, kami ingin fokus pada finalitas, yaitu aturan konfirmasi terkuat terhadap serangan pembelanjaan ganda.

Aturan konfirmasi: konsistensi vs ketersediaan

Aturan konfirmasi adalah algoritme yang, berdasarkan asumsi tertentu, menunjukkan kapan suatu blok dikonfirmasi dan kemungkinan tidak akan disusun ulang. Setelah blok dikonfirmasi, tindakan terkait transaksinya dapat diambil. Misalnya, hal ini dapat melibatkan penyerahan kopi kepada pelanggan atau mengantarkan mobil kepada pembelinya.

Aturan konfirmasi yang berbeda memberikan jaminan keamanan yang berbeda kepada pengguna. Keamanan aturan konfirmasi terdiri dari konsistensi dan ketersediaan, dan sangat bergantung pada algoritma konsensus yang mendasarinya:

• Konsistensi (keamanan): tampilan dua node mana pun konsisten di bawah partisi jaringan.
• Ketersediaan (kehidupan): transaksi terus dimasukkan ke dalam buku besar dalam jangka waktu tertentu bahkan setelah sebagian besar node berhenti berpartisipasi dalam protokol.

Teorema CAP memberi tahu kita bahwa tidak mungkin merancang algoritme konsensus yang tetap konsisten dalam partisi jaringan dan tersedia dalam partisipasi dinamis: jika terjadi partisi jaringan yang serius, node dapat memutuskan untuk terus memproduksi blok dan kehilangan konsistensi, atau berhenti dan kehilangan ketersediaan. Tidak ada cara bagi node untuk membedakan antara node lain yang offline (partisipasi dinamis) atau aktif tetapi tidak dapat dijangkau (partisi jaringan) dan oleh karena itu tidak mungkin untuk bertindak berbeda.

Eve tidak dapat mengetahui apakah Bob sedang offline atau berada di partisi jaringan yang berbeda.

Blockchain seperti Bitcoin, menggunakan konsensus seperti Nakamoto, mendukung keaktifan, yang berarti bahwa selama pemisahan jaringan, kedua belah pihak akan terus menghasilkan blok dan pada akhirnya akan menyusun kembali jika partisi tersebut teratasi, sementara yang lain seperti rantai Cosmos, menggunakan seperti PBFT konsensus, berhenti di bawah partisi jaringan untuk menjaga konsistensi.

Aturan konfirmasi pada Ethereum

Ethereum memprioritaskan ketersediaan di bawah partisi jaringan menggunakan algoritma LMD GHOST . Pendekatan ini berarti bahwa node yang jujur mungkin memiliki pandangan berbeda di ujung rantai dan dapat mengonfirmasi blok berbeda dengan ketinggian yang sama, sehingga berpotensi mengarah pada penataan ulang.

Dalam kondisi jaringan yang menguntungkan, Ethereum juga bertujuan untuk memberikan jaminan konsistensi melalui finalitas, menggunakan protokol Casper FFG . Finalitas adalah aturan konfirmasi yang paling kuat, dengan node yang memiliki aturan hard-code untuk tidak pernah mengatur ulang blok yang telah diselesaikan.

Buku besar yang diselesaikan (hijau) selalu merupakan awalan dari buku besar langsung (biru).

Jaminan finalitas dikompromikan jika dua blok yang bertentangan diselesaikan, sebuah peristiwa yang dapat terjadi jika lebih dari 1/3 validator bertindak jahat. Namun, di Ethereum, tindakan seperti itu menimbulkan hukuman yang signifikan yaitu kehilangan sahamnya.

Pengguna dapat memilih apakah akan menggunakan Casper FFG sebagai aturan konfirmasi paling aman atau lebih live dengan mengandalkan LMD GHOST. Aturan konfirmasi untuk LMD GHOST, mirip dengan aturan k-konfirmasi di Bitcoin, bisa lebih canggih dari sekadar melihat apakah transaksi tersebut disertakan dalam buku besar, sebagaimana ditentukan dalam aturan konfirmasi Blok Aman.

Aturan konfirmasi pada rollup

Rollup pada prinsipnya dapat menggunakan aturan konfirmasi yang sama yang tersedia di Ethereum. Jika Anda mengirim transaksi secara rollup, dan kemudian melihat transaksi yang sama diposting di L1 dalam blok yang diselesaikan, Anda mungkin juga ingin menganggap transaksi L2 sebagai transaksi final. Ternyata ceritanya jauh lebih kompleks dari ini.

Rollup data transaksi

Di Ethereum, blok mencakup daftar transaksi dan root status yang diusulkan di header blok. Jika eksekusi transaksi tidak mengarah pada keadaan yang diwakili oleh root, seluruh blok akan dibuang, termasuk transaksi yang nantinya dapat ditambahkan ke blok lain dalam urutan berbeda.

Pada rollup, karena tindakan penerbitan data dan akar dipisahkan, transaksi tidak perlu dibuang bergantung pada validitas akar status terkait. Dengan adanya pemisahan ini, cukup memeriksa apakah transaksi telah diselesaikan tanpa menunggu finalisasi root negara, sehingga melewati penundaan tambahan seperti periode tantangan 7 hari dalam rollup optimis.

Pembatalan perbedaan negara bagian

Perbedaan keadaan adalah keluaran dari fungsi transisi keadaan, dan untuk memvalidasi bahwa perbedaan tersebut memang valid, kita perlu menunggu bukti ZK. Pembuatan bukti ZK membutuhkan waktu, dan selain itu, ada insentif untuk menunda lebih lanjut untuk memasukkan lebih banyak transaksi dalam satu bukti untuk mengamortisasi biaya pembuatan dan verifikasi bukti dengan lebih baik.

Teknik agregasi bukti menawarkan solusi terhadap trade-off antara waktu konfirmasi dan amortisasi biaya: meskipun rollup mengalami aktivitas minimal, rollup masih dapat memperoleh manfaat dari amortisasi dengan memasukkan transaksi dari rollup yang lebih aktif ke dalam bukti yang sama. Contoh dari pendekatan ini adalah SHARP oleh Starkware, yang saat ini mengumpulkan bukti dari rollup Starknet, Paradex, dan StarkEx seperti dYdX dan bahkan Validium.

Dimana segala sesuatunya menjadi rumit

Spesifikasi derivasi rollup

Jika rollup tidak based, urutan derivasi batch dapat ditentukan oleh sequencer rollup, yang mungkin menerbitkannya dalam urutan berbeda di L1.

Sebagai contoh, rantai OP Stack menerbitkan batch di L1 yang ditautkan menggunakan hash dari batch sebelumnya. Batch ini tidak perlu dipublikasikan dalam urutan kronologis, yang mengarah ke jendela pengurutan 12 jam di mana node menunggu transaksi yang berpotensi hilang. Transaksi tidak boleh dianggap disertakan hanya karena dipublikasikan di L1: jika suatu batch belum terhubung ke rantai batch kanonik, ada risiko bahwa fork alternatif dengan urutan atau rangkaian transaksi berbeda akan dibuat.

Pada rantai OP Stack, waktu blok adalah 2 detik, menghasilkan 6 blok dalam setiap blok Ethereum. Pengelompokan 6 blok di antara blok Ethereum ini disebut “zaman.” Pesan L1-ke-L2 yang dikirimkan melalui L1 disertakan di bagian pertama blok pertama dari epoch yang sesuai untuk blok L1 tertentu. Meskipun transaksi ini dapat dianggap terkonfirmasi tanpa menunggu jendela pengurutan lewat, karena urutannya dalam buku besar L2 setelah derivasi diketahui, penting untuk dicatat bahwa node tidak akan mulai menghitung blok yang berisi pesan-pesan ini jika batch sebelumnya hilang. Hal ini karena keadaan tidak dapat dihitung tanpa urutan yang lengkap, dan oleh karena itu, akar keadaan juga tidak akan dipublikasikan di L1.

Konsekuensinya adalah pemeriksaan data on-chain saja tidak cukup untuk melacak waktu konfirmasi L1. Penting juga untuk memahami bagaimana blok L2 diturunkan dari data L1 dengan memeriksa perangkat lunak rollup node itu sendiri.

Fungsi yang diizinkan

Scroll merupakan data transaksi postingan rollup ZK, artinya pada prinsipnya seseorang tidak perlu menunggu bukti ZK untuk menganggap transaksinya final. Hal ini akan terjadi jika mereka tidak menerapkan fungsi untuk menghapus kumpulan yang belum terbukti.

https://etherscan.io/address/0x2e07f0fba71709bb5e1f045b02152e45b451d75f#code#F1#L260

Hal yang sama dapat diterapkan pada rollup yang memposting perbedaan status: zkSync Era dan zkSync Lite memiliki proses tiga langkah untuk memposting perbedaan status: pertama, mereka memasukkan data tanpa bukti apa pun, lalu memberikan bukti untuk data tersebut, dan kemudian, setelah penundaan 24 jam , root tersedia untuk dieksekusi guna memproses penarikan. Secara teori, ketika bukti diberikan, urutan transaksi sudah ditetapkan, sehingga seseorang tidak perlu menunggu hingga penundaan eksekusi berlalu. Kecuali, zkSync dapat mengembalikan blok tersebut:

https://etherscan.io/address/0x7Ed066718Dfb1b2B04D94780Eca92b67ECF3330b#code#F10#L425

Sedangkan untuk zkSync Era tidak ada blok yang pernah dikembalikan, di zkSync Lite hal itu terjadi sebanyak 8 kali.

Observabilitas finalitas

Karena perbedaan status pengeposan rollup tidak mengeposkan data transaksi, bagaimana kami dapat melacak bahwa suatu transaksi memang telah disertakan? Ya, kami dapat melacak efeknya, seperti nonce akun, namun kasus umumnya menjadi rumit. Sebulan yang lalu saya menanyakan pertanyaan berikut:

Mari kita lihat beberapa balasannya:

Ini adalah solusi yang berfungsi jika sequencer bersedia merespons Anda dan jika Anda memercayainya. Bagaimana jika tidak? Atau, bagaimana jika ya, tetapi Anda tidak memercayainya? Bagaimana Anda memverifikasi bahwa klaim tersebut benar?

Balasan favorit saya.

Solusi yang benar-benar berfungsi disarankan di sini:

Meskipun cara ini berhasil, hal ini berarti keputusan teknis penggunaan perbedaan status bocor ke dalam logika aplikasi, yang berarti bahwa meskipun rollup setara dengan EVM, proyek harus menyesuaikan kontraknya dengan pertimbangan ini.

Solusi parsial adalah dengan memposting root transaksi dan memverifikasi validitasnya di dalam bukti ZK. Bahkan dalam kasus ini, seseorang harus bergantung pada sequencer untuk mendapatkan jalur Merkle yang diperlukan, yang mungkin masuk akal dengan sequencer terpusat yang memiliki reputasi baik, namun menjadi lebih rumit dalam pengaturan tanpa izin.

Metrik keaktifan

Sebagai langkah pertama dalam melacak waktu hingga finalitas transaksi rollup, di L2BEAT kami mulai melacak metrik keaktifan, khususnya interval antara kumpulan transaksi (jika ada) dan akar status. Alasannya adalah jika rollup, misalnya, berinteraksi dengan L1 hanya sekali per bulan, pengguna tidak dapat mengharapkan waktu penyelesaian dalam hitungan menit. Metrik keaktifan dapat dianggap sebagai indikator batas bawah untuk waktu penyelesaian: jika rollup data transaksi memposting batch setiap dua menit sekali, dan dengan asumsi bahwa distribusi transaksi L2 seragam, perkiraan waktu penyelesaian tidak kurang dari satu menit .

Berikut beberapa contoh data yang kami lacak untuk zkSync Era (pembaruan status) dan OP Mainnet (tx batch):

Metrik keaktifan Era zkSync untuk bulan September.

Metrik keaktifan OP Mainnet untuk bulan September.

Seperti yang diperkirakan, karena bukti ZK membutuhkan waktu untuk dihasilkan dan ada insentif untuk memasukkan lebih banyak transaksi dalam satu bukti, zkSync Era memiliki metrik keaktifan yang lebih buruk daripada OP Mainnet. Penting untuk diingat bahwa, seperti yang telah kita bahas di bagian sebelumnya, metrik keaktifan tidak langsung diterjemahkan ke dalam pertimbangan finalitas: dalam kasus terburuk, OP Mainnet sebenarnya memiliki waktu finalitas yang lebih lama karena jendela pengurutannya.

Anda sekarang dapat menjelajahi metrik keaktifan untuk sebagian besar rollup di L2BEAT:

Keterbatasan pelacakan keaktifan

Meskipun keaktifan dapat dilihat sebagai indikator batas bawah finalitas, terkadang hal ini bisa menjadi indikator yang sangat buruk. Bayangkan sebuah rollup dengan waktu blok 4 detik, artinya untuk setiap blok Ethereum terdapat 3 blok rollup. Jika operator rollup hanya memposting dua blok L2 per blok L1, bahkan jika dari sudut pandang Ethereum rollup tersebut sangat aktif, operator rollup akan semakin tertinggal dari konfirmasi lunak L2 dan waktu penyelesaian akan semakin buruk. Meskipun ini adalah skenario ekstrem, rollup perlu diperhitungkan.

Contoh praktisnya adalah Starknet: meskipun kami mengamati rata-rata 32 detik antara pembaruan status, waktu penyelesaian sebenarnya mendekati 6 jam:

Sumber: starkscan.co

Hal ini karena Starknet menerbitkan pembaruan status root untuk setiap blok L2 di L1. Namun, untuk melakukan hal ini, mereka harus merujuk pada bukti SHARP, yang biasanya diposting kira-kira setiap 30 menit sekali. Selain itu, pembuktian ini berada sekitar 6 jam di belakang ujung rantai konfirmasi lunak L2.

Konfirmasi lunak

Konfirmasi lunak adalah aturan konfirmasi yang digunakan untuk mempersingkat waktu konfirmasi pada L2 dengan mengorbankan jaminan keamanan. Saat ini, dalam semua kasus, konfirmasi lunak berarti memercayai operator terpusat untuk tidak mengirimkan tx yang berbeda di L1. Konfirmasi lunak yang salah merupakan kesalahan yang dapat diatribusikan, oleh karena itu mekanisme untuk melacak reputasi sequencer pemotongan offchain atau onchain dapat diterapkan. Bekerja sama dengan Nethermind, kami berencana memperkirakan properti keamanan tersebut dan melacak jumlah nilai yang berisiko pada saat tertentu.

Kiri: jaminan ekonomi di Starknet jika mereka mempunyai konfirmasi lunak yang dijamin dengan mekanisme pemotongan. Kanan: nilai total berisiko berubah seiring waktu.

Maju

Melacak waktu hingga penyelesaian adalah tugas yang rumit. Langkah pertama kami adalah memantau interval pengiriman bukti untuk rollup ZK, yang menerapkan batas bawah yang lebih tinggi pada waktu penyelesaian dibandingkan dengan interval antara pengiriman akar negara bagian. Setelah ini, kami berencana untuk memperkenalkan grafik yang menampilkan data historis untuk setiap proyek. Selanjutnya, penelitian kami akan fokus pada semua mekanisme tambahan yang perlu dipertimbangkan untuk mencapai metrik real-time hingga waktu penyelesaian. Pantau terus!

Penafian:

1. Artikel ini dicetak ulang dari [medium]. Semua hak cipta milik penulis asli [Luca Donno]. Jika ada keberatan terhadap cetak ulang ini, silakan menghubungi tim Gate Learn , dan mereka akan segera menanganinya.
2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini adalah sepenuhnya milik penulis dan bukan merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, dilarang menyalin, mendistribusikan, atau menjiplak artikel terjemahan.