Aeternity Whitepaper

Thursday, May 3, 2018
Download document
Save for later
Add to list

Æternity blockchain The trustless, decentralized and purely functional oracle machine January 23, 2017 v0.1 Zackary Hess Yanislav Malahov Jack Pettersson [email protected] [email protected] [email protected] Abstract— Since the introduction of Ethereum in 2014 there III Applications 6 has been great interest in decentralized trustless applications III-A Blockchain essentials . . . . . . . . . 6 (smart contracts). Consequently, many have tried to implement III-A.1 Identities . . . . . . . . . . 6 applications with real world data on top of a blockchain. We believe that storing the application’s state and code on-chain is III-A.2 Wallet . . . . . . . . . . . 6 wrong for several reasons. III-A.3 Proof of existence . . . . . 6 We present a highly scalable blockchain architecture with a III-B State channel applications . . . . . . . 7 consensus mechanism which is also used to check the oracle. III-B.1 Toll API . . . . . . . . . . 7 This makes the oracle very efficient, because it avoids layering one consensus mechanism on top of another. State channels III-B.2 Insured crowdfunding . . . 7 are integrated to increase privacy and scalability. Tokens in III-B.3 Cross-chain atomic swaps . 7 channels can be transferred using purely functional smart III-B.4 Stable value assets and contracts that can access oracle answers. By not storing contract portfolio replication . . . . 7 code or state on-chain, we are able to make smart contracts III-B.5 Event contracts . . . . . . 7 easier to analyze and faster to process, with no substantial loss in de facto functionality. III-B.6 Prediction markets . . . . . 7 Applications like markets for synthetic assets and prediction III-B.7 Market with batch trading markets can be efficiently implemented at global scale. Several at a single price . . . . . . 7 parts have proof-of-concept implementations in Erlang. Devel- opment tools and application essentials such as a wallet, naming IV Implementation 8 and identity system will also be provided. IV-A Virtual machine and contract language 8 C ONTENTS IV-B Adoption via web-integration . . . . . 8 IV-C Open source modules . . . . . . . . . 8 I Introduction 1 IV-D Usability and UX design . . . . . . . 8 I-A Previous Work . . . . . . . . . . . . . 2 V Discussion 8 II Æternity blockchain 2 V-A Limitations and tradeoffs . . . . . . . 9 II-A Tokens, accounts and blocks . . . . . 2 V-A.1 On-chain state . . . . . . . 9 II-A.1 Access token, Aeon . . . . 2 V-A.2 Free option problem . . . . 9 II-A.2 Accounts . . . . . . . . . . 2 V-A.3 Liquidity loss and state II-A.3 Name system . . . . . . . 3 channel topologies . . . . . 9 II-A.4 Block contents . . . . . . . 3 V-B Future work . . . . . . . . . . . . . . 9 II-B State channels . . . . . . . . . . . . . 3 V-B.1 Functional contract language 9 II-B.1 Smart contracts . . . . . . 3 V-B.2 Multi-party channels . . . . 9 II-B.2 Example . . . . . . . . . . 4 II-C Consensus mechanism . . . . . . . . . 5 I. I NTRODUCTION II-C.1 Oracles . . . . . . . . . . . 5 The intention of this paper is to give a overview of II-D Governance . . . . . . . . . . . . . . 5 the Æternity blockchain architecture and possible applica- II-E Scalability . . . . . . . . . . . . . . . 6 tions. More detailed papers will be released in the future, II-E.1 Sharding trees . . . . . . . 6 specifically for the consensus and governance mechanisms. II-E.2 Light clients . . . . . . . . 6 However, it should be noted that our architecture is holistic; II-E.3 State channels and paral- all components tie together and synergize, in a modular way. lelism . . . . . . . . . . . . 6 The rest of this paper is broken into four parts. First, we II-E.4 Transactions per second at will introduce and discuss the fundamental theoretical ideas a given memory requirement 6 that inform our architecture. Second, we will discuss the 1

