Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(protocol): need one real ZKP every N blocks #13673

Merged
merged 4 commits into from
Apr 28, 2023

Conversation

dantaik
Copy link
Contributor

@dantaik dantaik commented Apr 28, 2023

To reduce the prover cost of testnets, a new config realProofSkipSize is introduced, assuming it's 10, then we only need real ZKP every 10 blocks (block 10, 20, ....). For other blocks, the oracle provers will be considered as the real ZKP and will allow those blocks to be verified.

@davidtaikocha this may affect the prover code.

@dantaik dantaik marked this pull request as ready for review April 28, 2023 04:22
@dantaik dantaik self-assigned this Apr 28, 2023
@cyberhorsey
Copy link
Contributor

client matching PR:
taikoxyz/taiko-client#198

@davidtaikocha davidtaikocha merged commit 7bf8e01 into major_protocol_upgrade_alpha3 Apr 28, 2023
@davidtaikocha davidtaikocha deleted the real_proof_every_n_block branch April 28, 2023 06:21
// For this block, real ZKP is not necessary, so the oracle
// proof will be treated as a real proof (by setting the prover
// to a non-zero value)
evidence.prover = address(1);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adaki2004 I should have let you review this change, as it may impact the tokenomics? if 90% of blocks's the proof times are very short, like 12-60 seconds, will the tokenomics still work?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, the mechanics heavily depends on the proof time. In case we will be able to find a good parameter (kinda average) it could work yes!
Depends also what is the difference between 'real' proof time?
30 minutes vs. the dummy ones (12-60s) ? If so, it might be very tricky to make it work. If the diff is not that drastic, i assume we need to find the sweet spot (=very close to the average).
Soon pushing the simulation code, you can try, but obviously it does not have this scenario possible. (Can try to incorporate tho next week to see how it behaves within these new circumstences)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason not to submit these at the expected proof time? It's only for testnets so seems good enough even if we could manipulate the prover fee.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can certain try to submit these proofs with a roughly average proof delay, but I just want to understand the nature of the impact of such a really small proof delay.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If most proofs keep being submitted below the target time the prover fee/reward will go to zero (except if the actual proof being submitted is a LOT longer than the target time to try and keep in balance somehow, but that would be very suboptimal)

Copy link
Contributor

@adaki2004 adaki2004 Apr 29, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See simulation results here:
#13657 (comment)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@davidtaikocha please make sure you don't submit these oracle proofs too soon!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dantaik It can come quick but would be good to have them as 'strictly' automated as possible so that we can calculate the rest properly (e.g.: every 10th block comes somewhere 1-2mins)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

5 participants