One common design philosophy among many cryptocurrency 2.0 protocols is the idea that, just like the internet, cryptocurrency design would work best if protocols split off into different layers. Under this strain of thought, Bitcoin is to be thought of as a sort of TCP/IP of the cryptocurrency ecosystem, and other next-generation protocols can be built on top of Bitcoin much like we have SMTP for email, HTTP for webpages and XMPP for chat all on top of TCP as a common underlying data layer.
So far, the three main protocols that have followed this model are colored coins, Mastercoin and Counterparty. The way the colored coins protocol works is simple. First, in order to create colored coins, a user tags specific bitcoins as having a special meaning; for example, if Bob is a gold issuer, he may wish to tag some set of bitcoins and say that each satoshi represents 0.1 grams of gold redeemable from him. The protocol then tracks those bitcoins through the blockchain, and in that way it is possible to calculate who owns them at any time.
Mastercoin and Counterparty are somewhat more abstract; they use the Bitcoin blockchain to store data, so a Mastercoin or Counterparty transaction is a Bitcoin transaction, but the protocols interpret the transactions in a completely different way. One can have two Mastercoin transactions, one sending 1 MSC and the other 100000 MSC, but from the point of view of a Bitcoin user that does not know how that Mastercoin protocol works they both look like small transactions sending 0.0006 BTC each; the Mastercoin-specific metadata is encoded in the transaction outputs. A Mastercoin client then needs to search the Bitcoin blockchain for Mastercoin transactions in order to determine the current Mastercoin balance sheet.
I personally have had the privilege of talking directly to many of the originators of the colored coins and Mastercoin protocol, and have participated considerably in the development of both projects. However, over about two months of research and particpation, what I eventually came to realize is that, while the underlying idea of having such high-level protocols on top of low-level protocols is laudable, there are fundamental flaws in the implementations, as they stand today, that may well prevent the projects from ever gaining anything more than a small amount of traction.
The reason is not that the ideas behind the protocols themselves are bad; the ideas are excellent, and the response of the community alone is proof that they are trying to do something that is very much needed. Rather, the reason is that the low-level protocol that they are trying to build their high-level protocols on top of, Bitcoin, is simply not cut out for the task. This is not to say that Bitcoin is bad, or is not a revolutionary invention; as a protocol for storing and transferring value, Bitcoin is excellent. However, as far as being an effective low-level protocol is concerned, Bitcoin is less effective; rather than being like a TCP on top of which one can build HTTP, Bitcoin is like SMTP: a protocol that is good at its intended task (in SMTP’s case email, in Bitcoin’s case money), but not particularly good as a foundation for anything else.
The specific failure of Bitcoin is particularly concentrated in one place: scalability. Bitcoin itself is as scalable as a cryptocurrency can be; even if the blockchain balloons to over a terabyte, there is a protocol called “simplified payment verification”, described in the Bitcoin whitepaper that allows “light clients” with only a few megabytes of bandwidth and storage to securely determine whether or not they have received transactions. With colored coins and Mastercoin, however, this possibility disappears. The reason is this. In order to determine what color a colored coin is, you need to not just use Bitcoin simplified payment verification to prove that it exists; you also need to trace it all the way back to its genesis, and do an SPV check each step of the way. Sometimes, the backward scan is exponential; and with metacoin protocols there is no way to know anything at all without verifying every single transaction.
And this is what Ethereum intends to fix. Ethereum does not intend to be a Swiss Army knife protocol with hundreds of features to suit every need; instead, Ethereum aims to be a superior foundational protocol, and allow other decentralized applications to build on top of it instead of Bitcoin, giving them more tools to work with and allowing them to gain the full benefits of Ethereum’s scalability and efficiency.
bitcoinmagazine: SOURCE: Ethereum: A Next-Generation Cryptocurrency and Decentralized Application Platform
