 All right. Good morning, everyone. It's great to be here. It's my first dev con. Super excited. And today I'm going to talk about basically build and operate the internet-scale dApps on setter network. But before I go to the technical content, I just want to say that we have a testnet app. And the testnet is not a black window that with awesome numbers, but an actual app you can download and try today. And you can play some board games in it. But we only have it in Android available right now. So we're just going to show basically a quick demo here. What this is about is this is like a game running on generalized state channel. It's a board game. It's basically connecting five. And you can create a game. And you can bet with your friend for 0.1 testnet ease. And now you can off you go. You can start to play. And the important thing here is that we want to show that state channel is actually going to help in terms of user experience, because you can see that each of the state transition in this kind of game is already implemented as generalized state channel, off-chain smart contract as what we call it. So this is kind of the user experience you can experience. And we also have the dispute protocol and the full seal is fully implemented. Now with this, we launched this testnet app, including this application on Ethereum San Francisco. And after about three weeks, we have 900 installs, 15,000 payment send. And amazingly, 17,000 games played over this 900 people. And the interesting thing I want to highlight is that this is all on testnet. If we put all these transactions back to back into this entire blockchain, it will take 57 days to finish all these transactions. But amazingly, we have a 15% user retention ratio for a seven-day user retention ratio. Even if people know this is fake money, they still stick on it. So this is kind of an amazing thing that we think generalized state channel can bring to the table. That is real mass user adoption that is pending. And we have the SDK already released today. And multiple teams are already building on top of the SDK with off-chain prediction market, some more board games, and some SLA micropayment, or basically microservices solutions. So you are very welcome to look up our GitHub and there are tutorials about that. So jumping to Celer Network. What is Celer Network is a coherent off-chain scaling architecture? What do we mean by that is Celer Network has two parts. One is the technology part called C-Stack. We propose a layered technology architecture. And the other part is C-economics, which we propose some crypto economic construct to solve some challenges in the state channel networks. And for C-Stack, we basically solved the question of how to support generalized off-chain scaling. How to route radio transfer efficiently in this kind of off-chain scaling networks. And how to bring mass adoption to off-chain D-apps by providing a better user interface and developer applications. So C-Channel is the lowest layer. What is C-Channel is basically our generalized state channel construct. We came to this generalized channel construct from the concept of a conditional payment and a conditional dependency. So let me just give a quick overview here. This is like a channel spec you can write. So when you're writing a generalized state channel application, what you're writing is first part is a smart contract. So to write a generalized state channel smart contract, instead, you basically need to implement these kind of functions and also have these kind of states in it. So I'm going to not talk too much in detail about that, but we have a separate talk I will refer to later. But the key part here is that this kind of construct enable generalized conditional state transitions. That is like you can make a transition in your state channel and conditionally depends on some other transitions in some other state channel. And ultimately, you can build this rather complex conditional dependency duct to implement the complex generalized state channel application logics. And to just make it a little more concrete here, to talk about what we did in the game, for example, so let's say Alice and Mo have a channel. Mo and Bob have a channel. And Alice wants to play a game with Bob and while betting on 0.1 ETH, or betting on $5 here. So what's going to happen is that Alice is going to send Bob a conditional payment of $5 related via Mo. And in the beginning, the conditional payment will be like a Boolean and the condition group. There is a Boolean and the condition group on top of it. What it means is that only if condition C1 and C2 both evaluate the true, then this condition and payment actually goes through. So there are two conditions in it. One is the standard multi-help intermediate transfer HTL registry condition. So basically, we generalize that HTL part also as a condition. And also the Alice and the Bob game. After this kind of a pass got set up, you will see only one repeal of the first condition and only one condition left, which is like the Alice and Bob's game condition. And when the game finally finishes, the Alice and Bob's condition or state is entirely a pure off-chain object that you translate entirely off-chain. And when this entire game finishes, this game gets resolved to an unconditional payment. So this is kind of like a process of how you can think about the generalized state channel in the conditional payment sense. So in C-channel, we have a bunch of out-of-box features including off-chain address translator to achieve this kind of a pure off-chain object, meaning that this kind of off-chain smart contract doesn't need to exist on-chain unless there's some dispute happening. We have cooperative settling. We have a single channel setup, which you can set up the entire channel with just one transaction. We have some direct final state claim functionality, dynamic deposit, and withdrawal. And for the conditions, we implement some out-of-box condition groups called boolean circuit condition and find a fund assignment condition groups. And they are all documented in our docs. Now, this is like a quick overview of the generalized state channel construct we have. And the second layer of seller's technology architecture is called CROT. So the reason that we need a routing architecture is because we really want this kind of a mechanism or a semantic to connect to this off-chain state channel network once and use it forever, right? So now, why is this off-chain payment routing is so challenging, right? A rhythm guy, a folks talks about, like, basically, why we need optimal routing, but why it is challenging. The reason is that the state channel network is very different from a data network. So for data network, the entire network is stateless. If you say it's 100 megabit per second link, it's going to stay 100 megabit per second, no matter how much data will deliver through it. But for a payment network, the capacity actually changes as you deliver a payment through each direction. And using simple algorithms like Shoddy's path routing can break down the channel very quickly. And when the channel, when this entire network topology is constantly changing, there is no way a decentralized routing algorithm can actually work. So what we proposed is called CROT. And the principle of CROT is to basically use the follow the congestion gradient or basically try to figure out, OK, this channel is too imbalanced. And OK, then maybe we shouldn't go through that path. And we should maybe not go following the Shoddy's path, but follow a longer path to basically try to maintain this overall balance of the network. And the second kind of a principle is that it will keep the channel balanced. And the key part here is that CROT is still a decentralized algorithm. Basically, you talk to your neighbor about the pressure you're delivering to each of the peers. And the pressure information get propagated through the network. And we can basically construct a routing algorithm on top of this. Now the interesting thing about CROT is that it is the first ever provably optimal routing algorithm, meaning that we can prove, in theory, that given any kind of arrival process of your payment, there is no other algorithm that can exceed the performance of CROT in theory. But there are a lot of implementation challenges and the things we need to do to carry this forward in production. And there are several layers in the CROT as well, but that's the most important part. In the simulation, we have observed CROT can achieve more than 20 times the higher performance compared to naive routing algorithms like Shoddy's path routing. OK, so COS. What is COS is a developer framework for CIAPS. It is basically the protocol layer Liam also talked about. And it is handling all the complexity for the developers to hide away conditional payment setup, state channel setup, and resolution protocols among them. And it is also bridging the on-chain and off-chain bytecode, meaning that today, how do you write an off-chain smart contract or a state channel application is that you write a smart contract first, and which support all these interfaces of off-chain applications? And then you write a native app, which also contains similar logics. Now, what we are aiming to achieve is that we hope to write one set of code, right? So you can just write one set of a VM code, like EVM code, and let the EVM also running on mobile devices and web applications to act as a real backend for these applications and mobile devices. So there is no need to write two set of applications and create a box at the same time. So it is also easy to use a runtime, which is a C-wallet I just talked about. So this is like we talked about how to support generalized conditional payment and high performance routing and also the operating system side of the network. Now, we'll move on to the C-economy, which is a crypto-economic construct off-center. And off-chain scaling or state channel achieves a huge amount of scalability, but it comes with trade-offs. What are these trade-offs? The first thing is a state availability challenge, which is how to make off-chain state always available for unchain dispute. So this is like basically a challenge. So Alice and Bob are transaction each other money, and their newest state is sequenced with sequence 49. And Bob goes offline. And what's going to happen is that Alice can go to the chain and be malicious and settle a older state, which is more favorable to Alice. Centralized monitoring is definitely a bad solution, right? But what about transfer monitoring? Well, transfer monitoring you can do, right? Basically, by letting Bob submit the current state to a trust-free monitoring services, and the trust-free monitoring services is trust-free because the trust-free monitoring services will also deposit an honesty bond to the smart contracts. And when Alice submitted this malicious intent to the trust-free monitoring services, we will submit the most current state. But if the trust-free monitoring services is malicious, the user can go online afterwards and basically claim the honesty bond. But the problem about this is that it doubles overall liquidity lockup for this entire state-channel network because now we not only need to everyone to lock up money on the state-channel, but also need these monitoring services to lock up money on the channel as well. It creates a heterogeneous interface for state-guarding because maybe sometimes you are guarding this kind of token, other kind of tokens, or some other kind of intermediate state that is hard to reason about what is the actual value underlying that stake. And it is very obscure and expensive pricing model because it involves locking up your liquidity and also we need to kind of do peer-wise negotiating with the monitoring services about the price. And it incurs some complex on-chain-off-chain interaction and gave you finally a rigid insurance model. You're basically insured with X percent for Y price. So how do we solve this? We solve this by introducing something called Seder's state-guarding network. A state-guarding network is a special kind of side-chain. You become a guardian by staking your Seder token into the side-chain. Now, when a user is going offline or a device is checking in his state, what it will do is that it will submit a statement and the state proof can be anything. It can be a game state, it can be a signed agreement, it can be auction acknowledgement, all that stuff. And the first question to figure out is who is guarding the state then? So now, a randomly selected set of state-guarding will be guarding the state. And the amount of state-guarding or the amount of Seder token at stake for this state is basically determined by the income flow generated by this particular user comparing to the income flow generated by this entire network. So in this case, this user is paying $1 per hour and the entire network is receiving $2 per hour and this user basically has half of the state-guarding covering for him. And of course, if you have like a more token stake in this network, you get more work to do and therefore get overall more income as a state-guardian to perform the job to help user guard the state. Now, how this works in practice then? So, that has become malicious against me, the older state. Now, each of the state-guardian randomly assigned will have a designated dispute slot and there is an anti-collusion build in this process meaning that if the first state-guardian is malicious and the second guardian can jump in and submit the state and the incentive for the second guardian is not only just take the fee from the user but also taking the state-guardian who didn't do his job properly, all his Seder tokens away basically. And in the worst case, all the state-guardians can be malicious and they can basically not dispute for a user's state and what will happen finally is that all this, so when user comes online later on, user can submit a proof of malicious behavior and all their Seder token will be compensated for the user. Now, what is this? This is actually a very, very efficient pricing mechanism combined with a new kind of insurance model. Right, so, you know, because user, when user is trying to submit a state, user is also trying to submit what is the payment associated with state. So, user can increase the level of payment to have more state-guardians guarding for the users or user can try to choose to use a small amount of payment to have a smaller amount of guardian guarding for the state. Now, the reason that this is a new kind of insurance model is because what is Seder token here is basically representing the income flow if you do the work in the state guardian network. And therefore, user is not insuring against X percent but insuring with a speed to recover potential loss if there's a kind of a state, this kind of a worst case happening even with anti-collusion. So, this is how we solve this state availability challenge using a size chain construct effectively. Now, the second challenge is called state connectivity challenge. What is connectivity challenge is this? Basically, you have Alice and Bob playing a board game on state channel and Alice is sending the winning proof to Bob, right? So, basically, Alice made the winning move and send the proof to the Bob but Bob is refusing to sign it and reach quit. Now, what do we do? Should Alice just submit this state to the mean chain and try to punish Bob at the same time? Well, no, because blockchain cannot differentiate between these three scenarios. The first case is Bob reach quitting, the second case is Alice is actually maliciously trying to submit the state to the Ethereum mean chain or there's no one's fault. It's just in the middle there's some network problem between them. So, we need a full back data exchange fabric that is reasonably available and can actually have attribution of state availability time and it's also cost effective and doesn't require large amount of resource from the end users. Now, blockchain as data availability service is the most straightforward answer. It is definitely available, like basically we're assuming that everyone has some availability to this blockchain infrastructure and it also have attribution of availability time but the problem is that it incurs on chain storage and we cannot even like, you know, basically purge that storage relatively efficiently and it requires O and monitoring. So, we can get basically piggyback the state of God and that's what we just mentioned also as a data availability service or data connectivity service. It is reasonably available has attribution of availability time because it's constructed sort of like a plasma and it doesn't have any on chain storage and therefore it solves the kind of expensive problem we are facing and it requires actually, oh, I made a typo basically, it actually requires O log and monitoring. We can introduce similar ideas of plasma cash for this kind of a state guarding or data connectivity problem which I'm not going into detail too much. So, basically how it works is that if Alice think Bob is offline, Alice will just submit a state proof to this state guardian network and wait for a timeout and later on Alice will just go on chain and start a truly like one bit claim challenge with money bound. If Bob just respond with actual like a, if Bob respond this challenge with also money bound, what Alice can do is that basically pull out the state availability testament from the side chain and Bob will lose money. So, and if Alice is malicious and submit a state proof, before the timeout actually run out, Bob will observe the state and respond also in the state guardian network for this kind of a data connectivity challenge. Now we talked about the state guardian which is a compact side chain created decentralized trust and it has some collusion resistant, expose a very simple unified interface. There's no additional liquidity lockup, create a very flexible economic dynamics for pricing and also for kind of insurance model for your state. And it also piggyback with a solution for data connectivity and you stay excited, token into the state guardian network and earn some service fees basically. Now, the third challenge we have is network liquidity challenge. We envision in the future a state channel network will look like this. You have a bunch of big node which are the off chain service providers and smaller node which are the end users and how state channel works is like this, right? So you basically have some deposit form each side. And the problem about this is like off chain service provider can run out of money pretty soon. And sometimes there's a mismatch between the off chain service providers technical capability and their capability to wail out like a capitals. And they will eventually result to centralization which is something that we don't want. And how to solve that is basically we construct something called a proof of liquidity commitment mining process. That is to say we try to first incentivize a stable and an abundant liquidity pool for this entire network. There are some liquidity backer has some idle liquidity and they can just lock it up in the seller network. And for example, some lock up 10 years for three years. Some lock up for 30 years for the two years and their virtual mining power is basically the multiplication of these two. And the newly generated the seller token will be distributed proportionally according to that. Now, when someone actually needs liquidity they will just start an auction process. And different people will just start to bid in this auction with different kind of interest rates ask and also with different number of seller token. We'll rank these bits by interest rate first and also then by amount of seller token. So seller token here in this process also act as kind of a frequent flyer mileage token kind of thing. And for example, this guy will finally win the bid and this entire bidding process will be a second price auction to get enough liquidity for this auction service provider to run. And there are tons of details of how to ensure security or enhance the security of this which I'm not going into today. Now we have the proof of liquidity committed mining basically mine seller token by locking idle liquidity in the auction platform and incentivize an abundant and stable liquidity pool and also this liquidity backing auction to actually finish this process. So again, we have the seller wallet running. Feel free to download it at get.seller.app. But before my talk end, I just want to also throw a quick vision of what do we call seller network 2.0. We have seen a lot of like these things popping up of auction scaling technologies, right? So we have a state channel, we have Plasma, we have a sidechain which is not quite Plasma like state channel, state guardian network and also we have true bits like interactive computing protocols. So each of the team is kind of working separately in different domains. What do we think is that auction scaling solutions are sharing a similar high level of philosophies and they can be combined as a coherent solution as where we are already starting to see in the seller network construct that we use the sidechain as kind of a part of the crypto economic construct. So that ends my talk. We have a very good team of researchers, designers and also engineers on board and we are always hiring. Feel free to send email to hiring at seller.network and it will go directly to my mailbox basically, all right? Okay, thank you very much. Oh yeah, any questions? Yes, yeah. So I have two questions. First, you have implemented an EVM here in your platform. I saw it in the white paper. Is that still happening? Yes, that is in the process. We're thinking about doing EOSM actually. Okay, so the EVM part is basically how can we make one set of coding instead of two set of code for auction applications? The reason that we are doing an EVM inside of like a mobile devices, you can run EVM in mobile devices today but what's a challenging part is to use that EVM as a backend for all the front-end interactions for the mobile platform, right? So basically you click a button, it talks to not the Java code but actually the EVM code. So that's kind of like the process we're doing and that's still in progress, yes. Okay, so you're not gonna implement EVM in the near future or you are gonna implement EVM in the future? So, okay, so let me just clarify that it has the capability to run, generalize the state channel applications to implement the, as the EVM. So we are in the process of like combining these two things together. Basically the mobile platform or the user client part and also the EVM, so, yeah. Okay, all right, thank you.