[DNM] [native-prover] add a canary value to native prover, and then run it in a unit test

[bleepbloopsify]

No description provided.

[Trivo25]

right now we load the wasm module here to inject it into jsoo and load it again for usage in o1js itself here

[bleepbloopsify]

Ah I see, it needs to be loaded and built in mina

[querolita]

So this is so you can import the canary in the unit test as import PlonkNapi from 'plonk-napi';?

[bleepbloopsify]

Yes correct

this is because the napi-rs package expects us to export this native module as a standalone npm package, rather than bundled together with our JS code.

I believe its so npm can decide which native bundle to download for the end-user, that way they don't grab every compiled binary for every version. (Also so they don't need rust to build and install an npm package).

I'm not sure what our plan for packaged and release was here, but we might need to do something like this, or we're going to implement the OS/ARCH switching ourselves?

[querolita]

Maybe related to this issue #2415, linking here for future reference

[bleepbloopsify]

Ah perfect

[querolita]

So should this replace

cargo build \
    --manifest-path "${PLONK_NAPI_ROOT}/Cargo.toml" \
    --release

in https://github.com/MinaProtocol/mina/blob/d4ff2e968c9b3239e99f9c414afe2a24ac855a1d/src/lib/crypto/kimchi_bindings/js/native/build.sh#L12-L14
?

I suppose the napi cli takes care of the different extensions for the dynamic library (depending on OS) and renames it to .node without needing us to do it manually?

[bleepbloopsify]

Yes correct.

We can also have it setup individual npm packages for us by specifying output locations and architectures (since I believe rust supports cross-compilation -- could also use docker/buildkit here)

It won't change the import paths, and as long as we have the js side exposed, everyone should be happy here

[querolita]

Yes, that's a good idea, having separate folders for different architectures.

Regarding the replacement, then feel free to update the build.sh script so it won't build the dynamic library twice once we go for this approach.

[bleepbloopsify]

Did several more inches of work here:
generating the platform + the header .js file with napi allows us to import the proper symbols now (but no default export, so YMMV, lol)

I'm opting to leave the current loading for wasm + napi AS-IS in the kimchi_stubs, this is meant so we can import the native module and run it locally in o1js (which I think still has value).

The JSOO process to compile the native plonk_wasm.js file requires that its a static JS file locally so that dune can pick it up and bundle everything together.

This process will allow us to load it in later in o1js, and access the methods easier, and also break up the native bundle properly.

I hope I'm not jumping the gun here, but this is probably the right way to continue, since npm is how we will distribute the appropriate native binaries, supposedly.

I'm OK to leave this as draft for now, since we also have a unit-test in gate-vector that seems to work just fine. On the other hand, this tests our type generation, so it might be even more important to get in

[bleepbloopsify]

request: decision

1. close this in favor of only using the rust side of napi-rs (and not napi-rs/cli -- no generating types)
2. keep this and flesh it out in favor of having both this and the build.sh build our bundle for now, to ensure that both typegen works and the native module separation works

@Trivo25 @querolita

[bleepbloopsify]

closing this because #2596 does this but way better