Pith. sign in

REVIEW 1 cited by

Flow: Separating Consensus and Compute -- Block Formation and Execution

Not yet reviewed by Pith; the record is open.

This paper has not been read by Pith yet. Machine review is queued; the pith claim, tier, and objections will appear here once it completes.

SPECIMEN: schema-true, not a live event

T0 review · schema-true

One-sentence machine reading of the paper's core claim.

pith:XXXXXXXX · record.json · timestamp

arxiv 2002.07403 v1 pith:6MEII3QT submitted 2020-02-18 cs.DC

classification cs.DC
keywords nodesconsensusexecutionflowtransactionblockcollectorsystem
verification ladder T0 review T1 audit T2 compute T3 formal
0 comments
read the original abstract

Most current blockchains require all full nodes to execute all tasks limits the throughput of existing blockchains, which are well documented and among the most significant hurdles for the widespread adoption of decentralized technology. This paper extends out presentation of Flow, a pipelined blockchain architecture, which separates the process of consensus on the transaction order from transaction computation. As we experimentally showed in our previous white paper, our architecture provides a significant throughput improvement while preserving the security of the system. Flow exploits the heterogeneity offered by the nodes, in terms of bandwidth, storage, and computational capacity, and defines the roles for the nodes based on their tasks in the pipeline, i.e., Collector, Consensus, Execution, and Verification. While transaction collection from the user agents is completed through the bandwidth-optimized Collector Nodes, the execution of them is done by the compute-optimized Execution Nodes. Checking the execution result is then distributed among a more extensive set of Verification Nodes, which confirm the result is correct in a distributed and parallel manner. In contrast to more traditional blockchain architectures, Flow's Consensus Nodes do not execute the transaction. Instead, Verification Nodes report observed faulty executions to the Consensus Nodes, which adjudicate the received challenges and slash malicious actors. In this paper, we detail the lifecycle of the transactions from the submission to the system until they are getting executed. The paper covers the Collector, Consensus, and Execution role. We provide a protocol specification of collecting the transactions, forming a block, and executing the resulting block. Moreover, we elaborate on the safety and liveness of the system concerning these processes.

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Leader Rotation Is Not Enough: Scrutinizing Leadership Democracy of Chained BFT Consensus

    cs.CR 2025-01 conditional novelty 6.0 of 10

    A Markov Decision Process analysis shows that chained BFT protocols (2CHS, CHS, Streamlet, Fast-HotStuff) have zero attack threshold for leadership democracy, and proposed countermeasures can raise the threshold to ab...

Pith tools