foreign
[Music]
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 uh
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
we're then going to cover
um where BLS wallet is today with some
examples and some of the features we
have built in
and then we're going to cover where
we're going next with the project and
finally we should have ample time for
questions
so we'll kind of go over the team and
some project outcomes to start
this is our wonderful team
right here off of it off little that's
okay
um we're scattered all across the globe
we're part of the privacy and scaling
Explorations Group which is a subgroup
of the ethereum foundation we work
mainly with zero knowledge proofs and
layers get layer 2 scaling technology
um our goal is to bring more privacy and
scalability to the ethereum blockchain
system
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 uh the
cost of L2 transactions primarily by
reducing the amount of data that is
rolled up into l1s by reducing
transaction size
currently with some initial numbers
uh which are a little difficult to see
right now we've essentially simulated
running 150 erc20 transfers both
regularly normally on a roll-up as well
as bundling them all together into a
single L2 transaction using BLS wallet
and we've gotten it down the transaction
data size by about a quarter
um we're hoping that we can go even
further than that uh we still need to
measure the impact that we're going to
have on layer 1 gas costs to see how the
transactions are actually going to be
reduced
um but our team likes to limbo and we
want to see how low can we go
with using some things involving address
books
um as well as some other indexing things
to reduce that call data even lower than
uh where it's at we'll get into um how
we reduce that size in a moment
so another outcome we're looking for is
to be able to improve wallets
um 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 so you can
change what features and things it has
over time so that wallets can serve a
more diverse set of users across the
entire ecosystem
and finally we want to make D apps a lot
easier to use
and so part of that is by having a baked
in multi-call
um or we call it multi-actions where you
can take multiple transactions and put
them into one
and then also having sponsored
transactions where the user does not
have to pay gas on their end and the D
app sponsors it instead so that way when
users first come in to try at the app
for the first time they don't have to go
stay tuned exchange to buy ethereum so
they can pay gas for transactions
so to start off we're going to cover Els
signatures and aggregations at kind of a
high level
uh BLS stands for bone Lin chacham uh is
a pairing cryptography based uh
signature scheme used in the ethereum
consensus layer zcash and a number of
other projects
it is
um deterministic for a given public key
and message
um validators currently are using BLS uh
signatures specifically on the bls-12381
curve uh two uh sign messages on the
consensus layer
um and then inside of the evm execution
layer we have access to the BN 254 curve
via eip197 that allows us to um which we
use in BLS wallet for both signing and
then verifying on chain the transactions
uh we're hoping in the future via a
newer EIP that we will be able to
actually move to the beacon chain uh
curve for more security and for better
access to Frameworks that the beacon
chain is using uh 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
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
um and this is really good for reducing
uh 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
instead we can use one BLS signature
across all of those transactions plus
one is ecsa signature and save on that
data that we roll up and that's in the
example we saw before why the actual
transaction data payload is much smaller
um if you're interested in learning a
bit more about the underlying of pairing
cryptography
um there's a really good visual guide at
cryptology which will go into the actual
aggregation and more about the actual
BLS signatures
so let's get into where we are today
with BLS wallet
so at a high level as per most normal D
app usage you're going to have a browser
that's going to have a extension usually
in the wallet and that's going to be
communicating to some RPC node and we
have the same setup in our example
prototype extension
we're then going to in our case though
have a set of user operations that we
forward to an aggregator service which
is going to take many to separate
operations and merge them all together
into one and submit them to an L2 node
which then will execute against our uh
contracts for the verification of the
signatures and then through the smart
contract wallet
to dive into that a little bit more
at a high level we're going to have a DF
starting out by generating the
operations which contain a set of
actions and we'll go into what that
format looks like in a second
the wallet extension will then use the
BLS client module to sign all of those
with those BLS signatures
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 uh 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 uh that is then executed against the
actual underlying DF code
so the first feature we're going to dive
into is the multi-caller action
um for this
so uh this is a library that our
teammate Andrew helped uh right if you
want to try it out you can npm install
BLS wallets Dash clients still keeps in
that edge of that stage
um 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
we then have an array of actions where
those actions are Atomic so if any one
of these actions were to fail then they
all would fail
um inside of that you can specify an F
value as part of that the contractor
targeting and then finally the encoded
function that you'll send over
in the case of the example we have up
here we're doing an approve and a swap
on a simulated decks and instead of it
having to be two separate transactions
we can just merge it into one via that
format
um using building on top of this we've
built a prototype uh browser extension
wallet called quill
and
fast cool called quill uh with Andrew
and katuk and
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
um if you want to learn more about how
we have this set up and how you can
integrate the D app into it right now um
You can find out more of the link below
in our GitHub repo on how to integrate
that in
so next we'll get into sponsor
transactions
so right now the pattern we're using to
have these sponsored transactions is to
have our normal flow but in the middle
we're injecting in this top Center
portion the aggregator an aggregator
proxy which essentially is taking those
operations we would normally submit to
an aggregator and is instead sending
them to it where it qualifies to see if
they're uh if they can be you funded uh
for free gas basically and so then that
aggregator proxy will add that payment
bundle in on uh in there and then submit
it to the normal aggregator which
requires the fee and this allows for us
to have those gasless transactions
our teammate John has built a uh very
cool demo using uh 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
um 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 uh the GitHub repo below
and it also is deployed at single pool
Dex react app.versel.app
um we're also looking into doing this
directly via a contract
um the way the aggregator currently
works is when it receives a bundle it's
going to actually introspect and look at
um 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. so one of the ways
you can take advantage of this inside of
a contract is just have it pay
transaction origin
and then the every year will get paid
um 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
um 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
um we still have more research to be
done to figure this out but we believe
it should be uh pretty feasible and
possible to do
all right and now I'm going to hand
things over to my teammate James James
thank you yeah you've done pretty well
given uh the slides have been a bit
often we've just lost our speaker notes
but okay
uh yep so with recovery um it's kind of
catastrophic with an AOA uh 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
yeah we've got the notes now behind the
timer
um yeah so with a recovery hash it just
consists of the address that you're
going to trust to call the recovery
function
um and the the hash of the wall the
wallet's public key that you're
addressing and some salt so that you
um so that an attacker can't actually
deduce your recovery um address or the
wallet that we'll call that 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 uh yes basically stop the
attacker who's Set uh who may have
attempted to
um 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 so as soon as you see a
problem
um in that someone's trying to set
something you didn't you can intercept
it with this
we take advantage of um 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 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 you can
then recover the wallet that was in the
browser and what you've done is
effectively set a private key to the
extension key rather than the one in the
browser so that is lost and you've
secured it
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 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
uh 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 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
um yeah some of the parameters are the
same except for the recipient and in
that case you can effectively yeah
deduplicate parameters uh there
you've got to ignore that screen there
we go uh yeah 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
um 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 we will be focusing oh my
slides moving around
yeah still focusing on aggregating
signatures and then we are working on
being 437 compatible one of our
colleagues is almost there with that and
I noticed that draw in the background
say hi uh so he's working on 4337
um what I should explain yeah 4337 is
doing account obstruction on chain so
they've um got a basically a smart
contract template for that and a
structure for how that will work um
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 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
um yeah smaller data sent in for the
larger addresses sorry larger public
keys and also doing things like floating
points 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 we want to
bring some of the stuff we have in our
current wallet basically into modules so
we may consider using safe for that and
some of the examples in 457 and then we
will inherently benefit from 4844 which
is um yeah towards dank shutting
so when we take a step back what we're
doing is lowering the transaction costs
on Layer Two and when you do that it
increases the number of viable
applications that can be built or viable
solutions that can be put out there to
solve problems
and I'd like to sort of visualize it
like this on the um the x-axis we've got
transaction costs and we have a lot of
defy things going on and that works on
layer one even if it's a um you know
during a busy time and there's uh 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
um with Roll-Ups 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
um will open up the applications towards
a microfinance in developing economies
so this is where we are now we're live
on arbitrim nitrogioli test net and
we're going to be deploying to Arboretum
and optimism after some autofixes and
other layer twos that evm compatible or
equivalent
we'll seek to do what
um basically get this into wallets
currently and to encourage ducks to use
it so we'll first Target applications
where this will have a direct benefit to
help help sort of priced out users and
of course support regular web free
wallets with integration via 4337
because that seems to be where the
attention is with wallets
and further 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 uh 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 but um
we hope that we sort of once that joins
in that we will get these real world
problems being solved by web3 Solutions
and uh 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 if
you want to learn more check it out in
browser demo it's at BLS wallet.org
maybe don't hit it all at once in case
it crashes but it'll be fine check it
out GitHub there's a Discord web3well
and um yeah are there any questions
okay I just question yeah okay
um again uh congratulations for the
project it's very it's going to be very
useful to the community my question is
um when you create the wallet and make
this this changes you're proposing that
is great
you need also to update to the clients
because for instance to support the
multiple
transactions they want to sign it it's
amazing idea
are you talking to the I don't know with
execution layer clients to help them to
adopt their clients how are being those
conversations absolutely yeah so
um 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
um 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 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 so there will be
a change on the wallet side so that I
have to sign with a different signature
scheme and then obviously in the UI and
all that apart from the quill extension
which is the um basically a reference
browser wallet we've also gone through a
large design
um I guess
um yeah a large design a set of design
and to look at what future wallets can
look like so these can form a bit of a
you know a bit of design help for
wallets as well
um
oh yeah
okay
oh
uh yeah with the clients like Geth or
neighbors are you talking to those teams
so so foreign
maybe shows it better
um this is a bit slow
yeah so the
the nodes don't need to change so so the
clients that uh the um say the
aggregators here we go uh this one so at
the moment we have a dedicated server
that will do the bundling we've already
had conversations with um one particular
Layer Two about this to say that they
would want to integrate this um so for
us that's been not been the barrier
we've heard great enthusiasm from
um the layer 2 networks to say as soon
as wallets are doing this they're going
to put it in like the nodes have a
vested interest to reduce their costs
so so that like for us that's been a
like that was I did an early litmus test
in a sense to talk to them and they're
like if this is in the wallets we'll put
it in the next day almost like that was
the the signal I got from them but as it
stands this is one solution um the 437
solution is a little different because I
think it's an alternative mempool
um but yeah you can maybe check out
their talk for more information on that
we've got a couple of questions over oh
sorry over here yep
hey Jesse from coinbase
um 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 uh layer yeah um I can cover for
the BLS signatures
um both the the current I think it's f
inflatanism is the repo
um and our wallet under the covers are
using the same BLS verification and
solidity and also the same client
libraries so they should be largely
compatible
um for that yeah 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 um signature for that pot and then
uh depending on which way you go
directly or via4337 it will just be
interacting with the contract wallets
that it deploys uh 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
um it's basically uh 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
um that you can specify a set of actions
I use a um
uh 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 so each user operation is in a
loop and within there it calls the set
of actions to the wallet and if one of
the actions fails only the user
operation is reverted not the rest of it
because of the try catch which was nice
the facility has that now
yep
um who do you anticipate running these
aggregated proxies
we hope that they get merged into the
nodes into their later nodes yeah to
start out um we would expect like the
app would probably run its own aggregate
proxy just to kind of like bootstrap the
process eventually
um it could potentially be like uh a
larger swath of say like nodes having
compatibility with that we also think
that um 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
um that's when the actual like payment
subsidation will happen and so then it's
less important but just to start out
we're having that kind of more like
centralized service just kind of get
things going
thanks for this presentation appreciate
it
does quilt have any sort of priority on
test automation for end-to-end testing
um you know usability testing seems like
wallets right now don't pay very much
attention
to the user experience yeah because what
are users seeing what are they clicking
on
yeah no definitely that's a very good
question so firstly the quill isn't um
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
so if you go to our Discord I think in
in The Design Channel we have a link to
the design brief that was done or does
it I forget what we call it as a whole
but there's just been a large design
process done to look at what wallets of
the future can look like multi-chain
multi-wallet and all of that being very
usable 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
thank you so much this is amazing
um 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
um for Signature aggregations uh 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 uh
so if I've I I have like multiple
transactions I have each proof and I
take them and just submit recursive
proofs so in that case how like how do
we think about developments in ZK evm
and BLS going to get I'm going to yeah I
think um and you might have some
fastness two James
um I think we haven't really fully
looked into what it's going to look like
but we think um 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 you
thanks everyone
[Applause]
[Music]
[Applause]
all right thank you so much for that
next up is a talk by Patrick who claims
to be an intern at infuria and in the
past has been an assistant professor at
many universities uh please welcome
Patrick for his talk on validating
Bridges Roll-Ups and plasmas
thank you