Method and apparatus for access authorization of data account

Abstract

The one or more embodiments of the specification provide a data account access authorization method and device, which is applied to a block chain node; an account type supported by the block chain includes a data account; the data account is used to maintain business data required for contract calculation of a smart contract deployed on the block chain; an account structure of the data account includes an authorization field used to maintain access authorization information corresponding to the data account; the method includes: receiving a data account authorization transaction initiated by a management party corresponding to the data account and directed to the data account; the data account authorization transaction includes an account identifier of a contract account and access permission information of the data account authorized to the contract account; in response to the data account authorization transaction, determining whether the management party has a management right corresponding to the data account; if yes, filling the correspondence between the account identifier of the contract account and the access permission information as the access authorization information corresponding to the data account into the authorization field in the data account.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of blockchain, and more particularly to a method and apparatus for authorizing access to a data account. Background Technology

[0002] The invention of smart contracts has lowered the barrier to entry for blockchain applications, and the launch of consortium blockchains has further accelerated the adoption of blockchain by enterprises. However, enterprises face significant technical challenges in applying blockchain, especially as their business logic becomes increasingly complex and business data continues to accumulate. Due to existing technological limitations and performance bottlenecks, complex business logic typically needs to be implemented through a single smart contract, which also needs to store a large amount of business data.

[0003] Therefore, the following problems are usually caused: First, the code size of smart contracts is large, and may even approach the upper limit of the virtual machine used to execute smart contracts; Second, if the smart contract is split into multiple sub-contracts to reduce the code size, cross-contract calls are required between these sub-contracts to execute business logic, which affects the execution performance of the business logic; Third, if the business logic implemented by the smart contract needs to be upgraded, a new smart contract needs to be deployed on the blockchain, that is, the upgraded business logic needs to be written into the new smart contract, and the business data in the original smart contract needs to be copied to the new smart contract so that the new smart contract is compatible with the business data in the original smart contract. Summary of the Invention

[0004] This specification provides one or more embodiments of the following technical solutions:

[0005] This specification provides a method for authorizing access to a data account, applied to a blockchain node; the blockchain supports account types including data accounts; the data account is used to maintain business data required for contract computation by smart contracts deployed on the blockchain; the account structure of the data account includes an authorization field for maintaining access authorization information corresponding to the data account; the method includes:

[0006] Receive a data account authorization transaction initiated by the administrator corresponding to the data account for the data account; wherein, the data account authorization transaction includes the account identifier of the contract account corresponding to the smart contract deployed on the blockchain, and the access permission information for the data account authorized to the contract account;

[0007] In response to the data account authorization transaction, determine whether the administrator has the management authority corresponding to the data account;

[0008] If the administrator has management permissions corresponding to the data account, the correspondence between the account identifier of the contract account and the access permission information is used as the access authorization information corresponding to the data account and filled into the authorization field of the data account.

[0009] This specification also provides a method for authorizing access to a data account, applied to a blockchain node; the blockchain supports account types including data accounts; the data account is used to maintain business data required for contract computation by smart contracts deployed on the blockchain; the account structure of the data account includes an authorization field for maintaining access authorization information corresponding to the data account; the method includes:

[0010] The system receives a data account authorization transaction for the data account initiated by the administrator of the contract account corresponding to the smart contract deployed on the blockchain; wherein the data account authorization transaction includes the account identifier of the contract account and the access permission information for the data account authorized to the contract account;

[0011] In response to the data account authorization transaction, determine whether the administrator has the management authority corresponding to the contract account;

[0012] If the manager has management permissions corresponding to the contract account, an approval event is generated corresponding to the access permissions granted to the contract account for the data account, so that when the manager corresponding to the data account receives the approval event, the manager approves the access permissions granted to the contract account for the data account and returns the approval result.

[0013] In response to the received approval result, when the approval result indicates that the approval is approved, the correspondence between the account identifier of the contract account and the access permission information is used as the access authorization information corresponding to the data account and filled into the authorization field of the data account.

[0014] This specification also provides a data account access authorization device applied to a blockchain node; the blockchain supports account types including data accounts; the data account is used to maintain business data required for contract computation by smart contracts deployed on the blockchain; the account structure of the data account includes an authorization field for maintaining access authorization information corresponding to the data account; the device includes:

[0015] The receiving module receives a data account authorization transaction initiated by the administrator corresponding to the data account; wherein the data account authorization transaction includes the account identifier of the contract account corresponding to the smart contract deployed on the blockchain, and the access permission information for the data account authorized to the contract account;

[0016] The determination module, in response to the data account authorization transaction, determines whether the administrator has the management authority corresponding to the data account;

[0017] In the authorization module, if the administrator has management permissions corresponding to the data account, the correspondence between the account identifier of the contract account and the access permission information is used as the access authorization information corresponding to the data account and filled into the authorization field of the data account.

[0018] This specification also provides a data account access authorization device applied to a blockchain node; the blockchain supports account types including data accounts; the data account is used to maintain business data required for contract computation by smart contracts deployed on the blockchain; the account structure of the data account includes an authorization field for maintaining access authorization information corresponding to the data account; the device includes:

[0019] The receiving module receives a data account authorization transaction initiated by the administrator of the contract account corresponding to the smart contract deployed on the blockchain, which is for the data account; wherein the data account authorization transaction includes the account identifier of the contract account and the access permission information for the data account authorized to the contract account;

[0020] The determination module, in response to the data account authorization transaction, determines whether the administrator has the management authority corresponding to the contract account;

[0021] The approval module, if the manager has management permissions corresponding to the contract account, generates an approval event corresponding to the access permissions granted to the contract account for the data account, so that when the manager corresponding to the data account receives the approval event, he / she approves the access permissions granted to the contract account for the data account and returns the approval result.

[0022] The authorization module, in response to the received approval result, when the approval result indicates that the approval is passed, fills the authorization field in the data account with the correspondence between the account identifier of the contract account and the access permission information as the access authorization information corresponding to the data account.

[0023] This specification also provides an electronic device, including:

[0024] processor;

[0025] Memory used to store processor-executable instructions;

[0026] The processor executes the executable instructions to implement the steps of the method as described in any of the preceding descriptions.

[0027] This specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the method as described in any of the preceding claims.

[0028] In the above technical solution, the blockchain node in the blockchain can respond to the received data account authorization transaction for the data account. When it is determined that the administrator who initiated the data account authorization transaction has the management authority corresponding to the data account, the correspondence between the account identifier of the contract account corresponding to the smart contract deployed on the blockchain in the data account authorization transaction and the access permission information of the contract account for the data account is used as the access authorization information corresponding to the data account and filled into the authorization field of the data account.

[0029] By adopting the above method, the contract code of a smart contract can be separated from the business data required for contract computation, thereby achieving the following objectives: First, the contract account corresponding to the smart contract only needs to maintain the contract code of the smart contract. Therefore, smart contracts with complex business logic can be broken down into multiple simpler sub-contracts, reducing the costs of smart contract development, testing, and upgrades. Second, user accounts registered in the blockchain, as well as contract accounts corresponding to smart contracts deployed on the blockchain, can directly access the business data maintained in the data account created on the blockchain. That is, data sharing between user accounts and contract accounts can be achieved through the data account, saving the execution overhead of smart contracts, enabling parallel access to business data, and improving the transaction throughput of the blockchain. Third, centralized maintenance of business data by the data account can realize the assetization of business data and facilitate the acquisition of large amounts of business data for data analysis, AI training, and other processing.

[0030] In addition, access control can be implemented for the data account by the contract account corresponding to the smart contract deployed on the blockchain, allowing only the contract account indicated by the access authorization information corresponding to the data account maintained in the data account to access the data account. Attached Figure Description

[0031] Figure 1 This is a diagram illustrating the account structure of a user account.

[0032] Figure 2 This is a schematic diagram of the account structure of a contract account.

[0033] Figure 3 This is a flowchart illustrating an exemplary embodiment of a data account creation method in this specification.

[0034] Figure 4 This is a schematic diagram illustrating the account structure of a data account according to an exemplary embodiment of this specification.

[0035] Figure 5 This is a flowchart illustrating an exemplary embodiment of a data account access authorization method.

[0036] Figure 6 This is a flowchart illustrating an exemplary embodiment of this specification, showing another method for authorizing access to a data account.

[0037] Figure 7 This is a flowchart illustrating an exemplary embodiment of this specification, showing another method for authorizing access to a data account.

[0038] Figure 8 This is a flowchart illustrating an exemplary embodiment of a data account access method in this specification.

[0039] Figure 9 This is a flowchart illustrating an exemplary embodiment of this specification, showing another method for authorizing access to a data account.

[0040] Figure 10 This is a flowchart illustrating an exemplary embodiment of this specification, showing another method for authorizing access to a data account.

[0041] Figure 11 This is a flowchart illustrating another data account access method as shown in an exemplary embodiment of this specification.

[0042] Figure 12 This is a flowchart illustrating an exemplary embodiment of a data account update method in this specification.

[0043] Figure 13 This is a schematic diagram of the hardware structure of a device shown in an exemplary embodiment of this specification.

[0044] Figure 14 This is a block diagram illustrating an exemplary embodiment of a data account access authorization device.

[0045] Figure 15 This is a block diagram illustrating an alternative data account access authorization device according to an exemplary embodiment of this specification. Detailed Implementation

[0046] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

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

[0048] Blockchain is generally classified into three types: public blockchain, private blockchain, and consortium blockchain. Furthermore, combinations of these types are possible, such as a combination of private and consortium blockchains, or a combination of consortium and public blockchains.

[0049] Of the three types of blockchains mentioned above, public blockchains offer the highest degree of decentralization. Participants in a public blockchain (also known as nodes in the blockchain) can read data records on the chain, participate in transactions, and compete for the right to record new blocks. Moreover, nodes can freely join or leave the network and perform related operations.

[0050] In contrast, private blockchains have write permissions controlled by a specific organization or institution, and data read permissions are governed by the organization's regulations. That is, a private blockchain can be viewed as a weakly centralized system, with strict restrictions on the number of nodes and a relatively small number of nodes. This type of blockchain is more suitable for use within specific organizations.

[0051] Consortium blockchains fall between public and private blockchains, enabling "partial decentralization." Each node in a consortium blockchain typically has a corresponding entity or organization; nodes join the network through authorization and form a consortium of stakeholders to jointly maintain the operation of the blockchain.

[0052] In a blockchain network, a node is a logical communication entity; multiple nodes of different types can run on the same physical server or on different physical servers.

[0053] For data generated outside the blockchain, it can be constructed into a standard transaction format supported by the blockchain, and then published to the blockchain. All nodes in the blockchain network will reach a consensus on the transaction. After consensus is reached, the nodes acting as ledger nodes in the blockchain network can persistently store this transaction on the blockchain.

[0054] Current blockchain systems typically include two main transaction models: one is the UTXO (Unspent Transaction Output) model, and the other is the account model.

[0055] To achieve data notarization for both types of blockchains, the following notarization methods can typically be used:

[0056] For blockchains that use the UTXO model, the native transactions they support typically only include transfer transactions. During the transfer process based on a transfer transaction, users can fill in additional data in the transaction remarks (i.e., transfer remarks) of the transfer transaction to store the additional data on the blockchain.

[0057] For blockchains employing an account model, the blockchain data that needs to be stored and maintained typically includes block data and account status data corresponding to blockchain accounts. Block data can further include block header data, block transaction data, and transaction receipts corresponding to those transactions, etc. When storing the various types of blockchain data shown above, they can usually be organized into a Merkle tree in a database as key-value pairs. When querying the various types of blockchain data stored on a blockchain node, the keys of these data can be used as query indexes to traverse the Merkle tree for efficient data retrieval.

[0058] In blockchains that adopt an account model, smart contracts for data notarization can be deployed on the blockchain. Users can call smart contracts to store the data that needs to be notarized as the account state of the contract account corresponding to the smart contract in the Merkle tree corresponding to the smart contract.

[0059] For example, a special Merkle tree, called an MPT tree, is typically used to store and maintain blockchain data. Account state data can be organized into an MPT state tree (commonly known as the world state) and stored in the database. The MPT state tree stores key-value pairs with the account address as the key and the account state data as the value. The data stored in the contract account corresponding to a smart contract is further organized into a Storage tree (an MPT storage tree used for data storage) and stored in the database. The hash value of the root node of the Storage tree is used as part of the account state data corresponding to that contract account and populated into the MPT state tree. The hash of the root node of the MPT state tree is then used as the authentication root and further populated into the block header. When a user needs to store data, they can call a smart contract to store the data to be stored as the account state data of the contract account corresponding to that smart contract in the Storage tree corresponding to that smart contract.

[0060] In the blockchain field, accounts are generally divided into two categories: user accounts and contract accounts. User accounts are accounts directly controlled by users and are also known as external accounts. Contract accounts, on the other hand, are accounts created by users through user accounts and contain contract code (i.e., smart contracts).

[0061] For accounts in a blockchain, their state is typically maintained through a structure. When a transaction in a block is executed, the state of the account associated with that transaction in the blockchain usually changes as well.

[0062] In one example, the account structure typically includes fields such as Balance, Nonce, Code, and Storage. Among them:

[0063] The Balance field is used to maintain the current account balance.

[0064] The Nonce field is used to maintain the number of transactions for this account; it is a counter used to ensure that each transaction can be processed exactly once, effectively preventing replay attacks.

[0065] The Code field is used to maintain the contract code of the account; in practice, the Code field usually only maintains the hash value of the contract code; therefore, the Code field is often also called the CodeHash field.

[0066] The Storage field is used to maintain the storage content of this account (the default field value is empty); for contract accounts, a separate storage space is usually allocated to store the storage content of the contract account; this separate storage space is usually referred to as the account storage of the contract account.

[0067] The stored content of a contract account is typically constructed into an MPT (Merkle Patricia Trie) tree data structure and stored in the aforementioned independent storage space; the MPT tree constructed based on the stored content of the contract account is also commonly referred to as the Storage tree. The Storage field usually only maintains the root node of this Storage tree; therefore, the Storage field is also commonly referred to as the StorageRoot field.

[0068] For user accounts, the values ​​of the Code and Storage fields shown above are both empty.

[0069] Please refer to Figure 1 , Figure 1 This is a diagram illustrating the account structure of a user account.

[0070] like Figure 1 As shown, the account structure of the aforementioned user account may specifically include an Identity field and a Balance field. The Identity field is used to maintain the account identifier for the user account.

[0071] It should be noted that the Code and Storage fields in a user account are usually empty. Figure 1 The Code and Storage fields are omitted from the user account structure.

[0072] Please refer to Figure 2 , Figure 2 This is a schematic diagram of the account structure of a contract account.

[0073] like Figure 2 As shown, the account structure of the aforementioned contract account may specifically include the Identity field, Balance field, Code field, and Storage field. The Identity field is used to maintain the account identifier of the contract account.

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

[0075] In programmable blockchains, the functionality of smart contracts can be provided to users, allowing them to create and invoke complex logic within the blockchain network. A smart contract is a program on the blockchain that can be triggered and executed by transactions.

[0076] In a programmable blockchain, each blockchain node can host a Turing-complete virtual machine as the execution environment for smart contracts, enabling the implementation of various complex logics. Users publish and invoke smart contracts on the blockchain, which then run on this virtual machine.

[0077] In reality, the virtual machine directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"), so smart contracts deployed on the blockchain can be bytecode. Bytecode consists of a series of bytes, each byte representing an operation. For reasons of development efficiency and readability, developers can choose not to write bytecode directly, but instead choose a high-level language to write smart contract code. For example, high-level languages ​​could include Solidity, Serpent, or LLL. Smart contract code written in a high-level language can then be compiled by a compiler to generate bytecode that can be deployed to the blockchain.

