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}); 

Solidity gas optimization - using logs instead of state variables

In Ethereum one of the most expensive operation is storing value in the blockchain itself, costing 20000 gas for creating a new variable and 500 to modify them. However, if you do not need to access the variable from another contract, just from outside of the ethereum virtual machine, like from a javascript UI, you can simply use an event that is written into the log of the blockchain instead of a state variable. Writing a log costs only 375 gas, certainly it works with a little bit different semantics as setting the value of a variable and can not be called from a contract, so it has to be carefully analyzed if it can be used in a certain usecase.

The idea can be executed in a more formal fashion as well, like creating an explicit state variable analysis of the smart contracts which shows for each state variable if it is necessarily needed to be accessed from a smart contract at the moment or in the future.