11 ms·

Stellar Consensus Protocol: Proof and Code

274 points by joyce 11y ago

olh 11y ago
Is this protocol isomorphic to bitshare's Delegated Proof of Stake (DPOS) [1]? Seems to have the same qualities. *[1] https://bitshares.org/delegates https://bitshares.org/delegates
- mazieres 11y ago
  Bitshares is more democratic than decentralized. Basically people vote their stakes to elect 100 nodes that ensure consensus, but everyone knows who the 100 nodes are. By contrast, the FBA trust model is completely independent of coin holdings, and just depends on pairwise relationships between the validator nodes. The resulting quorum structure is unlikely to look like a single fully-connected group.
kanzure 11y ago
Commentary and review from IRC: https://botbot.me/freenode/bitcoin-wizards/msg/36135395/ https://botbot.me/freenode/bitcoin-wizards/msg/36135395/
Rhapso 11y ago
I'm still reading the paper, but I'm not seeing any discussion of a sybil or eclipse attack defense.
- burke 11y ago
  This is kind of explained away implicitly by pages 6-7. Each node has its own quorum slice, and they tend to point upward to a set of trustworthy financial institutions, not entirely unlike DNS. i.e. FBA relies on a web of trust, not just on showing up and churning out hashes or whatever.
  - TheOsiris 11y ago
    isn't this still sort of pseudo-centralized? my guess is that most people will trust the same handful of nodes.
    - r721 11y ago
      It's interesting how this suddenly shifts into "journalistic independence" territory - what about who reports on that? What if some influential source would receive some financial aid for proper reporting?
    - JoelKatz 11y ago
      This kind of "pseudo-centralized" is decentralized. When the "central authority" gets all of its power from individual participants who choose to follow it, and those participants are free to change the authorities at any time, that's a decentralized model. Bitcoin isn't centralized just because everyone has to agree on which transactions are valid.
- mjb 11y ago
  Read section 3 and 4 of the whitepaper - the whole trust a quorum model is directly aimed at Sybil-style attacks. The key argument here is that the way they do group membership prevents these attacks by using a trusted quorum. This seems like a key place to focus attention for outside analysis of the properties of this protocol. If the assertions about this are incorrect, then the whole thing breaks down. As the Sybil paper points out, membership is critical for consensus. As a common-sense thing, "we have agreed" is super dependent on who "we" is. As for eclipse, the model is so fundamentally different that it's not clear that there is a direct analogy for those network attacks. What do you have in mind? I'm not saying that it's obviously safe, just that attacks on the network protocol would have a very different flavor.
- spolu 11y ago
  (disclaimer: I had early access to the white paper for review) Sybil attacks are not really directly applicable here since each node in the system picks its own quorum slices (basically the set of nodes that it trusts). There is no notion of global reputation and nodes do not need to know every other nodes to participate. Looking at the definition of quorum intersection[0] section 4.1 should give you a sense of the conditions that are required on the choice of quorum slices for the network to function properly (quorum intersection ensures safety) The proof exposed in the paper guarantees safety and liveness for the network provided a certain number of reasonable conditions are held true. What that means is that an attacker cannot force on intact nodes (definition p14) invalid transactions nor prevent the network from making progress. That being said, (at least in the version I reviewed) there is no guarantee provided with respect to ensuring that all valid transaction will eventually make it into the network. Indeed a set of highly trusted nodes (present in a lot of quorum slices) could attempt to preempt a specific set of transactions X (originated by edge nodes) by opportunistically broadcasting valid transaction set V_i for each successive ledger entry i that explicitly do not include the targeted set of transactions X. Under raw SCP as described in the paper and for certain topologies this preemption could be real and this is the closest I can think of a Sybil attack. It's important to note that we still have liveness and safety in that case. I believe the same kind of attacks to be plausible with the Bitcoin network and I know protection mechanisms against it are currently being evaluated by David, Jed and the rest of the team. I will let them share their progress when they think it's right. I also hope they will correct me if I stated anything inaccurate here! [0] https://www.stellar.org/papers/stellar-consensus-protocol.pdf https://www.stellar.org/papers/stellar-consensus-protocol.pd...
  - nullc 11y ago
    > I believe the same kind of attacks to be plausible with the Bitcoin network This isn't anyone elses understanding. Can you suggest a mechanism by which it would be possible for a minority conspiracy to perpetually exclude a transaction in Bitcoin?
    - spolu 11y ago
      Well in bitcoin, of course, trust would map to computing power.
yodsanklai 11y ago
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).
- mazieres 11y ago
  No. At least for the moment, the proofs are English language only.
- djb_hackernews 11y ago
  You may be interested in this[0] paper outlining AWS use of TLA+ to formally prove its systems. Also previous discussion here[1]. [0] http://research.microsoft.com/en-us/um/people/lamport/tla/formal-methods-amazon.pdf http://research.microsoft.com/en-us/um/people/lamport/tla/fo... [1] https://news.ycombinator.com/item?id=8096185 https://news.ycombinator.com/item?id=8096185
- ziedaniel1 11y ago
  If anyone's interested in proving distributed algorithms correct, they should check out the Verdi project (https://github.com/uwplse/verdi https://github.com/uwplse/verdi), which has proved Raft correct in Coq. I imagine handling Byzantine faults and the full complexity of SCP would be quite a bit harder, but probably doable. To me, though, it would be more interesting to prove the implementation correct. Rather than trying to prove an existing C++ implementation correct, it's probably more feasible to reimplement the algorithm within Coq and extract to runnable code. Verdi already supports that, but unfortunately it doesn't support disk state.
GhotiFish 11y ago
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" I can only read those lines so much before I get the feeling of being whitewashed. How does it work? Where is the data? 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. Something that takes on distributed consensus is a fantastically interesting project, this is so frustrating!!!
- jude- 11y ago
  Did you read the whitepaper? It's much more technical. Link: https://www.stellar.org/papers/stellar-consensus-protocol.pdf https://www.stellar.org/papers/stellar-consensus-protocol.pd...
nullc 11y ago
"It is the responsibility of each node v to ensure Q(v) does not violate quorum intersection". ::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 (https://bitcointalk.org/index.php?topic=144471.msg1548672#msg1548672 https://bitcointalk.org/index.php?topic=144471.msg1548672#ms...) 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. 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)) 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. 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". 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. 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.
ef4 11y ago
I'm excited for the ideas here and have been following Stellar. 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. 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. (I personally love where Rust is going too, but I could excuse people for not choosing it yet due to immaturit.)
- VienneseCPA 11y ago
  When your software aspires to move billions of dollars of value, it would ideally be written in Ada. That said, I agree that C# and Java are good options. What's hilarious is all of the Bitcoin startups that are running on node.js and mongodb. Would you put your kids on a flight if you knew the control system was written with javascript and mongodb? Yikes.
  - lectrick 11y ago
    Actually, having met a few of them, a surprising number are using PHP, which made me quite angry lol.
  - rational-future 11y ago
    You are partially right. It is completely possible to write in JS/Mongo systems as robust as Ada/Oracle|DB2|SQL Server. You just have to know what you are doing. There is no magic in Ada, Oracle, etc. Node and Mongo are moving hundreds of billions daily in HFS shops.
    - SkyMarshal 11y ago
      >There is no magic in Ada, Oracle, etc. There is no magic but there are strong constraints that shift reliance for correctness from fallible human programmers and peripheral tools to the type system and compiler, providing better integrated, systematic assurance.
leothekim 11y ago
I'm finding the graphic novel explaining federated consensus to be really entertaining: https://www.stellar.org/stories/adventures-in-galactic-consensus-chapter-1/ https://www.stellar.org/stories/adventures-in-galactic-conse...
- joyce 11y ago
  Joyce from Stellar here. Thanks! As we were working on the white paper, we realized how difficult it was to explain complex concepts like federated Byzantine agreement. We know it’s part of our jobs to make these ideas understandable. That way more people can join the dialogue and think of ways this infrastructure can be used to build services for their communities, which may be really far from the nearest computer science program. So we decided to add a lighter approach in hopes of making it fun for people to learn.
  - leothekim 11y ago
    Hi Joyce, thanks for chiming in! I'm glad Stellar is committed to elucidating the ideas behind the technology, and this is a thoughtful and creative approach. Reading the graphic novel first helped me understand the idea behind quorum slices while reading the paper. Can't wait to see more of this!
  - z3t4 11y ago
    The hard part is often explaining something. And if you want to change how money works, you need to be very good at explaining.
- tomasien 11y ago
  It's actually AMAZING! I've actually been pretty deeply embedded in the crypto community for a while and have spent some amount of time with the Stellar folk, and I after reading the gn I understand Stellar (and even the blockchain) significantly better! At least in a way that requires a lot less cognitive overhead to mentally tinker with.
lectrick 11y ago
How do they do proof-of-work?
- wmf 11y ago
  The whole point of Ripple/Stellar is that it doesn't use proof of work. They have an alternative that trades off trust for resource consumption.
oskarer 11y ago
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?
- diyang 11y ago
  You can get money in and out of the Stellar network using gateways. You can learn more about them here: https://www.stellar.org/learn/explainers/#Gateways_trust_and_credit https://www.stellar.org/learn/explainers/#Gateways_trust_and... This post is about keeping everybody's copy of the ledger the same using a process called consensus. Even if there were no gateways, there still is the problem of ledger agreement, so we'd still need consensus. Gateways and consensus are orthogonal. You can learn more about consensus here: https://www.stellar.org/learn/explainers/#Consensus https://www.stellar.org/learn/explainers/#Consensus
- themusicgod1 11y ago
  > How do I get my money from my bank account into the Stellar network? In addition to using gateways, as diyang suggests, there is another way, but you first need two things 1) Someone on the network who you trust. This may be your bank, but it could also be something else. I'm not going to tell you who or what you should trust, and to what extent, that is a decision that should be always in your hands 2) A path between the entity you trust and an entity that either you or your bank has access to. Until #2 exists, you can do what the poster below just said: use a gateway. This is not recommended, as they are probably going to track you and it may not be always possible to deal with them in a humane way. So really it depends on what your bank is, whether it makes sense to draw money from your bank into another form/service that is compatible with a service that stellar can talk to. What bank? What country? These things are going to matter on the global scale.
