Skip to main content

VEXCEL: ADAPTIVE ATTESTATION DIRECTED ACYCLIC GRAPH CONSENSUS PROTOCOL FOR DISTRIBUTED LEDGER SYSTEMS

TECHNICAL FIELD​

The present invention relates to distributed consensus protocols for blockchain and distributed ledger systems. More specifically, it relates to a method and system for achieving Byzantine fault-tolerant consensus in a leader-based blockchain that adaptively transitions between linear chain operation and directed acyclic graph (DAG) formation based on network conditions, using zero-transaction attestation blocks as unified liveness proofs, failover readiness signals, and state agreement certificates.

BACKGROUND OF THE INVENTION​

The Problem of Consensus in Distributed Ledger Systems​

Distributed ledger systems (blockchains) require a consensus mechanism to ensure all participating nodes agree on the order and validity of transactions. In leader-based Byzantine Fault Tolerant (BFT) consensus protocols, a designated leader validator proposes blocks containing transactions, and other validators verify and accept these blocks.

A fundamental challenge arises when the designated leader fails to produce a block within the expected time window. This may occur due to network latency, geographic distance between validators, hardware failures, or Byzantine (malicious) behaviour. Existing systems address this challenge through several mechanisms, each with significant drawbacks.

Prior Art and Its Limitations​

1. Multi-Round Voting Protocols (Tendermint/CometBFT, PBFT)

Protocols such as Tendermint and Practical Byzantine Fault Tolerance (PBFT) implement multi-round voting where validators exchange explicit vote messages (pre-vote, pre-commit) to reach agreement. When a leader fails, these protocols enter a timeout phase and elect a new leader through additional voting rounds.

Disadvantages: Each voting round requires O(n^2) message complexity where n is the number of validators. Leader failure triggers multiple additional communication rounds, increasing latency. Vote messages are a separate message type from blocks, requiring distinct handling logic. The voting mechanism, failover mechanism, liveness detection, and heartbeat are four separate systems that must be maintained independently.

2. Full DAG Consensus (Narwhal/Bullshark, DAG-Rider)

Systems such as Narwhal/Bullshark (Mysten Labs, 2022) and DAG-Rider (Keidar et al., 2021) implement consensus where all validators continuously produce blocks (vertices) in parallel, forming a full DAG. A separate agreement protocol runs atop the DAG to determine a total ordering of transactions.

Disadvantages: All validators produce blocks at all times, consuming bandwidth and storage even when the network is healthy and a single leader could efficiently produce blocks. The DAG ordering protocol adds complexity. Every vertex must be stored and processed, creating substantial overhead during normal operation when linear block production would suffice.

3. Committee-Based Attestation (Ethereum Gasper)

Ethereum's Gasper protocol uses committee-based attestation where subsets of validators produce attestation vote messages in designated slots. These attestations are included as vote data within canonical blocks.

Disadvantages: Attestations consume canonical block space. Committee assignment adds protocol complexity. Attestations are vote messages, not block structures, limiting their utility for failover.

4. On-Chain Voting (Solana Tower BFT)

Solana's Tower BFT records votes as transactions on the canonical chain. Each validator's vote consumes block space and compute resources.

Disadvantages: Votes compete with user transactions for block space. At scale, vote transactions represent a significant fraction of all transactions processed, reducing effective throughput.

5. Traditional Failover with Rollback

Many leader-based systems implement failover by having backup validators produce temporary blocks when the leader is absent. When the original leader's block eventually arrives, the temporary blocks must be rolled back and replaced. This approach introduces a class of bugs related to state reversal, double-execution of transactions, and race conditions between the rollback mechanism and incoming gossip messages.

Summary of Deficiencies​

No existing consensus protocol provides a mechanism that: (a) operates with zero overhead during normal linear block production; (b) automatically produces liveness proofs when the leader is delayed; (c) uses these liveness proofs as failover-ready blocks that can be deterministically promoted to canonical status; (d) forms a DAG structure only when network conditions demand it; (e) eliminates block rollback entirely; and (f) unifies failover, voting, liveness detection, and heartbeat into a single mechanism.

SUMMARY OF THE INVENTION​

According to a first aspect of the present invention, there is provided a method of achieving consensus in a distributed ledger system comprising a plurality of validator nodes, the method comprising:

