diff --git a/packages/attestation-service/README.md b/packages/attestation-service/README.md index 9e7ecf1fa2d..b2dc56afb54 100644 --- a/packages/attestation-service/README.md +++ b/packages/attestation-service/README.md @@ -8,8 +8,8 @@ You can use the following environment variables to configure the attestation ser - `DATABASE_URL` - The URL under which your database is accessible, currently supported are `postgres://`, `mysql://` and `sqlite://` - `CELO_PROVIDER` - The URL under which a celo blockchain node is reachable. This node should also have the `ATTESTATION_SIGNER_ADDRESS` unlocked for signing of the attestations themselves. -- `ACCOUNT_ADDRESS` - The address of the account on the `Accounts` smart contract -- `ATTESTATION_SIGNER_ADDRESS` - The address of the key with which attestations should be signed. You could use your account for attestations, but really you should authorize a dedicated attestation key +- `CELO_VALIDATOR_ADDRESS` - The address of the validator on the `Accounts` smart contract +- `ATTESTATION_SIGNER_ADDRESS` - The address of the key with which attestations should be signed. - `APP_SIGNATURE` - The hash with which clients can auto-read SMS messages on android - `SMS_PROVIDERS` - A comma-separated list of providers you want to configure, we currently support: diff --git a/packages/attestation-service/config/.env.development b/packages/attestation-service/config/.env.development index 76186201b78..b4feb5ef829 100644 --- a/packages/attestation-service/config/.env.development +++ b/packages/attestation-service/config/.env.development @@ -1,7 +1,6 @@ DATABASE_URL=sqlite://db/dev.db -CELO_PROVIDER=https://integration-forno.celo-testnet.org -ACCOUNT_ADDRESS=0xE6e53b5fc2e18F51781f14a3ce5E7FD468247a15 -ATTESTATION_KEY=x +CELO_PROVIDER=http://localhost:8545 +CELO_VALIDATOR_ADDRESS=0xE6e53b5fc2e18F51781f14a3ce5E7FD468247a15 APP_SIGNATURE=x SMS_PROVIDERS=twilio,nexmo NEXMO_KEY=x diff --git a/packages/attestation-service/src/requestHandlers/attestation.ts b/packages/attestation-service/src/requestHandlers/attestation.ts index 38c51b69035..c1fec847eec 100644 --- a/packages/attestation-service/src/requestHandlers/attestation.ts +++ b/packages/attestation-service/src/requestHandlers/attestation.ts @@ -40,12 +40,15 @@ export function getAttestationSignerAddress() { } export function getAccountAddress() { - if (process.env.ACCOUNT_ADDRESS === undefined || !isValidAddress(process.env.ACCOUNT_ADDRESS)) { - console.error('Did not specify valid ACCOUNT_ADDRESS') - throw new Error('Did not specify valid ACCOUNT_ADDRESS') + if ( + process.env.CELO_VALIDATOR_ADDRESS === undefined || + !isValidAddress(process.env.CELO_VALIDATOR_ADDRESS) + ) { + console.error('Did not specify valid CELO_VALIDATOR_ADDRESS') + throw new Error('Did not specify valid CELO_VALIDATOR_ADDRESS') } - return toChecksumAddress(process.env.ACCOUNT_ADDRESS) + return toChecksumAddress(process.env.CELO_VALIDATOR_ADDRESS) } function toBase64(str: string) { diff --git a/packages/docs/getting-started/baklava-testnet.md b/packages/docs/getting-started/baklava-testnet.md index 901fc2239a2..bdc3e7e2668 100644 --- a/packages/docs/getting-started/baklava-testnet.md +++ b/packages/docs/getting-started/baklava-testnet.md @@ -11,7 +11,7 @@ You have some instructions about running the network by operating a [full node]( Please refer to [Key Concepts](../overview.md#background-and-key-concepts) for background on blockchains and an explanation of terms used in the section. {% hint style="warning" %} -The Baklava Bet Network is designed for testing and experimentation by developers. Its tokens hold no real world economic value. The testnet software will be upgraded and the entirety of its data reset on a regular basis. This will erase your accounts, their balance and your transaction history. The testnet software will be upgraded on a regular basis. You may encounter bugs and limitations with the software and documentation. +Baklava, the incentivized testnet for the Celo Protocol. It is an early, partially audited release betanet version of the Celo Protocol. The Great Celo Stake Off allows eligible participants to engage with Baklava and, related to that participation and subject to these Terms and Conditions, eligible participants will have the opportunity to receive Celo Gold at the Mainnet launch of the Celo Protocol. The Great Celo Stake Off will operate in phases, with each phase focusing on a different part of the protocol or infrastructure to test. Transitions between each phase may include a full network reset, a hard fork, or an upgrade. {% endhint %} Please help us improve Celo by asking questions on the [Forum](https://forum.celo.org)! diff --git a/packages/docs/getting-started/running-a-validator.md b/packages/docs/getting-started/running-a-validator.md index 20527123f31..c894c46bc79 100644 --- a/packages/docs/getting-started/running-a-validator.md +++ b/packages/docs/getting-started/running-a-validator.md @@ -21,15 +21,19 @@ - [Run for election](#run-for-election) - [Stop Validating](#stop-validating) -This section explains how to get a Validator node running on the network, using a Docker image that was built for this purpose. Most of this process is the same as running a full node, but with a few additional steps. +This section explains how to get a Validator node running on the network, using the same docker image used for running a full node. -Validators help secure the Celo network by participating in Celo’s Proof of Stake protocol. Validators are organized into Validator Groups, analogous to parties in representative democracies. A Validator Group is essentially an ordered list of Validators, along with metadata like name and URL. +Validators help secure the Celo network by participating in Celo’s Proof of Stake protocol. Validators are organized into Validator Groups, analogous to parties in representative democracies. A Validator Group is essentially an ordered list of Validators. Just as anyone in a democracy can create their own political party, or seek to get selected to represent a party in an election, any Celo user can create a Validator group and add themselves to it, or set up a potential Validator and work to get an existing Validator group to include them. While other Validator Groups will exist on the Celo Networks, the fastest way to get up and running with a Validator will be to register a Validator Group, register a Validator, and add that Validator to your Validator Group. The addresses used to register Validator Groups and Validators must be unique, which will require that you create two accounts in the step-by-step guide below. -You can find more details about Celo mission and why becoming a Validator [at the following page](https://medium.com/celohq/calling-all-chefs-become-a-celo-validator-c75d1c2909aa). +Because of the importance of Validator security and availability, Validators are expected to run one or more additional "proxy" nodes. In this setup, the proxy node connects with the rest of the network, and the machine running the Validator communicates only with the proxy, ideally via a private network. + +Additionally, Validators are expected to run an [Attestation Service](https://github.com/celo-org/celo-monorepo/tree/master/packages/attestation-service) as part of the [lightweight identity protocol](/celo-codebase/protocol/identity), to provide attestations that allow users to map their phone number to a Celo address. + +You can find more details about Celo mission and why to become a Validator [at the following page](https://medium.com/celohq/calling-all-chefs-become-a-celo-validator-c75d1c2909aa). {% hint style="info" %} If you are starting up a Validator, please consider leaving it running for a few weeks to support the network. @@ -39,14 +43,18 @@ If you are starting up a Validator, please consider leaving it running for a few ### Hardware requirements -Because Celo network is based in Proof of Stake, the hardware requirements are not very high. Proof of Stake consensus is not so CPU intensive as Proof of Work but has a higher requirements of network connectivity and latency. Here you have a list of the standard requirements for running a Validator node: +Celo is a Proof of Stake network, which has different hardware requirements than a Proof of Work network. Proof of Stake consensus is less CPU intensive, but has higher network connectivity and latency requirements. Below is a list of standard requirements for running a Validator node on the Celo Network: - Memory: 8 GB RAM - CPU: Quad core 3GHz (64-bit) - Disk: 256 GB of SSD storage - Network: At least 1 GB input/output dual Ethernet -It is recommended to run the Validator node in an environment that facilitates a 24/7 execution. Deployments in a top-tier datacenter facilitates the security and better uptimes. +The recommended Celo Validator setup involves continually running three nodes on three separate machines: + +- 1 Validator node in a highly secure environment like a top-tier datacenter with 24/7 execution +- 1 Validator Proxy node, in a highly available, environment, but with lesser security requirements +- 1 Attestation node that runs the Attestation service and signs attestations, which can be a light node, and thus has lower requirements ### Software requirements @@ -72,35 +80,50 @@ When you see text in angle brackets <>, replace them and the text inside w ## Instructions -This section explains how to get a Validator node running on the Baklava network, using a Docker image that was built for this purpose. Most of this process is the same as running a full node, but with a few additional steps. +### Key Management + +Private keys are the central primitive of any cryptographic system and need to be handled with extreme care. Loss of your private key can lead to irreversible loss of value. + +#### Unlocking -If you are re-running these instructions, the Celo Docker image may have been updated, and it's important to get the latest version. +Celo nodes store private keys encrypted on disk with a password, and need to be "unlocked" before use. Private keys can be unlocked in two ways: -To run a complete Validator it's necessary to execute the following components: +1. By running the `celocli account:unlock` command. Note that the node must have the "personal" RPC API enabled in order for this command to work. +2. By setting the `--unlock` flag when starting the node. -- The Validator software -- A Proxy that acts as an intermediary for the Validator requests -- The Attestation Service +It is important to note that when a key is unlocked you need to be particularly careful about enabling access to the node's RPC APIs. -The Proxy is not mandatory but highly recommended. It allows to protect the Validator node from outside connections and hide the Validator behind that Proxy from other nodes of the network. +#### Account and Signer keys + +Running a Celo Validator node requires the management of several different keys, each with different privileges. Keys that need to be accessed frequently (e.g. for signing blocks) are at greater risk of being compromised, and thus have more limited permissions, while keys that need to be accessed infrequently (e.g. for locking Celo Gold) are less onerous to store securely, and thus have more expansive permissions. Below is a summary of the various keys that are used in the Celo network, and a description of their permissions. + +| Name of the key | Purpose | +| ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Account key | This is the key with the highest level of permissions, and is thus the most sensitive. It can be used to lock and unlock Celo Gold, and authorize vote, validator, and attestation keys. Note that the account key also has all of the permissions of the other keys. | | +| Validator signer key | This is the key that has permission to register and manage a Validator or Validator Group, and participate in BFT consensus. | | +| Vote signer key | This key can be used to vote in Validator elections and on-chain governance. | | +| Attestation signer key | This key is used to sign attestations in Celo's lightweight identity protocol. | | + +Note that account and signer keys must be unique and may not be reused. ### Environment variables -| Variable | Explanation | -| ----------------------------- | ----------------------------------------------------------------- | -| CELO_IMAGE | The Docker image used for the Validator and Proxy containers | | -| NETWORK_ID | The Celo network chain ID | | -| URL_VERIFICATION_POOL | URL for the Verification pool for the attestation process | | -| CELO_VALIDATOR_GROUP_ADDRESS | The public address for the validation group | | -| CELO_VALIDATOR_ADDRESS | The public address for the Validator instance | | -| CELO_PROXY_ADDRESS | The public address for the Proxy instance | | -| CELO_VALIDATOR_BLS_PUBLIC_KEY | The BLS public key for the Validator instance | | -| CELO_VALIDATOR_BLS_SIGNATURE | A proof-of-possession of the BLS public key | | -| PROXY_ENODE | The enode address for the Validator proxy | | -| PROXY_IP | The Proxy container internal IP address from docker pool address | | -| ATTESTATION_SIGNER_ADDRESS | The address of the attestation signer authorized by the validator | | -| ATTESTATION_SERVICE_URL | The URL to access the Attestation Service deployed | | -| METADATA_URL | The URL to access the metadata file for your Attestation Service | | +| Variable | Explanation | +| ----------------------------- | ------------------------------------------------------------------------- | +| CELO_IMAGE | The Docker image used for the Validator and Proxy containers | | +| NETWORK_ID | The Celo Baklava network chain ID | | +| CELO_VALIDATOR_GROUP_ADDRESS | The account address for the Validator Group | | +| CELO_VALIDATOR_ADDRESS | The account address for the Validator | | +| CELO_VALIDATOR_SIGNER_ADDRESS | The address of the validator signer authorized by the validator account | | +| CELO_VALIDATOR_SIGNER_POP | The proof-of-possession of the validator signer key | | +| CELO_VALIDATOR_BLS_PUBLIC_KEY | The BLS public key for the Validator instance | | +| CELO_VALIDATOR_BLS_SIGNATURE | A proof-of-possession of the BLS public key | | +| PROXY_ENODE | The enode address for the Validator proxy | | +| PROXY_IP | The Proxy container internal IP address from docker pool address | | +| ATTESTATION_SIGNER_ADDRESS | The address of the attestation signer authorized by the validator account | | +| ATTESTATION_SIGNER_POP | The proof-of-possession of the attestation signer key | | +| ATTESTATION_SERVICE_URL | The URL to access the deployed Attestation Service | | +| METADATA_URL | The URL to access the metadata file for your Attestation Service | | First we are going to setup the main environment variables related with the `Baklava` network. Run: @@ -117,230 +140,328 @@ In all the commands we are going to see the `CELO_IMAGE` variable to refer to th docker pull $CELO_IMAGE ``` -### Create accounts +### Create the Validator and Validator Group accounts -At this point we need to create the accounts that will be used by the Validator, the Proxy and the attestation signer. We create and cd into the directory where you want to store the data and any other files needed to run your node. You can name this whatever you’d like, but here’s a default you can use: +First, you'll need to generate account keys for your Validator and Validator Group. These are the keys that will have access to your locked Celo Gold, and thus should be handled with care. For the purposes of this guide, we will be storing these keys on your local machine, but we recommend that you store then in a more secure manner. ```bash -mkdir -p celo-data-dir/proxy celo-data-dir/validator celo-data-dir/attestations -cd celo-data-dir +# On your local machine +mkdir -p celo-data-dir/accounts +cd celo-data-dir/accounts +docker run -v $PWD/accounts:/root/.celo --entrypoint /bin/sh -it $CELO_IMAGE -c "geth account new" +docker run -v $PWD/accounts:/root/.celo --entrypoint /bin/sh -it $CELO_IMAGE -c "geth account new" ``` -It is worth noting that we create all these accounts on the same machine right now, but you are expected to use these accounts on the services on separate machines. We are going to need to create 4 accounts, 2 for the Validator, 1 for the Proxy and the last one for the Attestation Service. You can generate their addresses using the below commands if you don’t already have them. If you already have some accounts, you can skip this step. - -To create the accounts needed, run the following commands. The first two blocks create the accounts for the Validator, the third one for the Proxy, and the last one for the attestation service. Also we save these addresses to environment variables, so that you can reference it later (don't include the braces): +This should generate two accounts in your current directory and print them out, set them in an environment variables: ```bash -docker run -v $PWD/validator:/root/.celo --entrypoint /bin/sh -it $CELO_IMAGE -c "geth account new" +# On your local machine export CELO_VALIDATOR_GROUP_ADDRESS= - -docker run -v $PWD/validator:/root/.celo --entrypoint /bin/sh -it $CELO_IMAGE -c "geth account new" export CELO_VALIDATOR_ADDRESS= +``` -docker run -v $PWD/proxy:/root/.celo --entrypoint /bin/sh -it $CELO_IMAGE -c "geth account new" -export CELO_PROXY_ADDRESS= +Next, we'll run a node on your local machine so that we can use these accounts to lock Celo Gold and authorize the keys needed to run your validator. To do this, we need to run the following commands, which fetch the genesis block and a list of other nodes in the network to connect to. -docker run -v $PWD/attestations:/root/.celo --entrypoint /bin/sh -it $CELO_IMAGE -c "geth account new" -export ATTESTATION_SIGNER_ADDRESS= +```bash +# On your local machine +docker run -v $PWD/accounts:/root/.celo $CELO_IMAGE init /celo/genesis.json +docker run -v $PWD/accounts:/root/.celo --entrypoint cp $CELO_IMAGE /celo/static-nodes.json /root/.celo/ ``` -Those commands will prompt you for a passphrase, ask you to confirm it, and then will output your account address: `Address: {}` +To run the node: -{% hint style="danger" %} -**Warning**: There is a known issue `(Fatal: Failed to read passphrase: liner: function not supported in this terminal” rather than just failing)` running geth inside Docker that happens eventually. So if that command fails, please try again, and if it continues to fail after several attempts, check this page [this page](https://forum.celo.org/t/setting-up-a-validator-faq/90). -{% endhint %} +```bash +# On your local machine +docker run --name celo-accounts -d --restart always -p 8545:8545 -v $PWD/accounts:/root/.celo $CELO_IMAGE --verbosity 3 --networkid $NETWORK_ID --syncmode full --rpc --rpcaddr 0.0.0.0 --rpcapi eth,net,web3,debug,admin,personal +``` + +### Obtain and lock up some Celo Gold for staking -In order to register the Validator later on, generate a "proof of possession" - a signature proving you know your Validator's BLS private key. Run this command to generate this "proof-of-possession", which consists of a the BLS public key and a signature: +To participate in The Great Celo Stake Off (aka TGCSO) and get fauceted it's necessary to register online via an [online form](https://docs.google.com/forms/d/e/1FAIpQLSfbn5hTJ4UIWpN92-o2qMTUB0UnrFsL0fm97XqGe4VhhN_r5A/viewform). While you wait, let's deploy the remaining components: + +### Deploy a Validator + +To actually register as a validator, we'll need to generate a validating signer key. On your Validator machine (which should not be accessible from the public internet), follow very similar steps: ```bash -docker run -v $PWD/validator:/root/.celo --entrypoint /bin/sh -it $CELO_IMAGE -c "geth account proof-of-possession $CELO_VALIDATOR_ADDRESS $CELO_VALIDATOR_ADDRESS" +# On the validator machine +mkdir -p celo-data-dir/validator +cd celo-data-dir/validator +docker run -v $PWD/validator:/root/.celo $CELO_IMAGE init /celo/genesis.json +docker run -v $PWD/validator:/root/.celo --entrypoint /bin/sh -it $CELO_IMAGE -c "geth account new" +export CELO_VALIDATOR_SIGNER_ADDRESS= ``` -It will prompt you for the passphrase you've chosen for the Validator account. Let's save the resulting proof-of-possession to two environment variables: +In order to authorize our Validator signer, we need to create a proof that we have possession of the corresponding private key. We do so by signing a message that consists of the Validator account address. To generate the proof-of-possession, run the following command: ```bash -export CELO_VALIDATOR_BLS_PUBLIC_KEY= -export CELO_VALIDATOR_BLS_SIGNATURE= +# On the validator machine +# Note that you have to export CELO_VALIDATOR_ADDRESS on this machine +export $CELO_VALIDATOR_ADDRESS= +docker run -v $PWD/validator:/root/.celo --entrypoint /bin/sh -it $CELO_IMAGE -c "geth account proof-of-possession $CELO_VALIDATOR_SIGNER_ADDRESS $CELO_VALIDATOR_ADDRESS" ``` -### Deploy the Validator and Proxy nodes +Validators on the Celo network use BLS aggregated signatures to create blocks in addition to the Validator signer (ECDSA) key. While an independent BLS key can be specified, the simplest thing to do is to derive the BLS key from the Validator signer key. When we register our Validator, we'll need to prove possession of the BLS key as well, which can be done by running the following command: -We initialize the Docker containers for the Validator and the Proxy, building from an image for the network and initializing Celo with the genesis block found inside the Docker image: +```bash +# On the validator machine +docker run -v $PWD/validator:/root/.celo --entrypoint /bin/sh -it $CELO_IMAGE -c "geth account proof-of-possession $CELO_VALIDATOR_SIGNER_ADDRESS $CELO_VALIDATOR_ADDRESS --bls" +``` + +It will prompt you for the passphrase you've chosen for the Validator signer key. Let's save the resulting proof-of-possession to three environment variables: ```bash -docker run -v $PWD/proxy:/root/.celo $CELO_IMAGE init /celo/genesis.json -docker run -v $PWD/validator:/root/.celo $CELO_IMAGE init /celo/genesis.json +# On your local machine +export CELO_VALIDATOR_SIGNER_POP= +export CELO_VALIDATOR_BLS_PUBLIC_KEY= +export CELO_VALIDATOR_BLS_SIGNATURE= ``` -{% hint style="danger" %} -**Warning**: There is a known issue `(Fatal: Failed to read passphrase: liner: function not supported in this terminal” rather than just failing)` running geth inside Docker that happens eventually. So if that command fails, please try again, and if it continues to fail after several attempts, check this page [this page](https://forum.celo.org/t/setting-up-a-validator-faq/90). -{% endhint %} +We'll get back to this machine later, but for now, let's give it a proxy. + +### Deploy a proxy -In order to allow the node to sync with the network, give it the address of existing nodes in the network to the Proxy. The Validator will sync through the Proxy: +To avoid exposing the validator to the public internet, we are deploying a proxy node which is responsible to communicate with the network. On our Proxy machine, we'll setup the node as per usual now: ```bash +# On the proxy machine +mkdir -p celo-data-dir/proxy +cd celo-data-dir/proxy +docker run -v $PWD/proxy:/root/.celo $CELO_IMAGE init /celo/genesis.json docker run -v $PWD/proxy:/root/.celo --entrypoint cp $CELO_IMAGE /celo/static-nodes.json /root/.celo/ ``` -#### Running the Proxy - -At this point we are ready to start up the Proxy: +You can then run the proxy with ```bash -docker run --name celo-proxy -d --restart always -p 8555:8545 -p 8556:8546 -p 30313:30303 -p 30313:30303/udp -p 30503:30503 -p 30503:30503/udp -v $PWD/proxy:/root/.celo $CELO_IMAGE --verbosity 3 --networkid $NETWORK_ID --syncmode full --rpc --rpcaddr 0.0.0.0 --rpcapi eth,net,web3,debug,admin,personal,istanbul --etherbase=$CELO_PROXY_ADDRESS --proxy.proxy --proxy.proxiedvalidatoraddress $CELO_VALIDATOR_ADDRESS --proxy.internalendpoint :30503 +# On the proxy machine +# Note that you'll have to export CELO_VALIDATOR_SIGNER_ADDRESS on this machine +docker run --name celo-proxy -d --restart always -p 30313:30303 -p 30313:30303/udp -p 30503:30503 -p 30503:30503/udp -v $PWD/proxy:/root/.celo $CELO_IMAGE --verbosity 3 --networkid $NETWORK_ID --syncmode full --proxy.proxy --proxy.proxiedvalidatoraddress $CELO_VALIDATOR_SIGNER_ADDRESS --proxy.internalendpoint :30503 ``` -#### Running the Validator - -Now that we have the Proxy up and running, we need to obtain its enode and IP address, so that we can connect the Validator to the proxy. You can do that running the following commands: +Once the proxy is running, we will need to retrieve it's enode so that the validator will be able to connect to it. ```bash -export PROXY_ENODE=$(docker exec celo-proxy geth --exec "admin.nodeInfo['enode'].split('//')[1].split('@')[0]" attach | tr -d '"') -export PROXY_IP=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' celo-proxy) +# On the proxy machine, retrieve the proxy enode +echo $(docker exec celo-proxy geth --exec "admin.nodeInfo['enode'].split('//')[1].split('@')[0]" attach | tr -d '"') ``` -Now we can start up the Validator node. In the below command remember to replace the **VALIDATOR_ADDRESS_PASSWORD** for the password you used when you created the `CELO_VALIDATOR_ADDRESS`: +Now we need to set the proxy enode and proxy IP address in environment variables on the validator machine. ```bash -docker run -v $PWD/validator:/root/.celo --entrypoint sh --rm $CELO_IMAGE -c "echo VALIDATOR_ADDRESS_PASSWORD > /root/.celo/.password" -docker run --name celo-validator -d --restart always -p 127.0.0.1:8545:8545 -p 127.0.0.1:8546:8546 -p 30303:30303 -p 30303:30303/udp -v $PWD/validator:/root/.celo $CELO_IMAGE --verbosity 3 --networkid $NETWORK_ID --syncmode full --rpc --rpcaddr 0.0.0.0 --rpcapi eth,net,web3,debug,admin,personal,istanbul --mine --istanbul.blockperiod=5 --istanbul.requesttimeout=3000 --etherbase $CELO_VALIDATOR_ADDRESS --nodiscover --proxy.proxied --proxy.proxyenodeurlpair=enode://$PROXY_ENODE@$PROXY_IP:30503\;enode://$PROXY_ENODE@$PROXY_IP:30303 --unlock=$CELO_VALIDATOR_ADDRESS --password /root/.celo/.password +# On the validator machine +export PROXY_ENODE= +export PROXY_IP= ``` -**Security**: The command line above includes the parameter `--rpcaddr 0.0.0.0` which makes the Celo Blockchain software listen for incoming RPC requests on all the interfaces of the Docker container. Exercise extreme caution in doing this when running outside Docker, as it means that any unlocked accounts and their funds may be accessed from other machines on the Internet. In the context of running a Docker container on your local machine, this together with the `docker -p` flags allows you to make RPC calls from outside the container, i.e from your local host, but not from outside your machine. Read more about [Docker Networking](https://docs.docker.com/network/network-tutorial-standalone/#use-user-defined-bridge-networks) here. +Let's connect the validator to the proxy: + +### Connect the Validator to the Proxy + +When starting up your validator, it will attempt to create a network connection between the validator machine and the proxy machine. You will need make sure that your proxy machine has the appropriate firewall settings to allow the validator to connect to it. + +Specifically, on the proxy machine, port 30303 should allow TCP and UDP connections from all IP addresses. And port 30503 should allow TCP connections from the IP address of your validator machine. + +Once that it completed, go ahead and run the validator. + +```bash +# On the validator machine +docker run -v $PWD/validator:/root/.celo --entrypoint sh --rm $CELO_IMAGE -c "echo VALIDATOR_SIGNER_PASSWORD > /root/.celo/.password" +docker run --name celo-validator -d --restart always -p 30303:30303 -p 30303:30303/udp -v $PWD/validator:/root/.celo $CELO_IMAGE --verbosity 3 --networkid $NETWORK_ID --syncmode full --mine --istanbul.blockperiod=5 --istanbul.requesttimeout=3000 --etherbase $CELO_VALIDATOR_ADDRESS --nodiscover --proxy.proxied --proxy.proxyenodeurlpair=enode://$PROXY_ENODE@$PROXY_IP:30503\;enode://$PROXY_ENODE@$PROXY_IP:30303 --unlock=$CELO_VALIDATOR_SIGNER_ADDRESS --password /root/.celo/.password +``` The `mine` flag does not mean the node starts mining blocks, but rather starts trying to participate in the BFT consensus protocol. It cannot do this until it gets elected -- so next we need to stand for election. The `networkid` parameter value of `1101` indicates we are connecting the Baklava Beta network. -### Running the Attestation signer +### Register the Accounts -As part of the [lightweight identity protocol](/celo-codebase/protocol/identity), Validators are expected to run an [Attestation Service](https://github.com/celo-org/celo-monorepo/tree/master/packages/attestation-service) to provide attestations that allow users to map their phone number to an account on Celo. +By now 12,000 Celo Gold should have been sent to your Validator and Validator Group account addresses. This will allow you to submit transactions to the network via the `celocli`. To do so, you'll need to have a running node with access to the account keys. Start one by running the following commands on your local machine: -You can find the complete instructions about how to run the [Attestation Service at the documentation page](running-attestation-service.md). +```bash +# On your local machine +docker run -v $PWD/accounts:/root/.celo $CELO_IMAGE init /celo/genesis.json +docker run -v $PWD/accounts:/root/.celo --entrypoint cp $CELO_IMAGE /celo/static-nodes.json /root/.celo/ +docker run --name celo-accounts -d --restart always -p 8545:8545 -v $PWD/accounts:/root/.celo $CELO_IMAGE --verbosity 3 --networkid $NETWORK_ID --syncmode full --rpc --rpcaddr 0.0.0.0 --rpcapi eth,net,web3,debug,admin,personal +``` -### Stop the containers +Once the node is synced, we can register our accounts: -You can stop the Docker containers at any time without problem. If you stop your containers that means those containers stop of providing service. -The data dir of the validator and the proxy are Docker volumes mounted in the containers from the `celo-data-dir` you created at the very beginning. So if you don't remove that folder, you can stop or restart the containers without losing any data. +```bash +# On your local machine +celocli accounts:register --from $CELO_VALIDATOR_GROUP_ADDRESS --name +celocli accounts:register --from $CELO_VALIDATOR_ADDRESS --name +``` -You can stop the `celo-validator` and `celo-proxy` containers running: +### Lock up Celo Gold + +Lock up Celo Gold for both accounts in order to secure the right to register a Validator and Validator Group. The current requirement is 10k Celo Gold to register a validator, and 10k Celo Gold _per member validator_ to register a Validator Group. For Validators, this gold remains locked for approximately 60 days following deregistration. For groups, this gold remains locked for approximately 60 days following the removal of the Nth validator from the group. ```bash -docker stop celo-validator celo-proxy +# On your local machine +celocli lockedgold:lock --from $CELO_VALIDATOR_GROUP_ADDRESS --value 10000000000000000000000 +celocli lockedgold:lock --from $CELO_VALIDATOR_ADDRESS --value 10000000000000000000000 ``` -And you can remove the containers (not the data dir) running: +### Run for election + +In order to be elected as a Validator, you will first need to register your group and Validator. Note that when registering a Validator Group, you need to specify a commission, which is the fraction of epoch rewards paid to the group by its members. + +We don't want to use our account key for validating, so first let's authorize the validator signing key: ```bash -docker rm -f celo-validator celo-proxy +# On your local machine +celocli account:authorize --from $CELO_VALIDATOR_ADDRESS --role validator --pop $CELO_VALIDATOR_SIGNER_POP --signer $CELO_VALIDATOR_SIGNER_ADDRESS ``` -### Running the Docker containers in the background +Register your Validator Group by running the following command. Note that because we did not authorize a Validator signer for our Validator Group account, we register the Validator Group with the account key. -There are different option for executing Docker containers in the background. The most typical one is to use in your docker run commands the `-d` option. Also for long running processes, specially when you run in a remote computer, you can use a tool like [screen](https://ss64.com/osx/screen.html). It allows to connect and disconnect from running processes providing an easy way to manage long run processes. +```bash +# On your local machine +celocli validatorgroup:register --from $CELO_VALIDATOR_GROUP_ADDRESS --commission 0.1 +``` -It's out of the scope of this documentation to go through the `screen` options, but you can use the following command format with your `docker` commands: +Next, register your Validator by running the following command. Note that because we have authorized a Validator signer, this step could also be performed on the Validator machine. Running it on the local machine allows us to avoid needing to install the celocli on the Validator machine. ```bash -screen -S -d -m +# On your local machine +celocli validator:register --from $CELO_VALIDATOR_ADDRESS --blsKey $CELO_VALIDATOR_BLS_PUBLIC_KEY --blsPop $CELO_VALIDATOR_BLS_SIGNATURE ``` -For example: +Affiliate your Validator with your Validator Group. Note that you will not be a member of this group until the Validator Group accepts you. This command could also be run from the Validator signer, if running on the validator machine. ```bash -screen -S celo-validator -d -m docker run --name celo-validator --restart always -p 127.0.0.1:8545:8545 ....... +# On your local machine +celocli validator:affiliate $CELO_VALIDATOR_GROUP_ADDRESS --from $CELO_VALIDATOR_ADDRESS ``` -You can list your existing `screen` sessions: +Accept the affiliation: ```bash -screen -ls +# On your local machine +celocli validatorgroup:member --accept $CELO_VALIDATOR_ADDRESS --from $CELO_VALIDATOR_GROUP_ADDRESS ``` -And re-atach to any of the existing sessions: +Use both accounts to vote for your Validator Group. Note that because we have not authorized a vote signer for either account, these transactions must be sent from the account keys. Since you're likely to need to place additional votes throughout the course of the stake-off, consider creating and authorizing vote signers for additional operational security. ```bash -screen -r -S celo-validator +# On your local machine +celocli election:vote --from $CELO_VALIDATOR_ADDRESS --for $CELO_VALIDATOR_GROUP_ADDRESS --value 10000000000000000000000 +celocli election:vote --from $CELO_VALIDATOR_GROUP_ADDRESS --for $CELO_VALIDATOR_GROUP_ADDRESS --value 10000000000000000000000 ``` -### Reference Script - -You can use (and modify if you want) this [reference bash script](../../../scripts/run-docker-validator-network.sh) automating all the above steps. It requires Docker and screen. +You’re all set! Note that elections are finalized at the end of each epoch, roughly once an hour in the Alfajores or Baklava Testnets. After that hour, if you get elected, your node will start participating BFT consensus and validating blocks. -You can see all the options using the following command: +You can inspect the current state of the validator elections by running: ```bash -./run-docker-validator-network.sh help +# On your local machine +celocli election:list ``` -## Get elected as validator +If you find your Validator still not getting elected you may need to faucet yourself more funds and lock more gold in order to be able to cast more votes for your Validator Group! -### Obtain and lock up some Celo Gold for staking +At any moment you can check the currently elected validators by running the following command: + +```bash +# On your local machine +celocli election:current +``` -To participate in The Great Celo Stake Off (aka TGCSO) and get fauceted it's necessary to register online via an [online form](https://docs.google.com/forms/d/e/1FAIpQLSfbn5hTJ4UIWpN92-o2qMTUB0UnrFsL0fm97XqGe4VhhN_r5A/viewform). +### Running the Attestation Service -### Submitting transactions +As part of the [lightweight identity protocol](/celo-codebase/protocol/identity), Validators are expected to run an [Attestation Service](https://github.com/celo-org/celo-monorepo/tree/master/packages/attestation-service) to provide attestations that allow users to map their phone number to an account on Celo. -We created the `celocli` to allow users to easily interact with the smart contracts on the command line. The `celocli` generally expects a celo node, by default we are using the RPC API interface at `http://localhost:8545`. To submit transactions, the node should have the account unlocked (the one that is usually specified with `--from`). You can specify that through the `--unlock` parameter when starting your celo node. Otherwise you can use `celocli` to unlock the account with `celocli account:unlock` (assuming you have the `personal` module enabled). +Just like with the Validator signer, we'll want to authorize a separate Attestation signer. For that let's start our node on the Attestations machine: -### Lock up Celo Gold +```bash +# On the Attestation machine +# You have to export CELO_VALIDATOR_ADDRESS on this machine +export $CELO_VALIDATOR_ADDRESS= +mkdir -p celo-data-dir/attestations +cd celo-data-dir/attestations +docker run -v $PWD/attestations:/root/.celo $CELO_IMAGE init /celo/genesis.json +docker run -v $PWD/attestations:/root/.celo --entrypoint cp $CELO_IMAGE /celo/static-nodes.json /root/.celo/ +docker run -v $PWD/attestations:/root/.celo --entrypoint /bin/sh -it $CELO_IMAGE -c "geth account new" +export ATTESTATION_SIGNER_ADDRESS= +``` -Lock up Celo Gold for both accounts in order to secure the right to register a Validator and Validator Group. The current requirement is 10k Celo Gold to register a validator, and 10k Celo Gold _per member validator_ to register a Validator Group. For Validators, this gold remains locked for approximately 60 days following deregistration. For groups, this gold remains locked for approximately 60 days following the removal of the Nth validator from the group. +Let's run the node in the background (both to generate the proof-of-possession now and to run the attestation service later.) ```bash -celocli lockedgold:lock --from $CELO_VALIDATOR_GROUP_ADDRESS --value 10000000000000000000000 -celocli lockedgold:lock --from $CELO_VALIDATOR_ADDRESS --value 10000000000000000000000 +# On the Attestation machine +docker run --name celo-attestations -d --restart always -p 8545:8545 -v $PWD/accounts:/root/.celo $CELO_IMAGE --verbosity 3 --networkid $NETWORK_ID --syncmode full --rpc --rpcaddr 0.0.0.0 --rpcapi eth,net,web3,debug,admin,personal --unlock $ATTESTATION_SIGNER_ADDRESS ``` -### Run for election +Generate the proof-of-possession for the attestation signer -In order to be elected as a Validator, you will first need to register your group and Validator. Note that when registering a Validator Group, you need to specify a commission, which is the fraction of epoch rewards paid to the group by its members. +```bash +# On the Attestation machine +celocli account:proof-of-possession --signer $ATTESTATION_SIGNER_ADDRESS --account $CELO_VALIDATOR_ADDRESS +``` -Register your Validator Group: +With this proof, authorize the attestation signer on your local machine: ```bash -celocli validatorgroup:register --from $CELO_VALIDATOR_GROUP_ADDRESS --commission 0.1 +# On your local machine +celocli account:authorize --from $CELO_VALIDATOR_ADDRESS --role attestation --pop --signer $ATTESTATION_SIGNER_ADDRESS ``` -Register your Validator: +By now, you should have setup your Validator account appropriately. You can finish the actual deploy of the attestation service under the [Attestation Service at the documentation page](running-attestation-service.md). + +### Stop the containers + +You can stop the Docker containers at any time without problem. If you stop your containers that means those containers stop of providing service. +The data dir of the validator and the proxy are Docker volumes mounted in the containers from the `celo-data-dir` you created at the very beginning. So if you don't remove that folder, you can stop or restart the containers without losing any data. + +You can stop the `celo-validator` and `celo-proxy` containers running: ```bash -celocli validator:register --from $CELO_VALIDATOR_ADDRESS --blsKey $CELO_VALIDATOR_BLS_PUBLIC_KEY --blsPop $CELO_VALIDATOR_BLS_SIGNATURE +docker stop celo-validator celo-proxy ``` -Affiliate your Validator with your Validator Group. Note that you will not be a member of this group until the Validator Group accepts you: +And you can remove the containers (not the data dir) running: ```bash -celocli validator:affiliate $CELO_VALIDATOR_GROUP_ADDRESS --from $CELO_VALIDATOR_ADDRESS +docker rm -f celo-validator celo-proxy ``` -Accept the affiliation: +### Running the Docker containers in the background + +There are different option for executing Docker containers in the background. The most typical one is to use in your docker run commands the `-d` option. Also for long running processes, specially when you run in a remote computer, you can use a tool like [screen](https://ss64.com/osx/screen.html). It allows to connect and disconnect from running processes providing an easy way to manage long run processes. + +It's out of the scope of this documentation to go through the `screen` options, but you can use the following command format with your `docker` commands: ```bash -celocli validatorgroup:member --accept $CELO_VALIDATOR_ADDRESS --from $CELO_VALIDATOR_GROUP_ADDRESS +screen -S -d -m ``` -Use both accounts to vote for your Validator Group: +For example: ```bash -celocli election:vote --from $CELO_VALIDATOR_ADDRESS --for $CELO_VALIDATOR_GROUP_ADDRESS --value 10000000000000000000000 -celocli election:vote --from $CELO_VALIDATOR_GROUP_ADDRESS --for $CELO_VALIDATOR_GROUP_ADDRESS --value 10000000000000000000000 +screen -S celo-validator -d -m docker run --name celo-validator --restart always -p 127.0.0.1:8545:8545 ....... ``` -You’re all set! Note that elections are finalized at the end of each epoch, roughly once an hour in the Alfajores or Baklava Testnets. After that hour, if you get elected, your node will start participating BFT consensus and validating blocks. +You can list your existing `screen` sessions: + +```bash +screen -ls +``` -You can inspect the current state of voting by running: +And re-atach to any of the existing sessions: ```bash -celocli election:list +screen -r -S celo-validator ``` -If you find your Validator still not getting elected you may need to faucet yourself more funds and lock more gold in order to be able to cast more votes for your Validator Group! +### Reference Script -At any moment you can check the currently elected validators by running the following command: +You can use (and modify if you want) this [reference bash script](../../../scripts/run-docker-validator-network.sh) automating all the above steps. It requires Docker and screen. + +You can see all the options using the following command: ```bash -celocli election:current +./run-docker-validator-network.sh help ``` ### Stop Validating diff --git a/packages/docs/getting-started/running-attestation-service.md b/packages/docs/getting-started/running-attestation-service.md index 5894b8406bd..b7aba2dcd74 100644 --- a/packages/docs/getting-started/running-attestation-service.md +++ b/packages/docs/getting-started/running-attestation-service.md @@ -15,14 +15,14 @@ As part of the [lightweight identity protocol](/celo-codebase/protocol/identity) The service needs the following environment variables: -| Variable | Explanation | -| -------------------------- | ------------------------------------------------------------------------------------------------------------------ | -| DATABASE_URL | The URL under which your database is accessible, currently supported are `postgres://`, `mysql://` and `sqlite://` | | -| CELO_PROVIDER | The URL under which a celo blockchain node is reachable and the attestation signer is unlocked | | -| ACCOUNT_ADDRESS | The address of the validator account | | -| ATTESTATION_SIGNER_ADDRESS | The address of the attestation signer that was authorized by the validator account | | -| APP_SIGNATURE | The hash with which clients can auto-read SMS messages on android | | -| SMS_PROVIDERS | A comma-separated list of providers you want to configure, we currently support `nexmo` & `twilio` | | +| Variable | Explanation | +| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| DATABASE_URL | The URL under which your database is accessible, currently supported are `postgres://`, `mysql://` and `sqlite://` | | +| CELO_PROVIDER | The endpoint under which your node with the unlocked attestation signer key is available, should be `http://localhost:8545` if you followed the [instructions](./running-a-validator) | | +| CELO_VALIDATOR_ADDRESS | The address of the Validator account | | +| ATTESTATION_SIGNER_ADDRESS | The address of the attestation signer that was authorized by the Validator account | | +| APP_SIGNATURE | The hash with which clients can auto-read SMS messages on android | | +| SMS_PROVIDERS | A comma-separated list of providers you want to configure, we currently support `nexmo` & `twilio` | | A part of that we are going to setup the following environment variable about the Attestation Service Docker image: @@ -34,19 +34,9 @@ export CELO_IMAGE_ATTESTATION="us.gcr.io/celo-testnet/celo-monorepo:attestation- Currently the Sms providers supported are Nexmo & Twilio. You can create your user account in the provider of your election using the [Nexmo Sign Up form](https://dashboard.nexmo.com/sign-up) or the [Twilio Sign Up form](https://www.twilio.com/try-twilio). -### Nexmo - -Here is the list of the enviromnet variables needed to use the Nexmo SMS broker: - -| Variable | Explanation | -| --------------- | --------------------------------------------------------------- | -| NEXMO_KEY | The API key to the Nexmo API | -| NEXMO_SECRET | The API secret to the Nexmo API | -| NEXMO_BLACKLIST | A comma-sperated list of country codes you do not want to serve | - ### Twilio -If you prefer using Twilio, this is list of the variables to use: +Twilio is the most common and popular provider. For that you will need to provision the following variables: | Variable | Explanation | | ---------------------------- | --------------------------------------------------------------- | @@ -55,25 +45,24 @@ If you prefer using Twilio, this is list of the variables to use: | TWILIO_AUTH_TOKEN | The API authentication token | | TWILIO_BLACKLIST | A comma-sperated list of country codes you do not want to serve | -## Accounts Configuration +**Setup** +After you signed up for Twilio at [https://www.twilio.com/try-twilio](https://www.twilio.com/try-twilio), you should see your `ACCOUNT SID` and your `AUTH_TOKEN` in the top right of the console. You'll also want to enter in a credit card to fund the account. For most text messages, the costs will be very low. Find a more comprehensive price list at [https://www.twilio.com/sms/pricing](https://www.twilio.com/sms/pricing). If there are countries that you do not want to serve, you can specify them with the `TWILIO_BLACKLIST`. -First, the validator account needs to authorize the attestation signer. With `celocli` connected to a node that has the attestation signer unlocked, let's create a proof-of-posession: - -```bash -celocli account:proof-of-possession --signer $ATTESTATION_SIGNER_ADDRESS --account $CELO_VALIDATOR_ADDRESS -``` +To actually be able to send SMS, you need to create a messaging service under [Programmable SMS > SMS](https://www.twilio.com/console/sms/services). The resulting `SID` you want to specify under the `TWILIO_MESSAGING_SERVICE_SID`. Now that you have provisioned your messaging service, you need to buy at least 1 phone number to send SMS from. You can do so under the `Numbers` option of the messaging service page. To maximize the chances of reliable and prompt SMS sending (and thus attestation fee revenue), you can buy numbers in many locales, and Twilio will intelligently select the best number to send each SMS. -That will give you a signature that you can then use to authorize the key (with `celocli` connected to the node that has the validator account unlocked): +### Nexmo -```bash -celocli account:authorize --from $CELO_VALIDATOR_ADDRESS -r attestation --pop --signer $ATTESTATION_SIGNER_ADDRESS -``` +Here is the list of the enviromnet variables needed to use the Nexmo SMS broker: -The Attestation Service needs to connect to the node that has the attestation signer unlocked, configured via `CELO_PROVIDER`. +| Variable | Explanation | +| --------------- | --------------------------------------------------------------- | +| NEXMO_KEY | The API key to the Nexmo API | +| NEXMO_SECRET | The API secret to the Nexmo API | +| NEXMO_BLACKLIST | A comma-sperated list of country codes you do not want to serve | #### Database Configuration -For storing and retrieving the attestation requests the service needs a database to persist that information. Currently `sqlite`, `postgres` and `mysql` are supported. For testing purposes you can use `sqlite` but it's recommended to run a stand-alone database server using `mysql` or `postgres` if your intention is running the Attestation Service in a production environment. +For storing and retrieving the attestation requests the service needs a database to persist that information. Currently `sqlite`, `postgres` and `mysql` are supported. For testing purposes you can use `sqlite` but it's recommended to run a stand-alone database server using `mysql` or `postgres` if your intention is running the Attestation Service in a production environment. If you are running on a popular cloud provider, consider using their hosted SQL services. Depending on your database technology you need to create a database with the access for a specific user and password. @@ -85,23 +74,17 @@ export DATABASE_URL="mysql://user:password@mysql.example.com:3306/attestation-se export DATABASE_URL="postgres://user:password@postgres.example.com:5432/attestation-service" ``` -You can find the migration scripts for creating the schema at the `celo-monorepo`, `packages/attestation-service` folder. From there, after setting up the `DATABASE_URL` env variable you can run the following command: - -```bash -yarn run db:migrate -``` - ## Executing the Attestation Service The following command for running the Attestation Service is using Nexmo, but you can adapt for using Twilio easily: ```bash -docker run -v $PWD/attestation-service:/celo-monorepo/packages/attestation-service/db --name -d --restart always --entrypoint /bin/bash -e ATTESTATION_SIGNER_ADDRESS=$ATTESTATION_SIGNER_ADDRESS -e ACCOUNT_ADDRESS=0x$CELO_VALIDATOR_ADDRESS -e CELO_PROVIDER=$CELO_PROVIDER -e DATABASE_URL=$DATABASE_URL -e SMS_PROVIDERS=nexmo -e NEXMO_KEY=$NEXMO_KEY -e NEXMO_SECRET=$NEXMO_SECRET -e NEXMO_BLACKLIST=$NEXMO_BLACKLIST -d -p 3000:80 $CELO_IMAGE_ATTESTATION -c " cd /celo-monorepo/packages/attestation-service && touch db/attestation.db && yarn run db:migrate && yarn start " +docker run --name celo-attestation-service -d --restart always --entrypoint /bin/bash -e ATTESTATION_SIGNER_ADDRESS=$ATTESTATION_SIGNER_ADDRESS -e CELO_VALIDATOR_ADDRESS=0x$CELO_VALIDATOR_ADDRESS -e CELO_PROVIDER=$CELO_PROVIDER -e DATABASE_URL=$DATABASE_URL -e SMS_PROVIDERS=nexmo -e NEXMO_KEY=$NEXMO_KEY -e NEXMO_SECRET=$NEXMO_SECRET -e NEXMO_BLACKLIST=$NEXMO_BLACKLIST -p 3000:80 $CELO_IMAGE_ATTESTATION -c " cd /celo-monorepo/packages/attestation-service && yarn run db:migrate && yarn start " ``` ## Registering the Attestation Service -In order for users to request attestations from your service, you need to register the endpoint under which your service is reachable in your [metadata](/celo-codebase/protocol/identity/metadata). The following accounts require `celocli` to be connected to a node that has the validator account unlocked. +In order for users to request attestations from your service, you need to register the endpoint under which your service is reachable in your [metadata](/celo-codebase/protocol/identity/metadata). Run the following commands on your local machine where `$CELO_VALIDATOR_ADDRESS` is unlocked. ```bash celocli account:create-metadata ./metadata.json --from $CELO_VALIDATOR_ADDRESS @@ -110,10 +93,10 @@ celocli account:create-metadata ./metadata.json --from $CELO_VALIDATOR_ADDRESS The `ATTESTATION_SERVICE_URL` variable stores the URL to access the Attestation Service deployed. In the following command we specify the URL where this Attestation Service is: ```bash -celocli account:claim-attestation-service-url ./metadata.json --url $ATTESTATION_SERVICE_URL +celocli account:claim-attestation-service-url ./metadata.json --url $ATTESTATION_SERVICE_URL --from $CELO_VALIDATOR_ADDRESS ``` -And then host your metadata somewhere reachable via HTTP. You can use a service like [gist.github.com](https://gist.github.com) (remember to register the raw link) +And then host your metadata somewhere reachable via HTTP. You can use a service like [gist.github.com](https://gist.github.com). Create a gist with the contents of the file and then click on the `Raw` buttton to receive the permalink to the machine-readable file. ```bash celocli account:register-metadata --url --from $CELO_VALIDATOR_ADDRESS diff --git a/packages/helm-charts/attestation-service/templates/attestation.statefulset.yaml b/packages/helm-charts/attestation-service/templates/attestation.statefulset.yaml index 6b987ee74d9..48612116636 100644 --- a/packages/helm-charts/attestation-service/templates/attestation.statefulset.yaml +++ b/packages/helm-charts/attestation-service/templates/attestation.statefulset.yaml @@ -131,7 +131,7 @@ spec: - | yarn db:migrate sleep 5 - ATTESTATION_SIGNER_ADDRESS=`cat /root/.celo/attestationSignerAddress` ACCOUNT_ADDRESS=`cat /root/.celo/address` yarn start + ATTESTATION_SIGNER_ADDRESS=`cat /root/.celo/attestationSignerAddress` CELO_VALIDATOR_ADDRESS=`cat /root/.celo/address` yarn start ports: - name: http containerPort: 3000