Vakaa parhaat käytännöt älykkääseen sopimusten turvallisuuteen

blogi 1NewsDevelopersEnterpriseBlockchain ExplainedTapahtumat ja konferenssitPainaUutiskirjeet

Contents

tilaa uutiskirjeemme.

Sähköpostiosoite

Kunnioitamme yksityisyyttäsi

EtusivuBlogiBlockchain Development

Vakaa parhaat käytännöt älykkääseen sopimusten turvallisuuteen

Seuraavassa on joitain ammattivinkkejä seurannasta aikaleimanäkökohtiin, jotta Ethereum-älykkäitä sopimuksiasi vahvistetaan. mennessä ConsenSys 21. elokuuta 2020 Lähetetty 21. elokuuta 2020

vakauden parhaat käytännöt sankari

ConsenSys Diligence, tiimimme blockchain-turvallisuusasiantuntijoita.

Jos olet ottanut älykkään sopimuksen tietoturva-ajattelutavan sydämeen ja saat käsityksen EVM: n omaperäisyyksistä, on aika harkita joitain tietoturvakuvioita, jotka ovat ominaisia ​​Solidity-ohjelmointikielelle. Tässä yhteenvedossa keskitymme turvallisuutta koskeviin turvallisuussuosituksiin, jotka voivat myös olla hyödyllisiä älykkäiden sopimusten kehittämiselle muilla kielillä. 

Okei, hyppäämme sisään.

Käytä assert (), vaatia (), palaa () oikein

Mukavuustoiminnot väittävät ja vaatia voidaan käyttää ehtojen tarkistamiseen ja poikkeuksen heittämiseen, jos ehto ei täyty.

 väittävät funktiota tulisi käyttää vain sisäisten virheiden testaamiseen ja invariantien tarkistamiseen.

 vaatia Toimintoa tulisi käyttää varmistamaan, että kelvolliset ehdot, kuten panokset tai sopimusmuuttujat täyttyvät, tai ulkoisten sopimusten puheluiden palautusarvojen vahvistamiseksi. 

Tämän paradigman noudattaminen antaa muodollisille analyysityökaluille mahdollisuuden varmistaa, että virheellistä opkoodia ei voida koskaan saavuttaa: ts. Koodissa olevia invariantteja ei loukata ja että koodi on muodollisesti vahvistettu.

