Giới thiệu về cơ chế Force Inclusion của Rollup

Tác giả gốc: NIC Lin
Nguồn gốc: trung bình
Mạnh mẽ lên. Bài viết này sẽ giới thiệu cơ chế chống kiểm duyệt giao dịch của Rollup - Force Inclusion, đồng thời sử dụng thiết kế và thực tiễn của một số Rollup nổi tiếng làm ví dụ.
Ảnh của Artur Tumasjan trên Bapt
Kiến thức tiên quyết:
Biết cách Rollup hoạt động và lý do Rollup cần tải giao dịch lên L1
Chống kiểm duyệt giao dịch
Khả năng chống kiểm duyệt (chống kiểm duyệt) của các giao dịch là rất quan trọng đối với một blockchain. Nếu một blockchain có thể thực hiện giao dịch cho bất kỳ người dùng kiểm duyệt nào thì blockchain này không khác gì máy chủ Web2. Khả năng chống kiểm duyệt giao dịch hiện tại của Ethereum xuất phát từ số lượng lớn người xác thực. Nếu Alice muốn xem xét các giao dịch của Bob và ngăn các giao dịch của anh ta được tải lên chuỗi, thì Alice sẽ phải cố gắng hối lộ mọi người xác thực trong mạng, nếu không cô ấy sẽ bị như vậy. rác rưởi. Toàn bộ mạng email tiếp tục gửi các giao dịch spam cao hơn giao dịch của Bob để lấp đầy các khối. Dù thế nào đi nữa, chi phí của cô ấy sẽ rất cao.
Lưu ý: Trong kiến ​​trúc PBS hiện tại của Ethereum, chi phí đánh giá thực sự đã giảm đáng kể. Bạn có thể tham khảo đánh giá của OFAC về tỷ lệ khối trong giao dịch Tornado Cash. Khả năng chống kiểm duyệt hiện tại phụ thuộc vào các cơ quan xác minh và chuyển tiếp độc lập bên ngoài OFAC và khu vực tài phán của chính phủ.
Nhưng còn Rollup thì sao? Rollup không yêu cầu số lượng lớn trình xác thực để đảm bảo tính bảo mật của nó. Ngoài ra, Rollup chỉ có vai trò tập trung (Trình sắp xếp chuỗi, được gọi là trình sắp xếp chuỗi hoặc trình sắp xếp chuỗi) đối với các khối hàng loạt và nó an toàn như L1. Nhưng khả năng chống bảo mật và kiểm duyệt là hai thứ khác nhau. Xây dựng một Rollup cũng an toàn như Ethereum, nhưng nó chỉ có Trình sắp xếp tập trung. Sau đó, Trình sắp xếp có thể xem xét bất kỳ giao dịch nào của người dùng nếu muốn.
Sequencer có thể từ chối nhận giao dịch của người dùng, khiến người dùng không thể sử dụng hoặc rời khỏi Rollup.
cơ chế đưa vào bắt buộc
Đồng thời, Rollup bắt buộc phải có nhiều trình xác thực như L1 để đảm bảo khả năng chống kiểm duyệt. Tốt hơn là sử dụng trực tiếp khả năng chống kiểm duyệt của L1: trình sắp xếp cũng nén dữ liệu giao dịch vào hợp đồng Rollup của L1. một chức năng trong hợp đồng Tổng hợp để giám sát người dùng. Bạn cũng có thể chèn các giao dịch vào sắp xếp. Phương pháp này được gọi là đưa vào bắt buộc. Miễn là Sequencer không thể xem xét "giao dịch L1" của người dùng được giám sát, nó không thể ngăn người dùng buộc chèn các giao dịch Rollup thông qua L1, đồng thời hoạt động và tính bảo mật của Rollup dựa trên khả năng chống kiểm duyệt của L1.
Trình sắp xếp thứ tự không thể xem lại các giao dịch L1 của người dùng trừ khi có chi phí rất phức tạp
Lưu ý: Việc đưa vào bắt buộc chỉ có thể thực hiện được nếu Bản tổng hợp được thiết kế. Người dùng chắc chắn có thể vượt qua L1 và chèn các giao dịch Tổng hợp một cách mạnh mẽ. Nếu Rollup không cung cấp cơ chế bắt buộc đưa vào thì người dùng chỉ có thể cầu nguyện rằng việc đánh giá Sequencer sẽ không tự giao dịch.
Giao dịch có hiệu lực ngay lập tức so với hiệu lực bị trì hoãn
Nếu chúng tôi cho phép các giao dịch được chèn thông qua Force Inclusion được ghi trực tiếp vào lịch sử giao dịch của Rollup (có hiệu lực ngay lập tức), thì trạng thái của Rollup sẽ được thay đổi ngay lập tức. Ví dụ: Bob đưa một cây bút thông qua cơ chế Force Inclusion "Anh ấy đã chuyển 1000 DAI. đến giao dịch "Carol", nếu giao dịch có hiệu lực ngay lập tức thì số dư của Bob ở trạng thái mới nhất sẽ ít hơn 1000 DAI và Carol sẽ nhiều hơn 1000 DAI (tất nhiên, tiền đề là số dư của Bob vượt quá 1000 DAI).
Nếu giao dịch của Bob có thể được ghi trực tiếp vào lịch sử giao dịch và có hiệu lực ngay lập tức thì trạng thái của Tổng hợp sẽ thay đổi ngay lập tức.
Nếu Trình sắp xếp thứ tự đang thu thập các giao dịch ngoài chuỗi tại thời điểm này và đợi cho đến khi giao dịch tiếp theo được gửi đến hợp đồng Tổng hợp, nó có thể bị ảnh hưởng bởi giao dịch mà Bob buộc phải chèn và có hiệu lực ngay lập tức. Ví dụ: Bob chỉ cần gửi trước một giao dịch thanh toán "anh ấy" chuyển 1000 DAI cho Alice" tới Sequencer. Sequencer tương đương với việc xác minh rằng không có vấn đề gì và hứa sẽ nhận thu nhập. Cả Alice và Bob đều có thể truy vấn Sequencer xem giao dịch sẽ được nhận và tính toán kết quả trạng thái mới nhất (Alice có thêm 1000 DAI và Bob có ít hơn 1000 DAI). Nhưng khi Sequencer phát hiện ra rằng Bob đã vội vàng chèn giao dịch, trạng thái thực hiện của các giao dịch trong tay nó đã thay đổi. Nó biết rằng giao dịch “Bob đã chuyển 1000 DAI cho Alice” đã trở thành một lỗi thực thi và Alice không thể thực hiện được. đạt được 1000 DAI.
Trình sắp xếp thứ tự nhận được giao dịch của Bob, vì vậy Alice tin rằng cô ấy sẽ nhận được 1000 DAI
Kết quả là Bob trực tiếp buộc phải nhận một giao dịch xung đột khác trên L1, khiến giao dịch trong tay Sequencer không được nhận và Alice không thể nhận được DAI.
Đây có thể không phải là trải nghiệm tốt cho người dùng, do đó, Rollup thường làm cho giao dịch bao gồm bắt buộc có hiệu lực ngay lập tức nhưng nâng cao giao dịch lên trạng thái "chuẩn bị". Trình sắp xếp chuỗi có thể chọn có thêm các giao dịch ở trạng thái "chuẩn bị" vào cuối lô khi giao dịch ngân sách được gửi hay không. Nếu Trình sắp xếp chuỗi không bao giờ muốn xử lý các trạng thái "chuẩn bị" này thì các giao dịch này sẽ được xử lý sau một thời gian. Sau một khoảng thời gian nhất định, nó có thể bị buộc phải đưa vào lịch sử giao dịch.
Bob muốn lừa Alice bằng cách ép giao dịch doanh thu nhưng thực tế giao dịch sẽ được xếp hàng trước
Trình sắp xếp chuỗi có thể tự quyết định thời điểm "đưa" các giao dịch đang chờ vào hàng đợi, do đó giao dịch từ Bob đến Alice DAI sẽ được thực hiện trước tiên.
Nếu Trình sắp xếp chuỗi không chờ các giao dịch trong hàng đợi, sau một khoảng thời gian nhất định, người dùng (hoặc bất kỳ ai) có thể tự ép doanh thu.
Trình sắp xếp chuỗi từ chối nhận giao dịch của Bob, vì vậy Bob xếp hàng giao dịch từ L1
Trình sắp xếp thứ tự vẫn có thể tiếp tục từ chối các giao dịch trong hàng đợi trong một thời gian
Tuy nhiên, Sequencer không thể từ chối các giao dịch đang chờ trong hàng đợi mãi mãi. Sau một thời gian, bất kỳ ai cũng có thể kích hoạt thu nhập bắt buộc. Tiếp theo, chúng tôi sẽ giới thiệu cách triển khai cơ chế ngăn chặn lực lượng của Rollup nổi tiếng hơn như Optimism, Arbitrum, StarkNet và zkSync. .
Cơ chế bao trùm quyền lực lạc quan
Đầu tiên, hãy giới thiệu quy trình Gửi tiền của Optimism. Khoản tiền gửi này không chỉ đề cập đến việc gửi tiền vào Optimism mà còn tương đương với các thông báo gửi tiền tổng quát hơn cho L2 vào L2. Sau khi nhận được tin nhắn mới gửi, nút L2 sẽ truyền tin nhắn và chuyển đổi nó thành giao dịch cổng L2 để thực hiện và truyền tin nhắn đến người nhận được chỉ định.
Tin nhắn người dùng gửi tiền từ L1 đến L2
Hợp đồng L1CrossDomainMessenger
Khi người dùng quyết định gửi mã thông báo ETH hoặc ERC-20 vào Optimism, anh ta sẽ tương tác (trên web) với hợp đồng L1StandardBridge trên L1, chỉ định số tiền cần gửi và địa chỉ nhận số tiền đó từ đâu, v.v. Sau đó, thông báo kết nối L1StandardBridge được chuyển đến hợp đồng L1CrossDomainMessenger của lớp tiếp theo. Hợp đồng này chủ yếu được sử dụng làm hợp đồng liên lạc chung giữa L1 ​​và L2. Sử dụng hợp đồng liên lạc chung này để liên lạc với L2StandardBridge trên L2 để quyết định ai có thể Bắt đầu bằng cách đúc tiền. mã thông báo từ L2 hoặc rút mã thông báo từ L1. Nếu nhà phát triển cần phát triển hợp đồng về khả năng tương tác và trạng thái đồng bộ hóa giữa L1 ​​và L2 thì anh ta có thể xây dựng hợp đồng đó trên L1CrossDomainMessenger.
Hợp đồng CrossChainMessenger nhắn tin của người dùng được chuyển từ L1 sang L2
Hợp đồng cổng thông tin lạc quan
Sau đó, hợp đồng L1CrossDomainMessenger sẽ gửi tin nhắn đến hợp đồng OptimismPortal cấp thấp nhất. Sau khi hợp đồng OptimismPortal được xử lý, nó sẽ đưa ra một sự kiện TransactionDeposited. Các tham số sự kiện bao gồm "người đã gửi tin nhắn", "người đã nhận được tin nhắn". ", và các tham số thực thi liên quan.
Sau đó, nút Optimism của L2 sẽ lắng nghe sự kiện TransactionDeposited do thỏa thuận OptimismPortal đưa ra và chuyển đổi các tham số trong sự kiện thành giao dịch ghi lại L2. Người khởi tạo giao dịch L2 này có thể là "người gửi tin nhắn" trong sự kiện TransactionDeposited. người gửi giao dịch Người nhận sẽ là "người nhận tin nhắn" trong sự kiện và các tham số thực thi khác cũng được thông số sự kiện truyền vào.
Nút L2 chèn sự kiện TransactionDeposited do OptimismPortal phát ra vào các giao dịch L2 được chú thích
Ví dụ: đây là giao dịch trong đó người dùng gửi 0,01 ETH thông qua hợp đồng L1StandardBridge. Thông báo này và ETH được truyền đến hợp đồng OptimismPortal (địa chỉ là 0xbEb5...06Ed). vào giao dịch L2 và người khởi tạo tin nhắn là hợp đồng L1CrossDomainMessenger; Người nhận là hợp đồng L2CrossDomainMessenger trên L2;
bắt buộc đưa vào
Khi người dùng muốn buộc giao dịch của mình thực hiện một cách lạc quan, anh ta không cần gửi tin nhắn từ L1 đến L2, vì vậy anh ta sẽ không sử dụng hợp đồng L1CrossDomainMessenger. Hiệu quả mà anh ta muốn đạt được là làm cho hóa đơn cụ thể "giao dịch anh ta gửi và thực hiện trên L2 từ địa chỉ L2 của anh ta" được thực hiện suôn sẻ, do đó anh ta sẽ tương tác trực tiếp với hợp đồng OptimismPortal và để địa chỉ L2 của anh ta gọi hợp đồng OptimismPortal, vì vậy rằng khi sự kiện TransactionDeposited được chuyển đổi thành giao dịch L2, "người khởi tạo giao dịch" sẽ là địa chỉ L2 của anh ấy", để có thể nhìn thấy lại giao dịch.
Trong giao dịch L2 được chuyển đổi từ sự kiện TransactionDeposited, người khởi tạo sẽ là chính Bob; người nhận là hợp đồng Uniswap và nó sẽ đi kèm với ETH được chỉ định, giống như chính Bob đã thực hiện giao dịch L2;
Sử dụng địa chỉ L2 để gọi hàm DepositTransaction được ký bởi OptimismPortal và nhớ điền từng thông số của giao dịch L2.
Tôi đã thực hiện một giao dịch bắt buộc bao gồm đơn giản: chuyển tiền cho chính tôi theo địa chỉ L2 của tôi (0xeDc1...6909) và đính kèm tin nhắn văn bản "bắt buộc bao gồm". Đây là giao dịch L1 trong đó tôi thực thi chức năng DepositTransaction thông qua hợp đồng OptimismPortal. Bạn có thể thấy rằng trong sự kiện TransactionDeposited được phát ra, cả từ và đến đều là chính tôi và giá trị trong trường opaqueData còn lại (0000000000000000000 00 00000000000000000000000000000000000000000000000000000015BE000000000000C35000666F72636520696E636C7573696F6E) Số lượng được mã hóa ? "Người đó mang bao nhiêu ETH", "Người khởi tạo giao dịch L2 phải mang ETH đến người nhận L2", "Giới hạn gas giao dịch L2" và "Dữ liệu cho người nhận L2" và các thông tin khác.
Sự kiện ký gửi giao dịch được phát ra bởi giao dịch L1
Sau khi diễn giải các giá trị số của một số thông tin trong opaqueData này, bạn sẽ nhận được:
"Người gọi DepositTransaction gắn bao nhiêu ETH": 0 vì tôi không muốn nạp ETH từ L1 lên L2
"Người khởi tạo giao dịch L2 cần gửi bao nhiêu ETH cho người nhận L2": 5566 (wei), vì tôi muốn chuyển tiền cho chính mình
"Giới hạn gas giao dịch L2": 50.000
"Dữ liệu cho bộ thu L2": 0x666f72636520696e636c7573696f6e, xóa "bắt buộc đưa vào" mã hóa thập lục phân của chuỗi này
Không lâu sau, giao dịch L2 được chuyển đổi xuất hiện: ghi lại giao dịch L2 tôi đã chuyển tiền cho chính mình, số tiền là 5566 và dữ liệu là chuỗi "bắt buộc đưa vào". Và bạn có thể nhận thấy rằng Loại Txn (loại giao dịch) trong Thuộc tính khác ở dòng thứ hai đến dòng cuối cùng trong hình là giao dịch hệ thống 126 (Hệ thống), có nghĩa là giao dịch không phải do tôi thực hiện trong L2 mà đã được chuyển đổi từ sự kiện L1TransactionDeposited.
Chuyển đổi hoàn thành giao dịch L2
Nếu người dùng muốn gọi các hợp đồng khác với dữ liệu khác, điều tương tự cũng được thực hiện bằng cách điền từng tham số vào ký tự DepositTransaction. Chỉ cần nhớ sử dụng địa chỉ L2 để thực thi trên L1, sao cho người khởi tạo giao dịch L2. sẽ là địa chỉ L2.
cửa sổ tuần tự
Nút Optimism L2 được đề cập trước đó chuyển đổi sự kiện TransactionDeposited thành giao dịch L2 Trên thực tế, nút Optimism này đề cập đến nút Sequencer, vì vậy chỉ có Sequencer mới có thể quyết định thời điểm chuyển đổi nó thành giao dịch L2. . Khi nghe sự kiện TransactionDeposited, Trình sắp xếp chuỗi có thể không nhất thiết phải chuyển đổi sự kiện thành giao dịch L2 ngay lập tức nhưng nó có thể quyết định chuyển đổi sự kiện đó trong một khoảng thời gian. Khoảng thời gian này được gọi là cửa sổ trình sắp xếp chuỗi trên Optimism. mainnet hiện tại là 24 giờ. Sau đó, khi người dùng bắt đầu gửi tiền từ L1 hoặc nhận được lời nhắc hoặc buộc phải thực hiện giao dịch nạp tiền, trường hợp xấu nhất sẽ là nó sẽ chính thức được đưa vào lịch sử giao dịch L2 24 giờ sau đó, nhưng ít nhất điều này cũng tốt hơn giao dịch không bao giờ có thể giúp được.
Cơ chế bao gồm bắt buộc của Arbitrum
Lạc quan hơn, hoạt động gửi tiền của L1 sẽ phát ra sự kiện TransactionDeposited và việc còn lại là đợi Sequencer nhận hoạt động gửi tiền; nhưng trong bất kỳ hoạt động nào của L1 (gửi tiền hoặc gửi tin nhắn đến L2, v.v.) sẽ được lưu trữ trong hàng đợi được L1 đồng ý, thay vì chỉ phát ra các sự kiện. Trình sắp xếp chuỗi sẽ có một khoảng thời gian để thêm các hoạt động L1 trong hàng đợi này vào lịch sử giao dịch. Nếu trình sắp xếp được sử dụng hết khi hết thời gian, nó có thể được hoàn thành mà không cần ai phải thay thế trình sắp xếp.
Trọng tài sẽ duy trì một hàng đợi trong hợp đồng L1. Nếu Trình sắp xếp chuỗi không chủ động nhận các giao dịch trong hàng đợi thì khi hết thời gian, bất kỳ ai cũng có thể buộc các giao dịch trong hàng đợi được nhập vào lịch sử giao dịch.
Tất cả các hoạt động L1 đều là hợp đồng Hộp thư đến bị trì hoãn. Đúng như tên gọi, các hoạt động ở đây sẽ bị trì hoãn và hết hạn; hợp đồng còn lại là Hộp thư đến tuần tự, là giao diện để tải các giao dịch L2 lên Sequencer. Các giao dịch do Sequencer tải lên sẽ được ghi trực tiếp vào lịch sử giao dịch. Ngoài ra, khi Sequencer tải lên, bạn có thể chọn số lượng thao tác L1 cần lấy từ Hộp thư đến bị trì hoãn và ghi chúng vào lịch sử giao dịch cùng nhau để các thao tác L1 này có thể thực hiện. tác dụng.
SequencerInbox chứa lịch sử giao dịch Nói chung, chỉ Sequencer mới có thể trực tiếp ghi các giao dịch mới; DelayedInbox chứa các giao dịch đang chờ nhận.
Khi Sequencer ghi một giao dịch mới, nó có thể bắt đầu một giao dịch từ DelayedInbox và ghi nó cùng nhau.
Thiết kế phức tạp và tài liệu ấn tượng
Nếu độc giả tham khảo trực tiếp chương chính thức của Arbitrum về Sequencer và Force Inclusion, sẽ thấy Force Inclusion được đề cập ở đó tương thích như thế nào, cũng như một số tên tham số và tên hàm: Đầu tiên người dùng vào Hộp thư đến để đặt lịch hẹn gọi hàm sendUnsignedTransaction Nếu Sequencer không có trong cuộc hẹn Thu nhập trong vòng 24 giờ, thì người dùng có thể gọi hàm ForceInclusion được ký bởi Sequencer Inbox. Bằng cách này, ngay cả liên kết cũng không được đưa vào và bạn chỉ có thể tự mình đồng ý về chức năng tương ứng trong mã chương trình.
Khi tìm thấy hàm sendUnsignedTransaction, bạn thấy rằng bạn thực sự cần phải tự điền giá trị nonce và giá trị maxFeePerGas. Địa chỉ nào là nonce? Giá trị maxFeePerGas của mạng nào? Cách tốt nhất để điền vào nó là gì? Không có tài liệu nào, thậm chí không có của Natpsec. Sau đó, bạn cũng tìm thấy một hàm tích lũy giao diện: 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 và cách điền thông số, thậm chí cả Natpsec.
Bạn cân nhắc tất cả và thử trước khi điền các tham số và gửi giao dịch. Bạn muốn thử và sai để xem liệu bạn có thể tìm ra phương pháp chính xác hay không, nhưng bạn nhận thấy rằng tất cả các chức năng này sẽ sử dụng địa chỉ L1 của bạn làm địa chỉ. bí danh địa chỉ, dẫn đến kết quả cuối cùng. Người khởi tạo giao dịch trên L2 về cơ bản là một địa chỉ khác, vì vậy địa chỉ L2 của bạn hoàn toàn không di chuyển.
Gửi tin nhắn L2
Sau đó, tôi vô tình nhấp vào một liên kết trên trang tìm kiếm Google và phát hiện ra rằng Arbitrum ban đầu có một thư viện hướng dẫn trong đó có một đoạn script trình bày cách gửi giao dịch L2 từ L1 (hay còn gọi là Force Inclusion nghĩa là gì), và chức năng của nó hoàn toàn đầy đủ. khác với cái được đề cập ở trên. Bất kỳ cái nào trong số chúng chỉ là một hàm có tên sendL2Message và tham số tin nhắn thực sự là một giao dịch Arbitrum L2 đã ký? ? ? Ai có thể biết rằng "gửi tin nhắn L2" thực sự có nghĩa là "giao dịch L2 đã ký"? ? Và một lần nữa, không có tài liệu hoặc Natspec nào giải thích thời điểm và cách sử dụng chức năng này.
Kết luận: Thật rắc rối khi tạo giao dịch thu nhập bắt buộc của Arbitrum theo cách thủ công. Bạn nên làm theo hướng dẫn chính thức và chạy SDK Arbitrum. Không giống như các Rollups khác, Arbitrum có tài liệu hướng dẫn rõ ràng dành cho nhà phát triển và ghi chú mã dự án. Mục đích và thông số của nhiều chức năng thiếu sự giải thích, khiến các nhà phát triển phải mất nhiều thời gian hơn dự kiến ​​để truy cập và sử dụng. Tôi cũng đã hỏi mọi người ở Arbitrum về Arbitrum Discord nhưng không nhận được câu trả lời thỏa đáng.
Lưu ý: Khi tôi hỏi trên Discord, bên kia chỉ yêu cầu tôi nghe sendL2Message. Không cần phải giải thích các chức năng khác (kể cả sendUnsignedTransaction được đề cập trong tệp bao gồm bắt buộc) được sử dụng để làm gì, sử dụng chúng như thế nào và khi nào nên sử dụng chúng. sử dụng chúng.
Thật không may, StarkNet hiện không thực thi việc đưa vào. Chỉ có hai bài viết trên diễn đàn chính thức thảo luận về cơ chế kiểm duyệt và đưa vào bắt buộc.
Không thể chứng minh giao dịch thất bại
Lý do là hệ thống chứng minh không có kiến ​​thức của StarkNet không thể chứng minh các giao dịch không được ghi lại nên không thể cho phép ghi có bắt buộc. Bởi vì nếu ai đó cố ý (hoặc vô ý) buộc nhập giao dịch thất bại và không thể chứng minh được thì StarkNet sẽ bị kẹt trực tiếp: vì sau khi giao dịch bị ép buộc nhập, Prover phải chứng minh giao dịch thất bại, nhưng không có cách nào để chứng minh. .
StarkNet dự kiến ​​​​sẽ giới thiệu chức năng chứng minh các giao dịch không thành công trong phiên bản v0.15.0, sau đó có thể triển khai thêm cơ chế đưa vào bắt buộc.
Cơ chế bao gồm bắt buộc của zkSync
Cơ chế chuyển thông báo L1->L2 và cơ chế đưa thông báo bắt buộc của zkSync đều được thực hiện thông qua chức năng requestL2Transaction của hợp đồng MailBox. Người dùng chỉ định địa chỉ L2 sẽ được gọi, dữ liệu cuộc gọi, lượng ETH mang theo, giá trị Giới hạn Gas L2, v.v. , và phân chia các tham số của requestL2Transaction. Được kết hợp thành một giao dịch L2 và sau đó được mô phỏng trong Hàng đợi ưu tiên, Trình sắp xếp thứ tự sẽ chỉ định số lượng giao dịch được lấy ra khỏi Hàng đợi ưu tiên và nhận cùng nhau khi bản sao lưu giao dịch được tải lên L1 (chức năng commitBatches) .
zkSync rất giống với Optimistic về giao diện bao gồm bắt buộc. Cả hai đều sử dụng địa chỉ L2 của người dùng để gọi và điền dữ liệu liên quan (callee, dữ liệu cuộc gọi, v.v.), thay vì điền vào giao dịch L2 đã ký như Arbitrum; về mặt thiết kế, các giao dịch giống như Arbitrum trong việc duy trì hàng đợi các thực thể trong L1 và Trình sắp xếp chuỗi lấy các giao dịch từ hàng đợi và ghi chúng vào lịch sử giao dịch.
Người dùng chèn các giao dịch L2 vào hàng đợi ưu tiên thông qua requestL2Transaction và Trình sắp xếp chuỗi có thể giao tiếp với giao dịch từ hàng đợi ưu tiên khi thực hiệnBatches.
Nếu bạn nạp ETH thông qua cầu nối chính thức của zkSync, tương đương với giao dịch tại thời điểm này, nó sẽ gọi hàm requestL2Transaction của hợp đồng MailBox. Nó sẽ giữ ETH đã nạp lại trong hàng đợi ưu tiên giao dịch L2 và đưa ra sự kiện NewPriorityRequest. Vì hợp đồng mã hóa dữ liệu giao dịch L2 thành một chuỗi byte nên không dễ đọc nếu nhìn vào các tham số của giao dịch L1, bạn sẽ thấy rằng người nhận L2 trong các tham số cũng là người khởi tạo giao dịch. giao dịch vì (đó là Gửi tiền cho chính bạn), vì vậy Sau một thời gian, khi giao dịch L2 của sàn giao dịch được trình sắp xếp thứ tự đưa ra khỏi hàng ưu tiên và được đưa vào lịch sử giao dịch, nó sẽ được chuyển đổi trên L2 thành giao dịch ghi lại giao dịch chuyển khoản cho chính nó và số tiền chuyển là của người khởi tạo giao dịch trong L1. Gửi số tiền ETH do sàn giao dịch ETH mang lại.
Trong giao dịch nạp tiền L1, người khởi tạo và người nhận giao dịch đều là 0xeDc1…6909, số tiền là 0,03 ETH và dữ liệu cuộc gọi trống.
Kế toán 0xeDc1…6909 sẽ xuất hiện trên L2, giao dịch mà bạn chuyển cho chính mình. Loại giao dịch (Txn Type) là 255, là giao dịch hệ thống.
Tiếp theo, tôi gọi trực tiếp thư requestL2Transaction theo tập lệnh và gửi giao dịch ghi lại cuộc gọi cho chính tôi: không có ETH, dữ liệu cuộc gọi bao gồm mã hóa thập lục phân của chuỗi "bắt buộc đưa vào". Công thức tiếp theo được chuyển đổi thành giao dịch trên L2 ghi lại cuộc gọi của chính nó. Dữ liệu cuộc gọi chứa chuỗi "bắt buộc đưa vào": 0x666f72636520696e636c7573696f6e.
Khi trình sắp xếp thứ tự đưa giao dịch ra khỏi hàng ưu tiên và ghi nó vào lịch sử giao dịch, nó có thể được chuyển đổi thành giao dịch L2 tương ứng trên L2
Thông qua chức năng requestL2Transaction, người dùng có thể yêu cầu giao dịch L2 trên L1 với địa chỉ L2, chỉ định người nhận L2, số lượng ETH mang theo và dữ liệu cuộc gọi. Nếu người dùng muốn gọi các hợp đồng khác với dữ liệu khác, họ cũng cần điền từng tham số vào hàm requestL2Transaction. Chỉ cần nhớ sử dụng địa chỉ L2 để thực thi trên L1, để người khởi tạo giao dịch L2 sẽ là L2. Địa chỉ. .
Không có chức năng cho phép người dùng ép thu nhập
Mặc dù việc đặt các giao dịch L2 vào hàng ưu tiên sẽ tự động tính toán khoảng thời gian để Bộ sắp xếp chuỗi thu thập các giao dịch L2, nhưng thiết kế zkSync hiện tại không bao gồm các chức năng liên quan bắt buộc mà người dùng có thể tự thực hiện, tương đương với một nửa bộ. Vì vậy, mặc dù có “thời hạn hiệu lực của doanh thu” nhưng trên thực tế nó vẫn phụ thuộc vào việc Sequencer có muốn nhận doanh thu hay không: Sequencer có thể đợi đến khi chuyển đổi để nhận doanh thu hoặc không bao giờ có thể nhận bất kỳ giao dịch nào trong hàng đợi ưu tiên. Trong tương lai, zkSync nên bổ sung thêm các chức năng liên quan để người dùng có thể buộc thu nhập khi thu nhập đã qua nhưng chưa được Sequencer nhận. Đây là một cơ chế bắt buộc thực sự hiệu quả.
Tóm tắt
L1 dựa vào một nhóm lớn người để đảm bảo "bảo mật" và "khả năng chống kiểm duyệt" của Internet, trong khi Rollup dựa vào "khả năng chống kiểm duyệt của L1" để có được "bảo mật tương tự như L1", nhưng không bao gồm khả năng chống kiểm duyệt của Rollup. khả năng
Ngược lại, vì Rollup sử dụng một số lượng nhỏ hoặc thậm chí một Sequencer duy nhất để ghi các giao dịch nên khả năng chống kiểm duyệt của nó thậm chí còn yếu hơn. Do đó, Rollup cần có cơ chế Force Inclusion để cho phép người dùng bỏ qua Sequencer và ghi các giao dịch vào lịch sử để tránh bị Sequencer xem xét và không thể sử dụng hoặc rời khỏi Rollup.
Việc đưa vào bắt buộc cho phép người dùng buộc các giao dịch được ghi vào lịch sử, nhưng trong thiết kế, họ cần đưa ra lựa chọn về việc liệu giao dịch có thể được chèn ngay vào lịch sử và có hiệu lực ngay lập tức hay không. Nếu các giao dịch được phép có hiệu lực ngay lập tức sẽ gây rắc rối cho người sắp xếp thứ tự và khó khăn trong trải nghiệm người dùng, vì các giao dịch chờ nhận trên L2 có thể bị ảnh hưởng bởi các giao dịch bị L1 buộc phải nhận
Do đó, cơ chế bao gồm bắt buộc hiện tại của Rollup trước tiên sẽ đưa các giao dịch được chèn trên L1 vào trạng thái chờ và cho Trình sắp xếp chuỗi một khoảng thời gian để phản ứng và chọn xem có bao gồm các giao dịch chờ này hay không.
Cả zkSync và Arbitrum đều duy trì hàng đợi thực thể trong L1 để quản lý các giao dịch L2 do người dùng gửi từ L1 hoặc tin nhắn đến L2. Arbitrum gọi đó là hộp thư đến bị trì hoãn, zkSync gọi đó là hàng đợi ưu tiên;
Tuy nhiên, cách zkSync gửi giao dịch L2 tương tự như Optimism. Chúng được gửi đến L1 bằng địa chỉ L2, do đó, địa chỉ khởi tạo giao dịch L2 sẽ là địa chỉ L2. Chức năng gửi giao dịch L2 của Optimism được gọi là DepositTransaction; zkSync được gọi là requestL2Transaction. Arbitrum tạo một giao dịch L2 đã hoàn thành và ký nó, sau đó gửi nó qua thư sendL2Message. Arbitrum sẽ khôi phục người ký thông qua chữ ký trên L2 với tư cách là người khởi tạo giao dịch L2.
StarkNet hiện không có cơ chế bao gồm bắt buộc; zkSync đã triển khai một nửa bộ bao gồm bắt buộc - có hàng đợi ưu tiên và các giao dịch L2 trong mỗi hàng đợi có thời hạn hiệu lực thu nhập, nhưng trên thực tế, thời hạn hiệu lực này chỉ mang tính chất trang trí. , Trình sắp xếp chuỗi có thể chọn Không còn nhận bất kỳ giao dịch L2 nào trong hàng đợi ưu tiên nữa