Menafsirkan seluruh proses implementasi transaksi L2: apa kinerja keamanan dari setiap tahap?

Penulis: Nic@ imToken Labs

Kapan saya bisa yakin bahwa transaksi L2 akan dimasukkan dalam blok? Kapan saya bisa yakin bahwa pendapatan dari transaksi L2 tidak akan dibuang karena Re-org?

Artikel ini akan memperkenalkan seluruh proses implementasi transaksi L2 dan menganalisis kinerja keamanan setiap tahap proses transaksi.

Prasyarat:

• Seluruh proses transaksi L1 (Layer 1)
• Penyebab dan efek dari Re-org
• Memahami peran Ethereum saat ini dalam arsitektur PBS dan cara kerjanya
• Memahami perbedaan antara Optimistic Rollups dan Validity (ZK) Rollups

Pelajari tentang transaksi L1

PROSES TRANSAKSI

Diagram aliran transaksi L1

Re-org masih dimungkinkan setelah Blok pendapatan transaksi, dan perlu menunggu sampai re-org tidak mungkin terjadi untuk yakin bahwa transaksi telah diselesaikan.

Probabilitas dan biaya Re-org akan bervariasi tergantung pada Algoritma Konsensus rantai dan Kapitalisasi Pasar aset, dan perhitungan biaya Re-org tidak akan diperkenalkan di sini.

Pelajari tentang transaksi L2

PROSES TRANSAKSI

Setelah pengguna L2 menghasilkan dan menandatangani transaksi, biasanya dikirim langsung ke Sequencer yang bertanggung jawab untuk menyortir transaksi, dan Sequencer mengumpulkan transaksinya ke Blok L2. Kemudian, ketika Sequencer menulis data Blok L2 kembali ke L1 melalui transaksi L1, pengguna dapat melihat bahwa transaksi mereka termasuk dalam Blok L2 terbaru.

Namun, perlu dicatat bahwa karena data Blok L2 diunggah ke L1 melalui transaksi L1, masih mungkin untuk menghadapi situasi di mana L1 Re-org terjadi, sehingga Blok L2 tidak ditulis ke dalam sejarah Blockchain pada akhirnya, yaitu, setara dengan L2 Re-org, sehingga pengguna masih harus menunggu probabilitas L1 Re-org cukup rendah untuk memastikan bahwa transaksinya akan ditulis ke dalam sejarah Blockchain.

Diagram aliran transaksi L2

Pengguna pertama-tama menunggu transaksi dimasukkan ke dalam Blok L2, kemudian menunggu Blok L2 diunggah ke L1 melalui transaksi L1, dan akhirnya menunggu transaksi L1 diselesaikan.

Meskipun dibandingkan dengan transaksi L1, transaksi L2 memiliki periode waktu tambahan untuk menunggu transaksi L2 dimasukkan ke dalam blok L2 oleh Sequencer, tetapi pada kenyataannya, ketika ukuran blok L2 cukup besar dan kecepatan produksi blok cukup cepat, waktu tunggu ini tidak akan memakan banyak waktu, karena waktu tunggu terutama akan menghabiskan transaksi L1 untuk pengakuan pendapatan, jadi secara keseluruhan, pengalaman transaksi L1 dan transaksi L2 serupa.

Tetapi jika pengguna bersedia berkorban, dapatkah itu ditukar dengan pengalaman yang lebih baik?

Pra-Konfirmasi/Konfirmasi Cepat/Konfirmasi Lunak

Pengguna harus melihat Blok L2 (berisi transaksi L2) dimasukkan dalam Blok L1, dan bahkan menunggu sampai probabilitas terjadinya Re-org cukup rendah untuk percaya bahwa transaksi L2-nya telah diperoleh.

Tetapi bagaimana jika pengguna mau mempercayai Sequencer? Mungkin Sequencer dijalankan oleh tim pengembangan L2, dijalankan oleh organisasi terkemuka, dan jika Sequencer meyakinkan pengguna bahwa transaksinya akan segera dibayar, di Blok Xth, maka jaminan ini cukup bagi pengguna yang mau mempercayai Sequencer. Sama seperti jika pengguna mempercayai Dompet yang dia gunakan, dia tidak akan curiga pergi ke Etherscan untuk memeriksa ulang setelah Dompet memberi tahu dia bahwa transaksi telah dibayar.

Jaminan Pendapatan Transaksi yang diberikan oleh Sequencer ini disebut Pra-Konfirmasi, Konfirmasi Cepat, atau Konfirmasi Lunak, yang dapat dipahami sebagai jaminan pendapatan transaksi “awal” atau “lunak”. Tidak perlu menunggu transaksi L2 dimasukkan ke dalam blok L1, tetapi itu hanya janji lisan yang diberikan oleh Sequencer, dan Sequencer mungkin lupa janji asli karena bug atau Sequencer jahat akan langsung melanggar janji, yang dapat membuang waktu pengguna atau menjadi “Double Spend Attack”.

Selanjutnya, kita akan melihat beberapa cara berbeda di mana status pendapatan transaksi L2 disajikan.

Status pendapatan transaksi Arbitrum/Optimisme

Saat ini, pengguna yang mengirim transaksi di Arbitrum atau Optimism hampir dapat segera mendapatkan Tanda Terima Transaksi, yang akan menjadi hasil dari eksekusi transaksi. Ini berarti bahwa Sequencer telah mengurutkan dan mensimulasikan pelaksanaan transaksi secara lokal, dan tanda terima transaksi ini adalah pra-konfirmasi untuk pengguna.

Untuk mempelajari lebih lanjut tentang Arbitrum, deskripsi yang lebih rinci tentang siklus hidup transaksi dapat disalin ke tautan berikut ke dokumen resmi referensi browser:

Untuk pengenalan lebih rinci tentang siklus hidup transaksi Optimisme, silakan salin tautan berikut ke dokumen resmi referensi browser:

Periksa Status Pendapatan Transaksi di Arbitrum

Transaksi yang Anda lihat di Arbitrum Explorer akan berisi transaksi Pra-Konfirmasi, yaitu transaksi yang belum diunggah ke L1, seperti yang ditunjukkan pada gambar berikut, Anda dapat melihat bahwa ada indikator Dikonfirmasi oleh Sequencer di sebelah Nomor Blok 145353000:

Gambar di atas menunjukkan transaksi yang baru dikonfirmasi oleh Sequencer tetapi belum diunggah ke L1

Jika transaksi telah diunggah ke L1 seperti yang ditunjukkan pada gambar di bawah ini, statusnya telah berubah menjadi 69 Konfirmasi Blok L1, yang berarti telah diunggah ke L1 dan berisi data transaksi Blok dan ada 69 Blok di belakangnya:

Blok L1 yang berisi data transaksi ini sudah memiliki 69 Blok di belakangnya, dan semakin banyak Blok yang mengikutinya, semakin aman.

Atau transaksi yang ditunjukkan pada gambar di bawah ini, Blok L1 yang berisi data transaksi ini memiliki 6174 Blok di belakangnya, yang sudah sangat aman.

Tapi apa yang bisa dilakukan lebih baik di sini adalah menggabungkan informasi finalitas L1.

Cukup memberi tahu pengguna berapa banyak Konfirmasi Blok L1 yang ada adalah bantuan terbatas bagi pengguna, karena pengguna harus memahami dan menghitung tingkat keamanan yang diwakili oleh sejumlah Konfirmasi Blokir. Dan karena Layer 1 (yaitu Ethereum) sudah memiliki mekanisme finalitas seperti Casper FFG, Explorer sebenarnya dapat secara langsung menunjukkan apakah Blok Layer 1 saat ini diselesaikan di Layer 1. Saat ini, Explorer Optimism telah menerapkan fitur tersebut.

Periksa Status Penghasilan Transaksi pada Optimisme

Transaksi yang kita lihat di Optimism Explorer juga akan mencakup transaksi Pra-Konfirmasi, yaitu transaksi yang belum diunggah ke L1, seperti yang ditunjukkan pada gambar berikut, kita dapat melihat bahwa ada simbol Dikonfirmasi oleh Sequencer di sebelah Nomor Blok 111526300:

Transaksi yang baru dikonfirmasi oleh Sequencer tetapi belum diunggah ke L1

Namun, Explorer tampaknya tidak memiliki spesifikasi yang jelas tentang apa arti Dikonfirmasi oleh Sequencer, dengan mengatakan “Konfirmasi sequencer setara dengan beberapa konfirmasi blok pada L1.”, Menunjukkan bahwa Dikonfirmasi oleh Sequencer mewakili sejumlah Blok yang telah diunggah ke L1 dan telah diikuti oleh beberapa:

Namun nyatanya, transaksi terbaru juga ditampilkan sebagai Dikonfirmasi oleh Sequencer, dan bahkan puluhan hari yang lalu, status transaksi yang telah melewati masa challenge masih Dikonfirmasi oleh Sequencer:

Puluhan hari yang lalu, status transaksi masih macet di “Dikonfirmasi oleh Sequencer”

Tip membaca: Situasi di atas mungkin juga bahwa penjelajah menandai status yang berbeda di tempat yang berbeda: Dikonfirmasi Oleh Sequencer setelah Nomor Blok memberi tahu pengguna bahwa Blok telah dikonfirmasi oleh Sequencer, dan pengguna harus mengonfirmasi status setelah mengunggah ke L1 melalui informasi lain, seperti informasi “L1 State Batch” yang disebutkan di bawah ini.

Selain itu, transaksi yang telah diunggah ke L1 seperti yang ditunjukkan pada gambar di bawah ini memiliki dua informasi tambahan: “L1 State Batch Index” dan “L1 State Root Submission Tx Hash”. Dua informasi ini mewakili State Batch di mana transaksi L2 dimasukkan dan transaksi L1 di mana State Batch diunggah ke L1:

Klik pada State Batch “3480”, Anda dapat melihat bahwa statusnya Finalized, yang sesuai dengan status Finalized L1 (yaitu, Jaringan Utama Ethereum), yang merupakan state yang sangat aman yang telah berhasil mengumpulkan suara dari dua validator Epoch.

△ State Batch 3480 telah diakuisisi di L1 Block 18457449, dan Block 18457449 telah diselesaikan.

Sumber:

Jika batch telah diunggah tetapi belum diselesaikan di L1, itu akan ditampilkan sebagai Belum selesai:

Meskipun State Batch 3494 telah diunggah ke L1, blok L1 yang disertakan dalam batch belum diselesaikan.

Dibandingkan dengan Arbitrum Explorer, Optimism Explorer memberikan lebih banyak informasi (State Batch) untuk transaksi, dan akan langsung merangkai informasi Finalitas L1 ke L2 Explorer, sehingga pengguna dapat langsung mengetahui apakah Blok L1 telah diselesaikan, daripada menilai tingkat keamanan yang sesuai dengan jumlah Konfirmasi Blok.

Status Penghasilan Perdagangan StarkNet

Saat ini, setelah pengguna mengirim transaksi di StarkNet, meskipun penerimaan transaksi dapat ditanyakan dengan cepat, status transaksi yang ditampilkan dalam tanda terima biasanya akan dalam keadaan DITERIMA, yang berarti bahwa Node telah menerima transaksi dan tidak ada masalah setelah transaksi diverifikasi, dan akan menunggu transaksi diterima oleh Sequencer L2 Block dan dieksekusi, sedangkan transaksi dalam keadaan RECEIVED tidak akan memiliki hasil eksekusi transaksi. Pengguna dapat memeriksa kemajuan transaksi mereka melalui status transaksi yang ditampilkan di StarkNet Explorer.

Tips membaca: Jika Sequencer memproses cukup cepat, Anda dapat melewati status RECEIVED dan pergi ke status tempat transaksi telah diproses. Untuk pengenalan yang lebih rinci tentang proses perdagangan StarkNet, Anda dapat menyalin tautan di bawah ini untuk melihat dokumen resmi di browser Anda.

Dokumen Resmi: _and_concepts/Network_Architecture/transaction-life-cycle/

Transaksi yang terlihat di Starkscan, StarkNet Explorer, juga akan mencakup transaksi Pra-Konfirmasi, seperti yang ditunjukkan pada gambar berikut, Anda dapat melihat bahwa Status saat ini Diterima di L2, yang berarti bahwa ia telah diberi peringkat ke dalam Blok L2 oleh Sequencer:

“Diterima di L2” berarti telah ditempatkan di blok L2 oleh Sequencer, tetapi belum diunggah ke L1

