<aside> ⚠️ This document is shared outside of Scroll. Please be mindful when making live edits.

</aside>

<aside> 🚨 Note: Document has not been reviewed for accuracy after the Curie upgrade changes.

</aside>

Necessary Info

• API interface specs for the Coordinator
  • coordinator route
  • prover client
  • Peter: ProveChunk and ProveBatch here would be the best starting point.
  • Can we get proper specs here?
• The data of a sample prover job (chunk and/or aggregation) that they can use to mock coordinator behavior / interaction with a prover
  • See section below.
• An endpoint for allowing the prover to generate traces
  • Provers need access to scroll_getBlockTraceByNumberOrHash
  • Scroll Sepolia RPC Endpoint (using latest 4844 spec):
    • https://purple-cool-grass.scroll-testnet.quiknode.pro/7c71f2df0436f31b249b4158a1ef4dc1ddfe5248/
  • Example CURL request:

curl --location '<https://purple-cool-grass.scroll-testnet.quiknode.pro/7c71f2df0436f31b249b4158a1ef4dc1ddfe5248/>' \\
--header 'Content-Type: application/json' \\
--data '{
	"jsonrpc":"2.0",
	"method":"scroll_getBlockTraceByNumberOrHash",
	"params":[
		"0x1b4"
	],
	"id":1
}'

Design

Rough overview (see Miro board)

The new service will sit between our current “Coordinator” and “Provers” roles. The service translates the Coordinator’s “Pull” model of work to an adaptable format (ie being able to push to serverless prover platforms).

The Coordinator will communicate with the Prover Aggregation service just as if it were a set of on-site provers. Ideally, we see few to no changes in the Coordinator codebase.

Existing provers, if selected for proof generation, will communicate with this layer (via a plug-in) as though it were the coordinator. Ideally, there are few to no changes for existing provers.

The “Prover Aggregator” will be responsible for determining what external source to assign work to and handling the interaction before returning completed proofs to the Coordinator.

The “Prover Aggregator” will be responsible for delegating which prover service will do the work, and relaying results back to the coordinator. This might be local provers or external platforms. Beyond handling this interaction, it will also generate and provide everything a proof service needs (i.e., producing and transmitting traces).

The “Prover Aggregator” will use a plug-in system so that any platform-specific logic which is external to the stack (ie API keys, payment, auction mechanism, individual prover selection) can be isolated and built out by individual teams.

Scroll Stack chains will configure which Proof Providers they want to enable, along with basic logic on how to allocate work to these providers.

This mechanism also allows chains to run their own provers or work with private proof generation services, while falling back to open markets in times of high demand.

Work Allocation

How will the “Prover Aggregator” determine which service to use?

• The initial version should be configured as “Primary” and “Backup” plugins.
  • Default to one “plugin” unless it is unresponsive or at capacity.
  • More advanced prioritization / scheduling mechanisms could be too complicated for stack users.