Nxt NRS has been successfully hard forked and updated to NRS 1.7.5, with new amazing core features added, such as stable 1 minute transaction times, Singleton Assets, Coin Shuffling, Account Control for phased transactions, and Data Cloud. Everything is running stable and smoothly, and the Nxt core developers have started brainstorming Nxt NRS 2.0.
2.0 is mainly about scalability. The idea is to spawn side-chains from the main blockchain.
Lead developer Jean-Luc writes:
We have been brainstorming the Nxt 2.0 design for some time now, and here is our current proposal. This is a high level summary, and many details are not yet known, more specific design decisions will be made as the development moves along. What we propose is a significant architectural change, not just a bundle of features. And it will take us some time to get there.
– A new main chain will be created, on which NXT becomes a token used for forging only, “forgingNXT”. The current NXT ecosystem will become a child chain, preserving all features and holdings except the ability to forge. At the hard fork block, each NXT owner will have his NXT converted to both tokens in 1:1 ratio, and all other holdings migrated to the NXT child chain.
– It will always be possible to exchange NXT to fNXT, so small stakeholders not interested in forging may decide to sell their fNXT to large stakeholders running forging nodes. This would lead to some centralization, but also to a higher percentage of the (f)NXT stakeholders forging and thus securing the complete Nxt ecosystem.
– Child chains will all run the same code, but each one can be configured to have only a subset of the all possible features if needed. The NXT child chain will have all possible transaction types enabled.
– Each child chain will have its own native token/currency, in which payment transactions are denominated, asset ask/bid orders are placed, digital goods are priced, etc. Child chain transaction fees will also be in the native token.
– All transactions from all chains must be processed by all nodes. All nodes will carry all child chains for the last 1440 blocks at least. Archival nodes can opt to store one or more child chains longer, or indefinitely.
– Transactions on the child chains will be pruned completely after 1440 blocks on nodes not configured to archive them longer. A new node downloading the blockchain from scratch must make the assumption that since the forgers and all nodes that were running the blockchain at the time the prunable data was still there approved those transactions, they must have been valid at that time, even though the data to validate them again is no longer available.
– It must be possible to validate though that the effective fNXT balances of the forgers were indeed those that they claim to be. This is why transactions on the forging chain which change fNXT balances cannot be pruned, and must be kept to a minimum of essential transaction types.
– The child chain “blocks” will be implemented as a prunable attachment of a single (one per block per chain) transaction, of type ChildchainBlock, on the main chain. Anyone can create a ChildchainBlock transaction. However, it is up to the forgers that create blocks on the main chain to decide whether to include this ChildchainBlock transaction in a block. Forgers, just like all nodes, do full validation of all child chain transactions included in a ChildchainBlock, as long as the data has not been pruned yet.
– If there have been no transactions on a chain, there is no need to create a ChildchainBlock transaction for it, unlike the main chain where we continue to have blocks every 60s even if they are empty. We can think about reducing the main chain block times in order to allow for some child chains to have more frequent blocks.
– The forgers will accept fees in fNXT only, with the minimum fee required by the protocol for each transaction type also denominated in fNXT.
– When a ChildchainBlock transaction is included by a forger in the main chain, its creator pays a fee in fNXT to the forger. The amount of this fee is up to the ChildchainBlock creator, but must be at least equal to the total of minimum fees calculated in fNXT for each child chain transaction included. In return, the ChildchainBlock creator receives the fees, in native child chain token, paid by the senders of those child chain transactions.
– The exchange rate of child chain token to fNXT will therefore be determined by market forces. If no-one is willing to include a child chain transaction in a ChildchainBlock, it would mean that the fee offered in native token is not considered equivalent to the required minimum fNXT fee for this particular transaction, and such transaction will expire unconfirmed. If the value of the child chain native token drops to zero, no-one will be willing to create ChildchainBlocks for it, and transaction processing on this childchain will stop.
– Child chains will compete with each other for inclusion into a block, since at the end the forgers will still look at the fee/size ratio for each transaction and will want to maximize their forging profits, subject to main chain block size and transaction numbers limits.
– Before the pruning, each node must verify not only that the hash of the ChildchainBlock transaction matches, but that all transactions of the child chain enclosed within it are valid, i.e. there is no double spending, and all other validations. For that the node needs to know the current balances for all account holdings, on that child chain. To be able to still do pruning, we need a snapshot transaction, which takes a snapshot of the current child chain state only, without any history that led to this state. Then, after this transaction has been accepted in the blockchain for more than 720 blocks, we can assume that it is valid, prune all history for that chain before that snapshot, and discard the previous snapshot.
– The snapshot transaction for each child chain is created at regular intervals, such as 1440 blocks, by the forger of the current block. It will only contain the hash of the snapshot, not the full snapshot data.
– The snapshot data itself does not need to propagate through the network when the snapshot transaction is created. Each node that already is up to date, already has the state of the child chain being snapshotted, so it can generate such a snapshot for itself. It must only validate that the hash the forger calculated for the snapshot indeed matches its own snapshot.
– It is only nodes that are downloading the blockchain from scratch that would need to download the latest complete snapshot, and this is another reason that each node must generate and keep around this snapshot, to be able to serve it to such new nodes. The snapshot download can be in a torrent-like manner, different pieces from multiple nodes.
– Because every up-to-date node needs to validate all current transactions, even though we significantly reduce the long term blockchain bloat problem in terms of disk space used, and bandwith to download the blockchain from scratch, there will still be a bottleneck in terms of CPU for processing data on all chains, and the bandwith of having to receive and process current transactions for all chains. But since nodes don’t need to validate past child chain transactions that have already been pruned, overall downloading the blockchain from scratch should be faster and less CPU intensive.
– The forging chain which all nodes share guarantees security, even for child chains that don’t have many users and have transactions only occassionally. In return, each of the child chains gets the ability to be pruned. Child chains no longer need to keep all their old data going back to genesis in order to be secure, because they do not forge.
– As a first step, we will start with just the forging main chain, and the NXT chain as a single child chain to it, and perhaps a test child chain. Once we have this working, we implement the features required to be able to dynamically create a new child chain, or edit the properties of existing child chains.
–
Originally posted on Nxtforum.org.
Author: Jean-Luc. Join the discussion here:
https://nxtforum.org/core-development-discussion/nxt-2-0-design/