Nasa ibaba ang isang pinaikling bersyon ng ulat ng The Block Research na "A Deep Dive into the Future of Onchain Liquidity Routing." Ang buong PDF na bersyon ng ulat na ito ay matatagpuan dito.

Sa isang nahahati-hating onchain market, hindi na garantisado ang pinakamahusay na pagpapatupad sa pamamagitan ng pananatili sa iisang lugar. Ang liquidity na dating matatagpuan sa iilang lugar ay sumasaklaw na ngayon sa libu-libong pool at dumaraming set ng mga lugar ng DEX sa iba't ibang network, bawat isa ay nag-aalok ng iba't ibang presyo at lalim ng liquidity. Ang pagkakahiwa-hiwalay na ito ay nagiging isang kumplikadong problema sa paghahanap at pag-optimize ang isang simpleng pagpapalit ng token.

Umiiral ang mga DEX aggregator upang alisin ang pagiging kumplikado at magbigay sa mga user ng iisang pinakamahusay na opsyon. Sa konsepto, ginagampanan nila ang parehong papel ng isang flight search engine. Sa halip na pilitin ang mga user na suriin ang bawat lugar isa-isa, sinusuri ng isang aggregator ang market at nagbibigay ng ruta na nagpapataas ng kalidad ng pagpapatupad. Habang lumalawak ang aktibidad sa onchain at patuloy na nahahati-hati ang liquidity, ang mga aggregator ay hindi na lang isang kaginhawahan; sila ay lalong nagiging default na access layer para sa mahusay na onchain trading.

Sa mekanika, ang isang aggregator ay kumukuha ng instruksyon ng user tulad ng "palitan ang X ng token A para sa hindi bababa sa Y ng token B" at ginagawa itong plano ng pagpapatupad. Upang magawa ito, umaasa ang mga aggregator sa dalawang pangunahing bahagi ng imprastraktura: isang routing engine at isang transaction protection layer.

Ang routing engine ang pangunahing sistema ng pagdedesisyon ng aggregator. Ang trabaho nito ay hanapin ang pinakamabisang paraan upang makakuha ng liquidity sa iba't ibang onchain venue at kumpletuhin ang kalakalan. Ginagawa ito sa pamamagitan ng dalawang magkakaugnay na gawain.

Ang una ay ang pathfinding, na naghahanap sa mga posibleng ruta ng pagpapalit, kabilang ang multi-hop na ruta, upang matukoy ang isang mahusay na ruta sa ilalim ng kasalukuyang kondisyon ng liquidity. Ito ay hindi madali sa komputasyon dahil mabilis na lumalaki ang espasyo ng paghahanap sa dami ng mga venue at intermediate asset, habang patuloy na nagbabago ang kapaligiran habang nag-a-update ang mga estado ng pool sa bawat block. 

Ang pangalawa ay ang order splitting. Kahit na kaya ng isang venue na punan ang isang kalakalan, ang pagtulak ng malaking order sa iisang ruta ay madalas na nagreresulta sa malaking price impact. Kaya't hinahati ng routing engine ang order sa maraming pinagmumulan ng liquidity upang mabawasan ang pangkalahatang price impact. Gayunpaman, pinapataas nito ang pasanin sa pag-optimize dahil ang problema sa pagruruta ay nagiging parehong "aling mga ruta" at "sa anong proporsyon" sa ilalim ng mahigpit na paghihigpit sa oras.

Habang ino-optimize ng routing engine ang presyo, ang transaction protection layer naman ay nakatuon sa pagpapanatili ng halagang iyon sa panahon ng pagpapatupad. Pinapababa ng imprastrukturang ito ang slippage mula sa mapanirang daloy, pinakakita ang mga gawi na hinimok ng MEV tulad ng sandwich attack. Ang ugat ng isyu ay ang mga nakabinbing transaksyon sa mempool ay pampubliko, na nagbibigay sa mga MEV searcher ng pagkakataong unahan ang mga kalakalan upang kumuha ng halaga sa kapinsalaan ng mga user.

Samakatuwid, ang mga aggregator ay nakikipagkumpitensya hindi lamang sa paghahanap ng kaakit-akit na ruta sa papel, kundi sa kung gaano sila patuloy na makapaghatid ng inihayag na resulta sa totoong kondisyon, madalas sa pamamagitan ng paglilimita sa pagtagas ng impormasyon upang mapababa ang pagkuha ng MEV. Dito nagiging "pinakamahusay na epektibong spread" ang "pinakamahusay na presyo," at dito nagsisimulang magmukhang imprastraktura ang mga aggregator sa halip na isang simpleng feature ng UI.

Direktang nakakaapekto ang mga mekanismong iyon sa istruktura ng merkado. Hindi lang tinutulungan ng mga aggregator ang mga user na makahanap ng mas mahusay na presyo; inililipatan din nila ang daloy ng order sa iba't ibang venue, tinutukoy kung aling mga modelo ng liquidity ang nananatiling mapagkumpitensya, at nagsisilbing default na access point sa pagitan ng mga user at venue. Sa paglipas ng panahon, inililipat nito ang kapangyarihan sa negosasyon palayo sa mga indibidwal na DEX at patungo sa mga aggregator na kumokontrol sa distribusyon, routing intelligence, at pagiging maaasahan ng pagpapatupad.

Ang mga naunang aggregator ay kadalasang kahawig ng mga best-of router sa isang solong chain. Inihambing nila ang limitadong set ng mga pool, pumili ng ruta, at nagsagawa ng direktang onchain swap. Habang nahahati-hati ang liquidity at nagbabago ang disenyo ng DEX, naging isang tunay na disiplina sa pag-optimize ang routing, na nangangailangan ng mas malawak na saklaw ng venue, native multi-hop support, at mas matatag na paghawak ng panganib sa pagpapatupad, kabilang ang slippage na nauugnay sa MEV. 

Malinaw ang direksyon ng pag-unlad kahit na magkakaiba ang mga implementasyon: ang mga aggregator ay lumilipat mula sa "pagpili ng ruta" patungo sa "pag-oorkestra ng pagpapatupad," na pinapalawak ang kanilang saklaw mula sa price discovery hanggang sa paghahatid ng resulta.

Ngayon, ang bagong hangganan ay ang delegated execution. Sa halip na mangako sa nakapirming routing nang maaga, ipinapahayag ng mga user ang isang layunin, sabihin nating "palitan ang X ng token A para sa hindi bababa sa Y ng token B," at pinapayagan ang mga third-party na solver na magkumpitensya upang makapaghatid ng pagpuno. Ang disenyo na nakasentro sa layunin na ito ay epektibong inilalabas ang routing at pagpapatupad sa isang mapagkumpitensyang marketplace, kung saan ang mga solver ay nagmumula ng liquidity nang may kakayahang umangkop at isinasaloob ang nauugnay na panganib sa pagpapatupad, sa gayon ay ino-optimize ang kalidad ng pagpapatupad sa ilalim ng totoong kondisyon.

Sinusuri ng ulat na ito ang nagbabagong tanawin ng onchain liquidity routing, na nagdedetalye kung paano lumipat ang mga DEX aggregator mula sa simpleng tool sa paghahambing ng presyo patungo sa sopistikadong orchestrator ng pagpapatupad.