Papers
Topics
Authors
Recent
2000 character limit reached

Ledger Groups in Distributed Ledgers

Updated 15 December 2025
  • Ledger groups are formal constructs of nodes that collectively manage and validate state in distributed ledgers, enabling both intra- and inter-ledger operations.
  • They implement dynamic membership, authorization, and governance through methods such as certificate-based credentials and atomic, globally ordered governance transactions.
  • Advanced consensus protocols like PBFT and synchronous HotStuff ensure high-throughput, Byzantine fault-tolerant operation, as evidenced by experimental improvements in latency and scalability.

A ledger group is a general, formal construct denoting a collection of entities (often nodes or servers) that collectively maintain, validate, or coordinate events and state in a distributed ledger environment. The ledger group paradigm encompasses a spectrum of scenarios: from public blockchains and sharded ledgers to topological consortia of permissioned blockchains. The architectural instantiation, security guarantees, and operational semantics of ledger groups are foundational to the scalability, consistency, and security of distributed ledgers, supporting both intra-ledger and inter-ledger operations (Zhao, 2021, Fink et al., 23 May 2024, Shamis et al., 2021, Bui et al., 2016, King, 2019).

1. Formal Definitions and Topological Structure

The definition of a ledger group varies with context but shares two axiomatic features: (1) a well-defined set of participating nodes (often represented as a vertex set VV in a graph or simplicial complex), and (2) stable protocols or rules for collective state-management, membership, and consensus.

  • Consortium/Topological Ledger Group: In the XLPN-22 protocol for permissioned cross-ledger operation, a ledger group is modeled as a global topological consortium. Let there be kk permissioned ledgers, LiL_i (i=1,,ki = 1, \dots, k), each with n=3f+1n = 3f + 1 nodes ViV_i (tolerating up to ff Byzantine failures per ledger). The full ledger group is V=i=1kViV = \bigcup_{i=1}^k V_i, with the interconnection graph G=(V,E)G = (V, E) comprising all intra-ledger edges (full clique on ViV_i) and all inter-ledger edges ({u,v}uVi,vVj,ij\{u,v\} \mid u \in V_i, v \in V_j, i \neq j). This global mesh is homeomorphic to a (kn2)(kn-2)-sphere (Zhao, 2021).
  • Shard or Dynamic Ledger Group: In dynamically sharded distributed ledgers, each transaction is processed by an r-group (shard) Gr(a)G_r(a): the set of the rr nodes whose identifiers are closest to an address aa in Kademlia distance. For a transaction tt from sender ss to receiver rr, the validator group is V(t)=Gr(s)Gr(r)V(t) = G_r(s) \cup G_r(r), with rV(t)2rr \leq |V(t)| \leq 2r (Fink et al., 23 May 2024).
  • Public Ledger with Role Groups: In certificate-based group management, the ledger encodes group membership and authorization, where entities are grouped by public key, group ID, and role, and all events are indexed by the cryptographic hash i=H(GRPKU)i = H(G\Vert R \Vert PK_U) (Bui et al., 2016).

2. Membership, Authorization, and Governance

Ledger groups frequently serve as the context for encoding dynamic membership, authorization, and role delegation:

  • Certificate-based Group Membership: Membership and role assignments are encoded as signed certificates {PKissuer,PKsubject,auth,validity,Sigissuer}\{PK_{issuer}, PK_{subject}, auth, validity, Sig_{issuer}\}, with "add" and "revoke" actions globally ordered by the ledger. Membership state is determined by the latest event on the corresponding ledger index; a "revoke" makes an entity ineligible for the role (Bui et al., 2016).
  • Consortium Management in Permissioned Ledgers: Systems like IA-CCF encode all membership and replica key changes as atomic "governance transactions" in a governance sub-ledger. The active configuration (authorized member and replica keys) at any ledger index ii is determined by replaying this sub-ledger (Shamis et al., 2021).
  • Referendum Protocols for Reconfiguration: Changes in membership trigger on-chain referenda, where members vote, the result is committed atomically to the ledger, and state transitions to new configurations only after global acknowledgment and checkpointing (Shamis et al., 2021).

3. Consensus and Fault Models within Ledger Groups

The ledger group’s size, topology, and consensus protocol determine its robustness and throughput.

  • Byzantine Fault Tolerance (BFT) Bounds: For a group of N=3f+1N=3f+1 nodes (PBFT model), the system tolerates up to ff Byzantine nodes; safety and liveness require $2f+1$ correct signatures for progress (Zhao, 2021, Shamis et al., 2021). In sharded systems, with group size V(t)|V(t)| and bb Byzantine nodes in V(t)V(t), synchronous protocols admit f<1/2f < 1/2 (i.e., V(t)2b+1|V(t)| \geq 2b+1), asynchronous protocols require f<1/3f < 1/3 (V(t)3b+1|V(t)| \geq 3b+1) (Fink et al., 23 May 2024).
  • Consensus Protocols: XLPN-22 leverages intra-ledger PBFT (2 rounds per ledger) and a coordinated, globally-synchronized multi-phase protocol (5 phases: VOTE-REQ, VOTE-PREP, READY, COMMIT-REQ, COMMIT) across the full ledger group, achieving constant round complexity versus the number of ledgers (O(1)O(1) interledger communication) (Zhao, 2021). In dynamically sharded ledgers, consensus for a transaction is reached within O(r)O(r) nodes, with latency O(logN)+O(Δ)O(\log N) + O(\Delta) and high throughput due to parallel disjoint validator groups (Fink et al., 23 May 2024).
  • Accountability and Proofs of Misbehavior: In IA-CCF, all protocol messages are logged and signed; any conflicting messages from a single replica form a universal proof-of-misbehavior (uPoM), enabling precise attribution of faults even beyond the f<1/3f < 1/3 regime (Shamis et al., 2021).

