Back to Blog

Libra Core roadmap #2

December 17, 2019
Technical
Libra Engineering Team

At-a-glance

In Roadmap #2, we will focus on three main things: 1) delivering mainnet features in priority order, 2) defining launch criteria for going from Libra* pre-mainnet to mainnet, and 3) educating and including the Libra community so that they can be valuable contributors to the Libra project.

Roadmap #1 retrospective

Overview

Roadmap #1 was marked by discussions of design shifts in Libra Core ranging from how we deploy Libra pre-mainnet to Move script publishing. Thankfully, we remain on schedule for feature completeness and the community is growing strongly!

Highlights

  • Mainnet feature work: We finalized our designs in all major features for mainnet feature completeness, and all teams have moved into execution mode.
  • Pre-mainnet deployment: Pre-mainnet work has changed to adjust for changes in membership and extended timelines for testing.
  • Community support: Interest in the Libra project has turned into implementation and collaborative design!
    • We have regular calls with the Libra Association members to share progress and answer questions.
    • The Libra Developer Blog had its first contribution from an Association member.
    • We have participated in a few conferences like those at SF Blockchain Week to discuss topics like identity and security/privacy/economics.
    • We are using a GitHub Kanban to manage the project and provide complete transparency.

Roadmap #2

Roadmap #2 goals are to execute to our roadmap, define requirements for v1 launch, modify our pre-mainnet approach for non-technical members, and increase community involvement.

Mainnet feature work

We have finished relevant design work and have gone through a thorough, bottom-up timeline plan for all features. We are now working on a full set of Libra protocol architecture documents and finalizing our external APIs with input from the community. Moving forward, we are starting to identify the work needed to enable the community that the Libra project hopes to attract.

Below is a summary of our progress. Some new items have been added for visibility into what the team is doing right now. For a project management level view, see our GitHub Kanban and Recent Issues Updates.

Top priority feature list and status

 Feature  Workstream  Current Status 
Addressing / Interoperability Libra Protocol We are working through community feedback and input from the workshop session at the Libra Core Summit.
Full Nodes Libra Protocol Full node MVP done!
Full nodes have been pushed to testnet. We still have work to do on configuration/testing and discoverability.
Libra Protocol Definition Libra Protocol No new progress.
Reconfiguration (of the Validator Set) Libra Protocol We are actively working on consensus workflow (the unit test is pending review) as well as smart contract support (key rotation is supported, but adding/removing is in progress)
Reliability and Testing Libra Protocol Integrated Cluster Test now runs on every diff and discovers bugs in mempool/state sync, measures TPS (transactions per second) and latency.
Waypoints Libra Protocol We realized we could simplify the StateSynchronization flow (consensus/state synchronizer integration on GitHub)), so this is being worked on as a precursor to the rest of the Waypoints work.
Collections Move MVP for Vector done!
We might still want to revisit the API to figure out a better standard library experience.
Events Move Done!
Next steps are to optimize the storage schema.
Generics Move Nearly done!

  • IR parser, compiler, and all verifier checks have been implemented.
  • Fully supported in the VM, except for publishing generic resources directly. (A non-generic wrapper needs to be used right now.)
  • Next steps are to add more handwritten tests and prop tests.
Developer Infrastructure Libra Community We are in the process of finalizing the release process, but  recently have:

  • Now run continuous build and cluster test every 3 hours
  • Initiated notifications when nightly integration fails for Docker, config, or fuzzing tests
Pub/Sub Libra Community Prototype done!
We have a working prototype that we are productionizing now.  We went with an adaptor layer that lets any pub/sub system  integrate on top of Libra Core (e.g., RabbitMQ)
TCB Security / Crypto Amazing progress here!

  • Isolated the core logic for consensus safety along with the consensus private key. Next steps are to construct an independent process for full process separation of trusted and untrusted code.
  • Circulating an initial proposal on the Executor/VM safety. The main focus here is to establish a trusted path between consensus safety logic and this work and establishing trust on storage.
  • Shared proposal for automated, online key rotation with the experts at BisonTrails. They provided feedback that this proposal is more secure than typical approaches but very appropriate considering what is at stake.
