 So we have a packed two and a half hour session to be able to date about the state channels. Seven teams talking today. We're going to be preparing for various activities in part of the year. It's going to be very, very exciting. So I, Jeremy Long, have come from there. We've been working on the state channels for the three years now. It's a core technology in our particular application. And we've been working personally with the other teams over the last two or more recent times to try and reach some standardisation to this process. We have, I think, hopefully defined all of us right. This is what we've got out today. So we've got our four magna, the X-cell and finally the brain to wrap things up for us. Certainly the, all of the top set of joint state channels group with the amendment to producing standardisation across the teams. We've all over the years developed kind of the technology independently. And we're coming together to try and do some standards so that it will be easier to develop what you are and how you can hang out with the papers and technology, such as these we're doing in Washington as a guardian. And the way that we prefer to think about is how that sort of comes together in the next few months. So I'm just going to give you a quick oversight and do an introduction to the state channels. I'm guessing some of the most few of these are 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 off-chain. So it's a their-to-use solution. What the fundamental means is that we have a theory, we have the security properties of the chain, we know how it works, we know why it works, it's a decentralized manager, and we know the cryptography underneath it. But we can use a sequence of techniques to mean that we don't have to move to a gas and a point of transaction to the mind in order to get a smooth process flowing between individuals. This is a general explanation. There are variations on this. It's generally true for all mobile participants. You generally commit, before you start a state channel, you commit some funds on chain, along with any particular properties of what it is that you want this state channel to be about, or any rules of that channel, and the initial states of the channel. And then participants are directly with each other off-chain, advancing the state of the cycle of the channel and releases that they make following the rules of the channel and signing commitments as they proceed. And once the final outcome of the channel is determined and agreed by the participants, gone-chain transactions made again, it releases the funds according to the outcome of the state. So the simplest working example of a state channel with just two participants 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 chain, or a GDX contract in this case. And we have an initial state where they both have five, and then if they make it, if Bob sends one to Alice, Alice sends six to Bob, that's four. Then if Alice sends four to Bob, that's three and seven, et cetera. These are a series of transactions that people are making and signing. So we end up with a final state with the real way that the funds are distributed. That goes back onto the chain. It is mined accordingly. So in this case, the state of the channel is just the record of who has which funds. So in order to form more complex interactions, we need a state of the chain. So the state of the chain is a term that's been around for years, and it pretty much defines what we can do in a state channel. So I've always used this definition, and they're a bit of an example, they come down to the same thing. So the state of the chain is a function, or code, a different function in advanced state. A state represents where we are in the world. It represents an action on that state, which might transfer something, or press a button in the video again, or whatever it might be, and it produces a new state. So it's a linear process of advancing new states. The functions also determine a state that has no side effects. So by determinants, it can mean that if every time you apply this action to this state, you get the same new state. This is a vitally important point on the state of the channel, as you'll see later. And there's no side effect that means that everything you need to run the 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 channel. So we're going to talk a little bit about an example of this over the first few talks. So we picked one of ours. Let's see if I can get this to work. I will talk a little bit about this video. This is just an example of a state channel sort of actually working for a user experience working to choose. So you choose in how much this is the properties of the channel. So I'm choosing how much funds to open the channel with, and signing a transaction, and that transaction is sent to the chain. So while this is a video, I don't know if it takes ages. So behind the scenes here, the other counterparty, which is the housing arc. In our case, for example, there's also a science transaction. It's also committing funds to the chain. And so this is the set-up phase. They do very badly with this. So let's see if I can skip 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 the 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 type of the ball is spin-muted. Down in this corner you can see these are the balances of the player, and the house of the two people in the channel. So these balances change as the game progresses. So each of these, I think we'll try to think about it tonight, and I don't know if it was far represented, so stay in position. And we'll talk a bit more about that. And then when we get to the end of this, this is just verifying this contract. We will want to close the channel. So in the side of the transaction, which is what this is going to look like behind the scenes here, in the side of the transaction it says the end of the channel is agreed by the two participants. I have this part, and the house has this part, and it's in that transaction, so I'm going to check. And what's the end of the game? So in order to look at this work example, we need to do a lot of things. This is sort of the first half of the session. We need to implement the rules of this game in a state machine. We need to establish a protocol for orderly state transition as the game plays out. We need to implement security against bad actors or missing actors, actors and people who stop participating in the channel. We need to talk about how channels are funded and how you're going to come out at the end of that. And then we're going to talk a bit about user interface design. And that's pretty much the introduction to this, so I'm kind of too severe for who's going to start working on WeChat. So, yeah, 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 a state channel. 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 example, I'm going to explain at the abstract what is within the state. So let's dive into that. I'm just going to set a timer for myself so I can go into it properly. So what does the state contain? I mean, if there's questions, please, like, chat them out, because this is, like, it took a long time to be able to come up with this. 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 sent for a company. You need to know that. So it's in the state. The list of addresses. Two is the chain identifier. Is this main? Is it rocked? Is it ringed? What is this? You need to know what the chain identifier is. Three is a unique identifier 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, because this is, say, channeling to keep track of. It needs time here to make the version number. And again, this is somewhat obvious, but it's important to know this is in every state object. You'll see why in a 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 on your channel for all channels, you keep track of if this state was the last state ever. You know, for example, in the real-life game, you'll see some examples of this. If it just ended there, you need to know who gets which one. Right? Is it a final state? And state channels is a notion of, like, 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 challenge period, because as 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 as a necessary and important part of state channels, what exactly defines how you move from one state to the other. And the application-specific state data, obviously, like the 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 translator. Now, normally, maybe, as a challenger, you sign each state update with everybody, but we're going to describe how that can be a bit more simplified for each individual state. You just need one signature to move it forward. So that's in English. Yeah, question? So it seems like some of these are initialized when the channel's created and then they never change, but then other ones that they are... Exactly. Okay. Yeah, sorry, I'll say exactly that in a second. So this is back when I subscribe, but it's validity types, okay? So it's pretty self-explanatory. Some of these are, you know, the rest of some of the numbers are dynamic data types. And you can see to your question that some are fixed, some are dynamic. The fixed parts to this and the entire iteration of the state channel came. So on a good example, you'll see all this. The same people, the same blockchain, the same unique data file for this channel, the same channel's duration. I'm going to... You could make this an app, but it's included, it's static. And the same state machine, which is what we call the app definition. And 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. The app data obviously changes because you're pressing the state. Because it's final changes because you might get to the end, and the signature changes because each time you get a new signature. 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. And so here you can see an example of how state is progressed between two people as they pass the ball situation here. One goes, then the other goes. Then one goes, then the other goes. Then one goes, then the other goes. And it's always another one. It's not one... 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 consent, you want to move through each person for simplicity. And so, we have this concept of mover. The mover is pretty straightforwardly. It's the person in the participants' list who is turned on... For synonymous, it's modular and full list. So two is pretty straightforward. It's 01010101. 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 bought. 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 this final modifier, anyone can exit at any time. Now if 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, say it's also final, it's over. So this is not always something you wanted to do. Usually it's going to be not in your favor to just end abruptly. For example, if you're seeing 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 what you're doing to your board, usually this is a quick property. But it's a useful property because you do not want to have your money 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. In a payment channel example, it's more simple because you can end the payment channel at any time. I'm done with the channel. And then some of the core state channels are just in logic, is operated on by this valid or just in function. The way that state is considered to be valid, validly progressed, 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 will be there's a number. The next logical state is that number plus one. So here you can see the most basic statement which describes that state machine. You want the s2 counter to be s1 counter plus one. If it's not, it'll obviously this will work. So error will not be a true outcome. And so that is function search. So Jeremy was talking about advanced state. Is there a difference between advanced state and valid transition? Yeah. So this is a nuance we want to be, I can explain it now, but it's a nuance that we didn't want to put too on the slides, but basic, I'll say it as clear as I can. Valid transition is a function that defines that if you have two states, if you want a valid transition on them, it should be a certain true. Advanced state is, from the way we look at it, more of a 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 have the X on it. So we have three things. We have the previous board, we have the action, we have the new board. You can write a function, a valid transition, which says take the hash of the new state with 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 compare it as the hash of that equal to the hash of the new state being proposed, which has two in this case. So the hash of, basically the second state is equal to the advanced state of 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 high UI applications or we develop a point of view or maybe that's a bit more simpler to think about. I'll show you this slide. Because this could be not a term for this. So there's one thing I didn't, well actually it can't be because it's pure. And so every, so it's actually is the term in the state based on the state. Yeah. 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... Yeah. So like you mentioned in that, and for this, yes. However, that thing I mentioned you can write on top of this generalized version that you do have access to that. Okay. That's more of a way of describing it. For example, I think like architecture could be defined in different terms. I was just thinking in general essentially like if it was hard to, like if the state transition was complicated without the action, it might be hard to actually like calculate whether or not that's the property in the S1. Yeah. Always put the action in the state. Right. Just like how you define these things. Yeah. That's how I'd recommend it for application building purposes for the raw protocol definition. Yeah. It's a simple abstraction. So that's my part of the talk. So I'm just going to describe that's the shooting in the country. Okay. Thanks again. So what Liam's just explained like this is the structure of the states that are going to form the state town. 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. And we're going to talk about the application 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 just run through how this works. Each player either picks red or black and I say each player we're looking at a two pair scenario where that's confusing. What we've got player and a house so it's the two participants stage channel here and the other is the participants the house so the player is either red or black the house then decides and then an amount wager on that color 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 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 commuter wheel scheme which probably is familiar but I'll explain the next slide so in order to write the roulette 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 corner in the start stage the start stage is the balance of the house and the land in that state and those amounts should match the amounts that are deposited into the channel as we'll see a little bit later the next step is the proposed step so this is the thing that the player so like as as you said these plans take turns so we're going to start and start the proposed is going to be the thing the player does the house is going to respond to the set the player is going to respond to the reveal and then we're going to go around around taking turns in these states so to start the game the player formulates the proposed step and doing that the proposed step has balances if they compute the wager in this case the player wants the wager to they choose their colour and then they commit to a random number and they commit to a random number by providing a hash of the number that she had chosen in this space 4 and some secret value and that's the thing they made into the state and they sent that over to the house and out of the house they said look at that am I happy to accept this bet they decided 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 is 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 full position so like to calculate that full position they add together those two random numbers modular 36 37 37 37 37 to generate that random number in zero and then in fact they reveal their salt but they use to hash their random number so that the house can verify that they're not cheating the number that they're using is the number they've been admitted to and they calculate the winner and then they update the totals appropriately and then they can continue around this thing as many rounds they want to do so these are the different states and this is how we're going to model this like relapse game in our state channel so when we're actually writing the state-tell contract we need to encode these states and we also need to encode the valid transition rules between these states so if the if you start in a state what are the possible values for the post state that the player can craft there's 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 you know what these rules are going to be the first rule here is the house balance can't change so we can't have the player like formulating a bed and something like taking all the 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 house balance and the wager has to be smaller equal to the player balance choice has to be red and black and that's it so these are just like pretty much like date validation things this would have to be cleared up into a smart contract to check for two things about it actually do you have a question about how the house would not start it has to be cleared 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 like we'll come to this later bit late one of the problems about the entire state is that one of the problems in state channels is if one player stops responding and that's the thing that you need to get the chain involved and you have to be able to say you're not responding I'm going to challenge you on chain by the next date and the chain has to be able to check whether the state you've provided is valid transition so these rules do need to be coded into a smart contract and this is like the mispoke part of each different app in your writing okay the next one is a proposal because you get a little bit or anything 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-speed preview it's basically because you're thinking what happens if the player doesn't respond to the next step basically if the player doesn't respond to the next step let's deal with that later so these balances have to have to update like this that's the interesting part and then there's some bookkeeping stuff like the way you should change the choice shouldn't change you can't have the you can't have the house changing the players better and run and commit to change the next one is the step to the reveal this is where like most of the project of the actual application is so to make sure this step is valid we need to make sure that the player has calculated the joint random number correctly and in doing that they've used the value that they've submitted to and that's what this does basically so if you look here we're calculating what was the player's random number by the difference so full position house of random number and then we're checking that when you patch that with the sole that was provided you get this this random value from the last thing and the other thing is that you have to calculate the winner correctly now that's just that that's just described in words earlier about if it's red and even and not green and 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 fact that you said wrong then finally going through reveal back to the start just need to make sure the balance is the same okay so what I guess what I've just described there is the game specific parts of writing roulette as a straight channel application combined with that are the framework parts which is some of the stuff that Leon alluded to so um so here's the state what I'm showing you here is how we actually take that like game specific art 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 showed you today so we've taken that like game specific stuff and we've put it into a load of framework stuff so that things like participants the addresses the signing address the participants got an array got a chain ID a channel nonce the channel nonce pitched by the players to make sure that the channel ID is unique I'll show you that on the next slide um but this definition by writing roulette there I mean the address of the on-chain smart contract I've coded up the rules like so it's the first state and everything the outcome is what people would get if the channel stopped in this position um that's the house balance the player balance in the state um and then we've got it's not final on that signature um so the actual so we've got like the game state the game rules and that's put inside framework state which has this extra stuff and there are also some framework rules which define the how these states are allowed to update so the framework rules cover things like participants can't change the channel ID can't change the turn number must increment and so on um and I don't think we're actually going to go over those in these talks but you can find those um by now more about that if you're interested um okay so this is how we construct the player with actually craft um in their software um 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 like identify this channel and that's going to be important when we start potting money on the chain for the purpose of this channel um this is going to be like the channels identifier um and we're just going to call that R123 but in fact that's going to be a byte 32 um value that's going to you need to identify that channel and it's one of the participants to make sure that that is complete so together they can make sure that that channel on they can change that channel on to make sure that they know they can repeat the channel ID um and they that's one of the things that they have to take on they should never enter into a channel with a duplicate channel ID what do you enforce the channel um um seven participants so the next the first thing is on the off-chain off-chain code it's not not on-chain not on-chain it's on use of participant to make sure that you don't enter into another channel for the same ID so the first thing like in addition to all the other off-chain stuff I have to remember also need to make kind of a copy of all the non-side deals that you've used for each participant you know you can also do things like you can get around this by the the addresses at the top or it can be a formal addresses so it might mean that your software just generates a brand new address you use in every channel you enter into and that's another way of making use of this requirement you can go randomly or you can do it by storing the highest non-side of each just want to confirm the on-chain does not care so it's actually possible to see kind of like a reaction of the of the channel yes so a lot of these channels a lot of these channel IDs the chain will never know anything about the the program so like the chain really can't keep track of that for you you have to do it okay then for the first of this talk we're going to analyze some unimportant fields so I'm basically going to hide a lot of stuff that just stays the same and so this is what I'm going to be looking at and what I'm going to see if I state how an interaction in this case how it would actually work with all the updates in this format alright okay so this is the this is the first state we start with the player formulates the state you can see it's got like the start state in there and send it to the house and the house is going to formulate this next day and send it back and what the players are doing here is they're doing an opening kind of shape so we're doing this round where they're doing we call this 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 players safe it's basically their key to releasing that money if something goes wrong so both parties now hold two signed states one of each of their signatures on we call this the support proof for state one it's like suddenly you find the chain to show that both players like agreed you got to state one it's like I guess the format is like signature of player one valid transition signature of player two they've got like two states joined together with two signatures on there that's like a suddenly induced improvement the chain to say they're like agreed we got to this state you need both to check the turn number at the higher level to know yes you need both I mean if 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 involved otherwise I could do it unilaterally I could just like like I could create state ten then that to the chain and then and I could do that without any involvement it basically the reason is because we do this term taking stuff as 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 into that but after you send your signature say say the the party that sends the turn number one that he has no confirmation the other party received one seat yes let's say that's Edison Bob Edison zero Bob Bob sees the Edison one seat then calls them back then Bob will send the new turn number one okay so what happens Edison zero to Bob and then Bob sends one to Alice at that point Alice has zero and one and Bob has zero and one and when they both have zero and one then it's safe and you can also unchain 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 which is going to cover events so at the moment we're going to have adjudicator you can 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 this 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 they can then deposit so the player is going to first they have so they call this deposit method and they're going to get the channel ID and amount stored next to it and then the house deposit and you end up with the channel ID and the can stored next to it the ordering there is important the ordering there has to match the ordering of the participants and the reason it has to match that is because that's the order they get the money out in so like if the channel is only partly 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 victor of stuff the leans do okay so once they see the coins in the giunicator 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 staged and this is again part of the framework transition rules and that is to for both the participants to like acknowledge that they know that this journal 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 the first two are being the pre-fund setup the last two being post-fund setup and now we're in a position where all the participants agreed to open the channel we've funded the channel and now we can actually start running the algorithm which is what happens next so 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 in a random commit so that is the post state and the house just gone with this exact state and a random number we then start the 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 this like framework state that's around them suppose now the player wants to start stop playing so what I'm showing you here is a half case of the state of the state channel that you play you can conclude collaboratively so in this case what happens is player then signs the exact state but putting its final to true so this is where both what's going to happen here both participants are going to sign off on the final state so the player signs the state the final true final state final true they're then both holding two states with quite this final true we call that a conclusion proof so like it's like both both players have signed up on this and that's evidence you can give to the sustain to say we've finished this channel practically 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 like stored on the chain and at this point we say the channel is finalized the outcome that we agreed off chain has been registered on chain and it's the final version of that channel so this is how you do that two method two method checks that both of those are like final states and they're about a conclusion and stuff and then finally the final step is to actually get this and the way you do that you call the transfer so transfer on a channel it looks at what was in the adjudicator you'll see that there so like we've got this final outcome transfer first pays out first pays out to the first thing in the outcome it sets that to zero and then 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 the end is now going to talk about what happens when things go 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 adjudicated contract which is responsible for the one per lake going from channel ID to outcome and then we have a suite of asset holder contracts one for each token you want to use those data answers like an E-class at holder it's an ERC 20 asset holder but it's pretty important that these things are all in the same contract when you get on to having like more advanced channels to fund for another because they need to be able to send money even in the contract to each other are there any more questions if I hand over? So great that's how it's supposed to work what can go wrong I'm only going to talk with the two most important cases as one subtle one I'll also talk a little bit about the end of those important scenarios one is the player is playing and he's sending a state to the house house accepts it and he's waiting for the player to respond and nothing happens it's just the top floor is just waiting and specifically when this matters is in this example right here where the the player gambles 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 like oh shit as we lost and so this week what happens in this scenario you know 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 a supported state that shows that the player chose this after this choice I accepted it and now the guy's not responding so forced them to basically by initiating a time so you pass them the last state where the number was eight they had proposed their state you pass the acceptance of it you take them up bundle them into the contract and you push challenge and what happens is it puts this data it's supposed to end at seven three 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 doesn't respond to this challenge the house should win it's basically what that means is that if this was the last state the player just left which is a so we say seven three I want my money accepted it and it's a timeout match and that's the timeout to the length of the state the challenge duration I mentioned earlier and you know this is basically what the API looks like and if the guy doesn't respond after that timeout is finished you know the number of blocks is passed more than the sum of the challenge duration then basically it's considered to be done and in the same way that you would just mentioned when the chain says you know seven three that's basically seven chains now seven three 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 boom protocol if anything at any point in time goes wrong you can push this button and force your counterpart to make their turn so they're forced to pay as if they were doing events without any they're forced to respond in some way they have five each they both yeah they both have five each in and in the states in this when the house accepted the bet that the player made the outcome was changed to be the house one at this point 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 that the player won in the next state however you know ultimately maybe the house won that's because they were the same as this situation so that's basically what happens here is you force them to make them move and the only you want with is something that passes the biology tradition that passes the talk about so you're forcing the state machine forward so that's a challenge however there's another version of this where maybe the player just like went out and they weren't actually trying to not you know not respond because they thought they lost maybe they actually did win they just like closed the laptop for like 20 minutes or something like that they lost self-sufficiency they lost self-sufficiency something like this basically they should be able to respond right that's my way of time and so pretty straightforwardly you can imagine the state exists which is the right I mentioned a second video because they revealed and in fact they didn't choose a good number they chose red it was red and the most they should be able to do is take that go to the giudicator 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 the challenge basically gets erased and they can keep moving forward so you can just keep playing the game off-chain until something else happens whatever ends up happening 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 that's like 99.99% of the failure cases the only other failure case which I didn't put slides hard a super quick to explain is maybe 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 checkpoint and pass in the future state that's way in the future in terms of tenant or whatever 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 that's what I wanted to explain to you guys these are the 99.99% cases of actual on-chain operations that you need to do with the channel so that's the respond function that's it so everybody you see couple of questions I think we have like two or three minutes so yeah any questions does do they have an incentive to respond if they've lost but they want to keep their reputation as having uptime or something with the player they I mean if they don't respond then basically then as an on-chain artifact setting like at some point they were expecting to respond and they didn't so if you keep track of your reputation then you probably uh... so they wouldn't necessarily just give a prompt for an on-chain it's kind of hard though because it's a non-attributive called fault you know like you don't know if it's a challenge or a change whether I didn't respond to you or whether I responded to you and you've got it not a challenge or a change 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 then if you respond saying you've lost then there's always at least some incentive to respond in other words you optimize like the outcome distribution based on scenarios this is like the most basic basic if that's a challenge are you settling on a change or are those funds locked and a state channel for everyone to respond so um I guess what happens so if you launch this challenge and the customer response then that channel comes finalized on chain and at that point it's unidentified or if you computed it all it means is that you have your channel ID and your outcome in the indicator so at that point you just transfer out your funds just like you did in the example where we computed it um that would just be on chain so like in the happy case if basically we've got to exactly the same situation you did in the happy case where we have channel ID outcome on chain then we can release the funds um you know if a player doesn't respond can you automatically release the funds from the state channel to the region? yes so if a player doesn't respond you wait for the time out if a player doesn't respond you wait for this time out after that time out is finished you'll get in exactly the same situation in which the channel is finalized on chain you've got channel and outcome registered in the indicator and then you can you start to transfer the funds out um I think we're only going to 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 it doesn't work so one more how does the contract know that time is up? like does the house need to send another contact and say like hey you missed the channel period no it's like um like it's basically um when you actually want to interact with this like it's not literally the chain does not absolutely literally say okay the time is done like the checkmark alludes to it's more so the next time you interact with it there's a check with the checks there's a time up there effectively that's kind of what happens you don't really need necessarily to have a check like the bullying flags time is up because you can see like the challenge and the block members will be greater than that so you don't really need to register that checkmark with the checkmark so put it 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 the checks it says yeah the time was up so it kind of lazy evaluates it so as the house I would submit to end the state general to get my money back right 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 cool um let's just chill chill our talk tomorrow we have a talk tomorrow um 11-ish I think on the A2 stage where we're going to talk about this general project in the more of our growth mapping kind of way like hey great I understand it for this thing what about the funding for all the other stuff we're going to talk about that and um hopefully now you know like you know the beginnings of standardization across channels all of which we have some great working codes a lot of which are things I might talk about today and uh yeah I think it's a future looks bright for state channel so yeah thanks for uh future listening I might be asking why I can't see that's alright so we talked a little about the project dollars and the people behind it and uh the uh the user experience and the things that users have to do to interact with the change and all that a lot of cool stuff like that um alright um hi everyone I'm Arjun from CIMOC and I'm making channels usable for humans and uh and then we realized that's a really really big topic so we narrowed that down into in the browser and then we realized that's still a really big topic so now I'm talking about like one very specific user experience and we vaguely elude to the rest of them at least some time at the end and you guys can sort of choose your own adventure for the last five minutes um so the yeah the structure of this talk is going to be about three slides of me showing connects uh 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 after that we're just we're going to jump right into the channel provider standard that we're trying to process them and then also have that be useful across other channels cool what is connects so we started out as a user experience company um we spent a bunch of time trying to figure out like what the key barriers were to getting people to use Ethereum uh 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 realized okay wait before people even bring their value on chain and then we started out in a static and consistent environment which is absolutely terrible for any kind of development on the web um and uh and so uh since then uh we kind of shifted to doing uh channel stuff um it's about a year ago we went live uh the first image channel implementation which was this we turned out to be a lot harder than we expected uh just because uh when you put this stuff in front of people you realize oh there's a lot of really like base assumptions around like how um usable these things are in like a live environment um and uh that we really needed to validate and sometimes really change um so after after doing that we uh we channel uh protocol contracts all the way up to uh the wallet there so we actually built a production ready wallet uh the die-hard browser partner style slash spank base style wallet uh and like influenced by those and uh and then put that on for a bunch of people who actually used it like it was really helpful for us to understand oh wait so many of these things are completely wrong um and uh and that directly led to us working with other more like other really interesting projects in the space like uh you know detox wallet was sent out and then that was cool um and so uh it's kind of cool because we got to sort of precursor to it uh which will have like a very gradual like very uh smooth transition because the contracts are the same um and then we sort of aggregate all of these lessons that we've learned for us doing things really really company for a while uh and then we 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 okay how can we uh pretend like the user is like we sort of had this assumption in V1 where we were like okay well the user can back up their state but we're always just giving them the upstate 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 like based on right which are really important for us all cool and then where we're like trying to integrate in the next few months and then hopefully do more from there so we're trying to like build this open ecosystem that people can come into and then eventually decentralize a little bit more like what I think looks like cool sorry sorry for being shallow back to a state channel roulette okay so how can we make state channel roulette safe and easy in the browser people talk about like you know how do you back up user state in the browser 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 okay 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 okay 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 anything 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 never ran into this problem until about 2 weeks ago a whole heroin thing happened and then out of nowhere users started saying like hey 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 and we realized user transactions were taking 6 hours to find and so like our contract implemented time out because we don't say that they're going to deposit and just like leave it forever this is sort of a safety mechanism mostly for the user which is we were like okay well if a user forgets to deposit or something goes wrong like messages 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 in a stochastic environment so we sort of in B2 said 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 take it with them everywhere they think of 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 is that you'd have to actually recover your keys and that was awful because you're trusting your keys obviously that's terrible in the browser and as a solution to that we came up with this key provider standard that metamask implemented a bunch of other wallets implemented where you have your key hosted in this remote much more safe environment like usually I say environment like an extension or your phone the key can be put into a key store or it can be kept you really only have like a very very like narrow pipe of functions that can pass in and out and then you you can sort of make hooked calls from your browser environment to that remote that remote key and so we sort of looked at this and said okay 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 what we sort of ended up doing was treating the the core channel code that's implemented by by like state channels or projects as a as like an isolated piece that is within the wallets but it's sort of 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 as you want it to be in a trusted environment because you don't want somebody to write ROM validators or like a browser to implement the validators creatively and give you a weird state okay let's just treat that along with the 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 of our client that anybody wants to build right now or in the future this is 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 like in the future we can amend that as needed but I sort of suspect that it's 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 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 like apply it to whatever context however you want there's a few different ways to do this you can set it into that in browser context using like Chrome messaging like metamask or portis 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 like you can have like a hardware device and like do this using some other messaging system like you can sort of imagine like the context around this is really interesting like paying for parking you can just like tap your phone and then confirm on your phone and like you're not actually injecting your channel recovering your key on the barrier on that thing which would be awful and then on the DAP it's even easier this is the part that we kind of 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 like a lot of wallets are using this channel provider standard as a DAP it's basically just like the existing use provider standard you just say if this dot context dot channel provider get the channel provider from the context pass it into whatever client implementation one 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 like normal and so it'll just get passed up to the remote quality what is the consequence of this so actually one more side of just how it works is the review is pretty good wallet when you hit the spin and you feel like what that's doing is calling updating the state like basically proposing a state it's like the best analogy that it gives 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 install but you confirm on your phone and then that sort of state is updated and then that's reflected back in the application cool why do it this way so this is we learned from experience would be one that like 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 integrative 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 deposit into 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 in just there and now you're asking to on-work people as a separate step to connect and that just doesn't make sense for people too it is as easy as possible to integrate the channels like there's no we haven't yet found a way to make it as simple to just make calls to a remote channel than this and if you do find a way like let us know we'd love to make even simpler and then lastly this makes the safety of your channel exactly the same as the safety of your existing Ethereum wallets are a product type space unlike most of the other work that is being done in the space like material user traction and they are being used in production and so they've had production problems and they've had things like key linkages like user funds being lost like dependency issues that cause people to get hacked like those are the sorts of things that you need to worry about to bring channels to production and like this does make channels and operating in a channelized environment the same as what exists with Ethereum wallets cool that's sort of 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 prod is like it we actually have to like migrate everybody and that takes time into corporation 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 couple of contexts at least the other sort of user experience things that we've kind of seen were useful from this from this observation or things like treating your channels as like wallet in the state channels this is literally true that your channels will say wallet and that's really awesome because now you can leverage all of the other you know user experience paradigms that people have been building like for instance getting rid of doing gas extraction completely right like they're able to deposit into their wallet paying gas make a bunch of off-chain transfers and then withdraw in a way where the like counterparty or the hub offer for somebody else is the one that's actually paying gas cost transfers to off-line recipients availability is a really big issue on the web not just because people go off-line and because the internet also is a decentralized system that is forecasting but also because like people aren't always gonna be around to receive your payments that's something that we really really work on plugging and saving users that assist things like PISA for watchtowers but then this also means even just having the user be able to use their like their channel or their application in a bunch of different devices at the same time or maybe not at the same time but at least like in sequence and then only deploying like on-chain again only making on-chain transactions when you absolutely have to so moving your channel employment with Skrull 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 yeah thank you for a great talk first and just a quite strange question maybe try to find out what you might assist you with transactions possibly but no that is an interesting idea do we actually haven't even thought of it we just said okay let's so like it's a decentralized system and it gets more decentralized over time it's like really decentralized we don't want it to necessarily be the case that mining pools like 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 like which connects related organizations actually get their transaction processed ideally we just solve the problem at its root there will still be this issue of depositing and withdrawing but if we can move it to a point where it can happen asynchronously then it doesn't matter if it takes six hours right like it can it's something where like you can start a deposit for $100 at the start of your day and then like leave and then use your channel later on in the day and not even know that it doesn't go certain yeah that's a good question it's sort of up to the someone like Mademaska they want to implement that it's like because the so this is sort of a nuance that I didn't really cover but like the part of the way that state channels is implemented right now is like there's a there's you need a mnemonic because there's each application actually has a unique key and so you use a mnemonic to carve out a unique key path for for this specific framework that is different from all the keys that you would normally get on on a certain 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 would be centralized it should also make things more private because that's the case what we've actually found for most nuances that they've said that differently in terms of signatures we'll just build a completely different user experience for signatures over there that's I think that that probably makes sense and it's gonna be we like we don't want to be too accommodated 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 uninstalling in half and then like maybe sign on certain cases and maybe we can like expose a flag for like what seems safe to sign because the states will be in the same way a binder which how do I even read it so I'm gonna say hey the sign you this has to yeah yeah so there's metadata attached to it like you the 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 and we can do that within our client and pass it like that it's a lot of like hardware wallets it's a lot of like hardware wallets yeah there's a usability like security trade off there the cool thing about having application specific key is like worse comes to worst if somebody like compromises your funds the like 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 great talk by the way interesting so my question is do other projects have a similar problem and it's operating to use the chip to deal with transaction release and so they can be sure that when you draw a constant transaction that's reasonable for people do you mean for like like making the transaction happen yeah the example here is transaction release from the same time yeah yeah so that's interesting so like it's sort of up to it's sort of up to the whole implementer how they choose to do this right because they're the one or like I guess the client implementer because they're the ones that are making the transaction in that case in this specific case it was actually a transaction from for better baskets to pay and then Bruno and I talked about this and like clearly it was just that like it was sent to exactly the recommended I think it was safe low gas price and then he bumped it out like by like 5 to 10 percent and then it was fine but it just happened that the price was being effectively lost yeah yeah it was required to allow you to join a channel with now on transaction is there like a source of funds from the next or yes you always have like one okay let me take that one you always have okay 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 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 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-prisonial you can just take it with you wherever you want and then at some point in the future if you want to 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 to the ecosystem we got that now we're good thanks so much thank you thank you thank you so you talked about the channel network my name is Xin Cai and I'm the co-founder of the standard 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 production and before we get down to some of their technical details I want to take five minutes to talk about their adoption of the state channel So just a few months ago, the set-network just launched its minnet, and during the minnet, we practically released ratings. The first thing is our user-free single-blog application called SetEx, which is a real money e-sports gaming platform that's built on top of the state channel network. The second is that for the game developers, we also released the SetEx, which is a gaming SDK, so help them to submit and publish their games onto their SetEx Google app and enjoy the benefits brought by their state channel solutions. And finally, for the blockchain developers, we also released the SetEx Web SDK that can help the blockchain developers to leverage their state channel primitives, like the function payments, as they're plugging into their applications. And this is a short demo about the SetEx Mobile app, where basically the players can play the skill-based blockchain games on top of SetEx, and win crypto prizes, like Beezer, Dye, or Setter, and the entire price-payout process, and also some of the games are entirely viewing on top of state channel technology. So it is real-time interactive with no latency and zero gas-based, and also it is as secure as the online blockchain. And so far, their clear-sense has spent over $1.6 billion on this app, and there has been over 300,000 games played on top of SetEx. And currently, our monthly active users is over $12,000, and it's probably one of the most active decentralized applications on the server right now. And our users are also spread across 89 countries in the world. Okay, and also for the game developers, some of the questions that demand asks is that, can I build my own games on top of SetEx? Because SetEx, in itself, is built on top of the state channel network solutions. So do they need to understand their service 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 released the SetEx game SDK. So as a game developer, as long as you have a vanilla HTTP ML5 game, with just adding two lines of code, you can integrate your game with SetEx game SDK and enjoy the benefits of using the state channel network solutions. And it also requires zero blockchain experiences. And because we also want to bring the developers that are outside the blockchain community into their blockchain space. And on the left is how you might integrate with SetEx game SDK. And on the right is our game developer portal, which we can basically control and submit 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 in integration time we're integrating with SetEx game SDK is just less than 30 minutes. So that highlights theiveness of integrating with SetEx game SDK. And finally, we also provide a set of web SDKs. So this is an explosive menu of the use for low-level state channel primitives that could help them to develop their two applications, such as clinical payment. So on top of that, they can build many interesting applications like the prediction market. Next I will spend the rest of the talk talking about some of the technical design of our state channel network. And in particular, we just released a 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'm going to give a very high-level overview about the key design principles that we use while building and operating the state channel network. Okay. So here's the high-level architecture for set network. So basically the great area is the generic conditional payment network. So this network has lots 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 proportions which is essentially a set of smart contracts that handle the option to launch interactions such as opening a channel, depositing a small set of channel, and all these kind of operations. Okay. So within this conditional payment network, any client can send a payment to any other clients in this network. Okay. But this is not just a single 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. Okay. So for example, Alice can send Bob $10 if Bob is a winner of the chess game. So here's a payment from Alice to Bob. It's conditioned on the outcome of the chess game. Okay. So we set a network to provide a fairly generalized interface that brings the payment part and also the high-level application logic. So basically we decouple 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 this here is one common channel from assignments. And this kind of decoupling 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 decoupling and layer architecture later. Okay. So now let's first look at how set a network handle the hub by hub forward in all the conditional payments. Okay. So the first core data structure that we use here is called the conditional payment channel. So in set a network we allow the full duplex channel which basically allows the two peers to send payments to each other concurrently without interfering with each other. Okay. So in order to implement this kind of full duplex channel each peer will maintain a simple external data structure which basically maintains the current transfer amount from this peer to the other point. Okay. So here we use the protocol message to show what kind of information is to be included in the simple execution channel structure. For example, you need to include the channel ID, the peer address, the 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 in the channel. So here because we don't use worker route here because worker route is mostly used 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 worker route will incur many unnecessary additional capacity when computing the worker route and also verifying the worker route. Especially when you need to do some option verification officer pending payments. So we just use a list that maintains the list of IDs for the current pending payments. And the second important death structure that we use is called the conditional payment. So the conditional payment has the paytime 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's also a transfer function which tells or just specifies how we should resolve this payment depending on outcome of this condition. And here we provide many useful alternatives for resolving a conditional payment. For example the bullying end means that the source needs to pay the destination the full payment amount if all of the conditions included in this payment are becoming true. But we also provide other kind of preservation logic such as bullying all, bullying surrogate 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 conditions. Okay, so here's a kind of high level overview of the messaging protocol with a single hope basically how you forward the conditional payment to the next call. So the first step is that for the source to set up the payment to the destination it only involves one round trip 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 specifically saying that this condition has been finalized, we have finished the chess game and I commit that I can send you the money then the source and destination will settle the payment option and this also involves only one round trip of messages. And when necessary the source or destination can also choose to dispute or settle or resolve the payment option in case that someone tries to cheat or there's some disagreement about the payment state called application logic. And also we use the sliding window techniques in order to allow the source to send 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 hope. 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 hope level we use the, so this kind of hope-by-hope conditional payment forward is simple because it only involves very few round trip messages and it also supports a full dual-text channel. And also we achieve high throughput also through the full dual-text channel implementation on also the sliding window implementation. Okay, so currently what I'm talking about is all about the hope-by-hope forwarding so what's happening within a single hope. So what about the multi-hope? What kind of things we can build on top of this hope-by-hope 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 like that in Clark, back 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 the computer systems. Okay, so our design principles with design those end-to-end patterns is basically two-fold. First, we want to clearly couple the channel found 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 backbone 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 multi-hope payment with pooling conditions. So with this design pattern, basically the source can pay the destination a full amount if this condition becomes true. And this is a very simple design pattern that it is probably one of the most commonly used scenario in practice. For example, in our CELAC's mobile applications, we use this design primitive to implement the head-to-head game competition. And also it can cover the use case like prediction market or peer-to-peer social betting and also includes some of the casino applications that relate to our applications as mentioned earlier. And this is basically the highlight overview of our application protocols when we're trying to implement the multi-hope payment with pooling conditions. So for the sake of time, I will not go into the details about these protocols. Everything is including the protocol specification doc if you're interested to check it out. And also you can sell the payment option and the destination that also rejects the payment option. And also the source of destination can 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 any onto 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. Okay, so to summarize the kind of properties with the multi-hope payment with pooling conditions. It is simple because the relay nodes never need to care about their application logic. It's just thumbing forward in the conditional payment to the next file. And it's also low cost because the relay nodes never need to send the onto transaction. And in most of the cases it does not even have a single view only function for the event working. So that's greatly reduced its complexity. And it's also secure because it is resilient to any arbitrary relationship and applicator and it's also low in the messaging overhead. And the second end-to-end design permit is that it will provide new maneuverable conditions which basically means that the source can pay the destination an 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 based car insurance and their cloud hosting service and so forth. And these are the products which are still here. So far to summarize the kind of end-to-end design permit that we got mainly there are multi-hop payment with pooling contribution and multi-hop payment with numerical condition their design principle for them is that we highly optimize for the majority of use cases so that for the majority of use cases it's highly efficient and also secure and robust. And with these 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 there will also be some 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 it gives us a lot of flexibility but besides the two kinds of permitives that we'll build we also allow for example you can also build your own for example founding protocols like the natural protocol that today I'm going to talk about tomorrow but as an end-to-end like the founding protocol permitives and also on the application layer you can also build a forced-move gate-based station on applications so we provide this kind of flexibility to flagging your own application logic or your end-to-end channel founding logic so this kind of stacked and layered architecture designs just like today's internet architecture where online you have 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 a different application layer that handles like HTTP FTP and SNTP and all the layers share a common and unified interface between different views okay so just to summarize and give us some of the key takeaways here is that when we design our station networks we have several key design principles in mind the first design principle is of course the design should be also transparent 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 really note the complexity while pushing the complexity to the HTML and unfortunately we also want to minimize the on-chain non-transact interactions for example such as view-only functions or the event-watching this might be in contrast to many people's thoughts that the on-chain view-only functions or the event-watching is free because it is instant but the reality is that if you run the station network or different type of decentralized applications in production you will need to also pay for this view-only function of view-only working using some of the blockchain infrastructure services in your academy and that comes with a price and also calling a view-only function or doing an event-watching also occurs much in larger latency than you doing that with the local storage server or in 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 of these for example the key thing is that we try to decouple the channel-on-assignment process and there is a high-level statement 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 the blockchain that infrastructure was put about such as both on-chain, on-chain and different public broadchains can share the common data schema and then we even build out our own like protocol compiler for the Solidity and it's all in our GitHub repo if you are interested, feel free to check it out and we also support the zero-on-time contract and the protocol grade is something I don't mention but it's included in the bug and finally the kind of layered and covered 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 view so everything is included in our protocol specification doc so feel free 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 want to present some observations we made while we were looking into the project okay, so so when we talked about the reletics 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 but what we want is we want to also build an off-chain in a multi-party channel and connect more than two parties and this is something we spent on searching and to already give you the result it's possible but sometimes it's surprisingly expensive so when I want to do this talk 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 in most of these constructions you can just set it up as a multi-party so it's actually not like this but we also talked about networks with all these networks can be connected always to people so can we take this existing network and also the multi-party channels on top of it and the answer is yes so in order to connect others of the channel here we have to restructure this a little bit or organize this 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 we 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 have to get rid of them and the next step is we add a channel contract a multi-party channel contract for our state channels just as we would like to build another virtual channel and inside of this channel contract we can now put any kind of multi-party application that we want to run for example all of that but there is actually a downside when we talk about channels and networks we already have for example the network to look at and the multi-party channels could even work so for example Bob in this case collects 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 coins to Alice Alice has to submit one coin to the channel contract and Bob has to submit his own coin then Alice might win and the one of Charlie so two coins into this channel contract and the same actually on the other side as well so well he is technically only playing for one coin 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 if you relate for a long time to actually build a new multi-party channel directly on the ledger because then there will be a problem nevertheless it is possible to use existing networks and use multi-party channels on top of it and for a 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 in 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 and confirms 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 true party so it's not so bad that we fail a lot of parties it 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 really enforce function so another way of progressing states which makes some sense is a large multi-party channel it's a really parallel so everyone in parallel submits their inputs to everyone else so this is a lot of communication and 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 how do you state and then everyone sends and then in two steps we have all the confirmations and all of the inputs in parallel and this is too interesting concept I don't want to say which one makes more sense but it's interesting to have both in mind when we design a game because some games are really made for each of these state compression models because when you have a sequential game like Cobra it really one step depends on the next one so it really makes sense to go with a sequential way if you have for example if you want to generate randomness everyone has to send their input together so it might make sense to use a parallel approach if you can mix them have steps related to parallel and then have other steps that you use to branch and 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 well you stop but in an end party setting which you want to continue running the game even if one party is let's say you are playing Cobra and one of them doesn't have any funds anymore so you cannot continue playing but the others might want to finish their book game but on the other hand they don't want to have this empty so the party got kind of lost already to confirm every step because why would it so you want to maybe exclude the party in a channel and this is another new concept so far it was not very interesting and there is actually two cases that we entered into a 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 confirmed that I am out so this you can do off-chain you don't have to go on-chain but then there is also another case where some party simply awards whatever I don't carry anymore go on-chain to change the underlying concept rules but still this has to be designed on a regular 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 and it's kind of a contract of these kind of games it's also very dangerous so think about this a lot when you design a game it's a very famous problem Fairness is in general something that just really hard to achieve with multi-party scenarios and this is always tricky when people start to pollute so in this case let's see that Charlie and Bob pollute against Alice in the roulette example as we've heard before from Tom how you generate randomness so how you basically determine the winner in roulette is with this primitive ideal steps so first everyone commits to the randomness and then they run a function which says who's actually the winner so 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 so I should rather avoid and of course for Charlie this will be back because he gets slashed and his money gets burned but for Bob this is actually a good thing because he keeps his coin and he can keep the game he still has 50-50 chance that he might win his own and Alice's coin so in the end 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 Alice is with very expensive punishments so Bob or Charlie must induce that much money that it cannot be worthwhile and but this really grows exponentially with the amount of parties because now also Bob 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 revenue to agree on maybe some block hash in the future that also adds a little bit of revenue so Charlie won't be able to see exactly who's 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's and country's okay and now I hand over to Sebastian who's going to present some details about this Hi, I'm Sebastian Stamberg I'm working on the implementation of this stuff for a few months now and thank you for being here 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 is not like general this is just any thought we had the things that we decided on so definitely what should always be included is the protocol engine everything that defines the protocol and the basics this also includes the distribution of logic and logic very important is the systems because you run an off-chain protocol and off-chain application you always have an assist for example a state update the signatures that you receive the signatures that you send keep track of the nonsense keep track of other data maybe you have some protocols that you execute so all of this has to be consistent how you persist you also want to have an off-chain wallet so you might design a system to have the family keys we talked about the slide keys sometimes you want a key for each channel so then you would have an off-chain wallet that generates those keys but you don't have off-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 Wi-Fi so you design a protocol so this is nothing that really communicates to the blockchain 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 participants you want to agree on the parameters so you have to exchange my solutions this is also something of a Wi-Fi protocol and things that might not be included for example an off-chain wallet so you probably want to send requests callbacks back to the user or for off-chain funding or for the channels so you also probably don't want to keep track of off-chain keys so that's also the reason why sometimes you might want to implement as for example a metamask extension so you can so you can metamask to do this off-chain stuff that you do with all the off-chain and you also don't necessarily need to implement a network communication layer so it could be that you only define the messages because you define the Wi-Fi protocol but maybe you develop a library that hooks into another application already has some kind of network layer so you can just duplex the communication here you just send callbacks send this message you set up a subscription then you get messages that are followed so you don't need to provide this and then of course the framework itself you don't necessarily want the apps so the apps is like another concept so the apps are on top of the framework so one thing we can do is state 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 state 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 to the state channels so what we do is plug in the state channel SDK for example 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 find the channel and we said something that should be very easy to create and we also think that it's very important that we can make the developer inject or provide some mechanisms like logging and the networking stack and the persistence stack so we can find the persistence on abstract level and then let the developer inject say an SQL database and use this for the systems 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 state channel networks but on top of this it also has an interface which can communicate to the application so then for example GFPC or json-gram 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 an update 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 you probably want to at least have an automated dispute handling so you want the application to watch the chain and handle disputes automatically for your user not necessarily for your user but it's a very, it's a very complex thing to touch and then you also for example you can design it in such a way that you have on-chain callbacks to the application for certain on-chain actions like funding to 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 why the Lightning Network is pretty awesome because we talk about a bunch of others so you want to have like some central server, hub server and it should help other people to build virtual channels that's what we call virtual channels to enable applications to have this network so the idea is probably that you have some depth and the developer of the staff wants to enable users to use this and the very efficient way to do this is you give it state channels and then you run the hub server and then you let all people connect to your hub server and then you can have them open two-party or multi-party virtual channels over your hub and yes Do you think the hub server should extend the client node or should it be a separate container? 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 of the hub server should have a more shared code but I think at least that's what I'm thinking about it is that 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's at least what I think that makes sense so just a very brief notice on the language so we chose Go but a lot of people are using JavaScript 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 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 you can have it as a library that is the SDK we were talking about and it can be a standalone application so for the browser case it makes a lot of sense it makes you think it makes sense the graph free tooling is actually much better for JavaScript but for example we also have some IoT use cases and for those IoT cases it makes a lot of sense it goes less known so the reach is a bit slow but yes it's a type in the language so 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 a portable engine then you have on the left blockchain backhand and then you have some generic south database networking and then on top of the blockchain backhand we have channel applications so we design the whole system using which means the portable engine has no direct dependency on anything specific like no goreferium dependencies no dependencies not for us for logging no dependencies I don't know like TCP or something so it's really all going down to the interfaces so that means we find interfaces which say that's the way we want to use this stuff to exist and then we use it all in the whole protocol core and then we implement models interfaces as a blockchain backhand database in 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 right it's an absolute concept I think you also talked about it like seller they're doing blockchain messaging protocols here and this is like you can take this even further and say okay actually the whole engine of this protocol the stage and the protocols is very abstract for example we also look in the parent papers they're written in a very abstract way so for example that it only has right 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 and yes yes that's actually a very good question when you're designing this in an abstract way suddenly many many things become quite complicated or complex so you 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's equal to another address so you give this interface an equals method and you want to sign with your okay so actually you also have a concept of an account so you have an address and you have an account from this account you have an address and you can sign with it and 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 yes so this is like one of those concepts but you yeah so it makes things more complex but it's also nice because it forces you to really define variable interfaces and really forces you to understand how to design those protocols where exactly this layer where what separates the protocol from implementation specifics it's quite interesting and this is also like that's the same here on the top that's like this blockchain interface and I was talking about 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 and you want to go too much into detail you just need 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 this stuff we are going to release this SDK for ledger state channels soon and then we want to go to virtual channels the 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 to observe and then we also want to do additional backends because 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 an abstract concept you can really just provide a plasma back end suddenly and you can just reuse all the core engine and just have a plasma back end thank you today is from us we will have a look at challenges that we came in China Networks and especially just cause design from the system architecture from the view as well as from the experience from the view and basically share just some of our experiences that we encountered along the way of developing this 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 happened to 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 break up what is Rayden in case you guys don't know Rayden is a payment channel network that works with any year C20 token compared to the other talks before we've been somehow shifting between like generalised state channels and payment channels Rayden is solely payment channels and can be compared to for example the lightning network on Bitcoin it has a really, really similar idea the very core idea of this is that you have a payment channel and this one is always made by an on-chain deposit and once you have deposited tokens 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 digits into checks you send something back and forth and eventually you say, yeah I want to choose my tab and then you withdraw your funds from this channel the cool thing about Rayden exactly as a value is that you can not 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 a little bit so our status is that we are live on Manit 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 right now and there you just see our current payment that is pretty pretty small still that 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 they call it a 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 Rayden right now and we have the target group which is actually projects and developers that want to integrate with Rayden into their application while the user themselves the end user will not really know that he's actually using Rayden by using this application so first bucket is the actual end users and those are experiencing or might experience some challenges when they want to interact with the payment channel network for example, first and foremost it's really about application or also abstracting where technicalities the problem is I don't understand the logic of the 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 you see over time then the second problem, user interfaces are cumbersome to use and people are really unfamiliar with the terminology we use that's definitely also a problem on our side 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 making it to fix whatever 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 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 data, it's 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 who 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 or dispute 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 your camera actually goes through faster then a really huge problem I don't want to run a node 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 line to client it still work in progress but you can already test it on the testnet now and here in the back you see how the light client is performing in transfer to a rating full node or rating node the light 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 a 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 light client SDK the second option you can try this out if you like the master is always live as lightclient.rate.network if you want to try it out it would be great to talk to us after because right now there is only one token network for testing 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 light client master so just talk to a nice green man for the light client option number 2 is we can also help people to make running nodes easier and since this is a decentralized system we also rely on somebody for running nodes so make it as easy as possible the next option would be to go with depth node range is available on depth node both to the testnet and mainnet packages so if you are already running other nodes via depth node it's basically just one click and you can add your range nodes the other option is help with onboarding tools in the past it was really difficult to install range if you are not technical you will not be able to do it because we have developed something called the range wizard which basically installs and launches range for you all you need to do is download it and double click it and you have to have an infura project that you follow this one because we assume that people who don't want to run a node and who don't know how to install it might probably not run their own node but I assume in the future it will also be possible to add to your only serial node 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 or so and that one you can install without any help needed from our side so you can just go to our githubranger.network slash range installer or scan this QR code and it's available for Mac OS and for Linux for the testnet, for now but for the next release we hope to also have it for the main languages yeah and then the challenges from the other side so projects that want to integrate with range they are also facing some problems the first one is again kind of an education abstraction problem definitely people or projects developers that integrate with range 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 node also thanks 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 then also the third problem I need certain features that I don't find in the range right now so maybe it's not suitable for me some of the problems we can solve 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 access so we are basically powerful very extensive and very easy to access we have a developer portal and we are also always available via our technical help chat on github so in case you should have any problems just give us a short yeah basically don't want my users to run a node that's how the back end of the redline client SDK would look like from the front end yeah just integrate with the redline client SDK as soon as it's ready you can already try it on your system I need some features that's not a problem at all because now that we have basically leveled all of the core components and features that are like the basics for payment channel network we are super open to incorporating whatever feature you might need and we have already started with that so some of the projects where we are testing the channel withdrawal 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 interact 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 draw feature and it takes less on-chain transactions then actually closing the whole channel opening the channel again easier one other example is the guys from exchange union that just launched their swap between bitcoin or lightning and die already and they've been also really closely in touch with our developers so I guess if you want to have some feature implemented just send us now and we can talk it out and then looking over to our business part UX is obviously not only about the front end stuff and features but it's really influenced by the other like system architecture and yeah we will talk about that later thank you frenzy thank you guys for coming so I'm just going to go over with you guys what are some of the consequences from the use of int perspective of the things that we have chosen 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 by then so the idea that we have here is that for blockchain systems you can only fix two of these three possibilities and we want to fix that so that's why we are building state channels where you can actually have a scalable solution that's also secure and it's also decentralized so let's sort of go of every single presentation that we have had today and from my interpretation I think the biggest problem that we have here it boils down to communication because if you have a proof of work of a proof of state system you actually have to share the data with a lot of nodes and then that's actually what removes credibility from the system then we'll have overhead that we have in communication so what are our design goals and how are we going to actually fix this problem so we really want to have a very high degree of decentralization we really want our system to be completely decentralized no hubs hubs may appear in the network if there's 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 a very secure and 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 that the thing is good 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 favor that you have no control whatsoever it's just like the nature of the decentralizes it could also be that you're just bad and one of the guys that are trying to communicate with just went offline and that's just the truth and from a user perspective that's very very hard to explain why my transfer is set in 5 minutes to fail because it takes 6 hours for transactions to remind on chain we have to take that in consideration 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 start the transfer in the left side it may very fast actually completely transfer it if everything is successful the capacity is fine every node is online so the thing is going to be fast if something goes wrong 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 season because we cannot actually fix that it's inherent to how it 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 come up so let me go back so I'm trying to lock the funds and right now lock funds with the channel if charge is offline lock 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 what I'm saying is if you separate out the process of you review everybody's balances then you make the transfer in two 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 timeout okay path finding is complete you can do path finding at any moment the thing is you do not know if the path is actually successful right that's what I mean it's like you just lock the value in the channel as part of the path finding itself yes and then those transfer until later yeah and that lock is what either can happen if you're trying to lock the funds and one of the nodes is not aligning the lock that 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 right 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 the problem is that channel 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 we have to go the money has to be sent from the fading 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 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 systems make sure that the network section is going to be balanced because if the network is unbalanced and payments simply are not going to go through the failure ratio is going to increase so we have to have some strategies to help the network balance itself and the way that we do that is that we just introduce rebalance rebalance and fees so we use the 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 rebalancing 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 the mediator when you're actually doing that sort of strategy and that can be cumbersome to explain it right so what we do here to try to fix this problem is that instead of trying to play to people and have them actually think you understand 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 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 because we actually choose a path that has capacity to make 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 is that we sort of allow them 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 use that data to find paths that can actually work so yeah and that's also a very important thing we never force our users to do something we always have an escape hatch or a 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 not send about its updates at the cost of not using users and mediators so it can increase privacy but it is not necessarily going to be used to make payments go through that way yeah so for the next three years we are looking at different ways of trying to fix these problems we introduce refund transfers we are going to work on the cancer of the transfers and we are trying to figure out how we can actually make the try to find a service that is more privacy preserved but these are features that actually we have that even though there are trade-offs we think they are important because they are going to help make 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 are pretty much cutting everything in a few weeks and we are 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 all and we are happy to answer them