Ethereum and Google Cloud: How to build hybrid blockchain/cloud applications?
Editor's Note: This article comes fromBlue Fox NotesEditor's Note: This article comes from
Blue Fox Notes
Preface: To develop a dApp, not only data on the chain is needed, but also data off the chain. How to use decentralized oracles and Google Cloud datasets to obtain more reliable data? How to drive more dApp innovation?
By combining modern Internet resources and public cloud services, the adoption of blockchain protocols and technologies will be accelerated. This article will describe some applications that provide Internet-hosted data in an immutable public chain: using Chainlink oracle smart contracts to make it possible to place BigQuery data on-chain. But this article focuses on some that have a high degree of immediate utility: prediction markets, futures markets, and transaction privacy.
secondary title
Hybrid Cloud Blockchain Application
Blockchains focus on mathematical efforts to achieve consensus. Soon, the idea of extending this model came out, which allows peer-to-peer agreements between different parties, that is, contracts. The concept of smart contracts was first proposed by computer scientist Nick Szabo in 1997. In the early days, there were also examples of writing the protocol into blocks. With the efforts of dyed coins on the Bitcoin blockchain, more and more people gradually understood.
Smart contracts are embedded in the source of truth of the blockchain, therefore, they are immutable after a few block heights. This provides a mechanism that allows participants to commit cryptoeconomic resources to an agreement to trade with a counterparty, trusting that the terms of the contract will be enforced automatically, without third-party enforcement or arbitration.
But none of these solves a fundamental problem: where to get the variables for contract evaluation. If the data is not from recently added on-chain data, a reliable external data source is required. Such data sources are called oracles. (Blue Fox Notes: That is to say, how to obtain reliable data that triggers the terms of the contract.)
In previous work, we made public blockchain data freely available in BigQuery through the Google Cloud Public Datasets initiative. In this paper, we refer to this work as Google's Encrypted Public Dataset. You can find more information and examples of datasets in the GCP (Google Cloud Platform) marketplace.
This data set resource has led many GCP (Google Cloud Platform) customers to develop business processes based on automatic analysis of indexed blockchain data, such as SaaS profit sharing, reducing service abuse by layering network participant portraits, and using static Analytical techniques to detect software vulnerabilities and malware.
However, these applications all share a common attribute: they all use encrypted public datasets as input for off-chain business processes.
The following shows how a particular smart contract platform (Ethereum) interoperates with Google’s enterprise cloud data warehouse (BigQuery) via an oracle middleware (Chainlink).
This combination of components allows smart contracts to take action based on data retrieval ranging from on-chain queries to internet-hosted data warehouses. Our case can be generalized as a pattern of cloud/blockchain hybrid applications, where smart contracts can efficiently delegate cloud resources to perform complex operations.
secondary title
How to build it?
At a high level, Ethereum dApps (aka smart contract applications) request data from Chainlink, and Chainlink retrieves data from web services built on Google App Engine and BigQuery.
To retrieve data from BigQuery, a dApp invokes a Chainlink oracle contract and includes payment (e.g., a gas price at a specified point in time) for a parameterized request to be serviced. One or more Chainlink nodes are listening for these calls and, when observing, perform the requested action. External adapters are service-oriented modules that extend the functionality of Chainlink nodes, including authentication APIs, payment gateways, and external blockchains. In this case, Chainlink nodes interact with a dedicated App Engine web service.
After the network service responds successfully, the Chainlink node uses the returned data to call the Chainlink oracle contract, which in turn calls the dApp contract, thereby triggering the execution of downstream dApp-specific business logic. This is depicted in the figure below.
For details on integrating dApps, please refer to the relevant documentation of Google Cloud, which can request data from BigQuery through Chainlink. Gas prices can be viewed by date and block number.
secondary title
How to use BigQuery Chainlink oracles
This section explains how to build useful applications using Google Cloud and Chainlink.
Use Case 1: Prediction Markets
Participants in prediction markets allocate funds to predict future events. This interesting area is largely dominated by smart contract platforms, because as network ecosystems, their value will follow the power law, that is, the winner takes all. Opinions differ on which platform will succeed, and how to quantify success.
By using encrypted public datasets, even complex predictions can be made, such as a recent $500,000 bet on the future state of Ethereum that was successfully resolved on-chain. By retrieving the 1-day, 7-day, and 30-day activity of a certain dApp, it is possible to measure the type, volume, new progress and frequency of dApp utilization, which can be recorded.
These metrics are called daily, weekly, and monthly active users, and are often used by web analytics and mobile app analytics professionals to assess the success of websites and apps.
Use Case 2: Hedging Against Blockchain Platform Risks
The rapid adoption of Decentralized Finance is due to its successful transformation of the existing financial system with a blockchain environment, which is technically more trustworthy and transparent than the existing system.
Financial contracts like futures and options were originally created to reduce/hedge the risks associated with their vital operating resources. Likewise, data about on-chain activity, such as average gas prices, can be used to create simple financial instruments that provide holders with payments when gas prices get too high.
Other characteristics of blockchain networks, such as block times/miner centralization, create risks that dApp developers want to avoid. By providing high-quality data from encrypted public datasets to financial smart contracts, the risk exposure of dApp developers can be reduced. The end result is more innovation and accelerated blockchain adoption.
We document how an Ethereum smart contract interacts with a BigQuery oracle to retrieve gas price data at a specific time. We also implemented a stub of the smart contract option, showing how an oracle can be used to implement a future gas price collateral contract, which is a key input for the dApp to function.
Use case 3: Support submit/reveal in Ethereum using "submarine send"
By using the "submarine" sending method, smart contract users can increase the privacy of their transactions, successfully avoiding their counterparties who want to front-run transactions, making DEX more immediately useful. In this way, malicious behavior such as front-running can be prevented, but it also has limitations, if it does not have oracles to help.
In the absence of an oracle, performing a "submarine send" would cause the blockchain to bloat. Specifically, the EVM allows contracts to go up in chain up to 256 blocks, or about 1 hour. This maximum range limits the practical use of "submarine sending", since it creates unnecessary denormalization when it needs to rebroadcast data. Instead, by using oracles to implement "submarine sending", block bloat is eliminated as the scope of operations increases to include all historical chain data.
secondary title
in conclusion
We have demonstrated how to use the Chainlink service to serve on-chain data from BigQuery encrypted public datasets. This technique can be used to reduce inefficiencies (such as the use case of submarine sending), and in some cases add entirely new functions (such as the use case of hedging risk) to Ethereum smart contracts, and enable new on-chain business models (such as the prediction market use case ).
The essence of our approach is to balance a small amount of latency and transaction overhead for a potentially large amount of economic utility. As a concrete example, a common "submarine send" requires on-chain storage that scales O(n) with blocks added to the blockchain, but if the calling contract waits for an additional two blocks to call the BigQuery oracle , it can be reduced to O(1).
