LTO Network Technical Paper

Wednesday, June 12, 2019
Download document
Save for later
Add to list

LTO.network Blockchain for Decentralized Workflows www.lto.network ✦ Abstract Digitalization and automation of business processes offer great benefits in terms of productivity and cost reduction. Organizations struggle to tap into these benefits for inter- organizational processes, partly due to a lack of trust. Bitcoin has proven how blockchain can use distribution and cryptography to provide a system that does not rely on trust. LTO builds upon this foundation with a decentralized workflow engine employed for ad-hoc collaboration. Information is shared between parties using per-process private event chains and hashed on a public blockchain. This hybrid approach allows organi- zations to meet any data protection regulations and prevents scalability issues that are typically associated with blockchain projects. I NTRODUCTION The digital revolution has resulted in many changes that make our lives more efficient[1]. This wave of progress has taken place primarily in consumer-facing and internal business processes. When it comes to inter-organizational processes we have to acknowledge that the changes are less drastic. Faxing has largely been replaced by e-mail, and the typewriter is replaced by a word processor, but beyond these superficial changes, execution of the underlying processes have hardly changed. The first reason that automation has been absent is the reluctance of corpora- tions to rely on external systems operated by a counterparty[2], as the distribution of information plays an important role in the outcome of a relationship[3]. Where there is a natural power imbalance, one party may take control, forcing all others to use its centrally managed system. We see this when dealing with the government and to some extent with corporations. In a situation where no single party can claim control, automation simply doesn’t happen[4]. To achieve automation for inter-organizational processes, for over two decades people have experimented with decentralized workflows[5]. In these studies and experiments, a high level of trust and fair play is assumed, focusing primarily on solving technological challenges. In reality, this is a false assumption as a lack of trust prevents successful pilots from making it to production. A second reason for the absence of automation is the correlation between efficiency and corruption[6]. Traditionally large corporations and government bodies require a large number of people to execute a process. A fair amount of bureaucracy is required to coordinate such processes. This increases the costs of bribery, reducing the incentive to automate. Increasing efficiency negates this effect. This paper shows how both problems may be solved using blockchain, provid- ing a solution where all parties can be on equal footing.

1 C ONTENTS Part I. Live Contracts 3 1 Live vs Smart Contracts 3 1.1 Ricardian Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Finite state machine 3 2.1 Deterministic Finite State Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Extended Finite State Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Communicating finite state machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4 Contract as automaton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Alternative modeling methodologies 4 3.1 Petri Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 BPMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3 DEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4 Scenario 5 4.1 States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2 Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3 Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.4 Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5 Data-objects 5 5.1 Immutability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2 Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.3 Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.4 Custom types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6 Identities 6 6.1 Inviting identities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.2 Updating an identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7 Process 6 7.1 Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.2 Manual actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.3 System actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.4 Sub-processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.5 Projection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.6 Data operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.7 Passive testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8 Adaptive workflows 7 8.1 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.2 Deviation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.3 Scenario update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9 Event chain 8 9.1 Cryptographic signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.2 Hash chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10 Distribution 8 10.1 Private chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.2 Genesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 11 Consensus mechanism 8 11.1 Chance of a conflict . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 11.2 Branch validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.3 Cascading rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.4 Unanchored events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.5 Merging branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11.6 Forks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 12 Privacy 10 12.1 Linked data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.2 GDPR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.3 Zero-knowledge proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 13 Common patterns 10 13.1 Chain interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 13.2 Explicit synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Part II. Global blockchain 12 14 Centralized vs decentralized anchoring 12 15 Consensus algorithm 12 15.1 Leasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 15.2 Raffle factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 15.3 Forge probability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 15.4 Fair PoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 15.5 Generator signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 15.6 NG protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 16 Transaction types 13 16.1 Anchoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 16.2 Authentication and authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 16.3 Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 16.4 Chain of trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 16.5 Smart accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 17 Summary blocks 14 17.1 Key block size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 17.2 Growth without aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 17.3 Segregated witness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 17.4 Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 17.5 Difference to pruning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 17.6 Summary block size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 17.7 Total size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 17.8 History nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 18 Network vulnerability 16 18.1 Importance inflation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 18.2 Nothing at stake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 18.3 LPoS centralization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 18.4 Denial of service attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 18.5 SHA-2 vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Part III. Platform 18 19 Architecture 18 19.1 Micro architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 19.2 Application layers and services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 20 UI Layer 18 21 Application Layer 18 21.1 Web server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 21.2 Workflow engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 22 Private chain layer 18 22.1 EventChain service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 22.2 Event enqueue service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 22.3 Event dispatch service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 23 Public chain layer 19 23.1 Anchor service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 24 Container orchestration 19

3 Part I. Live Contracts Business process modeling is a common strategy for any programs. This is an inherent property of the Live Contract that medium or large organization[7]. Creating a visual representa- is obtained by the way it is defined. There is no separate natural tion of a workflow process allows it to be analyzed, improved, language version for legal purposes and a coded version for and automated (figure 1). Unlike procedures that are written in programme execution. a natural language or written in a programming language, these models can be understood by both humans and computers. 1.2 Enforcement On-chain enforcement is poorly suited for many real-world cases. Smart contracts rely on proactive enforcement, meaning either breaching the agreement must be impossible or dropping out must be possible for each side[12]. Draft document Take a non-disclosure agreement as an example. The blockchain can’t prevent a party from disclosing information, nor can it force a party to actively participate in resolving a Review document Declined breach. For such a contract to work, a self-enforcing agree- ment[13] must hold the full penalty as a deposit, so each party is better off participating in a resolution. Having to tie up large amounts of funds as deposits for × penalty fees on arbitrary contracts is impractical for most orga- Accepted nizations[14]. Additionally, the effectiveness of penalty interest and similar measures are limited to the value held by the smart + contract. Most inter-organizational business processes call for off- Party A signs Party B signs chain dispute resolution via an authoritative party. A Live Contract can facilitate in resolving a dispute. This may include conflict negotiation, mediation and even arbitration (by arbiter + or judge). Running a process on the LTO platform forms a verifiable history of events, reducing the amount of asymmetrical infor- mation. The distribution of information influences negotiations Fig. 1: A BPMN diagram can be used to visualize workflows. in case of a dispute[3] and influences the assessment by the authoritative third party. For inter-organizational cooperation, modeling is not done merely to improve communication. The parties involved must 1.3 User interface specify the process to serve as binding agreement[8]; on the LTO platform this is called a Live Contract. Ethereum provides an internal Turing-complete scripting lan- The LTO platform creates an ad hoc private blockchain for guage, which a programmer can use to construct any smart con- each Live Contract. Such a blockchain is not intended as an tract or transaction type that can be mathematically defined[10]. immutable ledger but ensures all parties have an up-to-date This makes it very abstract as the state contained within the countersigned history of events and shared states. contract has no intrinsic meaning. To interact with such contracts a user interface must be created for each specific smart contract, or more precisely, the 1 L IVE VS S MART C ONTRACTS interface of such a contract[15]. Standards like ERC-20[16] and Live Contracts have a similar goal as smart contracts as imple- ERC-721[16] manage to decouple the UI from the contract logic mented on Ethereum[9]. Both define and solidify logic that can in some cases but restrict the possibilities when designing a be applied in a trustless and verifiable way. contract. The philosophy behind these two types of digital contracts With Live Contracts, information does have an intrinsic is very different however. Ethereum describes smart contracts, meaning. While this restricts use cases, it does enable gener- as cryptographic ”boxes” that contain value. These boxes only ating an interface purely based on the data provided by the unlock it if certain conditions are met[10]. contract and its process. As a result, any workflow can be Live Contracts do not directly hold value but describe how digitalized and executed on the LTO platform without the need two or more parties should interact. The intent is much closer of creating a specific UI for each one. to that of a traditional (paper) contract. 2 F INITE STATE MACHINE 1.1 Ricardian Contracts A Live Contract defines a workflow as a Finite State Machine A Live Contract fits within the definition of a Ricardian con- (FSM)[17]. This makes it possible to visualize the workflow as tract1 [11]. Most notably, it’s easily readable by both people and a flowchart (figure 2), which makes it understandable for both humans and computers. 1. A Ricardian Contract can be defined as a single document that is a) a contract offered by an issuer to holders, b) for a valuable right held by holders, and managed by the issuer, c) easily readable by people (like a contract on paper), d) readable by programs (parsable like a database), e) digitally signed, f) carries the keys and server information, and g) allied with a unique and secure identifier.

