How Tx Processing Works

From ArdorDocs
Jump to: navigation, search
Other languages:

Transactions

Calculating the balances of each Ardor account require a scan of the entire blockchain. While this might sound inefficient, with the current day network speeds and CPU speeds it is not that big of a computational task. This offloads the work required of the Ardor server and thus allows even low powered mobile devices to be a Ardor node.

The details of a Ardor transaction are as follows:

  1. The sender specifies parameters for the transaction. Types of transactions vary (sending money, creating an alias, transmitting a message, issuing an asset or an order for an asset) but several parameters must be specified for any transaction:
    • the secret passphrase for the sending account
    • a specified fee of the transaction
    • a deadline for the transaction
    • an optional "referenced" transaction
  2. All values for the transaction inputs are checked. For example, mandatory parameters must be specified; fees cannot be less than or equal to zero; a transaction deadline cannot be less than 1 minute into the future.
  3. If no exceptions are thrown as a result of parameter checking:
    1. The public key for the generating account is computed using the supplied secret passphrase
    2. Account information generating account is retrieved, and transaction parameters are further validated:
      • The sending account's balance cannot be zero
      • The sending account's confirmed balance must not be lower than the transaction amount plus the transaction fee
    3. If the sending account has sufficient funds for the transaction:
      1. A new transaction is created, with a type and subtype value set to match the kind of transaction being made (sending money, creating an alias, sending a message, etc.). All specified parameters are included in the Transaction object. A unique transaction ID is generated with the creation of the object
      2. The transaction is signed using the sending account's private key
      3. The encrypted transaction data is placed within a message instructing network peers to process the transaction
      4. The transaction is broadcast to all peers on the network
  4. The server responds with a result code: the transaction ID, if the transaction creation was successful; an error code and error message if any of the parameter checks failed.


Byte Order

The byte order of a send Ardor transaction. Verified: NRS v2.1.0e

Length (bits) Name Data Definition Cumulative Total (bytes)
8 Type Transaction type, eg. payment/assets/marketplace 1
4 TX Version 1 currently, added attachments and appendages 1.5
4 Subtype Transaction subtype, eg. create bid order with asset type 2
32 Timestamp Current Timestamp where the epoch is the Nxt genesis block 6
16 Deadline Deadline in minutes for the transaction to be processed 8
256 Sender Public Key The 256-bit public key of the person sending the tx 40
64 Recipent/Genesis The recipent of the transaction, genesis for txs without recipient, eg. assets 48
64 Amount NQT Amount to send to the recipient, 1 nxt = 100000000 NQT 56
64 Fee NQT Fee amount, typical fee is 1 nxt/10000000 NQT 64
256 Referenced Transaction Full Hash Full hash for transaction to reference, usually left blank 96
512 Signature Signature of this transaction where this field is zero, signature must be generated by the private key of the earlier stated public key 160
32 Flags Flags for position 1 for arbitrary message, position 2 for encrypted message, position 3 for public key announcement, position 4 for encrypted message to self 164
32 EC Block Height Block height of referenced block for economic clustering 168
64 EC Block ID ID of the block referenced above 176


Transaction Confirmations

All Ardor transactions are considered "unconfirmed" until they are included in a valid network block. Newly-created blocks are distributed to the network by the account that creates them, and a transaction that is included in a block is considered to be confirmed once. Since subsequent blocks are added to the existing chain of blocks, each additional block adds one more confirmation to the number of confirmations for a transaction.

Ardor transactions are deemed reliable after 10 confirmations. Up to 720 recent blocks can be "re-organized" by the network in case of problems, so a transaction is considered irreversible after 721 confirmations. Transactions that have been confirmed 1440 times are considered permanent.


Transactions Order within a Block

Each child chain block is limited to 100 transactions, each Ardor block can have up to 10 child chain blocks. Therefore when more than 1000 transactions are ready to be included, the block generator needs to select which transactions to include in the next block.

The selection criteria is as follows:

Phased transactions are processed first, ordered by height (when they were accepted in the blockchain) and then index (for phased transactions accepted at the same height). Only then the regular unconfirmed transactions are processed sorted by fee then by arrival timestamp.

The sort by fee, then arrival timestamp only determines which unconfirmed transactions make it into the block. Within the block, the unconfirmed transactions are sorted by arrival timestamp.