It means we simply give two different nodes the same signing key and get them to sign conflicting proposals and votes. A more complicated Byzantine fault would take into consideration the structure of the underlying protocol to try to thwart consensus safety in a more intelligent way.
> And thanks to the protocols consensus rules your users can trust that for a transaction to go through your node and be accepted onto main net your node is a good actor.
Usually, you still have the “server is selectively lying” problem; unless the users are talking to each other, how do the consensus rules help with this?
In the context of consensus can't the attacker simply send invalid signatures to some participants and valid signatures to other participants thus preventing consensus?
> The obvious question for anything that claims to solve Byzantine consensus is: what about Sybil attacks?
Not really answering your question (which is answered elsewhere in the thread), but these things are independent in an interesting way. Sybil attacks, in the simplest sense, depend on running consensus across a group where you don't have trustworthy membership information. If you do, then it turns into an authentication problem, which is different. Sybil attacks are an attack on the protocol that controls jury membership (or authenticates jury members), rather than the consensus protocol itself.
Oh I think it was misunderstood. The full quote is: "Byzantine agreement guarantees distributed consensus despite the Byzantine failure of participants. However, it requires unanimous agreement on system membership by all participants. Each node in the network must be known and verified ahead of time." It is comparing SCP to Byzantine agreement protocols like paxos.
I think it's typically used when there's agreement on the list of nodes participating in the network. (The nodes can agree to change the list of participants, Lamport wrote about it in "Reconfiguring a State Machine".)*
With "blockchain" / proof of work, computing power substitutes for voting power: you pass state transitions by controlling a majority of the compute power rather than a majority of the voting power.
Have you seen "byzantine consensus" used in the second context (with proof of work) also?
(*) When I think of the Byzantine consensus problem, it's when:
- not every node has to vote in each round (so that the system can make progress even if some nodes fail);
- you can authenticate (e.g. with cryptography) that messages come from the appropriate sender (but not whether that sender is acting "honestly");
- the goal is to reach consensus, i.e., if any node concludes that some proposition (i.e. state transition) has passed, no nodes will ever agree on contradictory proposition.
> Consensus. Have _n_ nodes perform the same work (if it’s deterministic), and only accept (and pay) if all the nodes match - or at least the nodes that were part of the majority
> The consensus problem requires agreement among a number of processes (or agents) for a single data value. Some of the processes (agents) may fail or be unreliable in other ways, so consensus protocols must be fault tolerant or resilient. The processes must somehow put forth their candidate values, communicate with one another, and agree on a single consensus value.
This seems to me to be exactly what Bitcoin does, where the "value" is the sum of all facts asserted on the blockchain.
Malicious attacks are not the same as consensus failure.
Consensus requires agreement, malicious attacks are orthogonal, unless you're hypothesizing a malicious party introducing an intentionally incompatible node and a significant fraction of users switching to it.
A consensus algorithm is one that ensures that multiple independent actors come to agreement about anything. In a blockchain, multiple independent miners or validators need to come to agreement about which blocks have been committed.
A fault-tolerant consensus algorithm is a consensus algorithm that can tolerate failure of any nodes (e.g. miners or validators). By failure, I'm referring to fail-stop failures, where a miner or validator crashes or goes offline. The key metric for fault-tolerant consensus algorithms is the threshold for how many failures the system can tolerate. For example, Raft is a fault-tolerant consensus algorithm can tolerate up to 49.99% of node failures.
A Byzantine fault-tolerant consensus algorithm is a fault-tolerant consensus algorithm that can tolerate not just fail-stop failures, but arbitrary failures. For example, one or more nodes that get hacked by a malicious hacker might be coordinated to subvert consensus from within. Bitcoin is exciting because it can tolerate such attacks from within (e.g. any miner) to a significant degree. Tendermint is similar, except it doesn't require significant energy expenditure for its security.
Proof-of-Stake was a family of early consensus algorithms from cryptocurrency projects that don't use PoW mining. A lot of them are terrible and suffered from the "nothing at stake" problem. For a while, the Tendermint project had been using collateral bonds to ensure that there is actually "something at stake". But Tendermit is more general than that. You can have stake with collateral posted on-or-off-chain, or, you don't need to use collateral at all. It all depends on what you're trying to build.
If you want a standalone cryptocurrency blockchain, you'll want in-chain collateral with bond deposits. But different blockchains have different requirements, so posting collateral to put something at stake may not be one of them.
Personally I think we should just avoid the term "proof of stake".
Actually, we wrote the Ethereum virtual machine implementation that they're using. We're moving away from the EVM though, because the TMSP architecture allows for easier native-application development.
This is called delegated byzantine fault tolerance, and what blockchains like NEO and ARK use this, or a variation of it to provide consensus. Token holders basically "elect" the super nodes, and if any begin to act untrustworthy they are "voted out." I'm a fan of this consensus styles because blockchains become semi centralized over time. Maybe not in the technical full validating node way, but certainly politically centralized.
If you want a more theoretical review of byzantine consensus protocols, you need to read through the gossip-based protocol literature, in particular byzantine broadcast protocols[1], where consensus is just one powerful primitive among others.
A distributed consensus mechanism really isn't new, either. In fact, some mechanisms are as old as merkle trees. And even within the realm of consensus mechanisms, using BFT (https://en.wikipedia.org/wiki/Byzantine_fault) to achieve consensus is basically an 80's technology with a new spin on it. BFT isn't magical and brings its own set of problems - the most common is the relative simplicity of "majority" attacks.
reply