Support Ethereum Legacy Transactions

[Stebalien]

Filecoin currently supports EIP1559 transactions (transactions that include EIP115 Chain IDs), but doesn't support "legacy" transactions. Unfortunately, it turns out that some contracts rely on legacy transactions so that they can be deployed at the same address no matter what chain they're deployed to. Specifically, they rely on the fact that the transaction is not scoped to a specific chain so that the same message can be re-used to deploy the same contract across multiple chains.

For context, Filecoin supports EIP1559 transactions by converting them to standard Filecoin messages with a special signature type of "delegated" (where the Ethereum transaction signature is stored). Clients validate these messages by:

1. Noticing that the signature type is "delegated".
2. Determining that the "from" address is an Ethereum account (starts with f410f...).
3. Translating the Filecoin message back into an EIP1559 transaction and validating its signature.

Eventually, any signature marked "delegated" will be validated by the sender's account itself (think account abstraction). That is, "delegated" means that signature validation is delegated to the sender's account. But for now, the client does this explicitly.

Unfortunately, supporting legacy transactions throws a wrench into step 3. We can easily translate legacy transactions into Filecoin messages, but translating them back into legacy transactions means we need some way to detect the transaction type.

Solutions include:

1. Try both ways. That is, try to convert the Filecoin message to both an EIP1559 transaction and a legacy transaction, validating the signature over both formats. If it correctly validates in either case, accept the message. Unfortunately, this doubles the cost of signature validation (and is pretty nasty).
2. Another solution is to add another signature type (and rename the current "delegated" type to "eip1559", or something like that. Unfortunately, this will squash our future account abstraction plans, so I'd rather not do this unless we decide to entirely give up on them.
3. We could also prepend a transaction type byte to the signature field (for Ethereum transactions only). IMO, this is the best solution, but it may break any tooling manually signing/validating messages from Ethereum accounts. On the other hand, I'm doubtful any tooling like this exists, so we're probably fine.
4. Finally, we take advantage of the fact that the signature field of a EIP1559 transaction converted into a Filecoin message is always 65 bytes by appending a "type" byte to the signature if, and only if, we're dealing with a non-EIP1559 transaction. This is the least-likely to break existing tooling.

Personally, I'd propose option 3 as it's the cleanest, falling back on option 4 if we feel that option 3 is likely to cause issues.

[jennijuju]

I’m supportive of adding this feature as it blocks builders & limits tooling comparability

[raulk]

Solution 3 makes sense. I largely regarded the signature of Delegated transaction types as opaque to the protocol, in the sense that in the future we expect them to be validated by abstract accounts actors, and not by client logic. So, from that perspective, f410 account support (understood as the loose collection of components that enable f410 accounts) should be free to structure the signature as it sees fit, and there is no reason it should match byte-per-byte the Ethereum form.

[Schwartz10]

Would love to get this implemented because it will result in more generic wallet support for Filecoin. At glif we get a lot of users complaining about this:

e.g.

[smagdali]

Of the 4 options, my vote would be for the one that fixes the interop issues with least lifting required by the external parties currently hurt by this. @Schwartz10 Do you have any opinions on the 4 options?

[thelostone-mc]

Running into a similar issue while attempting to deploy https://github.com/allo-protocol/allo-v2/ onto filecoin

[aarshkshah1992]

Digging into this and taking ownership for shipping this.

[aarshkshah1992]

@Stebalien @Schwartz10 I am assuming that when we say "legacy" transactions here, we mean not just non-EIP-1599 transactions but also non-EIP-155 transactions i.e. transactions without a chainID.

[Stebalien]

I think, yes. But @Schwartz10 should confirm.

[aarshkshah1992]

@Schwartz10 By legacy transactions, do we mean ETH "Homstead" transactions without chainID and Accesslists and any of the EIP-1599 params ?

Basically, which ETH "legacy" transaction type do we want to support here ?

[i-norden]

https://github.com/ethereum/go-ethereum/blob/master/core/types/tx_legacy.go#L27

[aarshkshah1992]

Is there a reason users can't just convert legacy txns -> eip-1599 on the front-end and submit those signed txns to Filecoin ?

[aarshkshah1992]

This has been resolved. The problem is that some legacy contracts rely on legacy transactions, not legacy clients.

[Stebalien]

Because we don't have the key. Users use legacy txns so contracts can be deployed at consistent addresses on any chain, taking advantage of the message replay issue.

[Stebalien]

Basically:

1. Contract author signs a legacy deployment transaction from some ephemeral account and throws away the account's key (ideally uses a multi-party computation).
2. Contract author publishes this message on the web.

Now, anyone can submit this message to their chain (after funding the sending account on their chain) to deploy this contract. Importantly, because the deployment message is identical across all chains, the contracts address will also be identical.

[aarshkshah1992]

@Stebalien The contract address is a function of the sender address and nonce. Oh I see. We're using the contract signed by the original authour and that will always have the same nonce and same address no matter how many times we replay it and so we will always get the same contract address for every chain (albeit we can deploy this only once per chain because of nonce clashing).

[i-norden]

FWIW the only reliance contracts have on msg replay capability in order to deploy to the same address on different chains is one of convenience. You do not need to use the same exact message to deploy to the same address on another chain. Using CREATE you need the deployer account address and nonce to be the same. With CREATE2 instead of deriving from the deployer's account nonce it takes some salt that can reused (e.g. for the purpose of deployment across multiple chains without having to align nonces). In either case, the same exact signed message does not need to be reused.

[Stebalien]

Unfortunately, this is mostly an issue with contracts that have already been deployed on other chains (i.e., the ship has already sailed).

[aarshkshah1992]

Raised FIP for this at #995.

[aarshkshah1992]

Based on an offline Slack chat with Dmitri, looks like Fluence would also like to have this feature ! :)

