run a full break down on this speech give me a full complete summary of all key parts times lines updates please:

```
Thank you, and as you are fully advised with those that are on the side, and this is a main
stage for ants next time will be better.
So the weight is almost over.
The thing that I have been working about for almost all of this year is called the
B-chain.
So the B-chain is a proposed redesign of the consensus layer that incorporates all of the
latest and greatest ideas from the research movement, and the goals you try and transition
in a safe and fast manner from the B-chain that we have today to this B-chain, which
is much, much closer to the final design of the B-chain.
Now before I share more information, I have two disclosures, the claimants.
The claimant number one is that this is just a proposal.
This is my proposal, and the proposal will only go forward if there is a rough consensus
with it going forward.
The second disclaimer is that there is no new token, there is no new network, and we're
reusing the same ticker, and the topic is very, very clear as to what this ticker is.
Now in the rest of this talk, I want to take what may sound like a totally crazy idea,
and convince you that actually it may be not so crazy, that it might be a reasonable
proposal to put on the table to completely redesign the consensus layer.
And first, I want to tell you a little bit more about the B-chain, and what the ticker
vision is all about.
So the scope of the B-chain is specifically the consensus layer, and I mean, excluding
the data layer of the blogs and the execution layer of the EVM.
And the reason is that the blogs and the EVM are directly consumed by applications, and
there is a need to be forward and compatible.
And so the opportunity to modify these two layers is rather limited.
On the other hand, the consensus layer is not directly consumed by applications, and
so there is a big opportunity to shake things up a little bit there.
Now why am I proposing now to do this massive redesign of the consensus layer?
And it basically boils down to the fact that the B-chain is kind of old.
The spec was frozen five years ago, and in those five years so much has happened.
In particular, we have a much better understanding of the EVM.
Five years ago, we were extremely naive when it comes to the EV, and since then we've
seen the market really blossom and grow.
And we also have a much better understanding of mechanisms that can help us mitigate
the negative externalities of the EVM.
Secondly, from an engineering standpoint, we have this wonderfully powerful technological
stocks, where there's been plenty of breakthroughs.
In particular, we've seen stocks become all-dies of magnitude faster over the last five
years.
And we've seen the advent of ZKVMS.
The ZKVMS are amazing technology that allows any programmer in the world to make use of
this very powerful technology without having to be an expert in cryptography or in stocks.
And then finally, with the benefit of hindsight, we now know what the mistakes we made with
the B-chain.
And we have a bunch of technical debt, which is extremely sticky and tends to pile on over
time.
And maybe now we have an opportunity to clear this technical debt.
So I'm suggesting putting the greatest and latest of the consensus layer roadmap in
the B-chain.
So I guess it might be worse than a load of time looking at what exactly is in the consensus
layer roadmap.
There's basically nine different items, and I've categorized them in three different
buckets.
So we have production, staking, and cryptography.
So the block production has to do with any V. Right now, we have a lot of centralization
at the builder and relay level.
And one of the things that we want to do is have inclusiveness that dramatically improve
sensitive resistance.
Once we have sensitive resistance, we'll be in a position where we can clearly decouple
the validators from the block production pipeline.
And this is called a test to propose a separation and there's ideas like execution
options.
And then the final item here in the block production bucket is as the slots.
Maybe we can take the 12 second slots that we have right now and shrink them, all while
preserving the invariant that if you are on a home internet connection, you can participate
as a validator, as a first-class citizen, even if you are an illustrator with a high
latency internet connection.
Second bucket is staking.
The researchers, I think, have come to consensus broadly speaking that the current issues curve
is kind of broken and that there is an opportunity to improve the health and long-term outcomes
of Ethereum by changing it.
And the second item in the roadmap here under the staking bucket is this idea of dramatically
reducing the total amount of ETH to become a validator.
From 32 ETH down to just one ETH and there's ideas like orbit that have been circulating
around recently.
And then finally, this is an idea that has been talked about for many years is single-slot
financing.
It can be dramatically accelerating the process of Ethereum gaining financing.
And then the final bucket has two big ticket items.
Number one, can we snuckify the whole of the big, the consensus layer in real time using
a reasonable hardware?
And then finally, can we make the photography that is securing Ethereum sustainable for
the next decade and centuries and make it post-months and secure?
Now the coloring here is meant to suggest whether or not the item in the roadmap can be done
easily, incrementally or whether it can't.
So the five, sorry, the four green items here in the top left corner are items that I
think can be done and should be done in incremental forks on the decontainment.
So then when we get rid of those, we're left with big ticket items, the red items, that
I would argue are best done in a more holistic way.
So take chain stockification, for example.
In order to achieve real time proving of the decontainment with reasonable hardware, we're
going to need to change the hash functions, we're going to need to change the signatures,
the way that we serialize and verbalize the state.
And this is a massive change to the decontainment.
And so maybe there's an opportunity, well, if we were to make such a change, to change
other things at the same time.
And then the similar thing can be said for the bottom two red boxes, fastest locks and
faster finance, the truth is that five years ago, our mindset was security first when
we designed the decontainment.
And performance was not really a main consideration.
And with the benefit of hindsight, we found that there are designs that preserve all of
the security that we want, and at the same time, pick some of the low-hemifruit that
is available to us to improve performance.
Okay, so this slide here is trying to show the mapping from the consensus data roadmap
that I showed you and the talent for the roadmap.
We have some items that are classified under the merge, some that are under the scourge,
and then a couple that are under the verge and the spourge.
And the whole point of this slide is to communicate the fact that the deep chain is not about
changing the roadmap, more so that it is about identifying a specific subset of the roadmap
and accelerating it and putting a mimetic route around it.
Now one thing that is new in the consensus layer roadmap here is the fastest locks.
And the reason is that the discussion around fastest locks has happened this year at 2024,
but the talent roadmap diagram was only last updated in 2023.
Now in addition to being able to potentially accelerate these big ticket items, there's
a lot of technical debt and a mention that can be cleared out.
If we have single-stocked finality, we no longer need epochs, we can just have slots.
And the deposit contract that we have right now is kind of praise me, and it's a remnants
of the merge, and things like the sync committee is infrastructure that we won't need going
backwards if we have to obtain real-time stockification of the big chain.
And the list is on and on and on.
And this is doubled to see, as I mentioned, to just clear all in one go.
And if you interested in learning more about some of these big chain mistakes, last year
I did a whole talk where I talked about 20 or so different mistakes that were made in
the big chain design.
Okay.
So this is the big picture of you of how we have done upgrades to the consensus layer
since Genesis.
So in the bottom left here, you can see we did Genesis in 2020 and sit there, it's been
an extremely regular pattern.
Every single year, we've had a new fork, and every time we had a fork, we made one incremental
change to the consensus layer.
So in 2021, we had the sync committees, in 2022, we did the merge, in 2023, we added
withdrawals, and then proto-downshilding, and soon in 2025, we're going to increase the
maximum effective balance.
Now, what I expect will happen is that over the coming years, we will continue to make
these incremental forks, and we will be picking up the low-heimian fruit that was marked
as green bubbles in the roadmap, in the top left corner of the roadmap.
The depth we're going to kind of hit the wall, and the reason is that once we've picked
all of the low-heimian fruits, we're only left with all of the big ticket items that are
much more difficult to do in an incremental fashion.
And this is where the beam fork happened.
The beam fork is an opportunity to have a quantum leap forward in terms of upgrading the
consensus layer all in one go.
And one way to think about the beam fork is as a batching opportunity, with batching multiple
upgrades into one single fork, and this has benefits both technically and from a governance
standpoint.
And one way to think about this batching opportunity is as classification accelerationism.
This might sound like an oxymoron, but the basic idea is that we want Ethereum to go
in maintenance mode as soon as possible.
And right now there's this tension, because we know that there's these big ticket items
that require a fundamental re-architecturing of Ethereum, and the more we drag it along,
the further Ethereum will be in the position where it can comfortably ossify.
Okay, part two.
I want to try and highlight some of the technology that is going into the proposed beam chain.
And the way that I will frame this is basically in errors of Ethereum consensus.
Initially, we had the true-for-work error of Ethereum consensus and then we moved to
true-for-stage.
And now we're potentially entering this ZK error of Ethereum consensus.
And in this ZK error, we will be making heavy-headed use of schnarks as a technology.
So one place where we'll be making use of schnarks is schnarkifying the entire beam chain,
the entire consensus layer.
And this is where the ZKVNs become extremely extremely happy.
So imagine that you have implementations of the beam chain in various high-level languages
in Rust, in Go, for example, what you can do is compile these high-level images down
to bytecode that the ZKVNs will understand and get snarkification without having to worry
about details of the snarkification process.
Now one thing that I do on a highlight is that the only part that is snarkified is what
is called the state transition function, which is basically the crystalline core of what
it means to be a consensus client.
All of the infrastructure surrounding the state transition function, for example, the
networking or the syncing or the caching optimization or the folk choice rule, not
if that has to be snarkified and ultimately the state transition function is a small
subset of what it takes to build a client.
And what we've seen recently in the last couple years is risk-fire become the defacto
industry standard for these ZKVNs.
So risk-fire resident structure sets, and basically you can take high-level code and compile
it down to respire.
And we've seen seven different companies provide these risk-fired ZKVNs.
You may have heard of risk-zero, and SQ1, and the list of none of them.
Now one little side note here is that this exact technology, which is extremely powerful,
can also be used as the execution layer for the EVM, but that has a completely different
story to the B-chain story.
It's one which is extremely exciting because it means that we can dramatically increase
the gas limit as well as a vertically-scale Ethereum layer one.
But this is going to have to be for a different one.
The other place where we make heavy use of stocks in the B-chain is with aggregatable signatures.
We want to have a post-quantum aggregatable signatures.
And the proposal here is to use hash functions.
Hash functions are post-quantum secure, and you can use that as a basic building block
to build your cryptography.
So we would have hash-based signatures that are produced by the validators by the
testers.
And we would also have hash-based stocks where you can take many, many thousands of signatures
and compress them down to just one proof.
And with these two combined, you get a hash-based post-quantum aggregatable scheme that could
be used for Ethereum.
And one little nice detail is that this aggregatable scheme is intrinsically recursively aggregated
and can take aggregates of aggregates of aggregates, which is something that we can't
really do today with ELS, because it's much more flexible.
And the reason why I have this proposal here today is because in the last few months,
the progress and performance of snarkifying hash functions has gone through the absolute
roof.
So for those who are in the know, we're now able to prove on a laptop.
So this benchmark here was done in a laptop CPU, a MacBook Pro, we're now able to prove
two million hashers per second, which is an astounding amount of hashers per second.
And this means that this hash-based proposal has the potential of getting extremely performance
for the engine.
Now in addition to the very powerful ZKVNs that snarks everyone is using, I also want
to highlight that through a large extent, we would also be reusing existing infrastructure.
So the networking libraries, LIPP2P, the serialization of libraries, simple serialized, all of
that can be reused as it is today.
Same thing for the PySpec.
PySpec is the framework that we use to write the formal specification, sorry, the Python
specification, and the unit tests, and we can also re-use protocol guild, all of which
is infrastructure that didn't really exist when we started with the deconchain.
And the same thing can be said about teams.
When we started the process of the deconchain, there was no consensus client teams.
So the five consensus client teams that we have to do, this is manpower that can be reused
and doesn't have to be rebuilt.
And in addition to that, we have dedicated teams that will put in place with a marriage,
for example, if pandas opts, which does DevOps, and the security team within the general
calculation.
I also want to give a shout out to the incentives team, to the API research group, which
are also teams that all of this infrastructure didn't exist, and we can just re-use it for
three.
Okay, the final part is, so here I want to try and highlight some of the next steps
and how I see the future.
So one possible outcome here is that starting from 2025, we start the stepping process.
So this would be something that a small group of researchers would do, and they would
take maybe over a year, and then in 2026, the building process can happen where clients
would start writing, production will go, and then in 2027, we'll start an extremely
foreign testing process to make sure that this is all production-grade and safe to withdraw
it on maintenance.
Now the next step for me as a researcher would need to start writing the executable stack,
which I call the executable roadmap.
And the idea is to take the pixels that we have of the roadmap combined with the hundreds
of thousands of words that have been written on each research and in academic papers, as
well as all of the ideas that lie in the minds of researchers, combine all of this and extract
the core essence, which would be this executable aspect.
And ultimately, it would be a very small document, roughly 1,000 lines of Python code.
Now one exciting thing for me here is that the deep chain, assuming that there is infinite
senses to go in this deep direction, would be a fantastic, unmoving opportunity to bring
fresh blood into the space, especially for the consensus client.
So today we have consensus clients in North America, in Europe, in Boschemia.
And I'm very pleased to be able to announce today that we have already new consensus
client teams that are willing to build deep clients.
So we have one, which is based in India, which is called the Z team.
This is a deep client as an insect.
And then we have Lambda class in South America that has signaled an interest to also write
a deep client.
And so if you will also get involved, and we're going to need a lot of excellent time,
we're going to need spankers and networking experts and coordinators and cryptographic
experts and client teams, please reach out at this email address and beam up with us
on this new adventure.
Thank you so much.
Thank you so much.
Thank you.
Alright let's give one more time.
Come on a bigger round of applause.
Thanks for your presentation.
Really really appreciate it and thanks for the audience and appreciate it as well.
Now, now is the time to ask your question or if you see an interesting question, please
vote it.
Now, for those of you who didn't know about, don't leave here, okay?
Just give us some time because the volunteers need to clear a bit of the space.
There are still a lot of people outside, so at the end of Q&A, don't move.
Stay where you are because our volunteers need time to clear the hall later.
Okay, so just stay where you are and I'll instruct you in the end of Q&A.
Alright, just a little bit of the first question with the five votes right on top, deploying
many changes at once is risky.
If there is any one change, it's delayed or as a bug, they all get stuck or rolled back.
How hard have you tried to break them down in incremental matches?
Okay, great question.
So there's many things that I've tried to do to try and give this to be interesting.
The first one is to encourage all of the incremental upgrades, remember the four green items in
the roadmap that could be done ahead of time.
And by going through the process of the incremental upgrade, we're going to go through a lot of
the lessons and a lot of hard work and discover the challenges there and then.
The other thing that I'll mention is that the beam chain is really only about changing
the core of the clients, which is the state transition function, and a lot of the potential
opportunities for bugs, whether it's a networking layer, or the weaponization libraries,
or the full threshold, a lot of that infrastructure can, to a large extent, be reused.
Another thing that I want to do to de-risk the beam chain is make sure that all of the
existing clients are involved, because ultimately these are 50 abandoned women that have many,
many years of experience building consensus clients and they know what a lot of these pitfalls
are.
Another thing that I would say in terms of de-risking the beam chain is that we will have
an especially intensive testing period, which could last, for example, a couple of years.
This is what I had in the Shforman timeline, and during that time, we would do many, many
rehearsals on death tests and test tests, so that we could grow confidence that there
isn't a bug in this big upgrade.
Excellent.
Thank you for that.
The testing is very essential.
Now, the question that I've seen has got the most votes of maybe of the groups so far,
20 is the number to be, are you okay with people calling this ethereal 3.0, the me player
or ethereal ones to do this?
Okay.
Great question.
So, in my opinion, the money care I found 3.0 is not appropriate, and the reason is that
the beam chain is only about the consensus layer, is not about all of the firmware one is
just a consensus layer.
It excludes the data layer, dank charting, and it also excludes the eVM, and there's lots
of exciting stuff happening at these layers of the stack as well.
So, this is why I've tried to avoid the difference 3.0 money care.
All right.
I mean, it's a fair, fair answer as well, but people will do what people do best, and they'll
call it ethereal 3.0, and we'll get a few new points, and people will ask all the exchanges,
will my ethereal change and all that.
But let's go to the next highest voltage question, which ZKVM will be used for beam chain
as there's no standardization of ZKVMs?
Okay.
Fantastic question.
So, the amazing thing about the proposed design, and actually this is my different
metallic, is that the snarkification would happen off-chain and would not be enshrined
in consensus.
So, what that means is that every independent elevator can choose which ZKVM they prefer,
so they can use any of the 7 risk 5 ZKVMs, but they can also use non-risk 5 ZKVMs.
And ultimately, by having this off-chain snarkification, it means that if there's a bug in one
of them, it's very easy to fix.
If there is a performant optimization in one of them, you just update your client, and
you get this performant optimization.
And also, it means that we don't have to take winners, and we don't have to add a lot
of complexity on chain.
All of this is off-chain complexity at the social layer.
All right.
Thank you.
We got 30 seconds.
You have to take the last question at the top.
Anyway, to accelerate that timeline.
Okay.
We moved.
Okay.
Okay.
Well, let's think about work.
Okay.
They want it for 80, 90.
Okay.
Let's do that one.
Why are each researchers obsessed with lowering issuance?
It's hot.
We need the doubt to agree that this weighs the concept, okay?
Just take whichever question you want.
Okay.
I'm happy to answer all of the questions later on on all sides.
That's much.
Anyway, to accelerate that timeline.
Please email us at bead.chain or the film.org if you want to accelerate.
Let's go.
All right.

```