---
title: Advanced DAG-Based Ranking (ADR)
url: https://www.emergentmind.com/topics/advanced-dag-based-ranking-adr
type: topic
---

# Advanced DAG-Based Ranking (ADR)

Searching arXiv for the cited ADR and related DAG-ordering papers.
Advanced DAG-based Ranking (ADR) is a private-blockchain consensus design that combines a directed acyclic graph (DAG) ledger structure, a ranking-based node election mechanism, and a session-control layer for node admission, expulsion, and isolation. In the formulation reported in "Advanced DAG-Based Ranking (ADR) Protocol for Blockchain Scalability" [2508.04000], ADR was proposed to address low throughput, high latency, poor scalability, and the difficulty of managing node identities and malicious behavior in conventional blockchain systems. Its defining structure is a three-step protocol: nodes are first verified using public and private keys, an advanced DAG ledger is then constructed for block production and transaction validation, and finally a ranking algorithm filters malicious nodes, ranks the remaining nodes based on performance, and arranges them topologically [2508.04000]. Within the broader literature on DAG-based ledgers and DAG ordering, ADR belongs to a family of systems in which partial-order structures are converted into operational consensus orderings, but it places particular emphasis on identity-aware ranking and session control in private blockchain settings [1910.02059], [2407.02167].

## 1. Protocol definition and design rationale

ADR is presented as a DAG-based alternative to traditional linear-chain blockchains. In the reported design, a block may reference multiple prior blocks rather than one previous block, and honest nodes are allowed to write blocks and verify transactions using a DAG-based topology [2508.04000]. The protocol is motivated by the claim that conventional chain-based consensus is too restrictive because each block points to only one predecessor, which limits concurrency; by contrast, ADR uses a DAG structure to allow more parallelism [2508.04000].

The protocol is explicitly described as a private blockchain. This is because its selection mechanism depends on identity, authentication, and historical behavior, and because nodes are authenticated with public/private keys and then ranked according to reputation and performance [2508.04000]. The ranking mechanism acts as an incentive mechanism instead of Proof-of-Work mining rewards [2508.04000].

In comparative positioning, ADR is distinguished from several earlier DAG-based and blockchain systems. Relative to traditional blockchain, it replaces the single linear chain with a DAG ledger, allows a block to reference multiple prior blocks, rewards nodes with higher rank rather than coins, uses ranking to filter malicious nodes and select consensus participants, and adds Session Control Protocol (SCP) support for dynamic join/leave control [2508.04000]. Relative to IOTA, ByteBall, Spectre, Phantom, and Conflux, the paper characterizes ADR as combining ranking, topological ordering, and session control to make consensus more deterministic and secure for private blockchain settings [2508.04000]. A plausible implication is that the design goal is not merely throughput scaling, but throughput scaling under explicit membership management.

## 2. Three-step operational structure

ADR is specified as a three-step strategy. The first step is node verification using public/private keys under the Session Control Protocol. A node submits an entry request, its public key and private key are checked, and, if valid, it is assigned a default rank and a wallet/account; if invalid or unstable, it is treated as faulty and may be expelled [2508.04000]. The entry request is defined as
\[
R_{en} = (K_{pb}, K_{pr}, NR) \tag{6}
\]
and the confirmation message is
\[
PrepareRequest = ((R_{en}), sign). \tag{7}
\]
For leaving the system, the paper defines
\[
R_L = (K_{Pb}, K_{pr}, IR) \tag{8}
\]
and the leave confirmation
\[
PrepairJoinRequest = ((R_L), sign). \tag{9}
\]

The second step is advanced DAG ledger construction for block production and transaction validation. The consensus structure is defined as
\[
G = (E, V)/(ul/sl) \tag{1}
\]
with
\[
V = \{a \mid a \in R \cup B \cup L \cup T\}, \quad E = \{(a,b)\mid a \leftarrow b,\ \{a,b\}\in V\}.
\]
Here, a vertex can represent a transaction \(T\), a block \(B\), or a layer \(L\), and \(a \leftarrow b\) means \(b\) confirms \(a\) [2508.04000]. The DAG is divided into an S-Layer and a U-Layer, corresponding respectively to secured and unsecured layers, and transactions enter the mempool before being included in a block [2508.04000].

The third step is the ranking algorithm. It computes node rank values, removes malicious or unstable nodes, selects honest nodes for block production and validation, and topologically orders blocks or nodes in the DAG [2508.04000]. This third step is the defining feature of the protocol as named.

## 3. Ledger structure, block formation, and ordering

The reported ADR block structure contains a BlockHeader, PrevHash, Timestamp, MerkleRoot, BlockHash, and BlockBody [2508.04000]. PrevHash is described as an encrypted hash including previous block hash; BlockHash is described as a double SHA-256 hash of the header, a 32-byte digital fingerprint; Timestamp indicates when the block was added; the Merkle Tree and MerkleRoot store transaction hashes and support verification; and BlockBody contains transactions and their Merkle tree hashes [2508.04000].

The new-block event is given as Algorithm 1 in the source description:

```text
procedure newblock(valid_node, new_event1)
2. blocks1.append(new_event1.payload1)
3. tip = dag_head[block_length]. append(hash(new_event1.payload1))
4. hash = joining(hash(new_event1. payload1))
5. nodeList <- ADR consensus algorithm
6. Broadcast(new_event1.payload1)
7. ts = time.now()
8. new <- new + random exp()
9. Generate next block event at new_event1 generateNewBlock (tm, hash, tip)
10. return block_length
end procedure
```

This procedure describes a valid node appending a new transaction or event, updating the DAG tip, broadcasting the event, timestamping it, and generating the next block event [2508.04000]. The reported interpretation is that the protocol enables parallel block production and validation rather than serial chain extension [2508.04000].

ADR also includes a block-ordering procedure that organizes blocks into confirmed and unconfirmed lists:

```text
procedure BlockOrdering
2. Initialize the block list
3. todo_p.push(genesisBlock)
4. while_block_p == 0 do
5.   B <- todo_p.pop()
6.   if(orderlist(n) == u){
7.      orderList_conf.add(B)
8.      child(B) <- {j:(j,B) € E)
9.      Sort(child(B)) based on their hash values
10.  } else
11.      todo_p.push(C)
12.      ordListnon_conf.add(B)
13.  end if
14. end while
15. return ordList
end procedure
```

In this algorithm, ordering begins with the genesis block, traverses the DAG, separates blocks into confirmed and non-confirmed sets, sorts child blocks by hash values, and returns an ordered block list [2508.04000]. Within the broader DAG-consensus literature, this kind of mechanism corresponds to converting a partial-order structure into an operational order. "Reusable Formal Verification of DAG-based Consensus Protocols" [2407.02167] describes this general task as building a local DAG that represents a partial order of vertices and then totally ordering the vertices by agreeing on leader or anchor vertices and deterministically linearizing causal histories. ADR does not use that exact leader-commit formalism, but the comparison is structurally relevant because both approaches address DAG ordering as a distinct phase [2407.02167].

## 4. Ranking model and malicious-node filtering

The ranking subsystem is the central mechanism of ADR. The paper states that node rank is based on ranking points, resources occupied, ratio of faulty nodes, and acyclic graph layer level [2508.04000]. The rank equation is given as
\[
R_k = f(P, U, R)
\]
and specifically
\[
R_k = C_1P + C_2U + C_3R. \tag{2}
\]
In this notation, \(R_k\) is node rank, \(P\) is private key authentication, \(U\) is resources occupied, \(R\) is current rank, and \(C_1, C_2, C_3\) are constants [2508.04000].

The paper further defines a recursive ranking process inspired by link analysis. Initially, every address gets rank \(1/N\), where \(N\) is the number of nodes [2508.04000]. The update rule is reported as
\[
NR = (1-i) \cdot \frac{FR_1}{OL_1} + \cdots + \frac{FR_n}{OL_n} \tag{3}
\]
where \(NR\) is the rank of node \(A\), \(FR\) is the rank of the forward or subsequent linked node, \(OL_n\) is the number of outbound links, and \(i\) is the initial rank factor with \(0 < i \le 1\) [2508.04000]. The accompanying explanation states that each additional inbound link increases a node’s rank, outbound links dilute the influence of a node’s rank, and rank is updated recursively based on the ranks of linked nodes [2508.04000]. To avoid equal ranks, the paper rewrites the forward-rank term as
\[
FR \sim \_\_\_ (NR). \tag{4}
\]
The notation is explicitly described as informal in the supplied details, but the reported intent is to break ties and make forward rank depend on node rank [2508.04000].

Algorithm 3 gives the reported node-ranking procedure:

```text
procedure RankNodes(valid node, node key)
2. if key == true then
3.   if nodes == "new" then RankNewNode(node);
5.   else if(verifyRankNode(node) !< 0); FR = getForward(node);
7.        OL = getoutBack(node);
8.        calculates the new rank
10.  else
11.        sessionProtocol(node);
12. else
13.   sessionProtocol(node);
```

The described behavior is that the procedure first checks key validity, ranks new nodes, updates rank for existing nodes if their rank is nonnegative, uses `getForward(node)` and `getoutBack(node)` to compute rank evolution, and invokes SCP for nodes that fail verification [2508.04000]. Malicious nodes are described as obtaining negative or unstable ranks and being discarded, whereas honest nodes with better performance and valid behavior receive higher ranks and are more likely to participate in consensus [2508.04000].

This ranking-centered design is distinct from the block-ranking approach used in "Fairness and Efficiency in DAG-based Cryptocurrencies" [1910.02059]. That work studies an honest DAG ranking rule over blocks,
\[
f(B_t) = \alpha D(B_t) + \beta w(B_t), \qquad \alpha\in[0,1],\ \beta=1-\alpha,
\]
where ranking depends on block depth and weight, and validity is extracted from the closure of the top-scoring leaves [1910.02059]. ADR instead ranks nodes rather than blocks. This suggests that the term "ranking" in ADR refers primarily to participant selection and only secondarily to topological arrangement.

## 5. Session Control Protocol and fault handling

ADR uses the Session Control Protocol to manage node membership and maintain continuity under node churn or adversarial behavior. New nodes send the entry request
\[
R_{en} = (K_{pb}, K_{pr}, NR),
\]
the primary node verifies the request and broadcasts a confirmation, and faulty or low-reputation nodes are expelled using the leave request
\[
R_L = (K_{Pb}, K_{pr}, IR). 
\]
If the number of consensus nodes drops too low, dynamic joining is triggered [2508.04000].

The stated role of SCP is to ensure that malicious nodes are isolated, the network does not crash when nodes join or leave, consensus continues to satisfy its fault threshold, and entry or exit happens securely with signed confirmations [2508.04000]. The paper also defines malicious nodes as a set \(N_m\), honest or true nodes as \(N_{tr}\), and states
\[
N_T = N_{ur} \cup N_m. \tag{5}
\]
It refers to a threshold condition for liveness and says that the system remains live if the number of malicious nodes remains within the tolerated bound, consistent with the familiar \((n-1)/3\) style fault assumption used in Byzantine settings [2508.04000].

Liveness is defined in distributed-systems terms: validators eventually reach consensus, the protocol can continue to communicate and make progress, and malicious DoS-style miners should not halt the system [2508.04000]. The paper claims that ADR can tolerate malicious activity and maintain liveness by filtering low-rank nodes, using digital signatures, validating hashes of world states, and requiring consistency checks from multiple nodes [2508.04000]. It further states that consistency can be identified with probability over 99% and that current ledger state hash values should be persisted from at least 5 nodes during verification [2508.04000].

Within the broader DAG-consensus literature, this membership-control emphasis is not universal. "Reusable Formal Verification of DAG-based Consensus Protocols" [2407.02167] focuses instead on a network of \(n\) processes with up to \(f\) Byzantine processes, with \(n \ge 3f + 1\), and on verified safety properties such as prefix consistency and monotone leader commitment. ADR does not appear in that verification framework, but the juxtaposition clarifies that ADR’s distinctive contribution is identity-aware session control combined with ranking, rather than reusable formal proof of ordering safety [2407.02167].

## 6. Performance claims and comparative positioning

The throughput formula used in the ADR paper is
\[
T = T_j/N \tag{10}
\]
where \(T\) is throughput, \(T_j\) is block time, and \(N\) is the total number of transactions during that time [2508.04000]. Throughput, expressed in TPS, is the main metric used to assess scalability [2508.04000].

The implementation details reported for evaluation include a blockchain framework written in Golang and experiments on EC2 clusters. The cluster machines are described as running Ubuntu 16.04 with a 2-core Intel Core i5 2.4 GHz CPU, 8 GB RAM, and 256 GB SSD [2508.04000]. The scale descriptions include tests with more than 100 nodes on EC2 clusters in the abstract, a prototype with approximately 30–40 nodes in the summary, a simulation environment with maximum 40 nodes and an initial committee of 10 simulated machines, additional experiments with 20 nodes for fault tolerance, and 100 nodes with 200 shards for epoch transition tests [2508.04000]. Reported workload details include about 20 blocks for throughput evaluation, latency tests at node counts 50, 70, 90, 110, 130, and 150, 15 tests per block for latency, 50 experiments for fault tolerance, 10 blocks with various transactions for epoch tests, and node capabilities varied from 5% to 100% [2508.04000].

