Analisis Proses Eksekusi Transaksi Layer 2: Penilaian Keamanan di Setiap Tahap

Teknologi Layer 2(L2) membawa skalabilitas yang lebih tinggi untuk Ethereum, namun juga meningkatkan kompleksitas konfirmasi transaksi. Artikel ini akan menjelaskan secara rinci proses eksekusi lengkap transaksi L2 dan menganalisis kinerja keamanan di setiap tahap.

Tinjauan Proses Transaksi L1

Setelah pengguna mengirim transaksi, mereka harus menunggu penambang atau validator untuk mengemasnya ke dalam blok. Bahkan jika transaksi sudah dikemas, masih perlu menunggu sejumlah blok konfirmasi untuk mengurangi risiko reorganisasi (Re-org). Hanya ketika probabilitas reorganisasi cukup rendah, transaksi dapat dianggap sebagai konfirmasi final.

Penjelasan Rincian Proses Transaksi L2

Proses perdagangan L2 dibandingkan dengan L1, memiliki satu langkah tambahan:

1. Pengguna mengirimkan transaksi kepada Sequencer
2. Sequencer mengemas transaksi ke dalam blok L2
3. Sequencer mengirimkan data blok L2 ke L1
4. Tunggu konfirmasi L1

Di mana langkah 2-3 adalah khusus untuk L2. Pada tahap ini, transaksi belum dimasukkan ke dalam rantai, pengguna hanya dapat mengandalkan janji Sequencer, yang disebut "Pre-Confirmation"(Pre-Confirmation).

Mekanisme Konfirmasi Transaksi untuk Solusi L2 Utama

Arbitrum/Optimism

• Transaksi hampir dapat langsung mendapatkan tanda terima, ini adalah pra-konfirmasi dari Sequencer
• Explorer akan menampilkan status transaksi, termasuk "Confirmed by Sequencer" dan jumlah konfirmasi L1
• Optimism juga akan menampilkan status L1 Finality

StarkNet

• Status transaksi termasuk Received, Pending, Accepted on L2, Accepted on L1
• Waktu konfirmasi dari L2 ke L1 cukup lama, sekitar 4-5 jam
• Explorer tidak menampilkan informasi L1 Finality

zkSync

• Status transaksi termasuk Pending, zkSync Era Processed, Committed, Proven, Executed
• Memecah proses L2 ke L1 menjadi tiga tahap
• Explorer memberikan informasi rinci tentang setiap tahap

Mekanisme Pra-Konfirmasi L1

Jika bisa mengetahui pembuat blok sebelumnya, L1 juga dapat mendukung prakonfirmasi. Dalam arsitektur PBS, Builder dapat menyediakan layanan prakonfirmasi, tetapi efektivitasnya cukup lemah. Di masa depan, jika Proposer dapat terlibat dalam pembuatan blok, mekanisme prakonfirmasi mungkin akan lebih dapat diandalkan.

Memperbaiki Mekanisme Pra-konfirmasi

Dapat menggunakan kontrak pintar untuk memungkinkan Builder atau Sequencer menyetor deposit, dan menandatangani isi komitmen. Jika komitmen dilanggar, pengguna dapat mengajukan bukti dan menghukum pihak lain, sehingga meningkatkan kredibilitas pra-konfirmasi.

Ringkasan

• Transaksi L2 memiliki satu tahap tambahan yang menunggu untuk diunggah ke L1.
• Sebelum mengunggah L1, pengguna hanya dapat mengandalkan pra-konfirmasi dari Sequencer
• Sebagian besar L2 Explorer akan menampilkan status pra-konfirmasi
• Menunggu pengunggahan data L2 ke L1 adalah praktik yang paling aman.
• Dapat meningkatkan keandalan pra-konfirmasi melalui mekanisme insentif ekonomi.

Tabel di bawah ini merangkum jaminan konfirmasi dan risiko dari transaksi L1 dan Layer 2 di setiap tahap:

| Tahap | L1 Transaksi | L2 Transaksi | |------|--------|--------| | Kirim Transaksi | Tanpa Jaminan | Tanpa Jaminan | | Konfirmasi Awal | Builder berkomitmen ( di masa depan mungkin ) | Sequencer berkomitmen | | Mengemas Blok | Jaminan Tinggi | Jaminan Sedang ( tergantung pada Sequencer ) | | Unggah L1 | - | Jaminan Tinggi | | Beberapa Konfirmasi | Jaminan Sangat Tinggi | Jaminan Sangat Tinggi | | Konfirmasi Akhir | Jaminan Terbaik | Jaminan Terbaik |