From Private Besu to Espresso
This guide is for teams running a private, permissioned Besu network who want to move to an Espresso-based application environment. It covers what changes, what stays the same, and how the architecture fits together.
Why migrate
A private permissioned Besu network gives institutions control and privacy, but limits what they can prove to the outside world and constrains throughput to a single execution environment.
Espresso resolves this without requiring you to abandon your existing EVM logic, smart contracts, or access controls.
Transaction privacy
Yes
Yes, blocks encrypted before submission
Control over execution rules
Yes
Yes, unchanged
Decentralized finality
No
Yes, Proof of Stake consensus
External verifiability
Limited
State finalized by Espresso is verifiable by counterparties
Crosschain coordination
Manual or bridge-dependent
ZK-proof-secured, no trusted intermediary
Horizontal scale
Single instance
Multiple parallel Besu instances, each scaling independently
What stays the same
Your Besu EVM instance and execution logic
Your smart contracts
Your access controls and permissioning rules
Your compliance configuration
Your existing RPC interface for internal clients
You do not need to rewrite application logic or adopt a new VM. Espresso integrates at the settlement layer, below your existing execution environment.
What changes
Settlement moves to Espresso
Your Besu network currently handles ordering, finality, and execution internally through a single system. On Espresso, a dedicated sequencer handles ordering and streams blocks to Espresso, which provides finality through Proof of Stake consensus. Your Besu environment continues to execute transactions, but against Espresso's finalized transaction stream rather than an internally managed one.
A sequencer is added per application environment
Each Besu application environment gets a dedicated sequencer. The sequencer is responsible for ordering incoming transactions and streaming them to Espresso. Blocks can be encrypted before submission, so Espresso finalizes the transaction sequence without ever seeing the plaintext transaction content.
In the initial deployment, each application environment uses a single dedicated sequencer. Rotating and decentralized sequencers are supported for use cases that require them.
RPC nodes read from Espresso
Your RPC nodes, and any authorized clients that derive application state, read the finalized transaction stream from Espresso rather than directly from a local Besu instance. They decrypt blocks using access keys they hold, then execute the deterministic Besu logic to derive state. Because Espresso's consensus ensures all participants observe the same finalized sequence, all authorized clients derive identical state.
ZK provers are added for crosschain coordination
If your application needs to coordinate with other environments, for example using assets on one Besu instance as collateral in agreements on another, ZK provers generate zero-knowledge proofs that are attached to crosschain messages. Destination environments verify the proof without re-executing the source logic or accessing private data.
Multiple Besu application environments can run in parallel on Espresso. Espresso finalizes a unified sequence of transactions across all of them, and each environment scales throughput independently.
Migration path
Stage 1: Internal deployment
Deploy a test Espresso environment alongside your existing Besu network. Validate that your smart contracts and execution logic behave identically when running against Espresso's finalized stream. Espresso provides devops assistance and async support throughout this stage.
Estimated time: 3 to 4 days.
Stage 2: Devnet
Deploy to a shared development network. Validate sequencer configuration, encrypted block submission, and RPC node integration against a live Espresso environment.
Stage 3: Testnet
Run on Espresso's testnet. A minimum clean run of 5 to 7 days is required before proceeding to Mainnet. Espresso provides 24/7 monitoring throughout this stage.
Stage 4: Mainnet
Go live on Espresso Mainnet. Your application environment settles through Espresso's decentralized validator network.
Multiple instances for scale
A single Besu EVM instance has throughput limits. Espresso supports deploying multiple parallel Besu instances for the same application, each with its own sequencer, all settling through Espresso. Throughput scales linearly across instances while Espresso's finality latency stays bounded. This is how high-volume financial workloads, such as collateral management at institutional scale, can be supported without redesigning application logic.
Next steps
Contact Espresso to schedule a kick-off call and architecture review.
Configurable Execution Environments explains what you control vs. what Espresso provides.
What is Espresso? covers the consensus and ZK proof design in more detail.
Last updated