What is the definition of proof size?

  • What factors influence the size of a proof?
  • What are the steps involved in calculating the proof size? (the benchmark performs various tasks, but it also conceals many details)
  • How can we determine the maximum acceptable proof size for a runtime?

1 Answer 1


What is the definition of proof size?

Proof size is the size, in bytes, required to be able to successfully execute a block of a parachain during the parachains protocol. This is commonly referred to as the PoV Size (Proof of Validity).

What factors influence the size of a proof?

The data accessed during a block will affect the size of a proof. Since the Polkadot relay chain re-executes each parachain block, it also needs the subset of the parachains storage merkle trie which corresponds to the transactions in the block. For example, if a block only had one transaction, which was a transfer from Alice to Bob, you would a merkle proof which contains Alice's and Bob's account balances, but none of the other users. Similarly, if your block executed some smart contract, you would need to include the bytes of that smart contract into the proof.

So the size of a proof is influenced by the logic of the block, and the storage that needs to be accessed by that block.

What are the steps involved in calculating the proof size? (the benchmark performs various tasks, but it also conceals many details)

As with all benchmarking, you must calculate the worst case scenario to prevent users from attacking your chain. In this case, all storage items in FRAME must have a MaxEncodedLength. That is, given any runtime storage object, there must be a maximum size of that storage. Because of this an unbounded Vec is not allowed, only BoundedVec, which has a maximum number of elements.

Given that all objects have a statically computable maximum encoded length, benchmarking can simply keep track of which storage items are touched during a benchmark, and then calculate the worst case size of that storage, and keep a sum of the total number of bytes accessed throughout the execution of a worst case scenario transaction.

Of course, this will normally be a huge overestimate, but will capture the worst case scenario, which is needed to see if a transaction could fit into the block in the worst case scenario. Fortunately, at the end of a transaction, we can see how large the proof size ACTUALLY is, and refund the unused proof size. In this case, we can deterministically figure out the size of the proof at any point, unlike traditional execution time weights.

So for example, imagine I benchmark a transfer function. I will be touching two storage items: Alice's account and Bob's account. The Account object, lets say is the following struct:

struct AccountObject {
    nonce: u32,
    balance: u128,
    name: BoundedVec<u8, 100>,

In this example, accounts may have a name which is a string of up to 100 bytes. So given this object, we know the MaxEncodedLen of the Account Object is 4 + 16 + 100 = 120 bytes. But the proof size isn't simply 120 x 2 = 240 bytes, it must be that plus the rest of the merkle proof, which includes all the nodes leading up to the merkle root.

FRAME benchmarking takes advantage of a database that keeps track of the proof size throughout the execution of a transaction to spit out a final value in bytes.

How can we determine the maximum acceptable proof size for a runtime?

The maximum PoV size is determined by the relay chain. This is currently configured to 5 MB.

  • What happens if a parachain just propagates all transactions to have zero Proof-of-Validty size? The relay chain validators would re-execute until the actual consumption of 5 MB is reached and then stop validating this block? Or would they throw away all transactions inside the block?
    – Chralt
    Commented Sep 18, 2023 at 13:42
  • 1
    A block must be fully executed to be valid, so any kind of "only partial execution" means the whole block would be dropped. In this case, the proof size is not "reported" by the parachain, but provided as a blob to the validators. As in, it is not possible for them to lie about the size of the proof. If a chain does not provide a full proof, then as soon as the validator tries to read some proof data which is not there, the block will be dropped.
    – Shawn Tabrizi
    Commented Sep 19, 2023 at 20:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.