HyperBEAM Devices

HyperBEAM devices are the modular building blocks that power the AO Computer. Think of them as specialized engines or services that can be plugged into the AO framework to provide specific computational capabilities. This modularity is key to AO's flexibility, extensibility, and ability to evolve with new technologies.

Understanding the Device Architecture

What Are Devices?

In AO-Core and HyperBEAM, Devices are modular components responsible for processing and interpreting Messages. They define the specific logic for how computations are performed, data is handled, or interactions occur within the AO ecosystem.

Each device is essentially an Erlang module that implements a specific interface, allowing it to:

Define computation logic - Dictate how message instructions are executed
Enable specialization - Allow nodes to focus on specific computational tasks
Promote modularity - Add new functionality without altering the core protocol
Distribute workload - Handle different parts of complex tasks in parallel

HyperBEAM Device Architecture:

HTTP Request
     ↓
HyperBEAM Router
     ↓
Device Selection
     ↓
┌─────────────────────────────────────────┐
│ Device Types:                           │
│ • [email protected]  → Process State Mgmt    │
│ • [email protected]     → Lua Script Execution │
│ • [email protected]   → WebAssembly Execution│
│ • [email protected]     → JSON Processing      │
└─────────────────────────────────────────┘
     ↓
Processing Results
     ↓
HTTP Response

Device Ecosystem:
┌─────────────────────────────────────────┐
│ • Security Devices (authentication)     │
│ • Utility Devices (routing, caching)   │
│ • Custom Devices (domain-specific)     │
│ • Communication Devices (relays)       │
│ • Storage Devices (state management)   │
└─────────────────────────────────────────┘

This modular architecture allows HyperBEAM to handle diverse computational tasks by routing requests to specialized devices, each optimized for specific types of processing.

Device Naming and Versioning

Devices follow a consistent naming convention that makes them easy to identify and use:

Format: ~name@version or dev_name (for internal devices)

Examples:

[email protected] - Primary process management device
[email protected] - Lua 5.3 execution device
[email protected] - WebAssembly 64-bit execution device
dev_router - Internal routing device (development prefix)

The tilde (~) indicates a primary, user-facing device, while the dev_ prefix is used for internal or utility devices in the source code.

Versioning Strategy

Versioning indicates the specific interface and behavior of the device:

Semantic versioning - Major.minor.patch format
Backward compatibility - Breaking changes increment major version
Feature additions - New features increment minor version
Bug fixes - Patches increment patch version

Core HyperBEAM Devices

Process Management Devices

`[email protected]` - Process State Manager

The process device manages persistent, shared computational states similar to traditional smart contracts, but with greater flexibility.

# Access current process state
GET /[email protected]/now

# Get cached state (faster)
GET /[email protected]/compute

# Access specific state fields
GET /[email protected]/now/balance
GET /[email protected]/compute/users/USER_ADDRESS

Key Functions:

now - Calculates real-time process state by processing all messages
compute - Returns the latest known state without checking for new messages
State persistence - Automatic state snapshots to Arweave
Message ordering - Ensures deterministic state transitions

Use Cases:

Token contracts and DeFi applications
Voting and governance systems
Game state management
Decentralized databases

`[email protected]` - Message Scheduling

Handles the ordering and execution timing of messages within processes.

# Query scheduler status
GET /[email protected]/status

# Get message queue information
GET /[email protected]/queue/pending

Responsibilities:

Message ordering and consensus
Execution timing coordination
Load balancing across compute units
Fault tolerance and recovery

Execution Devices

`[email protected]` - Lua Script Execution

Executes Lua scripts for serverless functions and data processing.

# Simple calculation
GET /[email protected]&script=return 2 + 3 * 4/result

# With parameters
GET /[email protected]&script=return Args.name .. " is " .. Args.age .. " years old"&name="Alice"&age+integer=25/result

