As mentioned in the previous post, there are many ways to get to a consensus. It can be used to manage agreement on any data point among a collection of nodes in a computer network. We can expect to use consensus for more than just the balance of ledgers though. For instance, we might use consensus to reach an agreement about the state of any state machine.
In fact, Ethereum is built to do just that.
Ethereum executes programs that are referred to as smart contracts. The programs may be written in any computer programming language that compiles to the byte code for the Ethereum Virtual Machine. Solidity is one such language. It is a new language that has been designed to make it easy to express smart contracts, but it is not the only one being used to date — Go has been co-opted for smart contract development as well, and there are other languages under development.
Let’s go over some smart contract concepts. The term gets thrown around a lot, so it might be good to review where the idea came from, and see how Ethereum becomes a child of that invention. Looking into smart contracts will help us understand what Ethereum is doing with regards to consensus.
Once we have have a better idea about how consensus works with Ethereum, we might be able to entertain the ideas about how the contracts knit together communities on an Ethereum blockchain. We could use these smart contracts to manage how members of a community relate to each other. Since different versions of consensus alter incentives and agreements, we begin to wonder if smart contracts can change the flavor of consensus on top of Ethereum.
Can we just use Ethereum? Do we need to look elsewhere, or build something new? Perhaps we should explore the limits of smart contracts in making variations of blockchain offerings. Let’s start with a small part of smart contract history.
History of Smart Contracts
Introducing the Idea of Digital Signature
One paper talking about digital contracts and how they might be constructed is written by Ian Grigg in the year 2000. In the article, he introduces the Ricardian Contract.
From this discussion, Grigg derived this definition of a Ricardian contract:
“A Ricardian Contract can be defined as a single document that is a) a contract offered by an issuer to holders, b) for a valuable right held by holders, and managed by the issuer, c) easily readable by people (like a contract on paper), d) readable by programs (parsable like a database), e) digitally signed, f) carries the keys and server information, and g) allied with a unique and secure identifier.”
One section of the paper that stands out is its breakdown of governance, quoted here:
- Static Governance: persistence and availability of contract.
- Structural Governance: separation of concerns and ensuring that reliable parties are employed to carry out singular elements of the protocol.
- Dynamic Governance: real time auditing of the balance sheet and other key values.
Blockchain certainly seems to be a good fit for storing contracts and keeping track of changes.
But, before the Ricardian contract, the term Smart Contract was already defined by Nick Szabo in 1996.
The basic ideas were there. While Szabo was not thinking about virtual machines, his definition of the Smart Property did describe a processing unit of sorts:
"Smart property is software or physical devices with the desired characteristics of ownership embedded into them; for example devices that can be rendered of far less value to parties who lack possession of a key, as demonstrated via a zero knowledge interactive proof."
Ethereum assigns an instance of contract to an address. And, the address is the hash of the public RSA key (Ethereum style - slightly different than Bitcoin). So, that would be the first place that ownership is embedded into an Ethereum contract.
The Ethereum contract is in fact a piece of software, embedded on the Ethereum blockchain, where instances of it reside permanently, and therefore, Ethereum possesses static governance. The Ethereum Virtual Machine, EVM, runs programs that change the state of data governed by the contract. But, there is structural governance because nodes must reach consensus about the state of a contract instance. That is, the operation of miners is separate from the contracts and as long as miners play by the rules, they form a trustworthy group. As contracts go through state changes, the costs of execution are verified by the miner nodes. And, the state transition consensus ensures that values altered by the contract can be agreed upon resulting in a dynamic governance.
Checking on the State of the World
One way to avoid cheating in the execution of a distributed multi-player game is to require nodes to lockstep during state transitions. A certain amount asynchrony can be tolerated. But when a state transition happens, all nodes have to wait for each other and verify the taking of the step. This is proven out by Baughman and Levine here.
In a similar manner, as contracts are performed, the state of the world can be examined by a collection of nodes. Nodes can broadcast the state of the world to each other and wait until the state transition is verified. Not saying how the verification should take place, we can know that the contract state remains veridical if the nodes lockstep on these state transitions.
Of course, a great way to lockstep transitions is for nodes to come to consensus on the state by agreeing to store the record of the state on a blockchain.
This is the strategy used by Ethereum. Here's some pictographic interpretations of an Ethereum block.
Many Peer Verification
Bitcoin stores values on a ledger and these values reflect balances — if you will — of accounts.
Ethereum, on the other hand, stores the current state of machines implemented by programs (smart contracts) compiled to run on the Ethereum Virtual Machine. A node in the Ethereum blockchain works on coming to consensus on blocks, and each block contains validated state transitions of smart contracts.
Ethereum has employed the same kind of consensus as Bitcoin, PoW (Proof of Work). As Ethereum switches to PoS (Proof of Stake), it will not change much in its form of consensus when looked at in terms of partial asynchronicity and the use of the A2M wormhole. It is still a blockchain in a peer to peer network.
That is, Ethereum does consensus asynchronously.
But, it locksteps contract transitions. So, it executes contracts synchronously.
EVMs: The Bitcoin Version (Verification Code)
Ethereum is actually one of a growing number of blockchain offerings that can run smart contracts. In fact, Bitcoin has always had the ability to run very simple smart contracts. These are written in a very limited script language that is mostly used to instruct miners on how to verify transactions and distribute balances. Some of this script language can be found in any Bitcoin transaction.
Here is a link to the specification of this script language: Bitcoin Script
EVMs: The Ethereum Version
There is a lot to the Ethereum Virtual Machine, and we'll go over some concepts. More details about Ethereum can be found in the Yellow Paper.
Limited Turing Computability (The Price of Gas)
The Ethereum Virtual Machine is Turing computable. That means you can write any program in it.
Ethereum can be used to implement anything, except that it might run out of gas.
Every time a smart contract instance makes a state transition, it uses up some resources. Ethereum has devised a way to charge for this resource consumption. Some amount of gas is taken out of the contract execution fee. Gas costs ether, and each contract is allotted some gas before it runs. When the contract makes enough state transitions that all the gas is used up, the contract stops. If the contract has not completed its task, its work is rolled back. Otherwise, the contract is finalized.
Limited Turing computability eliminates some problems.
The reason for using gas is to limit the Turing computability. The contract cannot run in an infinite loop as a result. That is the biggest problem taken care of by the gas limit. Other problems related to resource consumption are also taken care of by the gas limit.
Where and When Contracts Run
The code for the smart contract is stored as well. Each node runs the EVM, so the programming details between state transitions are run on all the nodes in Ethereum's blockchain network. When the smart contract code reaches a point that it sends a message, the program will emit a message to the network. And then, the contract will have to wait for the next round of verification until it runs again.
These are some points to keep in mind:
-
Contracts run on all the peers.
-
Messages causing state transition are replicated at each verification copy.
-
Contracts run between state transitions (up to and including a state transition) and then continue after state transition consensus.
Contract World v.s. Miner World
Let's keep in mind that the smart contract does not run on a hardware machine but on a virtual machine. The miner's node, a real machine, likely sporting a fine multicore GPU, runs mining code.
The mining code, the Ethereum client, might be written in C++ or Go. For instance, Geth is written in Go. The Ethereum client makes use of the OS resources. It opens files, uses memory, and does Internet communication.
No part of the Smart Contract runs a process in the OS of the miner node on its own. If a smart contract sends a message, it is actually asking the EVM to have the Ethereum client include it in messages that the Client sends to its peers. The peers, also Ethereum clients, unpack the network messages and then locate the transaction indicating the state transition that will move a particular contract instance forward. This is a common form of virtual machine sandboxing. But, the EVM is said to be isolated. Smart contracts can not access files in any way, and can only access their own contract data, which is stored within the blockchain.
Can Contracts Do Consensus Themselves?
You can write any program you want in a language that compiles to the bytecode of the Ethereum Virtual Machine, so, can you influence the Ethereum consensus process? Say you have a special use case in mind. Say you want to add voting to the Ethereum consensus process. What keeps you from doing that?
One Contract Can't Do It
This seems like the kind of thing you might want to do, to change Ethereum consensus with a short smart contract. But, your contract would have be able to call back into the client code. Or, there would have to be a call provided by the EVM that would tell the consensus module to use some data provided by the contract or to run some support routine that influences the outcome of the consensus problem solver.
But, the EVM doesn't have such calls.
So, given that the influence option is out, you might want to write a contract that is itself a consensus program.
Many Contract Instances
The first question to ask is how many smart contract virtual nodes you will need to run a consensus algorithm.
You know that you will need at least three, but really, there should be many. In fact, if the whole system is to be open, you should allow people to come in and make new contract instances so that they can mine. You can imagine that you will have to store tens of thousands of contract instances within the blockchain. Each smart contract that is its own node will be a rather substantial program. Take a look at any implementation of an Ethereum client in order to get an idea of what has to be written in Solidity. So, you are asking to store large blobs?
Keep in mind that there are many articles telling us that blockchains are not suitable for storing large blobs.
Just How Impractical is This?
-
Gas: Well, you don't want your system to stop running. You will need an unlimited supply of gas, and that costs lots of money.
-
Time: Each smart contract will do need to do a state transition on the EVM everytime it wants to do a state transition of its own. Then, it will wait for a state transition at the EVM level to be validated before it can move on to examine its own set of state transitions that it is validating. So, imagine that the peer-to-peer conversation carried out for consensus will take some number of state transitions at the EVM level to validate any one state transition on the smart contract level.
-
Nodes upon Nodes: To top that off, the smart contract will have to store its own ledger within the blockchain. Again, this is a blob.
So, you get the picture.
Writing a consensus system in smart contract languages and running them on an EVM is a bad idea.
Plug and Play Consensus
A better idea would be to change the Ethereum Consensus algorithm and launch a new version of it. Do a fork, as they say.
Then, you could battle it out with one of the new, quickly written pile of code that implements a client. Not a bad idea if you have time and money to go that route. Of course, obtaining the source code won't cost you money, because it is open source.
The code for Geth can be found here: geth.
And, the C++ client can be found here: cpp-ethereum
What Consensus Change Means to a Ledger
Of course, if you go through all the work to change Ethereum to your needs, you really have to start a whole new blockchain.
If you used something like Ethereum, you have to start with your own genesis block. Then, you have to build up the economically busy community that uses your blockchain. Be careful, however, because the S.E.C. is already starting to crackdown on things that look like their own currency.
Ethereum is currently undergoing consensus revisions because it is changing its consensus algorithm. As such, it will undergo a hard fork. Here is one of many discussions about the hard fork to come: Ethereum Hard Fork
A system with a firmly chosen consensus system cannot just play around with it. Each change in the algorithm means a giant change in its economy and the world of its users.
If you have imagined your own consensus, it might do well to think long and hard about how to use your system. It might also be good to investigate other blockchain implementations that may prove to be more helpful to you.
Modular Consensus Systems
If you look at Paxos, you can see that it is a family of algorithms. There helpful for studying, but if you're experimenting, how do you try each one?
Remember that fooling around with the code for consensus algorithms can be difficult. If there is one well established family of algorithms floating around, how can you even begin to think of picking a single one for your own blockchain using your own consensus algorithm?
Finding a codebase that allows you to plug and play consensus algorithms would be nice. That is becoming a reality, and in some sense, it is already real. The following sections serve to introduce a few systems with modular consensus.
Fabric
This Hyperledger project is a project supported by the Linux Foundation. Fabric is a blockchain implementation that has a modular architecture. More about Fabric here.
You can also read more in this discussion of Fabric's architecture. Within its architecture, there is a "consensus layer". You can get a description of plugable consensus here.
Parity
Parity has made an implementation of Ethereum. The hook into their plugin consensus can be found here: Pluggable-Consensus
Proposed Modularity for Ethereum
In the Ethereum White paper, on the Ethereum wiki, there is a suggestion of making some parts of it modular. This is only brief though. Time will tell if Ethereum will provide a codebase that allows for modularity in consensus. You can read about it in the Future Ethereum white paper.
Conclusion
As you can see there is a long path to getting to a place where you can create a veridical consensus system. To start off, you have to get your algorithm right. And, we have seen that it took about three decades to get to Bitcoin from the invention of merkle trees. But, since Bitcoin, there have been many approaches to consensus that have made use of the confluence of distributed systems and cryptocurrency.
In some sense, security is a function of decentralization. Consensus is a form of voting for a selected peer, one who is selected by the consensus algorithm. In order to rearchitect consensus for your own needs, the blockchain peer can be altered. Systems with modular consensus algorithms will provide a facile approach to tailoring consensus.
