Regarding gas. The gas savings of implementing
CHAINID opcode is zero. Currently, chain ID be gotten for ~800 gas (G_sload) from a naive oracle implementation, or it can be hardcoded in a contract for 3 gas (G_verylow). This new approach would reduce that to 2 gas (G_base). The gas savings calculation for adding an opcode is:
savings = Δgas × number_of_uses
Here, the calculation is:
0 = 798 × 0
Compare to EIP-145. Their equation is approximately:
a very lot = some × a lot
In summary, from the perspective of gas,
CHAINID opcode is a premature optimization. The argument in favor of
CHAINID opcode on the basis of gas savings would be much stronger if people were added to this discussion who are currently using the ~800 gas oracle approach or the 3 gas hardcoded approach and see other merits of this addition.
Regarding safety. It is not our job to babysit developers. By explaining the potential problems with
CHAINID opcode I illustrated that the use cases are not yet well known enough to say if it provides any value whatsoever.
Regarding trusted third party. It is simple to create an oracle that works on all existing networks that returns the correct chain ID for ~800 gas. After that is done, no further trust is required. If additional networks are created they are welcome to also implement the oracle. This is implementable TODAY. We can open a separate thread if anybody is interested in this. If nobody is interested in this then clearly CHAINID opcode is not needed.
Regarding “why not?” There are many things which can be implemented. For example, an opcode which concatenates strings or rotates the top three stack items would be very useful. The threshold for adding new features should not be “this proposal doesn’t make it worse than what it already is”. The threshold should be “this feature is badly needed, workarounds are already in widespread use”.
Regarding what if the oracle is set up incorrectly. Then it would work incorrectly.
Regarding an alternative to find chain ID histories.
Thank you for the proposal. I believe the best solution is to have two new opcodes:
GENESIS returns the hash of the genesis block and
CONSENSUSCLIENT returns the hash of the consensus client used to validate the last block.
This approach with a simple trustless tool allows finding the lineage of any block and maintains usefulness on both sides of a contentious or non-contentious fork.
Regarding building for the future.
^ Yes, we should build standards based on the future and a good understanding of the use cases.
Regarding Ethereum Foundation.
I disagree, in the event of a contentious fork, both networks would call themselves “Ethereum”. If the Ethereum Foundation supported version is the less used fork then they may assert trademark rights against people using the other network. It is undocumented whether they would do this. A request to document this is here https://github.com/ethereum/ethereum-org/issues/841 This is a fundamental issue preventing enterprises from using Ethereum mainnet.