I want to boost this idea from @murbard to add a “virtual baker” to the protocol that contracts can point at and be allocated rewards, either directly or by holding a token. It’s an alternative to my idea where bakers bid on pools of tez, which I’ve come to call “conventioning”, as a solution to opportunity cost from baking in DeFi contracts. This is an issue for building strong anonymity sets with Sapling, for Dexter where (unlike on Ethereum) fees paid to liquidity providers compete with baking rewards, and in systems involving delegated SNARK proving (e.g. Coda’s “snarketplace” — this is technically possible with Sapling, although the feature won’t be exposed in Tezos).
I’ve come to believe the virtual baker is the better solution because it takes the burden off of contract developers and because it doesn’t require security proofs like conventioning. However, it’s not without its own challenges, including developing an efficient implementation and the fact that it requires a protocol upgrade.
Also note there’s a lot of crossover between the ctez approach described below and Trustless Staking Tokens or “TST”.
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.
- 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.
- 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.
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.
