HNHacker News
TopNewBestAskShowJobs

thoughtlede

97 karma · joined April 18, 2021

Giridhar Manepalli. https://exhypothesi.com
submissionscomments
thoughtlede··on Clocks and Causality – Ordering Events in Distributed Systems (2022)
Need more time to think this through. A few comments:

1. The problem space being solved in proof-of-history needs special mention. It assumes byzantine faults. (My article does not).

2. If I understood it correctly, the idea behind proof-of-history is that you perceive the flow of time in "windows". Each window is linked to the state of the previous window (ala blockchain) and has enough randomness built into it that predicting window attributes is a very-low-probability case. When a new event is generated you declare that event to be part of a certain window. You could not have fraudulently backdated your event because the future windows already considered the original future window state (i.e., the state before you inserted your event). You cannot future-date your event because you cannot predict the randomness.

3. At the outset, this is a clever idea. But you mentioned "scalable", I wonder how you would deal with the order of events that are rightfully binned to the same window. Wouldn't you end up with "concurrent events" and find yourself back at square one?

4. At some level, this design can be classified as a causal consistent system. In a non-byzantine world, causal consistent systems can afford network partitions. But in this world, you assume the systems have access to the window-ing system of time flow.

Apologies if I grossly misinterpreted the article.

thoughtlede··on Clocks and Causality – Ordering Events in Distributed Systems (2022)
Right. The flavors of Lamport clocks I stated in the article are used in CRDTs designs I studied.

While CRDTs are eventually consistent, I wouldn't dismiss them as such without qualification. They are causal-consistent when offline and sequential-consistent when online. (This duality is why CRDTs have been hard for me to wrap my head around them).

thoughtlede··on Clocks and Causality – Ordering Events in Distributed Systems (2022)
Author here. Pleasantly surprised to see the article here.

Some context behind the article. I studied CRDTs for a few months, and noticed that different CRDT designs use logical clocks in different and clever ways. And I haven't seen anyone narrate all those ways of use in one article. My attempt with this article was to dredge up those flavors of logical clocks into one article and give them names for future reference.

(To respond to a couple of other comments, I ignored atomic (and gps-based) clocks in this discussion, as indicated in my footnote 3).

thoughtlede··on Query Engines: Push vs. Pull
This is a gem, for me, for its conciseness:

> Crossing a boundary from a pull system to a push system requires polling its state, and crossing a boundary from a push system to a pull system requires materialization of its state.

thoughtlede··on Internal Consistency in Streaming Systems
Interesting article. Two comments:

1. I have always thought of (eventual) consistency to mean consistency between replicas: how in-sync are the replicas in what they "store". Whereas, internal consistency as defined here seems to mean how "multiple reads" can lock into the same storage state. I believe the two concepts are orthogonal, so comparing the two concepts didn't feel natural to me.

2. If transaction ids are monotonically increasing (an if), isn't it possible for subsequent reads to lock into the maximum transaction id of the first read? For example:

    select credits, max(txnid) from table;
    select debits from table where txnid <= max_txnid;
← PreviousPage 2 of 2