https://nxtforum.org/core-development-discussion/nxt-2-0-design/Core dev Riker calculated splitting nxt into mother- and childchain will allow nxt to scale to 200 Transactions Per Minute while keeping the blockchain at 540 MB instead of 43 GB. Many agree scalability is important but some believe it can be achieved in less intrusive and better ways. Often heard criticism is that nxt is a platform yet Jean Luc makes too many changes and has not respected backwards compatibility and user friendliness enough chasing away users and developers. Instead the core devs should focus less on code cleanness and efficiency and more on retaining and building out existing users & features.
automagically
What is their current TPS?
About the same as Bitcoin if blocks were full, 3 tps.
Currently there are 2 transactions per minute, about 2000 transactions per day
the community has not decided on a distribution method for fnxt yet. the most likely scenario is a 1:1 fnxt to nxt distribution. there have been arguments made that nxt as a childchain will lose at least half its value with unknown consequences for asset issuers and asset holders. asset holders funds are locked in an illiquid market, so they will end up with less fnxt. there are arguments beeing made that this is unfair, as those who used the platform and tried to make it flourish will get less than those who just hold.
there are also people who say nxt as a childchain will die, because the platform will be filled with business childchains and nobody is going to pay the fnxt for the nxt childchain blocks (see bottom for explaination). in that case your current versatile nxt token is lost and you end with a token that is only used for forging
Crypto creator needs to buy (f)nxt to pay for the creation of an asset?
assets are created on childchains. you need to pay with childchain tokens (for example nxt) to issue an asset. fnxt is the forging token on the motherchain. fnxt is used to secure the motherchain and all childchains via PoS. forgers on the motherchain will receive fees for that in fnxt.
while all transaction fees on the childchain are paid in childchain tokens, fees for a block to be included in the motherchain have to be paid in fnxt. those fees will be paid by someone, e.g. a childchain forger or childchain creator (e.g. like a business)
Quote
What is nxt used to pay for?
its the token on the nxt childchain. you can buy assets, buy stuff on the marketplace, write messages etc.
--------------
nxt will remain a token (child)
fnxt will be used ONLY for forging (motherchain) can't be pruned
fnxt can carry 255 TX/block * 1440 = 367,200 TX/day [3 tps]
- 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.
Show Posts
