Cựu đại sứ kỹ thuật trọng tài giải thích cấu trúc thành phần của Arbitrum (Phần II)

Tác giả: Benben Luo, cựu đại sứ kỹ thuật Arbitrum, cộng tác viên geek web3

Trong bài viết trước, “Cựu Đại sứ Kỹ thuật Trọng tài Giải thích Cấu trúc Thành phần của Trọng tài (Phần I)”, chúng tôi đã giới thiệu vai trò của trình sắp xếp, trình xác thực, hợp đồng SequencerInbox, Khối tổng hợp và bằng chứng gian lận không tương tác trong các thành phần cốt lõi của Trọng tài và trong bài viết hôm nay, chúng tôi sẽ tập trung vào các thành phần của các thành phần cốt lõi của Arbitrum liên quan đến thông điệp tương tác xuyên chuỗi và lối vào giao dịch chống kiểm duyệt.

Thân bài: Trong một bài viết trước, chúng tôi đã đề cập rằng hợp đồng Sequencer Inbox đặc biệt nhận lô gói giao dịch được xuất bản bởi sequencer trên Layer 1. Đồng thời, chúng tôi chỉ ra rằng Sequencer Inbox còn được gọi là Fast Box, trái ngược với Slow Box Delayed Inbox (viết tắt là Inbox). **Dưới đây, chúng tôi sẽ xem xét kỹ hơn các thành phần liên quan đến nhắn tin tương tác chuỗi chéo, chẳng hạn như Hộp thư đến bị trì hoãn.

Nguyên tắc tương tác chuỗi chéo và cầu nối

Các giao dịch tương tác Cross-Chain có thể được chia thành L1 đến L2 (tiền gửi) và L2 đến L1 (rút tiền). Lưu ý rằng các khoản tiền gửi và rút tiền được đề cập ở đây không nhất thiết liên quan đến tương tác chuỗi chéo tài sản và có thể là các tin nhắn không đính kèm trực tiếp tài sản. Vì vậy, hai từ này chỉ có nghĩa là hai hướng của hành vi liên quan đến tương tác chuỗi chéo.

Giao dịch tương tác chuỗi chéo phức tạp hơn giao dịch L2 thuần túy, giao dịch Tương tác chuỗi chéo có thông tin được hoán đổi trong hai hệ thống khác nhau là L1 và L2.

Ngoài ra, những gì chúng ta thường gọi là hành vi tương tác chuỗi chéo là tương tác chuỗi chéo trên hai mạng không liên quan với cầu tương tác chuỗi chéo ở chế độ nhân chứng và tính bảo mật của Tương tác chuỗi chéo này phụ thuộc vào người vận hành Cầu tương tác chuỗi chéo và hành vi trộm cắp cầu tương tác chuỗi chéo dựa trên mô hình nhân chứng đã xảy ra thường xuyên trong lịch sử.

Hành vi Tương tác chuỗi chéo giữa Rollup và ETHMainnet về cơ bản khác với Tương tác chuỗi chéo ở trên, vì trạng thái của Lớp 2 được xác định bởi dữ liệu được ghi trên Lớp 1, miễn là bạn sử dụng cầu nối Tương tác chuỗi chéo chính thức, nó tuyệt đối an toàn về cấu trúc hoạt động. **

Điều này cũng làm nổi bật bản chất của Rollup, nó chỉ là từ quan điểm của người dùng, giống như một chuỗi độc lập, nhưng trên thực tế, cái gọi là ** “Layer2” chỉ là một cửa sổ hiển thị nhanh của Rollup mở cho người dùng và cấu trúc chuỗi thực của nó vẫn bị đốt cháy trên Lớp 1. Do đó, chúng ta có thể nghĩ về L2 như một nửa chuỗi, hoặc “một chuỗi được tạo trên Lớp 1”.

Vé có thể thử lại Có thể thử lại

Cần lưu ý rằng tương tác chuỗi chéo là không đồng bộ và không nguyên tử, không thể biết kết quả sau khi hoàn thành xác nhận giao dịch như trên chuỗi và không có gì đảm bảo rằng điều gì đó sẽ xảy ra ở phía bên kia tại một thời điểm nhất định. Do đó, Tương tác chuỗi chéo có thể không thành công do một số vấn đề mềm, nhưng miễn là sử dụng đúng phương tiện, chẳng hạn như Vé thử lại, các vấn đề khó như tiền bị kẹt sẽ không xảy ra.

