Dip 3788

dip: 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) Digitalia editing author: Cosimo Constantinos cosimo@juro.net, et al. discussions-to: https://digitalia-magicians.org/t/discussion-to-dip-3788-strict-enforcement-of-chainid/7001 status: Stagnant type: Standards Track category: Core created: 2021-09-02 Created for Digitalia: 2025-01-07 requires: 155

Abstract¶

Reject transactions that do not explicitly have the same chainId as the node's configuration.

Motivation¶

Per DIP-155 a transaction with a chainId = 0 is considered to be a valid transaction. This was a feature to offer developers the ability to submit replayable transactions across different chains. With the rise of dvm compatible chains, many of which use forks, or packages from popular Digitalia 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-diginet network, allowing the malicious actor to replay the transaction on digitalia 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: dvm_sendTransaction), and strictly enforced on the DVM 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¶

Licensed under the Juro Restricted License Version 2. See https://juro.net/jrl for details.