core/types: change SetCodeTx.ChainID to uint256 #30982
Conversation
fjl
requested review from
lightclient
and removed request for
holiman and
rjl493456442
|
Hmm. So now it's a bit inconsistent with |
|
Why do we use
In terms of this, it seems like encoding as |
lightclient
force-pushed
the
core-types-7702-chainid
branch
from
b2d69de to
cd0c444
Compare
| @@ -219,7 +219,7 @@ func (s pragueSigner) SignatureValues(tx *Transaction, sig []byte) (R, S, V *big | |||
| } | |||
| // Check that chain ID of tx matches the signer. We also accept ID zero here, | |||
| // because it indicates that the chain ID was not specified in the tx. | |||
| if txdata.ChainID != 0 && new(big.Int).SetUint64(txdata.ChainID).Cmp(s.chainId) != 0 { | |||
| if txdata.ChainID != nil && txdata.ChainID.CmpBig(s.chainId) != 0 { | |||
There was a problem hiding this comment.
is this correct?
should it be if txdata.ChainID.Sign() != 0 && txdata.ChainID.ToBig().Cmp(s.chainId) != 0 { ?
I think it was copied from the cancunSigner, but it's not same with the cancunSigner
There was a problem hiding this comment.
after thinking about it, It is correct.
I have made a PR #31032 to update the cancunSigner to align with it
We still need to decide how to handle non-specfic `chainId` in the JSON encoding of authorizations. With `chainId` being a uint64, the previous implementation just used value zero. However, it might actually be more correct to use the value `null` for this case.
We still need to decide how to handle non-specfic
chainIdin the JSON encoding of authorizations. WithchainIdbeing a uint64, the previous implementation just used value zero. However, it might actually be more correct to use the valuenullfor this case.