CN115914249B - Cold chain data storage and query method and device based on block chain block classification - Google Patents
Cold chain data storage and query method and device based on block chain block classification Download PDFInfo
- Publication number
- CN115914249B CN115914249B CN202211555363.2A CN202211555363A CN115914249B CN 115914249 B CN115914249 B CN 115914249B CN 202211555363 A CN202211555363 A CN 202211555363A CN 115914249 B CN115914249 B CN 115914249B
- Authority
- CN
- China
- Prior art keywords
- block
- data
- transaction
- chain
- address
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application discloses a cold chain data storage and query method and device based on block chain block classification, comprising the following steps: the block structure of the block chain is improved, a class block identification field is added in the block head, a former class block Hash identification field is added, and a alliance chain is established. The cold chain data is divided into device data, order data, and privacy data. The device data is signed to make a transaction uplink request, the order data is symmetrically encrypted to make a uplink request, and the privacy data is asymmetrically encrypted to make a uplink request. And the alliance chain node packages the transactions with the same receiving address in the transaction buffer pool, waits for consensus after the packaging is completed, and can uplink the block after the consensus is completed. According to the application, the flexible uplink of the data is realized by classifying the blocks, the data with different functions is stored on the same block chain, meanwhile, the classified inquiry optimization is realized by a block classification mode, the search data is reduced by classification, and the inquiry speed of the block chain is improved.
Description
Technical Field
The application belongs to the technical field of block chains, and particularly relates to a cold chain data storage and query method and device based on block chain block classification.
Background
At present, cold chain logistics generally refers to a system engineering for ensuring the quality and performance of refrigerated and frozen articles in a specified low-temperature environment all the time in various links from production, storage, transportation and sales to consumption. The cold chain is a supply chain system which aims at ensuring the quality of refrigerated and frozen products and aims at keeping a low-temperature environment as a core requirement, so the requirements of the cold chain are higher and more complex than those of a common normal-temperature logistics system. Problems occur in any one link of the cold chain, which easily leads to breakage of the cold chain, thereby affecting the quality of the product and the final use of the product by consumers. However, existing cold chain data management schemes are generally based on active RFID temperature sensing tags and wireless communication technology, and are accomplished by cloud platform data storage and analysis. In this way, the data is easily tampered with maliciously, which causes unqualified cold chain logistics commodities to enter the market, and it is difficult for consumers to judge whether the purchased products have quality problems from the aspect of the products, so a more perfect cold chain data management scheme is needed to trace back to the specific cause of the problems.
The prior art combines blockchain technology with the cold chain domain based on the non-tamperable nature of the data uploaded into the blockchain. The method can realize anti-counterfeiting tracing of cold chain products and ensure benefits of consumers to a certain extent. In the prior art, cold chain data is uploaded to a blockchain for storage based on the non-tamperable nature of the data uploaded to the blockchain. The blockchain in the management mode generally adopts a blockchain with a single-chain structure, the blockchain with the single-chain structure has the characteristic that all the block data disclose private data to all nodes, and when the data is traced, the whole blockchain needs to be traced back, so that the inquiry efficiency is low. Aiming at the problem, the blockchain based on the multi-chain technology has certain advancement, but the construction of the multi-chain blockchain has the problems of high cost, copy management and the like.
Based on this, a need exists for a method that can effectively promote blockchain data storage and querying.
Disclosure of Invention
The application aims to: in order to solve the problems, the application provides a cold chain data storage and query method and device based on block chain block classification, which improve the block structure of a block chain, improve the user transaction data uplink process and the alliance link point packaging process, realize the functions of data classified storage and selectable query, and improve the flexibility of data uplink, the selectivity of block chain query and the block chain query efficiency by the method.
The technical scheme is as follows: the application provides a cold chain data storage and query method based on block chain block classification, which comprises the following steps:
step 1: improving the block structure of a block chain, adding a class block identification field into a block head, adding a former class block Hash identification field, and establishing a alliance chain;
step 2: preprocessing cold chain data, namely marking the cold chain data into equipment data D1, order data D2 and privacy data D3, signing the equipment data D1 to provide a transaction uplink request, symmetrically encrypting the order data D2 to provide a uplink request, and asymmetrically encrypting the privacy data D3 to provide a uplink request;
step 3: the alliance chain node packs the transactions with the same receiving address in the transaction buffer pool, marks CB1, CB2 and CB3 according to the filling type of the receiving address when packing, waits for consensus after packing is completed, and can uplink the block after the consensus is completed;
step 4: based on the alliance chain, the user selectively queries the alliance chain according to the authority.
Further, the specific method for establishing the alliance chain in the step 1 is as follows:
step 1.1: the block structure of the block chain is improved, a block type identifier is added into a block head, and the blocks are classified into different types of blocks by filling different values;
step 1.2: adding a former type of block Hash identification field into the block header;
step 1.3: establishing a alliance chain based on the improved block structure;
step 1.4: the alliance chain comprises four types of transactions, wherein three types are transactions of deployment contracts, the remaining types are transactions of calling contracts, and the transactions of deployment contracts generate no specific receiving object in the transactions; the transaction of calling the contract needs to set the receiving address in the transaction as the address of the contract on the chain;
step 1.4.1: the transaction of the deployment contract in step 1.4, identifying different data transactions by specifying different receiving addresses;
step 1.4.2: the reception address of the transaction containing the device data D1 is specified as 0x0;
step 1.4.3: the receiving address of the transaction containing the order data D2 is specified as 1x1;
step 1.4.4: the received address of the transaction containing the private data D3 is specified as 2x2.
Further, the uplink request of the device data D1 in the step 2 specifically includes:
the device data D1 is provided with a uplink request by a block chain user plaintext; the user creates a transaction comprising a send address, a receive address 0x0, device data D1, a transaction signature.
Further, in the step 2, the order data D2 is AES-symmetrically encrypted and then a request for uplink is made:
step 2.3.1: based on a random function, generatingSymmetric encryption key k n ；
Step 2.3.2: order data D2 and encryption key k are encrypted by an AES symmetric encryption function n Encrypting to obtain ciphertext MD2;
step 2.3.3: the user creates a transaction, wherein the transaction comprises a sending address, a receiving address 1x1, a ciphertext MD2 and a transaction signature.
Further, in the step 2, the privacy data D3 is asymmetrically encrypted and then a uplink request is provided:
step 2.4.1: generating a symmetric encryption key pair { public key pk based on a random function n Private key sk n }；
Step 2.4.2: private data and public key pk through RSA asymmetric encryption function n Encrypting to obtain ciphertext MD3;
step 2.4.3: the user creates a transaction, wherein the transaction comprises a sending address, a receiving address 2x2, a ciphertext MD3 and a transaction signature.
Further, the specific method of the step 3 is as follows:
step 3.1: the node searches the transaction buffer pool, checks transaction content, and fills the class block identifier according to the receiving address;
step 3.2: a block filling type block identifier CB1 with a receiving address of 0x0, a block filling type block identifier CB2 with a receiving address of 1x1, and a block filling type block identifier CB3 with a receiving address of 2x 2;
step 3.3: filling a previous block Hash value, filling a previous type of block Hash value, and filling other fields to obtain a complete block header;
step 3.4: continuing to search the transaction buffer pool and adding other transactions with the same receiving address into the block;
step 3.5: stopping packaging transaction when the set capacity of the block is reached, broadcasting the block to the whole network, and waiting for consensus;
step 3.6: the blocks are commonly identified by using a practical Bayesian and busy family PBFT common identification algorithm, and the latest block is formed after the common identification is completed.
The application also discloses a cold chain data storage and query device based on the block chain block classification, which comprises a memory, a processor and a computer program stored on the memory and capable of running on the processor, wherein the computer program realizes the steps of the cold chain data storage and query method based on the block chain block classification when being loaded to the processor.
The application adopts the technical scheme and has the following beneficial effects:
the application realizes the storage and inquiry of cold chain data by utilizing an improved block chain block structure based on the existing block chain technology, and is specifically described as follows: by improving the block chain block data structure, a block chain with different types of blocks is formed for storing cold chain data with different properties. The data flexible uplink is realized by classifying the blocks, the data with different functions is stored on the same block chain, meanwhile, the classified inquiry optimization is realized by a block classification mode, the search data is reduced by classification, and the inquiry speed of the block chain is improved.
Drawings
FIG. 1 is a flow chart of a method and apparatus for cold chain data storage and querying based on blockchain block classification;
FIG. 2 is a diagram of a federated chain;
FIG. 3 is a block diagram of a federated chain;
FIG. 4 is a flow chart of a cold chain user creation transaction;
FIG. 5 is a flowchart of a federation link point packaging transaction.
Detailed Description
The present application is further illustrated below in conjunction with specific embodiments, it being understood that these embodiments are meant to be illustrative of the application and not limiting the scope of the application, and that modifications of the application, which are equivalent to those skilled in the art to which the application pertains, fall within the scope of the application defined in the appended claims after reading the application.
Step 1: the block chain block structure is improved, a class block identification field is added in a block head, a former class block Hash identification field is added, and a alliance chain is established, wherein the specific method comprises the following steps:
step 1.1: the block chain block structure is improved, a block type identifier is added in the block header, and the blocks are classified into different types of blocks by filling different values.
Step 1.2: and adding a former type of block Hash field into the block head, and connecting blocks of the same type through the added Hash value.
Step 1.3: based on the improved block structure, a coalition chain is established.
Step 1.4: the alliance chain comprises four types of transactions, wherein three types are transactions of deployment contracts, the remaining types are transactions of calling contracts, and the transactions of deployment contracts generate no specific receiving object in the transactions; the transaction that invokes a contract requires that the received address in the transaction be set to the address of the on-link contract.
Deploying transactions of the contract, identifying different data transactions by specifying different received addresses; the reception address of the transaction containing the device data D1 is specified as 0x0; the receiving address of the transaction containing the order data D2 is specified as 1x1; the received address of the transaction containing the private data D3 is specified as 2x2.
Step 2: the method comprises the steps of preprocessing cold chain data, dividing and identifying the cold chain data into device data D1, order data D2 and privacy data D3, signing the device data D1 to provide a transaction uplink request, symmetrically encrypting the order data D2 to provide a uplink request, and asymmetrically encrypting the privacy data D3 to provide the uplink request. The specific method comprises the following steps:
step 2.1: cold chain data preprocessing, which divides the cold chain data into device data D1, order data D2, and privacy data D3.
Step 2.2: and judging whether the data is the private data D2, if so, jumping to the step 2.3, and if not, jumping to the step 2.6.
Step 2.3: generating a key pair { public key pk using a random number n Private key sk n }
Step 2.4: private data and public key pk by RSA asymmetric encryption function n The encryption is ciphertext MD3.
Step 2.5: the user creates a transaction, wherein the transaction comprises a sending address, a receiving address set to 2x2, a ciphertext MD3 and a transaction signature.
Step 2.6: and judging whether the data is the order data D2, if so, jumping to the step 2.7, and if not, jumping to the step 2.10.
Step 2.7: generating encryption key k using random number n 。
Step 2.8: order data D2 and encryption key k are piled up as an encryption function by AES n Encrypted as a secret bit MD2.
Step 2.9: the user creates a transaction, wherein the transaction comprises a sending address, a receiving address set to be 1x1, a ciphertext MD2 and a transaction signature.
Step 2.10: the user creates a transaction comprising a send address, a receive address 0x0, device data D1, a transaction signature.
Step 2.11: the transaction is sent to the federation chain node.
Step 2.12: the node verifies whether the transaction is legal or not through a transaction signature verification mode, if the transaction is legal, the step is skipped to 2.13, and if the transaction is not legal, the step is skipped to 2.14.
Step 2.13: the node checks whether the transaction repeatedly occurs, if not, jumps to step 2.15, otherwise jumps to step 2.14.
Step 2.14: the transaction is discarded.
Step 2.15: and adding the transaction into a transaction buffer pool, and broadcasting the transaction.
Step 3: and the alliance chain node packs the transaction with the same receiving address in the transaction buffer pool, and waits for consensus after packing is completed after CB1, CB2 and CB3 are identified according to the filling type of the receiving address in packing, and the block can be uplink after the consensus is completed. The specific method comprises the following steps:
step 3.1: the node retrieves the transaction buffer pool and looks up the transaction content.
Step 3.2: judging whether the receiving address is 0x0, if yes, jumping to step 3.3, otherwise jumping to step 3.10.
Step 3.3: filling type block identifier CB1 and filling former type block hash value CB1 n-1 。
Step 3.4: and filling other fields of the block header to obtain a complete block header.
Step 3.5: the other transactions continue to be retrieved.
Step 3.6: and judging whether the received address is 0x0 or an on-link contract address, if so, jumping to the step 3.8, otherwise, jumping to the step 3.7.
Step 3.7: and (3) putting the transaction back to the transaction buffer pool, and jumping to the step (3.5).
Step 3.8: the transaction is added to the block.
Step 3.9: and judging whether the block memory reaches the block set capacity size, if so, jumping to the step 3.27, otherwise, jumping to the step 3.5.
Step 3.10: judging whether the receiving address is 1x1, if yes, jumping to step 3.11, otherwise jumping to step 3.18.
Step 3.11: filling type block identifier CB2 and filling former type block hash value CB2 n-1 。
Step 3.12: and filling other fields of the block header to obtain a complete block header.
Step 3.13: the other transactions continue to be retrieved.
Step 3.14: and judging whether the received address is 1x1 or an on-link contract address, if so, jumping to the step 3.16, otherwise, jumping to the step 3.15.
Step 3.15: and (3) putting the transaction back to the transaction buffer pool, and jumping to the step (3.13).
Step 3.16: the transaction is added to the block.
Step 3.17: and judging whether the block memory reaches the block set capacity size, if so, jumping to the step 3.26, otherwise, jumping to the step 3.13.
Step 3.18: and judging whether the receiving address is 2x2, if so, jumping to the step 3.19, otherwise, jumping to the step 3.27.
Step 3.19: filling type block identifier CB3 and filling former type block hash value CB3 n-1 。
Step 3.20: and filling other fields of the block header to obtain a complete block header.
Step 3.21: the other transactions continue to be retrieved.
Step 3.22: and judging whether the received address is 2x2 or an on-link contract address, if so, jumping to the step 3.24, otherwise, jumping to the step 3.21.
Step 3.23: and (3) putting the transaction back to the transaction buffer pool, and jumping to the step 3.21.
Step 3.24: the transaction is added to the block.
Step 3.25: and judging whether the block memory reaches the block set capacity size, if so, jumping to the step 3.27, otherwise, jumping to the step 3.21.
Step 3.26: and placing the transaction back into the transaction buffer pool.
Step 3.27: stopping the current block transaction from being added and waiting for block consensus.
Step 3.28: the blocks are commonly identified by using a practical Bayesian-Preemption (PBFT) consensus algorithm, and the completion of the consensus becomes the latest block.
Step 4: based on the alliance chain, a user can selectively inquire transactions on the alliance chain according to the authority, and the specific method comprises the following steps:
step 4.1: the transaction data of a certain type of block can be queried, the alliance chain is searched according to the type of block identification, and the transaction data is traced back according to the hash value of the former type of block.
Step 4.1.1: when inquiring the class block CB1 transaction, the related plaintext equipment data D1 can be directly inquired.
Step 4.1.2: when inquiring the class block CB2 transaction, the ciphertext data MD2 can be obtained and have the key k n The ciphertext may be decrypted to obtain order data D2.
Step 4.1.3: when inquiring the class block CB3 transaction, the ciphertext data MD3 with the private key sk can be obtained n The node(s) of (c) may decrypt the ciphertext to obtain the private data D3.
Step 4.2: the whole block chain can be queried, all blocks can be queried, and transaction data can be traced back according to the Hash of the previous block.
The foregoing embodiments are merely illustrative of the technical concept and features of the present application, and are not intended to limit the scope of the application in any way, as will be apparent to those skilled in the art from the following detailed description. All equivalent changes or modifications made in accordance with the spirit of the application should be made within the scope of the present application.
Claims (7)
1. The cold chain data storage and query method based on the block chain block classification is characterized by comprising the following steps:
step 1: improving the block structure of a block chain, adding a block-like identification field in a block header, adding a block Hash identification field with the same type as the former block, and establishing a alliance chain;
step 2: cold chain data preprocessing to identify cold chain data partitions as device dataD1Order dataD2Private dataD3Device dataD1After signing, a transaction uplink request is put forward, order dataD2Providing a uplink request after symmetric encryption, and privacy dataD3The uplink request is put forward after asymmetric encryption;
step 3: the alliance chain node packs the transactions with the same receiving address in the transaction buffer pool, marks CB1, CB2 and CB3 according to the filling type of the receiving address when packing, waits for consensus after packing is completed, and can uplink the block after the consensus is completed;
step 4: based on the alliance chain, a user selectively inquires the alliance chain according to the authority, searches the alliance chain according to the class block identifier, and backtracks transaction data according to the Hash value in the block Hash identifier field with the same previous type.
2. The method for storing and querying cold chain data based on blockchain classification as in claim 1, wherein the specific method for establishing the coalition chain in step 1 is as follows:
step 1.1: the block structure of the block chain is improved, a block type identifier is added into a block head, and the blocks are classified into different types of blocks by filling different values;
step 1.2: adding a block Hash identification field with the same type as the previous block into the block header;
step 1.3: establishing a alliance chain based on the improved block structure;
step 1.4: the alliance chain comprises four types of transactions, wherein three types are transactions of deployment contracts, the other types are transactions of calling contracts, and the transactions of deployment contracts do not need to be appointed for receiving objects in the generation transactions; the transaction of calling the contract needs to set the receiving address in the transaction as the address of the contract on the chain;
step 1.4.1: the transaction of the deployment contract in step 1.4, identifying different data transactions by specifying different receiving addresses;
step 1.4.2: containing device dataD1The received address of the transaction is specified as 0x0;
step 1.4.3: containing order dataD2The received address of the transaction is specified as 1x1;
step 1.4.4: containing private dataD3The received address of the transaction is specified as 2x2.
3. The method for storing and querying cold chain data based on blockchain classification as in claim 1, wherein the device data in step 2D1Specifically, the uplink request of (1) is:
device dataD1The block chain user plaintext proposes a uplink request; a user creates a transaction comprising a transmitting address, a receiving address 0x0, and device dataD1Transaction signature.
4. The method for storing and querying cold chain data based on blockchain classification as in claim 1, wherein the order data in step 2D2After AES symmetric encryption, the uplink request is proposed:
step 2.3.1: generating symmetric encryption keys based on a random functionk n ；
Step 2.3.2: order data by AES symmetric encryption functionD2Encryption keyk n Encryption as ciphertextMD2；
Step 2.3.3: a user creates a transaction, wherein the transaction comprises a transmitting address, a receiving address 1x1 and a ciphertextMD2Transaction signature.
5. The method for storing and querying cold chain data based on blockchain block classification as in claim 1, wherein the step 2 is performed on private dataD3After asymmetric encryptionAnd (3) making a uplink request:
step 2.4.1: generating a symmetric encryption key pair based on a random function, a public keypk n Private keysk n ；
Step 2.4.2: private data and public key by RSA asymmetric encryption functionpk n Encryption as ciphertextMD3；
Step 2.4.3: a user creates a transaction, wherein the transaction comprises a sending address, a receiving address 2x2 and ciphertextMD3Transaction signature.
6. The method for storing and querying cold chain data based on blockchain classification as in claim 1, wherein the specific method in step 3 is as follows:
step 3.1: the node searches the transaction buffer pool, checks transaction content, and fills the class block identifier according to the receiving address;
step 3.2: a block filling type block identifier CB1 with a receiving address of 0x0, a block filling type block identifier CB2 with a receiving address of 1x1, and a block filling type block identifier CB3 with a receiving address of 2x 2;
step 3.3: filling a Hash value of a previous block, filling Hash values in a Hash identification field of the previous block with the same type, and filling other fields to obtain a complete block header;
step 3.4: continuing to search the transaction buffer pool and adding the transaction with the same receiving address into the block;
step 3.5: stopping packaging transaction when the set capacity of the block is reached, broadcasting the block to the whole network, and waiting for consensus;
step 3.6: and the blocks are subjected to consensus by using a practical Bayesian and busy family PBFT consensus algorithm, and the latest block is formed after the consensus is completed.
7. A blockchain-based cold chain data storage and querying device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the computer program when loaded into the processor implements the steps of the blockchain-based cold chain data storage and querying method as claimed in any of claims 1-6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211555363.2A CN115914249B (en) | 2022-12-05 | 2022-12-05 | Cold chain data storage and query method and device based on block chain block classification |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211555363.2A CN115914249B (en) | 2022-12-05 | 2022-12-05 | Cold chain data storage and query method and device based on block chain block classification |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115914249A CN115914249A (en) | 2023-04-04 |
| CN115914249B true CN115914249B (en) | 2023-09-29 |
Family
ID=86489465
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211555363.2A Active CN115914249B (en) | 2022-12-05 | 2022-12-05 | Cold chain data storage and query method and device based on block chain block classification |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115914249B (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105630609A (en) * | 2016-02-24 | 2016-06-01 | 杭州复杂美科技有限公司 | Block chain packing and storing method |
| CN109040341A (en) * | 2018-08-27 | 2018-12-18 | 深圳前海益链网络科技有限公司 | Intelligent contract address generating method, device, computer equipment and readable storage medium storing program for executing |
| CN109687953A (en) * | 2018-12-24 | 2019-04-26 | 杭州复杂美科技有限公司 | Classification of business transaction method, equipment and storage medium |
| CN113127908A (en) * | 2021-04-29 | 2021-07-16 | 郑杰骞 | Chain structure address generation method, chain structure address generation device, transaction data processing method, transaction data processing device and storage medium |
| CN115186296A (en) * | 2022-07-15 | 2022-10-14 | 中国石油大学(华东) | Process tracing method and device for oil field sensitive data |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20200085095A (en) * | 2019-01-04 | 2020-07-14 | 삼성전자주식회사 | Electronic apparatus and method for managing data based on block chain |
| CN111681017B (en) * | 2020-08-14 | 2020-12-11 | 支付宝(杭州)信息技术有限公司 | Goods batch true checking method and device based on block chain and electronic equipment |
-
2022
- 2022-12-05 CN CN202211555363.2A patent/CN115914249B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105630609A (en) * | 2016-02-24 | 2016-06-01 | 杭州复杂美科技有限公司 | Block chain packing and storing method |
| CN109040341A (en) * | 2018-08-27 | 2018-12-18 | 深圳前海益链网络科技有限公司 | Intelligent contract address generating method, device, computer equipment and readable storage medium storing program for executing |
| CN109687953A (en) * | 2018-12-24 | 2019-04-26 | 杭州复杂美科技有限公司 | Classification of business transaction method, equipment and storage medium |
| CN113127908A (en) * | 2021-04-29 | 2021-07-16 | 郑杰骞 | Chain structure address generation method, chain structure address generation device, transaction data processing method, transaction data processing device and storage medium |
| CN115186296A (en) * | 2022-07-15 | 2022-10-14 | 中国石油大学(华东) | Process tracing method and device for oil field sensitive data |
Non-Patent Citations (3)
| Title |
|---|
| Ledger design language designing and deploying formally verified public ledgers;Nadim Kobeissi etal.;《2018 IEEE European Symposium on Security and Privacy Workshops》;全文 * |
| 冷链物流智能配载推荐系统的设计研究;万玉龙 等;《农村科学实验》(第9期);全文 * |
| 基于区块链技术的农产品信息追溯系统模型研究;范立南;《物流科技》(第12期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115914249A (en) | 2023-04-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Guan et al. | Toward privacy-preserving cybertwin-based spatiotemporal keyword query for ITS in 6G era | |
| US8595504B2 (en) | Light weight authentication and secret retrieval | |
| US9438412B2 (en) | Computer-implemented system and method for multi-party data function computing using discriminative dimensionality-reducing mappings | |
| US9391965B2 (en) | Data search device, data search method, data search program, data registration device, data registration method, data registration program, and information processing device | |
| CN110166411A (en) | A kind of data transmission method, device and network node | |
| US20090138698A1 (en) | Method of searching encrypted data using inner product operation and terminal and server therefor | |
| US20170308580A1 (en) | Data Aggregation/Analysis System and Method Therefor | |
| CN104967693A (en) | Document similarity calculation method facing cloud storage based on fully homomorphic password technology | |
| CN109361644B (en) | Fuzzy attribute based encryption method supporting rapid search and decryption | |
| CN110430039A (en) | A kind of production management system and method based on block chain | |
| CN112131227A (en) | Data query method and device based on alliance chain | |
| CN109643324B (en) | Encrypted message searching method, message transmitting and receiving system, terminal and medium | |
| US20240104234A1 (en) | Encrypted information retrieval | |
| CN108604984A (en) | For the encrypted method and system of interest in content center network | |
| US20170322977A1 (en) | Method for retrieving encrypted graph, system for retrieving encrypted graph, and computer | |
| CN115834200A (en) | Attribute-based searchable encryption data sharing method based on block chain | |
| CN104166821B (en) | A kind of method and apparatus of data processing | |
| CN106789008B (en) | Method, device and system for decrypting sharable encrypted data | |
| CN111311288A (en) | Block chain based distributed commodity storage tracing method and system | |
| US20190340391A1 (en) | Multiple message retrieval for secure electronic communication | |
| CN115914249B (en) | Cold chain data storage and query method and device based on block chain block classification | |
| CN110765488A (en) | Data storage and reading method and electronic equipment | |
| CN103414703B (en) | Based on safe subscription delivery system and the method for radio sensing network and cloud computing | |
| CN110245965B (en) | Safety method for ice cream stick data processing system and ice cream stick with two-dimensional code | |
| US20230006813A1 (en) | Encrypted information retrieval |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |