Skip to content

Latest commit

 

History

History
212 lines (139 loc) · 21.5 KB

fip-0091.md

File metadata and controls

212 lines (139 loc) · 21.5 KB
Raw
fip title author discussions-to status type category created
0091
Add support for Homestead and EIP-155 Ethereum Transactions ("legacy" Ethereum transactions)
Aarsh (@DharmaBum)
Last Call
Technical
Core
2024-04-17

FIP-0091: Add support for Homestead and EIP-155 Ethereum Transactions ("legacy" Ethereum transactions)

Simple Summary

This FIP proposes the integration of Ethereum Homestead and EIP-155 transactions (collectively referred to as "legacy" transactions) into the Filecoin network. This addition complements the existing support for EIP-1559 transactions in Filecoin. Homestead transactions are crucial for enabling the deployment and operation of legacy contracts on Filecoin. Additionally, EIP-155 transactions will allow users to employ wallets like Coinbase Wallet to transmit EVM transactions to Filecoin.

This FIP focuses exclusively on the integration of Homestead and EIP-155 transactions. These legacy transactions lack several parameters found in newer transaction types, such as AccessList, MaxFeePerGas, and MaxPriorityFeePerGas. Moreover, they do not adhere to a specific "transaction type," a concept introduced in EIP-2718. The potential integration of EIP-2930 transactions will be addressed in future FIPs.

Abstract

The Filecoin network already supports EIP-1559 transactions. These transactions have a designated transaction type of 0x02 and have the following parameters:

type EIP1559Tx struct {
	ChainID             int
	Nonce               int
	To                  *EthAddress
	Value               big.Int
	MaxFeePerGas        big.Int
	MaxPriorityFeePerGas big.Int
	GasLimit            int
	Input               []byte
	AccessList          []EthHash
	V                   big.Int
	R                   big.Int
	S                   big.Int
}

However, Filecoin does not support Homestead transactions or EIP-155 transactions. These transactions do not have a designated transaction type and have the following parameters:

type LegacyEthTx struct {
	Nonce    int
	To       *EthAddress
	Value    big.Int
	GasPrice big.Int
	GasLimit int
	Input    []byte
	V        big.Int
	R        big.Int
	S        big.Int
}

For Homestead transactions, the main distinction relevant to this FIP is that Homestead transactions do not contain a ChainID, so the transactions are not scoped to a specific chain. This allows replaying the same signed contract creation transaction across multiple chains for deploying a contract and also enables the contract to have the same address across chains.

EIP-155 transactions do not have an explicit ChainID parameter but they are scoped to a specific chain and enable chain replay protection by encoding the ChainID in the V parameter of the signature, ensuring that the transaction digest signed by the user contains the ChainID. EIP-155 transactions allow users of wallets like Coinbase Wallet to send EVM transactions to Filecoin as these wallets use EIP-155 EVM transactions.

Support for legacy transactions on Filecoin will be enabled by prepending an extra marker byte to the signature of legacy transactions. This will allow Filecoin to detect that a transaction is a legacy transaction and to process and execute it accordingly. For Homestead transactions, the marker byte will be 0x01 and for EIP-155 transactions the marker byte will be 0x02.

The GasPrice parameter from the legacy transaction will be utilized to determine both the GasFeeCap and GasPremium parameters in the Filecoin message, as GasPrice encompasses the full cost per unit of gas that the sender is willing to pay. This logic will be the same for both Homestead transactions and EIP-155 transactions.

To ensure compatibility with Filecoin's signature verification, which only recognizes V values of 0 or 1 (as is also the case with the current signature verification implementation in go-ethereum), adjustments will be made to the V parameter in legacy transactions before verifying their signatures. Specifically, for Homestead transactions, 27 will be subtracted from the V parameter. For EIP-155 transactions, the adjustment will involve subtracting (2*ChainID + 35) from the V parameter.

This adjustment is necessary because, unlike EIP-1559 transactions supported by Filecoin that strictly use V values of 0 or 1, the V parameter in Homestead transactions can be either 27 or 28, and for EIP-155 transactions, it is calculated as (0 or 1 + (2 * ChainID + 35)) where the selection of 0 or 1 is the same as in EIP-1599 transactions.

A detailed specification for EIP-155 transactions is provided here.

Change Motivation

Homestead transactions lack a ChainID parameter, which means they are not tied to any specific blockchain. Consequently, the same signed Homestead contract creation transaction can be reused to deploy the same contract across different chains.

Many smart contracts currently active on various chains were initially deployed using Homestead transactions. These transactions were signed by the contract authors using ephemeral accounts, and the keys were subsequently discarded. These signed Homestead contract deployment transactions are now publicly available online.

By supporting Homestead ETH transactions, this FIP facilitates the easy deployment of these existing contracts on the Filecoin network. This is achieved by replaying the original, signed Homestead contract deployment transactions on the Filecoin network.

Furthermore, supporting EIP-155 transactions enables users of wallets like Coinbase Wallet, which only handle EIP-155 transactions, to send EVM transactions to Filecoin.

Specification

Filecoin supports EIP-1559 transactions by converting them into standard Filecoin messages. These messages are distinguished by a unique "delegated" signature type, which encapsulates the original Ethereum transaction signature. The validation process for these messages involves:

  1. Identifying the "delegated" signature type.
  2. Confirming that the "from" address originates from an Ethereum account (indicated by the prefix f410f...).
  3. Reconstructing the original EIP-1559 transaction from the Filecoin message and verifying its signature.

Handling Homestead Transactions

For Homestead transactions, the validation process is similar, with a crucial modification in the third step. To differentiate Homestead transactions from EIP-1559 and EIP-155 transactions and to accurately reconstruct the original Homestead Ethereum transaction from the Filecoin message, this FIP introduces a method to mark Homestead transactions uniquely. Specifically, it proposes prepending a distinct marker byte 0x01 to the signature of a Homestead ETH transaction.

This adjustment occurs after the Homestead transaction is submitted to a Filecoin node but before it is broadcast across the network.

It is straightforward to distinguish whether a newly submitted legacy ETH transaction is a Homestead transaction rather than an EIP-155 transaction. This distinction is possible because the V value in the signature of a Homestead transaction is either 27 or 28. In contrast, the V value for an EIP-155 transaction is calculated as (0 or 1) + (2 * ChainID + 35). Therefore, if a legacy transaction contains a V value of 27 or 28, it is determined to be a Homestead transaction and the marker byte 0x01 is appended to its signature before broadcasting it across the network.

Consequently, the signature length of a Homestead ETH transaction extends to 66 bytes, compared to 65 bytes for an EIP-1559 transaction. This modified signature is also stored in the chain state for Homestead transactions.

The revised steps for processing and validating a Filecoin message representing a Homestead Ethereum transaction are:

  1. Recognize the "delegated" signature type, indicating an Ethereum transaction.
  2. Verify that the "from" address is an Ethereum account (starting with f410f...).
  3. Distinguish the transaction type based on the signature length:
    • If the signature is 66 bytes long and starts with 0x01, it is translated to a Homestead ETH transaction.
    • If the signature is 65 bytes long, it corresponds to an EIP-1559 transaction.
  4. Validate the transaction parameters and signature (after ignoring the first marker byte 0x01 for Homestead ETH transactions as that is not part of the signature created by the user).

Handling EIP-155 Transactions

EIP-155 transactions provide chain replay protection by incorporating the ChainID in the V value of the signature. The V value is calculated as (0 or 1 + (2 * ChainID + 35)), where the selection of 0 or 1 is the same as in EIP-1599 transactions. Although the ChainID is part of the transaction digest signed by the user, it is not an explicit parameter in the transaction itself, as it is encoded in the V value.

To ensure chain replay protection, a Filecoin node must verify that the ChainID signed by the user in the transaction digest matches the ChainID of the network to which the node is connected.

To differentiate a Filecoin message representing an EIP-155 transaction from a Filecoin message representing an EIP-1559 or a Homestead transaction, and to accurately reconstruct the original EIP-155 transaction from the Filecoin message, this FIP proposes prepending a distinct marker byte 0x02 to the signature of an EIP-155 transaction. This adjustment takes place after the EIP-155 transaction is submitted to a Filecoin node but before it is broadcast across the network.

As mentioned earlier, it is easy to distinguish whether a newly submitted legacy ETH transaction is an EIP-155 transaction or a Homestead transaction based on the V value of the signature. The marker byte can be prepended to the signature accordingly before broadcasting it across the network.

The signature length for a Filecoin message representing an EIP-155 transaction can be calculated as (1 byte for the marker byte 0x02 + 32 bytes for the R value of the ETH signature + 32 bytes for the S value of the ETH signature + size of V value), where V is (0 or 1 + (2 * ChainID + 35)). Thus, the signature length depends on the size of the ChainID. However, since the ChainID is known at runtime, the signature length of a Filecoin message representing an EIP-155 transaction is also known at runtime.

The Filecoin mainnet ChainID is 314. Consequently, the signature length for a Filecoin message representing an EIP-155 Ethereum transaction is calculated as follows: 1 marker byte + 32 bytes for the R value + 32 bytes for the S value + 2 bytes for the mainnet ChainID, totaling 67 bytes. Currently, no Filecoin network ChainID is 1 byte in length, ensuring that the length of an EIP-155 signature will not coincide with that of a Homestead signature. Should this scenario arise in the future, the two can still be distinguished by examining the marker byte.

Based on the above, the revised steps for processing and validating a Filecoin message representing a EIP-155 transaction are:

  1. Recognize the "delegated" signature type, indicating an Ethereum transaction.
  2. Verify that the "from" address is an Ethereum account (starting with f410f...).
  3. Distinguish the transaction type based on the signature length:
    • If the signature is 66 bytes long and starts with 0x01, it is translated to a Homestead ETH transaction.
    • If the signature is 65 bytes long, it corresponds to an EIP-1559 transaction.
    • If the signature length is equal to the length of the expected EIP-155 signature length and starts with 0x02, it is translated to a EIP-155 transaction.
  4. Validate the transaction parameters and signature (after ignoring the first marker byte 0x02 for EIP-155 transactions as that is not part of the signature created by the user).
  5. Ensure that the ChainID signed by the user in the transaction digest is the same as the ChainID of the network

Note that this FIP does not need any changes to the EVM/FVM runtime and to built-in Actors.

Handling the GasPrice parameter of the legacy transaction

The Filecoin & FVM gas fee market follows a model similar to EIP-1559 and so expect Filecoin messages to contain both GasFeeCap and a GasPremium parameters on the transaction.

For EIP-1559 transactions, GasFeeCap and GasPremium parameters for the Filecoin message are derived from the MaxFeePerGas and MaxPriorityFeePerGas parameters on the EIP-1559 transaction respectively.

However, legacy ETH transactions only have a GasPrice parameter. To convert a legacy ETH transaction to a Filecoin message, both the GasFeeCap and GasPremium parameters will be set to the GasPrice set on the legacy transaction. This is because GasPrice already represents the full price per unit of gas that the user is willing to pay. See the Incentive Considerations section below for a detailed explanation.

This process is the same for both Homestead and EIP-155 transactions.

Specific Handling of the V Parameter in Signatures

The use of the V parameter in the signature of an Ethereum transaction and the values it can contain has gone through several iterations over the years. Here are the important points to note for the purpose of this FIP:

For EIP-1559 transactions that are supported by Filecoin, the V parameter in the signature can take a value of either 0 or 1. This helps determine which of the two possible Y coordinates is correct for the elliptic curve point that corresponds to the R part of the signature. This is necessary because the ECDSA signature produces an R value and an S value, but two possible Y coordinates can be derived from the X coordinate (R).

However, for Homestead transactions, the value of V was arbitrarily set to 27 (corresponds to 0 in EIP-1559 transactions) or 28 (corresponds to 1 in EIP-1559 transactions) and serves the same purpose of being able to specifically determine the parity of the Y coordinate corresponding to the R component of the signature.

Given that the current signature verification implementation for the delegated signature type(which is the signature type that will be used for both the legacy ETH transaction types in addition to EIP1559 transactions) only recognizes V values of 0 or 1, it is necessary to adjust the V value in the signature of Homestead transactions by subtracting 27. This adjustment must be made prior to the authentication and verification of the message's signature, as well as before extracting the public key and sender's address from the Homestead transaction's signature.

Note that this is only a temporary transformation for the purpose of a validating the signature of a Homestead transaction and for extracting the public key of the sender from the signature. The V value that gets persisted in the chain state for the Homestead transaction will be the original V value set on the transaction by the user.

For EIP-155 transactions, all of the same principles apply with one exception: since the V value of the signature in EIP-155 transactions is set to (0 or 1 + (2 * ChainID + 35)) to encode the ChainID in the V value, the V value must be adjusted by subtracting (2 * ChainID + 35). As described above for Homestead transactions, this adjustment for EIP-155 transactions must be made prior to the authentication and verification of the message's signature, as well as before extracting the public key and sender's address from the EIP-155 transaction's signature.

The go-ethereum implementation also uses the same method for handling the V value of legacy transactions before validating the signature as can be seen at https://github.com/ethereum/go-ethereum/blob/74e8d2da97aacc2589d39584f6af74cb9d62ee3f/core/types/transaction_signing.go#L543

Design Rationale

