(https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md)
Link to Part 1: https://steemit.com/eos/@dcryptonight/dissecting-the-eos-io-technical-whitepaper-part-2
Hey guys! I'm new to EOS and I'm just getting up to speed with it. Part of my study of it is to dissect it section by section. I thought it might be helpful to other newcomers so they know where to look for the facts they're looking for. So here, I'm dissecting the whitepaper and posting it in this subreddit. I only read it an hour per day. I'll post my dissections here everyday I read about it, then compile everything when I've read it completely.
I hope this helps! :)
"The EOS.IO software introduces a new blockchain architecture designed to enable vertical and horizontal scaling of decentralized applications. This is achieved by creating an operating system-like construct upon which applications can be built. The software provides accounts, authentication, databases, asynchronous communication and the scheduling of applications across hundreds of CPU cores or clusters. The resulting technology is a blockchain architecture that scales to millions of transactions per second, eliminates user fees, and allows for quick and easy deployment of decentralized applications."
- This section just gives the readers a brief explanation of the blockchain
- examples of disrupting businesses
- brief reason why mass adoption is important
- a few reasons why free usage is required
- briefly cites the need for flexibility in enhancing applications with new features, and why the platform must be robust enough in fixing bugs
- explains why a good user experience is paramount for a blockchain application
- briefly describes what parallel performance means
- Explains what the Delegated Proof of Stake (DPOS) algorithm is
- Explains the voting system for producers
- Explains the system for producing blocks
- Gives a scenario of a fork happening
- Gives a scenario of double-production and removal of abusers
- Transaction of confirmation by 15 out of 21 block producers when a malicious block producer creates two or more forks
- Explains a scenario when users are on a minority fork and how transactions on the fork are confired
- Block header requirement for every transaction
- for preventing replay of a transaction on forks that do not include the reference block
- for signaling the network that a particular user and their stake are on a specific fork
