Khi nào có thể chắc chắn rằng giao dịch L2 (Layer 2) sẽ được bao gồm trong một khối? Khi nào có thể chắc chắn rằng thu nhập từ giao dịch L2 sẽ không bị loại bỏ do một Re-org?

Bài viết này sẽ giới thiệu đến độc giả toàn bộ quy trình triển khai giao dịch L2 và phân tích hiệu suất bảo mật ở mỗi giai đoạn của quy trình giao dịch.

Kiến thức tiên quyết:

1. Toàn bộ quá trình giao dịch L1 (Lớp 1)

2. Nguyên nhân và tác động của Re-orgs

3. Hiểu vai trò và phương pháp hoạt động trong kiến trúc PBS hiện tại của Ethereum

4. Hiểu sự khác biệt giữa Optimistic Rollup và Validity (ZK) Rollup

Hiểu giao dịch L1

Quy trình giao dịch

Sau khi người dùng phát hành và ký một giao dịch, nó được gửi đến mạng ngang hàng và chờ đợi Mỏ vàng trong cơ chế đồng thuận PoW hoặc Người đề nghị trong cơ chế đồng thuận PoS bao gồm nó vào một khối. Khi một người dùng phát hiện ra rằng giao dịch của họ đã được bao gồm trong khối mới nhất, họ không thể chắc chắn 100% rằng giao dịch sẽ được ghi chép vĩnh viễn trong lịch sử blockchain đó. Điều này là do khả năng xảy ra sự kiện blockchain được biết đến là “Re-org.” Người dùng phải đợi cho đến khi xác suất xảy ra Re-org trong một khối cụ thể đủ thấp để tin tưởng rằng giao dịch của họ sẽ được ghi chép trong lịch sử blockchain.

Hình minh họa quy trình giao dịch L1

Ngay cả sau khi giao dịch được bao gồm trong một khối, vẫn có thể xảy ra Re-org. Người ta phải đợi cho đến khi có khả năng xảy ra Re-org thấp mới có thể tin chắc rằng giao dịch đã được hoàn thành.

Xác suất và chi phí của một Re-org thay đổi tùy thuộc vào thuật toán đồng thuận của một chuỗi và giá trị thị trường của tài sản của nó. Phương pháp tính toán chi phí của một Re-org sẽ không được thảo luận chi tiết ở đây.

Hiểu giao dịch L2

Quá 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 Trình sắp xếp chuỗi chịu trách nhiệm đặt hàng giao dịch. Sequencer sau đó bao gồm giao dịch này trong một khối L2. Sau đó, khi Sequencer ghi dữ liệu khối L2 trở lại L1 thông qua giao dịch L1, người dùng có thể thấy giao dịch của họ được bao gồm trong khối L2 mới nhất. Tuy nhiên, điều quan trọng cần lưu ý là vì dữ liệu khối L2 được tải lên L1 thông qua giao dịch L1, nên vẫn có khả năng gặp phải L1 Re-org. Kịch bản này có thể dẫn đến khối L2 không được đưa vào lịch sử blockchain, dẫn đến việc tổ chức lại L2 một cách hiệu quả. Do đó, người dùng phải đợi cho đến khi khả năng tổ chức lại L1 đủ thấp trước khi họ có thể tự tin rằng giao dịch của họ sẽ được ghi lại trong lịch sử blockchain.

Hình minh họa Quy trình Giao dịch L2

Người dùng đầu tiên chờ giao dịch của họ được bao gồm trong một khối L2, sau đó chờ khối L2 được tải lên L1 thông qua một giao dịch L1, và cuối cùng chờ giao dịch L1 được hoàn tất. Mặc dù việc chờ giao dịch L2 được bao gồm trong một khối L2 bởi một Sequencer thêm một bước so với giao dịch L1, thời gian chờ đợi này thường không quan trọng nếu khả năng của khối L2 là lớn và tốc độ tạo khối nhanh. Đa số thời gian chờ đợi thực sự được dành cho việc xác nhận giao dịch L1. Do đó, tổng体，trải nghiệm người dùng cho giao dịch L1 và L2 tương đối giống nhau. Nhưng liệu người dùng có thể thương lượng để có một 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

