►
From YouTube: Onboard The World Into Your Rollup dApp with BLS Wallet by Jacob Caban-Tomski | Devcon Bogotá
Description
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/onboard-the-world-into-your-rollup-dapp-with-bls-wallet/
Bringing non-web3 native users into a dApp is always a fraught, friction filled experience, even with cheaper transaction costs on rollups. In this talk, we will show you how you can modify a dApp using BLS signatures & a smart contract wallet to:
- Embed a wallet directly in your dApp, and allow users to eject by swapping its public key.
- Bundle multiple transactions into one and submit to an aggregator to lower friction & save on gas.
- Pay for your user's transactions.
Speaker(s): Jacob Caban-Tomski
Skill level: Intermediate
Track: Layer 2s
Keywords: scaling,onboarding,dapp
Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/
Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
A
Itos
and
welcome
everybody
how's
everyone
doing
today,
nice,
all
right,
I'm,
Jacob,
montowski,
I'm,
a
developer
on
the
BLS
wallet
project,
and
here
with
me
today-
is
James
Zacky,
who
is
our
Project
Lead
and
we're
going
to
talk
about
BLS
wallet
anyways?
What
we're
going
to
cover
today
when
the
next
slide
pops
up
is
we're
going
to
go
over
at
a
high
level,
the
team
and
project
outcomes
a
little
bit
on
the
basics
in
a
high
level
overview
of
BLS
signatures
and
aggregation.
A
A
A
So
cut
some
of
the
outcomes
we
want
to
try
to
reach
with
our
project
and
the
primary
one
are
North
Star
or
here
in
the
southern
hemisphere.
The
Southern
Cross
is
going
to
be
reduce
the
the
cost
of
L2
transactions,
primarily
by
reducing
the
amount
of
data
that
is
rolled
up
into
l1s
by
reducing
transaction
size.
A
So
another
outcome
we're
looking
for,
is
to
be
able
to
improve
wallets
one
of
the
features
with
that
is
going
to
be
account
recovery.
Sometimes,
people
talk
about
a
social
recovery,
so
if
your
project
keys
are
compromised,
is
there
a
way
you
can
swap
to
a
more
secure
set
of
private
keys
and
what
kind
of
features,
functionalities
and
security
that
will
enable?
And
then
we
also
want
to
have
upgradable
functionality
for
wallets.
A
So,
to
start
off
we're
going
to
cover
Els
signatures
and
aggregations
at
kind
of
a
high
level.
Bls
stands
for
bone
Lin
chacham
is
a
pairing
cryptography,
based
signature
scheme
used
in
the
ethereum
consensus,
layer,
zcash
and
a
number
of
other
projects.
It
is
deterministic
for
a
given
public
key
and
message.
A
We
have
access
to
the
BN
254
curve
via
eip197
that
allows
us
to
which
we
use
in
BLS
wallet
for
both
signing
and
then
verifying
on
chain
the
transactions
we're
hoping
in
the
future
via
a
newer
EIP
that
we
will
be
able
to
actually
move
to
the
beacon
chain
curve
for
more
security
and
for
better
access
to
Frameworks
that
the
beacon
chain
is
using
to
improve
that
signature.
But
the
most
important
thing
for
us
is
Central
aggregation
and
what
we're
able
to
do
with
the
BLS
signature
scheme
is
take
multiple
signatures.
A
Let's
work
yeah
and
merge
them
into
one
signature.
So
normally
with
the
signature
space
you'd
have
taking
up,
we
can
shrink
it
into
just
one,
and
this
is
really
good
for
reducing
the
data
that
we
roll
up
into
an
L1
because
normally,
when
a
rollup
goes
in,
it
takes
all
the
transaction
data
as
well
as
the
signatures
for
each
of
those
transactions,
specifically
the
RS
and
V
components
of
that
signature.
A
A
A
Those
are
then
submitted
into
this
aggregator
service
to
create
a
single,
a
bundle
of
operations
with
one
aggregated
signature,
then
the
bundler
will
aggregator
will
take
that
set
of
transactions
and
we'll
submit
them
into
the
layer.
2
evm,
where
we
can
do
some
work
with
expansion
to
expand
the
call
data
parameters
into
more
Advanced
or
more
verbose
data.
We
do
the
BLS
signature,
verification
across
those
and
then
finally,
for
each
of
those
operations
and
actions,
we
submit
it
to
the
actual
contract
wallets
and
that
is
then
executed
against
the
actual
underlying
DF
code.
A
So
this
is
a
library
that
our
teammate
Andrew
helped
right.
If
you
want
to
try
it
out,
you
can
npm
install
BLS,
wallets
Dash.
Clients
still
keeps
in
that
edge
of
that
stage
in
there
we're
going
to
have
a
bundle
that
we're
generating
and
the
wallet's
going
to
sign
it.
That
operation
is
going
to
have
a
nonce
which
is
going
to
be
the
current
wallet
nonst,
for
if
the
wallet
hasn't
been
created
yet
and
it's
going
to
be
lazily
created,
it'll
just
be
zero.
A
A
A
And
as
you
can
see
here
in
an
example,
we
have
a
standard
transaction
confirmation
which
contains
three
actions
inside
of
it,
one
of
them
in
the
middle
being
an
approved.
So
instead
of
a
user
having
to
go
in
and
separately
run
the
transaction
for,
approve
and
say,
transfer
and
something
else,
we
can
do
it
all
in
one
and
have
just
one
confirmation
dialogue
pop
up
to
them.
A
Our
teammate
John
has
built
a
very
cool
demo
using
scaffoldeth
for
the
scaffoldeth
community,
which
is
a
single
pool
Dex.
As
you
can
see
here,
it's
a
just
single
pool
decks
with
a
swap.
It
does
use
the
multi-action
as
well
to
do
the
approve
and
the
swap
inside
of
it,
and
then
it
all
runs
inside
of
the
browser
with
no
need
for
like
upfront
gas,
because
the
aggregator
proxy
is
going
to
subsidize
it,
and
so
that
allows
for
free
transaction.
You
can
find
out
more
at
this.
A
We're
also
looking
into
doing
this
directly
via
a
contract.
The
way
the
aggregator
currently
works
is
when
it
receives
a
bundle.
It's
going
to
actually
introspect
and
look
at
whether,
when
it
stimulates
executing
that
transaction,
if
it
gets
paid
either
in
F,
or
we
also
allow
erc20
tokens
if
it
sees
that
it
happens,
it
will
include
it
in
the
bundle
it's
going
to
submit
to
layer
2..
A
You
can
also
do
things
potentially
like
gate
this
payment
via
an
allow
list,
ownership
of
an
nft
or
potentially
even
something
like
a
zkp
proof,
so
that
you
can
only
allow
certain
people
to
have
access
to
that.
This
also
allows
anyone
potentially
to
be
a
bundler
and
submitter,
potentially
even
Mev
Bots,
that
are
looking
for
profits
and
be
able
to
submit
those
in
so
that
you
don't
have
to
go
through
a
specific
aggregator
and
you
could
submit
to
say
just
a
general
say:
bundle
mempool
going
on
top.
A
C
You
yeah
you've
done
pretty
well,
given
the
slides
have
been
a
bit.
Often,
we've
just
lost
our
speaker
notes,
but
okay
yep.
So
with
recovery,
it's
kind
of
catastrophic
with
an
AOA
if
your
private
key
is
compromised,
you're,
basically
racing
against
an
attacker
to
secure
your
assets,
but
with
a
smart
contract
wallet,
we've
implemented
a
recover
function
that
requires
basically
setting
a
recovery
hash
from
that
hash.
C
Yeah
we've
got
the
notes
now
behind
the
timer
yeah,
so
with
a
recovery
hash.
It
just
consists
of
the
address
that
you're
going
to
trust,
to
call
the
recovery
function
and
the
the
hash
of
the
wall,
the
wallet's
public,
key
that
you're
addressing
and
some
salt,
so
that
you
so
that
an
attacker
can't
actually
deduce
your
recovery
address
or
the
wallet
that
we'll
call
that.
C
So
when
you
do
call
recovery,
you
pass
in
those
parameters
and
you
are
the
caller
itself,
then
you
can
immediately
reset
your
BLS
key
and
yes,
basically
stop
the
attacker
who's
Set,
who
may
have
attempted
to
take
some
of
your
assets
or
set
some
of
the
other
functions.
So
if
an
attacker
steals
your
key
and
tries
to
reset
your
key,
they
can't
do
that
because
there's
a
one-week
delay
in
setting
that
parameter
with
your
recovery.
You
can
do
that
straight
away.
C
We
take
advantage
of
the
fact
that
when
you
first
set
your
recovery
hash,
it
will
set
it
immediately,
but
otherwise
it's
a
secure
function,
so
it
will
have
a
delay
and
in
doing
that,
you
can
do
something
quite
fun
with
that
in
that,
if
you
want
to
onboard
your
users,
you
can
put
a
wallet
inside
the
browser
and
have
them
use
that
you
can
send
them
some
assets
like
give
them.
Basically
a
web
2
usability
experience,
but
you
they
actually
have
web
free
assets
in
their
browser
wallet.
C
But
then,
at
some
point
they
may
say
they
may
wish
to
secure
those
assets
further.
So
you
have
the
smart
contract
deployed.
You
have
the
key
inside
the
browser,
but
that's
not
very
secure,
so
you
can
do
something
like
suggested,
the
user,
that
they
set
the
recovery
hash
of
their
browser
wallet,
and
you
can
do
that
via
the
DAP
and
then
from
the
secure
wallet
that
you've
prompted
them
to
install
like
if
it's
our
prototype
extension
quill.
C
We
find
that's
just
a
smooth
way
to
onboard
people
so
where
to
next.
So,
let's
sort
of
start
with
where
we
began.
So
we
were
looking
primarily
at
aggregating
signatures,
obviously
to
reduce
the
call
data
towards
layer,
one
on
Roll-Ups
and
we
wanted
to
I,
don't
have
slides
here
so
yeah
I
wanted
to
leverage
account
abstraction,
which
was
at
the
protocol
layer
first,
so
that
was
eip2938
with
that.
We
realized
there
could
be
some
delay
for
that,
and
also
that
seems
to
have
paused
since
then.
C
So
we
decided
at
that
time
to
focus
on
a
BLS.
Only
signature
scheme
because
that's
what
we
needed
and
that
would
be
a
contract
wallet.
We
did
some
preliminary
optimizations
like
parameter
deduplication.
So
if
you
have
a
bundle
with
a
lot
of
common
parameters,
you
can
effectively
like
factorization,
you
take
it
once
out
the
front
and
fill
in
the
gaps.
So
something
like
an
airdrop
is
is
really
valuable.
C
So
if
someone
wants
to
do
an
airdrop,
they
can
send
a
bundle
of
transactions
they
pass
in
one
contract,
they're
interacting
with
it's
one
sender:
it's
one
address
it's
calling
it
and
then
yeah.
Some
of
the
parameters
are
the
same
except
for
the
recipient,
and
in
that
case
you
can
effectively
yeah
deduplicate
parameters.
There
you've
got
to
ignore
that
screen.
There
we
go
yeah.
C
Some
of
the
wallet
features
we
then
focused
on
were
as
Jake
described,
sponsored
transactions,
multi-action,
recoverability
and
upgradability,
and
then
we
heard
about
eip4337
and
started
getting
some
interest
in
popularity
and
at
that
time
our
contracts
were
going
for
audit,
so
we're
trying
to
figure
out.
Do
we
just
finish
what
we're
doing
or
look
at
that?
So
then
we
decided
to
yeah
look
towards
being
compatible
with
four
through
the
seven.
So
that's
where
we
are
now
where
to
next,
we
still
focusing
on
aggregating
signatures
for
the
lowest
cost
transactions
on
Layer
Two.
C
C
What
I
should
explain?
Yeah
4337
is
doing
account
obstruction
on
chain,
so
they've
got
a
basically
a
smart
contract
template
for
that
and
a
structure
for
how
that
will
work
regarding
paying
gas
as
well.
The
way
we
originally
did
it
as
Jake
described,
is
putting
in
a
reward
to
the
TX
origin,
so
that
Mev
Bots
can
process
the
transactions,
but
there's
also
the
way
using
the
Altman
pool
that
4357
proposes
it.
So
we
can
do
either
of
those
depending
on
what
the
DAP
wants.
Further
optimizations
the
4337
user
operation
contains.
C
You
know
more
gas
parameters
to
take
care
of
the
way
they
do
that,
but
for
when
we
want
to
do
it
the
direct
payment
way,
we
can
again
optimize
those
parameters
out
by
not
passing
them
in
having
a
preceding
function
that
then
populates
them
with
zeros
and
then
from
there.
We
can
do
public
key
mapping,
so
we
have
yeah
smaller
data
sent
in
for
the
larger
addresses,
sorry,
larger
public
keys
and
also
doing
things
like
floating
points.
C
So
if
a
bundle
has
a
lot
of
variables
that
are
actually
within
a
specific
range,
we
don't
need
to
pass
in
a
un256-bit
number
for
each
of
them.
We
can
actually
have
some
smaller
range
for
those,
so
saving
bytes.
Wherever
we
can
there's
a
lot
of
things
we
want
to
do
there,
some
of
it
just
almost
like
it
would
say,
a
refactor
phase.
C
Even
if
it's
a
you
know
during
a
busy
time
and
there's
you
know,
high
gas
costs,
a
high
value,
Asset
transfer
is
worth
it.
You
will
pay
a
hundred
dollars
a
transaction
to
move
something
of
significant
value.
Similarly,
if
you're
there's
a
hyped
up,
nft
drop
people
will
spend
the
gas
to
do
it.
But
that's
not
everyone.
That's
a
that's
kind
of
I
would
say
very
small
set
of
a
population
with
Roll-Ups.
C
You
can
get
cheaper
transactions
towards
tens
of
cents
or
less,
and
then
you
can
casual
gaming
at
warrants
that
you
can
spend
tens
of
cents
for
a
certain
type
of
interaction
and
that
works
there.
But
what
we
want
to
do
is
go
towards
this.
We
with
evm
Roll-Ups,
adding
the
BLS
signature
scheme,
gives
you
some
savings
and
obviously
all
the
other
things
that
that
reduce
the
layer
to
transaction
cost
will
open
up
the
applications
towards
a
microfinance
in
developing
economies.
C
Optimization
will
just
be
ongoing.
We'll
look
to
do
those
other
optimizations
to
make
transactions
cheaper
for
the
wallets
that
already
have
it
integrated
and,
of
course,
things
just
get
even
better
when
when
four
eight
four
four
drops.
So
this
is
how
it
feels
to
me
that
we've
got
on
the
one
hand,
a
lot
of
real
world
problems,
that
kind
of
a
cut
out
from
the
web
free
Solutions
due
to
the
cost
per
transaction.
C
But
we
hope
that
we
sort
of
once
that
joins
in
that
we
will
get
these
real
world
problems
being
solved
by
web3,
Solutions
and
yeah.
We
just
sort
of
are
looking
forward
to
that
time,
because
I
think
that's
when
we'll
get
again
a
Resurgence
of
a
lot
of
activity,
we
have
a
lot
of
users
will
actually
be
able
to
benefit
from
The
Primitives
that
we're
building,
but
everyone's
building
in
the
community
So
This
Is
Us,
where
web
BLS
wallet.
C
D
D
C
Yeah,
so
quite
a
while
ago
we
we
started
that
Journey
we
started
contacting
I
think
there
was
even
end
of
last
year.
I
started
contacting
some
wallets
just
to
see,
which
ones
might
be
interested.
How
to
begin
that
conversation,
and
so
it's
a
very
good
question.
We
had
some
interest
from
wallets.
Certain
wallets
are
saying
yes,
we
want
to
do
this,
it's
quite
interesting,
but
with
what
we
had,
it
just
seemed
to
not
get
integrated.
C
So
there
was
a
bit
of
a
delay,
I
think
from
wallets,
but
we
were
also
not
live
yet
so
I
think
once
we're
live.
That
will
be
helpful
when
4357
came
about,
which
is
the
on-chain
account
abstraction.
There
was
a
lot
of
conversation
interest
around
that
standard,
and
so
maybe
the
wallets
will
integrate
that
standard
sooner
and
then
we
can
have
those
conversations
again
and
to
say
look
here
is
an
implementation,
and
these
are
the
features
of
this
one
and
I'm
sure
there'll
be
other
implementations
for
other
signature
schemes.
C
D
C
So
so
foreign
maybe
shows
it
better.
This
is
a
bit
slow,
yeah,
so
the
the
nodes
don't
need
to
change,
so
so
the
clients
that
the
say
the
aggregators.
Here
we
go
this
one.
So
at
the
moment
we
have
a
dedicated
server
that
will
do
the
bundling.
We've
already
had
conversations
with
one
particular
Layer
Two
about
this
to
say
that
they
would
want
to
integrate
this.
So
for
us,
that's
been
not
been
the
barrier.
C
B
Hey
Jesse
from
coinbase
two
questions:
one
is:
if
we're
exploring
kind
of
eip3
4337,
is
there
anything
specific?
We
should
be
keeping
in
mind
with
BS
BLS
to
make
sure
that
there's
like
compatibility
there
just
on
the
coinbase
side
and
then
the
second
question
is:
how
does
the
atomicity
actually
work
in
the
user
operation
transactions?
How
is
that
actually
implemented
and
like
executed
on
the
actual
layer,
yeah.
A
C
And
and
yeah
regarding
the
what's
required
on
your
side,
it
would
just
be
the
signing
like
the
client
side
would
just
need
to
sign
the
BLS
signature
for
that
pot
and
then,
depending
on
which
way
you
go
directly
or
via4337.
It
will
just
be
interacting
with
the
contract
wallets
that
it
deploys.
The
second
question:
sorry,
what
was
the
second
one
again,
the
oh
yeah,
sorry,
that's
right!
So
for
the
multi-actions
we
have
a
set
of
it's.
C
Basically,
an
array
of
actions
inside
a
user
operation
and
and
I
think
457
has
done
the
same
thing.
It's
it's
the
same
format
that
you
can
specify
a
set
of
actions.
I
use
a
so
yeah,
it's
kind
of
a
cascaded
function,
so
that
I
can
call
it
a
try
on
one
of
them.
And
so,
if
one
of
the
actions
fails,
then
it
reverts
and
then
so
all
of
them
revert
within
that
try
and
then
I
catch
and
then
I
go
on
to
the
next
user
operation.
C
A
Yeah
to
start
out,
we
would
expect,
like
the
app
would
probably
run
its
own
aggregate
proxy
just
to
kind
of
like
bootstrap
the
process.
Eventually,
it
could
potentially
be
like
a
larger
swath
of
say,
like
nodes,
having
compatibility
with
that.
We
also
think
that,
if
we're
able
to
kind
of
move
more
towards
that,
like
contract
funding
for
the
gas
that
will
make
it
so
it
does
not
matter
kind
of
where
you
submit
it
when
it
eventually
is
executed
on
chain.
E
C
Yeah,
no
definitely
that's
a
very
good
question,
so,
firstly,
the
quill:
isn't
we
don't
want
to
release
Quail
as
a
wallet?
It's
meant
to
be
like
a
reference
implementation
to
show
how
other
wallets
can
integrate
the
client.
We
had
considered
spending
more
effort,
making
the
UI
match
the
designs
that
have
come
about
so
the
designs
we
have
over
there.
C
So
we've
done
that
as
more
of
an
exercise
to
say
this
is
what
wallets
can
do,
but
again
we
had
considered
putting
that
into
quill,
but
because
we
don't
want
to
necessarily
launch
it.
We
leave
them
there
as
reference
implementations,
quill
being
the
technical
one
and
the
design
being
for
other
wallets
to
learn
from
if,
if
that's
a
value,
so
there
was
some
user
research
done
with
that.
As
well
and
yeah
I
think
we
still
have
some
time
for
questions.
We've
got
another
yep,
we
go
question
up
the
front.
F
Thank
you
so
much.
This
is
amazing.
I'm
just
learning
about
BLS,
so
don't
mind
if
my
question
is
too
naive,
but
with
developments
like
ZK
evm
on
layer,
twos
for
Signature,
aggregations
and
atomicity,
like
I,
can
basically
do
like,
as
you
showed
like,
approve
and
then
transfer
like
bunch
of
things.
What
do
you
think
about
like
recursive
proofs?
So
if
I've
I
I
have
like
multiple
transactions,
I
have
each
proof
and
I
take
them
and
just
submit
recursive
proofs?
A
Yeah
I
think,
and
you
might
have
some
fastness
two
James
I-
think
we
haven't
really
fully
looked
into
what
it's
going
to
look
like,
but
we
think
this
wallet,
PLS
wall
ecosystem,
would
work
in
any
evm
compatible
system,
and
so
we
might
be
able
to
even
reduce
some
of
the
data
that
needs
to
be
proved
or
run
over
in
those
eke,
evm
setups.
But
I.
We
haven't
done
a
ton
of
experimentation
yet,
but
there
is
the
possibility
that
it
will
help
at
South
China.
That's
our
time.
Thank.