Orbs Network
  • Overview
    • What is Orbs?
    • Layer 3 Protocol
    • Running on EVM and TON
    • Enhanced Execution
    • L3 for Advanced Trading
    • Network Diagram
    • White Papers and Spec
  • Orbs Lambda
    • What is Orbs Lambda?
    • Network Diagram
    • Example Use Cases
    • Step by Step Overview
      • Development Requirements
      • Select Unique ID
      • Project Template
      • index.js Implementation
        • Execution Environment
        • Allowed Packages
        • Supported Networks
        • Execution Triggers
        • Sending Transactions
      • Testing Locally
      • Deploying to Production
      • Analyzing Execution
  • Orbs VM
    • What is Orbs VM?
    • Network Diagram
    • Example Use Cases
    • Step by Step Overview
      • Development Requirements
      • Select Unique ID
      • Docker Image Implementation
        • Execution Environment
        • Working Directory
        • Entry Point
        • Health Check
        • status.json
      • Testing Locally
      • Deploying to Production
      • Analyzing Execution
  • Powered by Orbs
    • Liquidity Hub
      • Integration Spec
    • Perpetual Hub
    • dTWAP Protocol
      • Integration Spec
      • Network Diagram
      • dTWAP Tutorial
      • FAQ
    • dLIMIT Protocol
      • Integration Spec
      • dLIMIT Tutorial
      • FAQ
  • Community Projects
    • Notification Protocol
      • Integrate a New Project
      • Network Diagram
    • TON Access
      • Network Diagram
    • TON Vote
Powered by GitBook
On this page
  • CPU architecture
  • Memory
  • Persistent disk storage
  • CPU load
  • Communication and ports
  • Standard output and logs
  • Privacy and secrets
  1. Orbs VM
  2. Step by Step Overview
  3. Docker Image Implementation

Execution Environment

PreviousDocker Image ImplementationNextWorking Directory

Last updated 2 years ago

CPU architecture

The official CPU architecture supported by the protocol is x86_64 since network validators run cloud-compatible machines (normally Linux, but this is not required). To make sure your image supports this architecture, it should support the amd64 variant. If you want to keep image size down, it's ok to support this architecture only.

Memory

A running docker image should not consume more than 500MB of RAM. Consuming too much memory for sustained durations will put the service at risk of termination and non execution.

The service may naturally keep variables in memory to maintain its internal state. Regard this memory as a nice-to-have cache only, meaning the service may be restarted from scratch without warning and lose all of its memory contents.

Persistent disk storage

A service is allowed to use persistent disk storage for data. This storage is not intended for big data and should be limited to 1GB of space per node (the distributed storage is then 1GB multiplied by the number of nodes running the container which can be dozens).

You should be aware that although most validator nodes have been quite stable since mainnet launch in 2019, validators may change, decide to leave the network and others may come in their place. Any data stored on a specific node may be lost. By continuously synchronizing important data across all validator nodes, there's strong certainty that this data would not be lost.

If you need a dedicated storage solution, there are quite a few decentralized storage solutions available in the industry. Small amounts of data with extremely high availability and robustness can be stored on-chain on smart contracts in networks like Polygon and Avalanche. Large amounts of data can be stored on decentralized services like and (4.1.7). An overview of available industry storage solutions is available .

CPU load

Orbs VM is not designed for computationally intensive actions. Most services are . If your business logic is CPU-bound, Orbs VM may not be the right solution for you. Containers that consume excessive CPU for long durations of time (over 20% of an average cloud core) are at risk of termination and non execution.

It is a good practice to spread CPU consumption over time. It is also a good practice to spread intense I/O operations over time, for example avoiding heavy reading and writing to disk for long periods of time.

Communication and ports

Containers are able to listen for incoming connections and make outgoing network requests. Port mapping for your container is specified during deployment.

Standard output and logs

Privacy and secrets

Much like smart contracts on-chain, Orbs VM is a decentralized protocol running on public and open infrastructure. This means that the source code of your service is generally expected to be open and all data retained by the service is publicly available to any community auditor. Do not store any private information or secrets that you would not otherwise store in a smart contract.

A container may output logs to standard output (stdout). A recent extract of these logs is available for analysis by visiting the network . Be aware that these logs are publicly accessible to anyone.

IPFS
TON Storage
here
I/O-bound
status page