BLSKeyIndex.abi.json

Overview

The BLSKeyIndex.abi.json file defines the Application Binary Interface (ABI) for a smart contract module that manages BLS (Boneh–Lynn–Shacham) keys associated with wallets. The primary purpose of this contract is to handle the acceptance and validation of BLS keys linked to a given wallet address and indexed by a signer. It also tracks metadata such as timestamps, readiness state, and versioning. The contract exposes functions to verify key acceptance conditions, manage lifecycle actions (construction and destruction), and retrieve contract state information.

This ABI specifies the contract's interface, including its functions, state variables (fields), and event structure (empty in this case). It provides the necessary details for interacting with this contract in a blockchain environment supporting this ABI format.

Detailed Description of Classes and Functions

Fields (State Variables)

Name	Type	Initialization	Description
`_pubkey`	`uint256`	true	BLS public key associated with this contract instance.
`_timestamp`	`uint64`	false	Timestamp marking a significant event or state change.
`_constructorFlag`	`bool`	false	Flag indicating whether the constructor has completed.
`_root`	`address`	true	Root wallet address linked to this BLS key instance.
`_bls`	`bytes`	true	Raw BLS key data in byte format.
`_wallet`	`address`	false	Wallet address currently associated or in use.
`_ready`	`bool`	false	Indicates if the contract is in a ready state for operations.

Functions

All functions are defined with their inputs and outputs, with no explicit return values except where noted. The contract uses version 2.4 of the ABI specification.

constructor(wallet: address)

Purpose: Initializes the contract instance and associates it with a specific wallet address.
Parameters:
- wallet (address): The wallet address to bind with this BLS key index.
Returns: None
Usage: This function is called once upon contract deployment to set the initial wallet.

isBLSKeyAccept(wallet: address, signerIndex: uint16, pubkey: uint256, rep_coef: uint128, stake: uint128, virtualStake: optional(uint128), ProxyList: map(uint8, string), myIp: string, nodeVersion: optional(string))

Purpose: Performs validation to determine if a given BLS key is acceptable for the wallet and signer index provided.
Parameters:
- wallet (address): Wallet address associated with the key check.
- signerIndex (uint16): Index of the signer within the wallet.
- pubkey (uint256): The BLS public key to validate.
- rep_coef (uint128): Reputation coefficient influencing acceptance.
- stake (uint128): Stake amount associated with the signer.
- virtualStake (optional(uint128)): Optional virtual stake amount that may modify validation.
- ProxyList (map(uint8, string)): A mapping representing proxy nodes or addresses.
- myIp (string): IP address of the node requesting verification.
- nodeVersion (optional(string)): Optional version string of the node software.
Returns: None
Implementation Details: This function likely contains logic to check if the BLS key meets certain criteria based on stake, reputation, and network topology (proxied nodes). The inclusion of virtualStake and nodeVersion suggests dynamic or conditional acceptance logic.
Usage: Called when a node or wallet wants to verify if a BLS key can be accepted for signing or participation.

isBLSKeyAcceptContinue(wallet: address, signerIndex: uint16, pubkey: uint256, seqNoStartOld: uint64, stake: uint128, virtualStake: optional(uint128), ProxyList: map(uint8, string), sumReputationCoef: uint128, nodeVersion: optional(string))

Purpose: Continuation or second-stage validation of a BLS key acceptance process, possibly after an initial check.
Parameters:
- wallet (address): Wallet address under validation.
- signerIndex (uint16): Signer index.
- pubkey (uint256): BLS public key.
- seqNoStartOld (uint64): Sequence number from a prior state or session.
- stake (uint128): Stake amount.
- virtualStake (optional(uint128)): Optional virtual stake.
- ProxyList (map(uint8, string)): Proxy mapping.
- sumReputationCoef (uint128): Total reputation coefficient.
- nodeVersion (optional(string)): Optional node version string.
Returns: None
Implementation Details: This function likely performs additional checks that depend on a sequence number and aggregate reputation, indicating it's part of a multi-stage key acceptance or renewal protocol.
Usage: Invoked after isBLSKeyAccept to finalize acceptance logic or handle continued validation workflows.

destroyRoot()

Purpose: Destroys or removes the root contract or associated resources.
Parameters: None
Returns: None
Usage: Used to clean up or deactivate the root or parent contract instance.

destroy()

Purpose: Destroys or deactivates this contract instance.
Parameters: None
Returns: None
Usage: Called to dismantle or remove this BLS key index contract from the blockchain.

getReadyStatus() -> bool

Purpose: Retrieves the readiness state of the contract.
Parameters: None
Returns:
- ready (bool): true if the contract is ready for operations, otherwise false.
Usage: Can be called by external entities to check if the contract is fully initialized and ready to accept operations or key validations.

getVersion() -> (string, string)

Purpose: Returns the version information of the contract.
Parameters: None
Returns:
- value0 (string): The primary version string.
- value1 (string): Secondary version string or sub-version.
Usage: Provides versioning metadata for compatibility and maintenance purposes.

Important Implementation Details and Algorithms

The contract maintains initialization flags and timestamps to track the lifecycle of the BLS key index.
The use of optional parameters in isBLSKeyAccept and isBLSKeyAcceptContinue enables flexible validation logic adapting to different node versions and stake configurations.
The ProxyList map suggests the contract may consider proxy nodes in its acceptance algorithm, potentially to manage delegated or multi-node signing.
The multi-step acceptance process (isBLSKeyAccept followed by isBLSKeyAcceptContinue) indicates a protocol that handles both initial validation and continuation/confirmation phases, possibly to prevent replay attacks or ensure state synchronization.
Destruction functions allow for controlled cleanup, supporting contract upgrade or deactivation scenarios.

Interaction with Other System Components

The contract depends on wallet addresses and signer indices, indicating it functions within an ecosystem that manages multiple signers per wallet.
It interacts with external inputs such as reputation coefficients, stake amounts, and proxy lists, which are likely maintained or updated by other parts of the system.
The presence of nodeVersion parameters suggests compatibility checks or feature gating based on node software capabilities.
Functions like destroyRoot imply a hierarchical contract structure where this contract might be a child or submodule controlled by a root contract.
The ABI allows external callers (e.g., nodes, wallets, or system controllers) to query readiness and version, facilitating integration and monitoring.

Mermaid Diagram: Structure of BLSKeyIndex Contract

classDiagram
class BLSKeyIndex {
+_pubkey: uint256
+_timestamp: uint64
+_constructorFlag: bool
+_root: address
+_bls: bytes
+_wallet: address
+_ready: bool
+constructor(wallet)
+isBLSKeyAccept(wallet, signerIndex, pubkey, rep_coef, stake, virtualStake, ProxyList, myIp, nodeVersion)
+isBLSKeyAcceptContinue(wallet, signerIndex, pubkey, seqNoStartOld, stake, virtualStake, ProxyList, sumReputationCoef, nodeVersion)
+destroyRoot()
+destroy()
+getReadyStatus() bool
+getVersion() string,string
}

This diagram visualizes the contract’s primary fields and exposed functions, highlighting its role in managing BLS key acceptance and contract lifecycle.