►
From YouTube: EOS MANDEL Kickoff Meeting! (Feb 9th 2022)
Description
UNCUT Verision: https://youtu.be/Xi1bi3LIye8
All EOS Mandel Meetings : https://github.com/EOS-Nation/mandel/issues/37
#eos #eosio
A
Thanks
for
joining
this
is
our
first
call
to
kick
off
the
upgrade
of
mandel.
We'll
share
our
experiences
with
our
previous
consensus.
Upgrade
1.8
upgrade:
what's
the
code
status,
is
it
going
to
be
2.3
and
3.0,
or
a
3.1
that
sort
of
thing?
How
will
we
test
and
what's
the
strategy,
how
will
we
communicate
and
then
roles
and
responsibilities
and.
B
So
we're
calling
it
the
mandel
release.
It
is
a
plus
holder
name,
the
name
really
doesn't
matter.
The
release
itself
is
not
necessarily
time
sensitive,
there's
no
imminent
urgent
technical
requirement
for
us
to
do
an
upgrade
at
this
time.
Whether
updates
on
may
19th
may
20th
on
june
1st
on
july,
2nd
on
april
4th.
B
The
communication
strategies
in
place,
essentially
the
the
contacts
for
those
that
are
relevant
in
place,
that
we've
got
the
documentation,
the
standard
operating
procedures
and
so
part
of
this
upgrade.
The
idea
behind
it
is
to
set
all
that
foundation
so
that
in
the
future,
when
we'll
want
to
do
more
frequent
updates
and
more
important
updates,
as
eosio
plus
working
group
stands
up,
and
that
becomes
more
of
a
formal
entity
that
we
will
have
essentially
done
a
practice
run
under
very
much
test
conditions
with
very
little
outside
pressures.
B
To
do
so
right
now,
I'm
leaning
towards
advocating
for
a
few
different
things
so
the
way
that
it's
being
set
up
or
the
way
that
it
has
been
set
up
right
now,
we've
got
2.0.
So
yes,
I
o
2.0,
which
is
becoming
mandal
3.0.
We
have
the
release
candidate
one
right
now
and
eos
io
2.1
is
becoming
mandal
2.3.
B
This
has
a
few
benefits
and
it'll
also
give
a
little
bit
more
time,
depending
on
what
the
cost
is
to
add
a
few
functional
features.
One
of
the
main
drivers
for
this
update
is
to
essentially
move
away
from
the
current
repo
that
is
owned
by
block
one
to
the
community
owned
repo,
which
right
now
is
in
the
hands
of
the
enf
as
a
placeholder,
but
that
will
eventually
fall
in
the
hands
of
of
whatever
the
entity
that
leads,
eosio
plus
will
become.
B
One
of
the
extra
features
that
we're
looking
at
adding
and
we're
in
talks
with
is
stemming
from
the
api
plus
blue
paper
should
be
released
on
give
or
take
february
24th,
but
the
english
version
is
pretty
much
done
at
this
point.
It's
it's
just
finalizing
and
it's
being
sent
to
translation,
but
I
already
have
access
to
it.
The
teams
have
been
already
working
on
this
for
for
a
few
months.
One
of
the
features
that's
in
there.
B
So
it
doesn't
even
need
to
be
a
hard
fork
when
we
talk
about
the
hard
fork,
it's
because
we'd
be
enabling
certain
functions
which
would
require
people
to
upgrade.
However,
some
of
those
functions
we
haven't
deemed
it
necessary
up
until
this
stage,
it
wouldn't
necessarily
fulfill
that
requirement
of
showcasing
that
we're
not
running
the
block
one
repo,
because
those
functions
currently
exist
in
2.0
or
2.1,
and
so
we
could
potentially
continue
pointing
to
the
block
one
repo
turn,
those
on
it,
wouldn't
necessarily
showcase
that
we're
not
that
we're
running
our
our
own.
B
However,
if
we
add
the
api
transaction
life
cycle
improvements
and
those
functions
are
functional
on
whatever
version
that
we're
running,
let's
assume
is
3.1.
It
would
inevitably
showcase
that
we're
not
running
the
block
one
repo,
without
necessarily
having
to
do
a
hard
fork.
The
advantage
of
that
is
that
we'd
be
able
to
buy
a
little
bit
more
time
to
be
able
to
put
in
the
3.1
to
be
able
to
add
those
improvements,
as
well
as
then
having
a
new
function.
B
That's
there
by
a
certain
date,
depending
on
the
time
that
that
would
be
still
getting
our
opportunity
as
well
to
to
re-exercise
the
muscle
of
going
through
a
large
upgrade
like
this,
without
necessarily
enabling
the
hard
fork
functions.
Let's
say
by
the
end
of
june
or
early
july,
or
something
like
that,
and
then
only
enabling
those
hard
functions
later
on
and
so
again
it
would
buy
us
a
little
bit
more
time.
It
would
fulfill
part
of
the
business
requirements.
B
It
would
fulfill
part
of
the
technical
requirements
as
to
why
we
would
do
the
update
and
it
would
fulfill
a
few
of
the
other.
I
guess
checklist
items
that
are
a
little
bit
less
tangible
in
terms
of
branding
marketing
investor
confidence
signaling
to
the
market
that
we're
no
longer
associated
to
block
one
those
type
of
things.
So
that's
where
I'm
leading
right
now,
I'm
looking
at
what
the
costs
are
in
terms
of
time
and
actual
resources.
B
There
are
a
few
teams
that
are
helping
out
on
this
in
terms
of
core
developer
teams
in
terms
of
management,
in
terms
of
being
able
to
to
actually
write
the
code
and
such
and
so
I'll
be
able
to
provide
updates,
as
we
go
week
by
week
being
very
upfront
as
early
as
possible,
I'm
leaning
towards
doing
that.
Instead
of
doing
a
may
19th
release
of
2.3
and
3.0.
B
Having
said
that,
if
the
costs
are
too
high,
I
may
advocate
for
going
to
the
2.3
and
3.0,
which
is
the
current
approach,
and
I
do
believe
that
we're
able
to
meet
those
timelines.
We
have
roughly
three
months
from
now
before
that
date
and
whether
it's
that
date
or
a
few
days
before
after
again,
it's
somewhat
irrelevant,
but
we
are
capable
of
pulling
off
this
this.
This
upgrade.
B
B
So
it's
actually
somewhat
easier
and
there
seems
to
be
a
renewed
interest,
especially
in
the
west
anyways,
by
looking
at
people
on
this
call
to
be
able
to
help
coordinate
last
time
around
in
september
of
2019
a
lot
of
the
people
that
I've
seen
in
the
chat
here
weren't
there
at
that
time,
when
daniel-
and
I
were
posting
these
calls,
especially
for
the
first
ones,
it
was
him-
and
I,
and
maybe
michael
from
us,
eos
usa.
So
I
had
maybe
three
people
on
the
call
for
the
first
couple
of
calls.
C
We
are
now
a
business
network.
We
need
to
serve
business,
customers
we're
not
no
longer,
I
mean
three
years
ago.
We
were
bp,
mostly
near
turk.
Now
it
is
a
business
network.
We
have
a
bunch
of
exchanges,
a
few
applications
are
still
running
on
use,
so
we
need
to
serve
them.
The
goal
of
the
whole
upgrade
should
be
to
serve
customers,
not
just
upgrade
software,
because
we
want
to
yeah.
We
need
to
address
the
interest
of
of
the
customers.
First
of
all,.
A
Yep,
I
agree
good
point.
Thank
you
stan.
Our
main
objective
here
is
not
to
upgrade
to
mandel,
but
it's
to
create
the
system
that
enables
eos
to
upgrade
frequently
the
enf
has
expressed
a
goal
to
have
quarterly
upgrades
on
eos.
At
some
point,
stan's
point
about
making
sure
this
is
a
customer
focused
is
a
good
one.
One
of
my
key
results
is
related
to
kind
of
avoiding
unexpected
service
disruptions
for
exchanges
and
applications.
You
know
we're
not
going
to
be
able
to
talk
to
every
single
exchange
and
app.
A
We
can
at
least
target
over
x,
daily
volume
and
then
hope
that
captures
the
majority.
So,
as
eve
mentioned,
when
we
we
started
having
the
kickoff
calls
for
the
1.8
gram,
it
was
a
pretty
small
group
sort
of
slowly
grew
the
attention
over
time
and
had
more
people
join.
As,
as
we
went,
a
lot
of
the
work
we
did
was
asynchronous,
so
I
imagine
the
same
thing
will
happen
this
time.
I
imagine
I'll
be
doing
a
lot
of
coordinating
with
the
block
producers,
but
the
high
level
steps
were
when
we
started
the
outreach.
A
We
already
had
everything
on
jungle
and
kylan.
So
we
began
by
testing
the
1.8
features
on
both
kylin
and
jungle.
Once
we
were
confident
that
the
features
were
working
as
expected,
we
upgraded
the
bp
notes
to
1.8
without
activating
the
features
and
then
began
the
process
of
assisting
developers
in
exchanges
for
them
to
upgrade
their
nodes.
A
Once
we
had
some
more
understanding
of
how
much
time
those
stakeholders
would
need
to
do
the
upgrade
that's
when
we
set
the
activation
date
and
communicated
it
broadly
and
then
finally,
we
activated
those
1.8
features
when
we
had
strong
confidence
that
the
majority
of
impacted
stakeholders
were
ready.
If
I
recall
correctly,
we
were
pretty
successful.
I
think
there
was
maybe
just
one
exchange
that
was
not
upgraded,
and
so
there
were
some
disruption
to
service
for
that
exchange.
You
know.
We
know
that
from
the
time
that
we
publicly
announced
and
we
had
everything
on
test
nets.
A
E
A
C
So
I'll
propose
that
we
start
jungle
4
with
with
the
block
one
code,
basically
to
2.0,
latest
2.0
release
and
then
start
upgrading
the
nodes
to
mandel
3.0
see
how
they
behave,
how
the
upgrade,
how
smoothly
the
upgrade
goes,
how
it
handles
the
data
eventually
as
soon
as
3.1
is
ready.
We
will
upgrade
that
too,
and
then
we
need
to
test
the
consensus
upgrade
finally
and
make
sure
that
all
systems
are
ready.
This
consensus
upgrade
also
brings
some
changes
in
state
history.
C
B
Really
there
are
two
separate
upgrades,
so
the
I
guess
upgrading
to
3.1
should
that
be
the
route
can
occur
much
before.
I
guess
the
consensus
upgrade
so
everybody
on
the
network,
potentially
if
the
timelines
are
okay,
could
be
running
3.1
by
end
of
june
mid
july,
something
like
early
july.
The
consensus
upgrade
afterwards
of
the
functions
that
require
the
consensus
upgrade
that
could
be
maybe
two
or
two
months
later
or
so
do.
F
C
B
B
I
I
concur
with
so
we
would
do
the
2.0
to
3.0
on
jungle,
4
and
then
eventually,
3.1
and
then
eventually.
Turning
on
some
of
those
hard
fork
features
should
we
deem
them
to
be
accessed
necessary.
They
don't
necessarily
need
to
be
turned
on
if
we
don't
believe
that
they
actually
bring
any
value.
Currently
they're
not
turned
on
because
we
don't
deem
them
to
have
any
value.
Part
of
the
idea
with
the
hard
fork
side
of
things
was
in
order
to
showcase
that
we
were
not
running
the
block
one
code
anymore.
B
However,
if
we
do
have
api
transaction
life
cycles,
then
we
don't
need
necessarily
to
do
a
hard
fork.
We
would
just
have
that
function,
which
is
a
soft
work
in
3.1
without
ever
having
to
do
a
hard
four
still
meeting
that
requirement
of
showcasing
that
we're
not
running
the
block
one
or
code
repo.
We
still
need
several
things:
yeah.
C
B
C
We'll
have
eventually,
probably
several
test
nets
jungle
as
a
let's
say,
primary
public
test
net
for
everyone
to
try
their
stuff,
but
also
a
few
other.
Smaller
test
nets,
for
particular
use
case
test
scenario,
an
upgrade
scenario:
cardin
kalin,
is
basically
designed
to
be
more
stable
right,
so
current
is
for
pre-production
tests.
For
example,
upland
is
doing
all
pre-production
tests
on
carbine,
so
ellen.
C
E
A
G
C
G
Yeah,
but
you
can't
run
the
defuse
code
unless
you
have
two
point:
mandel
2.3,
so
there
are
clients
and
stuff
that
run
off
the
api
nodes
today
that
will
all
of
a
sudden
break.
So
we
would
upgrade
this.
Let's
say
we
don't
go
to
3.1
right
away.
We
would
upgrade
to
mandel
3.0
and
if
we
don't
bring
2.3
along
in
the
test
net
to
test
it
all
and
everything
for
the
upgrade.
When
we
converted
the
the
mainnet
from
block
one's
2.0
2.1
to
just
mandel
3.0,
we
would
break
stuff
like
the
defuse
code.
B
G
How
long
in
terms
of
time
we
we
can't
be
sure
when
that
will
be
done,
so
we
have
to
have
a
contingency
plan
that
says
my
opinion
you're
right
that
the
fort
jungle
4
would
have
3
mandel
3.0
in
it
and
mandel
2.3
api
nodes
in
it,
so
that
we're
testing
what
the
upgrade
for
the
mainnet
will
look
like
with
real
the
real
code.
If
we
then
get
the
3.1
code,
then
I
would
suggest
yeah,
then
we
then
we
switch
the
strategy,
but
we
don't
have
an
answer
on
that.
G
We
may
not
have
an
answer
on
that
for
weeks.
So
meanwhile,
3.0
is
ready
to
go
into
jungle
four
now
we
could
start
working
on
it
versus
waiting
and
then
finding
out.
Oh,
we
wasted
weeks
because
that's
what
we're
the
direction
we're
going
to
need
to
go
anyway.
I
I
want
you
to
know.
I
fully
agree.
We
should
go
straight
to
3.1,
it's
a
matter
of
logistics
and
costs
and
timing,
we're
not
getting
people
stepping
up,
saying
hey.
We
want
to
do
that,
merge
and
we
can
do
it
cheaply
and
quickly.
C
C
Manual,
2.3
is
kind
of
it's
a
dead
end
right.
So
this
this
branch
will
not
be
developed
further
than
to
the
tree
right.
It
costs
time
and
money
to
develop,
to
test
release
and
to
maintain
maybe
we
can
skip
it.
I
don't
know
if
we
can,
but
if
we
can,
that
would
be
awesome
to
actually
save
just
spare.
The
resources
I
mean
are.
B
C
Are
running
continuous,
I
mean
it's.
The
business
continuity
anyway
right,
so
all
nodes
will
be
still
running
for
some
time
for
at
least
next
six
months
you
don't
need
to
upgrade
the
node.
If
you
run
2.01,
you
can
keep
running
them
without
problems,
but
as
soon
as
there's
consensus
upgrade
all
nodes
need
to
be
updated
to
a
compatible
version,
so
consensus.
C
There's
evm
coming
right
so
and
yeah.
There
are
some
some
good
good
things
that
are
coming
with
this
mandel
branch,
which
might
be
required
sooner
than
we
expect.
This
is
one
one
of
the
aspects
right,
so
we
have
several
aspects.
We
have
political
aspect,
we
have
technical
aspect
and
we
have
two
branches
potentially
to
maintain
all
these
points
need
to
be
analyzed
and
all
pros
and
cons,
and
and
basically
as
soon
as
we
have
strategy
in
the
end,
we
should
also
not
be
too
confusing
for
node
operators
like
exchanges
and
applications.
I.
G
Think
the
issue
stand
is
that
right
now
we're
trying
to
hedge
both
strategies
until
we
can
get
clarity
on
which
one
is
going
to
be
and
whether
we
can
pull
3.1
off
directly.
So
we
kind
of
have
to
plan
two
paths
so
that
we're
not
just
waiting
because
waiting
would
be
wasted
time.
So
we're
kind
of
planning
two
paths
in
parallel,
hoping
that
we
can
do
3.1.
That's
eve
knows
that
that's
my
strong
opinion
that
we
should
just
go
straight
to
3.1
with
a
merged
code
base.
G
But
if,
for
you
know
numerous
reasons,
we
can't
pull
that
off,
then
we
at
least
have
to
have
a
plan
in
our
pocket
that
we
can
get
to
running.
You
know
3.0
with
2.3
at
the
same
time,
and
so
I
know
it,
it's
wasteful
that
we're
doing
double
planning,
but
at
least
it's
allowing
us
to
to
make
forward
progress
until
we
know
that
that
data
running.
C
Launching
jungle
4
with
mandel,
3.
or
whatever
mandel,
is
at
now
right.
So
now
it's
three
to
three
that
all
release
kind
of
that
are
soon
that
will
be
released
and
then
it
we'll
start
working
on
new
features
for
3.1.
We
need
to
have
jungle
4
with
with
all
that
code
available,
so
that
people
can
also
test
all
compatibility
tests
should
be
available.
G
Know
in
jungle-
four,
it's
always
is,
I
know,
there's
a
couple
of
crypto
lions
guys
on
the
call.
Thank
you
do
we
know
when
jungle
four
will
get
spun
up
with
the
mandel
three,
because
the
3.0
code
was
released.
Do
we
have
any
kind
of
timeline
and
when
we
see
mandel
3.0
will
come
up
under
jungle?
Four.
A
A
G
I'm
debating
that
a
little
bit
and
stan
knows
way
more
than
I
do,
but
I
think,
if
we're
going
to
be
testing
in
the
2.3
plus
3.0,
the
eventual
mainnet
will
run
that,
and
so,
if
we're
for
testing
in
jungle,
four,
which
would
be
a
proxy
to
what
main
that
would
be,
I
would
say
we
would
test
2.3
in
jungle,
four
alongs.
We
would
add
it
and
we'd
start
here's
my
proposal.
G
4
as
api
nodes
run
the
defuse
code
against
it
and
stuff
see,
we
didn't
break
anything,
and
so
we
know
we're
running
a
3.0
2.3
hybrid
in
mainnet
when
they
upgrade,
and
we
did
the
same
thing
and
I
would
start
by
putting
a
the
way
in
my
opinion
I
would
do
it
is
I'd
start
by
putting
some
block
1
2.1
nodes
there
and
upgrade
them
to
mandel
2.3
all
in
jungle.
Four.
All
of
that
would
be
done
in
jungle.
G
B
A
What
we've
done
is
like
the
the
bleeding
edge
stuff
happens
on
on
jungle.
We
do
the
and
then
we
we
tried
to
do
on
kylin
the
same
process
that
we
would
do
on
mainnet,
so
we're
a
little
more
open
to
breaking
stuff
on
jungle,
and
then
we
once
it's
tested,
we
kind
of
follow
the
same
activation
plan
on
kylin
that
we
would
for
mainnet.
G
I
I
just
think
that
2.3,
because
it's
going
to
be
an
api
node
of
what
should
be
a
mandel3
blockchain.
That's
why
I
think
you
need
you
should
test
it
on
jungle
4..
If
we
want
to
do
a
second
rev
like
a
whole
upgrade
directly
in
kyla,
and
that's
that's
fine!
It's
it's
just
a
that's.
Why
I'm
just
I'm
hesitant
to
say
we
should
test
2.3
in
jungle,
three,
because
jungle,
three
won't
be
running.
Mandel
3.0
block
producers
does.
G
I
would
do
for
clarity.
Daniel
is,
I
would
say,
upgrade
you
know
down
in
your
second
and
third
bullet.
Under
two
three
and
three
dough
I
would
say:
upgrade
b,
one
two
dot,
o
bps
to
mandela,
3.0
and
then
upgrade
b1,
2.1,
yeah
and
then
down
in
the
one
below
it'd,
be
upgrade
b1
for
the
api
nodes,
upgrade
b1
2.1
api
nodes
to
2.3
yeah
and
then
same
thing
in
front
of
the
bp
notes
for
3.0
b1
2.0,
2.0
yeah.
So
then
people
are
kind
of
like
oh
okay,
you're
being
very.
A
Explicit
very
literal
and
and
stan
going
to
your
your
feedback
either
of
these
could
happen
on
either
of
the
test
nets.
Depending
on
what
path
we
choose
right
now,
the
the
uncertainty
is
whether
we're
going
to
be
going
with
with
either
path.
It
would
happen
in
my
understanding
on
the
same
test
nets.
Wouldn't
they
or
are
we
going
to
be.
C
A
Whatever
path
we
take,
upgrading
jungle,
4
or
launching
jungle,
4
with
2.0
is
the
same.
We
can
start
that
process.
It
doesn't
matter
if
we
know
which
path
we're
on
up
the
second
upgrading
bp
b1
2.0
bps
to
mandel
3.0
doesn't
matter,
we
can.
We
can
start
start
that
process
and
then,
when
we
get
when
it
gets
time
to
upgrade
the
apis,
that's
when
we
have
to
stop
and
ask
ourselves:
okay.
G
Yes,
because
the
3.0
will
have
been
basically
a
throwaway
release
that
we
would
never
run
or
use.
It
was
just
used
as
the
merge
point
for
303
and
no
one
would
ever
run
300
or
23..
Those
would
just
be
had
been
done
as
ports
and
then
there's
a
merge,
and
so
no
no,
no
one
should
bother
going
through
these
ports
unless
you're
going
to
actually
run
them
for
a
period
of
time.
So
they'll
just
be
predecessors
to
the
merge.
Okay.
C
G
G
You
should
be
taking
the
main
net
from
2.0
directly
to
3.1,
and
therefore
I
mean
we
paid
for
it
already.
But
3.0,
in
my
mind,
is
just
a
port
and
some
added
features
that
got
thrown
in
and
the
merge
makes
it
where
you
do,
a
single
upgrade.
You
know
and
we'll
test
that
and
test
the
hell
out
of
that
in
jungle.
Four,
but
you
don't
want
to
make
mainnet
go
through
two
upgrades.
If
you
can
just
go
through
one
from
2.0
directly.
B
H
A
A
G
Stan's
point:
I
I
see
the
point
now:
we
could
at
least
be
testing
the
features
in
3.0
and
getting
familiar
with
them
because
they
are
going
to
live
in
3.1
and
all
it
does
is
it
makes
it
where
we
can
delay
the
decision
point.
But
then,
when
the
merge
comes,
we
would,
in
my
opinion,
just
so.
Everyone
knows
here's
my
opinion
now
for
3.1.
G
Let's
say
we
do
go
to
three
to
one.
So
I'm
going
to
go
back
and
agree
with
say
we
would
upgrade
them
to
3.0.
So
we
start
testing
right
away.
Then,
when
3.1
comes,
we
wipe
jungle
completely
and
do
the
same
line
and
do
the
beat.12.obps.3.0
we
don't.
We
don't
go
mandel
3.0
to
3.1.
We
now
start
upgrading,
b1
2.0
3.1.
That
would
be
the
following
line,
because
we'd
have
learned
a
lot
from
what
happened
in
3.0,
which
code
will
live
in
3.1,
but
we
didn't
wait
for
3.1
to
start
to
do
the
testing.