Predictable actor address generation for wallet contracts, state channels (aka CREATE2)

[anorth]

At present, the only way to confidently know what address an actor will have once created is to actually create it. The “stable” actor address computed by the NewActorAddress VM syscall remains fixed over chain re-orgs but depends on the history of the account actor originating the transaction where it’s called (it varies with call sequence number) and so can only be trusted by that party (until finality).

I propose adding a method to the Init actor which creates an actor at an address that is predictable ahead of time, controlled by the actor deployer, and remains independent of chain events (state and call sequence). This is the equivalent of Ethereum’s CREATE2 opcode.

I advocate implementing this prior to the FVM M2 release, so that we can better support user-friendly smart-contract wallets from the beginning.

Motivation

Predictable actor addresses allow generation of an address to which an actor can be deployed in the future, controlled by a specific creator. Funds can be sent to such an address prior to an actor being deployed there, and only the nominated creator can later deploy a contract to control them. The resulting address is independent of future events–it does not depend on any blockchain state.

One big use case for this facility is smart-contract wallets. With predictable addresses, users can receive funds into a wallet address prior to deploying any wallet actor there, but confident they will be able to do so. A “user” here could include smart-contract wallet platforms, which can generate addresses for unsophisticated end users prior to those users ever generating a private key, and then deploy a wallet actor only if and when that address receives funds. They could then hand control of the wallet actor over to one or more account actors.

Another use case is state-channel applications that wish to perform off-chain interactions, with the reliable possibility of reverting to on-chain transactions to settle disputes. Predictable contract addresses allow parties to exchange signed messages to such an actor prior to it being deployed. The parties can trust that only a specific piece of code could ever be deployed to that address.

Background

Current state

The existing process for actor address generation and creation is:

• An actor sends an Exec message to the Init actor specifying code CID and constructor params
• The Init actor uses the NewActorAddress syscall to obtain a stable address. This is calculated as hash(originator address, originator callseqnum, count of NewActorAddress during this txn). The originator address is the SECKP/BLS public-key-derived address.
• The Init actor computes the next actor ID, and stores mapping of address to ID
• The Init actor calls the CreateActor syscall with computed actor ID and Exec code CID
• The Init actor invokes constructor of the newly created actor with Exec parameters
• The Init actor returns the computed actor ID and stable address

The computed actor address is stable in the sense that the originator can rely on it being constant even if a reorg causes the allocated actor ID (computed next) to change. It does not depend on state. However, it is not predictable far in advance or trustable by other parties because it depends on the originator callseqnum.

Prior art - CREATE2

The Ethereum CREATE2 opcode (EIP-104) deploys a contract to an address that is computed as hash(0xFF, sender, salt, bytecode). This guarantees that if sender ever deploys bytecode using CREATE2 and the provided salt, it will be stored in the resulting address. Note that the bytecode here is “initcode”, which is evaluated to generate the code to be deployed, and introduces some hard-to-think-about security challenges. CREATE2 can only be used by contracts (factories) because EOA transaction don’t have salt–this is by design.

More background on the EVM contract deployment process, but Filecoin is different (simpler) due to coupling of the VM with the Init actor.

Proposal

Add a new method Exec2 (name TBC) to the Init actor.

type Exec2Params {
    CodeCid: Cid, // Same as Exec
    AddressSalt: Bytes, // New
    ConstructorParams: Bytes, // Same as Exec
}

Exec2 behaves similarly to Exec, but rather than using NewActorAddress to compute the address, it computes it as hash(senderID, params.AddressSalt, params.CodeCid). This address should have type tag Actor (=2), the same as those generated by NewActorAddress. These two methods of generating an address will never collide (up to hash security) because the first hashed items SenderID and OriginatorAddress have no overlap.

The hash function shall be blake2b, following the existing actor address scheme.

With this scheme, someone can compute off-chain what address would be generated when a specified sender deploys a specific code CID with a known salt at any point in the future.

Implementation notes

Note that thanks to VM/Init actor coupling, no new syscall is needed here. The only change is to the Init actor.

VM implementations would need to change the behaviour when a message is sent to an actor-type address that is not yet initialised. At present, such sends are rejected (SysErrInvalidReceiver). Instead, the destination actor must be created with a placeholder code CID representing code yet to be deployed. The deployment capability must be restricted to the Init actor, as is currently the case.

Open questions

Dependency on constructor parameters

This scheme leaves the constructor parameters out of the address inputs. This means that the sender does not commit to them. Future FVM code delegation mechanisms could mean that different constructor parameters result in very different actor behaviour, which is a risk to any third party relying on the code to be deployed to some address.

We could consider including the parameters CID in the address hash inputs. This would provide complete clarity over the code and state to be deployed, but also remove flexibility. E.g, a smart contract wallet platform would be unable to specify different end-users’ private keys, or any other parameter, to different actors at construction (but could invoke a subsequent method to authorize them).

Unification with NewActorAddress

This scheme raises the question of whether we could unify the address generation approach with that used for the existing actor addresses. The use case for NewActorAddress is generating a address without an externally provided salt value, stable, but not necessarily predictable. If you squint, the inputs to NewActorAddress could form the salt to an address created with the proposed scheme–they take the place of an externally-provided unique value.

If we added syscalls to expose the originator address and originator nonce, the Init actor could read these value to construct most of the salt, and then compute the address. The remaining salt item is to distinguish multiple new actor creations in a single top-level transaction. Ethereum does this by incrementing the nonce on the caller contract (which for us is always Init), but this makes the address unstable across re-orgs.

• Would adding a simple sequence number parameter to Exec be good enough for all practical needs?
• Is there anything else that’s not chain state we could use to distinguish multiple calls? Like gas used so far? It would be really nice to remove the internal counter that the VM has to keep to support this call.

If we do this, we could remove the NewActorAddress syscall, because the Init actor would compute the address.

Compatibility with future address schemes

The FVM team have proposed a new universal address scheme in https://github.com/filecoin-project/fvm-specs/blob/505fa1ed0daabfcf2033e8fe79d9b64019a36ca0/04-evm-mapping.md. Since predictable addresses created by this proposal are in the same address space as existing type 2 actor addresses, they will be similarly compatible with this scheme. Alternatively, a 256-bit hash function could be used to natively create a class-4 address from the beginning.

[Stebalien]

Dependency on constructor parameters

This is likely required (or at least very useful) for most use-cases. Basically, it allows one to very easily assert that some address could only contain a specific actor (e.g., a multisig owned by a specific user).

Technically, this isn't absolutely required as long as the "origin" actor (the one creating new actors) includes enough information in the "salt". However, that:

1. Makes it difficult to provide guarantees/audit.
2. Makes it impossible for the "origin" actor to be upgradable while retaining the guarantees.

NOTE: the EVM effectively includes the constructor parameters in CREATE2, simply because it doesn't have constructor parameters.

We could consider including the code CID in the hash inputs

Your scheme already does this, right?

[anorth]

Dependency on constructor parameters

This is likely required (or at least very useful) for most use-cases.

Different use cases will want different things. For the contract wallet example I give, the flexibility to provide constructor parameters is helpful, because the end user doesn't necessarily have any on-chain identity when the address is computed. It's part of a new-user-friendly onboarding flow (defer private key stuff until after receiving value, someone buying your NFT etc). They could work around the params being committed by calling a post-construction method to change the authority away from the platform's address.

But other use cases where someone besides the deployer needs certainty over the behaviour of the code to be deployed, it's unhelpful. Such cases could work around params being free by using code that has no constructor parameters.

I'm not sure where to land, it's a good discussion.

We could consider including the code CID in the hash inputs

Your scheme already does this, right

Thanks, typo. Changed to "parameters CID".

[Stebalien]

It's part of a new-user-friendly onboarding flow (defer private key stuff until after receiving value, someone buying your NFT etc)

Hm. It sounds like there are really two different motivations here:

1. A "reserved" address space for a particular actor. This allows the user-friendly workflows you're imagining.
2. The ability to make guarantees about any actor deployed to a particular address. This was the original motivation behind CREATE2 (allows

Honestly, these are both pretty useful and we probably want to support both use-cases. We could do this with two methods, but, IMO, having the wallet initially owned by the creator also seems pretty reasonable.

[anorth]

We'll need to remove or change the DeleteActor syscall to avoid resetting the account nonce, else this mechanism will open up tricky issues around replay protection and assurances over the code and possible state at an address (no monotonicity guarantee would be possible).

https://github.com/filecoin-project/fvm-specs/issues/100

[Stebalien]

So, I've been thinking about this a bit and went down a rabbit hole of potential constraints:

• The addressed actor has a specific code + constructor params, but can be created by anyone.
• The addressed actor can only be created by some specific actor, but can contain any code.
• The addressed actor creation must be triggered by an off-chain message sent from a specific account.
• The addressed actor may only be created once some hash preimage has been revealed.

Etc...

Then I remembered: this kind of complexity explosion is why smart contracts exist.

Proposal

Make it possible to provide CREATE2-like guarantees in userspace (with user-defined actors). Specifically, add an Exec2 method to the init actor, but compute the address as hash(sender_address ++ address_salt) where the immediate caller of Exec2 chooses the address_salt.

Out of the box, a user will only be able to prove that an actor at address X must have been deployed by some actor at address Y. However, a well-known actor can be deployed to address Y to provide additional constraints.

For example, a CREATE2 actor could be created that:

1. Takes a code CID (c), constructor parameters (p), and an address salt (s) as input.
2. Calls Init.Exec2 on the given code CID (c) and constructor parameters (p), but constructs the address salt as join(sender, c, p, s).

However, unlike CREATE2, this allows us to provide arbitrary constraints on counterfactual contracts:

• Contracts that can only be deployed after some epoch.
• Contracts that can be deployed by anyone, but must be initialized with some code and initial parameters).

The main downsides to this approach are:

1. Gas. Realizing a counterfactual actor creation will require an additional send. HOWEVER, the point of counterfactuals is that they should never hit the chain anyways.
2. The new actor's constructor will see the actor-creation actor as the "sender".

[anorth]

Overall I think direction seems good. It does introduce more things to think about, but that's because more design space is opened up. We would presumably deploy an immutable actor embodying the commitment-to-code property of my original proposal (or wallet providers could use their own).

Contracts that can be deployed by anyone, but must be initialized with some code and initial parameters

Just clarifying, the address still depends on the immediate caller address, but I think you're saying if that immediate caller (A) is an immutable actor that embodies the code and parameters, and calls Exec2, then anyone can call (A) to trigger a deployment.

I'm not sure how much of a problem the contract-creator as sender is in practise. But your proposal to delegate the salt computation seems to resolve it without adding any significant overhead in the case where the caller/callee don't care about that.

I would think that sender is still required in the hash payload for your option 2. It's not obvious to me that desired properties continue to hold if the address does not necessarily depend on caller.

[anorth]

Also, I expect we're going to be forced to embody a calling convention the built-in actors in order for them to interoperate well with user actors. I don't think it's worth resisting this. It's not the same as the VM restricting the convention. I have a proposal for this coming.

[anorth]

See #401

[Stebalien]

Just clarifying, the address still depends on the immediate caller address, but I think you're saying if that immediate caller (A) is an immutable actor that embodies the code and parameters, and calls Exec2, then anyone can call (A) to trigger a deployment.

Yes.

I would think that sender is still required in the hash payload for your option 2. It's not obvious to me that desired properties continue to hold if the address does not necessarily depend on caller.

In option 2, the address would depend on actor that creates and returns the salt. It's pretty much the same as option 1, except that it's called by the init actor, instead of calling the init actor.

[Kubuxu]

I like the train of thought here.

The new actor's constructor will see the actor-creation actor as the "sender".

Doesn't the actor's constructor always see the Init actor as the sender?

[eshon]

Just an FYI - There was recently a Create op code related hack worth $27M on Optimism. The attacker was able to deploy multisig to an unowned address because the recipient, Wintermute, had created their multisig in 2020 using an out-of-date Create opcode and not Create2. Source: https://rekt.news/wintermute-rekt/

[anorth]

I thinking about token APIs, I've realised that predictable addresses on Filecoin will differ from Ethereum in an important way: it's impossible to send native FIL tokens to an Actor address before an actor is deployed there. Unlike pubkey addresses, the system can't automatically deploy an account actor there. This limitation carries over to any reasonably simple implementation of a token API – such token would record balances by canonical ID address, but there's no ID address until an actor is deployed. This is a significant limitation for wallet platforms, where a motivating use case is to delay code deployment until after receiving value.

This limitation could be worked around if we can somehow trigger provision of the ID address for an actor address, i.e. init the state tree entry, without knowing the code that's to be deployed there. There are already other cases where, in an attempt to resolve an address to an ID, the built-in actors make a zero-value send to an address in order to init the actor. This only works for pubkey addresses, for which we can deploy the built-in account actor.

Maybe the zero-value send could install a sentinel code CID which marks an actor as awaiting deployment via Exec2?

Maybe (this would be cool) the zero-value send installs actor code which implements the upgrade entry point and verifies that hash(senderID, params.AddressSalt, params.CodeCid) its own address!

[anorth]

See #459 for a proposal that may subsume this one.

[luckyparadise]

Hi @anorth just checking for documentation purpose if you still want this to be classified as a Pre-FIP or you are deferring it?

[anorth]

We could remove the label. It will either be a FIP soon, or retired, but can't tell yet.

[jennijuju]

F4 address supports this likely - @anorth should we retired this in favour of f4 discussion and FIP?

[anorth]

Yes we can remove the pre-FIP label. Otherwise I don't think we need to do anything? It's not worth locking discussions just because they're old.