Brief review I did of the paper a while back:<p>Forkable strings (a la Ouroboros) makes unrealistic assumptions.<p>Ouroboros is a Proof-of-Stake altcoin that comes with a security proof based on the idea of "forkable strings".<p>As a brief introduction: each round/epoch consists of a sequence (of length n) of leaders, each chosen from a set of stakeholders, that have the authority to decide between multiple valid branches of a fork. They model this, using a concept they invent called a "forkable string", and prove various security properties about it.<p>The full definition can be read in page 16 of the Ouroboros paper. One key assumption is that they assume all the honest leaders (say, at indexes H = [i], a subsequence of the full sequence [0, 1, ..., n-1]), will only commit to chains that have increasing depth, as i increases.<p>For example, suppose that our sequence of leaders is 5 stakeholders long [s1 ... s5], and stakeholders s2, s3, s5 are honest. Suppose we start off at block O. Then suppose that s2 commits a new block B 2 blocks away from O:<p>O <-- ? <-- B[s2]<p>(The arrows go in the opposite direction in the paper, but I prefer it this way because that is how the references go. ? knows about O, O doesn't know about ?.)<p>Then a "forkable string" assumes that s3 knows about B[s2], and since s3 is honest (as we assumed for our scenario) she <i>will</i> commit her new block C, >2 blocks away from O. Suppose she commits it 3 blocks away:<p>O <-- ? <-- ? <-- C[s3]<p>Then s5 knows about C[s3], and being honest, <i>will</i> commit his new block E, >3 blocks away from O:<p>O <-- ? <-- ? <-- ? [..] <-- E[s5]<p>Using this property (and others) of forkable strings, the authors then go on to prove various security properties about Ouroboros.<p>As you might have noticed already, this property assumes that all honest nodes can reliably receive all other honest nodes' blocks. The paper in fact freely admits this in various places, e.g. on page 10 and page 16. I was already skeptical when reading that, but the fact that this assumption forms such a key requirement of their security proof raised my eyebrow(s) even further.<p>If every honest node can reliably receive all honest nodes' blocks, we don't need any complex leadership selection algorithm nor the idea of forkable strings. Everyone can just sync (union) their view of what blocks they've seen with each other via this magical "reliable channel", and run a deterministic pure algorithm like `sort | head -n1` to disambiguate any forks!<p>The whole point of a maxvalid() algorithm (e.g. PoW in bitcoin) is to secure the case where nodes <i>including honest ones</i>, don't have reliable channels to each other e.g. because they are under attack, or because of pervasive network latency. As soon as you assume they already have a reliable channel to everyone else, you have already "begged the question", and anything you build on top of this (like `sort | head -n1`) is guaranteed to "work".<p>(Another strange thing, is that the authors allow the attacker to selectively show different honest nodes different stuff [1], but for some reason is not able to prevent honest nodes from seeing all other honest nodes' stuff.)<p>[1] e.g. page 17 "the honest player associated with the third slot is shown a chain of length 1 produced by the adversarial player of slot 2" but is unable to see the other (2) node, that eventually forms the ^t chain ("tine").