This started out as a response to "The case for building on bitshares_toolkit", but I got a bit carried away and ended up with the epic wall of text you see below. I'm going to cross-post it to r/ethereum
, but I hope here to spark a discussion specifically about TruthCoin, and the advantages that a TruthCoin DApp on Ethereum would have over a special-purpose alt-chain.
* Bitcoin and Alt-coins are Special-Purpose Chains
What's the difference between a general-purpose blockchain and a special-purpose blockchain? Let's start with bitcoin, the original special-purpose chain for computing and comparing sha256 hashes. Bitcoin users started the chain by mining on generic x86 (general-purpose) CPUs. But because sha256 hashing is a specific computation, btc mining is now dominated by Application Specific Integrated Circuit (ASIC) hardware. Litecoin is another special-purpose chain, except it computes scrypt hashes (some manufacturers are already started shipping scrypt ASIC miners). There's also a Primecoin for computing prime numbers
, and a bunch of other special-purpose chains commonly known as alt-coins.
* Special-Purpose Chains: Backend and User Perspective
How does it work when we want to use the services provided by separate special-purpose chains? Let's look at the granddaddy of alt-coins, namecoin, which like bitcoin uses sha256 hashes. Additionally, it also provides some standard namecoin script opcodes for associating plaintext pseudonyms with unique addresses (public/private keypairs), so namecoin addresses can register and "own" domain names or identities/handles. Let's say you want to use bitcoins to purchase a namecoin .bit domain that its owner is selling. What does it take to get these two special-purpose blockchains (bitcoin and namecoin) to interact with each other? The immediate option (and the only one available today) is a centralized service running a web server in front of both p2p daemons (as nodes of their respective networks, bitcoind and namecoind). That centralized service is a BTC/NMC exchange, and maybe it has an interface allowing you to register "dot-bit" names (otherwise you'd have to open up two separate wallets - one for each coin). The centralized exchange is a trusted third-party that holds in escrow the BTC and NMC of each user (whose coins could be stolen by a dishonest exchange operator).
* A General-Purpose Chain: Backend and User Perspective
So how is using a unified general-purpose chain different from a special-purpose one? On the Ethereum general-purpose chain, each service is provided by some "DApp" (distributed app "hosted" by all ethereum miners). A DApp is an interface to a specific "contract", running at some address on the blockchain. For instance, to register a name, you would open the EtherNames DApp in the ethereum client's built-in browser, type in the name you want to register, and "send" the registration as a transaction with data. There's no need to copy and paste addresses since the Ethereum client provides hooks for seamless wallet access inside every DApp. The registration transaction is sent to the EtherName DApp's contract address, which is running some variant of the namecoin contract code
. A specific contract gets initialized at a particular address by some untrusted third-party individual/entity (the DApp author). The contract author is *not trusted*, all the author does is upload the contract code and pay the initial "gas" fee
. The contract code is independently executed and verified by each ethereum miner as part of a single atomic transaction. Atomicity
means that the ledger database updates are all-or-nothing, so no user has to worry about the risk of having to pay first because any and all transactions needed to fulfill a contract are guaranteed to occur within the same block, or the contract is broken and won't run at all. Think of Ethereum contracts as interconnected threads in a big web of complex multi-sig transactions of Ethers and contract-specific sub-currencies, all of which run atop the same unified blockchain.
* Special-Purpose Chains: Developer Perspective
From the developer's perspective, operating a service that uses two separate special-purpose chains requires maintaining both blockchains (upgrading separate software, providing enough processing power, disk space, and bandwidth for each chain). It also requires maintaining user accounts, as well as wallets on two separate chains (multiplied by the number of users). Hosting a server is needed to run both the namecoin daemon and bitcoin daemon (unless outsourced to a centralized API). The web developer will need to maintain a web server and app stack such as LAMP (Linux Apache Mysql Php) or MEAN (Mongodb Express Angular Node). Finally, the service must hold the users' deposits of bitcoins and namecoins in secure hot wallets and offline cold storage, keeping them safe from hacker thieves. Altogether, every service operator needs to independently maintain a separate full-stack system, which can be a herculean effort.
* A General-Purpose Chain: Developer Perspective
A service operating on Ethereum has a DApp backend hosted right on the blockchain, maintained by miners (who earn gas fees). A developer simply authors the contract code and pays the gas fee to initialize it on the blockchain, which is much easier than forking an alt-coin to start yet another genesis block. DApp's do not need a separate API for access and integration by other developers; authors just name functions inside a contract, directly exposing an API (with optional fee-per-use) that enables message calls from any other Ethereum DApp. Also, DApp authors do not need to maintain user accounts, since the users interact with the DApp directly on the blockchain through their ethereum addresses. Nor do DApp authors need to maintain user wallets since private keys stay private in a decentralized system. Unlike the current convention where coins are deposited to a wallet address controlled by some third-party, in a truly decentralized system private keys are only used for signing transactions as inputs to contracts.
* Meta-Coins as Feature Specs
Meta-coin protocol extensions like Colored Coins, MasterCoin, and CounterParty work by organizing a group of users who agree to interpret bitcoin transaction data according to some metadata specification, supplementing the base rules of the bitcoin protocol. For example, MasterCoin specifies creating multisig 1-of-n bitcoin transactions and encoding data in the n-minus-1 unused public keys. In the meta-coin approach, each feature or "contract" is specified in the meta-protocol. Two MasterCoin features are registration of a data stream and the creation of a sub-currency, these are baked into the specification and reference client alongside the other features. While you can register new data streams and sub-currencies, if you want to create a new contract that is some kind of a hybrid between a data stream and a sub-currency, such as a call/put option or a Contract For Difference (CFD), it would need to be implemented directly in the reference client, and unlocked as a feature
at some future block number. Implementing new features in a meta-coin protocol that doesn't have a scripting language
requires specifying them directly in the protocol and must be effected at the organizational level.
* Scripts and DApps vs Forks and Features
Embedding a scripting language into a crypto-currency gives it the same kind of extensibility that gamers crave in video games. Scripts empower players to create "mods" and customize their game-world with new levels, characters, and maps. In the crypto-currency world, scripting allows for the extension of a plethora of decentralized features such as trading, lotteries, and ecommerce, all atop a shared, compatible platform. Bitcoin has a scripting language, but with severe limitations including: lack of loops, binary state variables limited to spent or unspent transaction outputs, and blockchain blindness
. The difficulty of using bitcoin script has in effect given rise to a landscape of competing alt-coins and meta-coins with incompatible protocols. The preferable route, and vision of Ethereum, is to foster a fully-featured ecosystem of compatible, interacting DApps. Providing a Turing-complete scripting language on a general-purpose blockchain with message calls between contracts
stimulates adoption of Ethereum as a shared decentralized Operating System and kernel.
* Decentralized House, Decentralized Dealer
Consider the concept of a decentralized lottery. In a semi-decentralized lottery that is merely provably fair
, although the operator is not capable of altering any particular dice outcome, he can simply shut down the service immediately after a big winning bet comes in, scamming the user of his money and winnings. But in a fully decentralized lottery, the mechanism for distributing the winnings is written into the contract itself (open-source and audited by users), so no central operator is needed. While writing such a contract in bitcoin script is theoretically possible (see pages 12-15)
, to my knowledge none has been implemented. In practice, it is easier to create a LottoCoin as a special-purpose alt-chain
. In contrast, writing a script on the Ethereum platform for a fully decentralized lottery is not only feasible
but relatively easy
The limitations and difficulties of using bitcoin script to implement decentralized features natively on the bitcoin blockchain has resulted in a fragmented ecosystem of incompatible, competing alt-chains and meta-coins. While it is theoretically possible to use bitcoin script for complex contracts like cross-chain atomic trading
, practical implementations of such features have yet to be achieved (to my knowledge). On the other hand, Ethereum focuses on providing an easy-to-use scripting language for implementing advanced contracts on a general-purpose blockchain. Ethereum's extensible platform enables the realization of advanced decentralized features that previously were inaccessible.