Lý tưởng nhất là người dùng nên chứng kiến các giao dịch L2 của họ (bao gồm trong các khối L2) được bao gồm trong các khối L1 và thậm chí đợi cho đến khi khả năng tổ chức lại đủ thấp, trước khi tin tưởng rằng các giao dịch L2 của họ đã được đưa vào. Nhưng nếu người dùng sẵn sàng tin tưởng Sequencer thì sao? Giả sử Sequencer được vận hành bởi nhóm phát triển L2 hoặc một tổ chức có uy tín. Nếu Sequencer đảm bảo với người dùng khi nhận được giao dịch của họ rằng họ sẽ được đưa vào ngay lập tức hoặc trong khối thứ X, sự đảm bảo này có thể đủ cho những người sẵn sàng tin tưởng Sequencer. Điều này giống như một người dùng tin tưởng ứng dụng ví của họ không liên tục kiểm tra Etherscan để xác nhận giao dịch sau khi ví đã thông báo cho họ về việc đưa vào.

Sự đảm bảo này được cung cấp bởi Trình sắp xếp chuỗi được gọi là Xác nhận trước, Xác nhận nhanh hoặc Xác nhận mềm. Đây có thể được hiểu là đảm bảo bao gồm giao dịch "sớm" hoặc "mềm". Chúng không yêu cầu chờ giao dịch L2 được đưa vào khối L1, nhưng chúng chỉ là cam kết bằng lời nói từ Trình sắp xếp. Sequencer có thể quên lời hứa của họ do lỗi hoặc Sequencer độc hại có thể phá vỡ lời hứa của họ, dẫn đến lãng phí thời gian cho người dùng hoặc, trong trường hợp xấu nhất, tiếp xúc với "cuộc tấn công chi tiêu gấp đôi".

Tiếp theo, chúng tôi sẽ giới thiệu một số cách khác nhau để trình bày trạng thái của việc bao gồm giao dịch L2.

Trạng thái Bao gồm Giao dịch trên Arbitrum/Optimism

Hiện tại, sau khi người dùng thực hiện giao dịch trên Arbitrum hoặc Optimism, họ gần như ngay lập tức nhận được biên nhận giao dịch, bao gồm kết quả của việc thực hiện giao dịch. Điều này cho thấy Rất rằng Sequencer đã sắp xếp và mô phỏng việc thực hiện giao dịch tại địa phương, và biên nhận giao dịch phục vụ như Một xác nhận trước cho người dùng.

Để biết thêm thông tin về vòng đời giao dịch chi tiết trên Arbitrum, bạn có thể tham khảo tài liệu chính thức tại: https://docs.arbitrum.io/tx-lifecycle

Để được giải thích chi tiết hơn về vòng đời giao dịch trên Optimism, hãy tham khảo tài liệu chính thức tại: https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Kiểm tra Trạng thái Bao gồm Giao dịch trên Arbitrum

Các giao dịch được hiển thị trên Arbitrum Explorer bao gồm các giao dịch với Trước Xác nhận, tức là các giao dịch chưa được tải lên L1. Như được thể hiện trong hình ảnh dưới đây, một giao dịch với Số Khối 145353000 được đánh dấu là “Đã Xác nhận bởi Sequencer,” cho biết rằng nó đã được xác nhận bởi Sequencer nhưng chưa được tải lên L1:

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

Ngược lại, hình ảnh tiếp theo cho thấy một giao dịch đã được tải lên L1, với trạng thái là “69 Xác nhận Khối L1.” Điều này có nghĩa là khối L1 chứa dữ liệu giao dịch này có 69 khối theo sau, cho thấy một mức độ bảo mật cao hơn:

[Hình ảnh một giao dịch trên L1 với 69 xác nhận khối]

Một ví dụ khác là giao dịch có xác nhận khối 6174 L1, như hình dưới đây, được coi là rất an toàn.

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

Kiểm tra trạng thái bao gồm giao dịch trên Optimism

Các giao dịch được hiển thị trên Trình duyệt Optimism cũng bao gồm những giao dịch với Tiền Xác nhận, tức là những giao dịch chưa được tải lên L1. Như được hiển thị trong hình ảnh dưới đây, một giao dịch với Số khối 111526300 được đánh dấu là “Đã xác nhận bởi Sequencer”:

[Hình ảnh chỉ thể hiện giao dịch được xác nhận bởi Sequencer nhưng chưa được tải lên L1]

