The cost of validating a ZkVM blockchain consists of relaying and validating transactions. Relay cost is proportional to the size of the transaction, while validation cost is proportional to the number of multipliers used by the R1CS proof.
While R1CS proof size is logarithmic in number of multipliers, the validation cost is still reflected in the size of the program. This is because multipliers count is mostly affected by the outputs, and every output requires at least 96 bytes of data.
However, each transaction needs Bulletproofs generators prepared before the proof is verified. With the current Bulletproofs API we can begin constructing a verification CS, call Verifier::multipliers_len and do BulletproofGens::increase_capacity accordingly and then finish with Verifier::verify.
Given the above, we can simply cap transactions by their encoded size, which is a good proxy for the total validation cost.
Each mempool decides on the size limit of each individual transaction.
Block commits to the total size of all included transactions in the BlockHeader and it is verified during block verification.
Block's commitment is verified separately against some global limit. Either against a built-in limit ("1Mb should be enough for anybody" as in Bitcoin), or a network-agreed parameter ("validators/miners vote", as in Stellar), or some gradually-growing number to account for future network improvements ("17.7% per year", as in BIP103).
The cost of validating a ZkVM blockchain consists of relaying and validating transactions. Relay cost is proportional to the size of the transaction, while validation cost is proportional to the number of multipliers used by the R1CS proof.
While R1CS proof size is logarithmic in number of multipliers, the validation cost is still reflected in the size of the program. This is because multipliers count is mostly affected by the outputs, and every output requires at least 96 bytes of data.
However, each transaction needs Bulletproofs generators prepared before the proof is verified. With the current Bulletproofs API we can begin constructing a verification CS, call
Verifier::multipliers_len
and doBulletproofGens::increase_capacity
accordingly and then finish withVerifier::verify
.Given the above, we can simply cap transactions by their encoded size, which is a good proxy for the total validation cost.