elective-stereophonic
elective-stereophonic
Nxt 2.0 design singapore
Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Stable Nxt Client: Nxt 1.12.1 Upgrade before block 2870000 is mandatory!

Pages: 1 2 3 [4] 5 6 ... 51

Author Topic: Nxt 2.0 design  (Read 210968 times)

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Nxt 2.0 design
« Reply #60 on: February 09, 2016, 10:24:19 am »

Does the child chain have flexibility?
For example, does a child chain would be flexible enough to implement quantum resistant crypto for its child blocks, or implement smart contracts? Etc etc..
All nodes must run the same code and understand all transaction types. A child chain can be restricted not to support some transactions or features, but cannot add its own features, unless we implement and make such features potentially available to other child chains too.
The "NXT" child chain does not necessarily need to have all features that a child chain can have though. If we implement some restrictive features needed for a particular child chain type, no need to enable those on the NXT child chain too.

Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

Cassius

  • Hero Member
  • *****
  • Karma: +207/-18
  • Offline Offline
  • Posts: 2459
  • Rather be a pirate than join the navy
    • View Profile
Re: Nxt 2.0 design
« Reply #61 on: February 09, 2016, 10:29:32 am »

So Nxt itself will have to pay fNxt in order to operate. All regular txs on the Nxt chain are paid in NXT. Who pays the fNXT?
Logged
I head up content for BitScan, crypto business hub.

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Nxt 2.0 design
« Reply #62 on: February 09, 2016, 10:35:57 am »

I am still trying to determine what role the native NXT coins role will be...

 - No longer plays a role in forging
 - Child chains are able to use all the features of NXT
 - Child chains will move onto centralized exchanges and will have BTC pairings. Furthermore superBTC will be able to trade with child chains.
 - Now has to compete with fNXT. Some view this as doubling the supply of NXT.

It seems clear that fNXT has a role (while i think this might fail at least it has a clear role), but what is NXT's?
It will be same as what NXT is now, minus the ability to forge. It will have the network effect, because this is what all NXT owners will continue to have. Currently a clone can also have all the features of NXT yet doesn't have the same value, a child chain with exactly the same features will be just like a clone, but why would NXT holders migrate to it?

SuperBTC should become a token for a child chain instead of the asset that it is now. As it is pegged to BTC, it is a different economy, with its own risks.

An asset should be possible to trade in NXT, or in SuperBTC, by submitting the ask/bid transaction on the corresponding child chain, unless the asset issuer or the child chain properties do not allow that. It is the transactions that need to belong to a specific child chain, in order to be possible to be able to prune them, and to have their fees in different tokens. But many entities such as assets will be global, since as I explained every node will need to be able to validate every child chain transactions, therefore needs the current state of every child chain. Which exactly objects will be global and which restricted to a child chain remains to be determined.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

allwelder

  • Hero Member
  • *****
  • Karma: +196/-13
  • Offline Offline
  • Posts: 1867
  • NxtChina.org
    • View Profile
    • NxtChina.org
Re: Nxt 2.0 design
« Reply #63 on: February 09, 2016, 10:38:24 am »

fNXT will be pegged with Current NXT with 1:1 always,right?
Logged
NxtChina |Weibo |Twitter Donation welcomed:NXT-APL9-66GU-K8LY-B3JJJ

blackyblack1

  • Hero Member
  • *****
  • Karma: +165/-82
  • Offline Offline
  • Posts: 1764
    • View Profile
Re: Nxt 2.0 design
« Reply #64 on: February 09, 2016, 10:41:06 am »

fNXT will be pegged with Current NXT with 1:1 always,right?
No. Market will decide both ways.
Logged

Cassius

  • Hero Member
  • *****
  • Karma: +207/-18
  • Offline Offline
  • Posts: 2459
  • Rather be a pirate than join the navy
    • View Profile
Re: Nxt 2.0 design
« Reply #65 on: February 09, 2016, 10:45:47 am »

So Nxt itself will have to pay fNxt in order to operate. All regular txs on the Nxt chain are paid in NXT. Who pays the fNXT?

@J-L (or anyone who knows): is this correct?

cassius
10:43 AM Who pays fNXT to secure the NXT chain?

blackyblack
10:43 AM @cassius: I think the idea is to pay fees in NXT and forger will decide if fNXT rate is suitable

cassius
10:43 AM Hm, ok. That's actually pretty good
10:44 So forgers will end up collecting potentially dozens of sets of fees in different currencies

blackyblack
10:44 AM guess so

cassius
10:44 AM The more chains are secured on fNXT, the more lucrative forging will be

Logged
I head up content for BitScan, crypto business hub.

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Nxt 2.0 design
« Reply #66 on: February 09, 2016, 10:48:15 am »

So Nxt itself will have to pay fNxt in order to operate. All regular txs on the Nxt chain are paid in NXT. Who pays the fNXT?
Anyone willing to do it. Unlike forging where we need an algorithm to determine in a random but predictable way who the next forger should be, it doesn't matter who does the bundling of a group of child chain transactions into a ChildchainBlock transaction, because at the end it is a main chain forger (selected by the current forging algorithm, based on fNXT effective balance) who needs to include this ChildchainBlock transaction into a main chain block, and does all their validation again (and all other nodes do that too).

How that will work in practice remains to be designed. I guess similar to how Shufflers work, those willing to do an exchange of fNXT to NXT (because this is what the result is, they pay fNXT they have to the forger, and get NXT from the child chain transactions in return), will run such a process, with some parameters limiting the amounts they want to exchange and the rate willing to accept. The default NRS client should have some basic implementation, maybe not very smart but making sure it does not overload the network (by e.g. everyone trying to create such blocks). It will really be like a trading bot.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

Cassius

  • Hero Member
  • *****
  • Karma: +207/-18
  • Offline Offline
  • Posts: 2459
  • Rather be a pirate than join the navy
    • View Profile
Re: Nxt 2.0 design
« Reply #67 on: February 09, 2016, 10:51:08 am »

Right, so you have regular forgers within the NXT chain, who forge for NXT, and 'meta forgers' who secure the NXT chain on the fNXT chain - also in return for NXT, but this is converted to fNXT at the market rate?
Logged
I head up content for BitScan, crypto business hub.

icoin

  • Newbie
  • *
  • Karma: +2/-0
  • Offline Offline
  • Posts: 9
    • View Profile
Re: Nxt 2.0 design
« Reply #68 on: February 09, 2016, 10:55:19 am »

Does the child chain have flexibility?
For example, does a child chain would be flexible enough to implement quantum resistant crypto for its child blocks, or implement smart contracts? Etc etc..
All nodes must run the same code and understand all transaction types. A child chain can be restricted not to support some transactions or features, but cannot add its own features, unless we implement and make such features potentially available to other child chains too.
The "NXT" child chain does not necessarily need to have all features that a child chain can have though. If we implement some restrictive features needed for a particular child chain type, no need to enable those on the NXT child chain too.
What can be done to allow flexibility?
Since, one child chain might want to implement a feature that other child/main chain does not need, and all features cannot be implemented on main chain, hence, without flexibility, system cannot scale.
Logged

abctc

  • Hero Member
  • *****
  • Karma: +148/-13
  • Offline Offline
  • Posts: 1396
    • View Profile
Re: Nxt 2.0 design
« Reply #69 on: February 09, 2016, 11:14:13 am »

Right, so you have regular forgers within the NXT chain, who forge for NXT, and 'meta forgers' who secure the NXT chain on the fNXT chain ..
- I think it is vice versa: "you have regular forgers who forge fNXT chain for fNXT tokens, and 'subsidiary bundlers' who bundling a blocks of child chain for the child tokens." 
And IMHO it is too complicated to be practical.
Logged
Welcome to the Nxt generation of crypto!   Magis quam Moneta (More than a Coin)
"Do not worry, it is an attack" (c) Jean-Luc

Jetboy

  • Jr. Member
  • **
  • Karma: +19/-2
  • Offline Offline
  • Posts: 58
    • View Profile
Re: Nxt 2.0 design
« Reply #70 on: February 09, 2016, 11:18:54 am »

Q: Have you considered cross chaining? Since there is a mother chain for forgning, will there be a bridge chain as well?

A: What does that mean?

Concrete example: Could a coloured coin move from child A to child B?

I'm not saying this is important or useful at the launch of 2.0, but maybe something to consider while writing the new implementation?

Quote
Q: I assume some children will be public while others will be permissioned.

A: The opposite of public is private. No, there can be no private (in the sense of not publicly readable) chains.

Is this contraint only due to the fact that forgers must read the full content of the child's transaction?

If it's "impossible", could we introduce another method for allowing private (in the sense of unreadable data for outsiders) chains? This could mean a world of difference to a lot of potential business users.

Overall my point is that the more modular and flexible NXT is, the higher the chance for greater adoption. If we are to compete against a world machine, then at least we must see to it that NXT's comparable limitations translates to ease of use and flexibility within the boundries. Parties who want to foster a baby should have a maximum of choice to make something that fits them without having to rewrite half the software and not be able to commit blocks for validation to the mother.
« Last Edit: February 09, 2016, 11:22:43 am by Jetboy »
Logged

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Nxt 2.0 design
« Reply #71 on: February 09, 2016, 11:19:55 am »

Right, so you have regular forgers within the NXT chain, who forge for NXT, and 'meta forgers' who secure the NXT chain on the fNXT chain - also in return for NXT, but this is converted to fNXT at the market rate?
To avoid confusion, I wouldn't call those who create ChildcoinBlocks forgers. They are the ones who receive NXT for what they do, the real forgers receive the fNXT.

It could be that only forgers are allowed to create ChildcoinBlocks, but then we are forcing them to accept each of the child chain tokens instead of fNXT. They may not want that, and if they don't, the child chain should not stop, as someone else may be willing to do the conversion, either for business reasons (to keep the chain running), or because he finds the current market rate good and wants to do the trade.

We need the level of indirection provided by creation of such ChildcoinBlocks in order to be able to do pruning. After pruning, what remains from all child chain transaction is just a hash. There is no record left that the ChildcoinBlock creator received the child tokens collected as fees, and what their amount was. But there is a permanent record left that the forger received the fNXT, which is what matters, to be able to re-create all forgers' effective balances from scratch when downloading the blockchain and verify that they legitimately forged all blocks. If they did, it is assumed that all other, now pruned, transactions on the child chains were valid at the time they were processed, and the current final state for all chains is valid, even if the detailed history leading to it is missing.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

Cassius

  • Hero Member
  • *****
  • Karma: +207/-18
  • Offline Offline
  • Posts: 2459
  • Rather be a pirate than join the navy
    • View Profile
Re: Nxt 2.0 design
« Reply #72 on: February 09, 2016, 11:30:33 am »

Right, so you have regular forgers within the NXT chain, who forge for NXT, and 'meta forgers' who secure the NXT chain on the fNXT chain - also in return for NXT, but this is converted to fNXT at the market rate?
To avoid confusion, I wouldn't call those who create ChildcoinBlocks forgers. They are the ones who receive NXT for what they do, the real forgers receive the fNXT.

It could be that only forgers are allowed to create ChildcoinBlocks, but then we are forcing them to accept each of the child chain tokens instead of fNXT. They may not want that, and if they don't, the child chain should not stop, as someone else may be willing to do the conversion, either for business reasons (to keep the chain running), or because he finds the current market rate good and wants to do the trade.

We need the level of indirection provided by creation of such ChildcoinBlocks in order to be able to do pruning. After pruning, what remains from all child chain transaction is just a hash. There is no record left that the ChildcoinBlock creator received the child tokens collected as fees, and what their amount was. But there is a permanent record left that the forger received the fNXT, which is what matters, to be able to re-create all forgers' effective balances from scratch when downloading the blockchain and verify that they legitimately forged all blocks. If they did, it is assumed that all other, now pruned, transactions on the child chains were valid at the time they were processed, and the current final state for all chains is valid, even if the detailed history leading to it is missing.

Ok, so the ChildcoinBlocks forgers middlemen are effectively the ones who exchange NXT for fNXT and bundle txs?
This has to be dealt with carefully. It cannot be centralised (e.g. on the child chain creator) or risk there not being a market for NXT<>fNXT.
Logged
I head up content for BitScan, crypto business hub.

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Nxt 2.0 design
« Reply #73 on: February 09, 2016, 11:34:43 am »

Concrete example: Could a coloured coin move from child A to child B?
If you are talking about assets, such objects will really be global. Whether a specific asset is hidden or not accessible on some child chain, and if such restriction is permanent or can be changed, those are details that can be decided later.

Quote
Quote
Q: I assume some children will be public while others will be permissioned.

A: The opposite of public is private. No, there can be no private (in the sense of not publicly readable) chains.

Is this contraint only due to the fact that forgers must read the full content of the child's transaction?

If it's "impossible", could we introduce another method for allowing private (in the sense of unreadable data for outsiders) chains? This could mean a world of difference to a lot of potential business users.
Not just forgers, absolutely everyone. Forgers don't have any special role in validating transactions, they only decide which transactions to include. This is fundamental to how Nxt works.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Nxt 2.0 design
« Reply #74 on: February 09, 2016, 11:41:27 am »

Ok, so the ChildcoinBlocks forgers middlemen are effectively the ones who exchange NXT for fNXT and bundle txs?
This has to be dealt with carefully. It cannot be centralised (e.g. on the child chain creator) or risk there not being a market for NXT<>fNXT.
I think by default forgers should also act as such middlemen, at least for NXT/fNXT processing, with some configuration to also enable that for other child chains or disable even for NXT.
The child chain creator must not have any special powers, I agree, because there is always a risk that their account may be compromised, this should not break the child chain in any way.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

Cassius

  • Hero Member
  • *****
  • Karma: +207/-18
  • Offline Offline
  • Posts: 2459
  • Rather be a pirate than join the navy
    • View Profile
Re: Nxt 2.0 design
« Reply #75 on: February 09, 2016, 11:46:50 am »

Ok, so the ChildcoinBlocks forgers middlemen are effectively the ones who exchange NXT for fNXT and bundle txs?
This has to be dealt with carefully. It cannot be centralised (e.g. on the child chain creator) or risk there not being a market for NXT<>fNXT.
I think by default forgers should also act as such middlemen, at least for NXT/fNXT processing, with some configuration to also enable that for other child chains or disable even for NXT.
The child chain creator must not have any special powers, I agree, because there is always a risk that their account may be compromised, this should not break the child chain in any way.

Yes, that would make sense. I feel that the original NXT should have a privileged position, at least to start with. However, it would be wrong to force forgers to accept the Rimbit-childchain-coins. Naturally many forgers would immediately dump child coins for NXT or BTC or fiat at market rates, but that doesn't matter.
Logged
I head up content for BitScan, crypto business hub.

Jetboy

  • Jr. Member
  • **
  • Karma: +19/-2
  • Offline Offline
  • Posts: 58
    • View Profile
Re: Nxt 2.0 design
« Reply #76 on: February 09, 2016, 11:52:56 am »

Q: Is this contraint only due to the fact that forgers must read the full content of the child's transaction?

A: Not just forgers, absolutely everyone. Forgers don't have any special role in validating transactions, they only decide which transactions to include. This is fundamental to how Nxt works.

Then excuse my unfamiliarity with the system, but is it so that only peers in the child chain will validate and then forgers trust those validations?

The problem I seek to solve is the one of permissioned chains where the parties can exchange data without revealing the specifics (or payload if you want) of what is being exchanged. A group of business users could like to have their own thing going and still want to commit (some or all) validated tx to the mother for a variety of non-trust and judicial reasons.
Logged

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Nxt 2.0 design
« Reply #77 on: February 09, 2016, 12:27:50 pm »

There is no trust involved, this is why everyone needs to validate all transactions. First, when a new unconfirmed transaction is received by a node, it validates it and only then keeps it in its memory pool and forwards it to others. When a forging account running on that node reaches its time to generate a block, it goes through all unconfirmed transactions in its memory pool (already validated), selects as many of them as possible to fit into a block (by default making sure to maximize the fees it will receive), creates the block and sends it to some of its peers. Each node that receives a new block goes through all transactions in it and validates all, and accepts the block only if all transactions are valid, and only then propagates the block further. Subject to rules on selecting the best fork, and all other details about forging. But no-one blindly trusts the forgers, or any other node from which a block or a transaction is received.

If only a few nodes have access to the data in some transactions, an attacker can send an invalid transaction (data not matching the hash for example) to the whole network, and nodes that don't have access have to accept it as they cannot know whether it matches or not. Nodes that do have access to the data will never accept it. But as they are a minority, the blockchain fork forged by the rest of the network will grow faster, and on that fork the invalid transaction will be included. That minority of nodes that do know that the transaction is invalid will never switch to that fork, even though it is the winning one. As a result, the network will fork permanently.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

petko

  • Full Member
  • ***
  • Karma: +24/-0
  • Offline Offline
  • Posts: 100
    • View Profile
    • My blog
Re: Nxt 2.0 design
« Reply #78 on: February 09, 2016, 12:36:40 pm »

I see an opportunity for simple payment verification of payments in the child chains. It's pretty much similar to SPV in Bitcoin with the difference that the POW is substituted with fNXT POS.

The verifier has the whole fNXT chain processed, and the SPV proof is the child block that contained the respective transaction (if the transactions were organized in Merkle tree, the Merkle path would have been enough). So having the child (NXT) block, the verifier checks that the block has indeed a corresponding ChildcoinBlocks transaction in the fNXT chain, and can (similarly to Bitcoin) safely assume that the child payment was correctly verified by the full nodes.

With this, the SPV client software doesn't need to download the whole child chain state - only to process the fNXT chain. (Yeah, JLP just explained how important it is everyone to run full node, but anyways we cannot prevent the development of alternative clients, and SPV clients are essential for the Bitcoin adoption IMO)

Another application is a two-way peg similar to the one proposed by the blockstream guys - https://blockstream.com/sidechains.pdf
In fact, since every node processes the fNXT chain, converting fNXT to child tokens is pretty strait-forward - a transaction that specifies the amount and to which child chain are the tokens converted.
The SPV proof comes in use for the opposite conversion: in order to claim the fNXT tokens, the converter includes in the fNXT transaction an SPV proof that the child tokens were locked at least 720 blocks ago.
Of course the problem is the fNXT blockchain bloating. Even with Merkle path, the size of the NXT to fNXT conversion transaction would be log(size_of_the_sidechain_block). And it must be stored forever in the fNXT chain.

Edit: there might be a more economical approach to NXT->fNXT conversion - instead of providing a proof for the lock, the converter can directly lock the child tokens with a transaction in fNXT chain. But have to think further about how is this possible... maybe I'm wrong from the very beginning.
« Last Edit: February 09, 2016, 12:49:16 pm by petko »
Logged

Ludom

  • Hero Member
  • *****
  • Karma: +197/-15
  • Offline Offline
  • Posts: 1733
    • View Profile
    • Plaisir & Valeur d'histoire
Re: Nxt 2.0 design
« Reply #79 on: February 09, 2016, 01:03:31 pm »

I'm very enthusiast about this Nxt 2.0

Edit : forget my questions, I don't understand very well the proposition.

I have some questions:
- On the childchain "Nxt", who pays the fees for the motherchain? Should we wait on free willing of the forgers of the childchain "Nxt". If it's so, some forger will pay and other will not.
Do you think to propose a tool to make pay collectively the fees?

For sure, the project is revolutionary. I see how the motherchain will be fully decentralised, I see how an organisation/business can launch a childchain and take care on the fees (centralised system). But I don't understand how to create a fully decentralised childchain if we have to pay the fees to the motherchain.
It's possible to have childchains without paying fees to the motherchain?

I don't worry about the price of the NXT. It'll be switched between two new tokens :
- MILK (motherchain token)
- NXT  token (childchain Nxt with the established economic activity token)

With our MILK we'll be allowed to forge for all the childchains (and be rewarded with the fees)
With our NXT token we continue to forge for the Nxt fees and we continue to use it to buy assets and things.

But is it possible to create two tokens for the mother blockchain ? One token for the forging power and one token to pay the fees. I think it could be a good feature. It's like the difference between the motor and the fuel.
« Last Edit: February 09, 2016, 01:33:40 pm by Ludom »
Logged
Support us to publish "The first book about Nxt"
Pages: 1 2 3 [4] 5 6 ... 51
 

elective-stereophonic
elective-stereophonic
assembly
assembly