Website documentation updates

[adaki2004]

This is a private issue - for now - to gather and update information which is published on the website/documentation but not up-to-date anymore.

1. Rate limiting using EIP-1559 section -> Diagram is somewhat OK in terms of 'rate limiting' indeed with the EIP1559 math, but i'm thinking if we should re-draw it a bit.. In general i'd say, maybe it is OK, i'll ask Brecht. --> Brecht said it is OK as is for now.

2. EIP-1559 powered prover fees section -> we dropped this concept. Maybe a good name is like: "Off-chain Proof Market" (or something like that)
   Instead of the EIP-1559 powered prover fees, this is the diagram (in excalidraw) - which i would use:
   https://discord.com/channels/984015101017346058/984087854839922731/1146091042207170621
   So basically, some notes to incorporate:

This section is OK, because it is a general description:

Proving blocks requires ...
..
4.The proof generation cost depends on how fast a proof needs to be generated.

I'd throw away the next 2 paragraphs and somewhat describe the current proving mechanisms and structure, which is:

• There is an off-chain proof market where the proposers would seek for possible proof service providers. (per block basis)
• There will be an exposed API to query the available providers off-chain
• Once there is a settlement off-chain (about the proving fee), the proof service provider has to grant the proposer a signature, with which it shows a commitment to prove that block in time.
  The proof service provider can be: EOA or contracts. (Pools). The criteria to be a Pool contract is: implement either the IProver interface (which we defined) or the IERC1271 (isValidSignature)
• So when the proposer proposes a block, this signature is verified. (Revert if not OK).
• Then, TKO is minted to the proposer (! not necessarily need to be part of this description i guess, just describing how it works) as an extra incentivizer as proposing blocks might not be profitable alone (if we deduct eth on-chain fees, and the proving fee)- this is based on an 'emission rate per second' compared to the last proposed block.
• In case it is an EOA account or the prover pool implements the IERC1271, the proof reward is ETH
• In case it is implementing the IProver interface, the prover fee can be ETH and any custom ERC20 (or even NFTs if that is in the deal.)
• To have an 'insurance' the Prover needs to pay a relative high amount of TKO (per block) to secure his/her intentions. If he/she fails to prove in time, 1/4 will be sent to the actual prover and 3/4 will be burnt, otherwise he gets it back.

3. Intrinsic validity check is not really correct:
   On protoocl level we do not check this:
   Cs​=TIMESTAMP (timestamp is correct)
   Cm=DIFFICULTYCm​=DIFFICULTY (mixHash is correct)

4. https://taiko.xyz/docs/concepts/proving
   Currently, any prover can create proofs for proposed blocks. This means that the number of "state transitions" 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 state transition (state transition) will receive the reward of TTKO.

4.1. The last state transition (state transition) i think is duplicated.
4.2. The reward is ETH not TKO anymore, and (possibly, theoretically any ERC20 or even NFTs if the Prover pool implementation favors it.)

5. Types of Provers incorrect (we have now Oracle proof only, no system)

6. Remove this point 4:
   "With anchoring, the block mapping function M (defined in the whitepaper) can be simplified to:"

7. Remove formulas/notation on that page.