Giải thích toàn bộ quá trình thực hiện giao dịch L2: hiệu suất bảo mật của từng giai đoạn là gì?

Tác giả: Nic@ imToken Labs

Khi nào tôi có thể chắc chắn rằng một giao dịch L2 sẽ được bao gồm trong một khối? Khi nào tôi có thể chắc chắn rằng doanh thu từ giao dịch L2 sẽ không bị loại bỏ vì Re-org?

Bài viết này sẽ giới thiệu toàn bộ quá trình thực hiện giao dịch L2 và phân tích hiệu suất bảo mật của từng giai đoạn của quá trình giao dịch.

Điều kiện tiên quyết:

• Toàn bộ quá trình giao dịch L1 (Lớp 1)
• Nguyên nhân và hậu quả của việc tổ chức lại
• Hiểu vai trò hiện tại của Ethereum trong kiến trúc PBS và cách thức hoạt động của nó
• Hiểu sự khác biệt giữa Optimistic Rollups và Validity (ZK) Rollups

Tìm hiểu về các giao dịch L1

QUY TRÌNH GIAO DỊCH

Sơ đồ luồng giao dịch L1

Tổ chức lại vẫn có thể sau Khối thu nhập giao dịch và cần phải đợi cho đến khi tổ chức lại không có khả năng xảy ra để tự tin rằng giao dịch đã được hoàn tất.

Xác suất và chi phí của Re-org sẽ thay đổi tùy thuộc vào Thuật toán đồng thuận của chuỗi và Vốn hóa thị trường của tài sản và việc tính toán chi phí Re-org sẽ không được giới thiệu ở đây.

Tìm hiểu về các giao dịch L2

QUY TRÌNH GIAO DỊCH

Sau khi người dùng L2 tạo và ký giao dịch, nó thường được gửi trực tiếp đến Sequencer chịu trách nhiệm sắp xếp giao dịch và Sequencer thu thập giao dịch của mình vào Khối L2. Sau đó, khi Sequencer ghi dữ liệu L2 Block trở lại L1 thông qua giao dịch L1, người dùng có thể thấy rằng giao dịch của họ được bao gồm trong Khối L2 mới nhất.

Tuy nhiên, cần lưu ý rằng vì dữ liệu Khối L2 được tải lên L1 thông qua các giao dịch L1, vẫn có thể gặp phải tình huống L1 Re-org xảy ra, dẫn đến Khối L2 cuối cùng không được ghi vào lịch sử của Blockchain, tức là tương đương với L2 Re-org, vì vậy người dùng vẫn phải đợi xác suất L1 Re-org đủ thấp để chắc chắn rằng giao dịch của mình sẽ được ghi vào lịch sử của Blockchain.

Sơ đồ luồng giao dịch L2

Trước tiên, người dùng đợi giao dịch được đưa vào Khối L2, sau đó đợi Khối L2 được tải lên L1 thông qua giao dịch L1 và cuối cùng đợi giao dịch L1 được hoàn tất.

Mặc dù so với các giao dịch L1, các giao dịch L2 có thêm một khoảng thời gian để chờ đợi các giao dịch L2 được Sequencer đưa vào các khối L2, nhưng trên thực tế, khi kích thước khối L2 đủ lớn và tốc độ sản xuất khối đủ nhanh, thời gian chờ đợi này sẽ không mất nhiều thời gian, vì thời gian chờ đợi sẽ chủ yếu dành cho các giao dịch L1 để ghi nhận doanh thu, vì vậy nhìn chung, kinh nghiệm của giao dịch L1 và giao dịch L2 là tương tự nhau.

Nhưng nếu người dùng sẵn sàng hy sinh, nó có thể được đổi lấy trải nghiệm tốt hơn không?

** Xác nhận trước / Xác nhận nhanh / Xác nhận mềm **

Người dùng sẽ thấy Khối L2 (chứa các giao dịch L2) được bao gồm trong Khối L1 và thậm chí đợi cho đến khi xác suất xảy ra Re-org đủ thấp để tin rằng giao dịch L2 của anh ta đã kiếm được.

Nhưng nếu người dùng sẵn sàng tin tưởng Sequencer thì sao? Có thể Sequencer được điều hành bởi nhóm phát triển L2, được điều hành bởi một tổ chức có uy tín và nếu Sequencer đảm bảo với người dùng rằng giao dịch của anh ta sẽ được thanh toán ngay lập tức, tại Khối thứ X, thì sự đảm bảo này là đủ cho người dùng sẵn sàng tin tưởng Sequencer. Cũng giống như nếu người dùng tin tưởng vào Ví mà anh ta đang sử dụng, anh ta sẽ không nghi ngờ đến Etherscan để kiểm tra kỹ sau khi Ví đã cảnh báo anh ta rằng giao dịch đã được thanh toán.

Đảm bảo thu nhập giao dịch do Sequencer này cung cấp được gọi là Xác nhận trước, Xác nhận nhanh hoặc Xác nhận mềm, có thể được hiểu là đảm bảo doanh thu giao dịch “sớm” hoặc “mềm”. Nó không cần phải đợi các giao dịch L2 được đưa vào khối L1, mà nó chỉ là một lời hứa bằng lời nói được đưa ra bởi Sequencer và Sequencer có thể quên lời hứa ban đầu do lỗi hoặc Sequencer độc hại sẽ trực tiếp vi phạm lời hứa, có thể lãng phí thời gian của người dùng hoặc là “Double Spend Attack”.

Tiếp theo, chúng ta sẽ xem xét một số cách khác nhau trong đó trạng thái doanh thu của các giao dịch L2 được trình bày.

Tình trạng doanh thu giao dịch của Arbitrum/Optimism

Hiện tại, người dùng gửi giao dịch trên Arbitrum hoặc Optimism gần như có thể ngay lập tức nhận được Biên lai giao dịch, đây sẽ là kết quả của việc thực hiện giao dịch. Điều này có nghĩa là Sequencer đã trình tự và mô phỏng việc thực hiện các giao dịch cục bộ và biên lai giao dịch này là xác nhận trước cho người dùng.

Để tìm hiểu thêm về Arbitrum, bạn có thể sao chép mô tả chi tiết hơn về vòng đời giao dịch vào liên kết sau vào tài liệu chính thức tham khảo của trình duyệt:

Để được giới thiệu chi tiết hơn về vòng đời giao dịch của Optimism, vui lòng sao chép liên kết sau vào tài liệu chính thức tham khảo của trình duyệt:

** Kiểm tra trạng thái doanh thu giao dịch trên Arbitrum**

Các giao dịch bạn thấy trên Arbitrum Explorer sẽ chứa các giao dịch Xác nhận trước, nghĩa là các giao dịch chưa được tải lên L1, như thể hiện trong hình sau, bạn có thể thấy rằng có chỉ báo Xác nhận bởi Trình sắp xếp bên cạnh Số khối 145353000:

Hình trên cho thấy các giao dịch chỉ được xác nhận bởi Sequencer nhưng chưa được tải lên L1

Nếu giao dịch đã được tải lên L1 như thể hiện trong hình bên dưới, trạng thái của nó đã thay đổi thành 69 Xác nhận khối L1, có nghĩa là nó đã được tải lên L1 và chứa Khối dữ liệu giao dịch và có 69 Khối đằng sau nó:

Khối L1 chứa dữ liệu giao dịch này đã có 69 Khối đằng sau nó và càng nhiều Khối theo sau nó, nó càng an toàn.

Hoặc giao dịch được hiển thị trong ảnh chụp màn hình bên dưới, Khối L1 chứa dữ liệu giao dịch này có 6174 Khối đằng sau nó, vốn đã rất an toàn.

Nhưng những gì có thể được thực hiện tốt hơn ở đây là kết hợp thông tin cuối cùng của L1.

Chỉ cần cho người dùng biết có bao nhiêu Xác nhận khối L1 là trợ giúp hạn chế cho người dùng, bởi vì người dùng phải hiểu và tính toán mức độ bảo mật được thể hiện bằng một số Xác nhận khối như vậy. Và vì Lớp 1 (tức là Ethereum) đã có cơ chế cuối cùng như Casper FFG, Explorer thực sự có thể hiển thị trực tiếp liệu Khối Lớp 1 hiện có được hoàn thiện trong Lớp 1 hay không. Hiện tại, Explorer của Optimism đã triển khai một tính năng như vậy.

** Kiểm tra trạng thái thu nhập giao dịch trên sự lạc quan **

Các giao dịch chúng ta thấy trên Optimism Explorer cũng sẽ bao gồm các giao dịch Xác nhận trước, nghĩa là các giao dịch chưa được tải lên L1, như thể hiện trong hình sau, chúng ta có thể thấy rằng có biểu tượng Xác nhận bởi Trình sắp xếp bên cạnh Số khối 111526300:

Các giao dịch chỉ được xác nhận bởi Sequencer nhưng chưa được tải lên L1

Tuy nhiên, Explorer dường như không có thông số kỹ thuật rõ ràng về ý nghĩa của Xác nhận bởi Sequencer, nói rằng “Xác nhận trình tự tương đương với một vài xác nhận khối trên L1.”, chỉ ra rằng Xác nhận bởi Trình sắp xếp đại diện cho một số Khối đã được tải lên L1 và đã được theo sau bởi một số:

Nhưng trên thực tế, giao dịch mới nhất cũng được hiển thị là Xác nhận bởi Sequencer, và thậm chí hàng chục ngày trước, trạng thái của giao dịch đã vượt qua giai đoạn thử thách vẫn được Sequencer xác nhận:

Hàng chục ngày trước, trạng thái giao dịch vẫn bị kẹt ở mức “Xác nhận bởi Sequencer”

Mẹo đọc: Tình huống trên cũng có thể là trình thám hiểm đánh dấu các trạng thái khác nhau ở những nơi khác nhau: Trình sắp xếp được xác nhận bởi Bộ sắp xếp sau Số khối cho người dùng biết rằng Khối đã được Trình sắp xếp xác nhận và người dùng phải xác nhận trạng thái sau khi tải lên L1 thông qua các thông tin khác, chẳng hạn như thông tin “Lô trạng thái L1” được đề cập bên dưới.

Ngoài ra, giao dịch đã được tải lên L1 như thể hiện trong ảnh chụp màn hình bên dưới có hai thông tin bổ sung: “L1 State Batch Index” và “L1 State Root Submission Tx Hash”. Hai mẩu thông tin này đại diện cho State Batch trong đó giao dịch L2 được bao gồm và giao dịch L1 thông qua đó State Batch được tải lên L1:

Nhấp vào Lô trạng thái “3480”, bạn có thể thấy rằng trạng thái của nó là Đã hoàn thiện, tương ứng với trạng thái Cuối cùng của L1 (nghĩa là Ethereum Mainnet), đây là trạng thái rất an toàn đã tích lũy thành công phiếu bầu của hai trình xác thực Kỷ nguyên.

△ Lô trạng thái 3480 đã được mua lại trong L1 Block 18457449 và Block 18457449 đã được hoàn thiện.

Nguồn:

Nếu lô đã được tải lên nhưng chưa được hoàn thiện trong L1, nó sẽ được hiển thị là Chưa hoàn thành:

Mặc dù State Batch 3494 đã được tải lên L1, khối L1 được bao gồm trong lô vẫn chưa được hoàn thiện.

So với Arbitrum Explorer, Optimism Explorer cung cấp nhiều thông tin hơn (State Batch) cho các giao dịch và nó sẽ trực tiếp xâu chuỗi thông tin L1 Finality đến L2 Explorer, để người dùng có thể trực tiếp biết liệu L1 Block đã được hoàn thiện hay chưa, thay vì đánh giá mức độ bảo mật tương ứng với số lượng Xác nhận khối.

Trạng thái thu nhập giao dịch của StarkNet

Hiện tại, sau khi người dùng gửi giao dịch trên StarkNet, mặc dù việc nhận giao dịch có thể được truy vấn nhanh chóng, nhưng trạng thái giao dịch hiển thị trong biên lai thường sẽ ở trạng thái RECEIVE, có nghĩa là Node đã nhận được giao dịch và không có vấn đề gì sau khi giao dịch được xác minh, và sẽ đợi giao dịch được Sequencer L2 Block nhận và thực hiện, trong khi giao dịch ở trạng thái RECEIVED sẽ không có bất kỳ kết quả thực hiện giao dịch nào. Người dùng có thể kiểm tra tiến độ giao dịch của mình thông qua trạng thái giao dịch hiển thị trên StarkNet Explorer.

Mẹo đọc: Nếu Sequencer xử lý đủ nhanh, có thể bỏ qua trạng thái RECEIVED và chuyển đến trạng thái mà giao dịch đã được xử lý. Để được giới thiệu chi tiết hơn về quy trình giao dịch của StarkNet, bạn có thể sao chép liên kết bên dưới để xem các tài liệu chính thức trong trình duyệt của mình.

Tài liệu chính thức: _and_concepts/Network_Architecture/transaction-life-cycle/

Các giao dịch được thấy trên Starkscan, StarkNet Explorer, cũng sẽ bao gồm các giao dịch Xác nhận trước, như thể hiện trong hình sau, bạn có thể thấy rằng Trạng thái hiện đang được Chấp nhận trên L2, có nghĩa là nó đã được xếp hạng vào Khối L2 bởi Trình sắp xếp:

“Được chấp nhận trên L2” có nghĩa là nó đã được Sequencer đặt trong khối L2, nhưng chưa được tải lên L1

Hai trạng thái đầu tiên của Được chấp nhận trên L2 là Đã nhận và Đang chờ xử lý, có nghĩa là “giao dịch đã được nhận và xác minh” và “giao dịch đang được xử lý bởi Trình tự” và giao dịch sẽ chuyển sang trạng thái Được chấp nhận trên L2 sau khi giao dịch được thực hiện:

Giao dịch được nhận và xác minh

Giao dịch đang được xử lý bởi Sequencer

Sau khi dữ liệu giao dịch được tải lên L1, trạng thái sẽ thay đổi thành Được chấp nhận trên L1, như thể hiện trong hình sau:

Dữ liệu giao dịch đã được tải lên L1

Mặc dù các giao dịch của StarkNet có trạng thái phong phú hơn cho phép người dùng biết tiến trình giao dịch, nhưng có thể mất bốn hoặc năm giờ để giao dịch được tải lên L1 (có thể vì mất nhiều thời gian để tạo Bằng chứng không có kiến thức), vì vậy người dùng trong thời gian này dựa vào xác nhận trước của Sequencer.

Ngoài ra, Explorer chỉ hiển thị Được chấp nhận trên L1 cho các giao dịch được tải lên L1 và không có thông tin Xác nhận cuối cùng hoặc Khối với L1, có nghĩa là người dùng phải kiểm tra xem có đủ Khối trong Khối L1 hay chúng đã được hoàn tất hay chưa.

Nhìn chung, do tắc nghẽn hiệu suất của chính StarkNet, người dùng cần dựa vào Xác nhận trước trong một thời gian dài và Explorer không hỗ trợ thông tin cuối cùng của L1, dẫn đến trải nghiệm kém về ghi nhận doanh thu giao dịch StarkNet, đó là điểm StarkNet cần được cải thiện trong tương lai.

Trạng thái doanh thu giao dịch của zkSync

Tương tự như StakrNet, zkSync cũng có trạng thái Chờ xử lý, có nghĩa là Node đã nhận được giao dịch và giao dịch đã được xác minh mà không gặp vấn đề gì, nó sẽ đợi giao dịch được Block và thực hiện bởi Sequencer L2, trong khi giao dịch ở trạng thái Chờ xử lý sẽ không có bất kỳ kết quả thực hiện giao dịch nào.

Người dùng có thể biết tiến trình giao dịch của mình thông qua trạng thái giao dịch được hiển thị trên zkSync Explorer.

Mẹo đọc: Nếu Sequencer xử lý đủ nhanh, bạn có thể bỏ qua trạng thái Đang chờ xử lý và chuyển đến trạng thái mà giao dịch đã được xử lý.

Để được giới thiệu chi tiết hơn về quy trình giao dịch của zkSync, bạn có thể sao chép liên kết sau để xem nó trong trình duyệt của mình:

Các giao dịch bạn thấy trên zkSync Explorer cũng sẽ bao gồm các giao dịch Xác nhận trước, chẳng hạn như giao dịch trong ảnh chụp màn hình bên dưới, bạn có thể thấy rằng Trạng thái hiện là zkSync Era Processed, có nghĩa là nó đã được xếp hạng vào Khối L2 bởi Trình sắp xếp:

Giao dịch này đã được Sequencer đặt trong khối L2 và hiện đang chờ được tải lên L1 (Ethereum Sending)

Sau khi Sequencer đã tạo ra một L2 Block, Block và các giao dịch trong đó sẽ trải qua ba giai đoạn theo trình tự: Committed, Proven, và uted, cho biết rằng “Block đã được tải lên L1”, “Tính hợp lệ của Block đã được chứng minh” và “Trạng thái L2 đã được cập nhật lên L1 sau khi giao dịch Block đã được thực hiện”. Khối và giao dịch ở các giai đoạn khác nhau được hiển thị dưới đây:

Lô 292700 đã được tải lên L1 và đang trong giai đoạn Cam kết. Nguồn:

Trạng thái hiện tại của giao dịch trong Batch 292700 đã thay đổi từ Ethereum Sending sang Ethereum Validating, cho thấy rằng nó đang chờ được xác minh bởi Zero-Knowledge Proof.

Di chuyển mũi tên qua biểu tượng Xác thực Ethereum cũng sẽ hiển thị các giai đoạn khác nhau và liên kết giao dịch từ giai đoạn trước (Gửi) cũng sẽ được đính kèm:

Giao dịch này bước vào giai đoạn “Xác thực” và liên kết đến giao dịch đã tải Hàng loạt lên L1 ở giai đoạn trước (Gửi) cũng có thể được xem tại đây.

Hiệu quả của Batch 292000 đã được chứng minh, vì vậy hãy bước vào giai đoạn Đã được chứng minh:

Sau khi Batch được chứng minh, nó sẽ chuyển sang trạng thái Proven với một liên kết đến giao dịch thực hiện hành động Chứng minh.

Giao dịch cũng sẽ chuyển từ “xác thực” sang “uting”, nghĩa là chờ được thực hiện.

Khi lô được chứng minh, nó sẽ chuyển sang giai đoạn chờ đợi (khoảng 21 giờ trong các tài liệu chính thức) trước khi giao dịch bên trong được thực hiện và trạng thái L2 được ghi lại trên L1 được cập nhật. Điều này chủ yếu là do một biện pháp bảo vệ đã được thêm vào trong giai đoạn alpha để đảm bảo rằng có đủ thời gian để phản ứng với bất kỳ lỗi nào phát sinh. Khi lô được thực hiện, nó bước vào giai đoạn uted cuối cùng:

Sau khi lô được thực thi, nó sẽ đi vào trạng thái uted cuối cùng với một liên kết giao dịch thực hiện hành động ute.

Trạng thái giao dịch trong Batch cũng đã được cập nhật thành “uted”

Trái ngược với StarkNet, nơi các giao dịch L2 đến L1 được hoàn thành trong một bước, quá trình chuyển L2 sang L1 của zkSync được chia thành ba giai đoạn chi tiết hơn: Cam kết → Đã được chứng minh → uted.

Mặc dù toàn bộ quá trình giao dịch được kéo dài đến khoảng một ngày hoặc lâu hơn như một biện pháp bảo vệ, trạng thái Cam kết cho phép người dùng nhanh chóng biết liệu giao dịch đã kiếm được hay chưa (và không còn chỉ là xác nhận trước khi giao dịch được cam kết) mà không cần phải dựa vào sự tin tưởng vào Sequencer trên cơ sở liên tục.

Ngoài ra, zkSync Explorer cung cấp hiển thị dữ liệu phong phú và đầy đủ cho các giai đoạn khác nhau, để bất kỳ ai cũng có thể nắm bắt trạng thái giao dịch mới nhất thông qua trình thám hiểm và thậm chí có thể xác minh cá nhân việc thực hiện giao dịch của từng giai đoạn chuyển đổi (chẳng hạn như từ Cam kết sang Chứng minh, từ Đã được chứng minh sang uted).

Tuy nhiên, cần lưu ý rằng như một biện pháp bảo vệ cho pha alpha, lịch sử có thể được sửa đổi bởi zkSync Sequencer tại thời điểm này.

Điều này cho thấy rằng mặc dù một giao dịch có thể nhanh chóng chuyển ra khỏi xác nhận trước và chuyển sang giai đoạn cam kết, Sequencer thực sự có thể xóa giao dịch của người dùng khỏi lịch sử trước khi giao dịch bước vào giai đoạn uted. Do đó, người tiêu dùng vẫn cần tin tưởng Sequencer trong tối đa một ngày.

L1 cũng có thể hỗ trợ Xác nhận trước

Nếu bạn có thể biết trước ai chịu trách nhiệm sản xuất các khối, thì L1 cũng có thể hỗ trợ xác nhận trước.

Lấy Ethereum làm ví dụ, người thực sự tạo ra các khối là Người xây dựng và Người xây dựng có thể cung cấp dịch vụ Xác nhận trước để cung cấp cho người dùng đảm bảo thu nhập giao dịch. Nhưng vì Builder không nhất thiết phải có quyền đối với một đầu ra nhất định và một Block nhất định, mà phải đấu thầu quyền đối với từng đầu ra Block, vì vậy hiệu quả của Pre-Confirmation này sẽ tương đối kém, và sức mạnh của Builder phải được xem xét, nếu Builder không đủ cạnh tranh, thì Builder khó có được quyền sản xuất Block, vì vậy Pre-Confirmation do Builder cung cấp Dịch vụ sẽ bị xâm phạm rất nhiều.

Nếu bạn muốn tránh những vấn đề trên, tốt hơn hết bạn nên nhờ Proposer cung cấp dịch vụ Pre-Confirmation, bởi vì “Proposer nào sẽ đề xuất Block đầu tiên” thường là một tình huống được tính toán trước, xác định.

Tuy nhiên, vì trong kiến trúc PBS hiện tại, Proposer chỉ đề xuất vai trò của Block, và vai trò thực sự tạo ra Block và xác định nội dung của Block là Builder, vì vậy Proposer không thể trực tiếp nhồi nhét một giao dịch vào Block hoặc yêu cầu Builder nhồi nhét một giao dịch. Khi kiến trúc PBS thay đổi trong tương lai, chẳng hạn như thêm Danh sách bao gồm hoặc cho phép Người đề xuất tham gia sản xuất khối, Người đề xuất sẽ có cơ hội cung cấp dịch vụ Xác nhận trước.

Mẹo đọc: Để biết thêm thông tin về PBS, vui lòng sao chép liên kết bên dưới để đọc trong trình duyệt của bạn: _4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss.

Cải thiện xác nhận trước

Xác nhận trước chỉ là một lời hứa bằng lời nói của Người xây dựng hoặc Người sắp xếp chuỗi L2 và bên kia không có nghĩa vụ thực hiện lời hứa và không có cơ chế phạt cho việc không thực hiện.

Có thể làm cho lời hứa này yên tâm hơn? Trên thực tế, có, bởi vì người chịu trách nhiệm tạo ra Khối và nội dung lời hứa của anh ta (ví dụ: “trong 1.350.000 Khối giao dịch doanh thu”) có thể được viết dưới dạng kiểm tra điều kiện. Do đó, chúng tôi có thể sử dụng hợp đồng thông minh để điều chỉnh Trình tạo hoặc Trình sắp xếp, yêu cầu họ cung cấp dịch vụ Xác nhận trước khi thế chấp tiền gửi trong Hợp đồng thông minh và ký nội dung khi đưa ra lời hứa về thu nhập giao dịch, khi người dùng thấy rằng Trình tạo hoặc Trình sắp xếp chưa thực hiện cam kết, nội dung đã hứa và chữ ký của bên kia có thể được gửi đến Hợp đồng thông minh và Hợp đồng thông minh có thể kiểm tra xem cam kết đã được thực hiện hay chưa (chẳng hạn như “trong lần đầu tiên Doanh thu khối 1.350.000 cho giao dịch này”).

Mặc dù kịch bản áp dụng của hợp đồng trên vẫn đang trong giai đoạn chứng minh khái niệm, video trình bày được hiển thị trong liên kết bên dưới cho biết một ví dụ về một trong các ứng dụng hợp đồng, vui lòng sao chép liên kết bên dưới để xem chi tiết trong trình duyệt của bạn:

Tóm tắt

• Sau khi các giao dịch L1 được đưa vào các khối L1, xác suất Re-org sẽ giảm dần và niềm tin của người dùng vào doanh thu giao dịch sẽ tăng dần.
• Thêm một quy trình giao dịch cho các giao dịch L2 so với các giao dịch L1 là giai đoạn mà các giao dịch L2 được bao gồm trong các khối L2 và chờ được tải lên L1.
• Tuy nhiên, trong quy trình giao dịch mà giao dịch L2 nhiều hơn giao dịch L1, do dữ liệu chưa được tải lên L1 ở giai đoạn này nên vẫn có khả năng xảy ra các biến, vì vậy việc đảm bảo thu nhập giao dịch mà người dùng có thể có được ở giai đoạn này là lời hứa bằng lời nói của Sequencer, được gọi là Xác nhận trước hoặc Xác nhận nhanh, Xác nhận mềm.
• Nếu Sequencer độc hại hoặc nếu có một lỗi đơn giản, thì lời hứa của Sequencer có thể bị vi phạm, dẫn đến không ghi nhận doanh thu cho các giao dịch L2 của người dùng.
• Hiện tại, hầu hết các trạng thái giao dịch L2 trong Explorer của họ bao gồm trạng thái Xác nhận trước, chẳng hạn như Xác nhận bởi Trình tự cho Trọng tài / Lạc quan hoặc Được chấp nhận trên L2 cho StarkNet. Khi bạn thấy thông tin đó, vui lòng chú ý đến thời gian hiệu lực của đảm bảo doanh thu giao dịch được cung cấp bởi thông tin này.
• Nếu bạn không muốn tin tưởng Xác nhận trước do Sequencer cung cấp, bạn sẽ cần đợi lâu hơn một chút và xác minh với thông tin do L2 Explorer cung cấp về dữ liệu L2 được tải lên L1.
• Xác nhận trước có thể được kết hợp với việc thiết kế các ưu đãi kinh tế, chẳng hạn như hình phạt thông qua Hợp đồng thông minh khi Sequencer vi phạm các cam kết, để người dùng có thể được bảo vệ rõ ràng hơn.

Bảng dưới đây minh họa đảm bảo doanh thu giao dịch và các kịch bản rủi ro tương ứng được cung cấp bởi các giao dịch L1 và giao dịch L2 ở các giai đoạn khác nhau của quá trình giao dịch: