CN110543788B - Data storage method, apparatus, computer readable storage medium and computer device - Google Patents
Data storage method, apparatus, computer readable storage medium and computer device Download PDFInfo
- Publication number
- CN110543788B CN110543788B CN201910859251.8A CN201910859251A CN110543788B CN 110543788 B CN110543788 B CN 110543788B CN 201910859251 A CN201910859251 A CN 201910859251A CN 110543788 B CN110543788 B CN 110543788B
- Authority
- CN
- China
- Prior art keywords
- transaction
- block
- node
- state
- full
- 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
- 238000000034 method Methods 0.000 title claims abstract description 69
- 238000013500 data storage Methods 0.000 title claims abstract description 61
- 238000012790 confirmation Methods 0.000 claims abstract description 77
- 238000012795 verification Methods 0.000 claims abstract description 55
- 238000012544 monitoring process Methods 0.000 claims abstract description 25
- 238000012545 processing Methods 0.000 claims description 81
- 230000002159 abnormal effect Effects 0.000 claims description 19
- 238000004590 computer program Methods 0.000 claims description 11
- 238000004140 cleaning Methods 0.000 claims description 8
- 238000010586 diagram Methods 0.000 description 13
- 230000008569 process Effects 0.000 description 10
- 230000001360 synchronised effect Effects 0.000 description 8
- 238000007726 management method Methods 0.000 description 7
- 230000005540 biological transmission Effects 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 5
- 238000004422 calculation algorithm Methods 0.000 description 4
- 239000003795 chemical substances by application Substances 0.000 description 4
- 230000005856 abnormality Effects 0.000 description 3
- 230000006978 adaptation Effects 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 238000012550 audit Methods 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 238000012937 correction Methods 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000005201 scrubbing Methods 0.000 description 2
- 238000013475 authorization Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000013524 data verification Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 230000003862 health status Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000009545 invasion Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000012954 risk control Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Classifications
-
- 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/22—Indexing; Data structures therefor; Storage structures
- G06F16/2219—Large Object storage; Management thereof
-
- 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/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- General Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Computer Security & Cryptography (AREA)
- Data Mining & Analysis (AREA)
- Accounting & Taxation (AREA)
- Software Systems (AREA)
- Finance (AREA)
- Economics (AREA)
- Computing Systems (AREA)
- Development Economics (AREA)
- Technology Law (AREA)
- Marketing (AREA)
- General Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The present application relates to a data storage method, apparatus, computer readable storage medium and computer device, the method comprising: acquiring service data; the business data comprises business identification and transaction state information; monitoring service data and updating transaction state information; transmitting the service data to the full-quantity node according to the service identifier, so that the full-quantity node generates the service data into a corresponding current block and performs consensus verification; receiving verified blocks distributed by the full-quantity nodes, and writing the verified blocks into corresponding transaction tables; updating the block writing state of the transaction table, and determining a transaction confirmation tag by utilizing the updated transaction state information and the block writing state; and deleting the service data in the cache when the block writing state and the transaction confirmation label are successfully written into the disk. The scheme provided by the application can effectively store the transaction state of the service request and effectively ensure the accuracy and the effectiveness of the transaction state.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a data storage method, apparatus, computer readable storage medium, and computer device.
Background
With the rapid development of computer technology, blockchain technology is increasingly being widely used. The uniqueness of the distributed storage of a blockchain is that each node of the blockchain stores complete data in a blockchain structure. Currently, the blockchain transaction is usually confirmed by a lightweight node relative to a consensus node, that is, payment can be verified without running a complete node, and only the block header of all data blocks needs to be saved. The lightweight nodes are connected with the full-volume nodes, and by querying the blockchain network for a matching transaction, the blockchain network can be confirmed that the transaction has been approved, and how many confirmations of the network are obtained.
However, when the node confirms the transaction, the related transaction is usually obtained by using a filter, the transaction can be confirmed only after being packed into a block, and the transaction needs to be confirmed depending on the height of the block. For transactions that are not packed into blocks temporarily, the blocks and the transaction states may not be synchronous, and repeated payment is easy to occur, so that the validity and the transaction security of the transaction states are not guaranteed.
Disclosure of Invention
Based on this, it is necessary to provide a data storage method, apparatus, computer-readable storage medium and computer device for solving the technical problem that the validity of the transaction state and the transaction security are not guaranteed because the transaction state cannot be accurately and effectively judged.
A data storage method, comprising:
acquiring service data; the service data comprises a service identifier and transaction state information;
monitoring the service data and updating the transaction state information;
Transmitting the service data to a full-quantity node according to the service identifier, so that the full-quantity node generates a corresponding current block from the service data and performs consensus verification;
Receiving verified blocks distributed by the full-quantity nodes, and writing the verified blocks into corresponding transaction tables;
updating the block writing state of the transaction table, and determining a transaction confirmation tag by utilizing the updated transaction state information and the block writing state;
and deleting the service data in the cache when the block writing state and the transaction confirmation label are successfully written into the disk.
A data storage device, the device comprising:
The data acquisition module is used for acquiring service data; the service data comprises a service identifier and transaction state information;
The data monitoring module is used for monitoring the service data and updating the transaction state information;
The data sending module is used for sending the service data to a full-quantity node according to the service identifier, so that the full-quantity node generates a corresponding current block from the service data and performs consensus verification;
the data storage module is used for receiving the verified block distributed by the full-quantity node and writing the verified block into a corresponding transaction table; updating the block writing state of the transaction table, and determining a transaction confirmation tag by utilizing the updated transaction state information and the block writing state;
And the cache cleaning module is used for deleting the service data in the cache when the block writing state and the transaction confirmation label are successfully written into the disk.
A computer readable storage medium storing a computer program which, when executed by a processor, causes the processor to perform the steps of the data storage method described above.
A computer device comprising a memory and a processor, the memory storing a computer program which, when executed by the processor, causes the processor to perform the steps of the data storage method described above.
The data storage method, the data storage device, the computer readable storage medium and the computer equipment are used for monitoring the service data in real time after the service data in the cache are acquired, updating the transaction state information, simultaneously sending the service data to the full-quantity nodes corresponding to the target block chain according to the service identification, enabling the full-quantity nodes to generate the current block of the service data, and carrying out consensus verification on the current block. And receiving the verified blocks distributed by the full-quantity nodes, writing the verified blocks into the corresponding transaction tables, storing the received verified blocks in real time, and updating the block writing state of the transaction tables. Because the processing state in the service data processing process is continuously monitored, and the transaction state information is updated in real time, whether the transaction state corresponding to the service data is successful or not can be respectively confirmed by using the updated transaction state information and the block writing state of the transaction table, and a transaction confirmation label corresponding to the verified block is generated. By respectively storing the transaction state information and the received verified block in real time and respectively confirming the transaction state according to the transaction state information and the block writing state, whether the edge node receives the verified block or not can judge the transaction state of the service data according to the transaction state information stored locally by the edge node, so that the current transaction state can be effectively ensured to be accurate and effective, further the condition of repeated payment caused by uncertain transaction state can be effectively prevented, and the transaction safety is effectively improved.
Drawings
FIG. 1 is a diagram of an application environment for a data storage method in one embodiment;
FIG. 2 is a block diagram of a block chain business system in one embodiment;
FIG. 3 is a flow diagram of a method of data storage in one embodiment;
FIG. 4 is a flow chart illustrating the steps of monitoring transaction status in one embodiment;
FIG. 5 is a flow chart of a method of data storage in one embodiment;
FIG. 6 is a timing diagram of a method of data storage in one embodiment;
FIG. 7 is a block diagram of a data storage device in one embodiment;
FIG. 8 is a block diagram of a data storage device in another embodiment;
FIG. 9 is a block diagram of a data storage device in another embodiment;
FIG. 10 is a block diagram of a computer device in one embodiment.
Detailed Description
The present application will be described in further detail with reference to the drawings and examples, in order to make the objects, technical solutions and advantages of the present application more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application.
FIG. 1 is a diagram of an application environment for a data storage method in one embodiment. Referring to fig. 1, the data storage method is applied to a data storage system, wherein the data storage system may be a blockchain service system based on blockchain technology. The data storage system includes a terminal 110 and a blockchain service system 120, the blockchain service system 120 being a computer node deployed in a blockchain network. The terminal 110 and the blockchain service system 120 communicate over a network. The terminal 110 may be a desktop terminal or a mobile terminal, and the mobile terminal may be at least one of a mobile phone, a tablet computer, a notebook computer, and the like. The blockchain service system 120 may be implemented with a stand-alone server or a server cluster of multiple servers.
In one embodiment, referring to FIG. 2, the blockchain service system 120 includes multiple levels of nodes: edge node 1202, proxy node 1204, consensus node 1206. Wherein each consensus node may also be deployed with a corresponding billing node. Nodes in the overall blockchain service system may be denoted blockchain nodes, each of which may be provided as a server. The edge node 1202 may be a first-level authority deployed computer node, and the first layer may be an application service layer in a blockchain service system, such as a computer node deployed by each service provider. Edge node 1202 may be the node closest to the user terminal side that is connected to service participant terminal 110 and each block link point. Proxy node 1204 may be a second level authority deployed computer node, which may be a platform product service layer in a blockchain service system, such as a provincial authority deployed computer node. The consensus node 1206 may be a corresponding authority-deployed computer node of a third hierarchy, which may be a blockchain bottom-level platform in a blockchain business system, such as a country-level and provincial-level organization-deployed computer node. Each of the edge node 1202, proxy node 1204, and consensus node 1206 has a corresponding service area. Each edge node 1202 is connected directly to the proxy node 1204 in the service area to which it belongs through a network, or indirectly to the proxy nodes 1204 in the corresponding service area through other edge nodes 1202. The edge node 1202 may be configured to receive a service request initiated by a service participant terminal and distribute a request packet to a corresponding node in the blockchain service system according to a service attribute.
Blockchains are novel application modes of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanisms, encryption algorithms, and the like. The blockchain (Blockchain), essentially a de-centralized database, is a string of data blocks that are generated in association using cryptographic methods, each of which contains information from a batch of network transactions for verifying the validity (anti-counterfeit) of its information and generating the next block. The blockchain may include a blockchain underlying platform, a platform product services layer, and an application services layer.
The blockchain underlying platform may include processing modules for user management, basic services, smart contracts, and operational monitoring. The user management module is responsible for identity information management of all blockchain participants, including maintenance of public and private key generation (account management), key management, maintenance of corresponding relation between the real identity of the user and the blockchain address (authority management) and the like, and under the condition of authorization, supervision and audit of transaction conditions of certain real identities, and provision of rule configuration (wind control audit) of risk control; the basic service module is deployed on all block chain node devices, is used for verifying the validity of a service request, recording the service request on a storage after the effective request is identified, for a new service request, the basic service firstly analyzes interface adaptation and authenticates the interface adaptation, encrypts service information (identification management) through an identification algorithm, and transmits the encrypted service information to a shared account book (network communication) in a complete and consistent manner, and records and stores the service information; the intelligent contract module is responsible for registering and issuing contracts, triggering contracts and executing contracts, a developer can define contract logic through a certain programming language, issue the contract logic to a blockchain (contract registering), invoke keys or other event triggering execution according to the logic of contract clauses to complete the contract logic, and simultaneously provide a function of registering contract upgrading; the operation monitoring module is mainly responsible for deployment in the product release process, modification of configuration, contract setting, cloud adaptation and visual output of real-time states in product operation, for example: alarming, monitoring network conditions, monitoring node equipment health status, etc.
The platform product service layer provides basic capabilities and implementation frameworks of typical applications, and developers can complete the blockchain implementation of business logic based on the basic capabilities and the characteristics of the superposition business. The application service layer provides the application service based on the block chain scheme to the business participants for use.
As shown in fig. 3, in one embodiment, a data storage method is provided. The present embodiment is mainly illustrated with the method applied to the edge node 1202 in the blockchain 120 in fig. 2. Referring to fig. 3, the data storage method specifically includes the steps of:
step 302, obtaining service data; the transaction data includes a transaction identification and transaction status information.
In a blockchain-based service system, a plurality of blockchains can be deployed in advance according to service types, each blockchain has a corresponding service type, and the same service type can also correspond to a plurality of blockchains. Each blockchain may have a corresponding blockchain identification. The terminal can be provided with corresponding service application for initiating service request of corresponding service type. The block chain based service system comprises a plurality of nodes, and each node can process the received service data correspondingly. The blockchain node may be a deployed server that establishes connections with multiple blockchains and with multiple terminals. In this embodiment, the data storage method is applied to a data storage system, which may be a block chain based service system. The business system can be a public chain system, a private chain system or a alliance chain system.
The edge node refers to a computer node with lower safety reliability relative to the total nodes of the cores in the blockchain system, and the edge node can be a lightweight node relative to the total nodes, can provide transaction and inquiry functions, and does not have total transaction information. The full-quantity node is a computer node for storing the full-quantity data file, and has higher safety and reliability.
Full-scale nodes refer to computer nodes in a blockchain system that are critical to ensuring data reliability. The full-scale nodes may be reliable nodes in the blockchain system, and the full-scale nodes may include proxy nodes, consensus nodes, billing nodes, and the like. The full quantity of nodes are used as core nodes in the block chain system, and have high requirements on the hardware performance of the computer and the network environment. In the alliance chain scene, in order to ensure the requirements of safety and performance, only a few authority members can deploy reliable nodes. For example, in the above electronic invoice scenario, only the national tax administration may deploy reliable nodes; in the above-mentioned copyright evidence scenario, only the national rights center may deploy reliable nodes. The computer nodes deployed by the authority mechanism have higher capability of preventing malicious attack invasion, and can ensure smaller computer performance fault probability, so that the computer nodes can be considered as full-scale nodes.
The service data refers to data generated by corresponding to a service required by a user, and the service data can have various forms, for example, a service request initiated by a terminal to a certain service, a confirmation request of the user to the certain service, a data read-write operation of the user to the certain service, and the like. For example, in a transaction scenario, the business data may be transaction data, such as an electronic invoice or the like. The service data includes a service identifier and transaction state information, and the transaction state information may be initial transaction state information of the service data, for example, the initial transaction state information may be a pending state.
For example, when the service data is sent by the terminal based on the service request, the terminal may be installed with a service application corresponding to the service system, and the user may initiate the corresponding service request through the service application on the terminal. And the edge node receives the service request time sent by the terminal, and stores the service data carried by the service request into a cache. The service request carries a corresponding service identifier, and the edge node performs signature verification and authority verification on the service request first.
Specifically, the service data further includes signature information, and after receiving the service request, the edge node obtains pre-stored key information corresponding to the user identifier, and verifies the signature information of the service data by using the key information. Specifically, the edge node may analyze the corresponding signature by using the public key of the user to obtain summary information, calculate summary information of the data packet according to a preset algorithm, match the two summary information, and determine that the signature verification passes if the matching is successful. After the signature verification is passed, the edge node may further obtain a corresponding blockchain identifier according to the service identifier carried by the service request, where there may be multiple blockchains corresponding to the service type. The edge node performs hash calculation on the service type, the service identifier and the plurality of blockchains respectively to obtain a corresponding hash result set, and when the target blockchain identifier corresponding to the service data exists in the hash result set, the edge node indicates that the target blockchain has access right.
When the signature verification and the authority verification of the service request are both verified, step 304 is performed; if any one of signature verification and authority verification fails, the service request is determined to fail to verify, which means that the service request has malicious attack or service data has malicious tampering risk, and the edge node can intercept the service request and the service data.
The edge node can also directly acquire the service data in the cache, and the service data in the cache can be the service data stored in the cache after receiving the service data sent by the terminal; the service data obtained from other service platforms can also be stored in the cache.
And 304, monitoring service data and updating transaction state information.
The transaction state information may represent a real-time transaction state of the service request, and when the transaction is in different stages and periods, the corresponding transaction state information is different, for example, the transaction state includes various state information such as pending, processing, consensus, successful transaction and the like, and includes detailed transaction information.
And when the edge node sends the service data corresponding to the service request to the full-quantity node corresponding to the target blockchain identifier, monitoring the transaction state of the service data of the service request. Specifically, when the service data is not yet sent to the full-volume node, the transaction state of the service data can be directly identified, for example, the current transaction state of the service data can be state information such as non-distribution, unprocessed, pending and the like. The edge node monitors the processing state of the service data in real time and updates the transaction state information according to the processing state in real time.
And step 306, sending the service data to the full-quantity node according to the service identifier, so that the full-quantity node generates the service data into a corresponding current block and performs consensus verification.
The lightweight nodes are edge nodes connected with the full-quantity nodes. The full volume node may be deployed with multiple nodes. For example, in the above electronic invoice scenario, full-scale nodes may be deployed in several data centers distributed throughout the country at the national tax administration, respectively. The plurality of full-quantity nodes are connected in pairs through a network. Each full-scale node is connected with a plurality of edge nodes nearby through a network. When the full-scale node is deployed with a plurality of the full-scale nodes, the edge node may preferentially transmit the traffic data to the full-scale node located closest to the edge node. The full nodes that receive traffic data broadcast the corresponding blocks to other full nodes, each of which distributes the blocks to the edge nodes in the manner described above.
The block is a data packet carrying transaction data on a block chain network, is a container data structure marked with a time stamp and a hash value of a previous block, and is verified and confirmed by a consensus mechanism of the network. The block includes a block header and a block body. The block header records the time stamp of the previous sequential block and the time stamp of the current data block. The tiles also include a tile height, which is the number of tiles linked to the backbone, i.e., the number of tiles linked to the blockchain. The block height may be an identifier of a block, which may include a plurality of, for example, hash values of a block header, and may include a block height, with each block having a specific, fixed block height. The block ledger is a carrier for recording the data to be authenticated generated for a period of time, and records the information of a plurality of data blocks. The plurality of data blocks are serially connected in the block ledger according to the generation time sequence.
After the edge node determines the corresponding target block chain identification from the multiple block chains according to the service identification, the edge node sends the service data corresponding to the service request to the full-quantity node corresponding to the target block chain identification, so that the full-quantity node generates the service data into the corresponding current block, and the consensus node in the full-quantity node performs consensus verification on the generated current block. And after the common identification verification is passed, the full-quantity node writes the current block into a corresponding block account book, broadcasts the current block to other accounting nodes of the target block chain, and then synchronously distributes the current block to a plurality of light-weight nodes so that the light-weight nodes back up and store the current block.
In one embodiment, after the edge node obtains the service data, the edge node determines a corresponding target test chain identifier from the plurality of block chains according to the service identifier, and then generates a corresponding current block according to the service data. Specifically, the edge node may obtain the block header information of the last block associated with the current block in the target manner chain, generate the current block according to the block header information of the last block, and write the service data into the current block. When the current block is generated, the characteristic value of the current block can be generated according to the block head information of the previous block, and particularly, a plurality of hash algorithms can be adopted for parallel calculation, so that the characteristic value of the current block is obtained. The edge node further generates a current block of the service data according to the block characteristic value, the service data, the signature information, the block header characteristic value of the previous block, the timestamp and other information. After the edge node generates the current block corresponding to the service data, the current block is distributed to a plurality of full nodes corresponding to the target block chain identifier. And after the current block is acquired by the consensus nodes in the total number of nodes, performing consensus verification on the current block. And broadcasting the current block in the target block chain and writing the current block into the block account book after the common identification verification is passed.
After the edge node distributes the service data to the full-quantity node, the processing state of the full-quantity node on the service data can be obtained in real time. For example, when the full node generates a corresponding current block according to the service data, the edge node may acquire transaction state information of the service data in block generation from the full node; when the full-quantity node performs consensus on the current block, the edge node can acquire transaction state information of the service data in the consensus from the full-quantity node; after the total node passes the current block consensus verification and writes the current block consensus verification into a block account book of the consensus node, the service request is successfully transacted, and the edge node can acquire transaction state information of successful transaction of the service data from the total node.
The edge node generates corresponding transaction state information according to the transaction state acquired in real time, for example, the transaction state of the transaction state information can be modified according to the current state acquired in real time. The edge node caches the transaction state information in real time.
Step 308, receiving the verified block distributed by the full-quantity node, and writing the verified block into a corresponding transaction table; updating the block writing state of the transaction table, and determining the transaction confirmation tag by using the updated transaction state information and the block writing state.
The target blockchain also comprises a corresponding transaction table, each node in the target blockchain stores a corresponding transaction table, and the transaction table is used for storing transaction record data formed by transaction input and transaction output.
After the total node passes the current block consensus verification, the total node writes the current block into a corresponding block account book, broadcasts the current block to other accounting nodes of a target block chain, and then synchronously distributes the current block to a plurality of light-weight nodes. The edge node receives the current block distributed by the full-quantity node in real time. Wherein the block comprises a block header and a block body. The full-scale node may distribute the verified block to the edge node through the proxy node, and the proxy node may forward only the block header portion of the verified block to the edge node when distributing the verified block to the edge node. When the edge node receives the block header of the verified block distributed by the proxy node, the block header part of the verified block is stored. Specifically, the edge node obtains a transaction table corresponding to the target blockchain identifier, and writes transaction data of the verified block into the transaction, so that the verified block is stored.
Wherein the edge node generating transaction state information and receiving the verified block distributed by the full-volume node may be unsynchronized. The edge node stores the generated transaction state information and the received verified block in real time respectively.
After the edge node writes the verified transaction data of the block into the transaction table, the writing state of the block in the corresponding transaction table is updated. When the verified block is stored, writing transaction data corresponding to the block into a transaction table, wherein the writing completion indicates that the current block is successfully stored, and the block writing state of the transaction table is the block writing success.
After the edge node stores the generated transaction state information and the received verified block in real time, whether the transaction state of the service data is successful or not can be determined according to the transaction state information and the block writing state of the transaction table. Specifically, when the state in the transaction state information is successful, determining that the transaction state of the service data is successful, generating and storing a corresponding transaction confirmation label. When the block writing state of the transaction table is that the block writing is successful, a transaction confirmation label of successful transaction is added to the service request. The edge node generates and stores a transaction confirmation label as long as the edge node receives the successful transaction state information of the transaction at will or detects that the writing state of the block of the transaction table is successful, namely, the transaction is successful at the moment. The edge node may store both the transaction confirmation tag and the transaction table in a local disk.
In step 310, when the block writing status and the transaction confirmation label are both successfully written into the disk, the service data in the cache is deleted.
The edge node stores service data in a cache, and stores related cache information generated in the process of processing the service data, wherein the cache information can comprise data such as transaction state information for monitoring the transaction state of the service data, processing information for the service data and the like. The edge node stores the generated transaction confirmation label and the acquired verified block into a local disk, and when the transaction confirmation label and the verified block are both stored into the disk, the edge node indicates that the writing state of the block and the transaction confirmation label are successfully written into the disk.
When the writing state of the block and the writing of the transaction confirmation label are successful, the transaction state of the business data is indicated to be successful. The edge node may delete the relevant service data in the cache.
Because the blockchain is a factor of P2P (Peer-To-Peer) propagation mode and storage of a consensus node, two possibilities exist for the transaction state in the cache of the edge node, if the transaction state information acquired by the edge node is successfully returned first, namely, the transaction success is confirmed according To the transaction state information, the transaction state in the cache is changed into a successful state and a transaction confirmation label is generated, and at the moment, the cache information in the cache can be deleted only after the verified block is synchronized To the transaction of the edge node; in another case, the verified block is synchronized to the edge node, the transaction state will become a block writing success state, and then the transaction success can be confirmed according to the block writing state of the transaction table and a transaction confirmation label is generated, and at this time, the cache information is deleted from the cache until the transaction state information of successful transaction response is obtained.
The edge node can effectively and timely acquire the transaction state of the service data by updating the transaction state information of the service data in real time. And respectively storing the generated transaction state information and the received verified blocks in real time, and respectively confirming whether the transaction of the business data is successful or not according to the transaction state information and the block writing state. Therefore, whether the edge node receives the verified block distributed by the full-quantity node or not can judge the transaction state of the service data according to the transaction state information stored locally, so that the current transaction state can be effectively ensured to be accurate and effective, and further the condition of repeated payment caused by uncertain transaction state can be effectively prevented. When the writing state of the block and the writing of the transaction confirmation label are successful, the transaction state can be completely guaranteed to be a successful state at the moment and the block is successfully stored, and the transaction state information in the edge node cache can be deleted at the moment so as to reduce the resource occupation of the edge node.
In this embodiment, after the edge node obtains the service data in the cache, the edge node monitors the service data in real time, updates the transaction status information, and simultaneously sends the service data to the full-scale node corresponding to the target block chain according to the service identifier, so that the full-scale node generates the current block of the service data, and performs consensus verification on the current block. And receiving the verified blocks distributed by the full-quantity nodes, writing the verified blocks into the corresponding transaction tables, storing the received verified blocks in real time, and updating the block writing state of the transaction tables. Because the processing state in the business data processing process is continuously monitored, and the transaction state information is updated in real time, whether the transaction state corresponding to the business data is successful or not can be respectively confirmed by utilizing the updated transaction state information and the block writing state of the transaction table, and a transaction confirmation label corresponding to the verified block is generated. By respectively storing the transaction state information and the received verified block in real time and respectively confirming the transaction state according to the transaction state information and the block writing state, whether the edge node receives the verified block or not can judge the transaction state of the service data according to the transaction state information stored locally by the edge node, so that the current transaction state can be effectively ensured to be accurate and effective, further the condition of repeated payment caused by uncertain transaction state can be effectively prevented, and the transaction safety is effectively improved.
In one embodiment, the verified block includes a block header, the full node includes a consensus node, an accounting node and a proxy node, the full node is used for returning to a processing state and generating a current block, the consensus node is used for performing consensus verification on the current block, the consensus node, the accounting node and the proxy node can write the verified block into the block account book, and the proxy node is used for synchronously distributing the block header of the verified block to the edge node.
A lightweight node and a full-scale node may be included in the blockchain service system, the lightweight node may include an edge node, the full-scale node includes a consensus node, a billing node, and a proxy node, and the lightweight node and the full-scale node may each be deployed with a plurality of nodes. For example, in the above electronic invoice scenario, consensus nodes and accounting nodes may be deployed in several data centers distributed throughout the country in the national tax administration, proxy nodes may be deployed in tax administration of each province throughout the country, and edge nodes may be deployed in tax administration of each city and service providers throughout the country. The service provider refers to an organization with the authority to issue electronic invoices. The light weight nodes and the full quantity nodes are connected through a network, and all the nodes among the full quantity nodes are connected in pairs through the network.
The edge node refers to a computer node with lower safety reliability relative to the total number of nodes of the core in the blockchain system, and the edge node can be a lightweight node relative to the total number of nodes. The edge node may be a lightweight node (NIGHTWEIGHT NODES), for example, the edge node may be an SPV (SIMPLIFIED PAYMENT Verification) node, where the SPV node is a lightweight node with respect to the consensus node, and may provide transaction and query functions, but does not have full-scale transaction information, i.e., the SPV node does not need to store data of the entire blockchain, only stores part of data related to the SPV node that needs to be verified, and may save storage resources. The SPV node may be a node that supports the use of Bloom filters (Bloom filters) to quickly retrieve and return relevant data. Not every node in the blockchain network contains all data of the whole network, in order to simplify payment verification, an SPV node is arranged in the blockchain service system and is responsible for judging whether the transaction is authenticated by node consensus of the blockchain and how many times, and one transaction can be verified without backing up all data.
The full-quantity node is a computer node for storing the full-quantity data file, has higher safety and reliability, and can be a reliable node in a blockchain system. The SPV nodes may pull the block header of the associated block to the proxy node, and may synchronize the block header between the SPV nodes.
Specifically, the full-quantity nodes can return the processing state in the processing process of the service data to the light-weight nodes in real time, and any node in the full-quantity nodes can generate a corresponding current block according to the service data. After the total node generates the current block, the consensus node in the total node performs consensus verification on the generated current block, after the block passes the consensus verification, the verified block is broadcasted in the target block chain and written into the block account book, the billing node and the proxy node receive the broadcasted verified block and write the verified block into the block account book, and the proxy node synchronously distributes the block head part of the verified block to the edge node. Because the edge node is a lightweight node relative to the full-quantity node, the data of the whole blockchain is not required to be stored, so that only partial data of the block head of the verified block can be stored, storage resources can be effectively saved, and meanwhile, the validity of transaction data is ensured.
In one embodiment, as shown in fig. 4, monitoring service data, and updating transaction status information specifically includes the following steps:
step 402, the node flow direction of the service data is tracked.
Step 404, detecting the processing state of the total node to the service data, and updating the transaction state information according to the processing state.
Step 406, when it is detected that the consensus of the consensus node in the total nodes to the current block of the service data is completed, generating a transaction confirmation label corresponding to the verified block.
The edge nodes are connected with the full quantity of nodes through the network, and the node flow direction can indicate which node the service data flows to and which node is currently located. After receiving the service data sent by the edge node, the full-quantity node can feed back the processing state of the service data to the edge node in real time.
And after the edge node receives the service request and determines the corresponding target block chain identification according to the service identification in the service request, distributing the service data to the full quantity of nodes corresponding to the target block chain, and searching the node flow direction of the service data according to the service identification by the edge node. The edge node can route the transaction request corresponding to the service data to the consensus node through the proxy node, so that the consensus node generates a corresponding current block for the service data, and performs consensus verification on the current block.
Specifically, when the edge node receives the service request, the edge node may generate transaction state information of the service data and add a corresponding timestamp, and store the generated transaction state information in a cache local to the edge node. Meanwhile, the edge node searches the node flow direction corresponding to the service data of the service request in real time. The edge node can forward the service data to the consensus node through the proxy node in the full-quantity node, and after the proxy node acquires the service data, the processing state information of the received service data can be fed back to the edge node according to the data transmission path. When the consensus node receives the service data forwarded by the proxy node, the received processing state can be fed back to the edge node through the forwarding path, and when the consensus node generates a corresponding block from the service data and performs consensus verification on the current block, the processing state in the consensus is fed back to the edge node. And when the consensus node passes the consensus verification of the current block, feeding back a processing state of completion of the consensus or success of the transaction to the edge node.
The edge node can detect the processing state of the corresponding node to the service data in real time through the feedback condition of each node in the total nodes to the service data. After the edge node acquires the processing state fed back by the proxy node or the consensus node each time, the processing state acquired in real time is updated to the transaction state information, for example, the processing state acquired in real time can be newly added to the transaction state information according to the current timestamp, so that the transaction state of the service data can be effectively recorded in real time in the local cache of the edge node.
When the current block of the service data is detected to be completely identified by the identification node, the identification node indicates that the transaction state corresponding to the service data is successful, and the edge node updates the successful transaction state into the transaction state information to generate a transaction confirmation label corresponding to the identified block. The transaction confirmation tag may be stored in a database on disk of the edge node. And the edge node receives the current block forwarded by the proxy node and stores the current block, and when the writing state of the block and the transaction confirmation label are written successfully, the transaction state information in the edge node cache is deleted, wherein the transaction confirmation label is not deleted when the edge node deletes the transaction state information in the cache.
In this embodiment, the edge node detects the processing state of the corresponding node for the service data in real time by searching the node flow direction of the service data, and updates the transaction state information according to the processing state, so that the transaction state corresponding to the service request can be effectively cached at the edge node, and whether the edge node receives the verified block distributed by the full node or not, the transaction state of the service data can be judged according to the transaction state information locally stored at the edge node, so that the validity of the current transaction state can be effectively ensured.
In one embodiment, receiving the verified block distributed by the full volume node, writing the verified block into the corresponding transaction table includes: receiving verified block heads distributed by the full-quantity nodes; acquiring a transaction table corresponding to the block, and writing transaction data of the block head into the transaction table; when the transaction data of the block header is detected to be written into the transaction table, updating the block writing state of the transaction table into a writing success state.
The edge nodes and the full-quantity nodes are connected through a network, wherein the edge nodes can be directly connected with proxy nodes in the full-quantity nodes, and all nodes between the full-quantity nodes are connected in pairs through the network. The current block includes a block header and a block body. The transaction table is used for storing transaction record data consisting of transaction input and transaction output. For example, a data structure of a UTXO (Unspent Transaction Output, unexpired transaction output) model, which is part of the transaction input and output, may be utilized to store specific transaction data, and may be the most basic building element of the transaction.
After the edge node sends the service identification to the full-quantity node corresponding to the target block chain, the consensus node in the full-quantity node generates a corresponding current block according to the service data, and performs consensus verification on the current block. After verification, the common node writes the verified block into the block account book and broadcasts the block account book in the target block chain, so that each node in the target block chain writes the received verified block into each block account book. After receiving the verified block, the proxy node in the target block chain extracts the block header part of the verified block and synchronously distributes the block header of the verified block to a plurality of edge nodes.
The edge node acquires the block head of the verified block distributed by the connected proxy node in real time, and stores the block head. Specifically, when the edge node stores the verified block, the transaction table corresponding to the target blockchain identifier is obtained according to the verified block, and the transaction table is used for storing specific transaction data. The edge node stores the acquired block header, that is, the edge node writes the acquired transaction data of the acquired block header into the transaction table, so as to update the current block into the corresponding transaction table. Wherein the transaction table is stored in a disk of the edge node. The edge node can also detect the writing state of the block of the transaction table in real time, and when detecting that the transaction data of the block head is written into the transaction table, the edge node indicates that the verified block is written into the disk successfully. At this time, the edge node updates the block writing status of the transaction table to a block writing success status.
In this embodiment, by detecting the block writing state of the transaction table, the transaction state can be effectively determined in time, so that the accuracy and consistency of the current transaction state can be effectively ensured. When the edge node stores the verified block corresponding to the service data, only the block head part of the block is required to be stored, and when the data verification, query and other processes are realized, the data storage cost can be reduced, and meanwhile, the consistency and the effectiveness of the transaction data are ensured.
In one embodiment, the method further comprises: if the processing state of successful transaction returned by the full-quantity nodes is received, updating transaction state information according to the processing state, and generating a transaction confirmation label corresponding to the verified block; when receiving the verified blocks distributed by the full-quantity nodes, writing the verified blocks into the corresponding transaction tables and updating the writing state of the blocks; and deleting the service data in the cache when the block writing state and the transaction confirmation label are successfully written into the disk.
When the current block consensus verification corresponding to the generated service data is passed by the consensus nodes in the total nodes, the transaction state corresponding to the service request is a successful transaction processing state. The transaction confirmation tag may then be represented as an identification that the transaction state corresponding to the service request has been successful.
After the edge node acquires the service request, the processing state of the service request is monitored in real time. And the edge node simultaneously sends the service data to the full-quantity node corresponding to the target block chain according to the service identifier, so that the full-quantity node generates a current block of the service data, performs common-identification verification on the current block, and synchronously distributes the verified block to a plurality of edge nodes after the verification is passed. And after the current block consensus verification is passed, the consensus node returns a processing state of successful transaction to the edge node through the proxy node.
At this point, the processing state of the edge node receiving the transaction success and the time of the receiving agent node distributing the validated chunk may be unsynchronized. The edge node monitors the processing state of the service request and waits to receive the block after the verification of the distribution of the connected proxy node.
Specifically, if the edge node receives the successful processing state of the transaction returned by the full node, the transaction state information is updated according to the processing state, and the transaction state information at the moment already indicates that the transaction is successful, the edge node generates a transaction confirmation label corresponding to the verified block and stores the transaction confirmation label. At this time, if the terminal initiates a transaction inquiry request of the service request to the edge node, confirmation information of successful transaction can be returned to the terminal.
If the terminal does not receive the successful processing state of the transaction at the edge node or the block after the distribution verification of the connected node, when a transaction inquiry request of the service request is initiated to the edge node, the edge node returns corresponding current transaction state information to the terminal according to the current transaction state information stored in the cache.
And when the edge node subsequently receives the block after the verification of the distribution of the connected proxy node, storing the block after the verification. Specifically, the edge node updates the block writing state in the corresponding transaction table according to the verified block. When the verified block is stored, transaction data corresponding to the verified block is written in the transaction table, such as a block header. The completion of writing indicates that the block has been successfully stored, and updates the transaction table and the writing status in the block writing to a writing success status. When the block writing state is that the block writing is successful and the transaction confirmation label is generated, the block writing state and the transaction confirmation label are both successfully written into the disk, and the edge node deletes the service data in the cache.
In this embodiment, the received processing state and the validated block distributed by the connected node are stored in real time, so that the transaction state corresponding to the service request can be effectively cached and determined at the edge node, and whether the edge node receives the validated block or not, the transaction state of the service data can be determined according to the transaction state information locally stored at the edge node. Therefore, the accuracy and the effectiveness of the current transaction state can be effectively ensured, further the condition of repeated payment caused by uncertain transaction state can be effectively prevented, and the transaction safety is effectively ensured.
In one embodiment, the method further comprises: if the verified block distributed by the full-quantity node is received, writing the verified block into a corresponding transaction table and updating the block writing state, and generating a transaction confirmation label corresponding to the verified block; when receiving the successful processing state of the transaction returned by the full-quantity node, updating the transaction state information according to the processing state; and deleting the service data in the cache when the block writing state, the transaction confirmation label and the transaction success state are written into the disk successfully.
After the edge node acquires the service request, the processing state of the service request is monitored in real time. And the edge node simultaneously sends the service data to the full-quantity node corresponding to the target block chain according to the service identifier, so that the full-quantity node generates a current block of the service data, performs common-identification verification on the current block, and synchronously distributes the verified block to a plurality of edge nodes after the verification is passed. The edge node monitors the processing state of the service request in real time and waits for receiving the verified block distributed by the connected proxy node.
The processing state of the edge node receiving the transaction success and the time of receiving the validated block distributed by the proxy node may be unsynchronized. Specifically, if the edge node receives the verified block distributed by the connected node, it indicates that the service request at this time has been successfully transacted. The edge node writes the verified block into the corresponding transaction table and updates the writing state of the block for storage, and the writing completion indicates that the block is successfully stored, and updates the transaction table and updates the writing state in the writing of the block into the writing success state. The edge node generates a transaction confirmation label corresponding to the verified block and stores the transaction confirmation label. If the terminal initiates a transaction inquiry request of the service request to the edge node at the moment, the terminal can return confirmation information of successful transaction.
If the terminal does not receive the verified block distributed by the connected node at the edge node and does not receive the processing state of successful transaction, when a transaction inquiry request of the service request is initiated to the edge node, the edge node returns corresponding current transaction state information to the terminal according to the current transaction state information stored in the cache.
When the edge node subsequently receives the successful transaction processing state returned by the full-quantity node, the transaction state information is updated according to the processing state, and the current transaction state information is determined to be the successful transaction state. The edge node may also store a status identifier corresponding to the transaction success status. When the block writing state is that the block writing is successful and the transaction confirmation label is generated, the block writing state and the transaction confirmation label are both successfully written into the disk, and the edge node deletes the service data in the cache.
The received processing state and the current block distributed by the connected node are respectively stored in real time, so that the transaction state corresponding to the service request can be effectively cached and determined at the edge node, and whether the edge node receives the current block or not, the transaction state of the service request can be judged according to the transaction state information locally stored at the edge node. Therefore, the accuracy and the effectiveness of the current transaction state can be effectively ensured, and further the condition of repeated payment caused by uncertain transaction state can be effectively prevented, so that the transaction safety is effectively ensured.
In one embodiment, the method further comprises: receiving verified blocks distributed by the full-quantity nodes, and writing the blocks into corresponding transaction tables; establishing connection with the full quantity of nodes according to preset time frequency; synchronizing the verified blocks from the connected full-scale nodes; and checking the stored blocks according to the blocks obtained by synchronization.
Wherein, the connected node of the edge node refers to a computer node connected with the edge node through a network. The edge nodes may have one or more connected nodes. The connected nodes can be full-scale nodes or other edge nodes, and can also be proxy nodes in the full-scale nodes. When the connected node comprises a proxy node, it means that the edge node is directly connected to the proxy node via the network, i.e. there is a connection path with the proxy node. The proxy node stores a block account book corresponding to the target block chain and a complete block.
After the edge node obtains the service data, the service data is sent to the full-quantity node corresponding to the target block chain according to the service identification, so that the full-quantity node generates a current block of the service data and performs consensus verification on the current block, and after the verification is passed, the full-quantity node synchronously distributes the verified block to a plurality of edge nodes. The edge node also monitors the processing state of the service data in real time and updates the transaction state information in real time according to the processing state. The edge node receives the verified block and stores the block in real time, and updates the writing state of the block.
After the edge node receives and stores the verified blocks forwarded by the connected nodes, the edge node can further establish connection with the full quantity of nodes according to preset time frequency. Specifically, a time frequency for establishing a connection channel with the full-volume node is preset for each edge node. And the edge node determines whether a connection channel between the edge node and the node exists according to the preset time frequency. If not, the edge node sends a connection request to the full-scale node to establish a connection channel with the full-scale node.
After the edge node establishes a connection channel with the full-scale node, the edge node may also send a data synchronization request to the full-scale node to synchronize the corresponding block from the full-scale node. The data synchronization request carries the node identification of the edge node. Node identification is information, such as an IP address, that can uniquely identify a computer node. The full-quantity node acquires a block related to the corresponding edge node according to the node identification, and synchronizes the block to the corresponding edge node.
The blocks synchronized to from the full nodes may be considered accurate and reliable with a high degree of confidence, and the edge nodes may also derive the relevant blocks generated during the current collation period from the full node synchronization. The edge node compares the corresponding verified blocks synchronized from the full-scale node, and checks whether the block heights of the blocks acquired from the full-scale node or other edge nodes are consistent, whether the time stamps contained in the block heads of the blocks are consistent, and the like. If the block heights of the blocks and the time stamps contained in the block heads are consistent, the correction result is normal, and the blocks corresponding to the service data stored in the edge nodes can be considered to be safe and reliable without malicious tampering. When the block heights of the blocks or the timestamps contained in the block heads are inconsistent, the checking result is abnormal, and the risk of malicious tampering of the blocks stored by the edge nodes is indicated. By collating blocks stored in the edge nodes from blocks pulled from the data source, the reliability of the blocks stored in the edge nodes can be effectively improved.
In one example, the method further comprises: when the result of the check is abnormal, deleting the transaction data with abnormal blocks in the transaction table; and re-writing the transaction data of the blocks obtained from the full-quantity node synchronization into a transaction table.
The block ledger in the edge node records information of a plurality of blocks related to the block ledger, and the block ledger can be a transaction table stored in the edge node. And when the result of the check is data exception, the edge node is shown to have the risk of being tampered maliciously. The edge node stops pulling the current block from the full-scale node or other edge nodes, deletes the transaction data of the abnormal block recorded in the local block account book of the edge node, and when a connection channel between the edge node and the full-scale node is established, re-pulls the corresponding verified block from the full-scale node so as to synchronize the verified block corresponding to the local abnormal block from the full-scale node. The edge node rewrites transaction data of the blocks obtained by synchronization into a transaction table based on the blocks synchronized from the full-quantity nodes, thereby rewrites and updates the blocks with abnormality. And periodically checking the blocks stored in the edge nodes, and timely rewriting and updating the block account book data when the checking finds abnormality, so that the reliability of the blocks stored in the edge nodes is improved.
In one implementation, when the result of the check is abnormal, an abnormal alarm is generated based on the block with the abnormal data, and the abnormal alarm is sent to the monitoring terminal. The monitoring personnel can access the corresponding edge nodes through the monitoring terminals, clean all blocks in the edge nodes, and rewrite transaction data of the blocks obtained synchronously into the transaction table so as to reconstruct a corresponding block account book, thereby recovering abnormal data.
In one implementation, when the result of the check is abnormal, the edge node may replace the stored block with the abnormal data based on the block obtained from the reliable node synchronization, so as to implement the update correction of the block ledger periodically. In other words, when the data is found to be abnormal, only the block in which the abnormality exists may be deleted.
In one embodiment, the method further comprises: receiving a transaction inquiry request sent by a terminal, wherein the transaction inquiry request carries a transaction identifier; inquiring the corresponding transaction state and the block writing state in the transaction table according to the transaction identification; and returning inquiry result information to the terminal according to the transaction state and the block writing state.
The terminal can be provided with a service application corresponding to the service system, and a user can initiate a corresponding service request through the service application on the terminal. After the terminal initiates the service request by the corresponding service application, the edge node in the block chain service system can directly acquire the service request appointed for transmission and further process the service request.
The service request carries service data and a transaction identifier, and the service data can also comprise a corresponding service identifier. The transaction identifier is used for representing the information which corresponds to the service request and is unique enough identifier.
After the edge node obtains the service request, the service data is sent to the full-quantity node corresponding to the target block chain according to the service identifier, so that the full-quantity node generates the current block of the service data and performs consensus verification on the current block, and after the verification is passed, the full-quantity node synchronously distributes the verified block to a plurality of edge nodes. The edge node also monitors the processing state of the service data in real time and updates the transaction state information in real time according to the processing state. The edge node receives the verified block and stores the block in real time, and updates the writing state of the block. When the writing state of the block and the writing of the transaction confirmation label are successful, the transaction state is successful, and the current block is stored successfully, at the moment, the transaction state information in the cache can be deleted, and the cache occupation is reduced.
After the terminal sends the service request to the edge node, the transaction state of the service request can be queried in real time. The transaction state may be a processing state of the service data in the service request. The edge node monitors the processing state of the service request and waits to receive the current block distributed by the connected proxy node. The edge nodes respectively buffer the received processing states in real time and store the verified blocks distributed by the connected nodes. Therefore, when the terminal sends a transaction inquiry request to the edge node, inquiring the corresponding transaction state and the block writing state in the transaction table according to the transaction identifier; and generating corresponding inquiry result information according to the transaction state and the block writing state, and returning the inquiry result information to the terminal.
Specifically, when the block writing state is not written, transaction state information in the cache is obtained, query result information is generated according to the transaction state information, and the query result information is returned to the terminal. The transaction state information may include a transaction confirmation tag that the transaction is successful, and the edge node generates query result information according to the transaction confirmation tag and returns the query result information to the terminal. And when the block writing state is successful writing, generating inquiry result information according to the block writing state and the transaction confirmation label, and returning the inquiry result information to the terminal. The received processing state and the verified block distributed by the connected node are respectively stored in real time, so that the transaction state corresponding to the service request can be effectively cached and determined at the edge node, no matter whether the edge node receives the verified block or not, the terminal can effectively inquire the transaction state of the service request according to the transaction state information locally stored at the edge node, the accuracy and the validity of the currently inquired transaction state information can be effectively ensured, and further the situation that a user pays repeatedly due to uncertain transaction states can be effectively prevented, and the transaction safety is effectively ensured.
In one embodiment, returning query result information to the terminal based on the transaction status and the block write status includes: when the block writing state is unwritten, acquiring transaction state information in a cache; and generating inquiry result information according to the transaction state information, and returning the inquiry result information to the terminal.
After the terminal initiates the service request by the corresponding service application, the terminal can also initiate the transaction inquiry request of the service request to the edge node in real time. After receiving a transaction inquiry request sent by a terminal, the edge node acquires transaction state information and block writing state information stored in a local cache of the edge node according to a transaction identifier.
Specifically, when the block writing state in the edge node is unwritten, it indicates that the verified block corresponding to the service request has not been stored successfully, and at this time, the transaction state of the service request cannot be determined according to the block writing state of the block. The edge node caches transaction state information in the buffer, and the transaction state comprises various state information such as pending, processing, consensus, successful transaction and the like. The edge node obtains the current transaction state information in the cache, where the current transaction state information may be the transaction state information closest to the query time of the transaction query request, or the transaction state updated most recently in the transaction state information. The edge node further generates transaction inquiry result information according to the current transaction state information, and returns the transaction inquiry result information to the terminal. Therefore, the transaction state corresponding to the service request can be effectively cached and determined at the edge node, and the terminal can effectively inquire the transaction state of the service request according to the transaction state information locally stored at the edge node no matter whether the edge node receives the current block or not, so that the accuracy and the effectiveness of the transaction state information are effectively ensured.
In one embodiment, returning query result information to the terminal based on the transaction status and the block write status includes: when the block writing state is writing success, generating inquiry result information according to the block writing state and the transaction confirmation label; and returning the query result information to the terminal.
After receiving a transaction inquiry request sent by a terminal, the edge node acquires transaction state information and block writing state information stored in a local cache of the edge node according to a transaction identifier. When the writing state of the block is writing success, the current block corresponding to the service request and the storage are successful, and the transaction state is transaction success state. At this time, the storage library stores transaction confirmation tags, and the edge node can directly generate query result information according to the block writing state and/or the transaction confirmation tags and return the query result information to the terminal.
In this embodiment, the received processing state and the current block distributed by the connected node are respectively stored in real time, so that the transaction state corresponding to the service request can be effectively cached and determined at the edge node, and the transaction state of the service request can be judged according to the transaction state information locally stored at the edge node. Therefore, the accuracy and the effectiveness of the current transaction state queried by the user can be effectively ensured, and further the situation of repeated payment caused by uncertain transaction state can be effectively prevented.
In one embodiment, FIG. 5 is a flow chart of a method of data storage in one embodiment.
As shown in fig. 5, the data storage method specifically includes the following steps:
step 502, obtaining service data; the transaction data includes a transaction identification and transaction status information.
Step 504, monitoring service data, and searching for node flow direction of the service data; and detecting the processing state of the total node on the service data, and updating the transaction state information according to the processing state.
And step 506, the service data is sent to the full-quantity node according to the service identification, so that the full-quantity node generates the corresponding current block from the service data and performs consensus verification.
Step 508, receiving the verified block header distributed by the full-quantity node, obtaining a transaction table corresponding to the block, and writing the transaction data of the block header into the transaction table; updating the block writing state of the transaction table, and determining the transaction confirmation tag by using the updated transaction state information and the block writing state.
In step 510, when the block writing status and the transaction confirmation tag are both successfully written to the disk, the service data in the cache is deleted.
Step 512, a transaction inquiry request sent by the terminal is received, where the transaction inquiry request carries a transaction identifier.
Step 514, inquiring the corresponding transaction state and the block writing state in the transaction table according to the transaction identification.
And step 516, generating inquiry result information according to the transaction state and the block writing state, and returning the inquiry result information to the terminal.
In a specific embodiment, referring to FIG. 6, FIG. 6 is a timing diagram of a method of data storage in one embodiment. As shown in fig. 6, after the edge node obtains the service request, the service data carried by the service request is stored in the local cache, where the service data includes the service identifier and the transaction status information. The edge node monitors service data in real time and updates transaction state information. The edge node can also send the service data to the full-quantity nodes of the corresponding target block chain according to the service identifier at the same time; and enabling the full-quantity nodes to generate the current block of the service data, carrying out consensus verification on the current block, and after the verification is passed, synchronously distributing the verified block to a plurality of light-weight nodes by the full-quantity nodes. The full-scale nodes include consensus nodes, billing nodes, and proxy nodes. And the edge node updates the transaction state information in real time according to the processing state of the total node on the service data, and stores the transaction state information in real time. And after the edge node receives the verified block distributed by the nodes connected with the full quantity of nodes, storing the verified block in real time, and updating the writing state of the block. The edge node can confirm the transaction state of the business data respectively by the transaction state information and the block writing state, and when the writing of the block writing state and the transaction confirmation label is successful, the edge node indicates that the transaction state is successful and the verified block is stored successfully, and the edge node can delete the transaction state information in the cache.
Fig. 3-5 are flow diagrams of a method of data storage in one embodiment. It should be understood that, although the steps in the flowcharts of fig. 3-5 are shown in order as indicated by the arrows, these steps are not necessarily performed in order as indicated by the arrows. The steps are not strictly limited to the order of execution unless explicitly recited herein, and the steps may be executed in other orders. Moreover, at least some of the steps in fig. 3-5 may include multiple sub-steps or stages that are not necessarily performed at the same time, but may be performed at different times, nor does the order in which the sub-steps or stages are performed necessarily occur sequentially, but may be performed alternately or alternately with at least a portion of the sub-steps or stages of other steps or other steps.
In one embodiment, as shown in FIG. 7, a data storage device 700 is provided, comprising a data acquisition module 702, a data monitoring module 704, a data transmission module 706, a data storage module 708, and a cache scrubbing module 710, wherein:
A data acquisition module 702, configured to service data; the business data comprises business identification and transaction state information;
the data monitoring module 704 is configured to monitor service data and update transaction status information;
the data sending module 706 is configured to send service data to a full-capacity node according to the service identifier, so that the full-capacity node generates a corresponding current block from the service data and performs consensus verification;
The data storage module 708 is configured to receive the verified block distributed by the full-volume node, and write the verified block into the corresponding transaction table; updating the block writing state of the transaction table, and determining a transaction confirmation tag by utilizing the updated transaction state information and the block writing state;
the cache cleaning module 710 is configured to delete the service data in the cache when the block writing status and the transaction confirmation tag are both successfully written to the disk.
In one embodiment, the current block includes a block header, the full node includes a consensus node, an accounting node, and an agent node, the full node is configured to return a processing state and generate the current block, the consensus node is configured to perform consensus verification on the current block, the consensus node, the accounting node, and the agent node are configured to write the current block into a block ledger, and the agent node is configured to synchronously distribute the block header to an edge node.
In one embodiment, the data monitoring module 704 is further configured to track the node flow direction of the traffic data; detecting the processing state of the total node nodes on the service data, and updating transaction state information according to the processing state; and when the fact that the consensus node in the total nodes performs consensus on the current block is detected, generating a transaction confirmation label corresponding to the verified block.
In one embodiment, the data storage module 708 is further configured to receive the verified block header distributed by the full-volume node, obtain a transaction table corresponding to the block, and write transaction data of the block header into the transaction table; when the transaction data of the block header is detected to be written into the transaction table, updating the block writing state of the transaction table into a writing success state.
In one embodiment, the data storage module 708 is further configured to, if a processing state of success of the transaction returned by the full-volume node is received first, update transaction state information according to the processing state, and generate a transaction confirmation tag corresponding to the verified block; when receiving the verified blocks distributed by the full-quantity nodes, writing the verified blocks into the corresponding transaction tables and updating the writing state of the blocks; the cache cleaning module 710 is further configured to delete the service data in the cache when the block writing status and the transaction confirmation tag are both successfully written to the disk.
In one embodiment, the data storage module 708 is further configured to, if the verified block distributed by the full-volume node is received first, write the verified block into the corresponding transaction table and update the block writing state, and generate a transaction confirmation tag corresponding to the verified block; when receiving the successful processing state of the transaction returned by the full-quantity node, updating the transaction state information according to the processing state; the cache cleaning module 710 is further configured to delete the service data in the cache when the block writing status, the transaction confirmation tag, and the transaction success status are all successfully written to the disk.
In one embodiment, as shown in fig. 8, the data storage device 700 further includes a data checking module 712, configured to receive the verified block distributed by the full-volume node, and write the block into the corresponding transaction table; establishing connection with the full quantity of nodes according to preset time frequency; synchronizing the verified blocks from the connected full-scale nodes; and checking the stored blocks according to the blocks obtained by synchronization.
In one embodiment, the data checking module 712 is further configured to delete transaction data having an abnormal block in the transaction table when the checking result is abnormal; and re-writing the transaction data of the blocks obtained from the full-quantity node synchronization into a transaction table.
In one embodiment, as shown in fig. 9, the data storage device 700 further includes a transaction inquiry module 714, configured to receive a transaction inquiry request sent by the terminal, where the transaction inquiry request carries a transaction identifier; inquiring the corresponding transaction state and the block writing state in the transaction table according to the transaction identification; and generating inquiry result information according to the transaction state and the block writing state, and returning the inquiry result information to the terminal.
In one embodiment, the transaction inquiry module 714 is further configured to obtain transaction status information in the cache when the block write status is unwritten; and generating inquiry result information according to the transaction state information, and returning the inquiry result information to the terminal.
In one embodiment, the transaction query module 714 is further configured to generate query result information according to the block writing status and the transaction confirmation tag when the block writing status is writing successful; and returning the query result information to the terminal.
FIG. 10 illustrates an internal block diagram of a computer device in one embodiment. The computer device may be in particular a server 120 of an edge node in the block chain traffic system of fig. 1. As shown in fig. 10, the computer device includes a processor, a memory, a network interface, an input device, and a display screen connected by a system bus. The memory includes a nonvolatile storage medium and an internal memory. The non-volatile storage medium of the computer device stores an operating system, and may also store a computer program that, when executed by a processor, causes the processor to implement a data storage method. The internal memory may also have stored therein a computer program which, when executed by the processor, causes the processor to perform a data storage method. The display screen of the computer equipment can be a liquid crystal display screen or an electronic ink display screen, the input device of the computer equipment can be a touch layer covered on the display screen, can also be keys, a track ball or a touch pad arranged on the shell of the computer equipment, and can also be an external keyboard, a touch pad or a mouse and the like.
It will be appreciated by those skilled in the art that the structure shown in FIG. 10 is merely a block diagram of some of the structures associated with the present inventive arrangements and is not limiting of the computer device to which the present inventive arrangements may be applied, and that a particular computer device may include more or fewer components than shown, or may combine some of the components, or have a different arrangement of components.
In one embodiment, the data storage apparatus provided by the present application may be implemented in the form of a computer program that is executable on a computer device as shown in fig. 10. The memory of the computer device may store various program modules that make up the data storage device, such as the data acquisition module 702, the data monitoring module 704, the data transmission module 706, the data storage module 708, and the cache scrubbing module 710 shown in FIG. 7. The computer program of each program module causes a processor to execute the steps of the data storage method of each embodiment of the present application described in the present specification.
For example, the computer device shown in FIG. 10 may perform step 302 by the data acquisition module 702 in the data store shown in FIG. 7. The computer device may perform step 304 via the data monitoring module 704. The computer device may perform step 306 via the data transmission module 706. The computer device may perform step 308 via the data storage module 708. The computer device may perform step 310 via the cache cleaning module 710.
In one embodiment, a computer device is provided comprising a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps of the data storage method described above. The steps of the data storage method herein may be the steps in the data storage method of the above embodiments.
In one embodiment, a computer readable storage medium is provided, storing a computer program which, when executed by a processor, causes the processor to perform the steps of the data storage method described above. The steps of the data storage method herein may be the steps in the data storage method of the above embodiments.
Those skilled in the art will appreciate that all or part of the processes in the methods of the above embodiments may be implemented by a computer program for instructing relevant hardware, where the program may be stored in a non-volatile computer readable storage medium, and where the program, when executed, may include processes in the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in embodiments provided herein may include non-volatile and/or volatile memory. The nonvolatile memory can include Read Only Memory (ROM), programmable ROM (PROM), electrically Programmable ROM (EPROM), electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double Data Rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (SYNCHLINK) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), among others.
The technical features of the above embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.
The foregoing examples illustrate only a few embodiments of the application and are described in detail herein without thereby limiting the scope of the application. It should be noted that it will be apparent to those skilled in the art that several variations and modifications can be made without departing from the spirit of the application, which are all within the scope of the application. Accordingly, the scope of protection of the present application is to be determined by the appended claims.
Claims (24)
1. A data storage method, applied to an edge node, comprising:
acquiring service data; the service data comprises a service identifier and transaction state information;
The node flow direction of the service data is searched;
Detecting the processing state of the full-quantity node to the service data, and updating the transaction state information according to the processing state;
Transmitting the service data to a full-quantity node according to the service identifier, so that the full-quantity node generates a corresponding current block from the service data and performs consensus verification; the full-quantity node comprises a consensus node, the full-quantity node is used for returning to a processing state and generating a current block, and the consensus node is used for carrying out consensus verification on the current block;
Receiving verified blocks distributed by the full-quantity nodes, and writing the verified blocks into corresponding transaction tables;
updating the block writing state of the transaction table, and determining a transaction confirmation tag by utilizing the updated transaction state information and the block writing state;
and deleting the service data in the cache when the block writing state and the transaction confirmation label are successfully written into the disk.
2. The method of claim 1, wherein the verified block includes a block header, the full-scale node further includes a billing node and a proxy node, the consensus node, the billing node and the proxy node each writing the verified block to a block ledger, the proxy node for synchronously distributing the block header of the verified block to an edge node.
3. The method according to claim 2, wherein the method further comprises:
and when the fact that the current block is completely identified by the common identification node in the total nodes is detected, generating a transaction confirmation label corresponding to the identified block.
4. The method of claim 1, wherein receiving the verified block distributed by the full-volume node, writing the verified block to a corresponding transaction table comprises:
receiving the verified block header distributed by the full-quantity node;
Acquiring a transaction table corresponding to the verified block, and writing transaction data of the block head into the transaction table;
and updating the block writing state of the transaction table into a writing success state when the transaction data of the block head is detected to be written into the transaction table.
5. The method according to claim 1, wherein the method further comprises:
if the processing state of successful transaction returned by the full-quantity node is received, updating the transaction state information according to the processing state, and generating a transaction confirmation label corresponding to the verified block;
when receiving the verified block distributed by the full-quantity node, writing the verified block into a corresponding transaction table and updating a block writing state;
and deleting the service data in the cache when the block writing state and the transaction confirmation label are successfully written into the disk.
6. The method according to claim 1, wherein the method further comprises:
If the verified block distributed by the full-quantity node is received, writing the verified block into a corresponding transaction table and updating the block writing state to generate a transaction confirmation label corresponding to the verified block;
when receiving a successful transaction processing state returned by the full-quantity node, updating the transaction state information according to the processing state;
and deleting the service data in the cache when the block writing state, the transaction confirmation label and the transaction success state are written into the disk successfully.
7. The method according to claim 1, wherein the method further comprises:
receiving the verified blocks distributed by the full-quantity nodes, and writing the blocks into corresponding transaction tables;
establishing connection with the full-quantity nodes according to preset time frequency;
Synchronizing the verified blocks from the connected full-scale nodes;
and checking the stored blocks according to the blocks obtained by synchronization.
8. The method of claim 7, wherein the method further comprises:
when the result of the verification is abnormal, deleting the transaction data with abnormal blocks in the transaction table;
And rewriting transaction data of the blocks obtained by synchronizing the full-quantity nodes into the transaction table.
9. The method according to any one of claims 1 to 8, further comprising:
Receiving a transaction inquiry request sent by a terminal, wherein the transaction inquiry request carries a transaction identifier;
inquiring a corresponding transaction state and a block writing state in a transaction table according to the transaction identifier;
and generating inquiry result information according to the transaction state and the block writing state, and returning the inquiry result information to the terminal.
10. The method of claim 9, wherein the generating query result information from the transaction status and the block writing status and returning the query result information to the terminal comprises:
when the block writing state is unwritten, acquiring transaction state information in the cache;
and generating inquiry result information according to the transaction state information, and returning the inquiry result information to the terminal.
11. The method of claim 9, wherein the generating query result information from the transaction status and the block writing status and returning the query result information to the terminal comprises:
When the block writing state is writing success, generating inquiry result information according to the block writing state and the transaction confirmation label;
And returning the query result information to the terminal.
12. A data storage device for application to an edge node, the device comprising:
The data acquisition module is used for acquiring service data; the service data comprises a service identifier and transaction state information;
The data monitoring module is used for searching the node flow direction of the service data; detecting the processing state of the full-quantity node to the service data, and updating the transaction state information according to the processing state;
The data sending module is used for sending the service data to a full-quantity node according to the service identifier, so that the full-quantity node generates a corresponding current block from the service data and performs consensus verification; the full-quantity node comprises a consensus node, the full-quantity node is used for returning to a processing state and generating a current block, and the consensus node is used for carrying out consensus verification on the current block;
the data storage module is used for receiving the verified block distributed by the full-quantity node and writing the verified block into a corresponding transaction table; updating the block writing state of the transaction table, and determining a transaction confirmation tag by utilizing the updated transaction state information and the block writing state;
And the cache cleaning module is used for deleting the service data in the cache when the block writing state and the transaction confirmation label are successfully written into the disk.
13. The apparatus of claim 12, wherein the verified block includes a block header, the full-scale node further comprises an accounting node and a proxy node, the accounting node and the proxy node each writing the verified block to a block ledger, the proxy node for synchronously distributing the block header of the verified block to an edge node.
14. The apparatus of claim 13, wherein the data monitoring module is further configured to generate a transaction confirmation tag corresponding to the verified block upon detecting that the consensus of the current block by a consensus node of the total number of nodes is complete.
15. The apparatus of claim 12, wherein the data storage module is further configured to receive a verified tile header distributed by the full-volume node; acquiring a transaction table corresponding to the verified block, and writing transaction data of the block head into the transaction table; and updating the block writing state of the transaction table into a writing success state when the transaction data of the block head is detected to be written into the transaction table.
16. The apparatus of claim 12, wherein the data storage module is further configured to, if a processing state of success of the transaction returned by the full-volume node is received first, update the transaction state information according to the processing state, and generate a transaction confirmation tag corresponding to the verified block; when receiving the verified block distributed by the full-quantity node, writing the verified block into a corresponding transaction table and updating a block writing state;
The cache cleaning module is further configured to delete the service data in the cache when the block writing state and the transaction confirmation tag are both successfully written into the disk.
17. The apparatus of claim 12, wherein the data storage module is further configured to, if a verified block distributed by a full-volume node is received first, write the verified block into a corresponding transaction table and update a block write state, and generate a transaction confirmation tag corresponding to the verified block; when receiving a successful transaction processing state returned by the full-quantity node, updating the transaction state information according to the processing state;
The cache cleaning module is further configured to delete the service data in the cache when the block writing state, the transaction confirmation tag and the transaction success state are all successfully written into the disk.
18. The apparatus of claim 12, wherein the apparatus further comprises:
The data checking module is used for receiving the verified blocks distributed by the full-quantity nodes and writing the blocks into the corresponding transaction tables; establishing connection with the full-quantity nodes according to preset time frequency; synchronizing the verified blocks from the connected full-scale nodes; and checking the stored blocks according to the blocks obtained by synchronization.
19. The apparatus of claim 18, wherein the data collation module is further configured to delete transaction data for which there is an abnormal block in the transaction table when the collation result is abnormal; and rewriting transaction data of the blocks obtained by synchronizing the full-quantity nodes into the transaction table.
20. The apparatus according to any one of claims 12 to 19, further comprising: the transaction inquiry module is used for receiving a transaction inquiry request sent by the terminal, wherein the transaction inquiry request carries a transaction identifier; inquiring a corresponding transaction state and a block writing state in a transaction table according to the transaction identifier; and generating inquiry result information according to the transaction state and the block writing state, and returning the inquiry result information to the terminal.
21. The apparatus of claim 20, wherein the transaction inquiry module is further configured to obtain transaction state information in the cache when the tile write state is unwritten; and generating inquiry result information according to the transaction state information, and returning the inquiry result information to the terminal.
22. The apparatus of claim 20, wherein the transaction inquiry module is further configured to generate inquiry result information based on the block writing status and the transaction confirmation tag when the block writing status is writing successful; and returning the query result information to the terminal.
23. A computer readable storage medium storing a computer program which, when executed by a processor, causes the processor to perform the steps of the method of any one of claims 1 to 11.
24. A computer device comprising a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps of the method of any of claims 1 to 11.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910859251.8A CN110543788B (en) | 2019-09-11 | 2019-09-11 | Data storage method, apparatus, computer readable storage medium and computer device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910859251.8A CN110543788B (en) | 2019-09-11 | 2019-09-11 | Data storage method, apparatus, computer readable storage medium and computer device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110543788A CN110543788A (en) | 2019-12-06 |
| CN110543788B true CN110543788B (en) | 2024-05-03 |
Family
ID=68713410
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910859251.8A Active CN110543788B (en) | 2019-09-11 | 2019-09-11 | Data storage method, apparatus, computer readable storage medium and computer device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110543788B (en) |
Families Citing this family (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111159303A (en) * | 2020-01-07 | 2020-05-15 | 杭州宇链科技有限公司 | Method for reducing block chain data storage cost |
| CN111241061B (en) * | 2020-01-09 | 2023-04-07 | 平安科技（深圳）有限公司 | Writing method of state database, data processing device and storage medium |
| CN111507717B (en) * | 2020-04-20 | 2022-08-12 | 腾讯科技（深圳）有限公司 | Data processing method, device, block node and computer readable storage medium |
| WO2020143855A2 (en) | 2020-04-22 | 2020-07-16 | Alipay (Hangzhou) Information Technology Co., Ltd. | Managing transaction requests in ledger systems |
| WO2020143856A2 (en) | 2020-04-22 | 2020-07-16 | Alipay (Hangzhou) Information Technology Co., Ltd. | Managing transaction requests in ledger systems |
| CN111415161B (en) * | 2020-04-27 | 2024-03-19 | 财付通支付科技有限公司 | Block chain-based data verification method and device and computer readable storage medium |
| CN111478827B (en) * | 2020-06-24 | 2020-12-04 | 支付宝(杭州)信息技术有限公司 | Pressure testing method, device and system for block chain network |
| CN111475501B (en) * | 2020-06-24 | 2020-10-30 | 支付宝(杭州)信息技术有限公司 | Data cleaning method and device for block chain network |
| CN111611321B (en) * | 2020-06-29 | 2023-07-25 | 度小满科技(北京)有限公司 | Data storage method, device and blockchain system |
| CN111917859B (en) * | 2020-07-28 | 2022-08-12 | 腾讯科技（深圳）有限公司 | Data transmission method and device, computer equipment and storage medium |
| CN112883107B (en) * | 2020-12-31 | 2022-05-17 | 杭州趣链科技有限公司 | Asynchronous execution method, system and related equipment for transactions in block chain |
| CN112748881B (en) * | 2021-01-15 | 2024-02-20 | 长城超云(北京)科技有限公司 | Storage fault-tolerant method and cluster system oriented to virtualization scene |
| CN112926982B (en) * | 2021-01-20 | 2022-08-02 | 腾讯科技（深圳）有限公司 | Transaction data processing method, device, equipment and storage medium |
| CN112988412B (en) * | 2021-02-07 | 2023-06-27 | 中国联合网络通信集团有限公司 | Edge caching method, base station and system based on block chain network |
| CN113034146B (en) * | 2021-05-25 | 2021-08-17 | 杭州云链趣链数字科技有限公司 | Block chain-based communication method, system, electronic device and storage medium |
| CN113852662B (en) * | 2021-08-06 | 2023-09-26 | 华数云科技有限公司 | Edge cloud distributed storage system and method based on alliance chain |
| CN114049213B (en) * | 2021-11-15 | 2024-07-09 | 深圳前海鸿泰源兴科技发展有限公司 | Informationized financial data analysis system and analysis method |
| CN115271733B (en) * | 2022-09-28 | 2022-12-13 | 深圳市迪博企业风险管理技术有限公司 | Privacy-protected block chain transaction data anomaly detection method and equipment |
| CN116684425B (en) * | 2023-07-28 | 2023-10-27 | 腾讯科技（深圳）有限公司 | Block chain data processing method, system, device and computer equipment |
| CN116956332B (en) * | 2023-09-20 | 2024-01-05 | 深圳市智慧城市科技发展集团有限公司 | BIM data processing method, BIM data processing equipment and computer readable storage medium |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109191124A (en) * | 2018-08-16 | 2019-01-11 | 北京京东尚科信息技术有限公司 | Block chain network, dispositions method and storage medium |
| CN109214823A (en) * | 2018-08-27 | 2019-01-15 | 北京京东金融科技控股有限公司 | Transaction verification method, device, storage medium and electronic equipment based on block chain |
-
2019
- 2019-09-11 CN CN201910859251.8A patent/CN110543788B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109191124A (en) * | 2018-08-16 | 2019-01-11 | 北京京东尚科信息技术有限公司 | Block chain network, dispositions method and storage medium |
| CN109214823A (en) * | 2018-08-27 | 2019-01-15 | 北京京东金融科技控股有限公司 | Transaction verification method, device, storage medium and electronic equipment based on block chain |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110543788A (en) | 2019-12-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110543788B (en) | Data storage method, apparatus, computer readable storage medium and computer device | |
| CN110633323B (en) | Service data storage method, device, storage medium and computer equipment | |
| CN110598446B (en) | Block chain-based test method, device, storage medium and computer equipment | |
| CN110572450B (en) | Data synchronization method and device, computer readable storage medium and computer equipment | |
| WO2021036545A1 (en) | Smart contract-based data processing method, and device and storage medium | |
| CN110263585B (en) | Test supervision method, device, equipment and storage medium | |
| CN109255084B (en) | Electronic bill query method, device, storage medium and computer equipment | |
| CN110597837B (en) | Service data processing method, device, storage medium and computer equipment | |
| WO2021233049A1 (en) | Blockchain–based data processing method, apparatus, device, and readable storage medium | |
| CN110784495B (en) | Block chain-based discovery and configuration information management method for big data cluster system | |
| CN110602116B (en) | Block chain based data verification method, device and computer readable storage medium | |
| CN110602095B (en) | Data distribution and storage method and device based on block chain network | |
| CN110597541B (en) | Interface updating processing method, device, equipment and storage medium based on block chain | |
| CN109656778A (en) | Data capture method, device, computer equipment and storage medium | |
| CN110597918A (en) | Account management method and device and computer readable storage medium | |
| CN113765675B (en) | Transaction data processing method, device, equipment and medium | |
| CN112448946A (en) | Log auditing method and device based on block chain | |
| CN112087497B (en) | Data synchronization method and device, electronic equipment and readable storage medium | |
| CN110597883A (en) | Vehicle rental data processing method and device based on block chain and storage medium | |
| CN110599267A (en) | Electronic invoice billing method and device, computer readable storage medium and computer equipment | |
| CN116827957B (en) | Information processing method, device, equipment and medium based on multi-block chain | |
| CN111506661B (en) | Content access management method, device and storage medium | |
| CN112163917B (en) | Bill processing method and device based on blockchain, medium and electronic equipment | |
| CN110598449B (en) | Data processing method and device for performing insurance function, storage medium and computer equipment | |
| CN117057913A (en) | Block chain management method, device, computer, storage medium and program product |
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 |