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

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

Kiến thức sơ bộ:

• Toàn bộ quy trình giao dịch L1 (Layer 1)
• Lý do và tác động của các trường hợp Re-org
• Hiểu về vai trò và phương pháp vận hành trong kiến trúc PBS Ethereum hiện tại
• Sự khác biệt giữa Optimistic Rollup và Validity (ZK) Rollup

Hiểu giao dịch L1

Quá 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 p2p, đợi để được bao gồm trong một khối bởi một Miner theo cơ chế đồng thuận Proof of Work (PoW) hoặc một Proposer theo cơ chế đồng thuận Proof of Stake (PoS). Khi người dùng nhận thấy giao dịch của họ đã được bao gồm trong khối mới nhất, chưa chắc chắn rằng giao dịch sẽ được ghi chép vĩnh viễn trong lịch sử blockchain. Sự không chắc chắn này là do khả năng của một “Re-org” (tổ chức lại) xảy ra trên blockchain. Người dùng phải đợi cho đến khi khả năng xảy ra Re-org đủ thấp để tin tưởng rằng giao dịch của họ sẽ được ghi chép vĩnh viễn trong lịch sử blockchain.

Quy trình Giao dịch L1 được minh họa

Ngay cả sau khi một giao dịch được bao gồm trong một khối, vẫn có thể xảy ra Re-org, có nghĩa là xác nhận chỉ có thể được đảm bảo khi xác suất của Re-org trở nên không thể xảy ra.

Khả năng 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ỗi blockchain và giá trị thị trường của tài sản của nó. Tài liệu này sẽ không đi sâu vào phương pháp tính toán chi phí Re-org.

Hiểu giao dịch L2

Quy trình giao dịch

Người dùng L2 tạo và ký giao dịch, thường gửi trực tiếp đến một Sequencer, sau đó Sequencer bao gồm những giao dịch này trong một khối L2. Sau đó, khi Sequencer đăng dữ liệu khối L2 trở lại L1 thông qua một 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 đăng lên L1 thông qua một giao dịch L1, vẫn có khả năng xảy ra một L1 Re-org, có thể dẫn đến việc khối L2 không được ghi lại vĩnh viễn trong lịch sử blockchain. Tình huống này tương tự như một L2 Re-org, do đó người dùng phải đợi cho đến khi xác suất xảy ra L1 Re-org đủ thấp để tin tưởng rằng giao dịch của họ sẽ được ghi lại vĩnh viễn trong lịch sử blockchain.

Quy trình Giao dịch L2 Được minh họa

Người dùng phải chờ giao dịch của họ được bao gồm trong một khối L2, sau đó khối L2 được đăng lên L1 thông qua một giao dịch L1, và cuối cùng là giao dịch L1 được hoàn tất.

Mặc dù giao dịch L2 liên quan đến thời gian chờ đợi bổ sung để được bao gồm trong một khối L2 bởi Sequencer so với các giao dịch L1, thời gian chờ đợi này thường ngắn nếu dung lượng khối L2 lớn và quá trình tạo khối nhanh, vì thời gian chờ đợi chính là để giao dịch L1 được xác nhận. Do đó, trải nghiệm tổng thể của người dùng đối với giao dịch L1 và L2 tương tự.

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

Người dùng nên tự xác minh rằng giao dịch L2 của họ, cùng với khối L2, đã được bao gồm trong một khối L1, và thậm chí chờ đến khi xác suất của một Re-org đủ thấp để tin tưởng rằng giao dịch L2 của họ đã được bao gồm.

Nhưng nếu người dùng sẵn lòng tin tưởng vào Sequencer? Sequencer có thể được vận hành bởi nhóm phát triển L2 hoặc một tổ chức đáng tin cậy. Nếu Sequencer đảm bảo người dùng ngay sau khi nhận giao dịch của họ rằng họ sẽ được bao gồm trong một khối cụ thể, bảo đảm này có thể đủ cho những người sẵn lòng tin tưởng vào Sequencer. Điều này tương tự như người dùng tin tưởng ứng dụng ví của họ và không kiểm tra Etherscan một cách ám ảnh để xác nhận sau khi được thông báo về việc bao gồm giao dịch.

