search

Agoric / agoric-sdk

monorepo for the Agoric Javascript smart contract platform
Apache License 2.0
329 stars 208 forks source link

normalize (cosmos) ChainInfo schema #9807

Open 0xpatrickdev opened 4 months ago

0xpatrickdev commented 4 months ago

What is the Problem Being Solved?

To facilitate contracts for @agoric/orchestration, chain and connection info will be published to vstorage for clients and contracts to access.

The ChainInfo schema is inconsistent. Namely:

  1. a mixture of snake_case and camelCase is used
  2. some keys use counterParty* while others use counterparty*
  3. Sometimes counterparty is an object, other times its flatted to counterPartyPortId and counterPartyChannelId
  4. All prefix.key_prefix values say 'FIXME'

Description of the Design

  1. use camelCase to comply with js eco conventions
  2. counterparty is one word not two
  3. Propose to flatten, but if nested is preferred we should do it consistently
  4. remove prefix.key_prefix from the schema - we can append later if needed

Security Considerations

Scaling Considerations

Test Plan

Upgrade Considerations

dckc commented 4 months ago

internal consistency doesn't seem as valuable as consistency with whatever external database we're mirroring.

what do the chain registry npm packages do?

a mixture of snake_case and camelCase is used

got an example?

p.s. I see denom_units in https://www.npmjs.com/package/chain-registry

dckc commented 4 months ago

counterparty is one word not two remove prefix.key_prefix

concur

0xpatrickdev commented 3 months ago

A point for not using a counterparty object and instead flattening the data structure - it might be common to destructure these values and the developer might need to alias to something like rPortID, rChannelID, rConnectionID. (Would be nice to avoid this if we anticipate it as a common pattern)