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

Infura Developer Tutorials

Tutorials

Getting Started With Infura

Comparing NFT Standards - ERC-721 vs ERC-721a vs ERC-1155

Wanna be in the same league as Damien Hirst, DC, and Niftys? Then build your NFT on the Palm network!

Infura and Palm NFT Studio are excited to announce that the Palm network is now available to all users of Infura. Nearly 430,000 developers now have access to create NFTs on the Palm network.

The Palm NFT Studio

The Palm network is an Ethereum sidechain dedicated to selling, purchasing, and trading NFTs that are associated with real-world and digital assets. Palm provides low gas costs and fast transaction finality. The network is over 99% more energy efficient than Proof of Work-based blockchain networks, providing artists with a more sustainable solution today, while Ethereum upgrades to Proof of Stake in the Merge, tentatively scheduled for release in July 2022.

The Palm NFT Studio has collaborated with Damien Hirst, DC, Niftys and Warner Brothers and other artists in minting NFTs on the Palm network.

How to mint an NFT on Palm

For users looking to mint NFT projects, the Palm network provides an effective solution to create NFTs that are able to be bridged back to Ethereum.

To access the Palm mainnet or testnet endpoints, here’s how to get started:

1. Login to your Infura account and select an existing Ethereum project (or create a new Ethereum project if you have not yet).

2. Click on the settings of the project to view the Palm API endpoints.

Using Palm mainet and testnet is free as part of all Infura plans, and requests sent to the API count as part of your existing plan. No action is required to activate Palm, and the availability of Palm testnet allows you to have an environment to begin developing and testing your NFT project before going live.

See our documentation on Palm for more information, as well as links to helpful tutorials.

Get in touch and start building

Interested in creating your own NFTs, but do not know where to start?

Learn more from Infura’s Director of Engineering, Kris Shinn, on minting NFTs using Infura and Replit, based on his EthDenver 2022 presentation.

Let us know how you are using NFTs in our Discord and feel free to ask questions in our community.

Just getting started with Infura? Our docs will get you building.

Ethereum Network Updates, Upgrades, Hard Forks

Infura - Ethereum Network Updates

Network

The Palm network is now available for all NFT creators on Infura

Last July, we published Ethereum JavaScript Libraries: web3.js vs. ethers.js (Part I) to provide “a comparison of web3.js and ethers.js, focusing on their similarities and differences, so that you can better understand the nuances of the libraries.”

To recap, we dove into the documentation of both libraries. We then used a modified version of a software evaluation framework Andres Canal established in his article “Using Quill,js to Build a WYSIWYG Editor for your Website” to guide the reader toward making the best decision in choosing which library to use.

The article was “written with the intent of educating developers to understand the tradeoffs between the two libraries to be able to make a decision of which library to use for their particular use case.”

How have the conclusions from that article changed over the course of the past year?

Table 1: Comparison of Conclusions about Web3.js and Ethers.js




July 2020
October 2021




Web3.js has a community of users and maintainers associated with the Ethereum Foundation. Web3.js has a good API reference and has been around since 2015. Many projects are using it and the library has been the go-to in many "Build Your First dApp" tutorials.
Web3.js is best for those who prefer the most-used Ethereum javascript library that is also maintained by a blockchain-focused firm. Web3.js's strengths are its tests and community. Documentation is currently modest in design and scope and can definitely be improved.


Ethers.js is excellent because it is a small, compact library with a large number of test cases. It has good “Getting Started” documentation, making it accessible to new users. Developers find ethers.js simple and intuitive and the library has gained in popularity over the past two years, seeing increased downloads and usage by projects.
Ethers.js is best for those who prefer lightweight, user-friendly libraries with robust testing and documentation. Ethers.js’s strengths are its documentation, tests and community. It could have more maintainers in order to create some redundancy in the development team - currently a single individual.







Let’s dive into the updated data and explain why these conclusions have changed.


1) How important is the popularity of the library?

To use Andres Canal’s definition,

“A popular project on Github means exactly what you expect it to. Namely, that there are lots of people questioning, contributing, and supporting it. This activity tends to result in more reliable software. You can check the popularity of any project by looking at how many stars it has, how many issues are opened, how many pull requests are pending, and how many contributors worked on the project.”

Web3.js has about 11,600 stars and ethers.js 3,100 as of Oct. 14, 2021. Web3.js is used by 112,849 repositories, compared with 65,519 for ethers.js.

Looking back to July 2020, Web3.js had nearly 8,800 stars while ethers.js had nearly 1,500. Web3.js was used by 51,300 repositories on GitHub, compared with 18,500 for ethers.js.

Web3.js remains the more popular library, but impressively for both libraries, their dependencies have at least doubled over this time period. Web3.js remains more popular, but the overall pie of dependent projects has grown from about 69,800 to 178,368. We will dive more into the dependencies in question 3.


2) How important is the maintenance of the library?

To quote ourselves from the last article,

“We want to use libraries that are updated frequently, so that bugs are squashed and new features are added. Though it is not perfect, looking at a month (or two) of commits, closed issues, active issues, and the number of maintainers over that time period can give a sense of the strengths and weaknesses of an open source project. This also reveals patterns of maintenance, giving some insight to the user of a library when updates and bug fixes are generally addressed, which can be used as a proxy metric for maintenance of the library.”

Using the same metrics from our last article, we see the following for both libraries.

Table 2: GitHub Monthly Pulse for Sept. 14, 2021 to Oct. 14, 2021




Library
Commits to Main Branch
Closed Issues
Active Issues
Maintainers




web3.js
20
60
107
10


ethers.js
2
17
39
1






GitHub Pulse now reveals some additional useful information about the libraries, which gives us even more context of why we are seeing what we are seeing.

For web3.js, we can see that a single individual is responsible for the majority of the commits, though there are three individuals that have 10 or more commits. This is something I see as a plus. This means there is redundancy built into the development team, in case someone were to stop contributing to the project. Web3.js has 121 commits to branches other than the main branch, as web3.js is transitioning off of the 1.x version as outlined in this blogpost the roadmap for web3.js (which we will reference again in the next section). This indicates a lot of work is going into the future releases.

For ethers.js, Richard Moore continues to be the sole maintainer of the library, but there are many more people contributing to the project by opening and closing issues on the GitHub repository, indicating that there is a community of individuals committed to the health of the library. By virtue of a single maintainer, it is not surprising to see fewer overall commits.


3) Who is responsible for the development of the library and how many projects use it?

ChainSafe is the lead maintainer of the web3.js library, having received a grant from the Ethereum Foundation to “continue the maintenance and further development” of web3.js in September 2020. ChainSafe’s outline of the future plans for web3.js reveals major changes coming, such as the deprecation of web3-bzz and web3-shh packages in version 3.x and an eventual move to Typescript in version 4.x. These are exciting additions, but the tradeoff is that ChainSafe will need time to realize these while maintaining the existing library.

Ethers is the lead maintainer of the ethers.js library, which is Richard Moore’s project, so we can think of Richard Moore = Ethers. Ethers has been the lead maintainer of the project since the inception of it. This can be a risk for some projects, but in this case, it has made ethers.js very quick in adding features and capabilities. For example, ethers.js is fully TypeScript-ready with “definition files and full TypeScript source” according to the documentation.


Table 3: Dependent Repository and Package Counts, October 15, 2021




Library
Dependent Repositories
Dependent Packages




web3.js
113,018
4,685


ethers.js
66,950
3,505







Web3.js, likely due to the longer existence of the project, has more repositories and packages that are dependent upon it. When compared with metrics from our last article, ethers.js is closing the gap with web3.js when it comes to dependent packages.


4) How important is it that the library has tests?

Answer: Very important to any dApp developer worth their salt. Luckily for us, both libraries have gotten even better since our last article.

Ethers.js has a test suite API documented for the current v5 release on their GitHub repository. The documentation of the testing is very impressive. Check it out.

Web3.js has added test documentation since our last article. This documentation, based on my personal inspection, appears robust and clearly written.

I believe ethers.js has the lead, but web3.js has done a great job catching up in terms of its tests and their documentation, and I feel both have great coverage when it comes to tests. Tests are a strength for both libraries now.


5) How important is the number of downloads of the library?

As of Oct. 15, 2021, web3.js has 30,767,910 downloads and ethers.js has 24,284,490 downloads. Compare that with May 20, 2020, when we first looked at this statistic, when web3.js had 14,703,432 downloads and ethers.js had 8,500,336 downloads. The overall pie has grown, but the difference in downloads is surprisingly close: a difference in total downloads of 6,484,420 on Oct. 15, 2021 compared with a difference of 6,203,096 in late May of 2020.

When we look at weekly downloads, the two libraries are practically even: web3.js at 330,102 and ethers.js at 339,318. Weekly downloads of both libraries have nearly doubled since we last checked this statistic (May 20, 2020, for those following along): web3.js at 175,661 and ethers.js at 184,798.


6) How important is web performance?

Web performance is indirectly measured by comparing the size of the libraries, as we are assuming smaller libraries take less time to load in the browser.

Both libraries are small. Web3.js has decreased the size of the library to 7.28 MB unpacked (unpacked refers to the size of the library when published) from 10.6 MB when we last checked. Ethers.js touts its very small size, which has increased to 322 kb uncompressed from 284 kb uncompressed over the same time period. It’s unclear what occupies 322 kb within ethers.js. NPM shows ethers.js 10.2 MB unpacked, and I confirmed this when I downloaded to my personal machine and calculated the size of the ethers.js package using the Finder application on Macs. So we have to take ethers.js's word that it is small in size, which is a big plus, though I do need to do further research to confirm this claim is valid.


7) How important is the quality of the documentation?

Ethers.js is the clear winner when it comes to the quality of the documentation of the library and it stands out for three key reasons.

 1. Ethers.js has an extensive “Getting Started Guide,” which helps a user orient themselves to both the library and the vocabulary of Ethereum.
 2. Ethers.js has useful call outs and additional information provided as part of the documentation, giving the end user visual cues, convenient links, and other helpful user experience features that make reading and using the documentation an enjoyable experience.
 3. Ethers.js documentation has an extremely useful feature - a toggle to single page view, in which all documentation is provided on a single page. This makes using “Ctrl + f” in the documentation a breeze, and helps with finding the method you are looking for quickly.

Web3.js has not had many visible changes to the documentation since our last article and could use an update to make the user experience more pleasant.

