Secure Access Control for DAG-based Distributed Ledgers

07/20/2021
by   Lianna Zhao, et al.
0

Access control is a fundamental component of the design of distributed ledgers, influencing many aspects of their design, such as fairness, efficiency, traditional notions of network security, and adversarial attacks such as Denial-of-Service (DoS) attacks. In this work, we consider the security of a recently proposed access control protocol for Directed Acyclic Graph-based distributed ledgers. We present a number of attack scenarios and potential vulnerabilities of the protocol and introduce a number of additional features which enhance its resilience. Specifically, a blacklisting algorithm, which is based on a reputation-weighted threshold, is introduced to handle both spamming and multi-rate malicious attackers. The introduction of a solidification request component is also introduced to ensure the fairness and consistency of network in the presence of attacks. Finally, a timestamp component is also introduced to maintain the consistency of the network in the presence of multi-rate attackers. Simulations to illustrate the efficacy and robustness of the revised protocol are also described.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

10/04/2019

HDMI-Walk: Attacking HDMI Distribution Networks via Consumer Electronic Control Protocol

The High Definition Multimedia Interface (HDMI) is the de-facto standard...
04/13/2021

Position-based cryptography: Single-qubit protocol secure against multi-qubit attacks

While it is known that unconditionally secure position-based cryptograph...
10/28/2020

EC-SVC: Secure CAN Bus In-Vehicle Communications with Fine-grained Access Control Based on Edge Computing

In-vehicle communications are not designed for message exchange between ...
12/04/2018

An Idea to Increase the Security of EAP-MD5 Protocol Against Dictionary Attack

IEEE 802.1X is an international standard for Port-based Network Access C...
10/02/2019

Eradicating Attacks on the Internal Network with Internal Network Policy

In this paper we present three attacks on private internal networks behi...
02/10/2018

About being the Tortoise or the Hare? - A Position Paper on Making Cloud Applications too Fast and Furious for Attackers

Cloud applications expose - beside service endpoints - also potential or...
06/15/2021

Voting for the right answer: Adversarial defense for speaker verification

Automatic speaker verification (ASV) is a well developed technology for ...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

Over the last decade, Distributed Ledger Technologies (DLTs) have become a very popular topic both in industry and academic communities because of their broad applications across many vertical domains, such as, supply chain, smart cities [1] and decentralized finance [2]. In essence, a distributed ledger, just as the name suggests, is an immutable database shared across multiple agents in a decentralized manner, where participants have consensus on the contents of the database. DLT’s are viewed as a game changing technology in many industries as they enable an immutable recording of exchange of assets, and can also be used to design cyberphysical systems [3].

The best known DLT architectures is Blockchain [1]. While the inception of Blockchain represented a leap forward in achieving consensus and immutability in a Peer-to-Peer (P2P) network, its technological and design limitations make it unsuitable for many Internet-of-Things (IoT) applications [4]. For example, from a structural perspective, the incentive mechanism in Blockchain encourages the validation of large transactions over small ones, and tends to centralise power in the hands of a few powerful mining pools [5]. Moreover, the time interval between the creation of new blocks leads to low throughput and scalability issues that seriously limits the range of domains to which Blockchain can be applied.

Recently, many researchers have suggested alternatives to the basic Blockchain structure. One such alternative is Direct-Acyclic-Graph (DAG) based DLTs [6, 7]. A typical DAG architecture is represented by the IOTA Tangle [8]. Instead of using a chain, every new incoming transaction can freely reference existing transactions in a graph structure. This means many transactions are verified in a parallel fashion, thereby realising a more scalable and high-throughput architecture. Unlike in the Blockchain where Proof-of-Work (PoW) is used to reach consensus among nodes, the IOTA Tangle employs a lightweight reputation-based voting mechanism to keep consistent ledger states, and PoW is only employed to make Denial-of-Service (DoS) attacks expensive [9]. Consequently, the PoW in the Tangle tends to be computationally much less expensive than the one used in Blockchain [3].

In this paper, we consider certain specific DAG-based ledgers that have been proposed for IoT applications. While their design overcomes some of the scalability and economic issues in traditional Blockchains, these DLTs also give rise to new challenges in terms of the design of access control mechanisms to support their operation. In fact, Blockchains have an intrinsic filter provided by the work performed by the miners to select which transactions should be added to the ledger. Removing PoW makes DAG-based DLTs more IoT-friendly, but also necessitates an explicit access control mechanism to guarantee fair writing rights to the network nodes. While the literature on congestion and access control for conventional networking applications is rich, a distinguishing feature of DLTs is that they must be designed to operate in a reliable manner in adversarial environments, and this mandates new line of research in the area of congestion and access control.

Our objective here is to address this issue. We focus on the IOTA Tangle and its recently proposed reputation-based222In this paper, we consider reputation as a numeric value associated to a node depending on some characteristics. In principle, reputation should be difficult to gain and easy to lose; reputation may be simply computed according to the stake handled by nodes or by analysing node’s behavior from a more complex point of view. However, the actual way of computing reputation is out of the scope of the paper. We also assume that nodes have perfect knowledge of reputation of all the other nodes. While this assumption may not be realistic, our access control algorithm can successfully deal with small inconsistencies in the reputation perception among different nodes. access control algorithm [10]. However, our analysis can be applied to any distributed network that seeks to guarantee fair access and consistent databases across the network participants in an adversarial environment. The basic idea is to allow users with a larger amount of reputation333The measure of reputation in IOTA is called mana. to have a larger impact on the system. Note that in DLTs, access to the ledger is highly competitive, affecting both consensus and the ability of users to generate revenue. Consequently, access control mechanism plays a very important role in DLTs. This paper studies the reference mechanism adopted as a part of the IOTA protocol, describes its vulnerabilities and proposes a number of additional countermeasures to fix these problems to be resistant to specific attack scenarios. In particular, we consider the following issues concerning the aforementioned protocol.

  • We analyse the security of [10] against more advanced attacks than considered in the original work, e.g., nodes send different streams of transactions to different neighbours to harm consistency.

  • We introduce several components to ensure ledger consistency across network participants (see Definition IV.6). More specifically, we propose specific buffer management techniques, transaction reordering and improved gossip strategies to improve the network solidification process. (For a discussion of solidification requests and timestamp ordering, please refer to V.B).

  • We propose an effective method to penalise attackers through blacklisting specific malicious flows (blacklisting strategy - please refer to IV.A).

  • We evaluate and benchmark the robustness of the newly designed IOTA access control algorithm via extensive simulations.

The remainder of this paper is organised as follows. In Section II, we give a brief description of access control mechanism for DLTs and some related network concepts. In Section III, we present Blockchain structure including its commonly used consensus mechanism and DAG-based DLTs. In Section IV, a node model for our access control mechanism and definitions needed in this paper are provided. In Section V, we review the access control protocol described in [10], highlight vulnerabilities, and suggest modifications to suppress these vulnerabilities. Section VI presents simulations to illustrate the efficacy of our approach. Finally, we conclude our paper in Section VII.

Ii Comments on prior work

The topic of designing access control algorithms, and more generally access control mechanisms, is a very rich one in the domain of the computer networking. That said, this topic, is relatively new when considering distributed ledgers, and the design of such algorithms in this specific context gives rise to new and original challenges due to the adversarial nature of the environments in which ledgers are designed to operate. This richness, and simultaneous sparsity, makes a compact discussion of prior work challenging. Our objective here is thus to highlight specific concepts that underpin the work described in this paper, and to provide a hint of the broader context. In terms of DLTs, recently several architectures, have been proposed incorporating access control modules both to guarantee fair writing rights to the network nodes [11, 12], and to prevent spamming attacks [13, 14]. These include both NANO and IOTA [15, 16]. The NANO DLT is particularly interesting when highlighting the need for access control mechanisms. Specifically, the NANO ledger was subjected to attacks that could have been prevented by incorporating an appropriately designed access control mechanism444https://senatusspqr.medium.com/nanos-latest-innovation-feeless-spam- resistance-f16130b13598. Indeed, the motivation for this present paper is the proposed IOTA access control algorithm [10] and the need to make this module robust against certain types of adversarial attacks. In terms of connection to traditional networking work, our work builds heavily on some of the most mature work in this area, with the caveat that algorithm design is revisited from the perspective of operation in adversarial environments, That said, much of the work reported in this paper builds on traditional scheduling algorithms such as Defecit Round Robin (DRR), and flow based access control, such as the Additive-Increase Multiplicative-Decrease (AIMD) algorithm [37]. Such algorithms are well documented in many publications, and we do not repeat this discussion here. Nevertheless, the interested reader is referred to the following publications for more background on these and related topics [17] [18][19] [20] [21].

Iii Preliminaries

Iii-a Blockchain

As we have mentioned, Blockchain is the most famous DLT architecture and was introduced by Satoshi Nakamoto in the Bitcoin whitepaper [22] in 2009. In Blockchain, as in all DLTs, data are replicated across all nodes in a P2P network without a third-party or central authority. Transparency and consistency are ensured as all nodes in the network maintain a copy of the ledger and independently verify each new record. This is done in a manner which makes it very difficult for any node to change the content of the ledger. This property is known as immutability. A high-level diagram of the Blockchain structure is depicted in Figure 1 which we describe next.

In Blockchain, special users called miners are responsible for gathering data and assembling them into blocks that are later added to the Blockchain. Immutability is then guaranteed by the fact that each block is connected to the previous one through a cryptographic mechanism that exploits PoW and hash functions [23]. The aim of this hash-based PoW is to find a nonce value which is smaller than the current target value. A new block will be issued successfully by miners who successfully find such nonce. This solves the problem of double-spending and Sybil attacks555Sybil attack means attackers are trying to get multiple identities in order to gain advantage in a reputation system[24]. at the cost of a large computational expense and a low throughput. For more details, the interested reader can refer to [25] [26] [27].

Fig. 1: A simplified Blockchain structure. The purple block is the new incoming block which need be added to the chain. The green blocks (except the first block also named genesis block) are already added to Blockchain, yellow blocks are similar to green blocks, but in orphan chain.

An alternative to PoW is Proof-of-Stake (PoS) [28]

. In PoS, instead of requiring miners to do computational work, the probability of successfully issuing blocks relies on a quantity called stake that represents a share of the total currency. Namely, the more stake a node has, the higher chance this node can be selected to issue a block. A variant of PoS is called Delegated Proof-of-Stake (DPoS) and is employed, for instance, in BitShares 

[29], EOS [30] and Cosmos [31]. In DPoS, not all nodes are allowed to issue blocks. Every node holding stake votes for its trusted witnesses whose job is to issue and validate blocks as the representative of all nodes. Because there are fewer nodes that participate in block issuing and validating work, the issuing and confirmation speed of blocks results accelerated.

Iii-B DAG-based DLT

Recently a number of DLTs based in directed acyclic graphs (DAGs) have been developed, specifically with a focus on serving the needs of the IoT industry [32]. One such architecture is the IOTA Tangle. A DAG is a graph with no directed cycles and in the IOTA Tangle, each node in the graph represents a transaction. Roughly speaking, the IOTA Tangle operates as follows. New transactions arrive and are appended to the DAG in return for approving existing transactions that have been already added to the DAG but which have not yet been approved by other transaction. This is depicted in Figure 2. Newly arriving transactions (green) randomly select unapproved transactions (purple) and check that these transactions are consistent with each other and the contents of the ledger. Once these selected purple transactions have been validated, they become orange, and the green validating transactions become purple. In the language of the IOTA Tangle, with reference to Figure 2, if there is a directed path between transaction and transaction , we say transaction directly/indirectly approves666https://blog.iota.org/the-tangle-an-illustrated-introduction-1618d3e140ad/ transaction . When new transactions arrive, they validate up to eight (with two as a default) existing transactions which are chosen at random [33]. For further details on the consensus protocol of the Tangle, the interested reader can refer to [33].

Fig. 2: A simplified architecture of ledger

While Figure 2 depicts the architecture of a ledger stored in a single device, multiple copies of the Tangle are stored and synchronized across many devices. This scenario is depicted in Figure 3 and makes evident the need for an access control mechanism which in turn dictates the fairness properties of the ledger and allows the Tangle to resist spamming attacks that might cause the loss of synchronization of the different copies of the ledger in the network. Note that while access is controlled automatically in Blockchain through leader election (e.g., PoW, PoS), no such system naturally arises in the Tangle. Thus, the design of an access control mechanism for lightweight IoT-friendly DLTs, such as the IOTA Tangle, is particularly pressing.

Fig. 3: A peer-to-peer network

Iv System model

We consider a P2P network with a set of nodes where . Each node is connected with neighbours where . Node has a reputation value . Nodes perform two main tasks.

  • Nodes verify the validity of existing transactions (e.g., verifying that the transaction has a valid signature) and participate in conflict (e.g., double spending) resolution. Discussion related to transaction validation and consensus are outside the scope of the paper, but can be found in [34] [35].

  • Nodes issue transactions to transfer data or value transactions. Each transaction must include, among other information, the ID of the issuer, the list of transactions which approves, a timestamp indicating the local current issuing time.

In line with [10], we describe here the main components of the protocol (more information can be found later in the section).

  • Transactions received from neighbours are first filtered to remove invalid ones according to some rules: some typical filters include signature validation and removal of duplicates and old transactions.

  • Filtered transactions are added to the inbox of the node; specifically, the inbox is split into queues in order to differentiate the node issuers, where denotes transactions issued by node in node ’s inbox.

  • We mentioned that nodes can also issue transactions themselves. The issuing rate of each node is controlled by a rate setting algorithm according to the node’s reputation and its inbox length.

  • A scheduling mechanism is employed to schedule transactions from the inbox. The protocol sets a fixed global transaction writing power , where is the rate at which this writing work is done. Hence, the dissemination rate, (see Definition IV.4), can be at most . The reader should note that fixing the scheduling rate is a fundamental component for the successful operation of the protocol defined in [10]. We denote that the rate at which node issues transactions as . In the current version of the protocol this minimum rate is set as .

  • Scheduled transactions are then forwarded to neighbours through a gossip algorithm and added to the local version of the ledger (if they satisfy the consensus protocol of the DLT).

Depending on the transaction issuing rate, a node can be said to be in one of four possible states.

  • Inactive node: A node is said to be inactive if it is not issuing transactions – it only stores the ledger updates and participates in conflict resolution.

  • Content node: We model the issuing rate of a content node as a Poisson process with a rate parameter , where, as we have mentioned, is the minimum allowed rate and is the reputation of node . In other words, content nodes never exceed their fair proportion of the global writing power according to their reputation.

  • Best-effort node: A node is said to be best effort if it is issuing at rate , while obeying the restrictions imposed by the access control algorithm. In practice, if many nodes are inactive or issue transactions occasionally, which is likely to be the case, some nodes may want to exploit the unused bandwidth to issue more transactions than their content rate.

  • Malicious node: A node is said to be malicious if it does not follow the rules imposed by the access control algorithm. Such nodes try to harm the network and affect consistency and fairness by introducing congestion and degrading network performance.

To help the exposition, the notation used in the remainder of the paper is summarized in Tables I and II.

reputation of node
the set of all nodes
the total number of nodes
the queue length for node ’s transactions in node ’s inbox
issuing rate of node
global transaction writing power
the dissemination rate of node
the dissemination rate of all transactions
the maximum deficit for each empty queue
TABLE I: Notation for node and network model.
transaction’s parent
a given fixed time threshold
given constant
solidification requests list
node’s inbox transactions list
transactions list we have already scheduled
the time when any honest node blacklist malicious nodes
reputation-scaled inbox length for node
the threshold of blacklisting a node
the time interval between current time and
TABLE II: Notation for pseudocode.

Finally, we now add a number of definitions to assist the exposition of the sequel.

Definition IV.1 (Past cone).

The past cone of transactions is the set of all transactions which transaction approves either directly or indirectly.

Definition IV.2 (Solid transaction).

If a node has in its ledger all transactions in the past cone of a given transaction, then we say that this transaction is solid. An example of a solid and unsolid transaction are shown in Figure 4.

Fig. 4: A comparison between solid and unsolid transactions. The yellow transaction is solid in the upper ledger, but is not solid in the lower ledger because the lower ledger does not contain the green transaction yet.
Definition IV.3 (Disseminated transaction).

A transaction is said to be disseminated when it reaches all nodes in the network.

Definition IV.4 (Dissemination rate).

The rate of the disseminated transactions issued by node is denoted by . Moreover, denotes the total dissemination rate from all nodes.

Definition IV.5 (Latency).

Latency refers to the period of time between a transaction being issue and when it is added to the ledgers of all other nodes. In case a transaction is not delivered, this will have latency infinity.

The following definitions relate to requirements of the algorithm and are useful when we evaluate the efficacy of the access control algorithm. They are taken directly from [10].

Definition IV.6 (Consistency).

If a transaction issued by an honest node (i.e. a node obeying the proposed protocol) is written by one honest node, it should eventually be written by all honest nodes.

Definition IV.7 (Fairness in dissemination rate).

The fairness in dissemination rate means that the dissemination rate of each node should be allocated proportional to the node’s reputation.

Definition IV.8 (Fairness in latency).

The fairness in latency means that, for a given dissemination rate relative to the node’s reputation, a node’s transactions should experience similar latency. In other words, the latency of a nodes’ transactions is related to reputation-scaled dissemination rate 777 The reputation-scaled dissemination rate is the value that dissemination rate of this node divide the node’s reputation value. Other terms, including reputation-scaled inbox length, are defined similarly to this.and not a node’s own reputation.

Definition IV.9 (Security).

Malicious nodes that arbitrarily deviates from the proposed protocol should be unable to interfere with any of the above requirements.

V Analysis and extensions of [10]

As we have already mentioned, this work builds on the access control algorithm proposed in [10], addressing a number of potential attack scenarios not considered in the introductory paper and considering requirements arising from the DAG structure of the ledger in more detail. We now review the existing algorithm and introduce the improvements proposed in this work.

V-a Access control algorithm in [10]

The congestion algorithm in [10] is organized around three functional components: a scheduling algorithm; a rate setting algorithm; and a buffer management policy.

  • Scheduling: In order to accommodate latency-critical flows arising from bursty arrivals, [10] proposes a modified version of the Deficit Round Robin (DRR) scheduling algorithm, DRR– (DRR minus), where each flow is connected with a queue and is served in a round robin manner [36] according to node reputation.

  • Rate setting: In order to maximize the utilization of the network and ensure that nodes are not overwhelmed, an AIMD method is adopted by each node. Specifically, every node checks the length of its inbox in order to gauge the congestion level of the network and adapts its issue rate accordingly. Relying only on local congestion measurements is enough to evaluate the degree of congestion of the network since transactions are broadcast to all network participants which schedule them at the same rate. Hence, all nodes will see the same number of transactions within a short time-frame. Unlike in TCP, where the protocol considers explicit notification transactions, the usage of local information is fundamental to properly deal with an adversarial environment.

  • Buffer management: When the buffer becomes full, this component drops transactions depending on the number of transactions in the inbox issued by each node, weighted by the issuing node’s reputation.

Fig. 5: Inbox of node . Each transaction in the queue is solid and ordered by timestamp. The dotted red line above represents the blacklisting threshold which is concerned with reputation-scaled inbox length of each node. The deficit every node gets each round is proportional to node reputation.

V-B Extensions of access control in [10]

In [10], a baseline access control algorithm was shown to satisfy requirements and perform well in an honest environment, and demonstrated an ability to filter out the transactions of malicious nodes in the case of a simple attack scenario. However, an extensive security analysis was not performed in [10] and the following key points were not addressed.

  • Blacklisting: While the buffer management scheme proposed in [10] ensures that malicious nodes can not cause the transactions of honest nodes to be dropped, there is no explicit mechanism for blacklisting malicious nodes to avoid wasting resources on malicious spam.

  • Solidification: The buffer management proposed in [10] does not take solidification of transactions within the DAG structured ledger into consideration (see Definition IV.2). In particular, dropping malicious transactions may prevent the solidification of subsequent honest transactions. For example, if node receives transactions from malicious nodes and other new coming transactions have already appended to the ledger, at this time dropping malicious transactions would affect the consistency of the ledger.

  • Attacks: Only a basic attack scenario is considered in [10], which does not account for the ability of a malicious node to send different traffic to different neighbours, operate numerous nodes, or find new peers after being identified as an attacker by its current peers.

We propose to extend the algorithm of [10] by introducing a blacklisting mechanism and a number of modifications to explicitly take the need for solidification and the associated issues into account. These improvements ensure that more advanced attacks can be prevented, as we demonstrate by simulation in Section VI.

V-B1 Blacklisting

We define the reputation-scaled queue length as

(1)

We augment the protocol in [10] by adding a condition , where is the threshold to blacklist a node. As shown in Figure 5, when a node receives transactions from its neighbours, if the reputation-scaled queue length related to node is larger than , then node will blacklist node . Consequently, it will drop any new incoming transactions issued by node , and update the time when node blacklist this misbehaving node (malicious node). We denote this time by . Note that transactions that are already in the inbox of node will be scheduled as normal to avoid potential inconsistencies, as these transactions may have already been added to the local ledger by other nodes in the network.

Additionally, we propose an improved AIMD rate setter. Depending on whether or not blacklisting has occurred recently, two cases are considered. If no blacklisting has happened yet, or the time since the last blacklisting even is greater than a given time threshold , the rate setter follows the same AIMD algorithm as in [10]. Namely, if the reputation-scaled queue length, is larger than a certain threshold , the issuing rate of node decreases through a multiplicative decrease parameter 888Recall that the AIMD algorithm [37] is characterised by two parameters; an additive increase parameter , that determines the rate at which the node probes for available bandwidth; and a multiplicative decrease parameter , that determines the fraction of resource the node releases in response to congestion. In the rate setting defined in [10] these parameters depend on their reputation.. After decreasing the rate, the process of issuing and rate setting waits for seconds to allow the network to stabilise. On the other hand, if is less than , the issuing rate of node increases by local additive increase parameter – the product of . is defined as , where is a global additive increase parameter for all nodes and denotes the writing work needed for a transaction to be added to the ledger. On the other hand, if the time since the last blacklisting event is smaller than a given threshold, , the issuing rate of node is set to be proportional to the issuing rate of a content node, , where the parameter is a given fixed value. The blacklisting algorithm is depicted in Algorithm 1.

Remark: When a node is blacklisted, there is an instantaneous drop in local traffic, and as blacklisting can happen at slightly different times for different nodes, this can cause discrepancies between nodes’ local views of traffic levels. This is particularly critical for best-effort nodes that try to fill the spare bandwidth after when traffic levels drop, which may cause them to be perceived as attackers by their neighbors that have not yet blacklisted the malicious node. For this reason, we pause the rate setting increase for some time after blacklisting.

Remark: The blacklisting method in our work is a local method, requiring no additional global information. Local blacklisting is enough as it is likely that honest neighbours will drop an attacker’s transactions, and hence, these will not be propagated through the network. In the event the attacker tries to change neighbours (i.e., re-peering) then it will be blacklisted by these new neighbours as well. In order to test the efficacy of this designed algorithm, a set of simulations are presented in the next section.

1:Part 1: How to blacklist a malicious node in node’s inbox
2:if Node receive a transaction issued by other nodes then
3:     if  then
4:         Blacklist node
5:         Drop transactions issued by node
6:         Update
7:     end if
8:end if
9:Part 2: Improved AIMD Rate Setter
10:Repeat each time a transaction is issued:
11:if  then
12:     if  then
13:         
14:         Stop rate setting and issuing for seconds
15:     else
16:         
17:     end if
18:else
19:     
20:end if
Algorithm 1 Blacklisting algorithm

V-B2 Solidification requests

Due to the DAG structure of the ledger, and due to delays in the network, it is possible that some transactions at this point might not yet be solid (see Definition IV.2). To avoid these kind of situations, and to maintain consistency of the ledger, we introduce a new component called solidification requests to ensure that all the transactions in the past cone are received by the node. When a transaction arrives at the front of the queue in the node’s inbox, if the transaction is not solid, the node sends a solidification request to ask its neighbours to send the missing transactions in the past cone. The transaction can only be scheduled when it becomes solid (full past-cone is received). By introducing the rule that transactions should not be scheduled until they are solid, we may encounter issues when nodes are blacklisted and the transactions of the blacklisted node are required to solidify. This problem can be further exaggerated by an attacker by sending different streams of transactions to different neighbours. To deal with this problem, we also introduce ordering of transactions in the inbox based on their timestamps, this ensures that transactions are scheduled and forwarded in roughly the same order by all nodes, even if they are received in different order from malicious nodes. Solidification requests are further explored in Section VI, where it is shown that if this component is not deployed, the dissemination rate of the whole network drops to zero. The solidification algorithm is described in Algorithm 2.

1:Repeat each time a transaction is scheduled:
2:if  is  then
3:     if  not in // then
4:         add into
5:     end if
6:else
7:     do normal DRR– scheduler
8:end if
Algorithm 2 Solidification Requests

Vi Simulation results

Vi-a Simulation setup

In order to test the robustness and effectiveness of the designed algorithm under potential attack scenarios, we have built a Python simulator. In what follows, the network used to illustrate our results is composed of 50 nodes, each of which is peered with 4 randomly chosen neighbours. Communication delays between nodes are exponentially distributed in the range from 50 ms to 150 ms. The reputation distribution used in our simulator follows the measured distribution from the IOTA network and is depicted in Figure

6. Specifically, we use the number of transactions issued by each account in the IOTA network, which follows a Zipf distribution999Wealth has also been shown to follow similar distributions, so this model is also well suited to reputation systems derived from wealth, i.e., PoS [38]. with exponent 0.9. The scheduling rate is set to 50 transactions per second. Other relevant parameters are set as follows: the maximum deficit for each empty queue , , , , , , and seconds (see Table III). The effect of parameters, such as increase parameter , the decrease parameter , the work threshold , and the total number of nodes, are shown in [10], the interested reader can refer to that. For each experiment, ten Monte Carlo simulations are performed.

Scheduler Rate Setter Blacklisting
TABLE III: Access control algorithm parameters used in simulations.

In our experiments, there are two types of malicious nodes:

  • The first type are malicious nodes sending above the rate allowed by the rate setter module to its neighbours. We call this a spamming attacker.

  • The second type are malicious nodes that send different streams of transactions to different neighbours, while each stream individually obeys the rate setter indications. These are named multi-rate attackers.

Malicious nodes can simultaneously be both spamming and multi-rate attackers. Furthermore, we assume that attackers can change their neighbours as soon as they detect that they are blacklisted by all neighbours. We call this action “re-peering”, and it results in a more sophisticated attack scenario.

Remark: Multiple coordinated malicious nodes in the system at the same time constitutes a very powerful form of attack. As we shall see, our modified algorithm is able to cope with such a scenario.

The rest of the section is organized as follows. In Section VI-B we consider the following attack scenarios:

  • The first experiment considers a spamming attacker without re-peering.

  • The second experiment considers a spamming attacker with re-peering.

  • The third experiment considers a multi-rate attacker without re-peering.

  • The fourth experiment considers multi-rate attacker with re-peering.

  • The fifth experiment considers multiple nodes attacking the network simultaneously.

Then, in Section VI-C we present an analysis of the robustness of the protocol:

  • The first experiment considers when the nodes’ reputation varies over time.

  • The second experiment considers the impact of active nodes becoming inactive and switching back to being active.

Finally, in Section VI-D a number of experiments are presented to illustrate the improvements of our algorithm compared to [10]. Note that to the best of our knowledge, [10] is the first piece of work which proposes reputation-based access control for DAG-based ledgers and removes the need for PoW for Sybil protection. So here we can only provide this one comparison.

Fig. 6: Reputation distribution follows a Zipf distribution with exponent 0.9. As shown by each bar’s colour, nodes are Best-effort in red, Content in blue, Inactive in grey and malicious in green.

Vi-B Analysis of the access control algorithm in a malicious environment

Vi-B1 Spamming attacker without re-peering


In this subsection, we consider a spamming attacker which issues transactions at a larger rate that allowed by the rate setter module. This malicious node does not reconnect with other neighbors of the network after being blacklisted. Figure 7 and 7 show the dissemination rate and reputation-scaled dissemination rate per node (see Definition IV.4) respectively. We use red lines to plot best-effort nodes, green lines for malicious nodes and blue lines for content nodes. Furthermore, in the plots, the thickness of every line is chosen to be proportional to each node’s reputation. The difference between Figure 7 and 7 is that, 7 depicts the reputation-scaled dissemination rate. From 7, we can see that the value of best effort nodes and content nodes converge to a constant value respectively by the end of the simulation. This means that fair access is eventually ensured for every node. Note that both the dissemination rate and the reputation-scaled dissemination rate of the attacker drop to zero since the malicious node has been blacklisted by all neighbours, hence isolated. This of course means that all transactions from this malicious node will be discarded.

The dissemination rate and the mean latency over all disseminated transactions are presented in Figure 7. In this plot, even when attackers appear, the dissemination rate for all transactions converges to a constant value, as does the mean latency.

The reputation-scaled inbox length of a randomly-chosen neighbor of the attacker is depicted in Figure 7. As can be observed the reputation-scaled inbox length of honest nodes is low. This is especially true between 10 and 50 seconds when the spammer node is trying to fulfill the available bandwidth. This value is also low between 50 seconds to 60 seconds because we have set the malicious nodes neighbours issuing rate to be proportional to that of a content node with their is less than 15 seconds.

The fairness in latency of the revised protocol is validated in Figure 7. In particular, Figure 7 depicts the cumulative density function of the latency of the transactions issued by each node. It is clear from this plot that malicious node’s transactions experience a much higher latency than other transactions: this happens because attacker’s transactions cannot be scheduled by honest nodes over short time scales as they get backlogged at the inboxes of honest nodes before the attacker is blacklisted.

Fig. 7: This set of figures is spamming attacker scenario without re-peering. (a) is dissemination rate of each node and (b) is scaled dissemination rate of each node. (c) is dissemination rate and mean latency for each node. (d) is reputation-scaled inbox length of one randomly selected malicious node’s neighbour. Transactions issued by honest nodes are in red, while transactions issued by malicious nodes are in green. (e) is the cumulative density function of latency across all transactions for all nodes.

Vi-B2 Spamming attacker with re-peering


We now consider the impact of spamming attacker with re-peering after blacklisting. As can be observed, although there are some fluctuations in the scaled dissemination rate caused by malicious nodes re-peering, the dissemination rate converges quickly to a constant value (see Figure 8 and 8). Note also that the dissemination rate of malicious nodes declines quickly to zero. Thus it can be observed that the designed protocol in this paper is also effective in mitigating this type of attack.

Figure 8 depicts the total dissemination rate and the mean latency across all transactions for all nodes, including honest nodes and malicious nodes. Observe that there is a clear decreasing trend for both dissemination rate and latency from time 25 seconds to time 60 seconds. This is due to the gradual blacklisting of the malicious node by all honest nodes (remember that re-peering is enabled). Furthermore, it is interesting to see that malicious node is isolated, the unused bandwidth which was “wasted” by the attacker becomes now available and best-effort nodes can use it.

The reputation-scaled inbox length of a randomly-chosen neighbor of the attacker is depicted in Figure 8. As can be seen, honest nodes blacklist malicious node gradually because of malicious node re-peering behaviour. The grey line shows the percentage of honest nodes that have blacklisted the malicious node over time. The reason why the percentage is not at one hundred is that the malicious node can not blacklist itself.

The fairness in latency of the revised protocol is validated in Figure 8. In particular, Figure 8 depicts the cumulative density function of the latency of the transactions issued by each node. It is same as the previous scenario that malicious node’s transactions experience a much higher latency than other transactions.

Fig. 8: This set of figures is spamming attacker scenario with re-peering. (a) is dissemination rate of each node and (b) is scaled dissemination rate of each node. (c) is dissemination rate and mean latency for each node. (d) is reputation-scaled inbox length of one randomly selected malicious node’s neighbour. Transactions issued by honest nodes are in red, while transactions issued by malicious nodes are in green. The grey line depicts the percentage of how many how many honest nodes have been blacklisted malicious node along with time. (e) is the cumulative density function of latency across all transactions for all nodes.

Vi-B3 Multi-rate attacker without re-peering


