Bài viết thứ ba trong loạt bài giải thích về chế độ Fusion tập trung vào thành phần onchain của quá trình giải quyết hoán đổi.

Trong hai bài viết trước của loạt bài này, chúng ta đã thảo luận lần lượt về khái niệm trình giải quyết và thành phần ngoài chuỗi của quy trình giải quyết hoán đổi.

Hãy tiếp tục từ nơi chúng ta đã dừng lại. Chúng ta đang ở một giai đoạn trong quá trình giải quyết hoán đổi khi backend của trình giải quyết đã "quyết định" điền vào lệnh Fusion mà nó nhận được từ dịch vụ chuyển tiếp 1inch, trong một khối nhất định, với một số lượng nhất định tài sản hoán đổi được trả lại cho người dùng. Bây giờ, chúng ta sẽ xem xét phần onchain của quá trình giải quyết hoán đổi. Nhưng trước tiên, chúng ta sẽ mô tả những người tham gia vào quá trình này.

Phần trên chuỗi của quá trình thực hiện hoán đổi Fusion liên quan đến những tương tác khá phức tạp giữa các thực thể chuỗi khối sau:

Một lưu ý rất quan trọng: trong một số trường hợp (không phải lúc nào cũng vậy), trình giải quyết thực hiện nhiều lần điền trong một đợt, lên đến 32 lần. Thông thường, có nhiều số dư mã thông báo trong hợp đồng công nhân của trình giải quyết và phần phụ trợ có thể tiếp nhận nhiều lệnh từ "luồng" mà trình chuyển tiếp cung cấp và thực hiện một chuỗi các lần điền.

Chúng ta sẽ xem xét tình huống sau.

Người giải quyết đã chọn 3 đơn hàng có khả năng sinh lợi từ người chuyển tiếp để thực hiện:

  • 100 DAI cho ít nhất 0,6 WETH

  • 0,6 WETH cho ít nhất 100 DAI

  • 0,01 WBTC cho ít nhất 36 UNI

Mục tiêu kinh doanh của trình giải quyết là thực hiện cả 3 lần hoán đổi theo cách mà người dùng nhận được ít nhất số tiền họ mong đợi. Chúng tôi sẽ bỏ qua các chiến lược kiếm tiền có thể có của trình giải quyết và đơn giản hóa các phép tính để bạn có thể hiểu được ý tưởng chung.

Bây giờ, phần phụ trợ cung cấp thông tin về các lệnh đã chọn cho hợp đồng công nhân. Điều gì xảy ra tiếp theo?

NB: biểu đồ này là phần tiếp theo của một bài viết dành riêng cho thành phần offchain của việc giải quyết hoán đổi. Nhưng để dễ hiểu, chúng ta bắt đầu từ bước 1.

Bước 1

Hợp đồng công nhân (hoặc ví) gọi phương thức settleOrders() của hợp đồng thanh toán 1inch, cung cấp thông tin đơn hàng ở định dạng nén nhẹ gồm các byte; các đối số calldata và tokensAndAmounts được sử dụng để lưu trữ thông tin này.

Ở đây, bạn có thể nhận thấy một vài chi tiết thú vị:

  • rateBump đến từ người báo giá và xác định hiệu quả lợi nhuận. Đây là phần trăm chênh lệch giữa số tiền đấu giá hiện tại và số tiền đấu giá tối thiểu. Ví dụ, nếu giá trị rateBump là 4_000_000 và auctionEndAmount (lợi nhuận tối thiểu) là 500, thì số tiền đấu giá hiện tại là 700.

  • totalFee là khoản phí mà tất cả người giải quyết phải trả cho 1inch Foundation (Quan trọng: hiện tại tính năng này không được sử dụng - người giải quyết không phải trả bất kỳ khoản phí nào cho 1inch Foundation).

  • limitOrderProtocol là một thể hiện của giao thức được khai báo trong hợp đồng thanh toán thông qua giao diện Solidity tương ứng. Nó được sử dụng để gọi hợp đồng này từ hợp đồng thanh toán.

Bước 2

Hợp đồng thanh toán gọi phương thức fillOrderTo() của hợp đồng lệnh giới hạn, cung cấp dữ liệu của một trong 3 lệnh từ danh sách - ví dụ, 100 DAI cho ít nhất 0,6 WETH:

  • Tương tác - thông tin này bao gồm 2 lệnh nữa trong số lệnh sẽ phải được thực hiện sau đó.

  • Tạo hoặc lấy số tiền - nghĩa đen là số tiền phải trả hoặc số tiền cần nhận. Chỉ một trong những số tiền này có thể khác không. Nếu bạn đặt makingAmount, bạn chỉ định số tiền bạn muốn nhận được dưới dạng trình giải quyết. Ngoài ra, bằng cách đặt takingAmount, bạn xác định số tiền bạn muốn bán dưới dạng trình giải quyết. Một số tiền sẽ được tính toán dựa trên số tiền khác.

  • Mục tiêu - địa chỉ của hợp đồng công nhân sẽ nhận được mã thông báo nguồn.

Các bước 3-4

Hợp đồng lệnh giới hạn gọi hợp đồng mã thông báo nguồn để chuyển số tiền hoán đổi từ người dùng sang hợp đồng công nhân của bộ giải quyết, sử dụng giao diện ERC20 Solidity.

Một bộ phận lắp ráp không dễ đọc đối với con người, tạo calldata và gọi hợp đồng mã thông báo. Các bộ phận lắp ráp của hợp đồng được tạo ra để tiết kiệm khí và cung cấp dữ liệu phức tạp.

Các bước 5-6

Hợp đồng lệnh giới hạn gọi lại hợp đồng thanh toán bằng phương thức gọi là  fillOrderInteraction() và gửi interactiveData chứa thông tin về các lệnh tiếp theo trong lô (thông tin đã nhận trước đó trong các tương tác). Về phía thanh toán, mã giải mã interactiveData chuyển đổi nó trở lại thành các tương tác.

Nếu lô không chứa thêm lệnh nào nữa (kịch bản 1 bên dưới), nó sẽ hoàn tất tương tác và gọi hợp đồng công nhân của trình giải quyết "yêu cầu" nó giải quyết các lệnh. Điều này có thể thực hiện được vì hợp đồng công nhân sẽ nhập giao diện của chúng tôi có tên là IResolver. Trong Solidity, các tương tác giữa các hợp đồng thường được thực hiện theo cách này. Chúng tôi sẽ đề cập đến những gì công nhân thực hiện trong các bước 16-17 bên dưới.

Nếu bất kỳ lệnh nào khác vẫn còn trong lô, hợp đồng thanh toán sẽ gọi lại hợp đồng lệnh giới hạn. Hai hợp đồng sẽ tiếp tục trao đổi dữ liệu cho đến khi tất cả các lệnh được thanh toán và tất cả tiền đã được thu thập từ tài khoản của người dùng (100 DAI, 0,6 WETH và 0,01 WBTC trong ví dụ của chúng tôi).

Bước 7

Chúng tôi gần hoàn tất rồi. Hợp đồng người giải quyết công việc đã nhận được tất cả tiền từ người dùng thông qua hợp đồng thanh toán 1inch và lệnh giới hạn. Bây giờ, đã đến lúc thực sự giải quyết các lệnh!

Sau đây là các thuộc tính của lệnh:

  • Đơn hàng 1: 100 DAI cho ít nhất 0,6 WETH

  • Đơn hàng 2: 0,6 WETH cho ít nhất 100 DAI

  • Lệnh 3: 0,01 WBTC cho ít nhất 36 UNI

Có vẻ như chúng ta có thể khớp lệnh 1 và lệnh 2 mà không cần bất kỳ hành động bổ sung nào. Vì vậy, chúng ta sẽ chỉ cần gửi 0,6 WETH thu được từ người dùng đã gửi lệnh 2 đến người dùng đã gửi lệnh 1 một cách an toàn và ngược lại. Do đó, lệnh 2 trong số 3 lệnh đã được giải quyết bằng tiền của chính người dùng.

