Distributed Ledger Technology, Cyber-Physical Systems, and Social Compliance

Distributed Ledger Technology, Cyber-Physical Systems, and Social Compliance

Abstract

This paper describes how Distributed Ledger Technologies can be used to design a class of cyber-physical systems, as well as to enforce social contracts and to orchestrate the behaviour of agents trying to access a shared resource. The first part of the paper analyses the advantages and disadvantages of using Distributed Ledger Technologies architectures to implement certain control systems in an Internet of Things (IoT) setting, and then focuses on a specific type of DLT based on a Directed Acyclic Graph. In this setting we propose a set of delay differential equations to describe the dynamical behaviour of the Tangle, an IoT-inspired Directed Acyclic Graph designed for the cryptocurrency IOTA. The second part proposes an application of Distributed Ledger Technologies as a mechanism for dynamic deposit pricing, wherein the deposit of digital currency is used to orchestrate access to a network of shared resources. The pricing signal is used as a mechanism to enforce the desired level of compliance according to a predetermined set of rules. After presenting an illustrative example, we analyze the control system and provide sufficient conditions for the stability of the network.

\newremark

remarkRemark

I Introductory remarks

Bitcoin, and the technology that underpins it, Blockchain, have recently become a souce of great debate and controversy in both business and scientific communities. To its supporters, Distributed Ledger Technology (DLT) (the agnostic term for Blockchain and related technologies) is a key technology that will unlock new disruptive business models such as peer to peer trading, protect the rights of individuals, democratise society, and remove the need for central arbiters in many applications (the greedy middle that manages and exploits our assets and identities for financial reward). To its detractors, DLT is nothing more than pure hype, irrational speculation, and a means to enable new forms of illegality built on the anonymity that underpins the technology. DLT as a technology is truly unparalleled in its ability to split and divide opinions. Countries such as Switzerland and Singapore are openly embracing its potential, while other countries, such as China and India are trying to regulate its use [1]. Leading societal thinkers are also split on DLT; with George Soros1 thinking it to be nothing more than a bubble and others such as Al Gore embracing the idea that algorithms might one day assume some of the functions of government2.

Though the schism in DLT thinking is very real, everyone seems to agree on one basic fact - that DLT is potentially a very disruptive technology. Even opponents of the technology are exploring the many ways it can be used, and the consequent potential implications for society. Roughly speaking, as the name suggests, DLT is a technology for keeping multiple distributed copies of a single ledger. Multiple distributed holders of this ledger achieve consensus to agree on the contents of a ledger, and manage it in a manner so that it cannot be altered. This ledger can be used not only to keep track of financial transactions, but also to record “who did what, and when” for a whole host of non-financial applications (such as keeping track of food as it passes through a supply chain). The immutable nature of the technology means that DLT is suitable for a vast array of applications in which accurate and honest records of transactions are important. Given the ubiquity of such applications, it is unsurprising that large corporations such as IBM3 and Facebook4 are investing heavily in this technology.

While current applications of DLT are mainly focussed on payments and on record keeping, our interest in the technology stems from both the design of cyber-physical systems, and the need to enforce compliance in the sharing economy applications. Motivated by a large class of such systems, in which humans and machines, or machines and other machines, must orchestrate their behaviour to achieve a common goal, we are interested in using DLT as a design tool. Even though, formally speaking, this use of DLT appears to be new, we believe it to be very significant, and as we shall explain, distributed ledger technologies give rise to a number of properties that make them suitable to solve a number of cyber-physical design challenges that arise in the context of Smart Cities.

I-a Motivational Examples: Cyber-physical systems, the Sharing Economy, and Social Contracts

We are interested in designing a certain type of cyber-physical system. In the following examples, humans and machines must orchestrate their behaviour, sometimes sequentially, in order to achieve a common goal - such as sharing of a resource. Even though these examples appear mundane, they represent an important class of common problems that are arising more frequently in the arena of smart cities.

(i) Electric vehicle (EV) charge point anxiety : Many issues impeding the adoption of electric vehicles, such as long charging times, and range anxiety, have been addressed by advances in technology. One issue, that is more related to human behaviour than technology, remains however. That is the issue of Charge Point Anxiety. More specifically, public charge points are often occupied in many urban centres either by EV owners parking there for the entire workday (despite the EV being fully charged), or by ICE vehicles illegally occupying designated spaces. In either scenario the charge point is unavailable to other users resulting in under-utilization of valuable infrastructure. This leads to EV car owners experiencing the fear that a charge point may not be accessible when needed - Charge Point Anxiety. This is one of the main remaining barriers preventing the mass uptake of EVs. It is important to note that the inability to connect vehicles to the network is not just an inconvenience for EV owners. It also reduces the ability of the electrical grid to store energy in the EV fleet. This is an important consideration in the design of grid ancillary services - especially for vehicle to grid (V2G) services and in using the vehicle fleet as a storage buffer.

The most intuitive solution to charge point anxiety would be increase the number of charge points in these areas but, unfortunately, this is often not feasible due to cost. An alternative idea is to develop an adapter to extend the reach of charge points and so allow multiple EVs to connect simultaneously. To this end we designed an adapter (called a dockChain Adapter [2]) that allows the adapters to connect to a charge point in a ‘daisy-chained’ or ‘cascaded’ manner as shown below in Figure 1. It is envisaged that each car will carry an adapter as a standard component, similar to a spare wheel. When connecting to a charge point, the car owner connects the adapter to the charge point (or to another dockChain adapter), then connects the car to his/her adapter - as depicted in Figure 1.

Fig. 1: Three vehicles connected to a single charge point and charging simultaneously using three dockChain adapters

To see how DLT technology arises in the context of this example, suppose now that the yellow car wishes to disconnect from the chain. The car owner simply disconnects the car from the yellow box, and then the yellow box from the blue box that is upstream. One must now hope that the owner of the yellow car will connect the green and blue boxes together (assuming that the cables reach). There is, of course, no guarantee that this happens. One could use a ratings based system (as used by Uber or Tripadvisor) to rate compliance. An alternative to this approach is to incentivise good behaviour using a crypto-token. That is, to use a digital coin, as part of a deposit system. When the yellow car wishes to remove itself from the chain, it deposits a digital token into the charge point; once it reconnects the chain, its token is returned. In this case the token is used as a bond; if it is of sufficient value, then the yellow car owner is greatly incentivised to reconnect the chain.

(ii) Smart charging hubs for electric bikes : While EV’s are currently experiencing massive growth in popularity, mainly due to increased awareness around air-quality, they will not solve all mobility problems in cities. First, in many cities, the impact of such vehicles is limited, due to the way in which people live. For example, in cities such as Berlin, Germany, where people mostly reside in apartments, lack of charging infrastructure (or access to it), is likely to impede adoption. More generally, exchanging traditional vehicles for electric vehicles, will not address problems associated with road or parking congestion. It is in this context that electric bikes, or pedelecs, are seen as an essential component on the path to e-mobility. e-bikes are easily stored, do not require any infrastructure (the battery disconnects from the bike and can be charged from a regular wall socket), and their range (circa 40km) makes them eminently suitable for use in urban environments. In addition, the on-demand electrical assist provided by the motor, effectively removes many of the usual impediments to cycling (topology, wind, age of cyclist). Furthermore, the opportunity to develop services, for and from such bikes is very appealing, and it is in this context that we have developed, jointly with MOIXA5, a smart battery for both residential and on-street use. Roughly speaking, our smart battery is a unit that aggregates the batteries from a number of e-bikes. For example, this could be part of a mailbox system in an apartment block. Typically, each e-bike battery is of the order of 500 ; thus the aggregated amount of storage in say 30 batteries would be enough to power ancillary services in an entire building, making such aggregations an attractive part of any backup storage system. Similar opportunities exist for on-street systems.

Fig. 2: A schematic of the MOIXA/UCD ChargeWall system

To see how DLT technology arises in the context of this example, we must first note that the batteries are financially valuable parts of the e-bike system. In our system, as part of a resident management plan, apartment owners would give residents access to an e-bike, as well as access to shared vehicles, in exchange for fewer parking spaces. Residents would purchase crypto-tokens (whose value would exceed that of a battery) and use a digital deposit system as described above; namely in order to release a battery, users would deposit a token into the ChargeWall, which would then be returned when the discharged battery is returned.

(iii) The scourge of disposable cups : It should be clear to the reader that the above problems share certain common features; namely humans, in their interaction with machines, must comply with certain behaviour to achieve common societal goals. Another example of an important system of this type concerns irresponsible waste disposal. For example, in 2011 it was estimated that 2.5 billion coffee cups were thrown away (the figure is likely to be higher now)6. To many, decomposable cups are seen as the solution to this problem. Yet, at closer inspection, the introduction of biodegradable cups is only a small part of the solution; namely, not only must we use such cups when drinking our coffee, we must also put our biodegradable cup in the correct trash can or else risk contaminating other waste. As in the previous examples, that is where DLT comes in. One could associate a digital token with an RFID enabled biodegradable (or reusable) cup, and return this token once the user has placed the cup in the correct trash can.

(iv) General compliance problems : It should be clear to the reader that there are many smart-city compliance problems where digital deposits can be used to enforce both human and machine behaviour. Examples include enforcing time-restricted parking, interfacing with 3D printers, gaining access to charge points, and ensuring that cyclists and car drivers comply with traffic light signalling (we shall see this last example in much more detail later). Assuming that the reader is convinced of the merits of these applications, the reader may also ask why DLT is the method of choice for implementation. Could one not use any other payment method - such as PayPal or Visa to realise such a system? The answer is that DLT is much more suited to such applications than other digital payment methods for a number of reasons.

  • First, DLT is a distributed technology making it much more robust than a centralised payment system.

  • Second, at least some DLT technologies (e.g. Legicash,7 Byteball,8 IOTA [3]) are designed with the objective to be more suited to high frequency micro-trading that say PayPal or Visa. For example, sometimes, low value transactions will not be processed by traditional digital payment systems due to a lack of incentive in the transaction value for vendors (note: this is also a problem for some DLT architectures such as Bitcoin).

  • Third, PayPal or Visa will always take a transaction fee - making their use in digital deposit based systems questionable; namely, where the entire value of the token is intended to be returned to a compliant agent.

  • Finally, in principle, DLT tokens are more like cash that other digital forms of payment. More specifically, transactions are pseudo-anonymous9, that is the cryptographic nature of the addressing is less revealing that other forms of digital payments that are uniquely associated with an individual, the time and location of the spend, and the item that was transacted. This is unlike card based transactions, which always leave a trail of what was done and when. Thus from a privacy perspective (re. Cambridge Analytica and Facebook10), the use of DLT is much more satisfactory than traditional digital transactions.

From the perspective of cyber-physical systems, especially when humans are involved, fee-less transactions and privacy are the key considerations.

I-B Related work

Since the publication of the white paper where Blockchain was first introduced [4], the literature on DLTs has grown rapidly as researchers from industry and academia alike have been trying to explore the limits of this new technology and its possible applications. Nowadays it is possible to find plenty of material to understand the underlying principles on which DLTs are built: relevant reviews on the functioning principles of the Blockchain have been presented in [5], [6] and [7], while a thorough exposition on a more recent architecture for DLTs, called the Tangle, can be found in [3] and [8]. In [9] the authors discuss the advantages and disadvantages of Blockchain taking the insurance sector as an example. Unlike much of the literature on the topic, this paper proposes a critical perspective, emphasizing that the Blockchain should not be considered as a one-trick tool to be applied to every possible domain but, rather, a new technological advancement with its own niche of use. A similar perspective is also discussed in [10]. Particular applications of DLTs to store healthcare informations and IDs are presented in [11] and [12], while [13] proposes to employ Blockchain as a means for arbitrating roles and permissions in IoT.

Despite all these use cases, to the best of the authors’ knowledge, the use of DLTs in a control setting have yet remained unexplored: our interest, as anticipated in an earlier section, stems from the possible applications of DLTs in a smart city environment, using the digital tokens as a way to enforce the desired level of compliance in the resource-sharing interactions between humans and machines. A natural question that arises in this context is the value of the token that would be lost when an agent is not compliant. If this value is too high, (economic) activity stops and resources are not fully utilised; if it is too low, then compliance levels will be low and resources will not be effectively (perhaps optimally) utilised.

It is worth noting that the idea of using control signals in related areas is not new. For example, link pricing concepts are standard in networking [14], and many stochastic signalling strategies can be interpreted as a price [15, 16, 17]. More specifically, a large number of papers have been published on the topic of dynamic pricing being used to increase the quality of service provided to customers in various domains. The underlying concept is sometimes referred to as Transactive control, which is the design of feedback loops using financial transactions to improve quality of service in domains such as cities or the smart grid area: particular examples on this topic can be found in [18]-[22]. Other specific examples of dynamic pricing can be found in [23] (incentivizing users to schedule electricity-consuming applications more prudently) and in [24] (managing EVs charging and discharging in order to reduce the peak loads).

In all the aforementioned works, the control mechanism is obtained using economic transactions in the form of dynamic toll pricing; what we propose is a form of dynamic deposit pricing. The subtle, but substantial difference between the two approaches is that in the first case a user has to pay a certain amount of money in order to access a service, whereas in the latter, a user is forced to deposit a certain amount of tokens that will be returned once certain criteria are met. Thus, in the latter application it is risk that is being priced, rather than a form of demand management. In other words, from the perspective of a single agent, the amount of digital tokens deposited represents a risk for not complying with a set of rules, rather than a price to pay to access a service. It is important to stress that dynamic deposit pricing is not a disguised form of dynamic toll pricing: in the first the objective is optimize the use of a resource shared among agents, in the latter the objective is to ensure that the level of compliance is high enough to not jeopardize the system performance (or even lead it to instability). To give a practical example, consider a digital driving license associated with a fixed amount of tokens. Every time the driver crosses a checkpoint (e.g., a junction with traffic light) they deposit a certain amount of tokens and receive them back only if they behave as a “good citizen” (i.e., they do not break any rule while driving). In this example, the amount of tokens does not represent the amount of money needed to access a service but rather, a way to ensure that a shared resource is accessed fairly by all the agents involved. Section IV provides an example to show how low levels of compliance negatively affect the performance of a traffic junction and how this token model can be employed in such a setting. It seems pretty clear then that, while both approaches use a form of dynamic pricing as control signal, the domains of applications are widely different.

The focus of this paper is thus twofold: in the first part we present a concise, accurate, model for a type of DLT dynamics that would be suitable for implementing the kind of dynamic deposit pricing strategies which we have envisaged. The DLT model is designed to address the need for high-frequency, low-latency transactions, and we analyse its properties, providing details and a theorem about its stability. The second part presents a class of applications based on the use of DLT to control cyber-physical systems. In particular, we propose a pricing token mechanism to regulate compliance levels at interacting junctions in a road network. The situation described is just an instance of a vast class of problems where human users are expected to adhere to a predetermined set of rules in order to ensure an efficient sharing of resources (see Section I-A for a set of examples).

The contributions of the paper can thus be summarised as follows:

  • A detailed model of a practically important DLT designed for IoT applications: extensive Monte Carlo simulations are provided to validate its behaviour and show the accuracy of the proposed set of equations;

  • An analysis of the stability of the DLT under the hypothesis of a high arrival rate of transactions. Here, as we shall see, stability relates to the ability to double spend tokens (commit fraud).

  • A dynamic deposit pricing mechanism to regulate the compliance levels at interconnected activities to ensure efficient access to a shared resource: sufficient conditions are provided for the stability of the system;

  • An application of the pricing token mechanism to road intersections where vehicles are expected to respect the constraints imposed by the traffic light in order to access the junction.

I-C Organization

The reminder of the paper is organised as follows. Section II describes the most well-known DLT structures and provides an analysis of what requirements a cryptocurrency must have to be used in the control of cyber-physical systems. Section III describes the mathematical modelling of the Tangle: first a more general and stochastic system is presented and validated, then, under the assumption of a high arrival rate of transactions, a deterministic fluid model is derived and analysed in depth. Section IV describes the use of pricing tokens in cyber-physical settings: examples and simulations are provided to show how low levels of compliance affect negatively the performances of these systems. Finally, main conclusions and future work are outlined in Section V. Note finally that the literature on DLT architectures is split between academic publications and non-archival sources (such as forums, web pages, and news articles). We adopt the convention that non-archival sources are given in the form of footnotes, and more conventional publications in the reference list.

Ii Discussion of Basic DLT structures

A DLT is a spreadsheet where a record of transactions and other account information is transcribed, accessible and (potentially) owned by every node of a Peer to Peer (P2P) network, with an intrinsic mechanism to enforce consensus among its users.

Such systems, despite being conceptually simple, must possess certain properties to be useful in a large-scale cyber-physical setting.

  • DLT architectures must be scalable:. That is, for IoT applications, the number of transactions per second between devices can be in the order of thousands. Therefore any infrastructure needs to be able to manage such an amount of operations.

  • Double-spending: The DLT infrastructure must be resilient to attacks from malicious users (e.g., the structure must be safe against double spending attacks). Here, by double spending, we mean the ability of an agent to spend the same token more than once.

  • Energy costs: With the energy costs of bitcoin already approaching absurd levels, the energy cost to maintain the network infrastructure consistent and safe from attacks has to be kept at a reasonable level.

  • Fees: Transactions should be free of transaction costs. This is an extremely important feature from a control perspective. Consider the examples already discussed; if any time a transaction among devices enforces the payment of a fee, this will eventually deplete the coin value, thereby hindering its ability to participate in the network regulation problems.

  • Price volatility: Trading a fixed number of tokens on open platforms may be subject to significant price fluctuations. Developing economic systems, or using such tokens to implement a control strategy is difficult, due to possible hoarding of tokens. Thus, the ability to create tokens that are fixed against a stable currency, such as the US dollar, is very important.

In this Section we provide a description of two widely used DLT architectures, traditional Blockchain and the Directed Acyclic Graphs (DAGs). Note that such systems can be compared from an architectural perspective, from the perspective of the above items, or from the perspective of the consensus mechanism; for example, Blockchain is a competitive consensus system, whereas DAGs typically operate a swarm type of consensus mechanism (that use a type of majority voting algorithm).

Ii-a Blockchain

Blockchain was first introduced by Satoshi Nakamoto in his seminal white-paper [4] as the technology on which the Bitcoin was developed. Since that first paper, and following the success of Bitcoin, a large number of other currencies have been developed trying to emulate or to improve the original design. Almost all these currencies, at their core, share the same functioning architecture introduced by Nakamoto.

Blockchain is a peer to peer (P2P) distributed ledger of transactions [25], meaning that the ledger file (i.e., the spreadsheet that holds every transaction record) is not stored at a central server, but rather copies are distributed across a network of private computers (nodes). In order to exchange currency (or information), nodes issue transactions among each other using public/private key cryptography [5]. Every account-holder has a public key and a private (secret) key. The latter is used to sign/authenticate transactions, whereas the public one provides a unique address in the system.

Example 1.

For instance, in order for a user Paul to send a certain amount of currency to Anna, he needs to write a transaction, signed with the private key of the address where the coins are stored, attach his own public key to identify himself as the sender, and address it to Anna’s public key so as to identify her as the receiver. The transaction states that Paul’s account balance will decrease by some amount and that Anna’s account balance will increase by the same or lesser amount (any difference will be taken as a transaction fee by the successful miner, see below). This transaction is broadcast to the network and, after validation, is applied to every copy of the ledger.

