Data management method based on blockchain system, and blockchain node

Abstract

A data management method based on a blockchain system, and a blockchain node. The method is executed by a blockchain node, and comprises: receiving a first transaction for calling a first contract, wherein the first transaction is used for registering first data; executing the first contract according to the first transaction, and generating a unique first identifier in a blockchain system, so as to use the first identifier as an identifier of the first data; and storing the first identifier in a contract state of the first contract.

Description

Data management method and blockchain node based on blockchain system

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on July 31, 2023, with application number 202310956046.X and application name “Data management method and blockchain node based on blockchain system”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The embodiments of this specification belong to the field of blockchain technology, and in particular to a data management method and blockchain node based on a blockchain system. Background Art

[0003] Blockchain is a novel application model for computer technologies, including distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. In a blockchain system, data blocks are linked sequentially in chronological order to form a chain-like data structure, cryptographically guaranteeing an unalterable and unforgeable distributed ledger. Due to its decentralized, tamper-proof, and autonomous nature, blockchain is gaining increasing attention and application.

[0004] Summary of the Invention

[0005] The purpose of the present invention is to provide a data management method based on a blockchain system to improve the management of data in the blockchain.

[0006] In a first aspect, this specification provides a data management method based on a blockchain system, wherein a first contract is deployed in the blockchain system, and the method is executed by a blockchain node, comprising:

[0007] receiving a first transaction invoking the first contract, where the first transaction is used to register first data;

[0008] executing the first contract according to the first transaction, and generating a first identifier unique in the blockchain system to be used as an identifier of the first data;

[0009] The first identifier is stored in the contract state of the first contract.

[0010] A second aspect of this specification provides a blockchain node in a blockchain system, wherein a first contract is deployed in the blockchain system, and the blockchain node includes:

[0011] A receiving unit, configured to receive a first transaction for invoking the first contract, where the first transaction is used to register first data;

[0012] a generating unit, configured to execute the first contract according to the first transaction, and generate a first identifier that is unique in the blockchain system to be used as an identifier of the first data;

[0013] A storage unit is used to store the first identifier in the contract state of the first contract.

[0014] A third aspect of this specification provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the method described in the first aspect.

[0015] A fourth aspect of this specification provides a blockchain node, comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in the first aspect is implemented.

[0016] In the solution provided in the embodiments of this specification, by generating a unique identifier for data based on a contract, the global uniqueness of the data identifier can be guaranteed even in a scenario of multi-party data processing, thereby facilitating multi-party data processing of the data. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0018] FIG1 is a diagram of a blockchain architecture in one embodiment;

[0019] FIG2 is a schematic diagram of a business scenario provided by an embodiment of this specification;

[0020] FIG3 is a flow chart of a data management method according to an embodiment of the present specification;

[0021] FIG4 is a flow chart of a method for updating data attributes according to an embodiment of the present specification;

[0022] FIG5 is a flow chart of a method for querying data information corresponding to a data identifier in an embodiment of this specification;

[0023] FIG6 is an architectural diagram of a blockchain node in a blockchain system according to an embodiment of this specification. DETAILED DESCRIPTION

[0024] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments derived by those skilled in the art based on the embodiments in this specification without creative effort shall fall within the scope of protection of this specification.

[0025] Figure 1 illustrates a blockchain architecture diagram in one embodiment. In the blockchain architecture diagram shown in Figure 1 , the blockchain system includes N nodes, with nodes 1 through 8 schematically illustrated in Figure 1 . The lines connecting the nodes schematically represent P2P (peer-to-peer) connections, such as TCP connections, for transmitting data between nodes. These nodes can store the full ledger, i.e., the status of all blocks and all accounts. Each node in the blockchain can generate the same state in the blockchain by executing the same transactions, and each node in the blockchain can store the same state database.

[0026] A transaction in the blockchain field can refer to a task unit executed and recorded in the blockchain. A transaction typically includes a sender field (From), a receiver field (To), and a data field (Data). In the case of a transfer transaction, the From field indicates the address of the account initiating the transaction (i.e., initiating a transfer task to another account), the To field indicates the address of the account receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount.

[0027] Blockchains offer smart contract functionality. Smart contracts on blockchains are contracts that can be triggered and executed by transactions within the blockchain system. Smart contracts can be defined in code. Calling a smart contract on a blockchain involves initiating a transaction to the smart contract address, allowing each node in the blockchain to execute the smart contract code in a distributed manner.

[0028] In a contract deployment scenario, for example, Bob sends a transaction containing information about creating a smart contract (i.e., deploying a contract) to the blockchain shown in Figure 1. The transaction's data field includes the code for the contract to be created (such as bytecode or machine code), and the transaction's to field is empty, indicating that the transaction is for contract deployment. After the nodes reach consensus through a consensus mechanism, they determine the contract address "0x6f8ae93..." Each node adds a contract account corresponding to the smart contract's contract address to the state database, allocates state storage corresponding to the contract account, stores the contract code, and saves the hash value of the contract code in the contract's state storage, thus successfully creating the contract.

[0029] In the contract invocation scenario, for example, Bob sends a transaction to invoke a smart contract to the blockchain shown in Figure 1. The transaction's "from" field is the address of the account of the transaction initiator (Bob), the "to" field is the aforementioned "0x6f8ae93...", the address of the invoked smart contract, and the transaction's "data" field includes the method and parameters for invoking the smart contract. After consensus is reached on the blockchain, each node in the blockchain can execute the transaction, thereby executing the contract and updating the state database based on the contract's execution.

[0030] Data is a record and depiction of the real world. Valuable information can be extracted from data through processing and refinement. The efficient circulation of data elements is crucial for fully realizing the value of data. A key step in the circulation of data elements is data identification. Traditional data identification solutions can already automatically identify static data and processed output data. However, these solutions only address data processing flows involving a single party, requiring only internal confirmation from a single party for data identification. Data identification becomes a challenge in multi-party data processing, especially in scenarios such as federated learning, where multiple parties jointly process data from all parties. Traditional data identification solutions can only identify the data of one party, and data from different parties may overlap.

[0031] This paper proposes a data management solution based on blockchain smart contracts. By automatically completing the data identification generation process through smart contracts, globally unique data identifiers can be generated for different participants. That is, the data identifiers of multiple participants are managed uniformly, so that there is no overlap in the data identifiers generated for different participants. Therefore, it is suitable for scenarios such as federated learning.

[0032] FIG2 is a schematic diagram of a business scenario provided by an embodiment of this specification. As shown in FIG2 , a data management contract (hereinafter referred to as contract C1) for data management is pre-deployed in the blockchain. This smart contract is established based on the data management solution in the embodiment of this specification and can be used to generate a unique identifier for data. It can also be used to perform management operations such as relationship tracing and attribute derivation between data. The data holder device 101 or the data holder device 102 can send a transaction to the blockchain to call contract C1. The blockchain node can generate a unique identifier for the data holder's data based on the transaction and store the unique identifier of the data and various attribute information corresponding to the data in the contract state of contract C1. In the embodiment of this specification, when the data holder device 101 and the data holder device 102 respectively send a transaction to the blockchain to call contract C1 to generate identifiers for the first data of the data holder device 101 and the second data of the data holder device 102, since the unique identifiers of the first data and the second data in the blockchain are generated by contract C1 respectively, there will be no duplication of the identifiers of the first data and the second data. Therefore, the data identifiers generated in this way can be used, for example, for federated learning between the participant corresponding to device 101 and the participant corresponding to device 102. Data holder device 101 or data holder device 102 can also update the attribute information corresponding to the data identifier by sending a transaction to the blockchain to invoke contract C1. Data processor device 20 can process data by sending transactions to the blockchain and generate data identifiers for newly generated data during the data processing process by invoking contract C1. Data consumer device 30 can query the data identifier and its corresponding attribute information from the blockchain.

[0033] The data management scheme in the embodiments of this specification will be described below.

[0034] Figure 3 is a flow chart of a data management method according to an embodiment of this specification. As shown in Figure 3, the method can be executed by a user device and a blockchain system. In one embodiment, the user device can be a data holder device 101, which registers its data by sending a transaction to the blockchain system. In another embodiment, the user device can be a data processor device 20, which processes data by invoking, for example, contract C2 to generate new data. Contract C2 includes a call to contract C1, and the generated new data can be registered in the blockchain system through contract C1.

[0035] Specifically, in step S301, the user device sends a transaction to the blockchain system to call contract C1 for registering data.

[0036] In one embodiment, the data holder device 101 sends a transaction Tx1 to the blockchain system. In this case, the From field of the transaction Tx1 is, for example, the account of the holder of the data (e.g., data D1) (e.g., Alice's account), the To field of the transaction Tx1 is the contract address of the contract C1, and the Data field of the transaction Tx1 includes, for example, the registration function of the contract C1 and the parameters passed to the registration function.

[0037] The input parameters may include, for example, a list of attributes of the data D1 to be registered. The attribute list may include descriptive information, version information, authorization information, usage restriction information, etc. of the data D1 in the form of key-value pairs. The attribute list may include an attribute marked "inherent required" to indicate that the sub-data of the data D1 must inherit the marked attribute.

[0038] The incoming parameters may also include a parent data ID list for the data D1 to be registered. This parent data ID list includes a list of IDs for the parent data of data D1. Based on the attributes of each parent data recorded in the contract status of contract C1, the attributes marked as "inherent required" for each parent data can be obtained. These attributes marked as "inherent required" are the attributes that data D1 must inherit.

[0039] In another embodiment, the data processing party device 20 sends transaction Tx2 to the blockchain system. The From field of transaction Tx2 is, for example, the account of the data processing party, and the to field of transaction Tx2 is the contract address of contract C2. Contract C2 is used to process two data in the contract state of contract C2, for example, adding two data D2 and D3 to obtain a new data D4. The registration function of contract C1 can be called in contract C2 to generate the data identifier of data D4 through contract C1. Among them, the input parameters of the registration function can be preset in contract C2, such as the attribute list, the parent data identification list, etc., to constitute the attributes of the newly generated data (such as data D4). Or contract C2 can determine the input parameters of the registration function based on the input parameters of contract C2, wherein the input parameters of contract C2 include, for example, the attribute list of the newly generated data, the parent data identification list, etc.

[0040] In step S303, the blockchain system generates a data identifier based on the transaction.

[0041] After receiving a transaction (e.g., transaction Tx1 or transaction Tx2), each node in the blockchain system reaches consensus on the transaction. After reaching consensus, each blockchain node executes the transaction, generating a data identifier based on the transaction. Because each blockchain node generates data identifiers according to the same pre-defined rules, each blockchain node generates a consistent identifier for the data.

[0042] In one embodiment, the contract state of contract C1 stores a count of created data identifiers, where the initial value of the count is, for example, 0. The blockchain node adds 1 to the value of the count each time a data identifier is created through contract C1, so that the count can indicate the number of data identifiers that have been created through contract C1.

[0043] When executing transaction Tx1, a blockchain node retrieves the current count value from the contract status of contract C1, adds 1 to it, and then uses the retrieved count value and the contract address to generate the identifier for the currently registered data. For example, if the contract address of contract C1 is addr1 and the retrieved count value is 150, the identifier for the currently registered data D1 can be determined to be addr1-150. Clearly, the data identifiers generated in this way are globally unique within the blockchain system, and the same identifier will not be generated for different data.

[0044] When executing transaction Tx2, the blockchain node can similarly determine the identifier of data D4 based on addr1 and the count value when executing transaction Tx2.

[0045] In another embodiment, when a blockchain node executes transaction Tx2 and begins executing the registration function of contract C1 to register data D4 based on transaction Tx2, it generates a log in the receipt of transaction Tx2. The log has a log identifier. Assuming that the log identifier is log3, the blockchain node can generate a data identifier for data D4 (e.g., "hash2-log3") based on the hash value of transaction Tx2 (e.g., hash2) and the log identifier. Since the hash value of transaction Tx2 is unique in the blockchain, and the log identifier log3 is unique among the multiple logs in the receipt of transaction Tx2, even if the registration function is called multiple times in transaction Tx2 to generate data identifiers for multiple data, the data identifier generated for data D4 remains globally unique in the blockchain system.

[0046] The unique identifier of the data is generated in the above manner. Compared with using the data hash value as the data identifier, the data identifier generated in the embodiment of this specification has no correlation with the content of the data itself, and thus does not restrict changes in the data itself.

[0047] In step S305, the blockchain node stores the identification of the data in the contract state.

[0048] After generating the data identifier as described above, the blockchain node stores the data identifier in the contract status of contract C1, so that the data identifier can be queried from contract C1 to verify whether the data identifier is data that has been registered through contract C1, thereby determining whether the data identifier is globally unique in the blockchain system.

[0049] The blockchain node can also store other data information in the contract state in association with the data identifier. Table 1 is a schematic diagram of the data information stored in the contract state in the embodiment of this specification. Table 1

[0050] In one embodiment, a blockchain node may store the creator of the data in association with the data identifier in the contract state.

[0051] Specifically, as shown in Table 1, for transaction Tx1, the creator of the registered data D1 (data identifier addr1-150) can be stored as the sending account of transaction Tx1, that is, Alice's account. For transaction Tx2, the creator of the registered data D4 can be stored as the contract address of contract C2.

[0052] In one embodiment, when a transaction used to register data also includes a list of attributes for the data, the blockchain node stores the list of attributes in association with the data identifier in the contract state of contract C1 based on the transaction. When an attribute is marked with "inherent required" in the attribute list in the transaction, this mark is also stored in the attribute list in the contract state. For example, if the attribute list included in transaction Tx1 includes a key-value pair of two attributes, Attr2 and Attr5, and Attr2 is marked with "inherent required," then the attribute list in Table 1 of the contract state will record the row corresponding to Attr2 and the row corresponding to Attr5. The row corresponding to Attr2 includes the attribute value (value2) of attribute Attr2, a mark for marking attribute Attr2 as "inherent required" (i.e., T in the third column of the attribute list), and a mark for marking attribute Attr2 as "non-inherent" (i.e., F in the fourth column of the attribute list). That is, the attribute Attr2 of data D1 needs to be inherited by the child data of data D1, and the value of the attribute Attr2 of data D1 is assigned relative to data D1, rather than inherited from the parent data. In other words, the attribute Attr2 is a non-inherited attribute. The row corresponding to Attr5 includes the attribute value (value5) of the attribute Attr5, a flag for marking the attribute Attr5 as "non-inherent required" (i.e., F in the third column of the attribute list), and a flag for marking the attribute Attr5 as "non-inherent required" (i.e., F in the fourth column of the attribute list).

[0053] In one embodiment, when a transaction includes an attribute list and a parent data identifier list, the blockchain node not only stores the attribute list in the transaction in the contract state of contract C1, but also reads the attribute list of each parent data from the contract state of contract C1 based on each parent data identifier, determines from the attribute list of each parent data the attribute (e.g., "Attr1") that must be inherited by the currently registered data (e.g., data D1), adds the key of the attribute to the attribute list of data D1 in the contract state, and points the value of the attribute to the value of the attribute of its parent data. In addition, as shown in Table 1, the blockchain node also records the row for attribute Attr1 in the attribute list of data D1 in the contract state. In the row for Attr1, the value column is a pointer to the value of Attr1 in the parent data of data D1. The attribute Attr1 is marked with a "T" in the "inherented" column to indicate that it is inherited from the parent data. The attribute Attr1 is also marked with a "T" in the "inherent required" column to indicate that the child data of data D1 will inherit this attribute Attr1 and maintain the same value as the attribute Attr1 in the parent data of data D1. Similarly, when the value of the attribute Attr4 inherited by data D1 from the parent data identifier list is determined, the row corresponding to Attr4 is recorded in Table 1.

[0054] In addition, as shown in Table 1, the attribute list of data D1 in the contract state can also store the identifier (origin) of the original data corresponding to the attribute marked "inherented." For example, for the attribute Attr1 described above, it can be determined whether the attribute Attr1 is marked "inherented" in the attribute list of the parent data. If it is marked, the parent data identifier list of the parent data can be traced back until the data identifier of the attribute in the attribute list that is not marked "inherented" (for example, ancestor data identifier 1) is determined as the identifier of the original data. By recording the origin for each inherited attribute of the data, the attribute list of the origin can be directly read from the contract state, and the attribute value of the attribute can be read from the attribute category of the origin.

[0055] After a blockchain node registers data in the blockchain, the creator of the data can update the non-inherited properties of the data.

[0056] FIG4 is a flow chart of a method for updating data attributes in an embodiment of this specification.

[0057] Referring to Figure 4, in step S401, the user device sends a transaction to the blockchain system to call contract C1 to update the attributes of the data.

[0058] In one embodiment, the data holder device 101 sends a transaction Tx3 to the blockchain system. The transaction Tx3 is sent by Alice's account. The update function of the contract C1 can be called in the transaction Tx3. The input parameters of the update function include, for example, a data identifier (e.g., addr1-150), a key-value pair of the attribute of the data to be updated (e.g., Attr2), etc.

[0059] In another embodiment, for example, the data processing device 20 sends a transaction Tx4 to the blockchain system, and the contract C2 is called in the transaction Tx4. The update function of the contract C1 is called in the contract C2. The input parameters of the update function include, for example, a data identifier (for example, hash2-log3), a key-value pair of the attribute of the data to be updated (for example, Attr3), etc.

[0060] In step S403, the blockchain system determines whether the caller of the update function of contract C1 is the creator of the data identifier based on the transaction.

[0061] Specifically, for the above-mentioned transaction Tx3, when the blockchain node executes the update function of contract C1 according to transaction Tx3, it can read the creator of data identifier addr1-150 (that is, Alice's account) from Table 1 in the contract status of contract C1. After determining that transaction Tx3 directly calls contract C1, it determines whether the sending account of transaction Tx3 is Alice's account, thereby determining whether the caller of contract C1 is the creator of data identifier addr1-150.

[0062] For the above transaction Tx4, when the blockchain node executes the update function of contract C1 according to transaction Tx4, it can read the creator of the data identifier hash2-log3 (that is, the contract address of contract C2) from the contract state of contract C1. Then, the blockchain node determines whether the update function of contract C1 is called by contract C2 in transaction Tx4, and thus determines whether the caller of contract C1 is the creator of the data identifier hash2-log3.

[0063] In step S405, when the blockchain node determines that the caller of the contract C1 is the creator of the data identifier, it determines whether the attribute to be updated is a non-inherited attribute.

[0064] That is, the creator of the data identifier can only update the non-inherited attributes of the data, that is, the attributes that are not marked "inherented" or marked "non-inherented", but cannot update the attributes of the data marked "inherented".

[0065] Specifically, the blockchain node queries the data identifier in the contract state to see whether the attribute to be updated (e.g., Attr2) is marked with "inherented". If it is not marked with "inherented", that is, "F" is marked in the "inherented" column in Table 1, then the attribute is a non-inherited attribute.

[0066] In step S407, when the blockchain node determines that the attribute to be updated is a non-inherited attribute, it updates the data attribute in the contract state.

[0067] Specifically, for example, for transaction Tx3, if the blockchain node determines that Attr2 is a non-inherited attribute, it updates the value of attribute Attr2 in the attribute list corresponding to data identifier addr1-150 in the contract state. That is, in Table 1, the value of Attr2 is updated from value2 to the new value of Attr2 included in transaction Tx3, such as value2′.

[0068] When the attribute Attr2 is marked as "inherent requried", the value of the attribute Attr2 of all descendant data of data D1 points to the value of the attribute Attr2 in the attribute list of data D1. Therefore, after updating the value of the attribute Attr2 in the attribute list corresponding to the data identifier addr1-150, it is equivalent to synchronously updating the value of the attribute Attr2 of all descendant data of data D1.

[0069] After the data identifier and its corresponding data information are stored in the blockchain system through the above method, the data user can query the data information corresponding to the data identifier from the blockchain system.

[0070] FIG5 is a flow chart of a method for querying data information corresponding to a data identifier in an embodiment of this specification.

[0071] As shown in FIG5 , in step S501 , the data user device 30 sends a transaction Tx5 for calling the contract C1 to the blockchain system to query data information.

[0072] In the transaction Tx5, for example, the query function of the contract C1 is called, and the input parameters of the query function include, for example, the data identifier "addr1-150", so as to read the data information corresponding to the data identifier "addr1-150" stored in the contract state of the contract C1. The input parameters of the query function may also include, for example, the key of the attribute to be queried, such as Attr4, to indicate the value of the query attribute Attr4. In the case where the input parameters of the query function do not include the attribute key, the transaction Tx5 can be used to query whether the data identifier "addr1-150" exists in the contract state of the contract C1, or the transaction Tx5 can be used to query all the data information corresponding to the data identifier "addr1-150" in the contract state.

[0073] In step S503, the blockchain system determines whether the data identifier to be queried is stored in the contract state based on transaction Tx5.

[0074] Specifically, the blockchain node determines whether the data identifier "addr1-150" is stored in the contract status of contract C1 based on transaction Tx5.

[0075] In step S505, when the blockchain system determines that a data identifier to be queried is stored in the contract state, it returns data information corresponding to the data identifier to the user device.

[0076] Specifically, the blockchain node queries the data identifier "addr1-150" in the contract state of contract C1. After querying the data identifier "addr1-150", according to transaction Tx5, it obtains the data information corresponding to the data identifier "addr1-150" from the contract state and returns the data information to the data user device. For example, the input parameters of the query function in transaction Tx5 include the key of attribute Attr4, and the user instructs to query the attribute value of attribute Attr4. Then, the blockchain node reads the attribute value of attribute Attr4 from the attribute list corresponding to the data identifier "addr1-150" in the contract state of contract C1 (as shown in Table 1) and returns the attribute value to the data user device.

[0077] FIG6 is an architecture diagram of a blockchain node in a blockchain system according to an embodiment of this specification. The blockchain system has a first contract deployed therein. The blockchain node is configured to execute the method shown in FIG3 to FIG5 , including:

[0078] A receiving unit 61 is configured to receive a first transaction for invoking the first contract, where the first transaction is used to register first data;

[0079] a generating unit 62, configured to execute the first contract according to the first transaction and generate a first identifier unique in the blockchain system to be used as an identifier of the first data;

[0080] The storage unit 63 is configured to store the first identifier in the contract status of the first contract.

[0081] The embodiments of this specification also provide a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the method shown in FIG. 3 to FIG. 5 .

[0082] An embodiment of this specification also provides a blockchain node, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it is implemented to execute the method shown in Figures 3 to 5.

[0083] Through the data management solution described in the embodiments of this specification, a globally unique identifier for data can be generated through a contract, so that the identifier can be applied to scenarios where multiple parties process data.

[0084] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages ​​and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0085] The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

[0086] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude that with the future development of computer technology, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, an in-vehicle human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0087] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "comprise", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not clearly listed, or also includes elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any particular order.

[0088] For the convenience of description, the above devices are described in terms of functions divided into various modules. Of course, when implementing one or more of the present specifications, the functions of each module can be implemented in the same or multiple software and / or hardware, or the module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0089] The present invention is described with reference to the flowcharts and / or block diagrams of the methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart and / or one or more blocks in the block diagram.

[0090] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0091] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0092] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0093] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0094] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0095] Those skilled in the art will appreciate that one or more embodiments of this specification may be provided as a method, system, or computer program product. Thus, one or more embodiments of this specification may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0096] One or more embodiments of this specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. One or more embodiments of this specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communications network. In distributed computing environments, program modules may be located in local and remote computer storage media, including storage devices.

[0097] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between the various embodiments can be referenced across them. Each embodiment focuses on the differences from the other embodiments. In particular, since the system embodiments are generally similar to the method embodiments, their description is relatively simple. For relevant parts, reference can be made to the description of the method embodiments. Throughout this specification, reference to the terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and integrate the different embodiments or examples, and features of different embodiments or examples, described in this specification, without conflict.

[0098] The foregoing is merely an example of one or more embodiments of this specification and is not intended to limit the one or more embodiments of this specification. It will be apparent to those skilled in the art that various modifications and variations may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this specification shall be included within the scope of the claims.

Claims

1. A data management method based on a blockchain system, wherein a first contract is deployed in the blockchain system, and the method is executed by a blockchain node, comprising: Receiving a first transaction that calls the first contract, where the first transaction is used to register first data; Execute the first contract according to the first transaction, and generate a first identifier that is unique in the blockchain system to be used as an identifier of the first data; The first identifier is stored in the contract state of the first contract.

2. According to the method of claim 1, the contract state stores a value of a first variable, the first variable corresponds to the number of data identifiers generated by the first contract, and the executing the first contract according to the first transaction to generate a first identifier unique in the blockchain system comprises: Generate the first identifier based on the contract address of the first contract and the current value of the first variable; Increase the value of the first variable by 1.

3. According to the method of claim 1, executing the first contract according to the first transaction to generate a first identifier that is unique in the blockchain system comprises: When performing the operation for generating the first identifier, generating a first log in the receipt of the first transaction, the first log having a unique log identifier in the receipt of the first transaction; The first identifier is generated based on the hash value of the first transaction and the log identifier of the first log.

4. The method according to claim 1, wherein the first transaction further comprises a first attribute list of the first data, and the method further comprises: A second attribute list is stored in the contract state in association with the first identifier, wherein the second attribute list includes elements in the first attribute list.

5. According to the method of claim 4, the first attribute list includes an attribute value of a first attribute and first indication information of the first attribute, and the first indication information is used to indicate that the sub-data of the first data needs to inherit the attribute value of the first attribute.

6. The method according to claim 1, wherein the first transaction includes a list of parent data identifiers, and the method further comprises: The second attribute list stores an attribute identifier of a second attribute inherited from parent data, second indication information and third indication information, wherein the second indication information is used to indicate that the attribute value of the second attribute is inherited from the first parent data indicated in the identifier list, and the third indication information is used to indicate that the child data of the first data needs to inherit the attribute value of the second attribute.

7. The method according to claim 6, further comprising: Storing an identifier of a creator corresponding to the first identifier in the contract state; receiving a second transaction for invoking the first contract, wherein the second transaction includes the first identifier and a key of a third attribute, and is used to update a value of the third attribute in the second attribute list in the contract state; According to the second transaction, when it is determined that the caller of the first contract is the creator and the attribute value of the third attribute is not inherited from parent data, the value of the third attribute is updated in the contract state.

8. According to the method of claim 7, when the first transaction directly calls the first contract, the creator is the sending account of the first transaction; or, when the first transaction calls the second contract and the second contract calls the first contract, the creator is the contract address of the second contract.

9. The method according to claim 6, further comprising: Determine, according to the attribute list of the first parent data stored in the contract state, the data identifier of the ancestor data corresponding to the second attribute; The data identifier of the ancestor data is stored in the second attribute list in association with the second attribute.

10. The method according to claim 4, further comprising: receiving a third transaction for invoking the first contract, wherein the third transaction includes the first identifier, and is used to query information associated with the first identifier; determining, according to the third transaction, whether the contract status of the first contract includes the first identifier; In the case where it is determined that the contract status of the first contract includes the first identifier, information associated with the first identifier is returned to the sending device of the third transaction.

11. A blockchain node in a blockchain system, wherein a first contract is deployed in the blockchain system, and the blockchain node comprises: A receiving unit, configured to receive a first transaction for invoking the first contract, wherein the first transaction is used to register first data; a generating unit, configured to execute the first contract according to the first transaction, and generate a first identifier unique in the blockchain system to be used as an identifier of the first data; A storage unit is used to store the first identifier in the contract state of the first contract.

12. A blockchain node, comprising a memory and a processor, wherein the memory stores an executable code, and when the processor executes the executable code, the method according to any one of claims 1 to 10 is implemented.

Images