I'm finding the graphic novel explaining federated consensus to be really entertaining: <a href="https://www.stellar.org/stories/adventures-in-galactic-consensus-chapter-1/" rel="nofollow">https://www.stellar.org/stories/adventures-in-galactic-conse...</a>
I'm excited for the ideas here and have been following Stellar.<p>But I'm hugely disappointed to see that they went with C and C++ for their new core codebase. This is the kind of code that needs strong safety, security, and correctness guarantees, and here in 2015 we have several mature languages with better safety & correctness guarantees.<p>C# and Java are both mature and mainstream, and either would have been a sane choice. Go is slightly less mature but also a safe and conservative choice.<p>(I personally love where Rust is going too, but I could excuse people for not choosing it yet due to immaturit.)
I'm getting very frustrated by this presentation, it's all "This is so amazing, it satisfies so many criteria, there's a big problem with financial institutions"<p>I can only read those lines so much before I get the feeling of being whitewashed. How does it work? Where is the data?<p>I'm reading the white paper now, but I felt compelled to post this comment after I read through yet another 10 paragraphs of exactly what I described above.<p>Something that takes on distributed consensus is a fantastically interesting project, this is so frustrating!!!
Commentary and review from IRC: <a href="https://botbot.me/freenode/bitcoin-wizards/msg/36135395/" rel="nofollow">https://botbot.me/freenode/bitcoin-wizards/msg/36135395/</a>
Interesting that Graydon Hoare [1], Rust's (initial) creator is one of the core developers.<p>1. <a href="https://github.com/graydon" rel="nofollow">https://github.com/graydon</a>
"It is the responsibility of each node v to ensure Q(v) does not violate quorum intersection".<p>::Sigh:: This sounds like it does not even speak to one of the major fundamental issues of their approach; which I pointed out in 2013 (<a href="https://bitcointalk.org/index.php?topic=144471.msg1548672#msg1548672" rel="nofollow">https://bitcointalk.org/index.php?topic=144471.msg1548672#ms...</a>) and appeared to play a critical role in Stellar's spontaneously faulting, and has been avoided in ripple by using effective centralized admission to the consensus in the system to ensure a uniform topology.<p>The (generalized) ripple "as-advertised"* consensus model can only be safe if the participants trust is sufficiently overlapping. In spite of requests by myself and several others (E.g. Andrew Miller) Ripple never formalized the topology requirement, much less how users are to go about achieving it. This paper goes forward in formalizing it, but still provides no guidance on achieving it; and absent that the only reliably way I know to achieve it is to have a central authority dictate trust. (*Ripple, as-deployed, centrally administers the "trust"; and Stellar faulted when it failed to do so and switched to a fully centralized approach (at least temporarily))<p>Consider a trivial example of two fully meshed subgraphs of 100 nodes each with an overlap of a single node. Assuming that each nodes behavior is tolerant to at least one ill behaved node, then both of the subgroups can come to a consensus (achieving at least 99 out of 100) about mutually exclusive state, and this can happen spontaneously without any attacker. More complicated partitioning-- ones involving many nodes in the min-cut, or more than two partitions-- are possible, to avoid it there must be 'sufficient' overlap.<p>Deciding on what the 'trust' topology must be to achieve safety requires non-local (and presumably private) information about what everyone else in the network trusts. The required minimum set of additional edges to make any particular natural trust topology into a safe one may have no relationship to whom anyone actually finds trustworthy in the real world. As far as I can tell no mechanism is proposed to establish a safe topology; just "the responsibility of each node".<p>To me that sounds a lot like saying "It is the responsibility of each node to not connect to any faulty nodes." Its a very strong assumption.<p>Separately, this system proposes a kind of consensus which is weaker with respect to blocking than e.g. Bitcoins. This is perhaps made most obvious by the point at the end about being unable to use the consensus to safely arbitrate global parameters (like system settings or version upgrades), something we do regularly in Bitcoin. It isn't clear to me why the authors believe that the system is fit for cryptocurrency use when it cannot guarantee eventual agreement about _all_ of the state. In Bitcoin the transaction 'light-cone' from coins splitting and merging appears to grow exponentially for most coins, so a failure to reach consensus on one transaction would eventually block most transactions. It's not clear to me if all participants could reliably detect stuck statuses and avoid dependance on them (if they could, why cant consensus continue). I'll need to read more carefully to understand this point.
I find this kind of stuff fascinating, but lack the CS and/or mathematics background to understand the discussion beyond the basics. I think I grasp the concepts outlined in the graphic novel linked elsewhere in these comments, but the whitepaper is too deep for me.<p>Any pointers for someone looking to gain an amateur understanding of this, or is this a topic of sufficient complexity that it precludes an amateur understanding?
Are they talking about computer verified proofs?
I wonder, are researchers able to prove the correctness of distributed algorithms the same way they would prove sequential algorithms (for instance, using some type of Hoare logic and sat solver/ proof assistant).
Is this protocol isomorphic to bitshare's Delegated Proof of Stake (DPOS) [1]? Seems to have the same qualities.<p>*[1] <a href="https://bitshares.org/delegates" rel="nofollow">https://bitshares.org/delegates</a>
It looks very promising, but I was unable to find the answer to this simple question: How do I get my money from my bank account into the Stellar network?