Start here

Have more questions? Submit a request

Consensys has built protocols, applications, and frameworks that have been instrumental in creating the rapidly iterating world of blockchain networks and web3. In these articles, we will show you how to leverage those tools, one step at a time, to build your own part of that ecosystem. We recommend you follow them in order, but hey--this is web3, you do you.

Welcome to web3 development: a mixture of familiar tools, protocols, and processes alongside modern implementations of tried-and-true cryptographic standards, all set to the low-key non-stop madness of global open-source collaboration. Some of these elements you may already use every day; some you may need to brush up on. If you're new to this space, you'll need to learn the 'crypto-native' ones from the ground up; for example, the question of which network.

The importance of network choice: speed up development, avoid technical debt

Throughout this guide, you will see references linking you to the Network Node. This standalone section walks you through what is probably the most important architectural decision you have to make when developing in web3: the network, or networks, on which you will deploy your application.

On a certain level, you “don’t need to worry about that until you deploy”; on the other, if you have a clear idea of which network you’re designing against, you can make choices early on that will save you huge amounts of time. Not all blockchain networks are the same from a developer’s perspective, and certain use cases or design requirements on the app side can force you towards one network rather than another.

It’s well worth your time to familiarize yourself with these considerations up front, so that you have an accurate understanding of your development roadmap and requirements. 

Jump to the Network Node

 

Setting up your environment

On many levels, web3 strives to be platform- and language-agnostic. In fact, enabling implementations of a given protocol or tool in multiple languages is a prominent design consideration. 

That said, a lot of the intended functionality of this tech is to be an evolution of the Web, and therefore, familiar Web development combinations abound. Python and JavaScript are the dominant languages. In particular, the nodejs ecosystem is the go-to place for general app development, and when it comes to writing your code, VSCode has a lot of web3-specific plugins.

 

Why does web3 use contracts, and what makes them smart?

In traditional Web development, we're putting our code onto a server which we're exposing to the Internet. That code could be open source or proprietary, and could be permissioned or non-permissioned. The user's browser and computer will have broad access into the code that produces the front end, whereas the back end, on your server, can remain opaque to them. Some of this remains the same in web3; some of it doesn't. 

Front-end

The front end feels quite familiar, and applications are often built in React, or Vue, or next.js, the same way they are in the traditional Web. However, front-end designers need to take into account not only communicating with any kind of backend they need on the site's server for app functionality, but also the blockchain's backend. This means communicating with the blockchain's API to get information about the state of the chain, and to send data to be written to the chain, if applicable. We'll cover the front-end, UX part of this when we talk about MetaMask, and the blockchain API data when we talk about Infura.

Back end

You may be used to worrying about database types, whether the use case is more suited to a SQL or non-SQL data format, etc. This can still be the case, depending on what your app is doing; increasingly, there are apps that are linking users' off-chain data to their on-chain data, in order to integrate traditional societal data silos into the blockchain world.

But often, you just don't need that stack; a lot of the time, your backend is the blockchain. It's a repository of all the actions taken by your users on the network, and your user is the one that controls your application's access to that data. We'll discuss that particular point more when we talk about MetaMask.

For an example of how you can build a useful app without keeping any information about your users, take a look at this blog post about MetaMask Activity, which both keeps users safe by recording no information about them, while providing customized, contextual experiences.

On-chain code

Public blockchain networks have multiple components, dealing separately with security, syncing data across nodes, and in the case of those chains which have them, an execution environment. This is the great innovation of Ethereum: the Ethereum Virtual Machine (EVM); it allows program code to be written to the blockchain, which can then be run by anyone. And it runs the way it's written for everyone, no matter who uses it. That program, written to chain, is called a smart contract. Why? Well: 

Interactions take place on an Ethereum-compatible network between addresses, each of which has a corresponding account, and private key. The private key, like it sounds, grants the holder control over that account. People interacting with the blockchain often generate accounts through using a Secret Recovery Phrase, a cryptographic tool capable of generating a number of accounts approaching infinity. Because these accounts are generated outside the blockchain and EVM environment, they're referred to as Externally Owned Accounts, or EOAs. (For more on accounts, private keys, and passwords, start with MetaMask's User Guide.)

Smart contracts have addresses too, although they are "internal" to the blockchain. Nevertheless, when an EOA invokes a smart contract through a transaction, there is a sort of "interaction between parties" occurring, and it happens programmatically, as written. This is the origin of the term "smart contract": the sense of a 'contractual relationship' between the invoker and the code. To those of you who are about to ask the question, yes, this is analogous and related to the concept of Ricardian contracts

 

What's in a dapp?

"dapp" is the term coined to refer to a 'decentralized app'. This is often thought of as "an app linked to a smart contract".

However, as the tools, games, interfaces, and other complexities built on blockchain networks have evolved, the definition of ‘dapp’ might be broadening. This category could also include: 

  • Apps that merely read data from the blockchain (without a smart contract that writes to the chain)
  • Apps that leverage already-existing smart contracts (and therefore just manage user permissions and approvals through a wallet interface)

These considerations matter when deciding on tooling; on the one hand, you don't want to choose an option that bloats your app with useless packages. On the other, you want the tool that makes development as fast for you, and as safe for your users, as possible.

Resources: Consensys Academy

If you're looking for resources to get your coding skills to where they need to be, consider Consensys Academy; for guidance in setting up your environment properly and brushing up on the languages and toolsets you need to succeed, check out Academy's Basic Training materials on GitHub.

 

Next:

Truffle Suite: A fully prepared blockchain treat, ready to unwrap

 

 

 

Articles in this section

Was this article helpful?
3 out of 3 found this helpful
Share