However, the user experience is just one side of the onboarding coin. Developer experience is the other. After all, a new network is just as good as the RPCs that let you use it. Only some developers have the resources to run a node.

Infura, one of the most popular Web3 node providers, now offers Celo Network RPC nodes to all users. So if you want to start building on this mobile-first network, there’s never been a better time. Before you start building, let’s learn more about Celo.

This article will provide a high-level overview of the Celo Blockchain Network and how you can start building on it using Infura.

What is Celo?

Celo is a high-throughput layer-1 network that focuses on mobile users.

Mapping Phone Numbers to Public Keys

Celo is easier for mobile phone users than other networks. Celo maps phone numbers to public keys, allowing users to send tokens to people who don’t have wallets. A decentralized attestation protocol does the mapping and links an account to a phone number. This service never receives the phone number in clear text to maintain privacy.

As a result, user experience is better than most blockchains, as all interactions are done through phone numbers, rather than 30+ character-long strings that are easy to make mistakes with and impossible to memorize.

Paying Gas Fees with ERC-20 Tokens

Another usability hurdle is that most networks require users to pay gas fees with a native token. This results in users exchanging other tokens for native ones just to be able to send transactions.

This is a problem for two reasons. First, it adds a non-trivial step to every transaction if the user doesn’t have enough native tokens. Second, exchanging tokens is taxable in some countries, so they need to keep track of each time they exchange to a native token just to cover gas fees.

With Celo, you can pay with any approved ERC-20 token currently available, even stablecoins, lowering yet another barrier to entry and making costs more predictable. However, there is one caveat: transactions paid with non-CELO gas currencies will cost roughly 50k additional gas. It’s also important to note that there is a governable list of accepted currencies.

When developing, Celo comes with a dapp SDK called ContractKit. This SDK is a suite of packages that make building on Celo more straightforward. Connect, one of ContractKit’s main packages, acts as a wrapper around web3.js that handles the different currencies to pay the fees.

You can set your preferred currency as default for all transactions, like in this example:

import { CeloContract } from "@celo/contractkit"

const accounts = await kit.web3.eth.getAccounts()
kit.defaultAccount = accounts[0]
await kit.setFeeCurrency(CeloContract.StableToken)

With this in your code, you are setting the default currency if the feeCurrency field is left blank when sending a transaction. The user can still select another currency to use.

ContractKit comes with a list of contract addresses that include all core Celo currencies. In the example CeloContract.StableToken refers to cUSD.

It’s also possible to set your preferred currency per transaction. In this example, we send cUSD and also pay with cUSD.

const contract = await kit.contracts.getStableToken()
await contract.transfer(recipientAddress, amount)
  .send({ feeCurrency: contract.address })

Celo’s virtual machine is also EVM compatible since it originated as a fork of Geth. This compatibility enables you to reuse most of your Solidity skills when deploying your smart contracts on Celo. However, there are some notable differences.

The first difference is that transaction objects have additional fields like feeCurrency, gatewayFee, and gatewayFeeRecipient. They provide full-node incentives and allow users to pay their gas fees with different tokens. This doesn’t affect you when porting smart contracts from Ethereum to Celo, but it could be an issue when porting from Celo to Ethereum.

The second difference could have implications for your Ethereum-based smart contracts. The DIFFICULTY and GASLIMIT opcodes aren’t supported, and the fields are also missing from block headers.

A third difference is that the key derivation path is m/44'/52752'/0'/0 and not m/44'/60'/0'/0 like in Ethereum. Essentially, this derivation path allows wallets to generate different keys from one seed phrase.

The Network is Carbon Negative

CO2 production by blockchain networks has been a huge talking point in the last few years. Coming from Bitcoin, many of the early networks used the Proof-of-Work consensus algorithm to eliminate Sybil attacks.

The Celo protocol uses BFT Proof-of-Stake, which minimizes energy usage of the network by over 90%. Plus, it can create a new block in five seconds, less than half the time Ethereum needs.

Furthermore, all blocks are finalized immediately, so you and your users don’t have to wait for their actions to be written on-chain.

All this optimization still produces CO2, so Celo uses projects like Wren, a carbon offset subscription service that offsets 65.7 tons of CO2 monthly to get carbon negative. With tech-funded rainforest protection, Celo has already saved over 30,000 tons of CO2.

Why Use Celo with Infura?

Infura offers free RPCs for prominent wallets, and many big Web3 projects use them as their RPC provider, including Brave, Uniswap, Compound, Gnosis, and Maker, just to name a few. Additionally, Infura has achieved 99.99% uptime and about 10 times faster response times than other service providers like Alchemy or Quicknode.

ConsenSys, the company behind Infura also created and maintains crucial Web3 projects such as MetaMask and the Truffle Suite. So the shared know-how of creating wallets, dev tools, and RPCs creates synergies you won’t get from any other RPC provider. This also means you get trusted and complementary end-to-end tooling from the ConsenSys suite of products that flawlessly integrate with Infura RPCs.

With the release of Celo RPCs, Infura now supports 10 different networks, so you can build on multiple chains at once. Best of all, it’s free to access these networks and their archived data!

Summary

Celo is an exciting chain that tackles Web3 user and developer experience pain-points with innovative solutions. With its mobile-first approach, users can interact with the network and receive tokens with their phone number rather than a crypto wallet, making onboarding to the network easier for Web3 newcomers.

With the option to pay gas fees with other tokens rather than the native currency, Celo also removed a massive hurdle in the daily use of a blockchain network. Other networks require fees paid with a native and potentially volatile token.

Now that Infura offers RPC nodes for the Celo network, it’s the perfect time to start building on this mobile-first blockchain network. For more information, check out Infura’s docs.

Seeing a local blockchain’s output in the terminal helps you to understand how your project will behave in a live environment. The ability to set the output to variables to manipulate some frontend code is even more useful. Some users may not know that you can do this by running Ganache in your browser.

This article explores how to run Ganache in your browser and highlights three great new features that make developing your Web3 projects easier.

Ganache in the Browser

Running a local blockchain instance to test your smart contracts is an essential step in the Web3 development process. By testing in this manner, you confirm things are working correctly before using a node service, such as Infura, to deploy your contracts to a testnet or mainnet. This minimizes the risk of ramping up daily limits and ensures you only need to deploy once. Ganache is an excellent tool that simulates the Ethereum network and allows developers to:

• Fork any Ethereum network without waiting to sync
• Establish block mining rules (instant, on-demand, intervals)
• Impersonate any real account without needing their private keys
• Make function calls with Ethereum JSON-RPC support

However, many who use this tool may be unaware that, since v7.0.0.0, Ganache can also run in your browser. Running in the browser allows you to set the local blockchain’s output to variables, which you can then use to test your frontend code. This visual process helps you to understand how your users will interact with your project and also enables you to test your dapp entirely offline (when using a local instance).

By first running Ganache in the browser and fine-tuning how your dapp reacts, you can easily switch the provider to your node service API once things are working as intended. Additionally, since Ganache’s latest update (v7.3.2 at the time of writing), you can now fork the Ethereum mainnet when running Ganache in the browser. This allows you to interact with real accounts and contracts through your frontend code.

The Project

In this section, we will create a basic smart contract using Truffle and its VS Code extension. Then, we’ll first deploy our contract to Ganache via the command line. Afterward, we will create a simple frontend to use Ganache in the browser and interact with our deployed contract.

Requirements

For this project, we will use the following:

• NodeJS / NPM
• Truffle & Ganache
• The VS Code Editor
• Truffle for VS Code Extension

Step 1 – Installation

First, we can run the command node --version in our terminal to ensure NodeJS and NPM are properly installed on our machine.

Next, we will install Truffle and Ganache by running the following command:

npm install -g truffle ganache

Checking the version number for Truffle and Ganache with truffle --version and ganache --version respectively will tell us if both tools were installed successfully.

The next step is to install VS Code, then navigate to the Extensions tab in the editor and search for Truffle for VS Code.

With everything now installed, we are ready to start working on the project.

Step 2 – Set Up the Project

With the Truffle for VS Code extension, we can easily create a new Truffle project through the VS Code command palette. Press ctrl + shift + P in the editor to open up the command palette and type truffle to see a list of commands we can use. Select Truffle: New Solidity Project and then create basic project to create a new project in the desired folder.

This creates an initialized project with a simple folder structure and example code we can use if we wish.

The ability to use console.log in our smart contract code is another great new feature recently available for Ganache. Before we create the smart contract for our project, let’s set that up by installing the required package. Navigate to the project folder in the terminal and type the following command:

npm install @ganache/console.log

Step 3 – Write the Smart Contract

The smart contract for our project will be a basic one we can donate some ETH to and request to see the balance.

In the contracts folder, create a new file and call it SimpleContract.sol. Next, fill it with the following smart contract code:

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import '@ganache/console.log/console.sol';

contract SimpleContract {

  constructor() {
    console.log('\n\n#################################################\n'
    '####         Now Deploying Contract          ####\n'
    '#################################################'
    );
  }

  function donate() public payable {
    console.log('Successfully Donated ', msg.value);
  }

  function getBalance() public view returns (uint256) {
    console.log("This contract's balance is:", address(this).balance);
    return address(this).balance;
  }

  // Needed in order to receive payments
  receive() external payable {}

}

The code in our smart contract is relatively simple. It displays a message in the console when we deploy our smart contract, provides the functionality to donate ETH and query the balance, and prints messages in the console when calling the functions.

Step 4 – Deploy to Ganache

After installing the Truffle for VS Code Extension, we can easily deploy by right-clicking the smart contract file and choosing Deploy Contracts. However, if we want to see our console messages, we will have to use our own terminal rather than the one built into VS Code. This could potentially change in the future, but for now, we will have to create a simple migration script to carry out the deployment.

In the migrations folder, create a new script called 1_SimpleContract.js and input the following code:

const SimpleContract = artifacts.require("SimpleContract");

module.exports = function (deployer) {
  deployer.deploy(SimpleContract);
};

Next, open up a new terminal window and start Ganache:

ganache

This terminal window is where we will see our console messages when they appear. We now have two terminal windows open: one running Ganache and the other open in the folder of our Truffle project.

In the terminal window that’s open in our Truffle project’s location, type the following command to initiate the deployment:

truffle migrate --network development

If the deployment is successful, we can see our console message printed in the terminal:

Great! Our contract is live on our local Ganache instance! We’ll leave Ganache running for now so we can interact with our contract using the browser. Before we get to that, copy the contract address from the output in the terminal where we typed the migrate command. We will use this address to point our frontend to our smart contract.

Step 5 – Build the Frontend

5.a – Setup

For the frontend of this project, we will use React. Navigate to a new empty folder and type:

npx create-react-app ganache-browser-test

Next, we will install Web3.JS to easily interact with our smart contract. Navigate into our new project folder and install Web3.JS with this command:

cd ganache-browser-test
npm install web3

Newer versions of create-react-app don’t play nicely with Web3.JS, so we need to install a specific version of React Scripts. We can do so with this command:

npm install --save-exact react-scripts@4.0.3

Finally, to use Ganache in our browser, we will install it directly as a dependency:

npm install ganache

Alternatively, you can add the CDN link in the html to access Ganache from the browser:

<script src="https://cdn.jsdelivr.net/npm/ganache@7.3.2/dist/web/ganache.min.js"></script>

Before we start working on the frontend code, we need to create a file containing our contract’s ABI so that we can interact with our smart contract. We can copy that file directly from our Truffle project. Navigate to the build/contracts folder in our Truffle project and copy the SimpleContract.json file.

Next, open up our frontend project in the editor and create a new folder called abi. In that folder, paste the SimpleContract.json file. The file structure for our frontend now looks like this:

5.b – The Frontend Code

With all the setup out of the way, we can start working on our frontend. First, open the App.js file in the src folder and replace the boilerplate code with this:

import { useState } from 'react';
import './App.css';
import SimpleContract from './abi/SimpleContract.json';

const ganache = require('ganache');
const Web3 = require('web3');

const options = {}  
const provider = ganache.provider(options);

const web3 = new Web3('http://127.0.0.1:8545');  

const CONTRACT_ADDRESS = 'YOUR_CONTRACT_ADDRESS'  
const USER_ADDRESS = web3.utils.toChecksumAddress('YOUR_ACCOUNT_ADDRESS');

const contractInstance = new web3.eth.Contract(SimpleContract.abi, CONTRACT_ADDRESS);

const App = () => {
  const [contractBalance, setContractBalance] = useState(0);

  const donate = async () => {
    const donationAmount = document.querySelector('#donationAmount').value;

    const response = await contractInstance.methods.donate().send({
      from: USER_ADDRESS,
      value: web3.utils.toWei(donationAmount)
    });

    console.log('donate response:', response);

  };

  const getBalance = async () => {
    const response = await contractInstance.methods.getBalance().call();

    console.log('getBalance response:', response);

    setContractBalance(web3.utils.fromWei(response));

  }

  return (
    <div className="App">
      <header className="App-header">
        <h1>Ganache In The Browser</h1>

        <div>
          <input
            type='number'
            id='donationAmount'
            defaultValue={0.01}
          />
          <label htmlFor='donationAmount'>ETH</label>
          <br></br>
          <button
            id='donate'
            type='button'
            onClick={donate}
          >
            Donate
          </button>
        </div>

        <div>
          <button
            id='getBalance'
            type='button'
            onClick={getBalance}
          >
            Get Contract Balance
          </button>
        </div>

        <div>
          <p>
            {contractBalance} ETH
          </p>
        </div>


      </header>
    </div>
  );
}

export default App;

Be sure to change CONTRACT_ADDRESS to the address we received when deploying our smart contract back in Step 4. As well, the USER_ADDRESS is the account that will call the functions. We can get this from the list of accounts that displays when we first started our Ganache instance in the terminal:

Any of these account addresses will work.

Before we move on, let’s take a second to walk through the code we wrote:

• We import our dependencies and SimpleContract JSON file.
• Set the ganacheand Web3 variables.
• Create an empty options variable that we initialize our provider instance with.
  • Note: This options variable is where we would set any of the options we would like our local blockchain instance to include, such as forking Mainnet or Goerli, when running Ganache strictly in the browser (without it running in our other terminal window).
• Initialize our web3 object using our localhost URL and port 8545, where our Ganache instance is already running.
  • Note: You can run Ganache strictly in the browser at this point by using the provider variable instead of localhost. We are using localhost in this case since we want to interact with our already deployed smart contract and see our console.log messages in the terminal output.
• Set our CONTRACT_ADDRESS and USER_ADDRESS variables.
• Create a contract instance we can use to call our functions in the App code.
• Create the contractBalance React state variable and its set method.
• Define our donate and getBalance functions.
• Finally, we return the html for our frontend.

5.c – Run the Project

Now we can run our app with npm start to display our frontend, which looks like this:

When we test our project, we can see the results and our console.log messages displayed on the terminal window which is running Ganache, and the ETH balance on our frontend successfully updates with the new balance.

Step 6 – Fork Goerli or Mainnet with Ganache in the Browser

