Balance is what MakerDAO needs
Dominik Harz is one of the authors of the “ Balance: Dynamic Adjustment of Cryptocurrency Deposits” paper that aims to reduce collateral in crypto-economic protocols. He presented the essence of Balance at a blockchain.tokyo event on Thursday, July 25, 2019.
Today, I will be talking about Balance, which is my latest paper. It is a protocol about reducing collateral in crypto-economic protocols. I will cover in a bit more detail what that actually means and what it is about.
Some of you may know the Dai project. Dai is a stablecoin. The idea is essentially that you build a cryptocurrency that is stable and pegged to the US dollar, and you get that guarantee of being stable by providing collateral. You put a lot more Ether into the stablecoin than you actually need. In Dai, you need at least 150% of collateralization, but in practice, you are bouncing somewhere between 350% and 600% of over-collateralization. That is super inefficient. You are so much over the collateralization threshold that the question is, can we do something about this, can we actually reduce collateral and still have the same level of security?
Since “Balance” is a bit more of an academic paper, there are also other academic protocols that suffer from the same problem:
- FairSwap is a protocol for the exchange of digital goods (files); the provider pays a deposit to commit to a swap
- TrueBit is a verifiable computation scheme, where you play this verification game with collateral; solvers provide a deposit against providing false results
- XCLAIM is a protocol that allows you to trustless exchange cryptocurrencies so you can exchange Bitcoin or Ether without a centralized exchange; but you also need collateral to protect against volatility between currencies; vaults post a deposit to insure against stealing coins
So what is the big problem? What if that exchange of digital assets takes a long time and cryptocurrencies fluctuations need to be accounted for? What if somebody is actually malicious? We need to account for any kind of hidden motivations. And the only way to account for that is that we need to over-collateralize, right? So we just have a lot more collateral than we actually need.
This leads to a dilemma, because the service provider and the service consumer have different interests, with the former wanting to put up the least amount of collateral possible, whereas the latter wants a lot of collateral to have security that the provider does not cheat, but then also wants to pay reasonable fees. And obviously, the provider, if she has to provide a lot of collateral, she will charge higher fees.
So this leads to the dilemma that the requirement of deposits or collateral is subjective to each agent in the system. The question is, can we actually reduce the deposits but still get the same level of security? The answer to that question is “yes”.
Let me explain our crypto-economic protocol at a very high level. First, you initialize the protocol and somebody, Alice in this case, provides a deposit to the protocol. Then, Alice basically has two choices. Either she does something that is in the interests of the protocol — and we verify that through a smart contract. When the protocol concludes, Alice can take out her deposit again. Alternatively, Alice decides to be malicious. She will do something that is not desired, which we again can verify in the smart contract. What usually happens then is that Alice does not get paid and the deposit is refunded to the service consumer or it is burned.
Balance is an add-on to a protocol. So you take TrueBit or XCLAIM, and you can integrate Balance into that. We use a little trick — we can reduce deposits by less than the opportunity cost. We assume that there is some cost for participating in a protocol (because you could use your tokens elsewhere if you were not participating). And then we say, can we somehow monitor that agents actually continuously contribute to our protocol, and we are going to verify all of those actions through a smart contract.
To put it very simply, imagine you have a single function that evaluates either to true or false. The smart contract does exactly that, it determines whether the agent is behaving correctly, yes or no. And we reduce deposits over time, by continuous interaction, by less than this opportunity cost.
For that, we introduced layered systems. So imagine your service provider starts with a level of two times over collateralized, or 200%. She is behaving really, really nicely, so she can actually go a layer below that. If she continues to be nice, she can go another layer below that and end up with only 150% collateralization. The trick is essentially that the protocol integrates with the balances to set a boundary, how you want to reduce collateralization through the layers. We also want to make sure that that only happens when you are continuously nice.
We make some assumptions:
- Underlying ledger functionality for smart contracts; there is underlying functionality that allows us to enforce actions
- Over-collateralization due to event dependency or private information; Balance only works if you have over-collateralization — for example, the Lightning network does not need over-collateralization, so Balance does not work here
- Verifiable specification in a smart contract (also probabilistically); that is the smart contract function that evaluates to true or false, as mentioned earlier
- Deposits prevent economically rational agents from cheating; agents actually need to care about losing money
- Balance is integrated as an add-on to an existing protocol; implemented for FairSwap, TrueBit and XCLAIM, and we are currently working on Dai
So step by step, what do you actually do? You have Balance here, you integrated your crypto-economic protocol. Your Agents A, B, C and D, they will perform some actions and then they get a score for doing that. In the Balance smart contract, we have a mapping from each Agent score to the current Layer. So Agents A and B are assigned to Layer 1, C is Layer 2, and D is at Layer 3.
When the period ends, we are going to count what the Agents achieved, and we are going to adjust their Layers. We see here that Agent A stayed alright. C was actually really bad and is going back into Layer 1. Agent B behaved nicely, so B goes up one Layer. D continued to be very nice, so we leave D in the highest layer. Again, all these thresholds are defined by the underlying protocol. Now that we are finished with that round, everything starts from the beginning. If you want to lower your collateral, you have to continue to be nice. As the very last step, we are going to inform the agents of the changes.
Balance has been designed to exhibit the following properties:
- Auditability: agents can see the current deposits
- Transparency: deposit levels offer the same security against different economically rational agents; if there are different service providers at different layers, the provider choice of the service consumer does not matter as the system provides the same security against malicious attacks regardless
- Sybil resistance: agents cannot lower their deposits through Sybil identities
- Reduction of opportunity costs: agents can reduce their deposit and thereby their opportunity costs
- Strategy-proofness: agents behave truthful to their valuation
- Social welfare increasing: Balance increases social welfare in crypto-economic protocols; honest parties and rational parties can reduce their collateral (and malicious actors would cheat right away)
We basically have a certain utility for performing a good action and a certain utility for a bad action. And how a service provider would decide whether she is acting good or bad is dependent on this utility function: if the utility of being bad is higher than being good, then we should cheat. And if I was actually going to cheat, then I should cheat in the very first ground, because I will not save more by stepping through the layers. I will actually incur more cost by going through the layers than cheating right away. The higher your starting collateral, the more you can reduce. And if your starting collateral is exactly 100%, you are not over-collateralized, so you cannot reduce anything.
So what is a practical application? XCLAIM is a protocol for trustless cross-chain communication, and XCLAIM requires 2.06 over-collateralization in their paper. We can reduce that collateral by 10% by applying Balance. We have an implementation for that, it is Solidity code.
I have been talking a lot about the continuous interaction with the protocols.
But for something like Dai, you open a CDP at some point, but then you technically do not interact with the contract anymore. Right now, we are looking into how Balance would work for Dai, and we have some ideas how to stabilize Dai through reducing collateral, but it will take some time to finish the paper. So that is a discussion for later. Other threads we are pursuing is determining the optimal collateral at the outset — nobody has really addressed this yet, and we have only talked about reducing collateral. Lastly, we are looking into the question whether a restriction on the number of agents per layer has an impact.
If you found value in this article, please “clap” (up to 50 times).
This article is part of our Tokyo FinTech Publication, please follow us to read more from our writers, like hundreds of readers do every day.
Should you live in Tokyo, or just pass through, please also join our Tokyo FinTech Meetup. In any case, our LinkedIn page, Facebook page and our Instagram account are there for you as well.
