THE fastest crypto-currency is BitShares 2.0 over 100 000 transactions per second scalability (1 second block)
https://bitshares.org/technology/industrial-performance-and-scalability
Will be launched October 13 with 3 seconds block (30 000 transactions per second)
Topic: [EMUNIE] THE fastest crypto-currency - page 5. (Read 11666 times)
Ah, no matter. I'll wait for the open beta. Thanks.
Should be a few days before the 7 horsemen of the apocalypse approach.
I'll be patient.
Ah, no matter. I'll wait for the open beta. Thanks.
Should be a few days before the 7 horsemen of the apocalypse approach.
Ah, no matter. I'll wait for the open beta. Thanks.
How can one be an Emunie beta tester?
Dan has been slowly bringing more in over the past 2 years for the closed beta releases. I've been one for close to a year now. I was pretty frustrated in terms of how long it took to be givent the status. Lately it has been mostly founder beta testing (a much smaller group). From this point you would be better off waiting for the open beta. But to try to get closed beta access, you can try through the eMunie forum.
How can one be an Emunie beta tester?
why not a lean KV approach?
an in-memory/disk hybrid like redis can handle such tiny amounts of data in a blink
with lowest cpu usage compared to bloated rdbms. e.g. one million keys occupies only
100 mb memory. persistence is great via fine granulated shapshots. the api provides
all primitives to layer a query model on top. should be a good choice for this kind of task.
if a full persistent solution is needed something like sophia outperforms many other
disk based storages and is nearly as fast as redis but with a fraction in code size.
an in-memory/disk hybrid like redis can handle such tiny amounts of data in a blink
with lowest cpu usage compared to bloated rdbms. e.g. one million keys occupies only
100 mb memory. persistence is great via fine granulated shapshots. the api provides
all primitives to layer a query model on top. should be a good choice for this kind of task.
if a full persistent solution is needed something like sophia outperforms many other
disk based storages and is nearly as fast as redis but with a fraction in code size.
Will this approach run on a $600 commodity Notebook computer, which is what I am successfully using as an eMunie beta tester?
why not a lean KV approach?
an in-memory/disk hybrid like redis can handle such tiny amounts of data in a blink
with lowest cpu usage compared to bloated rdbms. e.g. one million keys occupies only
100 mb memory. persistence is great via fine granulated shapshots. the api provides
all primitives to layer a query model on top. should be a good choice for this kind of task.
if a full persistent solution is needed something like sophia outperforms many other
disk based storages and is nearly as fast as redis but with a fraction in code size.
an in-memory/disk hybrid like redis can handle such tiny amounts of data in a blink
with lowest cpu usage compared to bloated rdbms. e.g. one million keys occupies only
100 mb memory. persistence is great via fine granulated shapshots. the api provides
all primitives to layer a query model on top. should be a good choice for this kind of task.
if a full persistent solution is needed something like sophia outperforms many other
disk based storages and is nearly as fast as redis but with a fraction in code size.
Where can I find the specifications?
If you get something right the first time you don't have to worry about forking it later due to the inability of it to scale to necessary levels.
The "core" txn system is what is being done right the first time.
All other layers on top of that (e.g. client functionality) are merely utilized expressions of the capabilities for the users. Those can be updated easily.
The "core" txn system is what is being done right the first time.
All other layers on top of that (e.g. client functionality) are merely utilized expressions of the capabilities for the users. Those can be updated easily.
Yup, partitions my friend, that problem goes away 
Isn't this system going to be extremely difficult for updates in the long run? Partitioning and having different groups who don't update, etc.
That solution for you (if it fits your purpose) will be very fast, then your IO bottleneck with shift to network I imagine?
Network will become a bottleneck at 12'000 TPS (for 100 Mbps).
Yup, partitions my friend, that problem goes away
That solution for you (if it fits your purpose) will be very fast, then your IO bottleneck with shift to network I imagine?
Network will become a bottleneck at 12'000 TPS (for 100 Mbps).
Hmmm...Ive found that the major bottlenecks on lower end stuff is actually the IO DB writes/reads and not so much crypto related stuff. Sure it has a positive effect if you can speed it up, but a good 70%+ of optimizing I do is how to get data over the IO quicker and more efficiently.
What DB system do you use? MySQL? I use http://docs.oracle.com/javase/8/docs/api/java/nio/MappedByteBuffer.html.
I have just recalled that Emunie does much more than just payments, in this case we cannot compare our solutions, because our cryptocurrency works with payments only and doesn't need to do sophisticated stuff like order matching.
MySQL and Derby for development, probably go with Derby or H2 for V1.0.
The data stores themselves are abstracted though, so any DB solution can sit behind them with minor work so long as they implement the basic interface.
That solution for you (if it fits your purpose) will be very fast, then your IO bottleneck will mainly shift to network I imagine?
Hmmm...Ive found that the major bottlenecks on lower end stuff is actually the IO DB writes/reads and not so much crypto related stuff. Sure it has a positive effect if you can speed it up, but a good 70%+ of optimizing I do is how to get data over the IO quicker and more efficiently.
That was like word for word what Bytemaster said in this youtube video heh: http://www.youtube.com/watch?v=bBlAVeVFWFM
Well IO is always a problem bottleneck, thats simple developer 101
Hmmm...Ive found that the major bottlenecks on lower end stuff is actually the IO DB writes/reads and not so much crypto related stuff. Sure it has a positive effect if you can speed it up, but a good 70%+ of optimizing I do is how to get data over the IO quicker and more efficiently.
That was like word for word what Bytemaster said in this youtube video heh: http://www.youtube.com/watch?v=bBlAVeVFWFM
Hmmm...Ive found that the major bottlenecks on lower end stuff is actually the IO DB writes/reads and not so much crypto related stuff. Sure it has a positive effect if you can speed it up, but a good 70%+ of optimizing I do is how to get data over the IO quicker and more efficiently.
What DB system do you use? MySQL? I use http://docs.oracle.com/javase/8/docs/api/java/nio/MappedByteBuffer.html.
I have just recalled that Emunie does much more than just payments, in this case we cannot compare our solutions, because our cryptocurrency works with payments only and doesn't need to do sophisticated stuff like order matching.
You're probably the one and only developer I wouldn't mind proving me wrong 
If you can show me proof of an existing crypto processing 250 tx/s sustained, I'll be mildly impressed. If it can be done on 20 or less nodes, I'll be suitably impressed. If you can show the same doing 500 tx/s+ I'll be very impressed.
Likewise if you can show peaks of 500, 1000 & 2000+ the corresponding impressed level as described above will be in effect
If you can show me proof of an existing crypto processing 250 tx/s sustained, I'll be mildly impressed. If it can be done on 20 or less nodes, I'll be suitably impressed. If you can show the same doing 500 tx/s+ I'll be very impressed.
Likewise if you can show peaks of 500, 1000 & 2000+ the corresponding impressed level as described above will be in effect
What are requirements for bandwidth, RAM and CPU of a node?
PS: I'm using a hash-based signing algorithm, it's much faster than elliptic curve stuff (even faster than Ed25519), so I may have some advantage right from the start.
The lowest spec node I ran in that test was an Asus i3-3217 laptop, 32bit OS, 256MB of heap allocated to Java and the DB running on its 5400 rpm platter drive. Its a really crappy machine, the CPU is Quad Core, but it barely manages 2000 passmark points and the HD...well....pen and paper would be faster I swear. It *just* about kept up acting as a ledger node, so I guess that or lower is your target
Not sure if anyone in the network was running lower grade hardware than that.
Hmmm...Ive found that the major bottlenecks on lower end stuff is actually the IO DB writes/reads and not so much crypto related stuff. Sure it has a positive effect if you can speed it up, but a good 70%+ of optimizing I do is how to get data over the IO quicker and more efficiently.
You're probably the one and only developer I wouldn't mind proving me wrong
If you can show me proof of an existing crypto processing 250 tx/s sustained, I'll be mildly impressed. If it can be done on 20 or less nodes, I'll be suitably impressed. If you can show the same doing 500 tx/s+ I'll be very impressed.
Likewise if you can show peaks of 500, 1000 & 2000+ the corresponding impressed level as described above will be in effect
If you can show me proof of an existing crypto processing 250 tx/s sustained, I'll be mildly impressed. If it can be done on 20 or less nodes, I'll be suitably impressed. If you can show the same doing 500 tx/s+ I'll be very impressed.
Likewise if you can show peaks of 500, 1000 & 2000+ the corresponding impressed level as described above will be in effect
What are requirements for bandwidth, RAM and CPU of a node?
PS: I'm using a hash-based signing algorithm, it's much faster than elliptic curve stuff (even faster than Ed25519), so I may have some advantage right from the start.
Jump to: