Từ lý thuyết đến thực tiễn: Phân tích cơ chế thực hiện giao dịch chống kiểm duyệt của Ethereum Rollup

Tiêu đề gốc: "Giới thiệu cơ chế Force Inclusion của Rollup"

Tác giả: NIC Lin, người phụ trách Taipei Ethereum Meetup

Vừa hôm qua đã xảy ra một sự kiện gây chấn động cho nhiều người: Dịch vụ Layer 2 Linea của Ethereum do công ty mẹ Metamask là Consensys phát hành đã chủ động ngừng hoạt động, với lý do chính thức là để giảm thiểu tác động của vụ tấn công hacker Velocore. Điều này khiến người ta nhớ lại việc chuỗi BSC (BNB Chain) đã ngừng hoạt động để giảm thiểu thiệt hại do hacker tấn công trước đó. Mỗi khi mọi người bàn luận về những vấn đề như vậy, họ lại nghi ngờ về giá trị phi tập trung mà Web3 đang thúc đẩy.

Tất nhiên, nguyên nhân cốt lõi của sự kiện trên chủ yếu nằm ở sự thiếu hoàn thiện của cơ sở hạ tầng, tức là không đủ phi tập trung: Nếu một chuỗi đủ phi tập trung, thì không nên nói ngừng là ngừng. Do cấu trúc độc đáo của Layer 2 Ethereum, hầu hết các Layer 2 đều phụ thuộc vào Sequencer tập trung. Mặc dù trong những năm gần đây, có nhiều quan điểm về việc phát triển các trình sắp xếp phi tập trung, nhưng xét đến mục đích tồn tại và cấu trúc của Layer 2, chúng ta có thể cho rằng, trình sắp xếp của Layer 2 có khả năng cao sẽ không đủ phi tập trung, và cuối cùng có thể còn kém hơn mức độ phi tập trung của chuỗi BSC. Nếu thực tế đúng như vậy, thì chúng ta nên làm gì?

Thực ra, đối với Layer 2, mối nguy hiểm trực tiếp nhất do việc không phi tập trung của trình sắp xếp mang lại là khả năng kháng kiểm duyệt và tính khả dụng. Nếu có rất ít thực thể xử lý giao dịch (Sequencer), thì chúng nắm giữ quyền lực tuyệt đối trong việc phục vụ bạn: muốn từ chối thì từ chối, và bạn có thể không có cách nào để phản kháng. Cách giải quyết vấn đề kháng kiểm duyệt của Layer 2 rõ ràng là một chủ đề quan trọng.

Trong vài năm qua, các Layer 2 lớn của Ethereum đã đưa ra nhiều giải pháp khác nhau cho vấn đề kháng kiểm duyệt, chẳng hạn như các chức năng rút tiền cưỡng bức và buồng thoát của Loopring, Degate và StarkEx, cũng như chức năng Force Inclusion của Arbitrum và các OP Rollup khác. Những phương pháp này có thể tạo ra sự cân bằng nhất định đối với Sequencer trong một số điều kiện, nhằm ngăn chặn việc từ chối vô lý các yêu cầu giao dịch của bất kỳ người dùng nào.

Trong bài viết hôm nay, NIC Lin từ Hiệp hội Ethereum Taipei sẽ chia sẻ, đã tự mình thử nghiệm chức năng giao dịch kháng kiểm duyệt của 4 Rollup chính, phân tích sâu về thiết kế cơ chế Force Inclusion từ quy trình làm việc đến phương pháp vận hành, điều này đặc biệt có giá trị tham khảo cho cộng đồng Ethereum và những người nắm giữ tài sản lớn.

Kiểm duyệt giao dịch và Force Inclusion

Khả năng kháng kiểm duyệt giao dịch (Censorship Resistance) là rất quan trọng đối với một chuỗi blockchain, nếu blockchain có thể tùy ý kiểm duyệt và từ chối các giao dịch do người dùng khởi xướng, thì nó cũng giống như một máy chủ Web2. Khả năng kháng kiểm duyệt giao dịch hiện tại của Ethereum đến từ số lượng lớn các Validator, nếu ai đó muốn kiểm duyệt giao dịch của Bob, không cho giao dịch của anh ta lên chuỗi, thì họ phải mua chuộc phần lớn Validator trong mạng, hoặc gửi các giao dịch rác với phí giao dịch cao hơn Bob để chiếm chỗ trong khối. Dù bằng cách nào, chi phí sẽ rất cao.

Lưu ý: Trong cấu trúc PBS hiện tại của Ethereum, chi phí kiểm duyệt giao dịch đã giảm đáng kể, có thể tham khảo tỷ lệ khối kiểm duyệt giao dịch Tornado Cash theo OFAC. Khả năng kháng kiểm duyệt hiện tại phụ thuộc vào các Validator và Relay độc lập bên ngoài OFAC và quyền tài phán của chính phủ.

Nhưng Rollup thì sao? Rollup không cần một đống Validator để đảm bảo tính an toàn, ngay cả khi Rollup chỉ có một vai trò tập trung (Sequencer) để tạo ra khối, nó vẫn an toàn như L1. Nhưng an toàn và khả năng kháng kiểm duyệt là hai vấn đề khác nhau, ngay cả khi một Rollup an toàn như Ethereum, nhưng trong trường hợp chỉ có một Sequencer tập trung, thì việc kiểm duyệt bất kỳ giao dịch nào của người dùng đều có thể xảy ra.

Sequencer có thể từ chối xử lý giao dịch của người dùng, dẫn đến việc tài sản của người dùng bị giữ lại và không thể rời khỏi Rollup

Cơ chế Force Inclusion

Thay vì yêu cầu Rollup có nhiều Sequencer phi tập trung, tốt hơn là tận dụng khả năng kháng kiểm duyệt của L1:

Bản chất của Sequencer là đóng gói dữ liệu giao dịch và gửi đến hợp đồng Rollup trên L1, không bằng việc thêm một thiết kế vào hợp đồng, cho phép người dùng tự mình chèn giao dịch vào hợp đồng Rollup, cơ chế này được gọi là "Force Inclusion". Chỉ cần Sequencer không thể kiểm duyệt người dùng ở cấp độ L1, nó sẽ không thể ngăn cản người dùng chèn giao dịch một cách cưỡng bức vào L1. Như vậy, Rollup có thể kế thừa khả năng kháng kiểm duyệt của L1.

Sequencer không thể kiểm duyệt giao dịch L1 của người dùng, trừ khi phải trả một chi phí rất cao

Giao dịch cưỡng bức nên được thực hiện như thế nào?

Nếu cho phép giao dịch được viết trực tiếp vào hợp đồng Rollup thông qua Force Inclusion (tức là có hiệu lực ngay lập tức), thì trạng thái của Rollup sẽ thay đổi ngay lập tức, ví dụ như Bob thông qua cơ chế Force Inclusion chèn một giao dịch "chuyển 1000 DAI cho Carol", nếu giao dịch có hiệu lực ngay lập tức, thì trong trạng thái mới nhất, số dư của Bob sẽ giảm 1000 DAI, và Carol sẽ tăng 1000 DAI.

Nếu Force Inclusion có thể viết trực tiếp giao dịch vào hợp đồng Rollup và có hiệu lực ngay lập tức, thì trạng thái sẽ thay đổi ngay lập tức

Nếu lúc này Sequencer cũng đang thu thập giao dịch ngoài chuỗi và gửi lô giao dịch tiếp theo lên hợp đồng Rollup, thì có thể bị ảnh hưởng bởi giao dịch mà Bob đã chèn cưỡng bức và có hiệu lực ngay lập tức. Vấn đề này cần phải tránh bằng mọi giá, vì vậy Rollup thường không cho phép giao dịch Force Inclusion có hiệu lực ngay lập tức, mà trước tiên cho phép người dùng chèn giao dịch vào hàng đợi chờ trên L1, vào trạng thái "đang chuẩn bị".

Sequencer khi đóng gói giao dịch ngoài chuỗi gửi lên hợp đồng Rollup, sẽ chọn có chèn giao dịch ở trạng thái "đang chuẩn bị" vào chuỗi giao dịch hay không, nếu Sequencer liên tục phớt lờ những giao dịch ở trạng thái "đang chuẩn bị", sau khi thời gian chờ kết thúc, người dùng có thể chèn những giao dịch này cưỡng bức vào hợp đồng Rollup.

Sequencer có thể quyết định khi nào "tiện thể thu nhận" các giao dịch trong hàng đợi chờ

Sequencer vẫn có thể từ chối xử lý các giao dịch trong hàng đợi chờ

Nếu Sequencer từ chối lâu dài, sau một thời gian, bất kỳ ai cũng có thể sử dụng chức năng Force Inclusion để cưỡng bức chèn giao dịch vào hợp đồng Rollup

Tiếp theo, chúng tôi sẽ lần lượt giới thiệu cơ chế Force Inclusion của bốn Rollup nổi tiếng là Optimism, Arbitrum, StarkNet và zkSync.

Cơ chế Force Inclusion của Optimism

Đầu tiên giới thiệu quy trình Deposit của Optimism, quy trình này không chỉ đề cập đến việc gửi tiền vào Optimism, mà còn bao gồm việc "gửi thông tin từ người dùng đến L2" vào L2. Khi nút L2 nhận được thông điệp mới được gửi vào, nó sẽ chuyển đổi thông điệp thành một giao dịch L2 để thực hiện, gửi đến bên nhận được chỉ định trong thông điệp.

Người dùng gửi thông điệp từ L1 đến L2

Hợp đồng L1CrossDomainMessenger

Khi một người dùng muốn gửi ETH hoặc token ERC-20 vào Optimism, họ sẽ tương tác với hợp đồng L1StandardBridge trên trang web frontend, chỉ định số tiền muốn gửi và địa chỉ L2 nào sẽ nhận các tài sản này.

Hợp đồng L1StandardBridge sẽ chuyển thông điệp đến hợp đồng L1CrossDomainMessenger ở lớp tiếp theo, hợp đồng này chủ yếu là thành phần giao tiếp giữa L1 và L2, L1StandardBridge sẽ giao tiếp với L2StandardBridge trên L2 thông qua thành phần giao tiếp chung này, quyết định ai có thể đúc token trên L2, hoặc ai có thể mở khóa token từ L1.

Nếu nhà phát triển cần phát triển một hợp đồng để giao tiếp và đồng bộ trạng thái giữa L1 và L2, họ có thể xây dựng trên hợp đồng L1CrossDomainMessenger.

Thông điệp của người dùng được truyền từ L1 sang L2 thông qua hợp đồng CrossDomainMessenger

Lưu ý: Một số hình ảnh trong bài viết này đã viết CrossDomainMessager thành CrossChainMessager.

Hợp đồng OptimismPortal

Hợp đồng L1CrossDomainMessenger sẽ gửi thông điệp đến hợp đồng OptimismPortal ở lớp dưới cùng, sau khi hợp đồng OptimismPortal xử lý xong, nó sẽ phát ra một sự kiện có tên là TransactionDeposited, với các tham số bao gồm "người gửi thông điệp", "người nhận thông điệp", và các tham số thực thi liên quan.

Tiếp theo, nút Optimism trên L2 sẽ lắng nghe sự kiện Transaction Deposited do hợp đồng OptimismPortal phát ra và chuyển đổi các tham số trong sự kiện thành một giao dịch L2, người khởi xướng giao dịch này sẽ là "người gửi thông điệp" được chỉ định trong tham số của sự kiện Transaction Deposited, người nhận giao dịch sẽ là "người nhận thông điệp" trong tham số của sự kiện, các tham số giao dịch khác cũng được lấy từ các tham số trong sự kiện trên.

Nút L2 sẽ chuyển đổi các tham số của sự kiện Transaction Deposited do OptimismPortal phát ra thành một giao dịch L2

Ví dụ, đây là một giao dịch mà một người dùng gửi 0.01ETH qua hợp đồng L1StandardBridge, thông điệp này và ETH sẽ được chuyển đến hợp đồng OptimismPortal (địa chỉ là 0xbEb5…06Ed), sau đó vài phút sẽ được chuyển đổi thành giao dịch L2:

Người khởi xướng thông điệp là hợp đồng L1CrossDomainMessenger; người nhận là hợp đồng L2CrossDomainMessenger trên L2; nội dung thông điệp là hợp đồng L1StandardBridge đã nhận được khoản gửi 0.01ETH từ Bob. Sau đó, sẽ kích hoạt một số quy trình, chẳng hạn như phát hành thêm 0.01 ETH cho L2StandardBridge, và sau đó chuyển cho Bob.

Cách kích hoạt cụ thể

Khi bạn muốn cưỡng bức đưa giao dịch vào hợp đồng Rollup của Optimism, hiệu ứng bạn muốn đạt được là một giao dịch "được khởi xướng từ địa chỉ L2 của bạn trên L2 và muốn thực hiện" có thể được thực hiện thành công, lúc này bạn nên sử dụng địa chỉ L2 của mình để gửi thông điệp trực tiếp đến hợp đồng OptimismPortal (lưu ý rằng hợp đồng OptimismPortal thực sự nằm trên L1, nhưng định dạng địa chỉ của OP giống như định dạng địa chỉ L1, bạn chỉ cần sử dụng địa chỉ L1 giống như tài khoản L2 của mình để gọi hợp đồng trên).

Sau đó, người khởi xướng của giao dịch L2 được chuyển đổi từ sự kiện Transaction Deposited sẽ là tài khoản L2 của bạn, lúc này định dạng giao dịch sẽ giống như một giao dịch L2 bình thường.

Trong giao dịch L2 được chuyển đổi từ sự kiện Transaction Deposited, người khởi xướng sẽ là chính Bob; người nhận là hợp đồng Uniswap; và sẽ kèm theo ETH được chỉ định, giống như Bob tự khởi xướng giao dịch L2

Nếu bạn muốn gọi chức năng Force Inclusion của Optimism, bạn cần gọi trực tiếp hàm depositTransaction của hợp đồng OptimismPortal, điền các tham số của giao dịch mà bạn muốn thực hiện trên L2

Tôi đã thực hiện một thí nghiệm Force Inclusion đơn giản, giao dịch này muốn đạt được điều này: chuyển tiền từ địa chỉ của tôi trên L2 (0xeDc1…6909), và kèm theo một thông điệp "force inclusion".

Đây là giao dịch L1 mà tôi thực hiện hàm depositTransaction qua hợp đồng OptimismPortal, có thể thấy trong sự kiện Transaction Deposited mà nó phát ra, cả "from" và "to" đều là chính tôi.

Giá trị trong mục opaque Data mã hóa thông tin về "người gọi hàm deposit Transaction đã kèm theo bao nhiêu ETH", "người khởi xướng giao dịch L2 muốn chuyển bao nhiêu ETH cho người nhận", "Giới hạn Gas của giao dịch L2" và "Dữ liệu cho người nhận L2" v.v.

Giải mã thông tin trên sẽ lần lượt nhận được:

"Người gọi hàm deposit Transaction đã kèm theo bao nhiêu ETH": 0, vì tôi không gửi ETH từ L1 đến L2;

"Người khởi xướng giao dịch L2 muốn chuyển bao nhiêu ETH cho người nhận": 5566 (wei)

"Giới hạn Gas của giao dịch L2": 50000

"Dữ liệu cho người nhận L2": 0x666f72636520696e636c7573696f6e, tức là mã hex của chuỗi "force inclusion"

Không lâu sau, giao dịch L2 đã được chuyển đổi: một giao dịch tôi chuyển tiền cho chính mình trên L2, số tiền là 5566 wei, dữ liệu là chuỗi "force inclusion". Và có thể thấy, trong dòng thứ hai từ dưới lên trong mục Other Attributes, loại giao dịch (TxnType) hiển thị là giao dịch hệ thống 126 (System), cho thấy giao dịch này không phải do tôi tự khởi xướng trên L2, mà là được chuyển đổi từ sự kiện Deposited của giao dịch L1.

Giao dịch L2 đã được chuyển đổi

Nếu bạn muốn gọi hợp đồng L2 thông qua Force Inclusion, gửi dữ liệu khác, thì chỉ cần điền các tham số vào hàm deposit Transaction trước đó, chỉ cần nhớ rằng, bạn cần sử dụng địa chỉ L1 giống như tài khoản L2 của mình để gọi hàm deposit Transaction, như vậy khi sự kiện Deposited được chuyển đổi thành giao dịch L2, người khởi xướng sẽ là tài khoản L2 của bạn.

Cửa sổ Sequencer

Nút Optimism L2 đã đề cập trước đó sẽ chuyển đổi sự kiện Transaction Deposited thành giao dịch L2, thực ra nút Optimism này chỉ Sequencer, vì điều này liên quan đến việc sắp xếp giao dịch, nên chỉ có Sequencer mới có thể quyết định khi nào sẽ chuyển đổi sự kiện trên thành giao dịch L2.

Khi lắng nghe sự kiện TransactionDeposited, Sequencer không nhất thiết phải ngay lập tức chuyển đổi sự kiện thành giao dịch L2, có thể có một khoảng thời gian trễ, khoảng thời gian tối đa này được gọi là Cửa sổ Sequencer.

Hiện tại, Cửa sổ Sequencer trên mạng chính của Optimism là 24 giờ, tức là khi người dùng gửi một khoản tiền từ L1 hoặc một giao dịch Force Inclusion, trong trường hợp xấu nhất, phải sau 24 giờ mới được ghi vào lịch sử giao dịch L2.

Cơ chế Force Inclusion của Arbitrum

Trong Optimism, thao tác Deposit trên L1 sẽ phát ra một sự kiện Transaction Deposited, phần còn lại là chờ Sequencer ghi nhận thao tác trên; nhưng trong Arbitrum, các thao tác xảy ra trên L1 (gửi tiền hoặc gửi thông điệp đến L2, v.v.) sẽ được lưu trong một hàng đợi trên L1, thay vì chỉ đơn giản phát ra một sự kiện.

Sequencer sẽ được cấp một khoảng thời gian để đưa các giao dịch trong hàng đợi trên vào lịch sử giao dịch L2, nếu thời gian đã đến mà Sequencer vẫn không hành động, thì bất kỳ ai cũng có thể hoàn thành việc này thay cho Sequencer.

Arbitrum sẽ duy trì một hàng đợi trên hợp đồng L1, nếu Sequencer không chủ động xử lý các giao dịch trong hàng đợi, khi thời gian đã đến, bất kỳ ai cũng có thể cưỡng bức ghi nhận các giao dịch trong hàng đợi vào lịch sử giao dịch L2

Trong thiết kế của Arbitrum, các thao tác như gửi tiền xảy ra trên L1 đều phải thông qua hợp đồng Delayed Inbox, như tên gọi của nó, các thao tác ở đây sẽ bị trì hoãn; một hợp đồng khác là Sequencer Inbox, là nơi mà Sequencer tải giao dịch L2 lên L1. Mỗi lần Sequencer tải giao dịch L2 lên, họ có thể đồng thời lấy một số giao dịch đang chờ xử lý từ Delayed Inbox để ghi vào lịch sử giao dịch.

Sequencer có thể đồng thời lấy giao dịch từ DelayedInbox khi ghi vào giao dịch mới

Thiết kế phức tạp và tài liệu tham khảo có sẵn

Nếu độc giả tham khảo trực tiếp phần về Sequencer và Force Inclusion trên trang chính thức của Arbitrum, họ sẽ thấy có đề cập đến cách thức hoạt động của Force Inclusion, cũng như một số tên tham số và tên hàm:

