NicolaAuthors: Nicola, Anca
Motivation
In an ideal world, an SP is a thin SP (See The Fat vs Thin SP thesis).
The Thin SP delegates some of their activities to external parties in order to let a competition of service providers optimize and lower the costs. For example, sealing and proving could be delegated to external Sealing-as-a-Service and SNARK provers that have better streamlined pipelines.
However, currently the protocol does not have these concepts natively, hence it does not allow for trustless delegation of sealing and proving.
Why is trustless delegation important?
- Processes can be automated, hence could be cheaper
- SPs and service providers do not need to interact, trust each other or interact in a more traditional way
What could we do?
We should explicitely separate the SP ID (often referred to as MinerID) from the SealerID and the ProverID.
Proposal
Sealer ID
- Allow for SealerIDs to be registered
- Change the MinerID used for the sealing process to be the SealerID
- Change the MinerActor to allow for any sector from any SealerID to be added into the protocol (if not used)
Prover ID
- Allow for ProverIDs to be registered
- Allow for any prover to submit valid ProveCommit/WindowPoSt on behalf of their users
- This requires changing the WindowPoSt and ProveCommit message to add a signature of the SP with their worker key on the inputs that WindowPoSt and ProveCommit messages they are approving
- Change the PoRep proof to be uniquely attributable to a ProverID (this is not needed if the sealer ID is the same as the prover ID). This can be done with a new circuit, or by using the existing circuits but with a slightly bigger proofs.
Make SNARK proofs uniquely attributable
It is important that SNARK proofs generated by a prover cannot be stolen from other provers (or the SP themselves) from the mempool. For example, consider a smart contract that rewards the first prover to submit the proof, we want to make sure that the prover who does the work gets the reward.
Although the current proofs are stealable (not uniquely attributable), there is a simple change that we can do to make the existing proofs attributable.
Design rationale
The circuit must have as a public witness the ProverID and this must be hashed inside of the circuit.
Solutions
- If Sealer ID = ProverID, then this will be trivially already working (since the MinerID can be substituted by the SealerID, which is the same as the ProverID).
- If Sealer ID ≠ ProverID, then we must make sure that the Prover ID is a public input and hashed inside of the circuit. This can be done in two ways:
- (ideal, not compatible with existing circuits ) Writing a new circuit that explicitely takes the ProverID as input (requires a new setup!)
- Reusing one of the merkle-tree verification as “hash function” for the Prover ID. In other words, we use one of the challenge public inputs - note that this is only possible for WindowPoSt today
- SnarkPacking proofs together with an extra proof that checks only prover ID (very small circuit needed, it may even not be succinct) - requires some modifications to SnarkPack to aggregate different relations