Pre-Dev-Update Thread! Yay! :D

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.

12 Likes

Great work guys :grinning:!

The dream of a torrent site that can never be taken down is closing in :joy:!

Thank you

10 Likes

9th. :slight_smile:

Does the 19 000tps can handle Raspberry nodes as elders ?

4 Likes

Amazing :+1:t3::+1:t3::+1:t3:

4 Likes

Yes it’s for any machine so pi should be fine, we will soon find out. …

9 Likes

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

9 Likes

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.

11 Likes

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.

So I’d say that @oetyng, @danda, and the others working on or that advocated for DBC/AT2 deserve a round of applause. :clap::clap::clap:

21 Likes

In terms of final settlement Bitcoin is faster than VISA. 10 minutes compared to days.

4 Likes

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

4 Likes

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.

2 Likes

Apparently Harmony One can do 2000 TPS and if they get enough nodes they will reach 1 million TPS

1 Like

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.

14 Likes

Does anyone know the current number of nodes per section before a split occurs?

1 Like

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?

2 Likes

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

9 Likes

Does this mean a section currently has exactly 7 elders and between 7 and 14 adults?

3 Likes

7 Elders + 7 Adults at least. To split it needs 28 nodes min, circa 30 nodes for split tho as nodes are not 100% balanced in address space.

12 Likes

In previous testnets we used only at2 but don’t have measurements. It is likely that it would be approx 50% of that with the network doing additional wallet updates, some/mostly remote. What’s nice here is the client has the Dbc, so no wallet needs agreed/updated and at the same time no wallet transaction records, which is a bit leaky.

12 Likes