Add ERC: Cache invalidation in ERC-5219 mode Web3 URL

[nand2]

Abstract

In the context of the ERC-6860 web3:// standard, this ERC extends the ERC-6944 resolve mode: This standard add mechanisms to alleviate limitations to the use of standard RFC 9111 HTTP caching.

[eip-review-bot]

File ERCS/erc-7774.md

Requires 1 more reviewers from @axic, @g11tech, @SamWilsn, @xinbenlv

[nand2]

Hi!

Thanks for the initial review!
I am now refining the ERC and I am implementing in on web3protocol-go -- sometimes implementation helps to track some conceptual bugs.

[SamWilsn]

There are definitely some security considerations, no? At the very least contracts need to correctly emit cache invalidation events, or stale content could be served.

I bet there are some unpleasant interactions between this and chain reorgs. as well?

[nand2]

Yes indeed!
I have added 3 :

• Stale content will be served during the delay between a user transaction emitting a cache clearing event, and the web3:// client picking and processing the event.
• For each cached page, websites must properly implement cache invalidation events; otherwise, stale content will be served indefinitely.
• In the event of a chain reorganization, the web3:// client must roll back its caching state, or reverted content will be served until the next cache clearing event.

The first one is something that conceptually annoys me (even if the web3:// client is optimizing its logs reading by using streams, it can theorically be missed).
So I am thinking about ways for the website to signal to the web3:// client when fetching a page: "hey please ensure you are up to date with block XXX (because I just made a change on it via a TX)".
A HTTP header in the request is an idea, but may be not practical when doing a page change (e.g. in blog post edit page, save tx, then go to blog post page view). Thinking...

[nand2]

@SamWilsn Also thanks again for the review; for taking the time to read this whole thing and make comments! :-)

Now thinking about the signaling discussed just before.

[nand2]

Ok got the rough idea : a /.well-known/ URL that expose the currently processed blocks of blockchains.
The client can then poll this URL and wait until the user TX block was processed in the web3:// client before redirecting. That way he can ensure the user will see the new version.
The web3:// client MAY use the fetching of this /.well-known/ URL as a signal to speed up the processing of new blocks.

I'll add that shortly.