Editable Blockchain Editing Method, System and Device with Dynamic Editing Rights

Abstract

The present invention belongs to the field of blockchain technology, and discloses an editable blockchain editing method, system and device with dynamic editing rights. The method of the present invention includes: constructing a leader public key and a main trapdoor; when a user needs to edit data on the blockchain, querying their own credit points, generating an editing request and sending it to the leader after determining the right to initiate the editing request; after the leader verifies the permissions, broadcasting the editing request to other users in the system; the users and the leader respectively perform self-checks and verifications on the voting permissions, and if the voting passes, the leader generates a subordinate trapdoor and distributes the sub-keys of the subordinate trapdoor to each user; selecting an editor for the current editing request to perform the editing; the supervisor verifies the editing operation and updates the credit points of relevant users. The present invention can realize the editable function of the blockchain system, dynamically adjust the editing permissions, and can solve the problems of accountability when problems occur in the edited data and the limitation of editing permissions.

Description

Technical Field

[0001] The present invention belongs to the technical field of blockchain, and particularly relates to an editable blockchain editing method, system and device with dynamic editing rights. Background Art

[0002] The core feature of traditional blockchain technology is the immutability of data, which is achieved through cryptographic hash functions and consensus mechanisms, ensuring the credibility and security of data. However, this also leads to the problem of lack of flexibility, as once data is written into the blockchain, it cannot be modified. In addition, permissionless blockchain networks may lead to malicious users abusing their permissions to store sensitive or illegal data. And immutability also limits the application of blockchain in multiple fields, such as the financial and copyright fields. Therefore, a blockchain solution with editability and traceability can better meet the needs of data updates and privacy protection, and promote the application of blockchain in a wider range of fields.

[0003] Currently, many solutions have been proposed for such problems, but their functions are not perfect.

[0004] The paper "G. Ateniese, B. Magri, D. Venturi, and E. Andrade, RedactableBlockchain – or – Rewriting History in Bitcoin and Friends, in 2017 IEEEEuropean Symposium on Security and Privacy (EuroS&P), IEEE, 2017." explored the concept of modifiable blockchain. Their permissioned blockchain solution based on chameleon hash uses a chameleon hash function with a trapdoor to implement editing blocks and maintain hash consistency. However, this solution does not address the issues of accountability when problems occur with the edited data and the limitation of editing permissions.

[0005] The paper "K. Ashritha, M. Sindhu, and K. V. Lakshmy, Redactable Blockchainusing Enhanced Chameleon Hash Function, in International Conference onAdvanced Computing and Communication Systems, 2019." proposed an editable blockchain solution using an enhanced chameleon hash, in which a non-linear secret sharing scheme is adopted to prevent malicious sharing of false shares. However, this solution also does not address the issues of accountability when problems occur with the edited data and the adjustment of editing permissions.

[0006] The paper "Y. Jia, S. F. Sun, Y. Zhang, Z. Liu, and D. Gu, RedactableBlockchain Supporting Supervision and Self-Management, in ASIA CCS '21: ACMAsia Conference on Computer and Communications Security, ACM, 2021." proposed a stateful chameleon hash with revocable sub-keys (sCHRS) and designed a new type of redactable blockchain construction. They introduced a semi-trusted supervisor to supervise the editing behavior, but did not consider how to hold illegal acts accountable or solve the problem of adjusting editing permissions. Summary of the Invention

[0007] The purpose of the present invention is to provide an editable blockchain editing method, system and device with dynamic editing rights in view of the deficiencies of the prior art, which is used to implement the editable function of the blockchain system, dynamically adjust the editing rights, and can solve the problems of accountability and editing right limitations when problems occur in the edited data.

[0008] Specifically, the present invention is implemented by the following technical solutions.

[0009] On the one hand, the present invention provides an editable blockchain editing method with dynamic editing rights, including:

[0010] Master trapdoor generation stage: The leader selects a multiplicative cyclic group and , and whose order is , the generator is , sets a bilinear mapping , selects hash functions and , represents the unit group of order , and a secure pseudorandom number generator , outputs the public parameters ; generates three random numbers , where , and calculates ; generates a signature key pair using the public parameters, and then constructs the leader's public key and the master trapdoor ;

[0011] Editing Request Phase: When a user needs to edit data on the blockchain, the user first queries their reputation score from the leader, determines the corresponding user permissions based on the preset reputation score permission grading rules to determine whether they have the right to initiate an editing request. The user who has the right to initiate an editing request packs their identity identifier , the original message , and the new message they hope to modify into an editing request and sends it to the leader; the leader queries the user's reputation score to verify whether the user has the permission to initiate an editing request. If so, the leader broadcasts the editing request to other users in the system and enters the voting phase;

[0012] Voting Phase: After receiving the editing request, other users in the system perform a self-check on their voting permissions. If they have voting permissions, they select a random number for this vote , calculate a hash value for the editing request using a hash function , and then encrypt the hash value , the random number using the leader's public key as the encrypted voting information and send it to the leader; after receiving the encrypted voting information, the leader checks whether the user has voting permissions based on the user's reputation score. Votes cast by users without voting permissions will be discarded, and votes cast by users with voting permissions are valid votes; the voting result formed by aggregating all valid votes is decrypted by the leader using the leader's private key. If a set proportion of users agree to the editing request, the voting result is considered to have passed; otherwise, this process ends; calculate the sum of the random numbers in all valid votes ;

[0013] Trapdoor Generation Phase: If the voting result is passed, the leader generates a new random string , a secondary trapdoor and a witness based on the triple composed of the hash value of the block , the original message , the new message , and the main trapdoor , and then broadcasts the generated new random string and witness ; after receiving them, users use the leader's public key , the triple composed of the hash value of the block , the original message , the random string , the received new random string and witness ​​​, verify the hash value of the block Validity, inspection and witness Is it valid? After the verification result is counted and passed by the leader, the generation of the slave trapdoor is completed.

[0014] Secret sharing phase: The leader distributes the subkey of the trapdoor to each user; after receiving the subkey of the trapdoor, the user verifies the distribution process of the subkey of the trapdoor and obtains the subkey of the trapdoor through decryption. , and construct the corresponding proof ;

[0015] Edit phase: The user receives the sum of the random numbers broadcast by the leader , combined with the user's own public key , calculate its own candidate editor hash value, and broadcast it and the user's public key to the chain; the user receives the candidate editor hash values ​​of other users broadcasted by other users, and integrates them into an array after sorting; each user then finds the candidate editor with editing rights and the smallest candidate editor hash value from all candidate editors, sends it to the leader for confirmation, and then becomes the editor of this editing request, and then the user sends the decrypted subkey Sent to the editor of this edit request; the editor of this edit request subsequently recovers the trapdoor key And send it to the leader, after the leader verifies it, get it from the trapdoor ; Then according to the trapdoor Calculate new message The corresponding final random string , perform data editing;

[0016] Verification and maintenance reputation stage: Supervisors verify the editing operations. During this process, the reputation points of relevant users are updated according to the preset reputation point update rules based on the verification results to reward compliant operations and punish violations.

[0017] Furthermore, the credit points authority classification rules are as follows:

[0018] Nodes with a reputation score of [0, A) are classified as malicious nodes, and have no voting rights, no edit request rights, and no edit rights;

[0019] The node with reputation points at [A, B) is classified as a common node. This node has voting rights, but no edit request rights and no edit rights.

[0020] The node with reputation score in [B, C) is classified as a good node. This node has voting rights, edit request rights, but no editing rights;

[0021] Nodes with a reputation score in the range of [C, 100] are classified as excellent nodes, which have the right to vote, the right to edit requests, and the right to edit;

[0022] Among them, A, B, and C are all positive integers.

[0023] Furthermore, the reputation score update rule includes: classifying user behaviors into different user behavior categories and setting corresponding feedback values, where the feedback value is positive or negative;

[0024] Among them, user behavior categories are mainly divided into two major categories: the first category is malicious behavior, and the corresponding reputation score adjustment value is negative; the second category is good behavior, and the corresponding reputation score adjustment value is positive;

[0025] It is set that the absolute value of the reputation score adjustment value when the user behavior category belongs to malicious behavior is greater than the absolute value of the reputation score adjustment value when the user behavior category belongs to good behavior.

[0026] Furthermore, in the edit request stage, the leader will also send the verification result of the edit request permission to the supervisor, and the supervisor will update the user's reputation score according to the reputation score update rule.

[0027] Furthermore, the leader generates a new random string , a sub-trapdoor and a witness based on a triple composed of the hash value of the block , the original message , and a random string , the new message and the main trapdoor , including:

[0028] Generating the root hash value of the new block hash tree , where the leaf nodes are, from left to right, two random numbers generated by the random number generator , , the hash value and the identity identifier of the leader ; calculating the signatures and according to equations (3) and (4), outputting the new random string , the sub-trapdoor and the witness , and then broadcasting ;

[0029] (3);

[0030] (4);

[0031] Among them, is the identity identifier of the block producer, is the root hash value of the block hash tree M, is the second part in the random string r, and are the random numbers generated when constructing the leader's public key and the main trapdoor; witness From the trapdoor New random string Among them is the first part in the random string r, are the two random numbers generated when the block is produced, represents the concatenation of two bit strings.

[0032] Further, the leader distributes the sub-key of the subordinate trapdoor to each user; after receiving the sub-key of the subordinate trapdoor, the user verifies the distribution process of the sub-key of the subordinate trapdoor and obtains the sub-key of the subordinate trapdoor through decryption And construct the corresponding proof including:

[0033] 5-1) The leader distributes the sub-key of the subordinate trapdoor to each user:

[0034] The leader selects an integer Among them mapping of is an integer group of order q, let the subordinate trapdoor key ; Select a polynomial of degree Among them t is the minimum number of users required to recover the subordinate trapdoor, t ≤ n; calculate the coefficient commitment value is the multiplicative cyclic group in mutually independent generators; encrypt the sub-key, the encrypted sub-key of the i-th user n is the total number of users to whom the sub-key of the subordinate trapdoor is to be distributed, is the public key of the i-th user, is a polynomial of degree ;

[0035] For each the leader randomly selects a number and calculates the following formula:

[0036] (5);

[0037] Use , , , to calculate the common value c1:

[0038] (6);

[0039] wherein, represents the concatenation of two bit strings; is a hash mapping from to ;

[0040] Calculate the response to each user , i = 1, 2,..., n, and generate a proof of the distribution process ;

[0041] Output the encrypted sub - key , the coefficient commitment value , and the proof , and broadcast them to the chain;

[0042] 5 - 2) The user verifies the trapdoor sub - key distribution process:

[0043] Calculate the intermediate parameter:

[0044] (7);

[0045] Verify the common value: Verify whether the following formula holds. If it holds, the trapdoor sub - key distribution is successful; otherwise, the distribution fails and the distribution is redone:

[0046] (8);

[0047] 5 - 3) The user performs trapdoor sub - key decryption:

[0048] Using the i - th user's encrypted sub - key received by the user, the user's public key and the user's private key as inputs, calculate the following formula:

[0049] (9);

[0050] where S i is the decrypted sub - key of the i - th user, and the user's public - private key pair satisfies ;

[0051] Randomly select a value , and calculate the following formula:

[0052] (10);

[0053] (11);

[0054] Generate the proof for the i-th user .

[0055] Furthermore, the editing request stage also includes: the leader obtains the user identity according to the editing request, obtains the user behavior category according to the verification result of the editing request authority, and hands the user behavior category and user identity to the supervisor for processing, and the supervisor updates the credit points according to the credit points update rules.

[0056] On the other hand, the present invention provides an editable blockchain system with dynamic editing rights, which implements the above-mentioned editable blockchain editing method with dynamic editing rights, including a leader, a user and a supervisor;

[0057] The leader, as the leader of the editing operation, is responsible for generating the master trapdoor and slave trapdoor of the Chameleon hash function, secretly sharing the slave trapdoor, saving the credit score list of all users, responding to the credit score query request of the user, counting the voting results and calculating the sum of random numbers;

[0058] The user is a user node in the blockchain network. According to their roles and behaviors in the blockchain editable system, they are divided into different node categories. Users of different node categories have different permissions and responsibilities in the system. All users have reputation points. According to the preset reputation point permission classification rules, the user's permissions are divided. Users vote for editing operations, initiate editing requests, and perform editing operations according to their corresponding permissions.

[0059] The supervisor maintains the user's reputation points and updates the corresponding user's reputation points according to the user's behavior category and preset reputation point update rules.

[0060] On the other hand, the present invention provides a computer-readable storage medium having a computer program stored thereon, characterized in that: when the computer program is executed by a processor, the steps of the above-mentioned method for editing an editable blockchain with dynamic editing rights are implemented.

[0061] In yet another aspect, the present invention provides a computer program product, comprising a computer program, which, when executed by a processor, implements the steps of the above-mentioned method for editing an editable blockchain with dynamic editing rights.

[0062] The beneficial effects of the editable blockchain editing method, system and device with dynamic editing rights of the present invention are as follows:

[0063] The editable blockchain editing method, system and device with dynamic editing rights of the present invention use a master-slave trapdoor method. The master trapdoor will not be shared with any other user. During the editing process, a slave trapdoor is generated according to a new message of the editing request, and then the secret of the slave trapdoor is shared. The editor performs editing operations according to the restored slave trapdoor. This method prevents the master trapdoor from being leaked, and users cannot modify data that has not undergone a legal editing process according to the slave trapdoor, which is beneficial to the security of on-chain data in the editable blockchain system.

[0064] The editable blockchain editing method, system and device with dynamic editing rights of the present invention introduces a reputation mechanism to dynamically maintain the user's reputation points, reward compliance operations and punish violations, ensure the security of the system and the standardization of user behavior, and ensure the stability of the entire system. Through the reputation point authority classification rules, users are given dynamic editing rights, editing request rights, and voting rights, which is beneficial to the data security of the editable blockchain system. BRIEF DESCRIPTION OF THE DRAWINGS

[0065] Figure 1 Schematic diagram of an editable system framework according to an embodiment of the present invention.

[0066] Figure 2 Schematic diagram of the reputation mechanism of an embodiment of the present invention.

[0067] Figure 3 It is a schematic diagram of the editing process of an embodiment of the present invention. DETAILED DESCRIPTION

[0068] The present invention is further described in detail below in conjunction with embodiments and with reference to the accompanying drawings.

[0069] One embodiment of the present invention is an editable blockchain system with dynamic editing rights, such as Figure 1 As shown, it includes leaders, users and supervisors.

[0070] In the blockchain editable system of the present invention, the leader, as the leader of the editing operation, is responsible for broadcasting the parameters required for the editing operation and distributing them to users, and is responsible for maintaining the security of the trapdoor. Specifically, the leader is responsible for generating the main trapdoor of the chameleon hash function ( ), from the trap door ( ), secret sharing from the trapdoor ( ), save the credit score list of all users, respond to the user's credit score query request, count the voting results and calculate the sum of random numbers.

[0071] User nodes in the blockchain network (hereinafter referred to as users) can be divided into different node categories according to their roles and behaviors in the blockchain editable system. Users of different node categories have different permissions and responsibilities in the system. Preferably, in the blockchain editable system of this embodiment, all users have reputation scores. According to the reputation score permission grading rules, the permissions of users are divided, and users can vote on edit operations, initiate edit requests, and execute edit operations according to the corresponding permissions.

[0072] The main task of the supervisor is to supervise and manage the behaviors of users. Specifically, the supervisor is responsible for maintaining the reputation score list and updating the reputation scores of the corresponding users in the reputation score list according to the behavior categories and reputation score update rules of the users, as Figure 2 shown.

[0073] The editable blockchain editing method with dynamic editing rights of the present invention, as Figure 3 shown, includes generating a main trapdoor, an edit request, voting, generating a sub-trapdoor, secret sharing, editing, and verification and maintenance.

[0074] I. Generating a main trapdoor.

[0075] The leader generates a set of public parameters , and calculates a signature key pair by using the public parameters, and then constructs the leader's public key and the main trapdoor .

[0076] Specifically, the leader selects the multiplicative cyclic groups and according to the security parameters of the editable block system, and have an order of , a generator of , sets the bilinear mapping , selects the hash functions and ( represents the unit group of order q), and the secure pseudorandom number generator , and outputs the public parameters ; generates three random numbers , where , and calculates ; generates the signature key pair by using the public parameters, and then constructs the leader's public key and the main trapdoor .

[0077] The leader's public key Can be used to verify the validity of the hash value. When the block is initially generated, according to the leader's public key , the message and the block producer identity , generate the hash value of the block and the random string . When the user node needs to verify the validity of the hash value, receive the leader's public key and the triple containing the hash value , the message and the random string as input, and verify the hash value of the block and the random string through the generative verification of the hash value.

[0078] Specifically, input the public key , the message and the block producer identity , and randomly generate two random numbers ; then calculate . is the root hash value of the block hash tree M, where the leaf nodes are, from left to right, the two random numbers generated by the random number generator , , the hash value and the block producer identity ; initially set , represents a placeholder, that is, is a null value. Calculate the hash value of the block and the random string according to the following formula:

[0079] (1);

[0080] (2);

[0081] where, represents the concatenation of two bit strings.

[0082] When it is necessary to verify the validity of the hash value, receive the leader's public key and the triple containing the hash value , the message and the random string as input, and verify whether the hash value of the block and the random string are valid by checking whether formula (1) holds. If formula (1) holds, the verification passes and 1 is output; otherwise, the verification fails and 0 is output.

[0083] II. Editing Request Phase.

[0084] When a user needs to edit data on the blockchain, the user first queries their reputation score from the leader to determine whether they have the right to initiate an editing request. The level of the reputation score determines the user's permissions. The corresponding user permissions for the reputation score are determined according to the preset reputation score permission grading rules to determine whether the user has the right to initiate an editing request. A user who has the right to initiate an editing request can package their identity , the original message , and the new message they hope to modify into an editing request package , and send it to the leader. The leader queries the reputation score of this user to verify whether the user has the editing request permission. If so, the leader broadcasts the editing request to other users in the system and enters the voting phase. Subsequently, the leader sends the verification result of the editing request permission to the supervisor, and the supervisor updates the reputation score list according to the reputation score update rules.

[0085] The specific steps are as follows:

[0086] 2-1) The user initiates a reputation score query request to the leader with their identity as a parameter. The leader queries the reputation score list and returns the reputation score of this user . After obtaining the reputation score, the user determines whether they have the permission to initiate an editing request according to the preset reputation score permission grading rules. A user who has the right to initiate an editing request generates an editing request , and sends it to the leader. The editing request includes the user's identity , the original message , and the new message they hope to modify into .

[0087] 2-2) After receiving the editing request initiated by the user, the leader queries the reputation score list to obtain the user's reputation score corresponding to the user's identity, and verifies whether the user who submitted the editing request has the editing request permission according to the preset reputation score permission grading rules. If the verification result of the editing request permission indicates that the user does not have the permission to initiate an editing request; if , it means that the user has the permission to initiate an editing request. If the user has the permission to initiate an editing request, the leader broadcasts the editing request to other users in the system and enters the voting phase.

[0088] Preferably, in another embodiment, the editing request stage further includes the leader obtaining the user identity identifier according to the editing request and obtaining the user behavior category according to the verification result of the editing request permission , and handing over the user behavior category and the user identity identifier to the supervisor for processing. The supervisor updates the user credit score in the credit score list according to the credit score update rule accordingly. The value range and explanations of the user behavior category are shown in Table 3 and the user identity identifier to the supervisor for processing. The supervisor updates the user credit score in the credit score list according to the credit score update rule accordingly. The value range and explanations of the user behavior category are shown in Table 3

[0089] For example, if the verification result of the editing request permission , then the user behavior category ; if the verification result of the editing request permission , then the user behavior category .

[0090] III. Voting stage

[0091] After receiving the editing request, other users in the system perform a self-check on the voting permission. If they have the voting permission, the user selects a random number for this vote , calculates a hash value for the editing request , and then uses the public key of the leader to encrypt the hash value and the random number as the encrypted voting information, and sends the encrypted voting information to the leader. After receiving the encrypted voting information, the leader performs a voting validity detection based on the user's credit score, that is, detects whether the user has the voting permission. Invalid votes, that is, votes cast by users without voting permission, will be discarded, and votes cast by users with voting permission are valid votes. The voting result formed by summarizing all valid votes is decrypted by the leader using his own private key. If more than a certain proportion (for example, more than half) of the users agree to the editing request, the voting result is considered to pass; otherwise, the editing process ends. Finally, calculate the sum of the random numbers in all valid votes .

[0092] The specific steps are as follows

[0093] 3-1) When other users in the system receive the editing request broadcast by the leader, they first query their own credit score from the leader according to their user identity identifier to determine whether they have the voting permission: other users in the system use their identity identifier as a parameter to initiate a credit score query request, and the leader returns the user's credit score by querying the credit score list ​After the user obtains the reputation points, it is determined whether the user has the voting right according to the reputation point permission grading rules.

[0094] 3-2) If the user has the voting right and agrees to the edit request, a random number for this vote of the user is selected , and the hash function is used according to the edit request to calculate the hash value . The user uses the public key of the leader to encrypt the hash value and the random number to generate the encrypted voting information , and send it to the leader.

[0095] After receiving the encrypted voting information of the voting user , the leader detects whether the user has the voting right according to the user's reputation points: the leader queries the reputation point list , obtains the user reputation points corresponding to the user identity identifier , and verifies whether the user has the voting right according to the reputation point permission grading rules. If the voting right verification result , that is, the user has the voting right, the vote is valid; if the voting right verification result , that is, the user does not have the voting right, the vote is invalid.

[0096] 3-3) For the valid encrypted voting information , the leader uses its own private key to decrypt it to obtain the voting result (agree or disagree), the plaintext hash value and the random number .

[0097] 3-4) The leader statistically analyzes all the decrypted voting results : The leader calculates the sum of the random numbers in all the encrypted voting information submitted by the voting users. If the voting users reaching the set ratio (such as more than half) agree to the edit request, the voting result is considered to pass.

[0098] IV. From the trapdoor generation stage.

[0099] If the voting result is passed, the leader is based on the triple composed of the hash value of the block, the original message and the random string , the new message and the main trapdoor , generate a new random string , from the trapdoor and the witness , and then broadcast . The leader broadcasts the newly generated parameters (the new random string and the witness ), which can ensure that all participants can receive and verify the validity of these trapdoor parameters through the witness , thus guaranteeing the integrity and consistency of the blockchain.

[0100] After receiving this information, the user uses the public key of the leader , the hash value of the block , the original message and the random string to form a triple, the newly received random string broadcast by the leader and the witness to perform a legality verification, that is, to verify the validity of the hash value of the block and check whether the witness is valid. After the verification result is counted and passed by the leader, the generation of the trapdoor is completed.

[0101] The specific steps are as follows:

[0102] 4-1) Generate the root hash value of the new hash tree of the block , where the leaf nodes are, from left to right, two random numbers generated by the random number generator , , , the hash value and the identity identifier of the leader . Calculate the signatures and according to equations (3) and (4), output the new random string , the trapdoor and the witness , and then broadcast .

[0103] (3);

[0104] (4);

[0105] Among them, is the identity identifier of the block producer, is the second part of the random string r, that is, the second parameter in equation (2), and are the random numbers generated when constructing the public key of the leader and the main trapdoor; the witness , from the trapdoor , a new random string , where is the first part in the random string r, , are two random numbers generated when the block is generated, represents the concatenation of two bit strings.

[0106] 4-2) After the user receives the new random string and the witness broadcast by the leader, verify the validity of the hash value of the block and check whether the witness wtx is valid:

[0107] According to the public key of the leader, the hash value of the block, the original message, and the received new random string , verify the validity of the hash value of the block, that is, verify whether equation (1) holds, where are used to replace respectively. If the equation holds, the hash value of the block is valid. Check whether the witness wtx is valid (check the signature in using the public key of the leader; check whether the hash value of the block in the witness is equal to the hash value of the block in the witness; check whether the root hash value in the witness is the root hash value of the hash tree and is equal to the root hash value in the new random string; check whether the new random string is equal to the identity identifier of the leader in the hash tree

[0108] ; if all are satisfied, output 1; otherwise output 0).

[0109] V. Secret sharing phase.

[0110] The leader distributes the sub-keys of the trapdoor to each user. After receiving the sub-keys of the trapdoor, the user needs to verify the distribution process of the sub-keys of the trapdoor and obtain the sub-keys of the trapdoor through decryption , and construct the corresponding proof .

[0111] Preferably, the reputation mechanism module tracks the operation behaviors of users during this process, including whether the verification and decryption steps are compliant, and adjusts the reputation scores of users according to these operations.

[0112] The specific steps are as follows:

[0113] 5-1) The leader distributes the sub-key of the trapdoor to each user:

[0114] The leader selects an integer , where is a mapping of , and is an integer group of order q. Let the trapdoor key be . Select a polynomial of degree , , and t is the minimum number of users required to recover the trapdoor, t ≤ n; calculate the coefficient commitment value , , is a multiplicative cyclic group independent of in the generator; encrypt the sub-key. The encrypted sub-key of the i-th user is , , n is the total number of users to whom the trapdoor sub-key is to be distributed, is the public key of the i-th user, is a polynomial of degree .

[0115] For each , the leader randomly selects a number , and calculates

[0116] (5);

[0117] Using , , , calculate the common value c1:

[0118] (6);

[0119] Among them, represents the concatenation of two bit strings. Unless otherwise specified in the following text, is the hash mapping from to .

[0120] Calculate the response to each user , for \(i = 1, 2, \ldots, n\), and generate a proof of the distribution process . It is a proof of integrity in secret sharing and encryption protocols, used to verify whether participants operate according to the rules when executing the protocol. It ensures that the data has not been tampered with and all steps have been correctly executed. It is a zero-knowledge proof to guarantee the security and reliability of the entire process.

[0121] Output the encrypted sub-key , the coefficient commitment value , and the proof , and broadcast them to the chain.

[0122] 5-2) The user verifies the trapdoor sub-key distribution process:

[0123] Calculate the intermediate parameter:

[0124] (7);

[0125] Verify the public value: Verify whether the following formula holds. If it holds, the trapdoor sub-key distribution is successful and output 1; otherwise, the distribution fails and output 0, and the distribution needs to be redone.

[0126] (8);

[0127] 5-3) The user performs trapdoor sub-key decryption:

[0128] Taking the encrypted sub-key of the \(i\)-th user received by the user , the public key of the user and the private key of the user as inputs, calculate the following formula:

[0129] (9);

[0130] where \(S\) i is the decrypted sub-key of the \(i\)-th user, and the public-private key pair of the user satisfies .

[0131] Randomly select a value , and calculate the following formula:

[0132] (10);

[0133] (11);

[0134] Generate the proof of the \(i\)-th user .

[0135] where It is a proof of integrity used to verify whether the user's operations in the protocol are correct and legal. It ensures that the user has performed the correct calculation steps and has not forged or tampered with the data. It is a form of zero-knowledge proof that guarantees the security and credibility of the protocol.

[0136] Output the decrypted sub-key of the i-th user and the corresponding proof 。

[0137] VI. Editing phase.

[0138] The user receives the sum of the random numbers broadcast by the leader and combines it with the user's own public key , and uses the hash function to calculate the user's own candidate editor hash value , and broadcasts it and the user's public key to the chain. The user receives the candidate editor hash values broadcast by other users, sorts them, and integrates them into an array. Each user then finds the candidate editor with editing rights and the smallest candidate editor hash value from all candidate editors, sends it to the leader for confirmation, and uses it as the editor for this editing request. Then the user sends the decrypted sub-key to the editor of this editing request.

[0139] The editor of this editing request then recovers the trapdoor key S and sends it to the leader. After passing the leader's verification, it obtains the trapdoor tk. Then, according to the trapdoor it calculates the final random string corresponding to the new message , performs data editing to ensure that the data update in the blockchain is consistent with the hash value.

[0140] The specific steps are as follows:

[0141] 6-1) The user finds the editor of this editing request.

[0142] The user receives the sum of the random numbers broadcast by the leader and the user's public key as inputs, uses the hash function to calculate the candidate editor hash value , and broadcasts it and the user's public key to the chain.

[0143] The user receives the candidate editor hash values broadcast by other users, sorts them, and integrates them into an array 。

[0144] Select the candidate with editing rights and the smallest hash value from all candidate editors as the editor of this editing request. The specific steps are: Find the smallest candidate editor hash value among , and obtain the corresponding user public key . Query the reputation score list, if the smallest candidate editor hash value If the corresponding user does not have the right to edit, the request will be deferred to the first user with the right to edit, who will be the editor of this edit request. Sent to the editor of this edit request.

[0145] 6-2) The editor of this editing request performs the recovery operation from the trapdoor key. The specific steps are:

[0146] At least Users The decrypted subkey is the input, where B is the serial number set of the collected decrypted subkeys, is the set of subkey serial numbers distributed by the leader, is the decrypted subkey of the ith user. The Lagrange interpolation function is used to calculate the trapdoor key , ,

[0147] in, , are the coefficients in the Lagrange interpolation polynomial.

[0148] 6-3) Calculation of new messages by editors The corresponding final random string :

[0149] The editor will recover the trapdoor key Submit to the leader. The leader verifies the equation Is it true? If true, the editor will send a trapdoor . The editor then uses the trapdoor , triple , News ,in , check whether the triple is valid, calculate , , ensuring hash consistency.

[0150] 7. Verification and maintenance phase.

[0151] Supervisors will verify the editing operations, including checking whether the data is consistent, whether the operation is compliant, etc. In this process, the reputation points of relevant users are updated according to the preset reputation point update rules based on the verification results to reward compliant operations and punish illegal behaviors, ensuring the security of the system and the standardization of user behavior.

[0152] Supervisors convert users' behaviors and contributions into reputation points according to the preset reputation points mechanism, and determine the user's authority in the editing process based on the points. Reputation points are calculated based on the user's edit request authority, edit authority, correctness of edits, and participation in voting. The dynamic adjustment of reputation points is achieved through reputation point update rules to ensure that users' behavior in the system complies with regulations and to punish or restrict violations.

[0153] The reputation mechanism of the present invention includes reputation score initialization, reputation score authority classification rules and reputation score update rules.

[0154] When the system is first built, the leader initializes the reputation points. Users can get the reputation value of any node by sending a request to the leader. When the user is editing, he or she queries the reputation points list and determines whether he or she has the permission for the current operation according to the user permission classification rules. Finally, the supervisor updates the reputation points of the user node according to the reputation points update rules.

[0155] The credit score initialization includes: the leader uses a preset random function to set the credit score of each node, sets the credit score of the node to a certain value within the set range, and generates a specific number for each node (for example, 1, 2, 3, ..., N, where N is the number of nodes in the cluster). When a user needs to query the credit score of a node, he can query the credit score of any node by sending a request to the leader.

[0156] The credit score permission classification rule is to divide the user's operation permissions according to the node's credit score. For example:

[0157] Nodes with a reputation score of [0, A) are classified as malicious nodes. They have no voting rights, no edit request rights, and no edit rights. Malicious nodes cannot participate in any part of the editing operation.

[0158] The node with reputation score at [A, B) is classified as a common node, which has voting rights, no edit request rights, and no edit rights. Common nodes can normally perform edit voting and provide sub-keys of sub-slave trapdoors during edit operations.

[0159] Nodes with reputation points in [B, C) are classified as good nodes. They have voting rights, edit request rights, and no edit rights. When there is an edit requirement in the system, a good node can initiate an edit request.

[0160] Nodes with reputation scores in the range of [C, 100] are classified as excellent nodes. These nodes have the right to vote, the right to request editing, and the right to edit. When there is an editing requirement in the system, the editor selects from the excellent nodes.

[0161] Among them, A, B, and C are all positive integers.

[0162] For example, referring to Table 1, set the initial reputation scores of the nodes in the range of (60, 100), and generate a specific serial number (1, 2, 3,..., N) for each node. Nodes with reputation scores in the interval [85, 100] are classified as excellent nodes, nodes with reputation scores in the interval [70, 85) are classified as good nodes, nodes with reputation scores in the interval [60, 70) are classified as ordinary nodes, and nodes with reputation scores below 60 are classified as malicious nodes.

[0163] Table 1 User Node Classification Table

[0164]

[0165] For the node category permission grading table, referring to Table 2, assign different permissions in the editing operation to nodes with different categories.

[0166] Table 2 Node Category Permission Grading Table

[0167]

[0168] Preferably, the reputation score update rule includes: classifying user behaviors into different user behavior categories category, and setting corresponding feedback values reward. The feedback value can be positive (reputation score encouragement value) or negative (reputation score penalty value).

[0169] As shown in Table 3, the user behavior category category is a three-digit integer digital code, and the reputation score adjustment value (reward or penalty value) reward corresponding to this category can be positive or negative, and can be an integer or a decimal. note is the explanation of the corresponding user behavior category.

[0170] Among them, user behaviors are mainly divided into two major categories: the first category is malicious behaviors, and the corresponding reputation score adjustment value reward is negative; the second category is good behaviors, and the corresponding reputation score adjustment value reward is positive.

[0171] Preferably, the reputation mechanism determines whether the user behavior category belongs to the first category or the second category by distinguishing the highest bit of the user behavior category "category". When the user behavior category belongs to malicious behavior, the absolute value of the reputation score adjustment value "reward" is generally set relatively large, and the punishment intensity of the reputation mechanism module for malicious behavior is very high; when the user behavior category belongs to good behavior, the absolute value of the reputation score adjustment value "reward" is generally relatively small, and users need to accumulate more good behaviors to maintain a relatively healthy reputation score. For example, in Table 3, when the highest bit of the user behavior category "category" is 3, it indicates malicious behavior, and the absolute value of the reputation score adjustment value "reward" is generally set relatively large, and the punishment intensity of the reputation mechanism module for malicious behavior is very high; when the user behavior category belongs to good behavior, the highest bit of the user behavior category "category" is 2, and the absolute value of the reputation score adjustment value "reward" is generally relatively small, and users need to accumulate more good behaviors to maintain a relatively healthy reputation score.

[0172] When a certain node has an illegal operation during the editing operation, the reputation score adjustment value of this node is deducted. The evaluation behavior of malicious nodes is that they have illegal operations many times during the editing operation so that the reputation score is reduced to the corresponding reputation score range of malicious nodes.

[0173] Table 3 Reputation Score Update Rule Table

[0174]

[0175] The supervisor verifies the editing operation and maintains the user node reputation score, which specifically includes the following steps:

[0176] 7-1) The supervisor verifies the legality of the editor's hash value.

[0177] In this operation, first, the hash values of users without editing permissions in the candidate editor hash value table are excluded, and then the remaining hash values are sorted to obtain a hash value array . Then, check whether the hash value of the selected editor is the minimum value. If so, the editing operation is legal, and the corresponding user behavior category (such as 202) of the legal editing operation is output; otherwise, the corresponding user behavior category (such as 302) of the illegal editing operation is output. The user identity identifier of the editor and the user behavior category will be used for subsequent reputation score maintenance.

[0178] 7-2) The supervisor verifies the hash consistency and the correctness of the sub-key.

[0179] The supervisor, according to the public key , two triples and , witness and evidence , verify the hash consistency and the sub - key correctness, and output the hash consistency verification result and the sub - key correctness verification result . Include:

[0180] Verify the hash consistency, and check the following four items:

[0181] Check whether the triple is valid, that is, use its parameters to replace the corresponding original parameters in formula (1). For example, use in to replace , to replace , and verify whether formula (1) holds;

[0182] Check whether the values of the two triples and are equal to the value in the witness ;

[0183] Check whether the witness is equal to , in ;

[0184] Check whether is equal to in .

[0185] If the above four items all pass, the hash consistency verification result is , that is, the hash consistency verification passes, otherwise it is , and the hash consistency verification fails.

[0186] Verify the correctness of the sub - key value by checking whether the following equation holds. If it holds, the sub - key correctness verification result is , that is, the sub - key value is correct, otherwise it is , that is, the sub - key value is incorrect.

[0187]

[0188] i is the parameter in the proof of the i - th user, is the public key of the i - th user, S i is the decrypted sub - key of the i - th user, Yi is the encrypted sub - key for the i - th user.

[0189] 7 - 3) The supervisor verifies the editing legality.

[0190] If the result of the sub - key correctness verification is , it indicates that the sub - key is incorrect. Output the corresponding user behavior category (e.g., 304), and the user identifier of the editor is the user identifier of the provider of the proof for the i - th user.

[0191] If the result of the sub - key correctness verification is while the result of the hash consistency verification is , it indicates that the sub - key is correct, but the hash consistency fails. Therefore, punish the editor, output the corresponding user behavior category (e.g., 303), and the user identifier of the editor is the user identifier of the editor.

[0192] If the result of the sub - key correctness verification and the result of the hash consistency verification are both , it indicates that the sub - key is correct and the hash consistency passes. Reward the editor and the sub - key provider, output the corresponding user behavior category (e.g., 204) and the user identifier of the editor.

[0193] 7 - 4) The supervisor updates the reputation score and sends it to the leader.

[0194] The supervisor maintains the reputation score list according to the user behavior category , the user number of the editor and the reputation score list , and generates a new reputation score list and sends it to the leader.

[0195] The editable blockchain editing method, system and device with dynamic editing rights of the present invention use the master - slave trapdoor method. The master trapdoor will not be shared with any other users. During the editing process, a slave trapdoor is generated according to the new message of the editing request, and then the secret sharing of the slave trapdoor is performed. The editor performs the editing operation according to the recovered slave trapdoor. This method prevents the master trapdoor from being leaked, and users cannot modify the data that has not passed through the legal editing process based on the slave trapdoor, which is beneficial to the security of the data on the chain in the editable blockchain system.

[0196] The editable blockchain editing method, system and device with dynamic editing rights of the present invention dynamically maintain the user's reputation points by introducing a reputation mechanism module, rewarding compliant operations and punishing illegal behaviors, ensuring the security of the system and the standardization of user behavior, and ensuring the stability of the entire system. Through the reputation points authority classification rules, users are given dynamic editing rights, editing request rights, and voting rights, which is beneficial to the data security of the editable blockchain system.

[0197] In some embodiments, certain aspects of the above-mentioned techniques may be implemented by one or more processors of a processing system executing software. The software includes one or more executable instruction sets stored or otherwise tangibly implemented on a non-transitory computer-readable storage medium. The software may include instructions and certain data that manipulate one or more processors to perform one or more aspects of the above-mentioned techniques when executed by one or more processors. Non-transitory computer-readable storage media may include, for example, magnetic or optical disk storage devices, solid-state storage devices such as flash memory, cache, random access memory (RAM), or other non-volatile memory devices. The executable instructions stored on the non-transitory computer-readable storage medium may be source code, assembly language code, object code, or other instruction formats interpreted or otherwise executed by one or more processors.

[0198] Computer-readable storage media may include any storage medium or combination of storage media that can be accessed by a computer system during use to provide instructions and / or data to the computer system. Such storage media may include, but are not limited to, optical media (e.g., compact disks (CDs), digital versatile disks (DVDs), Blu-ray disks), magnetic media (e.g., floppy disks, tapes, or magnetic hard drives), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or flash memory), or micro-electromechanical system (MEMS)-based storage media. Computer-readable storage media may be embedded in a computing system (e.g., system RAM or ROM), fixedly attached to a computing system (e.g., a magnetic hard drive), removably attached to a computing system (e.g., an optical disk or a universal serial bus (USB)-based flash memory), or coupled to a computer system via a wired or wireless network (e.g., network accessible storage (NAS)).

[0199] Note that not all activities or elements in the above general description are required, that a part of a particular activity or device may not be required, and that one or more further activities or elements may be performed or included in addition to those described. Further, the order in which the activities are listed need not be the order in which they are performed. Also, these concepts have been described with reference to specific embodiments. However, those of ordinary skill in the art will recognize that various modifications and changes can be made without departing from the scope of the disclosure set forth in the following claims. Accordingly, the specification and drawings are to be regarded as illustrative rather than restrictive, and all such modifications are included within the scope of the disclosure.

[0200] Benefits, other advantages, and solutions to problems have been described above with respect to specific embodiments. However, no benefit, advantage, solution to problems, or any feature that may cause any benefit, advantage, or solution to occur or become more pronounced should be construed as a critical, required, or essential feature of any or all the claims. In addition, the particular embodiments disclosed above are merely illustrative, as the disclosed subject matter may be modified and practiced in different but equivalent manners apparent to those skilled in the art that benefit from the teachings here. No intention is made to limit the details of the construction or design shown herein other than as described in the claims. It is, therefore, evident that the particular embodiments disclosed above may be altered or modified, and all such variations are considered within the scope of the disclosed subject matter.

Claims

1. An editable blockchain editing method with dynamic editing rights, characterized in that, include: Main trapdoor generation phase: The leader selects a multiplicative cyclic group according to the security parameters of the editable block system and , and whose order is , with the generator being , sets the bilinear mapping , selects the hash functions and , represents the multiplicative group of order , and the secure pseudorandom number generator , outputs the public parameters ; generates three random numbers , where , and calculates ; uses the public parameters to generate the signature key pair , then constructs the leader's public key and the main trapdoor ; Edit Request Phase: When a user needs to edit data on the blockchain, the user first queries their reputation score from the leader, determines the corresponding user permissions according to the preset reputation score permission grading rules to determine whether they have the right to initiate an edit request. The user who has the right to initiate an edit request will use their identity identifier , the original message , and the new message that they hope to modify into to package and generate an edit request, and send it to the leader; the leader queries the user's reputation score to verify whether the user has the permission to initiate an edit request. If so, the leader broadcasts the edit request to other users in the system, and enters the voting phase; Voting stage: After other users in the system receive an editing request, they perform a self-check on their voting permissions. If they have voting permissions, a random number for this vote is selected for the user , and a hash function is used for the editing request to calculate a hash value . Then, the public key of the leader is used to encrypt the hash value and the random number as encrypted voting information and sent to the leader. After receiving the encrypted voting information, the leader checks whether the user has voting permissions based on the user's reputation score. Votes cast by users without voting permissions will be discarded, and votes cast by users with voting permissions are valid votes. The voting result formed by aggregating all valid votes is decrypted by the leader using the leader's private key. If a set proportion of users agree to the editing request, the voting result is considered to have passed; otherwise, this process ends. Calculate the sum of the random numbers in all valid votes ; From the trapdoor generation stage: If the voting result is passed, the leader generates a new random string , the original message , and the random string -composed triple, the new message , and the main trapdoor , generates a new random string , the subordinate trapdoor , and the witness . Then, the generated new random string , and the witness are broadcast. After receiving them, the user uses the leader's public key , the hash value of the block , the original message , and the random string -composed triple, the received new random string , and the witness to verify the validity of the hash value of the block and check whether the witness is valid. After the verification result is counted and passed by the leader, the subordinate trapdoor generation is completed. Secret sharing phase: The leader distributes the sub - secret keys of the trapdoor to each user; after receiving the sub - secret keys of the trapdoor, the user verifies the sub - secret key distribution process of the trapdoor and obtains the sub - secret key of the trapdoor through decryption , and constructs the corresponding proof ; Editing stage: The user receives the sum of the random numbers broadcast by the leader , and combines it with the user's own public key , calculates the user's own candidate editor hash value, and broadcasts it and the user's public key to the chain; the user receives the candidate editor hash values of other users broadcast by other users, sorts them, and integrates them into an array; Each user then finds the candidate editor with editing rights and the smallest candidate editor hash value from all candidate editors, sends it to the leader for confirmation, and uses it as the editor for this editing request. Then the user sends the decrypted sub-key to the editor of this editing request; the editor of this editing request then recovers the trapdoor key and sends it to the leader. After passing the verification by the leader, the editor obtains the trapdoor ; Then, based on the trapdoor calculate the new message corresponding to the final random string , and perform data editing; Verification and maintenance reputation stage: Supervisors verify the editing operations. During this process, the reputation points of relevant users are updated according to the preset reputation point update rules based on the verification results to reward compliant operations and punish violations.

2. The editable blockchain editing method with dynamic editing rights according to claim 1, characterized in that, The credit points authority classification rules are as follows: Nodes with a reputation score of [0, A) are classified as malicious nodes, and have no voting rights, no edit request rights, and no edit rights; The node with reputation points at [A, B) is classified as a common node. This node has voting rights, but no edit request rights and no edit rights. The node with reputation score in [B, C) is classified as a good node, which has voting rights, edit request rights, but no editing rights; Nodes with a reputation score of [C, 100] are classified as excellent nodes, and have voting rights, edit request rights, and edit rights; Among them, A, B, and C are all positive integers.

3. The editable blockchain editing method with dynamic editing rights according to claim 1, wherein The credit score update rule includes: classifying user behaviors into different user behavior categories and setting corresponding feedback values, which are positive or negative; Among them, user behavior categories are mainly divided into two categories: the first category is malicious behavior, and its corresponding credit score adjustment value is negative; the second category is good behavior, and its corresponding credit score adjustment value is positive; The absolute value of the credit score adjustment value corresponding to a malicious behavior is set to be greater than the absolute value of the credit score adjustment value corresponding to a good behavior.

4. The editable blockchain editing method with dynamic editing rights according to claim 3, characterized in that, The editing request stage also includes the leader sending the verification result according to the editing request authority to the supervisor, and the supervisor updating the user's reputation points according to the reputation point update rule.

5. The editable blockchain editing method with dynamic editing rights according to claim 1, characterized in that, The said leader, based on the triple composed of the hash value of the block , the original message and the random string , the new message and the main trapdoor , generates a new random string , a subordinate trapdoor and a witness , including: Generate a new hash tree for the block of the root hash value , where the leaf nodes are, from left to right, two random numbers generated by a random number generator ; the hash value and , and the identity identifier of the leader ; calculate the signatures and and according to equations (3) and (4), output a new random string , from the trapdoor and the witness , and then broadcast ; （3）； （4）； Among them, is the identity identifier of the block producer, is the root hash value of the block hash tree M, is the second part of the random string r, and are random numbers generated when constructing the leader public key and the main trapdoor; witness , from the trapdoor , the new random string , where is the first part of the random string r, , are two random numbers generated when the block is produced, represents the concatenation of two bit strings.

6. The editable blockchain editing method with dynamic editing rights according to claim 5, characterized in that The leader distributes the sub-key of the trapdoor to each user; after receiving the sub-key of the trapdoor, the user verifies the distribution process of the sub-key of the trapdoor and obtains the sub-key of the trapdoor through decryption. , and constructs a corresponding proof , including: 5-1) The leader will distribute the subkeys from the trapdoor to each user: The leader selects an integer , where is a mapping of which is an integer group of order q. Let the trapdoor key be ; select a polynomial of degree , where , , and t is the minimum number of users required to recover the trapdoor, t ≤ n; calculate the coefficient commitment values , , is a multiplicative cyclic group in which is an independent generator; encrypt the sub-keys. The encrypted sub-key for the i-th user is , , n is the total number of users to whom the trapdoor sub-keys are to be distributed, is the public key of the i-th user, is a polynomial of degree .​ For each , the leader randomly selects a number , and calculates the following formula: （5）； Utilize , , , to calculate the common value c1: （6）； Among them, represents the concatenation of two bit strings; is from to is a hash mapping; Calculate the response for each user , where i = 1, 2, ..., n, and generate a proof of the distribution process ; Output encrypted sub-key , coefficient commitment value , and proof , and broadcast them to the chain; 5-2) User verification of the subkey distribution process from the trapdoor: Calculate the intermediate parameters: （7）； Verify the public value: Verify whether the following formula is true. If so, the distribution from the trapdoor subkey is successful; otherwise, the distribution fails and redistribution is performed: （8）； 5-3) User performs decryption from the trapdoor subkey: Taking the encrypted sub-key of the i-th user received by the user , the public key of the user and the private key of the user as inputs, calculate the following formula: （9）； Among them, S i is the decrypted sub-key of the i-th user, and the public-private key pair of the user satisfies ; Randomly select a value , and calculate the following formula: （10）； （11）； Generate the proof for the i-th user .

7. The editable blockchain editing method with dynamic editing rights according to claim 1, characterized in that The editing request stage also includes: the leader obtains the user identity according to the editing request, obtains the user behavior category according to the verification result of the editing request authority, and hands the user behavior category and user identity to the supervisor for processing. The supervisor updates the credit points according to the credit points update rules.

8. An editable blockchain system with dynamic editing rights, implementing the editable blockchain editing method with dynamic editing rights as described in any one of claims 1-7, characterized in that, Includes leaders, users, and supervisors; The leader, as the leader of the editing operation, is responsible for generating the master trapdoor and slave trapdoor of the Chameleon hash function, secretly sharing the slave trapdoor, saving the credit score list of all users, responding to the credit score query request of the user, counting the voting results and calculating the sum of random numbers; The user is a user node in the blockchain network, and is divided into different node categories according to its role and behavior in the blockchain editable system. Users of different node categories have different permissions and responsibilities in the system; All users have credit points. According to the preset credit point authority classification rules, the user's authority is divided. Users vote on editing operations, initiate editing requests, and perform editing operations according to their corresponding authority. The supervisor maintains the credit scores of users and updates the corresponding users' credit scores according to the behavior categories of the users and the preset credit score update rules.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, it implements the steps of the editable blockchain editing method with dynamic editing rights as described in any one of claims 1-7.

10. A computer program product, comprising a computer program, characterized in that: When the computer program is executed by a processor, it implements the steps of the editable blockchain editing method with dynamic editing rights as described in any one of claims 1-7.

Images