operating a leader-based consensus protocol wherein a designated leader validator produces canonical blocks at sequential block heights;

when the designated leader fails to produce a canonical block within a predetermined timeout period, having one or more non-leader validators produce attestation blocks, wherein each attestation block is a signed block structure containing zero transactions and a sentinel gas limit value of zero, stored in a separate storage layer from the canonical chain;

having a subsequent leader validator reference hashes of received attestation blocks in a multi-parent field of the next canonical block header, thereby forming a directed acyclic graph when attestation blocks are produced, while maintaining a linear canonical chain during normal operation; and

when the designated leader fails entirely, deterministically promoting the attestation block from the nearest backup validator to canonical status by transforming the gas limit to the canonical value, replacing the proposer identity, and re-signing the block.

According to a second aspect, there is provided a distributed ledger system configured to perform the method of the first aspect.

According to a third aspect, there is provided a non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to perform the method of the first aspect.

The invention provides the advantage that four traditionally separate mechanisms -- failover block production, Byzantine voting rounds, heartbeat liveness detection, and state agreement proofs -- are unified into a single attestation block concept. The attestation block simultaneously proves that the producing validator is online (liveness), agrees with the canonical state (state agreement), is ready to assume leadership (failover readiness), and has an operational clock within acceptable drift (heartbeat). This unification reduces protocol complexity, eliminates the class of bugs associated with block rollback, and provides zero overhead during normal linear chain operation.

BRIEF DESCRIPTION OF THE DRAWINGS​

Figure 1 shows the overall system architecture of the consensus protocol in linear mode (normal operation) and DAG mode (leader delay), according to an embodiment of the invention.

Figure 2 shows the lifecycle of an attestation block from creation through storage, gossip propagation, DAG reference, and optional promotion to canonical status.

Figure 3 shows the staggered timeout mechanism for multiple backup validators, illustrating how circular distance from the leader determines attestation production order and promotion priority.

Figure 4 shows the block header structure with the multi-parent field enabling DAG formation, including the distinction between the canonical parent hash and attestation hash references.

Figure 5 shows the attestation-to-canonical promotion transformation, including the fields modified during promotion (gas limit, proposer, signature).

Figure 6 shows the gas limit sentinel classification mechanism, illustrating how receiving nodes distinguish attestation blocks from canonical blocks.

Figure 7 shows the weighted leader selection algorithm using deterministic seeding and pure integer arithmetic.

Figure 8 shows the adaptive mode transition between linear chain operation and DAG formation, triggered by attestation block production.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS​

The following description sets forth specific details to provide a thorough understanding of the invention. It will be apparent to a person skilled in the art of distributed systems and blockchain consensus protocols that the invention may be practised without some or all of these specific details. In some instances, well-known structures and techniques have not been described in detail to avoid unnecessarily obscuring the description.

1. System Overview​

Referring to Figure 1, a distributed ledger system 100 comprises a plurality of validator nodes 110, 120, 130, 140 connected via a peer-to-peer network 150. Each validator node maintains a copy of the canonical blockchain 160 and a separate attestation storage 170.

The system operates in two modes:

Linear mode (Figure 1a): A designated leader validator 110 produces canonical blocks at sequential block heights. Non-leader validators 120, 130, 140 receive and verify these blocks. The canonical chain 160 is purely linear with each block referencing a single parent hash.

DAG mode (Figure 1b): When the leader 110 is delayed or absent, non-leader validators 120, 130 produce attestation blocks 180 that are stored in attestation storage 170. The next canonical block 190 references both the canonical parent hash and attestation block hashes in its multi-parent header field, forming a DAG structure.

The transition between modes is automatic and requires no explicit signal, configuration change, or governance action. The system is in DAG mode whenever attestation blocks exist at the current height, and in linear mode otherwise.

2. Block Header Structure​

Referring to Figure 4, each block in the system has a header 200 comprising:

  • A block height field 201 (unsigned 64-bit integer) indicating the sequential position in the canonical chain;
  • A timestamp field 202;
  • A proposer field 203 identifying the validator that produced the block;
  • A multi-parent field 204 comprising a variable-length vector of cryptographic hashes, wherein the first element is the hash of the canonical parent block and subsequent elements are hashes of attestation blocks produced at the current or previous height;
  • A state root field 205 representing the current state of all accounts;
  • A transactions root field 206 representing a Merkle root of included transactions;
  • A gas used field 207;
  • A gas limit field 208 serving as a sentinel value for block classification (described in Section 4);
  • A base fee field 209;
  • A cryptographic signature field 210 (Ed25519, 64 bytes) over the hash of the header fields.

