In zero-knowledge proof (ZKP) systems like zk-SNARKs and zk-STARKs, the preprocessing phase (or setup phase) is a one-time, circuit-specific procedure that generates the proving key and verification key required for all subsequent proof generation and verification. This phase compiles a high-level program, representing the statement to be proven (e.g., "I know a valid transaction"), into a system of cryptographic constraints. For zk-SNARKs, this often involves a trusted setup ceremony to generate a Common Reference String (CRS), a critical process that, if compromised, could allow fraudulent proofs. In contrast, zk-STARKs use publicly verifiable randomness to achieve a transparent setup, eliminating this trust assumption.
LABS
Glossary
Preprocessing Phase
An offline setup in Multi-Party Computation (MPC) protocols where parties generate and share correlated randomness to accelerate secure online computation.
Chainscore © 2026
definition
BLOCKCHAIN CONTEXT
What is Preprocessing Phase?
The initial, off-chain stage in a zero-knowledge proof system where the prover prepares the computational statement to be proven.
The output of this phase is highly specialized. The proving key is used by the prover to generate a succinct proof that they possess a valid witness (private input) satisfying the circuit's constraints. The verification key, which is much smaller, is used by any verifier to check the proof's validity in constant time, independent of the original computation's complexity. This separation is fundamental to the efficiency of ZKPs, as the heavy cryptographic lifting is done once during preprocessing, enabling fast and scalable proof generation and verification thereafter. The security of the entire system hinges on the integrity of this phase's execution.
Practical implementations vary by protocol. In zk-SNARKs (e.g., Groth16), the preprocessing is circuit-specific and requires a meticulous multi-party computation (MPC) ceremony to decentralize trust. For zk-STARKs, the setup is transparent, relying on public hash functions, making it more agile for updating circuits but often resulting in larger proof sizes. Recursive proof systems and proof aggregation techniques may have their own preprocessing requirements to compose proofs efficiently. Understanding this phase is crucial for developers choosing a ZKP framework, as it dictates trust models, upgradeability, and initial deployment overhead.
The preprocessing phase is a cornerstone for applications like zk-Rollups (e.g., zkSync, StarkNet), where a single verification key can be used to validate batches of thousands of transactions. It also enables private smart contracts and identity attestations by allowing users to prove compliance with rules without revealing underlying data. While computationally intensive upfront, this phase unlocks the paradigm of verifiable computation, where trust is transferred from repeated execution to a single, cryptographically sound verification step.
how-it-works
BLOCKCHAIN CONSENSUS
How the Preprocessing Phase Works
The preprocessing phase is a critical preparatory stage in a blockchain's consensus mechanism, where transaction data is validated, ordered, and batched before being finalized into a block.
In the preprocessing phase, network nodes receive and verify incoming transactions against the protocol's rules, checking for validity—such as correct digital signatures, sufficient funds, and proper syntax—before they are considered for inclusion in a new block. This stage involves collecting transactions into a mempool (memory pool), where they await processing. Nodes perform initial checks to filter out invalid or malformed transactions, preventing them from consuming further network resources and ensuring only legitimate data proceeds to the consensus layer.
Following validation, the phase often includes ordering and batching transactions. In many protocols, a designated node, such as a block proposer in Proof-of-Stake or a leader in some BFT-based systems, is responsible for selecting transactions from the mempool and arranging them into a proposed block template. This ordering can be first-in-first-out (FIFO) or based on factors like transaction fees (e.g., gas price in Ethereum) to optimize for network throughput and economic incentives. The output of this phase is a candidate block, ready for formal approval.
The preprocessing phase is distinct from the final consensus round. It handles the computational groundwork—validation and proposal—so the subsequent voting or proof-generation phase can focus solely on agreeing on the block's legitimacy and order. This separation of duties enhances efficiency; for instance, in Tendermint, a proposer creates a block in the preprocessing round, which is then voted on by validators in a consensus round. Efficient preprocessing directly impacts a network's time-to-finality and overall scalability by streamlining the data pipeline leading to irreversible settlement.
key-features
BLOCKCHAIN GLOSSARY
Key Features of the Preprocessing Phase
The preprocessing phase is the initial stage of transaction execution in a blockchain network, where transactions are validated, ordered, and prepared for inclusion in a block.
01
Transaction Validation
The first critical step where nodes verify the cryptographic signatures and check the nonce and account balance of the sender to ensure the transaction is legitimate and well-formed before it is considered for ordering. This prevents invalid transactions from consuming network resources.
02
Mempool Management
The mempool (memory pool) is a temporary holding area for validated transactions awaiting confirmation. Key functions include:
- Prioritization: Sorting transactions, often by gas price or fee.
- Eviction: Removing stale or invalidated transactions.
- Propagation: Sharing the transaction set with peer nodes.
03
Transaction Ordering
Determines the sequence in which transactions from the mempool will be executed. This is a core function of consensus mechanisms and can be influenced by:
- First-Come-First-Served (FCFS): Simple but susceptible to manipulation.
- Priority Gas Auction (PGA): Users bid for earlier inclusion.
- Leader/Sequencer Selection: In PoS or rollups, a designated node orders transactions.
04
State Access List Preparation
For EVM-compatible chains, this involves pre-fetching the state trie data (account balances, contract code, storage slots) that the transaction will read or modify. This optimization, formalized by EIP-2930, reduces execution complexity and can lower gas costs by declaring accessed addresses and storage keys upfront.
05
Frontrunning & MEV Mitigation
The public nature of the mempool during preprocessing exposes transactions to Maximal Extractable Value (MEV) exploitation, such as frontrunning and sandwich attacks. Mitigation strategies developed in this phase include:
- Private Transaction Pools (e.g., Flashbots Protect).
- Commit-Reveal Schemes.
- Fair Sequencing Services.
06
Fee Market Dynamics
The preprocessing phase is where the blockchain's fee market operates. Users submit transactions with a bid (gas price/base fee + priority fee). Validators or block producers select transactions to maximize their revenue, creating a real-time auction that determines network congestion and the cost of inclusion.
common-protocols
ARCHITECTURAL PATTERNS
Protocols Utilizing Preprocessing
The preprocessing phase is a critical architectural component for scaling blockchains, where transaction execution is separated from consensus. This section details the major protocols that implement this pattern to achieve high throughput and low latency.
02
Solana
Solana's architecture features a pipelining mechanism where transaction processing is broken into sequential, specialized hardware stages. A key preprocessing step is the Banking Stage, which performs signature verification, deduplication, and scheduling of transactions before they enter the execution pipeline. This preprocessing allows validators to stream transactions efficiently, contributing to Solana's high throughput by maximizing CPU and GPU utilization across multiple cores.
03
Sui
Sui employs an object-centric data model and leverages Byzantine Consistent Broadcast for simple transactions. For transactions involving only owned objects (e.g., a peer-to-peer transfer), Sui validators can preprocess and commit them immediately without global consensus. This parallelizable preprocessing of independent transactions eliminates bottlenecks, enabling sub-second finality for a large subset of operations. Complex transactions involving shared objects still use its Narwhal & Bullshark consensus.
04
Aptos
Aptos uses the Block-STM parallel execution engine. Preprocessing here involves a shared mempool and transaction ordering via its AptosBFT consensus. Validators sequence transactions into a block, and Block-STM then speculatively executes them in parallel, using software transactional memory to manage conflicts. This design pre-orders transactions for parallel processing, dramatically increasing throughput compared to sequential execution models.
05
Monad
Monad is building a parallelized Ethereum Virtual Machine (EVM) execution layer from the ground up. Its preprocessing phase is centered on MonadBFT, a pipelined consensus algorithm, and deferred execution. Validators agree on the order of transactions (consensus) before fully executing them. This separation allows execution to be parallelized optimistically, and any state discrepancies are resolved later, decoupling consensus latency from execution time to maximize hardware efficiency.
06
Fuel Network
Fuel is a modular execution layer (Layer 2) optimized for the UTXO model. Its core innovation is parallel transaction execution enabled by strict access lists in its FuelVM. During preprocessing, transactions declare their state dependencies. The FuelVM scheduler can then execute non-conflicting transactions in parallel. This design requires upfront dependency declaration, making the preprocessing phase critical for unlocking massive parallel throughput.
ZK-ROLLUP EXECUTION
Preprocessing vs. Online Phase Comparison
A comparison of the two primary phases in a ZK-Rollup's transaction lifecycle, highlighting their distinct computational, trust, and latency characteristics.
| Characteristic | Preprocessing Phase | Online Phase |
|---|---|---|
Primary Function | Proof Generation & State Commitment | Transaction Execution & Validation |
Location | Off-chain (Prover Node) | On-chain (L1 Smart Contract) |
Computational Load | High (ZK-SNARK/STARK proving) | Low (Proof verification only) |
Latency | Seconds to minutes | Block time (e.g., ~12 sec) |
Trust Assumption | Cryptographic (Validity proof) | Economic (Bond slashing) |
State Data | Generates new state root & proof | Verifies proof & updates canonical state |
User Interaction | None (automated by sequencer/prover) | Final settlement & asset withdrawal |
Cost Driver | Proof generation (compute-heavy) | L1 gas for data & verification |
generated-materials
PREPROCESSING PHASE
Types of Correlated Randomness Generated
During the preprocessing phase of a threshold signature scheme (TSS), participants collaboratively generate and distribute secret shares that will later enable the creation of a single, valid signature. This phase produces several key cryptographic components.
01
Secret Shares
The core output of the distributed key generation (DKG) protocol. Each participant receives a secret share, which is a piece of the group's collective private key. No single party ever knows the full private key.
- Purpose: Enables threshold signing where a subset of participants (e.g., 3-of-5) can collaborate to sign.
- Property: Shares are generated such that they are statistically independent of the actual private key, ensuring security.
02
Verification Keys & Public Key
Alongside secret shares, participants generate corresponding verification keys (also called public key shares).
- Individual Verification Key: Allows any party to cryptographically verify that a signature share is valid and was created by the holder of the corresponding secret share.
- Group Public Key: The aggregate of all verification keys, which is the public address others use to send assets or verify the final, combined signature.
03
Randomness Commitments
To ensure the integrity of the preprocessing, participants broadcast commitments to their secret polynomials or shares before revealing them.
- Mechanism: Typically a Pedersen Commitment or Feldman's Verifiable Secret Sharing (VSS) scheme.
- Purpose: Provides a public, binding commitment that allows other participants to verify that the shares they later receive are consistent and were not altered after the fact, preventing malicious behavior.
04
Non-Interactive Zero-Knowledge Proofs
Participants often generate zero-knowledge proofs (ZKPs) to prove the correctness of their secret shares without revealing the shares themselves.
- Example: A Schnorr proof or DLEQ (Discrete Logarithm Equality) proof.
- Function: Proves that a participant's public verification key is correctly derived from their secret share, and that all participants are contributing to the same group public key. This is critical for malicious participant detection.
05
Pre-Signatures (if applicable)
In some advanced protocols like FROST or for blind signing, the preprocessing phase can generate pre-signatures or nonce commitments.
- Composition: These are pre-computed, one-time-use secret nonce shares and their public commitments.
- Advantage: Allows the final signing phase to be non-interactive or asynchronous, significantly improving latency and practicality for applications like blockchain validators.
security-model
BLOCKCHAIN FUNDAMENTALS
Security Model and Trust
This section examines the foundational security assumptions and trust models that underpin blockchain networks, focusing on the critical preprocessing phase where participants agree on rules before execution.
The security model of a blockchain defines the assumptions about participant behavior—such as the number of malicious or faulty nodes the system can tolerate—required to maintain the network's core guarantees of consensus, data availability, and state validity. This model establishes the trust boundary, specifying whether the system is secured by cryptographic proofs (trust-minimized), a known set of validators (trusted), or a hybrid approach. The preprocessing phase is a crucial initial stage where these security parameters and protocol rules are established and agreed upon by network participants before any transactions are processed.
During the preprocessing phase, often implemented via a genesis block or a smart contract deployment, the system's initial state and consensus rules are cryptographically committed. This includes defining the validator set, staking requirements, governance parameters, and the logic for fraud proofs or validity proofs. This phase is trust-critical; if the preprocessing setup is compromised, the security of all subsequent transactions is undermined. For example, in optimistic rollups, the one-week fraud challenge window and the identity of the whitelisted verifiers are set in this phase.
Different architectures leverage distinct trust models in preprocessing. A proof-of-work chain like Bitcoin establishes trust through economic expenditure and a longest-chain rule encoded at genesis. A proof-of-stake network like Ethereum defines its validator set and slashing conditions. Layer 2 solutions often inherit security from a Layer 1 during preprocessing by posting a commitment (like a state root or a validity proof) to a smart contract on the base chain, thereby anchoring their security to the underlying blockchain's consensus mechanism.
benefits-advantages
PREPROCESSING PHASE
Benefits and Advantages
The preprocessing phase in a zero-knowledge proof system transforms raw computation into a structured, provable format. This foundational step is critical for achieving the efficiency and security guarantees of ZK proofs.
01
Computational Offloading
The heavy lifting of converting a program into a constraint system (like R1CS or Plonkish) is performed once during preprocessing. This allows the prover and verifier to reuse the same structured circuit for multiple proofs, drastically reducing the per-proof computational overhead.
02
Verifier Efficiency
Preprocessing generates a small, fixed verification key for the verifier. This key is a cryptographic digest of the circuit, enabling the verifier to check proofs in constant time (often milliseconds) regardless of the original program's complexity, which is essential for blockchain scalability.
03
Prover Setup & Optimization
The phase produces a proving key and often performs circuit-specific optimizations (e.g., gate ordering, lookup table generation). This setup allows the prover to generate subsequent proofs much faster than if it had to compile the circuit from scratch for each execution.
04
Trusted Setup Requirements
For certain proving systems (e.g., Groth16), preprocessing involves a trusted setup ceremony to generate cryptographic parameters. This is a critical security step where toxic waste must be discarded; its completion establishes a foundation of trust for all proofs using that circuit.
05
Enabling Universal Circuits
Advanced preprocessing can create universal circuits or recursive proof systems. For example, a preprocessing step might set up a circuit that can verify proofs of other circuits, enabling scalable rollups and complex proof composition without re-running the full setup.
06
Deterministic Proof Generation
By fixing the circuit structure and cryptographic parameters upfront, preprocessing ensures that proof generation is deterministic for a given witness. This eliminates runtime variability and guarantees that valid proofs will always be accepted by the pre-configured verifier.
PREPROCESSING PHASE
Frequently Asked Questions (FAQ)
Common questions about the initial stage of blockchain transaction processing, where transactions are validated, ordered, and prepared for execution.
The Preprocessing Phase is the initial stage in a blockchain's transaction lifecycle where transactions are received, validated, and ordered before being passed to the execution engine. It involves verifying the basic syntactic and cryptographic integrity of a transaction, such as checking the digital signature, ensuring the transaction format is correct, and confirming the sender has a sufficient nonce. This phase does not execute the transaction's logic or modify the global state; it merely prepares a valid, ordered batch of transactions for the subsequent Execution Phase. Its primary output is a Candidate Block or a Mempool of pending, validated transactions.
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall