PoRep Service

[wjmelements]

CC @lordshashank
This adds a PoRepService that utilizes SectorContentChanged notifications and the FIP-0112 methods.
The Service creates deals which have configuration parameters including expiration and payment rate.
When a SP seals a sector they can match up pieces with deals.
The entire value of the deal is locked up using the fixed lockup system (the sliding lockup system can't work for this).
Faults and expirations are identified by keepers who receive bounties funded by the FilecoinPayV1 service operator fee.
The SP gets paid according to uptime.
The client can try to extend the deal past the original expiry but the SP has to also extend the sector's lifetime (if they don't then it will expire).
SP payments can be withdrawn by the miner actor's owner via sudo, which can also be used to claim any future FilecoinPay incentives.

Changes

• add PoRepService, PoRepDeal, PoRepPayee, and their tests

[wjmelements]

this is currently done in the updateLockups callback but I want to optimize this so we modify the lockups only once per deal.

[wjmelements]

After the latest fixes, the happy path is working on localnet. I'll need a few more hours to repackage the scripts into something less hacky. I also want to test other paths.

[wjmelements]

I have tested the happy and faulty cases in a local devnet. That found a few issues with fvm-solidity that are now fixed.

[lordshashank]

had a superficial look into whole flow, I like the create2 usage and also incentivization of sector fault reporting. jsut pointing out few obvious things that come to my mind

• As just tracking sectors, in case we do snapdeal type of thing, sector might not have the data with which it was initially made.
• no differentiation between verified and non-vefired deals (ig fine as all deals being made currently are verified only)
• I just don't see any utility of filecoin pay in the whole flow, if its not streaming rail, i think just do simple locking and paying, lot less complexity and everyone's life would be lot easier.
• couldn't we have integrated the same sp registry we have for fwss in here as well somehow? or is there a plan for that i am not seeing? i was under impression we want to make it generalizable for all filecoin related services.

[wjmelements]

src/PoRep* now has 100% test coverage. I measured that using a MockFilecoinPay to avoid stack too deep, allowing it to build without --via-ir (necessary for forge coverage to work).
lcov.info.gz

[wjmelements]

couldn't we have integrated the same sp registry we have for fwss in here as well somehow

No, this is deliberately an uncurated service. Perhaps an entry in the registry can associate with a Miner actor somehow, and that could surface provider info.

in case we do snapdeal type of thing, sector might not have the data with which it was initially made.

Yes that's true. We'd need that functionality to come with a way to detect if the piece content of a sector has changed; then we could utilize the bounty system to detect missing pieces. An opt-in notification like SectorContentChanged would not be sufficient since the miner could simply not notify the Service.

[BigLep]

@wjmelements : what are the next steps here? Is this intended to land soon, or is this just showing that we can add a PoRep service when we want to?

(I also see one failing check.)

[wjmelements]

I'm inclined to remove this file. I introduced it mainly to check for solc bytecode improvements and regressions. It has been a pain to get it to be deterministic and I suspect it will cause other people trouble in the future, and more trouble than it is worth.

[jennijuju]

couldn't we have integrated the same sp registry we have for fwss in here as well somehow? or is there a plan for that i am not seeing? i was under impression we want to make it generalizable for all filecoin related services.

@lordshashank is correct here. We should allow PoRep SPs to register their PoRep service in the same SP registry, as an offering.

[jennijuju]

what are insurance and keepers?

[wjmelements]

what are insurance and keepers?

"Insurance" is the fund paid to keepers to report faults and early sector termination. Keeper is a standard name for third parties who are paid to do maintenance for a protocol, but anyone can perform this function, including the client. In the case the client collects it, it functions like insurance, but the name is tentative.

[wjmelements]

Perhaps an entry in the registry can associate with a Miner actor somehow, and that could surface provider info.

We should allow PoRep SPs to register their PoRep service in the same SP registry, as an offering.

We could also use getProviderPayee instead of PoRepPayee if the provider is registered. But I do not know a way besides Miner.GetOwner to validate the relationship between a miner's actor ID and the providerId. We would have to make sure that a random user cannot be made the payee for the miner.

We'd probably want to bind the miner actor ID to the ServiceProviderInfo to allow payee lookup across all products. On the other hand, they may want to use separate miners for separate products, but they should register separate ServiceProviders in that case. Another reason to put it into the product rather than the provider is that it is product-specific information.

My current solution creates a singleton PoRepPayee account bound to the miner's actor ID that can be fully managed by the miner's owner. The benefit of this is that the miner's ownership can change and the funds will then be accessible by the new owner. They can register this account as their payee for other services and receive all of their funds in one place.

Eastore's solution is that the service operator is trusted to register the payee for each service provider.

I discuss this problem here: Eastore-project/ddo-client#7

But I think the time to build the product registration will be when we know what it needs to contain.

[lordshashank]

You can probably use the https://github.com/filecoin-project/filecoin-solidity/blob/c72ec4bf8213f38ca5cd6f553abff5cab0709488/contracts/v0.8/AccountAPI.sol#L41 function to verify signature from a miner actor, i used to do this for verification at few places, so that any f4 eoa address can prove ownership of miner actor during registration, etc.