In relation to https://github.com/webb-tools/gadget/pull/190#pullrequestreview-2202443032, we want tasks/jobs to have access to a Context that allows the developer access to networking and other first-class primitives that may need to be specifically engineering for a target environment (TEE/SGX, WASM, crypto, zk, etc.)
When considering adding networking and other things to the job, it's important to remember that we will want to benchmark this. So for networking, when we test a job, we must also benchmark the bandwidth consumed by tests/executions. This will be useful for metrics reporting, for understanding node specs and networking specs amongst other things.
If we are to support general zero-knowledge proofs of correct job execution (i.e. verifiable computations as a service) we may also want to consider how the Context could support such tools. Integrations with sp1 and leveraging that API to program a task using their API would allow automated compilation into the proper zk pipeline. Try to keep our scope wide enough but focused enough to cover our ideas and get something tangible implemented.
This already supported by the #[job] macro, just create you Context type and add it as the first arg to your job/task. The generated handler will have that so you can pass it to the job.
Overview
In relation to https://github.com/webb-tools/gadget/pull/190#pullrequestreview-2202443032, we want tasks/jobs to have access to a
Context
that allows the developer access to networking and other first-class primitives that may need to be specifically engineering for a target environment (TEE/SGX, WASM, crypto, zk, etc.)When considering adding networking and other things to the job, it's important to remember that we will want to benchmark this. So for networking, when we test a job, we must also benchmark the bandwidth consumed by tests/executions. This will be useful for metrics reporting, for understanding node specs and networking specs amongst other things.
If we are to support general zero-knowledge proofs of correct job execution (i.e. verifiable computations as a service) we may also want to consider how the
Context
could support such tools. Integrations with sp1 and leveraging that API to program a task using their API would allow automated compilation into the proper zk pipeline. Try to keep our scope wide enough but focused enough to cover our ideas and get something tangible implemented.