Potential instruction to help with u32 safety checking about miden-vm

[bobbinth]

That would be awesome! I do want to say that this might be a fairly involved task. So, maybe worth splitting it into a couple of PRs. For example, the first (simpler) PR could be to add u32assert2 instruction to Miden assembly, and only after that add it to the VM's instruction set.

[0xkanekiken]

If no one else is looking into it, then I'd like to pick this up?

[0xkanekiken]

Actually, that's the plan! I will start working on adding u32assert2 instruction to Miden assembly and submit a PR. Just wanted to know your thoughts on how are we planning to reduce the overall VM cycles. For ex: adding two u32 value unsafely will require 1 VM cycle and likewise doing it safely would costs us 7 VM cycles (1 for addition and 3 each for asserting u32). How can we do this in 2 VM cycles("we'd be able to do must safe operations at just 2x the cost of the unsafe ones.")? Are we planning to do the operation unsafely first and then check of the output is u32 or not? Again this method will cost 4 VM cycles. Apologies if I'm missing something. Thanks.

[bobbinth]

Actually, that's the plan! I will start working on adding u32assert2 instruction to Miden assembly and submit a PR.

Great!

For ex: adding two u32 value unsafely will require 1 VM cycle and likewise doing it safely would costs us 7 VM cycles

Once u32assert2 is implemented as a native VM operation (i.e., an operation which takes 1 cycle) the cost of safe operations will be reduced significantly. But you are right, for operations where we need to check that output is in the right range, it will still take more than 2 cycles. To take a u32add operation as an example.

Plain u32add would take 4 cycles and would look like this:

u32assert2
u32add.unsafe
eq.0
assert

But u32add.full would take only 2 cycles and would look like this:

u32assert2
u32add.unsafe

PS: There is a typo in "we'd be able to do must safe operations at just 2x the cost of the unsafe ones" - "must" should be "most" :)

[0xkanekiken]

Thanks for the explanation. Makes sense now. What opcode shall I use for U32assert2?

[bobbinth]

For the assembly instruction let's call it u32assert.2.

As discussed above, as a part of the first PR there is no need to change the actual opcodes of the VM. But once we get there, the opcode could be just u32assert2.

[0xkanekiken]

I'll start working on adding u32assert2 to the core VM instruction set, given it's already been added to the assembly. @bobbinth What binary literal shall I use for u32assert2?

[bobbinth]

@0xkanekiken - yep, u32assert2 sounds good.

[0xkanekiken]

@bobbinth - I've introduced u32assert2 opcode to the VM instruction. Let me know your thought on the pull request.

[bobbinth]

Closed by #202