Summary
We have been steadily gathering data on the performance of Proof-of-Coverage and are ready to release the PoC version 8 update. This update brings a few key bug fixes and enhancements detailed below.
Contents
-
Target filtering: With the introduction of hierarchical targeting we stopped checking whether the target Hotspot is actually eligible to be a target. This was largely done for performance improvements, however, we are re-introducing target filtering with PoC v8. We believe we have mitigated the performance drawbacks by limiting the target search space addressed in PoC v7. We know that there are Hotspots on the network which are not participating in any poc/reward activity for a variety reasons (offline, etc), and there is no reason to attempt to target or path through them.
-
Witness RSSI centrality metrics: As the network grows we have gathered enough data to make more conscientious decisions around which Hotspots to include to when creating PoC paths. In order to do this we split the witness histogram into two buckets, one being a "good" bucket the other being "bad". The probability of picking a witness as a next hop in the path is now governed by the ratio of good vs bad counts. We believe this to be a better approach rather than simply declaring a witness as bad by looking at RSSI values. The fact that RSSI alone is not a good enough metric to make such decisions hinders better paths, and as a result we plan on adding additional witness data collection to make better decisions going forward.
-
Address next hop randomness bug: Thanks to the community we identified a bug in the next hop selection algorithm where the random seed for target selection would conflict with the seed for the first subsequent hop when creating a path. We've addressed this bug by generating a random seed once for targeting, and propogating that through the target/pathing algorithm.
-
Fix extremely long next hops: We've introduced a new chain variable
poc_max_hop_cellswhich would limit how far away a potential next hop can be. It is defined in terms of h3 grid cells. -
Ensure new consensus members have latest block: We've added code to prevent slow block gossip holding up a new election round by trying to fast-forward all the new consensus group members to the same block.
-
Bump assumed valid block: We've also bumped the assumed valid block to 196777.
-
Adjust some peerbook gossip rules: We're trying some changes to peerbook gossip to try to keep peers fresher.
Chain Var Proposal
| Var | Existing | Proposed | Rationale |
|---|---|---|---|
| poc_version | 7 | 8 | Bump poc_version |
| poc_v4_prob_rssi_wt | 0.2 | 0.0 | Zeroed because centrality weight takes precedence with v8 |
| poc_v4_prob_time_wt | 0.2 | 0.0 | Zeroed because centrality weight takes precedence with v8 |
| poc_v4_prob_count_wt | 0.2 | 0.0 | Zeroed because centrality weight takes precedence with v8 |
| poc_v4_randomness_wt | 0.4 | 0.5 | Increased to still keep 50% chance of picking a random witness as next hop after filtering. |
| poc_centrality_wt | undefined | 0.5 | Introduced to pick potentially legitimate witnesses as next hops when constructing paths. |
| poc_max_hop_cells | undefined | 2000 | Introduced to limit max next hop distance. A rough estimate is given by: sqrt(3).a.(n-1), where, a: hex_edge_length and n: poc_max_hop_cells. For hexagons at resolution 12, ~32.5kms |
| poc_good_bucket_high | undefined | -80 | Upper bound for a good RSSI value |
| poc_good_bucket_low | undefined | -115 | Lower bound for a good RSSI value |
Related PRs
- blockchain-core#365: Support for PoC v8.
- miner#291: Miner side support for PoC V8.
- miner#319: Fast forward new consensus members to prevent slow block gossip.
- miner#320: Bump assumed valid block to 196777.
- libp2p#254: Store similar peers, add debugging to relcast exits
Plan
We've been betaing this release since Saturday morning and plan to release it go General Availibility this evening. We will then activate PoCv8 sometime Monday morning.