4 2.1 Deterministic Finite State Machine The event chain (see section 9) is able to function as a com- Any blockchain logic needs to be deterministic[18]. Where munication channel between two FSMs. When two processes computer programs may require extra effort to comply with are isolated by using different event chains, this communication this requirement, a DFSM is deterministic by definition. channel is non-deterministic, which inherently makes the whole system non-deterministic[20]. This can be overcome by making acknowledgments part of the FSM as shown in section 13.1. start q0 2.4 Contract as automaton Document declined Request review A Finite State Machine can be applied as an agreement between q1 the participants by formalizing obligations, permissions and prohibitions that parties impose on the other[21]. Contracts like Document accepted financial agreements[22] and service contracts[23] can be fully digitized as FSM. q2 However, these representations are not sufficient to be used Party 2 signed Party 1 signed as workflow, as they do not define the orchestration, com- munication, and choreography within a process. These factors q4 q3 can be incorporated, however, this causes the FSM to grow exponentially in complexity[24]. Party 1 signed Party 2 signed For practicality, an FSM will at best represent an incomplete q5 contract. This doesn’t have to be a problem as these gaps may be filled by default rules[25]. The system does allow Fig. 2: Example of a Finite State Machine visualized as a flowchart renegotiation of a Live Contract, either to resolve a particular situation or in general, as shown in section 8. Another thing to note is that not every action in a process 2.2 Extended Finite State Machine constitutes a binding factor. In figure 1, the acceptance of the Also visualized in figure 2 is how a problem arises when text of a document does not constitute a binding agreement, as multiple actions are required to get to a state, but the order this only occurs when the document is signed. To facilitate this in which they occur is arbitrary. This can be modeled as a distinction, actions can be categorized as either informative or transition path for every possible order, as is done in figure 2. performative actions[26]. However, with this approach, the number of states and state transitions will grow exponentially with the number of actions. This makes the visualization of the workflow less clear, but also 3 A LTERNATIVE MODELING METHODOLOGIES makes it harder and more error-prone to define the workflow. Communicating extended finite state machines are commonly This is why instead of using a regular FSM, a Live Contract used in describing telecommunication systems and other real- uses an Extended Finite State Machine[19] (EFSM), allowing time systems[27], but not business processes. for conditional state transitions. More common notations for workflows provide additional Figure 3 defines the same workflow as in figure 2 using an challenges when modeling decentralized inter-organizational EFSM. processes. start q0 3.1 Petri Nets Petri nets[28] are a graphical way of representing a system in Document declined Request review which there are multiple independent activities running at the same time. The ability to model multiple activities differentiates q1 Petri nets from finite state machines. In a finite state machine, there is always a single “current” state that determines which Document accepted action can occur next. In Petri nets, there may be several states Party i signed any one of which may evolve by changing the state of the Petri q2 net. Alternatively, some, or even all, of these states may evolve [party i 6= signed] in parallel causing several independent changes to the Petri net Finalize document to occur at once[29]. [∀ i ∈ parties : i = signed] Workflow nets (WF-nets) are a subset of Petri nets that may be used to describe business processes[30]. WF-nets can q3 describe the whole process rather than only one sequence. Extended finite state machines use a global state to hold Fig. 3: Example of an Extended Finite State Machine: conditions in information. This information must be isolated per sequence. brackets have to be true for the transition to be valid Failure of making the data immutable can be exploited as shown in section5.1. With Petri nets, using global information isn’t possible. Instead, information needs to flow through the 2.3 Communicating finite state machines workflow. Finite state machines are limited to sequential behavior, they do With the approach of CEFSMs, sequences are defined as not support concurrent processes. In order to represent work- individual processes. This makes it trivial to apply access flows with concurrency, each sequence of parallel instructions control. When representing the workflow as a whole, this can’t may be represented as individual FSM. be addressed in the same way.

5 Petri nets have an interesting notation, which has proven • σx as an action, to be able to correctly represent a business workflow. Given • Σ as the set of all possible actions Σ = {σ1 , ..., σn }, it’s possible to address the mentioned challenges, the WF-nets • δ as the transition function δ : Q × Σ → Q, notation might be preferable over using individual FSMs. • F as the set of final states with F ⊂ Q | F = ∅, Due to the similarity between Petri nets and FSMs, switch- • I¯ as all actor definitions, ing to WF-nets does not fundamentally change the solution as • Ā as all asset definitions, described in this paper. • D as the set of embedded data-objects. 3.2 BPMN 4.1 States BPMN is the industry standard in business model processing States in set Q typically consists of: and would be a likely candidate for a modeling notation • a title: a short title for the state, for LTO. However, there are a number of limitation that are • a set of actions with transaction as {(− → qx , δ), ...}, particularly problematic for inter-organizational systems[31]. • a description: a long description for the state, The Business Process Execution Language (BPEL) typically • a map or instructions for specific actors. associated with BPMN, is a non-deterministic Turing complete language towards web services[32]. This makes it ill-suited for The state describes the actions that may be performed in this automation on a blockchain. state and includes the state transition. This allows actions to be A proposed alternative is to translate a BPMN model into a used in different states. Petri net, which is translated in a smart contract[33]. While the translation into a (Turing complete) smart contract 4.2 Actions is unnecessary, the translation from BPMN into a Petri net (or CEFSM) might be interesting in order to support the current The scenario defines Σ, the set of all possible actions that can industry standard. be performed in the workflow. Examples of such actions are filling out a form, reviewing a document, and sending an HTTP request or response. The action type and object properties are 3.3 DEMO defined using JSON schema. “DEMO” is an acronym for “Design & Engineering Method- An action defines which of the actors from set I may execute ology for Organizations”. This methodology for describing it, as well as, optionally, additional constraints as described for organizations and their business processes is based around the EFSM. the ”communicative action”. It uses four models to create a When an action is executed, a state transition is triggered. holistic view; the Construction Model (CM), Process Model Actions can be categorized in manual actions that require (PM), Action Model (AM), and Fact Model (FM)[34]. human interference to be executed and system actions that can Rather than considering each step of a process individually, be executed automatically by the system. it establishes a generalized workflow for every single performa- Optionally actions can define instructions on updating ac- tive transaction. In such a transaction, there are two roles: the tors and assets using data from the response. initiator and the executor. The standard sequence that follows is as follows. The initiator does a request, the executor makes 4.3 Actors a promise, the executor performs the actions and makes a statement about the result, the initiator either accepts this as Set I¯ defines all actors that can have a role in a process. transaction completed or rejects it[26]. Each actor is defined as an object using JSON Schema. Actor Other alternative flows are also modeled, like the execu- properties that are relevant to the process must be defined. tor declining the request, the initiator wanting to revoke the An actor in a scenario is only a static definition that may be request, the executor being unable to fulfill the promise, etc. instantiated in a process. These alternative flows are often not, or only partially, modeled when using other modeling methodologies, while in practice 4.4 Assets these are always present. Ā defines all assets that are available in a process. An asset is a In the Process Model (PM) it combines these transactions variable data-object. Properties that are relevant to the process to model a complete business process. The difference between must be defined. this model and a workflow is that in this model everybody Note that the scenario only defines the structure of assets. works in parallel as much as possible, specifying dependencies Assets can only be instantiated within the process. between transactions where needed. The models don’t give a clear overview of where we are in a process. Also, mutual exclusion of information (don’t edit a document that’s ready 5 DATA - OBJECTS to be signed) is not immersive but needs to be specified. Besides scenarios, other types of data-objects may be defined. DEMO might be a good way to make a high-level model, All data-objects, including scenarios, use JSON schema as a which yields a workflow that can then be fine-tuned. This type definition. Common examples are forms, documents, and reduces the reliance on deviations (see section 8.2). templates. Data-objects can be embedded in a process or linked and 4 S CENARIO stored independently. Linked objects are identified by the SHA256 hash of its JSON A workflow is defined as a data-object; the scenario. It consists representation. To ensure JSON encoding the data always yields of: the same result, a deterministic method of JSON encoding is • qx as a state with q0 as the initial state, applied. • Q as the set of all possible states Q = {q0 , ..., qn−1 },

6 5.1 Immutability 6.1 Inviting identities Data-objects are immutable to the extent that applying a mod- To add parties to a process, the scenario needs to define actions ification to a data-object, yields a new data-object. If this data to add other identities. If the public keys are known within the object is embedded in the process as an asset, the old object is process, the identity can be added directly. replaced with the modified one. When the public key is not known, the identity needs to be Importantly, if the same data-object is available in multiple invited (figure 4). This can be done through any means deemed processes, changing the object in one process will never propa- secure enough, including e-mail. The inviting system generates gate to other processes. a one-time key and sends it to the invited identity. The invited Failing to do so could lead to exploitable situations. Figure party must replace this with its own secure ’user’ and ’system’ 1 shows the process of negotiating and signing a document. It’s keys. clear that the document must not be allowed to be modified Before a new identity can fully participate in a process, during the signing sequence. additional authentication may be required. This can range from SMS verification to federated identity verification and even 5.2 Forms notary approval. A form definition uses a JSON Schema to define the data Initiate process structure that should result from filling out the form. Optionally q0 a UI Schema can be used to specify how a corresponding field may be rendered and displayed. Generate temporary key pair There are several similar implementations[35–38] for this. The aim is to work together with these projects to form a unified q1 standard. Send key pair to identity 5.3 Documents q2 Digital workflows can largely eliminate the need for paper doc- uments. However legal compliance, backward compatibility, Invitee replaces tempo- and simply convention may still require the use of documents. rary keys with own key By defining templates as part of the Live Contract, natural pair language documents can be generated using data gathered by the process. q3 We recommend using the Open Document Format[39], which supports fields and conditional sections for creating Fig. 4: Inviting an identity to join the process. templates. 6.2 Updating an identity 5.4 Custom types An identity is free to modify its own information, except for the Any JSON schema that defines an object can be used as a data- identifier. This also allows a party to switch to another node. In object type. Usage of custom types causes the risk of a workflow cases where a user should not be allowed to switch nodes, it’s not working properly as other parties may participate via a up to the node of the identity to reject that change. Removing node that doesn’t support that type. Data with unknown types an identity can be done by clearing the sign keys, encrypt key will be stored ”as is” and is unavailable outside of the context and node URI. of the process. Updating other identities is only possible if such an action is defined in the scenario and allowed in the current state. 6 I DENTITIES An identity defines a person, team or organization within a Live 7 P ROCESS Contract. An identity always has the following information: Where a scenario is the stateless definition of a workflow, the process is a stateful instantiation, consisting of: • identifier, • node URI, • θx as response, where f : qx 7→ θx • custom information, • Θ as an ordered list of all responses Θ = {θ0 , ...θn } • sign keys, • qt as the current state • an encrypt key. • I as set of all available actors • A as set of created assets Identities are not the same as actors. An actor is an abstract role like ’student’, an identity might be ’Bruce Willis’ or ’Acme corp’. 7.1 Actions Sign-keys is a map with one or more public keys associated Executing an action always yields a response. The response with the identity. The ’user’ key belongs to the identity and must be signed by the actor and submitted as a new event. can only be used by him/her to sign an action. The ’system’ Nodes independently determine the new state based on the key is owned by the node that the identity uses and is used to current state and the executed action. sign automated actions. Other key types may have a meaning The scenario is defined as a deterministic FSM. However defined within a process. this only concerns the state transitions and the projection. On The public encryption key can be used to encrypt data, that systems like Ethereum and Hyperledger, all logic must be can only be decrypted by this identity. deterministic, as it’s executed by all nodes and needs to yield identical results on all systems[40].

