►
From YouTube: NEAR EVM Working Group Update [2020-12-18]
Description
Follow the latest from NEAR Protocol on,
Website: https://nearprotocol.com/
Discord: https://near.ai/discord
Medium: https://near.ai/medium
Twitter: https://near.ai/twitter
GitHub: https://near.ai/github
#WhiteboardSeries #Blockchain #FutureIsNEAR
A
A
It
seems
like
we
are
live,
which
is
great,
so
yeah
and
give
me
just
one
second,
I'm
going
to
share
share
the
the
the
the
new
discussion
that
we
have
right
now.
My
screen
share
my
screen.
A
Yeah
so
hello,
everybody.
This
is
a
weekly
edm
group.
Work
group
call
we're
discussing
all
this
on
the
school,
the
news
about
the
evm
project
in
nir
and
our
current
status
and
discussing
multiple
things
that
are
maybe
valuable
for
for
everyone
to
listen
to.
So
we
decided
that
it
would
be
a
really
good
idea
to
to
add
some
some
structure
to
these
meetings,
so
we
would
like
to
introduce
agenda
and
we
are
actually
would
like
to
start
the
discussions
about
the
weekly
calls
beforehand.
A
So
it
was
not
the
case
for
this
particular
call,
but
this
is
something
that
is
going
to
be
implemented
the
next
time
well,
probably
in
the
new
year,
because
I
do
not
think
that
we
are
going
to
have
any
more
calls
any
more
workgroup
calls
this
year.
So
starting
new
year,
we
are
going
to
post
the
discussions
about
what
we
are
going
to
discuss
actually
on
this
calls
beforehand,
and
anyone
would
be
able
to
introduce
his
topic
here
and
we
would
be
able
to
discuss
this
also.
A
We
have
changed
the
the
call
time
and
we
extended
it
a
little
bit
because,
like
25
minutes,
it's
not
enough
for
for
us
to
discuss
everything,
so
it
was
extended
to
45
minutes,
and
it
now
starts
about
1
hour
and
45
minutes
earlier
than
it
was
previously.
This
was
is
done
well.
This
was
motivated
by
the
change,
the
difference
in
the
in
the
time
for
all
of
the
participants
of
the
culture
so
yeah
we
have
it
as
is
right
now,
maybe
we
need
to
also.
A
We
actually
would
like
to
discuss
whether
we
would
like
to
reschedule
this
call.
Maybe
it's
not
very
convenient
for
everybody
yeah
and
with
the
agenda.
We
are
the
main
parts
we're
keeping
the
same
the
same
structure.
A
B
Sure
so
we
are
working
towards
the
the
phase
two
which
we
have
a
planned
plan
date
in
the
middle
of
january,
and
right
now,
as
of
right,
this
instant,
we
are
trying
to
survive
the
holiday
period
when
most
most
people
will
be
absent,
and
we
also
have
a
team
member
departure
bo
who
is
being
reassigned
so
we're
trying
to
gain
all
all
his
knowledge
before
he
be
before
he's
a
little
bit
further
away
from
us,
so
they're
just
trying
to
survive
the
predict
period
at
this
this
instance.
A
Great
all
right,
so,
let's
do
then
the
weekly
update,
so
on
my
site,
it
was
not
that
much
to
report.
I
was
doing
a
little
bit
of
messaging
brainstorming,
I'm
going
to
to
show
you
some
of
the
ideas
that
we
have
in
the
in
the
discussion
topic.
These
are
pretty
fresh,
so
yeah
it
was
discussing
after
our
yesterday's
calls
on
meta
transactions
and
previous,
some
previous
calls
with
ilia.
So
this
is
like
some
reflection
on
on
what
we
can
do
with
this,
but
besides
that,
no
major
things
on
my
end.
B
Okay,
so
I'll
continue
from
there
so
yeah
you-
and
I
collaborated
very
deeply
this
week
on.
I
think
we
did
average,
probably
two
or
three
calls
a
day,
so
our
focus
this
week,
I
would
say,
was
gaining
a
deep
understanding
of
all
stakeholders,
visions
for
this
team
and
what
the
evm
product
should
be.
B
Also
in
preparing
for
my
focus
this
week
in
preparing
for
the
holidays
and
both
departure
from
the
team.
I
I've
had
to
delve
deep
into
gas
mass
transactions
also
known
as
meta
transactions.
B
It
wasn't
actually
something
I
had
planned
to
get
into,
but
at
the
moment
we
have
nobody
else
in
the
team
it
could
be
assigned
to.
So
I
have
to
take
it
over,
so
we
had
a
number
of
calls
about
that,
and
also
also
some
discussions
with
ilyan
and
with
alex
kidano
and,
of
course,
yesterday,
the
very,
very
long
call
with
beau
mike
and
alex,
so
I'm
working
on
figuring
out
what
all
that
is
about
what
we've
done
and
what
we
need
to
do.
B
What
we
ought
to
do,
which
is
not
necessarily
the
same
thing
as
what
we
are
doing,
and
I
think
we
would
benefit
from
discussing
the
transactions
later
on.
This
call,
let's
see
what
else.
Looking
at
my
notes
here,
we
interviewed
with
max
a
bunch
of
candidates.
There's
two
candidates.
I
believe
who
we
are
extending
an
offer
to
for
joining
the
evm
and
or
the
bridge
teams.
B
B
B
B
We
are
going
to
have
to
not
slow
down
because
of
waiting
on
people
to
review
things,
and
given
that
it's
better
to
do
side
branch
for
a
bit
and
then
when
eugene,
for
example,
is
back,
he
can
review
everything
in
one
go
and
we
can
launch
the
master
yeah.
I
reviewed
and
merged
the
tone
of
piazz
from
mike
and
ball
and
looked
at
frank's
in
the
books.
Pr
for
implementation.
B
I
finished
the
anemone
test
suite
to
a
state
where
I
need
to
rebase
it
and
then
I
can
hand
it
over
to
frank
for
further
further
work.
I
don't
plan
to
work
on
that
more
and
I
continued
some
work
on
the
prototype
for
the
web
3
proxy
endpoints
and
then,
of
course,
as
everybody
on
the
team.
I
dug
into
the
new
core
code
base
and
runtime,
starting
from
the
two
great
core
walkthrough
sessions
with
max
that
we
recorded
and
will
be
posted
on
youtube
soon.
B
C
C
So
what
was
missing
was
decoding
the
ilp
in
included
the
functional
arcs
and
the
eip
hash.
The
function
args
part
based
on
the
structure
of
the
type
definitions
and
the
then
yaiki
has
the
entire
meta
transaction,
which
was
hash.
Entire
transact
meta
transaction
was
done
before
and
in
the
last
region
called
the
iop
encoded
arcs
into
eth
api
encoded,
so
evm
runner
can
handle
the
handle.
The
function
call
and
also
had
a
long
discussion
with
a
team
so
that.
C
I
cannot
hold
gives
gives
me
a
good
understanding
of
how
meta
transaction
is
handled
and
interact
from
the
user
and
the
entire
user
story.
C
And
then
I
will
review
some
pr's
from
mike
arjo
on
no,
not
maybe
not
otto
and
frank,
and
I'm
going
to
move
for
move
four
time
to
contract
runtime
team,
so
I'll
still
collaborating
with
the
evm
team
on
the
until
meta
transaction
is
finished,
and
let
me
know
if
like
something
is
need
to
be
changed
in
my
transaction.
So
I
can
still
take
a
look
and
I
also
will
still
review
pro
requests.
C
C
For
the
benchmark
staff,
you
ask
frank
to
to
take
over
yeah.
That's
pretty
much
all
the
okrs
from
assigned
to
me.
A
Great
thanks
bo
eugene
is
out
of
the
office
at
the
moment,
so
he
is
not
presented
on
this
call
frank.
What's
on
your
side,.
D
Yes,
I
was
working
on
the
crypto
zombies
test
suite
and
I
ran
on
some
issues.
There
was
signing
the
with
another
account
and
then
I
basically
dug
deep
into
the
runtime
and
rust
in
general
to
better
understand
the
problem
and
also
attended
this.
This
presentation
max
gave
about
the
runtime
which
were
really
helpful,
yeah
it's
at
the
moment.
D
It
feels
a
bit
frustrating
to
not
be
pumping
out
code,
but
it
seems
it's
the
most
efficient
use
of
my
time
to
really
get
this
understanding
of
the
runtime
and
what
is
there
to
efficiently
write
the
tests.
I
reviewed
the
benchmark
pro
request
from
eugene
and
that
got
merged.
I
believe-
and
so
this
goes
well
together
with
the
testing
which,
which
I
will
take
over
as
well,
because
it's
it's
pretty
much
the
same
things
you
you
test
the
contracts
and
you
you
benchmark
them
and
what
we
need
to
add.
D
There
is
erc20
and
aoc
721
tokens
in
the
tests
and
the
benchmarks
and
for
the
existing
crypto
zombies,
the
the
contract.
We
have
likes
the
functionality,
so
I
opened
up
an
issue
there
and
we'll
add
that.
A
Okay:
okay,
great
mike.
E
Yeah
yeah
this
week
was
a
lot
of
getting
evm
information
out
of
my
head
and
into
documentation.
So
now,
when
people
go
to
near.org
and
click
on
documentation,
there's
a
develop
section
at
the
top
and
then
on
the
left,
hand,
side
bar,
there's
a
ethereum
compatibility
section
and
there's
three
different
documents
on
there.
One
of
them
is
about
how
to
use
truffle
and
we're
also
looking
forward
to
adding
hard
hat
at
some
point.
E
So
we
can
look
forward
to
that.
Another
one
is
on
the
near
web
3
and
the
last
one
is
kind
of
a
long
like
instruction
manual
on
how
to
set
up
a
local
development,
which
is
you
know,
not
ideal.
It's
not
dockerized,
but
at
least
if
projects
want
to
get
the
entire
thing
working
locally
and
start
hacking
at
it
and
debugging.
You
can
follow
those
huge
instructions
and
that'll
work
in
the
process
of
writing
the
documentation.
E
I
realized
that
there
is,
there
could
be
an
even
simpler
example
than
pet
shops,
so
I
have
like
a
42
lines
that
interact
with
the
evm
and
betanet,
so
that
may
give
some
people
a
better
example
of
how
to
just
interact
with
it
without
having
to
dissect
the
the
ui
and
all
of
that
inside
of
pet
shop,
so
that
one
is
also
published
and
linked
to
in
the
docs
pet
shop
is
finally
merged
and
it
is
good
to
go,
and
this
is
using
basically
one
of
the
use
cases,
which
is
a
user
already,
has
a
near
account.
E
E
We
have
a
couple
other
use
cases
we
want
to
be
able
to
do
the
most
recent
work
here
has
been
on
trying
to
unblock
arto,
as
he
has
a
bit
more
time
with
some
of
us
going
on
vacation
in
terms
of
getting
the
basic
meta
transactions
going,
and
the
workflow
here
would
be.
E
Someone
can
click
on
sign
inside
of
pet
shop
metamask
pops
up
with
something
to
sign
that
gets
sent
to
sort
of
a
simple
mvp,
relayer
trusted
relayer,
and
then
that
was
going
to
go
into
the
near
core
node
so
that
that
is
sort
of
the
proof
of
concept
that
we
would
like
to
get
out
of
the
way.
So
I
have
two
pr's
I
opened
this
morning
for
that.
E
I
realized
that
near
provider,
which
is
our
web3
provider,
could
have
a
second
option
for
sort
of
like
a
read
only
so
if
people
want
to
go
to
a
dap
and
they
want
to
like
get
some
information
from
the
chain
instead
of
like
actually
mutating
state
that
wasn't
really
possible
and
how
we
were
instantiating
using
the
constructor.
So
that
was
another
change
that
has
come
this
week.
I
think
that's
about
it
for
me,.
A
F
Quick
question:
sorry,
would
it
make
sense
to
have
the
layer
inside
the
the
is
rpc
proxy,
given
that,
like
that,
pet
shop
is
probably
already
should
be
using
it.
E
A
Yeah
but
we
actually
finished
the
updates,
so
we
can
go
into
this
and
if,
if,
if
you
will,
I
can
try
to
present
what
we
were
discussing
a
bit
earlier,
maybe
this
will
be
some
some
new
information.
Maybe
this
was
something
that
you
have
requested.
You
give
me
just
a
second.
I'm
going
to
pop
up.
A
A
A
A
Yeah,
so
this
is
something
that
I
that
I
sketched
up
with
regards
to
the
transaction
and
the
messages
flow,
so
so
the
the
motivation
was
that,
like
we
have
ethereum
transactions,
so
so
what
we
were
discussing
yesterday
on
the
meta
transaction
call
is
that
everything
that
we
that
the
user
is
going
to
sign
for
near
evm
is
just
the
the
message
which
is,
which
is
true,
which
will
look
like
in
the
meta
mask
in
the
metamask
interface.
Really
bad,
and
but
there
are
some
of
the
ethereum
transactions
specified
ones
that
look
nice.
A
A
Second
thing
is
that
we
actually
have
different
relay
and
infrastructure
approaches,
because
at
some
point
in
time
probably
devs
would
like
to
pay
for
the
user
transactions
happening
on
near
and
that
will
be
okay.
The
motivation
of
of
of
these
three
layers
can
be
of
this.
Really
transactions
can
be
outside
of
outside
of
of
the
economics
of
the
blockchain,
so,
for
example,
dap
can
can
get
some
additional
percentages
on
the
on
the
on.
A
On
the
like
withdrawals
and
stuff,
like
that,
so
coming
like
taking
multiple
things
here,
I
think
that
this
might
be
a
very,
very
draft
version
of
how
we
can
implement
the
messaging
of
the
existing
ethereum
users
and
actually
anything
that
can
create
authenticated
message.
So
we
actually
have
multiple
phases
in
the
in
the
messaging
process.
So
we
have
an
entity
that
would
like
to
create
an
action,
and
then
we
need
to
convert
this
action
into
something
that
is
acceptable
by
near
blockchain,
which
is
which,
which
needs
to
have
like
economics
connected
to
it.
A
Then
we
need
to
authentify
this,
at
least
on
the
near
blockchain,
and
actually
do
the
execution.
So
so
I
propose
the
following
following
approach
here,
so
ethereum
wallet.
So
if
we
are
taking
taken
first
of
all,
ethereum
wallets
into
consideration,
so
ethereum
wallet
issues,
the
ordinary
ethereum
transactions
or
is-
is
used
for
signing
the
messages
we
can.
We
can
take
any
of
these.
So
in
the
end
of
this
step
we
are
having
the
valid
signed,
signed
message.
A
A
Again,
this
can
be
a
centralized
release
or
decentralized
relay
hub,
or
if
he
can
do
the
self
release
of
these
messages.
In
case
he
has
a
near
account.
So
nothing
stops
him
with
taking
this
signed
message.
Put
him
as
a
single
argument
of
a
single
or
maybe
not
single,
offers
some
contract
call
on
the
near
side
and
sign
it
with
his
near
with
his
new
yorkie.
A
Now
then,
this
near
this
valid
rapping
near
transaction
goes
to
the
entry
contract
on
the
on
some
kind
of
or
on
the
near
watson
runtime.
This
entry
contract
takes
a
look
at
this
message
and
can
understand
that
it
has
multiple
implementations,
some
specific
implementation
of
the
messaging
protocol.
This
messaging
protocol
can
be
eip-712.
A
This
messaging
protocol
can
be
something
more
specific
than
eip712,
for
example,
with
the
incentivization
scheme
for
the
relayers.
So,
for
example,
in
this
structured
data,
there
is
some
specific
fields
where,
where
it
is
specified
amount
of
money
that
the
user
needs
to
pay
or
amount
of
bridge
tokens
that
a
user
needs
to
pay
to
their
to
their
relay,
or
it
can
be
some
some
any
other
crazy
protocols.
So
so
then,
the
messaging
protocol
implementation
is
actually
checking
the
authentic.
A
The
the
authenticate
is
authenticating
the
initial
message
that
what
the
user
was
signing
and
inside
of
this
message
and
protocol
implementation
contract.
There
is
a
check
of
the
eds.
These
csi
or
ecdsa.
A
Signatures
from
ethereum
or
here
can
be
any
other
types
of
signatures
implemented
for
from
other
blockchains,
for
example,
that
are
not
working
with
the
same
signatures
or
anything
else.
So
here
is
the
validation
of
the
of
the
initial
message
and
the
checking
of
the
signatures,
and
then
this
message
in
protocol
implementation
is
actually
calling
specific,
specific
contracts
that
can
be
both
in
washing
runtime
and
evm
runtime
and
any
any
other
runtime
that
that
we
will
have
on
your
blockchain.
A
Obviously,
within
this
call
functions,
it
can
be
a
little
bit
more
complicated
things.
For
example,
if
we
have
implicit
accounts
of
users-
and
we
have
this
message-
and
this
accounts-
they
allow
for
function-
keys
from
the
messaging
protocol
implementation.
So,
for
example,
this
we
can.
We
can
pretend
that
implicit
user
account
is
doing
the
call
yeah.
So
this
is
something
that
I
see
as
a
as
a
way
how
we
can
implement
this
yeah.
A
A
good
thing
about
over
everything
that
I
have
said
here
is
that
we
are
implementing
the
complex
parts
of
the
messaging
protocols
and
entry
contracts
and
stuff
like
that
as
a
contract
here,
so
we
can
update
it
and
we
can
add
messaging
protocols
on
the
fly
and
we
actually
are
open
for
other
developers
to
develop
their
own
messaging
protocols.
A
For
example,
it
can
be
some
some
iot
devices
that
are
that
are
authenticating
their
data
by
some
specific
protocol
that
we
do
not
know
at
the
moment,
but
they
also
can
send
their
information
in
near
using
absolutely
the
same
related
infrastructure
and
then
entry
contracts
and
then
just
the
specific
implementation
of
the
of
this
specific
protocol
so
yeah.
This
is
something
that
I
wanted
to
bring
for
the
discussion.
What
do
you
think
and
first
of
all,
india?
What
do
you
think
of
this.
F
So
there's
a
few
points.
One
is
ethereum
transactions
actually
show
like
in
metamask.
So
actually
the
meta
transactions
are
way
better
formatted
than
the
native
ethereum
transactions,
because
the
arguments
are
all
like
rlp
encoded
in
metamask.
F
F
A
No,
no!
No!
No!
We
are
not
going
to
replay
this.
I
was
not
saying
sorry,
so
we
can
use
the
ethereum
transactions
that
are
scheduled
for
our
network.
So,
as
you
know,
the
chain
id
is
presented
in
the
ethereum
transaction,
so
so
the
user
can
change
the
chain
to
which
he
is
sending
the
transaction.
So
that's.
F
Yes,
I
recommend
we
never
ask
user
to
change
to
change
the
chain
in
the
meta
mask,
because
nobody
knows
how
to
do
that,
like
like
I've
actually
tried
myself
like
I
went
to,
for
example,
matic
app
and
it
says
hey,
you
should
change
the
chain
and
I'm
like,
and
I
do
what
so
like.
It's
like
yeah.
F
Yeah
I
mean
like
I,
I
know
I
can
do
it.
I
know
I
can
find
the
rpc
point
et
cetera,
but
like
the
generally,
should
we
shouldn't,
like
the
whole
point
with
metro
transactions?
Is
that
you
don't
need
them
to
do
anything
right?
You
just
landed
website
and
just
sign
transactions,
so
I
suggest
we
stick
with
av
712
for
metamask,
specifically.
A
A
To
say
that,
potentially,
if
the
meta
mask
will
make
the
user
interface
a
little
bit
better
or
for
example,
there
is
another
wallet
that
sends
normal
ethereum
transactions,
that
is
able
able
to
show
normally
the
the
network
to
which
it
sends
it,
and
then
it
would
be
also
okay,.
B
B
F
I
think
alex
was
also
suggesting
that
you
can
quote-unquote
self-relay,
which
is
like.
If
you
I
mean,
if
you
have
a
ethereum
wallet,
but
you
still
have
an
ear
wallet
or
something
anyway.
So
so
so
this.
A
This
can
be,
this
can
be
yeah.
This
can
be.
This
can
be
the
case
for
the
people
that
would
like
to
take
a
next
step.
For
example,
they
do
not
want
to
pay
some
additional
fees
to
their
layers
for
this.
They
can
set
up
their
near
wallets,
but
they
would
like
to
continue
using
metamosque
and
and
that's
it
they
they
have
set
up.
The
near
wallet
put
a
bunch
of
near
there
and
they're
just
using
that
wallet
to
to
pay
for
the
transactions
popping
up
in
metamask.
A
It
would
be
obviously
much
easier
for
well,
maybe
not
much
easier,
but
it
can
be
one
of
the
ways
how
how
existing
depths
can
can
modify
their
front
end,
so
they
are
just
using
the
same
meta
mask
so
they're
doing
almost
nothing
they're,
just
sending
everything
to
they're.
Just
changing
one
line
of
the
code
when
they're
specifying
the
the
web3
provider.
F
Okay,
let
me
paraphrase
you:
the
self
self-reliant
doesn't
work
in
any
way
you
described
the
only
way
it
works.
If
there's
a
key
inside
the
front
end.
The
science
transactions
in
your
front
end
like
the
relaying,
requires
a
secret,
a
secret
key
on
the
relayer
side.
So
if
it's
my
account,
then
it
needs
to
be
my
key
on
my
laptop
right
to
sign
transactions.
E
B
But
this
is
not
different
from
the
the
current
relaying
scheme,
regardless,
we
have
a
server
side.
End
point
that
releases.
F
B
F
F
A
contradiction
in
terms
of
the
front-end
side,
otherwise
otherwise,
like
the
relayer,
cannot
have
a
secret
key
of
of
you
sure
that
makes
sense
yeah.
So
I'm
interested
in
like
the
quote-unquote
self-refilling,
is
just
not
using
any
layer.
That's
my
point.
Contradiction,
okay,
okay!
So
so
so
this
is
actually
the
the
contract
itself.
Is
this
question
that
I
I've
been
pondering
because
so
right
now
the
current
design
of
evm?
Is
we
actually
embedded
meta
transactions
inside
evm.
F
B
F
B
Right,
so
you
do
you
like
what
alex
is
presenting
here,
that
we
would.
It
would
be
deploying
contracts
that
are
the
taking
taking
these
inputs
and
handling
that.
B
But,
but
is
that,
is
that
there's
an
approach?
Is
it
better
than
us
basically
hard
coding
things
into
the
evm
implementation.
F
B
Yeah,
the
one
thing
we
were
discussing
with
alex
earlier
today
was
that
so
neither
of
us
is
super
familiar
with
how
how
you
call
from
a
wasm
contract
how
you
call
into
the
evm,
but
I
assume
jujun
has
been
saying
that
that
that
all
works
fine.
So
I
assume
that
we
are
good
on
that
front
already.
Okay,.
F
Yeah,
it's
just
it's
just
a
promise.
Call.
B
Yeah,
okay,
I
gotta
look
at
that,
but
assuming
we
have
that
primitive
that
facility,
then
this
can
be
implemented,
at
least,
as
you
said
level
in
the
details
yeah,
it
can
be.
F
So
so
here's
the
potential
issues,
one
is
because
it's
a
country
like
you
need
to
deploy
a
contract
per
every
user,
so
so
it
starts
with,
like
I'm
a
new
user.
How
do
I
get
one
of
those
contracts
right
like
so
how?
How
does
the
creation
flow
works
then?
Because
our
con,
like
we
like
our
storage
and
near,
is
reasonably
expensive?
F
Like
you
know,
you
need
to
pay
somebody
to
actually
like
do
this,
because
it's
a
contract,
yeah.
The
the
other
issue,
which
is
kind
of
like
subsequent
issue
is
that
is
when
you
do
call
this
with
meta
transaction
right.
It
will
do
this
proxy
and
when
it
will
come
into
evm
so
right
now
we
have
this
scheme
where
all
the
accounts
get
hashed
so
like
to
to
determine
who
has
called
some
ethereum
some
ethereum
contract
to
determine
the
address.
F
We
hash
the
incoming
account
id
of
near
right
so
ilya.near
we
hash
it
and
take
first
or
whatever
last
20
bytes,
and
that
is
the
address.
That's
used
inside
evm
for
all
the
for
all
the
stuff,
and
so
that
part
is
like
with
the
meta
transactions.
The
whole
idea
was
that
now
you
can,
you
have
the
same
address
inside
evm
as
you
as
your
metamask
shows
you
to
you.
F
If
we
go
with
this
contract
approach,
even
though
your
contract
name
like
a
account
id
may
be
your
ethereum
address,
dot
e
eth
or
evm,
or
whatever
inside
the
vm,
it
will
get
hashed
again,
so
so
we
may
need
to
either
have
code
to
like
resolve
it
or
or
just
be.
Okay
with
this,
like
this
address
will
be
different
and
kind
of
like
you
need
to
understand
how
this
will
surface
to
people
to
users
right
when
they
will
be
looking
for
their
balances
right
in
explorer
and
stuff
like
this
right.
A
Cannot
be
this
implemented
on
in
the
messaging
protocol
implementation?
So
so
the
call
of
the
so
maybe
the
call
of
the
evm
contract
within
the
call
we
need
to
specify
who
is
actually
doing
the
call
or
like
how
we
are
actually
doing
this
and
maybe
because
of
the
implement.
F
Okay,
so
you
cannot
specify
who
is
calling,
because
that's
I
mean
otherwise.
I
can
specify
that
you
know
then
take
all
your
money
right.
So
so
I
mean
that's
why
it's
like
we.
I
need
to
specifically
hard
codes
that
this
dot,
if
accounts,
are
all
have
this
contract,
but
that's
it's
very
bad,
because,
ideally
you
want
to
let
people
to
remove
the
contract
or
change
it.
E
E
Yeah
I
I
guess
I
was
just
thinking
the
key
would
be
your
near
account
and
then
you
know
the
the
value
would
be
like.
Possibly
an
array
of
like
this.
Is
your
actual
ethereum
account,
and
this
is
you
know
if
we
want
to
keep
backwards?
Compatibility
like
the
the
the
20
bytes
that
you
mentioned.
F
Now
you
can
extend
it
that
validates
that
the
message
it
received
is
indeed
eap,
712
signed
by
this
key
set
of
keys.
I
can
actually
like
add
whatever
right.
This
is
where,
like
we
can
add
any
type
of
like
messages,
yeah
verification,
including
ethereum
transactions-
if
you
want
indeed
and
then
based
on
that
right,
this
contract
will
proxy.
This
call
to
something
else
now
now,
so
this
is
kind
of
just
pulling
out
what
beau
did
right
the
code.
He
wrote
pulling
this
out
into
a
smart
contract,
pretty
much
yeah.
F
B
F
B
And
the
exact
same
issue
arises
on
the
gas
station
network
on
ethereum,
as
in
you
can
no
longer
say
message
that
sender,
you
have
to
call
a
special
function
called
underscore
message:
sender,
which
will
try
to
recover
well
we'll
recover,
who
sent
the
message.
F
Yeah,
so
so,
in
our
case,
you
don't
need
to
do
that
right.
You
know
like
if
you
do
deploy
per
users
and
it
will
be
just
pretty
like
it
will
be
just
message
sender
exactly
this
is
this
is
why
near
is
like
yeah.
Our
account
model
is
actually
different
from
ethereum
is
because
you
can
do
this
kind
of
stuff.
You
could
like
do
proxy
type
of
thing,
yeah,
which
I
mean
in
theory.
You
can
do
in
this
heading,
but
it's
like
super
complicated.
B
F
B
Exactly
exactly
this
is
the
question,
and
we
were
talking
about
this
yesterday
on
the
long
long
long
column
about
these
things.
Okay,
so
probably
not
something
we're
gonna
resolve
on
on
this
call,
but
we
can.
We
can
come
back
to
this
question
and
we
actually
almost
out
of
time
in
terms
of
our
original
schedule,
four
more
minutes
so
so.
F
The
thing
I
was
mentioning
yeah,
I
think
relayer
and
the
rpc
proxy
right
can
be
just
one
service,
because
at
the
end
it
will
be
web
3
provider
on
the
front-end
side.
Right.
That's
using
these
things
to
both
like
get
the
data
from
blockchain
and
sign
some
message
and
then
route
it
to
the
to
the
blockchain.
So
it
makes
sense
to
kind
of
use
the
same
and.
B
I
agree.
I
agree.
We
should
probably
put
those
merge,
those
together.
Okay,
all
right,
let's,
let's
see
quickly
here,
for
what
do
we
have
that
we
can
handle
in
a
couple
of
minutes.
E
Yeah,
I
I
think
I'm
just
kind
of
grasping
at
all.
I'm
also
like
really
thinking
about
the
relayer
side
of
things
like
I
was
just
trying
to
think
about.
If
we
can
use
like
an
escrow
kind
of
system,
you
know
basically,
so
the
front
end
could
do
like
a
view-only
call
saying
like
hey.
Does
this
person
has
this
person
given
the
allowance
for
a
relayer
to
spend
at
least
one
near?
E
Yes,
then
I
can
reasonably
suspect
that,
like
I'm
gonna
do
this
call
for
them
and
I
will
get
reimbursed
for
the
gas
that
I'm
doing
so
that
that
was
my
kind
of
thinking
pose
right
there
not
not
fully
baked,
but
I'm
thinking
a
lot.
F
I
also
I
mean
I
think,
like
one
important
piece
will
be,
is
allowing
to
to
pay
on
ethereum
actually
like
on
the
ethereum
network
to
re-layer
and
then
relayer
will,
like
kind
of
credit
I
mean,
I
think
it's
like
it's
somewhat.
It's
not
very
decentralized,
but
I
think
it
will
be
needed.
It's
like
you,
just
pay
a
layer
like
a
few
dollars
and
then
later
we'll
just
like
pay
for
your
like
setting
up
and
pay
for
your
gas
for
a
while,
like
a
subscription.
A
Yeah,
absolutely
so,
from
my
point
of
view,
any
any
economic
relationship
in
between
replayers
and
and
the
user.
It
should
be
solved
somehow
in
the
in
the
messaging
protocol
itself,
so
it
can
be,
it
can
be
just
for
example,
you
have
an
account
on
the
relayer
site,
and
you
have
you
are
you
have?
I
don't
know,
visa
card
that
is
connected
with
this
account
and
you
just
specified
your
account
id
there
or
something
like
that,
or
using
some
some
specific
keys
to
to
sign
the
transaction
and
that's
it.
A
This
is
in
your
authentication
for
the
relayer,
or
there
can
be
a
specification
that
you
are
allowing
for
a
transfer
of
nap21
token
on
the
near
side
and
and
the
and
the
smart
contract
that
is
implementing
this
protocol
messaging
protocol
understands
how
to
how
to
use
this
information
on
its
side.
So
so,
from
my
point
of
view
like
having
having
well
like
put
in
in
the
smart
contracts,
the
logic
of
the
messaging
protocols
gives
lots
of
lots
of
lots
of
convenient
ways
how
you
can
implement
this
for
well.
F
I
would
actually
I
would
reduce
it
to
the
to
the
basis
so
like
just
charging
another
account
like
that's
what
we
had
in
meta
transactions
right
now
in
evm
right.
It's
just
charging
another
erc20
for
this
amount,
and
so
that
that
is
like
pretty
much
pretty
generic.
I
think,
and
then
everything
else
should
be
done
not
in
in
like
protocol
and
like
we
need
to
think
through
whatever
we're
gonna
launch
with
anyway.
B
Absolutely,
which
is
why,
which
is
why
I
think,
alex's
and
and
my
top
priority
has
to
be
these
user
stories
over
this
holiday
season.
We
we
are
both
working
when
most
everybody
else
is
gone,
but
it's
good.
It
gives
us
some
time
to
focus
on
on
a
few
important
things,
including
this
so
yeah.
B
Let's,
let's
work
on
those
user
stories
with
our
now
better
know
knowledge
and
understanding
of
of
what
we
want
and
and
what
can
be
done
and
let's
come
back
to
everybody
with
those
when
when
they
are
back
and
then
we,
then
we
get
approvals
from
from
all
stakeholders
from
what
we're
actually
doing
and
can
proceed
now.
I
think
we
already
over
schedule.
So,
let's
quickly
deal
with
the
rest
of
the
agenda
items,
the
number
one
thing
does:
does
anybody
want
to
reschedule
this
call
again?
B
B
You
know
works
great
for
everybody.
Anybody
have
any
suggestion
for
how
it
might
do
better
than
this
time.
E
B
B
Okay,
okay!
Well,
we'll
keep
that
in
mind.
It
might
be
better
for
other
other
people.
Okay
bo
this.
Basically,
as
I
understand
it,
you
have
two
working
days
left
until
you
go
on
vacation
and
you
don't
really
come
back
to
this
team
after
the
vacation.
So
if
you
can,
if
you
can
manage
it,
I
would
like
a
lot
of
your
time
in
those
two
working
days
as
monday
and
tuesday,
so
that
we
can
do
some
knowledge
transfer
on
on
the
meta
transactions.
B
Okay,
so
let's
talk
about
that
offline
alex
raised
the
question
of
what
we
are
doing
currently
in
nightly
ci
with
regards
to
local
net
and
beyond
a
simple
scenario
should
be
tested.
Does
somebody
know
I'm
not
familiar
with
that
as
yet.
C
C
I
can
give
some
update
so
thereby
we
finally
have
a
I
think.
Like
last
week,
mike's
pr
for
running
the
balance
of
tests
locally
was
merged
and
I
think
we
can
make.
I
can
run
that
in
on
ci,
and
I
really
see
I
know
like
just
running.
B
B
Is
assigned
to
you
regarding
balancer,
and
I
asked
you
actually
if,
if
you
can
still
do
that,
though,
or
give
that
to
somebody
else,
sounds
like
you
would
still
do
it
yeah.
Okay,
that's
great!
That's
great!
Let's
get
that
done.
B
Okay-
and
I
think
we
can
defer
the
discussion
about
dennis
project
yeah
okay,
so
we
managed
to
keep
it
a
little
bit
over
time
but
an
hour
so
not
too
bad
all
right.
So
I
guess
that's
that's
pretty
much
it
for
for
this
year
and
happy
happy
holidays
to
everybody
and
and
let's
resume
in
almost
two
weeks.