LTO.

network
Blockchain for Decentralized Workflows

www.lto.network

F
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