Artikkeli · r7-evm-001

Ethereum-tapahtuman kuitti: mitä onnistuminen ja lokit oikeasti kertovat?

Ei sijoitusneuvontaa.

Ethereumin tapahtumakuitti kertoo muun muassa, onnistuiko tapahtuman ylimmän tason suoritus ja mitä lokimerkintöjä kuittiin sisältyi. Se ei yksin kerro, että käyttäjän tarkoittama lopputulos saavutettiin, että vastaanottava palvelu hyvitti varat tai että lohko pysyy lopullisessa ketjussa. Nämä ovat eri tarkistuksia.[1], [2]

Tarkastelemme tässä Ethereum-pääverkon Byzantium-päivityksen jälkeistä kuittimallia. EIP-658:ssa status 1 tarkoittaa ylimmän tason suorituksen onnistumista ja 0 epäonnistumista.[1] Muissa EVM-verkoissa, historiallisissa lohkoissa ja eri tapahtumatyypeissä tarkista sovellettavat säännöt erikseen.

Mitä kuitti sisältää?

EIP-1474:n dokumentoimassa JSON-RPC-mallissa tapahtumatunnisteella haettava kuitti sisältää lohkon tunnisteen ja numeron, tapahtuman tunnisteen, käytetyn kaasun, tilan sekä lokiluettelon. Kuittia ei ole saatavilla keskeneräiselle tapahtumalle.[2] null tai puuttuva tulos ei siis ole sama asia kuin status 0: tarkista myös verkko, tunniste, palvelun historiatiedot ja vastauksen asiayhteys. EIP-1474 on Stagnant, eikä se takaa jokaisen palveluntarjoajan toimintaa.[2] RPC:n gasUsed kuvaa kyseistä tapahtumaa; konsensuskuitin cumulative_transaction_gas_used on eri kenttä.[2], [5]

Tila vastaa kysymykseen suorituksen ylimmästä tasosta, ei siihen, onnistuiko jokainen sisäinen kutsu. EIP-140 määrittelee, että sisäinen REVERT palauttaa kutsuoperaatiolle epäonnistumisen; kutsuva koodi voi käsitellä tämän tuloksen.[3] Siksi sisäinen epäonnistuminen ja koko tapahtuman epäonnistuminen ovat eri asioita. Pelkkä status 1 ei kerro kaikkien sisäisten toimintojen onnistuneen halutulla tavalla.[1], [3]

Kuvitteellinen esimerkki: sovellus pyytää sopimusta tekemään kaksi tarkistusta. Ensimmäinen sisäinen kutsu palautuu virheellä, mutta kutsuva ohjelma on kirjoitettu jatkamaan ja päättyy onnistuneesti. Kuitti voi silloin näyttää status 1. Oikeaa tapahtumaa ei ole testattu; lopputulos riippuu sopimuskoodista.

Entä loki?

Kuitti voi sisältää sopimuksen tuottamia lokimerkintöjä.[2], [5] Loki on tapahtumasta tallennettu viesti, jota täytyy tulkita sen tuottaneen sopimuksen ja tapahtuman kontekstissa. Merkinnän nimi tai käyttöliittymän antama selitys ei yksin todista, että sovelluksen taloudellinen tai liiketoiminnallinen tavoite toteutui. Tarkista sopimusosoite, verkko ja mitä kyseinen sopimus todella tekee.

REVERT kumoaa kyseisen kehyksen ja sen jälkeläisten tilavaikutukset ja lokit.[3] Kuvitellaan, että sisäkutsu peruutetaan, kutsuja käsittelee virheen, tuottaa oman lokinsa ja päättyy onnistuneesti: kuitti voi sisältää kutsujan lokin ja statuksen 1, mutta ei perutun kehyksen lokia. Jos ylempi kehys myöhemmin peruutetaan, myös siinä aiemmin onnistuneiden alikutsujen vaikutukset ja lokit kumoutuvat. Ylimmän tason peruutuksessa EVM-suorituksen lokit eivät jää kuittiin.[3], [5] Tämä on malliesimerkki, ei solmutesti.

Epäonnistunut ylimmän tason suoritus ei tarkoita maksutonta tapahtumaa tai koko transaktiota edeltävän tilan täydellistä palautumista. Kaasumaksu ja lähettäjän noncen muutos kuuluvat erikseen tarkasteltavaan tapahtumankäsittelyyn.[5], [14] EIP-7702:n tapauksessa jo käsiteltyjä delegointiosoittimia ei sen mukaan palauteta vain siksi, että myöhempi suoritus epäonnistuu.[9] Tämä ei tarkoita, että perutun kehyksen lokit säilyisivät.

Miksi kyselyn ajankohta kannattaa kirjata?

Lohkon jälkeinen tilakysely voi sisältää myös saman lohkon myöhempien tapahtumien vaikutukset. Siksi edes saman lohkohashin käyttö tai edellisen lohkon ja kohdelohkon tilojen vertailu ei yleensä eristä yhtä tapahtumaa. EIP-1898:n blockHash ja requireCanonical auttavat kiinnittämään kyselyn lohkoon, eivät tuota tapahtumakohtaista tiladiffiä.[8]

Kirjaa verkko, lohkon tunniste ja tapahtuman paikka lohkossa. Yhden tapahtuman muutosta voidaan selvittää esimerkiksi luotettavalla uudelleensuorituksella, jäljityksellä tai tiladiffillä oikeasta esitilasta ja oikeassa järjestyksessä. Menetelmän ja sen tuloksen luotettavuus on arvioitava erikseen; tässä ei ole tehty sellaista testiä.

Tarkista kuitti ja tulos erikseen

Vertaa ensin tapahtumatunnistetta, verkkoa ja kuittiin merkittyä lohkoa. Tarkista sitten status ja asiaankuuluvat lokit sekä se, mitä sovellus tai vastaanottava palvelu näyttää. Jos tavoite oli esimerkiksi palveluun tehtävä talletus, selvitä sen oma hyvitystila: ketjun kuitti ei ole sama asia kuin palvelun kirjanpidon hyvitys.

Pelkkä RPC-vastaus ei itsessään ole kryptografinen todiste. Lohko-otsakkeen kuittijuuri sitoo kuitit kuittipuuhun; oikein varmennettu kuittisisällytyksen todistus voi osoittaa kuitin ja sen lokien sisältymisen kyseiseen otsakkeeseen.[10] EIP-1186:n tilatodiste taas koskee tilajuurta ja kyseistä lohkotilaa, ei yksin yhden tapahtuman muutosta.[13] Kummassakin tarvitaan lisäksi oikean verkon luotettu tai erikseen varmennettu otsake sekä erillinen kanonisuuden ja finaliteetin arvio. Pelkkä loki ei todista palvelun hyvitystä.

Lohkon tunniste auttaa yksilöimään havainnon, mutta lohkoketjun tila voi muuttua uudelleenjärjestelyn yhteydessä.[8] Varmennusten ja lopullisuuden tulkinta on selvitettävä verkon ja vastaanottajan ehtojen mukaan. Tarkista tarvittava saldo tai sopimuksen tila oikeasta verkosta ja soveltuvasta lohkosta; myöhempi tilakysely voi kuvata jo muuttunutta tilannetta. Käyttöliittymää, RPC-palvelua tai todellista transaktiota ei ole tässä testattu.