On the Tezos delegation model

Research and Development
1

Delegation in Tezos

Proof-of-stake in Tezos combines two different ideas: using the cryptocurrency as a Sybil prevention mechanism, and using it as a bond to guard against byzantine behavior. Block creation rights accrue to past token owners but must be exercised by a bonded actor. In some instances, these are the same party (“self-baking”) but in many instances, there are different parties, a “baker” and a “delegator”. The delegator leases the block creation rights they receive to the baker which pays them with a fraction of the reward they collect (typically around 90%). Currently, the breakdown for a delegator looks roughly as follow:

  • inflation: 5.12% / year
  • reward retained by baker: 0.68% / year
  • reward paid to delegator, assuming baker retains 10%: 6.12% / year

The inflation-adjusted net for the delegator comes to about 0.95% / year, in tez, and is derived from two sources:

  • transaction fees paid on the chain (although those are currently minimal)
  • dilution of participants who do not participate in baking or even select a reliable baker

Conversely, we can look at the reward adjusted inflation experienced by a delegator as -0.94%.

Setting aside the collection of fees, the reward mechanism is fundamentally a mechanism to partially redistribute coin ownership from participants who do not help secure the network to those who do. However, with close to 80% of the network baking or delegating, that redistribution is very modest and the bulk of “baking” rewards ends up being a neutral transfer. How much of it? 1-0.95/6.12 ~ 84.5%.

There are benefits and drawbacks to this approach, let’s start with the benefits:

  • To obtain block creation rights require a hybrid strategy, bakers must stake a bond and convince enough people to delegate. The delegators can exercise judgement in assigning their baking rights and act as another layer of Sybil resistance.

  • Currencies - especially proto-currency - derive their value from social consensus, not some intrinsic property. As such, they can be subject to nominal value effects. This is a fancy way to say that inflating by 5% and distributing 5% to everyone equally can have moderately positive-sum effects.

  • The system, as it exists today, seems to be working quite well and has attracted a lot of positive attention.

The drawbacks mirror, in some sense, the benefits:

  • If the impact of the delegator’s choice of bakers on the security of the system is not marginal, they may simply go the best bidder, creating discouragement attacks where a malicious baker underbids everyone
    else merely to obtain delegation. Relying on a stake as opposed to popularity with delegators may be more robust.

  • Inflating by 5% and distributing 5% to everyone could have negative tax consequences in some jurisdiction. Though there are legal arguments against those (see https://coincenter.org/entry/taxing-cryptocurrency-block-rewards for the US) there is, at a minimum, uncertainty around it, suggesting that filers either consult with tax attorneys or make a conservative choice.

  • The system composes somewhat awkwardly with smart-contracts. Consider for instance tez wrapped in a smart-contract providing sapling-transactions. Who should bake? Who should decide? Should participants be punished for leaving their tez too long in the anonymity pool? That would be quite detrimental to the pool’s success.

Proof-of-stake systems tune their “reward-adjusted-inflation” based on the cost of securing the ledger. In Tezos, that tuning happens when bakers and delegates negotiate over how to split baking rewards. If the cost of validating the chain and producing blocks were to rise, for some reason, bakers could keep more of the reward they receive, if they were to fall, they might offer more to their delegators in a bid to attract more of them. However, there is considerable friction in this mechanism as there are, again “nominal effects” around the baker “fees”.

Is there an alternative?

Quite possibly, the benefits of the current model may outweigh its drawbacks, but they also may not and it’s worth exploring what an alternative looks like. The following contains specific numbers for illustrative purposes only.

A classical staking model might work in the following way: coins are explicitly staked and locked for some time, only then do stakers start receiving and exercising block creation rights. The reward associated with block creation is set competitively to ensure that sufficiently many coins are being staked. For instance, the chain might target 40% of coins staked (and at risk of slashing), and set the reward using a Dutch auction. This means the block reward would be set at the lowest level that is sufficient to convince coin holders to stake 40% of all coins. If few people are willing to stake, that reward may be high, if many people are willing to stake, it would be low. In principle, stakers might even be willing to accept a negative block reward if transaction fees are high enough.

In such a system, non-stakers are indifferent to staking, the net inflation they experience based on the block reward being paid to stakers is lower than the point at which they would be indifferent towards staking.

Rather than targeting exactly a fixed proportions of coins being staked, one might use a bonding-curve and programmatically set the reward as a function of the supply staked. This generalizes the previous approach. Consider the supply curve of staking, i.e. how much reward would be required for x% of the supply to be staked. The Dutch auction approach takes the intersection of this curve with a vertical, inelastic, demand curve at x = 40%. Eth 2.0 has chosen to use an inverse square root curve to determine staking reward as a function of supply staked, there’s nothing fundamentally principled about using an inverse square root, but nothing fundamentally unprincipled either, it’s a somewhat reasonable choice.

The general point is that both inflation and reward would likely be lower under this system, assuming equal amounts are staked. The auction essentially “nets” the back and forth that happens today between the 6.8% collected by a baker and the 6.12% paid to the delegate.

Consequences

  • This considerably reduces the opportunity cost for coins to not be staked, which lets them be used in smart-contracts without the difficulty of having these smart-contracts designate a baker. This makes a sapling wrapped tez far more practical.

  • Delegation, if it happens, puts the funds at risk of slashing, decreasing the risk of delegators delegating carelessly but increasing the risk of them acting too conservatively by only trusting large stakers. “Economic” security might increase, but security from a diversity of participants could conceivably decrease. The former is more objective, publicly verifiable and quantifiable, the latter is more subjective and harder to analyze but that’s not to say it can’t be substantial.

  • Tax matters, if they exist, can be greatly simplified.

How to get there?

Assuming that the tradeoffs of this form of staking are more compelling than the tradeoffs involved in the current approach, how does one approach migration from the existing system to a new one?

One approach is simply to propose a protocol that implements such a proposal. Upon activation of such a protocol, the staking model would change across the board. An important drawback to such a naive approach is that it would be highly disruptive to the staking environment. No amount of preparation and testing might adequately prepare the ecosystem for an abrupt transition.

A simple, yet effective solution, would be to blend-in a new staking model over time. An updated protocol could allocate a fraction of the block to the legacy model, and a fraction of the blocks to the new model, starting with 100% legacy and sliding, linearly to 0% over, say, two years. This would give ample time to the staking ecosystem to adjust and ample opportunity to identify and resolve any issue that might arise out of the transition. During that period, existing bakers would likely involve their delegates in the formation of staking pools.

Why bring this up?

The goal is to start a discussion about the benefits and drawbacks of this staking model. If ever implemented, it would represent an important departure from the existing model in Tezos and, as such, needs to be analyzed and discussed as early as possible.

9 Likes
2

This is a really important post on the dilemmas of the delegation model, so I hope people are indeed thinking seriously about these issues.

One beautiful thing about the current Tezos model is that the amount that participating token holders pay for network maintenance can settle around the actual cost of running a baking operation. This is an extraordinary improvement over POW that POS makes possible (assuming, of course, that POS is otherwise stable). Indeed, it is worth noting that today, this cost is commonly measured as a percentage of the new tokens attributable to the delegator’s stake. It is easy to imagine a world where the fee retained by a baker is instead denominated in more fixed terms – why not x XTZ per cycle?

But as the post also points out, it isn’t as simple as that as there are serious frictions and other effects that get in the way, including the problem of baker dominance and centralization.

The metaphors that enable humans to make sense of money and financial systems are deeply entrenched. We have to acknowledge these, and, like it or not, make design decisions that allow normal people to (a) have a basic understanding of what is going on, that (b) is also mostly accurate. Regarding point (b), it is important to acknowledge that full understanding need not be the goal; most of us can’t or haven’t really gotten our heads around the way fiat money works but luckily it usually doesn’t much matter.

In my (weakly-held) opinion, it will be difficult for POS (at least as implemented by Tezos) to thrive if the conventional wisdom does not improve to include an understanding that nominal new tokens created as block rewards are not like interest or dividends. And just as importantly, I’m not sure the conventional wisdom is capable of rising to this level.

So I am concerned about the further complexity introduced by a participation target (such as the proposed example of 40%), even assuming the perfect algorithm is out there. On the other hand, if 60% of tokens won’t be participating in any case, this could provide a two-tier system with simplicity, and an easy recourse to traditional money and finance metaphors, for a majority of token holders. But this would mark a big departure from the purity of the Tezos vision of broad/universal participation in the network. If we’re not aiming for 100%, the natural alternative is to aim (or maybe just slide) toward 1%.

Bitcoin is different but it is helpful to think of it as having 1% participation (the miners). There is something brilliant about this approach. Of course, the fact that to date Bitcoin has relied on the same kind of dilution that fuels POS seems wholly lost on Bitcoin users, as it is a fact artfully obscured by the powerful meme of the 21 million cap. But the high and misunderstood costs of Bitcoin aside, bitcoins look like the kind of tokens we humans can understand. “1 BTC = 1 BTC” and all that.

If we can’t aspire to 100% participation (and I think that tax and regulatory issues are very important, quite unfortunately, in addition to the issue of smart contracts addressed in the above post), is it feasible in POS to aim for 1%? (1% is a stand-in for “the minimum needed to ensure decentralization and security.”) Without the waste created by Bitcoin’s approach, this would allow the 99% to pay modestly for the maintenance of the network without upending the popular conceptions of money and tokens on which the whole apparatus depends.

Maybe 40% is what is feasible now, and 1% would only be stable and safe after the growth of the network.

Finally, note that if block rewards are taxed as immediate income, the tax problem would still be present even with 40% participation, although it would be notably less severe. The problem of overtaxation increases as validation participation approaches 100%.

2 Likes
3

Quite a conundrum. The same argument basically applies to sidechains, or layer 2 solutions such as state channels (e.g. lightning) or commit chains (e.g. plasma) which require locking tez in configurations where it doesn’t have a clear, identifiable, owner who can decide on a baker to select.

4

There is a potential way to address the problem of making tez easily available in defi applications without deploying complex machinery to provide it with a baker. It is a somewhat ugly and hackish though.

The idea would be to create a “virtual baker” inside the protocol, that automatically pays rewards every cycle to its delegates. The question becomes: how much reward exactly?

The virtual baker by itself has no clue about the typical amount of rewards retained by bakers. If it only matches inflation, there’s a chance it will be too stingy given that not everyone delegates. If it matches the rate of solo baking, it’s likely to undercut bakers and attract all delegation, thus killing the incentive to carefully pick bakers.

The solution is to target a fraction of the rolls, say between 15 and 25%. If 15% of the rolls or less are delegated to the virtual baker, the virtual baker pays the reward from solo-baking. If 25% of the rolls or more are delegated to the virtual baker, the virtual baker pays nothing. The reward is adjusted linearly between 15% and 25%.

This ensures that the system reaches some sort of equilibrium with the rest of the bakers. The virtual baker cannot aggressively undercut bakers (or it would attract more than 25% of delegation) but it cannot leave too much on the table either (or it would attract a lot less).

There are important drawbacks to this technique.

  1. the 15%-25% figure is pulled out nowhere. If it turns out to be too low, then the problem of dealing with the baking rights of tez collateral in smart-contracts will remain. If it turns out to be too high, then it will disrupt baking by magnifying the impact of delegation on governance and block creation rights.

  2. A naïve implementation would spend time O(n) adjusting balances which might work today but would not be future proof. This would require a careful implementation with lazy balance updates which is not trivial to do.

The main benefit is that this is minimally disruptive to the chain. All smart-contracts would have to do is point to the virtual baker and receive decent block rewards, but not as attractive as baking directly or even delegating directly.

2 Likes
5

An additional complication is that those contracts might not want to see their balance magically increase without a corresponding transaction. A simple solution would be for the virtual baker to provide a contract which pays out the reward to a callback address. If the call isn’t made within the cycle, the reward is forfeited. This solves the issue of adjusting balances in the protocol and doesn’t blow up the size of the state.

However, it creates weird incentives issues as the balance of the contract would not represent the implicit accrual incurred over the cycle. Meaning, in something like a dexter contract, people could deposit and withdraw just around the time where the reward is called. This can be addressed directly in the contract but requires extra complexity.

Another approach which doesn’t depend on a virtual baker would be to create a special contract which accrues virtual reward and provides an interface to a “ctez” token backed by an increasing number of underlying tez. Smart-contracts that require to hold large tez balances would hold ctez balances instead. Since the ctez contract’s tez balance can increase at every block, there’s no issue around accrual. However, this pushes some complexity inside the contracts since they now have to deal with a token interface as opposed to directly sending tez around.

Yet another approach is to follow the ctez approach but to offer protocol level support for ctez transfers.

1 Like