Expose OpZkPrecompile builtin to SilverScript front-end

[trillskillz]

Summary

Expose OpZkPrecompile as a callable SilverScript builtin.

This wires the existing engine-side KIP-16 opcode (0xa6) through the front-end with the minimal surface needed by downstream callers:

• add the builtin dispatch row in silverscript-lang/src/compiler/compile.rs
• add the debug value type row in silverscript-lang/src/compiler/debug_value_types.rs
• add the stdlib declaration/docs in silverscript-lang/std/builtins.sil
• add a minimal compile test (zk_minimal.sil) proving the builtin parses/builds through the compiler

Why

OpZkPrecompile is already implemented engine-side in rusty-kaspa via KIP-16, but the pinned silverscript-lang front-end snapshot still has no builtin row for it. That makes it impossible to express ZK-aware patterns in plain SilverScript without brittle raw-bytecode post-processing.

This PR intentionally keeps the builtin at 0 args. The opcode consumes its operands from the stack, and the operand schema varies by precompile tag, so pushing a tag-specific higher-arity wrapper into the compiler would leak verifier details into the front-end. Higher-level helpers can live in downstream SDKs.

Test plan

• cargo test --manifest-path silverscript-lang/Cargo.toml --test examples_tests -- --nocapture

Context

OpenSilver tracking RFC / downstream context:

• https://github.com/trillskillz/OpenSilver/blob/master/references/silverscript-rfc-opzkprecompile.md
• Upstream silverscript PR: expose OpZkPrecompile builtin trillskillz/OpenSilver#3

Reviewers who may care about the stack-shape/doc wording:

• @OriNewman
• @saefstroem

[trillskillz]

Follow-up from downstream prototyping in OpenSilver:

I validated that this PR's 0-arg builtin exposure is necessary but not yet sufficient for authoring a real Phase-5 contract in current SilverScript syntax.

Concrete finding:

• patched silverc accepts require(OpZkPrecompile())
• but the language rejects raw expression statements intended to push operands before the opcode, e.g.:

entrypoint function run(byte[] proof, byte[32] a, byte[32] b) {
    a;
    b;
    2;
    proof;
    vk;
    0x20;
    require(OpZkPrecompile());
}

The parser errors at the first a; with:

expected expression_list, modifier, array_suffix, or Identifier

So unless there's another stack-shaping form I'm missing, downstream contracts still need one of:

1. expression statements / explicit push syntax, or
2. a higher-arity builtin surface that lowers the operands in the right order.

I'm leaving this PR up because it still exposes the opcode name cleanly, but I wanted to flag that the current front-end syntax appears insufficient for real contract authoring beyond the minimal compile test.

[trillskillz]

Concrete follow-up from local prototyping:

I confirmed that compile_opcode_call() lowers builtin args in source order, then emits the opcode. That means a higher-arity surface can shape the stack deterministically.

I tested a local prototype by changing the builtin arity to 9 (for 5 Groth16 public inputs + n_inputs + proof + vk + tag) and compiling this contract successfully:

contract ShapeTest(byte[] init_vk) {
    byte[] vk = init_vk;

    entrypoint function run(byte[] proof, byte[32] a, byte[32] b, byte[32] c, byte[32] d, byte[32] e) {
        require(OpZkPrecompile(a, b, c, d, e, 5, proof, vk, 0x20));
    }
}

So the tradeoff is now clearer:

• 0-arg builtin: clean name exposure, but current syntax cannot push operands beforehand.
• Higher-arity builtin: mechanically viable today, but awkward because Groth16 arity depends on n_public_inputs.

That suggests the real design choice is probably one of:

1. add expression statements / explicit push syntax (general solution), or
2. add a tag-specific lowering surface that accepts a structured operand form and emits the canonical pushes internally.

I wanted to post the positive result too, because it shows the compiler lowering path itself is not the problem.

[trillskillz]

One more concrete narrowing result from reading the compiler:

Array arguments also won't solve this automatically.

Relevant behavior in compile.rs:

• compile_opcode_call() compiles each builtin arg expression in source order, then emits the opcode.
• compile_array_expr() lowers arrays as encoded/concatenated byte data on the stack, not as multiple stack items.

So a surface like:

OpGroth16Verify(vk, proof, publicInputs)

would still need custom lowering if publicInputs is meant to become:

• public_input_{n-1} ... public_input_0
• then n_inputs
• then proof
• then vk
• then tag/opcode

In other words, the current front-end gives us:

• 0-arg exposure: not enough
• generic array arg: also not enough by itself
• fixed higher arity: mechanically works, but awkward for variable n_public_inputs

That makes the likely viable upstream answers even narrower:

1. explicit push / expression-statement syntax, or
2. a purpose-built custom lowering helper (tag-specific / structured), not just a plain opcode builtin row.

[trillskillz]

I pushed a concrete follow-up prototype onto the PR branch:

• commit: ae065ef (Prototype Groth16 helper lowering for zk precompile)
• branch: trillskillz:feat/opzkprecompile-builtin

What it does:

• keeps OpZkPrecompile() as the minimal 0-arg builtin exposure from this PR
• adds a tag-specific helper prototype: OpGroth16Verify(verifyingKey, proofBytes, [a, b, c, ...])
• custom-lowers the third argument's array literal elements into separate public-input stack items
• then appends n_public_inputs, proofBytes, verifyingKey, and fixed Groth16 tag 0x20
• finally emits OpZkPrecompile

Why this seems interesting:

• it avoids raw push/expression-statement syntax
• it avoids a brittle OpGroth16Verify5 / OpGroth16Verify6 / ... family
• it matches the real compiler limitation we found: plain array args compile as blob data, so they only help if the compiler deliberately flattens the array-literal AST during lowering

Validation on the prototype branch:

• cargo test --manifest-path silverscript-lang/Cargo.toml --test examples_tests -- --nocapture ✅ (27/27)
• includes a new compile-only example: zk_groth16_helper.sil

I’m not claiming this is definitely the right final API, but it is now a concrete working option if the maintainers prefer a structured helper over broader explicit-push syntax.

[saefstroem]

There is no opcode called opgroth16verify. Please ensure errors are representative of the actual opcode names

[saefstroem]

There should not be such an opcode. It should be invoked via opzkprecompile and maybe we should pass args as a vector in order to ensure all of the tags are supported.