Kapan seseorang dapat yakin bahwa transaksi L2 (Layer 2) akan disertakan dalam blok? Kapan seseorang dapat 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 pada setiap tahap proses transaksi.

Pengetahuan Awal:

• Seluruh proses transaksi L1 (Layer 1)
• Alasan dan dampak kejadian Re-org
• Memahami peran dan metode operasi dalam arsitektur Ethereum PBS saat ini
• Perbedaan antara Optimistic Rollup dan Validity (ZK) Rollup

Memahami transaksi L1

Proses Transaksi

Setelah pengguna mengeluarkan dan menandatangani transaksi, transaksi dikirim ke jaringan p2p, menunggu penyertaan dalam blok oleh Penambang di bawah mekanisme konsensus Proof of Work (PoW) atau Pengusul di bawah mekanisme konsensus Proof of Stake (PoS). Ketika pengguna memperhatikan transaksi mereka telah dimasukkan dalam blok terbaru, belum pasti bahwa transaksi tersebut akan dicatat secara permanen dalam riwayat blockchain. Ketidakpastian ini disebabkan oleh kemungkinan "Re-org" (reorganisasi) yang terjadi di blockchain. Pengguna harus menunggu sampai kemungkinan Re-org terjadi cukup rendah untuk yakin bahwa transaksi mereka akan dicatat secara permanen dalam sejarah blockchain.

Proses Transaksi L1 Diilustrasikan

Bahkan setelah transaksi dimasukkan ke dalam blok, Re-org masih bisa terjadi, artinya konfirmasi hanya dapat dipastikan ketika probabilitas Re-org menjadi tidak mungkin.

Kemungkinan dan biaya Re-org bervariasi dengan algoritma konsensus blockchain masing-masing dan nilai pasar asetnya. Dokumen ini tidak akan membahas metode perhitungan biaya Re-org.

Memahami Transaksi L2

Proses Transaksi

Pengguna L2 menghasilkan dan menandatangani transaksi, biasanya mengirimkannya langsung ke Pemroses, yang kemudian menyertakan transaksi tersebut dalam blok L2. Selanjutnya, ketika Pemroses memposting data blok L2 kembali ke L1 melalui transaksi L1, pengguna dapat melihat transaksi mereka disertakan dalam blok L2 terbaru.

Namun, penting untuk dicatat bahwa karena data blok L2 diposting ke L1 melalui transaksi L1, masih mungkin terjadi Re-org L1, yang berpotensi menyebabkan blok L2 tidak tercatat secara permanen dalam sejarah blockchain. Skenario ini mirip dengan Re-org L2, sehingga pengguna harus menunggu hingga probabilitas Re-org L1 cukup rendah untuk yakin bahwa transaksi mereka akan tercatat secara permanen dalam sejarah blockchain.

Proses Transaksi L2 diilustrasikan

Pengguna harus menunggu transaksi mereka terlebih dahulu dimasukkan ke dalam blok L2, kemudian blok L2 diposting ke L1 melalui transaksi L1, dan akhirnya transaksi L1 diselesaikan.

Meskipun transaksi L2 melibatkan waktu tunggu tambahan untuk disertakan dalam blok L2 oleh Pemutus dibandingkan dengan transaksi L1, waktu tunggu ini umumnya singkat jika kapasitas blok L2 besar dan generasi blok cepat, karena periode tunggu utama adalah untuk transaksi L1 dikonfirmasi. Dengan demikian, pengalaman pengguna secara keseluruhan dari transaksi L1 dan L2 mirip.

Prapesan/Konfirmasi Cepat/Konfirmasi Lunak

Pengguna harus memverifikasi sendiri bahwa transaksi L2 mereka, bersama dengan blok L2, telah dimasukkan ke dalam blok L1, dan bahkan menunggu hingga probabilitas Re-org cukup rendah untuk mempercayai bahwa transaksi L2 mereka telah dimasukkan.

Tetapi bagaimana jika pengguna bersedia untuk mempercayai Sequencer? Sequencer bisa dioperasikan oleh tim pengembangan L2 atau institusi terkemuka. Jika Sequencer menjamin pengguna segera setelah menerima transaksi mereka bahwa mereka akan disertakan dalam blok tertentu, jaminan ini mungkin cukup bagi mereka yang bersedia mempercayai Sequencer. Hal ini mirip dengan pengguna yang mempercayai aplikasi dompet mereka dan tidak obsesif memeriksa Etherscan untuk konfirmasi setelah diberitahu tentang inklusi transaksi.

Jaminan-jaminan yang diberikan oleh Sequencer disebut sebagai Pra-Konfirmasi, Konfirmasi Cepat, atau Konfirmasi Lembut. Ini dianggap sebagai jaminan "preliminer" atau "lemah" tentang inklusi transaksi, yang tidak memerlukan transaksi L2 untuk disertakan dalam blok L1. Namun, ini hanyalah komitmen lisan dari Sequencer, yang mungkin dilupakan karena bug atau sengaja dilanggar oleh Sequencer jahat, yang pada kasus terburuk dapat mengakibatkan serangan pengeluaran ganda.

Selanjutnya, kami akan memperkenalkan berbagai cara status inklusi transaksi L2 disajikan.

Status Pengikutsertaan Transaksi Arbitrum/Optimism

Saat ini, pengguna di Arbitrum atau Optimism hampir seketika dapat menerima tanda terima transaksi setelah mengirim transaksi, menunjukkan hasil dari eksekusi transaksi. Ini menandakan bahwa Sequencer telah melakukan pengurutan lokal dan simulasi transaksi, memberikan pengguna Pre-Konfirmasi.

Pelajari Lebih Lanjut

Untuk informasi lebih detail mengenai siklus transaksi Arbitrum, lihat dokumentasi resmi:https://docs.arbitrum.io/tx-lifecycle

Untuk informasi lebih detail tentang siklus transaksi Optimism, lihat dokumentasi resmi: https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Status Pendapatan Trading untuk Arbitrum/Optimism

Saat ini, setelah pengguna mengirim transaksi di Arbitrum atau Optimism, mereka hampir segera mendapatkan tanda terima transaksi (Transaction Receipt), yang akan berisi hasil dari eksekusi transaksi. Ini berarti bahwa Sequencer telah melakukan pengurutan transaksi secara lokal dan mensimulasikannya sekali. Tanda terima transaksi ini adalah Pra-Konfirmasi yang diberikan kepada pengguna.

pelajari lebih lanjut

Untuk pengenalan yang lebih detail tentang siklus hidup transaksi Arbitrum, Anda dapat menyalin tautan di bawah ini ke browser untuk merujuk ke dokumen resmi:

https://docs.arbitrum.io/tx-lifecycle

Untuk pengenalan yang lebih detail tentang siklus hidup transaksi Optimism, Anda dapat menyalin tautan di bawah ini ke peramban dan merujuk ke dokumen resmi:

https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Periksa status pendapatan transaksi di Arbitrum

Transaksi yang terlihat di Arbiter Explorer akan mencakup transaksi Pra-Konfirmasi, yaitu, transaksi yang belum diunggah ke L1. Untuk transaksi ini seperti yang ditunjukkan dalam gambar di bawah, Anda dapat melihat tanda Dikonfirmasi oleh Penyusun di sebelah Nomor Blok 145353000:

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

Jika itu adalah transaksi yang telah diunggah ke L1 seperti yang ditunjukkan dalam gambar di bawah, statusnya telah berubah menjadi 69 Konfirmasi Blok L1, yang berarti bahwa itu telah diunggah ke L1 dan blok Layer1 yang berisi data transaksi telah Ada 69 blok yang mengikutinya:

Blok L1 yang berisi data transaksi ini sudah memiliki 69 blok yang mengikuti. Semakin banyak blok yang mengikuti, semakin aman.

Atau untuk transaksi ini seperti yang ditunjukkan dalam tangkapan layar di bawah, blok L1 yang berisi data transaksi ini sudah memiliki 6174 blok mengikuti, yang sudah sangat aman.

Namun sebenarnya, yang dapat dilakukan lebih baik di sini adalah menyajikannya dengan informasi Finality dari L1.

Hanya memberi tahu pengguna berapa banyak Konfirmasi Blok L1 yang ada memiliki manfaat terbatas bagi pengguna, karena pengguna harus memahami dan menghitung tingkat keamanan yang diwakili oleh jumlah Konfirmasi Blok tersebut. Dan karena Layer1 (yaitu, Ethereum) sudah memiliki mekanisme Finality seperti Casper FFG, Explorer sebenarnya dapat langsung menampilkan apakah blok Layer1 telah Finalized di Layer1. Saat ini, Explorer Optimism telah mengimplementasikan fungsi tersebut.

Memeriksa Status Tanda Terima Transaksi di Optimism

Transaksi yang dilihat di Optimism Explorer mungkin termasuk yang ditandai sebagai Pra-Konfirmasi, menunjukkan bahwa mereka belum diposting ke Layer 1 (L1). Seperti yang diilustrasikan di bawah ini, transaksi dengan Nomor Blok 111526300 ditandai sebagai "Dikonfirmasi oleh Penjalin":

Transaksi hanya dikonfirmasi oleh Pemroses tetapi belum diposting ke L1

Saat ini, Explorer tampaknya kurang memiliki definisi yang jelas untuk "Dikonfirmasi oleh Sequencer," yang menyarankan bahwa "konfirmasi Sequencer setara dengan beberapa konfirmasi blok di L1." Hal ini menyiratkan bahwa "Dikonfirmasi oleh Sequencer" berarti transaksi telah diposting ke L1 dan memiliki beberapa blok yang mengikutinya:

Namun, transaksi yang baru muncul juga ditampilkan sebagai “Dikonfirmasi oleh Penentu Urutan,” dan bahkan transaksi dari beberapa hari yang lalu, yang telah melewati periode tantangan, tetap berada dalam status “Dikonfirmasi oleh Penentu Urutan”:

Transaksi dari beberapa hari yang lalu masih dalam status "Dikonfirmasi oleh Pemeta"

Catatan bacaan: Situasi ini mungkin juga karena Explorer menyajikan indikator status yang berbeda di berbagai tempat: "Dikonfirmasi Oleh Sequencer" di sebelah Nomor Blok memberi tahu pengguna bahwa blok telah dikonfirmasi oleh Sequencer. Untuk memverifikasi status pasca-L1, pengguna harus merujuk ke informasi lain, seperti rincian "L1 State Batch" yang dibahas di bawah ini.

Selain itu, seperti yang ditunjukkan dalam tangkapan layar di bawah ini, sebuah transaksi yang telah diposting ke L1 mencakup dua informasi tambahan: "Indeks Batch Status L1" dan "Hash Transaksi Pengiriman Root Status L1." Detail-detail ini mewakili Batch Status mana transaksi L2 termasuk di dalamnya dan melalui transaksi L1 mana Batch Status ini diposting ke L1:

Dengan mengklik “State Batch 3480,” statusnya ditampilkan sebagai Finalized, sesuai dengan status Finalized di L1 (yaitu, jaringan utama Ethereum), yang merupakan status yang sangat aman yang dicapai setelah mengumpulkan suara dari validator selama dua epochs.

△ State Batch 3480 disertakan dalam Blok L1 18457449, dan Blok 18457449 telah Diselesaikan.

Sumber: https://etherscan.io/block/18457449

Jika Batch telah diposting namun belum Difinalisasi di L1, maka akan ditampilkan sebagai Belum Difinalisasi:

Batch Negara 3494, meskipun diposting ke L1, termasuk dalam Blok L1 yang belum Selesai：

Dibandingkan dengan Arbiter Explorer, Optimism Explorer menyediakan informasi yang lebih detail (Batch Negara) dan langsung menghubungkan informasi Finalitas L1 ke Explorer L2, memungkinkan pengguna untuk mengetahui apakah blok L1 telah Difinalisasi, daripada membuat penilaian sendiri berdasarkan jumlah Konfirmasi Blok untuk tingkat keamanan.

Status Pendapatan Transaksi StarkNet

Saat ini, ketika pengguna mengirim transaksi di StarkNet, mereka dapat dengan cepat memeriksa tanda terima transaksi. Namun, tanda terima sering menunjukkan status transaksi sebagai DITERIMA. Status ini menunjukkan bahwa node telah menerima transaksi dan setelah verifikasi, tidak ditemukan masalah. Transaksi menunggu untuk dimasukkan dalam blok L2 oleh Pemroses dan dieksekusi. Transaksi dalam status DITERIMA belum akan menunjukkan hasil dari eksekusi. Pengguna dapat memeriksa kemajuan transaksi mereka dengan melihat status transaksi yang ditampilkan di StarkNet Explorer.

Tips Membaca: Jika Sequencer memproses transaksi dengan cukup cepat, maka ia mungkin melewati status DITERIMA dan langsung beralih ke status diproses. Untuk pengenalan yang lebih detail terhadap proses transaksi di StarkNet, Anda dapat menyalin tautan di bawah ini ke peramban Anda untuk berkonsultasi pada dokumen resmi.

Dokumen Resmi:Siklus Hidup Transaksi StarkNet

Transaksi yang terlihat di Starkscan, sebuah Penjelajah StarkNet, juga mencakup transaksi Pra-Konfirmasi. Seperti yang ditunjukkan dalam transaksi berikut, Status saat ini adalah "Diterima di L2," menunjukkan bahwa itu telah dimasukkan oleh Pemangkas ke dalam blok L2.

Diterima di L2" berarti telah diantrekan oleh Sequencer ke blok L2, tetapi belum diunggah ke L1.

Dua status sebelum "Diterima di L2" adalah Diterima dan Tertunda, yang mewakili "transaksi telah diterima dan diverifikasi" dan "transaksi sedang diproses oleh Pengurutan," secara berturut-turut. Setelah eksekusi pemrosesan transaksi selesai, maka akan berpindah ke status "Diterima di L2":

Transaksi telah diterima dan diverifikasi.

Transaksi sedang diproses oleh Sequencer.

Setelah data transaksi diunggah ke L1, status akan berubah menjadi “Diterima di L1,” seperti yang ditunjukkan dalam transaksi berikut:

Data transaksi telah diunggah ke L1.

Meskipun transaksi StarkNet memiliki kumpulan status yang lebih kaya untuk memberi tahu pengguna tentang kemajuan pemrosesan, mengunggah transaksi ke L1 mungkin masih memerlukan waktu tunggu beberapa jam (mungkin karena pembuatan bukti pengetahuan nol memerlukan waktu lebih lama). Selama ini, pengguna bergantung pada Konfirmasi Awal Sequencer.

Selain itu, Explorer hanya menampilkan "Diterima di L1" untuk transaksi yang diunggah ke L1, tanpa informasi pendamping tentang Finality L1 atau Konfirmasi Blok. Ini berarti pengguna harus memeriksanya sendiri apakah blok L1 memiliki cukup blok berikutnya atau telah Difinalisasi.

Secara keseluruhan, karena kendala kinerja StarkNet, pengguna perlu mengandalkan Pra-Konfirmasi untuk jangka waktu yang lebih lama, dan Explorer tidak mendukung informasi Finalitas L1, menyebabkan pengalaman pengguna yang kurang memuaskan untuk konfirmasi pendapatan transaksi. Ini adalah area di mana StarkNet perlu memperbaiki di masa depan.

Status pendapatan transaksi zkSync

Seperti StakrNet, zkSync juga memiliki status PENDING, yang berarti bahwa node telah menerima transaksi dan tidak ada masalah setelah transaksi diverifikasi. Ini akan menunggu untuk disertakan dalam blok L2 oleh Sequencer dan dieksekusi. Namun, tidak ada transaksi yang akan dieksekusi dalam status PENDING tersebut. hasil dari.

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

Tips membaca: Jika Sequencer diproses cukup cepat, mungkin memungkinkan untuk langsung melewati status PENDING dan masuk ke status di mana transaksi telah diproses.

Untuk pengenalan yang lebih detail terhadap proses transaksi zkSync, Anda dapat menyalin tautan di bawah ini dan melihatnya di browser Anda: https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

Transaksi yang terlihat pada zkSync Explorer juga akan mencakup transaksi Pra-Konfirmasi, seperti transaksi dalam tangkapan layar di bawah ini. Anda dapat melihat bahwa Status saat ini adalah Diproses Era zkSync, menunjukkan bahwa telah dimasukkan dalam blok L2 oleh Sequencer:

Transaksi ini telah dimasukkan ke dalam blok L2 oleh Sequencer dan saat ini menunggu untuk diunggah ke L1 (Ethereum Sending)

Setelah Sequencer menyelesaikan blok L2, blok dan transaksi di dalamnya akan melalui tiga tahap yaitu Terverifikasi, Terbukti, dan Dieksekusi, yang masing-masing berarti “blok telah diunggah ke L1” dan “validitas blok telah dibuktikan”. Dan “status L2 diperbarui ke L1 setelah transaksi dalam blok dieksekusi.” Berikut ini menunjukkan tiga blok dan transaksi pada tahapan yang berbeda:

Batch 292700 telah diunggah ke L1 dan masuk ke tahap Terikat. Sumber: https://explorer.zksync.io/batch/292700

