A blockchain editing method and system based on cross-chain consensus and a storage medium

Abstract

This invention discloses a blockchain editing method, system, and storage medium based on cross-chain consensus, relating to the field of blockchain technology. The method includes: transmitting an editing proposal submitted by any participant in a first chain to other participants; in response to the received editing proposal, other participants conduct a cross-chain vote on the editing proposal, and a verification institution records the cross-chain voting results; the verification institution verifies the cross-chain voting results and grants editing permissions to a cross-chain management institution based on the cross-chain voting results; in response to the granted editing permissions, the cross-chain management institution edits the target block to obtain the editing result; the cross-chain management institution synchronizes the editing result to all participants; and in response to the editing result, all participants confirm the editing result. Compared to existing technologies, this invention designs a cross-chain protocol with an editability mechanism to ensure that all participants reach consensus on the edited block, maintaining the consistency and stability of the cross-chain network.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and more specifically, to a blockchain editing method, system, and storage medium based on cross-chain consensus. Background Technology

[0002] One of the key features of blockchain is its uneditability, which makes it a valuable transfer network that is being widely used in finance, the internet, logistics, and other fields, such as digital currency wallet address management, transaction information supervision, and digital bill transaction supervision.

[0003] However, as blockchain applications become more widespread, its "uneditability" brings some significant problems. These include legal risks associated with malicious activity within the blockchain, the prohibition against human error, and conflicts with the "right to be forgotten." Consider the following scenario: any illegal content embedded in a blockchain block can never be removed. Such data carries legal risks and creates regulatory obstacles for authorities. Furthermore, the "uneditability" characteristic makes human error intolerable, especially in the financial sector. Financial data recording largely relies on human intervention, and human error is unavoidable. Once an error occurs, it can never be corrected, resulting in extremely high costs associated with mistakes.

[0004] Although blockchain technology has been widely used in various fields, the immutability of traditional blockchains makes it impossible to modify the recorded blocks, which limits its application scenarios. Summary of the Invention

[0005] To overcome the problems of limited application and poor fault tolerance caused by the inability to modify blockchains as described in the prior art, this invention provides a blockchain editing method, system, and storage medium based on cross-chain consensus.

[0006] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0007] Firstly, a blockchain editing method based on cross-chain consensus includes:

[0008] An edit proposal submitted by any participant in the first chain is transmitted to other participants in the first and second chains; wherein cross-chain data exchange occurs between the first and second chains, and the edit proposal includes an index of the target block;

[0009] In response to the received edit proposal, other participants vote on the edit proposal across the chain, and the verification agency records the cross-chain voting results;

[0010] The verification body verifies the legality of the cross-chain voting results and grants the cross-chain management body editing permissions based on the cross-chain voting results;

[0011] In response to the granted editing permission, the cross-chain management authority edits the target block according to the index to obtain the editing result;

[0012] Based on the cross-chain consensus mechanism, the cross-chain management organization will synchronize the editing results to all participating parties;

[0013] In response to the edit result, all participating parties confirm the edit result.

[0014] Secondly, an editable blockchain system based on cross-chain consensus, applying the method described in the first aspect, includes:

[0015] The participants are used to propose edit proposals and transmit them to other participants in the first and second chains; they are also used to vote on the edit proposals across chains; and they are also used to confirm the edit results; cross-chain data exchange is performed between the first and second chains, and the edit proposals include the index of the target block;

[0016] Verification body, used to record cross-chain voting results, verify the legality of the cross-chain voting results, and grant editing permissions to the cross-chain management body based on the cross-chain voting results;

[0017] A cross-chain management body is configured to edit the target block according to the index in response to the granted editing permission; and to synchronize the editing results to all participants based on a cross-chain consensus mechanism.

[0018] Thirdly, a computer-readable storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, at least one program, code set, or instruction set is loaded and executed by a processor to implement the method described in the first aspect.

[0019] Compared with the prior art, the beneficial effects of the technical solution of the present invention are:

[0020] This invention discloses a blockchain editing method, system, and storage medium based on cross-chain consensus. The method allows cross-chain participants (i.e., participating nodes) to freely choose the content to be edited and the timing of the edit according to actual needs. This flexible editability enables the blockchain to adapt to different cross-chain application scenarios and business requirements, and improves fault tolerance. Simultaneously, to ensure the security of this editability, this invention allows all participants to jointly vote on the editing proposal across chains, with a trusted third party (i.e., a verification institution) recording and verifying the legality of the cross-chain voting results. This ensures the security and correctness of blockchain data while enabling blockchain participants to reach consensus in a short time, significantly improving the speed and efficiency of cross-chain interaction. Furthermore, this invention further ensures the security and integrity of data during cross-chain transmission by having all participants confirm the editing results. Compared to existing technologies, this invention designs a cross-chain protocol with an editability mechanism, ensuring that all participating blockchains reach consensus on the edited block, maintaining the consistency and stability of the entire cross-chain network. Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating the blockchain editing method described in Embodiment 1 of the present invention;

[0022] Figure 2 This is a schematic diagram illustrating the principle of the Sharmit sharing method in Embodiment 1 of the present invention;

[0023] Figure 3 This is a flowchart illustrating the process of participants confirming editing results in Embodiment 1 of the present invention;

[0024] Figure 4 This is a schematic diagram of the editable blockchain system in Embodiment 2 of the present invention. Detailed Implementation

[0025] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0026] To facilitate implementation of this invention by those skilled in the art, the basic blockchain model is described as follows:

[0027] Assume blockchain C NIt is a single chain consisting of consecutively connected blocks, where N is the height of the latest block, and the C1 block, which contains only the genesis block, has a height of 1; each block is denoted as a triple B. i = i x i ,ctr i >, i∈[0,N], B0 and B N These are the genesis block and the latest block, respectively; in the triple, s i ∈{0,1} K It is the hash value of the previous block, x i ∈{0,1} * It is data of arbitrary length, ctr i ∈N is a random number Nonce generated during the current block consensus process.

[0028] Therefore, the relevant data in the next block and this block satisfy S. N+1 =H(ctr) N , G(s N x N ), where H: {0, 1} * →{0,1} K and G: {0, 1} * →{0,1} K Here are K-bit collision-resistant hash functions, namely the outer hash function and the inner hash function;

[0029] To ensure the validity and integrity of a blockchain, the following two equations must hold true:

[0030]

[0031] s i+1 =H(ctr) i , G(s i x i ))

[0032] Wherein, parameter D∈N is the difficulty of the current blockchain, and q is the maximum number of hash requests allowed in each round of consensus.

[0033] The accompanying drawings are for illustrative purposes only and should not be construed as limiting the scope of this patent.

[0034] To better illustrate this embodiment, some parts in the accompanying drawings may be omitted, enlarged, or reduced, and do not represent the actual product dimensions; the same or similar reference numerals correspond to the same or similar parts;

[0035] It will be understood by those skilled in the art that certain well-known structures and their descriptions may be omitted in the accompanying drawings.

[0036] ​The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0037] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0038] Example 1

[0039] This embodiment proposes a blockchain editing method based on cross-chain consensus. (See attached document.) Figure 1 ,include:

[0040] An edit proposal submitted by any participant in the first chain is transmitted to other participants in the first and second chains; wherein cross-chain data exchange occurs between the first and second chains, and the edit proposal includes an index of the target block;

[0041] In response to the received edit proposal, other participants vote on the edit proposal across the chain, and the verification agency records the cross-chain voting results;

[0042] The verification body verifies the legality of the cross-chain voting results and grants the cross-chain management body editing permissions based on the cross-chain voting results;

[0043] In response to the granted editing permission, the cross-chain management authority edits the target block according to the index to obtain the editing result;

[0044] Based on the cross-chain consensus mechanism, the cross-chain management organization will synchronize the editing results to all participating parties;

[0045] In response to the edit result, all participating parties confirm the edit result.

[0046] This embodiment designs a flexible, editable cross-chain protocol, allowing cross-chain participants to freely choose the content and timing of block editing according to actual needs. This overcomes the limitation of application scenarios caused by the non-editability of blockchains and improves fault tolerance. Simultaneously, this embodiment enables all participants to jointly vote on editing proposals across-chain, with a trusted third party (i.e., a verification authority) recording and verifying the legality of the voting results. This allows for efficient and rapid consensus-building, significantly improving the speed and efficiency of cross-chain interaction while ensuring data security and accuracy. Furthermore, the confirmation of the editing results (i.e., the synchronized blocks) by all participants maintains the consistency and stability of the entire cross-chain network.

[0047] Those skilled in the art should understand that using a cross-chain consensus mechanism for synchronization can ensure data consistency.

[0048] It should be noted that the target block can be a block on the first chain or a block on the second chain. This means that participants on the first chain can propose edit proposals for blocks on the first chain or blocks on the second chain.