Các cam kết được cung cấp bởi Sequencer được gọi là Xác nhận Trước, Xác nhận Nhanh, hoặc Xác nhận Mềm. Những điều này được coi là các cam kết "sơ bộ" hoặc "mềm" về việc bao gồm giao dịch, không yêu cầu giao dịch L2 được bao gồm trong một khối L1. Tuy nhiên, những điều này chỉ là cam kết bằng lời từ Sequencer, có thể bị quên do lỗi hoặc cố tình bị phá vỡ bởi một Sequencer độc hại, trong trường hợp xấu nhất dẫn đến một cuộc tấn công chi tiêu kép.

Sau đó, chúng tôi sẽ giới thiệu các cách mà trạng thái bao gồm giao dịch L2 được hiển thị.

Trạng thái bao gồm giao dịch Arbitrum/Optimism

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

Tìm hiểu thêm

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

Để biết thông tin chi tiết hơn về vòng đời giao dịch của Optimism, vui lòng tham khảo tài liệu chính thức: https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Tình hình thu nhập giao dịch cho Arbitrum/Optimism

Hiện tại, sau khi người dùng gửi giao dịch trên Arbitrum hoặc Optimism, họ gần như ngay lập tức nhận được một biên nhận giao dịch (Transaction Receipt), trong đó sẽ chứa kết quả của việc thực thi giao dịch. Điều này có nghĩa là Sequencer đã sắp xếp giao dịch tại địa phương và mô phỏng nó một lần. Biên nhận giao dịch này là Bản xác nhận trước được cung cấp cho người dùng.

tìm hiểu thêm

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

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

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

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

Kiểm tra trạng thái thu nhập giao dịch trên Arbitrum

Các giao dịch được hiển thị trên Arbitrum Explorer sẽ bao gồm các giao dịch Trước Xác nhận, tức là các giao dịch chưa được tải lên L1. Đối với giao dịch này như được hiển thị trong hình dưới đây, bạn có thể thấy dấu Xác nhận bởi Sequencer bên cạnh Số khối 145353000:

Bức ảnh trên chỉ thể hiện 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 đó là giao dịch đã được tải lên L1 như được hiển thị trong hình dưới đây, trạng thái của nó đã được thay đổi thành 69 Xác nhận Khối L1, có nghĩa là đã được tải lên L1 và Khối Layer1 chứa dữ liệu giao dịch đã có 69 khối theo sau.

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

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

Nhưng thực tế, điều có thể làm tốt hơn ở đây là trình bày nó kết hợp với thông tin Finality của L1.

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

Kiểm tra trạng thái biên nhận giao dịch trên Optimism

Các giao dịch được xem trên Trình duyệt Optimism có thể bao gồm những giao dịch được đánh dấu là Pre-Confirmation, cho biết chúng vẫn chưa được đăng lên Layer 1 (L1). Như được minh họa dưới đây, giao dịch với Số Block 111526300 được gắn nhãn là “Đã xác nhận bởi Sequencer”.

Giao dịch chỉ được xác nhận bởi người Sequencer nhưng chưa được đăng lên L1

Hiện tại, Trình duyệt dường như thiếu một định nghĩa rõ ràng cho thuật ngữ “Đã xác nhận bởi Sequencer,” gợi ý rằng “các xác nhận từ Sequencer tương đương với một số xác nhận khối trên L1.” Điều này ngụ ý rằng việc “Được xác nhận bởi Sequencer” có nghĩa là giao dịch đã được đăng tải lên L1 và có một số khối theo sau:

Tuy nhiên, các giao dịch mới xuất hiện cũng được hiển thị dưới dạng “Đã xác nhận bởi Sequencer,” và thậm chí các giao dịch từ nhiều ngày trước, đã vượt qua giai đoạn thách thức, vẫn ở trạng thái “Đã xác nhận bởi Sequencer”:

Các giao dịch từ vài ngày trước vẫn ở trạng thái “Đã xác nhận bởi Sequencer”

Lưu ý đọc: Tình huống này cũng có thể do Trình duyệt hiển thị các chỉ báo trạng thái khác nhau ở nhiều nơi: “Đã xác nhận bởi Sequencer” bên cạnh Số Block thông báo cho người dùng rằng block đã được xác nhận bởi Sequencer. Để xác minh trạng thái sau L1, người dùng phải tham khảo thông tin khác, như chi tiết “Lô trạng thái L1” được thảo luận dưới đây.

Hơn nữa, như được hiển thị trong ảnh chụp màn hình dưới đây, một giao dịch đã được đăng lên L1 bao gồm hai thông tin bổ sung: “Chỉ số Batch Trạng thái L1” và “Băm Giao dịch Nộp Trạng thái L1.” Những chi tiết này đại diện cho Batch Trạng thái nào mà giao dịch L2 được bao gồm và thông qua giao dịch L1 nào mà Batch Trạng thái này đã được đăng lên L1:

Nhấp vào “State Batch 3480,” trạng thái của nó được hiển thị là Đã hoàn tất, tương ứng với trạng thái Đã hoàn tất trên L1 (tức là Ethereum mainnet), đây là một trạng thái cực kỳ an toàn đạt được sau khi tích lũy phiếu bầu từ các validator qua hai thời kỳ.

△ State Batch 3480 được bao gồm trong Khối L1 18457449, và Khối 18457449 đã được hoàn tất.

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

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

Chuyến hàng trạng thái 3494, mặc dù đã được đăng vào L1, nhưng lại được bao gồm trong một khối L1 mà chưa được hoàn thiện:

So với Trình duyệt Arbitrum, Trình duyệt Optimism cung cấp thông tin chi tiết hơn (Tổng trạng thái) và liên kết trực tiếp thông tin về Sự hoàn thành L1 với Trình duyệt L2, cho phép người dùng biết liệu một khối L1 đã được Hoàn thành hay chưa, thay vì phải tự đưa ra quyết định dựa trên số lượng Xác nhận Khối để đảm bảo an toàn.

Tình hình 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 vấn biên nhận giao dịch. Tuy nhiên, biên nhận thường hiển thị trạng thái giao dịch là ĐƯỢC NHẬN. Trạng thái này cho biết rằng nút đã nhận giao dịch và, sau khi xác minh, không phát hiện vấn đề nào. Giao dịch đang chờ được bao gồm trong một khối L2 bởi Sequencer và thực thi. Các giao dịch ở trạng thái ĐƯỢC NHẬN vẫn chưa có kết quả từ việc thực thi. Người dùng có thể kiểm tra tiến độ của giao dịch của mình bằng cách xem trạng thái giao dịch được hiển thị trên Trình duyệt StarkNet.

Mẹo Đọc: Nếu Sequencer xử lý các giao dịch đủ nhanh, nó 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 chi tiết về quy trình giao dịch trên StarkNet, bạn có thể sao chép liên kết dưới đây vào trình duyệt của mình để tham khảo tài liệu chính thức.

Tài Liệu Chính Thức:Vòng Đời Giao Dịch của StarkNet

Các giao dịch được xem trên Starkscan, một công cụ khám phá StarkNet, cũng bao gồm các giao dịch Trước Xác nhận. Như được thể hiện trong giao dịch sau, Trạng thái hiện tại là "Đã chấp nhận trên L2," cho biết rằng nó đã được xếp hàng bởi Sequencer vào một khối L2:

"Được chấp nhận trên L2" có nghĩa là nó đã được xếp hàng bởi Sequencer vào một khối L2, nhưng chưa được tải lên L1.

Hai trạng thái trước khi 'Được chấp nhận trên L2' là Nhận và Đang chờ, đại diện cho 'giao dịch đã được nhận và xác minh' và 'giao dịch đang được xử lý bởi Sequencer,' tương ứng. Sau khi quá trình xử lý giao dịch hoàn tất, nó sẽ chuyển sang trạng thái 'Đượ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 Bộ sắp xếp.

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ư đã hiển thị trong giao dịch sau:

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

Mặc dù giao dịch StarkNet có một loạt trạng thái phong phú để thông báo cho người dùng về tiến trình xử lý, việc tải lên giao dịch lên L1 vẫn có thể đòi hỏi một thời gian chờ đợi vài giờ (có thể vì việc tạo ra chứng minh không mẫu mất nhiều thời gian hơn). Trong thời gian này, người dùng phụ thuộc vào Xác nhận trước của Sequencer.

Ngoài ra, Trình duyệt chỉ hiển thị “Đã chấp nhận trên L1” cho các giao dịch tải lên L1, mà không có thông tin kèm theo về Độ chắc chắn của L1 hoặc Xác nhận Khối. Điều này có nghĩa là người dùng phải tự kiểm tra xem khối L1 có đủ khối tiếp theo đủ hay đã được Hoàn tất.

Nhìn chung, do hạn chế về hiệu suất của StarkNet, người dùng cần phụ thuộc vào Xác nhận Trước trong một thời gian kéo dài, và Trình duyệt không hỗ trợ thông tin về L1 Finality, dẫn đến trải nghiệm người dùng ít hài lòng hơn về xác nhận doanh thu giao dịch. Đây là một lĩnh vực mà StarkNet cần cải thiện trong tương lai.

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

Tương tự như StakrNet, zkSync cũng có trạng thái ĐANG CHỜ, có nghĩa là nút đã nhận giao dịch và sau khi giao dịch được xác minh không có vấn đề. Nó sẽ chờ được bao gồm trong khối L2 bởi Sequencer và thực thi. Tuy nhiên, không có giao dịch nào được thực thi trong trạng thái ĐANG CHỜ. kết quả của.

Người dùng có thể biết tiến độ xử lý của giao dịch của họ thông qua trạng thái giao dịch hiển thị trên zkSync Explorer.

Mẹo đọc: Nếu Trình tự được xử lý đủ nhanh, có thể có khả năng trực tiếp bỏ qua trạng thái PENDING và nhập vào trạng thái mà giao dịch đã được xử lý.

Để biết thêm thông tin chi tiết về quy trình giao dịch của zkSync, bạn có thể sao chép liên kết bên dưới và xem trên trình duyệt của bạn: https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

Các giao dịch được thấy trên zkSync Explorer cũng sẽ 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. Bạn có thể thấy rằng Trạng thái hiện tại là zkSync Era Processed, cho biết rằng nó đã được xếp hàng vào khối L2 bởi Sequencer:

Giao dịch này đã được xếp hàng vào khối 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 khối L2, khối và giao dịch trong đó sẽ trải qua ba giai đoạn Lên kế hoạch, Đã chứng minh và Đã thực hiện, tương ứng với “khối đã được tải lên L1” và “sự hợp lệ của khối đã được chứng minh”. Và “trạng thái L2 được cập nhật lên L1 sau khi giao dịch trong khối được thực hiện.” Phần sau sẽ cho thấy ba 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

Tình trạng hiện tại của các giao dịch trong Batch 292700 đã thay đổi từ Ethereum Sending thành Ethereum Validating, cho thấy rằng chúng đang chờ được xác minh bằng bằng chứng không mô tả để xác minh tính hợp lệ của chúng.

Di chuyển mũi tên qua biểu tượng Xác minh Ethereum 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 đã đang ở giai đoạn “Đang xác thực”. Liên kết giao dịch để tải lên Lô lên L1 ở giai đoạn trước (Gửi) cũng có thể được nhìn thấy trực tiếp ở đây.

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

Sau khi Batch được chứng minh, nó đi vào trạng thái Đã chứng minh, và một liên kết giao dịch để thực hiện hành động Chứng minh được đính kèm.

Các giao dịch bên trong cũng sẽ chuyển sang giai đoạn “Thực hiện” từ giai đoạn “Xác nhận”, đang chờ để thực hiện.

Khi Batch được chứng minh, nó sẽ sau đó vào một giai đoạn chờ đợi (tài liệu chính thức nói rằng khoảng 21 giờ) 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. Điều này chủ yếu do biện pháp bảo vệ vẫn đang ở giai đoạn Alpha để đảm bảo rằng có đủ thời gian để phản ứng khi xảy ra bất kỳ lỗi nào. Khi Batch được thực hiện, nó sẽ vào giai đoạn Thực hiện cuối cùng:

Sau khi Batch được thực thi, nó sẽ vào trạng thái Executed cuối cùng, và một liên kết giao dịch để thực hiện hành động Execute được đính kèm.

Trạng thái giao dịch trong lô cũng được cập nhật thành "Đã thực thi". Không giống như các giao dịch StarkNet, được hoàn thành từ Lớp 2 (L2) đến Lớp 1 (L1) trong một bước, zkSync chia nhỏ quy trình giao dịch từ L2 đến L1 thành ba giai đoạn chi tiết hơn: Cam kết → Chứng minh → Thực thi. Mặc dù điều này kéo dài toàn bộ quá trình giao dịch đến khoảng một ngày 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 của họ đã được bao gồm hay chưa (khi giao dịch bước vào giai đoạn Cam kết, nó không còn chỉ đơn thuần là Xác nhận trước) mà không cần liên tục dựa vào sự tin tưởng vào Trình sắp xếp. Hơn nữa, zkSync Explorer cung cấp hiển thị dữ liệu toàn diện và đầy đủ cho các giai đoạn khác nhau, cho phép mọi người nắm bắt trạng thái giao dịch mới nhất và thậm chí xác minh cá nhân việc thực hiện giao dịch ở từng giai đoạn chuyển đổi (ví dụ: từ Cam kết sang Chứng minh, từ Đã được chứng minh đến Thực thi). Tuy nhiên, điều quan trọng cần lưu ý là, như một biện pháp bảo vệ trong giai đoạn Alpha, zkSync Sequencer có thể sửa đổi các bản ghi lịch sử. Điều này chỉ ra rằng mặc dù các giao dịch có thể nhanh chóng vượt ra ngoài Xác nhận trước để bước vào giai đoạn Cam kết, Trình sắp xếp chuỗi vẫn có thể xóa các giao dịch của người dùng khỏi các bản ghi lịch sử cho đến khi chúng đạt đến giai đoạn Thực thi. Do đó, người dùng vẫn cần tin tưởng Sequencer trong tối đa một ngày.

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

Nếu nó được 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ụ, nhà sản xuất khối thực tế là Builder, 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 bao gồm giao dịch. Tuy nhiên, vì Người xây dựng không nhất thiết phải có quyền tạo ra một khối nhất định mà phải đấu thầu quyền sản xuất từng khối, hiệu quả của Xác nhận trước có thể yếu hơn. Ngoài ra, phải xem xét khả năng cạnh tranh của Nhà xây dựng; nếu Trình tạo không đủ cạnh tranh, họ sẽ khó đảm bảo quyền tạo khối, do đó làm giảm đáng kể độ tin cậy của các dịch vụ Xác nhận trước của họ. Để tránh những vấn đề này, một cách tiếp cận tốt hơn là cho phép Người đề xuất cung cấp dịch vụ Xác nhận trước, vì nó thường được xác định trước và chắc chắn Người đề xuất nào sẽ đề xuất khối nào. Tuy nhiên, trong kiến trúc PBS hiện tại, Người đề xuất chỉ đề xuất các khối và việc sản xuất khối thực tế và ra quyết định nội dung được thực hiện bởi Người xây dựng, vì vậy Người đề xuất không thể trực tiếp chèn giao dịch vào khối hoặc yêu cầu Người xây dựng làm như vậy. Trong tương lai, nếu kiến trúc PBS thay đổi, ví dụ, bằng cách thêm Danh sách bao gồm hoặc cho phép Người đề xuất tham gia vào sản xuất khối, Người đề xuất có thể có cơ hội cung cấp dịch vụ Xác nhận trước. Để biết thêm thông tin về PBS, vui lòng truy cập liên kết được cung cấp.

Cải thiện Trước Xác nhận:

Pre-Confirmation chỉ là cam kết bằng lời nói của Builders hoặc L2 Sequencers, không có nghĩa vụ phải thực hiện cam kết và không có cơ chế phạt nếu không thực hiện. Tuy nhiên, có thể làm cho cam kết này đáng tin cậy hơn bằng cách sử dụng hợp đồng thông minh để tiêu chuẩn hóa Builders hoặc Sequencers. Họ có thể cung cấp dịch vụ Pre-Confirmation trong khi cũng gửi một khoản tiền đặt cọc vào hợp đồng thông minh, và ký kết nội dung khi cam kết bao gồm giao dịch. Nếu người dùng phát hiện Builders hoặc Sequencers không thực hiện cam kết của họ, họ có thể gửi nội dung cam kết và chữ ký đến hợp đồng thông minh, sau đó hợp đồng có thể xác minh xem cam kết đã được giữ hay không. Mặc dù kịch bản ứng dụng của hợp đồng trên vẫn ở giai đoạn chứng minh khái niệm, liên kết dưới đây cho thấy một video trình bày về một ví dụ ứng dụng hợp đồng như vậy.

Tóm tắt:

Sau khi các giao dịch L1 được bao gồm trong các khối L1, xác suất tổ chức lại giảm và niềm tin của người dùng vào việc bao gồm giao dịch tăng dần. Các giao dịch L2 có quy trình làm việc bổ sung so với các giao dịch L1: "Các giao dịch L2 được bao gồm trong các khối L2 và đang chờ tải lên L1." Tuy nhiên, vì dữ liệu chưa được tải lên L1 trong giai đoạn này, nên vẫn có khả năng xảy ra sự khác biệt, vì vậy sự đảm bảo mà người dùng có thể nhận được về việc bao gồm giao dịch ở giai đoạn này là cam kết bằng lời nói từ Trình sắp xếp, đượ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 giản là gặp lỗi, lời hứa của họ có thể bị phá vỡ, dẫn đến 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 Explorer của họ bao gồm trạng thái Xác nhận trước, chẳng hạn như Arbitrum / Optimism's Confirmed by Sequencer hoặc StarkNet's Accepted on L2. Khi nhìn thấy thông tin như vậy, điều quan trọng là phải chú ý đến hiệu quả thời gian của đảm bảo bao gồm giao dịch được cung cấp. Nếu người dùng không muốn dựa vào Xác nhận trước của Trình sắp xếp, họ sẽ cần đợi lâu hơn và xác minh thông qua thông tin của L2 Explorer về dữ liệu L2 được tải lên L1. Xác nhận trước có thể kết hợp một cơ chế khuyến khích kinh tế, chẳng hạn như phạt Sequencers thông qua các hợp đồng thông minh khi họ thất hứa, cung cấp cho người dùng sự bảo vệ rõ ràng hơn. Bảng dưới đây cho thấy sự đảm bảo bao gồm 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à L2 ở các giai đoạn khác nhau của quá trình giao dịch.

Disclaimer：

1. Bài viết này được tái bản từ [Gateaicoin]. Mọi bản quyền thuộc về tác giả gốc [Foresight News]. Nếu có ý kiến ​​phản đối về việc tái in này, vui lòng liên hệ với Gate Họcđội của chúng tôi, và họ sẽ xử lý nó ngay lập tức.
2. Liability Disclaimer: 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 đội ngũ Gate Learn. Trừ khi được nêu rõ, việc sao chép, phân phối hoặc đạo văn bản dịch là không được phép.