An indirect additional comment on the documentation - ethers.org provides a very helpful “playground,” where you can try out the library in browser: https://playground.ethers.org/. This useful feature lets a user get started playing around with the library quickly and easily. While it could be argued that remix.ethereum.org provides a similar playground experience for web3.js, this is not the goal of remix, and remix support ethers.js as well.


8) How important is the overall usage of the library?

The last time we looked at the numbers, web3.js was the clear winner in overall usage, with ethers.js gaining users at a rate that appeared that it would only be time before ethers.js caught up to web3.js. The results today show that both have healthy ecosystems and a large number of users. My personal belief is that the overall growth of the ecosystem shows that both libraries have been adopted by a significant number of projects and users. So, while web3.js has more downloads, stars, and overall metrics, ethers.js is competitive to web3.js in its usage. It’s fair to say both have been widely adopted.


9) How important is the license?

This is one area that has not changed since we last reported. Web3.js still has the LGPLv3 license and ethers.js the MIT license. I am not a lawyer, and so this is the hardest area for me to pick a winner. It is worth reviewing Slava Todavchich’s article “Understanding open-source and free software licensing,” which we suggested in our July 2020 blogpost.

But wait... there is a new category!


10) How important is the community and community experience?

Yes, I am adding a new way to evaluate the two libraries, based on my experience in Developer Relations and Software Community. I am personally looking for robust channels where developers using the software can interact with one another, find information about updates and hotfixes, share their use cases and help each other debug their code. The best software projects provide this for their users and it is a differentiating factor.

Web3.js and ethers.js have both embraced Discord as a means to communicate directly with their community of developers. Web3.js lives within the ChainSafe Discord Server, in the channel #web3js-general. Web3.js has used this channel not just to interact with developers, but  as of September 2021, to promote a web3.js developer survey to help drive the direction of changes for version 4.x of web3.js. Ethers.js utilizes the EF JavaScript Team Discord Server, in the #ethers channel. Both are active channels with communication on a daily basis.

Both also use Twitter to communicate changes to their audiences, though both have relatively light follower counts. @web3_js (1,250 followers) and @ethersproject (1,279 followers) only tweet to announce updates and changes to the libraries, serving as another way for notifications about updates to get through to developers.

ChainSafe also uses their Medium account to post some updates about web3.js, though not a regular cadence.  

GitHub continues to be a source of discussion for communities of both libraries, though the shift to Discord by both reflects a growing trend in the Ethereum community, as well as in software communities in general, to commit to this tool for a mix of synchronous and asynchronous communication.

The verdict is that both take development and interaction with their communities seriously.

What’s the next step?

You should go ahead and test out the libraries themselves with Infura, and we created a tutorial for just this purpose: Ethereum JavaScript Libraries: web3.js vs ethers.js (Part II). The best way to see if my evaluation is valid is to kick the tires on both libraries.

In conclusion, instead of declaring a winner, it seems that Ethereum itself is benefitting from having two leading JavaScript front-end libraries. More libraries being built that can utilize the features of web3.js and ethers.js will push them to be even better (like web3-react, for example). In updating this article, I have been struck by the growth of downloads and dependencies of both libraries, making me of the opinion that you can choose either and feel comfortable with the decision. I hope this illuminated some ways you can evaluate both to choose what works best for you.

Get started building on Infura for free today.

Ethereum JavaScript Libraries: Web3.js vs Ethers.js: An Update

As the clock ticks down to the Merge, the Teku and Infura teams have continued refining their collaboration. In case you missed it, these two teams have created an eye-poppingly fast Ethereum 2.0 client sync experience. Since then, they have continued refining their integration and made some important discoveries and improvements.


Attestations with Teku

One of those discoveries was that validators linked to a remote beacon node could have significant performance issues: specifically, a lot of missed attestations. Obviously, this is a pretty crucial issue. It turned out to be not just a problem with a remote beacon node, but specifically a remote beacon node behind load balancers, including Infura’s load balancers.

If you’re interested in the blow-by-blow, check out the Github issue here.

The solution the team came to was to implement an option to disable early attestation publishing when the block is received:

--validators-early-attestations-enabled[=<FALSE>]

Find the full Teku documentation on this issue here.

This option allowed validators connecting to Infura beacon nodes to have performance equivalent to validators connected to a local beacon node, which in and of itself is impressive. It would appear that this is a fix not just for nodes connecting through Infura, but for any context where Teku validators are using load-balanced beacon nodes.

The second innovation the team has made surrounding attestations is batch attestations. This consists of sending all attestations produced for a given slot to the beacon node in a single batch. In the context of Infura, this allows running a lot more validators without hitting rate limits.


The future of history

Another feature that the team has been working on, which isn’t quite ready yet for a full release, is an innovative way to store historical state without having a hard drive the size of the Library of Alexandria.

With increasing adoption of decentralized technology, there is more and more demand, and even novel use cases, for historical chain data. The most top-of-mind for many in the space is tax compliance. Institutions and even individuals are increasingly in need of solutions for being able to query, quickly and cheaply, historical chain data.

Like most great things in this space, the solution being developed uses Merkle tries. Without getting too deep into the woods (pun intended), as it’s not finished yet, the technique essentially takes the difference between slots and stores the branch updates. The applicability for this is tremendous, so watch this space for more updates.


Safety through Diversity

