#5 What about alternatives?

In blog #4 Authentication and Authorization we described our troubles with securing a multi contract Dapp using Ethereum. However there are some more reasons that made us look past this, old but gold, standard. In this blog we will try shine light that and then see if we can figure out our wishes for an alternative.

As mentioned in our last blog security with Dapp of sufficient size is a problem for us. In an ideal situation we would be able to create roles, define what a role is allowed to do, assign those roles to users and check the authorization when accessing functions on a contract. However in multiple attempts we were unsuccessful in creating a failsafe, easy to use mechanism in a multi contract situation. This meant that, at this level of experience, we had our first serious problem with Ethereum.

Proof of Work (PoW)

Ethereum, in its current state is a blockchain based on the “Proof of Work” system, first put into practice by BitCoin. In this system, a couple of transactions are aggregated in a block. The miners in the network are then trying to find a cryptographic hash of that block that surpasses a certain threshold. An example of such a threshold can be: “The hash needs to start with seven zeroes.” The miners try to find this by brute forcing. They increase one value of the block to be called the nonce by one and then calculate the hash of the block. If that hash doesn’t meet the requirement they repeat the process until one of the miners in the network finds a hash that does. When a correct hash is found it is broadcast to the other miners which then validate it. This system takes quite an amount of compute power because of all the computed hashes that are not valid. This takes a lot of energy (and has a large carbon footprint) but is also slow. Partly due to the fact that calculating all these hashes is a slow process, but also due to Ethereum scaling the difficulty to the compute power in the network. When more miners are introduced, Ethereum heightens the threshold. To keep the average time of a block around 16 to 17 seconds.

This is a good thing for the main net, but a for a private network like ours this is quite a problem. When a valid hash is found about every 16–17 seconds, this means that saving data can only happen about every 16–17 seconds. This might not seem like much, that 16–17 is the average, the time between a block can sometimes peak to over 30 seconds. Waiting half a minute before data is saved, is not workable when a normal webapp reliably takes about 3 seconds or less for a similar save action.

We could make our own fork of Ethereum that forgoes upping the difficulty, however we lose all support from the main branch then. If a critical issue is found, we will have to patch it ourselves instead of relying on the Ethereum team for that.

Other than those reasons there is also the issue we described in blog #2 (The search for finding contracts) Ethereum has no way of finding contracts if we don’t know the address. We’ve found a way around that with the address list, but again that is not a solution that is fast. Loading multiple contracts for a list can take multiple minutes, we don’t have to explain that that is a performance issue.

After discussing the struggles we faced with Ethereum, we decided it was time to have a glance at alternatives, because there are many. At first we chose Ethereum because it is the biggest platform that supports smart contracts and thus has the most resources available for development. However after working with it for a while and finding all these struggles, we figured that we have a better understanding in the features we’re looking for.

A list of features we would like to have in a blockchain:

• Short time between blocks
• Possibility to create fully capable smart contracts
• More options for authorization
• Finding smart contracts without the need for an address list

Proof of Stake (PoS)

In 2011 an alternative for the “Proof of Work” system was coined somewhere on a BitCoin forum. This should eliminate some of the problems with the PoW system while still being a secure blockchain technology. In this system the nodes of the network automatically vote on the validity of a block by waging the coin of the network on how sure the program is of the validity of the block. Since the hash of a block doesn’t have to be found there is no instability in the time between blocks. The network creates every block at a specified interval. In some cases this is about the same a Ethereum, however some PoS blockchains can have blocks much quicker than regular PoW blockchains. This will suit our needs much better.

An added benefit of PoS is that it uses a lot less compute power since it is not calculating hundreds of thousands of invalid hashes. This means a computer with lower specs can easily be a node and also the entire ecosystem is more environmentally friendly.

Smart contract development

The ability to create smart contracts differs wildly per type of chain. Some support Solidity, the EVM and full compatibility with Ethereum while others choose to support different languages or no smart contracts at all. Somewhere on the spectrum lie the chains that support non Turing complete smart contracts. While they might be suited for some applications we will probably need the ability to do arbitrary calculations within a smart contract. We don’t have the time to explain Turing completeness in its entirety so we suggest looking it up yourself if you are interested in reading about it more, however the short explanation is that a Turing complete language allows for any and all tasks a computer can do. Sometimes one language is better suited for a task than another but if a language is Turing complete, it means that the task could be done with that language. However if we can already see that the chain doesn’t support a Turing complete language for creating contracts, we can quickly set it aside. We don’t want to cripple ourselves from the start.

Lastly we need to solve the problem with authorization so we need a chain that is likely to give us a better option for figuring out what a user is and isn’t allowed to do. Also we would like to skip having to create an address list as a contract on the blockchain so it would be amazing if the chain supports a way of keeping track of contracts.

We are not entirely certain which one it will be so we invite you to read our endeavours in actually selecting a new chain in our next blog.

If you’ve found this blog in any way helpful, give us a clap!