Now that we know our project functions properly on a locally running instance of Ganache, the next step is to run it on a forked version of a testnet and then mainnet. We won’t run through the actual process of doing that in this article, but setting it up to do so is simple. All we need to do is change a few lines of our frontend code.

First, the options variable needs to specify which network we wish to fork:

const options = { fork: { network: 'goerli' } };

Or:

const options = { fork: { network: 'mainnet' } };

Then we need to update our web3 variable declaration:

const web3 = new Web3(options);

Finally, we need to make sure that we update CONTRACT_ADDRESS with our address on whichever network we are forking. We also need to update USER_ADDRESS to an account address on the same network that has sufficient funds to donate to our contract.

When forking mainnet, that section of code could look something like this:

const options = { fork: { network: 'mainnet' } };
const provider = ganache.provider(options);

const web3 = new Web3(provider);

const CONTRACT_ADDRESS = '0x692586eaC70114C8F4714D89E7f72FAAbaeE0Cd7'  
const USER_ADDRESS = web3.utils.toChecksumAddress('0xCe7A99Bba7018fa455E6eD5CF88a7F26010F1E8F');

And with that, we could test our project with a forked version of mainnet using Ganache in our browser.

Conclusion

Testing projects by creating an interface helps to visualize how your dapp is running and gives you a better idea of how it will perform for users once on mainnet. Running in your browser while testing your frontend code is one of the features that make Ganache such a powerful tool in your development toolkit. For more information about working with Ganache or to contribute to the project, check out their Github or documentation.

At ETH Berlin recently, Infura announced plans for a new decentralized infrastructure network. This decentralized network has the potential to vastly improve how web3 developers and end-users access and interact with the data on blockchains.

Why is this a big deal? And what could it mean for Web3? Let’s take a look.

Decentralized Protocols

One of the most important innovations Web3 and blockchain technology make possible are decentralized protocols—networks and communities where anyone and everyone can participate. Protocols are a powerful new form of human coordination using technology and protocols like Bitcoin and Ethereum have led the way for so many others to emerge: NEAR, Polygon, and Arbitrum, just to name a few.

But what about the infrastructure and protocols that exist on top of these networks? Many companies creating the building blocks are operating in Web2 terms with centralized ownership and access to their services. As Web3 technology grows and matures, the need for decentralized protocols and infrastructure grows with it. That’s why Infura is launching a new infrastructure protocol for node services.

Node services are how some dapps access blockchain data in Web3. While some larger organizations choose to host their own nodes, self-hosting can be complicated and expensive. As a result, many developers rely on companies like Infura to manage the infrastructure and blockchain access for them.

A decentralized infrastructure protocol—one that offers this access but isn’t controlled by a single centralized entity—is a critical piece to completing the Web3 tech stack.

What is a Decentralized Infrastructure Protocol?

Let’s break down this question of centralized versus decentralized a bit further.

In a centralized node service, a single entity controls the protocol and infrastructure. Similar to how Web2 companies like Twitter or Facebook: one entity hosts the server that ensures the service is operational, gatekeeping the user data and pocketing the revenue. As a result, end-users like you and me only have one entry point into the service, and zero control over what happens behind the scenes.

In the case of a node provider, a single entity is responsible for keeping the service operational, the infrastructure running, and the node responses flowing. While there are multiple nodes running, they are all controlled by this single entity. If the centralized entity or its infrastructure goes down, so does the entire service, along with any applications that rely on that service. Remember when Facebook went offline on October 4th in 2021? That’s a prime example. Millions of people and services were disconnected as a result of their server outage. This is the principal shortcoming of centralized infrastructure: it can never guarantee 100% uptime the way a decentralized network can.

In a decentralized node service, there are multiple entities all joining together to support the protocol, host the nodes, validate the data, and distribute the risk of infrastructure. The decentralization of responsibilities is closer to the ultimate goals of Web3 and a truly permissionless infrastructure.

And, because there are multiple providers, users will have the choice of which provider to use. If a provider goes down, or one makes technical decisions the user doesn’t like, then the user can easily switch to a new provider.

With this many actors, there’s a requirement for ways to agree on upgrades, revenue sharing, architectural changes, and so on. We can already see this on Ethereum with the EIP system. From past experience, this often means implementing decentralized governance like a DAO.

Why is Decentralized Infrastructure Important?

So why is this decentralized node protocol a big deal?

As I mentioned earlier, decentralized networks have progressed significantly as well as some of the protocols, DeFi above all. However, decentralized data access is one of the most important components of the Web3 tech stack.

Until now, node access has been mostly centralized, since the vast majority of users access the blockchain through the node providing services. Without a decentralized node access protocol and infrastructure, we don’t really have decentralized Web3, which is the ultimate goal of this industry and ecosystem. A decentralized infrastructure protocol gives us:

• High-throughput and reliability - a proven architectural solution spread out over multiple entities reduces the risk of downtime and failures. It can ensure that users can access the data they need.

• Increased transparency - decentralized solutions, like open source software, often result in a higher level of transparency.

• Improved cooperation - Instead of competing, protocol providers collaborate to create a more effective and reliable infrastructure protocol.

How this will evolve is yet to be seen, but Infura plans to release the new protocol in stages.

What Can You Do?

Since Infura’s announcement at ETH Berlin was high-level, we don’t know yet how this decentralized infrastructure protocol will be implemented.

That said, there was an open call for infrastructure providers to get involved. Qualified providers can sign up for the early access program to help construct the test network. In the announcement, they listed the following qualifications:

• Experience running blockchain infrastructure

• Willingness to actively participate and provide feedback

• Interest in decentralizing blockchain API access

If you want to learn more about this decentralized network, keep an eye on Infura’s official channels for more information.

Since its inception in 2014, Ethereum has established itself as the de facto leader of blockchain platforms capable of supporting turing-complete smart contracts.

Ethereum has been instrumental in bringing about a revolution that we now know as web3. The largest decentralized exchange, NFT marketplace, and yield farming protocol all reside on Ethereum. The chain is responsible for handling billions of dollars worth of value, and it has opened up avenues for creators and investors that were previously unfathomable.

Although Ethereum dapps have enjoyed an immense amount of popularity amongst their users, they are nowhere close to achieving mass adoption. The sum of people who have used dapps still number only in the few millions. One of the biggest reasons for this is the scaling handicaps endemic to the chain. It becomes unusable very quickly for everyone barring a few high net-worth users.

Fortunately, there have been serious efforts made by the community to help Ethereum scale. By far, the most popular scaling solution available in the market today is the Polygon POS (Proof of Stake) sidechain. In this article, we are going to explore what Polygon is and how it overcomes Ethereum’s drawbacks. Finally, we will make a side-by-side comparison of both chains’ performances by creating an NFT-minting smart contract.

The Problem with Ethereum

Ethereum, despite its market leader position, suffers from a host of problems:

1. Low Transaction Throughput: Ethereum can handle only 15 transactions per second. Compared to solutions like Visa or Mastercard, which handle over 25,000 transactions per second, this figure is scant.
2. High Gas Fees: When a chain can handle few transactions, it must increase processing costs when the transaction volumes are high. Ethereum is notorious for its high gas fees. For instance, not long ago, it reached almost 7000 Gwei during a popular NFT mint (called Otherside). During this period, it would’ve cost you in excess of $500 to perform even the most basic transaction.
3. Slow Transaction Finality: Ethereum adds a block to its chain approximately once every 15 seconds. Since there are multiple miners competing to mine blocks at the same time, a block cannot be considered final until at least 4-5 blocks have been added on top of it. In essence, it takes more than a minute for a transaction to be considered final. With applications like games and financial tools, such a slow transaction finality is simply not acceptable.

The Solution

In order to achieve mass adoption and acceptance, it is imperative that a solution be developed on top of Ethereum that addresses its most glaring problems. In essence, we need a solution that has the following features:

1. Low-cost: Even the most computationally intensive transactions shouldn’t cost more than a few cents.
2. Fast: Transactions are confirmed almost instantly.
3. EVM Compatible: Developers don’t need to learn new tooling or languages in order to build on the solution.
4. Interoperable with Ethereum: Easy to deposit and withdraw funds to and from Ethereum and the solution.
5. Engaged community: A community that is committed to improving the solution over time as well as building user-friendly dapps on top of it.
6. Sustainable: Any solution looking to reach mass adoption must also be environmentally conscious.

Ethereum core developers are working on Layer 1 scaling fixes, such as sharding, but these solutions are nowhere near completion. We need solutions available today that are easy for anyone to get started on.

Introducing Polygon

The creators of Polygon designed a chain with all the aforementioned features in mind. Since its inception in 2017, the Polygon chain has gone on to become one of the most popular Ethereum scaling solutions.

Technically speaking, Polygon is an Ethereum sidechain. A sidechain is an independent blockchain that is connected to Ethereum via a bridge. Unlike L2s, sidechains do not inherit the security features of the main Ethereum chain. Instead, they implement their own consensus protocols and block parameters. As a result, sidechains aren’t required to post state changes and transaction data to Ethereum (whereas L2s are).

The greater independence of sidechains from Ethereum makes Polygon slightly more centralized but also enables it to achieve extraordinarily high levels of throughput.

The following are the improvements that Polygon has been able to achieve over Ethereum:

1. High transaction speeds: Polygon is capable of handling up to 65,000 tx/second, comparable to the scale of its centralized rivals.
2. Low transaction costs: Even the heaviest transactions on Polygon cost only a few cents. In most cases, a 10,000x reduction in cost can be observed vis-à-vis Ethereum.
3. Instant transaction finality: Polygon’s consensus protocol guarantees that transactions are confirmed almost instantly (less than 2 seconds).
4. EVM compatible: Polygon is built on the same software as Ethereum. Therefore, Ethereum developers can build on Polygon using the exact same tools.
5. Strong community: The Polygon team has spent millions of dollars to build a robust community of builders, investors, and users. It is already home to some of the most popular dapps on Ethereum with better UX and much cheaper costs.
6. Low energy consumption: Polygon uses the Proof-of-Stake protocol, which consumes 99.9% less energy than its PoW counterpart. In fact, Polygon has committed to being carbon negative by the end of 2022, making it one of the largest environment-friendly blockchains in the market today.

A Note on Polygon PoS Security

Unlike other sidechains, Polygon PoS does have a method in which it is able to inherit the security of Ethereum. The Polygon PoS chain utilizes the Plasma Bridge in order to maintain and guarantee a high level of security. Plasma has a unique exit mechanism, basically a set of smart contracts to help move assets and checkpoints for verification, which enables Polygon PoS to leverage Ethereum’s security.

The only drawback here is withdrawals from Polygon to Ethereum through the Plasma Bridge must go through a 7-day withdrawal period. Quicker withdrawals (within 30 minutes to 3 hours) are possible with the PoS Bridge, however, this method is not as secure as using the Plasma Bridge.

Both these bridges are still secure and safe to use, and in most cases should suit a user’s needs just fine. However, if your project requires state-of-the-art security, it is prudent to consider using Polygon L2 solutions such as Zero, Nightfall, and Hermez.

Comparison in Action

Now that we've seen the advantages that Polygon PoS has over Ethereum for certain projects, let's analyze deployment to both chains.

In the following sections of this article, we will create a simple NFT contract and deploy it to Polygon Mumbai and Ethereum Goerli testnets. We will observe how the development process for both chains is nearly identical.

Next, we will analyze NFT contracts that have been deployed previously (by other teams) on Ethereum and Polygon mainnets, and then compare cost and confirmation times.

Overview of the NFT Project

The project that we're going to create is extremely simple. We want to write and deploy an ERC-721 contract that mints a single NFT to the blockchain of our choice.

The first step in such projects is to create the NFT art, its associated metadata, and upload it to IPFS. For this tutorial, we have already done this for you.

You can check out the image uploaded to IPFS here and the associated NFT metadata here.

In case you're interested in learning more about NFT metadata, IPFS, and Pinata, check out this article here.

Creating the NFT Contract

Step 1: Install the MetaMask Extension

In case you haven't already, install the MetaMask extension for your browser. Once installed, MetaMask will guide you through creating your first wallet.

Step 2: Add Goerli and Mumbai Chains to MetaMask

By default, MetaMask comes with the Ethereum mainnet and the Goerli testnet configured. To add the Polygon mainnet and the Mumbai testnet chains, follow the instructions in this document.

Step 3: Get GoerliETH and Mumbai MATIC from a Faucet

Head over to Alchemy's Goerli faucet page and request some free GoerliETH. You may be required to create a free Alchemy account for this.

If all goes well, you should have 0.05 GoerliETH in your wallet when you switch to the Goerli test network.

In the same vein, acquire some free Mumbai MATIC from Polygon's official faucet. If successful, switching to the Mumbai chain should tell you that you have a balance of 0.2 MATIC.

Step 4: Install NPM and Node

We will build our project using JavaScript and node. In case you don't have node and npm installed on your local machine, you can do so here.

You can ensure that everything is working properly by checking the version number of node on your terminal.

$ node -v

Step 5: Create a Node Project and Install Dependencies

Let's set up an empty project repository by running the following commands:

$ mkdir nft-contract && cd nft-contract
$ npm init -y

We will be using Hardhat, an industry-standard Ethereum development environment, to build and deploy our smart contract. Install Hardhat by running:

$ npm install --save-dev hardhat

We can now create a sample Hardhat project by running the following command and choosing Create a basic sample project.

$ npx hardhat

Agree to all the defaults (project root, adding a .gitignore, and installing all sample project dependencies).

To check if everything works properly, run:

$ npx hardhat test

We now have our Hardhat development environment successfully configured. Let us next install the OpenZeppelin contracts package. This will give us access to ERC-721 implementations (the standard for NFTs), on top of which we will build our contract.

$ npm install @openzeppelin/contracts

Step 6: Writing the Smart Contract

Open the repository in your favorite code editor (e.g. VS Code). In the contracts folder, create a new file called NFTContract.sol.

We are going to create a very simple ERC-721 contract that mints a single NFT when deployed (i.e. within the constructor). Add the following code to the file:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;

import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";

contract NFTContract is ERC721URIStorage {

    constructor() ERC721("Panda NFT", "PNFT") {

        // Mint NFT
        _mint(msg.sender, 0);

        // Set metadata
        _setTokenURI(0, "ipfs://QmUyZoK21qb8YknXGfDB34RTY8vMqPb6Bsj9U9iLEnyrZR");

    }
}

Step 7: Deploy the Contract Locally

Let's now write a script to deploy and test the contract locally. In the scripts folder, create a new file called run.js and add the following code:

const hre = require("hardhat");

async function main() {

  const contractFactory = await hre.ethers.getContractFactory("NFTContract");
  const contract = await contractFactory.deploy();

  await contract.deployed();

  console.log("Contract deployed to:", contract.address);
}

main()
  .then(() => process.exit(0))
  .catch((error) => {
    console.error(error);
    process.exit(1);
});

Now run the following command on your terminal:

$ npx hardhat run scripts/run.js

Step 8: Deploy the Contract to Goerli

In order to deploy the contract to Goerli, we have to add the network to the hardhat.config.js file. Replace the module.exports object at the end of the file with the following:

