Merge branch 'bridge_eth' of https://github.com/taikoxyz/taiko-mono i…

…nto bridge_eth

packages/protocol/contracts/L1/TaikoEvents.sol

@@ -51,7 +51,7 @@ abstract contract TaikoEvents {
     /// @param proofTimeTarget The target time of proof generation
     /// @param proofTimeIssued The actual time of proof generation
     /// @param blockFee The fee associated with the proposed block
-    /// @param adjustmentQuotient The quotient used for adjusting future 
+    /// @param adjustmentQuotient The quotient used for adjusting future
     /// proof generation time to the target time
     event ProofParamsChanged(
         uint64 proofTimeTarget,

packages/website/pages/docs/concepts/overview.mdx

@@ -1,16 +1,107 @@
+import Image from "next/image";
+
 # What is Taiko?
 
-Taiko aims to build a secure, decentralized, and permissionless [rollup](https://www.youtube.com/watch?v=7pWxCklcNsU) on Ethereum. These requirements dictate the following properties:
+Taiko is a secure, decentralized, and permissionless [rollup](https://www.youtube.com/watch?v=7pWxCklcNsU) on Ethereum. Taiko achieves this by:
 
-1. All block data required to reconstruct the post-block state needs to be put on Ethereum so it is publicly available. If this would not be the case, Taiko would not only fail to be a rollup but would also fail to be fully decentralized. This data is required so that anyone can know the latest chain state and so that useful new blocks can be appended to the chain. For the decentralization of the proof generation Taiko requires an even stronger requirement: all block data needed to be able to re-execute all work in a block in a step-by-step fashion needs to be made public. This makes it possible for provers to generate a proof for a block using only publicly known data.
-2. Creating and proposing blocks should be a fast and efficient process. Anyone should be able to add blocks to the chain on a level playing field, having access to the same chain data at all times. Proposers, of course, should be able to compete on e.g. transaction fees and [Maximal Extractable Value (MEV)](https://ethereum.org/en/developers/docs/mev/).
+1. writing all block data required to reconstruct the post-block state to Ethereum. Recording block data to Ethereum as an L1 makes the data decentralized and public. This data is needed for everyone to know the latest chain state to add new blocks to Taiko. Taiko's proof generation requires an even stricter requirement: all executable data must be saved publicly in sequence. Consequently, provers can generate proofs for a block using only publicly known data.
+2. creating and proposing blocks should be a fast and efficient process. Anyone should be able to add blocks to the chain on a level playing field, having access to the same chain data at all times. Proposers, of course, should be able to compete on e.g., transaction fees and [Maximal Extractable Value (MEV)](https://ethereum.org/en/developers/docs/mev/).
 
-We achieve this by splitting the block submission process in two parts:
+We achieve this by splitting the block submission process into two parts:
 
 ## Block proposal
 
-When a block gets proposed the block data is published on Ethereum and the block is appended to the proposed blocks list stored in the [TaikoL1](/docs/reference/contract-documentation/L1/TaikoL1) contract. Once registered, the protocol ensures that _all_ block properties are immutable. This makes the block execution _deterministic_: the post-block state can now be calculated by anyone. As such, the block is immediately _verified_. This also ensures that no one knows more about the latest state than anyone else, as that would create an unfair advantage.
+When a block gets proposed, the block data is published on Ethereum, and the block is appended to the proposed blocks list stored in the [TaikoL1](/docs/reference/contract-documentation/L1/TaikoL1) contract. Once registered, the protocol ensures that _all_ block properties are immutable. This makes the block execution _deterministic_: the post-block state can now be calculated by anyone. As such, the block is immediately _verified_. This also ensures that no one knows more about the latest state than anyone else, which would create an unfair advantage.
 
 ## Block verification
 
 Because the block should already be verified once proposed, it should _not_ be possible for the prover to have any impact on how the block is executed and what the post-block state is. All relevant inputs for the proof generation are verified on L1 directly or indirectly to achieve deterministic block transitions. As all proposed blocks are deterministic, they can be proven in parallel, because all intermediate states between blocks are known and unique. Once a proof is submitted for the block and its parent block, we call the block _on-chain verified_.
+
+## The L2 block space
+
+Although block space is much
+cheaper than on L1, it is still necessary to adjust
+its price in a way to avoid L2 space being abused.
+EIP-1559 on Taiko dynamically adjusts the block space price.
+
+## Rate Limiting using EIP-1559
+
+Although rollups can have significantly
+higher network capacity than L1s,
+this capacity is not without limit. As such the protocol
+needs to be able to limit how much work the L2 network
+needs to do to keep up with the tip of the chain. Ethereum
+already has a mechanism in place to do just that with
+that we can use as well.
+
+<center>
+  <Image
+    src="/images/diagrams/concepts/eip-1559/fee-layout.png"
+    alt="proposed"
+    width={1200}
+    height={500}
+  />
+</center>
+At block proposal we keep track of how much work (measured in gas) is required to
+process the block, while subtracting the amount of work the Taiko network can handle.
+This effectively creates a market for network capacity (in gas) per ETH. This will
+impact how expensive Taiko block space is (paid by the block proposer), the higher
+the demand the higher the network fee (a fee paid to the Taiko DAO). This way, rate
+limiting is achieved in a way that does not simply impose a hard and inefficient
+cap on the network, instead this mechanism allows users to utilize the network in
+a fair way while allowing the Taiko network to capture the created value. And because
+the same mechanism is used on Ethereum it allows Taiko to be Ethereum equivalent
+(with some small implementation detail changes) even for this part of its network,
+which is not obviously the case for L2s.
+
+## EIP-1559 Powered Prover fees
+
+Proving blocks requires significant compute power to calculate the proof
+to submit and verify the proof on Ethereum. Provers need
+to be compensated for this work as the network needs to
+attract provers that are willing to do this work. How much
+to pay for a proof is not obvious however:
+
+1. The Ethereum gas cost to publish/verify a proof
+   on Ethereum is unpredictable.
+2. The proof generation cost does not necessarily
+   match perfectly with the gas cost.
+3. The proof generation cost keeps changing as proving software is optimized and the hardware used
+   gets faster and cheaper.
+4. The proof generation cost depends on how fast a
+   proof needs to be generated.
+
+Because the proving cost impacts the transaction fees
+paid by the users, the goal is to pay only as much as
+required for the network to function well. This means not
+underpaying provers because blocks may remain unproven,
+but certainly also not overpaying provers so that it doesn’t
+make sense to incur very high costs to try and generate
+proofs as quickly as absolutely possible. A good balance is
+key to a well working solution that takes into account the
+needs of the different network participants.
+It’s clear that a fixed proving fee does not work. The
+protocol should also not be dependent on a single prover
+for a block because this will put too much power in the
+hands of a single entity that can impact the stable progress
+of the chain.
+
+The network, somehow, has to find the correct price between
+two resources where the demand/supply is ever changing.
+We can model this problem as a market between the proving
+fee (per gas) per proof delay (per time unit), striking
+a dynamic balance between proving cost and proof delay.
+An additional complication is that the protocol expects
+the block proposer to pay the proving fee at block proposal
+time. As such, the baseFee of this model is used to charge
+the proposer of a block using the total gas used in the block.
+This is only an estimate of the actual cost because the
+actual cost is only known when the proof is submitted. If
+the estimated cost was too high the difference is returned
+to the block proposer and the baseFee is decreased. If
+the estimated cost was too low extra Taiko tokens are
+minted to make up the difference and the baseFee is
+increased. To lower the chance that the estimated cost is too
+low and extra Taiko tokens need to be minted, a slightly
+higher baseFee can be charged to the proposer than the
+one predicted by the model.

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

@@ -47,7 +47,7 @@ To stake your TTKOe try using the [staking dashboard](https://staking.l3test.tai
 Verify you have some prover logs:
 
 - `💰 Your block proof was accepted` means you are the first prover and receive the reward.
-- `✅ Valid block proven` just means a proposed block was successfully proved on TaikoL1 (by anyone).
+- `✅ Block proven` just means a proposed block was successfully proved on TaikoL1 (by anyone).
 
 If you are running a node in the background, you can view the logs with `docker compose logs -f`.
 

packages/website/pages/docs/manuals/node-runner-manuals.mdx

@@ -0,0 +1,6 @@
+# Node runner manuals
+
+These manuals list commonly used commands for node operation and troubleshooting. To setup a node, see the [Guides](/docs/guides).
+
+- [Grimsvotn L2 node runner manual](/docs/manuals/node-runner-manuals/grimsvotn-l2-node-runner-manual)
+- [Eldfell L3 node runner manual](/docs/manuals/node-runner-manuals/grimsvotn-l2-node-runner-manual)

packages/website/pages/docs/manuals/node-runner-manuals/eldfell-l3-node-runner-manual.mdx

@@ -39,29 +39,29 @@ docker compose -f ./docker-compose.l3.yml --env-file .env.l3 logs -f
 ## View execution logs
 
 ```sh
-docker compose -f ./docker-compose.l3.yml --env-file .env.l3 logs -f l2_execution_engine
+docker compose -f ./docker-compose.l3.yml --env-file .env.l3 logs -f l3_execution_engine
 ```
 
 ## View client driver logs
 
 ```sh
-docker compose -f ./docker-compose.l3.yml --env-file .env.l3 logs -f taiko_client_driver
+docker compose -f ./docker-compose.l3.yml --env-file .env.l3 logs -f l3_taiko_client_driver
 ```
 
 ## View client proposer logs
 
 ```sh
-docker compose -f ./docker-compose.l3.yml --env-file .env.l3 logs -f taiko_client_proposer
+docker compose -f ./docker-compose.l3.yml --env-file .env.l3 logs -f l3_taiko_client_proposer
 ```
 
 ## View client prover relayer logs
 
 ```sh
-docker compose -f ./docker-compose.l3.yml --env-file .env.l3 logs -f taiko_client_prover_relayer
+docker compose -f ./docker-compose.l3.yml --env-file .env.l3 logs -f l3_taiko_client_prover_relayer
 ```
 
 ## View zkevm prover logs
 
 ```sh
-docker compose -f ./docker-compose.l3.yml --env-file .env.l3 logs -f zkevm-chain-prover-rpcd
+docker compose -f ./docker-compose.l3.yml --env-file .env.l3 logs -f l3_zkevm_chain_prover_rpcd
 ```

packages/website/pages/docs/manuals/node-runner-manuals/grimsvotn-l2-node-runner-manual.mdx

@@ -63,5 +63,5 @@ docker compose logs -f taiko_client_prover_relayer
 ## View zkevm prover logs
 
 ```sh
-docker compose logs -f zkevm-chain-prover-rpcd
+docker compose logs -f zkevm_chain_prover_rpcd
 ```

packages/website/pages/docs/reference/contract-documentation/L1/TaikoConfig.md

@@ -0,0 +1,17 @@
+---
+title: TaikoConfig
+---
+
+## TaikoConfig
+
+### getConfig
+
+```solidity
+function getConfig() internal pure returns (struct TaikoData.Config)
+```
+
+#### Return Values
+
+| Name | Type                    | Description                           |
+| ---- | ----------------------- | ------------------------------------- |
+| [0]  | struct TaikoData.Config | config The Taiko configuration object |

packages/website/pages/docs/reference/contract-documentation/L1/TaikoData.md

@@ -0,0 +1,166 @@
+---
+title: TaikoData
+---
+
+## TaikoData
+
+### Config
+
+```solidity
+struct Config {
+  uint256 chainId;
+  uint256 maxNumProposedBlocks;
+  uint256 ringBufferSize;
+  uint256 maxVerificationsPerTx;
+  uint64 blockMaxGasLimit;
+  uint64 maxTransactionsPerBlock;
+  uint64 maxBytesPerTxList;
+  uint256 txListCacheExpiry;
+  uint256 proofCooldownPeriod;
+  uint256 systemProofCooldownPeriod;
+  uint256 realProofSkipSize;
+  uint256 ethDepositGas;
+  uint256 ethDepositMaxFee;
+  uint256 ethDepositRingBufferSize;
+  uint64 ethDepositMinCountPerBlock;
+  uint64 ethDepositMaxCountPerBlock;
+  uint96 ethDepositMaxAmount;
+  uint96 ethDepositMinAmount;
+  bool relaySignalRoot;
+}
+```
+
+### StateVariables
+
+```solidity
+struct StateVariables {
+  uint64 blockFee;
+  uint64 genesisHeight;
+  uint64 genesisTimestamp;
+  uint64 numBlocks;
+  uint64 lastVerifiedBlockId;
+  uint64 nextEthDepositToProcess;
+  uint64 numEthDeposits;
+}
+```
+
+### BlockMetadataInput
+
+```solidity
+struct BlockMetadataInput {
+  bytes32 txListHash;
+  address beneficiary;
+  uint32 gasLimit;
+  uint24 txListByteStart;
+  uint24 txListByteEnd;
+  uint8 cacheTxListInfo;
+}
+```
+
+### BlockMetadata
+
+```solidity
+struct BlockMetadata {
+  uint64 id;
+  uint64 timestamp;
+  uint64 l1Height;
+  bytes32 l1Hash;
+  bytes32 mixHash;
+  bytes32 txListHash;
+  uint24 txListByteStart;
+  uint24 txListByteEnd;
+  uint32 gasLimit;
+  address beneficiary;
+  address treasury;
+  struct TaikoData.EthDeposit[] depositsProcessed;
+}
+```
+
+### BlockEvidence
+
+```solidity
+struct BlockEvidence {
+  bytes32 metaHash;
+  bytes32 parentHash;
+  bytes32 blockHash;
+  bytes32 signalRoot;
+  bytes32 graffiti;
+  address prover;
+  uint32 parentGasUsed;
+  uint32 gasUsed;
+  uint16 verifierId;
+  bytes proof;
+}
+```
+
+### ForkChoice
+
+```solidity
+struct ForkChoice {
+  bytes32 key;
+  bytes32 blockHash;
+  bytes32 signalRoot;
+  uint64 provenAt;
+  address prover;
+  uint32 gasUsed;
+}
+```
+
+### Block
+
+```solidity
+struct Block {
+  mapping(uint256 => struct TaikoData.ForkChoice) forkChoices;
+  uint64 blockId;
+  uint64 proposedAt;
+  uint24 nextForkChoiceId;
+  uint24 verifiedForkChoiceId;
+  bytes32 metaHash;
+  address proposer;
+}
+```
+
+### TxListInfo
+
+```solidity
+struct TxListInfo {
+  uint64 validSince;
+  uint24 size;
+}
+```
+
+### EthDeposit
+
+```solidity
+struct EthDeposit {
+  address recipient;
+  uint96 amount;
+  uint64 id;
+}
+```
+
+### State
+
+```solidity
+struct State {
+  mapping(uint256 => struct TaikoData.Block) blocks;
+  mapping(uint256 => mapping(bytes32 => mapping(uint32 => uint256))) forkChoiceIds;
+  mapping(address => uint256) taikoTokenBalances;
+  mapping(bytes32 => struct TaikoData.TxListInfo) txListInfo;
+  mapping(uint256 => uint256) ethDeposits;
+  uint64 genesisHeight;
+  uint64 genesisTimestamp;
+  uint16 __reserved70;
+  uint48 __reserved71;
+  uint64 __reserved72;
+  uint64 __reserved80;
+  uint64 numEthDeposits;
+  uint64 numBlocks;
+  uint64 nextEthDepositToProcess;
+  uint64 blockFee;
+  uint64 __reserved90;
+  uint64 lastVerifiedBlockId;
+  uint64 __reserved91;
+  uint256[42] __gap;
+}
+```