Dua status pertama Diterima di L2 adalah Diterima dan Tertunda, yang berarti bahwa “transaksi telah diterima dan diverifikasi” dan “transaksi sedang diproses oleh Sequencer”, dan transaksi akan memasuki status Diterima di L2 setelah transaksi dijalankan:

Transaksi diterima dan diverifikasi

Transaksi sedang diproses oleh Sequencer

Setelah data transaksi diunggah ke L1, status akan berubah menjadi Diterima di L1, seperti yang ditunjukkan pada gambar berikut:

Data transaksional telah diunggah ke L1

Meskipun transaksi StarkNet memiliki status yang lebih kaya yang memungkinkan pengguna mengetahui kemajuan transaksi, mungkin diperlukan waktu empat atau lima jam agar transaksi diunggah ke L1 (mungkin karena butuh waktu lama untuk menghasilkan Bukti Tanpa Pengetahuan), sehingga pengguna selama ini mengandalkan pra-konfirmasi Sequencer.

Selain itu, Explorer hanya menampilkan Diterima di L1 untuk transaksi yang diunggah ke L1, dan tidak memiliki informasi Finalitas atau Konfirmasi Blok dengan L1, yang berarti bahwa pengguna harus memeriksa apakah ada cukup Blok di Blok L1 atau apakah mereka telah diselesaikan.

Secara keseluruhan, karena hambatan kinerja StarkNet itu sendiri, pengguna perlu mengandalkan Pra-Konfirmasi untuk waktu yang lama, dan Explorer tidak mendukung informasi finalitas L1, yang mengakibatkan pengalaman buruk pengenalan pendapatan transaksi StarkNet, di situlah StarkNet perlu ditingkatkan di masa depan.

Status Pendapatan Transaksi zkSync

Mirip dengan StakrNet, zkSync juga memiliki status DEJUDI, yang berarti bahwa Node telah menerima transaksi dan transaksi telah diverifikasi tanpa masalah, ia akan menunggu transaksi diblokir dan dieksekusi oleh Sequencer L2, sedangkan transaksi dalam status PENDING tidak akan memiliki hasil eksekusi transaksi.

Pengguna dapat mengetahui kemajuan transaksi mereka melalui status transaksi yang ditampilkan pada zkSync Explorer.

Tips membaca: Jika Sequencer memproses cukup cepat, Anda dapat melewati status PENDING dan pergi ke status tempat transaksi telah diproses.

Untuk pengenalan lebih rinci tentang proses transaksi zkSync, Anda dapat menyalin tautan berikut untuk melihatnya di browser Anda:

Transaksi yang Anda lihat di zkSync Explorer juga akan menyertakan transaksi Pra-Konfirmasi, seperti yang ada pada tangkapan layar di bawah ini, Anda dapat melihat bahwa Status saat ini zkSync Era Diproses, yang berarti telah diberi peringkat ke dalam Blok L2 oleh Sequencer:

Transaksi ini telah ditempatkan di blok L2 oleh Sequencer dan saat ini sedang menunggu untuk diunggah ke L1 (Ethereum Sending)

Setelah Sequencer membuat Blok L2, Blok dan transaksi di dalamnya akan melalui tiga fase secara berurutan: Committed, Proven, dan uted, yang menunjukkan bahwa “Block has been upload to L1”, “Block validity has been proven”, dan “L2 status has been updated to L1 after the Block transaction has been executed”. Blok dan transaksi pada tahap yang berbeda ditunjukkan di bawah ini:

Batch 292700 telah diunggah ke L1 dan berada dalam fase Komitmen. Sumber:

Status transaksi saat ini di Batch 292700 telah berubah dari Pengiriman Ethereum ke Validasi Ethereum, menunjukkan bahwa ia sedang menunggu untuk diverifikasi oleh Bukti Tanpa Pengetahuan.

Memindahkan panah ke ikon Validasi Ethereum juga akan menunjukkan tahapan yang berbeda, dan tautan transaksi dari tahap sebelumnya (Pengiriman) juga akan dilampirkan:

Transaksi ini memasuki tahap “Memvalidasi”, dan tautan ke transaksi yang mengunggah Batch ke L1 pada tahap sebelumnya (Pengiriman) juga dapat dilihat di sini.

Efektivitas Batch 292000 sudah terbukti, sehingga masuk ke fase Proven :

Setelah Batch terbukti, ia memasuki status Terbukti dengan tautan ke transaksi yang menjalankan tindakan Buktikan.

Transaksi juga akan beralih dari “validasi” ke “uting”, yaitu menunggu untuk dieksekusi.

Ketika batch terbukti, kemudian masuk ke masa tunggu (sekitar 21 jam dalam dokumen resmi) sebelum transaksi di dalamnya dieksekusi dan status L2 yang dicatat pada L1 diperbarui. Hal ini terutama disebabkan oleh perlindungan yang telah ditambahkan dalam fase alfa untuk memastikan bahwa ada cukup waktu untuk bereaksi terhadap bug yang muncul. Ketika batch dijalankan, ia memasuki fase uted akhir:

Setelah batch dijalankan, batch memasuki status uted akhir dengan tautan transaksi yang mengeksekusi tindakan ute.

Status transaksi di Batch juga telah diperbarui menjadi “uted”

Berbeda dengan StarkNet, di mana transaksi L2 ke L1 diselesaikan dalam satu langkah, proses zkSync memindahkan L2 ke L1 dipecah menjadi tiga tahap yang lebih rinci: Berkomitmen → Terbukti → uted.

Sementara seluruh proses transaksi diperpanjang hingga sekitar satu hari atau lebih sebagai perlindungan, status Committed memungkinkan pengguna untuk dengan cepat mengetahui apakah transaksi telah diperoleh (dan tidak lagi hanya pra-konfirmasi setelah transaksi memasuki Committed) tanpa harus bergantung pada kepercayaan pada Sequencer secara berkelanjutan.

Selain itu, zkSync Explorer menyediakan tampilan data yang kaya dan lengkap untuk berbagai tahap, sehingga siapa pun dapat memahami status transaksi terbaru melalui explorer, dan bahkan dapat secara pribadi memverifikasi pelaksanaan transaksi dari setiap transisi tahap (seperti dari Berkomitmen ke Terbukti, dari Terbukti ke uted).

Namun, perlu dicatat bahwa sebagai tindakan perlindungan untuk fase alfa, riwayat dapat dimodifikasi oleh zkSync Sequencer saat ini.

Ini menunjukkan bahwa meskipun transaksi dapat dengan cepat keluar dari pra-konfirmasi dan memasuki fase komitmen, Sequencer sebenarnya dapat menghapus transaksi pengguna dari riwayat sebelum transaksi memasuki fase uted. Oleh karena itu, konsumen tetap perlu mempercayai Sequencer hingga sehari.

L1 juga dapat mendukung Pra-Konfirmasi

Jika Anda dapat mengetahui sebelumnya siapa yang bertanggung jawab untuk memproduksi blok, maka L1 juga dapat mendukung pra-konfirmasi.

Mengambil Ethereum sebagai contoh, orang yang benar-benar menghasilkan blok adalah Builder, dan Builder dapat memberikan layanan Pra-Konfirmasi untuk memberi pengguna jaminan pendapatan transaksi. Namun karena Builder belum tentu mendapatkan hak atas output tertentu dan Blok tertentu, tetapi harus menawar hak atas setiap output Blok, sehingga efektivitas Pra-Konfirmasi ini akan relatif buruk, dan kekuatan Builder harus dipertimbangkan, jika Builder tidak cukup kompetitif, maka sulit bagi Builder untuk mendapatkan hak memproduksi Block, sehingga Pra-Konfirmasi diberikan oleh Builder Layanan ini akan sangat terganggu.

Jika Anda ingin menghindari masalah di atas, lebih baik meminta Pengusul menyediakan layanan Pra-Konfirmasi, karena “Pengusul mana yang akan mengusulkan Blok pertama” biasanya merupakan situasi deterministik yang telah dihitung sebelumnya.

Namun, karena dalam arsitektur PBS saat ini, Proposer hanya mengusulkan peran Block, dan peran benar-benar membuat Block dan menentukan isi Block adalah Builder, sehingga Proposer tidak dapat langsung memasukkan transaksi ke dalam Block atau meminta Builder untuk memasukkan transaksi. Ketika arsitektur PBS berubah di masa depan, seperti menambahkan Daftar Inklusi atau memungkinkan Pengusul untuk berpartisipasi dalam produksi blok, Pengusul akan memiliki kesempatan untuk menyediakan layanan Pra-Konfirmasi.

Tips Membaca: Untuk informasi lebih lanjut tentang PBS, silakan salin tautan di bawah ini untuk membaca di browser Anda: _4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss.

Tingkatkan Pra-Konfirmasi

Pra-Konfirmasi hanyalah janji lisan oleh Builder atau L2 Sequencer, dan pihak lain tidak memiliki kewajiban untuk memenuhi janji tersebut, dan tidak ada mekanisme penalti untuk tidak dipenuhi.

Apakah mungkin untuk membuat janji ini lebih terjamin? Sebenarnya, ya, karena orang yang bertanggung jawab untuk memproduksi Blok dan isi janjinya (misalnya “dalam 1.350.000 Blok transaksi pendapatan”) dapat ditulis sebagai pemeriksaan kondisi. Oleh karena itu, kita dapat menggunakan kontrak pintar untuk mengatur Builder atau Sequencer, meminta mereka untuk menyediakan layanan Pra-Konfirmasi saat menjaminkan deposit dalam Smart Contract, dan menandatangani konten saat memberikan janji pendapatan transaksi, ketika pengguna menemukan bahwa Builder atau Sequencer belum memenuhi komitmen, konten yang dijanjikan dan tanda tangan pihak lain dapat dikirim ke Smart Contract, dan Smart Contract dapat memeriksa apakah komitmen telah terpenuhi (seperti “di yang pertama 1.350.000 Block Revenue untuk transaksi ini”).

Meskipun skenario aplikasi dari kontrak di atas masih dalam tahap proof-of-concept, video presentasi yang ditunjukkan pada tautan di bawah ini memberi tahu contoh salah satu aplikasi kontrak, silakan salin tautan di bawah ini untuk melihat detailnya di browser Anda:

Ringkasan

• Setelah transaksi L1 dimasukkan dalam blok L1, kemungkinan Re-org akan turun secara bertahap, dan kepercayaan pengguna terhadap pendapatan transaksi akan meningkat secara bertahap.
• Satu lagi alur kerja transaksi untuk transaksi L2 daripada transaksi L1 adalah tahap di mana transaksi L2 termasuk dalam blok L2 dan menunggu untuk diunggah ke L1.
• Namun, pada alur transaksi dimana transaksi L2 lebih banyak daripada transaksi L1, karena data belum diunggah ke L1 pada tahap ini, masih terdapat kemungkinan variabel, sehingga jaminan pendapatan transaksi yang dapat diperoleh pengguna pada tahap ini adalah janji lisan Sequencer, yang disebut Pre-Confirmation atau Fast Confirmation, Soft Confirmation.
• Jika Sequencer berbahaya, atau jika ada bug sederhana, maka janji yang dibuat oleh Sequencer dapat dilanggar, sehingga tidak ada pengakuan pendapatan untuk transaksi L2 pengguna.
• Saat ini, sebagian besar status transaksi L2 di Explorer mereka menyertakan status Pra-Konfirmasi, seperti Dikonfirmasi oleh Sequencer untuk Arbitrum/Optimisme atau Diterima di L2 untuk StarkNet. Ketika Anda melihat informasi tersebut, harap perhatikan validitas waktu jaminan pendapatan transaksi yang diberikan oleh informasi ini.
• Jika Anda tidak ingin mempercayai Pra-Konfirmasi yang disediakan oleh Sequencer, Anda harus menunggu sedikit lebih lama dan memverifikasi dengan informasi yang diberikan oleh L2 Explorer tentang data L2 yang diunggah ke L1.
• Pra-Konfirmasi dapat digabungkan dengan desain insentif ekonomi, seperti penalti melalui Smart Contract ketika Sequencer melanggar komitmen, sehingga pengguna bisa mendapatkan perlindungan yang lebih jelas.

Tabel di bawah ini menggambarkan jaminan pendapatan transaksi dan skenario risiko terkait yang disediakan oleh transaksi L1 dan transaksi L2 pada berbagai tahap proses transaksi: