3DPass Architecture Native vs WASM: A Complete Technical Breakdown

The 3DPass blockchain splits execution between a native Rust node binary handling networking, consensus, and CLI operations, and a WebAssembly (WASM) runtime containing all on-chain logic that executes deterministically inside a sandboxed VM across all validators.

3DPass is built on the Substrate framework, which enforces a strict separation between host-side infrastructure and runtime logic. Understanding the 3DPass architecture native vs WASM distinction is essential for validators, miners, and developers contributing to the consensus layer or runtime pallets.

Native (Host) Components

The native side runs as a standard Rust binary directly on the validator's operating system. It provides the execution environment that loads, upgrades, and interfaces with the WASM runtime.

Node Entry Point and CLI

The native node binary starts at nodes/poscan-consensus/src/main.rs, which initializes the command-line interface, telemetry, and networking stack. This entry point constructs the full node service, including the RPC server, peer-to-peer networking, and consensus engine plumbing required for the Proof of Scan (PoScan) algorithm.

Chain Specification and WASM Loading

The nodes/poscan-consensus/src/chain_spec.rs file bridges the native and WASM worlds. During genesis block construction, it loads the compiled WASM_BINARY constant and embeds it into the chain specification. This ensures the WASM runtime is available on-chain from block zero, allowing subsequent validators to fetch and execute the runtime without relying on local native code.

Runtime Version Reporting

For diagnostics and version synchronization, runtime/src/lib.rs exposes a native_version() function gated behind the std feature. When called from the native node, this reports the runtime version that matches the compiled WASM blob, ensuring the host environment and on-chain runtime remain in sync during upgrades.

WASM (On-Chain) Runtime

The WASM side contains all blockchain logic, including pallets, runtime APIs, weight calculations, and cryptographic algorithms. This code compiles to a WebAssembly binary and executes inside a sandboxed VM, guaranteeing deterministic state transitions across heterogeneous validator hardware.

Core Runtime Definition

The runtime/src/lib.rs file serves as the central runtime definition. It aggregates all FRAME pallets—such as pallet_poscan for the PoScan consensus—and configures the runtime version, block length limits, and transaction payment logic. A critical line in this file, #[cfg(feature = "std")] include!(concat!(env!("OUT_DIR"), "/wasm_binary.rs"));, pulls the generated WASM blob into the native build for testing purposes.

Build Process and Compilation

The transformation from Rust source to WASM binary occurs in runtime/build.rs. This build script invokes substrate-wasm-builder, which compiles the runtime targeting wasm32-unknown-unknown and embeds the resulting binary as the WASM_BINARY constant. Validators building from source automatically generate this artifact during the standard cargo build --release process.

Pallets and Custom Logic

All business logic resides in pallets under runtime/src/ and the pallets/ directory. For example, runtime/src/algo.rs implements the WASM-compatible object-hashing algorithm used by PoScan to generate grid hashes from 3D object data. The EVM pallet (pallets/evm) and precompiles (precompiles/*) extend the runtime with Ethereum compatibility, all executing within the WASM sandbox.

How Native and WASM Interact

The 3DPass architecture relies on a three-phase lifecycle that coordinates the native host with the WASM runtime:

1. Build time – Running cargo build --release compiles the native node binary while runtime/build.rs simultaneously invokes substrate-wasm-builder to generate the WASM runtime. The resulting blob is embedded as WASM_BINARY within the native binary.

2. Node startup – When the native node launches via nodes/poscan-consensus/src/main.rs, it reads the embedded WASM_BINARY through chain_spec.rs and stores it on-chain as part of the genesis configuration. This makes the runtime available to all network participants.

3. Block execution – During normal operation, validators load the stored WASM blob into their Wasm VM. Every block executes within this sandboxed environment, ensuring deterministic state transitions regardless of the validator's native operating system or architecture. The native side provides only host functions for I/O, networking, and consensus timing.

Building and Running the Components

To compile both the native node and WASM runtime from the 3DPass source:

# Install the required WASM target toolchain

rustup target add wasm32-unknown-unknown --toolchain nightly-2023-05-05

# Build the native node (automatically includes WASM binary)

cargo build --release

After building, the artifacts appear as:

• target/release/poscan-consensus – the native node binary
• target/release/wbuild/poscan-runtime/poscan_runtime.compact.wasm – the standalone WASM runtime

To start the native node with the embedded WASM runtime:

./target/release/poscan-consensus \
  --base-path ~/3dp-chain/ \
  --chain mainnetSpecRaw.json \
  --name MyNode \
  --validator \
  --telemetry-url "wss://submit.3dpass.network/submit 0" \
  --author <mining-address>

The node loads WASM_BINARY from the native binary and executes it within the Wasm VM for every block.

To verify version synchronization between native and WASM:

#[cfg(feature = "std")]
pub fn native_version() -> NativeVersion {
    NativeVersion {
        runtime_version: VERSION,
        can_author_with: Default::default(),
    }
}

Calling runtime::native_version() from the host confirms the native build matches the on-chain WASM runtime version.

Summary

• Native components run as a standard Rust binary and handle CLI parsing, networking, consensus engine plumbing, and RPC services via nodes/poscan-consensus/src/.
• WASM runtime contains all blockchain logic including FRAME pallets, PoScan algorithms, and EVM compatibility, compiled via runtime/build.rs and stored on-chain.
• Interaction model follows a three-phase lifecycle: build-time compilation embeds the WASM blob into the native binary, startup loads it into genesis, and execution runs every block inside the Wasm VM.
• Key files include nodes/poscan-consensus/src/chain_spec.rs for bridging environments, runtime/src/lib.rs for runtime definition, and runtime/src/algo.rs for WASM-compatible hashing.

Frequently Asked Questions

What is the difference between native and WASM execution in 3DPass?

Native execution runs compiled Rust code directly on the validator's operating system to handle networking, storage, and consensus timing. WASM execution runs the blockchain runtime inside a sandboxed WebAssembly virtual machine, ensuring that all state transitions are deterministic and identical across every node regardless of hardware or OS.

Where is the WASM runtime stored in the 3DPass network?

The WASM runtime is stored on-chain within the blockchain state itself. During genesis block initialization, the native node embeds the WASM_BINARY constant (compiled from runtime/src/lib.rs via runtime/build.rs) into the chain specification. Validators subsequently fetch this blob from the chain state and load it into their Wasm VM for block execution.

How do validators build both components from source?

Validators must first install the WebAssembly target using rustup target add wasm32-unknown-unknown --toolchain nightly-2023-05-05. Running cargo build --release from the repository root compiles the native node binary (target/release/poscan-consensus) while automatically invoking substrate-wasm-builder in runtime/build.rs to generate the WASM runtime blob.

Can the native node run without the WASM runtime?

No. While the native node can perform auxiliary functions like peer discovery and RPC serving, it cannot produce or validate blocks without the WASM runtime. The consensus logic, transaction validation, and state transition functions all reside in the WASM blob (runtime/src/lib.rs and associated pallets). The native side merely provides the host environment and I/O capabilities required by the Wasm VM.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}