The multi-parent field 204 is the structural element enabling DAG formation. When no attestation blocks exist, the vector contains a single element (the canonical parent hash), producing a linear chain. When attestation blocks exist, the vector contains additional elements (attestation hashes sorted by byte ordering), producing DAG references.

The block header hash is computed over ALL elements of the multi-parent field 204, making attestation references part of the block's cryptographic identity. A maximum of 8 attestation hashes plus 1 canonical parent hash (9 total parent references) is enforced.

3. Attestation Block Construction​

Referring to Figure 2, an attestation block 300 is a full block structure with the following properties:

  • The bundle field 301 contains an empty vector (zero transactions);
  • The gas limit field 302 is set to zero (the sentinel value);
  • The gas used field 303 is zero;
  • The state root field 304 is set to a null hash (no state execution is performed);
  • The proposer field 305 identifies the non-leader validator that produced the attestation;
  • The multi-parent field 306 contains a single element: the hash of the last canonical block;
  • The signature field 307 contains an Ed25519 signature computed by the producing validator over the attestation block header hash.

Optionally, in a direct-forwarding transaction pipeline mode, the transactions root field 308 contains a Merkle root of transaction hashes that the attesting validator had received via the direct-forwarding pipeline since the last block. This cryptographically commits to which pending transactions were available to the validator at the time of attestation, enabling censorship resistance proofs and accountability mechanisms, while still carrying zero transactions for execution.

4. Gas Limit Sentinel Classification​

Referring to Figure 6, receiving nodes classify incoming blocks using the gas limit field as a sentinel value according to the following three-condition test:

A block is classified as an attestation block if and only if all three conditions hold:

  1. The block's bundle field contains zero transactions;
  2. The block's proposer is NOT the designated leader for the block's height;
  3. The block's gas limit field equals zero.

A canonical block has a gas limit equal to the system's canonical gas limit value (e.g., 5,242,880 gas units). This classification requires no additional metadata fields, flags, or message types. The gas limit field, which in an attestation block serves no computational purpose (there are no transactions to meter), is repurposed as a classification sentinel.

This is advantageous because it maintains backwards compatibility with existing block serialisation formats and requires no protocol-level message type negotiation.

5. Attestation Validation​

When a validator receives an attestation block via the peer-to-peer network, it performs five validation checks:

  1. Empty transactions: The bundle field must contain zero transactions. Any non-empty attestation is rejected as a transaction smuggling attempt.

  2. Non-leader origin: The attestation's proposer must NOT be the elected leader for the attestation's height. Leaders are required to produce canonical blocks, not attestations.

  3. Active validator membership: The attestation's proposer must be a member of the active validator set. Attestations from non-validators are rejected.

  4. Cryptographic signature validity: The Ed25519 signature is verified against the proposer's registered public key.

  5. Uniqueness per height: At most one attestation per validator per height is permitted. Duplicate attestations from the same proposer at the same height are rejected and treated as evidence of Byzantine behaviour (analogous to double-signing).

6. Weighted Leader Selection​

Referring to Figure 7, the leader for each block height is selected deterministically using the following algorithm:

Step 1: Compute a deterministic seed by applying a cryptographic hash function (Blake3) to the concatenation of the block height (as little-endian bytes) and a domain separator string ("leader_selection_v1").

Step 2: Interpret the first 16 bytes of the hash output as an unsigned 128-bit integer.

Step 3: For each active (non-jailed) validator, compute a weight value equal to staked_amount * performance_score / 1000, where performance_score is an integer in the range 0 to 1000 (per-mille). This calculation uses exclusively unsigned integer arithmetic with no floating-point operations, ensuring bit-exact determinism across all hardware architectures and compiler implementations.

Step 4: Sort the active validators by their public key bytes to establish a deterministic ordering.

Step 5: Compute target = seed modulo total_weight (sum of all individual weights).

