6 ms·

You are correct that safety requires overlapping quorums. However, the trust decisions are public, as this is what allows participants to discover quorums. Th

You are correct that safety requires overlapping quorums. However, the trust decisions are public, as this is what allows participants to discover quorums. The scenario you describe of two groups of 100 participants overlapping at one node might or might not be a problem. The most likely cause of such a topology is a Sybil attack, in which an attacker with one seat at the table gloms an extra 99 nodes onto the system that nobody trusts. The attackers' 100 nodes might of course diverge if they are so configured, but nobody will care. A priori, we cannot definitively answer what kind of topology will emerge. But there is certainly precedent for building a robust network out of pairwise relationships, namely inter-domain routing on the Internet.

wmf 12y ago
The attackers' 100 nodes might of course diverge if they are so configured, but nobody will care. The person who is being attacked cares, right? Is there a way for a Stellar node to realize that it has been partitioned from the real network?
- mazieres 12y ago
  Yes, and this is kind of the whole point of the protocol. It just hinges on defining the real stellar network. An analogous question is, "Is there a way for a computer to realize it has been partitioned from the real Internet?" Well, sure. Pick 50 web sites you think are really important--maybe a bunch from Alexa, plus your bank, employer, etc.--and make sure you can reach the vast majority of them (using https, of course, so no one can impersonate them). There's one sense in which FBA is stronger than the Internet analogy, however, it that is is actually testing transitive reachability. So instead of just making sure you can talk to those 50 web sites, you actually make sure all of those 50 web sites can talk to all the sites they consider important, and so on, until you get the transitive closure, which is basically the notion of an FBA quorum.
  - lectrick 12y ago
    > you actually make sure all of those 50 web sites can talk to all the sites they consider important This requires you to trust the 50, correct?
    - mazieres 12y ago
      Well for safety it's a logical AND, not an OR. But for liveness you'd most likely you'd have some threshold. For example, you might that at least 34 of the 50 are honest.