Serialization Security / Crypto Done!
Libra Canonical Serialization (LCS) has been finished and is in use throughout the system.
Libra Pre-Mainnet Production Ops (see Libra pre-mainnet section below)
Libra Testnet Production Ops (see Libra pre-mainnet section below)

Libra pre-mainnet

We now have eight validator nodes deployed to Libra pre-mainnet!

New strategy for pre-mainnet for non-technical Association members

We created a new milestone for non-technical member validator node deployments. These are members that may not have an in-house technical team. The Libra Association, Partnerships, and the Libra protocol team are working on a strategy to assist non-technical members to deploy when the software is feature complete. Such members need to start preparing for how they will deploy their validator node, either by hiring technical support or utilizing a third party to run their validator node.

Going forward, we will focus on inviting organizations to join the Libra Association, keep growing the network, and continue marching towards a self-service model.

A community of Libra validator node operators

Our initial members are aligned with us on the vision that the Libra network needs to become a self-service model in order to scale to 100 members. Members have been involved and were at the first Libra Core Summit on a node operations panel and leading breakout discussions. Bison Trails also wrote a Libra blog about running a validator node. The initial member team we have is strong and we have been growing the community (both SREs and software engineers).

We created a Libra Slack Workspace open to all members, which has several discussion channels and has helped grow this community. We have also launched a member portal that will have slack bots, provide support to members, integrate with GitHub, Discourse and the CLA processes, and allow members access to documentation, configs, and more.

We are also working to figure out the software release process, continuous integration/deployment, and topics like which software branches members should use.

Mainnet exit criteria and launch readiness

As we get closer to launch, the Association will need to identify metrics that will enable members to evaluate whether the Libra blockchain is ready for launch (a public launch of the network will be subject to a vote by the Council of the Association). We need to measure success and identify dependencies. We have kick-started these discussions. In Roadmap #2, we will start to define these metrics (technical and non-technical). First we will start on the Libra protocol.

Technical metrics: Metrics related to the Libra protocol software (network, developer infrastructure, storage, etc.), Libra protocol and wallet dependencies, testing real money, scaling testing, etc.

Non-technical metrics: Metrics related to the Libra Association, the reserve, other wallets, go-to-market metrics, etc.

Community support and working in the open

Having delivered on Roadmap #1 goals, we’ve expanded what we’re doing in order to really push quality, size, and engagement in the Libra community. Here are our added plans.

Transparency

We already work completely in the open, publish our plans (including this document), and have a rotation of on-call engineers to support our testnet, forums, and incoming GitHub issues. However, all of these things are reactive and sharing out what we’ve already done. We have also streamlined our CLA process for Association members and external contributors (individuals and corporations) to enable their contributions.

For Roadmap #2, we want to get buy-in on plans for how to be proactive and begin to involve the community in how decisions are made and things are built. To that end, we’re writing proposals for formal Libra Technical Working Groups (e.g., discussions of interoperability and a universal Identity standard).

Having input from the community will also create a much better product. In the realm of how things happen off-chain instead of internal to the Libra protocol, there is very fertile ground to plant seeds of community growth without slowing down our march to mainnet.

Community building

We are working to directly build the community up instead of letting it come to us. It’s not completely clear what this will look like right now, but there are two main audiences: Association members and non-member client developers (both app level and smart contract level).

For Association members, we held the first Libra Core Summit in mid-November 2019. The goal of this effort included creating a community of the technical points of contact of the Association membership, teaching our members how the Libra network works technically, and brainstorming which working groups are needed.

For client developers, we’re actively engaging to source many of our product requirements around developer infrastructure and APIs directly from the community. To date, we have been focused on creating something new and were more internal facing. This marks a shift to very active solicitation and research in order to best enable the Libra community.

*On December 1, 2020, the Libra Association was renamed to Diem Association.