Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Ari Juels: Authenticated Data Feeds and Criminal Smart Contracts

Episode Date: January 3, 2017

Ari Juels, a Professor at Cornell Tech (Jacobs Institute) and former Chief Scientist of RSA, joins us to discuss his work two of his blockchain-related research topics: Authenticated Data Feeds for Smart Contracts and criminal smart contracts. One of the shortcomings of decentralized smart contracts is their inability to retrieve information from the outside world. Smart contracts can’t make API calls to websites and data feeds, but rely on oracles to feed real-world information to the chain. This potentially requires a high trust in the oracle operators. Authenticated data feeds promise to solve the problem by relying on Intel’s novel SGX hardware. We also talked about how criminals could use smart contracts to more efficiently conduct crimes such as incentivizing the theft of private keys or even soliciting real-world crimes such as murder. Topics covered in this episode: Ari’s background in cryptography and cryptocurrencies The pain points with oracles as we describe them today The idea behind Authenticated Data Feeds The hardware and software architecture of the Authenticated Data Feed model and how hardware isolation works How Authenticated Data Feeds could be used to create criminal smart contracts The differents ways in which criminals could use Authenticated Data Feeds to release bounties for crimes such as private key theft or even murder Countermeasures to fight criminal smart contracts The Initiative For Cryptocurrencies & Contracts (IC3) and its raison d’être Episode links: Ari Juels' website Town Crier: An Authenticated Data Feed for Smart Contracts (white paper) The Ring of Gyges: Investigating the Future of Criminal Smart Contracts (white paper) IC3 - The Initiative For Cryptocurrencies & Contracts CCS 2016: Criminal Smart Contracts Talk Zero Days: Stuxnet Documentary This episode is hosted by Brian Fabian Crain and Sébastien Couture. Show notes and listening options: epicenter.tv/164

This is Epicenter, Episode 164 with guest, Ari Jules. This episode of Epicenter is brought you by Jax. Jax is the user-friendly wallet that works across all your devices and handles both Bitcoin and Ether. Go to J-A-A-W-X.I-O and embrace the future of cryptocurrency wallets. Hi, welcome to Epicenter, the show which talks about the technologies, projects, and startups driving decentralization and the global blockchain revolution. My name is Sebastian Kutjua. And my name is Brian Fabien, we're here today with R.E. Jules.

a professor at the Jacobs Institute at Cornell Tech and before he became an academic he was also a long-time researcher at RSA, the famous cryptography company. And of course Cornell, we've had on a bunch of times people from Cornell because they have some very interesting activities around blockchain and around cryptocurrencies. So we're going to speak a little bit about that as well. And we're going to speak especially about two papers that, that Ari has published with his team, one of them about authenticated data feeds, which may sound bland at first, but it's actually a very, very crucial topic. And the other topic, of course, sounds about as alluring and exciting as any paper probably ever published in the blockchain

cryptocurrency space is about a criminal smart contract. So thanks so much for coming on, Ari. My pleasure. Thanks for having me. I remember when we talked before, you mentioned that, so you were at RSA, which is sort of one of the key companies right around the public key cryptography. And you mentioned that when you joined them, which I think was in the 90s, if I remember correctly, that you were even involved in cryptocurrency related projects back then. Can you share a little bit about what you were doing then? Yeah, well, it was actually cryptocurrency that first turned me on to cryptography. I read a paper in 93, I think, by Stefan Brands on anonymous digital currency. So that was my introduction to cryptography and computer security.

The first projects I worked on at RSA were cryptocurrency related, in fact. And the first crypto conference I attended was financial cryptography in 1997, I believe it was, took place in Anguila. So why was there an interest back then on the side of the RSA in this topic? Well, people often forget that before the year 1A, after Bitcoin, there was a lot of interest in cryptocurrency, but centralized forms of cryptocurrency in which privacy was provided through various cryptographic techniques such as blind signatures. And so the idea in general was that a bank, a central authority, would issue currency, but wouldn't know to whom it had issued it. This form of cryptocurrency, if I can call it that, or digital currency, arose as a result

of a paper published in the very early 80s by David Schoam. So this was already an active area of research, and it was natural for RSA, which of course was a cryptography-focused company at that time to take an interest in this as a potential application of cryptography. Yeah, I mean, we just recently did an episode with Ian Great where we talked quite a lot about this early history and some of the projects that were going on back then.

And I think this is a topic, at least I would be very interested in, revisiting a few times and doing like historical episodes, right, when one talks about some of these projects. I remember Ian talked about there being a whole community of companies primarily around Digi Cash in Amsterdam in the 90s, who were all working on this. Right. I'm curious, what are your thoughts on why those early cryptocurrency

projects never took off in the way that Bitcoin has. Right. Well, it's rather hard to say. I mean, there were a number of companies focused on various approaches to digitizing currency. Mondex was one of them, a company that relied on temper resistant hardware, smart cards to store money. It was a fairly alluring scheme, actually, so I don't know why it failed. Digi Cash, of course, is the most notable success. and then failure in this realm.