To facilitate support for legacy transactions in Filecoin, several approaches were evaluated:

  1. Attempt dual validation by converting the Filecoin message into both an EIP1559 transaction and a legacy transaction, and then validating the signature for both formats. If either validation succeeds, the message would be accepted. However, this method would double the cost of signature validation, making it inefficient and cumbersome.
  2. Introduce a new signature type and rename the existing "delegated" type to "eip1559" or similar. This approach, however, conflicts with our plans for future account abstraction, which we are not prepared to compromise.
  3. Prepend a transaction type byte exclusively to the signature field of Ethereum transactions. This solution is optimal as it introduces minimal complexity and is straightforward to implement.
  4. Utilize the consistent 65-byte length of the EIP1559 transaction signature in Filecoin messages by appending a "type" byte only for non-EIP1559 transactions.

After careful consideration, we selected the third option. It offers a balance of simplicity, efficiency, and minimal impact on existing systems.

Backwards Compatibility

This proposal introduces support for additional Ethereum transaction types within Filecoin. Given that transactions are integral to the chain state, this modification constitutes a consensus-breaking change, necessitating an upgrade across all nodes to accommodate legacy Ethereum transactions.

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.

Test Cases

All pre-existing unit tests for the ETH RPC API and ETH transactions should continue working as before. Comprehensive new unit tests will be written for legacy transactions.

Existing integration tests for the ETH RPC API and ETH transactions should continue working as before. Comprehensive new integration tests will be written for legacy transactions.

Deployment & Execution of contracts with signed legacy transactions will be tested rigorously on a devnet/butterfly/calibnet networks.

Security Considerations

This proposal does not introduce any reductions in security.

Incentive Considerations

Filecoin and the Filecoin Virtual Machine (FVM) adopt a gas fee market similar to Ethereum's EIP-1559 model. This model introduces two key parameters to manage gas fees for transactions:

  1. GasFeeCap: This parameter determines the maximum amount of attoFIL a user is prepared to pay per gas unit for executing a transaction. It serves as a cap on the total transaction fee, ensuring that the sum of the base fee and the priority fee paid to miners does not exceed the GasFeeCap.

  2. GasPremium: This parameter determines the highest attoFIL a user is willing to pay per gas unit as a priority fee to miners for including their transaction in a block. It effectively limits the priority fee, especially when the GasFeeCap is higher than the base fee.

For EIP-1559 transactions, the values for GasFeeCap and GasPremium in Filecoin messages are directly derived from the MaxFeePerGas and MaxPriorityFeePerGas parameters of the EIP-1559 transaction.

However, legacy Ethereum transactions only have a single GasPrice parameter, which specifies the gas price a sender is willing to pay per unit of gas to process the transaction.

Under the FVM fee market framework, when processing legacy transactions, GasPrice is adapted to simultaneously fulfill the roles of both GasFeeCap and GasPremium. In this adaptation, both GasFeeCap and GasPremium are set equal to GasPrice. Initially, the base fee is subtracted, and any remaining attoFIL from the GasPrice, after this deduction, is allocated entirely as a priority fee to the miner. This arrangement ensures that the total fee (base fee plus priority fee) paid by the user for a legacy transaction does not surpass the GasPrice set by the user on the legacy ETH transaction. However, note that this does incentivise SPs to hoard legacy user transactions and only include them in blocks when the base fee is low so that they can earn more priority fees.

This logic is the same for both Homestead and EIP-155 transactions.

Product Considerations

This FIP enhances the Filecoin network by facilitating the execution of legacy Ethereum transactions, thereby bolstering Filecoin's interoperability with pre-existing Ethereum tools, libraries, contract suites, and frameworks that assume such transactions.

A significant number of smart contracts on various chains were initially deployed using Homestead transactions, signed by the contract authors through ephemeral accounts. Subsequently, these keys were discarded, and the signed Homestead transactions for deploying these contracts became publicly accessible online. This FIP enables users to deploy these pre-signed contracts on the Filecoin network by directly replaying the existing Homestead contract creation transactions.

Moreover, some contracts rely on Homestead transactions so that they can be deployed at the same address regardless of the chain they are deployed on. Specifically, they depend on the fact that the transaction is not scoped to a specific chain, allowing the same message to be reused to deploy the same contract across multiple chains. This FIP enables the deployment and execution of such smart contracts on Filecoin, as Homestead transactions do not have a ChainID parameter and are thus not scoped to a specific chain.

This FIP also enables users to use mainstream wallets such as Coinbase Wallet to send EVM transactions to Filecoin, as those wallets use EIP-155 transactions.

Implementation

Implementation of this proposal is in progress on the following integration branch: https://github.com/filecoin-project/lotus/tree/integration/eth-legacy-tx.

Copyright

Copyright and related rights waived via CC0.