Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stellar Protocol: A Federated Model for Internet-Level Consensus (2016) [pdf]

stellar.org

Post reply on HN
Print view View original

51–60 of 66 posts

Re: Stellar Protocol: A Federated Model for Internet-Level Consensus (2016) [pdf]

#51

Post by grandmczeb »

edem wrote: post #44
suckmydang wrote: post #3

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

Can Stellars be mined? I received some before 2015 when they were giving it away for free. Now I'm happy that I can turn them into BTC and withdraw cash...

> Can Stellars be mined?

No.

Re: Stellar Protocol: A Federated Model for Internet-Level Consensus (2016) [pdf]

#52

Post by blunte »

bitcurious wrote: post #39

Where can one actually buy some? I have some BTC/LTC I'd like to trade for stellar but it seems all of the reputable exchanges that trade it are closed to new registrants. Any suggestions?

Bittrex has it, and that's where I've been buying it.

Re: Stellar Protocol: A Federated Model for Internet-Level Consensus (2016) [pdf]

#53

Post by mazieres »

neuronexmachina wrote: post #2

I 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…

To be more precise about this, the Ripple consensus paper (https://ripple.com/files/ripple_consensus_whitepaper.pdf) says in Section 3.3, "Since the UNLs for each server can be different, agreement is not inherently guaranteed by the correctness proof." This of course doesn't mean that Ripple is never safe if UNLs disagree. (A node's UNL in Ripple serves the same function as a node's quorum slices in SCP.) It just means that the analysis from Section 3.2 does not apply. SCP was designed to be decentralized in the sense that we assumed different nodes would want to chose different quorum slices and wanted to achieve the best possible safety for any such choice.

A particular concern with Ripple is what would happen if Ripple validators failed not by crashing, but by getting compromised and acting maliciously (so-called Byzantine failure). The Ripple paper states in Section 3.2 that "it would take (4n + 1)/5 Byzantine failures for an incorrect transaction to be confirmed" (where all nodes are assumed to have identical UNLs and n is the size of that UNL). I believe this is an error, as with a quorum size of 80% of n, it is easy to construct a counter-example. Suppose nodes v_1 and v_10 are honest, while v_2, ..., v_9 maliciously deviate from the protocol. Now consider the two 80% sets (v_1, ..., v_8) and (v_3, ..., v_10). Those two sets overlap at only malicious nodes that could prevent v_1 and v_10 from hearing about each other's transactions.

The nice thing about SCP is that it is optimally safe (Theorem 13 in the paper). That doesn't mean it guarantees safety under all possible configurations (e.g., two disjoint sets of nodes that don't know about each other). But it means that in any configuration where there exists some protocol that could guarantee safety, SCP will guarantee safety as well. That includes Byzantine failure scenarios. So you could translate UNLs into quorum slices and substitute SCP for Ripple's consensus algorithm, and if RPCA was already guaranteed safe, then SCP will be, too. The converse is not guaranteed; you could choose a configuration that is safe under SCP and risks forking under RPCA.

Re: Stellar Protocol: A Federated Model for Internet-Level Consensus (2016) [pdf]

#54

Post by econner »

bbayer wrote: post #15

Stellar is one of the robust and undervalued asset. It has great potential and I think this year we will see lots of intereting things built on top of Stellar.

But why should XLM have any value? Isn’t it just a means to transfer other things?

Re: Stellar Protocol: A Federated Model for Internet-Level Consensus (2016) [pdf]

#55

Post by mazieres »

jondubois wrote: post #36

When I read white papers, there is only one question I need answered and I feel that the Stellar whitepaper just dances around that question: Does the algorithm fundamentally require that every transaction have to eventually pass through every node in the network? The idea of quorum slices seems to imply 'no' but the whitepaper doesn't appear to make any attempt to connect the concept of quorum slices with actual tra…

Yes. Every validator in Stellar has a copy of the complete ledger. However, different validators may be authoritative for different types of token. Say bank_A runs a validator and issues digital dollars on Stellar, while bank_B runs a validator and issues digital euros on Stellar. Each validator will store both banks' token holdings and prevent double spends. However bank_A should offer to redeem its digital dollars for real currency only when the redemption transaction commits on its own validator, and similarly for bank_B.

Running a validator protects a token issuer against double redemptions, as might happen in a mining-based blockchain where anonymous miners fork the blockchain and thus create twice as many tokens. That's fine for pure crypto tokens, where you can create Ethereum [classic] or Bitcoin cash out of thin air. But if you were using colored coins or ERC20 tokens to represent claims on bank deposits, these forks would be a problem.

Re: Stellar Protocol: A Federated Model for Internet-Level Consensus (2016) [pdf]

#56

Post by mazieres »

narrator wrote: post #6

Leader 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…

