Solidity Tips and Tricks - empty address

If you want to check if your address is null or equals to the 0 address, you have to use the address(0) keyword, like in the following example:

contract TestContract {

  function isAddressEmpty(address addr) returns (bool) {
    return (addr == address(0));
  }

} 

Solidity Tips and Tricks - comparing strings

In solidity you can not really compare two strings with each other. You can surely compare them as byte arrays practically comparing the characters one by one, however a more elegant way is to compute a hash of the two string and compare simply the two hashes. Due to the cryptographic properties of the hash functions, the chance to have the same hash of two different strings is astronomical small.  An example can be seen bellow:

contract Compare {

    

    function compare (string a, string b) returns (bool){

        return sha3(a) == sha3(b);

    }

}

Solidity Tips and Tricks - delegatecall and callcode

It should be paid attention that delegatecall and callcode are pretty much similar in a lot of senses. Both delegatecall and callcode are executed in the context of the calling contract, meaning that the whole context of the calling contract is actually vulnerable for different attack possibilities. The only difference is that in callcode msg.sender and msg.value are not preserved. As in the following example, the private variable of contract D is changed by callTest even if the function was called indirectly from contract E.

contract D{
    uint private n = 0;
    
    function getN () returns (uint) {
        return n;
    }
    
    function callTest(address _e, uint _n) {
        _e.callcode(bytes4(sha3("setN(uint256)")), _n);
    }
}

contract E{
    uint public n = 0;
    
    function setN(uint _n) {
        n = _n;
    }
}

Solidity Tips and Tricks - private variable and delegatecall

Delegatecall means in solidity that the contract is executed under the context of the calling contract. Pay attention however because that means that even the private variables can be set from a different contract if you call them with delegatecall. As an example, in the following code, calling delegateCallTest will change the private variable n for contract D, even if the variable is marked as private and variable setting is executed in contract E.

contract D{
    uint private n = 0;
    
    function getN () returns (uint) {
        return n;
    }
    
    function delegateCallTest(address _e, uint _n) {
        _e.delegatecall(bytes4(sha3("setN(uint256)")), _n);
    }
}

contract E{
    uint public n = 0;
    
    function setN(uint _n) {
        n = _n;
    }
}

Solidity Tips and Tricks - delegatecall

Delegate call in solidity is somehow tricky. It is basically executed in the context of the calling contract that creates a couple of unexpected behaviors. As an example, considering the following contracts, calling setN is executed in the context of D, meaning that _n variable of D will be set and not for E! Another feature is that msg.sender and msg.value do not change values.

contract D{

    uint public n = 0;

    

    function delegateCallTest(address _e, uint _n) {

        _e.delegatecall(bytes4(sha3("setN(uint256)")), _n);

    }

    

}

contract E{

    uint public n = 0;

    

    function setN(uint _n) {

        n = _n;

    }

} 

Comparing cryptocurrencies with Hyperledger Fabric

Based on the framework of the previous blog and dimensions, we can compare different cryptocurrencies like Bitcoin with Hyperledger Fabric. The characteristics of cryptocurrencies can be seen on the following picture:

The properties of Hyperledger Fabric can be seen on the following picture:

As the comparison shows as well, there are some major differences between the two technologies. As cryptocurrencies are intended to be a public network, Hyperledger Fabric is for consortium use-cases. This fact is visible on the transaction scope, higher transaction privacy, and better performance. Hyperledger Fabric implements a modular consensus mechanism, with several different algorithms, ranging from simple fault tolerance to simple Byzantine fault tolerance (maximum one node error). Another major difference is that Hyperledger Fabric does not implement any kind of a tokens, neither internal, nor external. Of course, transaction semantics is different as well, Hyperledger Fabric has a general purpose smart contract language however cryptocurrencies usually concentrate on one digital asset.  

Comparing Ethereum with Hyperledger Fabric

Based on the framework of the previous blog and dimensions, we can compare Ethereum  with Hyperledger Fabric. The characteristics of Ethereum can be seen on the following picture:

The following picture shows the different relative properties of Hyperledger Fabric:

As the comparison shows as well, there are some major differences between the two technologies. As Ethereum is intended to be a public network, Hyperledger Fabric is for consortium use-cases. This fact is visible on the transaction scope, higher transaction privacy, and better performance. Hyperledger Fabric implements a modular consensus mechanism, with several different algorithms, ranging from simple fault tolerance to simple Byzantine fault tolerance (maximum one node error). Another major difference is that Hyperledger Fabric does not implement any kind of a tokens, neither internal, nor external. 

Comparing cryptocurrencies with ethereum

Based on the framework of the previous blog and dimensions, we can compare standard cryptocurrencies with Ethereum. The characteristics of bitcoin and cryptocurrencies can be seen on the following picture:

And similarly the characteristics of Ethereum can be seen on the following picture:

Comparing the two frameworks, we can see there are differences in two areas. On the one hand, Ethereum provides a much bigger transaction semantics, as it is possible to formulate general Turing complete smart contracts. On the other hand,  Ethereum provides a better performance on consensus mainly because of the modified GHOST / Casper conensus algorithms. As Bitcoin is capable to process 4-7 transactions per second and the average block confirmation is 10 minutes, Ethereum is capable to process around 15 transaction per second and the processing time for a block is around 12 second. 

A framework for analyzing and comparing distributed ledger frameworks

Distributed technologies are getting more and more complex every day and there are an increasing number of different such technologies. For this reason it is important to set up a framework in which different distributed ledger and blockchain technologies can be analyzed and compared with each other. For the general comparison we would defined the following important dimensions:

- Transaction semantics: this dimension simply describes what can be represented by a transaction. In most simply exceptions transaction represent simply the sending of cryptocurrency from one account to another on. In more difficult scenarios, transaction represent general cryptoassets or IOU information. The other end of the possibilities are the general purpose smart contract programming languages, which provide the possibility to implement any kind of programming languages.

- Transaction structure, or rather transaction storage structure: is the way how the transactions are stored. In a blokchain based system the storage is the blockchain itself, but with other technologies like IOTA or Hashgraph, the transaction structure is rather a directed acyclic graph.  

- Transaction privacy: this dimension shows how a distributed ledger system handles transaction privacy and permissions. Most typical blockchain systems are completely public and do not handle privacy or transactions at all, meaning that all transactions are public for everyone and a transaction can be executed if one has the private key. Most cryptocurrency systems are moving to the pseudonym direction, meaning that although the transactions are public, the addresses are hard to associate with physical identities. Advanced, mostly consortium blockchain solutions, realize partial privacy meaning that some part of the transaction, like the amount to be transferred, is hidden and the rest is private. More experimental solutions offer more in the direction of transaction privacy, like with the help of zero knowledge proofs. 

Another direction is crypto-asset permission. Supposing we deal with crypto-assets, it makes sense to define different transactions for creating, reading or modifying a crypto-asset and associate permissions to these transactions. Optionally something as "delete" can be defined as well, like with creating an inverse transaction. 

- Network scope: this dimension described the scope of the P2P network. The most simple network is a private one, even if it is heavily discussed if it makes sense. The next possible solution are the consortium networks where peers of the system are not available to everyone just for a certain number of consortium members, usually concentrating on a specific industrial field. The other end of the range are the public distributed ledger technologies where the network is reachable publicly to everyone.   

- Consensus performance: clearly one of the most important part of every distributed ledger technology is the consensus mechanism. One of the major dimension how different different consensus algorithms can be compared is the performance. Performance can be best described with the average confident processing time of a transaction and the number of transactions that can be processed each second.

- Consensus fault tolerance: the second most important property of the different consensus algorithms is the fault tolerance. The sides of the coin are the simply fault tolerant systems and the maximal byzantine fault tolerant systems, where the system works even if 33% percent of the nodes are taken over by hackers. 

- Token and cryptoeconomics: last but not least, it an important feature for every distributed ledger system how much it contains tokens supporting internal or external mechanisms. Some systems do not have tokens at all, others support tokens only for different internal incentive mechanisms, but of course there are cryptocurrencies and multi-token systems as well. 

  

   

Solidity Tips and Tricks - indexed keyword

You may have seen the indexed keyword in some of the events in solidity, lie :

event Transfer(address indexed _from, address indexed _to, uint256 _amount);

It can be used only in events and has a meaning only outside solidity, like from javascript. If indexed value was used, the event log can be filtered, like with a statement:

var event = contract.Transfer({}, {fromBlock:startingBlock, toBlock: startingBlock + 2000});