foreign
[Music]
systems thank you I'm also one of the
co-organizers of East Berlin and I used
to work on various EF and ESP grants in
the past for both execution layer and
consensus layer clients and among others
as Francis already mentioned I launched
the early testnet with a bunch of cool
people that are also sitting here in the
room in 2019 so what I'm going to cover
today is I want to briefly dive into the
ethereum protocol history prior to the
merge
um and then specifically take a close
look at the implications of the merge on
the test Nets and finally give a quick
guide to selecting a test net for your
project so yeah let's dive right into
the protocol history everything started
with a test net
does anyone here know what's the meaning
of the ethereum
Genesis extra data is you might know the
Bitcoin extra data or against this
accelerator contains a news headline
does anyone know what the meaning of the
ethereum accelerators it's actually a
block hash from a test net
um ethereum was uh publicly fairly
launched by announcing a block number on
a Olympic test net that was
128 201 and once this test net was mined
on the uh test once this block was mined
on the test net this hash could be
inserted into the ethereum Genesis and
the public mining on ethereum mainnet
could start
Olympic was the last pre-release testnet
before the issue mainnet was launched
and the first public assumed testnet
after the launch was more
than was a proof of work testing it
using the same algorithm as mainnet and
interestingly it had a custom starting
launch of 2 to the power of 20 to
prevent transaction replays on mainnet
most of us probably remember the
Shanghai attacks during Defcon 2 in 2016
an attacker exploited the long discrete
time of the X code size op code in one
of the client implementations which
caused the denial of service of the
issue main net here's a photo of the
amazing guest team investigating the
issues and coming up with a solution to
address this issue two subsequent hard
Forks were scheduled for ethereum the
tanguine whistle Fork to fix the attack
vector and dispers dragon
Fork to allow cleaning up the state
afterwards however this protocol change
caused a consensus failure on Modern
this was specifically caused by the
different ways how the clients handled
this custom starting loans and it was
then decided it's not not a good idea to
have a custom protocol on a test net and
therefore modern was discontinued and
replaced by a new testnet called
ribstone groups was the first tester to
launch with shine ID right from Genesis
the chain ID served the purpose of a
simple replay protection according to
EIP 155
so the roof's intestine was also powered
by the isage proof of work engine we all
know proof of work is fairly
permissionless
so there is no good incentive to secure
a zero value proof of work test bet so
attackers moved to DOS rubstone
and the test net was unusable for weeks
in response parity launched the coven
proof of authority test net and guests
launched during the approval for
Authority test net for the first time
ethereum had a
way to have a more stable test net
environment however coven used the
parity Aura consensus engine and drink
be used to guess click consensus engine
and they were not con compatible
coven was therefore only accessible
through the parity serum stack
whereas ring B was only accessible by
gas or tooling that relied on the gas
stack
so in 2018 the girl initiative attempted
to address this by ideating a
cross-client proof of authority test net
in the end the initiative managed to
implement click and parity
and subsequently in 2019 the early
Testament was launched as a first
cross-client proof of authority test
mode with validators from both guests
and parity ethereum
at the same time coincidentally after
Defcon I believe the pantheon client was
released so there was a even a third
client available for running validators
on this test net and soon after also
nazamine joined the validator set
you know later the same year parity
except uh ethereum and um
leaving coven fairly unmaintained
unfortunately
now going fast forward in time
just earlier this year to prepare for
the merge some of the older testnets had
to be deprecated the protocol support
team announced the end of life for
Robson and Rigby on
the amazing ethereum Foundation block
they argued the older test Nets are
harder to maintain due to Growing
history and state and the growing
complexity to run the test net setup
so in foresight
however new test net was launched
sipolia interestingly sepolia
that was just launched not even a year
ago it was launched as a proof of work
test net using the same algorithm as
main net back in the day
there was a first time since uh the
Robson launched in 2017 that we actually
launched a new proof of work test net
the reason was potentially to have
another test net similar to mainnet to
allow for once again testing the merge
and now mainnet conditions
okay so let's
um recap the test Nets prior to the
merge modern is fairly dead it was
replaced by Robson in 2017.
was just deprecated a couple of weeks
ago
um coven diet was poverty leaving
ethereum
Rigby was also
deprecated just
a couple of months ago and that leaves
us with scurry and sympolia as the
latest test nets for ethereum
and now let's just uh take a look at
what it actually means to merge
uh yeah I took a lot of time to build
these slides so in ethereum this the
merch stands for an event where two
blockchains are literally glued together
you need a consensus layer Beacon chain
that takes over finality and Fork Choice
considerations
here shown in blue
um and this consensus layer Beacon chain
replaces the Legacy proof of work
consensus or the other consensus uh
mechanisms
on the execution layer here depicted in
red
so the slide shows the timeline of the
test net mergers
and I added a lot of details here I'm
standing in front of it I had a lot of
details here but let's revisit this
slide
in a bit
after talking a bit about the
implications
so um
just to recap a proof of work consensus
mechanism is permissionless as parental
motor consensus
so you can just turn on your CPU Miner
and hope for a block
in theory
on the other hand a proof of authority
is permissioned obviously only
authorized accounts may take part in
consensus
and then again proof of stake is fairly
permissionless
you have a token and you can stake it to
take part in consensus
so what does it mean for SEO mainnet the
merge obviously moving from proof of
work to proof of stake
um
just does not change much in this
perspective it was permissionless before
the merge is still permissionless after
the merge
but how does it look like for the test
Nets
so girly was merged with a beacon chain
test net
and um
to access
to get access to the consensus on the
growly test net prior to the merge uh
was con was permissioned so girly was
running a community maintained Valley
data set
however after the merge it transitioned
to a proof of stake consensus
interestingly and suddenly everyone can
participate in consensus
given you have access to girlies
so girly used to be permissioned is now
permissionless
but what about zipolia
um as I mentioned prior to the merge it
was powered by the permissionless esash
a proof of work algorithm here you can
see my sepolia Miner I was happy that I
once again can mine a test net
um and yeah I did not ask for permission
I can just I was just able to mine the
blocks I got a lot of zipolia either
um
but now there's something unique about
um the C polier Beacon chain
um since it was apparent that girly will
no longer be permissioned there was
actually the the Quest for having
another
permission test net to have a certain
stability guarantees
so it was decided that the polio gets a
beacon chain with a modified deposit
contract that does not accept regular
ether deposits
instead attracts the valid data sets
through an erc20 token
so in that case zipolia is a proof of
authority version of The Beacon chain
and therefore the access to the polio
consensus is permissioned
so let's take a look at this overview
again
um
this is a timeline actually on the
x-axis axis
the first test net to merge was rubson
was fairly similar to mainnet it was
proof of work
and after the merge it was proof of
stake right so permission less
permission less
then zipolia transitioned
with this modified Beacon chain
so technically the consensus algorithm
is still proof of stake but through this
permission
um
esc20 token that you require to take
part in consensus I call it for
Simplicity proof of authority here
because access to this consensus is
actually permissioned
um
and then
girly merge was Prada and test net were
exactly the opposite happened uh
the proof of authority test and it
became a proof of stake girly test net
after the merge
and then yeah we are here eventually
just a couple of weeks ago the mainnet
merge occurred so yeah just take a look
at the post merge test net landscape I
showed you that groups merged however it
has been deprecated by the ethereum
foundations a protocol support team
and it leaves us with uh girly and
simpleia is the only long-standing
public post merge test Nets
so I will conclude my presentation with
the
test net selection guide
I mean it's only two testers how hard
can it be
I um
I mentioned how amazing Museum block is
it's just a
great resource I found this slide on on
the ethereum Block
um
basically just Recaps what I just said
um
the open value data set for girly on the
one hand the closed value data set for
zipolia on the other hand
um obviously since Gurley is much older
it has a large state
that gives some better Network effect so
if you have an application that you want
to deploy Deploy on girly and you
require other applications or interfaces
you might find some on the polio girly
but not on the polio because the polio
is fairly new and not many applications
and libraries are deployed yet
however it's also longer to sink and
more involved to run girly
infrastructure
so to summarize this
please do use girly test net as it is
most similar to the ethium mainnet
girly is especially interesting for you
if you plan to test a beacon chain
validator if you want to test your setup
if you want to test upgrading client
versions if you want to test
going through protocol upgrades girly is
potentially the best uh or if not even
the only test Network you can actually
conduct this
um
yes please also do use the sepolia
testnet um
sepolia comes with the best stability
guarantees due to the permissioned
validator set
since it's fairly new it is fastest to
sync and also it has the best long-term
guarantees so I would lean towards a
recommending uh
to test your applications or even
migrate your applications
to sepolia instead of Gurley at this
point
yeah do not use groups and obviously um
I when when I prepared my slides I
realized that we are just in this
transition phase where big service
providers already start shutting down
infrastructure so you have to expect
interruptions and downtime
don't use coven for obvious reasons
and yes also I would not recommend using
Rigby even though there is some
long-term support planned for rink B for
almost another year but you will
potentially not get more protocol
upgrades on that Network so I would also
not recommend using ring B and that
regard yeah right there are some caveats
so as I mentioned the girly test net has
Esa supply issues due to the sheer
amount of users trying to test their
validator set up
each validator requires 32 is and if you
want to have a more involved setup with
I don't know 1000 validators it quickly
becomes a huge burden huge problem to
access these uh required test net tokens
this is something we still need to
figure out going forward so if you have
an idea please hit me up yeah and in
terms of testnet age Gurley is also
fairly old so it has it comes with a
Felipe or a rich history and State
and is therefore more difficult to
synchronize
especially now that it's merged with
prata which also comes with a fairly old
Beacon chain in in combination
and yes the polio is uh
uh relatively new as I mentioned it
I wrote down lack of infrastructure I
put it in Brackets because it's changing
really rapidly right now I just noticed
while preparing my slides that uh even
metamask has a sepolier
test Nets which now so um it's happening
I'm really happy that we get all these
Integrations now
oh yeah
okay
um this is my subjective recommendation
if you want to test infrastructure if
you want to test your validators I would
recommend you to run them on girly
if you want to test your applications I
would even encourage you to skip early
and go straight to run your stack on
sepolia
okay this was my talk
um please use girly or sepolia going
forward
um find me
for some spare Visa cards from East
Berlin they are pre-loaded with girly
and sipolia Isa so if you want some I
will not throw them into the audience if
I just fight me after the talk
um
and yes since we have a couple of
minutes left please ask questions
thanks for the presentation is there any
tutorial or manual how to be a validator
in sepolio
ought to be to help in the
infrastructure
short answer is you can't
because as I mentioned even though it's
proof of stake you need a special erc20
token to get access to this value data
set and you would basically have to
Google support your
GitHub repository and there is an issue
where you can request to be added to
this value data set
but in general not many teams will be
accepted just to keep it really
a small value data set
maybe two questions here
um one when
eip1559 came around it was very hard to
test that in advance because you have
these proof of authority networks that
had no fee market and then you have
these proof of work networks that had
like kind of a fee Market you could kind
of Reason about sort of what that change
would do
sorry I am leading into questionnaire
I'm just giving some background and then
coven if I seem to remember right was
like parody Technologies maintained it
for the old open ethereum parity climb
sort of the idea
and I think like now the execution layer
is a spec
there's some value behind
um
you know testing clients so I so I guess
Mike just to sum it up to a question
both testing features an execution layer
specs is there any thought in behind
testing those kind of things moving
forward spinning up test Nets or Forks
of test Nets to do that
so
I'm sorry I don't think I got the
question it's also I don't have the
speakers if you could just try to speak
up a bit or so so specific testing
specific features of ethereum forks like
a fee Market changes or testing the or
validating the the execution
spec was sort of the goal because like
you had like you know open ethereum or
parity and Geth and whether they synced
up or not in terms of where they're
executing uh you know evm basically
correctly was always a question right if
they ever split so so I that's that's
what I'm asking where are the where is
the test net infrastructure sort of
going in terms of forks and things
they're just gonna spin it up whenever
or whatever I want to beat this to death
um yeah I hope I understand the question
uh correctly
um so I was talking about public test
Nets today and public testness is always
a really final stage of testing
everything so if we want to test
execution layer changes the content
layer changes and whatnot you usually go
from from like a local simulations to to
permissioned deafness to
um through like a lot of hurls until you
actually get to a public test net and
these test Nets like when I recommend
Gurley or sepolier they will only get
protocol upgrades that have been
sufficiently tested before
um
I don't know if this answers your
question okay
um
do you know why did the mergers happen
the way around they did could wouldn't
it have been more logical for for goalie
to continue as a proof of authority
sorry I think I have to come down
I'm just wondering why the merges
happened the way around that they did as
opposed to gawley continuing as a proof
of authority in sepolia uh transitioning
yeah I think that's a very good question
the reason is that it merged with the
product test net which you used to be a
consensus layer testment for a very long
time where many teams already tested
um
running validators for more than a year
or one and a half year so it was already
this proof of
um stake test net available and it was
decided not to
um
launch a new test Beacon chain test net
um
for currently specifically
and just use the existing one so this is
that's why we had this flip that was
also discussed so maybe have a new uh
deposit contract on Gurley but in the
end they decided it's actually worse for
testing the merge to do the big big
merge because product was also the only
uh consensus layer test method had
about approximately the same amount of
uh values and mainnet as mainly
yes and it was very very valuable for a
specifically the consensus player teams
to have
um
to let to not sunset this prata test net
and you cannot have you cannot move this
product testing it to another execution
layer because it's all linked to the uh
deposit contract
to have validators or the external
participants on these test Nets and you
need to do a bug fix
when you need to do a bug fix on the
test net code are the external
participants such as validators having
to
rebuild their their validators on a new
machine image or a new version of the
code base
and how often does that happen during
the test net phases
what's the question uh if there's a bug
fix on a test net how often do you have
to rebuild your clients
yeah what's the workflow when there is
bug fixes applied to the test Nets if
you are a validator there might be a
protocol bug
so does the validators get coordinated
and they redeploy their nodes multiple
times during the test net rollout
uh yes this is basically uh yeah the
answer is yes but um
this happens very rarely because most
bugs are usually not caught on test Nets
but much much earlier thank you everyone