Grindery And The Blockchain Oracle Problem

Grindery And The Blockchain Oracle Problem

In a previous article, we discussed the basics of oracles and how they are used on the blockchain. Given how vital they are in the ecosystem, you'd suspect that all the kinks have been worked out, but that's not entirely true. There's a very well known problem with oracles that no one seems to be able to solve, without compromising the very tenets that Web3 is built on. 

It's clear, however, that Web3’s oracle problem needs solving, and Grindery's made it their mission to do just that.

 

What is The Blockchain Oracle Problem?

The blockchain is a frugal infrastructure. This frugality gives it its capabilities like decentralization but also introduces limitations like the oracle problem. 

Blockchains cannot pull in data from, or push data out, to any external system, as a function that is inherently built in. Blockchains are isolated networks - much like computer without access to the internet. But what makes blockchains secure (their isolation), is also a very real problem.

For example, let's consider Alice and Bob. Imagine if Alice wanted to send Bob 1 ETH. For this transaction to happen in the Ethereum network, all the participating nodes have to agree on a future state of the blockchain in which Alice’s account had been deducted 1 ETH that got credited to Bob. This would require each node to check for transaction validity (things like if Alice had 1 ETH to send, if Bob has an active account to receive it, etc...). Pretty straightforward.

Now, consider if we were to introduce a complication to this transaction - say Alice wants to send Bob 1 ETH worth of USDT. For this transaction to be validated, each node (or validators) has to check for an additional piece of information from the previous example - what the exchange rate of USDT/ETH is.  

 

Relying on Outside Information 

Information such as the conversion rate of USDT/ETH is not something that is readily available on the blockchain. This is an off-chain piece of information and in this particular case, it is dependent on the buy/sell pressure of USDT/ETH across all exchanges.

So, suppose we decide to use an off-chain data provider to give us this information. Validators can now make API calls to this provider to get the USDT/ETH conversion rate and validate the rest of the transaction. But, note that they will probably not be able to reach consensus in this manner. The USDT/ETH rate is time-sensitive and depending on when the API call is made, will return different values. There is also the question of the quality and validity of the information that the off-chain data is providing.

 

The Problem With Oracles

Given that, due to the deterministic nature of blockchains, we cannot rely on a conventional mechanism to fetch off-chain data. This is where oracles come into play. Oracles can take off-chain data and publish it on-chain so that individual nodes can rely on the copy of the data published on the chain to determine the validity of transactions. Hence, oracles operate as the middleware connecting on- and off-chain worlds. 

Note that just bringing oracles into the picture does not solve all our problems, however. For example, if the oracle publishes false and tampered data - blockchain transactions could be a disaster. How does the blockchain even know that the information provided via the oracle is true? Or, what if the information being sought is subjective or requires external data that not every node in the network as access to?

Secondly, if the oracles are centralized- they become single points of failure that are prone to hacks. To address the oracle problem in blockchains, one has to address all these concerns. Luckily, there are multiple projects solving these issues at the moment.

 

Web3’s Oracle Problem And Grindery

In our previous blog, as well as this one, we discussed how oracles act as the middle layer between on-chain and off-chain data. The problem of the two worlds being siloed exists in more segments than just data and currency.

For example, if we consider the ops environment in Web3- we see that many DAOs and Web3 tools do not have access to the much more developed Web2 world of tools. A tool like Hubspot, for example, is a popular CRM across Web2, but it's not a DAO’s first choice because it isn’t Web3 native - contributors cannot sign in with their wallets, it isn’t connected to Web3 dApps, etc. The same goes if you wanted to tally the results of a vote in an Airtable, then share the results on Slack. Or, what if you wanted to track wallet transactions on a Google Sheet. You'd have to input the data manually.

What is needed here is a middle layer to connect between the two. Something more functional than an automated oracle, such as Gelato for example. Then, Web3 organizations would suddenly get access to innumerable Web2 tools that have gone through years of perfection to become the ideal tools for Web3 use as well. 

This is what Grindery is currently building. It is a Web3 gateway (or a Web2 gateway depending on where you are looking from) that lets you connect thousands of Web2 apps with Web3, or Web3 dApps with Web2, all with a few clicks. Much like a popular Web2 workflow automator that starts with a Z, with Grindery Gateway you define your triggers, and your actions, connect your wallet, and you're all set.

Unlike an automator that doesn’t care what you do in the end; it just does a function and executes what you programmed within the existing Web3 infrastructure, our tool puts the entirety of cyberspace all of its tools at your disposal.

Contact us to learn more.

 

[How to end–what is the next piece?]