To be validated, transactions are sent to the P2P network. If they are consistent with all previous transactions, some specific nodes called miners collect them together into data structures called blocks (each miner can decide which transactions to add to a specific block). Once a new block is proposed by a miner, it is sent to the network; if it is valid, every other node will add it to the end of the Blockchain. Each block contains a reference to the previous block, and transactions in the same block are considered to have happened at the same time; refer to Figure 3 for a visual representation of this process. In order to incentivise nodes to become miners, for each transaction approved, a miner is rewarded by some amount of currency, in the form of a transaction fee or bitcoins; in other words, each user needs to pay a miner a certain amount of currency for the service of adding blocks to the Blockchain.

Assuming consistency of transactions, miners must complete a certain amount of work to validate a new block in the Blockchain. This mechanism is known as Proof of Work (PoW). PoW involves solving a computationally-hard puzzle; specifically, the node that performs it needs to operate brute force computations to find a particular hash (the image of a hashing function [26]) in a high dimensional space that satisfies certain conditions (due to the nature of the problem, it is not feasible to perform anything different than a brute force approach). The miner which adds the next block to the Blockchain is the first one who is able to compute a valid hash and hence solve the puzzle. The amount of computations needed to solve it is very high and as long as the total computational power of the honest nodes is greater than the computational power of attackers that try to perform double spending transactions, honest nodes will outpace dishonest ones and only legitimate transactions will be part of the Blockchain. For more information regarding the security of Blockchain systems, the interested reader can refer to [27]. In the event two or more miners solve the PoW at the same time, to avoid conflicts, the Blockchain system requires each node to build immediately on the longest chain available. In other words, if two valid blocks are issued at the same time, they will both be accepted in the Blockchain: at this stage there will be two or more possible chains on which miners can try to add further blocks. As soon as one block is added to one of the chains, this one (the longest chain) will be accepted by the network and all the other ones will be discarded. In this way, the Blockchain enforces consensus and avoids possible forks that might endanger consistency. Thus Blockchain may be thought of as a system that is built on a competitive consensus method.

Despite its simplistic brilliance, PoW suffers from a major drawback that greatly compromises its use in the long term: in order to keep the network secure, the amount of energy consumption to perform the computations for the PoW is tremendously large. In order to solve this issue a system called Proof of Stake (PoS), based not on the amount of computational power employed but on the basis of the amount of currency owned by each miner, has been developed. In PoS, a validator, who is the equivalent of a miner in the PoW is elected to add a further block to the Blockchain, on the basis of the amount of currency possessed, and depending on the age of the coins (usually called the maturity date). A user with more substantial amount of coins held for a long time will be more likely to validate a block. As in the PoW, the validator is rewarded with a transaction fee for their effort. This mechanism requires little or no computational power to be executed and therefore the energy costs involved in the PoS are negligible compared to the PoW. The interested reader can refer to [28] for a PoS-based Blockchain protocol.

Finally, it is worth noting that the Blockchain presents scalability issues in the form of transaction per second: at the current time, the two most famous Blockchain based cryptocurrencies, Ethereum and Bitcoin, are able to process up to 20 and 7 transactions per second. This, in addition to the fact that transaction fees appear to be necessary as an incentive for transaction approvals, poses the question of whether or not the Blockchain is a good candidate DLT in a cyber-physical control scenario.

Fig. 3: Visual representation of three blocks of a Blockchain. Each block references the previous one and therefore any change in any part of the chain would result in an inconsistency.

Ii-B Directed Acyclic Graphs

A different solution for achieving consensus in a DLT uses a Directed Acyclic Graph. The DAG is the backbone of several cryptocurrencies (e.g., IOTA11, Byteball12, Nano13). More specifically, a DAG is a finite directed graph with no directed cycles. In other words, it is a graph that consists of a finite number of vertices and edges, with each edge directed from one vertex to another, such that there is no path that connects a vertex with itself. An example of a DAG is depicted in Figure 4.

A particular instance of a DAG is the IOTATangle [3]. Here the consensus method is cooperative in nature, rather than competitive as is the case in Blockchain. The objective of the Tangle, according to the original paper, is to design a cryptocurrency for the IoT industry with its main features being the absence of fees and low energy consumption. The Tangle is basically a DAG where each vertex represents a transaction, called a site (in the rest of the paper we might use either site or transaction to refer to a vertex of the Tangle), whereas the graph represents the ledger. Whenever a new transaction is issued, this must approve two previous transactions. Each approval represents an edge of the graph. All yet unapproved sites are called tips and the set of all unapproved transactions is called the tips set. A directed edge between site and site , means that directly approves , whereas, if there is a path (but not a single edge) that connects to , we say that is indirectly approved by (e.g., see Figure 5). The first transaction in the Tangle is called the genesis block (i.e., the transaction where all the tokens were sent from the original account to all the other accounts) and all transactions indirectly approve it. Furthermore, in order to prevent malicious users from spamming the network, whenever a new transaction undergoes the approval step, it has to perform a PoW (a much lighter version than the one performed by the Blockchain). In what follows, we assume that there is a simple way to verify if, during the approval phase, the selected transactions are consistent among each other and with all the sites directly or indirectly approved by them. In case they were not, the selection process needs to be run again, until two consistent transactions are found.

To have a better understanding of the previous process refer to Figure 6: a certain instance of the Tangle, with three new incoming transactions is presented (upper panel). The green block (the leftmost) is the genesis site, blue blocks are transactions that have already been approved, red blocks represent the current tips of the Tangle and grey blocks are new incoming transactions. Immediately, when issued, a new transaction tries to attach itself to two of the network current tips (middle panel). If any of the selected tips was inconsistent with the previous transactions, or with each other the selection would be rejected and two other tips would be selected. Notice that at this stage, these transactions are not yet part of the Tangle as they are carrying out the required PoW and the tips remain unconfirmed (dashed lines) until this process is over. Once the PoW is finished, the selected tips become confirmed sites and the grey blocks are added to the tips set (lower panel).

Let us consider another example to explain with more detail the process of approval. Figure 7 shows a further instance of the Tangle. A malicious user sent a certain amount of money to a merchant. The corresponding transaction is the yellow block in the figure. The same user, afterwards, makes other transactions trying to double spend the same money that were sent to the merchant. These correspond to the green blocks. It is worth stressing, at this point, that there is no mechanism to force a user to select certain sites for confirmation. Any transaction can be selected as long as it is consistent with the sites that are approved (directly or indirectly) by it. Nevertheless it is reasonable to assume that the vast majority of nodes would have little interest in confirming specific transactions and would follow the tips selection algorithm proposed by the protocol. In this scenario, all the transactions that approve the original yellow site (the blue blocks) are incompatible with the green ones, therefore any new transactions can either approve the green/black sites or the blue/black ones. The green/blue combination would be considered invalid (as there is an inconsistency in the ledger) and a new selection would be made. The objective of an hypothetical attacker would be then to wait for the merchant to accept their payment, receive their goods, then create one or more double spending transactions that get approved by other honest sites. If this is the case, what prevents nodes from spending their money twice? Roughly speaking, depending on the tip selection algorithm employed, due to the presence of the PoW, any malicious user would need to possess the majority of the hashing power in the Tangle to perform such an attack and make it successful. A thorough discussion on the possible attack scenarios of the Tangle is beyond the scope of this paper and we refer the interested reader to [3] and [29].

Fig. 4: Example of a DAG with 11 vertices and 10 edges. All the vertices are directed and it is impossible to find a path that connects any vertex with itself.
Fig. 5: Transaction 8 directly approves 5 and 6. It indirectly approves 1, 2 and 3. It does not approve 4 and 7.
Fig. 6: Sequence to issue a new transaction. The green site represents the genesis block, the blue sites represent the approved transactions and the red ones represent the tips. The back edges represent approvals, whereas the dashed ones represent transactions that are performing the PoW in order to approve two tips.
Fig. 7: The blue and the green transactions are incompatible with each other.

Ii-C Blockchain vs. DAG: A cyber-physical perspective

While Blockchain is without doubt the genesis of the current interest in DLT, its use in a cyber-physical context is limited. Apart from the large energy costs, and the volatility of coins such as bitcoin, the long transaction times, transaction fees, and the inherent preference for miners to process large transactions rather than small ones, makes its use of limited value in cyber-physical control situations. In contrast, the DAG structure may be much more suitable for such use cases as it is claimed to support high-frequency (low latency) micro trading. Thus, in the remainder of this paper we focus solely on a mathematical description of the DAG as envisaged in the Tangle, and explain some use cases that relate to compliance in smart cities.

Iii The mathematics of the Directed Acyclic Graph

A directed acyclic graph (DAG) consists of a set of vertices or sites and a set of directed edges , with the additional condition that the graph has no cycles (a cycle is a collection of directed edges such that for and ). When an edge is directed from to (where ) we will say that is a parent of , and that is a child of . Viewed at a high level, a Blockchain is a simple example of a DAG, where the site set consists of the blocks, and the edge set consists of the directed edges from each block to its unique predecessor in the chain (except for the genesis block which does not have a predecessor). In our applications the DAG will be connected, and as in the Blockchain there will be a unique site (the genesis) which has no parent sites. In a finite DAG the acyclic condition implies that there must be at least one site with no children (this can be seen by following a path which always moves in the direction from parent to child). The sites with no children are referred to as the tips of the graph.

Iii-a The IOTA Tangle

The Tangle is an increasing family of finite DAG’s where each site of contains the record of a transaction which arrived at or before time . The DAG grows through the addition of new sites which represent newly arrived transactions. The special feature of the Tangle is that each new site is attached to two pre-existing sites on the graph by directed edges, meaning that the new site becomes the child of both of these pre-existing sites. Furthermore both of these pre-existing sites must be tips of the graph at the time when they are selected by the new transaction. There is a delay between the time when the tips are selected and the time when the new site is attached to the Tangle. This delay allows time for a proof of work and for the validation of the transactions in the two parent sites (this validation ensures that the transactions on the selected tips are consistent with each other and with their parent sites). Hence the directed edges from the new site represent approvals of the transactions which reside at the existing parent sites (note that these approvals do not imply any relation between the transaction in the new site and the transactions in the two parent sites). The weight of a site is (one plus) the number of sites which have approved it either directly or indirectly, which is also (one plus) the number of its descendants in the graph. Thus the weight of a site represents the amount of work which would be needed to repair the Tangle if the transaction represented by that site were altered, and so the weight measures the security of a transaction in the Tangle (in the Blockchain the analogous measure of security for a transaction is the accumulated difficulty of blocks which have been inserted subsequent to its own block).

We will describe a mathematical model for the growth of the Tangle in a situation where one central user maintains the record of the Tangle, and other users generate transactions for inclusion in the Tangle. In a real network many users would maintain local copies of the Tangle, and each user would independently update its own copy. However this complicates the analysis since it can lead to synchronization issues for updates. Therefore we assume the simpler scenario where only one user maintains the record, and other users view this record when they create a new transaction. The model will depend on (i) an arrival process which describes the creation of new transactions, (ii) a tip selection algorithm, which will describe how each newly created transaction selects two tips for approval, and (iii) a delay time which accounts for the time between creation of a transaction and its addition to the Tangle (for reasons of simplicity will be assumed to be the same for all transactions).

Iii-B Random tip selection model

Our analysis will focus on the simplest tip selection algorithm, in which each new transaction randomly and independently selects two tips for approval. We call this the random tip selection algorithm, and we will analyze the growth of the Tangle under this assumption. Keeping track of the growth of the full DAG would be quite complicated, but fortunately the random tip selection algorithm allows us to construct a simpler model which just keeps track of the number of tips. In this setting the growth of the Tangle is determined by the sequence of times when new transactions are created, and by the selections of tips for approval. The random tip selection algorithm was introduced and discussed in the paper [3], and later we will compare the predictions of our model with some of the results derived there.

We assume that when a transaction is created two tips are immediately selected and validation is attempted (note that the same tip may be selected twice by the new transaction, since in the random tip selection algorithm the two choices are made independently). If validation fails the choices are discarded and another two tips are selected for validation. This continues until the process is successful, and we assume that this whole validation effort is essentially instantaneous. However after the validation there is a waiting period during which the proof of work is carried out and the transaction is communicated to the central user where the Tangle is stored. During this time the approvals of the selected tips are pending, so the tips may still be available for selection by other new transactions. After the waiting time the two new directed edges are added to the graph, directed from the new site to its two parent sites. After this point the two parent sites are no longer tips, and so are no longer available for selection by other new transactions (note that the parent sites may have been previously selected by earlier arrivals, in which case they ceased being tips at an earlier time).

The reduced model involves these variables:

  • is the number of tips at time

  • is the number of ‘pending’ tips at time which are being considered for approval by some new transaction

  • is the number of ‘free’ tips at time

  • is the time when transaction is created

  • is the number of transactions created up to time

  • is the number of free tips selected for approval by transaction at time

We have the relation

(1)

and similar expressions for the other variables:

(2)
(3)
(4)

Assuming the random tip selection algorithm, is a random variable whose distribution depends only on the values of , and just prior to time . We assume that have left limits, and define and similarly for , . Then the distribution is

(5)
(6)
(7)

and the expected value is

(8)

The system of equations (1-4) is well-suited for simulation: if the transaction times are generated according to some rule (for example a Poisson process) then (1-4) provide the update rules for the variables (updates occur at both the creation times and the times when sites are added to the DAG). Some examples of the resulting simulations are shown in Fig. 8. Note that in the paper [3] the steady state (average) value of was predicted to be , which is consistent with the simulations shown in Figure 8 for large arrival rates and large values of .

Fig. 8: Four different simulations of the Tangle with increasing delays, (the larger the delay, the larger the steady value). Each simulation shows 100 realizations of the reduced model with transaction times, , generated according to a Poisson distribution with . The upper panel shows the leaves, , whereas the lower panel shows the free leaves,

Although we do not pursue these questions here, it would be interesting to consider general properties of the stochastic process defined by (1-4) such as the existence of a stationary distribution and ergodicity, under reasonable assumptions for (for example that is a Poisson process).

Iii-C Conflicts on the Tangle

The Tangle is designed to be a secure, reliable and robust ledger for storing transaction records. However as explained before it is possible for conflicting transactions to be added to the Tangle at more or less the same time, and so the only way for the Tangle to achieve its goal of reliable record-keeping is to hope that conflicting records will be eliminated as the Tangle grows. In order to explore this avenue for conflict resolution we consider the situation where several conflicting sub-DAGs exist on the Tangle, and analyze how the Tangle grows in the presence of such conflicting records. Recall that a newly created transaction will approve two parent sites that belong to the same sub-DAG, but will never approve two parent sites which belong to different sub-DAGs. Thus each sub-DAG will continue to grow, but the sub-DAGs will never be joined. If this situation were to continue indefinitely then the Tangle would remain inconsistent, and thus would not serve its primary purpose as a reliable record of authenticated transactions. This motivates investigating whether the attachment algorithm can lead to some kind of stochastic forcing that will eliminate all but one of the sub-DAG’s.

We will examine this question using the random tip selection algorithm previously discussed, and assume that conflicting sub-DAGs exist on the Tangle. Thus every site has a label from the set , indicating the sub-DAG to which it belongs. We will call this the type of the site. As before we assume that when a transaction is created the validation process is started, and that it ends when two tips of the same type have been chosen. At this point the site for the new transaction is labeled the same type as the selected tips.

The new model involves these variables:

  • is the number of tips of type at time , so

  • is the number of ‘pending’ tips of type at time

  • is the number of ‘free’ tips of type at time

  • is the time when transaction is created

  • is the type of the transaction

  • is the number of transactions of type created up to time

  • is the number of free tips selected for approval by transaction at time

The probability for a transaction at time to select two tips of type at the first attempt is

(9)

If tips of different type are selected, the choice is rejected and a new selection is made. This continues until two tips of the same type are chosen. Thus the eventual selection is conditioned on the event that the two selected tips have the same type, which occurs with probability . Hence the probability that a transaction is type is

(10)

Conditioned on the site being type , the distribution of the random variable is

and therefore

(11)

The relations for the variables are similar to before:

(12)
(13)
(14)
(15)

The system (12-15) can be used to generate simulations of the growth of the Tangle in the presence of conflicts. The only change from before is that at each time when a new transaction is created, the type of the transaction is selected using the distribution (10). The variables can then be updated at times according to the formulas (12-15).

Iii-D Validation of the Tangle model

To validate the model presented in the previous paragraph we compare its behaviour with an agent based version of the Tangle: at each time step a random number of transactions arrive, according to a Poisson distribution, and for each one of these transactions the tip selection algorithm is performed on the current tips set in order to generate graph structures equivalent to the ones presented in detail in Section II-B. In other words, this agent based model simulates the behaviour of each transaction, therefore providing an accurate replica of the mechanism described in Section IIB. The variables used for the comparison are the number of leaves and the number of free leaves . To obtain these quantities, for the agent based model, it is sufficient to enumerate the number of leaves and free leaves present in the respective sets at the end of each time step. Due to the stochastic nature of the Tangle, 500 Monte Carlo simulations are performed in order to obtain statistically meaningful results. Figures 9 and 10 show this comparison for and . In the second set of simulations, at a user tries to perform a double spending attack on the Tangle. For both scenarios it is easy to notice, even by visual inspection, that the evolution of and is identical: the realizations of the agent based model are superimposed on all the realizations obtained using equations (12-15), showing that the two systems exhibit the same dynamical behaviour. As a further note, notice how the attack in the second scenario fails due to the fact that not enough transactions were issued by the attacker. More details on this aspect are provided in the remainder of this Section.

Fig. 9: Simulation of the Tangle. The blue realizations represent the agent based model, whereas the red realizations represent the stochastic model. The upper panel shows the leaves, and the lower panel represents the free leaves, . Each simulation shows 500 realizations of the model with transaction times, , generated according to a Poisson distribution with and .
Fig. 10: Simulation of the Tangle with a double spending attack. The blue and red realizations represent the two types for the agent based model, whereas the cyan and green realizations represent the two types for the stochastic model. The upper panel shows the leaves, and the lower panel represents the free leaves, . Each simulation shows 500 realizations of the model with transaction times, , generated according to a Poisson distribution with and . At the attacker issues 200 transactions trying to outpace the original Tangle.

Iii-E Fluid model

In order to gain some understanding of the system (12-15) we consider the asymptotic regime of large arrival rate, where the time between consecutive transactions is very small. In this regime it should be reasonable to approximate the system (12-15) by a fluid model. The following derivation of the fluid model is heuristic, and it should be considered as an independent model for the Tangle which is motivated by the stochastic model described in the previous sections.

We introduce a scaling parameter so that the arrival rate is proportional to , and let to reach the fluid model. The rescaled variables are assumed to converge to deterministic limits as , and the limits are represented in the fluid model by real-valued functions . The creation of new transactions in the fluid model is described by an arrival rate which corresponds to the limit of . Following this logic, the arrival rate of transactions of type in the fluid model is , where is obtained from (10) by rescaling the variables:

(16)

(we assume the variables in the fluid model are continuous and thus etc). Furthermore the variable is replaced by its time average (over a short time interval), which by the law of large numbers is equivalent to the ensemble average (11). By rescaling variables and letting , this expected value converges to . Referring to the equation (14) the change of over a small time increment can be approximated as

Applying similar reasoning to the other equations we get the following set of delay differential equations (DDE) for the fluid model:

(17)
(18)
(19)

where

(20)

The solution of these equations can be interpreted as a fluid model which describes the dynamics of the Tangle with very high arrival rate, using the random tip selection algorithm. Note that the DDE system (17 - 19) must be supplemented by initial conditions in the interval .

Iii-F Stability of conflicts in the fluid model

In this section we assume that the arrival rate is constant, and we consider the existence and local stability of time-independent solutions of the fluid model. Local stability is analyzed using a linearization of the DDE. Given a time-independent solution of the system (17 - 19), the linearized model is constructed by letting

(21)

and keeping only those terms in the equations which are linear in . The resulting linear system of delay differential equations is denoted . The solution is locally stable if