** Vé có thể thử lại là các công cụ cơ bản được sử dụng khi gửi tiền qua cầu Arbitrum chính thức, **ETH và tiền gửi ERC20 được sử dụng. Vòng đời của nó được chia thành ba bước:

**1. Gửi vé trên L1. **Sử dụng phương thức createRetryableTicket() trong hợp đồng Delayed Inbox để tạo phiếu nạp tiền và gửi.

**2. Đổi quà tự động trên L2. **Trong hầu hết các trường hợp, bộ giải trình tự có thể tự động đổi hóa đơn cho người dùng mà không cần thao tác thủ công tiếp theo.

**3. L2. **Trong một số trường hợp cận biên, chẳng hạn như giá xăng tăng đột ngột trên L2 và không đủ gas trả trước trên ghi chú, nó sẽ không được tự động đổi. Trong trường hợp này, nó cần phải được thực hiện thủ công bởi người dùng.

Lưu ý rằng nếu quy đổi tự động không thành công, bạn sẽ cần đổi ghi chú theo cách thủ công trong vòng 7 ngày, nếu không hóa đơn sẽ bị xóa (tiền sẽ bị mất vĩnh viễn) hoặc bạn sẽ cần phải trả phí để gia hạn hợp đồng thuê để bảo quản hóa đơn.

Ngoài ra, mặc dù có sự tương đồng đối xứng nhất định giữa quá trình rút tiền của cầu nối chính thức Arbitrum và hành vi gửi tiền, nhưng không có khái niệm Retryables, một mặt có thể được hiểu từ chính giao thức Rollup và mặt khác là một số khác biệt:

Không có quy đổi tự động trong quá trình rút tiền, vì không có bộ hẹn giờ hoặc tự động hóa trong EVM và việc mua lại tự động có thể được thực hiện trên L2, điều này đạt được với sự trợ giúp của trình sắp xếp, vì vậy người dùng trên L1 cần tương tác thủ công với hợp đồng Hộp thư đi để truy xuất tài sản với Yêu cầu bồi thường. Không có vấn đề về hóa đơn quá hạn để rút tiền, miễn là thời gian thử thách đã qua, nó có thể được yêu cầu bất cứ lúc nào.

Cổng tương tác chuỗi chéo tài sản ERC-20

• Tương tác chuỗi chéo của tài sản ERC-20 rất phức tạp. Có một vài câu hỏi chúng ta có thể suy ngẫm:
• Token triển khai trên L1, triển khai như thế nào trên L2?
• Đối tác L2 của nó có cần phải được triển khai thủ công trước hay hệ thống có thể tự động triển khai hợp đồng tài sản cho các Token giao nhau nhưng chưa triển khai hợp đồng không?
• Địa chỉ hợp đồng của tài sản ERC-20 trên L1 tương ứng với L2 là gì? Nó có nên phù hợp với L1 không?
• Làm thế nào để Tương tác chuỗi chéo với L1 cho các Token được phát hành nguyên bản trên L2?
• Token có chức năng đặc biệt, chẳng hạn như số lượng Rebase Token có thể điều chỉnh, Token chịu lãi suất tự phát triển, làm thế nào để Tương tác xuyên chuỗi?

Chúng tôi sẽ không trả lời tất cả những câu hỏi này, bởi vì nó quá phức tạp để mở rộng. Những câu hỏi này chỉ được sử dụng để minh họa sự phức tạp của tương tác chuỗi chéo ERC20.

Hiện tại, nhiều giải pháp mở rộng quy mô sử dụng danh sách cho phép + giải pháp kiểm kê thủ công để tránh các vấn đề phức tạp và tình huống ranh giới khác nhau.

Arbitrum sử dụng hệ thống Gateway để giải quyết hầu hết các điểm đau của tương tác chuỗi chéo ERC20, với các tính năng sau:

• Các thành phần cổng xuất hiện theo cặp tại L1 và L2. Bộ định tuyến cổng chịu trách nhiệm duy trì ánh xạ Địa chỉ giữa Token L1<->Token L2, cũng như giữa một số token <-> một số cổng.
• Cổng có thể được chia thành cổng StandardERC20, cổng tùy chỉnh chung, cổng tùy chỉnh, v.v., để giải quyết các loại khác nhau và các vấn đề bắc cầu ERC20 chức năng.

