Structure

Below is the structure of a transaction on AIN blockchain. It largely contains 2 types of data: input from the creator and derived information.

Input from the transaction creator are:

• nonce: A numeric value added by the transaction creator to get a unique transaction hash. It strictly numbers transactions to distinguish and order them. Negative nonce value means it's not a strictly ordered nonce, i.e., -2 means loosely ordered nonce and -1 means unordered nonce.

• timestamp: The unix time of transaction creation. Used only in transactions that are not strictly numbered with nonces.

• operation: Specifies actual state-updating request. operation can be either:

  • a single-operation with:

    • type: type of operation ("SET_VALUE" | "INC_VALUE" | "DEC_VALUE" | "SET_RULE" | "SET_OWNER" | "SET_FUNCTION")

    • ref: path in the state tree to the value/rule/function hash

    • value: new value/rule/function hash to be set

  • a multi-operation with:

    • type = "SET"

    • op_list: List of single operations.

      • [ {type, ref, value}, {type, ref, value}, ..., {type, ref, value} ]

• parent_tx_hash: Identifier of parent transaction for nested transaction.

Derived data:

• hash: The hash of the transaction which uniquely identifies the transaction.

• address: Public key of the transaction creator.

• signature: The signature of the transaction that's used to validate the sender of the transaction. We use ECDSA and secp256k1 constants to define the elliptic curve.

When a transaction is received through a JSON RPC call, it will have 2 params. The first parameter will be the signature of the transaction by the {address}, and the second parameter will be the the transaction data object, which was used for signing. The transaction data object's properties include: nonce or timestamp, operation, and optionally, parent_tx_hash. A transaction's hash can be obtained by hashing the serialized the transaction object.