The main reported outcomes are summarized below.

| Category | Reported result | Comparison basis |
|---|---|---|
| Throughput | Early throughput below 1300 TPS; after about 8 epochs stabilized at an average of 1600 TPS | IOTA, ByteBall, and Phantom around 900 TPS in the average-throughput comparison |
| Latency | Substantially lower latency than IOTA and ByteBall across tested node sizes | Tested at 50, 70, 90, 110, 130, 150 nodes |
| Fault tolerance | Better liveness and throughput than IOTA and Phantom under faulty-node injection | Malicious nodes injected up to the \(n - 1/3\) factor |

The paper also reports that malicious nodes took about 10 epochs to regain enough rank to be chosen again [2508.04000]. In its comparison table, ADR is characterized as a private blockchain with ranking-based consensus, fee-less operation, digital-signature authentication, improved data management or confidentiality, and better throughput than the compared systems [2508.04000]. Approximate throughput figures listed in that comparison table include Bitcoin at 7 TPS, Ethereum at 8–9 TPS, IOTA at 850 TPS, ByteBall at 15 TPS, and Phantom at 1250 TPS [2508.04000].

These results are presented as performance claims of the ADR paper itself. A plausible implication is that the protocol’s empirical case rests on the interaction of three mechanisms rather than on DAG structure alone: authenticated admission, rank-based participant filtering, and topological block ordering.

## 7. Relation to adjacent DAG-ranking literature

ADR uses the phrase "Advanced DAG-based Ranking" explicitly as the name of a blockchain protocol [2508.04000]. In the surrounding literature, however, closely related ideas appear under different technical forms. In "Fairness and Efficiency in DAG-based Cryptocurrencies" [1910.02059], ranking is a block-selection rule over visible leaves in a block DAG. The valid block DAG is defined as
\[
VB(G) = \Gamma(\{\ell_1,\dots,\ell_k\}\mid G),
\]
where \(\ell_1,\dots,\ell_k\) are the \(k\) leaves with highest score under \(f\), and in the honest setting valid transactions can be taken to be the transactions appearing in valid blocks [1910.02059]. That framework shows that fairness and efficiency can break down when miners have differing levels of connectivity, even when everyone behaves honestly [1910.02059]. This is relevant context because it indicates that DAG structure and ranking rules alone do not guarantee fair or efficient behavior under partial information.

In "Reusable Formal Verification of DAG-based Consensus Protocols" [2407.02167], the ordering problem is formalized as follows: each process builds a local DAG representing a partial order, the protocol selects a sequence of leader or anchor vertices, and the vertices in the causal history of those anchors are deterministically linearized, for example by topological sort [2407.02167]. The paper verifies five protocols—DAG-Rider, Cordial Miners, Hashgraph, Eventually synchronous BullShark, and an Aleph variant—using reusable TLA+ specifications and TLAPS proofs [2407.02167]. The relevance to ADR is conceptual rather than direct: ADR also couples DAG construction with a later ordering phase, but its reported contribution lies in rank-based node selection and SCP, not in a formally verified leader-consensus specification.

A third adjacent use of DAG ranking appears outside blockchain. "RFID: Towards Low Latency and Reliable DAG Task Scheduling over Dynamic Vehicular Clouds" [2208.12568] uses a dynamic downward ranking mechanism, a resource scarcity-based priority changing mechanism, and a degree-based weighted earliest finish time mechanism for DAG task scheduling [2208.12568]. This paper is not about blockchain consensus, but it shows that "advanced DAG ranking" can also denote topology-sensitive prioritization under dynamic constraints. That contrast helps delimit ADR’s meaning: in ADR, ranking is tied to authenticated nodes, behavior filtering, and topological arrangement in a private blockchain rather than to generic DAG scheduling [2508.04000], [2208.12568].

Taken together, these related works indicate that DAG-based systems typically separate at least three concerns: DAG construction, ranking or representative selection, and final ordering or extraction of valid output [1910.02059], [2407.02167]. ADR adopts that general separation but instantiates it through identity verification, rank-driven participant control, and hash-based topological block ordering in a private-blockchain environment [2508.04000].

Source: https://www.emergentmind.com/topics/advanced-dag-based-ranking-adr