# Using modules
GET /[email protected]&module=MODULE_TX_ID&script=return math_utils.factorial(Args.n)&n+integer=5/result

Capabilities:

Full Lua 5.3 language support
Module loading from Arweave transactions
JSON processing and manipulation
String processing and regex
Mathematical computations
HTTP client functionality (via libraries)

Performance Characteristics:

Lightweight execution overhead
Fast startup time (no cold starts)
Memory efficient for small to medium computations
Excellent for data transformation and business logic

`[email protected]` - WebAssembly Execution

Executes WebAssembly code for high-performance computations written in languages like Rust, C++, Go, and others.

# Execute WASM module
GET /[email protected]&module=WASM_MODULE_TX_ID/function_name

# With parameters
GET /[email protected]&module=WASM_MODULE_TX_ID&arg1+integer=100&arg2="test"/compute

Advantages:

High performance - Near-native execution speed
Multiple languages - Support for Rust, C++, Go, AssemblyScript
Sandboxed execution - Secure isolated environment
Predictable performance - No garbage collection pauses

Use Cases:

Cryptographic operations (hashing, signatures, ZK proofs)
Image and video processing
Machine learning inference
Scientific computing
Game engines and simulations

Example WASM Module (Rust):

// Compile to WASM and deploy to Arweave
use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn fibonacci(n: u32) -> u32 {
    match n {
        0 | 1 => n,
        _ => fibonacci(n - 1) + fibonacci(n - 2),
    }
}

#[wasm_bindgen]
pub fn hash_data(data: &str) -> String {
    use sha2::{Sha256, Digest};
    let mut hasher = Sha256::new();
    hasher.update(data);
    format!("{:x}", hasher.finalize())
}

Data Processing Devices

`[email protected]` - JSON Manipulation

Provides JSON data structure access and manipulation capabilities.

# Format process state as JSON
GET /[email protected]/[email protected]

# Pretty-print JSON
GET /[email protected]/[email protected]&pretty=true

# Extract specific JSON fields
GET /[email protected]&data={"users":{"alice":{"balance":100}}}/users/alice/balance

Features:

JSON serialization and deserialization
Path-based field access
Pretty printing and formatting
Schema validation (when configured)
Type conversion and casting

`[email protected]` - Message Processing

The default device that resolves keys to their literal values within messages.

# Create temporary message with data
GET /[email protected]&greeting="Hello"&count+integer=42/count
# Response: 42

# Complex data structures
GET /[email protected]&config+map=host="localhost";port+integer=3000&items+list="a","b","c"/config/port
# Response: 3000

Type Casting Support:

+integer - Convert to integer
+float - Convert to floating point
+boolean - Convert to boolean
+list - Parse comma-separated values
+map - Parse key-value pairs
+binary - Treat as binary string (default)

Communication Devices

`[email protected]` - Message Relay

Forwards messages between AO nodes or to external HTTP endpoints.

# Relay GET request to external API
GET /[email protected]/call?method=GET&path=https://api.example.com/data

# Relay POST with data
POST /[email protected]/call?method=POST&path=https://webhook.site/your-webhook
Content-Type: application/json

{"message": "Hello from AO"}

# Relay to another AO process
GET /[email protected]/process/TARGET_PROCESS_ID?action=GetBalance&user=ALICE

Use Cases:

Cross-chain bridges - Connect to other blockchain networks
External API integration - Fetch data from Web2 services
Inter-process communication - Route messages between AO processes
Webhook delivery - Send notifications to external services

Security and Verification Devices

`[email protected]` - Secure Enclave Verification

Handles Trusted Execution Environment (TEE) attestation and verification.

# Get TEE attestation report
GET /[email protected]/attestation

# Verify node is running in genuine TEE
GET /[email protected]/verify

Security Features:

AMD SEV-SNP attestation
Intel TXT support
Hardware security verification
Remote attestation protocols
Cryptographic proof generation

`dev_codec_httpsig` - HTTP Signature Processing

