< Back

Ethereum Eco-System for Web Developers: Smart Contracts, Tokens & Tools

I had some time off work this week, and I had planned on spending some time researching all things Ethereum. So, I thought I would compile all my notes into this article, for other web developers to use as a guide to the Ethereum Ecosystem.

Cover Image

It was about eight or nine years ago that I first heard about cryptocurrency - Bitcoin at first, then Dogecoin. Every few months since that first experience, I feel like finally I understand how blockchain technology and cryptocurrencies work. Six months later though, without fail, I learn some more and think "No, now I've actually understood it."

I see my understanding of ERC standards (or smart contracts? NFT's?) as even more lacking. This is despite living with a housemate who set up an Ethereum Node in our living room, and was running a very cool interactive and NFT-generating browser-based game similar to reddit's "place" who has explained these concepts to me with a lot of patience and experience-appropriate detail.

While I'm the person many of my friends would come to for a simple explanation of these ideas, my own understanding still involves a lot of "Then draw the rest of the owl"-ish tropes and gotchas.

I had some time off work this week, and I had planned on spending some time researching all things Ethereum. So, I thought I would compile all my notes into this article, for other web developers to use as a guide to the Ethereum Ecosystem.

Cover Image

The Basics: What's in a Smart Contract?

As most neologisms go, Smart Contracts self-describe a contract implied to have 'smart properties' - which we can read through the lines as 'the ability to take actions or execute functions'. To start by reducing ourselves to the most basic explanation:

Smart contracts are code snippets which are executed on the Ethereum Blockchain, providing mechanisms to include various inputs, conditions and outputs.

What is a smart contract?

What can they do?

How are they used?

The Most Popular Ethereum Smart Contract Standards (ERC-20, ERC-721, ERC-777, ERC-1155)

Cover Image

ERC (Ethereum Request for Comment) Token interface standards make smart contracts composeable. This means they will stay compatible despite changes to decentralized exchanges. Each standard defines a specific combination of 'rules' that a token must adhere to. There is a really great article covering ERC-20 makeup interaction basics - ERC-20 is the most common (and possibly simple) standard, and is best explored first.

Each smart contract has a set of mandatory functions - for example, an ERC-20 token has:

and more. We also use the smart contract to store functions for handling transactions and balances.

I want to cover a few of the basics of the tokens you will most commonly encounter. By no means are these comprehensive descriptions - they're simply a catch-up, to help you get comfortable with the terminology (and application), just enough so that you can start exploring interesting smart contracts that other people have written.

The Ethereum Improvements Proposals Website is the central location for platform, api and contract standard proposals. It's a cool place to look around once you've got some basic understanding of the more popular ERC standards.

ERC-20

The Standard Fungible Token Interface

This is the most common, and what is considered the 'base standard'. Most ETH based tokens you'll encounter are ERC-20 Tokens. These can be used for purposes such as managing voting or currency systems - where fungiblity is important. An ERC-20 Token can also be used to create, as mentioned, a cryptocurrency on the Ethereum blockchain.

A great place to start if you want to write ERC-20 contracts is this tutorial which covers creating an ERC-20 token on Ropsten Test Net. I used this tutorial to create $lemToken.

While the other tokens in this aticle have documentation pages linked in this article, if you're going to read just one of the standards I would recommend ERC-20. It's what most other smart contract standards are modelled after in one way or another - The ERC-20 Standard.

ERC-721

The Standard Non-Fungible Token Interface

A 721 is non-fungible (ie. it has a no 1:1 value). I saw it referred to as a "deed" which made the most sense to me personally. While the standard has many feautures it shares with ERC-20, it's got a unique tokenId field - which adds its infamous functionality of being a uniquely identifiably token.

There's some further discussion around how the "art itself" that you might mint as an NFT appears in the NFT itself as, essentially, a link to an off-chain copy of the resource - but this has some pretty practical reasons for it.

Once you have a decent understanding of how ERC-20 works (and have perhaps tried to create your own), I'd highly recommend doing the tutorial on minting a 10,000 piece unique art collection. It glosses over the finer details of smart contracts, but is one of the best catch up articles on the NFT space that I've found.

For a little extra research, it's important looking into ipfs, which is a distributed web concept most often employed for storing the actual "asset" part of digial art on the blockchain. This is one of the core components of working with dApps - it's unavoidable at this point.

ERC-777

Non-Standard Fungible Token

Triple-seven is a fungible token standard, which attempts to add functionality to what would otherwise be similar to an ERC-20. Essentially, it's for building tokens with complex functionality. I would recommend this Jordi Baylina talk on ERC-777 from DappCon as an introduction (once you've read the docs, of course).

The key feature of ERC-777 is receive hooks, which is a type of function that can be called when tokens are sent to it. As a web developer, the general goal of React Hooks is a good comparison here - hooks attempt to make it easier to control the flow of a complex set of actions.

By this point, you've probably realised that most popular smart contract technology is made up of not one, but rather a network of contracts. This is an important concept to grasp, in order to understand the boundaries of immuatability and malleability of the network.

ERC-1155

An Attempt at a Fungibility-Agnostic Token

ERC-1155 is a standard combining efforts of all the contracts we've explored so far, creating a way to write contracts that manage multiple token types. Within a single contract, we can work with fungible, non-fungible, and almost any other sort of token in between. It does all of this while attempting to be even more efficient and cheap to work with than other smart contract standards.

It has a massive difference in gas fees (which we'll get to next) compared to other token standards, and you'll most often see it used in applications like dApp Games. These sorts of applications have the most cause to use a cheap and malleable method of managing a complex internal token system.

ERC-1155 is sometimes referred to as the lazy minting standard - it's the cheapest, most functional and most approachable for newcomers. Whether or not the implications of the "lazy" label fit remains to be seen, however no such label should never discourage you from exploring.

What is Gas and why am I paying for it?

Gas is usually measured in gwei. 1 gwei = 0.000000001 ETH

Gas is one of those mechanisms I thought I understood pretty well - and was kind of right about. Most are familiar, like I was, with transaction fees - a small additional fee (or a fee deducted from an amount sent), which ensures your transaction is processed by the mining network.

The Ethereum Developers' page on Gas and fees puts it most clearly:

Gas refers to the unit that measures the amount of computational effort required to execute specific operations on the Ethereum network.

There are also gas limits, which limit the amount of computational power used in a transaction (or in executing a contract). Miners are awarded gas fees in addition to the block rewards they're mainly after. The method of gas fee calculation changed mid-2021 so I'll leave you to read up on that yourself. But, essentially it was an attempt to make the fee-mechanism more predictable when sending a transaction.

Calculating the total transaction fee currently works as follows:

// Basic calculation

Gas units (limit) \* (Base fee + Tip)

// Example where:
// the gas limit is 21,000 (standard)
// the base fee is 100 gwei

21,000 \* (100 + 10) = 2,310,000 gwei = 0.00231 ETH

If you have a really complex smart contract that would exceed the computational gas limit of 21,000; you might have something more like:

// If we want the transaction the happen faster, we can tip more

120,000 \* (100 + 500) = 72,000,000 gwei = 0.072 ETH

// If we want to try and get a good deal, we can lower our tip and use a lower gas price.
// Our transaction may (read: will) take longer to process, but we don't mind in this case.

120,000 \* (55 + 55) = 13,200,000 gwei = 0.0132 ETH

That's a pretty significant savings. Miners can also set a gas price threshold, declining to process transactions that don't meet it. As a result, gas price is a moving number determined by supply and demand on the network. Most modern transaction methods (such as MetaMask, my preferred wallet method) will provide a recommended gas limit with an estimation on processing time.

The Etherscan.io Gas Tracker Dashboard is the easiest place to watch the average price. Just while writing this sentence, the gas price has jumped from ~80 gwei to ~60 gwei and back to ~70 gwei.

This is a pretty key topic that definitely deserves a full read of the documentation which I linked above.

Learning to Develop your Own Smart Contracts

A creative and talented friend of mine showed me the collectible CryptoKitties (an ERC-721-based token which is represented as "genetically unique" cartoon cats) a few years back - the hype around which infamously congested the ETH network around December 2017. In re-visting their website, specifically detailing the page on how CryptoKitties works, I realised I actually had a fair bit of background knowledge to work with. Clearly, I thought, there's something ineffective happening in my learning. I'm re-teaching myself concepts I already knew, but I only realise that I was already aware of these concepts once I manage to re-explain them to myself. The conclusion I've drawn from this may be ill-advised, but thinking back it's led me well on my understanding of the crypto space in general: Try and relate as much as possible back to other concepts you understand well.

As a preface, the fastest way to learn to write smart contracts (as it is with most programming self-study) is to see how other developers write them. If you read all the various opinions and experiences contained in the different articles linked from this post, you'll soon be bootstrapped-enough to begin experimenting with projects of your own.

Not only does reading the work of others help you learn the language syntax (in this case, Solidity), but it also allows you to learn best-practices and approaches which emphasise clarity and legibility. This is a no-brainer, especially for blockchain related work - where we're putting an emphasis on open-source projects and community-driven growth.

Understanding Smart Contracts as a Web Developer

Smart Contracts are most commonly written in Solidity which is similar to Javascript and Go

A philosophical question that always confuses me is the question of "kinds". What is a "kind"? Are rocks and trees different kinds of things? How about a rock and a pebble? Or, what about a cryptocurrency transaction and a smart contract? For me, at least, it's important to have some sort of mental framework for thinking about these things. Since we're developers, let's try and employ the mental framework a web developer would use to understand Smart Contracts.

It seemed helpful to me in my experimenting to consider a smart contract as a Class, like we might find in an Object-Oriented programming language like Javascript. This goes even further, in that each token type has a list of defined methods.

For example, take the following Javascript component which returns the account balance from an imaginary database we've created.

function getBalance(address) {
return accounts[address].balance;
}

export default getBalance

If we began to use this to build a sort of account management framework, we include this as a function of the framework, for developers to easily re-use:

// AccountPage.js

  import { getBalance } from "../utils/accountUtilities";

  const balance = getBalance("0xfE8cfDcfd36a0eee7e7ef8A95758f32a6Cc27a13");

  console.log(balance); // Balance: 1.298 ETH

This is essentially what is happening in a smart contract - well, almost anything can happen in one, but this is one of the default methods of the ERC-20 token, re-imagined in Javascript.

Here's what the actual function in Solidity might look like (this example is what I used in$lemToken)

// contract ERC-20Interface

function balanceOf(address tokenOwner) public constant returns (uint balance);

// Using balanceOf in \`$lemtoken\`

function balanceOf(address tokenOwner) public constant returns (uint balance) {
return balances[tokenOwner];
}`

You can read the code for all of the methods used in $lemToken here. It's only 100 lines or so, and here you can understand:

Smart Contract Development Tools & Local Environment

Cover Image

Using a development environment speeds up recurring tasks. It's become quite quick and easy to mock up, and hack on smart contracts. My most recent experience in doing so has both been a blast, and vastly more frictionless than previous attempts.

Again, learning Solidity back-to-front is going to be key to your progress. There's a fair bit of confusing syntax around the language that will become second nature the longer you stay with it.

If this is something you're hung up on, then How to Learn Solidity in 30 Days is full of resources to help you.

Anyhow, here are a few development tools that seem to be considered essentials for Ethereum blockchain development. They're very common (you're likely already aware of them if you've read any of the articles I've linked so far), and essential to understand to start having discussions about modern smart contract development.

Blockchain Security and Securing Smart Contracts

Identifying smart contract vulnerabilities is important. Use established Solidity design patterns. Again, services like OpenZeppelin provide a great advantage here. Given we're talking largely about valuable assets here, there are plenty of articles on security best-practices from very knowledgeable people.

There are plenty of Javascript-based testing libraries and recipes available - specifically in Truffle, mentioned in the tooling section above.

Like any sort of digital or cyber-security, you'll want to start with the basics. We're running apps over the internet, often using Javascript as a language to orchestrate it all. As the bare minimum, you'll want to have a basic understanding of:

Hacking also gets an important mention here. I'm sure you've seen some of the suprising attempts at crypto theft which occur every few weeks. Like anything digital, learning about things from a "hacking" perspective can offer great insight and accellerate early learning - as well as teach you things that standard practice education would not. We're of course talking about learning about blockchain hacking as in: "How does this work? Can I break it?", and not "Let's hack into that person's wallet.".

It's important to keep abreast of not only good and exciting news in this space - but also the bad news. Hacks like the Poly Network hack linked in the previous paragraph are some of the only ways we're going to find out where smart contracts break. I believe, as I'm sure you to do, that malicious actions like this are inevitable and only increasing - therefore it's only logical to start learning from them.

Along the line of learning from our mistakes, I'd highly recommend reading some smart contract post mortems, as these can be invaluable in gaining hindsight.

I really enjoyed dipping in and out of this video by

Extra Reading

Finally, here are a few articles I read either before, during or after doing the research I've outlined in this post. They're all worth reading, and over some important concepts that didn't make it into this post, but that I still felt had importance in learning about the basics of Smart Contract development.

When I had edited the article, there were only two links left. The first is a video I recommend watching, and the second is again a link the Ethereum Virtual Machine. If you're going to pick one, go for the latter.