Why is networkId explicitly required now?

[jiexi]

Hello there,

Just wondering why networkId in Common is explicitly required now. I don't believe it's required for building an unsigned transaction

I'm sure I've missed something.

Thank you

[holgerd77]

Hi there,
the code parts you are referencing only come into play for custom chains, otherwise the network ID is provided. If you are concretely stumbling upon something you would need to provide us with a small code example, otherwise you provide not enough context for a solid answer.

[jiexi]

Sorry, I should have been more clear. Specifically my concern is about custom chains using Common.custom that is passed to TransactionFactory.fromTxData(...)

I don't see networkId referenced in any of the transaction classes:

• https://github.com/ethereumjs/ethereumjs-monorepo/blob/master/packages/tx/src/legacyTransaction.ts#L280C13-L280C13
• https://github.com/ethereumjs/ethereumjs-monorepo/blob/master/packages/tx/src/eip2930Transaction.ts#L285
• https://github.com/ethereumjs/ethereumjs-monorepo/blob/master/packages/tx/src/eip1559Transaction.ts#L312
• https://github.com/ethereumjs/ethereumjs-monorepo/blob/master/packages/tx/src/eip4844Transaction.ts#L522

Usage being something like this

import { Common } from '@ethereumjs/common';
import { TransactionFactory } from '@ethereumjs/tx';

// This would throw because of missing  'networkId', 'genesis', 'hardforks', 'bootstrapNodes' fields
const common = Common.custom({
  name: "Example",
  chainId: "0x1",
});

const unsignedEthTx = TransactionFactory.fromTxData({...}, { common });

[holgerd77]

Hi there, sorry that there was no follow-up here. To finally give some answer: so, two things here. There is this signed/unsigned tx topic coming into play here + the network ID vs chain ID topic.

On the first, for signed tx, this does need a chain ID starting with (already old) EIP-155 (so this is what all "modern" txs are taking). Regarding network vs chain ID, so the network ID field is just a left-over from the old "before-chain-ID" days, I guess we can remove this from the code base, have directly taken this as an occasion to start a new deprecation tracking issue #3216 for an eventual next breaking release round.

Not sure of what parts you were aware of, so just giving the complete round here for completeness.

Will close this issue now, feel nevertheless free to ask follow-up questions if there are still uncertainties.