IPLD/state store DAG semantics, views, garbage collection

[anorth]

The current IPLD store interface appears simply as a Get/Put-style object store, which is misleading about the desired semantics. This issue documents my understanding, discussed with others, ahead of expression in the spec.

The state visible to and operated on by the VM is semantically a connected DAG, with a distinguished root being the root CID written into a block header. Only objects reachable in a traversal from this root, following CID links, are accessible in the store. The Get and Put methods are intended to be used to implement IPLD data structures such as the HAMT and AMT, not as a general object or K/V store. A future better abstraction could make this more clear.

• The state tree is a single logical store, it is is not namespaced by actor. If some actor can retrieve a value with some CID, all other actors can too (if they learn the CID).
• The only way for an actor to persist some value is to write it into its state object, or to Put() it and reference the resulting CID from that state, or reference it from some other object Put() and transitively referenced from the actor state.
• If an actor Put()s a value but does not save the CID in its state, a Get() in a subsequent message execution will find the value missing
• The state tree is logically distinct from the blockchain store: blocks, messages and other IPLD objects that make up the blockchain are not retrievable by actors (unless one of them explicitly Put()s such a value in the state)
• An actor's view of the state represents only a single history, and should not include objects created in other branches of the blockchain. If some message triggers a value to be stored in the state on one chain, but then a re-org removes that message from history, a Get() on the new chain should find the value missing.

Transaction scope The logical lifetime of a value Put() in the store, but not yet referenced transitively from the root, is still TBD (i.e. transaction scope). Garbage collection should remove unreferenced objects after that lifetime (logically, if not physically).

The shortest reasonable lifetime would be until the next state handle release, and I propose we do this. This would prevent the store being used as a communication channel between actors unless the CID of the object was also written to actor state, since actors cannot send messages while the state handle is held.

(A longer lifetime could be the current method invocation, or the current top-level message invocation. This would permit the state store to be used as a short-term communication channel between actors, which could exchange CIDs in messages pointing to objects placed in the state store. The need for this is unclear, though, and doing so would prevent future improvements to the Runtime API to make the tree nature more clear. Efficient inter-actor communication could be achieved more directly with some other mechanism in the future.)

Non-urgency of views and garbage collection The view and garbage collection semantics outlined above are not urgent for implementation because, given our control of the built-in actor code, we can ensure that the semantics are indistinguishable from having no views, transactions, or garbage collection. I believe that a sufficient constraint to achieve this is:

• no actor attempts a Get() with any CID other than one which that same actor has previously Put() (in the history currently being evaluated) and saved in its state.

This ensures that actors never attempt to retrieve an object which might have been gc'd (barring bugs). Note that there are CIDs in the state tree which are not expected to resolve: un/sealed sector CIDs, Piece CIDs in deals, etc. No actor should ever attempt to retrieve these from the state tree.

Implementers will probably add some kind of garbage collection for performance reasons, but initially have some freedom in semantics.

cc @jbenet @whyrusleeping @icorderi @sternhenri

[wadealexc]

Is actor state distinct from the state tree accessed through Get and Put?

I know an actor can Get things another actor Puts (as long as they have the CID). Does an actor's state have a root CID, and could another actor use that CID to Get the actor's state?

[anorth]

Pragmatically, they are in the same store and so we should define it that way. So yes, if an actor transmitted its state head CID to another actor, that actor could load and access it.