Paxos is a fault tolerant distributed consensus algorithm. Are there any blockchain frameworks which follows paxos algorithm for adding blocks to the blockchain.
Blockchain's consensus algorithms are used to keep malicious nodes from causing harm to the chain, it is a paranoid approach assuming everyone is malicious. These algorithms fall under the Byzantine fault tolerance scope.
On the other hand, Paxos in distributed computing is more trusting; when a master node goes down, the others will vote a new master node. A malicious node, or set of nodes, during this process could keep jumping in corrupting the election essentially halting the process. And if the malicious nodes become the master... then what?
There does exist a hybrid, but for the scale of a Blockchain, it could not keep up.
TLDR; None that I know of, and above is the reason.
Paxos (and Raft) is designed to be used as consensus algorithm in a more trusted environment where we expect nodes to not go rouge or in short it's not Byzantine fault-tolerant; Paxos in only partition-tolerant. Most of the blockchain implementations (like cryptocurrencies) run publicly (in a non-trusted environment) to bring consensus among all participating nodes. Achieving consensus in a public environment is a completely different and difficult problem.
In a public environment, nodes join and leave the network at their will. Also, hackers can exploit and manipulate the consensus by spanning multiple virtual nodes and corrupting the current state.
So Paxos can't be used to achieve consensus in blockchain.
Related
I cannot find any good explanation about these 2 statements about reorg:
1.Reorgs can increase the number of nodes within a blockchain over time, causing a poorer user experience.
Why reorg increases the number of nodes?
2.When reorging becomes more common, attackers only need to beat a portion of honest miners (due to the “longest chain rule”) rather than all of them.
Why is this so?
1.Reorgs can increase the number of nodes within a blockchain over time, causing a poorer user experience.
It doesn't. The statement doesn't make sense. Likely the source you are citing is incorrect.
2.When reorging becomes more common, attackers only need to beat a portion of honest miners (due to the “longest chain rule”) rather than all of them.
Ethereum doesn't have the longest chain rule, but the heaviest chain rule, so this statement needs to be rewritten for Ethereum. Thus, this rule is probably about Bitcoin and other proof-of-work chains that rely on longest chain rule. However, without context, it is not good to have security related discussion.
I am trying to figure out how PBFT consensus algorithm deals with the problem of double spending. I've read lots of literature but cannot seem to find an answer
pbft is a consensus algorithm given by Barbara Liskov and Miguel Castro in 1999 in order to prevent malicious attacks as malicious attacks and
software errors can cause faulty nodes to exhibit Byzantine (i.e., arbitrary) behavior. pBFT was designed to work efficiently in asynchronous systems as compared to previous bft algorithms which only worked on synchronous systems.
here is the research paper which states that
Practical algorithm for state machine replication that tolerates
Byzantine faults. The algorithm offers both liveness and safety
provided at most ⌊n-1 / 3⌋ out of a total of replicas are
simultaneously faulty. This means that clients eventually receive
replies to their requests and those replies are correct according to
linearizability. The algorithm works in asynchronous systems like the
Internet and it incorporates important optimizations that enable it to
perform efficiently
Double-spending is a potential flaw in a digital or electronic cash scheme in which the same single digital token can be spent more than once. Unlike physical cash, a digital token consists of a digital file that can be duplicated or falsified.
A double-spending attack is a potential attack against cryptocurrencies that has happened to several cryptocurrencies, e.g. due to the 51% attack.
But this problem can be prevented using consensus algorithms and blockchain
If two transactions attempt to spend the same tokens, each node will consider the first transaction it sees to be valid, and the other invalid. Once the
nodes disagree, there is no way to determine true balances, as each node's observations are considered equally valid , a way to bring the nodes back in sync is using consensus algorithms and with blockchain the transactions in this system are never technically "final" as a conflicting chain of blocks can always outgrow the current canonical chain, however as blocks are built on top of a transactions, it becomes increasingly unlikely/costly for another chain to overtake it and hence preventing the double spending problem.
The first step in PBFT is to get 2f + 1 nodes to agree to execute available transactions in the same order. This is done by routing all transactions through a Primary node which assigns a sequence number. All nodes that execute the transactions in the same order will reject the second spend. Since, at most f nodes can be faulty, this means that at least 2f + 1 - f = f + 1 nodes will accept the 1st spend and reject the second. When the client learns that f + 1 nodes have accepted the first spend, it can be certain that is the consensus, since at least 1 of those nodes is non-faulty.
In this article the author talks about data reliability: blocks are duplicated among the datanodes to ensure that data is preserved when a node crashes. I do understand the concept, but what would make a node crash ? Does this happen very often in practice ?
hdfs uses commodity hardware i.e nodes are built upon cheap hardware to decrease the overall cost.
Keeping this in mind blocks are duplicated.
I'm learning about the different Hyperledger based blockchain-frameworks and currently I'm reading about Sawtooth even though the question is not particularly related with Sawtooth.
Given that PoET is as good consensus algorithm as any, what I can't get my head around is what is the benefit of having a blockchain network which is not fault tolerance.
Not only for financial operations but for anything of value, even if there is not a targeted attack, if we have a node which is not working correctly, and this node "wins the lottery" and is the node to insert the next block, what is the mechanism (before or after this) to prevent the system from proceeding with a wrong state?
And if indeed Not a fault tolerant means exactly this, there could be a faulty behavior and it won't be detected, what is the purpose of using such a system even if it's fast and scalable and so on if there is good chance to end up with an incorrect data at the end?
I'm not trying to imply that those network are useless, on the contrary, I'm trying to get a grasp on the ideas behind blockchain and the different variations there are, and because I'm sure there is a good reason for Sawtooth to exist I would like to find out where my logic fails.
Question talks about Fault Tolerance in general. However the description in the question is oriented in a way to talk about Byzantine Fault Tolerance.
Broadly we can classify Byzantine Fault Tolerance and Crash Fault Tolerance. Byzantine behavior is the unexpected scenario arising because of the node, unpredictable result from the node, it could be intentional (malicious act from a node) or unintentional (machine's memory corruption/hardware issues). Crash fault tolerance is the high availability of the system, though there can be random node failures in the network.
There's a general misconception that a Blockchain system should always be Byzantine Fault Tolerant. There can be multiple use cases for the Blockchain system. Choosing what to achieve through Blockchain is thus use case specific.
For example, in most public networks where there's incentive involved for creating a block in the network and there's no established trust or no means of establishing trust among the participants. A consensus algorithm which provides the Byzantine Fault Tolerance may be opt over there.
Another use case for the Blockchain is its immutability property, i.e. when a data/state is added to the Blockchain it becomes highly computationally difficult to modify it. In case of private Blockchain consortium, participants may optionally prove their identity to the other nodes upon request through some other means and immutability property could be of interest to them. It may not matter who wins the election or who creates a block. To give you an instance, in case of Hyperledger Sawtooth with Raft as a consensus engine, leader gets a chance to create a block always. Raft provides Crash Fault Tolerance in the network as long as majority (50%+1) of the nodes are alive.
Hyperledger Sawtooth PoET when run on SGX is Byzantine Fault Tolerant and gives all the nodes a fair random chance to construct the block. In case if PoET is run in Simulator mode then it only gives the latter capability. The protection for Byzantine behavior is coming from the Trusted Execution Environment (TEE) like Intel SGX.
Note: Blockchain systems are designed so that participants get chance to validate blocks created by the winning node. They add the block to their ledger only after validation. In case of consortium a node will be caught if tries to manipulate and because there can be other means of identifying who is the participant, Byzantine behavior can be caught.
A Blockchain is a distributed design solution, by virtue of its design it provides at the least Crash Fault Tolerance for the system as a whole. Since the same copy of data is replicated across the nodes (at least more than one node), the data is not lost even if there's a failure of one or two nodes in the network. High availability is guaranteed.
I hope these points helped you to move next in your exploration.
I have a basic blockchain I wrote to explore and learn more about the technology. The only real world experience I have with them is in a one-to-one transaction from client to server, as a record of transactions. I'm interested in distributed blockchains now.
In its simplest, most theoretical form, how is consensus managed? How do peers know to begin writing transactions on the next block? You have to know when >50% of the entire pool has accepted some last block written. But p2p systems can be essentially unbounded, and you can't trust a third party to handle surety, so how is this accomplished?
edit: I now know roughly how bitcoin handles consensus:
The consensus determines the accepted blockchain. The typical rule of "longest valid chain first" ensures that only one variant is accepted. People may accept a blockchain after any number of confirmations, typically 6 is sufficient to ensure a clear winner.
However, this seems like a slow and least-deliberate method. It ensures that there is a certain amount of wasted work on the part of nodes that happen to be in a part of the network that had a local valid solution at roughly the same time as a generally accepted solution.
Are there better alternatives?
Interesting question. I would say the blockchain technology solves only probabilistic consensus. With a certain confidence, the blockchain-network agrees on something.
Viewing blockchain as a distributed system we can say that the state of blockchain is distributed: the blockchain is kept as a whole but there are many distributed replicas of local copies. More interestingly, the operations are distributed: Writes or reads can happen at different nodes concurrently. Read operations can be done locally at the local copy of the blockchain, but this read can of course be stale if your local copy is not up-to-date, however there is always an incentive for nodes in the blockchain network to keep their local copy up-to-date so that they can complete new transactions when necessary.
Write operations is the tricky part here, that blockchain must solve. As writes happen concurrently in a distributed fashion, blockchain must ensure to avoid inconsistencies such as double spending and somehow reach consensus on the current state. The way blockchain does this is probabilistic, first of all they made it expensive to write to the chain by adding the "puzzle" to be solved, reducing the probability that different distributed writes happen concurrently, but they can still happen, but with lower probability. In addition, as there is an incentive for nodes in the network to keep their state up to date, nodes that received the flooded write operation will validate it and accept that operation into their chain. I think the incentive to always keep the chain up-to-date is key here because that ensures that the chain will make progress. I.e a writer has a clear incentive to keep its chain up-to-date since it will be competing with the "longest-chain-first" principle against other concurrent writers. For non-adversarial miners there is also an incentive to interrupt the current mining, accept a new write-block and restart the mining process, ensuring a sort of liveness in the system.
So blockchain relies on probabilistic consensus, what is the probability then? The probability that two exactly equal branches growing in parallel at the same time is close to 0 assuming that there are not any large group of adversarial nodes taking over the network. With very high probability one branch will be longer than the other and be accepted and the network reach consensus on that branch and write operations in the shorter branch have to be re-tried. The big concern is of course big adversarial miner groups who might deliberately try to create forks in the blockchain to perform double spending attacks.. but that is only likely to succeed if they get close to 50% of the computational power in the network.
So to conclude: natural branching in blockchain that can happen due to probabilistic reasons of concurrent writes (probability reduced due to the puzzle-solving) will with almost 100% probability converge to a single branch as write operations continue to happen, and the network reaches consensus on a single branch.
However, this seems like a slow and least-deliberate method. It
ensures that there is a certain amount of wasted work on the part of
nodes that happen to be in a part of the network that had a local
valid solution at roughly the same time as a generally accepted
solution.
Are there better alternatives?
Not that I can think of, there would be many more efficient solutions if all peers in the system "were under control" and you could make them follow some protocol and perhaps have a designated leader to tell the order of writes and ensure consensus, but that is not possible in a decentralized open system.
In the permissioned blockchain environment, where the participants are known in advance, client can get cryptographic proof of the consensus (e.g. that it was signed at least by 2/3 of the participants) and to verify it. Usually it can be achieved using threshold signatures.
In the public blockchains, AFAIK, there is no way to do this since the number of participants is unknown/changes all the time.