Recently I have received a forwarded mail from my friend asking about my interest in running/delegating a Cardano staking pool. As I never tried my hand in running a node and also completely unaware of all the prerequisite details that need to be checked. So, I thought to give it a try at least for the time being I prepared myself to gain some knowledge about how everything happens. Here, I am sharing what do you need if you want to run a stake pool.
What are stake pools?
A staking pool allows multiple users to combine their resources and take part in the protocol without personally worrying about running and validating nodes. If you want to participate (delegate) in a staking pool then neither you require any constant internet connection nor you have to monitor the token value all the time. The stake pool node does all these jobs on your behalf.
The stake pool is the key component of the Cardano PoS protocol that represents the combined stake of pool users as a whole and is responsible for processing transactions and producing new blocks. To maintain security and network liveliness the protocol requires a sufficient number of nodes to be online. And in return, the stake pool operators are rewarded with incentives.
Prerequisites for stake pool operators
The following things are mandatorily needed for a Cardano stake pool operator:
- Knowledge regarding the initial environment set up.
- The node needs to be active all the time i.e 24*7*365.
- Should have system operation skills i.e able to run and maintain Cardano node.
- Knowledge regarding server maintenance and operation activities.
- Experience of development and operations (DevOps) would be very useful
- Familiarity with Prometheus or Grafana for alerts and monitoring, or some other monitoring framework of your choice.
Minimum requirements for running a stake pool
Following hardware requirements are needed:
- 4 GB of RAM
- 24 GB of hard disk space
- a good network connection and about 1 GB of bandwidth per hour
- a public IP4 address
Note that running a stake pool is not majorly dependent on processor speed.
Stake pool operator keys
Operators need to manage the hot (online), and cold (offline) keys for the pool. The cold keys should be kept secured in a device with no internet connectivity.
Stake pool operator needs these following types of keys:
- Stake pool cold key
- Stake pool hotkey (KES key)-Node operational key use to authenticate user identity. The KES key comes with a validity period mentioning the start time and key period parameters and needs to be updated every 90 days.
- Stake pool VRF key- Signing verification key. Stored within the operational certificate
Operational certificates
Stake pool operators must provide an operational certificate to verify that the pool has the authority to run and to check whether an operational key is valid or not to prevent malicious interference.
The certificate includes:-
- Operator’s signature.
- Other important information like addresses, keys, etc. about the pool
Certificates are generated on the offline machine using the offline/cold keys, before being copied over to the node to validate the KES keys used to sign the blocks. The certificate identifies the current operational key and is signed by the operator’s offline key.
Certificates include a kes-period (start date), which indicates the validity period of the certificate.
These certificates also contain a counter number in the header of each block that the node generates. The counter number helps in identifying the status of the certificate.
The counter plays a vital role in incase the KES key gets compromised. In such a scenario, the owner of the cold keys can create a new KES key and a new certificate with a higher issue number. So, whenever the node identifies two blocks that originate from the same cold key but using different KES keys, the higher issue counter gets selected.
Public stake pools
Public stake pools contain metadata in the registration certificate that is sent by a stake pool operator. This feature is although optional. The certificate might contain a URL of up to 64 bytes in length that points to a JSON object with the following content:
- A ticker of 3-5 characters, for a compact display of stake pools in a wallet.
- Title/name of up to 50 characters.
- Short textual description
- Homepage links with additional information about the pool (optional).
These are important considerations to note about the metadata:
- Metadata information is encoded in UTF-8, and will never exceed 512 bytes
- The content hash of the JSON object referenced in the URL (if present), should match the content hash in the registration certificate. In case of any discrepancy, the pool will not be displayed in a wallet.
- For the wallet to display the pool, the following conditions must be met
- The registration certificate must refer to the metadata.
- The metadata must be valid and have the correct content hash.
- The URL to the referenced JSON object should be present and be able to validate with the content hash in the registration certificate. If this process fails, the wallet will not display the pool.
- Any changes in the metadata require a new stake pool registration certificate with the new content hash that will be provided by the stake pool operator.
Metadata proxy servers
Metadata uses proxy servers to query the URL included in the registration certificate and then cache the metadata using the pool’s id as key. Wallets query these proxy servers to retrieve the metadata for the pools instead of sending an individual request to each of the pool’s metadata URLs. The cache metadata will become invalid if it does not match with the content hash listed on the certificate.
Thus this method provides desirable security benefits with the use of proxy servers. But they could become a point of centralization. To avoid this, they provide third parties (stake pools, community members, etc.) with code and binaries so they can run their proxy servers and prevent centralization.
Stake Pool Architecture
A stake pool node is a Jormungandr server that validates blocks from the Cardano blockchain. The stake pool operator sets up a stake pool node and after setup, it registers on the stake pool registry. The registry is maintained by the Cardano Foundation that contains metadata about stake pool owners. This data will be displayed in the Daedalus interface. Users who are not listed in Daedalus can still able to set up a stake pool if they have sufficient ADA to pay the transaction fee. The token holder can select the stake pool to which they want to delegate their stake by navigating to the Delegation tab in the Daedalus interface. This delegation action is recorded on the Cardano blockchain and will influence the slot leader selection process in the next epoch.
As stake pool operator, you will have two types of nodes:
Core nodes- Responsible for producing blocks. It is configured with various key-pairs and an operational certificate needed for block generation (cold keys, KES hotkeys, and VRF hotkeys). It only connects to its one or more relay nodes.
Relay nodes- Responsible for communicating with its core node, other relays, and external broadcasting blocks. A relay node doesn’t need any keys and will, therefore, be unable to produce blocks.
Each node should run on a dedicated server, and the core node server’s firewall should be configured to only allow incoming connections from its relays.
If you want to install the node from source then follow the steps here
Resources:
http://static.iohk.io/docs/guides/IOHK-StakePoolOperatorsGuide-ENG.pdf
https://docs.cardano.org/en/latest/getting-started/stake-pool-operators/index.html
