Closed MaksymMalicki closed 3 weeks ago
Hi @Osatuyi, this issue is currently just a writeup and requires further discussion.
Hey @MaksymMalicki thanks for gathering all these information! I have some questions, hope you can answer.
End run What it does - runs, until sufficient number of vm steps have been executed, to allocate needed number of memory cells for the builtins segments.
I am not sure I understand, running steps for the sake of running steps won't allocate extra slots in the builtins as far as I know. Once you hit the end of program running extra steps won't generate any changes on the pc
. Also, the runner already runs to the power of 2 when in proof mode.
Helper methods that need to be implemented: check_used_cells check_range_check_usage check_memory_usage check_diluted_check_usage
I am uneasy that you know with such clarity what methods are already needed before writing a solution. Are you by default saying that we should use the Python implementation? If it is the best way to do it for our project, then great, but I am unsure that you've already went through that line of thought.
I think before saying what's missing, we should now why is it missing. Why is it required by the VM, and then how do we solve it. I believe there are subtle but important differences there.
Same thing here. We dont need "read return values", I have no idea what does that means. From what I gather by reading the definition, we need to include in the memory trace a pointer to each builtin segment last accessed/allocated value. I dunno this explanation is correct, but at least there was an attempt to understand the VM..
If you don't understand what's missing then it makes sense to just use the python solution and not thinking too much about it. If that's the goal of this VM, then great, but then again, all VMs already do that... .
They need to contain this following information which is currently not present: ratio, cells per instance, instances per component. Maybe turning the BuiltinRunner from interface to datastruct would help.
What is ration, cells per instance and instance per component? Could you expand on what each of those fields represent.
I will stop signalling other stuff. I agree with the diagnosis, I disagree with everything else. All the solutions suggested seems to follow the thought of "We will be implementing it like this, because someone 3 years ago implemented it like this". Not taking into account the current context, the difference between languages and the difference in architecture that both projects have.
Again, that's not a bad approach but I think it is not the correct one, unless the goal is making a mediocre product. And again, if that's the best solution let's implement it that way, but first let's prove that's the best solution and if not then let's create it ourselves. I think that's the right approach.
Hi @rodrigo-pino, thanks for the feedback. I rewrote the issue context, focusing more on the diagnosis of the problem and what causes the differences. I agree that the previous version was very suggestive and written with the approach influenced by the existing solutions.
The problem: Currently, in the integration tests we are comparing decoded memory and execution traces of Nethermind Cairo-VM with the Starkware Cairo-VM implemented in Python. When we try to run the following Cairo0 programs as examples in Nethermind VM and Starkware VM with layout small, we can notice the differences in decoded memory traces, which are prompted by the integration tests.
After conducting some digging in the code of both VMs, I noticed, that the segments offsets, which are significant in memory relocation differ between the VMs. When running the following program:
We will notice, that the segments offsets for relocation look like this:
Eventhough the sizes of the segments look like this:
Since the addresses during relocation are transformed into felts, by adding the address offset to the segment base (offset), this should indeed cause the differences in the values of relocated addresses. The differences in the relocated addresses values look like this:
During decoding the memory in Nethermind VM, we take the highest memory address as length of the memory. As one can see in the example, the highest memory addresses are not the same, thus the effect of decoded memory filled with nills. From this short analysis, the difference in the memory traces is caused by two problems:
builtins
field of the compiled program json. This might cause differences in the memory traces, as some segments from given layout might not be present in thebuiltins
field, which will affect the segments offsets. To conclude with a question, should we support layout flags as well?