Google zooms in and builds a hybrid cloud blockchain application using ChainLink Oracle

On Thursday, tech giant Google Cloud developer said in a blog post that Ethereum application builders using Google software will integrate data from external sources in the blockchain using ChainLink's Oracle Smart Contract. This makes it possible to predict the use of many blockchains such as markets, futures contracts, and transaction privacy.

Allen Day, a senior developer at Google Cloud, writes that Chainlink can act as a middleware for smart contracts and real-world data, allowing decentralized applications (DApps) to obtain under-chain input without relying on centralized oracles.


(Photo from: Google Cloud)

By integrating with modern Internet resources and public cloud services, we can accelerate the adoption of blockchain protocols and technologies. In this blog post, Google Cloud describes some of the applications that make Internet-hosted data available in public chains that are not to be tampered with: using Chainlink Oracle Smart Contracts to place BigQuery data on the chain. There are countless possible applications, and developers have explored some of the applications they consider to be highly probable and immediate in their article: forecasting markets, futures contracts, and transaction privacy.

Hybrid cloud blockchain application

The blockchain focused on creating a shared consensus through mathematical forms, and later some ideas emerged to extend this model to allow for agreement between parties (ie contracts). In 1997, computer scientist Nick Szabo first described the concept of smart contracts in an article. An example of an early smart contract is the Colored Coin on the Bitcoin blockchain.

Smart contracts are embedded in the authenticity source of the blockchain, so after a few block depths, they are virtually immutable. This provides a mechanism to allow participants to submit encrypted economic resources to an agreement with a counterparty and believe that the terms of the contract will be enforced automatically, without the need for third party execution or arbitration if needed.

But none of this solves a basic problem: where to get the variables that evaluate the contract. If the data is not derived from recently added chain data, a trusted source of external data is required. Such a source of information is called oracle.

In previous work, developers used the Google Cloud Public Dataset program to provide public blockchain data in BigQuery for free for eight different cryptocurrencies. In this article, we refer to this work as Google's encrypted public data set. You can find more details and examples of these data sets in the GCP market . This dataset resource has led many GCP customers to develop business processes based on automated analysis of index blockchain data, such as SaaS profit sharing, using static analysis techniques to detect software vulnerabilities and malware. However, these applications have one thing in common: they all use encrypted public data sets as input to the out-of-chain business process.

In contrast, business processes implemented as smart contracts are executed on the chain and have limited utility without access to the out-of-chain input. To close the loop and allow for two-way interoperability, we not only need to make the blockchain data programmatic for cloud services, but we also need to make the cloud service programmatically interact with the smart contract.

Below, we will demonstrate how a specific smart contract platform (Ethernet) interoperates with Google's Enterprise Cloud Data Warehouse (BigQuery) via Oracle Middleware (ChainLink). This combination of components allows smart contracts to perform operations based on data from a chain query to an Internet hosted database.

How does Google Cloud build it?

From a high level, Ethereum Dapp (the smart contract application) requests data from ChainLink, which in turn retrieves data from Web services built using Google App Engine and BigQuery.

To retrieve data from BigQuery, Dapp calls the ChainLink Oracle contract and includes the payment for the service parameterized request (for example, the price of the gas at the specified point in time). One or more Chainlink nodes are listening for these calls, and after these calls are observed, the requested job will be executed. The external adapter is a service-oriented module that extends the functionality of the Chainlink node to an authenticated API, payment gateway, and external blockchain. In this case, the Chainlink node interacts with a specially built application engine Web service.

On GCP, developers implement a Web service using the application engine standard environment . The application engine was chosen because of its low cost, high scalability, and serverless deployment model. The application engine retrieves data from BigQuery, which carries a public cryptocurrency data set. The data provided by Google Cloud comes from closed queries, ie it does not allow arbitrary data from BigQuery, allowing only the results of parameterized queries. Specifically, the application may request (a) a specific Ethereum block number or (b) an average gas price for a particular calendar date.

After the Web service responds successfully, the Chainlink node uses the returned data to call the Chainlink oracle contract, which invokes the Dapp contract, and then triggers the execution of the downstream Dapp specific business logic. The process is shown below.


For more information on integrating Dapp, see Google Cloud's documentation for requesting data from BigQuery via Chainlink. For a descriptive query to BigQuery, you can view the price of the gas by date and block number.

How to use BigQuery Chainlink oracle

In this section, we will describe how to build useful applications using Google Cloud and Chainlink.

Use Case 1: Forecasting the market

Participants in the forecast market generally allocate capital to speculate on future events. One area of ​​concern: Which smart contract platform will dominate? Because as a network ecosystem, the value of the platform will follow the power law (ie, winner-take-all) distribution. There are many different opinions on the market about which platform will succeed and how to quantify success.

By using encrypted public data sets, even the most complex predictions are likely to be successfully resolved on the chain, such as the recent $500,000 bet on Ethereum's future state. Google Cloud also recorded how to measure the change, quantity, current status, and frequency of Dapp utilization by retrieving 1 day, 7 days, and 30 days of activity for a particular Dapp.

These metrics are called daily, weekly, and monthly active users, and web analytics and mobile app analytics professionals often use these metrics to assess application success.

Use Case 2: Hedging against blockchain platform risk

The decentralized financial movement was quickly adopted as a result of successfully innovating existing financial systems in a blockchain environment. At the technical level, these systems are more trustworthy and more transparent than current systems.

Financial contracts such as futures and options were originally designed to enable companies to reduce/hedged the risks associated with their critical resources. Similarly, data on chain activities (such as average gas prices) can be used to create simple financial instruments that provide payments to their holders if the price of the gas rises too high. Other features of the blockchain network, such as block time and/or miner concentration, can lead to risks that Dapp developers want to avoid. By introducing high-quality data from encrypted public data sets into financial intelligence contracts, Dapp developers' exposure can be reduced. The end result is more innovation and faster application of blockchain.

Use Case 3: Sending with submarine to implement Ethereum transaction privacy

A common limitation of Ethereum itself is the lack of transaction privacy, which allows opponents to take advantage of chain data leakage to leverage smart contract users.

By using the “ submarine send” method, smart contract users can increase the privacy of their transactions and successfully avoid those who want to preempt their opponents, making DEX more effective. Although this method is particularly useful in preventing malicious behavior like front-running, it does have its own limitations if you don't use Oracle.

Implementing submarine transmission without oracle will result in blockchain bloat. Specifically, the Ethereum virtual machine allows contracts to see up to 256 blocks (or about an hour) upstream of the chain. This maximum range limits the practical use of submarine transmissions because it can cause unnecessary denormalization when data needs to be rebroadcast. In contrast, by using Oracle to implement submarine delivery, blockchain bloat can be eliminated.

in conclusion

Google Cloud has demonstrated how to use the Chainlink service to provide data from a BigQuery encrypted public dataset on a chain. This technology can be used to reduce inefficiencies (submarine delivery) for Ethereum smart contracts and, in some cases, to add new features to the contract (hedge use cases) to make new chain business models possible (predictive Market use case).

Google Cloud's approach essentially uses a small amount of latency and transaction overhead in exchange for potentially large amounts of economic utility.

Google Cloud expects this interoperability technology to lead developers to create hybrid applications that leverage the capabilities offered by smart contract platforms and cloud platforms. In addition, Google Cloud is particularly interested in launching ML services for the Google Cloud Platform (such as AutoML and Inference API).