Hardware Based Secured Privacy Preserving Computation System for Three-Dimensional Data

: Three-dimensional (3D) data are easily collected in an unconscious way and are sensitive to lead biological characteristics exposure. Privacy and ownership have become important disputed issues for the 3D data application ﬁeld. In this paper, we design a privacy-preserving computation system (SPPCS) for sensitive data protection, based on distributed storage, trusted execution environment (TEE) and blockchain technology. The SPPCS separates a storage and analysis calculation from consensus to build a hierarchical computation architecture. Based on a similarity computation of graph structures, the SPPCS ﬁnds data requirement matching lists to avoid invalid transactions. With TEE technology, the SPPCS implements a dual hybrid isolation model to restrict access to raw data and obscure the connections among transaction parties. To validate conﬁdential performance, we implement a prototype of SPPCS with Ethereum and Intel Software Guard Extensions (SGX). The evaluation results derived from test datasets show that (1) the enhanced security and increased time consumption (490 ms in this paper) of multiple SGX nodes need to be balanced; (2) for a single SGX node to enhance data security and preserve privacy, an increased time consumption of about 260 ms is acceptable; (3) the transaction relationship cannot be inferred from records on-chain. The proposed SPPCS implements data privacy and security protection with high performance.


Introduction
With the rapid development of internet technology, three-dimensional (3D) geometry models of real-world objects have been employed to collect anthropometric data for many application scenarios. 3D model reconstruction has become an important business method for merchants to attract customers [1][2][3][4][5]. Massive 3D data emphasizes challenges around storage, management and computation. In traditional, the related services of 3D data are deployed in high-performance centralized servers [6,7]. However, the trusted third party with a large capacity and powerful computation inevitably inherits the single-point attack problems, which cannot preserve the security and ownership of stored data. Without the data owner's approval, such attacked data can be applied to proliferate huge commercial profits by unauthorized organizations [8]. Moreover, data owners have no awareness about how important their personal data is. For example, the refined 3D model reconstruction reveals personal information, including sex and appearance [9][10][11][12][13][14][15]. 3D sensitive data confirmation, security and privacy problems have attracted extensive attention. The cryptographic technique is considered as an effective scheme to relieve pressure from the demand of data privacy and security protection in traditional cloud scenes [16][17][18][19][20][21][22][23][24]. However, these methods have poor performance for centralized single point of failures and complex computation.

•
Hierarchical separation computation: The SPPC system adopts a hierarchical architecture: computation off-chain, storage off-chain and consensus on-chain. TEE performs critical data computation and attests to correct and complicated execution off-chain. Distributed data storage, independent from consensus and computation, provides secure and large-capacity storage. On-chain nodes are responsible for maintaining a consistent global state and performing consensus updates efficiently. • Data leverage scheme: Data expectation matching is realized by similarity computation of registered data text attributes with a graph structure. According to reputation value, the graph structure could be altered. Moreover, the registered costs should affect data provider ranking in a similarity computation list. In this way, the SPPCS voids network resource consumption caused by invalid transactions effectively. • Dual hybrid isolation model: To obscure the connection between the sender and receiver of a transaction, we design a transaction isolation model based on the TEE leader scheme. The TEE leader completes the transactions with the sender and the receiver asynchronously to cover up the direct relationship, which can avoid privacy Electronics 2021, 10, 1546 3 of 29 exposure issues caused by individual identity disclosure. To prevent access the all the original data, we also construct another hybrid model based on non-accessible attributes of TEE. Data requesters obtain computation results instead of accessing original data to preserve data confidentiality.
The rest of this paper is organized as follows: we present the related work of privacypreserving management in Section 2. Section 3 introduces the preliminaries throughout this paper. Section 4 details the architecture of SPPCS and specific implementation process. The experimental performance evaluation is conducted in Section 5. Section 6 analyzes the security and privacy of SPPCS proposed in this paper. Conclusions and discussions are presented in Section 7.

Privacy with Principles
In the early stage when it was realized that privacy protection is necessary for 3D sensitive data, various rules and constraints imposed by humans have been proposed [45,46]. To alleviate the embarrassment from body data collected with 3D devices, Golden et al. [45] stipulated that 3D data acquisition and analysis should not be performed in the same space. Moreover, 3D data machines cannot store sensitive data to avoid privacy leakage problems. Mironenko et al. [46] described some countries that defined 3D data protection legislation in a formal way, including transparency, individual participation, purpose specification and limitations, minimization, data quality and integrity, security and accountability and auditing. However, these principles were performed through restricting people and should not be considered as a panacea in privacy protection.

Network Implementation in Privacy Protection
Methods were proposed to mitigate the invasion pressure of 3D sensitive data storage and transformation over a network. Zuo et al. [47] proposed a two-factor secret key protection mechanism combined with attribute-based fine-grained access control to protect the confidentiality of shared sensitive data. Madankar et al. [21] utilized a cryptography method to preserve the privacy of biometric data. Jung et al. [48] designed an accountability model, AccountTrade, to prevent dishonest behavior, such as reselling others' datasets. Bindahman et al. [9] discussed the privacy problems produced by 3D body scanning technology and described the key points of a privacy-preserving framework. Wang et al. [10] proposed a time machine-like method to relive experiences with virtual reality and protect individual privacy in virtual worlds. Sekhavat et al. [13] utilized augmented reality devices to watch physical wearing with the human alternative mode. Compared with standing in front real cameras, this method can protect human body privacy.
Some filters and deep learning methods have been proposed to protect sensitive data privacy. Without image restoration, Wang et al. [49] proposed a coded aperture camera system with lens-free and a training mechanism to recognize human action in a privacypreserving way. Sarwar et al. [50] designed an adaptive space exploration to configure the privacy filter automatically, which reduces face resolution to preserve privacy. Chriskos et al. [51] utilized the singular decomposition method and proposed image projection on hypersphere methods to identify the individual rather than accessing the face data for identification. Yu et al. [52] developed a feature-based approach with AlexNet and designed an object-based approach with a deep learning classifier. Through configuring fine-grained settings, the approach could protect data privacy. Li et al. [53] proposed a deep convolutional neural network with k-anonymity, l-diverse and t-closeness to protect face privacy. However, training data become available to be exposed for malicious users who can access these data. Li et al. [12] designed a deep convolution neural network to remove sensitive 3D information and utilized a GAN-based generative adversarial network framework to synthesis models for parameter extraction. Xue et al. [20] presented a privacy-preserving method through which sensitive data can be stored and analyzed on any untrusted device through bloom filters, which could defend the privacy leakage from Electronics 2021, 10, 1546 4 of 29 original data at the storage level. Based on encrypted face features, encrypted machine learning parameters and additive secret sharing secret, Ma et al. [11] proposed a lightweight adaptive boosting face recognition method to protect facial data privacy.
Nevertheless, all the methods mentioned above are based on centralization, which neither solve the problem of privacy leakage caused by a single point of failure nor the data resale and repeated use without the knowledge of the data owner.