[0049] In some examples, the cross-chain management body is a consortium body.

[0050] In a preferred embodiment, transmitting the edit proposal submitted by any participant in the first chain to other participants in the first and second chains specifically involves the participant submitting the edit proposal broadcasting the edit proposal as a tuple P = (i, m, r) to the other participants; where i represents the index, m represents the content to be modified, and r represents the reason for editing.

[0051] In some examples, the pseudocode representation is as follows:

[0052]

[0053] In a preferred embodiment, the verification authority verifies the legality of the cross-chain voting result by:

[0054] When the number of cross-chain voting results reaches a preset threshold or a first preset ratio, the verification agency verifies the identity of the participant corresponding to the cross-chain voting result based on a public key encryption method: if the identity verification is successful, the corresponding cross-chain voting result is considered valid; otherwise, the corresponding cross-chain voting result is considered invalid, and the record of the cross-chain voting result is revoked.

[0055] In some examples, the set of attitudes of participants toward the edit proposal is represented as V = {v1, v2, ..., vn}, where vn represents the attitude of the nth participant. The function Verify(·) represents the authentication operation, and is represented in pseudocode as follows:

[0056]

[0057] As a non-limiting example, authentication based on public-key cryptography includes key generation (G), signing (S), and signature verification (U); where,

[0058] (1) Key generation: Use a random number r∈N as a security parameter, with an input of 1. r Output the public key pk and the private key sk, expressed by the following formula:

[0059] (pk,sk)←G(1 r )

[0060] (2) Signature: Using the private key sk and the message m as input, the output is the signature t.

[0061] t←S(sk,m)

[0062] (3) Identity Signature Verification: Using message m, public key pk, and signature t as input, if t is the signature of m, output D = 0; otherwise, output D = 1. The formula is as follows:

[0063] D←U(pk,m,t)

[0064] Those skilled in the art should understand that D=0 indicates successful authentication and D=1 indicates unsuccessful authentication.

[0065] It should be noted that the first preset ratio is the proportion of the expected number of received cross-chain voting results to the total number of participants. The expected number can be set by those skilled in the art based on the actual situation.

[0066] In one optional embodiment, the cross-chain voting result includes the attitude of the nth participant towards the edit proposal; granting editing permissions to the cross-chain management authority based on the cross-chain voting result specifically involves:

[0067] The verification agency counts the legitimate cross-chain voting results and determines whether the number of cross-chain voting results with the attitude of "agree" reaches or exceeds a preset threshold: if so, the trap key of the cross-chain management agency is restored, indicating that the cross-chain management agency has editing permissions; otherwise, no operation is performed.

[0068] In some examples, the attitude is described as "for" or "against";

[0069] In other examples, the attitude is described as "for", "against", or "abstain".

[0070] In some examples, a threshold value T is set so that when the number of votes in favor exceeds T, the condition for restoring the threshold key is met.

[0071] The function RecoverKey(V,T) represents the recovery threshold key verification operation, and its pseudocode is as follows:

[0072]

[0073] Those skilled in the art should understand that once the cross-chain management authority has its threshold key restored, it gains editing privileges.

[0074] It should be noted that this optional embodiment adopts a secret sharing mechanism, which is conducive to quickly reaching a consensus and distributing confidential information (i.e., threshold key) to a group of entities (N participants). When any k participants among the N participants agree to restore the confidential information, and k≥T, the confidential information (i.e., restore the threshold key) can be reconstructed.

[0075] In some examples, the Sharmir sharing method, including the secret distribution algorithm and the secret recovery algorithm, is used in the cross-chain voting process. See [link / reference]. Figure 2 :

[0076] (1) Secret distribution algorithm Share(tk)=(τ1,τ2,…,τ N Given a threshold key tk, randomly generate N sub-shares (τ1, τ2, ..., τk). N );

[0077] (2) Secret recovery algorithm Rec(τ1,τ2,...,τ) N )=tk∨⊥:Given k subshares belonging to (τ1,τ2,…,τ N ), recover the threshold key tk or return an abnormal value ⊥;

[0078] Those skilled in the art should understand that the threshold value needs to satisfy T≤N.

[0079] In a preferred embodiment, the cross-chain consensus mechanism includes at least one of the following: Byzantine fault tolerance algorithm, sidechain / relay-based synchronization mechanism, Paxos algorithm, and Raft algorithm.

[0080] In a preferred embodiment, a parameter adaptation mechanism is introduced into the method, including:

