github.com/onflow/flow-go@v0.35.7-crescendo-preview.23-atree-inlining/cmd/verification/README.md (about)

     1  # Verification
     2  ## Overview
     3  Verification nodes (VN) are responsible for verifying the correctness of execution results, generated by execution nodes as a result of running all collections inside a block. An execution node wraps each execution result by a container called "execution receipt" and broadcasts it to verification nodes. 
     4  
     5  In this document, we provide a high-level overview of the verification node's architecture. Each section includes links to the appropriate package, which may contain more detailed documentation.
     6  
     7  **Table of Contents**
     8  
     9  - [Terminologies](#terminologies)
    10    - [Execution Result](#execution-result)
    11    - [Chunk](#chunk)
    12    - [Execution Receipt](#execution-receipt)
    13    - [Chunk Data Pack](#chunk-data-pack)
    14    - [Verifiable Chunk](#verifiable-chunk)
    15    - [Result Approval](#result-approval)
    16  - [Software Architecture](#software-architecture)
    17    - [Follower Engine](#follower-engine)
    18    - [Finder Engine](#finder-engine)
    19    - [Match Engine](#match-engine)
    20    - [Verifier Engine](#verifier-engine)
    21  
    22  
    23  ## Terminologies
    24  
    25  ### [Execution Result](../../model/flow/executionResult.go)
    26  An execution result represents a commitment from an execution node to the interim and final states of computing the corresponding block, which is referenced by the execution receipt. 
    27  
    28  ### [Chunk](../../model/flow/chunk.go)
    29  Each execution result includes smaller units called [chunks](../../model/flow/chunk.go), each assigned to multiple verification nodes for verification. Each Verification Node only checks a small fraction of chunks through a [publicly verifiable and deterministic chunk assignment](../../module/chunks/publicAssign.go) algorithm.
    30  
    31  ### [Execution Receipt](../../model/flow/executionReceipt.go)
    32  An execution receipt is a signed version of an execution result, which provides authentication of the sender, guarantees the integrity of the message and a Specialized Proof of Confidential Knowledge (SPoCK). The execution receipts are broadcasted to the verification and consensus nodes.
    33  
    34  ### [Chunk Data Package](../../model/flow/chunk.go)
    35  As mentioned each chunk is assigned to multiple verification nodes. In order to be able to verify a chunk, a verification node sends a request for a chunk data package which includes all the data and proofs needed to verify a chunk.
    36  
    37  ### [Verifiable Chunk](../../engine/verification/messages.go)
    38  A "Verifiable Chunk" is an internal data structure of the verification nodes in Flow. A verifiable chunk is associated with a chunk of an execution result. It contains all information required to verify the correctness of execution state transition affected by that chunk.
    39  
    40  ### [Result Approval](../../model/flow/resultApproval.go)
    41  Verification node generates and broadcasts a "Result Approval" to the consensus nodes. A result approval is associated with a specific chunk of an execution result. It implies that the verification node has successfully verified the transition of the execution state represented by this chunk.
    42   
    43  ## Software Architecture
    44  
    45  ![alt text](architecture.svg)
    46  The above figure represents the software architecture of a Verification Node in Flow. The Verification Node is made up of four engines known as *Follower*, *Finder*, *Match*, and *Verifier* engines. 
    47  
    48  
    49  ### [Follower Engine](../../engine/common/follower)
    50  The Follower engine follows the consensus progress and notifies the Finder engine of any new finalized block.
    51  
    52  ### [Finder Engine](../../engine/verification/finder)
    53  The Finder engine receives broadcasted execution receipts from execution nodes as well as finalized blocks from the follower engine. It passes the execution result of each received execution receipt to the match engine if it satisfies the following two conditions: 
    54  - The execution result refers to a finalized block.
    55  - The finder engine has not processed this execution result earlier.
    56  
    57  By _processing_ an execution result, we mean the finder engine passing it successfully to the match engine. The Finder engine is concurrency-safe and ensures that it sends each execution result at most once to the match engine. In other words, it never tries passing a duplicate execution result that it has already processed. 
    58       
    59  ### [Match Engine](../../engine/verification/match)
    60  On receiving an execution result from the finder engine, the match engine performs the [chunk assignment](../../module/chunks/publicAssign.go) algorithm and determines the chunks assigned to this verification node. 
    61  For each assigned chunk, it then asks the execution node for its corresponding chunk data pack. Once the match engine receives a chunk data pack for an assigned chunk, it constructs a verifiable chunk for it and passes it to the verifier engine. Once a verifiable chunk is successfully passed to the verifier engine, its corresponding chunk is marked as a _matched_ chunk. Match engine considers a timeout for each chunk data pack request and retries the timed out chunk data pack requests a few times. It, however, guarantees to match each assigned chunk at most once, i.e., it never repeats passing a verifiable chunk for an already matched chunk. 
    62  
    63  
    64  ### [Verifier Engine](../../engine/verification/verifier)
    65  On receiving a verifiable chunk from the Match engine, the verifier engine performs the *verification* process. The verification process happens by executing all the transactions included in the chunk and verifying the correctness of the execution state transition affected by the chunk. If the chunk passes the verification process, the verifier engine generates a result approval for it and broadcasts it to all consensus nodes. 
    66  
    67  
    68