The transaction time for PoS and PoW

[0xGhost]

Hi, I am trying to reproduce the result of the time-consuming between PoS and PoW. However, when I tried to run PoS experiments I found the transaction time increased significantly as the number of miner nodes increased.(5 miner=0.9s , 20 miners=3.5s , 50 miner=8.8s , 100 miners=17.8s) After I read the code I found the miner nodes need to send blocks to all other connected miner nodes. And this process takes a lot of time since in the real world this happens in parallel. Should I remove this time to get the same result on your slide?

[HamzaBaniata]

Dear user,

Thank you for your interest.

Indeed, since this is only a simulation process on a single machine, you can only simulate parallel processing up to the number of CPU cores you have on your machine. For this reason, you may have noticed that a simple FOR loop was used for selecting a miner and generating/broadcasting a new block. Note that this is not the case when you select the PoW consensus in which we developed an actual parallel approach. The results presented on the slides (and in the published paper) represent an average 'individual' BLOCK CONFIRMATION TIME, and not the total experiment time. Meaning that we collected the timestamp differences between consequent blocks once the simulation is done.

This issue also depends on the speed of your CPU, you can check the infrastructure specifications where we ran our experiments which are also provided in detail in the published paper.

If you have a better approach to simulate which gives more realistic (i.e. close to real parallel) measures, please indicate this and we would appreciate your input.

best of luck,

The Development Team.

[0xGhost]

Hi,

Thank you for your reply. I currently program to calculate the time only for the selected miner node. Now it works as expected. I add a bandwidth limit to generate network loading time for a more realistic simulation and found the gossip process actually rewrites the whole chain other than getting the different (latest) blocks. Is that the expected result for this simulator?

Thanks,
0xGhost

[HamzaBaniata]

Hi,

Well, if you think about it, gossiping checks if the length of local chain is equal to the length of neighbors' local chains. Once it is found longer, you can either rewrite the chain .. or implement a function that checks (and re-validates!!) a block-by-block until finding where the fork started. We actually decided to use the simpler first approach but thank you for indicating this! The reason why we chose that approach is our future intention to add adversary miner module to the simulator. Accordingly, we are planning to use FoBSim to check how important it is to have intelligent vs. dump gossiping, followed by some ideas on federated learning integrating. We may later try the second approach by modifying on the gossip protocol. If you would like to try this for yourself, you can modify on this function directly and kindly report your analysis (function: gossip, Module: miner.py).

best,

The Development Team.

[0xGhost]

Hi,

I am working on PoS results and currently disabled the gossip process. I think PoS does not need gossip since the validator is fixed.

Thanks,

0xGhost

[HamzaBaniata]

Hi,

The validator is NOT fixed but rather randomly selected per each block. You can fix it by modifying on the function: ' trigger_pos_miners' which you can find in the 'new_consensus_module.py'.

best,

The Development Team.