If you’re here, we assume that you’re a developer/hacker who’s intrigued by the blockchain. You’re convinced that you understand how it works and now you’re itching to figure out what the blockchain means for you and your developer skill set.
Our goal in this post is to:
1. Explain how blockchain development differs from existing development paradigms
2. Provide context for the opportunities and challenges in this space
3. Point you to resources that will give you the foundation to start developing in this new paradigm
Paradigm Shifts for Developers
Internet applications benefit from network effects because they maintain centralized silos of information. Built upon shared, open protocols (e.g. TCP/IP, HTTP), companies like Yelp, Facebook, and Amazon benefit from having all of their users – and, as a result, data – in one place. This way they not only have an advantage over competitors with less data but also complete control over the way they monetize the data. In the words of crypto investor Joel Monegro, the current Internet paradigm captures most of its value through fat application layers, whereas the thin, underlying communication protocols capture minimal value.
Alternatively, the distribution of value in the blockchain paradigm can be described with fat protocols and a thin application layer. This paradigm shift is possible due to the innovation of cryptographic tokens, which are described well by Albert Wenger of USV:
“Historically the only way to make money from a protocol was to create software that implemented it and then try to sell this software (or more recently to host it)… With [cryptographic] tokens, however, the creators of a protocol can ‘monetize’ it directly and will in fact benefit more as others build businesses on top of that protocol.”
Previously, the creators of open communication protocols for the Internet, largely DARPA researchers and non-profit contributors, could not align financial incentives with protocol development. In contrast, protocol creators today can issue “tokens”, like Bitcoin and Ethereum, that represent the value of their decentralized protocols.
Monegro believes that this paradigm shift affects the way that developers should think about their applications: “The combination of shared open data with an incentive system that prevents “winner-take-all” markets changes the game at the application layer and creates an entire new category of companies with fundamentally different business models at the protocol layer.”
We’ve come to the understanding that in the blockchain paradigm, developers can capture value through protocol innovation. To continue our discussion, we review how blockchain technologies evolved to eventually cater to developers. Eight years ago, Bitcoin was conceived as a virtual currency that removed the need for centralized financial systems. Initially, developers actually tried building applications upon the Bitcoin blockchain by storing data in the blockchain itself, but it turned out to be pretty inefficient (as described in another old Joel post!). One of these developers, Vitalik Buterin, was frustrated by Bitcoin’s immobilism and risk averse culture for adopting new developer-friendly features. So, he built his own platform, Ethereum.
While Bitcoin was originally intended to serve as a new medium for financial store of value, Ethereum was invented to serve as a Turing complete developer environment. In Ethereum, developers write smart contracts in the Solidity programming language, and those smart contracts are run in the Ethereum Virtual Machine (EVM). Here, we observe an opportunity for developers to fork and implement their own blockchains to serve different purposes. To do so, however, would require rekindling developer support and network effects that existing blockchain technologies had previously achieved. Today, building on top of existing networks like Ethereum allows developers to become stakeholders in not only their own applications, but also the underlying protocol.
Dapps, App Coins, and Smart Contracts
Today’s blockchain developers often build decentralized applications, or dapps, on top of existing protocols to address specific markets and end users. In doing so, developers can issue tokens, or app coins, that are used to execute certain “functions” of the dapps themselves, not unlike Chuck-E-Cheese tokens are used for specific purposes like skeeball. These “functions” are the “smart contracts” that promise a dapp’s services in return for a digital asset, thereby removing the need for a middle-man to ensure the transaction. In other words, smart contracts promise that for one Chuck-E-Cheese token, you can exchange one game of skeeball.
As the functionality of the dapp becomes more sought after, the fixed number of app coins increase in value as a function of supply and demand. In other words, if it turns out that the Chuck-E-Cheese experience is truly remarkable and highly-demanded, the fixed supply of tokens become more valuable. This is the underlying principle that informs all ICOs (initial coin offerings), in which dapp developers solicit investment by offering app coins in return for capital to fund their projects.
But wait, you might ask, “Why not use an existing token as opposed to issuing your own, dapp-specific token in the first place?” Dapp-specific app coins enable small-scale economies that facilitate the application’s purpose. These tokens serve as scarce resources that can be regulated and governed to more closely align with the functionality of a dapp. This is where Ethereum comes back into the picture — with Ethereum, developers can very easily issue their own tokens for the specified use of their own dapps.
With an understanding of the underlying mechanisms of dapps, it’s important to think carefully about how decentralization would benefit your end users. Rather than jumping into a list of side projects, swapping relational databases for blockchain implementations, we urge you to consider the benefits of decentralization. For instance, Augur creates prediction markets by relying on decentralized participants to make correct predictions because they share financial incentives.
At a meta-level, there are also opportunities for innovation in the developer stack. Many blockchain developers liken the maturity of the blockchain tools and frameworks to those of the web during early days of the Internet. We spoke to Ben Yu of Stream, who described this as a new opportunity for developers: “There is extremely low-hanging fruit in making the field more accessible, and a lot of technical infrastructure needs to be built up to bring blockchain from 1994, in internet terms, to 2017.”
With the innovation of the blockchain, many have identified the opportunity to build a new, decentralized web stack that does not depend on centralized government or corporate entities. The traditional web stack is composed of building blocks like TCP/IP, DNS, databases, web servers, authentication systems and CDNs, and we are in the midst of replicating these components by using platforms like Ethereum as the base layer.
Challenges of Immutability
Brandon Millman, an engineer at 0x, described how blockchain immutability affects the way he thinks about security concerns: “Being in this space means being a lot more careful, especially because people’s money is at risk. Part of the benefit of the blockchain paradigm is that if you’re holding onto your private key, it’s hard for people to take money from you, but a lot of scams are getting you to willingly send your money to the wrong place instead of reaching in to steal money from your wallet.”
Developers, especially those accustomed to the fast pace of the startup world, are forced to consider tradeoffs between speed and security. As Ben Yu of Stream describes, “You have to move extremely fast, because the space is going enormously fast, but you can’t move fast and break things, which is the traditional philosophy for development being done now. If you break things, you lose hundreds of millions of dollars.”
Building on the blockchain requires a different level of planning. Developers can no longer apply hot-fixes or overnight patches, because they no longer have centralized control over entire systems. Instead, introducing system changes often involves hard forking entire protocols, or in some cases, providing separate sources for protocol parameters that aren’t tied directly into the blockchain.
Beyond the general challenges of immutability, Ethereum includes several limitations that blockchain developers might encounter. For one, Ethereum is unable to access real time data from outside the blockchain. Developers need to rely on trusted third party data providers, called oracles, to provide smart contracts with outside information like weather, random numbers, or currency values.
Moreover, Ethereum’s specification prevents real-time computations. Processing of block transactions takes upwards of 15 seconds (which is lightning fast compared to Bitcoin’s 10 minutes). As a result, developers need to write asynchronous code with front-end frameworks that can update states accordingly (like React).
With Ethereum, you are also tied to paying for your transactions by the operation with gas that translates into Ethereum’s ether. As a result, using the current version of Solidity, you could very feasibly find yourself hitting a transaction limit if the computation you intend to perform is too expensive (like verifying checkmate in a game of chess). As a result, on-chain computations because become costly in terms of money and network bandwidth. There are interesting alternatives like Truebit to perform more intensive computation off-chain.
In general, it can certainly feel overwhelming getting into this space. It’s an interdisciplinary field, spanning domains of economics, game theory, finance, computer science, math, cryptography, and more. However, that also means that there’s a lot of surface area to contribute.
Brandon of 0x recommends diving into areas where you have some interest or experience instead of trying to learn everything at once: “If you’ve done JS development beforehand, there are a lot of JS libraries that you can contribute to. While you will definitely need to know [how everything fits together] eventually, you don’t need to feel like you need to take an entire course initially.”
In the spirit of decentralization, most of the code for projects on the blockchain are also available through open-source. There are a number of good resources to get your hands dirty:
- The official Solidity docs are a good place to start.
- The Truffle Framework is one of the best solidity frameworks.
- See how tokens and token sales are developed in the zeppelinOS repo, one of the most trusted libraries to build dApps.
- Blockgeeks also provides an in-depth Ethereum token guide with code samples and high-level concepts.
- You can even learn from Crypto Kitties and create your own digital game on the blockchain.
In addition, the developer communities are remarkably receptive and helpful. Check out:
If you learn primarily by coding up your own projects, here are some ideas to get started:
- Build your own wallet. It can be a be a web, mobile app or desktop app.
- Create your own ERC-20 token and deploy it on the test net.
- Modify crypto kitties (dogs, tanks, zombies…) and deploy it on the test net.
In its current state, yes, blockchain development is messy. No, there aren’t clean frameworks and tools analogous to those that exist for modern web development. But why not see the blockchain’s nascent state as an opportunity to impact a paradigm-shifting technology?
On the blockchain, you don’t need to deploy any centralized servers, which means that there’s no single point of failure. If your whole stack is decentralized, there is no trusted third party involved making it censorship resistant, and your database is publicly verifiable. As the new paradigm offers opportunity to publicly share data, we observe a supreme advantage to decentralizing databases. This is the future we’re building towards on the Blockchain— where information and power are distributed systematically by cutting out the middleman.
Thanks to Ben Yu (Stream) and Brandon Millman (0x) for lending their time to be interviewed, and thanks to Niharika Bedekar, Craig Cannon, Claire Shu for reading drafts of this post.