mirror of https://github.com/embarklabs/embark.git
feat(@embark/site): update blockchain and contracts docs to v5
This commit is contained in:
Jonathan Rainville
parent
162d66b675
commit
9dcf236ab7
|
|
@ -48,13 +48,34 @@ We recommend using [environment variables](https://www.schrodinger.com/kb/1842)
|
|||
- **numAddresses**: Number of addresses you want from the node. Defaults to `1`
|
||||
- **password**: Password file where the password to create and unlock the accounts is. This is required
|
||||
- **privateKey**: Private key string
|
||||
- **privateKeyFile**: Either a file containing comma separated private keys or a keystore (password needed for the latter)
|
||||
- **privateKeyFile**: Either a file containing comma separated private keys or a keystore (password needed for the latter). This can also be set to `random` to generate a random account (useful when testing)
|
||||
- **password**: Password string for the keystore
|
||||
- **mnemonic**: 12 word mnemonic
|
||||
- **addressIndex**: Index where to start getting the addresses. Defaults to `0`
|
||||
- **numAddresses**: Number of addresses to get. Defaults to `1`
|
||||
- **hdpath**: HD derivation path. Defaults to `"m/44'/60'/0'/0/"`
|
||||
|
||||
{% notification info 'Old parameters' %}
|
||||
Please note, `account` has been replaced by `nodeAccounts` and `simulatorMnemonic` by adding a `mnemonic` account in the `accounts` array
|
||||
{% notification info 'Accounts order' %}
|
||||
The order in the accounts array is important. This means that using `nodeAccounts` first, as above, will set the node's account as the `defaultAccount` for deployment.
|
||||
{% endnotification %}
|
||||
|
||||
### Configuring account balance for development
|
||||
|
||||
When in development, we can specify the balance of each account using the `balance` option:
|
||||
|
||||
```
|
||||
module.exports = {
|
||||
development: {
|
||||
deployment: {
|
||||
accounts: [
|
||||
{
|
||||
mnemonic: "12 word mnemonic",
|
||||
balance: "5 ether"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Balances can be specified using [human readable units](/docs/contracts_configuration.html#Human-readable-Ether-units) such as "5 ether" or "200 finney". If no unit is specified the value will be in Wei.
|
||||
|
|
|
|||
|
|
@ -8,37 +8,28 @@ Embark offers a lot of configuration options and most of them already come with
|
|||
|
||||
## Common Parameters
|
||||
|
||||
Here are the common parameters. Again, most of them come with a decent default so don't get too overwhelmed by the amount of options available:
|
||||
Here are the common parameters. You will often need only a few of them to make your Embark node work.
|
||||
|
||||
If you want more configuration options, you can find them [here](/docs/blockchain_configuration.html#Advanced-parameters)
|
||||
|
||||
```
|
||||
module.exports = {
|
||||
default: {
|
||||
enabled: true,
|
||||
rpcHost: "localhost",
|
||||
rpcPort: 8545,
|
||||
rpcCorsDomain: {
|
||||
auto: true,
|
||||
additionalCors: ['localhost:9999']
|
||||
},
|
||||
wsRPC: true,
|
||||
wsOrigins: {
|
||||
auto: true,
|
||||
additionalCors: []
|
||||
},
|
||||
wsHost: "localhost",
|
||||
wsPort: 8546
|
||||
client: "geth"
|
||||
},
|
||||
development: {
|
||||
client: "geth",
|
||||
ethereumClientBin: "geth",
|
||||
datadir: ".embark/development/datadir",
|
||||
networkType: "custom",
|
||||
networkId: 1337,
|
||||
isDev: true,
|
||||
nodiscover: true,
|
||||
maxpeers: 0,
|
||||
proxy: true,
|
||||
targetGasLimit: 8000000
|
||||
development: {
|
||||
clientConfig: {
|
||||
miningMode: 'dev'
|
||||
}
|
||||
},
|
||||
testnet: {
|
||||
endpoint: "https://external-node.com",
|
||||
accounts: [
|
||||
{
|
||||
mnemonic: "12 word mnemonic"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
|
@ -47,11 +38,24 @@ Similar to [configuring Smart Contracts](/docs/contracts_configuration.html), th
|
|||
|
||||
### Parameter descriptions
|
||||
|
||||
Most of the options are self-explanatory, still, here are some brief descriptions.
|
||||
Most of the options are self-explanatory, still, here are some brief descriptions:
|
||||
|
||||
Option | Type: `default` | Value
|
||||
--- | --- | ---
|
||||
`enabled` | boolean: `true` | Whether or not to spawn an Ethereum node
|
||||
`client` | string: `geth` | Client to use for the Ethereum node. Currently supported: `geth` and `parity`
|
||||
`miningMode` | string: `dev` | The mining mode to use for the node.<br/>`dev`: This is a special mode where the node uses a development account as defaultAccount. This account is already funded and transactions are faster.<br/>`auto`: Uses a mining script to mine only when needed.<br/>`always`: Miner is always on.<br/>`off`: Turns off the miner
|
||||
`endpoint` | string | Endpoint to connect to. Works for external endpoints (like Infura) and local ones too (only for nodes started by `embark run`)
|
||||
`accounts` | array | Accounts array for the node and to deploy. When no account is given, defaults to one node account. For more details, go [here](http://localhost:4000/docs/blockchain_accounts_configuration.html)
|
||||
|
||||
## Advanced parameters
|
||||
|
||||
Here are all the parameters you can use to customize your node. Note that they all come with defaults that make it that you don't need to specify those.
|
||||
|
||||
We recommend putting those inside the `clientConfig` object a better structure.
|
||||
|
||||
Option | Type: `default` | Value
|
||||
--- | --- | ---
|
||||
`enabled` | boolean: `true` | Whether or not to spawn an Ethereum node
|
||||
`rpcHost` | string: `localhost` | Host the RPC server listens to
|
||||
`rpcPort` | number: `8545` | Port the RPC server listens to
|
||||
`rpcCorsDomain` | object | The CORS domains the node accepts
|
||||
|
|
@ -61,16 +65,15 @@ Option | Type: `default` | Value
|
|||
`wsOrigins` | object | Same as `rpcCorsDomain`, but for the Websocket server
|
||||
`wsHost` | string: `localhost` | Same as `rpcHost`, but for the Websocket server
|
||||
`wsPort` | number: `8546` | Same as `rpcPort`, but for the Websocket server
|
||||
`client` | string: `geth` | Client to use for the Ethereum node. Currently supported: `geth` and `parity`
|
||||
`ethereumClientBin` | string: `geth` | Path to the client binary. By default, Embark uses the client name as an executable (if it is in the PATH)
|
||||
`datadir` | string | Directory where to put the Node's data (eg: keystores)
|
||||
`networkType` | string: `custom` | Can be: `testnet`, `rinkeby`, `kovan` or custom, in which case, it will use the specified `networkId`
|
||||
`networkId` | number: `1337` | Used when `networkType` is set as `custom`. [List of known network ids](https://github.com/ethereumbook/ethereumbook/blob/3e8cf74eb935d4be495f4306b73de027af95fd97/contrib/devp2p-protocol.asciidoc#known-current-network-ids)
|
||||
`isDev` | boolean: `true` | Whether or not to use the development mode of the Node. This is a special mode where the node uses a development account as defaultAccount. This account is already funded and transactions are faster. It is recommended to start by using `isDev: true` for you project, as it is faster and safer
|
||||
`nodiscover`| boolean: `true` | Disables the peer discovery mechanism when set to `true`
|
||||
`maxpeers` | number: `0` | Maximum number of network peers
|
||||
`proxy` | boolean: `true` | Whether or not Embark should use a proxy to add functionalities. This proxy is used by Embark to see the different transactions that go through, for example, and shows them to you.
|
||||
`targetGasLimit` | number | Artificial target gas floor for the blocks to mine
|
||||
`genesisBlock` | string | The genesis file to use to create the network. This file is used when creating the network. It tells the client the parameters to initiate the node with. You can read more on [genesis blocks here](https://arvanaghi.com/blog/explaining-the-genesis-block-in-ethereum/)
|
||||
|
||||
{% notification info 'Using Parity and Metamask' %}
|
||||
|
||||
|
|
@ -92,15 +95,10 @@ Luckily, Embark has settings to limit the mining to a minimum so that everything
|
|||
Here are common parameters for private net configurations:
|
||||
```
|
||||
privatenet: {
|
||||
networkType: "custom",
|
||||
networkId: 1337,
|
||||
isDev: false,
|
||||
datadir: ".embark/privatenet/datadir",
|
||||
mineWhenNeeded: true,
|
||||
genesisBlock: "config/privatenet/genesis.json",
|
||||
nodiscover: true,
|
||||
maxpeers: 0,
|
||||
proxy: true,
|
||||
clientConfig: {
|
||||
miningMode: 'auto',
|
||||
genesisBlock: "config/privatenet/genesis.json"
|
||||
}
|
||||
accounts: [
|
||||
{
|
||||
nodeAccounts: true,
|
||||
|
|
@ -114,15 +112,12 @@ Note that we can always use the parameters we saw in the [Common parameters sect
|
|||
|
||||
### Parameter descriptions
|
||||
|
||||
Option | Type: `default` | Value
|
||||
Option | Type: `value` | Description
|
||||
--- | --- | ---
|
||||
`isDev` | boolean: `false` | You need to set `isDev` to false to use enable any network that isn't the development one
|
||||
`datadir` | string | Behaves the same way as stated above, but it is recommended to use a different for different networks
|
||||
`mineWhenNeeded` | boolean: `true` | Whether to always mine (`false`) or only mine when there is a transaction (`true`). It is recommended to set `mineWhenNeeded` to `true` as otherwise, you CPU will get massively used.
|
||||
`genesisBlock` | string | The genesis file to use to create the network. This file is used when creating the network. It tell the client the parameters to initiate the node with. You can read more on [genesis blocks here](https://arvanaghi.com/blog/explaining-the-genesis-block-in-ethereum/)
|
||||
`miningMode` | string: `auto` | You need to set `miningMode` to `auto` or `always` so you don't use the development mode
|
||||
`genesisBlock` | string | File to start the chain in a clean state for your private network
|
||||
`accounts` | array | Array of accounts to connect to. Go to the [Accounts configuration](/docs/blockchain_accounts_configuration.html) page to learn more on accounts
|
||||
|
||||
|
||||
## Testnet configuration
|
||||
|
||||
Test networks are networks that are public. Knowing that, if we want to connect to a node that we control, we will first need to synchronize it. This can take hours, as we need to download the blocks that we are missing from the other peers.
|
||||
|
|
@ -151,13 +146,12 @@ Here are the necessary parameters. Again, we can add more to override as you see
|
|||
Option | Type: `default` | Value
|
||||
--- | --- | ---
|
||||
`networkType` | string: `testnet` | Again, used to specify the network. `testnet` here represents Ropsten. You can change the network by using a `networkId` by changing `networkType` to `custom`
|
||||
`syncMode` | string | Blockhain sync mode
|
||||
`syncMode` | string | Blockchain sync mode
|
||||
`syncMode = 'light' `| | Light clients synchronize a bare minimum of data and fetch necessary data on-demand from the network. Much lower in storage, potentially higher in bandwidth
|
||||
`syncMode = 'fast'` | | Faster, but higher store
|
||||
`syncMode = 'full'`| | Normal sync
|
||||
`accounts` | array | Array of accounts to connect to. Go to the [Accounts configuration](/docs/blockchain_accounts_configuration.html) page to learn more on accounts
|
||||
|
||||
|
||||
## Mainnet configuration
|
||||
|
||||
Finally, the main network, a.k.a. mainnet. It may come as no surprise, but to sync to the mainnet, the step and configurations are actually the same as for a [test network](#Testnet-configuration). The only major difference is that the `networkType` needs to be `custom` with the `networkId` set to `1`.
|
||||
|
|
@ -175,4 +169,3 @@ mainnet: {
|
|||
]
|
||||
}
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ module.exports = {
|
|||
...
|
||||
development: {
|
||||
...
|
||||
contracts: {
|
||||
deploy: {
|
||||
SimpleStorage: {
|
||||
...
|
||||
}
|
||||
|
|
@ -34,7 +34,7 @@ Often, Smart Contracts need to be initialized with certain values right after th
|
|||
```
|
||||
...
|
||||
development: {
|
||||
contracts: {
|
||||
deploy: {
|
||||
SimpleStorage: {
|
||||
args: [100]
|
||||
}
|
||||
|
|
@ -48,7 +48,7 @@ The following configuration configures the `SimpleStorage`'s `initialValue` para
|
|||
```
|
||||
...
|
||||
development: {
|
||||
contracts: {
|
||||
deploy: {
|
||||
SimpleStorage: {
|
||||
args: {
|
||||
initialValue: 100
|
||||
|
|
@ -67,7 +67,7 @@ Both, `gas` and `gasPrice` can be configured for each Smart Contract. If we don'
|
|||
...
|
||||
development: {
|
||||
gas: 'auto',
|
||||
contracts: {
|
||||
deploy: {
|
||||
SimpleStorage: {
|
||||
args: [100],
|
||||
gas: 800000,
|
||||
|
|
@ -93,7 +93,7 @@ All we have to do is specifying the name of the Smart Contract we're interested
|
|||
|
||||
```
|
||||
...
|
||||
contracts: {
|
||||
deploy: {
|
||||
SimpleStorage: {
|
||||
args: [100, '$OtherContract']
|
||||
},
|
||||
|
|
@ -111,14 +111,14 @@ We can prevent Embark from deploying any of our Smart Contracts by using the `de
|
|||
```
|
||||
...
|
||||
development:
|
||||
contracts: {
|
||||
deploy: {
|
||||
SimpleStorage: {
|
||||
args: [100]
|
||||
}
|
||||
}
|
||||
},
|
||||
production: {
|
||||
contracts: {
|
||||
deploy: {
|
||||
SimpleStorage: {
|
||||
deploy: false
|
||||
}
|
||||
|
|
@ -138,7 +138,7 @@ There are two possible strategy options:
|
|||
|
||||
```
|
||||
strategy: 'explicit' // 'implicit' is the default
|
||||
contracts: {
|
||||
deploy: {
|
||||
...
|
||||
}
|
||||
```
|
||||
|
|
@ -152,7 +152,7 @@ This can then be combined with [disabling the deployment](#Disabling-deployment)
|
|||
|
||||
```
|
||||
...
|
||||
contracts: {
|
||||
deploy: {
|
||||
Currency: {
|
||||
deploy: false,
|
||||
},
|
||||
|
|
@ -178,7 +178,7 @@ The following example configures `UserStorage` to be a Smart Contract instance t
|
|||
|
||||
```
|
||||
...
|
||||
contracts: {
|
||||
deploy: {
|
||||
UserStorage: {
|
||||
address: '0x123456'
|
||||
}
|
||||
|
|
@ -186,6 +186,22 @@ contracts: {
|
|||
...
|
||||
```
|
||||
|
||||
## Using accounts in arguments
|
||||
|
||||
Accounts can be used as arguments using Embark's built-in interpolation syntax, similar to referring to Smart Contract instances.
|
||||
|
||||
```
|
||||
module.exports = {
|
||||
development: {
|
||||
deploy: {
|
||||
MyContractThatNeedsAccountAddresses: {
|
||||
args: ['$accounts[0]', '$accounts[4]']
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Configuring source files
|
||||
|
||||
By default Embark will look for Smart Contracts inside the folder that's configured in the application's [embark.json](configuration.html#contracts), the default being the `contracts` folder. However, if we want to change the location to look for a single Smart Contract's source, or need to compile a third-party Smart Contract to get hold of its ABI, we can do so by using the `file` property.
|
||||
|
|
@ -194,7 +210,7 @@ By default Embark will look for Smart Contracts inside the folder that's configu
|
|||
|
||||
```
|
||||
...
|
||||
contracts: {
|
||||
deploy: {
|
||||
SimpleStorage: {
|
||||
file: './some_folder/simple_storage.sol',
|
||||
args: [100]
|
||||
|
|
@ -207,7 +223,7 @@ If Embark doesn't find the file in the specified path, it'll expect it to be a p
|
|||
|
||||
```
|
||||
...
|
||||
contracts: {
|
||||
deploy: {
|
||||
ERC20: {
|
||||
file: 'openzeppelin-solidity/contracts/token/ERC20/ERC20.sol'
|
||||
}
|
||||
|
|
@ -219,7 +235,7 @@ Embark even supports reading the source from `https`, `git`, `ipfs` and `bzz` UR
|
|||
|
||||
```
|
||||
...
|
||||
contracts: {
|
||||
deploy: {
|
||||
ERC725: {
|
||||
file: 'git://github.com/status/contracts/contracts/identity/ERC725.sol#develop'
|
||||
},
|
||||
|
|
@ -243,7 +259,7 @@ The following example configures `SimpleStorage` to be already deployed somewher
|
|||
|
||||
```
|
||||
...
|
||||
contracts: {
|
||||
deploy: {
|
||||
SimpleStorage: {
|
||||
address: '0x0bFb07f9144729EEF54A9057Af0Fcf87aC7Cbba9',
|
||||
abiDefinition: [...]
|
||||
|
|
@ -267,7 +283,7 @@ That way, you don't need to have the contract on disk or even deploy it, if the
|
|||
Here is how you can do it:
|
||||
|
||||
<pre><code class="javascript">...
|
||||
contracts: {
|
||||
deploy: {
|
||||
SimpleStorage: {
|
||||
artifact: './path/to/SimpleStorage.json'
|
||||
}
|
||||
|
|
@ -327,7 +343,7 @@ The following example ensures `ERC20` won't be tracked and therefore redeployed
|
|||
|
||||
```
|
||||
...
|
||||
contracts: {
|
||||
deploy: {
|
||||
ERC20: {
|
||||
track: false
|
||||
}
|
||||
|
|
@ -359,7 +375,7 @@ We can specify a condition that decides whether a contract should be deployed by
|
|||
|
||||
```
|
||||
...
|
||||
contracts: {
|
||||
deploy: {
|
||||
ERC20: {
|
||||
deployIf: async (dependencies) => {
|
||||
return await dependencies.contracts.Manager.methods.isUpdateApproved().call();
|
||||
|
|
@ -399,7 +415,7 @@ SimpleStorage: {
|
|||
Wheras this configuration here runs the hook before all Smart Contracts are being deployed:
|
||||
|
||||
```
|
||||
contracts: {
|
||||
deploy: {
|
||||
SimpleStorage: { ... }
|
||||
beforeDeploy: async () => {
|
||||
console.log('Before all deploy');
|
||||
|
|
@ -413,7 +429,7 @@ We can specify the `onDeploy` hook to execute code, right after a contract has b
|
|||
|
||||
```
|
||||
...
|
||||
contracts: {
|
||||
deploy: {
|
||||
SimpleStorage: {
|
||||
args: [100],
|
||||
onDeploy: async (dependencies) => {
|
||||
|
|
@ -445,7 +461,7 @@ If we want to execute code once all of our Smart Contracts have been deployed, E
|
|||
|
||||
```
|
||||
...
|
||||
contracts: {
|
||||
deploy: {
|
||||
SimpleStorage: {
|
||||
args: [100]
|
||||
},
|
||||
|
|
@ -496,7 +512,7 @@ SmartContractName > onDeploy > [YOUR MESSAGE]
|
|||
The `logger` is injected as part of the `dependencies` object, so we can use it like this:
|
||||
|
||||
```
|
||||
contracts: {
|
||||
deploy: {
|
||||
SimpleStorage: {
|
||||
onDeploy: async (dependencies) => {
|
||||
dependencies.logger.info('Hello from onDeploy!');
|
||||
|
|
@ -519,7 +535,7 @@ Let's take the simple Smart Contract configuration from the [configuring gas and
|
|||
|
||||
```
|
||||
...
|
||||
contracts: {
|
||||
deploy: {
|
||||
SimpleStorage: {
|
||||
args: [100],
|
||||
gas: 800000,
|
||||
|
|
@ -533,7 +549,7 @@ This can as well be written as:
|
|||
|
||||
```
|
||||
...
|
||||
contracts: {
|
||||
deploy: {
|
||||
SimpleStorage: {
|
||||
args: [100],
|
||||
gas: '800 Kwei',
|
||||
|
|
|
|||
|
|
@ -2,224 +2,8 @@ title: Accounts & Deployment
|
|||
layout: docs
|
||||
---
|
||||
|
||||
Embark is very flexible when it comes to configuring wallet accounts for deployment. Whether we want to deploy from generated node accounts, or our own key store file. In this guide we'll take a closer look at how to configure wallet accounts for deployment of Smart Contracts.
|
||||
|
||||
## Specifying a deployment account
|
||||
|
||||
We can specify from which account we want to deploy a Smart Contract using the `from` or `fromIndex` options of a Smart Contract's configuration. The `from` parameter is a string which can be any account address:
|
||||
|
||||
```
|
||||
...
|
||||
contracts: {
|
||||
Currency: {
|
||||
from: '0xfeedaa0e295b09cd84d6ea2cce390eb443bcfdfc',
|
||||
args: [100]
|
||||
}
|
||||
}
|
||||
...
|
||||
```
|
||||
|
||||
`fromIndex` on the other hand, configures the index of the accounts array that is returned by `web3.eth.getAccounts()`. The following code configures the `Currency` Smart Contract to deployed from the first address:
|
||||
|
||||
|
||||
```
|
||||
...
|
||||
contracts: {
|
||||
Currency: {
|
||||
fromIndex: 0
|
||||
args: [100]
|
||||
}
|
||||
}
|
||||
...
|
||||
```
|
||||
|
||||
If both options are configured, `from` takes precedence.
|
||||
|
||||
## Using wallet accounts
|
||||
|
||||
We can use our own wallet accounts by specifying either a private key, a mnemonic, or a private key file. Let's take a look at how this is done.
|
||||
|
||||
{% notification danger 'A note on private keys in production' %}
|
||||
|
||||
While it's very convenient to put private keys, passphrases and mnemonics in the configuration file, we highly recommend doing this only sparingly and ideally move sensitive data into environment variables instead.
|
||||
|
||||
Please consider the following configuration options as development-only options and refer to [using environment variables for production](#Using-environment-variables-for-production), once you plan to deploy your application on Mainnet.
|
||||
|
||||
{% endnotification %}
|
||||
|
||||
### Using a private key
|
||||
|
||||
Using a private key is just a matter of adding it as `privateKey` option.
|
||||
|
||||
```
|
||||
module.exports = {
|
||||
testnet: {
|
||||
deployment: {
|
||||
accounts: [
|
||||
{
|
||||
privateKey: "your_private_key"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
This can also be set to `random` to generate a random account (useful when testing):
|
||||
|
||||
```
|
||||
privateKey: "random"
|
||||
```
|
||||
|
||||
### Using a private key store
|
||||
|
||||
Another option is to use an existing private key store file. Instead of writing the private key straight into the configuration file, we specify a path to a private key store file using the `privateKeyFile` option. Key store files need to be decrypted using a passphrase. That's why `privateKeyFile` needs to be used in combination with the `password` option, which is the passphrase needed to unlock the key store file:
|
||||
|
||||
```
|
||||
module.exports = {
|
||||
testnet: {
|
||||
deployment: {
|
||||
accounts: [
|
||||
{
|
||||
privateKeyFile: 'path/to/key/store/file',
|
||||
password: 'some super secret password'
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Using a Mnemonic
|
||||
|
||||
Last but not least it's also possible to use a mnemonic to generate a wallet and specify which of the wallet's addresses should be used for deployment. It's also possible to configure an HD derivation path if more control is needed.
|
||||
|
||||
```
|
||||
module.exports = {
|
||||
testnet: {
|
||||
deployment: {
|
||||
accounts: [
|
||||
{
|
||||
mnemonic: "12 word mnemonic",
|
||||
addressIndex: "0", // Optional. The index to start getting the address
|
||||
numAddresses: "1", // Optional. The number of addresses to get
|
||||
hdpath: "m/44'/60'/0'/0/" // Optional. HD derivation path
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Using node accounts
|
||||
|
||||
Some blockchain node clients such as Geth allow for generating accounts. This is very useful for development purposes. We can tell Embark to make use of those accounts, by using the `nodeAccounts` option and setting it to `true`.
|
||||
|
||||
In addition to that, we can combine the generated node accounts with our own custom accounts, simply by extending the `accounts` array with any of the configurations covered earlier:
|
||||
|
||||
```
|
||||
module.exports = {
|
||||
testnet: {
|
||||
deployment: {
|
||||
accounts: [
|
||||
{
|
||||
nodeAccounts: true
|
||||
},
|
||||
{
|
||||
privateKey: '...'
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
{% notification info 'Accounts order' %}
|
||||
The order in the accounts array is important. This means that using `nodeAccounts` first, as above, will set the node's account as the `defaultAccount` for deployment.
|
||||
{% endnotification %}
|
||||
|
||||
## Using environment variables for production
|
||||
|
||||
There are special security considerations to have when deploying to production. Chiefly, no private keys, private key files or mnemonics should be present in source control. Instead, we recommend using environment variables to pass those values in, like this:
|
||||
|
||||
```
|
||||
const secrets = require('secrets.json'); // should NOT be in source control
|
||||
|
||||
module.exports = {
|
||||
mainnet: {
|
||||
deployment: {
|
||||
accounts: [
|
||||
{
|
||||
privateKeyFile: secrets.privateKeyFilePath,
|
||||
password: secrets.password
|
||||
},
|
||||
{
|
||||
mnemonic: process.env.DAPP_MNEMONIC, // An environment variable is also possible
|
||||
addressIndex: "0", // Optional. The index to start getting the address
|
||||
numAddresses: "1", // Optional. The number of addresses to get
|
||||
hdpath: "m/44'/60'/0'/0/" // Optional. HD derivation path
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Configuring account balance for development
|
||||
When in development, we can specify the balance of each account using the `balance` option:
|
||||
|
||||
```
|
||||
module.exports = {
|
||||
development: {
|
||||
deployment: {
|
||||
accounts: [
|
||||
{
|
||||
mnemonic: "12 word mnemonic",
|
||||
balance: "5 ether"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Balances are specified using a [human readable units](/docs/contracts_configuration.html#Human-readable-Ether-units) such as "5 ether" or "200 finney". If no unit is specified the value will be in Wei.
|
||||
|
||||
## Using accounts in arguments
|
||||
|
||||
Account can be used as arguments using Embark's built-in interpolation syntax, similar to referring to Smart Contract instances.
|
||||
|
||||
```
|
||||
module.exports = {
|
||||
development: {
|
||||
contracts: {
|
||||
MyContractThatNeedsAccountAddresses: {
|
||||
args: ['$accounts[0]', '$accounts[4]']
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
Accounts configuration has moved to the blockchain config. You can learn more [here](/docs/blockchain_accounts_configuration.html).
|
||||
|
||||
## Deploying to Infura
|
||||
|
||||
We can also connect to a remote Infura.io blockchain node as per instructions below. The following specifies the configuration for the web3 provider, not the blockchain node configuration itself.
|
||||
|
||||
```
|
||||
module.exports = {
|
||||
testnet: {
|
||||
deployment:{
|
||||
accounts: [
|
||||
{
|
||||
// your accounts here, see above for details
|
||||
}
|
||||
],
|
||||
host: "rinkeby.infura.io/INFURA_TOKEN_HERE",
|
||||
port: false,
|
||||
protocol: 'https',
|
||||
type: "rpc"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
To deploy to Infura or another endpoint, just use the blockchain `endpoint`. More details [here](/docs/blockchain_configuration.html)
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ module.exports = {
|
|||
"http://localhost:8545"
|
||||
],
|
||||
gas: "auto",
|
||||
contracts: {
|
||||
deploy: {
|
||||
SimpleStorage: {
|
||||
args: [100]
|
||||
}
|
||||
|
|
@ -49,7 +49,7 @@ As mentioned earlier, the `default` environment can be easily extended and overw
|
|||
module.exports = {
|
||||
...
|
||||
custom: {
|
||||
contracts: {
|
||||
deploy: {
|
||||
SimpleStorage: {
|
||||
args: [200]
|
||||
}
|
||||
|
|
|
|||
Loading…
Reference in New Issue