EthCC 2: Johann Barbie

we are online so 25 slides 25 minutes about plasma in the wild my name is Johan and I work on this project that is called leap down and we've been building more VP more viable plasma dialects over quite a long time it feels and I wanna in this talk I want to share with you where we got and how it feels like to run it but first I guess I need you to wake you up a little bit so a show of hands who knows plasma or kind of yeah just raise your hand who would be kind of able to explain the difference between let's say plasma cash and plasma prime 0 hands okay oh one guy cool that was half half about yeah let's let's get going so I'll talk a bit about who so who are these leap peeps and then what so I'll give you a short rehearsal of plasma how how did it go to launch it on main net that's what we've done beginning of February and why why did we do that so where are we going with this why another plasma so yeah let's go so we started as kind of a bunch of game developers that really wanted to do something awesome on the theorem and we noticed that despite state channels and like all these kind of things it was super hard to to build decent games and somehow through talking to the theorem foundation and trying to do plasma research and all this kind of stuff we ended up where we are and instead of just being these freelance opportunists that we were at the beginning we kind of evolved into something that I'm standing as standing on the wrong corner here's better so we developed into this like community and we we got some values and stuff so those are mostly like you know running code we don't have any hierarchies there is no employment contracts we don't even know the names of some of the members and we try to achieve kind of rough consensus no hard governance hopefully no hard feelings we had some disputes though along the way and we don't I mean I don't know what that means like market camp but if there is a a sort of value to the project then we want to value the community over the value of the project in any decision on this is kind of where we are located every now and then I think these are locations from github or something like that so they might not be accurate but it's round about five to ten guys that care about it and this is kind of our HR everything board so we just kind of operate on github issues and they you can propose bounties you can earn bounties and there is nothing else than that okay so the question was because I was no microphone if we're actively developing and more VP or if we're just applying changes I'll come to that later but basically we've we've taken the more VP dialect and we've applied to it what the results of our research paper so our objective is to get computation on two layer two so just do more than simple transfers so we have not extended the more VP dialect with any specific attributes except those that are needed to run computation so these the assumptions of the exit game or more viable plasma and they stay the same we haven't modified those okay so I'll go through there should be a plasma ball but it's not showing up just a few pixels yeah I'll go through a rehearsal with you guys so you kind of know a little bit how the whole plasma works so I can talk about the other things so this is kind of my mind map of scalability it's a bit outdated but the blue thing is etherium and you can do different things like Kaspar and charting and if you're in 2.0 and so on to improve the scalability here but it will only be something something X and of course you can run other chains and bridge to them but you always start with like a pretty low economic security and you can do things that are like crypto economic games on top of layer 1 which is state channels plasma and plasma cash so if these two guys Alice and Bob on the top right they want to send a million transactions to each other they can give it to the guy with a candle and pay probably a few thousand dollars or they can give it to this slightly less serious looking guy the plasma operator and that guy will go ahead and hash it all together and then only commit 32 bytes into the theorem chain sorry what he will actually do he will put a number on it as well so you can kind of identify that and put it into the plasma contract and what does that give us so that gives us the ability to do proofs about the data structure so with a myrtle tree you have the proof of inclusion and if you do two proofs of inclusion for example of transaction 1 and transaction 2 and the inputs in the u TXO sense of inputs if these two inputs point to the same output then obviously this is a double spend and what do you gain from like proving a double spend well you make this plasma operator a restricted Authority so let's say he put down a stake before he became the plasma operator then this can be a proof of slashing him so now why is that more effective than you know just submitting the whole block well because these proofs are way more efficient than posting the whole block and yeah the contract can then take the transaction and parse it and make conclusions base of the transaction so beginning of february 2nd of february we took what we've developed and we've put it on the main net and that's the the part of the biggest part of this talk is just kind of letting you guys know which experience we collected what were the difficulties and so on so let's go first you need to know how we kind of structure these commits to a theorem so the plasma chain does runs on 10 demand and it does two to four ii blocks and then 32 of these blocks are taken and they are hashed together again in the Merkle tree into what we call a period and then these period is so the Merkel route of that period is submitted to the theorem chain so you can kind of conclude from this diagram that that would happen every one to two minutes so our theoretical capacity using that design I'm stressing theoretical is four thousand transactions per block one hundred twenty eight thousand transactions per period and then there's a configure there's a governance parameter that says that the distance between two periods should be at least at least six main net blocks so that's the period distance here one point five minutes above so with that we could do a thousand four hundred transactions per second cool what have we actually done well done zero point five transactions per block about six inch transactions per period and the average distance was about one hundred and five fifty room blocks so every 33 minutes in February on average that has been a period and that gives you zero point zero zero eight transactions per second so here is something that comes out of the tenement repository someone did a load test on it and on tenement nodes and it turns out that if you stress them with a little more than a thousand two hundred transactions per second their capacity actually decreases down to something at like 200 transactions per second at six thousand transactions load so let's take this point let's take like the theoretical capacity as I said was thousand something transactions but let's just take these two hundred so this is what we've actually measured so the period submission cost eighty two thousand gas and an average gas cost during that month was five point three gigabyte pretty cheap we've done the thousand one hundred periods and we've paid about seventy two dollars in that time well what does that give us a little bit more math so on the main net if you send a single transaction let's just say it's a transfer 21,000 gasps let's assume a pretty high gas cost of 20 gig away and the ether price of $130 you end up with 5.5 cents correct me if I'm wrong and then this is what we've achieved now on the plasma chain just doing super transfers is 16 transactions per period as I said and then submitting that takes 82,000 gas and we end up at one point 3 cents per plasma transaction so we've kind of done the 4x increase even with like the very shitty shitty load that we have and now let's remember these 200 transactions that have shown you in the load measurement and if so if we would run if it would max out our capacity to that then that woulda would end up at a cost of 0.001 2 cents per transaction so being on plasma you're kind of a little bit cheaper than on the minute already and there is a lot of room for improvement but you need to kind of you know they need to be enough transaction to do this stuff so prove all this math transactions per second who cares about transfers right so it's cool to measure these things but TPS is not really like how do you say the most important thing that we care about we exist because we wanna we want to bring decentralized apps to layer 2 so it's cool to roll up transactions and to process a lot of them but with the theorem we all kind of have this dream of doing more than just transfers right so certification mediation of trust all these kind of things and so last year with the with the help of our firstly theorem grant we came up with with this design that we call plasma leap and the idea is basically to yeah to allow apps to kind of take this leap onto layer 2 and then they would become plasma amps or claps and we wear these with this and there is like difficulties in doing that but we think as on the main developers need kind of stateful programming model to be able to develop these applications and in the next few slides I want to kind of take you through the difficulties that there are and how it's still possible to develop apps that run on layer 2 cool so the first thing that we did is go back to Bitcoin and look at page of script hash because that's how scripting or computation is done on Bitcoin and if you remember and let let me see if I get that right you take your redeem script and then you hash that and then you send funds to it and it's redeemable if anyone is able to bring the redeem script that hashes to the hash that holds the funds and some data that evaluates the redeem script to true and the data usually contains the witness so the signatures over the data and yeah so we've modeled off of that and we call these things spending conditions because coins are locked under these scripts and you can release them by kind of bringing the contract and bringing the data that evaluates the contract to true Bitcoin doesn't have any state so you can't store anything between one page of script hash and another what and then use it in the next page of script hash and yeah I'll talk about that on the next slide so here's such a spending condition example this is written in solidity it could be written in VIPRE you have a bunch of constants so there's this vendor address the guy that is able to claim from this and then there is just a simple function fulfill and that takes the witness so a signature and then it also takes some instructions like which token to send and where to send it to and the scriptures you know recovers the signer from the signature make sure that that matches the constant that is saved in it and then it initializes an ER C 20 and tries a transfer and if all that passes then the spending condition has been fulfilled and a u TX o that has been holding funds under this spending condition is spent on the plasma chain and the funds are transferred so how do you actually make sure that all this happens correctly because we are not running on chain and we don't know if the operator of this plasma chain remember this untrustworthy orange guy if he actually is doing what he's supposed to do right so we are developing a component that is called solely BM solidity a VM and it's an implementation of the EVM inside of the EVM and this component is there not to execute the full spending condition because you know because it's kind of emulated it would be way more expensive and we would be limited to way less gas than we are on the main net what it does it it plays an interactive game with the solver and the Challenger and then it only executes one opcode on chain so this is very similar to what Ruby does with represent lis except that we use this for EVM bytecode so you can write your contracts in any EVM language and here's a simple example so let's say I have a computation and I roll it out over all the opcodes so the first opcode is you know initializing the contract and the last opcode is a return or throw whatever it might be right then we have all these steps um and at each of these steps I hash the state of the VM and that means I take the memory and hash it together take the stack and hash it together I take all the environment variables and hash it together then I hash all that together and then I get 32 bytes that represent the state of the VM at each of these steps and then the interactive game between the solver and the Challenger starts and they kind of start and ask each other on chain what is your state of the VM at step 7 and then they notice oh it's the same so we must disagree somewhere in the second half of the execution and then they do this binary search until they end up with two consecutive steps so one after the other where they agree on the first one but they disagree on the second one and this is where the EVM in the EVM steps in and either one of them initializes the EVM the EVM makes sure that after hashing itself it matches the hash that is in this in this example step 12 and then it executes that one opcode and it sees who of the of these two guys was right in their claim of what the next step of execution is and with this interactive game we can make sure that yeah that the computation or that computation that the plasma operator uses to for example challenge exits that this computation has been executed correctly lots of time cool yeah let's go so we don't have a stateful computing model yet right what do I mean by stateful so just the fact that you know I can use the storage of the contract so you can just go to the top of your contract and you can say like I I don't know define a variable and change it later in another transaction right so unfortunately state makes the exit game of plasmas so much more complex and we can't use it so our smart contracts can just be like static script and now you say like oh I can't really use that because I want to build state machines right I want to represent something that will do something else in a later transaction and this was where we come up with an extension of fungible tokens an extension of the ERC seven to one because the plasma chain can manage two types of assets the fungible tokens you know that I use for transfers and gas and whatnot and non fungible tokens so we just bring in a non fungible token and we extend it with with a 32 bytes data record so imagine this as just changing the color of your crypto kitty and in the color of the crypto kitty you can now encode all kind of stuff so always the current owner of these of this NFT can change the data the yeah the storage route and you would say like yeah well but I'm limited to 32 bytes how is this any useful for me so but you're not actually you can do what is called state minimize storage I think we could use that for if you're in one point X quite nicely as well and here is an example of using patrícia tree to kind of store more data in your token than just these 32 bytes so you have a verify function here which obviously takes a token ID and it takes a key and a value and branch mask and siblings as well and with this data we can prove that the current route includes a value and at the key and in this Patricia tree that is stored and in the non fungible storage non fungible storage token yeah so we verify the proof and then we just return true so you have to bring your own data but you can verify during the execution that it is actually contained for reading or you can bring it update proof as well which is not included in this example but if you check out our sala vm and spending conditions repositories you'll find it there so finally let's put it all together on the left side you see two squares which are outputs of previous transactions and then the four squares on the right are together a transaction with two inputs and two outputs and the first input contains the spending condition that is for example reading from a storage token and the second input it just points through the storage token that I want to read this is kind of how we translate the UTX o model into the execution environment of your spending condition and here as you've seen before you can just use the ERC 20 or c72 1 interfaces to talk to assets and storage and all this stuff that is around on the chain and your contract is written in a way that let's say there is a problem with the clasp my chain doesn't continue or your user is just not happy with it and he decides that it should be exited or you want to run your app on a faster chain then you can exit your contract so that means you deploy it on the main net then you call the plasma exit functions which will first exit the storage token exit the assets that were in your contract and then you have everything on if you remain to continue running that contract to invoking it again and I don't know transferring it into another plasma chain we're just paying your users out or something like that so yeah that's it already so check out our website there is Docs there's the test net where you can run these spending conditions already so we have these spending conditions on the test net not yet on the main net on the main net you can for now just run simple transfers the moment that we got Saleh VM completed we will also launch these spend conditions on the main net and then there will be fully enforced for this interactive game that I've shown you and or write me an email right there at the bottom with questions that you can also ask now can you open the slide with the peda script hash solid a diversion I mean this one yeah what's the sort of okay so so there's like an output that has the hash of the script yes and is this this is this is the script so you take the script you hash it and you you you hash it first thing then you do a ripened D 160 on it so you got 20 bytes right it looks like an address and then you just send money to that address that's how you deploy a contract all right so so is it now kind of like this is the script that has been hashed before and now it's comparing the hash of this script and checking that that's kind of correct because I mean in some sense when you recover the signer yeah it could be just anyone who's fine that's creepy yeah what we do here it's a little confusing because it's not really like commented but you see how we try to recover the code hash from the address of this script so the execution environment of the smart contract on the plasma chain we inject the Sig hash of the transaction as this like as the address that you get when you would read this on the main net right so what happens is that you actually you sign over the hash of the transaction and then that gets injected into the contract and the contract can verify against its own hash that that that you know the right person has signed it sure but I mean in some sense suppose somebody you know sent the code hash right it's not the code hash in this situation though it's this sick hash of the transaction so it's a hash over all inputs all outputs and because it hashes over the inputs that also hashes over the transactions that will be spent that we have on the chain before so it's acts as a nuns in this situation like yeah I mean what I was just thinking that can I know like get that bytecode sign it myself and then sort of like kind of become designer in that thing because I mean then it would recover my signature yeah but we have we've we have the address of the supposed spender hashed into this contract right so yeah that that would be hard for you yeah more questions cool thanks guys Cavanaugh's questions [Applause]