Thank you Carter for starting this thread. After reading @assafmo and @Cashmaney feedback, Stashh is also in favor of the upgrade on the 21.
Firstly, with the testnet committee hat on, Iām not opposed to another testnet if the community wants it.
That said, I also want to advocate for LocalSecret, even amongst multiple teams like yourselves and Sienna.
Youāll just have to host a shared instance and ask them to either deploy their contracts, or give it to you to include in your build or testing phase.
If itās open source of course no problem to include in your project.
Iāve deployed such an example environment here to test the upgrade on my own, just running the latest LocalSecret as itās released.
Itās got a custom chain id of `my-secret-testnetā, which you can see in the LCD, RPC and the explorer
Thereās also a Keplr connection page, and some CLI connection info for folks testing in your environment.
It stops just short of a real testnet with SGX, but should satisfy most of your needs.
Iāve just rebuilt it and that took me a few minutes, but itās been running since the beta was announced.
The project is on github and thereās lots of improvements we can make, but Iāll leave it as is until thereās demand for more.
Bigger teams might want Kubernetes deployments, Ansible etc, and the docker-compose file should be easy enough to convert.
Hope that helps at least for the next upgrade, cos IMO itās better to have full control of the environment if youāre building a complex project like Shade.
I wonder if @Cashmaney can speak to how tough it would be to snapshot testnet state at one particular moment and make it into a larger localsecret instance?
Iāve reached out to Sienna, ALTER, Btn.Group, Trivium, Selenian, StakeEasy, V-IRL, and Time Capsule and linked them to this post for reference. Will follow up with Keplr and Fina as well in case the SecretJS change affects them. Is there anyone Iām missing?
@assafmo I know i mentioned this in our private comms but going to mirror it here.
For Local Secret would love to have the config being out-ported to the Docker Compose Configs, So i can set the default config or modify the config on how the testnet runs. This will help us (and probably others) make more suitable dev environments for multiple use cases, perhaps even painting a full internal shared testnet network hosted on docker (rather than having another public testnet)
Here is my version of the docker that we use internally for now.
Yeah, weāve noted that feedback and will try to add this feature soon. Thanks!
To me this all highlights the value of open discussion. When something doesnāt work it is human nature to say, āif I found that right away, what else might I findā¦ā. The critical parts to me from @assafmo and @Cashmaney are how much testing has been done, and the need to having a realistic risk acceptance model based on the importance of pushing things forward. So I am a yes.
In the future, could we, as @anon60841010 suggested on gov, clone mainnet and deploy upgrade to that leading up to a release? Then we upgrade mainnet and testnet at the same time and shut down the mainnet clone? Is this a crazy idea?