Advanced DAG-Based Ranking (ADR)
- ADR is a private blockchain protocol that uses a three-step process—node verification, DAG ledger construction, and ranking—to enhance scalability and security.
- The protocol constructs an advanced DAG ledger for parallel block production and transaction validation, significantly improving throughput and reducing latency.
- ADR employs a session control mechanism that dynamically manages node membership, filtering malicious nodes through identity-aware ranking.
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" (Noreen et al., 6 Aug 2025), 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 (Noreen et al., 6 Aug 2025). 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 (Birmpas et al., 2019, Bertrand et al., 2024).
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 (Noreen et al., 6 Aug 2025). 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 (Noreen et al., 6 Aug 2025).
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 (Noreen et al., 6 Aug 2025). The ranking mechanism acts as an incentive mechanism instead of Proof-of-Work mining rewards (Noreen et al., 6 Aug 2025).
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 (Noreen et al., 6 Aug 2025). 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 (Noreen et al., 6 Aug 2025). 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 (Noreen et al., 6 Aug 2025). 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
Here, a vertex can represent a transaction , a block , or a layer , and means $PrepareRequest = ((R_{en}), sign). \tag{7}$0 confirms $PrepareRequest = ((R_{en}), sign). \tag{7}$1 (Noreen et al., 6 Aug 2025). 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 (Noreen et al., 6 Aug 2025).
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 (Noreen et al., 6 Aug 2025). 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 (Noreen et al., 6 Aug 2025). 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 (Noreen et al., 6 Aug 2025).
The new-block event is given as Algorithm 1 in the source description:
$G = (E, V)/(ul/sl) \tag{1}$8
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 (Noreen et al., 6 Aug 2025). The reported interpretation is that the protocol enables parallel block production and validation rather than serial chain extension (Noreen et al., 6 Aug 2025).
ADR also includes a block-ordering procedure that organizes blocks into confirmed and unconfirmed lists:
$G = (E, V)/(ul/sl) \tag{1}$9
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 (Noreen et al., 6 Aug 2025). 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" (Bertrand et al., 2024) 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 (Bertrand et al., 2024).
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 (Noreen et al., 6 Aug 2025). The rank equation is given as
$PrepareRequest = ((R_{en}), sign). \tag{7}$2
and specifically
$PrepareRequest = ((R_{en}), sign). \tag{7}$3
In this notation, $PrepareRequest = ((R_{en}), sign). \tag{7}$4 is node rank, $PrepareRequest = ((R_{en}), sign). \tag{7}$5 is private key authentication, $PrepareRequest = ((R_{en}), sign). \tag{7}$6 is resources occupied, $PrepareRequest = ((R_{en}), sign). \tag{7}$7 is current rank, and $PrepareRequest = ((R_{en}), sign). \tag{7}$8 are constants (Noreen et al., 6 Aug 2025).
The paper further defines a recursive ranking process inspired by link analysis. Initially, every address gets rank $PrepareRequest = ((R_{en}), sign). \tag{7}$9, where $R_L = (K_{Pb}, K_{pr}, IR) \tag{8}$0 is the number of nodes (Noreen et al., 6 Aug 2025). The update rule is reported as
$R_L = (K_{Pb}, K_{pr}, IR) \tag{8}$1
where $R_L = (K_{Pb}, K_{pr}, IR) \tag{8}$2 is the rank of node $R_L = (K_{Pb}, K_{pr}, IR) \tag{8}$3, $R_L = (K_{Pb}, K_{pr}, IR) \tag{8}$4 is the rank of the forward or subsequent linked node, $R_L = (K_{Pb}, K_{pr}, IR) \tag{8}$5 is the number of outbound links, and $R_L = (K_{Pb}, K_{pr}, IR) \tag{8}$6 is the initial rank factor with $R_L = (K_{Pb}, K_{pr}, IR) \tag{8}$7 (Noreen et al., 6 Aug 2025). 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 (Noreen et al., 6 Aug 2025). To avoid equal ranks, the paper rewrites the forward-rank term as
$R_L = (K_{Pb}, K_{pr}, IR) \tag{8}$8
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 (Noreen et al., 6 Aug 2025).
Algorithm 3 gives the reported node-ranking procedure:
0
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 (Noreen et al., 6 Aug 2025). 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 (Noreen et al., 6 Aug 2025).
This ranking-centered design is distinct from the block-ranking approach used in "Fairness and Efficiency in DAG-based Cryptocurrencies" (Birmpas et al., 2019). That work studies an honest DAG ranking rule over blocks,
$R_L = (K_{Pb}, K_{pr}, IR) \tag{8}$9
where ranking depends on block depth and weight, and validity is extracted from the closure of the top-scoring leaves (Birmpas et al., 2019). 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
$PrepairJoinRequest = ((R_L), sign). \tag{9}$0
the primary node verifies the request and broadcasts a confirmation, and faulty or low-reputation nodes are expelled using the leave request
$PrepairJoinRequest = ((R_L), sign). \tag{9}$1
If the number of consensus nodes drops too low, dynamic joining is triggered (Noreen et al., 6 Aug 2025).
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 (Noreen et al., 6 Aug 2025). The paper also defines malicious nodes as a set $PrepairJoinRequest = ((R_L), sign). \tag{9}$2, honest or true nodes as $PrepairJoinRequest = ((R_L), sign). \tag{9}$3, and states
$PrepairJoinRequest = ((R_L), sign). \tag{9}$4
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 $PrepairJoinRequest = ((R_L), sign). \tag{9}$5 style fault assumption used in Byzantine settings (Noreen et al., 6 Aug 2025).
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 (Noreen et al., 6 Aug 2025). 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 (Noreen et al., 6 Aug 2025). 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 (Noreen et al., 6 Aug 2025).
Within the broader DAG-consensus literature, this membership-control emphasis is not universal. "Reusable Formal Verification of DAG-based Consensus Protocols" (Bertrand et al., 2024) focuses instead on a network of $PrepairJoinRequest = ((R_L), sign). \tag{9}$6 processes with up to $PrepairJoinRequest = ((R_L), sign). \tag{9}$7 Byzantine processes, with $PrepairJoinRequest = ((R_L), sign). \tag{9}$8, 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 (Bertrand et al., 2024).
6. Performance claims and comparative positioning
The throughput formula used in the ADR paper is
$PrepairJoinRequest = ((R_L), sign). \tag{9}$9
where $G = (E, V)/(ul/sl) \tag{1}$0 is throughput, $G = (E, V)/(ul/sl) \tag{1}$1 is block time, and $G = (E, V)/(ul/sl) \tag{1}$2 is the total number of transactions during that time (Noreen et al., 6 Aug 2025). Throughput, expressed in TPS, is the main metric used to assess scalability (Noreen et al., 6 Aug 2025).
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 (Noreen et al., 6 Aug 2025). 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 (Noreen et al., 6 Aug 2025). 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% (Noreen et al., 6 Aug 2025).
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 $G = (E, V)/(ul/sl) \tag{1}$3 factor |
The paper also reports that malicious nodes took about 10 epochs to regain enough rank to be chosen again (Noreen et al., 6 Aug 2025). 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 (Noreen et al., 6 Aug 2025). 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 (Noreen et al., 6 Aug 2025).
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 (Noreen et al., 6 Aug 2025). In the surrounding literature, however, closely related ideas appear under different technical forms. In "Fairness and Efficiency in DAG-based Cryptocurrencies" (Birmpas et al., 2019), ranking is a block-selection rule over visible leaves in a block DAG. The valid block DAG is defined as
$G = (E, V)/(ul/sl) \tag{1}$4
where $G = (E, V)/(ul/sl) \tag{1}$5 are the $G = (E, V)/(ul/sl) \tag{1}$6 leaves with highest score under $G = (E, V)/(ul/sl) \tag{1}$7, and in the honest setting valid transactions can be taken to be the transactions appearing in valid blocks (Birmpas et al., 2019). That framework shows that fairness and efficiency can break down when miners have differing levels of connectivity, even when everyone behaves honestly (Birmpas et al., 2019). 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" (Bertrand et al., 2024), 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 (Bertrand et al., 2024). The paper verifies five protocols—DAG-Rider, Cordial Miners, Hashgraph, Eventually synchronous BullShark, and an Aleph variant—using reusable TLA+ specifications and TLAPS proofs (Bertrand et al., 2024). 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" (Liu et al., 2022) 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 (Liu et al., 2022). 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 (Noreen et al., 6 Aug 2025, Liu et al., 2022).
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 (Birmpas et al., 2019, Bertrand et al., 2024). 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 (Noreen et al., 6 Aug 2025).
