Smart contract access authorization method and device

Abstract

This specification provides one or more embodiments of a method and apparatus for granting access to smart contracts, applied to a blockchain node; the blockchain node maintains access authorization information corresponding to smart contracts deployed on the blockchain; the method includes: receiving an access authorization transaction for a first smart contract deployed on the blockchain; wherein the access authorization transaction includes a contract identifier of a second smart contract deployed on the blockchain, and access permission information for the first smart contract authorized to the second smart contract; in response to the access authorization transaction, performing a legality verification on the access authorization transaction; if the legality verification of the access authorization transaction passes, adding the correspondence between the contract identifier of the second smart contract and the access permission information to the access authorization information.

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 granting access to smart contracts. 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 granting access to smart contracts, applied to blockchain nodes; the blockchain node maintains access authorization information corresponding to smart contracts deployed on the blockchain; the method includes:

[0006] Receive an access authorization transaction for a first smart contract deployed on the blockchain; wherein the access authorization transaction includes a contract identifier of a second smart contract deployed on the blockchain, and access permission information for the first smart contract authorized to the second smart contract;

[0007] In response to the access authorization transaction, the access authorization transaction is validated for legality.

[0008] If the access authorization transaction passes the legality verification, the correspondence between the contract identifier of the second smart contract and the access permission information is added to the access authorization information.

[0009] This specification also provides an access authorization device for smart contracts, applied to a blockchain node; the blockchain node maintains access authorization information corresponding to smart contracts deployed on the blockchain; the device includes:

[0010] The receiving module receives an access authorization transaction for a first smart contract deployed on the blockchain; wherein the access authorization transaction includes a contract identifier of a second smart contract deployed on the blockchain, and access permission information for the first smart contract authorized to the second smart contract;

[0011] The verification module, in response to the access authorization transaction, performs a legality verification on the access authorization transaction;

[0012] If the access authorization transaction passes the legality verification, the authorization module adds the correspondence between the contract identifier of the second smart contract and the access permission information to the access authorization information.

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

[0014] processor;

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

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

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

[0018] In the above technical solution, a blockchain node in the blockchain can respond to a received access authorization transaction for the first smart contract. When the legality verification of the access authorization transaction is passed, the node adds the contract identifier of the second smart contract in the access authorization transaction and the corresponding relationship of the access permission information for the first smart contract authorized to the second smart contract to the access authorization information corresponding to the smart contract deployed on the blockchain maintained by the blockchain node.

[0019] Using the above method, for two smart contracts deployed on the blockchain, if the second smart contract is authorized to access the first smart contract, then the second smart contract can access the data maintained in the first smart contract, thus realizing data sharing between different smart contracts.

[0020] Furthermore, for two smart contracts sharing data, the shareable data can be maintained by only the first smart contract, while the second smart contract only needs to maintain the contract code. Therefore, the second smart contract can be split into multiple simpler sub-contracts, reducing the cost of smart contract development, testing, and upgrades. Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating an exemplary embodiment of a smart contract access authorization method.

[0022] Figure 2 This is a flowchart illustrating an exemplary embodiment of a smart contract access authorization revocation method.

[0023] Figure 3 This is a flowchart illustrating an exemplary embodiment of a smart contract access method in this specification.

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

[0025] Figure 5 This is a block diagram illustrating an access authorization device for a smart contract, as shown in an exemplary embodiment of this specification. Detailed Implementation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0040] 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0058] This specification aims to propose a technical solution for authorizing access to smart contracts. By maintaining access authorization information corresponding to smart contracts deployed on the blockchain through blockchain nodes, access permissions are controlled between different smart contracts.

[0059] In the above technical solution, a blockchain node in the blockchain can respond to a received access authorization transaction for the first smart contract. When the legality verification of the access authorization transaction is passed, the node adds the contract identifier of the second smart contract in the access authorization transaction and the corresponding relationship of the access permission information for the first smart contract authorized to the second smart contract to the access authorization information corresponding to the smart contract deployed on the blockchain maintained by the blockchain node.

[0060] In a practical implementation, for a smart contract deployed on the blockchain (which can be referred to as the first smart contract), the blockchain nodes in the blockchain can receive access authorization transactions for the first smart contract.

[0061] The aforementioned access authorization transaction may include the contract identifier of the smart contract (which may be referred to as the second smart contract) that can be granted access rights to the first smart contract, and the access rights information for the first smart contract that are authorized to the second smart contract.

[0062] Upon receiving the aforementioned access authorization transaction, the blockchain node can respond to the access authorization transaction by verifying its legitimacy.

[0063] If the access authorization transaction passes the legality verification, the correspondence between the contract identifier of the second smart contract and the access permission information can be added to the blockchain node in the blockchain. The blockchain node can maintain the access authorization information corresponding to the smart contract deployed on the blockchain.

[0064] Using the above method, for two smart contracts deployed on the blockchain, if the second smart contract is authorized to access the first smart contract, then the second smart contract can access the data maintained in the first smart contract, thus realizing data sharing between different smart contracts.

[0065] Furthermore, for two smart contracts sharing data, the shareable data can be maintained by only the first smart contract, while the second smart contract only needs to maintain the contract code. Therefore, the second smart contract can be split into multiple simpler sub-contracts, reducing the cost of smart contract development, testing, and upgrades.

[0066] Please refer to Figure 1 , Figure 1This is a flowchart illustrating an exemplary embodiment of a smart contract access authorization method.

[0067] In this embodiment, blockchain nodes in the blockchain can maintain access authorization information corresponding to smart contracts deployed on the blockchain.

[0068] In one embodiment shown, the access authorization information corresponding to smart contracts deployed on the blockchain may include an access authorization list (also known as an Access Control List, ACL) consisting of a correspondence between the contract identifiers of at least one smart contract and the access permission information granted to these at least one smart contract for other smart contracts. It should be noted that the contract identifier of a smart contract may specifically be the account identifier of the contract account corresponding to that smart contract. The contract identifiers of these at least one smart contract and the access permission information granted to these at least one smart contract for other smart contracts are in a one-to-one correspondence; for example, the access authorization list may include the contract identifier of smart contract A and the access permission information granted to smart contract A for smart contract B, whereby smart contract A can access data maintained in smart contract B.

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

[0070] In practical applications, the aforementioned access permission information can specifically be an Access Certificate (AC). To ensure data security of the access permission information, improve its usability, and save storage space, the access authorization list can specifically store the contract identifier of at least one smart contract, and the corresponding hash values ​​of the access permission information granted to this at least one smart contract for other smart contracts.

[0071] The access authorization method for the aforementioned smart contract may include the following steps:

[0072] Step 102: Receive an access authorization transaction for a first smart contract deployed on the blockchain; wherein the access authorization transaction includes a contract identifier of a second smart contract deployed on the blockchain, and access permission information for the first smart contract authorized to the second smart contract.

[0073] Step 104: In response to the access authorization transaction, perform a validity check on the access authorization transaction.

[0074] Step 106: If the access authorization transaction passes the legality verification, the correspondence between the contract identifier of the second smart contract and the access permission information is added to the access authorization information.

[0075] For the smart contract deployed on the aforementioned blockchain (which may be referred to as the first smart contract), the blockchain nodes in the blockchain can receive access authorization transactions for the first smart contract.

[0076] The aforementioned access authorization transaction may include the contract identifier of the smart contract (which may be referred to as the second smart contract) that can be granted access rights to the first smart contract, and the access rights information for the first smart contract that are authorized to the second smart contract.

[0077] Upon receiving the aforementioned access authorization transaction, the blockchain node can respond to the access authorization transaction by verifying its legitimacy.

[0078] If the access authorization transaction passes the legality verification, the correspondence between the contract identifier of the second smart contract and the access permission information can be added to the access authorization information.

[0079] In such Figure 1 Based on the smart contract access authorization method shown, please refer to... Figure 2 , Figure 2 This is a flowchart illustrating an exemplary embodiment of a smart contract access authorization revocation method.

[0080] The method for revoking access authorization for the aforementioned smart contract may include the following steps:

[0081] Step 202: Receive an access authorization revocation transaction for the first smart contract; wherein the access authorization revocation transaction includes the contract identifier of the second smart contract and the access permission information for the first smart contract authorized to the second smart contract.

[0082] Step 204: In response to the access authorization revocation transaction, perform a legality verification on the access authorization revocation transaction.

[0083] Step 206: If the legality verification of the access authorization revocation transaction passes, then in the access authorization information, find the correspondence between the contract identifier of the second smart contract and the access permission information, and when the correspondence is found, delete the correspondence or switch the status of the correspondence to the revoked status.

[0084] For the smart contract deployed on the aforementioned blockchain (which may be referred to as the first smart contract), the blockchain nodes in the blockchain can receive access authorization revocation transactions for the first smart contract.

[0085] Similar to the access authorization transaction described above, the access authorization revocation transaction may also include the contract identifier of the second smart contract and the access permission information granted to the second smart contract for the first smart contract.

[0086] Upon receiving the aforementioned access authorization revocation transaction, the blockchain node can respond to the access authorization transaction by verifying its legality.

[0087] If the legality verification of the access authorization revocation transaction passes, the correspondence between the contract identifier of the second smart contract and the access permission information can be found in the access authorization information corresponding to the smart contract deployed on the blockchain maintained by the blockchain node. When the correspondence is found, the correspondence can be deleted or the status of the correspondence can be switched to the revoked status.

[0088] 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 digitally sign transactions initiated by the administrator, while the public key can be used to verify the signature. The public key can be broadcast within the blockchain.

[0089] In one embodiment, for the aforementioned access authorization transaction or access authorization revocation transaction, digital signature processing can be performed based on the private key of the manager corresponding to the first smart contract and the private key of the manager corresponding to the second smart contract. Correspondingly, the legality verification of the access authorization transaction or access authorization revocation transaction can specifically include verifying the signature based on the public key of the manager corresponding to the first smart contract and the public key of the manager corresponding to the second smart contract. If the signature verification passes, it can be determined that the legality verification of the access authorization transaction or access authorization revocation transaction has passed.

[0090] It should be noted that it can also be used in conjunction with, for example Figure 1The smart contract access authorization method shown, or as... Figure 2 Similar to the method for revoking access authorization for the smart contract shown, the access authorization information corresponding to the smart contract deployed on the blockchain and maintained by the aforementioned blockchain nodes is updated in whole or in part.

[0091] In such Figure 1 Based on the smart contract access authorization method shown, please refer to... Figure 3 , Figure 3 This is a flowchart illustrating an exemplary embodiment of a smart contract access method in this specification.

[0092] The above-mentioned smart contract access method may include the following steps:

[0093] Step 302: Receive a data access transaction for the second smart contract; wherein the data access transaction includes the data identifier of the target data to be accessed and the contract identifier of the second smart contract.

[0094] Step 304: In response to the data access transaction, search for the target data corresponding to the data identifier in the data maintained in the second smart contract, and if the target data is not found, further search for the access authorization information corresponding to the contract identifier of the second smart contract in the access authorization information.

[0095] Step 306: Based on the access permission information, determine the first smart contract that is authorized to access the second smart contract, and continue to search for the target data corresponding to the data identifier in the data maintained in the first smart contract.

[0096] For a smart contract deployed on the blockchain (e.g., the second smart contract mentioned above), a blockchain node in the blockchain can receive data access transactions for that second smart contract.

[0097] The aforementioned data access transaction may include the data identifier of the data to be accessed (which may be referred to as the target data) and the contract identifier of the aforementioned second smart contract.

[0098] Upon receiving the aforementioned data access transaction, the aforementioned blockchain node can respond to the data access transaction by searching for the target data corresponding to the data identifier in the data access transaction from the data maintained in the aforementioned second smart contract.

[0099] If the target data is not found in the data maintained in the second smart contract, the access permission information corresponding to the contract identifier of the second smart contract can be further searched in the access authorization information corresponding to the smart contract deployed on the blockchain.

[0100] Subsequently, based on the access permission information corresponding to the contract identifier of the second smart contract, the smart contract that grants access permission to the second smart contract (e.g., the first smart contract) can be determined, and the target data corresponding to the data identifier in the data access transaction can be searched in the data maintained in the first smart contract.

[0101] In one embodiment shown, the data maintained in the smart contract can be organized into a Merkle tree and stored in a local database mounted on the blockchain node. The Merkle tree stores key-value pairs. Therefore, the data identifier of the target data can include the key of the target data.

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

[0103] In one embodiment shown, the access permission information may further include an expiration date and a set of data identifiers for the data to which the access permission is granted to the second smart contract.

[0104] In the above situation, 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 based on the access permission information that the first smart contract authorized to the second smart contract has access permission.

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

[0106] In one embodiment shown, the native transaction types supported by the blockchain can be extended to create a native transaction for authorizing access to smart contracts, which may be referred to as an access authorization transaction.

[0107] For example, for a blockchain using the UTXO model, an access authorization transaction can be added to the existing transfer transactions it supports, specifically for authorizing access to smart contracts; while for a blockchain using the account model, an access authorization transaction can be added to the existing transfer transactions, smart contract creation transactions, and smart contract invocation transactions it supports, specifically for authorizing access to smart contracts.

[0108] Similarly, the native transaction types supported by the blockchain can be extended to create a native transaction for revoking access authorization to smart contracts, which can be called an access authorization revocation transaction.

[0109] It is possible to extend the native transaction types supported by the blockchain to create a native transaction for accessing smart contracts, which can be called a data access transaction.

[0110] The transaction formats for the aforementioned access authorization transactions, access authorization revocation transactions, and data 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 redefined.

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

[0112] like Figure 4 As shown, at the hardware level, the aforementioned devices include a processor 402, an internal bus 404, a network interface 406, memory 408, and non-volatile memory 410, 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 402 reads the corresponding computer program from the non-volatile memory 410 into memory 408 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.

[0113] Please refer to Figure 5 , Figure 5 This is a block diagram illustrating an access authorization device for a smart contract, as shown in an exemplary embodiment of this specification.

[0114] The aforementioned smart contract access authorization device can be applied to, for example... Figure 4The device shown is used to implement the technical solution of this specification. This device can act as a blockchain node in a blockchain; the blockchain node maintains access authorization information corresponding to smart contracts deployed on the blockchain; the access authorization device for the smart contract may include:

[0115] The receiving module 502 receives an access authorization transaction for a first smart contract deployed on the blockchain; wherein the access authorization transaction includes a contract identifier of a second smart contract deployed on the blockchain, and access permission information for the first smart contract authorized to the second smart contract;

[0116] The verification module 504, in response to the access authorization transaction, performs a legality verification on the access authorization transaction;

[0117] If the access authorization transaction passes the legality verification, the authorization module 506 adds the correspondence between the contract identifier of the second smart contract and the access permission information to the access authorization information.

[0118] Optionally, the device further includes:

[0119] The second receiving module receives an access authorization revocation transaction for the first smart contract; wherein the access authorization revocation transaction includes the contract identifier of the second smart contract and access permission information for the first smart contract authorized to the second smart contract;

[0120] The second verification module, in response to the access authorization revocation transaction, performs a legality verification on the access authorization revocation transaction;

[0121] If the access authorization revocation transaction passes the legality verification, the authorization revocation module searches for the correspondence between the contract identifier of the second smart contract and the access permission information in the access authorization information. When the correspondence is found, the module deletes the correspondence or switches the status of the correspondence to the revoked status.

[0122] Optionally, the access authorization transaction or the access authorization revocation transaction is digitally signed by the administrator corresponding to the first smart contract and the administrator corresponding to the second smart contract;

[0123] The verification module 504 or the second verification module:

[0124] Verify the digital signature of the access authorization transaction or the access authorization revocation transaction;

[0125] If the digital signature verification passes, the validity of the access authorization transaction or the access authorization revocation transaction is confirmed to have passed the verification.

[0126] Optionally, the device further includes:

[0127] The third receiving module receives a data access transaction for the second smart contract; wherein the data access transaction includes a data identifier of the target data to be accessed and a contract identifier of the second smart contract;

[0128] The first search module, in response to the data access transaction, searches for the target data corresponding to the data identifier in the data maintained in the second smart contract, and if the target data is not found, further searches for access permission information corresponding to the contract identifier of the second smart contract in the access authorization information; and...

[0129] The second search module, based on the access permission information, determines the first smart contract that has been granted access permissions to the second smart contract, and continues to search for the target data corresponding to the data identifier in the data maintained in the first smart contract.

[0130] Optionally, the access authorization information includes an access authorization list consisting of the contract identifier of at least one smart contract and the correspondence between the access permissions granted to the at least one target account for other smart contracts.

[0131] 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 smart contract; wherein, the key of the key-value pair is the contract identifier of the at least one smart contract, and the value of the key-value pair is the access permission information for other smart contracts authorized to the at least one target account.

[0132] Optionally, the data maintained in the second smart contract or the first smart contract 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;

[0133] The first search module or the second search module:

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

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

[0136] Second search module:

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

[0138] 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;

[0139] If the data identifier set includes the data identifier of the target data, the first smart contract that is granted access permissions to the second smart contract is determined based on the access permission information.

