-
Notifications
You must be signed in to change notification settings - Fork 208
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
bidirectional lookup of denoms / brands for IBC #9211
Comments
some recent relevant work: agoric-labs/ag-power-tools#8 (comment) see also: |
btw "petname" is a bit of a stretch here. It suggests that each person can have their own name for the tokens and that the names can be changed. I suppose those are true from the perspective of the BLD stakers as one aggregate "person", but... it's a stretch. |
"well known name handling" might be better |
refs: #9211 ## Description Prototyping for #9211 suggests we'll want to be [derive IBC denoms](https://tutorials.cosmos.network/tutorials/6-ibc-dev/#how-are-ibc-denoms-derived) using a hash of a path such as `transfer/channel-0/uatom` -> `ibc/27394FB092D2ECCD56123C74F36E4C1F926001CEADA9CA97EA622B25F41E5EB2`. I tried to use the sha256 function from `@cosmjs/crypto`, but I got error's about node's `crypto` module. `@cosmjs/crypto` imports an old version of `@noble/hashes`. The current version seems to be vat-safe. ### Scaling Considerations Compute performance: Doing a sha256 computation on XS in pure JS seems a little whacky. We could consider dropping down to C like we do for base64. But since this is a constant time operation, it doesn't seem worthwhile. Bundle size: A base64 encoded bundle with just this module seems to be around 500k. ``` ┌──────────────────────────────┬────────┐ │ (index) │ Values │ ├──────────────────────────────┼────────┤ │ @agoric/orchestration-v0.1.0 │ 1702 │ │ @noble/hashes-v1.4.0 │ 18820 │ └──────────────────────────────┴────────┘ total size: 36623 ``` ### Security Considerations supply chain: this adds a dependency on the current [@noble/hashes](https://www.npmjs.com/package/@noble/hashes), which is reasonably popular (3m weekly downloads) and seems to be well audited. ### Documentation Considerations I'm not sure where this shows up in the orchestration API yet. ### Testing Considerations A test that it works in a compartment is included. ### Upgrade Considerations Unrelated to any deployed code.
closes #9211 ## Description - feat: chainHub.registerAsset / lookupAsset - feat: Orchestrator.getBrandInfo - getChain() is now backed by a store - groundwork for asset info in agoricNames - #9752 ### Testing Considerations unit tests cover happy path. Low code-complexity doesn't seem to merit more. ### Security / Scaling Considerations none, AFAICT ### Documentation Considerations make `getBrandInfo()` work as documented, provided assets are registered with the ChainHub ### Upgrade Considerations not yet deployed
- still does not support brand lookups (see #9211) - throws error if a brand is provided instead of warning in the console - moves bondDenom check to delegate method to preserve functionality - also includes this helper on LocalOrchestrationAccount
- still does not support brand lookups (see #9211) - throws error if a brand is provided instead of warning in the console - moves bondDenom check to delegate method to preserve functionality - also includes this helper on LocalOrchestrationAccount
- still does not support brand lookups (see #9211) - throws error if a brand is provided instead of warning in the console - moves bondDenom check to delegate method to preserve functionality - also includes this helper on LocalOrchestrationAccount
Reopening until the "#9211" comments (8 files) are resolved. |
- still does not support brand lookups (see #9211) - throws error if a brand is provided instead of warning in the console - moves bondDenom check to delegate method to preserve functionality - also includes this helper on LocalOrchestrationAccount
What is the Problem Being Solved?
#8879 manages IBC paths but developers need a way to establish a correspondence between a denom and its issuing chain, and optionally an ERTP Brand.
Description of the Design
With the above requirements we landed on each contract having a ChainHub. That can load from agoricNames and/or be filled manually by contract code.
Security Considerations
Scaling Considerations
Test Plan
getBrandInfo
works with ChainHub (done in #9754)All exos look up denoms using ChainHub
Not in scope: filling ChainHub using agoricNames, which is
Upgrade Considerations
not yet deployed but needs an upgrade test
The text was updated successfully, but these errors were encountered: