Struct diem_key_manager::KeyManager
source · pub struct KeyManager<LI, S> { /* private fields */ }
Implementations§
source§impl<LI, S> KeyManager<LI, S>where
LI: DiemInterface,
S: KVStorage + CryptoStorage,
impl<LI, S> KeyManager<LI, S>where LI: DiemInterface, S: KVStorage + CryptoStorage,
pub fn new( diem: LI, storage: S, time_service: TimeService, rotation_period_secs: u64, sleep_period_secs: u64, txn_expiration_secs: u64, chain_id: ChainId ) -> Self
sourcepub fn execute(&mut self) -> Result<(), Error>
pub fn execute(&mut self) -> Result<(), Error>
Begins execution of the key manager by running an infinite loop where the key manager will periodically wake up, verify the state of the validator keys (e.g., the consensus key), and initiate a key rotation when required. If something goes wrong that we can’t handle, an error will be returned by this method, upon which the key manager will flag the error and stop execution.
sourcepub fn execute_once(&mut self) -> Result<(), Error>
pub fn execute_once(&mut self) -> Result<(), Error>
Checks the current state of the validator keys and performs any actions that might be required (e.g., performing a key rotation).
pub fn compare_storage_to_config(&self) -> Result<(), Error>
pub fn compare_info_to_config(&self) -> Result<(), Error>
pub fn last_reconfiguration(&self) -> Result<u64, Error>
pub fn last_rotation(&self) -> Result<u64, Error>
pub fn diem_timestamp(&self) -> Result<u64, Error>
pub fn resubmit_consensus_key_transaction(&mut self) -> Result<(), Error>
pub fn rotate_consensus_key(&mut self) -> Result<Ed25519PublicKey, Error>
pub fn submit_key_rotation_transaction( &mut self, consensus_key: Ed25519PublicKey ) -> Result<Ed25519PublicKey, Error>
sourcepub fn evaluate_status(&mut self) -> Result<Action, Error>
pub fn evaluate_status(&mut self) -> Result<Action, Error>
Evaluates the current status of the key manager by performing various state checks between secure storage and the blockchain.
Note: every time this function is called, the diem_timestamp registered on-chain must be strictly monotonically increasing. This helps to ensure that the blockchain is making progress. Otherwise, if no progress is being made on-chain, a reconfiguration event is unlikely, and the key manager will be unable to rotate keys.