I was reading a paper [1] that describes how to patch side-channel leakage by providing an abstraction at the OS level. It was a good read, although I was unable to follow most of the details on the microkernel designs that are specific to the L4 kernel. But one
sentence stood out and kept bugging me for two days:

Let’s start with Zero Knowledge Proof — arguably the one of the most important discovery of modern cryptography and computer science. Given the fact that cryptographers are not great at naming things, it is no surprise that ZKP is made up of three most philosophical words out there, which is fitting since the concept itself is full of intricacies and subtleties. Worse, the field is moving so fast in both theoretical and implementation directions, that it becomes all but impossible to catch up (I speak this only for myself, of course).

I am very proud of my Google Home. My son loves her as she plays him ABC and The Wheel on the Bus everyday. I took every opportunity to show her off to house guests. But that was before I moved to an university accommodation and relinquished the previous residential Internet connection. The university has WIFI coverage in the house, and provides several LAN ports on the wall. I plugged her in, and to my horror discovered that she does not work with WPA2 Enterprise Wifi network. And it’s not just her, other smart TVs aren’t likely to work either. They are not designed for networks with stringent security protection.

Evaluating performance of a system \(X\), another fancy name being benchmarking X, is as much of an art as a science. An art because there are many things to measure and report, and because visualizing the results is a creative endeavor. A science, or more of an engineering nature, because it involves designing, implementing, executing and collecting experiment results. Any computer scientist worth his salt would also want to automate the above process with complex scripts.

2019 started with a bang at work. My school organized a research week with a series of distinguished research talks delivered by world-class researchers. I hardly came away from any talk without learning anything new or interesting. The first day covered distributed systems, in glorious theoretical depth and practical complexity. Having only recently gotten less scared of this field, I left Valerie King’s presentation with wholly new understanding of the FLP theorem. Which is to say that my previous, though unstated, view of the theorem was wrong. Well, not as much wrong as incomplete. And that prompted me re-reading some papers, then spent several days wrestling with the original FLP paper. This blog is intended to capture what I understood so far. Knowing how subtle distributed systems are, it will not be the last on FLP and consensus protocols.

It’s been almost 9 months since my previous blog, but in Bitcoin time it must have felt like decades. While the Earth was barely completing three third of its course around the Sun, thousands of Initial Coin Offerings (ICOs) have come and also vanished (or busted) with so much money that rival the previous dot-com bubble. Riding on Ethereum, an ICO typical issues digital tokens to be used as assets or utilities, and attracts investors with unspoken promises of many X increases in token values.

Almost a year has gone by since I sat down and decided to take on Byzantine fault tolerance protocols, starting with its poster child PBFT. Despite countless reprintings and re-readings the OSDI’99 version of the paper, I never stop learning new things at every reread. This is party exacerbated by the fact that Hyperledger Fabric, an open source permissioned blockchain system, contains a Go implementation of PBFT which serves as the basis for truly understanding the protocol. Discrepancies between the implementation and the paper bring the protocol’s internal intricacies out to the surface. The following summarizes few subtleties I discovered.

During the course of my continuing struggle with PBFT, which deserves its own blog entry, I caught a reference to a term dissemination quorum. Previously content with the explanation of quorum being a fanciful term for describing a subset of nodes, of which the most common type is majority quorum, I followed the references rather reluctantly. And boy was I served a big humble pie.

The last month of 2016 saw 3 more books added to my Goodreads’ collections. And since this blog has not a single book review, it is perhaps the right time to jot down a few notes on these very interesting pieces of literatures.

Over the past 3 months I have finally came to face one of most important, yet most challenging (and feared) problems in distributed systems, namely distributed consensus. First raised in 1980s, the problem of getting a set of parties to agree on some value, remains an active area of research, with papers after papers appearing in top-tier systems conferences like SIGCOMM, NSDI, SOSP, OSDI. One may remark at the fact that researchers in the field have not reached a consensus on this decades-old consensus problem. Even without the human irrationality in the loop, the range of subtlety and unpredictability needed to be considered in solving consensus can perhaps be rivalled only by the human political systems. After all, there is no consensus on what is the best political system, and we as a race have worked on it since forever (and if this year is of any indication, we are failing specularly).

Computer security has established itself as a major and hugely active field of computer science. Its engine is driven largely by perpetual arm races between attacks and defenses, between breaking stuff and patching stuff. Helped by disproportionate media interest and sometimes biased narratives, security comes off as a fear factor, as something to be pessimistic about. It is true that the defense guys do not always take the spotlights, that only secure systems are ones that do nothing and thus being useless. Nevertheless, computer security is an art, and portraying their principals at work can be great movie material. Scorpion and Mr Robot, two popular Hollywood series with their the main heroes being computer hackers, are raising public awareness and appreciation for security professionals.

My undergraduate course in distributed systems was a disappointment. Starting the module (winter 2006) with anticipation of highly stimulating sessions, I was quickly let down by the materials. The textbooks were not the best, and the lecturers were clearly not passionate about the field. Over the next ten years, blind spots in my basic grasp of distributed systems kept revealing themselves. It was frustrating to encounter a (design) problem and have to work backward trying to reduce it to known principles. As much as the process helps remembering the principles better, I really wish the fundamentals were (better) taught in University.

In the wake of Apple’s announcement that they incorporating differential privacy in many of the Apple products, I think it’s high time to continue my quest to have a firm grasp on differential privacy. I wrote an introductory note on differential privacy in my old blog [1], but it was over 3 years ago. One could be forgiven in thinking that I should have become an expert by now. Yeah, no.

He was old, a typical Mediterranean old man with a rather big belly, a cherry face. He had a white shirt on, a ragged cap and a poorly laminated map of the city.

“Where are you from, brother?”

Here is to my new blog. May it last longer than the last one!