Byzantine Fault Tolerant Cooperative Caching

1. Byzantine Fault Tolerant Cooperative Caching Raluca Ada Popa, James Cowling, Barbara Liskov Summer UROP CSAIL, MIT The 3rd CSAIL Student Workshop

2. Outline • Introduction • Motivation • System Description • Discussion • Conclusions The 3rd CSAIL Student Workshop

3. Introduction • Cooperative caching: multiple peers coordinate their caches • Efficiency • Scalability • Byzantine client: any client that does not behave properly Our contribution is to add Byzantine fault tolerance to cooperative caching The 3rd CSAIL Student Workshop

4. Motivation • Cooperative caching is useless with Byzantine clients • Clients can provide false data • Our system is useful for a distributed safe storage system The 3rd CSAIL Student Workshop

5. System Setting • Many clients request/modify pages • Some are Byzantine • A storage server • Runs BFT • Clients commit transactions at the server • Clients implement cooperative caching Need efficient Byzantine fault tolerant cooperative caching on the peer side The 3rd CSAIL Student Workshop

6. System Overview • Optimistic approach • Few Byzantine clients in the common case • Reputation system for efficiency • Exploit locality • Organize peers in locality regions The 3rd CSAIL Student Workshop

7. Optimistic Approach • Assumes speculatively that clients are non-Byzantine • Upon commit, the server checks if data used was up-to-date • Rolls back if not • Check is based on hashes • Reputation system reduces the number of aborts The 3rd CSAIL Student Workshop

8. Locality • Split peers in locality regions based on their coordinates (eg. Vivaldi) • Look up a page in own locality region first • Rationale • Common case: hot pages are in locality region • Fast fetch of data Locality Region Clients The 3rd CSAIL Student Workshop

9. Page Lookup • Consistent hashing function in each locality region: • Peer with metadata for Page ID knows which peers store the page • Provides replication Peer with metadata for page ID Page ID The 3rd CSAIL Student Workshop

10. Maintaining Metadata • Each client informs the appropriate metadata peer when fetching from the server, updating, or removing a page • Metadata peers communicate • Server sends periodic invalidation streams (e.g. peer membership) The 3rd CSAIL Student Workshop

11. Page Fetch Walk-through • Look in local cache • Ask the metadata node in the locality region • Ask the server hash ?Page 5? Server The 3rd CSAIL Student Workshop

12. Reputation System • Each client maintains reputation scores • Initial debit • Debit increased/decreased depending on behavior • Is based on information from the server upon commit • Fetch from highest reputation peer • Clients sign messages The 3rd CSAIL Student Workshop

13. Discussion • Byzantine resilience • Reputation system • Last check performed at server • Efficiency • Three short network delays • Scalability • Server is offloaded The 3rd CSAIL Student Workshop

14. Project Status • Prototype is designed and implemented • Need to evaluate • Efficiency of the reputation system • Average fetch time The 3rd CSAIL Student Workshop

15. Conclusions • First Byzantine fault tolerant cooperative caching system • Efficient and scalable • We hope it will show good evaluation results The 3rd CSAIL Student Workshop

16. Thank You • Questions? The 3rd CSAIL Student Workshop