Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Virtual storage #10

Open
countvajhula opened this issue Jul 11, 2023 · 0 comments
Open

Virtual storage #10

countvajhula opened this issue Jul 11, 2023 · 0 comments

Comments

@countvajhula
Copy link
Collaborator

Currently, if a block is recorded as being stored on a particular peer, the block must actually reside there.

But it could be that, at some point, the peer decides to free up some space by compressing the block that it is hosting. In this case, the original block is no longer present on their machine but they are still in a position to provide it if it is requested. It could even be that the peer decides to free up even more space on their machine by storing the compressed block on the network as a separate file following its own storage scheme, so that neither the block nor even its compressed form are present on their machine. Yet, they are still in a position to fulfill a request for the original block.

To allow the peer to fulfill the request in these scenarios, it would be necessary to decouple the actual means of storage on a peer from the store/retrieve interface, and then abstract this means of storage.

Performance and Motivation

On the face of it, this seems to entail that the performance of downloads would become worse. But if there is high latency in downloading blocks from a peer employing a byzantine means of storage, the filesystem would measure that at a higher level as some form of lower "peer quality," thus only using this peer if other, more responsive, peers, are unavailable. The specific causes for the latency need not be known to the filesystem. At the same time, this gives a lot of flexibility to peers in fulfilling their storage contract however they see fit.

Implementation

For the storage abstraction, we could define a new class called StorageProvider that provides store and get methods. The default storage provider would implement simple local storage (i.e. the current behavior). Another could be CompressedStorage, which compresses the block before storing it on disk, and decompresses it before sending it to a client. Another could be NetworkedStorage, which stores the block by storing it on the network using one of the standard storage schemes! It would then obtain it from the network in order to send it to a requesting client.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant