Thoughts on Tokens for BCH
There is a clear market for tokens. Cryptocurrency is a quarter trillion dollar market and we can see that all kinds of projects are being developed and promoted. In addition, the popularity of "piggybacking" on solid blockchains is obvious (ERC20 tokens on ETH being the obvious example).
It is good for the BCH blockchain to get some of that market share. It would mean more publicity for BCH, more popularity, more usage, and more value. BCH needs every competitive advantage that it can get, as long as we're not doing anything to jeopardize the basic use case of peer to peer electronic cash.
Despite all the scams and frauds we see in the larger cryptocurrency community, there are legitimate uses for tokens. Even as some developers express doubt over the use-cases for tokens, they are clearly identified in both the GROUP proposal and the Tokeda proposal.
As many of the use-cases have been discussed, I won't waste time reiterating them, but we can see the market demanding and using tokens more. The Binance and CoinEX exchanges have their own tokens now.
The Current Debate
In the BCH development community, the current debate is between Andrew Stone's GROUP proposal and adopting one or more token proposals that don't require any BCH protocol change (such as Tokeda).
In basic terms, GROUP expands the transaction layer of the protocol to allow tokens by adding a special output to a transaction called a group authority UTXO. The GROUP proposal is the evolution of OP_GROUP. I had previously criticized OP_GROUP for breaking the abstraction layer between script and consensus. GROUP proposal fixes this concern.
My other chief concern would be if this proposal changes the economic incentives for miners. If enforcing the GROUP consensus rules is not more computationally expensive on a per byte basis, then I would argue that the economic incentives have not changed, since fees in Bitcoin are priced in bytes.
Determining whether it or isn't actually more computationally expensive would require analyzing and/or testing a specific reference implementation of the proposal.
Unlike with OP_GROUP, I have not heard technical arguments that point out something specifically wrong with the GROUP proposal. The main concern that other developers have is that the change is somewhat substantial to the BCH protocol. This naturally comes with risks of unknowns, along with technical complications, technical debt, and "unhardening" of the protocol.
A question was raised how GROUP will affect UTXO growth, and I haven't seen an analysis of this.
Risk vs. Reward
Token proposals need to be evaluated on a risk/reward basis. How much benefit does each proposal bring to BCH, and how risky is each one? Proposals that do not require modifications to the BCH protocol essentially have zero risk, since they aren't changing anything. So the question then becomes: How much risk does GROUP represent, and what does it provide that is better than the alternatives?
The main benefit of GROUP over other proposals seems to be that it is "SPV friendly". To understand what this means, you should understand the SPV security model. With SPV, a user can determine if a transaction is valid by checking the transaction against the merkle branch and the block headers.
Presumably, GROUP supports SPV because transactions that move tokens are enforced by miners; therefore if the token trasnfer is part of the transaction, and the transaction is part of the block, then the token transfer is inferred to be valid.
Alternative SPV token models
In the absence of something like GROUP, the challenge is that verifying if a token transfer is valid requires parsing the entire chain of transactions back to the origin of issuance. For token proposals that don't modify the BCH protocol, how can we accomplish this? One way is to have service nodes ran by the issuers or others that want to support the token ecosystem.
One such class of service provider could be BitDB-powered nodes.
Permissionless vs Permissioned Tokens
There is some talk of a 'permissioned' token scheme where the token issuer signs off on transfers. By providing a signature at each transaction, this solves the SPV question. The argument in favor of this scheme is that a token issuer already needs to be trusted to provide whatever value their token represents, so nothing is lost by also relying on them for transfers.
I find these arguments to be specious.
Just because the token issuer needs to be trusted to redeem the token does not mean there isn't a value in making transfers permissionless.
Also, the whole point of using a blockchain is to allow distributed consensus. If instead, consensus depends on what a central authority decides, why use a blockchain?
This logic is reflected in the reality of the markets. Permissioned tokens on a public blockchain do not even exist. There's zero demand or market for it. (At least no one so far has given me any examples. Please correct me if I'm wrong).
On the other hand, there's a quarter trillion dollar market for crypto tokens. Promoting the idea that the market really wants permissioned tokens over permissionless tokens when the reality says the opposite is in the territory of delusion.
However, it should also be pointed out that the need to support permissionless tokens does not necessarily mean we need GROUP.
A Universal Token Standard for BCH
Something like BitDB could be used to allow SPV wallets easy access to token balances could perhaps accomplish what GROUP seeks to do without a protocol change.
But there needs to be probably be ONE agreed upon standard. With tokens, the scaling burden on a BitDB style node is multiplied. Instead of maintaining one UTXO set, it now needs to support "N" UTXO sets, where N is the number of unique tokens. This is not unfathomable, but at the very least there should be a universal method used across all tokens so that the same rules could be easily applied to the meta data.
Whether or not we should change the BCH protocol to add GROUP is a risk/reward question and a matter of opinion.
Part of what made ERC20 so successful is how easy it is for anyone to create and issue a token, and for the ecosystem to support it. The BCH protocol already allows colored coins but no one uses it because the ecosystem doesn't support it.
One nice thing about GROUP is that by adding it to the protocol, the ecosystem would more easily adapt to support it, and you could argue that this also part of the ERC20 success.
However, this is not a strict necessity.
The ecosystem could adapt by convention, perhaps driven by a service provider such as BitDB. I would personally recommend we explore such an option. In any case, I believe BCH would greatly benefit from a universal method for doing SPV-friendly, permissionless tokens.
21 of 21 reviewers say it's worth paying for
0 of 21 reviewers say it's not worth paying for