Since the official Libra project announcement in June, response from the developer community has been thrilling to watch. Developers have released several blockchain explorers (libranaut, libraview, librabrowser, and libexplorer) and integrated Libra testnet into their wallets (ZenGo, including a large PR to Libra Core). We've also seen other blockchain projects integrate Move into their systems (Solana). Calibra continues to develop Libra Core heavily on GitHub. The team has also released two new guides: one for running Move applications locally and another showing how to run your own network. The Libra Discourse forums are active with discussions about transaction scripts, client development, and interest in Libra events continues to grow.
Steady technical progress and open and transparent dialogue are key to growing developer interest in the project. As Libra Core progresses towards Mainnet, look for blog posts like this one to find roadmap updates.
Launching the Testnet has allowed the team to quickly improve Libra Core by making it easy to troubleshoot, diagnose, and resolve software edge cases. The Testnet demonstrates Libra network functionality and provides early access to developers.
Following the Testnet, we hope to have a successful launch of the Libra Mainnet. One method we use for tracking the project's success is how many of the deployed nodes are managed by different partners. The end goal of Mainnet is for all partners to have nodes deployed on the network. Each node will run on a mixture of on-premises and cloud hosted infrastructure. Our belief is that wider diversity of infrastructure will provide more resiliency to the Libra network.
To help you better track development progress we've added a Kanban board (visualized task board) containing all major engineering priorities. You can track this Roadmap's progress here.
Like many open source projects, contributions must have be made pursuant to a signed contributor license agreement (CLA). We are reviewing a handful of options to streamline the existing, manual CLA approval process.
The current development process enforces a high level of code quality. One tool we've adopted is homu. Homu is an open sourced bot that works with our continuous-integration/continuous-deployment(CI/CD) systems to ensure tests always pass. Our homu bot, @bors-libra, works by continuously verifying that tests pass between PR revisions and after other PRs are merged. You can see commands issued on PRs that tag the bot and instruct it to do work. Using a bot for managing merges, is common in larger scale projects that want to keep tests "green". This change adds an additional layer of security to the project by enforcing branch protection so that changes to the protected branch can only be executed by the bot.
The engineering team has started to post their design notes in GitHub issues. If you're looking for ways to get involved, or want to track specific features, and give feedback you can scan the GitHub issues page.
We are working towards providing clearer and more plentiful ways to help you get involved over time. We hope that publishing this and future roadmaps, updating the status of high level priorities, and sharing design notes can give you guidance and insight into upcoming Libra Core features.
Sprint Based Development
Since the beginning of the project, the team has used 60-day sprints to help guide planning and development of Libra Core. Each sprint has a set of features organized by priority. For Roadmap #1 the team is focused on security and reliability and work towards integrating additional partners into the coming Libra Mainnet.
Goals for Libra Core in Roadmap #1 are to focus on security and reliability and to integrate our first partners into the Libra network pre-Mainnet.
We continue to complete design work for all priority features. We are making good progress implementing features like Full Nodes. We're working to define node reconfiguration specification will work prior to finalizing the Libra Protocol definition.
Addressing / Interop
- Interoperability between multiple wallets is key to the success of the Libra network. The team is working to formalize a simple scheme to support sending to/from sub-accounts.
- The Libra blockchain will consist of a single node type that can be configured differently. This will allow the node to act as either a validator or a non-validating node that stores full history (full node). We will also work to allow easily upgrading full nodes to validators and vice-versa.
Libra Protocol Definition
- The team is working to define the API, Wire Spec, Addressing/Interop, and other protocol dependencies.
- The validator set contains unique identification of validators active in the system. Over time, the validator set needs to support changes. From a blockchain systems perspective, changing the validator set impacts every component. Consensus needs to re-certify blocks, the network needs to to reconfigure, storage needs to persist a LedgerInfo, and clients need a way to validate read data across validator changes.
- Waypoints will provide clients with an external source of information about the history of the blockchain.
TCB (Trusted Computing Base)
- The trusted computing base (TCB) defines subsets of components that are critical to system safety and stability. Minimizing the hardware and software dependencies of the critical components helps avoid inadvertent bugs and malicious attacks.
- The team is looking to implement deterministic serialization for sharing RawTransactions between validator nodes. To see more discussion on this topic, see issue #454.
- Explored designs for representing events in Move.
- Stabilized Events API for developers.
- Provided examples for how developers could record events that happen on-chain.
- Implemented vectors and explored other collection types to support.
- We landed #597 which unblocks validator set management. There is additional work to support this in the verifier and as part of the correctness assurances.
As the project tracks towards the Mainnet milestone, it is necessary to bring more nodes online while maintaining the operation of the testnet. To aid this effort, we've created a staging environment that we call Pre-Mainnet. Pre-Mainnet is currently only accessible to partner nodes to allow them to connect to each other. A handful of partners have already deployed their nodes and have them communicating with each other. We expect to have more partners coming online shortly. We want to ensure the Libra network can meet rigorous performance benchmarks and overall system stability before opening access. Stay tuned.
Come Join Us In The Forum
If you have any additional questions or comments for engineering team about this roadmap, please leave a comment here.
As the Libra Association has maintained all along, responsible financial innovation, and regulatory oversight are not in contest. The Libra project will comply with applicable laws and will not launch until this is achieved.