EOS uses a delegated proof-of-stake system where 21 block producers verify transactions and add them to the blockchain. This architecture is meant to improve scalability compared to other blockchains, but it introduces several issues. EOS relies on an in-memory database called Chainbase that runs on the block producer servers, making it vulnerable to malware or data loss. The small number of block producers needed for consensus could allow for cartel-like behavior. And issues have emerged with transaction mutability, hacker blacklist replication, and full node data replication that undermine the security of the blockchain. Overall, the document argues that EOS's mainnet implementation appears rushed and bug-prone due to its unconventional design choices around scal

1. WHAT the hell is
wrong with EOS?
Updated from “Why EOS is not blockchain?”
3 March, 2019

2. EOS Mainent Architecture
21 Block Producers
EOS User
Block Producer
Candidates
21st
Block Producer
1st Block
Producer
Candidate

3. Update 1-8
Update
1-1
Update 1-2
Update 1-3
Update 1-4
Update 1-5
Update 1-6
Update 1-7
Update
The Scalability of Blockchain vs. Client Server System

4. Sharding
Raden
Netw
ork
ZK-SNARKS
POW → POS
Sidechain
Ethereum response to its scalability problem

5. Shrinks Consensus to 21 Block Producer
EOS response to blockchain scalability problem

6. Overview of EOS System Architecture
Source: Whiteblock, https://cdn0.tnwcdn.com/wp-content/blogs.dir/1/files/2018/11/EOS_Report.pdf

7. Chainbase
Cryptographically and directly verifying transaction on EOS mainet
Updating blockchain Verifying Transaction
How EOS BP verifies & updates transaction by Whiteblock

8. CPU
Checkpoint files Transaction Log files
Something similar to how EOS BP verifies & updates transaction
Directly-
Linked or
Memory-
Resident
Application
DatabaseAdapters
SERVER
Source: Oracle, Adapted from Oracle Timesten

9. Where in the world is this EOS “Chainbase” located?
Checkpoint files Transaction Log files
Directly-
Linked or
Memory-
Resident
Application
Chainbase
Block Producer
Server requirements
1. Expected location of servers
2. Type of servers (cloud, bare metal, etc)
3. Scaling plan for hardware

10. Core Layer
The block producing layer and the heart of the
operation.
The highest priorities are security and
connectivity to other block producing nodes.
Our goal is to utilize both bare metal for block
production and multiple cloud providers to
accomplish a mix of full control and quick
scalability.
- 80 GBs - 3 TBs of RAM (as needed)
- 4-8 vCPUs
- 1 TB of SSD Storage
RAM matters to BPs of EOS!
Source: https://www.eosnewyork.io/tech
Signing Node Producing Node Storage

11. Where this in-memory DB is usually used
● High Frequency Trading
● Derivative trading
● Real time billing
● EOS DApp….
This is why RAM matters to EOS!

12. Vulnerability of in-memory DB
● RAM resident VIRUS, Malware and such
CPU
Directly-
Linked or
Memory-
Resident
Application

13. BP tends to form a Cartel for Capacity Planning

14. EOS transactions are mutable with In-Memory DB
Checkpoint files Transaction Log files
Directly-
Linked or
Memory-
Resident
Application
Chainbase
21 Block Producer Servers

15. EOS Hacking from Hacker Blacklist replication flaw
21 Block Producers
EOS User
Block Producer
Candidates
21st BP
1st BP
Candidate
Outdated
Hacker list
Uptodate
Hacker list
Source:https://breakermag.com/heres-how-the-
2-09-million-eos-hack-really-happened/

16. EOS Full node Block Producer replication Issue
21 Block Producers
EOS User
Block Producer
Candidates
5 Full node
Block Producers
4TB
Transaction
dataSource:https://www.newsbtc.com/2019/02/27/e
os-blockchain-scaling/

17. EOS is assumed to be 4 BP server cluster client-server system
21 Block Producers
EOS User
Block Producer
Candidates
5 Full node
Block Producers
4TB
Transaction
data

18. EOS blockchain data size issue
● Assumed recent average EOS transaction speed = 2,000 TPS
Source: https://cryptocurrencynews.com/eos-breaks-transaction-time-record
https://cryptodaily.co.uk/2019/01/35-improvement-for-eos-transaction-speed
● Assumed average EOS transaction record size = 100 bytes (EOS transaction does not have known
transaction size limit but must be executed within 30 ms. The average size here is an assumption)
Source: https://eosio.stackexchange.com/questions/1710/size-limit-for-transaction-data
● Per second transaction size = 2,000 x 100 bytes = 200,000 bytes = 0.2 Megabytes
● Per day transaction size = 0.2 Megabytes x 86,400 seconds = 17,280 Mbytes = 17.28 Gigabytes
● Per year transaction size = 17.28 Gigabytes x 365 = 6,310,850 Gigabytes = 6,310.85 Terabytes
The more EOS gets users(dApps) it is destined
to get exploded.

19. Conclusion: EOS mainent seems to be made hasty and buggy