EthCC 2: Tyrone Lobban

good good evening everyone thanks very much for coming to this all place late this evening my name is Tyrone Robin I work at JPMorgan I'm the product lead for a platform called quorum if you're not familiar with quorum it's effectively a fork of the gift client that's designed for operating within permissioned environments and so what I'm going to be talking about today is really deploying aetherium in corporate production enterprise great environments and this idea of bringing aetherium to enterprise and in order to just frame the conversation what I'd like to do is talk about magnitude not scale not scaling not talking about charting or anything like that here really just that's this idea of magnitude and while I'm talking about this I would like you just think about the opportunity that you see in front of you and apologies in advance I work at a bank and so you're gonna see a series of pie charts so what we have here is the daily volume for the top five cryptocurrencies this is taken from a couple of days ago and I think this is significant you know twenty two billion dollars worth of transactions being traded in these open environments and these fairly new asset classes from a financial services perspective and you know clearly as you would expect you know tetherin bitcoin taking up the majority with a theorem around four billion transactions in terms of volume over that day but this is just a fraction of the daily volume of payments processed by JPMorgan every day so JPMorgan processes six trillion dollars worth of payments each day and when you compare that obviously to the daily volume of cryptocurrencies this is just a fraction listen half a percent I thought what was interesting here when I was put into the slide together was trying to represent the scale correctly and clearly the graph on the right is not to scale with one on the left and so as an exercise for myself I decided to try and scale it correctly and so here we have twenty two point eight billion dollars represented by this small little dot and then I guess a big circle which probably takes up most of that wall if you had to extrapolate it out so the scale and the magnitude here is I think quite interesting another data point is the fact that you know if we think about 2017 and the height of the ico boom we had almost seven billion dollars raised in this completely new financial services opportunity right this new way of raising finance and this completely open platform and again I think that's fascinating that we that 7 billion dollars worth of debt or whatever kind of classify these these tokens as was raised but again if you compare that to more traditional finance in 2017 global IPOs raised or finance raised through Global IPOs came in just shy of one hundred and eighty billion dollars so again from an IC o---- versus IPO perspective you know around 4% was raised through IPOs through IC o---- is and what's even more interesting is that if you could then compare that to the global debt that was issued in 2017 which came in around three point seven trillion dollars worth of debt even IPOs start to kind of pale in comparison so what is what is the point here well I guess the point I'm trying to make is that when we think about permission blockchains really the reason why we are currently focusing on them is because the magnitude that we are currently focusing on and trying to tackle within these traditional financial environments and corporate environments is significantly different to what we are looking at today at least in public blockchain land and so we need a rigorous control environment and a permissioned environment to actually enable us to tackle these challenges within this traditional world but I think the opportunity is that permission block chains can potentially be a proving ground for a future state when these traditional financial models actually do start to move on to public block chains or at least enabling that in some sense and so really this is the reason why JP Morgan developed quorum in the first place and so again if you're not familiar quorum is an open-source platform it's a fork of the gif in the gif client and it's designed for processing transactions within a put a permissioned Network it brings strong privacy and controls and if we think about what quorum is it's really an amalgamation of these characteristics so firstly it's aetherium under the hood as I say that brings privacy to the a theorem environment we implement permissions configurable consensus environment and also we have as a result of that much higher performance profile than what you get on public law chains and so what I'd like to do is just spend spend some time talking through some of the design the architecture and design of quorum and some of the technical details and then we'll marry that up against the requirements that we see from a an enterprise perspective and show how we're actually using quorum to to meet those requirements so firstly from a high-level design perspective you know quorum is is fairly straightforward people talk about quorum in sort of conceptual terms as a combination of what is really a guest node we refer to it as a quorum node which is get plus some modifications and a separate service called Tessera which is a Java implementation of the service or constellation which is a Haskell implementation of the service but really this service is something that enables privacy on a permissioned network it's made up of a transaction manager and a secure Enclave and we're going to go through how these things kind of work together and in a little bit but I think the important thing here is quorum is really just guess under the hood right now it's on guess one point eight point twelve we're looking to move to one point eight point eighteen soon and then we'll start to look at the constants at Constantinople up upgrade and additionally because it's just get the you know the tools that you kind of know and love from public blockchain just work out of the box when you're dealing with so called public transactions in a private network so you know trifle meta mask remix obviously all of the open zip and celebrity contracts they're all just deployable and compatible directly so one of the key things is obviously privacy and apologies a lot of information on the side here but I'll kind of talk you through this so the actually the primary reason why we developed quorum was to solve for privacy specifically from a financial services perspective it's really important that you know your counterparty has no visibility of your transactions you have to protect your balances you have to protect your your pricing etc and so we effectively have a hybrid privacy design we have two components that enable privacy so the first one is this Tessera and constellation service that I was mentioning this is the primary privacy service within quorum and what it enables is the point-to-point communication of private data so private data is is communicated directly between for example to Sara nodes and there's no global distribution of their private data on the blockchain what is globally distributed the however is a hash of the encrypted version of that data and important here it's it's not the encrypted data that's globally distributed it's a hash of the encrypted data so we're never actually storing encrypted data on the blockchain the way that we actually went about achieving this was through a couple of modifications firstly we introduced a new attribute onto the transaction model so there's a there's an attribute called private four which is effectively an array that you can pass in a list of addresses that you want to send your private data to so you can send you know these three counts party should be receiving this information you put their public keys in this array and then corn will effectively ensure that distribution happens in a point-to-point fashion we also split the state tree so in Coram you have a public state tree and a private state tree public state tree is the same across all core nodes and then a private state tree contains just the data that's relevant to you again importantly no encrypted data on chain and through kind of architecting your application you can actually use this model to ensure things like prevention of double spend in a token in a token environment but there are some limitations and so what we did was meant that with a zero knowledge proof simplement ation so in 2017 we worked with the z cash company to effectively in a all fully private tokens on a quorum environment and so this does actually give you a situation where you can have you know conservation of the total money supply as well as prevention of double spend in a private manner this is the proof of concept only but through this year we're going to be looking to actually industrialize that and productionize it but the idea here is that these two components really are compatible and work together quite nicely supporting various use cases so when we look at the entire solution quorum really has a quite a unique and novel approach to privacy so firstly there's no dependency on any third party application or external external service there's also no single point of failure so there's no special nodes there's no special components and we have the ability to integrate with new cryptographic schemes as well we ensure that we meet various regulatory requirements so when we developed quorum it was developed with this idea of knowing what our power regulatory requirements were around management of data and so again as I was saying earlier data is only transmitted in a point-to-point fashion and so you're always aware of where your data is and this enables you to actually meet local you know data compliancy laws and then finally we have a strong notion of security in this model because every transaction is actually visible directly on the chain by all nodes but only in only the hash of that data is visible and so what you effectively have is every node witnessing a transaction has occurred but doesn't have any visibility of what that transaction is about and so what this enables you to do is effectively you know present that hash to anyone else in the network and say please can you guarantee or or confirm the fact that I held this data and nothing has been changed on the network at all and overall what this gives us is this notion of decentralized privacy and so just as a kind of high-level schematic of what a Korell network looks like again every node on the network is the same everywhere every node is running the same protocol every node has exactly the same blockchain there is only one blockchain there's not a set of bilateral block chains and the only thing that really differs is the fact that you have these divergent state trees so that's privacy another important piece when we think about Enterprises is commissioning it's important that corporates know who they're transacting with know who they're doing business with there are strong know your customer rules that many organizations have to comply with and so we have multiple implementations or ways of actually achieving permissioning within the core of environment so the first one is that we have node level permissions this is effectively a configuration file on every node that allows you to determine which other nodes you can actually accept requests from and make connection requests to and coming in April we're also implementing a smart contract based permissions model so this is really enabling a fully decentralized view of the permissions model where every node on the network is guaranteed to be following the same rules in terms of how other entities are actually permissioned on to the blockchain and within the smart contract you can define you know whatever voting mechanism you need or want to actually permission different organizations onto the network and you can also do things like allowing for changes of who is actually governing the network overall who's operating the network equally you can decide you know how to blacklist or whitelist nodes deactivate nodes that might be you know temporarily problematic there may be inadvertently spamming the network for some you know some technical reason and so you can deactivate nodes through this process and then additionally we're introducing this idea of granular roll types so what we've seen through our experience with actually moving aetherium into production is that not every organization once or needs the same level of access regulator node for example may only need read-only access to the network and so what we're introducing is this notion of different role types so one entity may be able to submit transactions but not deploy a smart contracts another entity may be able to deploy smart contracts whilst another one might may only be able to read the blockchain contents itself as I said this is coming in April these last two features which I think is going to be really important for some of the larger networks that we're seeing being being stood up another important piece from a permission blockchain perspective is consensus so the idea of using a proof of work or even proof of stake within permission blockchains it's not really required we have a different trust model in a permissioned environment but what people do need typically is this notion of finality finality of transactions and what we've seen is that actually different use cases require or can benefit from different consensus algorithms and so we have a configurable consensus model within quorum so right now we have three consensus algorithms proof of authority which you know many of you will be familiar with we have a raft implementation and then we have a Byzantine fault tolerant implementation called Istanbul so just very quickly the way we think about PRA is that it's probably ideal for proof of concepts but given that it doesn't actually give you a finality guarantees it's not really something that we seeing used in production raft on the other hand is a fully crash fault tolerant consensus algorithm formally proved this is actually based on the sed raft implementation which underpins things like kubernetes and so what we see is a very high throughput low latency environment block cements at every 15 milliseconds on demand so you don't have a continuously growing chain and we also obviously as a result see transaction finality because every node on the network basically progresses the blockchain at the same time and then just very briefly on IP ft as I said Byzantine fault tolerance it actually has a very nice scaling characteristic it scales very similarly to what you would see in public aetherium and again importantly it provides us with transaction finality one of the providers who effectively provide a sort of managed service for quorum actually told us that there's around 2,000 networks currently running 2,000 core networks currently running idft but it's not just privacy performance permissioning different consensus algorithms that are needed from an enterprise perspective there are a host of other requirements that need to be met so from security to resiliency availability in different cloud environments the ability to continue test and integrate new changes being able to easily deploy software and also being able to monitor for failures so we've done a lot of work in this space on the security side of things we have a full integration with Azure key vault and also with hash hash II cobalt and these are really important in terms of the way that enterprises expect keys to be managed and a segregation of duties that is required specifically from a cyber perspective we've also off the back of that decided to further separate out the Enclave within the Tessera environment from the transaction manager and really what this is going to allow for is some sort of Enclave as a service where you can really bring the Enclave that you need for key management to the solution that you that you're currently developing in the same vein we're doing more work around API segregation that allows us to have better authentication of the of the various API calls and then finally we're introducing optionally the notion to have gas costs so gas is actually free on quorum by default there is no need to have ether to transact on the quorum network but in some of the larger networks what we're seeing is people do actually want to have some way of incentivizing people to actually behave correctly and throttle networks and transaction that are being committed to the chain and so optionally you can actually enable gas or at least the gas price on the resiliency front very quickly we have automatic node recovery for the tessera node so if that goes down it can retrieve payloads from its peers keep in mind that the tessera network is not really a blockchain and so you had to implement the recovery separately for that but what we do have as well with this era given that it's a Java based environment is full support for typical block database schemes that you would like with schemas that you would like or provided so h2 Oracle SQL Lite for example and then from a cloud perspective we have native supports in Asia the Microsoft is actually one of the early providers of cloud availability or cloud provision for quorum there's a quorum template that you can go on that can very easily spin up a blockchain network or set up a node and SOP have recently done the same thing continuous testing is extremely important for any production implementation right so what we are using is the gauge framework which is really nice framework that allows you to very easily describe tests and write tests in a number of different languages that basically give us a full regression an acceptance testing framework every time there's a pull request made the full suite runs and we run a daily a daily regression as well to ensure that any changes that we are making are not going to be breaking existing production implementations on the deployment side we've also developed something called quorum cloud which basically makes it easier for you to deploy two different cloud environments currently supporting AWS with additional cloud providers in the pipeline we also have an official docker image which makes it obviously very easy to deploy quorum containers and we're seeing support from some of these providers who are offering a managed type of service so collider and block daemon for example and then finally on the system monitoring aspect full integration with Splunk if you're familiar with Amber data or you know very prominent on the public blockchain side of things amedeo also has native support for quorum and then we have quite nice tools built through core fauna that allow you to actually monitor the various states of the network so how is that all being used how's it all coming together well a host of companies organizations and startups are using quorum clearly JP Morgan is a key user and we'll go through some of the details around some of the key production improvement stations that we have specifically the interbank information network also a debt issuance platform that we created and and I'm sure you would have seen the news on JPM coin but outside of JP Morgan you know we have large banks we have central banks who are building with quorum we have a host of service providers so you know your top four systems integrators Accenture iey clearly Microsoft is doing a lot of work on quorum as well and from a startups perspective this is I think really exciting too because a lot of these startups are building services and tools for the public in theory and blockchain and they're all directly compatible with quorum and so this is really one of the advantages of having a fork of the public blockchain is that you just get to use a lot of the innovation or you get to basically have access to a lot of the innovation that's taking place already and just some brief stats in terms of you know how quorum is being used so 11,000 docker pools and around 3,000 stars on github with about 25,000 monthly views so let's talk about some use cases and actually deploying quorum in a production environment so the first one is the interbank information network this is a network that's been formed by JP Morgan and the goal here is really to minimize friction in cross-border payments there are about a hundred and seventy banks signed up to this network and this was really born out of our analysis of the payments flow and how blockchain can be applied to daily payments and what we realized was payments by themselves actually work fairly well but when you look at cross-border payments often what we saw was delays you know from a couple of days to a number of weeks specifically related to the sanctions screening process so if I'm making a payment to someone in another country there's actually no way that that payment can go through directly the house that has to go through a series of correspondent banks and effectively you end up with this daisy chain of correspondent banks communicating this payment information to each other and what happens is if there is a sanctions flag that's being raised either by the person who's making the payment or against the person who's receiving the payment the payment effectively stops and each of these banks have to basically walk up the chain to the bank prior to them to actually get the information that they need there's no way to directly access the the end beneficiary or the remoter and so what we've done is we've created a blockchain platform called iin and this effectively simplifies this entire process moves it from a email and phone call based process where you have these very fragmented communication channels to something that allows for more peer-to-peer model to exist but in order to actually do this clearly quorum had to solve for a number of key requirements that these these surprises have firstly privacy we're talking about you know people's names and addresses and dates of birth and that information can't live directly on on the blockchain so we had to implement privacy using the Tessera model obviously permissions is important you have to make sure that only the banks that are part of this network can actually join the network and so implementing that strong governance model was was crucial performance you know we're dealing with you know hundreds of thousands of transactions from a sanction screening process perspective and so we want to make sure that we can actually meet the performance requirements and this is where things like the raft consensus algorithm come in security gain really important from key management and so this is where the integration with Azure key vault and hashey cobalt became very important providing that segregation of where the key lives versus who can actually interact with the node and then obviously continuous integration testing for any production environment similar story for another use case that we have this one is not actually in production but it's something that we are currently working on quite closely this is a debt issuance platform that we piloted last year with the National Bank of Canada they issued a hundred and fifty million dollars of debt using a Yankee CD product with investment from a number of global investors and really what the platform here is here is the debt issuance and lifecycle management platform and so what we have is the ability for issue is to issue debt tokens banks to issue cash tokens those to be exchanged atomic Leon chain we have within the smart contracts in the system lifecycle management and pay down automatically built in as well as a bidding and auction system for the initial distribution and actually an interesting point here as as I said this was March last year that we modeled the cash tokens and so you know when we think about the work that we've done on JPM coin this was actually the genesis or one of the genesis projects for that because we recognized the need for having on chain cash in order to actually support the system from a requirements perspective you know very similar to I n this it's important to have privacy implemented you know people cannot see investors for example shouldn't be able to see the price that another investor is paying or or how much they're buying we should only be allowing accredited investors onto the platform or specific issuers it's very important to have finality of transactions you know when you're making a bid for a particular piece of debt you don't want that to somehow be usurped by some other mining process for example and the same considerations around security and continuous integration not just JPM you know there's a number of other companies who are building on top of quorum moving into production I'm not going to go through the details of all of these but just to highlight you know across industries from commodities and trade finance and supply chain there's additional work happening in the payment space and kyc and national networks being built using quorum these companies are using quorum and more importantly using etherium within the enterprise because it enables them to actually put their business processes and transform their business processes using blockchain an important point here as well as that when we think about the requirements that these entities have and how that feeds into quorum really the the roadmap that we have is community driven so we have from a quorum team perspective regular discussions with companies that are actually building on quorum to take in their requirements to make sure that quorum is actually meeting their needs and we have you know daily dialogue with MIT with many organizations obviously JPMorgan being one of the key users of quorum it has you know quite a heavy impact in terms of the type of features that are being developed don't need to go through all of us and the slides will be available but but very you know clearly we're looking at things across a number of key categories which are the ones we discussed privacy commissioning and performance resiliency scalability interoperability with other platforms is extremely important for you know the the kind of future state of blockchain and the tooling that that sits around quorum as well we are hiring both on the engineering side and the product side as well as in the community space so if you're looking to get involved in the excited world of mission blockchains meeting me afterwards and just to summarize you know the the the messages here firstly going back to where we started the magnitude of the enterprise space is significant but I think an opportunity and so when we talk about scaling blockchains we should be thinking about scaling for the scale of enterprise and the magnitude of enterprise permission blockchains providing means of tackling these problems today and I think that in the future they may just end up being a provable proving ground and an on-ramp into opportunities that can be really explored within the public space I think that you will have a persistent state of permissioned and public blockchains but I think some of it may end up transitioning and then finally a theorem you know is being deployed in enterprise in production via platforms like quorum and I think this is just a really positive thing for everyone here in terms of bringing you know additional mindshare growth funding etc to the generalized etherium community so feel free to reach out if you want to learn more about quorum you can go into the JP Morgan calm web site quorum is 100% open sourced and so you can download the repo we also have a very active and growing slack so just use the bitly their quorum - slack and reach out thanks very much [Applause] what sort of boa check-check what sort of boa do you have which doesn't prove up sorry yeah so it is it's obviously chorim being a gap implementation just implements the same consensus as you would haven't guessed the point is that in the other implementations where they are leader based the other nodes just automatically follow the transaction or sorry the votes that are being committed okay so I think that that's a question that you often have you can't sorry can you repeat the difference between quorum and happy Liza fabric yeah so a number of key points firstly from a privacy perspective as I said there's a single blockchain on the network so when you think about hyper ledger fabric there's effectively you know they have the channels implementation and that ultimately requires or in one of these two is multiple block chains so some of the challenges that I think the fabric team are addressing and by the way JPMorgan is a one of the founding members of hyper ledger so I think that when you think about permission block chains in general there are going to be a number of solutions but what we've seen challenges with is things like transacting across channels and ensuring privacy of channels also the reliance on centralized ordering services to actually provide that transaction finality and privacy and then a very important point for all of us here is that quorum is you know based on aetherium and so we have direct compatibility with what is happening in the public aetherium space and so if you think about a future world where maybe these two things are closer together every everything you build for a quorum network is directly compatible with public aetherium network and largely that's largely true going the other way and I think that that's going to be a very important thing when we think about you know maybe these things are internet internet like maybe not but having that interoperability between a permissioned environment and a public watching environments I think is going to be crucial hi are you looking into state channel technology already for scalability and privacy yeah so the question was are we looking into state channels so we try and stay abreast with all of the latest developments that are happening within the public blockchain actually it's a it's a little bit unusual if you think about the quorum design in some sense it is it does actually provide like a sharding compatibility which is slightly different Odyssey 2 to state channels and what you're describing but I think when we think about how you can go about scaling the network quorum doesn't doesn't necessarily suffer from some of the same challenges that you have in public blockers so whilst we're looking at it and we will always look at the new technologies that coming out and seeing how we can leverage them we do actually are actually able to meet many of the requirements we had today just with the layer 1 implementation hi Jeff is GPL licensed and GPL is often a nightmare with legal and compliance Department so how does it work with JP Morgan and your partner's like markets yep so the question was just around the license and whether there are challenges with GPL so JP Morgan is clearly using quorum and we are we have to abide by all of the rules and requirements around the license GPL is actually fine to develop on as long as you're not making changes to the core code base so you can develop applications that sit on top of a GPL implementation and not have any concerns or your concerns around having to commit your courage you know make it publicly available and actually the services that we have developed around quorum so the Const and Dussehra environment those are actually Apache licensed the tercera sorry the ESL implementation from Z cache also is not GPL licensed so you can have a whole host of applications and services built around quorum which don't require you to give up any of your proprietary code base but I think actually principally it's very important to have a blockchain implementation that is not going to be kind of taken away from you and monetize and you don't get access to all of the features that are being developed and so we think it's really important that when people are building on top of quorum that and actually contributing to quorum that that everyone should benefit from that in the same way that everyone benefits from changes going into the public atrium space I have two questions the first one we got in zsl when will it be product ready I think that appears he was submitted one year ago and the second one is is there any plans by JPMorgan to support quacks you know placement of chess era I think they handled differently the way that the quartz notes are communicating yeah so just quickly was the first question around the timing of CSL I didn't quite catch what your first question was on yourself okay so a question is when will the CSL implementation be productionize so we're actually continuously looking at additional and new implementations of zero-knowledge our plan is for this year to have a strong production implementation but really it's largely dependent on the work that is happening elsewhere so we have a small cryptography team internally but we are going to be looking to continue you know partnerships with additional players externally and so I think part of it is just around what is happening outside clearly clearly there's a lot of change that is taking place since we want to make sure that we're able to you know really leverage that and implement the correct solution and then the second question was around crux so crux is you know fully compatible we know the developer of crux very well and I think it really just comes down to choice so crux being written and go to Sarah being written in Java constellation being written in Haskell there is no reason or requirements to use one or the other you can really use what you would like and so if you wanted to spin up a choral network using crux and you know you should be able to do that and I think it's a I think it's an important point because what we do want to enable is the development of additional services around quorum and I think crux is actually a really good example of that cool thank you very much [Applause]