**A** (0:05):
Cool. Hey guys, My name is Sunny Agarwal, one of the co founders of Sitka, and I am giving a talk on beating front running with threshold decryption and other Tendermint shenanigans. Before I start, I think one thing maybe I want to answer to the community is where have I been? As many people know, I left AIB back in July or August and what have I been doing since then? I took like a short hiatus from crypto for a bit. My main job at AIB anyways was shit posting on Twitter. So I built a bot to disintermediate myself. And then after that I started working on some random education stuff, some web of trust stuff. But the problem is crypto, once you're in it, it will always keep dragging you back in. So I decided, you know what, I called Dave and I was like, hey, let's build Sika into something. And so we're still running our valid and so we both decided to go full time on it. And so we're both building, continuing running our validators. We just started on Akash this month and so check that out. But Dave and I, we are like protocol designers at heart. And so we're like, how do we. Let's start building some cool stuff. And so we're working on a couple of different protocol projects, helping with open source cosmos development. But the main flagship project that we're working on now is how to beat censorship and front running, then using a number of different tools that we're coming up with. But the big one is threshold decryption and then other cool changes to Tendermint. This is a bit of an agenda of the talk today. We're going to first go into answering what is mev? And then we'll talk about what is front running and other types of ordering attacks. Why privacy in the mempool is the best way to solve it, why threshold decryption is the best way to get privacy in the mempool. And then other tenderman shenanigans you can do in order to make sure you truly hammer out the last any vestige of MEV left in the system. So what is mev? Minor extractable value. So the term minor extractable value is not that great. It really should be proposer extractable value. But you know, Phil, who came up with the term agrees. So you know, it's the value that a proposer can do. What, what are the powers that a single block proposer can do that they don't need some quorum of like voting power. You don't need 33% or 51% or 67% to do these attacks. If you are the proposer of the next block, these are certain powers that you have that you can exploit to extract value from the system. You can read transactions from the mempool, you can choose which transactions get included. You can choose the order of transactions that are included. You can mess with the timestamps of the block proposal. This is like time jacking and stuff. And you can censor other validators votes. One nice thing is with Tendermint, with our BFT time, we actually highly solve that one which is great. And then this one is consensus vote. Censorship is kind of really hard. We're going to ignore that one from now. It is a big problem that should be solved but it's out of scope for our solution today. So we're going to really focus on these three powers and what are the things you can do with them and the types of attacks you can do with them. I'll put them into two broad categories. Censorship attacks and ordering attacks. Censorship with an asterisk is like other types of censorship you could do by looking at the P2P layer and stuff, but really censorship based off of a transactions data. And you can choose ordering attacks. I think people generally have a good intuitive sense of what a censorship attack is. But what is an ordering attack? So let's talk into the most basic type of ordering attack which might be what people are familiar with finance like you know what a front running would be if let's say you go tell your broker that like hey, I want to buy a million shares of company X and then the broker what they would do is like they know that your buying of the shares is going to push up the price. So they would insert their own buying of the shares in front of you and then the put yours in so the price goes up and then they could sell right after you and basically you know, profit off of your thing. And this is bad for you because you're getting worse price when your buy actually has to change the broker's order hit first and that gives you worse pricing. So if you think about it, that's basically what's happening with validators as well. When Alice sends her transaction to the block proposer, the block proposer gets to choose the the order of transactions. So you know, they could get a lot of transactions in their mempool but they can add their own transaction to the mempool based off of knowledge of Alice's transaction. And when it's time to make the block, they can choose and guarantee that their block will always be the first one. And so they can sort of front run Alice in this way and you know, then get all the other validators to come in on it. The other validators don't really have that much choice in like agreeing on it or not. You know, according to the tenement protocol, as long as it meets some basic validity rules, they should be pre committing on it. On top of that. Oh, and you know, there are some other solutions that people come up with. You know, there's signed receipts, like oh, the proposal will send you signed receipts. But you know, this is, has a pretty high trust model in the proposer. And that's kind of our entire point of solving MEV is to like deal with like a malicious proposer, the or the MEV auctions. This is not really a solution. This is saying, hey, this bad thing exists, well let's try to put an auction on it rather than actually trying to stop it. Batch executions is actually an interesting one because it is a good medium level solution that works in very specific cases, but it's not a generalized solution that works in all cases. Even in those specific cases there are issues with it that maybe you can figure out by the time we get through this presentation. So on top of ordering attacks, we actually have another type of attack that you can do based off of the ability to read other people's transaction data. And this is called a dark forest attack. The term dark forest attack is off of the. It's a term that came out of this blog post that Dan Robinson and Georgiost wrote a couple months ago. But essentially how it works is imagine there's an on chain puzzle that says whoever can show the solution to the puzzle will get $5. So you know, Alice will go ahead and you know, she's very smart. She has an idea and figures out the solution to the puzzle. She sends her transaction with the solution to Sika, which is the proposer here. And Sika can just go ahead be an evil proposer. And you know, you know, because Sika clearly is evil, it can just look at Alice's solution, make its own transaction, but just copying Alice's solution into its own solution. And then when it makes the block, it can guarantee that its transaction will always be the first one in the block. So these are the two tasks you can do when you're based off of other transaction data. So how do we solve them? Well, the solution is encrypted transactions. Encrypted transactions are basically in the Abstract sense. What we want is a way that ALICE can send an encrypted transaction that is unreadable to the block proposer. The block proposer in the mempool, it can have all the transactions will be encrypted. It can produce a block with all the encrypted transactions and then all the validators will come to consensus, commit the block, finalize the block and then somehow some sort of magic will happen that will cause the transactions to get decrypted and executed. By the time it's decrypted, it's too late. The block has already been finalized along with the ordering of the transactions. Question is, how does the magic work? What is the process of this magic happening? I'd say there's three ways that I know of how to do that magic. It's trusted hardware, time lock encryption and threshold encryption. We're going to go ahead and evaluate these on this different trade off space and decide what's the pros and cons of each of them. Let's start with the first one, trusted hardware. How trusted hardware works is you basically have a block that happens. You go ahead, send the block to everyone, it gets committed and, and then the intel of the CEO of Intel comes in, does some sort of weird black magic and somehow the blocks get decrypted. How the black magic works I don't think I know. I don't know if anyone really knows. I don't know if intel really knows, but somehow it works. What are the cons of this? Well you know, first off, what are the pros of this? It's very easy to be added in as an opt in feature. So any mining pool or any block proposer today in, in a tendermint chain can basically build their own SGX solution and start offering this on an existing blockchain, which is really nice. And they could offer this as a feature like hey, if you want private transactions, send your transaction to our mining pool or our validator. What are the cons though? One that you have to sort of trust intel and stuff but there's also just not a great security trade off here. You know if you, if you follow like this the developments in like trusted hardware, there's basically like a, a major bug in SGX like every couple of months and it's like, you know, if you really wanted to break the security of SGX right now, you can go hire like 10 of the top notch like security engineers and you know, pay them for a year and you'll probably find a way to break the sgx, because it's just such an, it's not like some sort of unlike cryptography where it's like, oh, we have proofs explaining why this is valid. It's like, you know, we trust intel, they know kind of what they're doing. So you know the problem. So. Oh yeah. So the sgx, you know, you have, what's nice is you have very little execution delay. You have very, it has very negligible impact on consensus. There's not many protocol chains required. But the big con is it's not that much security. So let's go into the second solution. Time lock encryption. How does time lock encryption work? Time lock encryption is a cool cryptography technique where what you can do is you have an encrypted transaction and then you can start doing some process on this transaction that takes a estimatable amount of time. And once that amount of time is complete, then the transaction magically gets decrypted. How do we use this to help solve front running? What we would do is Alice will go ahead and send her transaction to the mempool of a proposer. The proposer can't read the transactions. They will go ahead and add it to a block. Meanwhile, the validators will start to take the encrypted portion of her transaction and start beginning the process to decrypt it. And then in the meantime, more blocks will go by. And then once the transactions are decrypted, we can go ahead and get the decrypted data and Sika can then go ahead and add it into a transaction and submit it to the chain. And so now the decrypted data is on chain, but the key is it's executed in the order of the that the encrypted version was added to the chain. This actually does have some problems though. One, there's a noticeable delay for the transaction execution because you can't have it. So as you see, there's going to have to be many blocks that go past before the transaction can be executed. It can't be done on the scale of seconds. Realistically, your execution delay will have to be on the scale of minutes to be like even reasonably secure. On top of this, there's a caveat that all transactions need to do time locking encryption, because what happens if. So at this process, Sika finishes decrypting Alice's transaction. And we said that Sicker is the one that has to submit it, Right? But what happens if, you know, Sika puts it its own transaction that can profit off of Alice's encrypted transaction. How do we prevent this from happening? We basically have to require that all transactions use the execution delay, which is really not great ux. Finally, it still doesn't provide the greatest security because especially if there's a hardware issue where some people, basically they have to be ASICs designed for this decrypting process. But if some validators or entities have put resources into building a better ASIC that can decrypt faster than everyone else, they could probably get an edge on making transactions that take advantage of this. Given all these cons, how are we doing on the trade offs here? The security is definitely better than the sgx, but it's not perfect. The execution delay is quite high and doesn't have a big impact on consensus time. But the big con, like I said, not great UX because everyone has to use it. Okay, so let's talk about the solution that we personally think is the way to go. Threshold encryption. How does it work? Well, first let's think about how does Tendermint work? Tendermint, we have this block proposal. All the validators have the proposal. What they do is they all go ahead and create a vote and they send it to the next proposer or really they send it to everyone. But for simplicity purposes we'll say they send it to the next proposer and then you can use these votes to create to finalize the block and then you put the lock on it. So how does threshold encryption work? Well, we can use this concept called threshold encryption where similar to threshold cryptography where many, you can have like many people come together to create a. You can have a group of three and any two of them can come together to create the same resulting signature. Here you could have the same thing. You could have 100 validators and any 2/3 of them can come together to produce a. To be able to decrypt all the transactions in a block and it can be any 2/3 of them. So what will happen is you. We have a block proposal that's propagated to all the block proposals, but all the transactions are encrypted. Then what would happen is each validator would create along with their consensus vote, they would also include a decryption share and send it to the next to all the other validators. Once you have all the votes and all the decryption shares, what you will do is you'll first use the votes to go ahead and lock all the transactions and finalize it. This is taking advantage of the vote extensions process that Dave mentioned in the Previous talk. It actually takes advantage of all the methods that Dave mentioned in the previous talk. But that's where you can imagine that this decryption share is attached. It's literally part of the pre commit. You can't send your pre commit without having a decryption share as well. Then once we have all these decryption shares, we can use them to do magic and cryptography magic. So this is like understood magic now, unlike the dark magic of intel sgx. And we can use it to decrypt all the transactions. We look at this trade off summary, it has really good security, almost basically equivalent to the security of your blockchain consensus itself. Its execution delay is quite low. It's only one block delay. But Tendermint already does one block pipelining anyways. And then you have a slight increase on the consensus just because now you have additional data that you have to include in your pre commit. So there's going to be a slight bandwidth hit, but it's not going to be that bad. One of the main cons here though is it really only works well in classical bft. You know, it's really hard to think about. Or you need some system in which all where many participants get to, you know, participate before a block is finalized. And that means it doesn't really work in Nakamoto consensus, which includes things like, you know, ETH 2.0, Casper design and stuff. And so, you know, on one hand you can think like oh, that kind of sucks because like that means it's not that useful. But on the other hand you can be happy because it's just more proof that Tendermint is like the greatest thing ever. And you can use Tendermint on all sorts of things. Cosmos chains, roll up chains. Tendermint is the way to go. There's one weird thing that we had to solve before we could be certain of the solution. It's an interesting problem that I think is just interesting and we want to share it. You get this problem where Alice basically what she wants to do is send an encrypted transaction. How it works is, is the encrypted part is actually a full self contained executable transaction and then it's wrapped in an unencrypted fee payment transaction that just is making sure that the transaction has sufficient fees and it has to declare what its gas limit is. So that way we need to have the amount of gas being used in clear text. Otherwise we blocks would become overfilled and we would never be able to execute anything. But then what's the issue here. What happens if Sika sees this and goes ahead and realizes, hey, let me take the encrypted part and throw out the decrypted fee payment and wrap it in my own, but I'm only going to pay 50 gas, then what's going to happen? It's going to go to the chain, it's going to get decrypted and it's going to say, hey, this transaction required 200,000 gas, you only provide 50 gas, it's going to fail to execute. But because of this, SECA gets to see Alice's decrypted data and that's not good. So how do we solve this? Well, we have this solution where we can guarant so this required sort of the invention of some new the threshold encrypt. The, you know, the standard special encryption paper that everyone refers to doesn't really have a solution to like or basically we have a way of making sure that you have some data that's in the encrypted part and in the clear text and that they are exactly the same. So that way if Alice's encrypted data internally said, hey, this transaction requires 200,000 but it gets sent in a transaction requirement wrapper transaction that says it only requires 50, we can reject it right then and there because we know that something is incorrect about this. And this way there's no way for Sika to cause our thing to be decryptable without being executable. How do we do the cryptography of this? I don't know, I'm not a cryptographer. You got to go ask my co founder Dave because he knows how this all works. So and then you know, there's also other things where you know, some of this stuff around all the, you know, there could be leaked information just based off the fact that like, you know, you can see the fee payer, you can see how much gas is being used, you can see the size of the transaction. And I think all of this stuff can be solved with like, you know, further privacy processes like you know, zero knowledge pools and stuff. But like what's cool is if you wanted front running resistance, you don't need to build an entire complex zero knowledge system where all state execution happens in zero knowledge. You can build something as simple as zcash and use that with this solution and get like, you can hide everything about a transaction and nothing will be known, which is really nice. So great. We've basically solved all the attacks that can be done by this solves all the attacks like we've done because based off of reading someone else's transaction data. Okay, but the problem is there's still two more powers that we haven't solved yet, which is controlling inclusion of transactions and reordering transactions. So let's talk about reordering transactions. This is going to bring us into this attack, what we call a blind front running attack. What does that mean? Let's say there's another puzzle on the chain where it basically says, hey, hey, the first person who can answer two plus two gets five bucks. Well you know Alice, because of our threshold encryption, all of the everyone else's solutions are all encrypted. So Sika can't copy the solutions. But you know, we're not that dumb. You know like we're learning, but you're not that dumb. We know the answer is four and we can add our transaction in the thing, but because we have the ability to choose the order of transactions, we can guarantee that we will always be the first one in the transaction. And so that $5 is going to be ours. And this whole like two plus two is meant to be like a joke thing, but you can imagine it's an obvious arbitrage opportunity, right? And this happens all the time on Ethereum. And if you can guarantee you're the first one on chain, you can always be the one to exploit it and get that mev. So how are we going to solve this? This is what we're going to solve. We're going to use a technique called order randomization. So very simple. All we do is we have all the, we've come to consensus on all the encrypted blocks, the block with all the encrypted transactions, we go ahead and do our magic to decrypt them and then we use some source of on chain randomness. So you can use, you know, VRFs, VDFs, blah blah, blah. But you know what's really nice is because all of the transactions that we had were encrypted, what we can just do is just take a hash of all the transactions once they are public and then use that as our randomness source. What we can do is use that randomness to just tornado around and reorder all the transactions. Now Sika has no way of guaranteeing the order of transactions. They just got to choose which transactions go on a block but not what order they are. Great, we solve line front running. Well no, not quite yet because we got rid of the ability to reorder transactions in the block proposal. But we haven't solved the ability to control inclusions of transactions in the block proposal. Imagine this. What we have is all these. Everyone has their solution to the puzzle and Sika has its own solution. And it cannot guarantee it's the first one in the block. But the thing is, it actually can. It, it can just make a block with only its own transaction in it. And however much reordering you do, our transaction is still always going to be the first transaction in the block. So how do we solve this? We propose a solution called joint proposals. How joint proposals work. And this is going to be really crazy because what's going to happen is using the vote extensions feature that was, you know, Dave introduced in the previous presentation and you know, we're also using it for threshold encryption shares. We can also include each validator can also include some transactions in their pre commit from the previous block. What this means is you could say, hey, this block can have up to 300 transactions. We have 100 validators. Each one is allowed to submit three transactions from its mempool. And some of them obviously will be repeats. But that's okay. Like, you know, at least that gets a lot more transactions into the chain and guarantees that, you know. So essentially what happened is each validator would include a couple of transactions along with their pre commit for the previous block. Well, we're going to use all the votes from the previous block, even if I, even if the proposer is malicious and decides to censor one of them. We can use all the pre commits from the we can commit on the previous block. But now we're left with. But in order to create the commit, the proposer had to acknowledge the existence of these transactions when it designs its proposal. It will be required to at minimum include the transactions that were told for it to be included by the other validators. This way SIKA can no longer guarantee that it's the only transaction in a block anymore. Once great, we basically solved all of these censorship, all of these proposer powers obviously, other than the consensus vote censorship, but. And what's interesting is if you think about it, how we did all of them is we actually shifted the power from being in the hands of a proposer to being in the hands of some quorum of validator. So that's what BFT time does, right? BFD time says, hey, the proposer doesn't get to choose the timestamp. So some quorum of all validators chooses the timestamp. Well, we did the same thing, you know, the proposer doesn't get to read the transactions, you need the agreement of some 2/3 of validators to be able to read the transaction. Same with controlling inclusion joint proposals makes it so 2/3 of validators have to be the proposer. Like everyone, 2/3 of validators are kind of partially doing the job of being a proposer. And so by eliminating these for powers, we basically solve all these classes of ordering attacks and massively, massively, massively reduce the amount of MEV that could be extracted from both ordering attacks and censorship attacks. So yeah, thank you guys so much and I hope that made sense. I have about five minutes for questions, so I'll just start taking them from the questions box because I don't have the ability to read through this giant chat box. Is there a link to this issue pr? Sorry, I don't know which issue PR you were talking about. So. But yeah, so I don't know which issue. For the all the ABCI stuff, there's a lot of issues and stuff that are available. There's no issue or PR for threshold decryption. This is something that SIKA is actively in the process of building right now. Does the threshold encryption efficiently support weighted voting powers? Are the shares constant size regardless of voting power? No, it does not efficiently support weighted voting powers and each share is constant size. This is why one of the things that we're doing is implementing a new version of the Cosmos SDK staking module that is really focused on being constant weight validators. But it's not going to be. But one annoying thing is on Polkadot and honestly most proof of stake chains they also try to have constant size. But if you want to run multiple, you have to still run. You have to declare multiple on chain validators and your delegators have to balance across your different validator entities. The way we're designing our staking module is as a validator we still only have to run one validator node and have one on chain validator. But the weights are not going to be as specific as the exact number of tokens we have. It's going to be atomized to be. There'll be a total of 1000 shares and then we're going to be weighted based off of that, but it's still going to be weighted off of delegation, just less discreetly. Does the threshold encryption efficiently support Same question. How can you vote on a block without being able to validate it? Since all transactions on the block because basically you're voting on. Currently we're already voting on a block without validating it. This is what Dave mentioned in the previous presentation that because of the lack of any process proposal thing right now the state machine can't verify any validity about the data of a block before it decides to vote on it. So it's not really that big of an issue. You can still verify stuff about the header and you know, making sure it's from a valid proposer and all sorts of things like that. And you can, you know, you can verify that all the signatures are still correct and there's a lot of stuff you can still verify. What happens if a transaction is found to be invalid after decryption has already been included? Encrypted form in the block. I mean, you just, yeah, there you just ignore that. You don't execute the block. So if the encrypted part turns out to be garbage, then it's fine. I mean, they still paid the fee for the decryption. That's why the fee payment has to be the wrapper. Fee payment has to be unencrypted because we have to make sure they're at least paying the minimum amount that's paying for the decryption process to happen. And then if we don't get to execute the transaction, I mean, they're lost. They just wasted fees on getting their transaction decrypted. Would this require a MPC key generation sharing in the first place? Yes, it would. And this is something we're also working on right now. We're trying to pick up some of the work that was started by the Core STAR team a couple months ago. I'm not sure what, they haven't quite finished it yet, but they've done a lot of good work. One of the things we're doing is evaluating different MPC solutions and deciding which is the best, best one to integrate into this system. And then what we have to do though is once again, this is another change that's required to the staking module, the MPC key generation process. You don't want to do it every five minutes. That would be really annoying. What we do is we've epochized the staking module. You can make delegation, transaction and unbond transactions at any time, but they just get buffered until the end of an epoch and then get executed. Then basically the validator set can only change once every epoch and the epoch would be something like 24 hours or something. That way that's more than sufficient time to do the key generation. The MVC process we're working on the staking module that does those two changes, the less discrete weights and the epoch ization process. Are there any other questions? Have you considered on chain key generation? Solve issues with sync poa? Honey Badger does this. Yeah. So the core star dkg, actually what they did was they had an off chain DKG process and an on chain one. And so they attempt to do the off chain one and if it doesn't work, then they start doing the on chain one. So this is something that we're probably going to pick up that work and try to do. Yeah.