🤝1.7. Consensus at Pirichain
In Pirichain, at least 80% of the validators and at least 50% of the core nodes are required to be approved. Apart from this situation, every action that will destabilize the system is reported to the servers, and the protocol to investigate the incompatible nodes is started.
Opportunities for companies to set up their own nodes in their locations are possible under certain conditions/contracts. 500.000 PIRI Coins are taken from companies as collateral. The contract is terminated if it is determined that the Byzantine fault tolerance is not complied with. Even if the contract is terminated, the guarantee is not paid back in the first year.
Performance Measurements
Since the queuing module will be activated in case of exceeding a certain traffic in the system, the load on the nodes remains constant after a certain value. This prevents the system from behaving inconsistently. The processor (CPU) undertakes the greatest load on the entire system. The reason is that there are many cryptographic operations. Since there are Process Queuing, Garbage Collector and Single Thread - Context Switch features on the ram, no bottleneck has been observed in 4 and a half million transaction records.
In tests on the system, a maximum of 190 thousand transactions were provided in one day. And 77% of them were retrieved and processed via queuing. During the recording of these transactions, it was observed that a maximum of 184 transactions joined a block period (10 seconds), and no inconsistency was observed in the number of transactions of the nodes.
Another situation expected from the system is the need to calculate the balances very quickly (maximum 150 ms). However, as the number of transactions in the system increases, the calculation time is expected to be delayed. As a result of the indexes added to the database, there is a slowdown of 400 ms after 600 thousand transactions. This delays the processes in very heavy traffic on the system, especially in data addition. In order to avoid this undesirable situation, there is a table on the server and nodes where only the balances are kept on the database side. Via this table, very fast transactions can be made. The flow chart showing the update process of this table is given in Figure 1.10.
Last updated
