EIP-1344: Add chain id opcode

EIPs
,
101

256-bit. I didn’t realize it wasn’t in the proposal

1 Like
102

It’s perfect, thank you.

103

This EIP is well past last call date. Will the process to move from Last Call to Accepted be activated?

2 Likes
104

I have https://github.com/ethereum/EIPs/pull/1994 open for that.

With recommended inclusion into Istanbul, I am hoping we can move this to Accepted soon so that implementers may be able to reference this proposal in a Solidified state.

I’m still working on the reference implementation into Trinity, but the Aleth implementation is here: https://github.com/ethereum/aleth/pull/5696

105

To clear this part of the confusion: that was added after the adoption of EIP-155 in a hard fork as well as the update of YP.

I clearly remember the ACD calls (around 2016 or 2017) where a 1 byte value was agreed on.

106

While I think this is a clever idea, in the worst case it means the calculation for the transaction exceeds 256 bits.

107

Thank you. Maybe more clever (read: risky) is an alternate implementation that does not depend on concatenation:

sha3(sha3(tar_gz(reference_implementation)) ^ sha3(genesis_block)) ^ sha3(genesis_block)

108

Maybe the 64-bit unsigned integer (uint64) would be enough? I don’t like planning for use cases that may be never needed. Even if you want to use a hash function, truncating the output to 64 bits seems good enough (@axic’s tip).

109

I’m strongly in favour not making it 256-bit wide. Allowing it to be 256-bit wide means that the RLP encoding of a transaction must use >256-bit arithmetic to calculate the v field.

1 Like
110

64 bits is a decent amount of entropy to avoid hash collisions with normal use, and there would likely be other mitigating factors if chain ID were hash-based and someone wished to exploit it to fake out other network node’s network discovery phases (or however it might be used). Given @axic’s observation of the need to change RLP encoding of transactions to support a larger field, I think this is a reasonable request.

What’s the worst case scenario for the v field?

If there’s consensus for this, I can update the EIP

111

From EIP-155:

If block.number >= FORK_BLKNUM and v = CHAIN_ID * 2 + 35 or v = CHAIN_ID * 2 + 36 , then when computing the hash of a transaction for purposes of signing or recovering,

1 Like
112

To make sure I understand. Do you want to set max chain id value such that v = CHAIN_ID * 2 + 36 will fit in 64-bits? Then I’d recommend targeting 63 bits - then you would allow this computation with signed types.

113

No, he was saying that the max value of chain ID must be less than MAX_UNIT256/2-36 to fit in 256-bit arithmetic. 64 bits is well inside that

114

I have no strong opinion whether the chain id or the complete calculation should be 64-bit, but I’d argue on the RLP level calculations must be able to support 256-bit so either way should be fine.

I’d also argue that eventually the transaction format should be cleared up and this workaround be removed as it was only added to minimize the impact of changes back in 2016/2017. By this logic chain id could be 64-bit.

I am also writing up an “errata” EIP to EIP-155 to clarify what we’re discussing here – as EIP-1344 only discusses EVM.

115

Will you make this change to the EIP?

116

Added: https://github.com/ethereum/EIPs/pull/2263

Also noticed some of the links were broken, so updating those separately.

Edit: Links PR here: https://github.com/ethereum/EIPs/pull/2264

117

I just noticed that this opcode is absent from the yellow paper. Does anyone fancy adding it?

118

Hmmm I would look into it :slight_smile:

1 Like