EOS whitepaper walk-through: Consensus algorithm Section Three, aBFT and TaPoS.
This is Section Three of Part Three of the EOS whitepaper.
Last time we talked about how Block Producers and the role they play in the EOS ecosystem.
This time we'll go over some difficult to grasp concepts of EOS.
aBFT (asynchronous Byzantine Fault Tolerance.)
Byzantine Fault Tolerance simply means the need to ensure that consensus will be reached among the different nodes around the world, taking into the account that some nodes might act maliciously.
asynchronous adds a different dimension because not all network communication is instantaneous.
Read more here.
Transaction as Proof of Stake (TaPoS)
The EOS.IO software requires every transaction to include part of the hash of a recent block header. This hash serves two purposes:
1. prevents a replay of a transaction on forks that do not include the referenced block
2. signals the network that a particular user and their stake are on a specific fork.
Over time all users end up directly confirming the blockchain which makes it difficult to forge counterfeit chains as the counterfeit would not be able to migrate transactions from the legitimate chain.
When a user sends a transaction, he does so under the assumption that the chain he is currently on is the legitimate one. By having the user state this assumption explicitly through the inclusion of the most recent block header hash, it show the network that there currently isn't any forks, and that they are all operating on the same chain.
If a transaction is sent with a block-header that isn't recognized, then the transaction will be rejected, letting the user know that he might have be connected to a forked chain.
It would be impossible for a fraudulent chain replicate the transactions because that would be having access to all the private keys that were used to make the transaction and using those keys to sign transactions with the latest block header of the fraudulent chain.
Read more about Transaction as Proof-of-Stake here.