forked from DecentralizedClimateFoundation/DCIPs
61 lines
2.4 KiB
Markdown
61 lines
2.4 KiB
Markdown
|
---
|
||
|
|
eip: 3788
|
||
|
|
title: Strict enforcement of chainId
|
||
|
|
description: Reject transactions that do not explicitly have the same chainId as the node's configuration.
|
||
|
|
author: Gregory Markou (@GregTheGreek)
|
||
|
|
discussions-to: https://ethereum-magicians.org/t/discussion-to-eip-3788-strict-enforcement-of-chainid/7001
|
||
|
|
status: Stagnant
|
||
|
|
type: Standards Track
|
||
|
|
category: Core
|
||
|
|
created: 2021-09-2
|
||
|
|
requires: 155
|
||
|
|
---
|
||
|
|
|
||
|
|
## Abstract
|
||
|
|
|
||
|
|
Reject transactions that do not explicitly have the same chainId as the node's configuration.
|
||
|
|
|
||
|
|
## Motivation
|
||
|
|
|
||
|
|
Per [EIP-155](./eip-155.md) a transaction with a `chainId = 0` is considered to be a valid
|
||
|
|
transaction. This was a feature to offer developers the ability to sumbit replayable transactions
|
||
|
|
across different chains. With the rise of evm compatible chains, many of which use forks, or packages
|
||
|
|
from popular Ethereum clients, we are putting user funds at risk. This is because most wallet
|
||
|
|
interfaces do not expose the chainId to the user, meaning they typically do not have insight
|
||
|
|
into what chainId they are signing. Should a malicious actor (or accidental) choose to, they
|
||
|
|
can easily have users submit transactions with a `chainId = 0` on a non-mainnet network, allowing
|
||
|
|
the malicious actor to replay the transaction on ethereum mainnet (or other networks for that matter)
|
||
|
|
as a grief or sophisticated attack.
|
||
|
|
|
||
|
|
## Specification
|
||
|
|
|
||
|
|
As of the fork block `N`, consider transactions with a `chaindId = 0` to be invalid. Such that
|
||
|
|
transactions are verified based on the nodes configuration. Eg:
|
||
|
|
```
|
||
|
|
if (node.cfg.chainId != tx.chainId) {
|
||
|
|
// Reject transaction
|
||
|
|
}
|
||
|
|
```
|
||
|
|
|
||
|
|
## Rationale
|
||
|
|
|
||
|
|
The configuration set by the node is the main source of truth, and thus should be explicitly used
|
||
|
|
when deciding how to filter out a transaction. This check should exist in two places, as a filter
|
||
|
|
on the JSON-RPC (eg: `eth_sendTransaction`), and strictly enforced on the EVM during transaction
|
||
|
|
validation.
|
||
|
|
|
||
|
|
This ensures that users will not have transactions pending that will be guaranteed to fail, and
|
||
|
|
prevents the transaction from being included in a block.
|
||
|
|
|
||
|
|
## Backwards Compatibility
|
||
|
|
This breaks all applications or tooling that submit transactions with a `chainId == 0` after block number `N`.
|
||
|
|
|
||
|
|
## Test Cases
|
||
|
|
TBD
|
||
|
|
|
||
|
|
## Security Considerations
|
||
|
|
It should be noted this will not prevent a malicious actor from deploying a network with `chainId = 1`, or copying any other networks chainId.
|
||
|
|
|
||
|
|
## Copyright
|
||
|
|
Copyright and related rights waived via [CC0](../LICENSE.md).
|