Blockchain Performance metrics

Below are summarized basic notes.
Feel free to communicate by bulent.yucesoy@gmail.com

-------------------

"transaction latency" = "confirmation time" - "submitting time"
			( trx is confirmed to be committed across the system, not per peer )
			( consensus algorithm and finality takes care here )

LATENCT is generally reported as AVERAGE
"average trx latency" = TOTAL OF ALL LATENCIES / TOTAL COMMITTED TRX COUNT

-------------------

"network size" = number of nodes participating in consensus or validation phases.
		 ( NOT number of all nodes )

"transaction throughput" = number of valid trx count among all peers.
			( does not include invalid trx count )
			( does not tell single peer performance but overall performance )
			( measured in TPS )

"blockchain work" = "transaction throughput" * "network size"

-------------------

transaction characteristics
 - transactions must model both its other transaction dependencies and data dependencies
 - computation load must not be so high for smart contracts
 - transactions must not be so large, it will increase network propagation times.

-------------------

network performance characteristics

- network model and topology is important.
  a network with less firewall may perform better for example.

  you can also examine below document for probable network topologies like MESH or HUB-and-SPOKE
  https://blogs.msdn.microsoft.com/azurecat/2017/12/15/designing-scalable-blockchain-networking-topology-in-azure/


- distance between nodes and network links
  nearer nodes may perform better. cloud solutions may be ideal than on-prem for this issue. 
  Many different companies use cloud from same service provider. service provider puts nodes as close as possible, maybe all in same data center etc?
  If implementing on-prem solutions, you may choose dedicated well-performing extranet VPN links for blockchain network.


-------------------

consensus protocol effects

 - A protocol with a “chain” communication pattern exhibits provably optimal throughput on a
LAN cluster with symmetric and homogeneous links, but degrades
badly on a wide-area, heterogeneous network. Furthermore,
external conditions such as load, network parameters, and actual
faults or attacks may vary over time in a given deployment. For
these reasons, BFT consensus should be inherently reconfigurable
and ideally adapt dynamically to a changing environment. Another
important aspect is to match the protocol’s trust assumption
to a given blockchain deployment scenario. Indeed, one may want to
replace BFT consensus with a protocol based on an alternative trust
model such as XFT , or a CFT protocol, such as Paxos/Raft
and ZooKeeper, or even a permissionless protocol.


- BFT protocols differ widely in their performance when deployed in
potentially adversarial environments 

-------------------

Peer-to-Peer communication protocol

Generally, Gossip or AMQP may be used for P2P communication.
you may prefer examining performance differences among these protocols

-------------------

Ledger Data Store DB Performance 

You may use any kind of Database to store Ledger.
Samples are LevelDB,CouchDB,Postgresql and many other more.
You may want to examine different DB alternatives to analyse your overall blockchain system performance.