Is it safe to just use the type of public input for the type of public output? What's the difference?
#I noticed that SelfProof now takes 2 type arguments. What should be the type of public output?
obtuse ivy
smoky lintel
Afaiu this is now a feature coming with the new input-output syntax. So basically you can now create part of your public input by returning data from the zkprogram method. I find i really useful when creating this from-to state-transition pattern
But you can just leave it undefined, then it will behave pretty much like before
obtuse ivy
Can you share an example of how it's useful? I'm not sure how to think about it coming from publicInput1 -> transition -> publicInput2. Now it's publicInput -> transition -> publicOutput? But that output can have a different type than the input?
north hill
It now feels more like a real program, that also returns your result! Previously, you had to do some mind bending tricks when you wanted to prove state transitions, now you just call a function that returns your result, with the benefit of a tiny proof attached to it
obtuse ivy
So I have this proof method: https://github.com/trumpet-zk-ignite-1/Contracts/blob/060a792da1154c42a78480c023c3c0ac24ca0709/src/phase/PhaseProof.ts#L19
The old way is my public input is a PhaseState, and each method's first arguments is newState: PhaseState. In the new way, I can just return newState? But actually I want to return a new proof where newState is the public input right?
So do I need to rewrite anything in my program? Or the new return feature is just an optional addition?
patent canopy
the new return feature is an optional addition. to stay in the old world:
- leave
publicOutputundefined in theZkProgramdeclaration. That is, change nothing - use
Proof<PublicInput, undefined>as your type
You wouldn't use the same type for input and output, but rather you'd leave one of them undefined