PoS Under the Orbs Architecture

David Yakira is Orbs Head of Research. He is also a PhD candidate in the Technion (Israel Institute of Technology) under the supervision of Prof. Idit Keidar. His research focuses on the interplay between game theory and distributed systems.

This post is the second in my series about my latest focus in Orbs — the Proof-of-Stake ecosystem. If you haven’t read the first post — it is available here: How PoW and PoS Can Help Create Better Apps.

Subject of this post

After the general introduction given in the previous post, this post starts discussing the PoS architecture used in the Orbs platform. We’ll go over some of its different components and the relationships between them. The purpose of all this is to ultimately lead us to the rationale behind some of the design decisions.

Also, keep in mind that the currently implemented PoS architecture in V1 is just the first phase. We have more ideas we aim to propose to the community in the future regarding where to take the PoS design in the versions to come. Since I want to focus on rationale, I may mention ideas that don’t appear yet in V1. Please forgive me and refer to the specifications above if unsure whether something is just a planned idea or is a feature that is already implemented.

Platform design choices

I want to start by outlining some of the primary design choices of the Orbs platform in general. This can only make sense in light of the specific goal the platform is trying to achieve. Namely, allowing developers to create apps that provide guarantees to their users, like forkability and auditability discussed in detail in the previous post of this series.

Design choice 1: Proof-of-Stake

The first and most fundamental design choice we have made was that the Orbs platform will fall under the PoS umbrella. Our motivation was simple — we believe that in order to provide the forkability and auditability guarantees, permissionless-ness is essential — the Orbs network must remain inclusive (open) and enable new participants to join. Moreover, nodes need to be incentivized (economically) to follow the Orbs protocol which allows for the healthy operation of the platform. Specifically, the network was designed to decouple the nodes operating the network from the content they process.

While PoW has proven effective in both these aspects, it does not seem to fit Orbs’ mission of building a platform for consumer apps, at least not without an additional layer. And while alternative approaches (inspired by this paper and similar ideas) might come to fruition one day, we believe that at this time PoS designs have the best potential to suit our needs.

We believe that a platform based on PoS can be tuned to provide the required capacity a massive consumer app needs while offering a sufficient amount of “decentralization”. However, in considering a PoS design, it is essential to guarantee its correct execution. For instance, democratic elections might seem like a reasonable decision-making procedure, but only so long as everyone has the right to vote and vote counting is done correctly. This leads us to the second design choice.

Design choice 2: External oversight for staking

The second design choice we’ve made was to implement the Orbs staking mechanisms (see below for more details) over an external PoW blockchain — Ethereum — and not internally on the Orbs platform itself. We see a circular trust flaw in the majority of PoS implementations where validators are executing the mechanism for their own election. If we want the election process to be pure, and have a strong verifiable guarantee for its correctness, it is preferable to hold the process externally to the system. I will dedicate one of my future posts to this topic because it’s so important.

In other words, the Orbs staking mechanisms operate as a pure dApp on Ethereum. This use-case (namely, the Orbs staking mechanisms) is indeed a perfect match for Ethereum — it does not require high capacity since votes are infrequent, and having this mechanism externally verifiable is important to the success of the Orbs platform as it adds a high degree of trust. PoW, as we’ve seen in the previous post in the Bitcoin discussion, has many unique benefits but is only suitable for very specific use-cases. We feel this is one of them.

Ethereum, widely seen as a publicly available chain that provides objective consistency (meaning it allows syncing nodes to reach “the exact same conclusion as the rest of the network on the current state”, as defined by Vitalik in this post), is used for several strategic aspects of Orbs’ operation. Beyond overseeing Orbs staking mechanisms, Ethereum also holds the periodic network configurations (the list of Orbs’ network nodes), which helps to sync new nodes that join the network.

Note that staking on Ethereum means that the ORBS token must run on Ethereum. The ORBS token is defined as an ERC20 token. The specific details of its distribution are available here.

Design choice 3: Multiple archetypes

