Enhancing TPS with stateless transaction validation

Tech Talk
1

Polkadot’s scalability model inherently supports horizontal scaling by adding more parachains. While this reduces the immediate need for TPS improvements on individual chains, optimizing the scalability of individual networks within Polkadot’s ecosystem remains important, given their independent state structures.

Currently, to execute a block, every transaction within the block undergoes a validation and preparation process through TransactionExtensions. This validation phase can be categorized into two types:

  1. On-chain state-dependent validation: Requires access to the state.
  2. Stateless (or context-free) validation: Does not depend on the state.

A prime example of stateless validation is signature verification, which relies solely on the message and digital signature embedded within the transaction. As this verification is independent of transaction correctness and order, it is inherently suitable for parallel processing.

Proposed Solution

I propose introducing a stateless validation API (to perform validation in a stateless context) or a flag (to mark entire extension validation as stateless) within TransactionExtension. Stateless extensions could be pre-validated in a separate process, and a block passing pre-validation would transition into a CheckedBlock or PreValidatedBlock, bypassing redundant checks during block execution. This would optimize the execution process and potentially improve TPS.

Next Steps

If the community finds this proposal valuable, I would be glad to contribute to its implementation and help design the necessary changes within Polkadot SDK.

I welcome your feedback and look forward to discussing this further!

3 Likes
2

The bottleneck for parachains is the relay chain verification of PoVs. There is not that much of things you can check in before to make the block verification faster, at least by pre-validating something. What could be done is to batch verify the signatures in a PoV. What makes this a little bit more complicated is that one parachain supports different kind of signing methods, so the speedup is maybe not that great.

The first step here should be to write some benchmark that does some verification of different kinds of signatures in batch and without a batch to see the potential speedup. Maybe just taking some simple transfer calls as transaction.

1 Like
3

This sounds like it might be getting close to (but not quite at) Sui’s address owned objects, which they allow to bypass consensus.

Have you studied the Sui model and their implementation?

Would this proposal mean that such “stateless” extensions could ever bypass consensus?

If not it will be worthwhile spending some time documenting the sense in which a (pseudo-?) “stateless” extension still needs validation - if nothing else it will be a bridge for Sui developers moving to Substrate based chains.

Related?:

1 Like