About this post
As was discussed in yesterday’s Governance meeting, the Roadmap 2020 RFC has been closed. Motivation for closing is that there are a lot of unresolved questions, no clear process for implementing items, and so the RFC wouldn’t be actionable.
For next year’s planning (roadmap 2021), it would be ideal to get a Roadmap Process RFC agreed and adopted well ahead of kick-off.
Meanwhile, the contents of 2020 Roadmap are instead posted here below, inviting for wider discussion and tracking or progress.
This doesn’t affect the roadmap contents, some items on the list below are already in the process of being actioned.
– Daniel
Grin 2020 Roadmap
Summary
This post lists areas and objectives that members of the Grin community would like to prioritize in 2020. The theme for the year is Underpinning. In construction, underpinning is the process of strengthening the foundation of an existing building or other structure. The ambition is to solidify Grin’s foundation throughout the course of 2020 and make it easier to build on in future years. This list is not exhaustive, and reflecting Grin’s open source nature, contributions in other areas are welcomed.
Motivation
Having a list of priorities commonly agreed on by members of the community can facilitate planning and identify what some of the deliverables might be throughout the course of the year. It also serves as a way to measure progress.
Furthermore, the process can be helpful in and of itself. As participants attempt to agree on a list of items that they consider are important to target for next year, it also becomes clear what is not as important in this context.
Community-level explanation
Development
- Kernel types. Complete specification of and implement relative kernels as outlined in mimblewimble/grin-rfcs#19
- Transaction building. Establish an approach that will be robust and good enough be a viable baseline for building grin transactions, and can replace unsafe http methods.
- Output linkability. Explore ideas and approaches to obfuscate the transaction graph, both in the mempool/p2p layer, and on the blockchain itself.
- P2P layer. Iterate on dandelion, explore Erlay, explore encrypting node traffic, and determine whether I2P support is something that should be dropped or targeted for implementation.
- Syncing and IBD. Take advantage of unspent bitmap commitment added in v3.0.0 to split IBD among many peers to improve latency, speed, and reliability. Explore FlyClient as a viable approach to light clients for mobiles and other devices, in order to reduce the reliance on hosted nodes.
- Proof-of-work. Prepare final tweak of ASIC Resistant secondary proof-of-work algorithm.
- Mining protocol. Research Stratum v2 and establish whether it’s a viable solution to reduce mining pool centralization.
- Testing. Integration tests, regression tests, unit tests. Processes, tools, and formalizing approaches.
- Releasing. Binary packaging, release processes, planning.
- Network upgrades. What should happen after the last scheduled hard fork in Jan 2021?
Developer experience (DX)
- Documentation. Promote documentation to a first class citizen in Grin.
- Exchange integrations. Provide better integration instructions for exchanges. Best practices, examples, and components as required.
- Wallet integrations. Provide better guidance for wallet projects on how to support Grin.
- Merchant integrations. Provide instructions for merchants on how to accept payments in Grin from their users in a manner that is privacy preserving and secure.
Community
- Onboarding. Make it easier for newcomers to begin contributing to the project.
- grincon2. Better planning, better lead times, raise quality, and attendance.
- Website. Improve communication and content on the Grin website.
- Meetups. Facilitate meetup organization and “local community start packages”.
Governance
- Moderation. Establish an indepent Moderation team.
- Vision. Define Grin trade-offs and design goals.
- Funding proposals. Formalize a process, encourage submissions.
- Resilience. Avoid creating any more single point of failures, share access and privileges.
- 2021 Roadmap. Improve on the roadmap planning process for the next year. More structure, milestones, and make it more inclusive.
Drawbacks
Having a defined roadmap might give the false impression to contributors that contributions in other areas are not welcomed. It might also introduce more hierarchy, politics, and bureaucracy into Grin’s processes.
Rationale and alternatives
As outlined, the focus is on improving what already exists today rather than introducing new functionality and features. This is deliberate. As the project is already spread out thin in terms of resources and contributors, care should be taken not to increase the surface area further.
Prior art
This RFC been heavily inspired by Rust’s 2019 roadmap process.[1]
In October 2019, there was a community call for ideas posted to the Grin Forum.[2] Below are excerpts from some of the submissions (by no means exhaustive):
AlexGSG:
there is a problem to withdraw from exchanges via HTTPS, it is drives the price down , because much easy to sell , than to buy!
Kurt:
Continue looking at techniques helping obfuscate tx graph (dandelion iterations, zero-knowledge cryptography to unlink TXO,…)
Phyro:
If a full node can scale on a mobile phone for many years to come start work on that, otherwise, research light client options
Andro:
The one thing that I want to see in 2020 is user friendly transactions and wallets.
notguilty:
Features are fun and nice but secondary to basic reliability. I would like to see a solid foundation…
Roelsmajor
When [FlyClient paper] Flyclient: Super-Light Clients for Cryptocurrencies?
Unresolved questions
- What about more detailed planning for node and wallet teams?
- What is the implementation strategy? How do we go about achieving what’s on the roadmap?
- How do we ensure that the contents in this RFC is well anchored with the contributors expected to make the actual heavy lifting?
- What happens when there are conflicting directions/ contributions?
Future possibilities
There is a lot of room for improving the roadmap process for future years, involving teams and contributors more directly and having a wider discussion about what’s important in the community. This was a first step. Hopefully there are learnings from this edition that can be used to improve future versions.