Skip to main content

ADAPTIVE ATTESTATION DIRECTED ACYCLIC GRAPH CONSENSUS PROTOCOL FOR DISTRIBUTED LEDGER SYSTEMS

U.S. Provisional Patent Application​

This application is related to U.S. Provisional Patent Application No. 63/914,009, filed February 8, 2026, entitled "IntentVM: Intent-Based Transaction Execution System for Blockchain Networks," and U.S. Provisional Patent Application No. 63/987,929, filed February 21, 2026, entitled "VexBridge: Method for Multichain Bridging of Tokens Without Vault or Wormholes," both by the same inventor, the disclosures of which are incorporated herein by reference in their entirety.

FIELD OF THE INVENTION​

The present invention relates generally to distributed consensus protocols for blockchain and distributed ledger systems. More particularly, the invention 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) behavior. Existing systems address this challenge through several mechanisms, each with significant drawbacks.

Description of Prior Art​

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.

These protocols suffer from 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, increasing both code complexity and attack surface.

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.

In these systems, 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.

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

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.

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

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 in the Prior Art​

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.

There exists a need in the art for an improved consensus protocol that addresses these deficiencies.

SUMMARY OF THE INVENTION​

In one embodiment, the present invention provides a method of achieving consensus in a distributed ledger system comprising a plurality of validator nodes. The method includes 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, one or more non-leader validators produce attestation blocks, 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, stored in a storage partition separate from the canonical blockchain. A subsequent leader validator references 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. When the designated leader fails entirely, the attestation block from the nearest backup validator is deterministically promoted to canonical status by transforming the gas limit to the canonical value, replacing the proposer identity, and re-signing the block.

In another embodiment, the invention provides a distributed ledger system comprising a plurality of validator nodes connected via a peer-to-peer network, each validator node having a canonical blockchain storage and a separate attestation storage partition, the system configured to perform the method described herein.

In yet another embodiment, the invention provides 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 described herein.

The invention advantageously unifies four traditionally separate mechanisms -- failover block production, Byzantine voting rounds, heartbeat liveness detection, and state agreement proofs -- 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​

FIG. 1A is a block diagram illustrating the system architecture in linear mode during normal operation, according to an embodiment of the present invention.

FIG. 1B is a block diagram illustrating the system architecture in DAG mode during leader delay, according to an embodiment of the present invention.

FIG. 2 is a flowchart illustrating the lifecycle of an attestation block from creation through storage, gossip propagation, DAG reference, and optional promotion to canonical status.

FIG. 3 is a timing diagram illustrating the staggered timeout mechanism for multiple backup validators, showing how circular distance from the leader determines attestation production order and promotion priority.

FIG. 4 is a data structure diagram illustrating the block header structure with the multi-parent field enabling DAG formation, including the distinction between the canonical parent hash and attestation hash references.

FIG. 5 is a flowchart illustrating the attestation-to-canonical promotion transformation, including the fields modified during promotion.

FIG. 6 is a decision tree diagram illustrating the gas limit sentinel classification mechanism used by receiving nodes to distinguish attestation blocks from canonical blocks.

FIG. 7 is a flowchart illustrating the weighted leader selection algorithm using deterministic seeding and pure integer arithmetic.

FIG. 8 is a state diagram illustrating the adaptive mode transition between linear chain operation and DAG formation.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS​

The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

1. System Overview​

Referring to FIGS. 1A and 1B, 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 (FIG. 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 (FIG. 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 FIG. 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 below);
  • 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. In the preferred embodiment, a maximum of 8 attestation hashes plus 1 canonical parent hash (9 total parent references) is enforced.

3. Attestation Block Construction​

Referring to FIG. 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 FIG. 6, receiving nodes classify incoming blocks using the gas limit field as a sentinel value according to a 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 in the preferred embodiment). 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 approach is advantageous because it maintains backward compatibility with existing block serialization 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 behavior (analogous to double-signing).

6. Weighted Leader Selection​

Referring to FIG. 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.

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 multiplied by performance_score divided by 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 FIG. 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 in the preferred embodiment), 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 in the preferred embodiment. 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 the peer-to-peer network 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 in the preferred embodiment), the validator queries known bootstrap nodes to verify it is not simply out of synchronization. If the probe reveals that a canonical block exists, attestation production is canceled.

8. Attestation Storage​

