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

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

Intro

The topic of Non–fungible tokens (NFTs)  is capturing broad interest from people outside of Web3:  popular media, celebrities, traditional business, social media influencers, and more. With all of the hype around multi-million dollar trading prices and “insert your favorite celebrity” shilling NFTs, it’s easy to get lost in the headlines. With this post, I hope to provide background on NFTs, some of their lesser known use cases, and some of the developer pains around NFTs. We will use Replit to create an NFT collection and give you practice minting your own NFTs.


Generally speaking, one of the least understood parts of NFTs is the word non-fungible. If you already have a firm understanding of this, well done! To get all of us on the same page, let’s define it here. I’ll first start with the definition of “fungible”. A dictionary.com defines it as:


“being of such nature or kind as to be freely exchangeable or replaceable, in whole or in part, for another of like nature or kind.”


In other words, fiat currency, ERC-20 tokens, and M&M’s are fungible. Any one of a like-kind can serve as an equivalent replacement for the other. Non-fungible describes a uniqueness both in form and value in which they cannot replace each other. Baseball cards, real estate property like your home, and cats are non-fungible. It is logical that digital collectibles are an obvious use case for NFTs. The uniqueness and rarity of a particular NFT can drive value amongst a group of collectors.


Background

According to the dates on the EIP list, the proposal around NFTs came around 2018 with ERC-721. With a lot of the focus on fungible tokens in years previous, this proposal started discussion around use cases for non-fungible tokens. The idea of a digital token representing uniqueness has a broad number of use cases that extend well beyond the current trend of digital collectibles.


 * Physical world value representation (deeds)
 * Negative value assets (debt paper)
 * Unique representation of ownership (rights from ownership)
   

As developers started exploring the NFT world, a number of extensions have been proposed ERC-1155 (MultiToken), EIP-2981 (Royalty Standards), EIP-3569 (Sealed MetadataURI standard)  EIP-3754 (Generalized NFT Standards),  EIP-3589 (Fungible Asset Collections).


With projects such as BAYC, CryptoPunks, and EulerBeats exemplifying the most popular projects, it’s hard to separate the idea of NFT from digital collectibles. Although digital collectibles is the dominant use case, it should be noted that NFTs can be used in much more broad applications.


One example of a non-digital collectible NFT is ENS domains. As of 2019 ENS became ERC-721 compliant. That means that domains can be transferred exactly the same as other NFTs. You can even trade them on OpenSea! While there are some differences between how an ENS domain is implemented compared to your favorite Bored Ape, you can trade them on open NFT marketplaces the same way.


As many of the projects today focus NFTs on digital art, that will be the use case we explore in this post. On with the show.


Developer Concerns

When starting an NFT project from scratch, there are a number of decisions and risks you have to consider. I’ve outlined a few here.


Let’s start with the contract. ERC-721 and ERC-1155 (and some of the extension standards) define a standardized interface you need to implement to be compliant; they say nothing about the implementation details. This means that if you develop a contract from scratch you should have it reviewed before deploying it and sending real value through it. To complete this part you need to learn Solidity, learn how to do a security audit on it (or hire a professional group like Consensys Diligence), and then deploy and hope for the best. If you have a bank roll, maybe you would want to offer a bounty for post-launch auditing.


Another set of decisions has to do with the collection itself. Are you going to do generative art (art produced by a renderer based on the metadata)? Is it going to be a collection of original art like Damian Hirst’s The Currency? Is it pregenerated? Dynamically generated? Either way, you have decisions to make as to what you want to represent and how you want to compile the metadata. This metadata is eventually going to be referenced by your contract’s tokenUri and be permanently immortalized on the blockchain. No pressure.


So, you got your assets together? Great! Now you need to decide on a place to store it. Will it be centralized, decentralized, or on-chain?


There’s a number of ways you can store your metadata. The ERC-721 spec calls for metadata to be stored in a tokenUri field in the contract. Anything that qualifies as a URI could technically work: https://, ipfs://, data-uri;, etc. There is some debate as to which is the best method. Storing on a centralized hosting provider (S3, web hosting, etc) is best, said no one ever, so we can cross that off the list straight off. Seriously speaking, centralized hosting runs the risk of going offline if the hosting provider is censored, a self hosted web server crashes, or someone forgets to pay the bill. It’s best not to risk that.


Some say that encoding it to a data-uri is best because it keeps all of the data on-chain and not reliant on additional storage technologies. While it does simplify the technology stack and has the benefit of getting the data in a single call, it comes with a higher gas cost and some inflexibility.


Some say IPFS is best because it gives you a content addressable URI (guaranteeing the content won’t change) and it’s off chain, so it saves on gas costs. We will be using IPFS in this blog post through Infura’s IPFS API. Whichever you pick is up to you and will be great. Except for the central storage idea. That one is not ok.





Now that you have all of that together, you have to send all of the transactions to mint. This is fine to put together manually if you are only minting a handful of NFTs. But what if you are dropping 10,000? How do you manage all of those transactions? While that is beyond the scope of this post, it is something you need to consider with larger NFT projects.



Get to the Minting Part, Already


Working with Replit

Replit is a browser based working environment. It allows for real time collaboration on a project and can be used for exploring ideas. All you need is an internet connection and a web browser to start collaborating on a project.


Replit makes it easy to start with a template and start jamming on code. Even better, you can share a link and mob program the project all in real time! Let’s get started by forking  this REPL.


Once we fork it into our account, we can dig in. The REPL we are working with is based on the public Solidity template with some extra tools geared toward the NFT use case. The template provides an easy way to connect a wallet, write and deploy contracts, and includes some CLI tools to help manage the creation process.



Starting With the Contracts

Writing contracts can have a steep learning curve: learning solidity, avoiding security risks, and understanding how to call and build on top of them. For standard contracts like ERC-721 / ERC-1155, there are open source libraries like OpenZepplin.  If the out of the box contracts don’t fit your project, you can still write your own contracts and get a security audit from Consensys Diligence and be assured that your contracts are secure. The REPL comes with 2 OpenZepplin contracts as a starting point: one for ERC-721 and one for ERC-1155.


Let’s customize this contract, then deploy it. Going for simplicity (and a no cost testnet), let’s implement an ERC-721 token on the Goerli testnet. There are 2 fields that are part of the contract that need to be filled out on creation. We have to give our token collection a name and a symbol. Since I have a small collection of badly made memes for this blog, I’ll use the name “Bad Meme Token”, and symbol “BM”. Seems like a good name for this token. With that out of the way, let’s deploy.


Now that we have the contract deployed we can get on prepping our tokens. It’s super easy in the REPL. The REPL gives us simple and easy access to make contract calls and send transactions to the network. All you have to do is customize your contract, connect your wallet, connect to Infura IPFS, and start deploying!


Create the assets on IPFS

As stated before, we will use the Infura IPFS API. All of the minting we are going to do in this blog post fits within the Free Plan, so you don’t need to be on a paid tier in order to experiment with minting NFTS.


The REPL gives us an easy way to manage the IPFS assets. In the template there is an assets folder. For all of the images we want to manage as an NFT, we first need to upload them to IPFS.

 1.  Create an Infura account (if you don’t already have one)
 2.  From your dashboard, hit “Create a New Project”
 3.  Select IPFS and fill out the project info
 4.  Take note of your project ID and Secret
 5.  Enter the Project ID and Project Secret into the REPL’s secrets manager as PROJECT_ID and PROJECT_SECRET
 6.  Open the REPL Shell
 7.  Enter the command npm run ipfs -d ./assets -g *.jpg
 8.  Take note of all of the CID URLs (you will need this for the metadata generation)
 9.  Using the CID URLs, generate and upload all of the metadata URLs.
 10. For each of those URIs generate the NFT!

There are some variations on how to do this and manage NFT assets on IPFS, but this is the simplest version. For the next level, look into managing a directory of assets in IPFS!


Gather the metadata

Ok, now that we’ve finished the initial asset storage it’s time to create the NFT metadata. NFTs need to have a metadata url associated with it. This needs to be a web compatible URL and can take one of 2 basic forms: An http url pointing to a storage solution (like IPFS) or a data-uri that is encoded and stored directly on-chain. While there are a lot of benefits with the data-uri direction, it is less flexible and more expensive than managing it with external storage. We’ll focus on the former for this tutorial.


Since we are doing a digital collectible, we assume that we want to have it appear on OpenSea so we can sell it for 100 ETH! OpenSea has metadata standards it recommends so we can easily display it in the marketplace. The metadata part is simply a json file that represents some descriptive data as well as the attributes (that help make the NFT unique). Using the image url’s we generated in the last step, we can create a json file like the following:


Once we have all of the JSON files created and on the filesystem, we can use the same ipfs utility to upload them to IPFS.


npm run ipfs -d ./assets -g *.json


We make note of all of the new URLs from the JSON upload process. That’s it! We’ve prepared everything that we need to mint our NFTs!



Mint all the things

Back to the REPL! The UI allows us to easily call contract methods and fill in all of the metadata without having to code it up. In the UI, locate your contract and click to expand the methods.  Locate the “mint” method. Enter the address of the recipient (put in your own address, unless you have a collection of addresses you want to mint to). Copy and paste the IPFS URL in the tokenURI field. And then:




BAM! You have achieved NFT. Congratulations.



Final Thoughts

We’ve stepped through some basics on how to mint some fresh NFTs using OpenZepplin, Replit, and IPFS on Infura. We’ve even created an entire BM collection! Now that you have the basics of minting an NFT, there are a number of topics you can explore further. Some examples include exploring novel use cases for NFTs, fractionalizable NFTs, how to manage a token drop, and using NFTs as a proof of ownership for other on-chain adventures. And because we've explored creating an NFT project from a beginner's perspective, there's still a lot of scope for you to play with. If you're interested in something more out-of-the-box, with quick-start features like a white-label storefront, support for fiat payments and email-based redemption flows, check out ConsenSys NFT. I hope this post can serve as an inspiration and a bit of hands on experience for your next world changing project. If you end up launching something, tweet us @infura_io!!!

Minting NFTs with Infura and Replit

Infura is going to ETHDenver and we can’t wait to meet you! Our friends at Truffle and ConsenSys Diligence will be there too! Here’s a rundown of all the action, including how to receive a free 3-month subscription to Infura and more…




Tech Talks & Workshops



Demo: Build the Future of Web3 Faster and Easier - New Tools and New Features

Feb 12 at 1pm, Art Hotel Ballroom, Art Stage

In this demo-packed session, Marc Mercuri, SVP of Developers at ConsenSys, shows how anyone with an idea can be a blockchain developer. From low code to pro code, this session debuts new features, tooling, and demos using Infura, Truffle, QBS, Nethereum, Visual Studio Code, Power Platform, Adobe Creative Cloud, and more!


Dev Hack Mixer
Feb 16 at 1pm - 5pm, Mirus Gallery Loft (Upstairs, 2nd Floor)

Come hang out with us at this ConsenSys mixer. Learn more about our developer tools, bounties, and more! Get inspired by special Web3 panels with music and munchies.


HYDRA - ETHDenver’s Official Opening Party

Feb 17 at 2pm - 2am, Wings Over The Rockies Air and Aviation Museum

A world-class, NFT-integrated sound system experience presented by Charged Particles and Dragonfire Acoustics is the best way to kick off your ETHDenver weekend! ConsenSys is an official sponsor and we’re looking forward to seeing you there for talks, panels, and live art before the HYDRA awakens and lights its fire long into the night.


Workshop: Deploy Your Own NFT with Infura, ConsenSys NFT and Replit

Feb 17 at 2:20pm, Art Hotel Ballroom, Art Stage

Kristofer Shinn, Director of Engineering at Infura, will show you how you can deploy your custom NFT in minutes using the combined power of Replit's browser-based code editor, Infura's infrastructure platform and the ConsenSys NFT platform.

Tech Talk on Blockchain Infrastructure

Feb 18 at 10am, Sports Castle, Main Stage

Eleazar “E.G.” Galano, Co-Founder at Infura, talks about blockchain infrastructure.


Panel on the Challenges of Scaling Blockchain APIs

Feb 18 at 12:50pm, Sports Castle, Main Stage

Eleazar “E.G.” Galano, Co-Founder at Infura, along with Nader Dabit from the Graph and Cuautemoc Weber from Gateway, will discuss the challenges of scaling blockchain APIs, with Clarissa Watson, Senior Technical Writer at ConsenSys, moderating.


Panel on smart contract security for Ethereum

Date and time TBC, ETHDenver 2022 Buidlathon, Sports Castle

Diligence will moderate a panel on the state of blockchain security.


Hackathons: Build, Test, And Deploy With The Leading Web3 Stack


Up for a challenge?


Take part in the bounties from Truffle in collaboration with Chainlink or ConsenSys Diligence at the hackathon! The physical hackathon runs February 17th to the 20th and the virtual hackathon runs February 11th to March 21st.


No matter what stage of development you’re at, we got you covered. Developers using Infura have access to best-in-class tech stack and seamless integration with Web3’s most popular decentralized wallet, MetaMask. Start building your journey with Truffle’s integrated development environment. Detect vulnerabilities in your smart contract before you deploy with ConsenSys Diligence.


Connect with us and get help with your hackathon projects on ETHDenver’s Discord at #consensys-devtools.




Come Hang Out


Booth & Helpdesk

Feb 17 - Feb 20, Booth M13, Floor 2, Shill Zone, Sports Castle

Visit our booth at EthDenver for help and demos from our technical experts at Infura, Truffle and Diligence. Infura is giving away free 3-month team subscriptions valued at $225 per month that supports 1M requests per day to every single visitor! Other goodies include:


 * Limited edition swag
 * Hackathon mentors to assist all BUIDLers
 * Mini design tutorials taught by our talented designer, Sam An
 * Product experts to answer all queries about our developer tools
 * Demos and bonus material related to our workshops
   
   

Stay Updated On Twitter


We can’t wait for you to explore all the wonderful events we have lined up for you! We want to see you build the next big thing in Web3 and look forward to connecting soon. For more information and to stay updated on all events, please follow us on Twitter: Infura, Truffle, Diligence. See you soon!




News

Infura Is Going To ETHDenver! See you there!

2021 was a big year for Infura and with 2022 ahead, Infura’s general manager Michael Godsey takes us from the early days to what the company is focused on today.


Infura launched at DevCon in 2016 and as you can see from A Brief History of Infura, we’ve come a long way. We now count a community of over 400,000 developers, which signifies both our quick growth and our commitment to making Web3 as easy to build on as Web2. This has always been our mission and will continue to be our north star: providing developers with the tools they need to ship.


Looking back means acknowledging how far we’ve come as a team and evaluating the performance of the Infura platform. We are grateful to each and every developer who chooses Infura as their infrastructure provider and are ready for the new opportunities and challenges 2022 will bring. Our constant exploration of how we can serve our community better is what makes Infura a leader in Web3 development. In this post I’d like to share a bit about my history, experience, and thoughts on what makes Infura so important to realizing the Web3 vision.


Early Beginnings

My dad was a programmer and I was born and raised in a computer family. This led me to complete a degree in mathematics, then a master's degree in video game design and production, and my first job at EA Games. It was at EA that I learned about game creation, programming, and the complexity of developing software. For me, gaming is about exploration, solving challenges, and expressing your creativity through archetypes like antagonists, heroes, and survivors. Gaming also connects people and creates community. Web3 is no different. In Web3 we have users who join a shared environment and interact with it to achieve their goals.


From Gaming to Web3 Infrastructure

I have always focused my time and energy on understanding the developer mindset. Never losing sight of the developer experience has helped me have a “first principles” approach to product design and continuously ask the deeper questions that solve design challenges so that Infura is the number one tool developers choose to build with. And while it all started at EA, a pivotal point came when I got a call from my friend and former co-worker, E.G. Galano, who was creating a company in the exciting new world of Ethereum.


I sat down with E.G. Galano, the co-founder of Infura, and immediately connected with his strong perspective of Ethereum from the developer standpoint. Ethereum was new and very exciting and with Infura, we wanted developers to explore its potential and make their ideas a reality.


Our focus has always been to give developers the tools and then watch how they disrupt the market. Infura has seen massive growth and change since its early days when I joined but one thing has never changed, our mission to make building apps on Web3 easy for everyone.


Web3 Evolutions That Have Guided Us

Over the last five years our understanding of Ethereum has shaped our focus to create a similar interface for other blockchains and protocols. Some of the most notable Web3 evolutions that have shaped Infura’s product roadmap are MetaMask and Polygon.

MetaMask

MetaMask is the first Infura customer. It’s also the most used app and wallet in Web3, connecting millions of users on Web3 everyday. We saw Metamask grow exponentially during our partnership that demanded a lot from Infura. Every infrastructure piece was built to ensure that it could keep up with MetaMask’s user growth, resulting in high-performance, scalable APIs very quickly.


With MetaMask as our customer, we created libraries, tutorials, and other developer resources that enabled developers to learn exactly what we were learning. Our investment provided not only free infrastructure but also shaped our approach in the developer educational lifecycle, during the early days of Web3, and enabled developers to experiment with Infura and innovate in a highly competitive, ever-changing Web3 landscape.

Polygon

Another important inflection point was when one of Polygon founders, Jaynti Kanani, came to us as a student. He was working on a very cool project called Dagger and was making some complex API calls that required an upgraded plan. We recognized the exciting work he was bringing to the ecosystem and got him set up on a special free student account, so he could experiment, unrestricted. We had no idea what Jaynti had brewing in his brain and it has been amazing to see the meteoric growth that he and the team have created with Polygon. Since adding Polygon APIs, the Polygon network on Infura has grown 3000%.


Polygon is a protocol for building and connecting Ethereum-compatible blockchain networks. It currently supports over 7,000 dapps using Infura, as of end-January 2022. The scaling solutions they’ve been able to build using Infura have contributed enormously to Ethereum’s growth and today, Polygon is now one of the leading side-chains in Web3 and a great addition to the Ethereum ecosystem.


We are inspired by Polygon's growth and believe it shows Infura's value and position in the market to allow developers to experiment with and over time, inevitably create successful products that advance Web3. Our decision to offer a freemium model is to assure developers we are here to stay and support you at any stage of your Web3 development journey, from ideation to product-market fit.


What Infura is Focused on Today

Infura’s growth has always been steady even through the many cycles of crypto winter. We see more and more developers coming to the platform to create projects that we couldn’t even imagine ourselves. Today, our focus remains to provide developers with the tools they need to ship. The challenge is to provide a platform that truly makes building easy and this motivates us. We welcome your feedback and collaboration in order to do this.


With the most recent updates to the platform including analytics, notifications, and the improved dashboard, developers can now better understand the data patterns in their projects that lead to growth, scalability, and a better UX for their customers. For Infura, it means that today, we can not only focus on core infrastructure, but also create more abstracted APIs and features, based on the emerging application and development patterns. These will allow developers to solve Web3’s biggest challenges and onboard even faster.


What Does 2022 Look Like for Infura?

2022 for Infura is looking very exciting! From the Merge, MetaMask, and DeFi applications, we’ll be busy!


Right now, we’re getting ready to embed Ethereum’s merge to Proof of Stake and provide the tools to developers who will be interacting with the new Consensus and Execution Layers (formally Ethereum 2.0) later this year.


Another core focus is to enable MetaMask to become an everyday tool for everyone interacting with the blockchain and to onboard early adopters by giving them a better developer experience. And since DeFi is here to stay, we believe MetaMask will become part of almost every person who uses DeFi and who are working actively with MetaMask to bring simpler, safer, and clearer experiences for users.


As for our team, we are more ecosystem-aligned, as we aim to provide a better user experience to best unlock the protocols for both mid-adopters and early adopters. NFTs will also play a big role this year, with major gaming companies showing interest in integrating Web3 in their games, unlocking new game mechanics, including a better marketplace and transferability. We’ve barely scratched the surface of NFTs, when it comes to implications on cross-entertainment mediums.


Infura’s focus is to grow every day by improving our platforms to ensure it remains the number one choice of developers. I strongly believe in Web3 and in how it will shape the future.


Infura is growing! With 30+ openings across the board, you can join us here or start building your Web3 project on Infura for free, here.

What’s ahead for Infura in 2022?

With the new year kicking off, we wanted to bring you on a journey of how we started Infura and some of the problems we’ve solved since our inception.

Infura has always been focused on improving the developer experience and making it easier for developers to connect to Web3. In this dynamic space, we continuously improve and innovate, adapting to the evolving problems blockchain developers face. What sparked the thought process that created what we know as Infura today?


A Simple Solution for Web3 Builders

When we launched Infura in 2016 at DevCon 2, our goal was to simplify the developer experience and make an impact on the growth of the ecosystem. We wanted to enable developers to bootstrap their Web3 applications and to experiment, without having to take on the burden of running their own infrastructure. Our hope was that more people would build innovative projects on Web3 and drive the rapid growth of the Ethereum ecosystem.

