Giải thích các giai đoạn khác nhau của doanh thu xác nhận giao dịch L2
Tuyển chọn TechFlowTuyển chọn TechFlow
Giải thích các giai đoạn khác nhau của doanh thu xác nhận giao dịch L2
Giới thiệu toàn bộ quy trình thực hiện giao dịch L2 và phân tích tính năng bảo mật ở các giai đoạn khác nhau của quy trình giao dịch.
Chuyên sâu báo cáo Web3Tác giả: Nic @imToken Labs
Khi nào thì có thể chắc chắn rằng một giao dịch L2 (Layer 2) sẽ được đưa vào khối? Khi nào thì có thể chắc chắn rằng lợi nhuận từ mộ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ộ quy trình thực hiện giao dịch L2 cho người đọc và phân tích mức độ an toàn ở từng giai đoạn của quy trình giao dịch.
Kiến thức nền tảng:
-
Toàn bộ quy trình giao dịch L1 (Layer 1)
-
Nguyên nhân và ảnh hưởng của sự kiện Re-org
-
Hiểu về các vai trò và cách vận hành trong kiến trúc PBS hiện tại của Ethereum
-
Hiểu sự khác biệt giữa Optimistic Rollup và Validity (ZK) Rollup
Tìm hiểu về giao dịch L1
Quy trình giao dịch
Sau khi người dùng tạo và ký giao dịch, nó sẽ được gửi vào mạng p2p, chờ Miner trong cơ chế đồng thuận PoW hoặc Proposer trong cơ chế đồng thuận PoS đưa giao dịch vào khối. Khi người dùng phát hiện giao dịch của mình đã được đưa vào khối mới nhất, họ vẫn chưa thể hoàn toàn chắc chắn rằng giao dịch sẽ được ghi vĩnh viễn vào lịch sử chuỗi khối, vì chuỗi khối có thể xảy ra hiện tượng gọi là «Re-org». Người dùng phải tiếp tục chờ đợi cho đến khi khả năng xảy ra Re-org tại khối đó thấp đến mức đủ an toàn, lúc đó mới có thể tin tưởng chắc chắn rằng giao dịch đã được xác nhận cuối cùng (finalized).
Sơ đồ quy trình giao dịch L1
Ngay cả sau khi giao dịch đã được đưa vào khối, vẫn có thể xảy ra Re-org; chỉ khi nào nguy cơ Re-org trở nên cực kỳ thấp thì mới có thể chắc chắn rằng giao dịch đã được Finalized.
Xác suất và chi phí để gây ra Re-org phụ thuộc vào thuật toán đồng thuận và giá trị thị trường tài sản của chuỗi đó, bài viết này sẽ không đi sâu vào cách tính toán chi phí Re-org.
Tìm hiểu về giao dịch L2
Quy trình giao dịch
Sau khi người dùng L2 tạo và ký giao dịch, thường thì giao dịch sẽ được gửi trực tiếp đến Sequencer – thành phần chịu trách nhiệm sắp xếp giao dịch – để Sequencer đưa giao dịch vào khối L2. Sau đó, khi Sequencer ghi dữ liệu khối L2 lên L1 thông qua một giao dịch trên L1, người dùng sẽ thấy giao dịch của mình nằ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 một giao dịch L1, nên vẫn có khả năng xảy ra Re-org trên L1 khiến khối L2 đó cuối cùng không được ghi vào lịch sử chuỗi khối – tương đương với L2 Re-org. Do đó, người dùng vẫn phải chờ đến khi khả năng xảy ra Re-org trên L1 đủ thấp thì mới có thể chắc chắn rằng giao dịch đã được ghi vào lịch sử chuỗi khối.
Sơ đồ quy trình giao dịch L2
Người dùng lần lượt chờ: giao dịch được đưa vào khối L2 → khối L2 được tải lên L1 qua một giao dịch L1 → giao dịch L1 được Finalized.
Mặc dù so với giao dịch L1, giao dịch L2 có thêm thời gian chờ để được Sequencer đưa vào khối L2, nhưng nếu dung lượng khối L2 đủ lớn và tốc độ tạo khối đủ nhanh thì thời gian chờ này không đáng kể. Thời gian chủ yếu tiêu tốn ở việc xác nhận giao dịch L1 được đưa vào, do đó trải nghiệm sử dụng tổng thể giữa giao dịch L1 và L2 là khá tương tự nhau.
Tuy nhiên, nếu người dùng sẵn sàng đánh đổi điều gì đó, liệu có thể đạt được trải nghiệm tốt hơn không?
Pre-Confirmation / Fast Confirmation / Soft Confirmation
Người dùng nên tự mình chứng kiến (giao dịch L2) khối L2 được đưa vào khối L1, thậm chí phải chờ đến khi xác suất xảy ra Re-org đủ thấp, mới có thể tin rằng giao dịch L2 của họ đã được xác nhận.
Nhưng nếu người dùng sẵn sàng tin tưởng Sequencer thì sao? Có thể Sequencer do nhóm phát triển L2 vận hành, hoặc do một tổ chức uy tín điều hành. Nếu Sequencer cam kết với người dùng rằng giao dịch của họ sẽ được đưa vào ngay lập tức, hoặc chắc chắn nằm trong khối thứ X, thì đối với những người dùng tin tưởng Sequencer, cam kết này có thể là đủ. Cũng giống như người dùng tin tưởng ví mà họ đang dùng, họ sẽ không còn hoài nghi kiểm tra lại giao dịch trên Etherscan sau khi ví đã báo thành công.
Cam kết này từ Sequencer được gọi là Pre-Confirmation, Fast Confirmation hoặc Soft Confirmation – có thể hiểu là lời hứa "sớm" hay "mềm" về việc đưa giao dịch vào khối. Nó không cần chờ đến khi giao dịch L2 được ghi vào khối L1, nhưng chỉ là lời hứa bằng miệng từ Sequencer. Sequencer có thể quên cam kết do lỗi phần mềm, hoặc một Sequencer độc hại có thể cố tình vi phạm cam kết, nhẹ thì làm mất thời gian người dùng, nặng thì dẫn đến tấn công "double spend".
Tiếp theo, chúng ta sẽ tìm hiểu một số cách biểu diễn trạng thái xác nhận giao dịch L2 khác nhau.
Trạng thái xác nhận giao dịch trên Arbitrum/Optimism
Hiện nay, người dùng trên Arbitrum hoặc Optimism sau khi gửi giao dịch gần như ngay lập tức nhận được biên lai giao dịch (Transaction Receipt), trong đó chứa kết quả thực thi giao dịch. Điều này cho thấy Sequencer đã sắp xếp giao dịch tại máy cục bộ và mô phỏng thực thi một lần. Biên lai này chính là Pre-Confirmation dành cho người dùng.
Để biết thêm chi tiết về vòng đời giao dịch trên Arbitrum, hãy 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://docs.arbitrum.io/tx-lifecycle
Thông tin chi tiết về vòng đời giao dịch trên Optimism, sao chép liên kết bên dưới vào trình duyệt: https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1
Kiểm tra trạng thái giao dịch trên Arbitrum
Trên Arbitrum Explorer, các giao dịch hiển thị bao gồm cả giao dịch ở trạng thái Pre-Confirmation – tức là chưa được tải lên L1. Như trong hình dưới đây, có thể thấy bên cạnh Block Number 145353000 xuất hiện nhãn «Confirmed by Sequencer»:
Giao dịch chỉ được Sequencer xác nhận nhưng chưa được tải lên L1
Nếu là giao dịch như trong hình dưới đây đã được tải lên L1, trạng thái sẽ hiện là «69 L1 Block Confirmations», nghĩa là nó đã được tải lên L1 và đã có 69 khối L1 được xây dựng nối tiếp sau khối chứa dữ liệu giao dịch này:
Đã có 69 khối L1 nối tiếp sau khối chứa dữ liệu giao dịch này – càng nhiều khối nối tiếp, càng an toàn.
Hoặc như giao dịch trong ảnh chụp màn hình dưới đây, đã có tới 6174 khối L1 nối tiếp phía sau khối chứa dữ liệu giao dịch – mức độ an toàn rất cao.
Tuy nhiên, điểm cải thiện ở đây là có thể tích hợp thông tin Finality của L1 để hiển thị rõ hơn.
Việc chỉ đơn thuần thông báo cho người dùng số lượng «L1 Block Confirmations» có hạn chế về mặt hỗ trợ, vì người dùng vẫn phải tự suy luận và tính toán mức độ an toàn tương ứng. Trong khi Layer1 (tức là Ethereum) đã có cơ chế Finality Casper FFG, nên Explorer hoàn toàn có thể trực tiếp hiển thị xem khối L1 đó đã được Finalized trên Layer1 hay chưa. Hiện tại, Optimism Explorer đã thực hiện được chức năng này.
Kiểm tra trạng thái giao dịch trên Optimism
Trên Optimism Explorer, các giao dịch cũng bao gồm cả giao dịch ở trạng thái Pre-Confirmation – chưa được tải lên L1. Như trong hình dưới đây, có thể thấy bên cạnh Block Number 111526300 xuất hiện nhãn «Confirmed by Sequencer»:
Giao dịch chỉ được Sequencer xác nhận nhưng chưa được tải lên L1
Tuy nhiên hiện tại Explorer này dường như chưa định nghĩa rõ ràng ý nghĩa của «Confirmed by Sequencer». Nó nói rằng «Sequencer confirmations are equivalent to a few block confirmations on L1», nghĩa là «được Sequencer xác nhận tương đương với vài lần xác nhận khối trên L1», ám chỉ rằng giao dịch đã được tải lên L1 và đã có vài khối nối tiếp phía sau:
Nhưng thực tế, giao dịch mới xuất hiện cũng hiển thị «Confirmed by Sequencer», thậm chí giao dịch cách đây vài chục ngày, đã qua giai đoạn thách thức, vẫn hiển thị trạng thái «Confirmed by Sequencer»:
Trạng thái giao dịch từ vài chục ngày trước vẫn là «Confirmed by Sequencer»
Lưu ý đọc: Trường hợp trên cũng có thể do Explorer đặt các trạng thái khác nhau ở vị trí khác nhau: nhãn «Confirmed By Sequencer» bên cạnh Block Number chỉ cho người dùng biết khối đã được Sequencer xác nhận, còn trạng thái sau khi được tải lên L1 thì người dùng phải tự kiểm tra qua các thông tin khác, ví dụ như thông tin «L1 State Batch» sẽ được đề cập ngay sau đây.
Ngoài ra, như trong ảnh chụp màn hình dưới đây, với giao dịch đã được tải lên L1, có thêm hai thông tin: «L1 State Batch Index» và «L1 State Root Submission Tx Hash». Hai thông tin này cho biết giao dịch L2 này nằm trong State Batch nào, và State Batch đó được tải lên L1 qua giao dịch L1 nào:
Khi nhấn vào State Batch «3480», bạn có thể thấy trạng thái là Finalized. Từ «Finalized» này tương ứng với trạng thái Finalized trên L1 (tức là Ethereum mainnet), là trạng thái rất an toàn đã tích lũy đủ hai Epoch phiếu bầu từ các validator.
△ State Batch 3480 được đưa vào L1 Block 18457449, và khối 18457449 đã được Finalized.
Nguồn: https://etherscan.io/block/18457449
Nếu là batch đã được tải lên nhưng chưa được Finalized trên L1, sẽ hiển thị là Unfinalized:
State Batch 3494 đã được tải lên L1 nhưng khối L1 chứa batch này chưa được Finalized.
So với Arbitrum Explorer, Optimism Explorer cung cấp nhiều thông tin hơn (State Batch) và trực tiếp tích hợp thông tin Finality của L1 vào giao diện L2, giúp người dùng biết ngay khối L1 đã được Finalized hay chưa, thay vì phải tự đánh giá mức độ an toàn dựa trên số lượng Block Confirmation.
Trạng thái xác nhận giao dịch trên StarkNet
Hiện nay, người dùng trên StarkNet sau khi gửi giao dịch, mặc dù có thể nhanh chóng tra cứu biên lai giao dịch, nhưng thường trạng thái trong biên lai sẽ là RECEIVED, nghĩa là nút đã nhận được giao dịch và xác minh không có vấn đề, đang chờ Sequencer đưa vào khối L2 và thực thi. Giao dịch ở trạng thái RECEIVED chưa có kết quả thực thi nào.
Người dùng có thể theo dõi tiến độ xử lý giao dịch thông qua trạng thái hiển thị trên StarkNet Explorer.
Lưu ý đọc: Nếu Sequencer xử lý đủ nhanh, có thể bỏ qua luôn trạng thái RECEIVED và chuyển thẳng sang trạng thái đã được xử lý. Để biết thêm chi tiết về quy trình giao dịch trên StarkNet, sao chép liên kết bên dưới vào trình duyệt: https://docs.starknet.io/documentation/architecture_and_concepts/Network_Architecture/transaction-life-cycle/
Tài liệu chính thức: https://docs.starknet.io/documentation/architecture_and_concepts/Network_Architecture/transaction-life-cycle/
Trên Starkscan – Explorer của StarkNet – các giao dịch cũng bao gồm cả giao dịch ở trạng thái Pre-Confirmation. Như trong hình dưới đây, có thể thấy Status hiện là «Accepted on L2», nghĩa là đã được Sequencer đưa vào khối L2:
«Accepted on L2» nghĩa là đã được Sequencer đưa vào khối L2 nhưng chưa được tải lên L1
Hai trạng thái trước «Accepted on L2» là Received và Pending, tương ứng với «giao dịch đã được nhận và xác minh thành công» và «giao dịch đang được Sequencer xử lý». Sau khi thực thi xong, giao dịch sẽ chuyển sang trạng thái «Accepted on L2»:
Giao dịch đã được nhận và xác minh thành công
Giao dịch đang được Sequencer xử lý
Chỉ khi dữ liệu giao dịch được tải lên L1, trạng thái mới chuyển thành «Accepted on L1», như trong hình dưới đây:
Dữ liệu giao dịch đã được tải lên L1
Mặc dù StarkNet có nhiều trạng thái phong phú giúp người dùng theo dõi tiến độ xử lý, nhưng thời gian tải dữ liệu lên L1 có thể phải chờ 4–5 tiếng (có thể do việc tạo bằng chứng zero-knowledge mất nhiều thời gian). Vì vậy, trong khoảng thời gian này, người dùng hoàn toàn phụ thuộc vào Pre-Confirmation từ Sequencer.
Thêm vào đó, Explorer chỉ hiển thị «Accepted on L1» cho giao dịch đã được tải lên L1, không hiển thị thông tin Finality hoặc Block Confirmation của L1, nghĩa là người dùng phải tự tra cứu xem khối L1 có đủ khối nối tiếp hay đã được Finalized hay chưa.
Nhìn chung, do nút thắt hiệu năng của StarkNet khiến người dùng phải phụ thuộc lâu vào Pre-Confirmation, cộng với việc Explorer không hỗ trợ thông tin Finality của L1, trải nghiệm xác nhận giao dịch trên StarkNet chưa tốt – đây là điểm StarkNet cần cải thiện trong tương lai.
Trạng thái xác nhận giao dịch trên zkSync
Tương tự StarkNet, zkSync cũng có trạng thái PENDING, nghĩa là nút đã nhận giao dịch và xác minh không có vấn đề, đang chờ Sequencer đưa vào khối L2 và thực thi. Giao dịch ở trạng thái PENDING chưa có kết quả thực thi nào.
Người dùng có thể theo dõi tiến độ xử lý giao dịch thông qua trạng thái hiển thị trên zkSync Explorer.
Lưu ý đọc: Nếu Sequencer xử lý đủ nhanh, có thể bỏ qua trực tiếp trạng thái PENDING và chuyển sang trạng thái đã xử lý.
Để biết thêm chi tiết về quy trình giao dịch trên zkSync, sao chép liên kết bên dưới vào trình duyệt: https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum
Trên zkSync Explorer, các giao dịch cũng bao gồm cả giao dịch ở trạng thái Pre-Confirmation. Như trong ảnh chụp màn hình dưới đây, trạng thái hiện là «zkSync Era Processed», nghĩa là đã được Sequencer đưa vào khối L2:
Giao dịch đã được Sequencer đưa vào khối L2, đang chờ được tải lên L1 (Ethereum Sending)
Sau khi Sequencer tạo xong khối L2, khối và các giao dịch bên trong sẽ lần lượt trải qua ba giai đoạn: Committed → Proven → Executed, tương ứng với «khối được tải lên L1», «tính hợp lệ của khối đã được chứng minh», và «trạng thái L2 sau khi thực thi giao dịch đã được cập nhật lên L1». Dưới đây là minh họa cho ba khối ở các giai đoạn khác nhau:
Batch 292700 đã được tải lên L1, bước vào giai đoạn Committed. Nguồn: https://explorer.zksync.io/batch/292700
Các giao dịch trong Batch 292700 chuyển từ Ethereum Sending sang Ethereum Validating, nghĩa là đang chờ được chứng minh tính hợp lệ bằng bằng chứng zero-knowledge.
Di chuột vào biểu tượng Ethereum Validating sẽ hiển thị các giai đoạn con, và liên kết giao dịch giai đoạn trước (Sending) cũng được đính kèm:
Giao dịch bước vào giai đoạn «Validating», liên kết giao dịch giai đoạn trước (Sending) được hiển thị rõ ràng.
Batch 292000 đã được chứng minh tính hợp lệ, nên bước vào giai đoạn Proven:
Batch được chứng minh → trạng thái Proven, kèm theo liên kết giao dịch thực hiện hành động Prove.
Các giao dịch bên trong chuyển từ «Validating» sang «Executing», nghĩa là đang chờ thực thi.
Sau khi batch được chứng minh, sẽ có giai đoạn chờ (theo tài liệu khoảng 21 giờ) trước khi thực thi các giao dịch và cập nhật trạng thái L2 lên L1. Đây là biện pháp bảo vệ trong giai đoạn Alpha, nhằm đảm bảo có đủ thời gian phản ứng nếu phát sinh lỗi. Khi batch được thực thi, sẽ bước vào giai đoạn cuối cùng là Executed:
Batch được thực thi → trạng thái cuối cùng Executed, kèm theo liên kết giao dịch thực hiện Execute.
Trạng thái các giao dịch bên trong cũng được cập nhật thành «Executed»
So với StarkNet, nơi việc chuyển từ L2 sang L1 diễn ra trong một bước, zkSync chia quá trình này thành ba giai đoạn chi tiết hơn: Committed → Proven → Executed.
Mặc dù là biện pháp bảo vệ khiến toàn bộ quá trình kéo dài khoảng một ngày, nhưng trạng thái Committed cho phép người dùng nhanh chóng biết giao dịch đã được đưa vào (sau khi vào Committed, không còn là Pre-Confirmation nữa), không cần tiếp tục tin tưởng hoàn toàn vào Sequencer.
Hơn nữa, zkSync Explorer cung cấp dữ liệu đầy đủ và phong phú cho từng giai đoạn, bất kỳ ai cũng có thể theo dõi trạng thái mới nhất của giao dịch, thậm chí tự xác minh việc chuyển đổi giữa các giai đoạn (ví dụ từ Committed sang Proven, từ Proven sang Executed).
Tuy nhiên cần lưu ý rằng, do là biện pháp bảo vệ trong giai đoạn Alpha, hiện tại Sequencer zkSync có thể sửa đổi lịch sử.
Điều này cho thấy dù giao dịch có thể nhanh chóng thoát khỏi Pre-Confirmation và đạt trạng thái Committed, nhưng trước khi đạt trạng thái Executed, Sequencer vẫn có thể loại bỏ giao dịch khỏi lịch sử. Do đó, người dùng vẫn phải tin tưởng Sequencer trong suốt khoảng một ngày.
L1 cũng có thể hỗ trợ Pre-Confirmation
Nếu có thể biết trước ai là người sản xuất khối, thì L1 cũng có thể hỗ trợ Pre-Confirmation.
Ví dụ với Ethereum, hiện tại người thực sự sản xuất khối là Builder, do đó Builder có thể cung cấp dịch vụ Pre-Confirmation, đưa ra lời hứa về việc đưa giao dịch vào khối. Tuy nhiên, vì Builder không chắc chắn giành được quyền sản xuất một khối cụ thể (phải đấu giá quyền sản xuất từng khối), nên hiệu lực của Pre-Confirmation này kém hơn. Ngoài ra, cần xem xét năng lực của Builder – nếu sức cạnh tranh yếu, Builder khó giành quyền sản xuất khối, do đó dịch vụ Pre-Confirmation từ Builder này sẽ giảm giá trị.
Để tránh vấn đề trên, giải pháp tốt hơn là để Proposer cung cấp dịch vụ Pre-Confirmation, vì «khối thứ mấy do Proposer nào đề xuất» thường được tính toán trước và mang tính xác định.
Tuy nhiên, trong kiến trúc PBS hiện tại, Proposer chỉ là người đề xuất khối, còn người thực sự tạo khối và quyết định nội dung khối là Builder, nên Proposer không thể tự chèn giao dịch vào khối hay yêu cầu Builder chèn giao dịch. Chỉ khi kiến trúc PBS thay đổi trong tương lai, ví dụ thêm Inclusion List hoặc cho phép Proposer tham gia tạo khối, thì Proposer mới có cơ hội cung cấp dịch vụ Pre-Confirmation.
Lưu ý đọc: Để biết thêm về PBS, sao chép liên kết bên dưới vào trình duyệt: https://mirror.xyz/0x347c9872A2a1dE370D798f9FE96341A9A0E05af8/oG_4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss.
Cải thiện Pre-Confirmation
Pre-Confirmation chỉ là lời hứa bằng miệng từ Builder hoặc Sequencer L2, bên đưa ra cam kết không có nghĩa vụ thực hiện, và không có cơ chế trừng phạt nếu vi phạm.
Liệu có thể làm cho lời cam kết này đáng tin cậy hơn không? Câu trả lời là có thể, vì người sản xuất khối và nội dung cam kết (ví dụ «đưa giao dịch vào khối 1350000») đều có thể được kiểm tra dưới dạng điều kiện. Chúng ta có thể sử dụng hợp đồng thông minh để quy định Builder hoặc Sequencer, yêu cầu họ đặt cọc tiền ký quỹ khi cung cấp dịch vụ Pre-Confirmation, đồng thời ký vào nội dung cam kết. Khi người dùng phát hiện Builder hoặc Sequencer không thực hiện cam kết, họ có thể gửi nội dung cam kết và chữ ký đến hợp đồng thông minh để kiểm tra.
Mặc dù các ứng dụng hợp đồng kiểu này vẫn đang ở giai đoạn thử nghiệm khái niệm, nhưng video bài giảng trong liên kết bên dưới trình bày một ví dụ cụ thể. Chi tiết xem tại: https://www.youtube.com/watch?v=Uw5HxSYXwYo
Tổng kết
-
Sau khi giao dịch L1 được đưa vào khối L1, xác suất xảy ra Re-org giảm dần theo thời gian, niềm tin của người dùng vào việc giao dịch được xác nhận tăng dần.
-
Giao dịch L2 so với L1 có thêm một bước: «giao dịch L2 được đưa vào khối L2 và chờ tải lên L1».
-
Trong bước bổ sung này của giao dịch L2, dữ liệu chưa được tải lên L1, vẫn còn rủi ro biến động, do đó bảo đảm mà người dùng nhận được về việc xác nhận giao dịch vẫn chỉ là lời hứa bằng miệng từ Sequencer, gọi là Pre-Confirmation, Fast Confirmation hoặc Soft Confirmation.
-
Nếu Sequencer độc hại hoặc đơn giản là gặp lỗi, cam kết từ Sequencer có thể bị vi phạm, dẫn đến giao dịch L2 không được xác nhận.
-
Hiện tại, hầu hết các L2 đều hiển thị trạng thái Pre-Confirmation trên Explorer của họ, ví dụ như «Confirmed by Sequencer» trên Arbitrum/Optimism hoặc «Accepted on L2» trên StarkNet. Khi thấy những thông tin này, hãy chú ý thời điểm hiệu lực của cam kết xác nhận giao dịch.
-
Nếu không muốn tin tưởng Pre-Confirmation từ Sequencer, người dùng cần chờ lâu hơn và tự kiểm tra thông tin trên L2 Explorer về việc dữ liệu L2 đã được tải lên L1 hay chưa.
-
Pre-Confirmation có thể được thiết kế thêm cơ chế khuyến khích kinh tế, ví dụ như phạt Sequencer khi vi phạm cam kết thông qua hợp đồng thông minh, để người dùng có được sự bảo đảm rõ ràng hơn.
Bảng dưới đây thể hiện mức độ bảo đảm xác nhận giao dịch và rủi ro tương ứng ở từng giai đoạn quy trình giao dịch L1 và L2:
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@imTokenOfficial
