Predictable Fees: The Orbs Blockchain and Orbs Token are Making Transaction Fee Models Usable

Published in

The Orbs Blog

7 min readJun 12, 2018

This post explains the Orbs platform economy from the point of view of the ORBS token. It is based on the position paper, a long but very enlightening read. Please note that much of this material is a work in progress and subject to change in the coming months.

Introduction

Consumer apps have begun creating token economies in which the end-users, advertisers, and third-party providers all take part. Compared to fiat money (that is, government money— USD, EUR, etc.) tokens are borderless, faster to transact, and incur fewer fees. Also, by placing tokens on a decentralized blockchain, it becomes more difficult to attack the tokens ledger even if an attacker gains access to the company’s servers.

Transition to the blockchain is not without its own issues, though. As the largest blockchain with smart contracts, Ethereum would be an obvious choice for apps, but Ethereum suffers from unpredictable fees and unpredictable transaction execution times. The price of gas — the toll for transactions on the Ethereum network — can fluctuate greatly in conjunction with volatile prices of Ethereum. Both of these are unacceptable for decentralized apps wishing to perform multiple micro-transactions per second on behalf of their end-users.

The Orbs platform was created with the mission to allow established consumer brands create large-scale decentralized apps. It is designed to solve the aforementioned unpredictability and provide additional features. For a more thorough discussion see the position paper.

This post distinguishes between the Orbs platform, and the ORBS token (written in all caps) used for paying and receiving fees on the Orbs platform. Also whenever Amazon AWS is mentioned, it can be substituted for every other cloud provider — this is for convenience only.
The terms app, decentralized app (“DApp”) and consumer app are synonymous.

What is the Orbs platform?

The Orbs platform is a decentralized infrastructure (or as we say in the industry Infrastructure-as-a-Service — “IaaS”). It is composed of a set of independent nodes, each running the Orbs software stack of micro-services. A node is composed of one or more machines, whatever number is necessary to provide a committed level of service.

Note the distinction between decentralized and distributed.
A distributed system has multiple physical or virtual machines but is governed by a single entity that can manipulate its data (“source of truth”) at will.
A decentralized system is also distributed but is not governed by a single entity; rather its control is fragmented between several parties such that (ideally) no single party can manipulate its data. Instead, a consensus must be reached between all parties as to what is the correct “source of truth” of the system so that its operation can continue.

Each node is operated by an organization, and all organizations that run nodes are collectively known as the Orbs Federation. This federation of nodes holds both the code and the data of the apps. This network is collectively governed by members of the Orbs Federation. When we say an app runs on top of the Orbs platform, this means its code lives in smart contracts and its data is stored on decentralized storage on top of the Orbs platform.

The organization that develops and deploys this app is responsible for paying subscription fees for the various services the app consumes, such as consensus, storage and execution of smart contracts.

Fees are paid to the Orbs platform and distributed to the federation members who run the nodes.

An app runs on a virtual chain — a subset of nodes that to the app seems like a completely separate blockchain, but still enjoys the greater security afforded by having the entire nodes network participate in consensus.

Using a virtual chain gives an app the option to choose which tier it would like to pay for (examples: SLA with up to 100 transactions/second, or 200, etc.).

An Orbs node would typically run on some cloud virtual machine, although it can also run on your laptop — it’s a matter of computing power and network speed. Running a node costs money (e.g. AWS subscription), so node operators receive fees in ORBS tokens as compensation for their expenses.

The same organization can both operate nodes and run an app on top of the platform — thus, it can both pay and also receive fees. In fact, this is the common case.

So, what is the ORBS token?

The ORBS token lives inside an Ethereum smart contract (the “token contract”) as a mapping of Ethereum addresses to ORBS tokens.

For example, if an app called myApp holds 1000 ORBS tokens, this is represented as balance[myApp_ethereum_address] = 1000; in the contract’s data.

So, the ORBS token is an Ethereum contract? What does Ethereum has to do with it?

Executing a contract on Ethereum has significant advantages, such as leveraging the existing integrations Ethereum already has to wallets, etc. It is also very secure, thanks for the large number of validators (miners).

Its disadvantages, such as unpredictable (and possibly high) fees, and long transaction confirmation time are not as pronounced, given the very low transaction rate (monthly subscription payments and distribution) and the relatively high value of every transaction.

So, can’t apps just launch their token economy over Ethereum? Why create the Orbs platform?

The motivation to create the Orbs platform appeared when one of our early partner apps tried to launch over Ethereum at the end of November 2017. At the same time, popular blockchain-based game CryptoKitties launched over Ethereum and promptly clogged the Ethereum network. Excess demand delayed transaction confirmations and drove up the price of gas.

For app developers, it presented a tremendous challenge to crafting a stable budget of fee expenses, since the prices of those expenses were subsequently shown to be unpredictable. When it comes to apps with a lot of users, it would be unbearable to sustain those kinds of delays — they are not interested in the complex technical reasons of why that would happen: End-users want fast and consistent response times.

Subscriptions: Where Orbs Differs

Contrary to Ethereum’s fee-per-transaction model, where each transaction execution incurs an immediate fee whose price fluctuates with the price of gas, the Orbs platform employs subscriptions, whose transaction rate is much lower (once per month) and more importantly, does not affect end-users (it is a transaction between the app and the Orbs Federation).

This works better for the Orbs Federation member (the validator) who receives fees. This makes its income predictable and consistent, in line with its predictable and consistent expenses, such as paying its own infrastructure subscriptions.

The concept of subscriptions emerged primarily from the need to provide fee predictability to decentralized apps. A subscription also enables programmable fee models per virtual chain, such as tiering — for example different SLAs to different apps, much in the same way as regular IaaS providers.

Instead of having an app pay a transaction fee immediately with every single transaction, the app pays at the beginning of the month a specific and known subscription fee, based on its SLA needs (e.g. up to 10 transactions per second, 100, etc.), then for the rest of the month it uses the Orbs platform services without having to deal with fees.

How do subscriptions work?

The Subscriptions smart contract over Ethereum holds subscription data (monthly fee, tier properties, etc.) for each virtual chain, and several utility methods for interacting with it.

To buy a subscription, the app invokes a pay subscription method on the Subscriptions smart contract over Ethereum. At that time, the amount paid is deducted from the dApp’s ORBS token balance on the ORBS token contract (also on Ethereum) and added to a subscription pool on the Subscriptions smart contract.

During that month, the subscribed app then uses such services as consensus nodes, decentralized storage, and execution of its own smart contracts over its virtual chain on the Orbs platform.

Before executing an app’s transaction, the platform checks the subscription data for that app which either approves or rejects the transaction based on the app’s subscription. This is a read-only check (using Ethereum’s call method). It only checks if a subscription is valid or not — it does not deduct any amount from any account. Also, reading the subscription data is cached on each node so in reality it is not necessary to actually access Ethereum for every single transaction.

At the end of the month, the collected fees in the pool are divided between Orbs Federation members (the node operators). This pays the cost of operating nodes, with some profit margin to incentivize perpetuation of this service.

ORBS token vs app tokens

You’re all probably waiting for this one.

We haven’t said anything yet about app-specific tokens. The ORBS token is the means of payment in the Orbs platform. An app running on top of the Orbs platform has a collection of smart contracts on top of the Orbs platform. These smart contracts that contain its logic may also manage a supply of its own app tokens, along with any other applicative data of its own internal state.

This is entirely unrelated to ORBS tokens (which again are managed in a smart contract on top of Ethereum). These internal app tokens would likely be used to transfer value between end-users of that app, but again this is entirely up to the app’s own discretion and the Orbs platform does not in any way interfere with management of that token.