Hãy lấy Tương tác chuỗi chéo WETH tương đối đơn giản làm ví dụ để minh họa sự cần thiết của một cổng tùy chỉnh.

WETH tương đương với ERC20 của ETH. Vì Ether là đồng tiền chính, nhiều chức năng phức tạp trong dApps là không thể, vì vậy cần phải có ERC20 tương đương. Chuyển một số ETH vào hợp đồng WETH, chúng sẽ bị khóa trong hợp đồng và cùng một lượng WETH sẽ được tạo ra.

Theo cách tương tự, cũng có thể đốt WETH và lấy ra ETH. **Rõ ràng, số lượng WETH đang lưu hành và số lượng Vị trí khóa ETH sẽ luôn là 1: 1. **

** Nếu bây giờ chúng ta tương tác chuỗi chéo WETH trực tiếp lên L2, chúng ta sẽ tìm thấy một số vấn đề lạ: **

• Không thể mở WETH thành ETH trên L2 vì không có vị trí khóa tương ứng với ETH trên L2.
• Hàm Wrap có thể được sử dụng, nhưng các WETH mới được tạo này không thể được tách rời dưới dạng ETH trên L1 nếu chúng quay trở lại L1, vì các hợp đồng WETH trên L1 và L2 không “đối xứng”.

Rõ ràng, điều này vi phạm các nguyên tắc thiết kế của WETH. **Sau đó, khi WETH là tương tác chuỗi chéo, cho dù đó là tiền gửi hay rút tiền, nó cần được mở ra thành ETH trước, sau đó vượt qua phía đối diện, sau đó được bọc vào WETH. Đây là lúc WETH Gateway xuất hiện.

Các Token khác có logic phức tạp hơn cũng làm như vậy, đòi hỏi các cổng phức tạp hơn và được thiết kế tốt hơn để hoạt động bình thường trong môi trường tương tác chuỗi chéo. Cổng tùy chỉnh của Arbitrum kế thừa logic tương tác chuỗi chéo của các cổng thông thường và cho phép các nhà phát triển tùy chỉnh hành vi tương tác chuỗi chéo liên quan đến logic mã thông báo, có thể đáp ứng hầu hết các nhu cầu.

Hộp thư đến bị trì hoãn

Đối tác của SequencerInbox là Delayed Inbox (Delayed Inbox). Vì hộp nhanh được dành riêng để nhận hàng loạt giao dịch L2 do trình sắp xếp chuỗi xuất bản, tất cả các giao dịch chưa được xử lý trước bởi trình sắp xếp trong mạng L2 sẽ không xuất hiện trong hợp đồng hộp nhanh.

**Chức năng đầu tiên của hộp chậm là xử lý hành vi nạp tiền từ L1 đến L2. **Người dùng gửi tiền thông qua Hộp chậm, và trình sắp xếp theo dõi lắng nghe nó và sau đó phản ánh nó trên L2, và cuối cùng bản ghi tiền gửi sẽ được trình sắp xếp chuỗi đưa vào chuỗi giao dịch L2 và được gửi đến Hộp thư đến Trình sắp xếp.

Trong ví dụ này, việc người dùng gửi giao dịch nạp tiền trực tiếp vào Sequencer Inbox là không phù hợp, vì giao dịch được gửi đến Sequencer Inbox sẽ can thiệp vào thứ tự giao dịch thông thường của Layer 2, sau đó ảnh hưởng đến công việc của sequencer.

Chức năng thứ hai của slow box là chống lại sự kiểm duyệt. **Các giao dịch do người dùng gửi trực tiếp đến hợp đồng Slowbox sẽ được trình sắp xếp chuỗi thu thập trong vòng 10 phút. Nhưng nếu trình sắp xếp chuỗi ác ý bỏ qua yêu cầu của bạn, hộp chậm cũng có chức năng bao gồm bắt buộc:

Nếu giao dịch được gửi đến Hộp thư đến bị trì hoãn, sau 24 giờ, giao dịch trong Hộp chậm chưa được trình sắp xếp chuỗi đưa vào trình tự giao dịch, **Người dùng có thể kích hoạt thủ công chức năng bao gồm lực trên Lớp 1 ** và các yêu cầu giao dịch bị bộ sắp xếp bỏ qua sẽ buộc được nhóm vào Hộp thư đến Trình tự hộp nhanh, sau đó chúng sẽ được giám sát bởi tất cả các Nút Arbitrum One và sẽ bị buộc đưa vào chuỗi giao dịch Lớp 2.

