orchestration - chain - provide well-known chain #9063
Assignees
Labels
enhancement
New feature or request
Comments
ivanlei
changed the title
turadg
changed the title
This was referenced May 6, 2024
what does that mean? |
mergify bot
added a commit
that referenced
this issue
May 20, 2024
refs: #9063 ## Description Extracted from #9376 ### Security Considerations <!-- Does this change introduce new assumptions or dependencies that, if violated, could introduce security vulnerabilities? How does this PR change the boundaries between mutually-suspicious components? What new authorities are introduced by this change, perhaps by new API calls? --> ### Scaling Considerations <!-- Does this change require or encourage significant increase in consumption of CPU cycles, RAM, on-chain storage, message exchanges, or other scarce resources? If so, can that be prevented or mitigated? --> ### Documentation Considerations <!-- Give our docs folks some hints about what needs to be described to downstream users. Backwards compatibility: what happens to existing data or deployments when this code is shipped? Do we need to instruct users to do something to upgrade their saved data? If there is no upgrade path possible, how bad will that be for users? --> ### Testing Considerations <!-- Every PR should of course come with tests of its own functionality. What additional tests are still needed beyond those unit tests? How does this affect CI, other test automation, or the testnet? --> ### Upgrade Considerations <!-- What aspects of this PR are relevant to upgrading live production systems, and how should they be addressed? -->
mergify bot
added a commit
that referenced
this issue
May 21, 2024
closes: #9207 ## Description While working on #9376 I needed some tests to check how the pieces fit together. None of them actually make progress on #9063 that that branch points to so I'm submitting them under this other PR. The goal of this PR is just to provide unit tests and some cleanup of the app code. It still has a lot of fake stuff. ### Security Considerations <!-- Does this change introduce new assumptions or dependencies that, if violated, could introduce security vulnerabilities? How does this PR change the boundaries between mutually-suspicious components? What new authorities are introduced by this change, perhaps by new API calls? --> ### Scaling Considerations <!-- Does this change require or encourage significant increase in consumption of CPU cycles, RAM, on-chain storage, message exchanges, or other scarce resources? If so, can that be prevented or mitigated? --> ### Documentation Considerations <!-- Give our docs folks some hints about what needs to be described to downstream users. Backwards compatibility: what happens to existing data or deployments when this code is shipped? Do we need to instruct users to do something to upgrade their saved data? If there is no upgrade path possible, how bad will that be for users? --> ### Testing Considerations <!-- Every PR should of course come with tests of its own functionality. What additional tests are still needed beyond those unit tests? How does this affect CI, other test automation, or the testnet? --> ### Upgrade Considerations never yet deployed
mergify bot
added a commit
that referenced
this issue
May 23, 2024
refs: #9063 refs: #9207 ## Description As part of #9063 I'm trying to improve the testing situation. One challenge is faking the bridges. This PR factors out some test utils, with the eventual goal of providing fixtures in each test for the bridge comms. Along the way I realized that one of the tests had the wrong bridge, and that we could have avoided that if the scoped bridges were typed by their bridgeId. So this also does that. @michaelfig I'd like your take on this. ### Security Considerations <!-- Does this change introduce new assumptions or dependencies that, if violated, could introduce security vulnerabilities? How does this PR change the boundaries between mutually-suspicious components? What new authorities are introduced by this change, perhaps by new API calls? --> ### Scaling Considerations <!-- Does this change require or encourage significant increase in consumption of CPU cycles, RAM, on-chain storage, message exchanges, or other scarce resources? If so, can that be prevented or mitigated? --> ### Documentation Considerations <!-- Give our docs folks some hints about what needs to be described to downstream users. Backwards compatibility: what happens to existing data or deployments when this code is shipped? Do we need to instruct users to do something to upgrade their saved data? If there is no upgrade path possible, how bad will that be for users? --> ### Testing Considerations <!-- Every PR should of course come with tests of its own functionality. What additional tests are still needed beyond those unit tests? How does this affect CI, other test automation, or the testnet? --> ### Upgrade Considerations <!-- What aspects of this PR are relevant to upgrading live production systems, and how should they be addressed? -->
mergify bot
added a commit
that referenced
this issue
Jun 6, 2024
refs: #9063 ## Description Progress on #9063, looking up primary chain info by chainID. Modeled after https://github.com/Agoric/agoric-sdk/tree/dc-unk-chain-misc Doesn't yet handle IBC connection info (`hostConnectionId`, `controllerConnectionId`). I propose this is worth landing without that but invite reviewers to weigh in with requests. ### Security Considerations <!-- Does this change introduce new assumptions or dependencies that, if violated, could introduce security vulnerabilities? How does this PR change the boundaries between mutually-suspicious components? What new authorities are introduced by this change, perhaps by new API calls? --> ### Scaling Considerations <!-- Does this change require or encourage significant increase in consumption of CPU cycles, RAM, on-chain storage, message exchanges, or other scarce resources? If so, can that be prevented or mitigated? --> ### Documentation Considerations <!-- Give our docs folks some hints about what needs to be described to downstream users. Backwards compatibility: what happens to existing data or deployments when this code is shipped? Do we need to instruct users to do something to upgrade their saved data? If there is no upgrade path possible, how bad will that be for users? --> ### Testing Considerations <!-- Every PR should of course come with tests of its own functionality. What additional tests are still needed beyond those unit tests? How does this affect CI, other test automation, or the testnet? --> ### Upgrade Considerations <!-- What aspects of this PR are relevant to upgrading live production systems, and how should they be addressed? -->
mergify bot
added a commit
that referenced
this issue
Jun 6, 2024
refs: #9063 ## Description More progress on #9063 Following up on #9459 Next I think I'll set up a tool to grab the chain-registry info for the chains in the checklist and bring them into agoricNames In parallel, @dckc is populating agoricNames with the chain _connection_ info which can be appended to even after the chain (graph node) is defined. ### Security Considerations no changes ### Scaling Considerations no changes ### Documentation Considerations no need ### Testing Considerations CI, including A3P proposal update ### Upgrade Considerations no yet deployed
Merged
mergify bot
added a commit
that referenced
this issue
Jun 10, 2024
refs: #9063 ## Description Progress on, - #9063 To be closed when all the names in the checklist are present. ### Security Considerations none ### Scaling Considerations none ### Documentation Considerations none ### Testing Considerations Updated test setup ### Upgrade Considerations Not yet deployed
mergify bot
added a commit
that referenced
this issue
Jun 11, 2024
refs: #9063 ## Description More progress on, - #9063 ### Security Considerations Sources chain network data from chain-registry. ### Scaling Considerations Writes each chain info node or edge to one vstorage node. ### Documentation Considerations none ### Testing Considerations We'll also have to solve making it work in Starship but I think that's a concern for #8896 or a new ticket. ### Upgrade Considerations Not yet released. When we do want to update the chain info in agoricNames we'll need new work.
Merged
mergify bot
added a commit
that referenced
this issue
Jun 12, 2024
refs: #9063 closes: #8879 ## Description Fast follow on #9376 Tests that uncovered that the JSON.stringify encoding is not a valid vstorage key. There's one character that can be used as a separator `_`, the only vstorage valid char that's not a chain-id valid char. (vstorage chars are superset of chain id chars) Also fixes the chain_id half of the connection key, which had been chain name. Also adds a cache to chain info writer so it doesn't write entries that exist and haven't changed. Some misc test supports as well. ### Security Considerations none ### Scaling Considerations none ### Documentation Considerations Eventually we'll document these new vstorage nodes, but probably by just pointing to some snapshots. ### Testing Considerations The A3P test checks that it works through agd CLI. ### Upgrade Considerations not yet released
mergify bot
added a commit
that referenced
this issue
Jun 12, 2024
refs: #9063 ## Description When we started fetching the data by JSON, the import of JSON lost the string values, widening to `string`. This made the string templates fail. It also widened true and false to `boolean`, which would prevent the feature inference for what a Chain can do. This wraps in `const` so the actual values propagate in the type. ### Security Considerations none ### Scaling Considerations none <!-- Does this change require or encourage significant increase in consumption of CPU cycles, RAM, on-chain storage, message exchanges, or other scarce resources? If so, can that be prevented or mitigated? --> ### Documentation Considerations none <!-- Give our docs folks some hints about what needs to be described to downstream users. Backwards compatibility: what happens to existing data or deployments when this code is shipped? Do we need to instruct users to do something to upgrade their saved data? If there is no upgrade path possible, how bad will that be for users? --> ### Testing Considerations CI <!-- Every PR should of course come with tests of its own functionality. What additional tests are still needed beyond those unit tests? How does this affect CI, other test automation, or the testnet? --> ### Upgrade Considerations none <!-- What aspects of this PR are relevant to upgrading live production systems, and how should they be addressed? -->
mergify bot
added a commit
that referenced
this issue
Jul 15, 2024
refs: #9063 ## Description Fixes bugs in unreleased code related to publishing `IBCConnectionInfo` to vstorage and parameterizing ICA channel creation. ### Testing Considerations These were surfaced in E2E testing. Includes an additional test to verify connection info between two well known chains, as current snapshots are a bit hard to decipher. ### Upgrade Considerations Changes unreleased code.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the Problem Being Solved?
Allow an object derived from a
ZcfSeatto return aChainobject based on achainNamewhich exposes common chain actions, including:For chains well-known to the API, the user should not have to specify IBC connection info.
Well Known Chains
Additionally, allow for chains unknown to the API additional details like IBC connection info may be needed.
Dependencies
Description of the Design
Security Considerations
Scaling Considerations
Test Plan
Upgrade Considerations
The text was updated successfully, but these errors were encountered: