-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
idea: HDP cli as server optional #40
Labels
P-low
Low priority, not for near future
Comments
How about going for smth simpler like a file |
Maybe before going for caching i would check how fast we can get by having a locally synced node. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Context
As for right now, as thread stop with one request call to cli,
InMemoryProvider
is useless. There is not much of possibility for provide proof in memory that requested in this short amont of seconds and get reset.Idea
What if make cli optionally able to spawn dedicated server in localhost and get requests with same thread — that way could leverage caching & or later persistent db and it fetching speed would be hugely faster
Ideally we could have a command to run server
and it start in
localhost::8080
for dedicated server.And for use
run
command that we originally have, it would be calling api in this caseConsideration
We have HDP-Server which export api interface. This might make conflict on responsibility.
-> another thought on this is, we could split HDP-Server for business purpose / and server on top of HDP cli for open-source purpose, as everyone could run and spawn HDP full logic on local
But If want to delicate this Caching logic to Server, we should implement logic around HDP Runner. Which also mean need to save result of proof to DB or Inmemory.
I believe work load around implement this in either HDP cli and HDP-Server would be not much difference, but As HDP cli takes on fetching proof, would like approach of make
Provider
support Fetching and also Caching so that it can deliver robust speedConclusion
Adding server on top of HDP cli doesn't mean just adding interface. I belive it could make sense to have this as HDP Core that support 1) cli for dev purpose 2) server for run the HDP flow 3) Have dedicated DB and Providers to optimize fetching 4) Connected to many backend as options for zkVMs
The text was updated successfully, but these errors were encountered: