EOS Whitepaper

Saturday, March 6, 2021
Buy EOS coin
Save for later
Add to list
Whitepaper.io is a project of OpenBook

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