MEV ja sandwich: miksi tokenvaihdon toteutushinta voi heiketä?

Tokenvaihdon toteutushinta voi heiketä, vaikka hyväksyisit vaihtoruudussa näkyvän tarjouksen. Yksi mahdollinen syy on sandwich-hyökkäys: toinen toimija järjestää omat kauppansa sinun vaihtosi molemmille puolille ja hyötyy hinnan muutoksesta. Tämä on yksi MEV:n muoto, ei selitys jokaiselle odotettua huonommalle kaupalle. Ethereum.orgin mukaan sandwichin kohteeksi joutuva käyttäjä saa yleensä huonomman toteutuksen ja kokee enemmän hinnan lipsumista.1

Ennen vahvistusta kannattaa katsoa ainakin odotettu vastaanottomäärä, pienin hyväksyttävä vastaanottomäärä ja kulut. Jos et ymmärrä, mitä ruudulla hyväksyt, voit jättää vaihdon tekemättä. Mikään yksittäinen asetus ei anna yleispätevää takuuta siitä, ettei järjestelyyn liittyvää riskiä ole.

Mitä MEV tarkoittaa?

MEV tulee sanoista maximal extractable value. Ethereum.org kuvaa sillä arvoa, jota voidaan saada muuttamalla lohkon transaktioiden sisällyttämistä, järjestystä tai jättämällä transaktioita pois. Kyse ei siis ole yhdestä tokenista tai erillisestä vaihtopalkkiosta, vaan mahdollisuudesta hyötyä siitä, miten tapahtumat päätyvät lohkoon.1

Lohkoon päätymistä odottava tapahtuma ei välttämättä toteudu siinä järjestyksessä kuin käyttäjät painoivat vahvistuspainiketta. Toimijat, joita kutsutaan usein searchereiksi, etsivät kannattavia tilaisuuksia. Mahdollisuudet ja tapahtumien välittämisen käytännöt riippuvat kuitenkin käytetystä verkosta ja reitistä: Ethereumia koskevaa kuvausta ei kannata siirtää sellaisenaan kaikkiin lohkoketjuihin.1

MEV kattaa sandwichia enemmän. Se, että tapahtuman yhteydessä esiintyy MEV:tä, ei yksin kerro, millainen tapahtuma oli tai kuka siitä hyötyi. Tässä keskitytään erityisesti tilanteeseen, jossa julkisesti näkyvän tokenvaihdon ympärille voidaan järjestää muita kauppoja.

Miten sandwich syntyy?

Kuvitteellinen esimerkki: käyttäjä vaihtaa tokenia A tokeniin B hajautetussa vaihtopalvelussa. Palvelu näyttää arvion saatavasta B:n määrästä. Käyttäjä hyväksyy sen ja lähettää tapahtuman verkkoon, mutta vaihto odottaa vielä toteutustaan.

Toinen toimija näkee odottavan vaihdon ja tekee oman ostonsa ennen sitä. Jos tämä muuttaa samaa likviditeettipoolia käyttäjän kannalta epäedulliseen suuntaan, käyttäjän vaihto saa aiempaa huonomman hinnan. Toimija myy sitten ostamaansa tokenia käyttäjän vaihdon jälkeen. Ethereum.org käyttää juuri tällaista ennen ja jälkeen tehtävien kauppojen asetelmaa sandwich-kaupankäynnin selityksenä.1

Esimerkki havainnollistaa mekanismin, ei kuvaa toteutunutta kauppaa eikä väitä, että mikä tahansa peräkkäisten tapahtumien jono olisi hyökkäys. Toteutukseen vaikuttavat muun muassa poolin tila, kauppojen koko ja niiden järjestys. Toiselle toimijallekaan lopputulos ei ole automaattisesti voitollinen; myös hänellä on kuluja ja riskejä.1

Oleellinen ajatus on, että kaupan näkyminen ennen toteutusta voi antaa muille tietoa, jota käytetään kaupan järjestelyssä. Sinun ei tarvitse rakentaa kaupankäyntijärjestelmää ymmärtääksesi riskin: kysymys on siitä, voiko vastaanottamasi määrä pienentyä verrattuna siihen, mitä odotit.

Tarjous, toteutus ja lipsuma ovat eri asioita

Vaihtoruudun arvio on päätöksenteon lähtökohta, ei sama asia kuin lopullinen toteutunut määrä. Kun tapahtuma lähetetään ja toteutuu myöhemmin, olosuhteet voivat muuttua. Toteutuneen määrän ja odotetun määrän eroa kutsutaan usein lipsumaksi eli slippageksi.

Lipsumalle on kuitenkin useita mahdollisia syitä. Markkinahinta voi muuttua odotusajan aikana ilman, että kukaan sijoittaa kauppoja tarkoituksella omasi ympärille. Myös oman vaihdon vaikutus pooliin on eri asia kuin myöhempi muutos tarjouksen ja toteutuksen välillä. Uniswapin dokumentaatio erottaa swapin hintavaikutuksen ja odotusaikana muuttuvan hinnan toisistaan.12 Siksi pelkkä odotettua pienempi vastaanottomäärä ei todista sandwich-hyökkäystä.

Tarkastele myös sitä, missä vaiheessa palvelu näyttää arvionsa ja mitä se sisällyttää siihen. Verkkomaksu, vaihtoon liittyvä maksu ja vastaanotettavan tokenin määrä voivat näkyä eri kohdissa. Jos vertaat vain ensimmäistä lukua lompakkoon myöhemmin ilmestyvään määrään, et välttämättä tiedä, mikä osa erosta johtui mistäkin.

Hyödyllinen vertailu tehdään samassa yksikössä: paljonko tokenia olit lähettämässä, paljonko palvelu arvioi sinun saavan ja paljonko sait lopulta. Erillinen verkkomaksu on syytä kirjata omana eränään. Näin et sekoita kulua suoraan vastaanottomäärän muutokseen.

Mitä lipsuman rajaaminen tekee?

Monessa vaihtokäyttöliittymässä voi asettaa sallitun lipsuman tai nähdä sitä vastaavan pienimmän hyväksyttävän vastaanottomäärän. Tarkka toiminta riippuu palvelusta ja vaihtotyypistä. Tarkista siis juuri kyseisen sovelluksen vahvistusnäkymä sen sijaan, että olettaisit kaikkien käyttöliittymien laskevan rajan samalla tavalla.

Jos kyseisessä vaihdossa pienin hyväksyttävä määrä on selvästi odotettua määrää alempi, hyväksyt mahdollisuuden huonompaan toteutukseen tämän rajan sisällä. Toisaalta tiukka raja voi tarkoittaa, ettei vaihto toteudu, jos hinta muuttuu liikaa. Epäonnistuneestakin ketjutapahtumasta voi verkosta ja toteutuksesta riippuen syntyä kustannus; tarkista tämä ennen uutta yritystä. Ethereumissa kaasumaksu maksetaan myös epäonnistuneesta toteutuneesta transaktiosta.14

Raja ei ole ennuste toteutushinnasta. Se ei myöskään yksin kerro, onko mahdollinen muutos johtunut tavallisesta markkinaliikkeestä vai toisen toimijan järjestelystä. Ajattele sitä omana hyväksymisrajana: millaista lopputulosta et halua alittaa, jos käyttöliittymä todella soveltaa näytettyä vähimmäismäärää kyseiseen tapahtumaan.

Varo myös rutiinia, jossa epäonnistuneen vaihdon jälkeen rajaa nostetaan vain saadaksesi tapahtuman läpi. Silloin päätös hyväksyä aiempaa heikompi toteutus voi jäädä huomaamatta. Pysähdy sen sijaan katsomaan uusi arvio, kulut ja oma syysi tehdä vaihto juuri nyt.

Voiko yksityinen lähetys auttaa?

Jotkin palvelut tarjoavat vaihtoehtoisia tapahtuman lähetys- tai toteutusreittejä, joita kuvataan esimerkiksi yksityisiksi tai MEV-suojatuiksi. Niiden tavoite voi olla vähentää tapahtuman näkyvyyttä julkisessa odottavien tapahtumien joukossa ennen toteutusta. Esimerkiksi Flashbots kertoo oman Ethereum-palvelunsa lähettävän tapahtumat yksityiseen välitysjärjestelmään sandwich-boteilta piiloon.13 Se ei kuitenkaan tarkoita samaa kuin täydellinen yksityisyys tai varma suoja kaikilta hintavaikutuksilta.

Käytännön ratkaisu riippuu toteutuksesta. Selvitä, ketkä reitin osapuolet ovat, millä ehdoilla tapahtuma välitetään ja mitä tapahtuu, jos se ei toteudu. Tarkista erityisesti, voiko palvelu käyttää muuta reittiä tai siirtyä takaisin julkiseen lähetykseen. Jos dokumentaatio ei kerro tätä ymmärrettävästi, suojauslupausta ei kannata tulkita takuuksi.

Myös vaihtojen pilkkominen tai toisen poolin käyttäminen voi muuttaa tilannetta, mutta nämä eivät ole yleisiä varmoja ratkaisuja. Useammasta tapahtumasta voi syntyä useampia kuluja ja niiden välillä olosuhteet voivat muuttua. Vertaa koko suunnitellun toiminnan ehtoja, älä pelkästään ensimmäisen osan houkuttelevaa arviota.

Miten tarkistan toteutuneen vaihdon?

Aloita oman lompakon ja vaihtopalvelun tapahtumatiedoista. Ota talteen tapahtuman tunniste, käytetty verkko, lähettämäsi ja saamasi token sekä vahvistuksen yhteydessä näytetty arvio, jos se on vielä saatavilla. Ilman alkuperäistä arviota jälkikäteen on vaikea tietää, mihin odotusta pitäisi verrata.

Lohkoselaimesta voi katsoa toteutuneen tapahtuman ja sen lohkon. Jos haluat selvittää nimenomaan sandwich-epäilyä, olennaisia ovat tapahtumien keskinäinen järjestys ja se, vaikuttivatko mahdolliset ympäröivät kaupat samaan vaihtoreittiin. Pelkkä samassa lohkossa näkyminen ei riitä todistamaan yhteyttä.

Älä myöskään anna tunnistautumistietoja tai lompakon palautussanoja kenellekään, joka lupaa selvittää tapahtuman. Julkinen tapahtumatunniste ja oman tapahtuman tiedot ovat eri asia kuin salainen avain. Jos et osaa tulkita tapahtumia, merkitse asia avoimeksi sen sijaan, että nimeät varmasti syyllisen tai tappion syyn.

Milloin vertailu on mielekäs?

Yhtä lukua on helppo katsoa irrallaan: esimerkiksi vastaanotettava määrä voi näyttää suurelta, vaikka sen vastineeksi lähetettävä määrä tai käytetty token poikkeaa siitä, mitä ajattelit. Varmista vertailua varten ensin tokenien nimet, määrät ja verkko. Tarkista myös, näytetäänkö hinta tokenia kohti vai koko vaihdon odotettuna tuloksena. Muuten kahden eri näkymän luvut voivat näyttää ristiriitaisilta ilman, että toteutuksessa on tapahtunut mitään poikkeavaa.

Jos palvelu näyttää sekä hinta-arvion että vähimmäismäärän, niillä on eri tehtävä. Arvio auttaa ymmärtämään, mitä palvelu odottaa tämänhetkisten tietojen perusteella. Vähimmäismäärä puolestaan kuvaa kyseisen toteutuksen ehtoa, jos sovellus sen näin määrittelee. Molempien vertaaminen omaan päätökseen on hyödyllisempää kuin yhden prosenttiluvun hyväksyminen automaattisesti.

Jälkeenpäin tehtävä vertailu on rajallinen, jos et tiedä, mitä ennen vahvistusta näytettiin. Kuvakaappaus voi auttaa muistamaan arvion ja käyttöliittymän ehdot. Älä kuitenkaan tallenna tai jaa kuvaan salaisia tietoja. Tapahtuman julkisen historian perusteella voi tutkia ketjussa näkyvää toteutusta, mutta se ei välttämättä kerro, mitä toinen toimija ajatteli tai miksi tämä toimi.

Mitä sana suojaus ei ratkaise?

Suojaus on hyödyllinen termi vasta, kun sen sisältö on selvillä. Yksi palvelu voi tarkoittaa sillä tapahtuman lähetysreittiä ja toinen ehtoa, jonka perusteella vaihto keskeytetään. Kolmas voi käyttää useita menetelmiä. Tarkista, mitä juuri oma palvelusi lupaa ja onko lupaus kuvattu teknisenä ehtona vai yleisenä markkinointiväitteenä.

Päätöstä voi helpottaa kysymällä ennen vahvistusta: mitä tietoa reitistä annetaan, millä ehdolla toimeksianto raukeaa ja mitä kustannuksia syntyy, jos sitä yritetään uudelleen? Jos näihin ei löydy vastausta, epävarmuus on osa valintaa. Odottaminen tai koko vaihdon peruuttaminen ennen lähettämistä voi olla järkevämpi vaihtoehto kuin hyväksyä ehto, jota ei ymmärrä.

Tarkista nämä ennen vahvistusta

• Vastaavatko lähetettävä token, vastaanotettava token ja verkko sitä, mitä olit tekemässä?
• Mikä on arvioitu vastaanottomäärä ja mikä on pienin hyväksyttävä määrä tässä käyttöliittymässä?
• Mitkä kulut näkyvät erikseen ja voiko epäonnistuneesta yrityksestä tulla kuluja?
• Onko käytössä ilmoitettu erityinen toteutusreitti, ja ymmärrätkö sen rajoitukset?
• Oletko valmis jättämään vaihdon tekemättä, jos hyväksyttäväksi asetettu lopputulos on liian huono?

Sandwich on siis yksi mahdollinen selitys toteutuksen heikkenemiselle, ei jokaisen hintaeron diagnoosi. Kun erotat arvion, hyväksymisrajan ja lopullisen tapahtuman toisistaan, sinun on helpompi päättää, mitä olet valmis hyväksymään — ja jälkikäteen selvittää, mitä todella tapahtui.