Hashing It Out
Hashing It Out

Episode 40 · 3 years ago

Hashing It Out #40 - Liam Horne - L4

ABOUT THIS EPISODE

Liam Horne is a developer, decentralization expert, and an open source entrepreneur with a focus on state channels. L4 and Counterfactual have released a new development playground that lets software engineers learn and play with state channels right from their browser. Liam gives us insights on what it's taken to get to this point, where the state of state channel development is right now, and where we're going with layer 2 solutions for scaling blockchains.

Links

  • http://twitter.com/liamihorne
  • https://playground.counterfactual.com/
  • https://twitter.com/l4ventures
  • https://l4.ventures/
  • https://lihorne.com/

Hey guys, today's episode has brought you by trail of bits. Trillo BITs, a cyber security company that offers both open source analysis software and consultation services to the blockchain industry. Since they're entrance into blockchain technology from the traditional cybersecurity field, they've released a suite of high quality smart contract analysis products of the community free of charge and work with many of the top companies industry to improve their security stance. This episode is product spotlight is on slither, thrittle bit slidity static analyzer framework, written and python three. slither parses your solidity contracts and compiles them into an intermediate representation language called slith Ir, which enables simple, high precision analysis. It then runs a large suite of vulnerability detectors for its detailed visual information about your contract and also provides an API to easily write custom analysis checks. On top of that, it's fast, an average execution time of less than a second. Not only this slither enable smart contract developers to de fine vulnerabilities, but it also helps enhance through cord comprehension. It's easy to use, helps you figure out what you're doing and helps you write better, more secure code. Find out more because it's Trilli bitscom. That's tr ailof be it Scom, or you can follow them on twitter at Trili bits. Enjoy the show. Guys injeryecast work. Welcome to hashing it out, a podcast where we talked to the tech innovators behind blockchain infrastructure and decentralized networks. We dive into the weeds to get at why and how people build this technology the problems they face along the way. Come listen and learn from the best in the business so you can join their ranks. Hello everyone, welcome back to hashing it out. It's episode forty. I'm your host, Dr Corey Petty, and my trustee cohost calling from Scha say hello everybody, Colin. Hello everybody, Colin. That's it done. Today we have leanhorm from we say L for, yeah, Ol for, and the kind of factual procact of factual project. That's kind of except a little bit there. We've been trying to get you on for quite a while because, said, over the last couple episodes you've been doing a lot of scaling discussions and this is clearly appropriate for that. You want to get start by giving our audience quick introduction as to who you are, how you got introduced into like the blockchain space and what L for is and counter factual is. Yeah, definitely. Yeah. So My name is Liam. I'm mostly, I would say, day Clim an engineer and overall contributed to the scaling research groups in the etherium world. I guess I originally came into the the blockchain space for more of like it's looking valley start up background where, for you know, multiple years after I left university, I was working on that, on basically different startups. On was a location analytics start up, kind of helping figure out where should put physical stores, and then there are a few others that basically we're run out of the startups venture studio called atomic and I had actually, that'sake, this kind of fortunate experience where in University, at the University of Waterloo, I was I was literally classmates with metallic. He was like the inventor of etherium and so I kind verse early on, was kind of following what he was up to personally and it was very interested in the project. So I kind of had a really good understanding of it, but I was looking at it from the lens of this is a phenomenal technology what can it do to you know, actually what kind of businesses can be built in around it or using it, and so I was always trying to figure out what that could be. Basically, I think in again of early two thousand and...

...seventeen, I was trying to answer that specific question and I just asked Batali, like what are the most important things right now and etherium, how are we going to make this secially like a viable feature for like, how will the technology actually have an impact in the future? And the most important thing back then and still today, was just scaling it. And so he just answered like the three most important things are goog of state research, charuting and state channels. And I'd never heard of state channels before, but O, there seem to be a lot of work being done in charting and who mistake? And so I thought, okay, well, I'll do a bit of a deep dive into this. This will be like a small for a. see what you do there. And Yeah, pretty pretty quickly I realize it was much larger than that. I got introduced the Jeff Coleman, who's kind of the inventor of the entire concept. He wrote a blog post in two thousand and fifteen and he's spoke at depcom one about the concept of state channels and he basically was lectured me every single day for a few weeks about in the entirety of his idea of state channels, and I was kind of just very hooked. And so while initially kind of looking at it from like what business is can be start, I just got so deep into actually looking into this specific research problem with state channels that I just I kind of just lost the interest in this business aspect of this focus entirely on building that. And so over the course of the past, I guess, year and a half, two years, I've just been entirely focused on taking what was in Jeff's head at the time of the idea of state channels and translated that into our production technology stack that can actually make it easy for any developer to use the technique because, again, from my narrative to how it was basically saying the most important thing is to build, to make it theory useful, is to scale it, and one of those the state channels, and so I've just been trying to basically get that to be at the point where people can actually use it. That's interesting based on that, based on my history and the, I guess, very unique experience you had with with getting like a one on one primer, but the person who, basically you don't kind of came up there with initial idea. I would like if you could describe, Rye as best or at least maybe to like a layman, what a state channel is in your mind. Yeah, so it definitely it's been this term that's been thrown around in a lot of really confusing ways. I think the easiest way to describe it is that the reason why we need a blockchain is that you fundamentally have this assumption that you don't trust anybody else ever, and so we need this global database that is updated by some kind of contensus mechanism that allows you to put into a transaction without having the trust or discuss anything with anybody, and you can rely that the database will be updated using basically, you know, the the amalgamation of techniques that are using blockchains, such that your transaction will be included, and that's physically have blockchains work huge. Put in the transaction, you can rely that no one's gonna be able to censor that twaction from going to the chain. Updating the state. However, that's like the worst case scenario right in some cases you can you can change it such that if you have the ability to just interact with people without having to not trust anybody, but if anyone ever does act maliciously, then in the worst case and that scenario go to the chain. That would basically speaking, sup dramatically because instead of every single time going to the chain for every state update, you can just communicate with the people that need to care about the state update and do that much quicker because you don't need to involve everybody and involve all this contensus mechanisms that blockchains add. You can just speak to the local people that care about it. But you can have the same trust garant the same trust guarantees, because if ever any of those people are malicious, you can go back to the chain and get your money out. So just changes it from changes blockchain use cases from being like the average case, is really slow and expensive to if to use the chain, to the worst case, is slow and expensive yet to use the chain. And the way it does that is that instead of, you know, you holding on to your money in your own etherium account, your own eath or your own arc, twenty tokens, or whatever it might be that you have control over. What you do is you line up a fixed group of people that you know you're going to be involved with over the next few iterations of this application. You...

