From 2fc3d8e09e1340df91b8ed748de1ff6bd2cc6bd0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ra=C3=BAl=20Kripalani?= Date: Wed, 21 Dec 2022 17:29:55 +0000 Subject: [PATCH 01/16] draft for Ethereum accounts, addresses, and signatures. --- FIPS/fip-nnnn-eam-eth-accounts.md | 386 ++++++++++++++++++++++++++++++ 1 file changed, 386 insertions(+) create mode 100644 FIPS/fip-nnnn-eam-eth-accounts.md diff --git a/FIPS/fip-nnnn-eam-eth-accounts.md b/FIPS/fip-nnnn-eam-eth-accounts.md new file mode 100644 index 00000000..8fa4d004 --- /dev/null +++ b/FIPS/fip-nnnn-eam-eth-accounts.md @@ -0,0 +1,386 @@ +--- +fip: +title: Supporting Ethereum accounts, addresses, and transactions +author: Raúl Kripalani (@raulk), Steven Allen (@stebalien) +discussions-to: +status: Draft +type: Technical Core +category: Core +created: 2022-12-02 +spec-sections: +requires: N/A +replaces: N/A +--- + +# Supporting Ethereum accounts, addresses, and transactions + + + +**Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)* + +- [Simple Summary](#simple-summary) +- [Abstract](#abstract) +- [Change Motivation](#change-motivation) +- [Specification](#specification) + - [Ethereum Address Manager (EAM)](#ethereum-address-manager-eam) + - [Installation and wiring](#installation-and-wiring) + - [EVM smart contract deployment via the EAM](#evm-smart-contract-deployment-via-the-eam) + - [State](#state) + - [Actor interface (methods)](#actor-interface-methods) + - [Method number `1` (`Constructor`)](#method-number-1-constructor) + - [Method number `2` (`Create`)](#method-number-2-create) + - [Method number `3` (`Create2`)](#method-number-3-create2) + - [Delegated signature type](#delegated-signature-type) + - [Transitory Delegated signature validation](#transitory-delegated-signature-validation) + - [Message transliteration](#message-transliteration) + - [Ethereum Account](#ethereum-account) + - [Installation and wiring](#installation-and-wiring-1) + - [Instantiation via promotion](#instantiation-via-promotion) + - [Actor interface (methods)](#actor-interface-methods-1) + - [State](#state-1) +- [Design Rationale](#design-rationale) + - [f410 address scope](#f410-address-scope) + - [Upgrade path towards Account Abstraction (AA)](#upgrade-path-towards-account-abstraction-aa) +- [Backwards Compatibility](#backwards-compatibility) +- [Test Cases](#test-cases) +- [Security Considerations](#security-considerations) +- [Incentive Considerations](#incentive-considerations) +- [Product Considerations](#product-considerations) +- [Implementation](#implementation) +- [Copyright](#copyright) + + + +## Simple Summary + +We introduce two actors: the **Ethereum Address Manager (EAM)** and the **Ethereum Account** actors. +Both actors are necessary to attain compatibility with Ethereum tooling. +We also introduce **Ethereum addresses** over the f4 address class, as well as a new **Delegated signature type** to accept native Ethereum transactions. + +## Abstract + +The Ethereum Address Manager (EAM) actor manages namespace `10` within the `f4` address class as defined in [FIP-0048]. +This namespace hosts Ethereum addresses in Filecoin. +Only Ethereum Accounts and EVM smart contracts deployed through the EAM acquire an Ethereum address. +These addresses begin with `f410` in textual form. +We use this notation throughout this document. + +The Ethereum Account actor represents an externally-owned Ethereum account, backed by a secp256k1 key. +It enables authenticating native RLP-encoded [EIP-1559 Ethereum transaction] submitted from Ethereum wallets, within the Filecoin protocol. +These messages are converted to Filecoin messages carrying a Delegated signature type. + +While baked into the protocol at this stage, the Ethereum Account and the Delegated signature type are extension points to eventually transition to future fully-fledged Account Abstraction (AA). + +## Change Motivation + +Foreign runtimes, like the EVM runtime introduced in FIP-TODO, often make assumptions about addressing schemes. +Programs deployed on those runtimes (e.g. EVM smart contracts) also inherit those assumptions. +Such assumptions come in the form of: + +- data types expectations +- cryptographic expectations (e.g. addresses derived from public keys) +- address predictability expectations (e.g. upon contract deployment) + +Fulfilling these expectations involves making Filecoin aware of Ethereum addresses, in a way that does not bake that awareness in the core protocol. +This is achieved by modelling Ethereum addresses over the newly-introduced `f4` delegated address class, under a dedicated namespace, managed by the EAM. + +Furthermore, supporting foreign runtimes in Filecoin is hardly useful if the tools and libraries built for those runtimes were unable to interact with Filecoin without changes. +Such handicap would harm easy reuse. +Supporting the submission and validation of transactions issued from wallets native to the original ecosystem is a must. +These capabilities are delivered by the Ethereum Account and the Delegated signature type, as a stepping stone towards full Account Abstraction (AA). + +## Specification + +### Ethereum Address Manager (EAM) + +We introduce the Ethereum Address Manager (EAM) actor as a singleton built-in actor, sitting at ID address `f010`. + +This actor manages the Ethereum address space, anchored at the f4 address namespace equalling its actor ID (`10` in decimal). +The address payload is the literal Ethereum address in binary form. +``` +# Ethereum address in Filecoin +0x04 || 0x10 || +``` + +The EAM also acts like a factory for EVM smart contracts, respecting Ethereum rules and semantics for the `CREATE` and `CREATE2` mechanisms for address generation. + +#### Installation and wiring + +During migration: + +1. The Wasm bytecode of the EAM (referred by its CodeCID) is linked under the System actor's registry under the key `"eam"`. +2. A single copy of the EAM is deployed as a singleton actor under ID address `f010`. + +The Init actor statically recognizes the EAM as an _authorized_ delegated address manager, and permits calls to its `InitActor#Exec4` method originating in it. +Address managers like the EAM use the `InitActor#Exec4` method to deploy new actors with delegated addresses under the namespace matching their actor ID (`10` in this case), with the address payload being provided as an argument. + +#### EVM smart contract deployment via the EAM + +The EAM offers two Filecoin methods `Create` and `Create2`, equivalent to their Ethereum counterparts. +In Ethereum, `CREATE` and `CREATE2` differ in their address generation rules: + +- `CREATE` computes the address in this manner: `Keccak-256(rlp_list(sender, nonce))`. It is thus non-deterministic. +- `CREATE2` computes the addres in this manner: `Keccak-256(rlp_list(0xff, sender, salt, bytecode))`. It is suitable for counterfactual deployments. + +EVM smart contracts are deployed to the Filecoin chain as follows: + +1. A contract deployment message is directed to the `Create` or `Create2` methods of the EAM. +2. The EAM computes the `f410` address as per the rules of the invoked method. + The resulting f410 address is semantically equivalent to the address Ethereum would've generated for the same inputs, thus retaining tool compatibility. +2. The EAM invokes the Init actor's `Exec4` method (see [FIP-0048]), supplying: + - The CodeCID of the EVM runtime actor. + - The EVM runtime actor's constructor parameters, concretely the EVM init code and original creator address. + - The assigned f410 address. + +#### State + +None. + +#### Actor interface (methods) + +##### Method number `1` (`Constructor`) + +The Constructor asserts that: + +1. It is being called by the System actor (f00). +2. It has been deployed on address `f10`. + +These checks prevent instantiation by users. + +_Input parameters_ + +None. + +_Return value_ + +None. + +_Errors_ + +- `USR_FORBIDDEN` (18) when attempts to instantiate this actor are made, or if deployed at an address other than f010. + +##### Method number `2` (`Create`) + +Deploys a smart contract taking EVM init bytecode and accepting a nonce from the user. +The Ethereum address (and therefore the f410 address) is calculated from these parameters. + +The `Create` method is to be used in two cases: + +1. When an EEOA deploys an EVM smart contract by submitting a native Ethereum message. +2. When a smart contract (running within the EVM runtime actor) calls the `CREATE` opcode. + +Note that this differs from Ethereum in that we take a user-provided nonce as a parameter. +This is necessary for the EAM to learn the nonce of a contract, when the `CREATE` opcode is used. +Technically, this allows an EEOA to deploy a contract with an arbitrary nonce, potentially using nonces in a non-contiguous manner. + +_Input parameters_ + +```rust +// DAG-CBOR tuple encoded. +pub struct CreateParams { + /// EVM init code. + pub initcode: Vec, + /// Nonce with which to create this smart contract. + pub nonce: u64, +} +``` + +_Return value_ + +```rust +// DAG-CBOR tuple encoded. +pub struct Return { + /// The ID of the EVM runtime actor that was constructed. + pub actor_id: ActorID, + /// Its f2 address. + pub robust_address: Address, + /// Its Ethereum address, translatable to an f410 address. + pub eth_address: [u8; 20], +} +``` + +_Errors_ + +TODO. + +##### Method number `3` (`Create2`) + +The deployment procedure is the same as `Create`, but this method takes a user-provided salt. +A deterministic Ethereum address (and therefore the f410 address) is calculated from these parameters. + +`Create2` only used when a smart contract (running within the EVM runtime actor) calls the `CREATE2` opcode. + +_Input parameters_ + +```rust +pub struct Create2Params { + /// EVM init code. + pub initcode: Vec, + /// User provided salt. + pub salt: [u8; 32], +} +``` + +_Return value_ + +Same as [`Create`](#method-number-1-create). + +### Delegated signature type + +We introduce a new `Delegated` signature type for Filecoin messages with serialized value `3`. +Delegated signatures are used in combination with abstract account senders, once Account Abstraction (AA) is fully realized. +Delegated signatures are opaque to the protocol, and are validated by actor logic. +However, we establish a transitory period where Delegated signatures are special-cased. + +#### Transitory Delegated signature validation + +We establish a transitory period whereby `Delegated` signatures are assumed to be secp256k1 signatures over the [RLP] representation of a native [EIP-1559 Ethereum transaction] sent from an Ethereum Acount actor. +This effectively couples the `Delegated` signature type to its only possible use at this stage, but provides an extension point for the future. + +Such transitory `Delegated` signatures must be verified by: + +1. Repacking the native RLP-encoded [EIP-1559 Ethereum transaction] from the Filecoin message (original signature payload). +2. Recovering the secp256k1 public key from such payload and the ECDSA signature. +3. Computing the Ethereum address from the secp256k1 public key by hashing the public key using Keccak-256, and retaining the last 20 bytes. +4. Calculating the corresponding f410 address (see conversion rules [EAM rules](#ethereum-address-manager-eam)). +5. Asserting that the sender's f410 address matches the expected f410 address. + +The client must perform this verification before chain inclusion, and before handing off the message to the FVM for execution. + +#### Message transliteration + +The RLP-encoded [EIP-1559 Ethereum transaction] is repacked in the following way from the Filecoin message. +Note that the top-level object is an [RLP] list, with 0-based indices. + +| Index | Ethereum Field | Source | +| ----- | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | +| 0 | Chain ID | Static network-specific chain ID, BE-encoded, stripped of leading zero bytes | +| 1 | Nonce | `FilecoinMessage#Nonce`, BE-encoded, stripped of leading zero bytes | +| 2 | Max priority fee gas | `FilecoinMessage#GasPremium`, BE-encoded, stripped of leading zero bytes | +| 3 | Max fee per gas | `FilecoinMessage#GasFeeCap`, BE-encoded, stripped of leading zero bytes | +| 4 | Gas limit | `FilecoinMessage#GasLimit`, BE-encoded, stripped of leading zero bytes | +| 5 | Recipient | Ethereum address extracted from f410 address in `FilecoinMessage#To`, or nil if `f010` (EAM), as this denotes a contract deployment | +| 6 | Value | `FilecoinMessage#Value` | +| 7 | Input data | `FilecoinMessage#Params` | +| 8 | Access list | TODO | + +### Ethereum Account + +We introduce the **Ethereum Account**, a non-singleton actor representing an external Ethereum identity backed by a secp256k1 key. +The **Ethereum Account** is a recognised message sender of messages with `Delegated` signatures, as per the scheme above. +Ethereum Accounts can only submit RLP-encoded EIP-1559 Ethereum transactions. + +#### Installation and wiring + +During the migration where this FIP goes live, the Wasm bytecode of the Ethereum Account (referred to by its CodeCID) is linked under the System actor's registry under the key `"ethaccount"`. + +#### Instantiation via promotion + +This actor cannot be instantiated via the Init actor. + +The FVM, and only the FVM, can instantiate an Ethereum Account through a special pathway that promotes an existing Placeholder actor to an Ethereum Account. +This happens on the first send (with nonce zero) from the Ethereum Account whose gas limit is sufficient to cover chain inclusion. + +Failure to meet chain inclusion gas will not cause Placeholder actor promotion to an Ethereum Account, even if the message is valid and bears nonce zero. + +The promotion is committed to the state tree even if the message subsequently fails by generating an exit code other than 0. + +#### Actor interface (methods) + +None. + +#### State + +None. + +## Design Rationale + +### f410 address scope + +The current solution only assigns f410 addresses to Ethereum Accounts and EVM smart contracts. +If an EVM smart contract wishes to interact with a Wasm actor, it must use a masked ID address. +Contrary to `f410`, ID addresses are reorg-unstable. +That is, the ID may change within the chain's finality window, i.e. 900 epochs. +Note othat the theoretical window for ID reorgs is 900 epochs, the probability decays as the chain progresses. + +We deliberately discarded assigning f410 addresses to non-Ethereum related actors to keep the design simple at this stage. +We expect the impact to be minimal because all user-deployed contracts at this stage _are_ EVM smart contracts, possessing `f410` addresses. +So these interactions are able to leverage f410 addresses: +1. Cross-contract calls and value transfers (EVM <> EVM). +2. Ethereum account to contract calls and value transfers, and viceversa (Eth Account <> EVM). + +The two interactions affected by this limitation are: +1. EVM smart contracts calls and transfers to Wasm actors. +2. EVM smart contract transfers to non-Ethereum accounts (f1/f3) addresses. + +For (1), the only non-singleton actor callable by EVM smart contracts is the _Miner actor_. +These can only be addressable by ID. +Having said that, Miner actors are unlikely to be involved in transactions early in their lifetime, so the impact of this issue may be limited. +However, Filecoin apps wishing to safeguard against ID reorgs can use external APIs to check if an ID used as an argument is within its reorg window, and can prevent such transactions. +Unfortunately the protocol does not offer a built-in way of fetching the creation epoch of an actor. + +For (2), transferring value to an inexistent f1 and f3 address from a smart contract is not possible because no ID address exists yet. +This is a hard limitation and cannot be worked around. + +Future revisions may enable assigning f410 addresses to any actor in the state tree. + +### Upgrade path towards Account Abstraction (AA) + +We prototyped Account Abstraction solutions extensively before submitting this FIP. +This FIP preserves the key extension points that will facilitate a (hopefully) elegant transition to fully-fledged Account Abstraction (AA). + +We forecast these rough steps to conduct the transition: + +1. Remove Delegated signature validation logic from clients, treating the signature as an opaque blob at the client level. +2. Perform AA-specific gas preflight checks in the client before accepting the message for inclusion, or propagating via the mpool. +3. Move the Ethereum transaction signature verification logic inside the `ethaccount` actor, so that it runs on-chain. +4. Generalise the Placeholder actor promotion path so that the relevant address manager gets to indicate the promotion target. Reconcile with (3). +5. Trigger the signature validation logic within the FVM the sender is an Abstract Account. + +## Backwards Compatibility + +Backwards compatibility is not affected, as this FIP introduces strictly additive features. + +## Test Cases + +TODO. + +## Security Considerations + +This FIP introduces a new signature type and a new transaction format to the protocol. +That is, we introduce new pathways to initiate transactions in the system, and extend the kinds of payloads that are entitled to do so. + +It is worthy to note that Filecoin already supports secp256k1 ECDSA signatures under signature type 1. +Clients are expected to reuse existing signature verification and key recovery logic. +However, what differs is the authentication logic. +The original signature payload must be reconstructed by repacking the RLP-encoded [EIP-1559 transaction]. +Any flaws in this logic is subject to security events. + +## Incentive Considerations + +No incentive considerations apply. + +## Product Considerations + +This FIP is essential to enable the product aspirations of FEVM (Filecoin EVM). +We expect seamless compatibility with existing Ethereum wallets, libraries, and tools. +However, we note the addressing limitations described in the [Design Rationale](#design-rationale) section may show up at the product level. +That said, we expect the consequences to be limited. + +## Implementation + +- The actor implementation lives in [`filecoin-project/builtin-actors`]. +- The reference FVM implementation lives in [`filecoin-project/ref-fvm`]. +- The reference client implementation lives in [`filecoin-project/lotus`]. + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + + +[`filecoin-project/builtin-actors`]: https://github.com/filecoin-project/builtin-actors +[`filecoin-project/ref-fvm`]: https://github.com/filecoin-project/ref-fvm +[`filecoin-project/lotus`]: https://github.com/filecoin-project/lotus +[FIP-0048]: https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0048.md +[EIP-1559 Ethereum transaction]: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md +[RLP]: https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/ \ No newline at end of file From 52e50f4fff8636e06500c2341133e6c0b80a10ac Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ra=C3=BAl=20Kripalani?= Date: Tue, 27 Dec 2022 17:19:22 +0000 Subject: [PATCH 02/16] complete draft and stamp with FIP number. --- FIPS/fip-nnnn-eam-eth-accounts.md | 81 ++++++++++++++++++------------- 1 file changed, 48 insertions(+), 33 deletions(-) diff --git a/FIPS/fip-nnnn-eam-eth-accounts.md b/FIPS/fip-nnnn-eam-eth-accounts.md index 8fa4d004..7700eddb 100644 --- a/FIPS/fip-nnnn-eam-eth-accounts.md +++ b/FIPS/fip-nnnn-eam-eth-accounts.md @@ -1,5 +1,5 @@ --- -fip: +fip: "0055" title: Supporting Ethereum accounts, addresses, and transactions author: Raúl Kripalani (@raulk), Steven Allen (@stebalien) discussions-to: @@ -8,7 +8,8 @@ type: Technical Core category: Core created: 2022-12-02 spec-sections: -requires: N/A +requires: + - 0054 replaces: N/A --- @@ -31,8 +32,8 @@ replaces: N/A - [Method number `2` (`Create`)](#method-number-2-create) - [Method number `3` (`Create2`)](#method-number-3-create2) - [Delegated signature type](#delegated-signature-type) - - [Transitory Delegated signature validation](#transitory-delegated-signature-validation) - - [Message transliteration](#message-transliteration) + - [Transitory validation](#transitory-validation) + - [Payload reconstitution](#payload-reconstitution) - [Ethereum Account](#ethereum-account) - [Installation and wiring](#installation-and-wiring-1) - [Instantiation via promotion](#instantiation-via-promotion) @@ -73,7 +74,7 @@ While baked into the protocol at this stage, the Ethereum Account and the Delega ## Change Motivation -Foreign runtimes, like the EVM runtime introduced in FIP-TODO, often make assumptions about addressing schemes. +Foreign runtimes, like the EVM runtime introduced in FIP-0054, often make assumptions about addressing schemes. Programs deployed on those runtimes (e.g. EVM smart contracts) also inherit those assumptions. Such assumptions come in the form of: @@ -161,15 +162,18 @@ _Errors_ ##### Method number `2` (`Create`) -Deploys a smart contract taking EVM init bytecode and accepting a nonce from the user. -The Ethereum address (and therefore the f410 address) is calculated from these parameters. +Deploys a smart contract taking EVM init bytecode and accepting a nonce from the user via `InitActor#Exec4`, assigning an f410 address to the contract. +The contract's f410 address is calculated using Ethereum heuristics for `CREATE`. + +The caller's Ethereum address (necessary for the `CREATE` logic) is extracted from the their f410 address. +If the caller lacks an f410 address, it defaults to the masked ID address form defined in FIP-0054. The `Create` method is to be used in two cases: 1. When an EEOA deploys an EVM smart contract by submitting a native Ethereum message. 2. When a smart contract (running within the EVM runtime actor) calls the `CREATE` opcode. -Note that this differs from Ethereum in that we take a user-provided nonce as a parameter. +Note that this method differs from Ethereum in that we take a user-provided nonce as a parameter. This is necessary for the EAM to learn the nonce of a contract, when the `CREATE` opcode is used. Technically, this allows an EEOA to deploy a contract with an arbitrary nonce, potentially using nonces in a non-contiguous manner. @@ -201,12 +205,12 @@ pub struct Return { _Errors_ -TODO. +- `USR_FORBIDDEN` (18) when the caller has an f4 address but it's not under namespace `10`. ##### Method number `3` (`Create2`) The deployment procedure is the same as `Create`, but this method takes a user-provided salt. -A deterministic Ethereum address (and therefore the f410 address) is calculated from these parameters. +A deterministic Ethereum address (and therefore the f410 address) is calculated from these parameters, using the original Ethereum `CREATE2` heuristics. `Create2` only used when a smart contract (running within the EVM runtime actor) calls the `CREATE2` opcode. @@ -225,6 +229,10 @@ _Return value_ Same as [`Create`](#method-number-1-create). +_Errors_ + +- `USR_FORBIDDEN` (18) when the caller has an f4 address but it's not under namespace `10`. + ### Delegated signature type We introduce a new `Delegated` signature type for Filecoin messages with serialized value `3`. @@ -232,43 +240,46 @@ Delegated signatures are used in combination with abstract account senders, once Delegated signatures are opaque to the protocol, and are validated by actor logic. However, we establish a transitory period where Delegated signatures are special-cased. -#### Transitory Delegated signature validation +#### Transitory validation We establish a transitory period whereby `Delegated` signatures are assumed to be secp256k1 signatures over the [RLP] representation of a native [EIP-1559 Ethereum transaction] sent from an Ethereum Acount actor. +The RLP representation is reconstituted from the Filecoin message as specified below. This effectively couples the `Delegated` signature type to its only possible use at this stage, but provides an extension point for the future. Such transitory `Delegated` signatures must be verified by: 1. Repacking the native RLP-encoded [EIP-1559 Ethereum transaction] from the Filecoin message (original signature payload). -2. Recovering the secp256k1 public key from such payload and the ECDSA signature. +2. Recovering the secp256k1 public key from such payload and the ECDSA signature included within the inner `Signature` struct of the chain message. 3. Computing the Ethereum address from the secp256k1 public key by hashing the public key using Keccak-256, and retaining the last 20 bytes. 4. Calculating the corresponding f410 address (see conversion rules [EAM rules](#ethereum-address-manager-eam)). 5. Asserting that the sender's f410 address matches the expected f410 address. The client must perform this verification before chain inclusion, and before handing off the message to the FVM for execution. -#### Message transliteration +#### Payload reconstitution + +To verify the Delegated signature, the unsigned RLP-encoded [EIP-1559 Ethereum transaction] is reconstituted in the following way from the Filecoin message. +The top-level object is an [RLP] list, and integers are encoded in the RLP way (big endian with no leading zeroes) -The RLP-encoded [EIP-1559 Ethereum transaction] is repacked in the following way from the Filecoin message. -Note that the top-level object is an [RLP] list, with 0-based indices. +| Pos | Ethereum Field | Source | +| ----- | --------------------- | -----------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| 0 | Chain ID | Static network-specific chain ID, re-encoded as an RLP integer | +| 1 | Nonce | `FilecoinMessage#Nonce`, re-encoded as an RLP integer | +| 2 | Max priority fee gas | `FilecoinMessage#GasPremium`, re-encoded as an RLP integer | +| 3 | Max fee per gas | `FilecoinMessage#GasFeeCap`, re-encoded as an RLP integer | +| 4 | Gas limit | `FilecoinMessage#GasLimit`, re-encoded as an RLP integer | +| 5 | Recipient | Ethereum address extracted from the f410 address in `FilecoinMessage#To`, or nil if `f010` (EAM), as this denotes a contract deployment, re-encoded as an RLP byte string | +| 6 | Value | `FilecoinMessage#Value`, re-encoded as an RLP integer | +| 7 | Input data | `FilecoinMessage#Params`, re-encoded as an RLP byte string | +| 8 | Access list | Empty. | -| Index | Ethereum Field | Source | -| ----- | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | -| 0 | Chain ID | Static network-specific chain ID, BE-encoded, stripped of leading zero bytes | -| 1 | Nonce | `FilecoinMessage#Nonce`, BE-encoded, stripped of leading zero bytes | -| 2 | Max priority fee gas | `FilecoinMessage#GasPremium`, BE-encoded, stripped of leading zero bytes | -| 3 | Max fee per gas | `FilecoinMessage#GasFeeCap`, BE-encoded, stripped of leading zero bytes | -| 4 | Gas limit | `FilecoinMessage#GasLimit`, BE-encoded, stripped of leading zero bytes | -| 5 | Recipient | Ethereum address extracted from f410 address in `FilecoinMessage#To`, or nil if `f010` (EAM), as this denotes a contract deployment | -| 6 | Value | `FilecoinMessage#Value` | -| 7 | Input data | `FilecoinMessage#Params` | -| 8 | Access list | TODO | +Note that the original transformation from the RLP message to the Filecoin message will be specified in an FRC for the Ethereum JSON-RPC endpoint. ### Ethereum Account We introduce the **Ethereum Account**, a non-singleton actor representing an external Ethereum identity backed by a secp256k1 key. The **Ethereum Account** is a recognised message sender of messages with `Delegated` signatures, as per the scheme above. -Ethereum Accounts can only submit RLP-encoded EIP-1559 Ethereum transactions. +Ethereum Accounts can only submit RLP-encoded [EIP-1559 Ethereum transaction]s. #### Installation and wiring @@ -306,10 +317,12 @@ Note othat the theoretical window for ID reorgs is 900 epochs, the probability d We deliberately discarded assigning f410 addresses to non-Ethereum related actors to keep the design simple at this stage. We expect the impact to be minimal because all user-deployed contracts at this stage _are_ EVM smart contracts, possessing `f410` addresses. So these interactions are able to leverage f410 addresses: + 1. Cross-contract calls and value transfers (EVM <> EVM). 2. Ethereum account to contract calls and value transfers, and viceversa (Eth Account <> EVM). The two interactions affected by this limitation are: + 1. EVM smart contracts calls and transfers to Wasm actors. 2. EVM smart contract transfers to non-Ethereum accounts (f1/f3) addresses. @@ -343,7 +356,9 @@ Backwards compatibility is not affected, as this FIP introduces strictly additiv ## Test Cases -TODO. +The reference implementations will include tests. + +This FIP may be enhanced with test vectors covering Delegated signature verification scenarios. ## Security Considerations @@ -353,7 +368,7 @@ That is, we introduce new pathways to initiate transactions in the system, and e It is worthy to note that Filecoin already supports secp256k1 ECDSA signatures under signature type 1. Clients are expected to reuse existing signature verification and key recovery logic. However, what differs is the authentication logic. -The original signature payload must be reconstructed by repacking the RLP-encoded [EIP-1559 transaction]. +The original signature payload must be reconstructed by repacking the RLP-encoded [EIP-1559 Ethereum transaction]. Any flaws in this logic is subject to security events. ## Incentive Considerations @@ -378,9 +393,9 @@ That said, we expect the consequences to be limited. Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -[`filecoin-project/builtin-actors`]: https://github.com/filecoin-project/builtin-actors -[`filecoin-project/ref-fvm`]: https://github.com/filecoin-project/ref-fvm -[`filecoin-project/lotus`]: https://github.com/filecoin-project/lotus [FIP-0048]: https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0048.md [EIP-1559 Ethereum transaction]: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md -[RLP]: https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/ \ No newline at end of file +[RLP]: https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/ +[`filecoin-project/builtin-actors`]: https://github.com/filecoin-project/builtin-actors +[`filecoin-project/ref-fvm`]: https://github.com/filecoin-project/ref-fvm +[`filecoin-project/lotus`]: https://github.com/filecoin-project/lotus \ No newline at end of file From baa68bbec64e62fe6f915fe649f94fb292ee097d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ra=C3=BAl=20Kripalani?= Date: Tue, 27 Dec 2022 17:19:50 +0000 Subject: [PATCH 03/16] rename to fip-0055.md. --- FIPS/{fip-nnnn-eam-eth-accounts.md => fip-0055.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename FIPS/{fip-nnnn-eam-eth-accounts.md => fip-0055.md} (100%) diff --git a/FIPS/fip-nnnn-eam-eth-accounts.md b/FIPS/fip-0055.md similarity index 100% rename from FIPS/fip-nnnn-eam-eth-accounts.md rename to FIPS/fip-0055.md From 171a25c53961d1f028ac8e6980e9a1f95ab0c60e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ra=C3=BAl=20Kripalani?= Date: Mon, 2 Jan 2023 12:45:33 +0000 Subject: [PATCH 04/16] apply APA style capitalization to title. --- FIPS/fip-0055.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/FIPS/fip-0055.md b/FIPS/fip-0055.md index 7700eddb..a8ad12d9 100644 --- a/FIPS/fip-0055.md +++ b/FIPS/fip-0055.md @@ -1,6 +1,6 @@ --- fip: "0055" -title: Supporting Ethereum accounts, addresses, and transactions +title: Supporting Ethereum Accounts, Addresses, and Transactions author: Raúl Kripalani (@raulk), Steven Allen (@stebalien) discussions-to: status: Draft @@ -13,7 +13,7 @@ requires: replaces: N/A --- -# Supporting Ethereum accounts, addresses, and transactions +# Supporting Ethereum Accounts, Addresses, and Transactions From 7d512d56b96fcfc1a86e5726fc812b5369fe5147 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ra=C3=BAl=20Kripalani?= Date: Mon, 2 Jan 2023 17:56:30 +0000 Subject: [PATCH 05/16] heavy editing round. --- FIPS/fip-0055.md | 332 ++++++++++++++++++++++++----------------------- 1 file changed, 172 insertions(+), 160 deletions(-) diff --git a/FIPS/fip-0055.md b/FIPS/fip-0055.md index a8ad12d9..cc3c7acf 100644 --- a/FIPS/fip-0055.md +++ b/FIPS/fip-0055.md @@ -25,28 +25,31 @@ replaces: N/A - [Specification](#specification) - [Ethereum Address Manager (EAM)](#ethereum-address-manager-eam) - [Installation and wiring](#installation-and-wiring) - - [EVM smart contract deployment via the EAM](#evm-smart-contract-deployment-via-the-eam) + - [Relationship with the Init actor](#relationship-with-the-init-actor) - [State](#state) - - [Actor interface (methods)](#actor-interface-methods) - - [Method number `1` (`Constructor`)](#method-number-1-constructor) - - [Method number `2` (`Create`)](#method-number-2-create) - - [Method number `3` (`Create2`)](#method-number-3-create2) + - [`Constructor` (method number `1`)](#constructor-method-number-1) + - [Contract factory methods](#contract-factory-methods) - [Delegated signature type](#delegated-signature-type) - [Transitory validation](#transitory-validation) - [Payload reconstitution](#payload-reconstitution) - [Ethereum Account](#ethereum-account) - [Installation and wiring](#installation-and-wiring-1) - - [Instantiation via promotion](#instantiation-via-promotion) - - [Actor interface (methods)](#actor-interface-methods-1) + - [Sender account](#sender-account) + - [Promotion](#promotion) + - [Actor interface](#actor-interface) - [State](#state-1) - [Design Rationale](#design-rationale) - - [f410 address scope](#f410-address-scope) - - [Upgrade path towards Account Abstraction (AA)](#upgrade-path-towards-account-abstraction-aa) + - [Upgrade path towards [Account Abstraction] (AA)](#upgrade-path-towards-account-abstraction-aa) - [Backwards Compatibility](#backwards-compatibility) - [Test Cases](#test-cases) - [Security Considerations](#security-considerations) + - [New signature type](#new-signature-type) + - [Inability to stably address some actors from EVM smart contracts](#inability-to-stably-address-some-actors-from-evm-smart-contracts) - [Incentive Considerations](#incentive-considerations) - [Product Considerations](#product-considerations) + - [Essential for ecosystem compatibility](#essential-for-ecosystem-compatibility) + - [Explorer adaptation](#explorer-adaptation) + - [Exchange adaptation](#exchange-adaptation) - [Implementation](#implementation) - [Copyright](#copyright) @@ -54,41 +57,50 @@ replaces: N/A ## Simple Summary -We introduce two actors: the **Ethereum Address Manager (EAM)** and the **Ethereum Account** actors. -Both actors are necessary to attain compatibility with Ethereum tooling. -We also introduce **Ethereum addresses** over the f4 address class, as well as a new **Delegated signature type** to accept native Ethereum transactions. +In order to enable existing Ethereum tools to seamlessly interact with the Filecoin network, it is necessary for Filecoin to: + +1. Recognize and deal with Ethereum addresses. +2. Fulfill Ethereum address expectations, both for accounts (secp256k1 public key derived) and contracts. +3. Model Ethereum's Externally-Owned Accounts (EOAs). +4. Support and validate native transactions issued by (EOAs) from Ethereum wallets. + +This FIP delivers these requirements by leveraging the f4 extensible address class (newly introduced in [FIP-0048]) to model Ethereum Addresses, managed by the **Ethereum Address Manager (EAM)** actor introduced herein. + +It also introduces the **Ethereum Account** actor to represent Ethereum Externally Owned accounts, capable of acting as message senders, and a new **Delegated signature type**, which enables validating native EIP-1559 Ethereum transactions carrying an secp256k1 ECDSA signatures over their RLP encoding. + +Both these elements act as extension points for an eventual fully-fledged [Account Abstraction] framework. ## Abstract -The Ethereum Address Manager (EAM) actor manages namespace `10` within the `f4` address class as defined in [FIP-0048]. -This namespace hosts Ethereum addresses in Filecoin. -Only Ethereum Accounts and EVM smart contracts deployed through the EAM acquire an Ethereum address. -These addresses begin with `f410` in textual form. -We use this notation throughout this document. +This FIP introduces three technical elements: -The Ethereum Account actor represents an externally-owned Ethereum account, backed by a secp256k1 key. -It enables authenticating native RLP-encoded [EIP-1559 Ethereum transaction] submitted from Ethereum wallets, within the Filecoin protocol. -These messages are converted to Filecoin messages carrying a Delegated signature type. +1. It formally defines the `f410` Ethereum address space, nested under decimal namespace `10` within the `f4` address class as defined in [FIP-0048]. + This address space is managed by the Ethereum Address Manager (EAM) actor, which also offers public methods to act as a factory for EVM smart contracts. + The address payload of an `f410` address is the original Ethereum address. + Ethereum addresses can be cast as `f410` addresses, and viceversa. -While baked into the protocol at this stage, the Ethereum Account and the Delegated signature type are extension points to eventually transition to future fully-fledged Account Abstraction (AA). +2. The Ethereum Account actor, representing an Externally-Owned Ethereum account, backed by a secp256k1 key, and capable of acting as a sender of native EIP-1559 Ethereum transactions. + This actor will eventually become an Abstract Account (AA) actor, once such framework is introduced. + +3. The Delegated signature type, carrying a signature eventually verified by actor code through [Account Abstraction] (AA). + At this time, Delegated signatures are special-cased secp256k1 ECDSA signatures over the RLP encoding of native EIP-1559 Ethereum transactions. ## Change Motivation -Foreign runtimes, like the EVM runtime introduced in FIP-0054, often make assumptions about addressing schemes. -Programs deployed on those runtimes (e.g. EVM smart contracts) also inherit those assumptions. -Such assumptions come in the form of: +The FVM is a multi-runtime execution environment, designed to accommodate various runtimes atop a Wasm-based foundation. +Supporting foreign addressing schemes, account models, and transaction formats is important to achieve full portability of programs, tools, libraries, and know-how to Filecoin. -- data types expectations -- cryptographic expectations (e.g. addresses derived from public keys) -- address predictability expectations (e.g. upon contract deployment) +In the case of the EVM runtime introduced in [FIP-0054], the runtime itself, as well as EVM smart contracts and tools, make various assumptions about addresses. +Concretely about their data type (uint160), derivation (from public key for accounts), and/or generation. +Fulfilling these assumptions is essential to avoid (a) breakage of original smart contracts and (b) long-ranged codebase forks with patches that would result in maintenance hell for Core Devs. +In addition, we'd like to refrain from baking these assumptions into the core protocol to avoid external coupling and unsustainable bespoke specialization. -Fulfilling these expectations involves making Filecoin aware of Ethereum addresses, in a way that does not bake that awareness in the core protocol. -This is achieved by modelling Ethereum addresses over the newly-introduced `f4` delegated address class, under a dedicated namespace, managed by the EAM. +We reconcile these requirements and constraints by modelling Ethereum addresses over the brand new `f4` delegated address class, under a dedicated namespace, managed by the Ethereum Address Manager actor introduced herein. -Furthermore, supporting foreign runtimes in Filecoin is hardly useful if the tools and libraries built for those runtimes were unable to interact with Filecoin without changes. -Such handicap would harm easy reuse. -Supporting the submission and validation of transactions issued from wallets native to the original ecosystem is a must. -These capabilities are delivered by the Ethereum Account and the Delegated signature type, as a stepping stone towards full Account Abstraction (AA). +Furthermore, when porting foreign runtimes to Filecoin, it is highly desirable to retain full tool and ecosystem stack compatibility with Filecoin. +This involves supporting transactions issued from existing wallets without modifications, verifying their native signature and authentication schemes. +The Delegated signature type and the Ethereum Account actor enable this. +They also serve as cornerstones for a future fully-fledged [Account Abstraction] (AA) framework in Filecoin. ## Specification @@ -96,14 +108,15 @@ These capabilities are delivered by the Ethereum Account and the Delegated signa We introduce the Ethereum Address Manager (EAM) actor as a singleton built-in actor, sitting at ID address `f010`. -This actor manages the Ethereum address space, anchored at the f4 address namespace equalling its actor ID (`10` in decimal). +This actor manages the Ethereum address space, anchored at the `f4` address namespace equalling its actor ID (`10` in decimal). + The address payload is the literal Ethereum address in binary form. ``` # Ethereum address in Filecoin 0x04 || 0x10 || ``` -The EAM also acts like a factory for EVM smart contracts, respecting Ethereum rules and semantics for the `CREATE` and `CREATE2` mechanisms for address generation. +The EAM also acts like an EVM smart contract factory, offering methods that respect the Ethereum address generation rules and semantics for the original `CREATE` and `CREATE2` mechanisms. #### Installation and wiring @@ -111,73 +124,60 @@ During migration: 1. The Wasm bytecode of the EAM (referred by its CodeCID) is linked under the System actor's registry under the key `"eam"`. 2. A single copy of the EAM is deployed as a singleton actor under ID address `f010`. +3. The EAM is allowed-listed in the Init actor as an _authorized_ delegated address manager. -The Init actor statically recognizes the EAM as an _authorized_ delegated address manager, and permits calls to its `InitActor#Exec4` method originating in it. -Address managers like the EAM use the `InitActor#Exec4` method to deploy new actors with delegated addresses under the namespace matching their actor ID (`10` in this case), with the address payload being provided as an argument. - -#### EVM smart contract deployment via the EAM +#### Relationship with the Init actor -The EAM offers two Filecoin methods `Create` and `Create2`, equivalent to their Ethereum counterparts. -In Ethereum, `CREATE` and `CREATE2` differ in their address generation rules: - -- `CREATE` computes the address in this manner: `Keccak-256(rlp_list(sender, nonce))`. It is thus non-deterministic. -- `CREATE2` computes the addres in this manner: `Keccak-256(rlp_list(0xff, sender, salt, bytecode))`. It is suitable for counterfactual deployments. - -EVM smart contracts are deployed to the Filecoin chain as follows: - -1. A contract deployment message is directed to the `Create` or `Create2` methods of the EAM. -2. The EAM computes the `f410` address as per the rules of the invoked method. - The resulting f410 address is semantically equivalent to the address Ethereum would've generated for the same inputs, thus retaining tool compatibility. -2. The EAM invokes the Init actor's `Exec4` method (see [FIP-0048]), supplying: - - The CodeCID of the EVM runtime actor. - - The EVM runtime actor's constructor parameters, concretely the EVM init code and original creator address. - - The assigned f410 address. +The Init actor statically recognizes the EAM as an _authorized_ delegated address manager, and allows it to call its `InitActor#Exec4` method. +Note that address managers like the EAM use the `InitActor#Exec4` method to deploy new actors with delegated f4 addresses under the namespace matching their actor ID (`10` in this case). +The caller provides the address payload as an argument to such method. For more details, refer to [FIP-0048]. #### State -None. - -#### Actor interface (methods) +This actor has no state. -##### Method number `1` (`Constructor`) +#### `Constructor` (method number `1`) -The Constructor asserts that: +The Constructor has no functional relevance. It is merely a safeguard to prevent accidental instantiation by users by asserting that: 1. It is being called by the System actor (f00). 2. It has been deployed on address `f10`. -These checks prevent instantiation by users. - -_Input parameters_ +The Constructor takes no input parameters and produces no return value. +It returns the `USR_FORBIDDEN` (18) exit code when the above assumptions are unmet. -None. +#### Contract factory methods -_Return value_ +To act like an EVM smart contract factory, the EAM offers two Filecoin methods `Create` (method number 2) and `Create2` (method number 3), equivalent to their Ethereum counterparts. -None. +The `Create` method is to be used in two cases: -_Errors_ +1. When an Ethereum Account deploys an EVM smart contract by submitting a native Ethereum message to Filecoin. +2. When a smart contract (running within the EVM runtime actor) calls the `CREATE` opcode. -- `USR_FORBIDDEN` (18) when attempts to instantiate this actor are made, or if deployed at an address other than f010. +The `Create2` method is only used when a smart contract running within the EVM runtime actor calls the `CREATE2` opcode. -##### Method number `2` (`Create`) +In Ethereum, `CREATE` and `CREATE2` differ in their Ethereum address generation rules: -Deploys a smart contract taking EVM init bytecode and accepting a nonce from the user via `InitActor#Exec4`, assigning an f410 address to the contract. -The contract's f410 address is calculated using Ethereum heuristics for `CREATE`. +- `CREATE` computes the address in this manner: `Keccak-256(rlp_list(sender, nonce))`. It is thus non-deterministic. +- `CREATE2` computes the address in this manner: `Keccak-256(rlp_list(0xff, sender, salt, bytecode))`. It is suitable for counterfactual deployments. -The caller's Ethereum address (necessary for the `CREATE` logic) is extracted from the their f410 address. -If the caller lacks an f410 address, it defaults to the masked ID address form defined in FIP-0054. +The Filecoin EAM `Create` and `Create2` methods match these heuristics to calculate Ethereum addresses (castable to `f410` Filecoin addresses). +The sender's Ethereum address is obtained by calling the `actor::lookup_delegated_address` syscall introduced in [FIP-0054], and extracting the Ethereum address from the `f410` address. +If the caller has no `f410` address, the EAM falls back to the masked ID address form defined in [FIP-0054]. -The `Create` method is to be used in two cases: +_General mechanics_ -1. When an EEOA deploys an EVM smart contract by submitting a native Ethereum message. -2. When a smart contract (running within the EVM runtime actor) calls the `CREATE` opcode. +EVM smart contracts are deployed to the Filecoin chain as follows: -Note that this method differs from Ethereum in that we take a user-provided nonce as a parameter. -This is necessary for the EAM to learn the nonce of a contract, when the `CREATE` opcode is used. -Technically, this allows an EEOA to deploy a contract with an arbitrary nonce, potentially using nonces in a non-contiguous manner. +1. The contract deployment message is directed to the `Create` or `Create2` methods of the EAM, containing the EVM init bytecode and further arguments (see below). +2. The EAM computes the would-be Ethereum address, respecting the original Ethereum semantics, thus retaining tool compatibility. +2. The EAM invokes the Init actor's `Exec4` method (see [FIP-0048]), supplying: + - The CodeCID of the EVM runtime actor (introduced in [FIP-0054]). + - The EVM runtime actor's constructor parameters, concretely the EVM init code and the address of the original creator. + - The computed Ethereum address, which the Init actor uses as the payload to form the `f410` address for binding it in its address registry. -_Input parameters_ +_`Create` Input parameters_ ```rust // DAG-CBOR tuple encoded. @@ -189,32 +189,11 @@ pub struct CreateParams { } ``` -_Return value_ - -```rust -// DAG-CBOR tuple encoded. -pub struct Return { - /// The ID of the EVM runtime actor that was constructed. - pub actor_id: ActorID, - /// Its f2 address. - pub robust_address: Address, - /// Its Ethereum address, translatable to an f410 address. - pub eth_address: [u8; 20], -} -``` - -_Errors_ - -- `USR_FORBIDDEN` (18) when the caller has an f4 address but it's not under namespace `10`. - -##### Method number `3` (`Create2`) - -The deployment procedure is the same as `Create`, but this method takes a user-provided salt. -A deterministic Ethereum address (and therefore the f410 address) is calculated from these parameters, using the original Ethereum `CREATE2` heuristics. - -`Create2` only used when a smart contract (running within the EVM runtime actor) calls the `CREATE2` opcode. +Note that this method differs from Ethereum in that we take a user-provided nonce as a parameter. +This is necessary for the EAM to learn the nonce of a contract, when the `CREATE` opcode is used. +Technically, this allows an Ethereum account to deploy a contract with an arbitrary nonce, potentially using nonces in a non-contiguous manner, but this is not deemed risky because the system guarantees no overwrites can happen. -_Input parameters_ +_`Create2` Input parameters_ ```rust pub struct Create2Params { @@ -225,9 +204,19 @@ pub struct Create2Params { } ``` -_Return value_ +_Return value from both `Create` and `Create2`_ -Same as [`Create`](#method-number-1-create). +```rust +// DAG-CBOR tuple encoded. +pub struct Return { + /// The ID of the EVM runtime actor that was constructed. + pub actor_id: ActorID, + /// Its f2 address. + pub robust_address: Address, + /// Its Ethereum address, translatable to an `f410` address. + pub eth_address: [u8; 20], +} +``` _Errors_ @@ -236,23 +225,23 @@ _Errors_ ### Delegated signature type We introduce a new `Delegated` signature type for Filecoin messages with serialized value `3`. -Delegated signatures are used in combination with abstract account senders, once Account Abstraction (AA) is fully realized. Delegated signatures are opaque to the protocol, and are validated by actor logic. +Delegated signatures will be used in combination with abstract account senders, once [Account Abstraction] (AA) is fully realized. However, we establish a transitory period where Delegated signatures are special-cased. #### Transitory validation We establish a transitory period whereby `Delegated` signatures are assumed to be secp256k1 signatures over the [RLP] representation of a native [EIP-1559 Ethereum transaction] sent from an Ethereum Acount actor. The RLP representation is reconstituted from the Filecoin message as specified below. -This effectively couples the `Delegated` signature type to its only possible use at this stage, but provides an extension point for the future. +This effectively couples the `Delegated` signature type to its only possible use at this stage, but provides an extension point for the future introduction of [Account Abstraction] (AA). Such transitory `Delegated` signatures must be verified by: -1. Repacking the native RLP-encoded [EIP-1559 Ethereum transaction] from the Filecoin message (original signature payload). -2. Recovering the secp256k1 public key from such payload and the ECDSA signature included within the inner `Signature` struct of the chain message. -3. Computing the Ethereum address from the secp256k1 public key by hashing the public key using Keccak-256, and retaining the last 20 bytes. -4. Calculating the corresponding f410 address (see conversion rules [EAM rules](#ethereum-address-manager-eam)). -5. Asserting that the sender's f410 address matches the expected f410 address. +1. Reforming and repacking the native RLP-encoded [EIP-1559 Ethereum transaction] from the Filecoin message (original signature payload). +2. Recovering the secp256k1 public key from such payload and the ECDSA signature bytes inside the `Delegated` signature. +3. Computing the Ethereum address from the secp256k1 public key by hashing the public key using Keccak-256, and retaining the last 20 bytes (i.e. original Ethereum address derivation logic). +4. Casting to an `f410` address (see conversion rules [EAM rules](#ethereum-address-manager-eam)). +5. Asserting that the message sender's `f410` address matches the computed `f410` address. The client must perform this verification before chain inclusion, and before handing off the message to the FVM for execution. @@ -268,7 +257,7 @@ The top-level object is an [RLP] list, and integers are encoded in the RLP way ( | 2 | Max priority fee gas | `FilecoinMessage#GasPremium`, re-encoded as an RLP integer | | 3 | Max fee per gas | `FilecoinMessage#GasFeeCap`, re-encoded as an RLP integer | | 4 | Gas limit | `FilecoinMessage#GasLimit`, re-encoded as an RLP integer | -| 5 | Recipient | Ethereum address extracted from the f410 address in `FilecoinMessage#To`, or nil if `f010` (EAM), as this denotes a contract deployment, re-encoded as an RLP byte string | +| 5 | Recipient | Ethereum address extracted from the `f410` address in `FilecoinMessage#To`, or nil if `f010` (EAM), as this denotes a contract deployment, re-encoded as an RLP byte string | | 6 | Value | `FilecoinMessage#Value`, re-encoded as an RLP integer | | 7 | Input data | `FilecoinMessage#Params`, re-encoded as an RLP byte string | | 8 | Access list | Empty. | @@ -278,25 +267,31 @@ Note that the original transformation from the RLP message to the Filecoin messa ### Ethereum Account We introduce the **Ethereum Account**, a non-singleton actor representing an external Ethereum identity backed by a secp256k1 key. -The **Ethereum Account** is a recognised message sender of messages with `Delegated` signatures, as per the scheme above. +The **Ethereum Account** must be recognized by the FVM and by clients as a valid message sender of messages with `Delegated` signatures, as per the scheme above. Ethereum Accounts can only submit RLP-encoded [EIP-1559 Ethereum transaction]s. #### Installation and wiring During the migration where this FIP goes live, the Wasm bytecode of the Ethereum Account (referred to by its CodeCID) is linked under the System actor's registry under the key `"ethaccount"`. -#### Instantiation via promotion +#### Sender account + +Filecoin clients and the FVM recognize the Ethereum Account as an authorized message sender. This includes components validating and executing messages, like the message pool, chain syncer, and executor. + +#### Promotion -This actor cannot be instantiated via the Init actor. +When the FVM executes the first message fulfilling the following characteristics, it promotes the Placeholder actor into an Ethereum Account by updating its CodeCID in-place, prior to executing the message. -The FVM, and only the FVM, can instantiate an Ethereum Account through a special pathway that promotes an existing Placeholder actor to an Ethereum Account. -This happens on the first send (with nonce zero) from the Ethereum Account whose gas limit is sufficient to cover chain inclusion. +1. The message carries a valid transitory Delegated signature. +2. The message carries nonce zero. +3. The message carries a gas limit sufficient to cover chain inclusion. +4. The `f410` address resolved from the recovered public secp256k1 key corresponds to a Placeholder actor. -Failure to meet chain inclusion gas will not cause Placeholder actor promotion to an Ethereum Account, even if the message is valid and bears nonce zero. +The promotion remains effective even if the message itself results in an exit code other than 0, including out of gas. -The promotion is committed to the state tree even if the message subsequently fails by generating an exit code other than 0. +Failure to meet chain inclusion gas will prevent the inclusion of the message and, therefore, will not promote the Placeholder into an Ethereum Account, even if we technically ascertained that the Placeholder corresponds to an Externally-Owned Account. -#### Actor interface (methods) +#### Actor interface None. @@ -306,41 +301,10 @@ None. ## Design Rationale -### f410 address scope - -The current solution only assigns f410 addresses to Ethereum Accounts and EVM smart contracts. -If an EVM smart contract wishes to interact with a Wasm actor, it must use a masked ID address. -Contrary to `f410`, ID addresses are reorg-unstable. -That is, the ID may change within the chain's finality window, i.e. 900 epochs. -Note othat the theoretical window for ID reorgs is 900 epochs, the probability decays as the chain progresses. - -We deliberately discarded assigning f410 addresses to non-Ethereum related actors to keep the design simple at this stage. -We expect the impact to be minimal because all user-deployed contracts at this stage _are_ EVM smart contracts, possessing `f410` addresses. -So these interactions are able to leverage f410 addresses: - -1. Cross-contract calls and value transfers (EVM <> EVM). -2. Ethereum account to contract calls and value transfers, and viceversa (Eth Account <> EVM). - -The two interactions affected by this limitation are: - -1. EVM smart contracts calls and transfers to Wasm actors. -2. EVM smart contract transfers to non-Ethereum accounts (f1/f3) addresses. - -For (1), the only non-singleton actor callable by EVM smart contracts is the _Miner actor_. -These can only be addressable by ID. -Having said that, Miner actors are unlikely to be involved in transactions early in their lifetime, so the impact of this issue may be limited. -However, Filecoin apps wishing to safeguard against ID reorgs can use external APIs to check if an ID used as an argument is within its reorg window, and can prevent such transactions. -Unfortunately the protocol does not offer a built-in way of fetching the creation epoch of an actor. - -For (2), transferring value to an inexistent f1 and f3 address from a smart contract is not possible because no ID address exists yet. -This is a hard limitation and cannot be worked around. - -Future revisions may enable assigning f410 addresses to any actor in the state tree. - -### Upgrade path towards Account Abstraction (AA) +### Upgrade path towards [Account Abstraction] (AA) -We prototyped Account Abstraction solutions extensively before submitting this FIP. -This FIP preserves the key extension points that will facilitate a (hopefully) elegant transition to fully-fledged Account Abstraction (AA). +We prototyped [Account Abstraction] solutions extensively before submitting this FIP. +This FIP preserves the key extension points that will facilitate a (projected) elegant transition to fully-fledged [Account Abstraction] (AA). We forecast these rough steps to conduct the transition: @@ -362,6 +326,8 @@ This FIP may be enhanced with test vectors covering Delegated signature verifica ## Security Considerations +### New signature type + This FIP introduces a new signature type and a new transaction format to the protocol. That is, we introduce new pathways to initiate transactions in the system, and extend the kinds of payloads that are entitled to do so. @@ -371,16 +337,60 @@ However, what differs is the authentication logic. The original signature payload must be reconstructed by repacking the RLP-encoded [EIP-1559 Ethereum transaction]. Any flaws in this logic is subject to security events. +### Inability to stably address some actors from EVM smart contracts + +The current solution **only** assigns `f410` addresses to Ethereum Accounts and EVM smart contracts. + +These interactions can benefit from stable `f410` addressing: + +1. Cross-contract calls and value transfers (EVM <> EVM). +2. Ethereum account to contract calls and value transfers, and viceversa (Eth Account <> EVM). + +These interactions cannot benefit from stable addressing: + +1. EVM smart contracts calls and transfers to Wasm actors. +2. EVM smart contract value transfers to non-Ethereum accounts (f1/f3 addresses). + +If an EVM smart contract wishes to interact with a Wasm actor, it must use a masked ID address (`0xff0000..` style addresses). + +Unfortunately, contrary to `f410` addresses, ID addresses are not reorg stable. +In other words, **the ID may be reassigned within the chain's finality window**, hence this security notice. +Note that even if the theoretical finality window is 900 epochs, the probability of reorgs decays as the chain progresses from the ID assignment. + +The implications of this limitation are as follows: + +1. Not a problem for singleton actors (e.g. power actor, storage market actor, etc.), as their ID addresses are fixed, but may be problematic for non-singleton actors. +2. As per [FIP-0050], the only non-singleton actor callable by EVM smart contracts is the _Miner actor_. + Interactions with recently-created miner actors are subject to reorg sensitivity. +3. Tranferring value to an f1 or f3 account can only be done via its masked ID address and is thus subject to reorg sensitivity. +4. Transferring value to Wasm non-singleton non-account actors (e.g. payment channels or multisigs) is also subject to reorg sensitivity. +5. Transferring value to an inexistent f1 and f3 address from a smart contract is not possible as no ID address exists yet. + +Unfortunately the protocol does not offer a built-in way to fetch the creation epoch of an actor, so implementing timing guards to prevent transfers or calls to reorgable ID addresses within contracts is impossible. + +Note that we deliberately discarded assigning `f410` addresses to non-Ethereum related actors at this stage to favor design simplicity in an already complex feature set, but we may revisit this decision in the future. + ## Incentive Considerations No incentive considerations apply. ## Product Considerations -This FIP is essential to enable the product aspirations of FEVM (Filecoin EVM). -We expect seamless compatibility with existing Ethereum wallets, libraries, and tools. -However, we note the addressing limitations described in the [Design Rationale](#design-rationale) section may show up at the product level. -That said, we expect the consequences to be limited. +### Essential for ecosystem compatibility + +This FIP is essential to enable the product aspirations of FEVM (Filecoin EVM), concretely the seamless compatibility with existing Ethereum wallets, libraries, and tools. + +### Explorer adaptation + +Explorers will need to adapt to display `f410` addresses bound to actors and their respective Ethereum addresses, on actor pages, message pages, and more. + +Explorers will need to recognize Ethereum Account actors and Delegated signatures. + +### Exchange adaptation + +Exchanges must support receiving funds from EVM smart contracts. + +Exchange may choose to enable sending to `f410` addresses, and may support taking in Ethereum addresses and converting them to `f410` addresses. ## Implementation @@ -393,6 +403,8 @@ That said, we expect the consequences to be limited. Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). +[FIP-0054]: https://github.com/filecoin-project/FIPs/pull/569 +[Account Abstraction]: https://github.com/filecoin-project/FIPs/discussions/388 [FIP-0048]: https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0048.md [EIP-1559 Ethereum transaction]: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md [RLP]: https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/ From 8340e7c35a636bbdd11a6b807e6c5ab004aa19e6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ra=C3=BAl=20Kripalani?= Date: Wed, 4 Jan 2023 13:32:53 +0000 Subject: [PATCH 06/16] apply suggestions from editor review. --- FIPS/fip-0055.md | 54 +++++++++++++++++++++++++++++++++++++----------- 1 file changed, 42 insertions(+), 12 deletions(-) diff --git a/FIPS/fip-0055.md b/FIPS/fip-0055.md index cc3c7acf..0a8492f6 100644 --- a/FIPS/fip-0055.md +++ b/FIPS/fip-0055.md @@ -2,7 +2,10 @@ fip: "0055" title: Supporting Ethereum Accounts, Addresses, and Transactions author: Raúl Kripalani (@raulk), Steven Allen (@stebalien) -discussions-to: +discussions-to: + - https://github.com/filecoin-project/FIPs/discussions/388 + - https://github.com/filecoin-project/FIPs/discussions/490 + - https://github.com/filecoin-project/FIPs/discussions/287 status: Draft type: Technical Core category: Core @@ -61,12 +64,12 @@ In order to enable existing Ethereum tools to seamlessly interact with the Filec 1. Recognize and deal with Ethereum addresses. 2. Fulfill Ethereum address expectations, both for accounts (secp256k1 public key derived) and contracts. -3. Model Ethereum's Externally-Owned Accounts (EOAs). +3. Model Ethereum's [Externally-Owned Accounts (EOAs)]. 4. Support and validate native transactions issued by (EOAs) from Ethereum wallets. -This FIP delivers these requirements by leveraging the f4 extensible address class (newly introduced in [FIP-0048]) to model Ethereum Addresses, managed by the **Ethereum Address Manager (EAM)** actor introduced herein. +This FIP delivers these requirements by leveraging the f4 extensible address class (newly introduced in [FIP-0048]) to model Ethereum Addresses, managed by the **Ethereum Address Manager (EAM)** built-in actor introduced herein. -It also introduces the **Ethereum Account** actor to represent Ethereum Externally Owned accounts, capable of acting as message senders, and a new **Delegated signature type**, which enables validating native EIP-1559 Ethereum transactions carrying an secp256k1 ECDSA signatures over their RLP encoding. +It also introduces the **Ethereum Account** built-in actor to represent Ethereum Externally Owned accounts, capable of acting as message senders, and a new **Delegated signature type**, which enables validating native [EIP-1559 Ethereum transaction]s carrying an secp256k1 ECDSA signatures over their RLP encoding. Both these elements act as extension points for an eventual fully-fledged [Account Abstraction] framework. @@ -75,12 +78,12 @@ Both these elements act as extension points for an eventual fully-fledged [Accou This FIP introduces three technical elements: 1. It formally defines the `f410` Ethereum address space, nested under decimal namespace `10` within the `f4` address class as defined in [FIP-0048]. - This address space is managed by the Ethereum Address Manager (EAM) actor, which also offers public methods to act as a factory for EVM smart contracts. + This address space is managed by the Ethereum Address Manager (EAM) built-in actor, which also offers public methods to act as a factory for EVM smart contracts. The address payload of an `f410` address is the original Ethereum address. Ethereum addresses can be cast as `f410` addresses, and viceversa. -2. The Ethereum Account actor, representing an Externally-Owned Ethereum account, backed by a secp256k1 key, and capable of acting as a sender of native EIP-1559 Ethereum transactions. - This actor will eventually become an Abstract Account (AA) actor, once such framework is introduced. +2. The Ethereum Account built-in actor, representing an Externally-Owned Ethereum account, backed by a secp256k1 key, and capable of acting as a sender of native EIP-1559 Ethereum transactions. + This actor will become an Abstract Account (AA) actor, if and when such framework is eventually introduced in the protocol. 3. The Delegated signature type, carrying a signature eventually verified by actor code through [Account Abstraction] (AA). At this time, Delegated signatures are special-cased secp256k1 ECDSA signatures over the RLP encoding of native EIP-1559 Ethereum transactions. @@ -106,14 +109,41 @@ They also serve as cornerstones for a future fully-fledged [Account Abstraction] ### Ethereum Address Manager (EAM) -We introduce the Ethereum Address Manager (EAM) actor as a singleton built-in actor, sitting at ID address `f010`. +We introduce the Ethereum Address Manager (EAM) built-in actor as a singleton built-in actor, sitting at ID address `f010`. This actor manages the Ethereum address space, anchored at the `f4` address namespace equalling its actor ID (`10` in decimal). +For more information on the f4 address class, refer to [FIP-0048]. + +The subaddress is the literal Ethereum address in binary form. -The address payload is the literal Ethereum address in binary form. ``` -# Ethereum address in Filecoin +# +# Ethereum address in Filecoin as an f4 address +# + 0x04 || 0x10 || +| | | +A B C + +# A: address class, also termed "protocol" +# B: leb128-encoded actor ID of address manager (termed "namespace") +# C: subaddress within the namespace +``` + +In textual form, this is represented as follows: + +``` +# +# Textual form of the above address +# + +"f4" || "10" || +| | | +A B C + +# A: address class, also termed "protocol" +# B: namespace as a decimal number with no padding +# C: subaddress (in this case the Ethereum address) with checksum appended, base32 encoded ``` The EAM also acts like an EVM smart contract factory, offering methods that respect the Ethereum address generation rules and semantics for the original `CREATE` and `CREATE2` mechanisms. @@ -266,7 +296,7 @@ Note that the original transformation from the RLP message to the Filecoin messa ### Ethereum Account -We introduce the **Ethereum Account**, a non-singleton actor representing an external Ethereum identity backed by a secp256k1 key. +We introduce the **Ethereum Account**, a non-singleton built-in actor representing an external Ethereum identity backed by a secp256k1 key. The **Ethereum Account** must be recognized by the FVM and by clients as a valid message sender of messages with `Delegated` signatures, as per the scheme above. Ethereum Accounts can only submit RLP-encoded [EIP-1559 Ethereum transaction]s. @@ -402,7 +432,7 @@ Exchange may choose to enable sending to `f410` addresses, and may support takin Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). - +[Externally-Owned Accounts (EOAs)]: https://ethereum.org/en/developers/docs/accounts/ [FIP-0054]: https://github.com/filecoin-project/FIPs/pull/569 [Account Abstraction]: https://github.com/filecoin-project/FIPs/discussions/388 [FIP-0048]: https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0048.md From ce57e1cc76d36f8268d343a85ba46d2e06b22a38 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ra=C3=BAl=20Kripalani?= Date: Wed, 4 Jan 2023 15:20:26 +0000 Subject: [PATCH 07/16] fix other instances of using f4 address 'payload' instead of 'subaddress'. --- FIPS/fip-0055.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/FIPS/fip-0055.md b/FIPS/fip-0055.md index 0a8492f6..82a030c8 100644 --- a/FIPS/fip-0055.md +++ b/FIPS/fip-0055.md @@ -79,7 +79,7 @@ This FIP introduces three technical elements: 1. It formally defines the `f410` Ethereum address space, nested under decimal namespace `10` within the `f4` address class as defined in [FIP-0048]. This address space is managed by the Ethereum Address Manager (EAM) built-in actor, which also offers public methods to act as a factory for EVM smart contracts. - The address payload of an `f410` address is the original Ethereum address. + The subaddress of an `f410` address is the original Ethereum address. Ethereum addresses can be cast as `f410` addresses, and viceversa. 2. The Ethereum Account built-in actor, representing an Externally-Owned Ethereum account, backed by a secp256k1 key, and capable of acting as a sender of native EIP-1559 Ethereum transactions. @@ -159,8 +159,9 @@ During migration: #### Relationship with the Init actor The Init actor statically recognizes the EAM as an _authorized_ delegated address manager, and allows it to call its `InitActor#Exec4` method. -Note that address managers like the EAM use the `InitActor#Exec4` method to deploy new actors with delegated f4 addresses under the namespace matching their actor ID (`10` in this case). -The caller provides the address payload as an argument to such method. For more details, refer to [FIP-0048]. +Note that address managers like the EAM use the `InitActor#Exec4` method to deploy new actors with a delegated f4 address under the namespace matching their actor ID (`10` in this case). +The caller provides the subaddress as an argument to such method. +For more details, refer to [FIP-0048]. #### State @@ -205,7 +206,7 @@ EVM smart contracts are deployed to the Filecoin chain as follows: 2. The EAM invokes the Init actor's `Exec4` method (see [FIP-0048]), supplying: - The CodeCID of the EVM runtime actor (introduced in [FIP-0054]). - The EVM runtime actor's constructor parameters, concretely the EVM init code and the address of the original creator. - - The computed Ethereum address, which the Init actor uses as the payload to form the `f410` address for binding it in its address registry. + - The computed Ethereum address, which the Init actor uses as the subaddress to form the `f410` address for binding it in its address registry. _`Create` Input parameters_ From 9a60842ae91997d6e89f3dd1a647323f17dd2d1f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ra=C3=BAl=20Kripalani?= Date: Mon, 9 Jan 2023 13:59:41 +0000 Subject: [PATCH 08/16] fix typos. --- FIPS/fip-0055.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/FIPS/fip-0055.md b/FIPS/fip-0055.md index 82a030c8..54378be0 100644 --- a/FIPS/fip-0055.md +++ b/FIPS/fip-0055.md @@ -69,7 +69,7 @@ In order to enable existing Ethereum tools to seamlessly interact with the Filec This FIP delivers these requirements by leveraging the f4 extensible address class (newly introduced in [FIP-0048]) to model Ethereum Addresses, managed by the **Ethereum Address Manager (EAM)** built-in actor introduced herein. -It also introduces the **Ethereum Account** built-in actor to represent Ethereum Externally Owned accounts, capable of acting as message senders, and a new **Delegated signature type**, which enables validating native [EIP-1559 Ethereum transaction]s carrying an secp256k1 ECDSA signatures over their RLP encoding. +It also introduces the **Ethereum Account** built-in actor to represent Ethereum Externally Owned accounts, capable of acting as message senders, and a new **Delegated signature type**, which enables validating native [EIP-1559 Ethereum transaction]s carrying a secp256k1 ECDSA signatures over their RLP encoding. Both these elements act as extension points for an eventual fully-fledged [Account Abstraction] framework. @@ -343,7 +343,7 @@ We forecast these rough steps to conduct the transition: 2. Perform AA-specific gas preflight checks in the client before accepting the message for inclusion, or propagating via the mpool. 3. Move the Ethereum transaction signature verification logic inside the `ethaccount` actor, so that it runs on-chain. 4. Generalise the Placeholder actor promotion path so that the relevant address manager gets to indicate the promotion target. Reconcile with (3). -5. Trigger the signature validation logic within the FVM the sender is an Abstract Account. +5. Trigger the signature validation logic within the FVM when the sender is an Abstract Account. ## Backwards Compatibility From 007f126f8c1845826acc7bf6b8fc8ed5a48d3f5f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ra=C3=BAl=20Kripalani?= Date: Mon, 9 Jan 2023 14:02:37 +0000 Subject: [PATCH 09/16] migration: specify that a new version of the init actor is deployed. --- FIPS/fip-0055.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FIPS/fip-0055.md b/FIPS/fip-0055.md index 54378be0..6546b7b2 100644 --- a/FIPS/fip-0055.md +++ b/FIPS/fip-0055.md @@ -154,7 +154,7 @@ During migration: 1. The Wasm bytecode of the EAM (referred by its CodeCID) is linked under the System actor's registry under the key `"eam"`. 2. A single copy of the EAM is deployed as a singleton actor under ID address `f010`. -3. The EAM is allowed-listed in the Init actor as an _authorized_ delegated address manager. +3. A new version of the _Init actor_ that recognized the EAM as an _authorized_ delegated address manager is deployed, by loading its Wasm bytecode to the blockstore, linking its CodeCID in the _System actor_, and updating `f01`'s CodeCID to it in the state tree. #### Relationship with the Init actor From 682e0f7b64d3347c84b98b4a25ee02df42bd385b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ra=C3=BAl=20Kripalani?= Date: Mon, 9 Jan 2023 14:05:42 +0000 Subject: [PATCH 10/16] clarify empty actor state == EMPTY_ARR_CID in state tree --- FIPS/fip-0055.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/FIPS/fip-0055.md b/FIPS/fip-0055.md index 6546b7b2..c10d1044 100644 --- a/FIPS/fip-0055.md +++ b/FIPS/fip-0055.md @@ -165,7 +165,7 @@ For more details, refer to [FIP-0048]. #### State -This actor has no state. +This actor has no state. The actor's `Head` field in the state tree is the `EMPTY_ARR_CID` static value, defined as the CID of an empty CBOR byte string. #### `Constructor` (method number `1`) @@ -328,7 +328,7 @@ None. #### State -None. +This actor has no state. The actor's `Head` field in the state tree is the `EMPTY_ARR_CID` static value, defined as the CID of an empty CBOR byte string. ## Design Rationale From 64ab02dc3ed585dd7e815a679f5e511823fb52f9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ra=C3=BAl=20Kripalani?= Date: Mon, 9 Jan 2023 14:07:03 +0000 Subject: [PATCH 11/16] failing to validate the signature leads to a signature verification failure. --- FIPS/fip-0055.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/FIPS/fip-0055.md b/FIPS/fip-0055.md index c10d1044..96da5a28 100644 --- a/FIPS/fip-0055.md +++ b/FIPS/fip-0055.md @@ -274,6 +274,8 @@ Such transitory `Delegated` signatures must be verified by: 4. Casting to an `f410` address (see conversion rules [EAM rules](#ethereum-address-manager-eam)). 5. Asserting that the message sender's `f410` address matches the computed `f410` address. +Should any of these steps fail, the signature must be considered invalid. + The client must perform this verification before chain inclusion, and before handing off the message to the FVM for execution. #### Payload reconstitution From 75b22a6581a5518b521df0de94c94c72e8734fc9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ra=C3=BAl=20Kripalani?= Date: Mon, 9 Jan 2023 14:19:52 +0000 Subject: [PATCH 12/16] backwards compatibility. --- FIPS/fip-0055.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/FIPS/fip-0055.md b/FIPS/fip-0055.md index 96da5a28..b12c657c 100644 --- a/FIPS/fip-0055.md +++ b/FIPS/fip-0055.md @@ -349,7 +349,10 @@ We forecast these rough steps to conduct the transition: ## Backwards Compatibility -Backwards compatibility is not affected, as this FIP introduces strictly additive features. +On a functional level, backwards compatibility is not affected, as this FIP introduces strictly additive features. +However, implementing this FIP will require built-in actor changes. +We expect the CodeCIDs of all built-in actors to be altered, as a consequence of the new and adjusted logic. +The new actor code will need to be linked in the System actor, and the CodeCID of all existing actors in the state tree will need to be patched to their new counterparts. ## Test Cases From 2cad288832495e8c447bfe6c91b1b9cda9312cd3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ra=C3=BAl=20Kripalani?= Date: Mon, 9 Jan 2023 14:23:44 +0000 Subject: [PATCH 13/16] link to branches. --- FIPS/fip-0055.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/FIPS/fip-0055.md b/FIPS/fip-0055.md index b12c657c..7646196c 100644 --- a/FIPS/fip-0055.md +++ b/FIPS/fip-0055.md @@ -430,9 +430,9 @@ Exchange may choose to enable sending to `f410` addresses, and may support takin ## Implementation -- The actor implementation lives in [`filecoin-project/builtin-actors`]. +- The actor implementation lives in [`filecoin-project/builtin-actors`], concretely in the [`next`](https://github.com/filecoin-project/builtin-actors/tree/next/) branch at the time of writing. - The reference FVM implementation lives in [`filecoin-project/ref-fvm`]. -- The reference client implementation lives in [`filecoin-project/lotus`]. +- The reference client implementation lives in [`filecoin-project/lotus`], concretely in the [`nv18-fevm`](https://github.com/filecoin-project/lotus/tree/feat/nv18-fevm) branch at the time of writing. ## Copyright From dfa9e091d8a89626a140130786ebc21861f288d3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ra=C3=BAl=20Kripalani?= Date: Mon, 9 Jan 2023 14:24:03 +0000 Subject: [PATCH 14/16] sort references. --- FIPS/fip-0055.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/FIPS/fip-0055.md b/FIPS/fip-0055.md index 7646196c..36173899 100644 --- a/FIPS/fip-0055.md +++ b/FIPS/fip-0055.md @@ -438,12 +438,12 @@ Exchange may choose to enable sending to `f410` addresses, and may support takin Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -[Externally-Owned Accounts (EOAs)]: https://ethereum.org/en/developers/docs/accounts/ -[FIP-0054]: https://github.com/filecoin-project/FIPs/pull/569 -[Account Abstraction]: https://github.com/filecoin-project/FIPs/discussions/388 -[FIP-0048]: https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0048.md -[EIP-1559 Ethereum transaction]: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md -[RLP]: https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/ [`filecoin-project/builtin-actors`]: https://github.com/filecoin-project/builtin-actors +[`filecoin-project/lotus`]: https://github.com/filecoin-project/lotus [`filecoin-project/ref-fvm`]: https://github.com/filecoin-project/ref-fvm -[`filecoin-project/lotus`]: https://github.com/filecoin-project/lotus \ No newline at end of file +[Account Abstraction]: https://github.com/filecoin-project/FIPs/discussions/388 +[EIP-1559 Ethereum transaction]: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md +[Externally-Owned Accounts (EOAs)]: https://ethereum.org/en/developers/docs/accounts/ +[FIP-0048]: https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0048.md +[FIP-0054]: https://github.com/filecoin-project/FIPs/pull/569 +[RLP]: https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/ \ No newline at end of file From f4fb1d83ca960e2b6830aff6bf915d1506448e62 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ra=C3=BAl=20Kripalani?= Date: Mon, 9 Jan 2023 14:29:48 +0000 Subject: [PATCH 15/16] add creation of null EthAccount in migration. --- FIPS/fip-0055.md | 1 + 1 file changed, 1 insertion(+) diff --git a/FIPS/fip-0055.md b/FIPS/fip-0055.md index 36173899..57209d00 100644 --- a/FIPS/fip-0055.md +++ b/FIPS/fip-0055.md @@ -155,6 +155,7 @@ During migration: 1. The Wasm bytecode of the EAM (referred by its CodeCID) is linked under the System actor's registry under the key `"eam"`. 2. A single copy of the EAM is deployed as a singleton actor under ID address `f010`. 3. A new version of the _Init actor_ that recognized the EAM as an _authorized_ delegated address manager is deployed, by loading its Wasm bytecode to the blockstore, linking its CodeCID in the _System actor_, and updating `f01`'s CodeCID to it in the state tree. +4. An Ethereum Account actor is created in the state tree with balance zero, nonce zero, and delegated address `f410faaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaonc6iji` (as per [FIP-0048]), corresponding to the Ethereum Null Address (0x0). #### Relationship with the Init actor From 53c50cbdb1f30535e29e4a795be3f5afc37a27e4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ra=C3=BAl=20Kripalani?= Date: Mon, 9 Jan 2023 15:56:18 +0000 Subject: [PATCH 16/16] remove list from frontmatter. --- FIPS/fip-0055.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/FIPS/fip-0055.md b/FIPS/fip-0055.md index 57209d00..8a11dcc3 100644 --- a/FIPS/fip-0055.md +++ b/FIPS/fip-0055.md @@ -2,10 +2,7 @@ fip: "0055" title: Supporting Ethereum Accounts, Addresses, and Transactions author: Raúl Kripalani (@raulk), Steven Allen (@stebalien) -discussions-to: - - https://github.com/filecoin-project/FIPs/discussions/388 - - https://github.com/filecoin-project/FIPs/discussions/490 - - https://github.com/filecoin-project/FIPs/discussions/287 +discussions-to: https://github.com/filecoin-project/FIPs/discussions/388 https://github.com/filecoin-project/FIPs/discussions/490 https://github.com/filecoin-project/FIPs/discussions/287 status: Draft type: Technical Core category: Core