At Infura, we believe testnet ETH should be free and easily accessible.

As an Ethereum developer, you know how important it is to test your dapps before deploying them to the mainnet. However, testing can be challenging when you need to acquire Sepolia testnet ETH to fund your smart contracts and there’s nowhere to turn.

Aligned with Infura’s mission of making building in web3 easy and accessible to everyone, we're releasing Infura’s new Ethereum testnet faucet that drips 0.5 ETH daily requests.


Why we created the Infura testnet faucet


At Infura, we believe testnet ETH should be free and easily accessible. Recent shortages of testnet ETH have caused significant problems for developers, who have had to purchase GoETH on the open market.

The monetization of GoETH led to speculators driving the price to $1.61 per token, and one user even purchased a Cryptopunk using funds from GoETH transactions.

Because testnet ETH should be free and easily accessible, the Ethereum Foundation is shutting down Goerli testnet and requesting that developers migrate to the Sepolia Testnet.

Infura's new testnet faucet is here to help the ecosystem by providing a reliable, high-volume drip of Sepolia ETH. Facilitating web3 development QA procedures on a test network is critical to the future of blockchain implementation at the protocol level. Access to a stable, high-volume faucet will make web3 development easier for developers.

With this faucet, you can request free testnet ether with just a few clicks. Want to see for yourself?

Here’s how.


How to use the Infura testnet faucet


To use the Infura testnet faucet, follow these simple steps:

First, to go: https://www.infura.io/faucet/sepolia.  

Then enter your Ethereum address into the open field. (More detailed steps to do this are here: How to get your Sepolia Wallet address on MetaMask)

Next, click the login button to access your Infura account.

Click "Receive ETH" and wait for the transaction to be processed. You can follow the Etherscan link for transaction verification.

Check your MetaMask wallet to confirm you’ve received your testnet ETH. You can do this on the Sepolia network. (Reminder: Secure your MetaMask wallet)



It's that easy! You can request testnet ETH as often as you need to, but please be aware of the 0.5 ETH daily limit.


Keep learning with Infura


Congratulations! Now you have the ETH you need to test your dapp, publishing a few smart contracts, and even mint some NFTs. Below are a few helpful resources to keep learning with Infura:

 * Getting Started with Infura
 * The Developer’s Guide to the Web3 Stack
 * Get started with using Infura’s NFT API + SDK
 * Read our Infura NFT API Documentation for more ideas
 * Deploy a Smart Contract on Sepolia Testnet and test it out!


Frequently Asked Questions


Q: Can I receive more testnet ETH?

A: The current limit is 0.5 testnet ETH per day, but this could change later.

We may increase testnet ETH rewards for engaging with Infura in the future. Open emails and follow us on Twitter to get the latest updates on test ETH withdrawal limits!

Q: Will you support upcoming testnets like Holesky?

A: We're working closely with the Ethereum Foundation on launching and providing services to additional testing and development in the Ethereum ecosystem. The upcoming Shanghai / Capella upgrade is in scope with upcoming iterations of the feature.

Q: What other features can we expect in the future?

A:  With the recent acquisition of Hal by ConsenSys, we plan to implement an example monitoring service to notify users when transactions are  fully processed. We already use Hal for internal monitoring of transaction processing for manual retries.

Additional FAQs are answered directly on the faucet site.

We hope the new Infura testnet faucet makes your developer experience easier and more pleasant so you can keep shipping your innovations and building the future of web3.

Infura product updates and feature announcements.

Infura Product & Features

Product & Features

Introducing Infura’s ETH testnet faucet: Get 0.5 ETH daily to test your dapps!

The Developer’s Guide to the Web3 Stack

Infura’s NFT API + SDK are packed with all the tooling you need to mint your innovations with ease.

Have you ever wanted to create something beautiful with a few lines of code? What if with just three lines of code you could build an NFT marketplace? Or mint digital art? With the announcement of Infura's NFT API + SDK general release today, you can! It’s never been easier to mint any-NFT-thing you want.  

Over the past several months, the Infura team has been hard at work to create the best NFT tooling possible. It was only June of last year when we started the private beta with a handful of developers, using a handful of endpoints that connected to Ethereum and Polygon.

“ConsenSys products have powered the NFT experience since the very beginning, with a significant volume of NFT transactions in the ecosystem passing through the MetaMask wallet backed by web3’s strongest infrastructure from Infura. Since the limited beta release of our NFT API and SDKs in June 2022, our team has made significant strides in making the NFT toolkit the best tooling builders need to bring their NFT innovation to the world,” said Rob Dawson, Chief Technology Officer, ConsenSys Software.

Today, the Infura NFT API comes with 14 endpoints so developers have access to all the metadata they need for building. The NFT API also includes read and write capabilities from eight blockchain networks, in four languages, with integrated IPFS access.

“With the general availability of the Infura NFT API, we are focused on helping even more developers capture the huge demand of the NFT market and accelerate their building journey with instant access to cross-chain data, pre-built templates, and the ability to mint NFT collections to 8 networks in one integrated product,” Rob added.

Today we want to thank you the 500 participants who took part in our beta programs and gave us such valuable feedback that has allowed us to build the NFT API + SDK we believe will empower creators.

Let’s learn more.


The Infura NFT API + SDK offers superior security with ConsenSys Diligence


While other RPC-providers might have similar endpoint offerings, Infura’s NFT API + SDK is a clear choice for creators and developers who value the safety of their smart contracts.

The Infura NFT SDK comes with three ERC-721 and ERC-1155  templates that cover more than 85% of all NFT use cases. Each template has been pre-audited by leading blockchain security platform, ConsenSys Diligence. This means these templates are not only easily customized with metadata to create and mint NFTs in minutes, but also provide top security.

Being pre-audited means Infura’s NFT templates have been run through Diligence’s smart contract security software, Diligence Fuzzing.

The fuzzing tool battle tests contracts by attacking them with millions of scenarios over and over again until the contract is deemed error-free. The blockchain is immutable and immutable means forever. Why risk your IP using anything else?


The Infura NFT API + SDK offers multi-chain options and compatibility


Infura is an industry leader when it comes to multi-chain compatibility with RPC endpoints to 14 networks. When it comes to the NFT API, 14 endpoints with read/write capability are supported across 8 networks.

This includes early access to the new zkEVM launched by ConsenSys that’s scheduled to be available to the general public in April. Its zero knowledge-rollup technology will reduce blocktimes, latency, and gas fees–significant for NFT dapps.


The Infura NFT API + SDK offers accelerated development with the ConsenSys product suite


Developers using the Infura NFT API can take advantage of accelerated development for their NFT innovations with easy integration to the ConsenSys product suite. Add Infura, Diligence, ConsenSys zkEVM, and MetaMask to your tooling to take your NFT project to the next level.

Developers and creators can use the Truffle Suite to build an NFT dapp, spin up a dev environment to test for free, then check the Truffle dashboard for results and predict gas fees.

Next, download the MetaMask Unity SDK to use the wallet as a login authenticator and automatically connect users and their wallets to your NFT dapp or blockchain game.


Hear what devs using the Infura NFT API + SDK are saying


"Infura’s NFT API removed all the legwork to provide NFT capabilities for our web3 gaming platform. We no longer have to analyze every smart contract on-chain to determine whether they are NFTs or store NFT data and metadata. Using the Infura NFT API means we don't need to worry about scaling our database to account for increased traffic of our wallet application. Infura does it all for us." - Jay Chung, Global Business Development at Intella X / Neowiz

“Infura’s NFT API and SDK helped us very quickly build a dashboard and advanced filtering system for our users by leveraging the high-level API. We did not need to parse a long list of blockchain transactions ourselves to display meaningful information. And compared to some concurrent providers, we’ve never had any issues with the API stability and the rate limiting. Plus, the first tier of pricing helped us grow in our first months without being too expensive.” - Louis Pinsard, Co-Founder & CTO at Dialog


The Infura NFT API + SDK is only getting better


While we believe the Infura NFT API + SDK are built to empower NFT creators today we’re certainly not finished making it the best tooling on the market. Here’s what to expect from the product roadmap:  

 * Six more Diligence-secured NFT smart contracts
   
 * Expansion of the read function, making it even easier for developers to extract, manipulate, and report on metadata.
   
 * Low code and no code offerings for those non-technical creators to ensure every kind of builder can participate in the NFT creator economy.


Get started today


Check out the below demo for step-by-step instructions to get started using the Infura NFT API + SDK today.



The Infura NFT API + SDK is now available for all Infura users. Don’t have any Infura account to use the NFT tooling?

No problem. You can create an account in just three steps for free on infura.io/register.

Happy minting!

Empowering creators with the Infura NFT API + SDK

Ethereum Network Updates, Upgrades, Hard Forks

Infura - Ethereum Network Updates

Network

How To Choose The Right Blockchain For Your Next Dapp

Blockchain development can be complex. And no wonder—when working within a decentralized system operating on a set of complex protocols there are many factors you need to consider. Even for even the simplest of activities, you need to access blockchain nodes, check gas prices, pay for gas, sign transactions, and more.

Infura is a powerful suite of APIs and developer tools that abstracts away these complexities on the most popular blockchains, including Ethereum, Linea, Arbitrum, StarkNet, IPFS, and more. By using Infura, you can spend more time building your dapp, and less time worrying about details such as scalability and uptime.

This guide provides all the steps necessary to set up and get started using Infura. You’ll be able to set up an Infura API key, access the Ethereum (Sepolia) blockchain, and use Infura to build your dapp. By the end of this guide, you’ll see why leading dapps and tools such as MetaMask, Uniswap, and MakerDAO rely on the reliability, ease of use, and scale of Infura to power their ventures.


Prerequisites

To get started, you’ll need a one-time setup of some tools and software essential to creating and deploying your dapp.


Set up MetaMask

First, in order to conduct transactions on a blockchain (for example, deploying a contract or minting an NFT), you’ll need a crypto wallet.

Several options for wallets are available in the market, but we’ll use the most popular and easy to use, MetaMask. MetaMask is a self-custodial wallet that gives users full control over their crypto and transaction authorizations. MetaMask is available for free as a browser extension.

Once you install the extension, MetaMask will ask you to complete a series of simple steps to set up a wallet for you. In the process, you’ll receive a secret phrase for accessing and managing your wallet. Make sure you store this secret phase safely (ideally both in a digital and physical space), and never share this publicly. If someone learns your secret phrase, they can then steal the assets in your wallet. We recommend creating a separate wallet address for development purposes, where your valuable assets wont be stored.


Switch to the Sepolia test network

Once your wallet is set up, navigate to the top-right of the wallet window and click on Show/Hide Test Networks. After showing test networks, you’ll see the drop-down option for Sepolia. Switch your network from Ethereum mainnet to Sepolia test network.

If this is your first time using a wallet, you should see a balance of 0 SepoliaETH. We’ll fund this wallet in a later step.


Node.js and npm

We’ll use Truffle to create the foundation of your project. Truffle is an industry-leading Ethereum development environment that allows you to create, test, and deploy smart contracts to EVM-based blockchains.

To use Truffle, you need to first install Node.js and npm. You can install both on your local machine by following these instructions.

You can verify their successful installations using the command line. (Your version numbers might be different from what’s shown below.)

$ node -v

v16.13.0

$ npm -v

9.1.1


Step #1: Obtain an Infura API key

As mentioned earlier, Infura is a tool that gives you easy, fast, and reliable access to most major public blockchains and L2s, including Ethereum. Infura does this by giving you access to RPC endpoints. Think of RPC endpoints as API endpoints to which you can send requests. In order to access these endpoints, you’ll need an Infura API key.


Create an account

To get an API key, you’ll first need to sign up for an Infura account that is free. Once you’ve signed up, you’ll be taken to the dashboard. This dashboard allows you to complete a variety of tasks, such as:

 * Create new API Keys
 * View analytics
 * Access support and other helpful resources
 * Setup project security
 * Upgrade your plan and activate add-on networks
 * Get network endpoints for mainnet and testnets
 * And more


Create API key

From the dashboard, click Create New API Key. This will open a pop-up form. For network, choose Web3 API. You can name the project anything you want.



Once you click Create, Infura will create a new API key for you and redirect you to the key’s dashboard page. Navigate to the Endpoints page for your key. project.

On this page, you’ll see all the RPC endpoints that you can access. Under Ethereum endpoints, select the endpoint for Sepolia. The endpoint should be of the format https://sepolia.infura.io/v3/[YOUR API KEY].


After this step, we recommend that you add your own RPC endpoint to MetaMask by adding a new customer network. This will allow you to track your MetaMask requests directly from the Infura dashboard and understand what is happening in the backend when you send transactions from your MetaMask wallet.


Step #2: Set up your development environment

With a MetaMask wallet and an Infura RPC endpoint in hand, you can begin setting up your development environment using Truffle.


Initialize a Node.js project

First, let’s set up a Node project and install all necessary packages. Create an empty Node repository by running the following commands:

$ mkdir infura-project && cd infura-project

$ npm init -y

Next, install Truffle:

$ npm -g install truffle

Remember that we installed MetaMask so that we could pay for transactions conducted on the blockchain. You’ll need to give Truffle access to your wallet so it can perform that action on your behalf. For this, you’ll need another package: hdwallet-provider.

$ npm install @truffle/hdwallet-provider

You’ll be sharing your wallet secret phrase with your Truffle project. Under no circumstance do we want these secrets to ever be made public. You should never hard-code your secret phrase or credentials into your project. Instead, provide them through environment variables.

We’ll use dotenv  and gitignore to do this. This prevents you from being committed to version control systems and reduces the risk of accidental exposure when sharing code repositories like GitHub.

$ npm install dotenv

Touch .env 

Add your project keys here, and wallet address.

touch .gitignore

Next, add “.env” to make sure GitHub doesn’t include the file containing your keys publicly.


Create a Truffle project

Now, we can create a barebones Truffle project. Run the following command from within your Node.js project root folder:

$ npx truffle init

To ensure that everything works correctly, run the following command:

$ npx truffle test


Compiling your contracts...

===========================

> Everything is up to date, there is nothing to compile.

✓ Downloading compiler. Attempt #1.


  0 passing (1ms)

If you don’t receive any errors, you can proceed with your project. If you have any issues, check out the Truffle support and help page.

In your project, you should now see a contracts subfolder. Within this folder, let’s create an extremely simple smart contract in a file called Donations.sol. This contract does the following:

 1. Allow anyone to make a donation.
 2. Allow the owner of the contract to withdraw all the donations made.

The code Donations.sol should look like this:

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

contract Donations {
  address public owner;

  constructor() {
    owner = msg.sender;
  }

  // Function to donate
  function donate() public payable {
    require(msg.value > 0, "Donation needs to be a positive value");
  }

  // Withdraw ether
  function withdraw() public payable {
    require(msg.sender == owner, "Only the owner can withdraw!");

    uint balance = address(this).balance;
    require(balance > 0, "No ether left to withdraw");

    (bool success, ) = (msg.sender).call{value: balance}("");
    require(success, "Transfer failed.");
  }
}

Compile the contract with the following command:

$ npx truffle compile


Compiling your contracts...

===========================

> Compiling ./contracts/Donations.sol

> Artifacts written to /home/user/infura-project/build/contracts

> Compiled successfully using:

   - solc: 0.8.20+commit.a1b79de6.Emscripten.clang


Configure Truffle and environment variables

Next, we’ll need a file to store our environment variables. This is where we’ll put your project secrets—namely, your MetaMask wallet secret phrase and the Sepolia RPC endpoint which contains your Infura API key.

In your project root folder, create a file called .env with the following information:

INFURA_ENDPOINT = "https://sepolia.infura.io/v3/<Your-API-Key>"

MNEMONIC = "<Your-MetaMask-Secret-Recovery-Phrase>"

Next, let’s inject this information and configure your Truffle project. Replace the contents of truffle.config.js with the following:

require('dotenv').config();

const HDWalletProvider = require('@truffle/hdwallet-provider');

const { INFURA_ENDPOINT, MNEMONIC } = process.env;


module.exports = {

  networks: {

    development: {

      host: "127.0.0.1",

      port: 8545,

      network_id: "*"

    },

    sepolia: {

      provider: () => new HDWalletProvider(MNEMONIC, INFURA_ENDPOINT),

      network_id: '11155111',

    },

  },

  compilers: {

    solc: {

      version: "0.8.19",

    }

  }

};


Step #3: Deploy your smart contract to Sepolia

Now that we’ve configured our Truffle project and written the smart contract, we can deploy it to the Sepolia blockchain.


Use the Infura faucet to get some test SepoliaETH

Although we’ve set up your MetaMask wallet and configured it to use the Sepolia network, your wallet balance is still 0 SepoliaETH. In order to conduct any transactions—such as deploying your contract, making donations, and even retrieving donations—you’ll be required to pay gas. So, you’ll need some SepoliaETH in your wallet.

Since we’re deploying our contract to a test network (Sepolia), you can obtain these tokens for free through the Infura Sepolia faucet.

Once you’ve filled up your wallet, you should see a small SepoliaETH balance.



Deploy smart contract to Sepolia

In order to deploy your contract to Sepolia, we’ll write a script called 1_deploy_contract.js. Create the file in the migrations folder and paste in the following code:

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


module.exports = async function (deployer) {

    try {

        // Deploy the Donations contract

        await deployer.deploy(Donations);


        // Get the deployed instance

        const donationsInstance = await Donations.deployed();


        console.log("Donations contract deployed at:", donationsInstance.address);

    } catch (error) {

        console.error("Error deploying the contract:", error);

    }

};

Then, deploy the smart contract:

$ npx truffle migrate --network sepolia

If all goes well, you should see output that looks something like this:

Compiling your contracts...

===========================

> Everything is up to date, there is nothing to compile.



Migrations dry-run (simulation)

===============================

> Network name:    'sepolia-fork'

> Network id:      11155111

> Block gas limit: 30000000 (0x1c9c380)


…


Starting migrations...

======================

> Network name:    'sepolia'

> Network id:      11155111

> Block gas limit: 30000000 (0x1c9c380)



1_deploy_contract.js

====================


   Deploying 'Donations'

   ---------------------

   > transaction hash:    0xab4650f9fb25379fcb7d95e18c42f3235069566da2cb75d5f654e7b9a5100f3b

   > Blocks: 0            Seconds: 20

   > contract address:    0xb658FB9c330381a059e8A14363F71fb7D4648f2A

   > block number:        3558024

   > block timestamp:     1685040444

   > account:             0x147A4cb54D7181222B7E10a91A492d5b4892b4aC

   > balance:             0.499121902496838849

   > gas used:            351239 (0x55c07)

   > gas price:           2.500000009 gwei

   > value sent:          0 ETH

   > total cost:          0.000878097503161151 ETH


Donations contract deployed at: 0xb658FB9c330381a059e8A14363F71fb7D4648f2A

   > Saving artifacts

   -------------------------------------

   > Total cost:     0.000878097503161151 ETH


Summary

=======

> Total deployments:   1

> Final cost:          0.000878097503161151 ETH


Congratulations! Your contract is now live! You can double-check this by searching for your contract address on Sepolia Etherscan.

You can also verify your contract on Etherscan by uploading the source code, which Etherscan will match and compare against the code on the blockchain. On the Etherscan page, click the Contract tab and then click Verify and Publish.

After this verification is complete, you’ll see the green check mark over the Contract tab.


Step #4: Send a transaction using MetaMask

Now let’s donate a small amount (0.001 ETH) to this contract. Navigate to the Contract tab and then to the Write Contract tab. Click on Connect to Web3.

This will open a modal to prompt you to connect to a wallet. Select your MetaMask wallet.

Once your wallet is connected, you can click donate. Enter an amount to donate (0.001), and then click Write.

Your MetaMask wallet will pop up, and you’ll be asked to confirm this transaction. Click Confirm.



After you’ve confirmed the transaction, you can view the transaction details. The list of transactions for the smart contract also shows the recent transaction.


And that’s it! With just a few clicks, you were able to make a donation through MetaMask on your smart contract. Every single step in the process was powered by Infura.


Step #5: Track smart contract activity on the Infura dashboard

To see the work done by Infura under the hood, you can check out the analytics associated with our Infura project. Navigate to the main Infura dashboard, find your project, and click View Stats.

If this is a project that you’ve just created, change the timeline to Last 1 Hour.

You will be able to see the number of requests made during that window.

You should also be able to see the specific requests made to the Sepolia Ethereum blockchain. On the surface, you’ve only made a few clicks, but hundreds of requests have been propagated to make what we wanted to do possible.

To also see your MetaMask transactions, you will need to update your MetaMask RPC endpoint by switching from the default MetaMask RPC to your Infura one.


Step #6: Start building

Infura simplifies your job as a blockchain developer by allowing you to connect to different blockchain networks without having to run your own nodes. This takes care of the scalability, uptime, and the reliability of your dapp so you can focus on the core logic of your business or product.

Now that you’re set up, let’s start building with the following resources:

 * How to Choose the Right Blockchain for your Application
 * The Developer’s Guide to the Web3 Stack
 * Full Stack Frontend using IPFS
 * Infura NFT API + SDK
 * Infura Help Center
 * Infura Discord

Stay up to update on all Infura product releases and news by following us on Twitter.

Infura product tips and Web3 tutorials for developers building decentralized applications.

Infura Developer Tutorials

Tutorials

Getting Started With Infura

So, why would you need a hybrid infrastructure model alongside Infura?

Let’s think about how your database is set up. You probably have your own database, which is great. What happens if that database goes down? Would your app continue to run seamlessly, delivering the experience you want your customers to get? Or, would your database shutdown cause outages and crashes in your app?

If the dataset you’re hosting is a public dataset, you have a new paradigm for making your infrastructure much more resilient and reliable by integrating Infura into your overall strategy. Infura implements a reverse proxy pattern internally and can be a highly reliable and performant node in your infrastructure stack, allowing you the ability to have a portion (or all) of your traffic routed to Infura.

You can choose to keep your database as your primary database with Infura as a backup, or vice versa. In this way, Infura will act as an always-on backup for your database, providing a level of flexibility previously not available with a single database running.

You also have the opportunity to use Infura as a stats comparison tool to make sure your performance is up to par. Alternatively, you may need to handle more load (request traffic) than your infrastructure can currently handle. You can route the overflow to an Infura project ID to handle spikes in traffic so your service stays up and running.

There are many opportunities for you to use Infura alongside your own in-house node infrastructure to improve your user experience. Let’s dive a little deeper on how we accomplish this.


What does it mean when Infura implements a reverse proxy pattern?

Let’s review what a normal proxy is first, and then we’ll flip it and reverse it, a la Missy Elliott, to talk about the reverse proxy. A proxy server (or web proxy or forward proxy) is a server located in front of a group of client machines (computers). When those computers make requests, the proxy server intercepts those requests and communicates with the target web servers on behalf of those clients. Basically, a proxy is a fancy word for a request/response middleman.

If you’re a visual learner, here’s a diagram from Cloudflare that shows just where that forward proxy sits:


What is a reverse proxy?

A reverse proxy is a server that typically sits on the edge of your infrastructure. It is responsible for receiving requests from web clients and subsequently routing them to one or more backend web servers.

Here’s another great diagram from Cloudflare to show how the reverse proxy fits in to the whole flow:




One of the main reasons to use a reverse proxy server is load balancing, ensuring the flow of traffic between clients and servers remains smooth. This is one of the main advantages of using both your own node and Infura. In addition, it allows you to cache content and provides web acceleration for improved performance. Lastly, reverse proxies allow for more efficient, secure SSL encryption and protection from DDoS attacks and related security issues.

As we previously mentioned, Infura can be used as a reverse proxy to assist with ensuring the flow of traffic for your clients and servers stays as smooth as possible, making for a more enjoyable user experience.


Some examples of a reverse proxy in action

Let’s first look at how we can set up a very simple reverse proxy using Caddy.

We will use our localhost and a backend HTTP service running on 127.0.0.1:9000 to make sure we’re getting our reverse proxy working correctly.

First, download Caddy. Once that’s downloaded, check out their Getting Started guide here. Or, follow along to learn how to set up a simple reverse proxy!


At this point, you may be running your own node, but since it takes too long to sync one for this article, we can substitute with a simple NodeJS stub to check that our reverse proxy is working correctly. I simply named mine main.js.


const http = require('http');

const hostname = '127.0.0.1';
const port = 9000;

const server = http.createServer((req, res) => {
   res.statusCode = 200;
   res.setHeader('Content-Type', 'text/plain');
   res.end('Reverse proxy success!\n');
});

server.listen(port, hostname, () => {
   console.log(`Server running at http://${hostname}:${port}/`);
});



This sets up a backend HTTP service running on 127.0.0.1:9000 mentioned earlier and will display a “Reverse proxy success!” message if our proxy is working correctly. To start this, run `node main.js` in a different terminal window and leave that connection open!

Next, we will want to create a Caddyfile (literally create a new text file in whatever directory you’re working in and name it Caddyfile). Once you have that set up, we will set up our simple reverse proxy itself inside the Caddyfile with just two lines:

localhost 

reverse_proxy 127.0.0.1:9000



In this instance, reverse_proxy is where we want to get our information from (the original site), and localhost is where we are redirecting to using our reverse proxy.

Now, from the same directory as your Caddyfile in a new terminal window from your `node main.js`, run:  

caddy run



This will start the caddy server and will allow your reverse proxy to work! Now, you’ll notice when you run this that you don’t see the “Reverse proxy success!” message popping up.

That’s because this just started the server. You now need to make a request to “https://localhost” and you’ll see the message. To do this, open another terminal window (that makes three now, for those of us keeping track), and simply run:

curl https://localhost



Running this command will give you the “Reverse proxy success!” message we were looking for, and now you know you’ve successfully set up a simple reverse proxy.


Enter Infura!

Now that we’ve gotten a basic reverse proxy up and running, let’s try one using an Infura endpoint. We will keep our overall setup of using a Caddyfile the same, but we won’t need the backend HTTP service running in the background, as that will be switched to an Infura endpoint.

We’re going to change up how our Caddyfile looks:

localhost 

reverse_proxy https://rinkeby.infura.io {
   header_up Host {/v3/<YOUR_PROJECT_ID>}
}



You will notice that we’ve added in a “header_up Host” inside the reverse_proxy section. This allows us to include our Project ID to both the Rinkeby endpoint and the localhost endpoint we are proxying to.

To test this out, we will need to send a request, so I used web3_clientVersion as an example:

curl https://localhost/v3/<YOUR_PROJECT_ID> \
-X POST \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"web3_clientVersion","params": [],"id":1}'



When we run this, we get the following output:

{"jsonrpc":"2.0","id":1,"result":"Geth/v1.10.8-omnibus-aef5bfb3/linux-amd64/go1.16.7"}



Cool! But how do I know my reverse proxy is working? Well, if you switch out `localhost` in our curl command to `rinkeby.infura.io`, you get the same output, which shows that our reverse proxy is running properly.


How do you use Infura as a backup for your own node?

We’re going to set things up initially the same as we did in the previous example but with two upstreams, one to our localhost and the other to the Infura node.

Next, we’re going to set up load balancing. Now, what’s load balancing? Load balancing acts like a traffic cop sitting in front of your application servers, routing client requests across all the servers that can fulfill those requests quickly and efficiently.

So how do we set that up?

Since we’re using Caddy, we can refer to their docs for the basics of how to use more than one upstream. When we look at lb_policy, there are many ways to determine which upstream Caddy will use first. Caddy will default to using the first listed upstream and will move down the list if the servers stop responding. In our example, we want to have localhost:9000 from our main.js file be the first upstream, meaning we want our reverse proxy to send the data through our localhost first, so we will identify that by putting it first in our list of upstreams (we will leave our Infura Rinkeby endpoint in as the second upstream):

localhost

reverse_proxy localhost:9000 https://rinkeby.infura.io {
   header_up Host {/v3/66172ed429624788ac264604755ba42c}
}



Since we are using the localhost:9000 port, we want to get that server back up and running. In another terminal window, start the Node server with node main.js.

To make sure everything is set up correctly, let’s run our request through by running the same request from earlier but with the :9000 port included, expecting to get the “Reverse proxy success!” message:

curl http://localhost:3000/v3/<YOUR_PROJECT_ID> \
-X POST \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"web3_clientVersion","params": [],"id":1}'



and we get the following output:

Reverse proxy success!



Excellent! Now, how do we incorporate the Infura endpoint to be a fallback?

You’ll notice we left the Infura endpoint in our Caddyfile where it originally stood and we asked our proxy to load balance using the first upstream (our localhost), which was how we got that “Reverse proxy success!” message.

Now that we confirmed that we set everything up correctly on our end, we’re going to kill the localhost server, mimicking what would happen if your private node went down. Once we do that, our requests should automatically start routing to the Infura node and we should get something similar to the below output:

{"jsonrpc":"2.0","id":1,"result":"Geth/v1.10.8-omnibus-aef5bfb3/linux-amd64/go1.16.7"}* Closing connection 0



But wait! We don’t get that! Instead, we get an error message.

This is because Caddy only allows us to use either two HTTP or two HTTPS endpoints - in our case, localhost is HTTP and our Infura endpoint is HTTPS.

Luckily, there is a tool we can use to make this work with localhost that will create a TLS certificate and sign it with a CA trusted locally by your device and browser. That tool is called mkcert, and it’s incredibly easy to install by following these steps.

Keep in mind if you’re doing this with your own private HTTPS node, you likely will not need this additional step.

If you are following our tutorial step-by-step (using localhost), be sure to follow all the steps, including updating your main.js file to the below to include the HTTPS requirement and the options constant.

const https = require('https');
const fs = require('fs')
const options = {
   key: fs.readFileSync('<PATH_TO_CERTIFICATE-KEY_FILE>.pem'),
   cert: fs.readFileSync('<PATH_TO_CERTIFICATE_FILE>.pem')
};

const hostname = '127.0.0.1';
const port = 9000;

const server = https.createServer(options, function(req, res) {
   res.statusCode = 200;
   res.setHeader('Content-Type', 'text/plain');
   setTimeout(() => {res.end('Reverse proxy success!\n');}, 1000)
});

server.listen(port, hostname, () => {
   console.log(`Server running at https://${hostname}:${port}/`);
});



When you run the mkcert localhost command from the tutorial, the certificate key file and certificate file used in the code above will be created.

Now that we have our localhost running with HTTPS, we can continue! Since we are running everything with HTTPS, we need to update our Caddyfile to reflect those changes.

localhost:3000 

reverse_proxy https://localhost:9000 https://rinkeby.infura.io {
   header_up Host {/v3/66172ed429624788ac264604755ba42c}
}



Now that we have all our files in order, let’s make sure our Node.js server is running and send that request again.

curl http://localhost:3000/v3/<YOUR_PROJECT_ID> \
-X POST \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"web3_clientVersion","params": [],"id":1}'



What do we get?

Reverse proxy success!



Perfect! That’s exactly what we want to get, as we have asked our reverse proxy to go to https://localhost:9000 first.

Now, what happens if we kill the Node server and send our request again? Remember last time we did this, we got an error message. This time we should be getting the result from our Infura Rinkeby node:

{"jsonrpc":"2.0","id":1,"result":"Geth/v1.10.8-omnibus-aef5bfb3/linux-amd64/go1.16.7"}



Success!

Our reverse proxy is, in essence, ignoring the localhost node, as it’s not functioning, and is defaulting to the Infura Rinkeby node!

Super easy, right? Now you know how to use Infura as a backup node to keep your services up and running smoothly!


Where can I learn more about reverse proxies?

Take a look at our client story from MakerDAO. They currently use Infura for a multitude of reasons, including using us as a backup node solution to ensure all developers can use the MakerDAO toolkit!

Another great example is the Polygon PoS network. We initially began working with Polygon to share some traffic load for their network, allowing users to access the Polygon networks via Infura endpoints and effectively ensuring their network remains fast and functional, regardless of traffic spikes they may see. We have since increased our partnership so we are now handling 100% of their network traffic.

Check out this blog post highlighting multiple companies across all verticals using a hybrid infrastructure model of their own nodes plus Infura. Get some ideas on how we can help you accomplish your needs, from verifying transactions to providing backup database services!

If you would like to run an Infura node in addition to your own, sign up for a free trial today.

How to Run Your Own Node AND an Infura Node

When enterprise developers build dapps on Ethereum, they often have to consider the entire tech stack and development process. The list of considerations range from application features such as Web2 interfaces to deployment, which is usually on a permissioned network hosted by a preferred cloud provider. Since most full-stack software engineers build off of SDKs and API calls, it’s important to establish the value of the application with consideration of the deployment network.



Get the best of both Web2 and Web3 worlds

Many enterprise blockchain business cases build on the principles of traditional Web2 development. Web2 focuses on operating with a fluid user experience with attention to detail on scalable and responsive code on multiple devices. A valuable decentralized application (dapp) in Web3 redesigns the economics and industry roles while building on complementary existing systems -- instead of fully replacing those systems with analogous Web3 features.

Say you would like to reinvent a syndicated loans issuance platform such as IPREO. This effort would require significant IT resources to spin up a minimum viable product from the ground up if you’re recreating features like tranche issuance calculations or calendar date exceptions. Instead, consider a path to lesser resistance: blockchain modules that connect these digital assets to new liquidity networks. The functionality is a re-issuance of an existing financial instrument to ABC network with a listing on XYZ automatic market maker rather than the full end-to-end dashboard.

To connect to pockets of liquidity, an enterprise developer must deploy with the same smart contract language that is compatible with the Ethereum Virtual Machine (EVM) and look to bridge the assets to networks with the desired investor and issuer markets.


Why build on public Ethereum?

Until now, publishing enterprise dapps on Ethereum requires significant system integration, executive buy-in and high set-up costs. Recently, we have seen more public blockchains working with enterprises to cover non-functional technical needs in order to meet minimum requirements of security audits and performance. However, the relatively tribal nature of the blockchain developer subculture means that mainstream enterprises are still conservative when it comes to building on Ethereum.

If you are an enterprise developer, consider the following advantages of building on public Ethereum vs. permissioned networks:

1. Faster setup and lower total cost of ownership

2. Immutability and longevity of the data stored with thousands of independent nodes

3. Composability and low barrier of entry to decentralized finance (DeFi)




1. Faster set-up and lower total cost of ownership

This is a standard private blockchain journey for a consortium:

After you develop your dapp, a lot of time is focused on node deployment adhering to enterprise software standards. On the business side, you are also trying to build a consortium to agree on the benefits and adoption before the tech is tested.

The consortium model usually chooses a separate tech vendor that does not have single ownership from one consortium member to prevent conflicts of interest. The tech vendor determining deployment and long-term support likely runs the Ethereum nodes on behalf of participants. This will get the product to market faster and focus on the business benefits.

The last step involves time and licenses for adding more nodes and mutualizing infrastructure costs across participants. Compared with private networks that remove tokens from their operation, public networks require ownership of native tokens to fund transactions. This gas cost pays for the infrastructure -- third parties running full nodes and running operations for mining/validating. In my time building enterprise projects, we have never seen this happen.

The public journey is much more straightforward. After you develop your dapp, the deployment is a choice between public networks with updated configurations on your Truffle setup. The added complexity is the gas costs for funding and running your transactions on this network.

To simplify connectivity to EVM-compatible networks, you can use Infura’s Ethereum API to connect your app instantly with a single line of code. Simplify your transaction management with Infura Transactions (ITX) using prepaid accounts without holding ETH on your balance sheets. ITX is a transaction relayer that manages your transactions to prevent dropped or stuck transactions.

You will also likely want to work with a team such as Diligence that can audit your contracts and monitor them when they’re live.

Public Ethereum has an overall lower total cost of ownership when you compare the operational cost of running a system on mainnet rather than focusing on the ownership and maintenance of the network itself.

A consortium may have more control in the private chain and face less security and treasury reviews at first. However, your infrastructure overhead and negotiations on consortium network matters tend to outweigh the convenience and added features of connecting to mainnet.


2. Immutability and Longevity

The Ethereum mainnet is secured by the interaction of thousands of independent nodes run by individuals and miners throughout the world. Private chains typically have a small number of nodes controlled by one or a few organizations. Those nodes can be tightly controlled, but only a few need to be compromised in order to rewrite the chain or commit fraudulent transactions.

At ConsenSys, we’ve recommended public networks to enterprise developers for their resilience of replicated data as you are able to recover more quickly with a larger network of more than 15,000 independent nodes. The more peers you have, the easier it is to find a seed and fully recover your recorded transactions. In consensus decisions, the more blockchain validators there are to verify transactions, the more difficult it is to coordinate a majority decision that may lead to an attack.

In a permissioned network, the security is governed by the node with the least security. Your network is only as secure as the weakest link. Any added nodes to the network may also increase the surface area of attack. Most institutions will recommend a base software security test in order to join as a full node owner. The node owner will have to pass standard penetration testing to prevent any hacking on the node in case it is a bad actor to the entire network.


3. Composability and Low Barrier to Entry on DeFi


The Ethereum network powers a vibrant ecosystem of third party applications and technology including DeFi and NFTs. A highly composable and interoperable system allows you to connect to DeFi to build financial products that enable and combine multiple apps to match specific user needs. The Ethereum mainnet offers enterprise developers the ability to gain access to market liquidity and provide innovative ways for users to participate in the exchange, trading or growth of that liquidity.

When we say composable, it’s much more than just an open banking API. It’s a set of open source live protocol contracts that can be called and extended. We’ve seen pure forks of open source code like with Uniswap to get sushiswap. The market has seen countless copies of DeFi models such as Compound and Aave, and it doesn’t look like things are slowing down anytime soon.

There’s more and more real value happening in DeFi leading us to believe that cryptocurrencies are not a fad. It is here to stay.

Watch Clemens’ presentation “Pitching Public Ethereum to Enterprises” at EdCon 2021.

Interested in building on Ethereum? Contact us to get support on starting your enterprise project.

3 things enterprise developers should consider when deploying on Ethereum

Are you excited by blockchain but don’t have a great deal of experience coding? It can be easy to fall down a rabbit hole of technical tutorials that make assumptions regarding your initial development knowledge. A particularly important topic to grasp is basic security within your code.

As you begin to build out your very own dApp, you will have to include information such as an Infura API key, along with a mnemonic.

If you are new to coding, this is the equivalent of giving a stranger your social security number and keys to your home. Once this information is public, there is no definitive way to ensure it hasn’t been captured by a person or web crawler, which could result in malicious behavior.

So, how can we address this?

Thankfully, we can use dotenv along with git to protect our sensitive information within our project when / if we push to github.

Dotenv is a zero-dependency module that loads environment variables from a .env file into process.env, storing configuration in the environment separate from the code. It is often a convention for environment variables to be stored in a .env file or other mechanisms based on the server you are using.

Note: This article will focus on building out a project using Truffle and Infura.

In our project, we will need to run the following command:

npm i dotenv


Once the process in our terminal has been completed, we will want to make sure we have the dependency successfully installed. Head over to your package.json file and check to ensure that dotenv has been added under dependencies.

Next, at the root of our project, let’s create a .env file:

Here is where you will add all of the sensitive information that should not be shared.

We will make sure we can access our .env information in our truffle.config file. At the top of the truffle.config file, add the following:

require("dotenv").config


This will tell your project to load anything that is in the .env into an environment variable, granting you access to it.

Now, instead of having to put our Infura api key or mnemonic in an exposed file, we can import that information from our .env file.

When it comes to gaining access to our project key we are going to use, sign up to Infura and create a project. In your dashboard, you should see something similar to this:

The following code is an example between the usage of .env and exposed information within truffle.config:

const HDWalletProvider = require('@truffle/hdwallet-provider');

const infuraURL = 'https://rinkeby.infura.io/v3/<project id here>'

const mnemonic = "Your mnemonic here"


rinkeby: {

provider: () => new HDWalletProvider (mnemonic, infuraURL),

network_id: 4,

gas: 5500000,

confirmations: 2,

timeoutBlocks: 200,

skipDryRun: true

},


Imagine if you pushed this up to github. Anyone would have the ability to open your truffle.config file could take advantage of your exposed mnemonic and project id from Infura.

Let’s take a look at that same code and implement better security practices.

Notice how we are calling upon the information without having to directly add to our file.

One important detail, as of now even with an .env file: if you push this project to github, it will show the .env file, which would defeat the purpose!

Take a look for yourself.

This is where .gitignore comes into play. We will need to create a .gitignore file, so we can push this project up to github.

Without getting into git, a quick summary could be git is version control software that keeps track of all of your files and the versions of them. What .gitignore does is it tells git not to keep track of this file along with everything it contains.

If you want to dive deeper into git along with other foundational material, have a look at our Basic Training, a free course that helps ensure you have the fundamental tools when developing.

At our root (similar to the level our .env file lives), we will create a .gitignore. Inside of that file, we will add .env along with any other files you would rather not be pushed to github.

We can now push our project up to github and notice that our .env file is no longer exposed. Our sensitive information is now much more secure.

If you are experimenting with this, make sure you add your .env file to your .gitignore before pushing.

If you are running into issues, remember gitignore ignores only untracked files. If your files were committed in the past, they are now tracked by git. To ignore them, you first need to delete said files, git rm them, commit and then ignore.

Otherwise, you can delete the .env file and run

Git rm .env --cached


Here is a helpful link discussing the removal of sensitive data from a repo if it was previously committed and discusses how to clean the git history. Savvy attackers don't just look at the most recent repository info, they'll look at the history of it as well.

Note: If you come across it in documentation, a question you might have is
“What is env. example”

An env. example file, on the contrary to this tutorial, is actually included in the repository, it is used as an example file for you to know what KEY=VALUE pairs you need for your project. Most often, it is used to copy the .env file and then change the values.

Example of execution:
Enter to the project root directory using your terminal.

Check if .env the file exists or not.

If the file does not exist then create a file named .env.

Now execute the command

cp .env.local .env.


So the .env.sample file has all the ENV declarations defined but without their values. It helps other developers establish/set up the project without having to reverse-engineer the codebase.

So after git clone, you usually execute the command `cp .env.sample .env` and fill in the values with the Infura credentials as we saw in the example above.

Note: When you create a new repo using github, if you scroll down you should see the option to include a .gitignore file so you don’t have to create one yourself in the future.

Hopefully, you found this article on basic security practices helpful as you begin to develop your very own projects. Feel free to join our Discord if you want to continue the conversation, share projects, ideas, and join the community!

Start here with a free Infura account >

How to Use .env to Enhance Basic Security Within Your DApp

Optimistic Ethereum is a rollup scaling solution that allows users to submit transactions on the Ethereum network and get them executed faster for a much lower gas cost. From the perspectives of users and developers, this is a "parallel universe" called Layer 2, or L2, where users typically have the same addresses as they do on the Ethereum blockchain (also called Layer 1 or L1). There are gateways that allow messages and assets to be transferred between the universes.

The Optimism network API largely uses the same JSON-RPC specification as Ethereum and Infura supports all the necessary API methods for building a fully functional application on the Optimistic Ethereum network.


Why are transactions cheaper on Optimism?

On L1 Ethereum, thousands of nodes run your transaction to verify that the proposed block that includes it is valid. This process is expensive and has to be paid for. Unlike on L1 Ethereum, Optimistic roll ups provide faster and cheaper transactions because it allows users to perform most of their tasks off-chain in a "layer 2" protocol. On Optimistic Ethereum, the smart contract has only two tasks: deposits/withdrawals and verifying proofs of transactions on chain. This makes the process more efficient and a lot cheaper.


Why is this safe?

The great thing about decentralization is you can trust that transactions are executed correctly because there are thousands of computers executing them. Honest miners would reject such a transaction. With rollups, you don't have that level of redundancy.

The answer, in the case of optimistic rollups, is incentives. Every node in the network has to put up a stake before it can propose a new block with the execution results of a transaction. Every other node can check up on those results, and if it thinks they are incorrect, dispute them. The dispute is resolved on L1, so it is as trustworthy as anything else in Ethereum. Whichever node lies, either proposer or disputer, loses its stake and most of it goes to the other node involved.

Of course, the whole point is to avoid running transactions in L1. This system achieves that by making it pointless to cheat. Any proposer who attempts to cheat is going to be caught by the other nodes, lose its stake, and not get the invalid transaction result accepted as valid. A disputer can force a single transaction to go into L1 arbitration as a denial of service attack, but the stake is high enough that it wouldn't be worth doing.


How does Infura work with Optimism?

Infura exposes endpoints for Optimistic Ethereum (the production network) and Optimistic Kovan (the test network). You use them the same way you use any other network, by selecting them from the menu and using the specified endpoint.

There are a few small differences between building on Layer 1 Ethereum and Optimism:

1. You must use the JSON-RPC API as we do not support Websockets yet.
2. Search filters are not yet supported


How to Get Started on Optimism...



The main difference between Optimism and regular L1 Ethereum (other than the cost) is the access point URL.

| Network          | RPC URL |


… If you are using the Truffle development environment

Infura users can add the free Truffle Optimism add-on directly on their Infura dashboard. The Truffle Optimism box also contains the configuration definitions required to use Infura. Currently, you will need to manually add the gas costs of transactions when you use Truffle to run deployments or tests on Optimistic Kovan or the main Optimistic Ethereum network.


… If you are using Hardhat

To use Optimistic Ethereum or Kovan, edit hardhat.config.js's modules.export.networks to add these definitions:

"optimistic-kovan": {
    url: 'https://optimism-kovan.infura.io/v3/<Infura Project ID>',
    accounts: { mnemonic: <your account mnemonic goes here> },
    gasPrice: 15000000,
    ovm: true // This sets the network as using the ovm and ensure
                      // contract will be compiled against that.
},
"optimistic-ethereum": {
  url: 'https://optimism-mainnet.infura.io/v3/<Infura Project ID>',
  accounts: { mnemonic: <your account mnemonic goes here> },
  gasPrice: 15000000,
  ovm: true // This sets the network as using the ovm and ensure
                    // contract will be compiled against that.
}



Then you simply run:

npx hardhat --network optimistic-<kovan or ethereum> <command>



… If you are using Remix

When you use the Remix Optimism plugin to develop for Optimism, network connections are created through the wallet. If you use MetaMask, you can select the network Custom RPC and fill in the details:

What is Optimistic Ethereum?

Infura now supports additional networks including Arbitrum, Optimism and Polygon.

All three projects are essentially new blockchain networks. They offer low transaction fees and faster confirmation times compared to Ethereum. Crucially, they extend the utility of Ethereum as users can transact using their assets that fundamentally reside on Ethereum.

This scaling approach is called off-chain protocols and we have put together a short post to help explain how they help to scale (and extend the utility) of Ethereum.


Why not just transact on Ethereum? What is the scalability bottleneck?

Ethereum supports around 15 transactions per second and as seen in Figure 1 the network fees tend to skyrocket when users exceed the network’s throughput ceiling. In some ways, the throughput limitation is self-imposed by the community in the pursuit of decentralization.

The goal for decentralization is to maximise the percentage of the world’s population who can verify the blockchain’s integrity (and transactions) in real-time. This goal is essential to minimise the trust in block producers as the community can self-enforce the set of consensus rules that govern the validity of blocks. Depending on the target percentage of the world’s population, there is a limit to the computational, storage and bandwidth available to the network for processing transactions.

Our challenge as a community is to figure out how to increase the network’s throughput while adhering to the imposed resource constraints.


Why should we care about off-chain protocols like sidechains or rollups?

Most approaches to scale the network focus on:

 * Distributing verification. The verification task is distributed amongst nodes on the network as opposed to requiring all nodes to replicate the same work (Ethereum today).
 * Better utilize the network's available resources. The network's resources should be continuously utilised and not allowed to sit idle. For example, short block intervals to better utilize bandwidth.  

Scaling solutions still remain a few years away from adoption as they require major changes to the underlying Ethereum protocol.

An alternative and popular scaling approach, off-chain protocols, is a solution that is immediately available. It scales the network in a following way:

Off-chain protocols: Transaction processing is moved away from Ethereum to another network while still transacting with the same assets that reside on Ethereum.

We consider this a scaling solution as other blockchain networks are not limited by the same resource constraints as Ethereum. They can experiment with various scaling protocols (or simply test the limits of go-ethereum) while extending the utility of Ethereum.


Where are my assets held when transferred to another network?

A bridge contract is responsible for holding the user’s assets on one blockchain (Ethereum) and notifying the other network to mint an equal quantity of coins for the user. Once minted, the user can transact on the other network and eventually withdraw their funds back to the original blockchain (Ethereum) via the bridge contract.

Not all bridge contracts are equal. We must consider the bridge contract's process for deciding when to release funds back to the user. Ideally, the funds should only be released if the bridge contract is convinced the other network is not compromised. This is called the underlying trust assumption that ultimately protects the user’s funds. It can often cause controversy when discussing whether an off-chain protocol is truly scaling Ethereum.

On one hand, some users only consider a new blockchain network a scalability solution if the other network can retain the same (or very close to) security of Ethereum.  Protocols that can achieve this level of security are often called rollups. Whereas, other users will be satisfied with stronger trust assumptions as long as the funds locked into the other network are secure enough (sidechains).

Rollups, that retain the same security as the main-chain, will require more resources from Ethereum. For example, every transaction on the rollup network generates a state update that is published to the bridge contract. Whereas a side-chain does not necessarily require significant resources from Ethereum as validation of transactions is performed by a set of external parties. This trade-off on security/resources will be felt financially by the users and as a result there is no free-lunch.

Regardless, we believe that different bridge contracts will emerge and implement different degrees of trust. In the end, all blockchain networks which support transacting assets that reside on Ethereum will increase the utility of Ethereum. It is just important that users are aware of the trust assumptions and risks before deciding to lock funds into a bridge contract.


What is a sidechain?

The term sidechain originates from a paper by Blockstream. It was an interoperability solution to enable two blockchains to verify information about each other’s progress via light-weight proofs. The intention was to allow bitcoins to be locked in Bitcoin and to be released in the other network (and vice versa) without trusting any intermediary with the funds.

Over the years, the term sidechain has taken on a life of its own. It is often used to imply that an independent blockchain network has a relationship with another blockchain network. In practice, this is implemented with a bridge contract that allows assets to be moved from the main-chain (Ethereum) to another blockchain network.

There are three type of bridge contracts that are used for side-chains:

 * Single organisational. A single party has custody of the funds locked in the bridge contract.
 * Multi organisational. A fixed set of independent parties (K of N) has custody of funds that are locked.
 * Crypto-economic. A dynamic set of parties, determined by their weight in assets, have custody of the funds.

For example, WBTC is a single organisational bridge as the BTC is held by BitGo. The Liquid Network and RSK blockchain implement a multi-organisational bridge as an appointed set of parties will authorise assets to be moved across from one blockchain to another (i.e., implemented as a multi-sig). Polygon is a crypto-economic bridge as it relies on (⅔)+1 of stake to appoint validators who post periodic checkpoints about the network’s state to the bridge contract (and this checkpoint can be used to automate user withdrawals).

Crucially, the bridge contract for a sidechain does not verify the integrity of the other network and instead it relies on a set of parties to attest to its validity. It is assumed that at least a threshold of parties should have a financial incentive to remain honest and protect the user’s funds.

While the cost of a sidechain transaction consumes no additional Ethereum resources, the trade off is that the network will not retain the security of Ethereum and ultimately, trustlessness.


What is a rollup?

The term rollup originates from barry whitehat’s zkrollup and it emerged from the research on Plasma.

A rollup is still an independent blockchain network, but the transacted assets that reside on Ethereum are protected by the bridge contract. It must be continuously convinced the rollup network is not compromised and the funds are not at risk. In the worst-case, the bridge will bypass the other network and allow users to unwind and eventually withdraw their funds.

A rollup can retain the same (or very close to) the security of Ethereum and this is accomplished by solving the following problems:

 * Data availability. The bridge contract must be convinced that all data is publicly available. This allows anyone to independently compute the rollup’s stateful database.
 * State transition integrity. The bridge contract must be convinced that all state transitions (transactions) are valid.
 * Censorship-resistance. The bridge contract will self-enforce transaction inclusion to ensure a user can eventually withdraw their funds if the network is compromised (or no longer making progress).

As a quick summary on potential solutions. The data availability problem is solved by just posting all data to the Ethereum network and this is where the name rollup originates (to roll up the data). The state transition integrity problem is solved using a fraud proof (Optimistic rollup) or a validity proof (zero knowledge rollups) system. The censorship-resistance problem is a little trickier, and often not discussed, but it requires the bridge contract to self-force the inclusion and eventual execution of user-generated transactions.

There is an on-going financial cost for rollup. The network must continuously provide evidence to the bridge contract that all finalised transactions are valid and the network is not compromised. This consumes resources from Ethereum and impacts the scalability that is attainable by rollups. However in the immediate term, it can significantly reduce the cost of a transaction. For example, in Arbitrum, a swap costs 1,600 gas compared to 120,000 gas on Ethereum.


What is the difference between a sidechain and a rollup?

Sidechains, such as Polygon and rollups, such as Optimism and Arbitrum are just independent blockchain networks. They have their own set of block producers and smart contract environments. The core difference between a sidechain and a rollup is found in the bridge contract that locks funds from Ethereum onto the other network. Precisely, it is the trust assumption that protects the funds held by the bridge contract.

 * Sidechain. The bridge contract may receive information about the other network, but it does not validate its correctness. A set of parties who govern the bridge are responsible for checking the other network is not compromised and attesting this fact to the bridge contract.
 * Rollup. A set of parties (sequencers) are responsible for providing evidence about the state of the other network to the bridge contract. It is up to the bridge contract to validate the evidence’s correctness and to independently verify the other network is not compromised.

It is a subtle difference, but it boils down to whether the bridge contract can self-enforce the validity of transactions on the other network or if it must rely upon a trusted set of parties to attest that it is valid.

Of course, there is no free lunch. Rollup networks can retain the security of Ethereum, but it also consumes more resources of Ethereum. This increases the financial cost to transact on a rollup network compared to a side-chain.  As a user or developer, you will need to consider the security offered by the other network and the potential financial cost that it entails.

Choose a solution that best suits your use case.


How can I get started with rollups and sidechains?

You can check out our blog announcements for the networks we support which includes Arbitrum, Optimism and Polygon.

All networks adhere to the same JSON RPC standard as the Ethereum network and they support EMV-compatible smart contracts. You can activate the networks in your Infura account, update the provider URL and start interacting with the networks immediately.

Arbitrum and Optimism are still in beta and in the progress of preparing for their mainnet launch. You may need to contact the teams if you want to deploy a smart contract to their mainnet. Polygon is already launched and you can start deploying contracts immediately.

We hope you found this article about rollups and side-chains informative. At Infura, we have supported Ethereum for over 5 years and we are excited to now support new projects that extend the utility (and scalability) of Ethereum.

Off-chain protocols: Sidechains and Rollups

This article delves into best practices for building decentralized products for the next iteration of the internet. It also highlights how MetaMask Snaps contributes to this endeavor.

UX design for decentralized protocols is an undiscovered and undefined discipline. The design principles used in web2 software development don’t apply to blockchain-based apps that require tokenomics, governance, and above all communities to thrive. 

Asking the right research questions and choosing the right research method is crucial to achieving product-market fit and scalability of dapps and communities. Here are the best practices we’ve learned for UX design research in web3. 


Choose the right research methods to answer your UX design questions

In an emergent industry like web3, knowing who your customers are can be challenging. As the world continues to adopt blockchain technology, your knowledge and understanding of who your target audience could constantly change. 

So how can you not lose sight of who you’re building for in order to create the perfect design of your product and service? 

Through continuous research and iterations.

This best practice, while not unique to web3, is essential in UX design since user adoption is growing faster than in traditional tech. Continuous research and iterations help you stay updated about who your customers are, how to investigate the experiences of end-users, and how to measure impact. 

Research as a discipline is a continuous process that helps with product improvements and iterations over time. If you’re looking to learn more about unknown areas of your product, customers, or potential customers, you’re performing discovery research. While some discovery research might not require deep contextual information, others may. 

For example, if you’re looking to measure the current design experience of your product, a short survey could easily obtain such insights. On the other hand, if you’re looking to understand the why behind current design experience ratings, then follow-up remote interviews are more equipped to help you uncover deeper insights. 

Remote interviews, contextual inquiries, and diary studies are uniquely positioned to uncover the why behind any research or business questions. Surveys, content testing, concept testing, and A/B testing are uniquely positioned to uncover the “what” behind any research question. 


Common UX research questions asked in Web3

Spoiler alert: research questions asked in web3 are no different than those asked in web2 because they’re all contextual and specific to the industry a researcher or business operates in. Research questions in web3 are web3 specific. 

Some questions might focus on various blockchains; others may revolve around protocols. However, it’s important to note that research questions are context-specific. 

Additionally, research questions are often reframed business questions. For example, your product team might have a business question like, “What new blockchains should we support?” Reframing this business question to a research question then evolves into: 

 1. What blockchains are developers most interested in building on?
 2. Why are developers interested in this blockchains? 
 3. What value would supporting other blockchains provide builders?

It’s important to gain alignment on your research questions from the stakeholders that you’re working with before starting an investigation. The last thing any researcher wants to do is investigate things that their stakeholders do not agree with. Save yourself time and effort by making sure your research questions align with business needs. 


Web3 UX is ours to define

Researchers are well-positioned to reframe business questions to research questions, create plans of investigation, and provide insights to help product and protocol design teams make data-driven decisions. 

There’s still a lot to learn in web3, especially as the rest of the world adopts blockchain technology. Choosing the right research methods to address research questions and asking the right research questions are essential. 

Research is a continuous and iterative process. As we learn more on our journey of supporting developers of all kinds, we’ll continue to share lessons learned and best practices for UX research and design in web3. Keep an eye out for part two of this series.


Three ways MetaMask Snaps enhances Web3 UX

