The Road Towards the First Upgrade…

Published in

Oasis Foundation

3 min readJan 5, 2021

While Mainnet has successfully launched, this is only the beginning. Thinking ahead we have identified several areas that need improvements in order to make ParaTimes and the overall network even more capable. In the near-term the following are a set of features the Foundation proposes to deploy as a Mainnet upgrade in Q1 2021. Each of those links to technical details in the form of an ADR. Many of the proposed changes have already been implemented in Oasis Core and some are undergoing audits.

Light Clients and Checkpoint Sync

In order to make bootstrapping of new network nodes much faster, the upgrade will introduce support for light clients and restoring state from checkpoints provided by other nodes in the network (see oasis-core#2880 and oasis-core#2440). Nodes will be able to announce that they provide public light client endpoints to make discovery easier (e.g., enabling block explorers to publish such endpoints).

Random Beacon

The random beacon is used by the consensus layer for ParaTime committee elections and is a critical component in providing security for ParaTimes with an open admission policy. ADR 0007 specifies a random beacon implementation based on SCRAPE which provides unbiased output as long as at least one participant (validator node) is honest.

On-chain Governance for Easier Upgrade Coordination

So far all of the network upgrades had to be manually coordinated off-chain, validators needed to take dumps at specific heights, patch the dump etc. Every upgrade also required any previous state (and history) to be wiped. The new on-chain governance service as specified by ADR 0006 provides a simple framework for submitting governance proposals, validators voting on proposals and once an upgrade proposal passes, having a way to perform the upgrade in a controlled manner which minimizes downtime.

ROSE Transfers Between the Consensus Layer and ParaTimes

In the current Mainnet there is no way for ParaTimes to interact with other accounts in the consensus layer. ADR 0003 proposes a mechanism where ParaTimes can emit messages as part of processing any ParaTime block. These messages can trigger operations in the consensus layer on the ParaTime’s behalf. This also means that ParaTimes get their own accounts in the consensus layer which can hold and transfer tokens.

A Path Towards Self-governing ParaTimes

Currently all ParaTimes can only be governed by a single entity — the ParaTime owner. In this regard governance means being able to update certain fields in the ParaTime descriptor stored by the consensus layer registry service. On one hand the ParaTime descriptor contains security-critical parameters and on the other there needs to be a mechanism through which the ParaTimes can be upgraded (especially so for TEE-based runtimes where a specific runtime binary is enforced via remote attestation mechanisms). ADR 0004 extends ParaTime governance options and enables a path towards ParaTimes that can define their own governance mechanisms.

…and Beyond

Beyond the consensus layer updates there are also other areas that the Foundation is thinking about based on feedback from the community which are in early phases:

Improving the ParaTime developer experience by introducing a high-level ParaTime SDK that provides common functionalities.
Improving the frontend developer experience by introducing a JavaScript SDK that supports both the consensus layer and arbitrary ParaTimes based on the ParaTime SDK.
Building a bridge between ParaTimes and other networks like Ethereum.

We welcome any additional proposals for enhancements from the community (either via the contribution process in Oasis Core or via high-level suggestions in this community forum) and are also providing grants.