Trong bài viết trước, “Cấu trúc thành phần của Arbitrum do Cựu Đại sứ kỹ thuật của Arbitrum giải thích (Phần 1),” chúng tôi đã giới thiệu vai trò của các thành phần chính trong Arbitrum, bao gồm trình sắp xếp thứ tự, trình xác thực, hợp đồng hộp thư đến của trình sắp xếp thứ tự, khối cuộn lên và vai trò của bằng chứng gian lận không tương tác. Trong bài viết hôm nay, chúng tôi sẽ tập trung giải thích các thành phần liên quan đến việc truyền thông điệp xuyên chuỗi và mục nhập cho các giao dịch chống kiểm duyệt trong các thành phần cốt lõi của Arbitrum.

Nội dung chính: Trong các bài viết trước, chúng tôi đã đề cập rằng hợp đồng Hộp thư đến theo trình tự được thiết kế đặc biệt để nhận các lô dữ liệu giao dịch do trình sắp xếp trình tự xuất bản trên Lớp 1. Đồ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” và ngược lại, có “hộp chậm” hoặc 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 việc truyền tin nhắn xuyên chuỗi, bao gồm cả 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 các giao dịch từ L1 đến L2 (gửi tiền) và giao dịch từ L2 đến L1 (rút tiền). Điều quan trọng cần lưu ý là các thuật ngữ “gửi tiền” và “rút tiền” ở đây có thể không nhất thiết liên quan đến việc chuyển tài sản xuyên chuỗi; họ có thể đề cập đến việc truyền tin nhắn mà không trực tiếp chuyển giao tài sản. Do đó, những thuật ngữ này chỉ thể hiện hai hướng của các hành động 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 liên quan đến việc trao đổi thông tin giữa hai hệ thống khác nhau, L1 và L2, khiến quy trình trở nên phức tạp hơn.

Ngoài ra, khi chúng ta nói về các hành động xuyên chuỗi, nó thường đề cập đến việc giao thoa giữa hai mạng hoàn toàn không liên quan bằng cách sử dụng cầu nối chuỗi chéo trong mô hình liên kết. Tính bảo mật của các hoạt động chuỗi chéo như vậy phụ thuộc vào người vận hành cầu nối chuỗi chéo và trong lịch sử, các sự cố trộm cắp thường xảy ra ở các cầu nối chuỗi chéo dựa trên nhân chứng.

Mặt khác, các hành động chuỗi chéo giữa Rollup và mạng chính ETH về cơ bản khác với các quy trình chuỗi chéo nói trên. Điều này là do 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 sử dụng cầu nối chuỗi chéo Rollup chính thức, nó sẽ có cấu trúc an toàn trong hoạt động.

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

Có thể thử lại

Xin lưu ý rằng các giao dịch chuỗi chéo là không đồng bộ và không nguyên tử. Không giống như các giao dịch trên một chuỗi, việc hoàn thành giao dịch và xác nhận kết quả sau một giao dịch trên một chuỗi là không thể thực hiện được trong các giao dịch xuyên chuỗi. Cũng không có gì đảm bảo rằng điều gì đó cụ thể sẽ xảy ra ở phía bên kia vào một thời điểm nhất định. Do đó, các giao dịch xuyên chuỗi có thể không thành công do một số vấn đề phần mềm, nhưng với việc sử dụng các kỹ thuật phù hợp, chẳng hạn như phiếu có thể 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ông cụ cơ bản được sử dụng trong cầu nối chính thức của Arbitrum trong quá trình gửi tiền, áp dụng cho cả tiền gửi ETH và ERC20. Vòng đời bao gồm 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 phiếu gửi tiền và gửi nó.
2. Tự động đổi vé trên L2: Trong hầu hết các trường hợp, trình sắp xếp thứ tự có thể tự động đổi vé cho người dùng mà không yêu cầu thêm thao tác thủ công.
3. Đổi thủ công trên L2: Trong một số trường hợp cực đoan nhất định, chẳng hạn như giá xăng tăng đột ngột trên L2, nếu lượng xăng trả trước trên vé không đủ thì việc quy đổi tự động không thể xảy ra. Trong trường hợp này, sự can thiệp thủ công của người dùng là cần thiết. Điều quan trọng cần lưu ý là nếu việc đổi vé tự động không thành công, người dùng cần đổi vé theo cách thủ công trong vòng 7 ngày; nếu không, vé sẽ bị xóa (dẫn đến mất tiền vĩnh viễn) hoặc người dùng cần phải trả một khoản phí nhất định để gia hạn việc lưu trữ vé.

Hơn nữa, liên quan đến quy trình rút tiền trên cầu chính thức của Arbitrum, mặc dù có sự tương đồng đối xứng nhất định trong quy trình so với tiền gửi nhưng không có khái niệm về vé có thể thử lại. Điều này có thể được hiểu từ góc độ của chính giao thức Rollup và một số điểm khác biệt có thể được nêu bật:

• Không có quy đổi tự động trong quá trình rút tiền vì EVM không có bộ tính giờ hoặc tự động hóa. Trên L2, việc quy đổi tự động có thể được thực hiện và được hỗ trợ bởi trình sắp xếp thứ tự. Do đó, 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 để lấy lại tài sản của mình.
• Không có vấn đề hết hạn vé trong quá trình rút tiền. Miễn là thời gian thử thách đã trôi qua, người dùng có thể yêu cầu tài sản của mình bất cứ lúc nào.

Cổng chuỗi chéo cho tài sản ERC-20

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

• cách triển khai mã thông báo được triển khai trên L1 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 các mã thông báo được phát hành tự nhiên trên L2 có thể được liên kết chéo với 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ể khám phá. 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 quy mô sử dụng giải pháp danh sách trắng và 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 Gateway để giải quyết hầu hết các vấn đề vướng mắc 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.
• Gateway Router chịu trách nhiệm duy trì việc ánh xạ địa chỉ giữa Token L1<->Token L2. Ngoài ra, việc á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 ERC20 tiêu chuẩn, 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ị đốt và ETH có thể bị rút. Rõ ràng, tỷ lệ WETH lưu hành và ETH bị khóa luôn là 1:1.

Nếu bây giờ chúng ta chuyển trực tiếp chuỗi WETH sang 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, 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. Do đó, khi WETH được liên kết chéo, cho dù là gửi hay rút tiền, 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

Bản sao của hộp thư đến nhanh, được gọi là Hộp thư đến tuần tự, là hộp thư đến chậm (có tên đầy đủ là Hộp thư đến bị trì hoãn). Tại sao phải phân biệt nhanh và chậm? Điều này là do hộp thư đến nhanh được dành riêng để nhận các lô giao dịch L2 do trình sắp xếp thứ tự xuất bản và mọi giao dịch không được trình sắp xếp thứ tự xử lý trước trong mạng L2 sẽ không xuất hiện trong hợp đồng hộp thư đến nhanh.

Chức năng đầu tiên của hộp thư đến chậm là xử lý quá trình gửi tiền từ L1 đến L2. Người dùng bắt đầu gửi tiền thông qua hộp thư đến chậm và khi trình sắp xếp thứ tự quan sát thấy điều này, nó sẽ phản ánh trên L2. Cuối cùng, bản ghi tiền gửi này được trình sắp xếp thứ tự đưa vào chuỗi giao dịch L2 và gửi đến hợp đồng hộp thư đến nhanh (Hộp thư đến trình tự sắp xếp).

Trong trường hợp này, việc người dùng gửi trực tiếp các giao dịch gửi tiền đến hộp thư đến nhanh (Hộp thư đến tuần tự) là không phù hợp vì các giao dịch được gửi đến hộp thư đến nhanh có thể làm gián đoạn thứ tự giao dịch thông thường trong Lớp 2, do đó ảnh hưởng đến hoạt động của trình sắp xếp thứ tự.

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

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 đó vẫn chưa được trình sắp xếp thứ tự hợp nhất vào chuỗi giao dịch, thì người dùng có thể kích hoạt chức năng bao gồm lực lượng trên Lớp1 theo cách thủ công. Hành động này buộc các giao dịch bị trình sắp xếp thứ tự bỏ qua buộc phải được tổng hợp vào hộp thư đến nhanh (Hộp thư đến theo trình tự). Sau đó, chúng sẽ được tất cả các nút Arbitrum One phát hiện và được đưa vào chuỗi giao dịch Lớp2 một cách mạnh mẽ.

