Open msbrogli opened 4 years ago
obiyankenobi
commented
4 years ago One other thing we want to test on the performance side is the impact of conflicting txs, as it means more work for the consensus mechanism. So we should test without and with conflicts.
pedroferreira1
commented
4 years ago I think the modules are all covered in the design. Maybe we should execute some tests with and without the indexes. I don't know the impact that they have when they need to be updated every time. One of the indexes we use in the p2p module but the others are only for API.
jansegre
commented
1 month ago The life time of a transaction has changed significantly, but a performance analysis would still be useful.
The Life of a Transaction
A new transaction or block usually goes through the following steps after it is received by the full node.
Check whether the transaction is valid
A transaction is valid it is follows a set of pre-defined rules split into three types: (i) Structure, (ii) DAG, and (iii) Network. These rules are different for blocks and transactions.
The Structure rules are related to the basic formation of the transaction. This verification can be done independently of other transactions.
The DAG rules are related to the placement of the transaction in the DAG. It includes the verification of the balance of funds and the scripts. This verification depends on other transactions, thus it must have access to the storage.
The Network rules are related to the network the transaction was sent to. It includes the verification of the minimum weight and the block reward.
Both structure and network validation step can be safely distributed to concurrent processes. But DAG validation cannot. The DAG validation requires access to all parents and inputs of a transaction, and some of them may be still processing.
Add the transaction to the storage with a default metadata
The transaction and its metadata are saved according to the storage. While the transaction itself is immutable, its metadata can be updated anytime.
It also updates all indexes used by the full node. This operation must be atomic and can run in parallel as long as the transactions being added are independent.
Even though adding to the storage can be distributed to concurrent processes, the indexes must be update following the timestamp order.
Run the consensus algorithm
As the transaction is valid and has been successfully added to the storage, the consensus algorithm is run to set whether the transaction is either executed or voided.
The consensus algorithm is different for blocks and transactions.
Propagate to other peers in the p2p network
The transaction is only propagated to synced peers.
Fire an event in the internal pubsub of the full node
This event is subscribed by the modules to do specific things. For example, the websocket sends a message to wallets to update their balances after a new transaction has arrived.
Performance Measure
We should measure the performance of each step in The Life of a Transaction. The slowest part will set the number of transactions per second that a full node can process. We should confirm it running a global test.
The tests must be executed separately for blocks and transactions. Transaction tests can also be split between with and without conflicts. The conflicts should only affect the consensus step because all other steps just ignore it.
We are interested into the following metrics for each test: CPU Use, Memory Use, Time Complexity, and Memory Complexity. These metrics covers both real and theoretical measures.
The tests must be available to be executed anytime. It should report the configuration of the computer where it was executed.
Initially, we will focus exclusively on tests that may require the span of many instances in AWS.
Transaction Validation Tests
These tests should create random transactions and check how long ... (TBC)
Storage Tests
It includes sub-tests for updating and querying indexes.
Consensus Tests
P2P Propagation tests