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:
- 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 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.