►
From YouTube: PEEPanEIP #29: EIP-137: Ethereum Domain Name Service & EIP-2544: ENS Wildcard Resolution with Nick J
Description
Topics covered:
01:42 - How ENS works at present?
02:05 - Basic functionality of the ENS
02:48 - More than just names
03:30 - EIP-173: ENS
04:25 - Namehash
06:05 - ENS architecture - Registry
06:35 - Resolving a name
07:20 - ENS by example - Resolvers
08:00 - Registrars
09:37 - What’s the security in this case? Is there a verification system to avoid resolving to an incorrect address?
10:12 - How is it resolved in the present system?
11:20 - If resolved from a single source then if anything goes wrong with the registrar, the system can be broken. How to prevent that?
13:50 - Has the upgrade process been established yet?
15:54 - EIP-2544 overview
18:17 - Pseudo Solidity snippet
22:36 - Data at the top level of resolver for Ether does the mapping that is stored on the blockchain?
23:00 - Is this proposal going to affect exchanges only or even the end user who is using ENS for wallet name?
24:34 - Does it involve heavy computation? Is it scalable?
27:50 - Does that open up a potential DoS vector?
28:52 - Is the large transaction volume considered for overall impact?
13:10 - ENS on L2
36:53 - Rephrasing Optimism rollups
40:17 - How do exchanges embed a private key for any subdomain, could you elaborate?
42:55 - What’s the connection between the exchange, ENS and that public key?
44:48 - Have there been other novel users being opened up with the Wild Card resolution?
47:28 - Could you talk about trading ENS on a secondary market?
48:07 - Does it make any difference in terms of price for normal users?
49:45 - Linking ENS with a website? Would you recommend any third-party service providers?
52:23 - Fun fact about ENS
52:42 - ENS for Eth2 deposit contract
53:13 - What does “improperly-configured client” refer to in the “security consideration” section of EIP-2544?
55:22 - Is it the right time to move EIP-2544 to the “Review” status?
57:50 - Fun fact about Nick J.
Resources:
EIP: https://eips.ethereum.org/EIPS/eip-137 (Final)
EIP: https://eips.ethereum.org/EIPS/eip-2544
Discussion: https://ethereum-magicians.org/t/eip-2544-ens-wildcard-resolution
Presentation: https://docs.google.com/presentation/d/1q318fia-wFcya9RGuPZA05m0akmottmveXv0Oa3o2_I/edit#slide=id.g3e04caa69e_1_2
A beginner’s guide to buying an ENS domain - https://medium.com/the-ethereum-name-service/a-beginners-guide-to-buying-an-ens-domain-3ccac2bdc770
Follow at Twitter:
Nick Johnson | James Hancock @JHancock | William Schwab @William94029369 | Alita Moore @AlitaMoore85 | Brent Allsop @Brent_Allsop | Pooja Ranjan @poojaranjan19
Potential directions for new EIPs with Nick Johnson - https://youtu.be/9rUu2HMXt0I
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Follow PEEPanEIP earlier episodes at https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.gg/tzYmDmF
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herders/PM
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
A
Welcome
back
to
another
episode
of
an
erp
dedicated
series
where
we
discuss
an
ethereum
improvement
proposal
and
understand
how
is
it
going
to
make
youtube
even
better?
My
name
is
ucharanjan
and
I'm
your
host
for
today's
episode
on
ems,
ethereum
name
service,
also
known
as
ens,
is
a
system
that
was
created
to
provide
shorter,
more
human-friendly
name
in
place
of
long
atm
addresses,
but
there's
more
to
ena
domain
names
than
just
making
a
memorable
wallet
address.
A
Ens
opens
up
the
door
for
websites
tab
to
make
themselves
accessible
via
a
decentralized
censorship,
resistance
and
user
control
domain
naming
system.
In
this
episode
we
will
talk
about
eip137,
ethereum
domain
name
service
specification,
which
is
already
in
final
status
and
eip2544
enf
wildcard
resolution,
which
is
a
standard
track
esc
proposed
in
february
2020
and
currently
in
draft
status.
A
A
Before
I
pass
on
the
microphone
to
nick
a
piece
of
information
for
those
who
aren't
familiar
enough
with
his
contribution
to
the
atm
ecosystem,
nick
johnson
has
been
a
long-time
eip
editor
and
was
on
our
show
a
few
weeks
ago
to
discuss
the
potential
directions
of
new
eips.
If
you
have
missed
watching
guitar,
you
may
follow
the
recording
available
on
penny
playlist
at
ethereum
cathedrals
youtube
glad
to
have
you
again
on
the
show
nick
and
the
floor
is
all
yours
good
to
be.
B
B
You
shouldn't
have
to
do
the
equivalent
in
ethereum.
So
that's
the
the
original
sort
of
basic
function
of
ens,
but
it
does
far
more
than
that,
so
it
also
supports
addresses
on
other
blockchains.
We
support
pretty
much
every
major
blockchain
at
this
point.
Swarm
and
ipfs
records
and
other
decentralized
content
records
legacy.
Dns
records
you
can
even
embed
inside
dns,
you
can
use
them
to
to
prove
your
identity
and
you
can
use
it
to
store
things
such
as
interfaces
for
contracts
and
so
forth.
B
So
generally,
the
idea
is
that
ens
is
intended
to
be
a
mapping
from
a
human
readable
name
to
just
about
any
data
that
would
be
useful
to
look
up
against
that
name,
so
the
basic
eip137
defines
enas
and
it
defines
dns
as
a
hierarchical
system.
Much
like
the
domain
name
service.
So
you
have
a
route
and
below
that
route
you
have
top
level
domains.
The
only
one
we
natively
deploy
on
ethereum
is
dot
eth
and
then
under
those
top
level
domains.
B
You
have
individual
second
level,
domains
like
an
ego,
montoya,
metamask,
oracle,
eyes,
neck,
etc,
and
then,
under
that
people
can
create
sub
domains
and
subtype
domains
and
so
on.
It's
hierarchical
and
there's
no
limit
to
the
number
of
subdomains
you
can
create
now
implementing
that
on
an
ethereum.
B
Smart
contract
is
a
bit
of
a
challenge
because
you
want
to
do
it
in
such
a
way
that
you
minimize
the
the
cost
and
complexity
of
looking
up
a
name,
and
so,
if
you
have
to
look
up
the
top
level
domain
contract
and
then
from
that
look
up
the
second
level
domain
contract
and
so
on,
then
that
kind
of
draws
things
out.
You
have
to
do
a
lot
of
lookups
in
order
to
resolve
a
name
which
is
an
efficiency
concern
and
also
a
complexity
concern.
B
So
we
developed
what
we
call
name,
hash
and
name
hash
is
a
recursive
function
for
translating
human
readable
names
into
an
identifier
that
represents
the
name
and
it
has
two
basic
properties.
One
is
that
it's
a
fixed
length
that
can
be
used
to
look
up
the
name
in
ens,
and
the
second
is
that,
given
the
name
hash
of
a
name
and
the
name
of
a
subdomain,
you
can
calculate
the
name
hash
of
the
subdomain.
B
So
what
I
mean
is,
if
you
have
the
name
hash
of
nick.eth,
and
I
say
I
want
to
look
up
the
wallet
sub
domain,
then
you
can
generate
the
name
hash
for
wallet.net.ed
without
having
to
access
the
the
entire
plaintext
name,
and
this
is
useful
for
a
variety
of
functions
inside
of
unis
as
we'll
see
so
here's
an
example
of
how
it's
implemented.
You
want
to
hash
food.name.tld.
B
The
way
you
do
that
is
you
take
the
keck
act,
256
of
the
sha-3
hash,
as
we
can
colloquially
call
it
of
the
name
of
name.tld
and
you
concatenate
that
wish
concatenate
that,
with
the
kick
act,
256
hash
of
the
subdomain
foo
answer
to
calculate
name.tld.
You
do
the
same
thing.
You
take
the
sha
three
of
name,
tld
and
concatenate,
that
with
the
sha
three
of
name
and
so
for
the
tld
is
where
the
the
whole
thing
ends
since
there's
no
further
domains.
B
You
you
put
in
the
zero
address
or
sorry
the
zero
hash
concatenate
that
with
tld
and
that's
where
you
get
the
name
hash
for
that.
So
now
we
have
a
procedure
where
we
can
take
a
name
of
any
depth
and
generate
a
unique
identifier
for
it
and
where
we
use
this
is
in
the
ens
registry.
So
there
are
three
main
components
of
enas
there's
the
registry,
which
maintains
a
mapping
from
every
single
name
in
the
system
at
any
depth
to
its
owner
and
to
the
resolver
responsible
for
it.
B
B
First,
you
consult
the
registry,
please
tell
me
the
resolver
for
food.heath
and
it
returns
the
address
of
that
resolver
and
then
you
go
off
and
you
consult
that
resolver
saying
please
tell
me
the
address
of
food.eth
or
the
bitcoin
blockchain
address,
or
the
ipfs
content,
hash
or
whatnot,
and
it
consults
whatever
it
has.
Implementation
has
internally
and
returns
it
to
you,
and
the
reason
for
this
interaction
is
that
it
means
that
the
system
is
extensible.
Anybody
can
build
a
new
resolver.
B
Anybody
can
extend
an
existing
one
to
add
a
new
content
type,
and
none
of
that
requires
a
system-wide
upgrade
or
the
permission
of
the
you
know
the
ens
creators
or
anything
like
that.
So
it
provides
for
a
system,
that's
very
extensible
and
is
sort
of
allows.
Permissionless
innovation
and
improvement.
B
The
third
component
of
ens
that
I
haven't
mentioned
yet
is
registrars
and
a
registrar
is
how
end
users
register
names
on
the
nes
and
they're,
not
really
a
formal
component
of
ens,
because
all
they
are
is
a
smart
contract
that
owns
a
name
and
if
you
own
a
name
you
can
create
sub-domains
of
that,
and
so
the
contract
simply
has
rules
to
say.
If
you
follow
the
set
of
rules,
I
will
create
a
sub-domain
for
you,
and
so
here's
a
really
very
simple
one.
B
B
C
B
So
the
the
idea
is
that
only
the
if
we
look
at
the
registry,
only
the
owner
field
at
the
owner
field
determines
who's
allowed
to
update
a
record
in
the
registry.
So
only
the
owner
of
nick
dottie's
can
set
the
resolver
address
for
nick.eth,
and
if
the
owner
is
at
least
vaguely
sensible,
they
won't
set
it
to
a
resolver
that
they
don't
control
or
that
they're
not
confident
will
will
operate
the
way
they
want
it
to.
B
Like
much
like
dns,
whoever
owns
the
name,
gets
to
control
what
it
resolves
to
and
you
don't
have
any
sort
of
a
priori
assurances
that
a
particular
name
is
owned
by
a
particular
party.
So
in
the
case
of
ens,
we
do
actually
provide
a
system
for
you
to
claim
your
dns
name
inside
the
units.
So
google
could,
as
of
when
we
deploy
it
later
this
this
month
or
next
claimgoogle.com,
and
then
it
would
resolve
the
way
google
wanted
to
it
to
resolve
inside
dns.
B
B
B
And
so,
if
you
own
a
name
that
there's
no
sort
of
central
administrator
for
the
ens
registry,
there
is,
however,
the
root
node.
The
the
sort
of
the
parent
to
all
the
top
legal
domains
is
owned
by
a
multi-circuit
present,
which
has
seven
key
holders.
I'm
one
of
them
and
the
other
six
are
people
well
known
in
the
community
who
are
unaffiliated
with
ens.
B
The
reason
for
this
being
that
ens
is
still
young
and
we
want
to
make
sure
that
we
can
upgrade
and
improve
it,
and
then
we
can
also
fix
bugs
as
they
crop
up.
That
is
something
we're
working
on
removing
and
the
first
step
to
that
is
actually
that
there's
a
permission
flag
in
a
contract
associated
with
ens.
That
allows
you
to
lock
out
the
key
the
root
key
holder's
ability
to
change
a
subdomain.
B
So
what
that
means
is,
we
can
say
we
can
ask
the
key
holders
to
flip
that
flag
for
eth
and
after
that
they
would
no
longer
be
able
to
affect
the
owner
of
dot
eth,
which
means
they
wouldn't
be
able
to
replace
the
registrar,
smart
contract,
which
means
that
any
registrations
associated
with
that
would
be
effectively
set
in
stone.
You
can
create
them.
B
C
B
Unfortunately,
so
because
beginning
of
last
year,
I
actually
sorry
20.
Let
me
think,
2019
november
the
day
before
my
wedding,
I
get
a
a
text
message
from
samsung
you
up
and
he
reveals
that
he's
discovered
a
critical
vulnerability
in
the
the
original
enes
registry,
which
I
have
to
say,
I
was
pretty
confident
in
because
it
was
a
very,
very
simple
contract,
but
he
nevertheless
managed
to
find
something
that
was
was
a
significant
issue.
B
B
Hopefully
that's
not
something
we
have
to
do
again.
We
know
it's
technically
possible.
It
is
complex
and
involved
and
and
expensive
in
terms
of
gas
consumption.
The
on
a
smaller
scale.
Smaller
upgrades
are
possible
thanks
to
the
the
multi-sig,
and
so
when
we
lock
that
out.
That
will
mean
that
if
there
was
a
big
bug
or
a
major
change,
we
needed
to
make
to
dot
eth.
B
We
would
have
to
do
the
big
migration
instead
of
a
much
smaller,
more
contained
one
and
that's
why
we
want
to
to
make
sure
that
we're
not
likely
to
have
to
do
that.
But
it's
also
a
good
thing
in
the
sense
that
the
the
big
migration
is
an
opt-in
procedure.
Everyone
who's
involved
in
the
ens
gets
to
look
at
it
and
say:
oh
okay,
they're
moving
us
to
a
new
contract
for
a
good
reason,
I'll
update
my
references.
B
Thank
you
any
other
questions
about
ens
basic
structure
cool.
I
guess
I'll
give
a
an
overview,
then
of
our
next
planned
improvement.
Part
of
a
package
of
things
we're
working
on.
This
is
formalized
in
ep
2544
and
it's
a
wild
card
resolution
for
ens.
So
the
basic
idea
behind
enes
is
very
straightforward.
B
B
If
you
want
to
name
your
contract,
you
you
need
to
in
you
know
individually
enter
the
name
of
the
contract
anyway,
but
there
are
use
cases,
for
example,
where
exchanges
want
to
offer
a
deposit
address
for
every
user
and
they'd,
like
that
deposit
address
to
have
a
human
friendly
name
or,
for
instance,
wallets
wish
to
issue
sub-domains
to
every
user.
But
given
the
gas
cost
of
sending
a
transaction
to
create
a
an
ens
name
for
every
user,
that's
prohibitive,
so
they
want
a
way
to
do
that.
B
That's
lower
overhead
and
part
of
the
solution
to
that
is
what
we're
proposing
here
with
wild
card
resolution,
and
so
the
basic
idea
is
very
straightforward.
We
have
this,
the
the
registry
layout
we
already
described
and
we
have
the
the
way
name,
hash
works,
and
so
what
you
do
is
you
start
by
doing
just
a
regular
lookup?
You
name
hash
the
name.
You
pass
that
into
the
registry.
B
You
ask
the
registry,
which
resolver
is
responsible
for
this
address
and
if
it
returns
a
resolver,
then
great
you're
done
and
if
it
doesn't,
you
say
well,
okay,
that
name
didn't
exist,
but
maybe
the
parent
name
exists,
and
maybe
the
parent
name
knows
about
this
name
we
care
about.
So
what
you
do
is
you
try
and
resolve
the
same
name
on
the
parent
resolver?
B
So
what
that
means
is
if
you're
looking
for
wallet.net.eth,
you
look
up
the
resolver
for
nick.eth
and
if
it
exists,
you
ask
it
about
wallet.net.ed,
you
don't
ask
it
about
nec.leave,
you
ask
about
that.
Subdomain,
even
though
it's
not
the
resolver
for
that
subdomain,
and
then
you
repeat
that
all
the
way
up
until
you
reach
the
top
level
domain
or
the
route
and
if
any
resolver
exists
along
the
way
and
answers
your
question,
then
you
can
skip
you
stop
there
and
if
none
does
then
no
results
same
as
today.
B
B
First,
you
do
create
a
name
hash
for
the
whole
name,
calling
it
node
here
and
then,
while
the
there
is
a
name
left,
you
look
for
the
resolver
of
that
and
you
try
and
look
up
the
address
on
it.
If
you
succeed,
you're
done,
if
you
don't
take
the
first
label
off
the
name,
so
food.name.tld
becomes
name.tld
and
repeat
the
whole
process,
and
so
this
is
pretty
straightforward
and
you
know
generally
well
accepted
as
being
a
reasonable
improvement.
B
There
are
a
few
wrinkles
that
we
have
yet
to
work
out
on
the
minor
end
of
things.
Should
the
should
we
treat
a
a
resolver
that
exists,
but
doesn't
return
a
record
for
your
name
as
stop
here,
no
result
or
should
we
consult
its
parent
resolver,
and
I
think
we
should
probably
do
do
the
former
because
of
the
the
sort
of
various
concerns
around
name
resolution
and
safety
and
so
forth,
in
that
this
potentially
opens
up
an
avenue
where
the
parent
name.
B
So
if
you
own,
you
know
peeping.eth,
you
want
to
be
able
to
set
a
resolver
and
know
that,
no,
that
the
eth
resolver
is
not
going
to
be
able
to
answer
any
questions
about
your
name,
because
you've
created
this
resolver
and
said
this
is
the
authoritative
source
for
it.
There
are
larger
issues
around
how
what
exactly
the
interface
for
looking
up
the
name
should
should
look
like
so
as
currently
specified
in
the
draft
eip.
B
B
So,
unlike
previous
upgrades,
where
we
added
new
content
type
or
whatnot,
where
only
clients
wanting
to
resolve
that
content
type
head
to
care,
this
will
require
everyone
who
resolves
names
on
the
nes
today
to
change
how
they
do
it,
which
is
another
major
upgrade.
Fortunately,
most
of
them
rely
on
one
of
a
few
javascript
or
other
language
libraries,
so
we
can
send
pull
requests
to
those
libraries
to
update
them
and
just
ask
the
individual
apps
to
update
their
dependencies
to
the
new
versions,
but
it's
still
a
significant
upgrade.
B
D
E
B
A
B
B
C
B
In
terms
of
you
know,
unfortunately,
because
gas
prices
have
escalated
so
much,
no
matter
how
affordable
your
application
is
still
getting
unaffordable,
and
so
we
are
actually
looking
into
layer,
2
solutions,
and
we
have
something
that
we
think
is
very
viable
for
offloading
a
lot
of
a
lot
of
work
onto
an
l2
and
therefore
reducing
the
the
overhead
on
the
ethereum
network
and
also
the
the
transaction
costs
people
to
have
to
pay,
and
you
might
have
seen
a
glimpse
of
it
earlier.
But
I
I
have
a
slide
to
talk
about
that.
B
If
we
have
time-
because,
although
I
know
it
wasn't
on
the
agenda
and
it's
kind
of
a
hasn't-
even
reached
the
draft
stage
yet
I
thought
it
would
be
an
interesting
extension
of
this.
So
I'm
happy
to
go
into
that
before
I
do
you.
You
did
ask
about
like
the
the
overhead
and
it's
not
computationally
intensive
to
resolve
ins
names
or
really
to
insert
them
like
I'm
proud
to
say
that
I
think
the
ens
registry
is
one
of
the
more
efficient,
widely
used
apps
on
ethereum
it
uses.
B
The
wildcard
resolution
potentially
requires
you
to
repeat
that
process
multiple
times
for
the
name
and
the
parent
name
and
the
grandparent
name
and
so
forth,
and
each
of
those
if
you're
consulting
a
remote
node
like
inferior,
may,
have
a
round
trip.
Time
of
you
know,
300
to
500
milliseconds.
So
by
the
time
you've
resolved
the
name,
a
couple
of
seconds
could
have
passed,
which
is
unacceptably
slow.
B
B
We're
also
because
this
contract
would
require
passing
in
the
entire
name.
There
is
a
practical
limitation
on
just
how
many
subdomains
you
can
create.
You
know
not
a
theoretically
unlimited,
but
in
practice
it
has
to
be
short
enough
to
fit
inside
a
call
which
is
a
very
long
domain.
Indeed,
nothing
anybody's
likely
to
want
to
use,
but
it
does
put
a
limit
on
that.
C
Like
as
far
as
ddos
is
concerned,
is
there
any
because,
like
the
actual
act
of
resolving
may
be
like
low,
but
then
there's
going
to
be
like
well?
Presumably,
if
enos
is
widespread,
then
it
would
be
for
every
transaction.
You
have
to
run
it
right,
so
it
would
be
large
volume
with
low
overhead.
So
is
that
considered
in
regards
to
like
its
overall
impact.
B
So
I
think
it's
if
you
consider
that
for
every
scene,
the
user
does
they're
likely
to
execute
multiple
balance,
lookups
and
they're,
probably
interacting
with
adap,
which
is
consulting
their
own
smart
contract
in
the
back
end
multiple
times.
The
percentage
of
of
call
traffic
that
adds
up
to
ens
traffic
is
is
very
small.
B
So
it's
not
typically
a
concern.
You
know
as
long
as
we
we
keep
the
resolution
procedures
reasonable.
It's
going
to
it's
never
going
to
show
up
as
more
than
a
blip
on
the
radar
compared
to
the
the
traffic
from
all
the
depth.
The
users
are
using
that
require
them
to
look
up
these
names
in
the
first
place
cool
if
nobody's
got
further
questions
on
wildcard
resolution,
and
it
seems
like
we
have
time,
shall
I
give
a
quick
overview
of
our
l2
plans.
A
B
Okay,
so
we
have
plans
for
for
how
to
implement
l2,
supported,
ens
and-
and
it's
helpful
first,
I
guess-
to
outline
a
few
basic
objectives,
which
is
that
we
have
no
plans
to
move
ens
itself,
the
main
registry
to
an
l2.
We
believe
that
naming
is
a
fundamental
resource
that
is
useful
to
have
on
l1,
but
we
want
to
minimize
the
amount
of
traffic
and
the
amount
of
cost
and
expense
borne
by
users
sending
transactions
by
providing
them
with
options
that
reduce
their
interaction
with
l1
and
enes's
requirements.
B
Here
are
a
little
unique
because
most
l1
l2
communication
is
structured
around
the
idea
of
the
user,
initiates
a
transaction
from
l1
that
needs
to
send
a
message
to
l2
or
the
user
initiates
a
transaction
on
l2
that
needs
to
send
a
message
to
l1
and
in
either
of
those
cases
you
have
transactions
you
have
over
here,
but
the
main
job
of
ens
is
reading
data.
Not
writing
it.
You
know
for
every
name
that
gets
written
to
the
chain.
It's
looked
up
a
thousand
or
ten
thousand
times.
B
B
You
know
this
particular
solution,
as
is
the
only
one
we'll
ever
use,
partly
because,
as
a
widely
deployed
system,
we
think
our
users
should
be
able
to
have
that
choice
and
and
because
you
know
we're
trying
to
build
a
permissionless
and
extensible
system
here
that
anyone
can
extend
and
sort
of
picking.
One
solution
isn't
really
in
the
spirit
of
that
and
partly
because
I
think
it's
way
too
early
to
be
pointing
to
any
l2
solution
and
saying
you
know
this
will
be
the
solution
everyone
uses.
B
So
there's
a
very
high
risk
that
you
pick
one
and
then
it
becomes
the
betamax
of
the
future.
You
know
so
to
speak,
which
of
course,
is
going
to
mean
nothing
to
anybody
born
after
like
1990,
but
never
mind.
So
the
what
we've
come
up
with
vitalik
came
up
with
an
original
proposal.
We've
had
a
couple
of
community
calls
where
we've
refined
and
extended
it,
and
we've
got
to
the
point
where
this
is.
We
think
not
only
a
good
solution
for
eas,
but
it's
actually
an
excellent
general
purpose.
B
B
They
configured
the
name
to
point
to
a
particular
l2
that
they
were
using
and
that's
up
to
them
and
because
the
protocol
is
open
and
doesn't
require
approval,
anyone
can
deploy
the
solution
for
a
new
l2
by
building
the
appropriate
sort
of
glue
infrastructure
to
hold
everything
together.
So
when
you
go
off
and
query
that
gateway,
it
goes
off
and
consults,
say
optimism
and
looks
up
the
name
for
you
and
returns
some
information
to
you.
B
And
if
we
stopped
there
we
would
have
a
working
name
service,
but
it
would
be
one
that
gives
up
basically
all
the
guarantees
of
running
on
the
blockchain,
because
you
wouldn't
have
any
assurance
that
that
name
server
was
returning
an
accurate
result
from
the
l2.
In
fact,
you
may
as
well
just
not
have
an
l2
and
have
that
gateway
server
responsible
for
answering
all
your
questions.
B
So,
to
give
a
concrete
example,
I've
been
building
an
mvp
implementation
of
this
optimism,
so
we
find
the
resolver
it
points
to
a
process.
I'm
running
I
go
and
consult
that
it
looks
up
the
name
on
optimism
and
it
gets
back
the
the
address
the
name
resolves
to,
and
it
also
gets
back
a
cryptographic
proof
of
the
fact
that
that
name
is
stored
in
store.
D
B
C
C
So
if
I'm
understanding
correctly,
what
you're
talking
about
is
that,
like
the
cool
thing
here,
is
that
you're
going
to
be
building
out
and
like
a
tool
that
allows
so
first
off
what
l2
is
to
my
understanding
feel
free
to
correct
me,
because,
but
what
l2
is
is
like
it's
the
it's
basically,
the
application
of
like
elliptic
curve
cryptology,
which
basically
just
makes
it
a
lot
cheaper
to
deliver
or
like
to
verify
a
large
number
of
of
proofs
and
to
verify
that
everything
is
like
accurate.
Is
that
correct.
B
It
it
sounds
like
you're
thinking
of
zk
roll
ups,
which
do
use
which
to
use
that
sort
of
crypto
to
efficiently
prove
that
there's
also
optimistic
roll-ups,
which
are
a
much
more
basic
application.
Basically,
what
you
do
is
you,
you
send
all
the
data
for
your
transactions
to
l1
as
normal,
but
instead
of
executing
them
there,
you
execute
them
on
your
l2
and
then
later
the
l2
comes
along
and
says.
B
I
assert
that
if
you
execute
all
these
transactions,
this
is
the
result,
and
then
they
have
this
whole
dispute
process
to
check
whether
they're
lying
and
if
they
are,
then
somebody
else
can
come
along
and
go
no
you're
wrong
and
so
forth,
and
so
it's
a
much
less
cryptographically
sophisticated
mechanism,
but
it
achieves
similar
goals,
and
you
know,
has
the
advantage
that
there
are
more
than
sort
of
10
or
15
people
in
the
world
who
understand
it.
Yeah
well,.
C
No,
that
that's
no
that's
a
really
great
point,
and
I
didn't
know
that
actually
so
I
gotta
look
into
that
after
this,
but
to
kind
of
go
back
to
it.
I
think,
like
the
cool
thing
that
you
guys
are
gonna
be
implementing,
is
basically
building
like
an
interface
for
allowing
verification
of
like
transact
or
like
the
name
verification.
Does
that
make
sense.
B
B
The
thing
that's
the
application
we're
using
it
for,
but
the
general
primitive
can
be
used
for
fetching
any
data
at
all
from
a
layer,
2
solution
without
having
to
care
which
layer
2
solution
it
is
and
without
having
to
introduce
extra
trusted
parties.
So
you
can
simply
say
answer
me
this
question
and
not
really
care
who's
answering
it
or
how
just
know
that
you
can
trust
the
result.
A
B
B
A
D
D
So
let
me
try
and
say
it
back
to
you,
I'm
pretty
sure
I'm
going
to
get
some
of
it
wrong,
but
that
that'll
be
maybe
how
we
figure
out
what
to
dig
into.
You
were
saying
that
a
in
exchange,
for
example,
would
have
the
ability
to
embed
their
embed
a
key
in
a
way
that
they
would
be
able
to
generate
further
public
keys,
all
going
back
to
the
same
root
derivation
address
for
any
sub
domain
that
would
be
spawned
on
their
initial
or
created
on
their
initial
on
their
initial
domain.
D
B
D
B
Respects,
but
the
basic
idea
with
that
spec
is
that
you
have
a
root
key
and
and
from
your
root
private
key
you
can.
You
can
derive
a
whole
bunch
of
of
child
private
keys
that
that
are
your
individual
wallets
and
from
those
private
keys
you
can
do
to
drive
the
public
keys
and
the
addresses
and
so
forth.
But
that
specification
also
has
a
way
to
do
this.
B
Where
what
you
do
is
you
derive
a
public
key
and
you
can
give
that
publicly
out
to
anyone
and
from
that
they
can
derive
sort
of
sub-wallet
addresses,
sub-private,
sorry,
sub-public
keys
and
you
can
derive
the
corresponding
private
keys
without
anybody,
of
course,
knowing
what
those
private
keys
are.
And
so
this
is
the
mechanism
you
use
here.
B
D
The
the
cryptography
part,
the
cryptography
part
that
angle
of
it
like
the
the
root,
derivation
and
then
kind
of
the
child
derivation
paths.
I
think
I
got
from
the
ens
perspective
right.
What
would
that
look
like,
though,
as
in?
What's
it
didn't
sound
like
you
know,
the
exchanges
were
is:
what's
the
connection
between
the
exchange
ens
and
that
republic
key
yeah.
D
Okay,
so
I
think
once
exchange.eth
is
registered
to
this
root
public
key.
That
means
that,
even
without
having
to
make
a
specific
kind
of
ens
registration
transaction
to
register
each
subdomain,
that's
there
ens
can
already
return
an
address
for
a
sub
domain,
even
without
a
specific
registration
for
it.
Yes,
that.
D
B
You
know
looking
up
looking
it
up
on
the
parent
resolver,
but
once
you've
got
that
you
don't
even
have
to
know
what
the
plain
text
name
is.
All
you
have
to
do
is
say.
Well,
I
was
given
this
blob
and
I'll
generate
a
unique
key
for
it
and
then,
as
long
as
your
process
for
generating
that
blob
is
deterministic,
the
exchange
can
do
the
same.
D
B
You
can
actually
put
all
of
the
users
domains
on
l2
and
therefore
you
know
you
actually
have
a
viable
end-to-end
solution,
other
other
things
for
for
wildcard
resolution.
For
instance,
if
you're
creating
say
a
gnosis
wallet,
you
could
have,
it
automatically
generate
a
name
for
every
gnosis
wallet,
and
you
could
do
that,
potentially
with
zero
additional
overhead
over
just
creating
the
wallet
because
you're
already
making
it
on
chain
transaction,
and
now
you
wouldn't
have
to
pay
the
extra
gas
to
insert
records
into
ens.
D
Very
interesting,
all
right
great,
I'm
like
trying
to
turn
through
my
head
real
fast.
If
there's
some
kind
of
airdrop
application
for
this,
like
you
know,
if
a
particular
dap
would
want
to
be
able
to
move
tokens
to
users,
but
I
can't
I
can't
figure
out
something
that
would
happen
there,
because
theoretically
they'd
have
to
still
know
which
sub
domains
would
eventually
get
used
or
have
to
drop
to
every
possible
subdomain
underneath
which
should.
B
B
Probably
I
don't
know,
is
it
I'm
guessing
somebody's
squatting
on
it?
Are
they
well
I'm
wondering
if
I
can
get
like
a
head
of
the
curve
here
right
I
mean
I
I'm
just
I'm
looking
it
up
for
you
now,
let's
see
what
etherscan
says:
it's
not
registered,
so
yes,
you
can,
but
now
that
you've
mentioned
it
on
a
live
stream.
You
should
probably
do
that
quickly.
Yeah.
A
A
B
My
personal
view
is
that
when
squatting
is
easier
and
cheaper
that
drives
up
the
price
for
users,
because
people
jump
in
snap
up
names
that
they
think
they
can
resell
at
a
premium
and
then
because
they
only
will
only
ever
be
able
to
resell
a
small
fraction
of
them.
They
have
to
pump
the
price
on
those
names
up
very
high
and
it
sort
of
reduces
the
liquidity
of
the
system.
The
ability
to
to
find
the
name
you
want
and
get
it
cheaply
and
easily.
B
So
personally,
I
think
that
in
the
net,
like
we'd
be
better
off
without
a
secondary
market,
but
of
course
secondary
markets
always
exist,
and
you
know,
although
I
think
that
they
are
net
harmful
to
the
system.
The
nature
of
building
a
permissionless
system
means
people
can
do
it,
and-
and
you
know
that
we're
not
going
to
attempt
to
stop
them,
but
we're
going
to
try
and
structure
the
system
in
a
way
that
benefits
users
who
want
to
buy
a
name
to
use
it
over.
A
B
Exactly
and
we've
got
no
desire
to
build
a
system
that
would
have
would
be
able
to
control
that,
even
but
when
we
think
about
how
to
price
names
and
how
to
handle
renewals
and
all
those
sort
of
things.
We're
always
going
to
think,
first
and
foremost
about
how
to
make
things
easy
and
affordable
for
the
users
who
want
to
actually
put
the
naming
system
to
use.
A
Okay,
so
my
next
question
is
related
to
linking
the
ens
with
a
website
on
a
very
high
level,
how
simple
or
complex
is
it
for
linking
an
ens
name
with
a
website?
Let's
say
a
user
who
is
using
ipfs
as
a
hosting
platform,
he's
not
too
much
deep
into
a
blockchain?
Maybe
the
product
and
service
that
he
wants
to
show
with
the
website
is
not
even
related
to
blockchain.
Would
it
be
simpler
for
with
the
documents
with
the
help
of
documents
to
go
ahead
and
do
that.
B
B
B
A
B
And
I
think
that
if
it's
not
your
primary
business,
if
you
know,
if
you're
doing
this
to
achieve
a
goal,
then
finding
somebody
else
who's
whose
primary
job
it
is
is
an
excellent
idea.
You
know,
despite
the
the
vision
of
decentralization
being,
everyone
can
do
everything
themselves,
it
doesn't
mean
you
have
to
do
everything
yourself
and
personally,
I
think,
there's
a
lot
of
room
for
companies
like
fleek
to
make
our
lives
easier
for
as
long
as
it's
convenient
for
us.
A
A
B
A
I
have
one
question
related
to
security
concerns.
I
found
that
in
the
proposal
itself,
25
44
out
of
the
three
security
concerns
that
were
listed.
My
question
is
related
to
the
risk
of
improperly
configured
client.
I
want
to
understand
what
does
improperly
configured
client
refers
to
here.
Is
it
some
custom
configured
client
like
a
fork
of
any
minute
client
or
is
it
any
of
the
existing
main
net
client.
B
Let
me
just
refresh
my
memory
one
second,
I
yep
I
I
have
the
section
while
compliant
enes
clients
will
continue
to
refuse
to
resolve
records
without
a
resolver.
There
is
the
risk
that
an
improperly
configured
client
will
refer
to
an
incorrect
resolver
or
will
not
reject
interactions
with
null
address
when
a
resolver
cannot
be
located.
B
A
Yeah
thanks
for
clarifying
that,
so
I
have
one
last
question
related
to
eip
status.
So
the
current
eip
2544.
It
suggests
that
it
is
in
draft
and
it
was
proposed
almost
a
year
ago,
like
february
2020,
and
if
you
believe
that
this
is
ready
for
review
and
you
would
want
to
accelerate
the
standardization
process.
B
I
I'm
not
really
up
for
pushing
it
further
than
that
right
at
the
moment,
because,
although
it's
been
around
for
a
while,
the
sort
of
ecosystem
has
been
evolving
a
bit
during
that
time
and
in
particular
the
l2
stuff.
We're
working
on
at
the
moment
is
directly
dependent
on
it
and
we
want
to
make
sure
that
it
meets
the
the
requirements
for
that
and
that
you
know
we
don't
have
any
edge
cases
that
we
hadn't
foreseen,
because
you
know
l2
support
didn't
exist
when
we
we
came
up
with
it.
A
Yeah,
that
makes
sense,
because,
when
when
it
is
like
labeled
as
review,
more
eip,
editors
will
come
up
and
add
their
formal
comments
as
review
comments.
What
what
is
needed
or
if
there
is
generally
I
have
read
on
almost
every
comment-
are
positive
about
it,
but
giving
it
a
proper
status
is
helpful.
A
Thank
you
for
the
wonderful
presentation
and
taking
out
time
and
talking
about
it
so
yeah.
This
is
a
relatively
new
concept
and
I'm
sure
that
many
users
and
job
developers
out
there
who
would
like
to
explore
its
feature
more
than
just
human
readable
wallet
learning
about
it,
is
going
to
help.
So
before
we
wrap
up
the
episode.
Another
fun
fact
about
next
ether's
card
that
was
started
by
nick
johnson
back
in
2017
with
physical
card
as
a
way
to
onboard
people
to
ethereum.
A
A
If
you
like
this
video
hit
like
and
share
it
with
the
people
of
similar
interests,
don't
forget
to
subscribe
with
em
cathartis
youtube
channel.
If
you
haven't
done
it
already,
we'd
love
to
hear
feedback
and
improvement
suggestions
to
make
this
series
even
knowledgeable,
for
you
do.
Let
us
know
which
erp
would
you
like
to
see
in
future
episodes?