CN107911373B - A blockchain rights management method and system - Google Patents

Abstract

The invention discloses a block chain authority management method and system. The method includes: identifying the authority change transaction sent by the user; wherein, the content of the authority change transaction includes the initiator, the user who changes the authority, the authority to be changed, and the corresponding change authority value; determine whether the initiator in the authority change transaction has authority change authority; if the initiator has authority change authority, modify the authority value of each user who needs to change authority to the corresponding change authority value, and execute the The permission change transaction of the block is recorded in the block; the transaction in the block is consensused, and the corresponding permission change transaction in the block takes effect after the consensus is passed. The authority management of this method is carried out directly in the blockchain without the need for external facilities, and is deeply integrated into the blockchain, which can perform all-round authority control on the blockchain. The change of authority needs to go through the consensus of the whole network, and Recorded in the blockchain, making the change record immutable and easy to audit.

Description

A blockchain rights management method and system

technical field

The present invention relates to the technical field of block chains, in particular to a block chain rights management method and system.

Background technique

The blockchain establishes a corresponding digital identity for each participant through cryptography. The digital identity of each participant consists of a pair of asymmetric public-private key pairs, where the public key can be generated through the private key. Participants use the private key to sign the information and send it to the blockchain. The blockchain recovers the public key based on the signature, and identifies the participant based on the public key (or its abstract), and further authenticates the participant's operation.

When the public blockchain processes the information provided by the participants, it needs to consume a certain fee, which is usually a token in the blockchain. Information can only be entered into the blockchain if the participant has a sufficient reserve of tokens. However, the above limitations are too simplistic to adapt to more complex application scenarios. When blockchain technology is applied to a specific industry, its participants are often enterprises and institutions in the industry. Due to factors such as security and performance, more detailed management of the rights of participants in the blockchain is required.

At present, for the above application scenarios, some rights management schemes have been proposed. The types and deficiencies of existing schemes are as follows:

First, access control is achieved through isolation. The specific implementation methods include but are not limited to: establish a virtual private network, and participants who can connect to nodes in the network have permissions; Perform rights management. The key point of such schemes is that rights management is undertaken by external facilities, not directly in the blockchain. The application of such schemes needs to bear the risks of external facility failure and evil, so such schemes are mostly used in scenarios with a high degree of trust between participants.

Second, use smart contracts for authority management. The key to this scheme is the authority management smart contract. The smart contract saves the identity and authority information, and other smart contracts realize the authentication of authority by calling the interface of the smart contract during the execution process. The permission information and authentication logic in this scheme are all implemented at the smart contract level, so it is impossible to control the permissions below the smart contract level (such as sending transactions, obtaining blockchain status, etc.). Applying this kind of scheme needs to bear the risk of transaction flood attack (recording a large number of useless transactions in the blockchain).

Therefore, how to solve the above problems and realize the all-round configuration of the permissions in the blockchain is not limited to the level of smart contracts and does not require external facilities, which is a technical problem that technicians in the field need to solve.

Contents of the invention

The purpose of the present invention is to provide a block chain rights management method and system to realize all-round configuration of the rights in the block chain, not only limited to the smart contract level, but also without external facilities.

In order to solve the above technical problems, the present invention provides a block chain rights management method, the method comprising:

Identify the authority change transaction sent by the user; wherein, the content of the authority change transaction includes the initiator, the user who changes the authority, the authority to be changed, and the corresponding change authority value;

judging whether the initiator in the authority change transaction has authority change authority;

If the initiator has permission to change the permission, modify the permission value of each permission change user who needs to change permission to the corresponding permission change value, and record the permission change transaction after execution into the block;

Consensus is carried out on the transactions in the block, and the corresponding permission change transaction in the block takes effect after the consensus is passed.

Optionally, the judging whether the initiator in the authority change transaction has authority change authority includes:

Obtain the latest block from the blockchain, and obtain verification information from the latest block as the root of the MPT tree;

Constructing an MPT tree by using the root of the MPT tree, and obtaining permission information corresponding to the initiator from the MPT tree;

It is judged according to the authority information whether the initiator in the authority change transaction has the authority to change the authority.

Optionally, the judging whether the initiator in the authority change transaction has authority change authority includes:

Call the smart contract interface to obtain the permission information corresponding to the initiator from the database;

