Just a quick progress report this week as we find ourselves across lots of jobs again, with no major new tool, development or idea to report.
Thanks for the comments on the payment-only network. We are evaluating this carefully from a technical perspective but also strategically. Close coordination with our legal team is required, so we’ll keep you updated as discussions progress.
We’ve been testing the stable set architecture using stateright and so far so good 
. We’ve modelled the simultaneous loss of all seven elders and subsequent promotion of seven adults from the stable set. Stateright takes quite a while to grind through 160 million-odd states, but none of those is a fork, which is very encouraging. We’re not out of the woods yet, though, because while membership seems solid, functionality built on top of it may not be. So that’s the next step.
@Oetyng has been using this period between major jobs to do some spring cleaning and refactoring work. One of those is integrating reward keys into sn_node. The previously used ed2559 reward keys, which were stored in ~/.safe, cannot be used with DBCs as they are now. So we have updated them to BLS keys and added them to the node info, and - importantly - to the structure that is voted on in membership. The elders must know the reward key of a node so that they can validate incoming payments and verify that the transfer/store cost is paid to the nodes.
Later work will see:
- Elders included in outputs when spending DBCs.
- Elders confirming that spends contain outputs destined for them.
- Implementing a commonly known deterministic transfer/store cost and distribution to nodes.
- Including transfer/store cost in outputs when spending DBCs.
- Elders confirming that the amounts in those outputs are sufficient.
He has also removed the ambiguous ‘peer’ concept, where clients and nodes were treated the same for messaging purposes, creating a clearer path for client and node related logic. This is a long due change, and with reward key integration the use of reward key as part of a node makes much more sense.
Also working on DBCs is @anselme who is looking again at payments now that the earlier RingCT design has been deprecated. Much of the previous code for payments should be usable and he is sorting through that now.
@roland has completed a course in OpenSearch - the platform we are using for telemetry.
We are still seeing bugs when nodes fail to join, and @qi_ma is on that one now.
Mostafa is fine tuning the consensus algorithm to ensure that all proposals are accompanied by supporting evidence.
@Chriso continues to simplify the CLI and remove wrappers and unused or unhelpful commands. Now’s the time to shout if there’s something you want to see in the CLI. Please use this thread for suggestions.
And last but not least @bochaco is upgrading Quinn and all dependencies of qJSON-RPC. He’s also looking at gRPC, the remote procedure call framework originally created by Google, since it seems inevitable that this is the way things are going with support for HTTP/3 & Quic. It offers many advantages over qJSON-RPC.
Useful Links
Feel free to reply below with links to translations of this dev update and moderators will add them here:
Russian ; 
German ; 
Spanish ; 
French; 
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!
first
