Is EIP 8105 open to any encryption mechanism?

Transcript

I'm going to ask another question of Lewis. Specifically to encrypted mem pools, you mentioned that someone could encrypt their own transaction, that they could use a decentralized encryption provider. Um I guess the question is with EIP 8105, is Shutter looking to enshrine our version of commit and reveal threshold encryption into the Ethereum core protocol, or uh is something different being proposed?

Yeah, no, exactly. Um definitely not. So, um the idea is to keep it open and generalized and to say that um any encryption technology that satisfied satisfies a very general and broad kind of like interface spec uh should be allowed. Um and and especially any key provider any should be allowed to to provide keys yeah. Um and just to but I would say just to make a nail down or also to reiterate a little bit why threshold encryption is kind of uniquely suited to do this is one, yeah, it's just just decentralized way, right? So, you want to decentralize it right?

Um but especially the unique property of threshold encryption is kind of it solves this last look problem, or there's kind of like this free option problem. Um so the if you encrypt with your own private key, that would also be decentralized, right? Because everyone encrypts with their own private key. But then there's a kind of a game theoretic issue because if you encrypt with your own private key, then you have an option later not to decrypt. And then you can actually invalidate your transaction and pull back your transaction at a later point. And why that's a big problem is because with there's always an option kind of in

So, if you do a let's say you commit to buying ETH at $1,000, I don't know, and then there there's going to be some time, let's say 10 seconds, where the price fluctuates up and down. If you then after If you've already committed to it and then afterwards you can just pull back your trade because you've seen, "Oh, the price went against me. The price in the meantime went to $990." You now no longer want to buy at a thousand right? Um so, you'll just pull it back and you invalidate your transaction and that's this free option. So, you have a free option not to decrypt essentially if you yourself encrypt. And now imagine this more elaborate attack where you just

send a thousand transactions at varying price points of ETH, right? And you just always to select the best one for you, right? So, that's kind of like then key key key key leads to the system. Um so, you want to have it decentralized and you need to eliminate this free option to make it just like work and sound, right? So, that's kind of this unique unique thing for threshold encryption because it kind of like enforces decryption. Uh and and you're not the one who decrypts. And it does so in a decentralized way where there's no So, the cool thing is I was like if like twelve Let's say you have twelve out of seventeen nodes need to um need to come together to to decrypt. There's like

this threshold of twelve compared to the total number of nodes of seventeen. So, let's say all the nodes have come together like six, seven, eight, nine, and then you're at like eleven, right? So, you just need one more key share to then get to the decryption. So, you have eleven, but you need twelve, right? And then there would be a theoretical free option, right? Where one one person could say, "Oh, I'm not releasing my key share. I can now uh I can now kind of have this free option not to decrypt." But um because now there's still seven there's still up to 17 left, so you still have um eight people left, right? No, wait.

Bad math. Six or something, I don't know. Well, 17 minus uh right? You have a good a large number of uh of um of actors um which all of them can can submit the last key share. So, you're taking away the option to decrypt from uh the option not to decrypt from one person to suddenly there's all these people who all can choose to to to submit their key share and decrypt. So, you're really making it extremely easy to get it to get decrypted, especially then if you scale it to 200 nodes, right? Then there's really like pretty sure that it'll get decrypted. Um so that that that that's kind of this

like um property of uh this is nice property of of like kind of uh unstoppable decryption. And so, like, it will be decrypted. And that's why we think a threshold encryption is probably the the the best approach. But yeah, still keep it generalized and still keep it open, especially keep it future proof, right? There might be much cooler and much better cryptographic systems in 2 years 2 3 years down the road, which we want to have it be compatible with with this as well. Maybe just a quick note uh when Luis mentions uh keep it generalized, what we're really talking about is allowing or creating a uh competitive marketplace for key provider services, for

encryption and decryption services. So, we could imagine that um some users which have low value transactions, um they may be willing to trust a TEE uh because it's fast and cheap and it has hardware assumptions. Uh other users, which have high-value transactions or sensitive transactions, uh may uh prefer uh to use threshold encryption uh and rely on cryptography rather than hardware. In the future, it might be FHE or some other type of encryption.

Um but really giving users a choice there.