The Key to Attracting More Blockchain Developers? It’s the Computation, Stupid

The cryptosphere is suffering from a talent drought. Despite all the entrepreneurs, visionaries, gurus, whizkids, architects, and pioneers who have piled in over the past decade, there is still one critical area where the industry is underserved: developers. There is a desperate shortage of skilled blockchain developers capable of operating at the protocol and application level.

These engineers of base layer protocols and the decentralized applications built atop them are the drummers of the blockchain world: the backbone that holds the band together. Without the ability to attract and retain the next generation of blockchain devs, the industry’s ability to innovate could be set back years. Solving this problem calls for some out of the blocks thinking.

Cracking the Computation Problem

As dApp developers will attest, the impediments to crafting decentralized apps don’t always become manifest at first. It’s possible to deploy an on-chain application without any hiccups, only to run into trouble further down the line once the app, the network it’s hosted on, or both become busy. That’s when the real problems begin.

Blockchains, by their nature, are designed to provision limited resources. Creating multiple copies of data and storing it on a distributed ledger scattered around the world isn’t efficient. As such, a fee market exists for network users, who must compete for scarce block space or resources, such as virtual RAM or CPU on EOS. Due to the volatile and fluctuating nature of these resources, in line with market demand, developers have no guarantee that their dApp will remain viable.

Grappling With Layer Two

To tackle blockchain’s computational problem, engineers have sought to direct the bulk of the demand up the stack, to layer two solutions, and outside of the stack, to sidechains that can perform computation away from the main chain. This can significantly lower resource costs and slash on-chain fees, but it does add another layer of complexity for aspiring blockchain devs to master. In a bid to surmount this problem, a number of initiatives have sprung up seeking to even the playing field between blockchain and traditional operating systems, providing a means for developers to switch from the latter to the former, without incurring a massive knowledge leap in the process.

Bridging the Blockchain Gap with Linux

Cartesi, for example, is a layer two infrastructure that’s seeking to bring operating system infrastructure to a blockchain environment – Linux in this case. The project was established with the goal of making the development of decentralized applications as close as possible to their centralized counterparts. The company believes that assigning developers a “decentralized Linux” to experiment with will give rise to a new wave of dApps.

Cartesi does more than simply provide a welcoming environment for developers to operate in: it also overcomes key drawbacks to utilizing existing layer two solutions such as Plasma and State Channels. These systems can result in heavy computational loads being relayed to the mainchain, or require the mainchain to resolve disputes that occurred on the second layer. When these solutions are used in conjunction with Cartesi, the mainchain can cheaply settle any disputes through Cartesi’s interactive verification procedure, which makes the cost of settling disputes negligible, even when dealing with complex contracts.

Through presenting the familiar environment of Linux in the unfamiliar world of the blockchain, Cartesi’s architects hope that a wave of developers will be tempted to experiment with dApps. It’s a theory that holds some weight. As co-founder Balaji S. Srinivasan has ventured, “A flag is something to align around. Bitcoin is many people’s first choice and many people’s second choice, which means it will become the community’s first choice. The closest analogy is Linux. Google & Facebook are tough competitors, but
cooperate on Linux.”

An influx of users can push up the costs of provisioning on-chain resources, making it impractical to continue supporting the app; alternatively, on networks such as Ethereum, rising on-chain costs due to network congestion can make it too expensive to complete transactions within the dApp, again jeopardizing the work that the development team has put into crafting it, and leaving communities frustrated. Solve the uncertainties surrounding blockchain’s computational problem and developers will be much more inclined to tinker with dApps and to stick around for the long haul.

Make Them an Offer They Can’t Refuse

In 2017, when ICO mania was at its height, Ethereum developers were at a premium. Even a run-of-the-mill Solidity developer capable of throwing together a token contract could bill three figures per hour without raising any eyebrows. The ICO craze has since abated, but demand for blockchain devs has not. In fact, due to the array of second and third-generation blockchains that have sprung up since, each seeking to spawn its own developer ecosystem, the range of chains and programming languages vying for developer talent has proliferated.

For developers contemplating taking the plunge and pledging fealty to the blockchain, there needs to be incentives to switch, and these aren’t necessarily financial – nor are they ideological, in most cases. Developers are inclined to start working with decentralized protocols for pragmatic purposes, which means lowering the technical barriers to entry. Ideally, it should be as easy to create a dApp as it should be to launch an app. When that threshold is reached, expect to see an explosion in the development of decentralized applications, as programmers combine the benefits of Web3 technologies – censorship-resistance, data privacy, certainty of access – with the ease of deployment that now comes as standard for conventional mobile apps.

Building the Block Tower of Babel

In addition to creating a familiar environment for developers to work in, blockchain also has a language problem to overcome. Today, there are hundreds of smart contract networks vying for developer talent to build up their respective ecosystems, each of which requires mastery of its own programming language. From Solidity to Go and C++ to Rust, there’s no common consensus over which languages are best suited to blockchain. As a result, developers are constrained with working with only a few spokes of the blockchain wheel at most, or are obliged to master new programming languages should they wish to switch chains.

At the moment, the decentralized web being constructed in fits and starts across competing blockchains, DAGs, and distributed ledgers is a babble of incompatible languages and implementations, keeping developers stranded on islands when they should be free to hop from point to point, crossing chains with impunity and bridging parallel ecosystems effortlessly. That utopian vision is still very much a work in process. In the meantime, provisioning cheap and accessible blockchain computation is the first step towards onboarding developers in their droves.

3 thoughts on “The Key to Attracting More Blockchain Developers? It’s the Computation, Stupid”

  1. You’re right, it’s a massive waste of energy and a huge contributor to global warming. It needs to be eliminated.

  2. Ethereum is transitioning to proof of stake, which will eliminate that energy consumption almost entirely. First phase should reach production first quarter next year.

  3. Block chain is a huge consumer of computation and energy resources that should be avoided whenever possible. There are other mythologies that can be use to increase security, and they can be developed further.

Comments are closed.