Pragmatic approach to solve UCG

[PaulRBerg]

Proposal

It's time to roll up our sleeves (see what I did here?), implement the streaming opcodes, and test the heck out of them on AWS, Hetzner, or other such hosting solutions.

An actual implementation would provide us with the ability to benchmark stuff. We would be able to estimate how the computational load grows, whether blocks are still being produced, DoS resistance, and more.

No Silver Bullet

There isn't any silver bullet for UCG. We are faced with a multi-faceted problem that requires us to draw on multiple fields: computer science, mathematics, economics, and blockchain design.

Potpourri of Solutions

Ordered from most to least impactful. I am confident that all of these combined will lead us onto the right track.

• Lazy Evaluation: We don't traverse the entire subgraph. We only look at users with transactions in the current block.
• Graph Optimization: As explained here, we will prune and split the graph by having two types of nodes storing an Optimized State and a Raw State.
• Topological restrictions
  • Restricted cadences. As discussed in Cadence for streaming opcodes #84, we will allow only certain cadences such as by-the-second, minute, hour, etc.
  • Discrete amounts: As discussed here, only certain amounts will be streamable, e.g. 1 USDC, not 1.01 USDC
  • Minimum stream amounts: Values below a certain threshold will not be allowed (to minimize spam).
• Processing limits: We will enforce an arbitrary cap on how large subgraphs can get (related: bad UX for cross-intersecting users).
• Batch Updates: zkSync-style bootloader architecture to run the entire set of transactions/ blocks as a single block to net out state changes.
• Transaction Prioritization: Minimize congestion by prioritizing txs that decompose subgraphs, or txs with a lesser computational load.
• Gas Refunds: Offer gas refunds for users who decompose subgraphs (as mentioned here).

Fallbacks

In the worst-case scenario, if our benchmarks prove to us that there's too much UCG, we can fall back to the following approaches:

1. Require powerful machine requirements (Solana's playbook)
2. Superfluid-style TOGA without liquidation fees (I am due to write a separate discussion about this)

RFC

CC @sablier-labs/sabvm