(22)

for all solutions of the linear system. The solution is locally unstable if there is some solution satisfying such that

(23)

The spectrum of the linear system is the set of complex values for which the system has a nonzero solution of the form

(24)

for some constants . The solution is stable if the spectrum is contained in the open left half of the complex plane, and is unstable if there is some element of the spectrum in the open right half of the complex plane [31].

Theorem 1.

Consider the system (17 - 20) with types, and with arrival rate . For each non-empty subset with there is a time independent solution

(25)

For all the time independent solution is locally unstable. For the time independent solution is locally stable.

Remark: there are possible static solutions, corresponding to all possible non-empty subsets of . In each static solution the total (rescaled) number of tips is , and this total is shared equally between the nonzero components. So the static solutions describe Tangles with equally sized conflicting sets of tips. The linearized model describes the growth and decay of solutions which are close to the solutions (25). So Theorem 1 shows that all time-independent solutions are unstable except for the case where there is just one type. This is consistent with the simulations of the full model shown in Figure 10.

Proof: we look for steady state solutions of the system (17 - 19):

(26)

This immediately leads to

(27)

and hence

(28)

Thus either or . Similarly the relation

(29)

leads to either or

(30)

Thus all nonzero components must be equal, and . Let be the number of nonzero components of the static solution, then these nonzero components are

(31)

To investigate local stability we consider small time dependent perturbations of the static solutions. If there are types with , and these do not contribute to the linearized equations. Thus without loss of generality we can suppose that , so the static solution is and . Consider time dependent solutions of the form

(32)

where are small. Then to linear order

(33)
(34)

and the DDE equations to linear order are

(35)

In order to investigate local stability, we consider a perturbation of the form

(36)

where are constant, and is a complex parameter. Substituting (36) into (III-F) leads to the equations

(37)

For we now display a class of solutions for which is real and positive, thus implying local instability. To this end consider the equation

(38)

It can be easily checked that the left side of (38) is zero and increasing at , and is negative at . Thus there is a positive real solution satisfying (calculations show that ). Define , and let be any nonzero vector with . Then it can be verified that there is a solution of (III-F) with and for . The existence of this solution implies that the static solution is locally unstable for . Conversely if then the parameter must satisfy the equation

(39)

It can be easily checked that every solution of (39) lies in the open left half plane, and thus solutions with do not lead to local instability. This implies in particular that for the static solution is locally stable.

Iii-G Summary of results

The preceding analysis strongly suggests that conflicting transactions cannot coexist on the Tangle in the regime of large arrival rate when the random selection algorithm is used to select tips for approval. The fluid model does allow conflicting sub-DAGs to co-exist as long as they have exactly equal numbers of tips, however the local instability result derived in this section implies that any small imbalance will quickly be amplified, and we expect that this instability will eventually lead to the removal of all but one of the sub-DAGs. The time scale for this effect is proportional to the delay parameter in the model. We conjecture that a stronger stability result holds, namely that all solutions of the fluid model (except the ones with exactly balanced sub-DAGs) converge to the static solution with as .

The fluid model is presumed to approximate the full stochastic model for large arrival rate, and of course the stochastic model will continually exhibit small fluctuations. Thus the locally unstable solutions of the fluid model should not appear in the stochastic model, and this conclusion is indeed supported by our simulations of the Tangle, for example in Figure 10. It is intuitively plausible that the random selection algorithm will remove conflicts on the Tangle through this stochastic forcing mechanism, and it is reassuring that the fluid model shows the same behavior. The paper [3] pointed out some potential weaknesses of the random selection algorithm which might be exploited to attack the Tangle. That paper also proposed a different tip selection algorithm based on a random walk along the DAG, which might provide more protection against malicious attacks. It would be interesting to analyze this random walk algorithm using the methods presented here.

Iv DLT, Social Compliance, and the design of Cyber-Physical systems

We now return to the use-cases described in the introduction. We are interested in using DLT to create a privacy preserving mechanism to enforce social contracts in situations where machines, and other machines, or humans, must orchestrate their actions to ensure efficient sharing of resources. In this context the digital token is used as a bond, or digital deposit, to ensure that various agents comply with social contracts. The risk of losing a token is then the mechanism that encourages agents to comply with these social contracts.

A natural question that arises in this context is the value associated with tokens that enforce a particular activity. If we set the value too low, then the risk is of no interest to an agent and the social contract is not enforced. If we set this value too high the activity may be suppressed entirely for fear of losing tokens, and the societal contract also fails. Thus we wish to place a value on tokens so that they freely move in our system, but also so that they encourage almost full compliance of all agents participating in the system. The issue of finding this value is the subject of this present section.

Before proceeding it is worth noting that the issue of compliance is sometimes not addressed in studies of algorithms to regulate, control, and optimise city infrastructures. Many publications addressing smart city problems assume full compliance with policies that have been engineered to optimally organise city infrastructures. For example, papers on optimisation of traffic lights frequently do not consider the issue of compliance. Of course, humans break rules, and the effect of this rule-breaking often profoundly affects how cities operates. For example, readers will be certainly familiar with the effect of drivers and cyclists who break red lights or block traffic junctions, especially during very busy periods of road usage.

In what follows, we explore the use of our DLT strategy to regulate access to interacting junctions in a road network. A specific example could be a network of streets with traffic lights at the intersections, and a population of road users who share the space with other traffic. The compliance goal is that agents (cyclists, drivers) will be ‘good citizens’ and will respect the instructions from the traffic lights. The control mechanism is an automatic token exchange whereby each agent arriving at a light will deposit some number of tokens with the junction. If the agent obeys the traffic lights when crossing the intersection then the tokens will be returned; otherwise the tokens will be kept by the system. The number of tokens required at the intersection can be adjusted in real time in order to control the level of compliance. The model assumes that each agent will randomly choose whether to comply with the local traffic light based on both the cost of non-compliance (leading to lost tokens) as well as their observation of the behavior of other agents (the assumption being that agents are influenced by how others behave). Note in this model, we could assume, for example, that each road user may only use a road if he/she has a positive token balance. Once a balance goes to zero, the user is no longer allowed to travel.