[0078] After a user sends a smart contract creation transaction containing contract code to the blockchain network, each blockchain node can execute the transaction in its virtual machine.

[0079] Once the blockchain nodes reach an agreement through the consensus mechanism, the smart contract is successfully created, and users can subsequently call this smart contract.

[0080] After a smart contract is created, a contract account corresponding to that smart contract appears on the blockchain, with a specific address; the contract code and account storage are stored in the contract account's account storage. The behavior of the smart contract is controlled by the contract code, while the smart contract's account storage preserves the contract's state.

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

[0082] After a smart contract is invoked, the account state of the contract account may change. Subsequently, a client can view the account state of the contract account through the connected blockchain node.

[0083] Smart contracts can be executed independently on each node of the blockchain network in a prescribed manner. All execution records and data are stored on the blockchain. Therefore, once such a transaction is completed, the blockchain stores an immutable and unlost transaction certificate.

[0084] This specification aims to propose a technical solution for authorizing access to data accounts. On the one hand, by further expanding the account types supported by the blockchain, a data account is created to maintain the business data for contract calculations of smart contracts deployed on the blockchain, thereby separating the contract code of the smart contract from the business data required for contract calculations. On the other hand, by maintaining the corresponding access authorization information in the data account, access control is exercised over the contract account corresponding to the smart contract deployed on the blockchain to the data account.

[0085] In the above technical solution, the blockchain node in the blockchain can respond to the received data account authorization transaction for the data account. When it is determined that the administrator who initiated the data account authorization transaction has the management authority corresponding to the data account, the correspondence between the account identifier of the contract account corresponding to the smart contract deployed on the blockchain in the data account authorization transaction and the access permission information of the contract account for the data account is used as the access authorization information corresponding to the data account and filled into the authorization field of the data account.

[0086] In practical implementation, for any data account created on the blockchain, the administrator corresponding to that data account can initiate a data account authorization transaction for that data account. In this case, the blockchain nodes can receive the data account authorization transaction.

[0087] The aforementioned data account authorization transaction may include the account identifier of the contract account corresponding to the smart contract deployed on the blockchain, as well as the access permission information for the data account authorized to the contract account.

[0088] Upon receiving the aforementioned data account authorization transaction, the aforementioned blockchain node can respond to the data account authorization transaction and determine whether the aforementioned management party that initiated the data account authorization transaction has the management authority corresponding to the aforementioned data account.

[0089] If the aforementioned management entity has the management authority corresponding to the aforementioned data account, then the correspondence between the account identifier of the aforementioned contract account and the aforementioned access permission information can be used as the access authorization information corresponding to the data account and filled into the authorization field of the data account.

[0090] By adopting the above method, the contract code of a smart contract can be separated from the business data required for contract computation, thereby achieving the following objectives: First, the contract account corresponding to the smart contract only needs to maintain the contract code of the smart contract. Therefore, smart contracts with complex business logic can be broken down into multiple simpler sub-contracts, reducing the costs of smart contract development, testing, and upgrades. Second, user accounts registered in the blockchain, as well as contract accounts corresponding to smart contracts deployed on the blockchain, can directly access the business data maintained in the data account created on the blockchain. That is, data sharing between user accounts and contract accounts can be achieved through the data account, saving the execution overhead of smart contracts, enabling parallel access to business data, and improving the transaction throughput of the blockchain. Third, centralized maintenance of business data by the data account can realize the assetization of business data and facilitate the acquisition of large amounts of business data for data analysis, AI training, and other processing.

[0091] In addition, access control can be implemented for the data account by the contract account corresponding to the smart contract deployed on the blockchain, allowing only the contract account indicated by the access authorization information corresponding to the data account maintained in the data account to access the data account.

[0092] Please refer to Figure 3 , Figure 3 This is a flowchart illustrating an exemplary embodiment of a data account creation method in this specification.

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

[0094] The aforementioned data account can maintain the business data required for smart contracts deployed on the blockchain to perform contract calculations. This allows for the separation of the smart contract's code from the business data needed for contract calculations.

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

[0096] Step 302: Receive a data account creation transaction for creating the data account; wherein the data account creation transaction includes business data required for contract calculation by the smart contract deployed on the blockchain.

[0097] Step 304: In response to the creation of a transaction for the data account, create a data account on the blockchain.

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

[0099] For the smart contracts deployed on the aforementioned blockchain, a data account creation transaction can be initiated by the administrator corresponding to the data account to be created. For example, the administrator can initiate the data account creation transaction through its corresponding client. Upon detecting this operation, the client can construct the data account creation transaction according to the standard transaction format supported by the blockchain and publish it to the blockchain. In this case, the blockchain nodes can receive the data account creation transaction.

[0100] In practical applications, the aforementioned manager can be the owner of the smart contract (for example, if the smart contract can implement the business logic of a certain enterprise, then the manager can be that enterprise), or the owner of the data account to be created (for example, if the data account can be used to maintain the business data of a certain enterprise, then the manager can be that enterprise).

[0101] It should be noted that other users may also initiate the aforementioned data account creation transaction, or the aforementioned blockchain nodes may construct the aforementioned data account creation transaction themselves when certain conditions are met. This specification does not impose any restrictions on this.

[0102] Specifically, the aforementioned data account creation transaction can be used to create a data account corresponding to the aforementioned smart contract. That is, the created data account can be used to maintain the business data required for the smart contract to perform contract calculations. Accordingly, the data account creation transaction can include the business data required for the smart contract to perform contract calculations.

[0103] Upon receiving a transaction to create a data account, the aforementioned blockchain node can respond to the transaction by creating a data account on the aforementioned blockchain.

[0104] For the data account created above, the blockchain node can add the business data from the transaction that created the data account to the data account for maintenance. In this way, a data account can be created to maintain the business data required for the smart contract to perform contract calculations.

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

[0106] 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 a Merkle tree and stored in a local database mounted on the blockchain node. Accordingly, the account structure of the data account may include a data storage field for maintaining the hash value of the root node of the Merkle tree, in which the business data required for contract computation by smart contracts deployed on the blockchain is written.

[0107] In the above-mentioned case, the aforementioned addition of business data from the data account creation transaction to the data account for maintenance may specifically include writing the business data from the data account creation transaction into the Merkle tree stored in the local database of the blockchain node to update the Merkle tree, and filling the data storage field of the data account with the hash value of the root node of the updated Merkle tree.

[0108] Please refer to Figure 4 , Figure 4 This is a schematic diagram illustrating the account structure of a data account according to an exemplary embodiment of this specification.

[0109] like Figure 4 As shown, the account structure of the aforementioned data account may specifically include a Storage field. The Storage field can be used to maintain the hash value of the root node of the Merkle tree, also known as the StorageRoot field. This Merkle tree contains the business data required for smart contracts to perform contract calculations.

[0110] In the above scenario, the contract account no longer needs to store the business data required for smart contract calculations. Instead, a separate data account maintains the business data required for smart contract calculations. This allows for the separation of the smart contract's code from the business data needed for its calculations.

[0111] In one embodiment shown, the business data required for the smart contract deployed on the blockchain to perform contract calculations may include business data content and data access codes corresponding to that business data content.

[0112] In the aforementioned scenario, the process of writing the business data from the data account creation transaction into the Merkle tree stored in the local database of the blockchain node to update the Merkle tree and filling the data storage field of the data account with the hash value of the root node of the updated Merkle tree, specifically includes writing the correspondence between the business data content and data access codes from the data account creation transaction into the Merkle tree to update it and filling the data storage field of the data account with the hash value of the root node of the updated Merkle tree. That is, 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 computation by the smart contract deployed on the blockchain, and the correspondence between the business data content and the corresponding data access codes.

[0113] Continue to refer to Figure 4 ,like Figure 4 The Storage field in the account structure of the data account shown can be used to maintain the hash value of the root node of the Merkle tree, also known as the StorageRoot field. This Merkle tree contains the business data content required by the smart contract for contract calculations, as well as the correspondence between the business data content and the corresponding data access code. In this case, the Storage field can be considered to include a Data field and its corresponding Data Access Code field.

[0114] The Data field can be viewed as the hash value of the root node of the Merkle tree that maintains the business data content written into the smart contract for contract computation, and the Data Access Code field can be viewed as the hash value of the root node of the Merkle tree that maintains the data access code written into the corresponding business data content.

[0115] In one embodiment shown, for the aforementioned business data content, the corresponding data access code may include interface code for reading / writing the business data content. That is, by calling the data access code, reading / writing the business data content can be achieved.

[0116] In one embodiment shown, the data account creation transaction may further include data description information corresponding to the business data required for contract computation by the smart contract. Accordingly, the data account structure may also include a data description field for maintaining the hash value of the data description information, which corresponds to the business data required for contract computation by the smart contract deployed on the blockchain.

[0117] In the above scenario, for the data account created, the blockchain node can also 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 of the data account.

[0118] Continue to refer to Figure 4 ,like Figure 4 The data account structure shown can specifically include a SchemaHash field and a Storage field. The Storage field can be used to maintain the hash value of the root node of the Merkle tree, also known as the StorageRoot field. This Merkle tree contains the business data required for smart contracts to perform contract calculations. In this case, the SchemaHash field can be used to maintain the hash value of the data description information corresponding to this business data.

[0119] In one embodiment shown, the account structure of the data account may further include any or more of the following fields: an account identifier field for maintaining the account identifier of the data account; a balance field for maintaining the balance of assets held by the data account; and a management field for maintaining the public key of the manager of the data account.

[0120] Continue to refer to Figure 4 ,like Figure 4 The data account structure shown may specifically include the Identity field, Balance field, AuthMap field, SchemaHash field, and Storage field. The Identity field is used to maintain the account identifier of the data account. The Balance field is used to maintain the balance of assets held by the data account. The AuthMap field is used to maintain the public key of the data account administrator.

[0121] It should be noted that the aforementioned management fields can specifically be used to maintain the public key of at least one administrator of a data account, and the corresponding relationship of the weights assigned to the public keys of these at least one administrator.

[0122] In practical applications, for data accounts created on the blockchain, both user accounts and contract accounts can access the data account to obtain the business data maintained within it, and thus perform certain processing based on that business data. To prevent any user account or contract account from arbitrarily accessing the data account created on the blockchain and to improve the security of the business data maintained within the data account, access control can be implemented for user accounts and contract accounts specifically for that data account.

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

[0124] In such Figure 3 Based on the data account creation method shown, please refer to... Figure 5 , Figure 5 This is a flowchart illustrating an exemplary embodiment of a data account access authorization method.

[0125] The method for authorizing access to the aforementioned data account may include the following steps:

[0126] Step 502: Receive a data account authorization transaction initiated by the administrator corresponding to the data account for the data account; wherein the data account authorization transaction includes the account identifier of the target account and the access permission information for the data account authorized to the target account.

[0127] Step 504: In response to the data account authorization transaction, determine whether the administrator has the management authority corresponding to the data account.

[0128] Step 506: If the administrator has management permissions corresponding to the data account, then the correspondence between the account identifier of the target account and the access permission information is used as the access authorization information corresponding to the data account and filled into the authorization field of the data account.

[0129] For any data account created on the blockchain, the administrator corresponding to that data account can initiate a data account authorization transaction for that data account. In this case, the blockchain nodes can receive the data account authorization transaction.

[0130] The aforementioned data account authorization transaction may include the account identifier of the target account that can be authorized to access the aforementioned data account, and the access permission information for the data account authorized to the target account.

[0131] Upon receiving the aforementioned data account authorization transaction, the aforementioned blockchain node can respond to the data account authorization transaction and determine whether the aforementioned management party that initiated the data account authorization transaction has the management authority corresponding to the aforementioned data account.

[0132] If the aforementioned management entity has the management authority corresponding to the aforementioned data account, then the correspondence between the account identifier of the aforementioned target account and the aforementioned access permission information can be used as the access authorization information corresponding to the data account and filled into the authorization field of the data account.

[0133] In one embodiment shown, the access authorization information corresponding to the data account may include an access authorization list (also known as an access control list, ACL) consisting of the correspondence between the account identifiers of at least one target account and the access permission information authorized to these at least one target account for the data account. It should be noted that the account identifiers of these at least one target account and the access permission information authorized to these at least one target account for the data account are in a one-to-one correspondence.

[0134] In one embodiment shown, for any target account, the correspondence between the target account's account identifier and the access permission information granted to that target account for a certain data account can be represented in the form of key-value pairs. The key in each key-value pair can be the target account's account identifier, and the value can be the access permission information granted to that target account for the data account. Correspondingly, the aforementioned access authorization list can be a Map list composed of key-value pairs corresponding to the at least one target account. In this Map list, the key in each key-value pair is the account identifier of the at least one target account, and the value is the access permission information granted to the at least one target account for the data account.

[0135] In practical applications, the aforementioned access permission information may specifically be an Access Certificate (AC). To ensure the data security of access permission information, improve its usability, and save storage space, the access authorization list may specifically store the account identifier of at least one target account, and the corresponding hash values ​​of the access permission information granted to that target account for that data account.

[0136] Continue to refer to Figure 4 ,like Figure 4 The data account structure shown may specifically include the Identity field, Balance field, AuthMap field, ACL field, SchemaHash field, and Storage field. The ACL field can be used to maintain access authorization information (e.g., an access authorization list) corresponding to the data account.

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

[0138] The following sections provide detailed explanations of the process for user accounts and contract accounts to access data accounts.

[0139] (1) User account access to data account

[0140] Combination such as Figure 5 For the data account access authorization method shown, please refer to [link / reference]. Figure 6 , Figure 6 This is a flowchart illustrating an exemplary embodiment of this specification, showing another method for authorizing access to a data account.

[0141] The method for authorizing access to the aforementioned data account may include the following steps:

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

[0143] Step 604: In response to the data account authorization transaction, determine whether the administrator has the management authority corresponding to the data account.

[0144] Step 606: If the administrator has management permissions corresponding to the data account, then the correspondence between the user account's account identifier and the access permission information is used as the access authorization information corresponding to the data account and filled into the authorization field of the data account.

[0145] The specific implementation of steps 602 to 606 can be found in steps 502 to 506, and will not be repeated here.

[0146] Please refer to Figure 7 , Figure 7 This is a flowchart illustrating an exemplary embodiment of this specification, showing another method for authorizing access to a data account.

[0147] The method for authorizing access to the aforementioned data account may include the following steps:

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

[0149] Step 704: In response to the data account authorization transaction, determine whether the administrator has the management authority corresponding to the data account.

[0150] Step 706: If the administrator has management permissions corresponding to the data account, an approval event corresponding to the access permissions granted to the user account for the data account is generated, so that when the administrator corresponding to the data account receives the approval event, the administrator approves the access permissions granted to the user account for the data account and returns the approval result.

[0151] Step 708: In response to the received approval result, when the approval result indicates that the approval is passed, the correspondence between the user account's account identifier and the access permission information is used as the access authorization information corresponding to the data account and filled into the authorization field of the data account.

[0152] For any data account created on the blockchain, the administrator corresponding to any user account registered by the user in the blockchain can also initiate a data account authorization transaction for that data account. In this case, the blockchain nodes in the blockchain can receive the data account authorization transaction.

[0153] The aforementioned data account authorization transaction may include the account identifier of the aforementioned user account, as well as the access permission information for the aforementioned data account authorized to the user account.

[0154] Upon receiving the aforementioned data account authorization transaction, the aforementioned blockchain node can respond to the data account authorization transaction and determine whether the aforementioned management party that initiated the data account authorization transaction has the management authority corresponding to the aforementioned user account.

[0155] If the aforementioned administrator has the management permissions corresponding to the aforementioned user account, it can generate an approval event corresponding to the access permissions granted to the user account for the aforementioned data account, and publish the approval event to the aforementioned blockchain. This allows the administrator corresponding to the data account to obtain the approval event from the blockchain, approve the access permissions granted to the user account for the data account accordingly, and return the approval result.

[0156] Upon receiving the aforementioned approval result, the aforementioned blockchain node can respond to the approval result by filling the authorization field of the data account with the correspondence between the account identifier of the aforementioned user account and the aforementioned access permission information as the access authorization information corresponding to the aforementioned data account when the approval result indicates that the approval is approved.

[0157] It's important to note that after a user account is registered on the blockchain, a corresponding public-private key pair can be assigned to that account. That is, the administrator associated with the user account can hold this public-private key pair. The private key can be used to sign transactions initiated by the administrator, and the public key can be used to verify the signature. The public key can be broadcast within the blockchain.

[0158] In one embodiment shown, if the account structure of the data account further includes a management field for maintaining the public key of the data account's administrator, when determining whether the administrator initiating the data account authorization transaction has the management authority corresponding to the data account, it can specifically be determined whether the administrator's public key matches the public key of the data account's administrator maintained in the management field. If so, it can be determined that the administrator has the management authority corresponding to the data account.

[0159] In one embodiment shown, the aforementioned management field can specifically be used to maintain the public key of at least one administrator of a data account, and the correspondence between the weights assigned to the public keys of these at least one administrator. In this case, when determining whether the public key of the administrator initiating the data account authorization transaction matches the public key of the data account administrator maintained in the management field, it can be specifically determined whether the weight corresponding to the public key of the administrator reaches a preset threshold based on the correspondence maintained in the management field. If so, it can be determined that the public key of the administrator matches the public key of the data account administrator.

[0160] In practical applications, the data account authorization transaction can be signed using the private key of the administrator who initiated it. Correspondingly, before responding to the data account authorization transaction, the administrator's public key can be determined, and the signature can be verified based on that public key. Only if the verification passes can the response be initiated.

[0161] Similarly, the account structure of the aforementioned user account may also include a management field for maintaining the public key of the administrator of the user account. In this case, when determining whether the administrator initiating the aforementioned data account authorization transaction has the management authority corresponding to the user account, it can also be determined whether the administrator's public key matches the public key of the administrator of the user account maintained in the management field. If they match, it can be determined that the administrator has the management authority corresponding to the user account.

[0162] It should be noted that, as well as, can also be used. Figure 6In a manner similar to the access authorization method for the data account shown in Figure 7, all or part of the access authorization information corresponding to the data account maintained in the authorization field of the aforementioned data account is updated; or, all or part of the access authorization is revoked (e.g., deleted or marked as revoked) of the access authorization information corresponding to the data account maintained in the authorization field of the aforementioned data account.

[0163] In such Figure 6 Based on the data account access authorization method shown in Figure 7, please refer to... Figure 8 , Figure 8 This is a flowchart illustrating an exemplary embodiment of a data account access method in this specification.

[0164] The above-mentioned data account access methods may include the following steps:

[0165] Step 802: Receive the data account access transaction of the user account for the data account; wherein the data account access transaction includes the data identifier of the target data to be accessed, and the access permission information authorized to the user account for the data account.

[0166] 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 of the data account.

[0167] Step 806: If the access permission information matches the access authorization information corresponding to the data account, then it is determined that the user account has the access permission of the data account, and the target data corresponding to the data identifier is searched in the business data maintained in the data account.

[0168] For any data account created on the blockchain, the blockchain nodes in the aforementioned blockchain can receive data account access transactions from any user account for that data account.

[0169] The aforementioned data account access transaction may include the data identifier of the data to be accessed (which may be referred to as the target data), as well as the access permission information granted to the aforementioned user account for that data account.

[0170] Upon receiving the aforementioned data account access transaction, the blockchain node can respond to the data account access transaction by determining 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 of the data account.

[0171] If the two match, it can be determined that the user account has access to the data account, and thus the target data corresponding to the data identifier in the data account access transaction can be found in the business data maintained in the data account.

[0172] Since the access authorization information corresponding to the data account may include an access authorization list consisting of the account identifier of at least one target account and the corresponding relationship between the access permissions granted to the at least one target account for the data account, in one embodiment shown, the data account access transaction may also include the account identifier of the user account.

[0173] In the above situation, when determining whether the access permission information in the above data account access transaction matches the access authorization information corresponding to the data account maintained in the authorization field of the above data account, specifically, we can first look up the access permission information corresponding to the account identifier of the user account based on the access authorization list maintained in the authorization field of the data account, and then determine whether the access permission information in the data account access transaction matches the found access permission information. If so, it can be determined that the access permission information matches the access authorization information corresponding to the data account.

[0174] Since the business data maintained in the data account can be organized into a Merkle tree and stored in the local database mounted on the blockchain node, and the Merkle tree stores key-value pairs, in one embodiment shown, the data identifier of the target data may include the key of the target data.

[0175] In the above situation, when searching for the target data corresponding to the data identifier in the data account access transaction in the business data maintained in the above data account, specifically, the value corresponding to the key of the target data can be found in the Merkle tree stored in the local database of the above blockchain node, and the found value is determined as the target data.

[0176] In one embodiment shown, the access permission information may further include an expiration period and a set of data identifiers for the data that grants access permissions to the user account.

[0177] In the above situation, when it is determined that the access permission information matches the access authorization information corresponding to the data account, it can also be determined whether the access permission information is valid based on the validity period in the access permission information. If so, it can be further determined whether the data identifier set in the access permission information includes the data identifier of the target data. If so, it can be determined that the user account has the access permission of the data account.

[0178] (2) Contract account access to data account

[0179] Combination such as Figure 5 For the data account access authorization method shown, please refer to [link / reference]. Figure 9 , Figure 9 This is a flowchart illustrating an exemplary embodiment of this specification, showing another method for authorizing access to a data account.

[0180] The method for authorizing access to the aforementioned data account may include the following steps:

[0181] Step 902: Receive a data account authorization transaction initiated by the administrator corresponding to the data account for the data account; wherein, the data account authorization transaction includes the account identifier of the contract account corresponding to the smart contract deployed on the blockchain, and the access permission information for the data account authorized to the contract account.

[0182] Step 904: In response to the data account authorization transaction, determine whether the administrator has the management authority corresponding to the data account.

[0183] Step 906: If the administrator has management permissions corresponding to the data account, then the correspondence between the account identifier of the contract account and the access permission information is used as the access authorization information corresponding to the data account and filled into the authorization field of the data account.

[0184] The specific implementation of steps 902 to 906 can be found in steps 502 to 506, and will not be repeated here.

[0185] Please refer to Figure 10 , Figure 10 This is a flowchart illustrating an exemplary embodiment of this specification, showing another method for authorizing access to a data account.

[0186] The method for authorizing access to the aforementioned data account may include the following steps:

[0187] Step 1002: Receive a data account authorization transaction for the data account initiated by the administrator corresponding to the contract account of the smart contract deployed on the blockchain; wherein the data account authorization transaction includes the account identifier of the contract account and the access permission information for the data account authorized to the contract account.

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

[0189] Step 1006: If the manager has management permissions corresponding to the contract account, an approval event is generated corresponding to the access permissions granted to the contract account for the data account, so that when the manager corresponding to the data account receives the approval event, the manager approves the access permissions granted to the contract account for the data account and returns the approval result.

[0190] Step 1008: In response to the received approval result, when the approval result indicates that the approval is passed, the correspondence between the account identifier of the contract account and the access permission information is used as the access authorization information corresponding to the data account and filled into the authorization field of the data account.

[0191] For any data account created on the blockchain, the administrator corresponding to any contract account associated with a smart contract deployed on the blockchain can also initiate a data account authorization transaction for that data account. In this case, the blockchain nodes in the blockchain can receive the data account authorization transaction.

[0192] The aforementioned data account authorization transaction may include the account identifier of the aforementioned contract account, as well as the access permission information for the aforementioned data account authorized to the contract account.

[0193] Upon receiving the aforementioned data account authorization transaction, the aforementioned blockchain node can respond to the data account authorization transaction and determine whether the aforementioned management party that initiated the data account authorization transaction has the management authority corresponding to the aforementioned contract account.

[0194] If the aforementioned manager has management authority corresponding to the aforementioned contract account, it can generate an approval event corresponding to the access rights granted to the contract account for the aforementioned data account, and publish the approval event to the aforementioned blockchain. This allows the manager corresponding to the data account to obtain the approval event from the blockchain, approve the access rights granted to the contract account for the data account accordingly, and return the approval result.

[0195] Upon receiving the aforementioned approval result, the aforementioned blockchain node can respond to the approval result by filling the authorization field of the data account with the correspondence between the account identifier of the aforementioned contract account and the aforementioned access permission information, as the access authorization information corresponding to the aforementioned data account, when the approval result indicates that the approval is approved.

[0196] It's important to note that after deploying a smart contract on the blockchain, a public-private key pair can be assigned to the contract account associated with that smart contract. That is, the administrator of the contract account can hold this public-private key pair; the private key can be used to sign transactions initiated by the administrator, and the public key can be used to verify the signature. The public key can be broadcast within the blockchain.

[0197] In one embodiment shown, if the account structure of the data account further includes a management field for maintaining the public key of the data account's administrator, when determining whether the administrator initiating the data account authorization transaction has the management authority corresponding to the data account, it can specifically be determined whether the administrator's public key matches the public key of the data account's administrator maintained in the management field. If so, it can be determined that the administrator has the management authority corresponding to the data account.

[0198] In one embodiment shown, the aforementioned management field can specifically be used to maintain the public key of at least one administrator of a data account, and the correspondence between the weights assigned to the public keys of these at least one administrator. In this case, when determining whether the public key of the administrator initiating the data account authorization transaction matches the public key of the data account administrator maintained in the management field, it can be specifically determined whether the weight corresponding to the public key of the administrator reaches a preset threshold based on the correspondence maintained in the management field. If so, it can be determined that the public key of the administrator matches the public key of the data account administrator.

[0199] In practical applications, the data account authorization transaction can be signed using the private key of the administrator who initiated it. Correspondingly, before responding to the data account authorization transaction, the administrator's public key can be determined, and the signature can be verified based on that public key. Only if the verification passes can the response be initiated.

[0200] Similarly, the account structure of the aforementioned contract account may also include a management field for maintaining the public key of the manager of the contract account. In this case, when determining whether the manager initiating the aforementioned data account authorization transaction has the management authority corresponding to the contract account, it can also be determined whether the manager's public key matches the public key of the contract account's manager maintained in the management field. If they match, it can be determined that the manager has the management authority corresponding to the contract account.

[0201] It should be noted that, as well as, can also be used. Figure 6In a manner similar to the access authorization method for the data account shown in Figure 7, all or part of the access authorization information corresponding to the data account maintained in the authorization field of the aforementioned data account is updated; or, all or part of the access authorization is revoked (e.g., deleted or marked as revoked) of the access authorization information corresponding to the data account maintained in the authorization field of the aforementioned data account.

[0202] In such Figure 9 Based on the data account access authorization method shown in Figure 10, please refer to... Figure 11 , Figure 11 This is a flowchart illustrating an exemplary embodiment of a data account access method in this specification.

[0203] The above-mentioned data account access methods may include the following steps:

[0204] Step 1102: Receive the data account access transaction of the contract account for the data account; wherein the data account access transaction includes the data identifier of the target data to be accessed, and the access permission information authorized to the contract account for the data account.

[0205] 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 of the data account.

[0206] Step 1106: If the access permission information matches the access authorization information corresponding to the data account, then it is determined that the contract account has the access permission of the data account, and the target data corresponding to the data identifier is searched in the business data maintained in the data account.

[0207] For any data account created on the blockchain, a blockchain node in the aforementioned blockchain can receive data account access transactions for that data account from any contract account.

[0208] The aforementioned data account access transaction may include the data identifier of the data to be accessed (which may be referred to as the target data), as well as the access permission information for the data account authorized to the aforementioned contract account.

[0209] Upon receiving the aforementioned data account access transaction, the blockchain node can respond to the data account access transaction by determining 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 of the data account.

[0210] If the two match, it can be determined that the aforementioned contract account has access to the aforementioned data account, and thus the target data corresponding to the data identifier in the access transaction of the aforementioned data account can be found in the business data maintained in the data account.

[0211] Since the access authorization information corresponding to the data account may include an access authorization list consisting of the account identifier of at least one target account and the corresponding relationship between the access permissions granted to the at least one target account for the data account, in one embodiment shown, the data account access transaction may also include the account identifier of the contract account.

[0212] In the above situation, when determining 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 of the data account, specifically, one can first look up the access permission information corresponding to the account identifier of the contract account based on the access authorization list maintained in the authorization field of the data account, and then determine whether the access permission information in the data account access transaction matches the found access permission information. If so, it can be determined that the access permission information matches the access authorization information corresponding to the data account.

[0213] Since the business data maintained in the data account can be organized into a Merkle tree and stored in the local database mounted on the blockchain node, and the Merkle tree stores key-value pairs, in one embodiment shown, the data identifier of the target data may include the key of the target data.

[0214] In the above situation, when searching for the target data corresponding to the data identifier in the data account access transaction in the business data maintained in the above data account, specifically, the value corresponding to the key of the target data can be found in the Merkle tree stored in the local database of the above blockchain node, and the found value is determined as the target data.

[0215] In one embodiment shown, the access permission information may further include an expiration date and a set of data identifiers for the data that grants access permissions to the contract account.

[0216] In the above circumstances, when it is determined that the access permission information matches the access authorization information corresponding to the data account, it can also be determined whether the access permission information is valid based on the validity period in the access permission information. If so, it can be further determined whether the data identifier set in the access permission information includes the data identifier of the target data. If so, it can be determined that the contract account has the access permission of the data account.

[0217] In practical applications, the business data required for smart contracts deployed on the blockchain to perform contract calculations typically changes according to actual circumstances. To ensure the accuracy of the business data maintained in the data accounts created on the blockchain and to prevent errors when smart contracts perform contract calculations based on this business data, it is necessary to update the business data maintained in the data accounts created on the blockchain.

[0218] In one embodiment shown, as Figure 3 Based on the data account creation method shown, please refer to... Figure 12 , Figure 12 This is a flowchart illustrating an exemplary embodiment of a data account update method in this specification.

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

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

[0221] Step 1204: In response to the data account update transaction, determine whether the administrator has the management authority corresponding to the data account.

[0222] Step 1206: If the administrator has the management authority corresponding to the data account, the updated business data is written into the Merkle tree stored in the local database to update the business data already written in the Merkle tree, and the hash value of the root node of the updated Merkle tree is filled into the data storage field in the data account.

[0223] For any data account created on the blockchain, the administrator corresponding to that data account can initiate a data account update transaction for that data account. In this case, the blockchain nodes can receive the data account update transaction.

[0224] Since the aforementioned data account can be used to maintain the business data required for smart contracts deployed on the aforementioned blockchain to perform contract calculations, in this case, the data account update transaction can include the updated business data.

[0225] Upon receiving the aforementioned data account update transaction, the aforementioned blockchain node can respond to the data account update transaction and determine whether the aforementioned management party that initiated the data account update transaction has the management authority corresponding to the aforementioned data account.

[0226] If the aforementioned management entity has the management permissions corresponding to the aforementioned data account, it can update the aforementioned business data maintained in the data account based on the updated aforementioned business data.

[0227] Since the business data maintained in the aforementioned data account can be organized into a Merkle tree and stored in the local database mounted on the aforementioned blockchain node, the updated business data can be written to this Merkle tree to update the business data already written to the Merkle tree. The hash value of the root node of the updated Merkle tree is then filled into the data storage field of the data account. Therefore, the data maintained in the data storage field of the data account is updated from the hash value of the root node of the Merkle tree containing the original business data to the hash value of the root node of the Merkle tree containing the updated business data.

[0228] It should be noted that the aforementioned data account update transaction may also include data description information corresponding to the updated business data. In this case, while updating the business data maintained in the aforementioned data account, the data maintained in the data description field of the data account may also be updated from the hash value of the data description information corresponding to the original business data to the hash value of the data description information corresponding to the updated business data.

[0229] In practical applications, the native transaction types supported by the blockchain can be extended to create native transactions with new functionalities within the blockchain. It should be noted that these extended native transactions with new functionalities can be independent of transfer transactions or smart contract call transactions.

[0230] In one embodiment shown, the native transaction types supported by the blockchain can be extended to create a native transaction for creating a data account, which may be referred to as a data account creation transaction.

[0231] For example, for a blockchain using the UTXO model, a data account creation transaction can be added to the existing transaction support for data transfers; while for a blockchain using the account model, a data account creation transaction can be added to the existing transaction support for data transfers, smart contract creation transactions, and smart contract invocation transactions.

[0232] Similarly, the native transaction types supported by the blockchain can be extended to create a native transaction for updating business data maintained in the data account, which can be called a data account update transaction.

[0233] The native transaction types supported by the blockchain can be extended to create a native transaction for authorizing access to the data account, which can be called a data account authorization transaction.

[0234] The native transaction types supported by the blockchain can be extended to create a native transaction for accessing the data account, which can be called a data account access transaction.

[0235] The transaction formats for the aforementioned data account creation transactions, data account update transactions, data account authorization transactions, and data account access transactions are not specifically limited in this specification; in practical applications, existing blockchain-compatible transaction formats can be adopted, or new transaction formats can be defined.

[0236] Please refer to Figure 13 , Figure 13 This is a schematic diagram of the hardware structure of a device shown in an exemplary embodiment of this specification.

[0237] like Figure 13 As shown, at the hardware level, the aforementioned devices include a processor 1302, an internal bus 1304, a network interface 1306, memory 1308, and non-volatile memory 1310, and may also include other hardware required for business operations. One or more embodiments of this specification can be implemented in software, for example, the processor 1302 reads the corresponding computer program from the non-volatile memory 1310 into memory 1308 and then runs it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic module, but can also be hardware or logic devices.

[0238] Please refer to Figure 14 , Figure 14 This is a block diagram illustrating an exemplary embodiment of a data account access authorization device.

[0239] The aforementioned data account access authorization device can be applied to, for example... Figure 13 The device shown is used to implement the technical solution of this specification. This device can act as a blockchain node in a blockchain; the account types supported by the blockchain include data accounts; the data accounts are used to maintain the business data required for contract calculations by smart contracts deployed on the blockchain; the account structure of the data account includes an authorization field for maintaining access authorization information corresponding to the data account; the access authorization device for the data account may include:

[0240] The receiving module 1402 receives a data account authorization transaction initiated by the administrator corresponding to the data account for the data account; wherein, the data account authorization transaction includes the account identifier of the contract account corresponding to the smart contract deployed on the blockchain, and the access permission information for the data account authorized to the contract account;

[0241] The determination module 1404, in response to the data account authorization transaction, determines whether the administrator has the management authority corresponding to the data account;

[0242] The authorization module 1406, if the manager has management permissions corresponding to the data account, then uses the correspondence between the account identifier of the contract account and the access permission information as access authorization information corresponding to the data account and fills it into the authorization field of the data account.

[0243] Optionally, the account structure of the data account may further include a management field for maintaining the public key of the data account's administrator;

[0244] The determining module 1404:

[0245] Determine whether the public key of the administrator matches the public key of the administrator of the data account maintained in the management field;

[0246] If the public key of the administrator matches the public key of the administrator of the data account, then it is determined that the administrator has the management authority corresponding to the data account.

[0247] Optionally, the management field maintains the public key of at least one manager of the data account, and the correspondence between the weights assigned to the public keys of the at least one manager;

[0248] The determining module 1404:

[0249] Based on the correspondence maintained in the management field, determine whether the weight corresponding to the public key of the management party reaches a preset threshold;

[0250] If the weight corresponding to the public key of the administrator reaches the threshold, then it is determined that the public key of the administrator matches the public key of the administrator of the data account.

[0251] Optionally, the device further includes:

[0252] The second receiving module receives a data account access transaction from the contract account for the data account; wherein the data account access transaction includes a data identifier of the target data to be accessed, and access permission information for the data account authorized to the contract account.

[0253] The second determining module, in response to the data account access transaction, determines 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 of the data account.

[0254] The search module determines that the contract account has the access rights of the data account if the access permission information matches the access authorization information corresponding to the data account, and searches for the target data corresponding to the data identifier in the business data maintained in the data account.

[0255] Optionally, the access authorization information corresponding to the data account includes an access authorization list consisting of an account identifier of at least one target account and a correspondence between the at least one target account and the access permissions granted to the data account.

[0256] Optionally, the correspondence is a key-value pair; the access authorization list is a Map list consisting of key-value pairs corresponding to the at least one target account; wherein, 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.

[0257] 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.

[0258] Optionally, the data account access transaction may also include the account identifier of the contract account;

[0259] The second determining module:

[0260] Based on the access authorization list maintained in the authorization field of the data account, search for the access permission information corresponding to the account identifier of the contract account;

[0261] Determine whether the access permission information in the data account access transaction matches the found access permission information;

[0262] If the access permission information in the data account access transaction matches the found access permission information, then the access permission information is determined to match the access authorization information corresponding to the data account.

[0263] Optionally, the business data maintained in the data account is organized into a Merkle tree and stored in a local database mounted on the blockchain node; the data identifier of the target data includes the key of the target data;

[0264] The search module:

[0265] In the Merkle tree stored in the local database mounted on the blockchain node, the value corresponding to the key of the target data is searched, and the found value is determined as the target data.

[0266] Optionally, the access permission information includes the validity period and a set of data identifiers for the data to which the contract account is authorized access.

[0267] The search module:

[0268] Based on the validity period in the access permission information, determine whether the access permission information is valid;

[0269] If the access permission information is determined to be valid, it is further determined whether the data identifier set in the access permission information includes the data identifier of the target data;

[0270] If the set of data identifiers includes the data identifier of the target data, it is determined that the contract account has access to the data account.

[0271] Optionally, the data account authorization transaction is a native transaction supported by the blockchain for authorizing access to the data account; the data account access transaction is a native transaction supported by the blockchain for accessing the data account.

[0272] Please refer to Figure 15 , Figure 15 This is a block diagram illustrating an alternative data account access authorization device according to an exemplary embodiment of this specification.

[0273] The aforementioned data account access authorization device can be applied to, for example... Figure 13 The device shown is used to implement the technical solution of this specification. This device can act as a blockchain node in a blockchain; the account types supported by the blockchain include data accounts; the data accounts are used to maintain the business data required for contract calculations by smart contracts deployed on the blockchain; the account structure of the data account includes an authorization field for maintaining access authorization information corresponding to the data account; the access authorization device for the data account may include:

[0274] The receiving module 1502 receives a data account authorization transaction initiated by the administrator of the contract account corresponding to the smart contract deployed on the blockchain for the data account; wherein, the data account authorization transaction includes the account identifier of the contract account and the access permission information authorized to the contract account for the data account;

[0275] The determination module 1504, in response to the data account authorization transaction, determines whether the administrator has the management authority corresponding to the contract account;

[0276] Approval module 1506: If the manager has management permissions corresponding to the contract account, it generates an approval event corresponding to the access permissions granted to the contract account for the data account, so that when the manager corresponding to the data account receives the approval event, it approves the access permissions granted to the contract account for the data account and returns the approval result.

[0277] The authorization module 1508, in response to the received approval result, when the approval result indicates that the approval is passed, fills the authorization field in the data account with the correspondence between the account identifier of the contract account and the access permission information as the access authorization information corresponding to the data account.

[0278] The apparatus embodiments are basically the same as the method embodiments, so relevant details can be found in the description of the method embodiments.

[0279] The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the technical solution in this specification, depending on actual needs.

[0280] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

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

[0282] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0283] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0284] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0285] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0286] 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 scope of one or more embodiments of this specification. The singular forms “a,” “described,” and “the” used in one or more embodiments of this specification and in the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more associated listed items.

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

[0288] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the protection scope of one or more embodiments of this specification.

Claims

1. A method for authorizing access to a data account, applied to a blockchain node; wherein the blockchain supports account types including data accounts; the data account is a new account type independent of user accounts and contract accounts, further extending the account types supported by the blockchain; the data account is used to maintain business data required for contract computation by smart contracts deployed on the blockchain; the business data includes business data content and data access code corresponding to the business data content; the data access code includes interface code for reading and writing the business data content; The account structure of the data account includes an authorization field for maintaining access authorization information corresponding to the data account; the method includes: Receive a data account authorization transaction initiated by the administrator corresponding to the data account for the data account; wherein, the data account authorization transaction includes the account identifier of the contract account corresponding to the smart contract deployed on the blockchain, and the access permission information for the data account authorized to the contract account; In response to the data account authorization transaction, determine whether the administrator has the management authority corresponding to the data account; If the administrator has management permissions corresponding to the data account, the correspondence between the account identifier of the contract account and the access permission information is used as the access authorization information corresponding to the data account and filled into the authorization field of the data account.

2. The method according to claim 1, wherein the account structure of the data account further includes a management field for maintaining the public key of the administrator of the data account; Determining whether the administrator has the management permissions corresponding to the data account includes: Determine whether the public key of the administrator matches the public key of the administrator of the data account maintained in the management field; If the public key of the administrator matches the public key of the administrator of the data account, then it is determined that the administrator has the management authority corresponding to the data account.

3. The method according to claim 2, wherein the management field maintains the public key of at least one manager of the data account, and the correspondence between the weights assigned to the public keys of the at least one manager; The step of determining whether the public key of the administrator matches the public key of the administrator of the data account maintained in the management field includes: Based on the correspondence maintained in the management field, determine whether the weight corresponding to the public key of the management party reaches a preset threshold; If the weight corresponding to the public key of the administrator reaches the threshold, then it is determined that the public key of the administrator matches the public key of the administrator of the data account.

4. The method according to claim 1, further comprising: Receive the data account access transaction from the contract account for the data account; wherein the data account access transaction includes the data identifier of the target data to be accessed, and the access permission information authorized to the contract account for the data account; 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 of the data account. If the access permission information matches the access authorization information corresponding to the data account, it is determined that the contract account has the access permission of the data account, and the target data corresponding to the data identifier is searched in the business data maintained in the data account.

5. The method according to claim 4, wherein the access authorization information corresponding to the data account includes an access authorization list consisting of an account identifier of at least one target account and a correspondence between access permission information for the data account authorized to the at least one target account.

6. The method according to claim 5, wherein the correspondence is a key-value pair; the access authorization list is a Map list consisting of key-value pairs corresponding to the at least one target account; wherein, 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.

7. The method according to claim 5, wherein 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.

8. The method according to claim 5, wherein the data account access transaction further includes the account identifier of the contract account; The step of determining 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 of the data account includes: Based on the access authorization list maintained in the authorization field of the data account, search for the access permission information corresponding to the account identifier of the contract account; Determine whether the access permission information in the data account access transaction matches the found access permission information; If the access permission information in the data account access transaction matches the found access permission information, then the access permission information is determined to match the access authorization information corresponding to the data account.

9. The method according to claim 4, wherein the business data maintained in the data account is organized into a Merkle tree form and stored in a local database mounted on the blockchain node; the data identifier of the target data includes the key of the target data; The step of searching for the target data corresponding to the data identifier in the business data maintained in the data account includes: In the Merkle tree stored in the local database mounted on the blockchain node, the value corresponding to the key of the target data is searched, and the found value is determined as the target data.

10. The method according to claim 4, wherein the access permission information includes a validity period and a set of data identifiers for the data to which access permission is authorized to the contract account; The determination that the contract account has access to the data account includes: Based on the validity period in the access permission information, determine whether the access permission information is valid; If the access permission information is determined to be valid, it is further determined whether the data identifier set in the access permission information includes the data identifier of the target data; If the set of data identifiers includes the data identifier of the target data, it is determined that the contract account has access to the data account.

11. The method according to claim 4, wherein the data account authorization transaction is a native transaction supported by the blockchain for authorizing access to the data account; and the data account access transaction is a native transaction supported by the blockchain for accessing the data account.

12. A method for authorizing access to a data account, applied to a blockchain node; wherein the blockchain supports account types including data accounts; the data account is a new account type independent of user accounts and contract accounts, further extending the account types supported by the blockchain; the data account is used to maintain business data required for contract computation by smart contracts deployed on the blockchain; the business data includes business data content and data access code corresponding to the business data content; the data access code includes interface code for reading and writing the business data content; The account structure of the data account includes an authorization field for maintaining access authorization information corresponding to the data account; the method includes: The system receives a data account authorization transaction for the data account initiated by the administrator of the contract account corresponding to the smart contract deployed on the blockchain; wherein the data account authorization transaction includes the account identifier of the contract account and the access permission information for the data account authorized to the contract account; In response to the data account authorization transaction, determine whether the administrator has the management authority corresponding to the contract account; If the manager has management permissions corresponding to the contract account, an approval event is generated corresponding to the access permissions granted to the contract account for the data account, so that when the manager corresponding to the data account receives the approval event, the manager approves the access permissions granted to the contract account for the data account and returns the approval result. In response to the received approval result, when the approval result indicates that the approval is approved, the correspondence between the account identifier of the contract account and the access permission information is used as the access authorization information corresponding to the data account and filled into the authorization field of the data account.

13. A data account access authorization device, applied to a blockchain node; the blockchain supports account types including data accounts; the data account is a new account type independent of user accounts and contract accounts, further extending the account types supported by the blockchain; the data account is used to maintain business data required for contract computation by smart contracts deployed on the blockchain; the business data includes business data content and data access code corresponding to the business data content; the data access code includes interface code for reading and writing the business data content; The account structure of the data account includes an authorization field for maintaining access authorization information corresponding to the data account; the device includes: The receiving module receives a data account authorization transaction initiated by the administrator corresponding to the data account; wherein the data account authorization transaction includes the account identifier of the contract account corresponding to the smart contract deployed on the blockchain, and the access permission information for the data account authorized to the contract account; The determination module, in response to the data account authorization transaction, determines whether the administrator has the management authority corresponding to the data account; In the authorization module, if the administrator has management permissions corresponding to the data account, the correspondence between the account identifier of the contract account and the access permission information is used as the access authorization information corresponding to the data account and filled into the authorization field of the data account.

14. A data account access authorization device, applied to a blockchain node; the blockchain supports account types including data accounts; the data account is a new account type independent of user accounts and contract accounts, further extending the account types supported by the blockchain; the data account is used to maintain business data required for contract computation by smart contracts deployed on the blockchain; the business data includes business data content and data access code corresponding to the business data content; the data access code includes interface code for reading and writing the business data content; The account structure of the data account includes an authorization field for maintaining access authorization information corresponding to the data account; the device includes: The receiving module receives a data account authorization transaction initiated by the administrator of the contract account corresponding to the smart contract deployed on the blockchain, which is for the data account; wherein the data account authorization transaction includes the account identifier of the contract account and the access permission information for the data account authorized to the contract account; The determination module, in response to the data account authorization transaction, determines whether the administrator has the management authority corresponding to the contract account; The approval module, if the manager has management permissions corresponding to the contract account, generates an approval event corresponding to the access permissions granted to the contract account for the data account, so that when the manager corresponding to the data account receives the approval event, he / she approves the access permissions granted to the contract account for the data account and returns the approval result. The authorization module, in response to the received approval result, when the approval result indicates that the approval is passed, fills the authorization field in the data account with the correspondence between the account identifier of the contract account and the access permission information as the access authorization information corresponding to the data account.

15. An electronic device comprising: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 1-12 by executing the executable instructions.

16. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the method as described in any one of claims 1-12.

Images