Solana validators switched consensus protocols on October 21, 2026, and operators had to run an Agave-based client to complete the change, a constraint with no direct equivalent among EVM-compatible nodes, where operators choose among several interchangeable clients. The Alpenglow upgrade replaced TowerBFT with a voting layer called Votor, and the Solana Foundation reported Firedancer and Frankendancer were not supported during the migration.
The feature gate activated at the start of epoch 1064, near 13:36 UTC, while TowerBFT kept running for the first 5,000 slots, about 18 minutes, and slot 459,652,999 became the Alpenglow genesis block after votes from 446 of the network’s 654 validators. Alpenglow consensus took over from slot 459,653,000, and the protocol targets finality of roughly 150 milliseconds, down from 12.8 seconds.
Validators also needed at least 0.8 SOL above the rent-exempt minimum in the vote account to pay the Validator Admission Ticket fee, which the network charges at the start of each epoch. Operators of EVM-compatible nodes face a different structure: Ethereum offers five execution clients (Besu, Erigon, Geth, Nethermind and Reth) and five consensus clients (Lighthouse, Lodestar, Nimbus, Prysm and Teku), and its documentation recommends a minority client to protect client diversity.
Alpenglow changed the data read by RPC providers and indexers, because vote transactions no longer appear in blocks, so transaction counts and TPS dashboards dropped without a fall in network activity, and the confirmed and finalized commitment levels describe the same state.
How EVM-Compatible Nodes Operate
The Ethereum Virtual Machine is a decentralized virtual environment for executing code consistently across every Ethereum node. It runs as a stack machine with a depth of 1,024 items, and compiled smart contract bytecode executes as opcodes. Each execution client includes an EVM implementation, so EVM-compatible nodes on other networks typically reuse the same bytecode semantics and expose the standard JSON-RPC interface.
Since The Merge, an Ethereum node needs two programs: an execution layer client and a consensus layer client. They communicate through the authenticated Engine API, which relies on a shared jwtsecret file, and the execution client serves JSON-RPC on port 8545 by default. Ethereum clients listen on TCP port 30303 and use UDP port 30303 for peer discovery by default, which gives firewall rules for EVM-compatible nodes a common starting point.
Hardware guidance in EIP-7870 recommends a CPU with four or more cores, 32 GB of RAM, a 4 TB NVMe drive and 50 Mbit/s of download bandwidth for a full node. Validating EVM-compatible nodes need eight or more cores and 64 GB of RAM. Consumer hardware handles the workload, and the Ethereum documentation identifies disk space as the main bottleneck.
Disk use depends on the client: Geth and Nethermind need 500 GB or more with snap sync, a full archive on Reth needs 2.2 TB or more, and consensus clients add about 200 GB of beacon data to the storage budget.
EVM compatibility appears on non-EVM base layers, as Etherlink, an EVM-compatible network built on Tezos, requires a computer with 500 GB of disk space and at least 16 GB of RAM to run its Smart Rollup node on mainnet.
Runtime and Language Differences in Non-EVM Nodes
Non-EVM networks replace the EVM with their own runtime, so tooling built for EVM-compatible nodes does not transfer directly, and each runtime defines a distinct programming model. Solana programs run on the Solana Virtual Machine, and developers write them mostly in Rust, either with the Anchor framework or with native Rust. Sui contracts use the Move language and an object-centric model, in which transactions with non-overlapping inputs can run in parallel.
Cardano uses the extended UTxO model and stores application state in datums attached to unspent outputs, so validators hold no mutable storage. Aiken, currently the most popular Cardano contract language, compiles to Untyped Plutus Core. Developers who move from EVM-compatible nodes to Cardano replace account balances with discrete outputs and rebuild their transaction logic off-chain.
Tezos contracts compile to Michelson, a stack-based base language, from high-level languages including LIGO and SmartPy. Cardano documentation maps Hardhat to the Aiken CLI and Infura or Alchemy to query APIs, which shows how developer tooling changes with the network. Teams operating non-EVM nodes therefore learn client commands, key management and upgrade procedures for each chain separately.
Hardware Requirements Depend on the Network
Anza’s Agave documentation recommends a Solana validator with 12 cores and 24 threads, 256 GB of RAM, and NVMe drives for accounts, ledger and snapshots sized at 1 TB, 1 TB and 500 GB. A staked node needs at least a 2 Gbit/s symmetric connection, and Anza recommends 10 Gbit/s of available bandwidth.
Anza advises against running validators inside Docker or behind NAT, requires a public IPv4 address, and warns of the greater operational expertise needed for cloud deployments. Ethereum clients, by comparison, run on laptops, servers and single-board computers.
Sui suggests a full node with eight physical cores, 128 GB of RAM and a 4 TB NVMe solid-state drive. Cardano lists a stake pool node with an x86 processor of two or more cores at 2 GHz, 24 GB of RAM in InMemory mode and 250 GB of storage, with 350 GB recommended for growth. The Cardano guidance also calls for one block producer and at least two relay nodes. Octez, the Tezos client, runs in rolling history mode on three CPU cores (arm64 or amd64), 8 GB of RAM plus 8 GB of swap, and a 100 GB SSD, and it stops when disk space runs out.
The figures contradict a common assumption: a Cardano or Tezos node needs far less disk space than an Ethereum full node. Node requirements track state size, throughput and synchronization design, so operators should verify the current documentation of each network before they provision servers. A sizing plan for EVM-compatible nodes starts from the Ethereum guidance, while each non-EVM network needs its own exercise with its own client, role and history mode.
Infrastructure Choices for Operators
Teams without in-house capacity can rely on node-as-a-service providers, which run EVM-compatible nodes and non-EVM nodes for developers and handle upgrades and scaling. Ethereum documentation names the trade-off: concentrating infrastructure with one provider conflicts with the goals of decentralized projects, and a large share of nodes already runs in the cloud.
Operators of non-EVM networks add one more check, because Solana’s Alpenglow migration showed how a single client family can become a client requirement for a protocol change.
Operators who plan multi-chain infrastructure should list, for each network, the supported clients, the upgrade calendar, the hardware tier and the contract language of the applications they serve. EVM-compatible nodes reduce the list to one toolchain, while non-EVM nodes add one toolchain per network.
FAQ
What are EVM-compatible nodes and which software do they run?
EVM-compatible nodes run client software that executes Ethereum Virtual Machine bytecode. An Ethereum node combines an execution layer client, which includes the EVM implementation and serves JSON-RPC on port 8545 by default, with a consensus layer client. Both programs communicate through the authenticated Engine API.
Do non-EVM nodes always need more powerful hardware?
No. Requirements depend on the network and the node role, not on EVM status. Ethereum full-node guidance calls for 32 GB of RAM and a 4 TB NVMe drive. A Solana validator needs 256 GB of RAM and a Sui full node needs 128 GB. A Cardano stake pool node needs 24 GB of RAM and 250 GB of storage, and a Tezos node runs on a 100 GB SSD with 8 GB of RAM plus 8 GB of swap.
Which smart contract languages and tools apply to non-EVM networks?
Solidity serves EVM networks, and each non-EVM network uses its own stack. Solana programs use Rust, often with the Anchor framework, and Sui uses Move. Cardano uses Aiken, which compiles to Untyped Plutus Core. Tezos compiles LIGO or SmartPy to Michelson. Ethereum tools have no direct counterpart in each network, and Cardano documentation maps Hardhat to the Aiken CLI.
What did the Alpenglow upgrade change for Solana node operators?
Solana replaced TowerBFT with the Votor voting layer at epoch 1064 on October 21, 2026. Validators needed version 4.3.2 of an Agave-based client, because Firedancer and Frankendancer were not supported for the migration. Each vote account also needed 0.8 SOL above the rent-exempt minimum to pay the Validator Admission Ticket fee. Vote transactions left blocks, so transaction counts in dashboards dropped.
Should a team self-host nodes or use a node-as-a-service provider?
Self-hosting gives full control over client versions and data but adds maintenance, hardware cost and upgrade work. A node-as-a-service provider handles upgrades and scaling, but it concentrates infrastructure with one vendor and conflicts with decentralization goals. Teams can compare supported clients, upgrade handling, history mode and hosting location for each network before they choose.