...know the common examples of Bar tag what you know you're going to be with the bar for a certain amount of time. You line them up, you put all of your state, which could be either or your se twenty tokens or any state that you have control over, into a single contract and then, off chain, you sign updates with each other, literally coordinating as an every person involved in the arrangement signs off every message, basically so that you, as long as you have you know, since it's among that fixed group, can at any point in time, distribute that state the ether they the Tokens, back onto the block chain. So it's kind of like a son of a group account. Hey, so that's that's great, but can you maybe differentiate between state channels and just payment channels a little bit? It's because they're kind of similar in the way that they function. It's basically the same thing, but stay channels, as the concept that you're proposing is more generalized and so use the term general state channels and maybe you can yeah different. So the history there is that the initial the first time the term like channels were used were basically, I think, to introduce the lightning network. And back then the only function you could do, you know, a bitcoin specifically is send. Right. The function is I want to send money, and so it's naturally was naturally called payment channels. But the analogous technique and Atherium, because you have more ways in which you can update state than just as send function, which is what Bitcoin can do. You can have kind of arbitrary functions that update state. We refer to them as state channels and historically what's happened is that people took the concept of payment channels, the idea that you put money together and you send it amongst each other using that one send function, and they've just translated the exact same feature set onto atherium and they call those payment channels on a theorium to the ideas you lock in Eith into a contract and then you sign messages pertaining to a sense of how the Eith is distributed amongst each other and they call those payment channels. But the reason why we called our technique generalized state channels is that we're not trying to just replicate payment channels on atherium. We're trying to replicate the general technique of band the group together to update the state of the block chain on atherium. And if you take that approach you can do an enormous number of really interesting things because the theoreum doesn't limit you in the same way they pit quite does so. As an example, if you look at what Spain chain has built, or if to this in general, you look at a payment channel, it's very simp it's very limited what you can do. You can send money back and forth. If you look at what raiding is done, they expanded that a little bit and they said not only can you send either back and forth, but you can also send your see twenty Tokens bactors and forward. And that was the next kind of step up from a payment channel. And then if you go one step above that and you look at what this company called Funfair as built, they called their thing fake channel, which is more of a marketing term, but they made it so that not only are you updating the balance as of RFE Twenty Tokens, you're actually updating the state of a specific casino based game. So my role on a roulette wheel and the outcome of the Spinning of the wheel. That's the state you're updating. We're taking it to the absolute like extreme that you can do in Atherium, which is the state you're updating. Is Not hardcore than to any contract. It's just arbitrary etherium transactions, which is a too bull like to value data just abstractly. And what you can do if you look go to that level of abstraction, you can start to update state on the blushing in any way you want, and so what we've done is we've kind of created this model around the state. Then we call at the off chain applications so that if you put money into a state channel, you can begin to instantiate these off applications that pertain to any smart contract. So that might be the tick tack toe game, it might be a payment channel again where you just updating balances, or it might be a chess game, or it might be a derivatives contract. It doesn't matter as long as you can write it in solidity in a contract. We've kind to included that as a type of way with which you can use a state channel, but not not the only way. So we don't call these like tick techte channels or chess channels or, you know, derivatives...

...contract channels, which is called them generalized state channels, where the types of applications you can use can be Defl des fined by the developer. So that's kind of the elite that we've taken. So it's it was payments and tokens or specific games. It's ourtificials, arbitrary state that we then provide a framework for capsulting within specific developers interest and what they want to build, if that makes sense. So yeah, now that's great. So what is the life cycle of such a game? So the reason I'm asking this specifically now is because there was a particular challenge that when I saw the SBC talk that Patrick mccrary gave when I was in Stanford, he even talk about battleship and he identified some certain problems with that particular game. It was a very good example of something that seems like it should work but doesn't, and I'm kind of wondering how you guys are tackling those challenges. Are and I'm assuming you're familiar with those problems, for audience. Basically it's a it's a challenge issue. So somebody wouldn't really lock up their eath for twenty four hours if somebody's messing up, you know what I mean. Are If somebody's not not compliant or playing by the rules of the game. There's a lot of ways you could grief somebody in such a game like that and they found that they couldn't find a solid solution for fixing that. Wondering what kind of research you're doing in that area. Yeah, I think there is up there. There is this fundamental limit that currently there's there's no way around this in any kind of channel or just in general, any kind of off chain construction, which is the easiest way to describe it, as the speaker Listener Fault crivalance problem, which is that if you are in a channel with anybody else or does in general, you're an off chain relationship with anybody else and you sign a message that your counterparty is expected to countersign but they don't, there's no way for any third party. Specifically, there's a way for a block chain to differentiate between that's the person never having received the message or that person intentionally not replying to you, forcing you to go to chain. So there's no way to say that if someone's not replying to you, that they are acting in bad faith. So because of that specific fundamental problem is always it's always possible for someone to, like you said, grief you by forcing you to go to the chain. So the goal of larater system just to make it in my opinion, one of the goals of religier systems is to make it so that it's impossible, or at least the cheapest possible in those scenarios, for you, the honest party, to resolve the channel and get your money back out if your counterparty is being malicious. I think what Patrick Study did is they said that at the present if you would implement it using presently known techniques, or at least presently popular techniques, the griefing costs of a counterparty and in the average case of a game, with the fees that you have to pay in the case that you get like griefs, end up being ridiculous in proportion to small types of average games. And maybe a regular consumer that would make when you want to play a blockchain game for small amount of money, would be willing to pay for the benefits of just playing the game of chain. So I would say with that analysis it's a useful analysis, but there's two conclusions that I would come to come from it. The first is that probably we're not going to one stay channels to be things that humans do with each other. Like it probably doesn't make as much sense for me as a human to like, load up a website and open up a channel and just manually click buttons and use my state channel that way as much as it makes sense for bots to do it could, because the reason is humans have all kinds of error scenarios where they as they leave, they are gone for too long of a time, they forget the computer crashes that lead to crash anarias very frequently. I think it makes much more sense for bots to eating state channels in different kinds of relationships where they can be much more reliable and additionally, they can provide guarantees of their uptime that other people can account for, such that the this scenario is where someone does go offline, it's a software error and...

...it's very infrequent. I think that's one of the first conclusions that come from it. The second conclusion is that I think in his study. There's just a number of techniques that you can use to really minimize that briefing cost that so far no one is really done, I think, like an x silent job of building a solution for. We're trying to go in that direction so that, no matter what the type of griefing Stereo is, the actile cost that you incur as the person being griefed is the absolute, like extreme limit of in terms of the minimum that about that you could pay. So I think there's still a lot of wiggle room for Patrick Study. But additionally I think it's also true that you want to make sure that you are playing against somebody that's extremely unlikely to grief you, because it's in their incentive and it should always be in there's incentive to knock grief you. That makes sense. So there's a lot of oppilation room. But he did touch on the a fundamental limit and he disposed it in a bit of a grandiose way. I'd say. Yeah, it was pretty interesting actually, the way he talks about it. I see what you're saying with the box, but you do not see a use case at all for humans to want to interact with these things on a more personal level. I do certainly see a use case. I just think that, because I make change, to me is a perfect use case. Like, even though they're not general at this point, sounds like they're closer to payment. It's it seems like people would want to do on demand purchasing for low cost and I don't think necessarily a plasma channels always the best choice. I think it's more along the lines of, like stay channels are really useful for when you when you're in scenarios where everyone is incentivized to work together all the time. If you have scenarios where there's a potential for grieving or someone to back out of the scenario and the rest of playing out that scenario gets expensive or lengthy, then stay channels may not be the right pace. But, like scenarios were, like the odds if those things happening are very low it maybe it may be worth while. I think also that there what important point is that the design space within which you can operate in to make types of applications where everybody's insteadivised to behave correctly is still not that well explored explored, and there's a lot of optimisations to be made still, like in our the way that we like at l for and with the conifatial project, whether we approach things, is we want to make it to that for any arbitrary application, it is. It's the Maximili thing. sentives are build into way that it's always in your intentive just keep on going and to keep playing the to keep using the application up getting state and behaving in a predictable manner, because the not doing that deally. It's such a way that it every minute time step of state updates. It's just it's always in your it's always in your favorites to cooperate and if it's ever not at a simply because of some externality, that is something that blockching simply can't capture. Like the example would be that either you just you fundamentally have a hatred for your counterparty that makes you want to discrief them, even though you might incur a bunch of cost yourself for briefing them and you lose money and they lose money, you benefit in some way from just briefing them because you feel satisfied from that right. That's an example of an externality. But yeah, one of the reasons why that's a human thing right. One of these is why I think computer based systems that do this is that they will not have those types of externalities. And additionally, this is things become more anonymous and private and you don't really know who you're dealing with. It's just simply an economical cost. It's just simply you look at the problem. If I cooperate, I get paid and everything will go smoothly. If I don't cooperate, I lose money. That's the only decision that you have to make. It'll always be the case you cooperate. So that that's the that's the design space that we kind of operating in that we think we want to match formize. So you've obviously then you must have mapped out like a ton of like scenarios where you need to mitigate that kind of risk. Maybe you can go through those scenarios for audience so we can kind of understand what that risk looks like. Yeah, I mean a lot of these things end up being like highly specific, but like one way of looking at it is obviously to look at the types...

...of ways that someone could grief you. So in a state channel, you always have a situation where you are signing an update you send a message, you account of Party and your expect them to apply. They have a couple of options, or rather you have a couple of options. If they don't apply, you can either go to chain and basically forced your counterparty to make a move, which means that you have to now incur the gas costs and that sucks for you, or you can wait it out for a certain amount of time, but in that case you're in your occurring kind of this opportunity cost, because now your capital is being locked up in a way that you did not initially want it to be locked up in, because you can't actually use it anymore because your counterparties on responsible. So both cases can have incurring at cost. So I guess one one of the ways in which we look at this design spasically found a solution is it's pretty straight forward. Solution is that if ever you get in the situation, you the person that as to go to the chain, can initially, when you set up the channel, have agreed upon with the counterparty that, if this ever happens, will split the gas costs in half. So if the other person is not replying to you, you going the chain is not like you just paying all of that gas costs in your out of pocket. It's actually splitting with the counterparty. So you'll pay half, they'll pay half. So the cost of someone not replying to you, from their point of view, actually is not just now this person go with the chain and that to wait. It's, as the eye, myself paying money for not responding. So that's one way we can slightly change the incentives, but not just one of many. Another another one, I guess I would add, is that there's this there's this problem that sometimes talked or talked about, where it's possible and if he's have these long lasting channels with lots of upplications and lots of state updates, that someone might go to the chain and just put all of them on the exact same time, kind of just flooding the chain with channel closed commands. Basically our challenges. One way that we make it that is part of the protocol we designed, is very periodically we're going to do like a bit of a garbage collection. So as often as is humanly possible we countersign things saying that if ever you would go to chain with any of this set of old states, this one single command that we've signed will nullify all of them. So it's kind of like this garbage collection for garbage cussion process built into the protocol so that every few updates you're kind of recycling all the old stuff that no longer needs to be disputed individually and it can be disputed in mass, and so that's one additional way that we've added something to the protocol to handle this. But again, these are kind of on the fringes and as we develop the protocol is what people use at the hope is that it's just simply the case that, no matter how large St scale, you always have an easy exit that's cheap for you and incurse the cost for our counterparty if ever there's militia's activity. So they get the goal was just make it simple and cheap and and make the attack doctors as small as possible. That's interesting. I have when I first learned about Yall's implementation of state channels a while ago, I was under the impression that the way that it differentiated itself was that it never initiated the state on chain and only basically set things up so that anyone could initiate it when they needed to. So like when you start thinking about stay channels. Do you have initiation phase where everyone basically puts all of their assets that they would like to put to the channel into it through a transaction? They broadcast that the channel is opened and then they interacted each other at nauseum until they're done with whatever they're doing, and then they, when they're done, they agree, they publish whatever the end state is. And what something that all four was doing, or counter factual was doing, was basically saying we're not going to do the initiation transaction, we're just going to set things up so that at any point during our discussion we can public wish the current state to the transaction that changes things appropriately. Is that no longer the case, or did I have it wrong? eventially, that's certainly still the case, I think. I think what's happened over the course of the past like years we've been working on this is that more other people have been following the same kind of technique we've actually I think we've I think we've gotten it to be...

