Episode 222: Something Brewing with Jill Gunter and Ben Fisch from Espresso Systems

Transcript

[Music] welcome to xero knowledge i'm your host anna rose in this podcast we will be exploring the latest in zero knowledge research and the decentralized web as well as new paradigms that promise to change the way we interact and transact online this week to roone and i chat with jill gunter and ben fish from espresso systems espresso has been in stealth mode for a couple of months but recently went public with their proof-of-stake l1 developed with flexible private applications and zk roll ups in mind we

explore the founding and development of the project the espresso base chain and the cape wrapped privacy smart contract application that they've built we walk through the programming model the evolution of privacy technology what configurable or flexible privacy means and could unlock the espresso road map and more but before we start in i want to highlight that the git coin grant round 13 is on now this means donations made on their platform during this period are actually matched from matching pools your donations go a lot further if you donate now i want to highlight the zero knowledge podcast grant it's a long-standing grant on git coin as well as the zk hack grant both are in the main pool so this is a

great way to support the show and our events if you want to i've added the link in the show notes i also want to point people to the zk tech side round this is organized by the zk validator and 0x park and we've brought together a great group of matching partners from the ecosystem so there's a 275k matching pool this goes towards zk projects and if you're interested in supporting these kinds of projects or just learning about them head over to git coin grants and check out the zk tech side round something i don't usually do on the show but wanted to ask if you like the show be sure to give us a review or a like on any platform where you're listening help us share the show to groups communities or teams you think

might get something out of being in the community and yeah thanks generally for listening i'm meeting lots of new joiners right now through zk hack on our telegram channels yeah and getting to learn about all sorts of new zk projects coming online so now tanya the podcast producer will tell you a little bit about this week's sponsor today's episode is sponsored by enoma anoma is a suite of protocols that enable self-sovereign coordination their unique architecture facilitates efficiently the simplest forms of economic coordination such as two parties transferring an asset to each other as well as more sophisticated ones like an asset agnostic bartering system involving multiple parties without direct coincidence of wants or even more

complex ones such as end party collective commitments to solve multi-polar traps where an interaction can be performed with adjustable zero-knowledge privacy visit anoma.network to learn more anoma is also hiring visit heliacs.dev jobs to find out about their openings so thank you again anoma now here is anna and tyrone's interview with espresso systems [Music] so i want to welcome ben fish and jill gunter back to the show this is the first time i have you both on here together but yeah welcome back thank you anna yeah it's great to be back great to see you so i'm very much looking forward to digging into this project it has been very much in stealth for some of the

people listening this might be the first time they hear about a project that you're doing together it's also one that tarun who's also on the call tarun and i have made early investments into him through robot me through zkv but i know that a lot has changed and so for me this interview is going to be a revisit and i'm very excited to find out how it's evolved so the name has also evolved a few times since we first spoke so why don't we first start with that what is the name of this project and how did you get here the name is espresso uh or espresso systems and we had a bunch of different names that we were thinking about one of the wonderful things about being in stealth is you can you can you can change have a long time to work through

your branding and perfect it um but espresso is just a really fun name that um we all liked and it evokes kind of speed and compression and it has a lot of fun memes or puns that you can do with it related to building blockchains that are scalable there have been a lot of coffee related dad jokes basically i think what is what penny's getting at which uh we're looking forward to sharing those with the general public over the coming weeks as well very cool so espresso what did you say espresso labs no espresso espresso systems okay so espresso systems tell us a little bit about what this project is all about

what are you focused on so espresso is a single shot scaling and privacy solution for the for the blockchain ecosystem oh my god was there a pun in there oh yeah here we go all right every generation of programming language needs a coffee reference well it's a virtual espresso machine that's what we're building here right not the evm but the v-e-m um but that aside espresso is focused on both scalability and privacy which obviously we're not the only project focused on those are two of the biggest problems um in the blockchain space right now and we can get more into the details about concretely our approach to these

two different problems and what we're doing but i think that the important thing to emphasize is that espresso is a solution for existing ecosystems so we are intending it not as a standalone ecosystem but as it is an independent layer one but through bridges to the existing evm ecosystem um it's intended as a scaling and privacy solution for other blockchains including ethereum very cool let's find out a little bit about the company the team so who makes up this team espresso systems who's in it so ben is our illustrious ceo i am head of strategy which means i'm doing a lot of things on figuring out go to market uh figuring out who the user base is what they care

about uh i'm also kind of like de facto doing a lot of things on marketing and other things that i have no business doing probably but that's the nature of early stage startups and then we have a team of about 25 people uh about 16 of whom are on the engineering side those numbers might be out of date by the time this airs because we actually have a few people joining over the coming few days we are growing quickly yeah um but we've been very lucky to uh be able to amass a really amazing team on the technical side both in cryptography and in systems engineering and then also to find a few really brilliant people on the product side for working with us as

well so yeah it's it's quite the crew that we've put together even while operating in stealth and we're we're excited to uh continue to grow the team here over the next few weeks oh very cool ben when we like i think the first time we spoke at the time you were part of dan bonay's group or is any of the people who came with like have you grabbed anyone from there for this team yes well i've i've worked with charles and benedict for a long time um charles lew and benedict boone's we all met in the phd program at stanford and we've collaborated on projects both in academia and in industry um over the years you know some of those went well some of those candidly didn't go well but you

know we've certainly bonded and gained a lot of experience together over the years and so we um started this together and brought in jill um very shortly thereafter and jill and i actually met in 2017 when she was talking about fat protocols at the mit that's a throwback for you all yeah and we've always dreamed of working together yeah the timing was worked out well yeah and it also turned out that we were down similar rabbit holes in terms of the problems that we were thinking about where um i guess i spent a lot of last year in the year prior thinking well first thinking about what i really have conviction on in the crypto space which i think is an important thing for all of

us to always be revisiting and one of the things that i really started paying attention to was just why the payments use case hadn't taken off yet and i was looking at a lot of the stuff that was happening with you know circle and usdc's massive growth over the course of 2020 but looking at the utility that stablecoins was offering it still was not being applied uh in the payment space which was kind of the original satoshi dream right of peer-to-peer digital cash and i started thinking a lot about both scalability and privacy and i knew that ben was one of the sort of like research luminaries of those worlds and uh hit him up and was lucky enough to be

able to to land on the team early on cool when we first started talking about this project i felt like it was ex it was very very centered on privacy and since then i know it's evolved maybe the underlying tech hasn't evolved that much but the the positioning or the way that you're describing it have so can you tell me a little bit about that journey like where you started what you saw yourselves at as at the beginning and where you are now absolutely yeah um and the tech has evolved as well too since we're a very research and development you know heavy company so um and we're always trying to solve you know the cutting edge problems

in the space so but when we started out we were positioning ourselves as you know focusing on solving privacy problems and we knew that building a scalable infrastructure is an important feature and i think that the shift in positioning is that we actually are building a scalability solution where privacy is an important feature and that's important when we look at what users we're trying to reach we want to be relevant to users who may not care about privacy right but one of the differentiating features of our you know of our infrastructure is that it also supports privacy in in web 3 apps how did you get to that point i was just going to go

there actually anna so that was perfect um i i wanted to talk a little bit about our process and our product process specifically and also just the way that um we're trying to approach building all of what we're describing here which is you know if you look kind of historically i think at it's funny to say historically this is only like the last five years but at the layer one projects of kind of the 2016-2017-2018 vintage you know a lot of kind of the playbook revolved around uh coming up with really neat sort of theoretically interesting solution to a problem that existed with ethereum writing a white paper about it and then

going away for a period of like one to five years and building that solution and then rolling it out with you know developer tooling around it and sort of field of dreams approach if you build it they will come and uh they will hopefully build interesting applications that attract users and i think that that's worked out really really well for those really nascent sort of bleeding edge at the time projects but i think if i look around at the industry today we've actually moved on from that as an industry which is really great you know we are at a point of maturity where we do have products in crypto in web3 web3 wasn't even a term right in 2017 not pervasively used anyway but we do have

these products that are finding real traction finding real product market fit and so it's something that we've been really intentional about as we are building infrastructure layer one that we don't want to just go away and bury our heads in the sand and think okay this idea that we've come up with is really cool and we're just going to drop it on the market when it's ready in a year or so is time but rather we wanted to have a much more engaged and ongoing product process with users ranging from developers to d5dgens to nft creators to dao admins all the way up to big institutions and so we've been very intentional over the last uh several months about you know

conducting user tests and really being engaged with all of those folks to understand user needs and that's where a lot of this feedback has has come from and that's where a lot of the positioning has evolved over time and i would anticipate that it will continue to which is actually the default thing if you look at you know most silicon valley tech companies like you know they end up in very different places in terms of what the product is in terms of positioning uh from where they started and as ben mentioned like we're still very much at the starting line here and so i think to us it doesn't perhaps feel like it's evolved that much

but i it surely will continue to and you're right to point out that certainly our positioning has been informed by all of those user studies even just over these these past few months going back to what you had said ben about sort of the privacy first now it's more like uh scaling solution with privacy optional is there a trend towards just focusing on scaling that you were kind of picking up on or do you actually feel like i almost wonder if like the industry had shifted so far to scaling and i almost feel like it's walking back to privacy i don't know if you picked up on that too and so that's why i'm curious about like how you see yourselves developing from here are you going to be doing most of the work into the privacy direction

or do you see it more in the scaling would you see it more in the adoption maybe and let that define it i think one of the main reasons to focus on scaling first and then privacy as a feature is that scaling is something that everyone everyone really needs everyone needs low-cost transactions and by being a scaling solution you can attract apps and liquidity and activity onto the system and that also helps when considering privacy as a future if there's no activity on the system if there's no apps being developed then it's if there's no liquidity then it's hard for anyone who wants privacy to you know really get any use out of the system and so we can talk more

you know in more detail on what exactly espresso is it's it's going to be like a high throughput uh blockchain that has bridges token bridges to ethereum and other evm blockchains and it runs a you know high-throughput proof-of-stake consensus protocol that integrates with roll-ups but all of this is you know designed to attract you know web3 apps to be deployed on espresso and then it seamlessly integrates with some of the privacy protocols that we've developed there to enable those app developers and users to have optionality around privacy one thing that i just wanted to add there's as well anna is that you really need both to unlock these kind of holy grail use cases in web3 and crypto you need

both scaling and privacy one thing that really came through as we've been talking to potential users over the last few months is that the scaling issue is a pain point today for today's users of these applications and so i think that it's important that we are meeting that pain point in any solution that that we design that we bring to market but equally then privacy it's not actually so much of a pain point as for example scaling is for today's users because today's users all came into this all transparent all the time for the most part world and and we're clearly kind of comfortable enough to adopt these

products despite that but privacy is a huge barrier to future users future use cases and innovation and so that's one framing that's kind of informed yeah our priorities and and positioning i would say i think it would be a great moment to actually jump into what the components of the system look like how they work together and i sort of want to revisit that like how how users could then interact with privacy but espresso systems is the company but espresso is also the platform maybe let's walk through the components of this system great yeah no espresso is

