Lý thuyết và thực hành: Các giao dịch chống kiểm duyệt được kích hoạt trong Ethereum Rollup như thế nào?

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

Tiêu đề gốc: "Giới thiệu về Cơ chế bao gồm lực lượng của Rollup"

Mới hôm qua đã xảy ra một chuyện khiến vô số người bàng hoàng: < mạnh>Linea, lớp Ethereum thứ hai do Consensys, công ty mẹ của Metamask ra mắt, đã chủ động đóng cửa Các quan chức cho biết mục đích của việc này là để giảm tác động của vụ hack 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 của 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 rồi, ở trên Nguyên nhân cốt lõi của sự việc nằm nhiều hơn ở sự thiếu hoàn hảo của bản thân cơ sở hạ tầng, tức là thiếu sự phân cấp: Nếu một chuỗi được phân cấp đầ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 Lớp 2 đều dựa vào Trình sắp xếp chuỗi tập trung Mặc dù ngày càng có nhiều tranh luận về trình sắp xếp chuỗi phi tập trung trong những năm gần đây, khi xem xét sự tồn tại của lớp thứ hai. Xét về mục đích và cấu trúc của nó, chúng ta có thể giả định một cách an toàn rằng trình sắp xếp của Layer2 rất có thể sẽ không được phân cấp nhiều và cuối cùng nó có thể không được phân cấp như chuỗi BSC. Nếu điều này là đúng 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 tính không phân cấp của bộ phân loại nằm ở hoạt động và phản kháng kiểm duyệt của nó. Nếu có rất ít thực thể (Trình tự sắp xếp) xử lý 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ó cách nào. Làm thế nào để giải quyết vấn đề chống kiểm duyệt của Lớp 2 rõ ràng là một chủ đề quan trọng.

Trong vài năm qua, các lớp thứ hai của 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 cưỡng bức rút và thoát khỏi cabin của StarkEx, cũng như Arbitrum và các chức năng Force Inclusion khác của OP Rollup. Các phương pháp này có thể kiểm tra và cân bằng Trình 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ột cách vô lý.

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. Anh ấy đã đí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à cung cấp phân tích chuyên sâu từ các khía cạnh như vậy. như quy trình làm việc và phương thức vận hành Với thiết kế của cơ chế Force  Inclusion, điều này đặc biệt có giá trị đối với cộng đồng Ethereum và các nhà đầu tư lớn nắm giữ số lượng tài sản khổng lồ.

Xem xét giao dịch và Bắt buộc

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, điều này không khác gì từ 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 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 vai trò 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 tính bảo mật và khả năng chống kiểm duyệt là hai thứ khác nhau. Ngay cả khi Bản tổng hợp an toàn như Ethereum thì chỉ với một Trình sắp xếp tập trung, mọi giao dịch của người dùng đều có thể bị kiểm duyệt.

Trình sắp xếp chuỗi có thể từ chối xử lý giao dịch của người dùng, dẫn đến việc tiền của người dùng bị giữ lại và không thể rời khỏi Tổng hợp

Cơ chế bao gồm bắt buộc

Thay vì yêu cầu Rollup phải có số lượng lớn Trình sắp xếp chuỗi phi tập trung, tốt hơn hết bạn nên sử dụng trực tiếp khả năng chống kiểm duyệt của L1:

Trình tự gốc Mục đích là đóng gói dữ liệu giao dịch và gửi đến hợp đồng Rollup của L1. Tốt hơn là nên thêm một thiết kế vào hợp đồng để cho phép người dùng tự chèn các giao dịch vào hợp đồng Rollup. Cơ chế này được gọi là "Lực lượng 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 chèn giao dịch ở cấp độ L1. Bằng cách này,Cuộn lên 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ả chi phí cao

Nên buộc như thế nào giao dịch có hiệu lực?

Nếu các giao dịch được phép ghi trực tiếp vào hợp đồng Tổng hợp thông qua Force Inclusion (nghĩa là có hiệu lực ngay lập tức), trạng thái của Tổng hợp sẽ thay đổi ngay lập tức. Ví dụ: Bob chèn một giao dịch. thông qua cơ chế Force Inclusion Đối với giao dịch "chuyển 1000 DAI cho Carol", 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 1000 DAI và Carol sẽ nhiều hơn 1000 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ậyRollup 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 chờ trên L1 và nhập ". 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 tiếp tục bỏ qua các giao dịch này trong hợp đồng. Trạng thái "chuẩn bị" Giao dịch, sau khi thời gian hết hạn, người dùng có thể buộc chèn các giao dịch này vào hợp đồng Tổng hợp.