We now consider the impact of a multi-rate attacker without re-peering. The dissemination rate and reputation-scaled dissemination rate are shown in Figure 9 and 9. In Figure 9, it can observed that the fairness of dissemination rate is maintained for honest nodes, based on their reputation, throughout the simulation. While malicious nodes steal allocation from other nodes at the beginning of simulation, this effect reduces to zero once malicious nodes spam their neighbours and they are blacklisted.

Figure 9 depicts the latency fairness properties of the network in this scenario. Note that when compared to content and best effort node, malicious nodes experience a much higher latency. The reason for this is as discussed above.

Fig. 9: This set of figures is multi-rate attacker scenario without re-peering. (a) is dissemination rate of each node and (b) is scaled dissemination rate of each node. (c) is the cumulative density function of latency across all transactions for all nodes.

Vi-B4 Multi-rate attacker with re-peering


We now consider the impact of a multi-rate attacker with re-peering. Figure 10 depicts the total dissemination rate and the mean latency across all transactions. Similarly to the previous experiments, attacker temporarily uses resources which it should not be using. Once the attacker is blacklisted, best-effort nodes rapidly detect the unused bandwidth and increase their throughput accordingly (from time 100 seconds onwards).

The reputation-scaled inbox length of a randomly-chosen neighbor of the attacker is depicted in Figure 10. As can be seen, due to the complexity of multi-rate attacks, especially with re-peering, the blacklisting process takes more time than in previous scenarios. The grey line shows the percentage of honest nodes that have blacklisted the malicious node over time. The reason why the percentage does not achieve 100% is same as the spamming attack with re-peering.

Figure 10 depicts the latency fairness properties of the network in this scenario. Note that when compared to content and best effort node, malicious nodes experience a much higher latency. The reason for this is as discussed above. Because of the complexity of the multi-rate attack, the latency of malicious node is much higher than other scenarios.

Fig. 10: This set of figures is multi-rate attacker scenario with re-peering. (a) is dissemination rate and mean latency for each node. (b) is reputation-scaled inbox length of one randomly selected malicious node’s neighbour. Transactions issued by honest nodes are in red, while transactions issued by malicious nodes are in green. The grey line depicts the percentage of how many how many honest nodes have been blacklisted malicious node along with time. (c) is the cumulative density function of latency across all transactions for all nodes.

Vi-B5 Multiple attackers


We now discuss the scenario when multiple malicious nodes simultaneously attack the network. First, we consider an attack performed by five spamming attackers (without re-peering). The reputation distribution of nodes of this experiment is illustrated in Figure 11. As the reader can see, we choose the malicious nodes to be in the top ten nodes by reputation, which means that the a large portion of the total reputation is controlled by malicious entities, making this an exceptionally powerful attack.

The fairness of dissemination rate and scaled dissemination rate is depicted in Figure 11 and 11. Because we have several malicious nodes who are blacklisted by their neighbours at different times, there are fluctuations in the scaled dissemination rate of honest nodes. As it can be observed, the dissemination rate and scaled dissemination rate of malicious nodes approaches zero after they have been blacklisted.

Figure 11 depicts the total dissemination rate and the mean latency across all transactions. Although there is a slight fluctuation when multiple spamming malicious nodes are blacklisted by their neighbours, honest nodes start to issue more transactions to occupy the rest of the bandwidth.

The reputation-scaled inbox length at a randomly-chosen neighbour of the largest-reputation attacker is depicted in Figure 11. The reputation-scaled inbox length of this attacker rapidly increases up to the blacklisting threshold, after which the neighbour starts dropping attacker’s transactions. Conversely, honest nodes’ inbox occupations remain low up to time 60 seconds; after that, when all attackers are blacklisted, best-effort nodes can exploit the bandwidth remained unused and reputation-scaled inbox length slightly increases.

Fig. 11: This set of figures is multiple spamming attackers scenario. (a) is reputation distribution follows a Zipf distribution with exponent 0.9. As shown by each bar’s colour, nodes are Best-effort in red, Content in blue, Inactive in grey and malicious in green. (b) is dissemination rate of each node and (c) is scaled dissemination rate of each node. (d) is dissemination rate and mean latency for each node. (e) is reputation-scaled inbox length of one randomly selected malicious node’s neighbour.

Second, we consider five multi-rate attackers trying to harm the network simultaneously. The reputation distribution in this case is illustrated in Figure 12. As in the previous case, attackers are chosen among the top ten nodes by reputation. Multi-rate attackers provide a more sophisticated way to harm the network and, at the same time, more difficult to detect. The goal of a DLT is to issue a distributed database where all nodes agree on which transactions are in the ledger. When attackers send different streams of transactions to different nodes, they are trying to violate the fairness criterion and using a larger share of transactions than the one that should be guaranteed by their reputation. In our mechanism, a fundamental tool to detect this attack is provided by the fact that the scheduler sorts transactions in the inbox by timestamps: this provides an objective rule that is useful in times of congestion to let all nodes schedule (approximately) the same transactions.

Figure 12 and 12 show the dissemination rate and the reputation-scaled dissemination rate under this attack. We can verify that, even in this case, the attack is successfully repelled. The reputation-scaled inbox length at the a randomly-chosen neighbour of neighbour of the attacker is depicted in Figure 12.

Figure 12 depicts the total dissemination rate and the mean latency across all transactions. As in the multiple spamming attack scenario, although there is a slight fluctuation when multiple spamming malicious nodes are blacklisted by their neighbours, honest nodes start to issue more transactions to occupy the rest of the bandwidth.

The reputation-scaled inbox length at a randomly-chosen neighbour of the largest-reputation attacker is depicted in Figure 12. It is clear that, compared to multiple spamming attacks, multiple multi-rate attacks experience more time and each attacker may increases up to the blacklisting threshold at different time. The similar point is that, after that, when all attackers are blacklisted, best-effort nodes can exploit the bandwidth remained unused and reputation-scaled inbox length slightly increases.

Fig. 12: This set of figures is multiple multi-rate attackers scenario. (a) is reputation distribution follows a Zipf distribution with exponent 0.9. As shown by each bar’s colour, nodes are Best-effort in red, Content in blue, Inactive in grey and malicious in green. (b) is dissemination rate of each node and (c) is scaled dissemination rate of each node. (d) is dissemination rate and mean latency for each node. (e) is reputation-scaled inbox length of one randomly selected malicious node’s neighbour of neighbour.

Vi-C Robustness analysis

We now present a brief discussion to highlight the robustness of our protocol against a set of realistic scenarios. While the experiments in Section VI-B concern a static scenario, in this section we consider that nodes’ reputation will change over time, new nodes will join the network and some of the existing nodes will change their status (from inactive to best-effort to content, and so on).

