Building hybrid blockchain/cloud applications with Ethereum and Google

Blockchain technologies and protocols adoption can be quickened by incorporating with public cloud services and modern internet resources. In this blog, we define a couple of apps of making web facilitated information accessible inside an immutable public blockchain: putting BigQuery data accessible on-chain utilizing a Chainlink oracle smart contract. Possible implementations are endless, but we have based this article on a handful that we believe are of significant and immediate usability: marketplaces prediction, futures contracts, and privacy of transactions. It is better to gain a good certification like google cloud certification to enhance knowledge related to the cloud application.

Hybrid cloud-blockchain applications

Blockchains rely on the computational work to create shared consensus. Ideas came up fast to expand this paradigm so that agreements, i.e. contracts, could be made between parties. In a 1997 article, the computer scientist Nick Szabo first introduced this idea of smart contracts. Efforts such as Colored Coins on the Bitcoin blockchain popularized an early example of inscribing agreements into blocks.

Smart contracts are integrated into the blockchain’s source of truth and are thus efficiently immutable after a few deep blocks. It offers a framework to allow participants to devote crypto-economic resources to a counterparty agreement and to assume that contract terms will be executed immediately and without third party arbitration or execution if desired.

But none of this answers an important issue: where to find the factors from which to test the contract. If the information collected is not extracted from data finally introduced on-chain, a trusted external data source is needed. This kind of source is known as an oracle.

How we built it

At a significant level, Ethereum Dapps (for example applications of the smart contract) demand information from Chainlink, which thus recovers information from a web service that worked with BigQuery and Google App Engine. 

A Dapp invokes the Chainlink oracle contract to retrieve data from BigQuery and incorporates payment for the parameterized request to be serviced (for example gas cost at a predefined point in time). One or more Chainlink nodes listen for such messages, and one performs the required job upon observation. External adapters are service-oriented components that expand the Chainlink node functionality to authorized APIs, gateways for payment, and other blockchains. The Chainlink node interacts with a purpose-built Web service from the App Engine in this case.

We executed a web service utilizing the Standard Environment of App Engine on GCP. Because of its high scalability, low cost, and serverless deployment model we picked App Engine. Application Engine gets information from BigQuery that has cryptocurrency datasets of the public. The information we’ve made accessible is from canned questions, for example, we aren’t permitting arbitrary information to be demanded from BigQuery, however just the results of queries that are parameterized. In particular, an application can demand the normal gas cost for either a particular calendar date or a particular Ethereum block number.

The Chainlink node invokes the contract of Chainlink oracle with the returned data after a satisfactory response from the web server, which in turn invokes the contract of Dapp and so activates downstream Dapp-specific business logic execution.

How to utilize the Chainlink oracle of BigQuery

We’ll describe in this section the best approach for the user applications can be built using Chainlink and Google Cloud.

Use case 1: Prediction marketplaces

Marketplace forecast members commit resources to usually speculate about possible events. There are several conflicting views on which platform should be effective, as well as how to measure performance.

It’s possible for even complex predictions by using the crypto public datasets like the ongoing $500,000 bet about the future state of Ethereum to be settled effectively on-chain. Also, we’ve reported how the volume, recency, variety, and Dapp frequency usage can be estimated by recovering 1-, 7-, and 30-day movement for a particular Dapp. These metrics are known as day by day, week after week, and month to month active clients and are as often as possible utilized by mobile application analytics.

Use case 2: Hedging against platform risk of blockchain

The digital finance revolution is gaining rapid adoption due to its effective reinvention of the traditional financial structure in blockchain environments which are more secure and open on a technological basis than the current structures.

Originally, financial contracts such as futures and options were developed to allow companies to reduce/hedge their risk related to resources that are critical to their operations. Similarly, on-chain data activity such as the average price of gas could be used to make simple financial products that provide their holders with payouts in cases where gas costs are increasing too high. Other characteristics of a blockchain network, such as miner centralization and/or block times, lead to risks against which Dapp designers would like to safeguard themselves. By having brought high-quality data to financial smart contracts from the crypto-public datasets, potential risk can be decreased for Dapp developers. The net result is more innovation and speeding up the adoption of the blockchains.

We’ve recorded how a smart agreement of Ethereum can interface with the BigQuery oracle to recover data of gas cost at a specific point in time. Also, we’ve executed a stub of an option for smart contract indicating how the oracle can be utilized to execute a collateralized agreement on future gas costs, a basic contribution for a Dapp to work. 

Use Case 3: Enabling reveals/commit across Ethereum utilizing submarine sends

One of the frequently mentioned limitations in Ethereum is itself an absence of transaction privacy which creates the capacity of adversaries to take benefit of on-chain information theft to leverage users of frequently utilized smart contracts. It can come in the form of forwarding deals involving distributed exchange addresses (DEx). As described in Send in the Submarines, To Sink Frontrunners, the front-running problem plagues all current DExs and slows the progress of the Decentralized Finance movement, as exchanges are a major aspect of many Defi applications/products.