Smart Mind Security-tankesättet

blogg 1NyheterUtvecklareFöretagBlockchain förklaradeHändelser och konferenserPressNyhetsbrev

Prenumerera på vårt nyhetsbrev.

E-postadress

Vi respekterar din integritet

HemBlogBlockchain utveckling

Smart Mind Security-tankesättet

Fem säkerhetsprinciper som varje Ethereum-utvecklare behöver veta plus grundläggande avvägningar. av ConsenSys 17 juni 2020 Upplagt den 17 juni 2020

Blockchain-säkerhet

Av ConsenSys Diligence, vårt team av blockchain-säkerhetsexperter.

Även om branschen mognar är smart kontraktutveckling fortfarande ett relativt nytt och moget område. Därför bör du förvänta dig ständiga förändringar i säkerhetslandskapet när nya buggar och säkerhetsrisker upptäcks och när nya bästa metoder utvecklas. Lärande och följa bästa praxis är bara början på det säkerhetsarbete du måste göra som en smart kontraktsutvecklare.

Smart kontraktsprogrammering kräver ett annat tekniskt tankesätt än vad du kan vara van vid. Kostnaden för misslyckande kan vara hög och förändring kan vara svår, vilket gör det på vissa sätt mer likartad med hårdvaruprogrammering eller programmering av finansiella tjänster än webb- eller mobilutveckling. Det räcker därför inte att försvara sig mot kända sårbarheter. Istället måste du lära dig en ny utvecklingsfilosofi.

Förbered dig på misslyckande

Alla icke-triviala kontrakt kommer att innehålla fel. Din kod måste därför kunna svara på buggar och sårbarheter.

  • Pausa kontraktet när saker går fel (“strömbrytare”).
  • Hantera mängden pengar i riskzonen (hastighetsbegränsning, maximal användning).
  • Ha en effektiv uppgraderingsväg för buggfixar och förbättringar.

Utrullning försiktigt

Det är alltid bättre att fånga buggar innan en fullständig produktionsrelease.

  • Testa kontrakt noggrant och lägg till test när nya attackvektorer upptäcks.
  • Förse bug bounties från och med alfa-testnätversioner.
  • Utbyggnad i faser, med ökad användning och testning i varje fas.

Håll kontrakten enkla

Komplexitet ökar sannolikheten för fel.

  • Se till att avtalslogiken är enkel.
  • Modulisera koden för att hålla kontrakt och funktioner små.
  • Använd redan skrivna verktyg eller kod där det är möjligt (t.ex. rulla inte din egen slumpgenerator).
  • Föredra klarhet framför prestanda när det är möjligt.
  • Använd endast blockkedjan för de delar av ditt system som kräver decentralisering.

Hålla sig uppdaterad

Håll koll på nya säkerhetsutvecklingar.

  • Kontrollera dina kontrakt för eventuella nya fel så snart det upptäcks.
  • Uppgradera till den senaste versionen av valfritt verktyg eller bibliotek så snart som möjligt.
  • Anta nya säkerhetstekniker som verkar användbara.

Var medveten om EVM: s idéer

Medan mycket av din programmeringserfarenhet kommer att vara relevant för Ethereum-programmering, finns det några fallgropar att vara medvetna om.

  • Var extremt försiktig med externa kontraktssamtal, som kan utföra skadlig kod och ändra kontrollflödet.
  • Förstå att dina offentliga funktioner är offentliga och kan kallas skadligt och i vilken ordning som helst. Privata data i smarta kontrakt kan också ses av alla.
  • Tänk på gaskostnaderna och blockera gasgränsen.
  • Var medveten om att tidsstämplar är exakta för en blockchain: gruvarbetare kan påverka tidpunkten för genomförandet av en transaktion inom en marginal på flera sekunder.
  • Slumpmässighet är inte trivial på blockchain, de flesta sätt att generera slumpmässiga nummer är spelbara på en blockchain.

Grundläggande avvägningar

Det finns flera grundläggande avvägningar att tänka på när man bedömer strukturen och säkerheten för ett smart kontraktssystem. Den allmänna rekommendationen för alla smarta kontraktssystem är att identifiera rätt balans för dessa grundläggande avvägningar.

