Implement Verified Random Function (VRF) for Randomized Leader Election

[hadv]

As part of the security improvements for the Simplex Consensus Protocol implementation, we need to implement randomized leader election to resist censorship and adaptive adversary attacks.

Requirements:

• Integrate a VRF implementation (e.g., schnorrkel or similar Rust crate if applicable, or standard BLS/Ed25519 based VRF).
• Replace the current deterministic or round-robin leader election with a VRF-based selection.
• Ensure that the leader election is verifiable by other nodes.
• Update the consensus logic to validate the leader's VRF proof before accepting a block/proposal.

Context:
Simplex consensus relies on randomized leader election to mitigate risks where an adversary could target the known next leader. VRF provides a cryptographic way to select a leader randomly such that the choice cannot be predicted long in advance but can be verified by everyone once revealed.

[hadv]

Alternative Option: DAG Consensus

In addition to (or as an alternative to) improving Simplex with VRF, we should consider adding DAG-based consensus (e.g., Narwhal/Bullshark) as a supported option.

Research Context:
Simplex consensus has (n^2)$ communication complexity, which limits scalability. A DAG-based approach could offer better throughput and scalability for larger networks.

Implementation Proposal:

1. Refactor into a trait/interface (decoupling ).
2. Implement a DAG consensus engine (e.g., implementing strict partial ordering of blocks).
3. Allow users to select the consensus mechanism via config/CLI (e.g., --consensus dag).

[hadv]

Alternative Option: DAG Consensus

In addition to (or as an alternative to) improving Simplex with VRF, we should consider adding DAG-based consensus (e.g., Narwhal/Bullshark) as a supported option.

Research Context:
Simplex consensus has O(n^2) communication complexity, which limits scalability. A DAG-based approach could offer better throughput and scalability for larger networks.

Implementation Proposal:

1. Refactor Consensus into a trait/interface (decoupling SimplexState).
2. Implement a DAG consensus engine (e.g., implementing strict partial ordering of blocks).
3. Allow users to select the consensus mechanism via config/CLI (e.g., --consensus dag).