there we go the slides are not so
performant but they are safe so I wanted
to give an overview of a theorem to
information security professionals so
what I want to do is sort of show you
where we're looking in the protocol and
the implementations and I'm hoping that
people will be inspired to come along
and perhaps fill in the gaps if you can
see am I missing something or it's just
with the things that we're working on
now and work with the other teams too so
I'm gonna be talking about validator
safety I'm going to be talking about the
phase zero software components how we're
viewing it as I said a set of software
bits so I'm going to be talking so phase
zero it means Casper proof of steak
without shards or execution and
Adrienne's gonna be talking about value
to privacy on the network and the
differential fuzzing work that's been
going on in f2 so I want to talk about
validators as you know they are
replacing the miners as the block
producers so taking them offline will
affect the liveness of the network and
stop new blocks which is very bad so I
want to talk about the two failure modes
of validators so we have these two
different modes this is offline
validates and equivocating validators so
an offline validator is a validator
that's either just simply not connected
to the Internet of the network or
they're on a different minority chain so
from the view of the the majority
canonical chain whether or not they're
just completely offline or whether
they're on a different chain it's
basically the same to us so these
validators they stand to lose in rewards
what they would have what they stand to
lose in penalties what they would have
gained in rewards so they're going to
start sort of leaking out at five
percent
five to ten percent per year this is in
the case where there's only just a
handful of validators if there's enough
validators to prevent finality the
system swaps into this mode where it
starts to quickly eject validators but
this is just so like general individual
case our losses so then the other hand
we have equivocating validator so these
are validators that have produced
conflicting messages so the easiest one
is you know two blocks are the same
height that are different it's a double
vote they violated the protocol they're
going to lose a lot of state quickly
they can get slashed and they're gonna
get it back ejected from the validator
set so these two modes have two
interesting properties the first is that
taking evaluator offline is generally an
unprivileged attack so if you know a bug
that causes a node
expend its resources and doing an auto
service or or perhaps crash then you can
generally do this by just connecting to
it on the on the internet and then
sending in a package and watching packet
and watching it go down whilst on the
other hand making it validator
equivocate should if the software stack
is good require elevated privileges on
the host machine so it requires someone
to have access to the machine which is
running the software of the validator
the reason being is that if a validator
can keep a history of its previously
signed messages it can check these
messages and detect if there's a clean
and equivocation before it signs a new
one so if you imagine the equivocation
detection and the signing is just like
one black box
there should be no message that you do
or don't send to it that can cause it to
equivocate without it being aware of it
beforehand so now I want to move on to
the software components this is how the
researchers and implementers have been
thinking about this system into two
distinct components one is the beacon
node the other is the validator client
so the validator client I'm sorry that
the beacon node is what we know is guest
this is the big piece of software
connects to the p2p network it gets
peers imports blog stub state
transitions verify signatures but
importantly it doesn't sign messages
that is the job of the validator client
so the validator client it connects to
the beacon node and uses it as a source
of truth so he doesn't need to connect
to the internet directly it connects via
the beacon node and then it requests
blocks its duties from the from the
beacon node signs them and then returns
them so this is what we have this
relationship where a bad beacon no can
cause a validator client to be offline
by either sending it nothing or sending
it garbage but it shouldn't be able to
if there's like a sovereign well
maintained validator client the beacon
node should not be able to make it be
slashed so moving on this is a bit of a
networking overview of the two
components here here I have these two
binaries here that are perhaps in the
wrong Linux folders but we'll ignore
that they don't necessarily have to be
two distinct binary they could be the
same thing
but this pattern is what we're seeing
from the majority of clients and ours
included I'll sort of show you why on
the next slide but in the terms of
networks we have the internet over here
which is the untrue
zone so this is where we have anybody
internet we're connecting to peers via
discovery v5 using UDP and then we're
talking to those nodes using a lid p2p
generally over TCP this is where people
can start to you know do denial of
service attacks and this is where we
need to be cautious of this where on the
other hand we have a private network
over here so this is a LAN or a VPN
something we trust and this is where the
validator client connects to the beacon
node via an API I have said TCP here but
it could be anything so the reason that
we have this private network over here
is to isolate the validator client from
the Internet and reduces the tax service
and the people that can get added and I
just have been mentioned here so the two
databases here there's the beacon node
has this is like the big like kind of
gets style level to be a rocks DB
database full of the chain and the
validator client will keep its own
database where it maintains its history
of messages enough so it can't get
slashed and perhaps some private keys
either on disk or on a trestle so this
is what I was mentioning before about
the reason that we've separated the
validator client out it's because it can
talk to multiple beacon nodes so we may
have the case typical pattern would be
valid a client connects to one of them
uses it as the source of truth of the
chain and perhaps it'll when it produces
a blocker attestation it may send it to
a few of them just to ensure that the
that the block gets propagated out to
the network and the validator client can
also maintain a sense of quality of
service of its beacon node so if the
beacon node is not responding or it's
not it's perhaps referencing some other
node to see whether it's blocks are
appearing in the chain if it decides the
quality of service is not good it can
just hop over to another vacant node and
because it's maintained a SATA base and
sign messages it may be offline during
that hop if they're on different chains
but it shouldn't be able to be slashed
so now as my last slide I just want to
go through this is the inside of a
beacon node to the big binary and this
is kind of like a very simple overview
from a security only perspective of
what's going on
so this is where messages may come in
here on the left from the internet and
end up in our database or perhaps we're
doing a response pulling something from
the database and sending it back to the
Internet so the first thing that we see
from the Internet is an
working stack that slip p2p so we're
being cautious here of eclipsed attacks
we'll be you know surround the validator
and give it a minority view of the
network alternatively we have to be
careful here with but we have to be
careful here of validator privacy adren
we'll talk about this and we're also
wary of resource exhaustion here if we
can make the p2p do too much work and
slow us down
we have marshalling where we're encoding
and decoding bytes from the network so
we have a new encoding and decoding
scheme that's simple serialized SS said
it is quite simple and straightforward
but it is new and it uses pointers
they're called offsets so here we need
to be quite careful of our seg faults
and all the interesting things that come
with encoding formats and perhaps on the
higher level here we have a consensus
message that we may intend to import to
our database on the lower level here
we're validating requests that we may
give back to response to someone so the
consensus message validation is is a
very complex piece of software so this
is the implementation of the earth 2.0
specs repository so this the earth 2.0
specs has written optimized for
readability but not for speed of
execution so one of the really important
things that client developers must do is
produce optimized versions of this
specification so we need to be careful
that these optimizations don't cause
consensus Forks you know given the same
blocking state we produce the same post
state so we're paying particular
attention here through fuzzing which
agen we'll talk about we're also very
cautious of resource exhaustion here
perhaps someone sends a block that's
valid but takes a long time to put to
process we want to we want to really
avoid this something else we want to be
particularly careful of is blocks where
it takes us a long time to determine
whether or not it came from a valid
producer so sometimes we have to do work
to figure out who should have produced
the block so we need to be particularly
careful here because if people can make
us do work to figure out who should have
sent it that means anyone can send it to
us so these are attacks that are open to
anyone not just people that are inside
the validator said so this is something
we've been actively working on lately
there's a lot of arithmetic in here
addition subtraction division that can
you know divide by zero or we can have
underflow as overflows
we're also doing a lot of access to
arrays in here where we're rewarding
people so this is where we need to be
very careful of seg faults too and then
finally here we have the request
validation so this is where we've serum
su has a new networking protocol so
during the design we're being quite
cautious to make sure that we don't
allow for requests that may take an
unreasonable amount of time in order to
respond to them or process them
so this is the end of my slides and
we're going to be hearing from Adrienne
about validator privacy and differential
fuzzing yeah so for the rest of this
talk I just wanted to give a very brief
overview of two specific examples of
some etherium some security
considerations in etherium - so
specifically validated privacy and
differential fuzzing so for validated
privacy what our valide is we need to
know what these guys are first which I'm
sure you all know but anyway validators
are aetherium two entities that drive
consensus via staking a theorem and
performing specific tasks in particular
they need to vote on shards and beacon
blocks and at the network layer they
need to produce blocks and they need to
produce attestation x' so that means if
you want to be a validator you need to
have a beacon node that's connected to
the network that actively produces
blocks produces outa stations so I want
to try and kind of give you a high-level
overview of what the actual issue we
have with validator privacy in aetherium
- we're using a protocol to publish and
propagate blocks and annotations on the
network called gossip sub there's
protocol labs I think in about an hour
or giving a deep dive into this
particular protocol but right now I just
want to give a like a very high-level
overview of roughly how it works and and
why there's an issue or a potential
issue or security consideration inside
of that so this is a simple peer-to-peer
network that's what I'm trying to what
I'm trying to show here in this diagram
each of the circles are beacon nodes the
direct lines or the solid lines between
those the direct connections physical
connections IP IP TCP connections if you
want between the nodes and you can
consider this as a very rough aetherium
to peer-to-peer network so
of all the nodes in the network there's
a subset of nodes which are validator
nodes what I mean by a validator node is
a beacon node that has a validator
client attached to it and they're the
ones that are producing blocks are
attestations when we publish a block or
an attestation on the network let's
consider this validator node in the
middle when we want when he wants to he
or she wants to produce a block on the
network it uses gossip sub the way that
this works so publisher block is you
select a subset of your connected peers
and you send them the block intern they
do the same thing in turn they do the
same thing and the block or attestation
gets propagated across the network such
that the entire network receives the
block okay so what's the issue with this
the issue is that the first people you
initially connect to what happens if one
of them is malicious they have a direct
connection to you so they know what your
IP address is if you're a validator
client on the network in practice and
malicious actor was actually going to
release or deploy a whole range of these
nodes and through timing analysis they
can actually work out who were the
validators specifically their IP
addresses on the network so assuming
that you can perform this attack you can
essentially collect the IP addresses or
the physical addresses of all the
validators on the network so why is this
an issue so it's an issue for a number
of reasons the first one is that you if
you know a specific valid a as IP
address you can target that computer and
you can das it you can perform an
eclipse attack for example which
segregates it from the network a
validator that's segregated from the
network can't perform its task that's
required to do and therefore it's valid
it there that will lose their stake so
what that means in practice if someone
comes along and says that you look fat
in a pair of jeans you go right oh I'm
gonna find your IP address you segregate
them from the network and they lose
their stake as punishment a more a more
severe attack and sophisticated hackers
if you if you know all the Valladares IP
addresses on the network you perform a
large-scale attack on a majority of
those Valadez and you kick a majority of
holidays off the network so that they
cannot perform their tasks if you do
that you can prevent or delay chain
finalization because the majority of
holidays aren't finalizing or agreeing
on blocks you can amplify validate a
loss because if a large number of valid
a's are disconnected from the network at
the same time it amplifies the amount of
stake that
and you can increase your own rewards by
removing competing valide so it gives
you some incentive to perform these
attacks so this is an active research
topic in aetherium too at the moment so
we don't have a specific solution is
what we're actually going to use but
there have been some proposed solutions
so some ideas are that we can run a set
of backup dos Harden nodes so what that
means is that if you are running a
validator client with a beaker node in
you publishing blocks and access
stations and you find that they're not
being received on the network you can
point your validator client to one of
these hardened backup
dos hardened beacon nodes or beacons
yeah beacon nodes which will then
propagate it for you another solution is
that for all validator nodes you could
probably put them behind tor ITP or
mixed net switch network layer kind of
infrastructures which which master IP
address but there's there's some latency
issues with this
there has been some analysis about how
bad this is handle is an attestation
aggregation strategy which has been
proposed by Pegasus firm consensus
they're also dealing with this problem
so if you're interested in this kind of
thing I suggest having a look through
some of their research papers I'll have
some references afterwards another
interesting idea is adding dandelion
inside gossip sub so again gossip sub is
our message propagation system dandelion
is an anonymization framework for
anonymizing Bitcoin transactions on the
Bitcoin network and I just want to give
a rough overview of how that might work
you know in our gossip sub network or
what has currently been suggested
so with dandelion there's an initial
phase so instead of us when we want to
produce a block or publisher block
across the network we don't use gossip
sub immediately we route it through a
few peers first and then those peers on
our behalf will propagate it via gossip
sub this is a stochastic process so
there's a random number of nodes that it
gets routed through so as a very rough
overview of how this works let's
consider the same a validator know that
wants to produce this that publish the
same block if we have dandelion in it
the first and anonymizing phases we
route it through two adjacent peers we
choose them each of those peers then for
example flip a coin and they flip a coin
as to whether they are going to
propagate it by a Gauss
so on behalf on or forwarded on to
another block so the first P let's say
the one at the bottom he's flipped a
coin and he is going to propagate it
across the network the top one flips the
coin and finds out I'm not actually
going to propagate it I'm going to pass
the block on to somebody else to then
propagated via gossip sub so those two
peers then do the same coin flip and
they find out that they're also going to
propagate by gossip sub so we now have
three nodes that are going to propagate
via gossip sub which just does the exact
same process as what we did earlier
propagates across the network so in this
example or in this scenario we find that
the blue peers are the ones that are the
first ones that have received it via the
gossip side messages and to from their
perspective it looks like that these
three nodes that decided it are the
source nodes for each of the gray nodes
that receive the message they're unsure
about which the source was because the
packet they received could have either
been the source or just another peer
that has just flipped the coin in is
propagated on behalf of somebody else so
this is the rough idea of anonymizing
the validator client source inside of
gossip sub again this is an active
research topic that we haven't decided
on what we're doing there's I encourage
anybody that's interested in in this
kind of a problem to look at the online
discussions that we're having at the
moment or to contact us afterwards or
just have a chat because there's some
interesting problems that we should we
should address here so here are some
references to have a look at further
details as I only have time to just very
hand wavy kind of go over this so
secondly I want to talk about
differential fuzzing differential
fuzzing is a project that Sigma Prime
has recently adopted in an attempt to
security harden all aetherium clients
perform a net so let me explain what
differential fuzzing is by firstly
explaining what fuzzing is fuzzing is a
security analysis tool used to find
abnormal behavior in software so if we
consider an arbitrary program for
example a rust as I said crate you can
think of this as just an arbitrary
function that has a set of inputs and a
set of outputs fuzzer generates
arbitrary data puts it in as inputs and
verifies that the outputs are what you
expect or if you have something explode
then you know something's wrong with
your code
if you actually have the source code you
can do something called guided fuzzing
which allows the fuzzer to instrument
the source code and mutate the input
functions such that it maximizes the
code execution paths of your function so
you can maximally check that your code
does what it expects and you try and
find these bugs so how does this relate
to a theorem to in aetherium to there's
a whole range of clients over a variety
of different programming languages each
of the clients have implemented the
consensus logic their own way and if
they're so there is a chance that any of
these clients given a set of inputs
could produce an output that is
different to another client and this is
bad because if we run this on a network
and a malicious actor knew what that
input was and it could segregate one of
the clients from the rest all users that
are using that client on the network
could in principle have a consensus fork
across the network which is something we
really really do not want so the idea is
we want to before we hit main that is to
ensure that all of these clients that
are that have implemented the etherium
to consensus logic implement it in such
a way that all of the inputs are pretty
much every input we can possibly give it
produce the same output amongst all the
clients so we don't get these forking
amongst the clients so specifically the
each of the clients implement a whole
range of functions on the network level
and consensus level in everywhere but
there's the main core consensus things
we really want to test the
state-transition functions there's a
whole heap of functions involved in this
but you can kind of summarize these into
three main functions the state
processing block processing and epoch
processing so these are the main ones we
want to target to ensure that all the
clients conform to so the way this is
done in a single slide very high-level
overview is we have a piece of software
which we call a differential fuzzer it
has plugins that essentially we allows
us to plug in each of the clients more
specifically their state transition
functions and the buzzer itself will
similar to an ordinary files they
generate a whole heap of random inputs
designed for the state transition
functions send them individually to each
of the clients get a response and make
sure all the clients agree on the
response if there's a difference then we
know that there's a difference between
the implementations in the clients and
we were going to check
this is something that we are currently
actively developing we still need to
onboard a number of clients and again
anyone that's interested I encourage you
to come and have a chat with us after so
I only had enough time to really just
very highly go over some security
considerations that we have to give you
a rough idea of some of the things that
are going on but this is the end of our
talk so if you're interested in any of
these topics I encourage you to come and
contact Paul or I or anyone else around
thank you
[Applause]
you