Ethereum
In my previous post, we’ve gone over the high-level structure of blockchain and its attributes. This post covers Ethereum and explore how blockchain can be used not only for money transfer but also application development.
More Than Money
The idea behind Ethereum was proposed by Vitalik Buterin. He wanted to apply the idea of decentralization to build applications with a central authority in control. He first proposed to add a scripting language to Bitcoin but was later rejected. Later, Dr. Gavin Wood released the Ethereum yellow paper, covering the Ethereum Virtual Machine (EVM) which is capable of executing smart contracts on the network.
Similar to blockchain, all computers across the Ethereum network have a full copy (ledger) of the application code and data. That means the platform can provide services at any time, without censorship or third-part interferences (however, this doesn’t necessarily mean extreme scalability nor low application response time).
Ethereum Architecture
To understand the high-level architecture of Ethereum, we compare it with the traditional client/server architecture. I really like Zastrin’s illustration.
Here is how a traditional client/server architecture looks like:
The main point is that the web application is deployed on centralized platforms or hosting services like AWS. All client applications need to access the centralized component for requested services.
The architecture of Ethereum is shown below:
The major difference here is that each client interacts with a decentralized application instead. Each computer holds a replica of all the data as well as the code. You can think of your computer as a dedicated mini server handling only your requests. Of course, what this implies is you will need to download the entire Ethereum blockchain to be able to use the application.
This is obviously infeasible. In practice, there are solutions like Metamask to mitigate the problem so your storage space won’t be saturated. But the high-level concept holds.
A Ethereum blockchain consists of two components:
Database: this is similar to the database we use in the traditional client/server architecture. The difference lies in how the data is represented and stored. Ethereum stores events as transactions which are exactly the same as BTC transactions, but are much more general as they can store anything ranging from a git commit message to a blog post. It can even be used to represent something more abstract such as ownership of artwork in the form of non-fungible tokens. Because Ethereum is a public blockchain, all the data stored in the blockchain will be visible to the public.
Smart Contract: this is fancy name for application code. The code is compiled into Ethereum Byte Code and then executed by the EVM.
The interesting part is the association between contract and code. ‘‘Contract’’ implies some form of agreement enforced by certain rules. ‘‘Code’’ on the other hand can be much more flexible. The reason behind this is that code deployed on the Ethereum blockchain can enforce the agreement because, once deployed, it can not be terminated or modified. The beauty behind this is that the smart contract is deployed in a distributed network. A successful tampering attempt can only be achieved through agreement from majority, which is hard to achieve.
How is identity established?
In a traditional server/client application, for example, like GitHub, a user account is identified using the username. To managed an account, a user must have the corresponding password to access and modify the information in the account. The notion of account in Ethereum is also similar. An account have a Ethereum address which is visible to the entire network just like a GitHub username. The private key is used to control an the account and is not meant to be shared publicly, which corresponds to your GitHub account password. The exception is the contract account. Intuitively, ths makes sense because it is meant to be accessed by all parties in the contract.
Not a Silver Bullet
There has been a lot of hype around Ethereum and blockchain in the business world. However, Ethereum is not meant to be the solution for all problems.
The root of Ethereum lies in decentralization. The benefit of decentralization comes at a cost. Because any request on the Ethereum blockchain has to go through multiple stages of verification, validation, and consensus, the response latency makes it unbearable for any application that needs to meet stringent time requirements.
For example, posting a Twitter can be done in a matter of seconds. All it takes is for the client to send the tweet to the server. The server adds the tweet in its database, and update the information to other clients. Doing this in Ethereum means we need to first seek agreement from multiple other nodes with completely network conditions, wait for consensus to be achieved (which takes some time), before the tweet becomes valid.
In fact, we have a simple prototype using Ethereum to provide a platform (like Patreon) for artists to demonstrate their artwork and receive financial support directly from their community without any third-party agencies. The advantage is, by avoiding third-party agencies, we reduced the cost of transaction. However, the problem is, whenever a user click the ‘’like’’ button, the information would not be reflected until minutes later. This would be unacceptable for products like Facebook or Instagram.