paritytech / paritytech/web3-storage
Avoid cheating (never storing anything) providers
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 13
- Forks
- 3
- Avg merge
- 2d 2h
- Merged PRs (30d)
- 33
Description
A client can defend against bad providers, by not extending and if service was really terrible also by burn. But this leaves a real gap, that I can see happening in practice: A client sets up an agreement with a provider and the provider does nothing ever - it does not even have any storage. Now the client can of course burn, but not all might and given that the provider had literally no storage, it had no cost, so any client not burning is already profit.
There are of course ways to mitigate this, but I would try to keep it simple, if we can:
- Provider registration should not be terribly cheap - a cheater will need to keep creating providers to sustain profit with cheating. If creating a provider has high enough cost then this already is a great mitigation, especially when combined with (2).
- UIs should steer users away from providers with no reputation, they might still pick one if cheap enough: Providers will need cheap agreements to ramp up their reputation. So you can have a bargain with higher risk of losing your money. Best case: Profit is so low that you need a few to break even with registration cost. A single burn along the way and you never became profitable, before turning "radio-active".
TL;DR: I think this issue is solvable via the UI layer mostly + reasonable registration costs. Providers need to ramp up some reputation to become profitable, which then also serves as a proof of work. A built up reputation costs some money, which makes it valuable. Here there might be a real gap. A cheater can of course try to build up a reputation, by being their own client. This will still cost them tx fees, but that's too little, we definitely also need to ensure time passing. A pure number of extended agreements is not enough, if agreements can have the length of (extreme case) only seconds or hours. It becomes meaningful if agreements lasts weeks/months ... as then the reputation needs to be built up over a longer time-span, which at least serves as a rate limiter of such attempts - especially if combined with high stake, which makes it very unattractive. Building up a reputation over weeks/months, paying registration fees and then burn that reputation on a handful of paying clients is not a good deal: UI should encourage users to burn in case the provider does not sign commitments, to protect other users.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files, tests, or entry points are identified in the issue. Begin by locating the provider-registration, agreement-duration, reputation, and UI flows, then define how registration cost, minimum agreement durations, reputation guidance, and burn recommendations should prevent non-storing providers.
Written by the indexing model from the issue text.
Assessment
- Domain
- blockchain, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100