Conversation
141c5c6 to
532b237
Compare
|
Im linking to the empty FWSS-terminate section from within settlements. I'll now submit a PR to fill that out. |
are we still comfortable with that approach given the pain we've had with IAmBored? it doesn't need to be eager but is there a world in which a Curio node never gets bored and never settles? |
|
|
||
| The settle task is scheduled twice a day through the IAmBored entrypoint. Upon waking up the settle task queries the `eth_keys` table for the first keys it finds with role == `pdp`. The task then queries the provider registry to learn the payee address. `Settle` task then delegates to the `filecoinpayment` library method `SettleLockupPeriod` to attempt to settle all rails in need of settlement that are paying out to the payee address using the FWSS contract as the rail's operator contract. | ||
|
|
||
| `SettleLockupPeriod` uses eth call methods on the filecoin-pay contract to lookup all rails operator and payee. The method's purpose is to periodically settle payment rails paying out to the payee address. To achieve this gas and local-resource efficiently the method schedules settlement as lazily as safely possible. It settles rails that have any possibility of client default between this run of the task and the next expected run in 12 hours. To determine this condition each rail's `settledUpTo` and `lockupPeriod` value is inspected. When a rail has not been settled for over one `lockupPeriod` the client can be in default. `SettleLockupPeriod` settles all rails that are within one day of meeting this condition. Additionally all termianted rails in the process of finishing out their last `lockupPeriod` of life are marked for settlement. For more about the details of termination and lockup periods and how this exactly determines default risk see the filecoin-pay [documentation](https://github.com/FilOzone/filecoin-pay/blob/main/README.md#per-rail-lockup-the-guarantee-mechanism). |
There was a problem hiding this comment.
settles rails that have any possibility of client default between this run of the task and the next expected run in 12 hours
this is wrong now, since we try and settle when we haven't settled for more than 7 days @ #1089
The logic in SettleLockupPeriod is kind of hard to describe and doesn't fit neatly in here, but here's my go:
On a 12 hour schedule, SettleLockupPeriod looks for rails that it should attempt to settle belonging to the service provider (payee) that are denominated in USDFC. Rails that are candidates for settlement include:
- Rails that have been terminated, passed their lockup period by no more than 7 days, and is not yet successfully settled
- Rails that have a lockup period less than one day (special case: settle whenever
SettleLockupPeriodis run) - Rails that have not been settled since
min(lockupPeriod - 1 day, 7 days). In this scheme, we always attempt to settle a rail once every 7 days, and for rails that have a lockup period of less than 7 days we settle them more frequently, but 1 day shorter than their lockup period so as to avoid getting to close to the end of the lockup period.
There was a problem hiding this comment.
Also this line also still says "lookup all rails operator and payee", it's more like: "queries all rails by payee and token, then filters to those matching the FWSS operator."
There was a problem hiding this comment.
termianted -> terminated (if you're going to keep your original and adjust it)
|
Should we target these changes towards the |
Yes, this is very much an issue right now. Upcoming harmony changes should fix this and move towards slightly different architecture. IAmBored was never meant to be this. We got lazy and abused it. |
I would merge in pdpv0 for now. Plan is to move all docs in one go. Once all docs PR are finished we can easily port over without accidentally leaving any content behind. I will also be restructuring Curio docs after that to get PDP more prominent space within the docs. |
No description provided.