EIP-2294: Explicit bound to Chain ID size

[fubuloubu]

eip: 2294
title: Explicit bound to Chain ID size
author: Bryant Eisenbach (@fubuloubu), Alex Beregszaszi (@axic)
discussions-to: <URL>
status: Draft
type: Standards Track
category: Core
created: 2019-09-19
requires: EIP-155

Simple Summary

Adds a maximum value to the EIP-155 Chain ID parameter to avoid potential encoding issues that may occur when using large values of the parameter.

Abstract

This EIP restricts the size of EIP-155 Chain ID parameter to a particular maximum value, in order to ensure that there is a standard around how this parameter is to be used between different projects.

Motivation

EIP-155 introduces the Chain ID parameter, which is an important parameter used for domain separation (replay protection) of Ethereum protocol signed messages. However, it does not specify any properties about the size that this parameter takes. @axic mentions this concern in EIP-1344 (comment) and suggests a reasonable maximum enforced size in order to ensure that there are no issues when encoding this parameter. This would allow a sufficient amount of different values for this parameter, which is typically chosen by community consensus as a genesis parameter for a given chain and thus does not change often.

There have been suggestions of using a hash-based identifier in place on Chain ID to allow the value to adapt over time to different contentious forks and other scenarios. This proposal does not describe this behavior, but ~63 bits of entropy should be enough to ensure that no collisions are likely for reasonable (e.g. non-malicious) uses of this feature for that purpose.

Specification

The maximum value of Chain ID is 9,223,372,036,854,775,771 (MAX_CHAIN_ID). This value is floor(MAX_UINT64 / 2) - 36, and is chosen to avoid overflow when performing uint64 math. For reference, a value of 0 or less is also disallowed.

A client should reject a value outside of this range in a provided transaction, and disallow a genesis configuration with a value for Chain ID outside of this limit. Due to how the calculation for chain ID is performed, the maximum value seen during the arithmetic is CHAIN_ID * 2 + 36, so clients must test to ensure no overflow conditions are encountered when the highest value is used. No underflow is possible.

Rationale

Without a well-chosen value of Chain ID, there could be differences in the implementation of EIP-155 (and EIP-1344 by derivative) in both client codebase and external tooling that could lead to consensus-critical vulnerabilities being introduced to the network. By making this limit explicit, we avoid this scenario for Ethereum and any project which uses the Ethereum codebase.

Backwards Compatibility

This EIP introduces a change that affects previous implementations of this feature. However, since no known chain makes use of a value outside of the suggested bounds, there should not be an issue in adopting this limit on the size of this parameter, therefore the impact should be non-existent.

Test Cases

Aleth PR

Implementation

TBD

Copyright

Copyright and related rights waived via CC0.

[PeterTheOne]

Btw. having a too short MAX size was an issue in web3j: hyperledger-web3j/web3j#913 and hyperledger-web3j/web3j#234 . A defined size could have prevented this, therefore I support this EIP.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP 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]

This issue 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.

[xinbenlv]

Hi @fubuloubu , I think this is an important improvement. Are you still pursuing this EIP? If you don't have time, I can volunteer to continue championing this EIP

[fubuloubu]

@xinbenlv pleade do! I don't have the time to champion it right now, but should be pretty straightforward

[xinbenlv]

@fubuloubu I recovered the content and are working on cleaning things up. Are you ok if I put you and @axic the first names? You did the main work so I assume it's better that you remain ahead, let me know if you prefer me to be the first name as champion.

[fubuloubu]

I am good without being mentioned

[xinbenlv]

Do you prefer not to be mentioned? Or do you just ok be either named or not named? @fubuloubu

[fubuloubu]

I'm okay not being mentioned

[xinbenlv]

Original authors: @fubuloubu @axic , could you give an approval for EIP-2294 to revive EIP process on this PR #5728 to approve the revival of this EIP?

[sambacha]

Metamask has a hardcoded value for rejecting chainId's over a certain number. That number is calculated based off of

source from remarks, metamask engineer

From ethereumjs-util@7.0.5, we have that:

  v = recovery + (chainId * 2 + 35)

Per the above discussion, we also have that:

  int_max = 2**53 - 1
  recovery_max = 3
  chainId_max = ?

Therefore:

  v_max = 3 + (chainId * 2 + 35) = chainId * 2 + 38
    &&
  v_max <= int_max
  
    ->
    
  2**53 - 1 = MAX_SAFE_CHAIN_ID * 2 + 38
  
    ->
    
  // Since we're dealing with integers, we round down.
  
  MAX_SAFE_CHAIN_ID = floor( ( 2**53 - 39 ) / 2 ) = 4503599627370476

Ethereumjs-util as referenced above has BigInt support since 7.0.9, regardless metamask has encoded this value within their application.
see https://github.com/ethereumjs/ethereumjs-util/releases/tag/v7.0.9

[xinbenlv]

Thank you @sambacha

[xinbenlv]

For follow up discussion please take them to https://ethereum-magicians.org/t/eip-2294-explicit-bound-to-chain-id/11090

In today's ACD,
@xinbenlv advocated to prioritize EIP-2294 into shanghai fork.
@MariusVanDerWijden responded that if it's low cost, let's do it, but don't need to have a deadline to be shipped before Shanghai fork.
@MicahZoltu responded support EIP-2294 that bounds chainId at its current proposed ceiling. Because it has been a de facto rule. @MicahZoltu further proposed that we don't need to do any coding immediately, just need to agree as a group and call it a rule.
@shemnon responded whether we should accept such bounding just because no one has ever used any chainId above bounds. Ask to think twice.

Please correct me if I were wrong.

For follow up discussion please take them to https://ethereum-magicians.org/t/eip-2294-explicit-bound-to-chain-id/11090