Standby delegates weight and health

[ghost]

Standby delegates are just as important as active delegates. They are a pool of resources that could potentially move to active delegation in the main chain or a delegate for a side-chain in the future. I would like to pose this as an enhancement request. In the hopes of sparking a discussion, it would be useful to tell, by any means, the health of a standby node as a foresight for selection as a delegate by other means.

[mrv777]

Is there anyway that for delegates 102-203 they could share the forging round and their order be randomly selected just like the active pool, except instead of forging a block, they are supposed to send out their current blockheight? (this verifies they are both online and at the correct block) or maybe to simplify that: don't do the random order or anything, but on the last block of the round, those delegates all just check their blockheight to verify they are at the correct height and they are online or just make standby delegates, the active delegates on the testnet somehow :)

I don't know if that makes sense at all, I'm tired and it's a rough day, but thought it could help the conversation :) I'm sure the API whitelist could cause an issue here too, but I'm thinking they broadcast their blockheight some other way.

[fix]

It is a bit difficult to include standby delegates for the following reason: missed blocks.

Conceptually the block is missed WHEN another delegate (the next one in round table) has forged it instead (and because there were no blocks).

Which means basically that finding a consensus algorithm to find legitimity to standby delegates would be overly complex (i thought about it a couple of times and could not come up with any)

[ghost]

Perhaps we could look at it outside of the core functionality. For example, an api enpoint that gets the uptime of the application itself. This has many downsides but could be a start. My other thought was a way to keep track of reloads, restarts and rebuilds but, this is executed outside, which cannot be tracked by the application itself, and could be easily modified if made external as a file.

[maxkordek]

In the future standby delegates will be the infrastructure for all kinds of apps and services. So we definitely need some way to see if they are online or not. One way would be a new sidechain which is being forged by every standby delegate, but that doesn't scale.

If we just give the blockchain height in a table I think it's sufficient. The client can counter-check with the local client and network if this is a good height or not. Thus, giving a green, orange, or red status.

[ghost]

@MaxKK My thought is to go beyond just the online status (on/off) but historical data on the participation of a user. I think a side-chain can be ideal for this use case. To expand on your point, a main standby delegate, as he/she receives blocks, records with information in a side-chain, peer ip x, height x. Thus confirming that the peer was online and able at the time of block x. This raises another issue, confirmation of ownership of peer ip x, but at least there is historical data on peer block receipt and therefore status.

[ByronAP]

pop number 101 as a round robin to delegates 101-201 decrementing each round then restarting at 101

[Gr33nDrag0n69]

What I described is based on testnet and lisk-explorer but could be applied at others places. Some of the standby delegate (pos 102+) had the chance to forge before going back in the 102+. In the explorer, when they go 102+, they go back to 0% productivity. Those could have a percentage because we actually have data on them. Thus it would make a difference between delegate that never forged and delegate that were downvoted (or else) .

For example, I downvoted 30 delegates because of bad productivity. I want tor replace them from standby. I have to remember the one I downvoted for bad productivity. 2 weeks later newcomers arrived. They have no idea in the standby delegate about the one that could have their chance and the one that burned their chance.

[shuse2]

This will be addressed by LIP-0022.