Today, we are sending a ‘hello world’ message from hyperbeam, marking the inception of our work on the development of custom ao hyperbeam devices, focused on ethereum execution machines: EVM & RISC-V.
In this blog post we will be outlining the current traction on building these devices, the fundamental differences between EVM & RISC-V, the future of Ethereum, and how we see hyperbeam as a fit in it.
Ethereum’s Future Battle: EVM vs RISC-V
Let’s start this article by discussing the EVM and RISC-V technical difference, and what we may expect as the defacto ethereum execution machine in the future. We will try to not to focus too much on the technicalities of EVM and RISC-V given the blog post main focus: hyperbeam devices. A future article will be dedicated to dive deeper into the EVM vs RISC-V topic.
Ethereum Virtual Machine (EVM)
The EVM is a 256-bit stack-based virtual machine, with a maximum stack depth of 1024 elements. Each stack lot is 256-bit, a huge size to make it possible to fit ethereum’s cryptography such as elliptic curve and 256-bit hashes.
Being built under the principles of stack-based virtual machines, the EVM follows the conventional implicit stack for all operations: push the value, pop it for computation, then push back the result.
(source: https://www.evm.codes/)
The stack-based design of the EVM keeps it simple, sandboxed and deterministic. Ethereum’s design along the stack-designed EVM make it “easy” to understand and implement. However, this architecture as-is design has too many no-necessary additional instructions overhead due to the design (push/pop opcodes), expensive opcodes pricing and limiting the access to the registers: all intermediate values get shuffled around on the stack, and doing 256-bit math on a physical 64-bit CPU is computationally expensive. The EVM has no built-in concept of smaller 32- or 64-bit integers, for example, even adding two 64-bit numbers in EVM incurs the cost of 256-bit operations.
RISC-V (“risk-five”)
RISC-V uses a register-based architecture with a core register file. A standard RISC-V chip (like RV64I) gives you 31 general-purpose registers (x1-x31) for integer values, with x0 hardwired as zero. Instructions directly reference these registers when they need data.
Addition only needs a single instruction since the values are already in registers. In this register model, you access operands directly by name, which eliminates the stack’s push/pop overhead. The 64-bit word size in RV64 aligns perfectly with today’s hardware, making typical calculations more efficient. Ethereum’s 256-bit values would still require multiple 64-bit operations, but the key advantage is that RISC-V gives compilers much more freedom: they can keep frequently used values in registers, eliminate unnecessary loads, and optimize instruction sequences in ways that stack-based VMs simply cannot match.
# example of adding two numbers in RISC-V
# Load values into registers first
li x1, 42 # Load immediate value 42 into x1
li x2, 58 # Load immediate value 58 into x2
# Perform addition
add x3, x1, x2 # x3 = x1 + x2 (result: 100)
# If we want to store the result in memory
sw x3, 0(sp) # Store the result at the address in stack pointer On April 20th 2025, Vitalik Buterin posted “Long-term L1 execution layer proposal: replace the EVM with RISC-V” on Ethereum Magicians discussing the potential idea of replacing the EVM with RISC-V as the virtual machine language that smart contracts are written in.
Then 2 weeks later, on May 3rd 2025, Vitalik posted on his blog an article titled “Simplifying the L1” expanding more on the future of Ethereum in terms of scaling, protocol simplification and the progressive roadmap to replace the EVM with RISC-V
source(https://vitalik.eth)
In summary, EVM’s design is built specifically for Ethereum – straightforward, deterministic, but somewhat unusual: there are no 256-bit stack machines everywhere. On the other hand, RISC-V represents a general-purpose approach.
Ethereum VMs on HyperBEAM
Now that we have discussed briefly the differences between EVM and RISC-V, let’s start speaking about what we have done and plan to do on hyperbeam in the scope of ethereum’s execution machines.
Given the roadmap put by Vitalik in the “Simplifying the L1”, Ethereum is set on the rails to transition in phases from EVM with RISC-V implemented precompiles (phase 1) to defaulted smart contract compute in RISC-V (phase 4).
Given that, we have decided to build both an EVM device and a RISC-V device.
EVM Device
Starting with the current and defacto ethereum’s virtual machine (EVM), we have created a hyperbeam device that port Revm (Rust implementation of the Ethereum Virtual Machine) as a NIF (Native Implemented Function) in the hyperbeam codebase.
The evm device is designed to take an EVM appchain configuration (gas limit, chain id, chain name) , interpret a given signed raw transaction (Create or Call transaction kind), and update the appchain’s state given the results from the state transitions.
Therefore, this evm device not just offers EVM execution, but also statefulness of a given context. As an implementation example, we have deployed an appchain with a deployed Uniswap V2, another with zama fhevm smart contracts layer, and a basic appchain with basic Ethereum functionalities.
For example, with the Uniswap V2 appchain we deployed a wrapped native gas token, multicall33 contract, uniswap factory contract, router contract, and tested the contracts stack.
With zama’s fhevm, we deployed all of the zama L2 smart contracts: proxy contract, ACL, fhevm executor, KMS verifier, fhevm gaslimit, inputverifier, decryption oracle, we initialied all of the contracts then deployed and minted EncryptedERC20 token. Check the full set of tests here
The variety of appchains, horizontal scalability, cross-intropability amongst each other and with ao-compute will set HyperBEAM with these devices as the cosmos of meta-VM compute (soon ™).
RISC-V Device
To complete the full future vision of Ethereum’s compute layer, we have developed a custom fork of R55 (an Ethereum Execution Environment that seamlessly integrates RISCV smart contracts alongside traditional EVM smart contracts) to handle signed raw transaction input and return the resulted computed EVM db.
After getting R55 to work with the OOTB interpretation of signed raw transaction, we built on top of it a hyperbeam device offering RISC-V compatible Ethereum appchains.
For example, this erc20.rs Rust smart contract was deployed on a hb risc-v appchain: github.com/loadnetwork/r55
-module(riscv_em_nif_test).
-export([test/0]).
test() ->
io:format("~n__riscv_em_nif__~n"),
ChainId = list_to_binary("1"),
% Test hello function
try
HelloResult = riscv_em_nif:hello(),
io:format("~nhello() result: ~p~n", [HelloResult])
catch
Error:Reason:Stack ->
io:format("Error calling hello(): ~p:~p~n~p~n", [Error, Reason, Stack])
end,
% Test eval_riscv_bytecode function
try
% Mint riscv erc20
SignedRawTx = list_to_binary("f8ad80850af16b16008435a4e90094f6a171f57acac30c292e223ea8adbb28abd3e14d80b84440c10f19000000000000000000000000000000000000000000000000000000000000000b0000000000000000000000000000000000000000000000056bc75e2d63100000824a53a0eab71453afe2dd526d44a9a8d722c050ac411002f658fade8b270f4e7e36b6d6a02d309512fa3abc8563ba0800dc0bd3d33ae2fe42cf349a51006a30f285ed755b"),
LoadRiscvResult = riscv_em_nif:eval_riscv_bytecode(SignedRawTx, ChainId),
io:format("~neval_riscv_bytecode() result: ~p~n", [LoadRiscvResult])
catch
Error2:Reason2:Stack2 ->
io:format("Error calling eval_riscv_bytecode(): ~p:~p~n~p~n", [Error2, Reason2, Stack2])
end,
% Test Retrieve State
try
StateResult = riscv_em_nif:get_appchain_state(ChainId),
% {ok, Decoded} = hb_json:decode(StateResult),
io:format("~n chaind_id 1 appchain state: ~p~n", [StateResult])
catch
error:Error3:Stack3 ->
io:format("Error calling get_appchain_state(): ~p~n~p~n", [Error3, Stack3])
end,
ok.
(source: github.com/loadnetwork/load_hb)
Additional inputs
The Ethereum devices still in PoC stage, we are set to deliver MVPs before EoM. The Ethereum-HyperBEAM roadmap has just started, and we plan to not just device-encapsulate bytecode interpreters, but also the full stack to run an Ethereum/EVM full node (execution layer, consensus layer, light nodes, JSON-RPC, and more).
Regarding HyperBEAM node cloud hosting, we will leverage our partnership with Latitude.sh -the leading provider of baremetal servers as a service - in order to offer beefy hardware for our devices, and ao-compute. Learn more about our partnership with Latitude here
What’s next
We have been building closely using the Ethereum and EVM stack for the past 12+ months. We have gained an excellent understanding and experience building a data-centric EVM layer 1 that uses Arweave for data settlement and bidirectional communication.
With hyperbeam, we see a golden early-opportunity to adopt this new novel paradigm, leverage its technology, and hyperbeam-ethereum using our experience with both: Arweave and EVM building.
If you love hyperbeam, ethereum, meta-VMs, and cross-interopability, then stay tuned for what we are building and what we will deliver!