Solidity & Security considerations

Hi there,

Ethereum is the silver of cryptocurrencies and has reached an all-time high price of $470. Today I want to talk about the most popular language in Ethereum and security considerations when it comes to Solidity.

As I said: Solidity is the most popular contract oriented language in Ethereum ecosystem. It has clear syntax and static type system.

The main construct in Solidity is the contract. It is very similar to a class definition in object oriented languages and can contain fields, functions, function modifiers, structure and enumeration types and it is also inheritable.

Contracts are executed usually to transfer assets between accounts in Ethereum and so security issues that can arise when writing smart contracts should be taken into consideration.

Call-stack

Every transaction in Ethereum has an associated call-stack. Call-stack itself is a low-level programming model used since very early machines to support subroutine calling in execution flow. Whenever you need to call a function the call-stack is used. You can think of it as a special structure to store the context of a function call including parameters, local variables and return values. Call-stack is using limited resource such as memory to store its data so it should be limited too.

Every time the contract is calling a function the associated call-stack of the transaction grows. The context of a function call represented in call-stack called call frame. The maximum depth the call-stack can reach is 1024 frames. That means there can be no more than 1024 nested function calls at a time. It was possible to exploit call-stack until 18/10/2016 by generating almost full call-stack and then invoking a victims function. This would then cause an unexpected behavior.

This vulnerability was addressed by a hard-fork of the Ethereum blockchain that changed the way how gas consumption is computed for function calls. After the fork, the caller can not use more than 63/64 of its gas and therefore can not reach a call stack depth limit of 1024 frames.

Contract immutability

The contract is immutable once it is deployed. Its code cannot be modified or altered somehow any more. This is the basic security concept but this is also a problem if a contract exposes any security vulnerabilities. There is no way to directly patch it.

One way to limit the immutability impact is to keep modular architecture of a system with separation of the interface from the implementation to support the replacement of a faulty component.

Unpredictable state

Since the state of a contract can be updated in every block and transactions in a block can be grouped arbitrarily by a miner, a caller can not know for sure in which state the contract is when sending a transaction. The actual state of a contract can also be unclear when the blockchain forks. It is possible that a contract is updated on a branch of the blockchain that turns out to be the shortest one at a later stage. The changes made to the contract would then be reverted.

The fact that the state of a contract is not always known to a caller can be exploited by adversaries.

In the following weeks, I will share with you technological insights into the blockchain world. Stay tuned to learn more.