It is judged according to the authority information whether the initiator in the authority change transaction has the authority to change the authority.

Optionally, the consensus on the transactions in the block is carried out, and the corresponding permission change transaction in the block takes effect after the consensus is passed, including:

When the block is received, extract all transactions in the block;

Constructing a temporary block on the basis of the received parent block of the block, and sequentially executing each of the transactions in the temporary block;

After all the transactions are executed, it is judged whether the permission verification information in the temporary block is consistent with the received permission verification information in the block;

If they are consistent, the transaction verification in the block is passed, and a consensus is carried out, and when the consensus is passed, the corresponding authority change transaction in the block takes effect.

Optionally, the authorization change transaction sent by the identification user includes:

Receive transactions sent by users;

Judging whether the transaction has an authority change transaction setting identifier;

If so, determine that the transaction is a permission change transaction.

Optionally, the way to save permissions in the blockchain includes:

Processing each authority information by using a data digest algorithm to generate verification information corresponding to each authority information;

A key field of the verification information is added in the block structure to record the permission information corresponding to each block.

Optionally, the method also includes:

Identify actions sent by users;

Determine whether the initiator of the operation has the authority to perform the operation;

If the initiator of the operation has the authority to execute the operation, execute the operation.

The present invention also provides a blockchain authority management system, the system comprising:

The identification module is used to identify the authority change transaction sent by the user; wherein, the content of the authority change transaction includes the initiator, the user who changes the authority, the authority to be changed, and the corresponding change authority value;

A judging module, configured to judge whether the initiator in the authority change transaction has authority change authority;

A permission change execution module, configured to modify the permission value of each user whose permission needs to be changed to a corresponding permission value if the initiator has permission to change the permission, and change the permission after execution The transaction is recorded in the block;

The consensus module is configured to perform consensus on the transactions in the block, and the corresponding authority change transaction in the block takes effect after the consensus is passed.

Optionally, the judging module includes:

The permission reading unit is used to obtain the latest block from the blockchain;

A verification information acquisition unit, configured to obtain verification information from the latest block as the root of the MPT tree;

A first authority information acquisition unit, configured to use the root of the MPT tree to construct an MPT tree, and acquire authority information corresponding to the initiator from the MPT tree;

A first judging unit, configured to judge whether the initiator in the authority change transaction has authority change authority according to the authority information.

Optionally, the judging module includes:

The second permission information acquisition unit is used to call the smart contract interface to obtain the permission information corresponding to the initiator from the database;

A second judging unit, configured to judge whether the initiator in the authority change transaction has authority change authority according to the authority information.

A block chain authority management method provided by the present invention deeply integrates authority management into the block chain. Every operation on permissions requires a consensus from the entire network to take effect. Every operation will be packaged and recorded in the blockchain for easy auditing. Due to the deep integration in the blockchain, during the implementation process, the permissions in the blockchain can be fully configured, not limited to the smart contract level, and no external facilities are required. The present invention also provides a block chain authority management system, which has the above beneficial effects, and will not be repeated here.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings that need to be used in the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only It is an embodiment of the present invention, and those skilled in the art can also obtain other drawings according to the provided drawings without creative work.

Fig. 1 is a flow chart of the block chain rights management method provided by the embodiment of the present invention;

Fig. 2 is a structural block diagram of a blockchain authority management system provided by an embodiment of the present invention.

Detailed ways

The core of the present invention is to provide a block chain authority management method and system, the authority management of which is carried out directly in the block chain, without the need for external facilities, and deeply integrated into the block chain, which can comprehensively control the block chain Permission control, the change of authority needs to go through the consensus of the whole network and be recorded in the blockchain, so that the change record cannot be tampered with and is convenient for auditing.

In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments It is a part of embodiments of the present invention, but not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by persons of ordinary skill in the art without making creative efforts belong to the protection scope of the present invention.

Please refer to Fig. 1, Fig. 1 is a flow chart of the blockchain rights management method provided by the embodiment of the present invention; the method may include:

S100. Identify a permission change transaction sent by a user; wherein, the content of the permission change transaction includes an initiator, a user who changes permission, a permission to be changed, and a corresponding change permission value.

Since the block chain authority management method provided in this embodiment requires deep integration into the block chain, it can carry out all-round authority control on the block chain, so as to overcome the block chain authority that can only be realized at the smart contract level in the prior art. Governance (that is, inability to control permissions below the smart contract level, such as sending transactions, obtaining blockchain status, etc.) or relying on external facilities. Therefore, this embodiment adds a new transaction type in the blockchain, that is, authority change transaction, which corresponds to the operation of authority. Whenever the blockchain receives a permission change request, a corresponding permission change transaction will be generated. The permission change transaction can be similar to ordinary transactions, and will be recorded in the block after execution, that is, the change history of permission information will be recorded in the blockchain for auditing. At the same time, a receipt (Receipt) can be generated like a normal transaction, so that the user can determine whether the authority change transaction is successful according to the receipt, that is, the receipt can enable the user to know the execution status of the authority change transaction in time. In this embodiment, the modification operations of the authorization information through the authorization modification transaction include: adding, deleting, modifying, and so on. The rights involved in the embodiments may include rights management, contract deployment, and sending ordinary transactions. Actually, they are not limited to the above three types, and may even include complex rights with restrictions (such as validity period).

Further, this embodiment does not limit the way of sending the authority change transaction to the blockchain, for example, it may send the authority change transaction through the external call interface, or send the authority change transaction through the smart contract interface. Specifically, the user can operate the permission information by calling the external interface. Or the user calls the smart contract interface, so that the smart contract virtual machine operates the permission information during the execution of the smart contract. With the help of the smart contract interface, automatic configuration of permissions using smart contracts can be realized. Of course, if automatic configuration is not required, the smart contract interface with this function may not be provided. Other smart contracts on the blockchain can directly change and obtain permission information through message calls between contracts. The access interface for external users can be JSONRPC. The following takes the JSONRPC interface as an example to illustrate the specific form of permission change transaction requests.

Example JSONRPC interface request:

{"jsonrpc":"2.0","method":"get_permission","params":["0x1234567890123456789012345678901234567890"],"id":1}

Example JSONRPC interface response:

{"jsonrpc":"2.0","id":1,"result":{"change_permission":false,"deploy_contract":true,"send_transaction":false}}

Since the authority change transaction is similar to other ordinary transactions, it is necessary to enable the blockchain to identify the authority change transaction. This embodiment does not limit a specific identification method. For example, it can be distinguished from ordinary transactions by adding a special identifier to the authority change transaction, or by sending unique identification information such as the address of the specific interface corresponding to the authority change transaction to distinguish it from ordinary transactions. This embodiment does not limit the type and form of the identification, as long as it can have a unique correspondence with the authority change transaction. That is, optionally, identifying a permission change transaction sent by a user may include:

Receive transactions sent by users;

Determine whether the transaction has permission to change the transaction setting flag;

If yes, determine that the transaction is a permission change transaction.

Specifically, this embodiment does not limit the form of the authority change transaction setting identifier. For example, it can be to add a special identification bit in the transaction; or according to the address of the smart contract called. For example, users can directly send transactions and call interfaces in permission smart contracts. According to the address of the calling contract, it can be distinguished whether the transaction is a permission change transaction. Or the user sends a permission change transaction to the blockchain, which has a special identifier, so that the blockchain can recognize that the operation of the transaction is a permission change.

This embodiment does not limit the content and format of the content contained in the authority change transaction, and the user can set it according to the actual situation. However, the authority change transaction needs to include at least the initiator of the authority change transaction, the authority change user (that is, the user to be changed, which can be represented by an external account address), and the authority to be changed (that is, the item to be changed authority, such as a deployment contract , send transactions, etc.), change the authority value (that is, the value of the authority to be changed, for example, it can be represented by True or False).

S110. Determine whether the initiator in the authority change transaction has authority change authority.

Specifically, steps S110 and S120 are the specific execution process of the authority change transaction. The step S110 is mainly to judge whether the originator of the authority change transaction is legal, that is, whether the originator has the authority to perform the change and modification operation of the blockchain authority. Only when the authority change transaction initiator is legal, the specific change operation will be executed. When the authority change transaction initiator is illegal, the authority change transaction fails. This embodiment does not limit the specific determination process, which is related to the storage form of the authority information and the like. That is, how to save permissions in an application scenario such as blockchain, such as how to maintain a permission table. In order to further ensure the reliability of authority management, the change record of authority information can be protected by cryptographic means, which cannot be tampered with. It is also convenient for auditing. For example, use a cryptographically verifiable data structure to store permission information. This data structure provides verification information in addition to saving the original data. The verification information has the following characteristics:

First: the same original data has the same verification information;

Second: It is difficult to construct matching original data based on the verification information.

Among them, the information field is usually generated using a digest algorithm in cryptography. The verification information of the permission information is included in the block structure as a key field. The meaning of the key field is: this field will be encoded into the block data and used to generate the hash of the block. Through the above design, the change of authority information will lead to the change of its verification information, and the change of verification information will lead to the change of block data and its hash. Therefore, the correctness of the permission information can be quickly checked through the block hash, making it difficult for the permission information to be tampered with. This can be achieved using any method that can cause a deterministic change in the block hash, such as through a Trie. Preferably, the way to save permissions in the blockchain can include:

Use the data digest algorithm to process each authority information to generate the verification information corresponding to each authority information; add the key field of the verification information in the block structure to record the authority information corresponding to each block . In this way, the change of the corresponding verification information in each block (that is, the data corresponding to the key field of the block) will cause the change of the block data and its hash. Therefore, the correctness of the permission information can be quickly checked through the block hash, making it difficult for the permission information to be tampered with. Two optional embodiments are listed below.

The first, optional, judging whether the initiator in the authority change transaction has the authority to change may include:

Obtain the latest block from the blockchain, and obtain the verification information from the latest block as the root of the MPT tree;

Use the root of the MPT tree to construct the MPT tree, and obtain the permission information corresponding to the initiator from the MPT tree;

According to the authority information, it is judged whether the initiator in the authority change transaction has the authority to change the authority.

Wherein, the storage form of the permission information corresponding to this judgment method may be as follows:

Use the MPT (Merkle Patricia Trie) tree to save the authority data, and use the hash of its root node as the verification information of the authority data. Add a new block field (such as the permissions field) in the block structure to save the verification information of the permission data. The structure of the authority data may be a user-based list, a group-based list, etc., which is not limited here. The permissions involved can be configured according to the characteristics of the blockchain, such as sending transactions, deploying contracts, calling read-only interfaces, etc., without specific restrictions. At this time, according to the characteristics of the blockchain, the permission information in a certain block can be obtained. The specific steps are as follows:

1. Obtain the specified block from the database (the specified block can be determined according to the block number or block hash, and the specified block here can be the latest block).

2. Obtain the value of the permissions field from the key field of the block.

3. Construct a Merkle Patricia Trie tree according to the value of permissions.

4. Obtain the permission information corresponding to the initiator from the Merkle Patricia Trie tree.

The second, optional, judging whether the initiator in the authority change transaction has the authority to change may include:

Call the smart contract interface to obtain the permission information corresponding to the initiator from the database;

According to the authority information, it is judged whether the initiator in the authority change transaction has the authority to change the authority.

Among them, the permission information corresponding to this judgment method is stored in the smart contract. The specific implementation is as follows:

1. Writing a smart contract is called a permission smart contract.

2. Write the permission smart contract into the genesis block.

3. Assign a specific address to the permission smart contract.

After the above steps, the permission information will be saved in the storage area (storage) of the permission smart contract. Changes to permission information will result in changes to the contract storage area, resulting in changes to the State Trie, resulting in changes to the hash of the block. In this embodiment, the state tree can be used as verification information of permissions. Due to the adoption of the smart contract, external users can directly call the interface in the smart contract to query the permission information. It is exactly the same as the ordinary smart contract query method, so I won't repeat it here. The following two methods can be used to obtain permission information inside the blockchain to control operations.

First: Simulate the execution of the call inside the blockchain, and call the smart contract interface to obtain the authority value.

Second: Simulate the execution of the smart contract and obtain the authority value directly from the database.

S120. If the initiator has permission to change the permission, modify the permission value of each permission change user who needs to change permission to the corresponding permission change value, and record the permission change transaction after execution in the block.

Specifically, if the initiator does not have permission to change permissions at this time, the permission change transaction will fail. In order to completely record the process of permission modification, it is also necessary to record the permission change transaction in the block at this time. Further, if the initiator has permission to change the permission, the permission value of each permission change user who needs to change permission is modified to the corresponding permission change value, and the executed permission change transaction is recorded in the block no matter whether the modification is successful or not.

