This document describes the highlights of the Concordium roadmap following the Mainnet release in Q2 2021.
The roadmap is a dynamic plan and it will regularly be updated to support users and applications and take new research into consideration. Furthermore, as the source code will be open and as the governance of the blockchain evolves towards decentralization inputs from the community will inspire the roadmap.
The roadmap is based on two central principles as described below
- Consolidating before extending
- In parallel with the Mainnet continuously running a public, open testnet for demonstrating new features and for validating new and existing applications
These principles will ensure that the Concordium Blockchain continuously provides a reliable, stable platform supporting numerous applications.
Furthermore, the roadmap has a strong focus on improving the capacity through sharding, providing a feature-rich and easy-to-use environment for smart contracts as well as enabling interoperability and auditability.
Security Audit and Certification
The Concordium software will regularly be reviewed by independent security specialists to provide an additional layer of quality assurance over that already done in our development labs.
One goal is to have the Concordium software certified as an additional quality stamp. The form of certification is being discussed. Common criteria is one option but, if available, other recognized blockchain specific certifications will also be considered. Depending on the choice the certification will be towards the end of this roadmap cycle.
Testnet and Mainnet
The launch of Mainnet follows four public releases in Open Testnet 1, 2, 3 and 4, gradually adding more functionality. The first testnet demonstrated our 2-layer consensus protocol and the second focused on the ID layer demonstrating how accounts can be created and used privately based on a validated identity. Open Testnet 3 focused on encrypted transactions and the robustness of the blockchain in large networks, while the last testnet added support for Rust-based smart contracts.
In relation to Open Testnet 3 and 4 participants were incentivized to solve specific tasks providing valuable feedback to Concordium. In this way, the participants could gain the right to a certain amount of GTU on Mainnet.
The incentivized challenges on Open Testnet 4 are now closed but the open testnet will continue after the launch of Mainnet with nodes being run by Concordium as well as external node runners¹.
Open Testnet serves important purposes
- Testing the quality of new features in an open environment. Concordium may incentivize certain tasks related to this.
- Regression testing of existing applications running on Open Testnet.
- A development platform allowing system integrators to test and use new applications (and smart contracts) before and during deployment on Mainnet.
Concordium approves certain versions of the software for use on the blockchain, and before a new version can be approved it must go through two levels of testing.
- Internal testing in our labs
- Testing on Open Testnet
Thus, all additions and changes must have been tested and used on Open Testnet before being deployed on Mainnet². Due to the internal testing in our labs, Open Testnet can be expected to be well functioning during test phases.
There are three types of planned updates
- Protocol updates. All bakers must update as a hard fork will otherwise be created.
- Functional updates. Adding new features and improvements to node software. Failing to update will not create a hard fork.
- Update of tools and APIs. These updates do not affect the core blockchain functionality.
Protocol updates are the most extensive and will be planned well in advance. Four such updates are planned with a gradually increasing interval between each in order to meet the expected need for more frequent updates early after launch.
One or two functional updates are planned between each protocol update depending on the time interval between the protocol updates.
The principle of first consolidating and then extending means that the first year after the Mainnet release will focus on consolidating and optimizing existing features and providing tools and templates for using these. While it will remain important to optimize the blockchain, more and more effort will gradually be focusing on adding new features and extending the tool set. This can take the form of internal development within Concordium, community projects or partner projects.
As mentioned the roadmap is subject to regular reviews, and as part of this the functional updates will be defined in detail influenced by the needs of the users and stakeholders.
However, the functional updates around a given Protocol Update will focus on tools and APIs for improving the usability of the features in the Protocol Update. The functional updates before and after Siriuswill, for example, focus on improving smart contract tools and mechanisms to extract data from the blockchain for Auditability and Telemetry.
The functional updates around Vega will mostly relate to tools for sharding and interoperability. Furthermore, depending on the availability of external wallets (custodial and non-custodial) activities related to wallets are planned at this point.
The roadmap features are grouped into themes. While the next section gives more detail on these, some dependencies between themes will guide part of the planning.
One such dependency relates to providing a finalization service based on the consensus protocol in the blockchain (denoted FaaS). This can be used by external service and is also a cornerstone in our sharding mechanism. However, one thing is to be able to register events using FaaS — another is to be able to efficiently validate data on the chain. For parties running nodes as part of the blockchain, this is less of an issue but for interoperability with external parties it is important that this can be done efficiently. Tools and mechanisms for this are placed under the feature denoted “State Proofs” in our roadmap under the “Auditability” theme and “Outgoing messages” in the Interoperability theme.
We see another dependency between the evolution of sharding and token support. Initially, we focus on providing smart contract templates for tokenization and swapping but as these contracts mature and as sharding matures these contract templates will be extended to cross sharding operations.
The diagram below illustrates these dependencies in the evolution towards Polaris:
Below we provide insight into the roadmap themes.
Initially, the main focus is to produce example contracts (templates) implementing tokenization (fungible and non-fungible) and swapping of tokens. Token swapping functionality will be enhanced to allow for swapping of tokens across different shards, when support for sharding is sufficiently mature.
Some smart contracts require access to cryptographically secure randomness. Based on current research this feature is planned for Vega.
Concordium will have internal projects and sponsor external projects to improve smart contract development, analysis and test. A central internal goal is to provide tools for formally verifying smart contracts.
On an even longer term other smart contract languages may be added in internal or external projects. The selection of these is still open and depends on the specific needs.
For interoperability we will focus on the use of the finalization service of our blockchain (FaaS). This involves two parts. One is to provide good tools for including external events in finalized blocks and the other is to provide an easy way to validate such events. As mentioned, these features are closely related to two other themes, Sharding and Auditability.
In addition, Concordium will closely follow and participate in standardization activities in relation to blockchain.
Sharding parallelizes execution by dividing the network into smaller components or shards. The main goal of sharding is to overcome scalability issues and to allow applications to be run on their own, private shard.
Each shard essentially corresponds to a separate blockchain, that can be run almost independently of the other shards. This means that transactions on one shard are only processed by the nodes on that shard, allowing more transactions to be processed overall. It also means that different shards may use different consensus mechanisms and be optimized for a specific purpose.
Each shard runs an individual blockchain and uses the control chain to coordinate the individual shards. The control chain manages shards, provides a finalization service to the shards and provides a vehicle for cross-shard transactions.
Sharding will be introduced in a phased approach
- Proof of concept of sharding on our testnet with an optimistic consensus protocol and using the FaaS on the control chain.
- Private shards on Mainnet based on the proof of concept.
- Improve Shard coordination.
- Intershard transactions
- Additional consensus mechanism on shards
Auditability and Telemetry
The “Auditability and Telemetry” themes are based on a common need to extract data from the blockchain. For auditability it must be possible to easily validate this data — e.g., using “state proofs”.
State proofs, as well as APIs for extracting data from the blockchain, are considered part of the layer 1 functionality whereas another functionality such as presentation of data and integration with accounting software is at a higher layer.
Concordium provides both a mobile and a desktop wallet.
The mobile wallet can be used for managing and using accounts. It is considered a reference wallet and the expectation is that over time this wallet will be replaced by other wallets. Depending on when this will happen a few improvements are planned.
The desktop wallet offers enhanced key management functionality (support for Ledger Nano S) and will, in addition to account management and transfers, be used by Concordium for governance operations.
Note that the APIs mentioned under “Auditability and Telemetry” for extracting data from the chain can also be used to enhance future wallets.
Core Chain Protocol
A number of improvements to the core blockchain protocols are planned at all layers (Network, Consensus and Transaction). Important goals are to constantly make the blockchain faster and cheaper and to monitor and possibly improve security.
A few of the planned features should be mentioned here. First of all, “account policies” will be introduced allowing an account holder to specify under which conditions the account can send or receive GTU (e.g., reject transfer of GTU from accounts in banned countries). It is also planned to introduce a mechanism to temporarily exclude nodes that send messages violating the protocol specifications.
In relation to the Orion release, we will demonstrate a new consensus mechanism that will pave the way to the next generation of the blockchain
The tokenomics model for the blockchain is expected to be relatively stable, and only few updates are planned.
A central new feature is to introduce delegation allowing GTU holders not running a node to delegate GTU to a pool to get a share of the rewards on the blockchain. Furthermore, after listing the GTU a service will be introduced for getting the value of the GTU in fiat currency (Euro). This will be needed for a more precise computation of cost of transactions and can also be used in wallets.
In order to extend the usage of the Concordium ID layer we give high priority to libraries for using the ID concept in other applications. Other activities are related to updating and streamlining the handling of the life cycle of the keys of anonymity revokers and identity providers.
We have presented the Concordium roadmap, which is based on two central principles
- Consolidating before extending
- Continuously running a public, open testnet for demonstrating new features and for validating new and existing applications
We believe that this will provide a reliable, stable platform supporting numerous applications. At the same time, the roadmap has a strong focus on improving the capacity through sharding, providing a feature-rich and easy-to-use environment for smart contracts as well as enabling interoperability and auditability.
We will continue sharing updates on our progress, and seek comments and constructive criticism on one hand, and global community engagement on the other hand.
We would like to thank the community for the interest and support thus far, and we will continue working hard to maintain it.
¹ It must be noted that the Open Testnet is completely independent of Mainnet and identities, accounts and GTU on Open Testnet cannot be used on Mainnet and vice versa.
² No rule without exception and we may have to deploy emergency updates directly on Mainnet without going through Open Testnet first.
Join Concordium’s Community:
Learn more: https://concordium.com