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].

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://docs.ethers.io/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 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://docs.infura.io/infura/networks/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://trufflesuite.com/boxes/optimism] 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?



Building a dapp frontend, using React & Network.js, that can connect and request
data from the Ethereum mainnet using Infura & Metamask 

Developing a service or business on Ethereum can be difficult, due to the
intricacies of working with a blockchain and the novel UX / UI issues to solve.
This series of guides aims to serve as a quickstart to Ethereum dapp
development, with a focus on front-end solutions. Thankfully, you don’t need to
reinvent the chain. There are many pre-existing tools and services that can be
leveraged to get a dapp running quickly, including:

 * Infura
   [https://infura.io/?&utm_source=infurablog&utm_medium=referral&utm_campaign=tutorials&utm_content=building_dapp_frontends] 
   as a JSON-RPC connection to the mainnet or testnets;
 * MetaMask [https://metamask.io/] to serve as the user’s wallet and web3
   provider;
 * OpenZeppelin [https://openzeppelin.com/] for contracts and Network JS, a
   javascript library for web3 (i.e. blockchain development). This code tutorial
   is inspired by their dapp creation guide
   [https://docs.openzeppelin.com/network-js/0.2/building-a-dapp-from-scratch].

Using these products together has the benefit of replacing database setup and
user credential management, resulting in a quick-to-start blockchain
infrastructure. In this tutorial, we’ll create a React dapp using Network JS
that can interact with MetaMask, which uses Infura as its connection to the
Ethereum mainnet.

Environment Setup 

Before we start you should have Node.js [http://nodejs.org] with npm installed.
Let’s begin by creating a new project...

mkdir web3-infura && cd web3-infura

npm init -y

...and installing Network JS
[https://github.com/OpenZeppelin/openzeppelin-network.js/tree/master] by
OpenZeppelin to get library methods for working with web3:

npm install @openzeppelin/network 

Now we’re ready to create a Dapp

Using a common React boilerplate called create-react-app
[https://github.com/facebook/create-react-app] we create the initial version of
our dapp. This is easy to setup with npx (npm’s package runner). One line and
we’ll have the scaffolding files for our dapp:

npx create-react-app client

> In order to use Infura inside your dapp, you’ll need to register
[https://infura.io/register?&utm_source=infurablog&utm_medium=referral&utm_campaign=tutorials&utm_content=building_dapp_frontends] 
to set up an account and create a Project
[/getting-started-with-infura-28e41844cc89/?&utm_source=infurablog&utm_medium=referral&utm_campaign=tutorials&utm_content=building_dapp_frontends]
.
In the client/src/App.js file, we find the react project and look for the
placeholder code written in App.js. We replace the placeholder code with the
following:

import React from 'react';
import './App.css';
import { useWeb3 } from '@openzeppelin/network/react';
const infuraProjectId = '<YOUR_INFURA_PROJECT_ID';
function App() {
const web3Context = useWeb3(`wss://mainnet.infura.io/ws/v3/${infuraProjectId}`);
const { networkId, networkName, providerName } = web3Context;
return (
<div className="App">
	<div>
	<h1>Infura/MetaMask/OpenZeppelin Dapp</h1>
		<div>
    	Network: {networkId ? `${networkId} – ${networkName}` : 'No connection'}
		</div>
		<div>
		Provider: {providerName}
		</div>
	</div>
</div>
);
}
export default App;



Our dapp will now reveal which Ethereum network (mainnet or a testnet) it is
currently connected to, and the web3 provider it’s using.

Let’s test this out by saving and starting the browser by running npm start from
within the /client directory. Test it out by replacing the mainnet in the Infura
websocket URL to rinkeby. If MetaMask is already installed, disable the
extension here as you will see it takes precedence.

How this works is that in the above code we import useWeb3 from the React
implementation of Network JS (@openzeppelin/network/react) in order to get a 
web3Context. This is a Javascript hook that will attempt to retrieve an injected
web3 provider which, by default, is MetaMask. If no provider is injected, it
will use the Infura URL set as web3Context.  The term injected means code or
data that comes from a user's browser and is available for the website to use.

> Please note there are a variety of Ethereum web3 libraries available in many
languages, and while the implementation specifics differ, they all implement
creating a web3 connection through a ‘provider’ or ‘signer’ so this step is
important to understand.
The useWeb3 hook attempts to obtain an injected web3 provider first, before
falling back to a network connection. Alternatively use useWeb3Injected for an
injected web3 provider or useWeb3Network for a network provider such as Infura
or a private node.

Add a React Component

Our next goal is to move the display of the current Ethereum network to a
component and see how components are re-rendered when changes are made, such as
the network.

To do this, the first step is to select a web3 provider to be injected, and
install it. We’re going to use MetaMask as our web3 provider in this tutorial,
so head to metamask.io [https://metamask.io/] to install it.

In the code below, the Web3Data component expects a web3Context. The networkId, 
networkName and providerName are obtained from the web3Context and displayed in
the component.

We then create a components directory in the client/src directory, and create a 
Web3Data.js file with the code below:

import React from 'react';
export default function Web3Data(props) {
const { web3Context } = props;
const { networkId, networkName, providerName } = web3Context;
return (
<div>
	<h3> {props.title} </h3>
	<div>
    Network: {networkId ? `${networkId} – ${networkName}` : 'No connection'
	</div>
	<div>
	Provider: {providerName}
	</div>
</div>
);
}



Now back inside App.js, we’ll add the Web3Data component to provide a 
web3Context. In the client/src/App.js file, add this import for the Web3Data 
component:

import Web3Data from './components/Web3Data.js';

Then replace the entire contents of the App function in App.js with the
following code:

const web3Context = useWeb3(`wss://mainnet.infura.io/ws/v3/${infuraProjectId}`);
return (
<div className="App">
	<div>
	<h1>Infura React Dapp with Components!</h1>
	<Web3Data title="Web3 Data" web3Context={web3Context} />
	</div>
</div>
);



Let's run npm start from within the client directory to start the dapp again to
see how React components are re-rendered by Network JS when changes are made to
accounts, connection type or network. You can test this out by changing networks
in MetaMask.

Requesting Access to Account Address

Requesting a user’s account address and displaying it is one of the most common
patterns among dapps. However, injected web3 providers don’t give the dapp
access to a user’s address until that user has given permission. This bit of
friction has been intentionally designed to protect user privacy and prevent bad
actors from using an account address to track the user around the internet. You
can learn more about this communication protocol here
[https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1102.md].

In our Web3Data.js file, we replace the contents of the component with the
following code:

import React, { useCallback } from 'react';
export default function Web3Data(props) {
const { web3Context } = props;
const { networkId, networkName, accounts, providerName } = web3Context;
const requestAuth = async web3Context => {
try {
	await web3Context.requestAuth();
	} catch (e) {
	console.error(e);
	}
};
    
const requestAccess = useCallback(() => requestAuth(web3Context), []);

return (
<div>
<h3> {props.title} </h3>
	<div>
    Network: {networkId ? `${networkId} – ${networkName}` : 'No connection'}
	</div>
	<div>
	Your address: {accounts && accounts.length ? accounts[0] : 'Unknown'}
	</div>
	<div>
	Provider: {providerName}
	</div>

	{accounts && accounts.length ? (
	<div>
	Accounts & Signing Status: Access Granted
	</div>
	) : !!networkId && providerName !== 'infura' ? (
	<div>
	<button onClick={requestAccess}>Request Access</button>
	</div>
	) : (
	<div></div>
	)}
</div>
);
}



Here’s what the above code is doing:

 * Accounts are pulled from the web3Context and, if available, the user’s
   address is displayed in the dapp;
 * If the accounts we have requested are not available, the dapp will produce a
   button that enables the user to give the dapp access to their address;
 * When the user presses that button, the requestAuth function in web3Context is
   called and the injected web3 provider can display a dialog to the user to
   request access. Using React functionality, useCallback is used to set up the
   callback for account request access.

Now, we start the dapp again by running npm start from within the client
directory.

In the browser, we press ‘Request Access’ to request access to the user’s
address, and then accept the request in the Metamask popup (or extension if no
popup). The user’s address will then be displayed. To restart the process,
logging out of Metamask will make the user request access again.

Account Balance

Finally, our third goal is to add to the React component to display the account
balance.

In the code below, we get the lib object, which contains the blockchain data we
want, from the web3Context, which is an initialized instance of web3.js (a
library that Network.js relies upon).

We use lib for the method getBalance to request the balance of an account, which
returns the balance as in value in units of wei
[https://www.investopedia.com/terms/w/wei.asp]. It’s easier to work with in
units of ether, so we convert it with the method fromWei.

Since we want to track the state of the account balance, we use a React-specific
function called useState. We also use useEffect to watch for if the account
address or networkId has changed, and update accordingly.

To get our dapp to display the account balance, we replace the contents of the
component in our Web3Data.js file with the following code:

import React, { useState, useEffect, useCallback } from 'react';
export default function Web3Data(props) {
const { web3Context } = props;
const { networkId, networkName, accounts, providerName, lib } = web3Context;
const [balance, setBalance] = useState(0);
const getBalance = useCallback(async () => {
	let balance = accounts && accounts.length > 0 ? lib.utils.fromWei(await lib.eth.getBalance(accounts[0]), 'ether') : 'Unknown';
	setBalance(balance);
}, [accounts, lib.eth, lib.utils]);
    
useEffect(() => {
getBalance();
}, [accounts, getBalance, networkId]);

const requestAuth = async web3Context => {
	try {
		await web3Context.requestAuth();
	} catch (e) {
		console.error(e);
	}
};
const requestAccess = useCallback((web3Context) => requestAuth(web3Context), []);
return (
<div>
<h3> {props.title} </h3>
	<div>
    Network: {networkId ? `${networkId} – ${networkName}` : 'No connection'}
    </div>
	<div>
    Your address: {accounts && accounts.length ? accounts[0] : 'Unknown'}
    </div>
	<div>
    Your ETH balance: {balance}
    </div>
	<div>
    Provider: {providerName}
    </div>
	{accounts && accounts.length ? (
	<div>
    Accounts & Signing Status: Access Granted
    </div>
	) : !!networkId && providerName !== 'infura' ? (
	<div>
	<button onClick={requestAccess}>Request Access</button>
	</div>
	) : (
	<div></div>
	)}
</div>
);
}



We start the dapp again by running npm start from within the client directory
and ta-da! The dapp should now display the account balance.

What you have now built is a dapp frontend (using Network.js) that can connect
to the Ethereum mainnet and request data from it (using Infura). Users “login”
(using Metamask), and the dapp displays the information the user cares about and
reacts to state changes.

Keep Learning

Our next tutorial will show you how to display the ERC20 balance of a user and
let them transfer it. Further web3 development guides will include topics such
as building with Ethers.js, using OpenZeppelin’s Starter Kits, and more complex
integrations such as setting up Eth Log filters with Truffle’s Drizzle
[https://github.com/trufflesuite/drizzle] framework to react in real time to
blockchain data changes on the frontend. 


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


Never miss a tutorial -- subscribe to our newsletter
[https://infura.us14.list-manage.com/subscribe?u=7bec10aa5be97e80fcb0e7c52&id=13433031de] 
to stay up to date. Ready to test out Infura? Sign up
[https://infura.io/register?&utm_source=infurablog&utm_medium=referral&utm_campaign=tutorials&utm_content=building_dapp_frontends] 
to start building for free!

Building Dapp Frontends with React & Network.js

Deciding whether to run your own Ethereum node (or nodes), outsource your
infrastructure to a Web3 provider like Infura
[https://infura.io/?&utm_source=infurablog&utm_medium=referral&utm_campaign=tutorials&utm_content=versus]
, or deploy a hybrid node solution really depends on your API workload. To help
developers evaluate their options, we’ve built Versus:
[https://github.com/INFURA/versus] an open source API benchmarking tool. Versus
compares your API workload across different node implementations and Web3
providers so you can make data-based decisions. 

Tests run using the Versus tool are 99% reproducible. In this post we step
through a sample test to demonstrate how the tool works, and share the test
parameters and results so others can follow the same method and reproduce them.

Getting Started
This project lives here [https://github.com/INFURA/versus]. Simply grab the 
latest release binary [https://github.com/INFURA/versus/releases] for your
platform, extract it, put it in your $PATH and you’re ready to roll.

How it Works
Versus is a command-line tool that reads lines of JSON-RPC requests from STDIN
and concurrently sends them to multiple endpoints. It validates that the same
results are returned, and compares the time to retrieve them, across each
endpoint.

For example: let’s say we have a file queries.json with lines of the types of
queries that our application performs:

$ cat queries.json

{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber"}

{"jsonrpc":"2.0","id":1,"method":"eth_getBalance","params" ["0x49318b3970C8a82275B440900bE45f27bf682108","latest"]}

{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0x2a0c0dbecc7e4d658f48e01e3fa353f44050c208","latest"]}



We can send those queries to our local node: `cat queries.json | versus "
http://127.0.0.1:8545"


The results would be returned super fast. That's because these are fairly simple
queries – and there are only three of them. If we want to run a few thousand
queries, it’s going to take a bit more time. We can bump up the concurrency of
versus with the --concurrency=20 flag. Add --verbose once or twice to get more
output as the process is going.

We can also run the same queries against multiple endpoints at the same time:

$ export INFURA_API_KEY=”... grab this from your https://infura.io/dashboard”
$ cat many-queries.json | versus -vv --concurrency=50 \
"http://geth-node:8545" \
	"http://parity-node:8545" \
	"https://mainnet.infura.io/v3/${INFURA_API_KEY}"


Some responses may be mismatched, but that’s to be expected. Geth and Parity
don’t always agree on the exact output that certain types of queries should
generate. Note that Websocket support is not implemented yet
[https://github.com/INFURA/versus/issues/11] - pull requests are welcome!

Generating Realistic Queries
Not many of us have a juicy many-queries.json sitting around on our hard drive -
and even if we do, these queries get stale really fast. The performance of a
node on queries that touch recently-mutated state will vary from state that is
super old.

To generate realistic queries, we can use Ethspam
[https://github.com/shazow/ethspam] - another handy open source tool. Ethspam
generates an infinite stream of realistic queries, based on the typical pattern
of RPC methods that Infura receives. It’s not perfect, but it’s very useful in
combination with Versus. After grabbing a binary release, we can pipe it
directly:

$ ethspam | versus -vv --concurrency=50 --stop-after=10000 \
"http://geth-node:8545" \
	"http://parity-node:8545" \
	"https://mainnet.infura.io/v3/${INFURA_API_KEY}"


Output
Below is an example of the output you can expect, once you’ve piped your query
into Versus:

In this example, we’ve used Infura
[https://infura.io/?&utm_source=infurablog&utm_medium=referral&utm_campaign=tutorials&utm_content=versus]
(Core Tier) as the Web3 provider, and a local “anonymous” node on an i3.xlarge
EC2 instance, and ran a test to compare the two.

Results
In this test, the local node was quite limited. Despite many optimizations
(high-IO storage, high memory with increased cache size, etc), requests were
bottlenecked. By comparison, Infura’s concurrency proved to be unbounded (i.e.,
there was no limit to how many requests Infura could respond to, per second). 
Some requests were very fast to serve from the local node, which resulted in a
lower minimum latency time -- however, the average and maximum latency was
significantly and consistently lower for requests through Infura (0.1291s
standard deviation for Infura vs 3.2035s for the local node).

Key Learnings
 1. The mismatched responses presented above were predominantly due to the local
    node disagreeing with Infura about what the latest block number was. If
    Versus is run with the --verbose flag, it will print mismatched results.
    Ethspam included some queries that required an archival node to retrieve.
    Neither the local node nor the Infura Core plan had access to archive-tier
    data, so these particular results matched up;
 2. Ethspam input is random, which means that if you’re using Versus to compare
    separate runs, your results won’t be consistent. When comparing nodes, make
    a single Versus run against multiple endpoints. A single run will confirm
    that the results match. Only make multiple Versus runs against each single
    endpoint if you’re using the exact same input;
 3. When running Versus against a single node, make sure that node is fully
    synced and functional. Nodes like geth will happily respond with an empty
    non-error response, even when it’s not synchronized, without doing any
    actual work. Running simultaneously against a known functioning node helps
    ensure that results are not mismatched.
 4. When running with high concurrency, make sure there are enough samples to
    reach consistent performance. At minimum, we suggest at least x100 requests
    per unit of concurrency. Higher is better!

Get Testing!
Though Versus was built by Infura, it’s intended to be an impartial and open
source project. We encourage ideas and pull requests from the Ethereum community
that seek to make Versus a better, more objective tool that anyone can run.

You can start playing around with Versus [https://github.com/INFURA/versus] now
to compare different node implementations and Web3 providers. Compare a light
node to a full node, compare different kinds of nodes against each other, or
compare Infura against other Web3 providers in high load/concurrency situations. 

Our hope is that developers will find Versus a useful tool to help them evaluate
what’s out there and ultimately find the best solution to power their DApp.


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

Want more Web3 tools? Check out this post
[/new-tools-for-running-ipfs-nodes-196de636f079/?&utm_source=infurablog&utm_medium=referral&utm_campaign=tutorials&utm_content=versus] 
for open source tools that help you interact more seamlessly with IPFS. Ready to
test out Infura? Sign up
[https://infura.io/register?&utm_source=infurablog&utm_medium=referral&utm_campaign=tutorials&utm_content=versus] 
to start building for free!

Engineering

Compare Ethereum API Performance with Versus

JSON RPC, methods, calls, requests - what does it all mean?! When you start
building a dapp on the Ethereum blockchain, you’re introduced to a host of new
concepts, request methods and naming conventions to employ - it can be
overwhelming. The Infura team are experts in web3 infrastructure. We build open
source tools and materials to help more developers interact with Ethereum and
IPFS. In this tutorial, we leverage the collective experience of our team to
bring you an in-depth guide to reading and writing requests to the Ethereum
blockchain, using Infura
[https://infura.io/?&utm_source=infurablog&utm_medium=referral&utm_campaign=tutorials&utm_content=rpcs_tutorial]
.

Key Terms and Concepts
Before jumping into the meat of this tutorial, let’s clarify some key
terminology. Below is a list of important terms and their corresponding
definitions that you need to get familiar with.

Request
A developer interacts with Infura by sending a request through JSON RPC either
over HTTP or WebSocket; as a single request or as a batched array. Requests
follow this format:

{"id":1234, "method": "eth_foo", "params":[...] }

Because you should be posting this to an endpoint that has your v3 key in it, we
can always associate these requests with a key or a project.

Method
The method is essentially what function we are asking an Ethereum node to
execute. This will either request data from the node, execute an EVM function
and return a response, or transmit data to the Ethereum network (send a
transaction). Currently there are 65 methods which are supported by the popular
Ethereum clients (Geth [https://geth.ethereum.org/], Parity
[https://www.parity.io/ethereum/], Besu
[https://www.hyperledger.org/projects/besu], Nethermind [https://nethermind.io]
):

The most commonly used methods are highlighted in bold and comprise the vast
majority of Infura’s traffic:

These methods can be grouped into the following categories:

i) Block Data Related

 * eth_getBlockByHash: retrieves a block's details by its hash (a string
   representing the 32-byte hash of a block);
 * eth_getBlockByNumber: retrieves a block's details by its number (an integer
   block number, or the string "latest", "earliest" or "pending");
 * eth_blockNumber: retrieves the current block number.

These methods retrieve static data about a particular block in the blockchain.
This data is contained in the blockchain headers and could include information
like block number or transactions mined, for example.

ii) Per User (address) Data

 * eth_getTransactionCount: retrieves the nonce of an address (i.e: how many
   transactions have already been mined, per user, for that address). This is
   needed because when you go to send a new transaction, there’s a field called
   ‘the nonce’ which is intended to prevent you from accidentally rebroadcasting
   transactions and sending them out in an order that you didn’t intend.

This method retrieves the simple state data for addresses. It doesn’t matter
whether that address is a user or a smart contract. Any address can have an ETH
balance.

iii) Reading Existing Smart Contract Data

The concept of smart contracts, and interacting with them, is what makes
Ethereum different from other blockchains. A smart contract is two things:

 1. It’s a bit of code, usually written in Solidity, that compiles down into
    byte code - which is understood by the Ethereum Virtual Machine (EVM);
 2. It’s a means of storage. Think of it as halfway between ‘disc storage’ and
    ‘ram.’

Below are the most common methods for interacting with smart contracts:

 * eth_call: retrieves a constant EVM method on a Smart Contract and is the
   primary way to retrieve already mined data from the blockchain about a
   particular smart contract;
 * eth_getLogs: retrieves events published by smart contract transactions. Smart
   contracts can emit logs that are really user defined, so when you’re creating
   this smart contract you can decide the format of these log events. These
   dapps can then see when your smart contract has emitted these events, and
   respond accordingly; 
 * eth_getStorageAt: retrieves raw state storage for a smart contract;
 * eth_getCode: retrieves the compiled EVM code for a smart contract. There is
   no copy of a smart contract’s source code on the blockchain itself. So, for
   example, when you search an address on Etherscan [https://etherscan.io/] and
   the verified code of that smart contract is returned, that all happens off
   chain.

Using eth_call
ERC20 is one standard for how developers can create a token. Almost all wallet
software understands this standard, so if you want to create a token and make it
easier for people to interact with it, ERC20 is a good place to start. 
Eth_call is the most commonly used method for interacting with smart contracts, 
particularly ERC20 contracts. A typical eth_call request looks like this:

At first glance, it’s not clear what any of this information represents. Let’s
break it down:

The "id":1 field is an identifier string which is set by the requester, and
helps make sure the client and server are communicating in the same context. 

The "jsonrpc":"2.0" field specifies the version of the protocol and must be
exactly “2.0”, which the protocol expects.

The from field is the data requester, which could be any wallet address or smart
contract. This field is optional.

The to field is always a smart contract. There are two ways to find out what
that smart contract is:

 1. You can make a request on the blockchain using eth _getCode, but that would
    give you the compiled code. Unless you have tools to reverse-engineer the
    EVM byteCode, you’re not going to immediately know what that means.
 2. You can type the smart contract address into Etherscan. 
    Searching Etherscan is the most common way to find out what type of smart
    contract you’re dealing with. Let’s take the smart contract address 
    0x6B175474E89094C44Da98b954EedeAC495271d0F
    [https://etherscan.io/address/0x6b175474e89094c44da98b954eedeac495271d0f] 
    and type it in to see what happens:

Etherscan tells us that this smart contract is for the ‘Dai Stablecoin (DAI)’.
At this point, we also have the opportunity to inspect the original Solidity
code for this contract and confirm that it’s verified:

Great! Now we know that this address represents an ERC20 contract.

Deep-Dive into ERC20
Created in 2015, ERC20 is a relatively simple token standard and the most common
contract type on Ethereum. Within this standard, an ERC20 token has to implement
the following functions:

 * function totalSupply() public constant returns (uint);
 * function balanceOf(address tokenOwner) public constant returns (uint
   balance);
 * function allowance(address tokenOwner, address spender) public constant
   returns (uint remaining);
 * function transfer(address to, uint tokens) public returns (bool success);
 * function approve(address spender, uint tokens) public returns (bool success);
 * function transferFrom(address from, address to, token uint) public returns
   (bool success). 

At certain times, an ERC20 token also has to emit the following events:

 * event Transfer(address indexed from, address indexed to, uint tokens);
 * event Approval(address indexed tokenOwner, addressed indexed spender, uint
   tokens).

You can view the standard on GitHub
[https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20-token-standard.md] for
more detail about how these functions work and when to emit these events. For
now, let’s try to request the balance for some of the DAI tokens.

We know that our address is 0xDfBaf3E4c7496DAd574a1B842bC85B402BDC298D. 

We also know that the DAI contract address is 
0x6B175474E89094C44Da98b954EedeAC495271d0F.

To query our balance using eth_call, we use the balanceOf function of the token
contract. The JSON-RPC format expects eth_call to have a specific data field
format that requires normalizing the contract function balanceOf to a short 
Function Selector
[https://solidity.readthedocs.io/en/develop/abi-spec.html#function-selector]. To
do this, we take out the names and the type of inputs it takes, and take that as
a string. We then run it through Ethereum’s sha3 keccak hash
[https://solidity.readthedocs.io/en/develop/abi-spec.html#function-selector]:

web3_sha3(“balanceOf(address)”)[0..4]-> 0x70a08231

The first four bytes of this hash comprise it’s 4-byte signature. We then take
this 4-byte signature, pad it with zeros, add our address as an input and send
the eth_call:

This is a hexadecimal number, padded to a 32-byte length with zeroes. If we want
to, we can convert this output to a decimal number by using a hex-to-decimal
converter. This would return the result 3.890227426645114e+24, which is
scientific notation for 3.890227426645114 * 10^24. This is the contract’s
balance of Dai in wei, a standard unit of 10^18.

So finally, divide 3.890227426645114 * 10^24 by 10^18, and ta-da! Now we know
the balance of the wallet address 0xDfBaf3E4c7496DAd574a1B842bC85B402BDC298D in
this contract is 3,890,227.426645114 Dai.

Sending Transactions
Eth_calls are commonly used to read data from a smart contract. But what if you
want to write data to a smart contract?

Let’s say we wanted to call the transfer function. Again, we would need to
normalize the function first. We take the string transfer(address to, uint
tokens) and hash it to get the 4-byte signature. Again, we take that 4-byte
signature, pad it with zeros, insert the address and the amount of tokens, and
package this information into a data string. We then sign the transaction and
send it using eth_sendRawTransaction.

At this point, nodes start broadcasting our transaction out to the rest of the
network. Eventually a miner will get a copy of it, go through all their
proof-of-work stuff, get lucky and find a hash that matches the proof-of-work
and broadcast a block that contains our transaction. Every node that receives
this block reads the transactions within it, re-executes them, and holds our
ERC20 token transaction in the EVM to update.

Gas is sent along with any other values, and is spent running the EVM code. The
miner gets the block reward, plus all the gas spent in transactions. If you’d
like to learn more about how Ethereum mining works, these EthHub docs
[https://docs.ethhub.io/using-ethereum/mining/] are a great start.

Mined Transactions
When a transaction is mined, two important things happen: the on-chain Ethereum
state is changed via contract interactions, and Event Logs are published for
public viewing. Once the Event Logs are published, we can execute JSON-RPC
requests for eth_getLogs to investigate what changed, relative to the events
that we care about, and react to them. 

For example: an event ticketing service that wants to issue off-chain tickets
based on crypto payments, could use eth_getLogs to find payments to their
address, and react to these events by processing some logic in their backend
servers to issue tickets to users.

Using eth_getLogs
In the above sample request, we use the parameters "from block" and "to block" 
to specify the hexadecimal block number that we are interested in retrieving
logs from. Note that if this information is omitted, the method will return
information from "block 0" to "block latest" by default (the entire chain
history) and that’s not ideal. Infura has a cap on requests of 10,000 events per
query. Best practice is to request a single block, as we’ve done in this
example, and do that for each mined block.

What this request is saying to the blockchain is “hey, I want event logs
relating to address 0x6B175474E89094C44Da98b954EedeAC495271d0F emitted in block 
0x91F37C (hexadecimal for block 9565052) that matches topics 
0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef, 
0x000000000000000000000000ee25e1ba53c225d250861c8e5a9a3e0fe19c790e and
0x000000000000000000000000dfbaf3e4c7496dad574a1b842bc85b402bdc298d.

The response returned for this request is an array of events. In the example
we’re using, only one event for one address matched the specified topics.

Topics

Topics are events emitted by smart contracts. If we take a look at the original
DAI ERC20 Solidity contract
[https://etherscan.io/address/0x6b175474e89094c44da98b954eedeac495271d0f#code] 
again 0x6B175474E89094C44Da98b954EedeAC495271d0F, we can see two event
signatures that could be associated with it:

 * 94    event Transfer(address indexed from, address indexed to, uint tokens);
 * 95    event Approval(address indexed tokenOwner, address indexed spender,
   uint tokens).

How do we find out which topic (event) it actually was? You guessed it: we have
to create the Function Selector of the Event and take the hash of it. Let’s try
the event on line 94:

web3.sha3('Approval(address,address,uint256)')

The resulting hash is 
0x8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925. This doesn’t
match the hash provided in the initial request response. Now let’s try the event
on line 95 of the contract:

web3.sha3('Transfer(address,address,uint256)')

Bingo! The resulting hash is 
0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef, which
matches the hash provided in the initial request response. Now we know that 
0xddf25 is the Transfer event.

More Event logs
You might be wondering what the data provided in the request response means:

In this context, data refers to all the ‘non-indexed stuff’ that’s captured in
the events. In our example, for the Transfer topic, data represents the number
of tokens that were transferred. That is, that 0x41f900d25d6693623a6 or
19471.6949921 Dai tokens were transferred from 
ee25e1ba53c225d250861c8e5a9a3e0fe19c790e to 
dfbaf3e4c7496dad574a1b842bc85b402bdc298d. 

This completes our investigation 🎉


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

View our developer documentation
[https://infura.io/docs?&utm_source=infurablog&utm_medium=referral&utm_campaign=tutorials&utm_content=rpcs_tutorial] 
to explore different ways to interact with Infura to read and write Ethereum
data. New to Infura? Sign up
[https://infura.io/register?&utm_source=infurablog&utm_medium=referral&utm_campaign=tutorials&utm_content=rpcs_tutorial] 
and get started for free!

Ethereum RPCs, Methods and Calls

On February 20th, hundreds of attendees, speakers, enthusiasts, and
entrepreneurs gathered in NYC for NFT.NYC [http://nft.nyc], the leading
Non‑Fungible Token (NFT) event, to discuss the latest trends and opportunities
in the emerging NFT ecosystem. During the event, Infura partnered with Horizon
Games [https://horizongames.net/] to bring a SkyWeaver Gaming Tournament to
life. 

Built on Ethereum using Infura’s API
[https://infura.io/?&utm_source=infurablog&utm_medium=referral&utm_campaign=event_recap&utm_content=skyweaver]
, SkyWeaver [https://www.skyweaver.net/] pioneers a new dimension of Play2Earn
gaming by providing a platform for digital trading card gaming. Players can play
casually or compete on the worldwide leaderboard to win cards that become their
property. Once won, the cards can then be used in battles, collected to
construct a legendary deck, or traded and sold in the marketplace. 

During the SkyWeaver Tournament, 16 players battled for a share of the 1,000 DAI
prize pool (provided by Maker) and up to 100 Silver SkyWeaver cards. Tournament
sign ups and DAI payouts were facilitated using a tournament platform that
allows anyone to organize tournaments from start to finish with easy participant
onboarding and smart contract-powered payments. The platform currently showcases
Ethereum-powered payments and prize pool management that is fast and
inexpensive.

Taking home the 500 DAI first place prize was 🥇MaxHS, a veteran SkyWeaver
player and former Hearthstone pro. He edged out 🥈TerrenceM, another well known
NYC local digital card game player, who walked away with 300 DAI.
🥉Cybourgeoisie and 🥉Feihu tied for 3rd and both took home 100 DAI. 

SkyWeaver Finals match. From left to right: TerrenceM, MaxHSSignificant
engineering demands are required to battle-test these new systems as adoption
scales. Infura’s ability to reliably manage scale ultimately led Horizon to
choose Infura as their Infrastructure partner for SkyWeaver.

> “The Infura team had proven their ability to handle this scale. We want to
express our gratitude to the Infura team and are proud to partner with Infura as
our Ethereum node provider as SkyWeaver moves into production ops.”
- Peter Kieltyka, CEO and Chief Architect of Horizon Games

.	.	.


NFT.NYC left us with a lot to be excited for. Inspired by all the excitement
shared by our tournament attendees, I sat down with Chris Gonsalves, Gaming
Partnerships Lead at ConsenSys
[https://consensys.net/?&utm_source=infurablog&utm_medium=referral&utm_campaign=event_recap&utm_content=skyweaver] 
and Michael Wuehler, Co-Founder of Infura
[https://infura.io/?&utm_source=infurablog&utm_medium=referral&utm_campaign=event_recap&utm_content=skyweaver]
, to get their thoughts on what 2020 holds for crypto games and what they
believe to be the most promising NFT use cases.

Why are NFTs gaining popularity in games?
A non-fungible token (NFT) is a unique and non-interchangeable digital asset
which can be used to represent all manner of virtual and real-world goods. NFTs
are gaining popularity because they enhance in-game economies by creating
verifiable digital scarcity and allow players to own (and sell) the assets they
collect. Game items represented by NFTs allow for independent tracking of
ownership history, provenance, and other metadata. In trading card games like
SkyWeaver, this creates a trustable ownership model that follows the same
principles as Magic: The Gathering with its physical assets. You can’t fake
owning a physical asset (for the most part, sans counterfeiting) but faking
digital ownership is incredibly easy without some kind of immutable tracking
mechanism.

In addition to enhanced ownership, blockchain-based games are unlocking more
ways for players to earn and monetize their assets. New concepts emerging such
as Play2Earn will enable skilled players to earn supplemental income from their
time spent playing and create new incentive loops to deepen player engagement.

In what spheres can NFTs be used besides games?
Gaming is a great use case for NFTs, but there are other emerging uses starting
to take shape. NFTs are a type of token that can be used to represent both
digital and physical assets that are verifiably unique. Digital certifications
that represent that someone has accomplished a certain action such as voting,
attending an event, or completing a specific task is another use case that goes
beyond video games. NFTs can be used to track everything from a rare piece of
art to the sushi that ends up on your plate at a restaurant. Traceability with
the foods we eat and products we use is becoming a big area of interest. A rare
cut of Wagyu beef could be tracked using an NFT to record ownership, producer,
age, and each hop it made along the supply chain before hitting your plate.

These concepts can even expand to collectables such as a rare jersey or limited
edition FunkoPops. A Lebron James jersey off the shelf is certainly not valued
the same as one previously worn by the superstar himself. Auctioning off
[https://www.nba.com/kings/blog/sacramento-kings-launch-leagues-first-live-blockchain-powered-auction-platform-authentic] 
authentic pieces of sports memorabilia backed by blockchain assets allows for
rarity verification, chain of ownership, and trackable metadata that will bring
more trust and extensible features to the market of collectibles.

What do you think 2020 holds for NFT crypto gaming?
More game industry veterans are founding and joining studios which are
developing games with built in blockchain features. With more talent, this will
mean the quality of the games will continue to get better and more capital will
flow to studios that have teams with decades of game experience. With the launch
of games like SkyWeaver, all new players will experience owning their first
digital asset. These players may not know at first they’re trading an NFT or
spending a stable token, but over time as they start earning these in-game
currencies and seeing the benefits of more open economies, they will be
incentivized to dig deeper and explore more games and applications built using
blockchain technologies.

Want your game considered for future Tournaments? If it’s built on Ethereum
using Infura’s API, you’re eligible! Submit a link to your game in this thread
[https://community.infura.io/t/your-game-featured-at-the-next-infura-gaming-tournament/1291?&utm_source=infurablog&utm_medium=referral&utm_campaign=event_recap&utm_content=skyweaver] 
for consideration.

Interested in competing in future Tournaments? Register your interest here
[https://community.infura.io/t/your-game-featured-at-the-next-infura-gaming-tournament/1291?&utm_source=infurablog&utm_medium=referral&utm_campaign=event_recap&utm_content=skyweaver] 
with a ‘+1’ and your email to stay up-to-date.

Michael Sanders, Chief Storyteller & Co-Founder, Horizon Games

Infura Blog | Community News and Announcements

Infura Community News and Announcements

Community

SkyWeaver Gaming Tournament Powered by Infura

On February 14-16, 2,000+ attendees gathered for the third annual ETHDenver
[https://www.ethdenver.com/] hackathon for three days of hacking, knowledge
sharing, and community building.
Whether you spent the weekend heads down building new dapps and competing for
sponsor prizes, or jumping between educational panels, workshops, and social
events, ETHDenver was one of the most productive and fun opportunities for a
Web3 developer to learn, engage, and contribute to this growing ecosystem. 

Infura
[http://infura.io/?&utm_source=infurablog&utm_medium=referral&utm_campaign=event_recap&utm_content=ethdenver] 
had engineers and product folks answering your questions at the ConsenSys help
desk and invited teams to compete for a $1000 prize for the best hack utilizing
the Infura API. To win the prize, hackers had to create a useful and unique
decentralized application using either the Infura Ethereum API or IPFS API. Many
other ConsenSys teams were represented, with great hacks produced around custom
MetaMask Snaps [https://github.com/MetaMask/metamask-snaps-beta/wiki/Motivation] 
and MythX smart contract safety analysis [https://docs.mythx.io/en/latest/].

Infura Hackathon Winners and Honourable Mentions
Many hackathon projects found using the Infura API to be the easiest integration
in their hack, with most deciding to use Infura as a Provider in various web3
libraries including ethers.js [https://docs.ethers.io/ethers.js/html/], web3.js,
and web3.py. Even mobile development using the Dart language was represented,
with Infura plugging directly into a library called web3dart. We were impressed
with the breadth of submissions and purposes of the dapps, and we thank and
congratulate the hackers!

Infura Bounty Winners
1x.ag [https://devfolio.co/submissions/xag-leverage-aggregator]

A project by the 1inch.exchange [https://1inch.exchange/] team, this project
created an easy way to get leverage on ERC20 tokens by using elements of the
following protocols: Compound, Fulcrum, Aave and MakerDAO CDPs. By combining a
new type of near-instantaneous loan called a flash loan, together with ChainLink
oracles for on-chain price verification, token owners could trade at a higher
leverage ratio. While most hacks release on testnets, this hack utilized
Infura’s Ethereum API to release on mainnet, which was super impressive.
Congratulations to the team for producing a really useful combination of DeFi
protocol building blocks! 🎉


LedgerLocker [https://github.com/Ryan-Ouyang/ledgerlocker]

This project was in two parts: an underlying smart contract, and a practical
application. The team created a contract that accepted Dai, and converted it to
‘savings Dai’ called ‘DSR’ to gain interest, which accrued while a user was
interacting with the service. After the service was completed, the Dai was
returned and the interest gained could be paid anyway the project designers
wished. The practical application was an Airbnb-like site that accepted user
deposits while renting, with an Arduino-powered lock that was connected to the
smart contract 👏

Honorable Mentions
TallyLock [https://devfolio.co/submissions/tally-lock]

TallyLock aimed to reduce the risk of election fraud by providing a simple and
affordable way to notarize and lock election tally sheets on a public
blockchain, right when they occur, in 3 simple steps. They used the Java library 
web3j [https://github.com/web3j/web3j] with an Infura API key to connect to
testnets. Based in Honduras, the TallyLock team believe that by putting election
results on Ethereum, their notarization process would be cheaper, compared to
the current method, and less susceptible to interference.

CountOnMe [https://devfolio.co/submissions/countonme]

Count on Me was designed specifically to connect patients to donors by blood
type, using geolocation. Built with Dart [https://dart.dev/] and Flutter
[https://flutter.dev/], the app was built to work for both Android and iOS
platforms, with the feature of being able to connect using web3dart
[https://github.com/simolus3/web3dart] through Infura.

DieKittyDie [https://github.com/Can-t-Stop-Won-t-Stop/dragon-kitty-contracts]

Tired of old CryptoKitties in your account? This team created a game that
enabled users to send their Kitties into battle against bosses. If your Kitty
won the battle, you received a treasure chest of Dai. This team used Infura with 
Truffle [https://www.trufflesuite.com/] for deploying their contracts to
Rinkeby.
Over 100 hacks were submitted in total at EthDenver this year. Some strong
themes emerged, with many teams building projects around Defi and Dai, Crypto
Gaming, improved Crypto UX, and planning ahead for Eth 2.0. You can read a full
account of all the winning projects on Medium
[https://medium.com/ethdenver/the-ethdenver-2020-finalists-buffidao-bounty-winners-627fd1b2427a]
. Shout-out to Consensys’s own team for hacking together Metacredits!

Future Events and More Infura Developer Resources
We’re working on building out more tools, tutorials, guides, and documentation
to help you build faster. For the next developer event, if you’d like to get a
headstart on learning how to create a frontend for a web3 project, please check
out and star our new developer-resources section on our github here
[http://github.com/infura/developer-resources]. Please create issues for guides
you’d like to see, and expect many more soon! Future topics include using the
features of Ethereum web3 libraries such as ethers.js, for all the major
languages.

Heading to EthCC?
Infura
[http://infura.io/?&utm_source=infurablog&utm_medium=referral&utm_campaign=event_recap&utm_content=ethdenver] 
and Consensys will be at EthCC [https://ethcc.io/] in Paris in two weeks, where
Infura will unveil an exciting new open source tool we’ve been building. If
you’re heading to this event, make sure to carve out some time to catch this
presentation!

Recent Posts (page 26)

Building Dapp Frontends with React & Network.js

Compare Ethereum API Performance with Versus

Ethereum RPCs, Methods and Calls

SkyWeaver Gaming Tournament Powered by Infura

What You Missed at EthDenver