# The New CAP Theorem on Blockchain Consensus Systems
## 5 Discussion
### Empirical Validation Through Real-World Data  
Here we consider and compare the Bitcoin (PoW), the Ethereum 2.0 (PoS), the Hyperledger Fabric 3.0 (Raft, PBFT), and the IoT micro-Blockchain 1.0. It is noted that neither the actual per-transaction consumption values nor the scale of the Blockchain system affect the results and the conclusions of this work, and even though the findings of the empirical analysis fortify the universal validity of the theorem, the data are given here as a mere reference to the reader. In our reference system, i.e., the IoT micro-Blockchain 1.0 framework running on a setup of Arduino Nano 33 IoT devices for \(W=\frac{2N}{3}\), \(N=100\) and events' frequency \(\sim\)\(10^{-2}\) Hz, the recorded energy consumption per event witnessing is approximately 55 \(\upmu\)Wh., and the time needed for a single event to be processed is \(\sim\)16 ms. This considers the energy and the time required for one event block to be transmitted, validated, and stored in the IoT network. The benchmarks of the framework are given in detail in [8], while the technical specifications of the reference hardware can be found in [33]. Bitcoin and Ethereum 1.0 PoW Blockchains mandate \(W\approx N\). In these, every peer node acquires and validates every event and is expected to participate in the competitive new-event verification process [16]. At the time of writing, an average per-transaction consumption of \(\sim\)1.200 kWh is recorded in the Bitcoin Blockchain. The average per-transaction size in the network is \(\sim\)512 bytes and the network occupies a total of approximately 16.754 accessible full and pruned nodes [34]. These given, this yields an overall entropic performance (P) of the bitcoin network of approximately 7.4 \(\times\) 10\({}^{4}\) kbit/kWh. It corresponds to the data bits that are inserted into the entire bitcoin Blockchain per kWh of electricity consumed. Macroscopically seen, the overall entropy of the system is reduced by this amount for every kWh spent [14]. The Bitcoin Blockchain constitutes the most inefficient consensus approach in terms of entropy reduction per energy unit in our benchmark. PoS-based Ethereum 2.0 introduces a far more sophisticated node hierarchy, initially invoking \(\mathrm{W}=128\) verifiers per transactional event, ending up to \(W=\frac{2N}{3}\) of the total body of the validators for the event to be considered as finalized [17]. This approach realizes the pros of scalability and delivers a more efficient architecture in terms of entropy conversion. At the time of the writing, average per-transaction consumption of \(\sim\)0.03 kWh is recorded for processing and finalizing a single transaction of an average \(\sim\)256 Bytes size on the Ethereum 2.0 Blockchain network. The network occupies approximately 8.900 accessible full nodes. This yields an observable information entropic performance of \(4.5\times 10^{8}\) kbit/kwh. Compared to the Bitcoin, the Ethereum Blockchain appears to be rank \(10^{4}\) times more efficient. Macroscopically seen, the rigid requirement \"everyone knows everything at all times\" is relaxed. This corresponds to lower values of \(W\) and has a positive impact to the entropic Performance (P) of the system. Hyperledger Fabric 3.0 adopts a trusted-node policy. It empowers adaptable strategies, relying on a fixed leader-follower hierarchy. It can deploy various consensus policies, from the default Raft where \(W=\frac{N}{2}+1\), to Practical Byzantine Fault Tolerant with \(W=\frac{2N}{3}\), to total endorsement requiring \(W=N\)[18]. The energy consumption and consequently the efficiency of the system varies and is subject to each implementation. In Table 1 we considered the default Raft case. Please note that all the above are estimations based on macroscopic metrics of the networks at the time of the writing, susceptible to further in-depth analysis and refinement. Still, this falls out of the scope of this work and remains a subject for future work. The above considerations are summarized in Table 1 below.