internal/ethapi: disable sending of non eip155 replay protected tx #22339

[JukLee0ira]

Proposed changes

This PR prevents users from submitting transactions without EIP-155 enabled.
Replay protection is important so we should gently force our users to use it.

It changes the JSON-RPC API quite significantly, so if you see the "only replay-protected (EIP-155) transactions allowed over RPC" error, you know that you need to update your signer.

Test

my test script

import { ethers } from "ethers";

async function testTransaction() {
  const provider = new ethers.providers.JsonRpcProvider("http://0.0.0.0"); //  replace with your RPC address
  const wallet = new ethers.Wallet("your private key", provider); // replace with your private key

  const nonce = await provider.getTransactionCount(wallet.address);
  const currentGasPrice = await provider.getGasPrice();

  const fakeTx = {
    nonce: nonce,
    gasLimit: 21000,
    gasPrice: currentGasPrice.mul(ethers.BigNumber.from(2)),
    to: "your destination address",
    value: ethers.utils.parseEther("1.0"),
    data: "0x",
  };

  // sign the transaction without EIP-155
  try {
    const noneipTx = await wallet.signTransaction(fakeTx);
    await provider.sendTransaction(noneipTx);
  } catch (error) {
    console.error("Transaction failed:");
    console.error("Details:", JSON.parse(error.error.body)); // expect output "only replay-protected (EIP-155) transactions allowed over RPC"
  }

  // sign the transaction with EIP-155
  const eip155Tx = {
    ...fakeTx,
    chainId: 54858,
  };

  try {
    const eip155SignedTx = await wallet.signTransaction(eip155Tx);
    const txResponse = await provider.sendTransaction(eip155SignedTx);
    console.log("Transaction sented! Hash:", txResponse.hash);
  } catch (error) {
    console.error("Transaction failed:", error);
  }
}

testTransaction();

Result

Transaction failed:
Details: {
  jsonrpc: '2.0',
  id: 50,
  error: {
    code: -32000,
    message: 'only replay-protected (EIP-155) transactions allowed over RPC'
  }
}
Transaction sented! Hash: 0x9c67fa1a8eba723332d41f0ccfea3cc71dff74e9bf0626ba97d9009a4ff8c584

Types of changes

What types of changes does your code introduce to XDC network?
Put an ✅ in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices apply)
• Regular KTLO or any of the maintaince work. e.g code style
• CICD Improvement

Impacted Components

Which part of the codebase this PR will touch base on,

Put an ✅ in the boxes that apply

• Consensus
• Account
• Network
• Geth
• Smart Contract
• External components
• Not sure (Please specify below)

Checklist

Put an ✅ in the boxes once you have confirmed below actions (or provide reasons on not doing so) that

• This PR has sufficient test coverage (unit/integration test) OR I have provided reason in the PR description for not having test coverage
• Provide an end-to-end test plan in the PR description on how to manually test it on the devnet/testnet.
• Tested the backwards compatibility.
• Tested with XDC nodes running this version co-exist with those running the previous version.
• Relevant documentation has been updated as part of this PR
• N/A

[gzliudan]

LGTM