Epic: Smart Contract Capability #59
Description
Status: Future Work (Not Active)
This is a long-term roadmap item for BitQuan's evolution.
Current Status: ON HOLD - waiting for:
- v1.0.0 mainnet stable (6+ months runtime)
- Security audits complete (x2 minimum)
- P0/P1 tasks finished (wallet encryption, TLS, JWT)
- Issue Epic: State Management & Pruning #60 (State Pruning) complete and deployed
Timeline: Earliest start date: 2027 Q1 (depends on prerequisites)
Design Philosophy:
- Conservative WASM implementation (not EVM-compatible)
- Strict gas metering (no infinite loops)
- Minimal host functions (no network/file access)
- Storage rent to prevent state bloat
- Account model for contracts, UTXO for transfers (hybrid)
Contribute:
- Discuss design tradeoffs in comments
- Research WASM implementations (Polkadot, Near, Cosmos CosmWasm)
- Study gas metering strategies
- Write security analysis of WASM sandboxing
DO NOT: Start implementation yet - premature optimization kills projects.
Research Notes
Implementations to Study:
- Polkadot (parity-wasm, wasmi)
- Conservative approach, proven security
- Near Protocol (wasmer)
- Account model, storage rent mechanism
- Cosmos CosmWasm (wasmer)
- Module system, gas metering
Design Decisions Needed:
| Decision | Options | Recommendation |
|---|---|---|
| WASM Runtime | wasmer vs wasmtime | wasmer (Near/Cosmos proven) |
| Transaction Model | Pure account vs hybrid UTXO+Account | Hybrid (UTXO for transfers, Account for contracts) |
| Gas Token | Separate vs native BQ | Native BQ (simplicity) |
| Gas Price | Fixed vs auction | Fixed (avoid complexity) |
| Contract Size Limit | 64KB / 128KB / 256KB | 128KB (balance size vs capability) |
| Storage Model | Pay-once vs rent | Rent per epoch (prevent bloat) |
Critical Security Concerns:
- Gas metering must count EVERY instruction (no bypasses)
- Sandbox must prevent file/network access (use seccomp/pledge)
- Reentrancy attacks (need call stack depth limit)
- Integer overflow in gas calculations
- Determinism (ban floating point, randomness without VRF)
Open Questions:
- How to handle contract upgrades?
- Immutable contracts vs proxy pattern?
- Cross-contract calls?
- Synchronous (simple) vs async (complex)?
- Gas model for storage?
- Charge per byte + per epoch retention?
- Contract verification?
- Optional source code upload for transparency?
Success Criteria:
- Deploy simple contract (counter, token)
- Gas metering kills infinite loop in under 100ms
- Sandbox audit: zero file/network access vectors
- Fuzzing: 500+ targets, 1,000+ hours, zero crashes
- External audit: 0 critical, 0 high findings
Contributors: Add links, papers, or ideas below
Original Task List
Goal: Enable BitQuan to be programmable beyond simple value transfers, leveraging WebAssembly (WASM).
Core Concept: Integrate a WebAssembly runtime into the node application.
Tech Stack: wasmer or wasmtime (Rust Crate)
Task List (to break into separate issues):
- Integrate WASM runtime by adding wasmer dependency and initializing instance in crates/consensus.
- Define host functions (APIs) for WASM to interact with the blockchain:
- host_get_balance(address)
- host_transfer(to, amount)
- host_get_storage(key) / host_set_storage(key, value)
- Implement gas metering—count WASM instructions and kill execution if quota is exceeded (handles infinite loops and seizes gas).
- Add new transaction types: Transaction::DeployContract and Transaction:: CallContract.
- Conduct security sandbox audit to ensure WASM cannot access file system or node network.