The case for Ethereum: general-purpose vs special-purpose blockchains

[martinBrown]

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.

* Conclusion
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.

[zack]

My understanding of ethereum might be wrong, if so, I hope someone corrects me.
I think that a custom blockchain would have lower fees than building it on top of ethereum.

Particularly the PCA (Principle Component Analysis) step takes about 60 seconds. If it was in ethereum, this step would be very expensive, because every ethereum miner would have to go through the entire 60-second computation. Everyone who ever downloads ethereum in the future will also have to go through the 60-second computation in order to verify old blocks and continue downloading.

By putting truthcoin into it's own blockchain, and using POS rather than POW to verify blocks, most people never have to compute the 60-second PCA. Only the handful of proof-of-stake miners who sign that block, and the next few blocks.

[psztorc]

martinBrown, I'm going to digest your post a little bit.

One thing you might want to look at is that "using the Bitshares Toolkit to build an alt-chain" is surely different from "fork Bitcoin to build an alt-chain", which is different from "build an alt-chain from scratch" which is different from "build an Etherium contract"

Aren't you confusing 1 and 2, for example, when you refer to Bitcoin scrypt?

Particularly the PCA (Principle Component Analysis) step takes about 60 seconds.

Really? On my machine (running an i5, 8 GB RAM), it takes 10.23 seconds on R and in Python it runs almost instantly, for a Vote Matrix of dimension 10000 by 100.

[martinBrown]

Particularly the PCA (Principle Component Analysis) step takes about 60 seconds. If it was in ethereum, this step would be very expensive, because every ethereum miner would have to go through the entire 60-second computation. Everyone who ever downloads ethereum in the future will also have to go through the 60-second computation in order to verify old blocks and continue downloading.

Actually, using Singular Value Decomposition (SVD) should work quite nicely because the SVD computation on the voter-decision matrix has the convenient property of efficient verification (correct me if i'm wrong). That means a TruthCoin contract on Ethereum can outsource the matrix factorization M = UΣV*. Doing this, the only computation run on the ethereum virtual machine (consuming gas fees) is verification by simply multiplying the submitted solution (a triple of matrices: [U, Σ, V]) and checking that it equals the stored voter-decision matrix. Then just pull the first column of the U matrix[1] (and do the post-processing) to calculate the outcome.

But I do agree with the logic of your concern, I even hypothesized here that it will be cheaper to run contract computations on Ethereum forks than on the official chain. Luckily, SVD happens to be efficiently-verifiable and so it should be rather simple to outsource the computations (again, the contract only verifies the solution). But even for messier computations that aren't efficiently-verifiable, they might be outsourcable through SchellingCoin wizardry (see the "Mining for Schells" section). There might be a nice composition here, where efficiently-verifiable SVD is used to measure the consensus answer to messy (*not* efficiently verifiable) computations.

1. described in steps 1 and 2 of section "(v) Operationalized Coordination Using SVD (Figure 3)" in Truthcoin_1.1.pdf.

[psztorc]

You are quite right. It is a matrix-factorization, so given the VoteMatrix (which might need to be sorted in a deterministic way), all that is required is to re-multiply the components and verify that the product is the given VoteMatrix, as you say.

[martinBrown]

One thing you might want to look at is that "using the Bitshares Toolkit to build an alt-chain" is surely different from "fork Bitcoin to build an alt-chain", which is different from "build an alt-chain from scratch" which is different from "build an Etherium contract"

Aren't you confusing 1 and 2, for example, when you refer to Bitcoin scrypt?

I mentioned "Scrypt", the hashing function Litecoin uses for mining (replacing sha256 in bitcoin). Maybe I should have capitalized it, if I wrote "Bitcoin scrypt" anywhere then its a typo. The hashing function "Scrypt" is quite a different thing than the forth-like scripting language and opcodes known as "bitcoin script".

Yes I do agree that 1) using bitshares toolkit, 2) fork bitcoin, 3) alt-coin from scratch, and 4) ethereum contract are all quite different things. But 1, 2, and 3 are fairly similar, they are just different ways (with varying difficulty) to implement a special-purpose alt-chain. The purest, ideal implementation would be done directly in bitcoin script, with the advantage that there's never a need to exchange bitcoins for truthcoins - voting and markets would happen as native bitcoin transactions to any bitcoin address (only the script embedded in the transaction matters, not the input/output addresses). Failing a pure bitcoin script implementation, another option is TruthCoins as colored coins (aka meta-coins or meta-protocol), where the TruthCoins are just fractions of a bitcoin at special addresses that are outputs of one master TruthCoin address (the addresses matter, and are hardcoded in the official TruthCoin client).

