the topic of distribution curves for is high on the agenda in the upcoming Hard Fork 17, I have been thinking for some time about how to arrange the block schedule for witnesses that adapts smoothly to the (eventual) necessity to split the schedule into 2 or more parallel threads without requiring two (or more) separate hard-coded schemes to generate the scheduling.

How it works now

For the less technically informed, the system as it stands works such that those who get the top 19 positions in a stake-weighted witness election all get an equal number of blocks allocated to them, an extra one goes to a miner, and then every 63 seconds one of the witnesses whose rank in the election is above 19, er, 19+, down the ladder really since we draw it top to bottom. The frequency by which these 'back up' witnesses get given that slot is based on something like a curve like the one shown in the picture above, which I will explain in a moment.

What I think would be better, and why

The curve above is what I would propose to use. I am not sure I have scaled it correctly with the parameters, but it's basically an inverse square curve. I have made a spreadsheet that calculates the proportions correctly - the chart above goes into negative after 50%, so instead I rescale it to 100 divided by the total at each integral number to find the percentage of blocks each node at that position gets:

https://docs.google.com/spreadsheets/d/1PTzFQ7WOXZVg7sZwYL72Cto_E8gXZbCcH2MwCs7OeMM/edit?usp=sharing

On the very right side every 10 slots I have the sum of the proportion at each group of 10 down the ladder. Note that I have just assumed a distribution of 100 witnesses, I am not sure there is that many available. The idea would be to calculate this curve periodically based on the current state of the election and number of available witnesses and spread it that way.

You can easily see that it gives about 42% of total blocks to the top 20, and then more evenly but progressively distributes the rest scaling from 9 down to 6% for each group of ten as you go down.

Potential abuse vectors

No different from the current scheme, there is always the possibility that one witness could attempt to DoS their competitors to get them removed from the list until they re-sign the witness declaration transaction after 24 hours continuously offline. The profit from this attack could be quite good but it wouldn't be a big search for suspects since outsiders have little interest and most importantly, motivation (by moving up the scale).

But perhaps even then this scheme has a benefit in this kind of scenario, they can't just take all of the witness blocks the other would have got, it would be reproportioned and everyone else would benefit, which would have to go into the (twisted) calculations of a 'witness' like this. The profit from such attacks would be pretty slim.

The difference that I see between a flat top 19 block allocation is that this increases competition since moving up a position has a benefit of a similar proportion to the difference in weights of votes (which are calculated on a somewhat similar curve). Increased competition can cause bad behaviour but it also strongly rewards good behaviour.

Outside of this, I can't see an new vectors of abuse from changing this. However, it instead has a different benefit, which is part of what I am proposing, it scales better with more witnesses, and it scales better when there is parallel block schedules as proposed for when the network reaches current capacity for processing transactions in time.

Proposal to enable the elimination (nearly) of missed blocks

This one is separate but somewhat related, but the basic idea is that instead of only one witness being selected for a block, a second one, generally picked from the next 10 or 20 slots down (except the last 20, where it doesn't matter so much) and the secondary has to make a block in the same slot, and propagate it, but if the primary witness makes the block on time, the secondary block is discarded.

This would eliminate missing blocks on the schedule, which would reduce jitter in the latency of payments (they would almost all be in 3 second slots). It would give a benefit to lower witnesses when the higher witnesses fail, in the form of more pay, and since block frequency is so low, there is good reasons to do this, it keeps the machines all doing something more often. Possibly rather than get nothing at all for the discarded secondary block, maybe the secondary can take 10% (or 1%) of the payment if they make the second block, and this would be processed and paid out by the following witness(es) in the schedule.

Possible gotchas

Though the secondaries don't have much time to mount an attack to stop the primary making the slot, there is some chance that this could be done. Perhaps a way to avoid this is to not allow either primary or secondary to know who is who until after the deadline. Separate witnesses could be randomly assigned the task of selecting the primary and the secondary, and even these nodes would not be able to tell the ones in a slot which the other is.

Concluding comments

I spend a fair bit of time lurking and sometimes quite chatty in the witness chatroom in the steemit.chat, so I know what is on the agenda and what other people are thinking. These two ideas came to me in the last few days while discussing the aspect of optimising the distribution of work for witnesses in a way that broadens the distribution of payments while at the same time making it more competitive between witnesses.

After all, we don't want witnesses to cooperate too much or the rest of us are going to suffer, so placing the temptation to backstab out there, people are not going to be so buddy buddy nor think that maybe nobody will care when they try to orchestrate some variety of coup, artificially reshuffling the schedule outside of the control of the voters (like the DoS attacks mentioned before).

update:

One thing I didn't think of is how this changes the veto scheme. I think it still works the same, except it's a 2/3 majority weighted by position. This still leaves the power to veto in the hands of the top half of the curve, where 2/3 is contained.

Veto of hard forks is a mechanism that defends against developers gone wild at Steemit, Inc., to explain to those who don't know how the witness system works. It was invoked prior to HF16 and stopped changes that were very unpopular with the elected witnesses.

---

We can't code here! This is Whale country!

Vote #1 l0k1

_{Go to steemit.com/~witnesses to cast your vote by typing l0k1 into the text entry at the bottom of the leaderboard.}

_{(note, my username is spelled El Zero Kay One or Lima Zero Kilo One, all lower case)}