Indexer.abi.json

Overview

This file defines the Application Binary Interface (ABI) of a smart contract named Indexer. The ABI specifies the contract's external interface, including its functions, inputs, outputs, and storage fields. It is used to interact with the contract on-chain by encoding and decoding data during transactions and calls.

The Indexer contract appears to manage ownership verification and wallet association with identity and cryptographic proofs, likely in a decentralized identity or authorization context. It supports complex ownership verification via zero-knowledge proofs and cryptographic keys, updating wallet addresses, querying contract details, and self-destruction.

ABI Structure and Components

ABI Metadata

ABI version: 2 — Specifies the ABI specification version.
Contract version: "2.4" — Version of the contract interface.
Header: ["pubkey", "time", "expire"] — Standard message header fields used in contract calls for authentication and replay protection.

Fields

The contract stores several internal state variables, some initialized during deployment:

Field Name	Type	Initialization	Description
`_pubkey`	uint256	true	Public key associated with the contract.
_timestamp	`uint64`	false	Timestamp of last state change or event.
_constructorFlag	`bool`	false	Flag to indicate constructor has run.
`_name`	`string`	true	Name or identifier for the contract.
`_wallet`	address	false	Wallet address linked to this indexer.
`_root`	address	false	Root address for hierarchical structure.
`_rootPubkey`	uint256	false	Root-level public key for verification.

Functions

1. `constructor(wallet, rootPubkey, index, root)`

Purpose: Initializes the contract instance with the provided wallet address, root public key, index, and root address.
Inputs:
- wallet (address): The wallet address associated with this indexer.
- rootPubkey (uint256): The root public key used for verification.
- index (uint128): An index value likely used for ordering or identification.
- root (address): Root address for hierarchical linking.
Outputs: None.
Usage: Called once during contract deployment to set initial state.

2. `isOwner(wallet, zkid, proof, epk, epk_sig, epk_expire_at, jwk_modulus, kid, jwk_modulus_expire_at, index_mod_4, iss_base_64, provider, header_base_64, pub_recovery_key, pub_recovery_key_sig, jwk_update_key, jwk_update_key_sig, root_provider_certificates, owner_pubkey, index)`

Purpose: Verifies ownership of the given wallet using a comprehensive set of cryptographic proofs and identity information.
Inputs:
- wallet (address): Wallet address to verify.
- zkid (string): Zero-knowledge identifier.
- proof (bytes): Zero-knowledge proof data.
- epk (uint256), epk_sig (bytes), epk_expire_at (uint64): Ephemeral public key and related signature/expiration.
- jwk_modulus (bytes), kid (bytes), jwk_modulus_expire_at (uint64): JSON Web Key modulus, key ID, and expiration.
- index_mod_4 (uint8): Index modulo 4, possibly for sharding or partitioning.
- iss_base_64 (string), provider (string), header_base_64 (string): Issuer information and cryptographic headers.
- pub_recovery_key (uint256), pub_recovery_key_sig (bytes): Recovery key and its signature.
- jwk_update_key (uint256), jwk_update_key_sig (bytes): JWK update key and signature.
- root_provider_certificates (map(uint256,bytes)): Map of root provider certificates.
- owner_pubkey (uint256): Owner's public key.
- index (uint128): Index for identification.
Outputs: None.
Usage: Called to prove ownership with complex cryptographic validation, potentially integrating zero-knowledge proofs and JWK-based authentication.

3. `isOwnerRoot(wallet, zkid, proof, epk, epk_sig, epk_expire_at, jwk_modulus, kid, jwk_modulus_expire_at, index_mod_4, iss_base_64, provider, header_base_64, pub_recovery_key, pub_recovery_key_sig, jwk_update_key, jwk_update_key_sig, root_provider_certificates, owner_pubkey, mirror)`

Purpose: Similar to isOwner but includes a mirror address, likely for root-level or mirrored ownership verification.
Inputs: Same as isOwner except the last parameter is:
- mirror (address): A mirror address, possibly referencing another contract or entity.
Outputs: None.
Usage: Used for root ownership verification or mirroring state across contracts.

4. `setNewWallet(wallet)`

Purpose: Updates the wallet address bound to this indexer.
Inputs:
- wallet (address): The new wallet address to associate.
Outputs: None.
Usage: Called to change the associated wallet, possibly after ownership verification.

5. destroyNode()

Purpose: Self-destructs the contract instance, removing it from the blockchain state.
Inputs: None.
Outputs: None.
Usage: Called to clean up or decommission the indexer node.

6. getDetails()

Purpose: Retrieves basic details about the contract instance.
Inputs: None.
Outputs:
- name (string): The name identifier of the contract.
- wallet (address): The associated wallet address.
Usage: Used to query stored metadata.

7. getVersion()

Purpose: Returns the version information for the contract.
Inputs: None.
Outputs:
- value0 (string): First version string.
- value1 (string): Second version string.
Usage: Used to verify contract interface versioning.

Important Implementation Details

The contract uses a header with pubkey, time, and expire fields to secure function calls, which is typical for authenticated blockchain messages.
Ownership verification (isOwner and isOwnerRoot) involves extensive cryptographic validation, including zero-knowledge proofs, ephemeral public keys, JSON Web Key (JWK) moduli, signatures, and root certificates. This indicates a robust multi-layered identity verification mechanism.
The contract supports hierarchical or mirrored ownership models, suggested by the presence of a root address and the mirror parameter in isOwnerRoot.
The contract maintains immutable fields initialized at deployment (_pubkey, _name) and mutable state like _wallet and _root which can be updated.
The destroyNode function allows complete removal of the contract, which is critical for lifecycle management.

Interaction With Other System Components

The contract interacts with cryptographic verification data structures such as zero-knowledge proofs and JWKs, which are likely produced and managed by off-chain identity providers or cryptographic services.
It references root_provider_certificates, implying integration with a certificate authority or root trust anchors.
The use of a mirror address in ownership verification suggests coordination or synchronization with related contracts or nodes in a network, possibly part of a larger identity or authorization framework.
Wallet updates and ownership checks indicate that this contract acts as a node or indexer in a system managing decentralized identity ownership and authorization.

Visual Diagram

flowchart TD
Constructor["constructor"]
IsOwner["isOwner"]
IsOwnerRoot["isOwnerRoot"]
SetNewWallet["setNewWallet"]
DestroyNode["destroyNode"]
GetDetails["getDetails"]
GetVersion["getVersion"]
Constructor -->|initializes| _pubkey
Constructor -->|initializes| _name
Constructor -->|initializes| _wallet
Constructor -->|initializes| _root
Constructor -->|initializes| _rootPubkey
IsOwner -->|verifies| Wallet[Wallet]
IsOwner -->|uses| Proofs[Proofs & Keys]
IsOwnerRoot -->|verifies root| Mirror[Mirror Address]
SetNewWallet -->|updates| _wallet
DestroyNode -->|self-destruct| Contract[Indexer Contract]
GetDetails -->|returns| NameWallet[Name & Wallet]
GetVersion -->|returns| Version[Version Info]
Wallet -->|linked to| IndexerContract[Indexer Contract]
Proofs -.->|provided by| OffChainServices[Off-chain cryptographic services]
Mirror -.->|syncs with| RelatedContracts[Related contracts]

The diagram illustrates the main functions and their relationships to contract state and external inputs. It highlights the initialization flow, ownership verification complexity, wallet management, and contract lifecycle actions.