We want to simulate a network of up to 10,000 peers participating in peer to peer mining pool. We want to estimate what is the frequency of share generation we can support with such a large network such that minimal to no shares are dropped from the P2Poolv2 share chain.
P2Poolv2 runs a share chain of mined shares generated by miners participating in the network. These are replicated on to all miners' instance of P2Poolv2 node. The simplest solution here is to have a linear chain and drop any blocks that fail to arrive at all nodes in time to be included in the main chain. Such shares are called orphans and are not rewarded - this is the high level design used in the original P2Pool.
We want to support more work from miners by allowing Uncle blocks, an idea that was in use in Ethereum until the PoS fork. The P2Pool for XRP also uses uncle blocks - allowing up to a maximum of three uncles per block.
We want to explore how many peers can participate in the network with 3 or maybe even more uncles, given an fixed rate of share generation per peer.
We will make a number of assumptions when simulating the network. The simulation should focus on the chain, especially the generation of the uncles blocks and number of orphans generated. We will abstract away the communication layer, so we do not spend time simulating the gossip protocol or the communication failures. We abstract all that by adjusting the latency of a reliable broadcast across all the network.
We want to simulate a peer to peer network with peers broadcasting their shares to all other peers.
-
Generate shares from each node using the normal distribution over a time period. These shares are broadcast to all other peers using the latency requirements in 4.
-
Each share generated by a node should include back links to the tip of the most of work chains available at the node. The number of tips should be configurable. These tips are later developed in uncle blocks as the chain develops.
-
Use a graphing library, maybe the Boost BGL to build the chain/dag of shares at each peer. We want to instrument this graph to be able to measure the number of uncles and orphans. Our main result will be derived from this data.
-
Stick to C++ simulation, i.e. avoid the python simulation layer provided by ns3 to help us scale the network we can simulate.
-
Assume a configurable latency of the reliable broadcast. We can extend this to select a range here, where a single message is delivered to all other peers within a range of time, i.e. not all nodes receive a given message at the exact same time.
-
Assume all received shares are valid and can be immediately added to the chain/dag.
-
At the end of the simulation check that all nodes have a consistent graph up to a certain depth. The latest part of the graph will be inconsistent. This could potentially be another result, where to observe the depth required to reach consistency for a given network size and share frequency.