Students may opt in for final project. Each team should be with 2-3 students. The score of final project will replace the score of midterm or lab 3.
Sign up link:
Proposal submission link:
Revised proposal submission:
3/3: Final project signup deadline.
3/10 (Postponed) 3/11: initial project proposal due
3/11-3/13: meeting with instructor
3/13: Project approval/rejection decision out
3/17: Revised proposal due
4/30: Project due
Demo during lecture time (4/30)
Code & report due @ 12pm
Project proposal document. 1 page US letter, 11 pt or larger.
Demo: 20 min presentation
Code: submit your implementation on github classroom
Report: 4-5 page report, describing design, implementation, and evaluation. (example: A Byzantine Fault Tolerant Raft, stanford 22spring)
+2 page on AI usage: please write down how you used AI tools (ChatGPT, Codex, Claude, Claude Code, OmO, etc). Tell us which tool and model you used for which tasks. Please share what went well, what didn't work well. Any caveats or interesting challenges in using AI agents (e.g., critical mistakes that was hidden, or anything you want to share). Please feel free to share your promts in appendix (not included in the page limit).
I highly suggest to discuss with me if you are interested in final project. You may come to my office hours to build some project ideas.
Here are some ideas you might be interested in for projects. This list is by no means exhaustive (some of them are borrowed from David Mazieres).
Building a new consensus protocol for satellite datacenters.
Extending Raft (may reuse lab2) to tolerate byzantine faults.
Applying CURP-like mechanism to Raft (may reuse lab 2).
Distributed protocols such as 2PC and Paxos are (1) short, (2) really hard to get right because of failures and uncertainty. Build a simple system that takes an implementation of these protocols and systematically explores their behavior in the face of crashes and network partitioning. See here for an example of how to do this for file systems.
Extending RIFL to provide exactly-once semantice for chain of microservices
Extending RIFL to provide exactly-once semantice for Spanner-like systems that provide migrations + SMR.
Build a distributed profiler that allows you to observe where time really goes in a distributed system. You should use it to spot bottlenecks in at least one existing distributed system.
Build a checking infrastructure than can plug into the many different RAFT implementations and find protocol errors. The nice trick you can use here is that you do not have to specify correctness: each of the protocols must do the same observable action given the same sequence of crashes, partitions, recoveries. You may want to look at what Kyle Kingsbury has done with Jepsen.
Build a clean, simple implementation of view stamped replication based on the updated Liskov paper that can be dropped into distributed systems in a way analogous to RAFT.
Raspberry/pi is a very popular embedded computing platform. Build a distributed system using r/pi nodes and some interesting cheap hardware. More ambitious: build a clean, simple "bare-metal" toolkit on r/pi that allows people to easily build such systems.
Build a simple, automatic distributed-parallel make implementation. Most makefiles are broken with spurious dependencies (slow) and missing dependencies (incorrect). Fortunately you can infer true dependencies automatically: kick off an existing (broken) build, intercept every "open()" system call to see which other files a given file depends on (e.g., all the files it #includes). Build a lightweight distributed system that does parallel distributed builds using these dependencies.
Build a large file store, like GFS, and possibly using RAID like Zebra.
Build a simplified version of a synchronization service like Google's Chubby.
Build a highly-available, replicated DNS server that uses Paxos to ensure consistency of updates.
Build a system-call or message-level interposition library that can be slipped underneath an existing networked server and transparently be used to replicate these services so that they can survive failure and network partitioning. (Something similar but more complicated that what you would build: parrot.)
Build a file synchronization tool like tra.
Build a raftscope-like visualization tool for a different protocol.