Init.Exec and "Runtime" CIDs

[Stebalien]

I've run into a few cases where I'd like to be able to create CIDs that are only valid at runtime. This can be useful for passing temporary datastructures between actors that will never be persisted into the state-tree. Otherwise, the user will need to create a real CID, and pay for the hashing.

One such example is the parameters to Init.Exec. At the moment, we've defined these parameters to be "raw bytes". However, we'd like to be able to pass more complex datastructures to constructors (e.g., ones containing CIDs/links).

At the moment, we have two options:

1. Make InitParams::constuctor_params a CID.
2. Make it some arbitrary CBOR "value" (no type constraints).

Both of these have drawbacks:

1. If we make it a CID, we need to compute the CID, which currently involves hashing.
2. If we make it an arbitrary CBOR value:
   1. We still need to call ipld::put_block on this value before calling the actor's constructor.
   2. We'd only support CBOR (or some specific codec).
   3. We'd have to decode the value (at least somewhat) inside the init actor, which isn't great.

One (somewhat crazy) solution would be to introduce a new fvm-specific "multihash code" for "ephemeral" CIDs (or even just an "application specific code". If the user calls ipld::block_link with this special multihash code, the FVM would assign a temporary ID to the block, and return a CID with that temporary ID as the digest (we can probably avoid a syscall here if we get cleaver). If the user then calls ipld::block_link with any other multihash code on a block containing one of these ephemeral CIDs, the FVM would reject the call.

Unfortunately:

• This would create two "colors" of blocks: those that can be persisted, and those that can't. Which is really not great.
• This is kind of a misuse of CIDs.

---

Honestly, in this case, the cost of hashing is likely minimal compared to everything else (we're creating a new actor). So maybe that's a viable solution?

[raulk]

Interesting.

Taking a step back, I think you might be hinting at a mechanism to define visibility of DAGs, e.g. exported/private DAGs, i.e. DAGs that can be integrated into the state tree vs DAGs that can't. The problem with this is that it breaks some guarantees in the receiver. Now it no longer has the guarantee that the received DAG can be unconditionally linked to from its state.

Another scenario where a different flavour of this could be useful is when staging a batch of write operations on a data structure. Right now, I believe the HAMT and the AMT rehash at every write. It would be nicer if one could perform a batch insertion/deletion/update and avoid the cost of rehashing at every individual operation. One way of doing that would be to use "placeholder CIDs" or "reference CIDs" temporarily until the batch is committed, which is when real CIDs would be calculated.

[Stebalien]

So, for HAMTs and AMTs, we just make changes in memory until we're "done", then we flush all at once.

We tend to run into this issue when we have cross-actor calls.

[Stebalien]

But yeah, "temporary" hashes may be more generally useful. On the other hand, re-serializing is probably more expensive than hashing in many cases.