Open-source roadmap
Opened this issue · 4 comments
All decentralised protocols need to be made open-source. However, the Ren team also wants to (a) be competitive in this space, given the hard work and capital invested by the team and the community, and (b) give an appropriate amount of time for security issues to be discovered and fixed before making the code-base available to potentially malicious actors.
This issue aims to discuss a roadmap for the open-sourcing of the Ren protocol, based on a specific set of milestones.
Roadmap
This roadmap outlines some key milestones that we would like to achieve before open-sourcing the entire code-base. It is in approximate chronological order:
- RenVM Testnet goes live to the community. Right now, the RenVM Testnet is only available to members of the working group. Once the RenVM Testnet goes live, community members will be able to play with the demos, and begin developing applications. This is a core part of testing the RenVM for security and stability.
- Smart contract audits by third parties. It is impossible to guarantee that smart contracts will be bug free, but getting third party audits is a necessary step to be sure that smart contracts are, with a high degree of confidence, free from vulnerabilities.
- RZL sMPC protocol and implementation audits by third parties. This will be done under NDAs with third party auditors and projects looking to adopt RenVM. At least initially, this should provide the community with an increased assurance that RenVM is correctly built without needing to trust the Ren team.
- RenVM Mainnet goes live to the community. All Darknodes will contribute to consensus initially, but only a subset of Darknodes controlled by the Ren team and members of the working group will contribute to execution. This ensures (a) that the protocol can be quickly updated if necessary, (b) that any disaster can be recovered from with minimal co-ordination, and (c) the community does not need to trust the Ren team to control all Darknodes.
- RenVM Mainnet has been running for a sufficiently long period of time. This ensures the security and stability of RenVM and gives us an opportunity to fix any bugs that reveal themselves during this time. (This issue will be updated with an exact time period when one is agreed upon.)
- A sufficient average daily volume is sustained over a sufficiently long period of time. This ensures the a sustainable and stable economic incentive to run a Darknode. (This issue will be updated with the exact volume and time period when they are agreed upon.)
- A sufficient number of projects have adopted RenVM. This ensures the a sustainable and stable economic incentive to run a Darknode, should any individual project fail or move away from RenVM. (This issue will be updated with the exact volume and time period when they are agreed upon.)
This isse will be edited to include new milestones as they are discussed, with justifying details as to why the milestones are sane.
paragraph 4.
Allow the ambassadors to be in the working group....?
The working group is made up of projects that are providing feedback on the design and implementation of the protocol. They are well positioned to do so, because each projects has specific needs and constraints. This allows us to ensure that the Ren protocol meets the needs of as many projects as possible.
This is in contrast to the Ren Ambassadors that are community members, but do not represent third-party projects.
Is this roadmap up to date?
2 years later...
Telegram promised to open source