Třetí článek v naší sérii vysvětlující režim Fusion je zaměřen na onchain komponentu swapového řešení.

Ve dvou předchozích článcích této série jsme diskutovali o konceptu resolveru a offchain komponentu procesu swapového řešení.

Pokračujme tam, kde jsme přestali. Nacházíme se ve fázi procesu řešení swapu, kdy se backend překladače „rozhodl“ vyplnit objednávku Fusion, kterou obdržel od 1palcové reléové služby v určitém bloku, určitým množstvím swapovaného aktiva, které má být vráceno zpět uživatel. Nyní projdeme onchainovou částí procesu řešení swapu. Nejprve však popíšeme účastníky tohoto procesu.

Onchain část provádění Fusion swap zahrnuje poměrně složité interakce mezi následujícími blockchainovými entitami:

Velmi důležité upozornění: v některých případech (ne vždy) překladač provede několik vyplnění v jedné dávce, až 32. Obvykle je v pracovní smlouvě překladače několik zůstatků tokenů a backend může vzít několik objednávek z „streamu“ které relé poskytuje, a proveďte sekvenci výplní.

Projdeme si následující scénář.

Řešitel vybral 3 potenciálně lukrativní objednávky od překladatele k vyřízení:

  • 100 DAI za alespoň 0,6 WETH

  • 0,6 WETH po dobu nejméně 100 DAI

  • 0,01 WBTC po dobu nejméně 36 UNI

Obchodním cílem resolveru je provést všechny 3 swapy tak, aby uživatelé získali alespoň částku, kterou očekávali. Vynecháme možné strategie výdělku řešitelů a zjednodušíme výpočty, abyste porozuměli obecné myšlence.

Nyní backend poskytuje informace o vybraných objednávkách do pracovní smlouvy. Co se stane dál?

Pozn.: tento graf je pokračováním jednoho z článku věnovanému offchain komponentě swapového řešení. Pro snazší pochopení však začneme od kroku 1.

Krok 1

Pracovní smlouva (nebo peněženka) volá metodu settleOrders() 1palcové smlouvy o vyrovnání a doručuje informace o objednávce v odlehčeném komprimovaném formátu bajtů; K ukládání těchto informací se používají argumenty calldata a tokensAndAmounts.

Zde si můžete všimnout několika zajímavých detailů:

  • rateBump pochází od dodavatele a efektivně určuje návratnost. Je to procentuální rozdíl mezi aktuální aukční částkou a minimální aukční částkou. Pokud je například hodnota rateBump 4_000_000 a auctionEndAmount (min. návratnost) je 500, bude aktuální aukce 700.

  • totalFee je poplatek, který musí všichni řešitelé platit 1palcové nadaci (Důležité: v současnosti se tato funkce nepoužívá – překladači neplatí žádné poplatky 1palcové nadaci).

  • limitOrderProtocol je instancí protokolu, který je deklarován ve smlouvě o vyrovnání prostřednictvím příslušného rozhraní Solidity. Používá se k volání této smlouvy ze smlouvy o narovnání.

Krok 2

Smlouva o vypořádání volá metodu fillOrderTo() smlouvy o limitní objednávce a dodává data jedné ze 3 objednávek ze seznamu – řekněme 100 DAI za alespoň 0,6 WETH:

  • Interakce - obsahuje informaci, že jsou hromadně další 2 objednávky, které bude nutné následně provést.

  • Vytváření nebo přijímání částek – doslova kolik zaplatit nebo kolik získat. Pouze jedna z těchto částek může být nenulová. Pokud nastavíte makingAmount, určíte, kolik chcete jako překladač dostávat. Případně nastavením takingAmount určíte, kolik byste chtěli prodat jako překladač. Jeden bude vypočítán na základě druhého.

  • Cíl – adresa pracovní smlouvy, která obdrží zdrojové tokeny.

Kroky 3-4

Smlouva o limitní objednávce volá smlouvu se zdrojovým tokenem, aby převedla swapovou částku od uživatele do pracovní smlouvy překladače pomocí rozhraní ERC20 Solidity.

Součást sestavy, která není pro člověka příliš čitelná, tvoří calldata a volá kontrakt tokenu. Montážní díly smlouvy jsou vytvořeny pro úsporu plynu a dodání komplexních dat.

Kroky 5-6

Smlouva o limitní objednávce zavolá zpět smlouvu o vypořádání metodou nazvanou  fillOrderInteraction() a odešle interactiveData obsahující informace o dalších objednávkách v dávce (informace dříve obdržené v interakcích). Na straně vypořádání kód dekóduje interaktivní data a převede je zpět na interakce.

Pokud dávka neobsahuje žádné další objednávky (scénář 1 níže), dokončí interakci a zavolá pracovní smlouvu řešitele, která jí „řekne“, aby vyřešila objednávky. To bude možné, protože pracovní smlouva bude importovat naše rozhraní nazvané IResolver. V Solidity se interakce mezi smlouvami obvykle provádějí tímto způsobem. Co pracovník dělá, probereme v krocích 16–17 níže.

Pokud v dávce zůstanou nějaké další příkazy, smlouva o vypořádání znovu vyvolá smlouvu o limitním příkazu. Tyto dvě smlouvy si budou vyměňovat data, dokud nebudou vypořádány všechny objednávky a shromážděny všechny prostředky z účtů uživatelů (100 DAI, 0,6 WETH a 0,01 WBTC v našem příkladu).

Krok 7

Jsme téměř hotovi. Smlouva mezi pracovníky a řešením problémů obdržela všechny prostředky od uživatelů prostřednictvím 1palcových vypořádacích a limitních smluv. Nyní je čas skutečně vyřešit objednávky!

Zde jsou vlastnosti objednávek:

  • Objednávka 1: 100 DAI za minimálně 0,6 WETH

  • Objednávka 2: 0,6 WETH za minimálně 100 DAI

  • Objednávka 3: 0,01 WBTC za minimálně 36 UNI

Vypadá to, že můžeme doslova spárovat objednávku 1 a objednávku 2 bez jakýchkoli dalších akcí. Takže bezpečně odešleme 0,6 WETH získaných od uživatele, který odeslal objednávku 2, uživateli, který odeslal objednávku 1, a naopak. Objednávky 2 ze 3 byly tedy vyřešeny pomocí vlastních prostředků uživatelů.

Poslední zbývající objednávka je swap 0,01 WBTC za 36 UNI. Pracovní smlouva neobsahuje žádné UNI. Pracovní smlouva tedy nazývá smlouvu o 1palcovém agregačním směrovači stejným způsobem, jakým to dělá každý uživatel ve starším swapu. Backend překladače může zavolat naše agregační API, aby získal optimální trasu a předal ji pracovníkovi k provedení. Router provede tuto swap a dodá 36 UNI do resolveru.

V tomto zjednodušeném příkladu resolver nevydělával nic, ale utratil prostředky za plyn na přenos dat mezi smlouvami. V reálném životě, jak je uvedeno výše, by backend překladače zohlednil všechny náklady a zajistil by, aby pro ně byly obchody ziskové a zůstaly v rámci poskytovaném službou kótování. Řešitel by se také snažil, aby swap byl pro uživatele maximálně ziskový.

Kroky 8-11

Nyní, když má pracovník-řešitel cílové tokeny, musí reagovat na zpětné volání a převést je do smlouvy o vypořádání. Ale počkat... Proč nemohou poslat tokeny přímo uživateli?

Ne, nemohou kvůli způsobu implementace architektury. Pamatujte, že krokem 5 tohoto postupu je zpětné volání metody fillOrderTo() volané smlouvou o vyrovnání ke smlouvě o limitní objednávce. Funkce se tedy stále provádí!

Vzhledem k tomu, že volající byla smlouva o vypořádání, v této konfiguraci se považuje za příjemce objednávky. Předpokládá se tedy, že tato instance obdrží odpověď od překladače a přenesených tokenů. Poté schválí smlouvu o limitní objednávce, která zase zavolá transferFrom() do cílové smlouvy o tokenu a částka swapu nakonec přistane v peněžence uživatele. Jsme hotovi!

Skutečný příklad Etherscanu

Jako poslední cvičení si zopakujme skutečný případ swapu Fusion: 1INCH na DAI, vyřešený řešitelem Seawise a jeho převody tokenů ERC20. Chcete-li dosáhnout nejlepšího výsledku, musíte zkřížit odkaz na obrázek níže s výše uvedeným diagramem, který odpovídá krokům.

V kroku 4 zavolá smlouva limitní objednávky transferFrom() na smlouvě o tokenu 1INCH, aby přenesl zdrojový token z adresy výrobce (0x90…9044) na adresu resolveru.

Kroky 5 a 6 nejsou v tomto seznamu zohledněny, protože nezahrnují žádné převody tokenů ERC20.

V kroku 7 Seawise jako resolver swapuje 1INCH za DAI v Uniswap poolu jako zdroj likvidity.

V kroku 8 společnost Seawise převede DAI na smlouvu o vypořádání 1 palce.

Kroky 9 a 10 jsou zde také přeskočeny, protože se jedná o interní zpětné volání mezi kontrakty překladače a 1palcovým kontraktem.

Nakonec v kroku 11 smlouva o vypořádání 1 palce převede cílové tokeny na výrobce.

Neváhejte a prozkoumejte tuto transakci na Etherscan:

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