Den smarte kontraktssikkerhetstanken

blogg 1NyheterUtviklereEnterpriseBlockchain ExplainedBegivenheter og konferanserPresseNyhetsbrev

Abonner på vårt nyhetsbrev.

Epostadresse

Vi respekterer personvernet ditt

HjemBloggBlockchain utvikling

Den smarte kontraktssikkerhetstanken

5 sikkerhetsprinsipper som alle Ethereum-utviklere trenger å vite, pluss grunnleggende avveininger. av ConsenSys 17. juni 2020 Publisert 17. juni 2020

Blockchain Security

Av ConsenSys Diligence, vårt team av blockchain-sikkerhetseksperter.

Selv om bransjen modnes, er smart kontraktutvikling fortsatt et relativt nytt og modent felt. Derfor bør du forvente konstante endringer i sikkerhetslandskapet, ettersom nye feil og sikkerhetsrisiko oppdages, og etter hvert som nye beste fremgangsmåter utvikles. Læring og følge beste praksis er bare begynnelsen på sikkerhetsarbeidet du må gjøre som en smart kontraktutvikler.

Smart kontraktprogrammering krever en annen ingeniørinnstilling enn du kan være vant til. Kostnadene ved feil kan være høye, og endring kan være vanskelig, noe som gjør det på noen måter mer lik maskinvareprogrammering eller programmering av finansielle tjenester enn utvikling av nett eller mobil. Det er derfor ikke nok å forsvare seg mot kjente sårbarheter. I stedet må du lære deg en ny utviklingsfilosofi.

Forbered deg på feil

Enhver ikke-triviell kontrakt vil ha feil i den. Koden din må derfor kunne svare på feil og sårbarheter.

  • Sett kontrakten på pause når ting går galt (“strømbryter”).
  • Administrer pengesummen (risikobegrensning, maksimal bruk).
  • Ha en effektiv oppgraderingsbane for feilrettinger og forbedringer.

Utrulling forsiktig

Det er alltid bedre å fange bugs før en fullstendig produksjonsutgivelse.

  • Test kontrakter grundig, og legg til tester når nye angrepsvektorer oppdages.
  • Gi bug bounties starter fra alfa testnet utgivelser.
  • Utrulling i faser, med økende bruk og testing i hver fase.

Hold kontraktene enkle

Kompleksitet øker sannsynligheten for feil.


  • Sørg for at kontraktslogikken er enkel.
  • Modulariser koden for å holde kontrakter og funksjoner små.
  • Bruk allerede skrevet verktøy eller kode der det er mulig (f.eks. Ikke rull din egen tilfeldige tallgenerator).
  • Foretrekker klarhet fremfor ytelse når det er mulig.
  • Bruk bare blockchain for de delene av systemet ditt som krever desentralisering.

Hold deg oppdatert

Hold rede på nye sikkerhetsutviklinger.

  • Sjekk kontraktene dine for eventuelle nye feil så snart den blir oppdaget.
  • Oppgrader til den nyeste versjonen av ethvert verktøy eller bibliotek så snart som mulig.
  • Vedta nye sikkerhetsteknikker som virker nyttige.

Vær oppmerksom på EVMs egenart

Mens mye av programmeringsopplevelsen din vil være relevant for Ethereum-programmering, er det noen fallgruver å være klar over.

  • Vær ekstremt forsiktig med eksterne kontraktssamtaler, som kan utføre ondsinnet kode og endre kontrollflyten.
  • Forstå at dine offentlige funksjoner er offentlige, og kan kalles ondsinnet og i hvilken som helst rekkefølge. De private dataene i smarte kontrakter er også synlige for alle.
  • Husk gasskostnadene og blokkeringsgrensen.
  • Vær oppmerksom på at tidsstempler er upresise i en blockchain: gruvearbeidere kan påvirke tidspunktet for gjennomføring av en transaksjon innen en margin på flere sekunder.
  • Tilfeldighet er ikke triviell på blockchain, de fleste tilnærminger til tilfeldig nummergenerering er spillbare på en blockchain.

Fundamentale kompromisser

Det er flere grunnleggende avveininger å vurdere når man vurderer strukturen og sikkerheten til et smart kontraktssystem. Den generelle anbefalingen for ethvert smart kontraktssystem er å identifisere riktig balanse for disse grunnleggende kompromissene.