Step 6: Walk the cumulative weight distribution: for each validator in sorted order, add its weight to a running sum. The first validator whose cumulative sum exceeds the target is the elected leader.

This algorithm is pure, deterministic, and reproducible on any conforming implementation.

7. Staggered Timeout and Attestation Production​

Referring to Figure 3, when a non-leader validator does not receive a canonical block from the leader within a base timeout period (FAILOVER_BASE_SECS, default 10 seconds), it produces an attestation block. However, validators do not all produce attestations simultaneously.

Each non-leader validator computes its circular distance (position) from the leader in the sorted validator key list:

If validator_index > leader_index:
    position = validator_index - leader_index - 1
Else:
    position = validator_count - 1 - leader_index + validator_index

The attestation timeout for each validator is:

attestation_timeout = FAILOVER_BASE_SECS + (position * FAILOVER_STAGGER_SECS)

Where FAILOVER_STAGGER_SECS defaults to 8 seconds. For a system with 5 validators:

  • Position 0 (nearest backup): 10 seconds
  • Position 1: 18 seconds
  • Position 2: 26 seconds
  • Position 3: 34 seconds

This staggered design ensures that only one validator produces an attestation at a time. Higher-position validators observe lower-position attestations arriving via gossip before their own timeout expires, allowing them to defer attestation production if sufficient attestations already exist.

Before producing an attestation, at a configurable probe interval (FAILOVER_PROBE_SECS, default 5 seconds), the validator queries known bootstrap nodes to verify it is not simply out of synchronisation. If the probe reveals that a canonical block exists, attestation production is cancelled.

8. Attestation Storage​

Attestation blocks are stored in a dedicated storage partition (column family) separate from the canonical chain. The storage key format is:

{block_height: 8 bytes, big-endian} {block_hash: 32 bytes}

This key format enables:

  • O(1) prefix-scan retrieval of all attestations at a given height (by scanning the 8-byte height prefix);
  • Efficient batch pruning of attestations older than a configurable retention threshold (default: 1000 heights) by iterating keys sequentially.

Attestation blocks are written directly to storage (not via the canonical block commit pipeline) because they are produced outside the canonical block execution scope and do not affect the state root.

Pruning of attestation storage occurs periodically (every 100 canonical blocks), removing attestations older than the retention threshold.

9. DAG Reference Collection​

When a leader validator produces a canonical block, it collects attestation hashes from the attestation storage for the current height using the following algorithm:

Step 1: Retrieve all attestation blocks stored at the current height via prefix scan.

Step 2: Compute the hash of each attestation block.

Step 3: Sort the hashes by raw byte ordering (lexicographic comparison of the 32-byte hash values).

Step 4: Truncate the sorted list to a maximum of MAX_ATTESTATION_PARENTS (default: 8) entries.

Step 5: Construct the multi-parent field as: [canonical_parent_hash, attestation_hash_1, attestation_hash_2, ...].

The deterministic sorting and truncation ensure that all honest nodes independently construct identical multi-parent vectors for the same set of attestation blocks.

10. Attestation-to-Canonical Promotion​

Referring to Figure 5, when the designated leader fails entirely and no canonical block is received, a backup validator promotes an attestation block to canonical status. This is a deterministic process that proceeds as follows:

Promotion eligibility: Each validator tracks the timestamp when the first attestation at the current height was observed (either self-produced or received via gossip). This timestamp is stored using an atomic compare-exchange operation, ensuring it is set exactly once (the first attestation wins). The promotion timeout for each validator is:

promotion_timeout = ATTESTATION_PROMOTION_GRACE_SECS + (position * FAILOVER_STAGGER_SECS)

Where ATTESTATION_PROMOTION_GRACE_SECS defaults to 5 seconds. Position 0 promotes after 5 seconds, position 1 after 13 seconds, and so on.

Promotion selection: All attestation blocks at the target height are retrieved. For each attestation, the proposer's address is resolved to their position in the sorted validator key list. The attestation with the lowest position (nearest backup to the leader) is selected for promotion.

Promotion transformation: The selected attestation block is transformed into a canonical block by:

  1. Setting the gas limit field from 0 to the canonical gas limit value (e.g., 5,242,880);
  2. Replacing the proposer field with the promoting validator's address;
  3. Computing a new Ed25519 signature over the modified header using the promoting validator's private key;
  4. Setting a failover flag to bypass the leader check for this specific block.

