Block production is a complex process and requires a node to connect to the internet. A wallet is said to be "hot" if the private key is available on a machine that is connected to the internet. More careful block producers may wish to avoid having hot wallets with substantial stake on them to mitigate risk in the case of hackers breaking into their systems.
A wallet is said to be "cold" if the private key is not and never has been available on the internet. Cold storage is preferred for wallets associated with meaningful stake as it is harder to hack into such systems if they never have been on the internet. This could be as easy as generating a keypair on a laptop with the internet turned off or using a hardware wallet like the a ledger device.
Mina's protocol requires block producers to stake using a hot wallet (see why in the last section of this article) -- however, there are some mechanisms in place to allow careful block producers to keep the vast majority of their stake in a cold wallet. Produced blocks and all the earnings associated with the produced blocks occur via delegation from this cold wallet to a hot one.
The next chunk of this article describes the actions needed to produce blocks effectively with the majority of your stake starting on and remaining on a cold wallet.
Before running your block producer, you'll need at least two accounts: One cold wallet and one hot wallet.
See our documentation page on generating keys. Note that as this is a hot wallet, you should not use the ledger or any other HSM for this keypair.
Take note of your hot public key.
Your hot wallet must be present in the consensus ledger before it can be used for staking. If your hot wallet address is present in the genesis ledger, then no further action is needed. However, if it is not, it's important that you acquire at least enough mina tokens to cover the account-creation-fee and send those tokens to this public key.
See our documentation page on generating keys. Note that as this is a cold wallet, you should prefer using the most secure mechanism for generating keys as you can preferably on a machine disconnected from the internet.
Your cold wallet must be present in the consensus ledger before its stake can be counted when delegated to your hot wallet. If you cold wallet address is present in the genesis ledger, then no further action is needed. Otherwise, acquire enough tokens to meaningfully participate in consensus and send it to this cold wallet address.
Next, ensure that you have delegated your cold account to your hot one. If you've set up your account to delegate to the correct spot in the genesis ledger, then no further action is needed. Otherwise you can delegate by using the
mina client delegate-stake command if your key was generated on a computer. Otherwise, see the delegate instructions on the Mina ledger README to learn more.
Follow the "Start up a node" instructions in the Connecting to the Network page using your hot wallet key.
You may be thinking: Why can't I create blocks directly from a secure enclave or other HSM device in Mina's protocol?
Two components of block production require use of the private key in interesting ways: Winning a slot and creating the Blockchain SNARK. Creating the SNARK within the secure hardware especially is extremely difficult and likely impossible to do quickly enough for our protocol given today's technology.
A block producer can determine if they've won a slot by evaluating a VRF (or verifiable random function) using their private key. The VRF needs to be evaluated for your account and every account that delegates to you for all slots within an epoch. To our knowledge, no one has ever implemented a VRF on an HSM, but this is likely not too difficult.
When a block producer wins a slot, in addition to just creating and broadcasting a block, a block producer must create a new SNARK proof that proves that the blockchain is valid including this new block. The SNARK proof uses the private key when it is embedding the VRF information into the proof. This proof is in place of a simple signature that other protocols ask their validators to perform. Creating this SNARK proof is very computationally expensive and relies on a lot of advanced cryptography. No HSMs on the market are capable of creating this SNARK proof efficiently enough even if one spent the time to implement the SNARK proving algorithm on them.