Testchain / onboarding opportunity

An ounce of prevention is worth a pound of cure.

I would like to see a permanent testchain that is upgraded before the primary chain. In order to flush out and avoid issues like we are seeing with the Granada upgrade ( and the kinds we have come across in the past ).

I don’t think it necessarily needs to be subsidized. Perhaps in the beginning. I think a testchain where the value of the coin is forced to zero ( thereby making all transactions non-taxable ) could be used as an onboarding opportunity for people to learn crypto without risk.

Which also makes it a fantastic marketing opportunity.

You could force the value to zero by making the coin centralized and explicitly stating that you will delete the balance of any exchange addresses.

Since it’s not necessarily meant to be decentralized a node owner could allow access to testing teams. Those teams could update or roll back various parts of the networks version in order to test varying conditions or simulate the current conditions ( or whatever desired ) of the mainchain.

3 Likes

It’s hard to disagree with you today that we need additional testing but isn’t there a testnet chain spun for every update for this purpose? Need more testers/bakers to make it look like mainnet?
We can incentivize people bake on a testnet just like TCF allocates some tez for grants every month.

1 Like

I would love to see something like Kusama and Polkadot. Their testchain Kusama acts like mainchain itself which is basically a test in production environment.

3 Likes

Testchains like edonet or florencnet are not the same thing. They are forever on that one protocol.

A testchain as I am describing would upgrade to the newer proposed protocols before the mainchain. It would also roll back if a proposal were rejected.

Preferably without rolling back the transactions.

4 Likes

My suggestion is after end of proposal period, a fork of test chain will automatically generated and all bakers would also onbard both mainnet and the testnet by default. This behavior should also formally be part of Tezos protocol, the testchain lives until mainnet take over the new protocol.

This way, we can even remove the adoption period entirely, currently the adoption period mostly is just a pure waiting game.

As a large scale distributed system which requires mutiple upgrades each year, a smooth and less surprising way of upgrading process is as important as other parts of this project.

Also it would be better if there were some upgrade checklists on tezosagora.org (or explorers tzstats.com tzkt.io etc), show key metrics like testchain missing rates, average block time, branches, average CPU, RAM, disk IO, node versions etc. With all these data at hand, bakers can have more confidence to vote during promotion period other than just vote yay/nay blindly.

3 Likes

I agree with this. Might be good to follow polkadot’s/Kusama’s example and make a testnet with cheap Tezzies so bakers can be more incentivised to help out. We definitely need to make these upgrades more fluid or big corporations won’t even consider Tezos for their projects.

2 Likes

I am seeing this topic come up more and more in the community.

A big disparity I am seeing is on whether it need to be incentivized via some external funding.

It seems as though many are not willing to take action unless they are funded. I’m certainly not against that but it is not necessary to get started and demonstrate why you might deserve funding and how you might intend to operate once the funding is gone.

The people in 2018 who made a big stink about testing gave up because they convinced themselves that they had to have funding. If they have slowly built things up since then, than today we would have the testchain we want and they probably would have gotten at least some funding at some point.

1 Like

A improvement of protocol upgrading test indeed does not absolutely require funding. The key issue here, our existing testnet is not designed for blockchain project like Tezos, it’s more like bitcoin testnet which a clean from scratch genesis block with total new test bakers. This works only for PoW blockchain, because miners compete eachother with CPU powers.

This is not the case for Tezos though, Tezos baking right pre-allocated to bakers according to their size, so the clean testnet can not simulate the real mainnet edge cases.

Simply fork the mainnet after proposal period and use the same chain history for testnet can improve the test dramatically. Somebody may say not all mainnet bakers willing to participate testing, well that’s actually better for testing. During real mainnet upgrade, some bakers offline ,some bakers run old version, some bakers simply late due to timezone issue. A wild situation can expose and capture more bugs with small well look after testnet.

Back to incentive topic, well my sugguestion is TF can simply delegate some of their tezzies to those bakers who actively tested, even better delegate to them and ask for less or zero baking reward.

1 Like

I would like to see a permanent testchain that is upgraded before the primary chain. In order to flush out and avoid issues like we are seeing with the Granada upgrade ( and the kinds we have come across in the past ).

The proposal testnets (such as Florencenet and Granadanet) are upgraded before mainnet. The transition from Florence to Granada in particular was tested on the Granadanet.

What is special about the testnet being permanent? How would this help detecting these kinds of issues?

I think a testchain where the value of the coin is forced to zero ( thereby making all transactions non-taxable ) could be used as an onboarding opportunity for people to learn crypto without risk.

How does this differ from the current situation? Testnet tokens are worthless because you can get them for free at the faucet.

Testchains like edonet or florencnet are not the same thing. They are forever on that one protocol.

Not exactly, they start on the predecessor protocol precisely because we also want to test the migration. They migrate in the early days of the testnet, usually through an on-chain vote.

2 Likes

Quite a lot of code would have to be written (and tested!) to allow to roll-back protocol upgrades. For example, if a protocol introduces a new Michelson instruction and some smart contracts are originated with it what should we do about them?

1 Like

We tried a variation of this for several upgrades (until Florence), the main problem is that because testchain tokens are worthless, a deny-of-service attack on a testchain node is cheap so it is not a good idea to run a baker on the same machine than a testchain node. See Draft: Add a draft for the deactivation of the test chain (!141) · Merge requests · Tezos / tzip · GitLab for the other reasons to deactivate this feature.

I don’t see the relationship between the adoption period and testing. The adoption period is about uncertainty on the result of the promotion vote.

2 Likes

Deny-Of-Service can and had happened on mainnet too, actually every upgrade always come with some level of “Deny”-Of-Service attack, that’s why I said it’s even more valuable for testing purpose. One or some big bakers can literially performance Deny-Of-Service attach by accident, and our chain should survival in such situation as much as it can. This is actually another area Tezos should improve, for example binance, coinbase and all TF bakers offline for what ever reason for several cycles, Tezos blockchain in theory should slowly back to normal rather than be impacted for all that period.

No need to make the testchain token valuable at all, some small incentive can be done by TF using the delegation as bonus etc would be enough to onboard enough bakers.

1 Like