Vi-C1 Time varying reputation

We consider the impact of a change in reputation of randomly selected nodes. We randomly select two nodes and change their reputation as follows: after seconds, we decrease the reputations of nodes and (resp. best-effort and content) by , and we increase (slightly) the reputation of their neighbors. The changes in reputation are depicted in Figure 13 and with specific reference to Figure 12. The difference in these two figures depicts the change of each node’s reputation in this experiment. Note that in this experiment we are only interested in verifying how the variation in reputation affects the operation of protocol. Consequently, it is not important which nodes are selected. The experiment is performed in an honest environment.

For this specific change in reputation, the dissemination rate, and the scaled dissemination rate of nodes 3 and 4, as well as their neighbours is depicted in Figure 13. It can be clearly observed that there is a decreasing trend in rate for the best-effort node 3 and the content node 4 from about 75 seconds onwards. The increasing dissemination rate of the neighbours of nodes 3 and 4 is marginal. This is because each of them only acquire a small fraction of newly available bandwidth. Note also that although there is a clear spike in dissemination rate when the node reputation changes, the network quickly settles to a new steady state.

The reputation-scaled inbox length of the one randomly-chosen neighbor of the attacker is depicted in Figure 13. As we shall see, although the reputation of several honest nodes are changed during the process, there is not any risk to the system. To be specific, no honest nodes will be blacklisted due sudden loss or gain of reputation.

Two more sets of simulations are presented here to illustrate the robustness and effectiveness of the designed protocol. The percentage decrease in reputation for the two nodes as and the dissemination rate and scaled dissemination rate of each node are depicted in Figure 13. For a decrease of in reputation the dissemination rate and scaled dissemination rate of each node are depicted in Figure 13.

Fig. 13: This set of figures is time varying reputation scenario. (a), (b) and (c) are dissemination rate and scaled dissemination rate of each node. (d) is reputation distribution follows a Zipf distribution with exponent 0.9. As shown by each bar’s colour, nodes are Best-effort in red, Content in blue, Inactive in grey and malicious in green. (e) is reputation-scaled inbox length of one randomly selected node two’s neighbour.

Vi-C2 Active nodes becoming inactive and reverting active

We now consider the impact of nodes going offline and coming back to the network. At time 100 seconds, several best effort nodes, and several content nodes, leave the network, which means they stop issuing transactions. Then at time 200 seconds, these nodes join the network again and restart generating transactions. The dissemination rate and scaled dissemination rate of each node is depicted in Figure 14 and 14. Although the transient fairness of the dissemination rate of some nodes is slightly affected during the interval 100-200 seconds, the value of scaled dissemination rate of each node converges after 200 seconds and achieves fairness eventually.

Vi-D Comparison with protocol in [10]

Finally, to conclude the paper, in this experiment, we compare the revised protocol proposed in this paper with the unmodified one that is described in [10]. In [10], all transactions are ordered by the order they arrive at node’s inbox and a simple DRR– scheduling algorithm is employed to scheduling these transactions in node’s inbox without considering the completeness of the ledger in each node. The problem with this mechanism is that the consistency can not be ensured when attacks occur.

Vi-D1 Basic protocol in [10] without solidification component

The network topology and reputation distribution are as described in scenario A.(1) above. Note, in this experiment, the access control protocol contains no solidification component. The dissemination rate and scaled dissemination rate are depicted in Figure 14 and 14. As can be observed, the dissemination rate and scaled dissemination rate of many honest nodes goes to zero over time, which means that no transaction is being scheduled by all nodes. This is clearly not desirable. The reason behind this outcome is that, when there are no solidification requests, the ledger of each node may contain different transactions. This means different transactions may reach different nodes, but a transaction is only considered to be disseminated if it reaches all honest nodes. So the consistency is not achieved when attacker sends different transactions to different neighbours under the algorithm in [10].

Vi-D2 The protocol in [10] without timestamp ordering component

Again, we retain the same network topology and reputation distribution of each node as in scenario A.(3). The dissemination rate of the network, and the mean latency for each node is depicted in Figure 14. Comparing with Figure 14, which depicts the situation when we have timestamp ordering, it is clear that the protocol is not robust without the timestamp ordering. This is much clearer from 50 seconds to 120 seconds. During this period of time, tn Figure 14, the dissemination rate of all transactions is far over the maximum value 50 and the mean latency is also very high during this long time. In Figure 14, while there is a slight increasing of mean latency, it converges to a stable value very quickly.

Fig. 14: (a) and (b) are dissemination rate and scaled dissemination rate in scenario which active nodes becoming inactive and reverting active, while the rest plots are contrast experiments with [10]. (c) and (d) are dissemination rate and scaled dissemination rate. (e) is dissemination rate and mean latency for each node in [10], while (f) is dissemination rate and mean latency for each node in this work.

Vii Conclusions

In this paper, an improved access control algorithm for DAG based DLT is designed to improve the security and robustness of such a network. A blacklisting algorithm, which is based on a reputation-weighted threshold, is introduced to handle both spamming and multi-rate malicious attackers. The introduction of a solidification request component is also introduced to ensure the fairness and consistency of network in the presence of attacks. Finally, a timestamp component is also introduced to maintain the consistency of the network in the presence of multi-rate attackers. Simulations to illustrate the robustness of the protocol are also described. Future work will focus on maintaining network utilization in the presence of attacks.