Et ideelt smart kontraktssystem fra en programvareteknisk skjevhet er modulært, gjenbruker kode i stedet for å duplisere det, og støtter oppgraderbare komponenter. Et ideelt smart kontraktssystem fra en sikker arkitektonisk skjevhet kan dele denne tankegangen, spesielt når det gjelder mer komplekse smarte kontraktssystemer.

Imidlertid er det viktige unntak der sikkerhets- og programvareteknikk ikke kan justeres. I begge tilfeller oppnås riktig balanse ved å identifisere den optimale blandingen av egenskaper langs kontraktssystemdimensjoner som:

  • Stiv vs. oppgraderbar
  • Monolitisk vs. modulær
  • Duplisering mot gjenbruk
Stiv vs. oppgraderbar

Mens flere ressurser, inkludert denne, understreker formbarhetsegenskaper som drepbare, oppgraderbare eller modifiserbare mønstre, er det en grunnleggende kompromiss mellom formbarhet og sikkerhet.

Smidbarhetsmønstre gir per definisjon kompleksitet og potensielle angrepsflater. Enkelhet er spesielt effektiv over kompleksitet i tilfeller der det smarte kontraktssystemet utfører et svært begrenset sett med funksjonalitet i en forhåndsdefinert begrenset periode, for eksempel et styringsfritt endelig tidsrammesystem for tegnsalg.

Monolitisk vs. modulær

En monolitisk selvstendig kontrakt holder all kunnskap lokalt identifiserbar og lesbar. Selv om det er få smarte kontraktssystemer som er høyt ansett som eksisterer som monolitter, er det et argument å gjøre for ekstrem lokalitet av data og flyt – for eksempel i tilfelle optimalisering av kodevurderingseffektivitet.

Som med de andre avveiningene som er vurdert her, utvikler beste praksis for sikkerhet seg fra beste praksis for programvareteknikk i enkle kortvarige kontrakter og trenden mot beste praksis for programvareutvikling i tilfelle mer komplekse evige kontraktssystemer.

Duplisering mot gjenbruk

Et smart kontraktssystem fra et programvareteknisk perspektiv ønsker å maksimere gjenbruk der det er rimelig. Det er mange måter å gjenbruke kontraktkoden i Solidity. Å bruke velprøvde tidligere distribuerte kontrakter som du eier, er generelt den sikreste måten å oppnå gjenbruk av kode på.

Du kan ofte stole på duplisering i tilfeller der ikke eide tidligere distribuerte kontrakter er tilgjengelige. Innsats som OpenZeppelin’s Solidity Library søke å gi mønstre slik at sikker kode kan brukes på nytt uten duplisering. Eventuelle kontraktssikkerhetsanalyser må inneholde all gjenbrukt kode som ikke tidligere har etablert et tillitsnivå som er i samsvar med midlene som er i fare i målet smart kontraktssystem.

Å bygge og lansere applikasjoner på Ethereum er uten tvil den mest spennende grensen for programvareingeniører i dag, men det krever kontinuerlig trusselmodellering, sikkerhetsrevisjon og planlegging av hendelsesrespons..

Diligence-teamet er her for å hjelpe deg å være årvåken og bygge tillit til implementeringene dine.

Bestill en Blockchain Security Spot Check

Våre 1-dagers vurderinger hjelper deg med å bygge sikkerhet inn i blockchain-koden din fra starten, slik at du kan spare tid og penger i det lange løp. Book Yours Today SecuritySmart ContractsNewsletterAbonner på vårt nyhetsbrev for de siste Ethereum-nyhetene, bedriftsløsninger, utviklerressurser og mer. E-postadresse Eksklusivt innholdHvordan lage et vellykket Blockchain-produktWebinar

Hvordan lage et vellykket Blockchain-produkt

Hvordan sette opp og kjøre en Ethereum-nodeWebinar

Hvordan sette opp og kjøre en Ethereum-node

Hvordan lage din egen Ethereum APIWebinar

Hvordan lage din egen Ethereum API

Hvordan lage et sosialt tokenWebinar

Hvordan lage et sosialt token

Bruke sikkerhetsverktøy i smart kontraktutviklingWebinar

Bruke sikkerhetsverktøy i smart kontraktutvikling

Fremtiden for digitale eiendeler og deFiWebinar

Fremtidens økonomi: digitale eiendeler og 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