Data processing method, device and equipment based on block chain and readable storage medium

Abstract

The invention discloses a data processing method, device and equipment based on a block chain and a readable storage medium, and the method comprises the steps: obtaining a target contract event corresponding to a target contract from a target block when determining that the consensus of the target block is passed; obtaining a target contract subscription list corresponding to the target contract; the target contract subscription list comprises a client identifier corresponding to a client subscribing the target contract; if the target contract is an active contract and the target contract subscription list and the active client list contain the same client identifier, determining the same client identifier as a write diffusion client identifier; the active client list comprises client identifiers corresponding to the active clients; and synchronizing the target contract event to a client corresponding to the write diffusion client identifier in a write diffusion mode, and synchronizing the target contract event to a client corresponding to the read diffusion client identifier in a read diffusion mode. According to the invention, the waste of network resources can be reduced, and the performance of the block chain system is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data processing method, apparatus, device, and readable storage medium based on blockchain. Background Technology

[0002] Current blockchain systems support clients subscribing to all transactions from blockchain nodes. A common approach is to detect events based on contracts. Each client can subscribe to one or more contracts. When a target contract generates a new target contract event, the blockchain node pushes the target contract event to all clients that have subscribed to the target contract. This is a write-diffusion event synchronization method.

[0003] However, the write-diffusion event synchronization method can lead to wasted network resources and excessive load on blockchain nodes when faced with a large number of clients. This is because blockchain nodes need to push contract events indiscriminately to clients that have subscribed to the contract, but many clients do not actually need to obtain or process contract events in real time. Furthermore, for these clients that do not need to obtain or process contract events in real time, this indiscriminate push mechanism can also cause information overload and may lead to clients processing large amounts of unnecessary data, thereby degrading the performance of the entire blockchain system. Summary of the Invention

[0004] This application provides a data processing method, apparatus, device, and readable storage medium based on blockchain, which can reduce the waste of network resources and improve the performance of the blockchain system.

[0005] This application provides, in one aspect, a blockchain-based data processing method, executed by a blockchain node, comprising:

[0006] When consensus is reached on the target block, the target contract event corresponding to the target contract is retrieved from the target block.

[0007] Retrieve the target contract subscription list; the target contract subscription list contains the client identifiers corresponding to the clients that subscribed to the target contract;

[0008] If the target contract is an active contract, and the target contract's subscription list and active client list contain the same client identifier, then the same client identifier is identified as the write diffusion client identifier; the active client list contains the client identifiers corresponding to the active clients;

[0009] The target contract event is synchronized to the client corresponding to the write diffusion client identifier through write diffusion, and to the client corresponding to the read diffusion client identifier through read diffusion. The read diffusion client identifier refers to the client identifier in the target contract subscription list excluding the write diffusion client identifier.

[0010] One embodiment of this application provides a blockchain-based data processing device, which is operated by blockchain nodes, and the device includes:

[0011] The event acquisition module is used to acquire the target contract event corresponding to the target contract from the target block when it is determined that the target block consensus has been passed.

[0012] The list retrieval module is used to retrieve the target contract subscription list corresponding to the target contract; the target contract subscription list contains the client identifiers corresponding to the clients that subscribed to the target contract;

[0013] The identifier determination module is used to identify the same client identifier as the write diffusion client identifier if the target contract is an active contract and the target contract's subscription list and active client list contain the same client identifier; the active client list contains the client identifiers corresponding to the active clients.

[0014] The first synchronization module is used to synchronize the target contract event to the client corresponding to the write diffusion client identifier via write diffusion.

[0015] The second synchronization module is used to synchronize the target contract events to the client corresponding to the read diffusion client identifier via read diffusion; the read diffusion client identifier refers to the client identifier in the target contract subscription list excluding the write diffusion client identifier.

[0016] Specifically, the first synchronization module is used to send the target contract event to the client corresponding to the write diffusion client identifier, so that the client corresponding to the write diffusion client identifier writes the target contract event into the client event set.

[0017] The second synchronization module includes:

[0018] The event set writing unit is used to write the target contract events into the target contract event set associated with the target contract;

[0019] The pull and push unit is used to determine the contract events contained in the target contract event set as pullable contract events when it receives an event pull request for the target contract from the target client, and send the pullable contract events to the target client so that the target client writes the pullable contract events into the client event set; the target client belongs to the client corresponding to the read diffusion client identifier.

[0020] The aforementioned data processing device further includes:

[0021] The first determining module is used to determine the average number of block contract events for the target contract within the target time period; the end time of the target time period is the current system time; the average number of block contract events refers to the average number of contract events corresponding to the target contract contained in the block within the target time period;

[0022] The second determination module is used to determine the average number of subscribers to the target contract within the target time period;

[0023] The first weighted summation module is used to perform weighted summation on the average number of block contract events and the average number of subscribed clients to obtain the contract activity corresponding to the target contract;

[0024] The first active determination module is used to determine the target contract as an active contract if the contract activity level is greater than or equal to the contract activity level threshold.

[0025] The first determining module includes:

[0026] The first window acquisition unit is used to acquire the sliding window of the number of contract events corresponding to the target contract; the sliding window of the number of contract events contains the number of block contract events corresponding to M blocks respectively; M is a positive integer; the number of contract events in a block refers to the number of contract events corresponding to the target contract contained in a block; the writing window time of the number of contract events in M ​​blocks all belong to the target time period;

[0027] The first average calculation unit is used to perform average calculation on the number of block contract events corresponding to the target block and the number of M block contract events to obtain the average number of block contract events of the target contract within the target time period.

[0028] The aforementioned data processing device further includes:

[0029] The first window update module is used to add the number of block contract events corresponding to the target block to the contract event number sliding window to obtain a new contract event number sliding window.

[0030] The first window update module is also used to remove expired block contract event counts from the new contract event count sliding window when it detects that the new contract event count sliding window contains expired block contract event counts. The expired block contract event count refers to the number of block contract events in the new contract event count sliding window whose write window time does not belong to the new target time period. The end time point in the new target time period is the system time when the new contract event count sliding window is detected.

[0031] The second determining module includes:

[0032] The second window acquisition unit is used to acquire the sliding window of the number of subscribed clients corresponding to the target contract; the sliding window of the number of subscribed clients contains N subscription client counts; N is a positive integer; a subscription client count refers to the number of clients subscribed to the target contract when a subscription update request is successfully executed; the writing window time of the N subscription client counts all belong to the target time period;

[0033] The second average calculation unit is used to perform average calculation on the number of N subscription clients to obtain the average number of subscription clients for the target contract within the target time period.

[0034] The aforementioned data processing device further includes:

[0035] The second window update module is used to update the contract subscription list corresponding to the target contract according to the target subscription update request when a target subscription update request for the target contract is received, so as to obtain the updated contract subscription list.

[0036] The second window update module is also used to determine the number of client identifiers contained in the updated contract subscription list as the number of updated subscription clients, add the number of updated subscription clients to the subscription client number slider window, and obtain a new subscription client number slider window;

[0037] The second window update module is also used to delete expired subscription client counts from the new subscription client count sliding window when it is detected that the new subscription client count sliding window contains expired subscription client counts. The expired subscription client counts refer to the number of subscription clients in the new subscription client count sliding window whose writing window time does not belong to the new target time period. The end time point in the new target time period is the system time when the new subscription client count sliding window is detected.

[0038] The aforementioned data processing device further includes:

[0039] The threshold determination module is used to obtain information on occupied computing resources and total computing resources.

[0040] The threshold determination module is also used to determine the idle computing resources of the blockchain node based on the occupied computing resources information and the total computing resources information;

[0041] The threshold determination module is also used to adjust the default contract activity threshold based on the idle computing power resource information to obtain the contract activity threshold.

[0042] The aforementioned data processing device further includes:

[0043] The identifier acquisition module is used to obtain the identifiers of the L subscription clients respectively; L is a positive integer, and a subscription client refers to a client that subscribes to one or more contracts;

[0044] The third determining module is used to determine the average number of block client events for each of the L subscribing clients within the target time period; the end time of the target time period is the current system time; the average number of block client events refers to the average number of contract events corresponding to one subscribing client contained in a block within the target time period;

[0045] The fourth determination module is used to determine the average number of subscription contracts for each of the L subscription clients within the target time period;

[0046] The second weighted summation module is used to perform weighted summation on the average number of block client events and the average number of subscription contracts for each subscribing client to obtain the client activity level for each subscribing client.

[0047] The second active determination module is used to identify active clients among L subscribed clients whose client activity level is greater than the client activity threshold, and generate an active client list based on the client identifier corresponding to the active client.

[0048] The aforementioned data processing device further includes:

[0049] The third synchronization module is used to synchronize the target contract events to the clients corresponding to the client identifiers contained in the target contract subscription list by writing diffusion if the target contract is an inactive contract, or if the target contract subscription list and the active client list do not contain different client identifiers.

[0050] Among them, L subscription clients include the target subscription clients;

[0051] The third determining module includes:

[0052] The third window acquisition unit is used to acquire the sliding window of the number of client events corresponding to the target subscribed client; the sliding window of the number of client events contains the number of client events in P blocks; P is a positive integer; the number of client events in a block refers to the number of contract events corresponding to the target subscribed client contained in a block; the writing window time of the number of client events in P blocks all belong to the target time period;

[0053] The third average calculation unit is used to perform average calculation on the number of block client events corresponding to the target block and the number of P block client events to obtain the average number of block client events for the target subscription client within the target time period.

[0054] Among them, L subscription clients include the target subscription clients;

[0055] The fourth determining module includes:

[0056] The fourth window acquisition unit is used to acquire the sliding window of the number of subscription contracts corresponding to the target subscription client; the sliding window of the number of subscription contracts contains Q subscription contract counts; Q is a positive integer; a subscription contract count refers to the number of contracts subscribed by the target subscription client when a subscription update request is successfully executed; the writing window time of the Q subscription contract counts all belong to the target time period;

[0057] The fourth mean calculation unit is used to perform mean calculation on the number of Q subscription clients to obtain the average number of subscription contracts of the target subscription client within the target time period.

[0058] One embodiment of this application provides a computer device, including: a processor, a memory, and a network interface;

[0059] The processor is connected to the memory and the network interface. The network interface is used to provide a data communication network element, the memory is used to store a computer program, and the processor is used to call the computer program to execute the method in the embodiments of this application.

[0060] One aspect of this application provides a computer-readable storage medium storing a computer program adapted for loading by a processor and executing the methods described in this application.

[0061] One aspect of this application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method described in this application.

[0062] In this embodiment, when a blockchain node determines that the consensus of the target block has passed, it can obtain the target contract event corresponding to the target contract from the target block; then, it can obtain the target contract subscription list corresponding to the target contract; the target contract subscription list contains the client identifiers corresponding to the clients that subscribe to the target contract; if the target contract is an active contract, and the target contract subscription list and the active client list contain the same client identifier, then the same client identifier is identified as the write diffusion client identifier; finally, the target contract event is synchronized to the client corresponding to the write diffusion client identifier through write diffusion, and the target contract event is synchronized to the client corresponding to the read diffusion client identifier through read diffusion; wherein, the active client list contains the client identifiers corresponding to the active clients; the read diffusion client identifier refers to the client identifier in the target contract subscription list excluding the write diffusion client identifier. The method provided in this application embodiment can dynamically classify contracts into active or inactive contracts, and clients into active or inactive clients. For active clients subscribing to active contracts, a write diffusion method is used to synchronize target contract events, while for inactive clients subscribing to active contracts, a read diffusion method is used to synchronize target contract events. This reduces unnecessary waste of network resources and alleviates excessive load on blockchain nodes and information overload on inactive clients, thereby improving the performance of the blockchain system. Attached Figure Description

[0063] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0064] Figure 1 This is a schematic diagram of a network architecture provided in an embodiment of this application;

[0065] Figure 2 This is a schematic diagram illustrating a scenario of a blockchain-based data processing method provided in an embodiment of this application.

[0066] Figure 3 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application;

[0067] Figure 4 This is a flowchart illustrating a data processing method for determining active contracts provided in an embodiment of this application;

[0068] Figure 5 This is a flowchart illustrating a data processing method for generating an active client list provided in an embodiment of this application;

[0069] Figure 6 This is a schematic diagram of a scalable blockchain contract subscription scheme system architecture that combines read diffusion and write diffusion, as provided in an embodiment of this application.

[0070] Figure 7 This is a schematic diagram of a blockchain contract subscription process that combines read diffusion and write diffusion, provided in an embodiment of this application.

[0071] Figure 8 This is a schematic diagram of a process for determining and dynamically switching activity based on real-time event subscription volume, provided in an embodiment of this application.

[0072] Figure 9 This is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of this application;

[0073] Figure 10 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0074] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0075] To facilitate understanding, the following brief explanations are provided for some of the terms:

[0076] 1. Blockchain: In a narrow sense, blockchain is a chain-like data structure with blocks as the basic unit. The blocks use digital digests to verify the previously obtained transaction history, which is suitable for the needs of anti-tampering and scalability in distributed ledger scenarios. In a broad sense, blockchain also refers to the distributed ledger technology implemented by the blockchain structure, including distributed consensus, privacy and security protection, peer-to-peer communication technology, network protocols, smart contracts, etc.

[0077] The goal of blockchain is to create a distributed data ledger that allows only additions and not deletions. The underlying structure of the ledger is a linear linked list. This list consists of interconnected "blocks," with each subsequent block recording the hash value of its predecessor. The validity of each block (and the transactions within it) can be quickly verified by calculating the hash value. If a node in the network proposes adding a new block, the block must be confirmed through a consensus mechanism.

[0078] 2. Block: A block is a data packet carrying transaction data on a blockchain network. It is a data structure marked with a timestamp and the hash value of the previous block. A block is verified and confirmed by the network's consensus mechanism. A block consists of a block header and a block body. The block header records the metadata of the current block, including the current version number, the hash value of the previous block, a timestamp, a random number, and the hash value of the Merkle root. The block body records detailed data generated over a period of time, including all verified transactions and other information generated during the block creation process; it can be understood as a form of ledger representation. Furthermore, the detailed data in the block body may include a unique Merkle root recorded in the block header, generated through a Merkle tree hashing process.

[0079] The predecessor block, also known as the parent block, is the block in which the blockchain achieves temporal ordering by recording the hash value of the block and the hash value of the parent block in the block header.

[0080] 3. Hash Value: Also known as an information feature value or characteristic value, a hash value is generated by converting input data of arbitrary length into cryptographic data and producing a fixed output using a hash algorithm. The original input data cannot be retrieved by decrypting the hash value; it is a one-way cryptographic function. In a blockchain, each block (except the initial block) contains the hash values ​​of its predecessor blocks. The hash value is a core foundation and the most important aspect of blockchain technology, preserving the authenticity of recorded and viewed data, as well as the integrity of the blockchain as a whole.

[0081] 4. Smart Contracts: A smart contract is a computer protocol designed to disseminate, verify, or execute contracts in an informational manner. The concept of a smart contract possesses three key elements: commitment, agreement, and digital form. Therefore, it can extend the application scope of blockchain to all aspects of transactions, payments, settlements, and clearing in the financial industry. A smart contract means that when a pre-programmed condition is triggered, the corresponding contractual terms are executed immediately, and its working principle is similar to the if-then statement in a computer program. Smart contracts allow for trusted transactions without a third party; these transactions are traceable and irreversible.

[0082] 5. State Data: State data is the data structure used in a blockchain system to represent the current state of the system. State data includes the balances of all accounts, the state of smart contracts, and other relevant information. State data is continuously updated as transactions are executed, reflecting the global state of the blockchain system at a given point in time. In blockchain systems, state data is typically stored in the form of a Merkle tree or other cryptographic data structures to ensure its integrity and security.

[0083] 6. Transaction Pool: A transaction pool (also known as a mempool) is a data structure in a blockchain network used to store transactions that have not yet been packaged into blocks. When a user submits a new transaction to the blockchain network, the transaction first enters the transaction pool. When blockchain nodes are preparing to generate a new block, they select a certain number of transactions from the transaction pool to package. Transaction pools help improve the processing capacity of the blockchain network.

[0084] 7. Blockchain Contract Subscription: Blockchain contract subscription refers to the process by which clients (users or applications) in a blockchain network detect specific events or state changes of smart contracts. When a smart contract performs certain operations or meets specific conditions, it triggers an event. Clients that have subscribed to these events can passively receive notifications without constantly querying the contract state. This mechanism allows clients to respond promptly to changes in the contract state, enabling real-time detection and interaction of blockchain data.

[0085] 8. Read Diffusion: Read diffusion is a data synchronization strategy in which the client actively pulls (reads) information from the server or data source. In the context of blockchain contract subscriptions, read diffusion means that the client periodically checks for the existence of contract events instead of waiting for pushes from blockchain nodes. This strategy is suitable for scenarios that do not require real-time updates because it reduces unnecessary network traffic and the processing burden on nodes.

[0086] 9. Write Diffusion: Write diffusion is another data synchronization strategy in which the server or data source actively pushes (writes) information to the client. In the context of blockchain contract subscriptions, write diffusion means that when a contract event occurs, the blockchain node immediately notifies all subscribed clients of these events. This strategy is suitable for scenarios requiring real-time or near real-time notifications, ensuring that clients can quickly respond to changes in contract state.

[0087] 10. Sliding Window: A sliding window is a data processing technique used to continuously monitor and analyze data streams over a given time period. It involves defining a fixed-size window over a time series and moving this window over time. During each window, only the data within that window is considered for analysis and decision-making. In the context of blockchain contract subscriptions, sliding windows can be used to monitor the frequency of contract events or client subscription activity to dynamically adjust system behavior, such as determining contract or client activity or adjusting data synchronization strategies (read diffusion or write diffusion).

[0088] Please see Figure 1 , Figure 1 This is a schematic diagram of a network architecture provided in an embodiment of this application. For example... Figure 1 As shown, the network architecture may include a blockchain node cluster 1000, a business server (server-side) cluster 100, and a terminal device (client-side) cluster 10. The blockchain node cluster 1000 may include at least two blockchain nodes. Figure 1 As shown, the blockchain node cluster 1000 may include blockchain node 1000a, blockchain node 1000b, ..., blockchain node 1000n; the business server cluster 100 may specifically include business server 100a, business server 100b, ..., business server 100n; and the terminal device cluster 10 may specifically include terminal device 10a, terminal device 10b, ..., terminal device 10n.

[0089] like Figure 1 As shown, terminal devices 10a, 10b, ..., 10n can respectively connect to business servers 100a, 100b, ..., 100n, so that the terminal devices can interact with the business servers through the data connection; business servers 100a, 100b, ..., 100n can respectively connect to blockchain nodes 1000a, 1000b, ..., 1000n, so that the business servers can interact with the blockchain nodes through the data connection; blockchain nodes 1000a, 1000b, ..., 1000n are interconnected, so that the blockchain nodes can interact with each other.

[0090] It is understandable that blockchain nodes can transmit data or blocks through the aforementioned data connections. The blockchain network can establish data connections between blockchain nodes based on node identifiers. Each blockchain node in the network has a corresponding node identifier, and each blockchain node can store the node identifiers of other blockchain nodes that are connected to it. This allows it to broadcast acquired data or generated blocks to other blockchain nodes based on their node identifiers. For example, blockchain node 1000a can maintain a node identifier list as shown in Table 1, which stores the node names and node identifiers of other nodes.

[0091] Table 1

[0092] Node Name Node identifier Blockchain node 1000a AAA.AAA.AAA.AAA Blockchain node 1000b BBB.BBB.BBB.BBB … … 1000n blockchain nodes CCC.CCC.CCC.CCC

[0093] The node identifier can be an Internet Protocol (IP) address or any other information that can be used to identify a blockchain node in a blockchain network. Table 1 only uses IP addresses as an example. For instance, blockchain node 1000a can send information (e.g., transaction data) to blockchain node 1000b using the node identifier BBB.BBB.BBB.BBB, and blockchain node 1000b can determine that the information was sent by blockchain node 1000a using the node identifier AAA.AAA.AAA.AAA.

[0094] In blockchain, before a block is added to the chain, it must pass consensus among the consensus nodes in the blockchain network. Only after consensus is reached can the block be added to the blockchain. Understandably, when blockchain is used in scenarios such as schools or commercial institutions, not all participating nodes in the blockchain (i.e., the blockchain nodes in the aforementioned blockchain node cluster of 1000) have sufficient resources and the necessity to become consensus nodes. For example, in... Figure 1 In the blockchain node cluster 1000 shown, blockchain nodes 1000a, 1000b, and 1000n can be used as consensus nodes. Consensus nodes in blockchain node cluster 1000 participate in consensus, that is, reaching consensus on blocks (containing a batch of transactions), including generating blocks and voting on blocks; while non-consensus nodes do not participate in consensus, but help propagate block and voting messages, and synchronize states with each other.

[0095] like Figure 1As shown, each terminal device in the terminal device cluster 10 can have a client installed. When the client runs on each terminal device, it can interact with any business server in the aforementioned business server cluster 100, enabling any business server in the business server cluster 100 to receive business data from each terminal device. This client can be a game application, video editing application, social application, instant messaging application, live streaming application, short video application, video application, music application, shopping application, novel application, payment application, browser, or any other client capable of displaying text, images, audio, and video data. This client can be a standalone client or an embedded sub-client integrated into another client (such as an instant messaging client, social client, video client, etc.), and is not limited here.

[0096] The first object can subscribe to one or more contracts in the blockchain through a client running on its associated terminal device, thereby obtaining the contract events corresponding to the subscribed one or more contracts. Taking the first object subscribing to a target contract as an example, the process can be as follows: the terminal device can respond to the contract subscription operation made by the first object through the client, generate a contract subscription request, and then send the contract subscription request to the corresponding business server. The business server can forward the contract subscription request to the blockchain node. The blockchain node can respond to the contract subscription request, record the first object's subscription to the target contract, and then, when a new contract event is generated in the target contract, the blockchain node can synchronize the new contract event to the client (i.e., synchronize it to the terminal device where the client is located).

[0097] It is understandable that there can be one or more clients subscribing to the target contract. When the number of clients subscribing to the target contract is too large, pushing the contract events corresponding to the target contract to multiple clients simultaneously through write diffusion will consume a lot of network resources and system load. However, some clients, although subscribing to the target contract, may not want to know in real time which contract events have occurred, which will cause unnecessary waste of network resources and system load. Therefore, this application provides a data processing method that classifies contracts and clients into active and inactive categories to determine whether to synchronize contract events to clients through write diffusion or read diffusion, thereby reducing the waste of network resources and improving the performance of the blockchain system. The data processing method is as follows: When the consensus of the target block is confirmed to be passed, the target contract event corresponding to the target contract is obtained from the target block; the target contract subscription list corresponding to the target contract is obtained; the target contract subscription list contains the client identifiers corresponding to the clients subscribing to the target contract; if the target contract is an active contract, and the target contract subscription list and the active client list contain the same client identifier, then the same client identifier is identified as the write diffusion client identifier; the target contract event is synchronized to the client corresponding to the write diffusion client identifier through write diffusion, and the target contract event is synchronized to the client corresponding to the read diffusion client identifier through read diffusion. Here, the active client list contains the client identifiers corresponding to the active clients; the read diffusion client identifier refers to the client identifier in the target contract subscription list excluding the write diffusion client identifier.

[0098] It is understood that the above-mentioned data connection is not limited to the connection method. It can be connected directly or indirectly through wired communication, or directly or indirectly through wireless communication, or through other connection methods. This application does not impose any restrictions on this.

[0099] It is understood that the blockchain-based data processing method provided in this application embodiment can be executed by a computer device, which includes, but is not limited to, the aforementioned blockchain node (which can be a terminal or a server), a business server, and a terminal device. The aforementioned server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The aforementioned terminal device can be a smartphone, tablet computer, laptop computer, desktop computer, smart speaker, smartwatch, etc., but is not limited to these.

[0100] It is understood that the embodiments of this application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, and assisted driving.

[0101] It is understood that, in the specific embodiments of this application, the subscription contracts and other related data involved require user permission or consent when applied to specific products or technologies, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant regions.

[0102] To better understand the above process of contract event synchronization, please refer to [link / reference]. Figure 2 , Figure 2 This is a schematic diagram illustrating a scenario of a blockchain-based data processing method provided in an embodiment of this application. Wherein, as... Figure 2 The blockchain node 20 shown can be any blockchain node in the aforementioned blockchain node cluster 1000, for example, blockchain node 20 can be blockchain node 1000a; Figure 2 The clients 21 and 22 shown can be installed on any of the terminal devices in the terminal device cluster 10. For example, client 21 can be installed on terminal device 10a and client 22 can be installed on terminal device 10b.

[0103] like Figure 2 As shown, blockchain node 20 can classify contracts and client activity levels, dividing contracts into active and inactive contracts, and clients into active and inactive clients. The classification rules for active and inactive contracts can be determined based on the number of events generated by the contract and the number of client subscriptions. For example, if the number of contract events corresponding to contract A exceeds a certain threshold, or the number of client subscriptions (i.e., the number of clients subscribing to contract A) corresponding to contract A exceeds a certain threshold, contract A can be considered an active contract. Specific active contract classification rules can be determined based on actual circumstances, and this application does not impose any restrictions on this. Similarly, the classification rules for active and inactive clients can be determined based on the number of contract events received by the client and the number of contract subscriptions. For example, if the number of contract events received by client 21 exceeds a certain threshold, or the number of contract subscriptions corresponding to client 21 (i.e., the number of contracts subscribed to by client 21) exceeds a certain threshold, client 21 can be considered an active client. Specific active client classification rules can be determined based on actual circumstances, and this application does not impose any restrictions on this. It is understood that in this application, blockchain node 20 can use different synchronization methods to synchronize contract events for contracts and clients of different activity types.

[0104] like Figure 2As shown, assuming that the number of contract events corresponding to contract A is greater than that of contract B, and the number of client subscriptions corresponding to contract A is also greater than that of contract B, then blockchain node 20 can determine contract A as an active contract and contract B as an inactive contract. Similarly, assuming that the number of contract subscriptions corresponding to client 21 is much greater than that corresponding to client 22, and the number of contract events that client 21 needs to receive is also greater than that of client 22, blockchain node 20 can determine client 21 as an active client and client 22 as an inactive client. Assuming that blockchain node 20 has just determined that the consensus of the target block has passed, when the blockchain node executes transactions in the target block, it can execute transactions that need to call contract A through the contract A process and generate corresponding contract events, assuming that the contract events corresponding to contract A include: contract A event 1 and contract A event 2; at the same time, it can also execute transactions that need to call contract B through the contract B process and generate corresponding contract events, assuming that the contract events corresponding to contract B include contract B event 1. Blockchain node 20 needs to synchronize the contract events corresponding to the contract to the clients that have subscribed to the contract. In order to avoid unnecessary waste of network resources and system load, blockchain node 20 can determine how to synchronize contract events based on the activity type of the contract and the activity type of the client.

[0105] like Figure 2 As shown, for active contracts and active clients, blockchain node 20 can choose the write diffusion method to synchronize contract events. For example, for contract A and client 21, since contract A is an active contract and client 21 is an active client, after the blockchain node receives contract A event 1 and contract A event 2, it will directly push contract A event 1 and contract A event 2 to client 21, which is write diffusion synchronization.

[0106] like Figure 2 As shown, for active contracts and inactive clients, blockchain node 20 can choose a read-diffusion method to synchronize contract events. For example, for contract A and client 22, since contract A is an active contract and client 21 is an inactive client, after receiving contract A event 1 and contract A event 2, the blockchain node will not directly push contract A event 1 and contract A event 2 to client 21. Instead, it will store contract A event 1 and contract A event 2 in the contract A event set. When client 22 sends an event retrieval request to blockchain node 20, blockchain node 20 will then send contract A event 1 and contract A event 2 to client 21, which is read-diffusion synchronization.

[0107] like Figure 2As shown, for inactive contracts, regardless of whether the client is active or not, blockchain node 20 can choose the write diffusion method to synchronize contract events. For example, for contract B and clients 21 and 22, since contract B is an inactive contract, whether it is client 21, which is an active client, or client 22, which is an inactive client, the blockchain node can directly push contract B event 1 to client 21 after receiving contract B event 1, that is, write diffusion synchronization.

[0108] It is evident that the number of contract events corresponding to active contracts is too large. If these contract events are pushed to all clients simultaneously, it will consume a lot of network resources and system load. For inactive clients, it is not necessary to receive these contract events in real time. Therefore, for active contracts and inactive clients, a read diffusion method can be adopted to synchronize the corresponding contract events, thereby avoiding unnecessary waste of network resources and system load.

[0109] Further, please see Figure 3 , Figure 3 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. The method can be implemented using blockchain nodes (e.g., the aforementioned...). Figure 1 This method is executed by any blockchain node in the blockchain node cluster 1000 in the corresponding embodiment. The following description uses the execution of this method by a blockchain node as an example, wherein the blockchain-based data processing method may include at least the following steps S101-S104:

[0110] Step S101: When it is determined that the consensus of the target block has been passed, obtain the target contract event corresponding to the target contract from the target block.

[0111] Specifically, a target block refers to any block in the blockchain network. It should be understood that some transactions in a target block may require the execution of corresponding contracts (i.e., smart contracts). When the contract code contains event code, a corresponding contract event is generated when the contract is called to execute a transaction, recording changes to relevant state data. For example, the contract code of a transfer contract might contain a transfer event code: `Transfer(address a, address b, amount c)`, used to record the transfer function (originating address, destination address, transfer amount). When a transfer contract is executed, in addition to executing the corresponding transfer function, a transfer contract event is generated through the aforementioned transfer event code. Others can then check this transfer contract event to know that the transfer function was called, and to know the originating address, destination address, and transfer amount at the time of the call.

[0112] Specifically, a target block can contain multiple transactions. Different transactions can invoke different contracts and generate corresponding contract events when executed. Therefore, a target block can contain contract events corresponding to N contracts, where N is a positive integer, and the target contract refers to any one of these N contracts.

[0113] Step S102: Obtain the target contract subscription list corresponding to the target contract; the target contract subscription list includes the client identifiers corresponding to the clients that subscribe to the target contract.

[0114] Specifically, a client identifier is a string composed of letters, numbers, or symbols that can uniquely identify a client. For example, a client identifier can be D1 or D2, and different clients correspond to different client identifiers.

[0115] Step S103: If the target contract is an active contract, and the target contract subscription list and the active client list contain the same client identifier, then the same client identifier is determined as the write diffusion client identifier; the active client list contains the client identifier corresponding to the active client.

[0116] Specifically, an active contract refers to a contract whose activity level is greater than or equal to the contract activity level threshold. Conversely, a contract whose activity level is less than the threshold can be called an inactive contract. The contract activity level threshold is a critical value used to define whether a contract is active. It can be a preset fixed value or a dynamic value that is continuously adjusted according to the computing power resources of the blockchain nodes. Contract activity can be calculated based on custom activity determination rules. For example, it can be calculated based on the total number of contract events corresponding to the contract in the blockchain, the number of clients subscribing to the contract in real time, or the number of contract events corresponding to the contract over a period of time, etc. This application does not impose any restrictions on these rules.

[0117] Specifically, an active client refers to a client whose activity level is greater than or equal to a client activity threshold. Conversely, a client whose activity level is less than the client activity threshold can be called an inactive client. The client activity threshold is a critical value used to define whether a client is active or not. It can be a preset fixed value or a dynamic value that is continuously adjusted according to the client's computing resources. Client activity can be calculated based on custom activity determination rules. For example, it can be calculated based on the total number of contract events received by the client, the number of contracts subscribed to by the client in real time, or the number of contract events received by the client within a certain period, etc. This application does not impose any limitations on these rules.

[0118] Specifically, the active client list contains the client identifiers of all active clients, and the target contract subscription list contains the client identifiers corresponding to all clients subscribing to the target contract. Therefore, the client identifier that exists in both the active client list and the target contract subscription list is the client identifier corresponding to the active client subscribing to the target contract (i.e., the same client identifier contained in the active client list and the target contract subscription list). For active clients subscribing to the active contract, the contract event synchronization can be performed using write diffusion. Therefore, the client identifier corresponding to the active client subscribing to the target contract can be determined as the write diffusion client identifier.

[0119] Step S104: Synchronize the target contract event to the client corresponding to the write diffusion client identifier via write diffusion, and synchronize the target contract event to the client corresponding to the read diffusion client identifier via read diffusion; the read diffusion client identifier refers to the client identifier in the target contract subscription list excluding the write diffusion client identifier.

[0120] Specifically, a feasible implementation process for synchronizing the target contract event to the client corresponding to the write diffusion client identifier via write diffusion can be as follows: send the target contract event to the client corresponding to the write diffusion client identifier, so that the client corresponding to the write diffusion client identifier writes the target contract event into the client event set.

[0121] Specifically, a feasible implementation process for synchronizing target contract events to the client corresponding to the read diffusion client identifier via read diffusion can be as follows: write the target contract event into the target contract event set associated with the target contract; when a pull request for an event of the target contract is received from the target client, determine the contract events contained in the target contract event set as pullable contract events, and send the pullable contract events to the target client so that the target client writes the pullable contract events into the client event set; the target client belongs to the client corresponding to the read diffusion client identifier.

[0122] To better understand the implementation of write diffusion and read diffusion, please refer to the above. Figure 2 ,like Figure 2As shown, assuming the target contract is contract A, when blockchain node 20 confirms that the target block consensus has passed, it obtains contract events corresponding to contract A from the target block: Contract A Event 1 and Contract A Event 2. After determining that contract A is an active contract, blockchain node 20 further identifies the client identifier of client 21, which subscribes to contract A, as a write diffusion client identifier, and the client identifier of client 22 as a read diffusion client identifier. Therefore, blockchain node 20 will immediately push Contract A Event 1 and Contract A Event 2 to client 21, and client 21 will write Contract A Event 1 and Contract A Event 2 into its own client event set for storage. Simultaneously, blockchain node 20 will also write Contract A Event 1 and Contract A Event 2 into the Contract A event set for storage, because blockchain node 20 will not directly push Contract A Event 1 and Contract A Event 2 to client 22. When client 22 needs to view the contract events of contract A, it can send an event retrieval request to blockchain node 20. After receiving the event retrieval request sent by client 22, blockchain node 20 will push all contract events contained in the contract A event set (which may include not only contract A event 1 and contract A event 2, but also contract events corresponding to contract A in blocks generated before the target block that have not yet been pushed to client 22) to client 22.

[0123] Optionally, if the target contract is an inactive contract, or if the target contract subscription list and the active client list do not contain different client identifiers, then the target contract events are synchronized to the clients corresponding to the client identifiers contained in the target contract subscription list via write diffusion.

[0124] The method provided in this application embodiment can dynamically classify contracts into active or inactive contracts, and clients into active or inactive clients. For active clients subscribing to active contracts, a write diffusion method is used to synchronize target contract events, while for inactive clients subscribing to active contracts, a read diffusion method is used to synchronize target contract events. This reduces unnecessary waste of network resources and alleviates excessive load on blockchain nodes and information overload on inactive clients, thereby improving the performance of the blockchain system.

[0125] Further, please see Figure 4 , Figure 4 This is a flowchart illustrating a data processing method for determining active contracts according to an embodiment of this application. This method can be used to determine the aforementioned... Figure 3 Whether the target contract described in the corresponding embodiment is an active contract. This method can be implemented by a blockchain node (e.g., the one mentioned above). Figure 1This method is executed by any blockchain node in the blockchain node cluster 1000 in the corresponding embodiment. The following description uses the execution of this method by a blockchain node as an example, wherein the blockchain-based data processing method may include at least the following steps S201-S204:

[0126] Step S201: Determine the average number of block contract events for the target contract within the target time period; the end time of the target time period is the current system time.

[0127] Specifically, the target contract can be one of the above. Figure 3 The target contract described in the corresponding embodiment, the target block can be the one described above. Figure 3 The target block described in the corresponding embodiment. The current system time refers to the system time when the blockchain node begins to determine the average number of block contract events. The average number of block contract events refers to the average number of contract events corresponding to the target contract contained in the block within the target time period. For example, if the target contract is contract A, the target block is block X, the system time when block X passes consensus is 9:05, and the preset time period is ten minutes, then the target time period can be 8:55-9:05. Assuming that the blocks that pass consensus within the target time period are block X, block Y, and block Z, block X contains 15 contract events corresponding to contract A, block Y contains 16 contract events corresponding to contract A, and block Z contains 17 contract events corresponding to contract A, then the average number of block contract events is the average of the number of contract events corresponding to contract A contained in blocks X, Y, and Z, i.e., (15+16+17) / 3=16.

[0128] Specifically, a feasible implementation process for determining the average number of block contract events for a target contract within a target time period can be as follows: Obtain a sliding window for the number of contract events corresponding to the target contract; the sliding window contains the number of block contract events corresponding to M blocks respectively; M is a positive integer; the number of block contract events refers to the number of contract events corresponding to the target contract contained in a block; the writing window times for the M block contract event counts all fall within the target time period; the average number of block contract events corresponding to the target block and the M block contract event counts are calculated to obtain the average number of block contract events for the target contract within the target time period. The sliding window for the number of contract events corresponding to the target contract is used to continuously detect and analyze the number of contract events corresponding to the target contract contained in the on-chain blocks within a certain time range. It can be understood as a window defining a fixed time length (i.e., a fixed time period) on the time series, which slides over time. For example, assuming the window length is ten minutes and the system time is 9:11, the sliding window covers the time period from 9:01 to 9:11. When the system time reaches 9:15, the sliding window covers the time period from 9:05 to 9:15. In other words, whenever a new block consensus is passed, the blockchain node can write the number of block contract events corresponding to the target contract in that block into the sliding window. However, since the sliding window slides over time, if the writing window time corresponding to the number of block contract events does not fall within the time period covered by the sliding window, the number of block contract events should be deleted.

[0129] Optionally, the number of block contract events corresponding to the target block is added to the contract event number sliding window to obtain a new contract event number sliding window. When it is detected that the new contract event number sliding window contains expired block contract event numbers, the expired block contract event numbers are deleted from the new contract event number sliding window. The expired block contract event number refers to the number of block contract events in the new contract event number sliding window whose write window time does not belong to the new target time period. The end time point in the new target time period is the system time when the detection of the new contract event number sliding window begins. For example, if the window time length of the contract event number sliding window is five minutes, at 9:10, when the time period covered by the contract event number sliding window is [9:05, 9:10], after writing the block contract event number of block 3 (assuming it is the target block) into the contract event number sliding window, the new contract event number sliding window can contain the block contract event number of block 1 (write window time 9:06), the block contract event number of block 2 (write window time 9:08), and the block contract event number of block 2 (write window time 9:06). If the entry window time is 9:10, the blockchain node can periodically (e.g., every 30 seconds, every minute) check the expiration of the contract event count sliding window. For example, if the blockchain node checks the expiration of the new contract event count sliding window at 9:13, and the time period covered by the new contract event count sliding window is [9:08, 9:13], then the number of contract events in block 1 will be the number of expired contract events, and the blockchain node will delete the number of expired contract events from the new contract event count sliding window.

[0130] Step S202: Determine the average number of subscribers to the target contract during the target time period.

[0131] Specifically, a feasible implementation process for determining the average number of subscribed clients for a target contract within a target time period can be as follows: Obtain a sliding window of the number of subscribed clients corresponding to the target contract; the sliding window contains N subscribed client counts; N is a positive integer; a subscribed client count refers to the number of clients subscribing to the target contract when a subscription update request is successfully executed; the write window times of the N subscribed client counts all fall within the target time period; calculate the average number of subscribed clients for the target contract within the target time period by averaging the N subscribed client counts. It can be understood that the sliding window of the number of subscribed clients is used to continuously detect and analyze the number of clients subscribing to the target contract within a certain time range. It also defines a window of fixed time length (i.e., a fixed time period) on the time series, and it slides over time. Assuming the time period covered by the obtained sliding window for the number of subscribed clients is [9:10, 9:20], which includes {the number of subscribed clients after the execution of subscription update request 1 is 15 (write window time 9:11), the number of subscribed clients after the execution of subscription update request 2 is 17 (write window time 9:17), and the number of subscribed clients after the execution of subscription update request 3 is 18 (write window time 9:19)}, then the average number of subscribed clients of the target contract within [9:10, 9:20] is (15+17+19) / 3 = 17.

[0132] Optionally, upon receiving a target subscription update request for the target contract, the contract subscription list corresponding to the target contract is updated according to the target subscription update request to obtain an updated contract subscription list. The number of client identifiers contained in the updated contract subscription list is determined as the number of updated subscription clients, and this updated number of subscription clients is added to the subscription client number sliding window to obtain a new subscription client number sliding window. When it is detected that the new subscription client number sliding window contains expired subscription clients, the expired subscription clients are deleted from the new subscription client number sliding window. The expired subscription clients refer to the number of subscription clients in the new subscription client number sliding window whose writing window time does not belong to the new target time period. The end time point in the new target time period is the system time when the new subscription client number sliding window is first detected. The target subscription update request can be a target subscription add request for subscribing to the target contract or a target subscription delete request for unsubscribing from the target contract. Accordingly, when the target subscription update request is a target subscription add request, the update process can be to add the client identifiers contained in the target subscription add request to the contract subscription list corresponding to the target contract; when the target subscription update request is a target subscription delete request, the update process can be to delete the client identifiers contained in the target subscription delete request from the contract subscription list corresponding to the target contract.

[0133] Step S203: Perform a weighted summation of the average number of block contract events and the average number of subscribed clients to obtain the contract activity level corresponding to the target contract.

[0134] Specifically, the average number of block contract events can correspond to a first weighting coefficient, and the average number of subscribed clients can correspond to a second weighting coefficient. The setting of the first weighting coefficient and the second weighting coefficient can be determined based on the actual situation, and this application does not impose any restrictions on them.

[0135] For example, a blockchain node can determine the average number of block contract events and the average number of subscribed clients for each contract on the blockchain in the most recent 10 minutes (assuming it is the target time period), as shown in Table 2:

[0136] Table 2

[0137]

[0138]

[0139] Assume that the first weighting coefficient corresponding to the average number of block contract events is α, and the second weighting coefficient corresponding to the average number of subscribed clients is β. Then, the contract activity of contract 1 is 3000*α + 100*β, and the contract activity of contract n is 1000*α + 10*β.

[0140] Step S204: If the contract activity level is greater than or equal to the contract activity level threshold, then the target contract is determined to be an active contract.

[0141] Optionally, blockchain nodes can obtain information on occupied computing resources and total computing resources; determine the idle computing resources of the blockchain node based on the occupied and total computing resources information; and adjust the default contract activity threshold based on the idle computing resources information to obtain the contract activity threshold. The occupied computing resources information is a quantitative indicator representing the computing resources occupied by the blockchain system; the total computing resources information refers to the quantitative indicator information corresponding to all computing resources of the blockchain system; and the idle computing resources information refers to the quantitative indicator information corresponding to the unoccupied computing resources of the blockchain system. The quantitative indicator information may include one or more indicators from multiple sources, such as CPU computing power, GPU computing power, memory usage, network bandwidth usage, and disk read / write capability. One feasible implementation process for adjusting the default contract activity threshold based on idle computing power resource information is as follows: If the idle computing power resource information is greater than the idle computing power resource information threshold, the default contract activity threshold is lowered to obtain the final contract activity threshold; if the idle computing power resource information is less than or equal to the idle computing power resource information threshold, the default contract activity threshold is raised to obtain the final contract activity threshold. The idle computing power resource information threshold can be set based on the actual operation of the blockchain system and is not restricted here. The default contract activity threshold refers to the initially set contract activity threshold. It is understood that when the idle computing power resource information is greater than the idle computing power resource information threshold, it indicates that the blockchain system still has a significant amount of computing power resources available. In this case, the threshold for determining active contracts can be raised, reducing the number of active contracts and thus increasing the number of contract events that need to be synchronized through write diffusion, thereby improving the utilization rate of computing power resources. Conversely, when the idle computing power resource information is less than the idle computing power resource information threshold, it indicates that the blockchain system has fewer computing power resources available. In this case, the threshold for determining active contracts can be lowered to increase the number of active contracts, thereby reducing the number of contract events that need to be synchronized through write diffusion and avoiding excessive load on blockchain nodes.

[0142] This application significantly improves the efficiency of blockchain contract subscription by intelligently distinguishing between active and inactive contracts and clients, combined with read diffusion and write diffusion strategies. The application of activity determination and sliding window technology enables the system to dynamically adjust resource allocation, reduce unnecessary network load, and ensure that real-time events are quickly delivered to active users, thereby optimizing overall performance and resource utilization while ensuring response speed.

[0143] Further, please see Figure 5 , Figure 5This is a flowchart illustrating a data processing method for generating an active client list according to an embodiment of this application. The method can be implemented using a blockchain node (e.g., the one described above). Figure 1 This method is executed by any blockchain node in the blockchain node cluster 1000 in the corresponding embodiment. The following description uses the execution of this method by a blockchain node as an example, wherein the blockchain-based data processing method may include at least the following steps S301-S305:

[0144] Step S301: Obtain the subscription client identifiers corresponding to the L subscription clients respectively; L is a positive integer, and a subscription client refers to a client that subscribes to one or more contracts.

[0145] Step S302: Determine the average number of block client events for each of the L subscribed clients within the target time period; the end time of the target time period is the current system time.

[0146] Specifically, the average number of client events per block refers to the average number of contract events corresponding to a single subscriber within a block during a target time period. For example, at 9:15, the target time period is 9:05-9:15. In the three blocks generated between 9:05 and 9:15, the number of contract events related to subscriber A are 18, 19, and 20 respectively. Therefore, the average number of client events per block for subscriber A during the period from 9:05 to 9:15 is (18+19+20) / 3 = 19.

[0147] Specifically, given L subscribing clients including the target subscribing client, a feasible implementation for determining the average number of client events per block for each of the L subscribing clients within a target time period can be as follows: Obtain a sliding window for the number of client events corresponding to the target subscribing client; the sliding window includes P blocks containing client events; P is a positive integer; the number of client events per block refers to the number of contract events corresponding to the target subscribing client contained in a block; the write window times for the P blocks containing client events all fall within the target time period; calculate the average number of client events per block for the target subscribing client and the P blocks containing client events to obtain the average number of client events per block for the target subscribing client within the target time period. In essence, the sliding window for the number of client events is used to continuously detect and analyze the number of contract events corresponding to the target subscribing client contained in on-chain blocks within a certain time range. It also defines a window of a fixed time length (i.e., a fixed time period) on the time series, and it slides over time. Assuming the time period covered by the sliding window for the number of client events is [9:10, 9:20], which includes {the number of contract events corresponding to the target subscribing client in block 1 is 15 (write window time 9:11), the number of contract events corresponding to the target subscribing client in block 2 is 17 (write window time 9:17), and the number of contract events corresponding to the target subscribing client in block 3 is 18 (write window time 9:19)}, then the average number of block client events for the target subscribing client within [9:10, 9:20] is (15+17+19) / 3 = 17.

[0148] Step S303: Determine the average number of subscription contracts for each of the L subscription clients during the target time period.

[0149] Specifically, given L subscribing clients, including the target subscribing client, a feasible implementation process for determining the average number of subscription contracts corresponding to each of the L subscribing clients within the target time period can be as follows: Obtain a sliding window of the number of subscription contracts corresponding to the target subscribing client; the sliding window of the number of subscription contracts includes Q subscription contracts; Q is a positive integer; a subscription contract number refers to the number of contracts subscribed by the target subscribing client when a subscription update request is successfully executed; the write window times for the Q subscription contracts all fall within the target time period; the average number of subscription contracts for the target subscribing client is calculated by averaging the Q number of subscribing clients. It can be understood that the client event count sliding window is used to continuously detect and analyze the number of contracts subscribed by the target subscribing client within a certain time range. It also defines a window of a fixed time length (i.e., a fixed time period) on the time series, and it slides over time. Assuming the time period covered by the obtained sliding window of subscription contract count is [9:10, 9:20], which includes {the number of subscription contracts after the execution of subscription update request 1 is 15 (write window time 9:11), the number of subscription contracts after the execution of subscription update request 1 is 17 (write window time 9:17), and the number of subscription contracts after the execution of subscription update request 1 is 18 (write window time 9:19)}, then the average number of subscription contracts for the target contract within [9:10, 9:20] is (15+17+19) / 3 = 17.

[0150] Step S304: Perform a weighted summation of the average number of block client events and the average number of subscription contracts for each subscribing client to obtain the client activity level for each subscribing client.

[0151] Specifically, the average number of block client events can correspond to a third weighting coefficient, and the average number of subscription contracts can correspond to a fourth weighting coefficient. The setting of the third and fourth weighting coefficients can be determined based on the actual situation, and this application does not impose any restrictions on them.

[0152] For example, a blockchain node can determine the average number of block client events and the average number of subscription contracts for each subscription client on the blockchain in the most recent 10 minutes (assuming it is the target time period), as shown in Table 3:

[0153] Table 3

[0154]

[0155] Assume that the third weighting coefficient corresponding to the average number of block client events is δ, and the fourth weighting coefficient corresponding to the average number of subscription contracts is γ. Then, the client activity level corresponding to client 1 is 4000*δ+2*γ, and the client activity level corresponding to client m is 1000*δ+1*γ.

[0156] Step S305: Among the L subscription clients, those whose client activity level is greater than the client activity level threshold are identified as active clients, and an active client list is generated based on the client identifier corresponding to the active client.

[0157] Specifically, the list of active clients can be as described above. Figure 3 The list of active clients described in the corresponding embodiment.

[0158] Furthermore, the above data processing methods can be implemented through scalable blockchain contract subscription scheme system architectures that combine different read diffusion and write diffusion approaches. For easier understanding, please refer to [link to relevant documentation]. Figure 6 , Figure 6 This is a schematic diagram of a scalable blockchain contract subscription scheme system architecture combining read diffusion and write diffusion, provided in an embodiment of this application. Figure 6 As shown, a blockchain node can include a network module, a verification module, a transaction pool module, a scheduling module, a consensus module, a subscription management module, an event management module, and a storage module. The internal implementation of a blockchain node and the interactions between these modules are described in detail below:

[0159] like Figure 6 The network module shown is responsible for handling all network communication between nodes and other nodes, including sending, receiving, and forwarding data. It acts as a bridge for nodes to interact with the outside world, ensuring that information can be transmitted securely and efficiently within the blockchain network.

[0160] like Figure 6 The primary responsibility of the verification module shown is to ensure the legitimacy and correctness of transactions and blocks. It typically comprises two sub-modules: certificate verification and permission verification. Certificate verification verifies the digital signatures of blocks and transactions, ensuring they originate from a trusted sender and have not been tampered with since their creation. Permission verification checks whether the entity initiating the transaction has the authority to execute it and whether the transaction complies with the rules of the blockchain network.

[0161] like Figure 6 The transaction pool module shown is a temporary storage area used to hold transactions that have been received by blockchain nodes but have not yet been packaged into a block. It allows nodes to sort and select transactions to determine which transactions will be included in the next block.

[0162] like Figure 6The scheduling module shown is responsible for managing the lifecycle of transactions and blocks, ensuring that transactions are processed and packaged according to a certain logic and order. It includes the following sub-modules: a block generator, a transaction scheduling module, a contract repository, and a contract process pool. The block generator is responsible for creating new blocks; it selects suitable transactions from the transaction pool and assembles them into blocks according to specific rules. The transaction scheduling module manages the transactions in the transaction pool, deciding which transactions should be prioritized or included in new blocks. The contract repository stores all smart contract code and related metadata deployed on the blockchain. The contract process pool provides the execution environment and resource management so that smart contracts can be invoked and executed.

[0163] like Figure 6 The consensus module shown implements the consensus algorithm in the blockchain network, which is crucial for blockchain security and consistency. The consensus module ensures that all nodes reach a consensus on the network state and verifies the legitimacy of new blocks.

[0164] like Figure 6 The subscription management module shown is responsible for handling client subscriptions and notifications of smart contract events. It includes the following sub-modules: a contract client subscription list and an activity level determiner. The contract client subscription list records which clients have subscribed to which contracts and which events, ensuring that the correct clients are notified when an event occurs. The activity level determiner contains two sub-modules for determining the activity status of contracts and clients: an active contract determiner and an active client determiner. The active contract determiner uses the frequency of contract events and other metrics to determine which contracts are active; the active client determiner uses the frequency of client interactions and other metrics to determine which clients are active.

[0165] like Figure 6 The event management module shown is used to manage the lifecycle of smart contract events, including event capture, storage, and distribution. It can contain multiple event management sub-modules for different contracts. For example, the event management module can include a Contract 1 event management module and a Contract 2 event management module. The Contract 1 event management module manages the lifecycle of contract events corresponding to Contract 1, and may include a Contract 1 event publishing module and a Contract 1 event set; the Contract 2 event management module manages the lifecycle of contract events corresponding to Contract 2, and may include a Contract 2 event publishing module and a Contract 2 event set.

[0166] like Figure 6The storage module shown is responsible for maintaining and managing all data storage on the blockchain, including the current state and historical records. It typically contains two sub-modules: a state database and a block ledger. The state database stores the current blockchain state, such as account balances and smart contract states. The block ledger stores all blocks and transactions that have been confirmed by the network, forming the blockchain's historical record.

[0167] Understandable, such as Figure 6 Each module shown can be deployed on a blockchain node, and the functions provided by each module can also be implemented by the blockchain node.

[0168] By having all the modules in the scalable blockchain contract subscription scheme system architecture that combines read diffusion and write diffusion provided in the embodiments of this application work together, it can be ensured that blockchain nodes can process transactions, generate and verify blocks, and maintain the overall state of the blockchain.

[0169] Furthermore, to facilitate understanding of the data processing methods proposed based on the above embodiments and the above-described... Figure 6 The system architecture shown illustrates a scalable blockchain contract subscription scheme that combines read and write diffusion. For a complete interactive process of a client subscribing to a contract from a blockchain node under this combined read and write diffusion model, please refer to [link to relevant documentation]. Figure 7 , Figure 7 This is a schematic diagram illustrating a blockchain contract subscription process combining read diffusion and write diffusion, as provided in an embodiment of this application. Figure 7 As shown, the entire process of subscribing to a blockchain contract that combines read diffusion and write diffusion can include the following steps S401-S409:

[0170] Step S401: The blockchain nodes confirm that the consensus for the new block has been reached.

[0171] Specifically, the new block can be one of the above. Figure 3 The target block described in the corresponding embodiment.

[0172] In step S402, the blockchain node retrieves all contract events from the new block through the event management module.

[0173] Specifically, a new block can contain contract events of one or more contracts. Blockchain nodes can first parse the new block to obtain all the contract events it contains.

[0174] In step S403, the contract event publishing module of each contract in the event management module obtains the contract events related to itself from the new block.

[0175] Specifically, from the above Figure 6As can be seen, each contract has its own contract event publishing module, which will only obtain the contract events corresponding to its own contract.

[0176] Step S404: The contract event publishing module accesses the active client determiner to obtain all active clients.

[0177] Specifically, a feasible method for the active client determiner to identify which clients are active can be found in the above. Figure 5 The data processing method for generating the active client list provided in the corresponding embodiment will not be described in detail here.

[0178] Step S405: For each contract, the contract event publishing module accesses the contract client subscription table to obtain the list of clients subscribed to the contract.

[0179] Step S406: For each contract, the contract event publishing module accesses the active contract determiner to query whether the current contract is an active contract. If yes, proceed to step S407; otherwise, proceed to step S409.

[0180] Specifically, a feasible method for the active contract determiner to determine whether the current contract is an active contract can be found above. Figure 4 The data processing method for determining active contracts provided in the corresponding embodiments will not be described in detail here.

[0181] Step S407: Does the client list of this contract contain active clients? If yes, proceed to step S408; otherwise, proceed to step S409.

[0182] In step S408, the contract event publishing module puts the contract events into the contract event set through read diffusion. After each client goes online, it retrieves the contract events from the contract event set.

[0183] In step S409, the contract event publishing module sends the event directly to the client event set of these clients through write diffusion.

[0184] Specifically, the implementation process of steps S407-S409 can be found above. Figure 3 The specific description of step S104 in the corresponding embodiment will not be repeated here.

[0185] The method provided in this application implements an adaptive event distribution mechanism based on contract activity and client activity. This mechanism dynamically classifies contracts as active or inactive contracts and clients as active or inactive clients by real-time monitoring of contract event generation frequency and client subscription behavior. For combinations of active contracts and inactive clients, a read diffusion strategy is employed to reduce unnecessary network load and resource consumption; for other combinations, a write diffusion strategy is used to ensure timely event delivery. This adaptive mechanism significantly improves the efficiency and scalability of the blockchain system when handling a large number of subscription relationships.

[0186] Furthermore, to facilitate understanding of the data processing methods proposed based on the above embodiments and the above-described... Figure 6 The illustrated scalable blockchain contract subscription scheme architecture, combining read diffusion and write diffusion, adjusts the sliding window based on real-time event subscriptions and updates the threshold according to system usage, ultimately affecting the activity determination of contracts and clients, thus achieving a dynamic activity switching process. Please refer to [link to relevant documentation]. Figure 8 , Figure 8 This is a schematic diagram illustrating a process for determining and dynamically switching activity levels based on real-time event subscriptions, provided in an embodiment of this application. Figure 8 As shown, the entire process of determining and dynamically switching activity levels based on real-time event subscriptions can include the following steps S501-S511:

[0187] Step S501: After the blockchain node deploys the contract, it initializes the sliding window for the number of contract events and the sliding window for the number of subscribed clients.

[0188] Specifically, the sliding window for the number of contract events is as described above. Figure 4 The sliding window for the number of contract events and the sliding window for the number of subscribed clients described in the corresponding embodiment are as described above. Figure 4 The corresponding embodiment describes a sliding window for the number of subscription clients.

[0189] Step S502: After the blockchain client subscribes to the contract, it initializes the client event count sliding window and the subscription contract count sliding window.

[0190] Specifically, the client event count sliding window is as described above. Figure 5 The client event count sliding window and subscription contract count sliding window mentioned in the corresponding embodiment are the above-mentioned Figure 5 The corresponding embodiment describes the sliding window for the number of subscription contracts.

[0191] Step S503: Is a new block being generated? If yes, proceed to step S504; otherwise, proceed to step S507.

[0192] Step S504: parse the contract events corresponding to the contracts in the block.

[0193] Step S505: Delete the oldest data in the contract event count slider and the client event count slider.

[0194] Specifically, deleting the oldest data in the contract event quantity sliding window means deleting data whose write window time no longer falls within the time period covered by the contract event quantity sliding window. For the detailed deletion process, please refer to the above. Figure 4 The optional description of step S201 in the corresponding embodiment will not be repeated here. The process of deleting the oldest data in the client event count sliding window can be referred to as deleting the oldest data in the contract event count sliding window.

[0195] Step S506: Add the latest data to the contract event count slider window and the client event count slider window.

[0196] Specifically, the latest data refers to the data contained in the new block related to the sliding window of contract event counts and the sliding window of client event counts.

[0197] Step S507: Are there any clients currently subscribing to or unsubscribing from the contract? If yes, proceed to step S508; otherwise, proceed to step S511.

[0198] Step S508: Update the contract client subscription table.

[0199] Step S509: Delete the oldest data in the subscriber count sliding window and the subscriber contract count sliding window.

[0200] Specifically, the process of deleting the oldest data in the subscriber count sliding window can be found above. Figure 4 The optional description of step S202 in the corresponding embodiment will not be repeated here. The process of deleting the oldest data in the subscription contract number sliding window can be implemented by referring to the process of deleting the oldest data in the subscription client number sliding window.

[0201] Step S510: Add the latest data to the subscriber client count sliding window and the subscriber contract count sliding window.

[0202] Specifically, the latest data refers to the number of clients subscribing to the contract and the number of subscription contracts corresponding to the contracts after the current client subscription or contract unsubscription.

[0203] Step S511: The blockchain node adjusts the activity threshold based on the current system's idle computing power resource information.

[0204] Specifically, the system's idle computing resources information can include data such as the current system's CPU (Central Processing Unit) and memory pressure. For detailed adjustment procedures, please refer to the above. Figure 4 The optional description of step S204 in the corresponding embodiment will not be repeated here.

[0205] The method provided in this application innovatively introduces sliding window technology for real-time detection and evaluation of the frequency of contract events and client subscription patterns. By analyzing the data within the sliding window, the system can dynamically adjust the activity threshold, thereby achieving accurate determination of contract and client activity. This method not only automatically optimizes resource allocation based on the current system load but also maintains efficient event notification services under different network conditions and system loads, significantly improving the performance and response speed of blockchain contract subscription services.