The tl;dr is that both alt-chains and meta-protocols are disadvantaged because they are separate blockchains (or separate meta-protocols). Separate chains/protocols fragment the ecosystem, because they are incompatible with the existing decentralized infrastructure, at least until someone implements cross-chain atomic transactions in pure bitcoin script (and I would bet that Ethereum launches before that happens). That means starting a new mining network (even merged-mining with bitcoin would require the cooperation of major mining pools), lobbying centralized exchanges to list TruthCoin (or if its a meta-coin, implementing a decentralized exchange as a feature in your custom meta-protocol), and maintaining the full client/server stack customized around that one single coin (the GUI, the client, the server daemon and rpc-API, a web API, all the plumbing, and so on). Libraries and toolkits like bitshares would help, but you're still duplicating an existing codebase to start a new chain and thus a custom stack. Maintaining all the modified components up-and-down the internals of a custom stack is going to be a tall order (unless you can manage to keep all the needed to changes to a few places in the codebase at only one or two levels of the stack).

I argue that the better option (both for the short-term and long-term) is a native script implementation, which runs seamlessly on an existing stack that would be maintained by a much larger community with overarching goals. A TruthCoin implementation in the native script of a general-purpose blockchain (a "bitcoin 2.0/web 3.0" platform) would greatly simplify the entire process because you'd only have to worry about your custom script/contract(s), not the other layers of the stack. An additional benefit is that you'd get out of the box full interoperability with all other services on that platform.

[toast]

Luckily, SVD happens to be efficiently-verifiable and so it should be rather simple to outsource the computations (again, the contract only verifies the solution).

Who pays for this outsourced comp time, and with which token? Not a counterpoint, just curious about the design.

and maintaining the full client/server stack customized around that one single coin (the GUI, the client, the server daemon and rpc-API, a web API, all the plumbing, and so on).

If you are using an embedded token inside ethereum, wouldn't you also need to do all of this? The ethereum team probably isn't going to be building special-purpose UI elements for every single smart contract in their blockchain or build RPC calls for exchanges to deal with special-rule embedded token, right? The only things you get out of the box are things present in bitcoin or bitshares as well (client/rpc/wallet shells).


It seems we disagree about whether special- or general-purpose is better, but our reasons are almost identical. I'd say, "special-purpose is better because you aren't tied to an existing decentralized infrastructure, so you can optimize around constraints related to the blockchain itself". It just comes back to comparing feature lists in a space there isn't much precedent in.

I suppose time and the market will tell.
IMO the best answer is, "why not both?" (or all four, in this case).

[martinBrown]

Luckily, SVD happens to be efficiently-verifiable and so it should be rather simple to outsource the computations (again, the contract only verifies the solution).

Who pays for this outsourced comp time, and with which token? Not a counterpoint, just curious about the design.

Whoever sends a transaction to a contract pays the gas fee (in ethers) for its execution, this defends the contract against malicious/spam submissions. If the contract issues a sub-currency, then correct submissions would be rewarded with some of that sub-currency (probably a sum reward to be divided equally among all correct submitters). The value of the sub-currency reward would have to greater than the gas fee paid to submit a solution. Following the money, the person paying for the outsourced comp time would effectively be anyone who purchases that sub-currency.

and maintaining the full client/server stack customized around that one single coin (the GUI, the client, the server daemon and rpc-API, a web API, all the plumbing, and so on).

If you are using an embedded token inside ethereum, wouldn't you also need to do all of this? The ethereum team probably isn't going to be building special-purpose UI elements for every single smart contract in their blockchain or build RPC calls for exchanges to deal with special-rule embedded token, right? The only things you get out of the box are things present in bitcoin or bitshares as well (client/rpc/wallet shells).

The Ethereum client has a built-in webkit view (a window similar to a UIWebView on iOS), with js API hooks to access the blockchain. Some functions in the current API are eth.getStorageAt(self.contractAddress) which would be used to get the vote-matrix at the current block, eth.watch(self.contractAddress) to watch for updates at each block and trigger a callback, eth.getKey() to and eth.transact() to create, sign, and send transactions, such as an SVD solution done client-side/off-chain in javascript.

Think of how a web client like blockchain.info works, where there's an API provided by the web server. The web server accepts calls to the API and passes them to the bitcoin daemon (whether bitcoind or bitcoinjs), waits to get the result back from the daemon, then forwards the result along to the user's web browser.

Now instead of a browser opening an HTTP connection to a web server in front of a daemon API, replace all that with a webkit view provided by a native client, with a direct hook API into the blockchain. The contract/DApp author creates the special-purpose UI in html/js, as a client-side html5 app (nothing more than a few html and js files). This is the DApp front-end, a zip of html/js files which call the ethereum hook API functions. The ethereum client opens them up in a webview, displaying to the user some buttons and forms for sending transactions and data to the contract (with access-control to the user's wallet, similar to how iOS apps do a password pop-up for in-app purchases). The back-end is just the contract "hosted" on the general-purpose blockchain.

It seems we disagree about whether special- or general-purpose is better, but our reasons are almost identical. I'd say, "special-purpose is better because you aren't tied to an existing decentralized infrastructure, so you can optimize around constraints related to the blockchain itself". It just comes back to comparing feature lists in a space there isn't much precedent in.

I suppose time and the market will tell.
IMO the best answer is, "why not both?" (or all four, in this case).

Yup, its an open research project and all avenues should be explored. I'm just being polemic for the sake of argument and optimism.

[toast]

Now instead of a browser opening an HTTP connection to a web server in front of a daemon API, replace all that with a webkit view provided by a native client, with a direct hook API into the blockchain. The contract/DApp author creates the special-purpose UI in html/js, as a client-side html5 app (nothing more than a few html and js files). This is the DApp front-end, a zip of html/js files which call the ethereum hook API functions. The ethereum client opens them up in a webview, displaying to the user some buttons and forms for sending transactions and data to the contract (with access-control to the user's wallet, similar to how iOS apps do a password pop-up for in-app purchases).

bitshares clients are also going this route, so the only difference is whether the backend is written in LLL or c++.

So I think Ethereum's advantage here shows for stuff that deals simultaneously with separate contracts / DACs, like cross-chain (cross-contract?) trading between totally disparate chains/contracts. But in either case, both sides have to implement something on their end (and both will have out-of-the-box solutions to let you do it).

I think this is the right approach, Qt-based bitcoin clone UIs are all terrible.

[martinBrown]

bitshares clients are also going this route, so the only difference is whether the backend is written in LLL or c++.

That's good to hear, having the p2p client itself render a qt-webkit html5 view (similarly to node-webkit) is one of those clever yet obviously-good ideas. Although, there is still a big difference between one distributed virtual machine running a lot of different scripts (contracts), and multiple distributed systems each of which has a different protocol. For an idea of the versatility of the scripting approach, consider that there are already three different Ethereum scripting languages so far: Serpent (python-like, for the pyethereum implementation), Mutan (Go-like for go-ethereum), and LLL (assembly-like for cpp-ethereum), all compile to EVM (ethereum virtual machine) bytecode.

So I think Ethereum's advantage here shows for stuff that deals simultaneously with separate contracts / DACs, like cross-chain (cross-contract?) trading between totally disparate chains/contracts. But in either case, both sides have to implement something on their end (and both will have out-of-the-box solutions to let you do it).

Contracts are by definition all on the some chain, as long as they don't use separate meta-protocols they are inherently compatible so saying "cross-contract" makes it sound more impressive than it is. Its like pointing out that bitcoin addresses can cross-transact with each other, ie that multi-sig bitcoin transactions (somewhat-complex contracts) are backwards-compatible with common single-sig ones (trivial contracts).

Cross-chain atomic transactions (as in database transaction, a more general concept than trading) would be a bigger technical advancement. Eg if separate bitShares chains were all capable of doing cross-chain atomic transactions with each other, that kind of protocol-compatibility would be something to brag about (but please not in the all-too-common way entrepreneurs in this space tend to oversell their products, and claim to have features long before they are actually implemented).

[martinBrown]

This is a diagram from Gavin wood's presentation (the c++ client developer), here's just the slides.

[Bitcoinfan]

Article on Gavin's view on Ethereum.  Truthcoin is also mentioned briefly.   

http://www.cryptocoinsnews.com/news/gavin-andresen-outlines-bitcoin-2-0-without-ethereum/2014/06/09

[toast]

Eg if separate bitShares chains were all capable of doing cross-chain atomic transactions with each other, that kind of protocol-compatibility would be something to brag about (but please not in the all-too-common way entrepreneurs in this space tend to oversell their products, and claim to have features long before they are actually implemented).

Of course we cannot brag before we have it but atomic cross-chain trading is a critical feature and essential to having a powerful market peg for all chains that implement BTS X. It had been implemented in previous alpha iterations and it was in the original whitepaper long before "bitshares" was given a promotion to refer to all chains and not just what is now called the BTS X family.

edit:  ah, I just saw cross-chain atomic *transaction* and not trading. NVM, we do not have that planned for the short term.

[toast]

Contracts are by definition all on the some chain, as long as they don't use separate meta-protocols they are inherently compatible so saying "cross-contract" makes it sound more impressive than it is.

What sort of contracts wouldn't use meta-protocols? For an autonomous system to be a proper value-adding mechanism doesn't it need to have total sovereignty over its native token, otherwise it is at best a service like coloredcoins, right? Do you expect Ether to be used as the unit of account for the most popular dapps?

[martinBrown]

Contracts are by definition all on the some chain, as long as they don't use separate meta-protocols they are inherently compatible so saying "cross-contract" makes it sound more impressive than it is.

What sort of contracts wouldn't use meta-protocols? For an autonomous system to be a proper value-adding mechanism doesn't it need to have total sovereignty over its native token, otherwise it is at best a service like coloredcoins, right? Do you expect Ether to be used as the unit of account for the most popular dapps?

When I said "contracts that use separate meta-protocols", I was talking about "contracts" such as MasterCoin features or CounterParty features, e.g. you can't trade user-issued CounterParty assets on the MasterCoin order books.

Ethereum contracts don't use meta-protocols, they all use the same set of opcodes, and communicate between each other with the CALL opcode for calling another contract (send a message, let it execute, get the response). For a contract to issue a user 1000 units of its sub-currency, it would just have the line this.storage[userAddress] = 1000. Only the contract can modify its storage, so it has total control over its token. But it could also provide free services (minus gas fees) even to users that don't have any of the sub-currency, so e.g. a name registration contract could have a tier of first-come-first-serve free (minus gas fees) usage for names longer than 5 characters, and a paid tier which requires payments in the sub-currency for names of 5 characters and under. My point is that a sub-currency is just a variable in a contract's storage, it only becomes a sub-currency when the other lines of script treat that variable as if it represents user balances. One contract could maintain 5 different sub-currencies, all at the same contract address. So its very flexible and arbitrary, not at all inherent to the structure of ethereum contracts.

Whether it will be more popular for DApps to use native Ethers (for more than just gas fees) or to issue their own sub-currencies is a very good question. I'm still chewing on this, but my initial thoughts are that for DApps which have their own-subcurrencies, the exchange process for Ethers->DApp-tokens will need to be seamless/frictionless, otherwise most users will ignore it (just as most people ignore most alt-coins).