[Load Testing] No extra upokt is minted, burnt or missing

[red-0ne]

Objective

Ensure that the tokenomics rules of the protocol correctly alter the actors balances.

Build confidence about how the TLMs are moving funds around actor and module account balances.

Goals

• Know where every upokt goes.
• Be in total control over funds mint, burn and movements.
• Ensure that in a long running process the actors balances are updated as expected.

Deliverables

• [ ] A single PR that:
  • [ ] Adds listeners to claim settlement events.
  • [ ] Have a condensed formula that calculates the expected actors balances after each settlement.
  • [ ] Ensure actual account balances are the same as the expected ones.
• [ ] Run and report results.

Non-goals / Non-deliverables

• Rewrite tokenomics logic.

General deliverables

• [ ] Comments: Add/update TODOs and comments alongside the source code so it is easier to follow.
• [ ] Testing: Add new tests (unit and/or E2E) to the test suite.
• [ ] Makefile: Add new targets to the Makefile to make the new functionality easier to use.
• [ ] Documentation: Update architectural or development READMEs; use mermaid diagrams where appropriate.

---

Creator: @red-0ne

[Olshansk]

cc @okdas - Why we need to enable load testing on LocalNet. Question: is it still blocked by our ability to use PATH instead of AppGateServer?

[Olshansk]

@red-0ne One additional element/idea to this ticket.

What if we just do a load test (thousands of suppliers, apps, services, etc...) where:

• Everyone has enough POKT to pay/supply services
• Everyone is honest (no slashing)
• Everyone is behaving well (no slashing)
• Inflation is set to 0

We should see:

• The total supply of POKT remain the same
• The total supply of POKT in account modules remain the same

Wdyt?

[okdas]

cc @okdas - Why we need to enable load testing on LocalNet. Question: is it still blocked by our ability to use PATH instead of AppGateServer?

Not blocked. We won't be able to proxy too many requests, but I think good enough volume. I've run a few tests already.

[red-0ne]

@Olshansk

What if we just do a load test (thousands of suppliers, apps, services, etc...) where:

The only problem lays in suppliers which are tied to relay miners that are resource provisioning intensive and are limited to 3 (cc @okdas)

We may be able to achieve it using lean clients :thinking:

Other than that, I see no blocker for a plan that scales those.

[red-0ne]

We won't be able to proxy too many requests, but I think good enough volume. I've run a few tests already.

@okdas is this related to what you're describing there ?https://discord.com/channels/824324475256438814/1300629445677416458/1300630681801457724

[Olshansk]

The only problem lays in suppliers which are tied to relay miners that are resource provisioning intensive and are limited to 3 (cc @okdas)

Where does this limitation come from?

That's the default configuration on main right now, but I don't think it should be hard to update it (with a bit of effort) unless I'm mistaken?

[Olshansk]

We may be able to achieve it using lean clients 🤔

Can you please provide more details on:

• What this solves?
• Why we can't do it without lean clients?

[Olshansk]

@red-0ne Dropping a note/idea here so I don't forget.

• Load test with inflation = 0 + burn = 0 : we should
• Load test with inflation = 0 + burn > 0: deflationary
• Load test with inflation > 0 + burn > 0: inflationary / deflationary based on circumstances

cc @RawthiL for visibility. We'll be using pocketdex alongside this and will likely need to build some necessary/cool/interesting charts. They'll all translate to Shannon.

Note: We'll need to turn this whole ticket/thread into a proper plan + design doc + blog post w/ clear requirements, visuals, etc

[red-0ne]

Just for context,

This will involve:

• Adding a TypedEventListener (that could help for the query client caching #543 task too).
• Past relay mining difficulty, At settlement, the mining difficulty used should be the one of the session at settlement and not the current session.