Artikel ketiga dalam seri kami yang menjelaskan mode Fusion difokuskan pada komponen onchain dalam penyelesaian swap.

Dalam dua artikel seri sebelumnya, kita masing-masing membahas konsep penyelesai dan komponen offchain dari proses penyelesaian pertukaran.

Mari kita lanjutkan dari bagian terakhir yang kita tinggalkan. Kami berada pada tahap dalam proses resolusi swap ketika backend penyelesai telah "memutuskan" untuk memenuhi pesanan Fusion yang diterima dari layanan relayer 1 inci, dalam blok tertentu, dengan sejumlah aset yang ditukar untuk dikembalikan ke pengguna. Sekarang, kita akan membahas bagian onchain dari proses penyelesaian swap. Namun pertama-tama, kami akan menjelaskan peserta dalam proses ini.

Bagian onchain dari eksekusi pertukaran Fusion melibatkan interaksi yang cukup kompleks antara entitas blockchain berikut:

Pemberitahuan yang sangat penting: dalam beberapa kasus (tidak selalu), seorang penyelesai membuat beberapa pengisian dalam satu batch, hingga 32. Biasanya, ada beberapa saldo token dalam kontrak pekerja penyelesai dan backend dapat menerima beberapa pesanan dari “aliran” yang disediakan oleh relayer, dan membuat urutan pengisian.

Kami akan membahas skenario berikut.

Penyelesai memilih 3 pesanan yang berpotensi menguntungkan dari penyampai untuk dipenuhi:

  • 100 DAI untuk minimal 0,6 WETH

  • 0,6 WETH untuk minimal 100 DAI

  • 0,01 WBTC untuk setidaknya 36 UNI

Tujuan bisnis dari penyelesai adalah untuk mengeksekusi ketiga swap sedemikian rupa sehingga pengguna mendapatkan setidaknya jumlah yang mereka harapkan. Kami akan mengabaikan kemungkinan strategi perolehan pendapatan dari penyelesai dan menyederhanakan perhitungan sehingga Anda dapat memahami gambaran umum.

Sekarang, backend memberikan informasi tentang pesanan yang dipilih ke kontrak pekerja. Apa yang terjadi selanjutnya?

Catatan: bagan ini merupakan kelanjutan dari artikel yang didedikasikan untuk komponen offchain dalam penyelesaian swap. Namun, untuk mempermudah pemahaman, kita mulai dari langkah 1.

Langkah 1

Kontrak pekerja (atau dompet) memanggil metode settleOrders() pada kontrak penyelesaian 1 inci, yang mengirimkan informasi pesanan dalam format byte terkompresi yang ringan; argumen calldata dan tokensAndAmounts digunakan untuk menyimpan informasi ini.

Di sini, Anda mungkin memperhatikan beberapa detail menarik:

  • rateBump berasal dari pemberi penawaran dan secara efektif menentukan pengembalian. Ini adalah perbedaan persentase antara jumlah lelang saat ini dan jumlah lelang minimal. Misalnya, jika nilai rateBump adalah 4_000_000 danauctionEndAmount(pengembalian minimum) adalah 500, maka jumlah pengambilan lelang saat ini adalah 700.

  • totalFee adalah biaya yang harus dibayarkan oleh semua penyelesai ke 1inch Foundation (Penting: saat ini fitur ini tidak digunakan - penyelesai tidak membayar biaya apa pun ke 1inch Foundation).

  • limitOrderProtocol adalah instance protokol yang dideklarasikan dalam kontrak penyelesaian melalui antarmuka Soliditas masing-masing. Ini digunakan untuk menyebut kontrak ini dari kontrak penyelesaian.

Langkah 2

Kontrak penyelesaian memanggil metode fillOrderTo() dari kontrak pesanan batas, yang mengirimkan data salah satu dari 3 pesanan dari daftar - misalnya, 100 DAI untuk setidaknya 0,6 WETH:

  • Interaksi - ini berisi informasi bahwa ada 2 pesanan lagi dalam jumlah besar yang harus dieksekusi setelahnya.

  • Menghasilkan atau menerima jumlah - secara harafiah berapa banyak yang harus dibayar atau berapa banyak yang akan diterima. Hanya satu dari jumlah ini yang bukan nol. Jika Anda menyetel makingAmount, Anda menentukan berapa banyak yang ingin Anda terima sebagai penyelesai. Alternatifnya, dengan menyetel pengambilanJumlah, Anda menentukan berapa banyak yang ingin Anda jual sebagai penyelesai. Yang satu akan dihitung berdasarkan yang lain.

  • Target - alamat kontrak pekerja yang akan menerima token sumber.

Langkah 3-4

Kontrak pesanan batas memanggil kontrak token sumber untuk mentransfer jumlah swap dari pengguna ke kontrak pekerja penyelesai, menggunakan antarmuka ERC20 Solidity.

Bagian perakitan yang tidak dapat dibaca manusia, membentuk data panggilan dan memanggil kontrak token. Bagian perakitan dalam kontrak dibuat untuk efisiensi gas dan pengiriman data yang kompleks.

Langkah 5-6

Kontrak pesanan batas memanggil kembali kontrak penyelesaian dengan metode yang disebut  fillOrderInteraction() dan mengirimkan interactiveData yang berisi informasi tentang pesanan selanjutnya dalam batch (informasi yang sebelumnya diterima dalam interaksi). Di sisi penyelesaian, kode ini mendekodekan interactiveData yang mengubahnya kembali menjadi interaksi.

Jika batch tidak berisi pesanan lagi (skenario 1 di bawah), maka batch tersebut akan menyelesaikan interaksi dan memanggil kontrak pekerja penyelesai untuk “memberi tahu” batch tersebut untuk menyelesaikan pesanan. Ini dimungkinkan karena kontrak pekerja akan mengimpor antarmuka kami yang disebut IRsolver. Di Solidity, interaksi lintas kontrak biasanya dilakukan dengan cara ini. Kami akan membahas apa yang dilakukan pekerja pada langkah 16-17 di bawah.

Jika ada pesanan lain yang tersisa dalam batch, kontrak penyelesaian memanggil kembali kontrak pesanan batas. Kedua kontrak akan terus bertukar data hingga semua pesanan diselesaikan dan semua dana telah dikumpulkan dari akun pengguna (100 DAI, 0,6 WETH, dan 0,01 WBTC dalam contoh kami).

Langkah 7

Kita hampir selesai. Kontrak pekerja-resolver telah menerima semua dana dari pengguna melalui kontrak penyelesaian 1 inci dan pesanan batas. Sekarang, saatnya menyelesaikan pesanan!

Berikut adalah properti pesanan:

  • Pesanan 1: 100 DAI setidaknya 0,6 WETH

  • Pesanan 2: 0,6 WETH setidaknya 100 DAI

  • Pesanan 3: 0,01 WBTC untuk setidaknya 36 UNI

Sepertinya kami benar-benar dapat mencocokkan pesanan 1 dan pesanan 2 tanpa tindakan tambahan apa pun. Jadi, kami cukup mengirimkan 0,6 WETH yang dikumpulkan dari pengguna yang mengirimkan pesanan 2 ke pengguna yang mengirimkan pesanan 1 dengan aman, dan sebaliknya. Dengan demikian, pesanan 2 dari 3 telah diselesaikan menggunakan dana pengguna sendiri.

Pesanan terakhir yang tersisa adalah swap 0,01 WBTC untuk 36 UNI. Kontrak pekerja tidak memiliki UNI di saldonya. Jadi, kontrak pekerja memanggil kontrak router agregasi 1 inci dengan cara yang sama seperti yang dilakukan pengguna mana pun dalam pertukaran lama. Backend penyelesai dapat memanggil API agregasi kami untuk mendapatkan rute optimal dan meneruskannya ke pekerja untuk dieksekusi. Router mengeksekusi swap ini dan mengirimkan 36 UNI ke solver.

Dalam contoh sederhana ini, penyelesai tidak memperoleh apa pun kecuali mengeluarkan dana untuk bahan bakar untuk mentransfer data antar kontrak. Dalam kehidupan nyata, seperti disebutkan di atas, backend penyelesai akan memperhitungkan semua biaya dan memastikan bahwa perdagangan menguntungkan bagi mereka dan tetap dalam kerangka yang disediakan oleh layanan penawaran. Penyelesai juga akan mencoba membuat pertukaran menguntungkan secara maksimal bagi pengguna.

Langkah 8-11

Sekarang, setelah penyelesai pekerja memiliki token tujuan, mereka harus merespons panggilan balik dan mentransfernya ke kontrak penyelesaian. Tapi tunggu… Mengapa mereka tidak bisa mengirimkan token langsung ke pengguna?

Tidak, mereka tidak bisa karena cara arsitektur diterapkan. Ingat, langkah 5 dari alur ini adalah callback ke metode fillOrderTo() yang dipanggil oleh kontrak penyelesaian ke kontrak limit order. Jadi, fungsinya masih dijalankan!

Karena penelepon adalah kontrak penyelesaian, dalam konfigurasi ini, penelepon dianggap sebagai pengambil pesanan. Oleh karena itu, instance ini seharusnya menerima respons dari penyelesai dan token yang ditransfer. Kemudian, ia memberikan persetujuan pada kontrak limit order, yang kemudian memanggil transferFrom() ke kontrak token tujuan dan jumlah swap akhirnya masuk ke dompet pengguna. Dilakukan!

Contoh Etherscan kehidupan nyata

Sebagai latihan terakhir, mari kita tinjau kasus nyata dari pertukaran Fusion: 1INCH ke DAI, diselesaikan oleh pemecah masalah Seawise, dan transfer token ERC20-nya. Untuk pengalaman terbaik, Anda perlu rujuk silang gambar di bawah ini dengan diagram di atas, sesuaikan langkah-langkahnya.

Pada langkah 4, kontrak pesanan batas memanggil transferFrom() pada kontrak token 1INCH untuk mentransfer token sumber dari alamat pembuat (0x90…9044) ke alamat penyelesai.

Langkah 5 dan 6 tidak tercantum dalam daftar ini karena tidak memerlukan transfer token ERC20.

Pada langkah 7, Seawise sebagai penyelesai menukar 1INCH menjadi DAI di kumpulan Uniswap sebagai sumber likuiditas.

Pada langkah 8, Seawise mentransfer DAI ke kontrak penyelesaian 1 inci.

Langkah 9 dan 10 juga dilewati di sini karena ini adalah respons panggilan balik internal antara kontrak penyelesai dan 1 inci.

Terakhir, pada langkah 11, kontrak penyelesaian 1 inci mentransfer token tujuan ke pembuat.

Jangan ragu untuk menjelajahi transaksi ini di Etherscan:

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