And it's not clear that its failure was due to technical problems so much as it was due to business problems and managerial problems. So one can easily imagine an alternate universe in which DigiCash flourished, and it's possible that in such a universe, we would today be using digital currency on a regular basis, but it would look very different from Bitcoin.

that's fascinating because I think one of the one of the most interesting segments of that in grigg interview I thought was him making this very point that a lot of these technologies had very good engineers around it but and the technology was for the most part rock solid but that business there was no business models or the business model wasn't sustainable or there were these managerial problems. And to hear you say that once again, sort of reinforces this idea that in order to build something sustainable, you need to have the technology side, but also the business side that have come together and in a unique marriage.

Yeah, well, cryptocurrency then and cryptocurrency now both attract some really outstanding technical talent. And David Schoam is known not just for developing blind digital signatures, which were what essentially fueled the growth of pre-Bitcoin cryptocurrency, but also for devising what are called mix nets. And those are essentially the basis for Tor. So he was one of the progenitors of Tor, as well as one of the progenitors of digital currency. Digi Cash was a company. He was involved in founding, and I believe at some point he may even have served as the CEO. So that's an example of the type of excellence that has marked this area of inquiry for quite a long time now. So you reasonably left, I think about two years ago, you left RSA to join or become an academic. What made you leave,

and how did you end up focusing so much on cryptocurrency-related topics? Well, I was, I guess, paradoxically, interested in academia because I felt there was more opportunity for influence and technology transfer than in an industry lab. It may seem a curious claim, but when you're working in industry lab, I was running RSA labs in my last years at RSA, you have essentially only one customer, namely the company in which the lab is located. As an academic, you have as many customers as you like, as it were, when you develop a new technology. And I have indeed found, as an academic, that it's been easier for me to influence new technologies than it was as chief scientist at RSA. So that was the reason for my leaving, and it seems to have panned out

in the way that I'd hoped. And did you anticipate that you were going to spend some of your research interest around blockchain and cryptocurrency when you left, or is that something that just sort of happened afterwards? Yeah, you were asking how I became involved. That was due to my colleague Elaine Shee, actually, who turned me on to smart contracts. I wasn't particularly interested in Bitcoin before I entered academia, although I had done research on cryptocurrency in the past, as I mentioned. But Elaine introduced me to smart contracts.

And in smart contracts, I saw just a fascinating range of possibilities. Of course, a cryptocurrency that supports smart contracts is a lot more flexible than a cryptocurrency without touring complete, if you'll allow me to use the term scripts. And offers many more possibilities. Some of them good. Some of them, as I guess we'll discuss later, not so good. But I saw here a topic that was both interesting from a research perspective and potentially quite impactful commercially and in the community at large. So speaking about your moving on to your first topic, which is this paper called Town Career Authenticated Data Feeds. Maybe first, where does the name Town Career come from? Well, a town crier historically was somebody who went around with a bell, ringing the bell, announcing the news of the day. And this was our goal in constructing what is often referred to as an Oracle, which we prefer to refer to as an authenticated data feed,

to serve as an authoritative source of news and facts state about the real world for smart contracts. That's the motivation. And why is it such a problem today for blockchain systems? Well, I would almost say that it is one of the major impediments to smart contracts really achieving fruition. As we were discussing earlier, I would, for instance, suggest that the reason that the Dow attracted something on the order of $200 million worth of investment was because investors in Ethereum had no. place else to put their money. And the reason for that is that it's very hard to write an interesting smart contract when you don't have access to reliable data that real world state. One of the very few things you can do, as you were remarking, is crowdfunding. And that's essentially what the Dow

was doing. So I think it was a lack of richness in the ecosystem that resulted in the Dow. And I think that lack of richness stems fundamentally from the inability of smart contracts to source a wide array of trustworthy data feeds. I tend to think this is a really fascinating new area of exploration with regards to blockchain technologies, having access to trusted sources of data. It seems like this is not the first of its kind of, like, Microsoft. Office is also doing something similar with this Bletchley architecture and the Cripplet system, where essentially a blockchain architecture, a decentralized blockchain architecture,

can rely on trusted sources of data that themselves are not centralized, but that inhibit the sort of same type of properties as a blockchain, whereas the source of the data itself can be trusted. and you put trust in this case in some hardware. So could you explain, perhaps elaborate on some of the technical architectural properties of this Tom Crier model on the hardware on the software side? Right. So Town Crier's main objective is to serve as a bridge between existing trusted sources of data, in particular websites, and for technical reasons, they have to be HTTP-enabled, serve as a bridge between websites and smart contracts.

So it's meant to be essentially a trustworthy pipe. Now, there are already pipes in existence that provide essentially the same functionality as Town Crier oricalize it would be an example. But the problem with these systems is that they require that you trust the system operator or you trust a couple of entities, TLS notary in addition, in the case of orcalize it. And typically, these are small operations. There's no particular reason to believe that they have implemented their systems correctly or that they themselves are trustworthy people, although I'm sure they are.

Now, of course, one can and should have the same concerns about Town Cryer. Why should some academics and their students stand up a service any more reliable than any other? The key technology behind Tom Cryer is something known as software guard extensions. This is a new instruction set architecture extension introduced by Intel into its recent model CPUs. SGX is an extremely powerful security technology. What enables you to do is run an out. application in a protected and isolated environment known as an enclave in such a way that even the operating system can't interfere with the control flow of the application and can't see

the state of the application. The enclave is, as far as the operating system is concerned, essentially a black box. Another thing that SGX enables is the production of what's called an attestation by the hardware to the software, the application, running in an enclave. It's possible for the hardware to generate a proof that a particular program is running in the enclave. When you combine all of this in an Oracle like Town Cryer, you get the ability to prove to people that data is being authentically scraped from a target website by a program running in an enclave that everyone can trust. can be published, scrutinized by the community, and so on and so forth. So in principle, you only

need to trust the hardware and Intel, of course, whom we all, whether or not we like it, need to trust for the most part anyway, in order to have the assurance that Town Cryer is delivering data faithfully from a source to a smart contract. Okay, so if I can just rephrase that. So the town Cryer is essentially a set of instructions running on secured hardware.

And by secured hardware, we're talking about an enclave that exists within a computer system that will run instructions at the service of the operating system. And the instructions that it's running have been, I presume that the

provisioning has been signed and also the instructions themselves and the results have been signed by the enclave. Now it's getting data. The instructions are calling external websites or calling APIs to receive data. So for instance, the enclave could call, say, the Bloomberg API and get market data. And then providing that data through the town crier to a smart And so what you have is you have a system where you have multiple routes of trust. You're trusting Intel and you're trusting their root key to properly, well, they attest essentially that you provisioned this enclave with a set of instructions. And it's also signing the results.

And you're trusting Bloomberg's key because they have a certificate. and, you know, one could argue on the validity of the certificate model, but, you know, let's assume that we trust Bloomberg's key. And then that information is then delivered to a smart contract, and those keys and sign the trend would presumably sign a transaction on the smart contract executing some action on a decentralized network. Is that an accurate representation? That's essentially right.

So there is, as you say, a program running in the enclave. a fingerprint of which is included in an attestation digitally signed by the platform. So a measurement is taken of the program and its memory at the time that it's stood up. And this measurement, this fingerprint to hash, is embedded in an attestation signed by the platform. So anyone who gets this attestation knows that it came from a platform that is running town crier code in an enclave. assuming that the fingerprint included in the attestation matches one published for the TownCryor Code. You can additionally bind to a particular instance of the Town Crier Code, a public key, whose private key is held by the application itself.

Once you've consumed the attestation then and determine that a legitimate piece of Town Crier Code is running, you know that anything signed with the private key, corresponding to the public key in the attestation, anything appropriately signed, was signed by the application. So you have the assurance that anything signed in this way was produced by a trustworthy piece of code. What does this piece of code do? It goes out and scrapes data from target websites.

The way that ensures that it's connecting to a valid website is exactly, as you suggested, by checking its certificate, at my bed, implicitly by doing it, by establishing an HTTP connection. All this is a little more involved than the description I'm giving because of problems like the lack of a network stack in the enclave. The enclave has to use the operating system to communicate with the network. But in essence, that's the way it works. So in this sort of stack of technologies that we've described, do you,

have to trust the operator of the enclave. What's the level of trust that you have to have in the operator? As long as you believe that the hardware can't be successfully tampered with, and there are some concerns about the security of SGX, and it's known to have side channels, for instance, but assuming that you embrace the abstraction that Intel is put forward, this black box model, you don't need to trust the operator at all. You, as you suggest, you do need to trust the website from which the data is being sourced, but you need to do that anyway if you're getting data from a website. But the operator you don't need to trust.

Are there any fail safes that one can imagine where perhaps the enclave would be retrieving data from multiple sources and making some sort of an average to figure out what an accurate value should be, or, let's say one of the websites is hacked or attacked or even just simply is down, making sure that that enclave can, that software can get the data from another source. Is that something that can be programmed within the enclave? Yeah, absolutely. There are few forms of replication that can be helpful in creating greater trustworthiness.

One is replication of the Oracle, the Towncrier Code itself. partly for reliability, but also in case an SGX host actually does get compromised. And somebody who's willing to invest enough money in breaking a CPU is almost certainly going to be able to do so. And so that's one form of replication that can be valuable. Another, as you suggest, is replication across data sources. And there are a number of ways to achieve such replication. You can forward data from multiple sources to a smart contract and let

