Discussion to EIP-3788: Strict enforcement of ChainId

Link to EIP.

I don’t think this change is a good idea because it doesn’t add value to the protocol and it breaks backward compatibility. Any wallet/signing tool that wants this can easily add it and we don’t benefit from adding it to the core protocol in ways that we cannot achieve by just convincing wallets/signers to add it.

In general, anything that can be solved at a higher layer than the core protocol I believe should be solved at a higher layer than the core protocol, and the core protocol should be as permissive as possible when given a choice between permissive and restrictive.

1 Like

I also think this is a bad idea. Also FYI some backlash we got in the geth repo after blocking pre EIP-155 transactions by default: https://github.com/ethereum/go-ethereum/issues/23152
In our case people can work around it via --rpc.allow-unprotected-txs but when this EIP gets accepted which I do not hope it will - then this really breaks it and should for sure be in the Backward compatibility section of the EIP.

Also FYI some backlash we got in the geth repo after blocking pre EIP-155 transactions by default: https://github.com/ethereum/go-ethereum/issues/23152

This was actually one of my main motivations (FWII, we were one of the parties affected, although no one was griefed) because geth is already blocking these transactions be default. We were using geth’s signing package to sign transactions on other chains, when we realized that geth was not respecting the chainId we were adding to transactions. It’s specifically for that reason that I’m proposing this, as we cannot assume or trust that the next million developers who start developing tooling and applications will understand the ramifications of L1/L2 interactions. Ultimately I find it to be completely unsafe. To also comment on the actual feedback that was raised, the notion of repayable transactions may have been quite useful in certain situations, but I believe it to be one of those situations where we created a design flaw by trying to be clever.

I don’t think this change is a good idea because it doesn’t add value to the protocol and it breaks backward compatibility.

I mean, it does add safety, its my main motivation behind this. I would be curious to know how many transactions are being submitted with a chainId of 0, I’ll see if I can get something created on DuneAnalytics.

[…] and the core protocol should be as permissive as possible when given a choice between permissive and restrictive.

This resonates with me quite a bit and I completely understand that. I’d like to hear some other people’s feedback regardless, alternatively I could also perhaps open a PR to the wallet interface or informational section for wallets.

In general, anything that can be solved at a higher layer than the core protocol I believe should be solved at a higher layer than the core protocol, and the core protocol should be as permissive as possible when given a choice between permissive and restrictive.

maybe this can be viewed as complete/incomplete info (instead of permissive/restrictive) ?

I mean, if the chainId is explicit (!=0), the info is complete, incomplete otherwise.

A pre-155 transaction is not incomplete, it is complete, just a different transaction type. Ethereum Mainnet currently has 4 transaction types:
Legacy: This is the pre-155 transaction type.
Legacy-155: This is post-155 transaction type.
1: EIP-2930 transaction type
2: EIP-1559 transaction type

None of these are more complete than any other, though some are newer than others. There are valid reasons for submitting pre-155 transactions, and post 155 transactions, and 2930 transactions, and 1559 transactions. Arguably, 2930 is the least valuable as very few people use it and there is no functionality it provides that cannot be provided by 1559. After that is 155 transactions which are incredibly widely used but provide no additional value beyond 1559 transactions. The last one to deprecate IMO is pre-155, because its functionality is not currently available anywhere else.

@greg I wonder if you have interest in creating an EIP that introduces a new transaction type that is like type 2 transactions (including supporting access lists), but explicitly skips the chain ID check? With that, I would be more in favor of a long-term EOL policy and process for pre-155 transactions.

Another option would be an EIP that introduces something like https://github.com/Zoltu/deterministic-deployment-proxy as a pre-compile or as a new deployment transaction type. This would ensure that the ability to deploy code to deterministic addresses is conserved across future Ethereum testnets, forks, and mainnet which would give us a clean path to deprecating pre-155 transactions.

1 Like

This is actually quite interesting, I could get behind this as a better way to “ease” it out. Also this would allow us to potential deprecate legacy based transactions (signing libs can just bump legacy to type 0x3 or whatever).

Why would you need this as a pre-compile, it works perfectly fine the way it is?

The primary legitimate use case for transactions that can be replayed across chains is for deterministic addresses of contracts deployed on multiple blockchains. Deterministic Deployment Proxy works and has been deployed to all existing public test networks and Mainnet, as well as several L2 chains and side chains. However, if we were to deprecate L1 support for replayable transactions, you would be unable to deploy the proxy to any new chains (like future public testnets or private testnets) created after such a change went live.

By providing users a way to reliably do deterministic address deploys to all future Ethereum-like chains (particularly testnets), we will remove the one legitimate use case for replayable transactions, and I would no longer argue against removing support for them from the protocol (which would mean setting up an EoL schedule for pre-155 transactions).

1 Like

Deprecating legacy transactions is going to be an uphill battle, but one that someone needs to undertake at some point in time. The difficulty is that someone with an offline wallet, pre-signed transaction, or un-upgradable hardware wallet will no longer be able to sign transactions. We have been very loath to make such a breaking change in the past because we don’t know how many (if any) people might be in such a situation.

One potential workaround for this would be to create a pre-compile that can be called with a signature that would execute a legacy signed transaction. This way it could be removed from the bulk of the protocol and the complexity for handling legacy transactions can live in a fairly well isolated location within the EVM as a precompile.

If you do decide to take on this project, I encourage and support you doing so! Just be aware that it is going to be a big project.

Been scheming it with lightclient for some time now, using a pre-compile is something I didn’t think of before to ease the transition.

FWIW there was a proposal and discussion for such a precompile here: EIP Proposal: CREATE2 contract factory precompile for deployment at consistent addresses across networks

1 Like