zkApp composability, pt 2: multiple proofs #296
Conversation
| @@ -0,0 +1,249 @@ | |||
| /** | |||
There was a problem hiding this comment.
the new example!
| @@ -657,8 +657,14 @@ class Party { | |||
| } | |||
|
|
|||
| hash() { | |||
| let fields = Types.Party.toFields(toPartyUnsafe(this)); | |||
| return Ledger.hashPartyFromFields(fields); | |||
| // these two ways of hashing are (and have to be) consistent / produce the same hash | |||
There was a problem hiding this comment.
this is what fixes the new example. the previous version was always returning variables, even outside the circuit
| // state type | ||
| Field, | ||
| // function that says how to apply an action | ||
| (state: Field, _action: Field) => { |
There was a problem hiding this comment.
Dumb question but when should action be interacted with? I see that we're not doing anything with it here but I'm wondering what its use case would be
There was a problem hiding this comment.
Nvm, just realized that actionsHash is being passed in. I guess the use would be extra information we want to pass into the reducer function to do something specific (e.g. check the hash?)
There was a problem hiding this comment.
action is a sequence event, which can potentially store information, and you'd combine that information to a state in the reducer.
example: action is a balance change, and the state is your account balance
Small PR which fixes the case of multiple independent proofs in one transaction.
This isn't composability, but a case that came up on initial testing that turned out to be broken. The PR fixes it and adds an example which combines the proofs of two smart contracts together in one transaction block
The PR also has a couple of other minor changes, to collect unrelated stuff which would deter from reviewing the bigger chunks (see next PR)