Trusted Blockchain Oracle Scheme Based on Aggregate Signature

With the development of blockchain technology, more and more applications need out-of-chain data. Thus, blockchain oracles have become an important bridge for transferring data on and off the chain. This paper studies the mainstream blockchain oracles scheme, summarizes the shortcomings of the existing schemes and proposes a new blockchain oracle scheme based on BLS (Bohen-Lynn-Shacham) aggregation signature to ensure that off-chain data can be transferred into the blockchain in a trusted and reliable way. Specifi-cally, the scheme uses multiple blockchain oracles to avoid the single point of failure or even a small number of malicious oracles, and improve the credibility of data. At the same time, it not only uses BLS aggregate signature to reduce the storage cost and communication overhead, but also uses commitment mechanisms to ensure the reliability and authenticity of the data. Be-sides, the simulation results show that the scheme can meet the practical application requirements.


Introduction
Blockchain is a decentralized, unchangeable data ledger [1]. It stores and verifies data through network nodes, which can solve the trust problem between unrelated nodes. Therefore, the blockchain will break the existing business model and infrastructure in many fields. And its distributed, immutable, persistent and other characteristics [2] make it have broad application prospects in the fields of finance, logistics, digital copyright, and public services.
As a special form of data, smart contracts [3] can also be written into the It is worth noting that the blockchain is a deterministic and closed system environment, and no uncertain factors are allowed in smart contracts. Therefore, the blockchain cannot actively obtain off-chain data. In order to overcome the limitations of smart contracts effectively and enable off-chain data to communicate with smart contracts and transfer data, it is necessary to deploy a bridge connecting the real world and smart contracts on the blockchain. The bridge is called blockchain oracle [5]. The user first informs the oracle on the chain of the external data that needs to be obtained through the network request, and then the oracle node obtains the external data through the off-chain API, and finally, the off-chain data will be returned to the user through the oracle. The off-chain data acquisition process [6] of the oracle is shown in Figure 1.
The oracle can be regarded as the only interface for data interaction between the blockchain and the external world, which is particularly important in the construction of the blockchain ecosystem. Take the network transaction system based on blockchain technology as an example. In order to be scalable and reliable, the system not only needs to obtain data on the blockchain efficiently and quickly, but also needs to obtain real data from off-chain or cross-chain data.
Due to the consensus algorithm of the blockchain and the use of a hash algorithm based on the Merkle tree structure, the integrity of the data on the chain is guaranteed. However, because the off-chain data is independent of the blockchain, a specific solution is needed to ensure the reliability and consistency of the off-chain data. In order to broaden the application scenarios of blockchain and ensure the reliability of data on the chain, this article summarizes the advantages and disadvantages of the current mainstream blockchain oracle scheme and proposes a new blockchain oracle based on BLS (Bohen-Lynn-Shacham) aggregation signature. The scheme reduces the storage space of the blockchain while ensuring the credibility of the on-chain data, and proves the practical value of the scheme through simulation experiments. The organization of this paper is as follows: Chapter 2 introduces the current mainstream blockchain oracle scheme, and summarizes its advantages and disadvantages; Chapter 3 introduces the theoretical basis of BLS aggregation signature; Chapter 4 proposes a new blockchain oracle scheme based on BLS aggregation signature, and discusses the security and correctness of the scheme; Chapter 5 conducted experiments on the program, and verified the feasibility of the program through comparison; Chapter 6 summarizes the work of this article and proposes the next research plan.
Provable [5] is an oracle scheme that provides centralized data transmission services for Ethereum, which provides a security guarantee for the data transmission layer of smart contracts. Provable obtains external data from the API or data source specified by the user's smart contract and can prove that the data provided to the smart contract is the correct data obtained from the specified API or data source at a specific point in time, ensuring verifiability and availability of out-of-chain data. However, it is only applicable to unsupported TLS versions (1.1 or lower), and can only be used in Ethereum, which is costly and relies on a single data source. TLS-N [8] is the first oracle scheme based on content extraction signatures. It uses the privacy protection function of Transport Layer Security (TLS) to generate non-interactive session proof based on blockchain smart contracts that can be effectively verified by third parties. TLS-N provides a practical and decentralized blockchain oracle, which enhances the auditability and reliability of web content. When generating a certificate, part of the TLS session (such as passwords, cookies) can be hidden to protect privacy, while verifying the rest of the content. TLS-N is compatible with TLS 1.3, but the TLS-N scheme increases communication overhead and the deployability is poor, which requires some improvements to TLS. It can be understood from previous deployments that the standardization and adoption process of TLS is very slow, so it will take longer time to improve the TLS standard.
Town Crier [9] is a verifiable data supply oracle system based on the Trusted Execution Environment (TEE), using trusted hardware (Intel SGX, Intel Software Guard Extensions) and HTTPS designed a trusted hardware hybrid protocol based on blockchain to solve the limitation of HTTPS lack of digital signature. Among them, Intel SGX's Enclave can encrypt and decrypt data requests from smart contracts or external data from data sources, and securely manage sensitive information. However, Town Crier requires hardware support, highly depends on the trusted execution environment, which is subject to security vulnerabilities attacks against Intel CPU and SGX, such as Foreshadow [12] and Spectre [12].
ChainLink [5] is the first decentralized oracle solution on Ethereum. It combines smart contracts on the chain with distributed data sources off the chain and securely pushes data between smart contracts and APIs through a reputation mechanism and an aggregation model. However, the aggregation cost of distributed data sources is high and the scalability is poor.
Augur [10] is a decentralized and low-cost prediction market platform oracle built on Ethereum. The prediction market is open to the general public, where users vote on information from the outside world. And their voting rights are allocated to different token holders, and the prediction results need to be agreed by a majority of users. Augur's incentive structure is designed to encourage users to remain honest and report accurate results to maximize their profits. However, Augur's consensus mechanism design leads to low prediction efficiency, prediction accuracy is restricted by the scale of the platform, and its uneven distribution of tokens damages the credibility of prediction results.
In general, the current mainstream oracle implementation schemes have the following problems: 1) Single data source. Users need to specify a single data source to obtain external data. If the data source itself is fake or maliciously tampered with, the data returned by the oracle is also wrong; 2) Poor deployment. The solution depends on hardware security or needs to make substantial changes to existing mainstream protocols; 3) High complexity of the scheme. It leads to uneven distribution of incentive mechanism or affects the final result; 4) Limited application scope. The current blockchain can guarantee the integrity of on-chain data. However, it cannot effectively guarantee the consistency of the off-chain data [13]. Besides, although the oracle can help the blockchain to obtain external data, it is still difficult to guarantee the reliability of external data sources [14], and if a single predictor is used, it will lead to centralization, leading to the risk of corruption, malicious and incorrect data generation.
In response to the above problems, this paper combines the mainstream blockchain oracle scheme and proposes an automated, lightweight and accurate blockchain oracle scheme. The solution uses multiple blockchain oracles to avoid single points of failure or even a small number of malicious oracles. The use of BLS aggregated signature reduces block space overhead and communication load. Besides, the method of using commitments to reveal ensures the authenticity of the off-chain data and improves the scalability and reliability based on the blockchain system.

Bilinear Mapping
Let 1 2 , , T G G G each be a multiplicative cyclic group with a large prime number p. Let : be a map with the following properties: 1) Bilinear: For all 1 2 , 2) Non-degeneracy: There exists 1 2 , other words, the map does not send all pairs into the identity in T G .
3) Computability: For all 1 2 , U G V G ∈ ∈ , the polynomial-time algorithm calculation can be found.

BLS Signature Algorithm and Aggregate Signature Algorithm
BLS signature algorithm [15] [16] is a digital signature algorithm constructed on the basis of bilinear mapping, which is mainly divided into four parts: initialization, key generation, signature and verification. BLS aggregate signature algorithm [17] also mainly consists of four parts: initialization, key generation, aggregate signature and aggregate signature verification. Its algorithm initialization and key generation are the same as BLS signature algorithm. 1) Initialization Let 1 2 , , T G G G each be a multiplicative cyclic group with a large prime number p, the generators are 1 g and 2 g respectively. The bilinear pairing is given by x v g G = ∈ , the private key is marked as sk x = , and the public key is marked as pk v = .

3) Signature
A given private key sk is used to generate signatures on the received message M, the signature ( )

Scheme Design
To improve the reliability of external data on the chain and prevent a single point of failure, the scheme uses multiple oracles. The basic framework of the blockchain oracle scheme is shown in Figure 2. When smart contracts need to obtain important external data, such as asset prices in financial derivatives, currency exchange rates for real-time transactions, the flight arrival time for flight delay insurance, and important game results, obtaining data from multiple data sources can improve the accuracy and credibility of the data, but some data sources may be malicious. The existing aggregate signature algorithm cannot exclude malicious signatures. The program will filter the requested data through the commit-reveal method, exclude malicious data sources, and improve the verification efficiency. Finally, the data on the chain is aggregated and signed, which reduces the amount of data on the chain and saves costs. Each oracle can obtain the external data required by the user's smart contract from each external API. The oracle can take the form of subscription or split reward to encourage the external API to return the correct message. This

The Specific Scheme
There are a total of n ( 3 1 n f ≥ + ) oracle nodes in this scheme, and only f oracle nodes are allowed to be malicious. The malicious nodes may have dishonest behaviors, such as invalid signatures or submitting wrong request data.
Step 1. Initialization After the oracle smart contract receives the data request from the user's smart contract, it sends the data request to each oracle, where 1 2 , , T G G G are the multiplicative cyclic groups with the order of a large prime number p, the generators are 1 g and 2 g respectively, and each oracle set the private key Step 2. Signature collection The oracle smart contract is sent to each oracle for query requirements. The oracle requests data from the external API and the external API returns the query data mi to the oracle. After the oracle splices m i and pk i , the oracle gene- f + 1 or more than f + 1 identical external data m, and the consistent data m is obtained.
Step 5. Aggregate signature The oracle smart contract performs aggregation signature to the user smart contract.
Step 6. Incentive The smart contract rewards oracles in the I with valid signatures and correct request data.
The main flow diagram of the scheme is shown in Figure 3.

Security Analysis
In order to analyze and define security [18], suppose there is an adversary who wants to forge a BLS aggregate signature. The security of the BLS aggregated signature scheme is equivalent to that there is no opponent who can forge aggregated signatures within a certain game range. The existence of forgery means that attacker attempts to forge an aggregated signature on a message of his choice through a group of users. In the aggregated key selection security model, adversary is given the ability to challenge the public key and select other public keys. His goal is to forge the existence of the collective signature.
The adversary also gains access to the signing oracle of the challenge key. The specific process is shown in Table 2. His advantage Adv AggSig is defined as his probability of winning in the game.
Note that the scheme does not impact the security of the signature scheme. In other words, the security of the signature is equal to the security of the used signature scheme [19].
Adversary has the ability to generate keys in the key selection model, and there is a potential multi-signature attack [20]. vulnerable to rogue key [21] attacks. rogue key attack is an attack that uses special parameters to make the aggregated signature offset valid parameters  3. Response. Finally, outputs k − 1 additional public keys pk2, …, pkk. Here k is a game parameter, at most N. These keys and the initial key pk1 will be included in the aggregate signature forged by . also outputs messages m1, …, mk, and finally, generates an aggregate signature σ that is signed by k users on their corresponding messages.
4. If the aggregate signature σ is an effective aggregation of messages m1, …, mk under the keys pk1, …, pkk, and σ is nontrivial, i.e., that is, did not request a signature on M1 under pk1, the forger wins. The probability is over the coin tosses of the key-generation algorithm and of .
during the aggregation process. Assuming that the public key of the honest user I is In the scheme proposed in this paper, each oracle sets its own private key, and no private key is transmitted during the interaction. Due to the difficulty of CDH, adversary cannot derive the corresponding private key from the public key. In addition, since the hash value calculated by each oracle contains the public key pk i , each hash value is different, so rogue key attacks cannot be carried out during the aggregation of signatures.

Reliability of Requested Data
The request data returned to the user's smart contract is always reliable. There are a total of ( ) 3 1 n n f ≥ + oracles in the scheme, allowing f oracles to be dishonest, so at least 2f + 1 oracles are honest. Among the 2f + 1 oracles received in the commit phase, at least f + 1 oracles are honest, which is larger than f dishonest oracles, and the number of honest oracles is always greater than the number of dishonest oracles. The reveal stage can always ensure that there are greater than or equal to f + 1 oracles that return the same correct answer. Therefore, the reliability of the data requested on the chain is ensured.

Validity of Aggregate Signature
The aggregated signature is aggregated from the signatures of the oracles that are honest and return the correct data. When the aggregated signature is to be veri-

Correctness of Motivation
The scheme effectively prevents free-riding attacks and ensures that dishonest oracles cannot get rewards. The commit-reveal stage effectively prevents free-riding attacks. A free-riding attack [5] refers to an attack in which a malicious oracle machine directly copies request data obtained by other oracles without spending additional costs to obtain request data and obtain rewards. In this scheme, the oracle does not summit mi in the commitment phase, but submits , ensuring the confidentiality of mi. After the oracle smart contract needs to verify the validity of the signature in the verification phase, the oracle will be classified according to the difference of mi in the revealing phase. If the signature is invalid, the oracle is considered dishonest, and the dishonest oracle will not appear in the reward set D k . The commit-reveal stage ensures that the dishonest oracle is not rewarded and the accuracy of the incentive is guaranteed.

Experimental Analysis
The experimental test runs in the Ubuntu 18.04 environment, and the specific configuration is Intel(R) Core(TM) i5-4210M CPU @ 2.60 GHz, 4 GB memory.
In order to verify the practical value of the scheme in this paper, the experiment mainly tests the performance of BLS aggregated signatures and the performance of multiple oracles. The experiment compares different signature schemes and tests the gas consumed by different signature schemes. After the smart contract is compiled on Remix, it is deployed on the Geth node of the Ethereum private chain for testing. Besides, gas is the count of the internal workload of the Ethereum virtual machine. All transactions, execution of smart contracts, or data storage all need to consume gas. The currency used by Ethereum is ETH, and the unit of gas is wei, 1 ETH = 10 18 wei. Figure 4 shows the average time consumption of each phase of the BLS signature. It can be concluded that the verification phase of the BLS signature consumes the most time, followed by the signature phase, and the least time-consuming phase is the aggregation signature. The signature phase includes the initialization of the signature algorithm and the completion of the signing of the message.
The total time of a BLS signature corresponds to the main time of actual operation of a blockchain oracle. Since in practical applications, the number of oracles is directly proportional to the amount of incentives, in order to balance  costs and ensure data reliability, the scheme needs to select an appropriate number of oracles according to the actual situation. When the number of oracles is equal to fifty times, the total time is 393.7 milliseconds, which proves that the scheme has relatively high feasibility. Refer to Table 3 for detailed data on the time-consuming of each stage and total time-consuming of the BLS aggregation signature. Figure 5 shows that the gas consumed by each scheme increases with the increase of the number of oracles, and the two show a certain linear relationship. Among them, BGLS is a BLS aggregation signature scheme with the lowest cost, but it cannot detect malicious oracles. BGR is a trapdoor permutation-based aggregate signature scheme proposed by Brogle et al. [22], which can be regarded as an aggregation variant of RSA. The disadvantage of BGR is that the aggregated signatures are created in sequence, which makes this scheme not suitable for application scenarios with multiple oracles. The solution in this paper is a fault-tolerant BLS aggregation signature. It is necessary to verify each BLS signature one by one before aggregation. The increase in the number of oracles will increase the number of finite field multiplications and pairing operations of two points, so the consumption of gas will be more than the BLS aggregation signature scheme. TLS-N can generate non-interactive session proofs based on blockchain smart contracts that can be effectively verified by a third party, effectively ensuring the correctness of the data on the chain, which consumes the most gas. The data measured by the smart contract is platform-independent. It can be compiled once and can be executed in various systems. Due to the computer's scheduling, a certain degree of error will be caused, but the overall gas consumption is basically the same. The gas consumed by the scheme in this paper is between BGR and TLS-N, but BGR needs to create signatures in order [23], which is not suitable for application in multi-oracles scenarios. Although TLS-N can provide verifiable proof of the data on the chain, it consumes much more gas than the scheme in this article. Therefore, according to the gas consumed by each scheme, the fault-tolerant BLS aggregation signature blockchain oracle scheme proposed in this paper has practical value.
It can be seen from Table 4 that the size of the BLS aggregation signature BGLS is fixed, and the size of the aggregation signature is equal to 160 bits, which has nothing to do with the number of oracles. Compared with Elliptic Curve Digital Signature Algorithm (ECDSA) signatures that cannot aggregate the signatures of the same message, BLS signature aggregation can aggregate the signatures of the same message and occupies a small space, and it is a completely deterministic signature algorithm. Because the BLS signature space is small, the gas consumed for storing BLS signatures is less than the gas consumed for storing  RSA signatures. But in terms of signature verification, the gas consumed to verify RSA signatures is less than that of BLS signatures, and the gas consumed to verify ECDSA signatures is lower. This is mainly because the cost of restoring the ECDSA public key is lower and related operations have been encapsulated into functions on Ethereum. However, since Ethereum recently accepted the improvement proposal (EIP 1108 [23]), this may significantly reduce the operating costs of BLS and BGLS. In summary, the blockchain oracle scheme that uses BLS signatures to aggregate signatures has certain advantages. Its aggregate signature space is small, which can save block space and reduce communication between blocks. In the future, the gas consumption of BLS and BGLS operations on Ethereum will be reduced.

Conclusions
In order to realize a large-scale blockchain-based network transaction system with scalability and reliability, the blockchain must be inseparable from off-chain data in specific application scenarios. The paper proposes a novel blockchain oracle scheme, which reduces the block space overhead and blockchain network load under the condition that the aggregated signature takes up a small space and less interaction, and ensures the consistency of the data on the chain and off the chain. In addition, the scheme can avoid single points of failure or even a small number of malicious oracles, ensuring the consistency of data on and off the chain. The experiment results show that the scheme has high practical value. The blockchain oracle can solve the problem of blockchain access to external data. It does not destroy the decentralization of the main chain. Therefore, under the premise of privacy security, it guarantees the strong correlation of the data on the chain and off the chain, and ensures the credibility and authenticity of external data sources.
Future research work mainly includes the following three aspects: 1) We will improve the BLS aggregated signature scheme or find other aggregated signature schemes to improve the security of aggregated signatures while reducing the complexity of operations.
2) We will combine the threshold scheme to optimize the BLS signature, to further simplify the interaction between the oracle and the smart contract.
3) According to the difference and importance of the data source, we will study the blockchain oracle schemes with different fine-grained trust mechanisms.