types for chain addresses

[turadg]

What is the Problem Being Solved?

With orchestration there will be "chain address" for many chains and functions that take an address may only work for addresses on a certain chain.

Description of the Design

Use TS string templates to create a generic "Cosmos address" and then concrete types for some well known chains. Consider having special addresses for "validator" etc

Security Considerations

Scaling Considerations

Test Plan

Upgrade Considerations

[0xpatrickdev]

#9312 contributed towards this. ~Two areas where I see remaining work -

• LocalChainAccount should use a ChainAddress object instead of a string

• finalize types in orchestration/src/types.d.ts:
  

  agoric-sdk/packages/orchestration/src/types.d.ts

  Lines 85 to 92 in 8e94b2a

  	/** An address on some blockchain, e.g., cosmos, eth, etc. */
  	export type ChainAddress = {
  	/** e.g. 1 for Ethereum, agoric-3 for Agoric, cosmoshub-4 for Cosmos */
  	chainId: string;
  	address: string;
  	// TODO what's the right way to scope the address? it's not chainId
  	addressEncoding: 'bech32' | 'ethereum';
  	};

  • do we need addressEncoding? I'm not sure we will be doing any encoding/decoding of pubkeys, so maybe no?
  • "etherum" encoding should maybe be hexadecimal
  • Tangential - we need to ensure chainId is readily available via Chain / ChainInfo

[0xpatrickdev]

Discussion around renaming ChainAddress.address -> ChainAddress.value led me back here... More recent thoughts:

• I think addressEncoding is helpful to preserve as it distinguishs accounts on cosmos-sdk chains that support hex and bech32. encoding, might be more concise
• EVM chainIds are integers. We might want an additional human-readable field, chainName or shortName, to capture something like 'eth' or 'gno'. See eip-3770 which is unofficially adopted by many

This gist attempts to spec out a universal blockchain address type. The pubKey types are largely irrelevant since we are only dealing with contract-controlled accounts.