Georgios Konstantopoulos ~ Plasma Cash: Towards improved Constructions Loom Network

[Music] okay so thank you for coming my name is Drew juice I will talk about plasma which is a scalability solution and my work is my current affiliation is with loom network a company which builds games which are built on scalable infrastructure so what is the problem we have some issues on Bitcoin with the current state it's one megabyte blocks even with cebu it we cannot get above like seven maybe ten transactions per second for aetherium when you do 21,000 gas transactions with our single value transfers you can maybe get like 28 transaction per second but if you want to do more complex transitions which are which is what's interesting there are three foot drops and I should say that these two slides are taken from patty McCrory from King's College so we have this problem where we they wanted to be decentralized and we also wanted to be verifiable by the public and the problem exists that if you have too many users you can also have a large set of validators so what can you do about this either first well first ways that you can go with a centralized approach which we really do not want the other approach is to go for alternative infrastructures which so far I don't think any has proven its value other approaches such as the one that a three-room 2.0 and other chains are taking is to shard so you have a main chain you have multiple chains and each shard that essentially has your throughput increases linearly with the amount of shirts and then we have the off chain approach where you essentially you take the state out and you try to design it so that even if something goes wrong of chain you can always go back to the original main chain to go to court and solve the dispute and I will talk about plasma which is essentially a framework for creating what we call non-custodial side chains so but let's talk about it firstly what is a side chain and what's their interests in it so imagine that you have two chains the parent chain and the plasma chain or the side chain what happens is that you lock your funds in an escrow contract it can be a multi-sig if you do it in Bitcoin or it sounds contract on material and what happens is that the plasma chain which is aware of what's happening on the main chain it creates some acids when it creates these assets you are basically able to transact with it and the whole idea the whole idea is that any transfers that you make on the plasma chain or the side chain they're very very fast because you essentially have like a more LSP centerline set up and when you want to withdraw your assets you do what we call in a and exit or you can burn the asset and basically what happens is that after if you blocks the asset that you had locked origionally it gets unlocked so inside chain terms this is called the two-way peg that and the logic is that you lock in the main chain you mint on the side chain you burn on the side chain and you unlock on the parent chain and basically there is one problem with this that if you want to do scalability I will claim that there is this trade-off between scalability and security which might not have any possibility result but it may as well be so what we want to do is that when you start centralizing the chain to make it more scalable you have the danger that if the sidechain manager essentially the data set of the sidechain does not want you to make the exit the withdrawal because they're censoring you you're not able to do it you're not able to get your fans out so tentatively what we do in plasma is what we say okay we will commit the state of the sidechain to the parent chain all the time so what happens that essentially each plasma block gets committed to the parent chain and then you buy some database manager which we call the operator usually for convenience and basically what you have is essentially a sidechain which is controlled by one party which commits all its state or metal roots of its state updates to the parent chain and what we do is that we design a thing called and exit game so when you start when you want to withdraw instead of allowing instant withdrawals what we do is that we have we need to do some delay and the delay is done so that if you for some reason try to make an invalid withdrawal attempt some other party will come and show up and they will say no you're your attestation is invalid and they will challenge and your challenge exit will get cancelled but if there is no challenge on the exit after you wait some challenge period t which is a security parameter of the system there you can finally you're exiting you can take your funds out of the plasma chain the notion here of somebody challenging it it introduces aliveness assumption so there must be people watching so this is like a thing to take into account well this is common in all layer two solution so even in lighting network in any kind of state tunnel network or plasma you always need to have some parties which watch within this challenge period because if nobody challenges during this period yes fraud can happen specifically my focus is on the violent of plasma and there have been many many variants of plasma cold plasma cash and the whole notion of it is that just like cash when you deposit it let's say five ether on the smart contract on the side chain you get a five-year bill and much like gas it has a serial number and you cannot split it so this means that if I have a five ether bill and I want to give it to Ben I need to give him the whole bill I cannot split it in any way because if I split it like in real world light you cannot split a coin and so this introduces an issue with fungibility but we assume that we use non fungible transactions and what you want to transact when you want to send your coin to someone else you need to refer to the block that you received it and the parent look and I will explain why you need that and similar to and when you want to withdraw your funds you also need to reveal two transactions the transaction in which you got the coin and the parent earns action and this is part of the exit game so what can happen before I can get to that like let me just say that the metal gives actually uses particle tree and thanks to Kelvin for making this graph basically this part metal tree is in order to Merkle tree where each leaf so if I have the coin with ID 10 it's the tenth leaf in the metal tree and this it allows us to do inclusion proofs just like all Merkle trees you just provide like log em hashes which show that your element was part of the medical tree but it also has this nice property that you can do exclusion improves which by exclusion proves you can you basically say that nothing was included there so an exclusion proof of coin 10 is that showing that at the IND extent there was nothing there while an inclusion proof is showing that there was some transaction there so now we'll talk about how Danvers exits and challenges work so let's take in a simple example so we have like Alice the usual suspect she deposits 5v3 on the plasma contract and she gets like a five if they're NFP as we say like on the plasma chain from nowhere and now she has it in block one let's say so I plug two she makes transfer to Bob let's say and when Bob gets the coin he must verify since the coins deposit that the coin has valid history what does this mean that it has valid the inclusion proves there have been no double spending it's it's very and so on and yes the plasma change has a uth so model it's not like a theorem where you have account you got coins each one with its own you TXO historian you need to verify that so let's say that block three comes like the coin just moved so we don't care by block before like when Bob sends it going to Charlie she not only does Charlie have to check the coin that it was spent in block one and two he must also verify that it was not spent in block three because clearly if there was a spend in block three the coin was double spent and we do not want that and this introduces a main thing about the receiver of a coin that they need to verify the coins history and this can have like non insignificant bandwidth requirements because you need to download the proofs from somewhere and when I say verify con history it means that you download all the metal proofs that prove inclusion and exclusion in your coin and then if you want to actually he just like verified he just points at there when he is everyday in the parent and now I will do like some like very basic graph like about how like the life line of the coin is so when you deposit it the coin is like at the state Q a you wanna make an exit and if everything goes well like you you exit your coin it goes into the next state seven days pass let that be the challenge field then you can finalize the exit and then you get with the other coin so that's a happy case but then if you have a non-interactive challenge and I will talk about how it's challenge works later if I make an exit and within that time frame some of the challenges my exit gets cancelled it's gone it's again to the initial stage in the interactive challenge case what happens is that you have like a counter which essentially counts how many interactive challenges the coin has and in order to finalize an exit for a coin must have 0 interactive challenges so if 7 days pass and nobody responds somebody can call again finalize the exit or final as the challenge and the coin cannot is no longer being exited if somebody responds even to all challenges very explicitly all challenges then you're back in the happy case so let's talk about how it's challenge worked so we have Alice again who has some coin that she received in the past she has verified the history she spends it and then immediately after spending it she goes to the parent chain and she calls exit and when she starts the exit they plasma contract it's not aware of the side chain full state it cannot know that the coin was spent what it knows that there was some commitment later so what Bob simply done that he goes to chain and he shows no this coin was spent and exit is canceled so that's the first one it's pretty straightforward the other approach is that Alice sends the coin Bob and Alice in a later block she'd double spend so she has a coin that she has already spent inside it again to Charlie and if Charlie wants to exit she basically is trying to exit the ample spend and in order to cancel and exit of a double spend you reveal an earlier spend from the exit and there let's spend it must be between the exit and the path a vexing block and the parent block so in this case this is the exiting block and this is the parent load and you challenge by showing a challenge between and in the implementations we call this challenge after traveled between and challenged before because what can happen is that we cannot have trust assumptions about this database manager the operator and what makes it very will happen is that the operator makes an invalid state transition by invalid state transition I mean that Alice is normally the last viola the owner of the coin but for some reason the operator gives the coin to Bob in their own database what happens that named Bob transact with it and let's assume that Bob Charlie and eland they're all friends and they want to take Alice's coin and if they were honest parties they would verify the coin history they would say that there is no spam from Alice to Bob unable to reject the coin so when Dylan exits Alice can do she can basically claim that she's the latest owner of the coin and if there is no response to that so this is the interactive challenge she she basically cancels the exit but if in fact like the wall spent from Alice to Bob then Bob or basically anyone else they can respond to the challenge of invalid history and this will pick em in the counter for the challenges and then the exit can go through so these are the three types of challenges so why is the secure is this secure and let's say and will people do it so firstly the assumption as I said is that somebody is able to make a challenge so when somebody starts an exudate I know d0 there is like time T until the X it can be finalized so this means that somebody must be able to get their exit transaction included in a block so let's say that some time passes I hate T want somebody broadcast the challenge it is the case that a miner could censor the challenged transaction and for example if t1 was later so if a miner is able to sense of the transaction for long enough then the attack will succeed because there is a challenge doesn't get included in time so somebody must watch and they must have they must be able to include their challenge transaction in time there is some safety condition that we're going to uphold for this and we have done some a lot of work on like making sure that an attacker will never like do this so what happens that when you exit not only do you pay like the gas ghost you also put up a security bond so you say I I put up one ether and I say that if somebody is able to challenge my exit i forfeit that it's like you put skin in the game in this thing so if there is no challenge that is successful and the attacker gets back you know and he just have to pay their gas cost but if the attack fails and some of the challenges they attack here we assume that this is a powerful adversary they can also go for a front run what is the front rounds essentially I make a transaction so attacker exits someone challenges and then what the attacker wants to do is that they want to front run the challenge they are gonna challenge themselves why do they want to do that because the bond that they are that they pay initially it goes to the challenge so if they are able to challenge themselves let's get the bond back and the cost to attack is significantly reduced so what we do to save that is that we essentially we only refund the part of the bond and you can know you can send the rest of the bond to try it in so like you can save 0.6 it's out of one we go to charity or just burn it send it to zero X zero and yeah I will skip this like without like some like the expected reward of the attacker in this in this scenario it must always be less than zero so basically what you do is that you parameterize the challenge period and the bond so that an attacker will know will never basically decide to attack because they expected reward is less than zero and so far so good but like what can we do like to get better so as I said like the plasma cash it has non fungible coins so this means that you cannot make arbitrary denomination payments so I have to either if I want to make a seven ether payment they have at any third coin or in my example you need to get some change in return and want to get this change in return you need to have like some notion of atomic transaction so that the operator includes a transaction that sends you seven if but also includes another transaction which you receive that you send seven it and you receive to it so you need a construction that is able to do that another approach for arbitrary denomination payments is that you essentially create each coin essentially becomes a payment channel between the user and the operator if you have like a five ether coin and another user it has a 3/3 coin you have capacities instead of values so the five ether coin it can have any value from zero to five and the other one the same so what you can do is that you reduce your coin by some amount so FIV third coin becomes three out of five and you have another coin which is let's say one out of three and you increase it to three out of three so you didn't need to do this atomic transaction which it uses one and in increases and the other approach to arbitrary denomination payment instead of five ether coin you get 100 coins 0.50 each one being 0.05 Eve and essentially instead of having built you have changed and there is a team that were you can this plasma group and they will be around so if you want like you can may hack or work with them right and I have an implementation of this but the thing is that this made this has like more complexity than the previous conceptions another problem is that we want to reduce data requirements even more because when I receive a coin I need to validate the coin ski story which means that if one year has passed and nobody has transacted with the coin I basically need to unload one year's worth of exclusion proofs which if you like commit often to the chain this can be maybe like one or two gigabytes which it may sound or may not sound big but for like clients which are on your mobile you cannot assume that you will have like two gigabytes for each coin and the solution to this are either you checkpoint so essentially you say that every 10,000 blocks this is the latest valid state and nobody can challenge with an earlier one and so you only need to verify the state up to the latest checkpoint the other thing that you can do is that basically instead of committing pair 15 seconds you can commit per minute which reduces the amount of data by four or any amount you want but this has an impact on finality because your transaction doesn't get confirmed fast enough other approaches which are more like with Monmouth as they call it like it's either with some snark or start a transaction which if I'm not mistaken there was an implementation at its Singapore that did plasma cash history compaction with zero knowledge snarks and all with RSA accumulators which was a very widely discussed mathematical topic like in the last few months for the plasma community finally this is a UT EXO chain that can only do payments so what if we could do like smart contracts on plasma so there are some approaches to this some users are doing EVM inside the VM during the verification but it's not exactly clear how this works so this I believe project doing that here is leap down so you may also want to talk to them about this but the approach that I prefer for this it's like if we could do state channels on plasma so essentially you would fund the channel with a plasma coin and you would settle the transaction to plasma and this has the benefit that you can do smart contracts on the plasma chain with these lines you can do for and for the payment channel you have this very nice property that you're the funding transaction of the channel in the settlement it still costs no fees so you're essentially not at layer 3 but you have like two layer two solutions interacting with each other and in order to do this you basically need to have a multisig account on the planet chain and some time lock so either with a hash time lock contract or something similar and this is ongoing work so let me just summarize what I just said so plasma is a noncustodial sidechain where you commit the blocks to the parent chain and some people have started calling this commit change which is a nice time to avoid the confusion it allows you to do gasless payments without annual board or boarding calls which is a huge advantage over channels because in channels we need to create the transaction on chain to participate a very very nice way to think about it is simply a compression mechanism instead of putting all data on chains just put 32 bytes per block it has the liveness requirement that the user is every challenge period one you need one honest party that's it like if you have one on a spot you can do that and many things have been built on with one honest party assumption say for example the sapling update for the cache so we can say that this is like n ok assumption for liveness and the current work in progress is to do smart contracts via channels arbitrate denomination payments with the ways that I proposed or even lighter light clients and thank you for your attention and I really technical document that explains how this thing works and I also have all the code open source so you can look at it and thank you very much for your attention and happy to take any questions on the topic I'm just kind of worried about your perspective on the distribution of like layer 2 solutions and how you think this all pan out do you see because like channels like this and plasma are very capital like intensive like you are committing to locking up resources into and like into this so just kind of wondering like do you think like they'll be some like database where like things are like minted on chain and you'll just use a database and it's held centrally somewhere like an exchange do you see like people using plasma do you see like a mix or how do you see like is the question about interoperability of obtain portables yeah and just like the distribution do you think it's gonna be like primarily one so I'm not sure I get the question like it is possible to have like can you like it maybe rephrase the question it's not clear to me how do you see layer 2 panning out and okay plasma is not like it's not like I don't think there's one winner like so there is it like one thing that I've been talking about lately that in Bitcoin you have lightning Network it's a it's one network that can accrue all the value and you have like people building on lightning on my film like and all other like chains you have like multiple layer two protocols and it's starting to get hard to figure out which one will accrue all the network effects for that so in the repair interoperability is a good thing to have but eventually thing will get to a state where you will have like either one large plasma chain or you will have a generalized state channels framework like under factual for example I'm not sure if I answer the question though yeah okay thank you very much and we'll have them from me on the signal