2019-08-21 08:53:47 +03:00
|
|
|
_section: Providers
|
|
|
|
|
|
|
|
A **Provider** is an abstraction of a connection to the
|
|
|
|
Ethereum network, providing a concise, consistent interface
|
|
|
|
to standard Ethereum node functionality.
|
|
|
|
|
|
|
|
The ethers.js library provides several options which should
|
|
|
|
cover the vast majority of use-cases, but also includes the
|
|
|
|
necessary functions and classes for sub-classing if a more
|
|
|
|
custom configuration is necessary.
|
|
|
|
|
2020-05-08 10:24:40 +03:00
|
|
|
Most users should be able to simply use the [[providers-getDefaultProvider]].
|
2019-08-21 08:53:47 +03:00
|
|
|
|
|
|
|
|
2020-05-08 10:24:40 +03:00
|
|
|
_subsection: Default Provider @<providers-getDefaultProvider>
|
2019-08-21 08:53:47 +03:00
|
|
|
|
|
|
|
The default provider is the safest, easiest way to begin
|
|
|
|
developing on //Ethereum//, and it is also robust enough
|
|
|
|
for use in production.
|
|
|
|
|
2020-05-08 10:24:40 +03:00
|
|
|
It creates a [[FallbackProvider]] connected to as many backend
|
2019-08-21 08:53:47 +03:00
|
|
|
services as possible. When a request is made, it is sent to
|
|
|
|
multiple backends simulatenously. As responses from each backend
|
|
|
|
are returned, they are checked that they agree. Once a quorum
|
|
|
|
has been reached (i.e. enough of the backends agree), the response
|
|
|
|
is provided to your application.
|
|
|
|
|
|
|
|
This ensures that if a backend has become out-of-sync, or if it
|
|
|
|
has been compromised that its responses are dropped in favor of
|
|
|
|
responses that match the majority.
|
|
|
|
|
2020-05-08 10:24:40 +03:00
|
|
|
_property: ethers.getDefaultProvider([ network, [ options ] ]) => [[Provider]]
|
2019-08-21 08:53:47 +03:00
|
|
|
Returns a new Provider, backed by multiple services, connected
|
|
|
|
to //network//. Is no //network// is provided, **homestead**
|
|
|
|
(i.e. mainnet) is used.
|
|
|
|
|
2020-05-08 10:24:40 +03:00
|
|
|
The //options// is an object, with the following properties:
|
|
|
|
|
|
|
|
_table: Option Properties
|
|
|
|
|
|
|
|
$Alchemy: [[link-alchemy]] API Token
|
|
|
|
$Etherscan: [[link-etherscan]] API Token
|
|
|
|
$Infura: [[link-infura]] Project ID or ProjectID and Project Secret
|
|
|
|
$Quroum: The number of backends that must agree
|
|
|
|
//(default: 2 for mainnet, 1 for testnets)//
|
|
|
|
|
|
|
|
| **Property** | **Description** |
|
|
|
|
| alchemy | $Alchemt |
|
|
|
|
| etherscan | $Etherscan |
|
|
|
|
| infura | $Infura |
|
|
|
|
| quorum | $Quorum |
|
|
|
|
|
|
|
|
_note: Note: API Keys
|
|
|
|
|
|
|
|
It is highly recommended for production services that to acquire
|
|
|
|
and specify an API Key for each sercice.
|
|
|
|
|
|
|
|
The deafult API Keys used by ethers are shared across all users,
|
|
|
|
so services may throttle all services that are using the default
|
|
|
|
API Keys during periods of load without realizing it.
|
|
|
|
|
|
|
|
Many services also have monitoring and usage metrics, which are
|
|
|
|
only available if an API Key is specifie. This allows tracking
|
|
|
|
how many requests are being sent and which methods are being
|
|
|
|
used the most.
|
|
|
|
|
|
|
|
Some services also provide additional paid features, whichare only
|
|
|
|
available when specifying an API Key.
|
|
|
|
|
|
|
|
|
2019-08-21 08:53:47 +03:00
|
|
|
_subsection: Provider Documentation
|
|
|
|
|
|
|
|
_toc:
|
|
|
|
provider
|
|
|
|
jsonrpc-provider
|
|
|
|
api-providers
|
|
|
|
other
|
|
|
|
types
|