Manages HTTP message signing and verification for authentication.

Capabilities:

HTTP signature generation and verification
Multiple signature algorithms (RSA, ECDSA, EdDSA)
Request/response integrity verification
Authentication and authorization

Utility and System Devices

`[email protected]` - Node Configuration

Configures the HyperBEAM node itself including hardware specs, supported devices, and payment information.

# Get node capabilities
GET /[email protected]/capabilities

# Get supported devices
GET /[email protected]/devices

# Get node status
GET /[email protected]/status

Configuration Options:

Hardware specifications
Available compute resources
Supported device list
Payment and billing information
Network connectivity options

`dev_cron` - Task Scheduling

Coordinates scheduled task execution and workflow management.

Features:

Cron-like task scheduling
Recurring job management
Event-driven automation
Workflow orchestration

`dev_monitor` - System Monitoring

Monitors process activity, performance metrics, and system health.

Monitoring Capabilities:

Process execution metrics
Resource utilization tracking
Error rate monitoring
Performance benchmarking
Alert generation

Financial and Access Control Devices

`[email protected]` - Payment Processing

Manages metering, billing, and micropayments for node services.

# Check payment status
GET /[email protected]/balance/USER_ADDRESS

# Get pricing information
GET /[email protected]/pricing/compute

Payment Features:

Micropayment processing
Usage-based billing
Multi-token support
Payment channel management
Revenue sharing protocols

`[email protected]` - Access Control

Handles authorization and access control for protected resources.

Access Control Features:

Role-based access control (RBAC)
Attribute-based access control (ABAC)
Token-based authentication
Multi-signature authorization
Temporary access grants

Data Storage and Management

`[email protected]` - State Management

Applies state updates directly to processes, often used for data migration and management.

# Apply state patch to process
POST /[email protected]/apply
Content-Type: application/json
{
  "operation": "update",
  "path": "/users/alice/balance",
  "value": 1500
}

# Get patch history
GET /[email protected]/history

Patch Operations:

State updates and migrations
Data consistency maintenance
Version control for process state
Rollback and recovery operations

Advanced Device Concepts

Device Composition and Pipelines

Devices can be chained together to create sophisticated processing pipelines:

# Multi-device pipeline:
# 1. Get process state
# 2. Transform with Lua
# 3. Format as JSON
# 4. Apply template
GET /[email protected]/now/[email protected]&module=ANALYTICS_MODULE/calculateMetrics/[email protected]/[email protected]&type=dashboard

Device Specialization

Nodes can choose which devices to support, allowing for specialization:

Compute-Optimized Nodes:

Focus on [email protected] and [email protected] devices
High-performance processors and memory
Optimized for CPU-intensive workloads

Storage-Optimized Nodes:

Specialize in [email protected] and [email protected] devices
Large storage capacity and fast I/O
Optimized for state management and data persistence

Security-Focused Nodes:

Run [email protected] and security-related devices
Hardware security modules (HSMs)
Trusted Execution Environments (TEEs)

Custom Device Development

While HyperBEAM comes with a comprehensive set of built-in devices, you can create custom devices in Erlang to extend functionality for specialized use cases. This is an advanced topic that allows you to build domain-specific functionality tailored to your exact needs.

For detailed guidance on building custom devices, see the HyperBEAM Device Development Guideopen in new window.

Device Discovery and Routing

HyperBEAM automatically routes requests to the appropriate devices based on the URL path. You can discover available devices on any node:

# List all available devices
GET /[email protected]/devices

# Get information about a specific device
GET /[email protected]/device/[email protected]

Devices are automatically load-balanced across available instances, with HyperBEAM handling routing optimization internally.

Performance Considerations

Different devices have varying performance characteristics:

[email protected] - Fast startup, low resource usage, ideal for simple logic
[email protected] - Higher performance for complex computations
[email protected] - Use /compute for cached state, /now for real-time updates
[email protected] - Very lightweight for data serialization