Người dùng trước tiên sẽ gọi hàm sendUnsignedTransaction trên hợp đồng DelayedInbox, nếu Sequencer không ghi nhận trong khoảng 24 giờ, thì người dùng có thể gọi hàm forceInclusion trên hợp đồng SequencerInbox. Tuy nhiên, Arbitrum cũng không đính kèm liên kết đến hàm trong tài liệu chính thức, chỉ có thể tự xem mã hợp đồng để tìm hàm tương ứng.

Khi tìm thấy hàm sendUnsignedTransaction, bạn sẽ thấy rằng bạn phải tự điền giá trị nonce và giá trị maxFeePerGas. Là nonce của địa chỉ nào? Là maxFeePerGas của mạng nào? Làm thế nào để điền cho đúng? Không có tài liệu tham khảo, ngay cả Natpsec cũng không có. Sau đó, bạn sẽ thấy trong hợp đồng Arbitrum có một đống hàm trông giống nhau:

sendL1FundedUnsignedTransaction, sendUnsignedTransactionToFork, sendContractTransaction, sendL1FundedContractTransaction, cũng không có tài liệu nào cho bạn biết sự khác biệt giữa các hàm này, cách sử dụng, cách điền tham số, ngay cả Natpsec cũng không có.

Bạn thử nghiệm điền tham số và gửi giao dịch với tâm lý "thử xem sao", muốn tìm ra cách sử dụng đúng, nhưng phát hiện rằng tất cả các hàm này đều sẽ thực hiện AddressAliasing trên địa chỉ L1 của bạn, dẫn đến việc cuối cùng khi phát động giao dịch trên L2, người gửi hoàn toàn là một địa chỉ khác, vì vậy địa chỉ L2 của bạn không hề động đậy.

sendL2Message

Sau đó, tình cờ mở Google tìm kiếm, tôi mới phát hiện ra rằng Arbitrum có một thư viện hướng dẫn, trong đó có kịch bản mẫu về cách gửi giao dịch L2 từ L1 (cũng chính là ý nghĩa của Force Inclusion), và hàm được liệt kê hoàn toàn không phải là bất kỳ hàm nào đã đề cập ở trên, mà là một hàm gọi là sendL2Message, và tham số message cần phải là một giao dịch đã được ký bởi tài khoản L2?

Ai mà biết rằng "thông điệp gửi đến L2 thông qua Force Inclusion" lại là một "giao dịch L2 đã được ký"? Hơn nữa, không có tài liệu nào và Natspec giải thích khi nào sử dụng và cách sử dụng hàm này.

Kết luận: Việc tạo ra một giao dịch cưỡng bức trên Arbitrum khá rắc rối, khuyên bạn nên chạy theo hướng dẫn chính thức của Arbitrum SDK. Arbitrum không giống như các Rollup khác có tài liệu rõ ràng cho nhà phát triển và chú thích mã, nhiều hàm thiếu giải thích về mục đích và tham số, dẫn đến việc các nhà phát triển phải tốn nhiều thời gian hơn dự kiến để tích hợp và sử dụng. Tôi cũng đã hỏi người trong Arbitrum trên Discord, nhưng không nhận được câu trả lời thỏa đáng.

Khi hỏi trên Discord, người ta chỉ bảo tôi xem sendL2Message, không muốn giải thích chức năng của các hàm khác (thậm chí là hàm sendUnsignedTransaction được đề cập trong tài liệu Force Inclusion) là gì, cách sử dụng, khi nào sử dụng.

Cơ chế Force Inclusion của StarkNet

Rất tiếc, StarkNet hiện chưa có cơ chế Force Inclusion. Chỉ có hai bài viết trên diễn đàn chính thức thảo luận về Censorship và Force Inclusion.

Giao dịch không thể chứng minh thất bại

Nguyên nhân trên thực ra là do hệ thống chứng minh không kiến thức của StarkNet không thể chứng minh một giao dịch thất bại, vì vậy không thể cho phép Force Inclusion. Bởi vì nếu có ai đó cố tình (hoặc vô tình) Force Include một giao dịch thất bại, không thể được chứng minh, thì StarkNet sẽ bị kẹt lại: vì giao dịch đã bị cưỡng bức đưa vào, Prover sẽ phải chứng minh giao dịch thất bại đó, nhưng nó lại không thể chứng minh.