nullc 12y ago
> are public Ah. What mechanism assures this consistency of this information? > at one node might or might not be a problem How could it not be a problem? If that is the totality of the network, and the network is 1-fault tolerant, what prevents spontaneous divergence of the state? > most likely cause of such a topology is a Sybil attack "likely"? It's not clear what you mean there. What statistical model have you adopted that allows you to reason about the likelihood of various topologies? Social networks usually appear to have small word behavior where its usually very easy to draw lines that describe disjoint local-majorities (or fairly large local-super-majorities). I agree that a sybil sticking on a bunch on a bunch of extra 'nodes' and the sybil nodes diverging as a result isn't interesting case. What I do think is interesting is what mechanism will prevent user's honestly stated trust (much less politically manipulated trust) being a bad topology? What is the procedure that I can follow, that if everyone else follows it, results in the correct global behavior (with high probability)? What are the additional assumptions required to achieve that and make it secure? Why are they plausible? Do they provide decentralization? (I can suggest on procedure which works: Stellar tells everyone who to trust; but it completely fails at decentralization so I assume that isn't the goal.) In Bitcoin our security assumption is that the computational majority of participants conform to the protocol ('are honest') and these participants are not completely partitioned from each other. People can then think about-- or debate-- how reasonable those assumptions are. (There are alternative formulations of Bitcoin's security which also argue about how plausible these assumptions are given economic incentive assumptions; but even this most simple set of assumptions gives people something easy to reason about.) Can you give a parallel (informally stated, but equally comprehensive) version of the security assumptions for your consensus system? > But there is certainly precedent for building a robust network out of pairwise relationships, namely inter-domain routing on the Internet. The Internet is _wildly_ inconsistent. Asymmetric routing is the norm, the internet frequently suffers small partitioning and loops; single malicious parties at the edge can frequently inject bad state that is accepted globally, congestion and blocking happens multiple hops away from users where they have no recourse. The internet is not a consensus system, and these issues are not usually hugely problematic; someones brokenness doesn't involve your traffic generally effect you, you can route around problems locally. Ephemeral routing and ledgers are fairly different problems. Ambiguity about the ownership of a coin eventually effects almost everyone. I'm not seeing the connection you're making there. I certainly agree that useful systems can be built from pairwise relationships: The original ripple design for pure IOUs without creating its own cryptocurrency prior to opencoin buying the ripple name was such a system, it had no need for a global consensus (except perhaps in certain atomic unwind cases)-- only the participants in a particular IOu transfer needed to be involved. It is not at all clear to me that a safe global consensus system can be built from pairwise trust.
jude- 12y ago
Hello Dr. Mazieres, thank you for making the Stellar whitepaper available! While inter-domain route agreements show precedent for building a robust network out of pairwise relationships, might this particular class of agreement also work because it happens to be a "small world" where failures are obvious? That is, the set of major AS operators is small enough that all the major players know one another (since ICANN) maintains a centralized list of who owns which AS number), and bogus route announcements are easy for an AS operator to detect since they coincides with floods of angry tech support calls asking why www.foo.com no longer loads (or loads www.bar.com instead). By contrast, it seems that Stellar is geared towards environments with neither of these properties--large worlds with hard-to-notice failure modes. I ask because I'd love to hear your thoughts on how to select quorum slices when considering the political and economic incentives that might influence which node operators I choose to trust. Specifically, do you foresee the emergence of a small set of big-player node operators that application developers almost universally (and blindly) select for their programs' quorum sets, like how web browsers and OEMs regard CA operators today? How can Stellar help users do better than blindly trusting a small set of operators? I'm assuming that the fact that big-player node operators must nevertheless externalize the same slot values in order to enjoy liveliness makes it easy for the application to automatically detect any equivocation? If so, how would nodes be deployed to resist DDoS attacks that try to break the vast majority of usres' quorum sets? I'm getting the impression that there's a missing precondition here that for a large-scale Stellar deployment to be successful, there must be a very diverse set of quorum sets. Thanks again!
- andrewstellar 12y ago
  Let's say there's 3 big "tier 1" operators, which everyone trusts. This means that if 2/3 colluded to defraud the system, they could. Then, a smaller non-profit or more "trustworthy" node comes online and says, hey everybody, add me to your quorum slice. I'll listen to these big operators and make sure they're honest, and you can listen to me to verify that. Now, regular nodes add the non profit node to each of their 2 member set slices. If one of the bigger guys colludes, the system is only blocked, because now the regular stellar users have depended on the non-profit node in each stellar slice, who has seen the collusion and isn't externalizing bogus transactions. Once the collusion is published by the whistle blower node, regular stellar nodes can remove those slices that contained the bad node, and the system moves forward. Now this is a completely contrived example but you can generalize it as a chain of trust webs, where i listen to the someone, someone listens to me and the person i listen to, and so on.

wmf 12y ago

The attackers' 100 nodes might of course diverge if they are so configured, but nobody will care. The person who is being attacked cares, right? Is there a way for a Stellar node to realize that it has been partitioned from the real network?

mazieres 12y ago
Yes, and this is kind of the whole point of the protocol. It just hinges on defining the real stellar network. An analogous question is, "Is there a way for a computer to realize it has been partitioned from the real Internet?" Well, sure. Pick 50 web sites you think are really important--maybe a bunch from Alexa, plus your bank, employer, etc.--and make sure you can reach the vast majority of them (using https, of course, so no one can impersonate them). There's one sense in which FBA is stronger than the Internet analogy, however, it that is is actually testing transitive reachability. So instead of just making sure you can talk to those 50 web sites, you actually make sure all of those 50 web sites can talk to all the sites they consider important, and so on, until you get the transitive closure, which is basically the notion of an FBA quorum.
- lectrick 12y ago
  > you actually make sure all of those 50 web sites can talk to all the sites they consider important This requires you to trust the 50, correct?
  - mazieres 12y ago
    Well for safety it's a logical AND, not an OR. But for liveness you'd most likely you'd have some threshold. For example, you might that at least 34 of the 50 are honest.

nullc 12y ago

> are public Ah. What mechanism assures this consistency of this information? > at one node might or might not be a problem How could it not be a problem? If that is the totality of the network, and the network is 1-fault tolerant, what prevents spontaneous divergence of the state? > most likely cause of such a topology is a Sybil attack "likely"? It's not clear what you mean there. What statistical model have you adopted that allows you to reason about the likelihood of various topologies? Social networks usually appear to have small word behavior where its usually very easy to draw lines that describe disjoint local-majorities (or fairly large local-super-majorities). I agree that a sybil sticking on a bunch on a bunch of extra 'nodes' and the sybil nodes diverging as a result isn't interesting case. What I do think is interesting is what mechanism will prevent user's honestly stated trust (much less politically manipulated trust) being a bad topology? What is the procedure that I can follow, that if everyone else follows it, results in the correct global behavior (with high probability)? What are the additional assumptions required to achieve that and make it secure? Why are they plausible? Do they provide decentralization? (I can suggest on procedure which works: Stellar tells everyone who to trust; but it completely fails at decentralization so I assume that isn't the goal.) In Bitcoin our security assumption is that the computational majority of participants conform to the protocol ('are honest') and these participants are not completely partitioned from each other. People can then think about-- or debate-- how reasonable those assumptions are. (There are alternative formulations of Bitcoin's security which also argue about how plausible these assumptions are given economic incentive assumptions; but even this most simple set of assumptions gives people something easy to reason about.) Can you give a parallel (informally stated, but equally comprehensive) version of the security assumptions for your consensus system? > But there is certainly precedent for building a robust network out of pairwise relationships, namely inter-domain routing on the Internet. The Internet is _wildly_ inconsistent. Asymmetric routing is the norm, the internet frequently suffers small partitioning and loops; single malicious parties at the edge can frequently inject bad state that is accepted globally, congestion and blocking happens multiple hops away from users where they have no recourse. The internet is not a consensus system, and these issues are not usually hugely problematic; someones brokenness doesn't involve your traffic generally effect you, you can route around problems locally. Ephemeral routing and ledgers are fairly different problems. Ambiguity about the ownership of a coin eventually effects almost everyone. I'm not seeing the connection you're making there. I certainly agree that useful systems can be built from pairwise relationships: The original ripple design for pure IOUs without creating its own cryptocurrency prior to opencoin buying the ripple name was such a system, it had no need for a global consensus (except perhaps in certain atomic unwind cases)-- only the participants in a particular IOu transfer needed to be involved. It is not at all clear to me that a safe global consensus system can be built from pairwise trust.

jude- 12y ago

Hello Dr. Mazieres, thank you for making the Stellar whitepaper available! While inter-domain route agreements show precedent for building a robust network out of pairwise relationships, might this particular class of agreement also work because it happens to be a "small world" where failures are obvious? That is, the set of major AS operators is small enough that all the major players know one another (since ICANN) maintains a centralized list of who owns which AS number), and bogus route announcements are easy for an AS operator to detect since they coincides with floods of angry tech support calls asking why www.foo.com no longer loads (or loads www.bar.com instead). By contrast, it seems that Stellar is geared towards environments with neither of these properties--large worlds with hard-to-notice failure modes. I ask because I'd love to hear your thoughts on how to select quorum slices when considering the political and economic incentives that might influence which node operators I choose to trust. Specifically, do you foresee the emergence of a small set of big-player node operators that application developers almost universally (and blindly) select for their programs' quorum sets, like how web browsers and OEMs regard CA operators today? How can Stellar help users do better than blindly trusting a small set of operators? I'm assuming that the fact that big-player node operators must nevertheless externalize the same slot values in order to enjoy liveliness makes it easy for the application to automatically detect any equivocation? If so, how would nodes be deployed to resist DDoS attacks that try to break the vast majority of usres' quorum sets? I'm getting the impression that there's a missing precondition here that for a large-scale Stellar deployment to be successful, there must be a very diverse set of quorum sets. Thanks again!

andrewstellar 12y ago
Let's say there's 3 big "tier 1" operators, which everyone trusts. This means that if 2/3 colluded to defraud the system, they could. Then, a smaller non-profit or more "trustworthy" node comes online and says, hey everybody, add me to your quorum slice. I'll listen to these big operators and make sure they're honest, and you can listen to me to verify that. Now, regular nodes add the non profit node to each of their 2 member set slices. If one of the bigger guys colludes, the system is only blocked, because now the regular stellar users have depended on the non-profit node in each stellar slice, who has seen the collusion and isn't externalizing bogus transactions. Once the collusion is published by the whistle blower node, regular stellar nodes can remove those slices that contained the bad node, and the system moves forward. Now this is a completely contrived example but you can generalize it as a chain of trust webs, where i listen to the someone, someone listens to me and the person i listen to, and so on.