Before diving into how MetaMask Snaps can enhance your web3 dapp’s UX, let's first clarify what MetaMask Snaps are. MetaMask Snaps, also known as ‘Snaps’, are JavaScript applications built by third-party developers that modify and enrich the wallet experience for MetaMask users by adding various features and functionalities.

Snap’s mission is to decentralize the development of the MetaMask wallet. Given the numerous protocols and projects launching daily, a decentralized approach is vital. The existing development team identified that an effective way to keep the MetaMask wallet updated with new protocols is to grant developers the ability to integrate support for their projects directly into MetaMask itself. To delve deeper into Snaps or to learn how to create your first Snap, click here.

Now that we've established what Snaps are, here are three ways Snaps  can elevate your web3 dapp’s UX:

 1. Interoperability: A unified wallet for multiple blockchains: The rapidly evolving web3 landscape often requires users to juggle multiple wallets, especially if they're engaging with different blockchains like Ethereum, Bitcoin, Solana, and others. 
    
    Instead of downloading and mastering various wallets, wouldn't it be easier to have one that does it all? MetaMask Snaps addresses this issue. With the help of third-party developers, MetaMask Snaps can expand the wallet's functionality, allowing it to cater to users engaging with non-EVM chains in a secure manner.
 2. Authentication: Streamlined sign-ins for dapps: A notable difference between web2 and web3 applications is the way user authentication is handled. In web2, users are required to provide their email and passwords or accept various cookies and terms. In contrast, the web3 experience is simple and straightforward: users only need to connect their wallet. MetaMask Snaps enhances this by introducing a new set of APIs.
    
    These APIs allow developers to explore innovative methods and further simplify interactions and authentication on dapps using shared decentralized identities and verifiable credentials.
 3. Security: Enhanced transaction insights: A significant concern in web3 today is phishing attacks, where users sign transactions without fully understanding their implications. To combat this, MetaMask Snaps implements measures such as checking recipient addresses against known phishing databases and simulating transactions to determine their potential outcomes, ensuring users have a clearer picture before confirming any action.

Metamask Snaps is a great way to introduce wallet-centric UX upgrades for your protocol and dapp. To learn more about building a Snap, visit this website. If you have questions or ideas, chat with us on GitHub or the Consensys Discord's snaps-dev-metamask channel.

web3

The Principles of Web3 UX Design Part 1: Research Best Practices

In this blog, we explore the fascinating journey of building the dapp "Polis" and its IPFS-powered database inspired by ancient Greece's Polis city.

In ancient Greece, there was a city called "Polis" where people gathered to discuss a wide range of topics, including politics, governance, and laws. Unfortunately, they never delved into the art of building a database in IPFS.

As a result, when we embarked on building the dapp Polis that necessitated an IPFS-powered database, we faced numerous challenges, occasionally succumbing to bouts of frustration. 

In this developer's tale, I'll explore our journey, highlighting our thought processes, unforeseen discoveries, and key moments. Although this isn't a comprehensive guide and may not represent the perfect solution, it stands as a valuable resource for those aiming to create something similar or explore deeper experimentation.


What is web3 dapp, Polis?

Polis is a knowledge base for all things dapps, its primary function is to be a collection of dapp templates and essential tools, curated to empower developers in their quest to create outstanding projects. For now, anyone can submit their entry on Polis in a few simple clicks and plans are on the way to better streamline this process. The code for Polis is also open-sourced so feel free to follow the repository and give it a star!


Choosing the stack for Polis with Infura and IPFS

In choosing the stack for Polis, we had two key requirements: using Polis should be free for all users and Polis must be developed using a decentralized database so as to reduce dependence on centralized providers. With these requirements set, we embarked on a quest for the Polis-stack.


Database

In choosing a database, the first option we ruled out was the blockchain, primarily because of gas fees. Considering the vast amount of data we planned to gather, including descriptions, links, and images, writing to the blockchain would be costly.

Other database solutions like orbit-db were available, but we sought something straightforward, minimalistic, and something we could easily integrate with our existing knowledge.

This lead us to IPFS, IPFS is a protocol designed for organizing and transferring data using content addressing rather than location addressing, complemented by peer-to-peer networking.

However, a significant drawback of IPFS is its emphasis on data immutability. Traditional databases allow for easy updates and modifications, while IPFS enshrines immutability. Once data is committed to IPFS, it remains unchanged. To update data, one typically generates a new version with a different content hash.

Our next challenge was finding a method to create mutable data storage with IPFS. One solution is to implement a mutable file system (MFS). Though a promising idea, we realized we weren't looking for file storage per se, but rather a database that might be encompassed in a single file.

Our research then led us to IPNS, and it appeared to be the perfect complement to IPFS. With their powers combined, we were set on the database end.


Infura IPFS

For easy access to IPFS, we chose Infura. Infura is both reliable and intuitive and with the Infura IPFS offering, you can be assured that your IPFS files are always stored securely, preventing the feeling that you're sending files into the Bermuda Triangle.

To interact with Infura, you can utilize the API endpoints or use the JavaScript client library for IPFS, ipfs-http-client or alternatively, you can use kubo-rpc-client. However, we chose to use the HTTP endpoints that Infura provides. For a comprehensive introduction to Infura IPFS, you might find this blog post helpful.


Frontend

For our frontend, we enlisted Next.js because, let's face it, it's the cool kid in town. To save ourselves from CSS-induced headaches, we brought in Tailwind CSS – because, frankly, we're not CSS superheroes.


w3name

To address content addressing and naming, we went with w3name. This is a service and client library that implements IPNS, - a protocol that uses public key cryptography to allow for updatable naming in an atomically verifiable way.

Now let’s dive into how we tied all these together.


IPFS as a database

For the sake of simplicity, we are creating a minimal JSON database named applications.json.

This JSON file consists of an array of objects, each representing an application submitted by a fellow web3 enthusiast. Here's an example featuring just one application.

[
	{
			"id": "oMObNGIHGupfgKkwUnK-W", // random string
			"user": "0xc12ca5A8c4726ed7e00aE6De2b068C3c48fA6570", // user's wallet address
			"createdAt": "9/1/2023, 11:34:27 PM",
			"category": [ "Security"],
			"title": "MobyMask ",
			"description": "This snap warns you when interacting with a contract that has been identified as a phisher in the MobyMask Phisher Registry.  ",
			"applicationUrl": "<https://montoya.github.io/mobymask-snap/>",
			"repoUrl": "<https://github.com/Montoya/mobymask-snap>",
			"screenshots": "QmddFhP3od4qRyLpzVQkoCuoGp3XRxHEeS1kckW3uHfiqF",
			"logo": "QmdiM7AnXtShBznk6HbHrTBttbetRYbeixmDjaypreuPCV",
			"isEditorsPick": false
	}

]



While searching for ways to build a simple database with IPFS, we came across an awesome blog post by Radovan Stevanovic. Based on this post, we built our own implementation, considering the data structure we wanted. We didn't implement all the database functionalities since we aimed to test an MVP of Polis first. 

Here are some primary functions in the database, sufficient to understand our direction, located in `lib/database.ts`. As we continue to receive more applications, both the JSON object and file grow in size. While this growth might pose challenges in the future, we're not overly concerned currently. 

We can tackle scalability issues later. Although IPFS excels in its present role, we must think about how we'll manage updates, like adding new applications or editing existing ones. Get ready for some tech magic as we mould IPFS's rigidity into a more adaptable dance, all thanks to IPNS!


Compensating for IPFS's shortcomings using IPNS

The primary challenge with our current approach is that any update to the JSON file results in a new file with a different CID. This isn't the desired outcome.

How does IPNS help address this issue? IPNS allows users to associate a mutable, human-readable name with a specific IPFS content address. Even when the content linked to the IPNS name changes, we can still access the updated content.

Here's a brief overview of how IPNS works:

 * An IPFS user generates a cryptographic key pair. The private key remains secret, while the public key is used to create an IPNS namespace.
 * The user can then publish an IPNS record, signing it with their private key. This record contains the mutable name and the corresponding IPFS content address (usually a hash).
 * The IPNS record is distributed across the IPFS network via the Distributed Hash Table (DHT), making it available to other users.
 * When someone wishes to access content associated with the mutable name, they look up the IPNS record using that name and retrieve the current content address.


Tying it all together with a frontend

In the 'Submit Application' modal, once the submit button is pressed, a brief pause ensues, highlighted by a continuously spinning loader icon on the button. A significant amount of data, including images, is then relayed to the submitApplication function. Here’s what goes on inside that function:

export const submitApplication = async ({
  images,
  data,
}: {
  images: FormData;
  data: string;
}) => {
  let logoHash, screenshotsHash;

  const logo = images.get("logo") as File;
  const screenshots = images.getAll("screenshots") as File[];

// adding the logo to ipfs and get back the hash of the file
  if (logo) {
    logoHash = await add({ file: logo });
  }

// adding all screenshots to ipfs as a directory and get back the hash of the directory
  if (screenshots.length > 0) {
    screenshotsHash = await add({ files: screenshots });
  }

  const application = JSON.parse(data) as Omit<
    IApplication,
    "id" | "screenshots" | "logo"
  >;

// retrive the latest database file. 
  const state = await retrieveDatabase();

  const newState = addNode(state, {
    id: nanoid(),
    ...application,
    screenshots: screenshotsHash,
    logo: logoHash,
    createdAt: new Date().toLocaleString("en-US", { timeZone: "UTC" }),
    isEditorsPick: false,
  });

// creating and add a new file to ipfs, then publish its hash to ipns
  await storeDatabase(newState);

// nextjs cache revalidation to show the newly added application
  revalidatePath("/");
};



Here’s a high-level description of what this function does:

 * Extracts image files: It extracts the logo and screenshots from the provided images FormData.
 * Uploads to IPFS: If provided, the logo and screenshots are uploaded to IPFS, and their respective IPFS hash values are stored.
 * Parses application data: The provided data string is converted to a JSON object.
 * Retrieves current database: It fetches the current state of the database.
 * Adds new application entry: A new application entry, including the uploaded image hashes, is added to the database.
 * Updates database on IPFS: The updated database is stored on IPFS and its hash is published to IPNS for mutable referencing.
 * Cache revalidation: It triggers a cache update to reflect the new addition in the user interface.

Let’s take a closer look at what happens inside the retrieveDatabase function referenced above:

const retrieveDatabase = async () => {
// getting the latest db hash
  const hash = await getcurrentHash();

  const json = await cat(hash);
  return deserializeDatabase(json);
};



Here, IPFS doesn't know the location of our database file, so it reaches out to IPNS and waits for a reply, IPNS finally responds with a hash, here’s a closer look at the getCurrentHash function:

const getcurrentHash = async () => {
const nameServiceUrl = process.env.WEB3_NAME_SERVICE_URL;//https://name.web3.storage/name

  if (!nameServiceUrl) {
    throw new Error("WEB3_NAME_SERVICE_URL is not set");
  }

  const res = await fetch(`${nameServiceUrl}/${process.env.DB_HASH}`);
	
  return (await res.json()).value; // hash of the latest db file
};



Here’s a closer look at the addNode function:

const addNode = (
  state: Map<string, ApplicationNode>,
  node: ApplicationNode
) => {
  return new Map(state).set(node.id, node);
};



Here’s a closer look at the storeDatabase function:

const storeDatabase = async (state: Map<string, ApplicationNode>) => {
  const json = serializeDatabase(state);
  const jsonDataBlob = new Blob([json], { type: "application/json" });
// adding the file to IPFS
  const hash = await add({ blob: jsonDataBlob, fileName: "db.json" });

  if (!hash) {
    throw new Error("couldn't store database");
  }
// updating the ipns record with the latest hash: refer the next act
  await update(process.env.DB_HASH!, process.env.DB_KEY!, hash);
};



A closer look at what goes on in the add function:

export const add = async ({ blob: Blob, fileName: string}) => {
  // append ?wrap-with-directory=true to the baseUrl to upload a directory
  const baseUrl = `${process.env.INFURA_IPFS_ENDPOINT}/api/v0/add`;
  const formData = new FormData();
  formData.append("data", data.blob, data.fileName);
  try {
    const response = await fetch(baseUrl, {
      method: "POST",
      headers: {
        Authorization:
          "Basic " +
          Buffer.from(
            process.env.INFURA_IPFS_KEY + ":" + process.env.INFURA_IPFS_SECRET
          ).toString("base64"),
      },
      body: formData,
    });
    const hash = (await response.json()).Hash;
    return hash;
  } catch (error) {
    console.error("Error adding file", error);
  }
};



Now, it's IPNS's turn to shine. It holds critical secrets, and only it can access and modify them using its private key, serving as the guardian of the name:

import * as Name from "w3name";
const update = async (ipns: string, keyStr: string, content: string) => {
	if (!keyStr) {
    	return;
  }

  const name = Name.parse(ipns);
  const revision = await Name.resolve(name);
  const nextRevision = await Name.increment(revision, content);
  const key = new Uint8Array(Buffer.from(keyStr, "base64"));
  const name2 = await Name.from(key);
// publishing the next version of the db with the private key
  await Name.publish(nextRevision, name2.key);
};




Wrapping Up

Though it might seem like we reached a seamless conclusion, the journey to this endpoint wasn't always smooth, as those who build often understand. Here are some trials, errors, and potential future challenges:

 * We toyed with the idea of merging traditional methods with newer ones. What if we saved application data in IPFS but stored user details in a web2 database like Supabase? This would simplify authentication and authorization. However, it felt incongruous, akin to powering a Tesla using a diesel generator while believing we were eco-friendly.
 * In our dapp's early version, we aimed to store data for each application in a unique IPFS directory covering data, screenshots, and logos. We'd then publish each to IPFS individually. This strategy resulted in numerous IPFS files. Plus, users had to oversee their IPNS private keys independently.
   
   The intent was to permit updates to a specific application by its creator exclusively. Yet, this approach made it challenging to search for applications, and when we did find them, the process was slow. Managing private keys presented another hurdle. We considered using MetaMask Snaps, which seemed promising, but we shelved the idea due to other prevailing issues.
 * We also experimented with Gun, OrbitDb, and a few other database solutions.

So, my friend, that's how my developer tale comes to a close. I hope you've enjoyed it. If you’re curious to learn more about IPFS and how Infura makes it easy to access IPFS, check out the Infura website and the developer’s guide to IPFS.

Dapp

A Developer's Tale: Building a Database with IPFS

In this blog, we discuss DIN's shift from centralized to federated, championing Web3's vision of digital sovereignty through decentralization.

If you have been following Infura’s journey of creating the decentralized infrastructure network, which we’ve termed DIN, you are aware that in order to progressively decentralize the RPC layer, we are moving from a centralized architecture to a federated one. You can learn more about this work here.

But first, let’s take a step back to revisit some core concepts of web3, the challenges and opportunities each presents and where the DIN fits in as well as the progress the team has made to date. 

Web3 is tricky to define. Is it a blockchain? Cryptocurrency? More privacy and freedom? The answer to these questions is “yes and…”. Web3 is about enabling digital sovereignty and developing new ways to connect and transact with each other using blockchain technology that removes the need for intermediaries. And this is what it looks like at a high level: 


Progressive decentralization is a journey

Decentralization can be thought of as a spectrum along 3 axes: technical, economic, and legal. By legal, what we really mean is governance. On the left, you can see examples of how centralization materializes over these axes. As we move right toward decentralized mechanisms, visibility, participation, and inclusion become increasingly enabled. Governance moves toward DAOs and decentralized roadmaps. Funding and economic incentives move more toward fostering community contributions. The technical side moves along a path that increasingly incentivises collaboration.

Different projects start out in different places along this spectrum and typically have a roadmap of how they want to progressively decentralize. We believe that because we are developing new models, new economics, and new ways of organizing, it can be risky to start at the far right of the spectrum.

Centralization can help stabilize projects that are early in their lifecycle to maintain high benchmarks of quality, ensure consistency of funding, and provide stronger governance. A good compromise to start new projects is through Federation. We start closer to the centralized side of the spectrum, but with core decisions to put the project on a decentralized path. While key elements of decentralization may be absent, there is a clear path on how to progressively move toward the right side. And this is precisely how the DIN is evolving.


The current state of the RPC layer

Now let’s narrow our focus to JSONRPC providers. While there are some providers that take a more decentralized approach, the vast majority of RPC providers follow Infura’s model of RPC as a service. It’s a useful and convenient service but has its challenges as a business. We think of RPC as a commodity business because the RPC is a standardized interface across providers, it starts to become an increasingly commoditized service as more providers enter the market. It has very low switching costs making providers interchangeable. The reality of a commoditized business is great for the customer as providers must drop prices to razor-thin margins in order to compete with each other.

In commodity businesses, the only way to succeed is to consolidate the market. A greater share of the market allows for economies of scale to continue driving down the price to win and maintain more market share. It’s a vicious cycle of centralization.

Looking at the provider space with the lens of the web3 ethos, it suffers from all of the common centralized issues: they tend to be single points of failure and are susceptible to availability issues, whether that’s due to technical issues, regulatory issues, or specific provider limitations. 

There is also an adversarial relationship between all of us providers. We are all doing very similar things to provide service, but there is a lot of wasted effort recreating our respective stacks. Infrastructure providers limit themselves by avoiding collaborative efforts to deliver a key service to the ecosystem.

So, given all of that talk on web3 ethos and decentralization, where should the infrastructure provider community go?


DIN: The path forward for a decentralized RPC layer 

For the past 7 years, Infura has been providing RPC as a service, but through the traditional mechanism, we are all familiar with - giving tools to developers, which is Saas.

Over the last few years, we really felt like it was a challenge for us to keep up with the amount of networks that were being added and at the same time the way that developers were interacting with us was changing. In the beginning, people were running their own nodes and maybe they were splitting traffic at some point and doing a combination of using Infura and running their own infrastructure. Later down the line,  they might have just decided that was not worth the pain and effort to run their own infrastructure and they were solely relying on us.

Over time, a whole ecosystem or industry of RPC providers popped up where there were many other providers serving the same networks that Infura was providing and people started to go the route of  - instead of running their own infrastructure they would use multiple providers.

Our goal has always been and will continue to be ensuring that any developer can gain access to production-ready and reliable Web3 infrastructure. Achieving 100% uptime requires a wider network of node providers to handle requests in the kind of extreme volumes we saw in past congestion events.

So to go back to the initial question - where should the infrastructure provider community go? Towards decentralization. A decentralized infrastructure network could help prevent things like outages while also providing shared uptime, wider access to new networks and a more reliable experience overall. It could also mean zero downtime.

Our approach to decentralized RPC is creating a system or a network that allows providers to generate revenue and customers can get an endpoint that is similar to their current experience - here is one endpoint that you can go to that is always on, connecting you to many different blockchains while behind that the traffic gets served by a network of providers as opposed to a single source.


Network roles and functions on DIN 


Right now we are still in the early stages of bringing this vision to life, but we have a clear path set ahead of us. The primary roles that we have envisioned for the federated state:

Ingress Operator - one or more agents who accept payment from a consumer and take responsibility for optimally routing requests to the network.

Node Provider or Operator - a reliable and robust service provider who can serve high-throughput requests at an agreed-upon quality of service.

The Watcher - reports degraded service with evidence and periodically tests node operators' performance anonymously. The goal of the watcher is to maintain the quality of service standards consistent across the network.


Let’s talk about what the current node operator journey looks like in the federated state. Bear in mind that as we are growing and progressing in this journey, this might change in order to accommodate any new requirements. 

Just to recap, when we say node operator, we refer to a participant in the federated network that is a service provider that can serve high throughput requests. They are in this for profit and they are amicably competing with the other DIN operators on quality of service.

As a prospective DIN partner, the first step you will go through is an onboarding session with some of the DIN team members where we will dive deeper into what DIN is, and what your responsibilities and requirements to participate in the network would be.

Next, we need to benchmark your capabilities in order to understand what kind of loads you can handle. The DIN team has put together a set of acceptance criteria for prospective partners which we will talk in more detail about further down in this blog. In a nutshell, there will be a set of tests run on your endpoints in order to determine what your current capabilities are. This helps us understand what are your strengths and weaknesses and where you would best fit within the federation.

Once benchmarking is done and the service agreements between the node operator and the federation are in place, you can start receiving failover traffic from other partners. If all goes well, the next step will be to optimise traffic from other partners. What we define as optimized traffic is the following: instead of having to scale up your own infrastructure when surges in traffic happen, you can just route the surplus traffic to one of the DIN partners, ideally maintaining your resources at a baseline level constantly. This can have so many benefits: easier to predict running costs, increased quality of service, minimized risk of production incidents.


Network acceptance criteria for infrastructure operators in a federated state 

Now, let’s talk about acceptance criteria. You might have noticed there that this is the second iteration of the acceptance criteria set. That is because, 2 weeks ago, we had the second in-person DIN partner meetup in New York. Let me just say that being in the same room with so many different and talented people all aligned on a vision has been truly inspiring and energizing. 

One of the topics we discussed was ways in which we can improve the initial acceptance criteria set we had in order to better understand a partner’s capabilities and to get a more robust understanding of their strengths and weaknesses.


As a result, we have agreed to benchmark prospect partners on 6 different criteria.

Availability of methods - in this federated state, we want to ensure that you can support the same methods that the majority of the partners can support. This is so that you can receive the failover or optimized traffic that I was talking about previously.

Latency - we will do a stress test approach where we will send different loads incrementally to determine where your system stops performing optimally. Of course, the rule of thumb here is that lower is better.

Consistency - there are different levels of testing consistency but for this initial federated state, we just want to verify that your nodes are consistent between themselves.

Max Gas Cap - we want to make sure you can support eth_calls at a certain threshold over the EVM block gas limit.

Sensible error response - we want to ensure consistency in error handling across partners for a seamless user experience.

Correctness - we are checking block number monotonicity. Again there are different levels of correctness, but for this stage, we just want to make sure that the new block number >= previous block number queries.


What’s next for the DIN team?

In conclusion, whether you're a seasoned Infura user or simply following our journey, the future holds exciting prospects. For our valued customers, a seamless experience remains our top priority, with enhanced reliability, improved uptime, and consistent performance on the horizon.

We're committed to demonstrating how this network will bring immense value to both customers and providers. The Federation will persistently welcome new partners, refining our acceptance criteria, and fortifying failover mechanisms, while advancing optimized traffic and inter-partner routing. As we continue to evolve, make sure to stay tuned for the innovative developments that lie ahead in the world of DIN.

If you're eager to delve deeper into the topics discussed in this blog, we invite you to check out our Smartcon 2023 talk. It provides an in-depth exploration of these subjects. You can view it here.

Infura

Progressive decentralization part 2: Evolving DIN through federation

Learn how to deploy a simple ERC-1155 smart contract using MetaMask, Infura, Linea and Hardhat to power a web3 RPG.

Heyo, this is Emily, your friendly developer advocate from Linea, here to get you excited about web3 gaming! In this tutorial, we’ll be talking about the ERC-1155 Multi-Token standard and how it gives developers the flexibility of supporting multiple fungible, semi-fungible, and non-fungible tokens in a single contract: allowing builders to gas-efficiently create new use cases to build out the Linea ecosystem. At the end, we’ll deploy a straightforward ERC-1155 contract using MetaMask, Infura, Linea and Hardhat to power the beginning of a cat-centric Web3 RPG.


Prerequisites:

 * Understanding of EIPs and ERCs.
 * Understanding of  ERC-20.
 * Understanding of ERC-721.