[aarshkshah1992]

Glif is also interested in seeing Filecoin support legacy transactions.

[rvagg]

Unfortunately, this will squash our future account abstraction plans, so I'd rather not do this unless we decide to entirely give up on them.

Is there more context for this? Somewhere these plans are documented?

[Stebalien]

The discussion started in #388 but we've moved on in our thinking quite a bit from there. But I don't think we have any fully up-to-date documentation. We had a lot of trouble getting "paymasters" working and, in general, our tipset model caused a lot of issues.

[aarshkshah1992]

TLDR: I think we might have to update the FIP and implementation to enable support for EIP-155 legacy transactions as well if we want better inter-op with existing wallets

• So, we're introducing support for legacy ETH transactions with Support Ethereum Legacy Transactions #962
• However, these are NOT legacy EIP-155 transactions (https://eips.ethereum.org/EIPS/eip-155) i.e. the V value in the signature does not encode the ChainID even if one is available. The transactions supported in that FIP are pre-EIP155 Homestead transactions where the V value is 27 or 28 and there is no replay protection as there is no concept of a ChainID
• However, even for legacy transactions, it looks like wallets such as Metamask etc assume that a ChainID is always present and encode it in the V value of the signature which means that the FIP in it's current form wont be able to support these "legacy transactions" thus defeating a main use case of introducing this FIP i.e. we want better interop for legacy txns with existing wallets
• Please can we have some feedback on this ? Should we introduce support for EIP-155 transactions in this FIP as well or are people only looking for support for Homestead transactions that have no replay protection ?

[rvagg]

It's unclear to me how the use-cases for this FIP map on to proper-legacy and EIP-155 transactions. It seems obvious from your testing that popular wallets want to do EIP-155 and call that "legacy homestead", so adding support would be a very positive step for that. But for the original case driving this FIP, of porting smart contracts, does that also require EIP-155? Or is it sufficiently entangled with the wallet support that we're looking at the same blocker?

The code difference required to make this work is relatively small, with the most novel work being around dealing with the different V encoding: https://github.com/filecoin-project/lotus/pull/11930/files/a0e1801bf64ef224dc33a1b2c2af1d196d44eadc..770d427479cf43ae2cd48b0353427ab8a1071222#diff-e7dbef00867d75fa58dbc4202bbe477f35efcaff402873ddb286e9e2de35801eR178-R182 - I think that supports the case for updating the FIP.

Is there a world in which we should only add EIP-155 and not go as far as pre-EIP-155? That's worth considering under the more features != more better lens, it's just more things that we need to support which strains resources.

[aarshkshah1992]

@rvagg

1. We need EIP-155 transactions to enable support for Glif, Coinbase Wallet, Phantom Wallet etc with EVM based Filecoin transactions as they use EIP-155 transactions under the hood. This is a big unlock for the ecosystem:
   The code difference with Homestead transactions entails two things:
   a) Enabling chain replay protection by extracting the ChainID from the V value in the signature and making sure it matches the ChainID of the node (as you have pointed out above)

   b) There is a difference in how we construct the digest for signature verification for EIP-155 transactions namely that we include the ChainID in the digest but not in the serialised transaction that is broadcast among nodes (as the digest can be reconstructed by extracting the ChainID from the V value of the signature)

2. Supporting pre-EIP-155 legacy transactions is what started this entire discussion. See @Stebalien 's comment at Support Ethereum Legacy Transactions #962 (comment). It enables deployment of legacy smart contracts already running in the wild on other EVM based chains that were created through legacy deployment transactions that do not have a ChainID at all.

[rvagg]

Supporting pre-EIP-155 legacy transactions is what started this entire discussion

I was under the impression it was "pre-EIP-1559" legacy transactions, so I was wondering if the distinction between the two legacy types mattered in this context and that maybe EIP-155 gives us what we need on both counts? I guess since it contains a chainID in the V that the answer is no and we need both.

[ZenGround0]

Is there a world in which we should only add EIP-155 and not go as far as pre-EIP-155?

I have the same question. Does the chainID in V mean that the chainID must be checked or just that it can be checked? Can we recreate the original "one message works on any chain" behavior with only the latest EIP 155 messages? Or do we truly need homestead to get that behavior?

[aarshkshah1992]

Hey , we need to support both the transaction types as the two transaction types serve different use cases. Let me elaborate:

1. "Pre-EIP-155" legacy transactions AKA Homestead transactions (AKA "old legacy transactions")

• These are NOT scoped to a specific chain. There is no concept of a ChainID in these transactions and so they do not offer chain replay protection i.e. the same sender can replay the same signed transactions across two different chains and both will be executed (as long as the nonces align on both chains ofcourse). These belong to the pre-2016 era of Ethereum.
• The reason we need to support this transaction type is that there are already signed contract creation "ChainID-less" legacy transactions in the wild where the private keys don't exist anymore (which is why @Stebalien crated this discussion). These transactions can be used to deploy the contracts on Filecoin only if Filecoin supports these transactions.

2. EIP-155 transactions (also AKA legacy transactions but "new legacy transactions")

• These transactions introduced chain replay protection to Ethereum transactions for the first time i.e. these transactions are scoped to a specific chain and the same transaction can not be replayed across multiple chains. The sender needs to create and sign different transactions for different chains (because the chains differ in their ChainID)
• The way these transactions work is be encoding the ChainID in the V value of the ETH signature and also making the ChainID a part of the tx digest that is signed by the user. Thus, the user signs the transactions for a specific chain. The signature verification should fail if there is a mismatch between the ChainID of the chain and the ChainID of the transaction.
• The chain thus needs to assert that the ChainID on the transaction matches the ChainID of the chain and offer chain replay protection to users.
• We need to support these as Coinbase Wallet etc use EIP-155 transactions under the hood when talking to EVM chains. We also can't ignore the ChainID set on the transaction and actually enforce chain replay protection.

Thus, both these transactions types are different - the former has no ChainID and offers no chain replay protection to users whereas the latter has a ChainID and offers chain replay protection and there are valid use cases for both in the context of enabling better ETH compatibility on Filecoin. Even go-ethereum supports both these transaction types.

[jsoares]

From the FIP:

The ETH RPC APIs will be enhanced to facilitate the reading and writing of legacy transactions. Importantly, all modifications to the existing ETH RPC APIs will maintain backward compatibility to ensure that current users and tools remain unaffected.

A learning from IPC/Fendermint is that Blockscout is somewhat particular about the combination of fields returned for each type of transaction. This isn't a matter for the FIP, just something to consider in the API changes and in the ongoing work with Blockscout to add support for Filecoin.

[aarshkshah1992]

Okay understood.

[jennijuju]

@arajasek follow-up on filecoin-project/lotus#11969 (review) - given fip is still in last call, I’d encourage you to raise your opinions here before it’s accepted, especially if you feel strongly about it’s not a 👍🏻thing for the network

[jennijuju]

FWIW I disagree with the following

I'm not too strongly in favour of this change, it's adding a lot more edgecase-handling to what is already one of the gnarliest parts of the Filecoin protocol. .....But I do think this is a step in the wrong direction.
In particular, I don't think we should lean into an attitude of "#962 (comment)". It's still very much sharp edges in the protocol, and the fact that it's in the client only means that it needs to be (potentially incorrectly / incompatibly) re-implemented by Forest and Venus too.

I think client implementers should implement protocol features based on what the network & its users need instead & deliver clean implementation as much as possible. Surely some features are tricker to implement, but I doubt this one is marginally close to be considered aa complicated or "high risk" change.

[arajasek]

I didn't raise it here because I think the product needs stated above trump my objection, but happy to have it preserved for the record.

[arajasek]

I think client implementers should implement protocol features based on what the network & its users need instead & deliver clean implementation as much as possible.

This has nothing to do with what implementers should do (though I agree they should aim for clean code, obviously). The point that I'm trying to make is that we shouldn't make changes that make the protocol yet more convoluted. This is a problem we've repeatedly made, to the point where a simple change like moving around partitions is now so complicated that we literally don't know how to do it safely.

I view this FIP as worsening that problem -- the handling of so-called "delegated" signatures in Filecoin today is already sloppy, and this change is a major worsening of that problem. I'm happy to say the pendulum swings in favour of this FIP because of the strong user demand expressed above, but we should at least agree that this is messy. And I do not agree that this is opaque to the protocol just because it's not in actors / VM code.

Surely some features are tricker to implement, but I doubt this one is marginally close to be considered aa complicated or "high risk" change.

I'll agree with that when we have it correctly and safely implemented and tested.

[crystalbit]

Hey! Dmitrii from Fluence here

As for one of our cases, for example we need to have Safe contract on their usual address on Filecoin.
They have prepared legacy txs for many chains, filecoin is here: https://github.com/safe-global/safe-singleton-factory/blob/e0da6b6ac6ae90cda554ebda88d2cdf5d5ef1938/artifacts/314/deployment.json

But for now I can do it only with original legacy transaction, which doesn't work for Filecoin

Does this FIP include this original type of legacy tx?

[aarshkshah1992]

@crystalbit Yes it does.