Terminology

Zetrix Terminology

Account Nonce Value

Nonce is an abbreviation of Number Used Once or Number Once. A nonce, in information technology, is a number generated for a specific use, such as session authentication. Typically, a nonce is some value that varies with time, although a very large random number is sometimes used. In general usage, nonce means “for the immediate occasion” or “for now.” In the case of Blockchain Proof of Work scenarios,the hash value, found by a Miner, matching the network’s Difficulty thus proving the Block Validity is called Nonce as well. In Zetrix, Account Nonce Value is used to identify the order in which the transaction is executed when the user submits the transaction.

Keypair

In the Zetrix project, the keypair is the interface that generates the public key, private key, address, and signature. Only the ED25519 signature algorithm is supported during the signing process.

Raw Private Key

A Raw Private Key is a byte array obtained by a random algorithm. A Raw Private Key is a prerequisite for generating a private key.

Raw Public Key

A Raw Public Key is a byte array generated by processing the raw private key with the ED25519 algorithm. A Raw Public Key is a prerequisite for generating a public key.

Private Key

A private key is a piece of code generated in asymmetric-key encryption process by the algorithm. It is known only to the owner, and is paired with a public key to set off algorithms for text encryption and decryption. The private key is a prerequisite for generating the public key and the address, and is also the basic element for completing the signature. The private key cannot be changed after it is generated. Once it is lost, it cannot be retrieved, so it needs to be kept safely.

Public Key

A string of characters derived from a private key that can be made public. The public key can be used to verify the authenticity of any signature created using the private key. It does not expose the private key when transmitted between networks. It is also a necessary condition for generating an address.

Address

An address is a place where cryptocurrency can be sent to and from, in the form of a string of letters and numbers. A cryptocurrency address can be shared publicly in the form of text or QR code to those who want to send you cryptocurrency. Similar to real-life addresses, contacts cannot be found without an address, so without addresses transactions cannot be completed.

Signature

A Signature refers to the process of encrypting and confirming transaction data by algorithm and private key and obtaining signature data. The user can verify the integrity and correctness of the transaction data through the signature data.

Transaction

A transaction is the act of exchanging cryptocurrencies on a blockchain. In Zetrix , all operations that modify blockchain data are called transactions, such as issuing assets, transferring assets, sending Gas, creating accounts, setting metadata and setting permissions, etc.

Transaction Blob

A Transaction Blob is a hexadecimal string obtained by serializing a transaction object. Transaction serialization refers to the process of converting the state information of a transaction object into a string that can be stored and transmitted through the ProtoBuf data structure.

Operating Zetrix

Zetrix Operation refers to writing data to or modifying data on Zetrix.

Submitting Transaction

Transaction Submission refers to sending a request to write data to or modify data on Zetrix.

Querying Zetrix

Zetrix Query refers to querying data in the Zetrix.

Account Services

Account Services provide account validity checking and query interfaces.

Asset Services

Asset Services provide asset-related query interfaces.

Contract Services

Contract Services provide a contract-related validity checking and query interfaces.

Transaction Services

Transaction Services provide a build transaction Blob interface, a signature interface, a query and a submit transaction interface.

Block Services

Block Services provide an interface to query the block.

Serializing

Serialization is used in many cases. For example, when we sign a transaction, we can only sign the byte string. In this case, we need to serialize the transaction into a byte string. In addition, we need to store the transaction and serialize it into a byte stream to store it. We chose Google's Protocol Buffer 3 for serialization. Therefore, all of our data structures are defined using Protocol Buffer 3. The advantages of Protocol Buffer 3 are fast at speed, small in size and supportive of multiple languages. We use SerializeAsString to represent the serialization operation of a protocol buffer object.

Account Address

In the asymmetric signature system, there are private and public keys. It works by randomly generating a public-private key pair according to the algorithm. The private key (skey) is kept by the user, and the public key (pkey) is made public. When you sign a signature, signature = sign (skey, message). When you conduct a verification, validate whether Verify (pkey, signature, Message) is true or false. So why do not use pkey as the unique identifier for the user? Because the length of pkey is not fixed. For a certain elliptic curve family algorithm, pkey is generally 64 bytes in length, and the length of pkey in RSA system is several hundred bytes, which is inconvenient for users to view and save. In order to be compatible with a variety of signature algorithms and fixed length, we hash the public key and add some other flag bits to generate the account address. It is a 36-byte string derived from the public key and is the unique identifier of the account.

Block

A block consists of 2 major parts, the block header (LedgerHeader) and the transactions (transaction_envs).

Asset

An asset is a digital certificate issued by an account.

Gas Token

The Gas token is a native token built into Zetrix and is used to pay for network transaction costs and operation and maintenance of the blockchain network. After Zetrix was started, 1 billion Gas were generated when the genesis account was created. In addition to those native assets, each time a new block is generated, a certain amount of Gas assets will be generated to reward the consensus nodes participating in the block packaging. Each time the Gas assets for each block generation and fees paid for the transactions in the block will be evenly distributed to all the consensus nodes packaging the block, and the modulo balance is randomly rewarded to a consensus node. The total amount of block rewards is 500 million. In the initial stage, 8 Gas are rewarded for each block generation. In the future, the number of Gas assets for generating a block will be attenuated by 1/4 every five years. After 360 years, 500 million Gas coins will be fully rewarded.

Account

The account is the main body of Zetrix and is a mapping of legal or natural persons in the real world.

Transaction

By a broad definition, a transaction is a combination of a series of operations to an account.

Operation

The operation is the specific action attached to the transaction, changing the atomic unit of the account. A transaction contains one or more operations.

Creating Account

The account is the main body of the transaction, and all transactions must be initiated through the account. Therefore, you must first create an account before performing other operations. The account creation operation is executed by other existing accounts. The first account is generated when Zetrix is started, and it is also a genesis account.

Issuing Asset

Any account can create its own assets by performing an asset issuance operation.

Transferring Asset

By transferring assets, you can transfer the assets in the source account to the destination address.

Setting Metadata

Metadata is a database of key-value pairs with versions. Each of its key-value pairs has a version number. Whenever this data is modified, the version number is automatically incremented by 1.

Setting Weight

Set the weight of the account owner and signer of the source account.

Setting Threshold

Set the threshold for each operation in the source account. If the weight of an operation in the transaction does not reach the threshold of the operation, the operation will be rejected.

Transaction Cache Queue

After a node in the blockchain network receiving a transaction request, it fist checks the legality of the transaction. If the transaction is legal, the transaction request is broadcast to other nodes and the request is added to the transaction cache queue.

Transaction Packaging

The system relies on a timer to initiate a consensus every 10s to package transactions for generating a new block. When a node packaging transactions, no more than 4M bytes are fetched in order from the head of the transaction cache queue. If there is a situation where the sequence of source account is broken, all the transactions requested by the source account will be skipped from the broken point, and the broken point of the source account will be marked, and the subsequent blocks will not package the transactions in the source account until the broken point is completed. The transactions for the source account will be packaged until the break is completed, or the transactions are deleted from the cache queue as they time out.

P2P

A peer-to-peer networking (P2P) is a distributed application architecture that distributes tasks and workloads between peers. It is a peer-to-peer computing model formed at the application layer as an Ad Hoc network or networking. Participants in this network are both providers of resources, services, and content, as well as recipients of resources, services, and content.

Broadcast and Multicast

When we define the message type, we can divide the message into broadcast messages and unicast messages according to the way the messages are transmitted. Broadcasting is a multi-drop delivery method that delivers a copy of a packet to each destination. Unicasting refers to the delivery of datagrams with only one destination.

In Zetrix P2P network, assuming there are four nodes, a unicast message means that node A receives a message from node B and does not propagate to C and D.

Consensus Node Selection

In order to ensure the stability and growth of the entire blockchain network, Zetrix enables you to select verification nodes. In this way, the discovered evil verification nodes can be excluded from the consensus node group, and the node with higher performance can be elected to join the verification node group.

Transaction Processing

All operations in the same transaction, either all succeed or all fail, which is called the atomicity or transactional nature of the transaction.

Transaction Fee

The user must pay the transaction fees to send the transaction request to cover the cost of depreciation, power, operation and maintenance of the computer equipment in the blockchain network. In Zetrix, transaction fees can be assessed before the transaction, and the assessment does not charge any fees, so that users can reasonably provide transaction costs according to their own circumstances. In addition, the cost standard can also be modified according to actual needs.

Cost Estimation

The basic fee check does not guarantee that the transaction fee paid is sufficient, because the basic fee check does not include the cost of the contract-triggered transaction. Therefore, in order to ensure that the transaction cost is sufficient, the user can first call the fee evaluation interface to evaluate the fee. Zetrix provides an http interface named TestTransaction for users to evaluate transaction fees. The cost assessment will actually execute the transaction in a fully simulated environment and calculate the actual transaction cost based on the execution of the transaction.

Fee Selection

In the real blockchain network, it may be necessary to adjust the transaction costs according to actual conditions. For example, in the case where the operation cost of the consensus node is fixed, the transaction volume of the entire network continues to increase, and the cost per transaction is diluted. At this time, a network-wide consensus mechanism is needed to adjust the transaction fee. Therefore, Zetrix needs to provide a fee election mechanism. When the blockchain is initiated, a contract account to select a fee scheme is created.

Contract

The idea of smart contracts was put forward by Nick Sabo in the 1990s, but because of the lack of a credible execution environment at the time, smart contracts were not applied to the real industry. Since the birth of Bitcoin, people realized that the bottom layer of Bitcoin is inherently capable of providing a credible execution environment for smart contracts, but Bitcoin's support for smart contracts is only at the level of simple scripting, and is not Turing complete, so smart contracts cannot be used in Bitcoin for commercial application.

In Zetrix system, the virtual machine provides platform-level support for the execution of smart contracts. The language of the smart contract is Turing complete, and developers can develop a business-level smart contract using the language provided by the platform. The smart contracts of BuVM are stored on the blockchain and distributed on each node machine. The user triggers the execution of the contract script through the transaction, and writes the result of the execution into the blockchain, and guarantees all the data is consistent through the underlying consensus.

Contract Creation

The contract is determined when the account is created. In the account creation operation, the contract content of the created account is determined. It is not allowed to modify the contract code after the contract is created.

Contract Execution

When a contract account receives assets transferred by other accounts, it will be triggered.

Contract Template

In the Zetrix system, the contract is an attribute of the account, defined in the contract field of Account.

Contract Debugging

In the design of the smart contract module, we provide a sandbox environment for debugging contracts, and the state of the blockchain and contract will not be changed during debugging. The smart contract can be debugged through the HTTP interface callContract. The smart contract can be an existed one on the public chain or contract code uploaded with parameters. The transaction is generated by using the callContract interface, so there is no need to pay the transaction fee.

Pedersen commitment

Pedersen promises to show the input or output of the transaction in the following form: C = rG + vH, r is a large random number, representing the blinding factor, v is the amount, G and H are the generating elements, C is the commitment of the output amount, and the transaction amount is blinded. G and H are two generators of ECC. A plaintext value multiplied by generator is a ciphertext simply encrypted by ECC.

This operation is unidirectional. Ciphertext can be deduced by plaintext and generator, but plaintext cannot be inferred by ciphertext and generator. This problem is called "discrete logarithm problem".

The blinding factor r is a random number chosen by the constructor of the transaction. This random number is equivalent to the private key in the asymmetric encryption algorithm. Only he knows that he can't tell others. The advantage of blinding each transaction amount is to keep "additive homomorphism".

Range Proof

Range proof: for the part of the amount, it needs to prove that the amount is not negative. For example, if someone constructs a malicious transaction, the transaction input is 10, and the transaction output is 20 and - 10, some money will be made out of nothing, and the equation verification is passed. In order to prove that all outputs of the transaction are greater than 0, each output of the transaction is accompanied by a range proof, a short zero knowledge proof, which is used to prove that the output value is greater than 0.

Address anonymity

Zetrix uses a one-time key to hide the address, which guarantees the privacy of the receiver. Its essential idea is that when the sender initiates a transaction, it uses the public key of the receiver to calculate a one-time public key, and then transfers the encrypted currency to the one-time address. The receiver uses its own private key to find the transaction belonging to itself through the decryption algorithm through monitoring the transaction in the network, so as to spend again. However, other nodes in the network cannot confirm that two transactions are sent to the same receiver, which realizes the non linkability of the transaction.

Suppose the original public key of the receiver is R2, and the one-time address after transformation is pubkey = R2 + Hash (Hash (tx), Hash (r2 * r1 * G), 0) * G, where R2 identifies the ownership of the receiver, Hash (tx) makes the receiver's address unique in the whole network, Hash (r2 * r1 * G) uses the ECDH secret key exchange technology to ensure that only the receiver can calculate it, 0 identifies the id of the transaction, and is used with the transaction hash to make the receiving address unique in the whole network.

Equality equilibrium

Zetrix privacy transaction simulates the transaction model based on utxo through smart contract. The blockchain nodes verify the legitimacy of the transaction by verifying the equality balance (i.e. the input and output are equal) and the range proof. Zetrix privacy protection uses the difference between the blinding factors, namely, exits = r1 + r2 - (r3 + r4), and signature sig = Sign (excess, m), Then calculate the difference between the input Pedersen commitment and the output Pedersen commitment. Excess = P1 + P2 - (P3 + P4) and verify the signature verify (Excess, sig, m) to ensure the equality balance.