 Hi everyone, I am from Perun off-chain labs 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 Warsaw, 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 Perun and Extensions where we try to build a framework for state channels The second one is called fair swap where we try 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 parent and extensions Smart order state channels is an extension of payment channels And most of you will have heard about payment channels and the ideas 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 a 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 used is the observation that we can run or we can put the 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 Alice and Ingrid 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 And this is really nice because for opening this channel We don't have to go on chain, but this completely happens off-chain We can also update this and close this off-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 end 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 a 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 a very naive solution is we just take a small contract buyer submits the coins Seller submits the money and then the contract verifies hash correct or hash incorrect But this is actually really expensive when we talk about large files about giga or megabytes So we propose a new protocol called fair swap 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-chain 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 splitting up the file in many small chunks and The hash that verifies its correctness is actually a merkle hash So the hash root of the merkle tree is Used to verify if the file is correct Or not correct So in this case we have a very nice scenario because Alice and Bob if they disagree about correctness of this can actually Limit the disagreement to a single element of this tree So either 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 then to verify and 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 the guarantee that if he gets a wrong file He can always generate a proof of misbehavior and it will always be accepted and Unfortunability 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 it can verify arbitrary programs 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 the same 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 fee 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 cheater 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 kid 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 while this piece of hardware is trusted the person that runs this 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 it 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. We're just quite common now in in cryptography and Try to run smart contracts inside This piece of hardware and what 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 parties and malicious operator We can uniquely attribute faults in case someone misbehaves and also this protocol is so simple that we can actually build it on Bitcoin Okay, so how does it work? We have this TE here and the operator and all of the parties So they want to play a poker game now, which means we load a poker game into this piece of hardware 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 locked 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 they 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 Ethereum Doesn't have right now and it's really hard to build in smart 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 the TE outputs a transaction saying okay here Alice and Charlie get all their 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 summarize over all of these three works is 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 satisfy Cryptographic security. So if you want to learn more about this feel free to talk to me here at DEF CON. Thank you