Ethereum solidity security tools summarized

 

Security in solidity - Ethereum has been always one of the most important topic. Some of the current most important tools are the followings:

SWC Registry /  

Smart Contract Weakness Classification and Test Cases

https://swcregistry.io/

Ethereum Smart Contract Security Best Practices 

https://consensys.github.io/smart-contract-best-practices/

MythX - a cool tool for getting information on solidity smart contract vulnerabilities 

https://mythx.io/ 

EthLint - an open source tool for analyzing Ethereum smart contracts. 

https://github.com/duaraghav8/Ethlint

Slither  - for making static code analysis on solidity contracts

https://github.com/crytic/slither

Hydra - framework for security and bug bounties

https://github.com/IC3Hydra/Hydra

How to get test DAI on Kovan

 

Getting test tokens on the test nets are not always simple. As an example on Kovan for getting test DAI for ethere, you can use the following repo: https://github.com/Daniel-Szego/DAIFaucet

The process is simply: 

Getting DAI test tokens on Kovan

Simple interface for changing ETH to DAI with the help of Uniswap

Kovan deployment: 0x786e3c83cd270414649079A758Ad92f961EDdA0A

Usage (Kovan only): 

Send ether to the DAIFaucet smart contract: 0x786e3c83cd270414649079A758Ad92f961EDdA0A

be sure that the gas limit is high enough, like 300.000 because it is a contract call

Changed DAI token will be available on your address. We use DAI token with address (on Kovan) : 0x4F96Fe3b7A6Cf9725f59d353F723c1bDb64CA6Aa

Exchange rate depends on Uniswap, it can be far from the mainnet exchange rates

Kovan DAI test tokens only, do not use it in production !

 

European Blockchain Infrastructure

EBSI (European Blockchain Service Infrastructure) is a blockchain service provided by the European Union in a test phase for the time being, with the aim of providing a single blockchain service to Member States. The antecedents of the project include the European Blockchain Agreement of 2018, to which Hungary also joined in 2019. On the other hand, the Alastria network, which provides the countries of the Iberian Peninsula with a quasi-state distributed general ledger technology platform, using a modified Ethereum / Quorum technology.

The development of the platform runs on several levels: on the one hand, they try to integrate as many countries as possible at Member State level and run local nodes in as many places as possible. From this point of view, the system can be considered as a consortium blockchain: no one can connect to the network and run their own node completely freely, but it is possible to create a fixed number of dedicated nodes per country. On the other hand, there is a strong emphasis on developing the base platform. This is not a completely new distributed general ledger technology, but the integration of existing and somewhat functional blockchain platforms into a single framework. Currently, the platforms to be integrated are a consortium solution from Ethereum, the Hyperledger Fabric consortium blockchain solution, and the Hyperledger Indy framework for decentralized identification. However, this list is not necessarily final, new basic blockchain technologies may be used in the future.

In addition to the development of the basic platform, the testing of use cases at the small experimental level has also started in parallel. In 2019, the following applications were launched:

- Notarisation: one of the features of the blockchain is that it is very difficult to change the entered transactions, so it is excellent for auditing the consistency of critical data and contracts. In practice, digital fingerprints of sensitive data and an associated timestamp are usually written into the blockchain so that the state of a given document at a given point in time can be audited.

- Diploma: the user case allows university diplomas awarded in the territory of the Union to be verified and easily exchanged between countries.

- European identity system: the use case aims at digitizing the various solutions used for identification in the Union.

- Authentic data sharing: aims at reliable and credible data sharing between the different institutions of the EU Member States.

The list is by no means final. It is planned that new application cases will be selected and implemented each year.

Technologically, the EBSI framework is organized into layers:

- The lowest infrastructure layer is responsible for a reliable and secure network connection between the nodes.

- The “chain and storage” layer implements the specific blockchain services by supplementing it with a so-called off-chain solution suitable for distributed storage.

- “core services” implements EBSI’s core services in a blockchain agonistic way, allowing the underlying blockchain platforms to change.

- The “user-case” layer implements the application cases listed above.

- The aim of the top tier is to enable the Union's industry to implement complex business applications using the layers mentioned above.

As mentioned at the beginning, EBSI is by no means a final service, after the 2019 start-up and initial deployment cases and test phase, new deployment cases will be selected in 2020, followed by the second version of the base platform from 2021. While it is still conceivable that we will have to wait a year or two before we can develop productive applications over EBSI, it is definitely worth keeping an eye on the evolution of the technology.

Ethereum parity node and monitoring

If you run a parity node one of the most important is to check if your sync is running or if it is stopped for some reason. Making sure that the json-rpc is enabled, you can use two checks:

1. Check if the sync is fully synced. 

curl --data '{"method":"eth_syncing","params":[],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545

if you get a false for the above command, it is fully synced. Otherwise you get the actual block number where the sync stays.

2.  Even if it is fully synced, the ancient block sync might be running, so the following command has to show that the blockGap is null:

curl --data '{"method":"parity_chainStatus","params":[],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545

parity tips and tricks - parity docker and persistent storage

If you use parity above 2.3.5 and you want to run with docker in a way that your chain is synced on a persistent storage, like under /srv/parity on an ubuntu machine, you can use something similar to the  following script:

sudo docker run -ti -d --name parity --network=host --user=root --restart=unless-stopped  -v /srv/parity:/home/parity/.local/share/io.parity.ethereum  parity/parity:v2.3.5 --chain=ropsten --geth --jsonrpc-apis "web3,eth,net,parity,parity_accounts,traces,rpc,parity_set,personal" --base-path /home/parity/.local/share/io.parity.ethereum

parity tips and tricks - ancient block sync error

If you use parity 2.3.5 syncing your blockchain and you open a geth console with the synchronization as well, your geth console might show that everything is synced but you can and error with ancient block syncing.

Like the following error: "Block information is incomplete while ancient block sync is still in progress, before it's finished we cant`t determine the existence of item"
In this case check the following :

 curl --data '{"method":"parity_chainStatus","params":[],"id":401697,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545

if it shows that there is still and existing blockgap it means that an ancient block syncing is still in progress, so wait until it finishes. If the sync does not improve check if you did not coicidently start parity with the --no-ancient option.  

Phases of learning solidity programming

Month 1: Yes, I can program in Solidity ! This is an easy language, similar to Javascript, with some types.

Month 2: Wait, Underflow / overflow ? I thought they can not cause problems.

Month 3: But, I should upgrade my contract ? Because it contains already ether and I forgot to implement an etherTransfer function ?

Month 4: Cool, I have some upgrade patterns, but they cost too much ether.

Month 5: Ooh, msg.sender, tr.origin, contract in the middle attacks ?

Month 6: Or, Fallback function ? Reentrancy ?

Month 7: Hmm, A transaction is always atomic, right ? So what is with address.transfer or address.call.value ?

Month 8: And, Libraries, Delegate calls ?

Month 9: Hence,  Stack, call stack attacks and front running?

Month 10: So, How about just reusing some ready libraries ? Like OpenZeppelin ?

Month 11: Or, Formal verification, bug-bounty, military programming ?

Month 12: No, I can not program in Solidity !

Solidity Tips and Tricks - security of the view modifier of a function

Solidity view function modifier means that the function do not modify the storage of the contract, due to the fact that it costs no gas to call this function. However, one might as well assume this feature as a security guarantee, meaning that the function can not modify the storage.  It is important to note however that in the 4. compiler versions there is actually no guarantee for that, the compiler gives a warning, but despite it compiles and deploys the contract without error. As an example, considering the following contracts:

pragma solidity ^0.4.24;

contract ViewImplementation {    
 uint public storageVariable = 0;
    
 function viewFunction() view external returns (uint) {
   storageVariable = 2;
   return 1;
 }
}

contract TestViewImplementation {
    
  address contractAddress =
           0xbbf289d846208c16edc8474705c748aff07732db;
    
 function testView() public {
   ViewImplementation imp =  ViewImplementation(contractAddress);
   imp.viewFunction();
 }  
}

Calling the viewFunction externally implied zero gas consumption and the storageVariable will not be modified. However, calling the function from another contractlike from testView will modifiy the storageVariable to 2.

The situation is fortunately better in the 5+ solidity versions, as there is not only warning but a compiler error as well in such a situations.  

Notes on Ethereum WASM

Ethereum WASM is on the horizon, providing a more stable, flexible and faster programming environment. However introducing the technology might bring a couple of unexpected results. The problem is that with the help of WASM there will be many other languages available for Ethereum programming, apart from Solidity. The real difficulty in Blockchain programming is however not the programming language knowledge, but actually the mindset. As Ethereum smart contracts store a huge amount of money on a public blockchain and actually the deployed code is pretty much immutable, developing such a code requires special considerations. Instead of Agile or DevOps methodologies, defensive programming, formal versification and correct by construction tools should be used. For those who has actually never taken part in mission critical system development, these methodologies are new. The result will be that many software developers with WASM compatible languages will start smart contract development, which will cause again a huge amount of buggy software and a lot of hacks on the public chain. That will result that the general perception of the chain security will be again pretty low.   

Configure Oraclize with an Ethereum consortium or private network

Supposing you want to use Oraclize with a consortium Ethereum blockchain network, like in the simplest case with your Truffle development environment , you have to do the following steps: 

1. Install Ethereum Bridge to one of the node on your Ethereum consortium network: https://github.com/oraclize/ethereum-bridge

git clone https://github.com/oraclize/ethereum-bridge.git
cd ethereum-bridge
npm install

2. Start your Ethereum Bridge, with the network url and an account, like for Truffle:

./ethereum-bridge -H localhost:9545 -a 0 --dev

3. At deploying with truffle, copy the OraclizeAPI_05.sol locally. 

4. You can practically use the same code as on a live network, in the Ethereum Bridge window, you can check the sent and received transactions as well. 

A very simple implementation can be found under EthereumBridge in the following github repo. 

Double spending and replay attacks in different distributed ledger systems

Double spending, avoiding double spending and avoiding replay attacks work differently in the different blockchain and distributed ledger systems, especially if we consider the ledger structure. 

- Bitcoin: in Bitcoin, there are only unspent transaction outputs that behave as coins. At proof of work, the winner miner defines an order of the transactions that are applied to the ledger, to the unspent coins. The rule is that every unspent output can be spent only once, so considering the transaction order of the winning miner, the first valid transaction spending an unspent transaction output will really spend it, the next such a transaction will be considered as double spending. Similarly, old transactions can not be replayed, because the output is already spent. 

- Corda: in some sense Corda uses a similar UTXO, unspent transaction based system as Bitcoin. However, the unspent outputs are not "coins", but complex state information of a contract. Similarly to Bitcoin, one output can be spent only once, realizing an efficient way of avoiding both double spending and replay attacks. As opposed to Bitcoin, there is no proof of work or mining, instead a special dedicated node, called the notary service is responsible for the ordering of the transactions. 

- Ethereum: Ethereum is not an UTXO but an account based system. Practically, every account has some kind of a value field with a nonce that is incremented at every transaction. So a transaction not simply referring to an account but to an  account with a certain nonce. At proof of work or proof of stake, the winning miner or validator creates a block that contain an ordering of the transactions. If there are two transactions referring to the same account with the same nonce, than the first will be executed and the second one will be recognized as double spending. 

- Hyperledger Fabric: Fabric has a little bit similar mechanism than Ethereum. Each transaction is simulated by the smart-contracts at the endorsement peers and read write sets are defined. A read operator is not only defined to a variable but to a version of a variable. As a consequence, two transactions referring to the same input variable in a way that one reads and one writes that variable can be executed only in one specific order. If in one round a transaction already wrote into a variable the version of that variable will be increased, so in the same round, the variable can not be the read input of another transaction. In Fabric, the is no proof of work, but a specific service, called the ordering service is responsible for creating a valid order of the transactions. 

How to trigger Ethereum smart contract if Solidity event occurs

Well you cannot react to an event in a solidity smart contract, there is no command at all in EVM that checks the event log. Besides, there is no way of starting a smart contract automatically. However, you can use a semi-trusted setup with Oraclize, where similarly to my previous blog, you can periodically check if an event has occurred.

Firstly, you can use an Ethereum explorer API to get information of an event of a contract with the following http get request.

https://api-ropsten.etherscan.io/api?module=logs&action=getLogs

   &fromBlock=<from>

   &toBlock=latest

   &address=<contract address>

   &topic0=<event id>&

   apikey=<YourApiKeyToken>

So, what you have to do is to query this log periodically with Oraclize and check if the necessary information is present.

  // schedule update schedules the next call
 function scheduleUpdate() payable {
   if (oraclize_getPrice("URL") > this.balance) {
       LogNewOraclizeQuery("Not enough fund");
   } else {
       // NEXT UPDATE IS SCHEDULED IN 60 MIN
      oraclize_query(60, "URL", " url explorer API for the event ");
   }
 }

 function __callback(bytes32 myid, string result) {

    // SECURITY CHECK

    if (msg.sender != oraclize_cbAddress()) revert();

        

    // PROCESS INFORMATION

    if (information_not_present){

    // SCHEDULE NEXT UPDATE

       scheduleUpdate();

    }

 }

Certainly this is not the cheapest and most efficient way of triggering a smart contract for an event, but it might work on a small scale. Experimental implementation can be found under EventTriggeredEthereumContract in the following GitHub repo. 

Update an Ethereum smart contract periodically with Oraclize

Ethereum smart contracts are normally not able to start automatically on a timely basis, there should be an external service that calls the contract periodically. You can however use Oraclize as an external service for such a use-case. Although Oraclize is an external service that one has to trust, but it works in a relative secure way providing different kind of security guarantees for the execution. Example code can be realized by the following two functions in a smart contract that is inherited from a version of the OrcalizeAPI, like from usingOraclize:

    function __callback(bytes32 myid, string result) {

// SECURITY CHECK

        if (msg.sender != oraclize_cbAddress()) revert();

// SCHEDULE NEXT UPDATE

        scheduleUpdate();

    }

    function scheduleUpdate() payable {

        if (oraclize_getPrice("URL") > this.balance) {

            LogNewOraclizeQuery("Not enough fund");

        } else {

    // NEXT UPDATE IS SCHEDULED IN 60 MIN

            oraclize_query(60, "URL", " .. test url ..");

        }

    }

Experimental implementation can be found under my github repo. Certainly, this is not necessarily the cheapest way for the operation, depending on the exact business logic operational cost might be extreme high. As a simple example, considering a simple code time of writing, the one simple transaction cost of incrementing a state variable with the cost of the service is around  0.01 ether, 

Truffle and solidity tips and tricks - error at contract deployment gas amount

If you deploy a contract with the help of truffle possibly on a development environment and you get the following error message: 

"Error encountered, bailing. Network state unknown. Review successful transactions manually 
Error: The contract code couldn't be stored, please check your gas amount."

Well, there might be the problem of the real gas amount at the deployment, but most typically you want to deploy a contract that has an abstract method, or it inherits coincidentally and abstract method that is not implemented. 

Truffle and solidity tips and tricks - nonce error with Metamask

If you use truffle development environment with Metamask as well you can often get the following error message: "the tx doesn't have the correct nonce". The problem is that you probably use the same accounts both from truffle development console and from the Metamask UI. Unfortunately, Metamask does not automatically update/refresh the nonce if the transaction was executed by the truffle development console. So what you have to do is to reset the Metamask account: Settings - Reset Account. 

Solidity and Truffle Tips and Tricks - converting string to byte32

If you want to convert strings in solidity to byte32 and you get different kind of error messages at  explicit or implicit converting or at changing between memory and storage variables, you can use the following function:

function stringToBytes32(string memory source) 
                                        returns (bytes32 result) {
    bytes memory tempEmptyStringTest = bytes(source);
    if (tempEmptyStringTest.length == 0) {
        return 0x0;
    }

    assembly {
        result := mload(add(source, 32))
    }
}

Strategical roadmap of payment and state channels

Strategical roadmap of different payment and state channels of the Ethereum and Bitcoin stack can be seen on the previous picture. The major categories are the followings: 

- simple payment channels are integrated with Bitcoin or Ethereum and provide the possibility to exchange off-chain tokens between two nodes. 

- lightning network is routed payment channel implementation on Bitcoin, providing the possibility to send transactions between multiply nodes even if they are not directly corrected. 

- micro Raiden is a non routed state channel for transferring ERC20 tokens off-chain and integrated with Ethereum. In micro Raiden multiply 'client' nodes are connected with one common 'server' node. 

- Raiden is a routed state channel for transferring ERC20 tokens off-chain and is integrated with the Ethereum stack. 

- Plasma is a special protocol based on the same ideas. It integrates Ethereum smart contracts with other blockchains. As an example part of the business logic might run on the Ethereum live chain, part of it only on an Ethereum proof of authority chain. 

General state channel implementations are not common at the moment. Perhaps the reason is for that, that cryptoeconomical incentive mechanism can not necessarily used in this case because we do not know what will be implemented by the smart contract. 

On the accounts of a account balances based blockchain system

Accounts of an account-balance based blockchain system are practically storage spaces that access is controlled by a public - private key ownership or identity proof and validated by the nodes. In a simplest case an account stores the balance of a use, a signature with the private key provides kind of a proof of identity, that you are allowed to access to the given account. It is important to note that in a transfer transaction, there are two balances that are validated differently: 

- the from balance must be checked if it matches with the signature of the private key of the account and the balance must be bigger than the amount of cryptocurrency to be transferred. 

- the to account must be compatible however with much less rules. Practically, it must not eve exist, it can be added to the chain on the fly. 

Ethereum extends this simple model to two different kinds of accounts: externally owned accounts and smart contract accounts. As externally owned accounts can practically initiate transactions to smart contracts, with prooved ownership of private public key information, smart contracts only react for external events. However the model can be even further extended. In a certain blockchain system, there can be: 

- Any kind of different account, with different state storage and validation rules, like accounts for miners, validators, special roles executing optimizations...

Notes on blockchain system state

The state of the blockchain can be different in different platforms and representations. In an UTXO bases system, the system state is indirectly represented by the outputs of the transactions. In an account - balance based system, each account contains an internal variable storing the balance and the account can only be changed if the owner signs a transaction with the private key. The model can be extended to contain variables and other elements in the state, just like with Ethereum, where the different state variables can be changed under different validation conditions. Further improvements can be imagined however, both the state and the validation can be hundred percent customized just like at Tendermint and a couple of similar blockchain systems. There might be a separation between standard and system blockchain state, giving an opportunity to on-chain governance. We might as well imagine that the blockchain state contains full scale objects, including properties and functions as well where the object state can be changed only via the functions that has to be signed by the private key related either to the public key of the object or the public key of the functions.  

Types of blockchain governance

One of the critical part of every blockchain solution is governance. It is especially valid for blockchain platforms, like Bitcoin or Ethereum, but it is actually the same for blockchain applications that are realized on the top of a platform. Governance means carrying out changes or further development of the application. There are several models that has different advantages and disadvantages in the practice:

- Off-chain governance means that the governance model is totally independent from the blockchain itself. Changes of the platform is proposed by a community or trusted people and both the implementation and the implementation is carried out by these people as well. Such a model has the advantage that it is technologically less challenging, however it might cause a split in the community resulting a split or hard-fork in the platform itself as well. Such models are realized by Bitcoin and Ethereum where improvements are presented by improvement proposals, like Bitcoin Improvement Proposal (BIP), or Ethereum Improvement Proposal (EIP). The model caused several hard-forks in the above mentioned platforms, resulting for example Bitcoin Cash, or Ethereum Classic. 

- On-chain governance means that several elements of the platform is able to change by a community decision, and both the decision mechanism and the change implementation is supported by the platform itself. Such an example is the difficulty increase or decrease mechanism of the Bitcoin network which is hard-coded in the consensus mechanism and is practically relized by the voting of the miners or the voting of the stakeholders. Other platforms like Monero have much further developed on-chain consensus mechanism, as an example part of the transaction fee is collected into an online wallet as an improvement budget, which can be used for further development or even marketing projects based on the voting of the community. 

From another perspective blockchain governance can be categorized on the fact, who makes the decision. From this point of view there might be the following models: 

- Centralized governance: systems like Ethereum has a pretty centralized governance. From a practical point of view almost all of the changes are governed eventually by Buterin. It has certainly, the advantage of being able to adapt fast, however not necessarily truly open as participation. 

- Open governance: Systems like Bitcoin has a real open governance model. Practically everybody can initiate new changes in the system and the implementation of these changes require a pretty open consensus as well. Practically the core developers, the miners, the exchanges and the shops should all agree in order that a change is implemented successfully. As it is almost a pretty open democratic process, certainly it can be very slow and inefficient in the implementation phase.

- Governance by trusted actors: There can be model between the two previously mentioned examples as well, where several trusted (and sometimes well known) actors can initiate and implement changes in the platform. Such governance model will be implemented directly by Hedera Hashgraph. Similar initiative can be found like in Dash or Monero, where indirectly the stakeholders or the master node responsibles can be regarded as trusted actors.