Leave and enforce tombstone after DeleteActor

[Kubuxu]

Today DeleteActore wipes an actor completely from the state. In a world with Predictable Address Generation this is an undesired property which can lead to security issues. We propose that DeleteActor leaves a tombstone after its call.

Motivation

Predictable Address Generation is a highly used feature in multiple already deployed contract systems. See Predictable Address Generation proposal for more details.

This feature is impossible to use safely in combination with DeleteActo,r if re-initialisation is allowed after DeleteActor is called.

Background

Predictable Address Generation allows anyone to generate an address to which an actor will be deployed in the future. This address is generated based on a partial initialisation state of the actor (for example known code but unknown parameter).

One such example could be a contract which has a known code but an unknown controlling key. After the controlling key is determined such a contract can be deployed to the pre-defined address. If that contract would ever call DeleteActor, an adversary could re-initialise the contract with their own controlling key. This leads to DeleteActor being an unsafe syscall and would discourage its use.

Proposal

DeleteActor should level a tombstone such that the re-creation of an actor under the same address is disallowed by the network.
This is primarily an issue for addresses of the Actor class, also known as stable addresses.

The state tree operates on ActorID addresses, the translation of stable address to ID address is performed based on an AddressMap HAMT within the InitActor. The AddressMap entries are not removed when DeleteActor is called, we propose to keep them so, they will be tombstones of deleted actors.

The InitActor should be modified to disallow the change of the stable address pointer. As in if a stable address is already present in the AddressMap list, that entry cannot be updated to point to a different ID address.

Whenever Predictable Address Generation is implemented, it should enforce that the Actor under the ID from the mapping table can be initialised only once, for example by creating a place holder under a given ActorID and allowing creation only when the placeholder is present or the stable address is not in the AddressMap.

The tombstone is defined as: Stable Actor Address is present in the AddressMap and the Actor under ID in that entry is not present in the state tree.

[anorth]

Great, thanks @Kubuxu. Thanks to the address map in init actor, this is nearly already the behaviour. I would say we don't need a FIP for this (it won't change any existing observable behaviour) but a code change and documentation in the init actor to clarify this behaviour.

[arajasek]

@Kubuxu Thanks for this! FYI, this is the kind of thing we like to include in the Network Upgrades docs as "Protocol Improvements and Bugfixes" (see, eg, the v16 doc here). That way minor changes like that don't get bogged down by the FIP process, but it's still tracked.

We don't have one started yet for v17 yet.

[Kubuxu]

Thanks, I originally started it as FIP as it was going to be a bigger change before I found this nice tweak. I'm not planning to propose an official FIP for it anymore.

It also got merged into builtin-actors: filecoin-project/builtin-actors#568