Trešais mūsu sērijas raksts, kurā izskaidrots saplūšanas režīms, ir vērsts uz mijmaiņas darījumu atrisināšanas onchain komponentu.
Sērijas divos iepriekšējos rakstos mēs attiecīgi apspriedām atrisinātāja jēdzienu un mijmaiņas atrisināšanas procesa ārpusķēdes komponentu.
Turpināsim no vietas, kur pārtraucām. Mēs atrodamies mijmaiņas darījumu atrisināšanas procesa posmā, kad atrisinātāja aizmugursistēma ir “nolēmusi” aizpildīt Fusion pasūtījumu, ko tā saņēma no 1 collas relayer pakalpojuma, noteiktā blokā ar noteiktu apmainītā līdzekļa daudzumu, kas jāatdod atpakaļ lietotājs. Tagad mēs apskatīsim mijmaiņas darījumu atrisināšanas procesa onchain daļu. Bet vispirms mēs aprakstīsim šī procesa dalībniekus.
Fusion mijmaiņas apmaiņas izpildes ķēdes daļa ietver diezgan sarežģītas mijiedarbības starp šādām blokķēdes entītijām:
Ļoti svarīgs paziņojums: dažos gadījumos (ne vienmēr) atrisinātājs veic vairākus aizpildījumus vienā partijā, līdz pat 32. Parasti atrisinātāja darbinieka līgumā ir vairāki marķieru atlikumi, un aizmugursistēma var pieņemt vairākus pasūtījumus no “straumes”. ko nodrošina relayeris, un izveidojiet aizpildījumu secību.
Mēs apskatīsim šādu scenāriju.
Atrisinātājs no relayera izvēlējās 3 potenciāli ienesīgus pasūtījumus, ko aizpildīt:
100 DAI vismaz 0,6 WETH
0,6 WETH vismaz 100 DAI
0,01 WBTC vismaz 36 UNI
Atrisinātāja biznesa mērķis ir izpildīt visus 3 mijmaiņas darījumus tā, lai lietotāji saņemtu vismaz tādu summu, kādu viņi gaidīja. Mēs izlaidīsim atrisinātāju iespējamās peļņas stratēģijas un vienkāršosim aprēķinus, lai jūs varētu saprast vispārējo ideju.
Tagad aizmugursistēma nodrošina informāciju par atlasītajiem pasūtījumiem darba ņēmēja līgumam. Kas notiks tālāk?
NB: šī diagramma ir viena no raksta turpinājums, kas veltīts mijmaiņas darījumu atrisināšanas ārpus ķēdes komponentam. Bet izpratnes vienkāršības labad mēs sākam no 1. darbības.
1. darbība
Darbinieka līgums (vai maciņš) izsauc 1 collas norēķinu līguma metodi settleOrders(), nodrošinot pasūtījuma informāciju vieglā saspiestā baitu formātā. Šīs informācijas glabāšanai tiek izmantoti argumenti calldata un tokensAndAmounts.
Šeit jūs varat pamanīt dažas interesantas detaļas:
rateBump nāk no citētāja un efektīvi nosaka atdevi. Tā ir procentuālā starpība starp pašreizējo izsoles summu un minimālo izsoles summu. Piemēram, ja rateBump vērtība ir 4_000_000 un auctionEndAmount (minimālā atdeve) ir 500, pašreizējā izsoles summa ir 700.
totalFee ir maksa, kas visiem atrisinātājiem ir jāmaksā 1 inch Foundation (svarīgi: pašlaik šī funkcija netiek izmantota — atrisinātāji nemaksā nekādas maksas 1 inch Foundation).
limitOrderProtocol ir protokola gadījums, kas ir deklarēts norēķinu līgumā, izmantojot attiecīgo Solidity saskarni. To izmanto, lai izsauktu šo līgumu no norēķinu līguma.
2. darbība
Norēķinu līgums izsauc limita pasūtījuma līguma metodi fillOrderTo(), piegādājot datus par vienu no 3 pasūtījumiem no saraksta — piemēram, 100 DAI vismaz 0,6 WETH:
Mijiedarbība - šeit ir informācija, ka kopumā ir vēl 2 pasūtījumi, kas pēc tam būs jāizpilda.
Summu taisīšana vai ņemšana – burtiski, cik maksāt vai cik saņemt. Tikai viena no šīm summām var atšķirties no nulles. Ja iestatāt makingAmount, jūs norādāt, cik daudz vēlaties saņemt kā atrisinātāju. Alternatīvi, iestatot takingAmount, jūs nosakāt, cik daudz vēlaties pārdot kā atrisinātāju. Viens tiks aprēķināts, pamatojoties uz otru.
Mērķis — tā darba ņēmēja līguma adrese, kas saņems avota marķierus.
3.-4. darbība
Ierobežotā pasūtījuma līgums izsauc avota marķiera līgumu, lai pārsūtītu mijmaiņas summu no lietotāja uz atrisinātāja darba līgumu, izmantojot ERC20 Solidity saskarni.
Montāžas daļa, kas cilvēkiem nav īpaši salasāma, veido zvanu datus un izsauc marķiera līgumu. Līguma montāžas daļas ir radītas gāzes efektivitātei un sarežģītu datu piegādei.
5.-6. darbība
Ierobežotā pasūtījuma līgums atgriežas pie norēķinu līguma, izmantojot metodi, ko sauc par fillOrderInteraction() un nosūta interactiveData, kas satur informāciju par turpmākajiem pasūtījumiem paketē (informācija, kas iepriekš saņemta mijiedarbībā). Norēķinu pusē kods dekodē interactiveData, pārvēršot tos atpakaļ mijiedarbībā.
Ja partijā vairs nav pasūtījumu (1. scenārijs tālāk), tā pabeidz mijiedarbību un izsauc atrisinātāja darbinieka līgumu, “sakot” tai atrisināt pasūtījumus. Tas būs iespējams, jo darbinieka līgums importēs mūsu saskarni ar nosaukumu IResolver. Programmā Solidity starplīgumu mijiedarbība parasti tiek veikta šādā veidā. Tālāk 16.–17. darbībā aplūkosim, ko darbinieks dara.
Ja paketē paliek kādi citi pasūtījumi, norēķinu līgums atkārtoti izsauc limita pasūtījuma līgumu. Abi līgumi turpinās datu apmaiņu, līdz visi pasūtījumi būs izpildīti un visi līdzekļi tiks iekasēti no lietotāju kontiem (mūsu piemērā 100 DAI, 0,6 WETH un 0,01 WBTC).
7. darbība
Mēs esam gandrīz pabeiguši. Darbinieka un atrisinātāja līgums ir saņēmis visus līdzekļus no lietotājiem, izmantojot 1 collas norēķinu un limita pasūtījumu līgumus. Tagad ir pienācis laiks faktiski atrisināt pasūtījumus!
Šeit ir pasūtījuma rekvizīti:
Pasūtījums 1: 100 DAI vismaz 0,6 WETH
Pasūtījums 2: 0,6 WETH par vismaz 100 DAI
Pasūtījums 3: 0,01 WBTC vismaz 36 UNI
Šķiet, ka varam burtiski saskaņot 1. pasūtījumu un 2. pasūtījumu bez papildu darbībām. Tātad, mēs tikai droši nosūtīsim 0,6 WETH, kas savākti no lietotāja, kurš iesniedza 2. pasūtījumu, lietotājam, kurš iesniedza 1. pasūtījumu, un otrādi. Tādējādi 2. no 3 pasūtījumiem ir atrisināti, izmantojot lietotāju pašu līdzekļus.
Pēdējais atlikušais pasūtījums ir 0,01 WBTC maiņa pret 36 UNI. Darba līguma atlikumā nav neviena UNI. Tātad darba ņēmēja līgums 1 collas apkopojuma maršrutētāja līgumu sauc tāpat kā jebkurš lietotājs to dara mantotā mijmaiņas darījumā. Atrisinātāja aizmugursistēma var izsaukt mūsu apkopošanas API, lai iegūtu optimālu maršrutu un nodotu to darbiniekam izpildei. Maršrutētājs izpilda šo mijmaiņas darījumu un piegādā 36 UNI uz atrisinātāju.
Šajā vienkāršotajā piemērā atrisinātājs neko nenopelnīja, bet iztērēja līdzekļus gāzei, lai pārsūtītu datus starp līgumiem. Reālajā dzīvē, kā minēts iepriekš, atrisinātāja aizmugure ņems vērā visus izdevumus un pārliecinātos, ka darījumi viņiem ir izdevīgi un paliek kotētāja pakalpojuma nodrošinātajos ietvaros. Atrisinātājs arī mēģinātu padarīt mijmaiņas darījumu maksimāli izdevīgu lietotājam.
8.-11. darbība
Tagad, kad strādnieks-risinātājs ir ieguvis mērķa marķieri, viņiem ir jāatbild uz atzvanīšanu un jāpārskaita tie uz norēķinu līgumu. Bet pagaidiet… Kāpēc viņi nevar nosūtīt žetonus tieši lietotājam?
Nē, viņi nevar, jo tiek īstenota arhitektūra. Atcerieties, ka šīs plūsmas 5. darbība ir atzvanīšana uz metodi fillOrderTo(), ko norēķinu līgums izsauc ierobežota pasūtījuma līgumam. Tātad funkcija joprojām tiek izpildīta!
Tā kā zvanītājs bija norēķinu līgums, šajā konfigurācijā tas tiek uzskatīts par pasūtījuma saņēmēju. Tādējādi šai instancei ir jāsaņem atbilde no atrisinātāja un pārsūtītajiem marķieriem. Pēc tam tiek apstiprināts limita pasūtījuma līgums, kas savukārt izsauc transferFrom() uz galamērķa marķiera līgumu, un mijmaiņas summa beidzot nonāk lietotāja makā. Esam pabeiguši!
Etherscan piemērs dzīvē
Kā pēdējo uzdevumu, apskatīsim reālu Fusion mijmaiņas gadījumu: 1 INCH uz DAI, ko atrisināja Seawise atrisinātājs, un tā ERC20 marķiera pārsūtīšanas. Lai iegūtu vislabāko pieredzi, jums ir jāatsaucas uz tālāk redzamo attēlu ar iepriekš redzamo diagrammu, ievērojot darbības.
4. darbībā ierobežojuma pasūtījuma līgums izsauc transferFrom() par 1 INCH pilnvaras līgumu, lai pārsūtītu avota pilnvaru no ražotāja adreses (0x90…9044) uz atrisinātāja adresi.
5. un 6. darbība nav atspoguļota šajā sarakstā, jo tie nav saistīti ar ERC20 pilnvaru pārsūtīšanu.
7. darbībā Seawise kā atrisinātājs apmaina 1 INCH uz DAI Uniswap pūlā kā likviditātes avotu.
8. darbībā Seawise nodod DAI uz 1 collas norēķinu līgumu.
Šeit tiek izlaistas arī 9. un 10. darbība, jo tās ir iekšējās atzvanīšanas atbildes starp atrisinātāja un 1 collas līgumiem.
Visbeidzot, 11. darbībā 1 collas norēķinu līgums pārsūta galamērķa marķierus ražotājam.
Jūtieties brīvi izpētīt šo darījumu vietnē Etherscan:
https://etherscan.io/tx/0x55e621337837f4f69f0c398ad5e9072a24811bbfd8cb2b208d621b940c9689b5