7 With LTO only a single node or a single actor executes an 7.7 Passive testing action, meaning actions do not need to be deterministic. As A scenario that contains a loop consisting exclusively of system such, concepts like oracles are not needed. actions could result in an infinite loop causing a massive amount of transactions. When validating, we want to reject 7.2 Manual actions scenarios that have such a construct. Applications built on the LTO platform must inform human Determining if a program can run forever is known as the actors which actions they may perform in the current state. A halting problem[41]. The problem has been proven unsolvable human actor will sign his own response event before submit- for Turing-complete machines. However, it can be solved for ting it to his node, which will distribute it to all parties. FSMs[42]. Since an FSM has a finite amount of transition paths, they can all be checked for loops. Passive tests for EFSM models are complicated by the 7.3 System actions presence of infeasible paths. This problem has been well- System actions do not require human interference but are documented but remains unsolved[19, 43]. For simplicity rea- executed by the node automatically. As such, the node signs sons, we can assume any path to be feasible by ignoring the the response, rather than the human user. conditions. We accept that this may cause false positives. These actions are always performed by a single system and do not have to be deterministic. Other parties validate the 8 A DAPTIVE WORKFLOWS response and can reject it if needed. Because there is no human A scenario will model the most typical cases of a process. It’s interference involved in system actions, the actions are signed impossible to foresee all situations in advance and tedious to by the system itself instead of the actor. model every possible edge case. Taking a code-is-law approach It’s also possible to schedule a system action to be executed would make the system rigid. Instead, Live Contracts supports at a later time. This is specified in the scenario. It allows three methods of resolving such issues. for a timeout on a state or polling an external source at a predetermined frequency. System actions are automatically executed and may yield 8.1 Comments an error when used incorrectly or when they fail otherwise. For Comments are used to communicate with other identities. these actions, not one but two state transitions must be defined. They can, for example, be used to resolve conflicts or conduct One for a successful execution and one in case of an error. discussions outside of the process. Using comments instead of off-chain communication methods makes sure that the conver- sations are logged on the blockchain. It also allows backtracking 7.4 Sub-processes to check when in the procedure certain conversations took A process based on an FSM can only be in one state at a time. place. Sub-processes allow a Live Contract to hold multiple states and Comments are not restricted to text messages. It is also make it possible for different procedures to be done in parallel. possible to use images or documents to assist in the commu- While these processes share an event chain, the data for each nication. Comments are not part of the process, meaning that process is still isolated. adding a comment does not trigger a state transition. This way To facilitate sub-processes, a Live Contract may contain sub- it is always possible to conduct a discussion about subjects that scenarios that can be instantiated from the main scenario. were not predefined in the procedure. 7.5 Projection 8.2 Deviation Besides the FSM state, the process also contains other stateful Any party may propose a deviation from the main flow by data in assets and actors. The payload of every response can be defining a partial scenario. This sub-flow must start from one used to update this data. The rules on how the payload updates of the states of an existing scenario and end in a state of that the data are defined in the scenario. Updating the projection is scenario. Deviation flows are only executed once as they are no deterministic and therefore applying a given set of responses longer available when the process returns to an existing state. against the scenario will always yield the same projection. All parties need to agree upon the deviation. Note that The projection can be used to set the parameters of an action. deviations might lead to forks that can only be resolved through It’s also the data for the conditions that make it an Extended manual conflict resolution. Finite State Machine. A deviation can be used to resolve disputes. Any party may propose it to dispute the correctness of a previous event and 7.6 Data operators present a solution on how to correct that. Another typical case of using deviations is a payment ar- Data operators may be used in the scenario for specifying how rangement. Organizations obviously don’t want to make that the projection affects the process. These operators are deter- option known at forehand. Predefined sub-flows allow such ministic functions without side effects. They can be used for arrangements while keeping them under wraps. arithmetic or logical operations. The result of these operations may be stored in the projection and can be used, for example, 8.3 Scenario update to base state transitions on. It may be required to change the scenario for a running process, for instance, when an agreement is updated or a new law is passed. A party may provide a new scenario for a given process through a deviation flow. This flow moves the state out of the outdated scenario and ends in a transition into the new scenario.

8 9 E VENT CHAIN 10.1 Private chain In order to determine the state of the FSM and the projection, The event chain is a private chain that is only shared between we need to process the set of responses in the given order. the nodes chosen by the identities. Nodes are not aware of Inserting or removing an event, changing the order of the private chains that they are not part of. events or modifying the payload might result in a radically A node stores and facilitates many event chains at the different state. same time. Unlike side chains, event chains are completely In a centralized solution, the controlling party is responsible isolated. Chains do not affect each other directly. This allows for data integrity. All parties rely on trust on this party to do for horizontal scaling, given that the activity per event chain is so, as it represents a single source of truth. In a decentralized reasonably low. system, this power and responsibility is shared among all parties. 10.2 Genesis To facilitate this, the event chain works like an ad hoc pri- vate blockchain. Each response is wrapped in an event, which Anybody may create a new event chain at will. The genesis can be viewed as a block with a single action. The sequence block of this chain contains the identity of the user that’s of these events form a hash chain that is shared between the creating the process, the subsequent block contains the scenario. parties. The consensus algorithm ensures the parties agree upon As part of the scenario, other identities will be invited to this the sequence of events. private blockchain. 9.1 Cryptographic signatures 11 C ONSENSUS MECHANISM To ensure nobody can falsify or forge events of others, each LTO is a distributed system, where all parties are able to event is signed before submitted using asymmetric cryptogra- participate via their own node. Nodes distribute all events to phy. The signed event also serves as a receipt, allowing other their peers, who process them. This means there is a brief parties to prove that the action has been executed by the signing moment where the state of the process between the nodes identity. differs. Eventual consistency[50] guarantees that, given that The platform uses ED25519[44] signatures. These elliptic- there is no new event submitted, eventually the state of the curve signatures are widely used, well supported and con- process on all nodes will be the same. sidered secure by institutions like NIST[45] and ENISA[46]. However, sometimes new events are submitted before con- Elliptic curve cryptography allows for faster single-signature sistency has been achieved. At this moment, it is possible that verification and signing without losing security. It also reduces two or more nodes append an event upon the event chain. Dur- the needed size of both the keys and the signatures. Note that ing a Byzantine failure[51], all nodes believe their information this method on itself doesn’t grant complete security, as any is valid. However, the overall system is in an inconsistent state. party is still able to falsify or forge their own events. In other In this state, nodes would no longer accept new events from words, cryptographic signatures can’t prove an event did not one another and need to be able to come to a consensus, rather occur. than halt. Distributed applications use a different kind of consensus algorithm for this. In general, this is a case of Byzantine fault 9.2 Hash chain tolerance (BFT). Early Byzantine fault tolerance methods do Each event can be uniquely identified using its SHA-2 256bit not scale well [52]. The invention of better scaling consensus hash. This industry standard algorithm is fast and resistant algorithms like proof-of-work [53], proof-of-stake [54] and proof- to pre-image and second-preimage attacks as well as colli- of-authorization [55] made it possible to create distributed net- sions[47]. It’s the recommended cryptographic hashing algo- works with a large number of participants, also called dis- rithm by NIST[48]. tributed ledger technology. Embedding the hash of the previous event in the hash of the While these consensus methods scale much better than next event creates a hash chain, which records the chronology traditional BFT methods, they have a need for a relatively high of the events. When used in combination with cryptographic amount of participants in order to be secure. The event chain is signatures, a hash chain provides an adequate measure of a private blockchain with relatively few participants, meaning proving that a specific sequence of events resulted in the current those algorithms won’t work. Rather than trusting on a majority state[49]. vote, nodes consider their state correct unless proven otherwise. 10 D ISTRIBUTION 11.1 Chance of a conflict Rather than requiring parties to pull information from a central Event chains rely on optimistic concurrency control. Many server or from each other, each party is responsible for pushing conflicts would put a strain on the consensus algorithm which events to the system of all other parties. can be relatively slow as it may have to wait on a block to be Systems need to be always available in order for events generated. not to get lost. Decoupling and the use of a message queue We define a distributed event chain as follows: reduce issues with temporary unavailability. In a typical case, • Let N be the set of entities {n1 , n2 , n3 , . . . } contributing all parties will connect to a node they trust which receives to the event chain. and processes events for them. This node is part of the larger • Let Cn be the event chain, a sequence consisting of system (see section 19.1). events (e1 , e2 , e3 , . . . ), belonging to entity n and let C With the focus on organizations and governments, it’s up be the set of all copies of the event chain {Cn |n ∈ N }. to these organizations to run a node. Users connect to the • Let’s define a conflict or branch as ∃ i, j ∈ N : i 6= node of their organization, or a publicly available node of their j, Ci0 = Cj0 , Ci 6⊂ Cj , Cj 6⊂ Ci . choosing, to participate in a process.

