[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