The third design choice made was to define two separate types of active participants in the network — Guardians and Validators, with different responsibilities and capabilities. Delegators are the third archetype. If you’re unfamiliar with these archetypes, a good introduction by Tal is also available here.

Validators. Validators are the network’s operators. They keep up-to-date replicas of Orbs’ virtual chains (see below for more details); propose, execute and confirm blocks; listen for incoming network requests and maintain their local pending transaction pools; reply to users’ queries; etc.

The network design must make sure Validators are honest, and since they are profit-driven entities, they must be (economically) incentivized to keep the platform secure. In many PoS architectures, incentivization is “soft” — meaning that validators, fearing from being voted out of power and missing out on token rewards, behave well. Orbs had been launched with a similar approach in mind, but we believe that “hard” incentives will be required as well. Hard incentives for Validators may include a requirement to lock ORBS tokens in a designated smart contract on Ethereum. If there’s an indication that a Validator committed a violation, locked tokens may be lost in accordance with the terms programmed into that contract. Locking is not currently implemented in V1 but is currently planned to be proposed to the protocol in the next versions.

Guardians. Guardians are meant to direct and oversee the Validators’ function and participate in platform decision making processes. Guardians represent the stakeholders via delegation of stake (we later elaborate on how delegation is done). Platform decisions include confirming protocol updates and instructing Validators to update their nodes, calibrating protocol parameters (such as rewards, etc.). Guardians serve as auditors of the platform and are incentivized to build tools to analyze Validators’ performance. They have the ability to vote out of power malfunctioning or misbehaving Validators in a controlled manner.

Delegators. Delegators are accounts that hold ORBS tokens and that have delegated their stake to a Guardian (see below for details on how delegation is done in practice). Stake delegation can be seen as a backup vote — a stakeholder chooses her Guardian of choice and appoints that Guardian as her delegate or representative (unlike EOS, one token can vote only for a single Guardian). The Guardian will then vote on her behalf. Guardians represent their Delegators in the decision making processes.

Design choice 4: Virtual chains and app isolation

The main topic of this document is the PoS architecture of the Orbs platform, and indeed, thus far, we have talked about one use of the ORBS token — staking. However, no discussion of the staking mechanisms is complete without referring to the primary use of the token. The ORBS token is the only means for paying subscription fees in order to deploy virtual chains (VCs), over which apps manage their backends. The specific fees for deploying VCs on the Orbs platform, which are designed to ensure stable and predictable fees, are laid out here.

VCs provide isolation between apps, particularly regarding governance, and an inherent form of (straightforward) sharding which allows infinite horizontal scalability since VCs are executed in parallel. For an in-depth discussion of these properties, take a look here.

A VC should be thought of as a typical backend with a few fundamental changes:

• Write operations require consensus among Orbs Validators.
• Responses to read requests can be validated against the state (which is under consensus), using cryptographic data structures like a Merkle tree.
• It is an append-only database, with a complete and tamper-resistant order of events.

Normally, apps coincide with VCs — one VC per app, and one app per VC. An app deploys (and updates) smart contracts on its VC. These smart contracts serve as the app’s logic (transition function). Since monthly payment for a VC is performed using the ORBS token on Ethereum, configuration of a VC is also specified on a virtual chain smart contract on Ethereum, where the app specifies the fee tier it wants to pay and its basic governance model:

• Apps choose between a few quality of service (QoS) tiers, each tier determines the resources (compute, bandwidth and storage) that the VC demands and the subscription fee required in order to run the VC. Validators are expected to dedicate the prescribed resources in favor of the VC. Fees are paid in ORBS tokens on Ethereum. They are paid in advance for the upcoming month (at least), to the virtual chain smart contract, from which each Validator receives her equal share.
• Apps specify who can deploy new smart contracts and upgrade existing ones. The Orbs platform permits apps to define complex governance models that allow their users to influence these policies, but without those defined, by default, only the key that created the virtual chain can do these things. It is possible to define an open VC where anyone can deploy new smart contracts, or limit this capability to a subset of users.