References

  • [1] P. Ferraro, C. King, and R. Shorten. Distributed ledger technology for smart cities, the sharing economy, and social compliance. IEEE Access, 6:62728–62746, 2018.
  • [2] Nikita Singh and Manu Vardhan. Distributed ledger technology based property transaction system with support for iot devices. International Journal of Cloud Applications and Computing (IJCAC), 9(2):60–78, 2019.
  • [3] Pietro Ferraro, Christopher King, and Robert Shorten. Distributed ledger technology, cyber-physical systems, and social compliance. arXiv preprint arXiv:1807.00649, 2018.
  • [4] Hong-Ning Dai, Zibin Zheng, and Yan Zhang. Blockchain for internet of things: A survey. IEEE Internet of Things Journal, 6(5):8076–8094, 2019.
  • [5] Marc Pilkington. Blockchain technology: principles and applications. In Research handbook on digital transformations. Edward Elgar Publishing, 2016.
  • [6] Andrew Cullen, Pietro Ferraro, Christopher King, and Robert Shorten. On the resilience of dag-based distributed ledgers in iot applications. IEEE Internet of Things Journal, 7(8):7112–7122, 2020.
  • [7] Yixin Li, Bin Cao, Mugen Peng, Long Zhang, Lei Zhang, Daquan Feng, and Jihong Yu. Direct acyclic graph-based ledger for internet of things: performance and security analysis. IEEE/ACM Transactions on Networking, 28(4):1643–1656, 2020.
  • [8] Serguei Popov. The tangle. White paper, 1:3, 2018.
  • [9] Iddo Bentov, Ariel Gabizon, and Alex Mizrahi. Cryptocurrencies without proof of work. In International conference on financial cryptography and data security, pages 142–157. Springer, 2016.
  • [10] A Cullen, P Ferraro, W Sanders, L Vigneri, and R Shorten. Access control for distributed ledgers in the internet of things: A networking approach. arXiv:2005.07778v3, 2021.
  • [11] Damiano Di Francesco Maesa, Paolo Mori, and Laura Ricci. Blockchain based access control. In IFIP international conference on distributed applications and interoperable systems, pages 206–220. Springer, 2017.
  • [12] Aissam Outchakoucht, ES Hamza, and Jean Philippe Leroy.

    Dynamic access control policy based on blockchain and machine learning for the internet of things.

    Int. J. Adv. Comput. Sci. Appl, 8(7):417–424, 2017.
  • [13] Jiejun Hu, Martin Reed, Nikolaos Thomos, Mays F AI-Naday, and Kun Yang. Securing sdn-controlled iot networks through edge blockchain. IEEE Internet of Things Journal, 8(4):2102–2115, 2020.
  • [14] Qingqiang He, Nan Guan, Mingsong Lv, and Wang Yi. On the consensus mechanisms of blockchain/dlt for internet of things. In 2018 IEEE 13th International Symposium on Industrial Embedded Systems (SIES), pages 1–10. IEEE, 2018.
  • [15] Colin LeMahieu. Nano: A feeless distributed cryptocurrency network. Nano [Online resource]. URL: https://nano. org/en/whitepaper (date of access: 24.03. 2018), 2018.
  • [16] Sandeep Kiran Pinjala and Krishna M Sivalingam. Dcaci: A decentralized lightweight capability based access control framework using iota for internet of things. In 2019 IEEE 5th World Forum on Internet of Things (WF-IoT), pages 13–18. IEEE, 2019.
  • [17] TV Lakshman and Upamanyu Madhow. The performance of tcp/ip for networks with high bandwidth-delay products and random loss. IEEE/ACM transactions on networking, 5(3):336–350, 1997.
  • [18] A. Demers and X. Parc. Analysis and simulation of a fair queueing algorithm. Computer communication review, 25(1):p.174–187, 1995.
  • [19] Go Hasegawa and Masayuki Murata. Analysis of dynamic behaviors of many tcp connections sharing tail-drop/red routers. In GLOBECOM’01. IEEE Global Telecommunications Conference (Cat. No. 01CH37270), volume 3, pages 1811–1815. IEEE, 2001.
  • [20] Rong Pan, Lee Breslau, Balaji Prabhakar, and Scott Shenker. Approximate fairness through differential dropping. ACM SIGCOMM Computer Communication Review, 33(2):23–39, 2003.
  • [21] Sally Floyd and Van Jacobson. Random early detection gateways for congestion avoidance. IEEE/ACM Transactions on networking, 1(4):397–413, 1993.
  • [22] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. Technical report, Manubot, 2019.
  • [23] Arthur Gervais, Ghassan O Karame, Karl Wüst, Vasileios Glykantzis, Hubert Ritzdorf, and Srdjan Capkun. On the security and performance of proof of work blockchains. In Proceedings of the 2016 ACM SIGSAC conference on computer and communications security, pages 3–16, 2016.
  • [24] John R Douceur. The sybil attack. In International workshop on peer-to-peer systems, pages 251–260. Springer, 2002.
  • [25] Ismail Butun and Patrik Österberg. A review of distributed access control for blockchain systems towards securing the internet of things. IEEE Access, 2020.
  • [26] Andrew Cullen, Pietro Ferraro, Robert Shorten, William Sanders, and Luigi Vigneri. Access control in adversarial environments for iot-oriented distributed ledgers. In 2021 IFIP/IEEE International Symposium on Integrated Network Management (IM), pages 968–973. IEEE, 2021.
  • [27] Yang Xu, Ju Ren, Guojun Wang, Cheng Zhang, Jidian Yang, and Yaoxue Zhang. A blockchain-based nonrepudiation network computing service scheme for industrial iot. IEEE Transactions on Industrial Informatics, 15(6):3632–3641, 2019.
  • [28] Dylan Yaga, Peter Mell, Nik Roby, and Karen Scarfone. Blockchain technology overview. arXiv preprint arXiv:1906.11078, 2019.
  • [29] Fabian Schuh and Daniel Larimer. Bitshares 2.0: general overview. accessed June-2017.[Online]. Available: http://docs. bitshares. org/downloads/bitshares-general. pdf, 2017.
  • [30] Elad Elrom. Eos. io wallets and smart contracts. In The Blockchain Developer, pages 213–256. Springer, 2019.
  • [31] Jae Kwon and Ethan Buchman. Cosmos whitepaper, 2019.
  • [32] Huma Pervez, Muhammad Muneeb, Muhammad Usama Irfan, and Irfan Ul Haq. A comparative analysis of dag-based blockchain architectures. In

    2018 12th International Conference on Open Source Systems and Technologies (ICOSST)

    , pages 27–34. IEEE, 2018.
  • [33] Serguei Popov, Hans Moog, Darcy Camargo, Angelo Capossele, Vassil Dimitrov, Alon Gal, Andrew Greve, Bartosz Kusmierz, Sebastian Mueller, Andreas Penzkofer, et al. The coordicide. Accessed Jan, pages 1–30, 2020.
  • [34] Jiahao He, Guangju Wang, Guangyuan Zhang, and Jiheng Zhang. Consensus mechanism design based on structured directed acyclic graphs. Blockchain: Research and Applications, page 100011, 2021.
  • [35] Yang Xiao, Ning Zhang, Wenjing Lou, and Y Thomas Hou. A survey of distributed consensus protocols for blockchain networks. IEEE Communications Surveys & Tutorials, 22(2):1432–1465, 2020.
  • [36] Madhavapeddi Shreedhar and George Varghese. E cient fair queuing using de cit round robin. IEEE/ACM Transactions on networking, 4(3):375–385, 1996.
  • [37] Martin Corless, Christopher King, Robert Shorten, and Fabian Wirth. AIMD dynamics and distributed resource allocation. SIAM, 2016.
  • [38] Charles I Jones. Pareto and piketty: The macroeconomics of top income and wealth inequality. Journal of Economic Perspectives, 29(1):29–46, 2015.