Optimization Tips:

Use device pipelines to chain operations in a single request
Cache frequently accessed data at the application level
Choose the right device for your workload (Lua for simple logic, WASM for computation)

Extensible Device Ecosystem

The modular nature of HyperBEAM devices enables endless possibilities for expansion. The community and ecosystem are continuously developing new devices for:

Specialized Hardware - GPU computing, AI/ML acceleration, quantum computing
Domain-Specific Logic - DeFi protocols, scientific computing, media processing
Cross-Chain Integration - Bridges to other blockchain networks
Industry Solutions - Custom devices for specific business needs

This extensibility ensures HyperBEAM can adapt to new technologies and use cases without requiring changes to the core protocol.

Security Considerations

HyperBEAM devices run in isolated environments with built-in security features:

Sandboxing - Each device operates in its own isolated environment
Resource Limits - Automatic memory and execution time constraints
Verification - Device signatures and integrity checking
Access Control - Permission-based device access

Best Practices:

Always specify device versions (e.g., [email protected] not just ~lua)
Validate inputs when building applications that use devices
Use TEE-enabled nodes ([email protected]) for sensitive computations

Next Steps

Explore the broader HyperBEAM ecosystem:

Build Custom Devices: Device Development Guideopen in new window
Lua Programming: Lua Serverless Functions
Process Integration: AO Process Development
Production Deployment: Builder's Journey

Resources

HyperBEAM Device Documentation: Official Device Docsopen in new window
Erlang/OTP Documentation: Erlang Referenceopen in new window

Documentation

# HyperBEAM Devices

# Understanding the Device Architecture

# What Are Devices?

# Device Naming and Versioning

# Versioning Strategy

# Core HyperBEAM Devices

# Process Management Devices

# [email protected] - Process State Manager

# [email protected] - Message Scheduling

# Execution Devices

# [email protected] - Lua Script Execution

# [email protected] - WebAssembly Execution

# Data Processing Devices

# [email protected] - JSON Manipulation

# [email protected] - Message Processing

# Communication Devices

# [email protected] - Message Relay

# Security and Verification Devices

# [email protected] - Secure Enclave Verification

# dev_codec_httpsig - HTTP Signature Processing

# Utility and System Devices

# [email protected] - Node Configuration

# dev_cron - Task Scheduling

# dev_monitor - System Monitoring

# Financial and Access Control Devices

# [email protected] - Payment Processing

# [email protected] - Access Control

# Data Storage and Management

# [email protected] - State Management

# Advanced Device Concepts

# Device Composition and Pipelines

# Device Specialization

# Custom Device Development

# Device Discovery and Routing

# Performance Considerations

# Extensible Device Ecosystem

# Security Considerations

# Next Steps

# Resources

HyperBEAM Devices

Understanding the Device Architecture

What Are Devices?

Device Naming and Versioning

Versioning Strategy

Core HyperBEAM Devices

Process Management Devices

`[email protected]` - Process State Manager

`[email protected]` - Message Scheduling

Execution Devices

`[email protected]` - Lua Script Execution

`[email protected]` - WebAssembly Execution

Data Processing Devices

`[email protected]` - JSON Manipulation

`[email protected]` - Message Processing

Communication Devices

`[email protected]` - Message Relay

Security and Verification Devices

`[email protected]` - Secure Enclave Verification

`dev_codec_httpsig` - HTTP Signature Processing

Utility and System Devices

`[email protected]` - Node Configuration

`dev_cron` - Task Scheduling

`dev_monitor` - System Monitoring

Financial and Access Control Devices

`[email protected]` - Payment Processing

`[email protected]` - Access Control

Data Storage and Management

`[email protected]` - State Management

Advanced Device Concepts

Device Composition and Pipelines

Device Specialization

Custom Device Development

Device Discovery and Routing

Performance Considerations

Extensible Device Ecosystem

Security Considerations

Next Steps

Resources