Create a staging/development Testnet

[lock9]

Summary or problem description
Developing dapps on N3 is challenging when dependent on other contracts due to differing hashes between testnet and mainnet or their absence on testnet.
Essential contracts like Props, Neo Burger, and Flamingo are not easily accessible on testnet. While CPM helps, undeployed contracts or different hashes force developers to store dependencies hashes or recompile their contracts.

Note: It's already possible to download the contracts from main net to run locally. The problem happens when you deploy your code on Test Net.

Do you have any solution you want to propose?
A helpful solution observed in a competitor blockchain is a separate testnet where all mainnet contracts are deployed with the same mainnet hash. This would allow developers to deploy their contracts to this testnet and run accurate tests.

Using the same hash is important to ensure integrations with other dapps are working correctly.

Where in the software does this update applies to?

• Other: Test Net

[Hecate2]

Welcome to neo-fairy-test. Test everything on mainnet with all existing contracts & all existing data, and forget testnets.

[lingyido]

I bet what you called is actually mainnet forking. neo-fairy-test may really help you in this way.

[lock9]

Hello,

There aren't problems related to local testing or using the main net state. I'm referring to an open testnet, where developers can deploy and validate their applications with 'beta testers'. The existing testnet is unsuitable because the dependent contracts aren't deployed or have different hashes.

Developers already use main net data and that's exactly why their projects break when deployed to testnet.

[lingyido]

Actually, I like your idea if someone could build a devnet and sync it periodically from mainnet and clean the temporary changes made by devnet transactions. Let's say, cleaning and making a fresh start from mainnet's state as its Genesis State per week is a good choice.

[lingyido]

The hard part is that when you sync your state from mainnet, the second block's committee node should be somehow changed to a set of devnet nodes.

If you could solve this problem, I'd like to join as one devnet node.

[lock9]

Hmm, I'm not sure if cleaning the state will help. Maybe if it happens once every a few months ok, but not too frequently.

The solution used by another network is deploying the contracts using the same hash. Some contracts will need setup, I'm not sure how they handle that.

If the contracts are deployed and we have access to testnet Neo and Gas, we can use Flamingo or another DEX to swap it for other tokens.

[lingyido]

Deploying contracts is not a concise solution. It's better to sync all of the mainnet state to devnet. Then not only the important contracts are synced, but also the small ones.

Another hard problem for state syncing is how to change network id after genisis block.

[lingyido]

The solution used by another network is deploying the contracts using the same hash. Some contracts will need setup, I'm not sure how they handle that.

Could you please say which chain are you referring? Let's digger out how they do that and if it could be done on NEO. Just asking for an indistinct feature will not attract enough attention.

[lock9]

If we deploy all contracts, the small ones will be present. However, I understand that the state may be necessary in a few situations. I don't think that cleaning the whole state once a week will help. Some tests take longer than a week.

About the network ids, maybe it won't be an issue if we use a custom node implementation (with some tweaks).

I'm referring to the Flow blockchain: https://developers.flow.com/networks/flow-networks/accessing-testnet

[lock9]

A more interesting solution might be to use NNS natively, allowing developers to use contract names instead of hashes. However, that won't help if the contracts aren't deployed to the testnet. Somehow, we need to ensure they are present. It could be through a 'forced deployment' (changing the state directly) or a whole 'sync.'

There are two challenges that make this more difficult for Neo:

• We need more extended testing periods to test GAS generation-related features.
• The script hash remains the same when you update your contract. If developers deploy an updated contract, the script hash will be different.

[AnnaShaleva]

@lock9, have you considered the nspcc-dev/neo-go#2406?

[lock9]

Hello @AnnaShaleva,

Not really because the problem isn't related to local tests, we already download and use main net state locally. The problem comes when we have to deploy the application on Testnet. The code will work locally and on main net, but not on test net.

Imagine if Neo / Gas had different hashes on the main net and test net. The code would be much harder to manage and maintain.

[lingyido]

I have read the documents of FLOW. We may need support from those contract owners to identify what initialization steps should be done. And it will cost a lot for maintaining such a devnet. I'm not going to develop tools like these. Hope that NGD or NSPCC or other teams could maintain such a devnet.

[lingyido]

If you can make the your local mainnet forking publicly available, then itself will be a good devnet. And it can be used by normal users if they could change wallet's rpc endpoint. It would be much better if neotube could support it.

[lock9]

Since the main issue here is validating the application with beta users, we need to ensure it's easily accessible. That's why I believe it could 'replace' the existing testnet. Many wallets already support the Testnet, but not all support custom RPC nodes.

Another thing to consider is that we can't demand developers to host a new network when they need to test their applications. Even if they do that, existing explorers and some wallets won't be able to interact with it.