 Welcome guys, good morning I will present to you about the radio network and how we are trying to get to a production ready payments and a network for a theorem I Want to thank Jeremy from fanfare for starting because basically what he described is very similar to what we are facing Testing trying to go to the main it So first of a little bit about myself, so I'm leftist carapesas. I have been working in the theorem space since 2014 Working on Solidity this plus-plus a theorem and some other stuff and Later, I joined brain bot as the core developer for adding network and there's the development team lead So we're going to talk about today. Essentially The current status of Raiden what we call the upcoming red eyes release Then get a bit of more technical Deep dive on the writing protocol talk about how we implement this protocol looking at the writing architecture We're going to talk about state machines very similar to what the fanfare guys are doing and then what is missing to get to production readiness So First let's talk about the current status of Raiden and the upcoming red eyes release Yeah, nice colors. So we were trying to get into a Release mode for DevCon like many many other projects, but we Were not a Lot of things came up because of the main a testing that also Jeremy mentioned So we are still on the last phases of testing the software To prepare for the minute release So the red eyes release will not be a production ready release because it will be missing some Key components which we will describe later in the talk the goal is to get mainnet feedback because Yeah, testnet is one thing but not many people use your software on the testnet and as Jeremy also said The behavior is rather different When you try your software on the testnet And we will release once we iron out most of the bugs But I guess we won't find out everything. So we will also have a bug bounty for the mainnet release So whenever we make the post, please watch out for them a bug bounty rules So now I'm going to go a bit more technical. I hope you guys are all awake To explain how the radium protocol works First of this is our The life cycle of a channel essentially People can open a channel so two participants either of them or a delegate can open the channel Then we have an open channel and anybody can deposit tokens or a delegate can deposit for either one of the Participants at this point we have a live channel and it can be used for transfers There is a lot of things that I can talk about our Protocol and the messages that are exchanged in a the happy case, but I've already talked about it in other talks and perhaps I Can just give a small overview here. So here is a mediated transfer From Alice to Dave through Bob and Charlie and the messages that are exchanged for a has time lock transfer So this is the happy path that the core of riding payment Through the payment channel network. I Want to go to a bit more interesting stuff. So essentially pending transfers So whenever you have a network like the above like we have Alice Bob Charlie Dave Ewald and Francie let's say and then Alice wants to send transfers to everyone through Bob So we send the has time lock transfer and here we see the state of the Alice Bob channel The receiving state of Bob so we keep a lock for the pending transfer and for each transfer that is going on we are putting all the locks in a miracle tree and Essentially, this is how we so all we need is the route which changes with every new lock and As the protocol continues A target like Dave will ask for the secret. So this is The pre-image that we will ask from from the initiator We will get it then send it back to the mediator and we will unlock the pending transfer and remove it from the miracle tree So This is how transfers would happen, but then at some point people would want to close a channel There are two possibilities to close a payment channel in writing network One is the happy path, which finally enough is not implemented yet You have only one transaction because both parties agree that they want these final balances and then the sign and send one Cooperative settle transaction on the chain the unhappy path Which is the adversarial one is what we have implemented right now So each party updates the contract with their side of the state of the channel and then we get to the settlement At the settlement The contract pays out the fin the finalized transfers for both parties and then we also have pending transfers So transfers that were not unlocked while the channel was closing and then we need to feed The the contract with them pending transfers how that happens we can see it here We need to involve the blockchain So essentially we have the token network, which is the the main contract that holds all of the channels and the secret registry which is essentially something that we got from the sprites paper from Patrick McCurry and At this point, let's say that the protocol continues a gets see gets the secrets from a sends it back to be But at the same time a closes the channel At this point be cannot continue with the protocol and has to go on chain What can he do? He has to prove that he knew the secret in time So he registers it in the secret registry contract and we have the block at which the secret registration happened so he can prove that He was aware of the secret on time then the protocol continues and as we discussed before so the Bee will have to update his side of the channel, which is essentially the mercury and the monotonically increased transferred amount Sorry Yeah, so someone This case be can call settle or a delegate can essentially settle the channel and this will pay out however much was owed to a and however much was owed to be from the finalized transfers and then we have to If they are big enough deal with pending transfers because this is another on-chain transaction so Bee will take his mercury, which is essentially like this whole thing and Send it to the token network and the token network would take from the secret registry where it's of the pending blocks Were registered and what will happen is that it will pay out Transfer one to be and transfer three four back to a So in conclusion what happens here is that be will receive transfer one because he Actually knew the secret and the register did on chain But transfers three and four will go back to the initiator. So a because the protocol didn't continue until the end So that's a few things about the protocol. There are a lot of more messages we can go on and on about but I would like to speak about What so how we are building this so what is the architecture that we are following for the right and client? Here is a very very high level overview at the core of a right and lies state machine and essentially Everything generates state changes that are fed to the state machine So like the transport layer gives us the state changes polling blocks and events will give us state changes API Calls will give us a sentence. They will all go in the state machine generate a new state and I also external events because there should be no side effects inside the state machine And we also log stuff in a database a Bit more details about this. So the state machine is a differential state machine. So essentially we It's just a simple function that takes a previous The current state state change and generates a new state and must have no side effects We save the state of all known channels in the database and that allows us to be persistent Which means that if right and crosses or if somebody starts it then whenever we restart it will be exactly the same status before This something that took us quite a bit of time And with the state machine we have improved the stability Because you can write unit tests for each part of the state machine and test State changes individually So how does the state machine in the database which we it's essentially right ahead log That's what wall stands for interact so Everything is a state change in writing, but before we do anything we log every state change inside the database After it's locked then we dispatch it to the state machine And that generates the new state and some internal events. So internal events is anything that has side effects. So and on-chain transaction and off-chain methods even just Making an entry into the debug log So this loop continues and continues and this is the how writing works At some point we take a snapshot of the state and put it back into the database and that is an optimization because When we want to restart after after a crash, let's say what we will do is we will have to replay all of the state changes To get into the same state that we were before and that at some point Let's say if right and was running for four weeks Would take quite a bit of time and as such we start by requesting the latest state that was snapshot it and Then we start and replaying the state changes since that snapshot Going away from the state machine, let's talk a little bit about the transport layer So since we deal with off-chain messages, so we receive and we send Messages to our channel partners. We have to have a specific transport layer Our architecture is transport agnostic in By design. So it's just a common interface of send receive and we can have pluggable transport layers. So We started with UDP, but We had a lot of problems due to not punching and we have now switched to using the matrix protocol So what is matrix and why are you are we using it? There is a blog post that you can check in writing network Medium account that has a lot of details about why that choice, but I will just go through some of the main points So it gives us a reliability As opposed to UDP transfers, you know that when you send the matrix Messages it will arrive and it will reach its target All connections start from the client to the server through HTTP long polling And that allows us to go around all of the NAT problems That may not sound too important, but when we were using UDP only Half of our issues were about the network configuration of the user and we ended up dividing network configurations Another good thing about matrix is that it uses a federated server setup. That means that we Don't have only one server, but it's a federation of servers And all messages are federated between the servers So if let's say one matrix server goes down, the protocol doesn't go down with it And it also gives us encryption out of the box So which are the entities that are starting the writing transport I want to give a big thing to my crypto to digital virtues to exchange union and to ki decentralized Because they are the first people who are running a matrix servers To help boost up the transport network of writing If any of you are interested in actually running a matrix server, just talk to me later or send us an email So we also have a rest api. That's how most users Interact with the writing client. It's very simple just exposes through rest api endpoints all of the basic functionality Let's say open channel close settle make transfers We also have some debugging endpoints through which people can give us their events And we can debug what's happening But most importantly, it's a work in progress. So an api is meant to be consumed by developers So it's made by us. We are also developers, but we don't have enough feedback yet So we have some kind of assumptions about how the endpoints should work Or About even the hierarchy of of the url endpoints. So please guys if you Want to play with writing test it use it and tell us if endpoints are Make sense or if You will need more endpoints less endpoints, etc We also have a user interface. It's just a web UI. You can go to this link of the qr and see it We have a video that is made by my colleague Christopher It's very nice. It explains how you can use writing through the web UI Essentially, it is just Showing you the Rest so it's just a Layer over the rest api So the next section, which is pretty Interesting is how can we achieve production readiness? What does production readiness mean? So as Jeremy said testing is is hard and Especially testing a protocol implementation is really hard. So we have been trying We had a lot of tests on on the testness so coven and rinkaby And then we started also testing on the main net and then things blew up like completely So you have a payment channel network, which Has a lot of moving parts has time logs. We have a separate transport layer And this is layer two and then you have layer one and we rely on really one layer one working correctly which Yeah, sometimes it doesn't like we're building software on top of something that's still experimental I would say Jeremy mentioned a lot of things about gas prices Yeah, we saw that like in the main net especially We have confirmation block. So five blocks of confirmation for reorgs that makes the user experience Terrible, but gives us safety Because it is an automated protocol that has to send transactions and once they are sent You have to assume that their mind or else everything breaks Because the protocol is just not followed. So basically exactly what Jeremy said before What do we do for testing then? So we have of course like most others A suite of automated tests We use Travis at this point. Maybe we will switch to something else since it has been pretty unstable for the past months Our cumulative the cumulative time is around three hours the test suite But we have parallelized the jobs and it takes about 50 minutes It covers a lot. We feel very confident when it's green, but it doesn't cover everything So My colleague Ullo made a new tool. We call it the scenario player essentially unlike them Continuous integration system that spins up a new private test for every Test run this uses existing test nets or a private test net And through a YAML language essentially create scenarios like you open 10 tunnels and 100 transfers in the meantime kill nodes restart nodes and Check if things if the balance is check out at the end And what is good about this is that even our non so tech Oriented colleagues can write scenarios here because it's a it's YAML. So it's it's pretty readable And the best thing that we The manual testing we have been doing a lot of manual testing. So clicking buttons on the user interface Making scripts that spin up nodes make hundreds of transactions kill stuff restart stuff In order to find bugs and we have found quite a bit of bugs So a lot of things go wrong when doing stuff like that on the mainnet Soon we would like to in order to feel more confident hit the state machine with fast testing essentially All of this is probably Not optimal. So the best way to Test a state machine would be to just feed it random but valid data And see if it breaks if you get into an invalid state, you have a bug So that's what we plan to do in the future for for testing So, um, we talked about what we have right now and what is coming with Veridice mainnet release, but we said it is not production ready and I cannot state this enough So what what is missing to achieve this production readiness? Um, first of all fees, right? So you would think that the payments and network has fees by default We we will not at red eyes Our production ready list will of course have fees But since we are trying to go and build incremental software that works, uh, we have scoped fees out for the mainnet release Of course, why are fees important? Well, I mean You need fees to incentivize mediation of transfers And also with a proper fee model, we can also Have a incentives to have a balanced network Another thing that will be missing from red eyes will be monitoring Patrick will talk a lot about this in the pizza talk later But what it is essentially is that if you go offline For an extended period of time with our defaults, it's more than two hours So it's not like if you just go offline, you lost money You just need to be offline for more than two hours Then you are in the danger zone of your partner closing the tunnel and basically, um, you're not having enough time to, um Claim your funds out of the tunnel So we will have a monitoring services that, um, we'll be looking at your tunnels and if something, um So if your partner acts while you're offline, they can take care of it Um, finally, um Uh, at the moment we have suboptimal routing, um, because, uh, when we create, uh, The route to the target, we only know, uh, the initial capacity that was, uh, the positive to the tunnel And we create, uh, the route to send, uh, the transfer through Using this, um, assumption Uh, in reality, you know, it's a, it's a moving network, uh, capacity changes all the time So we need to be able to, um, know the current capacity Our solution to this is to use a third party service. We call it the pathfinder And he will have a current view of the tunnel capacity because, um, nodes will be incentivized actually to send them Send to the path, uh, pathfinder helper capacity updates Um, so whenever you want to make a transfer, you just, uh, query the pathfinder What is the optimal route and then you send it, uh, that's very good because then You will get the optimal path so it will cost less and also, um The pathfinder will also, uh, give you, uh, a route that will help keep a healthy network So, um, you can, you guys can try it. Uh, we have a release every week, actually Preparing for the, um, for the mainnet everything is right now on the testnet all three testnets We have, uh, the contrast deployed so robsten, covan and rinkabee Um, and, uh, watch out for the bug bounty Whenever we, uh, finally make the red eyes mainnet release If you want to have a lot more, um, fun with riding and, uh, get into it and, uh, use it in a hands-on workshop My colleagues, uh, Jacob, Ulo and Paul will be hosting, uh, hands-on riding workshop, uh, from 1 p.m. To 3 at the micado room Uh, I will also be there. Uh, I think that the entire team will be there So you guys can just come interact with us and, uh, see how to use riding So that's all. Thank you. Uh, if you guys want more information Just follow us on twitter at ride and network Uh, take the website or just follow me at lefteris.jp Thank you very much