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 [https://twitter.com/PalmNft] 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
[https://palm.io/studio/damien-hirst-currency-nft-updates/], DC
[https://palm.io/studio/creating-a-sustainable-future-for-digital-fandoms/], 
Niftys and Warner Brothers
[https://palm.io/studio/niftys-launches-the-matrix-resurrections-nft-project-on-the-palm-network/] 
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 [http://infura.io/login] to your Infura account and select an existing
Ethereum project (or create a new Ethereum project
[https://docs.infura.io/infura/create-a-project] if you have not yet). 

2. Click on the settings of the project to view the Palm API endpoints
[https://docs.infura.io/infura/networks/palm/getting-started/accessing-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 [https://docs.infura.io/infura/networks/palm] for
more information, as well as links to helpful tutorials
[https://docs.infura.io/infura/networks/palm/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 [/minting-nfts-with-infura-and-replit/], based on his 
EthDenver 2022 [https://www.youtube.com/watch?v=kim7T4GDFOM] presentation. 

Let us know how you are using NFTs in our Discord and feel free to ask questions
in our community [https://community.infura.io/]. 

Just getting started with Infura? Our docs will get you building
[https://docs.infura.io/infura/].

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) [/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
[https://www.scalablepath.com/blog/using-quill-js-build-wysiwyg-editor-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 2020October 2021Web3.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
[https://github.com/ChainSafe/web3.js/pulse/monthly] and ethers.js 3,100
[https://github.com/ethers-io/ethers.js/pulse/monthly] as of Oct. 14, 2021. 
Web3.js is used by 112,849 repositories
[https://github.com/ChainSafe/web3.js/network/dependents?package_id=UGFja2FnZS0xNTA1NzY4MA%3D%3D]
, compared with 65,519 for ethers.js
[https://github.com/ethers-io/ethers.js/network/dependents?package_id=UGFja2FnZS0xNjEzMjI4Ng%3D%3D]
.

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

LibraryCommits to Main BranchClosed IssuesActive IssuesMaintainersweb3.js2060107
10ethers.js217391
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
[https://medium.com/chainsafe-systems/the-future-of-web3-js-v3-0-0-release-ecc9feecb2de] 
(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 [https://chainsafe.io/] is the lead maintainer of the web3.js library, 
having received a grant from the Ethereum Foundation to “continue the
maintenance and further development”
[https://medium.com/chainsafe-systems/chainsafe-receives-grant-from-ef-for-web3js-9e4376f5f36a] 
of web3.js in September 2020. ChainSafe’s outline of the future plans for
web3.js
[https://medium.com/chainsafe-systems/the-future-of-web3-js-v3-0-0-release-ecc9feecb2de]
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 [https://ethers.org/] 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 [https://docs.ethers.io/v5/#features]. 


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

LibraryDependent RepositoriesDependent Packagesweb3.js113,0184,685ethers.js
66,9503,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
[https://github.com/ethers-io/ethers.js/tree/master/docs/v5/testing]. The
documentation of the testing is very impressive
[https://docs.ethers.io/v5/testing/]. Check it out.

Web3.js has added test documentation
[https://github.com/ChainSafe/web3.js/blob/1.x/TESTING.md] 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
[https://npm-stat.com/charts.html?package=web3&from=2015-01-01&to=2021-10-15] 
and ethers.js has 24,284,490 downloads
[https://npm-stat.com/charts.html?package=ethers&from=2015-01-01&to=2021-10-15].
Compare that with May 20, 2020, when we first looked at this statistic, when
web3.js had 14,703,432
[https://npm-stat.com/charts.html?package=web3&from=2015-01-01&to=2020-05-20] 
downloads and ethers.js had 8,500,336
[https://npm-stat.com/charts.html?package=ethers&from=2015-01-01&to=2020-05-20]
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 [https://www.npmjs.com/package/web3] and ethers.js at 339,318
[https://www.npmjs.com/package/ethers]. 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 [https://www.npmjs.com/package/web3] and
ethers.js at 184,798 [https://www.npmjs.com/package/ethers].

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 [https://www.npmjs.com/package/web3] 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
[https://www.npmjs.com/package/ethers] 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
[https://medium.com/@moqod_development/understanding-open-source-and-free-software-licensing-c0fa600106c9]
,” 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 [https://twitter.com/web3_js] 
(1,250 followers) and @ethersproject [https://twitter.com/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
[https://medium.com/chainsafe-systems] 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)
[/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
[https://github.com/NoahZinsmeister/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 [https://infura.io/register] building on Infura for free today.

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

Infura Developer Tutorials

Tutorials

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
[https://consensys.net/blog/teku/teku-and-infura-team-up-to-make-the-fastest-ethereum-2-0-client-sync/]
. 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
[https://github.com/ConsenSys/teku/issues/4090].

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
[https://docs.teku.consensys.net/en/latest/Reference/CLI/CLI-Syntax/#validators-early-attestations-enabled]
.

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
[https://blog.ethereum.org/2020/08/21/validated-why-client-diversity-matters/] 
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 [https://infura.io/docs/eth2] here and sign
up [https://infura.io/register] 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 [https://caddyserver.com/]. Once that’s downloaded, check
out their Getting Started guide here
[https://caddyserver.com/docs/getting-started]. 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
[https://caddyserver.com/docs/quick-starts/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
[https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#load-balancing] 
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 [https://github.com/FiloSottile/mkcert],
and it’s incredibly easy to install by following these steps
[https://web.dev/how-to-use-local-https/]. 

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
[https://infura.io/customers/maker]. 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
[https://infura.io/docs/ethereum#section/Network-Add-Ons/Polygon-PoS]. 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
[https://consensys.net/blog/developers/how-to-save-time-on-devops-and-scale-with-infura-lessons-from-leading-ethereum-dapps/] 
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
[https://infura.io/register] 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 [https://infura.io/product/ethereum] to connect your app instantly
with a single line of code. Simplify your transaction management with Infura
Transactions (ITX)
[/why-you-should-use-infura-transactions-instead-of-building-your-own-in-house-relayer/] 
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”
[https://www.youtube.com/watch?v=EgbzVFfdZyg] at EdCon 2021.

Interested in building on Ethereum? Contact us [https://infura.io/contact]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
[https://www.trufflesuite.com/] 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 [https://infura.io/register] 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
[https://courses.consensys.net/courses/bootcamp-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
[https://docs.github.com/en/github/authenticating-to-github/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository] 
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
[https://discord.gg/ADWNDYVb8b] if you want to continue the conversation, share
projects, ideas, and join the community!

Start here with a free Infura account > [https://infura.io/register]

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
[https://github.com/ethereum-optimism/optimism-tutorial/tree/main/truffle#truffle-configuration] 
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
[https://github.com/ethereum-optimism/optimism-tutorial/pull/60/files] 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
[https://remix-optimism-compiler-plugin.readthedocs.io/en/latest?xgtab&] 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? 
Figure 1: Average gas price over the past three months. Typically spikes when
the network is congested.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
[https://blockstream.com/sidechains.pdf]. 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
[https://stonecoldpat.medium.com/a-note-on-bridges-layer-2-protocols-b01f8fc22324] 
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
[https://wbtc.network/dashboard/partners]. 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 [https://polygon.technology/] 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
[https://github.com/barryWhiteHat/roll_up] 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 [/arbitrum-supported-by-infura/], Optimism
[/infura-launches-support-for-optimistic-ethereum/] and Polygon
[/polygon-now-available/]. 

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

The future of Ethereum is here! 
Start accessing the Eth2 Beacon Chain through the Infura Eth2 API.
You can use Infura’s Eth2 API to analyze the state of the Eth2 chain, as well as
simplify and increase the reliability of your Eth2 validator setup. Explore the
full functionality and API spec [https://infura.io/docs/eth2].

Access the Beta
[https://infura.io/dashboard/eth2?utm_source=infurablog&utm_medium=referral&utm_campaign=eth2openbeta]

*Notice: Eth2 public beta: deprecation of project IDs*
[https://community.infura.io/t/notice-eth2-public-beta-deprecation-of-project-ids/2503?utm_source=infurablog&utm_medium=referral&utm_campaign=eth2openbeta]

Other resources

 * Ethereum 2.0 refers to a set of interconnected upgrades that will make
   Ethereum more scalable, more secure, and more sustainable. Learn more.
   [https://ethereum.org/en/eth2/vision/] 
 * Ethereum Foundation: Ethereum 2.0 Explained [https://ethereum.org/en/eth2/]
 * Ethereum 2.0 Knowledge Base
   [https://consensys.net/knowledge-base/ethereum-2/?utm_source=infurablog&utm_medium=referral&utm_campaign=eth2openbeta]
 * How to query validator balances programmatically with Infura’s Eth2 API
   [/checking-your-eth-2-0-validator-balance/?utm_source=infurablog&utm_medium=referral&utm_campaign=eth2openbeta]
 * A Guide to ConsenSys’ Eth2 Products
   [https://consensys.net/blog/blog/a-guide-to-consensys-eth2-products/?utm_source=infurablog&utm_medium=referral&utm_campaign=eth2openbeta]

Infura news, product announcements, and press releases.

Infura News

News

Infura’s Eth2 API is Live! How to Access the Public Beta

This blog post captures the highlights from Patrick McCorry's talk at EthDenver
2021 [https://www.youtube.com/watch?v=BmghRUEJtJ4&feature=emb_logo]. Patrick
[https://twitter.com/paddypisa] is Master of Relays at Infura and is
passionately working to solve transaction management friction for the industry.
We outline three critical problems that currently prevent developers and DeFi
users from getting more efficient transactions on Ethereum, and how Infura
Transactions seeks to eliminate this friction to create a better end user
experience.

What is the problem behind stuck transactions?
The Ethereum network is like a funnel. Transactions waiting inside the funnel
can be considered pending, and they are only mined after they have passed
through the funnel. A block is generated every 14 seconds, and every block
contains around 12MM gas. When there are too many pending transactions in the
funnel, and it exceeds the block capacity, it’s physically impossible for every
pending transaction to get into the next block. Generally, this is the source of
stuck transactions.

Ethereum as a global permissionless fee market. It is up to YOU to entice the
miner. 

Given this list of pending transactions, miners get to decide which transactions
to include in the next block and which transactions to ignore. This is why we
have a fee market. It is up to you to set a high fee that can outcompete all
other pending transactions and thus entice miners to include your transaction
over others. 

Problem #1: Transactions get dropped by the network
Let's consider the first source of stuck transactions. You pick your
transaction, set a fee you are happy with, sign it, and broadcast it to the
network. Then, for some reason, the transaction gets dropped and it won't be
picked up by miners because they are simply unaware of it.

Dropped transactions are typical when the network is under high congestion. Your
transaction must be propagated over the devp2p network, and any node between you
and the miners can decide to drop your transaction for any reason - especially 
when the mempool is congested. So, let’s assume an Ethereum node can only hold
4,096 transactions (default node configuration setting) and there are 4,097
transactions in the pending pool, then one transaction has to get dropped. If
your transaction is the one with the lowest fee transaction in the pending pool,
it will be the one that is most likely to get dropped. 

There are also various different (and often awkward) network rules that have an
impact on why transactions get stuck. For example: you might have 17
transactions in the pending pool, but it only guarantees to keep around 16, so
the 17th gets dropped as seen by the go-ethereum code
[https://github.com/ethereum/go-ethereum/blob/f91e55179eee5d3d2bd14fff3a30c2c15ead3086/core/tx_pool.go#L1297]
and config
[https://github.com/ethereum/go-ethereum/blob/3512b41c5cd024421a2048c70688c1b82f122dff/core/tx_pool.go#L167]
.

A wider problem with dropped transactions is called the nonce gap issue. Let’s
say you send 6 transactions in a row. For some reason, transaction 3 gets
dropped from the network. As a result, its child transactions (in this case
transaction 4, 5, and 6) are going to get stuck, and will never be confirmed by
a miner. That’s because there’s a special network rule: for every Ethereum
transaction, the nonce must increment strictly by 1. In this case however,
transaction 3 got dropped and makes it impossible for any proceeding transaction
to get mined. That’s an extremely frustrating situation to be in. 

How theoretical is the nonce gap problem? Do we really incur dropped
transactions? Let’s look at this research from Blocknative
[https://www.blocknative.com/blog/mempool-forensics]. Their forensic mempool
investigation surfaced the events on March 12 and 13 2020, when over 50,000
transactions an hour were being dropped from the pending pool as you can see
here: 

One company that suffered during Black Thursday (and highlighted in the 
Blocknative blog post [https://www.blocknative.com/blog/mempool-forensics]) was
MakerDAO. 

When the price of ETH collapsed on March 12, 2020, a large number of CDPs on
MakerDAO immediately became undercollateralized and eligible for forcible
liquidation
[https://community-development.makerdao.com/en/learn/vaults/liquidation/]. When
a CDP is forcefully liquidated, it triggers an auction process that lets anyone
(keeper bots) place a bid to purchase the remaining collateral. However, on
Black Thursday, many Keeper transactions were adversely affected as the network
congestion led to miner nodes dropping transactions at an unusually high rate.

This led to the keeper's bot non-dropped transactions becoming stuck. They tried
to bump the gas price of the stuck transactions including setting an outrageous
fee of 4,500 gwei (10x the normal gas fee) - and even that transaction got
stuck! This is because the dropped transactions resulted in a nonce gap that
prohibited miners from including any of the child transactions. The solution was
not to bump the gas price, but to re-publish the dropped transactions and fix
the nonce gap issue. 

Of course, some users noticed that keeper bots were struggling to submit bids
and they subsequently won the the auctions by submitting 0 DAI bids. Overall,
the keeper bots just had a bug in their relay infrastructure.

Problem #2: Transaction queues get stuck 
The second problem is how a bot manages the transaction fees for each
transaction in their queue of transactions.

It can become problematic if the same fee schedule is not applied across the
entire transaction queue. For example, you can see in the above that if there is
a low fee transaction in the middle of the queue, then it can be nearly as bad
as having a dropped transaction. This is because Ethereum miners don't always
look at your dependent transactions, and as a result the queue can get stuck
because of that one low fee. (This is slightly different to Bitcoin, as miners
do consider dependent transactions. This is called "child pays for parent"  and
it helps bump up the transaction fee.)

Problem #3: Paying too much… bad fee management
Finally, the third problem: setting the gas price too high. Commonly, people
visit Eth Gas Station [https://ethgasstation.info/index.php], get the trader
rate, and then send that to the network. For the most part, that works. You pay
a premium fee, and your transaction will get mined in the next few blocks. Of
course, the prices are so volatile that even that doesn’t work, because the fees
skyrocket by the time you send your transaction. Consequently,  everyone
overpays the fee and you still don't have a guarantee that the fee will be
sufficient for the transaction to get mined.

Solving these problems is not trivial.
Most teams that build their own in-house relayers would agree that transaction
relayer software is really fiddly. In fact, one team we spoke with recently,
described their in-house relayer as a complex beast. 

Writing robust fee-replacement and transaction monitoring software is complex
and time consuming. Transaction monitoring also requires dedicated
infrastructure, resources, and effort running 24/7 to work reliably. And even if
you build your own relayer, it’s really difficult to get satisfactory
guarantees. Unless done properly transactions won’t be mined at a reliable rate,
resulting in bad UX. If you get the relayer software wrong, you can end up with
a potential loss of funds. Some transactions are time-critical (e.g. a CDP) and
fragile transaction infrastructure could lose you money. 

Just like the issues faced by the keeper bots competing in the liquidation
auction on Black Thursday...most of the problems could have been avoided with
better relayer software.


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

...Enter Infura Transactions
So really, the whole point of Infura Transactions (ITX) is to help you to no
longer deal with stuck transactions and to ensure you do not need to re-invent
the wheel by building your own in-house relayer. 

How does it work? You can simply hook into the Infura Transactions API and send
your relay transaction to Infura. We'll guarantee that your transaction gets
delivered to Ethereum and that you will no longer deal with stuck transactions. 

How does ITX solve the problem?
The ITX relayer is built with the following features:

 * Republish periodically. ITX re-publishes the transaction every few minutes,
   so even if your transaction gets dropped, we don't need to check if it was
   dropped or not, we will always just republish it. 
 * Highest fee first. Our transaction queue is organized such that the highest
   fee paying transaction is at the start of the queue and the lowest fee paying
   transaction is at the end of the queue. 
 * Real-time fee adjustments. Our initial gas price estimate for sending the
   transaction aims to pay the minimum price while targeting a quick
   confirmation.
 * Escalator algorithm. We have an increasingly sophisticated bidding strategy
   such that we pay the best price at any time. 

Our list of features and ITX is built with reliability in mind and to help avoid
users paying unnecessarily excess fees. There are plenty of gotchas at the
network level that we have discovered while building ITX and we hope no one else
will need to re-implement the wheel to overcome the same issues. 

Who may find ITX useful? 
You may find ITX useful if you are working on the following products:

 * Crypto wallet providers. There are several wallet providers who send
   transactions on behalf of their users including Gnosis, Argent, Dharma and
   Loopring. Our infrastructure is close to plug-and-play for most smart
   contract wallet providers. 
 * Sequencers and rollup providers. A sequencer needs to send very large bocks (
   ~12 million gas for an optimism block
   [https://etherscan.io/tx/0x90ebd9630d98d5b0a186eec4c2382c296e5f41e828da910d76a53ab72ffe30e8]
   ) and thus they need to effectively outcompete the rest of the network to get
   their block confirmed. Our fee bumping strategy ensures that we'll eventually
   get the rollup block mined at the best price. 
 * Server-side scripts & DeFi bots. An example includes the keeper bot's for the
   liquidation auctions and ensuring the auction bids are reliably processed in
   time.
 * Dapps. An example is the Ethereum Name service as it requires ~3-4
   transactions before the domain name is set up. Ideally, the user can simply
   send ETH to the ENS service, and then the server-side script finishes the
   process on behalf of the user. 

How do we get started? 

We hope that you are now hyped up about using the ITX service for your project. 

To get started:

 1. ETH is money. You can deposit directly into our service as a pre-payment to
    cover your gas fees. This will act as your virtual gas tank and we will use
    that ETH to pay for gas on the network. ETH is the payment mechanism, ETH is
    money, use it as money, and deposit into the ITX service.
 2. Ethereum account. We use Ethereum signing keys to handle authentication for
    new relay requests to the ITX service. You sign it and then simply give us
    the job. 
 3. Coding project. You need a script or a project that will send a transaction
    to the network. 

How  to set up your gas tank:
All deposits are handled by an on-chain smart contract
[https://etherscan.io/address/0x015c7c7a7d65bbdb117c573007219107bd7486f9] and it
has the same address across all networks:

 * Send deposit. You can send the funds using the depositFor function. 
 * Wait. Your balance will be updated on the ITX service after 10 blocks. 
 * You are ready. Just send us a transaction and watch it get mined.

Just to remind everyone. ETH is money. ETH is how we take the payment. And ETH
is used in your gas tank. 

> Of course, since the deposit is handled by a smart contract. You can simply
automate the top-up process in your application and you may even use ITX to
perform the continuous top-ups. 
How have we implemented ITX:
We have three new JSON RPC commands. If you are using ethers.js, you can simply
use provider.send(["jsonRpcName","parameters"]) to send us the command.

Let's briefly cover each command:

relay_getBalance: Given an Ethereum account, it will return the balance of the
user's gas tank in WEI. 

relay_sendTransaction: Given a pre-signed relay transaction, it will return a
relay transaction has to let you track it's progress. 

relay_getTransactionStatus: Given a relay transaction hash, it will return a
list of broadcast Ethereum Transactions (and then you can check if one is
mined). 

Our Status API returns a list of transaction hashes due to how fee bumping works
in Ethereum. Every time we bump the network fee on your behalf it will produce a
new Ethereum Transaction (and a new hash). We decided to provide all  hashes to
let you decide how your users will track the progress of their transaction.

Find out more:
We hope you have enjoyed this article and hopefully you will decide to give ITX
instead of trying to build an in-house relayer (i.e., a complex beast). 

If you would like to find out more information about ITX and the API, then
please our documentation
[https://infura.io/docs/transactions?&utm_source=infurablog&utm_medium=referral&utm_campaign=Tutorials&utm_content=itxethdenver] 
and submit a request for alpha access
[https://infura.io/contact?&utm_source=infurablog&utm_medium=referral&utm_campaign=Tutorials&utm_content=itxethdenver]
. If you want something slightly more hands-on, then our ITX demo project
[https://github.com/INFURA/demo-eth-tx] is available for you to try.

Infura product updates and feature announcements.

Infura Product & Features

Product & Features

Why You Should Use ITX Instead of Building Your Own In-House Relayer

By Pedro Bergamini and Coogan Brennan

In our last post,
[/build-a-flash-loan-arbitrage-bot-on-infura-part-i/?&utm_source=infurablog&utm_medium=referral&utm_campaign=Tutorials&utm_content=flashbot2] 
we went over the three main concepts behind our bot: arbitrage, contract-based
transactions and optimistic transfer. 

In this post, we’ll walk through how to structure a program that can watch for
and execute on profitable arbitrage trades. 

Here is the overall flow of what we’re doing:

1) Program (“Bot”) is watching the price pairing of ETH-Dai on both Uniswap and
Sushiswap

2) When it spots a profitable arbitrage opportunity, it sends a transaction to a
contract we’ve deployed

3) Within one transaction, the contract:

> a) Uses flash swaps to optimistically borrow an asset from the lower priced pool
> b) Immediately sells the asset in the higher-priced pool
> c) Repays the flash swap loan and pockets the difference.


Let’s walk through the stack!

Our program is written in Node.js using the Ethers.js library and incorporating
an Infura endpoint. Our arbitrage smart contract is written in Solidity.

Infura
Our backend structure is written in Node and we will use our Infura node to
watch the price of ETH and Dai on the Uniswap and Sushiswap contracts. We’ll be
relying on our Infura endpoint to get those prices for each new block produced
on mainnet. (If you don’t have a free Infura account, you can sign up here
[https://infura.io/register?&utm_source=infurablog&utm_medium=referral&utm_campaign=Tutorials&utm_content=flashbot2]
.)

.env
This is super important! We’ll also need to store our private keys to sign
mainnet transactions. We put all our sensitive information in the .env file (an
example of which is in the repo
[https://github.com/pedrobergamini/uni-sushi-flashloaner/blob/master/.env.example]
). We also put in the address of our arbitrage contract and the key of our
Infura mainnet endpoint:

PRIVATE_KEY=
FLASH_LOANER=
INFURA_KEY=

Make sure PRIVATE_KEY is the same that deployed the FLASH_LOANER contract. Also,
the Ethereum account associated with PRIVATE_KEY needs to have enough funds to
cover gas costs, which can be high.

If you’re unsure about why we’re doing this, please read this excellent piece
explaining how to avoid uploading your private keys to Github.
[https://consensys.net/blog/blockchain-development/how-to-avoid-uploading-your-private-key-to-github-approaches-to-prevent-making-your-secrets-public/?&utm_source=infurablog&utm_medium=referral&utm_campaign=Tutorials&utm_content=flashbot2] 
As the article explains, we need to put sensitive information in this .env file,
then we add it to our .gitignore file,
[https://github.com/pedrobergamini/uni-sushi-flashloaner/blob/master/.gitignore] 
like so: 

.env
yarn.lock
package-lock.json
node_modules

This way, when we push our information to Github, this file will not be
included. This is super, duper important!

Ethers.js
We’re using Ethers.js because of its compatibility with Typescript, the original
language for project. This is an age-old questions for Ethereum developers but
for more on the differences between ethers.js and web3,js, please see this
article
[/ethereum-javascript-libraries-web3-js-vs-ethers-js-part-i/?&utm_source=infurablog&utm_medium=referral&utm_campaign=Tutorials&utm_content=flashbot2]
.

Contract Instantiation
Next, we instantiate the Uniswap and Sushiswap contracts on lines 11 and 12.
[https://github.com/pedrobergamini/uni-sushi-flashloaner/blob/master/index.js#L11] 
 

// uni/sushiswap ABIs
const UniswapV2Pair = require('./abis/IUniswapV2Pair.json');
const UniswapV2Factory = require('./abis/IUniswapV2Factory.json');

Sushiswap is essentially a fork of Uniswap, so they have the exact same contract
ABI and the exact same functions available to us….Another reason why they’re
good for arbitrage! (To learn why they have the exact same ABI, read about the
origins of SushiSwap here.
[https://www.delphidigital.io/reports/sushiswapvampire/])

provider.on('block')
Line 50 is the crux of the arbitrage bot.
[https://github.com/pedrobergamini/uni-sushi-flashloaner/blob/master/index.js#L50] 
Every block time, we will ask Infura to check the price of ETH and Dai in
Uniswap and Sushiswap. We’ll then compare those numbers to get the “spread,” or
possible profit margin. 

provider.on('block', async (blockNumber) => {
    try {
      console.log(blockNumber);
      const sushiReserves = await sushiEthDai.getReserves();
      const uniswapReserves = await uniswapEthDai.getReserves();
[...]
  }
}

A quick aside about frontrunning: Frontrunning, which is pushing small
advantages in data speed, is common in centralized finance trading. (You may
have read about it in Michael Lewis’ Flash Boys book.) We don’t have to worry
about this as much here because Uniswap and Sushiswap are decentralized
exchanges. Their price is kept on-chain and changes from block-to-block. 

Even if we were to somehow get information before the majority of the network,
the only way we can act on it is by including our trade in the next block, which
is visible to all. We’ll do some frontrunning defense by paying a high gas fee,
but that’s about the biggest gain available.

estimateGas
DeFi transactions like this can be very expensive. There may appear to be a
profitable arbitrage, but any profit margin may be eaten up by the cost of gas.
An important check of our program is to make sure our gas costs don’t eat into
our spread. We do this here and include it in our final check for shouldSendTx.

      const shouldSendTx = shouldStartEth
        ? (gasCost / ETH_TRADE) < spread
        : (gasCost / (DAI_TRADE / priceUniswap)) < spread;

For a pairing as common as ETH and Dai, there are not many profitable
opportunities. These are high volume pairs (many people using them) and Uniswap
and Sushiswap are relatively popular exchanges. In economic terms, arbitrage
opportunities result from market inefficiencies. If many people are using these
pairs, we are unlikely to find many opportunities. We must find newer tokens or
exchanges!

Contract
Follow along with the contract here.
[https://github.com/pedrobergamini/flashloaner-contract/blob/master/contracts/FlashLoaner.sol]

Basically, the contract acts as an intermediary for us. When our program detects
a profitable opportunity, it sends funds and instructions to this contract. 

Our arbitrage contract is relatively simple. Most of the code comes from
Uniswap’s own example in their repository
[https://uniswap.org/docs/v2/smart-contract-integration/using-flash-swaps/].

We have a constructor, which we feed some hard coded data like Uniswap and
Sushiswap’s contract addresses. We also have a single function, uniswapV2Call,
where we optimistically borrow tokens on one exchange, execute a swap on the
other, and repay the first swap back immediately.

pragma solidity =0.6.6;

import './UniswapV2Library.sol';
import './interfaces/IUniswapV2Router02.sol';
import './interfaces/IUniswapV2Pair.sol';
import './interfaces/IERC20.sol';

contract FlashLoaner {
  address immutable factory;
  uint constant deadline = 10 days;
  IUniswapV2Router02 immutable sushiRouter;

  constructor(address _factory, address _uniRouter, address _sushiRouter) public {
    factory = _factory;  
    sushiRouter = IUniswapV2Router02(_sushiRouter);
  }

  function uniswapV2Call(address _sender, uint _amount0, uint _amount1, bytes calldata _data) external {
      address[] memory path = new address[](2);
      uint amountToken = _amount0 == 0 ? _amount1 : _amount0;
      
      address token0 = IUniswapV2Pair(msg.sender).token0();
      address token1 = IUniswapV2Pair(msg.sender).token1();

      require(msg.sender == UniswapV2Library.pairFor(factory, token0, token1), "Unauthorized"); 
      require(_amount0 == 0 || _amount1 == 0);

      path[0] = _amount0 == 0 ? token1 : token0;
      path[1] = _amount0 == 0 ? token0 : token1;

      IERC20 token = IERC20(_amount0 == 0 ? token1 : token0);
      
      token.approve(address(sushiRouter), amountToken);

      // no need for require() check, if amount required is not sent sushiRouter will revert
      uint amountRequired = UniswapV2Library.getAmountsIn(factory, amountToken, path)[0];
      uint amountReceived = sushiRouter.swapExactTokensForTokens(amountToken, amountRequired, path, msg.sender, deadline)[1];

      // YEAHH PROFIT
      token.transfer(_sender, amountReceived - amountRequired);
    
  }
}

If there is any profit, we send it to the address which initiated the
transaction (_sender), who is us!

While this code is not production-ready, we hope it illustrates the basic
concept of flash swaps. We also hope it shows you how powerful this simple tool,
possible only on blockchain, can be. 

Fork this repo, play with it, make it better, and let us know how you’re using
it!

Want instant, scalable, and reliable API access to the Ethereum, Eth2, IPFS, and
Filecoin networks? Sign up for our Core service
[https://infura.io/register?&utm_source=infurablog&utm_medium=referral&utm_campaign=Tutorials&utm_content=flashbot2]
to start building for free today. Need more request volume and direct support?
Check out Infura+
[https://infura.io/upgrade?&utm_source=infurablog&utm_medium=referral&utm_campaign=Tutorials&utm_content=flashbot2]
to pick the right plan for your project.


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

Twitter [https://twitter.com/infura_io] | Newsletter
[https://infura.us14.list-manage.com/subscribe?u=7bec10aa5be97e80fcb0e7c52&id=13433031de] 
| Community
[https://community.infura.io/?&utm_source=infurablog&utm_medium=referral&utm_campaign=Tutorials&utm_content=flashbot2] 
| Docs
[https://infura.io/docs?&utm_source=infurablog&utm_medium=referral&utm_campaign=Tutorials&utm_content=flashbot2] 
| Contact
[https://infura.io/contact?&utm_source=infurablog&utm_medium=referral&utm_campaign=Tutorials&utm_content=flashbot2] 
| Open Roles
[https://consensys.net/open-roles/?discipline=32536?&utm_source=infurablog&utm_medium=referral&utm_campaign=Tutorials&utm_content=flashbot2]

Build a Flash Loan Arbitrage Bot on Infura, Part II

By Pedro Bergamini and Coogan Brennan

In the first installment of this series, we’re going to explain some of the
underlying concepts behind flash loans and flash swaps. In part two, we’ll show
you how to build your own Ethereum bot, running on Infura, watching for and
executing profitable arbitrage opportunities using flash loans.

Arbitrage
Arbitrage trading, independent of flash loans or blockchain, is when you have
the same asset with two different prices in two different exchanges.

For example, let’s look at two exchanges: Uniswap [http://uniswap.exchange/] and 
Sushiswap [https://sushiswapclassic.org/]. Sushiswap is a fork of Uniswap, which
means they run on the same contract code. While they’re two different exchanges,
we can use the same code to execute the same trade. Also, since Sushiswap is a
newer exchange, there may be fewer bots written for it.

Arbitrage works like this: One ether is worth 80 Dai on Uniswap and 100 Dai on
Sushiswap. We purchase 1 ETH on Uniswap and then immediately sell it on
Sushiswap, for a profit of 20 Dai (minus gas and fees). This is a typical,
profitable arbitrage trade.

Flash Loan vs Flash Swap
Flash loans and flash swaps are concepts specific to blockchain. The diagram
above shows some key differences between the two. Let’s flesh these points out.

Flash loans have a 0.09% fee on the interest-generating protocol Aave
[https://aave.com/flash-loans/]. It requires a minimum of three operations: 1)
borrow on Aave, 2) swap on a decentralized exchange, and 3) arbitrage swap on
another decentralized exchange to realize profit. Flash loans must be paid back
in the same asset you borrowed. If you borrow Dai, you need to pay your loan
back in Dai.

Flash swaps allow traders to receive assets and use them elsewhere before paying
for (or returning) them later in the transaction. Flash swaps, as done on 
Uniswap [https://uniswap.org/docs/v2/core-concepts/flash-swaps/], don’t have
flat fees (yet) but rather take a swap fee.
[https://uniswap.org/docs/v2/advanced-topics/fees] This can be seen as a “free”
loan compared to a flash loan because the swap fee is taken out of the trading
order- we do not have to make a separate payment. Last point of difference: we
can pay back flash swaps in either asset we’re exchanging. If we use a flash
swap to buy Dai with ETH, we can pay the swap back in either Dai or ETH. This
allows us to do more sophisticated operations.

Flash swaps and loans both employ “optimistic transfer,” a fascinating technique
we’ll get into later.

Flash Loans and Contracts
Another concept to understand about flash loans is the nature of Ethereum
transactions. All Ethereum transactions originate from an Externally Owned
Account (EOA), which is an Ethereum address operated by a human. An Ethereum
transaction can go from one EOA to another EOA, like when you pay a friend. An
Ethereum transaction can also go from an EOA to execute code in a contract. That
contract can call another contract and so on, until the gas in your transaction
runs out. 

*Note: If you’re new to transactions in Ethereum, check out this helpful
introduction to accounts, contracts, and types of Ethereum transactions
[https://kctheservant.medium.com/transactions-in-ethereum-e85a73068f74].

We will see later that flash loans require multiple function calls within their
execution, something that’s not possible from an EOA. Instead, we will deploy a
contract that contains the multi-step process. We initiate the arbitrage from
our EOA to the Aave contract but all we provide is the address to our deployed
contract. We also need to provide enough ETH to cover the gas cost of the
transaction, which can be quite costly due to the complexity of the
transactions. (Remember, a transaction’s price is determined by how much
computational power it requires).

Optimistic Transfer
Both flash loans and flash swaps employ a technique called optimistic transfer.
This remarkable DeFi innovation allows a user to take uncollateralized loans or
swaps and execute a trade as long as the user pays the service back by the end
of the trade. To better understand this mind-bender, let’s take a look at some
code.

Here is the LendingPool.sol contract code from Aave (V1).
[https://github.com/aave/aave-protocol/blob/master/contracts/lendingpool/LendingPool.sol#L843] 
We’re looking at the flashLoan function, specifically the following methods:

In line 877, we can see the contract transfer funds to the user’s contract
“optimistically”—It doesn’t check the balance of the user’s contract to see if
they have enough of that asset. Instead, the contract simply transfers the
amount.

How is this possible? Won’t the user just run off with those tokens? Well, if
this was the end of the transaction then that would be a serious problem. But as
you can see, it’s not the end of the code. Whether the user’s contract keeps
those tokens is contingent on the next few lines successfully executing.

After the optimistic transfer, on line 881, we see the Aave contract then calls
the user’s contract with the optimistic balance of tokens and any parameters the
user has passed in. Those parameters will be whatever the user needs to pass on
to their contract for the trade to be successfully executed. The transaction
workflow now temporarily halts on the Aave contract and moves to the user’s
contract, which executes its logic and hopefully a successful trade.

By line 884, the user’s contract has executed their code and the workflow now
returns to the Aave contract, which has a require statement extracting the fee
from the user’s contract. The optimism is over and now we must see if the
contract has executed a profitable trade! If so, the Aave contract will be able
to deduct its fee. If the trade has not been profitable, this require statement
will fail which means the entire transaction fails, meaning the asset transfer
we conducted optimistically two steps before essentially never happened.

Let’s take a look at how Uniswap implements their optimistic transfer. This is
from their UniswapV2Pair.sol contract, specifically the swap function:


The optimistic transfer happens at line 170-171, it’s the _safeTransfer method.
Uniswap has even commented out the optimistic transfer to better identify it (
Uniswap has great documentation and educational materials about their protocol
contracts, by the way! [https://uniswap.org/docs/v2/]). The next line is the
Uniswap contract calling the user’s contract with the optimistic balance. 

Again, imagine the transaction workflow temporarily pauses on the Uniswap
contract and moves to the user’s contract with the tokens optimistically
transferred. Once the execution has finished on the user’s contract, the
transaction workflow comes back to the Uniswap contract. The Uniswap contract
then assigns the new balance of the user’s contract and attempts to take the
swap fee (lines 180-181).

If the user’s contract had failed to make a profit with the tokens, the require 
statement on 182 would fail and the entire transaction would revert. This is the
key to optimistic transfer—it’s 100% dependent on the trade being successful. If
it’s unsuccessful, the transaction is invalid and will revert to the state
before the tokens were transferred. If it’s successful, however, the optimistic
transfer is maintained and the user takes their profit.


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

Arbitrage, contract coding and optimistic transfer come together to create an
impressive new tool. It’s an innovation built on top of the innovation of public
blockchains. The two innovations compound each other, creating a truly powerful
and unique mechanism. 

In part two of our series, the theoretical will meet the practical. We’ll walk
through actually building an arbitrage bot.
[/build-a-flash-loan-arbitrage-bot-on-infura-part-ii/?&utm_source=infurablog&utm_medium=referral&utm_campaign=Tutorials&utm_content=flashbot1] 
You can preview the code here.
[https://github.com/pedrobergamini/flashloaner-contract]

→ Our Eth2 API is live on mainnet! Drop us a message for Beta access.
[https://infura.io/contact?&utm_source=infurablog&utm_medium=referral&utm_campaign=Tutorials&utm_content=flashbot1]

→ Join the waitlist
[/introducing-infura-support-for-filecoin-developers/?&utm_source=infurablog&utm_medium=referral&utm_campaign=Tutorials&utm_content=flashbot1] 
for Infura’s Filecoin API.

→ Submit a request
[https://infura.io/contact?&utm_source=infurablog&utm_medium=referral&utm_campaign=Tutorials&utm_content=flashbot1] 
for access to Infura Transactions.


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

Twitter [https://twitter.com/infura_io] | Newsletter
[https://infura.us14.list-manage.com/subscribe?u=7bec10aa5be97e80fcb0e7c52&id=13433031de] 
| Community
[https://community.infura.io/?&utm_source=infurablog&utm_medium=referral&utm_campaign=Tutorials&utm_content=flashbot1] 
| Docs
[https://infura.io/docs?&utm_source=infurablog&utm_medium=referral&utm_campaign=Tutorials&utm_content=flashbot1] 
| Contact
[https://infura.io/contact?&utm_source=infurablog&utm_medium=referral&utm_campaign=Tutorials&utm_content=flashbot1]

Build a Flash Loan Arbitrage Bot on Infura, Part I

Ethereum JavaScript Libraries: web3.js vs. ethers.js (Part II)

So, you want to access the Ethereum network using Infura’s API - how do you go
about doing that? First, you’ll need to make sure you have an Infura account -
check out this tutorial
[/getting-started-with-infura-28e41844cc89/?&utm_source=infurablog&utm_medium=referral&utm_campaign=tutorials&utm_content=getting_started_eth_api] 
to get started! Next, you’ll want to determine which interface you want to use -
Infura supports JSON-RPC over both HTTPS & WebSocket interfaces. In this
tutorial, we’ll go through why you’d use each interface, as well as how to
access the Ethereum API via both methods using a Node.js example. 

HTTPS
HTTP/HTTPS is unidirectional - the client sends the request and then the server
sends the response - and has no state associated with it, meaning each request
gets one response and then the connection is terminated. You’ll want to use the
HTTPS interface if you’re getting data that only needs to be collected once or
if you’re accessing old data. You’ll see HTTPS used regularly with simple
RESTful applications.

Example:
In this example, we’ll write a Node.js program that uses the Rinkeby endpoints
and sends an RPC request to Infura to get the latest block data using 
eth_getBlockByNumber. From there, we will convert that block number from hex to
integer and print the integer block number to the terminal. Ready? Let’s go! 

The first part of writing this code is to install  Node (if you haven’t yet; you
can use npm [https://www.npmjs.com/package/node] or a download
[https://docs.npmjs.com/downloading-and-installing-node-js-and-npm]), DotEnv
[https://www.npmjs.com/package/dotenv], and your dependencies
[https://docs.npmjs.com/cli/install]. If you’re not familiar with dotenv, this
is a separate file that doesn’t get uploaded to GitHub that ensures your Project
ID and Project Secret (your environment variables) remain a secret in your code!
If you’d like more information, check out this Medium article
[https://medium.com/@thejasonfile/using-dotenv-package-to-create-environment-variables-33da4ac4ea8f]
.

Now that we’ve completed our installations, we can move on to creating our
app.js file and requiring dotenv and request at the top. This allows us to
access the request data as well as the variables contained in your dotenv file. 

const dotenv = require('dotenv').config();
var request = require('request');


Next, we take a look at the docs to see the required headers
[https://infura.io/docs/ethereum/json-rpc/eth-getBlockByNumber?&utm_source=infurablog&utm_medium=referral&utm_campaign=tutorials&utm_content=getting_started_eth_api] 
for eth_getBlockByNumber. Our headers need to containContent-Type:
application/json, so we’ll add that to our app.js file:

const dotenv = require('dotenv').config();
var request = require('request');

var headers = {
	'Content-Type': 'application/json'
};

Next, we’ll  identify what data we want to send through to the server. In this
case, we want to specify that we want:
1. JSON-RPC (the most recent version)
2. the method we’re calling
3. any block parameters we want to include (in this case, we’re wanting the
latest block’s data, so we’ll include a param for `[“latest”,true]`)
4. the ID 
You can think of this dataString as the sections of an HTML form we’re filling
out before  submitting them to the server. 

If you want to see how to lay this out, you can take a look at the provided
example from the docs using CURL commands (not exactly the params we’re looking
for, but you get the idea):

'{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params": ["0x5BAD55",false],"id":1}'


So, taking a look at the syntax and making sure our code is following suit, we
add our var dataString to app.js:

const dotenv = require('dotenv').config();
var request = require('request');

var headers = {
	'Content-Type': 'application/json'
};

var dataString = '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",true], "id":1}';

Now we’re getting somewhere! But where exactly are we getting the data from?
That’s the next part of the process. We need to create a variable that spells
out the:
1. url
2. method (i.e. POST/GET/etc.)
3. headers
4. body
5. any authorizations necessary (this is where you’d include information for
your project secret). 
Let’s go through what each of those entails:

 1. url: The URL you are using to access the API; you can find a list of all the
    networks with their corresponding URLs in our docs.
    [https://infura.io/docs/gettingStarted/chooseaNetwork?&utm_source=infurablog&utm_medium=referral&utm_campaign=tutorials&utm_content=getting_started_eth_api]
    • Note: where the URL in the doc says “YOUR-PROJECT-ID”, this is where
    you’ll put your Project ID from your dotenv file
    • We’re going to use Rinkeby endpoints, so we’ll use the Rinkeby HTTP URL
    
 2. method: The HTTP method (not the same as the “method” in the dataString)
    being used - identified in the docs
    [https://infura.io/docs/ethereum/json-rpc/eth-getBlockByNumber?&utm_source=infurablog&utm_medium=referral&utm_campaign=tutorials&utm_content=getting_started_eth_api]
    , specific to each JSON-RPC call being made
    • Potential options: POST/GET/PUT/PATCH/DELETE
    • getBlockByNumber is a POST request
    
 3. headers: Whatever headers are required for the call
    • We’ve already identified those in our var headers!
    
 4. body: Whatever information we’re sending with our request
    • In this case, we’ve again already done that work for ourselves by creating 
    var dataString!
    
 5. auth: Any authorization you may need to complete the request, if any (it’s
    not required)
    • This is where our Project Secret goes - note that the user field is left
    blank and your Project Secret (hidden in your dotenv file) goes into the 
    pass field
    • We aren’t requiring a Project Secret for this example, but we’ve included
    it as a comment for syntax’s sake:

const dotenv = require('dotenv').config();
var request = require('request');

var headers = {
	'Content-Type': 'application/json'
};

var dataString = '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",true], "id":1}';

var options = {
	url: `https://rinkeby.infura.io/v3/${process.env.PROJECT_ID}`,
	method: 'POST',
	headers: headers,
	body: dataString,
	// auth: {
	//   'user': '',
	//   'pass': `${process.env.PROJECT_SECRET}`
	// }
};

• Note: The syntax for the template literals is very important - check out this
article [https://dmitripavlutin.com/string-interpolation-in-javascript/] if you
need help! 

Alright, now we’re finally done with all the setup! All we have left is to
actually write the function that will send the request, get the response, and
get the JSON out of that response in a readable manner:

const dotenv = require('dotenv').config();
var request = require('request');

var headers = {
	'Content-Type': 'application/json'
};

var dataString = '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",true], "id":1}';

var options = {
	url: `https://rinkeby.infura.io/v3/${process.env.PROJECT_ID}`,
	method: 'POST',
	headers: headers,
	body: dataString,
};

function callback(error, response, body) {
	if (!error && response.statusCode == 200) {
		json = response.body;
		var obj = JSON.parse(json);
		console.log(obj)
	}
}

request(options, callback);

This provides us with the full raw JSON response, which can be a lot to look at
initially:

But, we know we’re looking for the most recent block number (which will be a hex
for us to then turn into an integer to print out): 

For this specific scenario, you could get the most recent block by using the
most recent transaction and getting its block number, but that way won’t work if
the block has no transactions in it! Using the following will allow you to get
block information, regardless of whether it has transactions or not:

Looking at the JSON data from the previous printout, we can see that 
obj.result.number provides us with the hex for the most recent block:

Every block also has a unique hash which is stored in the hash field, this can
oftentimes be more useful for subsequent requests, but we’ll focus on just the
number for now. When we console.log(obj.result.number), we get that same
highlighted hex value (it’s always good to double check you’re getting what you
expect to get from your code):

0x6f50f7


So we can define hex in our code as that obj.result.number in order to get
access to that hex value:

const dotenv = require('dotenv').config();
var request = require('request');

var headers = {
	'Content-Type': 'application/json'
};

var dataString = '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",true], "id":1}';

var options = {
	url: `https://rinkeby.infura.io/v3/${process.env.PROJECT_ID}`,
	method: 'POST',
	headers: headers,
	body: dataString,
};

function callback(error, response, body) {
	if (!error && response.statusCode == 200) {
		json = response.body;
		var obj = JSON.parse(json);
		hex = obj.result.number;
	}
}

request(options, callback);

Now, to the final part of the challenge: turning this hex into an integer and
printing out that integer! We want to call parseInt(hex, 16) to turn  our hex
string into an integer, and then we’ll console log that final result. hex is the
hex code we found in the previous step, and 16 signifies that hex is a
hexadecimal with a radix of 16 (if you don’t specify, any string beginning with
“0x” will be assumed to be a hexadecimal and therefore will have a radix of 16;
otherwise the radix will be 10):

const dotenv = require('dotenv').config();
var request = require('request');

var headers = {
	'Content-Type': 'application/json'
};

var dataString = '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",true], "id":1}';

var options = {
	url: `https://rinkeby.infura.io/v3/${process.env.PROJECT_ID}`,
	method: 'POST',
	headers: headers,
	body: dataString,
};

function callback(error, response, body) {
	if (!error && response.statusCode == 200) {
		json = response.body;
		var obj = JSON.parse(json);
		hex = obj.result.number;
		final = parseInt(hex, 16)
		console.log(final)
	}
}

request(options, callback);

When we run our code, we get:

7284488


Success! You now know how to use the Infura API to access Ethereum endpoints via
HTTPS! This method is great if you’re looking for more historical data or are
just needing the data once, but what if you need your data on a more rolling
basis? You’ll then want to use a WebSocket connection!

WebSocket
WebSockets are bidirectional and stateful, which means the connection between
the client and the server is kept alive until it is terminated by either party
(client or server). Once the connection is closed, it is terminated. The best
time to use a WebSocket is when you want to continuously push/transmit data to
the already-open connection, for example in cryptocurrency trading platforms,
gaming applications, or chat applications, where you want the data to be updated
constantly in real time.

Example:
In this example, we’ll write a Node.js program that again uses the Rinkeby
endpoints and uses a WebSocket connection to get the latest block header
information using a newHeads subscription type over that WebSocket connection.
For this one, we want to see an output of a tailing log of the latest block
header data from the WebSocket connection. Let’s get to it! 


To start off, we’re going to npm install and require the necessary constants - 
dotenv and ws (for WebSocket). This will allow us to hide our Project ID and
Secret and connect to the WebSocket, respectively. 

const dotenv = require('dotenv').config();
const WebSocket = require('ws');

Next, we’re going to open up our WebSocket connection by creating a new instance
of WebSocket:

const dotenv = require('dotenv').config();
const WebSocket = require('ws');

const ws = new WebSocket(`wss://ropsten.infura.io/ws/v3/${process.env.PROJECT_ID}`);

Again, we are using our dotenv file to keep our Project ID secret, which is why
we have the template literal here. 


If you read through the HTTPS section, hopefully part of this will look familiar
to you! After we have our WebSocket, we’re going to open it and send over our
data once it’s open (again, think about it like we’re submitting a form to the
server, telling it what we want). In this case, our method is eth_subscribe 
(since we’re subscribing to get the newest header
[https://infura.io/docs/ethereum/wss/eth-subscribe]) and our params are newHeads
, as that’s the type of subscription we want to get our result from:

const dotenv = require('dotenv').config();
const WebSocket = require('ws');

const ws = new WebSocket(`wss://ropsten.infura.io/ws/v3/${process.env.PROJECT_ID}`);

ws.on('open', function open() {
	ws.send('{"jsonrpc":"2.0","method":"eth_subscribe","params":["newHeads"], "id":1}');
});

Now we want to be able to look at the data we’re receiving in the response, so
we will assign a variable to the parsed JSON data and will console.log it to get
the header data we were asked for:

const dotenv = require('dotenv').config();
const WebSocket = require('ws');

const ws = new WebSocket(`wss://ropsten.infura.io/ws/v3/${process.env.PROJECT_ID}`);
	ws.on('open', function open() {
	ws.send('{"jsonrpc":"2.0","method":"eth_subscribe","params":["newHeads"], "id":1}');
});

ws.on('message', function incoming(data) {
	var obj = JSON.parse(data);
	console.log(obj);
	ws.close()
});

Notice at the end we close our WebSocket - this is an important step when we’re
trying to get just the latest block header data! Because we have closed our
WebSocket connection, our response is exactly what we want (the latest block’s
headers plus their data):

{ jsonrpc: '2.0', id: 1, result: '0x1' }


Want to know what happens if you don’t close the WebSocket connection? Of course
you do! We get this printout fairly quickly, and then it just keeps updating and
updating and updating and… you get the point. Here’s an example of what happens
when we leave the WebSocket connection open:


That’s it! Now you know how to open a WebSocket connection, call a method with
parameters, and get an output for both the latest block (and a running list of
the latest block, if that’s what you’re going for). 

Now go out and explore the Infura API
[https://infura.io/?&utm_source=infurablog&utm_medium=referral&utm_campaign=tutorials&utm_content=getting_started_eth_api]
!

Want More to Explore?
Check out all the possible requests you can make via HTTPS and WebSocket, as
well as some more complex concepts like rate limiting in our docs
[https://infura.io/docs/ethereum/json-rpc/?&utm_source=infurablog&utm_medium=referral&utm_campaign=tutorials&utm_content=getting_started_eth_api]
!

Subscribe to our newsletter
[https://infura.us14.list-manage.com/subscribe?u=7bec10aa5be97e80fcb0e7c52&id=13433031de] 
for more Web3 tutorials and product news. As always, if you have questions or
feature requests, you can join our community
[https://community.infura.io/?&utm_source=infurablog&utm_medium=referral&utm_campaign=tutorials&utm_content=getting_started_eth_api] 
or reach out to us directly
[https://infura.io/contact?&utm_source=infurablog&utm_medium=referral&utm_campaign=tutorials&utm_content=getting_started_eth_api]
.

Tutorials

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

Why You Should Use ITX Instead of Building Your Own In-House Relayer

Build a Flash Loan Arbitrage Bot on Infura, Part II

Build a Flash Loan Arbitrage Bot on Infura, Part I

Ethereum JavaScript Libraries: web3.js vs. ethers.js (Part II)

Getting Started with Infura's Ethereum API