<aside> 💡 This is an working doc where lotus, fvm and boost team share early what their thoughts on SP frontrunning look like and how they can be solved. It is subjective to change according to discoveries and conversations. Naming here is especially subject to change.
This is also motivation for the development of the v1.0 standard.
</aside>
Based on the network dynamics observed in the NFT.storage launch on 03/14/23, a core known issue has re-emerged.
We already see a lot of wasted bandwidth on both the client and SP side as many SPs attempt downloading data, but end up not successfully getting the deal since another SP already claimed and published their deal.
Key components of the SP election process:
ClientContractDeployed
— emitted when the client contract is deployed on mainnetsubscribe()
— called by the SP when they want to get added to the CC SP queueunsubscribe()
— called by CC admin if they want to remove an SP from the CC SP queue
getSPOrdering(id)
— view
function that any SP can call to determine the order of the SPs for the given proposal idKey flow of the SP election process:
ClientContractDeployed
)subscribe()
for a CC they are interesting in participating inDealProposalCreate
event gets emitted, with a unique proposal id x
DealProposalCreate
event gets submitted.getSPOrdering(id)
in order to determine when/if they are chosen to take the deal for a given proposal ideth_call
for getDealProposal(id)
.
x
], the next SP in getSPOrdering()
gets chosen to receive x
.