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 trình sắp xếp đượ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”, tương ứng là Hộp thư đến bị trì hoãn (gọi tắt là Hộp thư đến). Tiếp theo, 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, 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 (gửi tiền) và L2 đến L1 (rút tiền). Lưu ý rằng việc gửi 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à thông điệp 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. Trong lịch sử, các cây cầu xuyên chuỗi dựa trên chế độ nhân chứng thường xuyên gặp phải các vụ trộm cắp.

Ngược lại, hành vi chuỗi chéo giữa Rollup và mạng chính Ethereum về cơ bản khác với các hoạt động chuỗi chéo nói trên. Điều này là do 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 chuỗi chéo Rollup chính thức, cấu trúc hoạt động của nó được đảm bảo tuyệt đối.

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

Có thể thử lại

Điều quan trọng cần lưu ý là các hoạt động xuyên chuỗi không đồng bộ và không mang tính nguyên tử. Không giống như trên một chuỗi nơi kết quả của giao dịch được biết sau khi được xác nhận, các giao dịch xuyên chuỗi không thể đảm bảo rằng một số sự kiện nhất định sẽ xảy ra ở phía bên kia tại một thời điểm cụ thể. Do đó, các giao dịch chuỗi chéo có thể không thành công do các vấn đề phần mềm, nhưng với các phương pháp chính xác, chẳng hạn như Vé có thể thử lại, sẽ không có bất kỳ vấn đề nào như tiền bị kẹt.

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

1. Gửi vé trên L1: Tạo một phiếu gửi tiền bằng phương thức createRetryableTicket() trong hợp đồng Hộp thư đến bị trì hoã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 cần can thiệp thủ công thêm.

3. Đổi thủ công trên L2: Trong một số trường hợp nhất định, chẳng hạn như giá xăng tăng đột ngột trên L2 khi lượng xăng trả trước trên vé không đủ, việc đổi quà tự động có thể không thành công. Trong những trường hợp như vậy, cần có sự can thiệp thủ công của người dùng. Lưu ý rằng nếu quy đổi tự động không thành công, vé phải được quy đổi thủ công trong vòng 7 ngày; nếu không, vé có thể bị xóa (dẫn đến mất tiền vĩnh viễn) hoặc yêu cầu thanh toán một khoản phí để gia hạn hợp đồng thuê.

Hơn nữa, trong quy trình rút tiền của cầu chính thức Arbitrum, mặc dù có một số điểm tương đồng đối xứng với hành vi gửi tiền về mặt quy trình, nhưng không có khái niệm về Retryables. Điều này có thể được hiểu từ góc độ của chính giao thức Rollup và bằng cách kiểm tra một số điểm 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ộ tính giờ hoặc tự động hóa. Mặc dù việc quy đổi tự động có thể được triển khai trên L2 với sự hỗ trợ của trình sắp xếp thứ tự, nhưng 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 để yêu cầu tài sản của họ.

• Cũng không có vấn đề hết hạn vé khi rút tiền; miễn là thời gian thử thách đã qua, tài sản có thể được yêu cầu bất cứ lúc nào.

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

Các giao dịch chuỗi chéo liên quan đến tài sản ERC-20 rất phức tạp. Chúng ta có thể xem xét một số câu hỏi:

• Mã thông báo được triển khai trên L2 như thế nào nếu nó được triển khai trên L1?
• Hợp đồng tương ứng của nó trên L2 có nê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 đã được chuyển nhưng chưa được triển khai không?
• Địa chỉ hợp đồng của tài sản ERC-20 trên L2 tương ứng với địa chỉ của nó trên L1 là gì? Nó có khớp với địa chỉ trên L1 không?
• Làm thế nào các mã thông báo được phát hành tự nhiên trên L2 được liên kết chéo với L1?
• Làm thế nào để tạo ra 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 cung cấp có thể điều chỉnh hoặc mã thông báo đặt cược tự động, chuỗi chéo?

Chúng tôi không có ý định trả lời tất cả những câu hỏi này vì chúng quá phức tạp để có thể giải quyết một cách toàn diện. Những câu hỏi này chỉ nhằm minh họa mức độ phức tạp của các giao dịch chuỗi chéo ERC-20.

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 + 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 giao dịch chuỗi chéo ERC20, có các đặc điểm sau:

• Các thành phần Cổng xuất hiện theo cặp trên cả L1 và L2.
• Gateway Router có trách nhiệm duy trì việc ánh xạ địa chỉ giữa Token L1 <-> Token L2 và một số token <-> một số cổng.
• Bản thân Cổng có thể được chia thành nhiều loại khác nhau, chẳng hạn 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 vấn đề bắc cầu cho các loại và chức năng khác nhau của mã thông báo ERC20.

Để minh họa sự cần thiết của các cổng tùy chỉnh, hãy xem xét một ví dụ tương đối đơn giản về chuyển WETH chuỗi chéo.

WETH là ERC20 tương đương với ETH. Vì Ether đóng vai trò là tiền tệ chính nên nhiều chức năng phức tạp trong dApp không thể đạt được trực tiếp. Do đó, cần có ERC20 tương đương như WETH. Bằng cách gửi một số ETH vào hợp đồng WETH, chúng sẽ bị khóa trong hợp đồng, tạo ra số lượng WETH tương đương.

Tương tự như vậy, WETH có thể được đốt để rút ETH. Rõ ràng, lượng WETH lưu hành và lượng ETH bị khóa sẽ luôn duy trì tỷ 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, thì chúng không thể được mở gói thành ETH trên L1 vì 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 vượt qua chuỗi chéo WETH, dù gửi hay rút, trước tiên cần phải mở chuỗi vào ETH, sau đó chuyển qua và gói lại vào WETH. Đây là lúc Cổng WETH phát huy tác dụng.

Tương tự, đối với các token khác có logic phức tạp hơn, chúng yêu cầu các Cổng được thiết kế tinh vi và cẩn thận hơn để hoạt động bình thường 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 tiêu chuẩn 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, đáp ứng hầu hết các yêu cầu.

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

Bản sao của SequencerInbox, còn được gọi là hộp nhanh, là Hộp thư đến (có tên chính thức là Hộp thư đến bị trì hoãn). Tại sao lại phân biệt hộp nhanh và hộp chậm? Bởi vì hộp nhanh được thiết kế đặc biệt để nhận các lô giao dịch L2 do trình sắp xếp chuỗi xuất bản và mọi giao dịch không đượ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.

Vai trò đầu tiên của hộp chậm là xử lý hành vi gửi tiền từ L1 đến L2. Người dùng bắt đầu gửi tiền thông qua hộp chậm, sau đó trình sắp xếp trình tự sẽ phản ánh trên L2. Cuối cùng, bản ghi tiền gửi này 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 đồng hộp nhanh, SequencerInbox.

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 vào hộp nhanh là không phù hợp vì các giao dịch được gửi tới SequencerInbox sẽ cản trở trình tự giao dịch thông thường của Lớp 2, do đó ảnh hưởng đến hoạt động của trình sắp xếp thứ tự.

Vai trò thứ hai của hộp bị trì hoãn 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 bị trì hoãn thường được trình sắp xếp tổng hợp vào hộp 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, hộp bị trì hoãn có tính năng bao gồm lực lượng:

Nếu một giao dịch được gửi đến Hộp thư đến bị trì hoãn và vẫn chưa được trình sắp xếp thứ tự tổng hợp thành chuỗi giao dịch sau 24 giờ, 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ớp 1 theo cách thủ công. Hành động này buộc các yêu cầu giao dịch bị trình sắp xếp thứ tự bỏ qua phải được tổng hợp vào hộp nhanh, SequencerInbox, và sau đó được phát hiện bởi tất cả các nút Arbitrum One, do đó được đưa vào chuỗi giao dịch Lớp 2 một cách mạnh mẽ.

Như chúng tôi đã đề cập trước đó, dữ liệu trong hộp nhanh thể hiện 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 giao dịch cuối cùng có thể được đưa vào sổ cái L2 bằng cách sử dụng hộp bị trì hoãn, bao gồm các tình huống như buộc phải rút tiền từ Lớp 2.

Từ đó, có thể thấy rằng trình sắp xếp cuối cùng không thể kiểm duyệt vĩnh viễn các giao dịch theo bất kỳ hướng hoặc lớp nào.

Một số chức năng cốt lõi của Hộp thư đến chậm như sau:

• DepositETH(): Hàm này là phương thức đơn giản nhất để gửi ETH.
• createRetryableTicket(): Chức năng này có thể được sử dụng để gửi ETH, mã thông báo ERC20 và tin nhắn. So với DepositETH(), nó mang lại sự linh hoạt cao hơn, chẳng hạn như chỉ định địa chỉ nhận trên L2 sau khi gửi tiền.
• ForceInclusion(): Còn được gọi là hàm bao gồm lực, bất kỳ ai cũng có thể gọi hàm này. Chức năng này 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 điều kiện được đáp ứng, hàm sẽ tổng hợp thông báo một cách mạnh mẽ.

Tuy nhiên, điều quan trọng cần lưu ý là hàm ForceInclusion() thực sự nằm trong hợp đồng hộp nhanh. Để rõ ràng, chúng tôi đã thảo luận vấn đề này ở đây cùng với các chức năng hộp 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 tới 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 ghi lại các tin nhắn chuỗi chéo 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ó đạt được điều này thông qua một ánh xạ có tên là chi tiêu, liên kết các chỉ số chi tiêu của yêu cầu rút tiền với thông tin tương ứng của chúng. Nếu ánh xạ[spentIndex] != bytes32(0), điều đó cho biết rằng yêu cầu đã được rút lại. Nguyên tắc này tương tự như bộ đếm giao dịch nonce, được sử dụng để ngăn chặn các cuộc tấn công lặp lại.

