Event processing method, electronic device, and storage medium

Abstract

This application discloses an event processing method applied to a first blockchain node, comprising: determining a first storage location for event information; determining a second storage location for processing result information obtained from processing the event; and broadcasting storage address information to the blockchain network according to the first and second storage locations, wherein the storage address information, after verification based on a consensus mechanism, corresponds to storing the first and second storage locations in the same block of the blockchain. In this way, storing event information and processing result information together in a single block improves the storage correlation between event information and processing result information, thereby improving the efficiency of traceability and querying.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to an event processing method, an electronic device, and a storage medium. Background Technology

[0002] In related technologies, different consensus mechanisms are often required for different business processes based on blockchain to suit different business needs. Currently, related technologies based on the consortium blockchain framework Fabric use the Kafka consensus mechanism, which often involves input consensus and output consensus. For example, in transaction processing, input consensus is used to reach a consensus on the transactions, packaging a batch of transaction information into blocks for batch processing. Output consensus often uses each storage unit in the database storing multiple transaction-related data as leaf nodes, calculating the Merkle root hash value. However, this method prevents the input and output information of transactions from being stored together, greatly weakening the correlation between input and output information. When tracing and querying the content of a transaction, a large amount of computation is required, resulting in low efficiency. Moreover, if the content of any storage unit changes, the Merkle root hash value needs to be recalculated, bringing significant computational overhead to blockchain maintenance. Summary of the Invention

[0003] In view of this, the present invention provides an event processing method, an electronic device, and a storage medium.

[0004] The technical solution of this invention is implemented as follows:

[0005] In a first aspect, embodiments of the present invention provide an event processing method applied to a first blockchain node, the method comprising:

[0006] Determine the first storage location for the event information;

[0007] Determine a second storage location for the processing result information obtained from processing the event;

[0008] Based on the first storage location and the second storage location, storage address information is broadcast to the blockchain network, wherein the storage address information, after being verified by a consensus mechanism, corresponds to storing the first storage location and the second storage location in the same block of the blockchain.

[0009] Furthermore, the first storage location for the event information of the determined event includes:

[0010] The client obtains the processing result information obtained from processing the event forwarded by the client; the client is used to store the processing result information into the message queue where the event information corresponding to the processing result information is located;

[0011] Based on the processing result information, query the event information of the corresponding event;

[0012] Determine the first storage location of the event information in the message queue; the message queue is used to record the event processing order.

[0013] The determination of the second storage location for the processing result information obtained from processing the event includes:

[0014] Determine the second storage location of the processing result information in the message queue.

[0015] Further, broadcasting storage address information to the blockchain network based on the first storage location and the second storage location includes:

[0016] The first storage location and the second storage location are stored in the same block of the blockchain, and the storage address information corresponding to the block is determined;

[0017] The storage address information is broadcast to the blockchain network.

[0018] Furthermore, storing the first storage location and the second storage location in the same block of the blockchain includes:

[0019] The event information and the processing result information are packaged and stored in the database, and the corresponding third storage location is determined;

[0020] The first storage location, the second storage location, and the third storage location are stored in the same block of the blockchain.

[0021] Furthermore, storing the first storage location, the second storage location, and the third storage location in the same block of the blockchain includes:

[0022] The first storage location, the second storage location, and the third storage location are stored in the block body of the same block in the blockchain;

[0023] Obtain the event identifier data from the event information; the event identifier data includes at least: event type and / or event information hash value;

[0024] The event identifier data is stored in the block header corresponding to the block body.

[0025] Secondly, embodiments of the present invention provide an event processing method applied to a second blockchain node, the method comprising:

[0026] The event is processed based on event information;

[0027] Send the processing result information obtained from processing the event;

[0028] Obtain storage address information; the storage address information corresponds to the event information and the processing result information being recorded in the same block of the blockchain;

[0029] The blockchain is updated based on the storage address information.

[0030] Furthermore, the method also includes:

[0031] Store the event information in a message queue;

[0032] The process result information obtained from processing the event is sent, including:

[0033] The system sends the processing result information obtained from processing the event to the client; the client is used to store the processing result information into the message queue where the event information corresponding to the processing result information is located.

[0034] Furthermore, the method also includes:

[0035] Acquire the processing data generated during event handling; the processing data includes at least one of the following: event type, event information hash value, and event processing log;

[0036] Based on the processed data, determine the processing result information obtained from processing the event.

[0037] Furthermore, the event-based event information processing includes:

[0038] Based on the event information, determine the event type of the event;

[0039] If the event type is storage type, then the event information will be stored in the Object Storage Service module OSS;

[0040] The acquisition of processing data generated during event handling includes:

[0041] If the event type is storage type, then the processing data returned by OSS is obtained; the processing data also includes: storage file name and / or storage location index.

[0042] Furthermore, the client is also used to send the processing result information to the first blockchain node;

[0043] The process of obtaining storage address information includes:

[0044] Obtain the storage address information generated in the first blockchain node.

[0045] Thirdly, embodiments of the present invention provide an electronic device, the electronic device comprising: a processor and a memory for storing a computer program capable of running on the processor;

[0046] When the processor runs the computer program, it performs the steps of the method described in one or more of the foregoing technical solutions.

[0047] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer-executable instructions; after being executed by a processor, the computer-executable instructions can implement the methods described in one or more of the foregoing technical solutions.

[0048] The event processing method provided in this embodiment of the invention is applied to a first blockchain node, comprising: determining a first storage location for event information; determining a second storage location for processing result information obtained from processing the event; and broadcasting storage address information to the blockchain network according to the first and second storage locations, wherein the storage address information, after verification based on a consensus mechanism, corresponds to storing the first and second storage locations in the same block of the blockchain. In this way, recording the event information and processing result information together in the same block in the form of storage locations greatly improves the storage correlation between the event information and the processing result information, and is more conducive to improving the efficiency of event tracing and querying. Furthermore, recording events in the block by the storage location of the stored information, compared to storing the event information and processing result information themselves in the block, can greatly reduce the amount of data stored in the block, alleviating the storage and maintenance pressure on the blockchain. Attached Figure Description

[0049] Figure 1 A flowchart illustrating the event handling method provided in an embodiment of the present invention;

[0050] Figure 2 A flowchart illustrating the event handling method provided in an embodiment of the present invention;

[0051] Figure 3 A flowchart illustrating the event handling method provided in an embodiment of the present invention;

[0052] Figure 4 A flowchart illustrating the event handling method provided in an embodiment of the present invention;

[0053] Figure 5 A flowchart illustrating the event handling method provided in an embodiment of the present invention;

[0054] Figure 6 A flowchart illustrating the event handling method provided in an embodiment of the present invention;

[0055] Figure 7 A flowchart illustrating the event handling method provided in an embodiment of the present invention;

[0056] Figure 8 A flowchart illustrating the event handling method provided in an embodiment of the present invention;

[0057] Figure 9 A flowchart illustrating the event handling method provided in an embodiment of the present invention;

[0058] Figure 10 A flowchart illustrating the event handling method provided in an embodiment of the present invention;

[0059] Figure 11 The blockchain cloud storage consensus system architecture and flowchart provided in this embodiment of the invention;

[0060] Figure 12 This is a schematic diagram of the block structure provided in an embodiment of the present invention. Detailed Implementation

[0061] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on the present invention. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0062] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0063] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of the invention described herein can be implemented in an order other than that illustrated or described herein.

[0064] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein is for the purpose of describing embodiments of the invention only and is not intended to limit the invention.

[0065] like Figure 1 As shown, this embodiment of the invention provides an event processing method applied to a first blockchain node, the method comprising:

[0066] S110: Determine the first storage location for the event information;

[0067] S120: Determine the second storage location of the processing result information obtained from processing the event;

[0068] S130: Based on the first storage location and the second storage location, broadcast storage address information to the blockchain network, wherein the storage address information, after being verified by a consensus mechanism, corresponds to storing the first storage location and the second storage location in the same block of the blockchain.

[0069] In this embodiment of the invention, the event processing method can be applied to a blockchain-based business processing system, such as a data cloud storage and settlement business system. The first blockchain node can be a node in the blockchain used for consensus verification, such as a sorting node in the consortium blockchain framework Fabric.

[0070] Events can be pending transactions or other business processes, such as data storage transactions, settlement transactions, or transfer transactions in a data cloud storage and settlement business system. Event information can be raw information representing the content and requirements of the pending event. For example, when the event is a storage transaction, the event information can be transaction information including the data to be stored and the information of the transaction initiator.

[0071] Accordingly, the event processing result information can be information that characterizes the event processing status and result. For example, when the event is a transaction, the processing result information can be a transaction receipt, which can include the content generated during the transaction processing, such as the hash value of the transaction information, the address information of the transaction initiator and the transaction recipient, and the transaction logs generated during the transaction processing.

[0072] In one embodiment, determining the first and second storage locations can be achieved by querying the corresponding event based on event information and / or processing result information, thereby retrieving the first storage location storing the event information and the second storage location storing the processing result information. Here, the first storage location can be the location storing the event information or the location indicating the event processing order. For example, before event processing, if the event information is stored in a message queue in the business system to sequentially store received processing requests and prevent loss, then the first storage location can be the location of the event information in the message queue. Here, the message queue can be a message queue based on the Kafka consensus mechanism. Correspondingly, the second storage location can be the location storing the processing result information, or it can be the location of the processing result information in the message queue after it has been stored there.

[0073] In another embodiment, the first storage location and the second storage location corresponding to an event are stored in the same block information of the same block in the blockchain. The storage address information can be the address information corresponding to the block, which is used to represent the storage address of the event information (input) and the processing result information (output) of an event.

[0074] In one embodiment, event information and processing result information may not be stored in the block. Instead, events are recorded in the block through a first storage location and a second storage location. This eliminates the need to store all event information and processing result information in the block, significantly reducing the amount of data stored and thus alleviating the storage and maintenance burden on the blockchain. Furthermore, since consensus is no longer based on storage units in the database storing event and processing result information, but rather on verification based on the first and second storage locations, the computational overhead caused by re-hash calculations for every change in the content of a single storage unit, as seen in existing technologies, can be mitigated.

[0075] In another embodiment, a block is used to record only one event; that is, a block contains only information and data related to one event. For example, a block does not contain data related to the first and second storage locations of other events. This greatly improves the storage independence between different events. When tracing and querying events, there is no need to perform hash operations with other event information within the block, significantly reducing the computational overhead of event queries and further improving the efficiency of event queries. Simultaneously, since the storage location information is stored on the blockchain only after the event has been processed and the processing result information is obtained, the concurrency of business processing is reduced, alleviating the pressure on real-time processing, ensuring high system availability, and making it better suited for low-real-time, asynchronous business processing systems, such as the aforementioned data cloud storage and settlement business system.

[0076] By storing event information and processing result information together in the same block, the correlation between input and output information storage is greatly improved, and tight coupling between event input and output information is achieved. Thus, when it is necessary to trace and query the event later, the storage address of event information and time processing result information can be retrieved at the same time. Event information and processing result information can be obtained quickly and efficiently at the same time, improving the efficiency of event tracing.

[0077] In some embodiments, such as Figure 2 As shown, S110 includes:

[0078] S111: Obtain the processing result information obtained by the client forwarding the processing of the event; the client is used to store the processing result information into the message queue where the event information corresponding to the processing result information is located;

[0079] S112: Based on the processing result information, query the event information of the corresponding event;

[0080] S113: Determine the first storage location of the event information in the message queue; the message queue is used to record the event processing order.

[0081] S120 may include: S121: determining the second storage location of the processing result information in the message queue.

[0082] In this embodiment of the invention, the client can be a business platform, such as a cloud storage business platform in a cloud storage settlement business system. The client can initiate request information; for example, it can send a business processing request to a business processing node based on user instructions. The business processing node then processes the corresponding event information and obtains the processing result information. The client is also used to obtain the event processing result information and search for the corresponding event information based on the processing result information. For example, when the event is a transaction, the client can search for the corresponding event information in the transaction pool based on data such as the event identifier contained in the processing result information. Furthermore, the event information can be stored in a message queue by the business processing node.

[0083] In one embodiment, the processing result information is stored by the client in the message queue containing the corresponding event information after the client finds the event information. In this way, both the event information and the processing result information of the same event are stored in the same message queue, which makes it easier to record the entire processing process of an event in one message queue, so that relevant information can be found more quickly when verifying the authenticity of the event.

[0084] In another embodiment, S112 may include: obtaining the hash value of the event contained in the processing result information, for example, when the event is a transaction, obtaining the transaction hash value of this transaction contained in the processing result information, i.e., the transaction receipt; querying the corresponding event based on the event hash value, for example, performing a hash operation on the hash value to determine the corresponding event; determining the corresponding event information based on the queried event, for example, when the event is a transaction, matching and searching for the corresponding transaction information in a transaction pool containing transaction information of different transactions.

[0085] In one embodiment, a blockchain may contain one or more first blockchain nodes. When multiple first blockchain nodes exist, they retrieve event information and processing result information storage locations within the same group of the message queue, preventing multiple first blockchain nodes from repeatedly generating blocks for the same event. Multiple first blockchain nodes can generate and publish blocks sequentially according to the order in which the retrieved event information is in the message queue.

[0086] In another embodiment, after determining the first storage location of event information in the message queue, the first blockchain node can retrieve the corresponding processing result information in the message queue to determine the second storage location of the processing result information in the message queue. Thus, if an event is processed by multiple second blockchain nodes, since the processing result information generated by different second blockchain nodes is stored in different message queues, this avoids the first blockchain node determining the first storage location and then retrieving the second storage location from other message queues, which could lead to errors in the generated block and storage address information.

[0087] In another embodiment, if an event is processed separately by multiple second blockchain nodes—for example, a storage transaction processed separately by three endorsing nodes—the processing results will differ because the three endorsing nodes perform different processing actions, i.e., different storage paths and other information. Therefore, by storing a pair of event information and processing result information in each of the three message queues, the first blockchain node can retrieve the processing result information from each of the three message queues based on the event information and store these three pairs of event information and processing result information in the same block.

[0088] Thus, by generating blocks for recording events based on the respective positions of event information and processing result information in the message queue, not only can the storage correlation of event input and output information be improved and the huge storage volume caused by storing event information and processing result information in blocks be suppressed, but the blocks can also point to the positions of event information and processing result information in the message queue during the event processing. When event verification is required, the event input and output information in the message queue can be quickly located to determine whether the event processing process has occurred, thus improving the efficiency of event authenticity verification. On this basis, the tight coupling of event input and output information further improves the traceability of the event processing process.

[0089] In some embodiments, such as Figure 3 As shown, S130 includes:

[0090] S131: Store the first storage location and the second storage location in the same block of the blockchain, and determine the storage address information corresponding to the block;

[0091] S132: Broadcast the storage address information to the blockchain network.

[0092] In this embodiment of the invention, the first storage location and the second storage location are stored together in the same block, and the address of this block is determined as storage address information. Storing the first and second storage locations in a block allows for the generation of a block based on the first and corresponding second storage locations, used to record events corresponding to the first and second storage locations.

[0093] In one embodiment, broadcasting storage address information to the blockchain network can be done by broadcasting block address information, or it can also include sending the block address information to the publishing node in the blockchain, so that the publishing node can broadcast the storage address information so that other nodes such as clients and second blockchain nodes can obtain the block, complete the data on-chain, and synchronize the data between the nodes.

[0094] In some embodiments, such as Figure 4 As shown, S131 includes:

[0095] S1311: Package the event information and the processing result information into a database and determine the corresponding third storage location;

[0096] S1312: Store the first storage location, the second storage location, and the third storage location in the same block of the blockchain.

[0097] In this embodiment of the invention, in addition to storing the position information of the event information and the processing result information in the message queue, the block also stores the storage location of the event information and the processing result information in the database. For example, the event information and the processing result information are packaged into a set of data, and this set of data is stored in a key-value (KV) database, and its third storage location in the database is determined. Here, the third storage location can be a location index or an address pointer, etc.

[0098] In one embodiment, if an event is processed separately by multiple second blockchain nodes, the block stores three sets of event information and processing result information. Therefore, the three sets of event information and processing result information are jointly stored in the KV database to determine the third storage location.

[0099] In this way, a block contains the storage locations of the event information and processing result information of an event in the database, as well as their respective positions in the message queue. This allows for quick confirmation of the event's existence and authenticity based on its position in the message queue during event tracing and querying. Then, the event information and processing result information can be directly retrieved from the database based on the third storage location. Based on this, while ensuring the efficiency of event verification and tracing queries, it is possible to eliminate the need to store the event information and processing result information themselves in the block, significantly reducing the amount of data stored in the block and alleviating the storage and maintenance pressure on the blockchain.

[0100] In some embodiments, such as Figure 5 As shown, S1312 includes:

[0101] S1312a: Store the first storage location, the second storage location, and the third storage location in the block body of the same block in the blockchain;

[0102] S1312b: Obtain event identifier data from the event information; the event identifier data includes at least: event type and / or event information hash value;

[0103] S1312c: Store the event identifier data in the block header corresponding to the block body.

[0104] In this embodiment of the invention, a block consists of a block body and a block header. Here, S1312a can be either packaging the first storage location, the second storage location, and the third storage location into a block body, or storing the first storage location, the second storage location, and the third storage location within a block body. Similarly, S1312c can be generating a block header based on event identifier data. Thus, concatenating the block body and the block header constructs a block for recording the event.

[0105] In one embodiment, the event identifier data in the event information is data that can uniquely identify the event. For example, it can be account information of the current business processing system, event type, event information hash value, etc. The event information hash value can be a hash value obtained by hashing the file or data to be processed in the event. For example, when the event is a storage transaction, the hash value is obtained by hashing the file to be stored.

[0106] Understandably, the block header can also store the hash value of the current block, as well as the hash value of the previous block in the blockchain, in order to build a traceable block relationship in the blockchain.

[0107] In this way, the data containing the unique identifier of the input event information is stored in the block used to record the event. When a user needs to query and trace the event, the block recording the event can be quickly located in the blockchain based on data such as account information, event type, and hash value. Based on this, the existence and authenticity of the event are quickly verified by combining the first and second storage locations within the block. Furthermore, after the authenticity verification is passed, the corresponding event information and processing result information can be directly obtained based on the third storage location.

[0108] In this way, based on the key field settings in the block header, the position information of the input and output information in the block body in the message queue, and the storage location information in the database, a retrieval chain is formed, comprehensively optimizing the user's event tracing and querying process. This significantly improves the efficiency of event tracing legitimacy verification and related information retrieval while reducing the amount of blockchain data stored. Furthermore, since a block only stores information related to one event, verifying and querying that event does not require hashing with other event information that constitutes the Merkle tree, as is required by related technologies. Based on the independence of event-related information storage, the computational load required during event verification and tracing is greatly reduced.

[0109] like Figure 6 As shown, this embodiment of the invention provides an event processing method applied to a second blockchain node, the method comprising:

[0110] S210: Process the event based on the event information;

[0111] S220: Send the processing result information obtained from processing the event;

[0112] S230: Obtain storage address information; the storage address information corresponds to the event information and the processing result information being recorded in the same block of the blockchain;

[0113] S240: Update the blockchain based on the storage address information.

[0114] In this embodiment of the invention, the second blockchain node can be a node used for business processing, such as an endorsement node in the Fabric blockchain. The second blockchain node can obtain request messages sent by the client, which may carry data corresponding to the event to be processed. Based on the request message, the event information of the event to be processed can be determined.

[0115] In one embodiment, a client can simultaneously send a request message about an event to multiple second blockchain nodes, for example, to three endorsing nodes. Each of the three endorsing nodes processes the event and sends its processing result information back to the client. The client, upon receiving the processing result information from the three endorsing nodes, packages and signs the three processing result messages and sends them to the first blockchain node. Here, the first blockchain node also verifies the signature of the processing result information, stores the processing result information and the corresponding event information in the same block, and returns the storage address information corresponding to the block. The second blockchain nodes can then perform inter-node data synchronization based on the storage address information of this block.

