so we're gonna go ahead and get started
I'm gonna be very very brief
I'm Paul Brody I'm the global blockchain
leader at ey and before I hand this over
to the people who actually know what
they're doing I just want to kind of
give you two pieces of information that
might be useful for your background
number one a little bit about a why
right
ey is all in on the etherium ecosystem
right everything that we do all of our
applications that we develop in
blockchain are developed in the etherium
ecosystem they run on the etherium
private solutions they run in quorum and
most importantly from a strategic
standpoint everything we do is focused
in the long run towards making it
possible for enterprises to use the
public main net now why do we believe
enterprises should use the public name
that this is item number two we believe
that blockchains will be the biggest
transformational technology for
enterprises since ERP so ERP got
enterprises to coordinate internally
blockchain is a tool that's going to
allow networks of companies entire
business ecosystems to transact
seamlessly with each other to build
complex supply chains with a very low
overhead and incredibly high efficiency
but and this is the important thing
none of this matters and it will never
happen if we don't have incredibly high
standards of security and privacy for
public blockchains right no corporation
no enterprise is going to sign up for
anything if they know that their
competition can see what they're buying
or how much they're paying or where it's
going so nightfall is all about our
efforts to start to make that possible
and it fits in with a lot of the other
work we're doing whether it's audit
security tools or regulatory compliance
and without any further ado I'm going to
hand it over to the brilliant nightfall
team Michael
[Applause]
so yeah what we're gonna do is we're
gonna quickly go over what nightfall is
Paul's covered why we're doing this
we're going to cover the high-level
architecture how people can use
nightfall to build on top of their
applications and their new serfs going
to cover an exciting new piece of work
we're doing on batching so yeah public
blockchain is great we can all agree
with that but the transaction data is
public whereas businesses they need
transactional privacy okay as Paul
mentioned and that's why we build
nightfall so what kind of privacy does
nightfall enable at the moment well it
enables privacy of ERC 20 contracts and
ERC 71 contracts so you're fungible and
non fungible tokens already deployed
contracts people who earn those tokens
to make their tokens private and they
can hide the content being sent so for
ERC 71 the asset or for ERC 20 they can
hide the value being sent they can also
hide the recipient so the person being
sent the money will be hidden and won't
be known ok and really importantly and
what we're most excited about is that
this is completely open source in the
public domain so we've released all this
because we believe the best way to get
businesses to that stage to using the
public main that is to contribute and to
work with the community to get these
tools as good as possible so we're
inviting everyone to come look at the
repo contributions or welcome and let's
talk and we'll talk about what we're
planning on doing next if anyone has any
good ideas get in touch open issues open
PRS on github we'd really encourage that
so at its core nightfall has six sub
protocols so it does mint transfer and
burn off standard years 20 and years to
7:21 token contracts so what a mint does
is it takes your ERC 20 or 721 token and
mints it as an equivalent token
commitment that holds the same value as
a fungible token of ERC 20 or the same
token ID as the near c7 21 these token
commitments
later be used to transfer between
various parties to transact
confidentially as well as anonymously
and Bern lets you do the opposite of
mint which takes this token commitments
and burns them stick burns them to give
you back an equivalent ERC 20 or 721
that is held in escrow it's released on
burn at a very high level nightfall
looks like this and so you if you would
like to do a mint or a transfer or a
burn of a token or a token commitment
you have to generate a proof a Zika
proof of chain and and it's done in your
local server but also it your local
server also holds their private
information that is required to do these
transit proof generation as well but the
off chain server now will have to
interact with something called a shield
contract to make these proofs happen on
chain shield contract acts as an
interface and if it does multiple jobs
but it also talks to various kinds of
contracts most importantly being the ERC
20 in ER c 7 21 standard contracts so
when you'd like to mint or transfer or
burn what you would have to do is create
a proof of chain give it to the shield
contract shield contract will then on
mint escrow your token or on burn
release your token and but it uses these
various functions within shield
contracts in order to do that these
functions in written themselves actually
take the proof that is required along
with the public inputs that is required
to verify this proof and shield contract
will then call a verifier contract and
the verify function within the verifier
contracts to verify these proofs on a
successful verification it adds these
token commitments into the token
commitment cartman's marquetry there are
two important data structures in the
initial contract one being the mercury
that holds a list of all the commitments
created and the other being a nullifier
which holds a list of all the
commitments that have been spent in such
a way that you can't associate a commit
with its nullifier or whichever has been
spent yes so if we take a look deeper
into how the process works for first in
ER C 721 token so first let's suppose
Alice a user of an ER C contract owns a
token T okay and she wants to make this
private she wants to start doing
transactions under zero knowledge so she
will invoke the mint function which
nightfall exposes and that will first
give the she'll contract custody of her
token and Alice will also say here is a
commitment which hides the token hides
the underlying details of the asset and
binds Alice as the owner of that asset
and all people all other observers of
the blockchain will see is just a random
number they won't be able to interpret
thereafter what these commitments matter
so they're after every transfer is
private no one knows who is Sam what to
whom so we get that privacy that
businesses need and crucially the Merkel
tree within the shield contract the
leaves of which hold all these tokens
we've made big so we've given a huge
anon in anonymity set of about four
billion and so that's the 32 deep Merkel
tree so it's really important and again
people can transfer transfer no one
learns who assumed what to whom while
these commitments are being sent within
the shield contract if at some point in
the future someone wants to burn their
token I you make it public again do
something else with it
they can do so they can call the burn
function and it exposes that now Bob
owns T the token similar thing for er C
20 tokens so if you have already
deployed an ER C 20 contract your users
can use a shield contract to make those
tokens private so again Alice owns some
value and she gives the shield contract
custody of that value in tokens it mints
a commitment and because of the non
fungibility of putting making a
commitment it's like putting money in an
envelope so then we have to do similar
to Z cash a to in to our approach where
Alice takes two of her tokens transfers
one of them to a recipient and she gets
the other in change and similarly no one
learns who is sending what to whom in
this process and finally if someone
wants to retrieve their token they can
do so at the end
now there have been a lot of talks on ZK
snark so we're not going to go into much
detail on how they work there was a
really great track yesterday on how they
work and but crucially an ordinary
computation on the EVM you pass inputs
to the computation and it's done on the
EVM all the inputs are public but some
of our inputs we want to be private such
as our secret key what the asset is who
we are and so what we can do is we can
generate a proof and we pass that proof
to the blockchain and the proof just
looks like random gibberish numbers to
outside observers but crucially through
ZK snarks these can be verified as true
on the blockchain and we can verify that
this person does indeed own a token and
has the right to transfer it okay so the
architecture of the nightfall
application itself looks like this the
entire application is dark riced and
it's a microservices based architecture
at a very high level you have a PGA Tour
micro service which acts as an
authentication as well as an
orchestration layer and which in turn
speaks to the downstream micro services
being off trains zkp accounts and
database what option micro service lets
you do is talk to various parties off
chain without no information being
recorded on it such as ATM communication
and the kind of information that you'd
like to transfer off chain is the
private information that you'd like to
keep from being visible on aetherium but
for example a recipient of a token has
to know in order to access his token
commitments so that kind of information
you you communicate off chain using
swarm part of the etherium stack and
accounts micro service lets you create
accounts on the fly
it's um account standard accounts in
order to do mint sprint or transfer as
and when required the database micro
service talks to MongoDB database and it
stores both public and private
information that you're using in your
proof generation and in your
verification for various transactions
and this will be user specific
information that you're storing in
MongoDB I'll talk about zkp in a second
but all of these
all of these micro-services can then be
exposed to whatever sort of front and
interface your life nightfall currently
has a you eat that that you can use that
we use for demonstration purposes
you can also scrape that and integrate
it with an IOT sense or device or an ERP
or another web app as you require going
a bit more detail into zkp and it has
two components that it that it talks to
at its core firstly the Socrates
container Socrates is an incredible tool
that extracts away the generation of
proofs for Zika start it apt it
abstracts away the proving and
verification key generation exporting
verifier and verification of chain and
it is also quite up to date on the
latest happens within a zero knowledge
world as in the various proof systems
that are coming up or the various hashes
that are people using today so we use
Socrates to create these various proofs
of minge transfer and burn and we then
have to send these trends and these
proofs onto the blockchain using a we
use a guest node for this for the moment
and the get node talks to shield
contract and shield content internal
interacts with the other complimentary
contracts that we talked to all of this
logic of course is orchestrated with
node.js controller code which exposes a
REST API that the rest of our micro
services can consume but zkp micro
service by itself can can be used to to
do most of what mints burn and
transferred us today so what next for
nightfall so we have a road map here so
we're looking to build more developer
tools if anyone has any needs or ideas
or they've looked at the nightfall repo
and think something can be made better
please get in touch we're always trying
to make it better
one of our primary goals is to reduce
the cost of private transactions and
uture that's going to talk about
batching so we've made some leaps and
bounds on that we're also going to chip
away at the smart contract logic to
reduce the gas cost there and we're also
going to take a look at the verification
scheme to see if we can use a more gas
efficient one we're also going to look
at making the transact or anonymous
through relays and so if there are any
people knowing
relays please gain touch we look at that
and also we'll look at the trusted setup
so there are some new schemes coming out
at the moment that get rid of the nature
of a trusted setup they're coming
becoming more efficient so okay so one
of these odd more points I've been
working on is prove batching so as you
may know the verification is quite
costly so we developed a prototype to do
to do the bad chain so so the most
generic and practical way to do batching
for the time being is to do it via prove
composition that is you create a pool
that verifies another pool or the many
others post so so it was introduced in
this paper about four carri in data and
but there's a gap between the theory and
the implementation because the problem
is there is a mismatch arithmetic when
you want to do up for that generates a
pool because the arithmetic of
generation of the proof is not the same
as the verification of the pool so in
this paper they have introduced this
cycle of elliptic curve so mainly so
namely m84 mhz sex curve so mostly in
this research branch we know mostly
negative results about this we cannot
find for example cycles whether for
example be a family using in here young
or Freeman family we cannot find
composite order cycles of elliptic
curves so we have only this energy for
energy cycles and and the problem with
these cycle is that so they have
inbreeding degree four and six so that
makes the security in low or so to solve
this problem there are two solutions
whether you have to increase the size of
the film so this is like the variety for
753 an m-80 675 field used by coda so so
this comes with a trader so you have
high security but slow batching all the
other protein powder was introduced in
the XE paper which is maybe you need
only one nicosia
abounded a recursion and then you can
find good security curves but then also
the outer outer curve is is low so there
is some trade trade-offs and so our
protocol we have developed a somewhat in
between so we took the advantage of the
this fast cycle of 74 m86 and we do the
batching over this energy for m86
so as long as you want and then whatever
so you do it off chain so you do not
care much about the security even if it
is not an acceptable security for the
time being but then in the last
composition you we created a new curve
we call pendulum so via Cox pinch method
and we push this last pool that has good
security into the blockchain so this
creates some sort of a graph so we call
the pendulum graph so you have curves in
vertices and edges you have so those
mathematical equation that is the
subgroup order of the one elliptical is
equal to the characteristic field or the
other one and vice versa
so so we we are batching pose so 2 by 2
so we restrict issuers to batch to
submit force on em 86 and then we do
this recursion and so we we find last
off and then we do a final composition
of this pendulum curve that we push into
the blockchain so we've tried to do
everything in so practice so that the
community can you use it so we we've
added some some some nice features into
the parties for instance so everything
is public by the way so we've published
this this morning so for instance in
Socrates now you can you can do
Socrates verify so we have current line
verification in Socrates so we add so we
made so we changed how how Socrates was
built and we we made Socrates generic
over the car so so parties for now
allows you to generate force only on ads
being curved and now you can generate in
amenties for m86 or any other curve that
you have in your back-end so and we've
also developed this gadget of
aggregation so we our work realized also
on on bosoms or credits to Bhutan for
this as well so
we put everything into into Azure
parties and we published ours our repos
but so yeah the problem with that is we
can go mean it for the time being and my
vision is to go maintenance so we are
waiting for the the community decision
on AIP 1962 so if it goes in Istanbul we
can we can have so pre-compile of our
pendulum curve and we can do this on the
minute so and finally
so this batching protocol was developed
in another project called French kiss
and the night zone so this is a private
swap so that relies on DK snacks proof
batching so in in nightfall now you can
have you can do transfer now you can do
transfers in both ways so it is a swap
and you will have three pools so one of
the first transfer is the second or the
other transfer and one matching ZK slack
proof and we aggregate those ripples and
we push to the shield contract only one
one proof that verifies them all so the
the repos are public any contribution is
welcome so here are the links and so I
think that that's it for me thank you
so if you have any questions
[Applause]
you