spike for load testing Fast USDC

[turadg]

What is the Problem Being Solved?

Fast USDC has performance requirements. We need to gain confidence early in development that the end result will meet them.

Description of the Design

Draft how do we measure throughput at peak and sustained early

Prototype load testing ability

Security Considerations

Scaling Considerations

Test Plan

Upgrade Considerations

[LuqiPan]

Update: @toliaqat has given us the go-ahead for @dckc to pair with @gibson042 to spike on this

[dckc]

not exactly the same scope as this, but overlapping:

• SPIKE: prototype participants in Fast USDC sequence diagram #10254

[dckc]

fe1619a has some notes from an Oct 15 chat w/ @gibson042

We talked about a starting point:

1. Deterministic: How many Fast-USDC customers can we serve within the computron limit of a block?

Connecting this with wall-clock time is notoriously tricky:

• computron limit failed to keep swingset compute time in wall-clock bounds #6857

But one approach is:

2. Hardware-dependent: How does the wall-clock time filled with Fast-USDC work compare to the wall-clock time of another full block without Fast-USDC work? (for example, a block full of PSM or Vaults work).

[dckc]

I discovered that we have some historical data on CCTP usage. I'm inclined to deploy the prototype in #10254 in a running chain and simulate a watcher that acts like the historical usage.