Jude Nelson

> This will be very helpful to extended use cases to reuse block consensus logic, e.g. implementing an ephemeral WritableMarfStore for simulation. PR #6365 already has an ephemeral `WritableMarfStore` implementation.

> This is not an ephemeral WritableMarfStore implementation; it removes the dependency on concrete implementations. Yes, I understand that. Forgive me if this is asking you to repeat something you...

Hi @bestmike007, > Using trait over enum means that there can be infinite possibilities of implementations No one is questioning this in principle. What I'm questioning is whether or not...

> I think I disagree with this -- we have many traits throughout the codebase, and we change them without too much thought as to how it might impact downstream...

Just an update here -- I'm working on a series of traits as part of #6365 that should (hopefully) make it a lot easier to plug in external MARF and...

Okay, so here's what I have in https://github.com/stacks-network/stacks-core/pull/6365: ``` /// A MARF store transaction for a chainstate block's trie. /// This transaction instantiates a trie which builds atop an already-written...

I think @wileyj should try this patch out on a block-replay before merging, because the corresponding block validation script will need to be updated to use this new CLI. That...

Hey @usagi32, thank you for submitting this! It's definitely been a todo-item for the VM to require trait implementations to be read-only. Unfortunately, such a change is necessarily consensus-breaking, and...