I’ve added a branch: GitHub - nanocurrency/nano-node at election_scheduler, which is the start of an election scheduler component that will replace how elections are currently started. This will allow a separation between the decision of which elections to prioritize and the mechanics of tallying elections. Encapsulating prioritization this way makes the scheduling decision process easier because the site requesting the election to be started doesn’t need to evaluate all other scheduling considerations.
Elections are currently started in the node by the following sources:
- Live blocks off the network
- Confirmed dependents - when the previous block, and on receives the send block in the link field, are confirmed, the successor to that previous block can be activated if already in the ledger
- Higher block difficulty block rescheduling - when higher work is published for an existing, unconfirmed block in the ledger which doesn’t already have an election
- Vote observation hinting - when a % of the voting weight is seen for an unconfirmed block in the ledger which doesn’t already have an election
- When requested through the block_confirm RPC command
With the new scheduler component in place, all these sources will feed to a central list of eligible elections so their prioritization can be more accurately compared across all elections. The aim of this approach is to provide better control over which elections are being started so one particular trigger doesn’t dominate the resources. The ultimate result should be better election alignment across the network.
This branch also contains the start of an election prioritization scheduler which will start elections based on a combination of the account balance and the last time the account had activity. Separating accounts into balance tiers prevents scheduling starvation of any tier by any other tier.
The foundation for this design is from the TaaC and PoS4QoS proposals by @Rob with some modifications to support malleable and untrusted timestamps. While signed timestamps give more mathematical rigor to the scheduling algorithm, it would require changing the signed block contents, coordinating network upgrades, and would take several months or more to implement which doesn’t fit with the current tactical needs.
The scheduler will start elections for the highest priority accounts in each balance tier in a round-robin fashion and the priority within each tier is least-recently-used order for the respective account. There will be 128 balance tiers, one for each bit in the balance field, and the leading 0s in the balance will determine the bucket.
The scheduler can choose a bucket according to any probability function. The probability function is approximated by populating the schedule container with indices according to the desired bucket service frequency.
The new scheduler will consider the following:
- Priority scheduled accounts
- Confirmed dependents
- Vote observation hinting
- When requested through block_confirm
- Fork resolution - This separation allows forks to be cleanly separated into their own low priority tier.
Of note, the new priority scheme has the potential to remove PoW requirements largely or entirely. This will make nano integrations far simpler than they currently are and sets nano apart from all the other systems that view fees as the only solution to the scheduling design.
As a reminder, this is a focused discussion topic. If your post gets flagged as off-topic, please ensure it is specific and technical in nature to this design.