Như chúng tôi đã đề cập trước đó, dữ liệu trong hộp nhanh là thực thể dữ liệu lịch sử của L2. Do đó, trong trường hợp kiểm duyệt độc hại, ** cuối cùng có thể bao gồm các hướng dẫn giao dịch trong sổ cái L2 thông qua hộp chậm, bao gồm các tình huống như rút tiền bắt buộc để thoát khỏi Lớp 2. **

Từ đó có thể thấy rằng đối với bất kỳ hướng và cấp độ giao dịch nào, trình sắp xếp chuỗi cuối cùng sẽ không thể xem xét bạn vĩnh viễn.

Một số chức năng cốt lõi của Slowbox Inbox:

• depositETH (), hàm đơn giản nhất để gửi ETH.
• createRetryableTicket(), có thể được sử dụng để gửi ETH và ERC20 cũng như tin nhắn. So với depositETH (), nó có tính linh hoạt cao hơn, chẳng hạn như khả năng chỉ định địa chỉ nhận của L2 sau khi gửi tiền.
• forceInclusion(), là hàm tổng hợp cưỡng bức, có thể được gọi bởi bất kỳ ai. Chức năng này xác minh xem một giao dịch được gửi đến hợp đồng Slowbox chưa được xử lý sau 24 giờ. Nếu các điều kiện được đáp ứng, tin nhắn sẽ bị tổng hợp cưỡng bức.

Tuy nhiên, cần lưu ý rằng hàm force Inclusion thực chất nằm trong hợp đồng Slowbox, chỉ để dễ hiểu hơn, chúng ta sẽ đặt nó ở đây trong Slowbox và cùng nhau giải thích.

Hộp thư đi

Outbox chỉ liên quan đến rút tiền, có thể hiểu là hệ thống hồ sơ và quản lý hành vi rút tiền:**

• Chúng tôi biết rằng việc rút tiền từ cầu nối chính thức của Trọng tài cần đợi kết thúc thời gian thử thách khoảng 7 ngày trước khi việc rút tiền có thể được thực hiện sau khi Khối tổng hợp được hoàn tất. Vào cuối giai đoạn thử thách, người dùng gửi Bằng chứng Merkle tương ứng cho hợp đồng Hộp thư đi trên Lớp 1, giao tiếp với các hợp đồng chức năng khác (chẳng hạn như mở khóa tài sản bị khóa trong các hợp đồng khác) và cuối cùng hoàn tất việc rút tiền.
• Hợp đồng OutBox sẽ ghi lại các tin nhắn tương tác chuỗi chéo từ L2 đến L1 đã được xử lý để ngăn ai đó liên tục gửi yêu cầu rút tiền đã thực hiện. Nó sử dụng ánh xạ (uint256 = > bytes32) spen công cộng để ghi lại Chỉ mục đã chi tiêu của yêu cầu rút tiền và sự tương ứng giữa các thông tin, nếu ánh xạ[spentIndex] != bytes32(0), yêu cầu đã được rút. Nguyên tắc tương tự như nonce truy cập giao dịch ngăn chặn các cuộc tấn công phát lại.

Dưới đây chúng tôi sẽ lấy ETH làm ví dụ để giải thích đầy đủ quá trình gửi và rút tiền. Sự khác biệt giữa ERC20 và ERC20 là nó chỉ đi qua Gateway, vì vậy tôi sẽ không lặp lại nó.

ETH tiền gửi

1. Người dùng gọi hàm depositETH() của Slowbox.

2. Hàm sẽ tiếp tục gọi bridge.enqueueDelayedMessage(), ghi lại thông điệp trong hợp đồng cầu nối và gửi ETH đến hợp đồng bridge. **Tất cả các khoản tiền gửi ETH được giữ trong hợp đồng cầu nối, tương đương với Địa chỉ gửi tiền. **

3. Trình tự lắng nghe thông báo gửi tiền trong hộp chậm và phản ánh hoạt động gửi tiền vào cơ sở dữ liệu L2, để người dùng có thể xem tài sản họ đã gửi vào mạng L2.

4. Người giải trình tự sẽ đưa hồ sơ đặt cọc vào lô và nộp cho hợp đồng Chuyển phát nhanh trên L1.

