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

Pages: 1 ... 21 22 [23] 24 25 ... 51

Author Topic: Nxt 2.0 design  (Read 220443 times)

blackyblack1

  • Hero Member
  • *****
  • Karma: +165/-82
  • Offline Offline
  • Posts: 1764
    • View Profile
Re: Nxt 2.0 design
« Reply #440 on: February 18, 2016, 08:52:10 am »

The database sizes in the sheet represent database growth during the course of one year.

You can see that in the 2.0 case, the expected transaction database size is tied to the number of blocks on the mother chain since all the child chain transactions are packed into a single prunable attachment of a ChildChainBlock transaction and there is only one such ChildChainBlock transaction per child chain per mother chain block.
The point is, that in the 2.0 design, growing transaction rate from 2 TPM to 200 TPM on the child chain does not change the database size. This is the essence of the scalability improvement since in the 1.x design growing from 2 TPM to 200 TPM will increase the blockchain by a factor of 100.
I think 200 TPM on the child chain requires a higher mother chain TPS rate. Am I wrong?

I'm only considering in the transaction row the direct effect of child chain transactions on the blockchain size.
Additional transactions on the mother chain, for example to exchange NXT and fNXT or perform leasing are counted in the "fNXT related Table Size [MB]" the estimate is that the mother chain will operate at around 1/3 of transaction rate of the existing NXT chain. i.e. about 0.66 TPM.
If the mother chain has higher transaction rate this reduces scalability of course since the mother chain cannot be pruned.
Let me sum up things a bit.
Let's suppose we will increase TPS 100x. We will have:
- Motherchain running at 0,66 TPM.
- NXT childchain running at 200 TPM.
- NXT childchain DB size with near constant size (O(1) memory).
- Motherchain DB size with very low linear growth rate.
- Archival nodes for NXT childchain will have DB growth rate of 44Gb per year without any incentive doing it.

Are my calculations correct? Will the system be able to run with those assumptions?
Logged

lurker10

  • Hero Member
  • *****
  • Karma: +168/-33
  • Offline Offline
  • Posts: 1334
    • View Profile
Re: Nxt 2.0 design
« Reply #441 on: February 18, 2016, 09:17:11 am »

Archival nodes can set up an IP-based subscription. If there is demand for that data, there will be a service to meet the demand.
Logged
Run a node - win a prize! "Lucky node" project jar: NXT-8F28-EDVE-LPPX-HY4E7

Riker

  • Core Dev
  • Hero Member
  • *****
  • Karma: +440/-42
  • Offline Offline
  • Posts: 1796
    • View Profile
Re: Nxt 2.0 design
« Reply #442 on: February 18, 2016, 09:20:47 am »

Ok, since we're nowhere near a consensus I'll take another stab, on the grounds that it's guaranteed to work eventually.

The proposal is a brilliant way to create a scalable blockchain ecosystem. Unfortunately, that's not what we're doing - we're adapting an existing ecosystem, and consequently it suffers from the problem of the city slicker who asks a local farmer for directions after he gets lost in the country and is given the answer, 'If you want to get there, you don't start from here.' Assuming there's no better way of doing it (I'm not technically competent enough to know), getting from A to B is inevitably going to be painful and the chief concern is minimising the pain.

Can we create fNXT tokens that are effectively worthless in the medium term because they are locked to their accounts and cannot initially be transferred? The distribution could be determined by snapshot or average over time, based on past/current/just before the split holdings, whatever, but they couldn't be traded for a couple of years. You can forge with them, lease them, admire their shiny cryptographic beauty, but you can't sell them. Maybe you increase the available/movable balance gradually over time, after an initial cooling off period.

That means:
1) Only people with a long-term interest in the success of the Nxt platform will want them. Who is going to dump assets for NXT if they won't see profits - maybe - for 2 years?
2) No one gets something for nothing. No one is on the wrong side of a de facto expropriation. There's no immediate dilution and any transfer of wealth that does occur is delayed and does so very slowly, hopefully against the backdrop of overall substantial expansion of Nxt.
3) Assetholders, who have supported Nxt for the past 18 months and provided its primary use case with millions of USD of assets and activity, don't get spanked.
4) There's no immediate dump of fNXT, which risks compromising the security of the network through whales accumulating and centralising forging.
5) There's no dump of NXT by disgruntled holders, see 4)

Revenues from forging would be paid in fNXT and could become available balance immediately.

Discuss.