Promotion finalisation: The transformed block is submitted through the standard block validation and finalisation pipeline, executed against the current state, and broadcast to all peers via gossip. The first attestation timestamp is reset to zero, preparing for the next height.

This promotion mechanism is entirely deterministic: given the same set of attestation blocks and the same validator set, every honest node selects and promotes the same attestation. No additional voting round or agreement protocol is required.

11. Rollback Elimination​

A key advantage of the present invention is the complete elimination of block rollback during failover. In traditional leader-based BFT systems, when a backup validator produces a temporary block and the original leader's block subsequently arrives, the temporary block must be rolled back. This rollback process is error-prone, as it requires reversing state changes, restoring transaction receipts, and handling edge cases where transactions in the rolled-back block conflict with transactions in the arriving leader's block.

In the present invention, attestation blocks are never finalised against the canonical state. They are stored in a separate partition and contain zero transactions. When the leader's canonical block arrives, there is nothing to roll back, undo, or re-execute. The attestation blocks are simply referenced in the leader's block header as liveness evidence. If the leader never arrives and an attestation is promoted, the promotion creates a new canonical block through transformation rather than retroactively finalising the attestation -- the original attestation remains in attestation storage unchanged.

12. Unified Mechanism​

The attestation block unifies four traditionally separate mechanisms:

  1. Failover readiness: An attestation block is a pre-formed block structure that can be promoted to canonical status. It proves the validator is ready and able to assume leadership.

  2. Byzantine voting: By producing a signed attestation referencing the canonical parent hash, the validator implicitly votes for the current canonical chain state. No separate vote message type is needed.

  3. Liveness detection: The existence of an attestation block at a given height from a given validator proves that validator was online and operational at that time. No separate heartbeat mechanism is needed.

  4. State agreement: The attestation block's parent hash reference confirms the validator's view of the canonical chain tip. Validators that disagree about the chain state produce attestations with different parent hashes, which are detectable.

13. Security Properties​

The protocol enforces the following security invariants:

  • Attestation spam rejection: At most one attestation per validator per height is accepted. Duplicates are rejected and flagged as potential Byzantine behaviour.
  • Transaction smuggling prevention: Any attestation block containing non-empty transactions is hard-rejected at validation.
  • Leader attestation prevention: The elected leader cannot produce attestations; it must produce canonical blocks. This prevents a Byzantine leader from producing attestations to appear lively while failing to include transactions.
  • Double-sign detection: The existing double-sign detection system is extended to cover attestation blocks. A validator signing two different attestations at the same height is detectable.
  • Signature enforcement: All attestation blocks must carry valid cryptographic signatures from their proposer. Unsigned or incorrectly signed attestations are rejected.

14. System Parameters​

The following parameters govern the protocol's behaviour and may be adjusted for different network conditions:

ParameterDefault ValueDescription
FAILOVER_BASE_SECS10Base timeout before nearest backup produces attestation
FAILOVER_STAGGER_SECS8Additional timeout per position in backup ordering
FAILOVER_PROBE_SECS5Pre-attestation sync probe timeout
ATTESTATION_PROMOTION_GRACE_SECS5Grace period after first attestation before promotion eligible
MAX_ATTESTATION_PARENTS8Maximum attestation hashes in a canonical block's parent field
ATTESTATION_RETENTION_HEIGHTS1000Number of heights to retain attestation blocks before pruning

15. Practical Embodiment and Performance Results​

In a practical embodiment, the protocol was implemented in the Rust programming language and deployed on a live testnet comprising 5 validator nodes distributed across 4 continents (Europe, North America, Asia-Pacific). The validators operated over the public internet with latencies ranging from 1ms (co-located) to 280ms (Europe to Asia).

Before the invention, block production was dominated by the validator geographically closest to the seed node, which produced 68% of all blocks. High-latency validators (Singapore, Mumbai) produced fewer than 5% of blocks each.

After deploying the invention, all 5 validators produced blocks within a range of 16-24% each (the ideal distribution being 20% for 5 equal validators). High-latency validators achieved production parity with low-latency validators. The system processed over 150,000 blocks with zero rollbacks, zero double-sign incidents, and zero attestation-related failures.

