Closed ZenGround0 closed 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
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.
Paraphrasing some useful feedback from @magik6k about application as callee vs caller from POV of mining software.
We're abandoning this direction but plan to keep the branch around to document the experiment.
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.