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

Arbitrum xử lý các giao dịch nhắn tin xuyên chuỗi và chống kiểm duyệt như thế nào? Mô hình cầu chuỗi chéo của nó là gì?

Người viết: Luo Benben, cựu đại sứ kỹ thuật của Arbitrum và cộng tác viên đam mê web3

Trong bài viết trước* “Cựu Đại sứ kỹ thuật Arbitrum diễn giải cấu trúc thành phần của Arbitrum (Phần 1)”**, chúng tôi đã giới thiệu trình sắp xếp thứ tự, Trình xác thực, hợp đồng Hộp thư đến trình tự sắp xếp, 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 Arbitrum Trong bài viết hôm nay, chúng tôi sẽ tập trung vào các thành phần liên quan đến nhắn tin chuỗi chéo và lối vào giao dịch chống kiểm duyệt trong số các thành phần cốt lõi của Arbitrum. *

Trong bài viết trước, chúng tôi đã đề cập rằng hợp đồng Hộp thư đến tuần tự đặc biệt nhận gói dữ liệu giao dịch Batch do trình tuần tự xuất bản trên Lớp1. Đồng thời, chúng tôi chỉ ra rằng Hộp thư đến theo trình tự còn được gọi là hộp nhanh, trái ngược với hộp chậm Hộp thư đến bị trì hoãn (gọi tắt là Hộp thư đến). Dưới đây, chúng tôi sẽ giải thích chi tiết về các thành phần liên quan đến nhắn tin chuỗi chéo, chẳng hạn như Hộp thư đến bị trì hoãn.

Nguyên tắc liên chuỗi và bắc cầu

Các giao dịch xuyên chuỗi có thể được chia thành L1 đến L2 (nạp tiền) và L2 đến L1 (rút tiền). Lưu ý rằng việc nạp và rút tiền được đề cập ở đây không nhất thiết liên quan đến tài sản xuyên chuỗi, nhưng có thể là tin nhắn không trực tiếp bao gồm tài sản. Vì vậy, hai từ này chỉ đại diện cho hai hướng hành vi liên quan đến chuỗi chéo.

So với các giao dịch L2 thuần túy, các giao dịch xuyên chuỗi trao đổi thông tin ở hai hệ thống khác nhau là L1 và L2 nên quy trình phức tạp hơn.

Ngoài ra, cái mà chúng ta thường gọi là hành vi chuỗi chéo là chuỗi chéo trên hai mạng không liên quan bằng cách sử dụng cầu nối chuỗi chéo chế độ chứng kiến. Tính bảo mật của chuỗi chéo này phụ thuộc vào cầu nối chuỗi chéo. Những cây cầu dây xích 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 chuỗi chéo giữa Rollup và mạng chính ETH về cơ bản khác với chuỗi chéo nêu trên, vì trạng thái của Layer2 được xác định bởi dữ liệu được ghi trên Layer1,** miễn là bạn đang sử dụng Rollup chính thức. cầu chuỗi chéo tuyệt đối an toàn trong cơ cấu vận hành. **

Điều này cũng làm nổi bật bản chất của Rollup, nó chỉ trông giống như một chuỗi độc lập từ góc nhìn của người dùng, 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 Rollup mở cho người dùng. vẫn bị ghi trên Layer1. **Vì vậy, chúng ta có thể coi L2 là một nửa chuỗi hoặc “chuỗi được tạo trên Lớp 1”.

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

Cần lưu ý rằng cá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 xác nhận giao dịch như trên một chuỗi, cũng như không thể đả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 đó, chuỗi chéo có thể thất bại do một số vấn đề phần mềm, nhưng miễn là sử dụng đúng phương tiện, chẳng hạn như Vé có thể thử lại, các vấn đề khó như kẹt tiền sẽ không xảy ra.

**Vé có thể thử lại là công cụ cơ bản được sử dụng khi gửi tiền qua cầu nối chính thức của Arbitrum ** Cả hai khoản tiền gửi ETH và ERC20 sẽ đượ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 Hộp thư đến bị trì hoãn để tạo vé nạp tiền và gửi nó.

**2. Tự động đổi quà trên L2. **Trong hầu hết các trường hợp, máy phân loại có thể tự động giúp người dùng thanh toán hóa đơn mà không cần thực hiện các thao tác thủ công tiếp theo.

**3. Đổi thủ công trên L2. **Trong một số trường hợp đặc biệt, chẳng hạn như giá gas tăng đột ngột trên L2 và lượng gas trả trước trên vé không đủ, thanh toán tự động không thể được thực hiện. Tại thời điểm này, người dùng cần phải vận hành thủ công.

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

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

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

Cổng liên chuỗi tài sản ERC-20

