1 / 16

Byzantine Fault Tolerant Cooperative Caching

Explore the innovative approach of adding Byzantine fault tolerance to cooperative caching for robust distributed safe storage. Our system efficiently handles Byzantine clients, implements cooperative caching, and utilizes a reputation system for client behavior evaluation. Join us in this cutting-edge workshop to learn more about our optimistic approach, locality-based strategies, and maintaining metadata for efficient page fetches in a Byzantine-resilient environment.

mjeffrey
Download Presentation

Byzantine Fault Tolerant Cooperative Caching

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related