►
Description
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/demystifying-l2-transactions/
Transactions executed on rollups have a different lifecycle to L1 transactions. In this hands-on workshop, for devs and users alike, we’ll use Arbitrum as a demonstration tool to send transactions, follow them through their different stages of finality and analyse what fees they pay.
Speaker(s): Chris Buckland
Track: Layer 2s
Keywords: rollups,transactions,gas
Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/
Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
A
A
So
the
topic
of
the
talk
is
to
look
into
what
an
L2
transaction
is
in
the
context
of
arbitrim.
So
there
are
a
range
of
different
l2s,
but
the
one
we'll
use
today
is
arbitrim
and
L2
transactions
will
differ
between
those,
but
some
of
the
concepts
will
be
passed
between
them,
so
yeah.
So
there's
some
differences.
A
Some
similarities
we'll
go
into
some
of
those
and
I'll
first
give
a
bit
of
an
introduction
about
what
a
roll-up
is
and
that's
what
I
mean
by
L2
in
this
in
this
context
and
then
we'll
go
into
the
workshop
itself,
foreign
Okay.
So
at
a
very
high
level,
a
roll-up
is
a
side
chain,
it's
another
blockchain,
but
it's
connected
to
some
sort
of
base
chain
by
a
validating
bridge.
A
And
if
you
want
to
read
more
about
this
there's
a
paper
by
Paddy
you've
sat
in
the
back
of
a
room
over
there,
so
you
can
get
more
information
there,
and
this
is
a
kind
of
rough
overview
of
how
it
works.
So
you've
got
one
blockchain
at
the
top,
which
is
the
roll-up.
You've
got
the
main
blockchain
at
the
bottom,
which
in
this
case,
would
be
ethereum
and
they're
both
progressing
via
State
transitions.
A
A
So,
in
an
optimistic
roll-up
case,
there's
a
fraud
proofs
that
are
used
for
checking
that
state
and
in
the
case
of
a
ZK
roll-up,
it's
just
a
ZK
proof,
but
the
other
crucial
thing
is
that
green
blob
that
I've
put
inside
the
the
bridge
contract
and
that's
data,
that's
associated
with
the
state
transition.
So
you
on
the
on
the
roll
up.
You
need
us,
like
a
minimum
amount
of
data
to
be
able
to
recompute
the
state
transitions
that
are
occurring
on
the
on
the
roll-up.
A
A
So
this
is
a
kind
of
rough
life
cycle
of
a
L2
transaction,
so
a
user
would
create
a
transaction
they'd,
submit
it
to
a
sequencer
who
would
then
be
collecting
these
transactions
into
a
batch
when
the
sequencer
has
got
enough
transactions
they'll
compress
this
batch
using
some
standard
compression
algorithm
in
arbitrim's
case
this
is
broadly
and
then
they
submit
the
batch
to
ethereum.
So
that's
this
green
blob
is
that
batch.
There.
A
Yeah
and
another
kind
of
difference
between
L1
and
L2
transactions
is
gas.
So,
as
I've
mentioned,
L1
turns
like
L2.
Transactions
need
to
be
submitted
at
some
point
to
the
L1
and
someone's
got
to
pay
for
that
So.
Eventually,
that's
going
to
be
the
user
and
that
that
cost
is
associated
with
the
call
data
that
is
required
that
is
consumed
by
the
transaction
on
L1
and
is
priced
at
the
price
of
L1
gas.
A
Then
there's
L2
gas,
which
is
basically
the
same
as
L1
gas,
the
same
gas
that
you
know
on
ethereum,
but
it's
at
the
price
of
L2
right.
So
this
is
just
the
execution
of
the
transaction
that's
occurring
on
L2,
so
you
pay
first
to
put
the
transaction
on
L1
and
then
to
put
and
then
to
execute
it
on
L2.
So
there's
these
two
different
costs
and
we'll
kind
of
go
into
that
in
this
Workshop
yeah.
So
this
is
the
URL.
A
Yeah
so
I've
included
some
useful
links
at
the
top
there's
some
rpcs
there
to
connect
to
both
arbitrum
and
to
ethereum
and
just
some
other
stuff,
some
general
information.
If
you
want
to
read
more
about
like
L1,
L2
gas
and
some
of
the
ways
in
which
arbitrim
works
that
are
relevant
to
this
talk
yeah.
So
these
are
the
prerequisites
it's
just
there,
so
you
can
clone
this
repo
itself.
We've
got
curl
for
making
some
requests.
Foundry
for
using
cast
cast
is
a
kind
of
tool
for
helping
you
format.
A
A
Okay,
so
the
first
step
is
to
we're
going
to
send
the
transaction
on
L2,
so
I've
already
sent
a
transaction
which
you
can
use
if
you
want
in
your
example,
or
feel
free
to
like
use
your
own,
like
metamask,
connect
to
arbitrum
and
send
them
like
a
transaction
on
mainnet
at
the
moment,
they're
reasonably
cheap
I
think
so
it
should
cost
you
only
a
few
cents
to
do
that
if
you
want
to,
but
this
transaction
hash.
If
we
look
at
it
on
on
Arbor
scan.
A
A
A
A
So
it's
a
kind
of
like
LDL
one
is
it's
reading
the
state
from
the
L1
occasionally
and
one
of
those
bits
of
state
is
the
L1
block
number
you
can
access
this
as
part
of
the
arbitrary
VM
and
then
the
other
thing
is
this
gas
that
it
used
val1
and
that's
what
we're
going
to
look
into.
So
this
is
the
amount
of
gas
that
was
spent
to
send
this
traction
transaction
and
get
it
recorded
on
L1
yeah.
A
A
So
that
seems
like
a
lot
when
you
think
about
just
what
it's
doing
is
storing
just
a
bit
of
data
on
the
L1,
but
the
reason
why
it
seems
like
a
lot
is
because
this
is
in
units
of
L2
gas.
So
this
is.
This
has
been
scaled
for
what
it
would
be
if
it
was
on
L2
and
that's
just
to
make
the
accounting
a
little
bit
easier
inside
the
inside
of
arbitrum.
A
A
Okay
yeah.
So,
as
I
mentioned,
we
need
to
find
out
this
ratio
of
L2
to
L1
gas,
so
the
the
roll-up
is
is
estimating
at
any
one
at
any
point
in
time.
What
it
thinks
the
L1
gas
price
is,
and
it's
a
little
bit
more
complicated
than
just
reading
the
L1
base
V,
because
there's
a
time
lag
between
when
the
sequencer
processes
a
transaction
and
when
it
submits
it
onto
the
L1.
A
A
So
the
sequencer
never
ends
up
out
of
pocket.
They
always
get
exactly
what
they
paid,
but
there
is
some
mild
fluctuation
between
what
users
pay
now
and
what
users
pay
in
the
future.
So
some
users
now
might
receive
slightly
less
than
what
they
like
get
a
slightly
better
gas
price
than
what
they
expected.
Some
might
get
a
slightly
worse
one,
but
overall,
it's
quite
quite
close
to
the
average
quite
close
to
what
you
should
be
getting
so.
A
So
so
you
you
want
to
know
what
the
what
the
estimate
was
at
the
time
that
the
transaction
was
sent.
So
you
need
to
know
what
the
state
of
the
the
node
was
at
that
time,
and
for
that
you
need
an
archive
node,
a
full
node
wouldn't
be
able
to
do
this.
Yeah
say
again
exactly
yeah
I
think
I
think
full
nodes
do
keep
some
recent
historical
States
I
can't
remember
exactly
how,
but
probably
not
a
week's
worth
yeah.
So
you
so
to
do
this
kind
of
thing
that
we're
doing
now.
A
You
would
need
an
archive
node,
but
this
isn't
something
that
you
might
normally
want
to
do.
This
is
just
kind
of
like.
Let's
go
look
at
some
of
the
analytics.
It's
not
part
of
like
you,
don't
need
it
to
for
to
send
transactions
or
things
like
that,
and
there
are
ways
to
get
estimates
for
what
these
values
are
before
you
send
your
transaction
as
well.
So
you
know
what
you're
going
to
spend
you
don't
have
to
wait
and
inspect
it
afterwards.
If
you
want
to
yeah
I
think
there
was
someone.
B
A
It's
not
it's,
not
a
snapshot!
It's
just
well!
Yeah!
Okay!
You
you
need!
You
need
to
know
what
the
state
was
at
that
time,
because
this
is
stored
in
State.
This
L1
base
fee
estimate,
so
at
a
different
block
height
the
L1
based
vs
will
be
different
and
we
want
to
know
what
it
was
when
this
transaction
was
sent.
A
A
A
So,
as
I
mentioned,
we
want
to
work
out
this
ratio
so
that
we
can
scale
the
L1
gas
used
in
from
L2
gas
units
into
L1
gas
units
so
that
it
starts
to
make
sense
to
us
again.
So
we
also
need
to
know
what
the
L2
base
fee
was
at
that
time,
and
this
we
can
do
by
just
fetching
the
block
at
that
height
and
looking
at
the
base
fee
in
it,
yeah,
which
is
0.1
Gray.
So
arbitrum
has
like
a
minimum
L2
gas
price,
which
is
0.1
gray.
A
A
A
A
Yeah,
it's
a
really
great
question,
so
we
do
compression
over
a
full
batch
rather
than
individual
transactions,
which
does
leave
you
with
this
problem
right.
How
do
I
know
what
my
transaction,
how
many
bytes
it
will
use
in
the
compressed
batch
rather
than
in
in
in
the
other
amounts?
So
what
we
do
is
we
it's
it's
very
hard
to
figure
that
out
and
do
it
fairly,
because
it
also
depends
on
ordering
and
things
like
this.
So
what
we?
A
What
we
do,
is
we
compress
your
individual
transaction
when
we
give
you
an
estimate
for
it,
and
so
if
your
individual
transaction
is
more
compressible,
you'll
get
a
better
you'll,
get
a
better
estimate
for
it
and
you'll
you'll
be
charged
less,
but
that
still
isn't
quite
the
perfect
scenario.
But
that's
the
kind
of
like
halfway
house
that
we've
arrived
at
yeah
foreign.
A
Okay,
and
so
each
unit
of
each
byte
of
data
on
L1
consumes
around
consumes
16
gas
if
it's
a
non-zero
byte.
So
as
an
estimate,
we
can
say
that
this
consumed
around
like
180
bytes
of
data,
so
we
can
then
actually
go
and
take
a
look
and
see
if
that's
kind
of
what
it
did
consume
so
to
do
that,
we'll
rlp
encode,
the
transaction.
A
A
A
Is
there
a
way
you
don't
need
to
you
yeah,
because
what
you,
what
you,
so
what
runs
under
the
state
transition
is
the
full
decompression.
So
when
what
you're,
when
you
run
the
Ford
fraud,
proof
you're
bisecting
on
the
parts
of
the
state
transition.
So
if
the
decompression
is
within
that
state
transition,
then
yeah
you'll
be
able
to
decompress
you.
Don't
you
don't
need
an
implementation
of
the
decompression
on
L1.
You
need
it
on
L2
and
you
need
to
included
in
the
state
transition
yeah
foreign
yeah.
So
let's
try
and
explore
the
batch.
A
A
These
pre-compiles
by
the
way,
are
they're
kind
of
like
the
way
in
which
arbitrim
customizes
itself
compared
to
ethereum.
So
it
needs
to
do
some
special
things
like
this
and
they've
been
added
as
recompiles,
so
they
can
be
found
at
like
different
addresses
that
you
can
find
at
the
top
of
the
files
foreign.
A
A
little
bit
longer
wait
a
minute:
oh
yeah,
there
it
is
so
974
was
the
batch
number
I.
Don't
know
why
I
printed
some
rubbish,
but
oh
yeah,
it's
because
I
copied
the
there
we
go
yeah.
It
takes
a
little
bit
longer
that
one
because
we're
doing
oh,
no,
no,
it's
not
the
longer
one.
Okay,
this
one
might
be
a
bit
longer.
A
A
A
A
A
So
if
we
open
the
file,
we
can
see
that
it
begins
with
this
zero
zero
at
the
start-
and
this
is
not
part
of
the
compression-
this
is
just
a
a
type
of
the
data.
So
there
are
some
different
instantiations
of
arbitrim.
One
is
called
arbitrum
one.
Another
is
called
arbitrum
Nova
and
they
handle
data
in
different
ways.
So
arbitrim1
does
this
compression
it
stores
all
the
data
on
ethereum
Nova?
A
Doesn't
it
stores
its
data
with
an
external
party
that
external
those
external
parties
sign
that
they've
received
it
and
they
put
that
signature
along
with,
like
our
commitment
to
that
data
on
chain
and
this
zero
zero
here
just
tells
us
that
the
type
of
this
data
is
roll-up
data.
It's
arbitrine
one
data.
So
we
want
to
remove
that
before
we
do.
The
compression
I
do
the
decompression
sorry.
So
we
we
take
those
off
and
put
it
into
another
file.
A
A
A
A
So
if
we
look
at
that,
this
is
the
actual
batch
data
and
we
can
look
at
the
size
differences
now
between
the
the
compressed
and
the
decompressed
make
that
a
bit
bigger.
So
we've
got
this
one,
which
is
the
wait.
What
was
it
which
one
compressed,
which
is
a
198
bytes?
And
then
we've
got
the
decompressed
one
which
is
715,
so
you
can
see
the
difference
in
the
ratio
there
and
the
the
effectiveness
of
the
compression.
A
A
Isn't
actually
this
good,
because
this,
if
we
look
at
this
batch
data,
it
can,
it
includes
a
lot
of
zeros
and
zeros
are
charged
at
a
different
amount
in
in
gas
in
the
evm
they
charge
the
four
by
I
think
four
bytes,
four
four
gas
per
byte,
rather
than
16
for
non
non-zero
bytes
and
the
compressed
batch
will
be
almost
no
zeros
in
it.
They'll
be
it'll,
be
much
more
like
a
tenth
of
the
more
zeros
right
rather
than
oh,
a
16,
sorry
yeah
yeah.
A
A
B
A
A
A
Yeah,
because
when,
when
you're
compressing
the
addresses
in
in
a
batch,
then
it
does
a
lot
of
that
for
you
anyway,
like
so
it
the
two
yeah,
it's
one,
one
was
like
a
a
legacy
system
where
we
would
do
that.
We
would
allow
users
to
do
this
themselves
and
now,
like
the
whole
holistic
batch
way,
achieves
a
better
result.
A
A
A
Yeah
I,
don't
know,
I,
don't
know
how
important
it
is
to
standardize
this
specific
part
of
the
Roll-Ups,
because
it's
it's
something
that
users
shouldn't
really
be
interacting
with
generally
and
I
think
that's
the
most
important
part
to
standardize
but
yeah.
It
would
be
interesting
to
to
see
why
they
chose
those
that
as
well
yeah.
Sorry
I,
didn't
repeat
the
question
here:
I
asked
if
there
would
be,
if
there's
any
efforts
to
standardize
this
compression
algorithm
across
different
altitudes
yeah
registry.
A
Yes,
yeah,
so
there's
an
address
registry
that
you
can
use
you
you
register
and
address
against
an
index,
and
then
that
will
be
used
when
upon
execution.
You
substitute
your
indexes
into
your
transaction
and
then
there
will
be
de-substituted
from
the
registry
upon
execution
to
reduce
the
amount
of
call
data
that
even
goes
into
the
batch
itself.
Here
it
should
be
foreign.
A
A
A
B
A
So
the
question
was
the
execution
occurs
on
Layer
Two,
so
what's
happening
on
layer
one.
What
are
we
putting
there?
Yeah?
You
just
store
the
data
such
that
there's
an
there's
enough
data
there
so
that
anyone
who's
observing
ethereum
can
recompute
the
same
train,
State
transitions
that
are
occurring
on
L2
and
that's
important
so
that
anybody
can
can
take
part
in
a
fraud,
proof,
game,
yeah,.
B
A
A
A
A
Yeah,
so
to
clarify
on
what
we're
doing
here,
we're
emitting
a
sequence
number
and
what
the
L2
node
will
do
is
it
will
say:
okay,
I've
got
a
new
sequence.
Number
I'll
go
look
up
the
the
transaction
related
to
that
sequence,
number
I'll,
look
inside
the
call
data
I'll
find
the
batch,
basically
the
same
process
if
we
as
we've
just
done
and
all
of
that
all
doing
all
of
that
is
part
of
that
state
transition
function.
So
it's
all
yeah
yeah.
C
C
A
A
C
A
B
A
C
A
So
in
order
for
the
state
to
in
order
for
you
to
be
confident
of
ethereum
States,
you
want
a
wide
range
of
people
to
run
full
nodes
such
that.
If
an
invalid
State
transition
occurs,
a
large
number
of
people
can
get
together
and
form
consensus
that
that
was
an
invalid
State
transition.
That
should
be
a
rejected
fork
and
we
shouldn't
ignore
it.
A
A
A
A
A
Okay
yeah,
so
two
parties
take
place
in
a
fraudproof
game
to
figure
out
which
of
them
has
chosen
the
correct
state
and
then
one
of
them
wins,
which
is
what
you.
What
you're
asking
about,
and
at
that
point,
that
state
is
that
the
losing
state
is
rejected.
More
people
can
challenge
The
Winning
State
if
they
want
to,
but
the
losing
state
is
rejected.
A
A
What
you
see
is
the
correct
rules
and
the
same
kind
of
happens
on
L2
I
can
run
my
node
and
I
can
see
which
of
those
two
is
going
is
going
to
win
the
challenge,
because
only
one
of
them
is
correct
and
I
know
which
one
of
them
is
correct,
so
I
can
continue
to
accept
transactions
validate
them
and
we
can
continue
to
process
them
in
that
time.
What
you
can't
do
during
that
period
is
withdraw
funds
from
the
system,
so
withdrawals
are
paused.
A
Yeah,
so
the
question
is
it's
like:
if
two
two
states
are
in
violation
of
each
other,
is
people
defending
either
side?
What
is
the,
what
are
we
actually
challenging
where
what's
the
state
transition
that
we're
challenging?
Is
it
the
pre?
Is
it
from
the
previous
state
to
the
current
state,
or
is
it
further
back,
and
the
answer
is
it's
just
the
previous
assertion,
yeah
foreign.
A
Proofs
take
place
in
the
solidity
contract
and,
yes,
they
do,
but
the
way
they
the
way
they
work
is
that
there
is
a
bisection
game
that
the
two
parties
play.
We
don't
want
to
execute
the
full
State
transition
again,
so
instead
we
try
to
decide
which
part
of
the
state
transition
we
disagree
on.
So
we
take
the
state
transition.
We
bisect
it
into
many
parts.
A
We
allow
the
other
person
to
choose
which
part
they
disagree
with
and
which
part
they
agree
with,
and
so
you
always
you
have
you're
reducing
the
size
of
the
state
transition,
always
keeping
a
point
that
you
both
agree
on
and
always
keeping
a
point
that
you
both
disagree
on
and
making
that
smaller
and
smaller
and
smaller
until
you
get
down
to
a
single
opcode.
And
then
you
execute
that
single
op
code
up.
A
Is
the
question
that's
within
a
single
state
transition?
They
disagree
about
multiple
things,
or
is
it
that
there
are
multiple
people
disagreeing
about
one?
Okay?
So
if
there's
two
two
parties,
but
they
disagree
about
multiple
things,
then
I'll
just
be
the
first
disagreement
that
matters,
because
that's
all
you
need
to
to
slash
the
person
out
of
the
system
and
remove
their
their
state
from
system
yeah.
A
A
So
I
think
your
question,
I
think,
is
what
happens
if
someone
includes
an
an
invalid
transaction
in
in
the
batch
or
yeah.
So
so
the
optimum
virtual
machine
will
know
what
to
do.
If
someone
gives
in
an
invalid
transaction,
it
will
ignore
it.
Basically,
so
you
can
then
choose
to
run
a
different,
arbitrary
virtual
machine.
A
That
would
do
something
weird
with
that
and
then
we
would
end
up
at
different
states,
and
we
would
like
challenge
each
other
over
over
the
result
of
that,
but
just
including
an
invalid
transaction
in
the
batch
isn't
enough
to
like
confuse
an
honest
validator
that
something
weird
has
happened
or
that
they've
got
the
wrong
state
or
anything
like
that.
There
are
rules
about
what
to
do
for
every
bite
that
you
see
in
that
batch.
A
For
a
long
time,
so
the
question
is:
oh
sorry,
we
did
yeah.
So
the
the
question
is
given
that
during
a
a
fraudproof
game,
withdrawals
are
paused.
Isn't
there
an
attack?
You
can
do
on
the
system
to
delay
and
cause
problems
for
everyone
else
by
just
creating
a
challenge
and
what
is
the
cost
of
that
of
creating
that
challenge?
A
A
A
A
A
Is
that
a
yes
right
and
what
happens
when
someone
challenges
so
there's?
There's
a
separation
in
the
system
between
sequencing
transactions
and
generate
executing
those
transactions
to
create
a
state
to
update
state.
So
the
sequencer
has
no
power
over
what
state
will
be
update,
what
the
state
will
be
based
on
what
it
puts
there,
the
node
software
does.
So
if
the
sequencer
puts
rubbish
there,
the
node
software
like
honest
node
software
will
recognize
it
as
rubbish.
A
If
the
sequencer
puts
valid
stuff
there,
then
they
will
process
it
as
valid
stuff,
but
the
sequencer
is
all
it's
doing
is
putting
data
onto
the
chain.
They
don't
enforce
in
any
way.
What
the
state
should
be.
That's
a
result
of
that
data.
Those
are
the
validator
nodes
that
decide
that
yeah.
So,
given
just
some
data
that
arrives,
people
run
any
validator
nodes
need
to
decide
what
the
result
of
that
data
would
be
yeah.
So
that
kind
of
answered
the
question.
B
A
A
Exactly
so,
the
question
is
is
like
what
can
this?
What
powers
does
the
sequencer
have
in
the
system
and
the
sequencer
can
choose
ordering
of
of
things
inside
that
batch,
but
they
can't
manipulate
what
the
output
of
those
transactions
will
be
yeah.
So
you,
don't
you,
don't
trust
them
in
any
way.
For
the
security
of
the
system,
the
sequencer
is
necessary
for
lightness
lightness
of
the
system
to
get
transactions
moving
Fred's
like
waving
his
hand
over
there,
like.
A
Yeah,
so
at
the
moment
there
aren't
right
so
the
moment
we
trust
the
sequencer
to
pave
well,
if
they
don't,
then
we
won't
be
able
to
use
the
system
properly.
The
funds
will
still
be
safe
that
are
in
there
and
there's
a
secondary
backup
system
which
normal
users
can
use.
So
you
don't
have
to
go
by
the
sequencer.
A
If
you
don't
want
to
be,
you
don't
get
the
benefits
of
compression,
but
you
can
send
your
transaction
yourself
or
you
can
find
another
someone
willing
to
compress
stuff
for
you
and
put
it
into
into
the
system
for
you,
but
they
they
want.
Fundamentally,
the
sequencer
is
the
one
who
chooses
the
ordering
and
you
won't
be
able
to
do
that.
A
We
have
like
a
a
weight
a
time
period
where,
if
the
sequencer
is
not
actually
doing
its
job
at
all,
if
it's
not
updating
things
or
it's
not
including
these,
what
we
call
delayed
messages
which
are
user
sent
messages
via
the
L1,
then
after
a
time
period,
you
can
force
those
through
regardless
of
the
sequencer.
So
that's
the
kind
of
backstop.
A
A
A
So
that
comes
back
to
your
your
your
node
software
right.
So
if
you,
if
you
can
see
that
this
state
is
correct,
then
if
oh
sorry
yeah
yeah,
so
the
the
question
was
it's
like
what?
How
does
finality
work
in
the
system?
Given
that,
after
a
fraud
proof,
a
certain
state
will
be
rejected,
so
the
answer
is:
if
you
were
following
that
invalid
State,
then
you
will
basically
see
a
reorg,
probably
quite
a
deep
free-org.
A
But
if
you
were
running
on
a
software,
you
won't
see
and
you
won't
see
any
problems.
Basically,
you
won't
see
any
difference.
There'll
be
no
change
yeah,
but
you
can,
but
that
does
bring
into
the
question
what
the
finality
of
a
transaction
is
in
in
there
and
as
you,
as
you
pointed
out,
you
could
get
the
steep
reorg,
so
it
depends
whether
you're
running
software.
It
depends
like
whether
you're
running
node
software
or
not.
You
might
want
to
wait
just
until
that
week
period
is
off.
A
A
A
Yes,
it
will,
if
you
on,
if
you
think
that,
if
you,
if
your
node
software,
has
a
bug
in
it
or
you've,
done
something
malicious
with
your
node
software,
then
you'll
be
following
what
will
know
will
not
be
the
canonical
chain
eventually
and
so
you'll
see
results
that
will
not
never
happen
or
or
may
happen
in
a
different
way.
The
transactions
will
still
be
replayed.
So
you
all
the
transactions
are
on
L1.
So
anyone
who
wants
to
run
on
a
software
can
know
what
the
final
state
will
be.