Hey everyone,

one by one and we are on lucky number 7. In terms of disclaimers nothing changed, so I won't bother you with that part. For this week's post I prepared a few special treats: first I want to warn you guys about MVP hype abuse, second I did some investigating about EIP 712 and microraiden, last one is explanation of significance of "one contract per token" in raiden project. I hope you guys will enjoy reading this week's post as much I did writing it.

MVP

First subject I want to cover is what is MVP in a project. MVP (Minimal Viable Product) of a project is a goal in a process of project's development where all basic functionalities that a project should cover are working. Sometimes MVP is called MVR (Minimal Viable Release), you can pretend they are basically the same thing.

Reason why I want to discuss with you guys this subject is fact that last couple of week's some of projects that are working on Ethereum scaling released their MVP.

So, how exactly is releasing of MVP abusable? Well, since team working on a project defines what is MVP of their project themselves, they can set that goal very low, so they can quickly reach it, and then start hyping the project by saying they got very far and have a working MVP.

I must immediately say that I didn't go trough other scaling solution's code to see are their projects really "MVP worthy", but I just wanted to tell you guys that if you read a headline stating that some project released MVP it does not have to mean they are very far. I suggest you do your own research and try to figure out if it is really an MVP or they are trying to bring some attention to themselves.

If we talk about microraiden and raiden MVPs, I can tell you that they set their goal pretty high, meaning they want their MVPs to include almost finished product ready for general use. That is why microraiden, that is currently waiting for EIP 712, even tho they have pretty good workaround using Metamask is still not in MVP state.

You can compare releasing of MVP to "early access beta" game releases gaming companies do.

microraiden

If you know anything about microraiden development you know they are waiting for EIP 712 to be merged (you can read more about it in my last week's post).

There were lot of questions in comments about how much work is there to be done on microraiden once EIP 712 is merged. I did a little research and I have good news. For them to switch from Metamask workaround to using EIP 712 should not take more than a day of development. After that they will need to test the new implementation, release it and so on but that is what every change goes trough, so no big deal. You can picture that switch like unplugging old RAM from your PC and plugging in a new one.

Other thing microraiden devs are working on is documentation. They are taking their time on that. Might be because that documentation will include both projects, they want to wait before all the big changes are merged to raiden. Other reason I see is big switch in focus from microraiden to raiden, so devs are working on raiden and not bothered with documentation.

raiden

Raiden github is on fire last couple of weeks. In last week's post I talked how they merged a lot of "foundation" code and we were expecting "business logic" code to be merged in next couple of weeks.

Team's main focus are last 3 big issues in current milestone goal. Last week's post covered 2 of them by explaining what are state machines and how they will help project's stability.

On the beginning of the week they merged some of the code correlating those issues. More pull requests are currently waiting to be approved and merged as well. Reason why they didn't do it last week is because those are some really complex changes and they want to wait for approval of other team members before they do it.

There is a pull request for the third issue as well. Team is actively making corrections to the implementation and I think they re pretty close to finishing it. Issue is called "switch to one contact per token".

So, why are they doing that switch? Currently, Raiden implementation deploys one contract for each channel it creates. Even if the contracts are not very big, it's very slow to do that, while all the logic is shared between all channels, and only a couple of stored data fields distinguish one from another (receiver, sender, etc). This approach allow each token [network] to choose if and when it wants to upgrade, and maybe if needed, even implementing slightly different logic for it's own network (e.g. erc777 tokens, different interface, etc). It is a great upgrade and microraiden already works this way so it is proven good approach to a problem.

conclusion

microraiden - docs and waiting for EIP 712

raiden - lots of work around 3 last remaining issues. Everything is ready and waiting to be merged to code.

This is all folks. As always I am very grateful for all the positive comments and I will try to answer all of the questions best I can, so don't be shy. I hope you don't mind me referencing older posts. It should be pretty easy finding them so if you missed something you can ketchup (I just had to do this pun).

Have a great week!