module.exports = {
  solidity: "0.8.4",
  networks: {
    goerli: {
      url: "https://ethereum-goerli-rpc.allthatnode.com/",
      accounts: ["<-- WALLET PRIVATE KEY -->"]
    }
  }
};

Replace the placeholder with your MetaMask wallet's private key. (This can be found in Account Details.) Take care to never share this key or file publicly.

To deploy to the Goerli testnet, run the following command:

npx hardhat run scripts/run.js --network goerli

If all goes well, your terminal will display the address of the deployed contract on the Goerli network. Head over to https://goerli.etherscan.io and search for your contract address to view your contract.

You can find the contract that we deployed here.

Step 9: Deploy the Contract to Mumbai

Let's now deploy our contract to the Polygon Mumbai network. The best part of this step is that we have to change absolutely nothing in our contract or the run script. The only thing we need to add is the mumbai network to hardhat.config.js.

module.exports = {
  solidity: "0.8.4",
  networks: {
    goerli: {
      url: "https://ethereum-goerli-rpc.allthatnode.com/",
      accounts: ["<-- WALLET PRIVATE KEY -->"]
    },
    mumbai: {
      url: "https://rpc-mumbai.maticvigil.com",
      accounts: ["<-- WALLET PRIVATE KEY -->"]
    }
  }
};

Deploy to Mumbai by running:

npx hardhat run scripts/run.js --network mumbai

You can search for your contract address at https://mumbai.polygonscan.com. You can find our contract here.

You can also search for your Goerli and Mumbai NFTs on OpenSea Testnets. For example, here is the NFT we minted on the Mumbai network.

Comparing Cost and Time

By now, it should be abundantly clear that developing for Ethereum and the Polygon sidechain is nearly identical.

But what are the cost and time implications?

We won't be able to answer these questions with the contracts we deployed since we were operating on testnets using fake money.

But not to worry. We have deployed these contracts to the Ethereum and Polygon mainnets on your behalf. Let’s take a look at the performance.

Ethereum

You can check out the deployed NFT contract on Ethereum here and the contract creation transaction here.

Despite the recent drops in Ethereum prices (in terms of USD) and average gas prices (in terms of gwei), you can see that contract deployment cost around 0.02 ETH or $40.

The time to confirm this Ethereum transaction was approximately 40 seconds.

Polygon

You can check out the deployed NFT contract on Polygon here and the contract creation transaction here.

Notice that we paid 0.06 MATIC when MATIC was trading at $0.94. Therefore, we paid $0.06 to deploy the contract.

The time to confirm this transaction was 6 seconds.

In essence, this contract was confirmed almost 7 times faster and with a cost reduction of 1000x!

Conclusion

Ethereum is easily the most important smart contract blockchain in existence. However, it faces huge obstacles when it comes to scale and transaction costs.

Hopefully, this article has made a strong case for why Polygon is an excellent panacea to Ethereum's scalability problems. By operating as a PoS sidechain, it significantly increases processing speeds and reduces costs.

For Ethereum developers, building on Polygon requires almost zero additional upskilling. Ethereum tools are compatible with both environments. To start building on Polygon, check out the documentation here.

I never thought of myself as a writer. However, it turns out I actually have a knack for it! Learning new technology and then writing about it helps me solidify the concepts. As an added bonus, I’m able to help teach others on the same path as me. Creating technical content is fun! Eating cheap, frozen dinners every night is not. So how can I start accepting payment for all the hard work I’m putting in?

Some of my readers suggested I build a “Buy Me A Coffee” type feature on my website. This simple method to start accepting crypto donations could be my answer to move from frozen dinners to fresh produce!

This article will explain how I installed a method to receive crypto donations using no-code solutions by Coinbase Commerce. Then, we’ll build a simple project so you can see just how easy it is and how little code is involved.

The Problem: Broke But Still Building

I tell my readers and Twitter followers all the time that creating content around web3 tech is one of the best ways to learn it. Writing about something quickly points out any gaps in your knowledge. It’s a fast track to understanding these complicated networks and how they operate at a technical level. However, what I don’t tell them is that when you’re first starting out, writing technical articles doesn’t exactly pay the bills if you don’t have any clients yet.

Clients or not, helping others learn through content creation is rewarding. One of my favorite aspects of being a technical writer is when a reader reaches out saying that I helped them solve a problem or learn something new. Some of these readers even expressed interest in returning the favor. They suggested I build a “Buy Me A Coffee” type feature on my website. This seemed like an excellent way to get paid for the hard work I put into my content.

Building a feature like this from scratch sounds like a nightmare, though. I don’t have time to improve my frontend skills to do this properly; I just want to focus on web3 stuff! So I started looking for an easier solution—and found one with Coinbase Commerce.

The Solution: No-Code With Coinbase Commerce

Coinbase Commerce has easy-to-install payment gateways that make it simple to accept crypto. I can use this to create a “Buy Me A Coffee” feature on my site, no problem!

As a plus, I’m already familiar with Coinbase. I’ve been trading cryptocurrencies since 2017, and Coinbase was the first crypto exchange I ever signed up for.

Installing the donation gateway was easy. All I had to do was create the gateway in my Coinbase Commerce dashboard and then copy the code it generated onto my site. Then with only minor adjustments to the code, I got it to look how I wanted. Now I’m ready to start accepting crypto donations so I can hopefully treat myself to something a little better than frozen pizzas.

How to Install a Crypto Donations Button

For the rest of the article, we’ll run through creating a crypto donations button to show you just how easy it is. We’ll go through it step by step, so even if you’re not a developer, you’ll be able to start accepting crypto in minutes

What You’ll Learn

• How to easily install a link on your website to start accepting crypto donations

What You’ll Need

• A Coinbase Commerce account
• The Google Authenticator App on your phone (for 2-step account verification)
• A website to install your link on

Additional Resources

• Coinbase Commerce Docs

Step 1 - Set Up a Coinbase Commerce Account

The first step in getting a button to accept crypto donations is to set up a Coinbase Commerce account. Head to https://commerce.coinbase.com/ and select the Get Started button. Follow the steps to get everything set up correctly.

• Choose the Self managed option to get started with just an email address.
• Verify your account through email.
• Set up 2-step verification using the Google Authenticator app on your phone.
• Set up a Coinbase Crypto Wallet.
  • IMPORTANT!– Write down your seed phrase somewhere safe! Anyone with this seed phrase can empty your wallet!
  • Verify your seed phrase in the next step.
  • Lastly, you can save an encrypted version of your wallet to Google Drive if you want, but it’s not necessary.

After completing all the above steps, go to your new dashboard!

Step 2 - Whitelist Your Website

Now that you have a place to send any funds you may receive, the next step is to add your website to the whitelist. This just means adding your website to a list of approved websites that are allowed to host your new payment button. You wouldn’t want just anyone installing it wherever they want!

Click on your email address in the top right corner of the screen and select Settings.

Next, select the Security tab and click on the Whitelist a domain button. Enter the full URL of your website, including the https:// part. If this is successful, you will now see it in the list of approved sites.

Note: If you are a developer testing on a locally hosted instance of your website, you do not need to whitelist localhost.

Step 3 - Create a Checkout

The next step is to create the payment gateway your donate button will send the user to. Click on the Checkouts tab on the left-hand side of the screen, then select Create a checkout.

Fill in the details for your checkout, giving it a name, description, and image if you’d like. Then, select Let your visitors choose under the "What kind of pricing do you want to offer?” heading to accept donations. You can also ask for additional information from the person donating, but this is optional.

Once you have filled in the details, click on the Create checkout button at the bottom to finish. A popup will display some options for you to share your new checkout.

You can share your checkout link directly, copy the code to create the Donation Button on your website, or select View checkout to see it in action.

Step 4 - Add the Code to Your Website

The final step is to place the checkout code on your website. So navigate to your index.html or whichever page you want to put the button on and paste the code where it makes sense for you. For example, I added mine to the bottom of my hero section and changed the Button text to say “Buy Me A Coffee”.

Now clicking on the Donate button will send any charitable users to your shiny, new checkout page where they can donate as much as they like in multiple cryptocurrencies. Here’s what mine looks like:

Conclusion

Creating web3 technical content is challenging, yet rewarding. Any newcomer will see that it is a fast way to learn concepts quickly. However, they will also learn that being a content creator takes a while to start being a profitable career choice. This is where a “Buy Me A Coffee” button helps a lot.

This no-code solution makes things simple for anyone to make a crypto payment gateway in minutes. Now that I’ve got this fancy, new feature on my website, I can start accepting donations for all the hard work I put into creating content! No more frozen dinners for this guy! I’m moving up in the world!

If this article has helped you, maybe Buy Me A Coffee? ;)

I’ve only been in Web3 for about a year now, but I can honestly say that NFTs are the most exciting aspect about it for me. I’m not talking about Apes or Punks, however. PFP (profile picture) projects and art, although cool and a simple proof of concept for the technology, won’t create a better world.

Instead, I’m excited about the actual utility of NFTs. Allowing gamers to own their assets, delivering fair royalty commissions to musicians and artists, and making concert tickets impossible to scalp while providing a sweet digital memento are some of the use cases I find interesting.

However, building and interacting with NFTs aren’t always the easiest thing to do. As developers, we need clear resources to build projects effectively in order to give our users a better experience.

I recently heard about Infura’s private beta for their NFT API, so I thought I would check it out and see how it could improve my development workflow. In this article, I will explore the capabilities of Infura’s NFT API and test it out using a Lootbox NFT sample project from Infura’s Github.

What is the Infura NFT API?

According to this blog post on Infura’s website, the NFT API will help me “accelerate my time to value” and allow me to interact with anything related to NFTs through a convenient SDK. In addition, I can build and verify my NFTs, create metadata templates and easily mint NFTs. So my first impression is that I can start creating and interacting with NFTs using API endpoints rather than building smart contracts and deploying them.

Sounds pretty useful! And I’m all for testing any tool that will help improve my development processes. Infura’s NFT API suite seems helpful for any dev transitioning from Web2, since you can run API endpoints without Solidity.

Now let’s dive deeper and see what this NFT API is capable of.

Infura NFT API Capabilities

A quick glance through the NFT API documentation on Infura’s website proves my first impression correct. I will be able to deploy and call methods on my NFT contracts using Infura’s API endpoints, without having to actually write the smart contract code. This is a huge time saver!

Deploying a contract is straightforward. I create the NFT metadata in JSON format, upload the metadata to IPFS in another Infura project, then create a simple deployment script and run it with node. I also have to make a .env file to hold some environment variables. My deployment script ends up looking something like this:

import { config as loadEnv } from 'dotenv';
import { SDK, Auth, TEMPLATES } from '@infura/sdk';

loadEnv();

const auth = new Auth({
      projectId: process.env.INFURA_PROJECT_ID,
      secretId: process.env.INFURA_PROJECT_SECRET,
      privateKey: process.env.WALLET_PRIVATE_KEY,
      chainId: 4,
    });

const sdk = new SDK(auth);

const myNFTContract = await sdk.deploy({
   template: TEMPLATES.ERC721Mintable,
   params: {
     name: 'My NFT Contract',
     symbol: 'MYNFT',
     contractURI: 'https://MY_NFT_METADATA_URL',
   },
 });
console.log(`Contract address is: ${myNFTContract.contractAddress}`);

Then, I run it with Node. Infura creates a smart contract for me and uploads it to Ethereum behind the scenes. After that, I just need to make sure I have some tokens for whichever chainId I have specified in my code. In this case, the Rinkeby testnet (chainId: 4). From here, I could mint NFTs from this contract or gather the contract metadata.

This is a much easier method to create an NFT contract than writing Solidity code and deploying it myself!

The NFT API also provides methods for gathering NFT info from wallets, transferring NFTs from one wallet to another, and a host of other NFT methods. These include adding an address to the minter list, setting royalty info, and changing the contract URI.

Overall, it seems that Infura’s NFT API indeed helps improve my development workflow. Having all the necessary functionality for building and interacting with NFTs packaged together in an easy-to-use SDK is quite convenient!

But enough about what it can do, let’s see how this API works!

The Lootbox Project

Along with the NFT API, Infura released an NFT Gallery Project on their Github to demo its capabilities. All I will have to do is input an Infura project ID and secret, then connect my MetaMask wallet to the dapp frontend. Then the dapp uses the API to fetch all my NFTs to display nicely in the frontend. So to break that down, I will need the following things for this project:

• An Infura account
• Infura Project ID and Secret
• A MetaMask wallet extension with NFTs in it

Let’s get started!

Step 1 - The Infura Project ID and Secret

Before starting the Lootbox project, I want to gather the necessary items. So first, I’ll head to infura.io, log in, and create a new project. Then, I can grab the Project ID and Project Secret for use later.

Step 2 - MetaMask

This step will be quick because I already have the extension installed in my browser. If someone following along with this article doesn’t, however, head to metamask.io and download the extension for your specific browser. Then follow the steps to create a new account.

Next, I’ll sign in and switch accounts to the wallet address that holds my NFTs. If you need to acquire an NFT, you can head to your favorite marketplace and buy one or try to create one yourself using the Infura NFT API 😉. Either way, you will need some ETH in your wallet.

Step 3 - Setting Up The Project

With all the prep work out of the way, I can start building the project. So next, I’ll clone the project repo onto my local machine. I’ll first navigate to the folder I want to work out of and then type the following command:

git clone https://github.com/INFURA/nft-api-lootbox-gallery-app.git

Next, I will change directories into the project folder and install dependencies using yarn:

cd nft-api-lootbox-gallery-app
yarn

After everything is installed, the last thing I need to do is create a .env file to store my environment variables and secrets. I’ll just copy the file that’s already there and add my variables to it.

cp .env .env.local

Now I’ll open up the project and add my Project ID and Project Secret from my recently created Infura project. There’s also an option to input the Account Address of any wallet to view their NFTs, but I’ve got my own I want to see in the Lootbox NFT Gallery.

With all the setup out of the way, I can finally run the Lootbox project. But first, I want to browse through the code to see what’s happening under the hood.

Step 4 - The Lootbox Code

Based on the README file of the Lootbox project, the most important components are in the pages/index.tsx, hooks/useWallet.ts, and pages/api/assets.ts files. So I’m going to browse those and see if I can figure out how this project uses the Infura NFT API.

After looking through these files, I can see the pages/index.tsx file contains the code which displays the frontend for the project. If the showGallery state variable is true, then it should display my NFTs. If it’s false, then it should display the welcome text with the Connect Wallet button. This Connect Wallet button connects to some functions in the hooks/useWallet.ts file, so I’ll check there next.

In the hooks/useWallet.ts file, I can see the function which is supposed to grab my NFTs. Specifically, the getTokens function.

 const getTokens = async (accountAddress: string) => {
    try {
      const { data } = await axios.post('/api/assets', { accountAddress });
      return data.assets;
    } catch (error) {
      setTimeout(() => {
        setErrorMessage('Error getting tokens');
      }, 2000);
      return;
    }
  };

