Globally synchronized election scheduling proposal

There's been a lot of forum posts about which blocks should be prioritized, but not how to prioritize them. As seen on the beta network, the current system needs improvement. Here's my proposal:

The theory:

  • Manually research a global maximum sustainable concurrent elections number, referred to as X. A reasonable initial value would be 100. The value used should likely be conservative.
  • Each node has a local prioritization method. This would likely be prioritizing any local accounts and then sorting by time*balance. Because there's no requirement that every node has the same local prioritization method, this is easily upgradeable.
  • Start an election for every new block whose dependencies are confirmed
  • Mark the top X/2 elections sorted by the local prioritization method as locally prioritized (and all others as not locally prioritized)
  • Create a property for each election, effective weight. This is equal to the total weight of all representatives which have voted in the election plus, if the election is locally prioritized and the local representative has not voted in the election yet, the local representative's weight.
  • Sort all elections by effective weight, and vote in the top X elections.

The implementation:

  • The local priority function would return the maximum value for any accounts in a local wallet (and perhaps long term for any specified by an RPC), and for any other account, use time since latest block dependency * account balance after block. There could be a config option to use proof of work difficulty as prioritization to some degree. To sort ties, the election root bytes or time since election first seen could be used as a secondary key.
  • Elections would be stored in two binary heaps, likely using a boost multi index container. The first would be sorted by local priority, and the second would be sorted by effective weight.
  • I'm not too familiar with the existing sequential elections system, but new database tables may be needed to list successors to a confirmed block so the node knows which blocks it needs to create new elections for, and to create elections on startup. If a new incoming block's dependencies are confirmed, an election would be created immediately.
  • If a newly inserted election is in the top X/2 in terms of local priority, the election just after the top X/2 loses its local priority flag and the new election gains its local priority flag.
  • When an election's local priority flag changes, or when a representative votes for an election that it didn't before, its effective weight is recomputed.
  • If a new vote for an election is received, and the election is in the top X by effective weight after the vote is included in the effective weight, the vote is rebroadcasted.
  • Every broadcast interval, the top X elections sorted by effective weight are voted for. Any of those elections which were not in the top X elections sorted by effective weight in the previous broadcast interval have all representatives' latest votes for them rebroadcasted.
  • Bonus: representatives can be rate limited to X votes for any election per broadcast interval.
14 Likes

One potential addition to this to resolve issues around sequential elections and disagreement about confirmation status is to consider even non-sequential elections active, but only to vote in sequential ones. Any non-sequential elections would have both a local and global effective priority of 0, but could still receive votes and be confirmed (which would also confirm their dependencies). It may make sense to store these non-sequential elections in a separate container than sequential active elections.

2 Likes

I am wondering about this and if this is being considered as v22 beta testing results are being addressed here, Colin said he is working on a new function in v23 that might change things so there's that, curious nonetheless.