Tiêu đề gốc: "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)"
Tác giả gốc: Luo Benben, cựu đại sứ kỹ thuật Arbitrum, cộng tác viên đam mê Web3
Bài viết này được viết bởi Luo Ben, cựu đại sứ kỹ thuật của Arbitrum và cựu đồng sáng lập kiểm toán tự động hóa hợp đồng thông minh công ty Goplus Security Ben giải thích kỹ thuật về Arbitrum One.
Trong bài viết trước"Giải thích cấu trúc thành phần của Arbitrum (Phần 1)", chúng tôi đã giới thiệu vai trò của trình sắp xếp thứ tự, Trình xác thực, Hợp đồng hộp thư đến trình tự , 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 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 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.

Văn bản: 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 Lô được xuất bản bởi trình tuần tự 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 thư 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.

Các giao dịch chuỗi chéo 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 trong 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 sử dụng cầu nối chuỗi chéo chế độ chứng kiến trên hai mạng không liên quan. Loại chuỗi chéo này. Bảo mật. của chuỗi phụ thuộc vào người vận hành cầu chuỗi chéo Trong lịch sử, hành vi trộm cắp cầu chuỗi chéo dựa trên mô hình nhân chứng đã xảy ra thường xuyên.
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 ghi lại trên Layer1 Được xác định bởi dữ liệu, miễn là bạn đang sử dụng cầu nối chuỗi chéo chính thức của Rollup, cấu trúc hoạt động của nó tuyệt đối an toàn.
Đ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à
Cần lưu ý rằng các chuỗi chéo không đồng bộ và không có tính nguyên tử về mặt tình dục , không thể biết kết quả sau khi xác nhận giao dịch như trên 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 (Vé có thể thử lại), thì 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 nạp tiền qua cầu chính thức của Arbitrum. Chúng được sử dụng cho cả lần nạp ETH và ERC20. . 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, trình sắp xếp 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. Một số trường hợp đặc biệt, chẳng hạn như giá xăng tăng đột ngột trên L2 và lượng xăng trả trước trên vé không đủ, không thể tự động đổi. 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 quá trình đổi tự động không thành công, bạn cần đổi ghi chú 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. bạn sẽ cần phải trả một số tiền nhất định để lưu lại các khoản phí để gia hạn hợp đồng thuê.
Ngoài ra, đối với quy trình rút 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 với hành vi nạp tiền nhưng không có khái niệm về Có thể thử lại. Một mặt, nó có thể Từ chính giao thức Rollup, mặt khác, chúng ta có thể hiểu được từ một số điểm khác biệt:
·Có không có quy đổi tự động trong quá trình rút tiền, vì EVM không có bộ hẹn giờ hoặc tự động hóa và việc quy đổi tự động có thể được thực hiện trên L2, được triển khai 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 cần tương tác thủ công với Hộp thư đi hợp đồng đòi lại tài sản.
·Không có vấn đề hết hạn vé khi rút tiền mặt Miễn là thời gian thử thách đã trôi qua, bạn có thể yêu cầu vé tại. Bất cứ lúc nào.
Chuỗi chéo tài sản ERC-20 tài sản rất phức tạp. Chúng ta có thể nghĩ về một số câu hỏi:
·Một mã thông báo đượ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 phải 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 đã chuyển qua nhưng chưa triển khai không hợp đồng?
·Địa chỉ hợp đồng tương ứng với tài sản ERC-20 trên L1 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ự nhiên từ L2 đến L1?
·Làm cách 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 thu 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 để giải thích. Những vấn đề này chỉ nhằm minh họa sự phức tạp của chuỗi chéo ERC20.

Hiện tại có nhiều bản mở rộng giải pháp Tất cả các giải pháp danh sách trắng + danh sách thủ công đều được sử dụ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 đ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 ở 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à một số token<-> ; Ánh xạ giữa 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.
Chúng tôi 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.
Tương tự, WETH cũng có thể bị phá hủy và ETH cũng có thể 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 WETH trực tiếp với L2, chúng ta sẽ gặp một số vấn đề lạ:
·Chúng ta không thể liên kết chéo WETH trên L2 Unwrap trở thành ETH vì không có ETH tương ứng bị khóa trên L2.
·Có thể sử dụng hàm Wrap, nhưng nếu những 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ìL1 Hợp đồng WETH trên 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 phải được Unwrap sang ETH, sau đó chuyển sang phía bên kia và sau đó là Wrap sang WETH. Đây là vai trò của WETH Gateway.
Các mã thông báo khác có logic phức tạp hơn cần một 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 các 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.
Tương ứng với hộp nhanh, tức là SequencerInbox Bị trì hoãn Hộp thư đến (tên đầy đủ: Hộp thư đến bị trì hoãn). Tại sao phải có sự phân biệt giữa tốc độ và sự chậm chạp? Do 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 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 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 chuỗi giao dịch của 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 trực tiếp giao dịch nạp tiền tới hộp chuyển phát nhanh là không phù hợp vì giao dịch được gửi tới hộp chuyển phát nhanh Sequencer Inbox sẽ gây trở ngại với Lớp 2 Thứ tự giao dịch thông thường sẽ ảnh hưởng đến công việc của trình sắp xếp thứ tự.
Chức năng thứ hai của hộp chậm 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 tới hợp đồng hộp chậm sẽ được bộ phân loại tổng hợp vào hộp nhanh trong vòng 10 phút. Nhưng nếu bộ phân loại 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 giao dịch được gửi đến Trì hoãn Hộp thư đến, sau 24 giờ, các giao dịch trong hộp chậm chưa được trình sắp xếp trình 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 để trình sắp xếp trình tự bỏ qua chúng. yêu cầu 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,thông qua hộp chậm, các hướng dẫn giao dịch cuối cùng có thể đượ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 và các tình huống khác để thoát khỏi Lớp 2.
Có thể thấ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 vĩnh viễn bạn.
Một số chức năng cốt lõi của Inbox:
· 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à nạp 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(), còn được gọi 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 hàm Bao gồm lực thực chất nằm trong hợp đồng hộp nhanh. Để cho dễ hiểu, chúng ta sẽ cùng nhau giải thích ở phần sau. hộp chậm.
Outbox chỉ liên quan đến việc rút tiền. hệ thống ghi lại 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 chính thức của Arbitrum cần phải đợi khoảng 7 ngày mới kết thúc của giai đoạn thử thách, hành vi 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 những tin nhắn chuỗi chéo nào từ L2 đến L1 đã được xử lý để ngăn người nào đó 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ỉ mục đã chi tiêu và thông tin của yêu cầu rút tiền thông qua ánh xạ (uint256 => bytes32) chi tiêu công khai. Nếu ánh xạ [spentIndex] != byte32(0), yêu cầu đã bị rút. 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ó không đi sâu vào chi tiết.
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 một địa chỉ nạp tiền.
3. Trình sắp xếp thứ tự giám sát thông báo nạp lại trong hộp chậm và phản ánh hoạt động nạp lại vào cơ sở dữ liệu L2. Người dùng có thể xem nó trên L2. mạng vào tài sản mà bạn đã tính phí.
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ó tới hợp đồng hộp nhanh trên L1.

p>
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 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.execute Transaction() trên L1 Các tham số bằng chứng được đưa ra bởi hợp đồng ArbSys đã đề cập trước đó.
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 sẽ được mở khóa và gửi cho người dùng.

Nếu bạn sử dụng cầu nối chính thức của Optimistic Rollup để rút tiền mặt, sẽ có vấn đề trong việc chờ đợi giai đoạn thử thách. Chúng ta có thể sử dụng cầu nối chuỗi chéo riêng tư của bên thứ ba để tránh 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à là phương thức 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à tính thanh khoản 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 chuỗi chéo. Loại cầu xuyên xích chung là cầu chứng. 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 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 nhanh của L1, nó 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.
bắt buộc Inclusion() Chức năng thu thập bắt buộc được sử dụng Chống lại kiểm duyệt trình tự sắp xếp, mọi 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 tính năng này. Việc đánh giá độc hại của trình sắp xếp thứ tự ả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 phải rút tiền làm ví dụ để giới thiệu việc 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 nên chỉ cần thay đổi hai bước này:

·Gọi Đầu vào Các tham số của inbox.sendL2Message() trong hợp đồng hộp chậm trên L1 là các 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ờ đợi 24 giờ bắt buộc đưa vào, hãy gọi Force Inclusion() trong hộp nhanh để thực hiện hợp đồng hộp nhanh sẽ kiểm tra. cây cầu Có tin nhắn tương ứng nào 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ò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 sử dụng ForceInclusion() để thực hiện các giao dịch cục bộ L2 và giao dịch L2 đến L1.
Liên kết gốc
Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:
Nhóm Telegram đăng ký: https://t.me/theblockbeats
Nhóm Telegram thảo luận: https://t.me/BlockBeats_App
Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia