Skip to main content
This section provides an overview of the complete Stoffel system architecture and how the various components interact.

​
Overall System Design

Campaign-style Stoffel architecture diagram showing developer application code, build artifacts, coordinator-managed execution, VM parties, and authorized outputs. The same .stflb artifact connects the application-facing build path to the runtime party mesh. App code prepares protected inputs, the coordinator manages lifecycle and IO routing, and VM parties compute over shares.

​
Component Interactions

​
Development Workflow

  1. Project Creation: Stoffel CLI creates project structure with templates
  2. Code Writing: Developers write StoffelLang programs with MPC primitives
  3. Compilation: StoffelLang compiler generates optimized VM bytecode
  4. Testing: Local VM execution for development and testing
  5. Deployment: MPC network deployment with protocol integration

​
Runtime Execution

  1. Program Loading: Stoffel VM loads compiled bytecode
  2. Secret Sharing: Input data is secret-shared across MPC nodes
  3. Secure Computation: VM executes with MPC protocol integration
  4. Result Reconstruction: Output is reconstructed from secret shares

​
Data Flow

For the trust boundaries between the app, coordinator, and MPC parties, see the MPC Integration runtime diagram.

​
Clear Data Path

  • Public inputs and configuration data
  • Direct VM register operations
  • No cryptographic overhead
  • Immediate availability across all nodes

​
Secret Data Path

  • Private inputs requiring protection
  • Automatic secret sharing on input
  • MPC protocol operations during computation
  • Selective reveal for output reconstruction

​
Security Architecture

​
Isolation Boundaries

  • Process Isolation: Each MPC node runs in isolated environment
  • Memory Protection: Clear and secret data separation
  • Network Security: Deployments must authenticate party and client identities and protect confidential traffic
  • Access Control: Role-based access to computation resources

​
Trust Model

  • Backend-specific thresholds: HoneyBadgerMPC deployments require n >= 4t+1; AVSS requires n >= 3t+1
  • Backend-specific adversaries: HoneyBadgerMPC targets a static active adversary. AVSS checks shares against public commitments, but its integrated multiplication path inherits a static passive preprocessing limitation unless triples are independently validated
  • Conditional liveness: Asynchronous safety does not guarantee that every run or preprocessing attempt completes against every allowed fault
  • Explicit output boundary: Inputs and intermediate values stay shared unless the program opens them or sends output shares to an authorized client
For the phase-by-phase model and deployment assumptions, see Security and fault model.

​
Scalability Design

​
Horizontal Scaling

  • Committee Sizing: Select a backend-valid party count before execution; changing the committee requires an explicit secure resharing or transfer design
  • Load Distribution: Computation workload balancing
  • Geographic Distribution: Global node deployment support

​
Vertical Scaling

  • Resource Optimization: Efficient CPU and memory usage
  • Parallel Execution: Multi-threaded computation where possible
  • Caching Strategies: Optimized data and computation caching

​
Integration Points

​
External Systems

  • Database Integration: Secure querying of external databases
  • API Integration: RESTful APIs for system interaction
  • Blockchain Integration: Smart contract integration for verification

​
Development Tools

  • IDE Support: Language server protocol integration
  • Debugging Tools: Comprehensive debugging and profiling
  • Testing Frameworks: Specialized testing for MPC applications
This architecture enables secure, scalable, and developer-friendly multi-party computation while maintaining strong security guarantees.