[0206] Please see Figure 9 , Figure 9 This is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of this application. The data processing device can be a computer program (including program code) running on a computer device; for example, the data processing device is an application software. The data processing device 1 can be used to execute corresponding steps in the data processing method provided in the embodiments of this application. Figure 9 As shown, the data processing device 1 may include: an event acquisition module 101, a list acquisition module 102, an identifier determination module 103, a first synchronization module 104, and a second synchronization module 105.

[0207] Event acquisition module 101 is used to acquire the target contract event corresponding to the target contract from the target block when it is determined that the target block consensus has been passed;

[0208] The list retrieval module 102 is used to retrieve the target contract subscription list corresponding to the target contract; the target contract subscription list contains the client identifiers corresponding to the clients that subscribe to the target contract;

[0209] The identifier determination module 103 is used to determine the same client identifier as the write diffusion client identifier if the target contract is an active contract and the target contract subscription list and the active client list contain the same client identifier; the active client list contains the client identifier corresponding to the active client.

[0210] The first synchronization module 104 is used to synchronize the target contract event to the client corresponding to the write diffusion client identifier through write diffusion.

[0211] The second synchronization module 105 is used to synchronize the target contract event to the client corresponding to the read diffusion client identifier through read diffusion; the read diffusion client identifier refers to the client identifier in the target contract subscription list excluding the write diffusion client identifier.

[0212] The specific implementation methods of the event acquisition module 101, list acquisition module 102, identifier determination module 103, first synchronization module 104, and second synchronization module 105 can be found above. Figure 3 The specific descriptions of steps S101-S104 in the corresponding embodiments will not be repeated here.

[0213] Specifically, the first synchronization module 104 is used to send the target contract event to the client corresponding to the write diffusion client identifier, so that the client corresponding to the write diffusion client identifier writes the target contract event into the client event set.

[0214] The specific implementation of the first synchronization module 104 can be found in the above description. Figure 3 The specific description of step S104 in the corresponding embodiments will not be repeated here.

[0215] The second synchronization module 105 includes an event set writing unit 1051 and a pull and push unit 1052.

[0216] The event set writing unit 1051 is used to write the target contract event into the target contract event set associated with the target contract.

[0217] The pull and push unit 1052 is used to determine the contract events contained in the target contract event set as pullable contract events when it receives an event pull request for the target contract from the target client, and send the pullable contract events to the target client so that the target client writes the pullable contract events into the client event set; the target client belongs to the client corresponding to the read diffusion client identifier.

[0218] The specific implementation methods of the event set writing unit 1051 and the pull and push unit 1052 can be found in the above description. Figure 3 The specific description of step S104 in the corresponding embodiments will not be repeated here.

[0219] The data processing device 1 further includes: a first determination module 106, a second determination module 107, a first weighted summation module 108, and a first active determination module 109.

[0220] The first determining module 106 is used to determine the average number of block contract events of the target contract within the target time period; the end time of the target time period is the current system time; the average number of block contract events refers to the average number of contract events corresponding to the target contract contained in the block within the target time period;

[0221] The second determining module 107 is used to determine the average number of subscribed clients of the target contract within the target time period;

[0222] The first weighted summation module 108 is used to perform weighted summation on the average number of block contract events and the average number of subscribed clients to obtain the contract activity corresponding to the target contract.

[0223] The first active determination module 109 is used to determine the target contract as an active contract if the contract activity level is greater than or equal to the contract activity level threshold.

[0224] The specific implementation methods of the first determining module 106, the second determining module 107, the first weighted summation module 108, and the first active determining module 109 can be found above. Figure 4 The specific descriptions of steps S201-S204 in the corresponding embodiments will not be repeated here.

[0225] The first determining module 106 includes: a first window acquisition unit 1061 and a first mean calculation unit 1062.

[0226] The first window acquisition unit 1061 is used to acquire the sliding window of the number of contract events corresponding to the target contract; the sliding window of the number of contract events contains the number of block contract events corresponding to M blocks respectively; M is a positive integer; the number of contract events in a block refers to the number of contract events corresponding to the target contract contained in a block; the writing window time of the number of contract events in M ​​blocks all belong to the target time period;

[0227] The first average calculation unit 1062 is used to perform average calculation on the number of block contract events corresponding to the target block and the number of M block contract events to obtain the average number of block contract events of the target contract within the target time period.

[0228] The specific implementation methods of the first window acquisition unit 1061 and the first mean calculation unit 1062 can be found in the above description. Figure 4 The specific description of step S201 in the corresponding embodiments will not be repeated here.

[0229] The data processing device 1 mentioned above also includes a first window update module 110.

[0230] The first window update module 110 is used to add the number of block contract events corresponding to the target block to the contract event number sliding window to obtain a new contract event number sliding window.

[0231] The first window update module 110 is also used to delete the number of expired block contract events from the new contract event count sliding window when it is detected that the new contract event count sliding window contains the number of expired block contract events; the number of expired block contract events refers to the number of block contract events in the new contract event count sliding window whose write window time does not belong to the new target time period; the end time point in the new target time period is the system time when the new contract event count sliding window is detected.

[0232] The specific implementation of the first window update module 110 can be found in the above description. Figure 4 The optional description of step S201 in the corresponding embodiments will not be repeated here.

[0233] The second determining module 107 includes a second window acquisition unit 1071 and a second mean calculation unit 1072.

[0234] The second window acquisition unit 1071 is used to acquire the sliding window of the number of subscribed clients corresponding to the target contract; the sliding window of the number of subscribed clients contains N subscription client counts; N is a positive integer; a subscription client count refers to the number of clients subscribing to the target contract when a subscription update request is successfully executed; the writing window time of the N subscription client counts all belong to the target time period;

[0235] The second average calculation unit 1072 is used to perform average calculation on the number of N subscription clients to obtain the average number of subscription clients of the target contract within the target time period.

[0236] The specific implementation methods of the second window acquisition unit 1071 and the second mean calculation unit 1072 can be found in the above description. Figure 4 The specific description of step S201 in the corresponding embodiments will not be repeated here.

[0237] The data processing device 1 mentioned above also includes a second window update module 111.

[0238] The second window update module 111 is used to update the contract subscription list corresponding to the target contract according to the target subscription update request when a target subscription update request for the target contract is received, so as to obtain the updated contract subscription list.

[0239] The second window update module 111 is also used to determine the number of client identifiers contained in the updated contract subscription list as the number of updated subscription clients, add the number of updated subscription clients to the subscription client number sliding window, and obtain a new subscription client number sliding window;

[0240] The second window update module 111 is also used to delete the number of expired subscription clients from the new subscription client count sliding window when it is detected that the new subscription client count sliding window contains the number of expired subscription clients; the number of expired subscription clients refers to the number of subscription clients in the new subscription client count sliding window whose writing window time does not belong to the new target time period; the end time point in the new target time period is the system time when the new subscription client count sliding window is detected.

[0241] The specific implementation of the second window update module 111 can be found above. Figure 4 The optional description of step S202 in the corresponding embodiments will not be repeated here.

[0242] The data processing device 1 mentioned above also includes a threshold determination module 112.

[0243] The threshold determination module 112 is used to obtain information on occupied computing resources and total computing resources.

[0244] The threshold determination module 112 is also used to determine the idle computing power resource information of the blockchain node based on the occupied computing power resource information and the total computing power resource information;

[0245] The threshold determination module 112 is also used to perform numerical adjustment processing on the default contract activity threshold based on the idle computing power resource information to obtain the contract activity threshold.

[0246] The specific implementation of the threshold determination module 112 can be found in the above description. Figure 4 The optional description of step S201 in the corresponding embodiments will not be repeated here.

[0247] The data processing device 1 further includes: an identifier acquisition module 113, a third determination module 114, a fourth determination module 115, a second weighted summation module 116, and a second activity determination module 117.

[0248] The identifier acquisition module 113 is used to acquire the identifiers of the L subscription clients respectively; L is a positive integer, and a subscription client refers to a client that subscribes to one or more contracts;

[0249] The third determining module 114 is used to determine the average number of block client events corresponding to L subscription clients within the target time period; the end time point in the target time period is the current system time; an average number of block client events refers to the average number of contract events corresponding to one subscription client contained in a block within the target time period;

[0250] The fourth determining module 115 is used to determine the average number of subscription contracts corresponding to the L subscription clients within the target time period;

[0251] The second weighted summation module 116 is used to perform weighted summation on the average number of block client events and the average number of subscription contracts for each subscribing client to obtain the client activity level for each subscribing client.

[0252] The second active determination module 117 is used to determine the active clients among the L subscribed clients whose client activity level is greater than the client activity threshold, and generate an active client list based on the client identifier corresponding to the active client.

[0253] The specific implementation methods of the identifier acquisition module 113, the third determination module 114, the fourth determination module 115, the second weighted summation module 116, and the second activity determination module 117 can be found above. Figure 5 The specific descriptions of steps S301-S305 in the corresponding embodiments will not be repeated here.

[0254] The data processing device 1 mentioned above also includes a third synchronization module 118.

[0255] The third synchronization module 118 is used to synchronize the target contract events to the clients corresponding to the client identifiers contained in the target contract subscription list by writing diffusion if the target contract is an inactive contract, or if the target contract subscription list and the active client list do not contain different client identifiers.

[0256] The specific implementation of the third synchronization module 118 can be found in the above description. Figure 3 The optional description of step S104 in the corresponding embodiments will not be repeated here.

[0257] Among them, L subscription clients include the target subscription clients;

[0258] The third determination module 114 includes: a third window acquisition unit 1141 and a third mean calculation unit 1142.

[0259] The third window acquisition unit 1141 is used to acquire the sliding window of the number of client events corresponding to the target subscribed client; the sliding window of the number of client events contains the number of client events in P blocks; P is a positive integer; the number of client events in a block refers to the number of contract events corresponding to the target subscribed client contained in a block; the writing window time of the number of client events in P blocks all belong to the target time period;

[0260] The third average calculation unit 1142 is used to perform average calculation on the number of block client events corresponding to the target block and the number of P block client events to obtain the average number of block client events of the target subscription client within the target time period.

[0261] The specific implementation methods of the third window acquisition unit 1141 and the third mean calculation unit 1142 can be found in the above description. Figure 5 The specific description of step S302 in the corresponding embodiments will not be repeated here.