Status terkini transaksi dalam Batch 292700 telah berubah dari Pengiriman Ethereum menjadi Validasi Ethereum, menunjukkan bahwa transaksi sedang menunggu diverifikasi oleh bukti pengetahuan nol untuk memverifikasi keabsahannya.

Menggerakkan panah di atas ikon Ethereum Validating juga akan menunjukkan tahapan-tahapan yang berbeda, dan tautan transaksi untuk tahapan sebelumnya (Mengirim) juga akan dilampirkan:

Transaksi ini telah memasuki tahap “Validating”. Tautan transaksi untuk mengunggah Batch ke L1 di tahap sebelumnya (Mengirim) juga dapat dilihat langsung di sini.

Efektivitas Batch 292000 telah terbukti, sehingga memasuki tahap Terbukti:

Setelah Batch terbukti, masuk ke dalam status Terbukti, dan tautan transaksi untuk menjalankan tindakan Terbukti dilampirkan.

Transaksi di dalam juga akan masuk ke tahap “Menjalankan” dari “Memvalidasi”, yang menunggu untuk dieksekusi.

Ketika Batch terbukti, maka akan memasuki periode penantian (dokumen resmi menyebutkan sekitar 21 jam) sebelum menjalankan transaksi di dalamnya dan memperbarui status L2 yang tercatat di L1. Ini terutama karena langkah perlindungan yang masih berada dalam tahap Alpha untuk memastikan bahwa ada cukup waktu untuk bereaksi ketika ada bug. Ketika Batch dijalankan, maka akan memasuki fase Eksekusi final:

Setelah Batch dieksekusi, masuk ke dalam state Terakhir dieksekusi, dan tautan transaksi untuk mengeksekusi tindakan Eksekusi dilampirkan.

Status transaksi dalam batch juga diperbarui menjadi “Dieksekusi”. Berbeda dengan transaksi StarkNet, yang diselesaikan dari Layer 2 (L2) ke Layer 1 (L1) dalam satu langkah, zkSync memecah proses transaksi dari L2 ke L1 menjadi tiga tahap yang lebih rinci: Terkomitmen → Terbukti → Dieksekusi. Meskipun ini memperpanjang seluruh proses transaksi menjadi sekitar satu hari sebagai langkah perlindungan, status Terkomitmen memungkinkan pengguna untuk segera mengetahui apakah transaksi mereka sudah dimasukkan (sekalipun transaksi masuk ke tahap Terkomitmen, itu bukan lagi hanya Pra-Konfirmasi), tanpa terus-menerus bergantung pada kepercayaan pada Pemenggal. Selain itu, zkSync Explorer menyediakan tampilan data yang komprehensif dan lengkap untuk berbagai tahap, memungkinkan siapa pun untuk memahami status terbaru transaksi dan bahkan memverifikasi secara pribadi eksekusi transaksi pada setiap transisi tahap (misalnya, dari Terkomitmen ke Terbukti, dari Terbukti ke Dieksekusi). Namun, penting untuk dicatat bahwa, sebagai langkah perlindungan dalam tahap Alpha, Pemenggal zkSync dapat memodifikasi catatan historis. Hal ini menunjukkan bahwa meskipun transaksi dapat dengan cepat bergerak melewati Pra-Konfirmasi untuk masuk ke tahap Terkomitmen, Pemenggal masih dapat menghapus transaksi pengguna dari catatan historis sampai mencapai tahap Dieksekusi. Oleh karena itu, pengguna tetap perlu mempercayai Pemenggal selama satu hari penuh.

Layer 1 juga dapat mendukung Pra-Konfirmasi

Jika diketahui sebelumnya siapa yang bertanggung jawab untuk memproduksi blok, maka L1 juga dapat mendukung Pra-Konfirmasi. Mengambil Ethereum sebagai contoh, produsen blok sebenarnya adalah Builder, yang dapat menawarkan layanan Pra-Konfirmasi, memberikan jaminan kepada pengguna akan inklusi transaksi. Namun, karena Builder tidak selalu memiliki hak untuk memproduksi blok tertentu tetapi harus mengajukan penawaran untuk hak memproduksi setiap blok, efektivitas Pra-Konfirmasi bisa menjadi lebih lemah. Selain itu, daya saing Builder harus dipertimbangkan; jika seorang Builder tidak cukup kompetitif, akan sulit bagi mereka untuk mengamankan hak untuk memproduksi blok, sehingga secara signifikan mengurangi keandalan layanan Pra-Konfirmasi mereka. Untuk menghindari masalah ini, pendekatan yang lebih baik adalah memungkinkan Proposers untuk memberikan layanan Pra-Konfirmasi, karena biasanya sudah ditentukan dan pasti siapa Proposer yang akan mengusulkan blok tertentu. Namun, dalam arsitektur PBS saat ini, Proposers hanya mengusulkan blok, dan produksi blok sebenarnya serta pengambilan keputusan konten dilakukan oleh Builders, sehingga Proposers tidak dapat langsung menyisipkan transaksi ke dalam blok atau menuntut Builder untuk melakukannya. Di masa depan, jika arsitektur PBS berubah, misalnya, dengan menambahkan Daftar Inklusi atau memungkinkan Proposers untuk berpartisipasi dalam produksi blok, Proposers mungkin memiliki kesempatan untuk menawarkan layanan Pra-Konfirmasi. Untuk informasi lebih lanjut tentang PBS, silakan kunjungi tautan yang diberikan.

Meningkatkan Pra-Konfirmasi:

Pre-Confirmation hanyalah komitmen verbal oleh Builders atau L2 Sequencers, tanpa kewajiban untuk memenuhi janji dan tanpa mekanisme hukuman atas ketidakpenuhiannya. Namun, adalah mungkin untuk membuat komitmen ini lebih dapat diandalkan dengan menggunakan kontrak pintar untuk standarisasi Builders atau Sequencers. Mereka dapat menyediakan layanan Pre-Confirmation sambil juga mendepositkan obligasi dalam kontrak pintar, dan menandatangani konten saat membuat janji inklusi transaksi. Jika pengguna menemukan bahwa Builders atau Sequencers tidak memenuhi janjinya, mereka dapat mengajukan konten janji dan tandatangan ke kontrak pintar, yang kemudian dapat memverifikasi apakah janji tersebut telah dipenuhi. Meskipun skenario aplikasi kontrak di atas masih dalam tahap proof-of-concept, tautan di bawah ini menunjukkan video presentasi contoh aplikasi kontrak tersebut.

Ringkasan:

Setelah transaksi L1 disertakan dalam blok L1, probabilitas reorganisasi menurun, dan kepercayaan pengguna dalam penyertaan transaksi secara bertahap meningkat. Transaksi L2 memiliki alur kerja tambahan dibandingkan dengan transaksi L1: 'Transaksi L2 disertakan dalam blok L2 dan menunggu diunggah ke L1.' Namun, karena data belum diunggah ke L1 pada tahap ini, masih ada kemungkinan variasi, sehingga jaminan yang dapat diperoleh pengguna tentang penyertaan transaksi pada tahap ini adalah komitmen lisan dari Sequencer, dikenal sebagai Pra-Konfirmasi atau Konfirmasi Cepat / Konfirmasi Lunak. Jika Sequencer bersifat jahat atau hanya mengalami bug, janji mereka dapat dilanggar, menyebabkan kurangnya konfirmasi untuk transaksi L2 pengguna. Saat ini, sebagian besar L2 menampilkan status transaksi dalam Explorernya yang mencakup status Pra-Konfirmasi, seperti Konfirmasi oleh Sequencer Arbitrum/Optimism atau Diterima di L2 StarkNet. Ketika melihat informasi tersebut, penting untuk memperhatikan efektivitas waktu dari jaminan penyertaan transaksi yang disediakan. Jika pengguna tidak ingin bergantung pada Pra-Konfirmasi Sequencer, mereka perlu menunggu lebih lama dan memverifikasi melalui informasi Explorernya L2 tentang data L2 yang diunggah ke L1. Pra-Konfirmasi dapat menyertakan mekanisme insentif ekonomi, seperti menghukum Sequencer melalui kontrak pintar ketika mereka melanggar janji mereka, memberikan perlindungan yang lebih jelas kepada pengguna. Tabel di bawah ini menunjukkan jaminan penyertaan transaksi dan skenario risiko yang sesuai yang disediakan oleh transaksi L1 dan L2 pada berbagai tahap proses transaksi.

Penafian：

1. Artikel ini dicetak ulang dari [aicoin]. Semua hak cipta milik penulis asli [Berita Foresight]. Jika ada keberatan terhadap cetak ulang ini, harap hubungi Gate Belajartim, dan mereka akan menanganinya dengan cepat.
2. Penolakan Tanggung Jawab: Pandangan dan pendapat yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.