Pre-Dev-Update Thread! Yay! :D

OK so I did this…

willie@gagarin:~/projects$ safe -V
sn_cli 0.26.0
willie@gagarin:~/projects$ safe node bin-version
sn_node 0.42.6
willie@gagarin:~/projects$ safe node killall
Error: Failed to stop nodes (sn_node) processes: sn_node: no process found

willie@gagarin:~/projects$ safe node run-baby-fleming
Storing nodes' generated data at /home/willie/.safe/node/baby-fleming-nodes
Launching local Safe network...
Launching with node executable from: /home/willie/.safe/node/sn_node
Version: sn_node 0.42.6
Network size: 11 nodes
Using RUST_LOG 'sn_node=debug'
Launching genesis node (#1)...
Connection info directory: /home/willie/.safe/node/node_connection_info.config
Genesis node contact info: ["127.0.0.1:37872","127.0.0.1:45151","127.0.0.1:53345","127.0.0.1:45732","127.0.0.1:44502","127.0.0.1:40488","127.0.0.1:40724","127.0.0.1:60766","127.0.0.1:50556","127.0.0.1:37961","127.0.0.1:33055"]
Common node args for launching the network: ["-vv", "--idle-timeout-msec", "5500", "--keep-alive-interval-msec", "4000"]
Launching node #2...
Launching node #3...
Launching node #4...
Launching node #5...
Launching node #6...
Launching node #7...
Launching node #8...
Launching node #9...
Launching node #10...
Launching node #11...
Done!
willie@gagarin:~/projects$ 

and I saw this in another terminal

willie@gagarin:~$ tail -f ~/.safe/node/baby-fleming-nodes/sn-node-genesis/sn_node.log 
[sn_node] INFO 2021-05-27T15:08:32.325082943+01:00 [src/bin/sn_node.rs:106] 

Running sn_node v0.42.6
=======================
[sn_node] ERROR 2021-05-27T15:08:32.385751840+01:00 [src/bin/sn_node.rs:125] Cannot start node due to error: Logic("Config error: Invalid Ed25519 public key bytes"). If this is the first node on the network pass the local address to be used using --first. Exiting
1 Like

You may wanna make sure to clean up ~/.safe/node/baby-fleming-nodes folder as rewards keys format was changed between that node and later versions.

3 Likes

Thank you @bochaco
I can create a new Safekey and put files to baby-fleming with sn_node v0.42.6 and CLI 0.26.0 once I deleted ~/.safe/node/baby-fleming-nodes

4 Likes

Accidentally posted in the update thread before I realized that’s no allowed, so I deleted it there but I have to say…

This is why I love this project despite the long wait and the complete refactorings that threw out year’s of work. From the start it wasn’t even about crypto payments, but yet they could end up doing that better than anyone else, and without the environmentally unfriendly electricity cost. For something that was just recently announced as an addition to the main functionality this is really amazing.

22 Likes

Good work team. Much to be excited about!

23 Likes

:blush: :smiley: :grinning: I’m smiling a lot these days.

13 Likes

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?

10 Likes

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.

28 Likes

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?

2 Likes

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