today I'll be presenting the tension
between meev and sensitive resistance so
as was mentioned it's slightly
speculative more speculative than I'm
used to this is an idea that we've been
trying to formalize a little uh but it's
turned out to be quite difficult so let
me take you through an introduction and
see uh what your thoughts are at the end
so for this um session I'd like to frame
meev as an aligning values problem m is
the maximum value that some extractor
can extract from building the block uh
and this is some private benefits for
this uh actor and the ethereum protol
has some other um benefit function which
we call the Social benefits and in
principle The Ether protocol aims to
maximize this social benefits but it's
very unaware of anything that happens
outside of it so it doesn't know the
external state of the world and it fully
relies upon this actor the extractor is
an agent uh of the
protocol sensorship resistance is one of
the core values of the social benefit
that that ethereum has you can see it
has either an um a means to an end so
maybe you want to have cens resistance
to obtain some other properties uh for
example being able to have applications
that rely on this sensorship resistance
within real time or you could see it as
the end goal so have sensorship
resistance for the sake of sensorship
resistance whatever way you see it the
ecosystem needs to align the private
benefits which is the m that the
extractor can extract with the social
benefits which is what we as an ethereum
ecosystem want the eer tool to
do so here are some observations on
sensor ship uh without any normative
statements I'd say um so there are three
sorts of sensorship that we see uh
happening possibly is economic
censorship so maybe some attractor wants
to censor a transaction because it can
get more value uh by by doing so uh an
example is multi M that we've seen
earlier today uh or the leading example
that I wanted to use here is if someone
has some loan for example on a and it's
um it's it might get liquidated soon
they want to send a transaction in order
to heal their loan uh but the extractor
sensors this transaction because it
wants the loan to go bad in order so
that it can extract some M from it then
there's accidental censorship and this
may seem very weird how is a transaction
ever accidentally censored but it turns
out that this is actually something that
we observe uh right now so there are
many many messages floating around in a
mempool and sometimes Builders just
simply Miss transactions for whatever
reason that is uh and if we take it to
the limit uh builders in principle want
to keep their block as light weight as
possible so any transaction takes up
bandwidth and especially some
transactions that are very um very heavy
for example blobes take up but lots of
bandwidth if you take it more bandwidth
it means that your your block takes more
time to send to the other uh to the
other nodes meaning that you have to
send it earlier meaning that you can't
delay your block submission as well as
you could if you were to play optimal
timing games so potentially a builder is
is sensoring transactions because it
thinks that it may get more value if it
doesn't include this transaction but but
includes transaction in the future and
this is timing games taking it to the
limit uh a builder may actually miss its
slot uh which means that no transactions
in the slots end up on chain and this is
obviously censorship and then there's
regulatory censorship which is what most
people are probably familiar with is
there's some government that says these
sorts of transactions cannot be included
by this actor and where the actor is the
extractor who is an agent of the Adan
protocol but apparently also has other
constraints uh enforced
opponents so um given that we observe
these sorts of censorship or at least
that we know that these theoretically
exist the conclusion should be that the
values are currently not aligned
aligning private and social uh values is
something that economists have do been
doing for ages uh so there's a lot that
we know about this but within ethereum
we are relatively constrained in what we
can do for example giving um rewards for
it is difficult because it means that we
have to issue tokens and if you issue
tokens it means that possibly there is
some delusion uh that could benefit from
this so the way that we've been doing it
is analogous to regulation kind of uh
and this is our value aligning design
philosophy we do so by creating rules
that constrain how the AER can act
within a a certain
slot so for the for the framing of this
talk we'll use the state transition
function as how NV is attracted so GMA
is a state transition function it's
publicly known the extractor can alter
it um and what it says is which
transaction sorry which state
transitions are valid and which are not
so for example you can't put an invalid
transaction in a state transition
function and obtain a valid State
transition s here is the state of the
previous block which is also publicly
known and T is an ordered list of
transactions that the extractor inserts
into the state transition function to
obtain some S Prime which is the new
state the extractor in principle has
full control over this T and this is the
key part where we'll try to align values
by getting more information about T and
then making an opinionated choice on
what T should be
so if we map uh the states that that you
could enter into uh which is very high
dimensional it contains all of the
account and all of the balances into a
two-dimensional plane with just private
benefits and social benefits you may see
that SAR which would be the optimal
solution that some extractor uh employs
uh should rank very high on private
benefits this is clear because um this
is the objective function of the
extractor there's no objective to
maximize social benefits in principle
but perhaps there is some social benefit
here is relatively low but it could be
higher uh the the values don't
necessarily have to be
underlined the key problem here though
is that ethereum doesn't know what the
social benefit is and what Which social
benefits are possible this is because
ethereum has no knowledge about the
external states of the world except for
the T that was inputed by this extractor
and since this extractor doesn't have
the same values um it can't really know
what the social benefits are so on a
high level the idea of the current ways
to to increase C resistance is by first
of all making this more legible so you
could think of for example having
multiple inputs into t uh and not
necessarily acting up on it uh just
making it more legible in the first
place so the red part here is some State
transitions that are very undesirable
from the social benefit uh point of view
the orange part is maybe more desirable
the green part is good and the dark
green part is with ethereum views as the
best this slide is supposed to show that
uh making things legible doesn't always
mean that it's perfect you can see that
the dark green parts for example has the
same social benefit as some parts above
and under it uh yet ethereum the
protocol might think that these are
better uh purely because it's
constrained in the knowledge that it has
about the external
world one way that we then want to try
to align these values is by imposing
some constraints so you could think as
ethereum saying okay we've seen now some
of these um these possible states of the
world uh and we for sure do not want you
to go into this red and this Orange area
and maybe we we're not so careful and we
cut off some of the green area as well
it's very hard to make constraints that
are uh binding at the exact points that
we want uh and achieve the right goals
and you can see as well that's in this
in this very stylized example I must say
there's a straight line it's difficult
to make uh constraints that are more
bounded around for example circles or um
that have more nuances uh because if
theorum has to remain very neutral so um
it it cannot it can only cut off um
parts of the p mble states that are
obviously bad and cutting us parts of
the state that are potentially good in
some future would be uh bad for
neutrality so now I'll go through some
case studies the first one is inclusion
lists we have an Erp out for fossil
which is Erp 7805 which is our inclusion
list design the high uh the high level
design philosophy behind inclusion list
is that we allow uh the most
decentralized sets of participants that
has some input into centralized block
construction uh and the idea is that the
include shouldn't be able to attract any
any me so uh we do this because it kind
of aligns the private benefits and the
social benefits of the inclusionist
Creator and of the interian protocol if
the inclusionist Creator were able to
exract me then it would probably do so
and we observe that M leads to some
centralization uh and makes it difficult
to ensure that we don't have these sorts
of economic accidental or regulatory
censorship so the goal of inclusion list
is to increase the chain neutrality and
we do this by having some list of
transaction that constrains how the
execution payload is
created and this gets us at the notion
of unability which is one of the main
points of the talk unability is um is
something that we're trying to explore
more uh and it informal definition would
be that the inclusion list creates more
value for the inclusion list Creator if
used as intended it's very related to
incen of compatibility but incen of
compatibility assumes that you know
exactly what point you want to go
through and ether protol again has very
limited knowledge of the world and it
wants to be very neutral so it may it
may prefer to be neutral over getting
perfect in sense of compatibility it
just doesn't want some very obviously
dominated things to happen for example
using the inclusion list for me
extraction and maybe less obviously so
using it for pre- confirmations which is
that the inclusion list Creator tells
someone okay if you're in my inclusion
list you're guaranteed to be in the
block uh and you should pay me some fee
for this we don't want this to happen
because we believe that if these sorts
of markets pop up then we might go into
a similar setting as the MEF boo light
markets that we see for blood production
uh which would lead to centralization
and defeat the goals of censorship
resistance so the idea is that
inclusionist must be minimally invasive
such that the intended constraints are
achieved uh otherwise the private
benefits of inclusion list May uh differ
from the social benefits and if the
private benefits of different
inclusionist creators differ a lot uh
then it will lead to centralization with
the Meb like
market and a nice example here in my
mind is unconditional versus conditional
inclusionist unconditional inclusionist
states that if uh all transactions from
the inclusion list must be included in
the block regardless of whether the
block is full and conditional inclusion
list states that all transactions must
be included unless the block is full you
may intuitively think that unconditional
inclusion list gives you better
inclusion guarantees because any trans
transaction in the inclusion list must
be included within the blook but
actually unability gets at an earlier
notion of what goes into the inclusion
list so if you make inclusionist uh
unconditional meaning that they have
better inclusion guarantees and for
example uh to take the most exch example
you could say that this inclusion list
must be included at the top of the next
block because these transactions were
seen earlier perhaps this is some notion
of fairness whatever way um you could
make this argument that inclusionist
transaction should be included at the
top of the block and this would mean
that creating the inclusionist now
becomes very valuable and now there will
be a market for outsourcing this uh
inclusionist creation which perhaps
going to exactly the same person as the
one that constructed the blood and so we
explicitly want to prevent this uh by
making the inclusionist conditional so I
I would say that the constraint is maybe
more relaxed within conditional but the
way that the constraint is created uh is
is uh is more likely to gain what we
intended as a protocol to
achieve if that makes sense and then the
second case study would be multiple
coner block producers which is a whole
topic these days uh the basic idea is
that there are multiple block producers
producing subblocks simultaneously
instead of inclusion list where the
inclusionist has created sometime before
and I would actually argue that this
sometime before is a is a feature and
not a bud because precisely uh the
arguments that I'll show here is that uh
multiple tutor blood producers relies
upon some sophisticated parties whereas
inclusionist does not Foster the same
environment so the goal of multiple
concurrent block producers would be to
prevent economic censorship the idea is
that if we prevent uh transactions that
are sensored for some adverse selection
reason so transactions uh that need to
be very timely uh where there's for
example like high frequency trading
types of ideas then we can achieve a new
set of applications that we haven't been
able to realize today an example of M
mulp Block producers is mackenstein
which is the proposal from barnab and
Mike which means that one person creates
a top of block and the other person
creates the rest of block and another
example is braid which is proposed by
matnik enco which is a deterministic
merger of K chains where each payload is
merged deterministically According to
some pred
ordering
rule how this scores on the unability
table is is very speculative I say CU we
don't know that much about MP blood
producers yet but to me it sounds clear
that mcbp since it's specifically there
for the gain censal resistance for
transactions that are very meev
sensitive so these are the high
frequency trading transactions that may
suffer adverse selection if they were
put into the inclusion list where it
takes a little bit of time for them to
get included it would allow any blood
producer to attract equally well this is
basically one of the designed goals of
multiple block producers this means that
these partial blocks are a vehicle for
me and you can't expect uh a large uh
unsophisticated and geographically
decentralized set of participants to
have competitive private valuations for
these property rights of making these
partial blocks that carry me similar to
how we see now in Mev boost that there
are only two Builders who are very good
at this there are returns to skill of
being um a blood producer in mcbp which
means that my marginal benefits of
gaining an extra seat in these K consec
in these K parallel chains increases
with the amount of seats that I already
have and there returns to sophistication
so it's not easy to build these Bloods
even when blood building is constrained
it doesn't mean that blood building is
simple they definitely still returns to
sophistication and there are barriers to
entry which we now currently know mainly
in the form of private order
flow so that's why uh most po block
producers in my mind depends on a test
of proposer separation
and multiple blood producers is very
crowd so you can't expect uh
decentralized sets of participants who
are unsophisticated and willing to uh
willing en able I guess to contribute to
Central resistance to build partial
blocks so we need to ensure that its
creators are not also the testers
because that would then centralize the
tester set if you put some centralizing
force on a decentralized set of
participants um then the decentralized
set of participants will become
centralized and it's not that magically
the centralized uh property becomes
uh get some decentralization properties
so that's why a tested proposer unlocked
some new block construction pipelines
that are currently not possible you
could for example allocate the attesting
rights to a set of ATT testers uh and
allocate building rights to a set of
Builders
separately so what are some of the
consequences of this unability notion
well this is I think uh a very fun part
to explore and one thing that I've been
thinking about a bit is applications
consuming consensus information so now
assume that we have this uncodable
inclusion list meaning that it's very
unlikely that it will contain me
transaction since it's specifically
designed to not be a vehicle over meev
it's very unlikely to include Arbitrage
transactions therefore so an application
who may see this may treat transactions
that came via the inclusion list
differently from transactions that came
in via the main block it may do so
because it's it's more confident that
transactions from the inclusion list are
uninformed and won't uh take their
liquidity in general if if you're
designing a trading mechan it's
important to distinguish between those
who are very well informed arbitrageur
and those who are not because trading
between two parties is is in general
zero some especially if it's Arbitrage
so if an arbitrager is making money it's
at the cost of some other person in the
static World
Vision so what what you could possibly
do is you could use an asymmetric speed
bump which is something that's been
developed within traditional Finance uh
and what it does is it speed bumps
certain transactions and it doesn't
speed bump others um so the inclusionist
has a natural speed bump and again I
think this is a feature not bud so what
you may say is the inclusionist
transactions they are able to take
liquidity whereas the transactions From
the Block they're able to provide
liquidity taking liquidity is the
Arbitrage path where um providing
liquidity is is not the Arbitrage path
unless you look at for example just in
time liquidity uh but you could set up
the trading rules so that you uh aim
specifically for this meaning that
liquidity providers would face less um
adverse selection meaning that there
would be more liquidity low lower
trading cost for
users seemingly though it seems to be a
bit of a paradox it's um if the exchange
believes that the inclusion list is
uncodable then it's suddenly very
valuable to make the inclusion list
because now your transactions are
treated differently uh so then maybe
inclusion list becomes Crow again but
then if the inclusionist is Crow The
Exchange thinks okay well this is not so
valuable anymore I won't act upon it so
it seems to be kind of like the the SP
man name you know where you're pointing
towards each other and expecting the
other person um to do something or to
remain static I would say though that
this is not a paradox uh because the
application plays a sequential game and
also simultaneous game the application
must commit without regret uh to its
strategy of um of handling transactions
you can't imagine an exchange saying
okay if you send me your transaction I
have no clue what I'll do with it maybe
I'll do this maybe I'll do that so you
need some commitments of how the
exchange rules are set up and so the The
Exchange will only commit to um using
such an asymmetric speed bump if it
believes that the inclusionist would
still be uncodable after its commitment
so it must commit Without Regrets so
they shouldn't be a paradox even when
applications specifically use uncodable
inclusion lists we can still have
uncodable inclusion
lists so some of the um statements that
I'd like to leave off with is that if
cenal resistance gadgets are incredible
then its creators can be decentralized
so if there's no other um use case
that's better than uh using um the uh
censal resistance Gadget specifically
what what it's designed then you may ask
some of the decentralized participants
to create this because it won't
centralize the set
further if the censor resistance Gadget
is cable then its creators will be
centralized this is not a centralization
is not a feature of Market mechanism
although Market mechanisms can change it
a little it's mostly a feature of the
intrinsic property rights it doesn't
matter how you allocate for example
building rights uh especially within the
ether protocol because there can be
secondary markets um it's the fact that
building rights are inherently
sophisticated and there are inherently
barriers to entry so it's not about
proposer Builder separation it's about
the building
rights and finally uncodable sensorship
resistance gadgets seem stable uh so
potentially there's a whole new set of
applications that we can unlock if
applications can consume consensus layer
information so that was it uh I hope you
enjoyed and it's part some conversation
uh and I'd be happy to take any
questions
[Applause]
so does inclusionist with an
inclusionist committee members making
economic sensorship end times more
expensive uh this is a property that's
not currently in fossil fossil relies on
boosting the signal of solo stakers
fossils are uh Erp so we made this
decision because um putting this uh
property that you get an inclusionist
committee makes it n times more
expensive uh um as protocol complexity
we don't think it's warranted at this
point because we see a revealed
preference of people willing and able to
make uh to even take an economic penalty
to provide sensorship resistance getting
this property though is an easy
extension to Fossil um so if it's
necessary we could implement it
easily um yeah just scan the QR code for
anyone who wants to ask any questions
and it'll show up uh yeah we have a
second question uh which I'm going to
read out for the audience joining online
how do you achieve unability of ilil is
that a property enforced by the spec or
achieved through the selection of ilel
creators how to select who creates the I
yeah so uh the design philosophy behind
inclusion list is that you select the
most decentralized sets of participants
to have input into centralized block
construction so unability is not
achieved by the selection um because um
this is again it's it's achieved not by
the market mechanism but it's achieved
by the inherent property rights of
creating this inclusion list and so what
we do is we make the minimally invasive
uh way that inclusion list could be
structured in order to still attain the
Cent resistance properties that we're
looking at so specifically in our Erp uh
there are three seconds between that the
inclusionist last can be committed to
and um the block produced so it's
difficult to include any transactions
like Arbitrage uh because these would be
relevant within the the 3 seconds a May
face adverse selection if you were to do
so secondly there are multiple
inclusionist proposers so there's not
one inclusionist proposer who has
unilateral power over inclusion or or
exclusion which is the general
definition of me there's no private
order flow possible because
inclusionists are broadcasted publicly
uh and they are only enforced if they
are broadcasted publicly um so you can't
get any private transactions into the
block and most importantly inclusionists
don't have any ordering rights so an
inclusion this is just a set of
transactions inclusion sets I guess uh
and it doesn't say anything about the
ordering in the block meaning that uh
there there's there's no me to be
extracted it's the minimally invasive
inclusion is
possible um the next question is do you
think that if we don't uh incentive ILS
with some part of the fees it might lead
to a scenario where everyone creates
empty ILS so um I don't think this is
likely uh why I don't think this is
likely is uh in for we select 16
validators so if there's we we run some
numbers and conservative estimate of
solo stakers is 6% uh which means that
in 63% of SLS there's at least one solo
Staker we currently see that solo
stakers and others are are willing to uh
take some economic penalty to contribute
to censorship resistance we see people
locally building blocks and we see
people setting a Min bid within meth
boost meaning that if the MEF Bo's
revenue is lower than some threshold
I'll just build my block myself so you
see here an economic penalty
inclusionists don't impose any economic
penalty but they also don't gain you
anything given that people are willing
to take an economic penalty and
inclusionist basically give you zero we
expect at least some people willing to
participate if only one of the 16 is
willing to participate we already get
the sensal resistance properties that
we're looking
at um how can IL be unconditional in the
presence of the block gas limit yeah so
this is I think just a a semantics
question unconditional um could I
basically means that the transactions
have to be included regardless of uh
whether the block is for or not you
could make some separated uh gas for it
which was proposed in the ER 7547 which
is M inclusionist CP where there's just
a dedicated amount of gas for the
inclusion list and this usually comes
with u a somewhere in Block property uh
so potentially you could put it at the
bottom of the block uh you could also
say which is more complicated for the
Builder but the transaction just have to
be in the block I don't care where they
must be in there uh this would force the
Builder to reconstruct the block more
often and it would be slightly more
complicated in principle ILS with
unconditional and block ass limits are
not mutually exclusive because you up
the block a limit to accompany the
unconditional
I um if I selection does not take fance
into account could fil make the max EB
increase less effective so actually this
makes it more effective if you don't
take the balance into your account you
you select more people who have lower
balance you probably want to select more
people who have lower balance for
censorship resistance because they are
more likely to be unsophisticated maybe
geographically diverse you you probably
don't want to select coinbase even
though they might contribute to the
economic uh and The Accidental
censorship uh so in my mind uh not
taking balance into account makes fos a
lot more effective
actually wow that was really good talk
and really detailed
um give