Artikkeli · r8-evm-002
Ethereum-kutsun funktiovalitsin: mitä neljä tavua kertovat?
Kun sovellus kutsuu sopimuksen funktiota tavallisen Solidity ABI -muodon mukaan, kutsudatan neljä ensimmäistä tavua ovat funktiovalitsin. Niitä seuraavat koodatut argumentit. Valitsin auttaa tulkitsemaan pyydettyä funktiota, mutta ei yksin todista, mitä kohdesopimus todella tekee.[3]
Tässä käytetään Solidityn version 0.8.30 ABI-määrittelyä. Se kuvaa sovittua tiedon esitystapaa, ei kaikkien Ethereum-sopimusten pakollista sisäistä toimintaa. Kirjastojen ABI:ssa on omia eroja, ja sopimus voi käsitellä kutsuja myös muulla tavoin.[3] Emme tutki todellista tapahtumaa tai testaa lompakon näyttöä.
Mikä on ABI?
ABI eli application binary interface määrittelee, miten tietoa esitetään sopimusten välisissä ja ulkopuolelta tulevissa kutsuissa. Tieto koodataan tyyppien mukaan. Koodattu tavujono ei kuitenkaan selitä rakennettaan itse, joten tulkinta tarvitsee sopivan skeeman eli tyyppikuvauksen.[3]
Siksi samaa tavujonoa ei kannata lukea irrallaan tiedosta, millä säännöillä se pitäisi purkaa. Käyttöliittymän näyttämä funktion nimi on tulkinta, jonka oikeellisuus riippuu muun muassa käytetystä ABI-kuvauksesta. Pelkkä nimi ei ole todistus kohdesopimuksen tarkoituksesta.
Näin valitsin muodostetaan
ABI-määrittelyssä valitsin on funktion allekirjoituksen Keccak-256-tiivisteen neljä ensimmäistä tavua. Tässä funktion allekirjoitus tarkoittaa tekstimuotoista nimi- ja tyyppikuvausta, ei lompakolla tuotettua kryptografista allekirjoitusta. Siihen kuuluvat funktion nimi ja sulkeissa parametrien kanoniset tyypit pilkuilla erotettuna, ilman välilyöntejä. Parametrien nimet, sijaintimääritykset ja paluuarvon tyyppi eivät kuulu siihen.[3] Keccak-256 ei ole sama kuin standardin FIPS SHA3-256.
Tyypin kirjoitusasulla on merkitystä. Esimerkiksi ABI:n uint on uint256-tyypin synonyymi, mutta valitsinta muodostettaessa käytetään kanonista muotoa uint256.[3] Funktiovalitsimen laskenta ei ole sama asia kuin funktion suorittaminen.
Neljä tavua on lyhyt tunniste: eri allekirjoituksille voi osua sama valitsin. Siksi valitsinta ei pidä käyttää yksin yksiselitteisenä todisteena funktion nimestä tai sen turvallisuudesta. Tulkinnassa tarvitaan myös oikea kohdesopimus ja sen toiminnan arviointi.
Esimerkki: valitsin ja kaksi argumenttia
Solidityn ABI-kuvaus esittää funktion baz(uint32,bool) kutsun, jossa argumentit ovat 69 ja true. Esimerkin valitsin on 0xcdcd77c0. Sitä seuraa kaksi 32 tavun argumenttia: kokonaisluku 69 eli heksadesimaalina 0x45 sekä totuusarvo 1, kumpikin täydennettynä omaan 32 tavun kenttäänsä.[3]
Koko esimerkkikutsudatan pituus on 4 + 32 + 32 eli 68 tavua. Kyse on määrittelyn havainnollistuksesta, ei oikeasta tapahtumasta. Ensimmäiset neljä tavua ovat oletetun ABI-esityksen valitsin ja loput koodattuja argumentteja. Sama valitsin voi vastata useaa allekirjoitusta, joten oikea tulkinta riippuu kohteen koodista ja luotettavasta skeemasta; se ei takaa tiettyä suoritusta.[3]
Kaikki argumentit eivät kuitenkaan sovi näin yksinkertaiseen malliin. ABI erottaa staattiset ja dynaamiset tyypit. Ylimmän tason argumenttituplen dynaamisen arvon sijainti ilmoitetaan suhteessa koodatun argumenttiosan alkuun, ei valitsimen ensimmäiseen tavuun. Sisäkkäisissä tupleissa ja taulukoissa siirtymän kanta määräytyy kyseisen sisäkkäisen koodauksen mukaan, eikä aina ylimmän tason alusta. bytes-arvon sisältöosassa ilmoitetaan tavujen määrä ja sisältö täydennetään oikealta; string-arvon pituus lasketaan UTF-8-tavuina, ei merkkeinä.[3]
Miksi tulkinta ei vielä kerro lopputulosta?
Oletetaan, että näkymä tunnistaa neljä tavua funktion valitsimeksi ja näyttää kaksi argumenttia. Se on alku tavujonon tulkinnalle, ei vahvistus siitä, että kohde toimii halutulla tavalla. Merkitys riippuu myös siitä, mikä koodi käsittelee kutsun ja missä tilassa se suoritetaan.
Valitsimen nimihaku ja sovelluksen tarjoama ABI voivat antaa moniselitteisen tai väärän tulkinnan. Kaikki allekirjoituspyynnöt eivät ole tapahtumia tai ABI-funktiokutsuja: esimerkiksi ketjun ulkopuolella allekirjoitettava viesti on eri asia. Jos purettu pyyntö, kohde, verkko tai seuraukset jäävät epäselviksi, älä allekirjoita vain siksi, että nimike kuulostaa tutulta. Aihetta sivuaa erillinen sokeaa allekirjoitusta käsittelevä artikkeli new-059; sen lompakkonäkymää ei ole tässä testattu. Tarvittaessa pyydä pätevää teknistä asiantuntijaa arvioimaan kohde ja rajapintakuvaus.
Valitsin on siis rajattu työkalu: se erottaa neljän tavun valitsinkentän argumenteista oletetussa ABI-esityksessä, mutta ei tunnista funktiota yksikäsitteisesti. Se ei yksin todista sopimuksen aitoutta, tarkoitettua vaikutusta tai myöhemmän suorituksen lopputulosta. Tässä ei ole testattu lompakkoa, tapahtumaa tai allekirjoituspyyntöä.