Update 01 June, 2023

Development Updates
1

We declare NatNet a definite success! As far as we can tell, all home nodes operating behind NAT were successfully detected and shut down, mitigating the problems we were experiencing earlier where the network would try to communicate with unreachable nodes. Now we are confident in detecting nodes behind a NAT, the next step on that front would be allowing them to join via hole punching and UDP/Quic. NatNet was TCP only.

Alongside that though (NAT traversal still needs a bit of work, as we’ve mentioned before it’s quite basic in libp2p so this may take some time), there’s plenty afoot.

We’re taking an initial gander at provider nodes that can perform tasks such as archiving. If you remember, with libp2p we can treat certain nodes as service providers to perform special functions like archiving.

The other area we’ve returned to is the matter of node sizing (and trying to benchmark replication flows). How small is small? Are 1,000 small nodes better than one large one of the same capacity? What’s the difference when we have massive churn? What are the tradeoffs? We’re running some preliminary tests now.

General progress

@anselme has adapted the spendbook to hold both double spend entries instead of just one. They can then be more easily dealt with. This is on top of the recent merge of work getting DBCs into the RecordStore, which means they’ll be automatically replicated alongside chunks (only registers left to sort there).

@bochaco is working on serialising and sending payment proofs to nodes, trying various methods to keep things light.

@joshuef has been looking at the advantages and limitations of having multiple nodes per machine and options there. So far, with no optimisations, 10 nodes per Digital Ocean droplet run reasonably well (albeit with no churn), though doubling that number slows everything right down. This should allow us to have many, many more nodes in upcoming testnets though!

Thanks to input from the DiskNet and later internal testing, @roland is implementing a RecordHeader and validating the records before we store them. This also neatly allows us to separate the address space between our base data types (chunk/DBC/register) and have some custom processing there (merging register CRDT ops, for example).

@qi_ma is investigating a connection closed during data transmission issue. This may be related to an RPC address being used for data transmission when it shouldn’t be. If so, this may well be the root cause of some of the connection errors we’re seeing, as well as related issues where connections can also get closed as when dialing a peer it dials more than one of its addresses. @bzee has been digging in there.

Meanwhile, @Chriso and @aed900 continue to work on launch tools for testnets.

Away from the code @jimcollinson is once again heavily involved in market research and launch planning. He and @andrew.james are keenly examining methods to ensure smooth economic transitions during the initial stages of the Network, with a particular focus on liquidity. Now that the Foundation is successfully operating in Switzerland, this process is much simpler. Andrew is also liaising with Swiss auditors to discuss suitable accounting structures.

So no new testnet yet. But a busy time nonetheless!

Useful Links

Feel free to reply below with links to translations of this dev update and moderators will add them here:

:russia: Russian ; :germany: German ; :spain: Spanish ; :france: French; :bulgaria: Bulgarian

As an open source project, we’re always looking for feedback, comments and community contributions - so don’t be shy, join in and let’s create the Safe Network together!

50 Likes
3

First for once

So keeping double spend info, what will that allow you to do? Recover the tokens and let the sender do it right?

21 Likes
4

Second.

Wen launch party?:partying_face::partying_face::partying_face:

20 Likes
5

third. Beauty. Ants are very busy as per usual.

Thanks for your hard efforts, the goal is getting close now - we can all taste it!

Cheers

14 Likes
6

Thx 4 the update Maidsafe devs

NatNet was really great, can’t wait for the nexttestnet

Keep hacking super ants

17 Likes
7

Thanks so much to the entire Maidsafe team for all of your hard work! :horse_racing:

Also, the testnets give us all real hope in an increasingly scary world. :horse_racing:

15 Likes
8

So what’s between now and the next testnet, the large data network?

15 Likes
9

The NAT problem has been a long standing issue and it’s terrific to hear you finally being able to solve it! Great work @Maidsafe! :fire:

18 Likes
10

Next testnet will be interesting!

13 Likes
11

Prove the client maliciously attempted to double spend. That renders the DBC invalid and the sender loses his/her cash. I think this is quite powerful.

You see strict consensus says, chose 1 and only 1 and goes through hoops and message floods as well as coin tossing and so on. All that to make sure every honest node chooses the same single transaction and if there is a doublespend attempt they ignore the attempt.

I don’t like that and instead say, try if you dare to doublespend. The penalty is you lose the cash.

So for us you need to register the spend on the majority of the close group. The recipient, when spending needs to check the parent group. So then double spend needs to have 2 spends on 2 majorities of the close group. So it need to persuade a load of attackers to join the ruse. However, if ANY honest node sees the other spend attempt, they just broadcast that. As that is exactly 2 spends from the same key to different outputs, then it’s cryptographically proven to be an attempt.

Then add in DAG or Audit nodes where folk send all spends and there is another brick wall to deter attackers as those audit nodes can just broadcast the doubspend attempt as well. So the attacker not only fails, he loses his stake.

22 Likes
12

The tradeoff, as I see it, is that if the doublespend is an honest mistake, the newbie gets penalized as well, possibly to an extreme.

3 Likes
13

Better learn not to make mistakes then…

I once mistakenly put ÂŁ10 on the wrong horse in the 2:30 at Plumpton.
Did I lose my tenner? Yes
Did I get sympathy? No
Did I deserve any? No

Being pished in the bookies is no excuse, just as not double checking all inputs before any transaction is no excuse.

We can mollycoddle people too much.

Ever heard of doing a very small test transaction first?

9 Likes
14

I think the possibility to double spend is deep under the hood. Newbies will be using wallet apps, and any devs developing new things should be wise enough to try with small amounts.

6 Likes
15

But you’ll get it now… Hugs :heartbeat:

5 Likes
16

I think it will be a hard mistake to “honestly” make.

14 Likes
17

Hopefully.

4 Likes
18

It would be a hard mistake to make, it could be a bad wallet app, but then again a bad wallet app woudl likely do much worse than that and do honest spends of all your money :wink:

It will be cool to test this out and show folk how to try and doublespend and let them at it.

19 Likes
19

This mechanism is absolutely brilliant and cuts the nonsense off at the knees (or above :face_with_raised_eyebrow:) This alone makes the whole payment aspect of the network superior to anything else in existence. And that’s just the start.

24 Likes
20

Where are the thoughts on archive nodes.
Are there any special requirements to host/become one.

I am thinking along the lines of proof of stake validators. You have a stake/bond that gets slashed/fined for not doing your job correctly.

Could archive nodes perhaps have additional incentives/penalties to encourage more robust setup, battery backup, higher bandwidth, larger storage, better hardware etc.

9 Likes