Trusted Execution Environments (TEEs) for Blockchain Applications with Ari Juels | a16z crypto

Transcript

very happy to introduce Ari Jules very well known in the space wears a lot of hats professor at Cornell co-director of ic3 Chief scientist at chain link going to tell us about some of his latest work are you all yours okay thank you delighted to be here I'm going to talk today about trusted execution environments and focus mostly on applications to blockchains although I'm going to talk about a couple of other applications as well this is a very unusual talk for me in that normally I give a talk after a paper has come out that's after a body of work is fairly mature today on the other hand I'm going to talk about two blog posts

so this is kind of a Rough and Ready presentation it's a work in progress presentation if you will I wanted to give you that caveat up front a number of really powerful cryptographic Primitives are starting to find their way into blockchain systems and they include things like snarks you know various succinct zero knowledge arguments and proof systems useful for all kinds of things from private Oracle queries to decentralized Identity to ZK Roll-Ups which of course aren't actually ZK I'm not going to go there fully homomorphic encryption is starting to get a little bit of traction as a means for realizing private smart contracts that's still in its infancy secure multi-party computation similarly

offers the possibility of realizing private smart contracts and it's good for other things as well like Key Management I mean like the Bold assertion that all of these are functionally subsumed by trusted execution environments as well as some things I haven't talked about like black box obfuscation which is not realizable using cryptography right providely unrealizable but there's a huge Proviso here which I'll give you a little later functionally at least trusted execution environments can do all these things what is a trust or execution environment it's a an environment in which a program can be run with some special and fairly

powerful Protections in theory at least this environment is often referred to as an enclave when a program's running in an enclave in principle its Integrity is protected in the sense that exactly the program that has been launched is the program that will continue to run and the program can't be tampered with even by the creator of the software underlying it even by the owner of the host on which it's running if the te is functioning correctly so that's one nice property we get from a te the second key property is confidentiality in principle this program can run with

secret state state that other processes can't access and again even the owner of the host doesn't have access to again assuming that the te is functioning correctly so these are the two Key Properties additionally at least some Tes provide a capability known as attestation attestation enables the te to prove remotely to a party that a particular program is running is characterized by its build and within this attestation can be placed a little bit of user data by user data I mean data from the program typically that would be

something like the digest of a public key associated with the particular instance of the software that's running but this particular instance of program X and this means that user interacting with the program knows exactly what she's interacting with and thanks to the integrity and confidentiality properties knows that this program enjoys the protections that the te bring to bear on it this is the general setup for Tes and you can use them for lots of different things to give you a very simple example here if you wanted a zero knowledge proof around a decentralized identity document say that Alice wants to prove to Bob that she has

a digital driver's license from California she wants to prove she has a valid California license but she doesn't want to reveal anything else private information on the license for instance she wants to keep all that confidential well in principle you could use a zero knowledge proof or argument system to do this but you can also use a te and with a tee accomplishing this is conceptually very simple the a program designed for this purpose generating zero knowledge proofs on driver's licenses or whatever ingests a digital version of the driver's license signed by an appropriate Authority in this case presumably the California DMV and then the program sends to Bob in

this case the one that Alice wants to convince an attestation so Bob knows he's interacting with a valid piece of driver's license processing software right with this program acts along with a public key associated with the instances program and then the program can sign a statement proving the thing that Alice wants to prove to Bob in this case Alice has a valid driver's license from California and that's it all of the other details are hidden so this is how we accomplish construct zero knowledge proofs using Tes and minimal cryptography right just basically digital signatures

there are a few different types of te platform and several popular ones AWS Nitro is a software te the protections a piece of software enjoys derived from other software software protecting a hypervisor in this case where a virtual machine essentially is the enclave Intel sgx on the other hand is an instruction set architecture extension in some Intel CPUs that provides Hardware backing for The Enclave there's special instructions that provide the properties that I

described and enable things like attestation huh AMD has its own analog to Intel sgx Works a little bit differently it has a larger trusted Computing base meant to protect a virtual machine rather than just a an application but operates essentially along the same lines with Hardware backing for the te and it's likely that everyone has a te here either on the table in front of you or in your pocket namely in your mobile device arm trust Zone which is somewhat similar to the previous two but doesn't have attestation capabilities foreign so these things are in widespread use

and they're different variants that's the important thing to take away my group has been working with trust execution environments for quite some time way back in 2016 I guess we worked on an oracle system called town crier where the Oracle provided both confidentiality and integrity deriving from the properties of Intel sgx we stood this up as a public service and according to our colleagues at Intel this was actually the very first public-facing Intel sgx application and I think it's a grand total of four uses users didn't see a huge amount of uptake but it was a first and it launched me at

least on my exploration over the years of trust execution environments all right so I've given you some detail but the takeaway here is that in fact there's a very simple mental model to characterize Tes basically a te acts like a trusted third party it's a trusted third party that can enforce integrity and confidentiality as trusted third parties are able to do in the fully General sense and it's also capable of arbitrary fairly inexpensive computation there's some overhead associated with using an enclave with say Intel sgx but that overhead isn't all that large actually in some

cases you can get performance close to that of the Native speed of the CPU okay but again you know some serious provisos that will actually be the pith of the second half of this talk well I said I was going to focus on blockchain related applications for tees and in particular I'm going to focus on the topic of block building to understand why you might need special security properties for Block building I need to give you a little bit of background on what's called Mev maximal extractable value so let me do that now just give you a brief primer the problem of Mev stems from what can be characterized as an unfortunate fact about the way that blockchains operate

today and that is that the process of ordering transactions is temporarily at least centralized when transactions enter a mempool they get taken up by a validator and that validator forms a block consisting of whatever transactions it wants in whatever order it wants it has unilateral control over the contents of that block so for instance transactions may come into the mempool and the order one two three the validator can order them in the block One Two Three or it can swap The Ordering of these transactions it's entirely up to the validator often validators will order transactions by the gas fees they offer in a system

like ethereum but not always all right well why does this matter why do we care about the order of transactions let me give you an example to illustrate how important it ends up being let's suppose that Alice here is interacting with a defy system decentralized service like a decentralized exchange of decks right and she wants to buy some Bob's bubble token new token just came out whose current price is one eighth per BBT well what you can do then is send a thousand eth to the decks and she'll get back 1000 BBT all is well and good now the nice thing about decentralized Services about dexes is that they

provide transparency so Alice knows exactly what she should get from the system now an effect of her buying this asset is that the price in the decks will rise this is true of any exchange not just a Dax you buy an asset it's price Rises well a validator of course in constructing the block that contains Alice's transaction gets a glimpse of her transaction before the block has been fully constructed so what the validator can do is manipulate the transactions in the Block in the following way take advantage of Alice's transaction by making use of this observation that

Alice's transaction will cause the price to rise what the validator can do is squeeze in before Alice's transaction a buy transaction right it's as though the validator can look into the future and see that the price of this asset is going to rise so it knows to buy this asset prior to the event yeah analysis transaction that will cause the price to rise and then it can turn around sell that transaction and pocket The Profit so now we might have a situation like this validator buys the asset Alice buys the asset price Rises validator cash is at the validator is going to make money here right because the price Rose after purchase the asset and it just turned around sell it where does the profit for the validator come from in this

simplified example comes of course from the pocket of the user here from Alice this is known as a front running attack the validator has front run Alice here meaning it's squeezed its transaction in first and to be more precise this is a sandwich transaction where the validator squeezed Alice's transaction between two of its own back in 2020 we published a paper in which we put forth the term minor extractable value to characterize all of the various opportunities afforded to validators to make a profit through reordering and transaction injection of the type that I showed you since minors have gone away in ethereum and have been

replaced by validators people use the term now maximal extractable value same acronym though Mev and this is an acronym that people use fairly regularly Mev is challenging to deal with in a number of ways I'll talk about a little bit more detail the ecosystem has chosen to deal with Mev by constructing a fairly complicated supply chain as it's referred to the way that these opportunities get capitalized on involves a lot of different players in a kind of pipeline so give you a little detail because this will be relevant later

arbitragers those who identify opportunities to make money are known as Searchers they will observe users transactions or receive users transactions and put them together with their own arbitraging transactions in little sequences known as bundles Searchers will submit these bundles to entities that construct blocks these are known as builders so Searchers are in some sense competing to get their bundles into blocks here builders will act independently of one another to construct different blocks which they then submit to what's called a relay now ultimately the block that gets taken

up by a validator is going to be the block that offers the validator the biggest bribe validators obviously want to make as much money as possible so each of these blocks includes some money a kind of tip or bribe for the validator these block Builders are competing with one another to offer the largest bribe to the validator where's that bribe going to come from it's going to come from extracted Mev okay so some sense Searchers compete with one another block Builders compete with one another trying to produce the juiciest block for the validator they submit their blocks to relay relay will select the block that offers the largest bribe and that will get transmitted to the validator with a little extra infrastructure to achieve

certain trust properties and in fact relays also compete with one another so the takeaway here is that you have this complex multi-step multi-participant pipeline the supply chain to handle Mev and I'm going to talk in a moment about a way that we might embellish the supply chain to minimize the extraction of Mev from unwitting users this is an early version of an architecture floated by the ethereum foundation and others called proposer Builder separation the validator is often referred to as proposer at least in this context and Builders are exactly

the entities I described and the goal in PBS as it's called is to keep these two entities separate in the service of decentralization I'm not going to talk about decentralization though interestingly one of the main protagonists in this drama of Mev known as flashbots has begun to use trusted execution environments and to insert them into the supply chain in particular they've constructed a block Builder that runs inside an enclave this has been running on the main net for something like six months additionally they have very ambitious plans to build what my colleague Andrew Miller characterizes as a Marketplace of

mechanisms inside an enclave ultimately what they Envision is users submitting transactions with preferences as to how they want them to be processed and arbitragers providing various mechanisms to handle users transactions and this kind of grand environment bringing together mechanisms and transactions in some way that has yet to be specified this ambitious project is known as Suave at the moment it's somewhat nebulous but it too is likely to make use of trust execution environments well Mev remains what I would consider a problem for users users are losing a lot of money to

arbitragers and I don't have fully up-to-date statistics but flashbots provides or has provided in the past a nice transparency dashboard as they call it that gives you some sense of how much Mev is being extracted in the ecosystem this is actually just the tip of the iceberg this is a very particular type of Mev but over the course of recent period of something like eight months you know 300 million dollars in Mev has been captured by arbitragers and validators and others in the Mev supply chain and much of this comes from users pockets as I said this is also just the tip of the iceberg there's a lot of Arbitrage

going on other places like in centralized exchanges and between centralized exchanges decentralized exchanges but this gives you some sense of the scale of the issue well some have argued that Mev competition this aggressive extraction of Mev where Builders are competing with one another and relays are competing with one another is essentially inevitable inescapable in fact and they've made an informal argument to this effect right offered an informal proof which I'm now going to describe here suppose that a validator is offered a choice between two blocks Block B and Block B Star

and let's suppose that b pays reward r and B Star plays plays a higher reward R star it builds just a little higher than r which block is the validator going to choose well it's pretty obvious if we assume that the validator is rational the validator is going to choose the block with the juicier reward the bigger payment so it'll choose B Star well where is the reward coming from in these blocks essentially it's got to come from Mev extraction now of course the fee payments as well but if you imagine both of these blocks have the same transactions roughly the same transactions and

provide the same fees right the reward here the bribe for the validator is going to come from Mev extraction and therefore at the end of the day the block with the highest Mev extraction is the one that's going to go on chain and therefore competition of the type I described is inevitable okay this is the argument made by proponents of the Mev supply chain say we can't get away from extracting Mev so we might as well systematize it doesn't all right I mean doesn't this sort of rule out by assumption like lots of solutions people propose though like kind of encrypted mempool type stuff where the block is yeah so now let me prove the opposite exactly

okay now I want to prove the Mev competition is not inevitable suppose again same setup validator is offered Block B or B Star B pays reward R and B Star pays a slightly higher reward Epsilon higher which will the validator choose well no same setup as before validator is going to choose B Star but let's suppose that the reward here comes from a special set of transactions a special bundle if you will to use the term I introduced earlier bundled transactions worth a little bit here and let's suppose that these transactions have been fairly ordered you know ordered in a way that doesn't give arbitragers opportunities

to extract Mev aggressively and you can choose your favorite notion of Fairly ordered here right I don't care how you define it no and and it comes from private order flow I should mention right so the transactions here are not not present in that block well now the validator is going to choose this Block B star that contains transactions that have not been subject to maximally aggressive Mev extraction so I would argue that this shows that Mev competition is not inevitable if if we can append a bundle of the type that I've described here in some way if there's a mechanism to do this and I'm now going to propose such a

mechanism in a system called Prof which stands for private order flow this is Joint work with a whole bunch of people at least one of them here now with in particular a group of Andrew Miller UIUC group of Don song at UC Berkeley and at least one participant from Fidelity labs so as I mentioned Prof stands for protected order flow and the idea behind Prof is actually fairly simple we could use a trusted third party for it but I'm as I've suggested Tes behave in a sense like very practically instantiable trusted third parties so what Prof is going to do is run an

application in a te that ingests transactions from private order flow or private mempool and it's going to build a fairly ordered bundle again use your favorite notion of fairness I'll talk a little bit about that later why use a te here for this purpose well we can do things like encrypt the transactions going into Prof you can create an encrypted Channel between the user submitting a transaction and the Prof service itself if you use a te use the confidentiality property of the te and this helps also this this helps prevent Arbitrage if transactions are encrypted they're harder to Arbitrage

