►
From YouTube: Developer Panel Discussion featuring Bart Wyatt, Tal Muskal, Syed Jafri, and Raman Bindlish
Description
During this live panel discussion, Everything EOS brings together four of the top developers working with EOSIO to share their insight and experiences working with the open-source blockchain platform. Topics of discussion may include the latest features in EOSIO 2.1 RC, Developer Tooling, Interoperability, EOSIO EVM, Blockchain for Enterprise, Public vs Private use cases, increasing usage and adoption, and more.
Bart Wyatt - Block.one, VP of Blockchain Engineering
Tal Muskal - LiquidApps.io, Co-Founder and CTO
Raman Bindlish - BlockstartVentures.com, Managing Partner
Syed Jafri - ProtonChain.com, VP of Blockchain / Bloks.io, Founder
**
https://www.EverythingEOS.io
https://youtube.com/c/Everything_EOS
Telegram
http://t.me/Everything_EOS
Audio Podcast
https://itunes.apple.com/us/podcast/everything-eos/id1434560651?mt=2
https://open.spotify.com/show/3BphPZJNjBZvxaZ3Khsukx
https://anchor.fm/everythingeos
A
A
A
Thank
you
all
so
much
for
joining
me
today,
thanks
for
having
us,
so
I'm
really
excited
about
today's
call.
It's
an
honor
to
share
the
screen
and
stage
with
you
guys
you
guys
are
all
so
accomplished.
I
feel
like
I
almost
just
want
to
be
a
fly
on
the
wall
today
and
listen
to
all
of
the
conversation
that
happens.
But
let's
kick
this
off.
This
is
the
question.
That's
been
on
everyone's
mind.
A
B
Yeah,
I
think
we
should
we
should
get
this
800-pound
drill
out
of
the
way.
So
we
can
talk
about
more
fun
stuff.
I
can't
really
share
much
about
the
the
company
reaction,
but
I
can
speak
to
the
esi
esi
side
of
it
and
also
to
the
personal
side
of
it.
You
know
I've
been
able
to
I've,
had
the
privilege
of
working
with
dan
for
about
four
years
now.
It's
just
shy
of
that.
Our
total
relationship
and
it's
been
really
amazing-
to
work
with
him.
B
B
I
think
it's.
I
think
what
I
can
say
is:
we've
we've
already
been
kind
of
moving
into
a
different
mode
of
operation
for
our
eosio
product,
and
you
might
have
noticed
these
effects
over
the
past
year
and
a
half
or
so
we
had
started
to
move
from
the
kind
of
seat
of
our
pants
development
style
that
launched
the
chain
and
was
very
appropriate
during
those
early
days
when
things
had
to
move
really
fast,
and
we
had
to
address
problems
into
something.
That's
like
a
little
more
considerate.
B
It's
actually
like
a
legitimate
software
product
life
cycle
and
with
that
we
farm
a
lot
of
our
like
inspiration,
a
lot
of
our
innovation
goals
from
the
community,
and
so
over
the
past
year,
you've
seen
you've
seen
us
form
working
groups
with
the
community.
You've
seen
us
reach
out
more
to
the
community.
B
That
will
certainly
affect
the
mainnet
and
any
other
esi
obvious
change,
and
I'm
really
excited
to
see
that,
and
we
still
very
much
have
a
team
that
inspires
me
every
day
to
work
on
that,
and
you
know
I
think
we've
got
all
the
all
the
all
the
experience
and
all
the
intelligence
in
the
community
to
still
move
forward
at
that
at
that
pace
that
everyone's
come
to
expect.
So
you
know,
like
I
said
I
wish
I
wish
dan
the
best
I'm
excited
to
see
what
comes
next.
B
I
think
you
know,
I
think,
we're
I
think
we're
good
with
eosio
and
eos,
though
I
think
we're
still
going
to
we're
still
going
to
move
forward,
and
I
think
everyone's
still
going
to
be.
You
know
kind
of
happy
with
the
progress
and
the
change
into
this
more
of
a
you
know:
legitimate
product
life
cycle.
A
There
we
go,
I'm
sorry
about
that.
Thanks
for
that
response,
you
did
address
the
800
pound
gorilla
in
the
room
and
it's
something
that
everyone's
been
talking
about,
since
it
happened
a
lot
of
speculation.
As
a
matter
of
fact
bart.
You
have
a
prediction
market
of
you
becoming
a
cto
at
block
one,
and
every
single
person
on
this
panel
has
been
speculated
on
by
the
community,
whether
that's
realistic
or
not.
I
don't
really
see
it
as
being
realistic,
but
people
have
said
like
this.
Guy
should
be
cto.
A
That
guy
should
be
cto,
that
guy
should
be
cto.
So
I'm
going
to
run
through
this
panel
here
and
let's
put
out
a
hypothetical
I'll
start
with.
You
said,
if
you
were
in
charge
of
eos
io
development,
the
road
map
of
it
brendan
bloomer,
has
addressed
this
on
twitter.
He
said
that
there
will
probably
be
multiple
ctos
for
each
individual
product.
So
let's
assume
eosio
is
a
product
in
itself.
D
D
So
I
think
if
I,
if
I
was
cto,
I
think
those
two,
those
two
would
be
my
biggest
priority
and
beyond
that
I
think
general
there's
a
lot
of
like
dev
tooling.
That
could
really
that
could
really
be
crucial.
You
know
like
even
something
as
simple
as
I
know,
block
one
funded
eos
studio,
but
I
think
that
almost
needs
to
be
like
a
core
product
of
block.
D
One
of
allowing
online
compilation
of
contracts
online
ide
just
fully
hosted
that
runs
immediately
for
developers,
so
people
don't
even
need
to
run
local
environments
etc,
and
that's
one
of
the
issues
you
see
today.
Eos
io
only
runs
in
c
plus
plus
and
not
in
some
language
like
javascript
that
you
could
run
on
the
browser.
So
it's
it's
quite
hard
to
do.
Compilation
on
in
the
browser
environment
run
contracts
in
the
browser
environment,
and
I
think
I'd
like
to
end
that.
A
Say
I
just
want
to
go
around
the
room.
We
have
a
lot
of
field
to
cover
today,
but
I
want
to
go
around
the
room
on
this
topic,
because
this
is
good
feedback
for
block
one
and
I'm
seeing
in
the
live
chat,
good
feedback
for
the
developer
audience.
We
have
today
we're
up
to
96
on
the
live
stream.
So
thank
you
all
for
joining
me
same
question
for
you
tal.
A
E
Oh
thanks
zach,
so
I
think
I
will
take
it
a
little
bit
at
a
you
know,
ten
thousand
view
feed
view.
While
I
think
these
are
great
ideas,
we
can
discuss
technology
and,
as
tal
said
very
well
that
technology
is
not
the
only
thing
which
means
it's
a.
We
are
talking
about
blockchain
we're
talking
about
open
source.
We
are
talking
about
network
effects.
E
Now,
while
we
can
always
improve,
I
would
like
to
say
that
whatever
we
have
achieved
with
the
us
io,
what
have
we
done
to
create
network
effect
within
eos
community?
That
is
one
thing
which
I
would
like
cte
of
blockman
to
look
at.
For
example,
I
think
cyad
raised
a
point
about
your
studio.
That
was
a
great
tool.
Why
block
one
would
not
improve
on
it
and
make
it
a
finished
product
or
help
make
it
a
finished
product?
E
How
do
you
bring
community
projects
and
how
do
you
make
them
successful
and
not
just
focus
on
internal
projects
like
a
lot
of
focus,
I
think
even
the
community
is
waiting
for
what
block
one
will
release
next
means.
Why
is
that?
Because
that's
not
how
you
build
open
source
or
that's
not
how
you
build
network
effects.
You
need
to
wait.
You
need
to
say
what
are
the
ten
projects,
the
best
project,
or
not
even
best
project,
even
the
like
smallest
ideas,
which
are
not
there.
E
Yet,
how
do
you
handhold
them
and
create
an
ecosystem
of
support
for
those
projects
to
to
have
community
succeed
and
as
a
technical
leader
within
block
one?
I
would
like
the
cto
to
focus
on
how
do
we
make
these
community
projects
successful
work
together,
work
in
a
better
way
and
connecting
them
with
each
other,
making
sure
that
creating
a
network
effect?
E
I
would
say
that
should
be
the
focus
even
with
like
you
know,
we
have
a
great
technology
already
means,
while
I,
because
I'm
not
as
much
of
an
expert
on
like
evm
and
stuff,
which
I
think
tal
and
say
that
in
the
best
position
to
suggest
those
technical
improvements,
but
even
with
the
current
technology,
how
are
we
making
sure
that
this
creates
the
network
effect
within
the
us
io
ecosystem?
First,
even
before
going
and
targeting
other
blockchains?
That
would
be
the
focus
for
me.
A
Right,
I'm
not
gonna
ask
the
same
question
about
that
might
be
a
weird
one,
but
I
will
give
him
a
chance
to
respond
all
of
these
suggestions,
and
maybe
let
us
know
if
any
of
these
are
kind
of
in
the
skunk
works.
They
there's
a
lot
of
ideas
shared
here
here.
Is
there
anything
that
you're
able
to
follow
up
on
and
kind
of
share
any
nuggets
with
us.
B
So
I
I
don't
get
to
say
that
the
first
thing
I
would
do
is
give
the
vp
of
blockchain
engineering
a
huge
raise.
If
I
was
a
cto
okay
well
now,
so
I
think
it's
really
interesting,
like
we've
got
three
very
independent
perspectives
that
came
out
during
that
like
syed,
obviously
has
a
very
strong
awareness
of
like
what
the
developer's
plight
is
when
they're
making
stuff
for
esio
and
so
like
that's
very
relevant
because
kind
of
as
rama
was
pointing
out.
B
B
It
has
become
a
little
more
broad
than
than
ethereum,
but
I
do
wonder
if
those
projects
are
succeeding
because
of
that
or
if
they're
succeeding,
because
they've
built
their
own
network
effects
on
other
things.
So
I
mean
this
is
all
like
really
great
feedback.
As
far
as
like
what
we
have
in
kind
of
the
skunk
works,
you
know
we're
we're
developers
at
heart
on
the
inside
of
block
one
as
well
and
a
lot
of
these
decisions
we
made
in
context.
B
They
made
a
lot
of
sense
like
that,
the
asynchronous
calling
pattern
you
know
we
were.
We
were
in
the
middle
of
some
of
the
fallout
on
ethereum
for
some
of
these
reentry
bugs
at
that
time,
and
it
seemed
like
a
great
way
to
solve.
This
was
to
be
able
to
reason
better
about.
You
know
what
the
control
flow
would
be
like
amongst
independent
contracts
and
that's
how
we
kind
of
came
up
with
the
action
model.
We
have,
and
I
admit
that
it
violates
certain.
B
B
How
do
we
meet
developers
where
they
are
as
far
as
their
understanding
of
programming
paradigms
and
languages
is
really
you
know
front
and
center
as
far
as
kind
of
our
our
internal
road
map
and
what
we're
working
towards?
So,
I
think
a
lot
of
that
stuff
will
kind
of
start
to
come
into
come
into
focus
for
the
rest
of
the
community
soon.
B
A
All
right,
so
I
I
feel
free
guys
to
jump
in
after
everyone's
response.
I
think
what
you
guys
have
to
say
is
a
lot
better
than
what
I
have
to
say,
because
I
can't
relate
to
these
topics
as
well
as
you
guys,
but
one
question
I
have
for
you
bart
is
what
is
in
your
words,
what
is
the
vision
for
eos
io
and
who
do
you
see
as
your
target
customer
base
for
eos
io.
B
Sure
I
mean
our
vision
has
been
for
the
eosio
the
product.
The
protocol
has
been
relatively
true,
the
entire
time
I've
been
here.
You
know
we
are
looking
to
build
a
highly
capable,
highly
performant
blockchain
that
can
power.
You
know
a
new
level
of
of
authenticity
and
integrity
in
business
processes
and
people's
processes.
The
world
over.
B
I
think
that's
a
lot
of
power
and
I
think
you
know
we
are
still
very
much
in
the
early
stage
of
what
that
looks
like.
So
I
you
know,
I'm
still
very
excited
about.
You
know
what
the
future
holds
for
that.
So
that's
definitely
one
of
our
customers
is
these
public
networks,
but
you
know
and
true
to
kind
of
the
vision
that
dan
before
he
resigned,
laid
out
in
a
lot
of
his
talks.
I
don't,
I
don't
think
esio
the
product
stops
there.
B
There
are
a
lot
of
things
that
are
not
yet
ready
to
fully
embrace
that
decentralized
public
access
chain
concept
that
could
still
totally
benefit
from
this
this
integrity
and
this
authenticity.
In
order
to
do
that,
I
think
eosio
has
to
kind
of
play
ball
in
a
different,
a
different
different
field
than
some
of
the
blockchain
projects
that
focus
entirely
on
you
know
public
blockchains
and
in
their
operations,
and
that's
driven
us
to
create.
B
You
know
this
level
of
performance
and
to
consider
certain
features
for
customers
that
are
doing
you
know
either
consortium
or
or
kind
of
private
chain
implementations,
but
still
want
to
bring
some
amount
of
integrity
and
auditability.
So
we
consider
we
consider
both
of
those
as
like
you
know,
parallel,
but
useful
concepts
to
have
in
in
the
short
term.
I
think
blockchain
can
still
very
much
impact
and
revolutionize
business
in
the
long
term.
B
B
It's
gonna,
be
it's
gonna,
be
really
hard
to
make
everyone
happy
in
that
in
that
relationship,
but
just
trying
to
move
the
ball
forward
so
that
we
get
you
know
better
support
on
all
those
fronts
is,
is
kind
of
like
the
the
tactical
side
of
the
core
vision
of
just
making.
You
know
the
the
best
performant
blockchain
that
can
help
us
architect,
integrity
into
the
world.
So
I
mean
it
got
a
little
lofty
at
the
end,
but
that's
kind
of
where
I
see
it
right
now.
A
So
last
time,
you're
on
here
bart,
we
talked
about
the
new
consulting
arm,
the
blockchain
as
a
service,
the
enterprise
offerings
we
have
vermont
on
this
call
rahman.
That's
like
your
bread
and
butter.
You've
been
dealing
with
enterprise
customers
for
years
now,
what's
the
reception
like
when
you're
approaching
a
new
customer
or
new
potential
customer,
and
you
tell
them
that
eosio
is
the
best
technology.
This
is
the
one
I
want
to
use
like.
What
are
the
initial
reactions?
E
E
You
know
like,
for
example,
the
enterprise
in
block
one
within
block
one
when
we
talk
to
the
enterprise
group
and
so
on,
which
is
trying
to
help
get
this
into
like
enterprise,
your
sio
efforts,
but
anyway,
coming
back
to
your
questions
zach
on,
because
what
is
the
advertisement
for
your
cio?
That's
a
public
blockchain
right
when
script,
everybody
who
comes
to
blockchain
they
look
at
ethereum
is
the
biggest
smart
contract
platform,
and
then
we
have
this
recently
polka
dot
emerging
and
many
other
smart
contract
platforms
emerging.
E
And
if
there's
no
public
blockchain,
like
you,
know
kind
of
a
marketing
efforts
or
there
is
no
like
good
reputation
built
around
public
networks,
then
it's
very
difficult
to
sell
the
software.
It's
very
difficult
to
sell
eosio
based
solutions
because
of
course
it's
a
great.
I
think
we
can
always
talk
about
the
speed
of
your
sio.
It's
very
easy
when
we
get
to
the
technology
levels,
to
the
people
who
do
not
have
any
preferences.
E
Eosio
is
not
a
tough
sell
and
then
you're
talking
about
blockchain
and
bringing
it
doesn't
matter
to
them
which
stack
you
use.
But
when
we
talk
about
people
who
are
like
aware
of
what's
going
on
in
blockchain
world
who
are
coming
from
the
you
know,
the
reputation
angle,
eosio,
it's
it's
many
times,
you
hear
anything
but
yourself
don't
even
talk
about
yourself.
Let's
focus
on
something
else.
Can
you
do
something
else?
So
this
is
what
I
think
is
a
challenge.
E
We
need
to
go
and
figure
out
and
again
going
back
to
bart's
point
eos,
mainnet
or
public
networks
being
the
customers.
It
would
be
a
lot
of
help
if
block
one
or
the
technical
teams.
There
is
an
effort
to
go
and
build
some
viability
into
that.
At
this
moment,
it's
becoming
more
like
a
kind
of
a
step
child
treatment
where
rock
one
is
focusing
on
its
own
projects
and
your
cio
and
I'm
sure
means
I
think
we
keep
hearing
people
from
like
block
producers
and
eve
and
other
people.
E
They
tell
us
how
great
the
support
is
for
block
producers.
I
completely
understand
it
and
I
think
I'd
be
appreciate
block
one
doing
all
that
for
your
cio
and
the
growth
means
I'm
not
discounting
that.
But
what
I'm
saying
is
that
is
happening
behind
the
closed
doors
that
is
probably
could
have
been
done
more
openly.
There
should
be
probably
discussions
happening,
how
the
issues
were
resolved
instead
of
having
in
private
groups
or
in
some
smaller
groups.
E
We
need
to
it's
very
difficult
for
us
to
market
eos
io
from
that
perspective
and
recently
because
and
to
be
frank
last
two
years
it
was
hardly
anything
was
viable
other
than
your
scio,
because
we,
when
we
go
to
enterprise
solution,
then
we
say
we
want
to
scale.
Usi
was
the
only
scalable
solution
and
now,
with
the
help
of
liquid
apps
and
what
we
have
done
with
the
you
know
the
offer
solutions
we
have
built
with
the
like
kind
of
liquid
chains
and
you
know
connecting
them
to
mainnet.
E
So
there
are
a
lot
of
possibilities
now,
so
eosi
are
still
way
ahead
of
others
like
when
we
talk
about
polka
dot,
which
is
so
popular.
I
don't
know
why,
because
they're
not
even
launched
yet
like
there's,
no
para
channel,
there's
nothing
which
we
can
go
and
use,
but
still
that
is
the
first
choice
right
now,
and
I
think
that's
where,
when
you
talk
about
enterprise,
when
you
talk
about
how
can
we
bring
more
usage
of
yours,
I
o,
which
is
probably
more
ready,
means
again.
E
We
can
always
discuss
technology
and
saying
why
ethereum
or
solidity
or
all
these
things
are
better
or
not,
but
in
terms
of
readiness
in
terms
of
scaling.
Esio
is
way
ahead
of
anybody
else.
Right
now
in
terms
of
what
solutions
are
available
beyond
the
developer
tools,
of
course,
we
are
struggling
as
developers.
E
We
always
struggle
to
go
and
say
how
best
we
can
make
these
things
happen
and
the
ecosystem
is
not
there,
but
once
you
do
it,
the
solutions
are
working,
and
but
the
challenge
we
face
is
that
they
say:
oh
anything
but
yours
that
just
kills
the
conversation.
And
then
you
have
to
go
back
to
drawing
board
and
saying:
let's
do
something
else.
So
those
are
the
kind
of
things
I
would
still
go
back
and
say
it
has
to
be
a
joint
effort.
E
We
cannot
ignore
public
maintenance,
while
saying
the
technology
is
progressing
and
eosio
is
great,
because
that's
what
is
the
marketing
channel
for
any
software
blockchain
software,
because
it's
ultimately
open
source,
and
it
is
if
you
prove
that
you
have
the
longest
running
reputed
chain
and
a
public
network
that
is
the
best
advertisement
for
enterprise
to
go
and
trust
your
cio
and
say.
Yes,
I
want
to
build
on.
A
D
I
agree,
I
think
I
mean
you
know
even
going
back
to
what
tall
said
about
evm,
I
don't
and
bart's
question.
I
don't
think
the
evm
really
like
sure
it
adds
some
interoperability
and
the
fact
that
people
can
take
like
solidity
contracts
and
can
deploy
it.
But
I
mean
you
got
you
got
to
think
about
that
the
evm
ability
has
been
on,
let's
say,
tron
forever.
It
has
been
on
other
chains
for
a
very
long
time,
even
something
like
etc.
Right,
like
has,
is
just
a
fork
of
ethereum.
D
It
has
evm
capability,
just
adding
evm
capability
and
making
a
faster
really,
which
is
what
a
lot
of
chains
are
doing.
Now.
If
you
look
at
something
like
matic
as
like
a
layer,
two
for
ethereum,
et
cetera,
they're,
all
just
eve
faster
evms.
That's
that's
not
really
going
to
cut
it
long
term.
I
think
for
a
chain,
because
one
day
or
another
ethereum
will
just
catch
up
to
that
and
it
will
have
a
faster
evm
too,
and
what
the
network
effects
will
roll
over.
D
So
I
think
you
really
need
to
you
really
need
to
attack
it
from
a
different
perspective.
From
a
different
angle-
and
I
think
I
think
one
of
the
one
of
the
best
ways-
and
I
want
to
go
back
on
this
point-
is
one
of
the
best
ways
you
can
do.
This
is
by
tapping
into
a
a
developer
base
that
I
think
no
one
really
has
like.
D
I
think,
if
eos
io
could
prioritize
getting
eos
contracts
working
through,
let's
say
like
typescript
or
javascript,
it
really
will
open
up
eosio
to
millions
of
developers
that
can't
do
contracts
anywhere.
Evm
is
still
almost
like
a
completely
new
language
like
sure
it
might
be.
You
might
be
possible
to
go
from
javascript
to
solidity,
but
you
still
have
to
learn
a
ton
of
new
stuff.
Now,
compare
that
to
let's
say
eosio,
you
can
make
contracts
with
javascript.
D
I
think
that
would
really
attract
a
lot
of
developer
talent
for
the
market
itself.
I
think
the
market
like
for
enterprise
there's
no
other
answer
really
than
a
lot
of
a
lot
of
marketing.
Like
you,
you
need
those
evangelists
block,
one
funded
evangelists,
essentially,
who
are
going
out
and
evangelizing
eosio
to
these
fortune,
500
and
other
companies
and
in
other
ecosystems
you
see,
like
you
see
this
happening
very
readily.
I
mean
I'm
not
sure
about
how
much
of
that
is
happening
inside
block
one,
because
I
don't
have
visibility
there.
D
But
you
look
at
the
web
3
foundation.
They
have.
They
have
evangelists,
you
look
at
consensus.
They
have
evangelists
for
ethereum
tron
foundation,
et
cetera.
They
all
have
evangelists
that
go
to
these
enterprise
and
try
to
convince
them
about
the
technology,
and
once
you
have
these
evangelists,
then
you
can
really
start
to
clear
out
some
of
the
misconceptions.
You
know,
because
a
lot
of
these
people
that,
like
let's
say
the
raman,
is
going
to
they've
just
never
heard
of
eosio
or
if
they
have
it's
in
a
negative
light.
D
So,
if,
if,
if
there's
already
a
communal
effort
or
a
strong
enterprise
effort
to
dispel
these
myths
and
dispel
the
negative
connotations
that
are
just
starting
to
bite
or
have
already
formed,
it
really
makes
it
much
easier
to
create
a
network
effect,
be
it
in
the
enterprise
world
or
outside
it
outside
the
enterprise
world.
It
takes
the
same
thing
you
need.
E
One
thing
I
would
like
to
say,
like
I
completely
agree
with
you
and
I
have
actually
found
easier
to
hire
c,
plus
plus
developers
than
solidity,
because
it's
much
easier
there
are
much
many
more
people
out
there
who
can
do
it.
They
don't
need
to
know
blockchain,
because
you
can
just
teach
them
how
to
write
smart
contract,
which
is
much
easier
in
c
plus
plus
than
solidity.
E
On
the
other
hand,
I
think,
when
you
say
marketing
facebook
doesn't
facebook
does
how
they
do.
It
is
by
supporting
react
developers
by
solving
their
problems
by
hosting
forums,
and
you
know
their
their
facebook
how
the
corporate
work
world
works.
When
you
say
apple,
google,
facebook,
the
tools
they
build,
they
pay
for
open
source
developers
to
go
and
support
and
what
issues
they
are
facing
and
not
like
you
know,
leave
them
saying
that
okay,
you
go
figure
out
like,
of
course,
initially
the
documentation
is
low
on
open
source.
E
E
Know
we
had
100
plus
people
in
silicon
valley
coming
and
attending
eosio
workshops.
We
had
hardly
any
tool
and
we
spent
like
half
a
day
just
trying
to
set
up
a
basic
environment
to
develop,
and
that
was
unfortunate.
But
on
the
other
hand,
when
like
at
that
point,
there
was
hardly
any
help
available.
Even
today,
as
I
think
we
are
discussing
all
these
tools,
developer
tools
have
to
improve.
E
There
have
to
be
direct
outreach
and
special
community
people
which
are
driven
by
and
backed
by
probably
some
of
the
investments
that
are
going
into
esi
or
development
itself.
Instead
of
developing
next
year
usi3.
We
have
to
first
make
sure
that
esio
two
developers
get
the
support
they
need,
and
there
has
to
be
a
very,
very
strong
network
of
you
know,
support
engineers
for
that,
and
people
will
not
know.
E
If
we
expect
people
to
know
where
to
ask
the
question,
then
you
are
not
building
a
great
open
source
community,
the
writers
of
the
software.
When
you
say
facebook,
google
apple
they
reach
out,
they
reach
out
to
developers
and
they
actually
fund
this
community
support
people
to
go
and
actually
reach
out
to
where
how
they
are
facing
problems
and
solving
their
problems,
rather
than
waiting
for
them
to
come
and
find
the
right
channel
and
that's
what
they
did
in
initial
days.
E
That's
how
they
made
these
software
successful
and
again
I
will
go
back
to
doing
things
in
open
like
showing
that,
even
if
it
means
I'm
sure
means
I'm
sure
a
lot
of
people
are
not
are
not
even
aware
it
was
block
one
developers
like
where
to
reach
out
to
them
for
help.
That's
why
doing
these
things
in
open
doing
it
in,
like
you
know,
github
discussions
getting
the
like,
you
know,
have
opening
more
and
more
forums
as
many
places
as
possible.
E
I
think
that
would
help
developers
see
those
things
and
they
will
know
where
to
reach
out.
We
have
to
reduce
this
block
of
oh.
Can
I
really
talk
to
brockman
developers.
That
is
not
there.
When
you
are
developing
on
android
or
you
know,
ios.
There
are
enough
community
support
everywhere,
and
I
think
that
has
to
be
developed,
and
I
would
say
that
is
a
marketing
effort
which
these
people
did
like
when
you
say
facebook,
whether
they
did
they
supported,
react
developers.
D
Right
right,
yeah,
I'm,
I
would
agree,
I
mean
I
think
when
you
say
developing
in
the
open,
I
think
block.
One
does
like,
I
think,
a
lot
of
the
issue.
If
you
look
in,
if
you
look
at
github,
a
lot
of
the
stuff
that
comes
out
is
public.
I
would
say
it's
open.
It's
not
necessarily
closed
door.
Even
a
lot
of
the
issues
that
you
find
in,
like
people
find
issues
in,
let's
say
jungle
test
net.
A
lot
of
those
telegram
chats
end
up
into
a
github
issue.
D
So
I
don't
think
it's
necessarily
not
open
from
that
angle.
I
think
where
transparency
is
needed.
Is
these
bigger
upgrades?
Like
you
look
at
the
one
of
the
things
I
would
like
to
see.
You
look
at
the
eosio
spec
repo
thing
right
where
it's
essentially
it's
essentially
like
a
watered-down
version
of
like
improvement
proposals
for
eos
io.
We
saw
those
come
out
and
like
it,
it's
great.
D
D
Even
if
you
look
at
some
things
like,
let's
say,
let's
look
at
their
react
timeline
like
when
they
have
these
improvement
proposals.
They'll
give
a
target
date
like
this
will
come
in
quarter
three
twenty
twenty
or
this
is
coming
in
quarter,
four,
twenty
twenty
one,
so
developers
have
a
mental
model
of
like
where
the
software
is
today.
Where
is
it
going
and
that
clarity
does
not
exist
in
eos
io
today,
I'd
love
to
hear
bart's
thoughts
on
that
too.
B
B
Your
expectation
is
that
it
will
change
in
minor
ways
at
most
before
it
goes
live
on
whatever
the
date
it
is
in
in
terms
of
esio
and
really
software
development
in
general,
you're
always
making
choices.
You
know
we
can't.
We
can't
necessarily
build
the
perfect
software.
That
does
everything,
so
we
have
to
kind
of
triage
and
and
like
rigorously
prioritize
these
things
and
then
also
close
some
doors.
B
You
know
where
our
community
developers
is
at
and
make
that
decision
somewhat
in
conjunction
with
them,
so
that
we
that
we
know
that
when
we
are
essentially
committing
the
community
to
close
some
doors,
that
everyone's
okay
with
those
those
doors
that
we're
closing
and
we
can
get
more
specific
about
it
by
taking
like
a
specific
one
of
those
spec
repo
topics.
But
that's
the
kind
of
that's
the
kind
of
level
at
which
that
spec
repo
is
supposed
to
operate,
and
I
think,
unfortunately,
it
it
kind
of
failed
to
launch.
B
We
didn't
get
a
whole
lot
of
meaningful
interaction
with
the
community
out
of
it,
and
so
we
didn't
get
the
information
that
we
really
needed
to
go
forward,
and
that's
also
why
some
of
those
features
have
kind
of
hung
there
for
a
while,
because
we
still
have
to
make
some
hard
choices
about
them.
We
still
don't
feel
like
we've
gotten.
You
know
a
really
good
viewpoint
about
whether
one
decision,
the
other,
would
be
better
accepted
by
the
community.
I
mean
there's
there
are
proposals
in
there
for
things
that
would
dramatically
affect.
B
B
B
Also
this
question
of
even
if
we
have
some
of
these
things,
roll
out
and
and
make
the
technology
innovation
move
forward
at
a
rapid
clip,
can
we
can
we
get
to
where
we
want
to
go
both
as
a
product
team
and
as
a
community
based
on
that
technology,
innovation
alone,
because
you
know
believe
it
or
not
block
one
has
constrained
resources
in
that
we've
only
got
so
many
developers.
We
can
allocate
certain
things,
and
so
we
had
to
trade
between.
B
We
need
to
go
out
and
solve
the
problems
for
the
people
who
are
out
there
right
now.
Building
those
relationships
and
those
are
those
aren't
always
the
same
path.
Sometimes
those
are
very
divergent
paths
and
you
know
block
one
is
not
a
not
not
yet
perhaps,
but
not
currently
a
you
know
a
mega
corporation
with
thousands
of
developers
to
kind
of
move
around
the
map
and
allocate
like
we're
playing
a
game
of
risk.
B
We
still
have
a
very
tight,
cohesive,
small
team
on
this
core
product,
and
so
we
have
to
make
those
kind
of
tougher
choices.
Do
we
do
we
pursue
some
of
the
things?
I
think,
if
you
look
at
the
the
2.1
features
that
we
put
out,
you
can
see
a
pivot
into
focusing
a
little
bit
more
on
some
more
practical
things
like
you
know.
What
are
we
going
to
do
as
far
as
like
data
scaling
in
the
future?
Can
we
get
something?
That's
not
in
ram?
B
What
are
we
going
to
do
as
far
as
like
hardening
your
infrastructure
against?
You
know,
failures
and
disasters,
and
you
know
so
we're
kind
of
in
we're
kind
of
in
that
the
pendulum
is
slowing.
That
way
right
now,
and
I
think
you
can
see
that
reflected
in
what
we've
released
and
it
it
might
need
to
swing
back.
It's
certainly
an
interesting
conversation
to
have
into
some
of
the
more
innovation
things
I
don't.
I
don't
know
that
we
can
necessarily
or
want
to
necessarily
unilaterally
make
that
decision
as
block
one.
B
So
we
are.
We
are
definitely
hoping
for
a
little
bit
of
community
feedback
and
participation
there
to
help
us
know.
You
know
not
perfectly
which
way
to
go,
but
at
least
better,
better
map,
the
resources
we
have.
The
people
that
we've
trained
up
to
be
able
to
do
these
kind
of
complex
hard
things
with
the
you
know.
Triage
primary
list
of
like
okay.
B
So
I
mean
here
is
an
here's,
an
interesting
here's,
an
interesting
insight
into
kind
of
like
some
of
the
the
thinking
that
goes
on
behind
the
scenes,
particularly
on
that
topic.
We
have
at
least
I'm
only
going
to
talk
about
two
major
major
pathways
to
take
on
that
pathway.
One
is
we
can
take
the
kind
of
ad
hoc
approach
and
punch
host
functions
through.
B
If
you
were,
if
you
actually
like,
make
a
white
paper
and
draw
like
the
mathematical
equation
of
what
is
consensus
on
esio
each
one
of
those
things
comes
with
at
least
a
paragraph,
probably
more
like
a
couple
pages
of
things
that
it
must
do,
and
it's
easy
to
look
at
and
say
like.
Oh
that's,
that's
easy!
Just
you
know
hit
this
and
then
like
here.
B
Here's
where
the
output
comes,
and
then
we
look
at
it
and
we
say
okay
but
hold
on
like
if
there
was
a
competing
implementation
like
what
are
the
aliasing
rules
for
these
parameters.
What
happens
if
this
is
in
this
section
of
memory
and
it
like
overwrites,
a
certain
thing
and
what
we
have
to
look
at
all
that
stuff,
the
that's
the
price
we
pay
at
the
consensus
level
and
at
the
you
know,
car
hardening
level,
but
the
benefit
there
is
that
you
go
native
with
it
right
like
at
that
point.
B
You're
you've,
you've
flipped
from
your
kind
of
like
safe
webassembly
sandbox
into
native
code,
and
you
can
get
really
fast
with
that,
because
you
can
access
basically
anything
on
the
native
host,
including
you
know,
hardware,
acceleration
or
anything
like
that
that
we
might
have
access
to
so
there's,
there's
pros
and
cons
to
that,
pretty
pretty
steep
pros
and
cons.
The
other
side
of
it
is.
B
You
know:
we've
invested
a
lot
in
this
concept
of
eos
vm
and
we
have
a
lot
in
the
future
that
we're
going
to
invest
in
terms
of
making
that
vm,
smarter
and
making,
particularly
the
the
like
jit
step,
the
the
compilation
step
that
turns
it
into
native
machine
code.
A
lot
smarter,
I
hope,
I'm
not
I'm
not
gonna
make
anyone
mad
by
mentioning
like
one
of
the
unique
aspects
of
of
you
know.
B
Do
we
instead
lean
into
making
eos
vm
fast
enough
to
where
you
can
do
all
this
in
webassembly
and
we've
had
people
that
have
tried
to
do
it
in
webassembly
and
to
various
degrees?
You
know,
succeeded
it's
some
of
the
early
work
was
taking
like
a
vanilla
library
off
the
shelf
and
putting
it
in
there
and
that
didn't
always
work
out
too.
B
Oh,
I
know
I'm
going
to
do
some
upfront
work
when
you
initialize
this
library,
pre-calculate
a
bunch
of
tables,
make
this
whole
thing
faster,
so
that
at
run
time
in
your
critical
path,
everything
is
very,
very,
very
fast
and
snippy
that
doesn't
work
really
well
for
esio,
because
we're
going
to
do
that
installation
initialization
step
on
every
action
and
you
don't
really
get
the
amortization
benefits.
In
fact,
it
can
be
a
negative.
B
So,
as
we
started
to
see,
people
do
more
tailored
libraries
for
these
cryptographic.
Primitives
the
performance
started
to
to
trend
up
and
give
us
this
idea
that,
like
maybe
maybe
there
was
a
more
sustainable
long-term
way
of
of
getting
this
done,
and
that's
currently
kind
of
the
internal
debate
where
we
are
as
far
as
the
cryptocurrencies.
How
do
we?
B
How
do
we
deliver
that
to
you
in
a
way
that
we
aren't
going
to
have
to
rip
the
rug
out
from
under
you
in
a
year,
because
we
realize
that
we
took
the
unsustainable
path
or
the
the
path
that
won't
ever
get
you
the
performance?
You
need
to
do
like
a
full
zk
stark
of
whatever
your
application
is.
So
I
mean
it's
that,
as
you
can
tell
you
hit,
you
hit
a
particularly
hot
topic
for
some
of
our
internal
discussions.
B
So,
but
hopefully
I
can
like
peel
back
the
layer
and
show
you
that
some
of
these
things
are
are
like
hotly.
You
know,
debated
and
and
have
some
very,
like
some
very
esoteric
edge
cases
that
we
need
to
consider
so
that
we
don't
end
up
driving
the
protocol
into
a
place
where
we
can't
really
take
it
forward
and
succeed
with
it.
C
C
B
We
don't
we
don't
have
that
toolified
or
programified
right
now.
That's
more
of
the
educational
component
kind
of
inside
of
block
one
of
getting
people
from
you
know
new
developers
to
blockchain
technology
to
the
expert
level.
They
need
to
be
able
to
like
make
these
surgical
changes.
It
is
something
that
I
think
you
know
from
from
a
contributions
to
the
the
greater
technology
world
that
I
would
like
for
us
to
be
able
to
formalize
and
release,
as
you
know,
courseware
and
things
like
that.
B
But
it's
a
super
advanced
topic,
so
it's
it
might
be
a
while
before
our
our
training
portal
includes.
You
know,
advanced
blockchain
concepts,
500
that
has
seven
years
of
of
of
prerequisites
for,
and
only
one
person
or
two
people
on
the
planet
are
gonna
are
gonna
take,
but
it's
it
is.
It
is
fascinating
work,
I
think,
maybe
the
better
option
there
is
to
eventually
get
some
of
these
people
who
do
this
day
in
day
out.
B
If
I
can
get
them
to
stop
having
massive
migraine
headaches,
you
know
to
kind
of
come
out
into
the
world
and
start
talking
about
some
of
these
things.
So
people
can
get
an
idea
of
the
level
of
rigor.
We
apply
to
some
of
that
stuff
for
sure.
But
it's
it's
not
it's
not
something
that
we
have
like
formal
verification
for
yet
and-
and
you
know
in
this
case,
I'm
talking
about
protocol
level
stuff,
not
necessarily
like
smart
contract
application
level
stuff,
even
though
they
play
together.
It's
not
not
the
same.
D
B
B
Technologies
like
black
vault
are
eventually
going
to
play
somewhat
of
a
role,
if
only
tangentially,
in
something
like
ibc,
because
as
we
start
to
tighten
up
those
guarantees
for
safety
of
block
production
block
production,
then
on
some
of
these
you
know
side,
chains
and
sister
chains.
You
can
you
can
reel
in
finality.
B
B
A
A
He
was
talking
about
how
there's
half
second
finality
for
enterprise
applications
he's
currently
implementing
a
product
that
utilizes
four
independent
private
chains,
all
communicating
and
validating
across
all
chains,
and
then
we
hear
about
voice
which
isn't
open
source
and
a
lot
of
this
stuff
might
not
be
open
source.
But
a
lot
of
the
community
is
looking
towards
block
one
to
say:
let
us
see
the
best
practices
for
what
you
guys
are
doing.
You
guys
know
the
software
better
than
anybody.
B
I
mean,
I
think,
it's,
I
think,
that's
fair
criticism
for
sure
and
I
can't
really
speak
to
plans
to
open
source
some
of
the
products
that
dan
was
talking
about
when
he
was
making
those
those
tweets,
and
things
like
that.
I
do
think
you
know.
I
do
agree
that
these
kinds
of
these
kinds
of
the
things
that
we
learn
from
from
doing
these
technological
push
and
lifts
are
definitely
things
that
would
have
value
kind
of
coming
out
and
into
the
world.
B
C
I
think
the
community
is
already
kind
of
digging
into
every
less
detail
of
everything
that's
already
out
there.
So
I'm
not
sure.
That's
that's
correct.
I
think
everything,
that's
every
reference
will
be
better
than
nothing
in
my
opinion
and
any
reference,
even
if
it's
an
undocumented,
it's,
I
think
it's
better,
even
to
show
like
where
things
are
going
going
internally
and
and
what's
being
adopted
and
what
kind
of
approaches.
E
And
also
I
I
would
like
to
add
to
that
said
like
I,
don't
think
anybody
even
like
it's
very
difficult
to
track
decentralized
development,
and
I
can
tell
you
like
block
one-
would
be
surprised
to
see
how
much
development
is
going
on,
even
though
there
is
all
this
negativity
around
it.
The
eos
io
is
being
developed
like
those,
so
many
people
are
still
developing
and
assuming
that
it
will
not
be
useful,
I
would
say,
is
a
big
mistake
from
block
one
means
anything
you
can
put
out.
E
There
would
be
very,
very
useful
and
we
don't
want
to
reinvent
that's
the
whole
point
of
open
source
like
nobody
wants
to
reinvent
things.
You
want
to
give
as
many
examples
as
you
can,
which
you
have
developed
to
be
used,
and
that
is
all
about.
Like
we
started
with
that
network
effect
question,
that's
how
you
create
network
effect.
If
you
have
templates,
you
have
solutions
which
people
can
join
together
and
form
new
ideas,
and
that's
the
best
contribution
blockchain
technical
team
can
give
to.
You
know
the
developers.
E
C
Yeah
and
I
wouldn't
even
wait
for
examples
to
be
like
stable
and
finalized,
we
can
expect
that
if
you
rapid,
rapidly
prototyping
things,
we
can
expect
things
to
be
to
be.
You
know
in
alpha
stages,
but
but
I
I
think
it's
still
better
than
than
getting
things
in
like
changing
the
roadmap.
Every
six
months,
like
in
a
in
a
more
monolithic.
B
D
Yeah,
I
think
I
I
think
I
think
if
you
look
at
even
I
mean
we
keep
going
back
to
react,
but
if
you
look
at
react
like
everything
on
react
starts
from
like
zero,
like
everything
is
done
in
public,
you
know
in
a
way
there
it
goes
to
pre-alpha
alpha
beta,
but
it's
done
all
in
public.
I
I
I
think
that
would
be
yeah.
I
think
I
think
it
would
be.
A
All
right,
so
I
I
had
planned
to
ask
a
bunch
of
years.
I
had
2.1
questions
to
bart.
We
didn't
really
get
to
a
lot
of
them,
but
I
did
want
to
ask
one
that
phil
from
chintai
had
asked
about
it
publicly
on
twitter
and
was
looking
to
get
answers.
I
saw
someone
from
block
one
answered
on
the
stack
exchange,
but
I
maybe
want
to
get
a
more
thorough
answer
here.
So
roxdb
was
something
that
was
highly
anticipated
and
introduced
in
eos,
io
2.1.
B
B
B
B
But
there
will
be
some
point
when
you
know
the
amount
of
ram
you
would
want
to
put
on
a
single
node
in
order
to
process
a
chain
would
get
so
out
of
hand
that
it's
just
the
economics
don't
make
sense
as
far
as
like
sustaining
that
chain.
So
it's
kind
of
a
this
is
kind
of
a
you
know
like
a
y2k
style
problem
for
eosio.
B
We
know
that
at
some
point
in
the
future,
we
don't
know
when
exactly
esio
based
chains
will
will
exceed
the
kind
of
economic
feasibility
of
backing
everything
with
physical
ram,
at
least
at
the
ratio
that
chain
base.
Does
it
right
now,
which
is
not
to
say
that
there's
not
a
future
ram
based
technology
that
might
work?
It's
just
that
you
know.
We
know
we
had
to
make
progress
on
this,
so
roxdb
was
kind
of
a
like
a
promising
first
attempt.
B
There
always
has
to
be
a
first
attempt
when
you're
trying
to
take
something
and
and
kind
of
fan
it
out
into
multiple
options.
So
a
lot
of
the
a
lot
of
the
work
that
you
get
in
2.1
is
actually
not
on
the
surface.
You
can't
really
see
it.
It's
all
the
work
that
happened
behind
the
scenes
to
make
it
to
where
you
could.
You
know,
have
multiple
backing
stores
at
all,
whether
it's
ram
based
with
chain
base
or
whether
it's
disk
space
with
with
roxdb.
B
So
I
mean
that's
kind
of
like
the
history
of
like
you
know
the
problem,
we're
signing
at
a
high
level
of
problem
we
need
to
solve
and
why
we
were
looking
at
rocks
db.
It
gave
us
a
different.
A
different
set
of
you
know,
economic
things
to
tweak.
Now
we
can
talk
about
okay.
Well,
what's
the
cost
of
having
ssd
space
on
a
node
instead
of
physical
ram
in
2.1?
B
So
if
you
think
about
it,
like
our
token
balances
on
on
the
eos
main,
that
are
very
small,
so
having
a
lot
of
token
balances
like
running
a
digital
currency
or
something
like
that
is
probably
not
the
use
case,
it's
eventually
going
to
push
you
out
of
ram.
Now
you
mentioned
something
like
voice
voice
is
storing
you
know.
Well,
I
actually
don't
know
what
voice
is
storing
they're
their
own
application,
but
let's
speculate
that.
We've
got
some
sort
of
document
publishing
platform
and
they
want
to
store
the
documents
on
the
chain.
B
You
know
that's
going
to
be
much
bigger
than
a
row
in
the
database
for
like
a
currency
balance,
and
it
could
be.
You
know,
really
large,
like
multiple
k,
maybe
even
megs,
that
database
is
going
to
fill
up
a
lot
faster
than
than
your
token
database,
and
that
database
is
the
one
that's
going
to.
You
know
that
that
blockchain
application
is
the
one
that's
going
to
threaten
your
your
kind
of
like
upper
upper
limit
of
viability
for
a
ram-based
system
faster.
B
Again,
not
sure
the
the
first
step
is
having
any
optionality
there
and
the
second
step
will
be
refining
roxdb,
getting
it
to
the
point
where
we
think
it
is
as
ready
for
prime
time
as
it
can
be
letting
the
community
provide
feedback.
You
know
here's
here's
the
use
case
that
worked
better
here
and
there
so
that
we
can
educate
ourselves
through
kind
of
like
that
collaboration
and
then
maybe
maybe
that's
it.
B
B
So
I
mean
right
now:
it
is
designed
to
be
a
a
node
by
node
choice.
So
there's
no
there's
no
mechanism
by
which
you
can
enforce
the
entire
main
net,
like
swap
from
one
to
the
other.
I
think
it
is
intended
to
be
something
that
will
be.
You
know
once
it's
out
of
like
kind
of
the
developer
preview
and
and
and
as
good
as
we
can
make
it.
I
hope
it's
something
that
that
can
sustain
the
main
net
for
now.
B
I'm
going
forward
in
that
kind
of
like
heterogeneous
mode,
where
some
nodes
are
going
to
run
it
because
they
want
to.
They
want
to
pay
the
cost
for
ssd
style
access
and
other
nodes
are
not
going
to
run
it
because
they're
more
comfortable
with
the
ram
based
backing
and
then
it
would
be
kind
of
community
driven
and
loose
as
to
whether
or
not
the
use
cases
on
the
main
net
end
up
making.
You
know
shifting
the
node
operator
economics
one
way
or
the
other
like
if
they
all
consolidate
on
a
use
case.
B
That
is
really
bad
for
chain
based,
then
that
would
naturally
shift
nodes
over
to
to
like
a
rock
severe
a
different
technology,
and
we've
also
provided
a
go-between.
So
you
can
transition
from
one
to
the
other
using
the
portable
snapshots
seamlessly.
So
there's
not
a
whole
lot
of
lock
in
there
and
there's
a
lot
of
room
for.
A
E
E
I
would
just
like
to
round
it
up
by
saying
that,
in
terms
of
feasibility
of
what
can
be
done
in,
like
a
you
know,
at
least
in
a
public
blockchain
space
right
now
in
eos,
there
is
much
more
than
any
other
change
today
in
terms
of
what
you
can
scale
what
you
can
deliver,
along
with
the
community
tools
like,
along
with
the
like
the
scalability
like.
Even
we
were
talking
about
this,
the
ram
issues
and
all
this
has
been
solved
as
a
community
tool
like
with
liquid
apps.
E
E
While
there
are
some
deficiencies,
while
there
are
some
wish
lists
on
what
is
missing,
but
they're
still
in
terms
of
what
can
be
done
is
a
way
way
more
than
what
can
be
done
any
other
chain.
So
I
would
look
forward
to
how
we
can
work
together.
As
I
said
like,
there
are
a
lot
of
individual
teams
who
are
spending
a
lot
of
effort
and
been
doing
it
for,
like
last
two
and
a
half
years
since
the
main
net
launch.
E
A
All
right
so
usually
I
finish
off
the
shows
if
anyone's
got
anything
to
chill.
That
would
be
the
time
to
do
it,
but
thank
you
guys
all
so
much
for
joining
me.
I'm
sure
the
community
enjoyed
this
discussion.
I
think
these
kind
of
discussions
should
happen
more
frequently
both
in
the
public
and
in
like
developer
channels
as
well.