Incentivised testnet - Strategy paper
By Philipp Strauch
Status: draft, 07/10/18
Part1: Purpose, goals, value propositions and expectations
1.Introduction - Where we came from, where we heading to
With the invention of Bitcoin Satoshi Nakamoto started a new era in 2008. By linking the world of computer science and distributed systems with behavioral economics the world’s first decentralised currency was born.
Ethereum came around, expanded and generalised this idea by storing the state of a virtual machine instead of only the account balances on a distributed ledger and so made it possible that developers could build arbitrary decentralised applications on top. But Ethereum, as it is currently conceived, shows limitations in terms of scaling and secure smart contract development mainly due to the design of its virtual machine.
It is now time for RChain to do the next step. RChain with its revolutionary underlying computational model the Rho calculus, on which Greg Meredith worked almost 20 years, goes new ways in order achieve a secure, sustainable and scalable infrastructure on which mission critical applications can be built on top.
2. Purpose of the incentivised testnet - Why do we need it and what is an incentivised testnet?
Once again we entering unknown territory. With RChain’s unique components and features it is obvious that these needs to be technically examined closely within a testnet prior to the Mercury launch. This testnet can be seen as an alpha/beta release that will include all components and the full features set we will see later on the mainnet. Besides other this will include:
- Casper - The Proof of Stake consensus protocol developed in collaboration with the Ethereum team
- Rho virtual machine - The heart of RChain’s virtual computer whose underlying computational model is the Rho calculus
- Rholang - RChain’s concurrent smart contract language
- RSpace - RChain’s storage layer
- Name space system - The Rho calculus inherently comes with a name space system that enables RChain’s very expressive sharding solution
As mentioned before blockchains cover the field of distributed systems and behavioral economics. In order to create an environment that is closed to the economic model and the wild west of the mainnet it is the plan to incentivise participation as well as certain interactions within the testnet in a competition-like fashion.
Similar to the Ethereum Olympic testnet this competition will incentivise participants to compete and complete various challenges in multiple categories covering each component. These may include challenges around tx activity like spamming the network with transactions or for example trying to mess up and do crazy stuff with the state. Besides that, validators will be rewarded for participating in this testnet. For future mainnet validators this will also be an excellent opportunity to get comfortable with the setup and all procedures involved for validating in the RChain network.
3.0 Goals, value propositions and expectations
This section covers what we want to achieve with this incentivised testnet, what kind of values this testnet provides and what we need to expect to happen.
3.1 Robustness, stability, bugs and security
When many people will try to mess up with the system and are incentivised to attack and put load on it from different angles we can expect that things break. We will be able to find bugs that threaten the security such as consensus failure or that provide possibilities to threaten the liveness like ddos attacks on the network. Participants will run the software stack on various operating systems and hardware setups. We should expect build and runtime problems and reports for multiple setups. This way we can improve stability, compatibility and support on various platforms. Getting rid of every bug and problem reported during the testnet will overall increase the robustness of the network.
Not only gives the testnet us the opportunity to benchmark the network under more realistic conditions than’ lab tests setups’ it also will give us a good picture where limitations and bottlenecks are and where we can improve the performance as users will put a lot of load on each component of the system.
3.3 Battle test mechanics and cryptoeconomics
The crypto economic model of a blockchain should provide incentives of participants in this distributed system to behave in a certain way. Generally analysing these more complex system game theoretically is sometimes a difficult task. Providing an environment that is closest to the environment we can expect in the wild of the mainnet will give us the opportunity to incentivise parties to attack this economic model on testnet. Furthermore we will be able to have a run (or multiple) of the genesis ceremony as well as the RHOC/REV swap so that we can ensure that everything will go smoothly when Mercury launches.
One very important aspect when it comes to user and developer adoption is the user experience and usability of the tool set. As we will have users and node operators or validators with different background knowledge we can expect to get a lot of feedback regarding UX/UI throughout the testnet which we can use to iterate and improve it.
3.5 Documentation and specification
Another key element when it comes to adoption is that developers is given a good documentation and specification of the platform. One can expect that we will get feedback during the testnet that shows up mismatches in implementation and specification or unclear points in the specification as well as missing docmentation or tutorials.
3.6 Awareness, outreach, marketing
Last but not least having this competition-like testnet will raise raise awareness and visibility. It will attract developers to play with the development stack as well as potential future validators.