You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
This feature would give us the ability to spin up new temporary environments which will help with protocol development and addresses a number of problems.
New features are not available to the general public or partners until a release has been fully tested and deployed via governance proposal which can take weeks. This causes a significant delay in our ability to receive and then act on user feedback. We should have the ability to deploy experimental features to an experimental network and receive feedback early and often.
New protocol features are difficult to test under real world conditions using local environments. Using public test or mainnet networks will provide better data and insights.
There is no stateful environment for testing connections to new networks such as Solana, Polygon, Base, etc that our partners or early adopters can use.
Local test networks do not use the same state as our production networks and incompatibilities between production network state and new releases may be missed. We have stateful upgrade path testing but it is ephemeral and doesn't include support for testing external networks or CCTXs.
This would be useful for both core and external contributors to the protocol code and would also benefit dapp developers who may want to test features ASAP.
Describe the solution you'd like
We'd like to leverage the E2E tooling to create a forked network using state from a real network. The E2E tool will
Manipulate the original state to change the active validator and observer/signer set
It will deploy smart contracts to the external networks of choice if they do not already exist
We should have the ability to reuse the token contract, connector contracts, and TSS address between deployments.
It will leave the network available to run 24/7 if needed.
This image should explain it better.
Describe alternatives you've considered
We already have the ability to create new networks with no historical state which can address some of these issues but they require a lot of operational overhead to create each time. We also risk divergence between how ops deploys the networks and how the deployment of tests are done.
We could rebuild all this functionality outside of the E2E testing suite but it will result in a lot of rework, won't include the same tests, and won't be easily usable by external contributors.
We are also working on the developnet which will be a running network using the latest commits to the develop branch but that will be a standalone and blank network. developnet is not a replacement for this E2E forked network deployment feature but they are complimentary. This feature could make developnet a better representation of real world networks.
Motivation and Context
This will increase confidence by giving us a place to perform manual testing on a release before deploying it on a production network (Athens or Mainnet) and makes it easier to work on experimental features with other partners.
The text was updated successfully, but these errors were encountered:
So zetae2e would offer a command that allow to initialize a new setup: deploy system contracts on external chains, zetachain, update chain params, etc... from a ZetaChain network instance pre-initialized (in the sense the state is already populated but info about external chains must be updated)?
So zetae2e would offer a command that allow to initialize a new setup: deploy system contracts on external chains, zetachain, update chain params, etc... from a ZetaChain network instance pre-initialized (in the sense the state is already populated but info about external chains must be updated)?
Yep that's what I was thinking. It would be helpful to have a command that initializes a new setup including deployment of contracts, chain params, etc. Ideally we could pass in some parameters like which external networks to use (BSC-Testnet, Sepolia, BTC, BSC-Mainnet, etc )
Is your feature request related to a problem? Please describe.
This feature would give us the ability to spin up new temporary environments which will help with protocol development and addresses a number of problems.
New features are not available to the general public or partners until a release has been fully tested and deployed via governance proposal which can take weeks. This causes a significant delay in our ability to receive and then act on user feedback. We should have the ability to deploy experimental features to an experimental network and receive feedback early and often.
New protocol features are difficult to test under real world conditions using local environments. Using public test or mainnet networks will provide better data and insights.
There is no stateful environment for testing connections to new networks such as Solana, Polygon, Base, etc that our partners or early adopters can use.
Local test networks do not use the same state as our production networks and incompatibilities between production network state and new releases may be missed. We have stateful upgrade path testing but it is ephemeral and doesn't include support for testing external networks or CCTXs.
This would be useful for both core and external contributors to the protocol code and would also benefit dapp developers who may want to test features ASAP.
Describe the solution you'd like
We'd like to leverage the E2E tooling to create a forked network using state from a real network. The E2E tool will
This image should explain it better.
Describe alternatives you've considered
We already have the ability to create new networks with no historical state which can address some of these issues but they require a lot of operational overhead to create each time. We also risk divergence between how ops deploys the networks and how the deployment of tests are done.
We could rebuild all this functionality outside of the E2E testing suite but it will result in a lot of rework, won't include the same tests, and won't be easily usable by external contributors.
We are also working on the
developnet
which will be a running network using the latest commits to the develop branch but that will be a standalone and blank network.developnet
is not a replacement for this E2E forked network deployment feature but they are complimentary. This feature could makedevelopnet
a better representation of real world networks.Motivation and Context
This will increase confidence by giving us a place to perform manual testing on a release before deploying it on a production network (Athens or Mainnet) and makes it easier to work on experimental features with other partners.
The text was updated successfully, but these errors were encountered: