CN116383893A

CN116383893A - Block chain data statistics method and system

Info

Publication number: CN116383893A
Application number: CN202310347139.2A
Authority: CN
Inventors: 韩喆
Original assignee: Alipay Labs Singapore Pte Ltd
Current assignee: Advanced Nova Technology Singapore Holdings Ltd
Priority date: 2023-04-03
Filing date: 2023-04-03
Publication date: 2023-07-04

Abstract

The embodiment of the specification discloses a blockchain data statistics method and system. The method is performed by a block link point, comprising: acquiring a blockchain transaction; executing the blockchain transaction and determining the execution state thereof; and in response to the execution state being successful in the transaction, updating one or more pieces of statistical data, and writing the updated one or more pieces of statistical data into the blockchain for storage.

Description

Block chain data statistics method and system

Technical Field

The present disclosure relates to the field of information technologies, and in particular, to a blockchain data statistics method and system.

Background

While more and more transactions are completed on blockchains, corresponding data statistics capabilities are also required. Currently, in order to solve the problem of blockchain data statistics, most of the methods are to backup the data on the chain in a centralized system (such as a traditional database), and then perform the statistics on the backed up data off the chain. This practice of the chain-based centralized system presents a single point of disfigurement (e.g., falsifying data) and fails to provide reliable data services.

In view of this, it is desirable to provide a reliable blockchain data statistics scheme.

Disclosure of Invention

One of the embodiments of the present disclosure provides a blockchain data statistics method. The method is performed by a block link point, comprising: acquiring a blockchain transaction; executing the blockchain transaction and determining the execution state thereof; and in response to the execution state being successful in the transaction, updating one or more pieces of statistical data, and writing the updated one or more pieces of statistical data into the blockchain for storage.

One embodiment of the present disclosure provides a blockchain data statistics system, including an acquisition module and an execution module. The acquisition receiving module is used for acquiring blockchain transactions; the execution module is used for: executing the blockchain transaction and determining the execution state thereof; and in response to the execution state being successful in the transaction, updating one or more pieces of statistical data, and writing the updated one or more pieces of statistical data into the blockchain for storage.

One of the embodiments of the present disclosure provides a blockchain data statistics apparatus, including a processor and a storage device, where the storage device is configured to store instructions, and when the processor executes the instructions, implement a blockchain data statistics method according to any of the embodiments of the present disclosure.

Drawings

The present specification will be further elucidated by way of example embodiments, which will be described in detail by means of the accompanying drawings. The embodiments are not limiting, in which like numerals represent like structures, wherein:

FIG. 1 is a schematic illustration of an application scenario of a blockchain system shown in some embodiments of the present description;

FIG. 2 is an exemplary flow chart of a blockchain data statistics method shown in accordance with some embodiments of the present description;

FIG. 3 is a schematic diagram of providing blockchain data statistics capabilities and query services based on smart contracts, as shown in some embodiments of the present description;

FIG. 4 is an exemplary flow chart of on-chain statistics shown in accordance with some embodiments of the present description;

fig. 5 is an exemplary block diagram of a blockchain data statistics system as shown in some embodiments of the present description.

Detailed Description

In order to more clearly illustrate the technical solutions of the embodiments of the present specification, the drawings that are required to be used in the description of the embodiments will be briefly described below. It is apparent that the drawings in the following description are only some examples or embodiments of the present specification, and it is possible for those of ordinary skill in the art to apply the present specification to other similar situations according to the drawings without inventive effort. Unless otherwise apparent from the context of the language or otherwise specified, like reference numerals in the figures refer to like structures or operations.

It will be appreciated that "system," "apparatus," "unit" and/or "module" as used herein is one method for distinguishing between different components, elements, parts, portions or assemblies of different levels. However, if other words can achieve the same purpose, the words can be replaced by other expressions.

As used in this specification, the terms "a," "an," "the," and/or "the" are not intended to be limiting, but rather are to be construed as covering the singular and the plural, unless the context clearly dictates otherwise. In general, the terms "comprises" and "comprising" merely indicate that the steps and elements are explicitly identified, and they do not constitute an exclusive list, as other steps or elements may be included in a method or apparatus.

A flowchart is used in this specification to describe the operations performed by the system according to embodiments of the present specification. It should be appreciated that the preceding or following operations are not necessarily performed in order precisely. Rather, the steps may be processed in reverse order or simultaneously. Also, other operations may be added to or removed from these processes.

Some basic concepts referred to in this specification will first be described.

In this specification, the meaning of the term "blockchain" (sometimes also simply "chain") is flexible, depending on the particular context. For example, a blockchain may be abbreviated to a blockchain network (a node chain) or simply to blockchain data (or referred to as blockchain storage). The blockchain data may include, among other things, blockdata and status data. Block data is formed by links of blocks (data chains, also referred to as blockchains), and typically does not support modifications (add, delete, change values). Status data (e.g., account storage) supports addition, deletion, and modification, and updates (new, deleted, changed values) of blockchain data are validated after consensus passes. In addition, "uplink" may mean that content or content is written to blockchain data. "on-chain" may mean that the content is included in the blockchain data, or that the result of the operation requires consensus and affects the updating of the blockchain data, and "under-chain" may mean that the content is not included in the blockchain data, or that the result of the operation does not require consensus (nor does it naturally affect the updating of the blockchain data).

Blockchain transactions (abbreviated transactions) may be used to record various types of events and/or data. In some embodiments, the events of the transaction record may include one or more of characterizing the joining of a new node, the withdrawal of a node, the deployment of a smart contract, the transfer, and so forth. In some embodiments, the data of the transaction record may include one or more of an electronic contract, an electronic voucher, an electronic order, registration information, a digital fingerprint, and the like.

The desired code may be executed by a transaction trigger, which may also be referred to as execution of a transaction. For example only, a transaction for recording transfer activity may trigger an update to the account balance of the transfer party, a transaction for logging data may trigger writing data to blockchain storage, a transaction for querying data may trigger querying blockchain data, and so forth.

In some embodiments, execution of the transaction may include invocation of the smart contract, or execution of the transaction may be accomplished by invocation of the smart contract. A smart contract (abbreviated contract) may refer to a digital protocol that is stored in a distributed manner at various nodes in a blockchain system and that may be automatically executed under certain conditions. The smart contract is essentially a piece of code running in a blockchain network for completing business logic assigned by a user. The intelligent contract code (abbreviated as contract code) is stored in the local process after the common knowledge is completed from the created to each block link point, namely the intelligent contract deployment process. After the smart contract is deployed, the blockchain node may automatically read and execute the contract code upon satisfaction of a set trigger condition, such as receipt of a transaction invoking the smart contract (e.g., invoking an interface provided by the contract).

The smart contracts may have corresponding stores, referred to as contract stores. Under the operating mechanism of the blockchain, the contract store is non-tamper-evident as part of the blockchain store. The contract store may include a code portion (i.e., a contract code) and a data portion, wherein the data portion may include values of one or more variables (i.e., contract variables) in the contract code that may change due to invocation of the contract.

The address of the smart contract (abbreviated contract address) may indicate the storage location of the contract store, i.e., the contract address may be used to access the contract store, where access may refer to the addition or deletion of data. The contract store may be considered a contract account, and accordingly, a contract address is an address of the contract account.

Fig. 1 is a schematic diagram of an application scenario of a blockchain system shown in some embodiments of the present description. As shown in fig. 1, the blockchain system 100 may include a blockchain network 110 and a client 120.

The blockchain network 110 may include a plurality of blockchain nodes (simply referred to as nodes), such as node 110-1, node 110-2, node 110-3, node 110-n. In general, one node in the blockchain network 110 may receive transactions broadcast in the blockchain network 110 and generate new blocks based on the received transactions over a period of time. The transactions may be used to initiate events/actions in the blockchain system, e.g., for registering blockchain members, transferring transactions, deploying smart contracts, invoking smart contracts, etc. Each node is caused to generate the same block and add it to the blockchain (datalink) by running a consensus mechanism. That is, the consensus mechanism may ensure that the blockchains stored by each node remain consistent.

Upon receipt of the transaction, the blockchain node may perform the associated operations according to the transaction content, i.e., the execution of the transaction. For example, execution of the transfer transaction includes transferring a pass between accounts. As another example, the execution of a transaction to deploy a smart contract includes deploying the smart contract on a blockchain. As another example, execution of a transaction invoking a smart contract includes invoking (executing) a smart contract deployed on a chain. Execution of the transaction may trigger an update of the status data. By running a consensus mechanism, each node can update the state data in a consistent manner. That is, the consensus mechanism may also ensure that the state data stored by each node remains consistent.

The client 120 may generate and upload transactions to the blockchain network 110 to cause the transactions to be broadcast in the blockchain network 110, i.e., initiate the transactions. Each consensus node may generate a new block based on transactions received over a period of time. In some embodiments, nodes in the blockchain network 110 may also initiate transactions.

The client 120 may also initiate a query request to nodes (any of which may act as a server) in the blockchain network 110. In some embodiments, the query request may be issued in the form of a transaction, which means the execution of the transaction and the operation of the consensus mechanism. In some embodiments, the query request may also be issued in a non-transacted form, i.e., without executing a transaction and running a consensus mechanism, which is less costly to implement and suitable for use in high frequency query scenarios.

In some embodiments, the client 120 and blockchain node may be integrated on the same device. In some embodiments, the client 120 may join the blockchain network 110 as a consensus node (full-scale node) or may join the blockchain network 110 as a lightweight node without participating in the consensus. Typically, full-scale nodes hold more blockchain data (e.g., block headers and blockvolumes) to participate in the consensus, while lightweight nodes may hold only some critical blockchain data (e.g., block headers) and rely on full-scale nodes to verify the authenticity of content (e.g., transactions) on the chain.

Each consensus node may receive transactions to deploy intelligent contracts uploaded to blockchain network 110 and write contract code to blockchain data after running the consensus mechanism to implement deployment of intelligent contracts on the blockchain. For deployed smart contracts, the consensus nodes may receive transactions to invoke smart contracts uploaded to blockchain network 110 and invoke smart contracts that have been deployed on the chain.

For more details on the blockchain system 100 and its components, reference may be made to FIG. 2 and its associated description.

In some embodiments, the nodes in the client 120/blockchain network 110 may include various types of computing devices, such as smartphones, laptops, desktops, servers, and the like.

In some embodiments, the servers may be stand-alone servers or groups of servers, which may be centralized or distributed. In some embodiments, the server may be regional or remote. In some embodiments, the server may execute on a cloud platform. For example, the cloud platform may include one of a private cloud, a public cloud, a hybrid cloud, a community cloud, a decentralized cloud, an internal cloud, or the like, or any combination thereof.

Fig. 2 is an exemplary flow chart of a blockchain data statistics method as shown in some embodiments of the present description. The process 200 may be performed by any blockchain node in the blockchain network 110, and in particular, may be performed by the blockchain data statistics system 500 implemented on blockchain nodes as shown in fig. 5. As shown in fig. 2, the process 200 may include the following steps.

Step 210, a blockchain transaction is obtained. In some embodiments, step 210 may be performed by the acquisition module 510 shown in fig. 5.

In some embodiments, any blockchain node executing the flowchart 200 may receive the blockchain transaction from the client 120 or other blockchain node. In other embodiments, any blockchain node executing the flowchart 200 may generate the blockchain transaction itself, and then the blockchain node may broadcast the blockchain transaction in the blockchain network.

In some embodiments, execution of the blockchain transaction may be accomplished by invoking an intelligent contract, and accordingly, the blockchain transaction may include a contract address of the target transaction contract such that the blockchain link point invokes the target transaction contract in accordance with the contract address of the target transaction contract.

Step 220, executing the blockchain transaction and determining its execution status. In some embodiments, step 220 may be performed by the execution module 520 shown in fig. 5.

The execution status may be transaction success or transaction failure. The execution state may be determined by monitoring certain events. For example, in response to monitoring that the blockchain transaction writes blocks through consensus, the blockchain node may determine that the execution status is transaction successful.

In some embodiments, the blockchain transaction may include a field for indicating its execution status (hereinafter referred to as a transaction status field), and the blockchain node may be updated in real-time. For example, when a blockpass consensus is written to in response to monitoring the blockchain transaction, the blockchain node may update a transaction status field in the blockchain transaction to transaction success. That is, a blockchain node may read its execution status from the blockchain transaction.

As previously described, in some embodiments, a blockchain node may invoke a target transaction contract in the blockchain transaction to execute the blockchain transaction and obtain its execution status based on the contract address of the target transaction contract.

And step 230, in response to the execution status being successful, updating one or more pieces of statistical data, and writing the updated one or more pieces of statistical data into the blockchain for storage. In some embodiments, step 230 may be performed by the execution module 520 shown in fig. 5.

On one hand, the validity of the statistical data can be ensured by binding the data statistics with the transaction execution state. On the other hand, because the statistical data is written into the blockchain storage, each node needs to make consensus on the statistical data, the situation of single point disuse (counterfeiting of the statistical data) can be effectively avoided, and therefore the authenticity of the statistical data is ensured.

It should be noted that, the blockchain has consistency, and the consistency of the blockchain can ensure that the updating and writing of the one or more pieces of statistical data has consistency of results with the execution of the blockchain transaction. In particular, the updating and writing of the one or more statistics may be included in the execution of the blockchain transaction (e.g., in the invocation of the target contract), and if the final execution state of the blockchain transaction is successful, the one or more statistics may also be successfully updated and written to the blockchain storage; if the final execution state of the blockchain transaction is a transaction failure, then the one or more statistics will eventually also update as failed (of course, there is no write blockchain storage). In practical applications, the following situations may occur: firstly, after the execution state is changed to be successful in transaction, the block link point successfully updates one or more pieces of statistical data, and successfully writes the updated one or more pieces of statistical data into a block chain for storage; secondly, when the execution state is changed to the transaction failure, the block chain node refuses to update the statistical data; and thirdly, after the execution state is changed to the successful transaction, the block link point fails to update one or more pieces of statistical data successfully, or fails to write the updated one or more pieces of statistical data into the block chain for storage, and the block chain node can roll back the block chain transaction executed before and finally re-determine the execution state as the execution failure.

The statistical data may be defined according to actual needs, and the number and definition of the statistical data are not particularly limited in this specification. For example only, in some embodiments, the blockchain transaction may include a user identification of a transaction party and a transaction amount, and the blockchain node may update the total transaction amount and the total transaction amount for the transaction party based on the user identification and the transaction amount for the transaction party. For example, when the blockchain transaction includes a user identification of transaction party a (noted user_a) and a transaction amount (assumed to be 100 yuan), the blockchain node may accordingly increase the total transaction amount of transaction party a by 1 and increase the total transaction amount of transaction party a by 100 yuan. It will be appreciated that the total transaction amount and the total transaction amount for any transaction party may be stored in association with its user identification, in particular the user identification of the transaction party may be used as a key and the total transaction amount for the transaction party may be used as a value, i.e. the total transaction amount and the total transaction amount for the transaction party may be stored as a key-value pair.

In some embodiments, a smart contract for data statistics (hereinafter referred to as a data contract) may be pre-deployed, based on which a blockchain node may invoke a data contract to update one or more pieces of statistics data when the execution state is that a transaction is successful, and write the updated one or more pieces of data to blockchain storage.

In some embodiments, blockchain data statistics may be implemented through nested invocations of intelligent contracts, where transactional execution is implemented through invocations of transactional contracts, which may further invoke data contracts. In particular, the blockchain transaction may include a contract address of a target transaction contract, which may include a contract address of a target data contract. Based on this, the blockchain node may invoke the target transaction contract in the blockchain transaction to execute the blockchain transaction and obtain its execution status according to the contract address of the target transaction contract. And the blockchain node can also call the target data contract according to the contract address of the target data contract when the execution state is that the transaction is successful through the target transaction contract so as to update one or more pieces of statistical data, and write the updated one or more pieces of statistical data into the blockchain for storage. By deploying two special purpose contracts, transaction logic and data related logic (such as data statistics logic and data query logic) can be decoupled, so that the modularized development and maintenance of the system are facilitated.

In some embodiments, the target data contract may have an authentication mechanism built into it. In particular, the target data contract may also be used to: determining whether the target transaction contract belongs to a predetermined one or more authorized transaction contracts; and updating one or more statistics in response to the target transaction contract belonging to the one or more authorized transaction contracts, and writing the updated one or more statistics to a blockchain store. That is, under the authentication mechanism, the target transaction contract only allows the authorized transaction contract to invoke its data statistics capabilities, e.g., neither unauthorized transaction contracts nor other users (e.g., transaction parties) can trigger the updating of statistics via transactions. In this way, the target data contract can be prevented from being abused, and the reliability of the statistical data is ensured. For example, an attacker maliciously deploying an intelligent contract, and invoking a transaction for that contract is not the desired (acknowledged) source of statistics, resulting in erroneous updates of the statistics.

In some embodiments, the target data contract may include a contract address of a predetermined one or more authorized-trade contracts. In addition to the foregoing, the blockchain transaction may include an address of the target transaction contract, based on which the blockchain node may determine whether the contract address of the one or more authorized-transaction contracts includes the contract address of the target transaction contract, thereby determining whether the target transaction contract belongs to a predetermined one or more authorized-transaction contracts. Authentication can be quickly achieved by checking the contract address.

Of course, the authentication mechanism may be implemented in other ways. For example, the contract address of the predetermined one or more authorized-trade contracts may be stored outside of the target data contract, and accordingly, the target data contract may include an index of the contract address of the one or more authorized-trade contracts, i.e., the blockchain node may query (acquire) the contract address of the one or more authorized-trade contracts based on the index.

In some embodiments, the blockchain storage may include a contract storage, and the blockchain node may write the updated one or more statistics to the contract storage of the target data contract. That is, the contract account of the target data contract may store statistical data associated with the transaction party in addition to the contract code for updating the statistical data. For example only, for any party, the contract store of the target data contract may include a key value pair of a user identification of the party and a total transaction amount of the party, where the user identification may be a key (key) and the total transaction amount may be values (value).

In addition to providing data statistics capabilities, the target data contract may also provide data query services. In some embodiments, the target data contract may be provided with a data update interface for triggering the target data contract to update one or more items of statistical data and a data query interface for triggering the target data contract to execute a query associated with one or more items of statistical data. That is, a blockchain node may invoke a data update interface of the target data contract to update one or more statistics and write the updated one or more statistics to a blockchain store (e.g., to a contract store of the target data contract), and may invoke a data query interface of the target data contract to perform a query associated with the one or more statistics.

It will be appreciated that with reference to the foregoing embodiments, the data update interface of the target data contract may only allow for invocation by authorized trade contracts (e.g., the target trade contract), however, the data query interface of the target data contract may allow for invocation by all users.

The inquirer may upload an inquiry request to the blockchain network through the client 120. The blockchain node may also initiate the query itself. In some embodiments, the inquirer may directly inquire the target statistics, e.g., the transaction party may inquire about the total transaction amount and/or the total transaction amount itself. In some embodiments, the inquirer may inquire about the processing result based on the target statistics, for example, the transaction side may inquire whether the total transaction amount of itself reaches a preset number of times and/or whether the total transaction amount of itself reaches a preset amount.

In some embodiments, queries associated with one or more statistics may trigger consensus, e.g., the user side 120 may initiate a query transaction requesting query target statistics. In other embodiments, queries associated with one or more statistics may not trigger consensus, thus saving query costs and improving query efficiency. Specifically, upon receiving a query request, a blockchain node may invoke a data query interface of the target data contract based on the data query request to obtain a query result corresponding to the data query request based on the one or more items of statistical data. Further, the blockchain node may return the query result to the user terminal 120 of the querying party. Of course, the blockchain node may also directly invoke the data query interface of the target data contract to obtain the query result based on the one or more items of statistics.

Features of various embodiments provided herein may be combined without conflict. As illustrated below in connection with fig. 3 and 4.

As shown in fig. 3, each user (e.g., bank, financial institution) may communicate with the blockchain network, which may include invoking a target transaction contract (initiating blockchain transactions) and initiating a query request associated with the statistics, where the communication may be without the assistance of a centralized system or other user.

A target transaction contract and a target data contract are deployed in the blockchain network. It will be appreciated that a target transaction contract and a target data contract may be deployed on each blockchain node, the simplified process of which is illustrated in fig. 3. The contract account of the target transaction contract (target transaction contract account for short) may include a history transaction list and a contract address of the target data contract (target data contract address for short). In response to the execution status of the blockchain transaction being a successful transaction, the target transaction contract may automatically invoke the target data contract to trigger data statistics (trigger the updating and the uplink of one or more statistics).

The contract account of the target data contract (simply referred to as the target data contract account) may be used to maintain statistics for each user. As the execution state becomes transaction successful, one or more statistics are updated. Any user can query the target statistical data by calling the contract interface, and the decentralised blockchain system can effectively avoid the problem that the statistical data is lost or tampered.

The target data contract may provide a data update interface (which may be referred to as update (addr)) and a data query interface (which may be referred to as query (addr)). The data update interface may only allow the target transaction contract to be invoked (i.e., the target transaction contract is an authorized transaction contract of the target data contract), for example, after obtaining information such as an amount of money, a user, etc. in a blockchain transaction whose execution state is successful, the target data contract may update corresponding statistical data (such as a total transaction amount and a total transaction amount of the user) in persistent data in the contract. The statistics associated with one or more users may be stored in tabular form, which may be noted as map < addr, stat >. The query interface may allow for invocation by all users.

As shown in fig. 4, the flow of on-chain statistics may include the following steps.

The initializing step may include deployment of the target transaction contract and deployment of the target data contract. While deploying the target data contract, a data update interface may be provided that only allows the target transaction contract to call the target data contract.

The target data contract has an initialization field (not shown) for setting the contract address of the target transaction contract deployed in the initializing step, when the target data contract is initialized. The data update interface of the target data contract requires authentication, only allows the target transaction contract to be invoked, and does not allow other users or other contracts to be invoked. The manner of determining whether the caller is an authorized-trade contract may include determining whether the address of the caller is the same as [ authorized-trade contract address ].

After the target data contract is deployed, the contract address of the target data contract needs to be written into the target transaction contract. The purpose of writing the address ensures that each time a new transaction (the execution state is successful) is completed by a subsequent target transaction contract, the target transaction contract is automatically called to trigger the update and the uplink of the statistical data.

After contract deployment is completed, logic of each data statistics update is as follows: after a user submits a new transaction, a target transaction contract on a chain is called; then, executing the current transaction according to the logic of the target transaction contract and monitoring the execution state of the current transaction; if the current transaction is monitored to be successful, the target transaction contract may invoke a data update interface of the target data contract during invocation of the target transaction contract, trigger an update of one or more statistics to be uplink, e.g., update the total transaction amount and the total transaction amount of the current transaction party, and write the (updated) total transaction amount and the total transaction amount of the current transaction party to the target transaction contract account.

The logic of the target trade contract to invoke the target data contract after determining the execution status of the trade (success for the trade) is logic that is preset in the target trade contract upon deployment of the target trade contract. The update of the current transaction execution status monitoring and statistics in the update target transaction contract is performed in the same contract call, either successful or failed in view of the caller.

The update interface of the target data contract has authentication logic. It checks the contract address of the caller and if it is found that the address is not the address registered in the second previous step, it refuses to process the subsequent flow (update of statistics is up-link). In this way, other on-chain contracts can be prevented from becoming disliked.

It should be noted that the above description of the flow is only for the purpose of illustration and description, and does not limit the application scope of the present specification. Various modifications and changes to the flow may be made by those skilled in the art under the guidance of this specification. However, such modifications and variations are still within the scope of the present description.

Fig. 5 is an exemplary block diagram of a blockchain data statistics system as shown in some embodiments of the present description. The blockchain data statistics system 500 may be implemented on blockchain nodes. As shown in fig. 5, the blockchain data statistics system 500 may include an acquisition module 510 and an execution module 520.

The acquisition module 510 may be used to acquire blockchain transactions.

The execution module 520 may be configured to: executing the blockchain transaction and determining the execution state thereof; and in response to the execution state being successful in the transaction, updating one or more pieces of statistical data, and writing the updated one or more pieces of statistical data into the blockchain for storage.

In some embodiments, the blockchain data statistics system 500 may further include a query module 530, the query module 530 may be configured to: receiving a data query request; invoking a data query interface of the target data contract based on the data query request to obtain a query result corresponding to the data query request based on the one or more items of statistical data; and returning the query result.

For more details on the blockchain data statistics system 500 and its components, reference may be made to fig. 2 and its related description.

It should be understood that the system shown in fig. 5 and its modules may be implemented in a variety of ways. For example, in some embodiments, the system and its modules may be implemented in hardware, software, or a combination of software and hardware. Wherein the hardware portion may be implemented using dedicated logic; the software portions may then be stored in a memory and executed by a suitable instruction execution system, such as a microprocessor or special purpose design hardware. Those skilled in the art will appreciate that the methods and systems described above may be implemented using computer executable instructions and/or embodied in processor control code, such as provided on a carrier medium such as a magnetic disk, CD or DVD-ROM, a programmable memory such as read only memory (firmware), or a data carrier such as an optical or electronic signal carrier. The system of the present specification and its modules may be implemented not only with hardware circuits such as very large scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, etc., or programmable hardware devices such as field programmable gate arrays, programmable logic devices, etc., but also with software executed by various types of processors, for example, and with a combination of the above hardware circuits and software (e.g., firmware).

It should be noted that the above description of the system and its modules is for convenience of description only and is not intended to limit the present description to the scope of the illustrated embodiments. It will be appreciated by those skilled in the art that, given the principles of the system, various modules may be combined arbitrarily or a subsystem may be constructed in connection with other modules without departing from such principles. For example, in some embodiments, the execution module 520 may be a module, and may further include a status monitoring module and a data updating module, where the status monitoring module may be configured to monitor the status of execution of the transaction, and the data updating module may be configured to update one or more statistics and write the updated one or more statistics to the blockchain storage. Such variations are within the scope of the present description.

Possible benefits of embodiments of the present description include, but are not limited to: (1) The block chain data statistics is carried out on the chain, and the statistical data is stored on the chain in a lasting mode, so that the reliability of the statistical data can be effectively guaranteed, and for example, the risk of single-point wrought (counterfeit data) can be effectively avoided; (2) The updating uplink of the statistical data is bound with the transaction execution by utilizing the consistency of the block chain, so that the consistency of the results of the updating uplink and the transaction execution is ensured, and the validity of the statistical data is ensured; (3) An authentication mechanism is arranged in the contract, so that the data statistics capability of the contract can be prevented from being abused, and the reliability of the statistics data is ensured; (4) Queries associated with the statistics may not trigger consensus, saving query costs and improving query efficiency. It should be noted that, the advantages that may be generated by different embodiments may be different, and in different embodiments, the advantages that may be generated may be any one or a combination of several of the above, or any other possible advantages that may be obtained.

While the basic concepts have been described above, it will be apparent to those skilled in the art that the foregoing detailed disclosure is by way of example only and is not intended to be limiting of the embodiments of the present disclosure. Although not explicitly described herein, various modifications, improvements, and adaptations to the embodiments of the present disclosure may occur to one skilled in the art. Such modifications, improvements, and modifications are suggested in the present description examples, and therefore, are intended to fall within the spirit and scope of the example embodiments of this description.

Meanwhile, the specification uses specific words to describe the embodiments of the specification. Reference to "one embodiment," "an embodiment," and/or "some embodiments" means that a particular feature, structure, or characteristic is associated with at least one embodiment of the present description. Thus, it should be emphasized and should be appreciated that two or more references to "an embodiment" or "one embodiment" or "an alternative embodiment" in various positions in this specification are not necessarily referring to the same embodiment. Furthermore, certain features, structures, or characteristics of one or more embodiments of the present description may be combined as suitable.

Furthermore, those skilled in the art will appreciate that aspects of the embodiments of the specification can be illustrated and described in terms of several patentable categories or conditions, including any novel and useful processes, machines, products, or compositions of matter, or any novel and useful improvements thereof. Accordingly, aspects of the embodiments of this specification may be performed entirely by hardware, entirely by software (including firmware, resident software, micro-code, etc.) or by a combination of hardware and software. The above hardware or software may be referred to as a "data block," module, "" engine, "" unit, "" component, "or" system. Furthermore, aspects of embodiments of the present description may take the form of a computer product, including computer-readable program code, embodied in one or more computer-readable media.

The computer storage medium may contain a propagated data signal with the computer program code embodied therein, for example, on a baseband or as part of a carrier wave. The propagated signal may take on a variety of forms, including electro-magnetic, optical, etc., or any suitable combination thereof. A computer storage medium may be any computer readable medium that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code located on a computer storage medium may be propagated through any suitable medium, including radio, cable, fiber optic cable, RF, or the like, or a combination of any of the foregoing.

Computer program code necessary for operation of portions of embodiments of the present description may be written in any one or more programming languages, including an object oriented programming language such as Java, scala, smalltalk, eiffel, JADE, emerald, C ++, c#, vb net, python and the like, a conventional programming language such as C language, visualBasic, fortran2003, perl, COBOL2002, PHP, ABAP, dynamic programming languages such as Python, ruby and Groovy, or other programming languages and the like. The program code may execute entirely on the user's computer or as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or processing device. In the latter scenario, the remote computer may be connected to the user's computer through any form of network, such as a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet), or the use of services such as software as a service (SaaS) in a cloud computing environment.

Furthermore, the order in which the elements and sequences are presented in the examples, the use of numerical letters, or other designations are used, unless specifically indicated in the claims, is not intended to limit the order in which the steps of the examples and methods are presented. While certain presently useful inventive embodiments have been discussed in the foregoing disclosure, by way of various examples, it is to be understood that such details are merely illustrative and that the appended claims are not limited to the disclosed embodiments, but, on the contrary, are intended to cover all modifications and equivalent arrangements included within the spirit and scope of the embodiments of the present disclosure. For example, while the system components described above may be implemented by hardware devices, they may also be implemented solely by software solutions, such as installing the described system on an existing processing device or mobile device.

Similarly, it should be noted that in order to simplify the description of embodiments disclosed herein and thereby facilitate an understanding of one or more inventive embodiments, various features are sometimes grouped together in a single embodiment, figure, or description thereof. This method of disclosure, however, is not intended to imply that more features than are required by the embodiments of the present disclosure. Indeed, less than all of the features of a single embodiment disclosed above.

Each patent, patent application publication, and other material, such as articles, books, specifications, publications, documents, etc., referred to in this specification is incorporated herein by reference in its entirety. Except for application history documents that are inconsistent or conflicting with the content of this specification, documents (currently or hereafter attached to this application) which have limitations on the broadest scope of the claims of this application are also excluded. It is noted that, if the description, definition and/or use of a term in an attached material in this specification does not conform to or conflict with what is described in this specification, the description, definition and/or use of the term in this specification controls.

Finally, it should be understood that the embodiments described in this specification are merely illustrative of the principles of the embodiments of this specification. Other variations are also possible within the scope of the embodiments of the present description. Thus, by way of example, and not limitation, alternative configurations of embodiments of the present specification may be considered as consistent with the teachings of the present specification. Accordingly, the embodiments of the present specification are not limited to only the embodiments explicitly described and depicted in the present specification.

Claims

1. A method of blockchain data statistics, the method performed by a blockchain link point, comprising:

acquiring a blockchain transaction;

executing the blockchain transaction and determining the execution state thereof;

and in response to the execution state being successful in the transaction, updating one or more pieces of statistical data, and writing the updated one or more pieces of statistical data into the blockchain for storage.

2. The method of claim 1, wherein the blockchain transaction includes a contract address of a target transaction contract, the target transaction contract including a contract address of a target data contract;

the executing the blockchain transaction and determining its execution status includes:

invoking the target transaction contract according to the contract address of the target transaction contract in the blockchain transaction to execute the blockchain transaction and obtain the execution state of the blockchain transaction;

the responding to the execution state being successful in transaction, updating one or more pieces of statistical data, and writing the updated one or more pieces of statistical data into a blockchain for storage, comprising:

and when the execution state is successful transaction, calling the target data contract according to the contract address of the target data contract to update one or more pieces of statistical data, and writing the updated one or more pieces of statistical data into a blockchain for storage.

3. The method of claim 2, wherein the target data contract is further to:

determining whether the target transaction contract belongs to a predetermined one or more authorized transaction contracts; and updating one or more statistics in response to the target transaction contract belonging to the one or more authorized transaction contracts, and writing the updated one or more statistics to a blockchain store.

4. The method of claim 3, wherein the target data contract further includes a contract address of a predetermined one or more authorized-trade contracts, the determining whether the predetermined one or more authorized-trade contracts includes the target trade contract comprising: determining whether the contract address of the one or more authorized-trade contracts includes the contract address of the target trade contract.

5. The method according to claim 2, wherein the target data contract is provided with a data update interface for triggering the target data contract to perform the updating of one or more statistics and writing the updated one or more statistics to a blockchain store;

the target data contract is further provided with a data query interface for triggering the target data contract to execute a query associated with one or more items of statistical data.

6. The method as recited in claim 5, further comprising:

receiving a data query request;

invoking a data query interface of the target data contract based on the data query request to obtain a query result corresponding to the data query request based on the one or more items of statistical data;

and returning the query result.

7. The method of claim 2, wherein the blockchain store comprises a contract store, the writing the updated one or more items of statistical data to the blockchain store comprising: writing the updated one or more pieces of statistical data into a contract storage of the target data contract.

8. The method of claim 1, wherein the updating, writing of the one or more statistics is consistent with execution of the blockchain transaction.

9. The method of claim 8, wherein the updating and writing of the one or more statistics is performed during execution of the blockchain transaction.

10. The method of claim 1, wherein the blockchain transaction includes a user identification of a transaction party and a transaction amount, and wherein updating one or more statistics includes: the total transaction amount and the total transaction amount for the transaction party are updated based on the user identification and the transaction amount for the transaction party.

11. A blockchain data statistics apparatus comprising a processor and a storage device for storing instructions that when executed by the processor implement the blockchain data statistics method of any of claims 1-10.

12. The block chain data statistics system is characterized by comprising an acquisition module and an execution module;

the acquisition module is used for acquiring a blockchain transaction;

the execution module is used for: executing the blockchain transaction and determining the execution state thereof; and in response to the execution state being successful in the transaction, updating one or more pieces of statistical data, and writing the updated one or more pieces of statistical data into the blockchain for storage.

13. The system of claim 12, further comprising a query module to:

receiving a data query request;

and returning the query result.