Summary
Here are some of the main things to highlight since the last dev update:
- We continue to move all client messages definitions, and serialisation logic, to the new sn_messaging crate.
- Work to remove
streammanagement in nodes, as mentioned in last week’s update, has been completed and merged - We’ve been working through and fixing the issues highlighted by our new routing stress-testing tool.
-
A massive shout out and thank you to a couple of community members for PRs this week - @mav and @tfa both chipped in with multiple PRs across different repos to help out and improve our work. Always inspiring to see
- We’re still working away testing a final bug resolution that we hope will mean that we can release the next iteration of the testnet.
Safe Client, Nodes and qp2p
Safe Network Transfers Project Plan
Safe Client Project Plan
Safe Network Node Project Plan
Over the last week, we spent some more time improving the qp2p examples so that they better demonstrate the library’s features separately. Along with this, we extended the echo service example to support manual port forwarding. While implementing this, we identified and implemented a small extension that verified the endpoint provided by the user as input. This allows us to return an error much earlier instead of waiting for the network to identify and report the node as unreachable.
We also continued with moving all client messages definitions, and serialisation logic, to the new sn_messaging crate. We’ve improved the protocol and we are now using Msgpack for serialising all messages that are sent by clients to nodes. This is an ongoing task though, as some inner parts of the client messages are still using the bincode serialisation and we therefore need to migrate those to also use Msgpack.
Work has continued with the distributed actor transitions at elder change, i.e. signing over the section funds to the new elder constellations. A small bug hindering the transition (due to failing sig validation) has been taking some time to root out but has just now been found. Next steps in the transition are now to be tested.
Lastly, we’ve been progressing with updating client/node to remove client challenges and to re-enable proper onboarding of clients, after the work to remove stream management in nodes, as mentioned in last week’s update, was completed and merged. This in turn has turned up some potential issues in client message receival or parsing, so we’re digging in there.
API and CLI
This week we were able to successfully generate musl builds for CLI and authd in our CI, and therefore it’s all setup and ready for our very next release. This means both the CLI and authd applications should be compatible with any Linux platform out of the box from the release package, we’ll need the community to help us validate this is actually the case though by trying it out on as many different Linux platforms as possible. We’ll release the new versions in due course.
BRB - Byzantine Reliable Broadcast
Work continued this week to further polish the BRB crates. The DataType API was changed so that validation error details can be returned to the caller. Further along these lines, the rust-crdt crate has been enhanced so that each CRDT type we use now has a validate() method that can be called prior to applying an operation. Pull Requests for CI/CD (Continuous Integration and Continuous Deployment & Delivery) have been made for each BRB crate. We have a few more changes to finish up this week, after which we plan to make the first release to crates.io.
Routing
Last week we mentioned how the stress test tool uncovered some hidden issues in routing. This week we set out to track them down and fix them. One issue was that non-elder members of a section would not know that a split happened due to a bug in how the Sync messages were created. This was fixed and merged. There is another PR currently in progress which fixes a couple more of those issues. The remaining issues after that are probably all related to the way we handle section membership changes. We hope to resolve these by integrating the new BRB membership algorithm that was also mentioned last week. This work will start very soon, possibly as soon as next week, if all goes well.
Similar to our recent move to have all client messages definitions and serialisation logic in a separate crate (sn_messaging), we started looking at doing the same with sn_routing messages. The goal is to be able to separate all the message definition and serialisation logic, from the core routing logic. This should allow us to have a clear definition of the interface exposed by routing services, and therefore how any implementation (in any programming language) can be made compatible with our existing sn_routing implementation. We are in the very early stages of this process, but wanted to share our goal here.
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!
looking forward to test net!
and 
