Advancing Ethereum in Permissioned Networks: Integrating PBFT into Quorum

[Music] thank you yeah I'm Tyron Logan I work at JPMorgan and I'm the technical product lead for an a theorem based client called quorum I'm gonna be presenting with you today on basically consensus mechanisms and permission networks and how companies like JPMorgan and startups like me are coming together to really help advance the theorem both in the permission space and also in the in the public enterprise space so the nexus of the of you know all these themes is really quorum itself and for those of you who are not really familiar with quorum quite simply it's a lightweight fork of guess and so by that I mean you can take a smart contract that you have written and deployed to the main net and you can deploy it to a coral network in exactly the same way without any changes which is amazing but also not very exciting if that's all that quorum did so that we'll go through some of the additional features that Corum provides as well quorum is designed to our present operate within permission networks so we know who the protocol is geared towards we know who the participants on the network are and this gives us you know sembly away from a consensus perspective as well it makes us it gives us the ability to have faster consensus effectively ultimately though the reason why quorum exists is to provide enterprises who want to use a theorem with the features that they need to operate within a production environment and because they want to use aetherium you know one of the goals that we have as a result is to make sure that quorum stays as close to public aetherium as possible and this week actually we just upgraded to gif 1.7.2 which is actually really great news and if you use in quorum I think this is something that you know the user community have been looking at for a while so we're really excited about that but it's more than just that we're also helping provide standards under the umbrella of the Enterprise aetherium Alliance and really making sure that we are contributing back to the community but again really the ultimate goal is to have nerium available to enterprises within a production environment but to do that we have to solve four requirements that enterprises need and the first one of course that always comes up is privacy and from a current perspective what we have is the ability to have private transactions private smart contracts and also the ability to exchange assets in a private way and the way that this is achieved is effectively utilizing two services within the Corum architecture the first is constellation which is effectively the core privacy service that Corum implements and the second is a new one called zsl which stands for zero knowledge settlement layer which is a full implementation of zero knowledge proof within etherium it's something that we've done in collaboration with the Z cache team very recently and we'll go over what CSL gives us in a moment but from a constellation perspective if you think about you know I have an insurance contract for example that I want to deploy with yourself and I don't want anyone else on the network to know what the details of that contract are this is where we can use the constellation features to actually obfuscate that information and so effectively what happens is when I send that transaction into the network I make a call to constellation constellation we'll replace the the payload of that transaction with a hash of the encrypted payload and that hash is then globally distributed across the network there's nothing that's revealed about this information but what this does is it gives us some really nice resiliency properties which we're not going to get into today but the key here is that we actually also have a shadow constellation network that runs in the background and so what happens here is you have a point-to-point communication between these constellation nodes of their private information and so you never are globally distributing private information to parties that shouldn't see it but you do end up with this very strong pragmatic privacy solution the side effect though is that if you are not actually part of you know for example a chain of asset transfers then if you're trying to sell me an asset I don't necessarily have guarantees that you are the rightful owner of the asset or that you haven't sold sold it on to someone else and so this is where we leverage the CSL implementation so if you think about public if you we're balances and amounts are you know globally visible clearly from an enterprise perspective this is not really something that's going to fly and so with the CSL implementation what we have is a full obfuscation and shielding of balances of positions of transaction amounts and also of who is actually taking part in the transaction in the first place and so this combination of constellation and zsl gives us this really nice hybrid hybrid privacy environment within the quorum network but of course privacy is not the only thing that enterprises need they have high performance requirements very often given the high volumes that need to be processed and as a result the high throughput and they also need to make sure that those transactions are not only processed quickly but also definitively so once a transaction is actually written you know they don't want to have it reversed such that the transaction all of a sudden didn't take place and it was only going to be included in the chain in a later point and finally they need to know who they're actually transacting with you know we can't have this in an enterprise environment the pseudonymous or anonymous participation network and so the way that quorum solves for these things is on the performance side you know quorum is pretty quick we have blocks that it creates at every 50 milliseconds transaction throughput around a thousand transactions per second for simple value transfers and we ensure that transaction transactions are finalized immediately so the consensus mechanisms that we use I don't actually allow for Forks so you have a guarantee that once your transaction has been committed to the chain it's not going to be reversed and then from a permissioning perspective we have a strong protocol that ensures that you have to be authenticated and authorized onto the network and if you are not then basically you cannot actually communicate with any other node and it's probably a good time to actually talk about permission block chains in general you know the question always comes up why do you need a permission blossom why not just use a regular centralized database or distributed database and when you start to look at the properties of traditional distributed database technology and you have you know this trust among nodes this closed network you have strong consistency this starts to sound very much like the things that we need from an suspected you know all the requirements that we've just kind of gone through so why would we consider you know there's public blockchain or this blockchain implementation where you have only eventual consistency you don't know who's on the network you don't have the high throughput environment and really the answer comes down to the fact that even in this permissioned environment in this closed network we still only have partial trusts we don't have this unconditional trust amongst network participants and so actually from a permission network perspective and from a quorum perspective we kind of land somewhere in the middle and we end up taking you know the best of both worlds from from both the distributed database technology environment as well as the the public blockchain space so we have guarantees around the mutability we have guarantees around auditability and we have the ability to have multiple writers write to the to the chain without having to cede control to some central party to manage conflict resolution for example but the question of course is well what do you do from a consensus perspective in a permissioned environment we don't need proof of work we don't need proof of stake you know we don't have the same in sense of incentivization model that you have in public aetherium so what we can do is start to implement some some different and quicker consensus mechanisms to date we've had two in quorum we have a configurable consensus environment on the one hand we have quorum chain which is a smart contract based protocol that has virtues and block makers kind of akin to proof of authority which is something we're going to be looking to implement and then we have raft on the other on the other hand which is obviously a formally proven protocol it is actually based on the core OS HCD implementation which is used in things like kubernetes and Cloud Foundry and this is the consensus mechanism that gives us a lot of the properties that we've already spoken about but neither of them are Byzantine fault tolerant and so when we heard that a me had written a Byzantine fault tolerant consensus mechanism targeted at Geth we got very excited and quickly started collaborating with them to have have their consensus mechanism implemented within quorum and so with that let me hand over to you say who can tell you a little bit more about a me and also Istanbul [Applause] good morning everyone my name is util in front of me to get started I would like to quickly introduce Amy and what we are doing there I mean it's a blockchain service company based in Taiwan we provide launching services include blockchain infrastructure planning applications and plots and research our most well known projects are Istanbul P of T which are we are presenting today and the decentralized ledger for cost bank transactions in Taiwan while doing this project without current pows i doesn't quite meet our knee and that's why we implemented Istanbul P of T Istanbul PFT or IB ft was inspired by casual risk of practical Byzantine for tolerance paper publishing in 99 without blood tonight's implementation yes of the following key features first of all blocks in IB FD R final which means no fork is possible and no complements are necessary anymore in terms of governance he has a manageable they did have set so that editors can add or remove other waiters dynamically by building on performance you can process around 800 transactions per second at the same time he has the same no scalability as is - this and in order put in order to make blocks self verifiable when put consensus proof into block headers which also means implementing like client will be quite simple last but not least IP of the implemented gossip network so strong connection are not required to make the consensus work a B of T is a three-phase state machine replication algorithm here I like to use a simple network setup to demonstrate how i IP FD works say there are four waiters in this network in the first step or pre prepare staff one of the waiters will be selected as the proposer who is in charge of proposed a new block proposal the waiters can't accept that to ignore that or start a round change say they accept that then they will go cast prepare messages to other validators when they receive more than 2/3 of prepare messages and agree on committing the plug into blockchain they will forecast coming messages to other validators finally when they received more than 2/3 of coming messages they can install a plug-in to blockchain and broadcasted the block to other nodes and this concludes us wrong so in the nest wrong the nest proposal will be selected and proposal next block IB of T can take up to 1/3 of 40 nodes here I like to use a simple example to demonstrate how the network react to malicious behaviour say there is a dishonest proposer who always propose invalid block the network would detect that install a run change process the wrong change process is trying to find out who becomes the next proposer once this is a decided the next proposal would propose a new block and the block generation consensus will continue a PFD can explicitly detect cup of malicious behaviors to name a few they are stove editors mixed message codes for signatures proposal disguise round changes spamming and invalid block proposal right back to corner a little bit why the MEP corn there are a couple of reasons first of all corn is compatible with and close to Papa Experion actually we have implemented our IBM T on top of possible consensus engine so we have used the same code base send a pull request to public go Assyrian please check out the IP six five zero again the IP 6 5 0 for more detail also current and army are trying to solve the same problem not only for banking systems but also under regulatory environments Kern has supported three consensus options which are really useful in these cases they are car engine revved and now I BFG as well that's but not least with JP Morgan back in Korin it builds up trust while working for banking systems all right we have escaped a lot of technical details if you are interested in learning more please come to us all thing is here and we are way I mean teachers thank you so yeah assemble now is available in quorum which we are extremely excited about it gives us that all-important Byzantine fault tolerant consensus mechanism has really been on the roadmap since day one but I think the story is much bigger than just consensus yeah so if we look at what's happened in Coram over the last year we really have this nice collaborative environment that is has taken place so the Istanbul implementation has actually resulted in me submitting a PR back to get to improve the pluggable consensus interface and we've also partnered obviously as I said with Z cash for the first full zero knowledge proof simplement ation in an aetherium client and what this really gives is a really nice reference implementation for zero knowledge proof going forward within within public aetherium we've also collaborated with block apps who developed a tool called ëthe pruner which allows us to archive all historical states which obviously reduces blockchain blurt improves the performance of the of the network and as the name says f pruner this is not just something that's targeted at quorum but also something as targeted and used unusable for the actual main line theorem code base excuse me and then finally with como technologies who developed porosity which is an EVM decompiler decompiling by coded into solidity contracts that helps from a quorum perspective to identify vulnerabilities in smart contracts and of course given that chorim and etherium are very close together it's directly usable within public aetherium too so I think what you have is this in a really nice two-way movement of innovation between the public if they're in space and also from the permission in submission environment back to public aetherium and when you couple that with the number of companies that are now looking at chorim building on top of chorim building projects and on chorim building tools around chorim this is all directly relevant and useful to public aetherium as well so we have an increase in focus on etherium we have an increase in acceptability within enterprise of the theorem and ultimately I think in terms of what we are collectively trying to do that can only be a good thing so that's a that's our talk today thank you so much for listening if you want to have more information go to these places [Applause] you