From b5f246cb544584dd6321f3061a62eba4b9c2ed9c Mon Sep 17 00:00:00 2001 From: d1onys1us <13951458+d1onys1us@users.noreply.github.com> Date: Wed, 7 Jun 2023 16:05:26 +0200 Subject: [PATCH 1/2] feat(website): update proving docs --- .../website/pages/docs/concepts/_meta.json | 2 +- .../concepts/proving-taiko-blocks/_meta.json | 11 --- .../concepts/proving-taiko-blocks/provers.mdx | 1 - .../the-oracle-prover.mdx | 1 - .../verified-blocks-and-parallel-proving.mdx | 20 ------ .../website/pages/docs/concepts/proving.mdx | 71 +++++++++++++++++++ .../pages/docs/guides/enable-a-prover.mdx | 2 +- 7 files changed, 73 insertions(+), 35 deletions(-) delete mode 100644 packages/website/pages/docs/concepts/proving-taiko-blocks/_meta.json delete mode 100644 packages/website/pages/docs/concepts/proving-taiko-blocks/provers.mdx delete mode 100644 packages/website/pages/docs/concepts/proving-taiko-blocks/the-oracle-prover.mdx delete mode 100644 packages/website/pages/docs/concepts/proving-taiko-blocks/verified-blocks-and-parallel-proving.mdx create mode 100644 packages/website/pages/docs/concepts/proving.mdx diff --git a/packages/website/pages/docs/concepts/_meta.json b/packages/website/pages/docs/concepts/_meta.json index 25998bbb2d5..3a7076a2e7e 100644 --- a/packages/website/pages/docs/concepts/_meta.json +++ b/packages/website/pages/docs/concepts/_meta.json @@ -5,7 +5,7 @@ "creating-taiko-blocks": { "title": "Creating Taiko blocks" }, - "proving-taiko-blocks": { + "proving": { "title": "Proving Taiko blocks" }, "bridging": { diff --git a/packages/website/pages/docs/concepts/proving-taiko-blocks/_meta.json b/packages/website/pages/docs/concepts/proving-taiko-blocks/_meta.json deleted file mode 100644 index c74e1bd3c27..00000000000 --- a/packages/website/pages/docs/concepts/proving-taiko-blocks/_meta.json +++ /dev/null @@ -1,11 +0,0 @@ -{ - "provers": { - "title": "Provers" - }, - "the-oracle-prover": { - "title": "The oracle prover" - }, - "verified-blocks-and-parallel-proving": { - "title": "Verified blocks & parallel proving" - } -} diff --git a/packages/website/pages/docs/concepts/proving-taiko-blocks/provers.mdx b/packages/website/pages/docs/concepts/proving-taiko-blocks/provers.mdx deleted file mode 100644 index 6e0d3773759..00000000000 --- a/packages/website/pages/docs/concepts/proving-taiko-blocks/provers.mdx +++ /dev/null @@ -1 +0,0 @@ -The purpose of proving blocks is to allow bridges to withdraw state out of the rollup. To rely on some state that happened inside of the rollup, a bridge will want a proof that everything was done correctly. On Taiko you can [run a node as a prover](/docs/guides/run-a-node) and prove blocks, permissionlessly. This means that you can examine the proposed blocks on the TaikoL1 contract, and generate proofs for them. Currently, any prover can create proofs for proposed blocks. This means that the number of "fork choices" has no upper bound, because we don't know what is the correct state transition yet. Only first prover with a valid proof of the correct fork choice (state transition) will receive the reward of TTKO. diff --git a/packages/website/pages/docs/concepts/proving-taiko-blocks/the-oracle-prover.mdx b/packages/website/pages/docs/concepts/proving-taiko-blocks/the-oracle-prover.mdx deleted file mode 100644 index 7c75790b407..00000000000 --- a/packages/website/pages/docs/concepts/proving-taiko-blocks/the-oracle-prover.mdx +++ /dev/null @@ -1 +0,0 @@ -There is a concept of an oracle prover on Taiko, which will be removed when the circuits are complete and some rollup training wheels have been removed (such as DAO governance and multi-proofs). The oracle prover is a prover that is trusted to provide the correct state transition. If oracle proving is enabled, then the oracle prover will be forced as the first prover for a block and the second will be from a prover. The actual prover (one of you) however will receive the reward of course, this is just a safety mechanism we have in place while the ZK-EVM is still in development. diff --git a/packages/website/pages/docs/concepts/proving-taiko-blocks/verified-blocks-and-parallel-proving.mdx b/packages/website/pages/docs/concepts/proving-taiko-blocks/verified-blocks-and-parallel-proving.mdx deleted file mode 100644 index bcf9416167c..00000000000 --- a/packages/website/pages/docs/concepts/proving-taiko-blocks/verified-blocks-and-parallel-proving.mdx +++ /dev/null @@ -1,20 +0,0 @@ -There are three states that a block can be in on Taiko: -- Proposed -- Proved -- Verified - -We already know what a proposed block is (must pass at least the block-level intrinsic validity tests to be accepted by the TaikoL1 contract). Next, a proposed block can be valid or invalid, depending on whether it passes the transaction list intrinsic validity test. A block is invalid if it fails the transaction list intrinsic validity test, and this block is not created on Taiko. - -Now, a block can be proved, but also further "verified". What's the difference? A block is proved if it has a valid proof which proves a state transition from one state (parent block) to another (current block). However, blocks are proven in parallel by the decentralized provers. So while a block can prove a parent block transitions to the current block, we don't know if the parent block itself has been proven. As you can see, for a block to be "verified", it needs to prove the valid state transition to the current block, but the parent also need to be verified. We assume that the genesis block (which has no parent), is verified. So all the children blocks from genesis to the current block need to have proofs of their state transition for the current block to be "verified". - -For the visual learners here is a visualization of the three stages (proposed -> proved -> verified) - -**Proposed:** -![Proposed](/images/diagrams/concepts/proving-taiko-blocks/proposed.png) - -**Proved:** -![Proved](/images/diagrams/concepts/proving-taiko-blocks/proved.png) - -**Verified:** -![Verified](/images/diagrams/concepts/proving-taiko-blocks/verified.png) - diff --git a/packages/website/pages/docs/concepts/proving.mdx b/packages/website/pages/docs/concepts/proving.mdx new file mode 100644 index 00000000000..9687f6bcc08 --- /dev/null +++ b/packages/website/pages/docs/concepts/proving.mdx @@ -0,0 +1,71 @@ +import Image from "next/image"; + +# Proving Taiko blocks + +## Overview +The purpose of proving blocks is to give certainty to bridges about the execution that happened in the rollup. To rely on some state that happened inside of the rollup, a bridge will want a proof that everything was done correctly. On Taiko you can run a node as a prover and prove blocks, permissionlessly. This means that you can examine the proposed blocks on the TaikoL1 contract, and generate proofs for them. Currently, any prover can create proofs for proposed blocks. This means that the number of "fork choices" has no upper bound, because we don't know what is the correct state transition yet. Only first prover with a valid proof of the correct fork choice (state transition) will receive the reward of TTKO. + +## Verified blocks and parallel proving +There are three states that a block can be in on Taiko: +- Proposed +- Proved +- Verified + +We already know what a proposed block is (must pass at least the block-level intrinsic validity tests to be accepted by the TaikoL1 contract). Next, a proposed block can be valid or invalid, depending on whether it passes the transaction list intrinsic validity test. A block is invalid if it fails the transaction list intrinsic validity test, and this block is not created on Taiko. + +Now, a block can be proved, but also further "verified". What's the difference? A block is proved if it has a valid proof which proves a state transition from one state (parent block) to another (current block). However, blocks are proven in parallel by the decentralized provers. So while a block can prove a parent block transitions to the current block, we don't know if the parent block itself has been proven. As you can see, for a block to be "verified", it needs to prove the valid state transition to the current block, but the parent also need to be verified. We assume that the genesis block (which has no parent), is verified. So all the children blocks from genesis to the current block need to have proofs of their state transition for the current block to be "verified". + +For the visual learners here is a visualization of the three stages (proposed -> proved -> verified) + +**Proposed:** +
+ proposed +
+**Proved:** +
+ proved +
+**Verified:** +
+ verified +
+ +## Types of provers +### Community prover + +Currently, you only need a single proof from the any prover to verify a block. + +### Oracle prover + +The oracle prover is a prover from a unique address (our own address) that is able to override the community prover. This is a safety mechanism we have in place while the ZK-EVM is still in development and in case an invalid block was marked as verified from a community proof. + +### System proof + +A system proof is a fake proof that is generated by the system to mark a block as verified. We only require a real proof to be generated every N blocks. Otherwise, we accept a fake, system proof, and mark the block as verified. This is a temporary testnet feature to reduce the cost for community provers. + +### The proof cooldown period + +We have a proof cooldown period which is an interval of time we set after fully verifying a block. The reason we do that is to allow for a fault proof to come in, once we have a multi-prover system set in place. + + +## Prover dynamics + +### How the proof reward is determined + +A proof reward in TTKO is rewarded for successfully proving a block. This reward is dependent on the `proofTimeTarget`. You can see the current proof reward by calling `getProofReward` on the TaikoL1 contract. + +So that we don't grow a long list of unverified blocks for too long, we want to target proofs coming in at a certain rate. So we set a target proof time. If it has taken a long time since the last verified block, the proof reward increases to incentivize provers to generate a proof. + +Conversely, if everyone is submitting proofs quickly, then the proof reward decreases towards zero. This means that as a prover, you should query `getProofReward` on the TaikoL1 contract to determine if it is profitable to generate a proof. If you submit proofs as quickly as possible, then the proof reward will trend towards zero. + +### Default in simple-taiko-node + +The [simple-taiko-node](https://github.com/taikoxyz/simple-taiko-node) will come pre-configured to not submit proofs as quickly as possible, by querying `getProofReward`. This hopefully means that most nodes in the network are acting in the group interest, by responsibly not submitting the proof as quickly as possible. However, because the first prover will win the reward, and because the project is open source, anybody can modify the [taiko-client](https://github.com/taikoxyz/taiko-client) and act rationally to submit a proof slightly earlier than the default set in `simple-taiko-node`. As you can see, it causes somewhat of a prisoner's dilemma. + +### Proof skip + +We have a `realProofSkipSize` set [here](https://github.com/taikoxyz/taiko-mono/blob/main/packages/protocol/contracts/L1/TaikoConfig.sol#LL40C13-L40C30) so that a real proof is only needed every N blocks for the testnet. + +### Your role as a prover + +We are describing this dynamic so you can be informed when you run a prover. It's very possible that without the correct strategy, you will not be profitable as a prover. You are naturally competing in an open space where others could have more efficient hardware and generate a proof in a short amount of time that you cannot compete against. \ No newline at end of file diff --git a/packages/website/pages/docs/guides/enable-a-prover.mdx b/packages/website/pages/docs/guides/enable-a-prover.mdx index b56d5203464..b70e73a541b 100644 --- a/packages/website/pages/docs/guides/enable-a-prover.mdx +++ b/packages/website/pages/docs/guides/enable-a-prover.mdx @@ -3,7 +3,7 @@ import { Callout, Steps } from "nextra-theme-docs"; # Enable a prover - Only the first prover can get the reward, and others will be rejected by the protocol smart contract. This means the fastest prover will be able to prove the block and earn the reward, **if you have just the minimum hardware outlined in the prerequisited below, running a single prover, it's unlikely you will be able to prove any blocks (because you will be competing against other high-performance provers)**. +Only the first prover can earn the TTKO reward, and others will be rejected by the protocol smart contract. This means the fastest prover will be able to prove the block and earn the reward, **if you have just the minimum hardware outlined in the prerequisited below, running a single prover, it's unlikely you will be able to prove any blocks (because you will be competing against other high-performance provers)**. Meaning, if you do not have a powerful prover, the primary purpose of running a prover is to help test out and provide community feedback on running the node software. Keep in mind this will have a cost in electricity on your computer, and if you are not proving blocks, it's unlikely you will receive a reward to offset that electricity cost. From 2d7f6fa94c0628f95eeb63a0ff5e25760893d322 Mon Sep 17 00:00:00 2001 From: d1onys1us <13951458+d1onys1us@users.noreply.github.com> Date: Wed, 7 Jun 2023 16:06:36 +0200 Subject: [PATCH 2/2] feat(website): update proving docs --- packages/website/pages/docs/guides/enable-a-prover.mdx | 2 ++ 1 file changed, 2 insertions(+) diff --git a/packages/website/pages/docs/guides/enable-a-prover.mdx b/packages/website/pages/docs/guides/enable-a-prover.mdx index b70e73a541b..d3988c7c47c 100644 --- a/packages/website/pages/docs/guides/enable-a-prover.mdx +++ b/packages/website/pages/docs/guides/enable-a-prover.mdx @@ -6,6 +6,8 @@ import { Callout, Steps } from "nextra-theme-docs"; Only the first prover can earn the TTKO reward, and others will be rejected by the protocol smart contract. This means the fastest prover will be able to prove the block and earn the reward, **if you have just the minimum hardware outlined in the prerequisited below, running a single prover, it's unlikely you will be able to prove any blocks (because you will be competing against other high-performance provers)**. Meaning, if you do not have a powerful prover, the primary purpose of running a prover is to help test out and provide community feedback on running the node software. Keep in mind this will have a cost in electricity on your computer, and if you are not proving blocks, it's unlikely you will receive a reward to offset that electricity cost. + +Please see [How the proof reward is determined](/docs/concepts/proving#how-the-proof-reward-is-determined) for more details. ## Overview