Secret Network Testnet Committee Charter (Q3 2023)

Secret Governance
1

Hi everyone,

Thanks to an increase in SCRT, as well as the buffer, we exchanged for $30386 and this again allowed us to run for an additional month.
Testnet was challenging at times recently, but we’ve met the challenges.
Currently syncing can take a long time, and you require more memory.

This quarter we look forward to migrating to pulsar-3, which gives dApps a closer copy of mainnet.
Stakeholders are urged to reach out to @ertemann or myself so you’re kept in the loop and migrate timeously.

The charter was updated with the following tasks for the migration, and anything else it takes to ensure a smooth transition;

Migrate to pulsar-3

  • Run new testnet alongside pulsar-2, including faucet, load balancer for public endpoints
  • Co-ordinating with testnet validators
  • Communicating with stakeholders, dApp devs etc
  • Updating explorers, faucets, Keplr config
  • Updating docs
  • Updating Secret JS Templates

The budget is quite similar to the previous quarter, although market conditions have changed a lot and this makes the SCRT ask including buffer around 88K at current price.
Given the higher demand on the testnet recently, as well as the upcoming migration to pulsar-3, I don’t believe we can cut the expenses to compensate.
We’ll continue to strive to do the best we can with the support we have.

Screenshot 2023-07-02 at 18.39.17
Screenshot 2023-07-02 at 18.39.171792×1444 273 KB

Kind thanks for your support of the testnet.

2 Likes
2

Hey taariq,

I am mostly is support for the testnet and pulsar-3 setup.

Questions

  • How long are we going to have pulsar-2 and pulsar-3 (1-3 months?)
  • Is it possible to cut some costs here ( I think we should cut some spending here) this will help funds for longer term.
3

Thanks for the support Mohammed.
Details are not finalized but I think a couple of weeks should be enough, not likely more than 4.
As said not final and you and Shade’s input would be valuable too.

In terms of cost, of course the network can run with fewer nodes, as done before and as it will need to for pulsar-3 initially, at the risk of stability, as before.
Recently the testnet has taken strain under sustained load, and the redundancy helped a lot. And given pulsar-3 we’ll need that more than ever.

I can’t cut hours because typically I exceed the hours, especially recently, and the last few weeks no hours were charged as we’ve run out.

The biggest opportunity to cut costs long term would be to invest in hardware, but you’ve been down this road and know the risks, so it’s not an avenue I’d explore lightly. Perhaps next quarter with pulsar-3 only running we can reduce nodes a little.
Most of us are renting servers and run an instance per server, and those costs also just increased with my contract being renewed.

If you have some ideas, or perhaps the hardware you have can work for the testnet, let me know please.

4

Items leading to no vote based on image above:

Note says “based on maximum of 13 validators” but quantity per quarter is 30.
12 committee validators, and does not match the 13 maximum.
Committee validators and validator expenses overlaps
Commtttee ba[open] nodes is not clear and can’t be approved
API Server + load balancer fee - What kind of load balancer justifies this cost?
Backup endpoint - What kind of primary load balancer is being used that can’t support backup nodes?
Phoenix I, II, III, IV appear to be run by the same party with the same risk factors, thus should not be allocated funding beyond the first node. Should explain why Phoenix should get funded 4x more than other node runners

RAID5 does not require 30 disks, why do we need 30 validators on testnet?

Why is there a goal to cover costs for testnet when there is no such goal for mainnet?

5

Thanks for taking the time, will comment on each inline, the first couple of issues can hopefully be clarified together since it seems mostly a misunderstanding.

Note says “based on maximum of 13 validators” but quantity per quarter is 30.
12 committee validators, and does not match the 13 maximum.
Committee validators and validator expenses overlaps
Commtttee ba[open] nodes is not clear and can’t be approved

This is actually 14 now, apologies for the typo so let me clarify.

The charter says 10 validators, besides the 4 testnet validators.

Typically we have a couple less, as people come and go each quarter, there’s a waiting list if we have the maximum.

Quantity per quarter refers to the 3 months budgeted, so 10 per month X 3 months.

“Validators” refers to those run by other validators, so budgeted separately.

API Server + load balancer fee - What kind of load balancer justifies this cost?

This is not just a load balancer, this is also 3 API servers that are archive nodes, 64GB ram, SSD etc, as well as the node for the load balancer, which is the same spec. So that’s 4 servers besides the validator nodes. I’m running a 4th atm because we had some load issues and one server seemed to be struggling more than others, so I have a backup.

Backup endpoint - What kind of primary load balancer is being used that can’t support backup nodes?

This is the same setup I’m running, but run by a different validator, Secret Saturn.

Phoenix I, II, III, IV appear to be run by the same party with the same risk factors, thus should not be allocated funding beyond the first node. Should explain why Phoenix should get funded 4x more than other node runners.

4 X the hardware, at least, and I spread it across data centres so it’s not exactly the same risk factors.

RAID5 does not require 30 disks, why do we need 30 validators on testnet?

Its not 30, but in principle, with much fewer validators, we faced outages.

Now we spread the load and there are always a few validators in the timezone available for an upgrade.

Why is there a goal to cover costs for testnet when there is no such goal for mainnet?

Mainnet validators are rewarded in SCRT, and only mainnet validators can be testnet validators to offset some of the cost.
Also, on mainnet we fund over 70 API nodes, and testnet often has more load at times for stress tests.

With the market the way it is it’s fair to ask these and more questions, and how we can reduce costs.

If you can help us run the testnet reliably for less you’re welcome to join us.

In any event, your input is appreciated, thanks.