Grantee Exposé Lightning Talk 2 - Perun’s research on off-chain protocols by Lisa Eckey (Devcon5)
Devcon·Fri, Oct 9, 2020, 12:00 AM
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more. https://archive.devcon.org/archive/watch/5/grantee-expose-lightning-talk-2-peruns-research-on-off-chain-protocols Lisa Eckey presents Perun's research on off-chain protocols. Speaker(s): Lisa Eckey Skill level: Advanced Track: Developer Infrastructure Keywords: Scaling, scalability, state channels, exchange, privacy, security, technical Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum Learn more about devcon: https://www.devcon.org/ Learn more about ethereum: https://ethereum.org/ Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. Devcon 5 was held in Osaka, Japan on Oct 8 - 11, 2019. Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
Transcript
hi everyone i am from pier 1 of chain ups and i want to take this chance today to present what we've been working on in the last few years who we are we are two teams of applied cryptography researchers in Darmstadt Germany and vassal Poland and we provide cryptographic protocols and proofs but our focus our goal is how we can use smart contracts to scale blockchain in particular I want to present to you today three protocols that we've been working on the first one you might have heard about is called Piron and extensions where we try to build a framework for state channels the second one is called fair swap where we tried to build use smart contracts to build a fair exchange protocol and the last one is a very recent one called fast kitten where we use trusted execution environments to build secure private smart contract execution so let's start with the first one here on end extensions and smart or state channels is an extension of payment channels and most of you will have heard about payment channels and the idea is to get rid of this very long duration and costly single payments on the blockchain and encapsulate them into a channel which is secured by channel contract on chain and this allows to make off chain direct payments between two participants really fast without additional costs and our goal here is to take these existing payment channels and make them more powerful and we did this in three lines of works and the main component that we use to Staub servation that we can run or we can put contracts that we can put on chain also in state channels and not just one we can put multiple contracts into a state channel and this is a nice observation because if we can do this then we can also put a channel contract into a channel and this is really nice when we want to connect more than two players in this case for example we have Ellison English who have a channel and Ingrid and Bob who also have a channel and in both of these channels we now put a channel contract which opens a new virtual channel between Alice and Bob this is really nice because of opening this channel we don't have to go unchain but this completely happens off chain we can also update this at closest of chain and use it as much as we want again we can also open contracts inside the virtual channel as many as we want and the third extension that we very recently published is that we can also connect more than two people we can connect end parties by putting an end party contract into channels and this these M party channels also provide the same the same properties as a direct or a virtual Channel but enough about channels I have two more proposals to talk about the second one was fair swap and fair swap tackles the problem of fair exchange which is really hard to solve without a blockchain classical examples when you have a seller and a buyer and the seller has a file X and the buyer is willing to pay for this file but only if it's the right one which is here measured over his hash so very naive solution is we just take a contract buyer submits a coins seller submits the money and then the contract verifies has correct or has incorrect but this is actually really expensive when we talk about large files about bigger or megabytes so we propose a new protocol called phase one where we encrypt the file and not send it to the contract but directly send it to the buyer in the first message this is happening directly between seller and buyer so no on sharing communication the buyer cannot see the file at this point because it's encrypted and it's missing the key so it locks the coins which will make the seller submit the key and then the buyer can decrypt the file to actually look into it and verify if it's correct or not correct and in case it's not correct it sends a proof of misbehavior to the smart contract which the smart contract the the judge in this case will verify so the goal here is to keep this piece of information as small as possible ideally independent from the size of the overall file and how we did this is by exploiting up the file in many small chunks and the hash that verifies its correctness actually a local hash so the hash root of the local tree is used to verify if the file is correct or not correct so in this case we have a very nice scenario because Ellison bought if they disagree about correctness of this can actually limits the disagreement to a single element of this tree so in that the last element is wrong or a single evaluation of this hash tree is wrong and in this case they only have to send a single element a single chunk of the file which the judge has done to verify this can be done really cheaply we measured it around half a year ago where it was like two dollars independent from the file size so you could send an arbitrary large file and this complaint was taking a constant amount of fees and we also evaluate the security this is something that we take a lot of effort in formally modeling and verifying security of our protocols in this case we ensure that it's fair so atomic exchange of payment and file we also want to make sure that it's sound so the buyer has to guarantee that if he gets a wrong file you can always generate a proof of misbehavior and it will always be accepted and the unfortunate EE property is really important such that the buyer cannot come up with a wrong proof of misbehavior claiming the buyer misbehaved even though he didn't and we prove all of these properties formally in the paper we also worked on some extensions of this the most important one is that I was basically only explaining one example with the file and the hash this also works for generic witnesses and circuits so it's very powerful can use arbitrary programs or can verify arbitrary programs and we also have interactive and a non interactive version of this dispute of the proof of misbehavior and the non interactive is nice because we have as soon as we have five interactions with the contract and that's it and the interactive dispute has many more interactions with the contract but we have three fairness so we have the guarantee that all of these transaction fees that have to be paid for the dispute will only be carried by the teacher by the cheating party so an honest party doesn't really care how long it takes or how expensive it is it will always get reimbursed now to the last of three things that I wanted to present today which is called fast get in fast kitten we use a building block which is called a trusted execution environment te or trusted Hardware where this piece of hardware is trusted to run the code we give it and no one can influence this this execution but of course why this piece of hardware has trusted the person that runs it is not trusted so we have this operator who is in charge of giving feeding information to the TE and forwarding its output so it can stop the te you can stop forwarding its messages but it can never lie about the computation inside the te and it cannot influence the computation so we use this building block which is quite common now in in cryptography and try to run smart contracts inside this piece of hardware and we get from this is actually a really powerful protocol because we can run a contract independent of size of chain we have very high guarantees we can protect against malicious mock parties and malicious operator we can uniquely actually be at fault in case someone misbehaves and also this protocol is so simple we can actually build it on Bitcoin okay so how does it work we have this T here in the operator and all of the parties so they want to play a poker game now which means we load the poker game into this piece of card where the parties attest this te so they know that this is actually trusted hardware and this is actually running the right code and then the operator deposits a security penalty deposit and all of the parties lock the coins for the game then we start and at this point we don't need the blockchain we just run everything off chain so the parties send their inputs to the TE but I actually do it in an encrypted way so the operator cannot see the inputs and the TE also sends an encrypted output back to the parties so the operator has no idea of what's actually happening and also the parties don't see each other's inputs this is also a nice feature with a theorem doesn't have right now and it's really hard to build its my contracts but it's given for free in this setup so now the parties can actually see who won and get their money back from the TE which means that he outputs a transaction saying okay here Alessio Charlie get other coins of course we still have to protect against all this power that the operator has so in case it misbehaves we actually have to wait for a certain time out and then the parties get refunded their money but the operator lost his security deposit which is well really painful for him so to summarise over all of these three works is a very interesting observation that smart contracts are really powerful tools that we can use to ensure security and that can also use to build more scalable protocols and our goal here is to really provide cryptographic models and proofs with all of these protocols and really show that they satisfied cryptographic security so if you want to learn more about this feel free to talk to me here at DEFCON thank you [Applause] you
Automatic transcript — names and jargon may be misspelled.