9 For a conflict to occur by accident, two parties must add a block conflict becomes more or less linear based on the network delay to their chain before they received the others chain update. and transaction frequency. Let’s call the chance of somebody propagating an update to By using individual shared nothing events chains with the chain P (x). This chance depends on the amount of blocks decoupled message queues, the transaction frequency will be being added to the chain during a given time frame, the time it very low. This marginalizes the chance on a conflict. takes to propagate this block to the rest of the network and the amount of entities contributing to the chain in this time frame. 11.2 Branch validation Assuming everybody contributes equally to the network this can be derived to formula (1) A node can only prove the other party was aware of the chain up to the point of its last event. Any party is allowed to branch f ·t the chain after their last commit. If a party tries to branch P (x) = (1) n the chain from a point before his last event, that branch is with: automatically discarded by all (other) parties and the event is f = Total amount of transactions / time frame logged. n = Total amount of active participants Before accepting the new events from the conflicting branch, t = Time it takes to propagate a block to the rest of the network they are validated similar to any received set of events; The event must be signed correctly by one of the identities and This chance can be used to calculate the probability that the event must be anchored where the timestamp of the event a conflict will occur. This probability is derived by subtracting matches that of the anchor within given boundaries. the chance of not having a conflict from 1. When there is no conflict it means either nobody has contributed to the chain 11.3 Cascading rules that moment, the chance of which is calculated in formula (2), In case of a conflict, the following rules are applied in this order (1 − P (x))n (2) • the priority of the event, or only one node contributed to the chain, the chance of which • the priority of the actor, is calculated in formula (3). • the order of anchoring. n−1 P (x) · (1 − P (x)) · n. (3) An action in the scenario may be given priority, this trans- lates to the event priority. Additionally, some other event types Therefore the chance of a conflict is calculated by (4). like comments have a lower priority as the exact sequence is P (c) = 1 − (1 − P (x))n − P (x) · (1 − P (x))n−1 · n. (4) not of any importance. In case of a conflict occurs, the block that contains the action with the highest priority will be accepted. With a network delay of 1200ms we see about chance on a In case the priority is the same, rules are applied based on conflict of < 2%: identity, creating different levels of authority within the process. Every actor in the scenario may be given a priority level. By default, this priority is the same for all actors. To resolve the ·10−2 conflict, the events added by the actor with the highest priority f = 10 must be accepted. Chance of conflict 2 f = 0.5 · n If both the events priorities and the identities authorities are the same, the third method of consensus is applied. Nodes must anchor events on the global blockchain. The order of transaction on this global blockchain is fixed in mined blocks. Therefore the 1 order in which the events have been anchored on the global blockchain can be used to achieve consensus. When this is the case, the block that was anchored first must be accepted. 0 As such, a consensus of the private event chain is reached 5 10 15 20 25 via consensus on the public blockchain. On the public chain, Number of active participants consensus is reached by anonymous collaboration between a large number of participants. Fig. 5: This plot shows how the chance of a conflict occurring Using priorities allows a front-running attack, where an increases when the number of participants increases. However, actor may respond upon an event by creating a new branch it stabilizes if the total number of transactions stays the same. that subsequently invalidates that action. Priorities should only be used where this is not a problem. Figure 5 shows that the chance of a conflict occurring is more or less constant when the number of participants increases 11.4 Unanchored events but the total number of transactions stay the same. However, when the number of participants increases usually the number When a block is received that has not been anchored yet, one of transactions increase as well. For example, more participants may decide to accept the block anyway. This is, of course, if no may lead to more comments. When this is the case, the chance conflict arises by accepting it. If the anchoring of the block has of a conflict increases exponentially with the number of partic- merely been delayed, accepting it would prevent unnecessary ipants. delays in the process itself. On the other hand, if the block is LTO works with very few active participants on a single never anchored, no real problems arise. If everybody accepts event chain. This reduces the chance of a conflict. With 5 the block, the process may continue as normal and the block or more participants, the number of active participants is no may be anchored later. longer relevant. With more than 10 participants the chance of a

10 11.5 Merging branches 12.2 GDPR In case of a fork, most blockchain applications will pick With the arrival of the new GDPR[58] (General Data Protection one chain and ignore everything that happened on the other Regulation) in Europe, an argument has risen about the fact that branches. With a blockchain like Bitcoin, all transactions will be a lot of blockchain applications are not GDPR compliant [59]. included in the mined blocks of each branch eventually. The two main reasons for this are: On the event chain, the events themselves build up the hash • the fact that the blockchains immutable nature is in chain. Picking one of the forks would lose information about conflict with the right to both amend and erase your an executed action. Instead, when a node becomes aware of data, another branch that has precedence over its own branch, it must • the fact that there is no dedicated data controller since it base the events it has locally on top of the other chain. This is is a distributed environment. similar to a rebase action when using git[56]. Linked data means that the node chosen by the party to 11.6 Forks participate will act as the data controller for that user. All other parties are always data processors. Data requests are Even though there is a guaranteed way to achieve consensus, a automatically formatted to be proper data agreements, which participating party might decide to ignore the other chains and include the purpose and time required for processing the data. keep the fork in place. For most blockchain applications, like Ad hoc blockchains allow the complete chain to be erased if Ethereum[57], there is no reason to interfere with this, as value required. comes from participating on the main chain only. In short, LTO privacy features make the solution GDPR Live Contracts are a tool to digitize and partly automate compliant without much additional effort. existing processes. Even though the blockchain allows for forks, those processes usually do not. In the case of a fork, parties can start a secondary procedure to try to resolve the conflict 12.3 Zero-knowledge proofs manually. A scenario may require one party to prove to another party that it knows a specific value. A zero-knowledge proof is a method 12 P RIVACY of doing so without conveying any information apart from the fact that it knows that value. LTO is built for running processes between parties. Beyond The platform supports zero-knowledge proofs through an these parties, no-one needs to be aware of the process or even interactive proof system. Two parties; the prover and the veri- the collaboration. fier exchange messages with the goal for the prover to convince Public blockchains allow anonymous accounts, however the verifier of its honesty (completeness) and for the verifier to these function as pseudonyms. Any transaction may reveal the expose a dishonest prover (soundness)[60]. identity of an account, exposing the full transaction history. A zk-proof for a Live Contract is always an action between Smart contracts require the data to be public as it needs to be two parties. There is no need for experimental non-interactive available for every node. On consortium blockchains, partici- zero-knowledge proofs like zkSNARKS. pants are aware of each other. Ad hoc private blockchains uniquely allow a random assortment of participants to collaborate without the need 13 C OMMON PATTERNS for approval and without making information public. These 13.1 Chain interaction blockchains can be completely erased when the process has Some processes may have to interact with other processes been completed. to be able to continue. Examples are when a process needs permission from another process to continue or to retrieve the 12.1 Linked data result of a conflict resolution process. Requesting data from Each party connects via its own node or a node it trusts. Each another process is done by following the pattern shown in node has a private storage service, where users can store data. figure 6. Users have complete control over data stored here, similar to data stored on a service like DropBox. They can remove their q0 q0 personal data at any time. The data is not shared or processed Request without a valid data processing agreement and explicit ap- Receive request Sent request proval of the user. When an action results in linked data, that data is not q1 q1 directly shared with other parties, only a hash is added to the blockchain. LTO prevents the hash from being used for Sent response Response Receive Response anything else than verifying received data, by putting it in an envelope together with a timestamp and some random data. q2 q2 The hash created to form the envelope will never occur on the blockchain more than once. Fig. 6: Pattern followed when two processes interact. When an organization indicates it wants to perform an action that requires linked data, the node of that organization will automatically do a request. The data owners node checks if 13.2 Explicit synchronization the specified action is valid and thus may indeed be performed In some cases, it can be especially troublesome if an event is by this actor in the current state. propagated too late. If this is the case, explicit synchronization can be built into the scenario. This requires all parties to acknowledge the current state before continuing the process.

11 This is a pattern within the FSM intended to prevent parties from forking the chain of events prior to this event. In case of a dispute or conflict, such an acknowledgment can be used to decide which branch should be used to continue the process. This kind of explicit synchronization only works if all par- ties acknowledge the current state. If some parties lack the incentive to continue or even have the incentive to fork the process, another solution is required. In this case, the party that wants to continue the process announces this to all other parties. If any party that receives this announcement notices that the announced action is not valid on their chain then they can propagate this. This means that a fork has happened and regular conflict resolution has to be applied. To remove the impact of network delays during this announcement, a set amount of time is waited before assuming that nobody rejected the announced event.

12 Part II. Global blockchain The LTO Global blockchain is a permissionless public 15.1 Leasing blockchain, purposely build for verifying information. It exists NXT, Waves and other blockchains in this family use Leased to support Live Contracts and the private event chains. The Proof of Stake[64, 70]. By leasing tokens, the token holder global blockchain features anchoring and digital identities that passes the right to forge a block to the selected node. These are interoperable across event chains, blockchains, and applica- nodes can work similar to a mining pool, sharing the rewards tions. proportionally among the lessors. Notary transactions can be done on nearly any blockchain. NXT style networks are susceptible to attack when an at- However, on blockchains optimized for financial transactions tacker controls at least 1/3 of all active balances[71]. This is an or general logic, notary type of transactions are expensive issue, as projects that have implemented the LPoS algorithm and inefficient[61]. Furthermore, optimizations as pruning and tend to lead to a high level of centralization. The top 2 Nxt sharding can have a negative effect as relevant information is nodes control over 50% of the network[72]. With Waves, the omitted[62, 63]. top 2 nodes control over 1/3 the network and the top 5 over The global blockchain is of the Nxt family[64]. A unique 50%[73]. characteristic of this blockchain is that transactions are based In section 18 we discuss the importance of a high amount on a series of core transaction types that do not require any of decentralization for this network. To prevent nodes with script processing or transaction input/output processing on massive leased stakes, there is a limitation on leveraging on the part of network nodes. This reduces the blockchain size, leased tokens. Any node needs to own at least 10% of the increases efficiency and allows ways of aggregation particularly tokens it stakes. Proof of Importance also counters this effect beneficial for notary transactions. as it disadvantages nodes that are passive stakers. Rather than starting from Nxt directly, we use a fork of the WAVES platform[65] as a basis. This platform has implemented a number of improvements, like the NG protocol (section 15.6), 15.2 Raffle factor that our network will benefit from. The existing transaction To calculate the usage of the network by the node, which types focusing on digital assets, including colored coins, are influences the chance to forge a block, the balance of staking removed or disabled and replaced by notary transaction types. versus transactions, the S/T-ratio will be used. 14 C ENTRALIZED VS DECENTRALIZED ANCHORING Staked tokens as % of total ST ratio = Contributed transactions as % of total Other solutions for blockchain anchoring use a centralized approach, where all hashes are collected for a period of time. The S/T-ratio is related to a ‘raffle factor’. The raffle factor is From these transactions, a Merkle tree is created which is put a mathematical formula that influences the chance that a node in a single transaction on a third party blockchain like Bitcoin. will be chosen to generate a new block. The more balanced Because of this, there is no direct feedback from the system the ST-ratio ( closer to 1.0), the higher the Raffle factor. If and it can take several hours before the final receipt can be the ST-ratio is unbalanced (a node does not contribute any collected[66] from the central service. transactions), the raffle factor will be 1.0. The LTO global blockchain is a decentralized solution, 2 where every node sees all transactions. When an anchoring raffle factor r = 1 + (0.5 · e−0.5·(ST ratio−1) ) transaction is broadcasted it’s instantly visible, and after ap- This formula results in a large standard deviation of the proximately 3 seconds it’s pre-approved using NG (section bell curve. 15.6). The transaction is in a block within a minute. Nodes can keep track of all anchored hashes or only of 1.6 their own. If needed they can create a receipt independently (section 16.1). There is no need for a centralized service. 1.4 raffle factor 15 C ONSENSUS ALGORITHM 1.2 The global blockchain functions as a typical public blockchain. A node is selected as a generator to validate the transactions 1 and forge a block. To determine a generator we use the Leased Proof of Importance (LPoI) consensus algorithm. The generator 0.8 is to be rewarded with the fees of the transactions in the forged 0 1 2 3 4 5 block. ST ratio Proof of Importance is a variation on Proof of Stake (PoS), The maximum raffle factor is 1.5, which is halfway between where the chance of being selected to forge a block is deter- the minimum and the absolute maximum of 2.0. The absolute mined based on the number of tokens you hold and stake. With maximum is determined by the possibility for importance Proof of Importance, the chance increases based on usage of the inflation through spam transactions. This is shown in detail in network by the node[67, 68]. section 18.1. The token economy that emerges from this consensus al- To fully understand the concept of the raffle factor and its effect on gorithm is described in detail in the ”LTO Token Economy” the token economy, please read the ”LTO Token Economy” paper[69]. paper[69].