Tuy nhiên, Trình duyệt không rõ ràng xác định ý nghĩa của “Đã xác nhận bởi Sequencer.” Nó nói, “Xác nhận bởi Sequencer tương đương với vài xác nhận khối trên L1,” ngụ ý rằng một giao dịch được đánh dấu là “Đã xác nhận bởi Sequencer” đã được tải lên L1 và có một số khối theo sau nó:

[Hình ảnh hiển thị giao dịch gần đây được đánh dấu là “Xác nhận bởi Sequencer”]

Các giao dịch từ vài ngày trước, ngay cả những giao dịch đã qua thời gian thách thức, vẫn hiển thị trạng thái “Xác nhận bởi Người xếp hàng” :

[Hình ảnh cho thấy giao dịch từ vài ngày trước vẫn được đánh dấu là “Xác nhận bởi Sequencer”]

Lưu ý: Trình duyệt có thể hiển thị các trạng thái khác nhau ở các nơi khác nhau: “Đã xác nhận bởi Sequencer” bên cạnh Số khối chỉ ra rằng khối đã được xác nhận bởi Sequencer. Để kiểm tra trạng thái sau khi được tải lên L1, người dùng cần tìm kiếm thông tin khác, chẳng hạn như “Lô Trạng thái L1” được đề cập dưới đây.

Như được hiển thị trong ảnh chụp màn hình tiếp theo, một giao dịch đã được tải lên L1 bao gồm thông tin bổ sung: “Chỉ số Gói Trạng thái L1” và “Băm Giao dịch Nộp Gói Trạng thái L1.” Các chi tiết này cho biết giao dịch L2 được bao gồm trong Gói Trạng thái nào và giao dịch L1 nào đã tải Gói Trạng thái này lên L1:

[Hình ảnh hiển thị giao dịch với thông tin L1 State Batch]

Nhấp vào State Batch “3480” sẽ hiển thị trạng thái của nó là Đã hoàn thành. Trạng thái Đã hoàn thành này tương ứng với mainnet của Ethereum và cho biết trạng thái rất an toàn, đã tích lũy thành công hai kỷ nguyên của phiếu bầu của người xác thực.

[Hình ảnh cho Batch Trạng thái 3480 đã hoàn thành trong Khối L1 18457449]

Nguồn:https://etherscan.io/block/18457449

Nếu một Batch đã được tải lên nhưng chưa hoàn tất trên L1, nó sẽ được hiển thị là Chưa hoàn tất:

[Hình ảnh hiển thị một Lô Nhà nước được tải lên L1 nhưng chưa hoàn tất]

So với Trình duyệt Arbitrum, Trình duyệt Optimism cung cấp nhiều thông tin hơn (State Batch) và tích hợp trực tiếp thông tin L1 Finality vào Trình duyệt L2, giúp người dùng biết liệu khối L1 đã được hoàn tất hay chưa mà không cần phải giải thích số lần Xác nhận Khối cho mục đích an ninh.

Tình trạng doanh thu giao dịch StarkNet

Hiện tại, khi người dùng gửi giao dịch trên StarkNet, họ có thể nhanh chóng truy cập biên lai giao dịch. Tuy nhiên, trạng thái thường được hiển thị trong biên lai là NHẬN, cho biết rằng nút đã nhận và xác thực giao dịch là không có lỗi. Sau đó, nó sẽ chờ đưa vào và thực thi trong một khối L2 bởi Sequencer. Các giao dịch ở trạng thái RECEIVED chưa có bất kỳ kết quả thực hiện nào. Người dùng có thể theo dõi tiến trình giao dịch của mình thông qua trạng thái hiển thị trên StarkNet Explorer.

Lưu ý: Nếu Sequencer xử lý các giao dịch đủ nhanh, có thể bỏ qua trạng thái NHẬN và chuyển trực tiếp sang trạng thái đã xử lý. Để biết thêm thông tin chi tiết về quy trình giao dịch của StarkNet, vui lòng tham khảo tài liệu chính thức tại https://docs.starknet.io/documentation/architecture_and_concepts/Network_Architecture/transaction-life-cycle/

Trên Starkscan, một Trình duyệt StarkNet, các giao dịch bao gồm Xác nhận trước được hiển thị. Ví dụ, một giao dịch được hiển thị là “Đã chấp nhận trên L2” cho biết nó đã được sắp xếp vào một khối L2:

“Đã chấp nhận trên L2” có nghĩa là giao dịch đã được xếp vào một khối L2 nhưng chưa được tải lên L1.