[0116] In this way, the second blockchain node can complete event processing before the first blockchain node begins block generation and data uploading, significantly reducing the concurrency requirements for event processing in the business system and improving system stability. Furthermore, the received blocks store event information and processing results, greatly enhancing the storage correlation between event input and output information, thereby improving the efficiency of event tracing and querying.

[0117] In some embodiments, such as Figure 7 As shown, the method further includes:

[0118] S201: Store the event information in the message queue.

[0119] S220 may include: S221: sending processing result information obtained from processing the event to the client; the client is used to store the processing result information into the message queue where the event information corresponding to the processing result information is located.

[0120] In this embodiment of the invention, after the second blockchain node determines the event information of the event to be processed, it stores the event information in a message queue to record the time sequence in which the current event begins processing.

[0121] In one embodiment, after determining the processing result information, the second blockchain node signs the processing result information and sends it to the client. The client is also used to verify the signature of the processing result information. If the verification is successful, the client stores the processing result information in the message queue containing the corresponding event information to record the time sequence of the current event processing completion.

[0122] In another embodiment, if the client sends the request message for the event to multiple second blockchain nodes—for example, for a single transaction, the request message is sent to three endorsing nodes—the three endorsing nodes will insert the transaction information into different message queues to avoid confusion when the client stores the processing result information, i.e., the transaction receipt. Based on this, after confirming that it has received transaction receipts from all the endorsing nodes processing the transaction, the client stores the transaction receipt in the message queue corresponding to the transaction information of the originating endorsing node.

[0123] Here, the client stores the transaction receipt into the corresponding message queue. It can retrieve the transaction information corresponding to the transaction receipt and query the message queue corresponding to the transaction information. Alternatively, it can retrieve the corresponding transaction information and determine the node identity information of the endorsing node from which the transaction receipt comes, and determine the message queue where the corresponding transaction information is located based on the node identity information.

[0124] In this way, the processing results of events processed in the second blockchain node can be accurately stored in the message queue where the corresponding event information in that node is located, avoiding confusion during message insertion. Furthermore, it can make the paired event inputs and outputs stored in the block clearer, easier to query and trace.

[0125] In some embodiments, such as Figure 8 As shown, the method further includes:

[0126] S202: Obtain the processing data generated during the event processing; the processing data includes at least one of the following: event type, event information hash value, and event processing log;

[0127] S203: Based on the processed data, determine the processing result information obtained from processing the event.

[0128] In this embodiment of the invention, the second blockchain node generates processing result information representing the event processing status based on relevant data generated during the event processing. For example, when the event is a transaction, the processing result information, i.e., the transaction receipt, may include processing data such as: transaction type, transaction information hash value, address information of the transaction initiator and receiver, transaction contract storage address, transaction amount, transaction log, etc.

[0129] In this way, the processing result information can completely and clearly record the operational data generated during the event processing. When users trace and query events, they can clearly understand the event processing status based on the processing result information.

[0130] In some embodiments, such as Figure 9 As shown, S210 includes:

[0131] S211: Determine the event type of the event based on the event information;

[0132] S212: If the event type is a storage type, then the event information is stored in the Object Storage Service module OSS.

[0133] S202 may include: S2021: If the event type is storage type, then obtain the processing data returned by the OSS; the processing data may also include: storage file name and / or storage location index.

[0134] In this embodiment of the invention, the event processing procedures differ for different events. S211 may include: obtaining the event type recorded in the event information of the event. When the event type is storage type, for example, a storage transaction in a cloud storage settlement business system, the endorsing node can call the Object Storage Service (OSS) module to process the transaction, for example, uploading the file to be stored to OSS.

[0135] Accordingly, after storing the file to be stored in the preset area, OSS returns detailed storage data to the endorsement node, which may include, for example, the storage file name and / or storage location index, as well as the OSS server domain name. Optionally, if OSS uses fragmented storage to store the file, the returned processing data also includes fragment information, such as the start and end times of each fragment in the original video after the video file is fragmented.

[0136] In one embodiment, if a client sends an event request message to multiple second blockchain nodes—for example, for a storage transaction processed separately by three endorsing nodes—then each endorsing node uploads the file to be stored to OSS. OSS stores the three files in three different storage areas and returns the corresponding processing data to each of the three endorsing nodes. Therefore, since the file storage locations for different endorsing nodes are different, the received processing data will differ, resulting in different processing outcomes.

[0137] Accordingly, after confirming that it has received the processing result information from the three endorsing nodes, the client can determine that the OSS storage path corresponding to one of the processing result information is the primary path, and the other two are backup paths. Further, the client packages the three processing result information and sends it to the first blockchain node. In this way, backup storage of the file to be stored can be achieved.

[0138] In another embodiment, if the event type is determined to be other types, such as settlement transactions, transfer transactions, etc., the event is processed based on the event information. This can be done by querying the data usage or balance of the corresponding account and calling the chaincode to perform settlement or transfer processing.

[0139] Accordingly, if a transaction is processed separately by three endorsing nodes, when the transaction is a settlement transaction, transfer transaction, or other type, the client, after confirming receipt of transaction receipts from the three endorsing nodes, verifies the signatures of the three transaction receipts and compares their contents. Since settlement or transfer transactions have identical content, they do not have different storage location information as storage transactions. Therefore, the client also compares the contents of the transaction receipts sent by multiple endorsing nodes. After confirming that everything is correct, the client packages the multiple transaction receipts and sends them to the first blockchain node for block generation.

[0140] In some embodiments, the client is further configured to send the processing result information to the first blockchain node;

[0141] The process of obtaining storage address information includes:

[0142] Obtain the storage address information generated in the first blockchain node.

[0143] Here, the first blockchain node is the node in the blockchain used to generate blocks, such as the sorting node in the Fabric blockchain, which is used to record the processing result information and the corresponding event information in the same block. For example, the event information and the storage location of the processing result information in the message queue are stored in the same block.

[0144] This invention also provides an event processing device applied to a first blockchain node, comprising:

[0145] The first determining unit is used to determine the first storage location of the event information and the second storage location of the processing result information obtained from processing the event.

[0146] A broadcasting unit is used to broadcast storage address information to the blockchain network based on the first storage location and the second storage location, wherein the storage address information, after being verified by a consensus mechanism, corresponds to storing the first storage location and the second storage location in the same block of the blockchain.

[0147] This invention also provides an event processing device applied to a second blockchain node, comprising:

[0148] A processing unit is used to process the event based on the event information.

[0149] The sending unit is used to send the processing result information obtained from processing the event;

[0150] An acquisition unit is used to acquire storage address information; the storage address information corresponds to the event information and the processing result information being recorded in the same block of the blockchain;

[0151] An update unit is used to update the blockchain based on the storage address information.

[0152] In some embodiments, the apparatus further includes:

[0153] A storage unit is used to store the event information into a message queue.

[0154] In some embodiments, the acquisition unit is further configured to:

[0155] Acquire the processing data generated during event handling; the processing data includes at least one of the following: event type, event information hash value, and event processing log;

[0156] The device further includes:

[0157] The second determining unit is used to determine the processing result information obtained from processing the event based on the processing data.

[0158] The following provides a specific example in conjunction with any of the above embodiments:

[0159] In related technologies, Fabric employs a Kafka consensus mechanism that decouples input and output. Clients submit transactions to multiple endorser peers (EPs), receive a certain number of responses, and then submit them to the order peer (OP). After verification and ordering, the transactions are submitted to both the EP and the committer peer (CP). It's clear that Fabric's input consensus is completed at the OP, but the OP doesn't handle any output transaction data after business processing. Fabric's output consensus uses logically ordered buckets composed of key-value databases as leaf nodes of a Merkle tree, calculating the root value from the bottom up using hash operations. This separate input and output consensus significantly weakens the correlation between input and output data. In reality, cloud storage settlement services are more concerned with the size of the stored data space, start time, and other output results, making the execution of input consensus less meaningful. Furthermore, Fabric sets the number of transactions to be sorted and packaged in a batch or uses a timer in the OP. Since Kafka excels at handling small-volume transactions, an inappropriate transaction quantity setting can lead to performance degradation. This invention addresses cloud storage and settlement service systems by utilizing the working principle of Kafka to provide a tightly coupled input-output consensus mechanism based on Fabric. It records the location information of inputs and outputs on the blockchain to reduce the amount of data uploaded, and sets key data fields on the blockchain according to business needs to improve the system's data query efficiency.

[0160] like Figure 10 As shown, this embodiment of the invention provides a consensus mechanism and workflow for a Fabric-based blockchain cloud storage settlement system.

[0161] 1. The client (CLI) initiates a transaction request. Transaction request types include storage, settlement, and transfer. Different types of transaction requests contain corresponding data. The client here is not the user's client, but the cloud storage service platform. The transaction will first be sent to three endorsement nodes: Endorsement Node 1 (EP1), Endorsement Node 2 (EP2), and Endorsement Node 3 (EP3).

[0162] 2. The endorsing node inserts the original transaction into the Kafka message queue. Business systems typically set up such Kafka message queues to form a Kafka cluster (KFs) to sequentially store incoming request information to prevent loss.

[0163] 3. The endorsing node is actually the business server. First, the endorsing node verifies the transaction signature. After verification, it parses the transaction and performs relevant business processing based on the transaction data. For storage-related transactions, before uploading the original user data to OSS, audio and video processing such as transcoding and compression may be performed as needed by the business. For settlement or transfer-related transactions, based on the transaction request, it queries the data usage or balance of an account and calls the chaincode to execute settlement or transfer operations.

[0164] 4. For storage transactions, the endorsing nodes use the OSS Software Development Kit (SDK) to upload the data (either full file upload or fragmented file upload). Here, we see a situation where three endorsing nodes upload the same data. The actual cloud storage system also backs up the same data. The three endorsing nodes store the data in different OSS regions. OSS compresses the backup data to achieve backup.

[0165] 5. After storage is complete, OSS returns detailed data about the storage transaction to the endorsing nodes. OSS uses the bucket name (BucketKey) and object name (ObjectKey) as the data path. Other data, such as metadata identifiers (metaID), message-digest algorithm (md5), and the domain name of the OSS server where the data is stored, will also be returned. If it is sharded storage, the returned data should also include the start and end timestamps of the shards in the original video.

[0166] 6. The endorsing node assembles the received execution completion data into a receipt, adds its signature, and sends it to the client. Key data fields in the receipt include transaction type, transaction hash, initiator address, recipient address, contract address, amount, and transaction log. Storage-type receipts may also include, but are not limited to, metaID, MD5 hash, filename or file fragment name, BucketKey, ObjectKey, file size, fragment index, and start and end times (if fragmented upload is used).

[0167] 7. The client performs signature verification on the received receipts, compares the results of each endorsement node, and checks whether enough receipts have been collected from endorsement nodes.

[0168] 8. The client will receive receipts from multiple endorsing nodes. For settlement and transfer receipts, the client needs to verify the signature and confirm its accuracy. For storage receipts, the client needs to determine one of the three paths where the data is stored on OSS as the primary path, and the other two as backup data paths. Afterward, the client reassembles the receipt, adds its signature, and sends it to the sorting node.

[0169] 9. The sorting node retrieves the corresponding transaction from the transaction pool based on the transaction hash in the receipt, packages the transaction and receipt into a block body, constructs the block header, and finally assembles a block containing only the input and output of that transaction. The sorting node can operate in single-node or multi-node mode. A single-node sorting node performs block construction, sorting, and block generation. This is relatively simple but has limited processing capacity and is generally not used in production environments. In a multi-node scenario, each sorting node retrieves messages from the same group in Kafka, avoiding duplicate packaging of the same transaction-receipt. Multiple nodes publish blocks to the publishing node in chronological order and synchronize them to the endorsing nodes and clients. This ultimately completes the data upload to the blockchain and data synchronization between different nodes.

[0170] In addition, such as Figure 11 The diagram shows the architecture and process of a blockchain cloud storage consensus system based on Fabric.

[0171] Therefore, compared with the prior art, the embodiments of the present invention provide the following solution:

[0172] 1. Traditional Fabric Kafka consensus uses a decoupled input-output consensus method. Input consensus is achieved at the sorting nodes; output consensus uses each unit of the key-value database as leaf nodes, employing hash operations to obtain the Merkle root hash value. Its drawback is that any change in the content of any unit requires recalculating the Merkle root hash value, resulting in significant computational overhead. Cloud Kafka consensus, on the other hand, uses a tightly coupled input-output consensus method. The sorting nodes map input transactions to output receipts one-to-one, thus achieving input-output binding. Because the blockchain only records actual transactions and results, and no longer uses data from key-value database units as the basis for output, it significantly reduces computational overhead. (The key-value database is used to record and store all information about cloud Kafka user accounts, but it no longer participates in output consensus.)

[0173] 2. In traditional Fabric Kafka consensus, ordering nodes package a batch of transactions into a block. This approach is primarily suited for high-concurrency scenarios. If many transactions are received per second, it's time-efficient for ordering nodes and clients to sign and verify a batch of transactions. Furthermore, ordering nodes are not concerned with the results of business processing. Therefore, traditional Fabric Kafka consensus is more suitable for input-output decoupling scenarios. However, in cloud storage services, upon receiving a request, the business system processes and uploads data, and different transactions require different execution times. First, the business itself needs to provide a precise processing response for each transaction. Second, the tightly coupled input-output approach reduces message concurrency. Third, storage operations have low real-time and asynchronous characteristics, so ordering nodes and clients only need to complete signing and verification sequentially, reducing the pressure on real-time processing and ensuring high system availability. Therefore, we adopt a method of packaging a complete input-output block for consensus on-chain. Moreover, this method improves the efficiency of verifying and querying a transaction; that is, when querying a transaction, it is not necessary to perform hash operations with other transactions to obtain its hash value.

[0174] 3. This embodiment of the invention provides special processing for blocks uploaded to the Kafka consensus chain. In processes 2 and 8 above, both the input transactions and the output receipts are inserted into the Kafka message queue. It is important to note that the three endorsing nodes insert the transactions they each receive into three different groups or topics. After all transaction tasks are completed, the client inserts the output receipt for each transaction into the Kafka queue corresponding to the input transaction. For example... Figure 12 As shown, the content within the block is redefined. The sorting node can retrieve the output receipts corresponding to the input transactions from three Kafka instances. The three pairs of transactions (Trade) and receipts (Receipt) are located in the Kafka message queues at positions Tx1 kfk, Rt1 kfk; Tx2 kfk, Rt2 kfk; and Tx3 kfk, Rt3 kfk, respectively. Since these messages have definite positions in Kafka based on topic, partition, and bias, we record the position information of these transactions and receipts in the block body, rather than recording all the data in the entire transaction and receipt. The detailed data in the transactions and receipts will actually be stored in a database. We also package the location of the detailed data in the database (Database Addr) into the block body. Using this format as the block body greatly reduces the amount of data in the block body, which in turn reduces the amount of data in the blockchain. When a transaction needs to be queried, as long as it is verified, the required data, such as storage path and data volume, can be quickly located and obtained based on the location information of the transaction and receipt in Kafka.

