IPLD and Rent

[ZenGround0]

Here is a sketch of a simple IPLD based rent mechanism for FVM. While thinking about ideas in #530 it became clear that rent-like primitives are starting to show up in the builtin actors design space. I'm guessing others have thought a lot more about this generally but I didn't find anything written down here yet.

Expiring Links

In this model clients of the FVM pay for data up front set to expire after a given time. Clients would do this because storing data with a shorter expiration is cheaper and the utility of onchain data storage can change over time. Data links with an expiration are explicitly tagged as such directly in the IPLD data model. FVM implementations MUST resolve links to data before the expiration time. FVM implementations MUST fail to resolve links to data at and beyond the expiration time. Blockchain clients backing FVM execution would do GC of expired data per their own policies.

Proposal: achieve expiring links with a new IPLD data type: the expiring link or eCid

Abstractly expiring links consist of three fields
<clock-codec><time><cid>

The clock codec specifies which clock to use. One example of a clock is the filecoin block header clock which ticks once for every tipset height. Time can probably be a varint though perhaps we could delegate encoding to the clock codec. Time values should be well ordered supporting the >= and < operations. The cid is just the cid of the data

In the FVM we would allow writing expiring cids using the filecoin clock only, and maybe extend to other clocks in the future if use cases presented themselves.

Concretely in IPLD-CBOR this addition of a new top level type would mean selecting a new CBOR tag assignment i.e. 279, and then encoding expiring links as a tagged array of [ clock codec||time, cid]. Maybe clock and time are their own separate fields too rather than being serialized together.

Alternatives and Downsides

Specify expiration in cid

In order for this to interoperate with any kind of cid codec and specify arbitrary expiration times it doesn't make sense to me to implement expiring links with cid v1 codecs. If we updated to cid v2 we could add expirable field, expiration clock codec and expiration time directly into the cid. However updating to cid v2 is potentially even more disruptive than updating the IPLD data model.

A big downside to the Expiring Links proposal is that extending IPLD is an invasive change but it seems necessary in order to do something like this. It's also unclear if expiration and clock referencing is useful outside of the blockchain context so this might be considered an overspecialization for IPLD. This argument might motivate putting expiration meta data in cids rather than making a new top level link type.

It's unclear if adding a new top level type that includes a potentially unreachable cid is a non-starter for FVM reachability semantics of cids. It's not obvious why it would be but I know very little about this part of the system.

[Stebalien]

I'd rather have rent operate on a per-actor basis to avoid partial state. If we charge some form of rent for an actor's state, actors can choose when to remove specific state and the entire actor can be deleted if it runs out of funds to pay for rent.

I've mostly been focused on a per-actor model and per-period charging:

1. Charging for the next "period" on initial write.
2. Every period, walk the state-tree and figure what to charge each actor based on how much state the actor keeps alive (amortized over the other actors that share that state).
3. Deleting actors that can't pay for their state where said state can be restored as long as a user pays for it.

[Kubuxu]

I would suggest instead of straight-up deleting, allowing actors to "hibernate" to keep the commitment to the state. Charge rent for it as well if we want to but it would allow actors to "wake up" by providing all or most of the needed state when they need it.

It is a more complex mechanism but allows for recovery of for example forgotten multisigs.