Hey everyone,

first of all, where have i been for past 10 days? I didn't forget about you, so no need to worry =). Problem was that since I kinda got a bit serious with whole crypro/raiden situation I had to lay low for a bit until I get confirmation I am not breaking any of my contracts with companies I have given rights to my IP (intellectual property) or that I am bad PR to them. None of them found anything wrong so I have a green light to bring more fresh news from raiden github.

Talking about fresh news, there are tones of them, plus a little special about what is pathfinding our beloved developers are working on. Lots of text is incoming so lets keep this intro short.

"next minor release" milestone goal

First of all I would like to comment old milestone goal we were measuring progress with. I have a feeling developers gave up on reaching that goal and releasing minor release. If we look at what they have in focus at the moment and how they are working I'd say their main focus is not releasing a minor release, they want to skip that and go directly for MVP goal.

Somewhere in the development process project steered in the different direction and minor release seemed like something they don't want to be bothered with and instead they just decided to skip that part. I would not call that a failure in development process it is just that priorities changed. I would just like to make clear that MVP goal is far bigger goal than a minor alfa release.

Devs are currently going all out, new big features are being worked on constantly and I'd say the decision was correct.

EIP 712

If you are new, EIP 712 is what is keeping microraiden from reaching it's MVP.

Last week (Friday if i remember correctly) an Ethereum dev meeting took place. One of the things on the agenda was EIP 712. It was pushed on the agenda by one of the raiden devs (Lefteris Karapetsas aka LefterisJP). Importance of EIP 712 was discussed and it was decided to put some more focus into it's completion.

Since then some real effort was put into finishing it and last comment on it's github is:

In order to limit the scope of this EIP and move forward, let's just enable extensibility. Field names starting with an underscore are reserved. User-agents will experiment with these fields, and eventually standardize them in separate documents.

This basically means, lets keep it simple, finish this thing and think about extension of it in the future. Correct approach to the problem if you ask me.

I would just like to mention that agenda of the meeting was quite short and fact that EIP 712 was one of the points just shows that everybody in dev community understands importance of raiden and you can flush conspiracy theory where Ethereum devs are purposely delaying raiden progress down the toilet.

pathfinding

Pathfinding is one of the oldest problems programmers in general are dealing with. There is lots and lots of math behind it. specially the graph theory.

If you are not familiar with graph theory, it is not those X and Y axis graphs we are talking about here. Graphs graph theory is working with look more like map of public transportations in the city. So. basically there are some nodes (those would be stations in public transportation analogy) and links between them (path in analogy).

You can picture any network (internet, raiden network) like a public transportation service. Raiden nodes would be stations, if they can communicate and share information directly there would be a path between them and information are little abstract people trying to go from one station to another.

In real life people are more or less smart enough to know shortest path from their station to the destination station but in programming you have to guide information yourself. Information in addition to useful stuff (in internet that would be for example this blog post you are trying to read) have it's source and destination. It is nodes responsibility to guide that information from the source to the destination by the cheapest path there is.

Reason why I said "cheapest" is that in programming it is not always so clear what the cheapest is. In public transportation problem we know time is everything and everything is measured by it. But let's say we go to a bit bigger picture and we are in Europe on holiday and we don't care so much about time, and we decide to travel by train. In order to get some value from getting from city to city we decide that best path for us are not shortest paths in terms of time, best routes for us are trains that go trough nice landscapes so we can enjoy the nice views while traveling. But, since we are on holiday and switching trains is pain in the ass we would like to reduce times where we have to switch trains to the minimum. What is the best path now?

Those are exactly problems raiden devs are trying to solve in pathfinding repository. They don't have to compare beauty of landscapes on routes and switching trains. They are more into gas prices of transactions, number of "hops" (yes it is correct terminology, information hops from node to node) and capacity of channels in the path. They have to come up with how to best evaluate each route in terms of those parameters so it would be clear what the cheapest path is.

I hope that if you didn't have a clue what is the fuss behind pathfinding and pathfinding repository it is now a little less of enigma.

pathfinding

Last paragraph tried to explain what pathfinding is and this one will try to bring you what happened in terms of progress.

Devs are not yet sure about the formula that will exactly calculate cost of every route between nodes but they are certain what information will go into the calculation. So, they are currently working on making those information available on nodes and once they have that sorted out they will think about the exact formula.

They are working on optimizing process of obtaining that information as well.

monitoring-service

Monitoring service will be responsible on keeping an eye on the channels while user is not available to (example: no internet).

It seems they have figured out how to do it and they are in process of developing it. Issues they are currently tackling are standardizing communication between different parts, making whole thing recoverable and minor bugs they found along the way.

I'd say monitoring service is a bit ahead in development than pathfinding.

raiden

Implementation of state machine that would make raiden recoverable seems to be pretty much done in terms of logic behind it. They still have some leftovers like naming things more clear and implementing using that new feature in all parts of project (token swaps are still not adapted to new logic) but that is really minor, hard parts are done.

They plan to improve project by switching to web3, cover some edge cases etc., but I think properly finishing the state machines is currently main focus here.

raiden-contracts

One contract per token feature seems to be pretty much done (at least what I see from pull requests). It is really complex feature so I am not 100% sure on that, more like 90% sure =).

Their main focus at the moment is optimizing running and publishing contracts in terms of processing power and gas cost.

microraiden

Waiting for EIP 712 and some minor work on documentation, (ResidentSleeper for twitch people =))

rest of projects

Spec is always updating but it is reaction to what is developed so I won't cover it here.

Utilities repository is constantly expanded but nothing special will ever go on there.

conclusion

Uff more repos means more work and skipping one week didn't go in favour of it but I had to do it.

Developers are really bringing their A game lately and I would like to congratulate all of them on the work they are constantly doing (hence the top 20 position in some github research somebody did couple weeks ago). I am very proud every time I have honor to bring you information about their work.

I hope I didn't let you down too much by skipping 1 week and as always I am open to all the questions in the comments.

Enjoy!