...the absolute most like minimal API, so the only API that we actually have on chain in the honest scenario. So if there's no dispute, which is a not really dispute, but protocol deviation and handled a separate way. In the honest case, the only two operations that you ever see on chain are deposit and withdraw. That's it. This is also why I think it's a good mental all to think of the state channels as kind of this group activity, because you deposit into the group and you withdraw from the group and those are the only actions you every need to do. Everything else is a signatures off chain. So we never actually, in the honest case, put any state on chain or even reference to the application that's been used on chain at all. So if you and I, for example, wanted to open up a state channel, what we would do is just I would put in whatever I want to put in this a channel. You would put in whatever you want to put into the state channel. That's all you'd see on chain. Then off chain you'd speak the counterfact a protocol which, you know, the software that we have does all that automatically for you. And we've begun saying okay, let's do it with that toe game. Let's set up a contract for difference, let's agree on this Oracle and some point in the future just figuring out how our money is distributed and we do all kinds of agreement's just specifically between us, and then, you know, that might update our balances that we've perceived between each other. And at any point in time I want to take some money out, I just go to the chain and say want to withdraw this amount out. You would countersign the because you were being honest, and then some money would leave. But just put the money in, take the money out, and in between you're using this option, Cheam Protocol, which you know is designed. It's just a way to be secure and minimally minimal attack pators and things like this. So yeah, definitely we've designed it to be the most bare bones interface is possible. We actually like. One thing we want to do is because it's there's such a basic interface and the only actual launching function that you need is the ability for us to agree on things next to you to transaction, which is basically a multistick. What we actually want to do is try to get state channel is itself, the API for that, built into like the actual core protocol of like these, the core like Jason Rpc, that theorem exposes, and how have the multisike itself be a primitive on the theoryum, sort of the ideal world, all possible multisticks already exist. We just put money in and out of them as we as we will and use the schannel protocol whatever the money's in there. That's the the I think that's that the optimum end resolve of channels is. It's just a group protocol for dealing with money. That would be, I'd be quite a wonderful thing, because not all, I arm, will be. Stigs are a wonderful thing to have as a primitive, but they that that having a protocol like that with a minimal API, generalizes what can be done with a with a Multon stick account quite well and really really sets the tone for what the blockchain is actually use for, which is just that they don't the end all truth of the handling of money. The actual business logic associated with applications, businesses, whatever can be done off chain and its own trust environment, and not necessarily the trustless one that is blockchain. Yeah, yeah, I really, I really do hope this does start to happen and I think we should one thing that we should be doing intring to rally a bit more and the etherium like internals in the core protocol development to try and get these things plugged in like this. We haven't like a tract word of this working, which is the for example, with the create to upcode before. It's pretty hard for that because one thing that that gives us is that you have the terminusic addressing for all multi sticks, so you don't actually need to create the multiceal on chain, and so we've been able to do this before. But getting an up code actually merge into the main a THEOREM SPEC so I think most people underestimate that theorem is willing to adopt things that make things better. So yeah, I hoping then we can do that in the future. So can you tell us a little more about what it takes to build this from a team perspective, from a design perspective, what what do...

...you actually what is the what is your experiment look like? How does this start and then what is it evolved into? And what you know, what is the code look so yeah, so one of the things that I had learned from having been doing businesses in the past, of startups, is that it's extremely important to have the right incentives for everybody involved in any particular project and so right at the start when we started working on state channels, kind of ask myself, is this a business? Are People going to pay for this is you know, should we run a hub? Should we in some way? Maybe we should do consulting or something like that. But nothing really made much sense because at the fundamental way that we look at this whole problem is that this should be a primitive in aetherium. It's a basic data structure and a basic protocol that just doesn't itself need to be branded or in any way done in its own, like unique way. And so so the way that we approached it is this should be an open source project. We should run it kind of like what you look in the web community, like react or like our ember or things like that. And so basically the way I looked at it just like, let's get a bunch of good research out there, meet other people that are interesting this problem and try and structure a project that can get all of them working together without compromising on, you know, who owns it or who has control over it. Simply do simply trying our best to make this its own open source project. So that's how we approached it. We actually have now L for my company, developers that we have basically being paid to work on this and additionally, another any called prototyple that it is also paying developers to work on this. And as we've gone about this over the past year, we've also tried to a handful of other independent developers is interested in the problem, and so everything we do is it's public, it's it's all open source. Anyone can come in and we'll help them get up to speed with it. We also would look we also love partnering other projects, for example with Pisa that Patricl cores working on, and just gender. Genuinely speaking, we just trying to start it in such a way that we get the best quality protocol the help a theorem. It's a lead the charge of layer two protocols and development of applications in layer to do it in a way that is cohesive to the people can learn from what we're doing and actually built on top of it and never really deviate from that core goal. At some point in the future maybe some businesses will emerge, but right now we just want to build something that goes right into like a ness right. They're like comfortably into the theorem protocol. The say channels can just be a common good that everyone benefits from. In the meantime, you know, because blockchains have this kind of this treasury notion of that the original you know, people the launch the chain that foundations have funds. Were funded by the Therem Foundation, and it's in everyone's incentive. Basically, they want to see if you succeed. You want to see the protocol grow. We ourselves are just in the technology and we want to see the protocol grow as well. We wanted to succeed and so, you know, we're funded in order to do exactly that. So that's the way we approached it. At the moment we have, I think in total there or seven or eight engineers that spend full time or very close to full time, on actual development of the whole text act. And Yeah, and it seems to be growing and we have a bunch of people coming all the time that are interested in contributing, and so the goal is just, you know, learn from things like ember and other open source projects how you run a community like this and just do our best to see a growth that makes sense. So I noticed at L for is called L four dventures, and so I guess that is what you were just talking about. What is your relationship of that counterfactual? How do those two enter this to corely? Yeah, so, so L for is very interesting company. Basically what it is is it's myself and the others in the company that had a similar kind of passion for eitherium in this community and we didn't really know how to monetize her, what exactly to do, but we really really wanted to work on like court protocol development. We really want to...

...see it succeed, and so the way we approach it is this teaming up and will create different types of ventures, whether they're open source projects or or the kind of things I can talk about in a minute, that all benefit from being worked on by the same general group. And so what we do right now is we work on counterfactual. That's the kind of way that we frame it, is that we just have engineers that we put full time on counterfactual to help that product grow, but we ourselves don't own it. And we also work on eighth global, which is basically a hackathone organization that every few months of basically we run a large etherium packathon like you may have seen eath waterloo or or ethquenas areas or eath Berlin or Eth India or all these different etherium Hagathons, and the goal of those just get developers into the ecosystem. So again that's another's initiative to help ECO system grow. Myself and some of my friends and people that are not in help for but they're also passionate about this that you know I've worked with over the past several years, help with it and we do this together and so it's a really good initiative. And some of the people that work any global also working kind of factual and so there's a nice overlap there. So I just I think it's important to understand the separation of concerns with your with regards to everyone's incentive, my intentive is obviously to have my company and the people involved be very happy and we working meaningful stuff and for the things that we're working on to pay them well. But separately, the things that we're working on should lead to a really good end result for the stakeholders involved, which at the moment is mostly the Effi in community itself that you know, by practically the foundation of funding this these projects. So we've global. We hope that we can get a bunch of developers on board into the ECO system and then that'll lead to more interesting things being built or, you know, more users as effectively demanding good documentation and good, you know, scenarios for which the core protocol developers can use for feedback of how to develop the protocol. And then, separately, with counterfactual, we hope that we can lead to really useful tools for those exact same developers to build useful applications. So and then the day it's just like it's our company that we think is doing good for the ecosystem and the way that we do good is to these projects that we ensure everyone involved with is properly incentivised to work on. So let's talk about counterfactual for a second, because you guys just released to playground and that's like it's actually going to work. All sort of play with the stuff that you're talking about. So maybe you can give a big Ole announcement and tells how people can get involved in that. It definitely so one of those. So my background, I get some startups, is always taught me like you need to be able to communicate effeculate to people. What is the value proposistem what you're working on and what is it the minimum biable product in some way that you can get out that shows that value problem and with this project with state channels, the mvps surprisingly complicated, but really that's what the playground is. So it's this thing we just released a couple days ago, not as a product or anything like that that we're shipping as a company, but simply as a developer like sandbox environment that shows off all of the technology that we've been working on recently to production, I. State Channels. So what it is is it's a website that you can go to, you create an account with the website and what that does is it creates a state channel between you and a hub, which is something that we're running basically on a broker server in the background. And then what you can do is anyone else that's created an account a state channel with this hub, you can open what's called a virtual channel with them to play any arbitrary if they're in based game or at location in general. And the two of that we've putten on their tick. That toe and this dice rolling game where the higher two dice rolls went some me to show off a their random thiss. So the point of this project, this playground, is that any person anywhere in the world can just go to this website, which is playground COUNTERFACTU Acom. They can load it up, they can use it and they can see what it means to have, you know, the power of...

...generalizetate channels put into a production application, which, at this case it's just very simple. It's you create an account, you deposit your money in, you do any all this stuff off chain and then whenever you want you can withdraw money out, just as I said. And instead of it just being, you know, me talking about it, or presentation and a slide deck, whatever it might be, it's a tangible production ready APP that's running in your browser that you can look look and feel and see what it's like. So that's what the playground is. And the cool part is everything that's on the playground, all the code, is open source. You can peruse it on our GITHUB and you can see how this is all built. We've taken an approach with development itself, that's that all the pieces are reasonably modular. So the applications themselves are built with this developer library called CFHS. The environment called the playground hits its own environmental environmental container. It kind of mimics a wallet and in fact that specific piece of the of the code is being merged into Meta mask right now to kind of show you what it would look like to have stay channels built into your state channel walled itself. And additionally we have this node, which is the core saw where the runs in the browser, and that's also the same software that we're running in the cloud. That is like your stage channel node and, of course, all the protocols. The goal is to be able to go to emn person and sit down with them, explain my state jails interesting and then show them this demo, show them the code, and have them say, Oh, I see, I get how you can build this. It's not some obscure, complicated research constant anymore. It's it's there, it's in code, it makes sense. You know. Now I can begin to either use it or contribute to it in a way. That's saying it makes sense and isn't daunting, as most you know, blockchain research problems tend to be. So are you targeting one specific type of language or platform or like? Is there? Is it just a suite of tools that you can integrate into any project. Yeah, so presently everything is written in type script, mostly because, well, there's a couple of reasons. One is it's, you know, it's a very simple developer language people can read and understand. And too is it's very easy to get that running in a node process or in the browser. And from our point of view, in order to show this two people such they get it, you really want to be in an environment that they feel comfortable with and familiar with. It's much easier to say just go to this website and it is to say download this binary, learn it in the terminal in the background and then open up this thing. And then it's just too complicated and from one of the things we've seen, for example with with with raiding, is that if you want to run your own rating note, it's all this is huge python client. have to download, you have to do all these steps, and that's small little friction point. Is just limited the number of people that interact with it. But with this, you go to website, it's running like immediately, you just load up the website immediately. You know, have a state channel wall up that you can put money into. So it's a very important way to kind of get people's attention because they can just easily access it. So that's honestly, that's the main motivation behind why are we built it the way we did so far? I think that as you productionize this to the point where you're going to have real money and you want this to be truly performant, you're going to have different clients than implement the protocol. So there might be like a rust client that we work on in the future, but again taking a more of like a start up in oriative approach. We don't want to put you don't we don't want to get away ahead of ourselves here. This is still like early, early days for blockchains and super early as for state channels. Let's just get something working in an environment that has minimum friction for people to get involved with it, and then when that starts to work and we have to see people wanting to do stuff with it and the use cases get more complicated and have more demands, then have the engineering in the technology begin to follow those those demands and that user feedback, versus assuming some kind of extreme end state scenario years on the line and doing that first. So we don't have any particular bias intore like how this thing should ultimately get built in the ideal with way. We just want to buy us for getting something that works, that shows the functionality in people's hands as soon as possible, and to simplify the actual code itself and that and the concepts that are used, so that it's easy for any developer to get started with it. I think perhaps, like from our experience with Youth Global,...

...one of these hackathons where where we have all kinds of new developers all the time getting into the ecosystem. They don't have time to understand all the ridiculous complexity of this of this ecosystem. They just want to know, how do I build a decentralized APP? How do I do that? Give me like the getting started guide, the how to, the tutorial, the Youtube Video, and so we want to be able to get from where we are to that. Did answer to that question. Is it as possible. That's like, that's what mode of motivates are our development. You can basically trying to do a cryptosombies did for smart contract development, for you know, State Channel Development, and I think that a lot of APP instance development. I guess you could say is that an appropriate way to use that term? Yeah, I think I think it's. I think it's state channel application development. I I don't really like the term DAPP, and so if I've kind of generally avoided using that term, but I in the way that it is used in the in the terms of people referring to like if three in base applications. I would just say this is still adapt it just happens to be the case that instead of making contract calls every time you want to do a state update, you just make calls to a node and you use our API to do that. So it's the same concept of building it APP. You just have a different backend API that happens to return things faster and doesn't cost gas, but the same general concept. Just out of curiosity, as already cut you off. But the the interesting thing that keeps coming up, came up with Georgio's came up Patrick, is that state channels will be a very good alter native to running smart contracts directly on something like a what's conventionally called a plasma chain. Patrick, as another word for it with my brain is blinking on yet again. What do you commit chain? Called it a commit chain. Thank you, what do you see those two playing in with each other and how do you think maybe state channels? So, for instance, one of the griefing ways to grief is incurring a fee cost for a challenge by, you know, withholding the fact that you've received something and then grief you somebody that way. But that's because when you do the on chain commitments and all that stuff, each each transaction has a cost associated with especially since you're committing state, which is storage cost, which is per two hundred fty. Six Bits is Twenty Tho, you know, gas. So to all float some of that, some of the things have been discussed, is possibly merging the to cought, are mergings out the right word, using the two concepts of a commit chain, Aka a plasma chain, and state channels together so that you could kind of like mitigate that stuff? How do you see that future kind of evolving? Yeah, so I think I think it's really important to and Patrick is a good job of this and his life. Separation of concerns is is differentiate the two techniques in terms of whether you useful. Easiest way for me to describe it is that with stay channels, they're the best case Free State channels is when you know specifically who you're going to be interacting with and it's not unknown. So it's things like payments between fixed groups of people. It's things like, you know, Games like tick tacte or contracts, where they're basically the participant set is fixed. In any situation where you know who you're going to be interacting with ahead of time, it's clear. They channels are always the best way to go in any situation. Plasma, or just more generally, kmit chains, are useful for tuxed applications where you don't know who you're going to be interacting with ahead of time. So you know, dex's are really good, example, market places of any kind like this. You know public commits that you want to say hey to the public. This is something I need everybody understand and be aware of. You know, in order book, that's where plasma really shines because we stay channels, you...

...fundamentally can't expose this external state to the world. It's locked within the fixed group, and that's really it like in terms of when you need to decide today, use plasma, should I use stay channels, or is in general? What is the what's the difference that's that's like. That's fundamentally the difference. It's always better if you know how to time we do work. At any point, like, do you see them actually like interacting with each other? Yeah, certainly. I think that the way that you're going to interact with them is I don't think is any kind of like magical new third type of term that we can coin for the interaction between them. I think it's just I think the interaction between state channels and plasma is the same as the interacting between state channels and the main chain. The only difference is that if it's stay channels on plasma, you get all the benefits of state channels and all the benefits of Plasma, at least for the specific application that you're using, with the restrictions of state channels still, if that makes sense. So an example would be if you have a plasma chain and you have an account on a plasma chain, then you get this nice benefit that you're probably not going to pay fees and you don't have to go to the main chain any time you want to do anything on the you can do the stay channels. You can open an up up state channel between your account and any other account on the plasma chain, so that, in addition so having to go to chain for say that for whatever you're doing the plasma chain, you also don't need to go to chain, or rather you need to pay fees for the deposit and the withdraw step, which I mentioned, in the only two steps you need to worry about the state channels of it to begin with, so depositing and withdrawing can become felas as well. So that's a nice benefit, right. If you have a plasma chain, then creating a state channel is essentially free and there's no reason not to do it in that case. But I think it's important to make sure that you just stay these the two distinct solutions which happened to work well with each other, but that both offer distinct benefits compared to using the main chain individual that Ma sends. Yeah, they're isolated logically from each other, so that it's important to make sure that we understand that they are two separate development paths, but they do have this sort of like correlative like we probably should be working together so they're all compatible with each other. So if there's a standard first state chains and there's a standard for plasma plasma should probably implement the standard for state chains as well so that it can get all the benefits of the pop, sorry, steep, state channels it as well, so I get all the benefits of them. Yeah, we actually have a pretty cool project that were we haven't announced yet, that we're just embarking on now, which is effectively doing like precisely that, is ensuring that kind of leading plasma chain developers, or, more generally speaking, that the standards that are being implemented her plasma chains have the ability to support channels out of the box. The most recent development and plasma chains, which is predicate technique, which is basically the idea that for any given coin in the plasma chain you have a different Texa game. So if you have a coin that represents, saying, US, twenty token, or if it represents again, strip your kitty, whatever it might be, when you actually go to chain, as a different mechanism for how you distribute that back to whoever it is and owns it. And so what we've developed is a predicate that works for State Channel beat assets. So that's physically a multi sake predicate. So most important thing being that if you have some point that's on the plasma chain. You have the ability to say that this specific coin actually represents something that is owned by multiple people and use this multi SAC predicate for that. The predicate kind of terminology is coin basically by this plasma group team, and you can see all of their code as well, which is open source. And so that's the first half. The second half is with count of factual, because the actual framework that we've design can store arbitrary state again, like Eth or new arc twenty token or sevendred twenty one token or or literally anything, because our core primitive is just an etherium transaction. What what we're...

...doing if you're building an example counterfactual APP which uses plasma cash coins as the actual state that you have under your state channels control. And so one of the cool things that we're going to be able to ship in the next little while, after we build all of this, is on the playground. Probably we will put this an application where you actually deposit money into a plasma chain, but then you begin to interact with other people that are also in a state channel that's connected to that plasma chain to do any of these games. So I think that toe or high roller or any other game that we have in the demo. You can not be betting Eith, but you can actually be betting plasma cash points. And the cool thing is that, again, like I mentioned, the deposit and with draw step will be instant to the entire experience would not involve the etherium chain at all. That you want have to do any transact system in a mask, which is really cool. So we're already embarking on this kind of development road band the moment. I'm very happy to hear that. That's amazing. Yeah, I's than on that one. That's kind of like I like to ask this question to a lot of people who we have on or looking at the kind of the fundamental protocols and the layers of the stack that end up serving various applications and users. How do you see in user eventually interacting with this technology? Do you see it as completely offuscated from the end user and they experience the same thing they do with centralized applications, or do you see a fundamentally different way in which they interact with things and, if so, like, what are the differentiators of why this is important to do in the first place? Yeah, so I think that all of this stuff ends up just becoming an API that you call in the application the same way any of it, eate, any other API is called, and it just happens to be an API that offers you a very specific benefit, which is that, for things that have to do with state that you control personally, your own, you know, either your funds with either token, or some of the state that you can care about that you now have access to because of basically block chains, you can trustlessly interact with that state through some logic by this API. But it's the same way that you would call an API to update a database record on a centralized website or some company. It just happens to be the case at this API works regardless of any particular company. It just works using all these protocols we developed. So I think the end of the day, all we really need to do is provide a dead simple way for any existing application to replace the center realized services that they already used with a decentralized one with the absolute minimum amount of tradeoffs possible and, ideally a benefit that actually helps their that's that they're their business use case, and so that's what one of all amount do you I mean, are going to be good way of looking at this is met a mask. Right now. It's a bit in your face. You have this thing on the on the browser, but it's significantly better than literally running, say, like a blockchain in your browser and making calls that thing, because it's just absurd obstruction of technology in the face of a user. We've gotten down to a comic tension. So you just have to click a button every now and then. That's pretty nice, but we can do much, much better. At the end of the day. You should never see anything to do with a blockchain in your user experience. You should just have your user experience and be able to rely on whatever the promise is, that the application that gives you and you can, if you really to, inspect the source code to see that it's using these API and these protocols in the way that you can trust. The same way that we have all this interesting stuff to do secure transport, secure messaging and secure, you know, distribution of web assets, which is itself costedily complicated and interesting and involves a kind of crypto. But all a user sees a little green lock in the URL bar that says this site is secure. That's all I need to see. So I think the end of the day, that's that's what blockchain, all of this stuff that we're working able to amount to is just, you know, a little green lock that let you do something new and that's it. That's the use of though, the the actual market incentives that will just do will decide what kinds of products and businesses get built. That's a whole different question.

Yeah, there's the user experience. Yeah, just a little green lock, I think. So what's the dream? Room? Like? Think that's that's like. Yeah, I mean you've you've outline of future from user experience in point. But what's the dream from a societal impacts? What's what's The ideology driving you? Yeah, I think that. I don't think I necessarily subscribe the same way that others due to this the centralization movement in general. For All things, I think that that's a really nice direction to head in, but I don't pretend that that is the direction, that that's the end state that we're going to arrive at. It's kind of like saying this particular like way in which society stop rate, if it's like socialism, would be this beautiful end state where everyone wins out, but when you put into practice you realize all these weird situations that occur because of human behavior. That doesn't really make it work. I don't think that it's worthwhile to say that I'm like in a centralization maximalist and that's the way the world should be, because it's just impractical to make real large societal societal's changes with that kind of mindset. I think the minds oft I have is that this is a technology which introduces a fundamental new concept. You can now move value around without a little bit. That's basically that's that's the only thing that really provides. And so now that we can do that, what types of to cus existence society where the middle man can very easily get cut out in a way that doesn't really disturb human behavior, and let's just replace those things of better technology. And when those things get replaced, there will be new businesses which can emerge because of it. For example, the most basic example is that with stay channels are most even better example is that the blockchain. Now there's this notion of a minor that's a new type of business that never existed before, but now people can do that and they can make money, and you can, you know, you can basically make a living from that kind of new behavior that he's as in the world, and so and so businesses will begin to do that. So as we build the technology to get rid of basically, not necessarily when seeking him with the wrong term, but businesses that exist in society that could easily beat removed. Ya, it's better, technology will replace them with new kinds of businesses, which others will then fill in with different companies that are addressed the market demand for it, and then we'll just take a step forward. What do? A small iteration forward and where societies apt. But by no means are we're going to build a utopia with all this. We're just going to slightly change the incentives in a way that makes basically society of slightly better, just because we're getting rid of middle men that are slow and bureaucratic, can have unnecessary technological delays because it just haven't used the latest technology more or less. So that's so bad, little men. And see if there's if they're if you think that they're actually going to be fully replaced or only partially replaced by this. Well, even like I think is it's kind of hard to look at it that way because there's not really a full or partial replacement. Like one way when way to look at it is it would be very nice if we could, say, build this global centralized asset exchange for all assets and completely get rid of the New York Stock Exchange and all kinds of exchanges and just make it a human right that you have the ability to exchange with the other humans like that sounds amazing, it's great, but it's not like that vision kills the company of the New York stocking change. The air stocking change is just the collection of humans that currently have a way that business works. But as technology adapts they're going to slowly migrate over two different things that make sense space in the technology. So you know, it doesn't take a long time. Presently we're thinking, okay, well, we can use this technology to digitally wrap the existing securities and trade them over the botching protocol, which will maybe be easier for people to access but you know, arguably still be slower than just the existing rails. That just a wallshy, for example, but at least the being more open. And so what they're going to do is they're going to slowly adapt to that and build things that bridge into that system, but the actual existing company do not stock...

...change won't die. The point making it's unrealistic to think that we're going to change society and a fundamental like and our anarchy kind of way is more so slightly changing the incentives that will lead to new businesses that emerge and we're just pushing society for it slowly, one step at a time. I think it's just a better mental model because it leads to more realistic outcomes. A upper yeah, you also don't want to received as a threat. Like set up their own coin. So we want that. We want the those people start playing with the stuff, using it, seeing how how it could be integrated and while it might be their own chain in their own coin, at least it's a step in the direction where they're going. A we need to probably adopt this. I mean, at the end of the day, as none of us is getting rid of a middleman, it's changing the middle man to be something that's fundamentally different and they had can like say, for instance, pitcoin. Bitcoin is maybe changing the middleman from a bank a small coupball of people with heavily and heavily biased and sentence to the minors to verify transactions, who were playing a fair game, and it's very, very difficult to very very difficult to co OP and they're also in these things are run by software around by math or so on and so forth, that are also difficult to remove, the greed associated with the verification of transactions or ability to censor, and so you're just you're moving these middlemen into something that's more distributed, distributed or fair in the context for that makes more sense or where you would want something like that, for people can't arbitrarily make decisions that affect a bunch of people based on a small desire or whim. Yeah, I think an important thing like that. Note to mention is that it's it's creating new incentives that lead to new types of businesses that can fill in the gaps that maybe didn't exist before because they were just completely locked out. For example, it's I can't really list an asset in the near stalks change right now. It's like impractical, but at all the kind calls and yeah, I could easily just like throw one in there and it's be an open protocol. However, at the moment I can't do that right. So I think the way they look at it is if we do this, we open up the possibility for new businesses to come in, but it doesn't necessarily mean that they're going to be this to centralized, purely distributed group of people. They'll probably still be centralized in the way that we have like pretty centralized miners and in, you know, the light network for example, and in most a channel that works to probably be large centralized hubs. But that's not a problem just because it does not everything in the entire stack is distributed in a perfectly even way. The difference is that we have basically the equality of opportunity for everybody to be able to participate in this new model and the best businesses will still went out. It's kind of like decentralization in some ways. It's kind of it's slightly like approximated this equal, equal outcome kind of idea, but that's not what it represents. It's just equal opportunity in the sense of new businesses will emerge that anyone can participate in instead of being locked out by gatekeepers. But it doesn't mean that they're going to win. There's still going to be businesses that will dominate those new new kind of factors to make what I think that's good. I think that's a good way for capitalism to kind of keep moving forward using this technology. So I agree. I think it's also a great way to kind of wrap up this episode, because are there any questions or things that you would have liked us to discuss that we didn't get around asking about? No, I think I'm going to from my point of view, our team and l four and with the counterfactual project, our main mission right now is just keep getting this protocol to be simple and easy to understand and have tangible entry points for developers to to look get it and build on it with, and so I just hope that we can get any feedback, we can have people looking at it and telling us what they think and hopefully we can just keep moving forward to the team to make it to the more people that care about this stuff can actually take an axe item and use it as soon as possible. Separately with eth global, the other thing that we're working on, we're actively running hackathons across the world every few months. We Have Cape Town in April. We're going to be doing waterloo later on this year New York,...

Boston, India, and so if you ever want to just kind of hack on a theory and really the stuff, then you feel free to come to our hackathons and they're free for everybody. So it's just simply a matter of kind of having fun building stuff on the technology. I'll back that up. I was been to a few of them. I swear by them. Their wonderful events and I will continue to go to them and contribute. How can people reach out? How can people get all have you? I'm on twitter at Liam I horn. I also happily accept emails. Liam at L Four v Dooh. Or if you just want to chat quickly, we have a chat oncounter factual. It's just chatcounter FACTUALCOM and you can chat with me there. I'm pretty widely accessible outstanding and listeners. If you enjoy this, click the subscribe button, put the white buttons share it on twitter. You can find us as a podcast on hashing it out. Pod On twitter at Core Petty and Colin is at Colin Cuche, Coln Suscu. Thanks a lot, lamber. Appreciate your come on. Yeah, thanks, is Great.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (111)