Bitcoin took the world by surprise in the year 2009 and popularized the idea of decentralized secure monetary transactions. The concepts behind it, however, can be extended to much more than just digital currencies. Ethereum attempts to do that, marrying the power of decentralized transactions with a Turing-complete contract system. In this post, we will take a closer look at how Ethereum works and what makes it different from Bitcoin and other blockchains. Read on!
This is post 2 of a three-post series about Ethereum. Read post 1 if you haven't done so.
In our previous post, we took a closer look at what blockchains are and how they help in making distributed, verifiable transactions a possibility. Our main example was Bitcoin: the world's most popular cryptocurrency. Millions of dollars, in the form of bitcoins, are traded each day, making Bitcoin one of the most prominent examples of the viability of the blockchain concept.
Have you ever found yourself asking this question: "what would happen if the provider of this service or application disappeared?" If you have, then learning about Ethereum can make a big difference for you. Ethereum is a platform to run decentralized applications: applications that do not rely on any central server. In this post, we will explore how Ethereum works and build a simple PoC application related to authentication.
A blockchain is a distributed, verifiable datastore. It works by marrying public-key cryptography with the noble concept of the proof-of-work.
Each transaction in the blockchain is signed by the rightful owner of the resource being traded in the transaction. When new coins (resources) are created they are assigned to an owner. This owner, in turn, can prepare new transactions that send those coins to others by simply embedding the new owner's public key in the transaction and then signing the transaction with his or her private key. In this way, a verifiable link of transactions is created; each new transaction, with a new owner, pointing to the previous transaction, with the previous owner.
To order these transactions and prevent the double-spending problem, blockchains use the proof-of-work concept. Proof-of-work is a procedure that establishes a cost for grouping transactions in a certain order and adding them to the blockchain. These groups of transactions are called blocks. Each block points to a previous block in the chain, thus the name blockchain. By making blocks costly to make and making sure each new block points to the previous block, any potential attacker wanting to modify the history of transactions as represented by the blockchain must pay the cost of each block modified. Since blocks point to previous blocks, modifying an old block requires paying the cost for all blocks after it, making changes to old blocks very costly. A blockchain compounds the difficulty of modifying the blockchain by making the cost of creating blocks be of computational nature. In other words, to create new blocks, a certain amount of CPU power must be spent. Since CPU power is dependent on the advancement of technology, it is very hard for any single malicious entity to amass enough CPU power to outspend the rest of the network. A practical attack against a blockchain-based network usually requires a single entity controlling more than 50% of the combined CPU power of the network. The bigger the network, the harder it is to perform.
But, as we saw in our first post in this series, blockchains are more than just that. Transactions, by their very nature, can do more than just send resources from owner A to owner B. In fact, the very act of doing so can be described as a very simple program: the sender produces a computation (transaction) that can only be performed if the receiver produces, at some point in the future, the right inputs. In the case of a standard monetary transaction, the right input would be the proof of ownership from the receiver. In other words, the receiver can only spend the coins he received if he proves he is the rightful owner of those coins. It may seem a bit contrived but it really isn't. When you perform a wire transfer, you prove you are the owner of an account through some sort of authentication procedure. For a home-banking system, that could simply be a username and a password. At a bank, it would be your ID or debit card. These procedures are usually hardwired into the system, but with blockchains it needn't be so.
In our first post, we also took a cursory look at this. We first showed how Bitcoin transactions are, in fact, small programs that are interpreted by each node using a simple stack-based virtual machine.
<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
This virtual machine, in the case of Bitcoin, is limited by design. It is not Turing-complete and can only perform a limited number of operations. Still, its flexibility opened up the possibility for many interesting uses. The small script above, a.k.a. smart contract is the standard "pay to pubkey hash" Bitcoin script. It describes a small program that allows a sender to send coins to a receiver by verifying his identity with a public key: the standard A to B monetary transaction, with ID cards substituted with public and private keys. However, there's nothing preventing other uses, as long as you stick to the available operations supported by the virtual machine. We took a look at a possible use in our previous post, where we created a perpetual message system: immutable messages timestamped and forever embedded in the blockchain. The older they get, the harder it is for them to ever be changed. Nifty.
Now, we'll take a look at how Ethereum amplifies these concepts.
Ethereum: A Programmable Blockchain
Although the concept of the blockchain was born out of the research into cryptocurrencies, they are much more powerful than just that. A blockchain essentially encodes one thing: state transitions. Whenever someone sends a coin in Bitcoin to someone else, the global state of the blockchain is changed. Moments before account A held 50 coins, now account A is empty and account B holds 50 coins. Furthermore, the blockchain provides a cryptographically secure way of performing these state transitions. In other words, not only the state of the blockchain can be verified by any outside party, but any state transitions initiated by Blockchain users can only be performed in a secure, verifiable manner.
All software systems deal in some way or another with state transitions. So what if we could generalize the state transitions inside a blockchain into any software we could think of. Are there any inherent limitations in the blockchain concept that would prevent state transitions from being something different than sending coins? The answer is no. Blockchains deal with reaching consensus for decentralized computations, it does not matter what those computations are. And this is exactly what the Ethereum network brings to the table: a blockchain that can perform any computation as part of a transaction.
It is easy to get lost in the world of cryptocurrencies and simple exchanges of value between two users, but there are many other applications where distributed, secure computations make sense. It is this system that allows for things like:
- Secure deposits that get returned to the payer if conditions are met (or not).
- Money that cannot be spent unless a certain number of users agree to spend it.
- Money that can only be spent after producing external data that satisfies rules set in the script.
Given a Turing-complete system for computations associated to a blockchain, many more applications are possible. This is Ethereum.
Take a look at the things the community is working on to get a sense of the many useful ideas that can be run as decentralized applications.
Tune back in tomorrow, when we'll talk in more detail about Ether and Smart Contracts.