Update EIP-7702: Restrict chain_id to chain's id or zero

[rakita]

As we already checking if y_parity and s values additionally adding a check for correct chain_id seems logical.

This would make the EIP-7702 transaction invalid if it is not zero (chain agnostic) or has chain_id different from the Ethereum-s chain_id.

Would propose that this change is added after devnet-3 to not disrupt testing/developing efforts.

[eth-bot]

File EIPS/eip-7702.md

Requires 1 more reviewers from @adietrichs, @lightclient, @SamWilsn, @vbuterin

[lightclient]

We want the chain id to equal the chain's current ID or zero, no just zero and one.

[etan-status]

https://ethereum-magicians.org/t/eip-2294-explicit-bound-to-chain-id/11090/16?u=etan-status

I have asked about whether zero is being used sometime early 2023 here. Seems to be actually unused, but it would have to be formally reserved to indicate chain-agnostic (it doesn't have that special meaning right now)

[gumb0]

Should the check 1. in Behaviour be removed then?

[lightclient]

I think the way these checks are being added is a bit wrong. We want to first define the serialization of auth list, giving reasonable bounds, and then define the validity of the transaction given certain auth tuples.

For that reason, I think chain id should to be considered valid as long as it is less than 2**256 - 1. I don't think we should make the entire tx invalid just because an inner element has an invalid chain id -- therefore I am not in support of this PR.

[bumblefudge]

I haven't been following closely enough to agree or disagree with lightclient's point above, but I will just point out that the use of chainId 0 for offchain/EOA use-cases is documented here, if anyone wants to normref it (note that the EIP link policy would require linking to the commit-specific markdown on github, not the rendered jekyll output). it sounds like everyone has bigger fish to fry, tho, so tag me later if it comes back up in clean-up after the major construction is done!

[lightclient]

I think we've agreed to keep the validity check minimal and be based on the integer width.