Okay so I think we're right on to the on on to that at seven o'clock so we'll just start off
eventually. So hi, everyone. Welcome to Vethri Voice by Zeev,
where we talk about all things Vethri, rollups, app chains, and
similar interests in industries, of course. I am Karthik. I'm
the industrial media manager at Zeev. Today's discussion will be
on the topic of understanding the role of rollups in tackling
MEVs. So our speakers for today are Louis Besenberger, the
product manager of Shutter, and Dr. Ravi Chamriya, who's the
co-founder and CEO of Zeev, of course. Welcome to the Zeev,
Vethri Voice, Louis and Dr. Ravi. This will be one of a one-on-one
podcast session between the leaders of Shutter and Zeev, of
course. Dr. Ravi, please introduce yourself, followed by
Louis' introduction, and then we can start off the discussion.
Hi, everyone. My name is Ravi, I'm the co-founder, CEO of Zeev.
Zeev is a Vethri infrastructure as a service platform and one
of the leading rollup as a service providers today.
We provide dedicated node infrastructure, we provide
action infrastructure like Cosmos SDK or subnets or substrate
parachain-based chains, and as well as, you know, provide
support for infrastructure support for all the different
rollups, whether it be optimistic rollups using OP
Stack or Arbitrum Orbit, or ZK rollups or validity using
hyperchains or polygon CDK. Yep, yeah, Louis, over to you.
Thanks for having me. Thanks for having me. So one question
beforehand, are we sure that people are, that this is the
right time and that people invite, I think, set to in
half an hour, and there's no one joining?
I know we will have people joining eventually because it's
a floating crowd. So in the beginning, for a few minutes, it
is usually this way, but we'll have people joining for
Okay, okay. Good. Okay, so thank you for having me. I'm Louis,
I'm sort of product manager at Brainbot game behind, which is
the original sort of developer and incubator essentially of
shadow network. And yeah, and shadow network is this virtual
encryption DKG, so the symmetry key generation mechanism, which
serves use cases, especially in the in the realm of sort of
base layer neutrality, and, and sensor strip resistance, and in
most, even more generally speaking, information
symmetry. So, so the two main more specific use cases we are
working on currently, or the Shutter DAO is serving or the
Shutter is serving is the one is sort of MEV and supply chain
mempool encryption, where it serves to improve front running
and MEV resistance, especially for L2s. And the other one is
encrypting DAO voting, especially collaborating with partnering with
snapshot, where it is a native sort of integration with snapshot
which encrypts DAO votes ensures information symmetry during the
voting process, helps with sort of vote manipulation and
strategic voting, and encrypts the votes and then decrypts it
then. Yes, so on the L2 side, and on the MEV side, we're
partnering with Fisher with Gnosis chain, but also we
received a builders grant from the OP stack and they're
building sort of in the OP stack ecosystem, together with
mode, which will probably the first OP stack L2, which uses
this. And then we're working with many other awesome partners
in the Volap ecosystem, I would say. Zeev is one of them.
Espresso is another one, which is a sequencer network and, and
handful of others. Yeah, has an overview.
Oh, that's great. And I think this is the first time I'm
coming across Shutter DAO, but I think looks very, very
interesting. So, you know, first, let's talk about
Brainbot, which is the major topic of discussion today. And so
for the benefit of everyone, what exactly is the MEV and why it is
important? And especially when we talk about, we have seen, you
know, different tools in the case of public blockchains, and how
it is important in the case of app chains and rollups.
Yeah, so what is MEV? Yes, MEV is the, the, the value that
maximal, maximal extractable value is the value that people any
sort of intermediary or anyone can extract in unfairly,
essentially, or before someone else, essentially, from
transactions and from front running and arbitrage and other
and other places where essentially, someone can
meddle with the transaction order, or sensor transactions,
and then extract this MEV. So essentially, is profit from, from
manipulating the transaction order, essentially, that that's
sort of MEV, right. And then I think, how we look at it as
sort of, I mean, this is not super exact, but we'd say,
generally speaking, there are two different types of MEV. One
is sort of front running. So really before the transaction,
then one is back running. And this is more sort of the
general, after this transaction, is more about arbitrage and
liquidations. And we think the, the second one, the latter one
is probably not, not actually that bad. So people are
generally speaking fine with it, whereas front running is sort
of clearly, pretty clearly malicious, and it's clearly
harming users, and actually kind of just taking away from
people's trading profit, essentially. And, and it's also
just not intuitive, right? If you are disclosing your trading
intent, and if you are sort of exposing information to the
blockchain, by submitting a transaction, you are expecting,
I think, intuitively, to be benefiting from that
information yourself, right? Because you are, you have that
idea, right, you have that trade idea, for example, you're
not expecting it someone else kind of in flight sees your
transaction, and then is able to benefit from the information
that you provided to the transaction, not only this, but
they also can also even sort of, then exploit you, and
actually kind of even sort of steal money from you in this
way. So it's really unintuitive that is really
unintuitive that that you're exposed to this risk. And we
think people should be able to safely review a
transaction to the chain, right? And that is what the
mempool encryption can do, because then it is encrypted.
And then the neither the the sequencer or the transaction
validator can censor or front run, right? And then and
only afterwards, does it get decrypted and executed. So the
important thing is, while it is, while the transaction
ordering and inclusion is being put in place and finalized,
during that process, it is encrypted, right? And that's
kind of your Yep. For L two, it is interesting, right?
Because for two, there's one is this, this matter of fact
that there are currently some big trusted sequencers as
they the average from an optimum sequence, so who we
generally trust, not to extract front running related MEV,
because, because it wouldn't be in their interest, right?
Because they are controlling this entire platform. And
they're benefiting from the all the trading happening there.
And they're sort of not really interested in harming
the UX. So we see currently this little bit of a so on a
tool, the problem isn't as obvious as it is on L1 today.
However, longer term, we think it could be even an even
worse problem, because of the centralized nature of those
sequences, they're also probably then more
sophisticated. And, and your trust in the way we're
trusting the sequence and not the front run is really
not not how blockchain is supposed to be, right? You're
not, you're not actually supposed to trust those
intermediaries. That's sort of the whole point of public
blockchain is that you are reducing trust assumptions in
those sequences, right? So, so we think this is there's a
risk of this leading to even deeper entrenching of
those, those centralized intermediaries. And then also
again, so centralization vectors, and also censorship
vectors come from the from those tools, right? So that
that's sort of the role of a two MEV, or how this plays
into into that another just maybe minor, but could
actually be a very important aspect is, I think is
essentially the regulatory aspects of being able to
meddle with the transaction order and being able to
front run people is not something that the regulator
is looking upon favorably, we already seeing comments
from from regulators going direction of, wait a
minute, there's a centralized intermediary, which, which
can just meddle with the election order, and can
front run people and front running in the real world,
in this sort of traditional finance world is pretty
much illegal, that is, and it's really frowned upon
and illegal. And we think by having an encrypted man
pool, kind of, then you have this argument of
plausible deniability for the sequencer, the
sequencer can argue, hey, I am not even able to
front run because it's encrypted. So please don't
regulate me as if I would, right? Similar to how
WhatsApp can, can, can plausibly claim that they
can't really be responsible for all the, for all the
content that's happening, all the maybe potentially
malicious content that's happening, because it's
end to end encrypt. So that's another sort of
aspect, I think to L2MEV and encrypted man pools.
Right, no, absolutely. I think front running has
been a challenge. And of course, as you mentioned
illegal in the traditional finance space, also,
because front running means you have biased
information, or you have access to information
which is not available to anyone else in the
market. And you can exploit that information. So
information asymmetry is something which is
considered to be illegal. And I think when we talk
about validator ecosystem, it thrives on that. And
then, you know, so you talked about the
centralized sequencer. And when decentralized
sequencer comes in, then I think the problem will
be pretty much the same, like, like what we see
in the POS networks, right on the public chains.
Yeah, it's pretty much expected that it'll
probably develop in a similar, in a similar
way, exactly. And what I want to say, I think
there is, so why, why would you decentralize a
sequencer, right? Because, because the the
whole point of volips is that, I mean, is you are
creating the sequencer that then is super
efficient and low latency and very high
throughput, a little bit because it is
centralized, right. So, so one of the key
reasons, so I think people who are very quick
to argue that you have to decentralize the
sequencer should really sometimes take a step
back and think about why do they have to
decentralize. And if the answer to it is
censorship resistance or kind of better
dealing with the MEV supply chain, then I
would also recommend to look into sort of
the encrypted mempool, even as a potential
alternative to sequencer decentralization,
because the encrypted mempool gives you the
some of those benefits, right, it gives you
censorship resistance and gives you this
better MEV properties without having to
decentralize. And then in theory, that entire
setup could be lower latency and less
complex, because you're not having to deal
with all the sequential decentralization
stuff, while giving you still giving you
the upsides, the censorship resistance and
the MEV properties that you will have
with the decentralized sequencer setup,
right. So something to consider as an
alternative sequencer decentralization path.
So just to delve a bit deeper into this. So
yes, as far as front running is concerned,
you're absolutely right. I think encrypted
MEV pool solves the challenge. But still,
you know, centralized sequencer means that
there's an absolute control at the roll-up
level to control the sequencer, right. And
there may be, it becomes a single point
of failure. And I think it does not solve
the censorship resistance piece completely
because under the data, it's a single
machine run by an organization. So that
that risk still remains, you know, the
centralization risks. Yeah, there's
other, yeah, definitely, there's other
benefits to decentralization. Yeah,
besides that, and so essentially
availability, right, and so
reliability to having to having multiple
sequences in case one goes down. One
thing that one could think about is
is to have to separate that out
though, right, to have the encrypted
MEV pool, but still have redundancy in
terms of multiple sequencers ready to
jump in once it goes down, right,
that's, that's something that could be
combined. But yeah, I don't want to
argue that all roll-ups should have a
centralized sequencer, not at all. I
think just for some, some roll-ups
that are even, some of the roll-ups
we talked to are, you know, for
and they even themselves, they would
even like out of revenue, from their
revenue perspectives, they would even
say, we're not even that interested in
decentralized sequencer, because we
want to keep all the revenue for
ourselves. It also another could be
Yeah, 100% right. There are different
flavors that we are seeing. So one
bucket is, you know, they want
decentralized because their use
cases, let's say DeFi, right, and
they have moved to a roller because
low transaction, gas fee and higher
transaction throughput. So, but, but
they still want it to be completely
public in nature. And of course,
they want to give a comfort in terms
of sequencer itself. But then, yeah,
there, there are enterprise use
cases where they may have a small
consortium, and they don't require a
decentralized sequencer, it does not
make any sense for them to have it.
And, as you rightly said, and then
you know, in certain cases, initially
they are totally fine with
centralized sequencer. And that's
why what we are seeing today, most
of the L2s in the market today,
they have, they're still running
on centralized sequencer. But
eventually, there has been a lot of
discussions about some of the
existing L2s also opting for
decentralized sequencer. So let's
see, I think, different set of
customers, different requirements,
and the best part is that you
have, there are options for each
of these customers, with both
centralized and decentralized
And then, and then the cool thing,
rollup service platforms being able
to provide this Lego set, right,
where you can then say, I want a
centralized sequencer with this DA
layer, and I want it with the
encrypted mempool, or, or in those
choices. And, and but for some
other, some other rollup, it would
make more sense to have the
decentralized sequencer with or
without the encrypted mempools, I
think that that's going to be
that's very powerful, right, this
Lego set, and then, as you say,
different customer, different needs,
and being able to provide as much
differentiation, by having as much
parameters as possible per rollup,
I think is very powerful. And
I think interesting talking about
Brainbot, I think this is a very
So just to clarify, just to clarify,
Brainbot is sort of the the
developer company originally sort
of having incubated and being a
core developer behind Shatter. The
Shatter is also like fully
separate as a DAO, Shatter DAO 0x36,
you call it, is its own sort of
has its own DAO, truly fully
decentralized DAO with an
on-chain treasury. And Brainbot
is just one sort of part of the
community. But the cool thing is
the community is now really
growing and there's many other
contributors and they're growing,
even also technical developers
who are joining that ecosystem.
So just to clarify on the
difference between Brainbot and
Got it. Got it. Okay, so so the
entire MEB product is under
Got it. Okay. Okay. I think I
think that's good. And so, Louis,
you were also talking about the
initially in the introduction. So
can you provide more details as
to what what it is and how it
works? Yeah, you were talking
about some voting pieces.
Yeah, so it's pretty simple at
the core. So, so the current DAO
voting usually is done during
the voting process, which can
last, you know, several days or
weeks is, is fully open, which
is maybe fine for some use
cases, but in general, it is
sort of leads to information
asymmetry, right? Why? Because
the people who vote later have
less information about the
current, sorry, have more
information about how the vote
is looking like and that they
know how the other people have
voted, right? Then the rest.
So they have this inherent
public vote, in voting, which
is fully public, which can
lead to, you know, strategic
manipulation. Think about sort
of these instances where a
whale comes in really last
minute and sees how the vote
is going on, waits until the
very last minute, and they
know exactly how many tokens
borrow from somewhere to then
be able to sway the vote, kind
of attack it last minute. And
then also, we think just kind
generally speaking, information
symmetry problem. And we think
it is improved if the voting
process is, is encrypted and
is sort of closed. And only
afterwards, do you decrypt
and this is, I mean, this is
works. This is why in real
elections, you do it this
something like a close voting
where, you know, one voter
does not know what the other
has voted. To be honest, sort
of that, there would be a
separate part, right? So the
something that each other
something so afterwards, you
will still be able to see
what people have voted. But
it's just during the vote
during the votes, you don't
see what the actual tally is
currently, but this can be
anonymity as well. Yeah. And
yeah, we're building this
together with snapshot. So
snapshot down, you can just
go to the admin setting and
privacy level, essentially,
which from then on, all the
votes are encrypted and then
automatically the shutter
keepers collaborate, then
always per your vote. And
decrypt for you. So this is
also a nice automation step
don't, people don't have to
go individually to decrypt.
products that you are doing
interesting question. So I
think there are sort of a
competitor, those substitutes,
I would say. So I think, I
think sort of 99% of the, the
actually sort of actually
distributing it differently.
reduces the front-line. So
MEV projects are often then
connected to increase trust
assumptions. Right. So for
have a MEV protected RPC,
that means you're kind of
have that trust assumption
on the RPC provider not to
front-run you, right, which
decentralizes and reduces
stress assumption via this
mechanism. So those are, I
think the biggest group of
sort of what people think
are some, some more, some
competitive solutions in the
which are either also using
especially on other chains.
So there is in the Cosmos
bunch of things happening.
And then also, for example,
threshold encryption, as I
understand built into the
example of how it could also
be done for Ethereum or L2 as
well. And then and then I
would say there are there
are encrypted mempools using
they're using the VDF VDE
timelock encryption type of
functions, which, which can
sort of achieve a similar
end goal as a shutter kind
encryption VDE VDF field,
it's more about trusting the
hardware trust assumptions
it's kind of in a similar
realm there at Intel SGX.
And for shutter, you're more
trusting in the cryptography
and the decentralized keeper
set. So I think maybe both
have probably the place. And
something that's interesting,
I think could be like ways
to combine the two, right, to
even compound the two types
thinking about sort of like,
shutter be fortified? And
then you have to these both
happening. Yeah, but yeah,
but I think sort of on the
encryption, encrypt mempool
Ethereum, I think shutter is
I think very interesting.
So Louis, you recently made an
support for OPstack, and I
think you were mentioning
this at the start of this
call. So can you give us a
bit more about your launch
on or support for OPstack?
And then, you know, what the
subsequent roadmap looked like
roll-up stacks and some of
the other roadmap items you
Yeah, happy, happy to. Yeah,
so, so Pstack was really a
natural fit for us because
they're forward thinking in
terms of MEV, I've always
Optimism DAO gave a grant to
build this initial sort of
feasibility study a couple
finished. And now, and now
we built it out as a test
module for any OPstack chain
submitted a mission request
to the OPDAO, which I think
is a very positive support.
encryption interface and kind
of also this more practical
there on, I think sort of
next step is really the, the
really run this test net and
have people build upon it a
little bit and use our SDK
encryption. And yeah, actually
use it. And then, and then
mainnet, we're hoping to go
ready sort of towards the
end of April. And then from
there on, or even parallel,
I think other rollups could
discussion with most of the
bigger rollups. It's just
first to try it out. So for
committed to trying out the
testnet with us. And then
if it all goes well, also
intros, wants to try this
Gnosis chain. And then, and
support this. And whether
Got it. So right now, when
but still, if let's say we
the rollups stack, which is
not OP, let's say, then in
native integration, but it
mempool, the way we build
level modification. So we
one, you know, we at Zeeve
And I think Shutter was one
our all up journey. And we
this tool is something very,
a few startups, especially
know, different taxes and
well. So no, I think very
interesting talking to you.
to say? And any, any, any
for having me. I think, I
providing optionality and
just having the encrypted
mempool as another module
over other rollups, right.
of requests for proposals
things like building apps
check it out. I think it's
incentivizes people to do