Support smart-contract-based mapping of MinerID to IndexProviderPeerID

[bajtos]

The current Spark implementation assumes the on-chain PeerID found in Filecoin.StateMinerInfo response is the same as the IPNI index provider PeerID, see https://github.com/CheckerNetwork/FIPs/blob/frc-retrieval-checking-requirements/FRCs/frc-retrieval-checking-requirements.md#link-on-chain-minerid-and-ipni-provider-identity

Curio uses a different PeerID for on-chain state and index provider advertisements. To support Spark, Curio is maintaining the MinerID->IndexProviderPeerID mapping in a smart contract. (There is a single smart contract shared by all miners using this new mechanism.)

We need to improve Spark to support both flavours of MinerID->IndexProviderPeerID lookups.

Resources:

• Smart contract documentation: https://github.com/filecoin-project/curio/blob/main/market/ipni/spark/sol/README.md
• https://filfox.info/en/address/0x14183aD016Ddc83D638425D6328009aa390339Ce?t=3 is the final contract version
• Curio PR implementing the smart contract + Curio code updating the state: feat: spark contract filecoin-project/curio#377

Places where to implement this new mechanism:

• spark-deal-observer --> feat: add index provider library spark-deal-observer#143
• spark-checker
• spark-spot-check

Related:

• Research: how to share miner-peer-id lookup code between Spark Checker, Spot Check and spark-deal-observer #244

Open questions:

• How do we want to interact with the smart contract - are we going to use Ethers.js as we do elsewhere or implement something custom?
• If Ethers.js: how to obtain ABI.json file to initialise Ethers.js smart contract client.
• Are we okay to share the implementation using the current copy-n-paste approach or do we need to figure out how to share miner-peer-id lookup code first?
• How should we check the two flavours - one after other (which one to check first?) or in parallel?
• How can we make the RPC API call querying the smart contract state reasonably cheap in terms of Glif Compute Units spent? (Can we use the same mechanism as we use for Filecoin.StateMinerInfo queries?)
• Should we verify the signature of the mapping entry? I think we should verify, otherwise a malicious SP can delegate all Spark retrieval checks to a different SP by posting a mapping from their MinerID to a PeerID of somebody else. OTOH, this is not critical and can be moved to a follow-up task.

Tasks:

• Write a design proposal answering the questions above.
• Convert the proposal into a list of implementation (sub)tasks.
• Add the tasks to this list and implement them :)
• Set Abort Signal timeout to 60_000

Blocks CheckerNetwork/spark-deal-observer#117

[juliangruber]

Based on timing, one of @NikolasHaimerl and @pyropy is supposed to take this one

[simlecode]

We need to improve Spark to support both flavours of MinerID->IndexProviderPeerID lookups.

For DDO deals, Spark also supports obtaining peerid from StateMinerInfo? Do these two methods of obtaining peerid have priority? Is there any code implementation for this part.

[NikolasHaimerl]

We need to improve Spark to support both flavours of MinerID->IndexProviderPeerID lookups.

For DDO deals, Spark also supports obtaining peerid from StateMinerInfo? Do these two methods of obtaining peerid have priority? Is there any code implementation for this part.

I believe you can find what you are referring to here.

[juliangruber]

@simlecode at the moment, Spark only uses StateMinerInfo, so the implementation for both doesn't exist yet

It's also documented in the issue that we still need to decide how to combine the two methods:

How should we check the two flavours - one after other (which one to check first?) or in parallel?

[s0nik42]

Hello, not sure my contribution is helping, but I would like to say that we're moving more and more miners to curio and their Spark scores are dropping to 0.
Do you think we could have a first iteration around F05 and keep DDO for another iteration ?