A Tale of Two States
Bitcoin and Ethereum as State Transition Systems
--
The Ethereum White Paper explains Bitcoin as a State Transition System. Bitcoin state is a collection of accounts[1] and the system moves from state to state by executing transactions that credit one account and debit another.
Ethereum aspires to enable more complex transitions. Instead of just standard debiting and crediting, more complex computations should be possible. These operations are sequences of bytecodes for the Ethereum Virtual Machine and are usually expressed in one of the higher languages made for that machine (like Serpent).
To achieve that goal, the original Bitcoin state had to be extended by adding two extra elements to accounts: program text and data[2]. The data consists of bytes interpreted by the program text. By crediting such an account with ethers, the program is executed.
Program text is represented with bytes, too, so one might be tempted to think Ethereum is just like Bitcoin with a minimal extension of accounts with two fields and complex state transitions.
But this misses a very important difference between the two systems. Bitcoin state has declarative semantics, while Ethereum state has imperative semantics.
Bitcoin is, for all its ingenious mechanics (for distribution; for reaching consensus; for using proof of work to create non-repudiation), a simple system to understand. By this I mean that it is not difficult to understand what it is for and what exactly is the meaning of the data put into it. It’s just a bunch of accounts. It’s semantics is transparent.
Ethereum’s semantics is anything but that.
[1] In reality Bitcoin is a collection of owned coins. However, for the purposes of this paper we can pretend it to be a collection of accounts and transactions between them, without compromising the force of the argument.
[2] Such an account is called a Smart Contract.
Imperative versus declarative
A declarative description is some representation we use to inform others about how something is. An imperative description can be used to tell others how to do something. Doing things changes state.
As an example to clarify the difference between both, consider the concept ‘destination’, as in the destination of a journey. For a visitor, one’s house is the destination of the journey he has to make. One could help the visitor in one of two ways to reach that destination: with
- an address, or
- a description of the route from some known departure point.
On following the route description, the visitor executes a series of instructions that will bring him to one’s front door. In contrast, when provided with an address, the visitor has to find his way by himself. He will succeed, because he will recognize his destination (in our cities streets are named and houses have numbers!) [3].
A database is a declarative description of a part of reality. Bitcoin is a good example: the database describes how many bitcoins are owned by whom.
A program written in Javascript, C# or Serpent, however, is a recipe to compute something. What that something is, can usually only be concluded by running the program on a computer[4]. Essentially, such programs represent part of reality with a collection of variables. Program execution simulates processes in reality and the variables may take on many different values over the course of the run, settling on final values when the computation finishes.
The meaning of a declarative description can be read from the description itself; the meaning of an imperative description cannot, it is the outcome of an arbitrarily complex process.
[3] Even without a map (and given enough time), just wandering around randomly will eventually bring him to your front door!
[4] Experienced programmers will be able to predict an outcome just by reading a not too complex program. However, for each programmer there is some value for ‘complex’ that will exceed his capacity.
Ethereum state is imperative
The programming languages created for the Ethereum Virtual Machine are imperative: they allow for variables that the program can assign values to, arbitrarily many times. A Smart Contract is an imperative program. Each Smart Contract has state that is persisted from one run of the contract to the next (represented in the extra data of the account). We should think of an Ethereum account as a State Transition System itself.
So Ethereum really is a State Transition System that has state that is a collection of State Transition Systems!
The meaning of the data
It might be easier to understand the implication of the imperative nature of Ethereum state, by considering the question: what is the meaning of the extra data of an account? This data consists of (arbitrary many) bytes that will be used (interpreted) by the program code of the Smart Contract.
So this is a database with a single table (the accounts are the rows) where one of the columns has a unique interpretation for each record! Not just a unique value — in fact, a whole new way of attributing meaning to its value, for each record. A meaning that in principle can only be established by executing a program (unique to each record). This is a very unusual database, indeed.
As a matter of fact, you should not think of it as a database at all. That is the implication of Ethereum’s imperative semantics, and that is why it departs radically from Bitcoin’s declarative semantics.
A declarative alternative
The creators of Ethereum could have chosen a different path. They might have varied on the Bitcoin theme by using a functional language for its state transitions[5]. A program in such languages does not have state that can be arbitrarily changed. Programs in such languages have a declarative semantics. By using a functional language, complex state transitions would have become possible, while the nature of the states themselves would have remained unchanged (to wit, named accounts). Both state transitions and states themselves would have had declarative semantics.
Ethereum, as a State Transition System, would have been much more like Bitcoin.
On top of that the state description itself could have allowed more complexity, by deploying a richer descriptive language with a declarative semantics. The languages created for the Semantic Web (such as RDF and OWL) would have been excellent candidates.
Ethereum is a deployment option for imperative programs
We should foremost understand Ethereum as a deployment option. A Smart Contract is an imperative program that has access to accounts, that is guaranteed to run (by transferring ethers to it): non-censorship[6]. Moreover, there is no authority that prohibits some programs: non-discrimination. Both qualities, expressed as point 5 of the Ethereum Philosophy, are very special.
However, these qualities incur a cost, in terms of understandability. Being imperative, the Ethereum languages suffer from exactly the same problems that are well known from ordinary IT. Problems that have been attacked for decennia by adding new concepts to languages (such as procedures, blocks and strong typing) and new tools (type checkers, intellisense, syntax coloring, debuggers, steppers, etc.). This is where the big IDE’s make a difference: in helping the programmer overcome the inherent complexities of imperative programming.
Ethereum, however, is at the begin of that journey. It might take a long time before programming for Ethereum is being supported in the same way as programming in Javascript, C#, etc.
[5] Or a declarative language such as Prolog.
[6] At least, as long as the Blockchain is run by at least one node!
Conclusion
Bitcoin can be understood as a database, with special deployment. Ethereum must be understood as (imperative) programming, with special deployment. Strip away the deployment and you end up with the difference between a database and a programming language.
There is no comparison, no equal footing to compare both systems. Both systems being based on Blockchain creates a misleading sense of comparability. Actually, the term ‘Smart Contract’ adds to this confusion. A contract is the statement of a relation between parties. As such, it describes part of the world as it should be. With a stretch, we could call this declarative semantics. However, Ethereum Smart Contracts are imperative programs. They are not like ordinary contracts, at all.