The protocol maintained an average block time of 1.6-4 seconds during normal operation (leader present) and 15-18 seconds during leader failover (attestation → promotion cycle), compared to 30-60 seconds for multi-round voting protocols under similar conditions.

CLAIMS​

  1. A method of achieving consensus in a distributed ledger system comprising a plurality of validator nodes connected via a peer-to-peer network, each validator node maintaining a canonical blockchain, the method comprising:

    • operating a leader-based consensus protocol wherein, for each sequential block height, a designated leader validator is elected to produce a canonical block containing transactions;
    • characterised in that, when the designated leader fails to produce a canonical block within a predetermined timeout period:
      • one or more non-leader validators each produce an attestation block, wherein each attestation block is a cryptographically signed block structure containing zero transactions and having a gas limit field set to a sentinel value of zero;
      • each attestation block is stored in a storage partition separate from the canonical blockchain;
      • a subsequent canonical block produced by a leader validator includes, in a multi-parent field of its block header, hashes of attestation blocks received at the current or previous height, in addition to the hash of the canonical parent block, thereby forming a directed acyclic graph structure; and
      • the canonical blockchain remains a linear sequence of blocks at sequential heights.

  2. A method according to claim 1, characterised in that receiving validator nodes classify incoming blocks as attestation blocks or canonical blocks based on a three-condition test: (a) the block contains zero transactions; (b) the block's proposer is not the designated leader for the block's height; and (c) the block's gas limit field equals zero.

  3. A method according to claim 1 or claim 2, characterised in that, when the designated leader fails to produce any canonical block:

    • each non-leader validator computes a circular distance from the designated leader in a deterministically sorted list of validator public keys, said circular distance defining the validator's position;
    • the non-leader validator at position zero deterministically promotes an attestation block to canonical status by: (i) setting the gas limit field to the canonical gas limit value; (ii) replacing the proposer identity with the promoting validator's identity; and (iii) computing a new cryptographic signature over the modified block header using the promoting validator's private key; and
    • if the position-zero validator also fails, subsequent validators at higher positions promote after additional staggered timeout periods.

  4. A method according to claim 3, characterised in that the promotion timeout for each validator is computed as:

    promotion_timeout = base_grace_period + (position * stagger_interval)

    where position is the circular distance from the designated leader, base_grace_period is the time elapsed since the first attestation block was observed, and stagger_interval is a configurable parameter, thereby ensuring that at most one validator attempts promotion at any given time.

  5. A method according to any preceding claim, characterised in that the multi-parent field of each canonical block header comprises a variable-length vector of cryptographic hashes wherein:

    • the first element is the hash of the immediately preceding canonical block;
    • subsequent elements are hashes of attestation blocks, sorted by byte ordering of their hash values; and
    • the total number of attestation hash references is limited to a configurable maximum;
    • and wherein the block header hash is computed over all elements of the multi-parent field, making attestation references part of the canonical block's cryptographic identity.

  6. A method according to any preceding claim, characterised in that producing an attestation block by a non-leader validator simultaneously serves as:

    • a liveness proof that the validator is online and operational;
    • an implicit vote for the current canonical chain state, by reference to the canonical parent hash;
    • a failover readiness signal indicating the validator can assume leadership; and
    • a heartbeat confirming the validator's clock is within acceptable drift; thereby unifying failover, voting, liveness detection, and heartbeat into a single mechanism requiring no separate message types.

  7. A method according to any preceding claim, characterised in that attestation blocks are never finalised against the canonical state and never cause state transitions, such that when a delayed canonical block from the designated leader arrives after attestation blocks have been produced, there are no blocks to roll back, no state changes to reverse, and no transactions to re-execute.

  8. A method according to any preceding claim, characterised in that the designated leader for each block height is selected using a weighted deterministic algorithm comprising:

    • computing a deterministic seed by applying a cryptographic hash function to the concatenation of the block height and a domain separator;
    • for each active validator, computing a weight value equal to the product of the validator's staked amount and a performance score divided by a fixed denominator, using exclusively unsigned integer arithmetic with no floating-point operations;
    • sorting active validators by their public key bytes; and
    • selecting the validator whose position in the cumulative weight distribution corresponds to the seed value modulo the total weight.

  9. A method according to any preceding claim, characterised in that attestation blocks are stored using a key format comprising the block height encoded as a fixed-width big-endian integer concatenated with the attestation block hash, enabling prefix-scan retrieval of all attestations at a given height and sequential iteration for batch pruning of attestations older than a configurable retention threshold.

  10. A method according to any preceding claim, characterised in that, when operating in conjunction with a direct transaction forwarding pipeline, each attestation block includes a Merkle root of transaction hashes that the attesting validator had received via the forwarding pipeline, cryptographically committing to which pending transactions were available to the validator at the time of attestation, while still containing zero transactions for execution.

  11. A method according to any preceding claim, characterised in that the following security invariants are enforced:

    • at most one attestation block per validator per block height is accepted;
    • any attestation block containing non-empty transactions is rejected;
    • the designated leader for a height is prohibited from producing attestation blocks at that height; and
    • duplicate attestations from the same validator at the same height are flagged as Byzantine behaviour.

  12. A method according to any preceding claim, characterised in that a first attestation observation timestamp is tracked using an atomic compare-exchange operation, ensuring the timestamp is set exactly once per height regardless of whether the attestation was self-produced or received via gossip, and is reset to zero upon finalisation of a canonical block at that height.

  13. A distributed ledger system comprising:

    • a plurality of validator nodes, each comprising a processor and memory storing instructions for executing a consensus protocol;
    • a peer-to-peer network connecting the validator nodes;
    • a canonical blockchain storage on each validator node; and
    • an attestation storage partition, separate from the canonical blockchain storage, on each validator node;
    • characterised in that the system is configured to perform the method of any of claims 1 to 12.

  14. A non-transitory computer-readable storage medium storing instructions that, when executed by one or more processors of a validator node in a distributed ledger system, cause the one or more processors to perform the method of any of claims 1 to 12.

ABSTRACT​

A method and system for achieving consensus in a distributed ledger system wherein a leader-based blockchain protocol adaptively transitions between linear chain operation and directed acyclic graph (DAG) formation. During normal operation, a designated leader produces canonical blocks in a linear chain. When the leader is delayed or absent, non-leader validators produce zero-transaction attestation blocks stored separately from the canonical chain, with a gas limit sentinel value of zero for classification. The next leader references attestation hashes in a multi-parent block header field, forming a DAG. If the leader fails entirely, the nearest backup validator deterministically promotes an attestation to canonical status through field transformation and re-signing. The attestation block unifies failover, voting, liveness detection, and heartbeat into a single mechanism, eliminates block rollback, and provides zero overhead during normal operation.

[Best illustrated by Figure 2]

NOTES FOR FILING​

UK Intellectual Property Office (UKIPO) Requirements​

Filing strategy: File description-only (GBP 60) to secure priority date immediately. Claims, abstract, and formal drawings can be added within 12 months. Fees increase to GBP 75 after 1 April 2026.

Full filing cost: GBP 310 (filing GBP 60 + search GBP 150 + examination GBP 100). Increases to GBP 405 after 1 April 2026.

Formatting for PDF submission:

  • A4 paper, portrait orientation
  • Margins: minimum 20mm all sides
  • Line spacing: minimum 1.5
  • Capital letter height: minimum 2mm in text, 3mm in drawings
  • Each section (description, claims, abstract, drawings) starts on a new page
  • Pages numbered consecutively, centred top or bottom
  • Drawings: black lines on white, separate sheets, reference numerals matching description
  • Abstract: maximum 150 words (current draft: 142 words)

Form 1 (Request for Grant): Must be filed alongside the specification. Available online at gov.uk/patent-your-invention.

Drawings: The 8 figures described above need to be created as formal patent drawings (black line art on white A4). These can be filed informally at initial filing and replaced with formal versions within 15 months of the priority date.

Priority claim: If filing within 12 months of any earlier application (US or otherwise) covering the same subject matter, a priority claim can be made to the earlier filing date.

Inventor and Applicant​

  • Inventor: Christopher James Fernandes
  • Applicant: [Vexidus Corporation / entity name to be confirmed]

Relationship to Existing Patents​

  • IntentVM: U.S. Patent Application 63/914,009 (filed 8 February 2026)
  • VexBridge: U.S. Patent Application 63/987,929 (filed 21 February 2026)
  • Vexcel: This application (UK filing, no prior application)