Tài sản ERC-20 chuỗi chéo rất phức tạp. Chúng ta có thể nghĩ về một số câu hỏi:

• Token được triển khai trên L1, làm cách nào để triển khai nó trên L2?
• Hợp đồng tương ứng L2 của nó có cần được triển khai trước theo cách thủ công hay hệ thống có thể tự động triển khai hợp đồng tài sản cho các mã thông báo đã chuyển đổi nhưng chưa triển khai hợp đồng không?
• Đối với tài sản ERC-20 trên L1, địa chỉ hợp đồng tương ứng trên L2 là gì? Nó có phù hợp với L1 không?
• Làm cách nào để phát hành mã thông báo chuỗi chéo từ L2 đến L1?
• Làm thế nào các mã thông báo có chức năng đặc biệt, chẳng hạn như mã thông báo rebase với số lượng có thể điều chỉnh và mã thông báo có lãi tự phát triển, có thể được liên kết chéo?

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

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

**Arbitrum sử dụng hệ thống Cổng để giải quyết hầu hết các điểm yếu của chuỗi chéo ERC20. **Nó có 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, ** và ánh xạ giữa một số mã thông báo<->một số cổng.
• Bản thân 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 và chức năng khác nhau của các vấn đề bắc cầu ERC20.

Hãy lấy 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 việc tùy chỉnh cổng.

WETH là ERC20 tương đương với ETH. Là loại tiền tệ chính, Ether không thể thực hiện các chức năng phức tạp trong nhiều dApp, do đó cần 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à số lượng WETH tương tự sẽ được tạo ra.

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

Nếu bây giờ chúng ta liên kết chéo trực tiếp WETH với L2, chúng ta sẽ thấy một số vấn đề lạ:

• Không thể Unwrap WETH vào ETH trên L2 vì không có ETH tương ứng để khóa trên L2.
• Có thể sử dụng hàm Wrap, nhưng nếu các WETH mới được tạo này được chuyển trở lại L1, thì chúng không thể được giải mã thành ETH trên 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 nguyên tắc thiết kế của WETH. **Sau đó, khi WETH là chuỗi chéo, cho dù là nạp hay rút, trước tiên nó cần được mở vào ETH, sau đó chuyển sang phía bên kia và sau đó được gói vào WETH. **Đây là vai trò của WETH Gateway.

Điều tương tự cũng xảy ra với các mã thông báo khác có logic phức tạp hơn, yêu cầu Cổng được thiết kế cẩn thận và phức tạp hơn để hoạt động chính xác trong môi trường chuỗi chéo. Cổng tùy chỉnh của Arbitrum kế thừa logic giao tiếp chuỗi chéo của Cổng thông thường và cho phép các nhà phát triển tùy chỉnh hành vi 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

Tương ứng với hộp thư nhanh hay còn gọi là SequencerInbox là hộp thư chậm Inbox (tên đầy đủ Delayed Inbox)**. Tại sao phải có sự phân biệt giữa tốc độ và sự chậm chạp? Vì hộp nhanh được dành riêng để nhận lô giao dịch L2 do trình sắp xếp chuỗi phát hành nên tất cả các giao dịch chưa được trình sắp xếp chuỗi xử lý trước 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 lại từ L1 đến L2. **Người dùng nạp tiền thông qua hộp chậm và trình sắp xếp thứ tự sẽ theo dõi nó rồi phản ánh nó trên L2. Cuối cùng, bản ghi nạp tiền sẽ được trình sắp xếp trình tự đưa vào trình tự giao dịch L2 và gửi tới Hộp thư đến của trình sắp xếp hợp đồng hộp nhanh.

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 hộp chuyển phát nhanh là không phù hợp vì các giao dịch được gửi tới hộp chuyển phát nhanh Hộp thư đến tuần tự sẽ cản trở việc sắp xếp giao dịch thông thường của Lớp 2 và sau đó ảnh hưởng đến công việc của trình sắp xếp.

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

Nếu một giao dịch được gửi đến Hộp thư đến bị trì hoãn và sau 24 giờ, giao dịch trong hộp chậm chưa được trình sắp xếp thứ tự đưa vào chuỗi 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 lượng trên Lớp 1, ** để bỏ qua nó bởi trình sắp xếp chuỗi. Các yêu cầu giao dịch bị buộc phải thu thập vào Hộp thư đến của Trình sắp xếp và sau đó 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 vừa đề cập, 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, các hướng dẫn giao dịch cuối cùng có thể được đưa vào sổ cái L2 thông qua hộp chậm, bao gồm các tình huống như buộc phải rút tiền và thoát khỏi Lớp 2. **

Có thể thấy từ điều này rằng đối với các giao dịch theo bất kỳ hướng và cấp độ nào, trình sắp xếp 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 Hộp thư đến chậm:

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

Tuy nhiên, cần lưu ý rằng chức năng Bao gồm lực thực chất nằm trong hợp đồng hộp nhanh, để cho dễ hiểu, chúng tôi sẽ cùng nhau giải thích trong hộp chậm.

Hộp thư đi Hộp thư đi

Outbox chỉ liên quan đến việc rút tiền và có thể hiểu là hệ thống ghi chép và quản lý việc rút tiền:

• Chúng tôi biết rằng việc rút tiền từ cầu chính thức của Arbitrum cần phải đợi khoảng 7 ngày để kết thúc thời gian thử thách và Khối tổng hợp sẽ được hoàn tất trước khi việc rút tiền có thể được thực hiện. Sau khi thời gian thử thách kết thúc, 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, sau đó liên lạc với các hợp đồng để thực hiện các 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 chuỗi chéo từ L2 đến L1 đã được xử lý để ngăn ai đó gửi liên tục các yêu cầu rút tiền đã thực hiện. nó đi
• ánh xạ (uint256 => byte32) chi tiêu công khai, ghi lại sự tương ứng giữa Chỉ số chi tiêu của yêu cầu rút tiền và thông tin, nếu ánh xạ [spentIndex] != bytes32(0) thì yêu cầu đã bị hủy. Nguyên tắc tương tự như bộ đếm giao dịch Nonce để ngăn chặn các cuộc tấn công lặp lại.

Dưới đây chúng tôi sẽ lấy ETH làm ví dụ để giải thích đầy đủ về quy trình gửi và rút tiền. Điểm khác biệt duy nhất giữa ERC20 và Gateway là nó sẽ không được mô tả chi tiết.

Gửi ETH

1. Người dùng gọi hàm DepositETH() của hộp chậm.

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

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

4. Trình sắp xếp thứ tự bao gồm bản ghi nạp tiền vào lô giao dịch và gửi nó vào hợp đồng hộp nhanh trên L1.

Rút ETH

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

2. Trình sắp xếp thứ tự gửi yêu cầu rút tiền đến hộp thư chuyển phát nhanh.

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

4. Sau khi Khối tổng hợp 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 đã đề cập ở trên.

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

Rút tiền nhanh chóng

**Nếu bạn sử dụng cầu chính thức Optimistic Rollup để rút tiền mặt, sẽ có vấn đề phải chờ thời gian thử thách. Chúng tôi có thể sử dụng cầu nối chuỗi chéo riêng tư của bên thứ ba để khắc phục sự cố này: **

• Trao đổi khóa nguyên tử. Phương thức này chỉ trao đổi tài sản giữa hai bên trong chuỗi tương ứng của họ và là phương thức nguyên tử, chỉ cần 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à tính thanh khoản tương đối khan hiếm và bạn cần tìm đối tác trực tiếp.
• **Chứng kiến cây cầu xuyên xích. **Các loại cầu xuyên chuỗi thông thường là cầu chứng kiến. Người dùng gửi yêu cầu rút tiền của riêng họ và điểm đích rút tiền sẽ trỏ đến nhà điều hành cầu nối bên thứ ba hoặc nhóm thanh khoản. Sau khi nhân chứng phát hiện ra rằng giao dịch chuỗi chéo đã được gửi tới hợp đồng hộp nhanh của L1, anh ta có thể chuyển tiền trực tiếp 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 dựa trên dữ liệu mà nó đã gửi lên Lớp 1. **Vấn đề là hệ số an toàn ở chế độ này không cao bằng cầu Rollup chính thức. **

Buộc rút tiền

Force Inclusion() Hàm bao gồm lực được sử dụng để chống lại việc xem xét trình sắp xếp thứ tự. Bất kỳ giao dịch cục bộ L2, giao dịch L1 đến L2 và giao dịch L2 đến L1 nào cũng có thể được thực hiện bằng chức năng này. Việc đánh giá ác ý 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, trong hầu hết các trường hợp, chúng tôi sẽ chọn rút tiền và để lại L2. Do đó, những điều sau đây sử dụng việc buộc rút tiền làm ví dụ để giới thiệu cách sử dụng ForceInclusion.

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

• Gọi inbox.sendL2Message() trong hợp đồng hộp chậm trên L1. Tham số đầu vào là tham số cần nhập khi gọirútEth() trên L2. Thông báo này sẽ được chia sẻ với hợp đồng bridge trên L1.
• Sau khi chờ khoảng thời gian chờ bao gồm bắt buộc là 24 giờ, hãy gọi Force Inclusion() trong hộp nhanh để thực hiện việc đưa vào bắt buộc. 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 Outbox 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òn 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 thực hiện các giao dịch cục bộ L2 và giao dịch L2 đến L1 thông qua ForceInclusion().