Update 07 October, 2021

We introduced the idea of the Client writing the Spentbook a short time ago, and have been putting our heads down since then to work out the best way to implement this. This week we’ll explain our thinking so far.

General progress

Some successful bug bashing this week. @Chriso has got the CLI / API tests working properly, meaning the sn_cli / sn_api / safe_network combination is now more or less stable. In fact, the CLI and API are now ready to be merged into the main repo, which will mean no more hassle with having to combine compatible versions. :tada:

On that note it’s fantastic to see folks getting stuck in with the community testnet. Kudos to @josh for getting it off the ground. It flew for a while, which is good to see, and most importantly the log files it generated are a big help with our bug hunting, so thanks for sharing updates so far!

@bochaco has been working on some debugging tools that reads nodes’ logs to check that each message received is being processed to completion. On receipt of a command, a node should (a) do as instructed or (b) return an error, but occasionally they sit and do nothing which (c) can cause odd bugs or even (d) effectively lock up the node. Using this tool they have tracked down and fixed some possible culprits and so far the situation seems much improved. The same analysis can be used for the rest of the team’s bug hunting too, including @yogesh and @qi_ma who are investigating similar occurrences of deadlocking (endless loops) happening with internal commands. We plan to integrate this checking tool into the CI process.

Client Writes Spentbook

Before spending a DBC the client must create a Spentbook entry. This is an immutable data item stored on Adult nodes on the network that contains details of the desired transaction and ensures that once the transaction (DBC reissue) has occurred, the same DBC cannot be spent again.

In our current thinking, the flow goes like this:

  • Client creates Spentbook entry and signs it with its public key
  • Client sends the signed Spentbook entry to all 7 Elders in the relevant section
  • The Elders write this Spentbook entry to the closest 3 Adults to its address
  • The 7 section Elders sign the Spentbook entry with their BLS key share and return it to the Client
  • Provided the Client receives at least 5 such messages (a supermajority) it combines the BLS key shares to create Spentbook signed by a valid section key. At this stage it is called a Spentproof
  • The Client can now ask the Elders (which also run the Mint software) to reissue its DBC. It sends the DBC together with the Spentproof back to the Elders who now sign the reissue.

This process has a lot of attractive features: the network is not involved in the complex process of holding state (current information about account balances, etc); the Client does the hard work; the number of messages back and forth is acceptable; and it should be reasonably simple to implement without any major reorganisations or refactorings.

We’re still working through questions of auditability (proof of payment, etc) and optimisations, but this is the basic structure of how we avoid doublespend.


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!

62 Likes

Oo i’m first !

Can’t wait for the next official testnet! (with arm support) :slight_smile:

Seen it from the sideline - awesome work @Josh

29 Likes

You beat me by 2 seconds lol :wink:

13 Likes

Thank you for all your hard word, dev folks.
Thanks also to @Josh for having a go with the community network. I was not able to participate as fully as I’d hoped but intend to try again ASAP.

A neat explainer on how the Spendbook works - thank you. Simple and elegant, lightness and strength have been added, complexity and weight removed. Colin Chapman would have approved but unlike so many of Colin’s creations this baby WILL last not only the race for one driver and team, but many many years of productive work for us all.

18 Likes

Thanks for the update Maidsafe devs

Third beat @Southside to it now read.

Lol southside beat me to it, now really read

P.s.

Wow this is amazing news :clap: :clap: :clap: :champagne: :beers: :clinking_glasses:

17 Likes

Or did you :slight_smile:

9 Likes

No podium place for @19eddyjohn75!!! Sorry :slight_smile:

8 Likes

@Josh is die Antwoord! Respek!

12 Likes

I like the ambition but you need to work on the delivery!

13 Likes

If your not first your last :joy:

11 Likes

Thank you for this!

26 Likes

Nice update…

15 Likes

Thanks so much to the entire team for your wonderful update and all of your hard work. :racehorse:

16 Likes

I think it is obvious but it needs to be said that without @chriso and @joshuef’s guidance there would have been no community network. Thanks again for your time and help! :grinning:

32 Likes

Cool progress, cannot wait to see it working on the next testnet!

19 Likes

Just wondering what happens if (actually when since it will happen sometime)

  • section splits during this process OR
  • the client takes enough time for one of 5 elders to go offline?

Can the client restart the process or ???

14 Likes

Yes, that’s no problem, just a retry of the whole sig with the new section key. Ae makes sure you get a new section key and the client can see that plus the new elders to connect to and restart.

18 Likes

I just want to know that " is all development is completed including farming and maxwell" i heard in telegram group.
No offense

No. Still in Fleming stage. Maxwell development comes after Fleming.

1 Like