Ethereum – A Quick Overview

Posted: July 18, 2016 in Work Stuff


Ethereum is a technology that extends the concept of the secure BlockChain (made popular by BitCoin) by the addition of smart contracts. These contracts allow for facilitating, enforcing and validating of agreements between two or more parties.

The idea is that the smart contracts are written to the BlockChain and then deployed into a virtual machine that then runs inputs against the contracts and returns results. The contracts are written using one of two Ethereum specific languages and then compiled into a bytecode version for use by the Ethereum ecosystem in the form of DApps.

Once deployed to the BlockChain the contracts cannot be changed, but can be used by anyone.

The Idea

The initial concept behind investigating the use of smart contracts in Ethereum was the implementation of a marketplace for video assets. By using a smart contract, we could potentially enable both digital and access rights management for an asset, without the need for third-parties to provide ‘trusted services’.

This would allow for Studios to sell niche or older assets directly to the customers without the costs associated with going through normal video sale channels.

The Issues

Investigations into using Ethereum have run into issues that have effectively prevented us from building any form of working anything, let alone an actual prototype.

The platform was evolving fairly rapidly, with all the associated issues that this causes – out of date tutorials and documentation, broken tools, fragmented development environments and frameworks. Given the scale of the platform, this fragmentation is more obvious and problematic

From A 101 Noob Intro to Programming Smart Contracts on Ethereum

A development cycle in Ethereum would be to develop a contract locally with testing to ensure it works. Then you can either deploy to the Ethereum TestNet or to a private BlockChain in your own network that you have created. This would allow access by multiple users simultaneously to ensure that the contract still behaved as expected. Finally, the contract would be deployed into the real world for use by the DApp clients.


To build a contract you need a set of tools that work – even at this early stage we would expect the ability to write a contract and debug it without significant issues.

However, the toolset to build and deploy contracts is not complete. Issues include the deprecation of key components without working replacements. Tools such as AlethZero that supposedly allowed you to deploy contracts and interact with them are being replaced by a new IDE called Mix.

Mix needs to be built from source, but fails to build on most occasions. Once it does build, it is unstable and exits without warning when trying to write and test contracts. Mix is apparently the only tool that allows you to see inside a BlockChain for debugging. Without this ability, it becomes difficult to properly test contracts and the libraries trying to interact with them.

While AlethZero still exists, it is not updated and now seems to be missing functionality caused by the platform evolving, limiting its usefulness.

The core Ethereum ecosystem is written in Go and C++, with two distinct languages created for writing contracts – Serpent (with a syntax similar to Python) and Solidity (with a syntax similar to JavaScript). Both languages need to be compiled to bytecode (Abi) prior to use.

Converting to bytecode requires a compiler that also needs to be built from source – although this is a more reliable process than building Mix, it is still unpredictable. Tools such as Mix have a compiler built in, but as they are unstable, getting a contract written in another editor and then converting it is an awkward process.


There are two significant frameworks written by third-parties that attempt to make the contract creation process much less painful – Truffle and Embark. Both are NodeJS based apps that allow you to undertake some contract development. They allow for the creation of a contract, compilation to a JavaScript library and deployment as part of a web-based app. However neither allows you to actually see the resulting BlockChain and its contents for debugging and neither are of any use if you want to write an app that is not HTML based.

Both frameworks also contain bugs that have caused issues when trying to build contracts.


While the idea behind Ethereum and the use of Smart Contracts has a huge amount of potential, it is currently hampered by a poor tool set and development environment. This situation is not likely to improve in the near future as the platform is frozen while the community tries to find a solution to the problems caused by the loss of almost $53 million in funds from the DAO core system by a hack.

This hack also served to underline some significant flaws in the virtual machine that runs everything and the languages that have been built upon it. It appears that changes to the underlying VM will be needed to remove the revealed security flaws. Developing a new VM would mean rebuilding the BlockChain from scratch on the new VM, something that is unlikely to happen given the amount of money currently locked into the Ethereum ecosystem.

The languages available, although being presented as a language especially tailored for Smart Contracts, are not much different than regular programming languages (in fact, they are Turing complete). This means that everything written in them is entirely procedural and that no notions, terminology or vocabulary of high-level concepts of contracting can be used in the contracts’ code. While this might not seem important at first sight, it actually entails two big problems:

1. The procedural code can potentially be too complex to understand or verify prior to execution. This is one of the main reasons that the DAO code, even after being audited twice, had important vulnerability issues causing the problems aforementioned.

2. Contracts cannot be properly monitored or formally checked without the use of high-level contracting notions (fulfilment, violation, parties, clauses) at the language level. This is widely accepted in the field of the research of electronic contracting but the Ethereum developers have completely ignored it.

Given the weakness and instability in the platform and its toolset, we feel that further investigations in this technology needs to wait for either an alternative platform to emerge or for Ethereum to address these issues and create a more stable toolset.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s