Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
Unique Use-Cases for Web3 Privacy, Powered by Sapphire
Recorded: Aug. 21, 2023 Duration: 0:50:15Space Recording
Full Transcription
Oasis, as well as Johnny, the lead dev at Imperial. Johnny and Harry, do you guys want
to maybe give a brief introduction? And maybe Johnny, you can talk a bit about what Imperial
is trying to do, a brief overview of the project.
Sure. Good morning, everyone. So I'm Johnny. I've been working on Imperial for about five
months now. And as a project, we're focused on building tooling and an SDK for generalized
development of blockchain applications that abstracts a lot of the complex aspect of dApp
development. And one of those in particular that we're very focused on right now is wallet
abstraction and delegating authority of your wallet to different applications in a manner
that's trust minimizing, but also more flexible than just the typical approvals that you might
give for tokens. And we've been looking into using Sapphire. And I started doing some, you
know, early testing with it. We've gotten really good results. So we're really excited to talk
about it today. And I'm Harry. So I'm doing product management at the Oasis Protocol Foundation.
I've got a deep interest in account abstraction and confidentiality as well. And I'm really
focusing on all of the different ways that you can get not just privacy, but enable new options
for cross-chain or multi-chain or even like the next level of cloud hardware security module
sort of deeper access control that you can get with a confidential EVM. So in terms of use cases,
what Johnny was talking about is this is really interesting for us to investigate. And it opens
up new areas for EVM that are not available at the moment or are very complicated. And they're made
a lot simpler with Sapphire. Awesome. Yeah. Thank you guys so much for that. I think we're going to get
into the use cases in a minute. But I think the first place that we should probably start
is just the general overview of what is account abstraction. I know it's been getting a lot
of popularity, especially at like UCC and like Alex's keynote speech with all that account
abstraction. What is account abstraction? And what is the problem that is trying to be solved?
Maybe Harry can go first and then Johnny can weigh in.
Sure. So I think account abstraction is best shown with an example of what the problem is.
So for example, if I send you $50 or $100 worth of USDC to an account that you've set up,
you've made a wallet and it might be on Ethereum or Arbitrum or Sapphire or any of a number of other
chains. And you then have this sort of chicken and egg problem of in order to do anything,
I have to get the gas token for this so I can send a transaction on chain, so I can send my USDC
to myself or convert it to something else. So there's the notion of like native wallets and
externally owned accounts, which is the transactions, the accounts which are submitting the transactions
on chain and actually paying the gas for this. And a lot of the Ethereum ecosystem is based at the
moment around the notion that the people who are submitting the transactions on chain are the actual
people who, you know, are in the funds and performing the actions. But with account abstraction,
we need to think of these use cases and how can we let people not have to worry about getting gas
token just so they can send an ERC-20 token. And one of these examples is with the USDC, I say,
I want to send, you know, 50 USDC to my account or to some other account. And I'm going to give whoever
pays the gas for this transaction, you know, like $2 or whatever amount it costs to pay the gas.
And that's not possible with the assumption that the submitter of the transaction is the owner of
the money. So you need some more infrastructure there and some breakdown of some of these
assumptions in order to just make it easier to use.
Yeah. And I can add to that. I think one of the things that we're particularly interested in is
sort of like a subset of account abstraction is things like signature abstraction.
And it's the idea that you can use different signing algorithms to approve transactions.
And at the same time, I'd say another thing is, as it stands right now, you can have a contract
address that allows you to have more complicated logic in the behavior of an account.
And an end user account is non-transferable. And so if you were to create a level of abstraction on top
of that, you can have a different private key that could manage an account and things like that.
And so it's the idea of an account actually being transferable in a way and things like that.
Yeah. Yeah. Thank you so much. I think that that's helpful to give context to the audience.
I think for myself, the way I sort of frame it, maybe this is an incorrect way, but I just think
about basically account abstraction is trying to, again, I guess it's redundant, but abstract away
all the complexities that come with signing and making blockchain transactions and making it more
equivalent to what we are used to in Web 2 and Web 1. So that making any transaction is as simple as
like sending a Venmo or a cash app or something like that. So I guess like a good place to maybe start
this, we talked about this idea of contracts that have the ability to sign their own transactions. And I
think that basically what sort of exploded the area of account abstraction was this ERC
EIP 4337, where smart contracts can now also act as EOAs. So they can act as
contracts that also have the ability to sign their own signature. I know this is natively possible
on Sapphire. So maybe we can talk a bit about that first, Harry. What I guess went into that design
decision and why is it so unique and what does it enable? Sure. So if you look at transparent
chains like Ethereum where the contracts can't have secrets, so you're relying on a lot of external
infrastructure to do things which for us on Sapphire are really quite straightforward and basic.
So one of those is, you know, if I want to control an account on a different chain or if I want to
control a Bitcoin wallet, for example, I'd need to set up like an MPC committee that manages secret
keys and you end up with your own consensus algorithm and a lot of sort of additional
complexity around that and security problems as well. And some of the examples are like
you either rely on the custodial side of things with like Circle or wrapped BTC or you'd go for the
MPC approach with like Ren Protocol or even companies like Web3Auth, where you can store secret keys or
lit.dev or lit protocol which allows you to do delegated signing. And these are all like
additional pieces of infrastructure that are necessary to supplement the sort of the limitations of
what you can't do on Ethereum. And if you give contracts the ability to have their own
confidential secrets and to sign their own transactions, then the amount of sort of additional infrastructure
you need is reduced drastically. So this is, in terms of how to simplify the 4337 ecosystem,
I think that possibly maybe 50% of it is literally just built around the disadvantages of
of transparent EVMs like Ethereum. But they're still necessary. So there's a lot of supplementary
infrastructure that is really, really helpful. Like, yeah, it's an interesting space to look and see
what develops.
Yeah, yeah. So with that in mind, I guess a question for you, Johnny, is was this, was the simplicity of how
to do these account abstraction use cases using Sapphire and Opal, what initially drew you to
the platform? Or maybe was there something else that made you think that it was a great fit for
Imperial to be leveraged during their, as you look into use cases?
Yeah, I think it was the precompiles. So like, when you look at Sapphire, like, one of the things that
really jumped out to me was that you could generate randomness in a secure fashion inside of a smart
contract, which is, I mean, as anyone that's done any solidity developments, there's so much effort
that's put into, like, how do I create secure randomness on chain in like a non trusted fashion.
And so just to have that as like a given immediately, to me, it was like actually really exciting.
And then from there, being able to generate private key, public key pairs for both encryption and
signing, that's another really awesome tool, where you can have a private key on chain,
that not even the smart contract developer can have access to. And it opens up a lot of cool
possibilities that I think, you know, we're just barely scratching the surface of, but it's like a
thread that I just wanted to keep pulling at. And so, like some of the, like the initial things was,
you can create smart contracts that have an outcome where data can either be signed or a
transaction can be signed based on solidity logic. And so, in a lot of ways, I look at Sapphire more
as a distributed trusted execution environment that people can verify that I had, you know,
non manipulated compute occur. And so I almost see it as like a more general tool than just like a
blockchain environment. I see it as like a secure enclave for computation that's verifiable. And I
think that has just like very wide applications, not just in DAP development, but in a lot of
general purpose software development. And so that was kind of what got me excited about it.
Yeah, yeah, exactly. I love the way you think about that. What I often say is that
basically with Sapphire, I guess, and more so Opal, what we're trying to achieve is
the ability for other networks to offload their confidential computation needs to Sapphire. In
the same way, you know, an Arbitrum allows you to offload your scalability needs to Arbitrum,
or Celestia allows you to offload your data availability needs. Sapphire will allow you to
offload the confidential computation needs. And because the blockchain, you know, also know that
it's being done in a high integrity and trustless nature. But one thing I want to, I guess,
delve deeper into is some of these use cases. So, you know, you talked a bit about, I guess,
like what interests you in Sapphire? What are, you know, what's next on the Imperial pipeline? What are
some of the things that you're trying to build? And maybe how are you leveraging Sapphire to build
those things? Yeah. So, um, so I think it's, it's something that, you know, scales and complexity,
but, um, some of the initial things that we're looking at is, I think the, the privacy use cases
are obviously like really interesting in that you can offload if you have a privacy requirement for a
smart contract. Um, you can easily integrate that with Sapphire. And so we did some initial
experimentation with that and built like an enclave on Arbitrum that leverages, um, the OPL,
um, just to get more familiarized with the technologies and start to kind of open up some of
those, um, use cases. But what we're looking at right now is, so we're building an SDK for blockchain
development that, and the biggest thing is, um, when you're a user, um, especially in like a telegram
application or something like that, then you want to grant access to, uh, your accounts to different
applications on telegram or something like that. Um, one of the biggest things is you want to have
security of your private keys. You want them to be revocable, but you do want to give someone access
for trading behavior, um, or, you know, take actions on your behalf. And so using, um, Sapphire,
what you can do is create really fine getting controls over grants to different accounts. So you
can say to an account, like you are able to transact with these platforms or these DEXs trading these
currencies. Um, and when you, uh, no longer want them to be able to make tradings or trades on your
behalf, uh, you can revoke that access. Um, so they're able to take actions on behalf of an end
user account without ever having access to the private key. And I think from there, uh, like the
real area of growth is being able to, um, delegate, uh, more flexible trading on your behalf to different
accounts. And so this is, I think there's like a pretty long, uh, trajectory there in terms of being
able to actually give a trader the ability to make like a wide variety of trades on your behalf without
ever giving you up your private key without having very low risk of them doing something nefarious
with your account.
Yeah. Yeah. That's, that's super interesting. I guess, you know, there's like a, a good amount
of protocols, like set protocol kind of comes to mind, which like sort of are, are attempting to,
to copy like prolific traders and things of that nature. So I guess what you're saying is like using this
SDK, you can sort of grant access to a smart contract to like copy someone's trade, whether
it be, you know, based off of someone being a prolific trader or just being some sort of trading
algorithm or something along those lines. And then, you know, when you no longer want
them to have you have access, you have the ability to revoke that access. Is that, is that correct?
Is that sort of what's what you're talking about?
Um, yeah, so it could definitely work for like copy trading, right? Because you could, um,
provide like a signed transaction from an account and say, I want to make this same transaction,
but with a different value. Um, and then you have like an easy way for copy trading to be done
trustlessly. But I think it's also like, um, say you have a trader that has a strategy that they're
using for Uniswap V3 liquidity or something like that. Right. And you want to be able to give them,
um, some of your account balance with, um, you know, some performance fee being issued.
So there's a bunch of different ways that could be done. Right. But if they're like,
one example would be, if you create this account abstraction where you have a smart contract on
Sapphire that manages like a vault of the different users and their, you know, ownership share of the,
uh, funds in the account. And now you have like a pooled account that has the subtraction of like
the underlying commitments that account, and you have some fine grained control.
And then at the same time, you can have a trader that's working on your behalf,
but if they wanted to, um, you know, they're incentivized because they're putting their own
funds into a single account that they're managing on behalf of more people.
And so you have like a, a joint account with a single fund manager. And so it starts to create
this more kind of flexible, uh, environment for a trader where they have a performance fee for an
aggregated balance of a bunch of different accounts. And then they can start to get, um,
uh, people can pull their funds and add them as they want. And so that's basically being done
because you have like this, um, really cheap gas environment to build a smart contract that has,
you know, significantly more complexity than would be feasible in terms of gas on, um,
Arbitrum or even, or Ethereum or even Arbitrum. And so I think that you can go down. It's like,
I think the rabbit hole is pretty deep, I guess is what I'm saying. Like,
I think that there's really advanced use cases that can come from this.
Yeah. Yeah. That's, that's super cool. I haven't even thought about that, but I guess like one thing that,
you know, comes to mind is that one thing that I always say when I talk about like Sapphire and
Opal and what we're trying to do is, you know, in order for web three to compete with like web two,
basically we have to be able to have the same level of complexity and the same level of sophistication.
And basically, you know, with Sapphire, I think that we, we add this ability for confidential
computation and privacy, which greatly expands what can be done in web three. And it seems like,
you know, that, that example you just gave is, is like a great example of how we're doing that.
You know, these things that previously were not possible are now possible. And as you say,
we're just, we're just sort of scratching the surface. Um, I guess like the, the other thing I
wanted to follow up on is, uh, Harry talked about gasless transactions a bit. I know that you built,
I think, uh, a gap gasless process to unwrap tokens on Arbitrum, if that's not correct.
Um, I was wondering, yeah, if you could just delve into that a bit more, what, what's actually
happening under the hood? How is Sapphire being leveraged for that? Um, yeah, so, um, well, so
the general idea was, um, creating it. So if you have a, an environment where the tokens get wrapped
into a vault in Arbitrum, and then you need a way to relay that information to Sapphire. Um, and so that
can be done in like any number of ways. And I think that's, you know, something we talked about
a bit where if you could actually create, um, a light clients and a ZK bridge, now you have like
this trustless wrapping from different networks onto Sapphire. But then when it's in Sapphire,
in Sapphire, the biggest thing is relying on, um, EIP 712 for, um, signing type data. And what that allows is,
uh, trustless relaying of information from any chain to Sapphire. So that can involve like
transfers or, uh, swaps, or, you know, if you had like, uh, uh, a contract that was abstracting
a yield farm, um, kind of deposit and withdraw logic. And then once it's in Sapphire, um, you're
able to have the smart contract itself, uh, trustlessly real, you can relay the smart contract
signature on type data for the unwrap. So once the funds are unwrapped, now you have, for example,
say you've, uh, pulled them out to a different wallet and you have no gas in the wallet, but you
have wrapped ETH. Um, so as long as the token supports EIP 712, uh, permit signatures, then what
you can do is you can provide a signature and you can basically broadcast it and say like, I approve,
um, these funds being, uh, used by this contract. And then the contract just have to have very tight
guardrails that says like, all I'm going to do is, uh, either unwrap this wrapped ETH or trade this USDC
for a small amount of ETH and then transfer it back to the user. And so, um, the permit signature
allows you to give, um, very specific, um, allowance to an arbitrary contract. And so that was something
when I was building it, I was kind of curious why it didn't exist more. Cause I'm, I know I'm not the
only person that's ever bridged to a new chain and I don't have any gas. And then I'm like, you know,
you have to go into like the discord and, uh, you know, ask people to give you a little bit of gas and
you'll pay them back or something silly like that when it's very easy to just, um, create a,
a small smart contract that trades for ETH and relies on the permit signature and a relayer.
And I think this is mostly in due to, uh, people in blockchain development typically, uh, avoid any
sort of cloud infrastructure. Um, like that's very much like, uh, a thing that projects, uh, kind of,
I won't say they shun, but it's much less likely for a web three protocol to have like an elaborate
cloud infrastructure than it is in web two. And this is a problem that's easily solved by a single
server, um, that is just listening for any sort of, uh, transactions relayed to it.
Yeah. Yeah. I think that, uh, yeah, that, that makes a bit of sense. And yeah, probably
as we move forward in what we have, we have, we have to look for, you know, these sort of
bridges between web two and web three where, you know, I know like, uh, the pinnacle is like
decentralization, but, uh, at the same time we should be also, you know, thinking about like
what level of decentralization is enough, um, and where it's most important in a protocol, like, uh,
there are probably some areas that require decentralization more than others, uh, especially
like if it allows us to build use cases today, if the infrastructure doesn't exist in web three
yet. Um, but backing up a bit, um, I know we talked about a few use cases of Imperial. I just
wanted to get, um, your two cents, Harry, like what are some other use cases that you, uh, are
excited about with Sapphire, um, that maybe Imperial or any other project building on the network might
be interested in leveraging. Um, so I, I'm still trying to work out like, uh, how many
web three users are there out, you know, uh, with phones and men are asking their phones or,
or, uh, like, uh, web three wallets on their phones and their computers. And it's,
there's a huge number of people out there that have, uh, like very capable phones and computers,
and they've got access to, uh, the internet and they have, uh, money and, you know, uh,
loads of different countries around the world have different, uh, sort of banking infrastructure.
And I know that, uh, in a lot of places in Asia, it's, uh, very difficult to make a transaction where
it might take a day or two. And still in, in the UK and the US, uh, you've got the automated
clearing system that, uh, it's the alternative is crypto cryptocurrency or Zelle or something like
that, where it's just super quick and instant, but we're still having problems accessing the rest
of the world outside of the web three space that, um, you know, wants to use this. So, uh, in terms
of like regular users, uh, what Johnny's talking about with, uh, having limits on the amount of trade
that you can do or being able to delegate sort of permits to different people, uh, this is all
stuff that's really useful on a day-to-day basis. So, uh, being able to, you know, uh, give your
friends, um, Hey, you know, I'm, I'm gonna give you like a $50 or up to a hundred dollars and you can
just pay for transactions on my behalf. Um, or even, you know, your children, your family, um, or your
employer gives you a permit to spend up to a certain amount. And, uh, the, in terms of like
account abstraction, that's something that's severely missing in the existing ecosystem,
but with Sapphire being able to make transactions, being able to have secrets in the contracts,
uh, this lets us break free of having to install plugins of having to generate wallets. So, uh,
something I'm working on pushing at the moment is, uh, web auth authentication. So that's, uh, touch
ID, um, you know, face ID, the Android biometrics, uh, uh, uh, you know, security keys like YubiKey,
where the workflow is really, really like slick. It's straightforward. You know, uh, you go to
a website that supports, uh, pass keys and, uh, you scan a QR code and your phone links and you press
your finger on the screen and it authenticates with like a hardware device. That's, um, we're
not taking advantage of this. Uh, it's only in the past say four or five, six months that it's
started to become an initiative in the web three space to, uh, trying to gain access to the rest of
the people, make it easier for us who are already in the space to use the services. So, um, if you
combine that with, uh, account abstraction and like multi-chain, uh, cross chain, uh, use cases,
I think that's the, you know, this is like the, the next generation of web three, which is maybe web
2.5, not quite as awesome, but it's much more straightforward and much more, uh, understandable
by regular people. And yeah, it's, uh, I think the biggest advantage I see for like key pair
generation on Sapphire is that, uh, hopefully we won't need bridge tokens. So with ZK bridges and
being able to, uh, like verify the Ethereum beacon, uh, sort of consensus in ZK and have
that on Sapphire means that you don't have to have like a trusted bridge between Sapphire and other
chains. Likewise, if you have the Bitcoin like client running on Sapphire, then there's a lot of
stuff that you can do that, uh, it just makes things radically simpler. So instead of having
the, the sort of counterparty risk of bridges, and we all know how many different bridges have
been, uh, had oopsies over the past two years or three years, and just be able to like get rid
of that, that risk, make it more acceptable to normal people and make it, make the onboarding
process really, really slick. This is, I think Sapphire is absolutely perfect for this.
Yeah. Yeah, absolutely. And I know Johnny, you've also talked about this idea of using
like clients, uh, for Imperial. Maybe we can just like, you know, expand on this a little bit more.
What, what is it that makes that like clients enable you to do? Um, and why, like what use cases would
you look, look to leverage it for, for Imperial? And like, why do you think it maybe is, uh, you know,
a more secure or a better solution? Um, yeah, so I think it's, um, it's, it's also a convenience
thing, not just the security thing. Um, in the sense that if you have a state route for a block,
you can prove the transactions in the block. Um, and that's a lot more general than, uh, relaying
transactions. And so I think for, um, somebody that's building a bridge, if they just focus
on solving that one problem, it makes it slightly more complicated for the developer. Um, because
instead of them just saying like, uh, relay this message, um, they actually have to, um,
do the relaying themselves potentially. But in, in my mind, I like this solution because
it's less, it's censorship resistant because they're just serving a singular purpose
of putting these state routes on different chains. And then you kind of can use that however you want.
And so that could be, you know, if you have Ethereum state routes that can allow you to prove things about
any rollup that is checking in state on Ethereum. Um, and you know, you basically have
a much wider surface area for your bridging, um, versus relying on just the message passing bridge
where you have, um, really minimal control. And so for me, I like the ability to have
kind of fine grained control over the app I'm building and not have to rely on someone else's
infrastructure. Cause if their infra goes down, that's problematic. But, um, the idea of a ZK
bridge is that anybody would be able to relay state routes trustlessly. And so I think that
this is like a really cool concept and really well primed for, um, Sapphire because it could
become this sort of centrality node, um, for a lot of different protocols where, um, if you wanted
to bridge, you could go through Sapphire trustlessly for like a multitude of chains.
And so that's sort of how I'm thinking about it.
Yeah. Yeah. And Harry, maybe you can expand on that. I know you mentioned that you could
essentially like run a light client on Sapphire for like every chain, at least I think that's
roughly what you mentioned in the past. Maybe you can expand a bit on what you mean by that.
Yeah. Yeah. So I, I think one thing that's worth noting is that, uh, if you think of Sapphire as
being like a, uh, uh, confidential, but verifiable compute, then that means that you don't have to
submit all of your transactions on chain. So, uh, one of the problems with running light clients is
that, uh, uh, uh, you know, every chain ends up running light clients for every other chain. And then
like 80% of the block gas is just running light clients before you even start handling user
transactions. Um, but with, with Sapphire, because you have the confidential sort of verifiable compute,
you can, uh, tell the contract to create proofs or sign proofs that it's verified a certain number
of blocks. Uh, so, uh, say with Bitcoin, the, uh, cumulative proof of work and, uh, then pass that
in on chain in a transaction only when you need to modify state. So in terms of like scalability,
um, yeah, we have some options here that allow us to really break free of, of like the, the fundamental
limits that other blockchains are having. So I know, you know, everyone's just trying to build a
bigger, faster blockchain and you've got like Solana, which is the most reliable blockchain
in the world. It's, it's, it can do 60,000 transactions per second. Right. Uh, but really
we, you know, if you load the blockchain with writes continuously, uh, you do get fundamental
scalability problems. And, and part of that is, you know, every node has to have hard drives and, uh,
the minimum sort of specification for the node starts increasing and increasing, uh, to the point
where, you know, it becomes infeasible to, to run nodes and to keep the service going, uh, indefinitely.
But with Sapphire, you can sort of split the read, write, uh, loads. So if you're scaling across all
of the read nodes, you can perform a lot of compute that doesn't need to modify state. And a lot of that
can be like clients. And then of course you can take the proofs because, uh, if you can still sign for,
uh, sign proofs, uh, from a contract in a view call without spending any gas at all,
and then take that over to some other blockchain, uh, where you make a transaction. So I see lots of
interesting aspects in terms of like, uh, what Johnny said of Sapphire being in the center of everything
else and really enabling, uh, like cross chain use cases. So, uh, being able to bridge chains with each
other that don't have a bridge between them, because you can control funds natively on the
externally owned accounts or in key pair wallets on either chain and perform swaps or, uh, keep track
of, uh, the sort of the sum balance and do net settlement there. I think it's, it's an interesting
aspect to look at. Yeah. Yeah. Uh, I guess, uh, one follow-up question that I have there
is with Sapphire. I know it's possible for essentially, uh, smart contracts on Sapphire to
just sign directly, uh, on other chains. Like you, like, for example, you mentioned you could
even do it from Bitcoin. You can have the private key to a Bitcoin wallet, uh, in a Sapphire contract,
the Sapphire contract can just sign directly. So in some regards, like you don't, you don't need
bridging at all, uh, for the, the outgoing aspects of transactions. So is this a solution just for,
um, like chains moving toward sending messages to Sapphire or is it also Sapphire sending messages
to other chains? Uh, so one of the problems is, is about information of, uh, the contract on Sapphire
doesn't know, uh, the gas price on other chains, or, uh, it might not know the, the accountants on,
on the other chains. So you still need some kind of information coming into Sapphire or a trust model
where, um, you know, the user is controlling their own funds. So they can decide whatever the gas price
is and whatever the accountants is, because, uh, you want to avoid situations where, uh, you could
cause a denial of service. So this is where bridges, uh, as they are now come in and account abstraction,
like the 4337 standard, uh, which is like the sort of global sequencing problem, uh, making sure that
we don't waste gas or spend gas unnecessarily and make sure that our transactions will actually go
through. Uh, so there is a part missing in Sapphire at the moment in terms of, uh, being able to
communicate with other chains and being able to get information from other chains to know, uh, for
example, if a deposit has come in, uh, you would ideally need some kind of trustless oracle or a light
client to, to verify that, uh, uh, Bitcoin or, uh, an ERC 20 deposit has been made. Uh, but after that,
you, uh, when you have these, these pieces in place, you start getting like contract autonomy.
So think of like, uh, the role that your bank normally has, which is, uh, oh, you've, you know,
you've spent too much money in the past week with people that we were not aware of before. Let's,
let's put a control in place and start limiting this for your own benefit, according to rules that
have, uh, you've set yourself that might be, uh, oh, I just need to do a TOTP authentication,
which you can do with Sapphire because it can have secrets and you can't do that with, uh,
with other blockchain because they need to have the TOTP secret. So in terms of like taking control back
to the users, uh, I think it's interesting because it allows you to make your own decisions rather than the
bank decide for you, what your spend limits are, who you're supposed to be spending with,
you know, uh, or being able to arbitrarily, uh, sort of pause, uh, transactions, uh, unilaterally.
Got it. That's a super helpful. I guess the one, one last question I have in this regard is,
uh, we are, you know, working closely with a seller who has just released, uh, this, the CK
attestation framework or bridge, uh, called Brevis. Do you think that Brevis, uh, fits into this idea
well? And like, is that a ZK bridge that can have, has all the functionality that you just mentioned,
or, um, is there still something that we need, uh, besides Brevis? How do you see Brevis,
I guess, fitting into, you know, what we're trying to do, you know, everything we just talked about?
Uh, yeah. So Brevis is really interesting. It's what, uh, like, uh, uh, an initiative between
Stanford and Berkeley and, uh, Texas A&M and Georgetown, I think. And, uh, uh, in addition
to the seller where it's really the culmination of like, what is trustlessness? How do we reduce
trust in bridges? How can we make this as cheap to verify on as many different chains as possible?
And, uh, with the Sapphire 0.6, which I think we've literally just, uh, uh, uh, released test
nets, um, and we'll be going, uh, hopefully fixing some bugs and going live in the next month or two,
uh, where we're introducing the ZK primitive. So that allows us to run, uh, not only roll-ups and sort
of, uh, the ZK privacy ecosystem on, on Sapphire. Um, but we also have the, the trustless oracles,
so this is Brevis with, I think they support a Binance smart chain, the Ethereum beacon chain,
and I think they support the Cosmos ecosystem as well. So, uh, it's, it's, uh, an amazing piece
of technology and it's taken a lot of cumulative work of, uh, literally hundreds of hundreds of
really smart researchers to get to the point where we have the tools, uh, we have the research,
we have the specifications and, uh, the seller is possibly the, uh, the best implementation so far
that, that really nails, uh, uh, the problem of, uh, what's the sort of trifecta of like trustless,
uh, decentralized and, uh, and cheap, you know, and then you have Sapphire on top and you get
private as well, which is, it's phenomenal.
Yeah. Yeah. That's awesome. I can't wait to see sort of, you know, what, what gets developed as,
uh, you know, I think Brevis is a beta right now as they move towards that, they're being at launch
and as we get to start playing with it some more developers like Johnny get to, uh, start looking
at ways they can use it for their protocol. Uh, so really quickly, I want to, I do want to back
things up a little bit. Uh, we talked a lot about, you know, uh, current use cases, future use cases,
and maybe a bit about limitations, but I did want to, you know, just follow up and ask,
you know, are, are there still some limitations with account abstraction, some problems that need
to be solved or maybe even like, you know, just generalize, like there it's possible with Sapphire
today, but the user experience or the developer experience that you ran into Johnny, uh, could,
could use, uh, some, some upgrading so that it's, uh, has a lot less friction. Like where,
where do you see, uh, maybe some, some pain points that we need to address?
Um, well, yes, I think, you know, with any kind of newer tech, the biggest thing I think is
more people need to build on it. So you have more code to compare your code against. Right.
Um, and also in the same way, like more libraries, I think like the Sapphire library,
um, it's sort of like, it's like these primitives, right. But I would like, what I'd really like to
see is more developers start to contribute, um, their own sort of like cheat codes for working
with Sapphire. And so I know that there's the hackathon right now and, uh, we're working on our own,
uh, sort of library to submit and like an implementation to share. So people have something
to kind of see how we're approaching the problem, but I'm excited to see other developers,
um, kind of try to figure it out on their own as well. And I think that software development
by nature is really a collaborative and really decentralized kind of, uh, thing where people
try different ideas out and then eventually some people see it and say, oh, that's a good idea.
Let me take this aspect of that and combine it with that. And so, um, yeah, I think that's
really where it's at. It's early. So we just need more people building so that we can all kind
of work together to come up with some cool stuff. Yeah, exactly. What I like to, when I try to
explain blockchain to, to people who are maybe less web three native, you know, basically the
framework I, I, I try to explain it in is, you know, that everything's a puzzle piece. Uh,
and so like everything builds on top of something that's been built before. Um, and so like maybe,
you know, uh, projects that were built in the last bull run, you know, we're not going to be the ones
that are, you know, the most hype in this next kind of bull run, but most likely what's going to happen
is the products that are, are built on top of those previous projects are going to be the most
interesting ones. Um, so yeah, I, I think that I really liked the idea of like building these libraries,
building this community, uh, and sort of everyone helping each other out is exactly what we love to see
in the, the Sapphire ecosystem. And I also like wanted to thank you for mentioning the hackathon
and mentioning the idea that, uh, libraries are, uh, totally like, uh, uh, very valid and actually
like, uh, something that we wish to see in this hackathon. I know Harry, uh, made it a point to,
to make sure that that was added as a category and it wasn't just, you know, full-blown depths,
but also we need standards, we need libraries, we need all this stuff, uh, in order to, for the
ecosystem to start expanding. So yeah, just thank you for joining the hackathon. Thank you for being
a community member and contributing and helping other people out. Uh, with that said, though,
I do want to get Harry's opinion. What are, what are some limitations that you see right now, uh, with,
with, uh, account abstraction and some places that we can, uh, reduce developer friction, Harry?
Um, so I, I, I'm gonna carry on with what Johnny was saying really is, is in terms of, uh, the
different opportunities for libraries. And a lot of people are trying to create these, these, uh,
like larger things like, uh, maybe a cross chain decks or, uh, like, uh, a cross margin protocol where
it's all, it's quite complicated and it's a big undertaking to do. So, uh, there's a lot of
opportunities still to make a reasonable profit off of minimal components that, um, uh, can serve as
building blocks for others. So if you look at like the component more object model, where you have, uh,
uh, possibly like, uh, 30, 40, 50 different components that together, they act as like a
base layer that let you do so much more than if you were trying to create a huge, like, uh, uh,
you know, like, like a blockbuster app of your own, right? Where a lot of the, the existing
ecosystem runs off, uh, I call them worker bees, right? So it's, uh, now that you've got MEV on,
uh, on Ethereum, a lot of the times you don't actually have to have account abstraction. Uh,
you can just submit a transaction that, uh, will send back enough gas to, uh, pay for,
you know, the transaction itself. And somebody will come along and realize it's profitable.
And then, uh, the sort of the, the, uh, the, uh, the amount of gas necessary to, to run the transaction
we paid by somebody. And there's a lot of situations with like, uh, uh, how do we self-organize? How do
we create components that interact smoothly together? And for example, like the, the open
Zeppelin ecosystem, uh, they're good starting points for a lot of projects. And in terms of
standards, the, uh, uh, you know, there's still like with the RC 20, we've seen in the past couple
of months, there's some rough edge cases there. So yeah, I, I want to see what happens next. Like,
uh, can we have like more collaboration, maybe more specificity? So like projects doing a smaller
thing better at a reasonable price. And yeah, there's a huge amount of, a huge amount of work
that can be done just in terms of finding out what, what's available to do in the space and what's new.
Yeah. Yeah, absolutely. Uh, I think, uh, as Johnny has said, like,
we're just scratching the surface. So I really hope that anyone who's a developer who's listening
to this call, you know, sees the potential of this network and joins our discord or one of our
other community channels and, you know, asks questions and, you know, other community members
can help answer as well as the Oasis team. And we can start building, um, some libraries and some
standards and, you know, get, get sort of building these, uh, collaborative effects in the ecosystem.
Yeah. So I do think that we're out of time, but, uh, I just wanted to thank both Harry and Johnny
for hopping on this call and talking a bit about Sapphire and what, what, what, what the future
plans are. Uh, I do want to give you guys just a chance, uh, Johnny, like what's coming next for
Imperial? Is there any, uh, shout outs you want to give or, you know, any updates you want to give?
Um, yeah, I think the biggest thing, um, is that we're going to be releasing our SDK soon,
and we're starting to onboard some development teams that will be giving kind of like beta feedback.
And so if you are looking to build, um, an application using our SDK, um, right now we're
targeting sort of telegram based applications. It's just kind of like a nice controlled environment.
Um, please reach out to us. And if you're interested in learning more about the project,
we have a really active telegram and discord, um, and super interested in, um, you know, providing
more information and onboarding more members of the community as we kind of scale out our, uh,
project. And so, um, yeah, definitely look us up on our socials.
Yeah. And to follow it up, I just want to say to anyone in the audience, uh, Johnny and the Imperial
team do an amazing job at, you know, doing Twitter thread breakdowns of what they're building as well
as, you know, giving blog posts and all that. So if you want to keep up with the latest, uh, follow
the Imperial team, uh, on Twitter, uh, and Harry, just what's coming next for, uh, Oasis. What are
some things on the horizon that you might want to give some light to? Uh, well, I'd say in September,
we're going to be at, uh, DAPCON in, uh, Berlin and SmartCON in Barcelona. And I think a handful of
our team will be there. So if you're at either of the conferences, feel free to, uh, get in touch with
us on Twitter or on discord and, uh, we can meet up and, uh, talk about business or just tech or
anything at all. And, uh, but in terms of like Oasis is the platform, uh, we're looking at novel
ways of doing account abstraction of, uh, doing cross chains. So with the introduction of the ZK
precompiles and Sapphire 0.6, I think, uh, we're only starting to scratch the surface with the existing
precompiles we have. And as an addition, this is going to create a really interesting opportunity.
And, uh, we're also, uh, introducing the support for the NIST curves in Sapphire 0.6. So that's all
of the web to authentication, pass keys, uh, Yubi keys, touch ID. And, um, I, I think it creates a,
a very good starting point for a lot of different projects who are having problems with more
feasibility or, uh, you know, gas cost on Ethereum to be able to do it on Sapphire instead.
Awesome. Can't wait to see one of these sort of upgrades come out. Uh, yeah. So definitely if
you're in Barcelona or you're in Berlin, come to our booth and say hi and talk to us about Sapphire
and Opal. Uh, besides that, I just want to mention again that we are having a hackathon. So if you're a
developer, uh, feel free to join. Uh, we, we can't wait to see what you guys submit. And also we'll be
having more events like this, Twitter spaces, as well as, um, sort of community calls highlighting
some of the tech on our platform. So if you're interested in learning about Sapphire more and
Opal, uh, yeah, follow us on Twitter and keep up to date with all, all the events that we have,
we have going on. Anyway, uh, thank you so much, Johnny. Thank you so much, Harry, for coming on,
talking a bit about account abstraction and Oasis. I hope you guys have a great rest of your day.
Yeah, thanks. This is great.
Awesome.
Awesome.
