Stellar Protocol: A Federated Model for Internet-Level Consensus (2016) [pdf]
1–10 of 66 posts
Re: Stellar Protocol: A Federated Model for Internet-Level Consensus (2016) [pdf]
#2I was curious about how this was different from Ripple's approach, I thought this was interesting:
> Generally, membership in Byzantine agreement systems is set by a central authority or closed negotiation. Prior attempts to decentralize admission have given up some of the benefits. One approach, taken by Ripple, is to publish a “starter” membership list that participants can edit for themselves, hoping people’s edits are either inconsequential or reproduced by an overwhelming fraction of participants. Unfortunately, because divergent lists invalidate safety guarantees [Schwartz et al. 2014], users are reluctant to edit the list in practice and a great deal of power ends up concentrated in the maintainer of the starter list. Another approach, taken by Tendermint [Kwon 2014], is to base membership on proof of stake. However, doing so once again ties trust to resource ownership. SCP is the first Byzantine agreement protocol to give each participant maximum freedom in choosing which combinations of other participants to trust.
Re: Stellar Protocol: A Federated Model for Internet-Level Consensus (2016) [pdf]
#3When Stellar's codebase was still just a fork of Ripple (entire codebase was completely re-written from scratch in 2015), it experienced many divergent forks of the network due to weaknesses in the Ripple consensus protocol. Those weaknesses have been eliminated in the new SCP described in this paper, but AFAIK Ripple still has these systemic problems. The new Stellar codebase is actually a joy to work with.
Re: Stellar Protocol: A Federated Model for Internet-Level Consensus (2016) [pdf]
#4I was curious about how this was different from Ripple's approach, I thought this was interesting: > Generally, membership in Byzantine agreement systems is set by a central authority or closed negotiation. Prior attempts to decentralize admission have given up some of the benefits. One approach, taken by Ripple, is to publish a “starter” membership list that participants can edit for themselves, hoping people’s edit…
Eli5 please ! ;-)
Re: Stellar Protocol: A Federated Model for Internet-Level Consensus (2016) [pdf]
#5When Stellar's codebase was still just a fork of Ripple (entire codebase was completely re-written from scratch in 2015), it experienced many divergent forks of the network due to weaknesses in the Ripple consensus protocol. Those weaknesses have been eliminated in the new SCP described in this paper, but AFAIK Ripple still has these systemic problems. The new Stellar codebase is actually a joy to work with.
I know their api is really nice and I was surprised how easy was to work with it, whether it is a test net or public.
Re: Stellar Protocol: A Federated Model for Internet-Level Consensus (2016) [pdf]
#6Leader election in distributed systems is still an unresolved problem AFAIK except for proof of work. The problem is what does the leader have to give up to be a leader? The economic value of being the leader must be balanced by the work to become the leader otherwise there is an opportunity for arbitrage. For instance, if the value of leadership is X and the cost to do a Sybil or other attack is X/10 the network will be eventually attacked that way.
Re: Stellar Protocol: A Federated Model for Internet-Level Consensus (2016) [pdf]
#7I was curious about how this was different from Ripple's approach, I thought this was interesting: > Generally, membership in Byzantine agreement systems is set by a central authority or closed negotiation. Prior attempts to decentralize admission have given up some of the benefits. One approach, taken by Ripple, is to publish a “starter” membership list that participants can edit for themselves, hoping people’s edit…
Eli5 please ! ;-)
In other words you can implement arbitrary dynamic trust, Opening up the possibility of arbitrary hierarchies, and much more efficient and robust mechanisms of establishing truth. Authorities could be designed arbitrarily and evolve on top of this core protocol. This so far sounds closer to tcp/ip foundation. Bitcoin would be more like Series of children with a dynamic system of never ending strings and Styrofoam cups.
I bet there is already CS research theory ready to apply to this design. (Easier said than done and I am just guessing really).
Re: Stellar Protocol: A Federated Model for Internet-Level Consensus (2016) [pdf]
#8I was curious about how this was different from Ripple's approach, I thought this was interesting: > Generally, membership in Byzantine agreement systems is set by a central authority or closed negotiation. Prior attempts to decentralize admission have given up some of the benefits. One approach, taken by Ripple, is to publish a “starter” membership list that participants can edit for themselves, hoping people’s edit…
What part of this is interesting to you?
This paragraph does not explain how they are different from Ripple's approach only that they are in fact different.
Re: Stellar Protocol: A Federated Model for Internet-Level Consensus (2016) [pdf]
#9Leader election in distributed systems is still an unresolved problem AFAIK except for proof of work. The problem is what does the leader have to give up to be a leader? The economic value of being the leader must be balanced by the work to become the leader otherwise there is an opportunity for arbitrage. For instance, if the value of leadership is X and the cost to do a Sybil or other attack is X/10 the network wil…
You seem to use a very narrow definition of "distributed system" compared to most people. Could you explicitly state your assumptions? Your "distributed system" seems to coontain assumtions such as trustlessness and openness towards new participants. (No sybil attacks with fixed entities)
Re: Stellar Protocol: A Federated Model for Internet-Level Consensus (2016) [pdf]
#10Leader election in distributed systems is still an unresolved problem AFAIK except for proof of work. The problem is what does the leader have to give up to be a leader? The economic value of being the leader must be balanced by the work to become the leader otherwise there is an opportunity for arbitrage. For instance, if the value of leadership is X and the cost to do a Sybil or other attack is X/10 the network wil…
In distributed ledgers, it doesn't matter who the leader is. The system only has to ensure that leadership is distributed in such a way that it is statistically infeasible or economically unprofitable to rewrite history.
PoW distributes the leadership (block creation) via crypto puzzles. PoS tries to use economic incentives to make bad behavior more expensive than good.
There's work being done (which I personally believe is the right way to go) in using a leader election-based system that works like a lottery (Algorand[0] is an example). The basis of such a system is going to be the creation of non-biasable pseudo-random number generation.
Along these lines one of the more intriguing projects is called RandHound[1]. It's a way of creating distributed randomness (according to the paper's title). I think chains secured via lottery leader selection protocol has more promise than PoS.
Edit: for clarity
A lottery-based system works because the "winning numbers" (imagine a winner being a node whose public key when XOR'd with the winning number is below a certain value) are known to all (a protocol like randhound ensures that all nodes know the winning number). A winner's bundle of transactions are validated as his/her's by cryptograpic signature (which can be verified using the same public key that is used to confirm this person is truly a winner). Those are the broad strokes. Obviously there's a lot more to getting it to work. I've been working on it for months and still haven't gotten around to putting it down on paper.