Decentralized data transaction method applied to vehicle Internet of Things environment

Abstract

The invention provides a decentralized data transaction method applied to a vehicle Internet of Things environment, and a system applied to the method comprises an identity service provider, a block chain, a data center, a plurality of data sellers, a plurality of data purchasers and a plurality of roadside units. The method comprises a system initialization process, a secret key generation process, a certificate issuing process, a demand issuing process, a transaction request process, a transaction response process, a transaction supply process, a transaction confirmation process and a zero knowledge construction process. According to the method, the problems that a third-party platform is untrusted, easy to crash, poor in fairness and safety, low in large-scale data delivery efficiency and the like in the data transaction process in the Internet of Vehicles environment are effectively solved.

Description

Technical Field

[0001] The present invention relates to the field of data trading and designs a decentralized data trading method applied in a vehicle Internet of Things environment. Background Art

[0002] The traditional data transaction process has shortcomings such as the third-party platform being untrustworthy, prone to downtime, lacking fairness and insufficient security. In the Internet of Vehicles environment, the data transaction participants have insufficient privacy protection capabilities and the delivery efficiency of large-scale data being traded is low.

[0003] Zero-knowledge proof is a cryptographic tool that allows two untrusting parties to prove the validity of a proposition without revealing any additional information. Zero-knowledge proofs have a wide range of applications. For example, in cryptography, zero-knowledge proofs can be used to verify that a user possesses a specific private key without revealing the private key itself. In blockchain technology, zero-knowledge proofs can be used to prove the validity and consistency of transactions without revealing the specific details of the transaction. Summary of the Invention

[0004] To address the above-mentioned issues, the present invention provides a decentralized data transaction method for use in a vehicle-to-vehicle (V2I) IoT environment. The system employed in the method comprises an identity service provider, a blockchain, a data center, and a number of data sellers, data buyers, and roadside units (ROUs). The data sellers are vehicles participating in the V2I IoT environment; the data buyers are commercial entities that purchase data; the identity service provider is an off-chain entity trusted by both the data buyers and the data sellers; the RSUs are blockchain nodes that communicate with the data buyers and nearby data sellers; and the data center is used to store encrypted data from the data sellers for download by the data buyers.

[0005] The method includes a system initialization process, a key generation process, a certificate issuance process, a demand release process, a transaction request process, a transaction response process, a transaction supply process, a transaction confirmation process, and a zero-knowledge construction process;

[0006] The system initialization process is used to implement system initialization and generate system common parameters;

[0007] The key generation process is performed by the data seller, data buyer, and identity service provider, and all three generate public and private key pairs and digital identities.

[0008] In the certificate issuance process, the data buyer calculates the user's private key possession certificate, its own attributes and related credentials and sends them to the identity verification provider for verification. If the verification is successful, the identity verification provider sends the encrypted identity certificate to the data buyer and constructs and forwards the transaction to the nearby roadside unit, which is responsible for adding the data buyer's digital identity to the identity list of the blockchain; the data buyer decrypts the identity certificate and performs relevant verification. If the verification is successful, the identity certificate is stored; the data seller and the identity verification provider perform the same operations as above to obtain the identity certificate;

[0009] In the demand release process, data buyers and data sellers calculate and store verifiable expressions. Data buyers construct and forward transactions based on their identities to nearby roadside units. Roadside units call smart contracts to execute demand functions to release demands and add relevant transaction demand records to the transaction list.

[0010] In the transaction request process, the data seller finds transaction requirements that match the data being traded through the transaction list, performs identity verification and buyer type verification, and if verification passes, splits the data and calculates the ciphertext proof of the traded data. The ciphertext proof is uploaded to the data center. The data seller constructs and forwards the transaction to a nearby roadside unit, which calls the contract to issue a transaction request.

[0011] In the transaction response process, the data buyer verifies the seller's type. If the verification is successful, the buyer downloads the encrypted proof of the traded data and verifies it. If the verification is successful, the bill is calculated, and the transaction is constructed and forwarded to the nearby roadside unit. The roadside unit calls the smart contract to issue a transaction response.

[0012] In the transaction supply process, the data seller verifies the transaction ticket, constructs and forwards the transaction to the nearby roadside unit, and the roadside unit calls the smart contract to publish the transaction supply;

[0013] In the transaction confirmation process, after receiving the ciphertext of the key provided by the seller, the data buyer decrypts the plaintext key and verifies its validity. Once the verification is successful, the buyer uses the key to recover the traded data from the ciphertext proof of the traded data. The buyer then constructs and forwards the transaction to a nearby roadside unit. The roadside unit then calls the smart contract to issue a transaction confirmation, completing the transaction.

[0014] Zero-knowledge construction process: the data buyer constructs the user private key possession certificate, the identity service provider verifies the data buyer's user private key possession certificate, the data seller constructs the user private key possession certificate, the identity service provider verifies the data seller's user private key possession certificate, the data buyer constructs the user identity attribute legality certificate, the data seller verifies the data buyer's user identity attribute legality certificate, the data seller constructs the user identity attribute legality certificate, the data buyer verifies the data seller's user identity attribute legality certificate, the data seller constructs the ciphertext proof sub-process of the data to be traded, and the data buyer verifies the ciphertext proof of the data to be traded.

[0015] Beneficial effects of the present invention:

[0016] 1. Using a DID-based autonomous identity management solution and integrating zero-knowledge proof to verify the legitimacy of user identity, it ensures the privacy needs of vehicle users and commercial companies and realizes the privacy protection of user identity.

[0017] 2. Use zero-knowledge proof to verify the validity and existence of the data to be traded, and achieve privacy protection of data and user personal information.

[0018] 3. Use the Sigma zero-knowledge proof protocol, which supports a large amount of parallel computing and has a low time overhead for generating proofs, thereby supporting efficient large-scale data delivery for vehicles with limited computing power and adapting to vehicle networking scenarios.

[0019] 4. Transaction data based on blockchain smart contracts provides regulators with credible evidence data, making the entire data transaction process traceable, decentralized, auditable and accountable.

[0020] In summary, the present invention designs a decentralized, trusted, automatic, secure, and private data transaction method, which effectively solves the problems existing in the data transaction process in the Internet of Vehicles environment, such as the third-party platform being untrustworthy, prone to downtime, lacking fairness and security, and low efficiency of large-scale data delivery. It can support vehicles with limited computing power to conduct large-scale data transactions. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 Schematic diagram of the system structure used in this method. DETAILED DESCRIPTION

[0022] The system to which the present invention is applied is first described below.

[0023] like Figure 1 The following diagram illustrates the system used in the method described in this invention. The system includes a data buyer, an identity service provider, a blockchain layer, a roadside unit, and a data center. Each of these components is described below.

