Nxt Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Nxt Client 1.11.10 - NEW RELEASE: Ardor 2.0.5e TestNet - The Ignis ICO is over!! Ardor genesis snapshots will happen at Nxt block 1,630,000 (expected for 25th December)

Pages: [1] 2 3  All

Author Topic: Nxt Energy and Cost Efficiency paper update.  (Read 3960 times)

mczarnek

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 898
    • View Profile
    • Nxt Place - Craigslist for Nxt
  • Karma: +68/-4

Ok, we've updated the energy and cost efficiency analysis paper.  I think the number of forgers forging for the network is a more solid number.

Please check it out here:
https://docs.google.com/document/d/1J8uhdshu9epGRrQHBaloGc4itdvuAHZDAUtNDjOhz-8/edit?usp=sharing

I'd love to hear comments before we publish it. As far as I'm concerned should be ready to publish unless I hear otherwise. Thank you!
NXT Organization: Tech
Donations greatly appreciated: NXT-DWVJ-G89C-RHNL-6QW6Q

TeamWealth

  • Full Member
  • ***
  • Offline Offline
  • Posts: 217
    • View Profile
  • Karma: +11/-1

Great paper, I dont see any glaring mistakes in the math or anything along those lines. Highlights a huge advantage of NXT pretty well :)
NXT: NXT-V93N-SYX2-2CNW-5TF9Y

chanc3r

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1019
  • NXTInspect
    • View Profile
  • Karma: +124/-50

Thanks for posting the update on this important topic.
Been travelling a lot so not got to it yet - I will read in the next day or so.
Ian
NXT: 29996814460165 (NXT-JTA7-B2QR-8BFC-2V222)
@imrimr @NXTinspect

EvilDave

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1791
    • View Profile
    • NXT Foundation
  • Karma: +341/-40

I'm with chanc3r here...been busy, will read soon.
Thanks in advance....
Nulli Dei, nulli Reges, solum NXT
NXT Donations: NXT-BNZB-9V8M-XRPW-3S3WD
We will ride eternal, shiny and chrome!

chanc3r

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1019
  • NXTInspect
    • View Profile
  • Karma: +124/-50

Guys - reviewed and added a couple of new comments, some are suggestions to help people understand and in a couple of places it became a little too adversarial/non-objective so I suggested some alternatives,

overall nice improvements to the paper - think its looking good now and the rational for the network equivalence and the staggering difference in the energy requirements is amazing.
NXT: 29996814460165 (NXT-JTA7-B2QR-8BFC-2V222)
@imrimr @NXTinspect

mczarnek

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 898
    • View Profile
    • Nxt Place - Craigslist for Nxt
  • Karma: +68/-4

Thanks again chanc3r, you've been very helpful with this paper, give me a Nxt address and I'll send some Nxt your way.

I'll quickly read your new comments and will make changes, probably tonight.
NXT Organization: Tech
Donations greatly appreciated: NXT-DWVJ-G89C-RHNL-6QW6Q

antanst

  • Full Member
  • ***
  • Offline Offline
  • Posts: 216
    • View Profile
    • nxtblocks.info
  • Karma: +36/-0

Please bear in mind that right now, max transactions are 255 per block. So, everything that talks about thousands of transactions per second, visa level scaling etc. is just wishful thinking at this point.

chanc3r

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1019
  • NXTInspect
    • View Profile
  • Karma: +124/-50

Please bear in mind that right now, max transactions are 255 per block. So, everything that talks about thousands of transactions per second, visa level scaling etc. is just wishful thinking at this point.

Absolutely and with a block time of 1min we would need 60k in a single block to achieve this without parallel chains...
There should be no claims NXT can do this now but if it can/is scaled what would this look like.

I think the most powerful part is the if we had the same number of nodes as the most efficient bitcoin miners today we would use almost 400x less power...

Shows the idiocy of PoW!
NXT: 29996814460165 (NXT-JTA7-B2QR-8BFC-2V222)
@imrimr @NXTinspect

bob_ggg

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 90
    • View Profile
  • Karma: +9/-0

Ok, we've updated the energy and cost efficiency analysis paper.  I think the number of forgers forging for the network is a more solid number.

Please check it out here:
https://docs.google.com/document/d/1J8uhdshu9epGRrQHBaloGc4itdvuAHZDAUtNDjOhz-8/edit?usp=sharing

I'd love to hear comments before we publish it. As far as I'm concerned should be ready to publish unless I hear otherwise. Thank you!
I have read the paper and I am not sure I understand the analysis of bandwidth requirements. If you want to find the upper limit of the number of txn, you should include at least three processes: 1) txn upload, 2) previous block upload, 3) current block forging. They all that increase latency and reduce throughput. Process 1) and 2) should include network latency (and not just bandwidth limitations). A back-of-the-envelope analysis I posted a while ago was much less optimistic. unless you include advanced algorithms that support parallelism and pipelining.

mczarnek

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 898
    • View Profile
    • Nxt Place - Craigslist for Nxt
  • Karma: +68/-4

Ok, we've updated the energy and cost efficiency analysis paper.  I think the number of forgers forging for the network is a more solid number.

Please check it out here:
https://docs.google.com/document/d/1J8uhdshu9epGRrQHBaloGc4itdvuAHZDAUtNDjOhz-8/edit?usp=sharing

I'd love to hear comments before we publish it. As far as I'm concerned should be ready to publish unless I hear otherwise. Thank you!
I have read the paper and I am not sure I understand the analysis of bandwidth requirements. If you want to find the upper limit of the number of txn, you should include at least three processes: 1) txn upload, 2) previous block upload, 3) current block forging. They all that increase latency and reduce throughput. Process 1) and 2) should include network latency (and not just bandwidth limitations). A back-of-the-envelope analysis I posted a while ago was much less optimistic. unless you include advanced algorithms that support parallelism and pipelining.

Yeah latency is an issue, didn't think about that much.  Though I suspect not much of one.  I really think that we do need to implement predefined paths for sending transactions in the long run, if every forger sends these to 10 forger along that type of predefined paths, than even with some repetition built in at 1 million forgers (That'll be a nice day lol), it'd be log of say 5 million = 6 to 7 computers that is the longest path through the network.  I realize we aren't there and likely won't be when we reach Bitcoin's size.

I used Bitcoin's calculations (https://en.bitcoin.it/wiki/Scalability )without thinking through it much beyond we'd need to upload and download the current block which contains transactions.

I guess Nxt works a little bit different, with Bitcoin instant transactions aren't any issue, you broadcast your transaction to any miner and it just propagates through out the network in that way.

Anyway will think about that slightly more, would you happen to have that back-of-the-envelope analysis somewhere?

Also, thank you again Ian for the feedback, added a section that compares the energy usage of Nxt and Bitcoin to numbers people can related to.. did you guys know Bitcoin uses more energy than all the households in the US combined?  Actually may need to re-write that.. but it's up there.
« Last Edit: April 16, 2014, 10:36:48 pm by mczarnek »
NXT Organization: Tech
Donations greatly appreciated: NXT-DWVJ-G89C-RHNL-6QW6Q

bob_ggg

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 90
    • View Profile
  • Karma: +9/-0

I posted my estimated here

https://bitcointalk.org/index.php?topic=506757.msg5824693#msg5824693

Latency has a direct impact on throughput unless you consider a pipelined implementation.

chanc3r

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1019
  • NXTInspect
    • View Profile
  • Karma: +124/-50

I posted my estimated here

https://bitcointalk.org/index.php?topic=506757.msg5824693#msg5824693

Latency has a direct impact on throughput unless you consider a pipelined implementation.

matt - interesting read - to busy to look atm but you might want to have a read of bob's post and tune that section a bit if you agree with it.

EDIT: re-read again today - the network part is the weaker part of the paper, also you did not address my TF comment which I don't think materially reduces bandwidth... also bob's comments on bandwidth needed when you are not the forger i.e. just to exist as a peer vs bandwidth to successfully forge @xtps is a useful angle...
« Last Edit: April 17, 2014, 12:41:30 pm by chanc3r »
NXT: 29996814460165 (NXT-JTA7-B2QR-8BFC-2V222)
@imrimr @NXTinspect

bob_ggg

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 90
    • View Profile
  • Karma: +9/-0

A useful complement to the paper would be the analysis of a specific use case. My understanding is that the preferred forging machine should be hosted by a data center in order to reduce the chances of a DDoS. If so, the cost of hardware and bandwidth can be estimated relatively well. The energy issue would be difficult to address, but the cost of a virtual server and that of associated bandwidth are. Another key parameter would be the projection of the system performances assuming that a given number of machine ready for forging is available. This analysis requires some assumptions concerning the implementation of the software, but IMO it could reveal that the architecture of Nxt can support a TPS similar to the one supported by VISA. Ready to contribute to this analysis if I can be useful.

salsacz

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1765
  • NXT-R67P-6BZ2-XWAK-8RHZR
    • View Profile
  • Karma: +239/-67
Holidays are (almost) over, check more news at: Nxt Academy

mczarnek

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 898
    • View Profile
    • Nxt Place - Craigslist for Nxt
  • Karma: +68/-4

could have Nxt similar graph?
https://blockchain.info/charts/cost-per-transaction

I think eventually yes, very interesting if there was a way to come up with a formula using these numbers that would allow us to come up with predicted numbers side-by-side.  Not for this paper though.

@bob_ggg  Well the plan is use say 3 forgers, each of them reveal themself to 128 other forgers and it is known which forgers forward their traffic to the currently chosen forger.  The idea then is that those 128 forgers will act like DDOS protection and if done properly, very little other security is needed.


Regarding the bandwidth issue, have not had time to sit down and do a more in depth analysis and something just came up at work which will be taking up all my time during these next couple of weeks.  If anyone else would like to work on it, would be willing to pay them some small piece of the bounty or I'll do it in two weeks.  Something to keep in mind, uploading and downloading bandwidths should be treated separately.

As I understand it, you are downloading blocks and transactions, as well as uploading blocks and transactions.  Currently you send your transactions and maybe blocks to 10 other forgers, maybe also recieve from 10 others?  Not sure about those details.. like I said will further research in about two weeks, maybe this weekend, if nobody else has.  Thanks.
NXT Organization: Tech
Donations greatly appreciated: NXT-DWVJ-G89C-RHNL-6QW6Q

bob_ggg

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 90
    • View Profile
  • Karma: +9/-0

Sending data to three forgers should not be a problem in terms of bandwidth; the sender node has no BW limitation on its side.

I have assumed that the (only) forging node a) receives transactions from other nodes; 2) receives the previously forged block, 3) sends the currently forged block to the next forging node. It would be interesting to have access to a code profile to check if computing time required to assemble the block is really small (as I implicitly assumed) or not.
I guess that a major difference from the above model is that you have three forgers so that you can draw a kind of majority consensus (is this a dynamic Ripple-like model?). If I have understood the situation, then you have to include the sharing of the blocks until consensus is reached. I do not know how many iterations are needed, but they are additive to the latency time.
A nice evolution would be a pipelined model where at least two sets of forgers are defined, one set of forgers supposed to complete its block before the other can start. Transactions could then be sent to one of the two sets by the users according to the time preference. A large part of the work could be done by the second set of forgers even before the current block is defined, since all transactions could be validated except those that have further occurrences in the current block. If this model were considered, then BW considerations could be relaxed. However, before proceeding further I want to make sure that I understand the overall picture.

mczarnek

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 898
    • View Profile
    • Nxt Place - Craigslist for Nxt
  • Karma: +68/-4

I totally agree with the pipeline idea.  Transactions should be automatically forwarded along the the next forgers in line as soon as you have the information to do it.  And worst case scenario, we require that forgers get 40 Mbps internet.  With your calculations, 40 Mbps internet should be able to cover 2000 tps, which is doable for $60 per month.  When we get to the point where we can cover peaks of 2000 tps, that means that we're probably doing 1000 tps regularly?  Which means a block contains 60,000 transactions.  Even if someone only forgers one block per month, if we need to add an extra $0.001 per transaction to cover it, it's not awful.  Though by that point I imagine that we would've been able to implement something along the lines of pipelining and some other tricks to improve this.

The idea behind the 128 forgers is that you can even send your transaction to all 3*128 = 384 DDOS protection forgers.  The other forgers don't even know how to reach you.  If any of them are found to be DDOS attacking you, you can cut them off.  That being said, you are directly sharing your IP address with those DDOS protect forgers,  so if they want to DDOS attack that forger, then they can take that IP address and give it to other machine who can DDOS protection you.  So personally, I think that maybe a tiered approach would be better.  Have 128 forgers out front, they share their IP addresses, forward transaction on to 32 forgers who account for 4 forgers each.  Who then forward it onto 8 forgers who are the last found of protection before the forger.  Point being that 16 times less computers would be able to directly know how to send traffic to and directly attack the current forger. Haven't discussed that with anyone, maybe I'm missing something.

Back on topic, finally have a little bit of time.  It's not a core part of the paper, I could even drop it or just make a small note that at Bitcoin's size we'll only need to cover 1 transaction per second and can easily handle that. But sitting down now to try to work on this and come up with my own numbers.  Bob_ggg, you want to bounce around numbers, let me know.
NXT Organization: Tech
Donations greatly appreciated: NXT-DWVJ-G89C-RHNL-6QW6Q

bob_ggg

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 90
    • View Profile
  • Karma: +9/-0

I can add some numbers. Can you get to me some results from profiling the code? A main assumption was that the computing cost of forging is more or less equivalent to that of data transmission.

Referring to your discussion of pipelining, I do recommend to consider all options open to speed up the Txn performances even though their implementation is postponed. IMO, the issue of Txn performance is a key difference between Nxt and other products, with the exception of Ripple. Usually, high-performance requires high cost solutions. If this were not true for Nxt, then its competitive potential would be much higher. I posted a proposal to increase the performances of the parallelism of the forging process here

https://nxtforum.org/general/hierarchical-forging/

mczarnek

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 898
    • View Profile
    • Nxt Place - Craigslist for Nxt
  • Karma: +68/-4

That'd be great, I've spent some time looking through the code, if does look like every block has a header to it and I believe that this is the snippet of code that actually assembles the blocks:
Code: [Select]
byte[] getBytes() {

        ByteBuffer buffer = ByteBuffer.allocate(4 + 4 + 8 + 4 + (version < 3 ? (4 + 4) : (8 + 8)) + 4 + 32 + 32 + (32 + 32) + 64);
        buffer.order(ByteOrder.LITTLE_ENDIAN);
        buffer.putInt(version);
        buffer.putInt(timestamp);
        buffer.putLong(Convert.nullToZero(previousBlockId));
        buffer.putInt(blockTransactions.size());
        if (version < 3) {
            buffer.putInt((int)(totalAmountNQT / Constants.ONE_NXT));
            buffer.putInt((int)(totalFeeNQT / Constants.ONE_NXT));
        } else {
            buffer.putLong(totalAmountNQT);
            buffer.putLong(totalFeeNQT);
        }
        buffer.putInt(payloadLength);
        buffer.put(payloadHash);
        buffer.put(generatorPublicKey);
        buffer.put(generationSignature);
        if (version > 1) {
            buffer.put(previousBlockHash);
        }
        buffer.put(blockSignature);
        return buffer.array();
    }
Found here: https://bitbucket.org/JeanLucPicard/nxt/src/0f9d43c0e30ad8697d82d7b34a0bf1bd2bb181c9/src/java/nxt/BlockImpl.java?at=master

You should check out Nxt's Parallel Chains idea.  It was introduced by BCNext and I have to run out the door but it sounds very similiar to your hierarchical forging.  For some reason I can't get the right page to load at the moment.. if it works later I'll post a link.

I agree the more solid we can make the forging and core algorithm the better it will be for Nxt in the long run.  I think it's quite important to increase the number of transactions per second as well as get instant transactions working in an efficient manner(which is my next project.. possibly after helping write an improved transparent forging algorithm).
NXT Organization: Tech
Donations greatly appreciated: NXT-DWVJ-G89C-RHNL-6QW6Q

bob_ggg

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 90
    • View Profile
  • Karma: +9/-0

That'd be great, I've spent some time looking through the code, if does look like every block has a header to it and I believe that this is the snippet of code that actually assembles the blocks:
Code: [Select]
byte[] getBytes() {

        ByteBuffer buffer = ByteBuffer.allocate(4 + 4 + 8 + 4 + (version < 3 ? (4 + 4) : (8 + 8)) + 4 + 32 + 32 + (32 + 32) + 64);
        buffer.order(ByteOrder.LITTLE_ENDIAN);
        buffer.putInt(version);
        buffer.putInt(timestamp);
        buffer.putLong(Convert.nullToZero(previousBlockId));
        buffer.putInt(blockTransactions.size());
        if (version < 3) {
            buffer.putInt((int)(totalAmountNQT / Constants.ONE_NXT));
            buffer.putInt((int)(totalFeeNQT / Constants.ONE_NXT));
        } else {
            buffer.putLong(totalAmountNQT);
            buffer.putLong(totalFeeNQT);
        }
        buffer.putInt(payloadLength);
        buffer.put(payloadHash);
        buffer.put(generatorPublicKey);
        buffer.put(generationSignature);
        if (version > 1) {
            buffer.put(previousBlockHash);
        }
        buffer.put(blockSignature);
        return buffer.array();
    }
Found here: https://bitbucket.org/JeanLucPicard/nxt/src/0f9d43c0e30ad8697d82d7b34a0bf1bd2bb181c9/src/java/nxt/BlockImpl.java?at=master
I need the help of some one willing to spend a few minutes and collect a few numbers that give the time spent in the key routines during forging. Is there any way to run a profiler and gather the results? If the hypothesis that most of the time is spent in the (few ?) lines of crypto code, I could try to map them on an FPGA and see what I get in terms of performance. In this way, they would be out of the loop if the communication between processor and FPGA is small.

Quote
You should check out Nxt's Parallel Chains idea.  It was introduced by BCNext and I have to run out the door but it sounds very similiar to your hierarchical forging.  For some reason I can't get the right page to load at the moment.. if it works later I'll post a link.

I agree the more solid we can make the forging and core algorithm the better it will be for Nxt in the long run.  I think it's quite important to increase the number of transactions per second as well as get instant transactions working in an efficient manner(which is my next project.. possibly after helping write an improved transparent forging algorithm).

I think that the idea of PC and HF (hierarchical forging) are very different. PC are ideal to create a chain dedicated to a specific goal (such as AE or AT). HF is a way to restructure the main chain in a way that guarantees more parallelism with the same allocation of computing resources. I tried to reuse the concept of transactions that are verified locally in case they involve parties that belong to the same cluster. In this way, the accounts that do not belong to that specific cluster do not need to worry about it, providing that the overall balance of the cluster remains the same.
Basically, HF exploits the fact that most transactions are either based on geographical location or directed toward a few large retailers. From a formal/algorithmic standpoint, it is possible to introduce graph cutsets that take this intrisic structure into account.
The implementation of this idea is simple in a premined system, while it would be much more complex in an environment such as BTC where mining modifies the monetary aggregate with a coinbase transaction.
Pages: [1] 2 3  All