is the platform is the blockchain that will have bridges to the rest of the evm ecosystem but it runs its own high throughput high-throughput proof-of-stake consensus protocol and one of the things that we've been working on really hard is how to integrate that with roll-ups to achieve better scalability without compromising on decentralization and specifically decentralized data availability roll-ups are a very popular scaling solution and technique these days and it really is the only way to scale past you know thousands of transactions per second because consensus protocols on their own just hit fundamental information information theoretic bottlenecks in

terms of how fast information can propagate through the network and so rollups are a way of compressing many transactions into a smaller size transaction which is ultimately necessary if we want to keep fees low even you know in the sense range as demand scales beyond what you're seeing on ethereum today but the challenge is and with a pitfall of a lot of existing um all really existing roll-up solutions are that they either are posting um all the raw transaction data to the consensus protocol and achieving a fairly limited amount of compression reducing certain things required for verification but not overall significantly reducing the amount of

information that needs to be propagated through the system or they're resorting to something called a data availability committee which is essentially a centralized solution to making sure that data is available to everyone in the system so that they can use that data to build transactions and so what we've been focused on is how to carefully integrate rollups with a proof of stake consensus protocol in order to get around that issue and then i can also talk about this is a lot at once so maybe we can break this up but i can also talk about our privacy protocols and how those work well actually that was my one my next question was actually cape protocol let's let's actually talk about some of these different pieces and then talk

about how they work together but yeah what is cape and this is actually where i got a bit confused so like is espresso the l1 that's the blockchain espresso is the l1 okay and cape which stands for configurable asset privacy for ethereum is a protocol that can run on any evm platform so it's not it's not only attached to espresso it could actually it's a protocol it's something that could be deployed in another place that's right it is a protocol that could be deployed in a different place although there will be certain advantages of cape running on espresso one of the caveats of running cape or really any privacy protocol on ethereum is that

transaction fees and ethereum are not private so like for example tornado cache needs a relayer to basically aggregate the transactions and submit them and that's because in order to submit an ethereum transaction you need to have an ethereum account and pay fees from it from a non-private account so there are certain there are certain advantages like that that is you know running cape directly on espresso will have but it can be deployed on any evm blockchain and in fact right now we've deployed it as a demo on ethereum's testnet rink b okay cool and is this what's being deployed has it been deployed or will it be deployed it's being deployed this week so literally as we see this as we speak so

by the time the podcast goes out it will have it ready yeah it's a little weird that we're trying to time travel into the future here or the past yeah um quick question regarding this um so so i deploy a contract on an evm chain that sort of wraps the local asset but then when i do certain function calls it goes across the bridge to espresso is that like how how does that mechanically work i guess like i said you know in terms of like user submits transaction to the cape contract and yeah yeah maybe walking through that would be yeah no uh so cape is a protocol that can run within an in evm blockchain so cape is currently demoed

on ethereum's test net but we will migrate cape the protocol to espresso when we launch the espresso blockchain um that's where it will live primarily yeah that's where it will live assets will separately can be bridged over from ethereum to espresso in the same way that they're bridged over to other you know blockchains that are interoperable with ethereum um the way that cape works is that um if you have say an erc20 within the evm on a given blockchain then you can wrap that erc20 into a cape token that will have configurable privacy features and it's up to the creator of that wrapper functionality to determine

what are those privacy features currently there are viewing policies and even freezing policies that the token wrapper can configure but in the future this in will expand to you know customized policies um using some of the other protocols that we've developed but haven't released yet so would you imagine it sort of being that like say you have a token on ethereum and you'd bridge it over to espresso you'd wrap it in cape and then use it in espresso for certain things okay i think because you're deploying on rinkubi there's this idea that like when you talk about bridging would you

actually ever think of deploying on ethereum as well and then bridging through cape can you bridge through the l through the dap basically i mean we we actually thought initially about running cape directly on ethereum the problem with running it on ethereum is twofold one um you know high fees you really need some kind of scaling solution in order to make that you know keep those fees down and make it more efficient and number two we would anyways need to run it through a relayer similar to tornado cache um because of the issue of the privacy of paying transaction fees on ethereum so given our agenda it made more sense to run cape on espresso and also we're going to be focusing on the

seamless interaction between cape assets and smart contracts or web3 apps that run on espresso we have a lot more control over that than we do on ethereum actually one quick question so this is a big debate right now in sort of the multi-chain world which is you can have a single asset that has many synthetics represented on another chain like west exists in five forms on solana or which in a lot of ways led to the wormhole hack so due to the kind of like technical fungibility between the different synthetics in within d5 protocols but then like when one gets hacked you really probably don't want them all to be viewed as equal

so when you're thinking about kind of privacy and sort of side channel attacks you know how do you think about like a single erc20 being minted in multiple synthetics on espresso or do you like enforce that being done in a single fashion or like yeah i guess how are you thinking about because i think this like proliferation of multiple representations of the same asset thing you know has already been a security issue and i'm just kind of curious if there's like extra privacy sort of side channel attacks from that because i i i haven't really thought that much about it until you just described your design so i actually i'm kind of curious if there's actually anything anything that you're thinking of with

regard to that yeah it's a good question it's a little hard to address in in very broad terms but it would help i think to think through an example so cape is particularly suitable and when developing cape we we're really targeting creators of assets like stable coins which are sort of a bridge between the traditional financial ecosystem and blockchain ecosystem because staple coins largely speaking are created by money service businesses and administrated by money service businesses they are centrally backed so you know if you think about a stablecoin issuer um you know they can be minting their stablecoin directly on cape on espresso they might have units

of that stable coin that are already minted in year c20 on you know on ethereum and if you think about the interaction where something gets locked in a contract on ethereum and then minted on espresso and then move back it's not a whole lot different from moving between different representations of the dollars between banks right right right i guess there's still sort of this question of like let's suppose there are two synthetics so i have one erc20 i meant two versions of it on espresso and then certain people when they bridge back to ethereum tend to bridge and high like actually are the quantities revealed on ethereum upon coming back like i i'm just curious

if there's like some type of like statistical thing of like i go across on one type of asset i trade in like a curve pool to the other type of asset and i come back and in that loop i sort of like leak information about my identity based on like the quantities i i sent does that make does that make sense um yeah to some degree it's not really that there exists two different types of synthetics on another blockchain it's so i would think about it like this if you if you have usdc which is really an acid type right and you have units of that you know on ethereum right or even if you have units with that with let's i think it's simpler to think about if you have units with that within an erc20 on espresso

and then we can think about how the interaction between that and cape works because moving from you know between ethereum to espresso and then from espresso to a kind of a cape wrapped asset are similar so by having multiple versions of cape wrapped usdc it doesn't really mean that you have it's really that you have different ways of encapsulating the same asset but every unit itself is when you lock a when you lock a unit of usdc in inside its erc20 contract and then create a unit of it you know within a certain form inside cape that has certain

viewing properties move it around burn it and move it back each of those units are they don't simultaneously exist within cape and then also within the original erc20 in in a completely independent and movable way there's an atomic you know dependence between them so you're getting exactly the same token back when you get out of cape basically you are yes the sort of take i got here was the idea that if you'd have multiple types of usdc that had been bridged over or rapteath or something like like it's almost like i wonder i don't know if terena if i'm correct here but it's like what if you moved usdc's from other evm compatible chains all

towards this one is that what you're thinking yeah yeah yeah so one one problem we've seen a lot on solana and avalanche is that there are multiple bridges right between ethan solana and ethan avalanche and each bridge has its own representation of the the erc and uh then basically people make curve pools or like some type of like concentrated liquidity pool that says like hey these two things should basically be equal and there's an arbitrage between them now when the solana wormhole attack happened um a thing that maybe was somewhat less reported was that soland which is the biggest lender on uh solana had an insane amount of

utilization of loans because people the the solen sort of contracts effectively said hey look the oracle price between wormhole west and synapse with or you know whatever bridge any bridge with i forget which ones were all there but there there's like a bunch of them were is basically one to one but one of them actually just like had this hack and actually you know had this mint event in theory it should not be one to one anymore so people just started adding that as collateral almost instantly it was actually amazing how fast people are doing this they added that as collateral and then started borrowing the other types of eth as it was crashing so until jump was like we're going to put the 300 million dollars in it was not you know basically people were putting in something that's

worth 10 cents on the dollar and borrowing a dollar against it and this multiple synthetic representation thing has become a big point of contention there was a there was a twitter space with press switch and sunny and they had a big argument about it again wow yeah so so it can cause both security issues but i've actually i don't think anyone's ever ever talked about the privacy issues of having these multiple synthetics because like you sort of are leaking some information about yourself if you go between multiple representations of the same like on this destination chain if you have multiple representations of the same source asset i really don't think it's fundamental to having multiple representation i mean we

have multiple representations of the dollar we have a zillion representations of the dollar you have bank of america dollars you have you have you know chase bank dollars right the issue that you're talking about is really more due to independent price oracles that are specific to a particular representation of an asset and you have like now different you have basically are i mean you're talking about forms of arbitrage i think it's more to do with that than the fact that you have multiple representations but it is it is the the interaction between these different representations and those price oracles are you asking terena if um there are issues around like the fungibility of these things that get complicated by the privacy element of it yeah yeah to some extent like like on

the espresso side right like how how do you think about that because i i i you know like i said i i can it's very clear it has these security issues because if the synthetic can never be rehypothecated due to either a bug like the wormhole attack or sort of something where you know like a mechanism that's supposed to either be a price oracle or something that yeah as an arbitrage game goes wrong right um things things happen but i'm sort of more curious like how how do you think about that the privacy side because i i don't think anyone's ever actually really well no it's a really good question and you know frankly i think that with these i mean side channel issues can be so complicated so you like you really don't

know until you think deeply about it and sometimes things you know get discovered later then you have to figure out a fix my first reaction to this is that privacy is uh more localized in the sense that let's look very concretely what it means to if you have a certain wrapped version of usdc and you're using it within cape then you're transacting it anonymously you know or privately within the pool of assets being transferred within this one you know shielded pool and so it's more of a localized property of those transactions and how those transactions are indistinguishable from one another and you know then a relationship between what's happening there and other representations of you know usdc on completely different

blockchains but that said yeah side channels can creep up in all kinds of unexpected ways so it's hard to say no like there aren't side channels that could be exploited and you always have to be vigilant about that you're giving us something to think about to ruin this is great i i mean i just i just think app developers on espresso will be having to think about this a little bit well yeah i mean i think that it goes to a great point though of just how devilishly tricky it is when you introduce privacy into the mix to design applications sound secure systems you know there's just so much more at play even this question of you know fees and and what what you're using uh for fees and i

think that one thing i'm super appreciative uh for anna and and the work that she's done in in kind of education and and so many others are now kind of picking up the mantle of in this sort of like zk universe within our little crypto sphere is um you know just getting getting developers getting entrepreneurs and everybody else up the curve on these types of questions that yeah even for us all day you know thinking about it all day long like there are always going to be things that that sneak up like this just because these playbooks have not been fully written yet i was going to say it might be useful to explain a bit more about like how cave works and the functionality of it to put a lot of what

ben was just saying in context jill you and i are so synced that was literally what i was about to say we both know how to do a podcast you can tell it's like what's the next yes sorry sorry sorry i veered us on no no it's great yeah yeah that was awesome so yeah actually i wanted to understand a little bit deeper what is happening inside cape because i i just had this thought as we talked about locking it up it has these principles i actually don't know what it does after that like do you just transfer it to other people do you trade it in cape how much can you actually do it's a transfer protocol so it doesn't it doesn't yet

um have with inside of it trading mechanisms um of course you can have off chain bartering mechanisms which you know and then support you know direct trades but it is a transfer protocol it doesn't run you know like a defy or uniswap protocols within it um yet so first of all uh you can create assets directly within cape you can also wrap assets that have been already created within an erc20 within the evm and once you have a cape asset then you can transfer it to other addresses or other users and the unique thing about cape is that every asset has certain configurable properties or what we call policies we currently support flexible viewing

policies and and a freezing policy that the asset creator can configure so for example a stablecoin issuer could decide that every public viewer should not be able to see any of the details of transactions it should be completely anonymous and and private to the general public but the stablecoin provider or designated auditor should be able to see details of transactions over certain amounts certain credential attributes of the sender and receiver addresses and that can be configured and just to put a little bit of that in in context we really designed this with specifically stable coin issuers but really asset creators of all types in mind um and so you know the flow is

that you go go into cape uh we'll have a user interface for it that will stand up here in a few weeks but um you you go into it and you can either as ben said create or wrap an asset and then the next thing that you do if you are the asset creator and not just an end user of the system is you designate exactly what ben just described in terms of who can see what about the transactions that are happening within this asset that you're creating and also uh some of these other policies that are standard to stable coin issuers so like freezing and so forth so that's that was really kind of the design principles underpinning it are there select assets that you already have in mind are you able to actually

limit what kinds of assets can come in or is it sort of free-for-all people can bring any erc20 rapid it's almost like could you whitelist any particular kinds we do not yeah we do not have control since since it is a protocol we could have control over what's supported in our user interface but we do not really control what is happening inside the protocol itself i think that this actually comes back though a little bit to roon kind of obliquely a bit to what you were talking about a few minutes ago just in terms of like these questions of of fungibility this is nothing to do with like side channels or hacks or privacy but as you were talking it did make me think of this

challenge that we're thinking through though with cape where you could theoretically have you know many many people wrapping the same type of asset over with all different configurations of privacy and these different policies right and then you get to this uh kind of state where you need to as an ecosystem and marketplace get back to having like shelling points around okay this is you know kind of the canonical most widely used most liquid version of xyz stablecoin uh within this system but that's kind of gonna be an emergent problem and and property i think of the system don't worry this is everyone's

having the same problem this is why press switch and sunny who have very different philosophies on how to tackle this where i had this very large argument the other day now i wanted was it recorded yeah yeah i hope it's recorded so i'm not sure i think you can record them i don't know if they did i but it i can like hear their two voices in my head already i feel like i'm like bummed i missed it yeah well we'll try to dig it up if we can find it we'll add it in the show notes to for our listeners to have a chance to catch it i kind of want to understand a little bit like a use case like maybe we can walk through who is using this and how like can you paint a picture of someone who

wraps it in they wrap a token in cape within cape and then they transfer it and then they potentially take it out at some point yeah just maybe walk us through one of these and who who is this person what are they doing why are they doing this yeah yeah i know there's probably many but maybe you can just help us with like all of like the user interviews and and ever all of the scenarios that we had to come up for for those are just are just coming to mind for me here but ben why yeah why don't you kick off i mean i think that we can uh continue with the stablecoin example uh since it's again it's an example of a type of asset that is typically issued by a money service business that has risk management

responsibilities and the users are well two-fold right one the user of cable would be the asset creators who are either creating these stable coins or creating versions of existing stable coins you could have you know existing stable coin issuers use cape to create basically add privacy as a feature sort of like an incognito mode to their existing assets so that their users can enjoy that privacy but while still retaining the level of visibility and control that they have on ethereum which is essential for their risk management in fact one of the things that's like unfortunate about um or perhaps fortunate but about you know privacy protocols on

on blockchains are that when something goes through a privacy protocol and then comes out of it right it's it's always labeled as having gone through that so it's very easy for the money service businesses who who run some of these d5 protocols right to decide oh we'll ban anything that has come from tornado cache and so what cape provides is a middle ground solution where you know those protocols can endorse a cape wrapped version of these assets so that users can transact it privately so it's not public revealed to everyone but it is visible at least to um you know certain auditors and and and therefore won't be banned from the from

the other d5 protocol sponsored by those auditors so this is almost like like would you picture the issuer of the stable coin as building somehow with this in mind like are they connected are they are they deploying something on top of it are they the person that like sort of dapp or user would they be providing the user interface where their users could actually use this track if they want to so just i think just to take an example you know let's say one of the big centralized money service business stable coin issuers right let's say they are looking at kind of the state of the world and the blockchain industry and where it's going and they say you

know what's going to be a really important feature for our users is privacy and maybe not sort of like monaro level privacy or you know tornado cash oriented positioning around it but just like standard financial services uh traditional tradify uh level privacy right um so like not needing a centralized system not needing the database like still on a blockchain still immutable still right cryptographically proven so let's say that they're seeing demand from big businesses of like hey we want to explore using your stablecoin to do payroll for contractors in other countries or even pay suppliers in other countries right that stablecoin issuer

might say okay hey you know we want to attract these these big sort of next generation users to or stablecoin we need a privacy solution that's going to balance our need for risk management and reporting with their need you know our potential users need for privacy from their competitors and and other actors that stable coin issuer could then come use the cape platform as as it's as it exists today i mean we'd need to have it not be on test net but you know as the user interface for example exists today they could either create a brand new version of their existing stablecoin within cape that has the parameters that

they want or they could create what we call a wrapped asset type on cape which is basically a template for any holder of that existing stablecoin to be able to wrap that erc20 coin into and that wrapped asset type or indeed that new asset that they're minting on cape would again be able to have the right parameters that they need in order to meet the needs of those users and so again they could do that all within the user interface that we're providing and those end users you know these theoretical businesses that want to pay suppliers overseas could use the interface that we're providing as their

wallet etc but as ben has highlighted a few times cape is fundamentally a protocol and so if they wanted to stand up their own interfaces around that and so forth um for their own users they could do that typically stablecoin issuers or providers are not providing a user interface to their users they're creating assets that then exist on a blockchain and we're creating a wallet right that users can use to interact with cape assets um similar to metamask you know or my ether wallet right and again i'm just gonna plug so we're gonna be putting up the ui uh here

towards the end of the month um and again it's just going to be on testnet it's a demo it's going to be on ethereum's test nut and it's not even going to be on the espresso test net which will come with all kinds of benefits as ben is flagged but um we're really really looking forward to having that be out in the world and getting asset creators and also end users to go in and play with that wallet and play with you know the mint functionality and the configurations and and so forth to get more feedback on it cool in terms of how it functions as an end consumer app and you know how asset creators and and consumers of uh you know interact with it it's not that different from a product like zk.money

right and it just gives more flexibility and control to the asset creators you know uh so that it's not just totally anonymous assets within the shielded pools on on cape there they could have certain you know visibility or free or freezing properties configured by the asset creators cool tyrone you had something you wanted to jump in on i guess uh i i'm more curious from more of the development slash product side like which feature is like when i take my erc20 i wrap in cape and i go across what are sort of the basic view and permissioning functions you're starting with i guess like you know it sounds like there are there's this

universe of different types of things but like from a token standard looking perspective like what are kind of what do you view as like the initial ones or the more fundamental ones to start with and how are you kind of thinking about the features of of that from the perspective like let's say i'm a prospective developer and i want yeah so right now in the current version of cape it's so it's somewhat limited uh because we have and this is also for technical reasons we wanted to have like one you know universal zero knowledge circuit that captures all of these so that you can't distinguish transactions by you know the type of asset that's being transferred in its policy in the future we can give more more flexibility to the creators of these assets to program their own like

arbitrary policy but right now it's really just any subset of the amounts you know receiver and sender addresses and a subset of the attributes of digital credentials associated with the sender and receivers yeah i think in future though tyrone um you know one concrete use case that we're excited about is thinking about how we might be able to support things like for example uh implementation of the travel rule here right where you know below a certain threshold reporting requirements are more relaxed and above a certain threshold of transfer amount uh reporting requirements then kick in um we actually have that as a feature

now so you can configure that you only see information about those fields that i mentioned if the amount is over yeah cool threshold value yeah that's implemented in the protocol that won't be on the ui at the outset um but that's you know again i think another example of how we've built this with really like stable coin issuers and and all manner of asset issuers in mind um and we're looking forward to continuing to kind of expand what those use cases and applications look like as we go and think about it more deeply what are the actual zero knowledge proofs what is the cape protocol using we're using planck and actually well

extensions of planck um in fact we have an open source library called jellyfish that um is already open on github and it it's based on planck but it it has certain extensions of turbo planck and other small optimizations that were enabled us to make our circuits really efficient really our constraint systems really efficient given that you have these different types of so like you can select the privacy settings does that inform what size of circuit you need or does it actually affect the zero knowledge proof or is it just like there's a standard zkp and underneath there's some like other stuff that you

can configure yeah there's one constraint system and that's important so that every transaction looks indistinguishable from another transaction the viewing policy is an input to the proof if you have different viewing policies it doesn't change the proof that's being computed just change the inputs okay if you want to enable custom policies that go beyond this then it's hard to give just one universal um you know zero knowledge constraint system to capture everything and so if you want users to be able to program their like their own constraints then you need uh this is getting very technical but you need like two levels

of recursion in order to be able to hide things and so we have um an extension of the sexy system that um is based on integra using planck is it for the for the inner proofs and uh plonks also for the outer proofs and we'll be releasing that soon um as well and and we have a paper on it that we're going to um that we're going to put out there which is basically just making a lot of optimizations to to sexy um based on planck and it has sort of like an identics improvement in the performance on um on the state of the art of that are there any other constraints uh that come with kind of merging those two and

because they both have sort of different representations of things um so i was just curious like when when like from from the perspective of like a programmer like do they have to like think in terms of writing a sexy sort of code or do they think in terms of like oh i need to like actually think of lookups and stuff like that like i'm just kind of curious like how how that works from the end user standpoint frankly like cape and the way that the cape protocol works and the way that zexi works are actually uh very similar in terms of their programming model it's all utxo based and dexi is really an extension of the utxo system where like everything is basically a cap encapsulated as a record and every

transaction basically deletes records or nullifies records and creates new records that's how cape works as well the additional thing that zexi does it within the xe protocol is that it's it's proving that it satisfies the custom creation and destruction predicates of any records that a transaction is creating or destroying and it's hiding the predicates of the records so all of this is abstracted away from the user yeah we haven't integrated dexi with cape into like an end consumer product yet so it's a little hard to say exactly you know what it's going to look like to the user in terms of how they

write a custom policy and express that using a constrained system or programming in the higher level language and then that gets compiled down to like a a plan constraint system and that entire flow like we haven't really you know completely integrated that into a consumer product but it's not that different of a programming model from the way that you know cape works itself but sexy actually has this programmable con like it you can actually program within it at least like that's what sort of alios working on and so as i understand that the espressos l1 that's where you would have smart contract type things that's where the evm compatibility lives the cape lives on top of that right as a dapp as a

protocol but would you then have programmability with and and i'm guessing like cape is programmed but it's sort of pre-programmed and then users can interface they can choose their settings but yeah like do you actually also expect people to build again on top of cape like would you want them to be able to program on that sort of third level up yeah that's a really good question so the way that sexy enables programmability is that you know it allows users to basically create these rules for how you know records can get created or destroyed and that can determine a certain you know type of application but sexy is still quite limited in terms of

um how it can achieve you know programmable privacy in web3 apps it's really only handling off-chain computation if you really if you want to retain the privacy features that it enables zx would not allow you to build a privacy preserving version of any type of smart contract that requires public data also there can be fundamental limitations of that because the data needs to be public right so sexy doesn't allow you to build like private uniswap also private new swap is not really possible unless you change the definition of how it works so there are limitations of that but what it is really good for is

user-defined assets that have customized rules in terms of how they work so you can imagine that every asset has a different zero-knowledge proof constraint that needs to be satisfied by the transaction and you want the transaction to hide what the asset is and what the what is the circuit that you're proving is satisfied so that you can't distinguish transactions by you know their their types that's what zexi is very good for obviously it's more flexible than that but we're still trying to figure out how it will again like integrate into a developer platform and how users will want to use it because it's not really clear what developers can do with sexy in like a meaningful way around the

uh around programmable privacy that's like a very high level concept that i know is tossed around in the industry but when you get down to the gory details of how things work it's not obvious uh what programmable privacy means okay so i want to go back to the espresso layer i think we've we've done kind of a cool dive into cape sit that sits on top of espresso but like so espresso is in l1 do you actually do you have other protocols also planned that are separate from cape do you picture like multiple privacy protocols interacting with that l1 or do you picture cape as the primary like are you kind of delivering sort of this both both together and that's that makes up the entire system yeah the two the two

privacy protocols that we worked on were one cape and then to this you know newer version of zxe which we call very sexy for verifiable sexy because it's unified he uses uni universes you have an acronym very nice but that was the sound of 500 sighs no that was just [Laughter] um and and those are the two privacy protocols that we have and we do not have any other protocols planned it's a lot already on [Laughter] but yeah a lot of our focus right now is

on the espresso layer one and how it works in terms of its integration of roll up and consensus and how it achieves higher throughput without compromising on data availability okay cool and i think that's what i want to explore now is like let's go back to that point now that we understand a little bit more about what's living on top of it like do first of all like it's evm compatible right it's that's the part that's evm compatible how are you doing that is it like a fork of death are you doing something that compiles down into something else but like you can deploy solidity code on it so we're actually developing a zika vm so we are building a rollup directly for the evm

we're translating evm opcodes um you know two constraints and um so that's one exciting thing that we've been working on um just like an inefficient implementation of zke evm which zk evm by the way are you like following which camp because there's a few different projects like working on that i know hermes has one ef is working on something like this do you have your a unique one scroll scroll yeah so it would be a lot more similar to what so i would say that the the different approaches roughly break down into two different categories one is build your own custom vm and then have a com you know compilation from the evm to that vm and then the other approach is to try to

directly build a constraint system that captures the evm as closely as possible and yeah i don't want to butcher what other projects are doing specifically so those are just the two broad categories and we are in the latter category so we are building a constraint system that directly captures evm state transitions and yeah we're working on using our turbo you know plonk constraint system and the various optimizations that we've made to try to make that efficient although i would say that while it's good to make small efficiency um optimizations in the representation of the evm i think that with the trend in the industry towards having just hot really high performance approvers i'm

sure you're aware of um z prize and this you know industry i think you're participating in that right so there's an industry initiative to have um you know high performance approvers and there's also a lot of startups already that are working on doing that it's a it's less important to have these small differences in in in how the constraint system works when you can run roll-up servers like on a very high performance platform which is different for roll-up and privacy where privacy requires you know consumers to produce these zero-knowledge proofs like on a phone or on a laptop yeah um so that's just something to note that betting on really high performance approvers and the fact that the

computational cost of producing roll-up proofs per transaction is still just so so much smaller than the costs that are currently due to like gas fees due to congestion on blockchains um that it's not as significant to care about these small differences in the efficiency of the prover which is why we're focusing a lot on how rollup integrates with consensus to you know achieve higher throughput but while preserving the decentralization of the system which is so core interesting so the espresso being the l1 that is actually where the zk evm works here that's that's where that lives the zika evm yes is a component of the espresso consensus protocol

and the protocol itself um i mean the the provers are a separate logical component so like the the the servers that are computing these roll-up proofs do not need to be consensus nodes themselves but would be sending proofs and data to consensus nodes but the the way that this integrates with consensus is exactly in who gets to verify proofs and who actually has to receive data and basically sign to say that they've received data and then conserve data to other nodes or users so i want to kind of see cape is deployed on the ckevm it is it like those proofs are they being

generated within cape town is a higher level application okay so where like but okay i keep thinking of i keep thinking of roll-up models where you have like you have smart contracts that do the verification of the proofs so in the case of cape or is it cape is deployed is a smart contract deployed on espresso that's actually doing the verification of the proofs that underlie the cape protocol or yeah i think let's like let's take a look a step back i think that it gets confusing with like all like these terms being thrown around in the industry like roll ups or consensus or this or that or the other cape is at the application layer right transaction processing itself right that's at like the layer one level right

and so um when you have roll-ups roll-ups are you should really think about roll-ups and consensus as just combine defining a new consensus protocol right a consensus protocol is just a transaction processing system that has um you know some way of ordering transactions and then different consensus protocols you know ranging from a centralized system to you know a decentralized system of different types right are having different security properties of what guarantees you have around consistency and and liveness um and data availability so when we talk about the roll-up and the consensus and espresso like this is all describing just this abstract transaction processing system it has nothing to do with the the

application layer at the application layer is the fact that you can run protocols like cape and then you can run you can run evm transactions evm is is uh is you know it's a virtual machine it's a way of describing what you know logical transactions can be processed by the system sorry and i'll tell you where my mix-up comes in because i because i often am talking to zk roll up projects and recently like one project mentioned that like the zika roll up what it looks like it's just it looks like a dap and that has like kind of like thrown me for a loop that yeah verification smart contracts just look like you can't have right because you can have roll-ups run just through a

smart contract which gets kind of trippy right so you can actually have a boost trapped on top of the consensus so you can actually have a roll-up that just looks like it's just run by a smart contract and that's actually the core of the problem that because um roll ups are somewhat of an afterthought as a way to you know scale throughput and there isn't this careful integration of roll up with with with the underlying consensus protocol you end up in a situation where either you're posting way too much data on chains still and therefore you're limited in terms of how much you can scale or you have a half-hearted association to data availability and so we want to make sure that we're looking

at it as an integrated design with certain security goals right we want to maintain that if the you know two-thirds of the stake is you know honest or incentivized right however you think about that then you maintain these properties of consistency liveness and data availability and then that's the security property want to prove of the overall system including how roll-ups interact with consensus as part of the protocol on the data availability side though like is is the model then the underlying model is it similar to these other data availability solutions like are you thinking about it in the kind of context of like celestia or is it very very different because what's built on top has different needs

based on my understanding of celestia it's very different than celestia is based on basically proofs of retrievability and it could in you know retrospect look somewhat similar to different ways of having data availability committees but to give you a peek into how it works we have a proof of state consensus protocol which is based on you know randomized committee elections which is how some of these proof of state consensus protocols work so concretely we have integrated um the hot stuff consensus protocol with a randomized sortition-based proof-of-stake protocol kind of similar to algorand so it's you can think of it as algorand but with hot stuff as the internal bft as opposed to

the bft that algorand uses and the way that we integrate rollups is in terms of how committees get randomly elected to actually receive and then serve the raw transaction data versus how committees get elected to just participate in voting on transaction ordering and at a very high level the reason why it is possible to scale throughput and still achieve decentralized data availability is that you do not need to elect as large of a committee to basically function as the data availability committee as you do to participate in voting and the reason is that when you

sample a random committee you need two-thirds plus epsilon of that committee to be honest in order to maintain safety but as long as one of a random committee member is honest uh then you preserve data availability right and there's other subtleties as well such as the fact that due to the possibility of an adversary to adaptively corrupt a committee after it becomes known you actually need to broadcast blocks that are being voted on to through gossip to everyone in the network before the committee becomes known because otherwise an adversary could could basically bribe or corrupt those committees and then basically get control of their keys and and mess up

with uh with the safety of the system whereas that's not uh the same concern with data availability so uh that's getting a little bit too much into weeds and we do have a white paper that we're writing on this and we'll be publishing soon but in a nutshell it it really comes down to a careful look at how rollups interact with a particular consensus protocol and a careful analysis of the of the desired security properties that you want in order to be able to achieve this i will say one thing which is that there is some similarity with celestia here and that data availability sampling still does sort of like here coupling consensus with a proof of kind of like retrievability

but the idea that you randomly select uh some subset of validators to provide the set of transactions in like some non-corruptible way and like making sure that they don't get revealed until after is actually quite similar so i'm excited for the paper because there's there's definitely some overlap and now that there's three main data availability things going on right now uh like eth2 celestia and this it'll be interesting to compare polygon has one too by the way oh yeah sorry i forgot but i think polygon is very similar to celestia actually two is trying to do one thing that's quite different yeah in like how they do the sampling they told me it was somewhat different but there's an episode that

i think came out last week as of now a few weeks before this episode protocols are somewhat similar at a high level and quite different when you look at the underlying details um yeah the unfortunate thing is there's only one actual sort of fully fleshed out data availability paper that exists which is the celestial one so everything else is kind of like a very like the eth2 and e2 on in particular is like very like hazy like a lot of the details are not there for instance so like you can't really compare them because they haven't written anything up yeah and we'll have a paper out soon that explains what we're doing and how it distinguishes from what celestia is doing

cool do you imagine other projects deploying on espresso itself or do you actually see it as like a fully fleshed out system with both sides with like the underlying l1 and cape and that users are supposed to more like deploy on both of those or kind of work in that system i think fundamentally espresso is it is a layer one right and so we view it very much as that open platform and we hope that people will yeah transport apps that exist on other chains onto espresso that people will use it as an open platform for innovation in all kinds of new ways that haven't been possible to date but at the

same time we're also aware that again to go back to just the state of the industry and how much it's matured and how far it's come it's not good enough i think anymore to just put that out there and uh and say yes come one come all and and build something here we wanted to make sure that we were seating it um with functionality and designing it with intentionality around what those types of things will be and so that's a bit of context as to how we came up with this architecture at the outset and cape both as a protocol and something of an end-user product at the outset but certainly we hope that it goes well past even our wildest dreams

cool well on that note i want to say thank you to both of you for coming on the show thank you so much it's a pleasure to be here yes and thanks for sharing with us espresso it sees the light of day i'm very i'm very excited to be able to also talk a little bit more openly about it um and now share this episode where we got to explore it thanks so much yeah great thanks it was great great great chat about this and actually getting getting things out in the open definitely i want to say thank you to the podcast producer tanya the podcast editor henrik and to our listeners thanks for listening