13 15.3 Forge probability To combat this, as well as reduce the chance of forks, Fair The chance of being selected to forge is P (f orge) = S · r. PoS uses the generation signature of 100 blocks ago. Any The contributed transactions T are calculated over time. When change in balance on the node or in leases changes Ti for a calculating P (f orge), S must be constant over the same period given Xn . Nonetheless, any group controlling at least 1/3 of of time to prevent the possibility of abuse. the tokens can still get a 30% advantage. PoI requires the staked balance and raffle factor to be constant over a fixed period of blocks. This would make it even Start staking b c more vulnerable for such an attack. a Stop staking As a solution, the generation is not a hash that can be publicly calculated. Instead, a node must hash the previous generations signature and sign that hash with its private key. 1 2 3 4 5 6 This serves as a generation signature. Contrary to Nxt and Waves, a node can only calculate Ti for itself, making it im- a = Moment when P(forge) is calculated possible to determine the generators in advance. b = Moment when you forge a block 15.6 NG protocol c = Moment when tokens are still locked The NG protocol was proposed to reduce the scalability issues Fig. 7: Timeline for staking tokens and forging blocks. Time is on Bitcoin. While it was never implemented on Bitcoin, Waves measured in number of summary blocks. NG is active on their main net since December 2017. With NG, two type of blocks are generated; the micro block and the key block. The node that was previously elected 15.4 Fair PoS may continue validating transactions, creating micro blocks on The formula that decides which node is eligible to forge a new average every 3 seconds. When a new node is elected it creates block, is based on the Fair Proof of Stake algorithm[74] created a key block from the outstanding micro blocks. Transactions in by Waves. This is an improvement on the original Nxt PoS a micro block can be considered secure to some extent, and are algorithm, which overvalues higher stakes. suitable for low-risk transactions like anchoring. For a further understanding about the underlying algorithm, The reward of the transaction fees is split between the node please read the ”Fair Proof of Stake” paper[74]. that forged the micro block and the node that forged the key To convert this algorithm from PoS to PoI, the formula block in a 40% - 60% split. This split must always be in favor of applies the raffle factor to the staked balance to result in the the key block forger. Otherwise, there would be an incentive to effective balance as bi · r. disregard the already forged micro blocks and create new micro blocks yourself. • Ti as block generation time for i-th account, In a public stress test Waves’ NG has been proven to be able • Xn is the generation signature, to process up to 6000 Tx/min, with a peak of 17,000 Tx/min[75]. • r raffle factor, Potentially the NG protocol could handle up to 1000 Tx/sec or • bi percentage of staked vs total staked, 60,000 Tx/min. • Λn is the base target NG reduces practical latency and is a key component for • Tmin = 5 is a constant for delay between blocks, other optimizations. • C1 = 70, a constant defining shape of delay distribution, • C2 = 5E17 is a constant to adjust base target. 16 T RANSACTION TYPES log(Xn /Xmax ) The LTO global blockchain uses predefined transaction types. Ti = Tmin + C1 · log(1 − C2 · ) This allows for more compact blocks and removes the need for r · bi · Λn scripting. The list of transaction types may be extended in the If you receive a new block before the time delay is reached, future if needed. The types of transactions that are currently this block must be added to the chain and a new time delay possible are: must be calculated. The previous Ti is no longer relevant. Each node calculates Ti itself, this information is not supplied by a • Anchor: used to verify transaction from the private generator. This means that there is no point in using an incorrect blockchains, stake in the calculations. • Issue a certificate: used to declare relationships between identities, • Extend/revoke a certificate: used to extend or remove 15.5 Generator signature such a relationship, The block hash is never considered in determining the time • Transfer token: used to send tokens to another identity, delay Ti . That hash is based on the contents of the block, which • Stake tokens: used to let a participant stake or lease is determined by the node forging the block. If this hash played tokens, any part in determining who could forge the next, it would be • Cancel staking: used to stop staking or leasing tokens, trivial to manipulate Ti . A node could create several different • Set script transaction: used to configure smart accounts. blocks and only broadcast the one that has the lowest time for itself. To prevent this, only the generation signature is used. This 16.1 Anchoring signature is a secondary hash chain, using only the previous Anchoring is the method of taking a hash of a document or generation signature, plus the public key of the generator. With other data and storing it within a transaction on the blockchain. Nxt this is completely deterministic, making it susceptible to be The goal is to make it impossible for anyone, including the taken advantage of[71]. creator, to back-date or forward-date his document[76].

14 Every event of the private event chain is anchored onto mimics the chain of trust as done with PKI validation but the global blockchain. Third party applications may use the without the central authority. Rather than an absolute root global chain to anchor documents for proof of existence. We certificate, the blockchain address of our organization or an estimate that 99% of all transactions on the global chain will organization we do business with functions as trust root. be anchoring transactions. Considering that most transactions are for anchoring, aggregating these reduces the disk space 16.5 Smart accounts required by the blockchain. By default, any transaction for an account must be signed using When forging a block, a node creates a Merkle tree[77] the private key associated with the account. Waves introduced from the transactions in the order presented in the list. Only the concept of smart accounts, allowing anyone to customize the Merkle root is added to the blockchain. As part of the this logic[78]. validation, each node recreates this Merkle tree. To do so, this logic can be scripted using a Non-Turing Nodes are able to index every anchor hash. However, to complete language. This script is only used to verify or deny reduce disk size, most nodes should opt to extract the Merkle a transaction for a specific account. It cannot trigger other path of its own anchor transactions. This path forms the receipt transactions. As such, this type of smart contract does not that can be stored with the original data (like the event). prevent aggregation. A further limitation is placed on LTO smart accounts to ensure this. 16.2 Authentication and authorization LTO does not have data transactions, other transactions Challenge/response authentication methods, like username are not accessible from the script. You may validate whether and password verification, requires a centralized system. In a transaction has been signed by one or more other parties, a fully decentralized system, we rely on cryptographic signa- enabling multi-signature. Rather than specifying these accounts tures to provide authentication. While information isn’t shared directly, the requirement may reference a certificate instead. between the event chains, parties can still be identified across There are other limitations one might place on an account chains given the key pair used for signing. as well. An account can be locked, only allow the transfer of In a broader sense, parties can sign any type of information tokens after a number of blocks, require a minimum number this way. This is a similar use case as currently presented by of tokens to remain on the account or only allow transferring PKI certificates. The reliance on Central Authorities to issue tokens to specific accounts. and revoke certificates has hindered the adoption of it as a Anchoring transactions are an exception. They always need replacement for challenge/response authentication. to be signed with the private key of the account. This logic is in With public blockchains, public/private key pairs can be place to apply future optimizations and can’t be modified. created and used without the need for a central authority. A Using multi-signature is recommended when running a key pair forms a unique identity, which can be referenced via node. The account associated with the node typically holds a an address which is determined from the hash of the public key. large number of tokens in order to stake and anchor. The private key to this account is known to the node. With multi-signature, obtaining that key won’t give direct access to those tokens. 16.3 Certificates A certificate transaction allows any identity to convey informa- 17 S UMMARY BLOCKS tion about another identity by referencing its address. Unlike tokens, granting and revoking an account is fully under control Anchoring is a low-impact, non-disrupting method to bring of the issuer. an extra layer of security to the blockchain. We anticipate that The certificate can be given a specific type chosen by the other applications that do not use Live Contracts, will also use party that issued the certificate. While not required, it’s rec- the anchoring feature. ommended that a certificate is acknowledged by the recipient One aspect of the blockchain that counteracts scalability is account before displayed to others. the fact that the blockchain will keep growing[79]. The size puts certain requirements on the hardware to keep a copy. It also puts a burden on new nodes that have to play back the 16.4 Chain of trust whole chain. To reduce the growing speed of the chain, it uses While a public address with a private key pair is a method of summary blocks. authentication, it doesn’t provide a solution for authorization. Certificates can be used to specify relationships between iden- 17.1 Key block size tities. Table 3 shows the structure of a key block on the blockchain. This is a similar approach to the Web of Trust (WoT). The The global chain should be scalable up to 50 million transac- WoT has a number of drawbacks over PKI, which we do not tions per day. This is about five times the expected usage. The have on our platform. size of such a key block is determined by the block data and Establishing and revoking a relationship or marking an the transaction data (5). identity as compromised is simple, instant and irrevocable on the blockchain. Blockchain transactions are timestamped, Keyblock size = d + t (5) which allows for verifying the existence of relationships on a certain point in time. with: Rather than simply setting an identity, we set a specific d = block data, relationship. The transaction doesn’t confirm or deny any other t = transaction data. information about the identity except the existence of the re- lationship, removing the need of physically meeting the other Before calculating the expected blocksize, the following party. assumptions are made: In a given context, we only care about finding a chain of • 99.98% of the transactions are anchoring transactions trust between two identities based on this relationship. This (table 5). This is the main use of the global blockchain,