There are three principal differences in the way apps run over Ethereum compared to Orbs that I want to emphasize. (i) Fee structures are more flexible — apps can easily subsidize costs for their users rather than requiring their users to pay fees for each of their transactions. (ii) Apps enjoy resource isolation and can have resources (such as transaction throughput) guaranteed in advance. (iii) While smart contracts in Ethereum may define privileged entities, the typical governance model of a smart contract is that its code is immutable. A VC, on the other hand, is well suited for code updates and must declare the process that authorizes updates explicitly — this is the application governance.

Anyone can create a new VC (and thus create an app) — this process is completely permissionless. Since apps need ORBS tokens in order to pay subscription fees, they are expected to be the primary consumers of ORBS tokens. Also, VC isolation makes it very easy to let anyone create a VC and reduces the risks it might arise. One VC cannot interfere with other VCs — not due to mistakes and not intentionally.

I want to emphasize — running an app over the Orbs platform means that the data produced by the app (and its users) is being made publicly available — this is due to the forkability guarantee that allows practically anyone to fork the app’s backend at any time and continue independently. However, an app might have only certain parts of its backend on the Orbs platform while other parts are kept off-chain using infrastructure that allows for confidentiality and data protection.

Orbs staking mechanisms

Now that the general overview of the Orbs network is clear, we can deep dive into the details of the different mechanisms that define the PoS architecture.

Guardian nomination (DPoS)

Anyone can become a Guardian in the Orbs network simply by sending a registration transaction to the guardian contract. However, it is not becoming a Guardian that is key, but rather becoming a significant Guardian backed by many Delegators who hold a large amount of ORBS tokens.

Appointing a Guardian (or delegating tokens to a Guardian) happens on Ethereum, where any account with ORBS tokens, can send a delegation transaction to the voting contract, indicating one of the Guardians.

In order to reduce product friction and make delegation as easy as possible, alternate delegation methods exist such as sending 0.07 ORBS tokens to the Guardian’s address. This guarantees that even users that aren’t tech savvy enough to send custom Ethereum transactions, but do know how to send ERC20 tokens, would still be able to participate.

Delegation remains valid for as long as a newer delegation has not been made. Delegation does not involve the transfer of the delegated tokens to a third party and currently does not require locking of the tokens. The Delegator remains in full control of her tokens while they are delegated. Note that delegation is tied to a specific account, so when ORBS token are transferred to a different account, the delegation ends.

Validator nomination (PoS)

Anyone can become a Validator in the Orbs network, but the appointment procedure may take time and may require a minimum of stake. In addition, Validators are kept under constant scrutiny by the Guardians and may be voted out of power at any time (see the following subsection).

The first step in becoming an active Validator is to register in the validator contract, a process that is designed to be completely permissionless. As hard incentives are introduced, registration may require locking of ORBS tokens.

Registered Validators undergo a warm-up period during which they connect to the network, sync (see below), and get ready to join as active Validators. After the warm-up period, a registered Validator joins the candidate validator list. In normal circumstances the top N candidates, in terms of (locked) stake, are appointed as the active Validators. Currently, N=22, but this figure may increase in the future.

Once the locking functionality has been made available and activated, registered or active Validators (with locked tokens) will always be able to voluntarily quit and request the unlocking of their tokens. After the Validator deregisters on Ethereum (requires sending a transaction to the validator contract in Ethereum), an unlocking period will begin, by the end of which the Validator can pull her ORBS tokens back to her personal Ethereum account. During the unlocking period, a Validator will no longer be part of the Orbs network (can not propose blocks, confirm blocks, etc.).

Guardians vote out Validators in ongoing elections

Guardians take part in periodic election events to remove misbehaving Validators. For specifics of the mechanism, like the exact election period, please take a look here.

In order to vote, Guardians send voting transactions to the voting contract on Ethereum. Among the top N+3 candidate Validators (in terms of stake), a Guardian votes by selecting up to 3 candidate Validators to disapprove. A vote is valid for a vote expiry period, which implies that Guardians are meant to cast a new vote frequently.

