Scalability plus Security

peps and i'm here to talk about getting getting scalability plus security and what kind of properties that we want to get and I think kind of in our solution which I think achieves like a lot of cool properties which you kind of may not have have been focused on so in terms of kind of goals of what we want when we're talking about scaling smart contracts and and kind of building smart contracts there's kind of a lot of different things that we want to achieve that kind of are sometimes contradictory properties and a lot of different solutions have different trade-offs so we want scalability and and what does scalability mean is is kind of an it means different things to different people we want security that's pretty straightforward we don't want anybody stealing our money we want compatibility interoperability so you know we don't want to all be in our own little boxes and not be able to interact with the blockchain in general and what's more contracting so I mean asset transfer is great but like this isn't etherium event we want smart contracts and we want to be able to do cool stuff there so then scalability and this is topic I think about a lot because scalability is really valuable and it's value and there's a lot of different elements of scalability so but kind of the most common thing that people think about is high throughput like how many transactions per second can your system do and that's obviously important that kind of is directly related to how many users you have that's pretty valuable but there's a lot of other important things going on too so low latency time to finality in aetherium if you want your users to actually be secure they might be sitting there on a little spinning ball for five minutes waiting for their transaction to confirm and get enough confirmations to be secured and so you really want to avoid that you really want to have a low latency experience where users can click and it's committed you want to support many participants so you want to be able to kind of have it have a DAP that a lot of people can use you want to have ample storage you don't want to have like the tiny amount of storage that you can currently have in the ethereum blockchain via storage is so expensive and you want to do complex computation like you don't want to be limited to only very very simple pieces of computation and logic and that's kind of both the size of the contract which I know from experience building our own system the like size limit is really annoying in terms of how much code you can write um and also you want to be able to run a lot of instructions per second and have an efficient machine so I mean not need to like the gas limit kind of as a very limiting factor so then the question is can we achieve all these things that's a whole lot of properties that I just listed and I think probably most people would agree that they're basically all really valuable and you know you get into a kind of sacrificing some for others but like optimally you would achieve as much of that as possible and and I think we have a solution that it that achieves good been to that for a lot of applications and kind of just in terms of like what we are I mean there's a lot of different places that scaling takes place there's like all the amazing work going on with like aetherium 2.0 and all of that awesome stuff but we are squarely focused on layer 2 building on top of an underlying blockchain and adding a lot of value to that so orbitrim makes smart contracts scalable and secure arbitral being being kind of the main product that we're developing that i'm gonna be talking about today and we use a combination of let's see protocol design incentive mechanism mechanisms and a virtual machine architecture and so we have kind of a lot of different components and a lot of different areas of research that have combined to make this possible and I'll give you kind of an idea about how all of these different different techniques come into play in our system so how our Bertrum works and this is kind of gonna go a little bit into the technical detail of essentially like what our magic solution is so that you can understand if it's something that would be useful for you so kind of I'm gonna start with some terminology that's useful in understanding what's going on in our system so first of all we our consensus agnostic that kind of we're a layer two we don't care that much about the layer one it needs to work uh-huh it needs to be secure because everything is only as secure as whatever your blockchain is but to us it's kind of a black box and so we just go up the verifier and it could be anything we're building on aetherium I love aetherium so you know that's that's what we're doing practically but in terms of like the abs the concepts are gonna be talking about this is just a black box the biggest the most important concept that we talked about is validators and and these are kind of layer two validators and validators in our system and the kind of the core of our system is that when you create a smart contract you specify a list of validators and those validators are the ones that are responsible for running that smart contracts and what our system does is it provides a really strong security guarantee that the system will run correctly if anyone any single one of those validators is honest and so you don't need that many validators to be able to assume this especially if they're known identity so let's say you have like ten validators that's most likely more than enough for your application for your users to be confident that they won't entirely clued that at least one of them will be honest and so now I'm just going to talk about an example of what are Bertram what using are Bertram looks like in practice and I'm gonna use the example of a two-player game let's say that Alice and Bob are playing a game of chess what do they do well the first thing they do is they write a solidity contract or they download a solidity contract they're probably not writing it themselves which is this chess game I mean what they do then is they load it up into a virtual machine into a layer to execution environment and so they both agree they essentially both come together they say hey we both agree that we're running this code and we're gonna commit to that and and they create this virtual machine which is essentially in smart contact world you can also call it a third party but it's but it's trustless there's no kind of actual person that's running the game it's just running all on the network and in this case Alice and Bob are actually running it themselves since they choose to just be the validators for this contract and if you're familiar with state channels this is essentially that they are participants in a state channel together and it's a very similar model to that and so they send back and they send moves back and they send moves to this to this kind of magic virtual machine it'll it'll validate their moves and it'll verify in the end of the game that the games actually been correct and payout to the winner and so you have kind of the end hire smart contract going on in layer two with no need to go to the base chain at all and and for our case and I'll dig into this more and this is kind of an inch of the biggest distinguishers of our of what we're doing there's no circumstance in which and in which this contract has to be on the main chain it exists entirely in kind of in between Alice and Bob no matter what happens so the thing to talk about now is so we have we have contracts or in this talk yeah you never really use the term VM because I like it better and they have a set of validators so then the question is what what are these validators doing what's the kind of what's the magic protocol that they're running in order to achieve the NHS property and achieve kind of achieved the things I'm talking about so validators first of all are incentivized to agree unanimously about what a vm will do because that's the easiest path forward because most of the time we're just gonna have the validators agreeing they're not gonna be in a fight they're not gonna nothing's gonna go wrong they're just gonna agree and and one thing you want is you want that fast path to be really fast because most of the time that's what's gonna happen and so what they do in this case is essentially we have a virtual machine and we say well currently the virtual machine machine is in this state so this is kind of the state of the channel between them and then if you execute the machine some it'll be in this after state and there gonna be some action so our machine is gonna is gonna send some money to someone on chain it's gonna do something it's gonna take some externally visible actions Alice and Bob both signed this and done confirmed and and with immediate finality with no need to wait and so you can get the feedback instantly that that these actions are going to occur which means that your UI can update immediately and you don't need to worry about security or a reorg or any of that stuff but what if they won't come to an agreement what if what if Alice and Bob just that something's gone wrong between them they're they're pissed at each other alice is trying to make bob's life hard or the around what can we do that if we can't get them both to sign the same thing and use this easy easy method and so for that we have this thing called disputable assertion which looks a lot like a unanimous assertion it's basically the same thing except only Bob signs it and so we haven't been able to actually get everybody involved to sign off but we have a way forward and so what Bob does is he broadcasts this assertion to the network and at that point a clock starts ticking there's our clock and and Alice can respond during that time if she wants to and she can say hey Bob's lying that's wrong if she doesn't respond within that time period once again it's going to be confirmed and so Bob can unilaterally move the move the state forward without having to kind of do without having to put the contract on chain without having to do any sort of major on chain operations except for some small transaction and so in this essentially what happens here is when you make this disputable assertion you're just you deposit some funds and if there's a challenge then one or the other person will have their funds slashed and so you're not gonna have challenges unless people are willing to shell out a lot of money for no reason and so the economic incentives here make it so that this should really not have to happen because people will be honest because they know that there's a guarantee that they'll get punished if they're not so how do we how do we handle these challenges so let's say there's a challenge and we had n steps of execution and we're trying to figure out was this true was this a lie without putting the whole contract on chain and unfortunately given time constraints I can't go into all the details of how this works but essentially what they do is they shrink the challenge down so there's currently a dispute over n steps and we narrow it down so then we get a dispute over n over two steps and then n over four steps and we shrink it down until we get a dispute over one step and that's kind of the smallest unit we can get to so we're disagreeing about like a really small thing and we want to settle that and so the question then is can we make the can we make that really cheap to resolve like do we have to like is can we prove one step without revealing a massive amount of data and so we have the arbitral machine architecture which is optimized for this purpose so that all one step proofs can be emulated in small constant time can be sent to the network in small constant size essentially everything's really cheap and so we can have guarantees that no matter what these conflicts will be cheap to resolve there are four kind of major principles and ways that we did this and kind of we always felt a little crazy going into this inventing our own VM architecture but it's really cool because it gives you like really strong guarantees about the about the gas cost of these disputes which in turn makes this makes the incentives of the system really easy to reason about and so we essentially did is we made it we made a machine architecture that's a Merkel tree and and you know there's there's some details into that but essentially opcodes work on this Merkel tree and they work near the roof so they don't need to go down to the leaves which means it's pretty cheap to reason about stuff near the root and so we're in a conventional architecture you have kind of flat memory and code and you probably need to do merkel proofs into those in order to like track what operation and what cell your reading in in the arbitral architecture through through a little bit of magic and I think I'm gonna I should have time to explain that a little bit we kind of get rid of the all these various logarithmic things that you'd otherwise have to put on the blockchain and so essentially we do kind of this this kind of magic transformation so instead of having memory in the classic sense we instead have these fixed size blocks called tuples and this will just be kind of a cell that contains a few values and so where normally you would have just like memory being emulated and you'd have this flat memory and then you'd probably merkel eyes it and build a tree instead that's all just done at the application layer or at the compiler layer and so instead of having a read instruction you instead have a read library call uses all of these sub operations and makes it efficient and so instead of having a memory read for instance be kind of log in in needing to trace of this tree you instead just have kind of log in little micro operations they each cost very little independently and so this one step is very cheap the other cool thing we get with with this technology is we get privacy and specifically the state of the VM is only revealed to that VMs validators and since unlike kind of normal state channels under no circumstances ever have to go to the blockchain you can guarantee that only these validators will ever need to know the state of that contract and all that'll be on chain is is salta Palash --is of the vm state and and kind of some metadata essentially about the execution of it but we have this strong guarantee that you don't need to put any of any kind of serious data on chain you can reveal it if you want to if you want to make it public you can but you don't have to compare to the regular box chain we're kind of it's part of the architecture that you have to make everything public and you can use crypto cryptography to fix that a little bit but it's kind of fundamental so we're companies in the middle of developing orbitrim it started out as a research paper now we're a company now we're building it we should have our initial alpha release out within the next few weeks there's a lot of various components of this system there's kind of all of the virtual machine related stuff so assembler runtime there is kind of this the honest validator code base that will essentially run this whole protocol in the background so that as a developer as user you don't need to think about any of this you want to be confident it works so it shouldn't be a total black box but you don't actually need to deal with this in practice and this is a layer 2 project building on top of the theory 'm and we have built in interoperability with the theory and so you can take all of your existing ERC 20 or c 7:21 tokens own them in orbitrim contracts do whatever you want send them back and forth and you can just take your existing solidity code run it through our compiler and deploy immediately onto our Bertram so you don't need a code for like a special framework you don't need fit into whatever kind of but into into our frame into what we're doing you just take your existing code and click a button and you can deploy so just kind of closing out our Bertram we can actually really achieve a lot of these scalability and and and with strong security properties that I talked about the beaming in the talk using this combination of protocol design incentive mechanisms and virtual machine architecture and we're also hiring so if this sounded cool we should definitely talk so thank you very much questions yeah there are a couple asterisks is there for sure so essentially there there are parts of the salute of solidity that we can't support so you can't support generic synchronous calls to on chain contracts because you're executing in this like little layer to world so you can't just like arbitrarily plug into the existing world but you can for instance support sending and receiving tokens you can support a lot of that most things so most state channel projects have kind of a framework you have to plug into we're not doing that so we do kind of take your take your existing truffle project install like our our provider and deploy into our Bertram and kind of assuming your contract doesn't use these unsupported features it is as simple as that any other questions or feel free to call me out and file [Music] yeah yeah no absolutely yeah see anybody else sir awesome all right well thank you guys for listening