Standard for Input/Output Padding

[dhsorens]

From work on evm-asm:

Currently, evm-asm receives SSZ bytes from e.g. Zisk but SSZ doesn't self-identify length, so evm-asm does some unsafe guessing, which is (in principle) fine if the host is known and configured but not ideal. We're considering putting in an RLP-envelope so the input into evm-asm can self-identify length.

It would be nice to have a standard enforced everywhere on how inputs/outputs are padded.

[pirapira]

This is relevant because zisk inputs are always multiple of eight-bytes.

Evm-asm has a length prefix (8 bytes, big endian).

Evm-sail has a length prefix too (8 bytes, little endian).

[jsign]

Let’s separate the discussion reg input and output.

Inputs

Regarding the input the standards says: void read_input(const uint8_t** buf_ptr, size_t* buf_size) .

If the host sent 10 bytes, then from the guest program perspective it must receive buf_size equals 10. IMO, if a zkVM is not sending 10 because it is adding some padding or similar, it is not conforming to the specs.

Under this assumption the guest program received a well-define chunk of bytes that must SSZ decode. There should be no ambiguity on how to do this since the specs assume the received bytes contain no padding or similar. (i.e. if there are trailing bytes, the input is wrong and the guest must fail. There is already a test for this in execution-specs).

My tentative conclusion (if I’m not missing anything) is that we don’t need to change the standards or execution-specs.

@pirapira, you mentioned:

This is relevant because zisk inputs are always multiple of eight-bytes.

But looks to me they aren’t doing what you say. They append the original length internally, which is what is used as buf_size , so it doesn’t seem there should be any confusion on the guest program side regarding this? They do pad the input, but the guest program must use buf_size.

Output

For output in the standard, we have void write_output(const uint8_t* output, size_t size)

This must mean that from the verifier perspective, the received bytes must have length size. If this isn’t the case, it does not comply with the spec. (The standard accepts multiple write_output calls, quite honestly, I would propose to remove this and only accept one -- open to feedback here).

We know for a while Zisk does not conform to the spec here (at least for now), since they pad the output. The reason this hasn’t been “a big deal” is that the verifier can construct the expected output and compare it directly (expecting only zeros if there are trailing bytes), since part of the responsibility of the verifier is to know what it expects. But, IMHO, dealing with extra bytes and checking they are zero etc is not something acceptable.

If write_output was called with size as a parameter, the verifier must receive size bytes, and be part (indirectly) of committed public inputs (fine if outside of the application layer to not complicate execution-specs for no good reason). If this isn’t the case, I would consider the zkVM is not complying with the specs.

Under this assumption, from an SSZ decoding perspective, there is no ambiguity (i.e. potential trailing bytes mean an incorrect guest program execution since the encoded SSZ bytes are wrong).

Tangent: Zisk currently limits this interface to 256 output bytes. That limit is another potential conformance issue reg specs (although for the current guest program definition, it shouldn't be a problem, but we shouldn't use this as an argument).

---

cc-ing @han0110, @frisitano since I think they discussed this also out of band if they want to chime in.

[pirapira]

I had discussion with @frisitano too.

My conclusion is that what's in zkevm-standards cannot be improved to help evm-asm.

evm-asm will not be using RISC-V code provided by zkvm teams (unless they prove theorems about their RISC-V code), so zkevm-standards remains an informal source of guidance.

evm-asm needs to reverse-engineer read_input() and write_output() implementations, instead of calling them.

[jsign]

evm-asm needs to reverse-engineer read_input() and write_output() implementations, instead of calling them.

Why not calling them? Isn't this the purpose of having the standards?

[pirapira]

evm-asm will be implementing the formally verified versions of input and output, using each zkvm's features. The reason is that evm-asm needs to prove the implementations' max steps and memory consumption (like stack consumption).

[dhsorens]

The fact that there are canonical ways to transform "incorrect" input and output into what we expect makes me not worry too much about this, but it could be nice to be a little more precise in the specs. In principle the standard could be an equivalence relation - valid input up to trailing zeros (defined by a truncation function that checks that what it truncated is always just 0's)

[jsign]

The fact that there are canonical ways to transform "incorrect" input

In my answer above, the current zkevm-standards makes it quite clear that there is no fact justifying this?. Or maybe I'm missing something? If so, can you say what we could add to make something that might feel unclear?

and output into what we expect

Reg the output, Zisk isn't complying, but I don't see this as a standardisation problem (but more like their implementation). Maybe we can make it clearer that the output length should be part of the committed public input? Happy to add any extra sentence to clarify further, if that helps.

@dhsorens @pirapira, maybe the next steps for to move this forward is that you could propose a concrete change in the standardisation that you feel can help to make things clearer? Feel free to open a PR or we can keep discussing in this thread (but maybe in more concrete ways).