Lệnh còn lại cuối cùng là hoán đổi 0,01 WBTC lấy 36 UNI. Hợp đồng công nhân không có bất kỳ UNI nào trong số dư của nó. Vì vậy, hợp đồng công nhân gọi hợp đồng bộ định tuyến tổng hợp 1 inch theo cùng cách mà bất kỳ người dùng nào thực hiện trong hoán đổi kế thừa. Phần cuối của trình giải quyết có thể gọi API tổng hợp của chúng tôi để có được tuyến đường tối ưu và chuyển nó cho công nhân để thực hiện. Bộ định tuyến thực hiện hoán đổi này và cung cấp 36 UNI cho trình giải quyết.

Trong ví dụ đơn giản này, trình giải quyết không kiếm được gì ngoài việc chi tiền cho gas để chuyển dữ liệu giữa các hợp đồng. Trong thực tế, như đã đề cập ở trên, backend của trình giải quyết sẽ tính đến tất cả các chi phí và đảm bảo rằng các giao dịch có lợi cho họ và nằm trong khuôn khổ do dịch vụ báo giá cung cấp. Trình giải quyết cũng sẽ cố gắng làm cho việc hoán đổi có lợi nhuận tối đa cho người dùng.

Các bước 8-11

Bây giờ, sau khi worker-resolver có token đích, họ phải phản hồi lệnh gọi lại và chuyển chúng đến hợp đồng thanh toán. Nhưng khoan đã… Tại sao họ không thể gửi token trực tiếp đến người dùng?

Không, họ không thể vì cách kiến ​​trúc được triển khai. Hãy nhớ rằng, bước 5 của luồng này là lệnh gọi lại phương thức fillOrderTo() được hợp đồng thanh toán gọi đến hợp đồng lệnh giới hạn. Vì vậy, hàm vẫn đang được thực thi!

Vì người gọi là hợp đồng thanh toán, trong cấu hình này, nó được coi là người nhận lệnh. Do đó, trường hợp này được cho là sẽ nhận được phản hồi từ trình giải quyết và các mã thông báo đã chuyển. Sau đó, nó cung cấp sự chấp thuận cho hợp đồng lệnh giới hạn, sau đó, gọi transferFrom() đến hợp đồng mã thông báo đích và số tiền hoán đổi cuối cùng sẽ đến ví của người dùng. Chúng ta đã hoàn tất!

Một ví dụ thực tế về Etherscan

Bài tập cuối cùng, chúng ta hãy xem xét một trường hợp thực tế của Fusion swap: 1INCH sang DAI, được giải quyết bởi trình phân giải Seawise và các giao dịch chuyển token ERC20 của nó. Để có trải nghiệm tốt nhất, bạn cần tham chiếu chéo hình ảnh bên dưới với sơ đồ ở trên, khớp với các bước.

Ở bước 4, hợp đồng lệnh giới hạn gọi transferFrom() trên hợp đồng mã thông báo 1INCH để chuyển mã thông báo nguồn từ địa chỉ người tạo (0x90…9044) đến địa chỉ người giải quyết.

Bước 5 và 6 không được phản ánh trong danh sách này vì chúng không liên quan đến bất kỳ việc chuyển giao token ERC20 nào.

Ở bước 7, Seawise với tư cách là đơn vị giải quyết sẽ hoán đổi 1INCH thành DAI trong nhóm Uniswap làm nguồn thanh khoản.

Ở bước 8, Seawise chuyển DAI sang hợp đồng thanh toán 1 inch.

Bước 9 và 10 cũng bị bỏ qua ở đây vì đây là phản hồi gọi lại nội bộ giữa trình giải quyết và hợp đồng 1inch.

Cuối cùng, tại bước 11, hợp đồng thanh toán 1 inch sẽ chuyển mã thông báo đích đến cho người tạo.

Hãy thoải mái khám phá giao dịch này trên Etherscan:

https://etherscan.io/tx/0x55e621337837f4f69f0c398ad5e9072a24811bbfd8cb2b208d621b940c9689b5