🐬gid_bd928 retweetledi
With the Toccata fork upcoming, @p4bpj asked - "What would a "normal transaction versus stark-proof." look like?
@michaelsuttonil broke it down in his typical brilliant fashion!
We like to try visualize and contextualize. We recognize these illustration often are not perfect, but we wanted to offer a more commoner kick at this.
So, here goes...Picture a #Kaspa block like a delivery truck.
Every block has two limits:
1. How much weight it can carry (compute mass)
2. How much space is inside (byte size)
Today, normal transactions are like small boxes with heavy locks on them.
Each lock is a signature, and those signatures are expensive in weight. So the truck fills up by weight before it runs out of space. That’s why we land around a few hundred typical transactions per block.
The #Toccata update makes the truck bigger in terms of space. More room inside.
But the weight limit stays the same. So normal transactions still hit the same ceiling.
Now introduce a STARK proof.
Instead of hundreds of small boxes, you load one large crate.
It takes up a lot of space
It uses a meaningful portion of the weight
But it still fits within both limits
And inside that crate is something different.
It’s a proof that many actions already happened correctly.
The network doesn’t have to re-do all that work.
It just checks the proof.
What this means
For simple payments, nothing changes.
You still send and receive the same way.
What changes is what a transaction can represent.
Instead of one action per inclusion, a single transaction can carry a fully verified outcome of many actions.
The network verifies the result instead of replaying every step.
That shows up as:
- Fewer steps to reach finality
- More happening behind a single confirmation
- Greater confidence that what you’re seeing is already resolved
And this extends beyond simple transfers.
Where systems generate large volumes of activity, this model allows that activity to be batched, proven, and anchored ONCE.
Enterprise infrastructure
Large event streams, logistics, energy, telecom, identity systems could aggregate activity and settle a single verified state.
Banks and financial systems
Payments, clearing, and position updates could be grouped into provable batches, where correctness is established before settlement and then verified on-chain.
Large corporations
Internal systems, supply chains, and audits could produce verifiable state commitments, reducing the need to reconcile thousands of individual records.
AI systems
Computation-heavy processes could commit results as proofs, allowing outcomes to be verified without exposing or replaying all intermediate steps.
Different domains. Same pattern.
Same system. Same limits. More settled per block.
Michael Sutton@michaelsuttonil
Normal transactions are dominated by sig cost (1000 compute gram per sig, where 500k is the compute mass block limit -> max 500 sigs per block). Compute mass also counts byte size (1 gram per byte), so 500 sigs are unrealistic, hence the known ~300 txs per block number. It assumes 300 1:2 txs (1 in, 2 outs) with minimal size. Increasing the block *byte-size* limit (aka transient mass) from 125kb to 250kb means that you are still constrained with 300 typical txs but they can carry more data (eg in their payload) a stark proof on the other hand, costs 250 sigops + ~225kb in size. so compute mass is at least 250*1000 + 225kb = 475kg ~< 500kg compute mass limit and raw size is, as said, 225kb so it’s still bellow the transient mass limit
English