Hai trạng thái trước đó, Đã nhận và Đang chờ, đại diện cho “giao dịch đã nhận và được xác nhận” và “giao dịch đang được xử lý bởi Sequencer.” Sau khi xử lý, trạng thái sẽ thay đổi thành Được chấp nhận trên L2.

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 Đã chấp nhận trên L1, như được hiển thị trong hình dưới đây cho giao dịch này:

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

Mặc dù các giao dịch StarkNet có bộ trạng thái phong phú hơn, cho phép người dùng biết tiến trình giao dịch của họ, việc tải lên L1 có thể mất vài giờ, chủ yếu là do thời gian cần thiết để tạo bằng chứng không có kiến thức. Do đó, người dùng dựa vào Xác nhận trước của Sequencer trong khoảng thời gian này.

StarkNet Explorer chỉ hiển thị Được chấp nhận trên trạng thái L1 mà không kèm theo thông tin về L1 Finality hoặc Block Confirmation. Người dùng cần kiểm tra xem có đủ khối đã được thêm vào sau khi giao dịch của họ trên L1 hay chưa hoặc nó đã được Hoàn tất chưa.

Do toàn vị StarkNet's hiệu suất hạn chế, phụ thuộc lâu dài vào Xác nhận Trước và thiếu hỗ trợ cho thông tin L1 Finality trong Trình duyệt, trải nghiệm người dùng cho việc xác nhận bao gồm giao dịch trên StarkNet cần được cải thiện.

Tình trạng Bao gồm Giao dịch zkSync

Tương tự như StarkNet, zkSync cũng có trạng thái PENDING, chỉ ra rằng nút đã nhận và xác minh giao dịch mà không gặp vấn đề nào. Giao dịch sau đó sẽ chờ để được bao gồm và thực thi trong một khối L2 bởi Sequencer. Các giao dịch ở trạng thái PENDING vẫn chưa có kết quả thực thi nào.

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

Mẹo Đọc: Nếu Bộ xử lý chuỗi xử lý giao dịch đủ nhanh, có thể bỏ qua trạng thái ĐANG CHỜ và chuyển trực tiếp sang trạng thái giao dịch đã được xử lý.

Để biết thêm thông tin chi tiết về quá trình giao dịch của zkSync, vui lòng theo dõi liên kết này: https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

Các giao dịch được xem trên Trình duyệt zkSync cũng bao gồm các giao dịch Trước Xác nhận, như giao dịch trong ảnh chụp màn hình dưới đây. Tình trạng hiện tại là “Đã xử lý qua giai đoạn zkSync,” cho biết rằng nó đã được sắp xếp vào một khối L2 bởi Sequencer:

Giao dịch đã được sắp xếp vào một block L2 bởi Sequencer và hiện đang chờ được tải lên L1 (Gửi Ethereum).

Sau khi Sequencer hoàn thành một khối L2, khối và giao dịch của nó trải qua ba giai đoạn: Đã cam kết, Đã chứng minh và Đã thực hiện. Cụ thể, chúng chỉ ra rằng “khối được tải lên L1,” “sự hợp lệ của khối được chứng minh,” và “trạng thái L2 sau khi thực hiện các giao dịch trong khối được cập nhật lên L1.” Dưới đây là ví dụ về các khối và giao dịch ở các giai đoạn khác nhau:

Batch 292700 đã được tải lên L1 và đã nhập vào giai đoạn Cam kết. Nguồn: https://explorer.zksync.io/batch/292700

Trạng thái giao dịch trong Batch 292700 thay đổi từ Ethereum Sending sang Ethereum Validating, cho biết chúng đang chờ xác minh chứng minh không có kiến thức của tính hợp lệ của họ.

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

Giao dịch này đã đi vào giai đoạn “Xác thực”. Liên kết giao dịch để tải lên Lô vào L1 ở giai đoạn trước (Gửi) cũng có thể được nhìn thấy trực tiếp tại đây.

Lô 292000 đã được chứng minh tính hợp lệ, vì vậy nó nhập vào giai đoạn Đã Chứng minh:

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

Các giao dịch sau đó chuyển từ trạng thái “Đang xác thực” sang “Đang thực thi,” điều này có nghĩa là chúng đang chờ được thực thi.

Sau khi một Batch được chứng minh, có một thời gian chờ đợi (khoảng 21 giờ theo tài liệu chính thức) trước khi thực hiện các giao dịch bên trong và cập nhật trạng thái L2 được ghi lại trên L1. Đây là một biện pháp bảo vệ trong giai đoạn Alpha để đảm bảo thời gian phản ứng đầy đủ trong trường hợp có lỗi. Khi Batch được thực thi, nó bước vào giai đoạn Thực thi cuối cùng:

Sau khi thực thi, Batch nhập vào trạng thái Thực thi cuối cùng, với một liên kết đến giao dịch thực thi hành động Thực thi.

Trạng thái giao dịch trong lô cũng được cập nhật thành “Thực hiện.”

So với StarkNet, nơi giao dịch di chuyển từ L2 đến L1 trong một bước, zkSync phân tích quá trình từ L2 đến L1 thành ba giai đoạn chi tiết hơn: Đã cam kết → Đã chứng minh → Đã thực hiện. Mặc dù như một biện pháp bảo vệ, toàn bộ quá trình giao dịch mất khoảng một ngày, trạng thái Đã cam kết cho phép người dùng nhanh chóng biết liệu giao dịch của họ đã được bao gồm (sau khi Đã cam kết, không chỉ là Trước Xác nhận) mà không chỉ dựa vào niềm tin vào Sequencer. Ngoài ra, zkSync Explorer cung cấp dữ liệu toàn diện cho mỗi giai đoạn, cho phép bất kỳ ai theo dõi tình trạng giao dịch mới nhất và thậm chí xác minh các chuyển đổi giữa các giai đoạn (ví dụ, từ Đã cam kết sang Đã chứng minh, từ Đã chứng minh sang Đã thực hiện).

Tuy nhiên, quan trọng phải lưu ý rằng như một biện pháp bảo vệ trong giai đoạn Alpha, zkSync Sequencer hiện tại có thể sửa đổi các bản ghi lịch sử. Điều này có nghĩa là ngay cả khi giao dịch có thể nhanh chóng chuyển từ giai đoạn Trước Xác nhận sang giai đoạn Đã Xác nhận, Sequencer vẫn có thể xóa các giao dịch của người dùng khỏi bản ghi lịch sử cho đến khi chúng đạt đến giai đoạn Đã Thực hiện. Do đó, người dùng vẫn cần phải tin tưởng Sequencer trong vòng một ngày.

L1 Cũng Có Thể Hỗ Trợ Xác Nhận Trước

Nếu có thể biết trước người chịu trách nhiệm sản xuất khối là ai, thì L1 cũng có thể hỗ trợ Xác nhận Trước. Lấy Ethereum làm ví dụ, người sản xuất khối thực tế là Người Xây dựng, người có thể cung cấp dịch vụ Xác nhận Trước, mang lại cho người dùng sự đảm bảo về việc bao gồm giao dịch. Tuy nhiên, do Người Xây dựng không có quyền được đảm bảo để sản xuất một khối cụ thể mà phải đấu giá quyền để sản xuất mỗi khối, hiệu quả của dịch vụ Xác nhận Trước này tương đối yếu. Ngoài ra, cần xem xét sức mạnh của Người Xây dựng; nếu một Người Xây dựng thiếu sức mạnh cạnh tranh, sẽ khó cho họ giành quyền sản xuất khối, làm giảm giá trị của dịch vụ Xác nhận Trước của họ.

Một giải pháp tốt hơn để tránh những vấn đề này sẽ là để Bên Đề Nghị cung cấp dịch vụ Xác Nhận Trước, vì thường đã quyết định trước và chắc chắn rằng Bên Đề Nghị nào sẽ đề xuất khối nào. Tuy nhiên, trong kiến trúc PBS (Phân Tách Bên Đề Nghị-Xây Dựng) hiện tại, Bên Đề Nghị chỉ chịu trách nhiệm đề xuất khối, trong khi Xây Dựng quyết định nội dung của khối. Do đó, Bên Đề Nghị không thể trực tiếp chèn giao dịch vào một khối hoặc yêu cầu Xây Dựng làm điều đó. Tình hình này có thể thay đổi với các sửa đổi trong tương lai cho kiến trúc PBS, như việc thêm Danh Sách Bao Gồm hoặc cho phép Bên Đề Nghị tham gia vào sản xuất khối, giúp Bên Đề Nghị 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 vào trình duyệt của bạn để đọc: https://mirror.xyz/0x347c9872A2a1dE370D798f9FE96341A9A0E05af8/oG_4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss.

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

Xác nhận trước chỉ là lời hứa miệng từ Một Người Xây Dựng hoặc L2 Sequencer, không có nghĩa vụ phải thực hiện và không có cơ chế trừng phạt cho việc không tuân thủ. Lời hứa này có thể trở nên đáng tin cậy hơn không? Có, bởi vì nội dung của cam kết (ví dụ, “bao gồm giao dịch này trong khối 1350000”) được thực hiện bởi người chịu trách nhiệm sản xuất khối có thể được viết dưới dạng kiểm tra có điều kiện. Do đó, chúng ta có thể sử dụng hợp đồng thông minh để điều chỉnh Người Xây Dựng hoặc Sequencer, yêu cầu họ gửi tiền đặt cọc vào hợp đồng thông minh khi cung cấp dịch vụ Xác nhận Trước và ký nội dung cam kết. Nếu người dùng phát hiện rằng Người Xây Dựng hoặc Sequencer không giữ lời hứa của họ, họ có thể gửi cam kết và chữ ký đến hợp đồng thông minh để xác minh.

Mặc dù việc áp dụng các hợp đồng như vậy vẫn ở giai đoạn chứng minh khái niệm, đường link dưới đây đến một video trình bày một ví dụ về ứng dụng hợp đồng:

https://www.youtube.com/watch?v=Uw5HxSYXwYo

Tóm tắt

Sau khi giao dịch L1 được bao gồm trong một khối L1, khả năng xảy ra Re-org dần giảm, và sự tự tin của người dùng vào việc giao dịch của họ được bao gồm cũng tăng lên.

Các giao dịch L2 có quy trình bổ sung so với các giao dịch L1: giai đoạn “giao dịch L2 được bao gồm trong một khối L2 và chờ đợi để được tải lên L1.” Trong giai đoạn này, vì dữ liệu chưa được tải lên L1, vẫn có khả năng thay đổi, và do đó, sự đảm bảo duy nhất mà người dùng có về việc bao gồm giao dịch của họ là cam kết bằng lời từ Sequencer, được biết đến như là Xác nhận Trước, Xác nhận Nhanh hoặc Xác nhận Mềm.

Nếu Sequencer là người có ý đồ xấu hoặc gặp sự cố, cam kết của họ có thể bị vi phạm, tiềm ẩn nguy cơ thiếu xác nhận cho giao dịch L2 của người dùng.

Hiện tại, hầu hết các L2 hiển thị trạng thái giao dịch trong Explorers của họ, bao gồm trạng thái Xác nhận trước, như “Đã xác nhận bởi Sequencer” của Arbitrum/Optimism hoặc “Đã chấp nhận trên L2” của StarkNet. Người dùng nên nhận thức về tính hợp lệ thời gian của sự đảm bảo bao gồm việc bao gồm giao dịch được cung cấp bởi các trạng thái này.

Nếu người dùng không muốn tin tưởng vào Xác nhận Trước của Sequencer, họ sẽ cần phải đợi lâu hơn và xác minh thông qua thông tin được cung cấp bởi Trình duyệt L2 về dữ liệu L2 đang được tải lên L1.

Trước Xác nhận có thể bao gồm cơ chế khuyến khích kinh tế, chẳng hạn như các hình phạt thông qua hợp đồng thông minh đối với Sequencers vi phạm lời hứa của họ, mang lại sự bảo vệ rõ ràng hơn cho người dùng.

Bảng dưới đây cho thấy các đảm bảo bao gồm giao dịch và các kịch bản rủi ro tương ứng cho các giai đoạn khác nhau của giao dịch L1 và L2: [Xin lưu ý rằng bảng không được cung cấp trong bản dịch.]

Disclaimer：

1. Bài viết này được sao chép từ [GateimToken Labs]. Tất cả bản quyền thuộc về tác giả gốc [Nic]. If there are objections to this reprint, please contact the Gate Learnđội ngũ, và họ sẽ xử lý nó ngay lập tức.
2. Bản Khai Báo Miễn Trừ Trách Nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không hình thành bất kỳ lời khuyên đầu tư nào.
3. Bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được nêu, việc sao chép, phân phối hoặc đạo văn bản dịch là không được phép.