# EPF Week 10 Update

This week, I faced some blockers and most of the time was spent on trying to resolve them. I was able to perform `execute` operation on `pectra-devnet-6 with/without epoch transition` successfully but it failed on the test case `mainnet without epoch transition`.

The zkVM crashed silently without any errors so after delving into what was the root cause of this error, I found that the line `let (output_bytes, report) = vm.execute(state_ssz, block_ssz, cache)?;` was returning an empty `output_bytes` array. Furthermore, as I dug more inside the stack, I realized the root cause of this error was due to this line in my `zkvm/host/src/backend.rs`

let (output, report) = client.execute(STATE_TRANSITION_ELF, stdin).run()?;
ZKMPublicValues { buffer: Buffer { data: [], ptr: 0 } }

I consulted with Artiom for help with this and he said that either the VM runs out of memory or Ziren doesn't support the large cycle count. He asked me to reach out to the Ziren team as well so I opened an [issue](https://github.com/ProjectZKM/Ziren/issues/284) in their repository.

The guest code exited without any errors before the deserializations of the `state_ssz`, `block_ssz` and `cache_ssz`. One of their team members reported that the `state_ssz` could be causing excessive memory usage, so I asked if there was provision for an alternative allocator since Ziren uses `bump-allocator` by default for managing memory allocation. A similar [issue](https://github.com/succinctlabs/sp1/issues/2334) has been opened by the Grandine team for SP1.

This was also the first time I came to know about `bump-allocator` and `embedded allocator`. `bump-allocator` uses linear allocation pattern which moves the pointer in a preallocated memory region while `embedded-allocator` uses a dynamic (heap-like) allocation pattern which supports reclaiming/reusing memory and handles fragmentation. In our case, even after changing to `embedded-allocator`, it caused memory overflow likely due to metadata overhead and fragmentation.

Apart from that, I was examining the previously written code like the `state transition` functions and overall guest + host code workflow since there was not anything else to do from my side. I made a slight change to my [PR](https://github.com/Dyslex7c/grandine-zk/pull/1) as well.

For some reason, local proving takes a lot of time. It ran continuously for around 12 hours before I eventually had to stop it. On the other hand, `execute without proving` doesn't take much time, likely because proving includes heavy cryptographic operations over a large finite field.

## Work for the next week

I believe there isn't much changes to make in the code for now until mentioned. Nevertheless, I will still try and optimize it further and look into the codebase more in depth and maybe learn something new. I will also try to implement the 64-bit atomics for MIPS that was previously causing a blocker.

## Conclusion

This week was mostly spent on debugging and understanding of the zkVM internals. I was able to trace the exact place that was causing the issue and later concluded that it was a memory allocation issue. With help from the Ziren team, I hope we can get past this blocker soon.