When dealing with provers we need to be able to persist state of proving requests in case of network failure or hardware restart or cancellations.
In particular for Bonsai, without storing state, we would be unable to know how many tasks are in the queue, risking waiting in vain if there were none, or overloading the queue by mistake.
Usage
The DB introduced in this PR should be used either in front of Raiko, from taiko-geth or taiko-reth. Or after raiko. It can be either integrated in an existing product or as a microservice, for example as a daemon or a server.
Note
This PR currently has no doc as I need to leave it 95% finished due to personal reasons.
For @petarvujovic98, as discussed please review the error model so that it fits Raiko with anyhow, thiserror, ....
I might not be able to update it for several days so feel free to take over.
API
For now this provides
A way to enqueue a new task
A way to update the status(es) of an existing task, including caching a proof and changing proof providers.
A way to retrieve a cached proof
A way to get a task status. This returns a vector (provider, status, timestamp) as a task might be in network failure say in Bonsai, and we switch to local proving and it's in-progress.
This will need a way to clear the GuestInput/Payload with "older than Duration" parameter, default 18 days (EIP-4844 blobs expiry) as those are several megabytes.
Overview
When dealing with provers we need to be able to persist state of proving requests in case of network failure or hardware restart or cancellations.
In particular for Bonsai, without storing state, we would be unable to know how many tasks are in the queue, risking waiting in vain if there were none, or overloading the queue by mistake.
Usage
The DB introduced in this PR should be used either in front of Raiko, from taiko-geth or taiko-reth. Or after raiko. It can be either integrated in an existing product or as a microservice, for example as a daemon or a server.
Note
This PR currently has no doc as I need to leave it 95% finished due to personal reasons.
For @petarvujovic98, as discussed please review the error model so that it fits Raiko with anyhow, thiserror, ....
I might not be able to update it for several days so feel free to take over.
API
For now this provides
This will need a way to clear the GuestInput/Payload with "older than Duration" parameter, default 18 days (EIP-4844 blobs expiry) as those are several megabytes.