Ett perfekt smart kontraktssystem från en programvaruteknik är modulärt, återanvänder kod istället för att duplicera det och stöder uppgraderbara komponenter. Ett idealt smart kontraktssystem från en säker arkitekturbias kan dela detta tänkesätt, särskilt när det gäller mer komplexa smarta kontraktssystem.

Det finns dock viktiga undantag där säkerhets- och programvaruteknik kanske inte anpassas. I båda fallen erhålls rätt balans genom att identifiera den optimala blandningen av egenskaper längs kontraktets systemdimensioner såsom:

  • Styv kontra uppgraderbar
  • Monolitisk kontra modulär
  • Kopiering kontra återanvändning
Styv kontra uppgraderbar

Medan flera resurser, inklusive denna, betonar smidighetsegenskaper som dödbara, uppgraderbara eller modifierbara mönster, finns det en grundläggande avvägning mellan smidbarhet och säkerhet.

Smidbarhetsmönster tillför per definition komplexitet och potentiella attackytor. Enkelhet är särskilt effektiv över komplexitet i fall där det smarta kontraktssystemet utför en mycket begränsad uppsättning funktioner under en fördefinierad begränsad tidsperiod, till exempel ett styrningsfritt system för avtalsförsäljning med begränsad tidsram..

Monolitisk kontra modulär

Ett monolitiskt fristående kontrakt håller all kunskap lokalt identifierbar och läsbar. Även om det finns få smarta kontraktssystem som uppskattas som monoliter, finns det ett argument att göra för extrem lokalisering av data och flöde – till exempel när det gäller att optimera effektiviteten för kodgranskning.

Som med de andra avvägningarna som beaktas här, utvecklas bästa praxis för säkerhet bort från bästa metoder för programvaruteknik i enkla kortlivade kontrakt och trend mot bästa metoder för programvaruteknik när det gäller mer komplexa eviga avtalssystem.

Kopiering kontra återanvändning

Ett smartt kontraktssystem ur ett mjukvaruteknikperspektiv vill maximera återanvändning där det är rimligt. Det finns många sätt att återanvända kontraktskod i Solidity. Att använda beprövade tidigare utplacerade kontrakt som du äger är i allmänhet det säkraste sättet att uppnå kodåteranvändning.

Duplicering är ofta beroende av i fall där tidigare ägda kontrakt inte är egna. Insatser som OpenZeppelin’s Solidity Library försöka tillhandahålla mönster så att säker kod kan återanvändas utan duplicering. Analyser av kontraktssäkerhet måste innehålla alla återanvända koder som inte tidigare har fastställt en nivå av förtroende som står i proportion till de medel som är i riskzonen i målet smart kontraktssystem..

Att bygga och starta applikationer på Ethereum är utan tvekan den mest spännande gränsen för programvarutekniker idag, men det kräver kontinuerlig hotmodellering, säkerhetsgranskning och planering av incidentrespons..

Diligence-teamet är här för att hjälpa dig att vara vaksam och bygga förtroende för dina distributioner.

Boka en Blockchain Security Spot Check

Våra 1-dagars recensioner hjälper dig att bygga säkerhet i din blockchain-kod från början så att du kan spara tid och pengar på lång sikt. Boka din idag SäkerhetSmarta kontraktNyhetsbrevPrenumerera på vårt nyhetsbrev för de senaste Ethereum-nyheterna, företagslösningar, utvecklarresurser och mer.E-postadressExklusivt innehållHur man bygger en framgångsrik Blockchain-produktWebinar

Hur man bygger en framgångsrik Blockchain-produkt

Hur man ställer in och kör en Ethereum-nodWebinar

Hur man ställer in och kör en Ethereum-nod

Hur man bygger ditt eget Ethereum APIWebinar

Hur man bygger ditt eget Ethereum API

Hur man skapar en social tokenWebinar

Hur man skapar en social token

Använda säkerhetsverktyg i Smart Contract DevelopmentWebinar

Använda säkerhetsverktyg i Smart Contract Development

Framtiden för finansiella digitala tillgångar och DeFiWebinar

Framtiden för ekonomi: digitala tillgångar och deFi

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