Trình sắp xếp chuỗi có thể quyết định thời điểm "nhận ngẫu nhiên" các giao dịch trong hàng chờ

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 Sequencer từ chối trong một thời gian dài, bất kỳ ai cũng có thể sau một thời gian khoảng thời gian Buộc chèn các giao dịch vào hợp đồng Rollup thông qua chức năng Force Inclusion

Tiếp theo, chúng tôi sẽ giới thiệu theo thứ tự Force Inclusion của bốn Rollup nổi tiếng hơn, bao gồm Optimism, Arbitrum, Cơ chế StarkNet và zkSync được triển khai.

Cơ chế bao gồm lực lượng của Optimism

Đầ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. bao gồm "Gửi thông tin người dùng gửi đến L2" vào 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.

Thông báo của người dùng từ Gửi tiền L1 đến L2

Hợp đồng L1CrossDomainMessenger

Khi người dùng muốn gửi mã thông báo 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. nhận được những tài sản này.

Hợp đồng L1StandardBridge sẽ chuyển thông báo đến hợp đồng L1CrossDomainMessenger của lớp tiếp theo Hợp đồng này chủ yếu được sử dụng như một thành phần để liên lạc lẫn nhau giữa L1 ​​và L2. , L1StandardBridge Thành phần giao tiếp phổ quát này giao tiếp với L2StandardBridge trên L2 để xác định ai có thể đúc mã thông báo trong L2 hoặc ai có thể mở khóa mã thông báo 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 OptimismPortal

Sau đó, hợp đồng L1CrossDomainMessenger sẽ được gửi đến hợp đồng OptimismPortal cấp dưới cùng. Sau khi hợp đồng OptimismPortal được xử lý, một sự kiện có tên TransactionDeposited sẽ được đưa ra. người đã gửi tin nhắn" và "người đã nhận được tin nhắn". "người" 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 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 đã gửi tin nhắn" được chỉ định trong tham số sự kiện Gửi tiền giao dịch và người nhận giao dịch là "người đã nhận được tin nhắn" trong tham số sự kiện. Các tham số giao dịch khác cũng được lấy từ các tham số trong các sự kiện trên.

Nút L2 sẽ chuyển đổi thông số sự kiện Gửi tiền giao dịch của OptimismPortalemit thành giao dịch L2

Ví dụ: đây là< mạnh> 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 giao dịch L2 vài phút sau: < /strong>

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.

Cách kích hoạt 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à thực hiện một giao dịch " từ "Giao dịch được khởi tạo và thực hiện bởi địa chỉ L2 của bạn trên L2" có thể được thực hiện suôn sẻtại thời điểm nàybạn nên sử dụng địa chỉ L2 của mình để 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 tế là trên L1. Tuy nhiên, đị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ỉ với 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 đưa ra 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 giống như 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 xướng sẽ là chính Bob; người nhận là hợp đồng Uniswap; và nó sẽ đi kèm với các điều khoản được chỉ định ETH, giống như Bob đã tự mình thực hiện giao dịch L2

Nếu bạn muốn gọi hàm Force Inclusion của Optimism thì bạn phải gọi trực tiếp DepositTransaction của hợp đồng OptimismPortal và thêm Điền vào các thông số của giao dịch được 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 một điều: trên L2 Sử dụng địa chỉ của tôi để tự chuyển (0xeDc1…6909) bằng 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

Giá trị trong cột Dữ liệu mờ còn lại được mã hóa bằng "gọi " Chức năng Giao dịch tiền gửi mang lại bao nhiêu ETH", "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à "Dữ liệu cho 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": < /strong>0 , vì tôi không gửi ETH từ L1 đến L2;

"Người khởi tạo giao dịch L2 muốn gửi bao nhiêu ETH cho người nhận": 5566 (wei )

< p>"GasLimit cho giao dịch L2": 50000

