A singleton contract maintaning upload/download URLs for each SP

[bajtos]

A follow-up for this Slack discussion..

In the Pandora Service contract implemented by #14:

• SPs can register with their owner address, PDP upload URL and piece retrieval URL.
• The contract owner can then approve/reject the SP and SP gets assigned a unique ID on approval.

I see two concerns mixed together:

• A Service contract wants to have a way which SPs it do business with. (This is the approve/reject part.)
• FS components (Synapse SDK, FilCDN, Spark Checker) need to find PDP Upload and Piece Retrieval URLs for a given SP.

I am concerned that the current approach will create a lot of friction for people building new services. When they fork & modify the Pandora contract to implement different service logic, they will then have to:

• Teach Curio & Venus how to submit PDP Upload and Piece Retrieval URLs to the new service contract
• Teach components like Synapse SDK and FilCDN how to find those URLs in the new service contract

I am proposing a different design to be implemented post-M1:

• Extract the registry mapping SPs to their URLs into a standalone smart contract.
  • This smart contract will be a singleton, similar to PDPVerifier, which is also a singleton.
  • In Curio & Venus, there will only be one smart contract where to submit upload & retrieval URLs.
  • FWIW, Curio already supports a similar smart contract - see MinerPeerIDMapping Smart Contract
• Let all components use this singleton smart contract to look up PDP Upload and Piece Retrieval URLs
  • Synapse SDK
  • FilCDN
  • Spark Checker
  • etc.
• Modify the Pandora Service contract to maintain only the registry of approved SPs.

I am arguing such a design will make it much easier for others to build & deploy their own FS Service contracts.

[aarshkshah1992]

@bajtos Extremely excited for the details. This is so mysterious.

[jennijuju]

Teach Curio & Venus how to submit PDP Upload and Piece Retrieval URLs to the new service contract

If there’s a standardized set of information that SPs need to submit, this logic can be abstracted away from the SPs themselves. SP software would be responsible for knowing what services the SP wants to participate in (via some configuration), and for interacting with the relevant service contracts accordingly.

That said, this does not introduce a fundamentally new requirement — SP software already needs to know how to interact with service contracts, whether that’s submitting messages or listening for deals. It’s similar to how token holders need to approve & stake via specific contract calls, rather than simply broadcasting, “I want to stake,” and expecting the network to do the rest.

FWIW, Curio already supports a similar smart contract — see MinerPeerIDMapping Smart Contract

If Curio already includes something similar, why not use that as a starting point? Do we really need to introduce a separate registry contract?

More broadly, I think it's challenging to design a sufficiently generic registry contract without better understanding what kinds of metadata different service creators may need from SPs, for example, rn we need a URL, some may need to know the location, some services may require one URL per client..

Rather than creating a centralized registry with rigid semantics, it might be more effective to define one or more FRCs that standardize a minimal contract interface, e.g., any service offering PDP or PoRep-based storage could expose a getPeerURL() method. Each service contract could then decide how to gather and manage this data, based on its specific needs.

This would preserve flexibility, reduce external dependencies, and encourage more composable tooling across the ecosystem.

[bajtos]

I see what you mean, @jennijuju.

How do you envision that Synapse SDK and FilCDN implement SP URL lookup from multiple registries?

Assuming a standardised interface:

• I suppose Synapse SDK has an easy job, as it can make an RPC API call for the standardized method on the user-provided service contract address. Service builder does not need any help from the Synapse maintainers to enable Synapse SDK consumers to use the new service.
• FilCDN is listening for events to maintain Cloudflare-local indexes. If each service contract has its own registry of SPs and their retrieval URLs, then FilCDN needs to listen for SP registration events from all services. To ship a new service contract, the builder needs to get in touch with FilCDN, and we must start indexing events from their new service contract.

Rather than creating a centralized registry with rigid semantics, it might be more effective to define one or more FRCs that standardize a minimal contract interface, e.g., any service offering PDP or PoRep-based storage could expose a getPeerURL() method.

In my mind:

• PDP is not usable without URLs for uploading & downloading data.
• This information should be part of the PDP infrastructure.
• The same way as there is a single PDPVerifier contract (a centralised component with rigid semantics, to paraphrase your words 😉 ), I argue there should also be a single PDPOwnerRegistry maintaining Owner->{pdpUrl, retrievalUrl} mapping.

/cc @juliangruber for visibility, we briefly discussed this in our 1-1 earlier today.

[bajtos]

I was thinking about this more during my lunch break.

I see how it can be valuable to have more than one registry, as it allows Service Providers (SPs) to advertise different URLs for different services.

For example, with the pay-per-byte-retrievals we are exploring in FilCDN, I can imagine that SPs may want to provide two different URLs - one for pay-per-byte retrievals and another for "regular" retrievals so that they can provide different service quality like download speeds.

At the same time, I still believe we need to design this in a way that will make it frictionless for builders to create new service contracts - let builders focus on the business logic (billing schemes, SLA enforcement, etc.) and allow them to ship a new service contract with zero interaction with FilOz/FilCDN/Curio teams & codebases.

I am going to open a new issue in FilCDN roadmap to keep track of what we need from our side. What would a registry tailored to FilCDN look like.

[bajtos]

FilCDN issue: filbeam/roadmap#9

I think this is a post-M2 task.

[jennijuju]

@bajtos does the sp registry resovles this?

[bajtos]

Yes! I am closing this issue as resolved.