test(boot): Fast USDC chain impact

[dckc]

refs:

• Fast USDC load test #10890

Description / Scaling / Testing Considerations

Demonstrate that impact on the chain is sustainable:

• vm integration test with a repeated iteration. In each iteration:
  • lp deposit
  • advance (oracle submit x3, IBC ack)
  • settle (IBC hook)
  • lp withdraw
• Capture metrics for each iteration (details in comments below)
• fix some seat leaks in the contract: moving to fix(fast-usdc): .exit() all internal temporary seats #10939
• fix a couple leaks in test harnesses

Security / Documentation Considerations

not much.

Upgrade Considerations

preparation for deployment.
not yet deployed.

[cloudflare-workers-and-pages]

Deploying agoric-sdk with    Cloudflare Pages

Latest commit:	73461e1
Status:	✅  Deploy successful!
Preview URL:	https://7d31b522.agoric-sdk.pages.dev
Branch Preview URL:	https://dc-fu-impact.agoric-sdk.pages.dev

View logs

[dckc]

I looked at the output using a jupyter notebook.
Exported source: fu-fun.py

VStorage: ~Flat (64 iterations)

lin(impact.vstorageTotalSize[13:])

intercept	slope
169303.86892	14.858679

Exported objects: ~Flat

lin(impact.kernelObjects[20:])

intercept	slope
596.86039	0.108578

lin(impact.clistEntries[20:])

intercept	slope
1908.711039	0.227136

[dckc]

Heap Sizes: ~Flat

That's the 25 largest vats, excluding vat1, which is so large it's an outlier:

32 iterations, reaping every 4th.

[dckc]

Computrons: ~Flat

def unitize(s):
    return s / s.max()

lin(unitize(impact1.computrons.dropna())[10:])

intercept	slope
0.902157	0.000069

Note: techniques for measuring this were drawn from...

• test(fast-usdc): count computrons for advancement #10621

[dckc]

Heap Size: investigating some growth

• v35 = smartWallet
• v41 = fastUsdc

p.s. escalated to a separate issue: #10955

[dckc]

Diagnosing kernel metric leaks: some in test harness, some in contract

Initial measurements showed neither kernelObjects nor kernelPromises were flat:

We diagnosed kernelPromises as a test harness problem:

• EV.sendOnly leaks kernel promises #10942
• test: Stop leaking kernel promises from EV.sendOnly calls #10943

For kernelObjects, we spot-checked individual objects, grabbing their kref and looking for it in a .slog file. The first deliveries where these objects were found had methods such as makeNoEscrowSeat:

{"type":"syscall","crankNum":381,"vatID":"v12","deliveryNum":4,"syscallNum":115,"replay":false,"ksc":["send","ko107",{"methargs":{"body":"#[\"makeNoEscrowSeat\",[{},{\"exit\":{\"onDemand\":null},\"give\":{},\"want\":{}},\"$0.Alleged: ExitObject\",\"$1.Alleged: SeatHandle\"]]","slots":["ko110","ko111"]},"result":"kp134"}],"vsc":["send","o-52",{"methargs":{"body":"#[\"makeNoEscrowSeat\",[{},{\"exit\":{\"onDemand\":null},\"give\":{},\"want\":{}},\"$0.Alleged: ExitObject\",\"$1.Alleged: SeatHandle\"]]","slots":["o+d11/1","o+d10/1"]},"result":"p+7"}],"time":1738634347.628174,"monotime":13.78046653}

Some searching for makeNoEscrowSeat reminded me that the contract makes some temporary seats with makeEmptySeatKit(), and if we don't .exit() such seats, they leak.

• fix(fast-usdc): .exit() all internal temporary seats #10939

[dckc]

Diagnosing VStorage Growth: test harness limitation

Initial measurements of vstorage were nowhere near flat either:

We diagnosed this as a limitation of the storage mock:

• test(internal): fake vstorage advance blockHeight #10933