-
Notifications
You must be signed in to change notification settings - Fork 229
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
support non-Cosmos addresses in ChainHub #11007
base: master
Are you sure you want to change the base?
Conversation
Deploying agoric-sdk with
|
Latest commit: |
3add2cf
|
Status: | ✅ Deploy successful! |
Preview URL: | https://4c94c50c.agoric-sdk.pages.dev |
Branch Preview URL: | https://250-non-cosmos.agoric-sdk.pages.dev |
f486d77
to
e7aebd1
Compare
chainId: string; | ||
// TODO should we call this accountAddress to align with CAIP-10? | ||
/** The address value used on-chain */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Vitalik has been calling this a "chain-specific address" ethereum/ERCs#735
c4096c3
to
24525be
Compare
if (parts.length >= 3) { | ||
return { | ||
chainId: `${parts[0]}:${parts[1]}`, | ||
accountAddress: parts.slice(2).join(':'), // Handles cases where the address contains colons |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we expect this to be the case (colon in address value), or are we being defensive? Maybe better to throw if the length is > 3?
* agoric1megzytg65cyrgzs6fvzxgrcqvwwl7ugpt62346 | ||
* cosmosvaloper1npm9gvss52mlmk | ||
*/ | ||
export type CosmosAddress = `${string}1${string}`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should call this Bech32Address
, or even just Bech32
? For Ethereum, we could do:
export type (Hex|HexAddress) = `0x${string}`
Maybe too hungarian, but bech32
is also used outside of cosmos
// TODO should this be AccountId to align with CAIP-10? | ||
/** An address on some blockchain, e.g., cosmos, eth, etc. */ | ||
/** à la CAIP-2 */ | ||
export type ChainId = `${string}:${string}`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this work for the backwards compat case? i.e. agoric-3
instead of cosmos:agoric-3
? The answer might be it doesn't, and this is probably fine, but looking to better understand
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One of these is always namespaced. CosmosChainAddress['chainId']
is just agoric-3
.
Looks like this comment was reviewing by commit (good idea). In another commit it was changed to ScopedChainId
to clarify.
@@ -191,7 +191,6 @@ export const prepareIcaAccountKit = (zone, { watch, asVow }) => | |||
this.state.chainAddress = harden({ | |||
value: address || UNPARSABLE_CHAIN_ADDRESS, | |||
chainId: this.state.chainId, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would we want to prefix this with cosmos
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had considered that but it would make more cases to handle. In CosmosChainAddress
, chainId
is always within the cosmos
namespace. The CAIP-10 form always has a namespace.
destination = | ||
typeof destination === 'string' | ||
? chainHub.makeChainAddress(destination) | ||
: destination; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
iiuc - destination can be a non-cosmos chain?
I would expect makeTransferRoute
to throw if it sees a non-cosmos namespace. is this path tested?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. This is just for IBC. I'll handle make that more explicit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh good, it was already checking
assert.equal(namespace, 'cosmos'); |
but I'll leave a comment here to make the reader aware
@@ -200,7 +229,7 @@ export interface OrchestrationAccountCommon { | |||
* the transfer is rejected (insufficient funds, timeout) | |||
*/ | |||
transfer: ( | |||
destination: ChainAddress, | |||
destination: AccountId | CosmosChainAddress, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
destination: AccountId | CosmosChainAddress, | |
destination: AccountIdable, |
24525be
to
3add2cf
Compare
3add2cf
to
8a4659b
Compare
Deploying agoric-sdk with
|
Latest commit: |
8a4659b
|
Status: | ✅ Deploy successful! |
Preview URL: | https://37eb86ad.agoric-sdk.pages.dev |
Branch Preview URL: | https://250-non-cosmos.agoric-sdk.pages.dev |
refs: https://github.com/Agoric/agoric-private/issues/250
Description
Introduces new types and guards to use CAIP-2 and CAIP-10.
Maintains backwards compatibility by widening type guards and transforming types as needed.
Security Considerations
none
Scaling Considerations
none
Documentation Considerations
New types will appear in generated docs
Testing Considerations
TODO:
Upgrade Considerations
This has changes for both the API and the contract.
The A3P upgrade test will cover that the contract continue to work with these changes.
The API is kept backwards compatible through widening params and having type aliases.