Showing posts from July, 2020

The great work of your life, by Stephen Cope

I finished listening to this book 10 days ago. I liked this book a lot while listening to it. Now, I am having second thoughts.
The book uses the Bhagavad Gita (a 700-verse Hindu scripture dated to the second century BCE) as a source/starting point to dispense advice about how to have a fulfilling life and career.
The Gita is a dialogue between Krishna and Arjuna right before the start of the climactic Kurukshetra War in the Hindu epic Mahabharata. Two massive armies have gathered to destroy the other. The Pandava prince Arjuna asks his charioteer Krishna to drive to the center of the battlefield so that he can get a good look at both the armies and all those "so eager for war". He sees that some among his enemies are his own relatives, beloved friends, and revered teachers. He does not want to fight to kill them and is thus filled with doubt and despair on the battlefield. He drops his bow, wonders if he should renounce and just leave the battlefield. He turns to his chariote…

Modeling Streamlet (take two)

This post is a sequel to my last two posts on Streamlet. The first one explained the protocol. The second one presented a first draft modeling of the protocol.
In this post, I present two improvements to the first draft modeling.  In the first, I will make the epochs monotonic at the process level. In the second one, I give each node its own inbox, instead of using a shared whiteboard message set. Again, I will introduce the model dev-log style, using the notes I took while developing it.
Adding locally monotonic epochsWhy don't I just sequentially increase e in the process main loop. Instead of using while true, with e \in E, the process will go through the epochs in increasing order. This still doesn't constrain the processes to go in lock-step through the epochs. Each process can go through epochs in its own pace independent of the others. The only requirement is if a process participated at an epoch (either as a proposer or voter), it will not participate at a lower epoch nu…

Modeling Streamlet in TLA+

I had provided an overview of the Streamlet blockchain protocol in my last post, please read that before reading this post on modeling Streamlet in TLA+. Also if you want to get an idea about TLA+, this may be a good post to read.
Here I model the crash fault-tolerant version of Streamlet provided in Appendix A of the paper. Modeling Byzantine nodes is very hard: How do you simulate arbitrary behavior of the nodes? How do you then hope to model check it? So I stick with the crash fault-tolerant version which is very similar to the Byzantine fault-tolerant version of the protocol. This version only considers crash faults and in turn it can tolerate up to a minority of node failures.
The reason I started modeling was because I was suspicious how there was no need for using the epoch number knowledge in the protocol or the proof of safety in an asynchronous environment. The protocol employs only the longest chain rule. Longest chain does not necessarily mean the chain with the highest epoc…

Streamlet: textbook streamlined blockchains

In this 2020 technical report, the authors claim to present a very simple BFT consensus protocol. I am taking it that "textbook" in the title is used as praise for simplicity of the algorithm. 
Nakamoto consensus is definitely simpler than Streamlet, but in contrast to Nakamoto consensus Streamlet provides deterministic finalization and does not suffer from the costly proof-of-work (POW) and the low-throughput POW induces. And, among the protocols that provide deterministic finalization, including PBFT, Tendermint, HotStuff, yes, Streamlet is the simplest protocol. So, yes, Streamlet deserves your attention.
Streamlet protocolStreamlet is an amalgamation of existing techniques. It borrows stuff from Casper, HotStuff, and Elaine Shi's earlier work. But that's OK. The goal is to show the simplest protocol, not necessarily the most novel or the most efficient protocol. Here is the protocol, verbatim from the introduction of the paper.
In Streamlet, each epoch has a designat…

Masters of Doom: How Two Guys Created an Empire and Transformed Pop Culture (book review)

Masters of Doom is a 2003 book by David Kushner about John Carmack and John Romero cofounded id Software and produced video-games, including Doom and Quake.  
The book was read by Will Wheaton. I  retrospectively recognized his voice from the "Ready Player One" book. He has a very enjoyable and engaging reading style, very close to voice acting.
This was an OK book. It is engaging and worth a read if you don't know much about Carmack and Romero and early days of PC video gaming scene. Unfortunately the book lacks depth, and remains superficial in its analysis and observations. The characters covered, although interesting, come across always as one dimensional.  
One thing that stands out in the book is John Carmack's legendary focusing capability. Carmack is a learning machine. He can take off a couple weeks to master a new sub-area. In the book, he was quoted as saying that he likes the process [of learning and developing games], not just the end result. He took pride …

Misc links edition July 3rd

Popular posts from this blog

I have seen things

SOSP19 File Systems Unfit as Distributed Storage Backends: Lessons from 10 Years of Ceph Evolution

PigPaxos: Devouring the communication bottlenecks in distributed consensus

Frugal computing

Learning about distributed systems: where to start?

Fine-Grained Replicated State Machines for a Cluster Storage System

My Distributed Systems Seminar's reading list for Spring 2020

Cross-chain Deals and Adversarial Commerce

Book review. Tiny Habits (2020)

Zoom Distributed Systems Reading Group