Add EIP: BLOB Data and Rollup Operator Rewards

[khajievN]

ATTENTION: ERC-RELATED PULL REQUESTS NOW OCCUR IN ETHEREUM/ERCS

--

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

• The PR edits only existing draft PRs.
• The build passes.
• Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
• If matching on email address, the email address is the one publicly listed on your GitHub profile.

[eth-bot]

File EIPS/eip-0000.md

Requires 1 more reviewers from @g11tech, @lightclient, @samwilsn, @xinbenlv

File EIPS/eip-00000.md

Requires 1 more reviewers from @g11tech, @lightclient, @samwilsn

[nerolation]

This is spam.

[abcoathup]

This doesn't appear to be an EIP (in its current form)

Rollups are already using blobs, with the incentive that it is generally cheaper than calldata: https://www.growthepie.xyz/economics

[sopia19910]

Hello,

Ethereum has adopted layer technology, where L2 is connected to the Ethereum blockchain with finality at lower fees. This means that L2 blocks are also recognized as part of the Ethereum blockchain.

In other words, Layer 2 is part of the Ethereum blockchain, and I believe that this scalability should extend not only to blocks but also to validators and the reward system. However, the current focus is solely on block expansion, which has led to the perception that Ethereum is becoming centralized.

Therefore, I believe that if the validator and reward systems are also expanded, Ethereum would not be considered centralized.

To address this issue, our team has made a proposal, and we plan to continue suggesting specific code modifications to support this.

To clarify what we are proposing: ultimately, we are suggesting not just providing rewards to operators who perform rollups, but also creating a system where the consensus algorithm of L2 chains interacts with L1 and receives rewards based on that interaction. We will further elaborate on this in more detail.

[ppopth]

This doesn't make sense at all. As @abcoathup said, rollups are already incentivized. There is no need for this EIP. I think this PR can be safely closed.

[sopia19910]

Based on the current Layer 2 rollup policies, our proposal may not align fully with traditional approaches. However, considering the future scalability of Layer 3, our proposal is worthy of close examination.

In Layer 3, it is highly likely that specialized data providers will emerge. In this scenario, we believe that the Ethereum chain will face two strategic options:

1. Receive extensive data through layers, enabling client transactions on the Ethereum chain based on aggregated and statistical data, or
2. Center aggregation solely on rollup blocks at the topmost layer for a streamlined approach. We believe that layer scalability should not be limited to simple block finality but should also include extensible reward policies that interact with the consensus algorithms of lower layers.

This proposal envisions a content provider layer supplying data to the Ethereum chain. We plan to further refine and update this proposal with more detailed considerations in the future.

[g11tech]

This proposal is lacking sufficient detail to be assigned an EIP number.

@khajievN could you add more details to this EIP proposal for us to consider it for draft?

[sopia19910]

@g11tech As requested, we've added detailed specifications to the EIP proposal regarding a reward mechanism designed to reduce cost burdens and enhance sustainability for Rollup operators uploading L2 block data to L1, and we plan to continue our research and improvements on this topic.

[SamWilsn]

This proposal is still kind of a mess (no offence intended). You should cleanly separate any application-level content from the changes that require a hardfork. The application-layer content should be an ERC.

This pull request still needs more detail before we can give it a number; it reads more like a plan to come up with a proposal than a proposal itself. You should specify things like the arguments the opcode pops from the stack, what it pushes, the state changes it makes, and the gas cost for executing it. The motivation should focus on why we should put this opcode into the protocol, and the rationale should justify it being an opcode over (for example) a precompile.

Getting technical agreement from the Editors isn't required. Even if we think it's a terrible idea (and I'm not saying this one is), we'll still assign a number as long as the proposal is ~feasible and sketched out technically.

[github-actions[bot]]

The commit 4c4a5843976d32dfaabc89409e5cd528fed192c0 (as a parent of 46876de196541027087e0a199609066482467d4e) contains errors. Please inspect the Run Summary for details.

[github-actions[bot]]

There has been no activity on this issue for six months. It will be closed in 7 days if there is no new activity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.