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.
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?
- Essentially an immutable (unchangeable) deployment of a program.
- Contains a set of public and/or private functions (some mandatory, some user-defined).
- Can involve a set of internal conditions to control the output produced.
What can they do?
- Be interacted with (have their functions called externally)
- Can produce an output when prompted with the correct input.
- Contain, create, or assign assets, tokens, deeds, or currencies etc. of value (or of no value)
- Use the blockchain like an Event Sourcing system to validate actions
- Endless interesting things, when interacting with the blockchain and other smart contracts.
How are they used?
- Most often found used to create tokens on the Ethereum Blockchain, or as NFT minters.
- Often requires a fee to deploy and execute.
- Run on the EVM (Ethereum Virtual Machine) - we won't cover this in this article.
- Different standards for different use cases (ie. currencies, games, deeds, bills, etc.)
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: totalSupply, balanceOfWallet, transferFrom, 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.
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
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.
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 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.
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.
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.
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.
// accountUtilities.js
function getBalance(address) {
const currentBalance = accounts[address].balance;
return currentBalance;
}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 ETHThis 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:
- How immutable functions work to repeatedly generate output data.
- Where you might change methods in order to give tokens a specific feature.
- How Smart contracts could have malintent. (What would happen if I edited the
transfer()function to send 1/3rd of each transaction to my own address?)
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.
-
- Web-based Smart Contract IDE.
- Written on Solidity (with tools to compile, and deploy)
- FOSS
- Many example snippets will link to a Remix repo
-
- A library of security standards for Smart Contracts
- Most commonly used to securely implement an ERC-XXX standard.
- Docs written with a little more passion than the EIP ones.
-
- Smart Contract Suite written in JS
- All you need to deploy, test, run, debug smart contracts (and something most ethdevs use).
- Often used in conjunction with OpenZeppelin's standards library (with Go-like imports).
-
- Fork the blockchain locally for development.
- Written in JS.
- Options of CLI or GUI tooling.
-
- A web3 based game played on the EVM.
- Each level is a smart contract that needs to be 'hacked'.
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:
- Web Dev Security Best Practices (HTTP/HTTPS/Proxies)
- How to use a browser and visit local and external websites safely (not as easy as it seems)
- Common Javascript security concerns (and loopholes)
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.
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.
https://guide.rarepress.org/#/