The What’s and Why’s of ERC-1155

In order to explain ERC-1155, it’s easier to start by explaining the limitations of ERC-721s and ERC-20s in the context of Web3 games.

In a standard RPG, you might have different types of fungible tokens - gold, silver, and copper - as well as hundreds of types of non-fungible tokens - swords, armor, and shields. In a world without ERC-1155, each one of these tokens would have to be a separate contract. Then, if you wanted to trade items and money, you’d have to initiate a separate transfer transaction for each individual token contract. Imagine how expensive that would be!

So, to trade 1 horse for 2 gold, 1 silver, and your finest sword, you’d have to:

 * Execute a transfer of 2 gold on the gold contract.
 * Execute a transfer of 1 silver on the silver contract.
 * Execute a transfer of the finest sword on the sword contract.
 * Execute a transfer of 1 horse from the horse contract.

That’s 4 transactions for conceptually just one trade (potentially 8 depending on how you decide to execute smart contract approvals for transfers)! When gas prices are high and transaction times are slow on Ethereum, imagine how expensive and painful that would be.

This is where ERC-1155 comes into play, allowing multiple tokens to be defined in a single contract and multiple tokens to be exchanged through a batch transfer in a single transaction.

WOW.


But wait, what’s this about semi-fungible tokens?

ERC-1155 is cool because it allows for the creation of semi-fungible tokens, which at its core is a token that has fungible and non-fungible properties.

For example, entry tickets to an event are often cited as semi-fungible tokens. Before the event date, entry tickets are essentially fungible - there are no unique properties as one entry ticket could be exchanged for another. However, once used it has the potential to be turned into some type of memorabilia.

In the game we’ll be building, one example of a semi-fungible token is what we’re calling a Schroedginer box. Initially, there is nothing unique about any of the boxes - they’re completely fungible. However, once opened, they can take on non-fungible properties - potentially becoming incredibly rare or incredibly common NFT (but I promise no dead cats).


How does metadata work?

If you’ve created an NFT before, you might be used to creating a new URI on IPFS with metadata for each NFT. In the case of ERC-1155, there’s an optional metadata extension, which relies on a substitution mechanism to use the same URI for all token types. Because we are only storing on URI, we can save significant gas costs. This substitution mechanism allows clients to replace an {id} property in order to represent all the different metadata for each NFT.

We’ll go over different strategies and how to upload data to IPFS for multiple token types in part 2. For now, this serves as the end of the introduction, and we’ll get on to deploying a very simple contract!


Let’s get building!

In this tutorial, we’ll be deploying a contract on Linea, an EVM-equivalent ZK-rollup that helps lower gas fees and speed up transaction times. Because it’s EVM-equivalent, the process is no different from deploying on Ethereum!

You can find more information on the Linea website.

In order to deploy a smart contract, you’ll need to do a few things:

 * Setup Hardhat: a development environment for writing, deploying, and testing your smart contracts.
 * Sign up for Infura: an RPC provider to help connect your dapp to Linea.
 * Install MetaMask: a self-custodial wallet.
 * Get Linea ETH: required for making transactions on Linea.
 * Install VS Code (or your favorite code editor).


Create a Hardhat project

In order to get started, open up your terminal and create a new folder called “kitten-collect”. Navigate into this folder and run the following command to create a new Hardhat project.

npm init
npm install --save-dev hardhat
npx hardhat init



Select “Create an empty hardhat.config.js” with your keyboard and hit enter.


Write the smart contract

Rather than implement an ERC-1155 contract from scratch, we can use OpenZeppelin’s ERC-1155 contract as a base. To do so, go ahead and install OpenZeppelin’s contract library:

npm install @openzeppelin/contracts



Create a new directory called “contracts” and create a file inside the directory called “KittenCollectItems.sol”.

Now, to utilize the OpenZeppelin contract, add the import statement at the top of the file and have your contract extend ERC-1155 like so:

import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";


// SPDX-License-Identifier: MIT
pragma solidity >=0.4.22 <0.9.0;


contract KittenCollectItems is ERC1155{
constructor() public {
}
}



In this game, we’ll have three types of token assets:

 * CAT_NIP: This is a fungible token, representing our in-game currency that can be used to buy non-fungible and semi-fungible tokens in the game.
 * CAT_TOY: This is a non-fungible token, representing toys like scratching posts and laser pointers.
 * CAT: This is a non-fungible token, representing different cats you can own.
 * SCHROEDINGER_BOX: This a semi-fungible token, representing interchangeable, indistinguishable loot boxes that once opened, contain cat toys, cats (all living), or nothing at all.

As mentioned above, the metadata for each token needs to be associated with an ID. We’ll go over actually uploading and structuring your metadata in part 2, but for now, we’ll just put in a dummy string. Again, since this is the simplest iteration of our web3 RPG, we’ll also just associate a single unique ID with each token type. Change your code to look like this:

import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";

import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";


// SPDX-License-Identifier: MIT
pragma solidity >=0.4.22 <0.9.0;


contract KittenCollectItems is ERC1155{
uint256 public constant CATNIP = 0;
uint256 public constant CAT_TOY = 1;
uint256 public constant CAT = 2;
uint256 public constant SCHROEDINGER_BOX = 3;


constructor() ERC1155("https://kittencollect-example/api/item/{id}.json"){
}
}



Note that we removed the public visibility modifier on the constructor. If we were to leave it there, we would get a compilation error Warning: Visibility for the constructor is ignored. If you want the contract to be non-deployable, making it "abstract" is sufficient.

This is because constructors are only called once on contract deployment, so there’s no need to add a visibility modifier to the function.

In this tutorial, we’ll just be sending assets directly to the contract deployer by minting tokens upon contract deployment - specifically, 1000 catnip, 1 cat toy, 1 cat, and 5 Schroedinger boxes. In future iterations, we’ll move the minting mechanism into separate functions to mint specific tokens to player addresses as well.

In our case, since we’re minting multiple token types, OpenZeppelin offers a _mintBatch function in their implementation of ERC-1155 structured as follows:

_mintBatch(address to, uint256[] ids, uint256[] amounts, bytes data)



So, to mint our tokens, we’ll match our designated IDs to the amount we want to dispense to the address of the deployer:

import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";


// SPDX-License-Identifier: MIT
pragma solidity >=0.4.22 <0.9.0;


contract KittenCollectItems is ERC1155{
uint256 public constant CAT_NIP = 0;
uint256 public constant CAT_TOY = 1;
uint256 public constant CAT = 2;
uint256 public constant SCHROEDINGER_BOX = 3;


constructor() ERC1155("https://kittencollect-example/api/item/{id}.json"){
uint256[] memory ids = new uint256[](4);
ids[0] = CAT_NIP;
ids[1] = CAT_TOY;
ids[2] = CAT;
ids[3] = SCHROEDINGER_BOX;


uint256[] memory amounts = new uint256[](4);
amounts[0] = 1000;
amounts[1] = 1;
amounts[2] = 1;
amounts[3] = 5;
		
_mintBatch(msg.sender, ids, amounts, "");
}
}



Now that we’ve got the basics of an ERC-1155 contract down, let’s actually deploy it!


Write the migration script

In order for Hardhat to understand how to deploy a contract, we need to give it instructions under the script folder. Create a file called deploy.js and add the following code:

async function main() {
  const [deployer] = await ethers.getSigners();


  console.log("Deploying contracts with the account:", deployer.address);


  const token = await ethers.deployContract("Token");


  console.log("Token address:", await token.getAddress());
}


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




Deploy your smart contract

In order to deploy to a live network, you’ll need to add the Linea RPC URL to your hardhat.config.js. But, how do you get that?

First, you’ll need to sign up for an Infura account:

Then, create an API key, choosing Web3 API for your network type, and copy the API key - you’ll need that for later:

In order to deploy, you’ll need to add this API key and your wallet’s secret recovery phase into your hardhat.config.js. However, this is incredibly dangerous, as you don’t want to expose that information by accidentally uploading it to GitHub. Start by creating a .env file and a .gitignore file in your root directory.

Add the appropriate information to the .env file, inputting your secret recovery phrase as the mnemonic:

SECRET_RECOVERY_PHRASE=<YOUR SECRET RECOVERY PHRASE>
INFURA_API_KEY=<YOUR INFURA API KEY>



Then, make sure to add this line to your .gitignore:

.env



In order to use these environment variables in your hardhat.config.js and deploy, you’ll need to install:

npm i -D dotenv



Then, in your hardhat.config.js, add the following code:

require("@nomicfoundation/hardhat-toolbox");
require('dotenv').config();

const { SECRET_RECOVERY_PHRASE, INFURA_API_KEY } = process.env;

module.exports = {
//...cont



Then, you’ll want to configure the Linea network under networks, using the new environment variables you’ve configured:

module.exports = {
solidity: "0.8.19",
networks: {
	linea: {
		url: `https://linea-goerli.infura.io/v3/${INFURA_API_KEY}`,
              accounts: [SECRET_RECOVERY_PHRASE]
	} 
     } 
};



Finally, we can deploy your contract! Remember that you’ll need to fund your wallet with Linea ETH, using either a faucet or bridging ETH from Goerli to Linea Goerli. Call this from the CLI:

npx hardhat run scripts/deploy.js --network linea




Start building on Linea with Infura

Congrats! You’ve deployed an ERC-1155 contract on Linea using Infura! If you get stuck or have questions, please find us in Discord. Also, don’t forget to follow us on Twitter to find out about part 2 of building a web3 RPG.



ERC-1155

Building a web3 RPG Part 1: Deploy an ERC-1155 Multi-Token Smart Contract

Palm, an Ethereum sidechain, is transitioning to a Polygon CDK-powered Chain to enhance its operations and expand its range of use cases.

Palm, an Ethereum sidechain originally focused on the buying, selling, and trading of NFTs associated with digital and real-world assets, has transitioned its testnet to the Polygon ecosystem by utilizing the Polygon Chain Development Kit (CDK), following the merger of Candy Digital & Palm NFT Studio.

This migration positions the Palm network to better provide dapps with increased speed, security, and scalability, making it well-suited for high-traffic applications like gaming, social media, and e-commerce.

Infura is currently supporting Palm through this migration by using a 3rd party partner to give developers seamless access to this network.

The former Palm endpoints, which went live on Infura in June 2021 have since then garnered a total of 7.2 billion lifetime requests.


Benefits of Palm for Infura developers

Some of the benefits of Palm network transitioning to an L2 are:

 1. Improved speed, security and scalability: The L2 Palm network will offer high speed, security, and scalability to dapps.
 2. EVM-compatibility: Developers can now write and deploy EVM-compatible DeFi applications on the Palm network using popular Ethereum libraries, tooling, and development tools.
 3. EVM-compatible NFT marketplace: This migration also makes it possible for Palm network to onboard both primary and secondary NFT marketplaces with full minting capability.


What do Infura developers need to know?

Infura developers are not expected to do anything as all endpoints will remain the same. Although access will be provided via a 3rd party partner, pricing for requests on Palm will align with the existing Infura pricing model.

Palm’s testnet will go live using the Polygon Chain Development Kit on October 2nd. Subsequently, Palm’s mainnet will follow, although this date is yet to be confirmed. We will have further communications once the mainnet is ready.

Infura is committed to facilitating a smooth transition for all our users by minimizing any disruption to operations and providing comprehensive support throughout the migration process. Please check out the Infura documentation for Palm for further information.

Recent Posts (page 2)

The Principles of Web3 UX Design Part 1: Research Best Practices

A Developer's Tale: Building a Database with IPFS

Progressive decentralization part 2: Evolving DIN through federation

Building a web3 RPG Part 1: Deploy an ERC-1155 Multi-Token Smart Contract

Palm Network Scales Up for Enhanced Operations and Broader Use Cases