Attestation blocks are stored in a dedicated storage partition (column family) separate from the canonical chain. The storage key format in the preferred embodiment 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 in the preferred embodiment) 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 (e.g., every 100 canonical blocks in the preferred embodiment), 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 entries (default: 8 in the preferred embodiment).

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 FIG. 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 the peer-to-peer network). 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 in the preferred embodiment. 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 zero to the canonical gas limit value (e.g., 5,242,880 in the preferred embodiment);
  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 finalization: The transformed block is submitted through the standard block validation and finalization pipeline, executed against the current state, and broadcast to all peers via the peer-to-peer network. 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 finalized 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 finalizing the attestation -- the original attestation remains in attestation storage unchanged.

12. Unified Mechanism​

The attestation block of the present invention 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 behavior.
  • 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 active 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 behavior 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

Those skilled in the art will recognize that the specific default values are presented by way of example and not limitation, and that different values may be selected based on network topology, validator count, and latency characteristics.

15. Practical Embodiment and Performance Results​

In a preferred 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, and Asia-Pacific). The validators operated over the public internet with latencies ranging from 1 millisecond (co-located) to 280 milliseconds (Europe to Asia).

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

After deploying the invention, all 5 validators produced blocks within a range of 16-24% each (the ideal distribution being 20% for 5 equal-weight 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-to-promotion cycle), compared to 30-60 seconds for multi-round voting protocols under similar conditions.

CLAIMS​

What is claimed is:

  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;
    • when the designated leader fails to produce a canonical block within a predetermined timeout period, causing one or more non-leader validators to 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;
    • storing each attestation block in a storage partition separate from the canonical blockchain;
    • including, in a multi-parent field of a subsequent canonical block header produced by a leader validator, 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 while maintaining a linear canonical chain at sequential heights; 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 field to a canonical gas limit value, replacing a proposer identity field with the promoting validator's identity, and computing a new cryptographic signature over the modified block header.

  2. The method of claim 1, further comprising classifying incoming blocks as attestation blocks or canonical blocks based on a three-condition test comprising: (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. The method of claim 1, wherein deterministically promoting the attestation block further comprises:

    • computing a circular distance for each non-leader validator from the designated leader in a deterministically sorted list of validator public keys, the circular distance defining the validator's position;
    • selecting the attestation block produced by the non-leader validator at position zero for promotion; and
    • if the position-zero validator has not produced an attestation or has also failed, selecting the attestation block from the next lowest-position validator.

  4. The method of claim 3, wherein a promotion timeout for each validator is computed as a base grace period plus the product of the validator's position and a stagger interval, thereby ensuring that at most one validator attempts promotion at any given time.

  5. The method of claim 1, wherein the multi-parent field of each canonical block header comprises a variable-length vector of cryptographic hashes, wherein:

    • a 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 a 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. The method of claim 1, wherein 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 in the attestation block's multi-parent field;
    • a failover readiness signal indicating the validator is prepared to assume leadership; and
    • a heartbeat confirming the validator's clock is within acceptable drift of the network; thereby unifying failover, voting, liveness detection, and heartbeat into a single mechanism requiring no separate message types.

  7. The method of claim 1, wherein attestation blocks are never finalized against a canonical state of the distributed ledger system 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. The method of claim 1, wherein 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 a 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 a cumulative weight distribution corresponds to the seed value modulo a total weight of all active validators.

  9. The method of claim 1, wherein storing each attestation block comprises using a key format comprising a block height encoded as a fixed-width big-endian integer concatenated with an 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. The method of claim 1, further comprising, when operating in conjunction with a direct transaction forwarding pipeline, including in each attestation block 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 the attestation block still contains zero transactions for execution.

  11. The method of claim 1, further comprising enforcing the following security invariants:

    • accepting at most one attestation block per validator per block height;
    • rejecting any attestation block containing non-empty transactions;
    • prohibiting the designated leader for a height from producing attestation blocks at that height; and
    • flagging duplicate attestations from a same validator at a same height as Byzantine behavior.

  12. The method of claim 1, further comprising tracking a first attestation observation timestamp 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 the peer-to-peer network, and resetting the timestamp to zero upon finalization of a canonical block at that height.

  13. The method of claim 1, wherein the non-leader validators produce attestation blocks at staggered intervals determined by each validator's circular distance from the designated leader in a sorted list of validator public keys, with nearer validators producing attestation blocks earlier than more distant validators, thereby preventing simultaneous attestation production and ensuring ordered failover.

  14. A distributed ledger system comprising:

    • a plurality of validator nodes, each comprising at least one processor and a 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;
    • wherein the instructions, when executed, cause each validator node to:
      • participate in 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, produce an attestation block comprising a cryptographically signed block structure containing zero transactions and having a gas limit field set to a sentinel value of zero, and store the attestation block in the attestation storage partition;
      • when producing a canonical block as a designated leader, include hashes of received attestation blocks in a multi-parent field of the canonical block header; and
      • when the designated leader fails entirely, deterministically promote an attestation block to canonical status by transforming the gas limit field, replacing a proposer identity, and re-signing the block.

  15. The system of claim 14, wherein producing an attestation block simultaneously serves as a liveness proof, an implicit vote for the canonical chain state, a failover readiness signal, and a heartbeat, thereby unifying four traditionally separate consensus mechanisms into a single block structure.

  16. The system of claim 14, wherein the attestation blocks are never finalized against a canonical state and contain zero transactions, such that no block rollback is required when a delayed canonical block from the designated leader arrives.

  17. The system of claim 14, wherein each validator node computes a staggered attestation production timeout based on the validator's circular distance from the designated leader in a deterministically sorted validator set, preventing multiple validators from simultaneously producing attestation blocks.

  18. 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 comprising a plurality of validator nodes, cause the one or more processors to:

    • participate in a leader-based consensus protocol wherein a designated leader validator produces canonical blocks;
    • when the designated leader fails to produce a canonical block within a timeout period, produce a zero-transaction attestation block with a gas limit sentinel value of zero, and store the attestation block separately from a canonical blockchain;
    • reference hashes of attestation blocks in a multi-parent field of subsequent canonical block headers, forming a directed acyclic graph structure while maintaining a linear canonical chain; and
    • deterministically promote an attestation block to canonical status when the designated leader fails entirely.

  19. The non-transitory computer-readable storage medium of claim 18, wherein the instructions further cause the one or more processors to classify incoming blocks as attestation blocks based on a three-condition test comprising zero transactions, non-leader proposer origin, and a gas limit field equal to zero.

  20. The non-transitory computer-readable storage medium of claim 18, wherein the instructions further cause the one or more processors to unify failover block production, Byzantine voting, liveness detection, and heartbeat functionality into the single attestation block mechanism.

ABSTRACT OF THE DISCLOSURE​

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 block 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.

FILING NOTES​

USPTO Provisional Patent Application Requirements​

What this document covers: A US provisional patent application requires only a written description that enables a person skilled in the art to make and use the invention. Claims are optional (but included here for completeness and to establish claim scope early). Formal drawings are not required for a provisional but are recommended.

Filing fee: $80 (micro-entity) or $160 (small entity) via USPTO EFS-Web.

Micro-entity qualification (37 CFR 1.29): The applicant qualifies if:

  1. Meets small entity requirements (fewer than 500 employees);
  2. Has not been named as inventor on more than 4 previously filed US patent applications (CJ has 2: 63/914,009 and 63/987,929 -- this would be #3);
  3. Did not have a gross income exceeding 3x the median household income (~$225,000) in the previous calendar year; and
  4. Has not assigned or obligated rights to an entity exceeding the income threshold.

12-month deadline: A non-provisional application claiming priority to this provisional must be filed within 12 months of the provisional filing date.

PCT route: Within 12 months, a PCT application can be filed claiming priority to this provisional, providing 30 months to enter national phase in UK, EU, and other jurisdictions.

Formatting for PDF Submission​

  • US Letter size (8.5" x 11")
  • Margins: minimum 1" top, 0.75" left/right/bottom
  • Font: 12-point minimum, preferably Times New Roman or Arial
  • Line spacing: 1.5 or double
  • Pages numbered consecutively
  • Each section starts on a new page (description, claims, abstract)

Inventor and Applicant​

  • Inventor: Christopher James Fernandes
  • Applicant: Vexidus Labs Ltd (assignee)
  • Correspondence Address: [To be completed]
  • U.S. Provisional Patent Application No. 63/914,009 (IntentVM), filed February 8, 2026
  • U.S. Provisional Patent Application No. 63/987,929 (VexBridge), filed February 21, 2026

Docket Information​

  • Title: Adaptive Attestation Directed Acyclic Graph Consensus Protocol for Distributed Ledger Systems
  • Internal Reference: VEX-PAT-003
  • Technology Area: Blockchain / Distributed Systems / Consensus Protocols