As Ben mentioned in his last week’s update, one of this sprint’s biggest objectives was to implement Unified Structured Data into routing. One of the reasons we refer to it as ‘biggest’ is because it changes how upper layers interact with routing and so it also changes routing’s API. This means that we were not able to think in terms of individual modules anymore, but had to put our heads together with guys from Vault and Client to make sure we’re on the same page.
But there have been other big changes, less visible to the outside world though still very significant, from both a security and code reduction perspective. Previously, our messages looked something like this (header, (body, signature)). Now they now look more like this ((header, body), signature). Blink and you may miss this change, essentially the header is now part of what is signed.
Although it may not seem so, this change is a huge one. Previously, we knew we could not trust the header so our algorithms had to account for this fact. These changes caused us a little code depth which we knew we’d need to deal with sooner or later. On the other hand, last weeks refactor changed this and we can now happily report that all messages are now fully cryptographically signed.
Another big objective of this sprint was to plug Sentinel into Routing. As a reminder, here is a short description of what Sentinel is all about: In a decentralised network such as SAFE we cannot trust individual nodes, because anyone who knows how to use our protocol can become one. Whom we can trust though, is a set of nodes which are picked by the network if they’re all telling us the same thing. We call such set of nodes a ‘close group’. Now, imagine that such a close group sends us a message. What we see internally is a set of messages each from an individual node. It is then the purpose of Sentinel to ‘group’ such messages and validate that they really came from nodes selected by the network, then present the result to the upper layers.
So back to the objective, the plugging itself is not done yet, but a big chunk of refactoring was done for it to be possible. Just to sketch the idea, imagine again that a group entity sends us a messages, that is, we receive a set of messages, we had to identify which pieces of each such message are not changing and only make those part of the group message (we came to call these pieces ‘message invariants’). With this done, we will now be able to quickly move forward and resolve two other issues as well, namely code reduction and switching to a channel based interface as opposed to dynamic dispatch interface [1].
As far as the sprint and other libraries go, since week two, we’ve managed to stay ahead of our progress estimates. CRUST library concluded its work for this sprint and we are working to resolve a final issue for the OSX platform. DNS crate has also concluded its work yesterday and we have verified everything works as expected against the mock routing layer, so a very positive sprint all round. Testing against the live routing nodes should commence in the next few days.
And to be complete, here is also the update from Justine.
[1] Dynamic dispatch interface has the disadvantage that it is single threaded, blocking routing code until the dispatched code finishes. With the channel interface, we just insert a message into the channel and continue right away thus allowing for better parallelisation, enabling multiple actions to happen in tandem. (This is a nice introduction to this approach).