What's interesting is that SCP implements consensus without electing a leader. There are, of course, numerous asynchronous protocols that do this, like Ben Or, Rabin, Mostéfaoui, and most recently HoneyBadger, but is rarer for synchronous protocols like SCP. However, it is necessary for SCP's setting, because if you don't even have agreement among nodes over what nodes do and don't exist in the system, how could you hope to elect a leader.

One way to view how SCP avoids leader election is to consider that it is effectively emulating the leader. SCP has two phases, a nomination and a balloting phase. The nomination phase is effectively like one or more instances of an asynchronous broadcast protocol (which don't require a leader since multiple nodes can choose to broadcast). The balloting phase is like Paxos, except that the value to propose is embedded in the ballot number so nodes don't require a leader to tell them what is being proposed--they can each emulate the leader themselves.

Re: Stellar Protocol: A Federated Model for Internet-Level Consensus (2016) [pdf]

#57

Post by hossbeast »

jcfrei wrote: post #23
nullstyle wrote: post #12

Earlier quoted context omitted.

Thanks for the kind words! (disclosure: I designed most of the API) We're not done yet. IMO it's still not easy enough to build great software on top of our work.

Are there future plans to add smart contracts (with a "Turing-complete" virtual machine) to Stellar? I think that the Stellar consensus protocol with its speed would be perfect for overcoming the current limitations of Ethereum.

Turing completeness is not a virtue in a smart contracts language.

Re: Stellar Protocol: A Federated Model for Internet-Level Consensus (2016) [pdf]

#58

Post by Neutrion »

cantrip wrote: post #8
neuronexmachina wrote: post #2

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

Your doubt is legit, afterall they may not be so different:

https://www.quora.com/Why-did-Jed-McCaleb-leave-Ripple-to-st...

Re: Stellar Protocol: A Federated Model for Internet-Level Consensus (2016) [pdf]

#59

Post by Torn »

runeks wrote: post #34

There’s a great, three year old HN thread about the Stellar protocol, starting with a critique by Gregory Maxwell ( nullc ) here: https://news.ycombinator.com/item?id=9342348

Stellar was re-written in 2015, so I suspect this critique will be of the legacy Ripple protocol

Re: Stellar Protocol: A Federated Model for Internet-Level Consensus (2016) [pdf]

#60

Post by nullstyle »

jcfrei wrote: post #23
nullstyle wrote: post #12

Earlier quoted context omitted.

Thanks for the kind words! (disclosure: I designed most of the API) We're not done yet. IMO it's still not easy enough to build great software on top of our work.

Are there future plans to add smart contracts (with a "Turing-complete" virtual machine) to Stellar? I think that the Stellar consensus protocol with its speed would be perfect for overcoming the current limitations of Ethereum.

Not so much concrete plans around smart contracts (that I know of); I would characterize stellar as having aspirations and some early stage work and research with the intentions of enabling smart contracts on top of stellar. For example, we've done some work on "simple contracts" as described here: https://www.stellar.org/blog/multisig-and-simple-contracts-s....

Rant Incoming:

I don't think building a turing-complete VM into stellar anytime soon is prudent. The work the ethereum folks have done is crazy impressive, and certainly it is beyond anything I myself could create, but IMO they are also too cavalier. I don't think we (programmers in general) have the collective smarts, wisdom, discipline, and ethical codes needed to build a safe "world computer" yet, and I don't think we've got a good grasp of the potential ramifications of an unsafe solution. I imagine there are many unknown unknowns to encounter as the world stumbles in the dark, greedily, from where we are today in the direction of skynet.

All that said, I'd really like to see a world with more decentralizing forces and where decentralized applications can more feasibly compete with centralized services. I think stellar can help make this happen one day. I'm sick of being forced to trust the googles and facebooks of the world with my personal data while not having viable alternatives, and I think one way to work towards breaking their outsized influence on humanity's digital culture is to enable and make accessible more decentralized interactions of increasing richness. Instead of building one turing-complete decentralized protocol to rule them all, I'd love to see us continue to develop a constellation of focused decentralized systems that we can consider/develop/verify/maintain in isolation first. Then, as our comfort with each system grows, we can work to carefully combine and layer them in increasingly useful ways. There's such a long way to go.

On a related note, IMO we too often think that what we're doing on a day to day basis is just computer science and don't often enough consider the social science-y aspects of our work. From how we structure our APIs to how we communicate with users about the responsibilities involved with participating in decentralized systems, we have tons of soft problems to overcome that can't easily be fed into a compiler or reasoned about formally to determine the quality of our solutions. For evidence, look at what occurred recently with the parity wallet/solidity or -- an example that hits closer to home for me -- the snafus around the account recovery system in stellar's original web client.

---

Please take the above with a grain of salt. I realize that the above isn't supported with citations and in the end I'm just some random fuckhead coder. I'm sure plenty of people here can point to why my thoughts on the subject are wrong and why ethereum is taking the correct approach to smart contracts; I don't pretend to be able to hang with the big brains of the cryptocurrency space.

All of the above is also not representative of stellar's official positions... these opinions are 100% my own.

Post reply on HN