Enhanced Execution

Orbs is set up as a separate decentralized execution layer operating between existing L1/L2 solutions and the application layer. Orbs enhances the capabilities of existing EVM and TON smart contracts opening up a whole new spectrum of possibilities for Web 3.0, DeFi, NFTs and GameFi.

Limitations of Smart Contracts

Decentralized apps running over L1 blockchains rely on smart contracts to implement their backend logic. Smart contracts are indeed decentralized and secure, but suffer from many inherent limitations due to the sandboxed design of the L1 security model.

  • Contracts cannot access data outside the chain Known as the "oracle problem", smart contracts are unable to query external data that isn't stored on the chain they're implemented on. Examples of interesting external data sources include a market price feed for DeFi apps and accessing platforms like social networks like Twitter and Telegram.

  • Contracts cannot trigger future actions Smart contracts react to user transactions and cannot trigger future actions based on arbitrary conditions. Consider a DeFi position that needs to implement stop-loss or protect a user's loan against liquidation. Triggers include scheduled recurring operations, events/logs/messages generated by smart contracts, state changes and external triggers from oracle sources.

  • Contracts cannot be implemented in any language On the EVM, smart contracts are implemented in Solidity. On TON, they are implemented in FunC. These languages are carefully designed to be deterministic and obey the limits of the VM. Popular productive languages which include JavaScript, Python, Go and Rust are not supported and cannot be used by dapp developers.

  • Contracts cannot access historic data Due to the nature of blockchain, smart contracts can only read data from the head - the state according to the latest block. Logic that is based on historic data, like calculating votes based on token holdings on a set past date is impossible to implement.

  • Contracts can only access limited API API that is available to smart contract developers is limited by design and includes basic operations like crypto primitives and latest block time. When a developer requires access to rich new API, such as a different signature scheme, a complex native algorithm or an unsupported math operation, they would not have the freedom to pick any library and use it.

  • Contracts are limited in their access to storage and compute resources Even with the latest scaling solutions, smart contracts are still expensive to run in Web 2.0 terms. Smart contracts are not able to implement CPU-hungry operations like an AI neural network or access or analyze big data.

A Decentralized Solution

DeFi, Web 3.0 protocols and dapps are becoming more and more complex, while smart contracts are still inherently limited by design. This means that many DeFi and Web 3.0 projects still rely on centralized backend solutions.

It is not difficult to explain why centralized backend infrastructure is not optimal for DeFi and Web 3.0 projects, as it contradicts the trustless ideal of the industry. Centralization poses security and robustness risks due to the existence of a single point of failure. Centralized infrastructure exposes project participants to malicious behavior, increases liability and is usually expensive and difficult to maintain.

The Orbs Network solves this pain by operating as a decentralized serverless cloud, allowing developers to extend smart contracts with L3 decentralized backend services. These are deployed to be executed by Orbs PoS validators (Guardians) and relieve projects of the need to rely on centralized backend solutions.

The Orbs protocol provides two different execution services:

  • Orbs Lambda Event driven, serverless and decentralized computing solution, similar in concept to AWS Lambda - but decentralized. Read more

  • Orbs VM Dedicated decentralized virtual machine based on Docker containers, similar in concept to AWS EC2 - but decentralized. Read more

Last updated