[Music]
hello everyone um today I'm presenting
fossil which is our inclusionist design
that we're proposing to be implemented
into itan Pro schol via Erp
7805 so you may have expected tomma here
uh who is the lead on the fossil
projects but unfortunately he couldn't
make it so I'm Jillian I'm one of his
teammates at the robust incenters group
at the etherum foundation and and I'll
presenting be presenting our joint work
with to as the lead Franchesco me barnab
Bay Terren who is here as well Jacob and
Jun so first of all I'll give a bit of a
high level introduction to what are
inclusion lists and what are we actually
trying to achieve here so the
inclusionist design philosophy is that
ethereum has access to centralized
agents and decentralized agents and we
want the decentralized agents to have
some inputs into centralized blood
construction so inclusion list really
Leverage The decentralization in the
validator set that we've gten from
proposer Builder separation and it's the
first design of its kind uh to do so uh
and having inclusion list is necessary
to obtain uh the core property of
ethereum which is to provide CH
neutrality CH neutrality we Define here
as any valid and pending transaction
that pays the pervading base fee is
included within the block unless there's
no space
anymore so the basic idea of inclusion
list is that there are some lists of
transactions that constrains how a block
is created and usually you would say
that this list of transactions must be
included in the Block in some way fosil
doesn't change this basic idea it's more
about who creates the list and how is
the list
enforced so what is fosil fosil is forth
Choice enforced inclusion list so the
four Choice enforced part says something
about how it's enforced uh and F allows
multiple validators to provide inputs
into block construction achieving this
core property of uh increasing the
credible neutrality so here you can
think about censorship resistance
whether this is for transactions that
are being censored because of regulatory
reasons for economic reasons or by
chance uh as happens today and then
there are some other design goals which
is robustness of the system we want
fossil to be used and we want it to be
only used to provide these um this
increase incedible neutrality and uh
another design goal is extendability so
we want fil to be very future compatible
um yet we need inclusionist today since
block struction is so centralized so fil
is a recurring architecture that we see
in multiple designs that we're
considering for other um use cases like
pias or other economic
benefits so now I'll go over on a more
specific level of how foso actually
works and how these inclusion list are
created distributed and enforced and
later we'll do a bit of a recap again so
I said that F allows multiple validators
to provide some inputs into block
Construction in this EIP specifically
we're saying that There are 16
validators that are randomly selected
every slot to become inclusion list
committee members uh and what these
committee members do is they each
propose uh a single inclusion list by
themselves and these are then later
aggregated into one complete one so
committee members they observe the mol
and see transactions in whatever way
that they see them and they construct
their local inclusion list which is a
list of transactions that they sign over
uh which is then distributed and each
inclusion list is at most 8 kilobytes
which should be around 20 transactions
on average uh so 20 * 16 gives you 320
average transactions over all of the
fossil inclusion lists uh and a block on
average has about 200 transactions so we
allow uh fossil to be used as like a
block template all transactions in
principle could be included via foso um
with some extra overlap because these
agents might the inclusion of committee
members might not be coordinated agents
so they may choose similar transactions
um so there needs to be some
overlap so now that these agents make
their own inclusion list these inclusion
List have to be created and they need to
go to the proposer who needs to include
them and the testers who enforce them
via the fork choice so first we'll look
at how these inclusion lists are
distributed to the proposer each I
Committee Member distributes their uh
inclusion list over the global topic
this is the the peer-to-peer part of the
network where all participant listen to
uh ATT testers who enforce the inclusion
list which we'll see in a bit uh freeze
their view of the available loal
inclusion list at second n so what they
do is all inclusion list that they had
seen before second n uh they will
enforce and inclusion list that come in
later uh they do not enforce but they
still propagate them to the to the block
producer and this is essential because
this time reference is there to prevent
split view attacks a split view attack
is when an inclusion list Committee
Member is trying to split the view of
the block producer and the attester so
the person who has to act on it and
those who has to enforce it you could
imag that if the testers think that
there are more inclusion lists than the
proposer then the proposer can't adhere
to the rules of the inclusion list
because simply doesn't know what's
available so we give the block producer
three more seconds to act on it uh to
prevent the split view so if the block
producer doesn't have uh inclusion list
at second 9 the attestor can still
propagate it to the block
producer the block also doesn't have to
be entirely rebuilt inclusionist
transactions can be appended to the
block uh meaning that it can be fairly
done fairly quickly
so then on to enforcement so I've hinted
at this already a bit and it's in the
name of course enforced via the fork
Choice um the testers enforce whether
the proposer did indeed adhere to the
inclusion list conditions that were
specified so uh the testers only vote
for the block if the inclusion lists
were indeed adhered and how it works
specifically is the testers have been
listening to the global topic where the
inclusionist have been propagated and
they freeze their View at second n of
the inclusionist that they're going to
enforce first uh and they take the union
of all transactions that they had seen
in these inclusion lists and check
whether any of these transactions was
not included in the execution payload
that that they received so they checked
whether a transaction from the inclusion
list was not in the block if this is the
case they check if the block is full or
not so if the block is full then
obviously you can't include the
transactions anymore so um if if the
tester is happy so the block um contains
all the transactions or the block is
full and then the attester vote for the
block
if the tester is unhappy so the
inclusionist U has more transactions and
the the the execution payload misses a
view then the test does not vote for the
block so the the property that we're
getting at here is if the block producer
does not adhere to the inclusion list
its block will not become canonical
because in testers enforce
it so this is the full fil mechanism we
have 16 validators randomly chosen that
make inclusion list they propagate them
the block producer receives them it
includes all transactions in its block
and the testers uh then enforced that
the block producer did in fact do
this so the core property that we're
trying to get at here is the censorship
resistance property uh and the idea is
that if there's only one honest
inclusionist Committee Member in the
committee it can include the
transactions that are most likely to be
censored by the blood producer uh and
include them uh in its inclusion list
meaning that the blood producer has to
include them in the block if we have a
network observation that there is a
conservative estimate of 6% of solo
stakers then there's a 63% chance that
in this single slot there's at least one
inclusionist Committee Member who's a
solo Staker but again inclusion lists
are not only about regulatory censorship
they're very much about economic
censorship there's been some
observations of Builders strategically
underfilling their blocks perhaps
because they want them to be lighter uh
in terms of the the bandwidth that they
consume uh or maybe perhaps because they
play some games or they simply haven't
seen some transactions so inclusion
lists are here for all of those sorts of
transactions
the idea is that we're boosting the
signal that solar stakers provide uh
while not relying on economic incentives
here because they complicate the
mechanism and it adds a lot of protocol
complexity so now I'll go on to show how
fossils designed to be as robust as
possible and robustness here refers to
robustness against consensus types of
attacks like the um split view attack
and equivocation and it also refers to
execution layer types of attacks so
people using fossil for other reason
forens of resistance but for example as
a vehicle to extract maximum
distractable value
me so first the consensus layer attacks
um we've talked a little bit about the
split view but there in fact there are
two split view attacks to consider first
of all um there's the split view that
inclusionist committee members ensure
that the block producer would have a
worse view of the available inclusion
list than the testers and this is bad
because then the block producer can't
produce a block that becomes chical so
we prevent this by giving the block
producer three extra seconds u in which
the testers have a really Frozen their
view then secondly there's a split view
attack uh that's related to I
equivocation so you could imagine a
Committee Member signing two inclusion
lists and sending one to the block
producer and one to the tester set if it
would have control over that um and how
we prevent any bad things from happening
here is we say it as if um there are two
inclusion list so if an attestor blood
producer receives two inclusion lists
from the same Committee Member then they
do not impact how the block is
constrained at all um so what this means
is that if a block producer receives two
inclusion lists doesn't know how to act
now it knows okay I I do not have to
adhere to this this is a weird case it
should not be happening and the testers
also know this so they don't enforce
inclusionist where there are two a
testers have 4 seconds after the block
is produced to receive these inclusion
list so here again we uh prevent the
split view not enforcing any
inclusionist when two are sent uh is a
deliberate decision because um this
should happen either if the node is
configured incorrectly or if it's an
attack and um realistically it has the
same impacts as someone sending no
inclusion list so if you said no
inclusion list no inclusion is enforced
if you send two also no is enforced and
the other inclusion list from the other
committee members are still enforced of
course so then there's transaction inv
validation so transactions in the
inclusion list may be invalid at the
time that the inclusionist Committee
Member propagated them towards that the
block producer must include them there
there are two reasons for this
potentially the inclusionist Committee
Member doesn't know the right head of
the chain so it's building on some other
head uh and the second reason is that
the block producer could include
transactions before the transactions
from the inclusion list so the the
inclusive Committee Member cannot
possibly know what the block producer is
going to do since it acts before so
transactions could be invalid to prevent
free data availability which is a a
problem that arose with a previous uh
inclusionist EIP uh a tester's only
check where a transaction could have
been validly appended to the execution
payload so if a transaction is invalid
then clearly it cannot be validly
appended similar to how if a block is
full a transaction cannot be validly
appended because it because it would
raise the gas limit over the maximum uh
and inclusion lists are never written on
chain um it's only the execution payload
that's written on change so this
prevents free date availability as
well then if there can be invalid
transactions in the inclusion list this
may lead to some games uh that you might
think of so it could be that uh someone
knows that it will make the block at
second 12 uh and it tries to flood the
mle with transactions that it will
invalidate in its block later on meaning
that um it floods uh the inclusion list
of transactions that will be invalidated
therefore not really constraining its
block uh too much so first of all this
is a difficult attack to pull off in
practice because usually the MEF boost
Builders only know that they're the
Builder close to the 12C line or maybe
even past that uh but we have like a
defense and debt strategy here uh to
prevent this so how we do it is
inclusion list proposers are free to
choose whatever inclusion rule that they
like so they're free to construct their
inclusion list however they like and
clients can be um an agent for them so
potentially one client prefers uh the
way of creating inclusionist By Priority
fee others may prefer to make incl
inclusion list based on how long
transactions have been pending in the
mle and others might use some sort of
puristic that they think is most
valuable to create inclusion list if
people create inclusionist in various
different ways it's more difficult to
attack them so if for example one client
incluses inclusionist mechanism that
says I want to make my list based on how
long transactions have been in a mempo
uh just ordered youd need to flood the
mempo long before that's uh long before
your slot making it potentially a lot
harder uh to know that you can
invalidate them so this is really a
defense and debt strategy uh it's
unlikely that this will happen the G is
quite limited uh but even then uh we're
trying to prevent it
so then um you could think of commitment
ATT taxs so an inclusion list is some
way to constrain the value that a block
producer could um extract so inclusion
list Committee Member could say um if
you pay me then I include something in
this block or if you don't pay me or
sorry if you pay me then I exclude
something from my inclusion list so the
latter is an extortion attack the first
is an inclusion attack and this is
mainly a worry uh if there's only one uh
Committee Member we try to prevent this
by having multiple Comm committee
members making it uh economically less
less important uh and second most less
likely so then uh taking commitments
attached to the extreme you could think
of fossil as uh a vehicle for meev but
we try to prove that this is incorrect
uh we do this via a concept that we call
unability so the inclusion list cannot
be crowded out by other users uh than
simply providing this censorship
resistance property so we don't want
inclusionist proposers to sell their
rights to make Invision list we argue
that fossil is robust against these
sorts of Mev boost like markets that you
might think uh arise if um if if you
would believe that um it's valuable to
sell inclusionist proposing rates we say
that fossil is not very useful for this
because there are no ordering guarantees
inclusionist doesn't tell you where in
the block your transaction lands there
is no private order flow possible
because any inclusion list is publicly
propagated over the network in order for
it to be enforced there are multiple
inclusionist proposal which prevents
some of the inclusion and extortion
attacks that we talked about briefly uh
and the inclusionist created 3 seconds
before the block producer acts so the
block producer has more information
about the external states of the world
than those who make the inclusionist
have and this means that no individual
inclusionist proposer has the right to
include order or exclude transactions
which is like the canonical definition
of
me so fosil is specifically designed to
be as robust as possible against meev
markets for inclusionist proposing rats
second is extendability and here uh we
argue that foso is a great step in the
right direction we feel that it's very
necessary to have some form of
inclusionist today since there are only
two Builders uh and we see that fos of
recurring architecture in different uh
products that we're trying that I guess
not products uh erps that we're in
imagining um and so here I'll present
two possible extensions you shouldn't
take these as part of fossil because
they're not in the Erp but there are
things that could be built on fosil
without changing the underlying
architecture so first is making some
transaction fee mechanism to incentivize
sensorship resistance so the design
philosophy behind fossil is to boost the
value or boost the signal of those that
already provide sensor resistance to
ethereum uh in a way that's doesn't cost
them anything but it doesn't gain them
anything either potentially for some use
cases you want these inclusionist
committee members to actually gain
something uh from from providing this
resistance service and what you could
think here is an Erp 1459 like mechanism
where the priority fees are given to
those who create the inclusion list um
potentially subject to how much they
contributed to individual transactions
being
included the general idea is to make it
a lot more expensive to sensor
transactions uh you could do this via
this transaction fee mechanism and you
could also change the way that tips work
in ethereum potentially by having
separate tips for uh inclusion list
inclusion and block inclusion or having
a conditional uh tip that was
popularized by Elijah Fox Mann and
mpai and then secondly we're looking at
fossil for blobes so Erp 7805 currently
doesn't support blobes although it could
with some small changes potentially but
then uh but taking it a step further and
looking at full data availability
sampling um enforcing inclusion is
becomes a bit more difficult because
those who enforce it need to know that
all of the data was indeed available
they need to know that the block could
have included all of these transactions
so then we could extend fil with some
extra condition where the testers have a
good view of whether the data is
available or not to again prevent split
view types of attach the important thing
here is that this fully builds upon the
architecture that we're proposing within
fosil um so fosil is very future
compatible fil architecture is basis for
many more extensions these are just two
examples but you could go crazy with
this and um I think it's a very
interesting design space so it's a
summarize also allows 16 validators to
contribute to blood construction which
is currently very centralized and mostly
in the hands of two Builders the main
goal is to increase the censal
resistance of ethereum right now and the
cyles are to provide robustness against
consensus layer and execution layer
attacks consensus layer attacks again
being the equivocation split view
execution layer attacks being being
crowded out by me types of markets and
the second side goal would be to be very
extendable so we want fossil to be
future compat ible and unlock a new
field for ethereum that we cannot
imagine now so the next steps are Erp
7805 is available if you're interested
please scan the QR code uh and v through
it we're trying to move towards
implementation in clients and my call to
action to you is that please reach out
to us if you have any questions about
fil if you think that fosil could be
used as a vehicle for me so this is the
thing that we're explicitly designing
against uh and if you think that you'd
like to use fossil uh on your layer to
to provide censorship resistance
there so that was it thank you very much
uh and I'll be open to any
[Music]
questions thank you and uh also big
apologies for um calling out the wrong
name um so this is Julian marah from
robot incentive group at the EF um so
let's get into the Q&A um julan please U
maybe oh yeah yeah um so the first
question the I committee introduces for
the first time a duty for validators
that require mempo access are there any
concerns with this yeah that's an
interesting question so um currently in
ethereum validators need to have access
to the menol anyway because sometimes
they um in principle from the etherum
protocol they they are asked to
construct blocks most of them Outsource
this vmf boost but currently validators
have access to the mle uh so now we're
introducing uh some way that this is
necessary I guess even if there's a very
strict reason why you don't want to have
access you could also just propose an
empty inclusion list and then again we
rely on that there's at least one person
willing to make an inclusion list um I
think this shouldn't be a problem
validators if they want they can run a
version of the mle that's well suited
for them um yeah so I I don't think this
should be a big
problem next question uh how does the
validator access the mempo and how does
it select transactions yeah so um I'm
not sure if this is like more of a a Dev
side of question or rearch question uh
coming from the research side I'll
answer it as a as a research question I
guess so how does it select transactions
um this could be to maximize some some
objective function that they have for
themselves uh maybe they want to include
transactions because they they think
that regulatory censorship is very bad
or maybe they want to include
transactions because they don't want uh
people to mess with how their favorite
application works or whatever for so for
economic reasons um in principle
inclusionist committee members are free
to construct their inclusionist as they
like um and since there are no rewards
for this um there's no reason why you
wouldn't for example order and buy
priority fee um on the de side um
potentially like catches later teren is
here as well um yeah I think that will
be better to do
later right uh next question will there
be PBS style Marketplace for uh forming
for inclusion lists it seems to be just
another block space consumption design
from that perspective yeah um so we're
very aware of this and fossil is
designed explicitly to not uh Foster
such a such a market for outsourcing
some key observations here are that meev
boost relies on economies of skill there
are high barriers of Entry because of um
because of private order flow and the
economies of skill come because it's
very difficult to construct uh a very
valuable block uh and this makes that
it's individually rational to Outsource
my block construction to some M boost uh
builder for FAL inclusion list this
isn't the case so uh reting inclusion
list is very easy because you just
select transactions based on some heris
that you like uh they're not that big I
mean you could include 12 20 average
size transactions um and you don't have
any ordering guarantees over this so you
can't run sophisticated algorithms to
say what uh value can I extract from
these um from these transactions you
have to commit 3 seconds before the
block producer so doing any Arbitrage is
is basically impossible if it were not
already impossible because of the
ordering there's no private order
because any inclusion list is propagated
publicly otherwise it's not enforced uh
so this makes it that it's not
individually rational to oursource block
um inclusionist um production I guess
the question here is that we're very
convinced of this and we've talked to
builders and Searchers and no one has
come up with a way to use inclusion list
as a vehicle for me if you do find a way
uh I'd be very interested uh in trying
to contradict
that is this proposal compatible with 4
second block times um so the person who
asked this expression probably thought
no but I think is actually very
compatible um the interesting thing
about inclusion list is that the the
timeline um doesn't necessarily depend
on uh the block construction timeline so
when inclusion lists are created and
propagated which is the largest part of
the timeline uh can be completely
parallel to block construction
inclusionists don't have to depend on
the head of the chain uh they could be
made for example uh in principle they
could be made whenever early let's say
three blocks early or something and then
it could still constrain the current
block and since this timeline is very
very easy as in the block producer must
receive them for which it could have a
very long time and the enforcement is
done by the testers it doesn't add like
additional time uh delays that being
said if you make them very far in
advance the inclusionist is more likely
to hold invalid transactions which may
not contribute much to sens
resistance next question how about the
integration of fossil with e PBS and
single slot finality they should be
aligned coordinately so we're proposing
fil separately from epbs or single Sal
finality I think this is important
because I don't see an inherent tension
between these as I explained in the
previous answer the fossil timeline can
be completely parallel from other
timelines um so in my view it's it's
very compatible with both and they don't
have to be uh implemented at the same
time they're proposed as different uh
proposals does it mean transactions from
inclusion list will always be at the
bottom of the block it mean so first of
all transactions aren't necessarily from
inclusion list transactions in the men
pool are seen by inclusion list and then
included in the block but the block
doesn't contain a set a section that's
like this is for inclusion list um so
some transactions that uh you I guess
you could just see them as transactions
in the mle mle transactions currently
usually are not put on the top of block
because this is a very valuable spot
maybe someone can extract some me from
being at the bottom of the block so I'd
expect them somewhere to be in the
middle there are no ordering uh or
properties of like where and block it
should be
should equ equivocating committee
members be slashed so in our design we
don't slash committee members we do this
because there is no reward scheme we
want to incentivize as much
participation as possible so slashing
could be CS because you have a bad not
setup and you accidentally signed
something twice you don't want to do
this uh you want to prevent it um but if
it happens we don't want to penalize for
it slashing in uh equivocating on your
attestations is important for finality
to give some economic weights behind the
transactions that land on chain slashing
for double signing a block already uh is
different it it's not related to
finality it's it's uh but it does cause
a bit more stress on the on the Chain SL
um equiv with your inclusionist doesn't
cause anything it just means that your
inclusionist isn't enforced it's
equivalent to sending no inclusionist so
that's why we don't slash for it right
so unfortunately we have run