 So, we have a pact to have our session for the day about state tellers. Seven teams talking today and we are through various activities in parts of the puzzle. It's going to be very, very exciting. I've carried on from there, working on the stations for the three years now. This is for the core technologies with our particular stations recently. We've been working firstly with the other teams over the last two or more recent times to try and to bring some standardisation to this process. I think that hopefully if I'm going on as a guide, this is what we've got out today. So, that's right. I'll form Magnum next itself and finally be grateful to wrap things up for us. Certainly, all of the top sectors joining the state-owned group with the amendment to producing a standardisation across the teams. We've all over the years developed the technology independently and we've come in together to try and do some standards so that it will be easier to develop words of the URI and other companion applications and technologies such as these we're doing, and what we're doing out of the army. And the way that we prefer is looking forward to seeing how that comes together in the next few months. So, I want to give you a quick oversight and do an introduction to the state channels. I'm guessing it's the most few of these polls there before we dive in. So, you can express this in a number of different ways but I've really hit the state channels already. A combination of protocols and techniques that allow two or more participants to execute a sequence of complex transactions between each other off-chain while retaining the security properties of the underlying blockchain. So, it's a their-to-use solution. What the fundamental means is that we're a theory, we have the security properties of the chain, we know how it works, we know why it works, it's a decentralised manager, and we know the cryptography underneath it. But we can use sequence of techniques to mean that we don't have to agree to pay the gas and support the transaction to the mines in order to get any smooth process flowing between individuals. This is a general explanation. There are variations on this. It's generally true to all more participants. You generally commit, before you start a state channel, to commit some funds on the chain along with any particular properties of what it is that you want this state channel to be about, what are the rules of that channel, and the initial states of the channel. And then participants rank directly with each other off-chain, advancing the state of the channel via choices that they make, following the rules of the channel and signing commitments as they proceed. And once they find out that another channel is determined and agreed by the participants, on-chain transactions to make again, this releases the funds according to the outcome of the state channel. So, the simplest working example of a state channel with just two participants, just sending in funds to and from each other. So, we've got two participants out of the group here, and they commit some funds into a contract on the chain, a GTC contract in this case, and we have an initial state where they both have five, and then if Bob sends one to Alice, Alice has six, and Bob has four, then if Alice sends four to Bob, she makes seven, etc. These are a series of transactions that people are making and signing, so we end up with a final state with the way that the funds are distributed that goes back onto the chain in his mind accordingly. So, in this case, the state of the channel has just been recorded, which funds. So, we need to do not just perform more complex interactions, we need a state-of-the-chain. So, the state-of-the-chain is a term to be around if you decide to go from the years, and it pretty much defines what we can do in a state-of-the-chain. So, I've always used this definition, and they're a bit of an example that they can come down to the same thing. So, the state-of-the-chain is a function, or code of the function advanced state. A state represents where we are and will. It takes an action on that state, which might transfer something, or press a button in a video again, or whatever it may be, and it produces a new state. So, it's a linear process of advancing new states. The function is also deterministic, and it has no side effects. So, by deterministic, I mean that if every time you play this action to this state, you get the same new state. This is a vital important part of the state-of-the-chain, as you'll see later when we talk about security. And there's no side effect. It means that everything you need to run a state-of-the-chain is in the state. It's entirely self-contained. And any application that can be coded using this technique is a habit of the state-of-the-chain. So, we're going to talk a little bit about an example of this over the first sort of few talks. So, we picked one of ours. Let's see if I can get this to work. I will talk over this video. This is just an example of a study channel sort of actually working from a new experience point of view. So, choosing how much this is the properties of the channel. So, I'm choosing how much funds to open a channel with, and signing a transaction centre-of-the-chain. So, while this is a video, I don't know if it takes ages soon. So, you might see this here, the other counterparty, which is the housing arc. In our case, for example, there's also science and transaction. It's also committing funds to the chain. So, this is the set-up phase. They've been very badly with this. Let's see if I can speak on a little bit. Right. So, when the chain is open, we have the ability to play our game, which is advancing state. So, as a player, in this case, we can make a sequence effect. And there's a random number of process here, which we'll talk about a bit, which determines the outcome of the winnings. And each time that the ball is spinning, you can go down to this corner, you can see this is the balance, this is the player, and the house is the two people in the channel. And these balances change as the game progresses. So, each of these, I think we're trying to think about it now, and I don't know if it was five records since the state of transition. And then we'll talk a bit more about that. And then, when we get to the end of this, this is just a step back. We're referring to this contract. We will want to close the channel. So, inside the transaction, which is all this is going on standing behind the scenes here, inside the transaction it says the end of the state, the end of the channel, is according by the two participants, I have this part, and the house has this part, and it says that the transaction was marked on the chain. So, in order to look at this work example, we need to still want to say that this is sort of the first part of the session it's all going to be about. We need to implement the rules of this game in a state of change. We need to establish protocol for orderly state transition as the game plays out. We need to implement security against bad actors or missing actors, actors of people who stop participating in the channel. We need to talk about how channels are funded, and how you're going to come on the end of that. And then we're going to talk a bit about user interface this time. And that's pretty much the introduction to this. So, I'm kind of at the team. So, there, who's going to start working on Wednesdays? That's great. So, the way that we're going to go into this is I'm going to do a bit, Tom's going to do a bit, and we're going to explain just one part very clearly that we've standardized for our state channels. So, this is specifically the state progression protocol, and how you move state forward. And we're going to go through the example of roulette. But before we do the roulette, then I'm going to explain at the abstract what is within the state. So, let's dive into that. I'm going to set a timer for myself so I know what to require. So, what does the state contain? If there's questions, please shout them out, because this is like, it took a long time to get to the point where this was all agreed upon. And does anything because understood is very useful to verify. So, what is in the state? In English, this is exactly everything. So, it's a pretty comprehensive list I'm going to go through, and a pretty sub-explanatory, but I'll go through them. So, obviously, in every state object, you need to know who's involved and reason why. It's because this is a fixed set of people. You know, I'm just a set protocol. You need to know that. So, it's in the state, the list of addresses. Two is the chain identifier. Is this maintained as a Robson? Is it rigged for you? What is this? Is it, like, it's an eosler? Is it in the know what the chain identifier is? Three is that you need to identify for this particular channel. So, that's just basically one number for all the channels you ever use as a client. You keep track of that. Fourth is the channel period. So, if you need to go to the chain, you want to know how long are we going to wait. So, again, this month, this is per state. You keep track of this. Then there's version number, obviously, this is state channeling to keep track of each time you recommend a version number. Again, this is somewhat obvious, but it's important that you know this is an every state object. You want to see one bit. There would be outcome of the state. This one's a bit more nuanced if you're not familiar with state channels. Every single time you update the state of your channel for all channels, you keep track of if this state was the last state ever. For example, in the real-life game, you'll see some examples of this. If it just ended there, you didn't know who gets which one. Right? Is it a final state? And state channel is a notion of late. Are we done for sure? And if everyone signs off on a bunch of final states which we'll show, you can know that you do not need a channel period because it's a notion of finale. You're not going to progress further from this particular state. You sign off on that. The definition of the state machine, which Jeremy just described, is a necessary and important part of state channels. What exactly defines how you move to the other? And the application-specific state data. Obviously, like a state machine, only makes sense if you're passing in data to group with. And then the most obvious piece is the signature of the transmitter. Now, normally maybe a state channel is primarily like you sign each state update with everybody, but we're going to describe that to be a bit more simplified. For each individual state, you just need one signature to move it forward. So that's in English. So it seems like some of these are initialized when the channel is created and then they never change, but then other ones are... Exactly. I'll say exactly that in a second. So this is that when I subscribe, but it's a lot of these types. It's pretty self-explanatory. Some of these are just some of the numbers that are dynamic data types. And you can see to your question that some are fixed, some are dynamic. There are parts that are the same and the entire iteration of the state channel came. So on a real example, you will see all this. The same people, the same blockchain, the same unique data file for this channel, the same channel iteration, and we could make this an ad for this and put it as static. And the same state machine, which is what we call the app definition. You'll see why it's an app definition. Variable is a turnover. It goes up. The outcome changes based on the situation that you're at in the game. It's nice to change this because it's progressing the state. It's final changes because you might get to the end and signature changes because each time you get a new security. So this is very specific but it's important to keep in mind all these properties as we explain it. So some things to keep in mind. Each individual state has a mover. So here you can see an example of how state is progressed between two people as a whole situation here. One goes, then the other goes. Then one goes, then the other goes. And it's always a turnover. It's not A, B, C, A, B, A, B, A, B. It's always A, B, C, A, B, C, A, B, C. It's cyclical in that sense. And again, there's a lot of reasons. Fundamentally it's because this is a unanimous consent protocol. You need to be able to account for the fact that every single person is involved in this protocol and has to be consensual to state updates. And whether or not to be the case, then one could be the other and you've got to have different situations. Since it's fundamentally unanimous in a sense, you want to move through each person for simplicity. And so we have this concept of a mover. The mover is pretty straightforwardly. It's the person in the participant's list who is turned on for its analysis, module of the electoral list. So on two it's pretty straightforward. Zero one, zero one, zero one, zero one. Obviously the person who's turned it is has to sign the state. That should be fairly straightforward. You can't have Alice signing a state where it's meant to be Bob. Which means if Alice is signing some state sending it to Bob, if that is the latest known state, it's expected that Bob is going to reply. And that's a very important property. You want to know if any way you can assert that someone is at fault by not responding, that is very useful for running the on-chain logic to be as simple as possible. And another property is that with the final modifier anyone can exit at any time. If at any time I choose I'm done I can say that this is final for me if the rest of the participants sign off with their turn, it's also final. It's over. So this is not always something you want to do. Usually it's going to be not in your favour to just end abruptly. For example, and you've seen the roulette if you want to end abruptly when you're expected to be making a move such as like rolling on the machine then basically you're doing it your way. Usually this is a quick property. But it's a useful property because you do not want to be locked up. So the main point being made here is that you should be able to exit at any point in time if you choose. Since your money is unlocked but probably you're going to be losing out because usually that's a forward operation. So it's more simple because you can end the payment channel at any time. And so the claim against final is to say I'm done with the channel. And then some of the core state channels where just some logic is operated on by this valid or just some function. The way that state is considered to be valid for graphs is that the valid is just between any two function returns true. So you take two states S1, S2, it should be true. S2, S3, it should be true. And the most basic possible example at the right on the slide is a counter. In a counter this application would be there's a number and the next logical state is that number plus one. So here you can see the most basic statement that's on the machine. You want the S2 counter to be S1 counter plus one. If it's not it'll obviously this one. So error will not be a true outcome. And so that is function return. So Jeremy was talking about advanced state. Is there a difference between the advanced state and the valid transition? Yeah, so this is a nuance I can explain it now, but it's a nuance that we didn't want between the slides. But basics, I'll say this clearly as I can. Valid transition is a function which defines that if you have two states if you want valid transition on them those are the true. Advanced state is from the way we look at it more functional interface on top of this function. And you can think of it as if I have some state and I want to advance it with an action so let's say for tic-tac-toe, I have tic-tac-toe board and I want to place the X on the tic-tac-toe board then the result is the tic-tac-toe board and I with the X on it. So we have three things. The previous board we have the action, we have the new board. You can write a function valid transition which says take the hash of the new state of the X on the board. That's variable one. And then run, apply an advanced state for the old board and the action and you get the output from that function and compares the hash of that equal to the hash of the new state being proposed which has two in this case. So if the hash of basically the second state is equal to the advanced state of the S1 plus an action, that is a valid transition. So this is just a slightly higher level abstraction which allows for that type of application to be built and also for this kind of application to be built. And since we're not, this is more about the standard of the state progression protocol and not as so standard for how you write applications when we develop a point of view or maybe that's a bit simpler to think about. I'll show you this slide. Because this can be done in terms of this. Right. So there's one thing I didn't, well actually it can't be because it's pure and so it actually is the term in the state based on the state. Yeah. So you don't have access to the action so essentially you have to be able to tell that it's a valid transition without knowing the... So like you mentioned in that and for this, however that thing I mentioned you can write on top of this generalised version that you do have access to that. That's more of a way of describing this. For example, I think you can write in different terms. I was just thinking in general essentially like if it was hard to like if the state transition was complicated then potentially without the action it might be hard to actually calculate whether or not S2 properly came from S1. You always put the action in the state code. Right. Just like how you define these things. That's how I'd recommend it for application building purposes for the raw protocol of the commission. So that's my part of the talk. So I'm just going to describe that description in the comments below. Thanks again. So what Liam has just explained is the structure of the states that are going to form the state code and what I'm going to start off by talking about is how you actually write an application that runs in this format and the application that we're going to focus on is based on the roulette application that Jeremy produced. We're going to simplify it slightly in terms of this talk. So what we're going to look at is this example which we're calling red-black roulette and red-black roulette is basically just roulette but you can only choose the red numbers or the black numbers. So I'll just run through how this works. Each player either picks red or black and each player we're looking at a two-player scenario where that's competing what we've got a player and a house so it's the two participants' stage channel here that we're focusing on. One participant's the player, the other's the player and the other's the participant's the house. So the player picks either red or black the house then decides and an amount of wager on that colour. The house decides whether to accept or not. The roulette wheel is then spun and it generates a random number between 0 and 36 and the player wins if they chose red and it's even and not 0 or if they chose black and the number is odd. So the interesting thing here is going to be that third point where the roulette wheel is spun and it generates a random number between 0 and 36 and we're going to be looking at how you actually do that in a stage channel and as a spoiler the answer is to do a commin reveal scheme which probably is familiar with that in the next slide. So in order to write this in a stage channel we have to break this process down into a series of different states and define which transitions are allowed between those states. So in the case of roulette we're going to end up with this state machine here. So we start in the top left hand corner in the start stage and the start stage just stores the balances of the house and the player. So when they enter into the state channel we're going to land in that state and those amounts should match the amounts that they'll deposit into the channel as we'll see a little bit later. The next step is the poster. So this is the thing that the player so like that these players take turns so we're going to start and start and propose is going to be the thing that the player does the house is going to respond to except the player is going to respond to the reveal and then we're going to go round and round to take turns in these states. So to start to take on the game the player formulates the proposed step and in doing that the proposed step has balances if they include the wager in this case the player wants the wager to eat and then they commit to a random number and they commit to a random number by providing a hash of the number that you've chosen in this case four and some secret value and that's the thing they they came to the state and they sent that over to the house and out of the house they say look at that they're like am I happy to accept this bet they decide yes and so then they reply with this other state so they take everything that was in the proposed state and to that they add their random number so we're actually doing a one side commit reveal but that's fine so like at this point the house is they just like pick their random number and then they send that back to the player now the player at this point knows whether they're one or not they can see the house's random number they know what their random number was and their next action is to reveal this state so the reveal state has the final form position so like to calculate that form position they add together those two random numbers on to those thirty-seven thirty-seven thirty-seven thirty-seven to generate that random number in zero and thirty-seven and then they reveal their salt that they used to hash their random number so that the house can verify that they're not cheating and the number that they're using is the number that they've committed to and they calculate the winner and then they update the totals appropriately and then they can continue around this thing as many rounds as they want to do so these are the different states and this is how we're going to model this relent game in our state channel so when we're actually writing a state account contract we need to encode these states and we also need to encode the valid transition rules between these states so if you start in a start state what are the possible values post state that the player can craft because obviously not all of them we have to be quite specific about which states are okay so what I'm going to do quickly now is just go through each of these transitions what the rules are and I expect you can probably start guessing what these rules would be so the first rule here is the health balance can't change so we can't have the player formulating a bed and somebody might take your house's money similarly where balance can't change this is kind of like to face itself the wager has to be smaller equal to the health balance and the wager has to be smaller equal to the player balance choice has to be red flag and that's it so these are just like pretty much like data validation things this would have to be coded up into a smart contract to check but two things would be better Do you have a question on that? It has to be coded into a smart contract and the reason it has to be coded into a smart contract is if we end up having to dispute a certain chain the chain needs to be able to check we'll come to this later bit late one of the problems about the intercap of the state is if one player stops responding and that's the thing where you need to get a changing mode and you have to be able to say you're not responding I'm going to challenge you on a change by the next state and the chain has to be able to check whether a state you've provided is a valid transition so these rules do need to be coded into a smart contract and this is like the mispoke part for each different app you're writing ok the next one is a proposal because to get a little bit more into the thing so in this step we update balances and again we're going to explain why you update the balances like this later but as a quick preview it's basically because you're thinking what happens if the player doesn't respond to the next step you know basically if the player doesn't respond to the next step you know it doesn't deal with that later so these balances have to have to update that's the interesting part and then there's some booking things so the way you should change the choice shouldn't change you can't have the house changing the players and the next one is the step to the reveal this is where most of the project of the actual application is so to make sure that this step is valid we need to make sure that the player has calculated the joint number correctly and in doing that they've used the value that they've recommended to and that's what this does basically so if you look at recalculating what was the player's random number by the difference and then we're checking that when you hash that with the sole that was provided you get this random value for the last thing and the other thing is that you have to calculate the winner correctly now that's just that physical cycle that I've described earlier about if it's random even all that sort of stuff and we also need to make sure that we update the house value and the player value correctly so in this case you can see that the player has won and that there's a mistake there the value is probably set for longer and finally going from reveal back to the start we just need to make sure the balance is the same okay so what I guess what I've just described there is the gain of specific parts of writing roulette as a state channel application combined with that are the framework parts which is some of the stuff that Leon alluded to so here's the state what I'll show you here is how we actually take that gain specific part and put it into the state channel framework so this is the state that Leon introduced and this is how it maps on to that start state that I should be paying so we've taken that gain specific stuff and we've put it into a load of framework stuff so we've added things like participants, the addresses the signing addresses of the participants we've got an array we've got a chain ID, a channel nonce a channel nonce is pitched by the players to make sure that the channel ID is unique and what I'll show you back on the next slide we've got this app definition by writing roulette roulette there I mean the address of the modern chain smart contract I've coded up the rules I've spent two previous slides turn number is starting at zero it's the first state and everything the outcome is what people would get if a channel stopped in this position that's the house balance the player balance and then we've got it's not final on that signature so the actual so we've got like the game state, the game rules and that's put inside the framework state which has the stacks for stuff and there are also some framework rules which define how these states are allowed to update so the framework rules cover things like participants can't change and chain ID can't change the turn number must increment and so on and I don't think we're actually going to go over those in these talks to find those by now more about that if you're interested okay so this is how we construct the initial state and what the player would actually craft in their software and they also calculate channel ID so the channel ID is calculated by hashing together the participants and the channel knowledge and the chain ID so that's how we identify this channel and that's going to be important when we start potting money on the chain for the purposes of this channel this is going to be the channel's identifier and we're just going to call that R123 but in fact that's going to be a value that's going to uniquely identify that channel and it's one of the participants to make sure that that is to be so together they can make sure that their channel knowledge they can change that channel knowledge to make sure that they know they can repeat the channel ID and that's one of the things that they have to take on they should never enter into a channel with a duplicate channel ID but they're going to enforce all the channel data then and the channel knowledge must be used at the same time the burden is it purely on the off-champ off-champ code not on-champ it's on use of participant to make sure that you don't enter into another channel for the same ID so the burden in addition to all the other off-champ stuff I have to remember also me to make a copy of all the NASA deals with the same pair it's enough to store the highest non-series used for each participant you can also do things like you can get around this by the addresses at the top or it can be a thermal addresses so it might mean that your software just generates a brand new address for you and every channel you enter into and that's enough where we can use this as a question so you can do it randomly by storing highest non-series just to confirm the on-champ does not care so it's actually possible to see kind of like a reaction of the on-champ Yes, so like a lot of these channels a lot of these channel IDs the chain will never know anything about the program so like the chain really can't keep track of that for you you have to do it ok, the first is talk we're going to hide some unimportant fields so I'm basically going to hide a lot of stuff that stays the same and so this is what I'm going to be looking at and what I'm going to do now is I'm going to go through state by state how an interaction in this state and how it would actually work with all the updates in this format um alright ok, so this is the this is the first state we start with and the player formulates the state you can see it's got the start state in there and send it to the house and the house formulates its next state send it back and what the players are doing here is they're doing an opening hand shape so we're doing this round where they're doing the pre-fund setup round and it's making sure that both players have a state that's signed by both of them before they put any money on the chain and that's important in order to keep the players safe it's basically their key to releasing that money if something goes wrong so both parties now have two signed states one made to their signature round we call this a support proof for state one it's like somebody can find the chain to show that both players agree we got to state one it's like a I guess the format is like signature of player one valid transition, signature of player two so we've got like two states joined together with two signatures on it that's like a something you can do to the proof that you can go to the state Why do you need both? Do you check the current number at the higher points? Yes You need both because each one is only signed by one participant so in general proof I got to a point I need signatures from all the participants otherwise if I could do it unilaterally I'd be like if you create state 10 then that's the chain and I could do that without any involvement basically the reason is because we do this term taking stuff is a consequence of that if you're going to sign if each person is going to sign one state you need two signatures and that means you need two states we do actually have an optimization where you don't need that but don't get to that But after you send your sign card say the party that sends turn number one he has no confirmation that the other party received this one state Yes Let's say this is Edison, Bob Edison zero, Bob Bob sees the Alice one state and then calls on back then Bob will send a new turn number one So what happens is Alice sends zero to Bob and then Bob sends one to Alice at that point and then Alice has zero and one and Bob has zero and one and when they both have zero and one then it's safe for them to deposit one chain So here I'm going to introduce the adjudicator which is the one chain contract which is going to hold the funds for the duration of the channel and it's also going to be responsible for enforcing the rules if there's a challenge if we end up in a dispute situation I'm going to introduce a couple of bits So at the moment we're going to have adjudicator just think of it like in actual fact adjudicator is a suite of a number of contracts but I'm just going to consider it to be just one contract and it's going to have addresses so that's going to be addresses for channels balances and outcomes So now they both hold these two states so the player the player is going to first to save the first participant so they call this the deposit method and introduce that you get the channel ID and the amount stored next to it and then the house deposits and you end up with the channel ID and the tenant stored next to it the ordering there is important the ordering there has to match the ordering of the participants because that's the order they get the money out in so like if you ended if the channel is only partially funded the first player is going to have precedence in getting the money out first which is why they put the money in first that should become a victory so that's what these do Okay So once they see the coins from the adjudicator they can then proceed with the exchange in states to have done this pre-fund setup then deposit we're now going to have the post fund setup stage and this is again part of the framework transition rules and that is to both the participant to acknowledge that they know that this channel is now funded they both see the money on the chain so again they're just going to echo the same state back and forth so they've now basically got four copies of this like start state with increasing turn numbers pre-fund setup and now we're in a position where all the participants agree that we've opened the channel and now we can actually start running the algorithm which is what happens next so that these are the next states when you start running the algorithm here we have actually you can see that the app data has expanded and inside the app data we've got those states that I have in the state machine so you can see that we've got a proposed major choice around the commit so that is the post state and the house response is the accept state and the random number we then do the next state so we do the reveal state again it's all packed into the app data and we finally finish up in back in the start state we've done like all four states in that roulette state machine and they're all packed into the site framework state that's around them so suppose now that the player wants to stop playing so what I'm showing you here is a HAPT case it's in our other state of the state channel so you deposit, you play you can conclude collaboratively so in this case what happens is the player then signs the exact same state but putting is final to true so this is where what's going to happen here participants are going to sign off on the final state so that the player signs the state of final true house finds the state of final true they're then both holding two states with quite this final true we call that a conclusion proof so it's like both players have signed up on this and that's evidence you can give to the sustainer to say we've finished this channel so you can then take that conclusion proof we're going to provide it to the adjudicator and the outcome from this channel is going to get printed into the adjudicator so the final outcome for this is the player has seven houses three and that is stored on the chain and at this point we say the channel is finalised the outcome that we agreed on chain has been registered on chain and it's the final version of that channel so this is how you do that the two method two method checks that both of those are are like final states and they're about a transition and stuff and then finally the final step is to actually get the money out of this and the way you do that is to transfer so transfer on a channel it looks at what was in the adjudicator you can actually do that there so I've got this final outcome transfer first phase out the first thing in the outcome is that it's out to zero and then it pays out to the second person in the outcome paying out the external Ethereum addresses so the money is now out to the contract and we've finished our state channel interaction Liam is now going to talk about what happens if we're wrong we can pull that question Is there a separate batch of adjudicator contracts for each application? No so the way we have it currently is that we have one adjudicator contract which is responsible for going from channel ID to outcome and then we have a suite of asset holder contracts one for each token you want to use the state channels so it's like an E asset holder it's an ERC20 asset holder but it's pretty important that these things are all the same contract when you get on to having more advanced channels of fun for another because they need to be able to send money to each other Are there any more questions? Great, that's how it's supposed to work what can go wrong I'm only going to talk about the two most important cases one subtle one I'll also talk a little bit about the end but these are the most important scenarios one is the player is playing and sending a state to the house house sets it and just waiting for the player to respond and nothing happens software is just waiting and specifically when this matters is in this example right here where the player gambled some money on some on red and the house accepted the gamble and the player now is expected to do the reveal state that we started to talk about earlier and realize oh shit like as you lost and so this will be what happens in this scenario like I said the house is going to have its funds locked unless it does something so what we do is we introduce into the adjudicator this new method called challenge and challenge is basically a button you can push on the adjudicator which requires that you send in like Tom mentioned a supported state that shows that the player chose this at this choice I accepted it and now the guy is not responding so force them to basically by initiating a time so you pass in the last state where your number was 8 they had proposed their state you pass in your acceptance of it you take them up and bundle them into the contract and you push challenge and what happens is it puts this data on state it's supposed to end at 7th 3th at this point in my acceptance of the state which is an important kind of subtlety there the outcome immediately after the house accepts it at this point says the house wins because if that state were to be the last state ever which is the case if the player isn't responding to this challenge the house should win it's basically what that means is that if this is the last state the player is left which is a candidate in forfeit so we say hey 7th 3th I want my money I accepted it and it's a timeout now timeout is the length of the state and this is basically what the API looks like and if the guy doesn't respond after that timeout is finished the number of blocks is passed more than the challenge ratio then basically it's considered to be done and in the same way that you work with a conclusion proof from what Tom just mentioned where the outcome on the chain says 7th 3th that's basically selling chain it's now 7th 3th and the channel is done this is what happens if someone stops responding to you you can always force them to you that's why this whole thing is called force move protocol because if anything at any point of time goes wrong you can press this button and force your counterparty to make their turn so they're forced to fade as if they were doing a bet without any regular blood they're forced to respond in some way they have 5 each they both have 5 each in and in the states when the house accepted the bet that the player made the outcome was changed to be the house won the house accepted the bet I now get the money and if the player provides a reveal state after this that is the one that calculates that they were the winner based on that function that we mentioned then it would change to be that the player won in the next state however ultimately maybe the house won will be the same so that's basically what happens here is you force them to make them move and the only logical thing that they can respond with is something that passes the ball or just tests the protocol so you're forcing the state machine forward so that's a challenge however there's another version of this where maybe the player was gone for a little while and they weren't actually trying to not respond because they thought they lost maybe they actually didn't win they just closed the laptop for 20 minutes maybe they lost a signal or something like this basically they should be able to respond that's why we have a time up and so pretty straightforwardly you can imagine the state exists which is the one I mentioned a second ago actually I swapped the 7 I didn't do it consistently in this case the player gets the 7 because they revealed and in fact they chose a good number they chose red it was red and the most they should be able to do is take that go to the judicator and respond so we introduce a new button called respond you just pass in that latest state that you've signed which is a logical transition based on all the rules and then you'll be able to see that the challenge basically gets erased and they can keep moving forward the point is like they weren't malicious they came back everything's okay and the chain allowed for this to save so those are like 99.99% of the failure cases the only other failure case which I didn't put slides hard a super quick they explained is maybe the player decides to put some super old state way at the beginning when they were back at 5.5 then what you can also do is the third button is a check point and pass in the future state that's way in the future and it'll effectively slash the player because that's the most obvious case of them trying to cheat but that's the more edge case software error situations these are the 99.99% cases of actual on-chain operations so that's the respond function that's it so do you have any questions any questions do they have an incentive to respond if they've lost but they want to keep their reputation as having off time or something the player they if they don't respond then as an on-chain artifact at some point they were expecting to respond and they didn't have their reputation and you probably would take that into account so they wouldn't necessarily just give a prompt for an off-chain artifact it's a bit hard though because it's a non-attributory port you don't know if it's a challenge on chain whether I don't respond to you or whether I respond to you you've got it and want to challenge on chain anyway so one thing you could do is you don't have to make the numbers all line up exactly and you could make it that you lose a little bit more if you don't respond than if you respond saying you've lost there's always at least some incentive to respond yeah, there's all kinds of words you can optimize like the outcome distribution based on scenarios this is like the most basic basis if that's a challenge are you settling on chain or are those funds locked on the state channel for everyone to respond so I guess what happens so if you launch this challenge and the you press a button to respond then that channel becomes finalized on chain and at that point it's unidentifiable from if you've concluded it all it means is that you have your channel ID and your outcome in the duplicator so at that point you just transfer out your funds just like you did in the example where we concluded it because that would just be on chain so like in the happy case basically we've got to exactly the same situation you did in the happy case channel ID outcome on chain if a player doesn't respond can you automatically release the funds from the state channel to your region yes so if a player doesn't respond you wait for the time out so if a player doesn't respond you wait for this time out after that time out is finished you'll definitely start to do the same situation in whether the channel is finalized on chain you've got channel and outcome and then you can you start to transfer the funds out I think we're only one minute over now so I want to make sure we don't go too far we can do one more question we can do one more question how does the contract know that time is up does the house need to send another contact and say hey you missed the challenge period no it's like when you actually want to interact with this the chain does not literally say the time is done it's more so the next time you interact there's a check effectively you don't really need necessarily to have a check you can see the challenge and the block members will be greater than that so you don't really need to register that checkmark so put another way you just want to client side and then you just go to withdraw because you know the time is up and then when you go to withdraw it checks and says yeah the time was up so it kind of lazy evaluates it so as the house I would submit to end the chain to get my money back because you want to withdraw the money anyways so you just say hey withdraw and as long as you're after the challenge period it'll let you do it I think on the A2 stage where we're going to talk about this general project in a more of a road mapping kind of way like hey great we understand what about the funding part what about all that stuff we're going to talk about that and hopefully now you know the beginnings of standardisation across channels all of which we have some great working codes a lot of which are made now which are things I talk about today and I think it's a future looks bright for the state channel hi everyone I'm Arjun from Conex my talk is on making channels usable for humans and then we realise that's a really really big topic so we narrowed that down into the browser and then we realised it's still a really big topic so now I'm talking about one very specific user experience feature improvement that we did and then I'm just going to hand wabily allude to the rest of them at least some time at the end and you guys can like sort of choose your own adventure for the last five minutes so yeah the structure of this talk is going to be about three slides of me showing Conex I've been told that I don't do that enough so I'm just going to give people a background on what we do and I've found that not a lot of people know yet and then after that we're going to jump right into the channel provider standard that we're trying to implement both within our system and then also have that be useful across other channels cool, what is Conex so we started out as a user experience company we spent a bunch of time trying to figure out what the key barriers were to getting people to use Ethereum initially we thought it was sort of like a bridging mechanism we needed to find better ways for people to bring their value on chain and then we sort of realised okay wait, before people even bring their value on chain Ethereum doesn't scale and it's just a really stochastic and consistent environment which is absolutely terrible for any kind of development on the web and so since then we kind of shifted to doing channel stuff about a year ago we went live with our first image channel implementation which was the spang chain image channel hub that was actually at DevCon last year and at DevCon last year I said we were going to work on getting this integrated into more places and they weren't usable which is sort of good because we did actually do that and it turned out to be a lot harder than we expected just because when you put this stuff in front of people you realise there's a lot of really base assumptions around how usable these things are in the web environment and that we really needed to validate and sometimes it really changed so after doing that we realised about half a year later that the best way to do that would just be to build a full stack environment where we were controlling everything from the channel protocol contracts all the way up to the wallet there so we actually built a production ready wallet the die-carded browser partner style slash spang-based style wallet and it influenced by those and then put that out in front of a bunch of people who actually used it all the time still a lot of people use it which is kind of cool and it seems like mostly it's being used for demos of channel stuff or as a reference implementation but it was really helpful for us to understand oh wait so many of these things are completely wrong and that directly led to us working with other really interesting projects in the space like Detalk, where a wallet was sent out and then that was cool so it's kind of cool because we got to be sort of incrementally built a lot of exposure as a result of this cool where are we now? We went live with v2 v2 uses the state channels framework or at least a sort of precursor to it which will have like a very gradual very smooth transition because the contracts are the same and then we sort of aggregate all of these lessons that we've learned from doing things really really complicated for a while and then we also significantly improved our trust assumptions so we said we sort of looked back at the way that we were filling things and said ok how can we reduce the amount of time the hub is holding onto user state how can we not do the thing where we like kind of just pretend like the user we sort of had this assumption in v1 where we were like ok well the user can back up their state but we're always just going to give them a hub state because we really don't want to ever have a case where like the user state breaks and we just hadn't had the time to fix that yet so it's like things like that which are second level assumptions outside of the line of base burn environment which are really important to think about as well and then where we're going everyone keeps complaining that nobody's using channels so we're going to make you lose them this is sort of where we're like trying to integrate in the next few months and then hopefully do more in there so we're trying to build a system that we can come into and then eventually decentralize a little bit more like what I think cool sorry for being a shell back to state channel roulette ok so how can we make state channel roulette safe and easy in the browser and this is actually like a harder task than most people realize because there's a lot of the things that people talk about like you know how do you back up user state and the browsers are really insecure environment you don't want to put your keys there but you do want to put your state there but you also want to back up your state somewhere else and then you have all these other headaches like ok well in reality users aren't just going to be on one browser all the time they're probably going to want to have their channel available on multiple different devices you know like when you do that you actually share a state between all these devices and you kind of decide ok let's just focus in on one very specific problem which is the biggest user experience hurdle we've seen so far which is that the hardest part about using layer 2 is that layer 1 is awful and like any point where layer 2 touches layer 1 is sort of the biggest user experience nightmare a really good recent example of this is we spent like a year with our channels on mainnet to this problem until about 2 weeks ago when the whole heroin thing happened and then I don't know where users started saying like hey like I'm not able to deposit into my channel I'm not actually able to put money in there what's going on is your stuff broken you know what is happening and we were like what the hell is happening all of our stuff says it's fine we don't understand that anyway we actually looked at user scan we realized user transactions were taking 6 hours to find and so like our contract improved our time out because we don't want users to sort of deposit or say that they're going to deposit and just leave it forever this is sort of a safety mechanism mostly for the user we were like ok well if a user forgets to deposit or something goes wrong message doesn't get sent or something like that we don't want them to have an unusable channel and so it's good because it worked but it's terrible because everybody was like oh your channel is broken so this is a really good example of situations where you don't really understand what is going to happen on chain because it's such a stochastic environment so we sort of in B2 said ok let's not only improve the user experience of depositing and get rid of this time out but also try to make it so that users never really have to go on chain or like really can just pick up their channel and take it with them everywhere they go so what does that look like so there's a really interesting and existing example of how this works when you use any decentralized application today the old way to do it was that you'd have to actually recover your keys and that was awful because you're trusting your keys obviously that's terrible on the browser and as a solution to that we came up with this key provider standard that MetaMask implemented a bunch of other wallets that it implemented where you have your key hosted in this remote a much more safe environment like a extension or your phone the key can be put into a key store it can be kept into a place where you really only have a very narrow pipe of functions that can pass in and out and then you sort of make hoped calls from your browser environment to that remote that remote key and so we sort of looked at this and said ok wait why can we not just do this for channels as well and actually Bruno from MetaMask helped us a ton with figuring this out but it was it turns out we could and what we sort of ended up doing was treating the core channel code that's implemented by state channels or projects as an isolated piece that's within the wallets because it's trusted code in the sense that it is like the user's code that validates that the state that they're getting is real and we wanted to be in a trusted environment because you don't want somebody to write wrong validators or like a browser to implement a validator spiritually and give you a weird state and so we said ok let's just treat that along with a key that's been getting passed into it as like a normal key and then do the exact same thing inject a provider to the channels instead from an application that exists on front end like in a browser context back into this remote wallet cool so what does this look like so in a wallet this basically means spinning up a client and it can be next or it can be any other state channel framework client that anybody wants to build right now or in the future so it's a great thing about standards and then map all those time methods to a channel provider it's a pretty standard interface we actually just took the same interface for now in the future we can amend that as needed but I sort of suspect that it's probably going to stay roughly like this for a while and then the way that that looks from an implementation perspective for wallets is like the ERC is it 1-3-3-7? No it's 1-1-3-7 I don't know there's a standard RPC interface so you just copy paste that and then just implement these methods and it would work and then basically like set up bundle that up and then inject that into whatever context however you want there's a few different ways to do this you can set it into that browser context using like Chrome messaging like Metamask or Portis or 4padeq you can also use something like Wallet Connect which is an isolated protocol for or actually bridging two environments together you can also do this you can have a hardware device and do this using some other messaging system you can imagine the context around this is really interesting and for parking you can just tap your phone confirm on your phone you're injecting your channel into the barrier you're not actually recovering your key on the barrier on that thing and then on the DAP it's even easier this is the part that we want to optimize on is we just wanted to make it incredibly easy for people to leverage channels so if you get to the point where a lot of wallets are using this channel provider standard as a DAP it's basically just like the existing ease provider standard you can just say if this.context.channelprovider get the channel provider from the context pass it into whatever client implementation you want that runs on the same framework and now all of a sudden you have access to a user to a remote channel they don't have a channel you can create one but otherwise most times you can just call functions on the channel and it'll just get passed up to the remote wallet what is the consequence of this actually one more side of just how it works wallet when you hit the spin and you feel like on your left what that's doing is calling updating the state basically like proposing a state the best analogy that I can give is basically like invoicing your channel and that invoices for any sort of state update and so then you get that on your phone you confirm on your phone your wallet can decide how they want to show that experience to you whether they want you to sign on every transaction or sign on just like your app itself but you confirm on your phone and then that your service data is updated and that's reflected back in the application cool why do it this way so this is we learned from experience would be one that while building things using channels are awesome the process of actually getting users to interact with the channels themselves like on-chain is just brutal and like the like the integratability of v1 was severely affected by that so like as you sort of probably saw that our v1 of connects really was integrated mostly with bullets and the reason that that was the case was because having to build and like completely isolated like application meant that users had to get positive to that application separately and every single person we went to and asked about that said oh we're already doing all of this work to try to on-work people into Ethereum and now you're asking us to on-work people as a separate step into connects and that just doesn't make sense for people two it is actually the easiest possible way to integrate the channels in your data like there's no we haven't yet found a way to make it as simple to just call to a remote channel then this and if you do find a way like let us know we would love to make it even simpler and then lastly this makes the safety of your channel exactly the same as the safety of your system in Ethereum wallets Ethereum wallets are a productized space unlike most of the other work that is being done in this space like Ethereum wallets have material user attraction and they are being used in production and so they've had production problems and they've had you know things like users funds being lost dependency issues that cause people to get hacked those are the sorts of things that you need to worry about to bring channels to production and this does make channels and operating in a channelized environment the same as what exists with Ethereum wallets cool so that's the channel provider stuff that we've been thinking through that's live-ish now it's like on-staging and we're waiting to put it into master this is another consequence of like having people using the one in fraud is like we actually have to like migrate everybody and that takes time into coordination burden we can't just like release it and so we're in the process of doing that right now but once that happens you'll be able to use this within like a public context at least the other sort of user experience things that we've kind of seen where we're useful from this last separation where things like treating your channels as like a wallet in the state channels this is literally true that your channel is a multi-sig wallet and that's really awesome because now you can leverage all of the other user experience paradigms that people have been building like better transaction so for instance getting rid of doing gas extraction they're able to deposit into their wallet not paying gas maybe a bunch of off-chain transfers and then withdraw in a way where the counterparty or the hub offer for somebody else is the one that's actually paying gas cost transfers to offline recipients availability is a really big issue on the web not just because people go offline and because the internet also is a decentralized system that is stochastic but also because people aren't always going to be around to receive your payments that's a thing that we really, really focus part on plugging in state backups users of these things like Visa for watch towers but then this also means even just having the user be able to use their channel or their application in a bunch of other devices at the same time or maybe not at the same time but at least in sequence and then only deploying like on-chain again only making on-chain transactions when you absolutely have to so moving your channel deployment to withdrawal using create2 cool so this is your menu is there anything here that you'd like me to cover or any other topics because I think aside from this I was just going to leave it open for questions thank you for a great book for instance just a strange question can you try to partner with what you might be pleased with what it says to the transactions possibly no that is an interesting idea do we actually have any myth on of it we just said okay let's so it's a decentralized system and it gets more decentralized over time it's decentralized on top we don't want it to necessarily be the case that mining pools I'm sure this will happen at some point but we don't want it to become a case of mining pools become political around which next related organizations actually get their transaction process ideally we just solve the problem at its root there will still be this issue of deposit but if we can move it to a point where it can happen asynchronously then it doesn't matter if it takes six hours it's something where you can start a deposit for $100 at the start of your day and then leave and then use your channel later on in the day and not even know that it didn't go through my question was the signage if private is still within the metamask for every message I need to sign what's the problem yeah that's a good question it's sort of up to someone like metamask how they want to implement that it's like because the so this is sort of a nuance that I didn't really cover but part of the way that state channels is implemented right now is like there's a you need a mnemonic because each application actually has a unique key and so you use a mnemonic to carve out a unique key path for this specific framework that is different from all the keys that you normally get on a Zerion the rationale behind this is that it's actually like a really easy way to enforce stopping replayability across different apps and like handles a whole host of conditions and then also theoretically what can be centralized it should also make things more private because that's the case what we've actually found from most wallets is that they've said okay well we'll just use a channel specific mnemonic and we'll just do that differently in terms of signatures we'll just build a completely different user experience for signatures over there I think that that probably makes sense and it's going to be we don't want to be too opinionated so we're trying to leave it outside of next for now but I suspect that what will probably happen is something like you know sign on install and like on installing a app and then maybe sign on certain cases and maybe we can like expose a flag for like what seems to be the design but the stage will be a binary how do I even read it so I'm not going to say hey let's sign you this so there's metadata attached to it the state that you're getting is like the signature but then it's also like an encoded application state so you can always decode the application state and check it we can do that within our client and pass it on it's a lot like hardware wallets yeah there's a usability security trade off there the cool thing about having an application specific key is worst comes to worst if somebody compromises your funds or you lose the key or some horrible thing happens you lose only the applications funds and not the rest of your stuff which is like the same yeah that's also a lot better that's a great talk by the way I thought it was pretty interesting so my question is you don't have to project on a similar problem and there's something really interesting that you have to deal with what's actually really easy to solve like the nature of that and the overall concept of that do you mean for for like making the blockchain that should happen yeah the example is the transaction that's actually interesting so it's sort of up to it's sort of up to the wallet implementer how they choose to do this because they're the one I guess the client implementer because they're the ones that are making the blockchain transaction in that case in this specific case it was actually a transaction phone for better masking to pay and then Bruno and I talked about this and literally it was just that it was set to exactly the recommended I think it was safe load gas price and then he bumped it out but it just happened to be the case that at the time the safe load gas price was being effectively lost yeah it's required to allow users to join a channel with now on chain transactions is there like a source of funds for next yes you always have like one okay let me take that one you always have one on chain transaction to get funds sometimes it can be paid by the hub and then they can send you money in the channel so you can imagine like I buy funds that are already in a channel using like wire or something like that in this case like the user is still depositing into their channel but we're saying okay instead of depositing every single time you want to do anything like use any application we're saying you deposit once with your wallet and then whatever balance do you have there you don't really need to withdraw it you just sort of keep it there it's safe nothing's really going to happen to it and like it's completely non-custodial if you want and then at some point in the future if you want to yeah the real thing that we're extremely excited about like the channel provider stuff is it becomes like we want to get to the point where like you're able to leverage state channels without actually needing to be a state channel application so like being able to say like if channel provider like if like a channel exists make this payment using the channel and if it doesn't exist then make it on chain right that's automatically going to give like massive scalability benefits with this ecosystem okay we got that there we're good we're good thank you okay so good morning everyone my name is Shin Kai and I'm the co-founder of the channel network today I'm very happy to talk about the some of the design principles that we got while building and operating the state channel networks in real world protection and before we get down to some of the technical details I want to take five minutes to talk about the adoption of the state channel okay so just a few months ago the state network just launched its minnet and during the minnet we decided to release ratings the first thing is our user-facing application called state access which is real money it's called gaming platform that building on top of the state channel network the second is that for the game developers we also release the state access in an okay so help them to submit and publish their games or select mobile app and enjoy the benefits brought by the state channel solutions and finally for the blockchain developers we also release the set of web SDK that can help the blockchain developers to leverage their state channel primitives like the commission payment and the plugin into the application so today and this is a short demo about the select mobile app where basically the players can go based on blockchain games on top of set-axe and with crypto prices like user, diet or setter and the entire price payout process and also some of the games are entirely viewing on top of the state channel technology so it is real-time interacting with no latency and zero gas base and also it is as secure as the online blockchain and so far the players has spent over 1.6 billion US dollars on to this app and there has been over 300,000 games play on top of set-axe and currently our monthly active users is over 12,000 and is probably one of the most active decentralized applications on the server right now and our users are also spread across 89 countries and also for the game developers some of the question that demand access is that is my home games on top of set-axe because set-axe in itself is built on top of the state channel network solutions so do they need to understand the setter's technology, do they need to handle the option payment, do they need to manage users' private keys so the answer is no and we also release the set-axe game SDK so a set game developer as long as you have a vanilla HTTP ML5 game you can integrate your game with set-axe game SDK and enjoy the benefits of using the state channel network solutions and it also requires zero blockchain experiences and we also want to bring the developers that is outside the blockchain community into their blockchain space and on the left it shows how you might integrate with set-axe game SDK and on the right is our game developer portal which we can basically control and there is a big game submission and publishing process and so far we have got over 250 developers registered on the developer board and they have already submitted over 100 games on to their developer portal and another interesting data is that the first time integration time for integrating with the set-axe game SDK is just less than 30 minutes so that highlights theiveness of integrating with set-axe game SDK and finally we also provide a Seria web SDK so this is a explosive menu of the use for low level state channel primates that could help them to develop their two applications such as kind of payment so on how is that, we can build many interesting applications like prediction market, non-custodian exchange and also some of their micro payment services ok so today next I will spend the rest of the talk talking about some of their technical design of our state channel network and in particular we just released the full protocol specification about our invitation of state channel network if you are interested feel free to check out this link for more details and today I am going to give a very high level overview about the key design principles that we use by our building and operating the state channel network ok so here is the high level architecture for set network so basically the great area is the generic conditional payment network so this network has a lot of larger relay nodes connected to each other and also has a lot of smaller end users connected to these relay nodes and this conditional payment network has a layer and anchor to different public which is essentially a set of smart contracts that handle the off-chain to on-chain interactions such as opening a channel, depositing a set of channels and all these kind of operations ok so we think this conditional payment network any client can send a payment to any other clients in this network but this is not just a simple payment so we allow the payment to have an arbitrary dependency on the outcome of a certain application logic and this is called conditional payment ok so for example, Addis can send Bob $10 if Bob is a winner of the chess game so here is a payment from Addis to Bob is conditioned on the outcome of the chess game ok so we in set network we provide a fairly generalized interface that brings the payment part of the high-level application logic so basically when you couple the channel from assignments and also the high-level state progression of the application logic so basically you can do a lot of state channel applications and share one common channel from assignments now and this kind of coupling and layer architecture allows the two modules to be updated and involved independently just like today's internet and I will introduce the benefits brought by this kind of coupling and layer architecture ok so now let's first look at how set network handles the hub by hub forward in all the conditional payment ok so the first core data structure that we use here is called the conditional payment channel so in set network we allow the full duplex channel so which basically allows the two peers to send payments to each other concurrently without interfering with each other ok so in order to implement this kind of full duplex channel each peer will maintain a simplex payment channel data structure which basically maintains the current transfer amount from this peer to the other point ok so here we use the protocol message to show what kind of information needs to be included in the simplex payment channel data structure for example you need to include the channel ID, the peer address sequence number, the amount of money you have transferred from this peer to the other peer and also most importantly we also have a list that maintains the current pending payments in this state channel. I know that this is different from some of the existing state channel design which gives the protocol route for storing and verifying the current pending payment on the channel. So here because we don't use the protocol route here because a protocol route is mostly useful for the case where you have a pending only operations but in the state channel especially the conditional payment channel you will have a lot of frequent insertion and dilation of the payment object so in this case using the protocol route will incur many unnecessary additional capacity when computing the protocol route and also verifying the protocol route especially when you need to do some option verification of the pending payments so we just use the list that maintains the list of ID for the current pending payments and the second important data structure that we use is called the conditional payment. So the conditional payment has a pay time stamp and also the source destination for the conditional payment and also it includes a list of conditions that this payment is dependent on. And most importantly there is also a transfer function which tells or just specifies how we should resolve this payment depending on the outcome of this condition. And in here we provide many useful preventive for resolving a conditional payment. For example the bullying end means that the source needs to pay the destination the payment amount if all of the conditions included in this payment are becoming true. But we also provide other kind of resolution logic such as bullying all, bullying circuit and also the logic to handle the numerical conditions. So basically the source can send the destination an arbitrary amount depending on the outcome of the condition. Okay so here's the kind of high level overview about the messaging protocol with a single hope. Basically how you forward the conditional payment to the next pop. So the first step is that for the source to set up the payment to the destination it only involves one bunch of messages. The source just say okay I request a conditional payment to you and the destination just responds back. And when you want to resolve a payment basically saying that this condition has been finalized we have finished the chess game and I commit to that I can send you the money. Then the source and destination will settle the payment option. This also involves only one round trip of messages. And when necessary the source of destination can also choose to dispute or settle or resolve the payment option in case that there's someone tries to cheat or there's some disagreement about the payment state or the application logic. And also we use the sliding window techniques in order to allow the source to set multiple concurrent payments to the destination without receiving its act. So this kind of sliding window techniques significantly improve the kind of throughput we can get within a single hop. And that's also inspired by the current internet design. Okay so just to summarize the kind of properties that we got on a single hop level we use this kind of hop-by-hop conditional payment already is single because it only involves very few round trip messages. And it also supports a full-due text channel and also we achieve high throughput also through the full-due text channel implementation on also the sliding window implementation. So currently what I'm talking about is all about the hop-by-hop already. So what's happening within a single hop? So what about the modic hop? What kind of things we can build on top of this hop-by-hop conditional payment permitted? So in other words what kind of end-to-end design permitted that we can provide on top of this? And the end-to-end design pattern is also very important in the traditional distribution system and also the internet. If you look at this kind of very classical paper by Danny Clark to the age of the beginning of the internet, you can see that there's also a lot of design patterns for the end-to-end in computer systems. So our design principles will design those end-to-end patterns especially in two forms. First, we want to clearly couple the channel function allocation process and the high-level state progression of the application logic. And second, we want to push the complexity to the age while reducing the kind of relay nodes complexity. This is to ensure that the bank-owned network just like today's internet is secure and as robust as possible. Okay, and on top of that we provide several useful end-to-end design patterns. The first is called the modic hop payment with pooling conditions. So with this design pattern basically the source can pay the destination if this condition becomes true. And this is a very simple design pattern that it is probably one of the most commonly used scenarios in practice. For example, in our CELACs mobile applications, we use this design permitted to implement the head-to-head game competition and also it can cover the use case like prediction market or peer-to-tee peer social banking and also include some of the casino applications like Rolater applications that I mentioned earlier. And this basically is a high-level overview about the communication protocols when we try to implement the modic hop payment with pooling conditions. So for the sake of time I will not go into the details about these protocols. If you have everything including the protocol specification doc, you are very interested to check it out. And also you can settle the payment option and the destination also rejects the payment option. And also the source of destination also choose to resolve the payment option if necessary. But not here that so in our design, the relay nodes never need to send any empty transactions. Only the source of the destination needs to do that. So this is greatly reduced the complexity for the relay nodes and also ensure they are secure and also robust in the bank volume. OK, so to summarize there is a kind of properties with modic hop payment with pooling conditions. It is simple because the relay nodes never need to care about their application logic. It's just done with forwarding the conditional payment to the next part. And it's awesome low cost because the the relay nodes never need to send the empty transaction. And in most of the cases it does not even has a single view only function on the event working. So that's greatly reduced its complexity and it's also secure because it is resilient to any arbitrary relation of application and it's also lowering the messaging overhead. And the second end-to-end design permit is that we provide is new managerial conditions which basically means that the source can pay the destination and arbitrary amount depending on the outcome of their condition. So this enables some of the other interesting use cases like a second price auction whereas an auction winner can pay well pay their second highest price to the auctioneer. And also some other use cases like usage fees, car insurance and their cloud hosting service and so forth. And these are the products OK. So far to summarize the kind of end-to-end design permit that we got. Namely is there multi-hop payment with pulling contribution, multi-hop payment with numerical condition. Their design principle for them is that we highly optimize for the majority of the use cases. So that for the majority of the use cases is highly efficient and also secure and robust. And with this two end-to-end design permit we can build a dependency on lots of application logic. So for example you can build a turn-based station application like the gongpo app that we're building. And also as a separate application will also be some of the auction app like the Oracle service is built by chilling and also it could even be some application logic running on the roll-up chain or the commit chain. So that's great. We have a lot of flexibility but besides the two kinds of permit that we'll build we also allow for example you can also build on your own for example funding protocols like the natural protocol that we are going to talk about tomorrow as an end-to-end funding protocol permit and also on the application layer you can also build a forced-movement-based station that provides this kind of flexibility to lacking your own application logic or your end-to-end channel funding logic. So this kind of stacked and layered architecture designs just like today's internet architecture where online you have a unified IP layer so this is just like the IP layer for the value transfer network and next is the transfer layer that handles the end-to-end control and on top of that you can build an application layer protocols like HTTP, FTP and SNTP and all the layers share a common and unified interface between different needs. So just to summarize and give us some of the key takeaways here is that we design our station networks we have several key design principles in mind. The first design principle is of course that the design should be secure and also trustworthy and the second thing is that we want to minimize the on-chain footprint when we are building the station network because the on-chain transaction cost and also the latency is very high and certainly we also want to minimize the relay on a relay node the complexity while pushing the complexity to the HTML. And the fourth thing we also want to minimize the on-chain transaction interactions. For example such as the view-only functions or the event-working this might be in contrast to many people's thoughts that the on-chain view-only functions or the event-working is free because it is instant but the reality is that if you run the station network or you run different type of decentralized applications in production you will need to also pay for this view-only functionality in infrastructure services like if you are an academy and that comes with a price and also calling a view-only function or doing an event-working also occurs much in larger latency than you doing that with the local storage server or exchange message with your peer. And lastly we also want to minimize the on-chain communication already happening. So with these design principles in mind we take several design choices for example the key thing is that we try to decouple the channel-found assignment process and the high-level state progression of the application logic and these kind of design principles are also highly optimized for the majority of the use cases and also there are some design habits that I don't mention here for example we use a blockchain and our state-of-the-art infrastructure is full about such as both off-chain and on-chain share the common data schema and then we even build out our own like a protocol compiler for the Solidity and it's all in our data report if you are interested in checking it out and we also support the zero-on-time contract and the protocol great to do something I don't mention but it's including the bug and finally the kind of leader that we cover architecture is flexible for future use cases. So it's hard to squeeze in everything in 20 minutes but this is just a high-level review so everything is including our protocol specification doc so perfect to check out. Thank you very much. Hi everyone, I'm from here we are actually two teams based in large Dutch Germany and I am the research team and I want to present some observations we made while we were looking into the pretty party channels recently and we decided to do a little bit about what's going on on the individual side first. Okay, so pretty party this is not working so when we talked about the reletics group we talked about how we can connect two teams but quite often in the real world we want to connect more than two people for example three or as many as we want and in this we can build of course a smart contract in Ethereum because we want to also build an off-chain in a pretty party channel that connects more than two parties and this is something we've been switching to already give you the result it's possible but sometimes it's surprisingly expensive so when I want to do this talk a little bit about the challenges where it's difficult to design this and where designers of apps for this kind of channels have to be a little careful so the first question is how do we set it up? Well, we've heard about how to set up a normal channel and in most of these constructions you can just set it up as a multi-party so it's actually not that different but we also talked about networks with all these networks going to connect always two people so can we take this existing network and also the 20 party channels on top of it and the answer is yes so in order to connect others about the challenge here we have to structure this a little bit or it organizes a little bit and then we can build up on top of it but the nice thing is we don't have to go on-chain at all but we can build all of this off-chain in the existing network so the first step is you have to find a path that connects all three of these players the second step is we have to actually get rid of all of the people on the path that we don't want to actually be part of the channel so in this case we're actually going to give up and the next step is add a channel contract a multi-party channel contract to RSA channels just as we would like to build another virtual channel and inside of this channel contract you can now put any kind of multi-party application that you want to run for example all of the vent but basically on the outside when we talk about channels and networks we already have quite some potential to look at and multi-party channels could even work so for example Bob in this case connects Alice and Charlie and when they want to play a game and all of them let's say invest one coin then Bob has to be able to pay out two points to Alice and Bob has to submit one coin to the channel contract and Bob has to submit his own coin that Alice might win and one of Charlie so two points into this channel contract and the same actually on the other side as well so when he's technically only playing for one coin he has to submit four coins just to make this possible and this is quite bad when you have a very long channel with a lot of people so you have more and more pleasant so it might make sense to relate for a long time I need to actually build a new multi-party channel directly on the ledger because many came with this problem nevertheless it is possible to use existing networks and new multi-party channels on top of it and for low for a low amount of money this makes a lot of sense okay so another thing that we looked into is how to progress the state in a channel one that we've seen so far is this step by step where you always have a turn so when Alice's turn is she provides her input then it's Bob turns Alice's input then it's Charlie's turn who confirms both Bob's and Alice's input and then actually meeting two more turns until all of the inputs are confirmed so we need quite some steps while this is free party so it's not so bad but we feel a lot of parties might take quite a while until all of the inputs are confirmed and unless we have the lay step so unless we have all of the confirmations we never actually know if this is something we can freely enforce function so another way to present states which makes some sense in large multi-party channels is to do it in parallel so everyone in parallel puts their inputs to everyone else so this is a lot of communication end to end then everyone runs the contract function on all of these inputs so that means to be like some sort of sorting there is no first contract served in this way but if you don't care then you can just run one function on all of these inputs and everyone sends around their confirmations on the next state and then in two steps we have all the confirmations and all of the inputs in parallel and this is two interesting concepts I don't want to say which one makes more sense but it's interesting to have both in mind when you design a game because some names are really made for each of these standard compression models because when you have a sequential game that covers it really one step depends on the next one so it really makes sense to go in a sequential way but if you have for example if you want to generate randomness everyone has to send their input so it might make sense to use a parallel approach but if you mix them have steps related to parallel and then have other steps then there is a third thing that I want to highlight which is what happens to the party boards this is kind of easy to solve because one of them stops responding while you stop but in an end party setting it might make sense to actually want to continue running the game even if one party is full let's say you're playing over and one of them doesn't have any funds anymore so you cannot continue playing but the others might want to finish their book thing but on the other hand they don't want to have this empty so the party that kind of lost already to confirm every step because where would it be so you want to maybe exclude part in a channel and this is another new concept that so far was not very interesting and there's actually two cases that we exclude partisan the first one is when this party agrees which might be the case for example when this person is like okay I lost the amount see I confirm the amount so this you can do off-chain you don't have to go on-chain but then there's also another case where some party simply awards funds what they like and in this case you have to go on-chain to change the underlying concept rules of the concept rules but still this has to be designed on the main level because it's really important that a few of us cannot exclude someone if they want to so you have to be quite careful about the security why this is an important feature in this kind of contract of these kind of games it's also very dangerous to do a lot when you design a game even worse than this is the fairness problem fairness is in general something that is really hard to achieve in multi-party scenarios and this is always tricky when people start to pollute so in this case let's assume that Charlie and Bob could pollute against Alice in the Roulette exam as we've heard before from Tom how you generate randomness so how you basically determine the winner in Roulette and give me the old steps so first anyone who messes with a randomness and they reveal it and then they run a function which says who's actually the winner so if Charlie and Bob pollute now then Charlie actually in the sixth round knows all of the information to see who's the winner so Charlie can say okay Alice actually won, we are losing these two points here so I should rather ignore and of course for Charlie this will be bad because he gets slashed and his money gets burned but for Bob this is actually a good thing because he keeps his coin and when they keep the game he still has 50-50 chance that he might win his own and Alice is going so in the end they will they have quite a high chance of still getting some of the money so it will always make sense for Charlie to reward and it's really hard to protect against this so one way of protecting ends is with very expensive punishments so Bob or Charlie must use that much money that it cannot be worthwhile to fund this pollution attack but this really is gross exponentially with the amount of parties because now also Bob would pollute with Alice so he must be able to like Bob must be secure in case he won and it's getting really bad when you have a lot of parties and the other idea is to have external revenues to agree on maybe some block cash in the future that also adds a little bit of revenue so Bob Charlie won't be able to see exactly who is the winner when they have to reveal but still this is something which is really tricky to design and something that I want to mention because it's important to keep this in mind when you design your party child and children's and now I hand over to Sebastian who is going to present some details about the future Okay, hi I've been working on the implementation of this stuff for a few months now and 10-15 years so the first thing I want to talk about is some general thoughts about what should be included in the stage of framework what should not be included I mean this stuff like general rules we decided on what to include so definitely what should always be included is the protocol engine everything that defines the protocol and this also includes the general logic just in this case and of course the very important is the persistence because you run an off-chain protocol an off-chain application you always have an assist for example say now that the signatures that you receive are signatures that you send keep track of the nonsense keep track of other data maybe you have some micro-products that you execute so all of this has to be consistent if you design a framework you have to think about this how you persist it and when you persist it you also want to have an off-chain wallet so you might design a system to have a family of keys we talked about this right this sometimes you want to generate a key for each channel so then you would have an off-chain wallet that generates those keys but you don't have on-chain wallets so this is also something that makes sense to include and then of course because you now have a complete off-chain application you actually have a networking application so you have a wired protocol so you design a protocol so this is nothing that really communicates with the blockchain I think this is really the protocol how the different participants in the network communicate with each other so for example you want to agree on a channel you want to agree on the participants you want to agree on the parameters that the channel is working on so you have to exchange messages this is also something of a wired protocol and things that might not be included for example an on-chain wallet so you probably want to send you a request call back to the user or for on-chain funding of all the channels so you also probably don't want to keep track of on-chain keys so that's also that's also the reason why sometimes you might want to implement this all as for example a metamask extension so you can relate so you can create a metamask to this awesome stuff that you do with all the on-chain and you also don't necessarily need to implement a network communication so it could be that you only define the messages as you define the wired protocol but maybe you develop a library that hooks into another application so this application already has some kind of networking layer so you can just duplex the communication here you just send callbacks in case you send this message you set up a subscription then you get messages that are followed to the framework so you don't need to provide this and then of course the framework itself doesn't necessarily the apps is like another concept inside of this on top of the framework so one thing we can do is stay channel SDK this is what we're doing right now internally so this is the first step this is the inner core of it that's the library so the stay channel SDK is this situation we have an application and it already uses the Ethereum blockchain and now we want to enable it to give it a stay channel so we plug in the like a stay channel SDK for example the library and then suddenly you can also do off-chain direct transactions the complexity of the whole channel protocol of course should be done by this so you have to design a very nice API that makes it as easy as possible to extend your application so it should be easy concept like okay I want to connect those two people we found the channel and we said something that should be very easy and we also think that it's very important that we can make the developer to inject or provide some mechanisms like logging and the networking stack and the persistence stack so we define the persistence on abstract level and then let the developer inject same SQL database and use this whole system and then the next step is to have this is something like the lightning node, the LND node so this is a full-blown standalone application so the standalone application has all the logic for handling the stay channel networks but on top of this it also has an interface which can communicate to the application so it's very important that it's actually a bi-directional interface because in channels you always have this situation that you want to have callbacks to the application because you may receive a state update from the other party so you have to ask back to the user how do I handle this case that now I received an update and so in this case you want to send callbacks back to your application but there are also other things that you want to like hide for example at least give them automated dispute handling so you want your application to watch change and handle disputes automatically for your user not necessarily have to use it it's a very interesting touchy principle yes and then you also for example you can design in such way that you have on-chain callbacks to the application for certain on-chain actions like funding of the channel and then this is the third level is really to have a hub server because I mean we didn't really talk about this much but state channels really become awesome the moment you build networks this is also by the lightning network it's pretty awesome so you want to have some central server hub server and it should help other people to build virtual channels that's what we call virtual channels applications for this network so the idea is probably that you have some depth and the developer of the staff wants to enable users to use the staff and the very interesting way to do this is you give state channels and then you run the hub server and then you let all the people connect to your hub server and then you can help them open two-party or multi-party virtual channels over your hub and yes so do you think the hub server should extend the client node or should this be a separate feature? I think that you probably would have the client node and the hub server both around the library around the core SDK but they're probably kind of separate I mean I think the implementation is more of a shared code but I think at least that's what I'm saying and it is something kind of separate because I think the hub server is a lot about the whole logic about handling virtual channels helping the virtual channel whereas the nodes are more the end nodes the end clients that is what I kind of know that makes sense and yes so just a very brief notice on what we chose for the package so we chose Go but a lot of people are using JavaScript and I don't think any of it is good or bad it's just that many people did JavaScript and we just wanted to try something new that makes sense for some like standalone type forms of applications so it really comes down to the use cases for example you can have a browser extension that's what we saw a lot today and we can have it as a library that is the SDK was talking about and it will be a standalone application so for the browser case it makes a lot of sense to use JavaScript and we think it makes sense to use it and the directory tooling is actually much better for JavaScript but for example we also have some IoT use cases in mind and for those IoT cases we think it makes a lot of sense to use Go it goes less known so the reach is a bit slower but yes and then it's a type in the client language so it's a new type as a JavaScript just briefly talking about architecture that we have internally so we see here some layers at the bottom you see interfaces I'll come to that shortly then you have more protocol engine then you have on the left blockchain backend I call it and then you have some generic type database logging networking then on top of the blockchain backend we have a channel application we design the whole system using the protocol engine has no direct dependency on anything specific no Go Ethereum no dependencies and say not for us for logging no dependencies I don't know like TCP so it's really all going down to the interfaces so that means we define interfaces which say that's the way we want to use this stuff if it were to exist and then we use it all in the whole protocol core and then we implement all those interfaces as a blockchain backend database logging everything and yes and this is a very very nice decoupling of this whole software so that the core protocol because all the protocols you have seen today the stage and the protocols are a very generic concept it's an absurd concept I think you also talked about it like Cella they're doing blockchain agnostic between protocols here and this is like you can take this even further and say actually the whole engine of this protocol, the stage and the protocols is very abstract so for example if you also look in the parent papers they are written in a very abstract way so for example it only has it models the blockchain as a ledger, as an account based ledger so this is a very abstract thing it is not tied to any blockchain yes so I think that's nice because it's always coming back I'm very curious for your advice you will not use it by the time they will use it that's actually a very good question I think I have a backup slide I think I'm going to open this slide first yeah here it is so when you're designing this in an abstract way suddenly many many things become quite complex you can identify a couple of concepts for example addresses you have the concept of an address but you don't want to specify what is an address so this is all an interface so you only say okay what do you really want to do with an address you want to check that it is equal to another address so you give this interface an equal to method and you want to sign with your okay so actually you also have the concept of an account so you have an address and you have an account from this account you can sign with it you can verify so you have something called signature but it's just like an abstract signature and then you can verify that the signature belongs to this address and yeah so this is like one of those concepts so it makes things more complex but it's also nice because it forces you to really define very well interfaces and really forces you to understand when you design those protocols this layer where what separates really the protocol from implementation specifics it's quite interesting and that's the same here on the top that's like this blockchain interface so what do you really want to do with a blockchain you actually just want to interact with the adjudicator in those ways you want to fund different channels you want to watch the adjudicator so there's this concept of watching something but you don't really need to go too much into detail you want to say okay watch this channel with this ID for something bad to happen and then you can react you want to dispute or just like register states adjudicator and you also actually the settling yes I just want to show like a short program what we want to do so we receive the grant from the German government research team to develop the stuff we are going to release this SDK for ledger state channels and we want to go to virtual channels virtual channels again is this concept of having several channels that you connect together to a long virtual channel to build networks and then we want to go to multi-party state channels and have a good observer and then we also want to do additional because currently obviously we're just concentrating on ethereum because it's like the nicest blockchain to develop on right now and finally we also want to state channels and plasma chains so instead of having a blockchain as a back end you have a plasma chain as a back end so this is the nice thing if you have such abstract concept you can really just provide a plasma back end something and you can just reuse all the core engine and just have a plasma back end that's it ok everybody last part of the state channel session today is from us we will have a look at challenges in the human channel networks and especially to discuss design dilemmas from a system architecture point of view as well as from a user experience point of view and basically share just some of our experiences that we encountered along the way of developing this yeah my name is Francie and I will soon also talk about stuff later on our overall goal maybe shared with all of the other projects that have been presented for us is making all building standards with such less applications on top of Ethereum as easy as possible and yeah surprise what we encountered along the way was getting the user experience and the system architecture right for this is really hard so yeah before we dive into why it is hard I just want to really bring up what is right in case you guys don't know right in this payment channel network it works with any years in 2020 compared to the other talks before we've been somehow shifting between generalised state channels and payment channels and can be compared to for example the lightning network on this point it has a really really simple idea and yeah the very core idea of this is that we have a payment channel and this one is always backed by an on-chain deposit and once you have deposited topics into this payment channel you can do as many off-chain transfers as you wish by exchanging balance proofs with your channel partner and those balance proofs you can just imagine as digital to checks you send something back and forth and eventually you say yeah I want to you withdraw your funds from this channel the cool thing about rating exactly as a value is that you cannot only pay the people that you have a direct channel open with but you can also pay anybody else in the network as long as you have a connected path of payment channels within receiving party but that comes with some challenges and that is what we will talk about in a bit so our status is that we are live on-manage with a limited alpha version since end of last year and this version is featuring all of the core functionalities that you can imagine for payment channel networks so doing direct transfers mediated transfers and so on but it's pretty limited in terms of user experience as well as in terms of which token networks you can currently use it with right now it's limited to revenue and yeah there you just see our current payment is pretty pretty small still but we hope that we can make it a bit bigger by improving all the things that I will discuss now so yeah let's take a moment to talk about this magic as I call the user experience and why it's maybe not working out yet so well I'm trying to test this into two different user groups because we have basically the direct end user that wants to make a payment using right now and we have the target group which is actually projects and developers that want to integrate with RAIDIN into their application while the user themselves the end user will not really know that he's actually using RAIDIN by using this application so first market is the actual end users and those are experiencing or might experience some challenges when they want to interact with payment channel network for example first and foremost it's really about education or also abstracting where technicalities the problem is I don't understand the logic of payment channel network and I also don't know how to use them the most interesting part of that is that most users don't understand the idea of a network you can send payments to anyone you don't need to open a channel with them this is like the number one problem that we see of retirement then the second problem user interfaces are cumbersome to use that's definitely also a problem on our side how can we make things easier not thinking so much from the technology perspective but rather which comparisons can be used that already exist in the real world and that people are using it for example they are banking into places then another problem is I definitely don't want to have to be online all the time and I totally want my payments to go through like why shouldn't it go through and last but not least I don't want to run a note what is even a note and why do I have to run it so yeah a few of those problems we are trying to tackle with the next release that's upcoming the first two problems I don't want to be online all of the time and I want my payments to go through they can be at least improved by introducing services so on top of that you will have very soon service layers already now live on the testnet which will come with monitoring services and with pathfinding services those two are like third party services that can be provided by anybody who wants to join and will be part of the brain services registry and yeah they will really just improve user experience the monitoring service will basically be a watchtower for example if you are familiar with PISA they are offering watchtower services and they will basically just look after your channel if you go offline and solve this problem with a challenge that we also talked about earlier on the talks and then the pathfinding service will basically just give you cheap or short routes through the network so that you can be more sure that you can actually go through faster then a really huge problem is I don't want to run a note this problem we have two solution approaches for the first one is that we can work here in the last couple of months on a live client it's still work and progress but you can already test it out and here in the back you will see how the live client is performing and trying to reach a full note the live client is compatible with any web3 and a web browser so basically you can just use a weather mask obviously it also has some user experience challenges right now like you have to sign random hex strings and messages which is really cumbersome but we are getting there and the interface that you see is basically the first reference implementation of the live client SDK the second option you can try this out if you like the master is always live as liveclient.rate.network if you want to try it out it would be great to talk to us after because now there is only one token that we have deployed for testing that is the TTT token and if you want to mint this or if we should send you some tokens just let us know I also see Kessels on the back who is our live client master so just talk to a nice green man on the back for the live client option number two is we can also help people to make running notes easier and since this is a decentralized system for running notes so make it as easy as possible one solution would be to go with death note writing is available on death note both to the testnet and mainnet packages so if you are already running other notes via death note it's basically just one click and you can add your writing notes the other option is help with onboarding tools in the past it was really difficult to install writing if you are not technically you will not be able to do it in the past and now you are able to do it because we have developed something called the Rain Wizard which basically installs and launches for you all you need to do is download it and double click it and you have to have an infura project like this one because we assume that people who don't want to run a note and who don't know how to install it might probably not run their own note but I assume in future it will also be possible to connect to your own serial note if you have one and yeah then it does all of the stuff that needs to be done and yeah it takes only 5 minutes or 4 seconds and that one you can install without any help needed from our side so you can just go to our githubrain.network.com rain installer or scan this QR code and it's available for Mac or S and for Linux for the testnet for now but for the next release we hope to also have it for the main entities and then the challenges from the other side so projects that want to integrate with rain they are also facing some problems the first one again kind of education abstraction problem definitely people or projects developers that integrate when they don't want to have to know how payment channel networks work and what we do in the back end so to use it in their product second problem I definitely don't want to force my users to run a note also next to the last problem I don't want the complexity to increase I really don't want the worst experience for my users it should be basically seamless and then also the third problem I need certain features that I don't find in the range right now so maybe it's all suitable for me some of the problems we can solve for example not understanding a payment channel network yeah please don't all go and learn payment channel network tech now because this should be inspected away for you we try to make it as easy as possible by offering a really high level API which should be self explanatory we are also working on some good new documentation we have a fairly we have a fairly long and very extensive documentation already and now we are trying to develop a new documentation which is very easy to understand so we are basically powerful very extensive and very easy to understand we have a developer portal and we are also always available via our technical help chat on Githa so in case you should have any problems just give us a short yeah basically don't want my users to run a note that's how the back end of the RAID9 client SDK would look like we saw the front end before yeah just integrate with the RAID9 client as soon as it's ready you can already try on the tester I need some features that's not a problem at all because now that we have basically 11 all of the core components and features that are the basics for payment channel network to incorporating whatever feature you might need we have already started with that so some of the projects where we are testing a channel with draw feature which means that you can simply withdraw certain parts of the funds or all parts of the funds without the need of closing a channel this is interesting for example if you want to keep this channel open because you know you are tagged with this person a lot but maybe you are the party always receiving funds then you might want to cash out once in a while without closing the channel and that is now possible with the channel draw feature and it takes less on-chain transactions that actually closing the whole channel opening the channel again is a lot easier and one other example is the guys from exchange union that just launched their swap between Bitcoin or Lightning and dye of RAID9 and they've been also really closely in touch with our developer so yeah I guess we are going to have some feature implemented just to let us know we can talk it out and then looking over to a business part UX is obviously not only about the front and sub and features but it's really influenced by the other like system architecture and yeah we will talk about that one I just want to share with you guys what are some of the consequences from the use of int perspective and design wise what are the consequences of our design so let's just start with what are we doing here we are trying to fix this right now so the idea that we have here is that for blockchain systems you can only pick two of these three possibilities and we want to fix that so that's why we are building stage channels where you can actually have a scalable solution that's also secure and it's also decentralized so that's sort of the big O of every single presentation that we have had today and from my interpretation I think the biggest problem that we have here is that it boils down to communication because if you have a proof of work of a proof of stake system you actually have to share the data with a lot of nodes and then that's actually what removes the scalability from the system then we have overhead that we have in communication so what are our design goes and how are we trying to actually fix this for them so we really want to have a very high degree of decentralisation we really want our system to be completely decentralized no hubs hubs may appear in the network if there is highly connected hubs that are trusted by the users but we don't want that to be part of our design we want to have by design a decentralized system we also want to have it very secure and a very high performance system so this is our goals and I'm just going to try to tie together like this what are the consequences of the UX perspective what are the trade-offs that we have so one very important trade-off that we have is that if we want to have speed we may have to start in trustlessness we sometimes have to in some circumstances we have to sacrifice speed so if everything happens on the happy case but it's very hard to actually explain to people the sad case when things actually don't go so well and that can happen for a few reasons the balances of the channels in the network are actually changing all the time so you never really know in a distributed network like a payment network like Raven if the channels that are trying to use actually have capacity when the payment is actually going to go to them so the payment itself may just favour something that you have no control whatsoever it's just like the nature of the decentralises it could also be that it's just bad and one of the guys that are trying to communicate with just went offline and that's just the truth of the this one and from my user perspective that's very very hard to explain why my transfer is set in 5 minutes to fail because it takes six hours for transactions to remind on-chain we have to take that in consideration and then we define the expiration of the hash time lock and that sort of goes back to the user in a very unexpected and unpleasant way so just you show that in a more clear fashion when we started transferring between the left side it may be very fast actually to be transferred if everything is successful the capacity is fine every node is online so the thing is going to be fast and business is going to be happy it's going to take a lot of time and that's one of the things that we want to actually at least improve in system because we cannot actually fix that it's inherited to college works right now what do we do yes why don't we just like lock funds into the path before you actually make the commitment transaction that's exactly what we do we first lock the funds and then we review the secret backwards and then everything is going to be unlocked but in that case the locked payment failing shouldn't be a lot of time out so let me go back a little bit so I'm trying to lock the funds and right now I'm trying to lock funds with the channel Charlie if Charlie is offline we cannot lock the funds does it make sense right so what I'm asking is from a user experience perspective what you're doing is A is basically committing to the transaction to B when they initiate that transfer and so they have no ability to back out of that transfer one second that happens what I'm saying is if you separate out the process of you reduce everybody's balances then you make the transfer into separate steps that means that you can decouple path finding from actually making the transaction so if path finding fails you can have like a three second time out okay path finding is completely decoupled you can do path finding at any moment the thing is you do not know if the path is actually going to be successful that's what I mean is you just lock the value in the channel as part of the path finding itself and then those transfer until later and that locking is where the failure can happen if you're trying to lock the funds and one of the nodes is not aligned the locking didn't happen and then the nodes that actually have locked funds they have to wait until the lock expires you get the funds back you cannot escape from that if you try to escape from that you're going to end up with double spending so what we can do is actually from the user perspective we can sort of hide this but it's like there's no solution in the worst case it's always going to have to wait for the lock expiration what we do right now is that we introduce in the protocol ways of not having to wait for the lock to expire so we have a thing that's called refund transfer so if the problem is that general capacity we just refund out of the way to any shape that transfer is complete and we can try any one so it's like a better user experience in that sense another thing that we're going to work on is making it a set of transfers because refund transfers right now require twice as much capacity because you have to go the money has to be sent from the failing node out of the way back to any shape and then we are going to have twice to collateral and we want to remove that so that we don't have to actually have twice to collateral to fail like certainly a transfer another problem that we have with usability is we want to make the system work and one of the very important things that we have to do in the system is make sure that the network section is going to be balanced because if the network is unbalanced then payments simply are not going to go through the failure ratios when they increase so we have to imply some strategies to help the network balance itself and the way that we do that is that we just introduce rebalance rebalance in fees so we use a pathfine service and we through the pathfine service we can compute which path is going to be the cheapest and we always try to make sure that the cheapest path is the path that's actually going to rebalance the network the problem here is that these strategy works are rebalance in the network but it's actually very hard to explain to people how it works because you always have to take channels and pairs from the perspective of a mediator when you're actually doing that sort of strategy and that can be cumbersome to explain it so what we do here to try to fix this problem is that instead of trying to play to people and having them actually thinking about how it works we make very good defaults so we think about the problem and we just make the decision on behalf of the user and we always try to make sure that it's going to be safe and secure and it's going to be efficient for the whole network yes that's our solution we're just thinking about the defaults and a very problem that sometimes happens is that for instance it's very important for us to actually know the balances of the channels that's crucial for pathfine service to actually choose a path that has capacity to meet the transfer the problem there is that to know the capacity we actually have to share information about the payments that are happening so we have to trade off a little bit of privacy to make sure that the payments are going to happen in the network so the performance really depends on giving up a little bit of privacy so the way that we try to fix this is that we sort of allow now to lie a little bit about the capacity and not send updates out that often so that we don't have a complete view of everything that happened but we can actually choose that data to find paths that can actually work so and we that's also a very important thing we never force our users to do something we always have escape hatch or the configuration that allows them to opt out of something that we believe that may not be good for everyone in this case a node can decide to fix things at the cost of not being used as an mediator so he can increase his privacy but he's not necessarily going to be used to make the payments go through the network yeah so for the next three years we're looking at different ways of trying to fix these problems we introduced the refund transfers we are going to work on the cancer of the transfers and we are trying to figure out how we're going to actually make the plan find service more but these are features that actually we have that even though there are trade-offs we think they're important because they're going to help making sure that our payments actually go through and usually it's going to have just a better experience by not having to go through all these problems that can happen so with that I just want to say that we're pretty much cutting everything in a few weeks that it's going to have the monitoring service and it's going to have the pathfinder service so we expect the successful rate of transfers to increase and people don't have to run in all its full time anymore so please try it out I would say that we are pretty much production ready and everyone should try it out and if you have questions just reach us out in the medium channel and we are happy to help you thank you