Dưới đây, chúng tôi sẽ giải thích quy trình gửi và rút tiền bằng ETH làm ví dụ. Quy trình dành cho mã thông báo ERC20 cũng tương tự, với việc bổ sung Cổng, nhưng chúng tôi sẽ không trình bày chi tiết về điều đó ở đây.

Tiền gửi ETH

1. Người dùng gọi hàm DepositETH() của Hộp thư đến bị trì hoãn.
2. Hàm này sau đó 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ả số tiền ETH gửi vào đều được giữ trong hợp đồng bắc cầu, hoạt động như một địa chỉ gửi tiền.
3. Trình sắp xếp thứ tự giám sát thông báo gửi tiền trong Hộp thư đến bị trì hoãn và phản ánh hoạt động gửi tiền trong cơ sở dữ liệu L2. Người dùng có thể xem tài sản ký gửi của mình trên mạng L2.
4. Trình sắp xếp thứ tự bao gồm bản ghi tiền gửi trong một loạt giao dịch và gửi nó đến hợp đồng Hộp thư đến 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à đốt số lượng ETH tương ứng 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 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 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.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 nhanh

Sử dụng cây cầu chính thức Rollup lạc quan liên quan đến việc chờ đợi một khoảng thời gian thử thách. Để khắc phục vấn đề này, chúng tôi có thể sử dụng cầu nối chuỗi chéo của bên thứ ba riêng tư:

• Trao đổi hoán đổi nguyên tử: Theo cách tiếp cận này, tài sản được trao đổi giữa các bên trong chuỗi tương ứng của họ và đó là nguyên tử, nghĩa là nếu một bên cung cấp hình ảnh trước, cả hai bên đều có thể nhận được tài sản tương ứng. Tuy nhiên, tính thanh khoản tương đối khan hiếm, đòi hỏi phải tìm kiếm đối tác ngang hàng.
• Cầu chuỗi chéo dựa trên nhân chứng: Hầu hết các loại cầu chuỗi chéo đều thuộc loại này. Người dùng gửi yêu cầu rút tiền của họ, chỉ định đích đến là nhà điều hành hoặc nhóm thanh khoản của cầu nối bên thứ ba. 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 thư đến nhanh trên L1, họ có thể chuyển tiền trực tiếp cho người dùng trên L1. Về cơ bản, phương pháp này sử dụng một hệ thống đồng thuận khác để giám sát Lớp 2 và thực hiện các hoạt động dựa trên dữ liệu được gửi đến Lớp 1. Tuy nhiên, mức độ bảo mật ở chế độ này thấp hơn so với cầu nối chính thức Rollup.

Buộc rút lui

Hàm ForceInclusion() được sử dụng để chống lại việc kiểm duyệt trình tự sắp xếp. Nó có thể được áp dụng cho mọi giao dịch cục bộ L2, giao dịch L1 đến L2 và giao dịch L2 đến L1. Vì hoạt động kiểm duyệt độc hại của trình sắp xếp chuỗi ảnh hưởng đáng kể đến trải nghiệm giao dịch nên chúng tôi thường chọn rút tiền khỏi L2. Dưới đây là ví dụ về việc sử dụng ForceInclusion() để buộc rút tiền:

Trong bối cảnh 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. Vì vậy, chúng ta chỉ cần sửa đổi hai bước sau:

• Gọi inbox.sendL2Message() trong hợp đồng Delayed Inbox trên L1, với các tham số bắt buộc khi gọirútEth() trên L2. Thông báo này được chia sẻ với hợp đồng bridge trên L1.
• Sau khi chờ khoảng thời gian chờ bắt buộc đưa vào là 24 giờ, hãy gọi ForceInclusion() trong hợp đồng Hộp thư đến nhanh để buộc đưa vào. Hợp đồng Fast Inbox sẽ kiểm tra xem có tin nhắn tương ứng trong bridge hay không.

Cuối cùng người dùng có thể rút tiền từ Outbox, các bước còn lại thực hiện tương tự như quy trình rút tiền thông thường.

Ngoài ra, còn có các hướng dẫn chi tiết trong kho hướng dẫn trọng tài hướng dẫn người dùng về cách thực hiện các giao dịch cục bộ L2 và các giao dịch L2 đến L1 bằng cách sử dụng ForceInclusion() thông qua Arb SDK.

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

1. Bài viết này được in lại từ [Geek Web3], Mọi bản quyền thuộc về tác giả gốc [Luo Benben, cựu đại sứ kỹ thuật Arbitrum, cộng tác viên geek 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.