Terminology

Zetrix Terminology

Account Nonce Value

A nonce (short for “number used once”) is a unique value used in various areas of information technology, commonly for session authentication or transaction validation. It typically changes over time or is generated as a large random number to ensure uniqueness. In general terms, "nonce" implies something used temporarily or for a specific occasion.

In blockchain systems, particularly those using Proof of Work, a nonce is the value that miners discover to satisfy the network’s difficulty requirement thereby proving block validity.

In the Zetrix blockchain, the Account Nonce Value plays a crucial role in transaction ordering. It is used to determine the sequence in which a user's transactions are executed, ensuring proper synchronization and preventing replay attacks or double-spending. Each new transaction must include the correct nonce value corresponding to the sender’s account state for it to be processed successfully.

Keypair

In the Zetrix blockchain, a keypair is used to create your public key, private key, address, and digital signature. This is how users prove their identity and approve transactions.

Zetrix only supports the ED25519 algorithm for signing, which is fast, secure, and reliable.

Raw Private Key

A Raw Private Key is a byte array generated using a random algorithm. It serves as the starting input for creating a full private key, which is then used to generate a public key and blockchain address.

Raw Public Key

A Raw Public Key is a byte array created by processing a Raw Private Key using the ED25519 algorithm. It is the initial form of the public key, used to generate the final public key and address.

Private Key

A private key is a secret code generated by an encryption algorithm and known only to the owner. It is paired with a public key and is essential for encrypting, decrypting, and signing data.

In Zetrix, the private key is used to:

• Generate the public key and blockchain address

• Sign transactions to prove ownership

Once created, the private key cannot be changed or recovered if lost, so it must be stored securely at all times.

Public Key

A public key is a string of characters generated from a private key. It can be shared openly and is used to verify the authenticity of digital signatures made with the private key.

The public key:

• Does not reveal the private key

• Is safe to transmit across networks

• Is required to generate a Zetrix address

Address

An address is a unique string of letters and numbers where cryptocurrency can be sent or received. It can be shared publicly as plain text or a QR code with anyone who wants to send you tokens. Just like a physical address, a blockchain address is essential for transactions. Without it, assets cannot be transferred.

Signature

A signature is created by encrypting transaction data using your private key and an algorithm. It proves that the transaction was made by the owner of the private key. Others can use the signature to verify the integrity and authenticity of the transaction, ensuring the data has not been altered.

Transaction

A transaction in Zetrix refers to any operation that modifies data on the blockchain. While it commonly involves the exchange of cryptocurrencies, it also includes actions such as issuing or transferring assets, sending Gas, creating accounts, setting metadata, and configuring permissions. Every transaction is recorded on-chain and must be signed using a valid private key to ensure authenticity and integrity.

Transaction Blob

A Transaction Blob in Zetrix is a hexadecimal string generated by serializing a transaction object. Serialization is the process of converting the transaction’s state and data into a structured string format using the ProtoBuf protocol, allowing it to be stored, transmitted, and later parsed or verified by the blockchain network.

Operating Zetrix

A Zetrix Operation refers to any action that involves writing to or modifying data on the Zetrix blockchain. This includes operations such as updating metadata, setting permissions, issuing assets, or executing smart contract functions all of which result in changes to the blockchain state.

Submitting Transaction

Transaction Submission refers to the process of sending a request to the Zetrix blockchain to write or modify data. This includes submitting operations such as asset transfers, contract executions, or account updates, which are then validated and recorded on the blockchain.

Querying Zetrix

Zetrix Query refers to the process of retrieving data from the Zetrix blockchain. It allows users to access information such as account balances, transaction history, contract states, and other on-chain data without modifying the blockchain state.

Account Services

Account Services in Zetrix offer interfaces for validating account existence and querying account-related information. These services enable users and applications to verify whether an account is active and retrieve details such as balances, metadata, permissions, and asset holdings.

Asset Services

Asset Services in Zetrix provide interfaces for querying asset-related information, such as asset balances, issuance details, asset codes, and issuer information.

Contract Services

Contract Services in Zetrix offer interfaces for validating smart contracts and querying contract-related data. These services enable users to check if a contract exists, retrieve its properties, and access its current state and metadata without executing or modifying the contract.

Transaction Services

Transaction Services in Zetrix provide end-to-end support for handling blockchain transactions. They include interfaces for building a Transaction Blob (serializing transaction data into a hexadecimal format), signing the transaction with a private key, querying transaction status or details, and submitting the transaction to the Zetrix network for execution. These services ensure a secure and structured process for interacting with the blockchain.

Block Services

Block Services in Zetrix provide an interface to query block-related information, allowing users to retrieve details such as block height, hash, timestamp, validator information, and the list of transactions contained within a specific block.

Serializing

Serialization is essential in Zetrix for processing and storing transaction data. For example, when signing a transaction, the transaction must first be serialized into a byte string, as only byte strings can be signed. Similarly, to store transactions, they must be converted into a byte stream. Zetrix uses Google's Protocol Buffer 3 (Protobuf 3) as the serialization framework for defining and encoding all data structures. Protobuf 3 is chosen for its high speed, compact size, and multi-language support. The SerializeAsString method is used to perform the serialization operation on Protobuf objects.

Account Address

In an asymmetric signature system, a public-private key pair is randomly generated based on a cryptographic algorithm. The private key (skey) is securely held by the user, while the public key (pkey) is shared publicly. When signing, the system computes the signature using signature = sign(skey, message), and verification is done by checking if Verify(pkey, signature, message) returns true.

However, the public key is not used directly as the user's unique identifier because its length varies by algorithm typically 64 bytes for elliptic curve cryptography and hundreds of bytes for RSA making it cumbersome for users to store or recognize.

To address this, Zetrix generates a fixed-length account address by hashing the public key and appending certain flag bits. The result is a 36-byte string, which serves as the account’s unique and user-friendly identifier, compatible with various signature algorithms.

Block

A block in Zetrix is composed of two main components: the block header (LedgerHeader) and the transactions (transaction_envs). The LedgerHeader contains metadata such as block height, timestamp, hash of the previous block, and other consensus-related data. The transaction_envs section holds the list of all transactions included in the block, representing the changes to the blockchain state for that specific block.

Asset

An asset in Zetrix is a digital certificate issued by an account, representing a unit of value or entitlement. It can be used for various purposes such as tokenized currencies, ownership rights, or access credentials within the blockchain ecosystem.

Gas Token

The Gas token is the native utility token of the Zetrix blockchain, used to pay for transaction fees and support network operation and maintenance. At genesis, 1 billion Gas tokens were created and assigned to the genesis account. An additional 500 million Gas tokens are allocated as block rewards to incentivize consensus nodes. Each time a block is generated, 8 Gas tokens are initially issued, with the reward amount decreasing by one-quarter every five years until the full 500 million are distributed over approximately 360 years. For each block, both the transaction fees and block rewards are evenly distributed among the validator nodes, with any remaining fractional balance randomly awarded to one node.

Account

An account in Zetrix represents the primary entity on the blockchain and serves as a digital mapping of a legal or natural person in the real world. It acts as the foundation for ownership, identity, and authorization across all activities within the Zetrix network.

Transaction

By broad definition, a transaction in Zetrix is a combination of one or more operations executed on an account. These operations collectively modify the blockchain state, such as transferring assets, updating metadata, or setting permissions, and are processed as a single atomic action.

Operation

An operation in Zetrix is the specific action executed within a transaction that modifies the atomic unit of an account. Each transaction may include one or more operations, such as asset transfers, permission updates, or metadata changes, which together define the intended changes to the blockchain state.

Creating Account

The account is the core entity in Zetrix through which all transactions are initiated, making it the main body of the transaction. As such, an account must be created before any other operations can be performed. Account creation is carried out by existing accounts, meaning new accounts must be initialized by accounts already on the network. The first account, known as the genesis account, is created during the launch of the Zetrix blockchain and serves as the origin from which all other accounts are derived.

Issuing Asset

Any account in Zetrix can issue its own digital assets by performing an asset issuance operation. This allows the account to define and register a new asset on the blockchain, establishing its code, issuer, and associated properties.

Transferring Asset

Asset transfer in Zetrix enables the movement of funds from a source account to a destination address. This operation deducts the specified asset amount from the sender and credits it to the recipient, effectively shifting ownership. It is a fundamental function that supports payments, settlements, and value exchanges within the blockchain ecosystem.

Setting Metadata

Metadata in Zetrix is a versioned database of key-value pairs associated with an account. Each key-value entry has a version number that automatically increments by 1 every time the corresponding data is modified, ensuring traceability and consistency of updates over time.

Setting Weight

The Set Privilege operation in Zetrix allows you to define or modify the weights of the account owner and signer for the source account. This configuration determines the authority level required for transaction approvals and multi-signature setups, enabling fine-grained control over account security and access.

Setting Threshold

In Zetrix, you can set thresholds for each type of operation on a source account. These thresholds define the minimum total weight required from signers to authorize an operation. If the combined weight of the signers in a transaction does not meet or exceed the specified threshold, the operation will be rejected by the network, ensuring controlled access and enhanced security.

Transaction Cache Queue

When a node in the Zetrix blockchain network receives a transaction request, it first performs a legality check to validate the transaction’s structure, signature, and nonce. If the transaction is deemed valid, it is then broadcast to other nodes in the network and added to the transaction cache queue, awaiting inclusion in a future block.

Transaction Packaging

In Zetrix, the system uses a timer to trigger consensus every 10 seconds for block generation. During each cycle, a node responsible for packaging transactions will sequentially retrieve up to 4MB of transactions from the front of the transaction cache queue. If a break in the nonce sequence is detected for a source account (i.e., the expected transaction order is not maintained), the system will skip all subsequent transactions from that account starting at the break point. The break is then marked, and no future blocks will include transactions from the affected source account until the sequence is corrected. These transactions will either be packaged once the correct transaction is received or removed from the cache if they time out. This ensures transaction order integrity and prevents state inconsistency across the network.

P2P

Peer-to-Peer (P2P) Networking in Zetrix refers to a distributed application architecture where tasks and workloads are shared among network participants, or peers. This model operates at the application layer, forming an ad hoc network without centralized coordination. In a P2P system, each participant acts as both a provider and consumer of resources, services, and data—facilitating decentralized communication, synchronization, and data propagation across the blockchain network.

Broadcast and Multicast

In Zetrix, message types in the P2P network are categorized based on their transmission method into broadcast and unicast messages. Broadcasting is a multi-drop approach where a message is delivered to all nodes in the network, ensuring wide dissemination. In contrast, unicasting targets a single recipient, meaning the message is sent from one node to another without being propagated further. For example, in a network with four nodes (A, B, C, and D), if node B sends a unicast message to node A, only node A receives it, and it is not forwarded to nodes C or D. This distinction helps optimize network performance and control message scope based on the communication purpose.

Consensus Node Selection

To maintain the stability and scalability of the Zetrix blockchain network, the system allows for the selection and management of verification nodes. This mechanism enables the community or governance layer to identify and exclude malicious or underperforming nodes from the consensus group. At the same time, high-performance nodes can be elected to join the verification node group, ensuring that block validation and network operations remain secure, efficient, and reliable.

Transaction Processing

In Zetrix, all operations within a single transaction are executed with atomicity, meaning they either all succeed together or all fail together. This transactional integrity ensures that partial execution does not occur, preserving the consistency and reliability of the blockchain state.

Transaction Fee

In Zetrix, users are required to pay transaction fees when submitting a transaction request. These fees help cover the costs of infrastructure depreciation, energy consumption, and ongoing operation and maintenance of the blockchain network. To support transparency and cost-efficiency, Zetrix allows users to estimate transaction fees in advance without incurring any charges, enabling them to determine a suitable fee based on their needs. Additionally, fee standards are adjustable and can be updated in response to evolving network conditions or policy changes.

Cost Estimation

In Zetrix, a basic fee check alone does not guarantee that the transaction fee is sufficient especially for contract-triggered transactions, where the execution cost can vary significantly. To address this, users are advised to use the fee evaluation interface before submitting a transaction. Zetrix provides an HTTP endpoint called TestTransaction, which allows users to simulate the full execution of a transaction in a sandboxed environment. This simulation calculates the actual cost based on the transaction’s behavior, ensuring users can set an appropriate fee to avoid failure due to underpayment.

Fee Selection

In a real blockchain environment, transaction fees may need to be adjusted dynamically based on changing network conditions. For instance, if the operational costs of consensus nodes remain constant while network transaction volume increases, the cost per transaction effectively decreases due to dilution. To ensure fair cost distribution and sustainability, a network-wide consensus mechanism is required to recalibrate transaction fees.

Zetrix addresses this by introducing a fee election mechanism, allowing stakeholders to participate in selecting or updating fee schemes. At the blockchain’s inception, a contract account is established specifically for managing fee proposals and selections, enabling transparent and decentralized adjustment of fee parameters through governance.

Contract

The concept of smart contracts was first proposed by Nick Szabo in the 1990s, but at the time, there was no trustworthy execution environment to support real-world applications. With the emergence of Bitcoin, it became evident that blockchain could provide a secure and decentralized platform for smart contract execution. However, Bitcoin’s scripting capabilities are non-Turing complete, limiting its potential for commercial-grade smart contracts.

In contrast, the Zetrix system offers robust support for smart contracts through its BuVM (Blockchain Universal Virtual Machine). BuVM is Turing complete, allowing developers to build complex, business-level smart contracts using a platform-supported language. These contracts are stored on-chain, replicated across all nodes, and executed deterministically when triggered via a transaction. The results are then written back to the blockchain, with data consistency guaranteed by Zetrix’s underlying consensus mechanism, enabling secure, decentralized, and scalable execution of programmable logic.

Contract Creation

In Zetrix, a smart contract is bound to the account at the time of its creation. During the account creation operation, the contract code is defined and becomes an immutable part of that account. Once deployed, the contract code cannot be modified, ensuring immutability, security, and predictable behavior of smart contracts on the blockchain.

Contract Execution

In Zetrix, when a contract account receives assets transferred from another account, it automatically triggers the execution of the contract. This mechanism enables event-driven interactions, allowing the contract to process logic such as validating input, updating state, or initiating further operations in response to the incoming transfer.

Contract Template

In the Zetrix system, a contract is treated as an attribute of an account, specifically defined in the contract field of the Account structure. This design links the smart contract directly to the account, enabling seamless execution and management of contract logic as part of the account’s core functionality.

Contract Debugging

In Zetrix’s smart contract module, a sandbox environment is provided for secure debugging, allowing developers to test contract logic without affecting the actual blockchain state or contract data. This is achieved through the HTTP interface callContract, which supports debugging either by invoking an existing on-chain contract or by uploading new contract code with input parameters. Transactions executed via callContract are simulated only, so no transaction fees are incurred during the debugging process, enabling safe and cost-effective development.

Pedersen commitment

In Zetrix, Pedersen commitments are used to blind transaction amounts, ensuring both confidentiality and verifiability. The commitment is expressed as:

C = rG + vH

• r is a large random number called the blinding factor, similar in function to a private key.

• v is the transaction amount.

• G and H are independent elliptic curve generators.

• C is the resulting commitment, which hides the value v while still allowing for validation.

This method leverages the discrete logarithm problem, meaning it's computationally infeasible to derive v or r from C, G, and H—ensuring one-way encryption.

The use of a unique blinding factor r for each transaction ensures privacy and enables additive homomorphism, meaning commitments can be added together without revealing individual values. This is crucial for verifying balances and sums in confidential transactions without compromising on-chain transparency.

Range Proof

In Zetrix, to ensure the integrity of confidential transactions, each transaction output must be accompanied by a range proof. This cryptographic proof ensures that the output value is non-negative and within a valid range, typically greater than zero.

Without range proofs, a malicious user could construct an invalid transaction—for example, with an input of 10 and outputs of 20 and -10. Mathematically, the totals would balance, but the negative value would effectively create value out of nothing, compromising the system.

A range proof is a type of short zero-knowledge proof that allows validators to confirm an output is within a valid range without revealing its actual value. This preserves privacy while guaranteeing correctness, ensuring that no hidden inflation or fraud occurs through negative outputs.

Address anonymity

Zetrix employs a one-time key mechanism to protect the privacy of transaction recipients, ensuring that addresses are non-linkable and confidential. When a sender initiates a transaction, they use the receiver’s public key (R2) to compute a unique one-time public key, effectively creating a temporary address for that specific transaction. The funds are then sent to this one-time address, not the original public key.

The one-time public key is calculated as:

pubkey = R2 + Hash(Hash(tx), Hash(r2 * r1 * G), 0) * G

Where:

• R2: the receiver’s original public key, which ties to their identity.

• Hash(tx): ensures uniqueness of the address across the network.

• Hash(r2 * r1 * G): uses ECDH (Elliptic Curve Diffie-Hellman) key exchange for secure blinding, ensuring only the receiver can compute this component.

• 0: acts as a transaction index or identifier, ensuring the address is unique per transaction.

The receiver uses their private key to scan the network and decrypt transactions addressed to them. Other nodes, however, cannot correlate multiple one-time addresses to the same receiver, achieving non-linkability and enhancing transaction-level privacy within the Zetrix network.

Equality equilibrium

In Zetrix, privacy transactions are implemented using a smart contract-based simulation of the UTXO model, allowing for confidential asset transfers while preserving blockchain transparency and integrity.

To verify the legitimacy of a transaction, nodes check two key properties:

1. Equality Balance: Ensures that the total input equals total output, preventing unauthorized creation or loss of funds.

2. Range Proof: Validates that all output values are non-negative, avoiding hidden inflation via negative outputs.

Zetrix uses Pedersen Commitments to blind transaction amounts. To validate equality balance while keeping amounts hidden, it applies the concept of blinding factor difference, calculated as:

excess = r₁ + r₂ − (r₃ + r₄)

Where:

• r₁, r₂: blinding factors for inputs

• r₃, r₄: blinding factors for outputs

The sender signs the excess with a message m, creating:

sig = Sign(excess, m)

Then, compute the excess commitment:

Excess = P₁ + P₂ − (P₃ + P₄) (P₁–P₄ are Pedersen commitments of inputs and outputs)

The network verifies the signature using:

Verify(Excess, sig, m)

If valid, it confirms the inputs and outputs are balanced, ensuring the privacy transaction is legitimate without revealing the actual amounts involved.