Web3 Targets (EVM & Solana SBF)
Relevant source files
The following files were used as context for generating this wiki page:
Sploosh is designed as a dual-target programming language that enables developers to author code once and compile it to both web2 environments (Native, WASM) and web3 environments (EVM, Solana SBF). The system achieves this by enforcing on-chain specific safety rules and prohibitions at compile time, ensuring that code destined for a blockchain target is deterministic and secure.
The web3 integration is a first-class citizen of the language, providing Solidity-compatible storage layouts and built-in reentrancy guards. This architecture allows developers to ship on-chain protocols while benefiting from the memory safety and actor-based concurrency models provided by the core Sploosh language.
Sources: README.md:10-15, VISION.md:5-10, SECURITY.md:65-70
The On-chain Module System
The primary mechanism for defining web3-targeted code is the onchain mod block. This construct identifies a module that is subject to strict blockchain-specific prohibitions. Code within these modules cannot use non-deterministic features or host I/O operations.
Key Characteristics of On-chain Modules
- Prohibited Operations: No floating-point math methods, actors, file systems (fs), networking (net), database (db), or environment (env) access.
- Deterministic Execution: The compiler enforces these restrictions to ensure compatibility with blockchain runtimes.
- Target Backends: Supports compilation to EVM bytecode and Solana SBF (BPF).
Sources: VISION.md:78-83, SECURITY.md:70-75, crates/AGENTS.md:38-40
Logic Flow for Web3 Compilation
The following diagram illustrates how the Sploosh compiler distinguishes between standard and on-chain modules during the build process.
The compiler validates every onchain mod against specific restrictions before generating bytecode for the respective blockchain target.
Sources: README.md:120-128, VISION.md:78-83
On-chain Storage and Syntax
Sploosh provides a dedicated storage block within onchain mod to manage persistent state. By design, this layout is compatible with Solidity to facilitate easier migrations.
Storage and Event Components
| Component | Description | Syntax / Usage |
|---|---|---|
storage Block | Defines persistent on-chain state variables. | storage { balances: Map<Address, u256> } |
ctx::caller() | API to retrieve the address of the transaction sender. | let sender = ctx::caller(); |
emit | Keyword used for event emission. | emit Transfer { from: s, to: t, val: v }; |
chain::call | Low-level cross-contract call API. | chain::call (Solana CPI or EVM CALL) |
Sources: README.md:52-65, VISION.md:95-100, crates/sploosh-parser/src/lib.rs:434-450
On-chain Data Flow Example
The following sequence shows how a token transfer is handled within an onchain mod, involving storage access and event emission.
Sources: README.md:52-67
Web3 Security Model
The Sploosh security model for web3 targets focuses on "safe-by-default" behavior. This is primarily implemented through automated reentrancy protection and strict attribute enforcement.
Reentrancy Protection
Unlike Solidity, Sploosh implements a reentrancy guard by default for all public on-chain functions. A contract-wide boolean flag is set upon entry to any non-reentrant function.
- Default State: All
pubon-chain functions are guarded. - Opt-out: The
@reentrantattribute must be explicitly applied to allow reentrant calls.
Attributes and Keywords
The parser recognizes specific attributes and keywords tailored for blockchain development:
@payable: Opts a function into receiving native value (e.g., ETH or SOL).@reentrant: Explicitly disables the default reentrancy guard.u256: Native support for 256-bit integers, common in EVM environments.Address: A primitive type representing a blockchain account address.
Sources: VISION.md:90-105, SECURITY.md:65-75, crates/sploosh-parser/src/lib.rs:945-965
Cross-Chain Compatibility Strategy
Sploosh utilizes a single-syntax approach to handle the differing architectures of EVM and Solana (SVM).
Architecture Mapping
The compiler abstracts backend differences through the chain::call API, which lowers to the appropriate low-level instruction based on the target:
- EVM: Lowers to the
CALLinstruction. - Solana: Lowers to Cross-Program Invocation (CPI).
Target Support Table
| Target | Architecture | Format | Status |
|---|---|---|---|
| EVM | Account-based Storage (Solidity-style) | Bytecode | Specified |
| Solana | SBF (Solana Binary Format) | SBF / eBPF | Specified (Storage deferred) |
Sources: VISION.md:158-160, SECURITY.md:15-20, AGENTS.md:5-8
Summary
Web3 targets in Sploosh allow for high-level, safe contract development that compiles to both EVM and Solana SBF. By enforcing strict prohibitions on non-deterministic behavior and providing a safe-by-default reentrancy model, Sploosh aims to reduce common on-chain vulnerabilities. The language maintains compatibility with existing ecosystems through Solidity-compliant storage layouts and native u256/Address types, while allowing developers to use a familiar Rust-like syntax for smart contract logic.
Sources: VISION.md:120-130, README.md:145-150