Update ERC-6860: Add _blockNumber parameter to Web3 URL specification

[nishuzumi]

This PR extends the Web3 URL specification to include support for the _blockNumber parameter, allowing users to specify a particular block number when making queries and enabling access to historical blockchain data.

Summary of changes:

• Modified pathQuery to optionally include evmQuery
• Added new evmQuery rule to handle EVM-specific parameters
• Introduced blockNumberQuery rule for _blockNumber parameter

[eip-review-bot]

File ERCS/erc-6860.md

Requires 1 more reviewers from @nand2, @pichaoqkc, @qizhou, @samwilsn

[github-actions[bot]]

The commit e81887866a5076aaccf0f0bd2da1a86f7c221d08 (as a parent of 0e763e08768ed779071801a19bab61bfb22db06f) contains errors. Please inspect the Run Summary for details.

[nishuzumi]

@qizhou Add some fix code

[nishuzumi]

The rfc format problem has been fixed after the last modification, please kindly review it again @nand2, @pichaoqkc, @qizhou, @SamWilsn

[nand2]

Hi!

Thanks for the PR. Here is my feedback :

• The _from attribute is not necessary, it is already supported via the userinfo field in schema "://" [ userinfo "@" ] contractName [ ":" chainid ] pathQuery.
• In the Auto mode ABNF :
  • Please keep the ordering of lines from so that each new variable in a line is defined in a line below it.
  • The ERC contains both the complete ABNF notation in the appendix, and excerpts within the specification, please do the modifications at both places.
  • Instead of mixing attribute and evmParams in aQuery, it would be better to rework the attribute field, and start from there. Rename attrName and attrValue to something more precise, as the returns/returnTypes are no longer the only attributes. For example : attribute = retAttrName "=" retAttrValue / evmAttrName "=" evmAttrValue
  • For blockNumber : I guess we should add the 5 authorized string values ("latest", "earliest", "pending", "safe" or "finalized").
• In the auto mode section in the specification: Please describe briefly what these options do.
• The specification in ABNF notation indicate the structure of a valid web3:// URL. So, in manual mode, every query (mQuery = *( pchar / "/" / "?" )) is already allowed, so there is no need to alter it. On the other hand, the special _blockNumber and _gasLimit parameters should be described in the manual mode section in the specification (behavior, syntax of value (can reference the syntax definition of auto mode), whether they are forwarded to the smartcontract, etc)

I would also argue that, while prefixing these attributes with _ makes sense for the manual mode, to prevent conflicts with actual attributes used by the webpage, they are not necessary for the auto mode since there cannot be any conflict. One could argue that it may be confusing that sometimes it is _blockNumber and sometimes it is blockNumber, but on the other hand when we craft a web3:// URL, we already know for which mode we are crafting the URL. So:

• auto mode : web3://usdc.eth/balanceOf/vitalik.eth?returns=(uint)&blockNumber=12000000
• manual mode : web3://vitalikblog.eth/general/2024/07/23/circlestarks.html?_blockNumber=12000000

What do you think?

Other subject : Outside the scope of this ERC, but linked : for resource request mode (erc-6944), I think we would support this there as well, and it would make sense to me that we just do not forward the new attributes _blockNumber and _gasLimit to the smartcontract. So for the manual mode : should we also extract these from the calldata sent to the smartcontract? It would make sense to me.

Thanks!

[SamWilsn]

I'm not super involved with this standard, so I'll leave this to the other authors.

[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.

[github-actions[bot]]

This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.