Skip to content
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

Orch api factoring #9356

Merged
merged 14 commits into from
May 15, 2024
Merged

Orch api factoring #9356

merged 14 commits into from
May 15, 2024

Conversation

turadg
Copy link
Member

@turadg turadg commented May 9, 2024

closes: #9207

Description

Refactoring the API types and perhaps implementation to satsisfy:

  • a types module specifying the public chain-agnostic interface for Orchestration
    • it must not expose Cosmos SDK types
    • it should not change
  • a types module for the IBC subclass of the public interface

Security Considerations

Scaling Considerations

Documentation Considerations

Testing Considerations

Upgrade Considerations

Copy link

cloudflare-workers-and-pages bot commented May 9, 2024

Deploying agoric-sdk with  Cloudflare Pages  Cloudflare Pages

Latest commit: 01e4ac2
Status: ✅  Deploy successful!
Preview URL: https://6b950dce.agoric-sdk.pages.dev
Branch Preview URL: https://ta-orch-api.agoric-sdk.pages.dev

View logs

Copy link
Member

@0xpatrickdev 0xpatrickdev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Considering we paired on this, I suspect you may also want a ✅ from @dtribble before merging

@turadg turadg force-pushed the ta/orch-api branch 2 times, most recently from dfbc592 to 7d51e2f Compare May 10, 2024 22:57
@turadg turadg requested a review from dtribble May 10, 2024 22:57
@turadg
Copy link
Member Author

turadg commented May 13, 2024

Taking out of draft. There's one lint failure but it's on no-use-before-define and I'm making a separate PR to disable that rule,

@turadg turadg marked this pull request as ready for review May 13, 2024 16:59
dckc
dckc previously requested changes May 13, 2024
Copy link
Member

@dckc dckc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's talk more before going to .ts for vat code.

export type * from './cosmos-api.js';
export type * from './exos/chainAccountKit.js';
export type * from './exos/icqConnectionKit.js';
export type * from './orchestration-api.js';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this looks circular. I can imaging that's not a ts error, but it seems unhelpful for thinking about things.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a blocking request for the PR? I can untangle the circularity but I wouldn't want to do that until the API surface is agreed upon

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a blocking request for the PR?

no.

I'm trying to understand the proposal.

packages/orchestration/src/orchestration-api.ts Outdated Show resolved Hide resolved
packages/orchestration/src/types.ts Outdated Show resolved Hide resolved
* Chain. Some operations accept any member of the equivalence class to
* effectively designate the corresponding token type on the target chain.
*/
export type Denom = string; // ibc/... or uist
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This we would like to NOT be cosmos-specific.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have heard that Gravity has an encoding of eth etc. denoms.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/PeggyJV/gravity-bridge/blob/main/module/x/gravity/types/ethereum.go

I think they use gravity/ethcontractadress but that doesn't include the Chain ID. So we would want something more like eth/<chainId>/<contractAddress>. The key is that it fits into the Denom formats, so we can just use Denom everywhere.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we might have better luck with an object here. You are right to call out that for ethereum (and solana) the important identifiers are contractAddress and chainId - denoms do not come into play until someone decides to make a representation on an IBC chain.

Aside - other evm-interop chains do not follow the same baseDenom pattern as gravity . On axelar they look something like: dai-wei, dot-planck, uusdc, weth-wei. And on kava: erc20/tether/usdt. I think we'll want to preserve these values in the denom name space, and use additional keys (contractAddress, chainId) to facilitate building messages for non-IBC chains.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The general that we don't need to commit a particular, I don't think I would want an object for all of these, since we get a lot of them back that are well known in context. All those fit just fine in the model of string encoding. these are just arms that someone on their chain can decide to use. Everyone else uses indirect references to them.

packages/orchestration/src/cosmos-api.ts Outdated Show resolved Hide resolved
packages/orchestration/src/cosmos-api.ts Outdated Show resolved Hide resolved
packages/orchestration/src/cosmos-api.ts Outdated Show resolved Hide resolved
packages/orchestration/src/cosmos-api.ts Outdated Show resolved Hide resolved
packages/orchestration/src/types.ts Outdated Show resolved Hide resolved
packages/orchestration/src/types.ts Outdated Show resolved Hide resolved
};
cosmos: { info: CosmosChainInfo; methods: {} };
agoric: {
info: Omit<CosmosChainInfo, 'ibcConnectionInfo'>;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Omit is magic. What's this mean?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems more clear to construct types additively rather than with subtraction. So what is the name of the type that doesn't include those operations?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fair. Agoric is one special case among Cosmos chains so I don't think it needs its own type alias, but I'll change it to Pick instead of Omit

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use info so it looks like a localhost connection. Eventually it may be replaced with that implementation.

packages/orchestration/src/types.ts Outdated Show resolved Hide resolved
export type DenomArg = Brand | Denom;

/** Amounts can be provided as pure data using denoms or as native Amounts */
export type AmountArg = CoinAmount | Amount;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Order of "agoric type | low level type" should match between DenomArg and AmountArg.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For usability, I expect the low-level type should be first.

@dckc dckc dismissed their stale review May 13, 2024 19:16

based on mis-read / misunderstanding

@turadg turadg mentioned this pull request May 14, 2024
@turadg turadg requested review from 0xpatrickdev, dtribble and dckc May 14, 2024 14:24
@turadg turadg removed request for dckc and 0xpatrickdev May 14, 2024 22:27
Copy link
Member

@dtribble dtribble left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Turadg and I walked through comments and agreed on the results. I consider it auto-approved after he makes those changes.

@turadg turadg added the automerge:rebase Automatically rebase updates, then merge label May 15, 2024
@turadg turadg force-pushed the ta/orch-api branch 2 times, most recently from c2fedbc to 952045a Compare May 15, 2024 16:39
@mergify mergify bot merged commit 2dc53d7 into master May 15, 2024
63 checks passed
@mergify mergify bot deleted the ta/orch-api branch May 15, 2024 17:26
mergify bot added a commit that referenced this pull request May 16, 2024
no ticket

## Description

Started as documentation for
#9356 (comment) ,
then I carried out the new best practice so it would be consistent. That
was a bit of a rabbit hole.

It's in a better place, though I don't see it reflected obviously in the
type coverage report.

### Security Considerations

n/a, types

### Scaling Considerations

n/a, types

### Documentation Considerations

This documents the new beset practice

### Testing Considerations

CI

### Upgrade Considerations

n/a, types
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
automerge:rebase Automatically rebase updates, then merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

stub out the Orchestrator API
4 participants