The Smart Contract Network Effect Fallacy

by Kyle Samani

Ethereum is unquestionably the market leading smart contract platform. It’s the oldest and most mature. It likely has the best protocol developers and certainly has the best community. Developer interest is surging. Major companies are investing in the platform. It has a clear roadmap. It’s led by one of the brightest minds of our era.

At current prices, the combined network value of all of Ethereum’s competitors is about 10-15% of Ethereum’s network value.

Market prices imply that Ethereum has a strong network effect. Ethereum presents itself as the “world computer,” which naturally begs for OS-like analogies: the more developers use Ethereum, the more users will want Ether, which encourages more developers, etc.

This analogy doesn’t capture the nuance of the dynamics at play. Smart contract platforms like Ethereum should not be compared to operating systems, but rather to programming languages.

Specifically, the OS analogy misrepresents the network effects for the supply side (why should developers choose Ethereum) and demand side (why should users buy Ether). Concerns about network security are valid, but can be largely mitigated through cross-chain anchoring.

I’ll walk through each of these fallacies below.

Demand Side – Users Won’t Care

Operating systems create network effects because users make a mutually exclusive decision to use one OS at the expense of not choosing another OS. You cannot run Windows and Linux on your desktop (ignoring virtual machines since only a small minority of users have a need or technical ability to leverage virtual machines effectively).

Since users are locked into an OS, developers naturally develop for the OS. This creates more and better apps for the OS, which draws in more users. The virtuous cycle flourishes.

Users won’t have to know or care about which blockchain they’re interacting with. To most users, blockchains will be abstracted to “please enter your password to verify your transaction.”

As a user interacting with distributed applications (Dapps), you will never “see” a blockchain. All you will see is a web3 front end that triggers an on-chain transaction using a tool such as Parity or Metamask (for the rest of this post, I’ll refer to these types of tools as web3 clients even though web3 is technically Ethereum-specific). Although web3 clients don’t yet exist for non-Ethereum chains, they’re being built and will be available soon, and they’ll support multiple chains. In time, browsers will natively implement multi-chain web3 clients.

Web3 clients themselves can abstract this problem even further. As web3 clients implement support for many chains, they’ll also integrate decentralized exchanges such as Shapeshift and 0x. As a user, if you try to interact with a Dapp that requires Stratis tokens, but you only have Ether, your web3 client will seamlessly sell your Ether for Stratis on an exchange in real time. Then the web3 client will send those Stratis tokens to the Dapp. As a user, you won’t know or care about the underlying token at all.

Your web3 client will generate a mnemonic seed that’s used to derive private keys, public keys, and addresses for all supported chains. As a user, you’ll only have to memorize/store one “password” and everything else will be seamless.

To sum up all of the above, as a user, you won’t have to care what chain or token you’re using. All Dapps will, regardless of underlying technology platform, just work. All chain and token complexity will be abstracted away.

Supply Side – Interoperable Tokens Commoditize Chains

With any two smart contract platforms, tokens can roam across chains. ETH tokens will not be bound to the Ethereum chain. Stratis tokens will be available on the NEO chain, and Tezos tokens will be available on the WAVES chain.

How? Synthetic tokens.

Imagine a two known smart contracts, one on the ETH chain, one on the ETC chain. If I want to move X ETH tokens to the ETC chain, I send some ETH to that contract on the ETH chain and specify my ETC address. When the ETH contract receives my ETH, something like Cosmos will trigger the ETC contract to release X tokens to my ETC address. Those synthetic tokens can also be called ETH. This system works in both directions.

(I recognize this diagram doesn’t correctly portray how smart contracts issue tokens on a technical basis, but it’s still useful to illustrate how assets move across chains)

This function will level the playing field between chains. When any coin will run on any chain, why care about the chain or the token at all? A lot of complexity gets abstracted away.

Note there is one obvious downside to this mechanism: gas costs on each chain must be paid in the chain’s native currency. However, gas costs shouldn’t be significant on a % basis. If more than .1-.2% of transaction volume is being paid in gas, the chain itself will probably fail. In light of the framework I proposed above, the “how does a user pay for gas?” question is legitimate, but not substantial in impact relative to the gains of token-chain abstraction.

Mitigating Network Security Risks Through Cross Chain Anchoring

As a token loses network value, risk of 51%-style attacks increases. This is obviously true for proof-of-stake consensus systems. It’s also true for proof-of-work consensus systems as miners choose which coins to mine based on cost to mine vs value of the coin.

But even network security risk can be mitigated through cross chain anchoring. Ethereum is adopting this mechanism in Plasma by committing merkle roots from child chains to parent chains. This is live in Factom today: Factom anchors a merkle root of its own chain to every Bitcoin block.

In time, we’ll start to see most chains anchor themselves to other chains as a form of risk mitigation. Attacking a network will require attacking all anchored networks. This is exponentially more difficult than attacking a single chain.

Smart Contract Platforms Are Like Programming Languages

If users won’t care about underlying chains, if the tokens are instantly and seamlessly tradeable, if tokens themselves roam across chains, and if network security can be maintained, what avenues of differentiation are left between chains? Basically, dev tools and governance mechanisms.

Stratis has a singular focus: make it as easy as possible for C# devs to build using blockchains. There are millions of C# developers today, most of whom probably don’t want to learn Solidity (native Ethereum language) or Ocaml for Tezos. You could argue that C# developers are being irrational and should learn languages that are designed specifically for blockchains. For example, it’s unlikely that Stratis will be able to implement formal verification since C# wasn’t designed with formal verification in mind.

On the other hand, Javascript was developed as a front end language, but is now one of the most popular back end languages courtesy of Node.js. Some developers hate loosely typed languages like Javascript. Others hate statically-typed language likes C.

Even though all of the major programming languages today provide Turing-completeness, the market has empirically demonstrated a need for many programming languages with unique tradeoffs (readability, compiled vs interpreted, abstractions, memory management, native performance, parallelizability, etc).

A single blockchain shouldn’t dictate the rules and mechanics of all smart contract development. Given the lack of strong network effects, many smart contract platforms will thrive.

Now let’s turn to governance. Dash has had on-chain governance for a few years. By all accounts, it seems to work rather well. Tezos has presented a variation of Dash’s on-chain governance. The Dash community is thriving, innovating, and growing. On-chain governance may be what blockchains have always needed but never had.

There aren’t any historical counterfactuals to prove this case. Bitcoin has obviously faced serious governance challenges in the last couple of years, but many open source projects have thrived in the absence of on-chain governance. The Linux kernel, the many Linux desktops, Firefox, Wikipedia, Chrome (and all of its forks), the Android Open Source Project (and all of its forks), WebRTC, Ethereum itself, and many other open source projects have succeeded without a formal stakeholder engagement model.

Summary

Current market prices imply that Ethereum is going to be the runaway market leader for smart contract platforms. This is not a given. There are many secular trends at the demand level, supply level, and security level that commoditize most of Ethereum’s perceived advantages. Ethereum will not be the sole smart contract platform. That’s not to say Ethereum isn’t here to stay or that Ethereum won’t thrive. I wouldn’t bet against Ethereum. But there will be huge opportunities for non-Ethereum smart contract platforms. Ethereum will not be the one smart contract platform to rule them all.

Update – May 9th, 2018

Since writing this post, I’ve come to the realization that the premise of this post is correct – that smart contract platforms have little if any network effects – but that the conclusion of this post – that dev tooling is what matters and that smart contract platforms are like programming languages – is incorrect. Dev tooling and features will be copied across chains too.

In the spiritual successor to this post, On The Network Effects Of Stores Of Value, I argue that the only way to achieve meaningful network effects is for an asset to become both a store of value and a medium of exchange.