On July 6th RIF hosted an expert panel discussion on the topic of oracles: what are they and why do we need them? The transcript for the event is below, you can watch the full video here:
Raul: Welcome everyone to our RIF oracles expert panel! Thank you for joining us. Today we will be focusing on the topic of blockchain oracles: what are they and why we do we need them. The goal of this expert panel series is to educate our community on different topics in the blockchain space, also to provide a platform for experts to share different ideas and opinions on contested issues.
Rather than just sharing with you the perspectives of the RIF and RSK teams, we believe the best way to promote learning and collaboration in the space is to invite experts like yourselves to tell us what they have been up to in their work and how they have analyzed and overcome certain issues. I’d like to introduce you to today’s speakers and panel experts:
Nicolas Fett, CTO of Tellor, Julian Rodriguez, RIF Gateways PO, Joe Roets, CEO Dragonchain, Leo Vigna, CEO Vulcan Link.
If you’d like to give a short introduction of yourself and the work you are doing on oracles.
Nicholas: Thanks for having me, I am Nick Fett, CTO of Tellor. Tellor is a decentralized oracle on the Ethereum Network. The way we work is we have a network of staked miners that compete at a proof of work challenge to provide DeFi information. We provide currency prices for DeFi applications on top of Ethereum. I’m an economist by training, I worked for the federal government in the US, namely the CFTC, the regulator for financial products. And then I was doing a derivatives startup as an Ethereum grantee before I kicked of Tellor full time little over a year ago.
Julian: Hello, my name is Julian Rodriguez. I am the product owner of RIF Gateways. In RIF Gateways we are building a unified layer for conception of different oracle services. The idea is to integrate and leverage the existing protocols and create this unified layer for conception. Mainly we are starting on the RSK blockchain and the idea is to integrate all of these available protocols that are in the space and make it easy for users to consume them and subscribe to different oracles in different payment or subscription models.
Joe: Hello I’m Joe Roets. I’ve been a software architect for over 25 years and got into blockchain in 2010, worked back and forth in different startups and ended up at Disney building a private blockchain platform that we open-sourced and made a company out of it, Dragonchain. That was in 2014, 2016 we released, 2017 commercialized and we’ve been building a lot of interesting things and we touch on the oracle space a little bit including with a lot of interop focus. So we‘re primarily focused on scaled and secure enterprise or actual business applications of blockchain and everything in the ecosystem.
Leo: Hello everyone, I’m Leo and CEO of Vulcan Link. We are a Chainlink Node operator so we’ve been contributing to a lot of the reference data feeds from the chainlink oracle protocol and currently, in addition to running our oracle nodes, we’re focused on building platforms that highlight the diversity of existing oracle protocols. Our website feeds.link is looking to basically outgate a bunch of protocols. We currently have chainlink but we also are going to be adding Tellor The plan is to highlight the diversity of oracle solutions to see which best fits which use case. We’ve been running for two months now, we’re interested in learning about all the variety of oracles beyond just the ones we’re currently participating in.
Raul: My name is Raul Laprida. I am a Senior Researcher at IOVLabs. I am also the author of the RIF Gateways Whitepaper, the product that Julian is leading. Now we’ll move onto the questions. Why are oracles required?
Joe: Generally they get the external data, the real-world data, on to chain, and or between chains and/or to the user from the chain. Wide use.
Leo: That sums it up pretty well. Adding external data is all what oracles are about because, for people who aren’t familiar with blockchains, whether it’s a transactional blockchain like Bitcoin or more a computational syg machine like Ethereum, these protocols are initially isolated from the real world so you can’t submit like an HTTP request asking what the weather is or what’s the price of ethereum or any other crypto. So with these oracles we fetch external data and write it on-chain through our transaction, we pay the gas fee but we get compensated for writing that data on-chain. Then other dapps use this data for a multitude of use cases.
Raul: The next question I’ll address to Julian first, how can oracles propel the new web 3.0, and which is the approach you have to web 3 and blockchain-based oracle services on your project?
Julian: As I mentioned before, for RIF Gateways at this point we aren’t building our own protocol but we are trying to leverage what is existing mainly in the ethereum space and try to bring those into the RSK blockchain. We are working now with Chainlink, but have also integrated Provable and other protocols. As I mentioned, we are trying to build a unified layer for consumption that allows users to first browse the different available oracles feeds that are available and basically subscribe in a very easy fashion. One of the complexities we see in this space is that for integrating each oracle you need to understand how it is implemented. We want to provide a simplified experience.
Regarding how oracles propel Web 3, as it has been mentioned oracles are a big part of blockchain and other decentralized applications. It’s very difficult to imagine impactful use cases or scenarios where you can work in an isolated way and not have to access any information from the external world, whether it is an exchange rate for a financial application or any event such as insurance or other applications.I’m glad we are having this talk because oracles are a crucial part and an area where there is still a lot to do in the space.
Leo: If I could add to that, as someone who’s focused not really on designing protocols but more running nodes that add data to these oracle protocols, I see oracles as a kind of trifecta of the future of dApps that are aiming to have the web 3 decentralization with the web 2.0 user experience and fluidity. With layer 2 scaling solutions and meta transactions that are feeless for users and oracles, you kind of have the tooling that enables the creation of various diverse types of dApps that could not exist beforehand on blockchains. You get the external data, you get meta transactions where the Dapp can pay for their user’s fees, and you also get the scalability that comes with layer 2 scalability solutions where we have seen a lot of research on the Ethereum side. So with the data, the scalability, and the feeless user experience I think we’re going to be able to see the advent of dApps that feel like a regular website but also have the guarantees and security of the blockchain. That’s the long term vision that excites me most in the space.
Joe: Also, economy should be brought up. It might not be the easiest way to explain it in this question but you have the user experience side of things but also the decentralization itself. You need the economy, oracles are key, blockchain itself is key to that.
Raul: For the next question I will start with Leo. How do we ensure trust and avoid oracles being compromised?
Leo: This is a problem that hasn’t been perfectly solved, the civil attack. We’ve seen different types of solutions. For example, Tellor is using proof-of-work where each oracle has to do a certain amount of the work. With Chainlink, the point of decentralization comes from the aggregation of various data providers, various oracle operators such as Vulcan Link and others. Each provides data and you take the medium but each provides a challenge when even though the data is written in a decentralized manner we still need to make sure the APIs that people use are decentralized. For example, if 20 oracle operators all use the coinbase API then that data isn’t really decentralized because we all use the same back end API.
I think in the future we will need to see probably assigned data providers. For example, Coinbase started with their assigned data feed. If multiple exchanges have that option, this would enable better decentralization, and also proving the source of that data. As an oracle node operator, we could prove we’ve taken that data from this website and not just come up with a random number. Those are the things I’m interested in seeing, seeing provable centralized data that then gets written in a decentralized manner.
Nicholas: I think those are almost two separate problems, I would say the first is an oracle problem as far as figuring out how you will get off-chain data on-chain and move it there. The second question is: what is that data? So they are kind of separate. The first in that how do you get data on-chain making sure it’s not compromised. I think we sort of know how blockchains secure data, so how do you in a decentralized fashion come up with a consensus mechanism to secure what a database is. For that, you need a blockchain. It’s like what all of us would say, the only problem with oracles is that instead of specifying, ok it’s only for this limited setup, we are only doing these transactions and functions, now it’s everything. And you have to have a way to come to consensus on everything. And that’s how its a little bit more difficult and all of the problem statements, especially if you look back at the 2017 oracle designs or things like that, you’ve looked it up and say man, if they actually solve this they solve scaling and they solve connecting blockchains and so much more and none of them really ever took off because the oracle problem is really hard to solve from those perspectives.
Then moving on to the data piece that Leo was talking about, I think the way that we at Tellor look at it is there are two separate problems. If you look at “we want the price of Bitcoin on Ethereum” there’s the price of Bitcoin, there’s the price of Bitcoin on Coinbase, there’s the price of Bitcoin that somebody’s willing to buy from you right now for $1,000 or there’s the price of Bitcoin from multiple exchanges. They are all different numbers and there are different reasons you would want different ones. Because the problem is if you’re just getting it from let’s say Coinbase, of course, Coinbase itself providing it is the best, but the problem is now Coinbase can not provide it for you and they can censor it. But if you want something that’s truly censorship-resistant, maybe you just want to know more about the price of Bitcoin according to a bunch of people. It’s almost different use cases require different pieces of data.
Julian: The way I see it is there are two things that can be done. One is decentralization really helps, not only in terms of the sources, not just depending on a single source of truth, but also having decentralized nodes or different processes looking at the information but also getting the data from different sources. That’s one point, the decentralization. The other is try to work on more authenticity proofs. For example, there are mechanisms that can ensure what is the actual code that is running, the value that you are retrieving really belongs to that side, that it wasn’t tampered with during the transfer. There are things like SGFs which can ensure the oracle is running trusted environments by public code that is controlled; that also helps to bring transparency.
Joe: I think again it’s identity and economy. A lot of what we do, we’re not purely an oracle company, so what we do has a lot to do with when you’re in an enterprise having a spectrum of trust. Where can I trust my own data entirely, I can trust data of a business partner pretty well and when it gets further and further out decentralized, then I need more and more measurable proof because I don’t have a contract with them, I don’t know them. And we like to make things available at any point in that spectrum because there are different use cases and business use cases for those different levels of trust and when you’re talking about an oracle, some cases you don’t need a fully decentralized oracle because it’s coming from a trusted source. Like when we were talking about an assigned transaction from Coinbase, that’s good enough for me that’s fine, that’s business. If I’m running WikiLeaks that might not be good enough for me, I can’t necessarily trust that they won’t play with my numbers. So it’s all about the flexibility and how you structure that.
Leo: This touches on ideas like reputation with oracles, which is going to be a challenge in the future.
Raul: Now that you mentioned it, I know for example Tellor or Chainlink, scalability might also be a related issue with the sources of information you might want with your oracle. Is that a concern for you and Chainlink or Tellor right now?
Leo: I can speak regarding Chainlink for example. There are multiple areas of research. One is porting chainlink to other chains, so having bridges between chains and going to layer 2 chains. There are multiple chainlink partnerships along that, and also another current area of development I’m aware of is the use of bullet proofs so that oracle providers sign the data off-chain. Then we only have one transaction that gets verified on-chain. Currently, if you have 20 providers that are on an aggregator reference data contract listing the price of BTC, we each have to sign a transaction. But in the future with a bullet proof, multiple people can sign the transaction through off-chain communication, and only one transaction will be required to confirm the data update. That enables significant cost savings, for example, because that’s our main cost if your paying for your transaction. Especially when gas prices soar and that becomes an issue. But in the long term, there are innovations that are being worked on.
Nicholas: I think from Tellor’s perspective scalability in the oracle piece is almost second to scalability in the layer ones as well. We’re building on top of Ethereum right now. If you look at current costs to just mine, you could just mine every block on ethereum for 150 grand and just not let Tellor push any blocks to the chain. And you could do that with Chainlink or any of them. It’s just the cost of doing business on Ethereum, but at the same time, you don’t want to build products that rely on very fast oracles. We push that point a lot, especially with Bitcoin or Etheruem, there’s not finality in the chains themselves; you don’t want to necessitate 10-second finality through your oracle or build a product that necessitates that if the chain itself isn’t really finalized.
We try and get people to build slower things that can be more robust. If you remember black Thursday in March, gas prices on Ethereum shot up and basically the entire network froze for hours and hours and you couldn’t get any oracle pricing through and it broke a whole lot of protocols because they weren’t really built robustly. And I think it’s just something they haven’t solved at the layer one piece either. If you look at Coinbase, if you get a deposit for Bitcoin you wait an hour for confirmation before you’re allowed to do it. If it’s bigger you wait even longer, it’s still slow because there’s not finality in it. It’s sort of a problem, but it’s not a problem specific to oracles is what I would say.
Raul: Nicholas, now that we have you on the microphone I would like to ask you, how can we keep oracles as decentralized as possible, is this a priority?
Nicholas: Whenever I think of decentralization I always think ‘censorship-resistance’, can someone shut this thing down? I don’t need to talk about enterprises with Joe or anything like that, it’s sort of a different issue, as far as building oracles for enterprises. The thing you want to realize is that your only as decentralized or censorship-resistant as your least decentralized point. So even if you build this very robust derivatives network on top of bitcoin, then you have this central party as your oracle, you’re not decentralized at all. You see a lot of these issues whether it’s people building on stable coins or lending protocols on top of ethereum where they say they are completely decentralized and then it’s like, well you guys run your own oracle completely, you’re not decentralized at all. You guys could say the price of Ethereum is $10 million and throw it.
For us it should really be the number one priority, if you look at what’s really gaining traction, for us we think that things that are truly decentralized are what is going to take off. You look at whether it’s an Ethereum vs eos, eos sort of compromised on that and it hasn’t really taken off because people want to build things that are censorship-resistant. These are used for getting around laws. Whether it’s Bitcoin for getting around KYC, AML laws for digital transactions, and then you look at Ethereum you’re getting around security laws for issuing tokens, and what can oracles enable? It’s usually the things that are really going to take off on the blockchain so you need to say ok, what laws are we going to break and what are we going to get around and that’s kind of what’s exciting for me. Joe, any thoughts?
Joe: That’s funny. I would tend to agree. Decentralization in particular for censorship-resistance, that’s the biggest, maybe the most novel or interesting part of it, and yet that decentralization can be leveraged to provide a better economy, to pull in more info. Let’s say it is something you would see in an augur project, I want as much info on this question as possible before it’s answered and I want to build an economy on it, so I want the best information as early to profit the most, that’s really really interesting. In order to do that, you have to provide a good structure and a good economy and the hard part is I imagine, especially for you guys really working purely in the oracle space is, how do you possibly do that generically? That’s extremely hard. You think on any question how can I make sure the people that bring an answer, whether they’re coders connected to an API or there’s some interface for it, how can I make sure they are being honest generically, it’s really hard. That’s a reputation thing.
And just to note, we think, from a business perspective, that the vast majority of use cases that are possible that could actually leverage blockchain generically, don’t need absolute decentralization on most things. There are certain things they do, if I need to prove to my vendor I’m charging them the same, and am paying out the same for every other vendor, I do want that ideally on Ethereum or on some way that is fully decentralized. That anybody can check any of the numbers and say ok, I don’t know who that is but they are paid at the same rate as I am, that kind of thing. So it’s an interesting piece, the most interesting by far of the applications will be very decentralized, but the most mundane and with the most potential is in the non-decentralized sides of it that is feeding information from a trusted source that I need that I maybe make an agreement with and there’s some potential contractual liability even if you lie, so there is still the potential to apply incentives there, but it doesn’t have to be decentralized. But at the same time, it’s both right?
Julian: I agree, I think decentralization is a nice goal, but in order to get to fully decentralized systems we still have a road to transit. In terms of governance for decentralized systems in general, there’s still a lot to do yet that hasn’t been fully solved. And also in terms of efficiency; sometimes decentralized systems are less efficient and certain use cases as Joe mentioned may not need full decentralization, what the use cases need is reliable data on the blockchain, that’s all they need to fulfill their tasks. Many many use cases can be fulfilled with the solutions we have today until we reach truly decentralized solutions. I think it’s a nice goal but at least in my case if I’m developing something on the blockchain, I don’t see that as the main priority to be fully decentralized, but I understand the most interesting use cases, of course, will require that choice.
Leo: I think there’s also the potential for hybrid solutions, so I would say for example price feeds, some people might want to use decentralized exchanges such as Uniswap, but that can sometimes expose you to certain risks. On Uniswap V1 there were certain vulnerabilities where someone with a flash loan could manipulate the price and we had a couple of hacks with that. I think if I were to create a dApp today that was trying to get the most decentralized price feed, I think the fastest solution would be to take multiple oracle solutions and combine those because the risk of multiple of them having a critical failure at the same time is significantly lower than one of them having the problem. That’s what else I think is also very interesting; none of these might be perfect but many of these have flaws in different areas, so combining multiple oracles solutions can provide even more reliable a price feed. This is in the case of price feeds which is the main use case right now for oracles.
Nicholas: To pair off what Leo was saying, I think using multiple oracles is definitely one way to gain more security and a little bit more decentralization but I would just caution people whenever you are looking at oracle protocols if the protocols themselves are saying “we’ll decentralize later”, you see this strategy with a lot of blockchain products where they say they’ll just launch with a centralized oracle now and decentralize it later. The problem is well, we’ll launch now assuming we have an instantaneous decentralized oracle later and then you build all your front end and all your users get used to a super-fast oracle, and we’ll just be honest, a crazy fast decentralized oracle being built probably isn’t going to happen any time soon. Same with building like a lending platform and said, “well, we’ll just assume really fast decentralized layer one” well, it might be a while. You have to be careful where you are decentralizing and be realistic about what it’s actually going to look like in the future or it’s just a theater, your just kind of pretending to be decentralized for some reason.
Raul: Starting from Joe, what considerations change in the case of oracles for the enterprise?
Joe: This one is maybe a little broader to answer. We learned a lot at Disney inside of a large enterprise with what is possible and what a business will do, of course. Our whole focus has been on the protection of business data from the start because at least I thought early on that, beyond that most if not all enterprises will not except putting customer data on-chain. There has to be some separation and it’s typically structural and a lot of the projects out there from the beginning have tried to use math and encryption instead of structural architecture. With oracles it’s much the same, data protection is going to be key; if there’s no way they can expose certain aspects, if its a price point or something else then they will consider it. If its something that’s already public and they just need a verified source or multiple verified sources. The other pieces are actual integration, that it’s already expensive enough to produce software in a traditional enterprise, it’s very inefficient, it’s a very ugly sausage-making process where you end up with something that works but behind the scenes everything is always falling apart, and when you throw in something like any of the existing public chains out there its almost a non-starter, there’s almost no way you would want to pull that in.
And the other that you’ve already mentioned is scalability and flexibility. That’s why everything we’ve done is focused on those things. In the interest of the adoption of blockchain itself generically, and oracles are a big part of that, we need to answer, and we think we have answered, data protection, integration questions, scalability, and flexibility. The hardest part is usually communications: you solve the problem but its hard to cut through the noise with an actual solution, crypto Twitter is an example. It’s hard to get information out there in a way that people can consume and it’s even harder to get the right info out. Because this stuff is so abstract to most people that you have to find a way to pretty much show it to them: “here it is in a case that makes sense in a way that is a unique application.” An outside party can say “ok, this is something I would love to do but now it’s impossible” and it’s a beautiful thing to come in and say we’re using blockchain but you don’t even have to care about that, and oracles, that it just happens. It’s all a part of that because at the end it’s all about adoption to be able to get all of these chains to a higher level of adoption before people actually see what is possible. We are very early with all of this, but those things are key to it to get an enterprise to actually start adopting even in the smallest way some of this tech.
Julian: In the example of enterprise it’s a good example of how you can sacrifice a bit decentralization because you have it working partly in permissioned environments, more controlled. You probably need to integrate your blockchain application with your legacy systems or any type of applications you have running, probably, in that case, you have more flexibility to make more custom-built solutions that are more controlled and in that case, you can get better efficiencies. In that sense, you don’t need to suffer a lot of the issues we are suffering in the more open space.
Leo: I think one thing that might also change with enterprise data is even if you’re using a public chain like Ethereum, the type of data that the enterprise oracle will need will be much wider than what we’re currently offering. Right now the current use case for most oracles has been price feeds that are leveraged by DeFi protocols, but an enterprise customer might want to use like Joe mentioned, customer data or contract info. All of that, really technically we can get it done with Chainlink, but not really with the anonymity guarantees that private blockchains offer.
Raul: Julian, can you explain to the non-technical audience which is the most typical type of oracles?
Julian: As Leo mentioned, pricing feeds is one of the most typical ones. Basically smart contracts allow you to transfer value so anything that is related to financial applications, prices, currency exchange rates, financial assets, anything related to that is one of the most common ones. The other huge segment is events in the real-world, this is important if you have any insurance or escrow applications, dispute resolution applications in the blockchain you may need to react to certain things that happen in the outside world. you will probably need to build ad hoc or custom made oracles to get those specific events that you want. The other use cases are system integration in general, if you need to connect to any API, payment processer, a legacy back end system, whatever you may also need an oracle to do that and connecting to other blockchains. That’s another oracle, a type that is actually functioning as bridges between different blockchains.
Leo: I think one thing that’s interesting is what are the types of oracles that we haven’t thought about yet? In cryptography there’s the school of thought of “don’t roll your own crypto” and in oracles we’ve seen the creation of certain standards that make it easy to make your own custom oracle while still maintaining security. In the past, if you created a dApp that uses external data you’d have to code up your own oracle server that writes the data on-chain. But now with the standards, people won’t be rolling their own oracle they will be using an existing protocol and just writing an adaptor that fetches their own data they need for the application. But most of the standard stuff that connects to the Ethereum blockchain will already be implemented, it will just be about fetching the data that will be written on-chain in a standard way that dApp developers will learn to implement. This way we will see many more applications that in the past will have needed custom solutions but can now rely on a standard.
Joe: Can I add also, anything that would be for archival reasons, it could be historical data, weather data, rudimentary data, it could be simple stuff, the fact that the oracle was allowing that data to get on-chain with either some level of reputation, trust or something other in place. Even in the worst case, we’ve worked on projects where the data that comes in does come from an oracle with varying levels of decentralization depending, but that we in many cases try to apply bounty to it to be able to trust it. In some cases, the mere fact this arbitrary data that has been on-chain for 3 years now means something because I can’t go back and change that now. And it depends on what the data is, but the more atomic the data is the better our ability to trust it in the future because you get enough data on there that all connects, it becomes really hard to tell an alternative story in the future.
I’m not sure if you guys are looking at any of that right now. I’m sure a lot of the stuff you are looking at is for use right now, so finding data like most recent price so I can take action right now. We actually do a lot of work around getting data on-chain. Even looking at internal, this is a very arbitrary point of it but the fact that people will put tweets on chain that ends up proveable on the aggregate of Bitcoin, Ethereum, Ethereum Classic, and Binace, so you have to change all four chains in the future to go back and fake that this tweet wasn’t really what this person said. Who knows how valuable that is, in some cases its at least funny. That’s primarily what it’s for, to demonstrate this use case that we can get data on-chain that can then be later proven more than a screenshot that I can photoshop, that’s easy. The other side, Leo when you talk about the oracles that haven’t been considered, we actually do have something that was built way back at Disney and what amounts to it is ‘self oracles’. We have time based self oracles, they’re not possible on Ethereum but in Dragonchain because we’re hybrid we can do somethings where chains can become oracles to each other. You can do various things based on time, you can actually go out and pull in your own data on Dragonchain which is odd; the chain itself can go and get its own pricing data. But if you still have concern for trust you still have the same problems that you guys have, that part we‘ve left the solution for your guys and we’d like to integrate what you build to solve the cases where people really need to fix that problem.
Nicholas: We were talking about oracle use cases beyond the traditional ones, our first foray into research that we did with the Ethereum foundation was actually using oracles to bridge different chains together, so basically passing block headers whether it was for Bitcoin on Chain or different ethereum chain you could pass different block headers back and forth and you can verify different things that happened on different chains. That’s technically an oracle that’s doing that as well. I think in the future we’ll start to see more of that and like what Joe is saying, the next big piece for oracles is getting data from one chain to another or just getting data off-chain in general. Now you have this valid ownership, well, how do you read from the chain in a trustless manner whether it’s hardware or something like that, we’ve talked about the idea of having some sort of drone for instance that’s controlled by a DAO on Ethereum that could pass messages back and forth, that would be an oracle. There are different methods for having the transfer between different chains and pieces. I think those will be the next path for oracles when you realize how do you validate any sort of data and then we’ll go from there.
Raul: We’re running out of time so I’ll give you these the final question: Which are the main drawbacks when dealing with oracles? Leo, you can start.
Leo: I’ll focus on the drawbacks. It really depends on what protocol. Like I mentioned if you use on-chain decks you might risk some mutilation depending on the smart contract with things like flash loans. So I think uniswap v2 is much improved on that for the price feeds. For something like chainlink for example, for the drawbacks with something like API, the oracle is only as strong as the weakest link, if the API goes down that’s a problem. And also governance is critical. Who is paying the oracle? Right now chainlink has certainly improved the funding mechanism, we had certain dApps come on board and sponsor data feeds so that chainlink isn’t the only one paying for the reference data contracts. But in the future hopefully we will see forms of staking that will create penalty deposits so that if an oracle misbehaves they will lose their deposit and that allows token holders to stake an oracle and share revenue and have long term commitment to the data so that over the next couple thousand blocks, for example, we will always update the feed vs the current system that is mostly based on if you trigger a request we will respond to it but nothing guarantees that we will. Currently, it’s in our incentive to do so because we get paid and it improves our long term reputation. That’s chainlink specific. So improvements of governance and having penalty in staking.
Julian: I would add in terms of drawbacks, I think the cost needs to be improved a bit, I think the pricing reference contracts and that architecture of having one contract that is consumed by everyone and can allow you to subsides the cost. Otherwise, oracles are quite expensive, you need to write every transaction if you implement your own oracle. Also in terms of performance but this is also related to the blockchain itself as Nick mentioned. If the blockchain settles at a certain time it’s very difficult to have oracles, or it doesn’t make sense to have oracles that settle before that. But it’s true there is a limitation there that generally in the technology. Another drawback that I think isn’t that critical, I think Leo is working on this a little, there is not a marketplace or directory where we can have access to different oracles that allows applications to share and start connecting the different smart contracts that bring different data from the external world and have that place you can go to find the information. Eventually, we want to create a big network like the internet where we can get that information and you can trust it and know it’s working. I know that Leo is working on that with Vulcan Link.
Leo: I can speak to that quickly. Feeds.link is a platform you can view oracle data feeds. It’s still in development now. Initially, we launched with the Chainlink reference contracts but obviously Chainlink has their own website also with their reference contracts. The long term vision is to add other protocols, Tellor is going to be on board in a couple of days I think. We are also planning to have the maker doa oracles they plan to use, those are to a certain degree centralized, it depends, but to illustrate what oracles the current existing dApps use for example and what are the risks and historic performance of those oracles. We provide the platform to show all that the market offers currently.
Nicholas: We have been working for a while on an EIP, EIP 2362. Basically we want an oracle standard on Ethereum for reading different values, it’s been one of the issues in the space as far as if you are a project and want to integrate an oracle you have to write basically different adaptors for every single oracle contract and it’s quite a learning curve. So if we’re going to have an eventual oracle aggregate of oracle contracts we need some kind of standard, that’s what we’ve been working on. There’s a current EIP out there, we’re hoping it can be finalized soon and get people to start implementing it. So if you can go talk to your guys over at Chainlink you can push them a little bit harder then we can.
Raul: If you want to close with your final thoughts and conclusion. Julian?
Julian: I think this is a space that still needs a lot of development but I think it’s really exciting. As we spoke about at the beginning, oracles are going to be the enabler of the real uses cases that make an impact on our lives. Today we have these great applications particularly in the DeFi space and all this economy being built, but I think there is still a long way until we connect this with the real world. And this means also connecting devices, I’m thinking the IoT, things we can connect smart contracts to the actual world we interact with every day. That will be something very interesting to see in the future how we can really fulfill these visions. Like the car connected to your wallet and private key, if you sell it that gets transferred through the blockchain. All those uses cases we have said can be built but have a while to go to be realized.
Joe: About the subject itself, I believe that businesses or projects need to step back and think about the real requirements of what they are building, not be dogmatic. And figure out what that right model is. Because decentralization is complex enough that you want to make sure you focus it where you need it. Don’t try to apply it where it’s not necessary and you don’t need it where people don’t necessarily want it, where business doesn’t necessarily need it. The beauty then is that you have a mix of tech that you can apply and you need a good platform for it, that’s a lot of what we’re trying to focus on. We love to integrate with as many projects as possible and interop with as many chains as possible and in the end, it’s all about adoption, getting the technology in place, solving the problems and getting it out there, and getting it used. That’s what we’re all about.
Leo: I really agree with what Julian said about price feeds and how currently everyone’s using price feeds but we might see other data and currently the focus has been a lot on Defi, I’m really excited even though we mostly run price feeds right now, about the next wave of dApps coming online using layer two for scalability, oracles for their external data and meta transactions to get their users to have a feeless experience. I’m really excited for the no-compromise dApp, the dApp that’s decentralized but feels like traditional web experience. I don’t think we’ll see that on the main chain but we’ll likely see that on side chains or other protocols. Combined with oracles that will make really interesting use cases that we haven’t seen yet. I encourage any dApp developers to look into all of these protocols to fit their data needs, it’s definitely better than rolling your own solution, that way you can focus on your main business of dApp development and let us do the data.
Nicholas: Echoing what Leo and the others said, oracles are such an important part of the space. They’re starting to make up more and more a part of DeFi and their backing large amounts of value, I hope users look into what their oracle is, what the security features are, where the money is actually at risk because these oracles hold a lot of value already and people don’t even know how they work. Before you start building your project make sure you look into oracles and figure out what is possible and then if you already use one of these protocols make sure you ask them about their oracles and make sure you realize whether or not they’re as decentralized as they say they are.
Raul: I’m very curious especially about what all your projects have in your roadmaps. I have very positive thoughts on all the projects so thank you for joining.