The way transactions are executed in these two methods is also different. The first method is to first obtain the verification information from the temporary block, and use it as the root to build an MPT tree. Update the changed permission information to the MPT tree. Obtain the root of the updated MPT tree as the new permission verification information of the block. The second is to directly call the smart contract interface to execute the transaction. After the smart contract is executed, the verification information in the block will be automatically updated.

In any case, a receipt can be generated, so that the initiator can judge the specific execution of the authority change transaction through the specific content of the receipt.

S130. Consensus is carried out on the transactions in the block, and the corresponding authority change transaction in the block takes effect after the consensus is passed.

Specifically, in order to ensure the legitimacy and effectiveness of permission changes in this embodiment, permission transactions need to be recorded in the blockchain only after the entire network reaches a consensus, and the permission changes will take effect. That is, it can be understood that step S130 is the consensus process of the blockchain, which includes the process of verifying changes in permission information. This embodiment does not limit the specific conditions for passing the consensus of the whole network. For example, if more than two-thirds of the user consensus of the entire network is passed, it is considered that the authority change transaction has achieved the consensus of the entire network. At this time, after the consensus is passed, the corresponding permission change transaction in the block will take effect. That is, it is optional to carry out a consensus on the transactions in the block. When the consensus is passed, the corresponding authority change transaction in the block will take effect, which can include:

When a block is received, extract all transactions in the block;

Construct a temporary block based on the parent block of the received block, and execute each transaction in sequence in the temporary block;

When all transactions are executed, it is judged whether the permission verification information in the temporary block is consistent with the permission verification information in the received block;

If they are consistent, the transaction verification in the block is passed, and a consensus is carried out, and when the consensus is passed, the corresponding authority change transaction in the block takes effect.

Among them, the specific execution form of each transaction is executed sequentially in the temporary block, that is, the execution method of the permission change transaction is different according to the different permission acquisition forms. For example, when permission information is obtained in the form of an MPT tree, the execution method of the corresponding permission change transaction is: first obtain the verification information from the temporary block and use it as the root to build the MPT tree. Update the changed permission information to the MPT tree. Obtain the root of the updated MPT tree as the new permission verification information of the block. When using the smart contract interface to obtain permission information, the execution method of the corresponding permission change transaction is: directly call the smart contract interface to execute the transaction, and the verification information in the block will be automatically updated after the smart contract is executed.

Wherein, in this embodiment, the conditions for passing the consensus are not limited, and the specific conditions vary according to the consensus algorithm used.

Specifically, all transactions in the block at this time include authority change transactions and ordinary transactions, that is, the verification of authority information changes is usually performed at the same time as the verification of ordinary transactions. Each blockchain user will perform the above verification process. When the consensus process is completed and the result is correct, the corresponding permission change transaction in the block will take effect. This embodiment does not limit the specific algorithm used in the consensus process.

Based on the above technical solution, the block chain rights management method provided by the embodiment of the present invention deeply integrates the rights management into the block chain. The blockchain provides an operation interface for permissions, including adding, deleting, modifying, and checking. Every operation on permissions requires a consensus on the entire network to take effect, and the process of consensus and entry into force does not require manual intervention. Every operation will be recorded in the blockchain for easy auditing. Permission information and historical records of operations are protected by cryptography and cannot be tampered with maliciously. Due to the deep integration in the blockchain, this solution can fully configure the permissions in the blockchain during the implementation process, not limited to the level of smart contracts, and does not require external facilities.

During the operation of the blockchain, whenever a scene that requires judging permissions is encountered, no matter what form the initiator initiates the transaction (such as a transaction initiated through a smart contract interface), no matter what type of transaction is involved in the transaction Permission will verify whether the initiator has the permission of the operation, and only if the initiator has the permission, it will be allowed to perform the corresponding operation. Even the user may not have initiated a transaction, but just sent a normal request. For example, when a user initiates a transaction through the smart contract interface, it will be judged whether the initiator in the deployment smart contract transaction has the authority to deploy the smart contract. Therefore, based on any of the above embodiments, the method may further include:

Identify actions sent by users;

Determine whether the initiator of the operation has the authority to perform the operation;

If the initiator of the operation has the authority to execute the operation, execute the operation.