To show why this is effectively an interesting area to focus on, in what follows we present the effects on the traffic of a single junction as the compliance rate, decreases. Figure 11 shows a single junction where a traffic light coordinates the traffic flow of three roads: every units of time the traffic light switches and allows cars from a different road to pass. The amount of time for a vehicle to cross the junction is referred to as . The number of cars that crosses the junction, per time unit, is fixed and is referred to as . At the same time, each time unit, a certain number of cars, is randomly distributed among each road, according to a uniform distribution, increasing the length of each corresponding queue. In what follows we refer to the lengths of the three queues as , , and the average queue length as , whose magnitude will be used in what follows as an estimate of the performance of the junction (i.e., the larger the average queue, the worse the junction performs). Furthermore, there is a probability, namely , that at time a car from one of the queues with a red traffic light will go through. In this scenario, to take into account that cars are likely to slow down during this event, the crossing time increases by a fixed quantity, . To appreciate the effects of the compliance rate consider a junction with , , and as a random number generated by a Poisson distribution of mean . Figure 12 shows , averaged across 100 Monte Carlo simulations as the compliance level decreases from 1 to 0.8 (by 0.1 ticks). Note that while in the case for , the junction works smoothly (Figure 13 shows the individual behaviour of , and in a single realization of the process), even a small level of non compliance is enough to compromise the system performance and the delays caused by larger levels of non compliance are enough to make the system unstable. These results lead us to believe that the derivation of a control mechanism based on pricing tokens to avoid high level of non compliance, can be an effective way of improving the quality of services in cities.

Fig. 11: Visual illustration of the junction example.
Fig. 12: Each image shows , averaged across 100 Monte Carlo simulations. The compliance level for each simulation goes from 1, (upper panel) to 0.7 (lower panel). As the Compliance level decreases the performance of the system degrades until it becomes unstable.
Fig. 13: Single realization of , and for the junction system.

The control model for this system will be described by a series of differential equations for the cost of tokens (the cost of non-compliance) based on how the current compliance levels compare to some target levels. Sufficient conditions are established for the existence of a locally stable solution which achieves the target compliance goals.

Iv-a The network model

Consider a system of physically separated activity centers (for example road junctions), and a population of agents moving between these activities. The cost of participation at activity at time is , and the probability of compliance at activity at time is , with . The time averaged compliance level is defined as

(40)

where is a fixed window size for the average.

For each pair of activities the time lag is the minimum time needed for an agent to move from to (where by definition). The compliance level at activity is assumed to depend on the cost as well as the time averaged compliance levels for other activities, delayed by the corresponding time lags: for

(41)

The function is unknowable, but for the purposes of this analysis some basic properties can be assumed: in particular it is assumed that is differentiable, and that for all the function is monotone increasing in its last argument, so that

(42)

Also we define the feasibility region to be the set of compliance levels which can be achieved as time-independent solutions of (41) using some valid choice of costs :

(43)

The assumption (42) implies that for each there is a unique set of costs such that the equations are satisfied for each .

For each activity there is a fixed target compliance level , and the control equation for the cost is assumed to have the form

(44)

The function is a design parameter, and in particular is chosen so that , is differentiable and .

To summarize, the components of the model are

cost of token to start activity at time
compliance level for activity at time
[, where is total compliance]
time averaged history of compliance
window size for time average
feasibility region for compliance levels
target compliance level for activity
compliance level function
cost function
time lag between activities and

Iv-B Static solution

For a time-independent or static solution the cost must be constant for each . From (44) and the assumptions on the functions it follows that the static solution must satisfy

(45)

These conditions are possible only if the target compliance levels are in the feasibility region, that is if . In this case there are unique costs such that

(46)

Thus the system has a unique static solution for every set of target compliance levels in the feasibility region.

Iv-C Local stability analysis

To investigate local stability of the solution we consider perturbations of the static solution of the form

(47)

where are small. Also define

(48)

Then keeping only terms of lowest non-trivial order, and assuming differentiability of all functions gives the system of linear equations

(49)

where

(50)
(51)

In order to investigate stability of this linear system it is sufficient to consider perturbations of the form

(52)

where is a complex parameter. This assumption leads to the relations

(53)
(54)

Substituting (53) into (IV-C) gives the eigenvalue equation for each :

(55)

The system (IV-C) is locally stable if all solutions of (55) occur with in the open left half plane [31]. In order to analyze this condition, let denote the matrix with entries

(56)

Then letting denote the vector of values, the system (55) can be written as

(57)

Let denote the eigenvalues of , then a sufficient condition for local stability is that all values of which for some yield a solution of the equation

(58)

should lie in the open left half plane. Although this condition involves the precise details of the entries of the matrix , it is possible to find a general sufficient condition. Namely, for any in the closed right half plane, the modulus of the right side of (58) is greater than or equal to . Thus a sufficient condition is

(59)

We will next analyze how this condition applies to a simple network.

Iv-D Special case: a ring network

We introduce a simple network in order to analyze the stability question in more detail. So consider a network of activities arranged in a ring, and assume that the lag time is constant between all pairs of nearest neighbors . Furthermore assume that each activity is directly influenced only by its nearest neighbors, and that there is a constant such that

(60)

Finally assume also that the values and are constant, and let

(61)

Then the eigenvalues of the matrix are

(62)

Letting with , we have the bound

(63)

Therefore (59) implies that a sufficient condition for local stability is

(64)

The parameter records the sensitivity of the compliance functions (41) to the behavior of their neighboring activities. So for fixed the condition (64) requires that agents are not unduly influenced by the behavior of agents at other locations. For more complicated networks the same general result applies, namely that weak influence between agents at different activities leads to local stability of the static solution.

Iv-E Example: single junction

We now return to the single junction introduced in Section IV. In order to prevent the drastic decrease in performance due to the compliance level and to maintain the traffic of the junction within acceptable levels (with respect to the optimal level of compliance), we make use of the token system described in Section IV-A: assume, for the sake of simplicity, that the dynamics of the cost, are chosen as a first order system and that the compliance rate depends linearly on :

(65)
(66)

where represents the time unit of the junction system, the parameter represents values that can be empirically extracted by data collected at the junction and and represent the design parameters for the control system. Figure 14 shows (upper panel), (middle panel) and (lower panel): after an initial transient (where the oscillations are emphasized for illustrative purposes) stabilizes around the desired compliance rate (0.95, in this example). Furthermore, note that the steady state value of depends on the parameters of equation (65) (specifically on the choice of ). These values are supposed to be extracted empirically from real data (see equation (41)) and therefore it needs to be stressed that the particular steady state value reached by depends specifically on the arbitrary choice for this example.

Remark: as a final note we want to point out that while in this model the amount of deposit is the same for every user, it is easy to imagine extending equations (44), by taking into account variables that we neglected in our current analysis (e.g., individual wealth, amount of times the particular resource is used, amount of previous transgressions, etc.).

Fig. 14: Simulation of the junction system, with . The upper panel shows the average queue length, , the middle panel shows the compliance level and the lower panel show the cost, .

V Conclusions

This paper proposes the use of DLTs to control the compliance levels of users that share access to a common resource. In the first part of the paper we present a stochastic model for one choice of a DAG-based DLT (the Tangle), and demonstrate i