As we approach the reality of Ethereum 2.0, more and more voices are calling out a topic of vital importance: client diversity. The Ethereum Proof of Work consensus mechanism is, at this point, venerable and battle-tested, at least in blockchain terms, and is resistant to 51% of attacks. As the network transitions to Proof of Stake, the threat remains that a single Ethereum client will be running on a majority of validator nodes. This opens the door not only for a malicious attack, but also for single points of failure bringing down the entire network.

For more explanation, check out this very readable primer that should bring a lot of issues into focus. There are so many reasons to make the move to a Proof-of-Stake consensus model, and the network is on track to do so. It would be a stunning failure of vision and quite simply, wildly unsafe to move Ethereum to a PoS network that has a majority of any Ethereum client.

Even if we were to assume that all clients were going to act in the best interests of the network as a whole, which in and of itself is a leap most aren’t willing to take, the Ethereum network is a sprawling global entity with external dependencies. No client should be able to be a single point of failure for the entire network.

As we build the Beacon Chain and validators up and out, client diversity must be included as an essential consideration.

Learn more about Infura’s Eth2 API here and sign up for a free account.

Teku + Infura to 2.0: How to Handle Attestations

SoK: Validating Bridges as a Scaling Solution for Blockchains

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 acquires HAL to bring no-code notifications and data streaming to blockchain developers.

Let’s face it: building dapps can be complex. Even for experienced web3 teams there are some DevOps processes that are a drag to innovation like listener scripts to filter raw block data.

Infura’s mission from the start has been to democratize and facilitate blockchain access and developer education. Infura powers web3 giants like Metamask and Uniswap, but has also empowered thousands of emerging web3 companies and new developers who’ve made the switch. But there’s always work to be done to ensure the Infura developer platform makes building in web3 as easy as possible with the best development tools. But we can’t always do it alone.

This is why today we’re thrilled to announce HAL, a robust, no-code notification and data streaming tool that aims to revolutionize the developer experience, has joined Infura.


What is HAL?

HAL’s mission to make blockchains more user-friendly is supported by a no-code, seamless user interface that easily queries and automates blockchain data flows. HAL’s precision targets on-chain events and pushes that data to developers through platforms like Discord or straight into a database.

The simple utility of HAL, coupled with its no-code, user-friendly interface has given rise to many use cases for builders and users of web3 including liquidity health factor alerts, price updates, smart contract monitoring, and DAO governance votes. And that HAL has joined Infura, their opportunity to make web3 easier to build on are even greater.


Webhooks, blockchain listening, and on-chain signaling with HAL

HAL currently serves two audiences: web3 users and web3 developers. One of the main pain points for web3 users right now is limited UX design. No one wants to constantly monitor a dapp’s dashboard or token. HAL solves this problem by letting a web3 end-user subscribe to an on-chain event and push the signal to them where they will actually see it. The HAL tool has been integrated into the likes of Aave, DeFiLlama, and Snapshot, providing developers teams with an “out-of-the-box” notification feature customized to their product.

Many web3 developer teams care about specific block data because that is the start of a process that impacts their protocol and end-user experience. Smart contract updates, blacklisted callers, failed transactions related to their protocol can all be used as a trigger for an automated process. But setting up the infrastructure to index, filter, and push that data is both repetitive and detracts from the really innovative work required to make a good product. To solve this, HAL filters relevant data from the blockchain to provide precision-selected data that gets pushed to Webhook, AWS, SQL, or MongoDB.

Here are a few examples of how developers can use HAL’s tools:

Digital Banks

Digital banks rely on blockchain APIs to access data and diversify their digital offerings. They need to understand the various capabilities of assets such as digital cash and CBDCs across various blockchains, and leverage data from blockchain APIs to do so. A digital bank could use a tool like HAL to programmatically add a new account address into their analysis engine, or even provide tracking to their end user, without having to update their own code base to perform that filter.

Crypto Liquidity Hubs and Portfolio Trackers

Users of AAVE, a leading digital asset liquidity provider, leverage HAL Notify to protect their positions from liquidations right on their website with rapid, automated notifications for liquidity events. Crypto portfolio trackers like CoinStats or Covey ingest decentralized data and perform automatic processes to produce value for their customers by helping traders track their moves and understand their profit and loss.This type of platform would ingest blockchain data such as wallet balances – the fiat equivalent value of a user’s cryptocurrency on multiple platforms’ trade history – the price of cryptocurrency at the moment of an event, and data that unifies insights across multiple chains for a single end user.

Boosting User Engagement

Most of Web3’s leading DAOs rely on Snapshot to facilitate governance votes. The reason is simple: gas fees make it cost-prohibitive for users to vote on-chain, and every dapp would have to create a custom front-end UI for average users to interact with the smart contracts. Snapshot solves this problem by providing a trusted off-chain voting platform without gas fees, plus a strong UI, with the security of signed messages to verify votes. Snapshot relies on user engagement with governance events to provide value to their customers. By integrating HAL’s notification tool into their website, Snapshot quickly gave users the ability to get updates on social media when their favorite DAOs governance events happened. This boosted the user engagement with Snapshot voting, all by providing a smoother UX to Web3 end users.

Scaling DevOps

For many younger projects in Web3, some features of their technology are not automated. An example of this is a lending platform that sends rewards every week to customers who stake on their dapp. Using HAL, the developers of this platform can automatically query the network to identify wallets who have staked in their contract, for what amount, and for how long, then push this data into a traditional web2 stack. From there, it is easy for the team to automate a calculation and prepare to dispatch rewards. Another example is monitoring a smart contract’s token balance and receiving an alert in your team’s Slack when it needs a refill. Use HAL to save time on setting on-to-off chain processes or cut down manual checks.


HAL x Infura

At Infura, we believe that a leading-edge web3 notification/automation tool should be a central component of any developer tech stack to ensure they can easily integrate it within their software through an intuitive SDK or API. HAL’s position as a crucial building block toward a low-code/no-code development solution will bolster the Infura product suite by extending its capabilities in higher order APIs, while offering a new level of composability for developers to create “recipes” for notifications, similar to IFTTT or Zapier.

HAL provides the Infura developer community with the full capability to implement effective blockchain automation and notification solutions – in 10 minutes or less – and we’re excited to offer you the substantial benefits this entails.

Sign up for a free Infura account today!




News

HAL brings blockchain listening to Infura

The downfall of CeFi platforms has proven financial institutions must build on Ethereum and DeFi protocols directly, not through excessive intermediation.

The failures and setbacks of some prominent centralized finance (CeFi) platforms like FTX last year pose a critical question for financial institutions eager to adopt blockchain technology: why not build on DeFi (decentralized finance) protocols and robust blockchains like Ethereum directly?

As our CEO and Founder, Joseph Lubin has expressed, we need right-size intermediation. I believe there is a space for established financial institutions to innovate in web3, but this needs to be done by accessing the power of DeFi protocols on Ethereum directly.

In my conversations with incumbent financial institutions with deep experience in self-custody and payments, I frequently hear that as they develop web3 offerings, they’ve chosen to work with what I refer to as a Crypto FI.

Crypto FI means crypto-financial-institution. The term refers to when a bank works with another financial institution that has web3 capabilities in order to access Ethereum and DeFi as a blackbox product and not directly via their own node or a node as a service provider like Infura.

And while some Crypto FI solutions may give their customers a relatively faster go-to-market, it’s fundamentally no different than working with a custodian or correspondent bank. The only difference is that instead of stocks, bonds, or other currencies, it’s crypto and digital assets.

I've found this surprising as it amounts to layering on additional financial institutions versus the ease and security of using Ethereum and DeFi directly with Infura.


The benefits of accessing DeFi directly with Infura for financial institutions


Ethereum already does settlement successfully and has trustworthy lending markets and exchanges. Ethereum also has standards developers must adhere to, as well as composability to infinitely scale applications.

I've told financial institutions entering web3 that by using crypto-native software partners like Infura to leverage blockchain innovations and not a Crypto FI has several benefits:

 1. Margin compression: Solutions banks offer will be as costly as the intermediary or intermediaries between them and the protocols they are using to build financial products. Margins are compressed by the rent seeking of these intermediaries, whereas when using Ethereum directly they’re limited to the cost of gas only.
    
 2. More product flexibility: Solutions banks offer will be limited to what their intermediary can offer. Ethereum has infinite composability and interoperability on its own.
    
 3. Less counterparty risk: Solutions banks offer are exposed to significant financial, reputational, and compliance risk, because they’re dependent on third party crypto-custodians and correspondents like FTX. Major DeFi protocols that are fully decentralized do not present such risks as they execute logic according to smart contracts.
    
 4. No restrictions for non-financial apps: Solutions banks offer, when dependent on a Crypto FI can foreclose activities such as DAO voting, NFT as PFP, pay-with-asset, and staking. No such restrictions exist when using Ethereum directly.


What 2022 taught us about the strength of DeFi


The core lesson of 2022 is that incumbent financial institutions build on Ethereum and DeFi protocols directly, not through excessive financial intermediation.

My colleague Lex Sokolin, Head Economist at ConsenSys, has written extensively that the primary purpose of using Ethereum and DeFi protocols is to transform the manufacturing of financial services  — not just their distribution.

For example, there’s no reason that banks, with their existing key management services and the ConsenSys product suite that includes Infura infrastructure, couldn't readily create a stablecoin settlement system. This would free them from the burden of prefunding nostro accounts with each other and free up trillions of dollars of liquidity locked up in legacy procedures.


JP Morgan accessing DeFi directly and securely with Infura


An example of a major bank using DeFi directly with Infura happened in November of last year.

JP Morgan, in collaboration with the Monetary Authority of Singapore, DBS Bank, and SBI Holdings, did a live SGD-JPY cross-currency transaction on Polygon and AAVE, two protocols that have remained resilient since their inception. Infura's suite of high availability APIs was used to enable the transaction.

Are you ready to take advantage of DeFi directly on your terms without the risk and drawbacks of layering in additional financial intermediaries?

Contact us at Infura today to learn more.

Why building directly on Ethereum and DeFi protocols is stronger than the alternative

It’s that time of year again. When we look back, and reflect on how far we’ve come in one year. Working in Web3 is like aging in dog years: one year equates to seven. This industry moves at lightspeed and in keeping up with the pace, it’s easy to lose sight of just how much one can accomplish in a year. In this blog we breakdown the key moments at Infura in 2022 and make predictions for 2023.


Added support for 6 new networks


One of the most important evolutions the Infura platform underwent in 2022 has been the six blockchain networks we added to build a multi-chain future for Web3.

For many years Infura has been known as the first node provider to exist for Ethereum. Today Infura supports 12 networks in total, six of which were added in 2022. You could say 2022 was “the year of multi-chain expansion” at Infura. And while we consider it a great honor to have been the first infrastructure provider built to support Ethereum, we know the future of Web3 is multi-chain. Here is the complete list of network releases in their order:

February - Palm

May - NEAR

July - Aurora

September - StarkNet

October - Avalanche C-Chain

November - Celo

We believe every developer should be able to choose the right blockchain for their dapp and go into greater detail about the considerations for choosing a network in this blog.

Providing reliable data and consistent uptime to these networks through the Infura platform means we can also build for interoperability, connecting as many builders to as many networks as possible with a robust API solution.

We are grateful to every network that chose to partner with Infura last year. 2022 was most definitely the year of network releases and we will continue our steady drum beat of network rollouts into 2023. The future is multi-chain!


Launched the NFT API


Another 2022 milestone took place at NFT.NYC in June 2022, where we launched the NFT API. After witnessing the rise in NFT adoption that occurred throughout 2021, we knew we needed to support builders by providing an API with all the metadata and tooling they require to keep advancing NFT technology.

The announcement included our unforgettable Times Square billboard takeover and an event during NFT.NYC dedicated to helping developers be part of the beta and start using the API for their projects.


The Ethereum Merge to Proof of Stake


When reflecting on 2022, who could forget the most important technological upgrade in recent history? The Ethereum Merge. Taking place in the early morning of September 15th, 2022, the Merge is the largest decarbonization in the history of technology, reducing Ethereum’s carbon footprint by 99.98%.

The Merge was celebrated far beyond the Ethereum community with news outlets worldwide, both tech and mainstream, wanting to understand its importance and how a community of developers was going to pull off upgrading the consensus mechanism of the world’s largest public blockchain without anyone noticing. Needless to say, Ethereum’s migration to Proof to Stake was flawless and we could not have been more proud to be part of the core devs team.  

In the months and weeks leading up to the Merge, the Infura team made it our top priority to ensure developers were informed about the changes the Merge implied to their client software setups and how they could prepare.

We published Infura’s Guide to Preparing for the Merge, complete with FAQs and step-by-step instructions of how to upgrade software clients, to ensure a smooth transition for developers using Infura. We also hosted seven weekly workshops to have direct contact with our community and answer all their questions and concerns in an open, broadcast forum. Lastly, we said goodbye to Ropsten, Koven, Rinkeby, and welcomed Goerli and Sepolia as Ethereum’s new long-lived testnets.


Growing Infura’s APAC community


Asia is one of the fastest-growing regions in the world for blockchain adoption. The Asia Pacific blockchain market comprises China, India, Japan, South Korea, Australia, and others. Asia is the largest and most diversified continent on Earth. It’s also where you’ll find cutting-edge infrastructure, top-tier innovation clusters, and densely populated emerging markets. For these reasons it was important for Infura to increase our presence in these regions and grow our APAC community in 2022.

We attend 34 events, connecting with builders and sharing our infrastructure service to improve their development experiences and dapps. These events included Gecko Con in Japan, Buidl Asia 2022 in Korea, Global Digital Assets Investment Summit 2022 in Singapore, Hong Kong Fintech Week in Hong Kong, and the World Blockchain Summit Bangkok in Thailand.

We also launched Infura’s partnership with China Software Developer Network in December. Those who are interested in reading about it in Chinese can visit this webpage.


Decentralized infrastructure network announcement


The final and perhaps the most significant milestone of 2022 at Infura was the announcement of our plans to launch a new decentralized infrastructure network.

Infura’s Co-Founder, EG Galano, made the announcement at ETHBerlin just days after the Ethereum Merge on September 17th. He also shared the news in this open letter to our community and crypto Twitter and the press went wild! The news was picked by 20 publications like Bloomberg, Coindesk, and Decrypt.

We also received over 4,000 submissions to join the early access program and while we can’t share who applied and who’s been accepted yet, we can say some big tech from Web2 are among them.

We know how important decentralization is to the future of Web3 and that it must underpin the technology we build. We know how much this matters to our community of builders and to the end-user of dapps today. Our team continues to work on the network and is making excellent progress you can read about in this blog.

That covers the key moments of 2022 at Infura. How about we look ahead to the future?


Predictions for 2023


Given the backdrop of various companies like FTX, BlockFi, Voyager, Celsius and others who have suffered scandals and loss of customer deposits in the billions of dollars, we expect the coming year to bring greater focus on the technology stack used to support and offer crypto services to end-users. Our industry has relied for too long on a legacy Web2 technology stack that is no longer keeping up with the demands of crypto.


The rise of the web3 tech stack


To put it simply, most cryptocurrency services rely on centralized gateways to access or update opaque databases. They are fully trusted systems with no guarantees of integrity nor are they tamper-resistant to protect the records of user authorized transactions. Worse still, a single operator can freeze the entire system in an instant and indefinitely. As a community, we have somehow built systems that replicate the legacy financial system alongside all the risks associated with it.

In 2023 we expect to finally change the technology stack that underpins most financial services built to serve users interested in cryptocurrencies. There is growing evidence of a desire for change too.

In the immediate term, exchanges are rushing to implement and support proof of solvency and proof of reserve protocols to demonstrate their assets cover their liabilities and they are fully collateralized to support all customer withdrawals. It is a step in the right direction, but there are greater fundamental changes taking place in the long term.

The very fabric of crypto, especially Ethereum and other blockchain networks, is to build systems that ultimately protect the end-user from an all-powerful system operator.

As a community, we have witnessed how crypto can achieve this end-goal with the rise of decentralized finance (DeFi). It enables a range of financial services without intermediaries like auctions without auctioneers and swapping assets without brokers. The final step is deploying DeFi protocols on a technology stack that can scale up its throughout and support the adoption for billions of users.


Ethereum’s 2023 rollup centric roadmap


This brings us to a prediction for 2023 which focuses on the emergence of rollups and Ethereum’s roll-up centric roadmap. A rollup offers a fundamentally new technology stack that all cryptocurrency service providers can adopt.

It allows the system operator to maintain a centralized front-end for managing user activity, but a decentralized backend that allows anyone to contribute towards protecting the off-chain database. System operators can focus on offering a superior user experience while the rollup technology automatically protects the integrity of the system.

With this prediction in mind, it is why Infura has focused on supporting the various rollup protocols including Optimism, Arbitrum, Starknet and the zkEVM by Consensys. We foresee cryptocurrency service providers slowly migrating away from their legacy Web2 software to a new technology stack powered by rollups. Motivated by the desire to protect users and to allow the companies to focus on their product without the liability to protect billions of dollars.

To conclude, the rise of DeFi and rollups is at the heart of Infura’s mission. We, alongside our infrastructure provider collaborators for the upcoming decentralized network, must be ready to support the colossal scale of JSON requests that will surely come with the rise of a new technology stack based on Web3 principles – protecting end-users from the accidental or intentional abuses of the system’s operator with decentralized systems.

Infura’s 2022 Reflections & 2023 Predictions

We’re excited to continue the expansion of our multi-chain ecosystem that supports the needs of all developers, from those working on side hustles to the developer teams at the biggest Web3 companies. Our goal has been and always will be to grow the entire ecosystem in as many industries as possible. Supporting multiple networks is critical to that future.

Today, we’re thrilled to announce our 12th supported network – Celo – a truly unique community of “developers, designers, dreamers, and doers” laser-focused on building an interoperable ultra-light mobile identity client to help anyone with a smartphone move value anywhere in the world.

As part of ConsenSys, Infura, along with developer tools such as Truffle and Diligence, offer a one-stop shop for developers, that includes complementary Web3 tools and services for all supported networks. Now it’s easier than ever to build for the over six billion smartphone users worldwide on Celo.


The Celo Ecosystem

Celo’s mission of prosperity for all – particularly the financially underserved – as well as their focus on regenerative finance (ReFi), or “DeFi for good,” resonates with many of us at Infura. ReFi utilizes the power of blockchain and Web3 to address climate change, support conservation and biodiversity, and create a more equitable and sustainable financial system.

Celo makes it easier for billions of smartphone users worldwide to send money, with the ability to have transaction fees paid using tokens or a variety of stablecoins. Perhaps most compellingly, Celo allows users of Celo dapps and wallets (including MetaMask, Opera, Valora and others) to send or receive money using only their mobile phone number – a far more simple identity tag than a 42-character randomized wallet address. The simplicity of use coupled with virtually zero fees make Celo one of the most accessible protocols out there, reducing the complexity of financial transactions to the ease of sending a text message.

Celo uses a Byzantine Fault Tolerant consensus mechanism (Proof of Stake) for its decentralized, secure and permissionless carbon negative blockchain transactions. The reduced amount of data needed to sync to the Celo blockchain with the ultra-light client mobile identity client lowers the barrier to participation.


Why build on Celo with Infura

For Infura developers, Celo offers full EVM-compatibility and a broad codebase including Solidity, making the inspiring task of building for 6 billion smartphones surprisingly familiar and accessible. Plus, working with Infura means no syncing or complex setups, 10x faster request response times than self-hosted solutions and 99.99% uptime.

At Infura, the networks we offer aim to meet our developer communities where they most want to be. As such, you’re not limited to one network – signing up for an account with Infura to build on Celo or any single network gets you access to all 12 networks (and counting) through a simple, single line of code. A bonus: get access to free archive data with your Infura plan and exceptional developer resources.

Looking for inspiration on what you could do with Infura and Celo? Some notable DeFi projects in the Celo ecosystem include Ubeswap and Moola, a mobile-first platform for borrowing and lending assets on Celo. The Celo Ecosystem Venture Fund helps developers build on Celo, with over US$77.6M in grants given out so far.

See what kind of impact you could make on the future of decentralized, regenerative, socially inclusive finance by getting started today.


Start building with Celo + Infura

Getting started with Celo on Infura is easy. Follow the few simple steps below, to start building today!


Step 1: Login in or sign up

Login to your Infura account or sign up for a free account and check out our Infura quickstart guide!


Step 2: Create a new key

Once you are logged in click CREATE NEW KEY.

From the “CREATE NEW KEY” pop-up:

 * Select Web3 API (Formerly Ethereum) in the NETWORK dropdown list.
 * Provide a NAME for your project and click CREATE

Your new project's settings page has all the information you need to connect to the network.


Step 3: Connect to the Celo network

Use the Celo card Mainnet or Alfajores endpoints to send JSON-RPC requests to the Celo network.

Never expose your key secret. It must never be human-readable in your application.  We suggest using a .env file


Step 4: Make requests


Celo supports EVM JSON-RPC methods to interact with the Celo network.

Call a CELO JSON-RPC method

Use HTTPS to call a JSON-RPC method. In this example, we use curl to make the HTTPS request to obtain the latest block number.

Ensure that you replace <YOUR-KEY-ID> with a project ID from your Infura dashboard:

curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc": "2.0", "id": 0, "method": "eth_blockNumber", "params": []}' "https://celo-mainnet.infura.io/v3/<YOUR-KEY-ID>"

The result should look similar to the following:

{"jsonrpc":"2.0","id":0,"result":"0xdde9f2"}


Step 5: Choose a network

Use one of the endpoints below, as your Celo client provider.
Ensure that you replace YOUR-KEY-ID with a KEY ID from your Infura dashboard.

Celo Mainnet
Network: Celo Mainnet
Description: JSON-RPC over HTTPS
URL: https://celo-mainnet.infura.io/v3/YOUR-KEY-ID

Celo Testnet
Network: Celo Alfajores
Description: JSON-RPC over HTTPS
URL: https://celo-alfajores.infura.io/v3/YOUR_KEY_ID


Step 6: Add Celo Network to MetaMask

From MetaMask, select Settings > Networks > Add Network.

Add the Celo network details to MetaMask (shown below).

Celo Mainnnet

 * Network Name: Celo (Mainnet)
 * New RPC URL: https://celo-mainnet.infura.io/v3/<API-KEY>
 * Chain ID: 42220
 * Currency Symbol (Optional): CELO
 * Block Explorer URL (Optional): https://explorer.celo.org

Celo Testnet

 * Network Name: Celo (Alfajores Testnet)
 * New RPC URL: https://celo-alfajores.infura.io/v3/<API-KEY>
 * Chain ID: 44787
 * Currency Symbol: CELOBlock Explorer URL (Optional): https://alfajores-blockscout.celo-testnet.org


Step 7: Fund Your Testnet Account

Create an account on Celo Alfajores with the Celo Faucet and your account will automatically be topped up with the CELO token. You’re ready to go!

For more guidance, see Infura’s Celo documentation.

Celo x Infura: Continuing our multi-chain expansion with social, regenerative DeFi

We launched the private beta of our Avalanche Contract Chain (C-Chain) endpoints in July this year, and have seen strong usage, with great feedback from our community. Now, we are ready to offer Infura’s API for Avalanche C-Chain to all users for free!


With this addition, Infura now supports 11 networks (and will continue to add more networks) including Ethereum, IPFS, Filecoin, Polygon, Arbitrum, Optimism, StarkNet, Palm, NEAR and Aurora.


Avalanche has become one of the leading Layer 1 platforms since launching in September 2020, making transactions cheaper, faster and more reliable. Developers of smart contracts may find the Avalanche C-Chain interesting, as it focuses entirely on smart contracts to boost performance, rather than spreading its focus over multiple functions like most other blockchains. The C-Chain is one of three chains comprising Avalanche's Primary Network, and is also EVM-compatible, allowing for easy Ethereum dapp migration to Avalanche for scale. Furthermore, it’s poised to become a major network for facilitating DeFi protocols, because of its advanced scalability with a throughput of 4,500 transactions per second, lower transaction costs that are a fraction of Ethereum's, sub-second finality, and robust security.


Infura has always put the developer at the center of everything we do. The first to bring easy Ethereum access to developers with a standard JSON-RPC API, Infura removes the complexity and high cost associated with self-hosting an Ethereum node. Our mission is to grow the ecosystem for everyone and make it easy for developers to build the next innovative application. Over the past year, we have focused our efforts on expanding our multi-chain offerings, so that we can provide value for developers wherever you are building.


That’s why we’re working with Avalanche to create a powerful solution that enables the next wave of DeFi dapps in the marketplace. Through Infura’s C-Chain API, you’ll have instant access to all of Avalanche C-Chain’s benefits - high throughput, fast transaction speed, consistent uptime, high programmability, compatibility with all your favorite Ethereum tools, decentralization, and sound security, with substantially lower costs.


With Infura's C-Chain APIs, you can seamlessly access and communicate with Avalanche C-Chain with a few clicks in the same familiar Infura developer portal. With only one API key, you can access multiple networks beyond Avalanche C-Chain on your Infura plan, without paying a premium for add-ons. As part of the ConsenSys family, Infura developers also have access to the leading Web3 development stack that includes the Truffle development framework, Diligence security tools, and MetaMask wallet to help you build, test, deploy, and secure your dapps.  


Start building with Avalanche + Infura. Sign up for a free Infura account today.


News

HAL brings blockchain listening to Infura

Why building directly on Ethereum and DeFi protocols is stronger than the alternative

Infura’s 2022 Reflections & 2023 Predictions

Celo x Infura: Continuing our multi-chain expansion with social, regenerative DeFi

Infura Makes Layer 1 Network, Avalanche C-Chain, Available to All Users