Based on the above technical solution, the blockchain authority management method provided by the embodiment of the present invention can not only deeply integrate the authority management into the blockchain, but also can perform all-round configuration of the authority in the blockchain, not limited to the smart contract level , without the need for external facilities. It can also verify the permissions of various forms of operations in the blockchain to ensure the reliability of operations.

The following is an introduction to the blockchain authority management system provided by the embodiment of the present invention. The blockchain authority management system described below and the blockchain authority management method described above can be referred to each other.

Please refer to Fig. 2, Fig. 2 is a structural block diagram of the blockchain rights management system provided by the embodiment of the present invention; the system may include:

The identification module 100 is used to identify the authority change transaction sent by the user; wherein, the content of the authority change transaction includes the initiator, the user who changes the authority, the authority to be changed, and the corresponding change authority value;

Judging module 200, used to judge whether the initiator in the authority change transaction has authority change authority;

The permission change execution module 300 is used to modify the permission value of each permission change user who needs to change permission to the corresponding change permission value if the initiator has permission change permission, and record the permission change transaction after execution to the block middle;

The consensus module 400 is used to carry out consensus on the transactions in the block, and when the consensus is passed, the corresponding authority change transaction in the block takes effect.

Based on the above-mentioned embodiments, the judging module 200 may include:

The permission reading unit is used to obtain the latest block from the blockchain;

The verification information acquisition unit is used to obtain the verification information from the latest block as the root of the MPT tree;

A first authority information acquisition unit, configured to use the root of the MPT tree to construct an MPT tree, and acquire authority information corresponding to the initiator from the MPT tree;

The first judging unit is configured to judge whether the initiator in the authority change transaction has the authority to change according to the authority information.

Based on the above-mentioned embodiments, the judging module 200 may include:

The second permission information acquisition unit is used to call the smart contract interface to obtain the permission information corresponding to the initiator from the database;

The second judging unit is configured to judge whether the initiator in the authority change transaction has the authority to change according to the authority information.

Based on any of the above embodiments, the identification module 100 may include:

The receiving unit is used to receive the transaction sent by the user;

An identification judging unit, configured to determine whether the transaction has an authority change transaction setting identification;

The identification unit is configured to determine that the transaction is an authority change transaction if it has an authority change transaction setting flag.

Based on any of the above embodiments, the system may also include:

An operation identification module, used to identify the operation sent by the user;

An operation authority judging module, configured to determine whether the initiator of the operation has the authority to perform the operation;

An operation executing module, configured to execute the operation if the initiator of the operation has the authority to execute the operation.

Each embodiment in the description is described in a progressive manner, each embodiment focuses on the difference from other embodiments, and the same and similar parts of each embodiment can be referred to each other. As for the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and for the related information, please refer to the description of the method part.

Professionals can further realize that the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein can be implemented by electronic hardware, computer software or a combination of the two. In order to clearly illustrate the possible For interchangeability, in the above description, the composition and steps of each example have been generally described according to their functions. Whether these functions are executed by hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art may use different methods to implement the described functions for each specific application, but such implementation should not be regarded as exceeding the scope of the present invention.

The steps of the methods or algorithms described in connection with the embodiments disclosed herein may be directly implemented by hardware, software modules executed by a processor, or a combination of both. Software modules can be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other Any other known storage medium.

The above has introduced in detail a blockchain rights management method and system provided by the present invention. In this paper, specific examples are used to illustrate the principle and implementation of the present invention, and the descriptions of the above embodiments are only used to help understand the method and core idea of the present invention. It should be pointed out that for those skilled in the art, without departing from the principles of the present invention, some improvements and modifications can be made to the present invention, and these improvements and modifications also fall within the protection scope of the claims of the present invention.

Claims (9)