This function seems to make a POST request using a parameter from the /api/assets file and return the results with my assets. So looking into the pages/api/assets.ts file, I can see where the NFT API is being used.

  try {
    const { data } = await axios.get(  `https://nft.api.infura.io/networks/1/accounts/${accountAddress}/assets/nfts`,
      {
        headers: {},
        auth: {
          username: `${process.env.INFURA_PROJECT_ID}`,
          password: `${process.env.INFURA_PROJECT_SECRET}`
        }
      }
    );

    return res.status(200).json({
      assets: data.assets,
    });

This code calls the get function of the NFT API, using my Infura Project ID and Project Secret to access my account, and returns my NFTs in a JSON object. Following the path back to the pages/index.tsx file, if the getTokens function from hooks/useWallet.ts doesn’t timeout, it will return my NFTs, switch the setGallery state variable to true, and display my NFTs on the page.

Cool! So I’ve got an idea of how it works, let’s see it in action!

Step 5 - Running The Lootbox Project

To run the project locally, I just need to type:

yarn dev

After navigating to http://localhost:3000/, I can see a nice-looking frontend for the Lootbox Project.

Clicking on Connect Wallet prompts my MetaMask wallet to pop up to approve the connection request.

After connecting, it immediately starts fetching my tokens. This is the point where I now know the dapp is using the NFT API.

Once the fetch is successful, it displays my NFTs in a fancy gallery, allowing me to browse and choose each one to get a better look at them. Neat!

Conclusion

My verdict on the Infura NFT API is that it's a tool that cuts down my development time, and there’s quite a bit I can do with it. It’s handy to build, mint, and interact with NFTs from an easy-to-use API. Although I am more familiar with building NFT contracts with Solidity and deploying them with Truffle, I can easily see how this would help smooth the transition of a Web2 dev into Web3. Using JavaScript rather than writing a smart contract will be a huge time saver for many Web2 developers.

I would suggest trying the NFT API out for yourself. It’s still in private beta, but anyone can register. For more information on its capabilities, you can check out this YouTube demo or Infura’s documentation.

Archive nodes are particular nodes on the Ethereum Network that store historical blockchain data. Because they offer this historical information, they are helpful when you need to audit past transaction history or gather data. Services like Etherscan and Dune Analytics use archive nodes, but anyone can run one themselves.

In this article, we will review the different types of Ethereum nodes, dive deeper into Archive Nodes, and introduce the new archive node capabilities of Infura. We’ll then walk through a real-world project to show how to connect the Infura API and web3.js to a pre-built react frontend. Once complete, the user will be able to query an Archive Node for some statistics for a given Ethereum wallet address.

What Are Ethereum Nodes?

In simple terms, a node is just a connection point in a network. However, in the case of Ethereum, different types of nodes hold various responsibilities to the network.

The Ethereum blockchain operates on what is called the Ethereum Virtual Machine (EVM), which is a type of decentralized global computer. Nodes, in this case, provide the processing power for this computer. They serve requested data, create and validate blocks, store transaction data or smart contract code, and much more. Anyone with the required hardware can download an Ethereum client and spin up their own node to participate in the network. This also prevents any single entity from controlling the entire network and contributes to Ethereum’s decentralization.

There are four main types of Ethereum nodes, each contributing to the network differently. Together they relay information to other nodes, verify transactions and the EVM state, and provide the infrastructure needed to keep the Ethereum Network operating efficiently. They communicate with one another to ensure they all agree on the state of the network. Therefore, having more nodes makes the network stronger and more resilient to attacks.

Types of Ethereum Nodes

Full Node

Full Nodes verify transactions and EVM state, validate blocks, launch and execute smart contract code, and can serve network data when requested. They also store the state of the Ethereum Blockchain up to the most recent 128 blocks but can build an archive of historical states on demand.

Mining Node (Commonly referred to as a “Miner”)

A Miner is a Full Node running a mining client. In its present state, Ethereum provides consensus through the proof-of-work algorithm. To summarize, this means a mining node competes in a computation race with other mining nodes to create the next block. Once created, the new block is broadcast to the network to be verified by other nodes and appended to the end of the blockchain.

Light Node

A Light Node is a “light” version of a Full Node, which only contains block header data such as the previous block’s hash and a timestamp rather than the block data in its entirety. They make on-demand requests to Full Nodes and only validate certain pieces of state as required by their users. Example uses are to check balances, verify if a transaction was confirmed, check event logs, and do other light-duty tasks. Light Nodes can be easily run by lower-capacity devices such as a mobile phone or RaspberryPi.

Archive Node

An Archive Node is a type of Full Node that is running in “archive mode”. They contain all the same data as a Full Node but also all the historical state data of the entire blockchain since Genesis Block. We’ll focus on archive nodes for the remainder of this article.

More on Archive Nodes

Although Full Nodes can rebuild historical blockchain state data, this process is slow and inefficient. Depending on the use case, this data may need to be served up quickly. This is where Archive Nodes come in. Because Archive Nodes contain historical data from the very first block, they can easily trace any arbitrary transaction at any time.

Why Access an Archive Node?

If there is information you need to get from the Ethereum Blockchain before the most recent 128 blocks, the most efficient way to get this is through an Archive Node. Some of this information may include account balances, smart contract code, transaction counts, or the value at a particular storage position. They also enable the testing of smart contract code without creating a transaction on the blockchain.

Specs to Run an Archive Node

Running your own node means having more control of the information you share with the blockchain. You can create more secure and private dApps (decentralized apps), and your addresses and balances won’t leak to random nodes on the network. Running an Archive Node also means quick access to historical blockchain data without signing up for any third-party services.

These are the specifications you would need to be able to run your own Ethereum Archive Node:

• A CPU with at least four cores
• 16 GB or more of RAM
• An SSD drive with at least 6 TB of space
• At least 25 MBit/s bandwidth

As you can see, the requirements to spin up an Archive Node make it reasonably accessible. Not exactly cheap, but still within reach to an individual. It does require some technical know-how and constant upkeep though. If you don’t have the time, drive, or equipment to run your own, a Node Provider is a great alternative.

Archive Node Providers

Node Providers make it simple for anyone to access and interact with the Ethereum Blockchain through their easy-to-use APIs. All you need to do is create a new project and then easily call JSON RPC methods with the URL they provide.

Infura

Infura is arguably the most popular Node Provider in the space. It was created by ConsenSys, the team behind MetaMask and the Truffle blockchain development framework. They’ve been around for a while, and their services are great for beginners and organizations looking to scale.

• Now has free Archive Node Access
• Great free pricing tier
• Offers access to Layer 2 scaling solutions
• Many other add-ons to fit your needs
• Excellent documentation

Use Cases

Depending on the type of project you are building, there are several different technologies you could connect to a Node Provider.

Truffle / Hardhat

If you are writing smart contracts that interact with historical data, then a development suite such as Truffle or Hardhat would fit your needs. They both have an assortment of built-in tools that make the entire development lifecycle for your dApp much easier. Connecting to an Archive Node, in this case, is as easy as setting your provided API URL endpoint as a variable to be used in your frontend code.

Ganache

If you need quick access to an Archive Node for local development or testing, Truffle offers a personal blockchain that accomplishes this nicely. This blockchain is called Ganache. As of Ganache version 7.0, spinning up a local instance of the Ethereum blockchain with Archive access is as simple as one command:

ganache --fork

You could then interact with it similarly as above, using the URL: http://localhost:8545, or whatever you set the port to.

Direct Integration

If you don’t require a suite of blockchain tools, then you can use your Node Provider URL directly in your frontend code and connect to it with a JavaScript library such as ethers.js or web3.js. This is the option we will explore in the project below.

The Project

As mentioned at the start of this article, we will be making a simple “Year in Review” type app to display some wallet statistics from 2021. We will clone a pre-built frontend, so all we have to worry about is querying an archive node and then displaying the data nicely.

What we will learn:

• How to get an Infura API URL with archive access
• How to gather archive data using an Infura API URL and web3.js
• The JavaScript required to collect the data from the blockchain
• How to put the data together to display it nicely in the app

What is needed to complete the project:

• An Infura account
• Git
• Node / npm
• A code editor

Additional resources

• Infura docs
• Web3.js docs

The Infura API URL

The first step in our project is to set up our Infura account and acquire our API Endpoint URL. Head to https://infura.io/ and either create a new account or log in.

Create a new project to get the API Endpoint URL we will need later in our project.

Since archive access is now free for all users, we don’t need to complete any other steps with our Infura account.

With that out of the way, let’s start working on the frontend!

The Frontend

We will be building on top of a pre-made React frontend for the rest of this project. If you’ve never used React before, that’s okay. We will be walking through the rest of the steps together.

To install the project properly, we will use git and node package manager (npm). To see if they are already installed, we can check the version numbers in the command line:

npm --version

git --version

If they still need to be installed on your machine, you can get them at the following links:

• Node / npm: https://nodejs.org/en/
• Git: https://git-scm.com/downloads

Once installed, we are ready to start working on the rest of the project:

1. In the command line, navigate to the folder you would like to work out of and clone the repository for our project:

   git clone https://github.com/paul-mcaviney/archive-node-project-frontend.git
   

2. Change directories into the new project folder and install the required dependencies: cd archive-node-project-frontend

   npm i
   

3. After the dependencies finish installing, let’s run the project to make sure it’s working correctly so far:

   npm start
   

   If everything is installed correctly, we will now have a frontend running on http://localhost:3000 that looks like this:

   

   There’s a text field we will use to enter a wallet address. Clicking the Submit button takes us to our results page. We can also return to the input page from here by pressing the Enter New Address button.

4. Before we start coding, we need to install one more dependency. We will be using web3.js to access an Archive Node with our Infura URL. To install web3.js, type the following command in the directory for our project:

   npm install web3
   

5. We will do all of our coding in the App.js file under the src folder. The first bit of code we need to write is to import web3 to our project and connect it to our Infura URL. Under the import statements, and before the App function, add the following code:

   const Web3 = require('web3'); 
   const infuraURL = 'YOUR_INFURA_URL_HERE'; 
   const web3 = new Web3(new Web3.providers.HttpProvider(infuraURL));
   

   Note: Do not upload this project to a public repository without first hiding your actual Infura URL. You can use environment variables for this.

6. We’ll be using the useState React hook to update our UI. You’ll notice it’s already imported at the top of our file. Next, let’s add some React state variables to make it easier to display the data we gather from our Archive Node. Under the results state variable, add the following:

   const [address, setAddress] = useState(''); 
   const [currentBalance, setCurrentBalance] = useState(0); 
   const [startOfYearBalance, setStartOfYearBalance] = useState(0); 
   const [endOfYearBalance, setEndOfYearBalance] = useState(0); 
   const [balanceDifference, setBalanceDifference] = useState(0); 
   const [transactionCount, setTransactionCount] = useState(0);
   

7. Now we need to update the handleInput function to assign the user input to our address state variable instead of logging the comment:

   const handleInput = event => {     
     setAddress(event.target.value); 
   };
   

   Note: You’ll notice we didn’t put any checks here to make sure what the user inputs is actually an Ethereum wallet address. This is for the sake of keeping this tutorial simple. You will want to handle this differently if deploying publicly.

8. The last bit of JavaScript is an asynchronous function that will gather the data from the Archive Node, convert it to more readable values, and set our state variables. Under the comment that says Your JavaScript code will go here, type the following code:

   // Access and process data from Ethereum blockchain
   const accessEthereum = async () => {
   
     // 2021 Start and End Block variables 
     const START_2021_BLOCK = 11565019;
     const END_2021_BLOCK = 13916165;
   
     // Get current balance of address 
     const balance = await web3.eth.getBalance(address);
   
     // Convert balance from wei to ETH and set state variable
     setCurrentBalance(await web3.utils.fromWei(balance.toString(), 'ether'));
   
     // Get wallet balance at the start of 2021 (Block #11565019)
     const startBalance = await web3.eth.getBalance(address, START_2021_BLOCK);
   
     // Get wallet balance at the end of 2021 (Block #13916165)
     const endBalance = await web3.eth.getBalance(address, END_2021_BLOCK);
   
     // Convert startBalance to ETH and set state variable
     const startBalanceAsETH = await web3.utils.fromWei(startBalance.toString(), 'ether');
     setStartOfYearBalance(startBalanceAsETH);
   
     // Convert endBalance to ETH and set state variable
     const endBalanceAsETH = await web3.utils.fromWei(endBalance.toString(), 'ether');
     setEndOfYearBalance(endBalanceAsETH);
   
     // Set balanceDifference from start to end of 2021
     setBalanceDifference(endBalanceAsETH - startBalanceAsETH);
   
     // Get transaction count at start of 2021 (Block #11565019)
     let startTransactions = await web3.eth.getTransactionCount(address, START_2021_BLOCK);
   
     // Get transaction count at end of 2021 (Block #13916165)
     let endTransactions = await web3.eth.getTransactionCount(address, END_2021_BLOCK);
   
     // Set total transaction count in 2021
     setTransactionCount(endTransactions - startTransactions);
   
     // Received results, condition met to show them on screen
     setResults(true);    
   
   };
   

9. Moving on to the HTML, the first thing we need to do is replace the button function with the new one we just wrote. Change the function call for the button under the Change this button function comment:

   <button onClick={accessEthereum} className='form-button' type='submit' name='submit' id='submit'>
   

10. The final bit of code we need is the HTML that will display the data we gathered from our Archive Node. In the return statement, scroll down to the comment that says Your HTML code will go here and add the following:

    <h3>{address}</h3>
    
    <p className='result-heading'>Current Balance</p>
    <p>{currentBalance} ETH</p>
    
    <p className='result-heading'>Start of 2021 Balance</p>
    <p>{startOfYearBalance} ETH</p>
    
    <p className='result-heading'>End of 2021 Balance</p>
    <p>{endOfYearBalance} ETH</p>
    
    <p className='result-heading'>Difference from Start of 2021</p>
    <p>{balanceDifference} ETH</p>
    
    <p className='result-heading'>Number of transactions in 2021</p>
    <p>{transactionCount}</p>
    <br />
    

    To see the complete project code, check out this Github repository.

11. Now let’s test out our app and see if it works! First, start the app:

    npm start
    

    Enter an Ethereum wallet address to the text field and hit Submit. If you don’t have a wallet address that was active in 2021, you can use Vitalik’s.

    

    Awesome! Our results are displayed correctly, and we can see all the activity of the wallet address in 2021!

Conclusion

By following this tutorial, you accessed the data on an Archive Node using your Infura API Endpoint URL, then displayed it nicely in a simple ETH Year in Review app.

An Archive Node is required to access data from the Ethereum Blockchain prior to the most recent 128 blocks. They store all historical state data from the very first block and serve it up much more quickly and efficiently than a Full Node. Now that Infura offers free Archive Node access to all users, gathering historical blockchain data has never been easier!

Non-Fungible Tokens (NFTs) have exploded in popularity over the last year. And with NFTs being used for art, PFPs, lifestyle brands, sports, games, the metaverse, and more, they won’t be going away anytime soon. But the current state of NFTs has a few problems - notably, minting on Ethereum can be prohibitively expensive and the metadata behind those NFTs is often centralized.

In this article, we’ll look at one way to solve those issues by creating and deploying an NFT to the Polygon Network and using IPFS to store the metadata. In our example, we’ll use Truffle as our development environment and Infura to connect and interact with the blockchain and IPFS.

A Quick Overview of NFTs

Fungible tokens are cryptographic tokens that can be exchanged for any other of the same token (1 == 1). These include cryptocurrencies such as Bitcoin (BTC) or ETH. One Bitcoin is exactly the same as any other Bitcoin.

In contrast, NFTs are not fungible - one token is not replaceable by another, and they may have varying values (1 != 1). An NFT is an undisputable representation of digital ownership. It can be used to represent any manner of digital property such as images, videos, music, and so much more.

NFTs on Ethereum and Layer Two

Most NFTs are created on the Ethereum Network, as it allows for the greatest sense of security and decentralization. However, for the average person, there is a major issue: Transacting on Layer 1 of the Ethereum Network is expensive.

Over the course of 2021, several solutions to this problem have gained popularity. Layer 2 solutions such as Arbitrum, zkSync, and the Polygon Network are here to provide a more user-friendly experience. Transaction fees on these networks are a fraction of what they would be on Layer 1, and in most cases, significantly faster.

Another current problem with NFTs is that the metadata they contain isn’t always stored in a decentralized manner. If the organization hosting the metadata disappears, so does the value of your NFT. The best solution is to host the metadata using a global, peer-to-peer file system such as InterPlanetary File Storage (IPFS).

Combining technologies such as Polygon and IPFS creates a cost-effective method to deploy and store your NFT in a more decentralized and permanent way. Although we could use no-code services such as those provided by ConsenSys, it’s more fun to actually deploy one yourself and you will get a better understanding of how it all works behind the scenes.

So let’s look at how you can create and deploy an NFT to the Polygon Network. We will use Truffle as our development environment and Infura to connect and interact with the blockchain, and to store the metadata with IPFS.

Before deploying, we will test on a local instance of a blockchain with Ganache. When it’s ready to go live, we will deploy to the Polygon Mumbai Test Network and will verify the NFT on OpenSea, the world’s most popular NFT platform.

The Project

What You Will Learn

• Upload the NFT image and metadata to IPFS via Infura
• Set up the Polygon Network in MetaMask and get test funds
• Set up Truffle Development Environment
• Write an NFT smart contract
• Test deployment locally using Ganache
• Deploy to Polygon testnet using Truffle console and Infura
• Verify the NFT on opensea.io

What You Will Need

• NodeJS / NPM - installation and package management
• Truffle - development environment
• Ganache - local blockchain instance for testing
• Infura account - used to interact with IPFS and Polygon Networks
• MetaMask account - supply funds to process transactions

Additional Resources

• Polygon Docs
• Truffle Docs
• Infura Docs
• MetaMask Docs

Setting Up Accounts

Before we get to the fun parts like building and testing, let’s set up our accounts and get everything in place. This will ensure the rest of the process goes smoothly.

Get an Infura Account

Infura is an Ethereum node provider and API. It will allow us to easily connect to the Polygon Network and also provides an easy-to-use method for utilizing IPFS.

The first thing we need to do is head to infura.io and set up a free account. After verifying our email address, we can access the dashboard, where we can make new projects. The Polygon Network isn’t enabled by default, however.

We can add Polygon to our plan by selecting the “Add-Ons” tab on the left-hand side of the screen and scrolling down to “Network Add-Ons”. Next, we select “Polygon PoS Add-On” and go through the prompt to add it.

Now we’re ready to create a new project. Let’s head back to the dashboard and click on the “Create New Project” button. We’ll select Ethereum as the product and name our project Polygon-NFT.

Once our project is created, there are several things to note:

• The Project ID
• The project secret
• Endpoints selection
• Our endpoint link

Let’s change our Endpoint from MAINNET to POLYGON MUMBAI, which is the Polygon testnet. Our Endpoint link will then change. We will need the values on this page later, but for now, we are done with the project page.

IPFS via Infura

Since we are already in our Infura account, let’s go ahead and create another project. This one will be for utilizing IPFS to store the image and metadata of our NFT. This time when we create a new project, we will select IPFS as the product. Let’s name this one Polygon-NFT-Metadata.

For the next steps we will need the Project ID, project secret, and endpoint URL, but first, we need an image for our NFT.

Just right-click and save this to your machine ;)

Feel free to use your own image moving forward. OpenSea recommends the image size to be 350 x 350 pixels.

Now let’s upload the image to IPFS!

Using a command terminal, we will cd into the folder where our image is stored. To upload the image, type the following command:

curl -X POST -F file=@myfile \ -u "PROJECT_ID:PROJECT_SECRET" \ "https://ipfs.infura.io:5001/api/v0/add"

Note:

• @myfile should be the name of the image file in the current folder. So in our case @polygon-nft.jpg.
• PROJECT_ID and PROJECT_SECRET will be the keys provided in the settings for our Infura project.

The output from the command should look something like this:

The most important part of the output will be our “Hash”. We can actually verify the image was uploaded successfully by pasting that Hash into the following URL: https://ipfs.io/ipfs/YOUR_HASH_HERE

It’s important to note that Infura pins our data to IPFS by default. If we ever want to remove an item from IPFS we have to unpin it. Now that our image is stored on IPFS, let’s get the metadata stored there as well. According to standards by OpenSea, we will want our metadata in JSON format like so:

{ 
  "name": "My Sweet Polygon NFT",     
  "description": "Our amazing NFT deployed to the Polygon Network",     
  "image": "ipfs://YOUR_HASH_HERE" 
}

So let’s create a new text file in the same folder on our local machine as our NFT image. We can use any text editor for this; it doesn’t need to be anything fancy.

We’ll add the metadata in the same format as above. However, rather than using YOUR_HASH_HERE we’ll insert the actual Hash for our image that we just verified. We’ll save the file as nft-metadata.json. We also need to make sure there is no comma after the last item in our JSON file. If there is a comma, then OpenSea will not display the NFT properly.

Now we can add this file to IPFS using the same command as last time; we just need to replace the file name with @nft-metadata.json.

Excellent! We now have our metadata pinned to IPFS which has a link that points to our already pinned image. We’ll copy the Hash in the output to use later.

Setting Up MetaMask

In order to interact with the Polygon Network and to pay any transaction fees, we will need to set up a Web3 wallet. We will use MetaMask to do this. It is installed as a browser extension and allows us to connect to Decentralized Apps (dApps).

Let’s head over to metamask.io and download the extension for our browser. When using a crypto wallet like MetaMask, it’s a good idea to understand wallet safety.

Remember: Never share your seed phrase with anyone! Whoever has your seed phrase can withdraw your tokens.

We will need to use the 12-word seed phrase when setting up our Truffle project. So be sure to write that down and save it for later. Once we install MetaMask and open it to the dashboard, we need to add Polygon to our Networks dropdown.

When we click the dropdown, it reveals a button to add new networks to the list. So we’ll press the “Add Network” button, and add both the Polygon Mainnet and Mumbai Testnet.

We will need to enter in the following information:

Mumbai Testnet

Network Name: Mumbai (Polygon Testnet)

New RPC URL: https://rpc-mumbai.maticvigil.com/

Chain ID: 80001

Currency Symbol: MATIC

Block Explorer URL: https://mumbai.polygonscan.com/

Polygon Mainnet

Network Name: Polygon Mainnet

New RPC URL: https://polygon-rpc.com/

Chain ID: 137

Currency Symbol: MATIC

Block Explorer URL: https://polygonscan.com/

Now we have the Polygon Network added to our MetaMask, but if we switch to the Mumbai Testnet, there’s no MATIC! Let’s change that. We’ll need to copy our wallet address, which is listed under the name of our Account. It starts with 0x…

Next, we’ll head over to https://faucet.polygon.technology/ which is a faucet that provides test funds for development. We need to select the Mumbai Network and then paste our address into the text field. Once we hit “Submit” we should see some MATIC tokens in our MetaMask wallet after a minute or two.

Note: If you have multiple accounts in your MetaMask wallet, Truffle uses the first one by default. So be sure to add the test MATIC tokens to the first account in your list.

Now that we have loaded our wallet with some test tokens, we are ready to move on.

Install Truffle and Ganache

Truffle

Truffle is a development environment that provides tools to make building on the blockchain much easier. In order to install it via the command line, we will need NodeJS v8.9.4 or later and Node Package Manager (npm). If it’s not already installed, check out this link.

Once it’s installed on our machine, we can install Truffle using this command in the terminal:

npm install -g truffle

We can type the command truffle version afterward to ensure it was installed correctly. If there are any errors, be sure to add the npm modules to your path.

Ganache

Next we’ll install Ganache, a local blockchain instance used for testing before deploying to the Mumbai Testnet.

Ganache has a GUI version that can be downloaded here, but we will use the terminal version for the rest of this tutorial. It can be installed using this command:

npm install ganache --global

Again, we can verify proper installation by checking the version: ganache --version

Setting Up Our Project

Now that our accounts are set up and everything is installed properly, let’s start putting it all together. The first step is to navigate in our terminal to where we want to create our project and make a new directory.

mkdir polygon-nft-project && cd polygon-nft-project

One incredibly useful thing about Truffle is they offer a full suite of “boxes” for getting started quickly. They are essentially boilerplates that include helpful modules, pre-made smart contracts, frontend views, and more. For this project, we will utilize Truffle’s Polygon Box. Installation is simple; we just need to type this command:

truffle unbox polygon

After installation, we can see there are several new files in our project folder. The most important ones we will be working with are the README.md file, truffle-config.polygon.js, the 1_deploy_simple_storage.js under the migrations folder, and SimpleStorage.sol files, which can be found in the ‘contracts` folder.

You will likely see an ethereum and polygon folder under contracts. This is because typically when a project is deployed to Polygon, it should also be deployed to Ethereum so users can easily bridge their assets back and forth. We can delete the SimpleStorage.sol contracts since we won’t be using them.

Taking a quick glance through the README.md file, we can see that in order to deploy to the Polygon Network, we will have to add two things:

1. The Mnemonic phrase (seed phrase) of the wallet we are using
2. The Infura Project ID

We’ll want to store these in a .env file and make sure it’s added to our .gitignore so we don’t accidentally upload these secrets if storing our project on a public repository.

Downloading the Polygon Truffle Box also installed the .dotenv package for us. All we need to do is create a .env file in our root folder.

The mnemonic phrase for our wallet can be found in our MetaMask settings under the “Security & Privacy” heading. The Project ID can be found under the “Keys” heading in our Infura project settings. Our .env file will look something like this:

MNEMONIC="your twelve words here ..."`
INFURA_PROJECT_ID="project ID # here"

The next thing we should do is update Truffle to use the latest version of Solidity. In our truffle-config.polygon.js file, we can add the compiler version we wish to use.

Under the compilers section, within the solc curly braces, we’ll add the following: version: “0.8.11” (the latest version of Solidity at the time of this writing).

It should look like this:

// Configure your compilers
compilers: {
    solc: {
        version: "^0.8.11"
    }
},

Note: If you didn’t delete the SimpleStorage.sol contracts, then you will need to update their Solidity version in order to compile properly. Simply change the pragma line to the following: pragma solidity >=0.4.21 <0.9.0;

The last bit of prep work is just to install the OpenZeppelin contract library, as we will import several contracts. We can install it by typing this command in the root directory of our project:

npm install @openzeppelin/contracts

We are utilizing the OpenZeppelin library to make writing our smart contract easier and much safer. The contracts we will use have had thorough security audits and it ensures we are adhering to the industry standard for NFTs.

With our project set up properly, we are ready to get to the best part… Creating the NFT!

The Smart Contract

We will open up our preferred code editor from our project root folder. (I’m using vscode so the command is code ..) Create a new file under the contracts folder named PolygonNFT.sol.

Note: If you need to brush up on the Solidity coding language, check out my Solidity Basics Series.

We’ll be using the following smart contract for our NFT:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.11;

// Import the OpenZeppelin contracts
import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/utils/Counters.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

// Declare our contract and inherit from the OpenZeppelin ERC721 and Ownable contracts 
contract PolygonNFT is ERC721, Ownable {
    // Helpers for counting safely and converting data to strings
    using Counters for Counters.Counter;
    using Strings for uint256;

    // State variable for storing the current token Id
    Counters.Counter private _tokenIds;
    // Map token Ids to token URI
    mapping (uint256 => string) private _tokenURIs;

    // ERC721 requires a name for the NFT collection and a symbol
    constructor() ERC721("PolygonNFT", "PNFT") {}

    // Set the URI (metadata) for tokenId
    function _setTokenURI(uint256 tokenId, string memory _tokenURI)
        internal
        virtual
    {
        _tokenURIs[tokenId] = _tokenURI;
    }

    // Return the Token URI - Required for viewing properly on OpenSea
    function tokenURI(uint256 tokenId)
        public
        view
        virtual
        override
        returns (string memory)
    {
        require(_exists(tokenId), "Token does not exist");
        string memory _tokenURI = _tokenURIs[tokenId];

        return _tokenURI;
    }

    // Mint the NFT to the provided address, using the provided metadata URI 
    // Only the wallet address that deployed this contract can call this function
    function mint(address recipient, string memory uri)
        public
        onlyOwner
        returns (uint256)
    {
        _tokenIds.increment();
        uint256 newItemId = _tokenIds.current();

        _mint(recipient, newItemId);
        _setTokenURI(newItemId, uri);

        return newItemId;
    }
}

Pretty short, right?! That’s the beautiful thing about the composability of Web3. OpenZeppelin is doing most of the heavy lifting here with their ERC721 standard.

Basically, we are simply defining the NFT collection and symbol, supplying the NFT metadata via the _setTokenURI() function, putting it together with our mint() function, and then providing a way for OpenSea or anyone else to retrieve the NFT metadata through our tokenURI() function.

Testing Deployment With Ganache

Deploying to the blockchain is pretty simple, but before we can do that, we need to modify the 1_deploy_simple_storage.js file under the migrations folder. We just need to replace every instance of SimpleStorage with whatever we named our NFT smart contract. In our case: PolygonNFT. We should also rename the file to 1_deploy_polygon_nft.js to eliminate any confusion.

Our migration file should now look like this:

const PolygonNFT = artifacts.require("PolygonNFT"); 

module.exports = function (deployer) { 
    deployer.deploy(PolygonNFT); 
};

Before deploying our project to a live blockchain, it is common practice to test it on a local blockchain instance. We will use Ganache to do this. In a new terminal window, we will use this command to get it up and running:

ganache

The terminal should output some Available Accounts, their Private Keys, and so on.

To deploy our project to Ganache, open up the original terminal window. In the root directory of our project, type the command:

truffle migrate --config=truffle-config.polygon.js --network=development

Since there are two config files in our project, we need to specify which one to use. Truffle will use the truffle-config.js file by default. After hitting enter, we can see that Truffle compiles our contracts and then starts the migration. If all goes successfully, you will receive a transaction receipt that will look something like this:

Take note of the contract address

Now that our contract has migrated successfully to our local blockchain instance, we can use the Truffle Console to interact with it. The Truffle Console is a powerful tool that allows us to use JavaScript to interact directly with our contract without having to set up a frontend. To use it, type the command:

truffle console --config=truffle-config.polygon.js --network=development

Notice how the command prompt changes to truffle(development)>. We are now ready to start interacting with our smart contract.

First, we need to get an instance of our contract. Copy the contract address from our transaction receipt to be used in this line of code:

let instance = await PolygonNFT.at("YOUR_CONTRACT_ADDRESS_HERE")

It will return undefined but if we type instance it should output our contract ABI. Now we can call the mint function. We will need a contract address in which to send the NFT and our IPFS URI from earlier in the format: ipfs://YOUR_HASH_HERE

await instance.mint("YOUR_WALLET_ADDRESS", "YOUR_METADATA_URI")

It’s important to note that the mint function is being called by the address that deployed the contract because that is the one we logged into the Truffle Console with by default. The address we placed in the code above is the recipient of the NFT.

If all went well with our code above, we shouldn’t see any errors after we hit enter! We now know our contract works and we are able to mint an NFT from it. Unfortunately, since this is a local blockchain instance, we don’t have OpenSea or PolygonScan to verify that our NFT actually exists. For that, we will deploy to the Mumbai Testnet.

Deploy to Polygon Testnet

The process to deploy to the Mumbai Testnet is very similar to launching on our Ganache blockchain instance. We just need to exit the Truffle console by typing ctrl+c twice and then follow the exact same steps as above. The only difference is we will replace the network= development with polygon_infura_testnet.

Before moving forward, we need to make sure our Mnemonic phrase and Project ID are set up properly in our .env file otherwise, the next steps won’t work. (See the steps in the Setting Up Our Project section.) With those in place, our commands will now look like this:

truffle migrate --config=truffle-config.polygon.js --network=polygon_infura_testnet

The migration will take a little bit longer than our Ganache instance. Once it’s complete it will output a transaction receipt that looks similar to our last one. This time we can verify that our contract was successfully migrated to the Mumbai Testnet by entering our contract address to https://mumbai.polygonscan.com/address/YOUR_ADDRESS_HERE

Excellent! Our contract is live on the Mumbai Testnet! Now let’s interact with it and actually mint our NFT!

We’ll access the Truffle Console using the same commands as before, again, replacing the network= development with polygon_infura_testnet.

truffle console --config=truffle-config-polygon.js --network=polygon_infura_testnet

Get an instance of our contract using the contract address that was output on our Mumbai Testnet transaction receipt:

let instance = await PolygonNFT.at("YOUR_CONTRACT_ADDRESS_HERE")

And now, for the moment we’ve been building towards this entire article! Mint our NFT to our desired address using our IPFS URI in the format: ipfs://YOUR_HASH_HERE

await instance.mint("YOUR_WALLET_ADDRESS", "YOUR_METADATA_URI")

If there aren't any errors, we can check our contract on mumbai.polygonscan again and see that our mint() function was called! This time, we can verify that our NFT actually exists by checking it out on OpenSea.

Verify Our NFT On OpenSea

We can easily check out our new NFT on OpenSea by copying our contract address into the search bar at https://testnets.opensea.io/. Ethereum addresses have two versions, one that is checksummed and one that is not. The difference being the non-checksummed version is all lowercase. We may need to use the non-checksummed version to find our NFT on OpenSea. We can get this address by clicking on the Txn Hash on mumbai.polygonscan and then copying the address across from Interacted With (To):

Your contract address will be different

If our metadata was entered correctly we should now see our beautiful, new NFT live on OpenSea!

Conclusion

Congratulations! You have successfully deployed an NFT to the Polygon Mumbai Testnet! You uploaded your NFT image and metadata to IPFS using Infura’s API, set up your Truffle project and wrote a smart contract to create an NFT, tested deployment locally using Ganache, deployed to the Polygon Testnet with Truffle, Infura, and MetaMask, and finally, verified your NFT on OpenSea.

You now have the knowledge to deploy to the Polygon Mainnet, just make sure you have real MATIC tokens in your MetaMask wallet. Additionally, when deploying, be sure to use network=polygon_infura_mainnet instead of polygon_infura_testnet.

Your next steps would be to deploy to the Ethereum Mainnet to be able to bridge your NFT from Layer 2 to Layer 1. That is the topic for another article so be sure to check out the Polygon Docs in the meantime.

Thank you for following along with this tutorial! Take care, and happy building!

(The code for this project can be found here: https://github.com/paul-mcaviney/polygon-nft-project)

I'm Paulie from the Newsletter Team, and this is my story.

A Bit About Me

In 2021, I was having difficulty wanting to be at my job. Being an overhead crane technician and working away from home on shiftwork for seven years was starting to get old, and it was time for a change. Tech has always been a field I’ve been interested in. I love computers and building cool shit.

I’ve been dabbling in different technologies since 2017, from web dev to Python to game development with Unity and C#. But I've been a computer nerd pretty much my whole life.

I figured around the beginning of 2021, why not give web development an actual shot? So I started down the freeCodeCamp path, learning frontend, and building websites.

I got a couple cool sites up and running and was in the process of starting a freelance hustle when I began hearing a lot of buzz on Twitter about Web3. Of course, I had to at least look into it. I’m not one to dismiss something just because people say it’s all hype.

After I dug into Ethereum and realized just how valuable this tech could be in the future, I had to give it a try. Right around that time, I stumbled across some DAOs, but none really clicked with me.

Then I read Nader Dabit’s tweet:

I knew this was something I needed to get involved with. Unfortunately, I wasn’t entirely confident in my building skillz yet. But what better place to learn than a group of Web3 developers and enthusiasts?! So I minted my first-ever NFT and joined Developer DAO.

Overwhelmed but Optimistic

I soon discovered just how fast the web3 space moves. So much was happening in the DAO, it was hard to know where to focus or spend my time. It was obvious right off the bat though, that this is where I should be.

I could see a lot of enthusiasm across the entire DAO and so many talented people! The only thing was, I felt I wasn’t good enough to contribute. How could I? With so many people building things beyond my skill level, I would just make a fool of myself.

So I kept quiet, posting things once in a while that I came across on Twitter and participating in a few conversations here and there. However, I was still able to learn a lot even without contributing. People posted excellent links to learning resources and ideas flowed like crazy! I started the #100DaysOfWeb3 Challenge on Twitter and picked up the idea to start writing about what I’ve been learning. So, of course, I started my own blog.

Holders of the Devs4Revolution NFT can now mint their own Pixel Dev!

Paulie the Writer?!

I never actually saw myself as a writer before. But, through writing down my learnings, I’ve kind of taken a liking to it! It has helped me articulate my thoughts and solidify the concepts I learn. If I know a topic well enough to write it down in my own words, I’d say it has firmly lodged itself in my brain. I have returned to my own writing a few times to review things I get stuck on.

On top of all that, it helps other people! There have been multiple people reaching out saying I’ve helped them in one way or another, even inspiring others to start their own blogs! Man, that is a great feeling! 😁

Not to mention the opportunities that come along with proving you can do something. Your writing becomes your marketing. If people see that you can help with their problem, they are more likely to reach out! The demand for technical writers in the Web3 space is huge right now!

But I digress. Let’s get back to my journey with D_D.

Back to the DAO

Writing blog posts gave me something original to share with the DAO. My content would then get boosted by the D_D Twitter account, helping me reach more people and acquire new followers with every post.

However, it still felt like I wasn’t doing much in the DAO. I was attending Town Halls and voting on snapshots, but still searching for a way to get more involved.

Then Season 0 started, and guilds became a thing.

With specific guilds to cover different topics in the DAO, it was easier to narrow my focus. I was immediately drawn to the Writers Guild due to my interest in becoming a better writer. If you are interested in doing something, surround yourself with people already doing that thing, right?

The Writers Guild has been there to provide assistance when I feel stuck. There’s also a channel for requesting feedback on your written content.

Finally A Way to Contribute

Towards the end of November 2021, the Writers Guild announced they would create a newsletter for the DAO. Guild leader marc | wolovim.eth made a post calling for someone to help curate the highlights for the guilds, and right away, I thought this was something I might be able to do. Finally! A way I can contribute!

The only thing was... I was incredibly nervous to reply 😅

I thought about it for hours, deliberating whether I should or not. I eventually convinced myself to give it a shot. What’s the worst that could happen? If I feel overwhelmed, I could just take a step back, and someone else could pick up that task. That’s how DAOs work, isn’t it?

My reasoning was that I thought it would be an excellent opportunity to keep track of everything going on in Developer DAO. I was already browsing a lot of the channels. So why not write some of it down and share it with the rest of the DAO?!

So I replied to Marc saying I was interested, and he gave me an outline of what they were looking for. I managed to scrape together something that was acceptable and haven’t looked back since!

Confidence Through Contribution

Joining the newsletter team allowed me to narrow my focus. I was looking too broadly before, not knowing where to spend my energy. Now I have specific duties to get done weekly.

It has also made me more comfortable communicating in the DAO. Carrying out newsletter duties broke some of the hesitancy I once felt. I have no problem speaking up when others need help or if there’s a discussion I want to get involved with.

My willingness to help and activity didn’t go unnoticed either! Marc asked if I would like to be a moderator, to which I replied, “Of course!”.

With everything I’ve been helping out with, my confidence has been growing by the day. I really feel like I’m contributing to something great and that I’m actually able to make a difference by helping people in the DAO.

I’ve also tried to be more active on Twitter, helping out there when I see opportunities. Tons of people have questions about D_D!

Learn From My Example

Taking the leap and getting more involved is scary! You might feel like you don’t have anything to contribute, but trust me, you do! Developer DAO is a big place with a lot going on. Join channels on topics that interest you, and ignore the rest.

You can get a broad overview of what’s going on by subscribing to our newsletter. Once you start participating in conversations, opportunities for involvement will present themselves. Being friendly and helping others when you can goes a long way.

When you start working on a project or two, you could write about it also! The newsletter and DAO blog are always looking for more writers. So let us know what you’ve been working on! It could help others get involved too.

Wrapping Up

I’ve been writing for a couple months now and gained a few great clients, but I’m happy to announce my next big venture...

As of April 4th, 2022, I will be assuming the role of Director of Web3 Content at Dev Spotlight! They have been my best client, and when my contact offered me a position with them, there was no way I could refuse!

So long overhead crane technician, I’m going Web3 full-time baby!

Taking the leap and joining the newsletter team has taught me the benefit of getting out of my comfort zone. Being a part of Developer DAO has shown me the path I want to follow, and I’ve never felt closer to achieving my goals. I’ve also met some really great people along the way.

So if you are still hesitant about getting more involved, just know it’s not as scary as you think! Take the chance and get out of your comfort zone. It could be the best decision you ever make 😉

In this challenge, you are tasked with learning something Web3 everyday for 100 days. You should publicly announce somewhere, perhaps on Twitter, that you are attempting the challenge. Ideally, you will also post your progress often. Anything from the things you are learning, to how you are feeling about the challenge, or even just thoughts related to Web3. Just remember to use the tag #100DaysOfWeb3 somewhere in your post.

It is very similar to the #100DaysOfCoding challenge that has been popular on tech Twitter for many years. The goal is to build a habit and keep your learning consistent and accountable. You can use it to jump start your transition into the Web3 space, or just use it to build a healthy habit of learning.

What Is Web3?

Web3 is the decentralized version of the internet, aiming to return power back into the hands of everyday people, rather than the corporate megacorporations pervading the space today.

It heavily incorporates blockchain technology, so typically that is what people focus on when attempting the challenge. You may also cover other Web3 topics such as decentralized governance, DAOs (Decentralized Autonomous Organizations), Web3 gaming and micro-economies, or any number of other Web3 topics.

Why The Challenge?

If you struggle with learning something and sticking with it, it’s not necessarily about what you’re learning but more about your consistency. This challenge is to help you build a habit of logging on to your computer every day and dedicating some time towards learning a new skill. Regardless of what you want the outcome to be. Just showing up is the most important step.

Learning in public is a great way to hold yourself accountable and meet like-minded people. If you are posting your progress on Twitter, others can follow the hashtag which opens it up to the entire community. Posting often will also hopefully ease any anxiety you might have about putting yourself out there by giving you something straightforward to share every day.

How To Get Started

The first thing you should do before starting the challenge is figure out why you want to do it. Having a “why” in place will help you on the hard days when you aren’t feeling particularly motivated or things are feeling too challenging.

Your second step should be to create a Twitter account. Twitter is where almost everyone in the Web3 space hangs out so building your profile is an important step. Join the community and say hi! Some people like myself monitor the #100DaysOfWeb3 tag to say hello and offer encouragement to people on the journey. You could also do the challenge on Facebook or LinkedIn but the response will not be as impactful there.

Third, figure out where you want to start! I’ve got some resources listed below that should help you figure that out if you haven’t already.

Finally, just post your progress on Twitter from time to time. Most people post every day because it helps establish a habit of writing and putting yourself out there, but you absolutely do not have to if you don’t want to. This is your challenge! Do what works best for you! Just remember to add the number of day you are on and the #100DaysOfWeb3 tag.

ex: Day 33 / #100DaysOfWeb3

How To Succeed

This challenge is tough and not everybody will make it to the end. 100 days is a long time! Don’t be hard on yourself if you have to step back. Just know there is a whole community of us rooting for you to cross that finish line! Armed with the right attitude and some help from the community, you will be able to make it! With that in mind, here are a few tips to help you out:

• Ease into it — Going too hard right out of the gate will set your expectations too high for the rest of the challenge. There’s no need for any extra pressure.
• Take breaks — The risk of burnout in this challenge is real. If you need a day or two off here and there, that’s totally fine. We have lives outside of this challenge.
• Try not to compare yourself to other people — This is the trap of social media and is a recipe for discouragement. Everyone’s skill level and learning capabilities are different.
• Pick something and stick with it — Bouncing around from topic to topic without finishing something makes learning more difficult. There are some exceptions here but ideally you should finish that tutorial/project/whatever before starting a new one.
• Join a community — Surrounding yourself with like-minded people helps A LOT. You’ll meet some cool new friends and it provides a support group you can fall back on. It may even open up opportunities for you ;)
• Write about what you’re learning — This will help solidify concepts and could help other people on the same path as you. So start your blog (I recommend Hashnode) and put yourself out there!

Resources

Now that you know what the challenge is, here are a few resources to get you started:

General Blockchain and Crypto

• Whiteboard Crypto - https://www.youtube.com/channel/UCsYYksPHiGqXHPoHI-fm5sg
• Bitcoin Whitepaper - https://bitcoin.org/en/bitcoin-paper
• The Ethereum Network - https://ethereum.org/

Smart Contract / Dapp (Decentralized App) Development

• LearnWeb3 - https://www.learnweb3.io/
• Get Started With Ethereum Development - https://ethereum.org/en/developers/
• Get started with Solana Development - https://solana.com/news/getting-started-with-solana-development
• Crypto Zombies - https://cryptozombies.io/
• Buildspace 🦄 - https://buildspace.so/
• SpeedRunEthereum - https://speedrunethereum.com/
• 16hr Solidity, Blockchain, and Smart Contract Course - https://www.youtube.com/watch?v=M576WGiDBdQ

Front-End Development

• freeCodeCamp - https://www.freecodecamp.org/
• Traversy Media - https://www.youtube.com/c/TraversyMedia

Conclusion

There you have it! You are now armed and ready to start the 100DaysOfWeb3 challenge! Remember, take your time, take breaks, and have fun. This isn’t a competition, so be easy on yourself! Drop a comment below to let me know you’re starting, or you can tag me directly on Twitter @paul_can_code on Day 1 of your challenge. Good luck friend!

There’s no doubt, 2021 was an excellent year for Web3 users. If you were browsing crypto Twitter over the holidays, you may have noticed a lot of people talking about an SOS airdrop. Maybe you were one of the lucky ones to actually qualify for it? If you are curious about what all the fuss is about, this article is for you! We will go over what exactly an airdrop is, what they are used for, and how you might be able to qualify for one yourself. So strap on your parachutes, let’s jump into it!

So What The Heck Is An Airdrop Anyway?

Web3 is full of innovative new technology and people are getting rewarded for being early adopters. Since most of these applications require you to connect your crypto wallet in order to interact with them, it is easy to find out who the users are and compensate them for embracing the tech before anyone else. This reward, usually unannounced, is called an airdrop. It refers to the old WW2 term where food and supplies were dropped by plane to soldiers on the battlefield or dropping supplies in the same manner to victims of a natural disaster.

If you suddenly notice an additional amount of tokens or a fancy new NFT in your crypto wallet and have no idea where they came from, you may have just received an airdrop. Unsolicited airdrops aren’t the only way to receive them, though.

The most common way airdrops are received is through a claiming process. A project might make an announcement that some of its users qualify for a reward based on certain criteria. In the case of the SOS token, people were rewarded as a result of how much they spent on the OpensSea NFT Marketplace. The recipients were then able to go to https://www.theopendao.com/ and initiate a claim. Some people reported being able to claim up to $500 000 literally for just using the platform.

I’m going to give $30,000 to someone who retweets this tweet because it’s the end of the year and $SOS gave me half a million dollar 🆘️! (must be following me so I can dm you if you win). ofc Will show proof! pic.twitter.com/TJDc5YrU87

— Perry Saylor (@PerrySaylor_000) December 26, 2021

The crazy part? It wasn’t even OpenSea that initiated the airdrop. The unrelated organization OpenDAO took it upon themselves to reward NFT enthusiasts, most likely as a marketing scheme.

Airdrops can also be self-initiated. A platform might clearly state that it is handing out a reward for completing certain tasks, such as signing up for a newsletter or finishing a coding tutorial. Upon completing the task, the user is compensated for their efforts.

One other notable method of collecting an airdrop is through the hardfork of a network, such as when Ethereum split into Ethereum Classic or when Bitcoin split into Bitcoin Cash. To explain a blockchain hardfork simply, it is when one network splits into two different networks. This can happen for various reasons which I won’t get into. All you need to understand is that when it does happen, holders of the token used on the original network receive the same amount of the new token that is used on the forked network.

Airdrops aren’t just for tokens though. It is very common for NFT projects to gift another NFT to the original holders. Bored Ape Yacht Club sent holders a serum NFT which, when combined with their Bored Ape, created an entirely new NFT called a Mutant Ape!

What Are Airdrops Used For?

One of the main reasons organizations are giving out airdrops to its users is simply to reward them for being the first to interact with their platforms. These early adopters are providing quality user data and feedback in the initial stages of release, as well as potentially spreading the word. What better way to reward these individuals than free stuff!? When people receive free gifts, they usually tend to talk about it, which leads to the second reason an organization might send out an airdrop..

It’s a really great marketing tactic. Almost every time an airdrop has been released it has generated a ton of buzz around it. This in turn brings about a lot of brand awareness, which usually leads to more people getting involved.

Since big platforms such as Google and Facebook have put limits to the types of crypto advertising they allow, these organizations have to find other ways to get the word out about their projects. When something goes viral, everyone wants in on a piece of the action.

Additionally, for newer projects, if they announce they will be doing an airdrop in the future, or even just hint at it, people will be lining up to try out their platform. Considering some people have received airdrops worth thousands of dollars just for being early adopters, the risk to reward ratio is very enticing.

How Do You Qualify For An Airdrop?

Although there usually aren’t many absolute guarantees that an airdrop is on the way, there are a few signs you can look for:

• If they announce it: This is obviously the easiest sign to spot. Following Web3 companies on Twitter or subscribing to their newsletters is a surefire way to get notified of an upcoming drop and what you might need to do to qualify.
• If an organization is decentralizing: One of the most common ways for decentralized autonomous organizations (DAOs) to facilitate governance is through the use of an ERC-20 token. Who better to do the governing than people actively involved in the project? Start contributing and you could get airdropped some governance tokens. You might also find you enjoy the community, make some friends, and build cool projects along the way!
• Prior airdrops: Based off previous airdrops, it’s a safe bet that users of new protocols and projects could be rewarded for their efforts. Try to go through the actions a platform might want you to take for your highest chance of qualifying. For example: Using the swap feature in your MetaMask Wallet or trading and minting NFTs with zkSync. A lot of people on crypto Twitter are speculating that new Ethereum Layer 2 protocols will be hotspots for incoming airdrops in 2022. This Bankless article lists a few potential avenues you could investigate.

Tread Carefully

With all the hype around airdrops and basically anything else related to cryptocurrency, there are tons of scams out there. Some of them can be quite sophisticated too. If you’re playing around with platforms and trying to get qualified for an airdrop, do some research before aping into it. Brand new projects are popping up every day and some of them undoubtedly have nefarious intentions.

When first looking at a project, try to find information about the founders. If they are staying anonymous and have no previous reputable work in the public domain, that’s a big red flag. How long has the project been around? What are people saying about it? If the founders are well-established with prior work under their belts, chances are pretty high it’s legit.

Also be very careful when interacting with applications that require the use of your crypto wallet. Know what transactions you are signing and NEVER give anyone your private keys. If you have to enter your private keys to receive an airdrop, it is definitely a scam. If you are still questioning the legitimacy of the airdrop, move anything of value out of your wallet before initiating the claim.

The whole point of an airdrop is to receive something for free. If you are being asked to pay a registration fee or give someone money to be qualified, they are trying to play you. The only fee you might have to pay when claiming an airdrop is the gas fees.

If a large number of folks are receiving an airdrop, try to read into how their experiences are when claiming. Don’t just blindly follow the hype hoping to make a quick buck. Twitter is an excellent source of not only finding out about airdrops, but for reading about how people are reacting to them as well.

Good Luck!

I hope this article has helped shed some light on airdrops for you. Get involved with Web3 and the potential for rewards can be great. Of course, none of what I’ve posted here should be considered financial advice. Do your own research and be safe out there.

Good luck frens! WAGMI <3

If you've written a Solidity smart contract and tested it locally, the next logical step before deploying to mainnet is to try it out on a test network. Since gas fees on mainnet can be quite high, you want to make sure everything is working as intended and optimized in an environment that simulates the real thing before spending your hard earned ETH.

In my previous article , we wrote 2 smart contracts and used an interface to test out some interaction between them. In this article, we are going to deploy both of those contracts to the Ropsten testnet and verify functionality there. Arguably, one of the easiest ways to do this is with Remix IDE. To do this though, we will need a wallet to hold our test ETH and sign the transactions involved.

If you have your own smart contract you wish to deploy to the Ropsten test network, you can still follow along! We won't be testing the contracts from my previous article until towards the end, so everything else may still be applicable for you.

What You Will Learn

• What a test network is
• How to set up a Metamask Wallet
• How to get test Ether from a faucet
• How to deploy a smart contract to the Ropsten testnet using Remix

What You Will Need

• A Metamask wallet - https://metamask.io/
• Some test Ether in that wallet (We'll go over how to get this)
• A smart contract to deploy

Resources

• MetaMask security tips - https://metamask.zendesk.com/hc/en-us/articles/360015489591-Basic-Safety-and-Security-Tips-for-Metamask
• How To Not Get Rekt: Web3 Wallet Safety - https://ryanharris.dev/posts/web3-wallet-strategy/

What Is a Test Network?

If you've been following along with my articles, so far we've only been testing on a devnet. This is a lightweight local instance of the EVM that only exists temporarily. For something that more closely resembles the actual Ethereum Virtual Machine, we'll need to use a testnet.

As mentioned above, a test network is used for trying out smart contracts before deploying them to the Ethereum Mainnet. There are a few different types but all serve the same purpose. Their differences are mainly in how they achieve consensus. Rinkeby, for example, uses the proof of authority consensus algorithm, while Ropsten uses proof of work. If you are looking to simulate an environment that is closest to Ethereum Mainnet, you'll want to go with Ropsten since in it's current version, Mainnet is using proof of work.

To participate on these networks you will still need ETH however. There are a couple of ways to acquire some but the easiest is through a web-based service called a faucet. Some networks, like Ropsten, are also built to allow for mining, so you could acquire test ETH that way. Aside from these options, you could always ask someone to send you some test ETH directly.

It's also important to note that ETH used on a test network holds no real value. Similar to all currencies, the only reason Mainnet Ether is worth anything is because the community assigns value to it. And because test Ether exists on a separate network, you wouldn't be able to bridge it over to buy your CryptoKitties.

Before we can get any of this test Ether though, we will need a wallet to store it in. For this we will use MetaMask.

How To Set Up A MetaMask Wallet

Metamask on your PC is set up as a browser extension. It is a digital crypto wallet and you can use it to store ETH and any ERC20 tokens. Having a wallet like MetaMask installed in your browser allows you to interact with Ethereum dapps.

First thing's first, let's head over to https://metamask.io/download.html. It should automatically detect which browser you are using and show it as a choice for downloading right at the top but in case it doesn't, the supported browsers are listed just below that. Either way, click on the one that best suits your needs (I am using Chrome) and it will direct you to the install page. Hit the install button to add MetaMask as a browser extension.

Once MetaMask is installed, a new tab should pop up to get you started. If it doesn't, head into your extensions and click on it directly. You should pin it to your taskbar while you're there for easier access moving forward.

Okay, once you've clicked on the extension, you should be at the "Get Started" page. If you already have a wallet, this is where you would import it. We are going to create a new wallet though, so click that "Create a Wallet" button and let's proceed. I'll leave it up to you whether you want to agree to anonymous usage data collecting or not.

Next you will be asked to make a password for your wallet. I highly suggest using a password manager - bitwarden is a free, open source one and will help you keep track of your passwords and things you are signed up for. Anyway, create a password and let's move on.

If you've never worked with a crypto currency wallet before, I recommend you watch the short video introduced on the next page. It will explain what a secret recovery phrase is and what it is used for. Your personal phrase will be revealed on the following page. NEVER SHARE THIS PHRASE WITH ANYONE. PERIOD. Not even someone at MetaMask. If someone asks you for your secret recovery phrase, they are trying to scam you. Write it down and keep it somewhere safe. See the resources section at the top for additional wallet safety tips.

After you've got your phrase written down somewhere safe, let's proceed to the next page where we are asked to confirm it. Once that's all done, we are finally in our MetaMask wallet!

The first thing we should do is create a new account. I personally like to have a separate account specifically for development stuff, that way I don't send real ETH or accidentally upload the private key for my main account to github. So click on the circle in the top right corner of your screen and let's create a new account. We are going to name this one Dev.

Awesome! You've now set up your MetaMask wallet and are ready to fill it with some test ETH!

How To Get Test ETH

In order to get some test ETH, we are going to use what is called a faucet. Most faucets are just basic web apps where you input the wallet address you would like to receive test ETH to. We will be using the faucet linked directly from the Ethereum official website. There are other faucets out there, just do some research before using them. Some will ask you to connect your wallet and sign a transaction. Just make sure you know what you are signing before you actually do. For safety's sake, I prefer to use faucets that just require an address.

Let's head over to https://faucet.ropsten.be/ and input our wallet address. Click on the MetaMask extension and copy your wallet address.

Paste it into the text field and click the "Send me test Ether" button. It may take a little while to get some ETH transferred to your wallet

If you are unable to get any ETH from the faucet mentioned above, I've had pretty good luck with this one: https://faucet.dimensions.network/.

Once we've got some test Eth for the Ropsten network, we are ready to move on.

Accessing Ropsten From Remix

Using the Remix IDE, deploying your smart contracts to a test network is relatively simple. If you've deployed locally with Remix before, the process is much the same.

If you've got your own smart contract you wish to deploy, that's great! If you would like to follow along with the testing we will be doing after deploying, you can use 2 of the smart contracts from my previous articles. The code is posted below. Feel free to deploy them locally and test them out to see how they work.

ChangeState.sol

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.7;

contract ChangeState {

    string message;

    constructor() {
        message = "Hello World!";
    }

    function setMessage(string memory newMessage) public {
        message = newMessage;
    }

    function getMessage() public view returns (string memory) {
        return message;
    }
}

Interact.sol

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.7;

interface ChangeState {
    function setMessage(string memory newMessage) external;

    function getMessage() external view returns (string memory);
}

contract Interact {
    function getMessage(address contractAddress) public view returns (string memory) {
        return ChangeState(contractAddress).getMessage();
    }

    function changeMessage(address contractAddress, string memory newMessage) public {
        ChangeState(contractAddress).setMessage(newMessage);
    }
}

Now that you've got your smart contract ready, head to the Deploy and run transactions tab in Remix. At the very top you'll see the first text field called Environment and it is most likely set on JavaScript VM (London).

Change this setting to Injected Web3 and a MetaMask notification will pop up. It is asking which account you would like to connect to the Remix IDE. Choose your Dev account and press next.

Once you are connected, Remix will automatically detect which network you are on and will display it under the Injected Web3 in the Environment text field. If it doesn't say Ropsten, head into your MetaMask wallet and click on the networks tab. Select Ropsten and now you should be good to go.

Once you you have the Ropsten Network selected, you should see the amount of test ETH you have in your account as well. It will show in your MetaMask wallet, and also in the Account text field in Remix.

Now, the moment we've all been waiting for! Let's deploy our contracts!

Deploying To The Ropsten Test Network

In the Contract selection field, choose the contract you wish to deploy. If you don't see any options there, make sure you saved your contracts and they compiled without any issues. We will do ChangeState.sol first. Select it under the Contract heading and then hit that Deploy button!

MetaMask will immediately pop up with a transaction you can either confirm or reject. It will display important information such as the gas fee and total cost the transaction will be.

If everything looks good to you, press Confirm. It will take a couple seconds but another pop up, this time from Chrome itself, will appear saying the transaction was confirmed. You can also view the transaction on Etherscan. This is proof that our smart contract is now living on the Ropsten Network!

If you weren't able to follow the link in the popup, you can still view the transaction on Etherscan. Just copy the transaction hash from the transaction receipt printed in the console beneath where you write the code in Remix and paste the value in the URL https://ropsten.etherscan.io/tx/)/YOUR_TRANSACTION_HASH_HERE

So in my case it would be: https://ropsten.etherscan.io/tx/0xd2d08ab6071f0e10ef3c17e092ba47c87b3472bda8e13a0429f6cc8bf4ea3124

Repeat the process for the Interact.sol contract. Again, the transaction will take a little time because it actually needs to be mined and confirmed on the Ropsten Network, just how it would be with Ethereum Mainnet.

You should now see both contracts under the Deployed Contracts section in Remix. That means they are ready to test!

Testing Our Smart Contracts

Nothing really changes in regards to the way we test the functions on our contract now that it is on Ropsten. As such, we will be following the same testing procedures as my last article.

1. First, let's check that the contract was initialized with the correct value of the message variable. On the ChangeState.sol contract, click the getMessage button and it should return the value Hello World!

2. Next we'll make sure the Interact.sol contract is retrieving the correct value from our ChangeState.sol contract. Copy the address for the ChangeState.sol contract and paste it into the getMessage field on the Interact.sol contract. Click the getMessage button and it should also return with a value of Hello World!

   

3. So far so good! Next, we will test out the changeMessage function on the Interact.sol contract. Copy the same address as the previous step into the changeMessage field followed by a comma. After the comma, insert whatever message you want to change it to.

   Once you click the button to operate the function, MetaMask should pop up with another transaction to approve or reject. Once it is approved on the Ropsten Network you will be able to view the transaction on etherscan using the same method as above.

   

Congratulations! You just utilized the Ropsten test network to change the state of another smart contract! Feels pretty cool, doesn't it? For some extra fun, you can enter the address for the contract I uploaded and interact with that one! Be warned though, I don't have any filters set up and won't be actively monitoring the message so it could be anything, even swear words!!!!

Here's the address for my contract: 0xa67CD790Bf3A0358155DAE55e2232601D57Fef39

Finishing Up

Thank you for taking the time to read my article! I hope it has helped you with getting a MetaMask wallet set up and deploying contracts on a testnet. Also, if you have followed along with this series from the beginning, congrats! You should now have an understanding of some of the important basic concepts of a Solidity smart contract and are now ready to move on to more complicated things.

In this article we will be exploring the concept of composability using interfaces in Solidity smart contracts. Although there are other ways to achieve this, such as inheriting from abstract contracts, interfaces are well suited for simple tasks. We'll interact with the functions of one contract from a completely different contract! If that sounds exciting to you then let's get into it!

What You Will Learn

• How to use an interface to interact with another smart contract

What You Will Need

• An idea of how functions work in Solidity
• Basic familiarity with the online IDE Remix - https://remix.ethereum.org/

Resources

• A great article on Composability by Packy McCormick - https://www.notboring.co/p/idea-legos

Let's Get Started

If you followed along with my last article, you will be able to re-use the smart contract we wrote. We are just going to add a little something for initializing the message variable.

For those of you who didn't read my last article, it's a pretty simple contract. Head over to https://remix.ethereum.org and write the following code into a new file named ChangeState.sol.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.7;

contract ChangeState {
    string message;

    constructor() {
        message = "Hello World!";
    }

    function setMessage(string memory newMessage) public {
        message = newMessage;
    }

    function getMessage() public view returns (string memory) {
        return message;
    }
}

What we added to the contract below our declaration of the message state variable and above the declaration of the setMessage function, is called a constructor. It's an optional function that is only executed once when the contract is deployed and is used to initialize contract state. In this case we are initializing our message variable with the value of Hello World!. If there is no constructor defined, a default one will be created behind the scenes upon deployment.

Try deploying the contract and pressing the button for the getMessagefunction. If you aren't sure how to do this, refer to my previous article! You'll notice that before we even do anything, the value of our message variable is already Hello World! Sweet!

Now that we've got a working ChangeState contract, let's make a new contract to interact with it!

Implementing The Interface

We could just create a new contract underneath the ChangeState contract on the same file, but to emphasize that we are actually interacting from a separate contract, let's create a new file.

1. Open up the File Explorers tab and create a new file. We'll name this one Interact.sol.

2. Write the following code in your new contract file:

    // SPDX-License-Identifier: UNLICENSED
    pragma solidity ^0.8.7;
   
    interface ChangeState {
        function setMessage(string memory newMessage) external;
   
        function getMessage() external view returns (string memory);
    }
   
    contract Interact {
        function getMessage(address contractAddress) public view returns (string memory) {
            return ChangeState(contractAddress).getMessage();
        }
   
        function changeMessage(address contractAddress, string memory newMessage) public {
            ChangeState(contractAddress).setMessage(newMessage);
        }  
    }
   

   Before we declare our contract, we are introducing something called an interface. This is what we will be using to interact with our ChangeState.sol contract and, in this case, what facilitates composability. It is best practice to declare interfaces in between pragma statements and contracts.

   You'll also notice we have two of the functions from our ChangeState.sol contract in the interface and that both are declared as external. With an interface, we only need to state the functions we want to interact with. The external access modifier is required to convey that the functions will only be called from outside of the interface. More information on interfaces can be found in the Solidity Docs.

   Inside our Interact.sol contract, you'll notice that we pass an address argument into both of the functions. This is the address of the smart contract deployed on the blockchain whos functions we wish to use. So in our case, we would deploy our original ChangeState.sol contract, get the address it was deployed to and then pass that as an argument for the functions in our Interact.sol contract.

   Then in the lines with ChangeState(contractAddress).{name_of_function}() we are using the functions of our other contract.

   Cool! Now that we understand what it's supposed to do, let's test it out locally in Remix and make sure it works!

Testing Locally

1. Let's save our Interact.sol contract and then deploy it. We should now have two contracts deployed, ChangeState.sol and Interact.sol.
2. First, let's read the value of our message variable in the ChangeState.sol contract. Click on the getMessage button in that contract and it should display Hello World! which is what we initialized that variable to.

3. Next let's grab the value of that same variable but this time from our Interact.sol contract. To do this we will need to get the address that our ChangeState.sol contract was deployed to. Next to the name of the deployed contract, you will see an icon to copy the value to the clipboard. Copy that address and paste it into the text field next to the getMessage function in our Interact contract. Hit the button and it will display the value for us.

   

4. Let's do a quick test again before we move on. Use the setMessage function in our ChangeState.sol contract to change our message variable to something new. Press the getMessage button from our Interact.sol contract again and you will see that it displays the new value! So cool!

5. Now let's test that changeMessage function in our Interact.sol contract! Paste the ChangeState.sol contract address you copied in step 6. into the text field followed by a comma. Then input whatever you want to change the message variable to. Don't worry if you forgot to wrap your text in quotation marks. Remix knows that argument is supposed to be a string so adds them automatically on the backend if you didn't.
6. Now for the moment of truth! Click on the getMessage button for either contract (or both!) and witness the magic. The message variable's value has been changed from a completely different contract! How cool is that?!

Finishing Up

You know what would be even cooler? Deploying these contracts to test network so we can see how it works in an environment that simulates the actual Ethereum Virtual Machine! If that's something that interests you, keep your eyes peeled for my next article or even better, hit that subscribe button!

Thanks for taking the time to read my article. Hopefully you now have a better understanding of how we can implement an interface in one smart contract to use the functions in another. Any questions or comments, feel free to drop them below!

The Ethereum Blockchain however is more advanced than this. It can store blocks of code called smart contracts and through the Ethereum Virtual Machine (EVM) can execute the code stored in these contracts. This effectively allows for the modification of the EVM's state from block to block. Due to the immutability aspect, the previous state is still in the records of the blockchain, albeit in the form of hexadecimal hashes instead of human-readable text.

In this article we will write a simple smart contract with a function we can use to change its state. Before we get into coding though, it is important to understand a few concepts around contract state and transactions.

What You Will Learn

• What state and state variables are in Solidity
• Transactions and changing the state of a state variable
• General information about variables in Solidity

What You Will Need

• Basic knowledge of smart contracts — You can get caught up here → https://blog.paulmcaviney.ca/hello-world

Resources

• Blockchain for beginners → https://101blockchains.com/blockchain-for-beginners/
• The Ethereum Virtual Machine → https://ethereum.org/en/developers/docs/evm/
• Solidity Style Guide → https://docs.soliditylang.org/en/v0.8.9/style-guide.html

Why Does State Matter?

The internet as we know it today is stateless. State refers to information. Since there isn't a native mechanism for keeping track of or changing state built into the current internet, We rely on centralized authorities to act as intermediaries for the transfer of value and maintaining state.

Workarounds such as cookies have been implemented, but they are created by companies who may not have the best intentions when it comes to your data. It often leads to the mishandling of user data and can also be an enticing target for hackers looking for credit card information.

The ability to track and maintain state on Ethereum takes the power out of these institution's hands and gives it back to the people. State of the network is then collectively maintained. We no longer need to rely on these companies to settle payments or keep track of our sessions online.

So What Is State in Solidity?

This just refers to the data being stored on the blockchain at a particular block. There are two types of data that can be stored on the Ethereum Blockchain: permanent data and ephemeral data.

Once permanent data is stored, you guessed it, it's permanent. It can't be modified or deleted. An example of this would be a transaction hash. The simplest transaction would be sending ETH from one account to another and would include information such as the recipient, the amount of ETH sent, and a signature to identify the sender. This data is then hashed and stored on the blockchain.

Ephemeral data refers to information that could change from block to block, such as the balance of a particular account or the value of a variable stored inside a smart contract.

State Variables

There are three types of variables in the Solidity coding language:

• Local Variables - A temporary value that is declared inside of a function, cannot be accessed outside and is only present until that function is finished executing.
• Global Variables - Special variables that hold information about transactions and blockchain properties (eg: msg.sender, tx.origin).
• State Variables - Values that are permanently stored in contract storage and hold data related to the contract state.

Through the manipulation of state variables, we can effectively change the data being stored in a smart contract. State variables are declared inside contract scope and outside of function scope, meaning they would be one of your first declarations in a contract before declaring functions.

Transactions

In order to change the value of a state variable, you need to send a transaction. Although reading the value of this variable is free, it will cost a gas fee to send the transaction to change it. I won't go into what gas fees are in this post, but it is important to note that any transaction that changes the state of the Ethereum Virtual Machine will cost some amount of ETH.

There are also many factors that go into the calculation of gas fees such as the variable type, its size and even the order it is declared in relation to other variables. If you are deploying smart contracts onto Ethereum mainnet, gas fee optimization will play an important role. To learn more about gas fees check out the Ethereum Docs.

Now that you've got a basic understanding of what state is in Solidity and what it takes to change it, let's write our own smart contract to see it in action!

The Code

I'm going to assume you know the basic structure of a Solidity smart contract, so I won't be explaining anything pertaining to that. If you need to get caught up, you can do so here → https://blog.paulmcaviney.ca/hello-world

1. Head over to https://remix.ethereum.org/
2. Click on the Create New File button and let's name our new file ChangeState.sol

3. Enter the following code:

   // SPDX-License-Identifier: UNLICENSED
   pragma solidity ^0.8.7;
   
   contract ChangeState {
   
     string message;
   
     function setMessage(string memory newMessage) public {
         message = newMessage;
     }
   
     function getMessage() public view returns (string memory) {
         return message;
     }
   
   }
   

   • The line string message; is declaring the state variable that will be saved in contract storage.

   • The function setMessage() allows us to change the value of message and is set to public so any one can access it.

   • The function getMessage() is a getter function that returns whatever the value of message is at the time it is called. You should be aware that if you were to declare the state variable message as public, Solidity automatically creates a getter function with the same name. I just wrote it out like this for the sake of clarity. It would look like string public message; otherwise.

   Alright, so now we have this fancy bit of code and understand what it's supposed to do, let's test it out and see if it actually works!

   ---

   Testing The Code

4. Hit ctrl+s to save and compile the code. If all goes well, you should have a little green checkmark next to the Solidity compiler icon on the left side navigation bar. If there was an issue, the line number with the issue will be highlighted red and hovering over it will give you an idea of what the error might be.

5. Click on the Deploy & run transactions icon. You should then see the name of our contract ChangeState - ChangeState.sol underneath the Contract heading and directly underneath that there will be an orange Deploy button.

6. Click on the orange Deploy button and our contract should appear under the Deployed Contracts heading at the bottom. If you click on the little arrow beside CHANGESTATE it will reveal buttons for the two functions in our smart contract - setMessage and getMessage. These are the buttons that will allow us to test if everything is working properly.

   

   Remix does something cool here. Notice how the two function buttons are different colors? The orange setMessage button represents a transaction that is not payable. This means the function does not transfer ETH from one account to another, just the gas fees associated with the transaction. Transactions that are payable will appear as red. They will transfer ETH and also cost gas fees. The blue getMessage button represents a call function, meaning it is just trying to read some data from a contract.

   So just remember, orange and red buttons mean it costs gas, blue means it does not. Hovering over the buttons will display this as well.

   Now let's actually test these functions and see what's going on.

7. First, click on the getMessage button and it will reveal the default value for our message state variable. This will display 0: string: underneath the button, meaning it just returned an empty string.

   • Side Note - Each declared variable will have a default value based on its type - there is no concept of undefined or null in Solidity.

8. Next let's test the setMessage button. Enter in a new message in the text input that you'd like to assign to our message state variable. After clicking the button, you will notice that some new information was added in the console, which is located right underneath where we wrote our smart contract code. Click on the arrow beside the Debug button and let's check out what it says.

   

   Remember how in order to change the value of our state variable we need to send a transaction? This new message in the console is what's called a transaction receipt. It contains information about where the transaction came from, where it was going to and the amount of gas it cost. Interacting with any function that costs gas will produce a transaction receipt.

   More on transaction receipts → https://medium.com/remix-ide/the-anatomy-of-a-transaction-receipt-d935aacc9fcd

9. The last step in testing our contract is clicking on the getMessage button one more time. This time, you will see that the message was updated to whatever you set the message as! It read the value of the message variable from its location in contract storage on the blockchain and displayed it for you to see in all its glory!

   

   Since we are accessing the value of our state variable through a function in our own smart contract, you might not see the significance here. To really get an idea of how awesome this is we should deploy our contract to a testnet and interact with it there through another contract! This will be the subject of my next article.

More On Variables

Before I conclude this article, I want to leave you with some of the basic rules associated with variables:

• Variable scope can be defined to control who can use them
  • Public - anyone can get the value of this variable
  • External - only external functions can get the value - not used on state variables
  • Internal - only functions in this contract and related contracts can get the values of these variables
  • Private - can only be accessed by functions from the current contract
• Variable names are case sensitive.
• There are reserved keywords you should not use as variable names
• Solidity variables can't start with a number, they should start with a letter or an underscore.
• Solidity is a statically typed language, meaning the variable types need to be specified when declaring them

Conclusion

One of the greatest aspects of the Ethereum Blockchain is its ability to manage state through the EVM. You were able to successfully create a state variable, update its value which is placed in contract storage on the blockchain and retrieve that value. You should now have a basic understanding of how this is accomplished through the use of state variables and transactions. Congratulations! You are one step closer to mastering the fundamentals of Solidity!

Thanks for taking the time to read this article! I hope it helped you learn a little more about how Solidity works. If you would like me to write an article about a specific topic related to Solidity or Web3 in general, drop a comment or hit me up on Twitter!