"Memory Layout Restrictions" proposal

[marcinbugaj]

No description provided.

[kevaundray]

cc @jbaylina @shamatar @tamirhemo @maximmenshikov @eigmax @jonathanpwang

[maximmenshikov]

@marcinbugaj in general no objections.
However, as we need to debug code, I suggest that we add a point that zkVM developer team is recommended to supply a linker script that is a gentle mix of zkVM-specific linker script and normal Linux linker script. If we can run the app in native Linux, it gives significantly more debugging and testing capabilities, and I don't think we should throw this possibility away.
That might push the zkVM R&D team towards using the layout more compatible with Linux. I think it is good for zkVM world.

[kevaundray]

gentle mix of zkVM-specific linker script and normal Linux linker script

I'm wondering if this suggesting leans more towards just standardizing the memory layout?

[maximmenshikov]

gentle mix of zkVM-specific linker script and normal Linux linker script

I'm wondering if this suggesting leans more towards just standardizing the memory layout?

There are two widely different aspects: efficiency and compatibility.
zkVM must be efficient, but testing the ELF must be possible offline - this gives much richer debugging environment. In that case, we need linker script that is more compatible with regular Linux.

In our case, for debugging we have made zkvm-specific script and the Linux script that preserves sections and important symbols of the zkvm script. The latter is very good for gdb, lldb, whatever, and speeds up development a lot.

[marcinbugaj]

The silent assumption of mine was that a guest application source code can be compiled for Linux with stock toolchain (for C and Rust). That implies that no custom linker script for Linux is needed. That is achievable as long as zkVMs provide Linux implementations of precompiles library and IO library (#8). Perhaps we could standardize it in a separate PR saying that "zkVMs must provide precompiles library and IO library that works on Linux so that any application targeting zkVM can be compiled without source code modification for Linux". That proposal could be called "Testing and Linux guest program portability". @kevaundray , @maximmenshikov what's your take on that?

[kevaundray]

The silent assumption of mine was that a guest application source code can be compiled for Linux with stock toolchain (for C and Rust). That implies that no custom linker script for Linux is needed. That is achievable as long as zkVMs provide Linux implementations of precompiles library and IO library (#8). Perhaps we could standardize it in a separate PR saying that "zkVMs must provide precompiles library and IO library that works on Linux so that any application targeting zkVM can be compiled without source code modification for Linux". That proposal could be called "Testing and Linux guest program portability". @kevaundray , @maximmenshikov what's your take on that?

Would this mean that zkVMs will need to move their ecall syscall numbers down to not collide with linux syscalls? (For the zkVMs that use ecall)

[marcinbugaj]

Would this mean that zkVMs will need to move their ecall syscall numbers down to not collide with linux syscalls? (For the zkVMs that use ecall)

No. An application code won't use syscalls. That's because we agreed to riscv64im-unknown-none-elf which doesn't use syscalls for IO, memory allocation etc. Syscalls can be used as an internal implementation of IO library or precompiles library. These are provided by zkVMs and would be different for zkVM and host (x86). Actually there could be a generic implementation of these libraries for host.

[marcinbugaj]

@maximmenshikov , @kevaundray here is a document that covers compatibility and testing: https://github.com/eth-act/zkvm-standards/pull/12/files

[shamatar]

No objections from me