FilOzone / pdp

Smart contracts and utilities for Proof of Data Possession
Other
2 stars 2 forks source link

SPIKE: introduce SLA wrapper and put grinding checks there #47

Closed ZenGround0 closed 1 month ago

ZenGround0 commented 1 month ago

This delegates grinding fix to another contract we're calling the "SLA"

It keeps the bare PDPService contract very simple at the cost of adding another level of complexity.

ZenGround0 commented 1 month ago

@anorth I'm very curious how this lines up with your idea for PDP applications, whether you'd merge sla and recordkeeper, etc

ZenGround0 commented 1 month ago

A few things this has helped me sort out. First "SLA" here should be called application. Second there are two different approaches to SLA contracts -- wrappers using PDP Service as callee and framework where PDP Service is caller.

We need to choose one approach and stick with it rather than having two as in this experiment. We've already chosen framework since the record keeper is really just a simple application of the PDP service but we can back out of this if it ends up looking worse.

As to whether we should fix grinding in the application as in this PR vs in PDP Service, we should do it in PDP Service. All provider initiated removals will need to allow for some flexibility in when an expired root is removed from a proofset. If that flexibility is allowed to change proof set contents after a challenge is sampled it will degrade security.

Client initiated removals would be another way to avoid grinding but it is not the intention for how PDP Service is used. PDP Service is called by provider to perform actions that satisfy the application. However even if we did go back and change our intent then any reasonable client initiated removals would need to have coordination with the provider. It would be bad design if client were to call remove the epoch before a proof was due and change the necessary merkle proof inputs. Client initiated removals would end up needing a coordination mechanism with similar properties to the deferred adds and removals of the grinding solution.

ZenGround0 commented 1 month ago

Paraphrasing some useful feedback from @magik6k about application as callee vs caller from POV of mining software.

  1. The SP doesn’t need to trust the application as much with application as callee. There's a more limited set of problems you need to audit against. You know for sure that the PDPService contract is getting called when you submit a message.
  2. Its easier to have just one contract to call.
ZenGround0 commented 1 month ago

We're abandoning this direction but plan to keep the branch around to document the experiment.