Alex North

Thanks. Pending arguments about why it should be opinionated about format (preferably backed up by enforcement) I prefer option (1). I have forgotten it once was opinionated since at least...

See #137

A thought I had recently: I'm increasingly of the opinion that having components be generic in the blockstore is probably a design error. Instead, they should work with a dynamic...

> we have cases where we want to take ownership Could you expand on those? One candidate would be for mutations, but the current trait has no `mut` methods and...

Here's another case where a `B: Blockstore` trait needed to be introduced in order to abstract over the type of blockstore, but holding a reference would probably have been preferable....

> However, we could trivially solve this my removing all &mut receivers from the runtime, relying on interior mutability instead. Which is what we should likely do anyways. Now done!...

Note the nested H/AMT structures like MapMap, MultiMap require the blockstore to be `Clone` too, unless we change their APIs. This may be reasonable if we better establish a blockstore...

@aarshkshah1992 I think you make have completed this. Please close the issue if you believe so, or leave a comment here explaining what still needs to be done.

Keeping this issue open until the `Map` type is gone, replaced with what's currently called `Map2`.

There is good discussion in https://github.com/filecoin-project/FIPs/discussions/689. I don't think the options are mutually exclusive. For option A it is quite likely that using an aggregated proof wastes resources for proving...