[Dev Fund] canton-stress — load, contention and cost testing for Canton apps (public, listed on the Developer Hub) — seeking a SIG champion

Hello team,

I have been measuring how Canton applications behave under load and I’d like to find the right home for it before taking it further. Some of you will know me from daml-fuzz. This is separate work and I won’t file anything for it until that proposal has been decided.

On scope, up front: this is not protocol, synchronizer or node performance. That belongs to Digital Asset. I mean the layer above: whether a given registry, wallet or settlement app is fast enough, what limits it and what it costs to run.

The tool is public (Apache-2.0) and was recently accepted into the Canton Developer Hub catalogue under Smart Contract Dev:

github.com

Point it at a DAR and it runs:

node src/cli.ts <your.dar> --java-home <jdk> --traffic-price 60

For a Token Standard registry there is nothing to configure. It finds the Holding and TransferFactory templates, generates test holdings, boots a sandbox and reports throughput, which contract lost each race, the size and price of each transaction and what to change. For other Daml apps it generates a starting workload from the DAR’s own dependency graph and lists what it couldn’t infer instead of guessing.

Two results so far, both measured against third-party code as well as my own.

The first is that contention on a token registry follows a simple rule. A wallet picking input holdings at random mostly doesn’t collide with other people. It collides with holdings it has already spent. The failure rate comes out at about half the fraction of the pool consumed over a run:

contention ~= f / 2      where f = holdings spent / pool size

I wrote the predictions down before the runs. Across an eightfold range of pool depth they held to about two percentage points and raising concurrency fourfold moved the result by less than one, so it’s a bookkeeping effect rather than a concurrency effect. For transfers that gather several inputs it becomes geometric rather than linear, because a transfer fails if any one of its inputs is stale. It’s also avoidable: giving each in-flight submission a distinct input removed contention at every concurrency I tried and committed 240 of 240
transfers against 208, with no latency cost.

The second is that the same harness can put a price on a design decision.

Comparing two independent registries doing the same standard transfer, the settlement model turned out to be the expensive choice and the data model didn’t. A completed propose/accept transfer, counting both transactions since the receiver has to accept, comes to 26,220 bytes against 15,689 for a preapproved direct one. That’s about $0.60 more per transfer at $60/MB, or 67% and the gap grows with volume because a preapproval is created once per receiver while an acceptance is paid every time. The two data models differ by 287 bytes, under 2% and the richer one is the smaller. Stakeholder count adds cost linearly on top of that. These sizes are byte-identical from run to run, so they don’t need a large sample to be trusted.

What I’m asking for

I’ve written this up as a Development Fund proposal. It fits the Dev Fund 2.0
RFP on SDLC integration (testing frameworks and CI). As an external contributor
I need a Tech & Ops Committee champion before it can be filed, so I’m asking
here first rather than filing and having it closed unread.

1. Is this useful, or am I answering a question nobody is asking? I mean that literally. The contention rule matters most for parties that hold a lot: treasuries, venues, registries. It matters much less for ordinary wallets. I only learned that from someone with production data who told me so.
2. Which SIG owns it? Daml Tooling, Tokenomics and Token Standards all seem arguable and I’d rather be steered than pick.
3. Is anyone already doing this? If it overlaps work already underway, I’d rather contribute to that than run alongside it.
4. Would your team try it? I’m looking for two or three teams with a registry, wallet or app heading for MainNet who would run it once before a release, or gate their CI on cost per transaction. If you’d rather not set it up, send me a DAR and I’ll send back the report privately.

If someone on the Canton team thinks this belongs in the ecosystem’s tooling and is willing to champion it, I’ll send the proposal. If the answer is that it isn’t needed, that’s useful to know too.

Kind regards,

dfrnw