Add mips-zkm-zkvm-elf triple

[eigmax]

We are trying to add a new target mips-zkm-zkvm-elf into rustc.

We have implemented a MIPS zkVM(zero knowledge virtual machine) to generate validity/ZK proof for general purpose computing. It allows the dev to compile the rust program into MIPS ELF, and the it proves the MIPS emulator/VM and generate a succinct proof to tell the verifier that the computing has been executed as expected.

This new target can significantly reduce the installation overhead for Rust dev.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @jieyouxu (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

[taiki-e]

Btw, as for crossbeam, this issue was already resolved over a year ago. crossbeam-rs/crossbeam#1033

[jieyouxu]

Thanks for the PR. Before this target can be accepted, this PR will need two things:

1. Can you please also add platform support docs for this Tier 3 target?
   • You can take a look at e.g. https://github.com/rust-lang/rust/pull/130750/files#diff-bc17631f04294210bbf39b6bcac37f5158feeba4e2efcfb59de8be96a1a572a6.
2. Please also confirm that the target conforms with the Tier 3 target policy, as described in Adding a new target.
   • For example, see Add arm64e-apple-tvos target #130614 (comment).

[saethlin]

EDIT: nevermind, I thought we didn't have any zKVM-related targets, but we apparently do.

It is not at all clear to me (as a compiler maintainer who just tried to use Google to learn about zkvm) that these two uses of the term "zkvm" are referring to the same thing. It would be rather bad if they are not, so I would like some step taken to prevent/clarify problems here.

[eigmax]

@saethlin there is one already. https://doc.rust-lang.org/rustc/platform-support/riscv32im-risc0-zkvm-elf.html

@jieyouxu thanks! I will follow the instruction and add the docs.

[saethlin]

there is one already

I have read that. It is not clear to me, based on the terminology and authorship of this PR that these two things called "zkvm" are affiliated with each other, or are referring to a generic concept that they both agree they do not own.

[eigmax]

I have read that. It is not clear to me, based on the terminology and authorship of this PR that these two things called "zkvm" are affiliated with each other, or are referring to a generic concept that they both agree they do not own.

Good question. you are right, zkVM is a general concept that representing it can generate the validity proof (I would use this instead of zero knowledge proof for easier understanding) for some instruction set. For RISC0, it builds a zkVM for RV32, and for zkMIPS, we build a zkVM for MIPS32R2. More generally speaking, there are also some other impls, like zkWASM, or custom instruction set, like Miden.

For your concern, should dev be aware of different zkVMs? I think we should due to:

1. It's obvious that different apps may be built for different architecture, like MIPS or RV, and the validity proof should constrain the specific function and logic on specific architecture.
2. The original idea we build the zkMIPS is that MIPS is already used to build the Fraud Proof VM by some blockchain projects, like Optimism. And zkMIPS can help those projects to solve their long finality time issue.

[workingjubilee]

@eigmax Does "zkvm" actually have a specific meaning with regards to these targets that they all uniformly share, or are they allowed to have entirely different ZK proof implementations? Do they share a syscall standard or some other abstract interface? Why does "zkvm" matter for the target's name?

To put it another way, if tomorrow Apple decided to make their entire Darwin OS run on a ZKVM, would we want to rename all the Apple targets to {arch}-apple-darwin-zkvm and so on, or would this fact be largely unimportant from the perspective of merely compiling software for the target?

[workingjubilee]

cc @flaub @jbruestle @SchmErik Can you explain your perspective on the matter of using target_os = "zkvm" for two targets that don't seem to obviously share an OS interface?

[workingjubilee]

You copied the revision name, this is incorrect.

[qethu]

@eigmax Does "zkvm" actually have a specific meaning with regards to these targets that they all uniformly share, or are they allowed to have entirely different ZK proof implementations? Do they share a syscall standard or some other abstract interface? Why does "zkvm" matter for the target's name?

To put it another way, if tomorrow Apple decided to make their entire Darwin OS run on a ZKVM, would we want to rename all the Apple targets to {arch}-apple-darwin-zkvm and so on, or would this fact be largely unimportant from the perspective of merely compiling software for the target?

I suspect that the OS section is useful here, is that the ZK may be some different with BareMetal embedded software developing.
Such as it can set main as the entrance of the ELF file.

[qethu]

cc @flaub @jbruestle @SchmErik Can you explain your perspective on the matter of using target_os = "zkvm" for two targets that don't seem to obviously share an OS interface?

I guess that there may be a case that, a same app can be useful for both baremetal embedded hardware and zKVM emulator.
The 2 platform may be quite different, such as the code to initialize the hardware is not needed by zKVM;
and the entrance can be main (or other pure Rust code) on zKVM.

[workingjubilee]

Would that mean cfg(target_os = "zkvm") would be useless in terms of selecting the correct behavior, because there would be no consistent handling between these two "OS"?

I do not think it is appropriate to introduce future possibilities about "what if we make fn main() work on this bare metal target?" right now. The more important future possibility is what if one of these targets does and the other one doesn't, for any given behavior?

[workingjubilee]

In general, code compiled for "bare metal" targets does not necessarily have code to initialize hardware. Case in point: wasm32v1-none is also a bare metal target and also is a VM.