Adaptive Inflation and Cobaking: functional spec

Research and Development
1

We (@sophia and myself) are submitting the following functional spec to the community for review and comment:

Please note that there is no code accompanying this spec and we are not planning to implement it. The purpose is to have a concrete breakdown of the feature written down that can be debated. Comments are welcome, either here or on the hackmd.

5 Likes
2

How is the security of the smart-contracts involved in this ensured? That’s a lot of money we “trust” to these contracts…

3

I am not sure this cobaking feature is a good idea. What about unsolicited cobakers? What can I (as a baker) do when I do not want to have cobakers? There is not protection from that when I look at the spec and thats bad. What if I dont want to handle other peoples tezos but just mine? Now if a delegation happens to a baker that dont accepts delegations and does not pay out rewards I can just “ignore it”. But when someone suddenly just starts to cobake with me there is the possible risk of loosing his tezos now. And knwoing how great certain countries love to protect their customers this opens a door for possible lawsuits imo

1 Like
4

But when someone suddenly just starts to cobake with me there is the possible risk of loosing his tezos now. And knwoing how great certain countries love to protect their customers this opens a door for possible lawsuits imo

Within this spec, you can’t prevent cobaking but you can set cobaking fee to 100%, so effectively no one would cobake to you, unless it’s a mistake. A cobaking on/off switch could be added, but there is no such thing on Polkadot and Cosmos (afaik) and I’m not aware of any lawsuits.

How is the security of the smart-contracts involved in this ensured? That’s a lot of money we “trust” to these contracts…

The ovens or other contracts we have today in tezos will not be able to cobake, so they will remain as trustworthy as today. Someone will have to write contracts with explicit cobake ability, and any user of these new contracts should be aware that any funds they deposit are subject to slashing risk. We will probably have multisig cobaking contracts (which is a nice way to do corporate baking with multisig), I’m not sure we will have cobaking defi contracts.

1 Like
5

The “pseudo-token balance” is handled by the protocol? Not by smart-contracts?

6

That’s right. All that the smart contract can do is cobake or uncobake some amount of tez. Same goes for tz accounts. When you cobake, the frozen balance remains in your possession. The protocol keeps track of rewards and slashes and distributes them fairly.

1 Like
7

If a cobaker provides a bunch of capital for baking, and this new capital then pulls in a bunch of new delegators thanks to the free space provided, the cobakers can screw over all the new delegators by switching to a different baker leaving the old baker over-delegated. So a cobaker can inadvertently screw an entire bakery and it’s delegators by switching it’s cobaking bakery.

The only defense a bakery would have is to keep an equivalent amount of Tezos as those being cobaked, in reserves. This reserve is in case any cobakers leaves, the baker could quickly replace frozen funds. That way delegators would not be hurt by over-delegation.

9

If a large cobaker moves out, the baker will be sad because they lost the cobaker, not because they become overdelegated.

Under adaptive inflation, we should expect overdelegation to be a smaller issue than today, because delegation would bring little reward, so many delegators would opt to become cobakers, and there would be free space in abundance everywhere.

2 Likes
10

Even if i slowly get the reputation of a Taxman, i think many jurisdicitons handle baking different compared to delegating.

In some countries it is even seen as “commercial”. Maybe one could steer against it, with a “better” wording than “cobaking”. It is technical not baking. Baking does the machine of the delegation-service.

“Delegation+/Pooled Delegation” or something like that.

As soon as your own machine is involved/doing work/calculation (cobaking implies this), you are seen as an active participant. That’s what i got told from my Taxman.

11

Will it ever be possible to get rid of slashing from Tezos all together?

12

I am not convinced about cobaking and would prefer to separate Adaptive Inflation from cobaking when it comes to the implentation and voting on the proposal

13

Thanks, overall I think this is a great proposal!

Pros

  • it clearly specifies a new feature before its implemented (unlike most L1 changes in the past)
  • it incentivizes a higher security-to-supply ratio
  • it is opt-in, delegation and co-baking have fundamentally different risk/reward profiles, so should be kept separate
  • it formalizes security deposit capital lending which large bakers have been doing off-chain for years and makes it trust-less
  • it removes explicit baker payouts (YEY!) which
    (1) cuts unnecessary operational overhead for bakers,
    (2) prevents bakers from defrauding cobakers on payouts,
    (3) avoids bakers become custodians of payout proceeds,
    (4) avoids frequent value transfers (== taxable events) and gives cobakers exact control over when such transfers occur

Cons

  • uncobaking: during unfreeze the amount should be ‘unstaged’ and not counted against a co-bakers deposit X(b), otherwise future baking rights will be overcounted
  • the split into delegation and co-baking rewards will further raise the complexity of accounting for bakers
  • it is a lending protocol with liability implications (possibility for loss of customer funds due to baker negligence), so tax and regulatory compatibility should be considered in the design processes

Looking forward to a nuanced discussion.

4 Likes
14

I would like to see what would be the block rewards if 70%, 50 %, 30 % of the total supply is staked with a 15sec block interval ( as in Mumbai) and 8 sec ( future release) considering the 2.5 tez per block allocated for Liquidity baking. (Note that in the cosmos almost 65% of ATOM is staked)
Also, how do you prevent the griefing i.e single player posting a very high-security deposit so that the smaller and public bakers couldn’t earn any meaningful income from baking and shut shop?
Is there any minimum block reward guaranteed irrespective of any amount of security deposited or is there a scenario where block rewards can be zero (considering after paying for liquidity baking)?
How is the current change ensures that delegators get less rewards than co-bakers? I assume it depends on the bakers setting the fee for delegators and co-bakers.

15

Thanks @Alex , I have published version 1.1 of the spec which introduces uncobaking staging areas. They are necessary, as you are pointing out. I also incorporated some suggestions by others.

I would like to see what would be the block rewards if 70%, 50 %, 30 % of the total supply is staked with a 15sec block interval ( as in Mumbai) and 8 sec ( future release) considering the 2.5 tez per block allocated for Liquidity baking. (Note that in the cosmos almost 65% of ATOM is staked)

@Karthi1908 I just published a simulator notebook where you can see an estimate of rewards per baker under adaptive inflation. It can be expanded to run various scenarios.

Also, how do you prevent the griefing

We should indeed try out different scenarios with different curves. The simulator notebook is a first step towards that.

3 Likes
16

he baker including the slashing denunciation receives 1% of the slashed amount, while 99% is burned.

This is contract to today’s implementation where the baker receives 50%. The intent of this change is to discourage cobaking scams, where a baker attracts a large amount of cobaking then subsequently steals 50% of it by denouncing themselves using a different baking address.

Because accuser is another process, with only 1% reward, there is no risk than people decide to not run it ?

I understand why 50% is too much, but 1% is maybe to low ?