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

Infura Developer Tutorials

Tutorials

Getting Started With Infura

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

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

Infura and Palm NFT Studio [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.

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?

As we approach the Merge, we at Infura wanted to give you an update about what
testnets will be supported in order for you to understand what’s available for
you when testing your own infrastructure. Building on an informative article, 
History of Testnets
[https://consensys.net/blog/news/the-history-of-ethereum-testnets/], this blog
defines the future of the Ropsten, Kovan, Rinkeby, Görli, Sepolia testnets as it
relates to Ethereum’s merge to Proof-of-Stake this summer. Below, you will find
a description of the various Ethereum Execution Layer testnets and the current
knowledge on what will happen with each as part of the Merge.

TestnetWill it merge?What will it merge with?And then?RopstenYes, it merged at 
Total Terminal Difficulty 50000000000000000
[https://blog.ethereum.org/2022/06/03/ropsten-merge-ttd/]A new Ropsten beacon
chain, named Ropsten
[https://github.com/eth-clients/merge-testnets/pull/9/files#diff-9c29d3bc94e566d048ef001d00dde1baf09805a35e83ed384bd39fc3737ecc14R3]
It will be deprecated by end of year: 
https://twitter.com/TimBeiko/status/1534580444221431810KovanNoNothingIt will no
longer have anyone supporting it, and will be deprecatedRinkebyNoNothingIt will
no longer have anyone supporting it, and will be deprecated.GoerliYesThe Prater
testnet beacon chainWill still be used; anyone can be a validator on this
testnetSepoliaYesA new beacon chain, presumably named "Sepolia" but name of that
beacon chain is to be determinedWill be the primary testnet
Ropsten
Ropsten is the oldest testnet that is currently active and uses Proof-of-Work
(mining) for new blocks. So, it is also the testnet that is technologically
closest to Mainnet (for a more in-depth history of Ropsten and the predecessor
testnet Morden, we encourage you to read EIP-225: Clique proof-of-authority
consensus protocol
[https://eips.ethereum.org/EIPS/eip-225#standardized-proof-of-authority] by
Péter Szilágyi). However, since it uses mining, it's also entirely reliant on
miners to produce blocks. As such, the plan is for Ropsten to be deprecated
after the Merge. However, since it's the oldest testnet with a lot of data on
it, the community (by “the community”, we mean the participants in the All Core
Devs calls and discussions [https://github.com/ethereum/pm] and the Eth R&D
Discord [https://blog.ethereum.org/2020/03/31/eth2-quick-update-no-10/], with
support from Ethereum Cat Herders [https://www.ethereumcatherders.com/], 
Ethereum Magicians [https://ethereum-magicians.org/], and other teams and
individuals who participate in the governance of Ethereum) decided to go ahead
and execute the Merge on Ropsten, and then deprecate it by end of year, as a dry
run for the other testnets.

What should I do if I’m currently using Ropsten for testing purposes?

Ropsten will work for a bit longer, but it is starting to go away. You should
begin using another testnet if you are currently using Ropsten. Ropsten can go
through periods of no block production, so always be prepared to use another
testnet or a locally run blockchain like Ganache for testing purposes if that
occurs. Some time after the merge of mainnet Ethereum and the Beacon Chain,
Infura will announce that we will be removing the Ropsten endpoints from our
platform, and we will give you a timeframe for when those endpoints will be
deprecated.

QuestionAnswerWill it merge?Yes, it merged on June 8th, 2022What will it merge
with?A new Ropsten beacon chain, named Ropsten
[https://github.com/eth-clients/merge-testnets/pull/9/files#diff-9c29d3bc94e566d048ef001d00dde1baf09805a35e83ed384bd39fc3737ecc14R3]
And then?It will be deprecated at the end of year: 
https://twitter.com/TimBeiko/status/1534580444221431810Kovan
[https://kovan-testnet.github.io/website/]
Kovan was announced
[https://www.ibtimes.co.uk/parity-pushes-new-ethereum-testnet-kovan-after-spam-attacks-1609901] 
on March 6, 2017, as a response to the February 24, 2017 Denial-of-Service
attacks on Ropsten. It's a Proof-of-Authority (PoA) network, meaning that only
certain entities can produce new blocks. Merge support is not planned for
OpenEthereum and Kovan will no longer be supported, as it will stop getting new
EIP updates.

What should I do if I’m currently using Kovan for testing purposes?

Make preparations to switch to using another testnet if you are using Kovan, it
will not be supported after the Merge. So, at some time in the future, Kovan
will no longer produce blocks and will not be usable as a testnet. Infura will
announce when we will be removing the Kovan endpoints from our platform and give
you a timeframe for when those endpoints will be deprecated.

QuestionAnswerWill it merge?NoAnd then?It will no longer have anyone supporting
it, and will be deprecated.Rinkeby
In order to solve the challenges presented by malicious actors attacking the
Ropsten, the Clique Proof-of-Authority (PoA) consensus mechanism was developed
[https://eips.ethereum.org/EIPS/eip-225#standardized-proof-of-authority], along
with the Rinkeby network on which to run this consensus mechanism.

The Geth team has done a lot of work in order to maintain Rinkeby, but with the
release of Geth 1.10.18, Rinkeby is now officially deprecated
[https://github.com/ethereum/go-ethereum/pull/24884]. Péter Szilágyi has
encouraged the community to deprecate this tesnet with an eye to “clean(ing) up
stuff” (see tweet thread
[https://twitter.com/peter_szilagyi/status/1526065078604292097]).

What should I do if I’m currently using Rinkeby for testing purposes?

Make preparations to switch to using another testnet if you are using Rinkeby.
Rinkeby will not be supported, so at some time in the future, it will no longer
produce blocks and will not be usable as a testnet. Infura will announce that we
will be removing the Rinkeby endpoints from our platform and give you a
timeframe for when those endpoints will be deprecated.

QuestionAnswerWill it merge?NoAnd then?It will no longer have anyone supporting
it, and will be deprecated.Görli (Goerli) [https://goerli.net/]
Clique became a bit of a standard with regard to testnet consensus mechanisms
and Görli (which will be written as “Goerli” for the rest of this article) was
created to have a Clique PoA network, where many participants can run signers.
For example, Infura runs one of those Clique PoA network signers. Clique is
supported in Besu and in other non-Geth clients now, as well.

The current plan is for Goerli to merge with Prater (the beacon chain testnet)
and keep going. The “little umlaut that could” (pardon the pun) will persist as
a supported testnet. Interestingly, since anyone with 32 Goerli ETH can be a
validator on Prater, that means that Goerli will go from a "permissioned" PoA
network where the block producers are explicitly assigned, to a fully "open"
one.

What should I do if I’m currently using Goerli for testing purposes?

Continue to use Goerli. The Goerli endpoints will remain on the Infura platform
as a supported testnet, once Ethereum successfully merges to effect the
Proof-of-Stake consensus mechanism.

QuestionAnswerWill it merge?YesWhat will it merge with?The Prater testnet beacon
chainAnd then?Will still be used; anyone can be a validator on this testnet
Sepolia
Sepolia is the newest testnet, but is actually over seven months old. The plan
is to merge Sepolia with a new beacon chain, potentially of the same name.
Interestingly, in this transition, Sepolia will go from "PoW anyone can mine" to
"only these validators are allowed", much like the old PoA setup, but using a
beacon chain for consensus rather than Clique/Aura.

Infura will announce when users will have access to Sepolia endpoints.

Once we have the relevant endpoints available for use, we encourage those who
have a need to use an Ethereum testnet, to use Sepolia. The Sepolia endpoints
will be displayed similarly to how other testnet endpoints are currently
displayed on the Infura platform. We will make an announcement and provide
updated documentation when the Sepolia endpoints become available on Infura.
Please follow us on Twitter [https://twitter.com/infura_io] or follow this blog,
for more details.

QuestionAnswerWill it merge?YesWhat will it merge with?A new beacon chain,
presumably named "Sepolia" but the name of that beacon chain is to be determined
And then?Will be the primary testnetWhat about L2s and non-Ethereum Virtual
Machine compatible networks?

There are no current impacts to L2s or non-EVM chains related to the Merge, but
if new information becomes available or relevant, you can find it on our Twitter
[https://twitter.com/infura_io] or follow this blog

As always, this is an evolving space, so we will update and/or link out from
this post as more specific information becomes available or changes to this plan
occur. You can stay up-to-date with all things related to the Merge from an
Infura or ConsenSys product perspective, here [https://consensys.net/blog/].


I need a refresher on using testnets!

If you need a refresher on using testnets, check out our docs for tutorials
[https://docs.infura.io/infura/], which will walk you through sending API
requests, getting testnet ETH, and deploying a dApp (smart contract and a
front-end) . Follow us here [/], for updates.


I have read this far - where do the names of the testnets come from?

Train stations
[https://www.ibtimes.co.uk/parity-pushes-new-ethereum-testnet-kovan-after-spam-attacks-1609901]
. Typically it is related in some way to those who were part of the development
team(s) or an event that may have occurred (like the Amphora Interop event in
Greece). Each link below is to information on the respective train station,
going back to the first testnet, Morden.

 * Morden [https://en.wikipedia.org/wiki/Morden_tube_station] Tube Station,
   London, United Kingdom
 * Ropsten [https://en.wikipedia.org/wiki/Ropsten_metro_station] Metro Station,
   Stockholm, Sweden
 * Kovan [https://en.wikipedia.org/wiki/Kovan_MRT_station] Metro Rapid Transit
   (MRT) Station, Singapore
 * Rinkeby [https://en.wikipedia.org/wiki/Rinkeby_metro_station] Metro Station,
   Stockholm, Sweden
 * Görlitzer
   [https://en.wikipedia.org/wiki/G%C3%B6rlitzer_Bahnhof_(Berlin_U-Bahn)] 
   Bahnhof, Berlin, Germany 
 * Sepolia [https://en.wikipedia.org/wiki/Sepolia_metro_station] Train Station,
   Athens, Greece

ethereum

Ethereum Testnets Update Ahead of The Merge for Infura Developers



This blog explores the Rainbow bridge that supports transferring assets between
Ethereum, NEAR, and Aurora. 




At Infura, we believe the future of Web3 is multi-chain. It is becoming more and
more common for assets that reside on Ethereum to be bridged and used on other
blockchain networks. This is why Infura supports several new networks like
Arbitrum, Polygon, and Optimism, as together in this multi-chain world, all
chains increase the utility and scalability of Ethereum, DeFi and the wider
self-sovereign movement that is at the heart of Web3. 


But this brings us to the question:


How are assets moved to other networks and what is the trust assumption that
ultimately protects the assets? 


Over the years, the trust assumption for protecting assets held by bridges has
evolved and a summary can be found here
[https://stonecoldpat.medium.com/a-note-on-bridges-layer-2-protocols-b01f8fc22324]
.


This blog explores the Rainbow bridge which supports transferring assets between
Ethereum, NEAR and Aurora. Of course, Infura supports all 3 networks amongst
others, to give developers the broadest choice of options possible. 


We will release a step-by-step tutorial for getting started on NEAR on our blog
[/] next week and you can learn more about NEAR at the upcoming Infura Community
Call on Tuesday, May 31st by RSVPing here
[https://www.crowdcast.io/e/infura-devtools-community-may2022]. 




What is the Rainbow Bridge?


The Rainbow Bridge design is similar to the original sidechain paper
[https://blockstream.com/sidechains.pdf] and we are only considering the bridge
implemented on Ethereum. 


It can be broken into a few components: 


Staked relayers. Anyone can stake funds and effectively self-appoint themselves
to protect the assets held by the bridge. Like most staking systems, a relayer’s
deposit will be slashed if they try to cheat the system - an example of
crypto-economic security as relayers have skin-in-the-game.


Chain of block headers. A relayer has a single responsibility. They must watch
the NEAR blockchain, fetch a block header that is signed by all validators, and
publish the signed block header to the bridge contract on Ethereum. This is
repeated over time and the bridge contract will have an up-to-date view of
NEAR’s canonical chain. Note, only one NEAR block header per epoch (~12 hours)
is submitted.


Light client technology. This is the magic behind the Rainbow Bridge and it
works thanks to cryptography. Given a NEAR block header, it is possible to
convince the bridge contract on Ethereum about events on the NEAR network. For
example, we can convince the bridge contract that a user has signalled their
intent to withdraw their assets from NEAR to Ethereum. With this information,
the bridge can release the funds back to the user. 


Thanks to these three components, the bridge contract on Ethereum can keep
up-to-date with actions that occur on the NEAR network and be convinced that
funds should be released back to the user. 




How do fraud proofs work?


Unlike rollups like Arbitrum and Optimism, the fraud proofs do not check whether
a block header or its list of transactions is valid. To put it another way, it
is not possible to convince the bridge on Ethereum that any transaction on the
NEAR network is fraudulent. 


The trust assumption for the Rainbow Bridge is the following: 


A block header is accepted by the bridge contract if it is signed by the
validators on the NEAR network. 


As long as the validators on NEAR attest that the database is alive and well,
the bridge contract will accept that as fact. 


But this raises the question:


Why are there fraud proofs? What fraud is actually being checked? 


A NEAR block header has several signatures from the validators. But processing
the block headers on Ethereum is expensive, especially since it does not
natively support Ed25519 signatures. Thus, the fraud proof system was built to
avoid the expensive gas costs on Ethereum
[https://near.org/blog/eth-near-rainbow-bridge/]. As a fun fact, it isn’t
possible to fit signature verification of all validators in a single Ethereum
transaction. 


Briefly, the NEAR block header (alongside the validator’s signatures) are
submitted to the bridge contract on Ethereum. The signatures are not checked by
the bridge, but it is stored for a fixed period of time. All watchdogs will
fetch the submission, check the signatures locally, and submit a challenge if
any signatures are invalid. 


There are two potential outcomes: 


 * Accept after the challenge period. If there is no challenge, then the bridge
   contract will eventually accept the block header as valid.



 * Issue challenge. If there is an invalid signature, then the bridge contract
   will verify it and decide to reject the block if it is invalid. 
   



The challenge process adds a time delay before any actions can be performed by
the bridge contract, but it does save significant gas costs for running the
bridge.



Malicious Relayer, Functional WatchTowers, and the Dark Forest





On the 1st May, 2022, an attacker tried to steal the funds held by the Rainbow
Bridge, and Alex Shevchenko explained how the funds are safu and the attacker
was ultimately thwarted.


As detailed in the thread, the attack occurred as follows:




 1.  * The attacker staked 5 ETH to become a relayer for the Rainbow Bridge.
    
    
 2. The attacker created a fake block header with invalid signatures and
    submitted it to the bridge contract (fun fact: their first attempt failed).
 3. A watchdog checked the submission and issued a challenge, as they had found
    invalid signatures.
 4. MEV bots on the peer-to-peer network (“the dark forest”) stole the challenge
    and got their transaction mined first.
 5. The watchdog’s transaction failed, but the MEV bots collected the 2.5 ETH
    bounty (½ the relayer’s stake) and saved the day.




As someone who has worked on fraud proof systems, it truly is remarkable to
witness it working in practice.


The most interesting takeaway here, is the role and motivation of the watchdog
service. Historically, for almost all challenge-response protocols, the role of
a watchdog is to make easy money by monitoring the blockchain and submitting
fraud proofs to collect a bounty. Simply put, it should be a for-profit venture
that anyone can participate in. 


However, as we witnessed, a watchdog service cannot compete with the Dark Forest
[https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest] for transaction
delivery. Without sending transactions directly to the miners, I conjecture that
the Dark Forest will always steal the watchdog transactions and get them mined
first. This is because MEV bots specialise at stealing the payload of others and
it is difficult for centralised services to compete with privately run bots. 


At first glance, this looks like a bad outcome. The business model of a watchdog
is undermined by the existence of the Dark Forest and it does not make sense to
run a service to make money. But, I do wonder if, as a community, we have the
wrong mental model for watchdogs? 


Perhaps companies will run a watchdog as an altruistic service, not to make
money, but to protect the underlying system that they rely on. If so, the job of
a watchdog becomes one of simply issuing a signal to the Dark Forest and letting
the MEV bots take care of the rest.


For once, it is a positive outcome for MEV. :)




With All This in Mind…


Infura believes in the rise of a multi-chain world and the Rainbow Bridge is one
of many types of bridges that are being deployed to support interoperability
across blockchains. 


By supporting networks that can bridge to and from Ethereum, we hope to
contribute towards the rise of the entire multi-chain ecosystem and, of course,
help cement Ethereum as the ultimate and most decentralised layer one network. 


With this in mind, the success of the Rainbow Bridge to defend against a
malicious relayer is a wonderful example that underpins our decision to support
the NEAR network
[https://consensys.net/blog/press-release/leading-ethereum-development-platform-infura-partners-with-near-protocol-marking-expansion-as-a-multi-chain-connector/]
, a network that boasts a vast ecosystem [https://awesomenear.com/projects] for
a reason. Such resilience demonstrates the technical maturity and robustness of
the technology built by the NEAR team.

layer-2

Rainbow Bridge, Fraud Proofs and the Dark Forest

To date, the Chainlink [https://chain.link/] Network has delivered 2B+ data
points [http://data.chain.link] to smart contracts across the Web3 ecosystem.
Much of this growth can be attributed to its expanding network of top node
operators, which help ensure the seamless delivery of external data to smart
contract applications. These node operators include some of the world’s leading
enterprises, such as Swisscom and Deutsche Telekom. 


Infura is excited to announce that we are joining this world-class group of node
operators. By joining the Chainlink Network as a node operator, Infura will be
able to provide critical infrastructure for servicing the growing adoption of 
Web3 [https://blog.chain.link/web3/] and help unlock the next generation of
blockchain use cases.


Infura makes it quick, easy, and cost-effective for developers to connect to
Ethereum and IPFS and start building decentralized applications. With 99.9%
uptime, more than 400,000 registered users, 8.5 billion requests made via all
its networks daily, and over 263 million ETH transacted via its Ethereum API in
2021, Infura is critical Web3 infrastructure that provides tools that enable
developers to easily take their blockchain application from testing to scaled
deployment. Infura's network is utilized as a backend by popular Ethereum
services including MetaMask, Uniswap, and Truffle.


Chainlink, the industry-standard decentralized oracle
[https://chain.link/education/blockchain-oracles] network (DON), is the most
widely adopted oracle solution. Chainlink DONs connect smart contract
applications to existing web APIs, off-chain computations, and other blockchain
networks, helping expand the utility of decentralized applications across the
multichain ecosystem. Joining the Chainlink Network enables Infura to help
provide the mission-critical infrastructure powering the smart contract economy
with data points that offer definitive truth about the real world. In return,
operators can earn revenue by receiving rewards for network contributions.


We chose Chainlink because it has proven itself as the industry leader in the
oracle network space. The Chainlink Network has a multitude of time-tested
features that enable security, transparency, and authenticity in data delivery,
making it the leading oracle solution for dApps and node operators. Some of
these critical features include:


 * Data Integrity — Chainlink nodes cryptographically sign all data supplied
   on-chain to verify its origin, preventing man-in-the-middle attacks.
 * Blockchain Agnostic — Chainlink nodes are compatible with any blockchain
   environment, serving as a single gateway to sell data to any current or
   future blockchain.
 * Widely Adopted — Chainlink is the most widely used oracle network in the
   blockchain industry, providing access to a vast addressable market of
   potential data consumers.
 * Provably Secure — Chainlink is thoroughly audited open-source software that
   already secures tens of billions of dollars in value, showcasing its ability
   to trigger the automation of high-value smart contracts live in production.
   

“Chainlink is critical infrastructure for the Web3 economy. Becoming a node
operator on the Chainlink Network gives Infura the opportunity to help ensure
the secure supply of real-world data to smart contract developers, enabling them
to build new and exciting decentralized applications across DeFi, NFTs, gaming,
insurance, and other areas,” said Kristofer Shinn, Director of Engineering at
Infura. “Moreover, by running a Chainlink node, we will be able to help both the
growth of Chainlink as the industry-leading oracle network and the mass adoption
of trust-minimized Web3 applications.”


“Infura has established itself as one of the leading service providers in the
Web3 industry, providing smart contract developers with a set of high-quality
tools that lower the barrier to entry for building decentralized applications,”
stated William Herkelrath, Managing Director at Chainlink Labs. “Given its large
user base and expanding set of developer resources, it makes sense for Infura to
become a node operator on the Chainlink Network to support further innovation in
the smart contract ecosystem.”


About Chainlink

Chainlink is the industry standard for building, accessing, and selling oracle
services needed to power hybrid smart contracts on any blockchain. Chainlink
oracle networks provide smart contracts with a way to reliably connect to any
external API and leverage secure off-chain computations for enabling
feature-rich applications. Chainlink currently secures tens of billions of
dollars across DeFi, insurance, gaming, and other major industries, and offers
global enterprises and leading data providers a universal gateway to all
blockchains.


Learn more about Chainlink by visiting chain.link [https://chain.link/] or
reading the developer documentation at docs.chain.link [http://docs.chain.link/]
. To discuss an integration, reach out to an expert
[https://chainlinkcommunity.typeform.com/to/OYQO67EF?page=announcement]. 


About ConsenSys


ConsenSys is a leading Ethereum and decentralized protocols software company. We
enable developers, enterprises, and people worldwide to build next-generation
applications, launch modern financial infrastructure, and access the
decentralized web. Our product suite, composed of Infura
[https://infura.io/?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website&__hstc=148571112.a231d19721fb2188de6b01c8fed208f7.1628613675833.1648500873320.1648546025058.320&__hssc=148571112.4.1648546025058&__hsfp=2548326787&utm_medium=referral&utm_campaign=consensys_website?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website]
, Quorum [https://consensys.net/quorum], Codefi [https://codefi.consensys.net/], 
MetaMask
[https://metamask.io/?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website?utm_source=consensys&utm_medium=referral&utm_campaign=consensys_website]
, Truffle [https://www.truffle.com/], Diligence
[https://diligence.consensys.net/] and our NFT platform
[https://consensys.net/nft/], serves millions of users, supports billions of
blockchain-based queries for our clients, and has handled billions of dollars in
digital assets. Ethereum is the largest programmable blockchain in the world,
leading in business adoption, developer community, and DeFi activity. On this
trusted, open-source foundation, we are building the digital economy of
tomorrow. To explore our products and solutions, visit http://consensys.net/
[https://consensys.net/].

Infura news, product announcements, and press releases.

Infura News

News

Infura Joining the Chainlink Network as a Node Operator

Your building journey with Infura just got even easier and better. Starting
today, we are introducing simplified pricing plans [https://infura.io/pricing] 
that will allow you to focus on building and scaling your product, without
having to worry about infrastructure. 



We will automatically enable supported networks for all users. Once a network
launches, you will immediately have seamless access to the endpoints required to
send requests on that network. No add-ons or credit cards required. Currently,
Infura supports Ethereum, Polygon, Arbitrum, Optimism, Palm, Filecoin, NEAR, and
Aurora networks. See our documentation [https://docs.infura.io/]for more
information on how to access these networks on your Infura dashboard. Existing
networks that require a credit card will soon have the requirement to add it
removed. You will not be charged for adding Polygon, Arbitrum, or Optimism.



Ethereum archive requests are now free, up to a maximum of 25% of your total
requests per day for Core Free users, up to 50% of your total requests per day
for Developer Plan users, and up to your request limit for Team and Growth
users. This will allow you to better use requests to power your project with the
data you and your users need. 


To learn more about archive data and what you can do with it, read the rest of
the article.


Using archive data with your Infura plan
If you are writing smart contracts that interact with historical data, then you
may already be familiar with or using an integrated blockchain development suite
such as Truffle or Hardhat. They both have an assortment of built-in tools that
make the entire development lifecycle for your dapp much easier. Connecting to
an archive node is as easy as setting your provided API URL endpoint as a
variable to be used in your frontend code.


The Ethereum JSON-RPC and Websocket API used by Infura includes several methods
which might require access to an archive node. These methods include an extra
parameter for specifying a block number for the request. If you’re interested in
inspecting historical data, i.e. data outside of the most recent 128 blocks, for
any of the methods listed below, your request requires access to archive data.


eth_getBalance

 * Returns the balance of the account of the given address.



-d '{"jsonrpc":"2.0","method":"eth_getBalance","params":
["0xc94770007dda54cF92009BFF0dE90c06F603a09f", "latest"],"id":1}'



eth_getCode

 * Returns the compiled smart contract code, if any, at a given address.



-d '{"jsonrpc":"2.0","method":"eth_getCode","params":
["0x06012c8cf97bead5deae237070f9587f8e7a266d", "0x65a8db"],"id":1}'



eth_getTransactionCount

 * Returns the number of transactions sent from an address.



-d '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params":
["0xc94770007dda54cF92009BFF0dE90c06F603a09f","0x5bad55"],"id":1}'



eth_getStorageAt

 * Returns the value from a storage position at a given address.



-d '{"jsonrpc":"2.0","method":"eth_getStorageAt","params":
["0x295a70b2de5e3953354a6a8344e616ed314d7251",
"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9",
"0x65a8db"],"id":1}'



eth_call

 * Executes a new message call immediately without creating a transaction on the
   blockchain



-d '{"jsonrpc":"2.0","method":"eth_call","params": [{"from":
"0xb60e8dd61c5d32be8058bb8eb970870f07233155","to":
"0xd46e8dd67c5d32be8058bb8eb970870f07244567","gas": "0x76c0","gasPrice":
"0x9184e72a000","value": "0x9184e72a","data":
"0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675"},
"latest"],"id":1}

We included the next section for those who are unfamiliar with archive nodes. If
you would like to skip to a tutorial using archive data, click here.
What is an archive node?
An archive node is required to access data from the Ethereum blockchain prior to
the most recent 128 blocks. Ethereum’s full nodes do not store the generated
World State from each block verification. They only need to store information
such as headers and block contents.


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


Archive nodes on the other hand, in addition to all of a full node’s
capabilities, store terabytes of historic data that make it possible to query
any block at any point in time. Currently, Ethereum archive nodes take up 15
terabytes of space and a full sync and archive can take more than 6 months.
Using Infura to access archive data helps to save you time and compute cost of
running your own nodes.


Why access archive data?
Archive nodes are particular nodes on the Ethereum Network that store historical
blockchain data. Because they offer this historical information, they are
helpful when you need to audit past transaction history or gather data. A full
node running on archive mode is necessary to know the historical result of a
transaction. You can answer questions related to account balances, smart
contract code, transaction counts, token supply, token price, and more at any
block at any point in time.


This state contains the balance for each wallet and the value of all the smart
contracts internal variables. This is necessary to add new blocks to the
Ethereum blockchain, since new transactions may execute smart contracts. The
result of these transactions will depend on the content of these internal
variables.


Archive nodes also enable the testing of smart contracts without creating a
transaction on the blockchain. For example, if you use Ganache, which is a
personal blockchain simulator in the Truffle suite of development tools, it
enables you to fork Ethereum in full archive mode
[/post/fork-ethereum-replay-historical-transactions-with-ganache-7-archive-support] 
to test smart contracts before you deploy on a live blockchain.




Common use cases for archive data
Services like Etherscan and Dune Analytics use archive nodes to provide
visibility into blockchain transactions for their users. Anyone can run one
themselves or access archive data through their Infura API endpoints. Here are
some common use cases of what we’ve seen from Infura customers of archive
requests:


Get and check balance information for any address (whether it is an externally
owned account or smart contract) that is more than 128 blocks in the past. This
is probably the most common use case and why our large Ethereum customers, such
as decentralized exchanges, liquidity pools and wallets, have archive enabled.


Call a specific smart contract function to read data via that function like 
eth_balanceOf in the ERC-20 and ERC-721 token standard. You may need to read
information about a user’s Externally Owned Account and check if they have a
balance of a certain token for the following purposes:

•  Decentralized exchanges and liquidity pools

•  Wallets

•  Games built on Ethereum with an ERC-20 token or ERC-721 or any other token
standard that has the eth_balanceOf functionality

•  Any NFT marketplace (due to needing to call eth_balanceOf)



Pull point-in-time data (specifically a particular block) if you are:

•  An indexer

•  Any company trying to show account history for their users

•  An auditor, tester, or anyone conducting forensic analysis of a smart
contract, with the intention of figuring out why a smart contract behaved the
way it did




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



Tutorial: Archive Data Playground

We have created a full-stack application that provides a reference
implementation and proof-of-concept for various use cases that are enabled by
access to Ethereum archive data.


Check out the repo here:https://github.com/anataliocs/Archive-Data-Playground


Technologies Used:

•  Java 11

•  Spring Boot

•  Gradle

•  Typescript

•  React/Redux

•  node/npm




Setup and Configuration

The project is built with a Java/Spring Boot backend and a React front-end.  You
will need to install the following dependencies locally to run this project: 


 * An Infura account [https://infura.io/register]
 * Git [https://git-scm.com/downloads]
 * Node / npm [https://nodejs.org/en/]
 * Java 11
   [https://www.oracle.com/java/technologies/javase/jdk11-archive-downloads.html]
 * An IDE [https://code.visualstudio.com/]




Get your API endpoint URL and Project ID


Head to https://infura.io/ [https://infura.io/] and go to your project settings
page:

Now let’s set up our externalized configuration so that we can use our project
ID without exposing those details on Github.  The Spring Boot app uses Spring
Dev Tools when running locally so we can use a local 
“.spring-boot-devtools.properties” file for configuration properties.



Configuration for MacOS users:

Create the properties file:

touch ~/.spring-boot-devtools.properties

Open the properties file:

vi ~/.spring-boot-devtools.properties

Add the following line to properties file:

infura.projectid=[YOUR_PROJECT_ID]



Running the application:

Pull down the source code:

git clone git@github.com:anataliocs/Archive-Data-Playground.git

Import the project into your IDE and it should build automatically.  Our project
uses gradle to build the back-end and npm for the front-end UI.

Change directory into the project folder:

cd archivedataplayground/

Then to run the full stack, invoke the Gradle wrapper:

./gradlew

This command will start up the Spring Boot backend in dev mode and also the
React front-end all in one command!



After the application starts up you should see the following:

2022-05-31 11:21:45.262  INFO 83493 --- [  restartedMain] i.i.a.ArchiveDataPlaygroundApp           : Started ArchiveDataPlaygroundApp in 3.709 seconds (JVM running for 3.924)
2022-05-31 11:21:45.264  INFO 83493 --- [  restartedMain] i.i.a.ArchiveDataPlaygroundApp           :
----------------------------------------------------------
        Application 'archivedataplayground' is running! Access URLs:
        Local:          http://localhost:8080/
        External:       http://192.168.0.37:8080/
        Profile(s):     [dev, api-docs]
----------------------------------------------------------
<============-> 92% EXECUTING [2m 15s]




Navigate to the local server in a browser at http://localhost:8080/



On the right-hand corner click account -> Sign-in and use the canned login and
password “admin/admin”





You will then have access to the application.  The login flow comes from the
base Jhipster project scaffolding tool that was used to create the basic project
skeleton.

You can directly query Infura JSON-RPC endpoints if you navigate to 
http://localhost:8080/admin/docs or click Administration -> API

This will bring you to the Swagger UI interface where you can call JSON-RPC
endpoints such as getting blocks older than 128 blocks which are available via
Archive nodes with hydrated transactions.  These calls can then be used in Block
Explorer style applications or other use cases.

Some specific blocks of code that help enable this functionality include:

https://github.com/anataliocs/Archive-Data-Playground/blob/main/src/main/java/io/infura/archivedataplayground/config/InfuraConfig.java

InfuraConfig.java

@Configuration
public class InfuraConfig {

   @Bean
   public RestTemplate restTemplate() {
       return new RestTemplate();
   }
}

This code provides a “RestTemplate” singleton which can be injected in classes
where it’s needed and helps abstract away the complexity of making JSON-RPC
calls to Infura.

The “dto.infura” package contains POJO objects representing request and response
JSONs used in Infura RPC calls.

https://github.com/anataliocs/Archive-Data-Playground/tree/main/src/main/java/io/infura/archivedataplayground/service/dto/infura

For instance, the following 3 DTO objects contain the block and hydrated
transactions response from an eth_getBlockByNumber JSON-RPC call which can be
used to get archive blocks from Ethereum’s history.





GetBlockByNumberResponse.java

public class GetBlockByNumberResponse {
   private String jsonrpc;
   private String id;
   private GetBlockByNumberResult result;

   // Getters and setters 
}


Infura POJO response to de-serialize JSON



GetBlockByNumberResult.java

public class GetBlockByNumberResult {
   private String difficulty;
   private String extraData;
   private String gasLimit;
   private String gasUsed;
   private String hash;
   private String logsBloom;
   private String miner;
   private String mixHash;
   private String nonce;
   private String number;
   private String parentHash;
   private String receiptsRoot;
   private String sha3Uncles;
   private String size;
   private String stateRoot;
   private String timestamp;
   private String totalDifficulty;
   private Transaction[] transactions; //Hydrated Transactions

   // Getters and setters 
}


Infura POJO response to de-serialize JSON



Transaction.java
[/introducing-a-simplified-infura-plan-with-free-access-to-ethereum-archive-data-and-all-network-apis/Transaction.java]

public class Transaction {

   private String blockHash;
   private String blockNumber;
   private String from;
   private String gas;
   private String gasPrice;
   private String hash;
   private String input;
   private String nonce;
   private String r;
   private String s;
   private String to;
   private String transactionIndex;
   private String type;
   private String v;
   private String value;
}




The included “RestTemplate” will automatically marshal/unmarshal responses into
these Object types.

You could also consider using https://github.com/web3j/web3j to help facilitate
Infura JSON–RPC calls made using the Spring Boot backend.




The Front-end

One feature that archive data enables is Block Exploration.



This block explorer displays information about about famous blocks in Ethereum
history such as:

Frontier

 * Block height: 0
 * Genesis block
 * Jul 30 2015



Frontier Thawing

 * Block height: 200000
 * Ethereum price: $1.24 USD
 * Sep 07 2015



Homestead

 * Block height: 1,150,000
 * Ethereum price: $12.50 USD
 * Mar 14 2016



The front-end is implemented using React and Typescript.  This form allows you
to submit a block number and look up that block’s data and hydrated
transactions.

infura.tsx

…

<p className="lead">Explore historical Ethereum Data</p>
<Form onSubmit={handleBlockByNumberSubmit}>

 <ValidatedField
   name="blockNumber"
   label="Block Number"
   placeholder="Block Number in hex"
   required
   autoFocus
   data-cy="blockNumber"
   validate={{required: 'Block Number cannot be empty!'}}
   error={errors.blockNumber}
   isTouched={touchedFields.blockNumber}
 />

 <Button color="primary" type="submit" data-cy="submit">
   Search
 </Button><br/>

</Form>

…




Submitting the form dispatches a request to the Spring Boot API and uses a
reducer to parse the JSON returned from the backend.

infura.reducer.tsx

…

export const getInfura = createAsyncThunk('infura/get_json', async (blocknumber: string) => axios.get<any>(`api/infura/${blocknumber}`), {
 serializeError: serializeAxiosError,
});

…






This is only a simple example of functionality that access to archive data
enables.  Using this basic framework, you could create Ethereum block analytics,
more detailed Block Explorers, back testing for trading algorithms and
Blockchain forensics applications!



Start building with free Ethereum archive data on Infura today by signing up
[http://infura.io/register] for a free account.


To get more information about how to use archive data for your project, reach
out to us at support@infura.io.

Infura product updates and feature announcements.

Infura Product & Features

Product & Features

Introducing A Simplified Infura Plan, With Free Access to Ethereum Archive Data and All Networks

Discover the benefits of building on NEAR, the first non-EVM chain to be added
to the Infura network, and simple steps to creating your first project today.



We are thrilled to announce
[https://consensys.net/blog/press-release/leading-ethereum-development-platform-infura-partners-with-near-protocol-marking-expansion-as-a-multi-chain-connector/] 
Infura has successfully integrated with NEAR, a carbon neutral Proof of Stake
layer-one blockchain that is also infinitely scalable with sharding. Infura is
excited to offer developers more choice and improve their building experience
through this integration. This partnership means the NEAR community now has
access to the more than 430,000 Infura developers
[https://www.businesswire.com/news/home/20220315005062/en/ConsenSys-Raises-450M-Series-D-Funding-as-Leading-Self-Custodial-Wallet-MetaMask-Reaches-Over-30-Million-MAUs] 
already building and scaling the next generation of software in Web3. 

The integration has been in private beta for two months during which time a
group of developers were able to test the NEAR-Infura integration for a smooth
roll out of its now wide release. 

Adding NEAR marks Infura’s expansion beyond Ethereum Virtual Machine
(EVM)-compatible chains and a strategic shift toward Infura becoming a key
connector in a multi-chain ecosystem, while improving the overall developer
experience. 

If you’re already building with Infura, we encourage you to check out the NEAR
network and ecosystem, and get started building. If you’re raring to go, you can
scroll to the bottom of this post, for a quickstart tutorial by Cedric Magne.
Otherwise, below are the key benefits and features of building on the protocol
to determine how NEAR can fit into our developer journey, as well as the
ecosystem at NEAR to join the community. Lastly, we cover the steps to create
your first EVM-compatible project on NEAR. 



The NEAR Ecosystem 
The NEAR protocol was founded in 2018 by a former Microsoft employee, Alexander
Skidanov and a developer, Ilya Polosukhin. Some of the world’s leading custody
providers, wallets, applications, and blockchains are integrating with the NEAR
network. As of May 2022, the NEAR network has over $900M in total value locked
(TVL) and over $840M in bridged assets to Ethereum. 

Web3 apps and protocols built on NEAR. Source: nearweek.com 

Source: https://nearweek.com/newsletter/edition-58

Key Benefits of Building on the NEAR Network 
By integrating with NEAR Network, Infura developers will have greater access to
a carbon-neutral ecosystem with minimal environmental footprint. This is because
NEAR operates on a unique sharded blockchain
[https://near.org/papers/economics-in-sharded-blockchain/] called Nightshade,
which has limitless scaling capabilities allowing transaction-heavy
decentralized applications to function effortlessly with low fees. Transactions
are processed at 14 tps on Ethereum and 7 tps on Bitcoin. NEAR embodies similar
characteristics as the Ethereum 2.0 roadmap, including PoS and shard chains.
 Additionally, the partnership allows developers to build decentralized
applications using popular programming languages such as Rust and AssemblyScript
as well as provides developers access to superior learning resources
[https://near.org/education/]. 

Here are the core benefits of building on the NEAR network: 

 1. Sustainable: NEAR’s efficient PoS network is certified as carbon-neutral.
 2. Cost-effective: 1000x lower transaction fees for users and developers earn
    30% of transaction fees.
 3. Secure: A thriving ecosystem of validators maintains network integrity.
 4. Friendly: Human-readable account names follow a scoped DNS naming pattern.
 5. Harmonious: EVM and Rainbow Bridge were developed for interoperability among
    chains.
 6. Pragmatic: Contracts are written using expressive community-supported,
    general purpose languages: Rust and AssemblyScript.



Infura developers can access the NEAR Network now and continue to advance the
multi-chain ecosystem, while onboarding more users to Web3. Next up is a short
tutorial on how to create your first project on NEAR.



How to Create an EVM-Compatible Project on NEAR
If you don’t have an Infura account already check out our Infura quickstart
guide [/post/getting-started-with-infura-28e41844cc89]!

Click CREATE NEW PROJECT

From the “Create New Project” pop-up:

 * Select Ethereum in the PRODUCT dropdown list.
 * Provide a name, then click CREATE

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


Use the NEAR Mainnet or NEAR Testnet endpoints to send JSON-RPC requests to the 
NEAR protocol or choose Aurora Mainnet or Aurora Testnet for an EVM-compatible
developer experience on NEAR. 


Never expose your project secret. It must never be human-readable in your
application.  We suggest using a .env file
[/post/how-to-use-dotenv-to-enhance-basic-security-within-your-dapp]



Make Requests
NEAR supports JSON-RPC methods to interact with the NEAR blockchain.  NEAR
JSON-RPC calls are different from Ethereum JSON-RPC calls so choose Aurora if
you prefer the EVM JSON-RPC methods. 

Info: WebSocket calls are not currently supported when using the NEAR endpoints

Call a NEAR JSON-RPC method
Use HTTPS to call a JSON-RPC method. In this example we use curl
[https://curl.se] to make the HTTPS request to obtain the gas price of the most
recent block.

Ensure that you replace <YOUR-PROJECT-ID> with a project ID from your Infura
dashboard [https://infura.io/dashboard]

curl -X POST \
-H "Content-Type: application/json" \
--data '{"jsonrpc": "2.0", "id": 1, "method": "gas_price", "params": [null]}' \"https://near-mainnet.infura.io/v3/<YOUR-PROJECT-ID>"


The result should look similar to the following:

{"jsonrpc":"2.0","result":{"gas_price":"100000000"},"id":1}

Choose a network
Use one of these endpoints as your NEAR client provider.

Ensure that you replace YOUR-PROJECT-ID with a project ID from your Infura
dashboard [https://infura.io/dashboard]

Network Description URL NEAR Mainnet JSON-RPC over HTTPS https://
near-mainnet.infura.io/v3/YOUR-PROJECT-ID NEAR Testnet JSON-RPC over HTTPS 
https://near-testnet.infura.io/v3/YOUR-PROJECT-ID Aurora Mainnet JSON-RPC over
HTTPS https://aurora-mainnet.infura.io/v3/PROJECT-ID Aurora Testnet JSON-RPC
over HTTPS https://aurora-testnet.infura.io/v3/PROJECT-ID 

Get NEAR tokens
Create an account on NEAR testnet with the NEAR testnet wallet
[https://wallet.testnet.near.org/create] and your account will automatically be
topped up with the NEAR token.



JSON-RPC Methods
Refer to the NEAR API documentation [https://docs.near.org/docs/api/overview] 
for the list of JSON-RPC methods to interact with the NEAR blockchain.  On
Aurora, you can use Ethereum JSON-RPC methods.

NEAR also provides a JavaScript library
[https://docs.near.org/docs/api/javascript-library] to help create decentralized
applications on the NEAR platform. It works in conjunction with the RPC
endpoints [https://docs.near.org/docs/api/rpc] to help you connect your
application to the NEAR blockchain.

Infura specifically supports the following NEAR JSON RPC methods:

query
block
chunk
gas_price
network_info
validators
broadcast_tx_async
broadcast_tx_commit
tx
EXPERIMENTAL_changes
EXPERIMENTAL_changes_in_block
EXPERIMENTAL_genesis_config
EXPERIMENTAL_protocol_config
EXPERIMENTAL_tx_status
EXPERIMENTAL_receipt




NEAR-API-JS Quick Reference


Install
npm i near-api-js

Import
const nearAPI = require("near-api-js");

Connect
const { connect } = nearAPI;

const config = {
  networkId: "mainnet",
  keyStore,
  nodeUrl: "https://near-mainnet.infura.io/v3/YOUR_PROJECT_ID",
  walletUrl: "https://wallet.mainnet.near.org",
  helperUrl: "https://helper.mainnet.near.org",
  explorerUrl: "https://explorer.mainnet.near.org",
};
const near = await connect(config);

Note: Key store is not required if you are not signing transactions (using view
call methods on a contract)

See: https://docs.near.org/docs/api/naj-quick-reference



Keep Building
We are excited about this partnership and what it means for the Infura and NEAR
developer communities. We will be publishing a series of educational content to
ensure that builders have what they need to use NEAR and Infura, moving forward. 

Please refer to NEAR [https://docs.near.org/] and Infura
[https://docs.infura.io/infura/networks/near] documentation for assistance with
building, today. You can learn more about the partnership at the upcoming Infura
Community Call on Tuesday, May 31st by RSVPing here
[https://www.crowdcast.io/e/infura-devtools-community-may2022].

Recent Posts (page 5)

Ethereum Testnets Update Ahead of The Merge for Infura Developers

Rainbow Bridge, Fraud Proofs and the Dark Forest

Infura Joining the Chainlink Network as a Node Operator

Introducing A Simplified Infura Plan, With Free Access to Ethereum Archive Data and All Networks

Paving the Way for a Multi-Chain Future, Infura Now Supports NEAR Protocol