StarkNet dự kiến sẽ giới thiệu chức năng chứng minh giao dịch thất bại trong phiên bản v0.15.0, sau đó có thể thực hiện cơ chế Force Inclusion.

Cơ chế Force Inclusion của zkSync

Việc truyền thông điệp từ L1 sang L2 và cơ chế Force Inclusion của zkSync đều thông qua hàm requestL2Transaction của hợp đồng MailBox, người dùng chỉ định địa chỉ L2, calldata, số ETH kèm theo, giá trị L2GasLimit, v.v., requestL2Transaction sẽ kết hợp các tham số này thành một giao dịch L2, sau đó đưa vào hàng đợi ưu tiên (PriorityQueue), Sequencer sẽ trong quá trình đóng gói giao dịch gửi lên L1 (thông qua hàm commitBatches), sẽ chỉ định số lượng giao dịch từ hàng đợi ưu tiên cần được ghi nhận vào lịch sử giao dịch L2.

Cách thức Force Inclusion của zkSync tương tự như Optimism, đều sử dụng địa chỉ L2 của người khởi xướng (giống với địa chỉ L1) để gọi các hàm liên quan và điền thông tin (người được gọi, calldata, v.v.), chứ không giống như Arbitrum là điền một giao dịch L2 đã được ký; nhưng về thiết kế thì giống như Arbitrum, đều duy trì một hàng đợi Queue trên L1, và Sequencer sẽ lấy các giao dịch đang chờ xử lý do người dùng gửi từ Queue và ghi vào lịch sử giao dịch.

Nếu bạn gửi ETH qua cầu chính thức của zkSync, như giao dịch này, nó sẽ gọi hàm requestL2Transaction của hợp đồng MailBox, giao dịch L2 gửi ETH này sẽ được đưa vào hàng đợi ưu tiên và phát ra một sự kiện NewPriorityRequest. Vì hợp đồng mã hóa thông tin giao dịch L2 thành một chuỗi bytes nên khó đọc, nếu chuyển sang xem tham số của giao dịch L1, sẽ thấy tham số trong đó địa chỉ L2 của người nhận cũng chính là người khởi xướng giao dịch (vì là gửi cho chính mình), vì vậy sau một thời gian, khi giao dịch L2 này được Sequencer lấy ra từ hàng đợi ưu tiên và ghi vào lịch sử giao dịch, nó sẽ được chuyển đổi thành một giao dịch tự chuyển cho chính mình trên L2, và số tiền chuyển sẽ là số ETH mà người khởi xướng đã kèm theo trong giao dịch gửi ETH trên L1.

Trong giao dịch L1Deposit, người khởi xướng và người nhận đều là 0xeDc1…6909, số tiền là 0.03ETH, calldata là rỗng.

Trên L2 sẽ xuất hiện một giao dịch 0xeDc1…6909 tự chuyển cho chính mình, loại giao dịch (TxnType) là 255, tức là giao dịch hệ thống

Tiếp theo, tôi trực tiếp như trước đã thử nghiệm chức năng giao dịch cưỡng bức của OP, gọi hàm requestL2Transaction của zkSync, gửi một giao dịch tự chuyển: không kèm theo bất kỳ ETH nào, calldata chứa mã hex của chuỗi "force inclusion".

Sau đó, nó được chuyển đổi thành một giao dịch tự chuyển trên L2, dữ liệu trong calldata là chuỗi hex của "force inclusion": 0x666f72636520696e636c7573696f6e.

Khi Sequencer lấy giao dịch từ PriorityQueue và ghi vào lịch sử giao dịch, trên L2 sẽ chuyển đổi thành giao dịch L2 tương ứng

Thông qua hàm requestL2Transaction, người dùng có thể sử dụng tài khoản L1 giống như tài khoản L2 của mình, gửi thông tin trên L1, chỉ định người nhận L2, số ETH kèm theo và calldata. Nếu người dùng muốn gọi hợp đồng khác, kèm theo dữ liệu khác, thì cũng chỉ cần điền các tham số vào hàm requestL2Transaction.

Chưa có chức năng cho phép người dùng cưỡng bức ghi nhận

Mặc dù giao dịch L2 được đưa vào hàng đợi ưu tiên, sẽ tính toán thời gian chờ để giao dịch L2 này được Sequencer ghi nhận, nhưng hiện tại thiết kế của zkSync không có hàm Force Inclusion cho phép người dùng cưỡng bức thực hiện, tức là chỉ làm một nửa. Điều này có nghĩa là mặc dù có "thời gian chờ ghi nhận", nhưng thực tế vẫn là "xem Sequencer có muốn ghi nhận hay không": Sequencer có thể đợi đến khi hết thời gian mới ghi nhận, hoặc có thể hoàn toàn không ghi nhận bất kỳ giao dịch nào trong hàng đợi ưu tiên.

Trong tương lai, zkSync nên thêm các hàm liên quan, cho phép người dùng có thể cưỡng bức đưa giao dịch vào lịch sử giao dịch L2 khi thời gian ghi nhận đã hết nhưng vẫn chưa được Sequencer ghi nhận, như vậy mới thực sự là cơ chế Force Inclusion hiệu quả.

Tóm tắt

L1 dựa vào số lượng lớn các Validator để đảm bảo "tính an toàn" và "khả năng kháng kiểm duyệt" của mạng, trong khi Rollup chủ yếu được viết bởi một số ít hoặc thậm chí một Sequencer, khả năng kháng kiểm duyệt yếu hơn. Do đó, Rollup cần có cơ chế Force Inclusion để cho phép người dùng vượt qua Sequencer, ghi giao dịch vào lịch sử, tránh bị kiểm duyệt bởi Sequencer dẫn đến không thể sử dụng và không thể rút tiền khỏi Rollup.

Force Inclusion cho phép người dùng cưỡng bức ghi giao dịch vào lịch sử, nhưng trong thiết kế cần phải lựa chọn giữa "giao dịch có thể được chèn vào lịch sử ngay lập tức, có hiệu lực ngay lập tức" hay không. Nếu cho phép giao dịch có hiệu lực ngay lập tức, thì sẽ ảnh hưởng tiêu cực đến Sequencer, vì các giao dịch đang chờ được ghi nhận trên L2 có thể bị ảnh hưởng bởi các giao dịch cưỡng bức từ L1.

Do đó, hiện tại cơ chế Force Inclusion của Rollup đều sẽ cho phép các giao dịch được chèn vào L1 vào trạng thái chờ, và cho Sequencer một khoảng thời gian để phản ứng, để lựa chọn có ghi nhận các giao dịch đang chờ hay không.

zkSync và Arbitrum đều duy trì một hàng đợi Queue trên L1, để quản lý các giao dịch L2 mà người dùng gửi từ L1 hoặc thông điệp gửi đến L2. Arbitrum gọi là DelayedInbox; zkSync gọi là PriorityQueue.

Nhưng cách gửi giao dịch L2 của zkSync giống như Optimism, đều sử dụng địa chỉ L2 để gửi thông điệp lên L1, như vậy khi chuyển đổi thành giao dịch L2, người khởi xướng mới là địa chỉ L2 đó. Hàm gửi giao dịch L2 của Optimism được gọi là depositTransaction; zkSync gọi là requestL2Transaction. Trong khi đó, Arbitrum tạo ra một giao dịch L2 hoàn chỉnh và ký nó, sau đó gửi đi thông qua hàm sendL2Message, Arbitrum sẽ khôi phục người ký để làm người khởi xướng giao dịch L2.

StarkNet hiện chưa có cơ chế Force Inclusion; zkSync thì giống như đã làm một nửa cơ chế Force Inclusion, --- có PriorityQueue và mỗi giao dịch L2 trong hàng đợi đều có thời hạn ghi nhận, nhưng thời hạn này hiện tại chỉ mang tính chất trang trí, thực tế Sequencer có thể hoàn toàn không ghi nhận bất kỳ giao dịch nào trong PriorityQueue.