4. Storage, Scalability, and Efficient State Management

Ledger group architectures directly affect storage requirements and scalability:

Ledger Group Paradigm Storage Complexity Per-Node Storage
Dynamically Sharded Ledger O(t)O(t) total, O(t/n)O(t/n) per node Each node holds $1/n$ fraction
Topological Consortium (XLPN) O(kn2)O(kn^2) for interledger state Complete record per ledger
Public Membership Ledger Merkle prefix-tree; succinct proofs Subset indexed by group/role
  • Sharded Ledgers: Storage is horizontally scaled; by replicating each chain across rr nodes, total storage is O(rt)O(rt) (with tt transactions), and per-node storage is O(t/n)O(t/n) for nn validators (Fink et al., 23 May 2024).
  • Merkle Tree Structures: Both public ledgers for revocation (Bui et al., 2016) and accountable permissioned consortia (Shamis et al., 2021) employ Merkle trees for succinct (logarithmic-size) proofs of both presence and absence, facilitating efficient, verifiable queries by clients and auditors.
  • Governance/State Checkpointing: In IA-CCF, configurations, checkpoints, and batch roots are strongly bound to Merkle proofs, and configuration changes are fully checkpointed before becoming effective (Shamis et al., 2021).

5. Security, Cross-Group Interaction, and Protocol Composition

Security properties of ledger groups are a function of both intra-group and inter-group protocols:

  • Cross-Ledger Protocols: XLPN-22 achieves atomic cross-ledger commitment via a constant-round, globally coordinated protocol. Each phase requires $2f+1$ confirmations per ledger for state advancement, ensuring safety by PBFT’s signature invariants. Consistency between ledgers is guaranteed unless the coordinator equivocates, which is detected and leads to failover (Zhao, 2021).
  • Dynamic Shard Composition: By routing each transaction to both sender and receiver r-groups and using a single synchronous HotStuff instance, ScaleGraph avoids multi-phase cross-shard lookups or hindsight checks. Double-spend detection and state validity are guaranteed within a single consensus round over the combined validator group (Fink et al., 23 May 2024).
  • Negative Information and Revocation: The challenge of efficiently and reliably revoking membership or authorization in distributed settings (where withholding messages by adversaries is possible) is mitigated by the global consistency, linear ordering, and immutability of public ledgers, with Merkle-based proofs certifying current and historical group state (Bui et al., 2016).

6. Performance, Experimental Findings, and Application Domains

Experimental evaluations of ledger group architectures provide concrete guidance for parameter tuning, throughput projections, and real-world applicability:

  • Cross-Ledger and Consortium Protocols: In XLPN-22, reducing global communication to 5 synchronous rounds (vs O(k)O(k)) enables superior scalability for cross-ledger transaction batches; the protocol outperforms VLDB-20 by 18–50% and PODC-18 by 64–84% in latency, with linear throughput scaling up to 128 nodes and 16,000 transactions (Zhao, 2021).
  • Dynamically Sharded Ledgers for Microtransactions: ScaleGraph architecture achieves end-to-end transaction latency O(logN+Δ)O(\log N + \Delta) and per-node storage O(t/n)O(t/n), enabling large-scale deployment with billions of microtransactions across autonomous agents. Experimental results specify that for up to F=1/5F=1/5 Byzantine nodes in NN up to 16,000, synchronous protocol shard size r6181r\approx 61–81 suffices for zero compromise, while asynchronous protocols require r>5×r>5\times larger, demonstrating the efficiency advantage of synchrony assumptions (Fink et al., 23 May 2024).
  • Accountable Permissioned Ledgers: IA-CCF delivers >>47,000 tx/s with receipt generation (receipts increase overhead by about 3%), with WAN median transaction latency 183 ms. Auditing a ledger fragment is faster than live execution, supporting scalable and individually accountable ledger operation (Shamis et al., 2021).

7. Theoretical Models and Fluid Limits

Random graph models and deterministic fluid limits provide a rigorous foundation for understanding group-maintained ledgers such as the Tangle:

  • In the Tangle protocol, every user can append by referencing existing “tips” (unapproved transactions), leading to a DAG structure. The growth process is non-Markovian and is modeled by a delay differential equation in the fluid limit: dadt=12a/b\frac{da}{dt}=1-2a/b, dbdt=12a(th)/b(th)\frac{db}{dt}=1-2a(t-h)/b(t-h) for rescaled counts of free and total tips (King, 2019). These equations have a unique globally attracting fixed point, offering quantitative guidance for dimensioning system parameters and analyzing stability against adversarial attempts at divergence.
  • A plausible implication is that fluid-limit techniques can be applied to other group-maintained DAG ledgers to predict steady-state performance, tip backlog, and vulnerability to orphaned transactions.

In summary, the ledger group is a formal and operational abstraction that unifies diverse distributed ledger architectures, underpinning scalable transaction processing, robust consensus, atomic cross-ledger operations, individualized accountability, and flexible membership management, across both permissioned and permissionless settings (Zhao, 2021, Fink et al., 23 May 2024, Bui et al., 2016, Shamis et al., 2021, King, 2019).

Whiteboard

Follow Topic

Get notified by email when new papers are published related to Ledger Group.