[0175] This invention also provides an electronic device, which includes a processor and a memory for storing a computer program that can run on the processor. When the processor runs the computer program, it performs the steps of the methods described in one or more of the foregoing technical solutions.

[0176] This invention also provides a computer-readable storage medium storing computer-executable instructions. When executed by a processor, the computer-executable instructions can implement the methods described in one or more of the foregoing technical solutions.

[0177] The computer storage medium provided in this embodiment may be a non-instantaneous storage medium.

[0178] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0179] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0180] In addition, in the various embodiments of the present invention, each functional unit can be integrated into one processing module, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0181] In some cases, where any two of the above technical features do not conflict, they can be combined to form a new method or technical solution.

[0182] In some cases, where any one or two of the above technical features do not conflict, they can be combined to form a new equipment technical solution.

[0183] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0184] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. An event processing method, characterized by, Applied to the first blockchain node, the method includes: Determine the first storage location for the event information; the first storage location is either the location where the event information is stored or the location indicating the event information in the event processing order. Determine a second storage location for the processing result information obtained from processing the event; the second storage location is the location where the processing result information is stored. Based on the first storage location and the second storage location, storage address information is broadcast to the blockchain network, wherein the storage address information, after being verified by a consensus mechanism, corresponds to storing the first storage location and the second storage location in the same block of the blockchain.

2. The method of claim 1, wherein, The first storage location for the event information of the determined event includes: The client obtains the processing result information obtained from processing the event forwarded by the client; the client is used to store the processing result information into the message queue where the event information corresponding to the processing result information is located; Based on the processing result information, query the event information of the corresponding event; Determine the first storage location of the event information in the message queue; the message queue is used to record the event processing order. The determination of the second storage location for the processing result information obtained from processing the event includes: Determine the second storage location of the processing result information in the message queue.

3. The method of claim 2, wherein, The step of broadcasting storage address information to the blockchain network based on the first storage location and the second storage location includes: The first storage location and the second storage location are stored in the same block of the blockchain, and the storage address information corresponding to the block is determined; The storage address information is broadcast to the blockchain network.

4. The method according to claim 3, characterized in that, The step of storing the first storage location and the second storage location in the same block of the blockchain includes: The event information and the processing result information are packaged and stored in the database, and the corresponding third storage location is determined; The first storage location, the second storage location, and the third storage location are stored in the same block of the blockchain.

5. The method according to claim 4, characterized in that, The step of storing the first storage location, the second storage location, and the third storage location in the same block of the blockchain includes: The first storage location, the second storage location, and the third storage location are stored in the block body of the same block in the blockchain; Obtain the event identifier data from the event information; the event identifier data includes at least: event type and / or event information hash value; The event identifier data is stored in the block header corresponding to the block body.

6. An event handling method, characterized in that, Applied to a second blockchain node, the method includes: The event is processed based on event information; Send the processing result information obtained from processing the event; Obtain storage address information; the storage address information corresponds to the event information and the processing result information being recorded in the same block of the blockchain; the storage address information includes first storage location information and second storage location information; The first storage location information is either the location information for storing event information or the location information indicating the event information in the event processing order; The second storage location information is the location information for storing the processing result information; The blockchain is updated based on the first storage location information and the second storage location information.

7. The method according to claim 6, characterized in that, The method further includes: Store the event information in a message queue; The process result information obtained from processing the event is sent, including: The system sends the processing result information obtained from processing the event to the client; the client is used to store the processing result information into the message queue where the event information corresponding to the processing result information is located.

8. The method according to claim 6, characterized in that, The method further includes: Acquire the processing data generated during event handling; the processing data includes at least one of the following: event type, event information hash value, and event processing log; Based on the processed data, determine the processing result information obtained from processing the event.

9. The method according to claim 8, characterized in that, The event-based event information processing includes: Based on the event information, determine the event type of the event; If the event type is storage type, then the event information will be stored in the Object Storage Service module OSS; The acquisition of processing data generated during event handling includes: If the event type is storage type, then the processing data returned by OSS is obtained; the processing data also includes: storage file name and / or storage location index.

10. The method according to claim 7, characterized in that, The client is also used to send the processing result information to the first blockchain node; The process of obtaining storage address information includes: Obtain the storage address information generated in the first blockchain node.

11. An electronic device, characterized in that, The electronic device includes: a processor and a memory for storing computer programs capable of running on the processor; wherein, When the processor runs the computer program, it performs the steps of the event handling method according to any one of claims 1 to 10.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions; when executed by a processor, the computer-executable instructions can implement the event handling method as described in any one of claims 1 to 10.

Images