CN111447069A - Low-frequency access data processing method based on block chain - Google Patents

Low-frequency access data processing method based on block chain Download PDF

Info

Publication number
CN111447069A
CN111447069A CN202010206961.3A CN202010206961A CN111447069A CN 111447069 A CN111447069 A CN 111447069A CN 202010206961 A CN202010206961 A CN 202010206961A CN 111447069 A CN111447069 A CN 111447069A
Authority
CN
China
Prior art keywords
block
data
verified
hash value
access
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.)
Granted
Application number
CN202010206961.3A
Other languages
Chinese (zh)
Other versions
CN111447069B (en
Inventor
李茂材
蓝虎
王宗友
朱耿良
刘攀
周开班
时一防
刘区城
黄焕坤
杨常青
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202010206961.3A priority Critical patent/CN111447069B/en
Publication of CN111447069A publication Critical patent/CN111447069A/en
Application granted granted Critical
Publication of CN111447069B publication Critical patent/CN111447069B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Mining & Analysis (AREA)
  • Computer And Data Communications (AREA)

Abstract

The embodiment of the application discloses a low-frequency access data processing method based on a block chain, which comprises the following steps: receiving a verification request sent by a verification request party; acquiring a block where data to be checked is located in a preset block storage area according to a block identifier of the block where the data to be checked is located, and acquiring a block hash value of the block from a block head of the block where the data to be checked is located; receiving data hash values of other data in the block where the data to be verified returned by the cold standby center platform are located; obtaining a first hash value to be verified according to the hash value of the data to be verified and the data hash values of other data; if the block hash value is consistent with the first hash value to be verified, the verification is passed, and a message of successful verification is returned to the verification request party. By the method and the device, the storage cost of the block link point system can be reduced, and the data access speed is improved.

Description

Low-frequency access data processing method based on block chain
Technical Field
The application relates to the technical field of computers, in particular to a low-frequency access data processing method based on a block chain.
Background
Based on the situation that the speed of data addition is slow or even how small the data is added, the data stored in the system is continuously increased along with the continuous increase of the running time of the block chain node system, so that the problems that the storage cost of the block chain node system is too high and the data access speed is slow are caused.
Content of application
The embodiment of the application provides a low-frequency access data processing method and device based on a block chain, a service node and a storage medium, so that the storage cost of a block chain node system is reduced, and the data access speed is improved.
An embodiment of the present application provides a block chain-based low-frequency access data processing method, including:
the service node receives a verification request sent by a verification request party, wherein the verification request comprises a block identifier of a block where the data to be verified is located and a hash value of the data to be verified;
acquiring a block where the data to be checked is located in a preset block storage area according to the block identification of the block where the data to be checked is located, and acquiring a block hash value of the block from a block head of the block where the data to be checked is located;
inquiring whether a block body exists in the block where the data to be verified is located, if not, sending a block identifier of the block where the data to be verified is located and the hash value of the data to be verified to a cold standby center platform, so that the cold standby center platform obtains the block body of the block where the data to be verified is located according to the block identifier of the block where the data to be verified is located;
receiving data hash values of other data in the block where the data to be verified is returned by the cold standby center platform;
obtaining a first hash value to be verified according to the hash value of the data to be verified and the data hash values of the other data;
and if the block hash value is consistent with the first hash value to be verified, the verification is passed, and a message of successful verification is returned to the verification request party.
An embodiment of an aspect of the present application provides a low frequency access data processing apparatus based on a block chain, including:
the verification request receiving module is used for receiving a verification request sent by a verification request party, wherein the verification request comprises a block identifier of a block where the data to be verified is located and a hash value of the data to be verified;
the first block hash acquisition module is used for acquiring a block where the data to be checked is located in a preset block storage area according to the block identification of the block where the data to be checked is located, and acquiring a block hash value of the block from a block head of the block where the data to be checked is located;
the first query sending module is used for querying whether a block body exists in the block where the data to be verified is located, if not, sending the block identifier of the block where the data to be verified is located and the hash value of the data to be verified to the cold standby central platform, so that the cold standby central platform obtains the block body of the block where the data to be verified is located according to the block identifier of the block where the data to be verified is located;
the first receiving module is used for receiving data hash values of other data in the block where the data to be verified is located, and the data hash values are returned by the cold standby center platform;
the first calculation module is used for obtaining a first hash value to be verified according to the hash value of the data to be verified and the data hash values of the other data;
and the message returning module is used for returning a message of successful verification to the verification request party if the block hash value is consistent with the first hash value to be verified and the verification passes.
In one aspect, the present embodiment provides a service node, including a processor, a memory, and a transceiver, where the processor, the memory, and the transceiver are connected to each other, where the memory is used to store a computer program that supports the electronic device to execute the above low frequency access data processing method based on a blockchain, and the computer program includes program instructions; the processor is configured to call the program instruction to execute the block chain-based low-frequency access data processing method as described in an aspect of the embodiment of the present application.
In one aspect, an embodiment of the present invention provides a storage medium, where a computer program is stored in the storage medium, where the computer program includes program instructions; the program instructions, when executed by a processor, cause the processor to perform a block chain based low frequency access data processing method as described above in an aspect of an embodiment of the present application.
In the embodiment of the application, the service node receives a verification request sent by a verification request party, acquires a block where data to be verified is located in a preset block storage area according to a block identifier of a block where the data to be verified is located in the verification request, acquires a block hash value of the block from a block header of the block where the data to be verified is located, inquires whether a block exists in the block where the data to be verified, if the block identifier of the block where the data to be verified is located and the hash value of the data to be verified do not exist, sends the block identifier of the block where the data to be verified is located and the hash value of the data to be verified to the cold standby center platform, acquires other data in the block where the data to be verified is located according to the block identifier of the block where the data to be verified is located and the hash value of the data to be verified, returns the data hash value of the other data to be verified to the service node, and obtains a, if the block hash value is consistent with the first hash value to be verified, the verification is passed, and a message of successful verification is returned to the verification request party, so that the storage cost of the block link point system can be reduced, and the data access speed can be improved.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.
FIG. 1a is a schematic diagram of a system architecture according to an embodiment of the present application;
fig. 1b is a block chain diagram according to an embodiment of the present disclosure;
fig. 2 is a schematic flowchart of a low-frequency access data processing method based on a block chain according to an embodiment of the present application;
fig. 3 is a schematic view of a scenario for generating a first hash value to be verified according to an embodiment of the present application;
4a-4b are schematic flow diagrams of a method for processing low-frequency access data based on a block chain according to an embodiment of the present application;
fig. 5 is a schematic diagram illustrating a scenario of uplink access events in a block where access data is located according to an embodiment of the present application;
fig. 6 is a schematic structural diagram of a low frequency access data processing apparatus based on a block chain according to an embodiment of the present application;
fig. 7 is a schematic structural diagram of a service node according to an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
Please refer to fig. 1a, which is a schematic diagram of a system architecture according to an embodiment of the present application. At present, with the rapid development of network technology and the importance of each large enterprise on data security, a block chain is greatly valued and applied; the low-frequency access data processing method mainly comprises the steps that low-frequency access data are stored in a block chain node system, and when the low-frequency access data are needed, the low-frequency access data are obtained from the block chain node, however, as the running time of the block chain node system increases, the data stored in the system also continuously increases, so that the problems of high storage cost and slow data access speed are caused, and at this time, the low-frequency access data processing method provided by the embodiment of the application needs to be used for processing the low-frequency access data in the block chain network. As shown in fig. 1a, the system architecture diagram includes a block chain node system operating in a block chain network, a cold standby center platform, a verification requester and a terminal where the verification requester is located, where the block chain node system is a system for performing data sharing between nodes. As shown in fig. 1a, the block link point system may specifically include node 100a, node 100b, nodes 100c, …, and node 100 n. Wherein node 100a is a serving node.
The node, the cold standby center platform, and the terminal where the verification request party is located in the block link Point system may be computer devices, including a mobile phone, a tablet computer, a notebook computer, a palm computer, an intelligent sound, a mobile internet device (MID, mobile internet device), a Point Of Sale (POS) machine, a wearable device (e.g., a smart watch, a smart bracelet, etc.), and the like.
In addition, a plurality of nodes can be included in the block-link point system, each node can receive input information during normal operation, and the shared data in the block-link point system is maintained based on the received input information. In order to ensure information intercommunication in the block link point system, information connection can exist between each node in the block link point system, and information transmission can be carried out between the nodes through the information connection. For example, when any node in the blockchain node system receives input information, other nodes in the blockchain node system acquire the input information according to a consensus algorithm, and store the input information as data in shared data, so that the data stored in all nodes in the blockchain node system are consistent.
Each node in the block chain node point system has a corresponding node identifier, and each node in the block chain node point system can store the node identifiers of other nodes in the block chain node point system, so that the generated block can be broadcast to other nodes in the block chain node point system according to the node identifiers of other nodes. Each node may maintain a node identifier list as shown in the following table, and store the node name and the node identifier in the node identifier list correspondingly. The node identifier may be an IP (Internet Protocol) address and any other information that can be used to identify the node, and table 1 only illustrates the IP address as an example.
TABLE 1
Node name Node identification
Node 1 117.114.151.174
Node 2 117.116.189.145
… …
Node N 119.123.789.258
Each node in the blockchain nodal system stores one identical blockchain. A block chain is composed of a plurality of blocks, please refer to fig. 1b, which is a block chain diagram provided in the present embodiment of the present application, as shown in fig. 1b, the block chain is composed of a plurality of blocks, a starting block includes a block header and a block main body, the block header stores an input information characteristic value, a version number, a timestamp and a difficulty value, and the block main body stores input information; the next block of the starting block takes the starting block as a parent block, the next block also comprises a block head and a block main body, the block head stores the input information characteristic value of the current block, the block head characteristic value of the parent block, the version number, the timestamp and the difficulty value, and the like, so that the block data stored in each block in the block chain is associated with the block data stored in the parent block, and the safety of the input information in the block is ensured.
In view of the problems existing in the low-frequency access data processing method, the embodiment of the present application provides a low-frequency access data processing method based on a block chain, where the block chain is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission (P2P transmission), consensus mechanism, encryption algorithm, and the like, and is essentially a decentralized database; the blockchain can be composed of a plurality of serial transaction records (also called blocks) which are connected in series by cryptography and protect the contents, and the distributed accounts connected in series by the blockchain can effectively record the transactions by multiple parties and can permanently check the transactions (can not be tampered). The consensus mechanism is a mathematical algorithm for establishing trust and obtaining rights and interests among different nodes in the block chain network; that is, the consensus mechanism is a mathematical algorithm commonly recognized by network nodes in the blockchain.
Further, as shown in fig. 1a, in the process of implementing the low frequency access data processing method, the check requester sends a check request to the service node 100a through the terminal where the check requester is located, where the check request includes the block identifier of the block where the data to be checked is located and the hash value of the data to be checked, after receiving the check request, the service node 100a obtains the block where the data to be checked is located in the preset block storage area according to the block identifier of the block where the data to be checked is located, obtains the block hash value of the block from the block header of the block where the data to be checked is located, then queries whether the block exists in the block where the data to be checked is located, if not, sends the block identifier of the block where the data to be checked is located and the hash value of the data to be checked to the cold standby center platform, according to the block identifier of the block where the data to be checked is located, the method comprises the steps of obtaining a block body of a block where data to be verified are located, finding the data to be verified in the block body according to a hash value of the data to be verified, further obtaining other data except the data to be verified, sending the hash value of the other data to a service node, calculating by the service node according to the hash value of the data to be verified and the hash value of the other received data to obtain a first hash value to be verified, comparing the first hash value to be verified with the block hash value of the block, if the first hash value to be verified is consistent with the block hash value of the block, passing verification, and sending a message of successful verification to a verification request party.
Further, please refer to fig. 2, which is a flowchart illustrating a low frequency access data processing method based on a block chain according to an embodiment of the present application. As shown in fig. 2, the method may include:
step S101, a service node receives a verification request sent by a verification request party, wherein the verification request comprises a block identifier of a block where to-be-verified data is located and a hash value of the to-be-verified data.
Step S102, according to the block identification of the block where the data to be checked is located, the block where the data to be checked is located is obtained in the preset block storage area, and the block hash value of the block is obtained from the block head of the block where the data to be checked is located.
The block identifier of the block in which the data to be verified is located may be a block height of the block in which the data to be verified is located.
For example, the service node obtains a block with a block height of 500 in a preset block storage area according to a block identifier of a block in which the data to be checked is located, that is, a block height of 500, and obtains a block Hash value of the block from a block header of the block as Hash 1-8.
Step S103, inquiring whether a block body exists in the block where the data to be checked is located, if not, sending the block identifier of the block where the data to be checked is located and the hash value of the data to be checked to the cold standby center platform, so that the cold standby center platform obtains the block body of the block where the data to be checked is located according to the block identifier of the block where the data to be checked is located.
Specifically, the service node inquires whether a block body exists in a block where the data to be verified is located, if not, the block identification of the block where the data to be verified is located and the hash value of the data to be verified are sent to the cold standby center platform, the cold standby center platform obtains the block body of the block where the data to be verified is located according to the received block identification of the block where the data to be verified is located, finds the data to be verified in the block body of the block where the data to be verified is located according to the received hash value of the data to be verified, further obtains other data except the data to be verified, and returns the hash value of the other data in the block where the data to be verified is located to the service node.
For example, the service node queries a block where data to be checked k1 is located, that is, a block 500, to obtain that no block exists in the block, and sends a block identifier of the block where the data to be checked is located, that is, a block height 500, and a Hash value Hash1 of data to be checked k1 to the cold standby center platform, the cold standby center platform obtains the block of the block 500 according to the received block height 500, and finds a leaf node consistent with Hash1 in a merkel tree in the block according to the Hash value Hash1 of the data to be checked, so as to find data corresponding to the leaf node, that is, data to be checked k1, and further obtain other data k2-k8 from which the data to be checked k1 is removed, and returns the Hash values Hash2-Hash8 of the other data k2-k8 to the service node.
And step S104, receiving data hash values of other data in the block where the data to be verified returned by the cold standby center platform is located.
For example, the service node receives the data Hash value Hash2-Hash8 of the other data k2-k8 in the block where the data k1 to be checked is returned by the cold-standby center platform.
Step S105, obtaining a first hash value to be verified according to the hash value of the data to be verified and the hash values of other data.
In a possible implementation manner, the obtaining a first hash value to be verified according to the hash value of the data to be verified and the data hash value of the other data includes:
acquiring the position information of the data to be verified and other data in a Merckel tree from the block body of the block where the data to be verified is located;
and generating a verification Mercker tree according to the position information, the Hash value of the data to be verified and the Hash values of the other data, and determining the Mercker Hash value of the verification Mercker tree as the first Hash value to be verified.
The data to be verified and the position information of other data in the Merckel tree are the Merckel paths of the data to be verified and the other data in the Merckel tree respectively, and the service node can determine the position of the data in the Merckel tree through the Merckel path of each data.
For example, please refer to fig. 3, which is a schematic view of a scenario for generating a first hash value to be verified according to an embodiment of the present application. The service node obtains the position information of the data k1 to be verified and the data k2, … and k8 in the mercker tree from the block body of the block where the data to be verified are located, as shown in fig. 3, the position information of the data k1 to be verified starts from hash1-8, and reaches D1 after passing through hash1234, hash12 and hash1 respectively, that is, the position of the data k1 to be verified is the position of D1; the position information of the data k2 is from hash1-8, respectively passes through hash1234, hash12 and hash2, and then reaches D2, namely the position of the data k2 is the position of D2; …, respectively; the position information of the data k2 is from hash1-8, respectively passes through hash5678, hash78 and hash8, and reaches D8, namely the position of the data k8 is D8. The leftmost side of the Merckel tree is the data k1 to be checked according to the position information of the data, then the data k2, k3, k4, k5, k6 and k7 are arranged in sequence from right, and the data k8 is positioned at the rightmost side of the Merckel tree. The service node calculates and generates a verification Mercker tree according to the Hash value Hash1 of the data to be verified k1 and the Hash values Hash2-Hash8 of other data k2-k8 in the Mercker tree respectively according to the position information of the data to be verified k1 and the other data k2-k8 in the Mercker tree, and determines the Mercker Hash value Hash 1-8' of the verification Mercker tree as a first verification Hash value.
And step S106, if the block hash value is consistent with the first hash value to be verified, the verification is passed, and a message of successful verification is returned to the verification request party.
For example, the service node compares the chunk Hash value Hash1-8 obtained in step S102 with the first check Hash value Hash1-8 'obtained in step S105, and obtains that the Hash1-8 is consistent with the Hash 1-8', and then the check is passed, and a message that the check is successful is returned to the check requester.
In the embodiment of the application, the service node receives a verification request sent by a verification request party, acquires a block where data to be verified is located in a preset block storage area according to a block identifier of a block where the data to be verified is located in the verification request, acquires a block hash value of the block from a block header of the block where the data to be verified is located, inquires whether a block exists in the block where the data to be verified, if the block identifier of the block where the data to be verified is located and the hash value of the data to be verified do not exist, sends the block identifier of the block where the data to be verified is located and the hash value of the data to be verified to the cold standby center platform, acquires other data in the block where the data to be verified is located according to the block identifier of the block where the data to be verified is located and the hash value of the data to be verified, returns the data hash value of the other data to be verified to the service node, and obtains a, if the block hash value is consistent with the first hash value to be verified, the verification is passed, and a message of successful verification is returned to the verification request party, so that the storage cost of the block link point system can be reduced, and the data access speed can be improved.
Please refer to fig. 4a-4b, which are schematic flow charts of a low frequency access data processing method based on a block chain according to an embodiment of the present application. As shown in fig. 4a, the method may include:
step S201, the service node acquires the low frequency access block, and sends the block of the low frequency access block to the cold-standby central platform.
Specifically, the service node acquires a low-frequency access block from a preset block storage area according to a low-frequency access condition, wherein a block body of the low-frequency access block comprises a plurality of low-frequency access data. The low-frequency access condition comprises any one of the conditions that the block height is smaller than the preset block height, the timestamp is smaller than the preset timestamp, the number of times that the block is accessed is smaller than the preset number of times, and the time that the block is accessed last is earlier than the preset time.
For example, the service node screens out the blocks 8 and 12 meeting the low-frequency access condition from the block access record according to the low-frequency access condition that the number of times the blocks are accessed is less than 3 times, acquires the blocks 8 and 12 from the preset block storage area, and sends the block of the block 8 and the block of the block 12 to the cold-standby central platform.
And step S202, the cold standby center platform returns a data receiving confirmation message.
Specifically, after receiving the block of the low-frequency access block sent by the service node, the cold standby center platform returns a data reception confirmation message to the service node.
In step S203, the service node deletes the block of the low frequency access block.
Specifically, the service node deletes the block of the low-frequency access block in the preset block storage area when receiving a data reception confirmation message returned by the cold standby center platform.
Step S204, the service node sends the message of deleting the block body of the low-frequency access block to other nodes, wherein the message carries the account signature of the service node.
And the other nodes are other nodes except the service node in the block chain network.
In step S205, the other nodes check the account signature of the service node, and if the check is passed, delete the block body of the low frequency access block.
Specifically, the other nodes acquire the signature verification public key of the service node, the signature verification public key of the service node is used for verifying the account number signature of the service node to obtain a first check code, further, the hash algorithm is used for converting the message of deleting the block body of the low-frequency access block into a second check code, and if the first check code is consistent with the second check code and the check is passed, the block body of the low-frequency access block in the block storage area is deleted.
For example, a node a in the block chain network obtains a signature verification public key of the service node, applies the signature verification public key of the service node to verify the account signature of the service node to obtain a hash1, calculates a message for deleting the block body of the low frequency access block by using a hash algorithm to obtain a hash2, and deletes the block body of the low frequency access block 12 in the block storage region in the node a if the check is passed, if the hash1 is consistent with the hash 2.
Referring to fig. 4b, a flowchart of a low frequency access data processing method based on a block chain according to an embodiment of the present application is shown. As shown in fig. 4b, the method may further include:
step S206, the data access party sends an access request to the service node.
The access request comprises a block identification of a block where the access data are located and a hash value of the access data.
In step S207, the service node obtains the block where the access data is located and the block hash value of the block, and queries whether a block exists in the block.
Specifically, the service node acquires the block where the access data is located in the preset block storage area according to the block identifier of the block where the access data is located, acquires the block hash value of the block from the block header of the block where the access data is located, and inquires whether the block exists in the block where the access data is located.
For example, the service node obtains a block with a block height of 100 in a preset storage area according to a block identifier of a block where the access data is located, that is, a block height of 100, obtains a block Hash value of the block from a block header of the block as Hash1-50, and obtains that no block exists in the block. After that, step S208 is executed.
Step S208, if the access data does not exist, the service node sends the block identification of the block where the access data is located and the hash value of the access data to the cold-standby center platform.
Step S209, the cold standby center platform obtains a block body of a block where the access data is located.
Specifically, the cold standby center platform acquires the block body of the block where the access data is located according to the block identifier of the block where the received access data is located, acquires the access data in the block body of the block where the access data is located according to the hash value of the received access data, and further acquires other data except the access data in the block body.
For example, the cold-standby center platform obtains the block body of the block 100 according to the block identifier of the block where the received access data d2 is located, that is, the block height 100, and finds a leaf node consistent with the Hash2 in the merkel tree in the block body according to the Hash2 of the received access data d2, so as to obtain data corresponding to the leaf node, that is, the access data d2, and further obtain other data d1, d3-d50 except the access data d 2.
Step S210, the cold standby center platform returns the data hash value and the access data of the other data in the block where the access data is located to the service node.
For example, the cold-standby center platform returns the data Hash values Hash1, Hash3-Hash50 of the other data d1, d3-d50 to the service node.
In step S211, the service node calculates to obtain a second hash value to be verified.
Specifically, the service node receives the data hash value of other data in the block where the access data is returned by the cold standby center platform and the access data; and obtaining a second hash value to be verified according to the hash value of the access data and the data hash values of other data in the block where the access data is located.
In an optional embodiment, after receiving the data hash value of other data in the block where the access data is located and the access data returned by the cold standby center platform, the service node acquires the position information of the access data and the other data in the tacher tree from the block where the access data is located, generates a check tacher tree according to the position information, the hash value of the access data and the hash value of the other data, and determines the tacher hash value of the check tacher tree as a second hash value to be verified.
Here, the specific implementation manner of step S211 may refer to the description of step S105 in the corresponding embodiment, and is not described herein again.
In step S212, if the block hash value of the block is consistent with the second hash value to be verified, the service node returns access data to the data access party.
In step S213, the service node generates an accessed event of the block where the access data is located.
Specifically, the service node generates an accessed event of the block where the access data is located according to the access request, and the accessed event of the block where the access data is located carries a service node account signature.
In step S214, the service node uploads the accessed event of the block where the access data is located to the blockchain network.
In one possible implementation manner, the service node sends the accessed event of the block where the access data is located to a consensus node in a block chain network, so that the consensus node performs consensus verification on the accessed event of the block where the access data is located, and returns a consensus confirmation message when the consensus verification is passed;
and adding the block containing the accessed event of the block where the access data is located to the block chain network under the condition that the ratio of the number of the received consensus confirmation messages to the number of the consensus nodes reaches a preset consensus ratio.
Specifically, please refer to fig. 5, which is a schematic diagram illustrating a scenario that a block where access data is located is linked to an accessed event according to an embodiment of the present application. The service node generates a block accessed event where the access data is located, namely a block accessed event 701, according to the data accessing party and the access request, and acquires other block accessed events, wherein the other block accessed events include block accessed events 702 and … and a block accessed event 800, as shown in fig. 5, assuming that the number of block accessed events stored by each block (also including block 5007 and block 5008) in the block chain 500 is 100, block accessed event 1 to block accessed event 100 are stored in block 5001, and so on, block accessed event 701 to block accessed event 800 are stored in block 5008; taking the generation process of the block 5008 as an example, describing a detailed process of block generation, after the service node 50 generates the block accessed event 701, firstly verifying the block accessed event 701, storing the block accessed event 701 into a memory pool after verification is passed, updating a time stamp of a hash tree according to the obtained time stamp of the block accessed event 701, and then calculating a hash value of the block accessed event 701 by using a hash algorithm; the service processing platform 50 obtains the block accessed event 702, obtains the hash value of the block accessed event 702 through the above process until the hash value of the block accessed event 800 is obtained through calculation, then stores the block accessed event 701 to the block accessed event 800 into the block body of the block 2008, generates the hash value corresponding to the block 5008 according to the hash value of the block accessed event 701, … and the hash value of the block accessed event 800, the service node 50 generates the block 5008 to be linked according to the block header hash value of the block 5007, the hash value corresponding to the block 5008 and the block accessed event 701 to the block accessed event 800, broadcasts the block 5008 to be linked to a common node in a block chain, and checks the block 5008 to be linked by the common node, wherein the common node respectively treats the block accessed event 701, the block 5008 to be linked up by using a hash algorithm exemplarily, …, performing hash calculation on the block accessed event 800 to obtain hash values corresponding to each block accessed event in the block accessed events 701, … and the block accessed event 800, calculating to obtain check hash values according to the hash values of the block accessed event 701, … and the block accessed event 800, comparing the check hash values with the hash values corresponding to the block 5008, if the check hash values are consistent with the hash values corresponding to the block 5008, passing the consensus verification, returning a consensus confirmation message to the service node 50, and adding the block 5008 to be linked to the block chain 500 stored in the service node 50 when the ratio of the number of received consensus confirmation messages to the number of consensus nodes is confirmed to reach a preset consensus ratio (e.g. 51%).
In the embodiment of the application, after the service node sends the block of the low-frequency access block to the cold standby center platform for backup, the block of the low-frequency access block in the preset block storage area is deleted, and a message for deleting the low-frequency access block is sent to other nodes in the block chain network, and after the message is verified by the other nodes, the block of the low-frequency access block in the block storage area is deleted, so that the total data storage amount in the whole block chain node system is reduced, and the storage cost is reduced. Then, the service node receives an access request sent by a data access party, acquires a block where the access data is located in a preset block storage area according to a block identifier of a block where the access data is located in the access request, acquires a block hash value of the block from a block head of the block where the access data is located, inquires whether a block exists in the block where the access data is located, if not, sends the block identifier of the block where the access data is located and the hash value of the access data to the cold standby central platform, the cold standby central platform acquires other data in the block where the access data is located according to the block identifier of the block where the access data is located and the hash value of the access data, returns a data hash value of the other data to be verified and the access data to the service node, and acquires a second hash value to be verified according to the hash value of the access data and the data hash value of the other data, if the block hash value is consistent with the second hash value to be verified, the access data is returned to the data access party, so that the storage cost of the block link point system can be reduced, and the data access speed can be increased.
Fig. 6 is a schematic structural diagram of a low frequency access data processing apparatus based on a block chain according to an embodiment of the present application. The block chain based low frequency access data processing apparatus may be a computer program (including program code) running in a computer device, for example, an application software; the apparatus may be used to perform the corresponding steps in the methods provided by the embodiments of the present application. As shown in fig. 6, the low frequency access data processing apparatus 6 may include: a received check request module 61, a first block hash obtaining module 62, a first query sending module 63, a first receiving module 64, a first calculating module 65 and a return message module 66.
A verification request receiving module 61, configured to receive a verification request sent by a verification requesting party, where the verification request includes a block identifier of a block in which the data to be verified is located and a hash value of the data to be verified;
a first block hash obtaining module 62, configured to obtain, according to a block identifier of a block in which the data to be checked is located, the block in which the data to be checked is located in a preset block storage area, and obtain a block hash value of the block from a block header of the block in which the data to be checked is located;
the first query sending module 63 is configured to query whether a block body exists in the block in which the data to be verified is located, and if the block body does not exist, send the block identifier of the block in which the data to be verified is located and the hash value of the data to be verified to the cold standby central platform, so that the cold standby central platform obtains the block body of the block in which the data to be verified is located according to the block identifier of the block in which the data to be verified is located;
a first receiving module 64, configured to receive a data hash value of other data in a block where the data to be verified is located, where the data is returned by the cold standby center platform;
a first calculating module 65, configured to obtain a first hash value to be verified according to the hash value of the data to be verified and the data hash values of the other data;
a message returning module 66, configured to, if the chunk hash value is consistent with the first hash value to be verified, pass the verification, and return a message that the verification is successful to the verification requester.
The specific functional implementation manners of the check request receiving module 61, the first block hash obtaining module 62, the first query sending module 63, the first receiving module 64, the first calculating module 65, and the message returning module 66 may refer to steps S101 to S106 in the corresponding embodiment of fig. 2, and are not described herein again.
Referring again to fig. 6, the first calculation module 65 includes: a location unit 651 and a first hash value calculation unit 652 are acquired.
An obtaining position unit 651, configured to obtain position information of the data to be verified and other data in the mercker tree from the block body of the block where the data to be verified is located;
a first hash value calculation unit 652, configured to generate a verification tachr tree according to the location information, the hash value of the data to be verified, and the hash values of the other data, and determine the tachr hash value of the verification tachr tree as the first hash value to be verified.
The specific functional implementation manners of the obtaining position unit 651 and the first hash value calculating unit 652 may refer to step S105 in the embodiment corresponding to fig. 2, which is not described herein again.
Referring to fig. 6 again, the apparatus further includes a block sending and deleting module 67, and the block sending and deleting module 67 includes: a block acquisition unit 671, a sending unit 672 and a deletion unit 673.
A block obtaining unit 671, configured to obtain a low frequency access block from a preset block storage area according to a low frequency access condition, where a block body of the low frequency access block includes a plurality of low frequency access data; the low-frequency access condition comprises any one of the block height being smaller than the preset block height, the timestamp being smaller than the preset timestamp, the number of times the block is accessed being smaller than the preset number of times, and the time when the block is accessed last being earlier than the preset time.
A first sending unit 672, configured to send the block of the low frequency access block to a cold standby center platform;
a deleting unit 673, configured to delete the block of the low frequency access block in the preset block storage area when receiving a data reception confirmation message returned by the cold standby center platform.
The block sending and deleting module 67 further includes:
a delete message sending unit 674, configured to send, to another node in the blockchain network, a message for deleting the block of the low frequency access block, where the message carries the account signature of the service node, so that the other node verifies the account signature of the service node, and if the verification passes, deletes the block of the low frequency access block in the block storage area.
For specific functional implementation manners of the block obtaining unit 671, the first sending unit 672, the deleting unit 673 and the sending deletion message unit 674, refer to steps S201 to S205 in the embodiment corresponding to fig. 4a, which is not described herein again.
Referring to fig. 6 again, the apparatus further includes: a receive access request module 68, a second chunk hash acquisition module 69, a second query sending module 610, a second receiving module 611, a second computation module 612, and a return data module 613.
A receive access request module 68, configured to receive an access request sent by a data accessing party, where the access request includes a block identifier of a block where the access data is located and a hash value of the access data;
a second block hash obtaining module 69, configured to obtain, according to the block identifier of the block in which the access data is located, the block in which the access data is located in the preset block storage area, and obtain the block hash value of the block from the block header of the block in which the access data is located;
a second query sending module 610, configured to query whether a block exists in a block where the access data is located, and if not, send a block identifier of the block where the access data is located and a hash value of the access data to the cold-standby central platform, so that the cold-standby central platform obtains the block where the access data is located according to the block identifier of the block where the access data is located;
a second receiving module 611, configured to receive the access data and the data hash value of other data in the block where the access data is returned by the cold-standby center platform;
a second calculating module 612, configured to obtain a second hash value to be verified according to the hash value of the access data and the hash values of other data in the block where the access data is located;
a data returning module 613, configured to return the access data to the data accessing party if the block hash value of the block in which the access data is located is consistent with the second hash value to be verified.
The above-mentioned device still includes: a generate event module 614, a second send module 615, and an add module 616.
An event generating module 614, configured to generate, according to the access request, an accessed event of the block where the access data is located, where the accessed event of the block where the access data is located carries a service node account signature;
a second sending module 615, configured to send the accessed event of the block where the access data is located to a consensus node in a block chain network, so that the consensus node performs consensus verification on the accessed event of the block where the access data is located, and returns a consensus confirmation message when the consensus verification passes;
an adding module 616, configured to add, to the blockchain network, a block including an event that the block where the access data is located is accessed, when it is determined that a ratio of the number of the received consensus confirmation messages to the number of the consensus nodes reaches a preset consensus ratio.
For specific functional implementation manners of the access request receiving module 68, the second block hash obtaining module 69, the second query sending module 610, the second receiving module 611, the second calculating module 612, the data returning module 613, the event generating module 614, the second sending module 615, and the adding module 616, reference may be made to steps S206 to S212 in the embodiment corresponding to fig. 4b, which is not described herein again.
In the embodiment of the application, the service node receives a verification request sent by a verification request party, acquires a block where data to be verified is located in a preset block storage area according to a block identifier of a block where the data to be verified is located in the verification request, acquires a block hash value of the block from a block header of the block where the data to be verified is located, inquires whether a block exists in the block where the data to be verified, if the block identifier of the block where the data to be verified is located and the hash value of the data to be verified do not exist, sends the block identifier of the block where the data to be verified is located and the hash value of the data to be verified to the cold standby center platform, acquires other data in the block where the data to be verified is located according to the block identifier of the block where the data to be verified is located and the hash value of the data to be verified, returns the data hash value of the other data to be verified to the service node, and obtains a, if the block hash value is consistent with the first hash value to be verified, the verification is passed, and a message of successful verification is returned to the verification request party, so that the storage cost of the block link point system can be reduced, and the data access speed can be improved.
The block chain based low frequency access data processing apparatus 6 in the embodiment shown in fig. 6 described above may be implemented by a service node 700 shown in fig. 7. Please refer to fig. 7, which is a schematic structural diagram of a service node according to an embodiment of the present application. As shown in fig. 7, the service node 700 may include: one or more processors 701, a memory 702, and a transceiver 703. The processor 701, the memory 702, and the transceiver 703 are connected by a bus 704. The transceiver 703 is configured to obtain feedback information of a plurality of passenger accounts or send rating information of a target driver account, and the memory 702 is configured to store a computer program, where the computer program includes program instructions; the processor 701 is configured to execute the program instructions stored in the memory 702 to perform the following operations:
receiving a verification request sent by a verification request party, wherein the verification request comprises a block identifier of a block where the data to be verified is located and a hash value of the data to be verified;
acquiring a block where the data to be checked is located in a preset block storage area according to the block identification of the block where the data to be checked is located, and acquiring a block hash value of the block from a block head of the block where the data to be checked is located;
inquiring whether a block body exists in the block where the data to be verified is located, if not, sending a block identifier of the block where the data to be verified is located and the hash value of the data to be verified to a cold standby center platform, so that the cold standby center platform obtains the block body of the block where the data to be verified is located according to the block identifier of the block where the data to be verified is located;
receiving data hash values of other data in the block where the data to be verified is returned by the cold standby center platform;
obtaining a first hash value to be verified according to the hash value of the data to be verified and the data hash values of the other data;
and if the block hash value is consistent with the first hash value to be verified, the verification is passed, and a message of successful verification is returned to the verification request party.
In an embodiment, the processor 701 specifically performs the following steps when obtaining the first hash value to be verified according to the hash value of the data to be verified and the data hash values of the other data:
acquiring the position information of the data to be verified and other data in a Merckel tree from the block body of the block where the data to be verified is located;
and generating a verification Mercker tree according to the position information, the Hash value of the data to be verified and the Hash values of the other data, and determining the Mercker Hash value of the verification Mercker tree as the first Hash value to be verified.
In one embodiment, the processor 701 further performs the following steps:
acquiring a low-frequency access block from a preset block storage area according to a low-frequency access condition, wherein a block body of the low-frequency access block comprises a plurality of low-frequency access data; the low-frequency access condition comprises any one of the conditions that the block height is smaller than the preset block height, the timestamp is smaller than the preset timestamp, the number of times that the block is accessed is smaller than the preset number of times, and the time that the block is accessed last is earlier than the preset time.
Sending the block body of the low-frequency access block to a cold-standby central platform;
and deleting the block body of the low-frequency access block in the preset block storage area under the condition of receiving a data receiving confirmation message returned by the cold standby center platform.
In one embodiment, the processor 701 further performs the following steps:
and sending a message for deleting the block body of the low-frequency access block to other nodes in the block chain network, wherein the message carries the account number signature of the service node, so that the other nodes verify the account number signature of the service node, and deleting the block body of the low-frequency access block in the block storage area under the condition that the verification is passed.
In one embodiment, the processor 701 further performs the following steps:
receiving an access request sent by a data access party, wherein the access request comprises a block identifier of a block where access data are located and a hash value of the access data;
acquiring the block where the access data is located in the preset block storage area according to the block identification of the block where the access data is located, and acquiring the block hash value of the block from the block head of the block where the access data is located;
inquiring whether a block body exists in the block where the access data is located, if not, sending a block identifier of the block where the access data is located and the hash value of the access data to the cold-standby central platform, so that the cold-standby central platform obtains the block body of the block where the access data is located according to the block identifier of the block where the access data is located;
receiving data hash values of other data in the block where the access data is located and the access data returned by the cold standby center platform;
obtaining a second hash value to be verified according to the hash value of the access data and the data hash values of other data in the block where the access data is located;
and if the block hash value of the block where the access data is located is consistent with the second hash value to be verified, returning the access data to the data access party.
In one embodiment, the processor 701 further performs the following steps:
generating an accessed event of the block where the access data is located according to the access request, wherein the accessed event of the block where the access data is located carries a service node account signature;
sending the accessed event of the block where the access data is located to a consensus node in a block chain network, so that the consensus node performs consensus verification on the accessed event of the block where the access data is located, and returning a consensus confirmation message under the condition that the consensus verification is passed;
and adding the block containing the accessed event of the block where the access data is located to the block chain network under the condition that the ratio of the number of the received consensus confirmation messages to the number of the consensus nodes reaches a preset consensus ratio.
It should be understood that the service node 700 described in this embodiment may perform the description of the method for processing low frequency access data based on a block chain in the embodiment corresponding to fig. 2 and fig. 4a to 4b, and may also perform the description of the apparatus for processing low frequency access data based on a block chain in the embodiment corresponding to fig. 6, which is not described herein again. In addition, the beneficial effects of the same method are not described in detail.
Further, here, it is to be noted that: an embodiment of the present application further provides a computer-readable storage medium, where a computer program executed by the aforementioned low-frequency access data processing apparatus 6 based on a block chain is stored in the computer-readable storage medium, and the computer program includes program instructions, and when the processor executes the program instructions, the description of the low-frequency access data processing method based on the block chain in the embodiment corresponding to fig. 2 or fig. 4a to 4b can be executed, so that details are not repeated here. In addition, the beneficial effects of the same method are not described in detail. For technical details not disclosed in embodiments of the computer-readable storage medium referred to in the present application, reference is made to the description of embodiments of the method of the present application. As an example, program instructions may be deployed to be executed on one computing device or on multiple computing devices at one site or distributed across multiple sites and interconnected by a communication network, which may comprise a block chain system.
It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by a computer program, which can be stored in a computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. The storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), or the like.
The method and the related apparatus provided by the embodiments of the present application are described with reference to the flowchart and/or the structural diagram of the method provided by the embodiments of the present application, and each flow and/or block of the flowchart and/or the structural diagram of the method, and the combination of the flow and/or block in the flowchart and/or the block diagram can be specifically implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block or blocks of the block diagram. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block or blocks of the block diagram. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block or blocks.
The above disclosure is only for the purpose of illustrating the preferred embodiments of the present application and is not to be construed as limiting the scope of the present application, so that the present application is not limited thereto, and all equivalent variations and modifications can be made to the present application.

