A Faulty Oracle Will be Behind The Next Big Crypto Hack

Says Sergey Nazarov, who runs on of the most popular blockchain oracle providers

Good morning defiers! I spoke with Sergey Nazarov, CEO of Chainlink, which provides oracle networks for large corporations like Google, SWIFT, and dozens of blockchain companies. He says Chainlink’s most recent development, Mixicles, could eliminate the need for enterprise blockchains by making smart contract transactions private.

He explains why making trustworthy decentralized oracles is so important: They open the surface area of smart contracts, increasing the places where they can be attacked. (It’s why I’ve been on an oracle dive recently). There’s a lot to get wrong. He even goes as far to say the next big crypto hack might happen because of a faulty oracle.

Sergey talks about what he thinks Chainlink is getting right. He says his company’s advantage is in providing flexibility for users to create a custom oracle network that matches specific needs, and having a 25-person team focused only on oracles – they’re not building a product that competes with clients’ products. He hopes he can work with all of DeFi, including projects building their own oracles, like MakerDAO.

Sergey Nazarov. Image source: American Banker

The interview has been edited for clarity and length, and I’ve bolded my favorite quotes.

Camila Russo: Can you tell me about the real-world impact of your latest development, Mixicles?

Sergey Nazarov: I think the significance of that development is not small. Smart contracts are not competitive because they can't be made private, which is a deal-breaker for many contract types. This privacy dynamic is the only reason enterprise blockchains even exist. This is their only selling point.

CR: So if Mixicles are a solution to privacy and it really picks up, then it can help public blockchains compete with enterprise blockchains.

SN: Right. And it's not a small thing. There are three real problems right now. There's a connectivity problem, there's privacy and there's scalability. Oracles don't fully solve any of these problems. What they do is they contribute to solving them. The connectivity problem they do largely solve. That's their focus. The privacy problem can be solved by doing certain computations within the oracle network. What Mixicles really is, is showing a model for how you can have a private, decentralized financial instrument because you split the computation between the contract and the oracles. You took part of the contract and you've put it in the oracle and you said, I'm going to trust this oracle to remain private, which you can because you can designate who runs the oracles. And you can also designate that they run something called SGX, which inherently keeps the data private from even the node operator.

I would say, look, we're losing a lot of the market to enterprise blockchains. The only thing I know enterprise blockchains, or for that matter, centralized digital contracts, really do better than smart contracts is that they can provide this privacy that everybody has to have. And if we can get the public blockchain systems with their better security and better usability to have the privacy checkbox checked, we can go to a new level of adoption of public networks.

CR: What’s the big challenge about smart contracts using oracles?

SN: The reason that smart contracts can be made reliable is because all the parts related to the proper functioning of that contract are encapsulated within one secure system, right? There's no external data about token movement, token transfer, all the data, all the signing about transfers, happens on chain. But when we talk about making some kind of decentralized insurance contract or decentralized finance contract, or some kind of lending platform or something else, we're basically saying that this smart contract thing is now really made up of two or three parts.

It's not just made up of the code that triggers the state change and it's not just made up of a ledger that tracks data about ownership. It's now also made up of an intermediary third party called the oracle that's going to give it data about what happened.

The nature of the problem isn't just connecting this system to that system. The serious problem isn't about writing a piece of code. It's about writing a piece of code that then runs in a highly reliable infrastructure. What we're really talking about is if we're expanding what a contract is, to include the code on chain and the off chain systems, then we're expanding the surface area. So we're expanding how it could fail, and therefore we need to expand what we secure, and therefore we need to secure it.

CR: What’s the risk?

SN: If we don't secure it, then you're going to have things like the DAO, you can have situations where people get some money in that system and then people figure out the easiest attack vector is really this oracle thing, because at the end of the day, that seems to be the pattern in our space, right? People come in, they build systems. Some are secure, some are insecure, the systems get a certain amount of value in them and then eventually people realize that they didn't secure them well enough, and then somebody breaks them. It happened with crypto exchanges, it happened with smart contracts, and we're going to have a similar issue with oracles I think.

CR: How do you solve it?

SN: It's a question of what's the right decentralized infrastructure. What's the right approach? The approach from our point of view is one where you have a node operator, the node operator runs specific jobs. Jobs are like functions that the node operator can perform as an oracle for a contract. It could be something like, get me the BTC price, get me the BTC price and then do a specific calculation, find me the average between a few data sources. These very clearly defined jobs are then selected by user contracts. Those user contracts form a service agreement between themselves and the oracle contract. The service agreement very clearly defines the commitment of an oracle to fulfill an obligation which is backed by both their longterm reputation as an oracle and the immediate loss of a deposit.

The first thing a service agreement does is it creates a commitment from the oracle to the user. And that commitment is not some hand-wavy commitment. It's a significant economic commitment. The second thing that it does is it generates a bunch of data about all the very clearly outlined commitments that oracle has made and been able to fulfill.

The user selects the number of oracles they want based on a number of factors. The real question there is, why should I trust this oracle to do this type of computation for my contract?

I know why I rely on to state change of the contract. I rely on that state change because I consume extreme decentralization at a high price that's highly subsidized, right? I consume thousands of Ethereum nodes of decentralization. Those Ethereum nodes are subsidized up to 95% with block rewards, and I'm basically in a position where I go, okay, if there's 9,000 Ethereum nodes, I'm good. This state change is going to happen.

The question for oracles is, if you follow a similar model and you see I have 10,000 oracle operators and I want to query an API, it creates a  kind of a nightmare scenario where first of all, you have 10,000 API calls that isn't going to work a lot of the times. And so once you choose a job, you need to choose who's going to be responsible for that. You need to choose what level of security you want from them. And that's where you get to start making choices.

So the goal us is to make a framework through which people can compose decentralized oracle networks intelligently so that if they are going to have an oracle network and that oracle network is going to be on one hosting provider or it's going to be using one service like Infura to broadcast. Our framework, our system, it provides information like that to the user and it allows them to make informed decisions about the composition of oracles that they want to run.

CR: And when you say the composition of oracles, oracles is the combination of all of these different nodes doing one job? Is one oracle comprised of many different nodes?

SN: That's an oracle network.

CR: And when you talk about just one oracle, what does that mean specifically?

SN: It means one node operator. Then the way that the dynamic evolves is let's say your contract is a DeFi market for 100,000 bucks. and it grows to $1 million. Maybe now you need five oracles. Then it grows to $100 million. Maybe now you need 15. Then it grows to a couple of hundred million, and maybe now you need 21 or more. And the important thing is that you should be able to make intelligent decisions about the oracles that are triggering your contract and you should be able to scale up or scale down the amount of decentralization you're paying for.

CR: And these oracles, are they getting their price feed from one source? Will one oracle get their feed from an exchange API? Or where are they getting their information?

SN: It doesn't really make sense to get a price feed from a specific exchange because what happens is that you run into a data aggregation issue. We work with the largest crypto data providers, like Brave New Coin and Amberdata and BNC, which feeds data to the Bloomberg terminal. And what these services do is they aggregate exchange data and they normalize it to create a stable price.

CR: Can you tell me a little bit more about how your token is involved in your system?

SN: So our token does a few things. One of the important things that it does is staking. We're finalizing our implementation for that. But what that really does is it allows node operators to make an individual commitment. There's actually two dynamics around staking. One is what I call explicit state. Explicit staking is when you put up a certain amount of, you know, $10,000 worth of Links for a specific outcome that you're guaranteeing the specific contract, and that's what's at stake is that $10,000. The other form of staking is implicit staking. If enough node operators screw up service agreements, chances are the value of their holdings in Link is going to decrease. And that's the same logic as bitcoin. I'm a bitcoin miner. I have bitcoin, I have mining equipment that only works to make me more bitcoin. Do I really want to do something that will crash the price? I probably don't.

CR: What’s the amount of Link that node operators have to stake? How is it defined? Is it like a percentage of the amount that's in the contract?