it sort out how it wants to handle replicated data, whether, for instance, wants to take a majority vote over sources or an average in the case of, say, a stock quote or something else. Or you can do this within Town Cryer, which has the benefit of less data being sent to a smart contract and therefore lower cost in Ethereum, for instance, if we're the deploying this in Ethereum, where the amount of data transmitted determines the cost of a message. So there are these two forms of replication possible. Additionally, a very important feature of Town Cryer, something that it can achieve thanks to SGX that traditional oracles can't, is its ability to handle confidential data. And I can give you a couple of applications.

in which you can see the value of confidential data and why confidentiality of the type that Town Cryer provides or that can be accomplished by some other means is so important for smart contracts in general. Sure, perhaps. Can you give us one example of an application that would require confidentiality? Yeah, so let me give you an example. Our students, for instance, have put together a very nice little application, which, enables a smart contract to sell flight insurance. The idea is very simple. You're about to embark on a

flight. You request a policy from the smart contract, and you can request in the application as we've designed it, although you may want to change this in practice, you can request a policy of whatever amount you want. There's some associate premium that you need to send to the smart contract. and then if your flight is canceled or delayed, the smart contract will automatically compensate you. It will pay the amount specified in the policy. How does it determine whether your flight's being delayed or canceled? It uses town crier for this purpose.

So there's a very simple application, and one in which you can see why it's so important for smart contracts to have access to external sources of data, state about the real world. it also illustrates why confidentiality is so important. You need to specify, of course, in your policy what flight it is you want to insure. And if the flight you're insuring is, as would typically be the case, a flight you're actually on, you're broadcasting to the world, because this thing's on the blockchain, you're broadcasting in the world, your flight itinerary. And this is obviously undesirable. What you can do with Town Cryer is, is send the specifics of your flight, the flight number day and so on and so forth, directly into the enclave through an encrypted channel.

So that the code in the enclave can determine whether your flight was delayed or canceled, let the smart contract know whether a cancellation has taken place and therefore the policy should be activated. without the smart contract, without the blockchain, seeing flight details exposed in the clear. Now, this, as I said, is something you can do with a traditional Oracle, thanks to SGX, which provides this type of confidentiality, isolation of the program and its state with respect to the operating system. This is something you can do.

Yeah, that's a fantastic example. And also, just to run through a few other examples here, when in the Ethereum Vi-paper, right, one of the things they talk about is this idea of financial derivatives. Now, financial derivatives at the moment in Ethereum, you can't really do, right? But if you have, you know, currency data feeds

or, let's say, also, stock prices, you know, you could create synthetic versions of Apple stock, Google stock, you know, put options, call options, all kinds of stuff quite easily. And, you know, again, if you think of one of the

potentially exciting applications, for Ethereum, could be that in a country like China where they don't have access to stock market or, you know, they don't really have a tool to invest in, let's say, something like Apple, then they could potentially do that if you have those data feeds in something like Ethereum. And another example that's also mentioned Ethereum right. It was they said they have crop insurance. Again, you know, how do you do that if you don't get data in? but if you do have, of course, water, you know, fall levels and those kind of things,

all of a sudden becomes actually very trivial. Or maybe to give one last example, we've often done episodes on prediction markets. And if you look at one of the most prominent projects in this space is Auger, and they have developed this, in my view, convoluted system to try to essentially create a data feed, right, where they have, all these people with reputation, they're supposed to look up these events and then lock them, and then somehow this gets averaged, you know, weighted by how much reputation they have. And then the idea is this gets accurate outside information into the blockchain.

But, of course, it's very expensive and maybe still prone to some attacks. And then with something like SGX and those things, it just becomes totally trivial. So I think this is, yeah, it's super exciting. what you guys are working on. Yeah. So some of that, I mean, augurs and the prediction markets in general are an interesting way to deliver trustworthy data. They are, as you suggested,

prone to manipulation, particularly if somebody has a financial stake in manipulating the outcome of the market. An additional problem they have, of course, is that they can't provide confidentiality. And then, of course, they don't scale, precisely because they're so expensive, as you said. And they have to resolve

the events in the end, right? So somehow, how do they resolve the events, right? Either they have to rely on some sort of Oracle 2, which, in the example of Gnosis, right, one would rely on the Gnosis company. I'm sure they also will try to decentralize this in some ways. When Augur, they try to fully decentralize that, but then there has a lot of other downsides. And I think with this approach, you really just get rid of all of those problems. That's certainly the hope. Now, one of the things that Allgear does that a very basic Oracle, one that really just acts as a raw pipeline, doesn't do, is process data. But there's no reason that you can't run natural language processing algorithm in an enclave. And as long as people trust that the NLP algorithm is accurate,

it, they can rely on NLP instead of human beings to process data in a marketplace, with all of the complexity surrounding something like author or diagnosis. So, when can we expect to see those data feeds on, Ethereum, how far is this technology, when will companies, maybe prediction markets, and others incorporate some of these? tools. Well, we're hoping to stand up an alpha version of Tom Cryer quite soon, probably in the next month. That version will not be a production version and that it doesn't make, it doesn't make full use of SGX quite yet. Intel requires that users of SGX be appropriately licensed and

