Architecture and trade-offs

Why this architecture matters#

A long-running execution layer should not necessarily require every normal node to become an infinite archive server.

The node mainly needs to answer:

What is my current state?

What is my current head?

What should I execute next?

Can I retrieve old history if needed?

Can I verify what I retrieve?

If those properties hold, historical bytes do not necessarily need to stay on the fastest local disk forever.

That makes possible an architecture like:

active execution
→ local

recent history
→ local

old history
→ distributed storage

canonical ordering
→ blockchain

Each layer specializes.

Is the hybrid model safe?#

The answer depends on what we mean by safe.

Removing an old block from one node's local disk is not inherently unsafe.

The important properties are:

• the historical block remains available
• its expected identity is known
• retrieved bytes can be validated
• the canonical hash can be checked
• current execution state remains recoverable

Solizone EVM currently enforces the verification side through block validation and canonical hash checking.

But distributed historical availability is its own problem.

Production deployment still requires things such as:

• replication guarantees
• reliable network-level discovery
• multiple independent storage participants
• stronger crash-consistency guarantees

Those belong to future hardening work.

Does hybrid storage make Solizone EVM decentralized?#

Not by itself.

Distributed storage and execution decentralization are related, but they are not the same thing.

A decentralized execution layer requires multiple independent participants to be able to:

obtain canonical input
      ↓
execute independently
      ↓
derive the same state
      ↓
verify commitments

Hybrid storage helps by reducing the amount of local disk a normal participant may need.

That can lower the operational cost of running infrastructure.

But decentralization ultimately depends on:

• independent execution
• canonical ordering
• data availability
• verification
• consensus / finality
• multiple operators

Solizone EVM's architecture is being built so those pieces can remain separate.

Comparison with traditional blockchain nodes#

A traditional blockchain node often bundles several responsibilities together.

node
├── execution
├── consensus
├── state
├── block history
├── networking
└── storage

This can work well.

But it also means the node becomes responsible for an increasingly large amount of infrastructure.

Solizone EVM takes a more modular approach.

Solizone EVM
→ execution

Logos Storage
→ persistence

Logos blockchain
→ ordering / finality

The goal is not to eliminate node responsibility.

The goal is to make each responsibility explicit.

Full nodes vs archive-style nodes#

Not every blockchain participant needs the same historical access pattern.

Some users care mostly about:

current state
recent history
new blocks

Others need:

every historical block
historical analytics
old state queries

Those are different workloads.

Solizone EVM's hybrid model gives us room to eventually support both.

A normal execution node could keep a smaller active window.

An archive-oriented node could choose:

retention = much larger

or potentially retain everything locally.

The storage policy should match the role of the node.

Comparison with simple cloud storage#

Technically, Solizone EVM could upload old blocks into a normal cloud bucket.

That would solve part of the disk problem.

But it would also introduce an infrastructure dependency such as:

execution layer
      ↓
central cloud bucket

The direction of Solizone EVM is different.

It is being built around the Logos ecosystem, so Logos Storage provides a natural storage layer for the same ecosystem.

Content-addressed storage also gives us a useful property:

content
→ CID

instead of simply relying on:

some server
→ some filename

Comparison with modular blockchain architecture#

Solizone EVM fits naturally into the broader idea of modular blockchain systems.

Instead of asking one protocol component to handle everything:

execution
+
consensus
+
storage
+
data availability
+
historical serving

the architecture can be split.

execution
→ Solizone EVM

persistence
→ Logos Storage

ordering / consensus / finality
→ Logos blockchain

That lets the EVM layer evolve independently from the lower layers.