Every election event, based on a snapshot of Ethereum’s state (particularly, the ORBS token balances, the validator contract, guardian contract, and the voting contract), the Guardians’ votes are accumulated into a collective decision. A Guardian’s weight (at the time of the election event) is the total amount of tokens delegated to her including her own tokens. A Validator that accumulated enough of the total weight (of all Guardians that participated in the vote) is removed from the candidate list and eventually begins the unlocking period for cooldown. In the common terminology of computational social choice, this voting rule can be seen as a variant of approval voting combined with a weighted voting game (see also chapter 16 in the computational social choice book).

After an election event, the active Validators are the N candidates that staked the maximal amount of tokens and were not disapproved. Note that at most 3 Validators can leave the active Validator list in a single election event. There are some additional constraints to the Validators’ appointment procedure, such as: (i) Limit on the maximum number of candidates (that haven’t been active Validators before the election) that can join the active Validator list after a single election. (ii) Limit on the minimum number of active Validators.

There is a critical point to note here. While delegation and voting is done on Ethereum, the election results cannot be calculated on Ethereum. Since ORBS tokens move freely all the time, it is too expensive to recalculate Guardians’ accumulated delegated stake on every election event. Thus, election results are calculated on Orbs in a dedicated virtual chain. Election results are consumed by all other Orbs virtual chains as the active Validators that participate in the consensus process, run all Orbs smart contracts and store all Orbs blocks and state, are chosen by these elections.

Note that any Ethereum full node can verify that the reports are correct (and inform the public in case of an error). Later on, a scaling technique (TrueBit inspired, or using probabilistically checkable proofs, PCPs, as done by StarkWare) can be used to validate the reports on Ethereum. This will provide many exciting benefits that I’ll save for a later post.

Rewards and incentives

In this subsection I illustrate the rewards each archetype in the Orbs platform is entitled to. Essentially, the rewarding scheme is what drives participation in the Orbs platform and steers the platform as a whole towards its intended goals (like securing the network).

Delegators. A Delegator receives a reward for appointing a Guardian — the reward is proportionate to the amount of delegated tokens, and is entitled only in election events in which the Guardian participated (had a non-expired vote). For the specific amount of ORBS tokens that are distributed to Delegators, look here. In the first year a fixed amount of tokens will be distributed to Delegators, regardless of how many tokens are delegated. This implies that the reward (per delegated token) is higher when participation is low.

Guardians. A Guardian receives token rewards to incentivize active participation in the periodical Validator disapproval elections and to build a large community of represented stake. Thus, the reward is proportionate to the total amount of tokens delegated to her, for every election event in which she had a non-expired vote. Only the top M guardians (in terms of delegated tokens) receive rewards, this is an interesting limitation that will be discussed later in the rationale post. In the first year, a fixed amount of tokens will be distributed to Guardians regardless of how many tokens are delegated.

Validators. A Validator is compensated for operating the network. In the first year, Validators receive a fixed token reward to incentivize new Validators to join when the network use is still low. In addition, Validators get rewards proportional to the number of tokens they hold (in the future only locked tokens will count). We emphasize that unlike the previous cases, there isn’t a fixed amount of ORBS tokens to be distributed among Validators. A Validator does not get rewards during times she was not included in the active Validator list. Note that Validators’ rewards come in addition to VC subscription fees.

The next post

That’s it for now! In this post, we’ve mostly focused on outlining the staking mechanisms. We’ve explained how they work without going into details as to why they work this way.

In the next post, I will analyze the different decisions and show how they’re well suited towards steering the Orbs platform towards meeting the goals we’ve declared in the previous post. I’ll also explain our attempt at designing a healthy architecture, where common plagues of PoS architectures, like cartels and concentrations of power, are avoided.

Get involved with Orbs

• Visit the website to learn more about the Orbs public blockchain
• Orbs is open source! Review the code on Github and contribute
• Start developing apps on Orbs, review the documentation

Originally published at https://www.orbs.com on April 24, 2019.