1

EOS - An Introduction
Ian Grigg

Abstract—Current technologies for blockchain fall short of blockchain trade infrastructure. First, we summarise the Con-
providing what developers and end-users need in order to text of today’s market for DLTs. Then, we look at a Vision of
contract together and to build large scale businesses. We propose the end-user’s needs, and how to meet them. Then, we review
EOS, a performance-based and self-governing blockchain that an Architecture to meet the market demands.
provides an operating system for building large-scale consumer- Finally a quick Comparison with known systems and Con-
facing distributed applications. This paper outlines the context,
cluding remarks. For more technical details on the EOS.IO
vision and software architecture underlying EOS, which we are
building to serve a broad and diverse group of users with smart software, readers are referred to “EOS.IO Technical White
business. Paper” (Larimer 2017).
Keywords—EOS, blockchain, smart contract.
II. C ONTEXT
The Market. The market is competitive for all products and
I. I NTRODUCTION DLTs or blockchains are no exception. What are the market
offerings? Bitcoin might be seen as the chain of security, yet
The notions of digital cash and smart contracting have been a strong chain is only as valuable as the business it is attached
known for a long time, yet only in recent times have strides to. Perhaps recognising this, Ethereum touted the worldwide
been taken with respect to implementation. unstoppable Turing computer, a goal that might appeal to
This paper introduces the EOS.IO software underlying EOS computer scientists but has seemed elusive to other disciplines.
as a new platform for general value and contracting. EOS R3 built Corda to serve the needs of the financial institution,
is presented against a backdrop of three existing champions which is a large market but also an expensive and exclusive
because (a) they represent a broad range of opinions as to the one.
Distributed Ledger Technologies (DLT) space, (b) are large This section examines those prior systems from the per-
enough to matter, and (c) are familiar to the author. spective of major architectural features or necessities, which
Bitcoin (Nakamoto 2008) seemed to be the word on a suggests benchmarks or assumed starting points that industry
blockchain that promised the inspirations of both digital cash looks to.
and smart contracts. Although it captured the attention of the Consensus. With blockchains, we come to consensus over
cypherpunks, media and hodlers, it failed to make a mark on a block of transactions, such that no transaction conflicts with
business. Ethereum (Woods 2014) attempted to fulfill the smart any other, neither in this block nor prior blocks. Also known as
contract promise with an “unstoppable world computer” while the Two Generals Problem, there is a rich history in bringing
Bitshares (Larimer et al 2014) strove to open up the market for remote actors to agreement such that “I know that what you
tradeable assets. Hundreds of alternative Bitcoin blockchains see is what I see.” See Figure 1.
or altcoins strove to make a small difference seem louder. Bitcoin established proof of work or the Nakamoto signature
Corda (Brown et al 2016) backed away from blockchain as the way to bring an open entry community together over a
entirely and explored party to party workflow solutions. shared or distributed ledger in which all parties hold a complete
We are tantalisingly close but no prize has yet been awarded copy. This mechanism runs a lottery amongst many miners to
- by the end-users. It is timely to then take a fresh look at what determine who mines each block. Tickets in the lottery are
the demand is for, from their perspective, and lay down the competed for by a SHA2 puzzle, and as this requires energy
basis and a vision towards creating a practical and performant to produce, the winner of the lottery is rewarded with a fixed
amount of Bitcoin. In effect, anyone can be a General, and
Ian Grigg is a financial cryptographer and partner at block.one. iang the one that wins the lottery is the one that sets this moment’s
at block.one (see http://iang.org/). This work is licensed under Creative
Commons Attribution 4.0 International License (CC BY). Caveats: plan of battle. Following Generals can choose to accept that
(i) This paper is primarily about the EOS.IO software that permits a plan or block, or reject if invalid.
community to stand up an EOS blockchain. As the software is open source The fully shared ledger and the cost of proof of work,
and a community is free of any controls beyond their own Constitution, this running at 4% for Bitcoin and 11% for Ethereum at the time of
paper may be indicative but cannot be authoritative on any particular EOS this paper’s writing, have offended many. Permissioned ledgers
blockchain that a community might wish to stand up.
(ii) I have endeavoured to make this paper as independent as possible, (Swanson 2015) were proposed to not only block those we
but biases are ever-present and are what make life special. For the record, want to exclude from enjoying the benefits of our ledger, but
confidential information known to the author has been excluded, and would also to bring us back to the computer science roots of efficient
likely change some criticisms if included, for better or worse. consensus - practical but centralised designs well known in
(iii) This present version is a DRAFT for which I solicit broad feedback!
Nothing written herein is especially fixed for the EOS.IO software, and database science. Also proposed from time to time are proof of
changes are to be expected. stake, exotic cryptography and secure enclaves. Corda (Brown
et al 2016) established that consensus could be a user choice
EOS - An Introduction 05 July 2017 - v0.4 - DRAFT

on the precise exit state resulting from all contracts found in

each new block.
Contracts. Bitcoin added business logic to money by at-
taching validation ‘scripts’ to its transactions to suggest a
limited form of contracting, which popularly became known as
smart contracts (Szabo 1994, 1997). Ethereum’s notion of the
unstoppable worldwide Turing computer provided more fully
powerful coding, messaging and data storage. Corda pared
back these designs to validate and agree over UTXO-like state
with command-driven changes, but also limit access to only
the direct parties for confidentiality. Both Ethereum and Corda
introduced more powerful high-level languages with which to
express contracts.
Fig. 1. The ”Two Generals” Problem is fundamental in Computer Science Performance. Bitcoin has established a general limit of
about 3 transactions per second (TPS), at which point transac-
tions can be severely delayed. Ethereum seems to be stretched
at select points within a contract of transactions. By allowing at 15 TPS, and a recent congestion event was marked by a
interchangeability of servers called notaries that can mediate $2000 transaction fee to jump the queue. The limits on a
the consensus by any of the above means, Corda reduces the blockchain’s throughput are many: validating prior claimed
network operating cost to a level comparable to today’s IT blocks, processing the new block, and mining. Corda avoids
infrastructure. these limits for the most part, as its consensus is via selectable,
Value. Similarly, there are a wide variety of mechanisms to independent and localised notaries, as there is no need for
establish a fungible value such as cash. Smartcard money in the wider consensus than the parties. Every system is encumbered
1980s - 1990s was typically implemented through persistent by the physical limits of network propagation times.
internal data stores in each card that negotiated atomic dual- Use Cases. Notwithstanding the hype surrounding block-
card transactions. In the same timeframe, David Chaum’s chain, there is relatively little hard evidence of successful use
eCash (Chaum 1983) popularised the notion of a coin, being a cases. Bitcoin establishes a single currency, but the explosion
random number with a blinded signature that could be handed of altcoins, the failure of colored coins, and the absence of
from user to user. Triple entry (Grigg 2005) established that any smart contracts of interest suggest clear limits. Ethereum
each party could see the same receipt, each of which recorded tried to break those limits but to date success eludes, unless
a person to person transaction. Balance is calculated as the one considers the somewhat circular use case of raising funds
sum of receipts going in and out. on the promise of future use cases, as marked by steady traffic
Bitcoin uses the UTXO or unspent transaction output con- in ERC-20 contracts. Perhaps surprisingly, the progenitors
cept, a state-driven layout. Each transaction record spends a of EOS number are two ‘interesting’ use cases that have
set of previously unspent values, and creates new spendable reached production and scale, being a distributed exchange
values into the future. In contrast, Ethereum’s virtual machine (Bitshares) and a social media site (Steem). The promise of
provided a database mechanism such that a currency could smart contracts, however, remains elusive.
be constructed from a table, a significant improvement in Governance. To this author, the critical discovery of Bitcoin
flexibility, but opening up a wide surface area for attacks. is not that we can mediate with cryptography, or that the
These five distinct mechanisms suggest that the way to design is stable with decentralisation and open entry, but that
account for value is not settled science. it must preserve these characteristics to survive. Entry by
State Transition. Bitcoin’s block as a list of UTXOs, above, all is not only key to the consensus model of hash-mining
lays a claim to state, being the nature of those coins, that over the distributed ledger, it is also key to the survivability
block, that chain, at that time. The duality of the UTXO design of the system. Previous digital cash systems failed because
derives from the need of the lightweight or ‘SPV’ client to there was a centre, which was attacked in one way or another,
prove its incoming coins in a shared ledger: A receiving client showing a failure in governance. As if to provide further
with only limited access need only trace each single ‘coin’ abundant evidence, centralised exchanges in the Bitcoin era
from a block position back to its origin in order to determine are frequently attacked with thefts, contract breaches, denials
that an incoming transaction is good. The receiver does not of service, bankruptcies, seizures and enforced rule changes.
need to prove anything outside of the incoming coins, such as Then, the world divides generally into two: fully decen-
the sender’s balance, in order to ensure complete control of tralised open entry systems typified by blockchains, and the
the value. converse typified by centralised and permissioned ledgers, with
This powerful statement that the blockchain is a graph the space between the two being uncertain. Bifurcation over
of state was adopted broadly within the distributed ledger open entry raises the question of how the users govern, are
field. Even as Ethereum replaced the UTXO with its more governed, and how governance for the benefit works - in both
powerful virtual machine, it accepted that state was the point cases.
of consensus over which all nodes need to reach. On arrival of The general approach in open entry starts with caveat
a new hashed block, each validating node calculates and agrees emptor, which carefully sets a technical environment that is

Page 2
EOS - An Introduction 05 July 2017 - v0.4 - DRAFT

capable of most of what is required, but with enforcement of contracting and money has been excluded to the wider Internet.
rights limited by what can be automated in code. Sometimes Bitcoin is too unsafe, and its smart contracts opaque. Ethereum
labelled trustlessness, this regime draws a stark line between is too scary, too hard, too geeky. Corda is ‘big corporate.’ Other
that which is technical and strong as a chain, and that which systems have their weaknesses, all of them are restricted to the
is at the user’s discretion and therefore more dangerous. As elite coder, and everyone has a different view.
time goes on, institutional approaches such as improvement What is needed is smart business for the everyday person.
proposals and centres of power such as foundations or teams An everyday distributed application needs to live in a global
arise to deal with some of the dangers to users, to a greater blockchain that handles the open entry treasured by the Bitcoin
or lesser degree and success (Gupta 2014). Caveat emptor is discovery, has enough performance to build big business, is
typical of Bitcoin and Ethereum. connected enough to bring people together and is safe and
In contrast, in the permissioned network or walled garden secure enough that Wall Street’s Gordon Gecko can trade
approach, only those permitted can enter and act. In this alongside Africa’s Mama Biashara. Without drama, without
scenario, parties open an account, are onboarded by an agent fear, without missing out.
and can trade with a presumption of good behaviour. Implicitly The Target. The vision before us is a single global con-
or explicitly, enforcement of good behaviour is typically seen tracting blockchain that can scale up to handle a long-tail of
as out of scope at the technical level, although dentity typically businesses negotiating contracts for mutual advantage in a safe
plays an unclear part. The downside is that the wall around and secure environment.
the garden can be expensive to erect and maintain, and every In more practical terms, while there is much of value on the
year the gatekeeper charges more. This approach is commonly Internet, we focus on what is mediated by the web, and leave
assumed within heavily regulated markets such as banks and aside mobile and applications for now. What does a builder
the like, and is used by Corda. of a web application want? We assume that the target user is
Neither of these world states are user friendly - users lose the web entrepreneur, and therefore let’s work backwards from
too much money through caveat emptor, and systems that start that position.
from ‘permission’ become systems that discriminate, either at Principal Features. Our design predicts a blockchain to
the competitive level or the societal level. Users are routinely handle thousands of transactions per second for business
skeptical of either. contracts that are captured in easy to use and easy to secure
languages. The major features include:
III. V ISION • High performance messaging using event sourcing
End-state Goals. What is it that our user needs? In the • Delegated Proof of Stake
abstract, she wants to: • Contracts as negotiation and intent - messaging at its
heart
• Know her friends, business partners, and customers. • Usability from the user to contract writer to developer
• Communicate with them. to entrepreneur
• Be able to contract with them: • Governance for business and chain maintenance
◦ in the small, make peer to peer agreements, and The following section explores in more depth.
◦ in the large, build a sophisticated business to be
able to serve the market.
IV. T HE A RCHITECTURE
• Be able to retain and direct her value (pay bills, etc) as
a necessary component of business. The Philosophy. In large part the practical approach of the
◦ Then, all has to be done safely and securely. software underlying EOS is to extend the large-scale high-
performance blockchain experience in Bitshares and Steem
• Be able to invest in a predictable business. This is a to support end-user business. Most of the elements have
complex issue, but appears to require three components. been proven to a lesser or greater extent, this architecture
◦ Know that the ecosystem is advancing, and not at re-assembles them for a new purpose - to build distributed
undue risk of failing. applications.
◦ Pay for development effort up front with reason- This section describes some important architectural differ-
able payback in the future. ences that the software underlying EOS proposes against prior
◦ Because she knows that things - contracts, assets, practice. For more technical details, readers are referred to the
transactions, intents - go wrong, she wants to be EOS.IO Technical White Paper (Larimer 2017).
able to fix her difficulties. Including, with her The Message is the Medium. The EOS.IO software design
friends, her business, and her assets, and quickly, switches from the more popular consensus over state to the
cheaply and without undue escalation. less familiar consensus over events (Grigg, 2017-1). This
One caveat of arrogance: we assume her wants and her approach marries the event sourcing pattern (Fowler, 2005)
needs are synonymous. More precisely, we are making an to a blockchain made of events rather than state.
entrepreneurial judgement call over what we believe the user In computer science, a deterministic state machine is built
needs, and she’ll want it when she learns about it. as a machine of code, state (memory), and events, both in and
The Big Idea. It has become abundantly clear that for out. Every time something happens which causes a change,
one reason or another, the promise of universal peer to peer a practical machine saves intermediates to memory, and on

Page 3
EOS - An Introduction 05 July 2017 - v0.4 - DRAFT

Fig. 2. A Coke Machine expressed as a state machine

restarting it recovers itself by reading back those intermediates.

In building a practical state machine, we have a choice between
saving events or saving state, which choice depends mostly on
what we are trying to optimise.
In Figure 2, are we to save the red messages or the blue
state? A machine saving state is more likely to be used in a
context where we focus on what state it is in now, for example
databases. A machine saving messages as intent is more likely
to be useful when asking how we got to the state we are in
now, for example protocols or legally significant logs such Fig. 3. Delegation allows replacement of Generals after a bad campaign
as triple entry accounting (Grigg 2005). Restart is faster with
saved state, throughput is faster with saved messages.
Because users need performance, the design saves messages.
DPOS avoids the tax of mining, releasing that substantial
Restart of a messaging or event sourced machine is similar
value back to stakeholders. Value from block rewards would be
to recovering from the beginning, therefore incredibly slow,
initially captured entirely by the producers. However, because
and optimising startup means saving checkpoints - back to
they are elected by the community, they are incentivised to
state again. But, and here is a crucial outcome, in saving that
share the rewards by a scheme that producers agree on amongst
state, an actor remains bound by the saved messages, not the
themselves, and promote to the community.
state, so we can optimise heavily and even recalculate the
checkpoints if needed. Precisely how we optimise is too big By constitution, the long term reward for producing blocks
a topic for this introduction, but suffice to predict that the can be limited to for example 5% per annum (Larimer 2017-2).
combined techniques can in theory take blockchain from 3 By custom, we suggest that the bulk of the value be returned to
transactions per second to 3 million. the community for the common good - software improvements,
Consensus. For consensus over messages, the EOS.IO dispute resolution, and the like can be entertained. In the spirit
architecture uses Delegated Proof of Stake (DPOS), a two-tier of ‘eating our own dogfood,’ the design envisages that the
governance structure proven in Steem and Bitshares (Larimer community votes on a set of open entry contracts that act
2014). In the first tier, block producers are elected into a round like ‘foundations’ for the benefit of the community. Known as
of 21, each producer gets one block per round, and is rewarded Community Benefit Contracts, the mechanism highlights the
for the validation of incoming messages and production of importance of DPOS as enabling direct on-chain governance
the block of messages. A block released by one producer is by the community (below).
validated by the next and the next and so forth; if not validated, The Contract. The architecture comes closer to the nature
it is not built upon. Similar longest-chain mechanics to Bitcoin of contracting by treating contracts as a dynamic expression
are followed, and in short order, the producers converge on of negotiation, commitment and events, rather than the more
a longest chain. A block that is accepted by a quorum of static interpretation of ‘the four corners of the page’ or the
producers is declared immutable, and the chain of immutable performing code within a machine. We propose that messages
blocks becomes in effect a checkpoint. are the natural element of contracting, as they better capture
Like proof of work, producers can censor (ignore) messages, all phases of successful contracting: negotiation, intent, perfor-
or they can front-run by introducing their own from their mance and breach of obligations are all events better captured
superior knowledge of the future. To provide light-touch gov- as messages than, say, state.
ernance over bad acts by producers, each round of producers A user writes a contract as a virtual construct of interlocking
is continuously elected by the community using proof of stake handlers of messages. A user can convert her account into
(PoS). As this second tier blockchain-mediated election is over a contracting agent by adding message handlers and using
the producers and not the blocks, the so-called “nothing at her account’s inbuilt database-like store to hold the internal
stake” weakness does not apply. position of her contracts. Several message handlers working
In effect, a set of Generals is chosen for a campaign, and together can mediate a flow of messages so as to perform
each get one turn. After the campaign, the civilian community a complete contract or legally sound agreement through its
asserts its view to replace any bad Generals. lifecycle.

Page 4
EOS - An Introduction 05 July 2017 - v0.4 - DRAFT

Fig. 5. Concepts in code automation and prose contracts will evolve (Clack1’s
Fig. 4. Tensions between stakeholders in a blockchain Figure 5)

• The parties need a contract that is, first of all, an

From the perspective of a contract, the arrival, acceptance
actual contract. Parties also want the contract to be
and processing of a message is a simpler abstraction than state.
negotiable, readable, clear, and unambiguous - they need
Consider an order processing book as seen in a market for
their human intent to be captured faithfully. Preferably,
exchange: the book accepts bids to buy and offers to sell. When
contracts should also be supported by options for dispute
the time comes, it has to calculate a price at which to cross,
resolution and enforceability.
and then issue accepted orders to both sides. • The developer needs the language and wider system to
An order book in a messaging-based system is committing be easy to learn and write in, as well as expressive and
to its set of incoming messages and outgoing set of messages, securable, goals that often ignore higher semantics or
which is a relatively tractable task. In contrast, in a fully state contractual intent.
based system, all traders have to negotiate the acceptable state • Meanwhile the operators of the blockchain - producers
to all of many parties, including quantities and prices, before of blocks and full-node app businesses - need the con-
submitting a final state to the blockchain. This implies that tract to be scaleable and provide a reasonable basis for
traders would get to peek at the solution before agreeing, earning some revenue, interests that have little to do with
opening the door to game-playing. In practice, the only known human intent or developer expressibility.
way to solve this problem is with agents and messaging.
Taking the parties’ needs first, this pushes us in the direction
An active agent receives committed messages, decides on the
of melding plaintext legal prose tightly with computer code,
outcome, and sends out messages committing to that outcome.
glued with some parameters to “drive the deal” and reuse
Usability. The direct user of a blockchain is the developer the prose and code over many contracts (Grigg 2015). Many
who creates web apps for her end-users. To support an end- research efforts aim to merge the two contract views of code
user, the software must support the developer, first and fore- and prose together as either higher order parameters or a
most, and it must do so in ways that help the developer to legally expressive domain specific language (Clack1 et al 2016
support her users. High impact support for the the developer see their Figure 5) but none have as yet found this holy grail.
includes (a) the tools, (b) the language, and (c) the environ- This is an open research area with unsettled design choices
ment. (Clack2 et al 2016).
In the large, the EOS.IO developer will be supported by a Along those lines, our first temptation was towards the
web-based toolkit that provides a fully-serviced framework on developer: a source-interpreted scripting language based on
which to build applications as distributed web-based systems Wren, and customised to manage the design of a contractual
coordinating over the blockchain. Accounts, naming, permis- message handler. Example code snippet (Larimer 2017-1):
sioning, recovery, database storage, scheduling, authentication
and inter-app asynchronous communication are all built in. apply:
A goal of the architecture is to provide a fully-provisioned // assuming all prior steps pass,
operating system for the builder of apps, focussed to the web // perform the state transition
because that’s where the bulk of the users are. // that updates balances and/or
Language. Within our context of industrial scale distributed // creates a new account for receiver
applications, the language for writing contracts is high on var from = Balance[message.from]
the impact list. Most every other architectural feature in var to = Balance.find( action.to )
the EOS.IO software has solid foundation that is proven in from.bal = from.bal - action.amount
Bitshares and Steem, whereas the addition of smart contracts to.bal = to.bal + action.amount
stands out as uncharted territory. This hybrid of Wren is simple to learn, read, and reason
It behoves us to analyse the language needs carefully. From about, making it ideal for automated contracting. However, it
the point of view of selecting technology for automated or proved to be slow: a trial of trivial transactions capped out at
smart contracting, the three stakeholders critical for success 1,000 TPS, which brings us into collision with the needs of
are: the parties, the developers and the operators. operators, our producers and application businesses.

Page 5
EOS - An Introduction 05 July 2017 - v0.4 - DRAFT

Fig. 6. Members forge a Community with a Constitution

Fig. 7. Community can appoint governors to manage responsibilities

As we are aiming for 100 times that level, the team switched only and read-write code, each having different potentials for
to WebAssembly (WASM) which is a new intermediate lan- optimisation. To eliminate re-entrant issues, outgoing messages
guage designed to do the job that Javascript currently does will be stacked until completion, or dropped on failure. We
within browsers. WASM’s first unoptimised trial within the intend to add a SQL-like table structure to significantly ease
EOS framework delivered about 50,000 TPS for a currency adoption by those who are familiar with databases. Crypto will
contract. be external and mostly invisible.
Yet, WASM switches the challenge from the operators to As with the entire space for DLT, the competition continues
the parties - there are now 3 tangible views over any contract: internally. Wren is small and tight. WASM is only just out of
legal prose, source code initially in C and intermediate code standardisation. WASM’s early tools target C and C++ which
in WASM. are popular but are more costly to write code in, in comparison
Thus it is a reasonable question to ask - what or where is to high level late-generation languages such as Wren. These
the contract that the parties agreed to? I would like to face that challenges should not be insurmountable in the longer run as
question head on. In the two decades or so that I have seen the WASM project is intended to work with most languages,
contracts issued on the net, as Ricardian or otherwise, and and the bulk of the code in any DApp is outside the handlers, in
the hundreds of issues that have arisen from these contracts, the websites. The ability to accept many popular languages is
I have yet to see a dispute, or even a confusion where what enticing, an advantage available to Corda’s JVM but not easily
the contract said or meant was key to the dispute. Even with reachable by Bitcoin or Ethereum without a holistic approach
The DAO, that ill-fated $150 million lesson in how not to to the developer cycle.
issue a contract, the proximate cause was (in) security, and In conclusion, there are dramatic compromises in the choice
regardless of which side of the fence one fell in identifying of language and toolkits for the developer that go beyond
the contractual significance of the hack, the response was to mere codability. We would like an easy to read and reason
arbitrarily change whatever needed to be changed to get the scripting language that could speak in full contractual terms,
money back. There was no organised, formal or even a vestige be securable and be scaleable. But at the current state of the
of an attempt to resolve the dispute over interpretation of art, compromises have to be made.
the facts, the meaning and the rights. It is an open question Governance. Let us now turn to the environment. It is a
what proportion of disputes in court are over meanings and reality that things go wrong with automated processing of
confusions, and what percentage are simply power plays and contracts, to the distress of all. It is our hope to reduce both
bullying, but I am not optimistic. the frequency and the cost of those errors, but they cannot be
In the face of The DAO and other experiences, I suggest eliminated entirely, and our approach is to build in remedial
that the rule of one contract (Grigg 2004) looks dogmatic methods for when they do occur.
and overly constricting. Instead, at least for the unregulated A blockchain based on EOS.IO software assumes that all
part of the DLT space, there is opportunity to free up the who use the blockchain are members under a short Constitution
components of the contract to achieve better performance, even (Larimer 2017-2) (Grigg 2017-3) and by agreeing to which,
at the expense of a little misalignment. Meanwhile, we should all members form a Community subject to the Constitution.
focus on governance, and making dispute resolution available The Constitution sets down some basic rules for the benefit
and comfortable to the parties. of the community. The Constitution empowers three arms of
As of the time of writing, the set of languages available governance: arbitration for resolving disputes, block producers
to the contract developer is a work in progress. Whether for choosing blocks, and referenda for community voice.
WASM or Wren or another, we will still need to structure the Arranged in an interlocking triangle of governance, these three
language for performance and usability. Each named message arms support and counterbalance each other. Referenda are
handler will need to identify sections for each of static, read- used by the community to vote in the producers and arbitrators,

Page 6
EOS - An Introduction 05 July 2017 - v0.4 - DRAFT

as well as changes to code and constitution. Arbitrators can of major stakeholders to recognise the need for governance.
deliver legally binding rulings to resolve disputes, and also As an emergent business proposition, use of Ethereum has
for extraordinary changes such as hard forks. Block producers been dominated by raising funds for projects mostly aimed at
are at technical liberty to censor bad transactions or introduce finishing Ethereum as a platform, or competing with it. Few
remedial ones - but are mindful of community reaction. Ar- novel use cases have made their mark, suggesting that there
bitrators publish rulings, which producers might enforce, or is more work to do before the Ethereum concept of smart
users might seek external enforcement. contracts bears fruit.
This counterbalanced arrangement ensures that no party Corda. The primary distinguishing factor of Corda is that
or group has total power. Even founders or developers have it is not a blockchain but a framework for party to party
only limited ability to affect the rights of the community workflow. Instead of posting contracts and actions to a block-
members. Hard forks and other upgrades have a defined path, chain, parties exchange messages and come to consensus via
and individual disputes are channelled to a place where we can notaries. It achieves confidentiality for parties, high perfor-
resolve and get back to business. A further benefit is that most mance unconstrained by chain coordination, and the ability
of the above governance can be handled transparently, that is for parties to control the contracts as they succeed and fail.
by writing contract handlers to accept and manage disputes, Yet workflow works best with small numbers of parties, not
handle referenda and the like. large, and hence it is weaker on issuance of assets, especially
To make these institutions work, users have to agree to the cash and cash-denominated trading. Another weakness is that
Constitution, which empowers the producers to choose blocks, Corda’s walled garden approach for regulatory business stops
and reserves all disputes into the forum of arbitration. As it being an attractive mass market for small players.
well, the Constitution creates the legal rights expressed in the
blockchain by stating that each member receives those rights VI. C ONCLUSION
properly accounted for, and in return each member supports User experience. The direct users of a blockchain such as
the accounted rights of others. This trade of your rights for the EOS are the entrepreneurs and developers who write contracts
rights of others becomes the cornerstone of the community, in to implement distributed applications or DApps. Their users are
that the community is defined by both the usage of the platform the routine customers in retail, finance, logistics, media. Those
and the agreement to the Constitution. latter customers do not need to know what a blockchain is.
And thus we have preserved open entry even as the Com- Hence the goal is to give the developers a platform that allows
munity governs itself internally. Even as a user transacts, extensive business logic to be built, but the mechanisms of
all transactions from the first entry to the latest refer to the communication are hidden.
Constitution by hash, as a Ricardian Contract (Grigg 2004). The DApp developer is given a fully capable accounts,
As an explicit governance mechanism, the constitution creates permissioning and messaging platform in which to express the
more of a fenced field than a walled garden, and the gatekeeper system. The user interface matches what users are familiar
is automated as a transaction or signpost at all points. with - a webkit for building websites and of course access to
the blockchain. This approach is expressed as “an operating
V. C OMPARISONS system for blockchain.”
Bitcoin. As the platform that launched the first and most The fact that there is a blockchain can be hidden from the
successful cryptocurrency, Bitcoin is a baseline. Yet, as the user, as exemplified by Steem, being just another blogging
‘first’ its flaws shine as bright as its success: The UTXO platform that happens to be distributed on a blockchain.
verification model means that complex smart business has Use cases. An EOS blockchain is intended for high-
to be mediated through external code. The state is nicely performance messaging with business logic. Popular use
locked on chain, but the hard work of negotiation is done cases will include supply chain, resource management, user-
by the applications. It has no good framework for assets, messaging such as social media, asset issuance and trading,
especially as each transaction includes BTC, and is thus an accounting for remittances, and gaming.
affront to Gresham’s apocryphal warning against commingling A typical use case might be Uber. Ride-sharing is based
of assets, good money drives out bad. Its lack of a thoughtful on setting standards of behaviour for the driver and for the
governance layer results that upgrades are very difficult, and passenger. If drivers and passengers were part of the same
the community is at war with itself. For example, the artificial community, there would be an immediate benefit - the base
limit of 3 TPS that kills its scalability is because of the absence of liability and standards of behaviour would be covered
of governance. under community constitution and dispute resolution, and their
Ethereum. To rectify Bitcoin’s weaknesses, Ethereum es- contracts could be bilateral rather than intermediated, thus
tablishes a Turing-complete virtual machine capability on a minimising any regulatory difficulties.
world-wide computer. It has several major shortfalls. Firstly, it Then, as the contracts can be bilateral, the business flow
has a dramatically restricting requirement to find consensus on could be split up: tracking passengers in the market, tracking
state over thousands of program executions, leading to resource cars available, finding a match, negotiating a contract, perfor-
congestion at around 15 TPS. Secondly, the decision to go-it- mance, settlement, pricing, and social tracking could all be
alone on languages, VMs, toolkits and the like has caused a built as separate DApps that interact.
drag on developer capabilities. Thirdly, it suffers from the ad- Community. To support business, we need to solve prob-
hocracy of the Foundation that has emerged despite the refusal lems. And to scale the solving of problems, it has to be done

Page 7
EOS - An Introduction 05 July 2017 - v0.4 - DRAFT

R EFERENCES
[1] Richard Brown, James Carlyle, Ian Grigg, Mike Hearn, “Corda: an
Introduction” 2016
[2] David Chaum, “Blind Signatures for Untraceable Payments”, 1982 UC
Santa Barbara
http://blog.koehntopp.de/uploads/Chaum.BlindSigForPayment.1982.PDF
[3] Christopher D. Clack (1), Vikram A. Bakshi, Lee Braine “Smart
Contract Templates: foundations, design landscape and research
directions”, 2016
[4] Christopher D. Clack (2), Vikram A. Bakshi, Lee Braine “Smart
Contract Templates: essential requirements and design options”, 2016
[5] Martin Fowler, “Event Sourcing”, 2005
https://martinfowler.com/eaaDev/EventSourcing.html
[6] Ian Grigg, “The Ricardian Contract,” 2004
[7] Ian Grigg, “Triple Entry Accounting,” 2005
[8] Ian Grigg, “The Sum of All Chains - Let’s Converge,” 2015
[9] Ian Grigg, blog post “The Message is the Medium,” 2017-1
[10] Ian Grigg, blog post “Seeking Consensus on Consensus,” 2017-2
[11] Ian Grigg, blog post “A Principled Approach to Blockchain
Governance” 2017-3
[12] Vinay Gupta, interview “Bitcoin Cannot be divorced from pre-existing
political theory,” 2014
[13] Daniel Larimer, “Delegated Proof-of-Stake (DPOS)” 2014.
[14] Daniel Larimer, Charles Hoskinson, Stan Larimer, “A Peer-to-Peer
Polymorphic Digital Asset Exchange” 2014.
Fig. 8. The point is Smart Business [15] Dan Larimer, “EOS.IO Technical White Paper” block.one 2017
https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md
[16] Dan Larimer, block post “Implementing a Hypothetical Currency
by the community itself, which means it has to be in the Application on EOS,” 2017-1
architecture. To advance community, we must preserve open https://steemit.com/eos/@eosio/implementing-a-hypothetical-currency-
entry, but on entry provide the tools that users find useful for application-on-eos
governance. Users want to determine their risks and obligations [17] Dan Larimer, blog post “What could a blockchain Constitution look
to their counterparties. like?” 2017-2
When bound together as a community under a Constitution, [18] Satoshi Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System ”
2008
users will know that the rights, liabilities and obligations of
[19] Tim Swanson, “Consensus-as-a-Service” 2015
their counterparties are at least to a basic standard, as expressed http://www.ofnumbers.com/wp-content/uploads/2015/04/Permissioned-
in a constitution and as enforced in dispute resolution. In distributed-ledgers.pdf
addition reliable names and a web of trust can reduce the [20] Nick Szabo, “Smart Contracts”, 1994
anonymity of the Internet and give people a sense of belonging [21] Nick Szabo, “Formalizing and Securing Relationships on Public
to something important. Networks”, 1997
[22] Gavin Woods, “Ethereum: A Secure Decentralised Generalised
ACKNOWLEDGMENT Transaction Ledger”, 2014

This paper received useful feedback from Brendan Blumer,

Arthur Doohan, Dan Larimer, Wendy Lee, Aaron Leibling,
Konstantinos Sgantzos, Joseph VaughnPerling, Kokuei Yuan.

Page 8