Penumbra is a fully private Proof-of-Stake (PoS) network and decentralized exchange (DEX) for the Cosmos ecosystem. Penumbra integrates privacy with PoS through a novel private delegation mechanism that provides staking derivatives, tax-efficient staking, and on-chain governance with private voting. Penumbra connects to the Cosmos ecosystem via IBC, acting as an ecosystem-wide shielded pool and allowing private transactions in any IBC-compatible asset. Users can also swap these assets using ZSwap, a private DEX supporting sealed-bid batch auctions and Uniswap-v3-style concentrated liquidity. Sealed-bid batch auctions prevent frontrunning, provide better execution, and reveal only the net flow across a pair of assets in each block, and liquidity positions are created anonymously, allowing traders to approximate their desired trading function without revealing their individual beliefs about prices.
đ Useful Links đ
âș Documentation: https://protocol.penumbra.zone
Transcript written by bolbo :)
Chjango: And we are live!
Welcome to interchain.fm, your monthly podcast about all things blockchain interoperability, defi, nfts, web3, and all of the buzzwords.
I am your host Chjango Unchained and today I'm here with Henry de Valence of pPenumbra which is a zero knowledge DEX (i.e. decentralized exchange). We'll learn all about that in the next hour or so. Welcome to the show Henry.
Henry: Thanks, it's really great to be here.
C: Yes, and you have a PhD in cryptography I believe, right?
H: No, I started a PhD and then i just dropped out.
C: So, you dropped out? Congratulations!
H: Yeah, it was actually very convenient that the the timing worked out with the the first kind of big wave of, sort of, crypto enthusiasm. In that, there was an opportunity to do a lot of similar work that I would have been doing in academia. Instead, (I work) in the crypto ecosystem which is a lot more open and dynamic. So, it just made sense.
C: Right, would you mind just giving us an overview about that? Into more details?
H: Yeah, I started off actually doing mathematics and I've also done some computer programming. This was maybe around the first few years following the Snowden leaks. So, it felt like there was like a kind of a natural fit to try to go into cryptography. Because you get to combine both very high level abstract math with very low level computer programming, which is very satisfying. Also there's this whole sort of political aspect about building systems that reflect particular values. So, that was kind of my transition towards doing cryptography and then moved from academia into the cryptocurrency industry.
I worked at a chain inc before they did a merger with Stellar. Then after that, I went to the Zcash foundation for a while. Then, right about a year ago I moved on to take some time off. I just got approved for a green card so it's like the first time that I didn't have to be tied to a job.
C: Because you're Canadian?
H: Right, exactly. Then, while i was going hiking and stuff, I was doing some thinking about what are some of the lessons learned of privacy tech that we've seen so far. What are kind of some of the next
big problems to address? Then, that turned into âwell, maybe I should do public research project, write up some notes, post them online somewhere and see what people thinkâ. That eventually grew into Penumbra. So, that's kind of the storyline.
C: Long story short?
H: Yeah
C: Was there any connection to the Snowden leaks?
H: No, that was just the kind of ambient background environment.
C: Did that lead to the motivation for building privacy tech, for you?
H: Yeah, I would say so. I mean, it wasn't like âoh this thing happened and now I suddenly care about privacyâ. But at the time, I think one of the big effects of of seeing all those documents is that. the idea of mass surveillance went from this thing that weirdo privacy activists cared about to (being) undeniable that it's a real problem. It goes from, âoh well, sure everything is being sent around unencrypted and somebody could be spying on everythingâ to âoh they actually are (being spied on)!â. So, I guess that was one of the motivators for âhey, you know this is a thing that I actually could work onâ.
C: Got it. So, for our viewers can you give us an overview of what Penumbra is? I called it a zero knowledge DEX but maybe you could go further into it.
H: Yes, so there's sort of two aspects that in the case of Penumbra actually fit really well together. The first aspect is this shielded DEX and the idea is that you want to be able to do DEX functionality like trading but you don't want that trading to be constantly revealing all the information about what everybody is doing at all times. That's the first part.
The second part is fully shielded private layer one that can act as a shielded pool for any IBC compatible chain. That part is the more foundational infrastructure where we're building the shielded DEX on top of. I think you get this nice interplay between those two things where, from the perspective of having this cross chain shielded pool, you get a lot more anonymity and privacy when you build something that people can actually use. Also, having a DEX that's integrated into that shielded pool is giving people a positive reason to actually use this thing.
Then, from looking at it from the other side of that pairing, if you say âoh, I want people to be able to do trading on some decentralized platform and I want their information to be protectedâ. If you actually think deeply about what that means then it's super hard build some private thing on top of non-private transparent infrastructure. Because the kind of fundamental idea of what privacy is control over the disclosure of information, and once you've disclosed information on some public chain you can never take that back.
If you're trying to build some private system on top of some non-private infrastructure, as the designer of that system you're constantly fighting this impossible rear guard action to undo all of the privacy losses from the base layer. So, if we want to build something that actually works, we need to have some kind of infrastructures that's private all the way down.
C: Understood. So, what can somebody do with the shielded pools function that Penumbra has? Like, assuming they want to do some cross-chain action and they're starting on another DEX, like gravity DEX or osmosis, and they want the benefits of having a privacy layer. What does that look like from a user perspective?
H: So, the way this is going to work is that Penumbra is going to be a Cosmos zone just like other Cosmos zones. Someone who has assets on any IBC-connected chain can do an IBC transfer into the Penumbra zone. When they do that transfer, as they move the funds into Penumbra, those funds are instead of being recorded in this transparent account model, like in other cosmos sdk chains, they're recorded inside of the Penumbra shielded pool that can record any kind of cross-chain asset.
The first technical component is this cross-chain shielded pool, that can record any IBC asset. So, someone can transfer funds from some other chain into Penumbra and then have them be in that shielded pool. That's cool because now you can say âoh well, I can have my $atom or my $osmo or my $huahua or whatever and store it in this shielded wayâ, but just having some tokens and having them be on the chain is not actually that useful, right? People really want to do things (with their assets). So, there's a question of âokay, what can you do?â.
(In Penumbra), you can do the the most basic thing which is like private transactions you can also do private staking. Because we're building this fully private infrastructure, our own proof of stake system also should be private because you shouldn't be forced to kind of choose between âI get to participate in governance and securing the networkâ or âI get to participate in its core value propositionâ, right? That doesn't make sense, so we have private staking and then we have the kind of sort of real core value of the zone which is the private swaps.
So we have this shielded DEX that's integrated into the consensus mechanism and there's basically two sides to this DEX that hit different sort of trade-off points for having very fine-grained control over trading versus having more privacy or less disclosure of information about some of these activity. We decided to put that onto whether someone is on the the market taker side and they're doing swaps, or whether they're on the market maker side and they're doing liquidity provision.
Starting off with the market taker side, if you want to do a swap on Penumbra, you get like really good privacy. So, all of the swaps that people submit to the chain are batched (with) all the trades on a certain trading pair in every block get batched together and then executed as a single batch transaction with a common clearing price.
That means, that first of all, people are going to get a more fair execution. (This way) you don't have issue of like somebody reordering transactions, or how do you control the ordering of the transactions in a block because everything is done in one batch. We also have privacy for those trades where the input amounts of each individual user's contribution to that batch are never revealed.
When someone submits this swap all thatâs visible to other people on the chain, who are watching mempool, transactions or whatever, is just that there's a transaction where somebody is trying to swap on this trading pair and after all of that all of those swaps are collected and committed into the block. All that is revealed in the public chain state is the total amount of that batchswap. So, each user's individual trade amount stays private forever.
Now, if you're the only person in the batch then the total batch is the same as your single trade but we think that by having more users and providing something that's useful we can keep the anonymity set large. This is really cool from the perspective of an individual trader because it actually solves some existing problems that we've seen on DEX. It also solves the future problems, right?
There's a lot of discussions and drama about things like MEV (i.e. miner extractable value) and front running. You have these graphs of the amount of value that was extracted from uniswap and in response to that you see people sort of going on two main strategies. One is âwe can't really stop this from happening but we can make it so that everybody has an equal opportunity to exploit each otherâ. It's okay, I guess, that's good but it doesn't really fix the problem. It just moves around who gets to benefit from the arbitrage. I don't want to kind of knock on that because like look if there is going to be some arbitrage opportunity in a system, it's much much better if that is open to to everyone rather than like you have to like pay this amount and then you get to do the arbitrage. (This approach) doesn't really change the fact that there's this kind of lost value, right?
The second approach, which I think is better, is trying to to eliminate the potential for front running transaction ordering by doing mempool encryption or other strategies like that. (This is) where you say âokay, well what we're going to do is we're going to encrypt all of these transactions and then we're going to pick what transactions we're going to include in the systemâ. Then once we've committed to those, we'll collectively reveal them and find out what they are. This way even though all the transactions are still visible it's not possible for someone to do this kind of front running, right? I think that's a reasonable as an incremental approach. It does prevent the problem of somebody doing like transaction reordering or front running.
However, actually if you zoom out, it's really only solving this kind of first order symptom of the problem. The the core problem is you have people who are trying to trade in some online marketplace and every marketplace is also a market in information. (Currently), the system that people are using to trade does not allow them to control the disclosure of their information. So, they can't control who can know the things that I know, that I'm trying to trade on. How can you have a functioning market like that?
I think so far you know that with MEV and front running, it's a very easy thing to make legible in a graph. We can clearly see that this is what's happening here and we can make a graph, and everybody can see how big the problem is. Whereas even if you solved that and you still had transparency for everybody's trades, you'll see these these analysis reports from various defi analytics firms where they say âwe scanned through the chain and we looked at all of the wallets that ever interacted with uniswap. We analyzed all of their trading activity and here's a comprehensive picture what each individual person was doing. Well, is that good? No.
Even if you solve the front-running problem, you still haven't made it possible for people to like trade in a way that expresses their preferences. Because they also have to do this whole game of like, âwhat am I also signaling through this?â and âcan someone see my activity?â and so on and so forth. So, where we got to is that we should actually just cut all of this out. Do the so-called âclass fixâ to this bug. So, we're not just gonna do some mitigation, we're not gonna have these different layers of stuff that would would make all of this harder to exploit. We should just completely make the whole problem go away by not revealing any information. You can't have MEV if there's no information about what's going on in the transaction.
So, that's kind of the first part of this private trading from the the user's perspective, or a market-taking user specifically. We're kind of on this trade-off of privacy versus the amount of information disclosure, and we're trying to maximize privacy. However, when you're executing a trade as part of a batch there's also some loss of control there, right? If we're going to have some slippage limits on our AMM (i.e. automated market-maker), the slippage limits are sort of batch-wide. Because otherwise you would have to know information about âoh this individual trade had this specific slippage limitâ, it's impossible for the chain to process that without knowing the information about what was in that trade.
(Meanwhile) for the other side of the the the marketplace which is liquidity provision, we aim for a trade-off where you you still have some amount of privacy but it's less kind of absolute. For the back-end part of the AMM, the mechanism that we're going to use is similar to Uniswap v3 but rather than having a kind of account model where you know we have some account and here's all the positions - and you can just open up a block explorer and look at what is this Uniswap LP's (i.e. liquidity provider) strategy - all of the liquidity positions are created anonymously out of the chain's shielded pool. They're also closed back into the the shielded pool. So, when you're looking at the state of the AMM, as part of the public chain data, what you see is: here's all the liquidity that's available on chain, here's the exact disposition of all that liquidity, and as an LP you can look at that information and decide where you want to put your liquidity but you don't know whether this position is tied to this person or that person. You just know that it exists.
So you can figure out here's my strategy for doing liquidity provision, and I'm going to implement my own market making bot and other people aren't going to be able to tell exactly what are my movements specifically. Everybody gets to see the aggregate of the market but the individual preferences of each LP are protected. I think this is quite interesting trade-off in the AMM design space where we have batch execution, and there's no ability to see what the swaps are before they're executed. There's all these features that are good for market takers because they're forcing the market makers to compete on price rather than just on some random kind of mechanical arbitrage. Meanwhile, for the market makers who are having to compete on price, there's all these tools that let you actually more effectively do all that.
(As a result), you as market makers can have an active strategy and not have someone be able to trivially clone everything that you're doing. You can put time into writing a bot that does some kind of useful arbitrage and people won't be able to see what my actions are and then copy it.
C: All right. So, that was a lot to take in but just to give people a rundown of all of that: we're saying that shielded pools is Penumbra's way of solving the front-running and potentially time-bandit attacks that are pervasive within Ethereum for example, and other account-based blockchains that tend to leak a lot of metadata.
I know that osmosis is also working on a similar solution and they're using threshold decryption. How is what you're doing with shielded pools and batch execution different or similar to that?
H: It's a similar approach but with different implications because of differences in the system design. Before I get into it, I'll just do a kind of disclaimer that although I have read about the Osmosis design and talked with them, it's not my project so whatever I say about it is just my understanding and not a kind of authoritative statement about their project.
So, both Penumbra and Osmosis are going to be using threshold decryption to protect transaction information, but the difference is that in what are you encrypting. In Osmosis, the thing that is encrypted is the entire transaction, because the architecture of Osmosis is descended from the Cosmos SDK so it's like a kind of classic Cosmos system, and that architecture is not designed around privacy. Say you have some transactions, they do stuff, people can see what the transaction is and, by encrypting the entire transaction, you can have the chain commit to what transactions are going to happen before those actions are visible. That prevents this kind of first order front-running problem, but once those transactions are decrypted everybody gets to see all of the details of all of the transactions.
The difference with Penumbra is that we have this quite different system and state model for the blockchain that's designed to be fully shielded all the time. So, we're actually not encrypting the full transaction because the transaction is already shielded. In an idealized world, you wouldn't need to do any transaction encryption because the transaction already should be shielded. What we are going to use the threshold encryption to do, is encrypt the contribution of each swap to the batch total. So, instead of having a kind of like byte-oriented encryption for transaction bodies we just have integer valued encryption that is homomorphic, so you can add up the encryptions of different values and then you get an encryption of the sum. That lets us have the validators sum up the encrypted swap amounts of every swap, that's going to be included in a batch, and then only decrypt the batch total. What that gives us, is this very strong long-term privacy property of the individual swap amounts of each user's trade never being revealed. Both of these systems are much better than the situation on like a fully transparent system like Ethereum, but the difference is that if you're only encrypting the transaction until it's committed, then you've prevented front running but you haven't prevented someone from being able to scan through everybody's account activity after the fact.
So, if you think about what is the goal of doing any of this transaction encryption at all, it's to try to prevent people from looking at the information in other people's trades and then exploiting that information. Front-running you can think of as being a very narrow time window for doing that kind of exploitation and it's the kind that's like the easiest to exploit. It's also the easiest to make a graph of âhere's all the exploitation that's happeningâ but it's not the only ways to get information on other people's trades. It may actually be useful to me to know exactly what trades you're making even if I'm not in a position to do anything about it until after you've done that. Like I might sort of see you starting to make a few trades and make some guesses or I might be able to scan through the entire history of all of the trades that your account has ever done and then build some predictive model of what your strategy is, and then move. Thatâs the difference.
Both of these are big improvements over just a fully transparent system. I would say that in the case of Osmosis, we're kind of coming from different directions towards a similar goal. Osmosis is really cool, it's a system that's real and you can use it today. It's really exciting to see them try to make it incrementally more private but I think that it's quite challenging to take a system that's designed around the assumptions of a transparent model and then make it fully private, rather than kind of starting from how do we make this thing fully private and then build something that's people can use.
C: Understood. So, the problem set that you are solving with Penumbra is sort of a super set of the problems that osmosis is solving. Which is you are sort of privacy first, instead of just solving the problem of MEV resistance.
H: Yeah, I think that's fair. I would also say that one of the things that's really interesting about trading as a use case is, it's a context where privacy has a very quantifiable near-term economic value. One of the things that we've seen with privacy projects is that: building a private system is hard. Itâs hard because you have to do all this cryptography, it's hard because you need to have quite different state models. There's a lot of difficulties with making something that's private, and it's a lot easier to just like blast everybody's information all over the internet. Because of that, I think that a lot of privacy projects have struggled because they're trying to articulate âwe're building this private infrastructure and it's really good and you should use itâ. When you're trying to articulate why should you care about privacy and the story is âwe believe in privacy because it's a fundamental human right and because you don't know maybe in like five or ten years somebody is going to be scanning all of this chain data and it'll come back to haunt youâ. (It doesnât translate into a useful product today), because itâs this kind of very nebulous future harm. For me and many of the other people who build private systems, I'm on board with that. I'm sold (with that idea) but it's in itself doesn't translate into a viable useful product.
The thing that's really interesting about trying to build a private trading system is that, you can use the trading use case where privacy has this very near-term quantifiable value. You can make your graphs of how much value has been exploited from MEV and then you can use that activity to bootstrap this long-term fundamental privacy infrastructure. So, we're actually kind of aiming to sort of unite two different use-cases for the system, and the first is what we've mainly been talking about which is this defi DEX use-case. However, as a side effect of all of those people using this system, we want it to be able to provide long-term foundational privacy infrastructure. So, rather than saying âhere's a system thatâs private, you should use it because you care about privacyâ, ask âcan you do anything with it?â
C: Right. So, you talked about homomorphic encryption and that word just takes me back to mimblewimble. How is that similar to the tech behind nimblewimble or how is it different from confidential transactions in Monero, for example? How do they compare?
H: At a technical level, our system design is an evolution of the Zcash design. So, in a system like Monero you have confidential transactions and the the transaction amounts are all hidden but it doesn't really hide, in itself, the metadata of where the value is coming from. All of that's provided through this kind of layer of mix-ins, and each transaction could have been from these other 11 or however many transactions. That provides, in a theoretical sense, a kind of statistical privacy, that's not as strong theoretically compared to the model in a system like Zcash. In Zcash, when you make a transaction, what you do is you do this giant zk-proof (i.e. zero-knowledge proof) of: I'm spending value that was previously legitimate and it could have been from any transaction that had ever happened. So, the theoretical privacy guarantees that Penumbra is going to have are much closer to the stronger kind in Zcash. Thatâs because our design is an evolution of the design of Zcash.
That said, if you look at what is the actual privacy that you get, it's not really clear to me that ⊠I'm not saying that Monero doesn't have privacy or something, and I think it's interesting to note that like there's actually a lot of organic use there. Besides, if you have some kind of theoretically perfect design for a privacy system but people don't actually use it, then the anonymity set is not very large and the theoretical guarantees might not matter that much.
As such, what we're hoping to do, by having this shielded DEX, is provide people with positive reason to actually use the system. Then use that activity to grow the anonymity set. So that you get this network effect between users as the more users of this DEX you get, the more liquidity, and the better the price is. That kind of classic cycle.
Then you also have this cycle where the more people use the system, the stronger the anonymity set grows. Because we have this Zcash style property of every transaction's anonymity set is every previous transaction (that has ever happened). Not just, you know, a few different potential mix-ins.
C: Got it. So, I want to go back to the cross-chain UX (i.e. user experience) of moving value into Penumbra and potentially out of it. You touched on the fact that accounts, like in any blockchain with an account-based model, is completely privacy leaking as opposed to a UTXO model which is in Bitcoin and Handshake, for example. In account-based model, the second you share your address, your Cosmos or Ethereum address, with somebody you've effectively doxxed yourself. So, if you wanted to preserve privacy for yourself, you basically have to create several accounts and mimic the HD-tree that is available in Bitcoin and basically create a new account for yourself, each time you send an address to another person.
The other privacy leaking thing that's pervasive in network like Cosmos especially, with all the different chains and the airdrops, is your same Cosmos address is associated to an Osmosis address, is associated to a Secret address, is associated to a Chihuahua address and so on and so forth. So, the minute I use my Cosmos address, and then I send it into Penumbra, how does that preserve my privacy?
H: Yeah, the example you gave is actually a really great way to see this. So, let's say that you're doing this thing where it's like âOh, I don't want all of my activity to be linkable to each other, so I'm going to create all of these different Cosmos addresses for each purpose, and I'm going to carefully manage: I do this stuff with this address and this other stuff with another one.â
The thing is that, even if you do all that perfectly, the whole transaction history is public for everybody. So, even if there's not a kind of trivial link of âOh, I could just plug in this Cosmos address and get all of these associated onesâ, someone like Chainalysis, or whatever, can look at all the transactions and notice that the accounts are connected to each other. So, you get this kind of obfuscation but you don't really get privacy. So, if you wanted to use one of these other transparent zones in the ecosystem, and you wanted to have different identities in different contexts, you need a way for those identities to send value to each other without being linkable.
This is actually one of the the really cool use-cases for Penumbra. In having this cross-chain shielded pool, if you have your account A on the Cosmos hub, let's say, and then you send some tokens to your Penumbra account or address, and then later you send some of those tokens to your alt identity B, also on the hub. Those transfers are not trivially linkable to each other (due to Penumbra shielded pool).
You do have to be careful because this is kind of similar dynamic to the shielded pool in Zcash. There, if you sent exactly the same amount in both of those transactions, someone could say âHey, I saw exactly this amount go in and then exactly this amount go out, and maybe I could correlate thatâ. However, basically by sending value through the Penumbra shielded pool, people have a way to have different identities on different Cosmos chains without all of those identities being linkable to each other. Whereas now, even if you go and carefully construct all of these different accounts, the fact that they're sending value to each other links them. So, you only get this very surface level obfuscation but it's still possible for someone to link those things up.
C: Okay, so that brings me to the question of: why is there a need for a privacy based or privacy first AMM? I liked the analogy that you told me before when we met at Cosmo-verse, which is like when you go climb a mountain and you end up at the top of the mountain, where do you go from there? So, can you kind of expand on that?
H: Yeah, so this is like part of a reflection on my experiences working on Zcash. Like you have this really awesome technology, and once you go through all of the effort to have your funds in this shielded pool, âGreat! We have these shielded fundsâ. However then, what do you do with them?
So, it's kind of like the analogy of climbing a mountain, itâs like you go to all this effort to get into the shielded pool and have your value be recorded in a private way. Yet, once you get to the top of this mountain, there's not actually much to do. You can look around but eventually in order to actually do anything useful with your tokens, you have to sort of be pulled back down into this transparent area.
As long as your shielded ledger is not, in itself, a site of activity, you're always going to be facing this uphill battle of trying to convince people ârecord your value in this shielded pool or whatever until you move it out to do something with itâ. It's not great as a product but it's also not great in terms of privacy because the privacy and anonymity that you're getting from this shielded system comes from actually recording the value in a shielded way.
For us (at Penumbra), we want to kind of invert this picture and have the Penumbra DEX be this center of gravity that pulls value into the shielded pool and then keeps it there. Because it's not just âOh, I've put my tokens in the shielded pool and now I get to feel happy that I have privacyâ. It should be âI have my tokens in the shielded pool and now I can use them for LP-ing and earn yieldâ, or actually trade with them or do something. Like you're giving people a positive reason to participate in the system that's not just this kind of âOh, you should definitely record your value in a private way because privacy is important to youâ.
C: By the way this podcast is pet friendly, and so if your pet wants to make a cameo appearance more than welcome.
H: Okay, this is the really horrible cat who is very loud and demanding. Yeah, in particular the door to my office is a an automatic door from her perspective. Because she just yells and then eventually the door opens or closes.
C: And then food appears. I was just going to say that sometimes, lots of times in fact, some people who've started projects have like cameoed their pets and then obviously community decides it is a good idea to NFT them and then create a new like meme coin out of them. So, maybe on the Penumbra DEX there's just going to be some $petcoin.
H: Yeah, so actually on our testnets - which is another thing, we have we have some public testnets, I don't want to artificially raise anybody's expectations, effectively this is kind of our public CI. If you go to our GitHub, there's instructions on how to use the testnet - you can make some some transactions and just send send funds back and forth. There is actually a dog token on our testnet, of an anonymous team member. Because we're a privacy preserving project so you know the exact identity of the dog is a state secret.
C: Excellent!
H: Yeah, so one other thing that I just wanted to mention too, about this use-case of using Penumbra as a shielded pool for the interchain, is the combo of being able to connect to many different zones and being able to have trading happen inside of the shielded pool. This actually makes that use-case much much more powerful than an ordinary shielded pool.
The reason for that is, so we have this multi-asset shielded pool where you can record any type of asset you want, that's cool. But if you just had a multi-asset shielded pool that can record different assets, in a sense it's not really one shielded pool, it's just one shielded pool for each asset that are kind of stacked together. So, if someone moves of $atoms in and then later moves a bunch of atoms out, or if someone moves some $osmo in and moves osmo out, those are different types of tokens. And if you just had a multi-asset shielded pool, you wouldn't have any way to have shared privacy between the different assets that are in the same shielded pool.
However, because Penumbra has a DEX that's integrated into the shielded pool, someone can move tokens of one type into Penumbra and then trade them shieldedly for tokens of some other type, and then move those out to some other account that they control. And if you think about what that means, for someone who's trying to surveil all of these cross-chain transfers, if they're trying to just correlate amounts of tokens that are moving in and out, it's not just that they have to correlate âOh, this amount of this token and look up in my database of every other transfer of that tokenâ but it's âI have to look at all of the other transfers that have ever happened and then go through and look at like all of the historical trading prices of every possible trading pairâ. This is because someone could have traded at some time in the past and you don't know what the price is. So you get this kind of combinatorial explosion of the possible movements in and out of the chain.
Within Penumbra, we have very strong kind of cryptographic privacy. As you step out of Penumbra, and are transferring between some other transparent zone, that steps down to this kind of statistical privacy. Because we can't protect you once you leave our chain. But the fact that we can do activity within our shielded pool means that the statistical privacy that we can extend to people, who are using it to do sort of shielded transfers between zones, is much much stronger than would be possible if we just were a cross-chain shielded pool.
C: So, let me see if I understand this correctly. If I just wanted to sort of obfuscate the coins that are in my account, I would send it to Penumbra. Say I would send three $atom to Penumbra and then draw three atom out, but it would have effectively been swapped out with a new set of coins.
H: So, the thing that you you would need to be careful of, is not like if you just sort of shield some value and then you unshield it. You don't get privacy immediately because someone can like look at the amounts and sort of correlate that. To continue your example, suppose you sent three $atoms in and then you swapped, say two $atoms for some amount of $regen for whatever the current price was. Then later, you sent some of that $regen back to the hub or something, and let's say you sent it to a completely different address that you generated. Someone who's trying to link up those transactions has to be able to correlate this amount that came in, and then they have to look at all of these other possible transfers out.
Therefore, if you were to just immediately move stuff in and out then you probably would not get that much privacy. Because, again, the fact that you're talking to a transparent zone that makes it quite hard to get privacy there. However, if you move stuff into Penumbra, you keep it there for a little while, you do some trading ,you move like different amounts out, that is I think probably the best that's possible when you're talking to a another transparent ledger. Also just to be clear, this isn't really something that Penumbra itself can solve on its own.
There's a fundamental limitation when you're working with a transparent chain, about what information you can disclose.
C: Is it safe to say that Penumbra has similar functionality to a coin mixer so like a coinjoin, for example in Bitcoin? Somebody could do that except it also has the additional function of being a DEX.
H: What I would say is someone could use it similarly to a mixer, to get some kind of privacy, but the the actual functionality of Penumbra is much much more sophisticated. Because with a mixer, the idea is, there's this transparent world and we're just trying to unlink stuffs. (In contrast to just creating a mixer), our goal with Penumbra is we want to have a shielded ledger that's actually useful for people to do activity on. And if someone wants to sort of use that as just a brief stopover, and effectively use it as a mixer, that should be possible. Still, our goal really is that people should be able to record their value in a shielded zone and be able to do useful things with those tokens in a shielded way. Rather than this kind of model of âI'm trying to get as much privacy as I can, before I return to the chain where everything I do is constantly doxxing myselfâ.
C: Got it. What's the attitude of Penumbra to increment additional features, such as like lending and borrowing for example. Or, does it want to externally leverage a protocol such as Umee or some other chain that lets you do that? How would that work with Penumbra?
H: Yeah. So, our initial idea is to focus on having our initial set of functionality which is: transact, stake, swap, and market-make. We want to really nail down that functionality in a private way.
What's really awesome about being part of the interchain ecosystem, is that each chain can have specialization. Because every chain can be connected with IBC. So, for us when thinking about âOh here's this other functionality that we might want to have or that people might want to haveâ or people might want to have programmability or something like that. Our approach is basically we're going to pick the things that we think that we can do really well, and we're going to do those things. Then for everything else, we have IBC for people to be able to kind of get that functionality on more specialized protocols.
In the future, I think it would be really interesting to try to explore having programmability in Penumbra. However, as a sort of hard design goal, I think everything within Penumbra should be private. I think if you start trying to say âOh we have this chain, and then if you do these things that's private, but if you do these things it's not privateâ, it's very confusing. Whereas right now, the zone boundary is the privacy boundary and that's very easy to understand.
So, I think it would be really interesting to try to figure out like what does a good privacy or private programmability story look like, and I would like to work in that direction maybe post mainnet launch. However, initially the approach is like âhere's the stuff that we're going to specialize and do really wellâ and for everything else you should use IBC to connect to somebody else's chain, where they're doing that function really well.
C: Right. So, just to wrap up on my questions: when is mainnet launch? And can you give us a high level overview about the token and tokenomics?
H: Yeah. So, mainnet launch will happen at a point in the future. So far, we have a public road map where we've laid out sort of âhere's the different phases of development that we're going to doâ and we've laid out our strategy for being able to get those things done. But we haven't fixed to a specific schedule or dates. We'd like to go as fast as possible obviously, but at the same time we also want to do it correctly.
One of the challenges with building a private system, is that a lot of the kind of complexity and correctness is kind of front-loaded. You have to really get the design right because once you've gone to mainnet, it's not that you have some chain state that you can just look at because everybody's stuff is all shielded. So, that's a bit of a challenge and we haven't committed to a specific schedule. But as we get closer to readiness, we will definitely be sharing more.
Also on the tokenomics front, that's also something that we're still working through the details of. There's a lot of complexity in making a token and you want to do that right. For now, we've been focused on trying to build something that's real. So, we have these sort of testnets that that people can play with. They're not incentivized at all but we will definitely be releasing details on the tokenomics at some point in the future. Soonâą.
C: Will there be an airdrop?
H: Probably.
C: Nice.
H: I think that the kind of the norm in the Cosmos ecosystem of these cross-chain airdrops is actually very cool. I mean, not just from the perspective of an individual person who gets an airdrop but thinking about what it means for an ecosystem. I think it's really cool that you have basically all of these different projects and you have this really vibrant community of people that end up being kind of mutualistically invested in all of these different projects. I think that's really interesting.
It definitely feels like there's a very real kind of focus on decentralization. Especially in the blockchain space, everybody talks about decentralization. Then there's the projects that like talk about it and do it. Then there's also the projects that like talk about it and then like don't do it.
I think the environment in the Cosmos ecosystem where all of these different community members end up being cross-invested in all these different projects, really builds this kind of mutualistic cooperative and collaborative spirit. That's like super super powerful and valuable and I think that's one of the actually coolest innovations of the ecosystem.
With any kind of airdrop, I'm not actually aware of any successful airdrop that wasn't some kind of retroactive thing. Because there's this incentive problem of announcing stuff and then people run off, like with the keybase thing, I think was is a kind of famous example of that.
So, at some point when we're ready, we'll have some details. As for now, we actually have been really focused on just building the technology, and having that be real, rather than doing a lot of detailed planning about the tokenomics.
C: Yep, fair enough. So, I'm going to take some final questions from the audience. Then we will wrap up.
H: Cool.
C: gaz (audience) asks: the obvious question what differentiates Penumbra from Secret network?
H: Yeah, so I would say that the the key high-level thing there is that, in Penumbra the privacy and security is based on cryptography rather than trusting a single corporation which is Intel (as Secret network uses propietary Intel SGX technology).
I would say that with Secret network, it's definitely an incremental improvement. It's better to have people using a chain that's inside of some Intel hardware rather than just like broadcasting the history of everybody's stuff forever. But if you look at the history of SGX security, even in cases where actually it wasn't being used for anything particularly valuable. I wouldn't want to base the like fundamental security properties of a system on just trusting the Intel hardware.
It's a question of trade-offs right? Because if you're okay with just trusting Intel, then there's a lot of stuff that you can do that is easier, like doing programmability inside of SGX is just like running some computer programs. If you're fine with building your entire system on trusting Intel, then that's great. Personally I wouldn't want to just trust Intel's hardware security.
C: lanra (audience) asks: in your view are there any downsides to batch execution for AMM trades compared to FFS or mempool based execution? I guess users can't be guaranteed to get best execution vis-a-vis other venues. Sorry what's FFS?
H: Off the top of my head, I don't know the acronym. Maybe the person (audience) can fill in. But I can the question about downsides to batch execution.
Yes, there are downsides to batch execution. When someone is deciding to be part of this batch, they are giving up some kind of control over exactly how their trade is going to be executed. But what I would say is, in practice I don't think that a lot of users have that kind of control anyway. If you just kind of zoom out and think about the execution model of the blockchain. You have these transactions that are doing state updates. Then, those get collected into blocks and then executed. So, from the perspective of the underlying state machine, the minimum time resolution is in some sense the block. If you build mechanisms that expose some kind of higher time resolution than the actual sort of fundamental semantics of the chain, what you're doing is creating this opportunity for mechanical arbitrage where people are racing or competing to have their transactions ordered in a certain way.
I think some people might be able to win that arms race but most people won't. So, I think for for most people, having the semantics of everybody getting the same price and if there's noise of people trading in different directions, that should kind of cancel out prior to hitting the AMM. This is actually, I think going to give a better market design to go to this kind of frequent batch auction model. But for people who do actually want to have really fine-grained control over the execution of their trades, on the LP side, our mechanism is going to be quite similar to the like Uniswap v3. With concentrated liquidity and by making a liquidity position with a very narrow range, you can kind of simulate the effect of a limit order. So, we do provide a way for people who have very particular requirements about their execution, to get those but by participating on the LP side.
C: All right. And just to close out: where can people find you, Henry. And where can people more information about Penumbra?
H: So, if you go to penumbra.zone that is our website. Thereâs a link on the top of the website to the Discord, which is at this point primarily like development focused. There's also links to our GitHub and there's links to a draft protocol spec that has all of the design details that you could ever want to know. If there's something that's not there, then like just yell at us on Siscord. We'll, you know, that'll be âOh great, we should fill in this part of the specâ. On Twitter, there's the @penumbrazone twitter account. I also am on Twitter @hdevalence. So yeah, I would say that, to find out more about the project definitely join the Discord. And yeah, happy to be in touch. You can play with our testnet if you would like.
C: All right. Excellent! Well, thank you so much Henry for coming on the show. And if you want to stay tuned for next week, we're going to have Harry Halpin from Nym joining us on the show. So, thank you to the listeners for tuning in to this podcast this week and I'll see you in the next week. Bye.
H: Thanks for having me.