CN110572281B - Credible log recording method and system based on block chain - Google Patents
Credible log recording method and system based on block chain Download PDFInfo
- Publication number
- CN110572281B CN110572281B CN201910783467.0A CN201910783467A CN110572281B CN 110572281 B CN110572281 B CN 110572281B CN 201910783467 A CN201910783467 A CN 201910783467A CN 110572281 B CN110572281 B CN 110572281B
- Authority
- CN
- China
- Prior art keywords
- node
- log
- nodes
- consensus
- block
- 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
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1854—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with non-centralised forwarding system, e.g. chaincast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/069—Management of faults, events, alarms or notifications using logs of notifications; Post-processing of notifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
Abstract
The invention discloses a credible log recording method based on a block chain, which provides an overall architecture suitable for a distributed log system based on the block chain, and provides specific designs of each module and each layer in the overall architecture; particularly, in a consensus layer of a distributed accounting module, a multi-version concurrency control method, a random algorithm and an event monitoring mechanism are combined to improve the traditional practical Byzantine fault-tolerant algorithm. The invention is used for solving the problem of credible log function loss of further consensus verification on the correctness of the log generated by the node and the operation authority of the node in the existing distributed system and improving the problem of large communication traffic of the traditional practical Byzantine fault-tolerant algorithm.
Description
Technical Field
The invention relates to the research field of system log processing of computer application, in particular to a trusted log recording method and system based on a block chain.
Background
With the rapid development of computer technology and the increasing speed of internet, various computer application systems come into existence, and a log system is a very important functional component in a complete application system. It provides functions of log collection, log storage, log query, log analysis and the like. The application system can track various operation processes of the tracing user in the system through log query, and simultaneously carry out abnormal alarm and the like through log analysis. The mainstream open source distributed log systems at present are Scribe, Chukwa, Kafka, Flume systems and the like.
The Scribe system is an open-source real-time distributed log collection system developed by Facebook in the operation process of an internal application system of a company, collects log data generated by each node by using the Scribe service through installing the Scribe service on each node in the distributed system, and then collects the log data to a central service cluster of the distributed system, and the cluster stores the collected log data sent by each node in a centralized manner so as to perform off-line analysis on the log data; chukwa and Kafka are distributed log open source systems developed by Apache, and are different in that Chuwa focuses on monitoring data collection of a large-scale distributed system, and meanwhile, a powerful and flexible tool set is provided for developers, so that the developers can more conveniently display, monitor and analyze data collected from a distributed application system. Kafka focuses on real-time processing of message streams, is compiled by Scala and Java, and issues and subscribes messages in a distributed and real-time manner through a producer-consumer mode; like the script, the Flume focuses mainly on the collection, aggregation and transmission of log data of each node in the distributed system, and is sourced by Cloudera and provided for developers to use.
The distributed log system only provides functions of log collection, log storage and the like, and does not perform further consensus verification on the correctness of the logs generated by the nodes in the distributed system and the operation authority of the nodes.
The other block chain is essentially a distributed database with a chain structure, and is different from distributed databases with other master-slave architectures in that the block chain is a decentralized or multicentric database, nodes in the system are in peer-to-peer relationship, and the generation of new block data requires the nodes to achieve consensus. The data in the blockchain is essentially of a publicly transparent and non-tamperable nature. By synthesizing the existing blockchain project, the basic architecture model of the blockchain system can be basically divided into six layers, namely a data layer, a network layer, a consensus layer, an excitation layer, a contract layer and an application layer. The infrastructure model of the existing blockchain system is not particularly suitable for the log system, for example, the data layer stores all data in the blockchain in the blocks, and the data is not classified according to the specific characteristics of the data. For example, the log system does not need a stimulus layer and a contract layer, and a general interface layer of other application systems when the log system is used is needed. Finally, the practical Byzantine fault-tolerant algorithm is widely applied to a block chain alliance chain system as a consensus algorithm, and the problem that the consensus rate is obviously reduced along with the increase of the number of nodes in the system exists.
Disclosure of Invention
The invention mainly aims to overcome the defects and shortcomings in the prior art, and provides a block chain-based credible log recording method which is used for solving the problems that the existing distributed log system and the existing block chain infrastructure model are not suitable for a log system and a practical Byzantine fault-tolerant algorithm, and the consensus rate is obviously reduced along with the increase of the number of nodes in the system.
It is another object of the present invention to provide a trusted logging system based on block chains.
The main purpose of the invention is realized by the following technical scheme:
a credible log recording method based on a block chain comprises the following steps:
s1, registering and auditing the common nodes, managing the checked common nodes in the management node of the block chain system,
s2, registering the successful common node, starting the node and adding the node into a distributed accounting module of the block chain system;
s3, the common node submits a data operation request to generate a data operation log, and the data operation log is broadcasted in the block chain system in the whole network; after receiving the log, other nodes verify the log; randomly selecting common nodes as consensus nodes according to a proportion, and performing log block verification and view replacement certificate verification on the new log block through the consensus nodes, namely performing consensus verification;
s4, if the log data reach consensus, storing the data as block data in each node of the block chain system, and after the remaining common nodes generate new log blocks, requesting the consensus node to synchronize the new log blocks to complete log recording; if the log data does not achieve consensus, an error is reported.
Further, the common node is an application program; the management node is a management end; the consensus node is a common node participating in block consensus.
Further, the step S1 is specifically: the step S1 specifically includes:
the common node submits node information to a management terminal, an administrator logs in the management terminal to check the node information, and the node information is written into a database after the check is passed; the node information comprises an IP address, a node public key, a node access address, an operation authority and an organization to which the node belongs;
and auditing the common nodes, and managing the checked common nodes by using a management node of the block chain system, wherein the management comprises dynamic registration/cancellation, key distribution, authority distribution and authority inquiry.
Further, the step S2 is specifically: s201, after a common node is started, adding the common node into a distributed accounting module of a block chain system, sending a request for acquiring all node information of the system and a request for acquiring all node authority information to a management terminal, verifying the requests by the management terminal, namely performing IP address verification and public key verification, verifying whether the node sending the request is a node which is registered successfully in the block chain system, and after the verification is passed, returning relevant data in a database to the node;
s202, after the node information request is successful, the node can broadcast a view acquisition request to all nodes in the block chain system, and after receiving the same view return message sent by a certain number of different nodes, the node updates the view of the node; the certain number is the sum of the nodes of the block chain system minus the fault tolerance;
s203, the node needs to broadcast a latest block synchronization request to other nodes in the block chain system, wherein the synchronization request comprises a hash value of a local latest block; when the node receives that the hash value of a previous point in the block corresponds to the hash value of the local latest block, the node sends a request to the corresponding node again to obtain the whole content of the next block until the data in the local block chain of the node is consistent with the data in the local block chains of other nodes in the block chain system;
s204, when the node normally runs, sending a node authority information request to the management terminal every K hours, sending a node information request every L minutes, and broadcasting a block synchronization request to the whole network every M seconds;
and after the process is completed, the common node is successfully started, and the successfully started node can participate in the consensus verification of the new block.
Further, the step S3 is specifically: randomly selecting common nodes as consensus nodes according to a proportion, wherein the consensus nodes comprise consensus main nodes and consensus slave nodes; the common node submits a data operation request, generates a data operation log and performs whole-network broadcasting in a block chain system; after other nodes receive the log, log verification is carried out on the log at a local node server, wherein the log verification comprises conflict judgment, permission judgment, instruction pre-execution and signature judgment;
judging whether the operation request node has an operation type in the database or not by each node in the block chain system according to the authority information of all local nodes, if so, performing the next step, and if not, returning an error code; the instruction pre-execution is to execute the instructions in the log, judge whether the instructions are correct, and then perform rollback, if the instructions are correct, perform the next step, and if the instructions are wrong, return an error code; judging whether the instruction is generated by the node according to the value of the instruction log by the public key of the node generating the instruction in the instruction log and the log signature;
after the consensus master node verifies the instruction log, an instruction sequence number is distributed to the instruction log, wherein the instruction log received by the instruction sequence number table consensus master node is sequentially increased, and the instruction log is stored in an instruction log pool to be packaged;
the number of the reply log instructions received by the consensus master node from all the consensus slave nodes passes the verification is larger than the threshold value, the correctness is returned, and the reply number is larger than the threshold value; if the number of the common identification slave nodes is smaller than the threshold value, broadcasting the common identification slave nodes, and canceling the instruction stored in the instruction log pool to be packaged; the threshold is the total number of the nodes of the block chain system minus the fault tolerance, namely the threshold is calculated according to the fault tolerance in the PBFT algorithm and belongs to a part of the PBFT algorithm: assuming that the total number of nodes in the system is 3f +1, the fault tolerance of the system is f, so the threshold is 2f + 1.
Performing log block verification and view replacement certificate verification of the new log block through the consensus node, namely performing consensus verification;
specifically, log block verification is performed on the basis of log verification;
wherein, the log block verification: after the common identification master node finishes packaging the new log blocks, the common identification master node packages the new log blocks into a message broadcasted by the common identification slave node when the common identification negotiation is carried out between the nodes, and after the common identification slave node receives a formula message broadcasted by the common identification master node, the common identification slave node analyzes the new log blocks in the message to carry out log block verification:
verifying whether the timestamp in the log block header is greater than the timestamp generated by the last log block and less than the local timestamp; whether the log block height is the latest log block height in the local block chain plus one; the consensus slave node compares the blockHash value of the latest log block in the local block chain with the previousBlockHash value of the received new log block, and verifies whether the blockHash values are equal or not; the consensus slave node calculates a hash value from a first instruction in an unpackInstructionList log pool to an instruction log of the sequence number according to the last transaction sequence number in the new log block, constructs a Merkel tree, compares the value of the Merkel tree root node with the value of the Merkel tree root node in the new log block head, verifies whether the values are equal, and transfers the related instruction log to a packedInstructionList log pool; after the verification is passed, the consensus slave node calculates the blockHash value again according to the block head and the block weight, and verifies whether the received blockHash value is correct or not;
view replacement certificate verification: after the consensus master node fails or becomes a malicious node, initiating message communication for consensus master node replacement between the consensus slave nodes, and verifying a view replacement certificate:
defining the message format of the View replacement certificate as < View-change, v +1, m, s, i >, wherein v is the number of a View to be replaced, m is the randomly generated 32-bit string information of a node broadcasting the View replacement certificate, s is the signature of a private key between nodes on the information m, and i is the node number of a View replacement certificate sending node; judging whether the view number is the current view number of the node or not; judging whether a view replacement certificate sent by the node is received for the first time or not according to the node number i and the message stored in the ViewChange message set; and acquiring the public key of the corresponding node in the local memory of the node according to the node number i, and verifying whether the signature s in the certificate is correct or not by combining the information m in the certificate.
Further, the random selection of the common nodes in proportion as the consensus nodes specifically comprises: and selecting a consensus master node by the view change protocol, randomly selecting a consensus slave node by the consensus master node, and broadcasting the consensus slave node to all nodes by the consistency protocol after the selection is finished.
Further, the threshold is the total number of nodes of the blockchain system minus the fault tolerance.
Further, the step S4 is specifically:
the consensus process is as follows: combining an MVCC method, adding a record data version number to each database table of entity data, and using the MVCC method to realize CAS optimistic lock of log data in a block chain application layer, wherein the optimistic lock comprises conflict detection and data updating; the conflict detection specifically comprises the steps of performing conflict detection on instruction log data which are about to enter a log pool, putting the instruction log data into the log pool after no conflict exists, and finally packaging the instruction logs in the log pool into block bodies in batches and performing consensus;
if the log data agrees, storing as block data in each node of the blockchain system; if the log data can not reach the consensus, reporting an error; and after the new log block is generated, the rest common nodes request the common node for synchronizing the new log block, and the log record is completed.
The other purpose of the invention is realized by the following technical scheme:
a credible log recording system based on a block chain is characterized by comprising a management module and a distributed accounting module;
the management module comprises a background management end, wherein the background management end is used for managing common nodes, and the management comprises the steps of carrying out dynamic registration, dynamic logout, key distribution, authority distribution and authority inquiry on the common nodes and carrying out basic management on users using the background management end;
the distributed accounting module is divided into a data layer, a network layer, a consensus layer, an interface layer and an application layer; the data layer is used for processing log data and separately storing entity data and log block data; the network layer is used for transmitting and verifying log data, networking common nodes in a fully distributed P2P network structure, and networking the common nodes and the management nodes in a centralized structure; the consensus layer is used for performing consensus on the log data; the interface layer is used for log generation, log query and log analysis; the application layer is an application for generating logs.
Further, the data layer performs distributed chained non-tamperable storage of log data in data blocks.
Compared with the prior art, the invention has the following advantages and beneficial effects:
the invention solves the problems that the existing distributed log system does not carry out further consensus verification on the correctness of the log generated by the node in the distributed system and the operation authority of the node, and the existing block chain system infrastructure model is not suitable for the log system and the problem that the consensus rate is obviously reduced along with the increase of the node number in the distributed system by the traditional PBFT algorithm.
Drawings
FIG. 1 is a flow chart of a method for block chain based trusted logging in accordance with the present invention;
fig. 2 is a flowchart of a general node registration in the embodiment of the present invention;
FIG. 3 is a flowchart of a generic node start-up in the embodiment of the present invention;
FIG. 4 is a flowchart illustrating a common node log validation process according to an embodiment of the present invention;
FIG. 5 is a block chain-based log system according to an embodiment of the present invention;
FIG. 6 is a network diagram of nodes in the embodiment of the present invention;
fig. 7 is a design diagram of functional modules in the employment support system in the embodiment of the present invention.
Detailed Description
The present invention will be described in further detail with reference to examples and drawings, but the present invention is not limited thereto.
Example (b):
a block chain based trusted logging method, as shown in fig. 1, includes the following steps,
s1, registration and audit are carried out on the common nodes, and the checked common nodes are managed in the management node of the block chain system, which specifically comprises the following steps:
the common node submits node information to a management terminal, an administrator logs in the management terminal to check the node information, and the node information is written into a database after the check is passed; the node information comprises an IP address, a node public key, a node access address, an operation authority and an organization to which the node belongs;
and auditing the common nodes, and managing the checked common nodes by using a management node of the block chain system, wherein the management comprises dynamic registration/cancellation, key distribution, authority distribution and authority inquiry.
S2, registering the successful common node, starting the node and adding the node into a distributed accounting module of the block chain system; the method specifically comprises the following steps:
s201, after a common node is started, adding the common node into a distributed accounting module of a block chain system, sending a request for acquiring all node information of the system and a request for acquiring all node authority information to a management terminal, verifying the requests by the management terminal, namely performing IP address verification and public key verification, verifying whether the node sending the request is a node which is registered successfully in the block chain system, and after the verification is passed, returning relevant data in a database to the node;
s202, after the node information request is successful, the node can broadcast a view acquisition request to all nodes in the block chain system, and after receiving the same view return message sent by a certain number of different nodes, the node updates the view of the node; the certain number is the sum of the nodes of the block chain system minus the fault tolerance;
s203, the node needs to broadcast a latest block synchronization request to other nodes in the block chain system, wherein the synchronization request comprises a hash value of a local latest block; when the node receives that the hash value of a previous point in the block corresponds to the hash value of the local latest block, the node sends a request to the corresponding node again to obtain the whole content of the next block until the data in the local block chain of the node is consistent with the data in the local block chains of other nodes in the block chain system;
s204, when the node normally runs, sending a node authority information request to the management terminal every K hours, sending a node information request every L minutes, and broadcasting a block synchronization request to the whole network every M seconds;
and after the process is completed, the common node is successfully started, and the successfully started node can participate in the consensus verification of the new block.
S3, the common node submits a data operation request to generate a data operation log, and the data operation log is broadcasted in the block chain system in the whole network; after receiving the log, other nodes verify the log; randomly selecting common nodes as consensus nodes according to a proportion, and performing log block verification and view replacement certificate verification on the new log block through the consensus nodes, namely performing consensus verification; the method specifically comprises the following steps:
randomly selecting common nodes as consensus nodes according to a proportion, wherein the consensus nodes comprise consensus main nodes and consensus slave nodes; the common node submits a data operation request, generates a data operation log and performs whole-network broadcasting in a block chain system; after other nodes receive the log, log verification is carried out on the log at a local node server, wherein the log verification comprises conflict judgment, permission judgment, instruction pre-execution and signature judgment;
judging whether the operation request node has an operation type in the database or not by each node in the block chain system according to the authority information of all local nodes, if so, performing the next step, and if not, returning an error code; the instruction pre-execution is to execute the instructions in the log, judge whether the instructions are correct, and then perform rollback, if the instructions are correct, perform the next step, and if the instructions are wrong, return an error code; judging whether the instruction is generated by the node according to the value of the instruction log by the public key of the node generating the instruction in the instruction log and the log signature;
after the consensus master node verifies the instruction log, an instruction sequence number is distributed to the instruction log, wherein the instruction log received by the instruction sequence number table consensus master node is sequentially increased, and the instruction log is stored in an instruction log pool to be packaged;
the number of the reply log instructions received by the consensus master node from all the consensus slave nodes passes the verification is larger than the threshold value, the correctness is returned, and the reply number is larger than the threshold value; if the number of the common identification slave nodes is smaller than the threshold value, broadcasting the common identification slave nodes, and canceling the instruction stored in the instruction log pool to be packaged; the threshold is the total number of the nodes of the block chain system minus the fault tolerance, namely the threshold is calculated according to the fault tolerance in the PBFT algorithm and belongs to a part of the PBFT algorithm: assuming that the total number of nodes in the system is 3f +1, the fault tolerance of the system is f, so the threshold is 2f + 1.
Performing log block verification and view replacement certificate verification of the new log block through the consensus node, namely performing consensus verification;
specifically, log block verification is performed on the basis of log verification;
wherein, the log block verification: after the common identification master node finishes packaging the new log blocks, the common identification master node packages the new log blocks into a message broadcasted by the common identification slave node when the common identification negotiation is carried out between the nodes, and after the common identification slave node receives a formula message broadcasted by the common identification master node, the common identification slave node analyzes the new log blocks in the message to carry out log block verification:
verifying whether the timestamp in the log block header is greater than the timestamp generated by the last log block and less than the local timestamp; whether the log block height is the latest log block height in the local block chain plus one; the consensus slave node compares the blockHash value of the latest log block in the local block chain with the previousBlockHash value of the received new log block, and verifies whether the blockHash values are equal or not; the consensus slave node calculates a hash value from a first instruction in an unpackInstructionList log pool to an instruction log of the sequence number according to the last transaction sequence number in the new log block, constructs a Merkel tree, compares the value of the Merkel tree root node with the value of the Merkel tree root node in the new log block head, verifies whether the values are equal, and transfers the related instruction log to a packedInstructionList log pool; after the verification is passed, the consensus slave node calculates the blockHash value again according to the block head and the block weight, and verifies whether the received blockHash value is correct or not;
view replacement certificate verification: after the consensus master node fails or becomes a malicious node, initiating message communication for consensus master node replacement between the consensus slave nodes, and verifying a view replacement certificate:
defining the message format of the View replacement certificate as < View-change, v +1, m, s, i >, wherein v is the number of a View to be replaced, m is the randomly generated 32-bit string information of a node broadcasting the View replacement certificate, s is the signature of a private key between nodes on the information m, and i is the node number of a View replacement certificate sending node; judging whether the view number is the current view number of the node or not; judging whether a view replacement certificate sent by the node is received for the first time or not according to the node number i and the message stored in the ViewChange message set; and acquiring the public key of the corresponding node in the local memory of the node according to the node number i, and verifying whether the signature s in the certificate is correct or not by combining the information m in the certificate.
S4, if the log data reach consensus, storing the data as block data in each node of the block chain system, and after the remaining common nodes generate new log blocks, requesting the consensus node to synchronize the new log blocks to complete log recording; if the log data does not achieve consensus, an error is reported.
In the log system management process, as shown in fig. 2, only the normal node that is successfully registered at the management node can participate in the generation of the log block in the system. The registration process of the common node at the log system management end comprises four steps of node registration, node audit, key distribution and authority distribution.
As shown in fig. 3, the starting process of a common node in a log system based on a block chain includes the steps of: and starting the nodes, connecting the management end, acquiring all node information if the connection is successful, establishing connection with other nodes, sending a view acquisition message in a group mode, acquiring view information, sending a block synchronization message in a group mode, and synchronizing blocks. After the registration of the common node at the management end is successful, the flow when the common node is started to join the distributed accounting module of the block chain system mainly comprises the steps of obtaining node information, establishing connection with other nodes, obtaining view information and synchronizing local blocks of the nodes, and after the synchronization of the blocks is completed, the common node can represent that the node is started successfully, so that the common node can participate in the consensus verification of a new block.
And the data storage mode of the data layer is used for storing the entity data in the specific application system and the log block data in the distributed accounting module separately in different databases. All nodes in the distributed log system completely backup log blocks and entity data. The requirement of write operation in the log block is larger than that of read operation, while the requirement of entity data belonging to read operation is larger than that of write operation relatively, the two different data are respectively stored according to the specific requirements, which is beneficial to improving the overall performance of data operation of the distributed system. The networking mode of the nodes in the network layer adopts a fully distributed P2P network structure to perform networking among all common nodes in a alliance chain, and the networking is performed between the common nodes and the management nodes in a centralized mode.
And (4) a verification mechanism of a network layer in the distributed accounting module. The verification mechanism in the log system based on the block chain comprises the verification of three types of data: the method comprises the steps of database operation instruction log verification, log block verification and view replacement certificate verification. The MVCC method is combined in the verification of the database operation instruction log, as shown in fig. 4, the instruction log is generated at the local node server, the conflict judgment and the permission judgment are carried out, and the instruction pre-execution is carried out; performing conflict judgment and authority and signature judgment on the consensus main node, performing instruction pre-execution, and then performing instruction log sequence number allocation and storage; performing conflict judgment and authority and signature judgment on all the consensus slave nodes, performing instruction pre-execution, performing instruction log storage, and performing instruction log revocation; the method is used for ensuring the correct execution of database transactions and improving the concurrency performance of a block chain system; based on log block verification operation instruction log verification, performing basic verification on the block to ensure the correctness of block data in a block chain; and the view replacement certificate verification is used for ensuring the correctness of the next round of main node and consensus node selection process among the system nodes after the main node is down.
And a consensus algorithm of a consensus layer in the distributed accounting module. The consensus algorithm is improved on the basis of a traditional Practical Byzantine Fault Tolerance (PBFT) algorithm. Considering that the efficiency of the conventional PBFT algorithm for achieving consensus is higher when there are fewer network nodes in the distributed system, as the number of network nodes increases, the communication amount between the nodes significantly increases, and the rate of achieving consensus significantly decreases. The invention reduces the communication traffic among the nodes by combining a Multi-Version Concurrency Control (MVCC) method, a random algorithm and an event monitoring mechanism. (1) Combining with an MVCC method: adding a version field in the design of each database table of entity data for recording the version number of each piece of data, and realizing CAS (Compare and Swap) optimistic lock of log data at a block chain application level by using an MVCC method, wherein the optimistic lock mainly comprises the following two steps: collision detection and data update. In the alliance chain, the MVCC method is combined to perform conflict detection on the instruction log data which are about to enter the log pool, the instruction log data are placed into the log pool after no conflict exists, and finally the instruction logs in the log pool are packaged into the block body in batches and then are subjected to consensus process, so that the total times of consistent consensus among nodes can be reduced. (2) Randomly selecting a consensus node: when the number of nodes of the distributed system is small, the efficiency of achieving consensus of log blocks among the nodes based on the traditional PBFT algorithm is high, but the efficiency of achieving consensus among the nodes is reduced rapidly as the number of the nodes in the system increases. A large number of experiments show that when the number of nodes in a distributed system based on the PBFT algorithm exceeds 100, the overall performance of the system is poor, and the efficiency of consensus is low. Aiming at the problems of large traffic and low consensus efficiency when the number of system nodes in a consistency protocol is large, after the number of the system nodes exceeds a certain threshold value, the fairness and the unpredictability when the consensus nodes are selected are considered at the same time, the invention provides a method for combining a random algorithm and a PBFT algorithm, a certain number of nodes are randomly selected in all the nodes of the system according to a proportion as the consensus nodes, the generation verification of a new log block is carried out, and other nodes only need to request the synchronous latest block from the consensus nodes after the new log block is generated, so that the final consistency of the block data in all the nodes in a alliance chain system is achieved. The specific election process of the consensus node is carried out in the view change protocol. (3) An event monitoring mechanism: the traditional PBFT algorithm executes a checkpoint protocol through message communication among nodes in a distributed system, maintains the scale of information stored in a memory in each node, and reduces the memory overhead of the nodes. The improved PBFT algorithm of the invention replaces message communication among nodes by setting an event listener to clean expired data in a node memory, thereby reducing communication traffic among nodes in a distributed system.
A block chain based trusted logging system, as shown in FIG. 5, is generally divided into two modules, one of which is a federation chain management module, i.e., a management module, and the other is a distributed accounting module.
The management module is composed of a background management end, does not participate in the generation of data blocks in the log system, is mainly used for managing nodes in the alliance chain, and mainly comprises user management, node management, key management and authority management: and performing services such as dynamic registration/cancellation, key distribution, authority inquiry and the like on the nodes passing the verification, and performing basic management on the user using the management terminal.
The distributed accounting module is composed of all common nodes in a log system based on a alliance chain, the nodes are connected pairwise to form a peer-to-peer network with a P2P structure, and generation of a new block is determined jointly through a consensus mechanism. The distributed accounting module is totally divided into five layers, namely a data layer, a network layer, a consensus layer, an interface layer and an application layer; the data layer comprises a log block, a chain structure, a timestamp, a hash function, a flying symmetric encryption and a data verification; the network layer comprises a P2P network, a propagation mechanism and a verification mechanism; the consensus layer comprises PBFT + random + MVCC + event monitoring; the interface layer includes log generation, log querying, log analysis, and other functions.
The data layer comprises a log block, a chain structure, a timestamp, a hash function, a fly symmetric encryption and a data verification; the log block data in the distributed accounting module and the entity data in the specific application are stored separately, and may be stored in a relational database MySQL, Oracle, SQLite, or the like, or may be stored in a non-relational database Redis, Level DB, RocksDB, or the like, which is mainly determined according to the specific application scenario of the system. And the writing operation of the entity data is less, the query operation is more, and each complete node in the alliance chain system also needs to store all the entity data, so the SQLite relational database is selected. The SQLite is an in-process library that implements a self-sufficient, serverless, zero-configuration, transactional SQL data engine, the zero-configuration of which facilitates the deployment of nodes in a federation chain, and supports the functionality of most query languages of the SQL2 standard. And the entity data is connected into a specific system of the log federation chain application through a third-party database connection plug-in. The storage of log block data is the same as that of bitcoin and Ether block data, and the log block data is selected to be stored in a non-relational database levelDB, wherein the levelDB is a single-version persistent KV database developed by Google, has high random writing and sequential reading/writing performances, has general random reading performance and is just suitable for scenes with less block data query but much writing in a block chain.
As shown in fig. 6, if there are 4 normal nodes and 1 management end node in the log system based on the block chain, the networking mode of the nodes in the system is as follows: all the common nodes are networked in a fully distributed P2P network structure, and the common nodes and the management nodes are networked in a centralized mode.
The block chain-based log system network layer comprises a P2P network, a propagation mechanism and a verification mechanism; the verification mechanism comprises three types of data verification: the method comprises the steps of database operation instruction log verification, log block verification and view replacement certificate verification. The MVCC method is combined in the verification of the database operation instruction log, so that the correct execution of database transactions is ensured, and the concurrency performance of a block chain system is improved; based on log block verification operation instruction log verification, performing basic verification on the block to ensure the correctness of block data in a block chain; and the view replacement certificate verification is used for ensuring the correctness of the next round of main node and consensus node selection process among the system nodes after the main node is down.
The PBFT algorithm in the log system consensus mechanism based on the block chain is divided into a consistency protocol, a view change protocol and a checkpoint protocol.
The MVCC method is combined in the disposable protocol, on one hand, the MVCC method ensures that the system only needs to be locked when in write operation and not locked when in read operation, so that the read and write of the system are not conflicted, and the throughput of the system can be improved in an application entity database with more read and less write; on the other hand, compared with the table lock realized by the method, the optimistic lock realized by the MVCC method has higher fine granularity, and the concurrency performance is relatively improved. And finally, before the instruction logs are subjected to consensus operation, conflict detection is performed in advance, the double-flower problem is prevented, batch consensus operation of the logs is performed, and the operation times of the consistency protocol in the system are reduced.
In the view change protocol, when the number of nodes in a log system based on a block chain exceeds a threshold value, a random algorithm is introduced, and a method of randomly selecting a consensus node in a certain proportion is used for optimizing the system performance according to the total number of the nodes in the system. In the optimization method, a view change protocol is divided into two parts, one part is selection of a common node in a view, and a part of nodes are randomly selected from all common nodes to serve as the common node, so that the number of communication times among the nodes required when a block obtains system common knowledge is reduced; the other part is the selection of the main node, and the participating nodes are only the common nodes under the view in the system.
In the checkpoint protocol, an event listener is arranged to replace a traditional PBFT algorithm to execute the checkpoint protocol through message communication among nodes, so that outdated data in a node memory is cleaned, and communication traffic among nodes in a distributed system is reduced.
As shown in fig. 7, the block chain based log system is designed into a functional module when the log system is applied specifically in a certain employment support system. The log system based on the block chain provides technical support for personal data management of employment support systems and management functions of enterprises and organizations, records personal learning and working experiences, annual qualification of enterprises and the like in a full-process running-water accounting mode, enables personal and enterprise data stored in the block chain not to be tampered, and enhances the credibility of the data in the system.
In the functional module design of fig. 7, the log system based on the block chain mainly provides information such as credible and traceable personal calendars/curriculum vitae, enterprise qualification and the like for the employment unit of the employment support module in the three-created platform and job hunting personnel such as students or social people. The block chain-based log system and the employment support system perform data interaction through a data interface, wherein the employment support system mainly records and queries information of individuals and personnel units by calling the data interface provided by the log system, the log system receives a data request of the employment support system, which needs to be recorded in the block chain, through the data interface, and the data are verified and coordinated in consistency among nodes in the system through a consensus mechanism. From the overall architecture of the block chain-based log system, the system is a employment support module and comprises a employment support function and a log alliance chain; the employment support function comprises recruitment station management, personal data management, job hunting management, recruitment management, enterprise and organization management and off-school practice management; the log alliance chain comprises a distributed accounting module and a management module, wherein the distributed accounting module comprises a data storage module, a peer-to-peer network module, a consensus algorithm module, a message queue module and an interface calling module, and the management module comprises user management, node management, key management and authority management.
The above embodiments are preferred embodiments of the present invention, but the present invention is not limited to the above embodiments, and any other changes, modifications, substitutions, combinations, and simplifications which do not depart from the spirit and principle of the present invention should be construed as equivalents thereof, and all such changes, modifications, substitutions, combinations, and simplifications are intended to be included in the scope of the present invention.
Claims (10)
1. A credible log recording method based on a block chain is characterized by comprising the following steps:
s1, registering and auditing the common nodes, managing the checked common nodes in the management node of the block chain system,
s2, registering the successful common node, starting the node and adding the node into a distributed accounting module of the block chain system;
s3, the common node submits a data operation request to generate a data operation log, and the data operation log is broadcasted in the block chain system in the whole network; after receiving the log, other nodes verify the log; randomly selecting common nodes as consensus nodes according to a proportion, and performing log block verification and view replacement certificate verification on the new log block through the consensus nodes, namely performing consensus verification; the log verification comprises conflict judgment, authority judgment, instruction pre-execution and signature judgment; judging whether the operation request node has an operation type in the database or not by each node in the block chain system according to the authority information of all local nodes, if so, performing the next step, and if not, returning an error code; the instruction pre-execution is to execute the instructions in the log, judge whether the instructions are correct, and then perform rollback, if the instructions are correct, perform the next step, and if the instructions are wrong, return an error code; judging whether the instruction is generated by the node according to the value of the instruction log by the public key of the node generating the instruction in the instruction log and the log signature;
s4, if the log data reach consensus, storing the data as block data in each node of the block chain system, and after the remaining common nodes generate new log blocks, requesting the consensus node to synchronize the new log blocks to complete log recording; if the log data does not achieve consensus, an error is reported.
2. The method according to claim 1, wherein the common node is an application program; the management node is a management end; the consensus node is a common node participating in block consensus.
3. The method according to claim 2, wherein the step S1 specifically includes:
the common node submits node information to a management terminal, an administrator logs in the management terminal to check the node information, and the node information is written into a database after the check is passed; the node information comprises an IP address, a node public key, a node access address, an operation authority and an organization to which the node belongs;
and auditing the common nodes, and managing the checked common nodes by using a management node of the block chain system, wherein the management comprises dynamic registration/cancellation, key distribution, authority distribution and authority inquiry.
4. The method according to claim 2, wherein the step S2 specifically includes:
s201, after a common node is started, adding the common node into a distributed accounting module of a block chain system, sending a request for acquiring all node information of the system and a request for acquiring all node authority information to a management terminal, verifying the requests by the management terminal, namely performing IP address verification and public key verification, verifying whether the node sending the request is a node which is registered successfully in the block chain system, and after the verification is passed, returning relevant data in a database to the node;
s202, after the node information request is successful, the node can broadcast a view acquisition request to all nodes in the block chain system, and after receiving the same view return message sent by a certain number of different nodes, the node updates the view of the node; the certain number is the sum of the nodes of the block chain system minus the fault tolerance;
s203, the node needs to broadcast a latest block synchronization request to other nodes in the block chain system, wherein the synchronization request comprises a hash value of a local latest block; when the node receives that the hash value of a previous point in the block corresponds to the hash value of the local latest block, the node sends a request to the corresponding node again to obtain the whole content of the next block until the data in the local block chain of the node is consistent with the data in the local block chains of other nodes in the block chain system;
s204, when the node normally runs, sending a node authority information request to the management terminal every K hours, sending a node information request every L minutes, and broadcasting a block synchronization request to the whole network every M seconds;
and after the process is completed, the common node is successfully started, and the successfully started node can participate in the consensus verification of the new block.
5. The method according to claim 1, wherein the step S3 specifically includes:
randomly selecting common nodes as consensus nodes according to a proportion, wherein the consensus nodes comprise consensus main nodes and consensus slave nodes; the common node submits a data operation request, generates a data operation log and performs whole-network broadcasting in a block chain system; after other nodes receive the log, log verification is carried out on the log at a local node server, wherein the log verification comprises conflict judgment, permission judgment, instruction pre-execution and signature judgment;
judging whether the operation request node has an operation type in the database or not by each node in the block chain system according to the authority information of all local nodes, if so, performing the next step, and if not, returning an error code; the instruction pre-execution is to execute the instructions in the log, judge whether the instructions are correct, and then perform rollback, if the instructions are correct, perform the next step, and if the instructions are wrong, return an error code; judging whether the instruction is generated by the node according to the value of the instruction log by the public key of the node generating the instruction in the instruction log and the log signature;
after the consensus master node verifies the instruction log, an instruction sequence number is distributed to the instruction log, wherein the instruction log received by the instruction sequence number table consensus master node is sequentially increased, and the instruction log is stored in an instruction log pool to be packaged;
the number of the reply log instructions received by the consensus master node from all the consensus slave nodes passes the verification is larger than the threshold value, the correctness is returned, and the reply number is larger than the threshold value; if the number of the common identification slave nodes is smaller than the threshold value, broadcasting the common identification slave nodes, and canceling the instruction stored in the instruction log pool to be packaged;
performing log block verification and view replacement certificate verification of the new log block through the consensus node, namely performing consensus verification;
specifically, log block verification is performed on the basis of log verification;
wherein, the log block verification: after the common identification master node finishes packaging the new log blocks, the common identification master node packages the new log blocks into a message broadcasted by the common identification slave node when the common identification negotiation is carried out between the nodes, and after the common identification slave node receives a formula message broadcasted by the common identification master node, the common identification slave node analyzes the new log blocks in the message to carry out log block verification:
verifying whether the timestamp in the log block header is greater than the timestamp generated by the last log block and less than the local timestamp; whether the log block height is the latest log block height in the local block chain plus one; the consensus slave node compares the blockHash value of the latest log block in the local block chain with the previousBlockHash value of the received new log block, and verifies whether the blockHash values are equal or not; the consensus slave node calculates a hash value from a first instruction in an unpackInstructionList log pool to an instruction log of the sequence number according to the last transaction sequence number in the new log block, constructs a Merkel tree, compares the value of the Merkel tree root node with the value of the Merkel tree root node in the new log block head, verifies whether the values are equal, and transfers the related instruction log to a packedInstructionList log pool; after the verification is passed, the consensus slave node calculates the blockHash value again according to the block head and the block weight, and verifies whether the received blockHash value is correct or not;
view replacement certificate verification: after the consensus master node fails or becomes a malicious node, initiating message communication for consensus master node replacement between the consensus slave nodes, and verifying a view replacement certificate:
defining the message format of the View replacement certificate as < View-change, v +1, m, s, i >, wherein v is the number of a View to be replaced, m is the randomly generated 32-bit string information of a node broadcasting the View replacement certificate, s is the signature of a private key between nodes on the information m, and i is the node number of a View replacement certificate sending node; judging whether the view number is the current view number of the node or not; judging whether a view replacement certificate sent by the node is received for the first time or not according to the node number i and the message stored in the ViewChange message set; and acquiring the public key of the corresponding node in the local memory of the node according to the node number i, and verifying whether the signature s in the certificate is correct or not by combining the information m in the certificate.
6. The method according to claim 5, wherein the proportionally randomly selected common nodes are used as consensus nodes, and specifically: and selecting a consensus master node by the view change protocol, randomly selecting a consensus slave node by the consensus master node, and broadcasting the consensus slave node to all nodes by the consistency protocol after the selection is finished.
7. The method of claim 5, wherein the threshold is a total number of nodes in the blockchain system minus a fault tolerance.
8. The method according to claim 1, wherein the step S4 specifically includes:
the consensus process is as follows: combining an MVCC method, adding a record data version number to each database table of entity data, and using the MVCC method to realize CAS optimistic lock of log data in a block chain application layer, wherein the optimistic lock comprises conflict detection and data updating; the conflict detection specifically comprises the steps of performing conflict detection on instruction log data which are about to enter a log pool, putting the instruction log data into the log pool after no conflict exists, and finally packaging the instruction logs in the log pool into block bodies in batches and performing consensus;
if the log data agrees, storing as block data in each node of the blockchain system; if the log data can not reach the consensus, reporting an error; and after the new log block is generated, the rest common nodes request the common node for synchronizing the new log block, and the log record is completed.
9. A credible log recording system based on a block chain is characterized by comprising a management module and a distributed accounting module;
the management module comprises a background management end, wherein the background management end is used for managing common nodes, and the management comprises the steps of carrying out dynamic registration, dynamic logout, key distribution, authority distribution and authority inquiry on the common nodes and carrying out basic management on users using the background management end;
the distributed accounting module is divided into a data layer, a network layer, a consensus layer, an interface layer and an application layer; the data layer is used for processing log data and separately storing entity data and log block data; the network layer is used for transmitting and verifying log data, networking common nodes in a fully distributed P2P network structure, and networking the common nodes and the management nodes in a centralized structure; the consensus layer is used for performing consensus on the log data; the interface layer is used for log generation, log query and log analysis; the application layer is an application for generating a log;
the log verification comprises conflict judgment, authority judgment, instruction pre-execution and signature judgment; judging whether the operation request node has an operation type in the database or not by each node in the block chain system according to the authority information of all local nodes, if so, performing the next step, and if not, returning an error code; the instruction pre-execution is to execute the instructions in the log, judge whether the instructions are correct, and then perform rollback, if the instructions are correct, perform the next step, and if the instructions are wrong, return an error code; the signature judgment is to judge whether the instruction is generated by the node according to the value of the instruction log by the public key of the node generating the instruction in the instruction log and the log signature.
10. The block chain based trusted logging system of claim 9, wherein said data layer performs distributed chained non-tamperable storage of log data in data blocks.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910783467.0A CN110572281B (en) | 2019-08-23 | 2019-08-23 | Credible log recording method and system based on block chain |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910783467.0A CN110572281B (en) | 2019-08-23 | 2019-08-23 | Credible log recording method and system based on block chain |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110572281A CN110572281A (en) | 2019-12-13 |
| CN110572281B true CN110572281B (en) | 2021-12-21 |
Family
ID=68775888
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910783467.0A Active CN110572281B (en) | 2019-08-23 | 2019-08-23 | Credible log recording method and system based on block chain |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110572281B (en) |
Families Citing this family (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111159302A (en) * | 2020-01-02 | 2020-05-15 | 杭州时戳信息科技有限公司 | Data synchronization method and device, computer readable storage medium and computing equipment |
| CN111221914A (en) * | 2020-01-15 | 2020-06-02 | 同方知网(北京)技术有限公司 | Data exchange sharing tracing method based on block chain |
| CN111339550B (en) * | 2020-02-01 | 2023-08-29 | 温州理工学院 | Comment information credibility method based on blockchain technology |
| CN113010480B (en) * | 2020-03-26 | 2024-03-19 | 腾讯科技（深圳）有限公司 | Log processing method, device, electronic equipment and computer readable storage medium |
| CN111478962A (en) * | 2020-04-03 | 2020-07-31 | 广东奥维信息科技有限公司 | Block chain trusted log storage system |
| CN111885088A (en) * | 2020-08-06 | 2020-11-03 | 中国银行股份有限公司 | Log monitoring method and device based on block chain |
| CN112433885B (en) * | 2020-11-19 | 2021-09-10 | 腾讯科技（深圳）有限公司 | Block chain consensus processing method and device, electronic equipment and storage medium |
| CN112615847B (en) * | 2020-12-14 | 2021-09-17 | 上海交通大学 | Data sharing and privacy protection method based on block chain |
| CN112733182A (en) * | 2020-12-22 | 2021-04-30 | 航天信息股份有限公司 | Method and system for accessing intranet private data by block chain node point |
| CN112598523A (en) * | 2020-12-30 | 2021-04-02 | 广东微聚科技有限公司 | Aggregation block chain system |
| CN112860482B (en) * | 2021-01-27 | 2021-11-12 | 西南林业大学 | Block chain consensus performance optimization method |
| CN112866421B (en) * | 2021-03-30 | 2023-02-24 | 中国工商银行股份有限公司 | Intelligent contract operation method and device based on distributed cache and NSQ |
| CN114071247B (en) * | 2021-11-02 | 2024-03-01 | 上海佰贝网络工程技术有限公司 | Block chain data broadcast transmission method, system, computer equipment and computer readable storage medium |
| CN114448900B (en) * | 2022-04-02 | 2022-08-02 | 南京邮电大学 | SDN controller interaction method and system based on extended raft algorithm |
| CN117614750A (en) * | 2024-01-24 | 2024-02-27 | 北京亚鸿世纪科技发展有限公司 | Network security log query method and system |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108306893A (en) * | 2018-03-05 | 2018-07-20 | 北京大学深圳研究生院 | A kind of Novel Distributed Intrusion Detection Method and system of ad-hoc network |
| CN108769173A (en) * | 2018-05-21 | 2018-11-06 | 阿里体育有限公司 | The block chain implementation method and equipment of the intelligent contract of operation |
| CN108830733A (en) * | 2018-06-21 | 2018-11-16 | 中国银行股份有限公司 | A kind of information processing method, block scm cluster and system |
| CN109785131A (en) * | 2018-12-21 | 2019-05-21 | 昆明理工大学 | A kind of electricity transaction method based on block chain |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108494581B (en) * | 2018-02-09 | 2020-12-29 | 孔泽一 | Controller distributed log generation method and device of SDN (software defined network) |
| CN109347804B (en) * | 2018-09-19 | 2020-02-07 | 电子科技大学 | Byzantine fault-tolerant consensus optimization method for block chain |
-
2019
- 2019-08-23 CN CN201910783467.0A patent/CN110572281B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108306893A (en) * | 2018-03-05 | 2018-07-20 | 北京大学深圳研究生院 | A kind of Novel Distributed Intrusion Detection Method and system of ad-hoc network |
| CN108769173A (en) * | 2018-05-21 | 2018-11-06 | 阿里体育有限公司 | The block chain implementation method and equipment of the intelligent contract of operation |
| CN108830733A (en) * | 2018-06-21 | 2018-11-16 | 中国银行股份有限公司 | A kind of information processing method, block scm cluster and system |
| CN109785131A (en) * | 2018-12-21 | 2019-05-21 | 昆明理工大学 | A kind of electricity transaction method based on block chain |
Non-Patent Citations (1)
| Title |
|---|
| 基于聚合签名的共识算法优化方案;苑超 等;《计算机科学》;20180215;第53-56、83页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110572281A (en) | 2019-12-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110572281B (en) | Credible log recording method and system based on block chain | |
| US11663090B2 (en) | Method and system for desynchronization recovery for permissioned blockchains using bloom filters | |
| US20220141018A1 (en) | Method and system for an efficient consensus mechanism for permissioned blockchains using audit guarantees | |
| Nathan et al. | Blockchain meets database: Design and implementation of a blockchain relational database | |
| US9984140B1 (en) | Lease based leader election system | |
| US20190251198A1 (en) | Autonomous Interdependent Repositories | |
| CN113438084B (en) | Green power source tracing method and system based on R-PBFT consensus algorithm and timestamp | |
| WO2020108289A1 (en) | Database system, node and method | |
| CN103605698A (en) | Cloud database system used for distributed heterogeneous data resource integration | |
| CN111241589A (en) | Database system, node and method | |
| CN111612619A (en) | Storage sharing platform based on block chain and storage transaction method | |
| CN111241590A (en) | Database system, node and method | |
| CN114490685A (en) | DNS data query updating method and system based on block chain and verifiable calculation | |
| CN110543606A (en) | Method and system for storing genealogy data based on alliance chain | |
| CN111506661B (en) | Content access management method, device and storage medium | |
| CN116467026A (en) | Cloud desktop data secure sharing and tracing method and system based on blockchain | |
| CN114661231B (en) | Storage synchronization method and device for parameter change records of power grid monitoring master station system | |
| CN115934832A (en) | Metering test detection data credible sharing method based on block chain | |
| CN117010889A (en) | Data processing method, device, equipment, medium and product | |
| CN113364592A (en) | Engineering system file management system and method based on credit value union chain | |
| WO2020108288A1 (en) | Database system, node, and method | |
| CN111917826A (en) | PBFT consensus algorithm based on block chain intellectual property protection | |
| CN112926091B (en) | Block chain-based data ownership recording and data transaction verification method and device | |
| WO2023098327A1 (en) | Blockchain-based block processing method and apparatus, device, storage medium, and program product | |
| Zhou et al. | An online query authentication system for outsourced databases |
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 |