[0024] Data Seller (DS): A data seller is a vehicle participating in the vehicle Internet of Things environment that can provide traded data;

[0025] Data Buyer (DB). A DB is an entity that purchases data for commercial purposes, typically a company. Each data buyer publishes its data requirements through the data trading system. The data it requires is called traded data.

[0026] Identity Service Provider (ISP). An ISP is an off-chain entity (such as a government entity with a cloud server) trusted by the data buyer (DB) and the data seller (DS). The ISP issues a Verifiable Credential (VC) for identity authentication. If a dispute arises between the DB and the DS during a data transaction, the ISP will participate in off-chain arbitration to resolve the dispute.

[0027] The Blockchain Layer (BL) consists of nodes from around the world and uses a consensus algorithm to create a platform for evidence persistence. The blockchain records the identities of transaction participants, as well as the results and status of data transaction protocols. This invention assumes that blockchain data cannot be tampered with, and all parties can access the blockchain and obtain accurate data.

[0028] Roadside Units (RSUs). RSUs are typically roadside infrastructure within a connected vehicle environment (off-the-shelf equipment can be used) that communicate with surrounding vehicles and businesses. Furthermore, RSUs serve as blockchain nodes, jointly maintaining the blockchain layer and acting as data economic agents to process vehicle data sales and business purchase requests.

[0029] Data Center (DC). The DC provides cloud storage services. When a vehicle passes a nearby RSU, its data, encrypted with zero-knowledge proof, is stored in the DC, waiting for download by commercial companies.

[0030] The technologies utilized in the present invention are described below.

[0031] 1. Decentralized Identifier (DID) decentralized identity technology

[0032] The present invention uses DID technology to achieve identity recognition, which is mainly composed of DID and Verifiable Credentials (VC):

[0033] A DID is a globally unique identifier encoded using a Uniform Resource Name (URN). A DID is used to represent an entity's digital identity. It is not created and controlled by a central issuer (identity provider), but rather by the identity owner. A DID is associated with a DID document in JSON-LD format, which contains information about the DID, including the public key, authentication protocol, and available service endpoints.

[0034] VC: A descriptive statement issued by a DID entity A to endorse certain attributes of another DID entity B, with entity A's digital signature attached to prove the authenticity of these attributes of entity B. In this invention, the subscript added under VC indicates the corresponding entity.

[0035] 2. Bilinear Mapping

[0036] If a mapping A bilinear map is one that satisfies the following requirements:

[0037] and are all cyclic multiplicative groups of order prime number p.

[0038] g and h are and The generator of .

[0039] and With effective homomorphism Where ψ(h) = g.

[0040] have

[0041]

[0042] and Each element in has a unique binary representation

[0043] 3. BBS + Digital Signature

[0044] set up Signers are randomly selected q is a prime number, public key The signer's BBS+ digital signature for message m is in if Signature efficient.

[0045] 4. Blockchain Transaction Model (Data Encryption and Decryption Operation Model, Digital Signature Operation Model, Merkle Tree Model)

[0046] Since the present invention requires encryption and decryption to protect the privacy of each entity's data, the present invention uses asymmetric encryption and decryption and digital signature modeling here. This model is a general model. The present invention uses Enc() and Dec() to represent asymmetric encryption and decryption algorithms, and uses Sign() and Veri() to represent signature and verification algorithms respectively.

[0047] Asymmetric encryption and decryption modeling:

[0048] y=Enc(pk,x)

[0049] This formula represents encrypting data x using the public key pk to obtain the ciphertext y.

[0050] x=Dec(sk,y)

[0051] This formula represents the use of private key sk to decrypt ciphertext y to obtain data x. The above two formulas satisfy:

[0052] x=Dec(sk,Enc(pk,x))

[0053] This formula means that when data x is encrypted using the public key pk, it will be decrypted by the corresponding key sk to obtain x.

[0054] Digital Signature Modeling:

[0055] σ=Sign(sk,x)

[0056] This formula represents the signature σ obtained by signing data x with the private key sk.

[0057] b=Veri(pk,x,σ)

[0058] This formula represents the use of the public key pk and the data x to verify the signature σ and obtain the verification result b. If b=1, the verification is successful, and if b=0, the verification fails.

[0059] 1=Veri(pk,x,Sign(sk,x))

[0060] This formula means that if pk and sk are a pair of public and private keys, then using the private key sk to sign data x will definitely be verified successfully by the corresponding public key pk.

[0061] Merkle tree modeling:

[0062] Merkle Tree, also known as Merkle Tree or Hash Tree, is the underlying encryption technology of blockchain. It can effectively and securely verify the content of large data structures and is widely used by the Ethereum blockchain.

[0063] r=MKRoot(K)

[0064] This formula represents constructing a Merkle tree for the contents of a large data structure K and obtaining the Merkle tree root r.

[0065] ξ=MKPath(r,K i ,K)

[0066] This formula represents the use of the Merkle tree root r to obtain the leaf node K of the Merkle tree K. i The Merkle path ξ.

[0067] b=MKVeri(r,K i ,ξ)

[0068] This formula represents the use of the Merkle tree root r and the Merkle path ξ to determine K i Is it a leaf node of the Merkle tree K? Get the verification result b. If b=1, the verification is successful; if b=0, the verification fails.

[0069] 5. Zero-Knowledge Proof Protocol

[0070] Zero-knowledge proof protocols allow the prover to convince the verifier that a statement is true without revealing any information other than what has already been made public. The present invention utilizes the Sigma-protocol, a three-step interactive zero-knowledge proof of knowledge system (ZKPOK), which can be transformed into a non-interactive zero-knowledge argument using the Fiat-Shamir heuristic and the secure hash function H.

[0071] For example:

[0072] ZKPOK{(x):y=g x}

[0073] It means that the prover has x and can convince the verifier that x satisfies y = g x

[0074] 6. Smart Contracts

[0075] The present invention relates to a transaction contract (TradC), which includes 10 functions: adding an identity identifier DID (add), issuing a demand (need), requesting a transaction (req), responding to a transaction (order), providing data (offer), and confirming a transaction (complete).

[0076] TradC maintains DidList (did list) and TradingList (transaction list), where DidList stores the DIDs of system participants and TradingList is used to record data transaction status.

[0077] Only the identity service provider (ISP) can perform the added DID function.

[0078] 7. Blockchain Transaction Model

[0079] Since the present invention needs to send a transaction to the blockchain to call a contract, the transaction is modeled here, and this model is an existing general model.

[0080] tx=(σ,addr con ,func,paras)

[0081] Among them, σ represents the digital signature generated by the transaction sender for the transaction, which is signed by the blockchain private key of the transaction sender (addr con ,func,paras) is generated, and the blockchain will automatically verify the signature. The digital signature generation and verification process will not be described in detail in this invention. addr con Represents the address of the target contract of the transaction. func represents the function of the target contract. paras represents the parameters used when calling the function.

[0082] The following is an explanation of the symbols and definitions used in the subsequent contents of the present invention.

[0083] λ: safety parameter.

[0084] Multiplicative cyclic group, order is a prime number q.

[0085] Bilinear map.

[0086] g,g0,g1,,...,g l ,u0,...,u v : The generator of .

[0087] h: The generator of .

[0088] H: hash function:

[0089] (sk DB ,pk DB ):DB key pair.

[0090] (pk DS ,pk DS ):DS key pair.

[0091] (sk ISP ,pk ISP ): ISP's key pair.

[0092] did DB :DB's DID.

[0093] did DS :DS's DID.

[0094] did ISP : ISP's DID.

[0095] b1,...,b l : DB attributes.

[0096] s1,...,s l : Attributes of DS.

[0097] BBS+digital signature value

[0098] σ: digital signature value

[0099] ZKPOK0, ZKPOK1, ZKPOK2: Non-interactive zero-knowledge proofs

[0100] φ DB : Statements about DB attributes.

[0101] φ DS : Statement about DS attributes.

[0102] ξ DB : The access control policy of the DB specifies a specific DS type.

[0103] ξ DS :DS access control policy, specifying a specific DB type.

[0104] Randomly select an element from the set {1,2,...,q-1}.

[0105] from Randomly select an element from .

[0106] proof0: proof of possession of the user's private key.

[0107] proof1: Legal proof of user identity attributes.

[0108] Proof2: Ciphertext proof of transaction data D

[0109] The method of the present invention is described below, including the system initialization process, key generation process, certificate issuance process, demand release process, transaction request process, transaction response process, transaction supply process, transaction confirmation process, and zero-knowledge construction process.

[0110] 1. System initialization process

[0111] In this process, given the security parameter λ, ISP performs system initialization and generates system public parameters:

[0112] Step 1: ISP generates bilinear group pairs Its order is a prime number q, that is, the mapping

[0113] Step 2: ISP randomly selects a generator Where l and v are both integers, which are set by the ISP during the system initialization process. Specifically, l represents the number of attributes of an entity, and v represents the data to be traded. The number of columns to split the matrix into.

[0114] Step 3: ISP selects hash function

[0115] Step 4: ISP outputs system parameters

[0116]

[0117] Step 5: ISP deploys the contract TradC in the blockchain.

[0118] 2. Key Generation Process

[0119] In this process, given the system parameters Perform the following steps:

[0120] Step 1: DB randomly selects a private key Calculate the public key Let did DB =pk DB , output the public-private key pair (pk DB ,sk DB ).

[0121] Step 2: DS randomly selects a private key Calculate the public key Let did DS =pk DS , output the public and private key pair, (pk DS ,sk DS ).

[0122] Step 3: ISP randomly selects a private key Calculate the public key Let did ISP =pk ISP , output the public-private key pair (pk ISP ,sk ISP ), where did ISP It is a trusted did and has been added to DidList.

[0123] 3. Certificate Issuance Process

[0124] In this process, given the system parameters Set DB ownership Perform the following steps:

[0125] Step 1: DB random selection calculate send and relevant credentials (such as ID card, passport, driver's license, etc.) to the ISP. The specific steps of constructing proof0 are detailed in the DB construction proof0 steps described later.

[0126] Step 2: ISP Verification If the verification fails, the ISP outputs ⊥ and terminates the step. Otherwise, the following steps are continued. The specific steps of ISP verification of proof0 are detailed in the ISP verification of DB proof0 steps described later.

[0127] Step 3: ISP random selection

[0128] calculate Verifiable Credentials

[0129] Among them, σ ISP =Sign(sk ISP ,VC DB .body) is the ISP to VC DB The digital signature of the .body,

[0130]

[0131] Step 4: ISP calculates and sends To DB.

[0132] Step 5: ISP constructs and forwards transaction tx={σ,addr TradC ,add,(did DB)} to the nearby RSU, which will further initiate this transaction to call the add function of the TradC contract to do DB Added to the blockchain DidList.

[0133] Step 6: DB calculation

[0134] Step 7: DB judgment 1 = Veri(VC' DB .did ISP ,VC' DB .body,VC' DB .σ ISP ), if the verification fails, DB outputs ⊥ and terminates the step, otherwise continue to execute the following steps.

[0135] Step 8: DB calculates τ=τ'+τ", and verifies If the verification fails, DB outputs ⊥ and terminates the step. Otherwise, VC' is stored locally. DB and τ.

[0136] In this process, given the system parameters Set DS to have Perform the following steps:

[0137] Step 1: DS random selection calculate send and relevant credentials (such as ID card, passport, driver's license, etc.) to the ISP. The specific steps of constructing proof0 are detailed in the DS construction proof0 steps described later.

[0138] Step 2: ISP Verification If the verification fails, the ISP outputs ⊥ and terminates the step. Otherwise, the following steps are continued. The specific steps of ISP verification of proof0 are detailed in the following section: ISP Verification of DS Proof0.

[0139] Step 3: ISP random selection

[0140] calculate Verifiable Credentials

[0141] Among them, σ ISP =Sign(sk ISP ,VC DS .body) is the ISP to VCDS The digital signature of the .body,

[0142] Step 4: ISP calculates and sends To DS.

[0143] Step 5: ISP constructs and forwards transaction tx={σ,addr TradC ,add,(did DS )} to the nearby RSU, which will further initiate this transaction to call the add function of the TradC contract to do DS Added to the blockchain DidList.

[0144] Step 6: DS calculation

[0145] Step 7: DS determines 1 = Veri (VC' DS .did ISP ,VC' DS .body,VC' DS .σ ISP ), if the verification fails, DS outputs ⊥ and terminates the step, otherwise it continues to execute the following steps.

[0146] Step 8: DS calculates τ=τ'+τ", and verifies If the verification fails, DS outputs ⊥ and terminates the step. Otherwise, VC' is stored locally. DS and τ.

[0147] 4. Requirements Release Process

[0148] In this process, the commercial company, namely the data buyer DB (who owns the attribute ) has obtained VC' DB , perform the following steps:

[0149] Step 1: DB calculates and stores the verifiable expression

[0150] VP DB ={did ISP ,did DB ,proof1,σ DB}

[0151] Among them, σ DB =Sign(sk DB ,VP DB .body),

[0152] VP DB .body={did ISP,did DB ,proof1},

[0153]

[0154] For details, please refer to the DB construction proof1 step described later.

[0155] Set ownership DS has obtained VC' DS Follow the same steps as above to gain VP DS The details are as follows:

[0156] DS calculates and stores the verifiable expression

[0157] VP DS ={did ISP ,did DS ,proof1,σ DS}

[0158] Among them, σ DS =Sign(sk DS ,VP DS .body),

[0159] VP DS .body={did ISP ,did DS ,proof1},

[0160]

[0161] For details, please refer to the DS construction proof1 step described later.

[0162] Step 2: DB based on identity did DB Construct and forward transactions To the nearby RSU, RSU will further initiate this transaction to call the need function of the transaction contract TradC, where For the required data Description of deposit DB is the amount of DB mortgage, time need Indicates that the data is required at time need Valid until expiration.

[0163] Step 3: TradC executes the need function to publish the demand:

[0164] Judgment 1 = Veri(VP DB .did DB ,VP DB .body,VPDB .σ DB ) and VP DB .did DB Is it the identity that initiated the transaction? DB If not, output ⊥.

[0165] Judging VCs DB .did ISP ,VP DB .did DB Is it in DidList? If not, output ⊥.

[0166] Verify that the DB account balance is greater than deposit DB If the verification fails, output ⊥, otherwise the deposit of DB mortgage DB Transfer to TradC.

[0167] Add a transaction record in TradingList And set the following:

[0168]

[0169] tradind id .VP DB =VP DB ,

[0170] trading id .VP DS =NULL,

[0171] trading id .deposit DB =deposit DB ,

[0172] trading id .deposit DS =NULL,

[0173]

[0174] trading id .url=NULL,

[0175]

[0176] The id is trading id A unique identifier for Where exp is the current time.

[0177] 5. Transaction Request Process

[0178] In this process, the vehicle holding data D, that is, the data seller DS (with attribute ) Discover DB pair data through TradingList Demand trading id , perform the following steps:

[0179] Step 1: DS Verification Trading id .VP DB .proof1. For details, please refer to the proof1 step of DS verifying DB described later. If the verification fails, DS will terminate without performing any operation. Otherwise, it will continue to execute the following steps.

[0180] Step 2: DS judgment DS =trading id .VP DB .proof1.φ DB , that is, to determine whether it meets the specified buyer type. If the verification fails, DS will abort and not perform any operation. Otherwise, it will continue to execute the following steps.

[0181] Step 3: DS will Divide into n×v matrix, that is

[0182] in

[0183] Step 4: DS random selection and add to Right now

[0184]

[0185] Step 5: DS random selection Store k locally and use k to calculate proof2, where

[0186]

[0187] For details, please refer to the DS construction proof2 step described later.

[0188] Here k can be used in the subsequent process for the buyer to recover and obtain from proof2

[0189] Step 6: DS uploads proof2 to the data center DC, and DC returns the download link of proof2

[0190] Step 7: DS based on identity did DS Construct and forward transactions To the nearby RSU, RSU will further initiate this transaction to call the req function of the TradC contract, where For data Price, deposit DS is the amount of DS mortgage, time req Indicates that the transaction request was made at time req Valid until deadline.

[0191] Step 8: TradC executes the req function to issue a transaction request:

[0192] Judgment 1 = Veri(VP DS .did DS ,VP DS .body,VP DS .σ DS ) and VP DS .did DS Is it the identity that initiated the transaction? DS If not, output ⊥.

[0193] Judging VP DS .did ISP ,VP DS .did DS Is it in DidList? If not, output ⊥.

[0194] judge If the verification fails, output ⊥, otherwise continue to execute the following steps.

[0195] Verify that the current time is less than If the verification fails, output ⊥, otherwise continue to execute the following steps.

[0196] Verify whether the DS account balance is greater than deposit DS If the verification fails, output ⊥, otherwise the DS mortgage deposit DS Transfer to TradC.

[0197] set up

[0198] trading id .VP DS =VP DS ,

[0199] trading id .deposit DS=deposit DS ,

[0200]

[0201]

[0202] 6. Transaction Response Process

[0203] Step 1: DB judgment DB =trading id .VP DS .proof1.φ DS , that is, to determine whether it meets the specified seller type. If the verification fails, the DB will abort and not perform any operation. Otherwise, it will continue to execute the following steps.

[0204] Step 2: DB through trading id .url downloads proof2 from the data center DC and verifies proof2. For detailed steps, see XI. DB verification of proof2 in the zero-knowledge proof construction method of the present invention. If the verification fails, DB aborts and does not perform any operation. Otherwise, it continues to execute the following steps.

[0205] Step 3: DB calculates the bill where γ' K =MKRoot(K [n,v+1] ), K [n,v+1] Please refer to the proof2 step of DB verification described later for details.

[0206] Step 4: DB based on identity did DB Constructing forwarding transactions To the nearby RSU, RSU will further initiate this transaction to call the order function of the TradC contract, where Amount paid for DB, time order Indicates that the transaction response is at time order Valid until the deadline.

[0207] Step 5: TradC executes the order function and publishes the transaction response:

[0208] Judgment 1 = Veri(VP DB .did DB ,VP DB .body,VP DB .σ DB ) and VP DB .did DB Is it the identity that initiated the transaction?DB If not, output ⊥.

[0209] Judging VP DB .did ISP ,VP DB .did DB Is it in DidList? If not, output ⊥.

[0210] Judgment Trading id .VP DB Is it equal to VP? DB , if not, output ⊥.

[0211] judge If not, output ⊥, otherwise continue to execute the following steps.

[0212] Verify that the current time is less than If the verification fails, output ⊥, otherwise continue to execute the following steps.

[0213] Verify that the DB account balance is greater than and Is it greater than If the verification fails, output ⊥, otherwise the DB payment Transfer to TradC.

[0214] set up

[0215]

[0216] 7. Transaction and Supply Process

[0217] Step 1: DS judgment If it is not true, DS will terminate without any operation, otherwise it will continue to execute the following steps. K =MKRoot(K [n,v+1] ), here K [n,v+1] Obtained from the aforementioned transaction request process, please refer to the DS construction proof2 step described later for details.

[0218] Step 2: DS calculation

[0219] Step 3: DS builds and forwards the transaction

[0220] To the nearby RSU, RSU will further initiate this transaction to call the TradC contract offer function, time offer Indicates trading id In time offer Valid until expiration.

[0221] Step 4: TradC executes the offer function:

[0222] Judgment 1 = Veri(VP DS .did DS ,VP DS .body,VP DS .σ DS ) and VP DS .did DS Is it the identity that initiated the transaction? DS If not, output ⊥.

[0223] Judging VP DS .did ISP ,VP DS .did DS Is it in DidList? If not, output ⊥.

[0224] Judgment Trading id .VP DS Is it equal to VP? DS , if not, output ⊥.

[0225] judge If not, output ⊥, otherwise continue to execute the following steps.

[0226] Verify that the current time is less than If the verification fails, output ⊥, otherwise continue to execute the following steps.

[0227] set up

[0228]

[0229] 8. Transaction Confirmation Process

[0230] Step 1: Obtaining the database calculate

[0231]

[0232] Step 2: DB calculation Right now

[0233]

[0234] Step 3: DB calculation γ" K =MKRoot(K' [n,v+1] ).

[0235] Step 4: DB judgment If not, output ⊥, otherwise continue to execute the following steps.

[0236] Step 5: DB calculation Get data where z ij ∈Z [n,v+1] Exists in proof2, c' is obtained when DB verifies proof2. For details, see the DB verification proof2 steps described later.

[0237] Step 6: DB constructs and forwards transaction tx={σ,addr TradC ,complete,(id,VP DB )} to the nearby RSU, which will further initiate this transaction to call the TradC contract complete function.

[0238] Step 6: TradC executes the complete function:

[0239] Judgment 1 = Veri(VP DB .did DB ,VP DB .body,VP DB .σ DB ) and VP DB .did DB Is it the identity that initiated the transaction? DB If not, output ⊥.

[0240] Judging VP DB .did ISP ,VP DB .did DB Is it in DidList? If not, output ⊥.

[0241] Judgment Trading id .VP DB Is it equal to VP? DB , if not, output ⊥.

[0242] judge If not, output ⊥, otherwise continue to execute the following steps.

[0243] Verify that the current time is less than If the verification fails, output ⊥, otherwise continue to execute the following steps.

[0244] set up transfer The amount will be transferred to DS's account and the deposit will be returned separately. DB and depositDS The data transaction between DB and DS is now complete.

[0245] 9. Zero-knowledge proof construction process

[0246] 1.proof0 construction and verification

[0247] The steps for constructing proof0 in DB are as follows:

[0248] Step 1: DB random selection calculate

[0249] Step 2: DB calculation

[0250] Step 3: DB calculates z1 = r1 - c sk DB , z2=r2-c·τ'.

[0251] Step 4: Send to DB To the ISP.

[0252] The steps for ISP to verify DB's proof0 are as follows:

[0253] Step 1: ISP Calculation

[0254] Step 2: ISP determination If not, abort and output ⊥.

[0255] Step 3: ISP determination If not, abort and output ⊥.

[0256] The steps for DS to construct proof0 are as follows:

[0257] Step 1: DS random selection calculate

[0258] Step 2: DS calculation

[0259] Step 3: DS calculates z1 = r1 - c sk DS , z2=r2-c·τ'.

[0260] Step 4: DS sends To the ISP.

[0261] The steps for ISP to verify proof0 of DS are as follows:

[0262] Step 1: ISP Calculation

[0263] Step 2: ISP determination If not, abort and output ⊥.

[0264] Step 3: ISP determination If not, abort and output ⊥.

[0265] 2.Proof1 construction and verification

[0266] The present invention does not DB (b1,...,b l )=1 (existing technology can be used). The steps of DB constructing proof1 are as follows:

[0267] Step 1: DB random selection calculate send To DS.

[0268] Step 2: DB random selection calculate

[0269]

[0270] Step 3: DB calculation

[0271] Step 4: DB calculation

[0272] Step 5: Send to DB

[0273] To DS.

[0274] The steps for DS to verify DB's proof1 are as follows:

[0275] Step 1: DS calculation

[0276] Step 2: DS judgment If not, abort and output ⊥.

[0277] Step 3: DS judgment If not, abort and output ⊥.

[0278] Step 4: DS judgment If not, abort and output ⊥.

[0279] Step 5: DS judgment

[0280]

[0281] If not, abort and output ⊥.

[0282] Step 6: DS judgment If not, abort and output ⊥.

[0283] Step 7: Output 1.

[0284] The present invention does not DS (s1,...,s l )=1 (existing technology can be used), the steps of DS constructing proof1 are as follows:

[0285] Step 1: DS random selection calculate send To DB.

[0286] Step 2: DS random selection calculate

[0287]

[0288]

[0289]

[0290] Step 3: DS calculation

[0291] Step 4: DS calculation

[0292] Step 5: DS sends

[0293] To DS.

[0294] The steps for DB in the present invention to verify proof 1 of DS are as follows:

[0295] Step 1: DB calculation

[0296] Step 2: DB judgment If not, abort and output ⊥.

[0297] Step 3: DB judgment If not, abort and output ⊥.

[0298] Step 4: DB judgment If not, abort and output ⊥.

[0299] Step 5: DB judgment

[0300]

[0301] If not, abort and output ⊥.

[0302] Step 6: DB judgment If not, abort and output ⊥.

[0303] Step 7: Output 1.

[0304] 3.Proof2 construction and verification

[0305] DS constructs proof2 in the following steps:

[0306] Step 1: DS random selection

[0307] Step 2: DS random selection calculate

[0308]

[0309] Step 3: DS calculation Right now

[0310]

[0311] Step 4: DS calculation γ K =MKRoot(K [n,v+1] ). Here DS will save locally γ K .

[0312] Step 5: DS calculation Step 6: DS calculation Step 7: DS calculation Right now

[0313]

[0314] Step 8: DS local storage and sending To DB.

[0315] The steps for DB verification of proof2 are as follows:

[0316] Step 1: DB calculates γ' K =MKRoot(K [n,v+1] ).

[0317] Step 2: DB calculation

[0318] Step 3: DB judgment If not, abort and output ⊥.

[0319] Step 4: DB judgment If not, abort and output ⊥.

[0320] Step 5: DB judgment where i∈[1,n], j∈[0,v], z ij ∈Z [n,v+1] , K ij ∈K [n,v+1] , C i1 ∈C [n,1] , if not, terminate and output ⊥.

[0321] Step 6: Output 1.

Claims

1. A decentralized data transaction method applied in a vehicle Internet of Things environment, characterized in that: The system used in the method includes an identity service provider, a blockchain, a data center, and several data sellers, data buyers, and roadside units. The data sellers are vehicles participating in the vehicle Internet of Things environment; the data buyers are commercial entities that purchase data; the identity service provider is an off-chain entity trusted by the data buyers and data sellers; the roadside units are blockchain nodes that communicate with the data buyers and nearby data sellers; the data center is used to store data encrypted by the data sellers for download by the data buyers; The method includes a system initialization process, a key generation process, a certificate issuance process, a demand release process, a transaction request process, a transaction response process, a transaction supply process, a transaction confirmation process, and a zero-knowledge construction process; The system initialization process is used to implement system initialization and generate system common parameters; The key generation process is performed by the data seller, data buyer, and identity service provider, and all three generate public and private key pairs and digital identities. In the certificate issuance process, the data buyer calculates the user's private key possession certificate, its own attributes and related credentials and sends them to the identity verification provider for verification. If the verification is successful, the identity verification provider sends the encrypted identity certificate to the data buyer and constructs and forwards the transaction to the nearby roadside unit, which is responsible for adding the data buyer's digital identity to the identity list of the blockchain; the data buyer decrypts the identity certificate and performs relevant verification. If the verification is successful, the identity certificate is stored; the data seller and the identity verification provider perform the same operations as above to obtain the identity certificate; In the demand release process, data buyers and data sellers calculate and store verifiable expressions. Data buyers construct and forward transactions based on their identities to nearby roadside units. Roadside units call smart contracts to execute demand functions to release demands and add relevant transaction demand records to the transaction list. In the transaction request process, the data seller finds transaction requirements that match the data being traded through the transaction list, performs identity verification and buyer type verification, and if verification passes, splits the data and calculates the ciphertext proof of the traded data. The ciphertext proof is uploaded to the data center. The data seller constructs and forwards the transaction to a nearby roadside unit, which calls the contract to issue a transaction request. In the transaction response process, the data buyer verifies the seller's type. If the verification is successful, the buyer downloads the encrypted proof of the traded data and verifies it. If the verification is successful, the bill is calculated, and the transaction is constructed and forwarded to the nearby roadside unit. The roadside unit calls the smart contract to issue a transaction response. In the transaction supply process, the data seller verifies the transaction ticket, constructs and forwards the transaction to the nearby roadside unit, and the roadside unit calls the smart contract to publish the transaction supply; In the transaction confirmation process, after receiving the ciphertext of the key provided by the seller, the data buyer decrypts the plaintext key and verifies its validity. Once the verification is successful, the buyer uses the key to recover the traded data from the ciphertext proof of the traded data. The buyer then constructs and forwards the transaction to a nearby roadside unit. The roadside unit then calls the smart contract to issue a transaction confirmation, completing the transaction. Zero-knowledge construction process: the data buyer constructs the user private key possession certificate, the identity service provider verifies the data buyer's user private key possession certificate, the data seller constructs the user private key possession certificate, the identity service provider verifies the data seller's user private key possession certificate, the data buyer constructs the user identity attribute legality certificate, the data seller verifies the data buyer's user identity attribute legality certificate, the data seller constructs the user identity attribute legality certificate, the data buyer verifies the data seller's user identity attribute legality certificate, the data seller constructs the ciphertext proof sub-process of the data to be traded, and the data buyer verifies the ciphertext proof of the data to be traded.

2. The decentralized data transaction method applied to the vehicle Internet of Things environment according to claim 1, characterized in that: The identity service provider system initialization process specifically includes the following steps: Step 1: The identity service provider generates a bilinear group pair Its order is a prime number q, that is, the mapping Step 2: The identity service provider randomly selects a generator l represents the number of attributes of the data buyer and data seller, and v represents the number of columns after the transaction data is divided into matrices; Step 3: The identity service provider selects a hash function Step 4: The identity service provider outputs system parameters Step 5: The identity service provider deploys the transaction contract TradC in the blockchain.

3. The decentralized data transaction method applied in the vehicle Internet of Things environment according to claim 2 is characterized in that: In the key generation process, the data seller, data buyer, and identity service provider all generate key pairs and digital identities, as follows: Data buyers randomly select private keys Calculate the public key Let did DB =pk DB , output the public-private key pair (pk DB ,sk DB );in Indicates that an element is randomly selected from the set {1,2,...,q-1}; did DB Indicates the DID of the data buyer. DID is the identity information; Data sellers randomly select private keys Calculate the public key Let did DS =pk DS , output the public and private key pair, (pk DS ,sk DS );did DS Indicates the DID of the data seller; The identity service provider randomly selects a private key Calculate the public key Let did ISP =pk ISP , output the public-private key pair (pk ISP ,sk ISP ), where did ISP It is the trusted didd of the identity service provider and has been added to the DidList; didd ISP Indicates the DID of the identity service provider; DidList is a DID list.

4. The decentralized data transaction method applied in the vehicle Internet of Things environment according to claim 3 is characterized in that: The certificate issuance process includes the data buyer certificate issuance sub-process and the data seller certificate issuance sub-process; The specific sub-process for issuing data buyer certificates is as follows: Set the data buyer attribute set Perform the following steps: Step 1: Data buyers are randomly selected Calculate the user's private key possession proof send and related credentials to the identity service provider; ZKPOK stands for zero-knowledge proof, and its subscript corresponds to the subscript of proof0; Step 2: Identity Service Provider Verification If the verification fails, the identity service provider outputs ⊥ and terminates the step. Otherwise, the following steps are continued; Step 3: Random selection of identity service providers calculate Verifiable Credentials σ ISP Digital signature for identity service provider; Among them, σ ISP =Sign(sk ISP ,VC DB .body) is the identity service provider's response to VC DB The digital signature of the .body, Sign is the signature function; Step 4: The identity service provider calculates and sends To the data buyer; Enc is the decryption function; Step 5: The identity service provider constructs and forwards the transaction tx = {σ,addr TradC ,add,(did DB )} to the nearby roadside unit, which will further initiate this transaction to call the add function of the TradC contract to do DB Add to DidList; TradC contract is the transaction contract; addr TradC Represents the transaction contract address; σ represents the digital signature value; Step 6: Data Buyer Calculation Dec is the encryption function; Step 7: Data buyer judgment 1 = Veri(VC' DB .did ISP ,VC' DB .body,VC' DB .σ ISP ), Veri is the signature verification function; if the verification fails, the data buyer outputs ⊥ and terminates the step, otherwise continue to execute the following steps; Step 8: The data buyer calculates τ=τ'+τ", and verifies If the verification fails, the data buyer outputs ⊥ and terminates the step. Otherwise, VC' is stored locally. DB and τ; The specific process for issuing a data seller certificate is as follows: Set the data seller attribute set Perform the following steps: Step 1: Data sellers are randomly selected Calculate its user private key certificate send and related credentials to the identity service provider; Step 2: Identity Service Provider Verification If the verification fails, the identity service provider outputs ⊥ and terminates the step. Otherwise, the following steps are continued; Step 3: Random selection of identity service providers calculate Verifiable Credentials Among them, σ ISP =Sign(sk ISP ,VC DS .body) is the identity service provider's response to VC DS The digital signature of the .body, Step 4: The identity service provider calculates and sends To data sellers; Step 5: The identity service provider constructs and forwards the transaction tx = {σ,addr TradC ,add,(did DS )} to the nearby roadside unit, which will further initiate this transaction to call the add function of the TradC contract to do DS Add to blockchain DidList; Step 6: Data seller calculation Step 7: Data seller determines 1 = Veri(VC' DS .did ISP ,VC' DS .body,VC' DS .σ ISP ), if the verification fails, the data seller outputs ⊥ and terminates the step, otherwise continue to execute the following steps; Step 8: The data seller calculates τ=τ'+τ", and verifies If the verification fails, the data seller outputs ⊥ and terminates the step. Otherwise, the local storage VC' DS and τ.

5. The decentralized data transaction method applied to the vehicle Internet of Things environment according to claim 4 is characterized in that: In the demand release process, the data buyer executes the following sub-processes: Step 1: The data buyer calculates and stores the verifiable expression VP DB ={did ISP ,did DB ,proof1,σ DB } Among them, σ DB =Sign(sk DB ,VP DB .body), VP DB .body={did ISP ,did DB ,proof1}, proof1 is the legal proof of the corresponding user identity attribute; ZKPOK1 corresponds to the subscript of proof1; The data seller performs the following sub-processes: Step 1: The data seller calculates and stores the verifiable expression VP DS ={did ISP ,did DS ,proof1,σ DS } Among them, σ DS =Sign(sk DS ,VP DS .body), VP DS .body={did ISP ,did DS ,proof1}, Step 2: Data buyer based on identity did DB Construct and forward transactions To the nearby roadside unit, the roadside unit will further initiate this transaction to call the need function of the transaction contract TradC, where For the required data Description of deposit DB The amount of mortgage by the data buyer, time need Indicates the deadline for data demand; Step 3: TradC executes the need function to publish the demand: Judgment 1 = Veri(VP DB .did DB ,VP DB .body,VP DB .σ DB ) and VP DB .did DB Is it the identity that initiated the transaction? DB If it is not true, output ⊥; Judging VP DB .did ISP ,VP DB .did DB Is it in DidList? If not, output ⊥; Verify whether the data buyer's account balance is greater than deposit DB If the verification fails, output ⊥, otherwise the deposit pledged by the data buyer will be DB Transfer to TradC; Add a transaction record in TradingList And set the following: tradind id .VP DB =VP DB , trading id .VP DS =NULL, trading id .deposit DB =deposit DB , trading id .deposit DS =NULL, trading id .url=NULL, The id is trading id A unique identifier for Where exp is the current time, TradingList is the transaction list, deposit DS The amount pledged by the data seller, url is the link stored in the data center, For bills, Indicates the transaction status.

6. The decentralized data transaction method applied to the vehicle Internet of Things environment according to claim 5, characterized in that: During the transaction request process: Data sellers use TradingList to find data buyers and how they treat transaction data. Demand trading id , perform the following steps: Step 1: Data seller verifies trading id .VP DB .proof1, if the verification fails, the data seller will abort and not perform any operation, otherwise continue to perform the following steps; Step 2: Data sellers judge DS =trading id .VP DB .proof1.φ DB , that is, to determine whether it meets the specified buyer type. If the verification fails, the data seller will abort and not perform any operations. Otherwise, it will continue to perform the following steps; Step 3: Data sellers send data Divide into n×v matrix, that is in i∈[1,n],j∈[1,v] Step 4: Data sellers are randomly selected i∈[1,n], and add to Right now Step 5: Data sellers are randomly selected Store k locally and use k to calculate proof2, where Step 6: The data seller uploads proof2 to the data center DC, and DC returns the download link of proof2 Step 7: Data sellers do DS Construct and forward transactions To the nearby roadside unit, the roadside unit will further initiate this transaction to call the req function of the TradC contract, where For data Price, deposit DS The amount of collateral pledged by the data seller, time req Indicates that the transaction request was made at time req Valid until the deadline; Step 8: TradC executes the req function to issue a transaction request: Judgment 1 = Veri(VP DS .did DS ,VP DS .body,VP DS .σ DS ) and VP DS .did DS Is it the identity that initiated the transaction? DS If it is not true, output ⊥; Judging VP DS .did ISP ,VP DS .did DS Is it in DidList? If not, output ⊥; judge If the verification fails, output ⊥, otherwise continue to execute the following steps; Verify that the current time is less than If the verification fails, output ⊥, otherwise continue to execute the following steps; Verify whether the data seller's account balance is greater than deposit DS If the verification fails, output ⊥, otherwise the deposit pledged by the data seller is DS Transfer to TradC; set up trading id .VP DS =VP DS , trading id .deposit DS =deposit DS , 7. The decentralized data transaction method applied in the vehicle Internet of Things environment according to claim 6, characterized in that: The transaction response process is as follows: Step 1: Data buyer’s judgment DB =trading id .VP DS .proof1.φ DS , that is, to determine whether it meets the specified seller type. If the verification fails, the data buyer will abort and not perform any operations. Otherwise, it will continue to perform the following steps; Step 2: Data buyers trade id .url downloads proof2 from the data center DC and verifies proof2. If the verification fails, the data buyer aborts and does not perform any operation. Otherwise, continue to perform the following steps; Step 3: Data buyer calculates the bill where γ' K =MKRoot(K [n,v+1] ), K [n,v+1] Variables generated when data buyers verify proof2; Step 4: Data buyer based on identity DB Constructing forwarding transactions To the nearby roadside unit, the roadside unit will further initiate this transaction to call the order function of the TradC contract, where The amount paid by the data buyer, time order Indicates that the transaction response is at time order Valid until the deadline; Step 5: TradC executes the order function and publishes the transaction response: Judgment 1 = Veri(VP DB .did DB ,VP DB .body,VP DB .σ DB ) and VP DB .did DB Is it the identity that initiated the transaction? DB If it is not true, output ⊥; Judging VCs DB .did ISP ,VP DB .did DB Is it in DidList? If not, output ⊥; Judgment Trading id .VP DB Is it equal to VP? DB If it does not hold, output ⊥; judge If it is not true, output ⊥, otherwise continue to execute the following steps; Verify that the current time is less than If the verification fails, output ⊥, otherwise continue to execute the following steps; Verify whether the data buyer's account balance is greater than and Is it greater than If the verification fails, the output is ⊥, otherwise the data buyer pays Transfer to TradC; set up 8. The decentralized data transaction method applied in the vehicle Internet of Things environment according to claim 7, characterized in that: The transaction supply process performs the following steps: Step 1: Data seller judgment If it is not true, the data seller will stop and not perform any operation. Otherwise, it will continue to perform the following steps; where γ K =MKRoot(K [n,v+1] ), here K [n,v+1] In the aforementioned transaction request process, please refer to the data seller's proof2 construction step described later for details; Step 2: Data seller calculation Step 3: Data seller builds and forwards the transaction To the nearby roadside unit, the roadside unit will further initiate this transaction to call the TradC contract offer function, time offer Indicates trading id In time offer Valid until expiration; Step 4: TradC executes the offer function: Judgment 1 = Veri(VP DS .did DS ,VP DS .body,VP DS .σ DS ) and VP DS .did DS Is it the identity that initiated the transaction? DS If it is not true, output ⊥; Judging VP DS .did ISP ,VP DS .did DS Is it in DidList? If not, output ⊥; Judgment Trading id .VP DS Is it equal to VP? DS If it does not hold, output ⊥; judge If it is not true, output ⊥, otherwise continue to execute the following steps; Verify that the current time is less than If the verification fails, output ⊥, otherwise continue to execute the following steps; set up 9. The decentralized data transaction method applied in the vehicle Internet of Things environment according to claim 8, characterized in that: The transaction confirmation process performs the following steps: Step 1: Data buyer obtains calculate Step 2: Data buyers calculate ρ' ij =H(k',i,j), i∈[1,n],j∈[0,v], that is, Step 3: Data buyers calculate γ” K =MKRoot(K' [n,v+1] ); Step 4: Data buyer’s judgment If it is not true, output ⊥, otherwise continue to execute the following steps; Step 5: Data Buyer Calculation Get data where z ij ∈Z [n,v+1] Exists in proof2, c' is obtained when the data buyer verifies proof2; Step 6: The data buyer constructs and forwards the transaction tx = {σ,addr TradC ,complete,(id,VP DB )} to the nearby roadside unit, which will further initiate this transaction to call the TradC contract complete function; Step 6: TradC executes the complete function: Judgment 1 = Veri(VP DB .did DB ,VP DB .body,VP DB .σ DB ) and VP DB .did DB Is it the identity that initiated the transaction? DB If it is not true, output ⊥; Judging VP DB .did ISP ,VP DB .did DB Is it in DidList? If not, output ⊥; Judgment Trading id .VP DB Is it equal to VP? DB If it does not hold, output ⊥; judge If it is not true, output ⊥, otherwise continue to execute the following steps; Verify that the current time is less than If the verification fails, output ⊥, otherwise continue to execute the following steps; set up transfer The amount is transferred to the data seller's account, and the deposit is returned separately. DB and deposit DS to the accounts of data buyers and data sellers.

10. The decentralized data transaction method applied in a vehicle Internet of Things environment according to any one of claims 1 to 9, characterized in that: The zero-knowledge construction process includes the data buyer constructing the proof0 sub-process, the identity service provider verifying the data buyer's proof0 sub-process, the data seller constructing the proof0 sub-process, the identity service provider verifying the data seller's proof0 sub-process, the data buyer constructing the proof1 sub-process, the data seller verifying the data buyer's proof1 sub-process, the data seller constructing the proof1 sub-process, the data buyer verifying the data seller's proof1 sub-process, the data seller constructing the proof2 sub-process, and the data buyer verifying the proof2 sub-process; The steps involved in the data buyer's proof0 sub-process are as follows: Step 1: Data buyers are randomly selected calculate Step 2: Data Buyer Calculation Step 3: The data buyer calculates z1 = r1 - c·sk DB , z2=r2-c·τ'; Step 4: Data buyer sends To identity service providers; The steps of the identity service provider's proof0 sub-process for verifying the data buyer are as follows: Step 1: Identity Service Provider Calculation Step 2: Determine the identity service provider If not, terminate and output ⊥; Step 3: Identity service provider determination If not, terminate and output ⊥; The steps involved in the data seller's proof0 sub-process are as follows: Step 1: Data sellers are randomly selected calculate Step 2: Data seller calculation Step 3: The data seller calculates z1 = r1 - c sk DS , z2=r2-c·τ'; Step 4: Data seller sends To identity service providers; The steps of the proof0 sub-process for the identity service provider to verify the data seller are as follows: Step 1: Identity Service Provider Calculation Step 2: Determine the identity service provider If not, terminate and output ⊥; Step 3: Identity service provider determination If not, terminate and output ⊥; The steps involved in the data buyer's proof1 sub-process are as follows: Step 1: Data buyers are randomly selected calculate send To data sellers; Step 2: Data buyers are randomly selected calculate Step 3: Data Buyer Calculation Step 4: Data Buyer Calculation Step 5: Data buyer sends To data sellers; The steps of the data seller's verification of the data buyer's proof1 sub-process are as follows: Step 1: Data seller calculation Step 2: Data seller judgment If not, terminate and output ⊥; Step 3: Data seller judgment If not, terminate and output ⊥; Step 4: Data seller judgment If not, terminate and output ⊥; Step 5: Data seller judgment If not, terminate and output ⊥; Step 6: Data seller judgment If not, terminate and output ⊥; Step 7: Output 1; The steps involved in the data seller's proof1 sub-process are as follows: Step 1: Data sellers are randomly selected calculate send To data buyers; Step 2: Data sellers are randomly selected calculate Step 3: Data seller calculation Step 4: Data seller calculation Step 5: Data seller sends To data sellers; The steps of the data buyer's verification of the data seller's proof1 sub-process are as follows: Step 1: Data buyer calculation Step 2: Data buyer’s judgment If not, terminate and output ⊥; Step 3: Data buyer’s judgment If not, terminate and output ⊥; Step 4: Data buyer’s judgment If not, terminate and output ⊥; Step 5: Data buyer’s judgment If not, terminate and output ⊥; Step 6: Data buyer’s judgment If not, terminate and output ⊥; Step 7: Output 1; The steps involved in the data seller's proof2 sub-process are as follows: Step 1: Data sellers are randomly selected Step 2: Data sellers are randomly selected calculate Step 3: Data seller calculates ρ ij =H(k,i,j), i∈[1,n],j∈[0,v], that is, Step 4: Data sellers calculate γ K =MKRoot(K [n,v+1] ); Here the data seller will save locally γ K ; Step 5: Data seller calculation Step 6: Data seller calculation Step 7: Data seller calculation Right now Step 8: Data seller stores locally and sends To data buyers; The steps of the data buyer's verification of proof2 sub-process are as follows: Step 1: Data buyers calculate γ' K =MKRoot(K [n,v+1] ); Step 2: Data Buyer Calculation Step 3: Data buyer’s judgment If not, terminate and output ⊥; Step 4: Data buyer’s judgment If not, terminate and output ⊥; Step 5: Data buyer’s judgment where i∈[1,n], j∈[0,v], z ij ∈Z [n,v+1] , K ij ∈K [n,v+1] , C i1 ∈C [n,1] , if it does not hold, terminate and output ⊥; Step 6: Output 1.

Images