Consider increasing `ACCOUNT_UPDATE_MAX_SIZE` to allow account updates for Rust-compiled contracts

[greenhat]

Feature description

I'm hitting AccountUpdateSizeLimitExceeded when I'm creating an output note in the counter contract test in 0xMiden/compiler#555 at https://github.com/0xMiden/compiler/blob/d0032e7fa22fbad1ff704fc8f9c2367067164129/tests/integration/src/rust_masm_tests/testnet.rs?plain=1#L221-L224
The size of the counter account code is 72 KB, which is way above the 32 KB limit set in ACCOUNT_UPDATE_MAX_SIZE.

Why is this feature needed?

No response

[PhilippGackstatter]

72 KiB of code sounds very large to me for a counter contract. Is that an expected, normal size with all debug information stripped? I'm not sure if updating the limit in the protocol is the right approach. This limit multiplies per transaction and so a batch or block could end up containing 32 MiB of data with the current limit. Under the assumption that a counter contract is fairly simple and users would want to write much larger contracts, we'd have to increase the limit to a significantly greater value, e.g. 256 KiB or even more. Then a block could theoretically contain 256 MiB, which I assume is definitely too much for the network to handle.

If there is an assumption that this will go down in the future with optimizations, then I suppose we could increase the limit now (for testing purposes) and reduce it later.

[greenhat]

Yeah, it's a bit on a heavy side. It's a release build without any debug info.
1228 LOC MASM - https://github.com/0xMiden/compiler/blob/d0032e7fa22fbad1ff704fc8f9c2367067164129/tests/integration/expected/examples/counter.masm?plain=1, plus some linked i32 and mem intrinsics from https://github.com/0xMiden/compiler/tree/d0032e7fa22fbad1ff704fc8f9c2367067164129/codegen/masm/intrinsics

We don't do many optimizations now, so the size will definitely go down, but I'm not sure how significantly. @bitwalker any thoughts?

[bitwalker]

It's a release build without any debug info.

That might be true for the Rust part, but the MASM intrinsics will have debug info, and the assembler is always run with debug info enabled currently.

---

I'm curious how we're evaluating code size for purposes of this limit. Does it take into account sharing of nodes across MastForests? If most of the code is the same, but only a few nodes have changed, the effective delta of the code change might be on the order of bytes. If we're not considering sharing at all, then there is virtually no way to handle a case where your code changes are too large.

The compiler doesn't have much control over the final size of the MAST - we can choose compilation options in Rust that reduce code size, but beyond that, we're required to emit MASM that faithfully emulates the semantics of the input Wasm we get, so there isn't too much in the way of size optimization opportunities.

That said, the compiler does currently emit a fair amount of extra instructions related to type conversion due to how Wasm represents integer values, and how our frontend handles translating that to more precise types currently. We have some tasks in our backlog related to reworking that to avoid those redundant instructions, but until then, there isn't much we can do. I'm not convinced that trimming that fat would bring the delta under 32k though. I suspect it is just the size of the MAST itself that needs to be better compressed than it is today.

[bobbinth]

As @PhilippGackstatter mentioned, 32KB is already on a relatively "heavy" side by blockchain standards. On Ethereum, for example, the whole size of a smart contract's code is currently limited to 24KB (though, EIP-170 proposes to increase it to 256KB, I believe). In the short term, we could bump the size up to 256KB to unblock the compiler, but I think I'd be much more comfortable with something like 64KB or smaller.

Having said that, I do think there are quite a few things we can do to reduce the size:

• We should definitely strip out debug info to compute the size. My guess, this will have a significant effect on reducing the overall MAST forest size. We should probably prioritize this work.
• Our current serialization methodology is fast but "fat". We can implement a much more efficient serialization approach. I'm expecting the "slow but thin" serialization to give us somewhere between 5x and 10x in size reduction.
• We can put some of the compiler intrinsics in a standard library of sorts, and this library could be assumed to be present on every node/client (we could load it in addition to the two libraries we load now).
• We can optimize codegen a bit more to reduce redundant instructions as @bitwalker mentioned.

Overall, with about 1300 LOC, I would expect the serialized version of the counter contract to be under 4KB.

[bitwalker]

We should definitely strip out debug info to compute the size. My guess, this will have a significant effect on reducing the overall MAST forest size. We should probably prioritize this work.

This would have the greatest immediate impact for sure.

Our current serialization methodology is fast but "fat". We can implement a much more efficient serialization approach. I'm expecting the "slow but thin" serialization to give us somewhere between 5x and 10x in size reduction.

This is likely to produce the greatest impact overall, but we haven't done the work to specify the "slow but thin" format, and we'll likely need to be clever about it to achieve the desired improvements. Ultimately though, we definitely need to undertake this effort.

We can put some of the compiler intrinsics in a standard library of sorts, and this library could be assumed to be present on every node/client (we could load it in addition to the two libraries we load now).

I disagree strongly with this though. First, the compiler intrinsics are internal details of specific compiler versions, and could change for just about any reason (although the current set of intrinsics aren't likely to change much). In general I think we need to push to have less direct dependencies of this nature between toolchain components, not more.

Secondly, and I will die on this hill, I do not think we should treat the standard library special in any way, aside from the fact that it can be installed as a component of the Miden toolchain via midenup. It should be just another package. We know we need this anyway, because as contracts are deployed to the chain, they will have been built against specific versions of the standard library, and those dependencies can never change (short of replacing the contract code entirely). Any assumption on our part about specific library versions being "baked in" is going to bite us.

I will note that currently, we have to make that assumption about the standard library and the transaction kernel, but once the type system changes are implemented in the package format, and midenup is ready, we no longer need to do so, and my argument here is based on where we're going at the end of that work, not the current state now.

We can optimize codegen a bit more to reduce redundant instructions as @bitwalker mentioned.

I'm hopeful that when we get to this, that we can improve both size and runtime performance, but I don't have a good sense yet on how impactful the changes will be. I would assume for now that we can't rely on this being a solution.

Overall, with about 1300 LOC, I would expect the serialized version of the counter contract to be under 4KB.

Yeah, I suspect the MAST is what is blowing the size up so much, but would be interested to measure what parts specifically are causing the bloat, since those will be the parts we'll want to optimize the most. My guess is decorators (particularly debug info), but that's just a guess.

[bobbinth]

I disagree strongly with this though. First, the compiler intrinsics are internal details of specific compiler versions, and could change for just about any reason (although the current set of intrinsics aren't likely to change much). In general I think we need to push to have less direct dependencies of this nature between toolchain components, not more.

Secondly, and I will die on this hill, I do not think we should treat the standard library special in any way, aside from the fact that it can be installed as a component of the Miden toolchain via midenup. It should be just another package. We know we need this anyway, because as contracts are deployed to the chain, they will have been built against specific versions of the standard library, and those dependencies can never change (short of replacing the contract code entirely). Any assumption on our part about specific library versions being "baked in" is going to bite us.

I will note that currently, we have to make that assumption about the standard library and the transaction kernel, but once the type system changes are implemented in the package format, and midenup is ready, we no longer need to do so, and my argument here is based on where we're going at the end of that work, not the current state now.

Probably a separate discussion, but we do treat 2 libraries as special in the context of the blockchain (they are not special in the context of the VM though):

• miden-lib - this contains the transaction kernel and a few utilities. We can expect that miden-lib is loaded on all nodes/clients working with the blockchain.
• miden-stddlib - every node/client is also expected to load these for the purpose of transaction execution. This is needed, in part, because miden-lib relies on miden-stdlib.

The way I'm thinking of it now is that nodes/clients will need to load all existing versions of both libraries (unless we introduce some notion of "yanking") - but that shouldn't be a big issue because the references are hash-based and the underling MAST forest stores will be able to "de-duplicate" redundant procedures (though, this is something we still need to implement).

[bitwalker]

We can expect that miden-lib is loaded on all nodes/clients working with the blockchain.

I'm confused by this - by definition, if you compile a program that interacts with the rollup, then you will depend on some version of miden-lib, but you could easily have multiple programs that depend on different versions of miden-lib simultaneously. By definition, each miden-lib version will have a dependency on some specific Miden standard library version as well - but the parts of the standard library linked by miden-lib could be vendored so that updating the installed version of the standard library doesn't break the installed version of miden-lib. We have quite a bit of flexibility when it comes to linking. Fundamentally though, programs must link against specific MAST roots of the procedures they depend on, and for the sake of backwards-compatibility, it is necessary to be able to execute programs that use different versions of these libraries at the same time.

My understanding in any case, is that the plan was for the user-facing API of miden-lib to use some form of syscall indirection internally to avoid linking against specific kernel MAST roots, so the kernel itself might be pinned for a specific node/client pair - so the kernel might be special, but not anything else (and internally, the kernel library might link against a specific version of the standard library, but that is an internal detail). I don't know to what degree that indirection has been implemented in miden-lib, but that would be table stakes IMO for actually deploying things to a chain that isn't ephemeral.

The standard library on the other hand, doesn't have any dependency on the current kernel (AFAIK, and if there are parts that do, they should probably be moved to miden-lib IMO), so it isn't clear to me why we would make any assumptions (or impose any requirements) on specific versions of it. Ultimately you aren't linking against entire libraries, but specific procedures from a library - it just happens to be the case that, sans vendoring, having the package of the entire library is the only practical way to make sure the parts of it you actually linked against are available at runtime.

The way I'm thinking of it now is that nodes/clients will need to load all existing versions of both libraries (unless we introduce some notion of "yanking") - but that shouldn't be a big issue because the references are hash-based and the underling MAST forest stores will be able to "de-duplicate" redundant procedures (though, this is something we still need to implement).

This is a big part of what I mean by those libraries not being special. MAST is primarily beneficial when treated as content-addressable, and so you put all libraries/packages in some form of content store designed around that fact, and punt it to the person running the node/client to ensure that storage is seeded with the things they need. We should be building the tools to make that easy to do, as part of installing the toolchain; as part of running the node; and as part of running the client locally.

Back when I proposed the MAST refactoring, I mentioned that we would want to provide an abstraction in the VM for a registry of packages, and that this would allow for the VM to load packages (and request them on the fly if necessary), while not needing to provide the implementation of the registry itself. I also sketched out how a default filesystem-based registry could work, and what the tooling would look like to interact with it. At the time, we punted on that part of the proposal, but this is precisely the problem I was aiming to solve with that design. Rather than requiring that we ship certain libraries with the node and client, I think our approach should be to solve the handling of required libraries/packages via toolchain more generally, namely via the registry solution I proposed last year.

[bobbinth]

I'm confused by this - by definition, if you compile a program that interacts with the rollup, then you will depend on some version of miden-lib, but you could easily have multiple programs that depend on different versions of miden-lib simultaneously. By definition, each miden-lib version will have a dependency on some specific Miden standard library version as well - but the parts of the standard library linked by miden-lib could be vendored so that updating the installed version of the standard library doesn't break the installed version of miden-lib. We have quite a bit of flexibility when it comes to linking. Fundamentally though, programs must link against specific MAST roots of the procedures they depend on, and for the sake of backwards-compatibility, it is necessary to be able to execute programs that use different versions of these libraries at the same time.

This is largely correct - but the main difference from what I described is that I don't think we need to vendor miden-stdlib into miden-lib. Basically, node/client would have all versions of miden-stdlib and miden-lib loaded into its MAST forest store.

One of the reasons for this is that programs may rely on some functionality from miden-stdlib directly. A good example is our smt implementation. Version $x$ of miden-stdlib could have one implementation of smt procedures, and version $y$ could have another (e.g., more optimized) implementation of the same procedures. Some legacy programs could be built against version $x$ and other programs could be built against version $y$. But since the node/client would have all versions, they'd be able to execute all such programs.

The alternative would be to vendor smt procedures into each respective program, but that would needlessly blow up their size.

So, the concrete implication of the assumption that nodes/clients have all versions of these two libraries loaded is that account code, note and tx scripts, do not need to vendor miden-stdlib and miden-lib libraries they get compiled against.

My understanding in any case, is that the plan was for the user-facing API of miden-lib to use some form of syscall indirection internally to avoid linking against specific kernel MAST roots, so the kernel itself might be pinned for a specific node/client pair - so the kernel might be special, but not anything else (and internally, the kernel library might link against a specific version of the standard library, but that is an internal detail). I don't know to what degree that indirection has been implemented in miden-lib, but that would be table stakes IMO for actually deploying things to a chain that isn't ephemeral.

Yes, we have this indirection implemented but this is only for syscalls. Specifically, transaction kerenel exposes a single procedure which takes the index of the procedure to be syscalled (and relevant parameters), and then internally uses a dynexec to execute the required procedure.

The mechanism is actually a bit more flexible than this. Anticipating that we'll have multiple kernel versions in the future, the users will be able to choose which kernel they execute their transactions against (the choice is made by selecting a reference block for the transaction).

The standard library on the other hand, doesn't have any dependency on the current kernel (AFAIK, and if there are parts that do, they should probably be moved to miden-lib IMO), so it isn't clear to me why we would make any assumptions (or impose any requirements) on specific versions of it. Ultimately you aren't linking against entire libraries, but specific procedures from a library - it just happens to be the case that, sans vendoring, having the package of the entire library is the only practical way to make sure the parts of it you actually linked against are available at runtime.

The main purpose of this is reducing program size. miden-stdlib contains some foundational procedures (e.g., smt, Falcon signature, etc.) and we don't want every program to have to vendor these dependencies. So, while we don't have to guarantee that every node/client has all versions of the standard library available, I think it is quite beneficial and probably won't have any meaningful impact on performance (most procedures from miden-stdlib will already be present to support the functionality of miden-lib).

This is a big part of what I mean by those libraries not being special. MAST is primarily beneficial when treated as content-addressable, and so you put all libraries/packages in some form of content store designed around that fact, and punt it to the person running the node/client to ensure that storage is seeded with the things they need. We should be building the tools to make that easy to do, as part of installing the toolchain; as part of running the node; and as part of running the client locally.

The libraries are not special in the context of the VM (they work just like any other library). The are special in the context of the protocol: every node that follows the protocol should have both of these libraries (and all their versions) loaded in their MAST forest stores. As mentioned above, the main reason for this is so that users don't have to vendor these libraries for their programs.

Back when I proposed the MAST refactoring, I mentioned that we would want to provide an abstraction in the VM for a registry of packages, and that this would allow for the VM to load packages (and request them on the fly if necessary), while not needing to provide the implementation of the registry itself. I also sketched out how a default filesystem-based registry could work, and what the tooling would look like to interact with it. At the time, we punted on that part of the proposal, but this is precisely the problem I was aiming to solve with that design. Rather than requiring that we ship certain libraries with the node and client, I think our approach should be to solve the handling of required libraries/packages via toolchain more generally, namely via the registry solution I proposed last year.

We actually did implement this abstraction - it is the MastForestStore trait. The VM retrieves all MAST information it needs to execute programs via this interface. We have a simple memory-based implementation of this trait that we currently use, and there are plans to add other implementations (the client is likely to have sqlite-based implementation soon - though, we could go with a filesystem-based one too).

[greenhat]

Having said that, I do think there are quite a few things we can do to reduce the size:

• We should definitely strip out debug info to compute the size. My guess, this will have a significant effect on reducing the overall MAST forest size. We should probably prioritize this work.

Done. Disabling debug_mode for the assembler in the compiler brought the MAST size from 72 KB down to 25 KB, so it does not hit the limit anymore. It's still far too large. I'm afraid we will hit the limit pretty soon with more complex account code.

• Our current serialization methodology is fast but "fat". We can implement a much more efficient serialization approach. I'm expecting the "slow but thin" serialization to give us somewhere between 5x and 10x in size reduction.

I created 0xMiden/miden-vm#1873 for this. Furthermore, I'll be happy to take care of it when I'm done with high-priority compiler tasks. I had experience squeezing every bit in AST serialization before.

[bitwalker]

The mechanism is actually a bit more flexible than this. Anticipating that we'll have multiple kernel versions in the future, the users will be able to choose which kernel they execute their transactions against (the choice is made by selecting a reference block for the transaction).

I saw you mention elsewhere that you can't recall why we support this functionality (multiple kernels/kernel selection). Is this actually something we need, particularly with syscall indirection? It's hard for me to imagine a scenario where users will understand this choice, or what it means to choose a kernel this way.

Presumably if there are multiple kernels to choose from, it is because there are breaking changes between them, otherwise there would be no reason to ever choose anything other than the latest version of the kernel - but I would think that, due to syscall indirection, breaking changes can never be allowed; instead, you'd need to add a new syscall implementing the new behavior, and contracts would have to migrate over time, while the kernel would need to support both the old and new syscalls in perpetuity.

In any case, it sounds like perhaps we don't need that additional complexity anymore? Definitely interested to learn more about it, if we do deem that it is still needed. Regardless, I think that's mostly unrelated to the rest of this discussion, but wanted to get some clarity on it.

One of the reasons for this is that programs may rely on some functionality from miden-stdlib directly.

To be clear, I'm not arguing against the idea of seeding the package registry and store with "official" libraries, I'm arguing against the idea of assuming that this is the case in key places, such as the VM, compiler, node and client. From their perspective, these libraries are just like any other, so if they are unavailable, but needed for some task, then the resulting error should describe that X library is could not be loaded, and provide pointers on how to load it. The node and client would, I assume, need to be told which version of the kernel to load from the MAST store in order to bootstrap/interact with the protocol, but even the kernel could just be a component that is installed as part of the toolchain with that approach, rather than baked into the node and client.

Our toolchain management can ensure that all versions of miden-stdlib and miden-lib are present in the local registry/store "out of the box", but that is essentially something that a user could do entirely manually if they wanted to. All we'd really be doing is automating that step.

In essence, I'm advocating for not baking these libraries into anything, but leaving them as standalone objects meant to be installed/used as part of the overall toolchain.

The alternative would be to vendor smt procedures into each respective program, but that would needlessly blow up their size.

N copies of a procedure vendored in multiple libraries would all share the same MAST root, so in the content store it wouldn't blow up the size at all - there would only be a single copy of that procedure.

Package sizes might be larger, but again, you only need to vendor the parts of a library that are actually used, and because packages don't live on chain, and the code in them is simply referenced by hash, the increased size of a package with vendored dependencies ultimately wouldn't matter in practice.

More generally, vendoring is a case-by-case choice - you can vendor all your dependencies, none of them, or just a subset; and we don't have to apply that rule to every package we create either. The benefit of vendoring is that it makes your package easier to work with, at the cost of making the package larger in binary form (the effect of which depends on how much of the dependency you use).

In any case, whether we vendor miden-stdlib into miden-lib or not, seeding the package store with every version of miden-stdlib and miden-lib would contain identical contents, so the decision to vendor or not has more to do with the state of the Miden package registry than anything else. Making packages more standalone until we have something more centralized (i.e. crates.io for Miden packages), means less hassle for developers in the interim.

The are special in the context of the protocol: every node that follows the protocol should have both of these libraries (and all their versions) loaded in their MAST forest stores.

I would argue that this isn't sufficient criteria to call them special. By this measure, any code referenced by a contract you wish to execute, transitively, is "special", because it is required to have that code in the MAST store.

It is true that executing the protocol requires at least one version of those libraries, if not more, so having a system without them present in the MAST store is generally a non-starter - the caveat to that is that in practice, you only need the versions of those libraries that actually are going to be executed, and only the parts of them that are going to be executed, for the protocol to still work, for a given execution. Which again, is essentially no different than any other library involved in the implementation of the contract(s) you are trying to execute.

The node, to be maximally useful, would realistically need to have a MAST store with pretty much everything referenced by the chain. Without that, you can only execute contracts that use code you have in the MAST store already, which isn't great. This is another reason why having a registry abstraction is useful.

We actually did implement this abstraction - it is the MastForestStore trait.

That is only one half (the content store) of the abstraction that I proposed originally, and the most important one to be sure, since it is the abstraction by which MAST itself is stored and queried, and thus is most relevant to the VM while executing a program.

What I was referring to was the registry, the means by which the VM (more precisely, the Host impl), when loading a package to execute, can request the parts of that package which aren't in the store yet. It can do this by examining the package dependencies, and requesting them from the registry by their digest. The registry either returns the requested package, which can then be "installed" in the content store; or it returns an error explaining why the package could not be obtained.

The registry is an important component in all of this, because without it, package management (and store management) is an entirely manual task. We also do not want to make registry tasks the responsibility of the store, because those are orthogonal concerns, and it would impede the extensibility of the system overall.

Done. Disabling debug_mode for the assembler in the compiler brought the MAST size from 72 KB down to 25 KB, so it does not hit the limit anymore. It's still far too large. I'm afraid we will hit the limit pretty soon with more complex account code.

That tracks with what I was expecting the difference to be. I honestly expected it to be a bit more drastic than that, but not very surprised that it is still quite large even without debug info.

That said, @bobbinth was referring to stripping debug info decorators from the MAST itself, which is currently not supported yet. Disabling generation of debug info at assembly time is the wrong place to solve this in general, instead we'd want to strip debug info from the MAST in the client, presumably some time before the account update is being computed, so that the package itself can still provide the debug info when needed.

[greenhat]

Done. Disabling debug_mode for the assembler in the compiler brought the MAST size from 72 KB down to 25 KB, so it does not hit the limit anymore. It's still far too large. I'm afraid we will hit the limit pretty soon with more complex account code.

That tracks with what I was expecting the difference to be. I honestly expected it to be a bit more drastic than that, but not very surprised that it is still quite large even without debug info.

That said, @bobbinth was referring to stripping debug info decorators from the MAST itself, which is currently not supported yet.

Oh, I need to up my game with assembler then and get more familiarity with it. I noticed that debug_mode is a condition for including some decorators, but I missed that there are more of them.

Disabling generation of debug info at assembly time is the wrong place to solve this in general, instead we'd want to strip debug info from the MAST in the client, presumably some time before the account update is being computed, so that the package itself can still provide the debug info when needed.

I'm not sure if I'm following. If the user asked for --release from cargo-miden, why would we want to generate debug info in the compiled MAST?

[bitwalker]

I'm not sure if I'm following. If the user asked for --release from cargo-miden, why would we want to generate debug info in the compiled MAST?

Because if we don't generate the debug info for the build, it can never be recovered (in theory, recompiling with the exact same environment and inputs would produce the same binary, but that's unreliable, and not at all helpful if you are trying to debug a program where parts of it were produced by someone else).

The debug info can always be separated from the MAST, so there isn't any meaningful cost to always producing it, and it makes release packages useful in both modes.

There is still some work to be done to enable split debug info fully, but we should assume that we will always emit it by default.

[bobbinth]

The mechanism is actually a bit more flexible than this. Anticipating that we'll have multiple kernel versions in the future, the users will be able to choose which kernel they execute their transactions against (the choice is made by selecting a reference block for the transaction).

I saw you mention elsewhere that you can't recall why we support this functionality (multiple kernels/kernel selection). Is this actually something we need, particularly with syscall indirection?

Yeah - I'm not sure it is needed. I had some reason for this design initially, but I can't see it now. @Fumuran - maybe you remember? Either way, @Fumuran, could you create an issue to remove this functionality (and keep just one kernel per block)?

To be clear, I'm not arguing against the idea of seeding the package registry and store with "official" libraries, I'm arguing against the idea of assuming that this is the case in key places, such as the VM, compiler, node and client.

I think maybe we are talking about the same thing here but in different ways. These libraries are not special in any way (they look and behave just like any other library), but the key assumption here is that they are "pre-loaded". That is, when, I as a user, compile my account or note code, I can assume that all nodes will have these libraries and I don't need to vendor them. This would not be true for other libraries (i.e., if I write my own library or use a library that someone else wrote for some specific use case, I will need to vendor them). And of course, if I wanted to, for some reason, vendor miden-stdlib and miden-lib, I will be able to do that.

What this practically means for the compiler is that when we create a project template, we'd set these two libraries as vendored by default, and if the user wanted to change this setting, they'd be able to do that.

Package sizes might be larger, but again, you only need to vendor the parts of a library that are actually used, and because packages don't live on chain, and the code in them is simply referenced by hash, the increased size of a package with vendored dependencies ultimately wouldn't matter in practice.

Package size is the main thing I'm concerned about here - and more specifically package sizes for account code and note scripts (most other things don't really matter). But for these, every KB matters. So, if we tried to vendor something like std::collections::smt procedures into note scripts, they could easily blow up script sizes by something like 10x.

One thing to clarify here - the size really only matters for public accounts and public notes (because these go on-chain).

What I was referring to was the registry, the means by which the VM (more precisely, the Host impl), when loading a package to execute, can request the parts of that package which aren't in the store yet. It can do this by examining the package dependencies, and requesting them from the registry by their digest. The registry either returns the requested package, which can then be "installed" in the content store; or it returns an error explaining why the package could not be obtained.

I may be missing something here, but I'm viewing the registry part as an implementation detail of the MastForestStore interface. That is, as far as the VM is concerned, there is some implementation of MastForestStore it needs - how it functions underneath, doesn't really matter for the VM. We will have one way to implement it for the client, another way for the node, and people could even have custom implementations in the future.

For the node, the way I'm thinking it'll function, the registry will contain the following:

• All versions of miden-stdlib.
• All versions of miden-lib.
• Codes of all network accounts (these are a sub-type of public accounts).

We can expand this list with official libraries - but, at least the official implementation of the node, would not have anything else pre-loaded.

Oh, I need to up my game with assembler then and get more familiarity with it. I noticed that debug_mode is a condition for including some decorators, but I missed that there are more of them.

There are two things currently in progress:

• We want to remove this flag and always generate debug info at assembly time.
• We will add functionality to strip out all debug info from packages post code generation (and this will also include stripping out error messages and maybe other things).

There are issues for both of these in miden-vm but the work hasn't started on them yet. I believe these are one of the next things on @paracetamolo's list.