The launch and activation of PoC v4 introduced some interesting new paths and brought in much needed performance improvements. We have essentially quadrupled the number of challenges on the network as validation of PoC receipts is now significantly more efficient.

Since the activation of PoC v4 the community has been consistently providing feedback to make PoC challenges more random and fair. The new firmware 2019.12.16.0 attempts to address some of these issues. We also upgraded Erlang rocksdb to an upstream 1.1.0 version and bumped the assumed valid block to 138655.


With this update we attempt to solve:

Since each Hotspot maintains a histogram of the witnesses with the corresponding RSSI of witnessed packets, we can use the free space path loss formula to determine whether it’s impossible for two hotspots to have witnessed each other at those RSSI values. We will now filter these values out.

Secondly, we check whether the witness being considered for a potential next hop is actually an active Hotspot or not. If the Hotspot has not issued a challenge in the last 300 blocks it is considered inactive.

And finally, we added support for a chain variable for making the initial target selection more random. A breakdown of chain variables is described below.

We believe that witnesses which are too close to a challenged Hotspot should not gain any score, as these witnesses are often located in the same room or building as the Hotspot being challenged and not adding significant value to the network.

We also now ensure that RSSI values look reasonable and have added a check that the impossible RSSI values don’t dominate the overall RSSI values.

Since we can’t do a snapshot without committing, we do the next best thing and save the context state between old ledger height calls to the same height.

The ledger has two modes “active” and “delayed”. We ensure snapshots can only be taken from an “active” ledger.

Furthermore, when restoring a context cache we make sure the ledger is in delayed mode to prevent the context being installed onto the wrong subledger.

Floats are a necessarily evil and may cause a potential latent drift in the ledger view. Therefore we have normalized all the necessary floats introduced with PoC v4 and PoC v5.

We’ve added three comprehensive test suites to the miner to check for the above PoC v5 changes.

We’ve also improved how we assess PoC witness quality from blockchain-core so the API can do the same.

This builds on top of core#314 and ensures that verifiably inconsistent witnesses don’t get rewarded. We’ve added filters to check for two potential discrepancies:

  1. Check that the witness is sufficiently far from the Hotspot it witnessed. We believe this would discourage installing multiple Hotspots in vicinity and attempting to game the reward system.

  2. Since we collect the RSSI data in the ledger, we’ve also added a check for Free Space Path Loss for witness <-> challengee RSSI values.

This is to ensure that we correctly check the blockchain-core behavior in miner.

Chain variable proposal

Var Existing Proposed Rationale
poc_version 4 5 Update poc_version to 5
poc_v4_exclusion_cells 10 8 This will change min hop from ~433m to ~300m
poc_v4_prob_rssi_wt 0.3 0.0 Removed to compensate for poc_v4_randomness_wt
poc_v4_prob_time_wt 0.3 0.0 Removed to compensate for poc_v4_randomness_wt
poc_v4_prob_count_wt 0.3 0.0 Removed to compensate for poc_v4_randomness_wt
poc_v4_randomness_wt 0.1 1.0 Bias entirely towards picking a next hop witness randomly
poc_v4_target_prob_score_wt 0.8 0.0 Removed to compensate for poc_v5_target_prob_randomness_wt
poc_v4_target_prob_edge_wt 0.2 0.0 Removed to compensate for poc_v5_target_prob_randomness_wt
poc_v5_target_prob_randomness_wt undefined 1.0 Introduced to make target selection entirely random. Currently high scoring hotspots are always getting targeted, this causes a feedback loop where, high scoring will keep gaining score

Deployment Plan

We ran the beta overnight on Monday the 16th and marked it GA on Tuesday the 17th at 12 PM PST.