Getting your smart contracts onto Ethereum may seem daunting, especially if you are new to Web3. To build an application on Ethereum, you will need a connection to the Ethereum network. This necessitates operating a blockchain client (node software), which can be costly. It also requires a long initialization period to download the latest data from other peers and may require full-time personnel just to manage the software deployment.

This is why Infura created a zero-maintenance, easy-to-use API for Web3. And the best part? Developers get to choose whether they wish to use just Infura’s API to connect to the network or a hybrid infrastructure model with Infura as their primary provider, alongside an in-house node.

To make things even sweeter, we offered Infura completely free to use, up until around a year ago, when we finally implemented paid pricing for users that require 100,000 API requests per day. Even now, we have a forever-free Core plan. Why do we do all this, you may well ask. Because we genuinely want developers to have the freedom to choose, as well as the freedom to experiment with Web3, without having to first drop a large investment in time and money.


Solving the Problem of Monolithic Ethereum

The Ethereum client has historically been monolithic in its architecture. It has several subsystems that do specific things and are limited in how they can scale in the interest of minimizing operating requirements for users. These subsystems include:


 * Query Interface (JSON-RPC, WebSocket, IPC)
 * P2P Connection
 * Ethereum Virtual Machine (EVM)
 * Chaindata Storage
 * Transaction System
   

In the beginning, the above limitation in an Ethereum client’s architecture was not a problem. Then, along came the huge explosion of popular dApps such as CryptoKitties and massive token launches, both of which made running a single node insufficient and unsustainable in the long term.

So, what happens when you reach the limit of what a single node can do for you?

Due to the monolithic nature of the client, your only options are to run it on a larger machine or add more nodes to your deployment. Vertical scaling only works to a certain extent. The approach is not only expensive but due to the large chain database, it doesn’t always solve the problem.

If there is a bug discovered in the underlying node software, your whole system may become unstable and the fact that your application is bug-free won’t matter. It only takes one part of your sub-system failing, to potentially affect the health of your entire node. Case in point: in 2018, we encountered an issue where, if we received a deluge of websocket subscriptions to one particular node, the node would go into a partially deadlocked state, where it would receive blocks but not publish it to the subscribers.

The only way to deal with that problem at the time was to restart the node. This was not ideal, as we would disconnect not just from subscribers but also from everyone else who was connected to the node. So, Infura and other providers had to come up with custom solutions to stabilize the node software.

To address this inefficiency, Infura created a “cloud client” with a cloud-native architecture. The modularity of this allows us to be adaptable and horizontally scale to fit the needs of the growing Web3 ecosystem. We also developed a variety of microservices that offloaded dependency on the underlying client, and this allowed us to be more resilient to errors, as well as scale better.



Syncing Nodes: Faster, Better, More Efficient

Fast forward to today, the Ethereum client has become more modular, there are light nodes, stateless clients and a huge focus on trying to limit the growth of chain data. Even with the advancements, it still takes quite a while to sync an archive node or a full node. When you are growing rapidly and need more access to these nodes, you will find scaling increasingly difficult.

Back in 2016, it only took a couple of hours to sync our nodes and no additional tooling was required to maintain our infrastructure. As time went on and chain data grew, we switched to using snapshots of Amazon’s Elastic Block Store (EBS) chain data because these periodic snapshots were valuable for failure recovery. Later, we adapted again and started using fast Solid State Drives (SSD) we synced directly from object storage for efficiency and speed gains.

If you are interested, our implementation is actually based on MyCrypto’s implementation. There is more technical detail in the link, if you wish to give creating your own set-up a go.

On top of the fast SSDs, we are always looking for new solutions to help you scale faster.

We have a Source of Truth node that creates a snapshot of the latest chain data and pushes that snapshot to our Amazon S3 object storage. After which, a validator service verifies the chain data, ensuring there is no corruption and that all the required data is there. Then, the validator service marks the chain data as “verified”. This is all very useful if we have to scale up and add more nodes because the new nodes can easily grab this verified snapshot of the chain data, to speed up the syncing process.



What next?

The continued explosion of Ethereum users and demand for connectivity to other chains and services have pushed growth of our product suite further.

Today, Infura is powered by a cutting-edge, microservice-driven architecture that is optimized for scalability, reliability and efficiency. More than 350,000 developers connect to the Ethereum and IPFS networks through HTTPS and WebSocket. This year, we also expanded our support for Layer 2 networks, such as Polygon, Optimism and Arbitrum. And it all started with a simple premise: to make it easier to build on Web3.

In closing, we wish to say a big thank you to Tom Hay, Senior Product Manager and Jee Choi, Senior Systems Engineer, for their presentation on the history and evolution of Infura, at ETHPortland (see video below).



As we look forward to 2022 unfolding, what problems would you like us to help you solve? Holler at us on Twitter. Or, sign up for a forever-free account on Infura and start building your dream project today.

A Brief History of Infura

In Ethereum, archive nodes are full nodes running on archive mode. Ethereum’s full nodes do not store the generated World State from each block verification. They only need to store information such as headers and block contents.

They need to keep this information around long enough to be able to build up the blockchain historical state (data outside of the most recent 128 blocks) on demand. Storing only small amounts of data as opposed to the entire blockchain state enables full nodes to minimize storage and computation cost as well as sync time.

Archive nodes on the other hand, in addition to all of full node’s capabilities, store terabytes of historic data, making it possible to query any block at any point in time.


Build, Test, and Learn with Ganache 7 and Infura Integration

With the latest Ganache 7 upgrade, access to Ethereum Mainnet archive-state data is a breeze, requiring no extra configuration and just a single command. You can now instantly run your own fork of Ethereum’s Mainnet on your local computer with Ganache for free, thanks to Infura’s Ethereum archive nodes.  

For example, you can now debug verified external contracts using the Truffle Debugger. Previously, you had to connect to a self-hosted geth node that runs on archive mode, or pay for access to an expensive archive node.


How does it work?

Ganache uses the zero config mainnet forking feature under the hood, allowing you to simulate having the same state as the Ethereum mainnet, but on your local machine. To run Ganache in full archive mode, use this command: ganache --fork

This creates an archive node off of the Ethereum mainnet, you can also specify what network to create an archive node off of by attaching the --fork.network <Network Name> flag.

Lets walk through a demo of making requests to blocks older than 128 blocks from head, thereby using the archive data feature.

 * Start Ganache on archive mode with ganache --fork. This creates a fork of mainnet.
   




 * Next, in a new terminal window, run a request that fetches the balance of an address at block 1. The eth_getBalance RPC method accepts an address as well as an optional block parameter:

curl -H 'Content-Type: application/json'   --data '{"jsonrpc":"2.0", "id": 1, "method": "eth_getBalance", "params": ["0xe5Fb31A5CaEE6a96de393bdBF89FBe65fe125Bb3", "0x1"] }' http://localhost:8545


The 0xe5Fb31A5CaEE6a96de393bdBF89FBe65fe125Bb3 parameter on the curl request above represents the account address we want to query while 0x1 specifies the block number from which we want the result.

Taking a look at etherscan, this account received 1,000 ETH from the genesis block at block 1.

Notice how we got the response:

{"id":1,"jsonrpc":"2.0","result":"0x3635c9adc5dea00000"}

The number 0x3635c9adc5dea00000 is hex representation of 1 x 10^21 (WEI) which is equal to 1,000 ETH.


Performance Test

If you’re curious to know how Ganache’s archive node performs, we ran a speed test by simulating the Convex Finance’s system shutdown method that performs a number of token transfers. Here are the results:


Tool              Initial attempt              subsequent attempt  (exact same                  request)

Ganache 7      ~ 12 minutes                      ~24 seconds


Here’s a link to the repo in case you want to run these benchmark tests on your PC. Shout out to Matt Solomon for putting the repo together.


Conclusion

To get started with Ganache 7, whether as a new user or an existing Ganache v6 user, simply download it as an NPM package with the command npm install ganache --global or follow the instructions here.

We’re curious to see how developers leverage this feature during development. Let us know! Send us a tweet @trufflesuite or open a discussion here.


Recent Posts (page 13)

Minting NFTs with Infura and Replit

Infura Is Going To ETHDenver! See you there!

What’s ahead for Infura in 2022?

A Brief History of Infura

How to Fork Ethereum and Replay Historical Transactions with Ganache 7 Archive Support