I believe that in order to bring Secret to the same scale as ethereum, having a reliable testnet is crucial (ethereum has four public independent testnets, for example), so I want to make the stability of the testnet (and later betanet and staging net) a top priority, which means the KPIs the committee will track are as follows:
- The number of missed blocks throughout the testnet should be as low as possible. Ideally they should be as low as mainnet if not better and the uptime should be close to 99.99% (or at most 52.6 minutes downtime per year)
- The number of users asking questions about whether the testnet is down or is experiencing issues should decrease and ideally get close to zero. In the same spirit, the number of issues experienced in the testnet should be as close to zero as possible. This will require improving the tools and the documentation. Both of which will be done through extensive collaboration with the education committee and the development committee.
- The number of contracts deployed on testnet should increase; there will always be a need for localsecret (and I believe that this need will increase in the future with certain tools being developed), but I want to get to a point where every major developer will have a version of their application available on testnet. This will allow new users to join the Secret Network by seeing what it’s capable of, without having to spend money.
If you have any other questions about KPIs please do let me know and I will make sure to answer to the best of my abilities.
Yes, there will be two endpoints available, with 5 load balanced nodes each and run in separate data centres. The nodes will be provided by Stake or Die and Digiline.
I’m sorry I meant to write this in the initial post:
One of goal of the committee is it work and coordinate with all other major committees to start the necessary steps to improve the Secret Network as a whole. This committee will collaborate closely with the Dev Committee, the Education Committee and the Support Committee to make sure that the experience using the Secret Network is as good as possible, starting from the testnet.
I will help the Education Committee write documentation on topics such as:
- Running and managing validators on the Secret Network
- Creating a proper load-balanced setup for endpoints
- Guides on how to find the right hardware and what to look for in a data center
- Setting up a public-facing validator tracking website such as the one used by the Digiline Validator
I will collaborate with the Development Committee to write tools useful for the testnet and mainnet alike, such as:
- The Snip-20 Faucet
- The Snip-20 Transaction History Viewer
- The testnet monitoring tool
- Script to setup the previously mentioned front-facing validator tracking website
- Scripts to quickly get a validator up and running in both testnet and mainnet
- Scripts to manage a node more effectively and solve problems more quickly
- Scripts to automatically handle the failover from one node to the next when a validator’s node goes down.
- Writing necessary tools to get the Betanet and Stagingnet up and running
I will also work with the Support Committee in helping validators and node runners in the testnet and mainnet with problems they may be facing, whether it’s getting statesync to work or figuring out why a node suddenly crashed as is panic-ing when restarting.
In addition to that there will need to be some coordination with SCRT Labs to work on setting up the Betanet and later the Staging net. Betanet will probably need a lot of upkeep as it will be unstable. Staging net will need some work a few weeks before a major update, but will not have a lot of work most of the time.
Furthermore, I will be running three validators in three different regions. And I will be managing the Digiline front-facing endpoints for the network.
Frankly, some weeks 20 hours may not be enough
No. This is on-par with the development committee and requires the same skills. As you can see there are a lot of development tasks that I will be taking on as part of the work I will be doing for this committee. This rate is on par with what top development firms pay most of their developers and is on-par with the rates that freelance developers are paid. Thank you for the question tho, I do understand your concerns