FIP-0055: Ethereum accounts, addresses, and signatures (broken out of FIP-0054) #580

raulk · 2022-12-21T17:42:57Z

This FIP breaks out the Ethereum Account (formally EEOA), EAM, Delegated signatures, and Ethereum addresses out of the monolith FIP-0054. This will allow for more focused and efficient community review.

Simple Summary

In order to enable existing Ethereum tools to seamlessly interact with the Filecoin network, it is necessary for Filecoin to:

Recognize and deal with Ethereum addresses.
Fulfill Ethereum address expectations, both for accounts (secp256k1 public key derived) and contracts.
Model Ethereum's Externally-Owned Accounts (EOAs).
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

This FIP introduces three technical elements:

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.
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.
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.

raulk · 2022-12-22T11:30:38Z

@jennijuju @kaitlin-beegle can I have a FIP number here, please?

jennijuju · 2022-12-26T23:13:03Z

FIPS/fip-nnnn-eam-eth-accounts.md

@@ -0,0 +1,386 @@
+---
+fip: <to be assigned>


jennijuju · 2022-12-26T23:13:30Z

Is this ready for editor review?

raulk · 2022-12-27T17:20:13Z

Is this ready for editor review?

Yes, please move through. FIP number incorporated.

FIPS/fip-0055.md

raulk · 2023-01-03T10:04:35Z

This FIP draft is ready for merge and should be close to Last Call quality.

kaitlin-beegle · 2023-01-04T04:54:01Z

FIPS/fip-0055.md

+fip: "0055"
+title: Supporting Ethereum Accounts, Addresses, and Transactions
+author: Raúl Kripalani (@raulk), Steven Allen (@stebalien)
+discussions-to: <URL>


There's not a clear need for this FIP to have its own discussion post, except that there ought to be a landing place for someone who wants to ask questions about this particular spec, etc.

Unless you want to open up a distinct comment thread, let's just direct them here: #287

Also happy if you want to link them to other discussions about the f4 address class or FVM actors; no preference on my end.

I've linked to these three discussion threads here:

Account abstraction #388

MVP Account Abstraction Proposal #490

Introducing the Filecoin Virtual Machine #287

FIPS/fip-0055.md

jennijuju · 2023-01-04T06:35:58Z

