NXT Developer Riker NXT blockchain Q&A

Source: NXT Forum

Question 1:Transactions — http://nxtwiki.org/wiki/How_Tx_Processing_Works is nice, but are the types, subtypes, constraints etc documented anywhere? the bc appears to me as an event sourcing scheme, but are there any operating data models on top that’s documented? What does an actual tx look like?

Riker: Types, subtypes and constraints are part of the internal implementation of the core. I don’t think we have documentation for this but as you said any Java programmer looking at the server code or JavaScript developer looking at the client code should be able to figure this out quickly.
A transaction is composed of a generic data structure representing the inner working of blockchain including id, signature etc. in addition it may have subtype specific attachment which includes additional data specific to this transaction type and a collection of appendices which include optional data about the transaction such as message to self and prunable parts, public key announcement and more.

Question 2: Validation. Before the block is stamped, how are tx validated and by who? As far as I understand, one node get’s the honour and rewards for the stamping (concluding a block), but how are the tx validated and by whom? In what way? This is more a process, so maybe it’s documented in non-code?

Riker: Validation is performed several times (1) when a node receives the unconfirmed transaction from a client wallet (2) when a node receives unconfirmed transaction from another node (3) when a forger forges a block (4) when another node validates a new block received from a forger (5) phasing requires more validations

Question 3: I assume nodes can be corrupted, so that validation could be void if an attacker wants to screw up or double spend?

Riker: The assumption is that malicious nodes are always trying to exploit the blockchain at all levels, nodes can send illegal transactions, forge illegal blocks, fill blocks with useless data to delay other users’ transactions and many other tricks. Therefore nodes never trust each other, they always re-validate the information they receive and reject it if it violates the rules. As long as more than 50% of the stake is held by honest nodes, double spend and other cheating attempts should be rejected.

Question 4: Does the forger and all other nodes actually go through the events all the way from the genesis / last validated snapshot in order to validate all the validity of all tx?

Riker: The forger has to have an up to date blockchain which it already validated when downloading or building the blockchain. This means that it has the most current state of the blockchain so the new transactions are only validated against the current state.

Question 5: This means initial validation is left to a node (which could be corrupted) and later validations occur post block forging, implying inconsistencies in a forged block or two could be detected a few heights further on?

Riker: At the topmost level of the blockchain there are always inconsistencies, we call them forks, not necessarily because of bad actors. A node in China will see a block produced in China much faster than a node in the US will see it, and perhaps the node in the US already received a valid block from Germany. The blockchain has rules to resolve these forks. In NXT the idea is that the fork in which more forging balance was invested is the stronger fork and eventually all nodes will switch to this fork. Again any specific node can be a bad actor but as long as most of the nodes are honest, double spent attempts should be rejected and only blocks and transactions which comply with the protocol rules should be accepted into the blockchain.

Question 6: “the current state”. How does state work precisely? Does the node keep state of all accounts and ledger(s) at all time? i.e the node know the NXT balance on account X is Y, holds this state and updates the state if a new block contains any NXT-amount change on that account specifically? So if we had 5 million accounts, the server will keep the “inventory” so to speak for every single one in memory?

Riker: Yes, each node keeps the balances of all accounts and a lot more information in it’s database. We call these database tables “derived tables” since their information can always be rebuilt from blockchain data which only includes transactions and blocks. Unlike Bitcoin throw away addresses, accounts in NXT are expensive since each node has to keep track of them. We do have an optimization to remove empty accounts and only save their public keys which is only 32 bytes per account. Intuitively derived tables are somewhat like the Bitcoin UTXO.

Question 7: OK, so for my node to validate a transaction from another account, does it have to compute the balance from a snapshot in the event stack or will it track the balance all the way from genesis? again, just “comparing” to event sourcing

Riker: State is tracked all the way from Genesis to guarantee that the state is valid. You can trust nobody but the blockchain itself.

Question 8: So, just to get this straight: If my node receives a forged block containing 250 tx involving 400 accounts, it will actually track the let’s say NXT balance for those 400 accounts from genesis and up?

Riker: There are currently just over 50,000 active accounts, each node tracks the balance of each one of them. And not only the NXT balance, also the balance in each asset and currency and several other entities