WO2024021417A1

WO2024021417A1 - Data account creation method and apparatus

Info

Publication number: WO2024021417A1
Application number: PCT/CN2022/135405
Authority: WO
Inventors: 俞本权; 刘燕; 魏长征; 何家华; 郭学鹏
Original assignee: 蚂蚁区块链科技(上海)有限公司
Priority date: 2022-07-29
Filing date: 2022-11-30
Publication date: 2024-02-01
Also published as: CN115203747A

Abstract

Provided in one or more embodiments of the present specification are a data account creation method and apparatus, which are applied to a blockchain node, wherein an account type supported by a blockchain comprises a data account, and the data account is used for maintaining service data required for performing contract calculations by a smart contract deployed on the blockchain. The method comprises: receiving a data account creation transaction, which is used for creating a data account, wherein the data account creation transaction comprises service data required to perform contract calculations by a smart contract deployed on a blockchain; in response to the data account creation transaction, creating the data account on the blockchain; and adding the service data to the data account for maintenance.

Description

Data account creation method and device

This application claims priority to the Chinese patent application filed with the China Patent Office on July 29, 2022, with the application number 202210911233.1 and the invention title "Data Account Creation Method and Device", the entire content of which is incorporated into this application by reference.

Technical field

One or more embodiments of this specification relate to the field of blockchain, and in particular, to a method and device for creating a data account.

Background technique

The invention of smart contracts has lowered the application threshold of blockchain, and the launch of alliance chain has accelerated the application of blockchain by enterprises. However, enterprises' application of blockchain faces huge technical challenges, especially when the enterprise's business logic becomes increasingly complex and business data continues to accumulate. Due to existing technical limitations and performance bottlenecks, it usually needs to be implemented by a single smart contract. Complex business logic requires a large amount of business data to be stored under this smart contract.

Therefore, the following problems usually result: First, the code amount of the smart contract is large, and may even approach the upper limit of the virtual machine used to execute the smart contract; second, if in order to reduce the code amount of the smart contract, the smart contract is split Divided into multiple sub-contracts, cross-contract calls need to be made between these multiple sub-contracts to execute the business, which will affect the execution performance of the business; thirdly, if the business logic implemented by the smart contract needs to be upgraded, it needs to be in the block To deploy a new smart contract on the chain, you need to write the upgraded business logic into the new smart contract, and copy the business data in the original smart contract to the new smart contract, so that the new smart contract is compatible with the original smart contract. Business data in the contract.

Contents of the invention

One or more embodiments of this specification provide technical solutions as follows:

This specification provides a method for creating a data account, which is applied to blockchain nodes; the account types supported by the blockchain include data accounts; the data account is used to maintain smart contracts deployed on the blockchain for contract calculations Required business data; the methods include:

Receive a data account creation transaction used to create the data account; wherein the data account creation transaction includes business data required for contract calculation by smart contracts deployed on the blockchain;

creating a data account on the blockchain in response to the data account creation transaction; and,

Add the business data to the data account for maintenance.

This specification also provides a data account creation device, which is applied to blockchain nodes; the account types supported by the blockchain include data accounts; the data account is used to maintain smart contracts deployed on the blockchain for contract execution Calculate the required business data; the device includes:

A receiving module that receives a data account creation transaction used to create the data account; wherein the data account creation transaction includes business data required for contract calculation by smart contracts deployed on the blockchain;

A creation module, in response to the data account creation transaction, creates a data account on the blockchain; and adds the business data to the data account for maintenance.

This instruction manual also provides an electronic device, including:

processor;

Memory used to store instructions executable by the processor;

Wherein, the processor executes the steps of any of the above methods by running the executable instructions.

This specification also provides a computer-readable storage medium on which computer instructions are stored. When the instructions are executed by a processor, the steps of any of the above methods are implemented.

In the above technical solution, the blockchain node in the blockchain can respond to the received data account creation transaction, and perform the business required for contract calculation based on the smart contract deployed on the blockchain in the data account creation transaction. Data, create a data account on the blockchain, that is, add the business data to the created data account for maintenance.

Using the above method, the contract code of the smart contract can be separated from the business data required for contract calculation by the smart contract, so that the following purposes can be achieved: First, only the contract of the smart contract needs to be maintained in the contract account corresponding to the smart contract. code, so smart contracts with complex business logic can be split into multiple simpler sub-contracts, reducing the costs of smart contract development, testing, upgrades, etc.; Second, users registered in the blockchain User accounts, as well as contract accounts corresponding to smart contracts deployed on the blockchain, can directly access business data maintained in data accounts created on the blockchain. That is, data accounts can be used to implement user accounts and contract accounts. Data sharing saves the execution overhead of smart contracts, enables parallel access to business data, and improves the transaction throughput of the blockchain; third, centralized maintenance of business data by data accounts can realize the assetization of business data and facilitate the acquisition of large amounts of data. Business data is processed for data analysis, AI training, etc.

Description of drawings

Figure 1 is a schematic diagram of the account structure of a user account.

Figure 2 is a schematic diagram of the account structure of a contract account.

Figure 3 is a flow chart of a method for creating a data account according to an exemplary embodiment of this specification.

Figure 4 is a schematic diagram of the account structure of a data account according to an exemplary embodiment of this specification.

Figure 5 is a flow chart of a data account access authorization method according to an exemplary embodiment of this specification.

FIG. 6 is a flow chart of another data account access authorization method according to an exemplary embodiment of this specification.

Figure 7 is a flow chart of another data account access authorization method according to an exemplary embodiment of this specification.

Figure 8 is a flow chart of a data account access method according to an exemplary embodiment of this specification.

Figure 9 is a flow chart of another data account access authorization method according to an exemplary embodiment of this specification.

FIG. 10 is a flow chart of another data account access authorization method according to an exemplary embodiment of this specification.

Figure 11 is a flow chart of another data account access method according to an exemplary embodiment of this specification.

Figure 12 is a flow chart of a data account updating method according to an exemplary embodiment of this specification.

Figure 13 is a schematic diagram of the hardware structure of a device according to an exemplary embodiment of this specification.

Figure 14 is a block diagram of a data account creation device illustrating an exemplary embodiment of this specification.

Detailed ways

Exemplary embodiments will be described in detail herein, examples of which are illustrated in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings refer to the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatus and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

It should be noted that in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, methods may include more or fewer steps than described in this specification. In addition, a single step described in this specification may be broken down into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step in other embodiments. describe.

Blockchains are generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain. In addition, there can also be combinations of the above types, such as the combination of private chain and alliance chain, the combination of alliance chain and public chain, etc.

Among the above three types of blockchains, the most decentralized is the public chain. Participants who join the public chain (also called nodes in the blockchain) can read data records on the chain, participate in transactions, compete for the accounting rights of new blocks, etc. Moreover, each node can freely join or exit the network and perform related operations.

On the contrary, private chains have network write permissions controlled by an organization or institution, and data read permissions regulated by the organization. That is, a private chain can be viewed as a weakly centralized system with strict restrictions on nodes and a small number of nodes. This type of blockchain is more suitable for internal use within specific organizations.

The alliance chain is between the public chain and the private chain and can achieve "partial decentralization". Each node in the alliance chain usually has a corresponding entity or organization; the nodes join the network through authorization and form an alliance of stakeholders to jointly maintain the operation of the blockchain.

In the blockchain network, nodes are logical communication entities; multiple nodes of different types can run on the same physical server or on different physical servers.

For data generated outside the blockchain, it can be constructed into a standard transaction (Transaction) format supported by the blockchain, and then published to the blockchain, and all nodes in the blockchain network will process the transaction. consensus. After reaching a consensus, the node in the blockchain network that serves as the accounting node can persist the transaction in the blockchain.

Current blockchain systems usually include two mainstream transaction models; one is the UTXO (Unspent Transaction Output, unspent transaction output) model, and the other is the account model.

If the above two types of blockchains want to implement data storage, they can usually use the following storage methods:

For blockchains that use the UTXO model, the native transactions they support usually only include transfer transactions. In the process of transferring money based on the transfer transaction, the user can pass the transaction postscript in the transfer transaction (i.e., the transfer postscript). To fill in additional data, to store the additional data on the blockchain.

For blockchains that use the account model, the blockchain data that needs to be stored and maintained usually includes block data and account status data corresponding to the blockchain accounts in the blockchain; and the block data can be further Including block header data, block transaction data in the block, and transaction receipts corresponding to the block transaction data in the block, etc. When storing the various blockchain data shown above, the above various blockchain data can usually be organized into a Merkle tree (i.e. Merkle tree) in the form of key-value pairs and stored in the database. . When it is necessary to query the various blockchain data stored in the blockchain node, the data can be efficiently queried by using the keys of the various blockchain data as query indexes and traversing the above Merkle tree.

In a blockchain that adopts the account model, smart contracts for data storage can be deployed on the blockchain. Users can call the smart contract to use the data that needs to be stored as the contract account corresponding to the smart contract. The account status is stored in the Merkle tree corresponding to the smart contract.

For example, a special Merkle tree called an MPT tree is usually used to store and maintain blockchain data; account status data can be organized into an MPT status tree (commonly known as world status) and stored in the database; The MPT status tree stores key-value pairs with the account address as the key and the account status data as the value. The data content stored in the contract account corresponding to the smart contract will be further organized into a Storage tree (an MPT storage tree used to store data) and stored in the database; the Hash value of the root node of the Storage tree will be used as the Part of the account status data corresponding to the contract account is filled into the MPT status tree; and the hash of the root node of the MPT status tree will be used as the authentication root and further filled into the block header. When users need to deposit data, they can call the smart contract to store the data that needs to be deposited as the account status data of the contract account corresponding to the smart contract into the Storage tree corresponding to the smart contract.

In the field of blockchain, accounts are usually divided into two categories: user accounts and contract accounts; user accounts are accounts directly controlled by users, also called external accounts; contract accounts are created by users through user accounts, including Account of the contract code (i.e. smart contract).

For accounts in the blockchain, the account status of the account is usually maintained through a structure. When a transaction in a block is executed, the status of the account associated with the transaction in the blockchain usually changes.

In an example, the account structure usually includes fields such as Balance, Nonce, Code and Storage. in:

Balance field, used to maintain the current account balance of the account;

The Nonce field is used to maintain the number of transactions of the account; it is a counter used to ensure that each transaction can and can only be processed once, effectively avoiding replay attacks;

The Code field is used to maintain the contract code of the account; in practical applications, the Code field usually only maintains the hash value of the contract code; therefore, the Code field is usually also called the CodeHash field.

The Storage field is used to maintain the storage content of the account (the default field value is empty); for contract accounts, an independent storage space is usually allocated to store the storage content of the contract account; this independent storage space is usually Call it the account storage of this contract account.

The storage content of the contract account is usually constructed into a data structure of an MPT (Merkle Patricia Trie) tree and stored in the above-mentioned independent storage space; among them, the MPT tree constructed based on the storage content of the contract account is usually also called a Storage tree . The Storage field usually only maintains the root node of the Storage tree; therefore, the Storage field is usually also called the StorageRoot field.

Among them, for the user account, the field values of the Code field and the Storage field shown above are both null.

Please refer to Figure 1, which is a schematic diagram of an account structure of a user account.

As shown in Figure 1, the account structure of the above user account may specifically include an Identity field and a Balance field. Among them, the Identity field can be used to maintain the account identification of the user account.

It should be noted that since the field values of the Code field and the Storage field in the user account are usually null, the Code field and the Storage field are omitted from the account structure of the user account in Figure 1.

Please refer to Figure 2, which is a schematic diagram of the account structure of a contract account.

As shown in Figure 2, the account structure of the above-mentioned contract account can specifically include the Identity field, the Balance field, the Code field, and the Storage field. Among them, the Identity field can be used to maintain the account identification of the contract account.

It should be noted that the Code field usually only maintains the hash value of the contract code, which can also be called the CodeHash field. The Storage field usually only maintains the root node of the Storage tree built based on the storage content of the contract account, which can also be called the StorageRoot field.

In a programmable blockchain, users can be provided with smart contract functions to support users in creating and calling some complex logic in the blockchain network. The so-called smart contract is a program that can be triggered and executed by transactions on the blockchain.

In a programmable blockchain, each blockchain node can be equipped with a Turing-complete virtual machine as the execution environment for smart contracts, through which various complex logic can be implemented. When users publish and call smart contracts in the blockchain, they run on the virtual machine.

In fact, the virtual machine directly runs the virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"), so the smart contract deployed on the blockchain can be bytecode. Bytecode consists of a series of bytes, each byte can identify an operation. Based on various considerations such as development efficiency and readability, developers can choose a high-level language to write smart contract code instead of writing bytecode directly. For example, high-level languages can use Solidity, Serpent, LLL language, etc. Smart contract codes written in high-level languages can be compiled by a compiler to generate bytecode that can be deployed on the blockchain.

Users can send a smart contract creation transaction containing contract code to the blockchain network, and each blockchain node can execute the transaction in the equipped virtual machine.

When the blockchain nodes reach an agreement through the consensus mechanism, the smart contract is successfully created, and subsequent users can call the smart contract.

After the smart contract is created, a contract account corresponding to the smart contract appears on the blockchain and has a specific address; the contract code (Code) and account storage (Storage) will be saved in the account storage of the contract account. The behavior of a smart contract is controlled by the contract code, and the account storage of the smart contract saves the state of the contract.

After the user sends a smart contract call transaction to the Ethereum network, each blockchain node can execute the transaction in the equipped virtual machine.

After calling the smart contract, the account status of the contract account may change. Subsequently, a client can view the account status of the contract account through the connected blockchain node.

Smart contracts can be executed independently on each node in the blockchain network in a prescribed manner. All execution records and data are saved on the blockchain. Therefore, after such a transaction is executed, there is no way to save it on the blockchain. Transaction vouchers that are tamper-resistant and cannot be lost.

This manual aims to propose a technical solution for creating data accounts. By further expanding the account types supported by the blockchain, it can expand the business of maintaining smart contracts deployed on the blockchain for contract calculations. The data account of the data realizes the separation of the contract code of the smart contract and the business data required for the smart contract to perform contract calculations.

In specific implementation, for the smart contracts deployed on the above-mentioned blockchain, the blockchain nodes in the above-mentioned blockchain can receive data account creation transactions.

Among them, the above-mentioned data account creation transaction can be used to create a data account corresponding to the above-mentioned smart contract, that is, the created data account is used to maintain the business data required for the smart contract to perform contract calculations. Correspondingly, the data account creation transaction may include the business data.

When the above-mentioned blockchain node receives the above-mentioned data account creation transaction, it can respond to the data account creation transaction and create a data account on the above-mentioned blockchain.

For the above-mentioned data account created, the above-mentioned blockchain node can add the business data in the above-mentioned data account creation transaction to the data account for maintenance. From this, a data account can be created for maintaining the business data required for contract calculations by the above smart contract.

Please refer to FIG. 3 , which is a flow chart of a method for creating a data account according to an exemplary embodiment of this specification.

In this embodiment, the account types supported by the blockchain can be further expanded to expand a new account type that is independent of user accounts and contract accounts, called data accounts. That is, the account types supported by the blockchain can include user accounts, contract accounts and data accounts.

For the above-mentioned data account, the business data required for contract calculations of smart contracts deployed on the above-mentioned blockchain can be maintained. As a result, the contract code of the smart contract can be separated from the business data required for contract calculation by the smart contract.

The above data account creation method can be applied to blockchain nodes, including the following steps:

Step 302: Receive a data account creation transaction used to create the data account; wherein the data account creation transaction includes business data required for contract calculation by the smart contract deployed on the blockchain.

Step 304: In response to the data account creation transaction, create a data account on the blockchain.

Step 306: Add the business data to the data account for maintenance.

For the smart contracts deployed on the above-mentioned blockchain, the manager corresponding to the data account to be created can initiate a data account creation transaction. For example, the above-mentioned management party can perform the operation of initiating the above-mentioned data account creation transaction through its corresponding client. When the client detects this operation, it can construct the data account creation transaction according to the standard transaction format supported by the above-mentioned blockchain, and publish the data account creation transaction to the blockchain. In this case, the data account creation transaction can be received by the blockchain nodes in the blockchain.

In practical applications, the above-mentioned manager can be the owner of the above-mentioned smart contract (for example: the smart contract can implement the business logic of a certain enterprise, in which case the manager can be the enterprise), or can be the data to be created The owner of the account (for example: the data account can be used to maintain business data of a certain enterprise, in which case the manager can be the enterprise).

It should be noted that other users can also initiate the above-mentioned data account creation transaction, or the above-mentioned blockchain node can construct the above-mentioned data account creation transaction on its own when certain conditions are met. This instruction does not limit this.

Among them, the above-mentioned data account creation transaction can be used to create a data account corresponding to the above-mentioned smart contract, that is, the created data account can be used to maintain the business data required for contract calculation by the smart contract. Correspondingly, the data account creation transaction may include business data required by the smart contract for contract calculations.

The account structure of the data account is explained in detail below.

In one embodiment shown, similar to the aforementioned user accounts and contract accounts, the business data maintained in the data account can be organized into the form of a Merkle tree and stored in a local database carried by the blockchain node. Correspondingly, the account structure of the data account may include a data storage field used to maintain the Hash value of the root node of the Merkle tree, in which the business data required for contract calculation by the smart contract deployed on the blockchain is written.

In the above case, the aforementioned adding the business data in the above-mentioned data account creation transaction to the above-mentioned data account for maintenance may specifically include writing the business data in the above-mentioned data account creation transaction into the local database carried by the above-mentioned blockchain node. Store the Merkle tree to update the Merkle tree, and fill the hash value of the root node of the updated Merkle tree into the data storage field in the data account.

Please refer to FIG. 4 , which is a schematic diagram of the account structure of a data account according to an exemplary embodiment of this specification.

As shown in Figure 4, the account structure of the above data account may specifically include a Storage field. Among them, the Storage field can be used to maintain the Hash value of the root node of the Merkle tree, which is also called the StorageRoot field. The business data required for smart contract calculations is written in the Merkle tree.

In the above situation, the storage content of the contract account may no longer include the business data required by the smart contract for contract calculations, but an independent data account maintains the business data required by the smart contract for contract calculations. In this way, the contract code of the smart contract can be separated from the business data required for contract calculation by the smart contract.

In an embodiment shown, the business data required for contract calculation by the smart contract deployed on the above-mentioned blockchain may include business data content and data access code corresponding to the business data content.

In the above case, the aforementioned business data in the above-mentioned data account creation transaction is written into the Merkle tree stored in the local database carried by the above-mentioned blockchain node to update the Merkle tree, and the updated Merkle tree The hash value of the root node is filled into the data storage field in the above-mentioned data account. Specifically, it may include writing the corresponding relationship between the business data content and the data access code in the data account creation transaction into the Merkle tree to conduct the Merkle tree Update, and fill the hash value of the updated root node of the Merkle tree into the data storage field in the data account. That is to say, the data storage field in the data account can be used to maintain the Hash value of the root node of the Merkle tree, which contains the business data content required for contract calculation by the smart contract deployed on the blockchain, and The corresponding relationship between the data access code corresponding to the business data content.

Continuing to refer to Figure 4, the Storage field in the account structure of the data account shown in Figure 4 can be used to maintain the Hash value of the root node of the Merkle tree, which can also be called the StorageRoot field. The smart contract is written in the Merkle tree. The business data content required for contract calculation and the corresponding relationship between the data access codes corresponding to the business data content. In this case, the Storage field can be regarded as including the Data field and the corresponding Data Access Code field.

Among them, the Data field can be regarded as the hash value of the root node of the Merkle tree used to maintain the business data content required for contract calculation in the smart contract, and the Data Access Code field can be regarded as used to maintain the written content related to the business. The hash value of the root node of the Merkle tree of the data access code corresponding to the data content.

In one embodiment shown, for the above-mentioned business data content, the corresponding data access code may include an interface code for reading/writing the business data content. That is, by calling the data access code, the content of the business data can be read/written.

In an embodiment shown, the above-mentioned data account creation transaction may also include data description information corresponding to the business data required for the above-mentioned smart contract to perform contract calculations. Correspondingly, the account structure of the data account may also include a data description field used to maintain the Hash value of the data description information, which corresponds to the business data required for contract calculations by smart contracts deployed on the blockchain.

In the above case, for the above-mentioned data account created, the above-mentioned blockchain node can also calculate the hash value of the data description information corresponding to the above-mentioned business data in the above-mentioned data account creation transaction, and fill the calculated hash value into The data description field in this data account.

Continuing to refer to Figure 4, the account structure of the data account shown in Figure 4 may specifically include a SchemaHash field and a Storage field. Among them, the Storage field can be used to maintain the Hash value of the root node of the Merkle tree, which is also called the StorageRoot field. The business data required for smart contract calculations is written in the Merkle tree. In this case, the SchemaHash field can be used to maintain the Hash value of the data description information corresponding to the business data.

In an embodiment shown, the account structure of the above-mentioned data account may also include any one or more fields shown below: an account identification field used to maintain the account identification of the data account; The balance field of the balance of the assets held by the data account; the management field used to maintain the public key of the administrator of the data account.

Continuing to refer to Figure 4, the account structure of the data account shown in Figure 4 may specifically include an Identity field, a Balance field, an AuthMap field, a SchemaHash field, and a Storage field. Among them, the Identity field can be used to maintain the account identification of the data account. The Balance field can be used to maintain the balance of assets held by the data account. The AuthMap field can be used to maintain the public key of the administrator of the data account.

It should be noted that the above-mentioned management field can be specifically used to maintain the corresponding relationship between the public key of at least one manager of the data account and the weight assigned to the public key of the at least one manager.

In practical applications, for data accounts created on the blockchain, the aforementioned user accounts and contract accounts can access the data account to obtain the business data maintained in the data account, so that certain operations can be performed based on the business data. processing. In order to prevent any user account or any contract account from arbitrarily accessing the data account created on the blockchain and improve the security of the business data maintained in the data account, user accounts and contract accounts can be accessed for the data account. Permission control.

In one embodiment shown, the account structure of the data account may include an authorization field for maintaining access authorization information corresponding to the data account.

Based on the data account creation method shown in Figure 3, please refer to Figure 5. Figure 5 is a flow chart of a data account access authorization method according to an exemplary embodiment of this specification.

The access authorization method for the above data account may include the following steps:

Step 502: Receive a data account authorization transaction for the data account initiated by the manager corresponding to the data account; wherein the data account authorization transaction includes the account identification of the target account, and the authorization for the target account. Access permission information of the data account.

Step 504: In response to the data account authorization transaction, determine whether the manager has management authority corresponding to the data account.

Step 506: If the manager has the management authority corresponding to the data account, fill in the corresponding relationship between the account ID of the target account and the access authority information as the access authorization information corresponding to the data account. to the authorization field in said data account.

For any data account created on the blockchain, the manager corresponding to the data account can initiate a data account authorization transaction for the data account. In this case, the blockchain node in the blockchain can receive the data account authorization transaction.

Wherein, the above-mentioned data account authorization transaction may include the account identification of the target account that can be authorized with access rights to the above-mentioned data account, and the access rights information for the data account authorized to the target account.

When the above-mentioned blockchain node receives the above-mentioned data account authorization transaction, it can respond to the data account authorization transaction and determine whether the above-mentioned manager who initiated the data account authorization transaction has the management authority corresponding to the above-mentioned data account.

If the above-mentioned manager has the management authority corresponding to the above-mentioned data account, the corresponding relationship between the account ID of the above-mentioned target account and the above-mentioned access permission information can be filled in the data account as the access authorization information corresponding to the data account. Authorization field.

In one embodiment shown, the access authorization information corresponding to the data account may include a correspondence between the account identification of at least one target account and the access rights information for the data account authorized to the at least one target account, An access authorization list (also called an access control list, Access Control List, ACL). It should be noted that the account ID of the at least one target account and the access permission information for the data account authorized to the at least one target account are in one-to-one correspondence.

In an embodiment shown, for any target account, the corresponding relationship between the account identification of the target account and the access permission information for a certain data account authorized to the target account can be determined through the key-value key. Expressed in the form of a value pair; the key in the key-value pair can be the account ID of the target account, and the value can be the access permission information authorized to the target account for the data account. Correspondingly, the above-mentioned access authorization list may be a Map list composed of key-value pairs corresponding to the above-mentioned at least one target account; the key in the key-value pair in the Map list is the account of the at least one target account. Identification, value is the access permission information for the data account authorized to the at least one target account.

In actual applications, the above access permission information may specifically be an access certificate (Access Certificate, AC). In order to ensure the data security of the access permission information, improve the usability of the access permission information, and save storage space, the specific contents stored in the above access authorization list may be the account ID of at least one target account, and the number authorized to the at least one target account. The corresponding relationship between the Hash values of the access permission information of the data account.

Continuing to refer to Figure 4, the account structure of the data account shown in Figure 4 may specifically include an Identity field, a Balance field, an AuthMap field, an ACL field, a SchemaHash field, and a Storage field. Among them, the ACL field can be used to maintain access authorization information corresponding to the data account (for example: access authorization list).

In one embodiment shown, the target account may include a user account registered in the blockchain; or a contract account corresponding to a smart contract deployed on the blockchain.

The process of accessing data accounts by user accounts and contract accounts is explained in detail below.

(1)User account access data account

In conjunction with the data account access authorization method shown in Figure 5, please refer to Figure 6, which is a flow chart of another data account access authorization method according to an exemplary embodiment of this specification.

Step 602: Receive a data account authorization transaction for the data account initiated by the manager corresponding to the data account; wherein the data account authorization transaction includes the account identification of the user account registered by the user in the blockchain , and the access permission information authorized to the user account for the data account.

Step 604: In response to the data account authorization transaction, determine whether the manager has management authority corresponding to the data account.

Step 606: If the manager has the management authority corresponding to the data account, fill in the corresponding relationship between the account ID of the user account and the access authority information as the access authorization information corresponding to the data account. to the authorization field in said data account.

For the specific implementation of steps 602 to 606, reference can be made to steps 502 to 506, which will not be described again in this specification.

Please refer to FIG. 7 , which is a flow chart of another data account access authorization method according to an exemplary embodiment of this specification.

Step 702: Receive a data account authorization transaction for the data account initiated by the administrator corresponding to the user account registered in the blockchain; wherein the data account authorization transaction includes the account identification of the user account , and the access permission information authorized to the user account for the data account.

Step 704: In response to the data account authorization transaction, determine whether the manager has management authority corresponding to the data account.

Step 706: If the administrator has management rights corresponding to the data account, generate an approval event corresponding to the access rights authorized to the user account for the data account, so that the access rights corresponding to the data account are generated. When obtaining the approval event, the manager approves the access rights authorized to the user account for the data account, and returns the approval result.

Step 708: In response to the received approval result, when the approval result indicates that the approval is passed, use the corresponding relationship between the account ID of the user account and the access permission information as the access authorization corresponding to the data account. information to populate the authorization fields in said data account.

For any data account created on the blockchain, the manager corresponding to any user account registered by the user in the blockchain can also initiate a data account authorization transaction for the data account. In this case, the blockchain node in the blockchain can receive the data account authorization transaction.

Wherein, the above-mentioned data account authorization transaction may include the account identification of the above-mentioned user account, and the access rights information authorized to the above-mentioned user account for the above-mentioned data account.

When the above-mentioned blockchain node receives the above-mentioned data account authorization transaction, it can respond to the data account authorization transaction and determine whether the above-mentioned manager who initiated the data account authorization transaction has the management authority corresponding to the above-mentioned user account.

If the above-mentioned administrator has management rights corresponding to the above-mentioned user account, it can generate an approval event corresponding to the access rights authorized to the user account for the above-mentioned data account, and publish the approval event to the above-mentioned blockchain, thereby enabling The manager corresponding to the data account can obtain the approval event from the blockchain, approve the access rights authorized to the user account for the data account accordingly, and return the approval result.

When the above-mentioned blockchain node receives the above-mentioned approval result, it may respond to the approval result, and when the approval result indicates that the approval is passed, the corresponding relationship between the account identification of the above-mentioned user account and the above-mentioned access permission information shall be used as the corresponding relationship with the above-mentioned The access authorization information corresponding to the data account is filled in the authorization field in the data account.

It should be noted that after the user account is registered in the blockchain, the corresponding public and private key pair can be assigned to the user account. That is, the manager corresponding to the user account can hold the public-private key pair, the private key can be used to sign transactions initiated by the manager, and the public key can be used to verify the signature. Public keys can be broadcast in the blockchain.

In an embodiment shown, in the case where the account structure of the above-mentioned data account also includes a management field for maintaining the public key of the manager of the data account, when determining whether the manager who initiated the above-mentioned data account authorization transaction When you have the management authority corresponding to the above data account, you can specifically determine whether the public key of the manager matches the public key of the manager of the data account maintained in the management field. If so, you can determine that the manager has the same The management permissions corresponding to this data account.

In one embodiment shown, the above-mentioned management field can be specifically used to maintain the corresponding relationship between the public key of at least one manager of the data account and the weight assigned to the public key of the at least one manager. In this case, when determining whether the public key of the manager who initiated the above-mentioned data account authorization transaction matches the public key of the manager of the data account maintained in the management field, it may be specifically based on the public key maintained in the management field. Correspondence relationship, determine whether the weight corresponding to the public key of the manager reaches a preset threshold, and if so, it can be determined that the public key of the manager matches the public key of the manager of the data account.

In practical applications, the data account authorization transaction can be signed based on the private key of the manager who initiated the above data account authorization transaction. Correspondingly, before responding to the data account authorization transaction, the public key of the manager can be determined first, and then the signature is verified based on the public key of the manager. If the verification is passed, a response can be made.

Similarly, the account structure of the user account may also include a management field used to maintain the public key of the administrator of the user account. In this case, when determining whether the manager who initiated the above-mentioned data account authorization transaction has the management authority corresponding to the user account, the public key of the manager and the management of the user account maintained in the management field may also be determined. Whether the party's public key matches, if so, it can be determined that the manager has the management rights corresponding to the user account.

It should be noted that a method similar to the access authorization method of the data account shown in Figure 6 or 7 can also be used to perform all or all access authorization information corresponding to the data account maintained in the authorization field in the above data account. Partial update; or, revoke all or part of the authorization for the access authorization information corresponding to the data account maintained in the authorization field in the above-mentioned data account (for example: delete or mark the authorization as revoked).

Based on the data account access authorization method shown in Figure 6 or 7, please refer to Figure 8, which is a flow chart of a data account access method according to an exemplary embodiment of this specification.

The above data account access method may include the following steps:

Step 802: Receive the data account access transaction from the user account for the data account; wherein the data account access transaction includes the data identification of the target data to be accessed, and the data account authorized to the user account for the data account. access rights information.

Step 804: In response to the data account access transaction, determine whether the access permission information in the data account access transaction matches the access authorization information corresponding to the data account maintained in the authorization field in the data account.

Step 806: If the access permission information matches the access authorization information corresponding to the data account, determine that the user account has the access permission of the data account, and search the business data maintained in the data account. The data identifies the corresponding target data.

For any data account created on the blockchain, the blockchain node in the above-mentioned blockchain can receive the data account access transaction of any user account for the data account.

Wherein, the above-mentioned data account access transaction may include the data identification of the data to be accessed (which may be called target data), and the access permission information authorized to the above-mentioned user account for the data account.

When the above-mentioned blockchain node receives the above-mentioned data account access transaction, it can respond to the data account access transaction and determine whether the access permission information in the data account access transaction is consistent with the authorization field maintained in the data account. Whether the access authorization information corresponding to the data account matches.

If the two match, it can be determined that the above-mentioned user account has access rights to the above-mentioned data account, so that the above-mentioned target data corresponding to the data identifier in the above-mentioned data account access transaction can be found in the business data maintained in the data account.

Since the access authorization information corresponding to the data account may include the corresponding relationship between the account identification of at least one target account and the access permission information authorized to the at least one target account for the data account, the access authorization list is shown in In an implementation manner, the above-mentioned data account access transaction may also include the account identification of the above-mentioned user account.

In the above case, when determining whether the access permission information in the above-mentioned data account access transaction matches the access authorization information corresponding to the data account maintained in the authorization field in the above-mentioned data account, the specific method may first be based on the information in the data account. The access authorization list maintained in the authorization field, looks for the access permission information corresponding to the account ID of the user account, and then determines whether the access permission information in the data account access transaction matches the found access permission information. If so, then It can be determined that the access permission information matches the access authorization information corresponding to the data account.

Since the business data maintained in the data account can be organized into the form of a Merkle tree and stored in the local database carried by the blockchain node, and the Merkle tree stores key-value pairs, in an implementation shown In this method, the data identifier of the target data may include the key of the target data.

In the above case, when searching for the above target data corresponding to the data identifier in the above data account access transaction in the business data maintained in the above data account, the above Merkle stored in the local database carried by the above blockchain node can be used. In the tree, search for the value corresponding to the key of the target data, and determine the found value as the target data.

In an embodiment shown, the above-mentioned access permission information may also include a validity period, and a data identification set of data authorized to the above-mentioned user account access permission.

In the above case, when it is determined that the access permission information matches the access authorization information corresponding to the data account, it can also be determined based on the limited period in the access permission information whether the access permission information is valid. If so, then It may be further determined whether the above-mentioned data identification set in the access permission information includes the data identification of the above-mentioned target data, and if so, it may be determined that the above-mentioned user account has the access permission for the data account.

(2) Contract account access data account

In conjunction with the data account access authorization method shown in Figure 5, please refer to Figure 9, which is a flow chart of another data account access authorization method according to an exemplary embodiment of this specification.

Step 902: Receive a data account authorization transaction for the data account initiated by the manager corresponding to the data account; wherein, the data account authorization transaction includes a contract account corresponding to the smart contract deployed on the blockchain The account identification, and the access permission information authorized to the contract account for the data account.

Step 904: In response to the data account authorization transaction, determine whether the manager has management authority corresponding to the data account.

Step 906: If the manager has the management authority corresponding to the data account, fill in the corresponding relationship between the account ID of the contract account and the access authority information as the access authorization information corresponding to the data account. to the authorization field in said data account.

For the specific implementation of steps 902 to 906, reference can be made to steps 502 to 506, which will not be described again in this specification.

Please refer to FIG. 10 , which is a flow chart of another data account access authorization method according to an exemplary embodiment of this specification.

Step 1002: Receive a data account authorization transaction for the data account initiated by the manager corresponding to the contract account corresponding to the smart contract deployed on the blockchain; wherein the data account authorization transaction includes the data account authorization transaction of the contract account. Account identification, and access permission information for the data account authorized to the contract account.

Step 1004: In response to the data account authorization transaction, determine whether the manager has management authority corresponding to the contract account.

Step 1006: If the management party has management rights corresponding to the contract account, generate an approval event corresponding to the access rights authorized to the contract account for the data account, so that the access rights corresponding to the data account are generated. When the management party obtains the approval event, it approves the access rights authorized to the contract account for the data account, and returns the approval result.

Step 1008: In response to the received approval result, when the approval result indicates that the approval is passed, use the corresponding relationship between the account identification of the contract account and the access permission information as the access authorization corresponding to the data account. information to populate the authorization fields in said data account.

For any data account created on the blockchain, the manager corresponding to any contract account corresponding to the smart contract deployed on the blockchain can also initiate a data account authorization transaction for the data account. In this case, the blockchain node in the blockchain can receive the data account authorization transaction.

Wherein, the above-mentioned data account authorization transaction may include the account identification of the above-mentioned contract account, and the access permission information authorized to the contract account for the above-mentioned data account.

When the above-mentioned blockchain node receives the above-mentioned data account authorization transaction, it can respond to the data account authorization transaction and determine whether the above-mentioned manager who initiated the data account authorization transaction has the management authority corresponding to the above-mentioned contract account.

If the above-mentioned manager has the management rights corresponding to the above-mentioned contract account, it can generate an approval event corresponding to the access rights authorized to the contract account for the above-mentioned data account, and publish the approval event to the above-mentioned blockchain, thereby enabling The manager corresponding to the data account can obtain the approval event from the blockchain, approve the access rights authorized to the contract account for the data account accordingly, and return the approval results.

When the above-mentioned blockchain node receives the above-mentioned approval result, it may respond to the approval result and, when the approval result indicates that the approval is passed, use the corresponding relationship between the account identification of the above-mentioned contract account and the above-mentioned access permission information as the corresponding relationship with the above-mentioned The access authorization information corresponding to the data account is filled in the authorization field in the data account.

It should be noted that after the smart contract is deployed on the blockchain, the corresponding public and private key pair can be assigned to the contract account corresponding to the smart contract. That is, the manager corresponding to the contract account can hold the public-private key pair, the private key can be used to sign transactions initiated by the manager, and the public key can be used to verify the signature. Public keys can be broadcast in the blockchain.

Similarly, the account structure of the above-mentioned contract account may also include a management field used to maintain the public key of the manager of the contract account. In this case, when determining whether the manager who initiated the above-mentioned data account authorization transaction has the management authority corresponding to the contract account, it is also possible to determine whether the manager's public key and the management of the contract account maintained in the management field Whether the party's public key matches, if so, it can be determined that the manager has the management authority corresponding to the contract account.

Based on the data account access authorization method shown in Figure 9 or 10, please refer to Figure 11, which is a flow chart of a data account access method according to an exemplary embodiment of this specification.

The above data account access method may include the following steps:

Step 1102: Receive the data account access transaction from the contract account for the data account; wherein the data account access transaction includes the data identification of the target data to be accessed, and the data account authorized to the contract account for the data account. access rights information.

Step 1104: In response to the data account access transaction, determine whether the access permission information in the data account access transaction matches the access authorization information corresponding to the data account maintained in the authorization field in the data account.

Step 1106: If the access permission information matches the access authorization information corresponding to the data account, determine that the contract account has the access permission of the data account, and search the business data maintained in the data account. The data identifies the corresponding target data.

For any data account created on the blockchain, the blockchain node in the above-mentioned blockchain can receive the data account access transaction of any contract account for the data account.

Wherein, the above-mentioned data account access transaction may include the data identification of the data to be accessed (which may be called target data), and the access permission information authorized to the above-mentioned contract account for the data account.

If the two match, it can be determined that the above-mentioned contract account has access rights to the above-mentioned data account, so that the above-mentioned target data corresponding to the data identification in the above-mentioned data account access transaction can be found in the business data maintained in the data account.

Since the access authorization information corresponding to the data account may include the corresponding relationship between the account identification of at least one target account and the access permission information authorized to the at least one target account for the data account, the access authorization list is shown in In an implementation manner, the above-mentioned data account access transaction may also include the account identification of the above-mentioned contract account.

In the above case, when determining whether the access permission information in the above-mentioned data account access transaction matches the access authorization information corresponding to the data account maintained in the authorization field in the above-mentioned data account, the specific method may first be based on the information in the data account. Use the access authorization list maintained in the authorization field to find the access permission information corresponding to the account ID of the contract account, and then determine whether the access permission information in the data account access transaction matches the found access permission information. If so, then It can be determined that the access permission information matches the access authorization information corresponding to the data account.

In an embodiment shown, the above-mentioned access permission information may also include a validity period, and a data identification set of data authorized to the above-mentioned contract account access permission.

In the above case, when it is determined that the access permission information matches the access authorization information corresponding to the data account, it can also be determined based on the limited period in the access permission information whether the access permission information is valid. If so, then It can be further determined whether the above-mentioned data identification set in the access permission information includes the data identification of the above-mentioned target data, and if so, it can be determined that the above-mentioned contract account has the access permission of the data account.

In practical applications, the business data required for contract calculations by smart contracts deployed on the blockchain usually changes based on changes in actual conditions. In order to ensure the correctness of the business data maintained in the data account created on the blockchain and avoid errors when the smart contract performs contract calculations based on the business data, it is necessary to perform business data maintenance on the data account created on the blockchain. renew.

In an embodiment shown, based on the data account creation method shown in Figure 3, please refer to Figure 12. Figure 12 is a flow chart of a data account update method shown in an exemplary embodiment of this specification. picture.

The above data account update method may include the following steps:

Step 1202: Receive a data account update transaction for the data account initiated by the manager corresponding to the data account; wherein the data account update transaction includes the updated business data.

Step 1204: In response to the data account update transaction, determine whether the manager has management authority corresponding to the data account.

Step 1206: If the management party has the management authority corresponding to the data account, write the updated business data into the Merkle tree stored in the local database to update the Merkle tree. The business data that has been written is updated, and the Hash value of the root node of the updated Merkle tree is filled into the data storage field in the data account.

For any data account created on the blockchain, the manager corresponding to the data account can initiate a data account update transaction for the data account. In this case, the data account update transaction can be received by the blockchain nodes in the blockchain.

Since the above data account can be used to maintain the business data required for contract calculation by smart contracts deployed on the above blockchain, in this case, the above data account update transaction can include the updated business data.

When the above-mentioned blockchain node receives the above-mentioned data account update transaction, it may respond to the data account update transaction and determine whether the above-mentioned manager who initiated the data account update transaction has the management authority corresponding to the above-mentioned data account.

If the above-mentioned manager has the management authority corresponding to the above-mentioned data account, the above-mentioned business data maintained in the data account can be updated based on the above-mentioned updated business data.

Since the above-mentioned business data maintained in the above-mentioned data account can be organized into the form of a Merkle tree and stored in the local database carried by the above-mentioned blockchain node, in this case, the updated above-mentioned business data can be written into the Merkle tree. tree to update the business data that has been written on the Merkle tree, and fill the hash value of the root node of the updated Merkle tree into the data storage field in the data account. Therefore, the data maintained in the data storage field in the data account can be updated from the hash value of the root node of the Merkle tree in which the original business data is written to the Merkle tree in which the updated business data is written. The Hash value of the root node.

It should be noted that the above-mentioned data account update transaction may also include data description information corresponding to the updated above-mentioned business data. In this case, while updating the above-mentioned business data maintained in the above-mentioned data account, the data maintained in the data description field in the above-mentioned data account can also be replaced by the data description information corresponding to the original business data. The Hash value is updated to the Hash value of the data description information corresponding to the updated business data.

In practical applications, the native transaction types supported by the blockchain can be expanded to extend native transactions with new functions in the blockchain. It should be noted that the expanded native transaction with new functions can specifically be a native transaction that is independent of transfer transactions or smart contract call transactions.

In an embodiment shown, the native transaction types supported by the blockchain can be extended to extend a native transaction for creating a data account in the blockchain, which can be called a data account creation transaction. .

For example, for a blockchain using the UTXO model, a data account creation transaction dedicated to creating a data account can be extended based on the transfer transactions it supports; while for a blockchain using the account model, In other words, based on the transfer transactions, smart contract creation transactions and smart contract call transactions it supports, a data account creation transaction dedicated to creating data accounts can be expanded.

In the same way, the native transaction types supported by the blockchain can be expanded to extend a native transaction in the blockchain for updating the business data maintained in the data account, which can be called a data account. Update transaction.

The native transaction types supported by the blockchain can be expanded to include a native transaction for authorizing access to the data account in the blockchain, which can be called a data account authorization transaction.

The native transaction types supported by the blockchain can be expanded to extend a native transaction for accessing the data account in the blockchain, which can be called a data account access transaction.

Among them, the transaction formats of the above-mentioned data account creation transactions, the above-mentioned data account update transactions, the above-mentioned data account authorization transactions, and the above-mentioned data account access transactions are not specifically limited in this manual; in practical applications, compatible blockchain current transactions can be used. Some transaction formats can also be redefined into new transaction formats.

Please refer to FIG. 13 , which is a schematic diagram of the hardware structure of a device according to an exemplary embodiment of this specification.

As shown in Figure 13, at the hardware level, the above-mentioned equipment includes a processor 1302, an internal bus 1304, a network interface 1306, a memory 1308, and a non-volatile memory 1310. Of course, it may also include other hardware required for services. One or more embodiments of this specification can be implemented based on software. For example, the processor 1302 reads the corresponding computer program from the non-volatile memory 1310 into the memory 1308 and then runs it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each Logic modules can also be hardware or logic devices.

Please refer to FIG. 14 , which is a block diagram of a data account creation device according to an exemplary embodiment of this specification.

The above-mentioned data account creation device can be applied to the device shown in Figure 13 to implement the technical solution of this specification. The device can be used as a blockchain node in the blockchain; the account types supported by the blockchain include data accounts; the data account is used to maintain the smart contracts deployed on the blockchain required for contract calculations. Business data; the data account creation device may include:

The receiving module 1402 receives a data account creation transaction used to create the data account; wherein the data account creation transaction includes business data required for contract calculation by smart contracts deployed on the blockchain;

The creation module 1404 creates a data account on the blockchain in response to the data account creation transaction; and adds the business data to the data account for maintenance.

Optionally, the business data maintained in the data account is organized into the form of a Merkle tree and stored in the local database carried by the blockchain node; the account structure of the data account includes a method for maintaining the The data storage field of the Hash value of the root node of the Merkel tree;

The creation module 1404:

Write the business data to the Merkle tree stored in the local database to update the Merkle tree, and fill the Hash value of the root node of the updated Merkle tree into the data Data storage fields in accounts.

Optionally, the service data includes service data content and a data access code corresponding to the service data content;

The creation module 1404:

Write the corresponding relationship between the business data content and the data access code into the Merkle tree stored in the local database to update the Merkle tree, and store the updated Merkle tree The hash value of the root node is filled into the data storage field in the data account.

Optionally, the data access code includes interface code for reading and writing business data content.

Optionally, the data account creation transaction also includes data description information corresponding to the business data; the account structure of the data account also includes a data description field used to maintain the Hash value of the data description information;

The device also includes:

The calculation module calculates the hash value of the data description information corresponding to the business data in the data account creation transaction, and fills the calculated hash value into the data description field in the data account.

Optionally, the device also includes:

The second receiving module receives a data account update transaction for the data account initiated by the manager corresponding to the data account; wherein the data account update transaction includes the updated business data;

A second determination module, in response to the data account update transaction, determines whether the manager has management authority corresponding to the data account;

Update module, if the management party has the management authority corresponding to the data account, writes the updated business data into the Merkle tree stored in the local database to update the Merkle tree The business data that has been written is updated, and the Hash value of the root node of the updated Merkle tree is filled into the data storage field in the data account.

Optionally, the account structure of the data account includes an authorization field used to maintain access authorization information corresponding to the data account;

The device also includes:

The third receiving module receives a data account authorization transaction for the data account initiated by the manager corresponding to the data account; wherein the data account authorization transaction includes the account identification of the target account, and authorization to the target account access permission information for the data account;

A third determination module, in response to the data account authorization transaction, determines whether the manager has management authority corresponding to the data account;

The authorization module, if the manager has the management authority corresponding to the data account, fills in the corresponding relationship between the account identification of the target account and the access authority information as the access authorization information corresponding to the data account. to the authorization field in said data account.

Optionally, the access authorization information corresponding to the data account includes an access authorization consisting of the account identification of at least one target account and the corresponding relationship of the access permission information authorized to the at least one target account for the data account. list.

Optionally, the corresponding relationship is a key-value pair; the access authorization list is a Map list composed of key-value pairs corresponding to the at least one target account; wherein, the key-value key The key of the value pair is the account identifier of the at least one target account, and the value of the key-value pair is the access permission information for the data account authorized to the at least one target account.

Optionally, the target account includes a user account registered by the user in the blockchain; or a contract account corresponding to a smart contract deployed on the blockchain.