[0140] Optionally, the access authorization transaction is a native transaction supported by the blockchain for authorizing access to a smart contract; the access authorization revocation transaction is a native transaction supported by the blockchain for revoking access authorization to a smart contract; and the data access transaction is a native transaction supported by the blockchain for accessing a smart contract.

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

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

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

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

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

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

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

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

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

[0150] 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."

[0151] 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 smart contract access authorization method, applied to blockchain nodes; The blockchain node maintains access authorization information corresponding to the smart contracts deployed on the blockchain; The method includes: Receive an access authorization transaction for a first smart contract deployed on the blockchain; wherein the access authorization transaction is a native transaction supported by the blockchain for authorizing access to a smart contract; the access authorization transaction includes a contract identifier of a second smart contract deployed on the blockchain, and access permission information authorized to the second smart contract for data maintained by the first smart contract; In response to the access authorization transaction, the access authorization transaction is validated for legality. If the access authorization transaction passes the legality verification, the correspondence between the contract identifier of the second smart contract and the access permission information is added to the access authorization information to authorize the second smart contract to access the data maintained by the first smart contract.

2. The method according to claim 1, further comprising: Receive an access authorization revocation transaction for the first smart contract; wherein the access authorization revocation transaction includes the contract identifier of the second smart contract, and access permission information for the first smart contract authorized to the second smart contract; In response to the access authorization revocation transaction, the legality of the access authorization revocation transaction is verified; If the legality verification of the access authorization revocation transaction passes, then in the access authorization information, the correspondence between the contract identifier of the second smart contract and the access permission information is searched, and when the correspondence is found, the correspondence is deleted or the status of the correspondence is switched to the revoked status.

3. The method according to claim 1 or 2, wherein the access authorization transaction or the access authorization revocation transaction is digitally signed by the administrator corresponding to the first smart contract and the administrator corresponding to the second smart contract; Performing legality verification on the access authorization transaction or the access authorization revocation transaction includes: Verify the digital signature of the access authorization transaction or the access authorization revocation transaction; If the digital signature verification passes, the validity of the access authorization transaction or the access authorization revocation transaction is confirmed to have passed the verification.

4. The method according to claim 2, further comprising: Receive a data access transaction for the second smart contract; wherein the data access transaction includes a data identifier of the target data to be accessed and a contract identifier of the second smart contract; In response to the data access transaction, the system searches for the target data corresponding to the data identifier in the data maintained in the second smart contract. If the target data is not found, the system further searches for access permission information corresponding to the contract identifier of the second smart contract in the access authorization information. Based on the access permission information, the first smart contract that is granted access permission to the second smart contract is determined, and the target data corresponding to the data identifier is searched in the data maintained in the first smart contract.

5. The method according to claim 4, wherein the access authorization information includes an access authorization list consisting of a contract identifier of at least one smart contract and a correspondence between access permission information for other smart contracts 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 smart contract; wherein, The key of the key-value pair is the contract identifier of the at least one smart contract, and the value of the key-value pair is the access permission information for other smart contracts authorized to the at least one target account.

7. The method according to claim 4, wherein the data maintained in the second smart contract or the first smart contract 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; Searching for the target data corresponding to the data identifier in the data maintained in the second smart contract or the first smart contract 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.

8. 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 the second smart contract is authorized access; The step of determining the first smart contract to which the second smart contract is granted access based on the access permission information 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 data identifier set includes the data identifier of the target data, the first smart contract that is granted access permissions to the second smart contract is determined based on the access permission information.

9. The method according to claim 4, wherein the access authorization revocation transaction is a native transaction supported by the blockchain for revoking access authorization to a smart contract; and the data access transaction is a native transaction supported by the blockchain for accessing a smart contract.

10. An access authorization device for smart contracts, applied to a blockchain node; The blockchain node maintains access authorization information corresponding to the smart contracts deployed on the blockchain; The device includes: The receiving module receives an access authorization transaction for a first smart contract deployed on the blockchain; wherein the access authorization transaction is a native transaction supported by the blockchain for authorizing access to a smart contract; the access authorization transaction includes the contract identifier of a second smart contract deployed on the blockchain, and access permission information authorized to the second smart contract for data maintained by the first smart contract; The verification module, in response to the access authorization transaction, performs a legality verification on the access authorization transaction; If the access authorization transaction passes the legality verification, the authorization module adds the correspondence between the contract identifier of the second smart contract and the access permission information to the access authorization information, so as to authorize the access permission for the data maintained by the first smart contract to the second smart contract.

11. 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-9 by executing the executable instructions.

12. 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-9.

Images