Claims (10)

1. A low-frequency access data processing method based on a block chain is characterized by comprising the following steps:
the service node receives a verification request sent by a verification request party, wherein the verification request comprises a block identifier of a block where the data to be verified is located and a hash value of the data to be verified;
acquiring a block where the data to be checked is located in a preset block storage area according to the block identification of the block where the data to be checked is located, and acquiring a block hash value of the block from a block head of the block where the data to be checked is located;
inquiring whether a block body exists in the block where the data to be verified is located, if not, sending a block identifier of the block where the data to be verified is located and the hash value of the data to be verified to a cold standby center platform, so that the cold standby center platform obtains the block body of the block where the data to be verified is located according to the block identifier of the block where the data to be verified is located;
receiving data hash values of other data in the block where the data to be verified is returned by the cold standby center platform;
obtaining a first hash value to be verified according to the hash value of the data to be verified and the data hash values of the other data;
and if the block hash value is consistent with the first hash value to be verified, the verification is passed, and a message of successful verification is returned to the verification request party.
2. The method according to claim 1, wherein obtaining the first hash value to be verified according to the hash value of the data to be verified and the data hash values of the other data comprises:
acquiring the position information of the data to be verified and other data in a Merckel tree from the block body of the block where the data to be verified is located;
and generating a verification Mercker tree according to the position information, the Hash value of the data to be verified and the Hash values of the other data, and determining the Mercker Hash value of the verification Mercker tree as the first Hash value to be verified.
3. The method of claim 1, further comprising:
acquiring a low-frequency access block from a preset block storage area according to a low-frequency access condition, wherein a block body of the low-frequency access block comprises a plurality of low-frequency access data;
sending the block body of the low-frequency access block to a cold-standby central platform;
and deleting the block body of the low-frequency access block in the preset block storage area under the condition of receiving a data receiving confirmation message returned by the cold standby center platform.
4. The method of claim 3, wherein the low frequency access condition comprises any one of a tile height less than a preset tile height, a timestamp less than a preset timestamp, a number of times a tile is accessed less than a preset number of times, and a time when a tile was last accessed earlier than a preset time.
5. The method of claim 3, further comprising:
and sending a message for deleting the block body of the low-frequency access block to other nodes in the block chain network, wherein the message carries the account number signature of the service node, so that the other nodes verify the account number signature of the service node, and deleting the block body of the low-frequency access block in the block storage area under the condition that the verification is passed.
6. The method of claim 1, further comprising:
receiving an access request sent by a data access party, wherein the access request comprises a block identifier of a block where access data are located and a hash value of the access data;
acquiring the block where the access data is located in the preset block storage area according to the block identification of the block where the access data is located, and acquiring the block hash value of the block from the block head of the block where the access data is located;
inquiring whether a block body exists in the block where the access data is located, if not, sending a block identifier of the block where the access data is located and the hash value of the access data to the cold-standby central platform, so that the cold-standby central platform obtains the block body of the block where the access data is located according to the block identifier of the block where the access data is located;
receiving data hash values of other data in the block where the access data is located and the access data returned by the cold standby center platform;
obtaining a second hash value to be verified according to the hash value of the access data and the data hash values of other data in the block where the access data is located;
and if the block hash value of the block where the access data is located is consistent with the second hash value to be verified, returning the access data to the data access party.
7. The method of claim 6, further comprising:
generating an accessed event of the block where the access data is located according to the access request, wherein the accessed event of the block where the access data is located carries a service node account signature;
sending the accessed event of the block where the access data is located to a consensus node in a block chain network, so that the consensus node performs consensus verification on the accessed event of the block where the access data is located, and returning a consensus confirmation message under the condition that the consensus verification is passed;
and adding the block containing the accessed event of the block where the access data is located to the block chain network under the condition that the ratio of the number of the received consensus confirmation messages to the number of the consensus nodes reaches a preset consensus ratio.
8. A blockchain-based low frequency access data processing apparatus, comprising:
the verification request receiving module is used for receiving a verification request sent by a verification request party, wherein the verification request comprises a block identifier of a block where the data to be verified is located and a hash value of the data to be verified;
the first block hash acquisition module is used for acquiring a block where the data to be checked is located in a preset block storage area according to the block identification of the block where the data to be checked is located, and acquiring a block hash value of the block from a block head of the block where the data to be checked is located;
the first query sending module is used for querying whether a block body exists in the block where the data to be verified is located, if not, sending the block identifier of the block where the data to be verified is located and the hash value of the data to be verified to the cold standby central platform, so that the cold standby central platform obtains the block body of the block where the data to be verified is located according to the block identifier of the block where the data to be verified is located;
the first receiving module is used for receiving data hash values of other data in the block where the data to be verified is located, and the data hash values are returned by the cold standby center platform;
the first calculation module is used for obtaining a first hash value to be verified according to the hash value of the data to be verified and the data hash values of the other data;
and the message returning module is used for returning a message of successful verification to the verification request party if the block hash value is consistent with the first hash value to be verified and the verification passes.
9. A service node, comprising a processor, a memory and a transceiver, wherein the processor, the memory and the transceiver are connected with each other, the transceiver is used for receiving or sending data, the memory is used for storing program codes, and the processor is used for calling the program codes and executing the block chain based low frequency access data processing method according to any one of claims 1-7.
10. A storage medium, characterized in that the storage medium stores a computer program comprising program instructions; the program instructions, when executed by a processor, cause the processor to perform the method of blockchain based low frequency access data processing according to any one of claims 1 to 7.
CN202010206961.3A 2020-03-23 2020-03-23 Low-frequency access data processing method based on block chain Active CN111447069B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010206961.3A CN111447069B (en) 2020-03-23 2020-03-23 Low-frequency access data processing method based on block chain

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010206961.3A CN111447069B (en) 2020-03-23 2020-03-23 Low-frequency access data processing method based on block chain

Publications (2)

Publication Number Publication Date
CN111447069A true CN111447069A (en) 2020-07-24
CN111447069B CN111447069B (en) 2021-10-26

Family

ID=71654299

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010206961.3A Active CN111447069B (en) 2020-03-23 2020-03-23 Low-frequency access data processing method based on block chain

Country Status (1)

Country Link
CN (1) CN111447069B (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112069169A (en) * 2020-07-30 2020-12-11 北京奇艺世纪科技有限公司 Block data storage method and device, electronic equipment and readable storage medium
CN112667746A (en) * 2020-12-30 2021-04-16 浙江甲骨文超级码科技股份有限公司 Block chain based data storage method and equipment, electronic device and storage equipment
CN112699416A (en) * 2021-01-04 2021-04-23 烽火通信科技股份有限公司 File storage method, file verification method and electronic equipment
CN113032489A (en) * 2021-03-29 2021-06-25 湖北央中巨石信息技术有限公司 Asynchronous consensus method, system, device and medium based on block chain
CN114826617A (en) * 2022-04-29 2022-07-29 西北工业大学 Industrial Internet of things terminal system design and data verification method and hardware acceleration device

Citations (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108615153A (en) * 2018-04-28 2018-10-02 百度在线网络技术（北京）有限公司 Processing method, device, system, equipment and the storage medium of block chain data
CN109255614A (en) * 2018-08-31 2019-01-22 深圳付贝科技有限公司 Digging mine method and device, digging mine machine and block catenary system based on block chain
CN109299336A (en) * 2018-09-30 2019-02-01 腾讯科技（深圳）有限公司 Data back up method, device, storage medium and calculating equipment
CN109409889A (en) * 2018-11-13 2019-03-01 杭州秘猿科技有限公司 A kind of block in block chain determines method, apparatus and electronic equipment
CN109408461A (en) * 2018-09-14 2019-03-01 中国农业大学 A kind of distributed memory system and method for block chain
CN109460405A (en) * 2018-09-27 2019-03-12 上海点融信息科技有限责任公司 For the block generation method of block chain network, synchronous method, storage medium, calculate equipment
CN109493044A (en) * 2018-11-08 2019-03-19 深圳壹账通智能科技有限公司 Block chain block delet method, device and terminal device
WO2019101246A2 (en) * 2019-03-21 2019-05-31 Alibaba Group Holding Limited Data isolation in blockchain networks
CN109903049A (en) * 2019-03-01 2019-06-18 长沙理工大学 A kind of block chain transaction data storage method, device, equipment and storage medium
CN110009334A (en) * 2018-11-07 2019-07-12 阿里巴巴集团控股有限公司 A kind of building Mei Keer tree, simple payment verification method and device
CN110011981A (en) * 2019-03-15 2019-07-12 湖北工程学院 A kind of credible cloud storage method and system based on block chain
CN110263035A (en) * 2019-05-31 2019-09-20 阿里巴巴集团控股有限公司 Data storage, querying method and device and electronic equipment based on block chain
WO2019228550A2 (en) * 2019-08-20 2019-12-05 Alibaba Group Holding Limited Blockchain data storage based on shared nodes and error correction code
CN110647582A (en) * 2019-09-17 2020-01-03 腾讯科技（深圳）有限公司 Method and device for block chain network consensus checking, storage medium and computer equipment
WO2020023828A1 (en) * 2018-07-27 2020-01-30 Alibaba Group Holding Limited Blockchain-based cross-chain data operation method and apparatus

Patent Citations (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108615153A (en) * 2018-04-28 2018-10-02 百度在线网络技术（北京）有限公司 Processing method, device, system, equipment and the storage medium of block chain data
WO2020023828A1 (en) * 2018-07-27 2020-01-30 Alibaba Group Holding Limited Blockchain-based cross-chain data operation method and apparatus
CN109255614A (en) * 2018-08-31 2019-01-22 深圳付贝科技有限公司 Digging mine method and device, digging mine machine and block catenary system based on block chain
CN109408461A (en) * 2018-09-14 2019-03-01 中国农业大学 A kind of distributed memory system and method for block chain
CN109460405A (en) * 2018-09-27 2019-03-12 上海点融信息科技有限责任公司 For the block generation method of block chain network, synchronous method, storage medium, calculate equipment
CN109299336A (en) * 2018-09-30 2019-02-01 腾讯科技（深圳）有限公司 Data back up method, device, storage medium and calculating equipment
CN110009334A (en) * 2018-11-07 2019-07-12 阿里巴巴集团控股有限公司 A kind of building Mei Keer tree, simple payment verification method and device
CN109493044A (en) * 2018-11-08 2019-03-19 深圳壹账通智能科技有限公司 Block chain block delet method, device and terminal device
CN109409889A (en) * 2018-11-13 2019-03-01 杭州秘猿科技有限公司 A kind of block in block chain determines method, apparatus and electronic equipment
CN109903049A (en) * 2019-03-01 2019-06-18 长沙理工大学 A kind of block chain transaction data storage method, device, equipment and storage medium
CN110011981A (en) * 2019-03-15 2019-07-12 湖北工程学院 A kind of credible cloud storage method and system based on block chain
WO2019101246A2 (en) * 2019-03-21 2019-05-31 Alibaba Group Holding Limited Data isolation in blockchain networks
CN110263035A (en) * 2019-05-31 2019-09-20 阿里巴巴集团控股有限公司 Data storage, querying method and device and electronic equipment based on block chain
WO2019228550A2 (en) * 2019-08-20 2019-12-05 Alibaba Group Holding Limited Blockchain data storage based on shared nodes and error correction code
CN110647582A (en) * 2019-09-17 2020-01-03 腾讯科技（深圳）有限公司 Method and device for block chain network consensus checking, storage medium and computer equipment

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
ILYA SUKHODOLSKIY;SERGEY ZAPECHNIKOV: ""A blockchain-based access control system for cloud storage"", 《2018 IEEE CONFERENCE OF RUSSIAN YOUNG RESEARCHERS IN ELECTRICAL AND ELECTRONIC ENGINEERING (EICONRUS)》 *
SHANGPING WANG;XU WANG;YALING ZHANG: ""A Secure Cloud Storage Framework With Access Control Based on Blockchain"", 《IEEE ACCESS》 *
史锦山: ""物联网下的区块链访问控制综述"", 《软件学报》 *
王千阁，何蒲: ""区块链系统的数据存储与查询技术综述"", 《计算机科学》 *
高艳芳等: "基于区块链的无线体域网数据云存储完整性研究", 《东北大学学报(自然科学版)》 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112069169A (en) * 2020-07-30 2020-12-11 北京奇艺世纪科技有限公司 Block data storage method and device, electronic equipment and readable storage medium
CN112069169B (en) * 2020-07-30 2023-08-15 北京奇艺世纪科技有限公司 Block data storage method and device, electronic equipment and readable storage medium
CN112667746A (en) * 2020-12-30 2021-04-16 浙江甲骨文超级码科技股份有限公司 Block chain based data storage method and equipment, electronic device and storage equipment
CN112699416A (en) * 2021-01-04 2021-04-23 烽火通信科技股份有限公司 File storage method, file verification method and electronic equipment
CN112699416B (en) * 2021-01-04 2022-04-26 烽火通信科技股份有限公司 File storage method, file verification method and electronic equipment
CN113032489A (en) * 2021-03-29 2021-06-25 湖北央中巨石信息技术有限公司 Asynchronous consensus method, system, device and medium based on block chain
CN114826617A (en) * 2022-04-29 2022-07-29 西北工业大学 Industrial Internet of things terminal system design and data verification method and hardware acceleration device

Also Published As

Publication number Publication date
CN111447069B (en) 2021-10-26

Similar Documents

Publication Publication Date Title
CN111447069B (en) Low-frequency access data processing method based on block chain
CN110910138B (en) Block chain data supervision method and device
CN110049087B (en) Credibility verification method, system, device and equipment of alliance chain
CN110855777B (en) Node management method and device based on block chain
CN111464353B (en) Block link point management method, device, computer and readable storage medium
CN110046901B (en) Credibility verification method, system, device and equipment of alliance chain
CN110008665B (en) Authority control method and device for blockchain
CN111523890A (en) Data processing method and device based on block chain, storage medium and equipment
CN111382164B (en) Service processing method based on block chain network
CN110266872B (en) Address book data management and control method and device, cloud address book system, computer equipment and computer readable storage medium
CN110597918A (en) Account management method and device and computer readable storage medium
CN112671881B (en) Node organization management method and device, electronic equipment and readable storage medium
CN111984735A (en) Data archiving method and device, electronic equipment and storage medium
CN113271311A (en) Digital identity management method and system in cross-link network
CN112235423A (en) Cross-chain transaction processing method and device, electronic equipment and storage medium
CN111488626A (en) Data processing method, device, equipment and medium based on block chain
CN112650812A (en) Data fragment storage method and device, computer equipment and storage medium
CN111447068A (en) Time service evidence storing method based on block chain
CN110597820A (en) Block chain based information processing method and device, storage medium and equipment
CN112200680B (en) Block link point management method, device, computer and readable storage medium
CN114239072A (en) Block chain node management method and block chain network
CN110807203A (en) Data processing method, service operation center platform, system and storage medium
CN113760519B (en) Distributed transaction processing method, device, system and electronic equipment
CN101729569B (en) Distributed Denial of Service (DDOS) attack protection method, device and system
CN113961600A (en) Data query method and device, computer equipment and storage medium

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