15 • The other 0.02% are issue certificate transactions (ta- The second to last summary block and all blocks before ble 7), that are final. Nodes will not consider forks before that point, • All other transactions are infrequent and can be ne- regardless of the longest chain. This means that only the trans- glected, actions of the previous 500 to 1000 key blocks have to be stored. • All transactions are uniformly distributed over the By removing transaction data from the key blocks after it has blocks, been stored in a summary block, key block size is reduced from • On average one key block per minute is generated, 11.3MB to 277 bytes, making them negligible compared to the • Every day 1440 key blocks are created. summary blocks. The block data is 277 bytes big (table 3). Under the assump- tions made previously, the size of the transaction data can be 17.5 Difference to pruning calculated by equation (6). At first glance, this approach has similarities to blockchain pruning, as you only maintain a limited set of transactions. The T ransaction data size = n · (0.9998 · a + 0.0002 · c) (6) danger with pruning is in the introduction of a falsified state, with: threatening the immutability nature. a = Size of an anchor transaction (table 5), The danger comes from distributing the state of the c = Size of an issue certificate transaction (table 7), blockchain. With segregated witness, transactions are applied n = Amount of transaction per block. without signature validation, relying on the concept of finality. Still, every node needs to apply all transactions from genesis to This makes the total size of a key block about 3.8MB. calculate the current state. The actual transaction data is not used to calculate the block’s signature but is rather stored as an attachment next to 17.2 Growth without aggregation the block (table 2). As events without transactions, key blocks With 3.8MB per block and 1440 blocks per day, the blockchain are part of the blockchain and can’t be ignored. If transactions would grow 5.47GB per day / 2TB per year, if the blockchain are applied without validation, aggregating them holds little would continuously run a full capacity. risk. The expected usage is on average 10 million transactions, growing the blockchain 1.1GB per day. This results in about 17.6 Summary block size 3.65 billion transaction or about 400GB per year. For Bitcoin, with 340 million transactions total[80], it takes Summary blocks contain all information about non-anchor about 7 days to synchronize from genesis, depending on net- transactions and an aggregated version of all the transaction work and hardware speed. fees and other token transfers. They are rather larger blocks, With billions of transactions, doing this naively could mean especially compared to the key blocks. To reduce the amount of waiting weeks or even months for the global blockchain to memory used, the transaction fees and token transfer transac- synchronize. tions get reduced to a balance change per participant (table (4)). One of the goals of aggregating transactions is to require Besides this aggregation, the summary will also contain the only 20 minutes of synchronization per year, again depending other transactions. To calculate the expected size of a summary on network and hardware speed. With 365 summery blocks in a block, the following assumptions are made: year, a node should be able to process a summery block within • There is a total of 200000 participants, 3 seconds. • Every day 1 summary block is created, • Based on the assumptions in the previous section we 17.3 Segregated witness can assume that the balance change summary is the only Segregated witness is a strategy employed in Bitcoin to reduce significant part of a summary block. the data in a block[81] by separating a transaction into data that Using these assumptions, the size of a summary block can needs to be processed and data to verify the transaction in the be calculated. Using equation 7, this results in about 10.3MB. block. This second part is called the witness data, containing signatures amongst other things. Finality is the guarantee that blocks that are sufficiently Summary block size = T ransaction summary = p · e (7) deep will never be removed from the blockchain. Regardless with: of probabilistic finality or protocol finality, witness data is no p = Amount of participants in the last 1500 blocks, longer useful if the block is guaranteed to not be reverted. e = Size of a balance change summary entry (table 4. Nodes are free to remove witness data for blocks that reached finality, saving disk space. We’ve built on the logic of segregated witness for the concept of summary blocks. 17.7 Total size The total size of the blockchain consists of two parts. A static 17.4 Aggregation part and a growing part. The static part consists of the last 1000 Aggregation blocks are special blocks that are created every key blocks . Those will still contain the attachment data (5). 1440 blocks (about once a day). They contain aggregated values of all the blocks since the previous summary block. When Static part = n · k (8) replaying the chain, only the summary blocks need to be with: applied to get close to the current state. After this, only the n = Amount of keyblocks stored with transaction data, blocks created after the last summary block still have to be k = Size of a keyblock (5). replayed. This decreases the replay time significantly.

16 Using equation 8 results in the total size of the static part to no costs is undesirable, as it could aid an attacker trying to being about 11.3GB. Because only the last 1000 blocks are undermine the network with a 51% attack. The maximum raffle stored completely, which means including transactions, this factor of 1.5 ensures a high cost of inflating importance. size may differ slightly, but won’t grow noticeably. The growing part consists of the summary blocks (7) and 18.2 Nothing at stake what is left of the key blocks after the transaction data is removed. We’ll define the size as growth per year using equa- The nothing at stake principle is the assumption that nodes tion (9). will continue to build on any forks, rather than picking the Growing part = n · k + m · s (9) longest chain, as there is no downside in doing so[82]. If all nodes would display such ill behavior, an attacker would only with: need a small percentage of tokens to force the network to switch n = Number of keyblocks per year, to the other chain; a 1% attack. m = Number of summaryblocks per year, Such a situation is a Tragedy Of The Commons[83]. All k = Size of a keyblock without transaction data, parties seek individual gain by abusing the system. But if s = Size of a summaryblock (7). everybody is doing it, nobody benefits. Instead, it only leads to undermining the network, causing a decrease in the value of Still following the previously made assumptions this result in the underlying token. the blockchain growing about 3.7GB per year. Waves Fair PoS has made it a lot more difficult for an unpub- lished orphaned branch to catch up with the main branch[74]. 17.8 History nodes The possibility of profiting from such behavior with bad actors that only hold a small percentage of tokens is neglectable. Nodes are not required to delete old transactions. By main- A bad actor would need to create and maintain an altered taining all transactions, history nodes are able to prove the version of the node. The costs combined with the knowledge correctness of the blockchain in case it’s needed. History nodes that there is little chance of benefiting from it, should be enough are unable to pass a falsified history, as the blocks of the history to disincentivize this behavior[84]. node need to match those of other nodes. The network could rely on a relatively small amount of history nodes. There is no on-chain benefit of running a history node. It 18.3 LPoS centralization doesn’t increase the chance of forging new blocks. Running Projects that have implemented LPoS algorithm tend to lead to such a node must be done out of community interest or sec- a high level of centralization. ondary income. This effect can be explained by the reward per token. A professional setup with a near 100% uptime will not miss a 18 N ETWORK VULNERABILITY forging opportunity, yielding more reward with a set amount of tokens being staked. This draws token holders to lease to 18.1 Importance inflation these nodes and has a reinforcing effect as reduced overhead A particular worry with PoI is the inflation of importance allows for higher payouts to lessors. through dummy transactions. We can calculate the profit/loss Limiting the number of tokens per node is a flawed method from spam transactions as a formula of the maximum raffle enabling the opportunity for a Sybil attack[85]. In a permission- factor; less reputation system, a single node can advert itself as multi- • Raffle factor; r, ple pseudonymous identities, circumventing this limitation. • Percentage of staked tokens; bi , The nature of our solution means a majority of transactions • Cost of a transaction; c, will be signed by a key pair associated with a node. The • Total transactions on network; n, network will also consist of a relatively large number of nodes. • Spam transactions; τ , This has no effect on PoS, while on PoI this gives the platform • Rewards; p, users an advantage over non-user token holders. • Profit/loss from spam; ∆p = prmax − pr=1 . An additional measure is a limitation on leveraging on leased tokens; any node needs to own at least 10% of the tokens it stakes. p = (r · bi · n · c) − (τ · c) (10) r = 1, τ = 0 → p = bi · n · c (11) 18.4 Denial of service attack r = rmax , τ = bi · n → (rmax − 1) · bi · n · c (12) Due to the limited scalability, it’s fairly easy to overload any public blockchain with too many transactions. Transaction fees This gives are the primary defense against these sorts of attacks, but ∆p = ((rmax − 2) · bi · n · c) (13) transactions still need to be verified to conclude there are insufficient funds. Even more, with a decent amount of funds, Given it’s possible to overload the network with spam transactions as seen with Ethereum in July 2018. bi > 0, n > 0, c > 0, ∆p < 0 → (rmax − 2) < 0 (14) Nodes have the option to automatically increase the trans- actions fees in case of such an attachment. Ideally, nodes gain rmax < 2 (15) as much from staking as is spend on transactions. As the spam Equation 15 proves that it’s impossible to gain directly from tokens increase the rewards of transaction fees, this is used to spam transactions, with a maximum raffle factor of less than automatically counter the attack. two. A raffle factor close to two would make spam transactions nearly free. Increasing the importance of the network for little

17 18.5 SHA-2 vulnerability In 2017 SHA-1 was proven to be vulnerable when the Google research lab managed to find a collision where two different documents resulted in the same hash[86]. If SHA-2 256bit would have a similar vulnerability this could be devastating for anchoring based on a Merkle tree. If a collision is found, one can claim that the colliding document has been notarized. Even worse, given a Merkle root and a random hash, one might be able to generate a valid Merkle path. That would allow a hacker to verify any document. This would still not be a trivial task as for every branch in the tree, two hashes need to be combined that are exactly 32 bytes long. While bruteforcing a specific SHA-1 would still require too many computations to achieve in a lifetime, the birthday paradox results in much fewer computations being required to find a collision. The birthday paradox also applies to the LTO public chain, as there are many Merkle roots, each with a maximum number of Merkle paths. To overcome this, verification might fall back to history nodes in case the verification is disputed. However, this reduces the overall uses of anchoring nodes. Instead a secondary Merkle tree might be added where the SHA-2 hash is hashed with another algorithm like SHA-3 or Blake2. Simply double hashing isn’t useful when it’s possible to falsify a Merkle, as only a vulnerability in the outer algorithm is required for an exploit. However, if there are two Merkle trees, both algorithms would need to be broken. Even then, a collision needs to be found for both trees of a single block, removing the birthday paradox advantage.

18 Part III. Platform 19 A RCHITECTURE 21.2 Workflow engine 19.1 Micro architecture The actual creation and execution of the Live Contracts are done The LTO node is developed using the microservices architecture by the Workflow Service. If an event received by the Event pattern. This means that all functionality within the node is split Chain Service contains an action in the Live Contract it will into microservices, with each service being responsible for only be sent to the Workflow Service. The Workflow Service will a small part of the entire node. There are several advantages to execute the action which will lead to a state transition in the this pattern: workflow and a new projection of the workflow. This projection is stored in a MongoDB database. • Failure isolation, if a service fails it won’t necessarily interfere with other services. • Scalability, all the services within the node are decou- 22 P RIVATE CHAIN LAYER pled and can therefore run on different machines. This The private chain layer decouples the node. Decoupling ensures makes it really suitable for horizontal scaling. The scal- a stable system even in case of bad connectivity or high load. ing is automated, which can be found in the description The message queue is the communication layer for the private in section 24 chain. The technology providing the message queue will be • Flexibility, certain functionality flourishes better in cer- RabbitMQ. RabbitMQ is a lightweight message broker which is tain programming languages. Each service can be devel- perfectly suited to deliver messages within the node but also oped in a different programming language. to other nodes. RabbitMQ has a function called the Shovel. • Code quality, by splitting the node into small and well- A Shovel will dynamically setup a connection with another defined modules it becomes easier for developers to read RabbitMQ broker and exchanges messages. This mechanism is and review. This leads to better code quality. used to send events from one node to another. The microservices are grouped in a docker container. All Three services manage all inbound and outbound events. these containers are run using the Kubernetes container or- chestration platform. This will be described in section 24. Each 22.1 EventChain service microservice is designed to run independently. This means it has no shared dependencies, so each container has it’s own The service which manages the private chains is the Event database or event queue. Microservices are also designed to Chain service. This service processes all incoming events. Dur- operate statelessly, so they are easily scalable. ing this processing of events the services take the following steps: 19.2 Application layers and services • Validate the incoming event(s), by checking if it’s cor- As described in section 19.1 the node is split up into several rectly signed and if the chain isn’t broken. services. The services are grouped into 4 different layers. The • Validate if the chain matches the locally stored chain. If node consists of the following layers: not, it performs conflict resolution where possible. • UI Layer: this consists of UI applications that interact • If the event(s) are sent by the identity that belongs to this with the application layer, node it will execute the received event(s). Otherwise, it • Application layer: contains all the services that handle will only store them in the database. actions triggered by events from the event chain, • If a new identity is added from a different node, the • Private chain layer: takes care of the decoupling of the whole chain is forwarded to this node. node, • All the new events are forwarded to the related nodes. • Public chain layer: manages the public chain service. Our global public blockchain is optimized for storing For storage, the Event Chain service uses a MongoDB hashes. Each node indexes all hashes, so they can be database. easily verified. 22.2 Event enqueue service 20 UI L AYER The Event Enqueue service has the small task of putting events The UI layer contains two frontend applications which enable in the event queue. It does this both from services within the users to easily develop and debug their Live Contracts. First node (e.g. the Workflow Service and the Event Service) as well is the Chain Viewer. The chain viewer allows users to connect as from external users. to a specific node and list all the chains. The user can only list and view chains of which he is a part. The second application 22.3 Event dispatch service is the playground application. The playground application lets users develop Live Contract scenarios. It visualizes the scenario All messages in the event queue are handled by the Event in a state diagram and it contains other visualization and Dispatch Service. It picks up all the messages and distributes verification tools. them to the Event Service. If the Event Service processes the message it will be marked as handled. Otherwise it will be 21 A PPLICATION L AYER moved to the dead-letter queue. 21.1 Web server The web server application serves as a proxy between the front- end and the applications within the node. The web server performs two functions: • Authentication of all requests to the services • Proxies all requests to the correct service

19 23 P UBLIC CHAIN LAYER 23.1 Anchor service The Anchor service is at the heart of the public chain. The Anchor service will be a fork of the NXT platform extended with NG protocol. The Anchor service will be extended so it will not only be able to handle ’normal’ transactions but also data transactions. These data transactions will be used to store hashes from events on the private chains as is described in section 16.1. All these hashes will be collected daily and merged deterministically into a Merkle Tree. This way the data transactions can be removed from storage to reduce the storage footprint but people are still able to verify whether the hash existed. To be able to verify whether a certain hash is stored, all the hashes will be indexed. This way verification is much faster because you won’t have to search through all the data transactions. 24 C ONTAINER ORCHESTRATION Since the node is build up out of multiple microservices, a container orchestration platform is required to manage the running of the containers. Container orchestration platforms take care of a few tasks such as provisioning hosts, instantiating containers, restarting failed containers, scaling the cluster by adding or removing containers. Different container orchestra- tion tools can be used for this purpose like Docker Swarm, Mesos, Nomad or Kubernetes. Initially, a configuration file will be included for Kubernetes. Each service will be configured to run in its own Pod with its own load balancer. This is done so individual services can scale independently of each other. Scaling of services is managed using the Horizontal Pod Autoscaler [87].

REFERENCES 20 R EFERENCES [21] G Pace and J Schapachnik. “Contracts for Interacting [1] Hannah Ritchie Max Roser. Technological Progress. https: Two-Party Systems”. In: (2012). / / www. ft . com / content / cb56d86c - 88d6 - 11e7 - afd2 - [22] Mark D. Flood and Oliver R Goodenough. “Contract as 74b8ecd34d3b. Accessed: 03-06-2018. 2017. Automaton: The Computational Representation of Finan- [2] Christine Legner and Kristin Wende. “The challenges of cial Agreements”. In: (2015). inter-organizational business process design – a research [23] Davide Basile, Pierpaolo Degano, and Gian-Luigi Ferrari. agenda”. In: (2007). “Automata for Service Contracts”. In: (2014). [3] Benjamin E. Hermalin and Michael L. Katz. “Moral Haz- [24] Pierpaolo Degano Davide Basile and Gian-Luigi Ferrari. ard and Verifiability: The Effects of Renegotiation in “From Orchestration to Choreography through Contract Agency”. In: (1990). Automata”. In: (2014). [4] Audun Jøsang. “The right type of trust for distributed [25] Ian Ayres and Robert Gertner. “Filling Gaps in Incom- systems”. In: Proceedings of the 1996 workshop on New plete Contracts: An Economic Theory of Default Rules”. security paradigms. ACM. 1996, pp. 119–131. In: (1989). [5] Israel Z Ben-Shaul and Gail E Kaiser. “A paradigm for [26] Jan L.G. Dietz. “Understanding and Modeling Business decentralized process modeling and its realization in the Processes with DEMO”. In: (1999). oz environment”. In: Proceedings of the 16th international [27] YoungJoon Byun, Beverly A. Sanders, and Chang-Sup conference on Software engineering. IEEE Computer Society Keum. “Design Patterns of Communicating Extended Press. 1994, pp. 179–188. Finite State Machines in SDL”. In: (2001). [6] Ray Fisman and Roberta Gatti. “Bargaining for bribes: [28] Petri. “Kommunikation mit Automaten”. In: (1962). The role of institutions”. In: International handbook on the [29] Dennis Kafura. Notes on Petri Nets. http : / / people . cs . economics of corruption (2006), pp. 127–139. vt.edu/kafura/ComputationalThinking/Class - Notes/ [7] Jörg Becker, Michael Rosemann, and Christoph Von Uth- Petri-Net-Notes-Expanded.pdf. Accessed: 01-09-2018. mann. “Guidelines of business process modeling”. In: [30] Wil M.P. van der Aalst. “The Application of Petri Nets to Business Process Management. Springer, 2000, pp. 30–49. Workflow Management”. In: (1998). [8] Manfred Reichert, Thomas Bauer, and Peter Dadam. [31] Jan Recker et al. “How good is bpmn really? Insights from “Enterprise-wide and cross-enterprise workflow manage- theory and practice”. In: (2006). ment: Challenges and research issues for adaptive work- [32] Wil M.P. van der Aalst et al. “Life After BPEL?” In: (2005). flows”. In: (1999). [33] Luciano Garcı́a-Bañuelos et al. “Optimized Execution of [9] Vitalik Buterin. “Ethereum White Paper: A Next- Business Processes on Blockchain”. In: (2017). Generation Smart Contract and Decentralized Applica- [34] Jan L.G. Dietz. “DEMO: Towards a discipline of organi- tion Platform”. In: (2013). sation engineering”. In: (1999). [10] Vitalik Buterin and Karthik Gollapudi. A Next-Generation [35] JSONForms - React. https://jsonforms.io/. Accessed: 30- Smart Contract and Decentralized Application Platform. 08-2018. https : / / github . com / ethereum / wiki / wiki / White - [36] JSONForm - Bootstrap 3. https://github.com/jsonform/ Paper / f18902f4e7fb21dc92b37e8a0963eec4b3f4793a. Ac- jsonform. Accessed: 30-08-2018. cessed: 22-05-2018. [37] Mozilla react-jsonschema-form. https : / / github . com / [11] Ian Grigg. “The Ricardian Contract”. In: (2004). mozilla- services/react- jsonschema- form. Accessed: 30- [12] Nick Sabo. “Formalizing and Securing Relationships on 08-2018. Public Networks”. In: (1997). [38] Angular Schema Form. http://schemaform.io/. Accessed: [13] Telser. “A Theory of Self-Enforcing Agreements”. In: 30-08-2018. (1980). [39] Open Document Format. http : / / www . [14] David Joulfaian Douglas Holtz-Eakin and Harvey S. opendocumentformat.org/. Accessed: 30-08-2018. Rosen. “Sticking it out: entrepreneurial survival and liq- [40] Sindhu Sajana and Sethumadhavan. “On Blockchain uidity constraints”. In: (1993). Applications: Hyperledger Fabric And Ethereum”. In: [15] Toshi wallet now supports ERC20 tokens and ERC721 col- (2018). lectibles. https : / / blog . toshi . org / toshi - wallet - [41] Stephen A Cook. “The complexity of theorem-proving now - supports - erc20 - tokens - and - erc721 - collectibles - procedures”. In: Proceedings of the third annual ACM sym- e718775895aa. Accessed: 30-08-2018. posium on Theory of computing. ACM. 1971, pp. 151–158. [16] ERC-20 Token Standard. https://eips.ethereum.org/EIPS/ [42] Daniel Brand and Pitro Zafiropulo. “On communicating eip-20. Accessed: 30-08-2018. finite-state machines”. In: Journal of the ACM (JACM) 30.2 [17] Daniel IA Cohen and Daniel IA Cohen. Introduction to (1983), pp. 323–342. computer theory. Vol. 2. Wiley New York, 1991. [43] Robert M Hierons AbdulSalam Kalaji and Stephen Swift. [18] Marko Vukolić. “Rethinking permissioned blockchains”. “New approaches for passive testing using an Extended In: Proceedings of the ACM Workshop on Blockchain, Cryp- Finite State Machine specification”. In: (2003). tocurrencies and Contracts. ACM. 2017, pp. 3–7. [44] O Sury and R Edmonds. Edwards-Curve Digital Security [19] AbdulSalam Kalaji, Rob Mark Hierons, and Stephen Algorithm (EdDSA) for DNSSEC. Tech. rep. 2017. Swift. “A search-based approach for automatic test gen- [45] NIST. Transition Plans for Key Establishment Schemes using eration from extended finite state machine (EFSM)”. In: Public Key Cryptography. https : / / csrc . nist . gov / News / Testing: Academic and Industrial Conference-Practice and 2017/Transition- Plans- for- Key- Establishment- Schemes. Research Techniques, 2009. TAIC PART’09. IEEE. 2009, Accessed: 13-07-2018. 2017. pp. 131–132. [46] Daniel J. Bernstein et al. “High-speed high-security signa- [20] M.G. Gouda, E.G. Manning, and Y.T. Yu. “On the Progress tures”. In: Journal of Cryptographic Engineering 2.2 (2012), of Communication between Two Finite State Machines”. pp. 77–89. ISSN: 2190-8516. DOI: 10 . 1007 / s13389 - 012 - In: (1984). 0027-1. URL: https://doi.org/10.1007/s13389-012-0027- 1.

21 [47] Henri Gilbert and Helena Handschuh. “Security analysis [68] NEM. NEM technical reference. https : / / nem . io / wp - of SHA-256 and sisters”. In: International workshop on content / themes / nem / files / NEM techRef . pdf. Ac- selected areas in cryptography. Springer. 2003, pp. 175–193. cessed: 13-07-2018. 2018. [48] NIST. NIST Policy on Hash Functions. https://csrc.nist. [69] LTO. “LTO Token Economy”. In: (2018). gov/Projects/Hash- Functions/NIST- Policy- on- Hash- [70] Waves Platform. Blockchain Leasing For Proof Of Stake. Functions. Accessed: 13-07-2018. 2015. https : / / blog . wavesplatform . com / blockchain - leasing - [49] Bruce Schneier and John Kelsey. “Cryptographic Support for- proof- of- stake- bac5335de049. Accessed: 13-07-2018. for Secure Logs on Untrusted Machines.” In: USENIX 2018. Security Symposium. Vol. 98. 1998, pp. 53–62. [71] mthcl. “The math of Nxt forging”. In: (2014). [50] Peter Bailis and Ali Ghodsi. “Eventual consistency to- [72] Waves generators. http://dev.pywaves.org/generators/. day: Limitations, extensions, and beyond”. In: Queue 11.3 Accessed: 28-08-2018. (2013), p. 20. [73] Nxt Blockchain Explorer. https://nxtportal.org/monitor/. [51] Andrew S Tanenbaum and Maarten Van Steen. Distributed Accessed: 28-08-2018. systems: principles and paradigms. Prentice-Hall, 2007. [74] Kofman Begicheva. “Fair Proof of Stake”. In: (2018). [52] Miguel Castro and Barbara Liskov. Byzantine fault toler- [75] Waves-NG stress test: results in! https : / / blog . ance. US Patent 6,671,821. 2003. wavesplatform . com / waves - ng - stress - test - results - in - [53] Satoshi Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash 44090f59bb15. Accessed: 05-09-2018. System. https://bitcoin.org/bitcoin.pdf. Accessed: 17-05- [76] S. Haber and W.S. J Stornetta. “How to time-stamp a 2018. digital document”. In: (1991). [54] Aggelos Kiayias et al. “Ouroboros: A provably secure [77] Ralph C. Merkle. “Method of providing digital signa- proof-of-stake blockchain protocol”. In: Annual Interna- tures”. U.S. pat. 4309569. Jan. 5, 1982. tional Cryptology Conference. Springer. 2017, pp. 357–388. [78] A. Begicheva and I. Smagin. “RIDE: a Smart Contract [55] POA Network. Proof of Authority: consensus model with Language for Waves”. Pat. 2018. Identity at Stake. https : / / medium . com / poa - network / [79] Saifedean Ammous. “Blockchain Technology: What is it proof- of- authority- consensus- model- with- identity- at- good for?” In: (2016). stake-d5bd15463256. Accessed: 17-05-2018. [80] Blockchain number of transaction. https://www.blockchain. [56] Git Documentation. Git Branching - Rebasing. https : / / com / en / charts / n - transactions - total. Accessed: 05-09- git - scm . com / book / en / v2 / Git - Branching - Rebasing. 2018. Accessed: 09-08-2018. [81] BIP 141: Segregated Witness (Consensus layer). https : / / [57] Aaron van Wirdum. “Rejecting Today’s Hard Fork, the github . com / bitcoin / bips / blob / master / bip - 0141 . Ethereum Classic Project Continues on the Original mediawiki. Accessed: 05-09-2018. Chain: Here’s Why”. In: Bitcoin Magazine 20 (2016). [82] Problems Ethereum. https://github.com/ethereum/wiki/ [58] European Parliament. REGULATION (EU) 2016/679 OF wiki/Problems. Accessed: 30-08-2018. THE EUROPEAN PARLIAMENT AND OF THE COUN- [83] G Hardin. “The Tragedy of the Common”. In: (1969). CIL: on the protection of natural persons with regard to the [84] Nothing considered a look at nothing at stake vulnerabil- processing of personal data and on the free movement of ity for cryptocurrencies. https : / / pivx . org / nothing - such data, and repealing Directive 95/46/EC (General Data considered - a - look - at - nothing - at - stake - vulnerability - Protection Regulation). https://eur- lex.europa.eu/legal- for-cryptocurrencies/. Accessed: 30-08-2018. content / EN / TXT / HTML / ?uri = CELEX : 32016R0679 & [85] John R Douceur. “The sybil attack”. In: International work- from=EN. Accessed: 12-07-2018. 2016. shop on peer-to-peer systems. Springer. 2002, pp. 251–260. [59] Olly Jackson. “Is it possible to comply with GDPR using [86] Marc Stevens et al. “The first collision for full SHA-1”. In: blockchain?” In: International Financial Law Review (2018). (2017). [60] S Goldwasser, S Micali, and C Rackoff. “The knowledge [87] Kubernetes. Kubernetes, Horizontal Pod Autoscaling. https: complexity of interactive proof systems”. In: (1989). //github.com/kubernetes/community/blob/master/ [61] Blockchain costs per transaction. https://www.blockchain. contributors/design- proposals/autoscaling/horizontal- com/charts/cost-per-transaction. Accessed: 05-09-2018. pod-autoscaler.md. Accessed: 03-08-2018. [62] Emanuel Palm. Implications and Impact of Blockchain Trans- action Pruning. 2017. [63] Wenting Li et al. “Towards scalable and private indus- trial blockchains”. In: Proceedings of the ACM Workshop on Blockchain, Cryptocurrencies and Contracts. ACM. 2017, pp. 9–14. [64] Serguei Popov. “A probabilistic analysis of the nxt forg- ing algorithm”. In: Ledger 1 (2016), pp. 69–83. [65] Waves platform. WAVES whitepaper. https : / / blog . wavesplatform . com / waves - whitepaper- 164dd6ca6a23. Accessed: 16-07-2018. 2016. [66] Chainpoint Node API: How to Create a Chainpoint Proof. https://github.com/chainpoint/chainpoint-node/wiki/ Chainpoint- Node- API:- How- to- Create- a- Chainpoint- Proof. Accessed: 05-09-2018. [67] Gleb Kostarev. Review of blockchain consensus mechanisms. https://blog.wavesplatform.com/review-of-blockchain- consensus - mechanisms - f575afae38f2. Accessed: 13-07- 2018. 2017.

22 # Field Name Length 1 Version 1 2 Timestamp 8 3 Parent block signature 64 4 Consensus block length 4 5 Base target 8 6 Generation Signature 32 7 Transaction list Hash 32 8 Anchor Merkle root 32 9 Generator public key 32 10 Block’s signature 64 TABLE 1: Key block structure # Field Name Length 1 Amount of transactions (x) 4 2 Transaction #1 bytes 113 ··· ··· ··· 2 + (K - 1) Transaction #K bytes 113 TABLE 2: Key block attachment # Field Name Length 1 Version 1 2 Timestamp 8 3 Parent block signature 64 4 Consensus block length 4 5 Base target 8 6 Generation Signature 32 7 Transaction list Hash 32 8 Transaction #1 bytes TODO ··· ··· ··· 8 + (K − 1) Transaction #K bytes TODO 9 + (K − 1) Balance change summary entry #1 40 (Table 4) ··· ··· ··· 9 + (K − 1) + (N − 1) Balance change summary entry #N 40 (Table 4) 10 + (K − 1) + (N − 1) Generator public key 32 11 + (K − 1) + (N − 1) Block’s signature 64 TABLE 3: Summary Block structure # Field Name Length 2 Wallet address 32 3 Balance change 8 TABLE 4: Balance summary entry # Field Name Length 1 Transaction type 1 2 Anchor hash 32 3 Fee 8 4 Timestamp 8 5 Signature 64 TABLE 5: Anchor transactions structure # Field Name Length 1 Transaction type 1 2 Sending address 32 3 Receiving address 32 4 Amount 8 5 Fee 8 6 Timestamp 8 7 Signature 64 TABLE 6: Transfer transaction structure

23 # Field Name Length 1 Transaction type 1 2 Id 32 3 Sending address 32 4 Receiving address 32 5 Expiration Date 8 6 Certificate Type 32 7 Fee 8 8 Timestamp 8 9 Signature 64 TABLE 7: Issue certificate transaction structure # Field Name Length 1 Transaction type 1 2 Id 32 3 New expiration Date 8 4 Fee 8 5 Timestamp 8 6 Signature 64 TABLE 8: Update certificate transaction structure # Field Name Length 1 Transaction type 1 2 Sending address 32 3 Receiving address 32 4 Amount 8 5 Fee 8 6 Timestamp 8 7 Signature 64 TABLE 9: Lease transaction structure # Field Name Length 1 Transaction type 1 2 Sending address 32 3 Receiving address 32 4 Amount 8 5 Fee 8 6 Timestamp 8 7 Signature 64 TABLE 10: Cancel Lease transaction structure