[0081] Node monitoring: Each node periodically monitors its own network load, latency, transaction volume, etc.; the node can be any participant in the first chain or the second chain, a verification agency or a cross-chain management agency;

[0082] Data transmission: Nodes share monitoring data through message passing;

[0083] Performance metrics calculation: Performance metrics are calculated using collected data, and the performance metrics include at least one of transaction confirmation time, throughput, and network latency;

[0084] An adaptive algorithm is constructed to predict the optimal configuration of consensus parameters and verification rules under different loads based on current performance metrics and historical data; the adaptive algorithm is obtained based on preset rules or machine learning.

[0085] Based on the results of the adaptive algorithm, determine the parameter adjustment strategy;

[0086] The stringency of the verification rules is dynamically adjusted based on the current network load and performance requirements.

[0087] In response to the parameter adjustment strategy, each node updates its consensus parameters and verification rules;

[0088] After each node completes the update, continue to monitor performance metrics to determine if performance has improved: if performance has improved, maintain the current parameter configuration; otherwise, adjust the parameter configuration.

[0089] This preferred embodiment introduces a parameter adaptive mechanism, which can automatically adjust consensus parameters and verification rules according to different network loads and security requirements, thereby improving the adaptability and robustness of the protocol and enabling it to perform well in different environments.

[0090] In some examples, the adaptive algorithm is constructed as follows:

[0091] S1. Data Acquisition: Collect historical data from multiple time points, including transaction volume, confirmation time, and network latency;

[0092] S2. Feature Engineering: Assuming the dataset contains m samples (time points), for each sample i, construct a feature vector x(i) = [number of transactions (i), confirmation time (i), network latency (i)]T;

[0093] S3. Model Training: For each sample i, there is an actual confirmation time y(i);

[0094] A linear regression model is established with the goal of predicting the confirmation time. Its expression is: y(i)=θ0+θ1*number of transactions(i)+θ2*confirmation time(i)+θ3*network latency(i)+ε(i);

[0095] Where θ0, θ1, θ2, θ3 are the parameters of the linear regression, and ε(i) is the error term;

[0096] The model parameters θ = [θ0, θ1, θ2, θ3]T are estimated by minimizing the squared error;

[0097] Minimize objective: J(θ)=(1 / 2m)*Σ(y(i)-θT*x(i))2, for i=1 to m.

[0098] In some examples, determining the parameter adjustment strategy in response to the result of the adaptive algorithm includes:

[0099] S4. Model Prediction:

[0100] Suppose we have a new sample xnew, which includes the number of transactions new, the confirmation time new, and the network latency new;

[0101] Using the trained model parameters, predict the confirmation time: ypred = θT * xnew;

[0102] S5, Adaptive Adjustment

[0103] The predicted confirmation time ypred is used as the adaptive result. Based on the predicted confirmation time, parameters (such as consensus rounds) are adjusted to achieve the predicted confirmation time.

[0104] In some examples, the parameter adjustment strategies include, but are not limited to, high-load strategies, low-load strategies, network latency strategies, and dynamic adjustment magnitude strategies; wherein,

[0105] High load strategy: If the load index is higher than the preset threshold A, the basic confirmation time will be shortened; and / or the confirmation time will be reduced by a percentage based on the current confirmation time and the adjustment coefficient.

[0106] Low load strategy: If the load index is lower than the preset threshold B, the basic confirmation time will be extended; and / or the confirmation time will be increased by a percentage based on the current confirmation time and the adjustment coefficient.

[0107] Network latency strategy: If the network latency exceeds the preset threshold C, the confirmation time will be adjusted according to the latency. It should be understood that higher latency may require a longer confirmation time to ensure the security of the transaction.

[0108] Dynamic scaling strategy: Adjust the scaling factor according to the change in the load index to avoid overly aggressive parameter changes.

[0109] In a preferred embodiment, the method further includes: employing cryptographic methods to ensure the confidentiality and integrity of the communication process.

[0110] In some examples, the cryptographic methods include, but are not limited to, DES (Data Encryption Standard), 3DES (Triple DES), AES (Advanced Encryption Standard), TDEA (Triple Data Encryption Algorithm), Blowfish, and RC2.

[0111] In a preferred embodiment, in response to the edit result, all the participating parties confirm the edit result, see [reference]. Figure 3 ,include:

[0112] The participating parties perform integrity verification, signature verification, consensus verification, and security protection verification on the editing results, and record the verification results; the verification results are either passed or failed.

