-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add zetae2e serve-addresses #2393
Conversation
Important Review skippedReview was skipped due to path filters Files ignored due to path filters (4)
You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
@gartnera addresses.testnet.json is generated automatically by a script that accepts ZetaChain RPC endpoint (mainnet or testnet) and networks for connected chains' RPC. I see no reason why the same script cannot be used to fetch contract addresses for any other environment. We might need to tweak it a bit, but overall I think we should use it as auto-generation is generally more reliable than manually keeping a list up-to-date. Basically the script first queries ZetaChain RPC for supported chain list, then fetches RPC for each supported chain from the networks package, then makes a bunch of requests to all these RPC to get contract addresses. The only addresses it cannot get dynamically are here. |
We should consider storing all contract addresses in the upcoming Gateway contract, which will make this even more streamlined. Right now we're making at least 9 requests per chain to get all addresses. |
@fadeev because the addresses are not stable on localnet and developnet. The addresses will be different for every copy of localnet. As it stands today, you'd need to do a new release of protocol-contracts and toolkit to update the addresses right?
I think the new ChainInfo might be the best spot, so long as we only need it via RPC and not EVM. |
@gartnera from an off-chain program point of view, sure, but if you have a contract on Ethereum that needs to know ZETA token address or something, they can't make a query to an API, so having these addresses on EVM is important. |
@gartnera we can deploy a nightly (tagged) version of protocol contracts on npm with the latest version of developnet addresses. And you can run this script manually to generate localnet addresses. And modify Toolkit to accept those. |
Overall, having a registry contract that the TSS can write into would make the most sense to me for this. |
I think this is a good idea, but it would mean an additional tx/message on the Zeta core, which initiates this write . We should plan it accordingly . |
Description
In order for the toolkit to be usable on localnet and developnet, we need to be able to export the contract/tss/zrc20 addresses in the format that is expected. These addresses are not stable between localnet deployments, so we cannot simply export the data once. Add
zetae2e serve-addresses
command which will serve this data in the correct format.This PR is currently an POC for feedback. I will need help correctly mapping all the contract addresses from the e2e config format to the format expected by the toolkit. I will coordinate this change with changes across the networks and toolkit repo.
Another way of doing this is to just make all this info available via zetacored RPC or on-chain via EVM calls. That is more complex but is probably the better way to do it right @fadeev? I think we do have most of the info for zetachain already available (TSS, ZRC20), but not addresses of things deployed on external chains. Maybe related to this epic.
I think it would also be useful to add another endpoint which would serve the raw(ish) config to allow you to easily run
zetae2e
commands locally. So you could dozetae2e run --config http://localhost:9091/v1/zetae2econfig
.Current Output
Relates to:
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Include instructions and any relevant details so others can reproduce.
Checklist: