-
Notifications
You must be signed in to change notification settings - Fork 0
Transaction performance testing setup
These tests are purely for achieving consensus on transaction order and timestamps. They do not include the time to process transactions. For example, if every transaction is digitally signed, then a great deal of processing power might be needed to verify hundreds of thousands of digital signatures per second.
As with prior work, these tests are for achieving consensus on transaction order and timestamps, and assumes nodes are honest. They do not include the time to process transactions.
US East, US West, Canada, Sao Paulo, Japan, Australia, South Korea, and Germany.
Lowest: AWS t2.medium instances with two virtual CPUs, 4GB memory, and up to 1 Gbps network performance
Highest: AWS m4.4xlarge instances with 16 virtual CPUs, 64 GB memory, and up to 2 Gbps network performance
100-byte
On events-level, i.e. when a node receives a new event via the gossip-protocol.
Usually the python Client, but not sure if it is efficient enough, especially considering the transaction application including the signatures. To be compliant with other research papers, we might need to strip this down and modify a node to directly trigger these transactions.
Transactions per Second + Latency between nodes
Latency is measured as the average number of seconds from when a client first submits a transaction to a node until when the node knows the transaction’s consensus order and timestamp.
Small goal: 2 nodes, 250k TPS, <0.02 seconds latency
Big goal: 128 nodes, 500k TPS, <10 seconds latency
References: