1

I am learning smart contract programming on Ethereum (using Solidity) and realizing that security is highly important here. Why? Because of 2 reasons: they deal with high-stake financial transactions, and smart contracts are immutable once you deploy them. Hence, you have to be really sure about the safety of your code before deploying it. To ascertain this, several static analysis tools are being built and many researchers are actively publishing papers regarding their security.

Now, the security of a smart contract ultimately boils down to safeguarding the internal private variables being changed by a "non-owner" (of the contract). There are several variables and functions, a few public entry-points into the smart contract, and you have to ensure that no entry point leads to malicious consequences.

However, this kind of safeguarding sounds eerily familiar. Isn't that what we have been doing when designing web APIs or classes or RPCs or just any kind of architecture where calls from outside are being made to our internal code base? What exactly sets smart contracts apart in terms of security?

shivams
  • 221
  • 1
  • 5

2 Answers2

2

Ethereum-style smart contracts are entirely public and immutable, whereas classic web APIs can have private data, private logic, and can be updated at any time by the server operator. Thus, we have different security goals in each setting.

The important property of a smart contract is that it works exactly as expected. Since smart contracts might control significant funds, there is substantial motivation in applying formal methods and static analysis to verify correctness as far as possible. You are correct that there is already a large body of work in that field, but there's always room for further developments and for applying existing techniques to new programming languages and new problems.

You are potentially wrong in assuming that smart contracts have entry points and private data. Anyone can run the smart contract and observe its internal state, unless cryptographic techniques are used to protect the data. In principle, anyone could also falsify the output of the smart contract, but that is useless since the Blockchain uses a consensus mechanism. If we look at the classic C-I-A triad of security goals, Ethereum-style smart contracts do ensure the integrity of computations (via the consensus mechanism, e.g. proof of work or proof of stake) and their availability (through the distributed blockchain design). But they do not afford confidentiality except through the usage of cryptographic techniques.

amon
  • 1,068
  • 7
  • 9
  • Except they are not "immutable," if the devs choose to mutate them... like they did after the DAO hack... – hft Sep 16 '21 at 22:42
  • There are also commonly bugs in smart contracts such that they do not "work[] exactly as expected." – hft Sep 16 '21 at 22:43
  • @hft The DAO hack was resolved via a hard fork of the Ethereum blockchain – a highly unusual event, not something a normal smart contract developer can count on. Indeed, bugs are common and bugs are a problem. That is why my answer is saying that there is a lot of interest in applying formal methods and static analysis to smart contracts. – amon Sep 17 '21 at 09:02
  • @amon - on the CIA triad... isn't A traditionally Availability (https://www.isc2.org/Certifications/CISSP/CISSP-Student-Glossary)? – Martin Thompson Sep 24 '21 at 16:23
  • @MartinThompson You're right, A is typically Availability. I've edited accordingly. While that's the “official” definition, it's sometimes useful to look at availability through the lens of authorization: that something is available to authorized users, and not available to unauthorized users. – amon Sep 24 '21 at 16:31
  • @hft no smart contract got changed on the DAO hack. They reversed all transactions from the affected blocks, creating a new token (Ethereum vs Ethereum Classic). The original DAO contract is still there on the blockchain in its original state. – ThoriumBR Sep 24 '21 at 17:48
  • So, the entire platform got changed? Seems even worse. – hft Sep 24 '21 at 19:48
  • @amon - you bring another A to the party - authorization :) – Martin Thompson Sep 25 '21 at 18:33
0

A smart contract is much more attractive to an attacker than most other forms of software. Their motivations are higher, because of the potential of acquiring something of high financial value. The potential scale of the reward is high as the contract automates financial transactions - the bug can be exploited multiple times, earning value each time.

Things with financial value are of interest to an attacker - and that changes the effort you should put into defending them. Much like in the "real world" :)

-- edit after comment ---

Yes, technically, it's "just software" - so all the usual activities apply. The language is different, which means that there are likely to be different classes of bugs which are "most popular", but it does just come down to making sure your software does what you want. And will no doubt suffer the usual problems of inadequate descriptions of "what we want" which result in flaws, as well as the low-level implementation failures which don't quite do what the spec said. Another difference (as noted elsewhere in another answer) is that your code is, by the nature of the way the smart contracts work, public - so motivated people can go digging without having to faff about extracting binaries and reverse engineering things.

Martin Thompson
  • 101
  • 4
  • Yes. That is correct. However, what I am asking is how is securing them "technically" different. I am afraid if the researchers are trying to re-solve an already solved problem (solved in other security domains). – shivams Sep 13 '21 at 14:35