Summary
Here are some of the main things to highlight since the last dev update:
- We made the sn_fs GitHub repository public and encourage the more technical members of the community to try mounting a filesystem.
- The
sn_api
repo is now building against our updatedsn_client
. - Node and Client integration work took another leap forward with, amongst other things, a PR introducing
DebitProofAggregator
to complete the work for AT2 Transfers client-side, meaning the code for a secure and successful money transfer would be considered done when merged! - There was some great refactoring progress in
sn_routing
this week, with the prime benefit being that we are now able to quickly and easily bulk up our test suite.
CRDT
sn_fs
This week the team kicked the tyres of the sn_fs PoC a fair bit on Linux (Ubuntu), and a couple of brave souls even tried it out on macOS. One minor issue was identified and fixed on Linux. Unfortunately on macOS, several issues were reported that are not yet fixed, so we do not yet advise using it on that platform, although it does build and run, and some basic functionality did work. The code cannot be built for Windows at all yet.
Nevertheless, this week we are pleased to make the sn_fs GitHub repository public so that technical members of the community can build it and try it out and/or review the code. Build and mount instructions can be found in the readme. Please report any issues in its GitHub issues page with all the relevant details.
A reminder: sn_fs is a proof-of-concept to demonstrate that crdt_tree is viable for building a local caching filesystem. As such, there is presently no networking and no integration with the Safe Network itself and everything is subject to change.
Safe Client, Nodes and qp2p
Safe Network Transfers Project Plan
Safe Client Project Plan
Safe Network Node Project Plan
This week we’ve been updating the sn_api
crates (api
, cli
and authd
) with the massive changes we’ve seen from sn_client
. A lot has changed there since it was safe-client-libs
, including messaging and data type naming as well our transfer system. It’s been quite the batch of changes but the sn_api
repo is now building against our updated sn_client
and we’re ensuring tests are all in a good place for when we have that client fully functional against the nodes.
On the integration side of things, Node and Client modules have seen multiple fixes going in this week. With PR#245 in sn_data_types
merged, a handful of bugs were fixed that affected the Node regarding IDs, keys and message signing. These changes were reflected in Node PR#1128 and Client PR#1271. Once this is merged, Clients will be seeing a bit more action with the introduction of DebitProofAggregator
, which completes the work for AT2 Transfers client-side. This is the last piece in the Transfers puzzle that is required to accumulate and aggregate SignatureShares from section Elders to produce a DebitAgreementProof
for a secure and successful money transfer.
Looking ahead, once the above PRs are merged we should see more than half of the e2e tests going green right off the bat. With a few minor fixes and cleanups we will increase the stability of these two crux modules to work in sync. Next steps after fixing the remaining test suite issues is to expand the farming integration tests, complement the whole set with chaos testing, and integrate these updates with the qp2p IGD updates that were mentioned last week (which re-enables the “Nodes from home” concept)…then freeze the code for a testnet!
Routing
This week we continued refactoring routing in order to make it simpler, easier to test, and easier to reason about. First we landed a PR that removed the somehow confusing FullId
and PublicId
types. We now use more industry-recognised PublicKey
, SecretKey
and Keypair
instead. This was followed up by another PR to clean things up a bit more. We then landed another PR which refactors the internal logic using a command-driven paradigm and which allows us to re-structure the code into a couple of small, self-contained and loosely coupled components. Most importantly, it makes the code more easily testable. We already wrote a bunch of new unit tests using this approach and they were a breeze. This is quickly closing the test-coverage gap created by removing the old mock-network based tests which were too complex and unwieldy.
On the CRDT front, we continued with testing the PoC code we have for section membership data. We were creating different tests and fixing issues we discovered along the way. We are now looking at and trying to understand the effects of some more complex scenarios when it comes to section churns, and how we can deal with them, using CRDT logic. Thus this is where we’ll be focusing in the next few days by creating some tests which can reproduce these scenarios and finding a solution for them.
In parallel, we are starting to look at how the new CRDT-based membership data can be integrated into the routing codebase and its business logic, which implies finalising the internal APIs of our PoC code.
Useful Links
Feel free to reply below with links to translations of this dev update and moderators will add them here:
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!