cbeck88
commented
2 years ago Hey, thanks for posting!
This is a really important question and we didn’t really speak to it in any of the MCIPs.
So I want to try to focus first on some technical points of the system:
We need to ensure that the choice of using a confidential asset type or not is solely the responsibility of end users. We do not want to put node operators in the position of being the gatekeepers of allowed asset types.
The way this is actually specified and implemented is, the tokens.toml file has to be signed by the “MINT_TRUST_ROOT”. The public side of this key is baked into the enclave, and the pieces of this key are controlled by the foundation. So the node operators are not exactly the gatekeepers here, they can’t just edit this file at will, or their node will not be startable.
However, it is true that this does not prevent replay attacks. It’s conceivable that a node operator could be pressured to revert a change to tokens.toml, and the previous version is also signed, and this signature is good for all time, so that could work with the system.
The next question I want to focus on is: What exactly happens if a token id is added to tokens.toml and later removed?
In block version 2 (part of upcoming MobileCoin v2.0.0 release), any TxOut’s that have that token id still exist on the ledger (and no one knows which tokens they are), but it wouldn’t be possible to spend them in a transaction, because you would have to pay the fee in that token also, but for that to work, there must be a minimum fee for that token id, and that is specified in the token.toml, so the transaction will not pass validation. These TxOut’s are effectively frozen, until this token id is restored.
In block version 3 (the current version being developed in master), we have a new feature called “mixed transactions”. This allows that transactions can have inputs and outputs in multiple different token types, and as long as they are balanced across all token types, then the transaction is valid. The fee can be paid in any of the involved token types. So for instance, if a particular token were removed from tokens.toml, those tokens could still be moved, but you would have to pay the fee in MOB or some other token at that point, and you wouldn’t be able to pay the fee using that token any more.
Mixed Transactions is part of MCIP #31. The larger goal of MCIP #31 is to support atomic swaps on-chain. The goal is that we will use this feature to launch a swap service which enables peer-to-peer trades of one token for another, where the swaps settle on our chain. In fact those swaps can settle within a single mobilecoin transaction, so at that point, it may not even matter if a token is removed from tokens.toml – you can get a swap order that swaps your token for MOB, fill it to exactly the degree required to pay the transaction fee in MOB, then bundle that with your original transaction, and it’s as if you paid the fee in the original token.
So overall, the way things are headed, I don’t think we should worry about this:
What we need is to ensure that in such an event, the ecosystem built around the asset type is able to survive the initial creator of the asset type, we do not want people to feel that on the MobileCoin Network all their assets are at risk of disappearing overnight (ethereum smart contracts protect people from this risk).
Editing the tokens.toml file is not going to cause assets to disappear overnight, and in block version 3 they will still be transactable.
Removing a token from tokens.toml has other consequences though, even in block version 3 – it may prevent further minting of that token. Since we primarily designed this for fully-collateralized stablecoins, that’s a concern because minting and burning operations are related to how the stablecoin maintains its peg.
However, if we think through what effect this actually has, it doesn’t actually put the token holders at material risk, because the redemption flow for a fully-collateralized token involves burning, and burning is not impacted by the tokens.toml file. It’s entirely possible after this point that token holders could follow the redemption flow, or use an exchange and trade with people who follow that flow, and fully redeem all their tokens at full value. Preventing the minting of such a stablecoin will not lead to a death spiral in its value.
There are other ways that a fully-collateralized stablecoin can potentially be “censored” – the bank account which holds its reserves, or, the ethereum smart contract which holds its reserves, could be sanctioned. This would be catastrophic for the stablecoin and there’s nothing we could do technically to prevent this. I don’t believe that this form of attack is avoidable for fully-collateralized stablecoins, except through a robust compliance strategy.
I also think that this is ultimately less risky for the token holders than trying to build an algorithmic stablecoin.
—
Overall, I think that you raise a valid point – if for instance, we changed the system so that the tokens.toml file essentially lives on-chain, and the data are updated via e.g. a GovernorTx or similar, then it eliminates a class of attacks having to do with node operators being pressured to modify the tokens.toml. And I see no downside to this arrangement. Since it makes the system easier to understand and think about, it seems like an improvement.
I think the main reason we decided not to do this is that it would have increased the development effort required to ship the feature – we don’t have very well-developed ways of just storing data on-chain right now, because we haven’t historically used our chain that way. Right now it's a fair amount of work to add new types of data to the chain.
Getting our stablecoin out into the world is a major priority for us, so I think ultimately we went with a signed file because it was the simplest thing that seemed like it was going to work.
And I think if you think about the system carefully, I don’t think it has actually introduced a large censorship risk, at least, any more than already exists for fully-collateralized stablecoins.
However, that doesn’t mean we shouldn’t move the tokens.toml data on-chain. I think there are a bunch of other good reasons to do that, like transparency about the state of the file, and removing one of the operational steps required to run a node. I personally would support a change like this. It would require discussion, an MCIP, and prioritization.
Hello,
Reading the MCIPS about confidential token ids, I have a sense that there may be a major censorship vector that may have been overlooked. From what I understand, the transaction fee of every asset type must be stored in a toml file, and if a node wants to join the network with a toml file not matching the consensus, it will not be able to participate in the network.
Now this is an issue because an adversary having geopolitical influence may very well decide to outlaw a particular asset type. The situation may be as simple as the following: an asset type is managed and promoted by a company. For whatever reason, the government decides to go after the company and shutdown their operations worldwide. What we need is to ensure that in such an event, the ecosystem built around the asset type is able to survive the initial creator of the asset type, we do not want people to feel that on the MobileCoin Network all their assets are at risk of disappearing overnight (ethereum smart contracts protect people from this risk).
However right now, node operators can be pressured by law to remove a certain asset type from their toml file, since while they cannot see transactions they have control over that file. The only way to maintain consensus and avoid disrupting the network would be that every time an asset type is under legal attack in a jurisdiction, all nodes currently operating from the jurisdiction must move out of this jurisdiction. This is not a sustainable approach. What will instead happen is that whenever an asset type in outlawed somewhere, the MobileCoin Foundation will instruct all node operators to censor it to prevent fragmentation.
One needs to be realistic: when such a situation happens, the stakes are high and there is typically a lot of passion and emotion from members that will give them a lot of motivation to split the network rather than lose everything they have. Moreover, people watching such a situation play out (and potentially being themselves involved with a number of other confidential asset types) will likely also have strong opinions. I have a sense that this toml file is like the first cell of a malign cancer that will be fatal to the MobileCoin network.
We need to ensure that the choice of using a confidential asset type or not is solely the responsibility of end users. We do not want to put node operators in the position of being the gatekeepers of allowed asset types. To me confidential asset types are the killer feature of MobileCoin, especially with the fact that commissions are paid in the asset type rather than in MOB. So it would be essential to get this detail right.
Is my take on the current implementation correct? What are your thoughts on this risk?