CN112313916B - Method and system for pseudo-storage of anti-tampering logs by fusing block chain technology - Google Patents
Method and system for pseudo-storage of anti-tampering logs by fusing block chain technology Download PDFInfo
- Publication number
- CN112313916B CN112313916B CN201880093162.0A CN201880093162A CN112313916B CN 112313916 B CN112313916 B CN 112313916B CN 201880093162 A CN201880093162 A CN 201880093162A CN 112313916 B CN112313916 B CN 112313916B
- Authority
- CN
- China
- Prior art keywords
- log
- node
- query
- block
- block chain
- 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
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
A method for storing a tamper-resistant log by fusing block chain technology mimicry comprises the following steps: s1, collecting logs of all isomers in a mimicry storage system and converting the logs into logs in a standard format; s2, sending the converted standard log to a block chain network node, and packaging the log into a transaction by the block chain network node; s3, the block chain network node sends the transaction to a manager node, and the manager node stores the log into a pre-block; s4, the manager node sends the pre-blocks to a committee node, and the committee node verifies the pre-blocks and sends signatures to the manager node; s5, judging whether the collected committee signatures exceed half number by the housekeeper node; and S6, each node synchronizes the received new block into the block chain. And a block chain is used as a log storage module of the mimicry storage system to protect the mimicry storage log from being tampered. The process of generating the blocks by adopting the PoV algorithm has the advantages of low communication complexity, good performance and strong expandability, and is convenient for increasing or reducing the number of cluster nodes.
Description
Technical Field
The invention belongs to the field of internet technology improvement, and particularly relates to a method and a system for storing a tamper-proof log by fusing block chain technology mimicry.
Background
The distributed file system can effectively meet the huge requirements of mass data on storage and calculation, and has the advantages of expansibility, low cost and the like. The growing demand of uninterrupted file storage of the business system can be solved by expanding the storage capacity of the original system. The distributed file system is a basic application system constructed based on a single-machine operating system and a computer network environment, storage load is shared by a plurality of servers, file information is managed by using global metadata, and meanwhile, a large number of complex algorithms are used for guaranteeing data security, such as algorithms of consistency, fault tolerance, availability and the like.
The distributed file system uses a network as a transmission medium for data exchange, but rarely has a defense function against network attacks, is very vulnerable in the face of network attacks, and has the risks of data theft, data integrity damage and even storage cluster downtime. In addition, for security problems of the operating system, such as attacks of viruses, trojans and the like, security risks also exist in data on the distributed file system.
Besides the known attack mode, the traditional distributed storage system does not have a good coping mode when treating unknown system bugs. As a carrier of the distributed file system, the operating system inevitably has vulnerabilities. From the national information security level, there are few operation systems available for business use in China at present, and selectable objects are basically foreign products, and are influenced by business factors or national strategies, and part of the operation systems may be artificially set with backdoors, so that vulnerability events occurring on a computer system are frequent. Therefore, how to guarantee the security of data from the level of resisting the operating system attack and the network attack is also an important issue that must be considered in the future for the distributed file system.
As a solution for mass data storage, a distributed file system has many considerations on a data redundancy mechanism, but for some core confidential data, the security requirement is very strict, and how to achieve the purpose of providing normal services without interruption when the distributed file system faces attacks from intruders, it is obvious that this problem cannot be solved by a conventional data disaster recovery scheme.
The mimicry distributed file storage system adopts an active defense means aiming at unknown bugs and backdoors in the system. In the current internet environment, the core technology and the industrial foundation of the information field of China are seriously lagged, the network space attack cost and the defense cost have serious asymmetry, the national security requirement must be solved as soon as possible, and the idea of the security strategy of mimicry security defense is provided in the current background. The mimicry security defense emphasizes that different software and hardware variants are dynamically and pseudo-randomly selected to be executed under active and passive triggering conditions, and the similarity and the unicity of the system are changed by utilizing the isomerism and the diversity, so that the software and hardware execution environment observed by an attacker through a leak inside and outside the system or a backdoor has strong uncertainty, an attack chain based on the leak or the backdoor is difficult to construct, and finally the security risk of the system is effectively reduced. The DHR defense mechanism stems from the innovative theory and technology of mimicry security defense. The mimicry distributed file system architecture based on the DHR mechanism judges and tracks unknown threats through a reliable access control mechanism, a dynamic defense transformation mechanism, a heterogeneous redundancy mechanism and a block chain log mechanism, blocks and disturbs various attack means, and finally achieves the aim of effectively reducing the security risk of the system.
Meanwhile, logging is an indispensable function for a complete storage system. With the development of big data, the background architecture of the internet system becomes complex, and it is difficult for system managers to directly query log information at a certain node, so that a special log management system needs to be designed to help system managers to efficiently monitor the running condition of the system and timely find and process abnormal conditions. In addition, with the development of data mining and machine learning technologies, internet enterprises have become popular for recommending commodities by accessing log information and analyzing user behaviors through users, so that log data is regarded as important. Currently, log data is generally divided into a user access log, an application log, and a system log. The user access log records the login and exit activities of the user, and the log is used for tracking the behavior analysis of the user and is often used for user data mining. The system log records the starting, closing or fault information of the system and is of great importance to the running state and safety of the system. However, the traditional logging system does not consider the security, and the log information is easy to be tampered, so that the security of the mimicry storage system can be better improved by designing a safe and reliable logging system.
Chukwa is an open-source data collection system for monitoring a large-scale distributed system developed by Apache, is constructed on HDFS and Map/Reduce frameworks, and inherits excellent expansibility and robustness of Hadoop. In terms of data analysis, chukwa has a flexible and powerful tool set that can be used to monitor and analyze results to better utilize the collected data results. The structure is shown in fig. 1.
The main components are:
agents: is responsible for collecting the most original data and sending the data to the Collectors
Adaptors: an interface and a tool for directly collecting data, one Agent can manage the data collection of a plurality of adaptors
Collectors: is responsible for collecting the data received and sent by the Agent and writing the data into the cluster at regular time
map/Reduce Jobs: timed starting, which is responsible for classifying, sorting, de-duplicating and merging data in the cluster
HICC (Hadoop InfrastranstructeCare Center): responsible for the display of data
At the production end of each Data (basically at each node in the cluster), chukwa uses an Agent to collect the Data of interest, each type of Data is realized by an adapter, and the type (Data Model) of the Data is specified in the corresponding configuration. In order to prevent the Agent at the data acquisition end from being out of order, the Agent at Ahukwa adopts a so-called 'watchdog' mechanism, and can automatically restart the terminated data acquisition process to prevent the loss of original data.
On the other hand, for repeatedly collected data, they are automatically deduplicated during Chukwa's data processing. Therefore, the same Agent can be deployed on a plurality of machines for key data, and the fault-tolerant function is realized.
The data collected by Agents is stored on the Hadoop cluster. For the reason that the Hadoop cluster is good at processing a small number of large files, but the processing of a large number of small files is not a strong item of the Hadoop cluster, chukwa designs a Collector role, which is used for partially merging data and then writing the data into the cluster, so that the writing of a large number of small files is prevented.
On the other hand, in order to prevent a Collector from becoming a performance bottleneck or generating a single point of failure, chukwa allows and encourages to set a plurality of Collectors, agents randomly select one Collector from a list of Collectors to transmit data, and if one Collector fails or is busy, the next Collector is replaced, so that load balancing can be achieved. Practice has shown that the load of multiple collectors is almost even.
The log acquisition system has the defects that no safety mechanism exists, only one read-write access port exists, and log data are easily tampered when the system is attacked maliciously.
Afka is a messaging system originally developed from LinkedIn and used as the basis for LinkedIn's active Stream (Activity Stream) and operational data processing Pipeline (Pipeline). It is now used by many different types of companies as various types of data pipes and messaging systems. The architecture is shown in fig. 2.
1.Broker: the Kafka cluster contains one or more servers, which are called brookers.
2.Topic: each message issued to the Kafka cluster has a category, which is called Topic. (messages of physically different topocs are stored separately, and logically a topoc's message, although stored on one or more brokers, needs only to specify the message's topoc for the user to produce or consume data without concern as to where the data is stored).
3, partition: partition is a physical concept, each Topic containing one or more partitions.
4, producer: responsible for issuing messages to Kafka broker.
5.Consumer: and the message consumer reads the client of the message to the Kafka browser.
Consumer Group: each Consumer belongs to a particular Consumer Group (each Consumer may be assigned a Group name, or a default Group if a Group name is not assigned).
A typical Kafka cluster includes several producers (which may be Web View generated by a Web front end, or server logs, system CPUs, memories, etc.), several brokers (Kafka supports horizontal extensions, generally the greater the number of brokers, the higher the cluster throughput), several Consumer groups, and a Zookeper cluster. Kafka manages cluster configuration through Zookeeper, elects leader, and rebalance when Consumer Group changes. The Producer publishes the message to the brooker using the push mode, and the Consumer subscribes and consumes the message from the brooker using the pull mode.
The message system is used as a log system, no redundancy is introduced, if some nodes fail, logs are lost, meanwhile, the system is configured by relying on zookeeper, the consistency also relies on zookeeper, and if the zookeeper nodes are attacked maliciously, the system is written into error logs or the logs are tampered.
Disclosure of Invention
The invention aims to provide a method for storing a tamper-proof log in a pseudo-mode by fusing a block chain technology, and aims to solve the technical problem that data is easily lost or tampered due to the fact that a storage node for storing the log is in fault or is attacked maliciously.
The invention is realized in such a way, and provides a method for storing an anti-tampering log by fusing block chain technology mimicry, which comprises the following steps:
s1, collecting logs of all isomers in a mimicry storage system and converting the logs into logs in a standard format;
s2, sending the converted standard log to a block chain network node, and packaging the log into a transaction by the block chain network node;
s3, sending the transaction to a manager node, and storing the log into a pre-block by the manager node;
s4, the manager node sends the pre-blocks to a committee node, and the committee node verifies the pre-blocks and sends signatures to the manager node;
s5, the manager node judges whether the collected committee signatures exceed half, if so, the manager node issues formal blocks to all nodes and executes the next step, and if not, the manager node gives up issuing and returns to the step S4;
and S6, each node synchronizes the received new block to the block chain.
The further technical scheme of the invention is as follows: the method for storing the anti-tampering log by simulating the fusion blockchain technology further comprises the following steps:
and S7, inquiring, self-checking and repairing the logs stored in the block chain network.
The invention further adopts the technical scheme that: in the step S1, log collection comprises two message queues of UDP and TCP, and UDP or TCP is selected for transmission according to the size of log data.
The further technical scheme of the invention is as follows: the log query is divided into a fast query and a secure query, and the fast query comprises the following steps:
s711, sending a query request through a query unit;
s712, the quick query database feeds back a query result to the query unit;
s713, verifying the consistency of the log and the hash in the query result in the block chain, if so, executing the next step, otherwise, returning to the step S712 and feeding back error information to the query manager;
and S714, converting the inquired standard log into a log of a specific type and feeding back the log to an administrator.
The invention further adopts the technical scheme that: the secure query comprises the steps of:
s721, sending a query request to the quick query database through a query unit;
s722, rapidly querying the database, returning a query result, checking the consistency of the log and the hash in the query result, if so, executing the next step, if not, sending a log query request to any blockchain network node and jumping to S727;
s723, the query unit sends the log hash and the block number to any block chain network node as check information;
s724, the block chain network node receiving the information forwards the check information to all nodes in the block chain network;
s725, all block chain network nodes receiving the check request check whether the logs of the appointed hash exist in the block, if yes, the query unit is supposed to feed back the verification to pass, and if not, the query unit is fed back verification error information;
s726, if the query unit receives more than half of verification passing information of the blockchain network nodes within the effective time, the standard logs are converted into logs of a specified type and fed back to an administrator, and the query is finished, otherwise, a query request is sent to any blockchain node;
s727, forwarding the query request to the blockchain network by the blockchain network node receiving the query request, searching corresponding logs in a blockchain database of all the nodes receiving the query request, and returning the logs to the query unit;
and S728, if the query unit receives the same logs of which the number is more than half of that of the nodes in the effective time, converting the logs and feeding the logs back to an administrator, otherwise, feeding the logs back to the administrator that the query fails.
The further technical scheme of the invention is as follows: the self-checking and repairing comprises the following steps:
s731, the node performing self-checking sends a created block request to the block chain network;
s732, feeding back the created blocks to the database node by the block chain network node receiving the request;
s733, if the self-checking node receives the same blocks of which the number is more than half of that of the node in the valid time, comparing whether the blocks are the same as the blocks in the database of the self-checking node, if not, replacing the created blocks in the database with correct created blocks, and then checking whether each block in the block chain is correct through a hash value from the created blocks;
s734, if there is an incorrect block in the checking process, continuing to check the block after synchronizing the block in the block chain network until the checking is completed, and if the node is also a node in the fast query database, updating the content in the database in the self-checking synchronization process.
Another object of the present invention is to provide a system for fusing blockchain technology mimicry to store tamper-resistant logs, which comprises
The acquisition and conversion module is used for acquiring logs of all isomers in the mimicry storage system and converting the logs into logs in a standard format;
the encapsulation module is used for sending the converted standard log to the block chain network node, and the block chain network node encapsulates the log into a transaction;
the storage module is used for sending the transaction to the manager node, and the manager node stores the log into the pre-block;
the node verification and signature sending module is used for the housekeeper node to send the pre-block to the committee node, and the committee node verifies the pre-block and sends the signature to the housekeeper node;
the judging module is used for judging whether the collected committee signatures exceed half number or not by the manager node, if so, the manager node issues the formal blocks to all the nodes and executes the next step, and if not, the manager node gives up issuing and returns to the node verification and signature sending module;
and the storage module is used for synchronizing the received new blocks into the block chain by each node.
The further technical scheme of the invention is as follows: the system for pseudo-storing the tamper-resistant log by the fusion block chain technology further comprises
And the query and self-check and repair module is used for querying, self-checking and repairing the log stored in the block chain network.
The further technical scheme of the invention is as follows: the log collection in the collection conversion module comprises two message queues of UDP and TCP, and UDP or TCP is selected to be transmitted according to the size of log data.
The further technical scheme of the invention is as follows: the log query is divided into a fast query and a safety query, wherein the fast query comprises the following steps:
a quick request sending unit for sending the query request through the query unit;
the quick feedback unit is used for quickly inquiring the database and feeding back an inquiry result to the inquiry unit;
the quick judgment unit is used for verifying the consistency of the log and the hash in the query result in the block chain, if so, executing the next step, and if not, returning to the quick feedback unit and feeding back error information to the query manager;
the quick conversion return unit is used for converting the inquired standard log into a log of a specific type and returning the log to an administrator;
the security query comprises:
the safety request unit is used for sending a query request to the quick query database through the query unit;
the safety judgment unit is used for quickly inquiring the database to return an inquiry result and verifying the consistency of the log and the hash in the inquiry result, if so, the safety verification unit is executed, and if not, the safety judgment unit sends a log inquiry request to any block chain network node and jumps to the safety block inquiry return unit;
the safety check unit is used for sending the log hash and the block number as check information to any block chain network node by the query unit;
the check information forwarding unit is used for forwarding the check information to all nodes in the block chain network by the block chain network node receiving the information;
the safety check return result unit is used for checking whether logs of the appointed hash exist in the block chain network nodes of all the received check requests, if yes, the inquiry unit is expected to feed back the verification to pass, and if not, the inquiry unit is fed back verification error information;
the safety conversion log unit is used for converting the standard log into a log of a specified type and feeding the log back to an administrator if the verification passing information of more than half of the blockchain network nodes is received by the query unit within the effective time, and finishing the query, otherwise, sending a query request to any blockchain node;
the safety block inquiry returning unit is used for forwarding the inquiry request to the block chain network by the block chain network node receiving the inquiry request, searching corresponding logs in a block chain database of the safety block network node receiving the inquiry request, and returning the logs to the inquiry unit;
the return manager unit is used for converting the logs and feeding the logs back to the manager if the query unit receives the same logs of which the number exceeds half of the number of the nodes in the effective time, or feeding the logs back to the manager if the query unit receives the same logs of which the number exceeds half of the number of the nodes in the effective time;
the self-checking and repairing comprises:
a created block sending unit, configured to send a created block request to the block chain network from the node performing the self-check;
the node returning unit is used for feeding back the created blocks to the database node by the block chain network node receiving the request;
the comparison unit is used for comparing whether the block is the same as the block in the database of the self-checking node if the self-checking node receives the same blocks of which the number is more than half of that of the nodes in the effective time, replacing the created block in the database with a correct created block if the same blocks are different, and then checking whether each block in the block chain is correct from the created block through a hash value;
and the updating unit is used for synchronizing a certain block in the block chain network and then continuing to check if the certain block is incorrect in the checking process until the checking is finished, and updating the content in the database in the self-checking synchronization process if the node is also a node in the quick query database.
The invention has the beneficial effects that: and the block chain is used as a log storage module of the mimicry storage system to protect the log generated by the mimicry storage system from being tampered. The block chain adopts a PoV consensus algorithm to ensure the consistency and the safety of the stored data. The communication complexity of the PoV block generation process is low, the performance is good, the expandability is strong, and the number of cluster nodes is convenient to increase or decrease. Two query modes are adopted, rapid query and safe query are provided, different query requirements are met, the rapid query directly interacts with a rapid query database, and the safe query needs to be completed by interacting with the block chain network and the rapid query database together. The nodes in the block chain network are periodically self-checked and repaired, the correctness of the created blocks is determined through majority voting, then each block is checked through the chain structure of the block chain, and the blocks with errors request the correct blocks from other nodes in the network to be repaired.
Drawings
FIG. 1 is a Chukwa basic architecture diagram.
Fig. 2 is a schematic view of Kafka basic architecture.
Fig. 3 is a block chain log system architecture according to an embodiment of the present invention.
Fig. 4 is a log collection process provided by an embodiment of the present invention.
Fig. 5 is a process of storing a log into a blockchain and quickly querying a database according to an embodiment of the present invention.
Fig. 6 is a process of operating the PoV algorithm according to an embodiment of the present invention.
Fig. 7 shows two different query modes provided by the embodiment of the present invention.
Detailed Description
The invention provides a method for storing a tamper-proof log by simulating a fusion block chain technology, which comprises the following detailed steps:
log module integral framework
Similar to the traditional log system, the log system mainly comprises three parts of log collection, log storage and log query. In order to increase the security of log storage, a blockchain network is used for log storage; in order to improve the query efficiency, a quick query database is added for providing a service for efficient query to the outside. The log collection unit is responsible for collecting log data of different modules, can filter invalid log data, carries out format conversion on the log, and then randomly selects a block chain network node to distribute the log data. In order to prevent the block chain nodes from processing too many requests at the same time, the log distribution can realize load balancing. The log query and analysis unit can query log records from the block chain, and supports two query operations of quick query and safe query. The specific architecture is shown in fig. 3.
Log collection unit
The logs may be sourced from a variety of sources, such as logs of each isoform in a mimicry storage system, logs of a configuration manager, etc., and the log formats generated by the various components may not be the same. The log collection unit collects logs generated by log generation sources, carries out format conversion on correct logs after incorrect logs are filtered, converts the logs into a standard format, and finally releases the logs to a block chain network for storage. The log collection can adopt an active collection mode or a passive receiving mode, the collection units can be arranged in a plurality of modes, and each log source can send the log to any collection unit. The acquisition unit randomly sends the log to a block chain network node, and stores the log in a block chain through a block generation process. As shown in fig. 4.
The log acquisition unit comprises two message queues of UDP and TCP, and UDP or TCP is selected for transmission according to the size of log data, so that the communication efficiency can be increased, and the network communication traffic can be reduced. Aiming at the problem that the blockchain network cannot ensure that all received data are stored in the blockchain, the acquisition unit is provided with a caching and retransmitting strategy. The acquisition unit registers a block subscription service with the block chain network when starting, and the block can be acquired when the block chain network generates a new block. When the logs are sent, the sent logs are cached at the same time, timeout time is set, and when the acquisition unit receives a newly issued block, the logs are extracted from the block, and the same logs in the cache are deleted. If logs which are not inquired after timeout exist in the cache, the logs are retransmitted to the block chain, and the timeout time is reset.
In order to facilitate subsequent query analysis, the standard format of the log includes information other than the log content itself, including the log type, the application or service generating the log, the node generating the log, and the like. The standard format is shown in the table below.
Table 1 log storage format
The hash of the log is the log hash in the converted standard format, so as to facilitate the subsequent query verification and the duplication check when generating the block. There is a one-to-one relationship between each log and the source of production. Meanwhile, the converted log content also contains information possibly generated by all types of logs, and the standard logs can be converted into the logs of the corresponding types in a lossless manner.
Log storage unit
The blockchain is essentially an incremental distributed storage system, only allows data to be added but not modified or deleted, and each node in the blockchain network has a copy of the same complete blockchain, so that the blockchain essentially backs up the data by introducing a redundancy policy. The block chain ensures the consistency of data of each node through a consistency protocol, the consistency protocol is also called a consensus algorithm, and the invention selects a voting-based algorithm PoV (Proof of Vote) as the consistency algorithm of the block chain network. The storage process is shown in fig. 5.
Three identity nodes, namely a manager candidate node, a manager node and a committee node, are specified in the PoV consistency protocol, and the three special nodes jointly implement the consistency protocol to generate qualified blocks. The blockchain network implementing the protocol behaves as a state machine determined by the blockchain information, with each newly generated block modifying the state of the overall system. The state information maintained by the PoV protocol includes information such as a committee list, a manager candidate list, a manager list, a next manager, a start time of next block generation, and the like.
In a block chain network using PoV, committee nodes are the highest power nodes, and are equal, and they decide on consensus transactions by means of mutual voting. The generation of the block is responsible for the manager node, the number of the manager nodes is fixed and is marked as N b The manager node is generated by voting of the committee nodes, but not all the nodes can be voted, the nodes which can be elected to become the manager node are called manager candidate nodes, and the manager candidate nodes can be applied by any non-manager candidate nodes and are added after the approval of the half committee nodes. In addition, the committee node with the highest decision right can be applied by other nodes and joined after all committees agree. The steward candidate node and the committee node can quit the identity at any time without the consent of the committee node. All the node identity change information is stored in the block in a special transaction mode, and when the node receives a newly issued block, various node lists maintained by the node change according to the special transaction information.
Applying for becoming a manager candidate flow:
1) And applying for acquiring recommendation information from any committee node.
2) A recommendation message is sent to the committee node, and more than half of the committee's consent replies and signatures are obtained.
3) Recommendation information and more than half of the committee signatures are sent as transactions to all of the steward nodes.
4) Waiting for the block containing the transaction to issue.
Application becomes a committee:
1) Requesting all committee nodes to obtain an agreement signature.
2) An application committee transaction containing all committee signatures is sent to all caretaker nodes.
3) Waiting for the block containing the transaction to issue.
Voting for the next caretaker:
1) And selecting a fixed number of voting list signatures from all manager candidates by the committee node according to the scores or the preference of the committee node, and then sending the voting list signatures to all manager nodes.
2) The manager on duty (manager responsible for generating blocks) node counts the votes after receiving votes of all committees, the manager with the highest votes is selected as the manager of the next owner, and the manager number is determined by the transaction in the first block. And finally, putting the ballot, the ballot result and the ballot signature into the transaction and putting the transaction into a pre-block. The preblock is finally sent to all committee request signatures.
3) The caretaker on duty issues the blocks into the blockchain network after receiving the semi-committee signature.
In the PoV block chain network, each managed home production pre-block has a fixed time limit, and once no legal block is issued after the time is exceeded, the manager with the manager number +1 takes the turn to serve as the managed home production pre-block on duty, and so on. In addition, the time for each housekeeper to act as a housekeeper is also limited, and after a certain number of blocks are generated by a group of housekeepers, the housekeeper candidates need to be voted again to elect a new housekeeper. The time limit for each block and the number of blocks required to be generated by each housekeeper are recorded in the first block. The housekeeping number responsible for creating the pre-block is determined by the committee signature of the last block. Since the committee signature is random, the housekeeping of the next packed block is also random. The specific flow is shown in fig. 6.
Each anycast produces B w After a normal block, a special block is generated, which only contains the next transaction chosen by any caretaker, but no other transaction. All functional transactions (including applying for committee transactions, quitting committee transactions, applying for housekeeping candidate transactions and quitting housekeeping candidate transactions) and common transactions are packaged by the common block. The common transaction is a user-defined transaction and can contain any content, so that the blockchain can be applied to multiple purposes.
The generation of the normal blocks and the generation of the special blocks are similar, and the generation of the special blocks is started when a manager node receives a newly issued block and updates the identity of the manager node to be an on-duty manager, and the node starts generating the pre-block after waiting for a delay time. The delay time is also recorded on the first block. Setting the block generation delay can effectively slow down the block generation speed, increase the transaction number of each block package, and setting an appropriate delay time can increase the throughput of the block chain network. The method comprises the steps that a manager on duty needs to obtain transactions in a transaction cache pool and store the transactions in a block, if a common block is generated, all transactions in a functional transaction cache pool and a certain amount of transactions in the common transaction cache pool are stored in the block, and if a special block is generated, only votes in a voting cache pool are counted and then are put into the block to generate an unsigned pre-block. The amount of common transactions placed per block is capped, which can be adjusted manually to suit the needs of the system, while other functional transactions are not necessarily limited in the number of places because they are not generated in large numbers. The manager node sends the blocks to all committees after generating the pre-blocks, and the committees sign the block headers after verifying the correctness of the block information and then return the signatures to the manager on duty. After more than one-half of the committee's signatures are acquired, the caretaker on duty puts the committee signatures in the block header and issues the block with the time of the last committee signature as the block's generation time.
In combination with the feature that the time division of the PoV blockchain network defines the generation time of each block and the housekeeping rotation time, the present invention sets the timeout retransmission time of the acquisition unit to the period of housekeeping rotation, because the transaction in the buffer will be flushed once during housekeeping rotation to fetch the data that has been linked up. If the period of the query transaction is set as the period generated by each block, the system can query the log in time when data is newly added in the block chain, and meanwhile, network congestion caused by frequent polling operation is avoided.
In terms of performance, the PoV realizes stronger fault-tolerant capability and higher throughput performance through partial decentralization, the communication complexity of a generated block is only O (3 m), m is the number of committee nodes, the expansion is stronger, the addition or the withdrawal of a common node to or from a block chain network is not limited, and the addition or the withdrawal of the committee nodes and the housekeeper candidate nodes can be recorded in the block chain as special transactions after certain steps.
When the nodes in the PoV blockchain network receive the transmitted log, the log is forwarded to all manager nodes, i.e., the accounting nodes. The housekeeping nodes are partial nodes in the network, the number of the housekeeping nodes is fixed, and the logs can be packed into blocks to the maximum extent while the communication burden is reduced.
The block chain network provides block subscription service externally, and when one node subscribes the service of the block chain, all nodes in the block chain network add the IP of the node into a subscription list. When a new block is published in the blockchain network, the node receiving the newly published block sends the block to all nodes subscribed to the service.
Since the data in the block chain is stored in the block, the query efficiency is low when the data volume is large. Therefore, the function of rapidly inquiring the log is realized by adding a rapid inquiry database to the log data in the storage block of the database. The fast query database node subscribes to block services from the block chain network, and when the node receives a newly published block, data is extracted from the block and stored in the fast query database. The logs in the quick query database are stored in the format of table 2 below:
table 2 log storage format
Node failures in distributed storage are difficult to avoid, and each node in the blockchain network needs periodic self-checking and synchronous repair in order to correct error data in time.
Log query unit
In the log query mode, the rapid query can be carried out by rapidly querying the database, and the safe query can also be carried out by the block chain network. The fast query database can provide efficient and fast query service, and the security of data acquisition can be ensured by querying through the blockchain network. Although each blockchain network node stores one copy of the complete blockchain, it is theoretically possible to provide data query services. However, the data of a single node is unreliable, and the correctness of the query result cannot be ensured by querying the data through the single node, so that the correctness of the final query result is ensured by a majority voting mode. The general and secure query processes are shown in fig. 7.
And (3) a common query process:
(1) The query unit sends a query request;
(2) Quickly querying the database and returning a query result;
(3) Checking the consistency of the log and the hash;
(4) Converting the standard log into a log of a specific type;
(5) The log is returned to the administrator.
A safety query process:
(1) The query unit sends a query request to a quick query database;
(2) Quickly querying the database and returning a query result;
(3) Checking the consistency of the log and the hash;
(4) Sending the hash and the block number as check information to any block chain network node;
(5) The node receiving the information forwards the check information to all nodes in the network;
(6) All nodes receiving the check information check whether the corresponding blocks have logs of the designated hash or not, and then return results to the query unit;
(7) If the confirmation information of more than half of the block chain network nodes is received within the overtime, the standard logs are converted into formulated type logs and returned to the administrator, and the query is finished. Otherwise, sending a query request to any block chain network node;
(8) The nodes receiving the query request forward the query request to the block chain network, all the nodes receiving the query request search corresponding logs in the block chain database of the nodes, and return the logs to the query unit;
(9) If the query unit receives the same log exceeding half of the number of the nodes before timeout, the log is converted and returned to the administrator. Otherwise, the query failure is returned to the administrator.
The method mainly comprises the steps that efficiency is considered more importantly in ordinary query, interaction is directly carried out with a quick query database, safety query is more emphasized on correctness of query results, the query process has two stages, firstly, logs are queried from the quick query database in the first stage, confirmation is carried out through a block chain network, if the results are incorrect, query requests are sent to each node in the block chain network, majority judgment is carried out on the query results, and safety query can ensure that correct results can be obtained as long as the number of invalid or malicious nodes does not exceed half of the number of the block chains. Because the logs stored in the database are standard logs which are formatted, the system needs to convert the standard logs into logs of a required type and return the logs to the querier after acquiring the logs.
Self-checking and repairing of log system
Node failures in distributed storage are difficult to avoid, and each node in the blockchain network needs periodic self-checking and synchronous repair in order to correct error data in time. We have designed and made periodically run in the blockchain network nodes the following synchronization algorithm:
(1) Sending a create block request to the block chain network;
(2) The node receiving the request returns a creating block to the database node;
(3) If the same blocks with the number more than half of the number of the nodes are received before overtime, comparing whether the blocks are the same as the blocks in the database, if not, replacing the created blocks in the database with correct created blocks, and then checking whether each block in the block chain is correct or not from the created blocks through a hash value;
(4) If any block is incorrect in the checking process, the checking is continued after the block is synchronized in the block chain network until the checking is finished. If the node is also a node in the fast query database, the content in the database needs to be updated in the self-checking synchronization process.
And the block chain is used as a log storage module of the mimicry storage system to protect the log generated by the mimicry storage system from being tampered. The block chain adopts a PoV consensus algorithm to ensure the consistency and the safety of the stored data. The communication complexity of the block generation process of the PoV is low, the performance is good, the expandability is strong, and the number of cluster nodes is convenient to increase or decrease.
Two query modes are adopted, fast query and safe query are provided, different query requirements are met, the fast query directly interacts with a fast query database, and the safe query needs to be completed by interacting with a block chain network and the fast query database together.
The nodes in the block chain network are periodically self-checked and repaired, the correctness of the created blocks is determined through majority voting, then each block is checked through the chain structure of the block chain, and the blocks with errors request the correct blocks from other nodes in the network to be repaired.
The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents and improvements made within the spirit and principle of the present invention are intended to be included within the scope of the present invention.
Claims (10)
1.A method for fusing a block chain technology mimicry to store a tamper-proof log is characterized by comprising the following steps:
s1, collecting logs of all isomers in a mimicry storage system and converting the logs into logs in a standard format;
s2, sending the converted standard log to a block chain network node, and packaging the log into a transaction by the block chain network node;
s3, the transaction is sent to a manager node, and the manager node stores the log into a pre-block;
s4, the housekeeper node sends the pre-block to a committee node, and the committee node verifies the pre-block and sends a signature to the housekeeper node;
s5, judging whether the collected committee signatures exceed half number by the manager node, if so, issuing a formal block to all nodes and executing the next step, and if not, giving up issuing and returning to the step S4;
and S6, each node synchronizes the received new block into the block chain.
2. The method for storing a tamper-resistant log according to claim 1, wherein the method for storing a tamper-resistant log according to a fused blockchain technology mimicry further comprises the following steps:
and S7, inquiring, self-checking and repairing the log stored in the block chain network.
3. The method for pseudo-storing the tamper-proof log according to the fused block chain technology as claimed in claim 2, wherein the log collection in step S1 includes two message queues of UDP and TCP, and UDP or TCP is selected for transmission according to the size of log data.
4. The method for pseudo-storing the tamper-proof log according to the fused blockchain technology of claim 3, wherein the log storage query is divided into a fast query and a secure query, and the fast query includes the following steps:
s711, sending a query request through a query unit;
s712, the quick query database feeds back a query result to the query unit;
s713, the query unit verifies the consistency of the log and the hash in the query result, if yes, the next step is executed, and if no, the step S712 is returned and the error information is fed back to the query manager;
and S714, converting the inquired standard log into a log of a specific type and feeding back the log to an administrator.
5. The method for mimicry storing a tamper-resistant log according to the fused blockchain technique of claim 4, wherein the security query comprises the steps of:
s721, sending a query request to the quick query database through a query unit;
s722, rapidly querying the database, returning a query result, checking the consistency of the log and the hash in the query result, if so, executing the next step, if not, sending a log query request to any blockchain network node and jumping to S727;
s723, the query unit sends the hash and the block number of the log as check information to any block chain network node;
s724, the block chain network node receiving the information forwards the check information to all nodes in the block chain network;
s725, all block chain network nodes receiving the check request check whether the logs of the appointed hash exist in the block, if yes, the block chain network nodes feed back verification passing to the query unit, and if not, verification error information is fed back to the query unit;
s726, if the query unit receives more than half of verification passing information of the blockchain network nodes within the effective time, the standard logs are converted into logs of a specified type and fed back to an administrator, and the query is finished, otherwise, a query request is sent to any blockchain node;
s727, forwarding the query request to the blockchain network by the blockchain network node receiving the query request, searching corresponding logs in a blockchain database of all the nodes receiving the query request, and returning the logs to the query unit;
and S728, if the query unit receives the same logs with the number more than half of the number of the nodes in the effective time, converting the logs and feeding the logs back to the administrator, otherwise, feeding the administrator that the query fails.
6. The method for mimicry storing a tamper-resistant log according to claim 5, wherein the self-checking and repairing comprises the following steps:
s731, sending a created block request to the block chain network by the node performing self-checking;
s732, feeding back the created blocks to the database node by the block chain network node receiving the request;
s733, if the self-checking node receives the same blocks of which the number is more than half of that of the node in the valid time, comparing whether the blocks are the same as the blocks in the database of the self-checking node, if not, replacing the created blocks in the database with correct created blocks, and then checking whether each block in the block chain is correct through a hash value from the created blocks;
s734, if there is an incorrect block in the checking process, continuing to check the block after synchronizing the block in the block chain network until the checking is completed, and if the node is also a node in the fast query database, updating the content in the database in the self-checking synchronization process.
7. The system for fusing the block chain technology mimicry storage anti-tampering log is characterized by comprising
The acquisition and conversion module is used for acquiring logs of all isomers in the mimicry storage system and converting the logs into logs in a standard format;
the encapsulation module is used for sending the converted standard log to the block chain network node, and the block chain network node encapsulates the log into a transaction;
the storage module is used for sending the transaction to the manager node, and the manager node stores the log into the pre-block;
the node verification and signature sending module is used for the housekeeper node to send the pre-block to the committee node, and the committee node verifies the pre-block and sends the signature to the housekeeper node;
the judging module is used for judging whether the collected committee signatures exceed half number or not by the manager node, if so, the manager node issues the formal blocks to all the nodes and executes the next step, and if not, the manager node gives up issuing and returns to the node verification and signature sending module;
and the storage module is used for synchronizing the received new blocks into the block chain by each block chain network node.
8. The system of claim 7, wherein the system for fusing blockchain technology mimicry storing a tamper-resistant log further comprises
And the query and self-check and repair module is used for querying, self-checking and repairing the log stored in the block chain network.
9. The system for mimicry storage of a tamper-resistant log according to claim 8, wherein the log collection in the collection and conversion module comprises two message queues of UDP and TCP, and UDP or TCP is selected for transmission according to the size of log data.
10. The system for pseudo-storing the tamper-proof log according to the fused blockchain technology of claim 9, wherein the log storage query is divided into a fast query and a secure query, and the fast query includes:
a quick request sending unit, for sending the query request through the query unit;
the quick feedback unit is used for quickly inquiring the database and feeding back an inquiry result to the inquiry unit;
the quick judgment unit is used for verifying the consistency of the log and the hash in the query result in the block chain, if so, executing the next step, and if not, returning to the quick feedback unit and feeding back error information to the query manager;
the quick conversion return unit is used for converting the inquired standard log into a log of a specific type and returning the log to an administrator;
the security query comprises:
the safety request unit is used for sending a query request to the quick query database through the query unit;
the safety judgment unit is used for quickly inquiring the database to return an inquiry result and verifying the consistency of the log and the hash in the inquiry result, if so, the safety verification unit is executed, and if not, the safety judgment unit sends a log inquiry request to any block chain network node and jumps to the safety block inquiry return unit;
the safety check unit is used for sending the hash and the block number of the log as check information to any block chain network node by the query unit;
the check information forwarding unit is used for forwarding the check information to all nodes in the block chain network by the block chain network node receiving the information;
the safety check return result unit is used for checking whether logs of the appointed hash exist in the block chain network nodes of all the received check requests, if yes, the inquiry unit is expected to feed back the verification to pass, and if not, the inquiry unit is fed back verification error information;
the safety conversion log unit is used for converting the standard log into a log of a specified type and feeding the log back to an administrator if the verification passing information of more than half of the blockchain network nodes is received by the query unit within the effective time, and finishing the query, otherwise, sending a query request to any blockchain node;
the safety block inquiry returning unit is used for forwarding the inquiry request to the block chain network by the block chain network node receiving the inquiry request, searching corresponding logs in a block chain database of the safety block network node receiving the inquiry request, and returning the logs to the inquiry unit;
the return manager unit is used for converting the logs and feeding the logs back to the manager if the query unit receives the same logs of which the number is more than half of that of the nodes in the effective time, or feeding the logs back to the manager to cause the query to fail;
the self-checking and repairing comprises the following steps:
a created block sending unit, configured to send a created block request to the block chain network from the node performing the self-check;
a node returning unit, configured to receive the requested block chain network node and feed back the created block to the database node;
the comparison unit is used for comparing whether the block is the same as the block in the database of the self-checking node if the self-checking node receives the same blocks of which the number is more than half of that of the nodes in the effective time, replacing the created block in the database with a correct created block if the created block is not the same, and then checking whether each block in the block chain is correct or not from the created block through a hash value;
and the updating unit is used for synchronizing a certain block in the block chain network and then continuing to check if the certain block is incorrect in the checking process until the checking is finished, and updating the content in the database in the self-checking synchronization process if the node is also a node in the quick query database.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/CN2018/109007 WO2020062211A1 (en) | 2018-09-30 | 2018-09-30 | Method and system for mimicry storage tamper-proof log fused with blockchain technology |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112313916A CN112313916A (en) | 2021-02-02 |
| CN112313916B true CN112313916B (en) | 2023-01-17 |
Family
ID=69952739
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201880093162.0A Active CN112313916B (en) | 2018-09-30 | 2018-09-30 | Method and system for pseudo-storage of anti-tampering logs by fusing block chain technology |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN112313916B (en) |
| WO (1) | WO2020062211A1 (en) |
Families Citing this family (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111414431A (en) * | 2020-04-28 | 2020-07-14 | 武汉烽火技术服务有限公司 | Network operation and maintenance data disaster recovery backup management method and system based on block chain technology |
| CN111414433A (en) * | 2020-05-09 | 2020-07-14 | 北京阳光欣晴健康科技有限责任公司 | Distributed follow-up system based on block chain and ciphertext retrieval technology |
| CN111597168A (en) * | 2020-05-20 | 2020-08-28 | 北京邮电大学 | Block chain capacity recovery scheme based on integrity value |
| CN111813070B (en) * | 2020-09-11 | 2020-12-15 | 之江实验室 | Data grading synchronization method between master control units of mimicry industrial controller |
| CN112214800A (en) * | 2020-09-17 | 2021-01-12 | 新华三信息安全技术有限公司 | Log data sorting evidence-storing method, system, equipment and medium based on block chain |
| CN112383407B (en) * | 2020-09-22 | 2023-05-12 | 法信公证云（厦门）科技有限公司 | Block chain-based online notarization full-flow log processing method and system |
| CN112347491B (en) * | 2020-09-24 | 2023-06-27 | 上海对外经贸大学 | Endogenous data security interaction method for double-middle-platform double-chain architecture |
| CN112448946B (en) * | 2020-11-09 | 2024-03-19 | 北京工业大学 | Log auditing method and device based on block chain |
| CN112256808B (en) * | 2020-11-13 | 2023-09-12 | 泰康保险集团股份有限公司 | Data processing method, device and storage medium |
| CN112883106B (en) * | 2020-12-31 | 2024-02-13 | 北京百度网讯科技有限公司 | Block-out node determining method, device, equipment and medium of block chain |
| CN112948898A (en) * | 2021-03-31 | 2021-06-11 | 北京众享比特科技有限公司 | Method for preventing application data from being tampered in block chain and security module |
| CN113051616B (en) * | 2021-04-09 | 2023-12-19 | 新疆量子通信技术有限公司 | Method and system for improving safety of block chain |
| CN113259552A (en) * | 2021-04-19 | 2021-08-13 | 北京麦哲科技有限公司 | Anti-peeping privacy-protecting shooting device and method |
| CN113409141A (en) * | 2021-05-27 | 2021-09-17 | 航天信息江苏有限公司 | Grain storage full-flow traceable supervision method based on block chain technology |
| CN113269557B (en) * | 2021-05-31 | 2024-06-21 | 中国银行股份有限公司 | Transaction log acquisition system and working method thereof |
| CN113792290B (en) * | 2021-06-02 | 2024-02-02 | 国网河南省电力公司信息通信公司 | Judgment method and dispatch system for mimicry defense |
| CN113535493B (en) * | 2021-07-23 | 2023-08-25 | 北京天融信网络安全技术有限公司 | Method, device, medium and equipment for judging and testing mimicry Web server |
| CN113973008B (en) * | 2021-09-28 | 2023-06-02 | 佳源科技股份有限公司 | Detection system, method, equipment and medium based on mimicry technology and machine learning |
| CN113901142B (en) * | 2021-10-13 | 2024-05-07 | 辽宁大学 | Space-time data-oriented block chain architecture and range query processing method |
| CN114301624A (en) * | 2021-11-24 | 2022-04-08 | 天链(宁夏)数据科技有限公司 | Block chain-based tamper-proof system applied to financial business |
| CN114595205A (en) * | 2021-11-29 | 2022-06-07 | 国网辽宁省电力有限公司大连供电公司 | Block chain-based power system log partition storage and retrieval verification method |
| CN114756901B (en) * | 2022-04-11 | 2022-12-13 | 敏于行(北京)科技有限公司 | Operational risk monitoring method and device |
| CN114915657B (en) * | 2022-04-24 | 2024-01-26 | 中国人民解放军战略支援部队信息工程大学 | Mimicry application distributed tracking method based on OpenTraing specification |
| CN116015978B (en) * | 2023-02-13 | 2023-12-05 | 中国南方电网有限责任公司 | Heterogeneous redundant flow detection system based on mimicry safety technology |
| CN116028990B (en) * | 2023-03-30 | 2023-07-18 | 中国科学技术大学 | Anti-tampering privacy protection log auditing method based on blockchain |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105404701A (en) * | 2015-12-31 | 2016-03-16 | 浙江图讯科技股份有限公司 | Peer-to-peer network-based heterogeneous database synchronization method |
| CN110287259A (en) * | 2019-06-27 | 2019-09-27 | 浪潮卓数大数据产业发展有限公司 | A kind of audit log tamper resistant method based on block chain |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20170264428A1 (en) * | 2016-03-08 | 2017-09-14 | Manifold Technology, Inc. | Data storage system with blockchain technology |
| US20180157700A1 (en) * | 2016-12-06 | 2018-06-07 | International Business Machines Corporation | Storing and verifying event logs in a blockchain |
| CN107239953B (en) * | 2017-06-20 | 2021-10-29 | 无锡井通网络科技有限公司 | Block chain-based rapid data storage method and system |
| CN107835080B (en) * | 2017-11-09 | 2021-01-05 | 成都国盛天丰网络科技有限公司 | Distributed system data collection method and data signature generation method |
| CN108494581B (en) * | 2018-02-09 | 2020-12-29 | 孔泽一 | Controller distributed log generation method and device of SDN (software defined network) |
| CN108306893B (en) * | 2018-03-05 | 2021-08-03 | 北京大学深圳研究生院 | Distributed intrusion detection method and system for ad hoc network |
-
2018
- 2018-09-30 WO PCT/CN2018/109007 patent/WO2020062211A1/en active Application Filing
- 2018-09-30 CN CN201880093162.0A patent/CN112313916B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105404701A (en) * | 2015-12-31 | 2016-03-16 | 浙江图讯科技股份有限公司 | Peer-to-peer network-based heterogeneous database synchronization method |
| CN110287259A (en) * | 2019-06-27 | 2019-09-27 | 浪潮卓数大数据产业发展有限公司 | A kind of audit log tamper resistant method based on block chain |
Non-Patent Citations (2)
| Title |
|---|
| Jiaxing Li 等.Blockchain-Based Security Architecture for Distributed Cloud Storage.《 2017 IEEE International Symposium on Parallel and Distributed Processing with Applications and 2017 IEEE International Conference on Ubiquitous Computing and Communications (ISPA/IUCC)》.2018,第408-411页. * |
| 李彬 等.基于异构区块链的多能系统交易体系及关键技术.《电力系统自动化》.2018,第42卷(第4期),说明书第183-193段. * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112313916A (en) | 2021-02-02 |
| WO2020062211A1 (en) | 2020-04-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112313916B (en) | Method and system for pseudo-storage of anti-tampering logs by fusing block chain technology | |
| CN105959151B (en) | A kind of Stream Processing system and method for High Availabitity | |
| US8719232B2 (en) | Systems and methods for data integrity checking | |
| CN109815373B (en) | Data storage control method and device, server and readable storage medium | |
| Xiao et al. | Accountable MapReduce in cloud computing | |
| CN101997823A (en) | Distributed file system and data access method thereof | |
| Riesen et al. | Alleviating scalability issues of checkpointing protocols | |
| JP2012150805A (en) | Systems and methods for detecting fraud associated with systems application processing | |
| Hu et al. | MNOS: a mimic network operating system for software defined networks | |
| CN110071873A (en) | A kind of method, apparatus and relevant device sending data | |
| WO2022142781A1 (en) | Asynchronous bookkeeping method and apparatus for blockchain, medium, and electronic device | |
| Liskov et al. | Tolerating Byzantine faulty clients in a quorum system | |
| CN102902615A (en) | Failure alarm method and system for Lustre parallel file system | |
| CN111899019A (en) | Method and system for cross validation and sharing of blacklist and multiple parties | |
| EP2696297B1 (en) | System and method for generating information file based on parallel processing | |
| Essid et al. | Combining intrusion detection datasets using MapReduce | |
| Demirbaga et al. | Autodiagn: An automated real-time diagnosis framework for big data systems | |
| CN111343212B (en) | Message processing method, device, equipment and storage medium | |
| CN103268567B (en) | The efficient mass incident detecting of Facing to Manufacturing trade management system and processing method | |
| CN116841980A (en) | Bank data processing system | |
| CN111130882A (en) | Monitoring system and method of network equipment | |
| CN112860807B (en) | Fault-tolerant consensus method suitable for wireless block chain network | |
| US20230009460A1 (en) | Trail recording system and data verification method | |
| US11016807B2 (en) | Intermediary system for data streams | |
| US20230089235A1 (en) | Transaction processing method and apparatus, medium, and electronic device |
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 |