load.network
  • Load Network
  • Quickstart
  • About Load Network
    • Overview
    • Network Releases Nomenclature
    • Load Network Alphanets
    • Key Features
    • ELI5
  • Using Load Network
    • Compatibility & Performance
    • Network configurations
    • Load Network Bundler
    • 0xbabe2: Large Data Uploads
    • Load Network Bundler Gateways
    • Load Network Precompiles
    • LN-Native JSON-RPC Methods
    • load:// Data Protocol
    • Self-Hosted RPC Proxies
      • Rust Proxy
      • JavaScript Proxy
    • Code & Integrations Examples
      • ethers (etherjs)
      • Deploying an ERC20 Token
  • load hyperbeam
    • About Load HyperBEAM
    • ~evm@1.0 device
  • ~kem@1.0 device
  • ~riscv-em@1.0 device
  • Load Network Cloud Platform
    • Cloud Platform (LNCP)
    • Load S3 Protocol
    • load0 data layer
  • Load Network for evm chains
    • Ledger Archiver (any chain)
    • Ledger Archivers: State Reconstruction
    • DA ExEx (Reth-only)
    • Deploying OP-Stack Rollups
  • Load Network ExEx
    • About ExExes
    • ExEx.rs
    • Load Network ExExes
      • Google BigQuery ETL
      • Borsh Serializer
      • Arweave Data Uploader
      • Load Network DA ExEx
      • Load Network WeaveDrive ExEx
  • Load Network Arweave Data Protocols
    • LN-ExEx Data Protocol
    • Load Network Precompiles Data Protocol
  • DA Integrations
    • LN-EigenDA Proxy Server
    • LN-Dymension: DA client for RollAP
Powered by GitBook
On this page
  • About
  • Technical Architecture
  • References
Export as PDF
  1. load hyperbeam

~evm@1.0 device

The first Revm EVM device on HyperBEAM

PreviousAbout Load HyperBEAMNext~kem@1.0 device

Last updated 1 day ago

About

The @evm1.0 device: an EVM bytecode emulator built on top of Revm (version ).

The device not only allows evaluation of bytecode (signed raw transactions) against a given state db, but also supports appchain creation, statefulness, EVM context customization (gas limit, chain id, contract size limit, etc.), and the elimination of the block gas limit by substituting it with a transaction-level gas limit.

This device is experimental, in PoC stage

Live demo at

Technical Architecture

eval_bytecode() takes 3 inputs, a signed raw transaction (N.B: chain id matters), a JSON-stringified state db and the output state path (here in this device it's in )

#[rustler::nif]
fn eval_bytecode(signed_raw_tx: String, state: String, cout_state_path: String) -> NifResult<String> {
    let state_option = if state.is_empty() { None } else { Some(state) };
    let evaluated_state: (String, String) = eval(signed_raw_tx, state_option, cout_state_path)?;
    Ok(evaluated_state.0)
}

#[rustler::nif]
fn get_appchain_state(chain_id: &str) -> NifResult<String> {
	let state = get_state(chain_id);
    Ok(state)
}

References

device source code:

hb device interface:

nif tests:

ao process example:

v22.0.1
ultraviolet.load.network
./appchains
native/load_revm_nif
dev_evm.erl
load_revm_nif_test.erl
evm-device.lua