(im only half way through and will finish 👁️ tmr morning. @raulk could you please confirm if this PR is thorough review read in preparation of last call, or its just a draft update?

raulk · 2023-01-04T13:10:02Z

(im only half way through and will finish 👁️ tmr morning. @raulk could you please confirm if this PR is thorough review read in preparation of last call, or its just a draft update?

Feel free to do a Core Dev review in addition to a FIP Editor review here since my understanding is that we're pushing this over to Last Call imminently. But please separate both reviews as FIP Editor review may be blocking for merge, and Core Dev review might not be.

…ess'.

arajasek

Broadly looks good to me, various suggestions, only a couple blockers.

As a general note, this FIP is a little too forward-looking in terms of Account Abstraction. I think I understand the motivation for this approach to the FIP, and that future enhancement is germane to the design & history of this FIP, but it would be nicer if one could read & understand the specification of the immediate proposed change without thinking too much about future changes.

On an aside, it's really helpful for folks implementing migrations for network upgrades if a FIP specifies all necessary migration changes in a single section. This isn't especially relevant to this FIP (the migration is relatively simple, and has already been implemented in Golang), but I think it might be a good idea to modify the FIP template to add an explicit section for migrations. Note for future discussion.

FIPS/fip-0055.md

arajasek · 2023-01-05T14:58:14Z

FIPS/fip-0055.md

+
+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.


BLOCKER: I might be wrong, but I think this doesn't actually happen as part of the migration? Instead, the new Init Actor has the EAM pre-approved as an authorized delegated address manager.

Can resolve by either dropping this line, or telling me I'm wrong.

I think the discrepancy lies in that you interpreted this as an explicit action (e.g. there is some kind of transaction that happens after which the EAM becomes authorized), whereas I intended to write this as a constraint of the code. I can see why there's confusion here. Let me rejigger this.

I've tried to bring more accuracy to this in 007f126.

arajasek · 2023-01-05T15:11:47Z

FIPS/fip-0055.md

+
+#### State
+
+This actor has no state.


Can we make this a bit more explicit -- the Head of the EAM is set to the EMPTY_ARR_CID.

We also might want to specify that the migration should explicitly add this object to the state store? I'm not sure whether that's necessary, but I did so in the current Golang implementation of the migration.

Fixed in 682e0f7.

FIPS/fip-0055.md

arajasek · 2023-01-05T15:35:49Z

FIPS/fip-0055.md

+
+#### State
+
+None.


Similar note about State as for the EAM above.

Fixed in 682e0f7.

FIPS/fip-0055.md

arajasek · 2023-01-05T15:38:22Z

FIPS/fip-0055.md

+
+None.
+
+## Design Rationale


I don't think the upgrade path towards "full" AA is the only relevant design rationale to discuss. At the very least, I think we should reiterate (or extract and move here) some of the salient points under the Change Motivation section about wanting to to retain full Ethereum tooling and ecosystem stack compatibility with Filecoin.

I considered that, but discarded it to avoid repetition. Can do if folks really want that repetition here.

Yeah, I've had similar uncertainty when writing FIPs myself -- there's often major overlap between the Change Motivation and the Design Rationale (with the latter coming down to "designed so as to achieve the motivated change".

Defer to you / anyone else who feels strongly one way or the other.

Are there any specific design decisions you would like to call out here? If not, let's leave it as-is. The general address manager stuff should be in FIP-0048 (the one that introduces the notion of address managers), and I don't think there are any other noteworthy decisions specific to the EthAccount actor here beyond AA.

I agree with avoiding repetition. I interpret these sections as:

Motivation: what's the problem and why is it worth solving at all

Design rationale: why solve it this way, instead of some other ways

As a technical reviewer, I would like to see more explanation of why promotion is done this way, why it can't be done a more general way from the beginning. The section could probably highlight each of the Ethereum-specific mechanisms proposed (e.g. also the transitory signature delegation), explain they are temporary, and explain why the shortcut was needed.

arajasek · 2023-01-05T15:40:29Z

FIPS/fip-0055.md

+
+## Backwards Compatibility
+
+Backwards compatibility is not affected, as this FIP introduces strictly additive features.


FIP authors usually discuss the need for a network upgrade in this section (see a very simple example here). TBH, I'm not sure this is especially useful, since I don't think we've ever had a FIP that didn't need a network upgrade, but you can match precedent if you'd like.

What's the relationship between a network upgrade and backwards compatibility?

There's a Migration section which covers the transition during the network upgrade.

It's "backwards incompatible" in that it's "v9 incompatible", and so needs new actors version / network version -- that's often all this section has come down to.

Don't think you should necessarily match precedent here, though.

See 75b22a6.

arajasek · 2023-01-05T15:48:48Z

FIPS/fip-0055.md

+
+## Implementation
+
+- The actor implementation lives in [`filecoin-project/builtin-actors`].


Can we link the appropriate branches here, with a note that they will land in main branches upon this FIP's acceptance?

…ailure.

Was retracted a few days ago

anorth · 2023-01-05T20:29:44Z

FIPS/fip-0055.md

+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


Could we narrow this down to a single venue, perhaps #490, so technical discussion related to this proposal can be found in one place?

anorth · 2023-01-10T18:07:29Z

FIPS/fip-0055.md

+
+None.
+
+## Design Rationale


I agree with avoiding repetition. I interpret these sections as:

Motivation: what's the problem and why is it worth solving at all

Design rationale: why solve it this way, instead of some other ways

As a technical reviewer, I would like to see more explanation of why promotion is done this way, why it can't be done a more general way from the beginning. The section could probably highlight each of the Ethereum-specific mechanisms proposed (e.g. also the transitory signature delegation), explain they are temporary, and explain why the shortcut was needed.

anorth · 2023-01-10T18:14:23Z

FIPS/fip-0055.md

+
+### Exchange adaptation
+
+Exchanges must support receiving funds from EVM smart contracts.


Some don't even support receiving funds from native built-in actors like a multisig. There's not much we can do about it. I suggest dropping this, or at least softening to just being one more thing that exchanges might want to consider.

anorth · 2023-01-10T18:19:56Z

FIPS/fip-0055.md

+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


I don't understand this section, but discussion taken to #490 (comment)

q9f · 2023-01-13T14:56:40Z

FIPS/fip-0055.md

+
+Such transitory `Delegated` signatures must be verified by:
+
+1. Reforming and repacking the native RLP-encoded [EIP-1559 Ethereum transaction] from the Filecoin message (original signature payload).


EIP-1559 implies EIP-2718 transaction envelopes but you might want to specifically require that to reserve the potential to add more custom transaction types in future; either your own types, or if necessary, upstream Ethereum transaction types.

https://eips.ethereum.org/EIPS/eip-2718

draft for Ethereum accounts, addresses, and signatures.

2fc3d8e

raulk requested review from momack2, arajasek, jennijuju, kaitlin-beegle and anorth as code owners December 21, 2022 17:42

jennijuju reviewed Dec 26, 2022

View reviewed changes

FIPS/fip-nnnn-eam-eth-accounts.md Outdated

@@ -0,0 +1,386 @@

---

fip: <to be assigned>

Copy link

Member

jennijuju Dec 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0055

jennijuju changed the title ~~FIP for Ethereum accounts, addresses, and signatures (broken out of FIP-0054)~~ FIP-0055: Ethereum accounts, addresses, and signatures (broken out of FIP-0054) Dec 26, 2022

raulk added 2 commits December 27, 2022 17:19

complete draft and stamp with FIP number.

52e50f4

rename to fip-0055.md.

baa68bb

jennijuju reviewed Dec 30, 2022

View reviewed changes

FIPS/fip-0055.md Outdated Show resolved Hide resolved

raulk added 2 commits January 2, 2023 12:45

apply APA style capitalization to title.

171a25c

heavy editing round.

7d512d5

raulk requested a review from jennijuju January 2, 2023 17:57

raulk requested review from Stebalien and vyzo January 3, 2023 11:31

kaitlin-beegle reviewed Jan 4, 2023

View reviewed changes

jennijuju reviewed Jan 4, 2023

View reviewed changes

kaitlin-beegle approved these changes Jan 4, 2023

View reviewed changes

jennijuju previously requested changes Jan 4, 2023

View reviewed changes

FIPS/fip-0055.md Outdated Show resolved Hide resolved

FIPS/fip-0055.md Outdated Show resolved Hide resolved

FIPS/fip-0055.md Outdated Show resolved Hide resolved

raulk added 2 commits January 4, 2023 13:32

apply suggestions from editor review.

8340e7c

fix other instances of using f4 address 'payload' instead of 'subaddr…

ce57e1c

…ess'.

arajasek suggested changes Jan 5, 2023

View reviewed changes

jennijuju self-requested a review January 6, 2023 19:25

raulk added 8 commits January 9, 2023 13:59

fix typos.

9a60842

migration: specify that a new version of the init actor is deployed.

007f126

clarify empty actor state == EMPTY_ARR_CID in state tree

682e0f7

failing to validate the signature leads to a signature verification f…

64ab02d

…ailure.

backwards compatibility.

75b22a6

link to branches.

2cad288

sort references.

dfa9e09

add creation of null EthAccount in migration.

f4fb1d8

raulk requested a review from arajasek January 9, 2023 14:30

arajasek approved these changes Jan 9, 2023

View reviewed changes

remove list from frontmatter.

53c50cb

raulk merged commit ca2beaf into master Jan 9, 2023

raulk deleted the eam-eth-account branch January 9, 2023 17:20

anorth reviewed Jan 10, 2023

View reviewed changes

q9f reviewed Jan 13, 2023

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

FIP-0055: Ethereum accounts, addresses, and signatures (broken out of FIP-0054) #580

FIP-0055: Ethereum accounts, addresses, and signatures (broken out of FIP-0054) #580

raulk commented Dec 21, 2022 •

edited

Loading

raulk commented Dec 22, 2022

jennijuju Dec 26, 2022

jennijuju commented Dec 26, 2022

raulk commented Dec 27, 2022 •

edited

Loading

raulk commented Jan 3, 2023

kaitlin-beegle Jan 4, 2023 •

edited

Loading

raulk Jan 4, 2023

jennijuju commented Jan 4, 2023

raulk commented Jan 4, 2023

arajasek left a comment

arajasek Jan 5, 2023

raulk Jan 9, 2023

raulk Jan 9, 2023

arajasek Jan 5, 2023

raulk Jan 9, 2023

arajasek Jan 5, 2023

raulk Jan 9, 2023

arajasek Jan 5, 2023

raulk Jan 5, 2023

arajasek Jan 5, 2023

raulk Jan 9, 2023

anorth Jan 10, 2023

arajasek Jan 5, 2023

raulk Jan 5, 2023

raulk Jan 5, 2023

arajasek Jan 5, 2023

raulk Jan 9, 2023

arajasek Jan 5, 2023

raulk Jan 9, 2023

anorth Jan 5, 2023

anorth Jan 10, 2023

anorth Jan 10, 2023

anorth Jan 10, 2023

q9f Jan 13, 2023 •

edited

Loading


		## Backwards Compatibility

		Backwards compatibility is not affected, as this FIP introduces strictly additive features.


		## Implementation

		- The actor implementation lives in [`filecoin-project/builtin-actors`].


		### Exchange adaptation

		Exchanges must support receiving funds from EVM smart contracts.


		Such transitory `Delegated` signatures must be verified by:

		1. Reforming and repacking the native RLP-encoded [EIP-1559 Ethereum transaction] from the Filecoin message (original signature payload).


		#### State

		None.

FIP-0055: Ethereum accounts, addresses, and signatures (broken out of FIP-0054) #580

FIP-0055: Ethereum accounts, addresses, and signatures (broken out of FIP-0054) #580

Conversation

raulk commented Dec 21, 2022 • edited Loading

Simple Summary

Abstract

raulk commented Dec 22, 2022

Choose a reason for hiding this comment

jennijuju commented Dec 26, 2022

raulk commented Dec 27, 2022 • edited Loading

raulk commented Jan 3, 2023

kaitlin-beegle Jan 4, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jennijuju commented Jan 4, 2023

raulk commented Jan 4, 2023

arajasek left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

q9f Jan 13, 2023 • edited Loading

Choose a reason for hiding this comment

raulk commented Dec 21, 2022 •

edited

Loading

raulk commented Dec 27, 2022 •

edited

Loading

kaitlin-beegle Jan 4, 2023 •

edited

Loading

q9f Jan 13, 2023 •

edited

Loading