feat: peer id smart contract lookup

[NikolasHaimerl]

Smart Contract Client for IPNI Peer ID Resolution

This PR adds a new module that allows retrieving Filecoin index provider peer IDs from the on-chain smart contract. Key additions:

• Implements getIndexProviderPeerIdFromSmartContract function to retrieve peer IDs for miner IDs
• Adds comprehensive tests with mocked contract responses
• Includes error handling for invalid miner IDs and network failures
• Uses ethers.js for blockchain interaction for requests requests
• Uses human readable ABIs

This shared module will be used by other Spark components to resolve miner IDs to their corresponding IPNI peer IDs.
I tried using a regular rpc function as we have for spark-checker but I kept getting corrupt data for the Peer Id, so I defaulted back to using ethers and leave the change to rpc usage for a later point in time.
Related to
CheckerNetwork/roadmap#250
CheckerNetwork/spark-checker#118
CheckerNetwork/spark-checker#117

[juliangruber]

I tried using a regular rpc function as we have for spark-checker but I kept getting corrupt data for the Peer Id, so I defaulted back to using ethers and leave the change to rpc usage for a later point in time.

I assume the returned peer id is encoded and needs to be unpacked, rather than being corrupted. If JSON-RPC providers responded with corrupted data, we'd have a bigger issue. In any case, good to use a library then

[pyropy]

It's looking great so far 👏🏻

[bajtos]

@NikolasHaimerl How is the code in this pull request different from the implementation we have already shipped in spark-checker (via CheckerNetwork/spark-checker#117)?

I'd like to avoid second review of the code I have already approved.

[NikolasHaimerl]

@NikolasHaimerl How is the code in this pull request different from the implementation we have already shipped in spark-checker (via CheckerNetwork/spark-checker#117)?

I'd like to avoid second review of the code I have already approved.

The code is very similar to that from CheckerNetwork/spark-checker#117, the only difference is the repo and the fact that we do not use zinnia for tests.

[NikolasHaimerl]

I tried using a regular rpc function as we have for spark-checker but I kept getting corrupt data for the Peer Id, so I defaulted back to using ethers and leave the change to rpc usage for a later point in time.

I assume the returned peer id is encoded and needs to be unpacked, rather than being corrupted. If JSON-RPC providers responded with corrupted data, we'd have a bigger issue. In any case, good to use a library then

I would assume so, yes. I tried a bunch of different decoding methods including decodeFunctionResult from ethers, decodeAbiParameters from viem, TextDecoder, hexToString from viem and manually eliminating empty bytes and converting the bytes to string through but I could not get it to work. The signature was easily extractable. I moved on because I did not want to postpone the release of this library due to that challenge.

[juliangruber]

Code looks good to me, but RPC_AUTH needs to be passed by the library consumer, and RPC_URL should be changeable by the consumer.

[juliangruber]

I personally prefer to document things as they are available, so for now I would document the constants ABI and the contract address. That is the extend of the public API after merging this PR. The reasoning is that if we say we'll document last, we're likely to miss things, we're less likely to want to spend time on documenting well, and more often than not, we'll end up not documenting it at all. It's similar to saying you'll add a test suite when the project is finished.

[NikolasHaimerl]

I personally prefer to document things as they are available, so for now I would document the constants ABI and the contract address. That is the extend of the public API after merging this PR. The reasoning is that if we say we'll document last, we're likely to miss things, we're less likely to want to spend time on documenting well, and more often than not, we'll end up not documenting it at all. It's similar to saying you'll add a test suite when the project is finished.

I documented the two here: deaacf6

[juliangruber]

I believe you committed this to the wrong branch?

[bajtos]

npm ci is installing dependencies; why does it need an RPC auth token? Can we remove this env: block?

[bajtos]

npm ci is installing dependencies; why does it need an RPC auth token? Can we remove this env: block?

@NikolasHaimerl PTAL ☝🏻

[NikolasHaimerl]

Committed in 7263220

[bajtos]

Almost there!

I see two things remaining to address:

• ci.yml comment below
• missing documentation in README (did you perhaps accidentally push the commit to a different branch)?

[bajtos]

npm ci is installing dependencies; why does it need an RPC auth token? Can we remove this env: block?

@NikolasHaimerl PTAL ☝🏻

[juliangruber]

One comment + missing docs (wrong branch)

[NikolasHaimerl]

I believe you committed this to the wrong branch?

Yes, too many working branches on this library I feel. The change is in 66c0c16

[bajtos]

LGTM after you address Julian's two comments above 👏🏻

[juliangruber]

[juliangruber]

(as soon as CI passes)