You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 providesstore
andget
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.The text was updated successfully, but these errors were encountered: