Steven Allen

> Potential chunking of bytecode, if any. (Probably out of scope for M2.) Assuming EVM-only? > Garbage collection of unused code entries? I assume we'll punt this to "probably never".

Meta: @raulk would you prefer to put stuff like this in issues (easier to discuss) or in documents (easier to track over time).

Two alternatives: 1. Transactional memory: the actor SDK could check to see if the state-root has changed since last reading/writing it, and fail (unless the method was marked as "safe"...

This looks correct. To extend it a bit: - We should fix https://github.com/filecoin-project/ref-fvm/issues/636 first. - We should test the HAMT with different parameters. HAMTs may actually work, but we'll probably...

As much as it pains me, we may also want to consider a custom "packed" format for the leaves of our merkletree given our highly regular data.

> Optimizing for sequential storage (e.g., with some form of sparse array). Apparently, this won't help.

I'm actually not so sure: > Except for dynamically-sized arrays and mappings ... data is stored contiguously item after item starting with the first state variable, which is stored in...

If that's the case: - We should optimize for "low" slots. We'll likely want to put "low" slots in the state's _root_. - We should optimize sequential slots at random...

> Related to this, I'm looking at the part of the EVM storage layout docs where they illustrate the slots of a struct: > So it looks like the data...

Yeah, the unpredictable nature is definitely an issue. We "batch" like this because: - Lots of small blocks is inefficient in terms of round-trips and metadata. - We tend to...