Comments (11)
Some ideas to handle this:
- Reserve ranges of error codes for the kernel. Trying to use said error codes in a note would be a compilation error.
- Cons: I think this is a bad approach, since we would need to introduce configuration to the assembler, generally making the compilation process more complicated
- Instead of having the code being a single
err_code
, we can add the originating context. So the error would no longer be just the code but the pair(context, err_code)
. - Perhaps also add the MAST root to the error, this way one can unambiguously identify the source of an error.
- Cons: This may not work that well for the notes in the transaction script. Since the MAST root is the tx's script and not the notes. But I'm not sure how to fix this.
from miden-vm.
I think the first variant is the best one, since we don't modify MAST
and don't increase its size.
we would need to introduce configuration to the assembler
Is it necessary to have a changeable error codes configuration for the assembler? Can we have a fixed encoding pattern for them? Something similar to the approach we used with event_id
's. In that case the compilation process won't change, just a one more check.
Also I'm not sure that for now we can distinguish a plain procedure and a note, so probably we will need to introduce another flag in the AssemblyContext
in addition to the is_kernel
.
from miden-vm.
I think enforcing that there are no collisions is going to be difficult (or at least, I'm not seeing a way to do it). The main issue is that the same code can be used in multiple contexts. For example, we have collections::smt
code which could be used both by a kernel and by user code (e.g., note, account). So, we can't encode context into the smt
source code.
One thing we can do is try define a convention, and hopefully, people will follow it. The convention we've been following so far is:
- For error triggered by the VM itself, we set the top 16 bits of the error code to 0, and the remaining 16 bits define a unique error code for VM errors.
- For errors triggered by the code in standard library, we set the top 16 bits to 1, and the remaining 16 bits define a unique error code for the
stdlib
. - For errors triggered by the code in
miden-lib
, we set the top 16 bits to 2, and the remaining 16 bits define a unique error code for themiden-lib
.
from miden-vm.
@bobbinth in that case, I think the second option would do the trick:
Instead of having the code being a single err_code, we can add the originating context. So the error would no longer be just the code but the pair (context, err_code).
If you don't want to use the tuple, we can also forbid the high bits from being set at the MASM level, and the VM set the high bits depending on the context
from miden-vm.
I think the second option would do the trick:
Instead of having the code being a single err_code, we can add the originating context. So the error would no longer be just the code but the pair (context, err_code).
If you don't want to use the tuple, we can also forbid the high bits from being set at the MASM level, and the VM set the high bits depending on the context
I'm not sure how this would work. Specifically, by the time the VM executes an instruction, all info about where the instruction originated (i.e., which library) is erased. Basically, there isn't enough info to tell what the context of a given instruction should be.
from miden-vm.
I suppose you assumed I meant providing the information statically? In this case, since the same code can be execute at different contexts, the information would need to be retrieved at runtime from the System
struct. Is there are reason why this should not be possible?
from miden-vm.
context
in the System
struct is not the same context as the source of the instruction. System.context
is basically a random value (except for the root context, for which the value is always 0 - but even here, it doesn't help us as library code could be executed in both root context and user contexts).
from miden-vm.
context in the System struct is not the same context as the source of the instruction. System.context is basically a random value (except for the root context, for which the value is always 0 - but even here, it doesn't help us as library code could be executed in both root context and user contexts).
I don't think I'm following, that is exactly what I wanted. If lib A
has an error X
at root context we get (0, X)
, other we get (L, X)
, and that allows us to differentiate where the error happened
from miden-vm.
Let's take std::collections::smt
as an example. We can execute the code contained there in the root context or in user context. We can't force that code in std::collections::smt
is always executed in root context.
If we just want to figure out the context in which an error happened - we can already do that by overriding on_assert_failed()
method in the Host
interface. But this doesn't help us with preventing collisions in error codes.
from miden-vm.
But this doesn't help us with preventing collisions in error codes.
Yes, we established that already.
If we just want to figure out the context in which an error happened - we can already do that by overriding on_assert_failed() method in the Host interface.
Seems like it is already possible to get the context. Closing the issue.
from miden-vm.
I do think we should document the convention somewhere though. Maybe there are ways to improve on it somehow as well.
from miden-vm.
Related Issues (20)
- `stdlib smt`: add support for leaves with multiple key/value pairs
- Remove `smt64` from `stdlib` HOT 1
- Implement`adv.push_smtset` and `adv.push_smtget`
- Allow the removal of entries from advice map
- Handle extra memory requests made by new `RCombBase` op HOT 1
- `debug.stack` decorator is broken HOT 1
- Implement extensible subsystem for on-demand storage/provisioning of MAST objects HOT 7
- Test to ensure that `RCOMBBASE` instruction can be executed and proven HOT 1
- Introduce a newtype for to represent a row in a trace
- Update `StackOutputs` fields HOT 1
- Update `usize` serialization and deserialization HOT 1
- Encryption in the VM
- Kernel procedure table
- Reproducible (ish) builds HOT 6
- Change errors to use thiserror HOT 5
- mtree_verify should also accept err HOT 3
- Compilation failure due to missing name should report the user readable name HOT 4
- Rename miden crate so that it matches the package name. HOT 1
- Write tool to format `Cargo.toml` HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from miden-vm.