included essential applications, other possible use cases and become independent and can thus be processed in parallel. give intuitions for how to use the platform as a developer. Additionally, this means that contracts never write to shared Third, we will present the current proof-of-concept imple- state, greatly simplifying their testing and verification. We mentation, written in Erlang. We conclude with a discussion, believe that this design emphasizes that blockchains are including possible future directions and comparisons to other about financial logic rather than data storage; there exist technologies. decentralized storage solutions that complement blockchains perfectly. A. Previous Work Second, applications such as Augur have attempted to Blockchains, first of all Bitcoin, have shown a new way bring real-world data onto the blockchain in a decentral- to architect value exchange on the Internet [1]. This has ized way—in the process essentially building a consensus been followed by a number of promising advances: Ethereum mechanism inside smart contracts [8], instead of utilizing demonstrated a way to write Turing-complete smart con- the consensus mechanism of the underlying blockchain. This tracts secured by a blockchain architecture [2]; Truthcoin leads to inefficiencies but doesn’t increase security. The created tools for making oracles on blockchains [3], while natural conclusion from this is to generalize the blockchain’s GroupGnosis and Augur showed how to make them more consensus mechanism so that it can provide information efficient [4]; Casey Detrio showed how to make markets not only on the next internal state, but also on the state on blockchains [5]; Namecoin showed how to make the of the external world. It could thus be argued that the distributed equivalent of a domain name server [6]; Factom blockchain’s consensus mechanism determines the result of showed how a blockchain that stores hashes can be used as running what complexity theory dubs an oracle machine: a proof of existence for any digital data [7]. a theoretical machine that is more powerful than a Turing These technologies show great promise when it comes to machine because it has answers to some questions that can’t providing first-class financial and legal services to anyone. necessarily be computed, such as “Who won football game So far however, they have failed to come together to a X?” [need cit.] . unified whole that actually fulfills the promise. Specifically, Third, it seems natural that the consensus mechanism all solutions so far have been lacking in at least one of the could also be used to determine the parameters of the system. following respects: governance, scalability, scripting safety This allows it to adapt to changing external conditions, as and cheap access to real-world data [need cit.] . Æternity aims well as adopting new research and recent developments in to improve the state of the art in all of these respects. the field. The rest of this section introduces the Æternity blockchain II. Æ TERNITY BLOCKCHAIN in greater detail, starting with a brief overview of accounts, We believe that the lack of scalability, scripting safety tokens, names and the structure of blocks. This is followed by and cheap access to real-world data of current “smart con- an explanation of our approach to state channels and smart tract platforms” come down to three core issues. First, the contracts, and then a discussion on how the blockchain’s currently prevailing stateful design makes smart contracts consensus mechanism can be used both to create an efficient written for the platform hard to analyze1 , and statefulness oracle mechanism and to govern the system. Finally, we combined with sequential transaction ordering complicates discuss scalability from several different angles. scalability [need cit.] . Second, the high cost of bringing real- world data into the system in a decentralized, trustless and A. Tokens, accounts and blocks reliable way complicates or outright prevents the realization Despite being “stateless” from the contract developer’s of many promising applications [need cit.] . Third, the platforms point of view, the Æternity blockchain keeps track of several are limited in their abilities to update themselves, in order predefined state components. We will now explain these, as to adapt to new technological or economical knowledge. We well as the content of each block. For simplicity, this section believe that each of these three problems have clear solution assumes that every node keeps track of the whole blockchain. paths that should be explored. Possible optimizations are described in section II-E. First, recent research into state channel technology sug- A.1) Access token, Aeon: To use the blockchain is not gests that for many use cases, keeping state on-chain is not free, but requires that the user spends a token called aeon. necessary [need cit.] . It is very often entirely possible to store Aeon are used as payment for any resources one consumes all information in state channels, and only use the blockchain on the platform, as well as the basis for financial applications to settle any economic results of the information exchange, implemented on the platform. and as a fallback in the case of dispute. This suggests The distribution of aeon in the genesis block will be an alternative approach to blockchain architecture in which determined by a smart contract hosted on Ethereum. Further Turing-complete smart contracts exist in state channels but aeon will be created via mining. not on-chain. This increases scalability since all transactions All system fees get paid with aeon, all smart contracts settle in aeon. 1 The difficulty of analyzing stateful contracts was very clearly demon- A.2) Accounts: Each account has an address and a bal- strated by the re-entrance bug that brought down “The DAO”. This happened despite the code having been audited by several of Ethereum’s creators as ance of aeon and also a nonce which increases with every well as the general community [need cit.] . transaction and the height of its last update. Each account 2

also has to pay a small fee for the amount of time it is 1 macro Gold f870e8f615b386aad5b953fe089 ; open. The costs of creating and keeping accounts prevents 2 spam and disincentivizes state-bloat. The reward for deleting 3 Gold oracle accounts incentivizes the reclaiming of space. 4 if 0 1000 else 0 0 end 5 0 A.3) Name system: Many blockchain systems suffer from unreadable addresses for their users. In the vein of Aaron Fig. 1. A simple contract encoding a bet on the price of gold. The language Swartz’ work and Namecoin, Æternity features a name used is the Forth-like Chalang, which will be presented in section IV-A. system that is both decentralized and secure, while still supporting human-friendly names [9]. The blockchain’s state includes a mapping from unique human-friendly strings to fit that any transactions related to channels can be processed fixed-size byte arrays. These names can be used to point to in parallel, greatly improving transaction throughput. things such as account addresses on Æternity, or hashes e.g. The blockchain is only used to settle the final outcome of Merkle trees. or to resolve conflicts that arise, roughly analogous to the A.4) Block contents: Each block contains the following judicial system. However, because the blockchain’s behavior components: will be predictable, there is no gain in disputing the intended • The hash of the previous block. result of a state channel; malicious actors are incentivized • A Merkle tree of transactions. to behave correctly and only settle the final state on the • A Merkle tree of accounts. blockchain. All taken together, this increases transaction • A Merkle tree of names. speed and volume by several orders of magnitude, as well • A Merkle tree of open channels. as privacy. • A Merkle tree of oracles which haven’t answered their B.1) Smart contracts: Despite that the only state that respective questions. can be settled on-chain is a transfer of aeon, Æternity • A Merkle tree of oracle answers. still features a Turing-complete virtual machine that can • A Merkle tree of Merkle proofs. run “smart contracts”. Contracts on Æternity are strictly • The current entropy in the random number generator. agreements that distribute funds according to some rules, The hash of the previous block is required to maintain an which stands in stark contrast to the entity-like contracts of ordering of the blockchain. The transaction tree contains all e.g. Ethereum. Two of the more notable practical differences transactions that are included in the current block. With the is that by default, only the involved parties know about exception of the consensus vote tree, all the trees are fully a given contract, and only parties that have an open state under consensus: if a tree is changed from one block to the channel can create a valid contract. If the parties agree to a next, this change has to be due to a transaction in the new contract, they sign it and keep copies for future reference. block’s transaction tree, and a Merkle proof of the update It is only submitted to the blockchain if its outcome is has to be included in the block’s proof tree. The purpose of disputed, in which case the code is only ever stored as part the three remaining trees will hopefully become clear in the of the submitted transaction, never in any other state. If this following sections. happens, the blockchain distributes the tokens according to the contract and closes the channel. B. State channels As an example, fig. 1 shows a very simple contract that One of the most interesting developments in the encodes a bet on the price of gold at a certain time. On line 1, blockchain space lately is that of state channels. They operate the macro Gold saves the identifier of the oracle in question, on the basic principle that in most cases, only the people which will return true if the price of gold is below $38/g on affected by a transaction need to know about it. In essence, December 1st, 2016. The body of the contract is displayed the transacting parties instantiate some state on a blockchain, on lines 2-4: we first push the gold oracle’s identifier to e.g. an Ethereum contract or a Bitcoin multisig. They then the stack and call it using oracle, which will leave the simply send signed updates to this state between each other. oracle’s answer on the top of the stack. We use this to do a The key point is that either one of them could use these conditional branching: if the oracle returns true, we push to update the state on the blockchain, but in most cases, 0 and 1000 to the stack, indicating that 0 aeon should be they don’t. This allows for transactions to be conducted burned and 1000 aeon should go to the first participant in as fast as information can be transmitted and processed the channel. Otherwise, we push 0 and 0, with the second 0 by the parties, instead of them having to wait until the indicating that the other participant receives all aeon in the transaction has been validated—and potentially finalized— channel. Finally we push 0, which is taken to be the nonce by the blockchain’s consensus mechanism. of this channel state. In actual usage, the nonce would be On Æternity, the only state update that can be settled on generated at deployment. the blockchain is a transfer of aeon, and the only aeon that One important thing to note is that contracts on Æternity can be transferred are the ones that the transacting parties don’t maintain any state of their own. Any state is maintained already deposited into the channel. This makes all channels by the transacting parties and submitted as input at execution. independent from each other, which has the immediate bene- Every contract is essentially a pure function that takes some 3

1 : hashlock 1 macro Commitment a9d7e8023f80ac8928334 ; 2 swap 2 3 hash 3 Commitment hashlock call 4 == ; 4 if State33 else State32 end 5 call Fig. 2. A simple hashlock. Fig. 4. A simplified example of using the hashlock to play a multi-player game in channels. 1 macro Commitment a9d7e8023f80ac8928334 ; 2 3 Commitment hashlock call 4 if 0 100 else 0 50 end defined by the function State32, and we want to trustlessly 5 1 simultaneously update all the channels to state 33. When the game manager reveals the secret, it causes all the channels Fig. 3. Using the hashlock to trustlessly send tokens through a middleman. to update at the same time. b) Metered execution: Contract execution is metered in a way similar to Ethereum’s “gas”, but Æternity uses two input and gives a new channel state as output2 . The benefits different resources for its metering, one for time and one for of using pure functions in software development in general, space. Both of these are paid for using aeon by the party and in the development of financial applications in particular, that requests the execution. has been extensively documented in academia and industry This could be seen as undesirable, because it is probably for decades [10][need cit.] . another party that is causing the need for the blockchain to a) Contract interaction and multi-step contracts: resolve the dispute in the first place. However, as long as Even though all contracts are stateless and execute inde- all money in the channel is not used for betting, this can pendently of each other, contract interaction and statefulness be effectively nullified in the contract code, since it has the can still be achieved through hashlocking [need cit.] . A simple ability to redistribute funds from one party to the other. It hashlock is shown in fig. 2. On line 1, we define a function is in fact generally good practice to avoid using all funds called hashlock that expects the stack to contain a hash in a channel to transact, because it disincentivizes the losing h and a secret s. It swaps them on line 2, in order to hash party to cooperate when closing the channel. the secret on line 3, before calling the equality operator on B.2) Example: Let’s bring all of these ideas down to hash(v) and h on line 4. This returns true if the secret is a earth. In practice, if Alice and Bob want to transact using preimage of the hash. This function can be used to predicate a state channel on Æternity, they go through the following the execution of code branches in different contracts on the procedure: existence of the same secret value. 1) Alice and Bob sign a transaction that specifies how As a simple example usage, hashlocks make it possible for much money each of them is depositing into the users that don’t share a state channel to trustlessly send each channel, and publish it to the blockchain. other aeon, as long as there is a path of channels between 2) Once the blockchain has opened the channel, they can them. For example, if Alice and Bob have a channel and both create new channel states, send them between Bob and Carol have a channel, then Alice and Carol can each other and sign them. Channel states can be either transact through Bob. They do this by creating two copies a new distribution of the funds in the channel or a of the contract shown in fig. 3, one for each channel. The contract that determines a new distribution. Each of Commitment on line 1 is the hash of a secret that Alice these channel states has an increasing nonce and are chooses. On line 3 we push it to the stack and call the signed by both parties, so if a dispute arises, the latest hashlock function. Which branch of the if that gets valid state can be submitted to the blockchain, which executed depends on the return value of hashlock. Once enforces it. these contracts have been signed by all parties, Alice reveals 3) The channel can be closed in two different ways: the secret, allowing Bob and Carol to use it to claim their a) If Alice and Bob decide that they have finished aeon. transacting and agree on their final balances, Hashlocking can also be used to e.g. play multi-player they both sign a transaction indicating this and games in the channels, as shown in fig. 4. Everyone makes submit it to the blockchain, which will close the a channel with the game manager, which publishes the same channel and redistribute the money in the channel contract to every channel. Say we are in game state 32, accordingly. 2 It should be noted that since contracts can read answers from oracles b) If Alice refuses to sign a closing transaction for and some environment parameters, they aren’t completely pure functions. any reason, Bob can submit the last state that both However, oracle answers never change once they’ve been provided and of them signed and request to have the channel can be argued to be due to the computational richness of the oracle closed using this state. This starts a countdown. machine, rather than being an impurity. Environment parameters are deemed a “necessary evil” and will ideally be compartmentalized appropriately by If Alice believes that Bob is being dishonest, high-level languages. she has the opportunity to publish a state with 4

a higher nonce that both of them have signed Running two consensus mechanisms on top of each other before the countdown finishes. If she does so, the is as expensive as running both separately. Additionally, it channel closes immediately. Otherwise it closes doesn’t increase security, because the least secure one can when the countdown has finished. still be attacked and made to produce “false” values. Thus, we propose to conflate the two consensus mechanisms into C. Consensus mechanism one, essentially reusing the mechanism that we use to agree Æternity uses a hybrid Proof-of-Work and Proof-of-Stake on the state of the system, to also agree on the state of the consensus mechanism. The block-order will be determined outside world. via Proof-of-Work. Certain system variables will be deter- The way that this works is as follows. Any aeon-holder mined via on-chain prediction market system, which allows can launch an oracle by committing to answering a yes/no- the users to participate and bring in their knowledge. For question. When doing so, they also need to specify the the PoW algorithm we currently favor a variant of Tromp’s timeframe during which the question can be answered, which Cuckoo Cycle, one which is memory bound, and also is can start now or some time in the future. The user that an ”indirectly useful Proof-of-Work”, as it requires less launches the oracle is required to deposit aeon in proportion electricity to run, but instead has another limiting factor, to the length of the timeframe, which will be returned if the the one of memory latency availability. This also makes it user supplies an answer that gets accepted as truth, otherwise feasible to mine with a smart phone. it is burned. The blockchain generates a unique identifier for Tromp writes about his work: the oracle that can be used to retrieve the answer once it is available. ”[Cuckoo Cycle is] an instantly verifiable memory Once the time comes for the question to be answered, the bound PoW that is unique in being dominated by user who launched the oracle can supply an answer for free. latency rather than computation. In that sense, min- Once the oracle launcher has supplied an answer or until a ing Cuckoo Cycle is a form of ASIC mining where certain amount of time has passed, any other users can submit DRAM chips serve the application of randomly counter-claims by depositing the same amount of aeon. If reading and writing billions of bits. no counter-claims have been submitted by the end of the When even phones charging overnight can mine timeframe, the answer supplied by the user that launched the without orders of magnitude loss in efficiency, oracle is accepted as truth, and the deposit is returned. If any not with a mindset of profitability but of playing counter-claims are submitted, then the consensus mechanism the lottery, the mining hardware landscape will for blocks will be used to answer the oracle. This is more see vast expansion, benefiting adoption as well as expensive, but since we know we can take at least one of decentralization.” the two safety deposits, we can use it. Preview: The consensus mechanism has a somewhat non- standard role in Æternity. In addition to agreeing on new D. Governance blocks for the blockchain, it also agrees on both answers to Governance of blockchain-based systems has been a big oracle questions and the values of the system’s parameters. problem in the past. Whenever a system upgrade needs to be In particular, the consensus mechanism can change itself. done, this requires a hard fork, which usually leads to big However, it should be noted that this is not entirely unprob- discussions among all value holders. Even simple things, like lematic. For example, if a simple proof-of-work mechanism correcting an arbitrarily set variable in the source code, as was used, it would be rather cheap to bribe the miners to we have seen with the block size debate in Bitcoin, seem corrupt the oracle. Therefore Æternity is going to use a novel to be very hard in a system where the users’ incentives are hybrid Proof-of-Stake Proof-of-Work algorithm, leveraging not aligned with the decision makers, and where there is the benefits of both. Independently from this, PoW is going no clear upgrade path. We have also seen more complicated to be used to issue new aeon tokens. governance decisions, like fixing a single smart contract bug Sidenote: Originally Aeternity intended to be a 100 percent in “The DAO”, which required quick intervention by system proof-of-stake blockchain. We don’t think anymore that a developers. decentralized 100 percent PoS system is possible. The primary problem of these systems is easily C.1) Oracles: A crucial feature for most contracts, identifiable—the decision-making process for a protocol up- whether encoded as text or as code, is the ability to refer to grade or change is not well defined and lacks transparency. values from the environment, such as the prices of different Æternity’s governance system is part of the consensus. It uses goods or whether a certain event occurred or not. A smart prediction markets to function as efficiently and transparently contract system without this ability is essentially a closed as possible. system and arguably not very useful. This is a generally ac- Moreover, the consensus mechanism is defined by a num- cepted fact and there are already several projects that attempt ber of variables that determine how the system functions to bring external data into the blockchain in decentralized and that are being slightly updated by each new block. From way [8]. However, to decide whether a supplied fact is true how much it costs to make transactions or ask an oracle, to or not, these essentially require the implementation of a new modifications of fundamental parameter values like the block consensus mechanism on top of the consensus mechanism. time. 5

By having prediction markets about the variables that 2 change. define the protocol, the users can learn how to efficiently 3 improve the protocol. By having predictions markets about 4 We define the following variables for the following calculations: potential hard forks, we can help the community come to 5 consensus about which version of the code to use. Each user 6 B = block\_size in bytes chooses for itself which metric it seeks to optimize, but a 7 F = blocks\_till\_finality simple default strategy would be to maximize the value of 8 R = time\_till\_finality in seconds its holdings. 9 T = transaction size in bytes 10 E. Scalability 11 transactions per second = B * F / (T * R) 12 E.1) Sharding trees: The architecture that has been pre- 13 B = 1000000 bytes = 1 megabyte per block sented thus far is highly scalable. It is possible to run the 14 F = 24*60*2 blocks per day blockchain even when each user only keeps track of the 15 R / F = 30 seconds per block 16 R = 24*3600 seconds per day part of the blockchain state that they care about and ignores 17 T = 1000 bytes per transaction everyone else’s data. At least one copy of the state is needed 18 for new users to be certain about the substate that they care 19 1000000 * 24*60*2 / 1000 / 24*3600 about, but we can shard this data across arbitrarily many 20 = 1000000 / 1000 / 30 nodes so that each node’s load is arbitrarily small. Merkle 21 = ca. 32 transactions per second (fast enough to sign up every human within 8 trees are used to prove that a substate is part of the state years) [11]. It is easy to imagine a scenario where certain nodes specialize on keeping track of the trees and get paid for To operate a node, we need to keep a copy of all the inserts and look-ups. blocks since finality, and we need to be able to record 100 E.2) Light clients: Light clients don’t download the entire times more information, in case there is an attack. Estimating blocks. First the user gives their client a hash in the history that finality is 2 days, then there would be 5760 blocks till of the fork they prefer, a technique also known as weak finality. So the memory requirement is 5760 * one megabyte subjectivity [12]. Then the client knows only to download * 100 = 576000 megabytes = 576 gigabytes. When there forks that include a block with that hash. The client only isn’t an attack happening, one would only need about 5.76 downloads the headers of the blocks. The headers are much gigabytes to store the blocks. smaller than full blocks; very few transactions are processed. For simplicity, we made no mention of the block headers III. A PPLICATIONS when discussing the block structure in section II-A.4, but The stateless nature of the Æternity smart contracts makes they contain the following: it easy to build the following applications on Æternity’s • The hash of the previous block. blockchain. It is especially suitable for high-volume use- • The root hash of all of the state trees. cases. E.3) State channels and parallelism: State channels have immense throughput and most transactions inside them A. Blockchain essentials are never executed or even recorded on the blockchain. Blockchain essentials are necessary primitives like aeon, Additionally, the channels don’t write to any shared state wallets, names and related concepts. They modularize on-chain, so all transactions that actually do get recorded reusable components which can be used as application foun- on the blockchain can be processed in parallel. Given that dations and can be improved on. most consumer hardware sold today has at least four pro- A.1) Identities: Each account will have an associated cessing cores, this has the immediate effect that transaction unique ID number. Users can register unique names, and throughput is multiplied by roughly a factor of 4. link names to the Merkle-root of a data structure. The Furthermore, the fact that there will never be any complex data structure can contain one’s unique ID as well as other concurrent interaction suggests that sharding this blockchain information about one’s account. We aim to use Schema.org’s architecture should be relatively easy. Since blockchain JSON format to represent things like persons or companies sharding is still fairly experimental, we have deliberately [13]. chosen not to pursue any sharding techniques in the initial design of Æternity. However, if this changes in the future, A.2) Wallet: A wallet is a piece of software that is used Æternity should be one of the easiest blockchains to shard. to interact with Aeternity. A wallet manages private keys for E.4) Transactions per second at a given memory re- the aeon and creates and signs transactions. One can use quirement: The variables that define the protocol are all the wallet to send channel transactions, and use apps in the constantly being updated by the consensus. From their initial channel network. default values, we can calculate the initial default rate of A.3) Proof of existence: One transaction type allows for transactions per second. the publishing of the hash of any data. System participants can use the headers to prove that the data existed at that 1 Note that this is a draft and will likely point in time. 6

B. State channel applications season. We can insure them against their crops wilting from Smart contracts in state channels are perfect for micro- dryness. services on the web that require a high transaction through- b) Whistleblowing: Event contracts can also be used put. to incentivize revealing sensitive information. For example, B.1) Toll API: Most APIs existing today are publicly we could bet on the event “Information indicating that available for anyone to call, or else they are secured by a Company A has used illegal pesticides was released on or username-password–scheme or unique access tokens. Pay- before January 24th, 2017”. Any person with access to such ment channels allow for a new kind of API, where one information would be incentivized to first bet that the event pays for every call to the API, possibly every HTTP-request. will happen and then release it. Paying to access an API solves DDoS problems, and it makes B.6) Prediction markets: A prediction market works by it easier to build high-quality APIs that are always available. letting users bet on whether a future event will happen. From API responses that require a payment are fundamental for the the price of the bets we can predict the future likelihood [3], creation of as of yet impossible types of businesses and can [8], [16]. They are the most accurate way to measure the play an important role in the emergence of the decentralized future at a given price [need cit.] . Once the event has happened, economy. They create incentives for information owners to the market is settled using the oracle. make otherwise private data publicly available. As noted in section II-D, we can for example use predic- B.2) Insured crowdfunding: We can implement insured tion markets to predict which updates to the software will be crowdfunding using dominant assurance contracts [need cit.] . beneficial, and which will be harmful. We can also use them These are smart contracts that are used to raise money for a to estimate how much candidates in an election will actually public good, like a new bridge, a school or a market. be able to accomplish, so lies and baseless promises can be Dominant assurance contracts differ from traditional as- detected more easily. surance contracts like Kickstarter, in that they make it a dominant strategy to participate. If the good is not funded, all participants get their aeon back plus interest, so they are insured against reducing their liquidity without receiving the good. Using an oracle, we can ensure that the provider of the good or service only gets paid if the good or service is actually provided. B.3) Cross-chain atomic swaps: Cross chain atomic swaps allow for trustless exchange of aeon for bitcoins [14], [15]. These can be implemented using a hashlock, that locks the transactions on both blockchains under the same value. B.4) Stable value assets and portfolio replication: We can use smart contracts to program synthetic assets that stay nearly the same price as a real world asset. For example, we could make an asset that stays the same price as gold. Synthetic derivatives are created in equal and opposite pairs. For one user to have an asset that moves with gold, a different Fig. 5. Multidimensional prediction market. user will have to have an asset that move inversely to gold. For example, Alice could make a contract with Bob so that a) Multidimensional prediction markets: Multidimen- Alice owns 1 gram of gold. Out of the money in the contract, tional prediction markets allow us to predict the correlation one gram of gold worth of aeon will go to Alice, and the between possible future events. So for example, one could leftover money goes to Bob. The contract has an expiration predict that if Alice is elected leader, the price of potatoes date when the price of gold will be measured, and the funds will go down, and that if Bob wins, the price will go up. distributed to Alice and Bob accordingly. One could learn that if Google uses plan A for the next 3 B.5) Event contracts: Event contracts pay when an event months, that it will probably earn more money, and that if it happens and don’t pay when an event does not happen, as uses plan B, it will probably earn less. Or, as in fig. 5, we per the oracle’s telling. Apart from being interesting in them- can see that if Alice would be elected president, there is a selves, these can be used by several different applications: high likelihood of the price of potatoes being rather low. a) Insurances: We can use event contracts to imple- B.7) Market with batch trading at a single price: There ment insurances. For example, expensive music event tickets are two approaches available to attackers that want to rob can become worthless if the weather goes bad. However, if aeon from a market. They can take advantage of the market the concert-goer receives money if the oracle decides that being split in time, or they can take advantage of it being it rained on the day of the event, the investment can be split in space. protected so that one can afford to find an emotionally- • If the market is split in space, then the attacker does adequate alternative. Slightly more seriously, farmers are arbitrage. He simultaneously makes trades in both mar- often interested in the total number of inches of rain in a kets at once so that his risk cancels out and he earns a 7

profit. IV. I MPLEMENTATION • If the market is split in time, then the attacker front- Most key concepts already have proof-of-concept imple- runs the market. He reads the transactions coming into mentations in Erlang. This includes the blockchain itself, the market and creates buy and sell orders immediately the contract language and VM, the oracle and governance before and after. mechanisms, as well as an old version of the consensus mechanism. We have used Erlang/OTP because it makes it easy to write code that can respond to many requests in parallel and does not crash. The servers with the highest up- time in the world are based on Erlang. It has been used for industrial applications for 30 years, proving itself to be a reliable and stable product. A. Virtual machine and contract language The virtual machine is stack-based and similar to Forth and Bitcoin’ scripting language, although in comparison to the latter, it is rather rich. The VM supports functions instead of gotos, making its semantics relatively simple to analyze. A list of the VM’s opcodes can be found on our Github3 . Additionally, there exists a higher-level Forth-like lan- guage called Chalang, which compiles to bytecode for the VM. It supports macros and variable names, but keeps the stack-based execution model [17]. Examples of Chalang code Fig. 6. The black line is the demand curve, the red line is the supply curve. The sells in red are the same size as the buys in red. The vertical can also be found on our Github4 . line is the price the market maker selected. Everyone willing to buy at a higher price traded at that price, everyone willing to sell at a lower price B. Adoption via web-integration traded at that price. The web is the most popular application platform. We will provide easy-to-use web-development tools, such as JS- libraries and JSON-APIs for the core features of the Æternity To combine markets in space, everyone should use the blockchain. same market maker. To combine markets in time, we need to have trading done in batches, at single price. The market C. Open source modules maker needs to commit to each person what price he decided, In order to be easily re-used for private blockchain con- and if anyone can find contradictory commitments from the sortium and other use-cases, the software will be written in market maker, then all of his customers should be able to MIT-licensed modules, such as a consensus module, that can drain all of his channels. If the market maker commits to a be adapted to specific needs. fair price, then he will match the same volume of buyers and sellers together, as fig. 6 shows. Otherwise, he will end up D. Usability and UX design in a situation similar to fig. 7, thus taking a large risk. Frictionless human interaction will be a big focus of our development efforts. More specifically, we will make sure that who controls the identity, keys and transactions is clearly established. Also, offering easy access via web-gateways will be a central focus of future development. Users participating in prediction markets via a Tinder-like (swipe left/right) mobile interface, and simple web-wallets that can be easily integrated in a website through an iframe will be the new norm. V. D ISCUSSION We have provided an explanation of how to architect a fundamentally more efficient value transfer system. The described system is in fact a global oracle machine that can be used to provide decision making services at global scale. In particular, all the applications proposed in section III can be built easily and efficiently on top of Æternity. 3 https://github.com/aeternity/chalang/blob/ Fig. 7. The black is much bigger than the red. The market maker is selling many more shares than it is buying, thus taking on a lot of risk. master/opcodes.md 4 https://github.com/aeternity/chalang/tree/ master/examples 8

However, our approach has both fundamental limitations the secret to a hashlock has been revealed, the transaction and avenues for improvement. These are discussed here. doesn’t go through. If it goes offline afterwards, the only possible “negative” effect is that the transmitter is not able A. Limitations and tradeoffs to claim its aeon. While we do believe that the tradeoffs made in our architecture are reasonable given the resulting performance B. Future work increase in other areas, Æternity is not a catch-all solution for decentralized applications. It should rather be viewed as There are several possible ways to improve on the current a synergistic complement to existing technologies. There are architecture. several caveats that one need to be aware of. B.1) Functional contract language: A reasonable future A.1) On-chain state: Despite having many advantages, direction would be to experiment with high-level languages Æternity’s lack of programmable state makes it unfit for that adhere more closely to the functional paradigm. Keep- applications that require a custom state to be under con- ing track of an implicit stack is generally error-prone and sensus. For example, this includes DAOs as they are usually arguably not suitable for a high-level, developer-facing lan- conceived, custom name systems and subcurrencies which guage. This should be rather easy given that programs are are not tied to the value of an underlying asset. already pure functions (modulo some environment variables), A.2) Free option problem: If Alice and Bob have a and would greatly simplify both development and formal channel and Alice signs a contract, she essentially gives Bob verification of contracts. If this is done, it could also make a free option when she sends it to him: Bob can choose to sense to revise the VM to be tightly coupled with the new sign and return (i.e. activate) the contract at any time in language, to make the compilation less error-prone and less the future. Often this is not what is intended. To avoid this dependent on trust in the developers. Ideally, the translation problem, channel contracts aren’t immediately activated with from surface language to VM code would simply be a direct the full amount. They are divided up in time or space. Both transcription of peer-reviewed research, though pragmatic participants would sign up for the contract in small intervals concessions will likely have to be made. so that neither user ever offers a large free option to the B.2) Multi-party channels: Currently, all channels on other. Æternity are limited to two parties. While multi-party chan- For example, if the parties want to bet 100 aeon, then nels can de facto be achieved through hashlocking, this can they might sign up to it in 1000 steps that each increase the be expensive. Hence, we plan to investigate the possibility bet by 0.1 aeon. This would require about 1000 messages of adding support for n-party channels, with a m-of-n to pass, 500 in each direction, which is cheap enough since settlement mechanism. the contract is never submitted to the blockchain. As another example, if one wanted to make a financial asset that would G LOSSARY last for 100 days, one might sign up in 2400 steps of one hour each. This would require about 2400 messages to pass, Blockchain A distributed, tamper-proof database with me- 1200 in each direction. tered access. The database is defined by a growing list of A.3) Liquidity loss and state channel topologies: When hash-linked blocks and can have any rules for appending composing channels using hashlocks as demonstrated in them. section II-B.1, any middlemen have to lock up at least twice Aeon An aeon represents an unit of account and an access as many aeon as will be transmitted through them. For right to the Æternity blockchain. It is transferable. example, if Alice and Carol want to transact through Bob, Transaction A message from a user to the blockchain. Bob will act as Carol when interacting with Alice, and vice- This is how users can use their currency to access the versa. blockchain. Since this is expensive for Bob, he would most likely State Channel A relationship between two users recorded earn a fee as compensation. If Alice and Carol expect to on the blockchain. It enables users to send aeon back conduct many trades between each other, they can avoid this and forth, and to create trustless smart contracts between by creating a new channel and trustlessly moving the active them that are enforced and settled by the blockchain. contracts to the new channel using a hashlock. Hash A hash takes as input a binary of any size. It gives Still, since keeping an extra channel open impacts one’s a fixed sized output. The same input always hashes to liquidity negatively, going through middlemen is expected the same output. Given an output, one cannot calculate to be desirable in many cases, especially in cases where the input. the parties don’t expect to trade a lot in the future. Thus, a Hashlocking This is how we connect pairs of channels to channel topology where certain rich users make money from make smart contracts that involve more than 2 people. trustlessly transmitting transactions between other users is A secret is referenced by it’s hash. When the secret is expected to emerge. revealed, it can update multiple channels at the same It should be noted that this does not constitute a single time. point of failure, since we do not trust these transaction Governance A well-defined process of making decisions for transmitters with anything. If a transmitter goes offline before the future protocol(s) of the blockchain. 9

Oracle A mechanism that tells the blockchain facts about [11] R. C. Merkle, “Protocols for public key cryptosys- the world we live in. Using oracles users can predict the tems,” in IEEE Symposium on Security and Privacy, outcome of events, external to the blockchain system. 1980. Value-Holder An user who owns aeon, or an financial [12] V. Buterin, “Proof of stake: How I learned to derivative in the system. love weak subjectivity,” 2014. [Online]. Available: Validator A validator is an user who participates in the https : / / blog . ethereum . org / 2014 / 11 / consensus mechanism. In the case of Æternity, every 25 / proof - stake - learned - love - weak - value-holder can participate. subjectivity/. [13] “Schema.org schemas,” 2016. [Online]. Available: ACKNOWLEDGMENTS http://schema.org/docs/schemas.html. Thanks to Vlad, Matt, Paul, Dirk, Martin, Alistair, Devon [14] “Atomic-cross-chain-trading,” 2016. [Online]. Avail- and Ben for proof-reading. Thanks to these and lots of other able: https : / / en . bitcoin . it / wiki / people for insightful discussions. Atomic%5C_cross-chain%5C_trading. R EFERENCES [15] “Interledger,” 2016. [Online]. Available: https:// interledger.org/. [1] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash [16] K. J. Arrow, R. Forsythe, M. Gorham, et al., “The system,” 2008. [Online]. Available: https : / / promise of prediction markets,” Science, 320 2008. bitcoin.org/bitcoin.pdf. [Online]. Available: http://mason.gmu.edu/ [2] V. Buterin, “Ethereum: A next-generation smart con- ˜rhanson/PromisePredMkt.pdf. tract and decentralized application platform,” 2014. [17] Z. Hess, “Chalang,” 2016. [Online]. Available: [Online]. Available: https : / / github . com / https://github.com/aeternity/chalang. ethereum/wiki/wiki/White-Paper. [3] P. Sztorc, “Market empiricism,” [Online]. Available: http://bitcoinhivemind.com/papers/1_ Purpose.pdf. [4] M. Liston and M. Köppelmann, “A visit to the ora- cle,” 2016. [Online]. Available: https : / / blog . gnosis.pm. [5] C. Detrio, “Smart markets for smart contracts,” 2015. [Online]. Available: http://cdetr.io/smart- markets/. [6] Namecoin wiki, 2016. [Online]. Available: https : //wiki.namecoin.org/index.php?title= Welcome. [7] P. Snow, B. Deery, J. Lu, et al., “Factom: Business processes secured by immutable audit trails on the blockchain,” 2014. [Online]. Available: http : / / bravenewcoin.com/assets/Whitepapers/ Factom-Whitepaper.pdf. [8] J. Peterson and J. Krug, “Augur: A decentralized, open-source platform for prediction markets,” 2014. [Online]. Available: http : / / bravenewcoin . com / assets / Whitepapers / Augur - A - Decentralized - Open - Source - Platform - for-Prediction-Markets.pdf. [9] A. Swartz, “Squaring the triangle: Secure, decentral- ized, human-readable names,” 2011. [Online]. Avail- able: http : / / www . aaronsw . com / weblog / squarezooko. [10] T. Hvitved, “A Survey of Formal Languages for Contracts,” in Formal Languages and Analysis of Contract-Oriented Software, 2010, pp. 29–32. [On- line]. Available: http : / / www . diku . dk / hjemmesider / ansatte / hvitved / publications/hvitved10flacosb.pdf. 10