Routing in the dev updates over the last few weeks. Read from top to bottom for chronological order.
Routing & Crust
We are continuing with the work of figuring out an approach to deduce a consensus order of observed network events from a Directed Acyclic Graph (DAG) which was composed from the gossiped messages. We do have a solution that is not available as open source right now and we cannot use that exact algorithm. We have some test code in a private repository that we have working and will progress this to an open solution. We just published a blog post regarding this, you can read it here . So on to the good parts, this ordering consensus algorithm for intra section membership changes is nice and modular as well as mathematically proven. This means less code, less testnets (many testnets were to find all the rules regarding order, which have grown in complexity (although works)). We cannot say this is definitely the last unknown as we have not detailed network restarts after complete collapse or network managed upgrades amongst others, however this is a large step and one that allows us to much more clearly see the remainder of the features for a full-featured network, or in other words Beta. Much of the work (and there is an awful lot) is currently hidden here, but will be exposed very soon. We ask for a little patience with us in Routing for the next few days and possibly weeks. If this pans out then it will be very much worth it and you may find us able, at last, to give reasonable estimates of remaining development work. This does not mean detailed roadmap with timelines, but we will have a very clear route and make it clear which tests we wish to do, most of which will be in client APIs, language bindings and platforms.
and…
The Routing team is currently split into 2 teams looking deeper at consensus ordering. One team is looking at an improvement to an algorithm we have for that and the other is integrating an ordering algorithm in Routing itself. This work is looking at node added/lost, section split, merge, chain management and purging as well as secure message transfer (inter section messaging). The teams are pretty motivated and seem to be enjoying the certainty of the results as well as the reduction in conditional statements and timers in the Routing codebase.
It is really comforting to see the simplification and easier to understand algorithms in Routing. For too long that crate has been too complex, proving difficult to get Engineers familiar with it all. This is quickly reducing a huge barrier to entry and that is great for us as MaidSafe but amazing for the project itself as we hope these advances will allow many more than MaidSafe Engineers to work on the core and this is important to us all.
and…
And…
The Routing team is currently following two parallel promising leads to solve the issue of eventual consistency in the network in a robust way, this is in addition to our existing approach which is being integrated into Routing by one of the teams. This is exciting as more and more timers are being replaced as the algorithms in Routing become much more asynchronous and natural. We are hoping that we can remove swathes of complex code very soon and that will be a great step and one that reduces the requirement for so many testnets as we previously mentioned.
And…
And…
These ones are the most interesting IMO:
This work is looking at node added/lost, section split, merge, chain management and purging as well as secure message transfer (inter section messaging).
So on to the good parts, this ordering consensus algorithm for intra section membership changes is nice and modular as well as mathematically proven. This means less code, less testnets (many testnets were to find all the rules regarding order, which have grown in complexity (although works)).
But we’ll see on Thursday. It is great news though, and if you read the last few quoted lines you probably understand why this news is bigger than Alpha 3.
20 Likes