errors.sol
Overview
This Solidity source file defines an abstract contract named Errors which centralizes the definition of error codes used throughout the system. These error codes are represented as constant unsigned 16-bit integers (uint16) and cover a broad range of failure scenarios such as public key validation errors, transaction list issues, replay protection failures, signature verification problems, wallet recovery errors, and security card-related faults.
By using a centralized error contract, the system ensures consistent error handling and reporting across multiple contracts or modules, facilitating maintainability, debugging, and integration. The contract also includes a version identifier string (versionErrors) that can be used to track or enforce compatibility of error definitions.
Contract: Errors
Description
The Errors contract is declared as abstract, meaning it is not meant to be instantiated directly but rather to be inherited by other contracts that require access to standardized error codes.
Properties
Name | Type | Description |
|---|---|---|
|
| Version identifier of the error codes, currently |
|
| Error code for a zero (empty) public key. |
|
| Error code for detecting duplicate public keys. |
|
| Error code for invalid length of data or input. |
|
| Error code indicating a value that is too small. |
|
| Error code for insufficient balance in an account. |
|
| Error code when a transaction is missing or not found. |
|
| Error code indicating the transaction waitlist is full. |
|
| Error code for invalid maximum cleanup transactions count. |
|
| Error code indicating a replayed or duplicate message. |
|
| Error code for messages with an excessively large expiration timestamp. |
|
| Error code for expired messages. |
|
| Error code indicating the caller is not the owner. |
|
| Error code for an invalid cryptographic signature. |
|
| Error code indicating an expired factor (possibly for two-factor authentication). |
|
| Error code for invalid sender address detected. |
|
| Error code for an invalid Groth16 zero-knowledge proof. |
|
| Error code when a required factor is not found. |
|
| Error code indicating that a JSON Web Key (JWK) has expired. |
|
| Error code when a JWK is not found. |
|
| Error code indicating the JWK is invalid. |
|
| Error code related to TLS (Transport Layer Security) data issues. |
|
| Error code for a factor timestamp exceeding acceptable range. |
|
| Error code for duplicate certificate entries. |
|
| Error code when a certificate is not found. |
|
| Error code for JWK with a timestamp too large. |
|
| Error code indicating a new seed phrase candidate already exists during wallet recovery. |
|
| Error code when the new seed phrase candidate is not found. |
|
| Error code signaling a security card that is already activated. |
|
| Error code when there are no security cards available. |
|
| Error code for exceeding the allowable number of security cards. |
|
| Error code indicating the security card already exists. |
|
| Error code for a security card that is deactivated. |
|
| Error code when a security card is not found. |
Usage
Contracts inheriting from Errors can refer to these constants to revert transactions or emit error events with standardized error codes. This approach reduces the risk of mismatched or ambiguous error reporting.
Example usage snippet:
if (publicKey == address(0)) {
revert(uint16(Errors.ERR_ZERO_PUBKEY));
}
Implementation Details
The error codes are grouped by categories and assigned numeric values in distinct ranges (e.g., 100s for public keys, 200s for values, 300s for transaction lists, etc.) to facilitate easy identification and classification.
Error code constants are declared as
uint16to optimize storage and gas usage compared to larger integer types.The contract uses a fixed version string to support version tracking of the error definitions.
Interaction with Other System Components
This contract serves as a shared reference for error codes used by multiple components like transaction handling modules, message validation services, cryptographic proof verifiers, wallet recovery mechanisms, and security card management.
Other contracts can inherit from
Errorsto access uniform error codes, ensuring that errors returned by different contracts remain consistent and interoperable.Error codes related to cryptographic proofs and key management indicate integration with components handling authentication, authorization, and cryptographic verification, potentially linked to Digital Signature Verification and Wallet Recovery topics.
Transaction-related error codes suggest interactions with transaction pool or queue management systems, possibly detailed under Transaction Management.
Diagram: Errors Contract Structure
classDiagram
class Errors {
<<abstract>>
+string versionErrors
+uint16 ERR_ZERO_PUBKEY
+uint16 ERR_REPEATING_KEY
+uint16 ERR_BAD_LEN
+uint16 ERR_TOO_SMALL_VALUE
+uint16 ERR_LOW_BALANCE
+uint16 ERR_TRX_NOT_FOUND
+uint16 ERR_TRX_WAITLIST_OVERFLOWED
+uint16 ERR_MAX_CLEANUP_TXNS_INVALID
+uint16 ERR_MESSAGE_IS_EXIST
+uint16 ERR_MESSAGE_WITH_HUGE_EXPIREAT
+uint16 ERR_MESSAGE_EXPIRED
+uint16 ERR_NOT_OWNER
+uint16 ERR_INVALID_SIGNATURE
+uint16 ERR_FACTOR_EXPIRED
+uint16 ERR_INVALID_SENDER_ADDR
+uint16 ERR_INVALID_PROOF
+uint16 ERR_FACTOR_NOT_FOUND
+uint16 ERR_JWK_EXPIRED
+uint16 ERR_JWK_NOT_FOUND
+uint16 ERR_INVALID_JWK
+uint16 ERR_TLS_DATA
+uint16 ERR_FACTOR_TIMESTAMP_TOO_BIG
+uint16 ERR_REPEATING_CERT
+uint16 ERR_CERT_NOT_FOUND
+uint16 ERR_JWK_TIMESTAMP_TOO_BIG
+uint16 ERR_SEED_PHRASE_NEW_CANDIDATE_EXISTS
+uint16 ERR_SEED_PHRASE_NEW_CANDIDATE_NOT_FOUND
+uint16 ERR_CARD_IS_TURNED_ON
+uint16 ERR_NO_CARDS
+uint16 ERR_TOO_MUCH_CARDS_ADDED
+uint16 ERR_CARD_EXISTS
+uint16 ERR_CARD_IS_TURNED_OFF
+uint16 ERR_CARD_NOT_FOUND
}