Currently, the only "input" workers get for circuit compilation is the source code itself.
For advances usecases, for example, sideloading runtime methods or provably deploying the bridging contract from the settlement contract, dynamic inputs are needed that need to be baked into the circuits at compile time.
These values typically are collected by the sequencer and require a large amount of computation to be computed. Therefore, workers should be able to receive those arguments at startup from the sequencer.
Protocol
To solve this, there will be a message queue that reserves a dedicated queue for workers to register themselves to the sequencer and receive arguments in the process. For that, as soon as the sequencer is up and running, the sequencer dispatches a task with the arguments to that queue. As soon as any worker gets spun up, they listen for and consume that task where the arguments are sent as payload. After reading that task, the worker "completes" the task - i.e. sends a response back to the message queue, which the sequencer receives. When the sequencer sees that acknowledgement, it dispatches the same task again for any subsequently spun-up worker to consume and the protocol to start again
Currently, the only "input" workers get for circuit compilation is the source code itself. For advances usecases, for example, sideloading runtime methods or provably deploying the bridging contract from the settlement contract, dynamic inputs are needed that need to be baked into the circuits at compile time.
These values typically are collected by the sequencer and require a large amount of computation to be computed. Therefore, workers should be able to receive those arguments at startup from the sequencer.
Protocol
To solve this, there will be a message queue that reserves a dedicated queue for workers to register themselves to the sequencer and receive arguments in the process. For that, as soon as the sequencer is up and running, the sequencer dispatches a task with the arguments to that queue. As soon as any worker gets spun up, they listen for and consume that task where the arguments are sent as payload. After reading that task, the worker "completes" the task - i.e. sends a response back to the message queue, which the sequencer receives. When the sequencer sees that acknowledgement, it dispatches the same task again for any subsequently spun-up worker to consume and the protocol to start again