EEnso
A general-purpose virtual machine
Bruno Franc¸a
Trinkler Software [email protected]
Version 4 – August 1, 2019
Abstract —In this paper we introduce Enso, a virtual machinedesigned to be used as general-purpose state transition function inblockchains. This design allows the blockchain application logicto be coded into the state, instead of into the state transitionfunction, making it much more flexible and easier to modify. Abyproduct is reducing the frequency of forks, concerted or not.
I. I
NTRODUCTION
Despite the diversity and complexity in the blockchainworld today, all blockchains are just distributed virtual ma-chines.Independently of the function for which it is used, ablockchain is just a virtual machine running some code dis-tributed across several computers.The components of such a distributed virtual machine canbe visualized as a stack: StateSTFConsensusNetworkingStarting at the bottom, we have the networking. This basi-cally includes all the tools that the computer needs to connectto the other nodes and to receive, transmit and relay data acrossthe network. It is a standard component for any peer-to-peernetwork.Then we have the consensus. This allows all nodes to reachan agreement on what blocks are accepted. There is a hugevariety of consensus protocols, but they all have the sameobjective: making all honest nodes reach an agreement onsome input data.Lastly, we have the state and the state transition function(STF). State represents, of course, the current state of the vir-tual machine. The state, for most users, is the only componentthat they interact with. The state transition function is thefunction that takes as input the previous state and a block,and produces a new state as output. So, it is what defines therules for modifying the state. Contrary to the networking andconsensus, these two components no longer interact with, orhave any notion of, other nodes. Together they just form asimple virtual machine.
This work is licensed under the Creative Commons Attribution-ShareAlike4.0 International License.
The way in which each of these components is modified,or upgraded, varies from blockchain to blockchain. The fol-lowing image illustrates how legacy chains, like Bitcoin [1] orEthereum [2], are modified:State ← ExtrinsicsSTF ← ForksConsensus ← ForksNetworking ← AdoptionThe state is always modified with extrinsics . This is howmost people will interact with the blockchain and it is verystraightforward.Next we have the state transition function and the consensus.Both can be modified with forks, either soft forks or hard forks.The problem with forking is that forks are difficult to organizeand can cause the chain to split into two networks (ex: Bitcoinand Bitcoin Cash, or Ethereum and Ethereum Classic).Finally we have the network. Changes in the networknormally are not contentious since they can happen withgradual user adoption. For example, some nodes in the Bitcoinnetwork can start accepting transactions via Tor and relayingthem to miners. There is no need for any type of consensuson whether transactions should be accepted via Tor. Any nodethat wishes to do so can make that change and make thatservice available to the network right away. So, networkingupdates happen with organic user adoption.Recently, blockchains appeared which claim to be upgrad-able by governance . We are only interested in the technicalaspect of upgrading a blockchain and not in the social orpolitical aspect (e.g. if voting should be proportional to stake,etc). The most famous examples in this category are probablyTezos [3] and Parity’s Substrate (Substrate is not actually ablockchain but rather a blockchain development kit). With thistype of chain we have the following stack:State ← ExtrinsicsSTF ← SwapsConsensus ← SwapsNetworking ← Adoption We use the same definition for transaction as the one taken by Parity.There are extrinsics, which are any input to the state transition function, andboth transactions and inherents are mutually exclusive types of extrinsics.Transactions are extrinsics that are propagated through the network and signed.Inherents are neither propagated nor signed. An example of an inherent is atimestamp. a r X i v : . [ c s . CR ] A ug ote that the state and networking are still modified in thesame fashion as legacy chains, the difference is that the statetransition function (STF) and the consensus use module swaps instead of forks.In these blockchains, there is a shell that contains only thenetworking and some other auxiliary code. Then there are twoslots (one for the STF, another for the consensus) that acceptarbitrary code blocks, called modules .The idea is that a blockchain can be modified by simplyswapping one module for another. If the blockchain also hasgovernance functionality coded into it, it is possible for thenodes to reach an agreement on whether a module should beswapped or not.Governance and module swaps are different components.Governance only allows a network to reach an agreementon whether the blockchain is to be updated or not. Theactual method of doing that update is the module swapping.Objectively, the main difference between forks and swaps isthat swaps are concerted, while forks are not. Otherwise theprocess is similar. The miners (or validator, or authorities) allagree to, at a specific time, stop using one module and startusing the next one.The breakthrough on the part of Tezos was realizing thatlegacy blockchains have their governance off-chain and thatinstead the governance should be placed on-chain into the STF.Another way of analyzing this stack is seeing what func-tionality is coded into each component. As we have said, ablockchain is a distributed virtual machine, but of course, eachblockchain is running a specific application (also commonlycalled the runtime ). For example, Bitcoin is a distributedvirtual machine running a ledger application. We can visualizewhere each part of the application is located in the stack:App data ≡ StateApp logic ≡ STFConsensusNetworkingThe application logic and data are separated, with the logicbeing hardcoded into the STF and the data being stored intothe state.This separation of code and data is how early computersworked. Programs were hardcoded into the hardware usingplugboards and then data would be fed into the computerusing some storage medium (for example, punch cards). Thiswas time-consuming, requiring the plugboard to be rewiredwhenever a new program was to be run in the computer.Then along came the stored-program computer, which treatscode and data equally. The paradigm change was thinking ofthe hardware as a general-purpose shell without any specificfunctionality predefined into it. Now programs could be fedinto the computer just like regular data.Enso applies the stored-program computer concept toblockchains. It adopts a very simple general-purpose virtualmachine as the state transition function so that the applicationlogic can be put into the state. This allows for both theapplication logic and data to be modified with extrinsics, while the consensus and the virtual machine itself are still modifiedwith forks or module swaps.App logic and data ≡ State ← ExtrinsicsVirtual machine ≡ STF ← Forks/SwapsConsensus ← Forks/SwapsNetworking ← AdoptionBy treating the logic and the data equally, blockchains canbe built with a greater degree of flexibility. And extrinsicsallow for simpler and more granular modifications to theapplication logic. Changes to the consensus or to the virtualmachine still need to be done using the module swaps, butwe expect that consensus and virtual machine updates willbe fairly rare, at least when compared with changes to theapplication logic. II. A
CTOR MODEL
The actor model is a mathematical model of computation,especially useful when concurrency is desired, that was firstpublished in 1973 and is inspired in Physics. It treats allcomputation as the result of actors exchanging messages between themselves.An actor is an object with an address, code and storage.They communicate with each other by sending messages. Forthis, each of them has a mailbox , which is basically just aqueue for the incoming messages. Upon receiving a message,an actor will run it’s code and can alter it’s own storage.An actor is thus capable of the following actions: • Pulling messages from its mailbox queue. • Deciding what to do with a message, including ignoringit. • Modifying its internal state. • Sending messages to other actors at addresses that itknows about. • Creating new actors.There is no assumed sequence to the above actions and theycan be performed in parallel. Messages are asynchronous andthus may arrive in any order.III. S
PECIFICATION
In this section we will delve into the specification of theEnso virtual machine. Enso is heavily modeled after the actormodel, with the main difference being that Enso does notsupport concurrency, although concurrency could in theory beadded.Just like in the actor model, in Enso everything is either anactor or a message.An actor is an entity composed of the following compo-nents: • ID:
A unique identifier of the actor. • Code:
A block of code containing functions that can becalled by other actors. • Storage:
A data structure containing arbitrary informationand that can be read and modified by the code.2sing Enso, the state of the blockchain will be simply theset of all actors. So, all of the application logic and data willbe coded into the actors.Note that actors in Enso do not have a mailbox. That isbecause, since no concurrency is needed, there is only a single global message queue that orders all messages sent by allactors.Messages, put simply, are asynchronous function calls fromone actor to another. By asynchronous we mean that when anactor sends a message, the actor will not be blocked whileit waits for the message to be processed. Instead it will keepworking and accepting other messages. This asynchronicityis necessary because we want the virtual machine to keeprunning even if a function call fails.A message takes the form (ID_to, function_call,parameters) , where: • ID_to:
The ID of the actor that will receive the mes-sage. • function_call: The name of the function that willbe called. • parameters: A list of parameters that will be passedto the function.Now that we know that the state is composed of actors, andthat actors communicate between themselves with messages,we can state which actions are available to an actor in Enso: • Receive messages from the global message queue. • Processing messages by calling the corresponding inter-nal functions. • Modifying its own ID, code or storage. • Send messages to other actors at addresses that it knowsabout. • Read storage of other actors at addresses that it knowsabout. • Create new actors.Contrary to the actor model, actors in Enso are able toread each others storage. The blockchain state is public andaccessible to anyone, so it only makes sense to allow actorsto also read the entire state.The only component of Enso that remains to be describedis the global message queue, which is just a simple first infirst out queue for messages.When an message is processed, it is taken out of the queueand the function function_call of the actor
ID_to iscalled with the input parameters parameters . If, for somereason, the function cannot be called, for example if the actordoesn’t exist or there is no function with that name, themessage is simply ignored.IV. I
MPLEMENTATION
The objective of the last section was to describe the com-ponents of the Enso virtual machine and its operation in anabstract form. In this section we want to give some details onhow Enso can be implemented in practice.First, even though both the application data and logic willcoexist in the state, in most cases there will be a clear sepa-ration between both. By this we mean that, when developing a new blockchain with Enso, it is useful to divide the actorsinto two categories: • Kernel actors:
All actors created at the genesis blockand during updates to the blockchain. These are actorsthat define the rules for how the runtime works and areunique actors, meaning that there is only one instance ofeach actor type. • User actors:
All actors created by the users. There is apredetermined list of actor templates, from which userscan create new user actors.The idea is that the entire application logic will be codedinto the kernel actors, for example we may have one actor tohandle the incoming extrinsics, another that implements somegovernance method, etc. While the user actors will be regularactors like accounts or smart contracts, effectively representingthe application data.Second, an extrinsic is just a message that is sent by anuser, or by some other external source, instead of by an actor.Otherwise, an extrinsic should be able to be processed by anactor just like a message.Third, a block is just an ordered list of extrinsics. When thevirtual machine receives a new block, it just needs to processthose extrinsics in order and in the end it will have reached anew state.So, to process a new block, a node follows these rules:1) Receive an ordered list of extrinsics.2) Add all the extrinsics, in order, to the global messagequeue.3) Take the top message and send it to the correspondingactor.4) The receiving actor then may create more messages,which will also be added to the queue.5) Keep repeating steps 3 and 4 until there are no moremessages left6) When there are no more messages to be processed, thestate transition has finished.V. C
ONCLUSION
This paper analyzes the organization of a blockchain’scode by thinking of it as a distributed virtual machine. Wethen argue that a distributed virtual machine needs to actanalogously to a stored-program computer, which implies thatthe application logic needs to be coded into the state and thatthe state transition function needs to be a general-purposevirtual machine. Using this method it is possible to haveblockchains that are simpler and faster to develop and operate,and that require far fewer forks.R
EFERENCES[1] S. Nakamoto et al. , “Bitcoin: A peer-to-peer electronic cash system,”2008. [Online]. Available: https://bitcoin.org/bitcoin.pdf[2] V. Buterin et al. , “A next-generation smart contract and decentralizedapplication platform,” white paper , 2014. [Online]. Available: https://cryptorating.eu/whitepapers/Ethereum/Ethereum white paper.pdf[3] L. Goodman, “Tezos: a self-amending crypto-ledger,” , 2014. [Online].Available: https://everipedia-storage.s3.amazonaws.com/NewlinkFiles/16739988/8d4d1f1b-8/white paper.pdf, 2014. [Online].Available: https://everipedia-storage.s3.amazonaws.com/NewlinkFiles/16739988/8d4d1f1b-8/white paper.pdf