Topic: New Cryptocurrency written using 'Rust', looking for another programmer - page 2. (Read 2603 times)

This method is applicable only to payments. It won't work on advanced features like asset exchange.

Got it, guys. What is the name of the currency, so I could spot it when it's released and check how parallelization works?

@mczarnek: Do you have in mind a tx-based currency [like Bitcoin] or account-balance-based one [like NXT]?

Something like this could also help where you link transactions back to the ones they rely on seeing first though my initial thought is that dipping into negative balances may be easier to implement and enforce.

I don't have a source. I don't think it's needed in this case.
Look at this block for example: https://blockchain.info/block/000000000000000000c0e693dd6c552e8ba40ac63d978f7cef1b49cce03f8c7d
While there are some chains of transactions [I can see even one chain of 10tx!] they are exception. Most of transactions are using transactions from previous blocks. These can be easily parallelized.

Besides, even if you had 4 long chains of 300tx in one block, it'd max out 4 core cpu to 100% allowing for about the same time.

Good point. One fix is to allow account balances to dip into negative, keeping track of which accounts currently have negative  balances. And when finished processing, accept the block only if no such account balances exist.

Again, two steps, each of which can be done in parallel.. or maybe the second step can even just be, "Is list empty?"

What is the source of your numbers?

Not every transaction depends on the transaction before it. You can parallelize 99.9% of transaction processing and keep 0.01% serial [if one transaction depends on the one before it in the same block].

Alice has $10, Bob has $0.
Block contains "Alice pays Bob $5" and "Bob pays Alice $5".
One node will accept this block, another node will reject it because thread scheduler will change the order of transaction processing.
More interesting effects will happen during order matching if you have something like Asset Exchange.

I don't see any reason you can't parallelize transaction processing, which seems to be the majority of the work miners are doing.

I intend to keep basically a running total going for the most frequently used accounts, and as you process a transaction, you check to see if that account had enough money, assets, etc at that moment.  Even if they are out of order, the miner who initially mines them can mine them in either order.

I don't know that I would use it here would have to think through security implications further, but hashing these blocks together to make sure they have the correct hash could be done this way too, you just could keep an accumulator which is basically the 'sum' of all the byte values of transactions so order isn't important, appended to the header info, then at the end you put it through the hashing function.  And when it comes to verifying transactions, similarly it doesn't matter if they are out of order or not, either the block is valid or it isn't.  You can process all transactions in parallel into a buffer that is sorted by changes to individual account ids, then go through and check those all at once, then finally apply them. Each of those steps could be done in parallel.

Granted you would have to verify and manipulate all transactions in the block you are checking before you starting building the new one, but building a new block or verifying a block someone else mined could be done in parallel.

This probably would not be in version one as it is indeed a little trickier, but somewhere does the line, it would be nice to have this easy to add.  You could hope for 3 times speed up of block processing on a 4 core CPU.  Which may someday be significant.

This is an interesting part. How do you parallelize manipulations on a single ledger?

Hello,

I am in the process of writing a new cryptocurrency, because of the uniqueness of the mining algorithm, it needs to be re-written from scratch.  I've started the program using 'Rust' to do this.  I went with Rust because it means it means the transactions processing will be able to be parallelized easier and also because it forces you to write secure code that doesn't have the potential memory risks of C++ but in theory runs as fast as C++ (C++ has had lots of time to optimize itself.. Rust is still newish).

Any chance any developers are out there and interested?  I'd be happy to further explain the idea behind this new coin which I think will grab some attention.. the project just still happens to be in 'Stealth Mode'.


If you want to learn more about Rust developed by Mozilla, I recommend reading this post. It was the eye opener for me:
http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html

Or check out rust-lang.org