käytännön kiinteys ^ 0,5,0; sopimus Jakaja {funktio sendHalf (osoite maksettava osoite) julkinen maksettava tuotto (uint-saldo) {vaatia (msg.value% 2 == 0, "Tasainen arvo vaaditaan."); // Require (): llä voi olla valinnainen viestimerkkijono uint balanceBeforeTransfer = address (this) .balance; (Bool-menestys) = addr.call.value (msg.value / 2) (""); vaatia (menestys); // Koska palasimme, jos siirto epäonnistui, meillä ei pitäisi olla // mitään keinoa, että meillä olisi vielä puolet rahasta. vakuuttaa (osoite (tämä) .saldo = = balanceBeforeTransfer – msg.value / 2); // käytetään sisäisen virheen tarkistamiseen palautusosoite (tämä) .balance; }} Koodikieli: JavaScript (javascript)


Katso SWC-110 & SWC-123

Käytä modifikaattoreita vain tarkastuksiin

Modifioijan sisällä oleva koodi suoritetaan yleensä ennen funktion runkoa, joten kaikki tilamuutokset tai ulkoiset puhelut rikkovat koodia Tarkistukset-vaikutukset-vuorovaikutukset kuvio. Lisäksi nämä lausekkeet saattavat myös olla kehittäjän huomaamatta, koska modifikaattorin koodi voi olla kaukana toimintoilmoituksesta. Esimerkiksi ulkoinen puhelu muokkauksessa voi johtaa uudelleenkäynnistyshyökkäykseen:

sopimusrekisteri {osoitteen omistaja; function isVoter (osoite _addr) ulkoinen palautus (bool) {// Code}} sopimus Valinta {Rekisterirekisteri; modifier isEligible (osoite _addr) {vaatia (register.isVoter (_addr)); _; } funktioäänestys () isEligible (msg.sender) public {// Code}} Koodikieli: JavaScript (javascript)

Tällöin rekisterisopimus voi tehdä uudelleenkäynnistyshyökkäyksen soittamalla ElV.vote () isVoter (): n sisälle.

Huomautus: Käyttää muokkaajat Korvaa päällekkäiset ehtotarkistukset useissa toiminnoissa, kuten isOwner (), muuten käytä funktiota tai palauta toiminto. Tämä tekee älykkäästä sopimuskoodistasi luettavamman ja helpommin tarkastettavan.

Varo pyöristämistä kokonaislukujaolla

Kaikki kokonaislukujako pyöristyy alaspäin lähimpään kokonaislukuun. Jos tarvitset tarkkuutta, harkitse kertojan käyttöä tai tallenna sekä osoittaja että nimittäjä.

(Tulevaisuudessa vakavuudella on kiinteä piste tyyppi, mikä helpottaa tätä.)

// huono uint x = 5/2; // Tulos on 2, kaikki kokonaisluvut jakautuvat alaspäin lähimpään kokonaislukuun Koodikieli: JavaScript (javascript)

Kertojan käyttö estää pyöristämisen alaspäin, tämä kerroin on otettava huomioon, kun jatkossa työskentelet x: n kanssa:

// hyvä uint-kerroin = 10; uint x = (5 * kerroin) / 2; Koodikieli: JavaScript (javascript)

Osoittimen ja nimittäjän tallentaminen tarkoittaa, että voit laskea osoittajan / nimittäjän tuloksen ketjun ulkopuolelta:

// hyvä uintilaskuri = 5; uint nimittäjä = 2; Koodikieli: JavaScript (javascript)

Ole tietoinen kompromisseista välillä abstrakteja sopimuksia ja rajapinnat

Sekä käyttöliittymät että abstraktit sopimukset tarjoavat yhden mukautettavan ja uudelleenkäytettävän lähestymistavan älykkäille sopimuksille. Liitännät, jotka otettiin käyttöön Solidity 0.4.11: ssä, ovat samanlaisia ​​kuin abstraktit sopimukset, mutta niillä ei voi olla mitään toimintoja. Liitännöillä on myös rajoituksia, kuten se, että tallennustilaa ei voi käyttää tai periä muista rajapinnoista, mikä tekee abstrakteista sopimuksista yleensä käytännöllisempiä. Vaikka käyttöliittymät ovat varmasti hyödyllisiä sopimusten suunnittelussa ennen käyttöönottoa. Lisäksi on tärkeää pitää mielessä, että jos sopimus perii abstraktista sopimuksesta, sen on toteutettava kaikki toteuttamattomat toiminnot ohittamalla tai se on myös abstrakti.

Varatoiminnot

Pidä varatoiminnot yksinkertaisina

Varatoiminnot kutsutaan, kun sopimukselle lähetetään viesti ilman argumentteja (tai kun mikään funktio ei täsmää), ja niillä on pääsy 2300 kaasuun vain, kun soitetaan .send () tai .transfer () -sivulta. Jos haluat pystyä vastaanottamaan eetterin .send () – tai .transfer () -operaattorista, eniten varatoiminnolla voi tehdä tapahtuman kirjaamisen. Käytä oikeaa toimintoa, jos tarvitaan enemmän kaasua.

// huono toiminto () maksettava {saldot [msg.sender] + = msg.value; } // hyvät toimintatalletukset () maksettavat ulkoiset {saldot [msg.sender] + = msg.value; } function () maksettava {vaatia (msg.data.length == 0); lähettää LogDepositReceived (msg.sender); } Koodikieli: JavaScript (javascript)

Tarkista tietojen pituus varatoiminnoissa

Koska varatoiminnot ei vaadita pelkkää eetterinsiirtoa (ilman tietoja), mutta myös silloin, kun mikään muu toiminto ei täsmää, tarkista, että tiedot ovat tyhjät, jos varatoiminto on tarkoitettu käytettäväksi vain vastaanotetun eetterin kirjaamiseen. Muuten soittajat eivät huomaa, jos sopimustasi käytetään väärin ja toimintoja, joita ei ole olemassa, kutsutaan.

// huono toiminto () maksettava {emit LogDepositReceived (msg.sender); } // hyvä toiminto () maksettava {vaatia (msg.data.length == 0); lähettää LogDepositReceived (msg.sender); } Koodikieli: JavaScript (javascript)

Merkitse maksettavat toiminnot ja tilamuuttujat nimenomaisesti

Vakavuudesta 0.4.0 alkaen kaikkien eetteriä vastaanottavien toimintojen on käytettävä maksettavaa modifikaattoria, muuten, jos tapahtumassa on msg.value > 0 palautuu (paitsi kun pakotetaan).

Huomautus: Jotain, mikä ei ehkä ole ilmeistä: Maksettava modifikaattori koskee vain ulkopuolisista sopimuksista tulevia puheluita. Jos soitan maksamattomalle funktiolle saman sopimuksen maksettavassa funktiossa, maksamaton toiminto ei onnistu, vaikka msg.value on edelleen asetettu.

Merkitse selkeästi funktioiden ja tilamuuttujien näkyvyys

Merkitse nimenomaisesti toimintojen ja tilamuuttujien näkyvyys. Toiminnot voidaan määritellä ulkoisiksi, julkisiksi, sisäisiksi tai yksityisiksi. Ymmärrä niiden väliset erot, esimerkiksi ulkoinen voi olla riittävä julkisen sijaan. Tilamuuttujien osalta ulkoinen ei ole mahdollista. Näkyvyyden nimenomainen merkitseminen helpottaa virheellisten oletusten saamista siitä, kuka voi kutsua toimintoa tai käyttää muuttujaa.

  • Ulkoiset toiminnot ovat osa sopimusrajapintaa. Ulkoista toimintoa f ei voida kutsua sisäisesti (ts. F () ei toimi, mutta tämä. F () toimii). Ulkoiset toiminnot ovat joskus tehokkaampia, kun ne vastaanottavat suuria tietomääriä.
  • Julkiset toiminnot ovat osa sopimusrajapintaa, ja niitä voidaan kutsua sisäisesti tai viestien kautta. Julkisen tilan muuttujille luodaan automaattinen getter-toiminto (katso alla).
  • Sisäisiin toimintoihin ja tilamuuttujiin pääsee vain sisäisesti, tätä käyttämättä.
  • Yksityiset toiminnot ja tilamuuttujat näkyvät vain sopimuksessa, jossa ne on määritelty, eivät johdannaissopimuksissa. Huomautus: Kaikki, mikä on sopimuksen sisällä, näkyy kaikille blockchainin ulkopuolisille tarkkailijoille, myös yksityisille muuttujille.

// huono uint x; // oletus on tilamuuttujien sisäinen, mutta siitä tulisi tehdä selkeä funktio buy () {// oletus on julkinen // julkinen koodi} // hyvä uint yksityinen y; function buy () external {// vain soitettavissa ulkoisesti tai this.buy ()} function-apuohjelman () public {// ulkoisesti ja sisäisesti kutsuttava avulla: tämän koodin muuttaminen vaatii molempien tapausten miettimistä. } function internalAction () internal {// sisäinen koodi} Koodikieli: PHP (php)

Katso SWC-100 ja SWC-108

Lukitse pragmat tiettyyn kääntäjän versioon

Sopimukset tulisi ottaa käyttöön samalla kääntäjäversiolla ja lipuilla, joilla niitä on testattu eniten. Pragman lukitseminen auttaa varmistamaan, että sopimuksia ei vahingossa oteta käyttöön esimerkiksi käyttämällä uusinta kääntäjää, jolla saattaa olla suurempia havaitsemattomien virheiden riskejä. Myös muut voivat käyttää sopimuksia, ja pragma osoittaa alkuperäisten kirjoittajien tarkoittaman kääntäjän version.

// huono käytännön vakavuus ^ 0,4.4; // hyvä käytännön vakaus 0.4.4; Koodikieli: JavaScript (javascript)

Huomaa: kelluva pragma-versio (ts. ^ 0.4.25) kääntyy hienosti 0.4.26-yöllä.2018.9.25, mutta yökokoelmia ei kuitenkaan koskaan pidä käyttää tuotannon koodin kokoamiseen.

Varoitus: Pragma-lauseiden voidaan antaa kellua, kun sopimus on tarkoitettu muiden kehittäjien kulutettavaksi, kuten kirjastossa tai EthPM-paketissa tehtyjen sopimusten tapauksessa. Muuten kehittäjän on päivitettävä pragma manuaalisesti kääntääkseen paikallisesti.

Katso SWC-103

Käytä tapahtumia sopimuksen toiminnan seuraamiseen

Voi olla hyödyllistä, että sinulla on tapa seurata sopimuksen toimintaa sen käyttöönoton jälkeen. Yksi tapa saavuttaa tämä on tarkastella kaikkia sopimuksen tapahtumia, mutta se voi kuitenkin olla riittämätöntä, koska sopimusten välisiä viestipuheluja ei tallenneta estoketjuun. Lisäksi se näyttää vain tuloparametrit, ei todellisia tilaan tehtäviä muutoksia. Myös tapahtumia voidaan käyttää toimintojen käynnistämiseen käyttöliittymässä.

sopimus Hyväntekeväisyys {kartoitus (osoite => uint) saldot; funktio lahjoittaa () maksettava julkinen {saldot [viestin lähettäjä] + = viestin arvo; }} sopimuspeli {function buyCoins () maksettava julkinen {// 5% menee hyväntekeväisyyteen charity.donate.value (msg.value / 20) (); }} Koodikieli: JavaScript (javascript)

Tässä Pelisopimus soittaa sisäisen puhelun Charity.donate (): lle. Tämä tapahtuma ei näy Charityn ulkoisessa tapahtumaluettelossa, mutta näkyy vain sisäisissä tapahtumissa.

Tapahtuma on kätevä tapa kirjata sopimuksessa tapahtunut asia. Lähetetyt tapahtumat pysyvät lohkoketjussa muiden sopimustietojen kanssa, ja ne ovat käytettävissä tulevaa tarkastusta varten. Tässä on parannus yllä olevaan esimerkkiin, jossa tapahtumien avulla kerrotaan hyväntekeväisyysjärjestön lahjoitusten historiasta.

sopimushyväntekeväisyys {// määritä tapahtuman tapahtuma LogDonate (uint _mount); kartoitus (osoite => uint) saldot; funktio lahjoittaa () maksettava julkinen {saldot [viestin lähettäjä] + = viestin arvo; // emit event emit LogDonate (msg.value); }} sopimuspeli {function buyCoins () maksettava julkinen {// 5% menee hyväntekeväisyyteen charity.donate.value (msg.value / 20) (); }} Koodikieli: JavaScript (javascript)

Täällä kaikki hyväntekeväisyyssopimuksen mukaiset liiketoimet, joko suoraan tai ei, näkyvät kyseisen sopimuksen tapahtumaluettelossa yhdessä lahjoitetun rahan määrän kanssa..

Huomaa: mieluummin uudemmat Solidity-rakenteet. Pidä parempana rakenteita / aliaksia, kuten itsetuho (itsemurhan yli) ja keccak256 (yli sha3). Tarvittavat mallit (msg.sender.send (1 eetteri)) voidaan myös yksinkertaistaa siirron () käyttämiseen, kuten msg.sender.transfer (1 eetteri). Tarkista Vakauden muutosloki vastaaviin muutoksiin.

Huomaa, että “sisäänrakennetut” voidaan varjostaa

Se on tällä hetkellä mahdollista varjo kiinteät globaalit ominaisuudet. Tämä sallii sopimusten ohittaa sisäänrakennettujen toimintojen, kuten msg ja revert (), toiminnot. Vaikka tämä on tarkoitettu, se voi johtaa sopimuksen käyttäjiä harhaan sopimuksen todellisen käyttäytymisen suhteen.

sopimus PretendingToRevert {function revert () sisäinen vakio {}} contract ExampleContract on PretendingToRevert {function somethingBad () public {revert (); }}

Sopimuskäyttäjien (ja tilintarkastajien) tulisi olla tietoisia kaikkien älykkäiden sopimusten lähdekoodeista kaikista sovelluksista, joita he aikovat käyttää.

Vältä tx.originin käyttöä

Älä koskaan käytä valtuutusta tx.origin, toisella sopimuksella voi olla menetelmä, joka kutsuu sopimustasi (jos esimerkiksi käyttäjällä on varoja), ja sopimuksesi valtuuttaa kyseisen tapahtuman, koska osoitteesi on osoitteessa tx.origin.

sopimus MyContract {osoitteen omistaja; function MyContract () public {owner = msg.sender; } function sendTo (osoitteen vastaanottaja, uintimäärä) public {vaatia (tx.origin == omistaja); (Bool-menestys) = vastaanottaja.puhelu.arvo (määrä) (""); vaatia (menestys); }} sopimus AttackingContract {MyContract myContract; osoitteen hyökkääjä; funktio AttackingContract (osoite myContractAddress) public {myContract = MyContract (myContractAddress); hyökkääjä = viestin lähettäjä; } function () public {myContract.sendTo (hyökkääjä, msg.sender.balance); }} Koodikieli: JavaScript (javascript)

Sinun on käytettävä valtuutusta msg.sender (jos toinen sopimus kutsuu sopimustasi, msg.sender on sopimuksen osoite eikä sopimuksen soittaneen käyttäjän osoite).

Voit lukea lisää täältä: Vakausasiakirjat

Varoitus: Valtuutusongelman lisäksi on mahdollista, että tx.origin poistetaan Ethereum-protokollasta tulevaisuudessa, joten tx.originia käyttävä koodi ei ole yhteensopiva tulevien julkaisujen kanssa Vitalik: “ÄLÄ oleta, että tx.origin on edelleen käyttökelpoinen tai mielekäs.”

On myös syytä mainita, että käyttämällä tx.originia rajoitat sopimusten välistä yhteentoimivuutta, koska tx.originia käyttävää sopimusta ei voida käyttää toisessa sopimuksessa, koska sopimus ei voi olla tx.origin.

Katso SWC-115

Aikaleiman riippuvuus

On kolme pääkohdetta, kun käytetään aikaleimaa sopimuksen kriittisen toiminnon suorittamiseen, varsinkin kun toimintaan liittyy varojen siirtoa.

Aikaleiman käsittely

Huomaa, että kaivosmies voi muokata lohkon aikaleimaa. Harkitse tätä sopimuksen:

uint256 vakio yksityinen suola = lohko. aikaleima; funktio satunnainen (uint Max) vakio yksityinen tuotto (uint256 tulos) {// saat parhaan siemen satunnaisuudelle uint256 x = suola * 100 / Max; uint256 y = suola * lohko. numero / (suola% 5); uint256 siemen = lohko.numero / 3 + (suolaprosentti 300) + Viimeinen_maksu + y; uint256 h = uint256 (lohko.blockhash (siemen)); paluu uint256 ((h / x))% Max + 1; // satunnaisluku välillä 1 ja enintään} Koodikieli: PHP (php)

Kun sopimus käyttää aikaleimaa satunnaisluvun sijoittamiseen, kaivosmies voi tosiasiallisesti lähettää aikaleiman 15 sekunnin kuluessa lohkon validoinnista, jolloin kaivosmies voi tehokkaasti laskea vaihtoehdon, joka on suotuisampi heidän mahdollisuutensa arpajaisiin. Aikaleimat eivät ole satunnaisia, eikä niitä tule käyttää tässä yhteydessä.

15 sekunnin sääntö

 Keltainen kirja (Ethereumin referenssimäärittely) ei määritä rajoitusta sille, kuinka paljon lohkoja voi ajautua ajassa, mutta se täsmentää että jokaisen aikaleiman tulee olla suurempi kuin vanhemman aikaleiman. Suosittu Ethereum-protokollan toteutus Geth ja Pariteetti molemmat hylkää lohkot, joiden aikaleima on yli 15 sekuntia tulevaisuudessa. Siksi hyvä nyrkkisääntö aikaleiman käytön arvioinnissa on: jos aikariippuvan tapahtumasi asteikko voi vaihdella 15 sekunnilla ja säilyttää eheyden, on turvallista käyttää lohkoa. Aikaleima.

Vältä block.number käyttöä aikaleimana

Aikaviive on mahdollista arvioida käyttämällä ominaisuutta block.number ja keskimääräinen estoaika, tämä ei kuitenkaan ole tulevaisuuden todiste, koska lohkoajat voivat muuttua (kuten haarukan uudelleenjärjestelyt ja vaikeus pommi). Päiväkauden aikana 15 sekunnin säännön avulla voidaan saavuttaa luotettavampi arvio aika.

Katso SWC-116

Useita perintövarovaisuutta

Kun käytetään useita perintöjä Solidityssä, on tärkeää ymmärtää, kuinka kääntäjä laatii perintökaavion.

sopimus Lopullinen {uint public a; funktio Lopullinen (uint f) public {a = f; }} sopimus B on lopullinen {julkinen maksu; funktio B (uint f) Lopullinen (f) public {} function setFee () public {fee = 3; }} sopimus C on lopullinen {julkinen maksu; funktio C (uint f) Lopullinen (f) public {} function setFee () public {fee = 5; }} sopimus A on B, C {funktio A () julkinen B (3) C (5) {setFee (); }} Koodikieli: PHP (php)

Kun sopimus on otettu käyttöön, kääntäjä linearisoi perinnön oikealta vasemmalle (sen jälkeen kun avainsana on vanhemmat on lueteltu perusta-tyyppisimmistä johdetuimpiin). Tässä on sopimuksen A linearisointi:

Lopullinen <- B <- C <- A

Lineaarisoinnin seurauksena palkkion arvo on 5, koska C on johdetuin sopimus. Tämä saattaa tuntua itsestään selvältä, mutta kuvittele skenaarioita, joissa C kykenee varjostamaan tärkeitä toimintoja, järjestämään loogisuuslausekkeita ja saamaan kehittäjän kirjoittamaan hyödynnettävissä olevia sopimuksia. Staattinen analyysi ei tällä hetkellä aiheuta ongelmia varjostetuissa toiminnoissa, joten se on tarkastettava manuaalisesti.

Solidity’s Githubilla on oma projekti kaikki perintöön liittyvät kysymykset.

Katso SWC-125

Käytä tyyppiturvallisuuteen osoitteen sijasta käyttöliittymätyyppiä

Kun funktio ottaa sopimusosoitteen argumenttina, on parempi välittää käyttöliittymä tai sopimustyyppi kuin raaka osoite. Jos funktiota kutsutaan muualle lähdekoodissa, kääntäjä antaa ylimääräiset tyyppiturvatakuut.

Täällä näemme kaksi vaihtoehtoa:

sopimus Validator {toiminto validoi (uint) ulkoiset palautukset (Bool); } sopimus TypeSafeAuction {// hyvä toiminto validateBet (Validator _validator, uint _value) sisäinen palautus (bool) {bool valid = _validator.validate (_value); palautus voimassa; }} contract TypeUnsafeAuction {// virheellinen toiminto validateBet (osoite _addr, uint _value) sisäinen palautus (bool) {Validator validator = Validator (_addr); bool valid = validator.validate (_value); palautus voimassa; }} Koodikieli: JavaScript (javascript)

Edellä olevan TypeSafeAuction -sopimuksen käytön edut voidaan nähdä seuraavasta esimerkistä. Jos validateBet () kutsutaan osoite argumentilla tai muulla sopimustyypillä kuin Validator, kääntäjä heittää tämän virheen:

sopimus NonValidator {} -sopimushuutokauppa on TypeSafeAuction {NonValidator nonValidator; function bet (uint _value) {bool valid = validateBet (nonValidator, _value); // TypeError: Funktion kutsun argumentin tyyppi on virheellinen. // Virheellinen implisiittinen muunnos sopimuksesta NonValidator // sopimukseen Validator pyydetty. }} Koodikieli: JavaScript (javascript)

Vältä ulkoisten koodien käyttöä ulkoisten omistamien tilien tarkistamiseen

Seuraavaa muokkaajaa (tai vastaavaa tarkistusta) käytetään usein sen tarkistamiseen, soitettiinko ulkoisen omistetulta tililtä vai sopimustililtä:

// huono muokkaaja isNotContract (osoite _a) {uint size; assembly {size: = extcodesize (_a)} vaadi (size == 0); _; } Koodikieli: JavaScript (javascript)

Ajatus on suora: jos osoite sisältää koodin, se ei ole EOA, vaan sopimus. kuitenkin, sopimuksessa ei ole lähdekoodia käytettävissä rakentamisen aikana. Tämä tarkoittaa, että rakentajan ollessa käynnissä se voi soittaa muille sopimuksille, mutta osoitteensa extcodesize palauttaa nollan. Alla on vähäinen esimerkki, joka osoittaa, kuinka tämä tarkistus voidaan kiertää:

sopimus vainFOREOA {uint public flag; // huono muokkaaja isNotContract (osoite _a) {uint len; kokoonpano {len: = extcodesize (_a)} vaadi (len == 0); _; } function setFlag (uint i) public isNotContract (msg.sender) {lippu = i; }} sopimus FakeEOA {rakentaja (osoite _a) julkinen {OnlyForEOA c = OnlyForEOA (_a); c.setFlag (1); }} Koodikieli: JavaScript (javascript)

Koska sopimusosoitteet voidaan laskea etukäteen, tämä tarkistus voi myös epäonnistua, jos se tarkistaa osoitteen, joka on tyhjä lohkossa n, mutta johon on asennettu sopimus jossakin lohkossa, joka on suurempi kuin n.

Varoitus: Tämä asia on vivahteikas. Jos tavoitteena on estää muita sopimuksia soittamasta sopimustasi, extcodesize-tarkistus on todennäköisesti riittävä. Vaihtoehtoinen tapa on tarkistaa (tx.origin == msg.sender) arvo, vaikka tämäkin on haittoja.

Saattaa olla muita tilanteita, joissa extcodesize-tarkistus palvelee tarkoitustasi. Kaikkien niiden kuvaaminen tässä on soveltamisalan ulkopuolella. Ymmärrä EVM: n taustalla olevat käyttäytymiset ja käytä päätöstäsi.

Onko Blockchain-koodisi suojattu?

Varaa yhden päivän tarkistus turvallisuusasiantuntijoiltamme. Book Yours Today DiligenceSecuritySmart ContractsSolidityNewsletterTilaa uutiskirjeemme, niin saat uusimmat Ethereum-uutiset, yritysratkaisut, kehittäjien resurssit ja paljon muuta.Kuinka rakentaa onnistunut blockchain-tuoteWebseminaari

Kuinka rakentaa onnistunut blockchain-tuote

Kuinka perustaa ja suorittaa Ethereum-solmuWebseminaari

Kuinka perustaa ja suorittaa Ethereum-solmu

Kuinka rakentaa oma Ethereum-sovellusliittymäWebseminaari

Kuinka rakentaa oma Ethereum-sovellusliittymä

Kuinka luoda sosiaalinen tunnusWebseminaari

Kuinka luoda sosiaalinen tunnus

Turvatyökalujen käyttäminen älykkäässä sopimusten kehittämisessäWebseminaari

Turvatyökalujen käyttäminen älykkäässä sopimusten kehittämisessä

Digitaalisten varojen ja DeFi: n tulevaisuusWebseminaari

Rahoituksen tulevaisuus: digitaaliset varat ja DeFi

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Like this post? Please share to your friends:
Adblock
detector
map