Update EIP-4444: Make serving historical data an option

[peersky]

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-4444.md

Requires 1 more reviewers from @asn-d6, @lightclient, @ralexstokes

[github-actions]

The commit 7026759 (as a parent of 2038f8f) contains errors.
Please inspect the Run Summary for details.

[g11tech]

lgtm, leaving for authors to decide

[SkandaBhat]

LGTM

[peersky]

@g11tech @SamWilsn @poojaranjan Im continuing exploring EIP authorship experience here for dip.box project :)

How can I claim championship over this EIP?

I requested simple and reasonable addition and could not get it merged as authors are inactive, they did not respond nor here nor in magicians forum.

[g11tech]

@peersky you should attend an ACD and put your proposal there

[peersky]

@peersky you should attend an ACD and put your proposal there

Ok, execution call, right?

Frankly, I would assume its a waste of time of high value people in large quantity?

[lightclient]

I think SHOULD is still the right way to frame this. Accessing historical data over the eth protocol is not efficient as it stands today and we should continue thinking about ways to improve it.

[peersky]

I think SHOULD is still the right way to frame this. Accessing historical data over the eth protocol is not efficient as it stands today and we should continue thinking about ways to improve it.

But May doesn't stop you from doing that.
It makes proposal a lean, less breaking change, enabling to fast track this EIP into final status much faster.
Also it keeps more freedom around implementation. I might want to write my own node client that explicitly serves historical data that I WANT.

• For example I could monetize my RPC endpoint by serving historical, contract specific data to customers needing that in their specific dApp. I could negotiate with them retention fees etc.

MAY leaves me this freedom of doing without enforcing anything on rest client teams. While current formulation reduces optional feature scope.

Where is my thinking of this going wrong?

[g11tech]

@peersky you should attend an ACD and put your proposal there

Ok, execution call, right?

Frankly, I would assume its a waste of time of high value people in large quantity?

it changes basic assumptions of client behavior so if you feel strongly about it, you can go ahead and present your proposal. don't hesitate to put up your task in agenda. if you are sincere you might be given a few minutes to talk about it and get the room's opinion

[peersky]

@peersky you should attend an ACD and put your proposal there

Ok, execution call, right?
Frankly, I would assume its a waste of time of high value people in large quantity?

it changes basic assumptions of client behavior so if you feel strongly about it, you can go ahead and present your proposal. don't hesitate to put up your task in agenda. if you are sincere you might be given a few minutes to talk about it and get the room's opinion

Here is what I really think of this: https://x.com/iampeersky/status/2025197116398666089?s=20