 Thank you. Yeah, I'm Tyrone Loven. I work at JP Morgan and I'm the technical product lead for an Ethereum based client called Quorum I'm going to be presenting with Ute today on basically consensus mechanisms and permission networks and how companies like JP Morgan and startups like Ami are coming together to really help advance the theorem both in the permission space and also 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 quorum 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 quorum provides as well Quorum is designed to operate operate within permissioned 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 some leeway 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 Ethereum with the features that they need to operate within a production environment And because they want to use Ethereum know one of the goals that we have as a result is to make sure that quorum stays as close to public Ethereum as possible And this week actually we just upgraded to get 1.7 point 2 which is actually really great news and if you using 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 Ethereum Alliance and really making sure that we are contributing back to the community But again, really the ultimate goal is to have a theorem available to enterprises within the production environment But to do that we have to solve for requirements that enterprises need and the first one of course that always comes up is privacy And from a quorum 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 quorum architecture. The first is constellation Which is effectively the core privacy service that quorum implements And the second is a newer one called ZSL which stands for zero knowledge settlement layer Which is a full implementation of zero knowledge proof in Ethereum It's something that we've done in collaboration with the Zcash team very recently and we'll go over what ZSL 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 Replace 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 point-to-point communication between these constellation nodes of that 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 we leverage the ZSL implementation. So if you think about Public Ethereum where 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 ZSL 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 Corum 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's 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 Corum solves for these things is on the performance side You know Corum is pretty quick. We have blocks that are created 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 fork 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 Permissioned blockchains in general, you know the question always comes up. Why do you need a permissioned blockchain? Why not just use a regular centralized database or distributed database when you start to look at the properties of traditional distributed database technology and you have you know, there's trust among nodes this closed network you have Strong consistency this starts to sound very much like the things that we need from an enterprise perspective You know all the the requirements that we've just kind of gone through. So why would we consider? You know this 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 trust We don't have this unconditional trust amongst network Participants and so actually from a permissioned 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 immutability We have guarantees around auditability and we have the ability to have multiple Writers right 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 incentive incentivization model that you have in public Ethereum So what we can do is start to implement some some different and quicker consensus mechanisms to date We've had to in a quorum. We have a configurable consensus environment on the one hand We have quorum chain, which is a smart contract based Protocol that has voters 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 hand on the other hand Which is obviously a formally proven protocol It is actually based on the core OS etzied implementation Which is using things like Kubernetes and cloud foundry and this is the consensus mechanism That gives us a lot of the 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 to who can tell you a little bit more about a me and also Istanbul Good morning everyone. My name is Utiline from a me To get started. I would like to quickly introduce a me and what we are doing there I mean, it's a blockchain service company based in Taiwan We provide blockchain services include blockchain infrastructure blockchain applications and blockchain research our most well-known projects are Istanbul BFT Which are we are presenting today and the decentralized ledger for cross-bank transactions in Taiwan While doing this project without current POW design doesn't quite meet our need and that's why we implemented Istanbul BFT Istanbul BFT or IBFT was inspired by Castro Lisco's practical Byzantine fault tolerance paper published in 1999 Without blockchain nice implementation. It has the following key features First of all blocks in IBFT are final Which means no fork is possible and no compromises are necessary anymore In terms of governance it has a manageable very data set So that the data is can add or remove other data is dynamically by voting Unperformance it can process around 800 transactions per second at the same time. He has the same no scalability as each dash does and In order to 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. That's but not least IBFT implemented gossip network So strong connection are not required to make the consensus work IBFT is a three-phase state machine replication algorithm here I like to use a simple network setup to demonstrate how IBFT works Say there are four way data is in this network In the first step or pre-prepared step one of the Vedators will be selected as the proposer Who is in charge of proposed a new block proposal? The Vedators can't accept that to ignore that or start a wrong change Say they all accept that then they will broadcast prepare messages to other Vedators When they receive more than two-third of prepare messages and agree on committing the block into blockchain They they will broadcast coming messages to other Vedators Finally when they receive more than two-third of coming messages They can install the block into blockchain and broadcast the block to other nodes and this concludes consensus wrong So in the next round the next proposal will be selected and propose the next block IBFT can take up to one-third of 40 nodes Here I like to use a simple example to demonstrate how the network react to malicious behaviors Say there is a dishonest Proposer who always propose invalid block The network will detect that and start a wrong change process The wrong change process is trying to find out who becomes the next proposal Once this is decided The next proposal will propose a new block and the block generation consensus will continue IBFT can explicitly detect couple of malicious behaviors To name a few they are store Vedators makes message codes Forge signatures proposal disguise round-change spamming and invalid block proposal All right back to corner a little bit. Why the army pick Warren? There are a couple of reasons first of all Warren is compatible with and close to public Ethereum actually, we have implemented our IBFT on top of pluggable consensus engine So we have used the same code base send a poor request to public go Ethereum Please check our EIP 6 5 0 again EIP 6 5 0 for more detail Also current and I mean are trying to solve the same problem Not only for banking systems, but also under regulatory environments current has supported three Consensus options, which are really useful in these cases They are current trend revved and now IBFT as well That's but not least With JP Morgan backing Corrin 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 our team is here and we are wearing army t-shirts. Thank you So, yeah Istanbul now is available in Corrin, which we are extremely excited about it gives us that all important Byzantine fall tolerant Consensus mechanism has really been on the road map since day one, but I think the story is much bigger than just Consensus here. So if we look at what's happened in quorum over the last year, we really have this Nice collaborative environment that is has taken place. So the the Istanbul implementation is actually resulted in I mean submitting a PR back to get to improve the pluggable consensus interface and We've also partnered obviously as I said with z-cache for the first full zero-knowledge proofs implementation in an ethereum client and what this really gives is a really nice reference implementation for Zero-knowledge proofs going forward within within public ethereum We've also collaborated with block apps who developed a tool called eth pruna Which allows us to archive or historical state which obviously reduces blockchain bloat Improves the performance of the of the network and as the name says eth pruna This is not just something that's targeted at quorum But also something as targeted and used unusable for the actual main line ethereum code base Excuse me and then finally with co-made technologies who developed porosity, which is an EVM decompiler Decompiling bytecoded into solidity contracts that helps from a quorum perspective to identify Vulnerabilities in smart contracts and of course given that quorum and ethereum are very close together It's directly usable within public ethereum, too. So I think what you have is this in a really nice two-way Movement of innovation between the public ethereum space and also from the permission permission environment back to public ethereum and when you couple that with The number of companies that are now looking at quorum building on top of quorum building projects on quorum Building tools around quorum. This is all directly relevant and useful to public ethereum as well So we have an increase in focus on ethereum We have an increase in acceptability within enterprise of ethereum and ultimately I think in terms of what we're collectively trying to do That can only be a good thing. So that's it. That's our talk today. Thank you so much for listening If you want to have more information