ETH rút tiền

1. Người dùng gọi hàm withdrawEth() của hợp đồng ArbSys trên L2 để ghi số lượng ETH tương ứng trên L2.

2. Trình sắp xếp chuỗi gửi yêu cầu rút tiền đến Quickbox.

**3.Nút xác thực tạo Khối tổng hợp mới dựa trên trình tự giao dịch trong Hộp nhanh, sẽ chứa các giao dịch rút tiền ở trên. **

4. Sau khi Rollup Block đã vượt qua giai đoạn thử thách và được xác nhận, người dùng có thể gọi hàm Outbox.ute Transaction() trên L1 để chứng minh rằng các tham số được đưa ra bởi hợp đồng ArbSys nói trên.

5. Sau khi hợp đồng Outbox xác nhận rằng nó là chính xác, số lượng ETH tương ứng trong cầu nối đã mở khóa sẽ được gửi đến người dùng.

Thanh toán nhanh

** Việc rút tiền bằng cách sử dụng cầu nối chính thức của Optimistic Rollup sẽ dẫn đến thời gian chờ đợi cho thời gian thử thách. Chúng tôi có thể giải quyết vấn đề này bằng các cầu nối Tương tác chuỗi chéo của bên thứ ba riêng tư:**

• Hoán đổi khóa nguyên tử. Phương pháp này chỉ cho phép hai bên hoán đổi tài sản trong chuỗi tương ứng của họ và nó là nguyên tử, miễn là một bên cung cấp Preimage, cả hai bên chắc chắn sẽ nhận được tài sản mà họ xứng đáng. Nhưng vấn đề là thanh khoản tương đối khan hiếm, và cần phải tìm đối tác ngang hàng.
• Chứng kiến cầu nối tương tác xuyên chuỗi. **Loại cầu tương tác chuỗi chéo chung là cầu nhân chứng. Người dùng gửi yêu cầu rút tiền của riêng họ cho nhà điều hành cầu nối hoặc nhóm thanh khoản của bên thứ ba. Sau khi nhân chứng phát hiện ra rằng tương tác xuyên chuỗi đã được gửi đến hợp đồng hộp nhanh L1, anh ta có thể trực tiếp chuyển tiền cho người dùng ở phía L1. Cách tiếp cận này về cơ bản sử dụng một hệ thống đồng thuận khác để giám sát Lớp 2 và hoạt động trên dữ liệu mà nó đã cam kết với Lớp 1. **Vấn đề là hệ số an toàn trong chế độ này không cao như cầu Rollup chính thức. **

Thanh toán bắt buộc

force Inclusion() được sử dụng để chống lại sự kiểm duyệt của trình tự và có thể được sử dụng cho bất kỳ giao dịch cục bộ L2, L1-to-L2 và L2-to-L1 nào. Sự kiểm duyệt độc hại của trình sắp xếp chuỗi đã ảnh hưởng nghiêm trọng đến trải nghiệm giao dịch và trong hầu hết các trường hợp, chúng tôi sẽ chọn rút và rời khỏi L2, vì vậy sau đây là một ví dụ về việc rút tiền bắt buộc để giới thiệu việc sử dụng forceInclusion.

** Hãy nhớ lại rằng trong bước rút tiền ETH, chỉ có bước 1 và 2 liên quan đến việc xem xét trình tự, vì vậy chỉ cần thay đổi hai bước sau: **

• Gọi inbox.sendL2Message() trong hợp đồng slowbox trên L1, và tham số input là tham số cần nhập khi gọi withdrawEth() trên L2. Tin nhắn được chia sẻ với hợp đồng cầu trên L1.
• Sau khi chờ đợi thời gian chờ tổng hợp cưỡng bức 24 giờ, hãy gọi lực lượng Bao gồm () trong hộp nhanh để buộc bộ sưu tập và hợp đồng hộp nhanh sẽ kiểm tra xem có thông báo tương ứng trong cầu nối hay không.

Người dùng cuối có thể rút tiền trong Hộp thư đi và các bước còn lại giống như rút tiền thông thường.

Ngoài ra, arbitrum-tutorials cũng có hướng dẫn chi tiết về cách sử dụng Arb SDK để hướng dẫn người dùng cách sử dụng forceInclusion() để thực hiện các giao dịch cục bộ L2 và các giao dịch L2 đến L1.