zkSummit - ZK0x02 - Private Transactions on Ethereum - Jack Fransham (Parity)

Transcript

oh yeah hey guys I'm Jeff from tannerite we made many different things so things I'm going to talk about today is private transactions on the ethereum blockchain public blockchain and sort of the secret store which is the technology underlying that so yeah first things first like what what's the motivation for private transactions on aetherium I mean one of the benefits of ethereum is that it's permissionless but

i don't say that yeah it's and also the public so everyone can see that that is a selling point you could argue yeah so yeah racialist means anyone can submit a transaction and public means anyone can be the transaction bigger company is for small enterprises put it cases and just put I mean it so there are other reasons to have privacy but but this the private transactions that we implement are more so vendor enterprise I'll get into exactly why it's not so useful for the sort of like the C cash send money to sketchy people on the internet kind of

use case yeah we want to put this on they feel important rather than having on custom blockchain for all the reasons that people like having aetherium you know it's got many validators so yeah we have as Souness seem I saw which you're lying Appeals this is sort of better yeah it's it's it's a federated encryption scheme so no one person has the entire key it's exactly how that works later and yeah private

transactions which are sort of this is wrong I wrote this yesterday very quickly after landing from the u.s. actually transactions on the probably I'm watching where the the result isn't it's encrypted that's nice don't don't read up and yeah so you want to validate the the state changes in the transaction or if you want to submit a transaction you have to sort of submit it to the secret store and then the secret store checks whether or not you have permissions the Dunas so the reason

yeah so yeah the seeker store so it's yeah as I said it's better if it's mmm so I'll explain exactly how that works if you want to ask me questions its I can't give any exact details but I can give you a sort of example of how exactly that works but suffice to say that there's some number of nodes m and you need at least n of those to sign off on you encrypting something or decrypting something in order to decrypt it and this is sort of enforced mathematically and you get a new key every time you wanna prove something you

don't just have like monkey this is quite important because otherwise yeah you could just decrypt anything with what would send key and do destroy the sort of Federation and the permissioning is done on chain which which means you have like a small contract which takes it has one fortune it takes whether the document ID and the address and then just returns true or false whether or not that person is allowed to decrypt this it's quite coarse grained you you really you you it's like it's symmetrical which means that you can't allow someone to encrypt but not decrypt which for example you can't do with

public key cryptography it's it's the permissioning in secret sauce is very coarse-grained is mostly like as I said for folk enterprises cases so like where you don't want just anyone to do it but like within this organization it's generally okay for like most people to read and write it so yeah if you want to encrypt a theme or sign a thing with secret store which I'll get to exactly why you've got to do

this and why it's useful further for the private transactions you first generate a document ID which is like a hash of the document normally I mean it can be what you can just be like it's the same word for every document if you like let's just get up it'll be very useful normal it's a hash of the document and then you sign it with the key pair of your account which is yeah yeah you sound like eBay okay you are sorry I've validated these with like whether or not you send this your local node or whether you send this to like the one of this secret store nodes in my particular secret store instance it doesn't really matter which one you send it to because

they all sort of have to it you have to have like some n number of them anyway so you look like the way that we recommend to set it up is to have just one of them that has like an HTTP API that you can connect to if you want to generate your peas and whatever but yeah that one can just communicate using the normal paper secret or communication methods otherwise yeah but I couldn't application you only have one that runs the actual application level server so you generate the key generator on the remote path that is unique for each document and it is unique for each

account we you've signed it with as well the reason for Iron Man 4 and then you use this key to generate local P and then you encrypt that document with it and then you send the local key and the document ID signed back to the road and then it like associates this so that other people can retrieve it later so yeah decryption if so saying you've associated all this key with and with undersigned up another you with so you do I said it with the key with doctrine

ID then you send the encrypted document to someone else and they want to deep Reptar so first the Decrypter signs document ID to make sure that it's then requesting it because yeah it's its permission done like a per count basis you need to make sure the person who's requesting it it's you can't just like say it's any address and then that would you could like say the address of someone who does the permissions when you personally the person sending it doesn't have permissions so you have to sign nothing ready you request the decryption keys from the remote which yeah but this is where the mission comes in so each of

the each of the secret store nodes will call in to the contract and check whether or not that dr. muddy and address can is allowed to decrypt and then it's pretty simple it's not like super fancy zero-knowledge stuff the real like use useful stuff is it's in the enema end of my property so yeah probably transactions were to go on top of this I mean I think that the private transaction is a bit of a misleading term I mean it's really a private contract but technically like all the execution that's done in a

contract is done as part a transaction each transaction is a state-transition and the only time that code in the in a convert run is in a transaction so that's why we use this terminology but I think it might be a little bit confusing so yeah so the code and the state in the contracts of both encrypted I'm going to be decrypted by a certain secret store instance you don't really own you like not anyone not just anyone can validate the the state transitions only validators that also have access to the secret store can validate state transitions so you have this like wrapper contract really likely the the

only things wrapper contract does is like accepts a state transition you want to do you want to apply Texas it's been signed by at the moment it's all of the validators that the contract has you said women time although that's not a fundamental limitation I'll get into the limitations later yeah so not only do you need to have access to a secret store in order to validate transactions but also even just to submit transactions you have to store so this is the as I said this is like for the enterprise use case where you can have this sphere where it's trusted with an

outside that sphere it's not trusted and yeah so all the bad thing is not sign off on any like safe change so the flow is you request the state change you collect signatures from each of the validators and then the validators would check that our state change is is okay and then if you get enough signatures which at the moment is all of the signatures then you you submit the signed state transition to the public contract and then that will be accepted so this is pretty like so yeah this is this is useful already for private contracts but it has like some it has five

interpretations right now so the quality is why is he you know one state changed per block so like it only one transaction that transaction can do lots of stuff if they wanted to make like an ELC 20 token you can probably like roll up many transactions into one like transaction that you send to the contract only one state change and so at the moment you can't say only half the validators have to sign up before a state register on it all they validate to need to sign off which is annoying if some of the boxes are down or some the validators are being like maliciously having their packets slowed down by a nation state or whatever you can't do

events or logs you can't crew private comm other provider contracts learn you can't call public contracts so the end is the the signing has redone off chain you can't and yeah there's no like trace of a debugging support but like most of these are not like fundamental limitations I don't think I think maybe the private contracts not being includes other private contract it might be fundamental so now no different so no other thing any of these fundamental limitations you they just haven't been implemented like the fixes have been implemented okay and that's a lot to say it's quite short one any questions

excellent I mean obviously [Applause]