Fantastic update, thank you all. One Q about the 19,000 tps - does this figure need to cover PUT payments so: does 19,000 = PUT payments per sec + other p2p payments per sec? Or is the 19,000 tps independent of the number of PUTS per sec?
Yes, specifically this test is 1 in put paying 100 outputs and it takes
test tests::bench_reissue_1_to_100 ... bench: 5,289,357 ns/iter So this is independent of anything. These can also happen concurrently so I would expect we can push this figure significantly higher.
Trade offs are we need to check an Xor address per input (to see it’s not spent). That’s an async call, so we can probably have a large number of these per second. The clear thing is this is significantly faster than Visa and an awful lot faster than bitcoin.
Overall I feel we can really expand this easily, even with just bls batch sigs (which we need to code as threshold_crypto does not have these in place) and some parallelism I would think we easily 2-3X these figures.
What we are doing here is also (in addition to normal crypto payments) allowing the creation of put contracts/payments. So these would be the same throughput. i.e. we can get 100,000 chunks go through self encryption, get the names and then mint the DBCs for them in under a second. Then we can put at our leisure. That algo is in docs right now and going into POC any day. I hope T7 has that in place.
Why 100 outputs?
My expectation is:
- one t per PUT to credit the section wallet
- upon section split, N x t to issue a reward to each of N nodes in the section
Maybe the 100 is just part of the test rig?
Yes, this is a benchmark for us. All part of testing. We will increase the benchmarking as we go, to show many different processes. i.e. mint several thousand inputs against hundreds of thousand outputs and so on.
Great work guys !
The dream of a torrent site that can never be taken down is closing in !
Does the 19 000tps can handle Raspberry nodes as elders ?
Yes it’s for any machine so pi should be fine, we will soon find out. …
Very exciting to see dbc making progress.
Is this for a single-node mint, or single-section mint (multiple elder nodes reaching consensus on each spend)? From the dbc_mint repo it looks to be multiple nodes (using bls_dkg and SecretKeySet).
Single thread or multi thread? From the dbc_mint repo looks to be single thread.
ed25519 or bls keys? From the dbc_mint repo looks to be bls.
I’m just a little unclear on what the 19K tps stat means because from my testing of bls verifications it looks like each signature verification takes around 6ms, which would give around 170 tps. Being 100x faster than that is really impressive. Do you have any info about the test process to get the 19K tps number?
Ah the test is from
bench_reissue_1_to_100 thanks for this dirvine I need to read the whole forum backlog before posting!
edit: ah sorry Dimitar I should know better than to post in the other thread! Thanks for moving it
Single thread multi sig (single section mint) as you can see Benchmark splitting and merging by davidrusu · Pull Request #39 · maidsafe/sn_dbc · GitHub So a lot of reasons to be comfortable with this. Lots of room here to play and get a real feel for throughput.
Side note sig verification is client side for us. So we are all sig and client aggregates/verifies which is nice.
I can’t seem to find any other project, even those that claim to be light, fast, and are designed specifically for fast payments and fast payments alone, that can go over 1,500 TPS. Even then it seems to be being generous to real world stress tests.
In contrast Visa’s swift network can apparently handle 24,000 TPS max.
In terms of final settlement Bitcoin is faster than VISA. 10 minutes compared to days.
@bittog9 Great point and that is also an important metric. Though most/all crypto will have that advantage over the legacy systems.
Not related to settlement but an extra little piece on average transaction speed amongst various niche cryptos. Privacy coins tend to be slower so that is yet another leg up for Safe Network.
It probably depends on the currency. The Bank of England usually clears GBP in moments now. Not sure about the euro, but I believe the USD is slower.
Apparently Harmony One can do 2000 TPS and if they get enough nodes they will reach 1 million TPS
Well, good luck !
That kind of claim is interesting because some networks that shard like we do will be able to handle more TPS as they scale. That is supposedly also the case for IOTA I believe. EOS made some insane off the wall TPS claim but it wasn’t really proven and then when some group tested that claim they came in with a result of 50 TPS which of course lead to crypto tribe drama.
But if Harmony One can do 2,000 TPS and we can do circa 19,000 in one section with no optimizations then every time you add a section (shard) then add another 19,000 TPS. The network will have many sections and can scale continually, so we could make an even more bombastic claim of future TPS than Harmony One but that would be disingenuous, IMO.
I’d rather see us say 60,000 (or whatever it is after optimizations) TPS per section x2 every n additional nodes (n being number of nodes per section that would cause a split).
Something like that. As long as it is accurate, honest and clear.
Does anyone know the current number of nodes per section before a split occurs?
Assuming 50,000 tps after optimizations means the network hits 1000000 tps with only 20 sections. That is a baby beta network. Aren’t we expecting upwards of a million sections?
We recently set section size at 2*7 (14) to get splits happening more frequently. It’s a number we are playing with but want to hammer testnets with low section numbers, so many more sections. Still 7 Elders tho