"Dữ liệu cho người nhận L2":0x666f72636520696e636c7573696f6e, chính là từ này "bắt buộc đưa vào" Mã hóa thập lục phân của chuỗi

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 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ác sự kiện được chuyển đổi.

Giao dịch L2 đã 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 đó. 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 tiền gửi, để khi Sự kiện đã gửi đượ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 Ký gửi giao dịch thành giao dịch L2. Trên thực tế, nút Optimism này rốt cuộc đề cập đến Sequencer. , mối quan hệ này với thứ tự giao dịch, vì vậychỉ Người sắp xếp thứ tự mới có thể quyết định thời điểm chuyển đổi sự kiện nói trên thành 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à số tiền đó sẽ được đưa vào giao dịch. Lịch sử giao dịch L2 sau 24 giờ.

Cơ chế bắt buộc của Arbitrum

Hoạt động gửi tiền của L1 trong Optimism sẽ tạo 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 bao gồm thao tác trên ;Nhưng trong Trọng tài, các thao tác xảy ra trên 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 trên L1, thay vì chỉ đư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ó trong thời gian đó. Trình sắp xếp thứ tự.

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

Arbitrum Trong thiết kế, 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; , là nơi trực tiếp nơi Trình sắp xếp thứ tự tải các giao dịch L2 lên L1. Mỗi 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, bạn có thể lấy giao dịch đó ra khỏi DelayedInbox và viết nó cùng nhauThiết kế phức tạp và nhiều tài liệu tham khảo

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 Force được đề cập trong đó Cách thức hoạt động của Inclusion cũng như một số tên tham số và tên hàm:

Trước tiên, người dùng đi tới hợp đồng DelayedInbox để gọi sendUnsignedTransaction. Nếu Sequencer không được đưa vào trong vòng khoảng 24 giờ, người dùng có thể gọi hàm forceInclusion của hợp đồng SequencerInbox. Sau đó, 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. 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 các hàm tương tự trong hợp đồng Arbitrum:

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 chúng và cách thức sử dụng chúng. để điền các thông số, thậm chí không phải Natpsec.

Bạn cố gắng điền các thông số và gửi giao dịch với tâm lý thăm dò. Bạn muốn thử và sai để xem liệu mình có tìm được 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 sẽ sử dụng của bạn. Địa chỉ L1. Bí danh địa chỉ dẫn đến việc Người gửi cuối cùng có một địa chỉ khác khi bắt đầu giao dịch trên L2, do đó địa chỉ L2 của bạn vẫn bất động.

sendL2Message

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 riêng, trong đó có chứa các tập lệnh minh họa cách gửi L2 các giao dịch từ L1 (Nghĩa là ý nghĩa của Force Inclusion), và sau đó chức năng mà nó liệt kê không phải là bất kỳ chức năng nào được đề cập ở trên, mà là một chức năng có tên sendL2Message và tham số thông báo sẽ được đưa vào. hóa ra là tài khoản L2 Một thỏa thuận đã ký?

Ai có thể biết rằng "tin nhắn được gửi tới L2 thông qua Force Inclusion" thực 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 bằng 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. Tôi cũng đã hỏi người của Arbitrum trên 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ỉ yêu cầu 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 (ngay cả sendUnsignedTransaction đã đề cập trong tài liệu Force Inclusion), chúng là gì. dùng để làm gì, sử dụng chúng như thế nào và thời gian sử dụng chúng là gì.

Cơ chế ForceInclusion của StarkNet

Thật không may, StarkNet vẫ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 được giao dịch thất bại

Lý do trên thực chất là do hệ thống zero-know proof proof của StarkNet không thể chứng minh được giao dịch thất bại nên không được phép Buộc bao gồm. Bởi vìNếu ai đó cố ý (hoặc vô ý) Buộc Bao gồm một giao dịch thất bại mà không thể chứng minh được thì StarkNet sẽ bị kẹt trực tiếp: vì sau khi buộc phải đưa giao dịch đó vào, Prover phải chứng minh rằng giao dịch đó không thành công. , nhưng nó không có cách nào để chứng minh điều đó.

StartNet 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ế Buộc đưa vào.

Cơ chế ForceInclusion của zkSync

Việc truyền thông báo L1->L2 của zkSync và cơ chế Force Inclusion đều thông qua requestL2Transaction của hợp đồng MailBox Khi được thực thi, 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 giao dịch L2 và sau đó đưa nó vào hàng đợi ưu tiên (PriorityQueue) sẽ đóng gói giao dịch. Khi tải lên L1 (thông qua chức năng commitBatches), hãy cho biết số lượng giao dịch sẽ được đưa ra khỏi hàng ưu tiên và được đưa vào bản ghi giao dịch L2.

zkSync rất giống với Optimism ở dạng Force Inclusion Cả hai đều 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 ( được nhận bởi người gọi, dữ liệu cuộc gọi, v.v.), thay vì điền vào giao dịch L2 đã ký như Arbitrum; nhưng về mặt thiết kế, nó giống như Arbitrum, duy trì Hàng đợi trong L1 và Trình sắp xếp chuỗi lấy nó từ Đầu ra hàng đợi đang chờ xử lý. các giao dịch được người dùng gửi trực tiếp và ghi chúng vào lịch sử giao dịch.

Nếu bạn đi để gửi ETH thông qua cầu nối chính thức của zkSync. Đối với giao dịch này, nó 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 một 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 đổi thành giao dịch được chuyển về 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à calldata trống

< p style="text-align: center;">

< span style="font-size: 14px;">Sẽ có một giao dịch 0xeDc1...6909 được chuyển đến chính nó trên L2. Loại giao dịch (TxnType) là 255, là giao dịch hệ thống

Sau đó, tôi trực tiếp gọi hàm requestL2Transaction của zkSync và gửi một lệnh tự chuyển như tôi đã làm trước đây khi thử nghiệm chức năng giao dịch bắt buộc của OP: không có ETH, dữ liệu cuộc gọi sẽ mang mã hóa HEX của chuỗi "bao gồm lực lượng".

Sau đó, nó được chuyển đổi thành giao dịch trước đó của L2 thành chính nó. Dữ liệu cuộc gọi chứa chuỗi thập lục phân của “bắt buộc đưa vào”: 0x666f72636520696e636c7573696f6e.

Khi Trình sắp xếp thứ tự đư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ỉ với địa chỉ L2, gửi thông tin trong L1 và 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 bắt buộc đưa vào

Mặc dù sau khi giao dịch L2 được đặt vào hàng đợi ưu tiên, nó sẽ được Sequencer tính toán Có một khoảng thời gian chờ đợi để đưa vào, nhưng hiện tại không có chức năng Bắt buộc đưa vào mà người dùng có thể thực thi trong thiết kế zkSync, chỉ tương đương với 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 nhận doanh thu hay không": Người sắp xếp có thể đợi đến ngày hết hạn trước khi nhận giao dịch hoặc không bao giờ có thể nhận được 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 của thu nhập đã trôi qua nhưng chưa được Sequencer đưa vào. Cơ chế bao gồm hiệu quả.

Tóm tắt

L1 dựa vào một số lượng lớn người xác minh để đảm bảo tính "bảo mật" và "khả năng chống kiểm duyệt" của mạng. hoặc thậm chí một Sequencer duy nhất viết các giao dịch, khả năng chống kiểm duyệt 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út tiền từ Rollup.

Buộc đưa vào 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 "liệu giao dịch có thể được đưa ngay vào lịch sử hay không" lịch sử 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ờ 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ế bắt buộc bao gồm 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 phép Trình sắp xếp chuỗi một khoảng thời gian để phản ứng và chọn xem có nhận hay không những giao dịch này chờ đợi.

Cả zkSync và Arbitrum đều duy trì Hàng đợi 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 được gọi là DelayedInbox; zkSync được gọi là PriorityQueue

Nhưng cách zkSync gửi giao dịch L2 giống với Optimism hơn, cả hai đều sử dụng địa chỉ L2 để gửi tin nhắn đến L1, cách này sẽ chuyển đổi chúng đến L2 Sau giao dịch, 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, với PriorityQueue và mỗi giao dịch L2 trong Hàng đợi đều có ngày hết hạn. nhưng khoảng thời gian hiệu lực này hiện chỉ mang tính chất trang trí, Sequencer có thể chọn không đưa bất kỳ giao dịch L2 nào vào PriorityQueue

< /p>