Anton Gavrilov – Parity Technologies – Private Ethereum Transactions

Anton Gavrilov – Parity Technologies – Private Ethereum Transactions

Hello and Guten Abend. My name is Anton Gavrilov – I work in Parity. Just in case if you don’t know what Parity
is, we develop quite popular Ethereum client, and some other Ethereum products. I want to talk a little bit, very briefly,
about our latest additions into Parity named private transactions. To build a very, very high level and (Greek?)
presentations, I don’t think that we will be able to start developing new product after
presentation immediately, so, but maybe it will be a good start, and you’ll have some
understanding what you can do, and, most importantly, what you can not do with it, and what is this
for. So, let me start from the context first, why
it’s all needed, and why it sold. What’s the reasoning for all of this. In spite of the rumours that Ethereum will
recently replace all big corporations, banks, etc. And things that right now is being done with
thousands of men force, will be done with 10 lines of code. In spite all of these rumours, still Ethereum
not so, not the perfect solution for enterprises’ cases, as I call them. There are multiple reasons of course. Here I list two of them because they are important
from the standpoint of this presentation. First of all, it’s permission. As you probably know, that’s Ethereum, every
node can do anything. And all permission that right now exists can
be done, for example, on smart contacts level, or somewhere else. And, the second part, that is also pretty
important for this presentation, is data privacy. You don’t believe how many people believe,
or don’t know, that everything that they are doing in terms of where contracts are
publicly available. So, a lot of people think that’s happening
only on their nodes, and all other people don’t know what’s going on. Still, as I’ve said here, all data is available
for all nodes, surprisingly. There are several classical approaches – what
to do with it, how to nevertheless build this solution with enterprise features using Ethereum. The first classical approach is so-called
private blockchain, private chain. That’s pretty obvious, I think. The second approach: just to add more layers,
more (compliance?) in to your solution, and if you are exchange, don’t store anything
on blockchain, I mean, don’t store private data, don’t store crucial data – store
it somewhere else. But operate on blockchain as needed. And the third approach, (inaudible) protocol
a little bit, or not little bit. There are known solutions like WORM, like
Hyperledger, and they create product based on Ethereum, but with several additions that
support these use-cases. In Parity, they are trying to achieve (inaudible)
also. But you find and provide (inaudible) in our
clients – Ethereum clients. Here, private transactions is only part of
them. Here I list three major companies, but there
are more, of course. The first one is transactions permissioning. Using Parity, you can achieve permissioning,
and you can assign permission to nodes, so you can deploy your network. And assign several nodes permission like creating
contracts, calling contracts, creating transactions and so on, and so forth. The second big part of our, I call permission
features, but it’s just some name for this part of work. The second part is secret store – it’s
a pretty interesting thing, and I encourage you to read about it more, because I’m not
going to cover it in this presentation. Basically, the secret store is aimed to create,
generate and save, and manage secret keys that can be used for symmetric encryption. So basically, it’s Parity node that is running
in special mode. And the third part here, the major part, is
private transactions. Basically, the idea is to have encrypted smart
contracts operated on private or public chain. Of course, I will talk about it more next. But, still, as I said, everything is achieved
through modification of Parity clients, so we need to have Parity clients deployed in
your network. Here, very very high level picture; how it
works. As I’ve said, this store smart contract
in an encrypted way. In order to store it, we use special wrapper,
special wrap in public contract, and we store everything encrypted inside it as special
fields. So, in order to view it, view it in data inside
this contract, a node that has access to the key has to decrypt it, and using special IP
of course, special (inaudible), has to decrypt it. In order to modify data, inside this special
private contract, it’s more complicated story. Of course we have to decrypt it first, make
some changes in state of a contract, this private contract. After that, all these changes should be, must
be validated by special nodes. This provides guarantee that all these changes
will be made on accepted state – (inaudible) accept state, and all these changes are validated. After changes are validated, regular public
transactions is created, but payload for it is also just encrypted data that is changed
in some encrypted fields inside this public contract. So, for all users that don’t have access
to keys, is just public contract with encrypted fields inside. So we don’t see what there is inside these
fields, we don’t see code of this smart contract, so we don’t know what is going
on. Here we can see that all keys are stored inside
secret store, so we need to have it running for this solution. Of course, right now deployment procedure
is quite complicated – it’s not for beginners, let’s say. The first version of this solution is in production
on Kovan. It’s very important to know which limitation
it has. Most important limitation concerns this private
contract, so it’s, I call it a simplified contract, but basically we don’t support
events, we don’t support logs yet. We don’t support (tracing?) yet. And, in order to work with feed, you need
to work using Parity JS library, not web3.js, so web3.js is also not supported. As I’ve said, it’s deployed on Kovan,
we are fixing bugs, working on (the clock?), so all this limitation that I already listed,
(we around the clock?) of course, for next version. But most importantly, what we are interested
in right now is use cases. This work was done in terms of our energy
project, and, of course, we had in mind some use cases, some scenario, how this functionality
can be used. But still we don’t know actually how it
will be used in reality, because it’s very new functionality and we would love to hear
your use-cases – how you want to use it, which functionality you want to have. Which is crucial for you, which is more important
for you. We, Parity as a platform, would love to provide
this functionality for you in short time if it’s needed, but still for us it’s very
important to know this first. Here, as I said, a couple of links, but they
are pretty easily Googled, it’s our wiki, and our Github. So on wiki there are several tutorials; how
to start, how to deploy. And of course, very detailed description,
and more detailed description how it works, not just this very high level diagram. So, good place to start, and of course, if
you have any questions, ideas, requests, feel free to contact us. We love feedback – any feedback, and are very
eager to talk to you about it. So feel free. That’s basically it, I think I left some
time for questions, but also very short ones, I believe, right? Okay, thank you. (applause)

One comment

  1. Thank you, Anton I learnt a new word today, 'excursus' – a detailed discussion of a particular point in a book, usually in an appendix. Also, I enjoyed your presentation.

Add a Comment

Your email address will not be published. Required fields are marked *