[0113] Determine whether all verification results are passed: if yes, mark the edit result as valid; otherwise, mark the edit result as invalid.

[0114] In some examples, the integrity verification is implemented based on a hash function verification method, including but not limited to the Chameleon hash function.

[0115] In some examples, the signature verification includes:

[0116] Editor submission stage: The editor creates the edited data, generates a digital signature using their private key, and then submits the edited results, the original data, and the digital signature;

[0117] Extract Public Key: Extract the editor's public key from the submitted digital signature;

[0118] Obtain raw data: Retrieve the corresponding raw data from the blockchain for verification;

[0119] Verify signature: Using the editor's public key, the original data, and the digital signature, verify the validity of the digital signature: if the signature is valid, do not reject the editing operation; if invalid, reject the editing operation.

[0120] In other examples, the signature verification also includes additional security checks, such as checking the timestamp to ensure that the signature does not expire.

[0121] In some examples, the consensus verification includes:

[0122] Edit result broadcasting: The editor (i.e., the cross-chain management body) broadcasts the edit results to the entire network;

[0123] Node reception and verification: Other nodes receive the edit results and perform basic verification; if a node finds a problem with the edit results, it can temporarily reject the edit results;

[0124] Consensus mechanism: According to the rules of the consensus algorithm, nodes participate in the consensus process to decide whether to accept the edit result;

[0125] Block confirmation: Once enough nodes reach a consensus, the edit result is confirmed and included in the new block.

[0126] In some examples, the security verification includes code review and static analysis to find potential vulnerabilities;

[0127] In some examples, the security protection verification includes methods such as encryption, firewalls, and access control;

[0128] In some examples, the security verification includes performing security tests on the editing results, including but not limited to vulnerability scanning and penetration testing;

[0129] In some examples, the security verification includes dynamic analysis of the editing results, such as simulating malicious attacks in an isolated test environment, to assess the editing results' resistance to different attacks;

[0130] In some examples, the security verification includes establishing an isolated environment to isolate particularly sensitive editing operations in a secure environment and evaluating the results to prevent any potential risks;

[0131] In some examples, the security verification includes incorporating expert experience, with security experts conducting security audits to uncover potential unknown vulnerabilities and risks.

[0132] Example 2

[0133] This embodiment proposes an editable blockchain system based on cross-chain consensus, applying the method described in Embodiment 1, see [link / reference]. Figure 4 ,include:

[0134] The participants are used to propose edit proposals and transmit them to other participants in the first and second chains; they are also used to vote on the edit proposals across chains; and they are also used to confirm the edit results; cross-chain data exchange is performed between the first and second chains, and the edit proposals include the index of the target block;

[0135] Verification body, used to record cross-chain voting results, verify the legality of the cross-chain voting results, and grant editing permissions to the cross-chain management body based on the cross-chain voting results;

[0136] A cross-chain management body is configured to edit the target block according to the index in response to the granted editing permission; and to synchronize the editing results to all participants based on a cross-chain consensus mechanism.

[0137] In some examples, the participants are computing nodes on a blockchain network.

[0138] In some examples, the verification authority is a verification node on a blockchain network.

[0139] It is understood that the apparatus of this embodiment corresponds to the method of embodiment 1 above, and the options in embodiment 1 above are also applicable to this embodiment, so they will not be described again here.

[0140] Example 3

[0141] This embodiment proposes a computer-readable storage medium storing at least one instruction, at least one program, code set, or instruction set. The at least one instruction, at least one program, code set, or instruction set is loaded and executed by a processor to implement all or part of the steps of the method described in Embodiment 1.

[0142] It is understood that the storage medium can be transient or non-transient. Exemplarily, the storage medium includes, but is not limited to, USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks, and other media capable of storing program code.

[0143] In some examples, a computer program product is provided, which can be implemented by hardware, software, or a combination thereof. As a non-limiting example, the computer program product can be embodied in the storage medium, or it can be embodied in a software product, such as an SDK (Software Development Kit).

[0144] In some examples, a computer program is provided, including computer-readable code, wherein, when the computer-readable code is run in a computer device, a processor in the computer device performs some or all of the steps for implementing the method.

[0145] It is understood that the options in Embodiment 1 above also apply to this embodiment, so they will not be described again here.

[0146] The terms used to describe positional relationships in the accompanying drawings are for illustrative purposes only and should not be construed as limiting this patent.

[0147] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the present invention, and are not intended to limit the implementation of the present invention. It should be understood that in the various embodiments of this disclosure, the sequence number of each step / process does not imply the order of execution. The execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments. It should also be understood that the device embodiments described above are merely illustrative. For example, the division of units is merely a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components may be combined, or integrated into another system, or some features may be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms. For those skilled in the art, other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively describe all embodiments here. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the claims of the present invention.

Claims

1. A blockchain editing method based on cross-chain consensus, characterized in that, include: An edit proposal submitted by any participant in the first chain is transmitted to other participants in the first and second chains; wherein cross-chain data exchange occurs between the first and second chains, and the edit proposal includes an index of the target block; In response to the received edit proposal, other participants vote on the edit proposal across the chain, and the verification agency records the cross-chain voting results; The verification body verifies the legality of the cross-chain voting results and grants the cross-chain management body editing permissions based on the cross-chain voting results; In response to the granted editing permission, the cross-chain management authority edits the target block according to the index to obtain the editing result; Based on the cross-chain consensus mechanism, the cross-chain management organization will synchronize the editing results to all participating parties; In response to the edit result, all participating parties confirm the edit result; The verification mechanism verifies the legality of the cross-chain voting results, including: When the number of cross-chain voting results reaches a preset threshold or a first preset ratio, the verification agency verifies the identity of the participant corresponding to the cross-chain voting result based on a public key encryption method: if the identity verification is successful, the corresponding cross-chain voting result is considered valid; otherwise, the corresponding cross-chain voting result is considered invalid, and the record of the cross-chain voting result is revoked. The cross-chain voting results include the attitude of the nth participant towards the editing proposal; granting editing permissions to the cross-chain management organization based on the cross-chain voting results specifically involves: The verification agency counts the legitimate cross-chain voting results and determines whether the number of cross-chain voting results with the attitude of "agree" reaches or exceeds a preset threshold: if so, the trapdoor key of the cross-chain management agency is restored, indicating that the cross-chain management agency has editing permissions; otherwise, no operation is performed.

2. The blockchain editing method based on cross-chain consensus according to claim 1, characterized in that, The step of transmitting an edit proposal submitted by any participant in the first chain to other participants in the first and second chains specifically involves the participant submitting the edit proposal broadcasting the edit proposal as a tuple P=(i, m, r) to the other participants; where i represents the index, m represents the content to be modified, and r represents the reason for editing.

3. The blockchain editing method based on cross-chain consensus according to claim 2, characterized in that, The edit proposal is sent by the participating party that made the edit proposal to the cross-chain management authority, and then broadcast by the cross-chain management authority to the other participating parties.

4. The blockchain editing method based on cross-chain consensus according to claim 1, characterized in that, The cross-chain consensus mechanism includes at least one of the following: Byzantine fault tolerance algorithm, sidechain / relay synchronization mechanism, Paxos algorithm, and Raft algorithm.

5. A blockchain editing method based on cross-chain consensus according to claim 1, characterized in that, The method also includes: employing cryptographic methods to ensure the confidentiality and integrity of the communication process.

6. A blockchain editing method based on cross-chain consensus according to any one of claims 1-5, characterized in that, In response to the edit result, all participating parties confirm the edit result, including: The participating parties perform integrity verification, signature verification, consensus verification, and security protection verification on the editing results, and record the verification results; the verification results are either passed or failed. Determine whether all verification results are passed: if yes, mark the edit result as valid; otherwise, mark the edit result as invalid.

7. An editable blockchain system based on cross-chain consensus, employing the blockchain editing method based on cross-chain consensus as described in any one of claims 1-6, characterized in that, include: Participants are responsible for submitting edit proposals and transmitting them to other participants on the first and second chains; It is also used for cross-chain voting on the edit proposals; It is also used to confirm the editing results; cross-chain data exchange is performed between the first chain and the second chain, and the editing proposal includes an index of the target block; Verification body, used to record cross-chain voting results, verify the legality of the cross-chain voting results, and grant editing permissions to the cross-chain management body based on the cross-chain voting results; A cross-chain management authority, in response to the granted edit permission, edits the target block according to the index; It is also used to synchronize the editing results to all the aforementioned participants based on a cross-chain consensus mechanism.

8. A computer-readable storage medium, characterized in that, The storage medium stores at least one instruction, at least one program, code set, or instruction set, which is loaded and executed by a processor to implement a blockchain editing method based on cross-chain consensus as described in any one of claims 1-6.

Images