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.

Last updated