the tezos protocol and the problem of over-delegation

Question

Why does the Tezos protocol allow for baker over-delegation?

It is the Tezos protocol itself that has encoded the amount of XTZ that needs to be put up for baking and endorsements and the protocol also defines how long such funds need to be held for. Why does the protocol itself not provide a mechanism to prevent over-delegation?

It seems unfortunate that, even if I'm an over-delegated baker, and I can write that fact in size 100px font on my website, yet others can still mistakenly delegate to me.

Couldn't an operation very simply be built into the protocol like: tezos-client no longer accepting delegations for my_baker?

This would set a flag on the baker account and from then on out delegation operations to this baker would fail. This definitely seems better than nothing, but it does require manual intervention on the baker's part.

Trickier and possibly impossible would be for the protocol to automatically prevent this by detecting over-delegation using its own algorithms that are already built for enforcing deposit requirements. It gets tricky though, because this means a baker would need to fill their account with more and more XTZ prematurely to prevent from becoming over-delegated, instead of just waiting for the delegations to occur and then topping up their accounts accordingly.

Wondering if anyone is thinking about or working on this? It seems to be a significant problem.

(I realize this question starts to veer a bit into the subjective realm, but I still feel its a very important question and I haven't seen it asked or answered anywhere. I feel this question should exist somewhere in a very public and visible forum, so I'm asking it here.)

Answer 1

If the protocol did not allow for overdelegation it would mean that if the baker is at max capacity then she would not be allowed to remove any xtz from her implicit address. This is not acceptable because the only time that the bond is required is when the baker has a baking right and so only at that time she has to have to xtz available to post them as post collateral.

Preventing the baker from moving her capital when it is not required could be seen as an abusive constraint on baker’s capital and could even lead to an attack vector where one could “lock-in” a baker’s tz1 address by delegating to her just enough xtz. All in all this could become such a risk that deters individuals from starting bakeries operations.

Answer 2

The reason for over-delegation is to improve decentralization and encourage self-bonding; having a "personal" stake in the system.

Many different teams are thinking about this and working on solutions. Check out the Burebrot proposal by Cryptium Labs.

However it's not straigtforward;

• Being a permissionsless system, should we prevent A from delegating to B?
• There is no way to contact ones delegators since we do not know who they are
• A baker might remove all or part of it's bond - should this not be allowed?
• A baker might shut down - should this not be allowed?
• Self bonding is an important mechanism to avoid economies of scale and centralization

Over-delegation can be an annoyance for bakers, but it is an important mechanism to ensure decentralization and stake in the system. Perhaps a better way to "work around" this issue is to make better tools and encourage active delegators and bakers.

You can read more about overdelegation here.