When an off-the-shelf network can't keep up: why a custom blockchain virtual machine is needed
An off-the-shelf network sets the rules for executing operations rigidly: gas, limits on state size, a fixed set of system calls. As long as the product fits within these bounds, everything works.
As soon as the logic requires frequent computations within a single call, a specific access model, or a non-standard fee model, the transaction either fails to fit within the limit or costs more than it brings in value.
This is exactly where the demand for a custom blockchain virtual machine emerges: not "our own network for the sake of having our own network," but an execution environment designed for a specific workload.
The limitations of off-the-shelf blockchain networks show up in three places. The first is the cost of computation: a universal gas model penalizes heavy operations equally for everyone, even though in your scenario they may be routine.
The second is the rules for executing operations: you can't add a primitive the product needs or remove a check that only burns resources.
The third is the state access model: someone else's read and write rules force you to build workaround layers, and every layer means latency and a point of failure.
Custom virtual machine development begins not with code, but with a workload profile: which operations dominate, how much state needs to be kept hot, where asynchrony is acceptable, and where atomicity is required.
Based on this profile, a set of instructions and the rules for executing them are assembled, so that scenarios typical for the product take a short path rather than going through a universal interpreter.
Proprietary blockchain infrastructure does not mean a break with the ecosystem: nodes, wallets, and external integrations connect through standard interfaces, while the specifics stay inside the execution environment.
The cost of a mistake here is high: execution rules are baked into consensus, and changing them on a live network without a split means losing compatibility and the trust of holders.
That is why the execution environment project and the upgrade model are designed together, not as an afterthought. Below, we break down how this is addressed at the architecture level.
What a Custom Virtual Machine Delivers: The Effect in Numbers and a Comparison of Approaches
A custom blockchain virtual machine delivers an effect that is visible on load graphs: the network absorbs peak transaction spikes without a growing share of rejected operations. Below is exactly what changes and why.
Network Performance Under Load
A standard execution environment processes operations sequentially and hits a single-thread bottleneck as soon as heavy calls pile up in a block. A custom machine makes it possible to parallelize independent operations and move signature verification outside the main loop. In practice, throughput grows severalfold, while response time at peak remains predictable.
Optimizing Operation Execution
Gas rules and the instruction set are designed around the specific logic of the application: expensive operations that your scenario does not use are removed, while frequent calls get a shortcut.
This lowers the cost of a typical transaction and reduces the share of operations that fail due to an insufficient limit.
Infrastructure Resilience
Isolated execution contexts prevent a single faulty contract from bringing down a node or clogging the queue. Under overload, the network degrades smoothly: some operations wait, but they do not fail with an error. The share of failed transactions drops from double-digit values to single-digit percentages.
| Option | When It Fits | Limitations |
|---|---|---|
| Off-the-shelf general-purpose environment | Fast launch, standard scenarios | Speed ceiling, someone else's gas rules |
| Fork of an existing machine | Compatibility with ready-made contracts is needed | Bottlenecks and legacy constraints are inherited |
| Custom machine built for the task | High load, specific logic | Requires design and audit |
WebAssembly as a target format makes it possible to write contracts in several languages and execute them with predictable performance — this removes the dependency on a single development tool.
Which of these your network needs depends on the load profile. Describe the task, and we will come back with an estimate and a plan.
How we design and implement a virtual machine: stages of engineering work
Designing a custom blockchain virtual machine begins not with code, but with analyzing which operations the network must execute cheaply and predictably.
If this step is skipped, at the load stage it turns out that the gas model does not protect against overload, and the state grows faster than nodes can synchronize it.
That is why we fix the requirements for execution, storage, and consensus before the first line of the specification.
- Blockchain requirements audit. We analyze the scenarios: which transactions prevail, whether call privacy is needed, how execution cost is calculated, what limits exist on state size and throughput. The output is an execution model and a list of constraints that the architecture depends on.
- Virtual machine design. We define the instruction set, memory model, bytecode format, and deterministic execution rules. We separately work through compatibility with existing contracts if migration of already deployed logic is mandatory.
- Core and runtime implementation. We write an interpreter or compiler, embed resource accounting, and catch nondeterminism at the test level. Every instruction is covered by checks for identical results across all nodes.
- Node assembly and integration. We connect the machine to state storage, the mempool, and the agreement mechanism. We configure metrics: block execution time, rollback depth, behavior under peak load.
- Testing and audit. We run failure scenarios, check gas edge cases, and reproduce discrepancies between nodes. An external audit closes the risks in the execution model and error handling.
- Blockchain infrastructure deployment. We deploy the network, configure monitoring and update rules, and practice the procedure for rolling back to the previous version without losing state.
- Blockchain solution handover. We deliver the instruction specification, state schemas, node configurations, and update regulations — the client's team runs the system independently.
Each stage ends with an artifact that can be verified: the execution model, bytecode specification, test suite, network configurations. This makes it possible to track progress by facts, not by reports.
Describe the task — we will come back with an estimate and a stage-by-stage plan.
How does a custom virtual machine differ from off-the-shelf solutions and when should you choose it?
A custom blockchain virtual machine is a smart contract execution environment designed for a specific task rather than taken from a public network. An off-the-shelf network gives you a fast start: deploy a contract, connect a wallet, get a working product in a matter of weeks.
But along with that, you accept someone else's rules — the gas model, the set of supported operations, the protocol upgrade procedure, and the community's priorities, which have nothing to do with your task.
Forking open-source code looks like a compromise, but it is a compromise with obligations. You inherit someone else's architecture in its entirety, including the decisions you don't need, and then you drag them along in every update.
Any protocol change turns into manually porting edits on top of your branch: the further you go, the more expensive synchronization becomes, and compatibility with external tools gradually diverges.
Your own virtual machine flips the logic: first the execution model is formulated for your scenario, then the environment is written for it. If transactions must fit within a predictable cost, you build that into the resource computation rules.
If you need specific data types or protocol-level checks, they become part of the machine rather than a workaround contract. The pace of change stops depending on someone else's release schedule.
The price of this is responsibility for the entire stack: consensus, state, developer tools, audit.
That is why a custom machine is chosen when the execution logic itself is the product, or when the requirements for performance, privacy, and control over the rules don't fit someone else's model.
In all other cases, an off-the-shelf network or a carefully constrained fork will deliver results faster and with a lower cost of ownership.
Case study: how a custom virtual machine eliminated overloads and reduced the failure rate
The client came with a network on a forked public platform: their own calculation logic, but execution on someone else's virtual machine.
At peak loads, the validator pool became overloaded: the transaction queue grew faster than blocks could be confirmed, some operations dropped out on timeout, and fees spiked so much that the cost of an operation could not be predicted. Recurring transaction failures hurt user trust more than the latency itself.
What was changed
Our engineers designed a custom virtual machine for the client's specific calculation model: they removed the universal abstractions that were not used and replaced them with direct operations on state.
The gas model was rebuilt so that the cost of an operation is calculated based on the resources actually consumed, rather than an averaged profile.
Hot execution paths were separated out, and a deterministic state check was added before and after a block — a discrepancy is caught at the validation stage, not after confirmation.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Transaction failure rate at peak | 6-8% | below 0.5% |
| Block confirmation time | unstable, grew with load | stable, variance within 15% |
| Throughput | hit the platform ceiling | increased 3.5x |
| State size | grew uncontrolled | halved by pruning unused branches |
Confirmation time variance is the key metric for the client: while it fluctuated, no service on the network could give the user an honest forecast.
After implementation, the confirmation window became predictable, and the client's team was able to roll out services it had not previously dared to launch.
The experience of developing a custom network showed: the main savings are not in execution speed, but in the fact that failure is shifted to the validation stage, where it is cheap.
We built a load-testing rig reproducing the client's peak scenarios and ran several iterations on it before rolling out to the main network.
Ethereum Virtual Machine remained the reference point for tool compatibility — this way the client's team kept its familiar development and debugging tools.
Doubts before starting: compatibility, migration, rollback, and access
Virtual machine compatibility with already running contracts is the first question raised at the start.
If the network evolves from an existing one, we preserve the previous computation model and add new capabilities as a separate set of instructions so that old contracts execute without rewriting.
If the network is built from scratch, we fix the bytecode format and gas rules in advance — then migration to a new blockchain network comes down to transferring state and redeploying contracts, rather than rewriting logic.
Rollback of changes in a blockchain is a topic where it is important to separate levels.
Data written to a block is immutable, so rollback is designed at the governance level: a virtual machine update goes through versioning, a new version is activated on a schedule or by vote, and the previous one remains available for reading history. An error in execution rules is fixed by releasing the next version, not by rewriting the past.
What happens to contracts and data when the virtual machine is updated?
We fix the execution version at the moment a contract is deployed. An update adds a new version without affecting already recorded state: old contracts continue to run by their own rules, new ones by the current rules. Before activation, we run both versions on a copy of the network and compare computation results.
What if we already have our own node infrastructure? We deploy the network on your capacity or in an isolated environment, and describe access and blockchain infrastructure management through roles: who releases versions, who votes for activation, who only reads state.
Administrator keys are stored in a hardware module or a multi-party signature scheme — there is no single-party access to network management.
How are rights transferred after handover? The source code, deployment scripts, and access are transferred to you; our team can remain on support, but does not retain control.
The customer receives:
- a specification of the bytecode format and gas computation rules;
- a virtual machine repository with version compatibility tests;
- a state migration and contract deployment scheme;
- a role matrix and access management policy;
- a procedure for releasing and activating new versions with a rollback plan;
- blockchain solution documentation for your engineers;
- a regulation for node monitoring and response to computation discrepancies.
Describe your task — we will come back with an estimate and a work plan.