it's harder to extract harmful forms of Mev and this also of course protects the bundle once it's been constructed the transactions in the bundle have to be concealed from potential arbitragers until they get released publicly teas help you do that plus remember T's enforce an Integrity property when a program has been instantiated in a te you as a user can check that that program is what's running and so if this program realizes a particular notion of fairness you have the Assurance as a user of the service that that notion of fairness will apply to your transaction Prof constructs a transaction bundle then what does it do with this bundle this fairly ordered bundle

it's basically a block enrichment service this is one way to think of it when a block has been constructed by for instance a block Builder or has been received by a relay that's meant to go to a validator what the Prof service will allow you to do is send the block into Prof and Prof will append this special bundle to the block and it'll do all this privately to begin with okay so the gray box there indicates that all this is concealed to begin with it's all happening inside the enclave and therefore confidential with respect to everyone else and then Prof does something that's done in the Mev supply

chain which you don't need to worry much about but a little bit of trickery to ensure that block contents don't get prematurely exposed to the world in particular it outputs the header of this enriched block to be signed by the validator and only when it gets a signature from the validator commitment to this block from the validator does it release the contents of B Star right if a validator signs the block and then sees the contents of the block and incorporates them into a new block it will have equivocated right it will have signed two different blocks and then subject to slashing and so on and so forth this trick is used as I said in

the Mev supply chain this is a peculiar Prof it's just a way of ensuring that things don't get revealed prematurely okay so this is basically what Prof does it enriches blocks with this private water flow and here's a summary slide right so in summary transactions go into plot Prof constructs is bundle and that makes this bundle available on a selective basis to the Mev supply chain Prof is not technically all that interesting or rather the use of Tes is fairly straightforward here it's more interesting as a mechanism as a mechanism it has some rather intriguing features the first I've already alluded to in my proof that Mev

maximal Mev extraction isn't inevitable validators and therefore those in the supply chain are as rational entities essentially compelled to choose an enriched block over an ordinary block to choose a Prof embellished block because they'll get higher Rewards so remember that this Mev supply chain is a competitive one these Builders are competing with one another relays are competing with one another to furnish the juiciest block to the validator if they're going to be competitive with respect to others in the supply chain they need this kind of Epsilon advantage that profit is going to offer them right I'm assuming here that Prof pays

some Epsilon amount extra to the validator it's a rational relay for instance will choose to get this extra revenue and those competing in the supply chain will have to incorporate this Revenue into the blocks that they construct now I haven't described whether Prof gets used by relay or by a block Builder can actually be used by either and we're still figuring out exactly where to position in the supply chain but pick either one and just assume that it's operating there okay so it's attractive within the supply chain it's also attractive to users as a user you have a choice you can send your transaction into the public mempool or you can send it to some entity in the

Mev supply chain and have the Mev squeezed out of it put things in somewhat simplistic terms or you can send it to the Prof service now Prof only needs to offer an Epsilon reward you know tiny reward to be attractive to the supply chain and therefore can charge very little to users to use its service so a user may only have to pay say a penny extra to use Prof to get this protection as opposed to paying what is essentially a tax large tax on her transaction okay so it's also attractive to users and the hope is that it kind of sweeps over the ecosystem and makes Mev harmful Mev

extraction from users less prevalent well I said this is work in progress there's still a lot of things we have to figure out as I said we have to determine exactly where in the Mev supply chain Prof should be situated we need to think about how payment works there are a lot of details to work out what if there are multiple instances of Prof we would like for the possibility of multiple entities standing up different Prof Services can they operate in conjunction with one another I believe they can as they recogn one Prof instance may allow for instance a or may allow another Prof instance to append its own bundle uh after the first Prof instances but bundle because this

doesn't degrade the protections afforded to users but this again is something that we need to work out in detail plus I've just described one mechanism it's not clear that it's the best mechanism for this purpose there are others floating around like Mev share which I won't describe in detail that need to be compared with Prof to determine whether really the the best possible mechanism for this purpose all right well I said I'd talk a little bit about this notion of fair ordering you can choose your favorite notion of fair ordering with Prof right you could do what sometimes called temporal Fair ordering or first come first serve ordering something that mahimna here has been working on for a number of years

and decentralize the process of ordering you can just use encrypted transactions remember I said t allows you to encrypt transactions quite seamlessly or you can do both actually these are complementary approaches or you can do neither you can do something else entirely profit can accommodate any of these things let me go back to this mental model I offered you for what teas do right so T's are trusted third parties I said there are serious provisos and let me talk about those provisos now and the second half of my talk is going to focus on the limitations of Tes security limitations talk about something called The Sting framework

which is meant to bolster t Security this is Joint work with Andrew Miller's group with again a whole bunch of people all right good question yeah I'm just trying to think about like where that comes from and competition for it right so somehow it was just in the technical Innovation you also have to sort of win the market battle about who's getting that private order flow and everyone's just kind of like probably outside it's gonna be outside the scope of what you talked about but I just want a few thoughts about that yeah it's not something we thought very deeply about but as I said a Prof service is going to be attractive to users as a user has a choice either get front run or pay this tiny amount to a service that's going to provide

protection from front running so it should be attractive to users and therefore a Prof service should attract order flow naturally from users because the worry would be that Mev share kind of a solution could then offer like a big discount you know so like it's not just you'll pay a cent but actually I'll give you money back in some sense uh me the share does in fact reward users with some of the money that's been taken by arbitragers the question is are users better off using one service or the other and if you have arbitragers in the mix I would say there's a good chance that you're not getting the best possible execution because there's still some cut being taken right right exactly yeah I guess

like those are concerns you can imagine there's like a hedge fund block Builder and they just won't integrate um the Prof like order flow and because they're just like very focused on during Med that they always just have better bids than the builders integrated with Prof then would that be a concern well again if you've got two Builders all other things being equal and one Builder uses profit and the other doesn't the one that uses Prof is going to win the competition to get its block adopted so they would be giving up essentially a competitive Advantage I guess like the in practice with all the things equal doesn't seem as reasonable like you can imagine there's like latency disadvantages like going through to eat we can certainly talk at length about

all the Practical nuances but at least in this very basic model of rationality it behooves participants in the Mev supply chain to use Prof okay so let me talk about the sting framework here all right so I said if a t is functioning correctly it gives these wonderful properties integrity and confidentiality but as it turns out T's are often not functioning properly and there have been Myriad pretty serious attacks against Intel sgx in particular which is really the leading te at least fully functional te a meltdown inspector many of you may remember back in 2018 affected sgx the colorfully named sgx ax came out a

little later earlier this year in February multiple holes in sgx patched and last week yet another serious vulnerability in sgx was identified and is being patched all right so why bother with Tes some content that they're fatally flawed and we should use cryptography exclusively to enforce properties of the type that I've described in the stock well there are a few reasons to take T's seriously I'll try to convince you that in the long run they're going to be a foundational technology first you can use them as a defense and depth layer if you add a te to a system in the right

way you make it strictly stronger right this can even be a cryptographic protocol like secure multi-party computation or you can run MPC and put the nodes in enclaves now to break the MPC protocol you have to compromise a certain number of nodes but you've made it strictly harder to compromise those nodes so the protocol as a whole has become strictly stronger additionally and this is a somewhat more nebulous argument I would say that T's with respect to cryptography are a kind of disruptive innovation in the very classic sense of clay Christensen you've probably heard the example of radios transistor radios given as a

to describe to characterize what a a disruptive innovation is okay way back in the early 20th century people had these fancy radios with vacuum tubes that functioned extremely well provided excellent sound quality and then along in the 1950s came transistor radios this newfangled thing called the transistor enables you to build a radio that offered much lower quality than the furniture radio the radio had been around for many years but it was cheaper and eventually it grew to be as good as and better than the original radio unless you're a Die Hard audiophile

okay this is the Hallmark of a disruptive technology to begin with it's in some way worse but it's cheaper faster has some obvious advantage and this is true of Tes right Tes are much easier to use than fancy cryptographic Technologies and also conceptually simpler plus they provide very high performance at low cost so they have a number of advantages in terms of security we can argue this but they're basically worse that's true for the moment so at all you maybe they're like transistor radios and finally I would say that there are ways to bolster meaningfully bolster te

security I'm going to talk about one of those today and that is the sting framework so one observation I'd like to begin with is that in the case of block building in particular and this is true of some other protocols as well we only need to enforce confidentiality temporarily ephemerally in the case of block building once transactions go into a block which will happen in a matter of seconds they get revealed to the world so at that point they're no longer confidential it's not as though you've got persistent pii personally identifiable information sitting in an enclave right these are things that are going to be disclosed in the short term anyway so temporary leakage really isn't

catastrophic the thing we're really worried about in for instance the case of block building remember I mentioned that flashbots has a te based block Builder and Suave is based on the use of T I think we're really worried about in that particular application of Tes is systemic abuse we're worried about some dark service I'll call it a subversion service some subversion service arising that gives an adversary access to all new transactions coming into the service and also potentially gives it the ability to inject its own transactions into blocks in a way that it decides now you may ask is this a real threat is

