As you may have noticed, block times recently have regularly not been meeting their typical sixty second deadline with any regularity. You can read more about how we deal with slow block times and long elections here. In a recent post, we discussed a reduction in the rate of Proof of Coverage (PoC) challenges. While this seemed to briefly be effective, we quickly found ourselves back where we started with the growth of the network. While slowing the rate of challenge did have the intended effect, soon after we fixed a number of bugs and reissued a large number of location assertion transactions that had gotten lost, making the network even larger, and taking back most of the ground we had gained. While we were observing these changes, we have been working on a feature called hierarchical targeting. This pull requests and other related requests changes how the initial target of a PoC challenge. The initial target is the first step of a PoC challenge path. Previously, this Hotspot was selected from the entire list of hotspots. Somewhat obviously, this scales poorly as the network grows (recall, that while there are only a few thousand Hotspots at this point, they’re all running on relatively under-powered hardware). This code uses a new index that is built and maintained on disk of Hotspots that are relatively nearby each other (in H3 terms, they all share the same parent hex at resolution 5).
- Hierarchical Targeting: Don’t pull all Hotspots for every target selection and receipt validation. PRs core/318, miner/287
- Reduce Memory Usage: Another issue that we’ve been running into is Hotspot miners running out of memory and getting restarted by the linux OOM killer. These PRs start our efforts to make this happen less often: miner/286, libp2p/242, libp2p/243, libp2p/244
We’ll beta this release overnight, then GA in the morning on Friday, Jan 17. Once we’re satsfied that things are stable, we’ll commit a chain variable transaction setting
poc_target_hex_parent_res to 5 and
poc_version to 7.