SN: It's user defined. This is where the service agreement comes in and the flexibility of our system is that we are not a prescriptive system. We are very flexible. So the way a lot of decentralized computation gets consumed today is you have these thousands of nodes and you don't know who runs them. But because there's enough of them, you're assuming that even though there's no identity, there's Sybil resistance. So that means that they're not run by one person. And that's a valid assumption because when you have eight thousand, nine thousand nodes, that would be really tough.

What I'm saying is that in our system, the service agreement is as flexible as you want it to be. So the service agreement for decentralized insurance contract will be different than the service agreement for a decentralized derivatives. And it will be different than the service agreement for a gaming. And the reality is it'll also evolve as people use these service agreements in different environments. So, for example, in one environment, you want to be very conscious of on-chain costs and your service agreement might ask for the oracle network you don't want to make computation on-chain because it will cost you a lot of money. But in other chains that's not a problem because they have very low fees. There's a need for flexibility, so that every environment where a smart contract wants to interact with an external system, it can do that in the way that it needs to.

CR: Some platforms that have tokens enable voting. Is that something you foresee doing?

SN: It's hard to say right now. We don't have anything new to share about that. All of this is kind of evolving. Right now Link is mainly made for staking and it's made to pay the node operators. So right now the node operators get Link and soon enough the node operators will be staking in Link. And that's really the focus. Voting is a very complex thing. And what people would be voting on is an open question. It's an interesting idea, but we don't have any, any clear news on it yet. Let's put it that way.

CR: I spoke with Mariano of Maker recently and so wanted to get your perspective on how your oracles systems compare.

SN: Mariono is a great guy. I'm a huge fan and I'm also a huge fan of what Maker is doing with Dai. And I think it's very interesting what they what they're building. I think the reality is that we want to be part of it and the way that we want to be part of it is that we want to be one of the node operators. They're doing something that's in line with their model and it focuses on how do we have the Maker community vote on how to make Dai better? And what I would say is that if we built a high-quality oracle software and we've been able to prove to people that that oracle software is run by high-quality node operators and those node operators are able to provide guarantees that people find valuable, then I think it makes perfect sense that the voting system for Maker would consider that.

We have a team of 25 really top people. And we just want to solve this one problem. We want people like Maker and a lot of these other dapps to benefit from having a solution like the one we're making. We're open source under the MIT license, which is the most permissive license ever. It's even more permissive than Ethereum’s license. What I think is going to happen is just like people didn't want to build Ethereum to build their dapps, I don't think people really want to build oracles in order to build their dapp. I think what they want is a system that provides them the security guarantees that they need to build their dapp.

The other thing that I think is interesting is that let's say, Maker writes some kind of oracle software and let's say we write some kind of oracle software and let's say, somebody else writes some kind of oracle software. I think the smartest thing from Maker's point of view is to have a diversity of clients. So just like Ethereum has a diversity of clients, with Parity and Geth, I think it's similarly makes sense for there to be a diversity of clients such that even if you don't think Chainlink is the best yet or you don't think something else is good, you really might be in a better situation if you diversify your risk on that level as well. We're talking to the Maker community now. We hope to have a productive dialogue because the whole thing is our company doesn't make a competing DeFi products.

We don't have any interest in competing with any of these people. The entire purpose of our company is to make infrastructure that enables them. I think that's also another important point is that there might be people that don't want to use the infrastructure made by a competitor.

CR: That's a great point because maybe if you're using a competitors' infrastructure, there's always going to be some sort of risk that, you know, they might not be unbiased in their service somehow.

SN: Yeah, who knows, right? I think there is something to be said for being an open source, community driven oracle mechanism that doesn't compete with anybody on anything.

---

Sign up to get the best and only daily newsletter focusing on decentralized finance news, complete with analysis, exclusive interviews, scoops, and a weekly recap. All content is free for now. Those who become paid subscribers now, before the paywall goes up, get a big discount :)

About the author: I’m Camila Russo, a financial journalist writing a book on Ethereum with Harper Collins. I was previously at Bloomberg News in New York, Madrid and Buenos Aires covering markets. I’ve extensively covered crypto and finance, and now I’m diving into DeFi, the intersection of the two.