feat(website): update proving docs (#13915)

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": {

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:**
+<center>
+    <Image src="/images/diagrams/concepts/proving-taiko-blocks/proposed.png" alt="proposed" width={400} height={400} />
+</center>
+**Proved:**
+<center>
+    <Image src="/images/diagrams/concepts/proving-taiko-blocks/proved.png" alt="proved" width={400} height={400} />
+</center>
+**Verified:**
+<center>
+    <Image src="/images/diagrams/concepts/proving-taiko-blocks/verified.png" alt="verified" width={400} height={400} />
+</center>
+
+## 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.

packages/website/pages/docs/guides/enable-a-prover.mdx

@@ -3,9 +3,11 @@ import { Callout, Steps } from "nextra-theme-docs";
 # Enable a prover
 
 <Callout>
- 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.
+
+Please see [How the proof reward is determined](/docs/concepts/proving#how-the-proof-reward-is-determined) for more details.
 </Callout>
 
 ## Overview