Updates to the API of the Vault contract as worked on in codex-storage/codex-contracts-eth#220
Most important changes:
- token transfers are much more restricted in the vault, improving its safety
- when a storage request fails, only the providers at fault are punished, the rest are not
- when a storage request fails, the client is only reimbursed for the remaining time in the contract
- no longer possible for the marketplace to request one final storage proof before allowing withdrawal
- repair reward is temporarily stored with the client's funds while slot is free, and not yet filled; this could lead to client withdrawing repair rewards when slots are free when the request ends
* Quick and dirty analysis on viability of codex side chain
* Evaluation of existing side chains
Fixed errors in network cost calculation
* add comment about sponsoring validators for bootstrapping
Co-Authored-By: Eric Mastro <eric.mastro@gmail.com>
---------
Co-authored-by: Eric Mastro <eric.mastro@gmail.com>
* Initial commit of proposals #1 and #2
* proposal #1 is more fleshed out
* Update slot reservations proposal using mark's description and image
* rename document
* more updates
* Add simplified version of slot reservations after discussion with dmitriy
* add fourth slot reservations proposal, removing the other 3 (2 documents)
* PR comments
- hosts => SPs
- describe F(t_i), and h better
- add additional description of why fill reward no longer needed
* add in balasz's expanding window calculations document
---------
Co-authored-by: Mark <mark@spanbroek.net>
Co-authored-by: Balazs <bkomuves@gmail.com>
* Change request queue to slot queue
The request queue design was overly complicated as there was additional logic required to track one item with multiple slot indices. Instead, each item in the queue could be represented by a slot, and each time a request for storage is received, all slots for the request can be expanded and added to the queue.
* update note about resumption of queue processing
1. Add repair case — when a slot is freed in a contract
2. Clarify re-processing of requests
3. Format the document in sectional manner using Title, Heading 1, Heading 2
4. Organise the Request Queue design into sections
