-
Notifications
You must be signed in to change notification settings - Fork 214
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
SPIKE: prototype participants in Fast USDC sequence diagram #10254
Conversation
Deploying agoric-sdk with Cloudflare Pages
|
currently corresponds pretty closely to... The numbered arrows in the diagram correspond to
2024-10-10 14:29 cd6e57d chore(quickSend): skip bootstrap test (WIP) |
c42fbd6
to
6c05e8c
Compare
Base branch is changed to master. Please re-run the integration tests by adding 'force:integration' label. |
const fundingPool = await agoric.makeAccount(); | ||
const settlement = await agoric.makeAccount(); | ||
const feeAccount = await agoric.makeAccount(); |
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.
Can fee account be a Purse
? Only fundingPool
and settlement
might need to send or accept IBC transfers?
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.
In recent discussion, I confirmed with @sufyaankhan that it should be a normal cosmos account that the fee beneficiary creates before the contract launches; that way, they can withdraw at will using normal tx bank send
.
But I suppose it could be a Seat
, yes. (a Purse would give the contract direct access; we avoid that, normally)
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 said I think it's better to have something in master than nothing, but I want to qualify that. We should land the things we know even if they're incomplete. But there's some stuff to figure out around naming that I think we should nail down before this goes to master (so as not to teach people the wrong names and structure).
This PR still serves as a prototype even while open. Whenever someone's work depends on part of this let's land it. And if we get this to a point where what's known and what's temporary is clear, then let's land all of it.
Meanwhile, please PR the SwingSet changes in a PR to be reviewed by Kernel team. Maybe with a load test of some contract that's already in master. Perhaps price feeds because we want to optimize them at some point.
"source": "subdir", | ||
"sdk-generate": [ | ||
"vats/init-orchestration.js", | ||
"orchestration/init-quickSend.js" |
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.
in fast-usdc
now, yes?
I'm reluctant to have quickSend
around as a synonym for fast-usdc but we could use that to mean "the prototype". But what would be more clear is to call it that, like fu-prototype
. Let's try to get the naming of things figured out before merging this, and document it in the fast-usdc README.md
I forgot that part... let's see if it's easy... |
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.
Nice work 👏
export const NobleCalc = harden({ | ||
// XXX mock only | ||
fwdAddressFor: dest => `noble1${dest.length}${dest.slice(-4)}`, | ||
}); |
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.
Is this just for testing? if yes, can we move this to a /test
directory?
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.
yes, it's just for testing.
* @param {QuickSendAccounts & Passable} accts | ||
* @param {import('./client-types.js').CCTPTxEvidence} offerArgs | ||
*/ | ||
export const handleCCTPCall = async (_orch, ctx, accts, offerArgs) => { |
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.
Is it worth stubbing a notifier/subscriber for the Oracle, or adding a comment that denotes this behavior?
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.
elaborate? I don't understand what you mean.
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 wanted us to represent the Oracle Feed in a separate exo, but probably OK to punt on for now
in a couple tests: $ cd agoric-sdk/packages/boot $ SWINGSET_WORKER_TYPE=xsnap yarn test test/bootstrapTests/price-feed-replace.test.ts ... ✔ setupVaults; run updatePriceFeeds proposals (1m 27.6s) ℹ setPrice computrons 65536531n $ SWINGSET_WORKER_TYPE=xsnap yarn test test/bootstrapTests/orchestration.test.ts ... ✔ stakeAtom - smart wallet (13.8s) ℹ makeAccount computrons 15231491n
- part 1: send advance - part 2: settlement - sync arrow labels with sequence diagram
- support $SWINGSET_WORKER_TYPE
... and include contract, tools
- genesis vs. validator etc. - kubectl vs docker compose - skip mint100; gov1 has plenty - avoid tsx dep
## Description Support computron measurements in boostrap tests for performance testing by letting `makeRunUtils` caller provide a way to make a run policy. ### Security Considerations A swingset controller relies on the run policy to be well-behaved. But the caller of `makeRunUtils` can only shoot themselves in the foot. ### Scaling Considerations helps measure scaling issues ### Documentation Considerations JSDocs with static types provide adequate docs for an internal tool such as this. ### Testing Considerations Integration with a couple bootstrap tests is included. See also #10254 . ### Upgrade Considerations n/a
Helpful research. Not intended to merge or update at this point. |
refs: #10231
Description
quick & dirty prototype based on an early Fast USDC sequence diagram
Security Considerations
The contract code needs a careful scrub before anyone relies on it heavily.
Scaling Considerations
The detailed baseline computron count in this PR might be useful to track scaling issues going forward.
Documentation Considerations
not much
Testing Considerations
This includes several sorts of tests:
tx lifecycle
: heavily mocked unit test with diagram participants reified as objectwatcher: accept, report
: initial performance measurement, in computronsquickSend is in agoricNames.instance
- supports deployment on a running chainUpgrade Considerations
early prototype. doesn't involve upgrading anything that's already on chain