feat: Reverse Core <-> Prover interaction #3525
Conversation
EmilLuta
left a comment
EmilLuta
left a comment
There was a problem hiding this comment.
Left a bunch of comments. I'd love to hear more about your opinion on locking batches and maybe add a few more tests?
All in all looks good, let me know what you think!
| main_pool, | ||
| commitment_mode: self.commitment_mode, | ||
| l2_chain_id: self.l2_chain_id, | ||
| let processor = RequestProcessor::new( |
There was a problem hiding this comment.
I see this implementation relies on the HTTP communication without authentication. Do we consider moving this to RPC still communication? Asking as we have 2 resources (2 DB connections, one on API, one on requester) and more exposed interfaces (gateway needs to know about URL), whilst RPC would make this communication much simpler (data handler knows about gateway and that's it -- single resource utilization as well).
There was a problem hiding this comment.
yes, but that will be implemented separetely
| general_config.insert("prover_gateway.api_url", format!("http://127.0.0.1:{port}"))?; | ||
| } | ||
|
|
||
| let prover_gateway_port = general_config |
There was a problem hiding this comment.
Not sure why this is needed (alone). Wouldn't the same be needed for URL (imagine when starting a new chain) and poll timeout?
There was a problem hiding this comment.
I'm not sure that I understand the question. This is needed, since zkstack reallocates default ports, and there might be port conflicts.
| @@ -0,0 +1,24 @@ | |||
| use axum::http::StatusCode; | |||
There was a problem hiding this comment.
Isn't this a duplicate of middleware in proof_data_handler? Couldn't we simply unify these 2?
There was a problem hiding this comment.
hmm, the same we have for proof_integration_api. I think we probably can do some macro-based general implementation for this kind of middleware.
There was a problem hiding this comment.
(But I would prefer to do this separately)
2 participants
What ❔
Before Prover Gateway was polling ProofDataHandler for new proof generation data. This PR refactors interfaces of ProofDataHandler and implements the interaction backwards - ProofDataHandler periodically submits proof generation data to the gateway.
Why ❔
These changes were done in advance to make Prover Cluster possible
Checklist
zkstack dev fmtandzkstack dev lint.