Upstream silverscript PR: expose OpZkPrecompile builtin

[trillskillz]

Summary

OpenSilver now has a validated local patch lane for the pinned kaspanet/silverscript checkout:

• patch file: patches/silverscript-opzkprecompile.patch
• apply script: scripts/apply-silverscript-opzkprecompile-patch.sh
• npm entrypoint: npm run patch:silverc:zk

That script:

1. bootstraps the pinned upstream compiler checkout
2. applies the RFC patch for OpZkPrecompile
3. rebuilds silverc
4. smoke-tests a minimal .sil contract containing require(OpZkPrecompile())

So the patch path is no longer just design text — it works against the pinned upstream snapshot used by OpenSilver.

Next external step

Turn that validated local patch into the real upstream contribution:

• target repo: kaspanet/silverscript
• recommended PR title: Expose OpZkPrecompile builtin to SilverScript front-end
• reviewers to tag: @OriNewman, @saefstroem
• design reference: references/silverscript-rfc-opzkprecompile.md

Scope of the upstream PR

• add the builtin row in silverscript-lang/src/compiler/compile.rs
• add the debug value type in silverscript-lang/src/compiler/debug_value_types.rs
• add the stdlib declaration/docs in silverscript-lang/std/builtins.sil

Why this matters

This is the clean unblock for OpenSilver Phase 5. Until it merges, the ZK patterns remain design-only upstream, even though OpenSilver now has a local experimental patch path.

[trillskillz]

Validated the local patch lane against the pinned upstream snapshot.

What landed in-repo:

• patches/silverscript-opzkprecompile.patch
• scripts/apply-silverscript-opzkprecompile-patch.sh
• npm run patch:silverc:zk

Validation result:

• patch applied cleanly to upstream silverscript at pinned commit 2c46231
• rebuilt silverc
• smoke-tested a minimal .sil contract containing require(OpZkPrecompile())

So the upstream PR is now de-risked: the patch works on the exact snapshot OpenSilver is pinned to, and we have a reproducible local apply/build/smoke-test path.

[trillskillz]

Follow-up: OpenSilver also landed the first SDK-side safety rail for Phase 5.

New helper:

• buildGroth16WitnessPlan() in sdk/src/index.ts

What it does:

• returns the canonical Groth16 operand push order for OpZkPrecompile
• exposes the resulting invocation stack view (tag, verifyingKey, proof, nPublicInputs, public inputs)
• clones caller buffers defensively
• validates explicit expectedPublicInputs when supplied

This does not replace the upstream silverscript PR, but it means the OpenSilver side now has both:

1. a reproducible local compiler patch lane
2. a stack-order-safe SDK helper

So the next meaningful external step is still the upstream PR itself.

[trillskillz]

Another small but useful follow-up landed:

• the local patch lane now compiles a tracked repo contract instead of an inline temp file:
  • contracts/zk/opzkprecompile-smoke.sil
• scripts/apply-silverscript-opzkprecompile-patch.sh now hard-resets/cleans the pinned upstream checkout before applying the patch, so reruns are idempotent instead of failing on an already-modified worktree.

That keeps the local Phase-5 compiler smoke path reproducible and source-controlled.

[trillskillz]

The upstream PR is now open:

• Expose OpZkPrecompile builtin to SilverScript front-end kaspanet/silverscript#125 — Expose OpZkPrecompile builtin to SilverScript front-end
  • Expose OpZkPrecompile builtin to SilverScript front-end kaspanet/silverscript#125

What it includes:

• compiler builtin dispatch row
• debug value type row
• stdlib declaration/docs
• minimal compile test (zk_minimal.sil) in the upstream examples suite

Upstream verification run used before opening the PR:

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

[trillskillz]

New finding from local prototyping:

The upstream PR kaspanet/silverscript#125 is necessary but may not be sufficient for real Phase-5 contract authoring.

Why:

• patched silverc accepts the bare builtin name (require(OpZkPrecompile()))
• but current SilverScript syntax rejects raw expression statements meant to push verifier operands before the opcode
• example rejected by the parser:

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

So the real unblock may require either:

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

I commented this on the upstream PR as well so review can address it before we treat #125 as the full solution.

[trillskillz]

Another concrete prototyping result:

• the blocker is not argument lowering order
• compile_opcode_call() pushes builtin args in source order, then emits the opcode
• I locally changed the builtin arity to 9 and successfully compiled a fixed-5-input Groth16-style call

Working prototype shape:

require(OpZkPrecompile(a, b, c, d, e, 5, proof, vk, 0x20));

So the refined conclusion is:

• 0-arg builtin is insufficient because the language can't push operands ahead of time
• higher-arity builtin is mechanically viable, but Groth16 arity varies with n_public_inputs

That leaves two realistic upstream answers:

1. expression statements / explicit push syntax
2. a structured/tag-specific lowering surface for ZK precompiles

I posted the same result on upstream PR #125.

[trillskillz]

Additional compiler finding:

Array arguments are serialized/concatenated byte data, not multiple stack items.

So even a surface like:

OpGroth16Verify(vk, proof, publicInputs)

would still need custom lowering if publicInputs is supposed to become separate verifier stack operands.

That narrows the realistic fix further:

• 0-arg builtin: insufficient
• plain array arg: also insufficient on its own
• fixed higher arity: works mechanically, but awkward for variable n_public_inputs

Most likely real answers remain:

1. explicit push syntax
2. purpose-built structured lowering helper

[trillskillz]

Follow-up prototype pushed upstream:

• upstream branch commit: ae065ef
• title: Prototype Groth16 helper lowering for zk precompile

Key result:

• a structured helper prototype does work without raw push syntax
• shape: OpGroth16Verify(verifyingKey, proofBytes, [a, b, c, ...])
• implementation custom-flattens the array literal into separate verifier operands, then appends n_public_inputs, proofBytes, verifyingKey, and Groth16 tag 0x20 before emitting OpZkPrecompile

Validation:

• upstream cargo test --manifest-path silverscript-lang/Cargo.toml --test examples_tests -- --nocapture ✅ (27/27)

This is now the strongest concrete upstream candidate unless maintainers prefer broader explicit-push syntax instead.