Chúng tôi vừa đề cập rằng dữ liệu trong hộp thư đến nhanh đại diện cho 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, việc sử dụng hộp thư đến chậm cho phép các hướng dẫn giao dịch cuối cùng được đưa vào sổ cái L2, bao gồm các tình huống như buộc phải rút tiền để thoát khỏi Lớp2.

Từ đó, có thể thấy rằng đối với bất kỳ hướng và mức độ giao dịch nào, trình sắp xếp chuỗi cuối cùng không thể kiểm duyệ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 (Inbox):

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

Tuy nhiên, điều quan trọng cần lưu ý là chức năng ép buộc thực sự nằm trong hợp đồng hộp thư đến nhanh. Để dễ hiểu, chúng tôi đã giải thích vấn đề này cùng với hộp thư đến chậm.

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 nhận và quản lý các hành vi rút tiền:

• Chúng tôi biết rằng việc rút tiền trên cầu chính thức của Arbitrum cần phải đợi khoảng 7 ngày để thời gian thử thách kết thúc và việc rút tiền chỉ có thể được thực hiện sau khi Khối tổng hợp được hoàn tất. 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ó ghi lại sự tương ứng giữa Chỉ số chi tiêu và thông tin về yêu cầu rút tiền bằng cách sử dụng 'ánh xạ (uint256 => byte32) chi tiêu công khai'. Nếu ánh xạ[spentIndex] != bytes32(0), yêu cầu đã bị rút lại. Nguyên tắc này 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. Sự khác biệt duy nhất giữa ERC20 và ETH là ERC20 trước đây sử dụng Gateway. Chúng tôi sẽ không giải thích chi tiết.

Tiền 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 cầu nối và gửi ETH đến hợp đồng cầu nối. Tất cả tiền gửi ETH được giữ trong hợp đồng bắc cầu, tương đương với địa chỉ gửi tiền.

3. Trình sắp xếp thứ tự giám sát các 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 trên mạng L2.

4. Trình sắp xếp thứ tự bao gồm bản ghi tiền gửi 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àm drawEth() của hợp đồng ArbSys trên L2 và số ET tương ứng sẽ được ghi trên L2.

2. Trình sắp xếp thứ tự sẽ gửi yêu cầu rút tiền đến hộp 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, khối này sẽ chứa các giao dịch rút tiền ở trên.

4. Sau khi Khối tổng hợp trải qua giai đoạn thử thách cũng đã được xác nhận, người dùng có thể gọi hàm Outbox.execute 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 bridge sẽ được mở khóa và gửi đến người dùng.

Rút tiền mặt nhanh chóng

Khi sử dụng cầu chính thức Optimistic Rollup để rút tiền mặt, sẽ xảy ra 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 để loại bỏ vấn đề 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à mang tính 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 có được. 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 bằng phương thức ngang hàng.F
• Nhân chứng đi qua cầu dây xích. Các loại cầu xuyên xích 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 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 đến Lớp 1. Vấn đề là mức độ bảo mật ở chế độ này không cao bằng mức độ bảo mật của cầu nối Rollup chính thức. \

Buộc rút tiền

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

Nhìn lại các bước rút ETH, chỉ có bước 1 và 2 liên quan đến kiểm duyệt trình tự sắp xếp nên chỉ cần thay đổi 2 bước này:

• Khi 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 khoảng thời gian chờ 24 giờ bắt buộc đưa vào, Force Inclusion() trong hộp nhanh được gọi để 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, còn có hướng dẫn chi tiết về cách sử dụng Arb SDK trong arbitrum-tutorials để 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 hàm ForceInclusion().

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được in lại từ [极客 Web3]. Mọi bản quyền đều thuộc về tác giả gốc [极客 Web3]. Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Gate Learn , họ sẽ xử lý kịp thời.
2. Tuyên bố miễn trừ trách nhiệm pháp lý: Các quan điểm và ý kiến trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Việc dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch đều bị cấm.