Peer-to-Peer Technology
Kim et al. [54] designed a decentralized data platform for 3D point clouds to share efficiently and securely through a Dat protocol and a discrete global grid system. However, this platform cannot ensure the confidentiality of data use. With peer-to-peer (P2P) technology, 3D sensitive data privacy protection research still needs to be explored in depth. However, there have been many research activities to solve the privacy of sensitive data problem with blockchain in other fields.
Wang et al. [55] proposed a fine-grained access control decentralized storage framework based on blockchain. The security and privacy of stored data are enhanced by a public key encryption mechanism. This general method is not fully suitable in 3D data privacy protection, due to the inevitableness of reselling and accessing original data.
In internet of things (IoT) data security field, Lu et al. [56] proposed a blockchain-based federated learning framework to maintain data privacy. However, the training sets could reveal some original data privacy, which is fatal to 3D sensitive data.
Howard et al. [29] proposed a decentralized computation platform, Enigma, to prevent accessing raw data, based on blockchain technology. Al-Zahrani et al. [8] used blockchain and Data as a Service (DaaS) to construct a privacy-preserving data sharing model, which preserved the data controllability for data owner. Thus, this model cannot guarantee the data traceability and quality estimation for the data user.
For electronic medical data privacy problems, Zheng et al. [57] introduced a wearable healthy data sharing system based on blockchain to enable users to easily control and securely share their sensitive data. Yaji et al. [58] presented MeDShare, a blockchain-based system to provide medical data provenance, auditing and access control on untrusted parties. MeDShare revoked offending entities rights to access data in case of violation activities detected, with minimal risk to privacy exposure. Al Omar et al. [59] proposed a blockchain-based privacy-preserving platform for healthcare data, which leveraged pseudonymity of cryptographic functions to protect sensitive data privacy. These solutions cannot avoid various problems caused by accessing raw data. In addition, when anonymity is no longer secure in the real world, it will lead to identity exposure and pose challenges for privacy protection.
Among digital currencies, Li et al. [30] provided a privacy data storage protocol to preserve identity privacy in blockchain applications, based on the complete anonymity of the ring signature. BlockMaze, proposed by Guan et al. [31], an account-model blockchain that hided the linkage between transaction amounts and the sender-recipient. Along with dual balance model implemented by zk-SNARKs, BlockMaze has strong privacy guarantees. Although these cryptography functions provide users with greater privacy, they are not suitable for massive 3D data with overhead computation.
The idea of combining blockchain and TEE has been focused on the privacy preservation in data computation. Cheng et al. [38] proposed Ekiden, a system combined blockchain with TEE technology to separate the consensus from heavy computation and preserve data confidentiality. Similarly, Zhang et al. [35] leveraged blockchain as information interaction medium on-chain and utilized TEE off-chain computation to design Cerberus, which can guarantee privacy and efficiency of data procession. Dai et al. [34] designed SDTE, a blockchain-based data trading ecosystem to prevent dishonest activities in trading platforms. In SDTE, only analysis results can be obtained and the raw data cannot be accessed. Based on the blockchain and TEE, Wang et al. [36] proposed Hybridchain to improve execution efficiency through decoupling smart contract computation from consensus. A secure key-value memory system has been designed in Hybridchain to mitigate TEE memory limitations. Maddali et al. [37] presented VerBlock, a blockchain-based framework combined with TEE technology, to reduce endorsements in enterprise blockchains. Zhang et al. [39] presented an electronic voting system to protect the privacy of voters and votes based on Ethereum, smart contracts and the TEE environment. These proposals did not notice the identity leakage of the IP address associated with the owner/requester of data, whereas the pitfall should be considered to design 3D privacy protection schemes.
Although blockchain has excellent performance in data security, data auditing and sensitive data privacy protection, some immature defects, such as low scalability, doublespending attack and quantum algorithms in breaking cryptographic cracking, limit the wide application of this technology.

Preliminaries
In this section, we briefly discuss the relevant background knowledge throughout this paper.

Blockchain
As a tamper-resistant distributed ledger technology, the blockchain is linked together through cryptographic hashes as blocks and chains. The block on-chain record batches of valid transactions and processes with an iterative hash value confirmation of the previous block to original genesis block, which defends data modification effectively. In the blockchain system, all members can trust each other in a non-secure environment. The blockchain technology has been applied in decentralized cryptocurrency successfully, such as Bitcoin, Ethereum, Zcash, etc. Moreover, the development of smart contracts over the blockchain, especially Ethereum, contributes to performing trust governance in medical, identity management, asset management, and supply chain fields, etc.
The smart contact is written by Turing-complete programming languages and executed transparently in accordance with the code written on all block nodes. Ethereum supports a stack-based Ethereum Virtual Machine (EVM) to execute smart contacts. A smart contract should be considered as a contact account, which can be executed similarly with users' send transactions to the normal account. The GAS is introduced to limit the transaction overhead and avoid the infinite loop of smart contract execution.
Asymmetric cryptography, as the cornerstone of blockchain, contains a key pair public/private key. The data are encrypted with a public key and decrypted using a private key. The data signature is signed with a private key and validated by the corresponding public key. The public key is usually shared publicly, whereas the private key is only known to the owner. It is impossible for anyone to infer the private key from the public key and vice versa, which is guaranteed by the security of the encryption algorithm.

IPFS
An Inter Planetary File System (IPFS), as a decentralized storage structure, is a contentaddressed distributed network that stores large amount of data easily without any central coordinators [60]. The file stored in IPFS is recognized with a unique cryptographic hash, which can be identified by version-control history to remove duplication. IPFS facilitates concurrent access to stored data with a high-throughput performance.

Trust Hardware with SGX
The trust hardware relies on chip isolation to create a trusted execution environment (TEE) to prevent unauthorized access from tampering with or learning the inside state. Software Guard Extensions (SGX) is integrated into CPU architecture designed by Intel and has to be the most prominent TEE technology [61]. SGX preserves the confidentiality, security and integrity of sensitive data operation by creating a secure container enclave. The interfaces of enclaves could be defined at the initialization phase, after which the internal content will not be modified. The access control of SGX is shown in Figure 1.
Software Guard Extensions (SGX) is integrated into CPU architecture designed by Intel and has to be the most prominent TEE technology [61]. SGX preserves the confidentiality, security and integrity of sensitive data operation by creating a secure container enclave. The interfaces of enclaves could be defined at the initialization phase, after which the internal content will not be modified. The access control of SGX is shown in Figure 1. SGX provides local attestation and remote attestation to help remote entities verify whether the particular code is executed inside the enclave securely and correctly. Local attestation is used by enclave A to prove its identity to enclave B directly, with the same platform key. The enclave uses remote attestation to provide proof to different platform enclaves. At first, the quota enclave encrypts its contents with a hardware-protected enhanced private ID (EPID) key to construct the QUOTE structure, which is attested by remote enclaves on other platforms. Then, the remote enclave verifies the validity of the quote through IAS, which only permits the legitimate entity to issue remote attestation requests. The content received from the remote enclave can be decrypted with a group public key. After checking the validation hash value which summarizes the code and initial data, the validity results will be sent back to the original enclave.
The enclave in SGX uses sealing instructions to store sensitive data outside or read sealed data into secure memory, which greatly reduces the overhead of secure memory. Two sealing strategies have been supported in SGX: sealing data with a platform key permit other enclaves to access data on the same platform; sealing data use a special key that prevents sharing data with other enclaves on the same platform.

Graph Sturcture
The semantic text clustering methods based on graph structure has been researched and developed in depth for decades [56,[62][63][64]. In the graph structure, the weight-graph is considered as the most common way of representing a correlation in text content. . For graph structure , and * , if * ⊆ , * ⊆ , and no any other graph structure | * * |> | * |, the * should be considered as the maximum common sub-graph between and . The maximum common sub-graph contains information of nodes and edges, which can reflect the similarity in different graphs to cluster context categories into different groups. SGX provides local attestation and remote attestation to help remote entities verify whether the particular code is executed inside the enclave securely and correctly. Local attestation is used by enclave A to prove its identity to enclave B directly, with the same platform key. The enclave uses remote attestation to provide proof to different platform enclaves. At first, the quota enclave encrypts its contents with a hardware-protected enhanced private ID (EPID) key to construct the QUOTE structure, which is attested by remote enclaves on other platforms. Then, the remote enclave verifies the validity of the quote through IAS, which only permits the legitimate entity to issue remote attestation requests. The content received from the remote enclave can be decrypted with a group public key. After checking the validation hash value which summarizes the code and initial data, the validity results will be sent back to the original enclave.
The enclave in SGX uses sealing instructions to store sensitive data outside or read sealed data into secure memory, which greatly reduces the overhead of secure memory. Two sealing strategies have been supported in SGX: sealing data with a platform key permit other enclaves to access data on the same platform; sealing data use a special key that prevents sharing data with other enclaves on the same platform.

Graph Sturcture
The semantic text clustering methods based on graph structure has been researched and developed in depth for decades [56,[62][63][64]. In the graph structure, the weight-graph is considered as the most common way of representing a correlation in text content. A weight context graph G = {N, E, V} consists of N, the set of nodes ({n 1 , n 2 , . . . , n m }), E, the set of edges (E ⊆ N * N, e 12 , e 13 , . . . e ij , . . . , e mn ), and V, the weight adjacency matrix v e 12 , v e 13 , . . . v e ij , . . . , v e mn . The weight V e ij of the edge denotes the correlation degree between the nodes n i and n j . If G = {N , E , V } is the sub-graph of G, denoted as G ⊆ G, G meets N ⊆ N and E ⊆ E ∩ (N × N ). For graph structure G 1 , G 2 and G * , if G * ⊆ G 1 , G * ⊆ G 2 , and no any other graph structure |G * * |>|G * | , the G * should be considered as the maximum common sub-graph between G 1 and G 2 . The maximum common sub-graph contains information of nodes and edges, which can reflect the similarity in different graphs to cluster context categories into different groups.

The Proposed SPPCS Overview
In this section, we detail the scheme design of SPPCS. As described in Figure 2

System Framework
The corresponding description of each entity in Figure 2 is shown as follows: • DP: The unity owns sensitive data. In our system, DP can register data attributes, individual reputation value and expected unit price with the smart contracts. • DR: The users who require data from DP for their purposes perform three tasks in TCP to preserve data privacy. (1) After DRs broadcast demands on-chain, data matching analysis requirement should be delegated to TCP off-chain. (2) DRs obtain requirement matching list results from TCP and the results verification will be published on-chain. (3) DRs conduct hybrid transaction with DPs through TCP on-chain. • EB: Consensus nodes of EB are responsible for maintaining the consistency of data transaction records on-chain and validating state updates with the TEE attestation. EB in SPPCS also acts as an interaction medium among DP, DR and TCP.

Notation Description
Pk id_role the public key for id_role, which can be one of DP, DR, TN, TN enclave and CN Sk id_role the private key for id_role, which can be one of DP, DR, TN, TN enclave and CN Rep id_role the reputation, id_role can be one of DP, DR and TN EPrice id_role the expected price for id_role, which can be DP, DR and TN K id_role the symmetric key used for id_role, which can be original DP data and DR computation code RMResult id_role the requirement matching analysis result for id_role, which can be normal result list and serialized result list Store id_role the storage methods of id_role, which can be seal and unseal

System Framework
The corresponding description of each entity in Figure 2 is shown as follows: • DP: The unity owns sensitive data. In our system, DP can register data attributes, individual reputation value and expected unit price with the smart contracts. • DR: The users who require data from DP for their purposes perform three tasks in TCP to preserve data privacy. (1) After DRs broadcast demands on-chain, data matching analysis requirement should be delegated to TCP off-chain. (2) DRs obtain requirement matching list results from TCP and the results verification will be published on-chain.
(3) DRs conduct hybrid transaction with DPs through TCP on-chain. • EB: Consensus nodes of EB are responsible for maintaining the consistency of data transaction records on-chain and validating state updates with the TEE attestation. EB in SPPCS also acts as an interaction medium among DP, DR and TCP. • DS: IPFS, as a typical representative of DS, provides a safe and large-capacity storage. SPPCS utilizes IPFS to separate storage from consensus and computation. The IPFS receives encrypted data and returns location indexes.
• TCP: Trusted computation nodes, with SGX-enabled CPU and bios, should be considered as the core of TCP. These trusted nodes conduct delegated requirement matching computations, hybrid transactions and data analysis computations with REE and TEE. REE supports interaction interfaces between on-chain and off-chain. TEE guarantees confidentiality in the data process with SGX remote attestation, SGX seal and unseal and cryptographic methods. The delegation request is sent to TCP and the trusted computation node queries related information and executes the corresponding analysis. The trusted computation node securely stores the results outside the enclave with SGX seal, otherwise the reads seal data into the enclave with SGX unseal. Simultaneously, the trusted computation node sends execution results to EB for verification by SGX remote attestation and cryptographic methods. A quorum of trusted computation nodes run a hybrid transaction protocol to complete transactions and obscure the relationship between DR and DP.

Data Leverage Scheme
DR can verify whether the potential data of DP meets expectations, through delegating a data requirement computation to trusted nodes of TCP. Inspired by [63], we convert data matching analysis to compute the similarity graph structures. We denote the attribute item of required data as text T = {t 1 , t 2 , . . . , t n } and the data attribute of DP nodes registered onchain as a set of text items N = {n 1 , n 2 , . . . , n m }, where t n represents the n index keyword to describe required data and n m represents the m index data attribute expression of a DP node. The value of n m is defined as the product of occurrence frequency in T and DP node reputation, calculated as Equation (1): where Num(n m ) is the number of n m occurrences times, T num is the number terms of T, NR(n m ) is the normalized reputation of n m . The semantic relationship between two nodes of N is represented as E = e 12 , e 13 , . . . e ij , . . . , e mn , where e ij is the edge of n i and n j . With the weight value of edges being represented as V = v e 12 , v e 13 , . . . , v e ij , the calculation formula is as Equation (2): where Value n i+j is the co-occurrence of n i and n j in T. All DP node attribute descriptions into are represented in the weighted graph G = {G 1 , G 2 , . . . , G n }, of which the maximum common sub-graph sets can be constructed. For G 1 and G 2 , the maximum common sub-graph SG 12 consists of all co-occurrence nodes and their similarity nodes, where v e ij exceeds the threshold weight value. The similarity of G 1 and G 2 can be calculated as Equation (3): where Num(SG 12 ) is the number of co-occurrence nodes between G 1 and G 2 , Num max (G 1 , G 2 ) is the max number of nodes in G 1 and G 2 . We extend Equation (3) to obtain all nodes' similarities in G, denoted as SG = SG 12 , SG 13 , . . . , SG ij , . . . , SG mn , and leverage the k-means algorithm to cluster DP nodes into different attribute sets. The DR data matching list is composed of DPs above the similarity threshold value.

Workflow of SPPCS
The workflow of SPPCS is divided into three phases: register phase, requirement matching computation phase, and hybrid transaction execution phase. In this paper, we do not take pitfalls arising from TEE into consideration, since many mitigations have been proposed to protect the security and availability of TEE [65,66]. For simplicity, we implement the credible reputation scheme in [43] and assign tasks to selected trusted nodes.

1.
Register Phase In SPPCS, the DP, DR and trusted node (TN) should register entity information on EB with a smart contract, respectively. DR data requirement, DP data attribute, DP reputation, DP data quality estimation, TN reputation, TN expected prices and TN type should have been recorded on-chain. The main activities of this phase are initialize attestation, leader selection, attribute and requirement description, data storage and pre-estimation and registration. The registration steps are detailed in Figure 3.

Requirement Matching Phase
As the driver of SPPCS, data requirement contracts of DR are broadcast on-chain. Similar to SDTE [34], appropriate TNs need to be selected to conduct the requirement matching analysis. The main contents of this stage, shown in Figure 4, are as follows: (a) Delegation protocol: Corresponding to step 1 to step 4 in Figure 4, the DR broadcast requirement via blockchain starts the process of requirement matching analysis. ) can the node be a candidate. According to a combination strategy of higher and lower with the shortest response time, the DR publishes _ candidate nodes on-chain and deposits double either of the _ TNs expected. (b) Requirement analysis off-chain: According to the _ TNs selected by DR, these TNs first run an information synchronization protocol, such as Gossip, to maintain consistency of computation results.
Step 5 in Figure 4 presents the potential DP and establishes a secure channel with any one of the selected TNs recorded on-chain to send encrypted with , denoted as (  (a) Initialize attestation: The Ellipse Curve Cryptography (ECC) key pair of the DP, DR, TN, TN enclave and consensus node (CN) are denoted as < Pk id_role , Sk id_role >, where Pk is the public key, Sk is the private key and id_role is one of DP, DR, TN, TN enclave and CN. The TN initializes reputation Rep TN , node type Ptype TN , enclave public key PK Enclave and expected price EPrice TN . Similarly, the DP initializes reputation Rep DP and estimates the quality of own data Data pre_est . (b) Leader selection: Ptype TN can be set that is normal or complex, with a normal default value. Different Ptype TN TNs have different EPrice TN ranges and only complex Ptype TN TNs can perform hybrid transactions and run a leader election protocol. Complex Ptype TN TNs, with much higher upper limit EPrice TN values, consist of a complex trusted node pool (CTNP), where the winner in each round of elections updates the leader management smart contract. The term of the leader node is determined by reputation and the successful transactions number. The leader reputation is influenced by DR comments and the successful transaction rate. The number of successful transactions increased by one with a smart contract triggered by the DR validation. The smart contract records the reason for leader re-election, which takes place in these scenarios: 1 the number of successful transactions reaches a set value; 2 the leader node reputation value is lower than the set value. When DPs notice the leader node is inconsistent with the DR transaction period, DPs can continue transaction for reason 1 and reject it for reason 2 . (c) Attribute and requirement description: DPs extract data characteristics into text-item sets T attri , such as data type, data amount, unit price, etc. Moreover, DP creates a unique signature notion (USN), defined as DP signature of the keyword hash value Sig Sk DP (Hash(dp_word)), where the keyword is designated by the DP. DR converts the demand into keyword sets T req including required data description, expected size, bid price, required number of TN Num_TN req and unit delegation fee. (d) Data storage and pre-estimation: DP generates a one-time symmetric key K store to encrypt original data Enc K store (ori_data) in each round of transactions. Enc K store (ori_data) should be uploaded to IPFS and DP obtains the corresponding location index loc_index.
DR publishes the quality evaluation code Code_est of required data, based on which all DPs pre-estimate the data matching value Data pre_est . (e) Registration: DR releases the delegation register contract rdrc designed in next Section 4.4 to broadcast T req , Hash(Code_est) and Code_est loc_index . DP and TN complete registration by using the corresponding smart contracts. DP registers the contract prc records T attri hash value Hash(T attri ), USN and Data pre_est . DP information management contract pimc mainly contains Rep DP on-chain. TN register contract nrc includes Pk enclave , Ptype TN , EPrice TN and TN leader. Rep TN and the transaction number tran_num are registered in TN information management contract timc.

Requirement Matching Phase
As the driver of SPPCS, data requirement contracts of DR are broadcast on-chain. Similar to SDTE [34], appropriate TNs need to be selected to conduct the requirement matching analysis. The main contents of this stage, shown in Figure 4, are as follows: (a) Delegation protocol: Corresponding to step 1 to step 4 in Figure 4, the DR broadcast requirement via blockchain starts the process of requirement matching analysis. The TNs first notice the DR demand contract rdrc and establish secure channels to reply to DR with a TN signature Sig Sk TN (Hash(Rep TN , EPrice TN ), Enc Pk DR (Rep TN , EPrice TN )) pre-emptively. When DR receives a response node, it conducts an SGX remote attestation to validate TEE platform. Then, the DR verifies the signature of TN Sig Sk TN (Hash(Rep TN , EPrice TN ), Enc Pk DR (Rep TN , EPrice TN )) with Pk TN and decrypts Enc Pk DR (Rep TN , EPrice TN ) with Sk DP .
Only if Hash(Rep TN , EPrice TN ) equals Hash(Dec Pk DR (Enc Pk DR (Rep TN , EPrice TN )) can the node be a candidate. According to a combination strategy of higher Rep TN and lower EPrice TN with the shortest response time, the DR publishes Num_TN req candidate nodes on-chain and deposits double either of the Num_TN req TNs expected. (b) Requirement analysis off-chain: According to the Num_TN req TNs selected by DR, these TNs first run an information synchronization protocol, such as Gossip, to maintain consistency of computation results.
Step 5 in Figure 4 presents the potential DP and establishes a secure channel with any one of the selected TNs recorded on-chain to send T attri encrypted with Pk enclave , denoted as Sig Sk DP (Enc Pk enclave (T attri )). The selected TNs verify the identity of DP with Pk DP and then Dec Sk enclave (Enc Pk enclave (T attri )) to compare the consistency between Hash(Dec Sk TN (Enc Pk encalve (T attri ))) and Hash(T attri ) in prc. In particular, Dec Sk enclave ensure T attri is validated and executed in the TEE environment. If the previous two hashes have same value, TNs share validated T attri in ciphertext and then execute further computations in enclaves with the graph structure Graph N attri text , E attri , V weight_attri text . It is assumed that the requirement matching analysis result list and corresponding hash value are denoted as

Then,
TNs sign encrypted final results with Sk TN and send Sig Sk TN Enc Pk DR (< Hash(RMResult List_TN , RMResult serialized_List_TN >)) to DR through the OCALL method in step 7 of Figure 4. DRs are unable to obtain the information of DP from RMResult serialized_List_TN . (c) Execution result validation: Corresponding to step 6 in Figure 4, the smart contract recognizes the final computation result with Num_max of < Hash(RMResult List_TN ), Hash(RMResult serialized_List_TN ) >, where Num_max is the maximum occurrence number and is more than Num_TN req /2. When DR receives a response node, it conducts SGX remote attestation to validate the TEE platform, as shown in step 8 of Figure 4. Then, the DR utilizes Pk TN to check whether Sig Sk TN Enc Pk DR (< Hash(RMResult List_TN , RMResult serialized_List_TN >)) is from published TNs and validates the consistency between received Hash(RMResult List_TN ) and Hash(RMResult List_TN ) on-chain to ensure no tampering. In step 9 of Figure 4, the DR also considers the maximum occurrence number of < Hash(RMResult List_TN ), RMResult serialized_List_TN > as the validation result. When the final computation result is recognized by the smart contract as the same with the DR validation result, the smart contract is triggered to provide TNs with the correct computation and return extra change for DR with the reputation feedback received.
is the maximum occurrence number and is more than _ /2. When DR receives a response node, it conducts SGX remote attestation to validate the TEE platform, as shown in step 8 of Figure 4. Then, the DR utilizes to check whether

Hybrid Transaction Phase
In this phase, the essence characteristic can be presented as a proxy execution and pre-payment computation, as described in Figure 5.

Hybrid Transaction Phase
In this phase, the essence characteristic can be presented as a proxy execution and prepayment computation, as described in Figure 5. In step 1, DR sends a selected transaction SNN, USN and deposits double the ether of the (DPs + TN leader) expected value via smart contract, according to RMResult serialized_List_TN and CTNP leader state registered on-chain. Moreover, DR places hash of computation code Hash(code_comp), encrypted code location Enc Pk enclave (code_comp loc_index ), and encrypted symmetric key Enc Pk enclave K code_comp onchain with a computation contract. Leader REE retrieves information on-chain and utilizes ECALL to send each item, SNN, USN, Hash(code_comp), Enc Pk enclave (code_comp loc_index ) and Enc Pk enclave K code comp into TEE, where the items are packed into an unvalidated transaction list.
Step 2 and step 3 present corresponding DPs, which verifies the TN leader from TN register contract and creates a session key to transmit transaction identity proof Enc Pk enclave (Sig Sk DP (dp_word)) to the leader node. Then, in step 4, the TN leader TEE verifies hash of dp_word with USN and the validated DP is noticed by the leader REE via the OCALL method.
Step 5, the TN leader REE sends Enc Pk DP (SNN, USN) and deposits a double DP expected price on-chain with a smart contract. In step 6, DP sends Enc Pk enclave (loc_index), Enc Pk enclave (K store ), Hash(loc_index) and Hash(ori_data) on-chain for TN leader verification. Simultaneously, the TN computation contract pays a remuneration for DP. Then, the TN leader selects appropriate DP data for the DR code following these rules: 1 One-time execution: the TN leader loads all DP data to conduct a computation and obtain all rewards at once, with all selected DPs responding. 2 Multiple execution: According to the number of items in the selected transaction list, item_num is even or odd, the TN leader could load responding DP data in batches to process with the DR code. If item_num is even, the TN leader should select an appropriate even number of responding DP data each time, where the appropriate even number is less than item_num. If item_num is odd, the TN leader first selects a responding DP data number greater than 1 (3, 5, 7 . . . ). These principles break the one-to-one transaction relationship, which protects the correlation privacy of transaction parties. From step 7 to step 9, the TN leader pays after the encrypted computation results and the corresponding hash value is published on-chain. The change scheme makes the TN leader give feedback on DP and DR to evaluate the TN leader to obtain an extra deposit. and ℎ( _ ) on-chain for TN leader verification. Simultaneously, the TN computation contract pays a remuneration for DP. Then, the TN leader selects appropriate DP data for the DR code following these rules: ① One-time execution: the TN leader loads all DP data to conduct a computation and obtain all rewards at once, with all selected DPs responding. ② Multiple execution: According to the number of items in the selected transaction list, _ is even or odd, the TN leader could load responding DP data in batches to process with the DR code. If _ is even, the TN leader should select an appropriate even number of responding DP data each time, where the appropriate even number is less than _ . If _ is odd, the TN leader first selects a responding DP data number greater than 1 (3, 5, 7…). These principles break the one-to-one transaction relationship, which protects the correlation privacy of transaction parties. From step 7 to step 9, the TN leader pays after the encrypted computation results and the corresponding hash value is published on-chain. The change scheme makes the TN leader give feedback on DP and DR to evaluate the TN leader to obtain an extra deposit.

Smart Contract and Algorithm Design
In this section, we introduce the smart contract related interfaces and algorithm logic implemented in this paper. The SPPCS contains seven smart contracts-namely, the DR delegation register contract, DR computation contract, TN information management

Smart Contract and Algorithm Design
In this section, we introduce the smart contract related interfaces and algorithm logic implemented in this paper. The SPPCS contains seven smart contracts-namely, the DR delegation register contract, DR computation contract, TN information management contract, TN register contract, TN computation contract, DP information management contract and DP register contract. Then, as described in Figure 6, we detail the function and composition of these smart contracts. contract, TN register contract, TN computation contract, DP information management contract and DP register contract. Then, as described in Figure 6, we detail the function and composition of these smart contracts.  The DR delegation register contract broadcasts data demands EB, which makes DP and TNs notice data requirement. The pre-deposit interface enables DR deposits to be double the expected ether to pay for selected TNs after data matching analysis. Result analysis management counts the analysis result and sets the highest occurrence result list as the final result. DR registers the contract and publishes selected TN information, stores the data matching list hash value and provides a feedback interface to make reputation comments on the selected TNs. Reward management is used to send appropriate ether to selected TNs' addresses and return charge to encourage DR to give reputation feedback. The DR delegation register contract also provides an information query interface for DR and TN to retrieve related transaction information.

SPPCS
The DR computation contract broadcasts the selected transaction list on-chain and deposits enough value through the pre-deposit interface. The feedback interface is provided to make reputation comments on the TN leader. The DR computation contract utilizes reward management to pay for the leader and returns change to encourage DR to give reputation feedback. The information query interface is used to check related transaction information.
The TN information management contract stores TNs' reputation values and leader successful transaction numbers, which are called a DR computation contract and new TN or new leader initialize phase in the TN register contract. The information query interface in this smart contract helps the prospective DP and DR select appropriate TNs according to the contract information. The DR delegation register contract broadcasts data demands EB, which makes DP and TNs notice data requirement. The pre-deposit interface enables DR deposits to be double the expected ether to pay for selected TNs after data matching analysis. Result analysis management counts the analysis result and sets the highest occurrence result list as the final result. DR registers the contract and publishes selected TN information, stores the data matching list hash value and provides a feedback interface to make reputation comments on the selected TNs. Reward management is used to send appropriate ether to selected TNs' addresses and return charge to encourage DR to give reputation feedback. The DR delegation register contract also provides an information query interface for DR and TN to retrieve related transaction information.
The DR computation contract broadcasts the selected transaction list on-chain and deposits enough value through the pre-deposit interface. The feedback interface is provided to make reputation comments on the TN leader. The DR computation contract utilizes reward management to pay for the leader and returns change to encourage DR to give reputation feedback. The information query interface is used to check related transaction information.
The TN information management contract stores TNs' reputation values and leader successful transaction numbers, which are called a DR computation contract and new TN or new leader initialize phase in the TN register contract. The information query interface in this smart contract helps the prospective DP and DR select appropriate TNs according to the contract information.
The TN register contract records TN and leader TN specifications by TN list management and leader list management. The leader TN utilizes the deposit interface to deposit some ether, which is a penalty for a dishonest leader. Leader judgment management counts the negative vote number from TN list and call TN information management contract to clear the reputation value when the count number is greater than two-thirds of TNs.
The TN computation contract will not be detailed for the similar composition and function with the DR computation contract.
The DP information management contract maintains DPs reputation, which is called a TN computation contract and new DP initialize phase in the DP register contract. The information query interface makes TN recommend and select an appropriate DP to execute the transaction.
The DP register contract mainly records data quality pre-estimation value and stores data attribute descriptions. The information query interface is used to check DP data information for verification.
Off-chain computation involves a DR data matching process and results analysis provided by DR. We list the pseudo-code of data matching analysis off-chain computation in Algorithm 1.

Implementation and Performance Evaluation
We implemented and tested the SPPCS prototype based on the Ethereum private chain for sensitive data management. In the SPPCS scheme, the main activities are conducted by DRs, DPs and TNs. The DR and DP nodes were run in ThinkPad X1 carbon notebook with I7-10710 CPU and 16 G memory. The TNs and TN leader candidates were executed in 32 G memory Dell 7080-MT that provides SGX support with I7-10700 CPU. The smart contracts were deployed on a test EB private chain and encoded with solidity language. The enclave computation code was written in C/C++. We used ECC asymmetric encryption, AES symmetric encryption and a SHA256 hash algorithm to protect interactive data among DRs, DPs and TNs outside of TEE.
In order to validate and evaluate the performance of SPPCS, we simulated the entire operating mechanism, which should include: (1) data encryption; (2) security attestation; (3) execution privacy; (4) transaction efficiency. Transaction efficiency depends on the consensus performance of Ethereum, which is open to all. The performance of data encryption and security attestation are easily tested by encryption technology and TEE hardware. However, in SPPCS performance section, we mainly focus on execution privacy evaluation. We created twelve enclaves to represent TNs on two machines, with three enclaves from different SGX are TN leader candidates. As in the data description listed in Tables 3 and 4, two DR (labeled as DR1 and DR2) nodes were set to publish demands and ten DP (labeled as DP1, DP2, . . . , DP10) nodes were assigned to supply data.    With the command line tool, we can view DP register contract. As shown in Figure 7, the data attributes were recorded as a <DP account: data attribute hash>. The cryptographic functions ensure the confidentiality of DP data attributes and provide a validated method.

SGX Execution Performance Evaluation
In the data requirement matching phase, the execution time performance is mainly affected by the number of SGX nodes. More SGX nodes need longer synchronization time Figure 7. The data attribute value of DP register contract.

SGX Execution Performance Evaluation
In the data requirement matching phase, the execution time performance is mainly affected by the number of SGX nodes. More SGX nodes need longer synchronization time to obtain a data matching list. For the same DR1 request, seven potential DPs were interested in providing data. Without consideration of time consumption in DP identity validation, we performed a data matching computation 500 times with different numbers of TNs and recorded the result acquisition time in Figure 8.

SGX Execution Performance Evaluation
In the data requirement matching phase, the execution time performance is mainly affected by the number of SGX nodes. More SGX nodes need longer synchronization time to obtain a data matching list. For the same DR1 request, seven potential DPs were interested in providing data. Without consideration of time consumption in DP identity validation, we performed a data matching computation 500 times with different numbers of TNs and recorded the result acquisition time in Figure 8. From Figure 8, we can conclude that when the number of TNs increases from 1 to 3 and then to 5, the time difference is basically maintained at about 310 ms. However, when the number of TN increases to 7 and 9, the time difference increases by about 490 ms. The reason for this is that we simulated five enclaves as TNs on the same machine and four extra enclaves as TNs on another machine during this experiment. Whether the TN number is 1, 3 and 5, the time difference mainly exists in SGX operations with the same machine. The increased time difference of 7 and 9 TNs is probability consumed in a network link transmission. We believe that when the SPPCS is running, the time consumption for data matching computation of every additional TN should be increased by more than 490 ms, and the reliability of computation has been improved. Therefore, DR needs to balance the system computation performance with the result list safety when setting the required TN number. From Figure 8, we can conclude that when the number of TNs increases from 1 to 3 and then to 5, the time difference is basically maintained at about 310 ms. However, when the number of TN increases to 7 and 9, the time difference increases by about 490 ms. The reason for this is that we simulated five enclaves as TNs on the same machine and four extra enclaves as TNs on another machine during this experiment. Whether the TN number is 1, 3 and 5, the time difference mainly exists in SGX operations with the same machine. The increased time difference of 7 and 9 TNs is probability consumed in a network link transmission. We believe that when the SPPCS is running, the time consumption for data matching computation of every additional TN should be increased by more than 490 ms, and the reliability of computation has been improved. Therefore, DR needs to balance the system computation performance with the result list safety when setting the required TN number.
The time-consuming hybrid computation is decided by data transfer capacity, calculation size and SGX operations. In the same network environment and computing platform, fewer data should definitely allow for data transmission and calculation to be carried out more quickly. Then, in the same network environment and TN Leader, we mainly tested the time overhead of SGX operations. For the foot point cloud data of A about 4 MB (selected from DP1), B about 2 MB (selected from DP2), C about 4 MB (selected from DP7) and D about 5 MB (selected from DP9), we separately executed the same foot analysis algorithm 1000 times in the same hardware machine with SGX enabled/disenabled and recorded the corresponding average consumption times in Figure 9.
form, fewer data should definitely allow for data transmission and calculation to be carried out more quickly. Then, in the same network environment and TN Leader, we mainly tested the time overhead of SGX operations. For the foot point cloud data of A about 4 MB (selected from DP1), B about 2 MB (selected from DP2), C about 4 MB (selected from DP7) and D about 5 MB (selected from DP9), we separately executed the same foot analysis algorithm 1000 times in the same hardware machine with SGX enabled/disenabled and recorded the corresponding average consumption times in Figure 9. Whether in TEE or an ordinary execution environment, the calculation time becomes longer as the data capacity increases. However, the time-consuming difference with different execution environments subtly increased by about 260 ms, which is mainly produced by SGX operations: load encrypted data from untrusted space and output encrypted results from a trusted region. The time consumption cost of SGX security guarantee is acceptable.

Transaction Execution Privacy Evaluation
In SPPCS, DRs and DPs complete data transactions with the TN leader. The multiple DPs and DRs could, respectively, trade with the leader node at the same time, and the corresponding transaction records are shown in Figure 10. DR1 and DR2 deploy computation contracts correspondingly to selected data matching lists on-chain and deposit double the expected value of the TN leader and DPs, as recorded in blocks 157 and 160 of Figure 10a. In this test, the selected data matching list of DR1 contains DP1, DP2, DP7 and DP9. DR2 selects DP6, DP7 and DP9 as appropriate traders. The TN leader validates identity authentication information from multiple responding DPs (DP1, DP7 and DP6) and obtains original DP data whilst paying a remuneration. Although DP7 provides both DR1 and DR2 demand data at the same time, DP1 and DP7 follow the even-numbered list transaction rules, whereas DP6 and DP7 do not meet the odd-numbered list transaction rules. As presented in Figure 10b, according to the data selection rules described in in hybrid transaction phase, TN leader prioritizes DP1 and DP7 to perform calculation analysis for DR1. Then, the TN leader continues to validate DPs until the data transaction with DP6 and DP9 is complete through the smart contract. As DP6, DP7 and DP9 are in line with the odd-numbered list transaction rules, the TN leader selects DP6 and DP9 for DR2 computation at one time. After the TN leader validates the last DP2 and acquires corresponding data, DP2 is selected to complete the DR1 computation. Block 166, block 175, block 176, block 194 and block 204 in Figure 10c record DPs sending data to the TN leader in detail. Figure 10d records transactions between the TN leader and DRs (DR1 and DR2). Whether in TEE or an ordinary execution environment, the calculation time becomes longer as the data capacity increases. However, the time-consuming difference with different execution environments subtly increased by about 260 ms, which is mainly produced by SGX operations: load encrypted data from untrusted space and output encrypted results from a trusted region. The time consumption cost of SGX security guarantee is acceptable.

Transaction Execution Privacy Evaluation
In SPPCS, DRs and DPs complete data transactions with the TN leader. The multiple DPs and DRs could, respectively, trade with the leader node at the same time, and the corresponding transaction records are shown in Figure 10. DR1 and DR2 deploy computation contracts correspondingly to selected data matching lists on-chain and deposit double the expected value of the TN leader and DPs, as recorded in blocks 157 and 160 of Figure 10a. In this test, the selected data matching list of DR1 contains DP1, DP2, DP7 and DP9. DR2 selects DP6, DP7 and DP9 as appropriate traders. The TN leader validates identity authentication information from multiple responding DPs (DP1, DP7 and DP6) and obtains original DP data whilst paying a remuneration. Although DP7 provides both DR1 and DR2 demand data at the same time, DP1 and DP7 follow the even-numbered list transaction rules, whereas DP6 and DP7 do not meet the odd-numbered list transaction rules. As presented in Figure 10b, according to the data selection rules described in in hybrid transaction phase, TN leader prioritizes DP1 and DP7 to perform calculation analysis for DR1. Then, the TN leader continues to validate DPs until the data transaction with DP6 and DP9 is complete through the smart contract. As DP6, DP7 and DP9 are in line with the odd-numbered list transaction rules, the TN leader selects DP6 and DP9 for DR2 computation at one time. After the TN leader validates the last DP2 and acquires corresponding data, DP2 is selected to complete the DR1 computation. Block 166, block 175, block 176, block 194 and block 204 in Figure 10c record DPs sending data to the TN leader in detail. Figure 10d records transactions between the TN leader and DRs (DR1 and DR2). The TN leader returns computation results to DRs (DR1 and DR2) and is paid by calling the corresponding contract.  From transaction process recorded in Figure 10, there is no correspondence between DP data and the TN leader computation data. The transaction relationship between DRs and DPs cannot be inferred directly. Even if a DP leaks private information in the real world, it is impossible to infer more information with records on-chain. Compared with general blockchain-based transaction systems, and although the extra cost is mainly focused to invoke smart contracts for data demand matching computation and TN leader status maintenance, the transaction privacy is highly guaranteed. Moreover, our SPPCS reduces the consensus burden by transferring complex computation off-chain to maintain a high performance.

Security and Privacy Analysis
The SPPCS, proposed in this paper, combines EB, smart contract technology, IPFS and TEE mechanism to guarantee data confidentiality. In this section, we analyze the security and privacy of this scheme from denial of service (DoS) attack, malicious fraud attack and data exposure.

DoS Resistance
TEE nodes are vulnerable to DoS attack by DRs and may repeatedly broadcast computation tasks without any following operations or DPs could continuously deliver data to waste network resources. Moreover, DR and DP nodes also deal with the problem of network bandwidth waste caused by deliberately frequently invoking smart contracts.  From transaction process recorded in Figure 10, there is no correspondence between DP data and the TN leader computation data. The transaction relationship between DRs and DPs cannot be inferred directly. Even if a DP leaks private information in the real world, it is impossible to infer more information with records on-chain. Compared with general blockchain-based transaction systems, and although the extra cost is mainly focused to invoke smart contracts for data demand matching computation and TN leader status maintenance, the transaction privacy is highly guaranteed. Moreover, our SPPCS reduces the consensus burden by transferring complex computation off-chain to maintain a high performance.

Security and Privacy Analysis
The SPPCS, proposed in this paper, combines EB, smart contract technology, IPFS and TEE mechanism to guarantee data confidentiality. In this section, we analyze the security and privacy of this scheme from denial of service (DoS) attack, malicious fraud attack and data exposure.

DoS Resistance
TEE nodes are vulnerable to DoS attack by DRs and may repeatedly broadcast computation tasks without any following operations or DPs could continuously deliver data to waste network resources. Moreover, DR and DP nodes also deal with the problem of network bandwidth waste caused by deliberately frequently invoking smart contracts.
The SPPCS sets some rules against these problems: additional certain fee to be paid for invoking a smart contract, maximum number limitation of matching authentication and restrictions on remote attestation range.

Malicious Fraud Resistance
In the register phase, attackers could intercept requests to prevent DRs, DPs and TNs from completing registration. As a random event, participants complete registration by releasing or invoking smart contracts according to their wishes. Unless an interception attack is launched against a specific node, there is a very small probability that attackers block the legal request to prevent registration. Network attacks on specific targets can be prevented by adopting some network security strategies. In the computation and transaction phases, dishonest attacks may occur in DRs, DPs and TNs. The DR intentionally refuses to recognize TN calculation results and avoids paying TNs. The DP sends redundant invalid raw data to TN for extra remuneration. The TN fraud has two main purposes: provide dishonest analysis results to defraud rewards and maliciously steal or leak the original DP data. Moreover, collusion attacks are carried out between any two roles of the DR, DP and TN to obtain more rewards or utilize computing resources for free. The SPPCS mitigates dishonest attacks through combing the reputation feedback mechanism with a smart contract. In the data attribute matching phase, the DR needs a pre-deposit value and the final calculation result is decided by a delegation register contract, which avoids DR refuse to pay and obtains the wrong results. The TN with inconsistent calculation results should receive low reputation comments from smart contract, which greatly reduces the probability of the TN being selected again. In the computation phase, the TN validates whether original data hash is in line with the value registered on-chain, which refuses DP supply inappropriate data. Additionally, the encrypted original data are pulled into the TEE enclave, which prohibits data processions to be accessed and guarantees that the computation results cannot be tampered with. The change mechanism encourages DR to objectively evaluate TN, and TN to honestly evaluate DP. Furthermore, the pre-deposit broke DRs conduct the collusion attack and the reputation scheme effectively resists the collusion attack between DR and TN.

Confidentiality and Consistency
In SPPCS, various encryption and signature technologies are utilized to resist crack ciphertext during transmission. Blockchain consensus technology ensures the consistency of data status. In particular, TEE guarantees that the original data, process data and intermediate operations are inaccessible, which fundamentally maintains data confidentiality and privacy. Moreover, combined with TEE and blockchain, the dual hybrid transaction model is designed to isolate potential inferred connections between transaction parties. The transactions between DPs and DRs are completed through the TN leader. After obtaining the data matching list, the DR publishes selected transaction items, DPs provide corresponding encrypted original data to the TN leader and the blockchain maintains DR/DP transaction records with the TN leader simultaneously. As the TN leader receives multiple DR transaction entries during the term, the association between DRs and DPs is impossible to infer, which enhances the privacy and security of the SPPCS system.

Conclusions and Future Work
At present, unconscious sensitive data (such as 3D data) usage in a confidentialitypreserving and benefit-reserved manner is still a challenge. In this paper, the SPPCS is proposed, a trust hardware-based blockchain system to enhance privacy protection during sensitive data flow processes. The SPPCS decouples analysis computation and storage from consensus to achieve hierarchical separation computation. With a graph structure, the data leverage scheme of SPPCS performs a similarity computation of data expectation description and data provider description. The registered reputation value and costs on-chain are adopted by SPPCS as an important indicator to adjust similarity computation results and influence the final data requirement matching list. Specifically, the difference between the selected matching data quality evaluation and registered quality preestimation should affect the data provider reputation. According to the reputation value, the SPPCS prevents dishonest participants and reduces invalid data transactions effectively. Moreover, with the TEE security guarantee, the SPPCS designs a dual hybrid isolation model to set restrictions on accessing raw data and transaction parties' relationships. The analysis and experiments conducted on the Ethereum private chain and SGX demonstrates that (1) the SPPCS needs to consider the balance of enhanced security and more than 490 ms time consumption produced by two more TNs, whilst multiple TNs perform privacy computations; (2) the SPPCS can support execution security and privacy preservation with about extra 260 ms time consumption for SGX operations; (3) the SPPCS confuses the transaction direction between participants and prevents privacy disclosure of transaction relationship from on-chain records.
In the current SPPCS, we do not solve the problem of computation overhead increased by large-capacity data exceeding the enclave memory limit. Moreover, the threshold for TN leader candidates is difficulty, which needs to deposit a large value as a commitment. Future research should focus on two aspects: (1) a security memory expansion scheme should be designed to improve the applicability of SPPCS; (2) the TN leader operating mechanism should be optimized to attract more participants.