Update eip-00000.md

EIPS/eip-00000.md

@@ -10,13 +10,13 @@ category: Core
 created: 2024-10-23
 ---
 
-## **Abstract**
+## Abstract
 
 This proposal introduces a way to reward L2 Rollup operators for uploading block data to L1
 (the Ethereum mainnet). It reduces the gas cost burden for operators. It strengthens the
 sustainability of rollup operations. It promotes network decentralization.
 
-## **Motivation**
+## Motivation
 
 1. **There is a cost burden for L2 operators.**
     - An operator uploads L2 block data to L1. It pays gas fees but has no direct way to recoup them.
@@ -30,9 +30,9 @@ sustainability of rollup operations. It promotes network decentralization.
     - A reward scheme encourages more rollup operators to enter, which fosters competition and reduces rollup fees.
     - Multiple operators submitting blocks in parallel can reduce L1 transaction load and maximize overall network capacity.
 
-## **Specification**
+## Specification
 
-### **1) Block Submission and Reward Flow**
+### 1) Block Submission and Reward Flow
 
 #### L2 Block Creation and Data Aggregation
 
@@ -44,7 +44,7 @@ sustainability of rollup operations. It promotes network decentralization.
 
 - The block submitter sends the blobTx to a specialized Rollup contract on L1 (for example, RollupBlockSubmitter).
 - The data is committed on L1 through a transaction.
-- The msg.sender of that L1 transaction identifies the submitter.
+- The `msg.sender` of that L1 transaction identifies the submitter.
 
 #### Challenge Period and Verification
 
@@ -58,24 +58,24 @@ sustainability of rollup operations. It promotes network decentralization.
 - It considers metrics such as data size, network congestion, and compression efficiency.
 - It can grant extra incentives if data remains available on-chain for a required duration (e.g. with EIP-4844 blobs).
 
-### **2) How L1 Identifies the L2 Block Submitter**
+### 2) How L1 Identifies the L2 Block Submitter
 
-- L1 does not store the operator's identity explicitly, but it checks the transaction's msg.sender.
+- L1 does not store the operator's identity explicitly, but it checks the transaction's `msg.sender`.
 - A rollup contract logs events so that off-chain analyzers can track who submitted each block.
-- A mapping can store the block hash and operator address, like in this
+- A mapping can store the block hash and operator address, like this:
+
+  ```solidity
+  mapping(bytes32 => address) public rollupProposers;
 
-```
-mapping(bytes32 => address) public rollupProposers;
+  function submitRollup(bytes32 _blobHash) external {
+      rollupProposers[_blobHash] = msg.sender;
+      emit RollupSubmitted(msg.sender, _blobHash, block.timestamp);
+  }
+  ```
 
-function submitRollup(bytes32 _blobHash) external {
-    rollupProposers[_blobHash] = msg.sender;
-    emit RollupSubmitted(msg.sender, _blobHash, block.timestamp);
-}
-```
+- The operator can later call a `claimReward()` function to withdraw the reward.
 
-- The operator can later call a **claimReward()** function to withdraw the reward.
-
-### **3) Ways to Use L2 Block Submitter Information**
+### 3) Ways to Use L2 Block Submitter Information
 
 1. **Reward Distribution**
     - It grants rewards to the valid block submitter after the block passes all checks.
@@ -99,7 +99,7 @@ function submitRollup(bytes32 _blobHash) external {
 4. **Data Availability Period**
     - [EIP-4844](./eip-4844.md) blobs stay on-chain for around 2--3 weeks. The operator can earn extra rewards if no challenge arises during that period.
 
-### **5) Reward Delivery Methods**
+### 5) Reward Delivery Methods
 
 1. **Smart Contract--Based Reward**
     - The rollup contract on L1 tracks submitters. It can directly send ETH to them once a block is finalized, or allow them to call **claimReward()**.
@@ -109,9 +109,7 @@ function submitRollup(bytes32 _blobHash) external {
     - A new opcode (e.g. **OP_ROLLUP_REWARD**) can trigger automatic ETH transfers when a blobTx is accepted.
     - It requires a protocol-level change (a hard fork), so it is more difficult to implement and less flexible than the contract-based model.
 
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
-
-## **Rationale**
+## Rationale
 
 1. **Ensures Operator Sustainability**
     - An operator covers gas fees on L1. A reward allows the operator to recoup part of that cost and remain profitable, sustaining rollup operations.
@@ -122,7 +120,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 3. **Lowers L2 Transaction Costs**
     - A reimbursed operator can reduce L2 fees for users. It makes L2 adoption more attractive.
 
-## **Security Considerations**
+## Security Considerations
 
 1. **Reward Only after Proper Verification**
     - The system waits for fraud-proof or ZK-proof validation before issuing rewards.
@@ -136,7 +134,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
     - The system can require stake deposits from operators or vary rewards by past performance.
     - It can track multiple addresses tied to the same entity to prevent Sybil attacks.
 
-## **Backwards Compatibility**
+## Backwards Compatibility
 
 - This proposal targets EIP-4844 (Proto-Danksharding) for blob transactions.
 - It can also work with pre-EIP-4844 calldata, though data storage costs are higher there.
@@ -147,7 +145,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 
 The reward mechanism must be based on accurate verification, with clear rules to prevent fraudulent activity. Rollup operators submitting incorrect data should not receive rewards, and the reliability and accuracy of the data must be ensured.
 
-Needs discussion.
+<!-- TODO: Needs discussion. -->
 
 ## Copyright