This is Epicenter episode 507 with guest Alex Glucovsky.
Welcome to Epicenter, the show which talks about the
technologies, projects, and people driving decentralization
and the blockchain revolution. I'm Brian Crane and I'm here
with Federica Ernst and today we're gonna speak of Alex
Lukrovsky. He is the Co founder and CEO of
Matter Labs. And Matter Labs is the company
that's building ZK Sync, which is one of the most exciting and
sort of largest ZK roll up technologies that's looking to
scale Ethereum by kind of maintaining all the theorems,
trust, assumptions and bring freedom to people all over the
world. So thanks so much for joining
us, Alex. It's my pleasure.
Thank you for having me. So we had your own like three
years ago and a lot has happened since then, including the ZK
space having gotten lots of traction, lots of interest.
It's still an area that's, you know, hard for a lot of people
to sort of understand and wrap their head around, even people
working crypto. So I thought maybe we can start
with just a very brief recap of what are ZK rollups and why is
ZK such a great technology to scale blockchains?
Absolutely. Let me try it so with
blockchains. You know, like the we really
observe the revolution the the cost.
Starting with Bitcoin and the theory I'm taking it to the next
level smart contacts and all the programmability of money,
interactions value. Like really this is to me, it's
the continuation of the Internet revolution but it's a quantum
lip. It's a jump from Web 2.0 to web
3.0, like adding value to the Internet on transaction level.
The problem is that the very same properties that make things
like the coordinate theory and decentralized blockchains
valuable, they also lead to the difficulties in making it
available to all of people. There are some key things, in my
opinion, that we can distill this value to.
Among them are trustlessness, permissionlessness, openness and
full absolute inclusivity of this networks.
And to achieve that in the blockchain world from the early
days, we embraced the maxima of don't trust, verify.
So essentially everyone has to verify all the transactions, all
of the activity that's happening on chain.
And you can think of blockchains as the social economic systems,
but in the essence, what's happening under the hood, those
are just computing systems. So Ethereum is really Ethereum
started with the narrative of being the world computer.
And it's what the theory really is, if you look at it from the
computer science. So that means everyone has to
redo all of the computations for everyone else, which leads to
quadratic complexity of communication, storage,
computational requirements, and it's just infeasible to bring it
to the work when you are scaling the Internet and adding a value
layer onto the Internet. You can't rerun the computation
of all the other servers of all the other, like redo everything
that everyone else is doing. So like this is a fundamental
limitation which people have tried to solve with different
tradeoffs, always leaving some parts of this value proposition
severely damaged. Like either you give up
decentralization, or you give up security, or you give up some
other important properties. And it was not until zero
knowledge proves fear that we found a fundamental solution to
this. So we came up earlier.
The community came up with some really ingenious ways to make
these trade-offs in a limited way.
We we experimented with things like state channels, payment
channels, plasma which then transitioned into like
optimistic roll ups. All those things were important
steps on this journey. But the ultimate destination is
0 Knowledge Proofs to explain why Zero knowledge Proofs are
specifically like more more precisely succinct 0 knowledge
proofs or Snarks are in fact. They would be better called
proofs of computational integrity.
They allow you to verify arbitrary amount of computation
very cheaply. It doesn't matter how much
original computation you do, how much it would take you to
naively recompute. You can let someone do the hard
work for you and then only present you with a final proof.
Just going to be a short file, like one KB or maybe a few
kilobytes of data. That you can process using very
simple arithmetic operations and come to back to result whether
it's true or false. And the beauty of it, you can
combine various 0 knowledge proofs recursively.
So you can do a lot of computation in parallel and then
verify them, produce a proof that you verified some proofs
and verify these proofs of proofs, and so on.
Until we get to this one single proof, which attests to the
integrity of all the computation that you manage to back in
there. And then you settle this on
something like a theorem, as in global settlement layer, global
layer of consensus, where we all agree, okay, this is the last
state. And this enables us to scale
blockchains basically indefinitely.
And just let's say if I'm to verify all of these proofs, then
I need to know what is being proved though.
So if there's like a huge chain of all kinds of computation, I
still need to know, like you know, all of the things you are
computing, even if I don't have to do the computations.
You don't have to know all of these things.
You only need to commitment like in cryptography.
In the work of blockchains we have a really nice primitive
called commitment. Where you can have a single hash
that is a fingerprint of multiple things, like usually
with packets in a Merkle tree, and you have a lot of the leaves
at the bottom of the Merkle tree.
And then you have 1 hash, the root hash of the sparkle tree,
which will change like which is an unambiguous representation of
all of the data that is committed in this tree.
If you have to change one of the leaves, this hash will
necessarily change, and it's really, really hard.
Computationally infeasible. To find like to fake it, to find
some hash that will correspond to the set that you want.
So in in this regard, you don't have to know all of the things
that's happening computationally there, you only have to know
that whatever you're very fine has a subset which is of
interest to you. So like I I was recently
thinking that the best way to describe zero knowledge proofs
in the blockchain context. Would be to call them not zero
knowledge proofs, but like partial knowledge proofs where
you can only look at things that are important to you but you
still have the full picture and you know that everything else
that you currently don't care about is also still correctly
verified. So a good example of this to
intuitively understand this and you can calibrate me to let me
go deeper into tech or more high level in this interior, but the
intuitive understanding for people out there would be.
Imagine you're getting you're receiving a payment on PayPal or
Venmore or your bank account. You will see that your account
balance has increased. You might want to see who is
this payment coming from and you don't care about all the other
accounts in the world. You still want to be sure that
all the other accounts in your in at least in your bank are
correctly managed, that all the other payments are done with
high integrity. Because if that's not the case.
Maybe your account is increased, but like all the other accounts
are increased by $1 million and so the bank is really insolvent
and it will be will be able to to pay you this money.
When you go to the shop with your credit card you won't be
able to make the payment, so you don't care about those
competitions, but you still want them to be to be to be correct.
So like 0 knowledge proofs would allow you to verify the
integrity of all the other payments without having to care
about them. And the way we implement 0
knowledge proofs in the world of blockchains, the way we apply
them to blockchains today on Ethereum is by building ZK
rollups. And so we can talk about what ZK
ROLLUP actually is. Yes, let's do that.
So in a ZK rollup, who produces the ZK proofs and kind of what's
the mechanism meant to end? Sure.
So ZK Rollup is a layer to scaling solution.
So instead of transacting directly on layer one on the
theorem on the main net itself, we say, let's create a parallel
blockchain that is going to process transactions completely
separately. So we will have someone, some
entity or maybe decentralized by of entities that will accept
transactions and will sequence them in blocks.
We'll call this by. The sequencer can be centralized
run by 1 server. Can be decentralized, run by
consensus of multiple validators.
Doesn't matter. Let's just assume we have this
one blockchain. So the sequencer collects
transactions, back them into blocks, verifies that they're
valid like tries to. If the blocks are invalid, they
won't be able to produce the proofs.
And after the blocks are complete, they do two things.
One is they compute the zero knowledge proofs for all the
transactions in the block, and they produce a final proof that
this block is complete. To make it practical, it
probably requires still recursive proof generation.
So we will split this block into small, many small multiple
chunks. We will produce the proof for
each of the chunk. Maybe we will move heavy
operations into specialized 0 knowledge proofs that are more
efficiently verifiable than generic purpose transactions.
We will produce the proof of that.
Then we will aggregate all these proofs together in one single
proof of the block which contains like all the all the
logic that verifies all the logic that we need.
The transactions were done correctly, that the users
authorized and with signatures, that smart codec logic executed
correctly, and then all the hashes, like, we can basically
all the computation, right? We have this one proof, and then
this proof is submitted on layer one along with the new root hash
for this block. So we don't publish the entire
state, We don't publish all the transactions.
We just say, here's the new state, here's the new commitment
to the state, the new root hash. And here's a proof that this
newer root hash is indeed a valid transition from the
previous root hash, the previous commitment to the state which is
recorded from layer 1, to this new root hash and layer ones.
The smart contract only theorem can actually verify this proof.
Come to conclusion objectively, by nature of pure math
verification that the proof is correct and make the state
transition. And then we need the second
thing. We need to make sure.
That even though the state transition is now valid,
verified on on on layer one, and the transition is made and we
have the new root hash of this state, everyone else knows what
actually happened in this block. It was specifically with regard
to it what what is the new state of all the accounts in the
block. Because if people don't know it,
if external observers, the users or the the other violators don't
know what what what changed in the state.
They will not be able to do anything with it.
Like we will enter a state which is committed on the theory that
no one except for the for whoever made this transition can
actually process. I cannot prove to you that I
have money, I cannot access this money, cannot withdraw, I cannot
transact on this chain. So it would be like a frozen
state. So in order to solve this, we
have to publish something to the users to everyone.
Who wants to observe need to publish some piece of
information that will allow them to reconstruct the state or to
reconstruct the changes that happen from the state from the
previous known state. So there are two ways to do it,
like one is you publish all the transaction inputs and you just
like make it available to everyone and then people can
recompute these transactions and reconstruct the state, which is
something the optimistic roll ups do.
And the second approach is that you publish the actual
differences. For each storage slot that has
been changed in this roll up block, you publish the new state
of the storage slot. Either way, the observer now can
reconstruct the state and they can work with the new block.
But the trick is we have to publish it on some really strong
censorship resistant system. And the most censorship
resistant we have is Ethereum itself.
So we kind of abuse the theory of network to.
Make this data available. We call it the data availability
and the ultimate vision for Ethereum to be the settlement
and the data availability layer for rollups.
Making rollups the center of Ethereum roadmap and really the
place where all or most of the activity on Ethereum will
happen. Cool.
There's a lot to unpack here. Let me maybe recap this.
So basically from a technical point of view, what a ZK rollup
requires is fall forward. So you need regular checkpoints
on L1 that can't revert. You need a proof of correctness
from checkpoint to checkpoint. You need data availability on
L1, either directly by call data or kind of in the dank sharding
world in the site car blobs. The first thing is you need
forced inclusion, and basically that the next checkpoint is only
valid if forced inclusions are provably.
Part of the next checkpoint, right.
So we were kind of we will go into this in just a little bit
and to kind of discuss kind of the recent developments in kind
of the Villadium world and so on to kind of look at the entire
spectrum of kind of shades of L2.
But maybe before that kind of let's quickly talk about the
newly launched CK SYNC 2.0, because that kind of that came
out. Recently.
So now that we kind of know how ZK rollups function
theoretically, let's get down to the meaty part.
So what's new with ZK Sync 2.0? Well, ZK SYNC 2.0, which we call
ZK Sync ERA, is not such a recent development.
We watched it half a year ago, Life in a Minute, and it was the
very first ZK ABM, the very first ZK Rollup.
With generic programmability that could execute contracts
written for solidity insolidity for AVM.
So you could take a contract that works on Ethereum and you
just deploy it and it works out-of-the-box in most cases and
all the tooling works or like not all the tooling works but
like the critical pieces work like the web free API, the
testing, the deploying the access to it like logs.
And everything follows the EVM programming model.
And yes since then we we experienced a lot of growth on
the platform and it's in fact now the the most popular L2 on
Ethereum, we had more transactions in the last 30 days
than any other. L2 was I think 25,000,000
transactions with arbitrary following with 24 and optimism
is 16,000,000 and everyone else way below.
And it's currently the 3rd L2 by TVL and it's also growing,
fluctuating but the D Phi component is growing very
strongly and we have more and more projects launching on ERA.
So era, yeah it's it's a big step for a theory.
It's you know, it's what people were waiting for many years and
and thought it will take many more years to arrive in in the
full form. Let's kind of look at the
taxonomy of different CK roll ups, right?
So basically it's a space that has grown, you know, leaps and
bounds in recent years. And even on this podcast we we
recently interviewed Jody and David from ZKEVM at Polygon.
We spoke with Ellie from Stark with Zack and Joe from Adstech.
But there's also other people we haven't had on the podcast yet,
like the scroll team, the linear team, and so on.
Do you have a taxonomy in your head for these different ZK
rollups? So basically, what kind of
buckets do they fall into? Vitaly came up with this post
introducing different types of ZK Avms.
I'm not sure it will be irrelevant in the midterm, like
it's probably irrelevant. Still relevant now, but we're in
a very early experimentational phase.
In that post he broke it down into essentially degrees of
closeness to the original theorem specification.
Like how how, how far do we deviate from pure native layer
one in the M? Different ZK Avms have like some
of them embrace the byte code native approach, some of them
embrace compiling some, some are somewhere in between.
Some of them are trying to be as close to where one is to
replicate the full blocks of layer one and let storage be
kept in the exactly same format. So look at this.
I think this classification is going to disappear in the short
future because the productivity of 0 knowledge proves is
accelerating, still at the really high pace.
And so the performance characteristics will allow us to
basically verify arbitrary computations we will be able in
the very short term, we will be able to run like Ziki ABM, like
specialized programs compiled from Solidity to a Ziki VM which
is optimal for proving or proof the bytecode native EVM, and
like maybe even have storage proofs for.
For the exact same format as Ethereum or we will be able to
run like native code written in raster C all of that on the same
platform. So you as a builder will have a
choice of what type of computational environment you
want. For some applications you might
want to run bytecode compatible EVM, just there are use cases
like you want to deploy the address.
The contract which has exactly the same addresses as on all the
other AVM chains. So you have no choice but to
deploy native native code there. But for some other cases you
want 100,000 TPS decks optimized for very specific operation.
You can't really do it in. In India you can't do it because
your your sequencer is going to be the bottleneck.
So you will probably write a specialized app specific
application in Rust that just does that.
And you might want to deploy it as a Ziki Roller because you
still want all the benefits of interoperability and security
that you derive from Ziki Roller.
But you will probably not do it in India and you still want a
platform that can that enables you to incorporate all of these
designs. And so I think the real taxonomy
is going to be the like this architecture of interoperability
in the chains. So it's something we recently
came up with the publication of the ZK stack that allows you to
deploy your own chain and the architecture of hyper chains and
hyper bridges that connect them will allow you to have this like
different types of infrastructures deployed in the
interconnected way. So I think that's going to be
like one major classificator, like how different role
ecosystems approach this application specific design and
interpretability between them, like whether or not they can
make it seamless and native. And the second big
classification parameter that I would pick is the treating of
data availability. Do you publish the transaction
inputs or do you publish the state divs?
In what way do we enable volition?
Or is it the single data availability model?
You can only be a ZK rollup or only be a validity.
This is going to be a big important difference.
So those two things I think are much more than the degree of
compatibility, because the compatibility is going to be
solved and. Let's talk about the first
complex of questions 1st and then kind of the validium kind
of spectrum later. So we had LE on recently and he
was very adamant that Zkevms are not performant enough.
And basically, they don't offer basically in terms of kind of
how much computation you can do. He says that Cairo is doing
much, much better. But it sounds like you're saying
that in principle you can kind of mesh these two approaches.
Did I get that right or did I misunderstand?
This is absolutely correct, yes. So I agree with earlier that EVM
is not the most performant platform, especially for
sequential operations. So you can you could construct
an EVM that verifies transactions in parallel, and
then even though the performance of these transactions is not at
the limit of what the current compute is enabling, you kind of
don't care. Because what you care about is
the cost per transaction. And if the cost is much, much
less than the what the user is willing to pay.
And think of like payment applications.
Like if you're or you know like some some important some trading
where your margin is like some a few dollars per transaction but
you're only paying 0.0001 cent, you probably don't care.
Like what you care about is security, you care about
interpretability and you care about time to market.
And if time to market is important, you probably and
you're building smart contracts. You want to tap into a reach
existing ecosystem. You want to be building on
Something like Solidity that has a lot of libraries, a lot of
frameworks, a lot of tooling, a lot of people who know how to
build it. Because it's already hard to
hire Solidity developers. How hard would it be to hire
people who have to learn some specialized language?
So you want to reach broad ecosystem to be building your
stuff on. However, for other applications
for like something that like this 100 KTPS exchange, you
absolutely need the ultimate compute.
You want to like bring it down to you.
Probably maybe you don't even want to run it inside a virtual
machine like no matter if it's Cairo or VM or EVM or whatever.
Maybe you want like really like a bare metal implementation of
your specific roll up that can sell transactions really, really
fast running because all of them are sequential because they are
trading on the same trading pair.
You want to run them as fast as possible what the processor
enables you. So you get to this ultra high
frequency trading with 10s or hundreds of thousands of TPS.
So yes, I believe the future is with this differentiated
spectrum of approach. Cool.
That's very helpful. I want to understand this a
little bit more. So let's say you have to EVM.
Today on Ethereum, right with the EVM, basically there are
some performance limitations. For example, one is because of
the consensus, you have to like propagate the blocks like it
requires certain amount of block time, you can't make them too
massive. Another thing is maybe the kind
of computation of the state and the EVM.
Now we have the ZKV EVM here. What becomes a bottleneck here,
right, because you have a single sequencer that you sent a
transaction to. It's basically the bottleneck,
the speed at which you're able to create the proofs for for all
the transactions. Or I mean first of all how does
the the throughput and scalability of, you know one
single CKVM compared to ether main net and what what are the
bottlenecks there? That's really great question.
So we will have a couple of bottlenecks.
The first intermediate bottleneck is going to be the
speed of your sequencer, the base at which you can accept and
execute transactions and compute the block intermediate, block
results and block hashes. This does not depend on the like
whatever what's your knowledge proofs or fraud proofs you're
using does not depend on data availability.
It's just basic computation and networking and it depends on the
architecture of your chain. Some chains will be
decentralized and so you will have to tap into consensus and
you have to also make sure that your sequencing layer is fast
enough and like your latency is good enough for your
application. And some other chains might even
be completely centralized with a single server that can respond
in like 20 milliseconds time. And for some use cases this like
for this super high frequency trading this would be the case.
They will likely prefer this, but they might still want the
full validity and security derived from Ethereum and open
being not an isolated chain but the part of the bigger ecosystem
with all this rich liquidity. So that's your first bottleneck
and as you can see like the various trade-offs lead to
various different solutions. Your second trade off or
bottleneck is going to be your the data availability, how you
store data availability, how you manage data availability.
If you are a Ziki roll up then you are competing with all the
other roll ups on ethereal ziki and optimistic for the block
space because the block space of Ethereum is limited.
It's kind of a 0 sum game. If some blockchain if some roll
ups will get more data, there will be less data data
availability bandwidth available to other roll ups so which will
lead them just to higher prices for this data bandwidth.
So this is a big problem and the only way to solve it in the
short term to make the throughput really unlimited is
to use external data availability like off chain data
availability. So you will still have Z key
roll ups and maybe every chain should have a part of its
account in on the ZK roll up where all the data is published
on Ethereum and they enjoy high security.
But for the accounts that do not need high security or are
willing to take some risks into account you want to publish data
availability externally with zero knowledge proofs.
It makes a lot of sense. Makes a lot less sense with
optimistic approaches which we can discuss why.
But for for ZKS it works. So if you can go and you have
this kind of elastic extension of data availability bandwidth,
then this bottleneck is going to be solved for you.
And the third bottleneck we have is the actual ability to
generate 0 knowledge proofs. And this is the least of our
problems because the proof generation is they're relatively
cheap and we can do it on very broadly available hardware.
So the we last week we announced an upgrade called Bujum, a new
proof system that is being that's going to be embraced by
Ziggy Singh era. This is a proof system we've
been working on and off for a couple of years is based on the
construction called Redshift which is just a combination of
Plonk and Plonkish arithmetization and Fry
polynomial commitment. And the implementation we have
today only requires 6 to 16 gigabytes of RAM.
Depending on your configuration, you can choose parameters like
let's say 1616 gigabytes of RAM only.
GPU is basically consumer grade hardware.
You can do it on gaming machines, you can do it like on
any cloud provider. They have plenty of GPUs
available for machine learning for other purposes that you can
utilize. So we will be able to prove all
of the world's value transactions with ZK using
something like this. So that is not really a
bottleneck. So data availability and the
sequential throughput or the sequencer throughput are really
two bottlenecks and we can talk about the solutions.
The solution to the sequencer throughput is to have many
chains. There is no alternative to this.
Like we will not be able to handle all of the world's value
transactions on a single monolithic chain because it's
just physically invisible. Like you cannot imagine all of
the world's Internet servers running on a single server or
even on a single data center. Like that doesn't scale.
You need to be able to add more and more on demand.
It also won't work because different no matter what
configuration you take, you're making some trade-offs, latency
versus decentralization. Like if you're decentralized
consensus then you will nature to be able to handle less
throughput and less like. When you say decentralization in
this context, like what are you talking about decentration of
the sequencer? OK.
If you want to decentralize the sequencer as opposed to one, OK,
that makes sense, yeah, yeah. So one validator will be able to
handle like really high load with very low latency.
If you want to have hundreds of validators, then you naturally
have to make the data available to all of them.
You have to reach consensus, which requires at least two
rounds of communication between all of them.
You probably want them to be like broadly geographically
spread, not in the same country, not on the same continent.
So like the communication loop becomes larger, like you're not
getting anywhere, like you will be in the region of like one
second, order of magnitude of one second, maybe half.
Then basically you run something like tenement or something like
that, or correct tenement of hot stuff like you need.
Like even with the newest modification of hot stuff, you
need 2 rounds of consensus, 2 rounds of messaging for the
consensus. Which means you have to like
just send a message twice between different continents.
And you just limited by the speed of light and the speed of
communication and those networks which will determine the latency
of your consensus which you can eliminate if you're using like a
localized data server for centralized sequence.
So those trade-offs are impossible to make like once and
for all one-size-fits-all. So you will need multiple chains
and so the question is how do we incorporate multiple chains in
an architecture where they can still seamlessly, trustlessly
and capital efficiently communicate with each other.
And this is where the hyper chain architecture comes into
play. This is why we've been working
so hard on making this architecture available in the ZK
sync network and we would love to make it available to other
roll ups as well. But unfortunately the way
Ethereum is architected, it's not going to be as seamless
between different roll up ecosystems.
You will be able to pass messages between say Ziki Sync
like one of the Ziki Sync hyper chains and like one of the stock
where Starknet itself or one of the old trees.
So there will be some degree of trustlessness, but it's not
going to be as seamless in terms of assets movement.
To move an asset from one roll up to another you will either
need to use external liquidity or you will have to go through
layer one and actually pass the this asset from one.
Like bridge contract on Ethereum which belongs to Zicky Sing, to
the bridge contract on Ethereum which belongs to some other roll
up which will make a theory layer one itself.
The bottleneck of this bridge which will not really scale for
like we're talking about millions or billions of users.
But within the ecosystem will inside the Zicky Sing hyper
chain network, it will be possible in to arbitrary degree.
So like the way you can imagine, Hyperchange is just like like
you have like domains for e-mail you have Brian at Epicenter or
Gmail or whatever I have like alex@matterla-bs.com you can
send an e-mail from any address on any domain to any other
address on any other domain and you don't have to care about it.
You don't like the communication is the same, you just do one
click and in a few seconds or minutes the message arrives on
the other side and it's end to end encrypted, like you know
it's trustless. How does this work technically?
Because basically one ZK sync chain would have to know the
state of the other chain to actually make this happen,
right? So basically it's kind of like
the old problem of kind of having smartshots and how they
communicate, right? But yes.
So if you want to learn like real technical detail, like deep
technical details on how it works, I highly recommend this
Slosh paper where the Slosh team has done an extensive research
and documented really well how this will work.
But like the high level, yes, the two chains that transact
between each other and need to share need to have access to
each other's state. So this is already possible with
all roll ups on Ethereum. The moment you finalize the
state on one rollup, you can use storage proofs to access the
state of any other rollup. Because you can go, you can
pass. You can imagine that Ethereum
kind of unites all of the states of all the rollups in one huge
merkle tree, where Ethereum state tree is like the top of
this huge merkle tree. So what you do is only one
chain. You commit a message with a
destination of some other chain. And in this message you say here
I like, I am burning let's say 100 ETH on this chain here like
the smart contact takes care of this.
And so like I promise I like, I burn it in favor of this
destination on some other hyper chain within some period of
time. And you make this commitment,
you store it in storage. The other chain can then read
the storage and say, oh, I see that this amount was burn.
And here's a very, very important part.
Because both chains run the exactly same subset of circuits,
the exactly same subset of like cryptographic enforcement of the
rules, I can trust this other chain with a message that for
this commitment that the the this action has actually been
performed, that they actually burned this 108th.
I can trust it blindly because that chain is is like it's
validity is enforced by exactly same circuits as my own chain as
as I as myself, as as I myself as a chain, right.
So like for me, I can trust that chain as much as I can trust
myself. So I can easily min this 108th
on this chain like through some system counter that has access
to like minting. And it's probably going to be
like a part of the of your bridging.
Like your tokens will have to be aware if you either use system
conference for tokens or you use specialized tokens that know
about this functionality can mint this assets and then you
can use this assets natively. So you need to be part of the
same state, you need to have the same circuit so they can trust
each other. And then the third key component
of this architecture is that all of these chains have to share a
single bridge on Ethereum that holds assets for them.
Because if you don't share the same bridge that holds the
assets, then you can kind of like trust the other chain.
You can be sure that they burn some like 100 E and you can mint
it yourself inside your chain. You will never be able to
withdraw this hundred you because they don't belong to you
then. No blocked in your near bridge
on this area. Is is that last one the main
reason why you wouldn't be able to get the same kind of
convenience when it comes to like vision to start net or some
other thing? Precisely, yes.
Like you, you like in order. So like there would be a
question if you can trust Stark NET contracts because it's a
separate system that is managed by entirely different governance
You might like, you know you will have to write your
specialized contract, the custom user contract that says I trust
Starknet maybe other contracts don't but I do trust them.
So like I can believe that this message is real, but then like,
so that's actually the first problem like even if we if we
could manage the the ownership of this contract if this
contract would not be able to persuade the system contract
that we should mint if because the system contract does not
know if Starknet is not compromised by their government.
The system contract basically is able to verify the computation
that's done using specific circuits and starkness as
different circuits, so it like cannot directly verify.
That it's just a different system, not not governed by the
same like upgradeability pattern by the same code.
So like the system the system contract can only trust other
system contracts of trusted origin.
It cannot trust users code because if I can deploy
arbitrary smart contract which says meant me $1 million trust
me bro it's like it's it's honest because it's kind of from
the other chain. The system contract will say you
know like maybe maybe not so it has to be a message that comes
from the other system contract that actually burned this this
100 feet. But yes, but then the second
part is is is you're right. Like even if we if we solve that
we like on the system level we make an agreement.
We say like the kissing trusts darkness.
Darkness trusts the kissing. We still cannot pass the assets
because they are locked in different underlying bridge
conference. How does the hyper chain know
which other chains are in the hyper chain architecture and to
trust them right? I mean they kind of need a Hyper
chain ID that kind of says I am Hyper chain 72.
You can trust me, but is there any way of kind of faking that
or do you need a centralized register?
How do you go about that? You will have a smart contact on
Ethereum that will hold the Merkle tree of the hyperchange.
Let's call it the shared prover or the shared verifier in this
Merkle tree. All the state changes will only
be authorized if they are coming from a trusted hyper chain.
And by trusted I mean like from a hyper chain with the circuits
that the prover contract knows. Because the prover contracts are
always verifies the proofs against some verification keys.
Like when you verify a proof you need to know what you verify you
don't like. You need to have this commitment
to the circuits which we call the verification key.
It's a small key, but it unambiguously identifies certain
cryptographic program. One circuit always produces one
specific verification. So this breach contract will
have like one single verification key for all the
hyper chains. Any hyper chain that wants to
make a state position must support this verification, which
means that they are enforcing all the rules the way we all
agree that we all enforce. And this is also how you make
sure that the the tokens on each hyper chain actually
commensurate, right? Because basically I could be
evil hyper chain and could say, look I have 100 ETH, I will burn
it, I will reissue it on hyper chain 19 and then basically I
burn some sort of fake ether and kind of get really ether on
hyper chain 19. Absolutely correct.
So they have to share the circuits, maybe not all the
circuits, the hyper chains are actually highly customizable,
they are, they are fully sovereign, you can choose your
sequence, you can choose your data availability model, you can
choose your extensions whatever you want.
But there must be a some really small subset of circuits that
enforce this integrity, that enforce this the the asset
treasury that like really everyone cannot mess with anyone
else's assets. So this part must be common and
this is going to be the critical part to verify in the state
transitions. I think I think I get get that
part. Now let's maybe back up a little
kind of to the four requirements of AZK rollup.
So as we as we talked about you kind of you need you need
regular checkpoints that kind of rebut you need a proof between
checkpoint to checkpoint then you need data availability and
the reason why you need data availability is so that.
If there is no data availability, there's like some
sort of secret transaction that I can kind of include in the
block. Other people can no longer
calculate the current state of the block and can no longer
build on it, and thereby I can effectively break it, right?
I can. Kind of.
I can't steal ones, yeah, but I can.
I can make sure that no one else can do anything because I have
the secret transaction. This is why you need the data
availability. There are villadiums.
Which are basically ZK rollups without data availability and
this is kind of the direction that cello is going as well as
Polygon and so on. How do you think about this
spectrum of L tuners? And do you think maybe there's
even a way of kind of doing data availability optimistically so
that basically don't actually because basically if you look at
how much you spend? On the checkpoints versus on the
data availability, maybe you can give us the exact numbers for ZK
sync, but almost everything actually is is for data
availability rather than the checkpoints, right?
Absolutely correct. So I'll start with this last
question. Indeed the absolute majority of
the costs is going towards data availability from like we
currently have 3050 sales per transaction depending on
fluctuating gas prices Ethereum across all the roll ups.
The bulk of this cost is going to the table ability and it's
not going to change even after AP4844 which will hopefully
bring the costs down by a factor of 10 X make 20X.
But like the even the remaining one cent is going to be the
majority of the cost because the zero knowledge proofs
computation part is tiny. It's like 0.0 something like
it's hard to calculate exactly because there are many
components in the system like it's really like you can
benchmark something in vacuum but it's in detachment from the
real system. It's not going to be indicative,
but like we know for sure it's like a so correct.
The data availability is important, so if you want to
lower the cost you have to seek this external data availability
solutions like the building something like volidiums or
volitions talk about that in a second.
The the like let's reason about their L Two's Ness.
I think we need a good definition of what an L2
actually is and I've not seen a strict definition adopted by the
community like we kind of like know it intuitively but but not
precisely. I think a good definition would
be an L2 is a chain that derives its security from underlying
layer. One like security in various
senses, like it would be liveness, could be security of
fonts, retrievability of the fonts eventually and so on.
But you need to derive some security from L1 if you don't
derive security like for some significant security from L1.
So a side chain for example is not an L2 because your security
entirely depends on your set of validators.
They can do whatever they want with your money.
If they collude, they can still, they can freeze whatever.
With ZQ roll up the security is 100% direct from layer one.
You can always guarantee that the users will eventually be
able to withdraw all the funds, no matter what the validators,
if the contracts are immutable, if they don't have the right to
arbitrary change contracts, and of course if there are no box in
the implementation, which is a significant risk, which is not
negligible, like let's assume those two factors for now.
But in this case ZQ Rollup is like ironclad.
Security is exactly the same as the theorem in terms of its
properties. The validium is in between.
All the transactions in validium are enforced by zero knowledge,
proofs and theorem. So it's not possible to make
anything invalid. It's not possible to execute
something not on behalf of the user.
In this sense, it derives a very significant part of its security
from Ethereum. And for some use cases you
really you don't care that much about data availability, you
only care about the correctness of the code.
Like an example of this would be, let's say, online voting.
Let's say that you you're voting like, let's ignore salsish
resistance for now. Let's let's imagine that we have
some like perfect Salish resistance input because maybe
like, you know, like what? Like each party collects their
own votes and then each party submits their like, you know,
like we we have like, you know, blue party and the red party.
Both of them get as many votes as they can from their
respective proponents, and then each of them submits a
transaction on this chain and all you care about is to
calculate the votes correctly. And then you want to publish the
result on chain, but you want to make sure that it's actually
like correctly available on chain to other contacts, not
just to humans. To demonstrate which you could
do off changes generating 0 knowledge proofs, you want to
make it available to contacts. So for this, data availability
is really not important. All you care about in the end is
that the result is correct, right?
The same applies to oracles, like when you do Oracle updates,
you don't care about the state of the Oracle update because you
can discard that. Like if the chain is frozen, who
cares? Like you will be able to make
new Oracle ticks on the new chain when users migrate, right?
But what you care about is that the Oracle updates have been
correctly verified that they're coming from trusted sources,
that the way that averages are computed correctly and so on and
so on, right? So for those use cases, Validium
does not constitute any reduction in security because
you only use security for computation, which it's
perfectly secure. So from this perspective, I
think that Validium is actually like it should deserve to be
called ML2 to some degree. When we talk about the actual,
like real life security, like real world security for the user
assets, it becomes a lot trickier.
It's really hard to reason like we Now we are back to this game,
theoretical a plane where we can imagine that the operator, the
validators of this Villadium chain that locks a lot of like
some billions of dollars of your assets.
They could say, oh you know what, like let's try to
blackmail our users, let's freeze the state and then like
demand ransom. Or maybe they don't freeze the
state. Maybe they are hacked because
the servers that operate the validium have to be online, the
keys have to be on the whole machines.
So maybe there is some like ingenious way to hack the
systems and they compromise the majority of the of the
validators and then the hackers can demand some like it could
potentially become tricky. So I would of course treat
validium accounts always as like significantly less secure than
Ethereum accounts. But then you know, like you
could like the. I think the ideal solution is
the combination of both. When you have something like a
volition system where you as a user can decide for each of your
accounts, do you want it to be stored on Ethereum?
Like on a ZQ roll up with full Ethereum security guarantees but
maybe higher cost of transactions on this account and
for some other account you decide that it should be a valid
unit. Or is the key partner account
where the data availability is secured off chain by some
committee with some economic security.
But you use it as you would use your savings and your current
account. You would keep most of your
assets, most of your savings on the savings account.
Maybe you put them in some default protocols from your roll
up account and you don't touch it every day, the only
transactor rarely on it. So like most of your value is
there and then you move some of this value to your current
account on the on the validium side of of the volition.
Let's say on like you you on Zicky sink it would be called
Zicky Porter. So you put it in Zicky Porter,
maybe you have like your millions of dollars and on that
side and just a few thousand per month to pay for for your daily
needs on the volition side. And so you kind of like you you
you explicitly manage the risks of this exposure and if everyone
else is doing the same, then you have a lot less value locked on
the Validium side of the evolution, but you will have a
lot more transactions, which actually makes a perfect sense
from the from this balanced perspective, right?
Like you will have a lot of cheap transactions, a lot of
trading going on there, a lot of like computational activity like
Oracle updates and arbitrage transactions and so on and so on
happening on the evolution side. Sorry, on the Validium side.
Can I quickly? Kind of.
Question this to a certain extent.
Basically, if you kind of look how say Cello is transitioning
to being an L2, they're not forgoing their validator set,
right? So why a kind of CK sync?
And to be fair, all other L2S have like a centralized
sequencer, which is definitely also an attack vector, right?
The Validiums that kind of we see emerging, they already have
a decentralized validator set. And so basically, there's many
entities that in principle are allowed to kind of build the
blocks. Where do we see the trade off
here? So I mean, obviously if you had
a decentralized sequencer on ZK Sync, this point would kind of
fall, but currently you don't, right?
You can't really compare the two.
So first of all, we are committed to decentralizing the
sequencer. We actively work on this.
We have a prototype which will unveil very soon.
It's running on the hot stuff consensus.
It's going to be fully decentralized as a sequencer.
And what you want to get from the sequence of decentralization
primarily is the resilience and the liveness of your network.
You want to be sure that the network will remain operational,
like for everyday transactions, even if one or multiple parties
are compromised or going down or unavailable.
But the sequencer does not affect the security of your
funds. So you could argue that liveness
is part of security. I will admit that.
But if you put a lot of value in some default applications, yes,
you will be annoyed if it's not available, and you might have
some like opportunity costs for not being able to use it for a
couple of days. But it's nothing compared to the
ability to lose all of your fonts locked in, like in Unis
Lock for example. Right, but the validators can't
steer from you, right? I mean so basically if you have
the ability to kind of run your own full node, you can't be
duped about the state of the chain.
You can never steal funds, you can never steal funds.
Like all you could try to do is like the validators could try to
double, like they can't even do a double span.
Like they can only do some short term faking on chain that will
never finalize on the theory. And if you're if you're making
high value transactions, you always want to wait for the
final find, like for the finality on the theory and for
the checkpoint, but it actually guarantees that this transaction
is final before accepting it. If you're expecting someone for
some of the payment of $1 million, you have to wait for a
You cannot trust the sequencer, they just I have a confirmation.
Absolutely. But that's the same on
Villadium, right? So on Villadium, the validators
or like your guidance of data, the data availability providers
can actually freeze. Your state can freeze the entire
chain, and so your value will become unavailable to you.
You need only a single honest validator, right?
Because you're only one person who kind of makes the data
available. Great question.
This is a big misconception about the data availability
systems. If you have a state transition
which has been authorized by a decentralized set of validators,
and at least one of them is honest, that will apply.
This one honest validator will share the data with you.
However, if the majority of your validator set is compromised,
let's say like 2/3 of the validator set is malicious, then
they will do a state transition without sharing it with any of
the honest validators. So even though you have 1/3 of
the honest validators on the chain, they will never get a
single bit of this data from the malicious parties.
So it's like what matters is like who controls the state
transition, not who controls the data for the honest blocks.
Because if you control the state transition ability, then you can
always make this state transition into this unavailable
state and it doesn't matter that you have like a lot of honest
people on the chain. Okay.
So you need more than 1/3 honest majorities.
The other quorum like the chain can decide is it like one like
50%, two thirds, whatever. But like some quorum this quorum
that decides that yes we can accept the state transition
because we like the the the smart contract on Ethereum has
to make a decision whether this block has data available or not.
And it's it's impossible to look for for this block to for this
contract to tell it. Subjectively, it cannot talk to
all the validators. It cannot make data availability
sampling. Because it's a smart contract,
it can only work with limited amount of data that's been
passed. So the what the contract can
verify is like okay. Do I have enough signatures?
Do I have a quorum of signatures, Let's say 2/3?
It's a limitation of this verification code.
Okay. Yeah, that totally that clears
up my question. So if you look at kind of how.
DK sync and all other L2S are implemented at the moment.
They're all upgradable, usually from a single multi sync, right?
So I totally understand why this is done.
So you need to be able to mitigate potential
vulnerabilities and and on top of that L1 hasn't really
ossified enough, so there might be upgrades on L1 that kind of
might actively break things on L2.
So how, how do you then mitigate kind of?
The risk of compromise key attacks, right?
Because say there's like 20% twenty people on your on your
committee and you need like you know 10 signatures for upgrading
the contract any allowing you to steal funds and so on like
actually ceiling funds not just freezing them.
How do you mitigate that risk? This is a great question and
this is something like if you if you would ask me like how I feel
about this credibility, I would say I feel terrible like we it's
a key sync. The very first version of the
protocol we deployed is of Zicky Sync version one, which is now
called Zicky Sync right? It was completely immutable.
It was immutable with some upgrade period because we could
not tolerate that. Like the idea that some multi
sync control of credibility or the team can control of
credibility and just propose arbitrary changes completely
defeats the idea of this trustless scaling, right?
So like the? That was something we were we
were finding disgusting and then we had to learn the hard way
that, like we are way too early. We have to make the we have to
react to all our abilities because the bugs will be found
in the short term while the system is in developments.
You have to think you have to take a very paranoid defensive
mindset with mechanisms of defense in depth where you have
multiple layers of protection and you should be able to react
react in a timely manner to threats.
So we came up with the idea of the Security Council and since
then it like the the second chain that embraced the Security
Council was Arbitron earlier this year and now it's it's a
it's a broadly popular idea that like most other chains are
embracing and italic and L to be they are making great effort to
to push for it to to a set sign high bar of standards of what
constitutes a true Security Council.
So let's look at how Security Council works.
A-Team should only be able like the core team of any protocol
should only be able to propose a change for the upgrade which
will execute with some time lock so that the users have time to
withdraw from the protocol if they don't like the change or if
I'll try the protocol looks malicious.
Now if you deal with emergency, if there is a open box on your
system and live smart contracts, you want to be able to
accelerate this. And this is where Security
Council would kick in and you would get some external people
may be appointed by the governance of your protocol like
hopefully or ideally a broad set of participants of highly
reputable people from the community from a lot of
different jurisdictions who use off chain cold wallets to
control these keys. So what it gives you is the
protection from a regulatory capture.
Like it's a lot harder to compromise people in different
jurisdictions because like now it has to be something
universal. If if one government goes wrong
and and tries to like hijack the protocol, they will not be able
to do it. Like if if if if a single
company controls the protocol then the government of the
company where the company is incorporated would come to them
and say like make this upgrade or or you go to jail or
something like this right. But if if if we have a like a
broad set of participants, then it's much less likely because
it's harder. The second protection it gives
you is that compromising a lot of cold wallets in hardware
wallets or air gap machines or something like highly secured is
a lot harder than compromising the online servers with hot keys
in memory that are probably running in some cloud providers
that have access to the Internet that are vulnerable to 0 days.
To compromise the cold wallets that are not connected to the
Internet someone would have to go and break into like all of
the multi participants, which is a little bit harder.
But it's still not a perfect solution.
And the perfect solution would be to bypass the need to like to
withdraw the rights of upgrades from both the team and the
Security Council altogether. So the I can imagine the world
where the Security Council appointed by the governance,
proudly decentralized, highly secured with gold keys, can only
freeze the protocol for a short period of time if they see an
emergency, if there is a bug that needs the treatment, they
should go and do this. And then they should bring this
question to the protocol governance and the protocol
governance should decide and then make appropriate changes
and make the emergency upgrades on the product.
And then even in this case the question is like what is
governance? Is it just the majority of the
top and holders? Is it some broader set of
participants like I really admire?
I want to make a shout out to the Optimism team for for doing
a lot of work on on the on the process of governance like
elaborating different schemes like they have the idea of the
House of Citizens, the House House of Token Holders.
You offer a consensus between both of them, and even then we
might have some better mechanisms such as like
eventually bringing up this question to the consensus of
where one, you know maybe initiating a an upgrade in a way
that can only be accomplished with the soft fork of layer one
itself if there is a disagreement between different
parties of these governing entities.
So this is a big question which requires a lot more research,
but I hope I could get something.
Cool. That was very helpful.
So one question I think is kind of like very connected to this.
You mentioned the risk of bugs. I mean, I've also heard of other
people being quite concerned about this with regards to ZK
rollups. Can you talk a little bit about
where are the risks of bugs and what kind of consequences could
we have if there are maybe bugs in different places?
Well, all of the rollups are relatively new systems that need
to be bottle tested for a long period of time with a lot of
money until we kind of have enough confidence that they are
secure. The box can happen in various
places. For ZQ rollups, they're really
like if you look at the complexity of the systems, the
complexities is bounded to different isolated components.
So you could have a back in cryptography potentially.
Theoretically that could allow you to fake proofs or you could
have a back in circuits that would allow you to if you have
like if you are the validator, you can submit any proposal for
the new block. You could submit a malicious
block and then fake the proof that this block is actually
valid, right? If there are box, if you forgot
some constraints, if some things are missing in the circuit.
So to mitigate these things it's it's actually a lot easier to do
insecure labs and let's say an optimistic collapse, because you
can create redundant systems like the way it works in in all
mission critical systems today with like live emergencies,
aviation, nuclear energy and so on.
You never rely on a single component for security or for
safety for that matter, like in the aviation you always have
like multiple engines and multiple sensors.
The same thing can apply here. You don't want to rely just on
the validity proofs, you want to do things like 2 FA where you
need two separate mechanisms. In the case of ZQ roll up for
example, it would be. First a consensus of the
validators has to agree on that the block is valid and only then
they produce the zero Knowledge proofs and Ethereum Contact
verifies both the signatures of the majority of the validators
and the easier knowledge proof and only both match.
Then you make a state transition.
So now if there is a buck in cryptography it's you.
In addition to to breaking cryptography, you have to
compromise the majority of the violators, which is hard because
most likely they they were honest to begin with and then it
will be hard. You would you would have to buy
a lot of stake to be able to get to this critical quorum.
But then in addition to that, if you introduce some things like
withdrawal delays as we have in the case sync error for example,
the delays are withdrawed. The withdrawals are delayed by a
few hours. In addition to just verifying
the proof, you could say that you would also need to
compromise the Security Council who would be able to support the
problem and freeze the contract before the new malicious state
transition is compromised, which will bring you to three FA and
then like you can add one more layer of protection.
You can say that in addition to the validators and zero
knowledge proofs and this kind of fraud proof monitoring by the
Security Council, we would require a trusted execution
environment like SJX for example, proof that the state
transition is valid. It would give you like 4 layers
of protection that you have to bypass and you don't have to
rely on Intel or or NVIDIA or NVIDIA or other providers for
this. Like if the SGX proofs become
unavailable then the governance can always intervene and just
switch them off. This would be something so you
would always have kind of a multi stick of several different
components with growing degree of complexity of breaking that
for security. Okay, cool.
Thanks for explaining that. So maybe a final topic we wanted
to touch on, which is that. One thing that's being discussed
a lot, which is the sequencer and the decentralization of
sequencers, I mean it sounds like if I get sort of the ZK
sync path correctly, right, is that you basically want to have
the technologies to allow you know, like lots of different
people to do lots of CK roll ups and to choose to choose sort of.
Whether they want centralized sequencer or decentralized
sequencer and maybe different types of parameters.
So as a result, is that correct? And then for the path of, OK, I
want to decentralize sequencing solution.
Are you guys building decentralized sequencer and you
know how, what does that look like?
This is a correct statement. We are focused now on the ZK
stack, so we are which is based on the source code of the key
sync error. This is a modular framework.
This is a framework where you can replace different components
from the sequencer to the data availability layer to the way
you handle MVV. Like all of this, things are
going to be customizable for you and you have the full freedom to
choose what components you use in what way.
But we have to provide the basic components which some of them we
are working on at Matter labs, some will be provided by the
community, some will be provided by the grants program that that
we we want to initiate. But sequencer is really
fundamental it's it's one of the most important parts of the of
the stat and this is something we definitely want for the for
for error. We don't want error to remain a
chain with centralized sequencer.
We want to go to to to decentralize it in all aspects
as soon as we possibly can. So we are actively working on a
decentralized consensus. As I said before, we're using
hot stuff or modification of hot stuff called hotshot for it,
which gives you a very decent throughput at a very decent
latency. So for ZK Sync, we always take
the user needs as the like the north star of where we want the
Arctic architecture to go like we always architect back from
the ideal user experience we envision and the ideal user
experience is that every transaction confirms almost
instantly like within under one second and it costs like under
one cent. So that's kind of the the
utopia, the crypto utopia that we want to build.
And from this perspective the the consensus has to be fast
decentralized, but fast enough and low latency enough.
And HOTSHOT was was meeting this criteria criteria so it became
our choose. So, so just to clarify this
here, the consensus here, so it's basically.
Like, how does that work? Does it basically mean you have
a kind of like improve mistake that let's say there is someone
that's kind of like the leader at this point who does the
sequencing and then a bunch of data together gets passed around
and others kind of using hot stuff.
They test the validity or like the correctness of it and and
then that's confirmed and then you go to the next leader.
Or is hot stuff just used to basically choose the sequencer
and then for some point you just have this one party that's a
sequencer? Or like, how does that work?
So the blocks are being produced roughly every second and every
second the leaders decide that and all of the validators reach
consensus on what's the next block and it's in fault
tolerance. So like if the leader, if some
of the participants go down or become unresponsive it will self
repair quickly. But every second we have a
decision. Yeah, yeah, Okay.
And then do you feel like all of these things that are like huge
topics at the moment on the theory like around the Mev
pipeline and the proposed builder separation and those
kind of things? Will Will.
To what extent will this carry over to like this and the kind
of decentralized sequencing seeker sync roll ups?
This is a really, really good question.
I don't have a definitive answer to it.
We are in the research phase. We're looking at all the
different developments there. We're in touch with the Ethereum
Foundation with with guys building.
There are really amazing teams out there being shared
sequencers who think that shared sequencing is is the paradigm.
Sorry theorem, I don't have a firm conclusion yet like how it
will work. I have some concerns which which
I shared with all of them about the centralization of power.
If we come to to a world where proposal builder separation
leads to just a few entities essentially building all of the
blocks and all the chains, I think that's a bit dystopian
because it will give them a lot of soft power.
And like you don't want to eventually like to like like
some Google or Facebook or something like big corporation
like this to be powering all of the blockchains with nominal
decentralization through solid-state.
So we want to design systems that actually encourage
decentralization in various regards.
But there is a popular opinion that that might not be possible
and eventually, because of the complexity of entity extraction
and the value that you can produce from there, that this
inherent specialization in for builders will inevitably lead to
this outcome. I don't want to believe this.
I want to believe that we will be able to come up with designs
that actually broadly decentralized the system with a
lot of individual participants with ways to actually mitigate
MV and like it to prevent at least toxic MV from happening,
like targeted MV attacks. I think there are designs out
there that largely can accomplish this but I've also
heard concerns of schemes like encrypted mantles that they they
could lead to other problems leading to like less efficient
arbitrage on on on such systems and so on.
I don't have a definitive answer but we have a research team
focused on this and we will be just trying things out.
I can promise you that ZK Singh that you know to our core
various and we we we have not discussed the ZK credo yet but
this is like I encourage everyone to read and contribute
to the ZK CREDO which is our mission and philosophy and
various statement. We will do everything we can and
and we want our community to enforce it to go in the
direction of the maximum decentralization and
trustlessness. And so we will just pick the
designs for era and I think the community will support it that
maximize the decentralization and trustlessness and minimize
Med. But for hyper chains, I'm sure
that we will see a lot of experimentations and people will
be trying all the different models with like from going
maximum MV and then distributing it to the community to trying to
minimize MV and work with like first conference serve
principles or encrypted mantles or some other novel approaches
which I'm not aware of and eventually the market will
decide what works best. I wish we could go on because
lots of these actually sound super interesting, but we are
already way overtime. So we'll just have to have you
back at some point. Thank you so much for joining
us, Alex. It was super insightful.
Thank you. It was my pleasure.
It was a very interesting conversation.
Thank you for great question. Thank you so much.
Thank you for joining us on this week's episode.
We release new episodes every week.
You can find and subscribe to the show on iTunes, Spotify,
YouTube, SoundCloud, or wherever you listen to podcasts.
And if you have a Google Home or Alexa device, you can tell it To
listen to the latest episode of the Epicenter podcast, go to
epicenter.tv, subscribe for a full list of places where you
can watch and listen. And while you're there, be sure
to sign up for the newsletter so you get new episodes in your
inbox as they're released. If you want to interact with us
guest or other podcast listeners, you can follow us on
Twitter. And please leave us a review on
iTunes. It helps people find the show
and we're always happy to read them.
So thanks so much and we look forward to being back next week.