Artikkeli · r6-network-001
Ethereumin väliaikainen tallennus: mitä tapahtuu tapahtuman lopussa?
Ethereumin väliaikainen tallennus eli transient storage säilyttää sopimuksen työarvoja vain yhden tapahtuman ajan. Arvot poistetaan tapahtuman päättyessä. Se ei siis ole tapa tallentaa tietoa seuraavaa tapahtumaa varten, mutta se voi auttaa saman tapahtuman sisäisiä sopimuskutsuja jakamaan tilaa.[1]
Tässä on kyse Ethereum-virtuaalikoneen eli EVM:n suoritusmekanismista, ei siitä, että kaikki sopimuksen tiedot olisivat väliaikaisia. Sopimus voi käyttää erikseen myös pysyvää tallennustilaa. EIP-1153 määrittelee väliaikaiselle tilalle omat luku- ja kirjoitusoperaationsa.[1]
Miksi yksi tapahtuma tarvitsee yhteistä työtilaa?
Yksi tapahtuma voi käynnistää useita sisäkkäisiä sopimuskutsuja. Sama sopimus voi tulla suoritetuksi saman tapahtuman aikana useammassa kutsukehyksessä. Tällöin sopimuksen eri kehykset voivat käyttää samaa väliaikaista tallennustilaa, vaikka kunkin kehyksen tavallinen muisti on erillinen.[1]
Ajatellaan kuvitteellista sopimusta, joka asettaa väliaikaiseen paikkaan merkin toiminnon ajaksi. Jos samaan sopimukseen palataan sisäkkäisen kutsun kautta, uusi kehys voi lukea merkin ja toimia ohjelmaan kirjoitetun ehdon mukaan. Merkki ei itsessään tee mitään: sopimuskoodin pitää tarkistaa ja käsitellä se. EIP mainitsee tällaisen uudelleensisäänpääsyn lukituksen yhtenä mahdollisena käyttökohteena.[1]
Onnistunut funktion paluu ei tyhjennä väliaikaista tilaa: myöhempi saman tapahtuman kutsu voi nähdä jätetyn arvon tai lukon. Jos lukon tehtävä sitä edellyttää, sopimuskoodin on purettava se; muuten myöhempi toiminto voi estyä tai syntyä muita virheitä.[1]
Tämä on havainnollistus, ei kuvaus tietyn sovelluksen suojauksesta. Pelkkä tieto väliaikaisen tallennuksen käytöstä ei osoita, että lukitus olisi toteutettu oikein tai että sopimus olisi turvallinen.
Ajattele eroa näin: pysyvään tallennustilaan kirjoitettu tila voi olla relevantti myös seuraavalle tapahtumalle, kun taas väliaikaisen tilan arvoa käytetään saman tapahtuman sisäisen työn järjestämiseen. Kyse ei ole käyttäjän lompakon saldoluettelosta eikä tavasta säilyttää tokenien käyttöoikeutta seuraavaan tapahtumaan. Väliaikainen token-hyväksyntä saman tapahtuman ajaksi on kuitenkin yksi EIP:n mainitsemista mahdollisista käyttökohteista.[1]
Kenen tilaa luetaan?
Tila kuuluu sopimukselle, eikä mikä tahansa toinen sopimus saa lukea sitä kuin yhteistä julkista muuttujaa. Saman omistavan sopimuksen kehykset kuitenkin näkevät sen saman tapahtuman aikana.[1]
Tässä kutsutavalla on merkitystä. Tavallisessa CALL-kutsussa käytetään kohteena olevan sopimuksen väliaikaista tilaa. DELEGATECALL-kutsussa taas omistajana on kutsun tehnyt sopimus. Se, minkä sopimuksen koodia suoritetaan, ei siis yksin vastaa kysymykseen, kenen tallennustilaa operaatio käyttää.[1]
Tämä ero on tärkeä esimerkiksi silloin, kun tutkitaan sopimuksen ja sen käyttämän toteutuskoodin välistä työnjakoa. Ilman tietoa kutsutyypistä ei kannata päätellä, että kaksi erillistä osoitetta käyttäisivät samaa tilaa.
Mitä peruutus ja vain luku muuttavat?
Jos kutsukehys palautuu revert-virheellä, sen sisällä tehdyt väliaikaiset kirjoitukset perutaan. Sama koskee kyseisen kehyksen sisäisissä kutsuissa tehtyjä kirjoituksia. Kyse ei kuitenkaan ole siitä, että jokainen sisäisen kutsun virhe automaattisesti poistaisi kaiken koko tapahtumassa aiemmin tehdyn: rajaus riippuu siitä, mikä kehys palautuu.[1]
STATICCALL-kontekstissa väliaikaista tilaa voi lukea TLOAD-operaatiolla, mutta TSTORE-kirjoitus aiheuttaa poikkeuksen. Vain luku ei siis muutu kirjoittamiseksi vain siksi, ettei tieto ole pysyvää.[1]
Lopuksi koko tapahtuman väliaikainen tila poistetaan. Jos sopimuksen tarvitsee muistaa arvo tulevassa, erillisessä tapahtumassa, tätä mekanismia ei voi sellaisenaan käyttää sen säilyttämiseen.[1] Tarkista aina kyseisen verkon säännöt ja sopimuskoodi: tämä teksti kuvaa EIP-1153:n mekanismia, ei jokaisen EVM-yhteensopivan verkon käyttöönottoa.