Hi, welcome to epicenter of the show which talks about the
Technologies projects and people driving decentralization.
And the blockchain revolution. My name is CBS anchor Jo and I'm
here today with a new co-host, just as fights are who.
I'm sure. Lots of you will recognize as if
I know your face and the in the theorem ecosystem.
Joseph. Thanks for coming on and
co-hosting. This one with me, it's actually
quite fitting since we're talking with him beko who
couldn't coordinates all the theorems core developer meetings
and works at the, a theorem foundation on the protocol
support team. And today, we're talking about,
well, all things if you're re-emerge, which is quite timely
because there was just a major test net, merge, right?
Like a few minutes, Or we start at this, you know, this will go
out fairly fairly soon after after that happens.
So this is actually quite timely.
But yeah, thanks for thanks for co-hosting this one Joseph and
maybe tell us a little bit about yourself and what makes you a
competent co-host on this particular topic?
Well if I'm going to jump in on one, I feel like this is an
appropriate subject. I've been around the ethereum
space for a while. I do Communications and PR work
with most of my time at 3 and Foundation as well, but I'm sort
of a general tinkerer. So anything in the layer, one
sort of Block Chain space, that passes the legitimacy.
Sniff test is something that I've liked to play with for a
while and Just happy to jump in. Cool.
Well yeah happy to have you on. Hopefully you can come on for
you know most of our you know, ethereum Focus episodes because
I think you have a lot of Insider information and really
good insights. So glad to have you here it and
wonderfully about the public systems is that nobody has
Insider information. If you're paying attention Yeah,
and I, yeah, Tim. Thanks for thanks for joining us
today, right? Right after the merge.
I'm Cipollini. Oh, welcome Unser polio yes.
Yeah. Thanks for having me.
Cool. So before we talk to Tim just
want to tell you about his sponsors this week, security
block. Chains and earning rewards needs
doesn't need to be energy, intensive or complicated and by
staking your That's with Horace one.
You contribute to network security and earn rewards to.
Of course, one has been a Pioneer in this basement is 2018
and they secure hundreds of millions of dollars in assets on
over 30 decentralized, networks including Solana Cosmos etherium
and many others. If you're an institution and you
want to run your own node, you can use chorus one's white label
service, and their battle-proven infrastructure to participate in
proof of State networks in an easy way.
So head over to course dot one and start your steak Journey
were also supported by Paris. Swap are swap, is a multi-chain
decks aggregator. This means that through Paris
swap. You can easily access the
liquidity of various different. Decentralized exchange has the
protocol automatically finds the cheapest liquidity for you.
So you can know that you are getting the best price for your
trade Paris office. Also gasps friendly and helping
you keep your transactions low. They recently added support for
Avalanche polygon, B, SC and Phantom.
And you can also use Periscope directly in your Ledger Live
app. If you lose use a ledger in
addition to that, they are also becoming a down.
So if you have USB tokens that something you can participate
in. As in participate in the
governance of the protocol and the Paris walked out.
Just voted the gas refund program which will allow pair
swap stickers to get up to 100% of gas refunds on the trades on
top of their Auto compounding yield so they're still learn
more. Visit Paris, swap dot IO and
since we're here I also want to mention something that I think a
lot of people perhaps have already noticed some organizing
a conference in Paris on July 22nd.
It's called nebulae Summit. It's happening on the day after
ECC. So during ECC week which is one
of the largest aetherium developer conferences in Europe,
actually one of the largest blockchain developer conferences
in Europe as well. Nebula Simon is all about
celebrating the cosmos and interesting ecosystem so I hope
to bring a lot of you know Cosmos folks and etherium folks
together for this conference will be joined by Cosmos
developers researchers and entrepreneurs.
As they discussed the challenges facing the interest chain and
you're talking about the future of the internet of blockchains.
So take Are almost sold out as we speak right now we're going
to be pulling the plug on the ticket sale soon, but you might
be able to squeeze in check out nebular dot Paris for more
information and I do want to mention our sponsors who are
making this possible F, most anoma Club Neutron a gorik, and
Celestia. So with that, let's let's get
into this Tim. Tell us a little bit about your
background and how you got involved in this work.
Work. Yeah well I guess your first
thanks for having me on. Yeah my background so I I
started like getting interested in Block, chains around 2013,
2014. First year first heard about
Bitcoin and got into that. Then a couple years later, I
actually heard about a theorem through the doll but when the
Dow was like a project and not a hack so I'd like Her dimensions
of it before. But the the doll project is
really what Scotty that like actually try out a theorem.
So I literally bought ether and about thousand tokens like the
week or even maybe day before it got hacked.
And and then the next morning like remember reading on Reddit
the post about some I think Lisa likes a saying, I think someone
is draining the Dow and that was like a pretty eventful couple
weeks after that because not only was so dis big hack but
after it was The term classic split and you had to figure out
like how to split your tokens in order to prevent replay attacks
and and I knew like absolutely nothing about blockchain stands.
I was just like copy-pasting random commands in my terminal
hoping that I wouldn't just lose all my coins doing so.
So it was like a really interesting, I guess what I
think to get into this space but after the Dow there was like
this this LOL or it felt like you know, maybe if they were was
not. Going to be like a successful
experiment because, well, if this is a smart contract
platform and you can't write a smart contract on it without
getting hacked. You know, is there, is there a
ton of value there? So I guess I could following
your bit, but I didn't like late, 2016, early 2017.
You start to see a bunch of projects.
I use the theorem again, and obviously in, like, by mid-late
2017. There was this huge Ico, boom.
And there I kind of realize like there would probably be a lot of
Man for aetherium even if like all the applications in 2017
turned out not to work clearly you know there's a lot of things
you could do with blockchain like that and I decided I wanted
to work like at the protocol layer because as a user like it
was still pretty rough to use a theorem those days.
And you know like when there were like ico's and the mempool
would say congested for like hours to days it was just like a
really bad experience in felt like there's a lot, you could
improve their but I wasn't like an engineer research.
Sure. I was like a product manager.
So it took me a while to find like a product manager job
working on the protocol and not on the product, built on top of
the protocol so thick like about a year.
But then consensus put together a protocol team and I joined
that. And so I worked I worked as part
of consensus for about two and a half years on their hybrid Edge
or base you client. So got involved in basically
main that protocol work through that.
And as part of that, you know, I worked out with folks, like,
Hudson who is chairing the awkward as calls of the time and
and then around like 2020, he wanted to move on to other
things. And yeah, I decided to step up
and take the role there. And so since then I've been
basically coordinating these developer calls that we have on
the theorem where different protocol Implement
implementation teams get together and chat about it.
Changes to a theorem. Yes.
That's how how I ended up here. Gotcha, and before we dig into
core development and sort of how governance and a CD calls, all
chord F calls work in general, what your role today, we
mentioned earlier, you were with serum foundation on the protocol
support side. What is protocol support?
Can you just let the folks know? Yeah, so our team sucks pretty
well though. That the T, my mind that the EF
is called protocol support. And it's a bit of an odd team
because, like, for me, it was no TV was just like Hudson, you
know, like floating in the org chart and then like it since the
theorem has like grown and gotten more complex in the past
couple of years. Like the basically there was
just like a team put together and you know there's folks like
Danny and me where we obviously Charities calls.
There's a bunch of folks. To help either, like get better
inputs and share updates the community, like Trent, we just
have folks who work on like, you know, specific stuff behind the
scenes. Like there was the suppose we
emerge today and someone on our team is just working on getting
the hash rate on supposedly a so that we hit the merge at the
right time. And, you know this, yeah.
Stuff like client grants. Organizing like workshops.
So, you know, anything that basically supports like the work
of researchers and And core developers in the protocol is
stuff. We try to help with yeah.
I think we're getting toward the same point but may have a little
bit of a delay just so folks kind of get it.
What does governance look like on aetherium how is it?
How does it relate to these all chord F calls and who decides
anything? Okay.
Yeah, this is. There's a lot to unpack here.
So I guess like the very first bit that's important to know
about like a theorem governance especially relative to like
other blockchains, is we don't use like Queen voting or any
sort of formal voting as part of the governance process and the
roof reason there is that like we don't think that like coin
holders are like the Only stakeholders that we should like
disproportionately optimized for and and so if we don't have coin
voting you know it becomes a much Messier process for
governance to happen. There's definitely some pros and
cons to that but I think overall it's it works quite well for
theorem and generally the way the way I like changes to the
protocol would happen you know this is the happy path and then
we can talk about all the edge cases is You know, someone comes
up with an idea. We have we have a pretty open
process for like proposing changes to the protocol because
all the specifications are public, you know, anyone can
come and put together like a proposal to change something.
We use VIPs for that. Mostly again, there's some
exceptions here but like roughly we use the IPS and so if you
want to change something on the protocol you come you put
together the IP and then we usually ask that you get some
feedback, you know, async from people who are like have
relevant. Variants in the part of the
theorem you changing. So imagine, you know, you're
changing gas prices or something, then you probably
reach out to some client teams. You probably want to do some
benchmarking on likewise, the new gas price better if you're
if you're adding something new, you know, like trying to get
some feedback from like the people who will use this thing
that you're adding and like why is it important to them and
what's not? And once you have a proposal
that's like in decent shape, we have these public calls that
happen every two weeks called all core devs.
And there's a, there's a mirror version of that for for changes
to the beacon chain. But you know, for now we can
assume they're like, roughly the same thing.
So we have these public calls people come with a proposal and
then discuss it and then, you know, kind teams basically
decide whether or not that this is a change to should Implement.
And in practice it's incredibly rare that like a change will be
accepted like on the first. I'm the first time it's
presented depending on the complexity of the change.
It takes like a small number of months to like a small number of
years to get that change included.
And most of that time is spent just like in back and forth with
protocol developers who try to understand like does this change
actually benefits people and most importantly, like, is there
a security risk to aetherium by introducing this change?
So there's a long list of changes that like, would be
beneficial to end users with like there are settings,
security issues with them. And so, you know, we can't like
have them in the theorem, then, you know, assume you go through
this process. You convinced everybody on the
client teams of like okay, this change should go in kind of
teams will typically then write, like, write the code for your
change, right? Testings and whatnot and then
they just end up putting out the software there, still needs to
be like, adoption of this software by the entire theorem
community. And this is the part of ethereum
governance, which is like, very From from a lot of projects or a
lot of like uh Tyrell ones where when the client devs put out the
software, you can think of it as like an opinionated suggestion,
right? Like they think like okay these
are the changes we should make to a theorem and and this is
when we should make them. But if people like steak yours
and not operators, don't upgrade their nodes, those changes just
like don't happen and then practice, you know, usually by
the time we've put out like a set of changes the community
will adopt them. And the reason is like we try to
prune changes that like we think would not be adopted earlier on
the process just because it's quite messy to have an upgrade
happen where where you know, it's highly contentious and and
you know, to be carried, those have happened in the theorem in
the past but generally, if something feels like, you know,
there's not like broad community support and and there's not a
strong enough rationale to like, Despite that then it's kind of
inclined team's best interest to not include it because then
they're the ones who have to deal with like the Fallout of a
messy Network upgrade. So there is definitely like this
check you know by like everyone involved in ethereum about the
changes that go out. And then we, you know, there's
often leads to like very intractable conversations about
like what is the theory of community?
And who should get a say in what not then.
I don't think there's like a single answer there.
You know, different change. Bring out different parts of the
community with strong opinions, but yeah, it's really just
process of just like trying to come up with a set of changes.
That like-kind developers think will be adopted and and
proposing them and and in the default case they usually end up
being adopted but it's not something we can like, take for
granted or forced upon people. That's interesting.
I mean, I think that's the first time I heard someone really kind
of explained the the governance process for for upgrades and
etherium. I spend a lot more time on the
cosmos side of thing and and and of course there are.
You know, there's there's there's coin voting and your
governance is is an issue. I think that, you know, affects
all different blockchains. Whether it's, you know,
something like Bitcoin or theorem would say it with its
process. These or you know, blockchains
with built-in coin voting governance.
You think that coin voting governance, you know, could add
some level of you useful signaling in etherium,
governance. I mean, poor governance has its
flaws and we certainly see that in the cosmos faced recently,
but I think that as a signaling mechanism, it's highly effective
and like we saw recently, you know, some proposals on on on
some Cosmos chains, like get, you know, now, Two percent or
above 90 percent by in. So, I'm curious what your
thoughts are here. Yeah, that's that's a good
question. So I don't think it adds much at
the level of a theorem L1. And, and that's not to say it
does, it's not useful in other contexts, but I think for us
there's like two outcomes you can basically get with like your
signal either. It's like you know mixed or it's
like strongly in favor. I think for any case where it's
strongly in favor we can get that signal you know quite
easily. You know, and take, you know,
let's take something like EIP 1559, right?
Or like that. Even the merge, right?
I think if you polled coin holders about the merged, it
would tell you, they're all in favor because it reduces
issuance. And I you know, maybe I don't
know, maybe some of them have like a vested interest in proof
of work. So they would pull against but
like I my rough feeling is like, you know, it would probably be
Large majority in favor and if you think something like yeah if
you 1559 they would probably be even clearer because like okay
coin you know, like coins are getting burnt that's like you
know unnnnnnh undoubtedly good for quite holders but then it's
like if we because we don't have like a formal process to gather
other signals Beyond like these calls and whatnot.
It would sort of elevate. I think like that signal above
others. And it's not necessarily the
thing you want to Optimized for, especially in the short term,
right? Like, obviously, you know, like
ether holders are like a stakeholder as part of the
governance process, but they're not like the only one nor are
they necessarily the most aligned, you know, you could
argue like the client teams developing ethereum even though
they're not like the biggest coin holders by several orders
of magnitudes, like they have a desire to see like a theorems
Thrive as like a long term, you know?
Infrastructure that maybe like the coin holders today, don't
have right. Like maybe again if you have
like a very carrot troll view of this, maybe like most of the
coin holders today are just holding for the merge because
that's a trade for them and like, you know, they'll move on
to the next stage and I'm not saying this is the case and I
doubt it would be in practice but it's like it's not clear at
the me, the signal from coin holders at a specific block
being much more explicit than like all the other signals, we
have actually adds value, And like the route reason there is
like, yeah, you're like optimizing for many stakeholders
and there's obviously some alignment between coin holders
and the other ones, but it's not like complete and I think like,
the more your project is like aligned with coin holders, the
better like those governance votes are of a signal and if you
think like imagine like a very simple hypothetical defy
product, where like the coin basically gets part of like the
profits from like the upper. Shouldn't have that defy
product. I think in those cases, like,
it's entirely reasonable to have the coin holders.
Be like the main if not sole decider of governance there
because it's like, well, they're like building this thing and
this thing is like has clear like you know, business model or
like flow structure funds flow of funds structure and they can
optimize that and and there's not really like, you know, users
are obviously maybe not quite holders but then the users are
the ones who generate your Fateh.
So, like you want to keep them happy, and this is like
basically, you know, pretty simple alignment problem.
And whereas Fourier theorem it's like, you know, like yes,
there's obviously like that ether the asset but I think
that's like a subset of what like, people are trying to build
and and what users use it for. And that, you know, again the
very simplest example there you could say like, well, you know
it's good for coin holders when like, the fees are high and a
lot of East gets burned, but that's obviously very bad for
users. So you don't want the like yeah
over optimize for them. So yeah and and you know that
says it's also has had coin votes in the past and I'm not
sure like we've gained much information from them and this
is not even getting to like the technical parts of it were like
a lot of the East is not in a position where like he could
vote. So for example, you know some of
it is like in a multisig, some of it, there's like wrapped in
defy, some of it is like in Cold Storage so you're not even
getting like a vote of like coin holders, you getting like a
weird like vote of like the eith that's readily available and
willing to like take some sort of like procedural risk to go
and vote on that. So yeah, I'm pretty against it.
But I think for some other projects like where do you
incentive alignment is just much closer with just corn holders
that it makes it thundersense. We will get to the merge in just
a minute. I did want to just make a one
sort of point of clarification. One further question when it
comes to governance digging into the stakeholders that you were
mentioning. So for a lot of folks listening
in may have been a while and some of these terms consensus
layer clients execution layer clients, you mentioned an entire
secondary called. So, you know, in the old days
all coordinates was all the Chordettes and now you kind of
have these two layers happening in unison.
Can you explain a little bit about what this client ecosystem
looks like and you should have your thoughts on this sort of
facet of a theory of evidence and where it's headed in the
years to come. Yeah yeah that's a great point.
So yeah, everything we kind of talked about.
It's almost like the the pre Beacon chain etherium were like,
yeah. We had even then unlike other
like blockchains a, theorem has many implementation teams.
So like the ethereum protocol is specified using like basically
math and like some, some like readable but not optimized code
and then there's different teams you like.
It versions of this protocol and I think the best analogy is like
web browsers in a way where like if you go to like the, theorem
dot-org on Mozilla versus Chrome versus Firefox versus fari you,
you get to the same web page but obviously like Chrome versus
Safari. Have a bunch of different
features that's like they optimized for and so can think
of a theorem client implementations as that, right?
Like, where does the single specification that they follow?
Kind of like, you know, implementing HTTP and like DNS.
Solving for a browser. But then there's like a bunch of
degrees of freedom that they have to improve their
optimization stuff around sync, speed, database storage, you
know, the efficiency of API requests and whatnot.
And so this means they all kind of get a say in the governance
process, right? So it's not just like a single
implementation team deciding this but it's basically a set of
them and to make this even more complicated in practice.
Now we have both like what we call the execution layer of A
theorem, which is the current proof-of-work chain where like
smart contracts and and and user balances live.
But now we have this vegan chain, which is the proof of
stake, implementation of aetherium, and this proof of
stake, Beacon chain also has an independent specification and
the set of independent implementations for it.
And that means that like in practice for their governance,
you know, they need to come to consensus across all these teams
for changes and now we have the merge happening which is I like
the combination of the current execution chain, where we remove
proof of work. And instead rely on the existing
Beacon chain that the bring consensus to the network.
And so this means that both from like a technical but also
governance group perspective like these two layers will merge
together. Where, you know, now we have
people from say that Beacon chain giving input into
decisions that affect the execution chain because, you
know, they're affected by it and vice versa.
So and so this is probably like what the next couple years of
governance for theorem are like is like finding like cleanly
merging those two things and I think, you know, there's some
like interesting aspects that both of them that I think we
want to preserve. So I think that on the execution
chain, you know, we have like this very open process.
That's like fairly well-documented and people can
come into for the beacon chain because this launch like
separately from etherium, they wanted optimized for Need and
so, they've been like, much better at executing efficiently
and the cost there is like you. It's a bit harder to like, for
Outsiders to follow the process in the specific changes.
And I think, you know, as we as we Merchants to together,
hopefully, we can preserve like the speeds that we've had from
like developing these things independently and having it be a
bit more modular but also make like the process for specifying
changes across the entire theorem stack.
Jack, you know, very clear and transparent.
Yeah. So that's that's the big thing
will be, will be working on next, but in short, you'd say
it's much more of a peer review process than it is sort of a
participatory sort of token holder kind of thing.
It's definitely participatory. Peer reviews a bit.
It feels a bit too distanced from like, what?
Compared to what we have, right? Like peer reviews.
Usually like Anonymous. And like it's also usually like
one or a couple rounds, like very formal and discrete sets of
reviews. I think what we have is like
much more fluid where like, you get a bunch of reviews from your
peers, but it's, you know, people are not Anonymous or, you
know, they can be but like generally they're not or at
least, not all of them. And and it's also it's not just
Open to experts. This is probably the other thing
as well. It's like you know for example
take EIP 1559 which was like a popular one or you could think
like EAP 30 74 which is like another popular change, it
hasn't made it the theorem yet. It's not just kind as like
reviewing and deciding about this like the community and
different parts of it. Like, smart contract,
developers, and whatnot will come and they'll have strong
opinions. And those also need to get like
Incorporated. So it's it's this weird mix
where I guess there's a lot of public review but there's also
So it's also open to like anyone to come in and, like, in
practice, we get, it's like, we don't get every stakeholder that
come in every time but what a change effects, like a set of
stakeholders like you can, be sure that someone from that
group will show up and have a strong opinion.
And this is kind of what you want, right?
Like you want, like the most qualified or like the person's
like the strongest opinion to be heard and and to make a decision
based on that. So can you talk a little bit
about the like the test net landscape and what that looks
like? And what are the current test
Nets running? Yes, so that's changed a lot
recently, but maybe I can like share where we were at and where
we're hoping to go. But if there was like a lot of
tests Nets and cousins, obviously useful for both
application developers who can like deployed or contracts to
them before going to Maine that. And for client developers, who
can deploy, protocol changes them before going to maintenance
the problem with pestilences, like, they end up being very
unstable over time because One. Like if they run on
proof-of-work, like proof of work is not meant to run with
like little hash rate and you get a bunch of volatility in
terms of block times and whatnot at to, if they run on proof of
stake, again. It's like you're asking people
to like, run these validators for no reward, so it's quite
hard to keep them stable and then over time, you know, as
just like a normal Block Chain their history and their state
size grows. So it becomes harder to sink and
node. So we've decided with the merge
coming like this. Is like a good time to revisit
like what are our tests and and what do we want them to be going
forward. So basically we launched a new
test that for the merge called Kiln.
And this is like the first one will be shutting down right
after the merge. And yeah, there is just, we
wanted something earlier this year that anyone could use.
That was like, show them what post-merge ethereum feels like.
So, both infrastructure, providers, smart contract,
developers and whatnot. I'm so it was like a new
testament that we launched and It's only purpose is like you to
be there as a Verge test nut before we merge the other ones.
And so once we've merged my net, that one will go away.
I'm and then if you look at like the other like longer live test
that we basically have Gordy Rob Stinson and rinkeby, as well as
kovin, kovin has been like half deprecated for like over a year
and now is like fully deprecated, because open the,
theorem is basically the only software that can run validators
on it. And that client, Has been in
like a semi deprecated state for a year and now it's fully been
deprecated. So if you're using kovan
basically this is not going to transition to the merge and so
you should migrate to another test that because as soon as
like the merchants the it means that the network you're using
just does not does not reflect the state of ethereum network
today. Rinkeby we can be is maintained
by the get team and it's been around for a long time and now
has like a large State and the history.
Makes it harder to read notes on it.
So we're also not transitioning this one through the merge but
it has like a lot of applications depending on it
already. So we have a bit of a longer
shutdown period where we'll probably have it be live for
like about a year from now. Although as soon as the merge
happens again it won't be a good copy of the theorem my net.
So it's most it'll mostly be there for like Legacy reasons
but in about a year should be shut down.
Then we had a rough skin, which was another really old test net.
And this one was running on proof of work and it's always
been really chaotic because getting proof of work hash rate
on test, Nets is quite hard and and it's that means like the
average amount to get is really low.
But then if somebody just shows up when a minor, you know, they
overwhelm the network and that causes like super quick blocks
with a lot of uncles and then when they leave it causes super
slow blocks. So it's just, it's just a bit
annoying to maintain. It was always quite a bit in
this. This chaotic State look like a
lot of re orgs. And and so we actually we
transitioned this one through the merge first.
Because it felt like well, you know, it's already quite
chaotic. If we break it, it's probably
the least bad test that the brake.
And now it's running under proof of steak, but after the merge on
the theorem, a net will be shutting this one down as well.
So sometime before the end of the year and this leads us to
two tests Nets which were going to be maintaining.
So, the first is Gordie, Gordie, is also like fairly old but I
think of the like column Legacy test nuts, it's definitely the
one which has, like the strongest Community around it.
There's like a really diverse group of validators on it.
There's like a lot of enthusiastic running on Gordy
and there's also like the biggest Beacon chain, test Nets
at the Prater Beacon. Shame, that's like anchored to
it. So Gordy is a testament will be
maintaining going forward. We're going to run it through
the merge. It'll be the last test.
Now if we actually run through the merge and so that validators
Like dress rehearsal that they can.
They can try before before going down, may not.
But if you're using Gordy, you know, it's not, it's not going
away anytime soon and then, lastly, because Roxton and
rinkeby were like, so old. And like, large last fall, we
launched a new test method called cipolla, and this
actually just transition to proof of stake today, right?
Before we recorded this and this is like a new test Network.
We're the good thing about it is it's just like super light
weights to sink if you want to run a node on it you can you can
get up to speed in like less than an hour and it just makes
like really easy to maintain the downside is there's obviously
not as much stuff already deployed there.
So there's not as much like interrupt between between
contracts, but will be will be will be keeping this one as well
and hopefully growing the amount of stuff on it over time and
then the final difference between like guardianship olya
is because Gordie already had a really like Large validator
test, net. We're going to keep this as like
an open validator set. So if you just want to try stuff
on your validator on the test net, you could always use Gordy
and even after the merge with Prater like you'll still be able
to do that. But because again, like when
people have these tests and validators, they end up like not
really caring for them. It causes some amount of
instability on sip olya instead we've had like just a
whitelisted set of validators. R where, you know, these are all
like infrastructure companies and whatnot that that commits
the running them for multiple years.
So there it's quite a stable experience for developers.
So the recap all this Gordy and cipolla are the two tests that's
that are like sticking around long term.
This is what you should be using, you're moving to, and
then the other tests were going to be shutting down, you should
consider kovan basically already, you know, very far down
gets deprecation window and the shutdown soon, kill the merge It
will be shut down right after the main net.
Merge Rutherfordton will be shut down before the end of this
year. And then rinkeby will probably
be shut down sometime next year, but it'll be lagging behind me
method. So it won't be like a great
stage environment anymore. Okay, and this leads us in a
developer. It's good to know.
If you're a user you've been probably waiting to hear what is
the merge Where Do We Stand now? Because we're talking about test
Nets and test that merges. What happened today but I will
just hand you the mic for a while.
What's coming up? Yeah, and I guess I think this
is it's useful to give a better contact felt like, like how did
we get to, like, where we are today and then like, what are
the next couple steps? But basically we've been testing
the merge for over a year now. And if you count the launch of
the beacon chain, it's like more like two and a half or so years.
And like I mentioned earlier, you know, we launched this
Beacon chain separately from the ethereum like application,
proof-of-work chain, because at the time, is already a ton of
usage on a theorem. And we wanted to make sure that
it's like the We can chain worked and was stable and that
if it wasn't they wouldn't break everything else on the theorem.
So we launched it, and after I'd been up and running for a while,
you know, we started to the Prototype like, okay, how are we
going to actually combine these two networks together?
And like, really early designs for this?
Had like a migration as part of them, or like, users would have
to move from one to the other and I just felt like, really bad
user experience. We're ideally you don't want
them to Have to do that. And it was this Insight in.
Yeah, a few years ago that well, the clients, that run a,
theorem, the proof of work chain today.
They're already used to this concept of like different
consensus algorithms. So, like we mentioned, you know,
main that mean that uses uses proof of work but a lot of the
test that's don't write. They use what we call proof of
authority, you're just different consensus engines and similarly
like a lot of Enterprise private networks.
Also, Use like different consensus engines.
And so there is this idea of like, well what if instead of
moving all the applications over from like the proof-of-work tank
to the beacon chain? We simply had like the software
that's running all the applications change, what
consensus algorithm it listens to you to get, like to get the
consensus on the state of the network.
And this is like that, the very high level design of the merge
is that once we hit a certain point, the clients on the
network, stop listening to proof of Work as a way to get the
latest valid head for the for the blockchain and it started
listening to the proof of stake Beacon chain and this means that
you don't need to move all the applications over from one to
the other. You can simply kind of use a
different rule to tell you what was the latest Allan Block and
keep kind of building on the existing existing chain.
So we first prototype that in May of last year, there was like
a hackathon and we got some of the client team.
To get her to prototype. Like, could the post-merge
architecture work, where you have a beacon chain clients,
that kind of keeps track of the head and then they receive
blocks and they send them down to their execution client, which
runs the evm transactions. Make sure that those
transactions are valid and then like confirms that or orphans
the block, if not. So we prototype that in this
hackathon, we got it to work. So that was like, good
confirmation that like, this design was sound, you know, like
with the What would the two clients talking to each other?
Obviously it was a hackathon for a ton of bugs as we spent like
last summer, fixing all those bugs and ironing out a design
for like it, final architecture. And then last fall we prototyped
the actual transition from like proof of work that proof of
stake. So could you like start a
network up on proof-of-work, started Beacon, Shane
separately, and have them transition and you do not fall
apart throughout and safely like finalized on the other side.
So we got everyone in person actually for this for a week and
after like a week of work we managed to get like a first
prototype of that working where we launched a definite and it
started on proof-of-work moved over to proof of stake and it's
finalized on the other side. And so again, this was just like
a week-long hackathon. So there were tons of bugs and
issues, and we spent like all of the Fall after that fixing
those. And by they see the Christmas
holidays. We How to spec for, like the
entire merge and post-merger Theorem, which we felt was like,
pretty stable, like not perfect but, you know, roughly, right?
So we launched. Its first test, is called can
Sugi, right? Like late, December.
And this was just like, give people an idea of like what
post-merge etherium would look like for us to reach out the
infrastructure providers and application developers to make
sure that like, you know, things didn't break when they were
using it then, and And we got that confirmation.
We also run a bunch of stress tests on the network like
spammed it and put nodes and weird States and we found doing
that. We found some, some edge cases
in this spec. So we fixed all of those and in
March, we launched this killed test net, which I mentioned
earlier which which was basically like call it like 95%
final spec for the merge. So we've done some small tweaks
to this text since then, but no like big substantive changes.
They've mostly been either like clarifications or just, you
know, some edge cases that like a subset of clients were hitting
and whatnot, but like, the overall like functionality has
stayed the same since then. And after after launching Kiln,
we still felt like it would be good to get like some more
practice runs because you learn a lot.
Like, when the network runs through the merge and it's a bit
weird in a way because this is code that only has to run once
on Main meth. And there's like a ton of
complexity there. But in one summer just happened,
you know, you never need to run through the transition again.
So we wanted to make sure we got like as many kind of runs of
that as possible. And we started doing these
things called Shadow Forks, which are basically hard Forks
where we only launched a small number of nodes, controlled by
my client and testing teams which which have the hard fork
and then we see how it goes for them.
So you can think of this like, you know, there's like thousands
of nodes on like the theorem Network.
Well, we take like, 10 to 100, we spin them up and we tell
those like small number of nodes, I hate emerges happening
here and then we actually run through the merge on those nodes
and see what happens. And, and for a couple days,
also, we can replace transactions from Main methods.
Well, so we get to see, not only like running through the merge
on maintenance but also our denotes table afterwards, you
know, can you still sink and whatnot.
So we've been doing these shadow Forks over and over.
I think we had like our 11th or 12th one.
Earlier this week. So basically, like every week
since since like late March, if not multiple times a week
sometimes, and that's been really good that help us test
like not only every client implementation but also every
pair wise combination. So earlier we mentioned, you
know, there's like these clients that work on the execution
chain, these crimes. That work on the beacon chain,
there's four on one side. Five on the other this means
there's like, 20 pairwise combinations of like, one
Beacon. Then what, execution time that
you can get. And so the shadow Forks we
basically passed every single possible permutation and we want
to make sure that they all work and then we find, you know, when
we find bugs we obviously fix them.
And this is roughly like we're, we were like a month or two ago
and now we've, you know, we feel like much more confident than
liked it. The the Readiness of the code
we're not like 100% there yet, but you know, we felt ready
enough that it made sense to start.
Working the like long-lived tests on a theorem and there
were a couple of reasons for that.
The first is like, which Rob's then we mentioned earlier.
Like it's quite a chaotic test, it's already.
So it was even if like something went wrong.
It wasn't the end of the world, but we also wanted to give end
users, like people running validators at home, the chance
to run through like emerge. Basically because all these
shadow Forks, the nodes are basically controlled by client
teams and testing teams. But it's not open to anyone to
run a node. So we have this first Roxton
Fork where we had, we had like a new Pekin chain launch for
Rustin and anyone could join that.
And yeah, I'm on that. You know, we had people for this
faith and the network moved over and generally the transition
went well. So that was good.
We found some couple bugs that's been fixed and then today we ran
through the second test and that's that polio and the goal
there was to make sure it was like the bugs, you know, the
bugs on Robson wouldn't show up again and we're still worse.
You generally looks like the fork went well but we're still
digging into the details and coming through everything.
Once we have that we basically have one more test net to do
before May Nets and this is gorney with the printer Beacon
chain and this is a test Network.
You know, we really want things to be quite ready because this
is where the majority of stagers are like expected to like run
through the transition with their set up in anticipation of
maenette and it has a ton of activity as well.
So it's not a test that we wanted to.
The break. So once, you know, we once we've
like, debriefed on this supposedly a fork and and see
whether there's any issues we need to fix or address.
What we'll start scheduling and Gordy and then ones Gordy
happens. Assuming it goes well then we
would look at scheduling the fork for magnet and the goal is
really just to get as many like dry runs.
As we can in the increasingly complex scenarios where if you
start super complex room to slide from the start, you're
going to hit Bunch of issues. It could be really hard to find
a root cause but if you start with like the small Dev Nets
that you like increased complexity over and over, you
always liked fixing bugs at like the edge of like the complexity
and it just makes it much harder to much easier, sorry to fix
those bugs. If you're, if you're increasing
complexity as you go. Yeah, in short.
It's like, yeah, we spent the past year testing, we've done
one more test net. Today, there's one left and
assuming things go, well, go. Well on that one.
We'd move to my nut. So to recap, that merge
specific, Dev Nets, long-standing merge specific
Testaments in line with these shadow Forks, upgrade, the
long-standing ethereum test Nets that we covered earlier.
And then maenette, with one more long-standing test, net left to
go, and that's girly. That's correct.
Yep. And then Gordy with the Prater
Beacon chain and we'll just call it all Gordy after it emerged.
So what do you look for in a successful merge and when it's
done what's next? So, I know that a lot of work
has been done on Shanghai, and a lot of those listening would
probably be curious about. So there's some misconceptions
about the merge and I'm sure you're probably very familiar
with and can speak to from token on blocks to scalability.
And some of those things are covered in the next sort of set
of upgrades that come after So what's left coming up until the
merge? And what comes next?
Coming up until the merge is basically we want to monitor
these tests Nets like not only right after but also like you
know call it a week after so that we can still sink notes to
them and things work work well. And you know we have a whole
slew of metrics that we look at like from some pretty basic
stuff like our blocks being produced to like you know are
like transaction fees for every transaction being routed to the
right way. So it's you know now let's read
just combing through all these metrics and making sure that
like things are looking good and fixing anything.
Or it isn't. And then when we fix things, you
know, if we find a bug, well, typically, then write a test for
it and then run all the clients through this test Suite, because
it's possible that it's just like, you know, one client, it's
something during during emerge, but then all the clients
actually had the bug, it just happened, not to hit it.
And so that it's like, it's really like fine calming through
that and then if you know if you look out and you assume the
virgin's happen and we're all good.
Yeah. There's obviously more things on
the etheric realm. But beyond that, and maybe the
first that you hinted at, is this idea of like Beacon Cheng
withdrawals. So because the merge is like the
most complicated upgrade we've done to a theorem since probably
launching a theorem. We tried to cut down anything
that wasn't absolutely critical from it just so we can have like
the smallest possible set of changes which is already a
pretty big set of changes and and and the the the biggest like
cut that is the ability for validators.
Withdraw their Stakes back to to the execution layer.
So the like Foley exit as a validator.
So that's like the first big feature.
We're planning for after the merge typically, when we have
these hard forks with, with new features will introduce more
than one. So there's a bunch of other
proposals as well, but that's the stuff will be.
It will be working on right after one thing.
I'll note though with regards to validators and withdrawals is
while validators, won't be able to withdraw like they're their
Stakes after the merge like the 32.
Heath + like the rewards they've accrued as soon as the merge
happens. Validators will receive
transaction fees that currently go to minors and they'll be
receiving that on the execution layer itself.
So they won't, they won't be locked.
Like, validators are on the Deacon.
Shame. So this is kind of neat.
So if you are a sticker or even like using your stinking pool or
something, you will start accruing.
The non bird part of transaction fees, right after the merge. so
let's talk about what happened, just just a couple of minutes
ago, but an hour ago, the the cipolla emerge can you can you
talk about that and in the context of like sort of a you
know, this this broader roadmap and how significant it is to the
broader merge efforts Yeah. So like we were saying, it's
like the second out of three tests nuts and it is like this
new one, which we hope to keep stable and the, the validators
on this network are like a set of, you know, climb teams
testing teams, infrastructure providers.
So it's not, it's not like quite anyone like we because we want
we want this network to be stable.
We basically opened it the like any individual or entity that
can come. It's the running state
Validators over a long period of time but it is not just like a
web page where you can sign up and launch a validator like
there is for Prater. So this was like a good test
because it's like it shows us. Okay.
Like there is still like some group of like this think
entities and individuals that need to coordinate and and debug
things but it's still not as open as like the the Prater you
can chain or maintenance. So yeah.
It's like it increases like the complexity of things.
You know, because we're on this, this this call.
I haven't liked the digging through all the the specific
things that happen but a lot of high-level right before I jumped
on it seem like you know the network was relatively stable,
there were some parts of validators that's hit like some
some issues or were offline and it seems like folks are still
looking into that but well, no better than like the next couple
days. Like, you know what types of
bugs that we hit, where they boarded bugs.
Were they actually just like, And issues.
So, if their configuration issues is actually quite good
because it's like, you know, called is like operator error
rather than the like protocol problems.
So that seat, you can just restart the validators, the
wrong with the right configs, and it works.
So that's what we're looking at. I think once we have a clear
picture, there will start thinking about.
Okay, when do we want to Fork this last test net?
I think our bar for the last test, net will be higher because
we want to make sure that like, any Staker can run through it.
And that it's Like as close to my net as as possible.
And then yeah, assuming that goes well then we would we would
then move to merge magnet. And so this next test net,
anybody, anybody would be able to run a validator on this on
this on the next Testament. Yeah.
Yeah and you can already right like so you don't need to wait
for the Verge. You can literally go and like
register validator on Prater and and have it the up and ready for
the merge. And if if you want to also run a
post-merge validator right now, you can do so on rough stdin.
So rough said has merged and so you won't run through the actual
transition. But if you want to figure out,
okay, how do I configure my validator so that like I
actually get transaction fees and like, And some validators.
For example. Today, it is possible to use a
third-party provider. Instead of running an execution
there node to track deposits. After the merge, it won't be
possible to do so. So if you've been using, say in
for our Alchemy, but your beacon chain, clients to track
deposits. You can't do that after the
merge. So you need to figure out, okay,
how do I run? You know base, you never mind,
get Aragon and you can do all that on Roxton today and
register a validator and make sure that it's working.
Yeah. Cool.
So as we wrap up here, I think it would be interesting to maybe
talk a little bit about about scaling and you know how like
how post-merge, what's Caitlin we look like post-merge?
And you know I think it's interesting that you know a
theorem is taking this data, availability approach and
allowing sort of like ecosystem change to build on top of this
on. This on top of this base layer,
what is what is your view about? Like what this ecosystem will
look like post-merge you know, where will cover the majority of
applications live. And, and I think one
interesting, one interesting thing maybe also to consider is
what are some of the interoperability.
I mean beyond the, unlike bridging instance, things like
that. Like are what is the word, the
the work being done on a Need to ensure that all these different
Roll-Ups and like chains built on top of the data.
Availability layer will be able to talk to each other and like
do cross chain calls and stuff like that.
I think you know, over time in terms of just like designing if
they them there's been this this like Evolution where it's like
if you compare a theorem when it launched a Bitcoin, it was like
this maximally complex blockchain relative to fit quite
right where you know it concerns itself with like arbitrary
computation and state and whatnot.
I think obviously the blockchains landscape has
evolved a ton since them and and like the kind of design See in a
way for theorem has has kind of shifted the like okay what is
the actual minimal set of things?
We can provide with the highest level of security, which dead
enable people to build, you know, applications scaling
Solutions and whatnot that depend on them.
And so, you know, like one very obvious shift is I decided that
ethereum originally wanted to do something called execution
charting where there's a bunch of like L1 shards which each
process comp A patient and parallel that are like
management protocol. And we've moved to this world
where well instead, we'd rather allow like a free market of like
solutions to emerge and use etherium as like more of a
settlement layer in this would be seen with with l2's today.
And this is how, you know, we think about like scaling is the
l 1 chain. Like, I mean the capacity will
keep improving and there's some stuff we can do but like it will
not improve as quickly. As like the demand for Block
space grows, you know, so if you imagine we improve the capacity
like 10x or 100x over to next like five ten years, the men for
blockchain might grow like 100,000 x, right?
Like we need like several orders of magnitude more and this is
where things like basically layer.
Choose can't provide that. And so, and the way layer 2's
work, like, at a very high level, is that they trade off
this asymmetry, we're on etherium.
It's like very expensive to run computation, but fairly cheap to
store data, whereas on an L2 is actually quite cheap to run
computations. So if you can run all your
computations on L2 and post like some data about them back to L1
that allows you to, like, lower your fees a ton because you're
just running all these computations and not actually
running much on a theorem L1 +, ZK, Roll-Ups and optimistic,
Roll-Ups differ and how like, They approach this but a high
level it's like this is a symmetry between the cost of
like running operations versus posting data.
And so if we could get scaling solutions, that just run those,
computations off chain, either, like run like some proofs on
chain or some some disputes on chain but in mostly post data
that allows like for way cheaper transaction fees and for more
scale. And so today when these these
Roll-Ups and scaly institutions pose that about to aetherium,
the only mechanism they have to do so So is like storing data in
the blockchain forever. And this has like two to
consequences. One is like every single note on
the chain needs to process that data and to the, the hold on to
it basically forever. And so that means that like it's
it's still fairly expensive to store data on a theorem and so
when you pay for like a transaction on a layer to most
of the cost, you actually paying is to store this data back on
the theorem. The first thing we could do
there is like, okay, well how do we make it cheaper?
For data on other theory of because that doesn't mean it's
like cheaper for all these Roll-Ups that could be built and
or conversely that they can, like, accommodate more demand
for the same price and therefore scale.
And one thing about the Roll-Ups is, they don't actually need
this data to be stored Forever on the network.
They only needed to be posted on the network and available for
like some amount of time such that people can like, agree that
it was there and then it was correct.
And if If it is not correct have like a reasonable amount of time
to dispute it and typically this is on the order of like a week
more or less. So there's this like exception
within Roll-Ups that like, if the data has been made available
for roughly a week, it gives time for people to like, sanity
check it, make sure that there's no, like either malicious or
buggy transactions, or like mismatch between what the hell.
Two things is the state of the world and what L1 thinks the LT
state of the world? Is and if that happens that it's
fine. And so this is really the window
where like you want to provide like really strong security
guarantees around this data, this short period of time and
after that you almost like don't really need to provide much
because you can assume that all if there was a dispute it would
have been resolved. And and if somebody wanted to
make a copy of the data that they could have done so already.
And so this is where we get it to like this idea of data
availability. Which is say like, what if If
instead of just having these l2's store data on the
blockchain forever, they simply post it to another place where
still secured by etherium, but we don't guarantee this data is
available forever. We guarantee it's available
roughly like for how long roll ups.
Need it with some buffer, you know, on each side.
So like I was saying, you know, Roll-Ups usually need to stay
left for the order of like a week and like the proposals for
theorem right now is like what if we just provided a way to
make data available for like the order of like a month?
Or something. So it's like, you know, even if
it's even if you needed within a week, yeah, like maybe you need
to sink a node. Literally, you know, you need to
go buy a computer, get an internet connection setup, get
the guy come to your house, set it up, stick your node and and
you know this extra buffer would give you enough time that like
you could still recuperate student data that's way.
And so this is when we talk about like Proto, thanks Char.
Take. This is roughly.
The idea is what if we added like just a daily component on
the theorem, which is like affair?
Emeril but still highly secure but then you can charge less for
this data component because you're not, you're not basically
incurring a forever storage cause you incurring like a
short, duration, storage cost, and then the next level beyond
that is, what if instead of having all the nodes on the
network in cure this like short-term storage costs, you
could scale the amount of data that you're storing have nodes
Only Store subset of it but then get like a really Hi,
probabilistic guarantee that the rest of the data is available on
the network. And this is like, when we talk
about like full sharding, fourth area, more like, dang sharding,
which is like the latest spec for it, this is what it means.
Is we take this this infrastructure that we have the
store, like it ephemeral amount of data.
But instead of having every node store, a full copy of all the
data, you have every node Source a subset of it and do some like
cryptographic checks, Across the peer-to-peer Network to ensure
that other nodes are storing the rest of the day.
That would like a really, really high probabilities.
Right? Like thank you though.
There's like I don't know if it's like in the billions or
trillions but like there's an incredibly low chance of like
some amount of data would be would be unavailable on the
network and because basically, by doing that, you're able to
scale roughly by another order of magnitude, the amount of data
that you have. And then those, those cost
savings or like, basically, K-league bandwidth gets passed
on for layer choose and other solutions that help.
And so this is like roughly. The vision is just like, can we
hone in on the parts where security matter to most and like
put all of our efforts there and provide like these incredibly
high like security assurances that this data, you know, was
made available that this data was like correct and that the
network came to consensus on it. But then after that kind of
Outsource the, like, the community into the ecosystem,
like ways to store manage that data.
And you know, you're at a point was around like, like crossed,
you know, L to Communications and stuff like that.
I think, again, that's something where it feels like the L1
protocol itself is not the place for that to live, but where it's
probably much healthier. If you see just like Market, the
merge and the best Solutions, you know, gain traction there.
Okay, so, to recap slightly, the merge is happening.
And then, after the merge happens, we would dig into
things that look like optimizations that help with
scaling in L2 land. But I think, you know, as we
come close to closing, I could give you the mic back to talk a
little bit about why. I think some folks may be fell
off the wagon a little bit. Is that as a Research changes
titles, change, naming schemes change, and roadmaps change.
So, for those that have maybe been on the epicenter train for
closer to a decade, there are four stages to ethereum is
roadmap, right? There's Frontier Homestead,
metropolis and serenity and that's long gone.
And for those that sort of came around during the Ico era.
The question is when T2, which still kind of exists today in a
couple of different places and people that can Use one another
with supposed token. Name changes that don't exist,
but this revolves around some phases.
So, would you say this is kind of where the road map stands.
Now it's a merge be these kind of optimizations and whatever
else into the future. What is today's is this sort of
today's ethereum roadmap I guess I kind of met apart from your
question is like clearly the theorem roadmap has changed a
lot, so it's it's probably naive to expect, you know, today is
when it gets set in stone. I think maybe like the biggest
like conceptual changes were a bit less, like a linear now than
we were before. And because we've grown the
amount of people who contribute to the protocol, we're able to
do stuff in parallel to it agreed like We couldn't and so
there's things like when you know, like if you looked at like
you know, this like Frontier at the serenity roadmap or like
eats two phase zero phase one phase two, they all assume like,
you know, it's like we're going to work on 8 and we're going to
work on video. We're going to work on C.
Whereas today it, I think we're in a spot where like, obviously
we need to ship things. One after the other, we can't
ship every single thing at the same time, but there's
definitely different teams and different like, even within
teams like people that are working.
Going on, like the various, you know, big eater issues with
ethereum or like areas of improvements and the kind of
happening in parallel. So like we talked about like we
talked about Beacon, Cheng withdrawals, we talked about
sharding. We talked, you know, we didn't
talk about like, Mev and proposer Builder, separation
that we didn't talk about like statelessness and we didn't talk
about like DVM and genuine to improve that, but those are all
like threads that are happening in parallel today.
And I think you know a lot of high-level it's like there's
some protocol related things that we need to do to ensure
that a theorem like scales and is safe and like and that we we
don't end up in like a spot where there's like some
centralized actor within the system who can like exert a
really high level of control and of influence and there's a ton
of work that's being done on those fronts.
But then yeah, there's also a ton of work that's being done.
Like, Making sure the evm stays like relevant and keeps
improving and luckily, it's like, they're not blocked on
one, one on the other. And what what, I think like
happens is, then, you know, whenever something goes from the
spot where it's like ready to go from research to Productions,
then we typically will prioritize that and and gets
working on it at the client level.
And we've been lucky so far that like, it's just not happened as
To R&D efforts are like ready to shift at the same time and if
they are in the future which it probably will happen, then we'd
have to decide which one is higher priority or do we want to
bundle them together but yeah I think it's yeah there's not as
much like a single big roadmap and and that's one thing we've
tried to do like with the naming.
You know, you talked about like a 2 versus eat one and today we
call them like the consensus. They are versus like execution
layer and I think the best naming strategy like going
forward is just to try and Like describe things like very like
plainly like what they are like, you know, the consensus layer
like helps you, theorem Network. Come to consensus on the valid
tip of the chain, the execution layer, actually runs those
transactions. I think once we have like
sharding live, you know, it would be fair to called out like
a data layer or like a data availability layer.
And and similarly if you look, you know, the Mev land, when
they start to think about like proposer Builder, separation,
it's like they're taking this one step further.
They're looking at, like, okay, what's the role of a validator
where the different tasks that like a validator can do?
What are the degrees of freedom? And can we just like, you know,
segment that in an even more granular detail so that we can
we can analyze it better. So that's my hope.
Like I think if we if we can go for like having this like very
vague like yeah. Terms to just saying like Okay
these are like the five biggest problems and we need to address
them and this is like the solution bit that's Going to
address them, I'll be really happy.
Obviously, it's off its off my cultivate, but I've appreciated
that we're trending in that direction.
And I think we're going to have to save proposer Builder to
reparation for the second round. Yeah, you did someone else to
come and give it to our talk on that?
Yeah. Yeah, the next, the next time we
have someone from from EF on, it'll be the answer.
The question when III we should, you know, we need to start
getting some content out like early about about III again
since, you know, since it's our history with, you know, covering
this sort of topic on epicenter. But yeah, thanks, thanks for
coming on Tim. It's been great and you know
hopefully now our listeners, get a much better view of the
overall. All arch of the merge and
everything. That's, that's coming up.
Next, certainly I have a much better understanding NASA.
Hopefully, we can get you on again soon and in a couple of
months, when when things start to move into production.
Also, if you have, thank you so much for having me.
Great, thanks. 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 podcast. 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, .t V /, subscribe for
a full list of places where you can watch and listen, 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 guests or other podcast
listeners, you can follow Oh us on Twitter and please leave us a
review on iTunes. It helps me behind the show and
we're always happy to read them with thanks so much and we look
forward to being back next week.