Optionally, the account structure of the data account also includes any one or more fields shown below:

an account identification field used to maintain the account identification of the data account;

a balance field used to maintain the balance of assets held by said data account;

A management field used to maintain the public key of the administrator of the data account.

Optionally, the data account creation transaction is a native transaction supported by the blockchain for creating a data account; the data account authorization transaction is a transaction supported by the blockchain for accessing the data account. Authorized native transactions.

As for the device embodiment, it basically corresponds to the method embodiment, so for relevant details, please refer to the partial description of the method embodiment.

The device embodiments described above are only illustrative. The modules described as separate components may or may not be physically separated. The components shown as modules may or may not be physical modules, that is, they may be located in One place, or it can be distributed to multiple network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the technical solution in this specification.

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 computer, which may be in the form of a personal computer, a laptop, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, or a game controller. desktop, tablet, wearable device, or a combination of any of these devices.

In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

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

Computer-readable media includes both persistent and non-volatile, removable and non-removable media that can be implemented by any method or technology for storage of information. Information may be computer-readable instructions, data structures, modules of programs, 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 tape cartridges, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium, can be used to store information that can be accessed by computing devices. As defined in this article, computer-readable media does not include transient computer-readable media (transitory media), such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "comprises," or any other variation thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements not only includes those elements, but also includes Other elements are not expressly listed or are inherent to the process, method, article or equipment. Without further limitation, an element defined by the statement "comprises a..." does not exclude the presence of additional identical elements in a process, method, article, or device that includes the stated element.

The foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desired results. Additionally, the processes depicted in the figures do not necessarily require the specific order shown, or sequential order, to achieve desirable results. Multitasking and parallel processing are also possible or may be advantageous in certain implementations.

The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the one or more embodiments of this specification. As used in one or more embodiments of this specification and the appended claims, the singular forms "a," "the" and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will also be understood that the term "and/or" as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

It should be understood that although one or more embodiments of this specification may use the terms first, second, third, etc. to describe various information, the information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of one or more embodiments of this specification, the first information may also be called second information, and similarly, the second information may also be called first information. Depending on the context, the word "if" as used herein may be interpreted as "when" or "when" or "in response to determining."

The above are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. Within the spirit and principles of one or more embodiments of this specification, Any modifications, equivalent substitutions, improvements, etc. shall be included in the scope of protection of one or more embodiments of this specification.

Claims

A data account creation method, applied to blockchain nodes; the account types supported by the blockchain include data accounts; the data account is used to maintain the smart contracts deployed on the blockchain required for contract calculations Business data; the methods include:

Receive a data account creation transaction used to create the data account; wherein the data account creation transaction includes business data required for contract calculation by smart contracts deployed on the blockchain;

creating a data account on the blockchain in response to the data account creation transaction; and,

Add the business data to the data account for maintenance.
According to the method of claim 1, the business data maintained in the data account is organized into the form of a Merkel tree and stored in a local database carried by the blockchain node; the account structure of the data account includes A data storage field used to maintain the Hash value of the root node of the Merkel tree;

Adding the business data to the data account for maintenance includes:

Write the business data to the Merkle tree stored in the local database to update the Merkle tree, and fill the Hash value of the root node of the updated Merkle tree into the data Data storage fields in accounts.
The method according to claim 2, wherein the business data includes business data content and a data access code corresponding to the business data content;

writing the business data into the Merkle tree stored in the local database to update the Merkle tree, and filling the Hash value of the root node of the updated Merkel tree into the The data storage fields in the data account include:

Write the corresponding relationship between the business data content and the data access code into the Merkle tree stored in the local database to update the Merkle tree, and store the updated Merkle tree The hash value of the root node is filled into the data storage field in the data account.
According to the method of claim 3, the data access code includes an interface code for reading and writing business data content.
According to the method of claim 2, the data account creation transaction further includes data description information corresponding to the business data; the account structure of the data account further includes data used to maintain the Hash value of the data description information. description field;

The method also includes:

Calculate the hash value of the data description information corresponding to the business data in the data account creation transaction, and fill the calculated hash value into the data description field in the data account.
The method of claim 2, further comprising:

Receive a data account update transaction for the data account initiated by the manager corresponding to the data account; wherein the data account update transaction includes the updated business data;

In response to the data account update transaction, determine whether the manager has management authority corresponding to the data account;

If the management party has the management authority corresponding to the data account, then the updated business data is written into the Merkle tree stored in the local database to update the Merkle tree that has been written. The business data entered is updated, and the Hash value of the root node of the updated Merkel tree is filled into the data storage field in the data account.
The method according to claim 1, the account structure of the data account includes an authorization field for maintaining access authorization information corresponding to the data account;

The method also includes:

Receive a data account authorization transaction for the data account initiated by the manager corresponding to the data account; wherein the data account authorization transaction includes the account identification of the target account, and the data authorized to the target account. Account access rights information;

In response to the data account authorization transaction, determine whether the manager has management authority corresponding to the data account;

If the manager has the management authority corresponding to the data account, the corresponding relationship between the account identification of the target account and the access authority information is filled in the Authorization fields in data accounts.
The method of claim 7, wherein the access authorization information corresponding to the data account includes an account identification of at least one target account and a correspondence of access permission information authorized to the at least one target account for the data account. Access authorization list composed of relationships.
The method according to claim 8, the corresponding relationship is a key-value pair; the access authorization list is a Map list composed of key-value pairs corresponding to the at least one target account; wherein, the The key of the key-value pair is the account identifier of the at least one target account, and the value of the key-value pair is the access permission information for the data account authorized to the at least one target account.
According to the method of claim 7, the target account includes a user account registered by the user in the blockchain; or a contract account corresponding to a smart contract deployed on the blockchain.
According to the method of claim 7, the account structure of the data account further includes any one or more fields shown below:

an account identification field used to maintain the account identification of the data account;

a balance field used to maintain the balance of assets held by said data account;

A management field used to maintain the public key of the administrator of the data account.
The method according to claim 7, the data account creation transaction is a native transaction supported by the blockchain for creating a data account; the data account authorization transaction is a transaction supported by the blockchain for all transactions. Use the above data account to perform native transactions for access authorization.
A data account creation device, applied to blockchain nodes; the account types supported by the blockchain include data accounts; the data account is used to maintain the smart contracts deployed on the blockchain required for contract calculations Business data; the device includes:

A receiving module that receives a data account creation transaction used to create the data account; wherein the data account creation transaction includes business data required for contract calculation by smart contracts deployed on the blockchain;

A creation module, in response to the data account creation transaction, creates a data account on the blockchain; and adds the business data to the data account for maintenance.
An electronic device including:

processor;

Memory used to store instructions executable by the processor;

Wherein, the processor implements the method according to any one of claims 1-12 by running the executable instructions.
A computer-readable storage medium having computer instructions stored thereon, which when executed by a processor implements the method according to any one of claims 1-12.