Ethereum and smart contract security tools summarized

Some of the most important tools for testing ensuring or improving the security for your smart contract are the followings. Even if some of them are pretty much in a beta phase, it is practical to list them:

- OpenZeppelin: Solidity library for writing secure smart contracts:

https://github.com/OpenZeppelin/zeppelin-solidity

- Oyente: analysis tool for smart contracts:

https://github.com/melonproject/oyente

- SolCover: Solidity testing code coverage

https://github.com/sc-forks/solidity-coverage

- SolGraph: visualizing structure and control flow of solidity contracts

https://github.com/raineorshine/solgraph

- Vyper: new experimental and more secure programming language for Ethereum smart contracts

https://github.com/ethereum/vyper

- Securify: formal verification initiative for solidity smart contracts

https://securify.ch/

- SmartCheck: another verification tool for looking for wrongly implemented patterns
https://tool.smartdec.net/

- Ganache: more UI and user friendly testrpc

https://github.com/trufflesuite/ganache

Solidity and Truffle Tips and Tricks - default visibility

Dafault visibility in Solidity:
- for variables: private
- for functions: public

Solidity and Truffle Tips and Tricks - delete

Deleting objects and different variables are usually possible, however delete actually does not delete objects in solidity but it sets the values to the default value, like 0. As in the following examples, setMyMapping creates a new mapping element and initializes with _value. However deleteMyMapping does not actually deletes that element, instead it sets the value to zero. 

contract TetDelete{

mapping(string => uint) myMapping ;

  function getMyMapping (string _input) returns (uint){
      return myMapping[_input];
  }
  
    function setMyMapping (string _input, uint _value){
      myMapping[_input] = _value;
  }

  function deleteMyMapping(string _input){
      delete  myMapping[_input];
  }
}

Solidity and Truffle Tips and Tricks - function pointers

There is a possibility to use function pointers in solidity. Practically you can define a function and set a variable defining the type of the variable as var:

contract TetFunctionPointer{

  function myFunction (uint256 input){
  }

  function testFunction(){
      var fvPointer = this.myFunction;
      fvPointer(22);
  }
}

Solidity and Truffle Tips and Tricks - overriding built-in functions

Some items in solidity like the type address has a couple of built in function for transferring ether or querying balance. The functions are the followings:

<address>.balance (uint256):

balance of the Address in Wei

<address>.transfer(uint256 amount):

send given amount of Wei to Address, throws on failure

<address>.send(uint256 amount) returns (bool):

send given amount of Wei to Address, returns false on failure

 

you can not make inheritance from a built in type, however what you can do is to define the same functions in a custom class, indirectly overwriting these functions. 

contract ExtAddress{

  function balance (uint256){

  }

  function transfer(uint256 amount){

  }

  function send(uint256 amount) returns (bool){

  }

}

They do not directly overwrite the address functions, however in certain situations the functions can be exchanged for the first site. 

Solidity and Truffle Tips and Tricks - blockchash

you can use the blockchash() function to query the hash of a block from the blockchain. However, it is important to note that the hash of the latest or actually block is actually not known in execution time, because the block is still being minded. As a consequence block.blockhash(block.number) results always null.

Otherwise the blockchash might be zero for old blocks as well, as Ethereum stores only the last 256 block hashes for scalability reasons. 

Solidity and Truffle Tips and Tricks - order of modifiers

If you have several modifiers in a solidity function these modifiers might be dependent from each other, hence they might self modify the world state giving the possibility for another precondition for the next check. Anyway, the order of evaluation is from left to right as probably expected. So executing the test() function in the following code results "three"in the num variable. 

contract TestContract {

    string public num = "zero";

    

    modifier one(){

        num = "one";

        _;        

    }

    

    modifier two(){

        num = "two";

        _;        

    }

    modifier three(){

        num = "three";

        _;        

    }

    function test() one two three {

    }

}

Computational and business models for tokenisation

As most blockchain platforms are built on different tokens and cryptoassets it can be foreseen that most new state of the art blockchain end user applications will be based from an architectural perspective on tokens. For this reason it is an interesting question how different computational models and IT architectures can be reformulated based on tokens. Among the others:

- How accounting can be built on tokens, similarly as triple accounting ?

- How workflows can be built up with the help of tokens ? 

- How business processes can be formulated with the help of tokens ? 

- How token based collaboration models can be set ?

- How data flow models can be defined by tokens ?

- How business models can be defined with the help of tokens ?

- How organisational structure can be defined on tokens ?

- How blockchain tokens and classical database or network technology can be integrated with each other ?
- How markets can be built on tokens ?
- How AI and machine learning can be built on tokens ?

...

- What other kind of token based computational model can be imagined ?

Solidity and Truffle Tips and Tricks - all past events of a contract

So, if you want to read out all of the events of a contract and you have a geth client and a synchronized blockchain, even if you synchronized the blockchain with the --fast directive, you can use the following pattern: 

var abi = [{...}];

var contract= web3.eth.contract(abi);

var corionRef =contract.at(<... address...>);

corionRef.<Event>({},{fromBlock:0,toBlock: 'latest'}).get(
  function (error, eventResult) {
    if (error) console.log('Error in Event event handler: ' +
        error); 
    else console.log('Event result:'+ JSON.stringify(eventResult));
});

Blockchain + smart contracts and business logic

From an architecture perspective, initial versions of a blockchain protocol, like bitcoin had a pretty simple architecture: transactions were put into the system that were validated by nodes and ordered into batches by the miners and the state transaction was computed as well in the same time. This architecture was further developed by smart contract systems like Ethereum in a way that instead of simple transactions, a complex business logic can be executed named as smart contract. 

As smart contracts seem to be a natural way to define general business logic into a blockchain system there might be a fundamentally different way of extending a blockchain architecture. Mining or ordering service is responsible for finding a subset of the transactions that are consistent and avoid double spending. However this logic can be something much more difficult, like solving different graph algorithms on the transactional graph or even general computational algorithms like something with constraint satisfaction or rule based systems. It might be even an option to define ordering based business logic as different modules that might be dynamically configured. 

In this sense business logic in a blockchain system might be designed in a two level way, similarly as in a classical software design there is client side and server side business logic:

- business logic that extends a given transaction and influences only one or just a couple of addresses should be realized as a smart contract.

- business logic that effects all of the accounts and transactions and the perhaps the ordering logic of the infrastructure as well should be realized together with the ordering service as an attachable business logic module.