Skip to content
This repository has been archived by the owner on Jun 6, 2024. It is now read-only.

zkvm: capping blockchain validation cost #402

Open
oleganza opened this issue Feb 25, 2020 · 0 comments
Open

zkvm: capping blockchain validation cost #402

oleganza opened this issue Feb 25, 2020 · 0 comments
Labels
consensus Issues affecting consensus-level compatibility

Comments

@oleganza
Copy link
Contributor

oleganza commented Feb 25, 2020

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.

  1. Each mempool decides on the size limit of each individual transaction.
  2. Block commits to the total size of all included transactions in the BlockHeader and it is verified during block verification.
  3. 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).
@oleganza oleganza added the consensus Issues affecting consensus-level compatibility label May 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
consensus Issues affecting consensus-level compatibility
Projects
None yet
Development

No branches or pull requests

1 participant