Artikkeli · r7-evm-002

Ethereum-tapahtuman chain ID: milloin allekirjoitus kelpaa toisessa verkossa?

Ei sijoitusneuvontaa.

Chain ID eli ketjutunnus on yksi tapa rajata Ethereum-tyyppisen tapahtuman allekirjoitus tiettyyn ketjuun. Jos kaksi ketjua käyttää eri tunnuksia ja molemmat tarkistavat ne kyseisen tapahtumatyypin sääntöjen mukaisesti, yhdelle tarkoitettu suojattu tapahtuma ei sellaisenaan läpäise toisen ketjutunnuksen tarkistusta.[4], [5] Tämä ei ole yleinen takuu siitä, että kaikki allekirjoitukset tai kaikki verkot ovat suojassa uudelleentoistolta.

Uudelleentoisto tarkoittaa tässä sitä, että sama allekirjoitettu tapahtuma yritetään toimittaa myös toiseen ketjuun. Kysymys ei ole vain siitä, näyttääkö osoite samalta eri verkoissa. Olennaista on, mitä allekirjoitus sitoo ja millaiset kelpoisuussäännöt kohdaketjussa ovat käytössä.

Vanha tapahtumamuoto ja EIP-155

EIP-155 määritteli tavan sisällyttää ketjutunnus vanhan eli legacy-tapahtuman allekirjoitettavaan sisältöön. Suojattua muotoa käytettäessä myös allekirjoituksen v-arvon muodostus riippuu chain ID:stä.[4] Suoja on siis osa allekirjoituksen tarkistamista, ei pelkkä lompakon näyttämä verkkonimi.

Kuvitteellinen laskuesimerkki: EIP-155:n määritelmän mukaisella chain ID:llä 1 suojatun legacy-allekirjoituksen v voi olla 37 tai 38. Lasku on 1 × 2 + 35 = 37 tai 1 × 2 + 36 = 38.[4] Nämä luvut eivät ole yleinen tapa tulkita kaikkia Ethereum-tapahtumia: tyyppi ja sen koodaus ratkaisevat.

EIP-155 säilyttää myös aiemman allekirjoitusmuodon, jossa v on 27 tai 28.[4] Tässä vanhassa muodossa ketjutunnusta ei sidota allekirjoitukseen EIP-155:n mukaisesti. Siksi ei pidä olettaa, että jokainen legacy-tapahtuma sisältää tämän rajauksen. Toisessa ketjussa hyväksyminen riippuu lisäksi sen omista säännöistä ja muista tapahtuman kelpoisuusehdoista.

Uudempi muoto ei käytä samaa v-laskua

EIP-1559:n määrittelemässä tyypin 2 tapahtumassa chain_id on oma kenttänsä allekirjoitettavassa sisällössä. Myös tyyppitavu 0x02 sisältyy allekirjoitettavaan sisältöön, ja allekirjoituksen y-pariteetti, r ja s esitetään erikseen.[5] Älä siis sovella legacy-muodon 37/38-esimerkkiä sellaisenaan tämän tyypin kenttiin. EIP-2718 on tyyppikuori: se suosittaa tyypin sisällyttämistä tulevien tyyppien allekirjoituksiin, mutta ei takaa kaikille tyypeille samanlaista chain ID -kenttää. Kunkin tyypin oma määritelmä ratkaisee.[10]

Kuvitellaan kaksi EIP-1559:n sääntöjä noudattavaa verkkoa, joilla on eri ketjutunnus. Tyypin 2 tapahtuma, joka on allekirjoitettu ensimmäisen verkon tunnuksella, ei täytä toisen verkon ketjutunnustarkistusta sellaisenaan. Jos tunnukset ovat samat, pelkkä chain ID ei erota ketjuja toisistaan: muutkin kelpoisuusehdot ovat silti tarpeen. EIP-1344 käsittelee saman tunnuksen käyttöä ketjujen jakaantuessa mahdollisena uudelleentoistoriskinä.[6]

Miksi tunnus ei ratkaise koko tilannetta?

Kuvitteellisessa jakautumistilanteessa kaksi ketjua voi aluksi käyttää samaa tunnusta. Silloin tämän tunnuksen sisällyttäminen allekirjoitukseen ei yksin kerro, kumpaan haaraan tapahtuma on tarkoitettu. EIP-1344 nostaa saman tunnuksen säilyttämisen jakautumisen jälkeen esiin turvallisuusongelmana.[6] Esimerkki ei väitä, että jokin nimetty verkko olisi juuri nyt tässä tilanteessa.

Sama tunnus ei toisaalta tarkoita, että tapahtuma varmasti toteutuu toisessa ketjussa. Kohdeverkon tyyppi- ja fork-säännöt, nonce tai varat ja muut kelpoisuusehdot voivat estää sen.[5] Tästä syystä sekä automaattinen kelpaaminen että automaattinen estyminen olisivat liian vahvoja yleisväitteitä.

Mitä käyttäjän kannattaa tarkistaa?

Varmista lompakossa ja vastaanottajan ohjeissa oikea verkko ennen allekirjoittamista. Vertaa myös vastaanottajaa, tapahtuman sisältöä ja pyynnön tarkoitusta. Ketjutunnus ei vahvista, että verkkopalvelu on aito, vastaanottaja luotettava tai sopimuskutsu turvallinen.

Tässä käsitellään tapahtuma-allekirjoituksia, ei kaikkia erillisiä viesti- tai valtuutusallekirjoituksia. Niiden suoja riippuu erikseen kyseisen viestimuodon sekä sen tarkistavan sovelluksen, palvelun tai sopimuksen säännöistä; EIP-155:n tapahtumasuoja ei yksin kata niitä.[4], [6] EIP-7702-valtuutustuple on erillinen allekirjoitus: sen chain_id=0 voi sen sääntöjen mukaan kelvata useammassa sitä tukevassa verkossa, jos muut ehdot täyttyvät, vaikka ulompi tapahtuma olisi verkkoon sidottu. Tämä ei tarkoita automaattista hyväksymistä.[9] EVM-yhteensopiva verkko ei välttämättä käytä täsmälleen samoja asetuksia kuin Ethereum-pääverkko. Verkkoja, lompakoita eikä oikeita allekirjoituksia ole testattu.