Technical Roadmaps

Achieving broader permissionless participation necessitates that nodes, particularly those involved in consensus, are resilient against all possible attacks. While the Flow implementation of HotStuff-Jolteon  [10] and Consensus Follower [11] already provide robust BFT, further engineering efforts are required for other components. These range from minor tweaks to major overhauls. 

Below, we briefly summarize the highest-priority work streams for permissionless consensus participation:

Hardening the Staking Process with Proof of Possession

Proof of Possession [PoP] is a critical mechanism for the security of protocol signatures: a new node wanting to stake must prove it owns the private key corresponding to the public key it submits in the staking transaction [23]. Without PoPs, a malicious participant can fake a block attestation or a result approval.

Prevent Byzantine Nodes from Modifying Relayed Messages

At the moment, there are malleability edge cases with Flow blocks and other messages that nodes exchange. This does not pose an immediate threat since Consensus, Verification, and Collector Nodes are currently run by credible operators and are hence non-byzantine. However, it is crucial to close the malleability surface before enabling permissionless participation for these node types to prevent undetected propagation of incorrect data. In the future, verified data sharing among Access Nodes and trustless light clients will be ensured, requiring the resolution of malleability issues.

Automated Performance Incentives and Slashing

Flow uses rewards and financial penalties to incentivize availability, throughput, speed, correctness, and safety. The HotStuff-Jolteon implementation on Flow already detects and records all consensus violations, but adjudication and punishment currently rely on human governance. In the future, Message Forensics will enable nodes to conclusively prove fault for malicious messages and automated adjudication of slashing challenges and ejection of misbehaving nodes will be enabled. Overall, this work will drastically shorten attack windows and enable Flow to autonomously suppress attacks.

In practice, slow or unresponsive nodes are more common than malicious participants. Performance-Dependent Rewards mitigate this challenge: fast and reliable nodes receive higher compensation, while significantly underperforming nodes receive minimal rewards. This system discourages freeloaders and incentivizes high service levels. 

Hardening Against Malformed Messages from Consensus Nodes

For permissionless consensus participation, it is essential to harden all nodes' business logic against malformed messages from Consensus Nodes. While the HotStuff-Jolteon implementation on Flow is already BFT, it only inspects block headers, leaving some residual surface for malformed block payloads and other messages, such as synchronization requests to re-send data. The existing message-inspection framework, which currently protects against malicious Access Nodes, will be extended to include additional checks for consensus messages.

Resilience to Unresponsive or Malicious Verification Nodes

Extensive Checking Mode is crucial for the resilience of Flow against unresponsive verifiers, ensuring that a correct result receives the necessary verification approvals to be committed (sealed). In cases involving unresponsive verifiers, Consensus Nodes engage Extensive Checking Mode to incrementally expand the verifier set assigned to check the execution result. In the worst-case scenario, where ⅓ of verifiers are maliciously colluding with an Execution Node publishing an incorrect result, 100% of verifiers might eventually need to check the results. In monolithic blockchains, this "worst-case" cost of all nodes executing every transaction is the default. Comparatively, with a lower fraction of Byzantine verifiers (the overwhelmingly likely scenario), the probability of the worst-case verification cost in Flow exponentially decreases, making Flow an order of magnitude more energy and hardware-efficient than monolithic architectures.

While implementing Extensive Checking Mode on Consensus Nodes is relatively straightforward, adding the corresponding logic to Verification Nodes will require a larger-scale software revision. This would be most efficient if done alongside strategic performance improvements to Verification Nodes, enabling for optimistic verification of unfinalized forks (significant latency improvements) and resilience against malicious inputs from prospective Byzantine Execution Nodes (working towards permissionless Execution Nodes).

In some areas, the work on permissionless consensus participation naturally extends to Permissionless Verification Nodes, such as Extensive Checking Mode, Slashing, Performance-Dependent Rewards, and resilience to malicious messages from Verification Nodes. Additionally, there are clear work streams specific to Verification Nodes, summarized below. Interested readers can refer to the Verification Node Roadmap for further details. 

Faster Verification of Execution Results

Optimistic verification allows Verification Nodes to check the execution results for unfinalized blocks. This enhances network efficiency and improves the overall user experience by speeding up transaction confirmations.

Scaling the Flow Solution to the Verifier's Dilemma to Thousands of Nodes

Specialized Proof of Confidential Knowledge [SPoCK] is a novel cryptographic technique [24] that Flow uses to solve the Verifier’s Dilemma inherent to blockchains. The Verifier's Dilemma states that in blockchains with few cheaters, verifiers are incentivized to rubber-stamp all results as correct rather than perform costly verification [25].

At maturity, Flow aims to have over 1000 Verification Nodes, each checking about 8% of a block's computation. When included individually in a block, the proofs confirming that enough Verification Nodes actually confirmed the computation would consume roughly 3MB, exceeding the current 1MB block size limit for fast consensus. Since the Flow implementation of SPoCK is based on the BLS scheme [26], it can likely also be aggregated, reducing data size and improving efficiency. Formal security proofs for peer-reviewed publication are currently being worked on, followed by implementation.

Flow Collector Nodes form a horizontally scaling data-availability layer: they collect incoming transactions and group them into batches called ‘collections’. Collections are sent directly to the Execution and Access Nodes, while Consensus Nodes reference the collections in their blocks by hash [6]. The need for nodes to gracefully handle malformed messages from Collectors, slashing, and performance-dependent rewards are analogous to the other node roles. Beyond that, the remaining work for permissionless collector participation is limited to the following.

Proof of Collection Finality

Groups of collectors (known as ‘collector clusters’) use a mini-version of HotStuff to agree on which transactions to include in their collections. This ensures robust data availability and mitigates resource exhaustion attacks by preventing individual collectors from including garbage or repetitive transactions. As long as the fraction of Byzantine collectors in each cluster is less than one-third, malicious collections proposed by permissionless collectors will not be finalized by the cluster consensus, and the proposing collector will eventually be slashed. With only honest collectors, Consensus Nodes can currently trust that any collection submitted for inclusion in a block is indeed finalized as prescribed by the protocol. Before admitting permissionless collectors, this shortcut must be removed by adding proofs of collection finality.

Remove Centralized Initialization of Collector Clusters After Major Network Upgrades

Every week (referred to as an ‘epoch’), nodes can join or leave the Flow network at predefined points. Before a new epoch starts, the protocol randomly partitions all Collector Nodes participating in this epoch into new clusters. At initialization, each cluster requires a root collection as a starting point for their cluster consensus, and these root collections need to be signed by a supermajority of the collectors in the respective cluster (similar to a genesis block when starting a new chain). 

While the network is running, Collector Nodes use a smart contract to generate the root collections and gather their signatures. However, during major protocol upgrades, the network is temporarily stopped and restarted with the new version of the protocol, meaning there is not at that time a running network to generate the root collections. During these major upgrades, the Flow Foundation currently gathers the collector signatures and disseminates the root collections back to the collector clusters to enable them to start. The protocol’s dependence on the Flow Foundation as a coordinator of these network upgrades will be progressively reduced over time.

At present, the Flow network will benefit most from enabling permissionless participation of Consensus, Verification, and Collector Nodes while increasing the seats for permissionless Access Nodes. Due to their significant hardware requirements and the deterministic nature of their work, enabling permissionless participation of Execution Nodes will likely be one of the later steps.