ZK SDK Moves Toward Low-Level Proof Builders

The ZK SDK discussion became much sharper than the earlier "API shape" thread. Sutton said the most important part of the SDK is the implementation of commit_to_groth16, while finalize_with_proof is only partly helpful because it maps from the Risc0 receipt object. His proposed direction was that the low-level SDK should be oriented around script builders and should not assume it owns the full end-to-end script flow. ^[1]

That matters for SilverScript. Sutton described SilverScript as a main client that needs less stack cleverness but can use help mapping Risc0 objects, so a contract like require(risc0.groth16.verify(imageId, journalHash, proof)); can compile into a commit_to_groth16 call while signature-preparing software separately turns the receipt and journal into pushed proof data. ^[1]

He then wrote a concrete low-level API sketch. For Groth16, push_r0_groth16_witness would consume a receipt and prepare the stack shape, while append_r0_groth16_verifier would append the verifier fragment expecting journal_hash and compressed_proof on stack. For succinct receipts, push_r0_succinct_witness and append_r0_succinct_verifier would follow the same pattern around journal, claim data, control data, and seal. ^[2]

The main disagreement was journal-hash binding. saefstroem argued that users sometimes need to unlock only for a specific journal hash, and that this should be available at the public API level. Sutton's counter was that a fixed journal is a one-time proof covenant, so a covenant writer can push the constant journal hash before the verifier fragment. ^{[3] [4] [5] [6]}

Max143672 pushed the same direction from the low-level side. He argued the SDK should prefer general cases over specific ones, that journal hash can be produced by runtime calculation or passed from redeem script / sigscript arguments, and that higher-level helpers can be built on top once the low-level blocks exist. ^{[7] [8] [9] [10] [11] [12]}

IzioDev proposed the compromise: accept lower-level manipulation only for now, and demonstrate fixed or dynamic argument passing in examples until the SDK has enough maturity to justify a higher-level surface. Sutton later added that the receipt-to-proof-byte mapping should probably live in a separate function, because it is often called by the user building the transaction and then pushed into the signature script as pure data. ^{[13] [14]}

The thread ended with a smaller but concrete RPC interface proposal: Max143672 proposed using bytes instead of strings for block hashes and hashes in every new RPC endpoint, and IzioDev said this better aligns with wRPC. ^{[15] [16]}

All sources link to public messages in the Kaspa Core R&D (public) Telegram channel.