[0262] Among them, L subscription clients include the target subscription clients;

[0263] The fourth determination module 115 includes: a fourth window acquisition unit 1151 and a fourth mean calculation unit 1152.

[0264] The fourth window acquisition unit 1151 is used to acquire the sliding window of the number of subscription contracts corresponding to the target subscription client; the sliding window of the number of subscription contracts contains Q subscription contract quantities; Q is a positive integer; a subscription contract quantity refers to the number of contracts subscribed by the target subscription client when a subscription update request is successfully executed; the writing window time of the Q subscription contract quantities all belong to the target time period;

[0265] The fourth mean calculation unit 1152 is used to perform mean calculation on the number of Q subscription clients to obtain the average number of subscription contracts of the target subscription client within the target time period.

[0266] The specific implementation methods of the fourth window acquisition unit 1151 and the fourth mean calculation unit 1152 can be found in the above description. Figure 5 The specific description of step S303 in the corresponding embodiments will not be repeated here.

[0267] Please see Figure 10 , Figure 10 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 10 As shown above, Figure 9The data processing device 1 in the corresponding embodiment can be applied to a computer device 1000, which may include a processor 1001, a network interface 1004, and a memory 1005. Furthermore, the computer device 1000 may also include a user interface 1003 and at least one communication bus 1002. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen and a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 1005 may also be at least one storage device located remotely from the processor 1001. Figure 10 As shown, the memory 1005, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application.

[0268] In such Figure 10 In the computer device 1000 shown, the network interface 1004 provides network communication elements; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve:

[0269] When consensus is reached on the target block, the target contract event corresponding to the target contract is retrieved from the target block.

[0270] Retrieve the target contract subscription list; the target contract subscription list contains the client identifiers corresponding to the clients that subscribed to the target contract;

[0271] If the target contract is an active contract, and the target contract's subscription list and active client list contain the same client identifier, then the same client identifier is identified as the write diffusion client identifier; the active client list contains the client identifiers corresponding to the active clients;

[0272] The target contract event is synchronized to the client corresponding to the write diffusion client identifier through write diffusion, and to the client corresponding to the read diffusion client identifier through read diffusion. The read diffusion client identifier refers to the client identifier in the target contract subscription list excluding the write diffusion client identifier.

[0273] It should be understood that the computer device 1000 described in the embodiments of this application can execute the foregoing text. Figure 3 , Figure 4 , Figure 5 The description of the data processing method in any corresponding embodiment will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0274] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores a computer program executed by the aforementioned data processing device 1. The computer program includes program instructions, and when the processor executes the program instructions, it can execute the aforementioned... Figure 3 , Figure 4 , Figure 5 The description of the data processing method in any corresponding embodiment is already provided, and therefore will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments related to this application, please refer to the description of the method embodiments of this application.

[0275] The aforementioned computer-readable storage medium can be an internal storage unit of the data processing apparatus or computer device provided in any of the foregoing embodiments, such as a hard disk or memory of the computer device. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer device. Furthermore, the computer-readable storage medium can include both internal and external storage units of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0276] Furthermore, it should be noted that this application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the aforementioned... Figure 3 , Figure 4 , Figure 5 The method provided in any of the corresponding embodiments.

[0277] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0278] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0279] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the foregoing description as a network element. Whether these network elements are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can implement the described network elements using different methods for each specific application, but such implementation should not be considered beyond the scope of this application.

[0280] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data processing method based on blockchain, characterized in that, The method is executed by a blockchain node, and the method includes: When it is determined that the consensus of the target block has been passed, the target contract event corresponding to the target contract is obtained from the target block; Obtain the target contract subscription list corresponding to the target contract; the target contract subscription list contains the client identifiers corresponding to the clients that subscribe to the target contract; If the target contract is an active contract, and the target contract subscription list and the active client list contain the same client identifier, then the same client identifier is identified as the write diffusion client identifier; the active client list contains the client identifiers corresponding to the active clients; The target contract event is synchronized to the client corresponding to the write diffusion client identifier via write diffusion, and to the client corresponding to the read diffusion client identifier via read diffusion; the read diffusion client identifier refers to the client identifier in the target contract subscription list excluding the write diffusion client identifier.

2. The method according to claim 1, characterized in that, The step of synchronizing the target contract event to the client corresponding to the write diffusion client identifier via write diffusion includes: The target contract event is sent to the client corresponding to the write diffusion client identifier, so that the client corresponding to the write diffusion client identifier writes the target contract event into the client event set.

3. The method according to claim 1, characterized in that, The step of synchronizing the target contract event to the client corresponding to the read diffusion client identifier via read diffusion includes: Write the target contract event into the target contract event set associated with the target contract; When a request to pull an event for the target contract is received from the target client, the contract events contained in the target contract event set are identified as pullable contract events, and the pullable contract events are sent to the target client so that the target client writes the pullable contract events into the client event set; the target client belongs to the client corresponding to the read diffusion client identifier.

4. The method according to claim 1, characterized in that, Also includes: Determine the average number of block contract events for the target contract within a target time period; the end time of the target time period is the current system time. The average number of block contract events refers to the average number of contract events corresponding to the target contract contained in the block within the target time period. Determine the average number of subscribers to the target contract during the target time period; The average number of block contract events and the average number of subscribed clients are weighted and summed to obtain the contract activity level corresponding to the target contract. If the contract activity level is greater than or equal to the contract activity level threshold, then the target contract is determined to be an active contract.

5. The method according to claim 4, characterized in that, Determining the average number of block contract events for the target contract within the target time period includes: Obtain a sliding window for the number of contract events corresponding to the target contract; the sliding window for the number of contract events includes the number of block contract events corresponding to M blocks respectively; M is a positive integer; the number of contract events in a block refers to the number of contract events corresponding to the target contract contained in a block; the writing window time for the number of contract events in the M blocks all belongs to the target time period; The average number of block contract events corresponding to the target block and the number of M block contract events is calculated to obtain the average number of block contract events for the target contract within the target time period.

6. The method according to claim 5, characterized in that, Also includes: Add the number of block contract events corresponding to the target block to the contract event count sliding window to obtain a new contract event count sliding window; When the new contract event count sliding window is detected to contain expired block contract event counts, the expired block contract event counts are removed from the new contract event count sliding window. The expired block contract event counts refer to the number of block contract events in the new contract event count sliding window whose write window time does not belong to the new target time period. The end time point in the new target time period is the system time when the new contract event count sliding window is first detected.

7. The method according to claim 4, characterized in that, Determining the average number of subscribed clients for the target contract during the target time period includes: Obtain a sliding window of the number of subscribed clients corresponding to the target contract; the sliding window of the number of subscribed clients contains N numbers of subscribed clients; N is a positive integer; a number of subscribed clients refers to the number of clients subscribed to the target contract when a subscription update request is successfully executed; the writing window time of the N numbers of subscribed clients all belong to the target time period; The average number of subscribers for the target contract during the target time period is obtained by averaging the number of subscribers for the N subscribers.

8. The method according to claim 7, characterized in that, Also includes: When a target subscription update request for the target contract is received, the contract subscription list corresponding to the target contract is updated according to the target subscription update request to obtain an updated contract subscription list; The number of client identifiers contained in the updated contract subscription list is determined as the number of updated subscription clients. The number of updated subscription clients is added to the subscription client count sliding window to obtain a new subscription client count sliding window. When the new subscription client count sliding window is detected to contain expired subscription client counts, the expired subscription client counts are deleted from the new subscription client count sliding window; the expired subscription client counts refer to the number of subscription clients in the new subscription client count sliding window whose writing window time does not belong to the new target time period; the end time point in the new target time period is the system time when the new subscription client count sliding window is first detected.

9. The method according to claim 4, characterized in that, Also includes: Obtain the occupied computing power resources and total computing power resources of the blockchain node; The idle computing resources of the blockchain node are determined based on the occupied computing resources information and the total computing resources information; The default contract activity threshold is adjusted based on the idle computing power resource information to obtain the contract activity threshold.

10. The method according to claim 1, characterized in that, Also includes: Get the subscriber identifiers corresponding to L subscriber clients; L is a positive integer, and a subscription client refers to a client that subscribes to one or more contracts; Determine the average number of block client events for each of the L subscribing clients within the target time period; the end time of the target time period is the current system time. An average number of client events per block refers to the average number of contract events corresponding to a single subscribed client within a block during the target time period. Determine the average number of subscription contracts for each of the L subscription clients during the target time period; The average number of block client events and the average number of subscription contracts for each subscribing client are weighted and summed to obtain the client activity level for each subscribing client. Among the L subscribed clients, those with a client activity level greater than the client activity threshold are identified as active clients, and an active client list is generated based on the client identifiers corresponding to the active clients.

11. The method according to claim 1, characterized in that, Also includes: If the target contract is an inactive contract, or if the target contract subscription list and the active client list do not contain different client identifiers, then the target contract event is synchronized to the client corresponding to the client identifier contained in the target contract subscription list through write diffusion.

12. A data processing device based on blockchain, characterized in that, The device is operated by a blockchain node, and the device includes: The event acquisition module is used to acquire the target contract event corresponding to the target contract from the target block when it is determined that the target block consensus has been passed; The list retrieval module is used to retrieve the target contract subscription list corresponding to the target contract; the target contract subscription list includes client identifiers corresponding to the clients that subscribe to the target contract; The identifier determination module is used to determine the same client identifier as a write diffusion client identifier if the target contract is an active contract and the target contract subscription list and the active client list contain the same client identifier; the active client list contains the client identifiers corresponding to the active clients; The first synchronization module is used to synchronize the target contract event to the client corresponding to the write diffusion client identifier via write diffusion. The second synchronization module is used to synchronize the target contract event to the client corresponding to the read diffusion client identifier via read diffusion; the read diffusion client identifier refers to the client identifier in the target contract subscription list excluding the write diffusion client identifier.

13. A computer device, characterized in that, include: Processor, memory, and network interface; The processor is connected to the memory and the network interface, wherein the network interface is used to provide data communication functions, the memory is used to store program code, and the processor is used to call the program code to execute the method according to any one of claims 1-11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and to execute the method according to any one of claims 1-11.

15. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they can perform the method described in any one of claims 1-11.

Images