Mới hôm qua, một sự việc đã xảy ra khiến vô số người bị sốc: Linea, lớp Ethereum thứ hai do công ty mẹ Consensys của Metamask ra mắt, đã chủ động đóng cửa. Chính thức cho biết mục đích của việc này là để giảm tác động của vụ hacker Velocore. Và điều này không thể không nhắc nhở mọi người về việc đóng cửa Chuỗi BSC (Chuỗi BNB) trước đó dưới sự điều phối chính thức nhằm giảm tổn thất do các cuộc tấn công hacker . Bất cứ khi nào mọi người nói về vấn đề này, họ sẽ nghi ngờ giá trị phi tập trung mà Web3 ủng hộ.
Tất nhiên, nguyên nhân cốt lõi của những sự cố nêu trên nằm nhiều hơn ở hoàn thiện của bản thân cơ sở hạ tầng, tức là thiếu phi tập trung : nếu một Chuỗi được phi tập trung đầy đủ thì nó không nên dừng lại ở việc đánh rơi chiếc mũ. Do cấu trúc độc đáo của lớp thứ hai của Ethereum, hầu hết Layer2 đều dựa vào Trình sắp xếp tập trung . Mặc dù ngày càng có nhiều tranh luận về sắp xếp phi tập trung trong những năm gần đây, nhưng khi xem xét mục đích của lớp thứ hai và cấu trúc của nó, chúng tôi khó có thể tin được. Có thể cho rằng rằng bộ sắp xếp Layer2 rất có thể sẽ không được phi tập trung nhiều và cuối cùng có thể không được phi tập trung như Chuỗi BSC. Nếu thực tế là như vậy thì chúng ta nên làm gì?
Trên thực tế, đối với lớp thứ hai, tác hại trực tiếp nhất do phi tập trung sắp xếp nằm ở hoạt động và phản kháng kiểm duyệt của nó. Nếu chỉ có một số thực thể (Trình tự sắp xếp) xử lý các giao dịch thì nó có quyền tuyệt đối về việc có phục vụ bạn hay không: nó có thể từ chối bạn nếu muốn và bạn có thể không có lựa chọn nào khác. Làm thế nào để giải quyết vấn đề chống kiểm duyệt của Layer2 rõ ràng là một chủ đề quan trọng.
Trong vài năm qua, các lớp thứ hai chính Ethereum đã đề xuất nhiều giải pháp khác nhau cho vấn đề chống kiểm duyệt, chẳng hạn như Loopring và Degate, chức năng rút tiền và thoát cưỡng bức của StarkEx, Arbitrum và Chức năng bao gồm lực lượng khác của OP Rollup, phương pháp này có thể tạo kiểm tra và số dư trên Bộ sắp xếp theo các điều kiện nhất định để ngăn nó từ chối bất kỳ yêu cầu giao dịch nào của người dùng mà không có lý do.
Trong bài viết hôm nay, NIC Lin từ Hiệp hội Ethereum Đài Bắc đưa ra tài khoản của riêng mình, đích thân thử nghiệm các chức năng giao dịch chống kiểm duyệt của bốn Rollups chính thống và phân tích sâu sắc thiết kế cơ chế của Force Inclusion từ các khía cạnh như quy trình làm việc và phương pháp vận hành, đó là rất quan trọng đối với Ethereum và các nhà đầu tư lớn với tài sản khổng lồ.
Đánh giá giao dịch và bắt buộc đưa vào
Khả năng chống kiểm duyệt giao dịch (Censorship Resistance) rất quan trọng đối với một blockchain. Nếu blockchain có thể tùy ý xem xét và từ chối các giao dịch do người dùng thực hiện thì nó sẽ không khác gì một máy chủ Web2. Khả năng chống kiểm duyệt giao dịch hiện tại Ethereum xuất phát từ số lượng lớn Người xác thực. Nếu ai đó 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, họ phải cố gắng hối lộ hầu hết Người xác thực trong mạng hoặc spam toàn bộ. mạng liên tục gửi các giao dịch rác với phí xử lý cao hơn Bob để chiếm không gian 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í xem xét các giao dịch sẽ giảm đi rất nhiều . Bạn có thể tham khảo tỷ lệ các khối hợp tác với OFAC để xem xét các 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 an ninh. Ngay cả khi Rollup chỉ có một nhân vật tập trung (Trình sắp xếp chuỗi) để tạo các khối, nó 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 điều khác nhau. Ngay cả khi Rollup an toàn như Ethereum, chỉ với một Trình sắp xếp tập trung, bất kỳ giao dịch nào của người dùng đều có thể bị kiểm duyệt.
Sequencer có thể từ chối xử lý giao dịch của người dùng, khiến tiền của người dùng bị giữ lại và không thể rời khỏi Rollup.
Cơ chế bao gồm lực lượng
Thay vì yêu cầu Rollup phải có lượng lớn Trình sắp xếp chuỗi phi tập trung, tốt hơn là bạn nên sử dụng trực tiếp khả năng chống kiểm duyệt của L1:
Ban đầu, Sequencer sẽ đóng gói dữ liệu giao dịch và gửi nó đến hợp đồng L1 Rollup. Tốt hơn là nên thêm một thiết kế vào hợp đồng để người dùng có thể tự chèn các giao dịch vào hợp đồng Rollup. Cơ chế này được gọi là "Buộc bao gồm". Miễn là Sequencer không thể kiểm duyệt người dùng ở cấp độ L1, nó không thể ngăn người dùng buộc phải chèn giao dịch ở cấp độ L1. Bằng cách này, Rollup có thể kế thừa khả năng chống kiểm duyệt của L1.
Trình sắp xếp chuỗi không thể xem lại các giao dịch L1 của người dùng mà không phải trả giá chi phí cao
Các giao dịch bắt buộc sẽ có hiệu lực như thế nào?
Nếu các giao dịch được phép ghi trực tiếp vào hợp đồng Rollup thông qua Force Inclusion (nghĩa là có hiệu lực ngay lập tức), trạng thái của Rollup sẽ thay đổi ngay lập tức. Ví dụ: Bob chèn một giao dịch "chuyển 1000 Dai cho Carol" thông qua Force Inclusion. Nếu giao dịch có hiệu lực ngay lập tức, số dư của Bob ở trạng thái mới nhất sẽ ít hơn 1.000 Dai và số dư của Carol sẽ nhiều hơn 1.000 Dai.
Nếu Force Inclusion có thể trực tiếp ghi giao dịch vào hợp đồng Tổng hợp 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 Trình sắp xếp chuỗi cũng đang thu thập các giao dịch ngoài Chuỗi tại thời điểm này và gửi lô giao dịch tiếp theo đến hợp đồng Tổng hợp, thì nó có thể bị ảnh hưởng bởi các giao dịch mà Bob buộc phải chèn và có hiệu lực ngay lập tức. Phải tránh loại vấn đề này càng nhiều càng tốt, vì vậy Rollup thường không làm cho giao dịch Force Inclusion có hiệu lực ngay lập tức. Thay vào đó, trước tiên, nó cho phép người dùng chèn giao dịch vào hàng đợi trên L1 và vào trạng thái "chuẩn bị". .
Khi Sequencer đóng gói các giao dịch ngoài Chuỗi và gửi chúng đến hợp đồng Tổng hợp, nó sẽ chọn có chèn các giao dịch nói trên vào chuỗi giao dịch hay không. Nếu Sequencer bỏ qua các giao dịch này ở trạng thái "chuẩn bị", sau khi khoảng thời gian cửa sổ kết thúc, người dùng. có thể buộc các giao dịch này chèn vào hợp đồng Rollup.
Trình sắp xếp thứ tự có thể quyết định thời điểm "thu nhập ngẫu nhiên" các giao dịch đang chờ trong hàng đợi
Trình sắp xếp chuỗi vẫn có thể từ chối xử lý các giao dịch trong hàng chờ.
Nếu Trình sắp xếp chuỗi từ chối trong một thời gian dài, sau một khoảng thời gian, bất kỳ ai cũng có thể buộc giao dịch vào hợp đồng Tổng hợp thông qua chức năng Bắt buộc bao gồm.
Tiếp theo, chúng tôi sẽ giới thiệu thứ tự triển khai cơ chế Force Inclusion của bốn Rollup nổi tiếng, bao gồm Optimism, Arbitrum, StarkNet và zkSync.
Cơ Optimism bao gồm lực lượng lạc quan
Đầu tiên, chúng tôi sẽ 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 bao gồm "gửi thông tin do người dùng gửi đến L2" đến L2. Sau khi nhận được tin nhắn mới gửi, nút L2 sẽ chuyển đổi tin nhắn thành giao dịch L2 để thực hiện và gửi đến người nhận tin nhắn được chỉ định.
Tin nhắn của người dùng từ Khoản tiền gửi L1 đến hợp đồng L1CrossDomainMessenger
Khi người dùng muốn gửi token ETH hoặc ERC-20 vào Optimism, anh ta sẽ tương tác với hợp đồng L1StandardBridge trên L1 thông qua trang web giao diện người dùng, chỉ định số tiền cần gửi và địa chỉ L2 nào để nhận tài sản này.
Hợp đồng L1StandardBridge sẽ truyền thông điệp đến hợp đồng L1CrossDomainMessenger cấp tiếp theo. Hợp đồng này chủ đúc được sử token như một thành phần để liên lạc lẫn nhau giữa L1 và L2 . trong L2 hoặc ai có thể mở 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ộ hóa trạng thái giữa L1 và L2 thì anh ta có thể xây dựng nó trên hợp đồng L1CrossDomainMessenger.
Tin nhắn của người dùng được chuyển từ L1 đến L2 thông qua hợp đồng CrossDomainMessenger
Lưu ý: Trong một số hình ảnh trong bài viết này, CrossDomainMessager được viết là CrossChainMessager
Hợp đồng cổng thông tin lạc quan
Hợp đồng L1CrossDomainMessenger sau đó sẽ gửi tin nhắn đến hợp đồng OptimismPortal cấp dưới cùng. Sau khi xử lý, hợp đồng OptimismPortal sẽ đưa ra một sự kiện có tên là TransactionDeposited . Các tham số bao gồm "người đã gửi tin nhắn", "người đã nhận được tin nhắn". và các thông số thực thi liên quan.
Sau đó , nút L2 Optimism sẽ lắng nghe sự kiện Gửi tiền giao dịch do hợp đồng OptimismPortal đưa ra và chuyển đổi các tham số trong sự kiện thành giao dịch L2 . Người khởi tạo giao dịch này sẽ là "người gửi tin nhắn" được chỉ định trong tham số sự kiện Gửi tiền giao dịch. người nhận giao dịch là "người nhận tin nhắn" trong các tham số sự kiện và các tham số giao dịch khác cũng được bắt nguồn từ các tham số trong các sự kiện trên.
Nút L2 sẽ chuyển đổi tham số sự kiện Ký gửi giao dịch của OptimismPortalemit thành giao dịch L2
Ví dụ: đây là giao dịch trong đó người dùng gửi 0,01ETH 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), sau đó được chuyển đổi thành L2. giao dịch vài phút sau:
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; nội dung tin nhắn là L1StandardBridge đã nhận được khoản tiền gửi 0,01ETH của BoB. Sau đó, một số quy trình sẽ được kích hoạt, chẳng hạn như phát hành thêm 0,01 ETH cho L2StandardBridge, sau đó sẽ được chuyển cho Bob.
Làm thế nào để kích hoạt nó cụ thể
Khi bạn muốn buộc một giao dịch vào hợp đồng Rollup của Optimism, hiệu quả bạn muốn đạt được là cho phép "giao dịch được bắt đầu và thực hiện trên L2 từ địa chỉ L2 của bạn" được thực hiện suôn sẻ. Lúc này , bạn nên sử dụng The của mình. Địa chỉ L2 gửi thông báo 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 với định dạng địa chỉ L1. Bạn có thể gọi trực tiếp hợp đồng trên bằng tài khoản L1 có cùng địa chỉ như tài khoản L2 ).
"Người khởi tạo" giao dịch L2 được chuyển đổi bởi sự kiện Ký gửi giao dịch do hợp đồng thực hiện sẽ là tài khoản L2 của bạn. Tại thời điểm này, định dạng giao dịch nhất quán với giao dịch L2 thông thường.
Trong giao dịch L2 được chuyển đổi từ sự kiện Gửi tiền giao dịch, 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.
Nếu muốn gọi hàm Force Inclusion của Optimism , bạn cần gọi trực tiếp hàm DepositTransaction của hợp đồng OptimismPortal và điền các tham số của giao dịch bạn muốn thực hiện trong L2.
Tôi đã thực hiện một thử nghiệm Force Inclusion đơn giản Giao dịch này muốn thực hiện một điều: sử dụng địa chỉ của tôi để tự chuyển trên L2 (0xeDc1...6909) và đính kèm tin nhắn văn bản "bắt buộc đưa vào".
Đây là giao dịch L1 trong đó tôi thực hiện chức năng DepositTransaction thông qua hợp đồng OptimismPortal. Bạn có thể thấy rằng trong sự kiện Đã gửi giao dịch mà nó gửi, cả từ và đến đều là chính tôi.
Các giá trị trong cột Data mờ còn lại mã hóa “bao nhiêu ETH đi kèm với người gọi hàm Giao dịch gửi tiền”, “người khởi tạo giao dịch L2 muốn gửi bao nhiêu ETH cho người nhận”, “Giao dịch L2 GasLimit” và “ tới Dữ liệu của Người nhận L2" và các thông tin khác.
Sau khi giải mã các thông tin trên, bạn sẽ nhận được:
"Người gọi Giao dịch gửi tiền đã đính kèm bao nhiêu ETH": 0, vì tôi không gửi ETH từ L1 đến L2;
"Người khởi tạo giao dịch L2 nên gửi bao nhiêu ETH cho người nhận" : 5566 (wei)
"GasLimit cho giao dịch L2" : 50000
"Dữ liệu cho bộ thu L2": 0x666f72636520696e636c7573696f6e, là mã hóa thập lục phân của chuỗi "bắt buộc đưa vào"
Không lâu sau, giao dịch L2 được chuyển đổi xuất hiện: một giao dịch L2 trong đó tôi chuyển tiền cho chính mình, số tiền là 5566 wei 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 TxnType (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 hiển thị giao dịch hệ thống 126 (Hệ thống), có nghĩa là giao dịch này không phải do tôi thực hiện trong L2 mà được gửi bởi giao dịch L1 . Được chuyển đổi từ các sự kiện.
Giao dịch L2 được chuyển đổi
Nếu bạn muốn gọi hợp đồng L2 và gửi dữ liệu khác nhau thông qua Force Inclusion, không gì khác hơn là điền từng tham số vào chức năng Giao dịch tiền gửi trước đó. Chỉ cần nhớ sử dụng cùng địa chỉ L1 với tài khoản L2 của bạn để gọi. chức năng giao dịch gửi tiền, để khi Sự kiện gửi tiền được chuyển đổi thành giao dịch L2, người khởi tạo là tài khoản L2 của bạn.
SequencerWindow
Nút Optimism L2 được đề cập trước đó chuyển đổi sự kiện Đã gửi giao dịch thành giao dịch L2 Trên thực tế, nút Optimism này đề cập đến Sắp xếp chuỗi, vì vậy chỉ Trình sắp xếp chuỗi mới có thể quyết định thời điểm chuyển đổi sự kiện nói trên thành. một giao dịch L2.
Khi nghe sự kiện TransactionDeposited, Sequencer 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. Giá trị tối đa của khoảng thời gian này được gọi là SequencerWindow.
Cửa sổ trình tự hiện tại trên mạng chính Optimism là 24 giờ, tức là khi người dùng gửi một khoản tiền từ L1 hoặc Force Bao gồm một giao dịch, trường hợp xấu nhất là nó sẽ được thu nhập vào lịch sử giao dịch L2 sau 24 giờ.
Cơ chế bao gồm lực lượng của Arbitrum
Trong Optimism, hoạt động Gửi tiền của L1 sẽ đưa ra một sự kiện Đã gửi giao dịch và việc còn lại là chờ Trình sắp xếp chuỗi thu thập các hoạt động trên; nhưng trong Arbitrum, các hoạt động xảy ra trong L1 (tiết kiệm tiền hoặc gửi tin nhắn đến L2, v.v.) .) sẽ được lưu trữ trong L1 trong hàng đợi, thay vì chỉ đơn giản là đưa ra một sự kiện.
Trình sắp xếp chuỗi sẽ có 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 Trình sắp xếp chuỗi không làm gì khi hết thời gian, bất kỳ ai cũng có thể hoàn thành nó cho Trình sắp xếp chuỗi.
Arbitrum sẽ duy trì Hàng đợi trong hợp đồng L1. Nếu Trình sắp xếp thứ tự không tích cực xử lý 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 đưa 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 hoạt động như gửi tiền xảy ra trên L1 phải thông qua hợp đồng Hộp thư đến bị trì hoãn, như tên cho thấy, các hoạt động ở đây sẽ bị trì hoãn để có hiệu lực; trong đó Trình sắp xếp thứ tự tải các giao dịch L2 lên L1. Lần Trình sắp xếp thứ tự tải lên một giao dịch L2, nó có thể lấy ra một số giao dịch đang chờ xử lý từ Hộp thư đến bị trì hoãn và ghi chúng vào lịch sử giao dịch.
Khi Sequencer ghi một giao dịch mới, nó có thể lấy giao dịch đó ra khỏi DelayedInbox và ghi lại cùng nhau.
Thiết kế phức tạp và tham khảo được ghi chép đầy đủ
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, họ sẽ thấy rằng nó đề 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:
Trước tiên, người dùng truy cập hợp đồng DelayedInbox để gọi hàm sendUnsignedTransaction . Nếu Sequencer không được đưa vào trong khoảng 24 giờ, người dùng có thể gọi hàm ForceInclusion của hợp đồng SequencerInbox . Khi đó Arbitrum chính thức không đính kèm liên kết của chức năng vào tài liệu trang web chính thức nên bạn chỉ có thể tự mình xem chức năng tương ứng trong mã hợp đồng.
Khi tìm thấy hàm sendUnsignedTransaction, bạn thấy rằng mình phải tự điền giá trị nonce và giá trị maxFeePerGas. Địa chỉ nào là nonce? MaxFeePerGas được cung cấp trên mạng nào? Cách tốt nhất để điền vào nó là gì? Không có tài liệu tham khảo tập tin, thậm chí không có Natpsec. Sau đó, bạn cũng sẽ tìm thấy một loạt chức năng tương tự trong hợp đồng Arbitrum:
SendL1FundedUnsignedTransaction, sendUnsignedTransactionToFork, sendContractTransaction, sendL1FundedContractTransaction, 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 thông số, kể cả Natpsec.
Bạn cố gắng điền các tham số và gửi giao dịch với tâm lý muốn thử. Bạn muốn dùng thử và tìm lỗi để xem liệu bạn có thể tìm ra cách sử dụng chính xác hay không, nhưng bạn nhận thấy rằng các chức năng này đều thực hiện Xác minh địa chỉ trên địa chỉ L1 của bạn. , dẫn đến lỗi cuối cùng trên L2. Người gửi khi bắt đầu giao dịch chỉ đơn giản là một địa chỉ khác nên địa chỉ L2 của bạn vẫn bất động.
gửiL2Tin nhắn
Sau đó, tôi vô tình nhấp vào tìm kiếm trên Google và phát hiện ra rằng Arbitrum có thư viện Hướng dẫn, chứa các tập lệnh minh họa cách gửi giao dịch L2 từ L1 (nghĩa là Force Inclusion) và các chức năng được liệt kê trong đó không phải là bất kỳ chức năng nào đã đề cập ở trên, nhưng một hàm có tên sendL2Message và tham số tin nhắn thực sự là một giao dịch được ký bằng tài khoản L2?
Ai có thể biết rằng "tin nhắn được gửi tới L2 thông qua Force Inclusion" thực sự sẽ là một "giao dịch L2 đã ký"? Và không có tài liệu hay 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 bắt buộc 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ã. Mục đích và thông số của nhiều chức năng thiếu sự giải thích, khiến 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. Mình 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.
Khi tôi hỏi trên Discord, bên kia chỉ bảo tôi xem sendL2Message. Họ không muốn giải thích chức năng của các chức năng khác (thậm chí sendUnsignedTransaction đã đề cập trong tài liệu Force Inclusion), chúng dùng để làm gì, sử dụng như thế nào. , và khi nào nên sử dụng chúng.
Cơ chế ForceInclusion của StarkNet
Thật không may, StarkNet hiện chưa có cơ chế ForceInclusion. Chỉ có hai bài viết thảo luận về Kiểm duyệt và ForceInclusion trên diễn đàn chính thức.
Không thể chứng minh giao dịch thất bại
Lý do trên thực chất là do hệ thống Bằng chứng không tri thức của StarkNet không thể chứng minh được giao dịch thất bại nên không thể cho phép Force Inclusion. Bởi vì nếu ai đó cố ý (hoặc vô ý) Force Bao gồm một giao dịch thất bại không thể được chứng minh, StarkNet sẽ bị kẹt trực tiếp : vì sau khi giao dịch bị ép buộc thu 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 thất bại trong phiên bản v0.15.0, sau đó có thể triển khai thêm cơ chế Force Inclusion.
Cơ chế ForceInclusion của zkSync
Tất cả việc truyền tin nhắn L1->L2 và cơ chế Force Inclusion 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, dữ liệu cuộc gọi, số ETH bổ sung, giá trị L2GasLimit, v.v. requestL2Transaction sẽ kết hợp các tham số này thành một L2. giao dịch sau đó được đưa vào hàng đợi ưu tiên (PriorityQueue). Khi giao dịch được đóng gói và tải lên L1 (thông qua chức năng commitBatches), Trình sắp xếp chuỗi sẽ cho biết có bao nhiêu giao dịch được lấy ra khỏi hàng đợi ưu tiên và đưa chúng vào bản ghi giao dịch L2. .
zkSync rất giống với Optimism ở dạng Force Inclusion. Nó sử dụng địa chỉ L2 của người khởi tạo (phù hợp với địa chỉ L1) để gọi các chức năng liên quan và điền dữ liệu (callee, calldata, v.v.), thay vì như Arbitrum. trong giao dịch L2 đã ký; nhưng thiết kế giống với Arbitrum, cả hai đều duy trì Hàng đợi trong L1 và Trình sắp xếp chuỗi sẽ lấy các giao dịch đang chờ xử lý do người dùng gửi trực tiếp từ Hàng đợi và ghi nó vào giữa lịch sử giao dịch.
Nếu bạn đi tới Gửi ETH thông qua cầu nối chính thức của zkSync , chẳng hạn như giao dịch này, nó sẽ gọi hàm requestL2Transaction của hợp đồng MailBox. Nó sẽ đưa giao dịch L2 của Gửi ETH vào hàng đợi ưu tiên và đưa ra sự kiện NewPriorityRequest . Bởi vì hợp đồng mã hóa dữ liệu giao dịch L2 thành một chuỗi byte nên rất khó đọc. Nếu nhìn vào các tham số của giao dịch L1 này, bạn sẽ thấy người nhận L2 trong các tham số cũng là người khởi tạo giao dịch (. vì nó được gửi cho chính bạn), nên sau một thời gian, khi giao dịch L2 này được Sequencer đưa ra khỏi hàng đợi ưu tiên và được đưa vào lịch sử giao dịch, nó sẽ được chuyển thành giao dịch được chuyển cho chính nó trên L2 và số tiền chuyển khoản là Khoản tiền gửi của người khởi tạo giao dịch trong L1 Số lượng ETH được mang trong giao dịch ETH.
Trong giao dịch L1Deposit, người khởi tạo và người nhận giao dịch đều là 0xeDc1...6909, số tiền là 0,03ETH và dữ liệu cuộc gọi trống.
Giao dịch 0xeDc1...6909 sẽ xuất hiện trên L2. Loại giao dịch (TxnType) là 255, là giao dịch hệ thống. Sau đó, tôi đã gọi trực tiếp chức năng requestL2Transaction của zkSync giống như chức năng giao dịch bắt buộc của OP trước đây và gửi Tự chuyển khoản: không có ETH, dữ liệu cuộc gọi chứa mã HEX của chuỗi "bắt buộc đưa vào". Sau đó, nó được chuyển đổi thành giao dịch cuối cùng của L2 thành chính nó. Calldata là chuỗi thập lục phân của "bắt buộc đưa vào": 0x666f72636520696e636c7573696f6e.
Khi Sequencer đưa giao dịch ra khỏi PriorityQueue và ghi nó vào lịch sử giao dịch, nó sẽ đượ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ể sử dụng tài khoản L1 có cùng địa chỉ L2 để gửi thông tin trong L1, chỉ định người nhận L2, số ETH đi kèm 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, thì việc tương tự cũng được thực hiện bằng cách điền lần lượt các tham số vào hàm requestL2Transaction.
Không có chức năng nào cho phép người dùng buộc đưa vào
Mặc dù sau khi giao dịch L2 được đặt vào hàng ưu tiên, thời gian chờ để giao dịch L2 được đưa vào Trình sắp xếp chuỗi sẽ được tính toán ngẫu nhiên. Tuy nhiên , thiết kế zkSync hiện tại không có chức năng Force Inclusion mà người dùng có thể thực thi. tương đương với chỉ một nửa bộ . Nghĩa là, mặc dù có một "thời gian chờ để đưa vào", nhưng thực chất là "xem Người sắp xếp có muốn thu nhập hay không": Người sắp xếp có thể đợi đến ngày hết hạn trước khi thu nhập hoặc không bao giờ có thể thu nhập 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 giao dịch được đưa vào lịch sử giao dịch L2 khi thời hạn hiệu lực thu nhập đã trôi qua nhưng chưa được đưa vào Sequencer. Đây là một cơ chế Force Inclusion thực sự hiệu quả.
Tóm tắt
L1 dựa vào một số lượng lớn trình xác nhận để đảm bảo tính "bảo mật" và "khả năng chống kiểm duyệt" của mạng Rollup sử dụng một số lượng nhỏ hoặc thậm chí một Trình sắp xếp chuỗi duy nhất để ghi các giao dịch và 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 Trình sắp xếp thứ tự và ghi các giao dịch vào lịch sử để tránh bị Trình sắp xếp trình tự xem xét và khiến họ không thể sử dụng và rút tiền từ Tổng hợp.
Force Inclusion 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 chọn xem giao dịch có thể được chèn ngay vào lịch sử hay không và có hiệu lực ngay lập tức. Nếu các giao dịch được phép có hiệu lực ngay lập tức, nó sẽ có tác động tiêu cực đến Sequencer, vì các giao dịch chờ thu nhập trên L2 có thể bị ảnh hưởng bởi sàn giao dịch bị L1 buộc phải thu nhập .
Do đó, cơ chế Force Inclusion 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ó thu nhập các giao dịch đang chờ xử lý này hay không.
Cả zkSync và Arbitrum đều duy trì Hàng đợi trong L1 để quản lý các giao dịch L2 được người dùng gửi từ L1 hoặc tin nhắn đến L2. Arbitrum được gọi là DelayedInbox; zkSync được gọi là PriorityQueue
Tuy nhiên, cách zkSync gửi giao dịch L2 tương tự như Optimism . Nó sử dụng địa chỉ L2 để gửi tin nhắn đến L1. Sau khi chuyển đổi sang giao dịch L2, người khởi tạo 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 và ký một giao dịch L2 hoàn chỉnh, sau đó gửi nó thông qua chức năng 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ế Force Inclusion; zkSync giống như một nửa bộ Force Inclusion - có PriorityQueue và mỗi giao dịch L2 trong Queue đều có thời hạn hiệu lực bao gồm, nhưng thời hạn hiệu lực này hiện chỉ mang tính chất trang trí. Trình sắp xếp chuỗi có thể chọn không thu nhập bất kỳ giao dịch L2 nào trong PriorityQueue
