Validate State

Validate the current state of the Genesis. Contains 3 validation steps:

1. Input validation - the validation begins by evaluating global constraints, such as the allowance for extra objects and the presence of validators. If extra objects are not permitted and any are present, an error is immediately raised to enforce the restriction. This ensures that the input remains consistent with the system's intended configuration.

   Each validator is then individually validated to verify that its metadata is correct and adheres to specific rules. Validator metadata checks to ensure it meets requirements for length, character set, format, and logical correctness. The process involves validating key metadata fields such as names, descriptions, and various network addresses:

   • Name Validation: The name must consist of ASCII characters and must not exceed a predefined maximum length. This ensures compatibility and readability.
   • Description Validation: Descriptions must also be ASCII and within the allowable length, ensuring that metadata remains concise and standardized.
   • URL Validation: URLs for images and projects must not exceed the maximum length. This prevents excessively long or malformed URLs from being accepted.
   • Network Address Validation: Each network address (e.g., network_address, p2p_address, primary_address) must be ASCII-compliant and adhere to the length constraints. Additionally, these addresses must be correctly formatted for their respective types.
   • Address Format Checks: Specific addresses, such as p2p_address and primary_address, must be valid in the anemo protocol context. Any errors in parsing or interpreting these addresses result in immediate validation failure.
   • The validator's authority public key is extracted, and its proof of possession is verified. This cryptographic check ensures that the validator legitimately owns the provided authority key and account address.
   • The commission rate for validators must not exceed 100%, ensuring logical and acceptable fee structures.

   #![allow(unused)]
   fn main() {
   pub name: String,
   pub account_address: IotaAddress,
   pub authority_key: AuthorityPublicKeyBytes,
   pub protocol_key: NetworkPublicKey,
   pub network_key: NetworkPublicKey,
   pub gas_price: u64,
   pub commission_rate: u64,
   pub network_address: Multiaddr,
   pub p2p_address: Multiaddr,
   /// Primary address used for consensus-related inter-node communication.
   pub primary_address: Multiaddr,
   pub description: String,
   pub image_url: String,
   pub project_url: String,
   
   /// GenesisValidatorInfo
   pub proof_of_possession: AuthoritySignature,
   }

2. Token Distribution Schedule Validation - the validation process for the token distribution schedule ensures that the allocation and staking of tokens meet predefined rules and thresholds. The process begins with verifying the token distribution schedule itself, ensuring that all allocations are consistent with predefined rules. If a distribution schedule is provided, it undergoes a thorough validation to confirm that the total amount of tokens allocated does not exceed the pre-minted supply. Each allocation is evaluated for compliance with governance requirements, including verifying that tokens are staked with valid validators.

   Additionally, the process validates that all tokens allocated for staking are associated with valid validators. Each validator referenced in the schedule must exist and be available to participate in the network. The total staked tokens for each validator are aggregated, and their stakes are evaluated against the minimum stake threshold defined in the system's governance rules. This threshold ensures that validators have sufficient tokens staked to actively and effectively contribute to the network's operations. Any validator failing to meet the minimum stake requirement is flagged as non-compliant, with detailed error messages identifying the specific issues.

3. Output Validation - the output validation flow ensures that the generated output—representing the initial chain state—is correct, consistent, and adheres to all predefined system requirements and rules. The validation begins by retrieving the generated genesis checkpoint. If no genesis has been built, the validation process terminates early, as there is no output to validate. We can highlight 7 validation steps:

   1. Genesis System State Validation The genesis system state is verified to ensure it adheres to the expected configuration. For non-testing environments, the genesis state must be of version V1. System components such as the randomness state, authenticator state, bridge object, and coin denylist are validated to confirm their presence or absence based on the protocol configuration.
   2. Validator Metadata and Pool Mapping Active validators in the genesis state are matched against the input validators. The metadata of each validator is validated against its corresponding input definition, including: - IOTA address - Authority and network keys - Gas price and commission rate - Name, description, and associated URLs This step ensures that validators in the genesis state are configured exactly as defined in the input.
   3. System Parameters Validation Chain parameters such as protocol version, epoch duration, validator thresholds, and grace periods are checked to ensure they match the configuration specified in the input. Key values like the storage fund balance and epoch start timestamp are validated to confirm proper initialization.
   4. Token Distribution Validation The token distribution schedule is validated to ensure that all allocations are accurately reflected in the genesis state. The total supply is checked against the sum of the pre-minted supply and all allocations, ensuring no discrepancy.
   5. Signature Validation Validator signatures are checked to ensure that all provided signatures correspond to known validators and are valid against the genesis checkpoint. This step confirms that the initial state is cryptographically authenticated.
   6. Migration Data Validation If migration data is present, it is validated against the unsigned genesis state to detect and prevent corrupted or malicious data. Genesis containing migrations must include valid migration data. The validation is based on cryptographic links (i.e., hash digests) between genesis transactions, transaction effects and events.
   7. Object Accounting All gas and staked objects are accounted for, ensuring no surplus or missing objects unless extra objects are explicitly permitted by the configuration. This prevents unintended discrepancies in the genesis state.