somebody actually going to stand up a service to do something illegal criminal like this well yes I mean they're already a real threat there are plenty of examples of compromises being turned into Services over the long term right ransomware as a service has proliferated for many years botnets are mainly serving as denial of service as a service you can get exploits as a service there are zero days that you can access through a service you can basically rent a zero day right this is happening in dark markets I would even say that in some sense the Mev supply chain is itself a subversion service somebody

noticed that there's this flaw if you will in the way that blocks get built and created I mean you can think of it as a dark service a service to exploit this flaw systematically okay so I would contend that subversion services are a real threat and concern now the question is if there's a subversion service can we prove its existence I'll explain a little later what we might do with a proof of existence but this is the goal of the sting framework to be able to prove the existence of a subversion service the setup is as follows we have some Target application right good application like block building

and our concern is that there exists some subversion service that's allowing people to exploit this thing in a systematic way what we want to be able to do is enable a user whom we refer to as the Informer to prove to a verifier that the subversion service exists the Informer is going to do this in the sting framework by relying on an application called The Sting framework application the SF application and to give you a little bit of a preview what the SF application is going to do is generate fake inputs to the Target application that will help the user construct this proof so this is the setup this is the

framework as it were all right well why should we trust this sting framework application it's playing a critical role in verification you know what basis are we going to trust it well the sting framework application itself can run for instance in a te can be hardened by a te okay now obviously we need to be careful to ensure that the software is correct and you know we want to make sure it's a trusted Computing base is minimal and so on and so forth all right but the thing you may be thinking is okay if there's a subversion service maybe it's been constructed or it's possible to construct it because sgx has been broken right I began the second half of the talk by saying sgx has all these

vulnerabilities maybe the thing that as I said enables the subversion service is the fact that sgx has been broken so it's no help it would seem to be running an SF application Within an enclave if the underlying service is broken right what's the point but this we get a nice feature in this framework namely that if the SF application is broken suppose that it's creating bogus verification or facilitating bogus verifications because sgx is broken well that's okay actually because if sgx has been broken and that's what's giving us the bogus verification of Sting proofs then the target application

is in trouble because it's using sgx so in fact if sgx is broken and that's really all that we're learning from an SF proof that's fine that already tells it that the target application is in peril okay now let me give you three examples of how Stingers get constructed and how the sting framework can be used to detect subversion services so I'm going to talk about three Target applications the first is private contact Discovery so in this case we're thinking about a Target application like a signal for instance which provides exactly this functionality Target application that will ingest users contact lists keep them

confidential and reveal matches indicate for instance to Bob whether any of the users in his contact list are using the the messaging service in this case signal for instance okay but we'll reveal these matches only to the user so here for instance Bob learns that Alice is a user of the system okay and Alice will also learn that Bob is a user of the system but others are not going to learn that these matches have been indicated to the two users okay so signal actually does this and they too use te's for this purpose along with another cryptographic primitive

called o Ram which I won't get into which basically provides a kind of secure memory extensions the way way to think about it all right now let's suppose there's a subversion service here say that sgx is broken and somebody constructs a subversion service that creates for instance a government backdoor so the government can learn people's contact lists or maybe there's just some side Channel attack against sgx and somebody has decided to set up a subversion service and actually sell contact lists right so we're supposing the subversion service here leaks these what are supposed to be private contact lists to an adversary how do we prove how does an Informer prove the existence of this aversion service

the way it works is as follows the SF application in this case generates a stinger a fake input that is a essentially bogus randomly selected contact list and that contact list gets injected into the target application okay so this fake user gets inserted into the Target application now the fs app SF application generates this Stinger secretly privately it doesn't reveal it to the Informer or anyone else and it gets sent privately into the target application some principle nobody should see this thing there is no user you here this is a contact list corresponding to a user that doesn't exist

the way that the Informer proves the existence of the subversion service is by extracting this contact list and then sending it to the verifier right proving that it's correct how does the user do this the user sends it to the verifier and then gets the SF application to say yes this is a contact list that I just injected into the target application so now the user has proven the existence of a subversion service has proven the contact lists are leaking second application some since the main application I'm interested in is talk a private block building so as I said we already have private block Builders running in sgx on the

ethereum mainnet what do we do if there's a subversion service the target application in this case is the block Builder running in an enclave its job is to ingest transactions and construct blocks or bundles the transactions are encrypted they're sent in encrypted form into the application and the use of encryption on the transactions and the use of The Enclave more generally should prevent things like front running or should be able to prevent certain forms of exploitation it should keep transactions confidential while the block is being built at least right that's the kind of the minimal functionality you need for correctly

operating block Builder this target application could be the flashbot's sgx Builder could be Prof just something than just transactions and constructs a block or a part of a block all right so suppose we have a subversion service how does an Informer prove the existence of this service let's suppose that the service both leaks transactions and allows insertion of transactions into a block this is actually the thing that an arbitrager would want right this would be very profitable for an Arbitrage because the arbitrager then could extract Med arbitrarily and if the subversion service is made available on only a limited basis like if only one arbitrager has access to it the

arbitrager can extract med without competing with other arbitragers so this would be a a truly profitable service or opportunity for the Arbitrage now you might think that if blocks get manipulated it's going to be obvious to people but I do want to point out that the use of a subversion service can in fact be hidden it's very hard to tell whether a transaction is generated by an arbitrager or comes from an ordinary user to go back to my early example the sandwich attack the arbitrager was injecting a buy order into the system before the users buy order arbitrager can easily make its buy order look like that of an arbitrary

ordinary benign user right so the use of the SF SS can be hidden and therefore it really is important to prove its existence how do we do this again the protocol here is actually fairly simple the SF application generates a secret Stinger okay in this case just a essentially random transaction and this transaction is going to be very hard to guess because it's got lots of entropy in the signature sends this transaction an encrypted form into the target application okay and what the Informer does to prove the existence of the subversion service is extract the transaction from the

subversion service and then construct a second transaction that depends on the first and I'll explain in a moment how it might depend on the first and then places this second transaction into the same block as the first well why does this prove anything transaction one should be kept secret or should have been kept secret until the block was published but we've got the second transaction that depends on the first transaction the second transaction shouldn't exist it depends on a transaction That was supposed to be secret with respect to the entire world and transaction two is present in the same block as transaction one which means it was created before the block was published in other words before transaction one became publicly visible so this

constitutes a proof of existence of the subversion service let me get to my final example which is not a blockchain service namely tour I think most people are familiar with Tor but just to give you a very brief description of what it does it hides Network traffic and the way that it does that is by constructing what's called a circuit a sequence of privacy preserving nodes as it were between a client and a Target server circuit gets constructed typically consists of three nodes although in principle could be more the circuit is Secret in the sense that only the client knows it nobody else

should know it and this is how Network traffic gets hidden like the server the user is communicating with has no idea where the user came from because the user is employing this sequence of proxies in the circuit suppose this is a subversion service a service that removes the Privacy protections from circuits what it does is it outputs client identities and the circuits that they built okay this could happen if there's a powerful Network adversary for instance can happen in other ways as well governments are known to try to break Tor turns out to be very well engineered and hard to break so often what they'll do is compromise endpoints as we know from the Snowden leaks the uh one Wonderful

Name egotistical giraffe program at NSA this is aiming at compromising tour in an exactly this way but in any case the subversion service is clearly a desirable thing for for governments and others how do we prove the existence of a subversion service very similar idea to the two preceding examples the SF application generates a secret stinger in this case it's a circuit then it runs Tour on behalf of the client it doesn't want to reveal the circuit to the user so it basically handles the circuit and the Informer then extracts the circuit from the subversion service and proves again you know similar format to the previous two examples proves to the

verifier that the extraction was the extracted circuit was correct so as I said the circuit should be private even with respect to the Informer so the ability to learn the circuit proves the existence of the subversion service now there are a whole bunch of subtleties here like the Informer actually learns the first node in the circuit it has to know the first node in the circuit so it has to know where to send the traffic to plus if it colludes with the server that's being communicated with it can learn the third node but the second node the so-called middle relay should remain confidential all right well I'm running out of time here so I'm going to skip over this discussion of

some of the nuances of the sting framework suffice it to say that Stingers need to look realistic if they don't look realistic in principle the subversion service can refuse to produce outputs if it thinks somebody's trying to construct a proof of its existence it can drop out of sight this is one of the things that we have to contend with and this turns out to be a substantial technical challenge yeah in fact since I'm low on time here I'm going to skip over a number of things I'm just going to say some of the applications of SF proofs are just whistleblowing to help the community achieve a high level of assurance in the applications it's using particularly interesting is the

possibility of bounties what we've shown is that the verifier can be a smart contract and the smart contract can pay a reward for providing an SF proof that's somebody can set up a bounty for say a block Builder that can be claimed by anyone who's able to prove the existence of this of a subversion service you can also Imagine offering bounties for not full breaks but partial breaks of a system and from a mechanism design perspective this turns out to be an especially appealing option as I said this talk is based on a couple of blog posts one back in April on Prof and another in June on the sting framework there are

papers forthcoming in the next several months I'm hoping finally I want to mention that as an aside yesterday I announced that my blockchain Thriller novel The Oracle is going to be published in February I'm delighted to say as far as I know this is the first at least traditionally published novel that has crypto at its core and certainly the first crypto thriller so if you like Thrillers and you like crypto you may want to have a look that's it I'll end there yes I was wondering like going back to the first half of your talk if you have this option

uh for like regular users to submit their transactions either to this like private mempool or the public Med pool where they'll lose Mev do you expect that like why would anybody ever submit to the public mempool anymore wouldn't the normal blocks basically like start shrinking to nothing and blocks end up becoming Justice uh private part that you were appending to the end of blocks before you've just alluded to my master plan yes I mean the hope is that transactions eventually get routed exclusively through services that order them fairly so it's not that I want the public mempool to shrivel up but I would like to see less Mev depredation and I'm hoping that Prof is

a step in that direction so there's no problem if you're appending to like an empty block they're in principle shouldn't be a problem appending to an empty block but I should also point out that transactions that are not vulnerable to me the extraction just sending money for instance can go through the public mempool with no problem so I wouldn't expect empty blocks in any case I have a question here yeah so in the kickstarting phase I imagine that the traditionally there could be just blocks that are for the regular mempool so you need some sort of subsidy of this phase otherwise because since it's an append it's from I understand it's an

append only so if your block is four is not going in yeah so blocks are full we're potentially in trouble but thanks to eip1559 blocks are supposed to be half full yeah but it so then it interacts with the with the pricing mechanism because let's say if it's going to take 10 percent whenever so the blog Builders all the validators needs to account for the fact that oh they need to keep this 10 percent for Prof otherwise prices start increasing and we need to go back anymore yeah so we we yeah we don't go around that yeah so we you know we haven't thought through in detail how Prof interacts with eip1559 but at least in principle blocks

should not be full so there should be an incentive to append these bundles and presumably block Builders will take into account the extra fees incurred as a result of making blocks slightly larger right in fact I guess it'll cause the fees to rise slightly which might even be to their advantage but again we haven't thought this through in detail so maybe coaching maybe one simple version of this would be you know as a builder using the service maybe I specify how big a bundle I want back from you for example so then like if I had 15 million gas I have to then decide how much do I fill up like from the public band pool then the rest I'll get them the service yeah having a limited size allocation would certainly be one reasonable

approach to this issue it's kind of up to the Builder to decide I'm just thinking you might need to subsidize them at the beginning because if you start the 15 million if with the 50 meter they get muv they will just say okay I'm gonna put the 15 million and then maybe there is 1 million from you but then that that pushes the price up this would lead them shrink again the block size because of the how eib 1559 not only about the price Rising but tries to keep the block size around 15 million right but yeah I mean it does that by by you know raising the the Gap the gas price I think it's

fair to say that as a block Builder if you're given the choice if your block is not full and you're given the choice between filling it out with a Prof bundle or not you have room you'll put the bundle in the block right now there may be situations in which you can't do that because blocks get full I don't know what happens in that case I mean even the bootstrapping phase I would sort of I would think the new equilibrium to say like you were getting a million gas back from the service every time right you just have sort of like a new base fee where the public mempool you'd only have 14 million gas willing to pay the base fee right so you can only construct a 14 million gas out of the out of the public transactions and then you get the other million back

from the service I think that would be kind of like the new equilibrium how about the trade-off between the 1 million where they get easy Revenue versus the I agree well I think this I mean I think this is interesting like how would you expect like what fraction of the blocks is it going to be like Noemi said we're kind of like you have nothing from the public mempool and it's all just from the service or that to me is very interesting to see how it plays out but even now like it's it's not the case that all of the block is full uh based just with I mean like there will be some space left and like you can expect that to slowly decreases users choose private event pool as well maybe yeah I mean it would be fun to see

how it plays out so I mean at least like game theoretically you can like try to you can speculate what it's going to look like there are a lot of considerations here yeah I think that you know those ample opportunity for follow-up work clearly yeah question about profit so you mentioned there are multiple Enclave Solutions you thought about kind of enhancing Prof to use all of them as a maybe onion or onion of enclaves or like a consensus run between different architectures we've considered only superficially how different Prof instances would compose so as I mentioned you could for instance do the following if there are two Prof services

rather than one Prof service only allowing its bundles to be appended at the very end of a block it might allow its bundle to be appended after a bundle produced sorry before a bundle produced by the other Prof service because it knows that the other profit service is ordering transactions fairly and that the other Prof service is not going to end up sandwiching it in some way for instance that's as far as we've gotten and thinking about composition but certainly interesting to think about more sophisticated forms of surface composition yeah all right thanks again [Applause]