I like the idea in the sense that you make fNXT sort of stock options distributed to companies' employees to strengthen their commitment to the companies' success.
However, I'm afraid that unlike stock options, these fNXT also need to forge and if they are locked we are going to lose a lot of the forging power due to technicalities like people losing interest over the course of a long lockup period.
Logged
NXT Core Dev
Account: NXT-HBFW-X8TE-WXPW-DZFAG
Public Key: D8311651 Key fingerprint: 0560 443B 035C EE08 0EC0  D2DD 275E 94A7 D831 1651

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 #443 on: February 18, 2016, 09:26:13 am »

Perhaps it can be nuanced somewhat. A slow release of available fNXT over time, perhaps. I think it's worth exploring more though?
Logged
I head up content for BitScan, crypto business hub.

Riker

  • Core Dev
  • Hero Member
  • *****
  • Karma: +440/-42
  • Offline Offline
  • Posts: 1796
    • View Profile
Re: Nxt 2.0 design
« Reply #444 on: February 18, 2016, 09:27:05 am »

Let me sum up things a bit.
Let's suppose we will increase TPS 100x. We will have:
- Motherchain running at 0,66 TPM.
- NXT childchain running at 200 TPM.
- NXT childchain DB size with near constant size (O(1) memory).
- Motherchain DB size with very low linear growth rate.
- Archival nodes for NXT childchain will have DB growth rate of 44Gb per year without any incentive doing it.

Are my calculations correct? Will the system be able to run with those assumptions?

Generally yes, I'd like to add that the Motherchain growth depends on the number of the child chains not on the activity of the child chains. The best case scenario is one, or few, very active child chains, this maximizes the throughput of this design.
In case we have many, relatively inactive child chains, this reduces the savings. But note that we don't have empty blocks in the child chains so the worst case scenario are many child chains each one sending exactly a single transaction every minute. In this case the saving from the 2.0 design is very small.
Logged
NXT Core Dev
Account: NXT-HBFW-X8TE-WXPW-DZFAG
Public Key: D8311651 Key fingerprint: 0560 443B 035C EE08 0EC0  D2DD 275E 94A7 D831 1651

Riker

  • Core Dev
  • Hero Member
  • *****
  • Karma: +440/-42
  • Offline Offline
  • Posts: 1796
    • View Profile
Re: Nxt 2.0 design
« Reply #445 on: February 18, 2016, 09:33:28 am »

Perhaps it can be nuanced somewhat. A slow release of available fNXT over time, perhaps. I think it's worth exploring more though?

Frankly, I think we have bigger fish to fry. I say let the market forces distribute the fNXT after a 1:1 initial distribution (I still recommend my KeepAlive property idea for better initial distribution) , I don't see a big risk of centralization since there is no significant advantage to size here.
Logged
NXT Core Dev
Account: NXT-HBFW-X8TE-WXPW-DZFAG
Public Key: D8311651 Key fingerprint: 0560 443B 035C EE08 0EC0  D2DD 275E 94A7 D831 1651

blackyblack1

  • Hero Member
  • *****
  • Karma: +165/-82
  • Offline Offline
  • Posts: 1764
    • View Profile
Re: Nxt 2.0 design
« Reply #446 on: February 18, 2016, 09:34:46 am »

Archival nodes can set up an IP-based subscription. If there is demand for that data, there will be a service to meet the demand.
I think you are underestimating the importance of the archival nodes in the 2.0 design.
Logged

blackyblack1

  • Hero Member
  • *****
  • Karma: +165/-82
  • Offline Offline
  • Posts: 1764
    • View Profile
Re: Nxt 2.0 design
« Reply #447 on: February 18, 2016, 09:35:47 am »

Let me sum up things a bit.
Let's suppose we will increase TPS 100x. We will have:
- Motherchain running at 0,66 TPM.
- NXT childchain running at 200 TPM.
- NXT childchain DB size with near constant size (O(1) memory).
- Motherchain DB size with very low linear growth rate.
- Archival nodes for NXT childchain will have DB growth rate of 44Gb per year without any incentive doing it.

Are my calculations correct? Will the system be able to run with those assumptions?

Generally yes, I'd like to add that the Motherchain growth depends on the number of the child chains not on the activity of the child chains. The best case scenario is one, or few, very active child chains, this maximizes the throughput of this design.
In case we have many, relatively inactive child chains, this reduces the savings. But note that we don't have empty blocks in the child chains so the worst case scenario are many child chains each one sending exactly a single transaction every minute. In this case the saving from the 2.0 design is very small.
Is it correct that NXT balances and assets will be destroyed if not a single archival node will be available during 1440 blocks?
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 #448 on: February 18, 2016, 09:37:26 am »

Perhaps it can be nuanced somewhat. A slow release of available fNXT over time, perhaps. I think it's worth exploring more though?

Frankly, I think we have bigger fish to fry. I say let the market forces distribute the fNXT after a 1:1 initial distribution (I still recommend my KeepAlive property idea for better initial distribution) , I don't see a big risk of centralization since there is no significant advantage to size here.

Centralisation was only one issue. The main question here is the unknown and unknowable effects of creating 1bn new tokens on the existing financial ecosystem, particularly the asset exchange. Surely we cannot just take the line that 'It will probably be ok' and risk razing all that to the ground in the interests of creating a platform that is really well positioned to scale?
Logged
I head up content for BitScan, crypto business hub.

Riker

  • Core Dev
  • Hero Member
  • *****
  • Karma: +440/-42
  • Offline Offline
  • Posts: 1796
    • View Profile
Re: Nxt 2.0 design
« Reply #449 on: February 18, 2016, 09:39:32 am »

Let me sum up things a bit.
Let's suppose we will increase TPS 100x. We will have:
- Motherchain running at 0,66 TPM.
- NXT childchain running at 200 TPM.
- NXT childchain DB size with near constant size (O(1) memory).
- Motherchain DB size with very low linear growth rate.
- Archival nodes for NXT childchain will have DB growth rate of 44Gb per year without any incentive doing it.

Are my calculations correct? Will the system be able to run with those assumptions?

Generally yes, I'd like to add that the Motherchain growth depends on the number of the child chains not on the activity of the child chains. The best case scenario is one, or few, very active child chains, this maximizes the throughput of this design.
In case we have many, relatively inactive child chains, this reduces the savings. But note that we don't have empty blocks in the child chains so the worst case scenario are many child chains each one sending exactly a single transaction every minute. In this case the saving from the 2.0 design is very small.
Is it correct that NXT balances and assets will be destroyed if not a single archival node will be available during 1440 blocks?

The balances won't be destroyed since they'll be part of the latest snapshot each node maintains for each child chain but the transaction sequence which led to these balances on the child chain would be destroyed without archival nodes (or at least this is my current understanding)
Logged
NXT Core Dev
Account: NXT-HBFW-X8TE-WXPW-DZFAG
Public Key: D8311651 Key fingerprint: 0560 443B 035C EE08 0EC0  D2DD 275E 94A7 D831 1651

Windjc

  • Sr. Member
  • ****
  • Karma: +59/-17
  • Offline Offline
  • Posts: 360
    • View Profile
Re: Nxt 2.0 design
« Reply #450 on: February 18, 2016, 09:43:28 am »

Perhaps it can be nuanced somewhat. A slow release of available fNXT over time, perhaps. I think it's worth exploring more though?

Frankly, I think we have bigger fish to fry. I say let the market forces distribute the fNXT after a 1:1 initial distribution (I still recommend my KeepAlive property idea for better initial distribution) , I don't see a big risk of centralization since there is no significant advantage to size here.

Centralisation was only one issue. The main question here is the unknown and unknowable effects of creating 1bn new tokens on the existing financial ecosystem, particularly the asset exchange. Surely we cannot just take the line that 'It will probably be ok' and risk razing all that to the ground in the interests of creating a platform that is really well positioned to scale?

Is this a situation where this discussion is just a farce and the devs have already decided and we are just being dumbasses for thinking otherwise?

After seeing the bitcoin core devs give everyone the middle finger, I'm sensing the same type of attitude in this thread. Can someone tell me if I am right or wrong about this?
Logged

lurker10

  • Hero Member
  • *****
  • Karma: +168/-33
  • Offline Offline
  • Posts: 1334
    • View Profile
Re: Nxt 2.0 design
« Reply #451 on: February 18, 2016, 09:47:55 am »

Can someone tell me if I am right or wrong about this?

You're neither right nor wrong. As Damelon says, you're voicing an opinion. Others have different opinions.
Bitcoin will probably split in two forks this year, Core and Classic, because they can't come to one decision. NXT should do the same (NXT 1.x and NXT 2.0). And that's good, because diversity results in more decentralization. Decentralization is the main purpose of crypto currencies.
Logged
Run a node - win a prize! "Lucky node" project jar: NXT-8F28-EDVE-LPPX-HY4E7

sadface

  • Sr. Member
  • ****
  • Karma: +16/-2
  • Offline Offline
  • Posts: 273
    • View Profile
Re: Nxt 2.0 design
« Reply #452 on: February 18, 2016, 09:57:55 am »

Perhaps it can be nuanced somewhat. A slow release of available fNXT over time, perhaps. I think it's worth exploring more though?

Frankly, I think we have bigger fish to fry. I say let the market forces distribute the fNXT after a 1:1 initial distribution (I still recommend my KeepAlive property idea for better initial distribution) , I don't see a big risk of centralization since there is no significant advantage to size here.

Centralisation was only one issue. The main question here is the unknown and unknowable effects of creating 1bn new tokens on the existing financial ecosystem, particularly the asset exchange. Surely we cannot just take the line that 'It will probably be ok' and risk razing all that to the ground in the interests of creating a platform that is really well positioned to scale?

Is this a situation where this discussion is just a farce and the devs have already decided and we are just being dumbasses for thinking otherwise?

After seeing the bitcoin core devs give everyone the middle finger, I'm sensing the same type of attitude in this thread. Can someone tell me if I am right or wrong about this?

i saw it as such in the beginning, but i think we reached a point where a discussion can begin and concerns are taken seriously. maybe i'm mistaken tho :)
Logged

Riker

  • Core Dev
  • Hero Member
  • *****
  • Karma: +440/-42
  • Offline Offline
  • Posts: 1796
    • View Profile
Re: Nxt 2.0 design
« Reply #453 on: February 18, 2016, 09:59:40 am »

Is this a situation where this discussion is just a farce and the devs have already decided and we are just being dumbasses for thinking otherwise?

After seeing the bitcoin core devs give everyone the middle finger, I'm sensing the same type of attitude in this thread. Can someone tell me if I am right or wrong about this?

You are absolutely wrong. I've never worked in a dev team which consulted so much with its users before implementing a feature.
I can recall dozens of times that we changed a feature based on user feedback.

Come up with a well thought proposal, explain it clearly and we'll consider it.
Logged
NXT Core Dev
Account: NXT-HBFW-X8TE-WXPW-DZFAG
Public Key: D8311651 Key fingerprint: 0560 443B 035C EE08 0EC0  D2DD 275E 94A7 D831 1651

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 #454 on: February 18, 2016, 10:10:44 am »

Is this a situation where this discussion is just a farce and the devs have already decided and we are just being dumbasses for thinking otherwise?

After seeing the bitcoin core devs give everyone the middle finger, I'm sensing the same type of attitude in this thread. Can someone tell me if I am right or wrong about this?

You are absolutely wrong. I've never worked in a dev team which consulted so much with its users before implementing a feature.
I can recall dozens of times that we changed a feature based on user feedback.

Come up with a well thought proposal, explain it clearly and we'll consider it.

That is good to hear because right or wrong this is the #1 issue right now - which I appreciate is weird because this is presented as a tech matter, when fundamentally the impact is on community relationships, particularly with devs.
People have offered various suggestions - snapshots, locked forging balances, and so on. Bear in mind that the people who suggest these, like myself and windjc, don't necessarily have the tech background that you do and take for granted.
So thanks for your willingness to discuss these things and take (really very valid) concerns seriously, but please remember that we can't necessarily give a well-thought through proposal, because we don't know what we don't know.
Logged
I head up content for BitScan, crypto business hub.

cc001

  • Hero Member
  • *****
  • Karma: +68/-4
  • Offline Offline
  • Posts: 829
    • View Profile
Re: Nxt 2.0 design
« Reply #455 on: February 18, 2016, 10:31:07 am »

What about including the value of assets in the initial fNXT distribution, but with a lower weight?

example (parameter are arguable):
2/3 of all fNXT are distributed according to the NXT holding, meaning 666'666'666 fNXT are distributed to the NXT holders with a 1:2/3 rate.
the other 1/3 of fNXT (333'333'333) are distributed to asset holders in the following way:
We take for example the top 20 assets (rated by volume over the last 30 days, or something more sophisticated). For every holding of such an assets, its value in NXT is calculated. All those NXT-values combined are the stack to which the 1/3 fNXT are distributed evenly.

I see a few debatable points with this approach:
1. do we want to include asset holders somehow into the distribution calculation at all?
2. all parameters (2/3, top 20 assets, etc...)
3. which assets are valid for the distribution? top 20 by what value? fake assets?
4. what is the value of one asset in NXT? For example the average value over the last 20 trades?
5. which accounts holding the valid assets are valid? How to exclude issuer accounts? (maybe count only accounts that hold less than 1/3 of the amount of assets?)

Maybe we could generate a temporary distribution list and give the account holders some time to intervene if they think something is not correct?

I think NXT 2.0 is very deep change, so we could also use a fair amount of time to manage and verify the distribution of fNXT (write scripts, lists, check objections of the account holders, etc...)
Logged
cc001 Personal - NXT-8RXS-2SSK-RNF2-HSNL8
NxtReporting.com - The Nxt Asset Exchange Portfolio Manager with Profitability Tracking - Donations are greatly appreciated on NXT-5W4G-GAR6-JHJP-H8ZTW

KarlKarlsson

  • Hero Member
  • *****
  • Karma: +79/-25
  • Offline Offline
  • Posts: 711
    • View Profile
Re: Nxt 2.0 design
« Reply #456 on: February 18, 2016, 10:37:55 am »

What about including the value of assets in the initial fNXT distribution, but with a lower weight?

example (parameter are arguable):
2/3 of all fNXT are distributed according to the NXT holding, meaning 666'666'666 fNXT are distributed to the NXT holders with a 1:2/3 rate.
the other 1/3 of fNXT (333'333'333) are distributed to asset holders in the following way:
We take for example the top 20 assets (rated by volume over the last 30 days, or something more sophisticated). For every holding of such an assets, its value in NXT is calculated. All those NXT-values combined are the stack to which the 1/3 fNXT are distributed evenly.

I see a few debatable points with this approach:
1. do we want to include asset holders somehow into the distribution calculation at all?
2. all parameters (2/3, top 20 assets, etc...)
3. which assets are valid for the distribution? top 20 by what value? fake assets?
4. what is the value of one asset in NXT? For example the average value over the last 20 trades?
5. which accounts holding the valid assets are valid? How to exclude issuer accounts? (maybe count only accounts that hold less than 1/3 of the amount of assets?)

Maybe we could generate a temporary distribution list and give the account holders some time to intervene if they think something is not correct?

I think NXT 2.0 is very deep change, so we could also use a fair amount of time to manage and verify the distribution of fNXT (write scripts, lists, check objections of the account holders, etc...)
I am absolutely against a distribution to asset holders. If you invest in an asset, you trade a certain amount of NXT against a share of the business. As a result, you are no longer invested in Nxt for the amount you invested in the shares. Just because assets are valued in NXT doesn't mean you are having a stake in Nxt itself. The question you have to ask yourself as an asset investor is which way will benefit you more: stay in the asset or sell it for fNXT.

Please note that 95% of my NXT are invested in assets.
Logged
NXTinfo.org - Your toolbox to become an Asset Expert! | Twitter | Facebook | ZapChain

Sebastien256

  • Hero Member
  • *****
  • Karma: +169/-24
  • Offline Offline
  • Posts: 2823
  • ^LOOK UP^ = Nxt community!
    • View Profile
Re: Nxt 2.0 design
« Reply #457 on: February 18, 2016, 10:39:38 am »

Based distribution on assets do not make any sense, imho. Each asset are so different from one another that it is not possible to compare them and find a common ground where everyone will be in agreement. For example, some people may be holding a lot of asset that do not really trade, e.g. NEXTBOND, among others.
Logged
Please drop your ideas concerning Nxt and/or NRS in this topic -> List of feature request for Nxt and/or NRS (with the full list in OP).

lurker10

  • Hero Member
  • *****
  • Karma: +168/-33
  • Offline Offline
  • Posts: 1334
    • View Profile
Re: Nxt 2.0 design
« Reply #458 on: February 18, 2016, 10:44:12 am »

I am absolutely against a distribution to asset holders. If you invest in an asset, you trade a certain amount of NXT against a share of the business. As a result, you are no longer invested in Nxt for the amount you invested in the shares. Just because assets are valued in NXT doesn't mean you are having a stake in Nxt itself. The question you have to ask yourself as an asset investor is which way will benefit you more: stay in the asset or sell it for fNXT.

Please note that 95% of my NXT are invested in assets.

+1440

Asset holders get profits from assets, why should they be entitled to fNXT if they are not interested in supporting NXT by holding NXT or forging? Investing in assets is supporting the business they invest in, support for NXT is secondary and arguable, because most businesses at AE dump NXT to BTC or fiat to operate, this is downward pressure on the price. Yes, AE is important, but giving fNXT to asset holders means double rewarding asset holders, why?
Logged
Run a node - win a prize! "Lucky node" project jar: NXT-8F28-EDVE-LPPX-HY4E7

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 #459 on: February 18, 2016, 10:52:38 am »

Assetholders have opted to receive income based on whatever their assets do (could be BTC, USD, NXT, or camel milk). Also some assets hold substantial quantities of NXT; SuperNET I think has ~40m, LQD ~10m.
That's not really the issue. The issue is the risk of crashing the AE as an unintended consequence of the creation of fNXT, beating up the guys who have pretty much driven Nxt adoption thus far.
Logged
I head up content for BitScan, crypto business hub.
Pages: 1 ... 21 22 [23] 24 25 ... 51
 

elective-stereophonic
elective-stereophonic
assembly
assembly