1. A block chain authority management method, is characterized in that, described method comprises: Identify the authority change transaction sent by the user; wherein, the content of the authority change transaction includes the initiator, the user who needs to change the authority, the authority to be changed, and the corresponding change authority value; and the authority change transaction is similar to ordinary transactions in the blockchain; The involved permissions include authority management, deploying contracts, and sending ordinary transactions; sending the authority change transactions through the smart contract interface; judging whether the initiator in the authority change transaction has authority change authority; If the initiator has permission to change the permission, modify the permission value of each permission change user who needs to change permission to the corresponding permission change value, and record the permission change transaction after execution into the block; Use the smart contract interface to automate the configuration of permissions; Consensus is carried out on the transactions in the block, and the corresponding permission change transaction in the block takes effect after the consensus is passed; Also includes: Identify actions sent by users; Determine whether the initiator of the operation has the authority to perform the operation by directly or simulated calling the smart contract interface; wherein, direct calling refers to simulating the execution of the call inside the blockchain, calling the smart contract interface to obtain the authority value, Simulated calling refers to simulating the execution of the smart contract and obtaining the authority value directly from the database; If the initiator of the operation has the authority to execute the operation, execute the operation. 2. The method according to claim 1, wherein the judging whether the initiator in the authority change transaction has authority to change comprises: Obtain the latest block from the blockchain, and obtain verification information from the latest block as the root of the MPT tree; Constructing an MPT tree by using the root of the MPT tree, and obtaining permission information corresponding to the initiator from the MPT tree; It is judged according to the authority information whether the initiator in the authority change transaction has the authority to change the authority. 3. The method according to claim 1, wherein the judging whether the initiator in the authority change transaction has authority to change comprises: Call the smart contract interface to obtain the permission information corresponding to the initiator from the database; It is judged according to the authority information whether the initiator in the authority change transaction has the authority to change the authority. 4. The method according to claim 1, wherein the consensus on the transactions in the block is carried out, and when the consensus is passed, the corresponding permission change transaction in the block takes effect, including: When the block is received, extract all transactions in the block; Constructing a temporary block on the basis of the received parent block of the block, and sequentially executing each of the transactions in the temporary block; After all the transactions are executed, it is judged whether the permission verification information in the temporary block is consistent with the received permission verification information in the block; If they are consistent, the transaction verification in the block is passed, and a consensus is carried out, and when the consensus is passed, the corresponding authority change transaction in the block takes effect. 5. The method according to claim 4, wherein the identifying the authority change transaction sent by the user comprises: Receive transactions sent by users; Judging whether the transaction has an authority change transaction setting identifier; If so, determine that the transaction is a permission change transaction. 6. The method according to any one of claims 1-5, characterized in that, the way of saving rights in the blockchain includes: Processing each authority information by using a data digest algorithm to generate verification information corresponding to each authority information; A key field of the verification information is added in the block structure to record the permission information corresponding to each block. 7. A blockchain authority management system, characterized in that the system comprises: The identification module is used to identify the authority change transaction sent by the user; wherein, the content of the authority change transaction includes the initiator, the user who needs to change the authority, the authority to be changed, and the corresponding change authority value; and the authority change transaction is related to the block chain Similar to ordinary transactions; the involved permissions include authority management, contract deployment, and sending ordinary transactions; sending the authority change transactions through the smart contract interface; A judging module, configured to judge whether the initiator in the authority change transaction has authority change authority; A permission change execution module, configured to modify the permission value of each user whose permission needs to be changed to a corresponding permission value if the initiator has permission to change the permission, and change the permission after execution The transaction is recorded in the block; the automatic configuration of permissions is performed using the smart contract interface; A consensus module, configured to perform consensus on transactions in the block, and when the consensus is passed, the corresponding authority change transaction in the block takes effect; Also includes: An operation identification module, used to identify the operation sent by the user; The operation authority judging module is used to judge whether the initiator of the operation has the authority to perform the operation by directly or simulated calling the smart contract interface; wherein, the direct call refers to the execution of the simulated call inside the block chain, and the call The smart contract interface gets the permission value, and the simulated call refers to simulating the execution of the smart contract, directly obtaining the permission value from the database; An operation executing module, configured to execute the operation if the initiator of the operation has the authority to execute the operation. 8. The system according to claim 7, wherein the judging module comprises: The permission reading unit is used to obtain the latest block from the blockchain; A verification information acquisition unit, configured to obtain verification information from the latest block as the root of the MPT tree; A first authority information acquisition unit, configured to use the root of the MPT tree to construct an MPT tree, and acquire authority information corresponding to the initiator from the MPT tree; A first judging unit, configured to judge whether the initiator in the authority change transaction has authority change authority according to the authority information. 9. The system according to claim 7, wherein the judging module comprises: The second permission information acquisition unit is used to call the smart contract interface to obtain the permission information corresponding to the initiator from the database; A second judging unit, configured to judge whether the initiator in the authority change transaction has authority change authority according to the authority information.