Use tx segments in delegation program #18182
Conversation
martyall
force-pushed
the
martyall/issue-18123
branch
from
583f19a to
f58eb9a
Compare
martyall
force-pushed
the
martyall/issue-18123
branch
from
6aa03a9 to
e73c974
Compare
| ( message | ||
| , read_all_proofs_for_work_single_spec single_spec ) ) | ||
| with | ||
| let module T = Transaction_snark.Make (struct |
There was a problem hiding this comment.
This is unfortunate because the uptime snark worker state has its own transaction module derived from the same global constants. Ideally they would share one, but the setup makes it harder than its worth
There was a problem hiding this comment.
I mean, just move these code into snark worker & expose an interface specific for this case will solve the issue. Like a perform_uptime that just take last segment.
There was a problem hiding this comment.
So there's still going to be semantical difference in that it'll no longer be interruptible. But the fact that we're using smaller data to construct this proof should make it less relevant.
| , Sok_message.t * Snark_work_lib.Spec.Single.Stable.Latest.t | ||
| , (Ledger_proof.t * Time.Span.t) Or_error.t ) | ||
| F.t | ||
| ; perform_partitioned : |
There was a problem hiding this comment.
Note for later: it probably make sense to move code here back into snark worker.
It seems now a uptime snark worker is just a regular snark worker, nothing fancy.
glyh
left a comment
glyh
left a comment
There was a problem hiding this comment.
I think it make sense to just eliminate this uptime_snark_worker module and move all proving related stuff on snark worker's end if that's doable.
|
The story I heard is we're aggregating data across the whole block of txns. It doesn't seems like so here? Or is it just part of the bigger plan to use last txn segment in a block? Because now it seems we're using last txn segment in a txn. |
|
For compatibility, I think it might make sense to one of:
Which route did we pick? |
I was told to use the last transaction segment for zkapp txs -- due to protocol upgrades, zkapp txs will be to large to snark entirely within the timeout window for reporting to uptime service. This is not a problem with e.g. standard payments. |
As far as I can tell, the delegation program can't tell the difference in the snark statement -- notice that the delegation verifier code is unchanged. it doesn't do anything to e.g. check the statement has a certain format |
|
Okay, after the discussion here & on slack:
|
…ormal snark worker
|
!ci-build-me |
So I looked into it and IMO you're right that it would be better to just remove this uptime snark worker module and request snarks via the normal snark worker -- I can see no good reason why they are run as separate processes with separate setup boilerplate. However that is a bigger task than what was required here, and IMO it would be cleaner to do as a followup with sign-off from the team. So for now I have just shoved all the logic in the worker module which at least avoids recreating the tx snark module |
fixes #18123