Oasis Foundation.- While the Mainnet has launched successfully, this is only the beginning. Looking ahead, we have identified several areas that need improvement to make ParaTimes and the network in general even more capable.
In the short term, the following is a set of features the Foundation proposes to implement as a Mainnet upgrade in the first quarter of 2021. Each of these 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
To make bootstrapping 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 advertise that they provide public light client endpoints to ease discovery (for example, allowing 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 for providing security to ParaTimes with an open admission policy. ADR 0007 specifies a random beacon implementation based on SCRAPE that provides unbiased output as long as at least one participant (validator node) is honest.
On-Chain Governance for Easier Upgrade Coordination
Until now, all network upgrades had to be coordinated manually off-chain, with validators having to perform dumps at specific heights, patch the dump, and so on. Each upgrade also required wiping any previous state (and history).
The new on-chain governance service as specified by ADR 0006 provides a simple framework for submitting governance proposals; validators vote on the proposals and, once an upgrade proposal is approved, they have a way to carry out the upgrade in a controlled manner that 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 on the consensus layer. ADR 0003 proposes a mechanism whereby ParaTimes can emit messages as part of processing any ParaTime block.
These messages can trigger operations on the consensus layer on behalf of the ParaTime.
This also means that ParaTimes get their own accounts on the consensus layer that can hold and transfer tokens.
A Path Toward Autonomous ParaTimes
Currently, every ParaTime can only be governed by a single entity: the ParaTime owner. In this sense, governance means being able to update certain fields in the ParaTime descriptor stored by the consensus layer’s registry service.
On the one hand, the ParaTime descriptor contains security-critical parameters and, on the other hand, there must be a mechanism through which ParaTimes can be upgraded (especially for TEE-based runtimes where a specific runtime binary is enforced via remote attestation mechanisms).
ADR 0004 expands ParaTime governance options and enables a path toward ParaTimes that can define their own governance mechanisms.
…and Beyond
Beyond the consensus layer upgrades, there are also other areas the Foundation is considering based on community feedback, which are in early stages:
- Improving the ParaTime developer experience by introducing a high-level ParaTime SDK that provides common functionality.
- 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 such as Ethereum.
We welcome any additional proposals for improvements from the community (whether through the contribution process in Oasis Core or through high-level suggestions on this community forum ) and we are also providing grants .
MORE INFORMATION ABOUT OASIS