zenincognito 11y ago
Click View Source on Homepage. Easter egg ?
foobarqux 11y ago
Where should we first see Stellar deployed in a major way?
- tlrobinson 11y ago
  Stripe? (https://stripe.com/blog/stellar https://stripe.com/blog/stellar)
  - foobarqux 11y ago
    What significant application of Stellar do they have?
davewasmer 11y ago
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. 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?
- andrewstellar 11y ago
  Here's an overview that attempts to explain it in a less CS/math way and a more general and approachable way: https://medium.com/a-stellar-journey/on-worldwide-consensus-359e9eb3e949 https://medium.com/a-stellar-journey/on-worldwide-consensus-...
deleted 11y ago
[deleted]
- spolu 11y ago
  (disclaimer: I had early access to the whitepaper for review) You should look in the white paper[0] to the definition of an FBAS which differs from epaxos (while epaxos is egalitarian, SCP is federated). All related proofs are included in the whitepaper, the central one being theorem 3 in 4.2. Finally the protocol specification (Figure 15, p28) is also very interesting. [0] https://www.stellar.org/papers/stellar-consensus-protocol.pdf https://www.stellar.org/papers/stellar-consensus-protocol.pd...
  - yshalabi 11y ago
    Hi. I won't be able to read this for a while. I am not familiar with federated byzantine. Can you quickly comment on the difference between this and purely distributed consensus? How is fault tolerance maintained? Do we presume that top tiers are free of byzantine nodes? Thanks!
    - spolu 11y ago
      I think this page should answer your questions: https://medium.com/a-stellar-journey/on-worldwide-consensus-359e9eb3e949 https://medium.com/a-stellar-journey/on-worldwide-consensus-...
lucian1900 11y ago
Interesting that Graydon Hoare [1], Rust's (initial) creator is one of the core developers. 1. https://github.com/graydon https://github.com/graydon
- neilk 11y ago
  Graydon also created monotone, which was a big influence on git. http://www.monotone.ca/monotone.pdf http://www.monotone.ca/monotone.pdf https://en.wikipedia.org/wiki/Monotone_%28software%29#Monotone_as_Git_inspiration https://en.wikipedia.org/wiki/Monotone_%28software%29#Monoto...
  - LukeHoersten 11y ago
    I think Monotone was an alternative to BitKeeper and BitKeeper was the inspiration of Git and Mercurial. It even seems to suggest that in the link you posted.
    - pgeorgi 11y ago
      Linus played with Monotone before he started git (and it shows) He is even credited in the changelog: http://lwn.net/Articles/131744/ http://lwn.net/Articles/131744/
    - deleted 11y ago
      [deleted]
    - masklinn 11y ago
      BitKeeper not being available anymore was the impetus for starting Git and Mercurial (as replacements for BK), but many of the concepts in Git and Hg come from Monotone, most importantly the use of merkle trees (according to /u/ggherdov Matt Mackall[0] recently mentioned this explicitly on IRC). Linus also mentioned Monotone by name as "the most viable alternative" before starting/publishing git[1] and as pgeorgi noted contributed to the same. [0] https://www.reddit.com/r/programming/comments/31yi7d/graydon2_stellar_consensus_recent_programming/cq6c8j4 https://www.reddit.com/r/programming/comments/31yi7d/graydon... [1] https://lkml.org/lkml/2005/4/6/121 https://lkml.org/lkml/2005/4/6/121

274 points by joyce 11y ago

olh 11y ago

Is this protocol isomorphic to bitshare's Delegated Proof of Stake (DPOS) [1]? Seems to have the same qualities. *[1] https://bitshares.org/delegates https://bitshares.org/delegates

mazieres 11y ago
Bitshares is more democratic than decentralized. Basically people vote their stakes to elect 100 nodes that ensure consensus, but everyone knows who the 100 nodes are. By contrast, the FBA trust model is completely independent of coin holdings, and just depends on pairwise relationships between the validator nodes. The resulting quorum structure is unlikely to look like a single fully-connected group.

kanzure 11y ago

Commentary and review from IRC: https://botbot.me/freenode/bitcoin-wizards/msg/36135395/ https://botbot.me/freenode/bitcoin-wizards/msg/36135395/

Rhapso 11y ago

I'm still reading the paper, but I'm not seeing any discussion of a sybil or eclipse attack defense.

burke 11y ago
This is kind of explained away implicitly by pages 6-7. Each node has its own quorum slice, and they tend to point upward to a set of trustworthy financial institutions, not entirely unlike DNS. i.e. FBA relies on a web of trust, not just on showing up and churning out hashes or whatever.
- TheOsiris 11y ago
  isn't this still sort of pseudo-centralized? my guess is that most people will trust the same handful of nodes.
  - r721 11y ago
    It's interesting how this suddenly shifts into "journalistic independence" territory - what about who reports on that? What if some influential source would receive some financial aid for proper reporting?
  - JoelKatz 11y ago
    This kind of "pseudo-centralized" is decentralized. When the "central authority" gets all of its power from individual participants who choose to follow it, and those participants are free to change the authorities at any time, that's a decentralized model. Bitcoin isn't centralized just because everyone has to agree on which transactions are valid.
mjb 11y ago
Read section 3 and 4 of the whitepaper - the whole trust a quorum model is directly aimed at Sybil-style attacks. The key argument here is that the way they do group membership prevents these attacks by using a trusted quorum. This seems like a key place to focus attention for outside analysis of the properties of this protocol. If the assertions about this are incorrect, then the whole thing breaks down. As the Sybil paper points out, membership is critical for consensus. As a common-sense thing, "we have agreed" is super dependent on who "we" is. As for eclipse, the model is so fundamentally different that it's not clear that there is a direct analogy for those network attacks. What do you have in mind? I'm not saying that it's obviously safe, just that attacks on the network protocol would have a very different flavor.
spolu 11y ago
(disclaimer: I had early access to the white paper for review) Sybil attacks are not really directly applicable here since each node in the system picks its own quorum slices (basically the set of nodes that it trusts). There is no notion of global reputation and nodes do not need to know every other nodes to participate. Looking at the definition of quorum intersection[0] section 4.1 should give you a sense of the conditions that are required on the choice of quorum slices for the network to function properly (quorum intersection ensures safety) The proof exposed in the paper guarantees safety and liveness for the network provided a certain number of reasonable conditions are held true. What that means is that an attacker cannot force on intact nodes (definition p14) invalid transactions nor prevent the network from making progress. That being said, (at least in the version I reviewed) there is no guarantee provided with respect to ensuring that all valid transaction will eventually make it into the network. Indeed a set of highly trusted nodes (present in a lot of quorum slices) could attempt to preempt a specific set of transactions X (originated by edge nodes) by opportunistically broadcasting valid transaction set V_i for each successive ledger entry i that explicitly do not include the targeted set of transactions X. Under raw SCP as described in the paper and for certain topologies this preemption could be real and this is the closest I can think of a Sybil attack. It's important to note that we still have liveness and safety in that case. I believe the same kind of attacks to be plausible with the Bitcoin network and I know protection mechanisms against it are currently being evaluated by David, Jed and the rest of the team. I will let them share their progress when they think it's right. I also hope they will correct me if I stated anything inaccurate here! [0] https://www.stellar.org/papers/stellar-consensus-protocol.pdf https://www.stellar.org/papers/stellar-consensus-protocol.pd...
- nullc 11y ago
  > I believe the same kind of attacks to be plausible with the Bitcoin network This isn't anyone elses understanding. Can you suggest a mechanism by which it would be possible for a minority conspiracy to perpetually exclude a transaction in Bitcoin?
  - spolu 11y ago
    Well in bitcoin, of course, trust would map to computing power.

yodsanklai 11y ago

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).

mazieres 11y ago
No. At least for the moment, the proofs are English language only.
djb_hackernews 11y ago
You may be interested in this[0] paper outlining AWS use of TLA+ to formally prove its systems. Also previous discussion here[1]. [0] http://research.microsoft.com/en-us/um/people/lamport/tla/formal-methods-amazon.pdf http://research.microsoft.com/en-us/um/people/lamport/tla/fo... [1] https://news.ycombinator.com/item?id=8096185 https://news.ycombinator.com/item?id=8096185
ziedaniel1 11y ago
If anyone's interested in proving distributed algorithms correct, they should check out the Verdi project (https://github.com/uwplse/verdi https://github.com/uwplse/verdi), which has proved Raft correct in Coq. I imagine handling Byzantine faults and the full complexity of SCP would be quite a bit harder, but probably doable. To me, though, it would be more interesting to prove the implementation correct. Rather than trying to prove an existing C++ implementation correct, it's probably more feasible to reimplement the algorithm within Coq and extract to runnable code. Verdi already supports that, but unfortunately it doesn't support disk state.

GhotiFish 11y ago

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" I can only read those lines so much before I get the feeling of being whitewashed. How does it work? Where is the data? 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. Something that takes on distributed consensus is a fantastically interesting project, this is so frustrating!!!

jude- 11y ago
Did you read the whitepaper? It's much more technical. Link: https://www.stellar.org/papers/stellar-consensus-protocol.pdf https://www.stellar.org/papers/stellar-consensus-protocol.pd...

nullc 11y ago

"It is the responsibility of each node v to ensure Q(v) does not violate quorum intersection". ::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 (https://bitcointalk.org/index.php?topic=144471.msg1548672#msg1548672 https://bitcointalk.org/index.php?topic=144471.msg1548672#ms...) 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. 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)) 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. 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". 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. 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.

ef4 11y ago

I'm excited for the ideas here and have been following Stellar. 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. 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. (I personally love where Rust is going too, but I could excuse people for not choosing it yet due to immaturit.)

VienneseCPA 11y ago
When your software aspires to move billions of dollars of value, it would ideally be written in Ada. That said, I agree that C# and Java are good options. What's hilarious is all of the Bitcoin startups that are running on node.js and mongodb. Would you put your kids on a flight if you knew the control system was written with javascript and mongodb? Yikes.
- lectrick 11y ago
  Actually, having met a few of them, a surprising number are using PHP, which made me quite angry lol.
- rational-future 11y ago
  You are partially right. It is completely possible to write in JS/Mongo systems as robust as Ada/Oracle|DB2|SQL Server. You just have to know what you are doing. There is no magic in Ada, Oracle, etc. Node and Mongo are moving hundreds of billions daily in HFS shops.
  - SkyMarshal 11y ago
    >There is no magic in Ada, Oracle, etc. There is no magic but there are strong constraints that shift reliance for correctness from fallible human programmers and peripheral tools to the type system and compiler, providing better integrated, systematic assurance.

leothekim 11y ago

I'm finding the graphic novel explaining federated consensus to be really entertaining: https://www.stellar.org/stories/adventures-in-galactic-consensus-chapter-1/ https://www.stellar.org/stories/adventures-in-galactic-conse...

joyce 11y ago
Joyce from Stellar here. Thanks! As we were working on the white paper, we realized how difficult it was to explain complex concepts like federated Byzantine agreement. We know it’s part of our jobs to make these ideas understandable. That way more people can join the dialogue and think of ways this infrastructure can be used to build services for their communities, which may be really far from the nearest computer science program. So we decided to add a lighter approach in hopes of making it fun for people to learn.
- leothekim 11y ago
  Hi Joyce, thanks for chiming in! I'm glad Stellar is committed to elucidating the ideas behind the technology, and this is a thoughtful and creative approach. Reading the graphic novel first helped me understand the idea behind quorum slices while reading the paper. Can't wait to see more of this!
- z3t4 11y ago
  The hard part is often explaining something. And if you want to change how money works, you need to be very good at explaining.
tomasien 11y ago
It's actually AMAZING! I've actually been pretty deeply embedded in the crypto community for a while and have spent some amount of time with the Stellar folk, and I after reading the gn I understand Stellar (and even the blockchain) significantly better! At least in a way that requires a lot less cognitive overhead to mentally tinker with.

lectrick 11y ago

How do they do proof-of-work?

wmf 11y ago
The whole point of Ripple/Stellar is that it doesn't use proof of work. They have an alternative that trades off trust for resource consumption.

oskarer 11y ago

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?

diyang 11y ago
You can get money in and out of the Stellar network using gateways. You can learn more about them here: https://www.stellar.org/learn/explainers/#Gateways_trust_and_credit https://www.stellar.org/learn/explainers/#Gateways_trust_and... This post is about keeping everybody's copy of the ledger the same using a process called consensus. Even if there were no gateways, there still is the problem of ledger agreement, so we'd still need consensus. Gateways and consensus are orthogonal. You can learn more about consensus here: https://www.stellar.org/learn/explainers/#Consensus https://www.stellar.org/learn/explainers/#Consensus
themusicgod1 11y ago
> How do I get my money from my bank account into the Stellar network? In addition to using gateways, as diyang suggests, there is another way, but you first need two things 1) Someone on the network who you trust. This may be your bank, but it could also be something else. I'm not going to tell you who or what you should trust, and to what extent, that is a decision that should be always in your hands 2) A path between the entity you trust and an entity that either you or your bank has access to. Until #2 exists, you can do what the poster below just said: use a gateway. This is not recommended, as they are probably going to track you and it may not be always possible to deal with them in a humane way. So really it depends on what your bank is, whether it makes sense to draw money from your bank into another form/service that is compatible with a service that stellar can talk to. What bank? What country? These things are going to matter on the global scale.

zenincognito 11y ago

Click View Source on Homepage. Easter egg ?

foobarqux 11y ago

Where should we first see Stellar deployed in a major way?

tlrobinson 11y ago
Stripe? (https://stripe.com/blog/stellar https://stripe.com/blog/stellar)
- foobarqux 11y ago
  What significant application of Stellar do they have?

davewasmer 11y ago

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. 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?

andrewstellar 11y ago
Here's an overview that attempts to explain it in a less CS/math way and a more general and approachable way: https://medium.com/a-stellar-journey/on-worldwide-consensus-359e9eb3e949 https://medium.com/a-stellar-journey/on-worldwide-consensus-...

deleted 11y ago

[deleted]

spolu 11y ago
(disclaimer: I had early access to the whitepaper for review) You should look in the white paper[0] to the definition of an FBAS which differs from epaxos (while epaxos is egalitarian, SCP is federated). All related proofs are included in the whitepaper, the central one being theorem 3 in 4.2. Finally the protocol specification (Figure 15, p28) is also very interesting. [0] https://www.stellar.org/papers/stellar-consensus-protocol.pdf https://www.stellar.org/papers/stellar-consensus-protocol.pd...
- yshalabi 11y ago
  Hi. I won't be able to read this for a while. I am not familiar with federated byzantine. Can you quickly comment on the difference between this and purely distributed consensus? How is fault tolerance maintained? Do we presume that top tiers are free of byzantine nodes? Thanks!
  - spolu 11y ago
    I think this page should answer your questions: https://medium.com/a-stellar-journey/on-worldwide-consensus-359e9eb3e949 https://medium.com/a-stellar-journey/on-worldwide-consensus-...

lucian1900 11y ago

Interesting that Graydon Hoare [1], Rust's (initial) creator is one of the core developers. 1. https://github.com/graydon https://github.com/graydon

neilk 11y ago
Graydon also created monotone, which was a big influence on git. http://www.monotone.ca/monotone.pdf http://www.monotone.ca/monotone.pdf https://en.wikipedia.org/wiki/Monotone_%28software%29#Monotone_as_Git_inspiration https://en.wikipedia.org/wiki/Monotone_%28software%29#Monoto...
- LukeHoersten 11y ago
  I think Monotone was an alternative to BitKeeper and BitKeeper was the inspiration of Git and Mercurial. It even seems to suggest that in the link you posted.
  - pgeorgi 11y ago
    Linus played with Monotone before he started git (and it shows) He is even credited in the changelog: http://lwn.net/Articles/131744/ http://lwn.net/Articles/131744/
  - deleted 11y ago
    [deleted]
  - masklinn 11y ago
    BitKeeper not being available anymore was the impetus for starting Git and Mercurial (as replacements for BK), but many of the concepts in Git and Hg come from Monotone, most importantly the use of merkle trees (according to /u/ggherdov Matt Mackall[0] recently mentioned this explicitly on IRC). Linus also mentioned Monotone by name as "the most viable alternative" before starting/publishing git[1] and as pgeorgi noted contributed to the same. [0] https://www.reddit.com/r/programming/comments/31yi7d/graydon2_stellar_consensus_recent_programming/cq6c8j4 https://www.reddit.com/r/programming/comments/31yi7d/graydon... [1] https://lkml.org/lkml/2005/4/6/121 https://lkml.org/lkml/2005/4/6/121