secret
Table of Contents
03 – Being a Credible Validator
Gateway Overview
Gateway is a Substrate blockchain, that runs as a multi-validator Proof of Authority network (PoA). Validators are authorized by COMP Governance on Ethereum, through the existing governance framework.
On the Gateway testnet, validators will be added on a routine basis, and can include any interested organization / node operator. In production, validators (or the process for choosing validators) will ultimately be chosen by Compound governance, that is, COMP token-holders on Ethereum.
Following mainnet launch, Gateway can (and hopefully will) transition to proof-of-stake (PoS).
For more information about Gateway, please see the whitepaper at compound.cash.
Validator Economics
Incentives
The reward for being a validator is CASH. That is, a portion of total interest paid on assets borrowed from Gateway is paid directly to validators, on every block. If you are familiar with Compound v2, it’s analogous to reserves being paid directly to validators as opposed to remaining in the protocol.
In other words, assets can be locked on Gateway to be used as collateral to borrow CASH or other assets from Gateway. When assets (other than CASH) are borrowed from Gateway, interest is accumulated, paid, and earned in CASH. A fraction of that interest goes directly to the author of each block.
Validators also receive the fees for transferring assets, in blocks which they author.
Risks
In the long-term, Gateway is likely to move to a COMP Proof of Stake model, where malicious behavior as a validator could lead to slashing of staked COMP. However the intention is to design a system around incentives, using punishment only as a last resort.
The main risk to Gateway itself, is that the set of validators would collude together to betray the chain. In order to prevent this, we incentivize validators to have more to gain by following the rules of the chain (minus what they would lose by trying to cheat it), than they would gain by successfully destroying the chain.
For the initial Proof of Authority network, validators will be chosen who have significant reputational risk at stake. Assets allowed onto the chain will be capped to a value deemed to be covered by the business value of the validators, such that the cost to credibility that would be incurred is likely to dominate any expected gain from a successful heist.
Becoming a Validator
Overview
Validators are set by Compound governance via a proposal on the pre-existing Ethereum governance contracts. Compound governance votes (on Ethereum) to ChangeAuthorities (on Gateway), which if passed, is enacted by the substrate chain runtime, and then propagated back to the Starports.
While an Upload transaction requires one L1 transaction to process, Downloading requires both a Signature on Gateway, as well as an L1 transaction after your signature has been mined and validated. You can learn more about Validation by going here.
Publishing Keys
The ChangeAuthorities message specifies who the validators of Gateway are to become upon the next Session. The current keys required are {controller key, identity key} where the controller key is a Gateway address and the identity key is an Ethereum address.
The set of keys required by governance are called the validator keys, as opposed to the session keys which may be rotated at will by the controller.
Controller Key
The controller key should be a hardware (wallet) key, which can be used to sign extrinsics to set session keys for the validator’s node. The key provided to governance is the public address associated with this protected keypair which the validator controls.
Identity Key
The identity key should be a hardware (HSM*) key, which can be used to sign messages coming from the node’s off-chain workers. The key provided to governance is the public address associated with this protected keypair which the validator’s node has access to for signing messages to Gateway itself.
Starport Keys
We also require the node have access to a hardware (HSM*) key supported by each starport, however by using the starport key as the identity key, we simplify the initial requirements.
Starport keys will only be added if a starport cannot be supported by one of the existing starport keys. Validators will need to create and publish their public key for any new key type being added, though introduction of new key types should be kept to a minimum.
Since the identity key is the Ethereum starport key, the identity key is further specified as an Ethereum address associated with a protected (ecdsa) keypair which the validator’s node has access to for signing notices. No additional keys are needed for governance.
*As we launch testnet, we’ll be working on supporting more adapters for HSM keys based on the requirements surfaced by the initial validator set. As such, environment variables and in-memory keys may be used temporarily during the initial testnet phases.
Once the public keys needed are assembled by the validator, a proposal must be submitted to Compound governance, including a full list of validator keys in the set of authorities. See here for more information about Compound governance and proposals.
Session Keys
Once a controller key is accepted by governance, the expectation is that the owner of that key will operate a node and call SetKeys on it with a set of public session keys for the validator. The validator may assign new session keys at any time (to be picked up during the next session), but must set keys at least once or it may be deemed unavailable, and the operator removed from the validator set.
The current session will not be allowed to end until at least ⅔ of the validators specified as the new authorities have bound session keys to their controller key using SetKeys.
The session keys needed at the moment are an AURA key and a GRANDPA key, which are used for consensus on the substrate chain. They can be generated and used according to the general Substrate patterns.
Key Rotation
Controller, identity, and starport key rotation will be handled the same way as adding/removing any other set of validator keys, through a governance proposal containing the updated set of authorities.
Session keys may be rotated at will be validators, according to the above guidelines.
If for some reason a validator ever believes their key to be compromised, they should immediately notify the community via comp.xyz and any other means possible.
Multiple Keys/Nodes
Each validator node uses its own set of keys, thus if a validator wishes to run more than one node, they will need each set of validator keys included in a ChangeAuthorities proposal.
Reporting Starport Events
Each validator observes Starport events on the connected chains, and signs messages witnessing those events, which are stored on-chain. The events for which we have received signatures Starport chain thus far (up until some number of finalization blocks for chains with probabilistic finality*).
The worker which watches for events and signs them is also responsible for ensuring the signed messages are processed by the chain in order and none are skipped. Reporting inaccurate events, or events out of order, is considered to be malicious behavior, since it could only occur via intervention with the node software.
A validator may choose how it sources the events for each connected Starport chain. However, a default configuration is provided, and thus no action is necessary beyond running a node.
*For chains with probabilistic finality, like Ethereum, the number of blocks to wait for finalization will be chosen as a parameter. In the future, it may be dependent on the relative value of the transactions contained within it.
Signing Notices
Gateway runtime emits signed notices once it has collected enough signatures from Validators. Validators are required to sign all notices in the notice queue(s) via offchain workers which sign and post signatures back into the runtime. The notices can then be taken to a Starport to be executed, which is why validators need a key for each chain key type.
Notices are queued up by the runtime in response to certain extrinsics or other conditions which can occur. For instance, a user initiates an unlock via an extrinsic, which results in an ExtractionNotice or CashExtractionNotice being signed. Or governance votes on a new CASH yield rate, resulting in a FutureYieldNotice.
Nothing needs to be done beyond running a validator node with valid keys, in order to sign notices correctly.
Getting Paid
Choosing a Miner Address
The miner address is supplied via an inherent generated by the block author. Detailed instructions for configuring our reference implementation can be found here. If no miner address is supplied, the validators Eth identity key address is used.
A miner address should be chosen to receive validator rewards.
Being a Credible Validator
Running a validator node is a big responsibility. Validators are expected to secure their keys and nodes to the best of their ability. Only the most competent validators are likely to be elected and re-elected.
Hardware Security Modules
Whenever possible, hardware keys should be used for signing. Only the hardware wallet should have access to the raw key material, and only the validator node should be able to request signatures from the hardware wallet.
Node Protection
One of the goals of testnet is to harden the chain against various potential attacks. This means there will likely be some level of experimentation, and hopefully discussion, around the best practices for running a secure validator, and how to enforce/incentivize those things from the chain runtime.
Best practices will be maintained as part of the repo.
Booting a Validator Node
Hardware Requirements
These specifications should be more than sufficient to operate a Gateway node.
- CPU - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz
- Storage - A NVMe solid state drive >= 200GB (initial over-estimate)
- Memory - 64GB
Other Requirements
- Internet connectivity
- Ability to run a substrate binary (compile a Rust program and run it on the server)
- Firewall protecting server (highly recommended)
- Hardware Security Module (highly recommended) for signing notices
- Access to a trusted Ethereum node for reading events
- Same for any other Starport chains added during testnet
Building the Node Binary
Validators should build the node binary from source. Instructions for building and running are included together with the repository itself. The primary command used to build is:
cargo +nightly build --release
The node can be configured to run and monitored like any other Substrate chain.
QuickStart
#install rust
curl https://sh.rustup.rs -sSf | sh
rustup toolchain install nightly
rustup target add wasm32-unknown-unknown --toolchain nightly
# install substrate
curl https://getsubstrate.io -sSf | bash -s -- --fast
# build the compound chain release binary
git clone https://github.com/compound-finance/compound-chain.git
cd compound-chain
cargo +nightly build --release
# set MINER env var for validator payments, note, this is required to import blocks, whether you expect to author any blocks or only sync. e.g.
export MINER="ETH:0x3d9819210A31b4961b30EF54bE2aeD79B9c9Cd3B"
# set ETH_KEY and ETH_KEY_ID env var for signing notices to send events back to Ethereum. Note, be careful with your private keys! generate a throwaway testnet wallet or set the variable in some safer manner.
export KEYRING_TYPE=IN_MEMORY
export ETH_KEY="8da4ef21b864d2cc526dbdb2a120bd2874c36c9d0a1fb7f8c63d7f7a8b41de8f"
export ETH_KEY_ID=my_eth_key_id # for in memory keys, this can be anything
# Alternatively, if you are deployed on AWS, AWS_KMS is supported instead of ETH_KEY env var using.
export KEYRING_TYPE=AWS_KMS
export AWS_REGION=your_aws_region
export ETH_KEY_ID=your_key_arn
Environment="ETH_KEY_ID=arn:aws:kms:us-east-2:936310256153:key/8ab1ec35-f0f2-4aff-487"
# start the node in unsafe mode to set your author key #TODO: double check if rpc-methods unsafe is needed
./target/release/compound-chain \
--chain ./alphaTestnetChainSpecRaw.json \
--rpc-methods Unsafe \
--bootnodes /dns/brr-alice.compound.cash/tcp/30333/p2p/12D3KooWDpSeozmDJKZoyW4L197npEDCHovDZ8UAfnh8pFchbvVW
# Generate consensus keys in the node keystore, if you changed the rpc port, make sure to change the port you send this command to. Save the result for the next step
curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933
# Set session keys, ( tell node to use the keys you generated on last step )
## AUTHORITY ROTATION UNDER CONSTRUCTION
# TODO: this needs to be signed xtrinsic, right? polkadot.js instructions?
curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "session_setKeys", "params":[ROTATE_KEYS_OUTPUT]}' http://localhost:9933
# restart node, removing unsafe rpc and adding telemetry and Compound Labs bootnode. If you wish to boot from another node or nodes, you may
./target/release/compound-chain \
--chain ./alphaTestnetChainSpecRaw.json \
--bootnodes /dns/brr-alice.compound.cash/tcp/30333/p2p/12D3KooWDpSeozmDJKZoyW4L197npEDCHovDZ8UAfnh8pFchbvVW \
--validator \
--telemetry-url 'wss://telemetry.polkadot.io/submit/ 0' \
--name "My Gateway Testnet Node"
You should start syncing immediately. For guidance on deploying remotely, the Compound Labs testnet nodes are deployed with ansible and terraform on AWS, here. The polkadot secure validator setup is another great resource to understand deploying substrate nodes. For additional reference, the polkadot validator set up steps are very similar to those described here. As always, discussion will be ongoing in the Compound Discord.
Additional Resources
Adding Assets to Existing Starports
Adding assets to Compound Chain is easy and just requires a runtime call. This means that no software updates are required by validators, they will happen automatically as governance proposals are executed on Ethereum.
In order to add an asset, someone must build an extrinsic with the call to AddAsset. This extrinsic is added to a governance proposal on Compound Ethereum. When the proposal succeeds and is executed, the Ethereum Starport checks that the appropriate admin contract is the sender, and relays the message to Compound Chain as an event.
In particular, once Compound Chain executes the AddAsset admin function call, the new asset is stored in the supported assets on chain, and will be usable (assuming its price is also being reported).
Adding Starports
Adding starports to Compound Chain in some cases may simply require a runtime upgrade, just like adding an asset. Other cases (and probably the first one or two) are more likely to require explicit node software updates by validators. This depends on the complexities of fetching events from the starport chain and whether a new key type must be added to support it.
Chain Updates
Most chain upgrades happen via runtime upgrades. That is, an extrinsic is built containing the new WASM bytecode for the runtime, and then swapped using SetCode.
First the proposal containing the extrinsic is put forward to Compound Ethereum governance. If the proposal is passed, it is queued in the timelock, and then may be executed. Once executed, the Ethereum Starport will emit an event relaying the call to Compound Chain.
Once Compound Chain receives an officially executed governance proposal from the Ethereum Starport, it executes the proposal with Root privileges, meaning it may invoke any of the admin functions existing on Compound Chain (including SetCode to modify the runtime code itself).