Blockchain Technology Evolution

This is the 2nd of the 6 articles that I wrote for my course at the Singapore University of Social Sciences. The first part is here.

The past: The vending machine days

After the 2008 release of Satoshi’s whitepaper, Bitcoin gained some attention. People realized very early that the same decentralized, trustless technology can be used for other use cases other than transfers.

There were several projects started on the same bitcoin codebase. A few of the notable ones:

• Namecoin in 2011 – providing decentralized domain name service.
• Bytecoin in 2012 – The first privacy-centric token, utilizing the CryptoNote algorithm.
• Dogecoin in 2013 – So Coin, Much Purpose
• Aurora in 2014 – A digital currency for Iceland
• Monero in 2014 – Privacy, using CryptoNote and ring signatures.

Difficulties In Implementation

Bitcoin – by design – was created to do one thing – transfer bitcoins. So every change in the use case required a significant amount of development. The Bitcoin source code had to be forked (copied), and the copied code had to be significantly modified.

Because of that, every new implementation required highly specialized developers, who were well versed in cryptography, security and decentralized systems.

This made utilizing the new technology significantly more difficult.

Security In Numbers

Implementation was difficult enough – there were probably no more than a few hundred people in the world who had the skillset to touch that code.

But the operation after the deployment was the real deal breaker.

The Bitcoin network’s security lies in the number of nodes running the blockchain.

The more nodes (computers) sharing the data, the more secure the network becomes. If a malicious actor can operate 51% of the nodes, it can take over the network.

This is because – again – Bitcoin is a decentralized network. So if there is any dispute, the network has to come up with a consensus. The consensus is reached by simple majority – 51% of the nodes have to agree on a state of the network. Once there is a majority, the state becomes truth, that is accepted by the whole network. So a malicious actor with 51% of the nodes can rewrite history and damage the integrity of the network.

It is easy to see, that if the network has only 5 nodes, then all the attacker needs is 6 more nodes, and then the network can be hijacked. But if the network has 50,000 nodes, then taking it over is a much bigger challenge.

The more nodes, the safer the network is.

So every new deployed use case had to attract a significant amount of nodes (miners) before the network could be considered to be secure.

But attracting miners was still not enough — if said miners left for a better deal, for example for a new, more profitable coin to mine, then the network would become vulnerable again.

The need for a framework

It was realized early that both problems — difficult to implement use case, difficult to keep the network secure — could be solved with a framework. When we carefully observe the use cases:

Then we can realize that most of the architecture is the same, or similar enough.

Changing the use case of the bitcoin code was like modifying a vending machine to add new functionality to it. It is possible, but the effort is almost prohibitive. This was a very clear obstacle for the technology to gain acceptance.

Even ignoring the very significant security-by-numbers model, copying a complex code stack and keeping it up to date was going to become an engineering nightmare. Every bugfix, security issue, or improvement had to be implemented by each team independently.

It was not going to work.

The solution — in theory — is trivial. Use a common blockchain that is scriptable/programmable, so the different use cases can be implemented on top of it. This approach has several obvious advantages:

1. Implementation is easier. The developer can focus on the use case only, and take all the complex architecture for granted. Also, no need for crypto specialists.
2. If multiple applications can be deployed on the same blockchain, every application is as secure as the entirety of the whole network. This solves the “security by adoption” problem.

The Present: Multipurpose Blockchains

In 2013, Vitalik Buterin and his co-founders started a crowdfunding campaign to fund the development of a fully Turing-complete blockchain, called Ethereum.

Ethereum aimed to be the personal computer as opposed to being Bitcoin’s vending machine. Both the PC and the vending machine are computers, but the personal computer was designed to implement various use cases, without needing any structural change. The purpose of the computer can be completely changed, depending on what kind of software one runs on it.

In order to accomplish this, it needs much more complex input and output devices. Also, it is more difficult to implement it and to keep it secure.

EVM

Ethereum’s central piece is the EVM, the ethereum virtual machine. While Bitcoin’s miners process and validate transactions, Ethereum’s miners execute actual code deployed on the blockchain. Ethereum is the framework that provides the cryptography, the security, and the decentralized infrastructure. The programs (also known as “smart contracts”) implement the actual use cases.

The transactions on the ethereum blockchain can be:

• Actual transaction of ether — sending ether from one address to another
• Deployment of smart contracts — bytecode gets deployed to the blockchain. This code gets its own address, and can be called like an API call or a remote service after the block is mined.
• Execution of deployed code. For example, the smart contract could be two functions that sets and returns a variable. Then, by calling the “set” function, it will generate a new ethereum transaction, and when the transaction gets included into the new block, the function has been run and the results have been recorded on the blockchain.

The Future: Autonomous Organizations

This is not a specific use case, more like a fundamental property of blockchain-based applications.

Once a smart contract is deployed, it only obeys by its own code. Not even the author/deployer can do anything about that.

For example, if a contract has a bug in its withdraw() function, then it is possible that the funds sent to the contract will be lost forever. They will be there, but not accessible. This is not a theoretical scenario — it has happened multiple times that funds got frozen in smart contracts because of bugs.

This can happen because every time a smart contract code runs, it gets executed by every miner on the network. And the code comes from the blockchain, and it can’t be modified.

With open source code, one can publish the source and it can be audited by others. But it is still impossible to assure that the code running on the server is actually the exact same code.

With smart contracts not only the source code is open, but one can observe the exact code that is deployed on the blockchain, and in fact, every single execution of every function can be monitored.

This presents an unprecedented level of accountability. Every line of the deployed code and every detail of every execution is recorded and can be audited by everyone. This was not technically possible before.

This could enable a potentially new era in business collaboration. It has the potential to grow into a true collaborative economy where the mediator can be mathematically proven to be impartial and fair.

Conclusion

Blockchains are evolving from single-purpose applications to frameworks. Their fundamentals remain the same.