Start here

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.

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.