Crypto is a tool for turning a whole swathe of problems into key management problems. Key management problems are way harder than (virtually all) cryptographers think.
The Celo protocol was designed with the understanding that there is often an inherent tradeoff between the convenience of accessing a private key and the security with which that private key can be custodied. In general Celo is unopinionated about how keys are custodied, but also allows users to authorize private keys with specific, limited privileges. This allows users to custody each private key according to its sensitivity (i.e. what is the impact of this key being lost or stolen?) and usage patterns (i.e. how often and under which circumstances will this key need to be accessed).
The table below outlines a summary of the various account roles in the Celo protocol. Note that these roles are often mutually exclusive. An account that has been designated as one role can often not be used for a different purpose. Also note that under the hood, all of these accounts) are based on secp256k1 ECDSA private keys with the exception of the BLS signer. The different account roles are simply a concept encoded into the Celo proof-of-stake smart contracts, specifically Accounts.sol.
For more details on a specific key type, please see the more detailed sections below.
An account used to send transactions in the Celo protocol
Locked Gold Account
Used to lock and unlock cGLD and authorize signers
Authorized vote signer
Can vote on behalf of a Locked Gold Account
Authorized validator (group) signer
Can register and manage a validator group on behalf of a Locked Gold Account
Authorized validator signer
Can register, manage a validator, and sign consensus messages on behalf of a Locked Gold Account
Authorized validator BLS signer
Used to sign blocks as a validator
Authorized attestation signer
Can sign attestation messages on behalf of a Locked Gold account