How Tx Processing Works

From Nxt Wiki
Jump to: navigation, search
This page contains changes which are not marked for translation.

Other languages:
Deutsch • ‎English • ‎español • ‎français • ‎italiano • ‎Nederlands • ‎português do Brasil • ‎русский • ‎українська


Calculating the balances of each NXT 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 NXT server and thus allows even low powered mobile devices to be a NXT node.

The details of a NXT 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 NXT transaction. Verified: NRS v1.3.2

Length (bits) Name Data Definition Cumulative Total (bytes)
8 Type Transaction type, eg. payment/assets/marketplace 1
4 TX Version 0 on genesis, 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

Source: Alex Jones

Transaction Confirmations

All Nxt 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.

Nxt 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.