a critical service for the use of SGX is not yet live in production form. There's a test version currently available, but SGX isn't, as far as I know, available in production in complete form yet. But I expect that will happen soon, and our hope is that the town crier alpha will very quickly evolved into a beta. And I would hope sometime this year that we'll have a robust town-crier service available in Ethereum, serving many different forms of data and providing different varieties of confidentiality for its users. Let's take a short break to talk about Jacks. Jacks is a multi-coin wallet created by the people

at the Central. Now in the past, if he had a whole bunch of cryptocurrencies, it was a pain handle them. You either had to leave them on an exchange, which was insecure, or you had to have all these different wallets, which was a hassle. Fortunately, now with Jacks, those medieval days of darkness, misery, and suffering are over. Jack supports multiple cryptocurrencies and new ones are being added. But it's not just storing cryptocurrencies you can do with Jacks, but you can also exchange them directly from within side the wallet thanks to their shape-shift integration. And since there's only one seed, Jax makes it super easy to back up and sync to the other devices. Jaxx works with Windows, MacOS, Linux, Android, iOS, and has browser extensions for Firefox

and Chrome. So go to jacks.io, that's J-A-A-W-X.I-O to download the wallet and get started today. We'd like to thank Jax for the support of Epicenter. So at this point, these enclave technologies, I believe, are still sort of in their infancy. We have yet to see them be mass produced and massively available. It will be interesting to see what happens then when you can just like initiate an Amazon, on an enclave device on an Amazon instance or any type of cloud service. And that these things become readily available. One could imagine at that point that we have sort of this commoditization of data feeds

where data feeds become these commodities that you can just plug into and tie into any type of smart contract. Another thing that also is, I think interesting to consider is this commoditization of functions. So on one hand, we can have data feeds that are just pushing data to a contract. But on the other hand, we can also have smart contracts that call out this enclave to execute a specific sort of industry-specific function or something that perhaps is computationally very complex that you want to outsource to another system. Could you perhaps give us your thoughts on where this is going in the next 10, 15 years once these things have become readily available? Yeah.

So the larger vision as to how SGX might be used for blockchains is much broader than the one I've described for town. One can imagine executing smart contracts off-chain entirely in enclaves and having enclaves attest to their correct execution. This would have a number of benefits, including efficiency, ability, achieve much stronger confidentiality, and so on and so forth. So one can certainly imagine such a world. And given the way that the industry, certainly the financial industry, is already watering down blockchain technologies and planning to execute smart contracts off-chain, SGX seems like an essential ingredient. Do you see then these technologies, if they've become... I mean, this is a reason to think that they won't.

If they become massively available and robust, you know, scalable and, you know, we have industry support, do you see these as competitors to smart contracts? Well, you know, decentralized Ethereum style smart contracts? I'm not sure I would view them as competitors because I think they're achieving essentially the same functionality as smart contracts executing on a blockchain. There are many different blockchain models, of course, permission, permissionless, and so on and so forth. I think one can mix and match on-chain execution with off-chain execution and different blockchain models. So I don't see it as a competing so much as a complementary technology.

Well, let's move on to our next topic. And actually, it's going to be related a little bit as well. I think it's our matches to the authenticated data feed model, which is the topic of criminal smart contracts. Now, of course, Bitcoin has had a reputation for quite a long time in, you know, enabling illicit trade and silk growth, of course, is one of the best known Bitcoin projects. And so you seem also, you have now done research on what are some of the additional problems or different problems that come up when smart contracts are possible, as opposed to just, you know, cryptocurrency. So can you run us through? Is this a real threat, how big of a threat it is?

And what are some of the scenarios that you could see happening here? In the short term, I don't see it as a real threat. And part of the reason for that actually is the lack of good oracles at the moment. It's hard to construct a criminal smart contract without not access to real world state. So in some sense, Tau Cryer is going to be an enabler of the bad things achievable with smart contracts as much as it is of the good things. In the medium to long term, I definitely think it's a concern. We've already seen all kinds of mischief perpetrated as a result of the introduction of Bitcoin. Bitcoin has been very beneficial in many ways, but one can't deny

it's having fueled the rise of ransomware, for instance, which has become a real scourge, and leading to things like the Silk Road. So I think it's a real concern. Smart contracts create or provide much more flexibility than Bitcoin per se. And that flexibility will be used for good things and bad. It will almost certainly be abused. And it can be abused in some somewhat scary ways. One of the things you're talking about, I think the key concept in your

paper is this idea of commission fairness. Can you talk about what that is? Yeah, so commission fairness is essentially an embellished form of what's called fair exchange. A fair exchange is a problem that smart contracts solve very nicely. This is the problem of ensuring that when two parties transact with one another, that each gets what she is entitled to. So if, Alice has agreed to sell 10 shares of a stock to Bob, and Bob has agreed to pay $1,000, then Alice should get the $1,000, and Bob should get the 10 shares. So, ideally, we would like this transaction to be an atomic operation. If you use a smart contract, it can be.

Fair exchange is important in commerce of any type, and crime, of course, is just a form of commerce. It's a business. So it's important to criminals, just as it is for real honest players in a cryptocurrency. But Commission fairness acknowledges that fair exchange is actually not quite enough in a transaction, a legitimate commercial transaction or a criminal transaction. And I'll give you an example. So one of the criminal smart contracts that we explore in our paper is one that solicits the theft of a private key, like the signing key for a certificate authority.

So, say, Alice creates a smart contract, she offers $10,000 for anyone who can deliver the key, and Bob steals the key and delivers it to Alice. Well, fair exchange would mean that Alice gets the key and Bob gets the money. All seems good. But suppose that as soon as Bob steals the key, he reports the certificate authority that he stole in it. and then the certificate authority immediately revokes it. Well, Alice has gotten the key then, but it's worthless. So fair exchange hasn't guaranteed the implicit contract that Alice and Bob engaged in,

even if it fulfilled the literal contract. Commission fairness means that both parties get the value that they intended to get out of a contract. So it's a broader notion than fair exchange. And we formalize it in our paper for a few different smart contracts. So this example with the theft of a private key, can you explain how is it possible that, you know, if I'm the thief, I'm stealing this private key, how could I, you know, prove that I had this key to Alice to collect my payment without having to, you know, for example, post that key, you know, in clear text in an Ethereum contract? Because presumably I don't want to give it to everybody. I just want to give it to Alice.

Right. So here we can appeal to the magic of cryptography. If Alice embeds the public key of the certificate authority in her smart contract, Bob can provide her with the private key encrypted under Alice's public key and also provide a proof that the cipher text here actually contains legitimate private key. And this proof references the certificate authority's public key as represented in the smart contract. As I said, using the magic of crypto, one can construct such proofs. One can do it using ZK Snarks, for instance, but they're actually less costly techniques for this particular application. Today's magic word is crime, CRIME. Head over to let's talk bitcoin.com to sign in, enter the magic word, and claim you're part of the listener award. So you mentioned CK Snarks here. I mean, right now, Ethereum doesn't support those, right? So does that mean this smart contract wouldn't be possible at the moment on Ethereum,

but they would have to be support for ZK Snarks first? Or is there a way that one could do it today? Well, as I said, one can do it without ZK Snarks. Ethereum still doesn't quite have the crypto support. You would need to construct zero-knowledge proofs of the type needed here. So some embellishment of the crypto. capabilities of Ethereum would be required, but not a lot, actually. And I think there are many good uses for ZK Snarks and other forms of crypto, such that Ethereum will almost certainly want to support

them in the near future. And presumably also you could have ZKSnarks run on an SGX, and then have that evaluated in there potentially so that they kind of attest that, okay, this is the right key or this is the right proof. Yeah, that gets a little trickier. Intel uses a group signature scheme called EPID, which is also not supported in Ethereum at the moment. So the

validation would have to happen off-chain. It is possible. It just makes things a little more complicated. But yeah, so if you just look at the kind of larger implication, right? This is a pretty revolutionary idea, right? Because I, as a thief, I could say, or as a attacker or a

government or somebody I could say, okay, I want to put out a bounty for, yeah, let's say a private key of a certificate of authority so that I can afterwards fake the HTTP certificates. And, you know, I put out $50,000 or some amount on any Ethereum smart contracts. And then anybody at that company could steal that key, delivered to me, collect the money. And I don't even have to know who is that person. They don't have to reveal their identity. So that's a pretty powerful thing and a pretty threatening thing as well. And I think given the state of the, if you look at the current political landscape, geopolitical landscape and everything that we've been seeing with, you know, these alleged hacks of U.S. political parties by Russia with anonymous and WikiLeaks and all this kind of thing. You know, this could be a very, very powerful tool to the arsenal of any one of the players within this geopolitical, this new cyber geopolitical war where basically anybody can issue a bounty, say, you know, I want to get the key for, you know, this particular server in the Russian intelligence service.

and once that smart contract's been deployed, there's no stopping it. And essentially, it's up to, you know, who has the technical or even knowledge, you know, it could be even internal knowledge to release those keys. Yeah, and this is one of the frightening things about criminal smart contracts.

A criminal can create a smart contract and essentially just walk away. The contract will execute autonomously. and no further interaction is required by the soliciting criminal who created the smart. And there's an interesting question there. Is the criminal the one who deployed the smart contract or is the criminal the one who actually delivered the key? I think you probably need a lawyer on to talk about that. Right.

And additionally, to harken back here to our discussion of oracles, the competition of Oracle's, The combination of criminal smart contracts in oracles is an especially potent one because it enables criminals to solicit crimes in the real world, not just in the digital world. Far-fetched example we give in the paper is an assassination smart contract. There are lots of others that are a little less far-fetched and I think will be quite realistic. So the reason for our publishing the paper is that we regard these as real threats. and we think the community has to reflect seriously on how to counteract them, what mitigations should be built into blockchains before they do become a serious problem. So, yeah, now that we're at this lure topic, let's spend a little bit of time on that.

So with this working in a similar way, I would say, let's say I want to have somebody assassinated and putting out the bounty on Ethereum. And then how would they, you know, how would they collect that? that money, you know, if they really end up killing that person? Right. So the general idea here is that, you know, somebody stands up a smart contract and requests that the CEO of company X be assassinated and offers a bounty.

Then the smart contract can ingest an appropriately processed newsfeed to determine whether or not the assassination has taken place and pay out the bounty. Now, of course, the challenge here is how do you know, even if you know that the assassination took place, how do you know who was responsible for it? And for this purpose, it's necessary to use something we refer to in the paper as a calling card. This is a... So, in the real world, a calling card is an object traditionally left by a criminal at the scene of a crime as a kind of active bravado to call attention to himself or herself.

like the Beltway sniper in D.C. Some years ago used to leave a death tarot card near the bodies of his victims. That's an example of a calling card. In this context, a calling card is a piece of information about the crime that can only be known in advance by the criminal who perpetrates it. So an example would be the day, time, and place at which the assassination takes place. The way the contract would work is that the would-be assassin commits to a smart contract, puts a cryptographic commitment on the blockchain,

sends it to the smart contract before the crime is perpetrated, and then after the crime occurs can open this commitment to prove knowledge of details relating to the crime that demonstrate that he or she was actually responsible for it. And you can also require that the criminal leave a deposit so that you don't get, you know, frivolous commitments or attempts to guess details about a crime that's perpetrated. You know, thankfully, these activities are visible on the blockchain. So there's some hope of addressing them before they truly become problematic. If somebody actually does stamp up an assassination contract, one would hope that the community

would act to neutralize it in some way. And of course, it would certainly also be a warning sign to the person potentially, right? They said, like, hey, listen, there is a bounty out on you on the theorem or some other system. You know, you better get some bodyguards. You better get. Right. Well, thankfully, as I said, assassination is a little far-fetched. But in the case of some crimes, and key theft is a good example, you don't actually have to specify.

a single target to get benefit from the contract. For example, if you're interested in forging a certificate, you would be happy with the root key for any appropriate CA. And there are hundreds of root CAs associated with a typical browser. So the private key of any of those CAs would be sufficient for you to forge a certificate. You could, therefore, specify a bounty on any one of the, you know, in Internet Explorer, it's, I believe, over 750 CAs, any one of those 750 CAs. And that would be sufficient, as I said, to forge a certificate. So you would not actually be warning a single potential victim that a crime is about to occur, right?

You're warning a group of hundreds of potential victims. And it then becomes more difficult to defend against the attack. And in this case, would it also not be obvious? Well, you know, one would see somebody collected that bounty, but it wouldn't be possible to see which one of those keys was compromised. Yes, it's also possible to provide a zero-knowledge proof of the correctness of a private key that doesn't specify which private key it is, just specifies that the private key corresponds to the public key of some legitimate

certificate authority. Yeah, it's fascinating. You know, one can think of like this weird dystopian type movie scenario where you have, you know, these decentralized autonomous assassination markets where anybody can, anybody with the right amount of money can plan or put out a bounty for an assassination. and it'll be interesting to see how that would play out. Would that be sort of a leveling of powers or would there be some sort of mutually sort of destruction thing happening where nobody uses it because it could potentially be

catastrophic for everyone? Right. Yeah. You know, I think the greater risk is that people experiment with criminal smart contracts in a way such that the reputation of a cryptocurrency, like Ethereum is sullied, and criminal smart contracts then would really be to the detriment of legitimate users of a system of that kind. Or these criminal smart contracts are not so nefarious. They're not assassination contracts that the system in which they're being used is likely to be

shut down, but they are bad enough so that they pollute the water, right? That they drive. away potentially legitimate users of the system because the reputation of the system is so badly damaged. Yeah, and I think that's a very, very scary scenario, especially if you see in Bitcoin, right, so what was it used for? Okay, so some people bought some drugs online, right, and paid for Bitcoin, right? That's basically that and the ransomware ones are sort of the two criminal use cases. I think in Bitcoin that have really gotten some traction. And, you know, if one looks at some data analysis that has been done in Bitcoin, I think estimates are still that this is a very small percentage of Bitcoin transactions, you know, maybe 2, 3 percent or something like that, that concerns such illicit activities. And even then it has gotten, it has really tainted the reputation of Bitcoin very strongly.

But I think if you look at these criminal smart contracts, especially like something like an assassination contract or things like that, it will make for an incredible news story, right? It will make for it. And so it just takes one to completely dominate the image of such a system. Right. That's absolutely right. And that, as I said, is a real risk. Whether or not an assassination contract actually leads to an assassination is questionable. But whether an assassination contract might lead to some lurid news story that causes people to turn away from Ethereum is quite possible.

Well, let's do one last question on this one. What are some of the measures that exist to protect from criminal smart contracts? It's a really challenging problem, and it's not clear what the remedies are. One can delegate to some authority the ability to preemptively neutralize smart contracts, but that's challenging. And who's the authority? We're talking about decentralized cryptocurrencies here, so suddenly you're creating centralization. Who's the authority? How does the authority determine whether or not a smart contract is actually criminal?

That's a difficult question. The same format of smart contract I described with the calling card can actually be used for somewhat legitimate purposes as well as truly criminal ones. For example, you could use such a smart contract to solicit the return of a stolen piece of artwork. Then you're engaging with criminals. There's a risk of moral hazard that you're actually causing people to steal artworks, but the intention is good. Should such smart contracts be neutralized or not? It's really not clear. So these are the problems that bedevil any solution we've been able to come up. with. But I think almost certainly there will have to be some mechanism in place if we're to see

very nice systems like Ethereum thrive in the long run. So in closing here, just before we wrap up, I'd like to talk about IC3. So you're part of IC3, which is the initiative for cryptocurrencies and contracts. Can you tell us a bit about what is the IC3 and what the objectives are? Yeah, I'm happy to. I'm happy to. I see three is a recent. initiatives spanning at this point five universities, mainly Cornell and Cornell Tech, but also UIUC, University of Illinois, Urbana-Champaign, UC Berkeley, and the Technion. It includes a dozen faculty, most of them in technical areas, mainly computer science, but also including a faculty member at the business school at Cornell and one at the law school,

because, of course, the study of cryptocurrency isn't a purely technical one. They're very interesting financial and legal questions that form part of the research agenda of IC3. We have several dozen students at this point exploring a whole range of topics. IC3 was created to fill what we see as a really problematic gals. between the research is going on in academia and the needs of industry in the community at large. So IC3 is trying to do research that is relevant to the problems confronted by users today. We have a few industry partners. Intel is one of them, incidentally, speaking of SGX, with whom we work closely to distill out research problems that we believe are of significance,

and we work with others in the community. We have a close connection with the Ethereum Foundation as well. So, as I said, IC3 was created to bridge the gap between theory or academic research and practice. And that's what all of the dozen faculty members and many students are committed to. Yeah, and of course, we have had Emmen Gonser in Italy, Ayaln several times, Eamingunzier several times, who's also at the IC3. So what are the research questions that are driving your agenda and IC3's agenda? Well, we conceptualize our research agenda in terms of five big problems that we refer to as grand challenges.

One of those is the problem of scaling blockchains. This is a problem in any type of blockchain, permissionless, with smart contracts, without. We're looking to develop new techniques that allow cryptocurrencies to scale up to throughputs of potentially hundreds of thousands of transactions a second. So that's one of these grand challenges. Another is ensuring the correctness of smart contracts. The Dow amply illustrates the pitfalls of smart contract programming.

These are pitfalls that we're trying to address in our research. Another is the problem of confidentiality, where to be more precise, the tension between utility and confidentiality and blockchains. Blockchains are marvelous things in that they provide perfect transparency. Everything that happens on the blockchain is visible to the whole world. This is great for accountability, but it's disastrous for confidentiality. We believe that using techniques from cryptography and using things like trusted hardware, that's possible to eat, your cake and have it too, to run smart contracts that provide accountability, but also provide strong privacy. The fourth grand challenge is the delivery of strongly authenticated data

smart contracts, one of the problems we talked about today. And the fifth is writ large dealing with the unknown. When smart contracts in particular are executed, this is true more generally of blockchains, there's always the possibility that something unexpected will happen. Again, the Dow illustrates this problem quite nicely. So we believe that smart contracts should be designed in ways that are robust to error and unforeseen circumstances, that they should contain, for instance, what we refer to as escape hatches, ways of modifying the terms of the smart contract, modifying the execution of the smart contract. So these, these These five grand challenges are a broad umbrella in which the vast majority of our research

is conducted. And we believe that these are the most important challenges facing blockchain users today. Well, Ari, thanks so much for coming on today. And thanks so much for the work you're doing. I think it's super interesting. And I think you're absolutely right that these are such critical issues for this industry to resolve. And once they are resolved, it will be extremely interesting, the innovations those will unleash,

both on the good side and on the bad side. And it will certainly be watching very attentively also when this town crier is going to launch and, you know, when we're going to see some people doing the first experiments with that. So thanks so much for taking the time. Well, thank you. It was a real pleasure. Thanks for inviting me on to the show. And of course, we'll be linking as well to Ari's website and the papers we discussed today

as well as the IC3s website and other resources if people want to go a little bit more deeply into this topic so they'll know where to go. So yeah, thanks so much for joining Epicenter as part of the Let's TalkiCorps network. You can find this show and other shows on Let's StartBricon.com. And of course, you can subscribe to the show

on any of the podcast applications. And if you like the show, you and support us, then please leave us in iTunes review. It helps you people find the show. So thanks so much. we look forward to being back next week.