On-chain processing method and device based on multi-party terminal, equipment and medium

Abstract

The embodiment of the invention discloses an on-chain processing method and device based on a multi-party terminal, equipment and a medium. A specific embodiment of the method comprises the following steps: receiving a private key fragment and authorization information transmitted by an authorization terminal through a secure channel; verifying the authorization information to obtain an agency relationship; receiving request information submitted by the proxy terminal; verifying whether the authorization relation information is valid or not, and verifying whether the execution task information is within an authorization range or not; performing signature encryption on the public key information of the proxy terminal to obtain an execution signature; generating an execution record, and storing the execution record in a block chain in a chaining manner; and executing a change operation on the permission modification request initiated by the authorization terminal to obtain a permission change record, and uploading the permission change record to the block chain for storage. The implementation mode can be used for a block chain proxy scene with a high security standard, the risk of private key leakage is eliminated, and fine-grained permission control is realized.

Description

Technical Field

[0001] The embodiments of the present disclosure relate to the field of computer technology, and more particularly to a multi-party terminal-based on-chain processing method, apparatus, device, and medium. Background Art

[0002] On-chain proxy processing is a crucial permission management method on blockchains. Its security and flexibility directly impact the practical implementation of blockchain applications. For permission proxy scenarios on blockchains, the commonly used methods are: directly transferring private key authorization to the proxy terminal or deploying smart contracts to implement proxy functionality.

[0003] However, when using the above method to delegate permissions on the chain, the following technical problems often arise:

[0004] First, the private key authorization is directly transferred to the agent terminal, which can obtain complete control of the private key and cannot implement fine-grained restrictions on the agent's operating scope. Once the private key is leaked, the blockchain will cause permanent loss of assets and cannot be recovered through decentralization.

[0005] Second, deploying smart contracts to implement proxy functionality requires pre-defined permissions, which complicates the contract code and makes maintenance difficult. The public nature of blockchain means that contract execution details are exposed during execution, making it difficult to meet the needs of private scenarios.

[0006] The above information disclosed in this Background section is only for enhancement of understanding of the background of the inventive concept and therefore it may contain information that does not form the prior art that is already known in this country to a person of ordinary skill in the art. Summary of the Invention

[0007] The content of this disclosure is used to briefly introduce concepts that will be described in detail in the detailed description section below. The content of this disclosure is not intended to identify key features or essential features of the claimed technical solution, nor is it intended to limit the scope of the claimed technical solution.

[0008] Some embodiments of the present disclosure propose on-chain processing methods, devices, equipment and media based on multi-party terminals to solve one or more of the technical problems mentioned in the above background technology section.

[0009] In a first aspect, some embodiments of the present disclosure provide a multi-party terminal-based on-chain processing method, comprising: receiving a private key shard transmitted by an authorization terminal through a secure channel and a structured authorization information signed by the authorization terminal, wherein the private key shard is a private key shard generated by a threshold scheme and encrypted with a public key; verifying the authorization information based on the private key shard to obtain an agency relationship; receiving request information submitted by an agent terminal, wherein the request information includes authorization relationship information, execution task information, and agent terminal public key information; verifying whether the authorization relationship information is valid based on the agency relationship record stored in the blockchain, and verifying whether the execution relationship information is valid. Whether the task information is within the authorized scope, wherein the above-mentioned agency relationship record is obtained after performing a collaborative signature operation on the above-mentioned agency relationship; through the above-mentioned private key sharding, the above-mentioned agency terminal public key information is signed and encrypted to obtain an execution signature; according to the execution result, an execution record is generated to store the above-mentioned execution record on the chain in the above-mentioned blockchain, wherein the above-mentioned execution result is the execution result after the above-mentioned agency terminal decrypts the above-mentioned execution signature and executes the above-mentioned execution task information; according to the above-mentioned agency relationship record, a change operation is performed on the permission modification request initiated by the above-mentioned authorization terminal to obtain a permission change record, so that the above-mentioned permission change record is stored on the chain in the above-mentioned blockchain.

[0010] On the second aspect, some embodiments of the present disclosure provide an on-chain processing device based on multiple terminals, including: a shard receiving unit, configured to receive a private key shard transmitted by an authorization terminal through a secure channel and a structured authorization information signed by the authorization terminal, wherein the private key shard is a private key shard generated by a threshold scheme and encrypted with a public key; a shard verification unit, configured to verify the authorization information based on the private key shard to obtain an agency relationship; an information acquisition unit, configured to receive request information submitted by an agent terminal, wherein the request information includes authorization relationship information, execution task information and agent terminal public key information; an information verification unit, configured to verify whether the authorization relationship information is valid based on the agency relationship record stored in the blockchain, and verify whether the authorization relationship information is valid. Verify whether the above-mentioned execution task information is within the authorization scope, wherein the above-mentioned agency relationship record is obtained after performing a collaborative signature operation on the above-mentioned agency relationship; the signature encapsulation unit is configured to sign and encrypt the above-mentioned agency terminal public key information through the above-mentioned private key sharding to obtain an execution signature; the execution chain unit is configured to generate an execution record according to the execution result, so as to store the above-mentioned execution record on the chain in the above-mentioned blockchain, wherein the above-mentioned execution result is the execution result after the above-mentioned agency terminal decrypts the above-mentioned execution signature and executes the above-mentioned execution task information; the authority change unit is configured to perform a change operation on the authority modification request initiated by the above-mentioned authorization terminal according to the above-mentioned agency relationship record, and obtain a authority change record, so as to store the above-mentioned authority change record on the chain in the above-mentioned blockchain.

[0011] In a third aspect, some embodiments of the present disclosure provide an electronic device comprising: one or more processors; a storage device on which one or more programs are stored, and when the one or more programs are executed by one or more processors, the one or more processors implement the method described in any implementation manner in the first aspect.

[0012] In a fourth aspect, some embodiments of the present disclosure provide a computer-readable medium having a computer program stored thereon, wherein when the program is executed by a processor, the method described in any implementation manner in the first aspect is implemented.

[0013] The above-described embodiments of the present disclosure have the following beneficial effects: Through the on-chain processing method based on multiple terminals in some embodiments of the present disclosure, while eliminating the risk of direct private key sharing, fine-grained control of proxy terminal permissions is achieved, adapting to complex collaborative scenarios. Specifically, the risk of direct private key sharing and the inability to fine-grained control of proxy terminal permissions are caused by: once the private key is leaked, the blockchain will result in permanent asset loss, which cannot be recovered through decentralization. The public nature of the blockchain also causes the execution details of the contract to be disclosed during execution, which fails to meet the requirements of privacy scenarios. Based on this, the on-chain processing method based on multiple terminals in some embodiments of the present disclosure first receives a private key fragment transmitted by an authorized terminal via a secure channel and a structured authorization information signed by the authorized terminal, wherein the private key fragment is generated using a threshold scheme and encrypted with a public key. Thus, the private key fragment generated according to the threshold scheme physically avoids leakage caused by the completed private key transmission and is encrypted using the public key to ensure security during transmission. Then, the authorization information is verified based on the private key fragment to obtain the proxy relationship. Thus, the identity of the authorized terminal is verified through private key sharding, preventing authorization forgery. Next, a request message submitted by the proxy terminal is received, including authorization relationship information, execution task information, and the proxy terminal's public key information. This structured request message ensures operational compliance. Next, the validity of the authorization relationship information and the execution task information are verified to be within the authorized scope based on the proxy relationship record stored on the blockchain. The proxy relationship record is generated by performing a collaborative signature operation on the proxy relationship. This on-chain proxy relationship record provides a globally trusted authority status, ensuring real-time and consistent verification results. Next, the proxy terminal's public key information is encrypted and signed using the private key sharding to generate an execution signature. Generating an execution signature based on the private key shard ensures that the proxy terminal's operation requires collaborative authorization from multiple terminals. The signature encryption binds the proxy terminal's identity to prevent malicious use or substitution. Next, based on the execution result, an execution record is generated and stored on the blockchain. The execution result is the result of the proxy terminal decrypting the execution signature and executing the execution task information. Therefore, the execution record is uploaded to the blockchain, ensuring that the operation process is traceable and cannot be modified. When executing sensitive task details, they are encrypted and stored off-chain to meet privacy compliance requirements. Finally, based on the proxy relationship record, the permission modification request initiated by the authorized terminal is modified, resulting in a permission change record that is then uploaded and stored on the blockchain. This on-chain evidence of permission change records ensures that the change process is transparent and complies with consensus rules reached by multiple parties, avoiding operational delays and errors caused by manual intervention.In summary, a threshold scheme is used to split the private key and encrypt the transmission to ensure that no complete private key is leaked. Based on the dynamic update of the on-chain agency relationship records, fine-grained division and real-time adjustment of permissions are achieved. The execution details are encrypted on the chain, and unmodifiable evidence is retained on the blockchain to meet privacy compliance requirements in specific scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The above and other features, advantages, and aspects of the various embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and that components and elements are not necessarily drawn to scale.

[0015] Figure 1 is a flowchart of some embodiments of the on-chain processing method based on multiple terminals according to the present disclosure;

[0016] Figure 2 is a schematic structural diagram of some embodiments of a multi-party terminal-based on-chain processing device according to the present disclosure;

[0017] Figure 3 It is a structural diagram of an electronic device suitable for implementing some embodiments of the present disclosure. DETAILED DESCRIPTION

[0018] Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as being limited to the embodiments described herein. On the contrary, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustrative purposes only and are not intended to limit the scope of protection of the present disclosure.

[0019] It should also be noted that, for ease of description, only the parts related to the invention are shown in the drawings. In the absence of conflict, the embodiments and features in the embodiments of the present disclosure may be combined with each other.

[0020] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are only used to distinguish different devices, modules or units, and are not used to limit the order or interdependence of the functions performed by these devices, modules or units.

[0021] It should be noted that the modifications of "one" and "multiple" mentioned in the present disclosure are illustrative rather than restrictive, and those skilled in the art should understand that unless otherwise clearly indicated in the context, they should be understood as "one or more".

[0022] The names of the messages or information exchanged between multiple devices in the embodiments of the present disclosure are only used for illustrative purposes and are not used to limit the scope of these messages or information.

[0023] The present disclosure will be described in detail below with reference to the accompanying drawings and in conjunction with embodiments.

[0024] refer to Figure 1 , shows a process 100 of some embodiments of the on-chain processing method based on multiple terminals according to the present disclosure. The on-chain processing method based on multiple terminals includes the following steps:

[0025] Step 101: Receive a private key fragment transmitted by an authorization terminal through a secure channel and structured authorization information signed by the authorization terminal.

[0026] In some embodiments, the execution entity (e.g., an electronic device) of the aforementioned multi-party terminal-based on-chain processing method can be a distributed network built on secure multi-party computation (MPC) technology. Its core goal is to achieve secure sharded storage of private keys, dynamic permission management, and the generation and verification of transaction signatures through multi-node collaboration. Secure multi-party computation can be a cryptographic technique that allows multiple parties to jointly compute a function, each holding a portion of the input. During the computation, none of the parties can access the input information of the other parties. The authorization terminal can be the core operation entry point for the authorization party, the holder of the original private key, and is responsible for initiating authorization operations. The secure channel can be a communication channel established through an encryption protocol to ensure the confidentiality and integrity of data transmission. The authorization information can be standardized structured data created by the authorization terminal. A threshold scheme can be implemented by splitting a private key into multiple shards and setting a minimum number of shards. The original private key can only be recovered when the number of shards collected reaches or exceeds this minimum requirement. Private key shards can be fragments of the private key divided by the threshold scheme. Each shard is meaningless on its own, and only by combining a sufficient number of shards can the original private key be recovered. The public key encrypted private key shards can be encrypted with the public key of the target MPC node before each private key shard is transmitted, ensuring that the shard cannot be decrypted even if it is intercepted, and only the target node can decrypt it with the private key.

[0027] In practice, the encryption protocol may be Transport Layer Security (TLS). The standardized structured data may include the authorizer identity, the agent identity, the scope of authorization, and the validity period of the authorization. For example, the standardized structured data may be {delegator: delegator_address, delegate: delegate_address, permissions: [permission_1, permission_2, ...], valid_from: timestamp_1, valid_until: timestamp_2, nonce: random_number}.

[0028] In some embodiments, the execution entity may establish a secure channel using TLS encryption with the authorization terminal through the MPC node, and then receive the private key fragment and authorization information transmitted by the authorization terminal through the secure channel using TLS encryption.

[0029] Step 102: Verify the authorization information based on the private key shards to obtain the agency relationship.

[0030] In some embodiments, the execution entity may verify the authorization information based on the private key shards to obtain a proxy relationship. The proxy relationship may be a record of a delegation relationship between an authorization terminal and a proxy terminal. For example, the delegation relationship may include authorization information and permission status.

[0031] As an example, the execution entity can first decrypt the private key shard to obtain the original private key. The authorization information is then parsed to obtain the proxy terminal address, permission scope, and validity period fields. Next, the authorization terminal's public key is checked to ensure it matches the system-registered identity and the permission scope and validity period are determined. Finally, a unique authorization identifier is assigned to the proxy relationship, and the authorization information and authorization identifier are packaged and submitted to the blockchain.

[0032] While adopting technical solutions to solve the aforementioned technical problem, the following issues often arise: Private key shard transmission risk: Private key shards may be intercepted or tampered with during transmission, leading to shard leakage. Shard usage risk: The need to collect sufficient shards when using a private key may expose the identity of the shard-holding node, potentially leading to attacks and shard leakage.

[0033] Conventional solutions to these problems typically involve centralized management of hardware security modes. Private keys are stored in sharded hardware security modes, ensuring security through physical isolation. However, the inventors consider that hardware security modes may be susceptible to device failures and physical attacks that could lead to system failure. This also results in poor scalability and difficulty adapting to the dynamic node requirements of distributed blockchain scenarios. The following solutions can be employed:

[0034] In some optional implementations of some embodiments, the execution entity may verify the authorization information based on the private key shards to obtain the proxy relationship, which may include the following steps:

[0035] The first step is to assign nodes to the private key shards according to a preset node assignment rule to obtain a private key node set. The preset node assignment rule may be a random assignment rule, where the private key shards are randomly assigned to corresponding nodes. The private key node set may be a collection of private key shards assigned to different MPC nodes.

[0036] As an example, first, private key shards are assigned to different MPC nodes according to a preset rule. Finally, the assigned MPC nodes and the corresponding set of private key shards are obtained. For example, private key shards can be generated according to a threshold scheme, with a total number of shards of 5 and a minimum threshold of 3. The private key shards can be {shard 1, shard 2, shard 3, shard 4, shard 5}. The preset rule can be to randomly assign 5 shards to 5 nodes. Then, the assigned MPC nodes can be {node 1, node 2, node 3, node 4, node 5}, with a one-to-one correspondence between MPC nodes and private key shards.

[0037] The second step is to encrypt the private key shard corresponding to each private key node in the private key node set to obtain an encrypted private key node set, wherein each private key node independently manages the encryption key. The encrypted private key node set can be a set of each private key shard encrypted using the public key of the corresponding MPC node.

[0038] In practice, each MPC node corresponding to a private key shard uses its own public key to perform a cryptographic signing operation on the private key shard. This cryptographic signing operation can be performed using the BLS (Boneh-Lynn-Shacham) signature algorithm, a cryptographic scheme that supports signature aggregation, allowing multiple signatures to be combined into a single short signature, and the legitimacy can be quickly verified using the public key. For example, the private key shard assigned to MPC {node 1} is {shard 1}. Using {node 1}'s private key {private key 1} to encrypt {shard 1}, the result is {private key 1_node 1}. The encrypted result is {shard 1, private key 1_node 1}.

[0039] The third step is to perform a pre-signature test on each encrypted private key node set in the encrypted private key node set, generate a pre-signature corresponding to the encrypted node, and obtain a pre-signature set. The pre-signature test can be a test to verify whether the encrypted private key shard can be used to generate a valid signature and whether the private key shard is complete. The pre-signature set can be a set of temporary signature fragments generated by the test to verify the validity of the private key shard.

[0040] As an example, first, the MPC node uses its own private key to decrypt the corresponding private key shard. Finally, the MPC node is used to sign the test information to generate a partial signature of the private key shard. The test information can be an empty request information generated by the system, which is a prerequisite for signing. The test information is uniformly generated by the system, and the content is a hash value of a fixed string (for example, SHA256("MPC_TEST_STRING")). Each MPC node needs to use the decrypted private key shard to sign the hash value to generate a pre-signed fragment. For example, use the private key {private key 1} of {node 1} to decrypt {shard 1, private key 1_node 1} to obtain {shard 1}, perform a pre-signature test on the test information "test information", and obtain the pre-signed fragment {pre-signature 1}.

[0041] Step 4: According to the preset signature rules, perform the following steps for each pre-signature in the above pre-signature set:

[0042] The first sub-step is, in response to the pre-signature being invalid, transmitting a fragment retransmission signal to the authorized terminal.

[0043] As an example, the above-mentioned preset signature rule can be a defined standard for a valid signature, or a signature format. For example, if the pre-signature {pre-signature 2} generated by the MPC node {node 2} fails to pass verification, the authorized terminal is notified to retransmit the private key fragment.

[0044] In the second sub-step, in response to the above pre-signature being valid, the private key shard corresponding to the node is stored in ciphertext form to obtain a private key encrypted shard.

[0045] As an example, the ciphertext format can be a defined storage ciphertext standard or a ciphertext format. The private key encrypted shard can be a result of private key encryption stored in a standard ciphertext format. For example, if the pre-signature {pre-signature 1} generated by the MPC node {node 1} passes verification, the private key encryption result {shard 1, private key 1_node 1} corresponding to {node 1} is stored in the ciphertext form {ciphertext (shard 1, private key 1_node 1)}.

[0046] Step 5: Extract the authorization information to obtain the authorized terminal identity, proxy terminal address, proxy terminal authority scope, and validity period. The authorized terminal identity can be a unique identifier for the authorized terminal or a blockchain address. The proxy terminal address can be a unique identifier for the proxy terminal. The proxy terminal authority scope can specify the types of operations that the proxy terminal can perform and the restrictions. The validity period can be a practical window that limits the proxy terminal's authority.

[0047] For example, the authorized terminal identity can be 0x1A2b3c..., the proxy terminal address can be 0x9a8b7c..., the proxy terminal permission range can be {"action":"transfer","max_amount":"1000ETH","target":"0x123...def"}, and the validity period can be {"valid_from":"2025-01-01","valid_until":"2026-01-01"}.

[0048] The sixth step is to verify the identity of the above-mentioned authorized terminal to determine the legitimacy of the above-mentioned authorization information.

[0049] As an example, verify whether the identity of the authorized terminal is consistent with the system registration information.

[0050] Step 7: In response to the above authorization information being legitimate, the above proxy terminal address is subjected to authority verification, and the following authority verification steps are performed:

[0051] The third sub-step is to obtain the historical authority range and historical validity period of the above-mentioned proxy terminal address.

[0052] As an example, first, query the blockchain for the historical authorization records of the proxy terminal address. Next, query the permission scope and validity period from the historical authorization records. For example, the proxy address could be "0x123...abc." The historical authorization records reveal that the validity period is from "2024-01-01 to 2025-01-01" and that the "Contract Invoke" permission already exists.

[0053] The fourth sub-step is to determine whether the authority range of the proxy terminal overlaps with the authority range of the historical authority range.

[0054] For example, determining whether an authorized permission conflicts with a historical permission can be done by determining whether the operation type of the authorized permission overlaps with the permission scope list of the historical permission. Determine whether the target address of the authorized permission is the same as the target address of the historical permission. For example, the authorized permission could be "print information." The historical permission scope could be "call a contract." If there is no overlap in the permission scopes, verification passes.

[0055] The fifth sub-step is, in response to the above-mentioned permission scope contents not overlapping, determining whether the time span of the above-mentioned validity period conflicts with the time span of the above-mentioned historical validity period.

[0056] As an example, determine whether the validity period of the authorization information overlaps with the historical validity period. For example, the validity period of the authorization information may be "2025-01-01 to 2026-01-01." The historical validity period may be "2024-01-01 to 2025-01-01." If there is no time span conflict, verification is passed.

[0057] The sixth sub-step is to generate a proxy authorization record in response to the above time span not conflicting.

[0058] The proxy authorization record may be standardized according to a certain structure based on the authorization information.

[0059] For example, the proxy terminal address might be "0x123...abc." The permission scope might be "contract call, information printing." The validity period might be "2025-01-01 to 2026-01-01." The proxy authorization record might then be {"proxy terminal address":"0x123...abc," "permission scope":"contract call, information printing," "validity period":"2025-01-01 to 2026-01-01"}.

[0060] Step 8: Encrypt the fragments according to the private key, digitally sign the proxy authorization record, and generate an authorization evidence record.

[0061] The authorization evidence record can be a formal certificate that records the authorized operation and proves the authenticity of the operation. In practice, the certificate can be composed of authorization information and a digital signature.

[0062] As an example, first, the fragment is encrypted using the private key to generate a complete digital signature. Then, a unique identifier is generated using a hash algorithm for the proxy authorization record. Finally, the complete digital signature, proxy authorization record, and identifier are used to construct structured data.

[0063] The ninth step is to store the above authorization evidence record on the blockchain to obtain the above agency relationship.

[0064] The blockchain can be a database used to store proxy relationships, authorization records, and other key operations. Its core functions include immutability, traceability, and multi-party consensus. The proxy relationship can be a dynamic authorization delegation agreement between the authorization terminal and the proxy terminal.

[0065] As an example, first, necessary metadata is added to the authorization record to construct the blockchain information data field. Then, the blockchain information data field is cryptographically signed using an MPC node to obtain a partial signature. Next, the partial signature and the blockchain information data field are broadcast to the blockchain network for on-chain storage, resulting in stored information. Finally, the stored information and the authorization record are structured to form a proxy relationship. For example, the metadata could be the MPC network address and timestamp. The partial signature could be "0x6q9b...7m," the stored information could be the block height "#123456," and the blockchain explorer link could be "https: / / etherscan.io / tx / 0x5a8x...5s6f." The proxy relationship could then be {"delegation_id":"DLG-2025-001,""status":"active,""blockchain_ref":{"tx_hash":"0x6q9b...7m,""block_height":123456}}.

[0066] The above-mentioned first to ninth steps, as an inventive point of the present disclosure, solve the first technical problem mentioned in the background technology, "directly transmitting the private key authorization to the agent terminal, the agent terminal can obtain complete private key control, and cannot implement refined restrictions on the agent's operating scope, which may cause the private key to be leaked." The factors that lead to the above-mentioned technical problems are often as follows: the private key shard may be intercepted or tampered with during the transmission process. During the use of the private key shard, the identity of the node holding the shard may be exposed, thereby being attacked and leaked. Therefore, the present disclosure designs a secure channel shard transmission and MPC node secondary encryption scheme. After the private key shard is generated, it is transmitted to the target node through an encrypted channel. The target node ensures that the private key shard can only be decrypted by the target node through secondary encryption of the public key. The private key shard is strongly associated with the public key of the target node to prevent the incorrect use of the private key shard.

[0067] Step 103: Receive the request information submitted by the agent terminal.

[0068] In some embodiments, the execution entity may receive request information submitted by an agent terminal, wherein the request information includes authorization relationship information, execution task information, and agent terminal public key information. The agent terminal may be a device, system, or user authorized to perform a specific task, and completes on-chain operations on behalf of the authorized terminal by submitting request information. The request information may be structured data submitted by the agent terminal containing authorization relationships, task details, and identity credentials, which is used to trigger agent operations. The authorization relationship information may be core data describing agent authority, including authorization identification, scope of authority, and validity period. The execution task information may be the specific content of the on-chain operation that the agent terminal needs to perform. The agent terminal public key information may be the public key of the agent terminal, which is used to verify whether the request information is legal.

[0069] In practice, the execution entity may receive the request information transmitted by the proxy terminal via a TLS encrypted channel.

[0070] Step 104: Verify whether the authorization relationship information is valid based on the agency relationship record stored in the blockchain, and verify whether the execution task information is within the authorization scope.

[0071] In some embodiments, the execution subject can verify whether the authorization relationship information is valid and whether the execution task information is within the scope of authorization based on the proxy relationship record stored in the blockchain. The proxy relationship record is obtained after performing a collaborative signature operation on the proxy relationship. The collaborative signature can be a joint signature of the proxy relationship record by the node using private key shards, and a threshold number (for example, 3 / 5) must be met to generate a valid signature. The proxy relationship record can be structured data stored on the blockchain, which records the authority delegation relationship between the authorization terminal and the proxy terminal. In practice, the authority delegation relationship can be an agency relationship.

[0072] As an example, first, based on the authorization identifier provided by the proxy terminal, the corresponding authorization relationship record is retrieved from the blockchain. The authorization relationship record is parsed to obtain the authorized terminal address, proxy terminal address, permission scope, validity period, and digital signature. Next, the legitimacy of the digital signature in the authorization relationship record is verified. The current time is checked to see if it is within the validity period. The proxy terminal address is verified to be consistent with the proxy terminal address in the blockchain. Finally, the proxy terminal's execution task information is parsed to obtain the requested task type and task parameters. The task type is confirmed to be within the permission scope recorded on the blockchain. The task parameters are then verified to meet the constraints.

[0073] In some optional implementations of some embodiments, the execution entity may verify whether the authorization relationship information is valid and whether the execution task information is within the authorization scope based on the agency relationship record stored in the blockchain, which may include the following steps:

[0074] The first step is to extract the authorization information to obtain the proxy terminal identity. This authorization information can be specific information included in the request submitted by the proxy terminal, and can include permission declaration data. In practice, permission declaration data includes the authorization terminal identity, proxy terminal identity, permission scope, and validity period. This information can be extracted by extracting the corresponding information fields from the structured data in the request.

[0075] The second step is to determine whether the proxy terminal identity exists in the proxy relationship record. The proxy terminal identity is a unique identifier in the system. For example, the unique identifier can be a blockchain address or a public key hash.

[0076] As an example, first, use the proxy terminal's identity as the query key to call the blockchain browser API interface to query. Finally, get the return result and check whether the returned record is valid.

[0077] The third step is to obtain the agent terminal authority information in the agent relationship record in response to the presence of the agent relationship record. The agent terminal authority information may include the specific operation authority and restrictions granted to the agent terminal, such as the type of task to be performed and the validity period.

[0078] The fourth step is to determine whether the proxy terminal permission information matches the permission content of the execution permission information, wherein the execution permission information is extracted from the execution task information. In practice, the execution permission information can be an operation request extracted from the execution task information submitted by the proxy terminal, which can include a task type and task parameters.

[0079] As an example, first, the structured data in the request information is parsed to obtain the task type and task parameters. Finally, it is checked whether the task type is within the permission range and whether the task parameters meet the constraints.

[0080] Step 105: The public key information of the proxy terminal is signed and encrypted through the private key fragmentation to obtain an execution signature.

[0081] In some embodiments, the execution entity can use the private key shard to sign and encrypt the proxy terminal public key information to obtain an execution signature. The proxy terminal public key information can be the proxy terminal's public key, used to encrypt communications and verify the proxy terminal's identity. For example, it can be the public key hash corresponding to an Ethereum address. Signature encryption can be a dual operation that combines digital signature generation with public key encryption. The MPC node first generates a signature using the private key shard, and then encrypts the signature result using the proxy terminal's public key to ensure the security of the transmission process.

[0082] As an example, each MPC node first uses its own private key to decrypt the stored encrypted private key shard. Each node then uses the private key shard to generate a partial signature for the proxy terminal's public key. Finally, the partial signatures are combined into a full signature, which is then encrypted using the proxy terminal's public key to generate an encrypted signature.

[0083] For example, the encrypted private key fragments may be (node 1, node 2, ..., node 6), and the partial signatures may be (Sig1, Sig2, ..., Sig6). Node 1 generates Sig1. Node 1 (Sig1), node 2 (Sig2), and node 3 (Sig3) are combined to generate the complete signature (0x1f2e...3d4c), which after encryption may be (0x1f2e...3d4c, 0x234...def).

[0084] In some optional implementations of some embodiments, the execution subject may use the private key sharding to sign and encrypt the public key information of the proxy terminal to obtain an execution signature, which may include the following steps:

[0085] In the first step, random number shards corresponding to the proxy terminal's public key information are generated locally according to a preset threshold rule, resulting in a set of random number shards. The preset threshold rule may be a (t, n) threshold scheme, where n is the number of nodes. At least t shards are required to recover the secret (e.g., random number k). These random number shards may be random number fragments independently generated by each MPC node, which are combined to form the complete random number k.

[0086] As an example, first, a random number shard is generated locally, and each node generates a random number shard k i , satisfying k=k1+k2+…+k n Finally, the random number shards are stored locally, and each node saves its own shard k i , not exposed to other nodes.

[0087] For example, three MPC nodes (n=3, t=2) generate shards k1=5, k2=3, k3=2 respectively, and the complete random number k=5+3+2=10.

[0088] In the second step, each random number shard in the random number shard set is combined according to a preset secret sharing protocol combination to obtain a complete random number set. The secret sharing protocol can be Shamir (Shamir Secret Sharing), which allows shards to recover the secret through polynomial interpolation. The complete random number set can be the set of all shards. The complete random number k can be recovered only when at least t shards are used by the mobile phone.

[0089] As an example, first, the MPC nodes exchange the necessary shards through a secure channel. Finally, using the difference formula, Recover the complete random number. q can be the prime order of the elliptic curve selected by the authorized terminal, or it can be a Lagrange polynomial. mod can be a modulo operation.

[0090] For example, node 1 and node 2 provide shards k1=5 and k2=3, so the complete random number can be k=5+3=8.

[0091] The third step is to perform a sharding operation on the elliptic curve base point according to the private key sharding, generate a partial signature of the proxy terminal public key information, and obtain a partial signature set. The elliptic curve base point can be the announcement base point in the signature. For example, the base point G of the secp256k1 curve used by Bitcoin. The sharding operation can be to confirm that each node R i =k i *G, after combination, we get the elliptic curve point R=R1+R2+…+R n The above partial signature set can be the elliptic curve coordinate points corresponding to each node.

[0092] As an example, first, determine the node's elliptic curve coordinate point R. Finally, send the node's elliptic curve coordinate point R to the aggregation node.

[0093] For example, the elliptic curve coordinate point of node 1 may be R1=5·G, and the elliptic curve coordinate point of node 2 may be R2=3·G, and the total value is R=8·G.

[0094] The fourth step is to perform signature fragment aggregation on each partial signature in the partial signature set to generate the complete coordinate parameters corresponding to the partial signature, thereby obtaining a complete coordinate parameter set. The complete coordinate parameters can be a set of coordinates of elliptic curve points, which are used to generate the signature parameter r.

[0095] As an example, first, aggregate the elliptic curve coordinate points of all nodes, R = R1 + R2 + ... + R n Finally, the coordinate of the horizontal axis x of R is taken as the parameter r=Rx of the signature.

[0096] For example, if the elliptic curve coordinate point R = (x, y), then r = x. The signature parameter r can be 0x1f2e...3d4c.

[0097] Step 5: For each complete coordinate parameter in the complete coordinate parameter set, parse the horizontal axis feature value corresponding to the complete coordinate parameter and use it as the first signature parameter. The first signature parameter may be 0x1f2e...3d4c.

[0098] As an example, the horizontal axis coordinate x of the elliptic curve coordinate point R can be directly extracted. For example, the first signature parameter can be 0x1f2e...3d4c.

[0099] Step 6: Generate a double verification slice based on the above-mentioned proxy terminal public key information. The above-mentioned double verification slice can be an additional random number slice α used to verify the security of the signature. i .

[0100] As an example, generate α for each MPC node i , satisfying α=α1+α2+…+α n For example, node 1 generates α1=7, and node 2 generates α2=4. The total α=11.

[0101] Step 7: Perform a cross product operation on the double verification shard and the private key shard to generate a ciphertext intermediate quantity. The ciphertext intermediate quantity can be β i The above cross-product budget can be β i =α i ·k i For example, node 1 calculates β1 = 7·5 = 35, and node 2 calculates β2 = 4·3 = 12.

[0102] In the eighth step, the agent terminal public key information is calculated to obtain the first agent terminal public key information, wherein the first agent terminal public key information can be Q, which can be obtained by Q=d·G, where d is the private key.

[0103] As an example, the public key information of the first proxy terminal can be divided into two parts: i Calculate Q i =d i G, combined to get Q = Q1 + Q2 + ... + Q n For example, node 1 calculates Q1 = d1·G, and node 2 calculates Q2 = d2·G, and the total is Q = d·G.

[0104] In the ninth step, the execution task information, the first signature parameter, and the first proxy terminal public key information are encrypted to obtain an encrypted signature fragment, wherein the encrypted signature fragment may be a ciphertext generated by encrypting the proxy terminal public key.

[0105] As an example, first, the task information, the first signature parameter r and the first agent terminal public key information Q are structured to obtain structured data. Finally, the agent terminal public key is used to encrypt the task information M to obtain structured data and generate the encrypted signature fragment C. i =Enc(M,PK 代理 ).

[0106] For example, the task information may be ("action":"transfer"), the first signature parameter ("r":"0x1f2e...3d4c"), and the first agent terminal public key information ("Q":"0x456...def"). The ciphertext may be C_i.

[0107] Step 10: Double-encapsulate the private key fragment and the encrypted signature fragment according to the verification public key of the proxy end to obtain the first ciphertext information. i and encrypted signature shard C i The above double encapsulation can be achieved by sharding the private key into d i and encrypted signature shard C i Encrypt again to generate the first ciphertext information D i =Enc((d i ,C i ),PK 验证 For example, node 1 encrypts (d1, C1) to D_1, and node 2 encrypts (d1, C1) to D_2.

[0108] In the eleventh step, the first ciphertext information is decrypted and weightedly integrated according to a preset threshold rule to generate a second signature parameter.

[0109] As an example, first, decrypt the private key to verify the first ciphertext information and obtain the private key fragment d i And encrypted signature shard Ci, secondly, determine the inverse shard, and jointly calculate k through the MPC protocol -1 =(k1+k2+…+k t ) -1 mod n. Where k -1 is a random number k i Then, we get the second parameter s i parameter, Among them, H(m) can be the hash of message m. Finally, calculate the second signature parameter s,

[0110] For example, H(m) can be 5. The first signature parameter r can be 8, d iThe private key shards can be node 1 and node 2. Node 1 can calculate s1 = 19 (5 + 8 3) mod 23 = 19 29 mod 23 = 15. Node 2 can calculate s2 = 19 (5 + 8 4) mod 23 = 19 37 mod 23 = 20. The second signature parameter s can then be s = (15 + 20) mod 23 = 12.

[0111] In the twelfth step, the first signature parameter and the second signature parameter are combined according to a preset combination rule to obtain the execution signature.

[0112] As an example, a signature pair (r, s) is constructed using the first signature parameter and the second signature parameter as the execution signature. For example, the first signature parameter may be 8, and the second signature parameter may be 12. Then the execution signature may be (r=8, s=12).

[0113] Step 106: Generate an execution record based on the execution result, and store the execution record on the blockchain.

[0114] In some embodiments, the execution entity may generate an execution record based on the execution result, and store the execution record on the blockchain. The execution result is the result of the agent terminal decrypting the execution signature and executing the execution task information. The execution record may be standardized data of the execution result.

[0115] As an example, first, the execution result is structured and hashed. Second, the execution record is digitally signed using the MPC node's private key shard. Finally, the execution record and digital signature are combined to form blockchain data, which is then broadcast to the blockchain network for on-chain storage.

[0116] In some optional implementations of some embodiments, the execution entity may generate an execution record based on the execution result, and store the execution record on the blockchain, which may include the following steps:

[0117] The first step is to upload the first execution information to the blockchain to trigger execution and obtain a first execution result. The first execution information is obtained by the agent terminal decrypting the execution signature and executing the execution task information. In practice, the first execution information may be blockchain information data including task parameters and a signature. The first execution result may be the initial execution status returned by the blockchain.

[0118] As an example, first, the execution information is structured and represented. Second, it is broadcasted via the blockchain's node API (e.g., eth_sendRawTransaction in Ethereum). Finally, the first execution result is obtained.

[0119] For example, the execution information structured representation can be {"from":"0x123...abc","to":"0x789...ghi","value":"500ETH","signature":{"r":"0x1f2e...3d4c","s":"0x5a6b...7c8d"}}. The first execution result can be the hash information (tx_hash:"0x9d8e...7f6a") status (status:"peding").

[0120] The second step is to receive execution confirmation information. This execution confirmation information is feedback information obtained by the proxy terminal confirming the first execution result. This execution confirmation information may be the blockchain's final processing result of the execution information, including whether the execution was successful, the block height, and gas consumption. This feedback information may be structured data generated by the proxy terminal after parsing the confirmation information. For example, the structured data may be {"result":"success","block":"123456"}.

[0121] The third step is to combine the execution confirmation information with the first execution result according to a preset combination rule to obtain an execution record. The preset combination rule may be a rule for combining the execution result with the execution confirmation information, or may be a field mapping and data format.

[0122] As an example, we use field mapping to merge task parameters to generate an execution record. For example, an execution record might be {"task_id":"TASK-001","action":"transfer","params":{"to":"0x789...ghi","amount":"500ETH"},"tx_hash":"0x9d8e...7f6a","block_number":"123456","status":"success","timestamp":"2024-10-05T14:30:00Z"}}.

[0123] Step 4: Store the execution record on the blockchain. For example, first, construct the evidence. Then, broadcast the evidence, along with the execution record, to the blockchain. For example, the evidence might be {"to":"0x000...000","data":{"method":"storeRecord","params":"record"}}, and the evidence hash might be store_tx_hash:"0xdef...456".

[0124] Step 107: Based on the proxy relationship record, a change operation is performed on the permission modification request initiated by the authorization terminal to obtain a permission change record, so as to store the permission change record on the blockchain.

[0125] In some embodiments, the execution entity may perform a change operation on the permission modification request initiated by the authorized terminal based on the proxy relationship record, obtaining a permission change record to store the permission change record on the blockchain. The permission modification request may be a request initiated by the authorized terminal to adjust the scope of authority or validity period of the proxy relationship. For example, revoking a proxy: the authorized terminal sends a revocation request, and the MPC node deletes the corresponding permission record; modifying the scope of authority: adjusting the transaction types or limits that the proxy terminal can execute; updating the validity period: extending or shortening the validity period of the proxy authorization; and emergency freezing: temporarily suspending the proxy authority when a security risk is discovered. The permission change record may be structured data used to record permission modification operations.

[0126] As an example, first, the fields in the permission modification request are parsed and verified for plausibility in the delegation record. For example, the fields include the delegator address (delegator_address), delegation identifier (delegation_id), modification type (operation_type, such as modify_permissions), modification content (such as the new permission scope), and the delegator's signature (signature). Next, the permission scope field in the delegation record is modified, and the difference before and after the modification is recorded to create a change record. Finally, the MPC node signs the change record based on the private key shard and packages the signature and change record for storage on the blockchain.

[0127] In some optional implementations of some embodiments, the execution entity may perform a change operation on the permission modification request initiated by the authorization terminal based on the agency relationship record to obtain a permission change record, and store the permission change record on the blockchain, which may include the following steps:

[0128] The first step is to extract the permission modification request and obtain the authorized terminal's identity, modification details, and modification permissions. The modification details can be specific parameters that need to be adjusted. For example, the modification details can be a range, such as {"max_amount": "500ETH"}. The modification permissions can be the type of operation that the authorized terminal can perform to change the proxy relationship.

[0129] For example, a permission modification request can be {"delegator_address":"0x123...abc","delegation_id":"DLG-2024-001","operation_type":"modify","modification":{"max_amount":"500ETH"},"signature":"0x1f2e...3d4c"}.

[0130] The second step is to obtain the authorization terminal authority information in the agency relationship record based on the authorization terminal identity. The authorization terminal information may be the management authority of the authorization terminal in the agency relationship. The management authority may be the scope of permitted modification.

[0131] As an example, first, the agency relationship record is obtained through the authorization terminal identity identifier. Then, the corresponding fields in the agency relationship record are extracted.

[0132] For example, a delegation relationship record can be {"delegation_id":"DLG-2024-001","permissions":{"action":"transfer","max_amount":"1000ETH"},"valid_until":"2025-01-01"}, reading the "permissions" and "valid_until" fields.

[0133] The third step is to determine whether the modification permissions are consistent with the permissions of the authorized terminal permissions information. For example, if the modification permission is "modify", confirm whether the modification permission is within the allowed adjustment range. For example, the original permission may be "max_amount: 1000ETH", then changing it to 500ETH is legal.

[0134] In the fourth step, in response to the above permission content being met, the modification content is executed to obtain a stored record. The stored record can be an organized data recording the permission change operation, including a comparison before and after the modification.

[0135] For example, if max_amount is modified to 500 ETH and valid_until is updated, the attestation record can be {“operation_type”: “modify”, “before”: {“max_amount”: “1000 ETH”}, “after”: {“max_amount”: “500 ETH”}, “timestamp”: “2025-01-01T14:30:00Z”, “operator”: “0x123...abc”}.

[0136] Step 5: Sign the above-mentioned evidence record based on the above-mentioned private key sharding to obtain the above-mentioned permission change record. The above-mentioned permission change record includes the evidence record and the collective signature of the MPC node.

[0137] As an example, the MPC node first generates a partial signature using the private key shard, and then generates a full signature based on the partial signature. For example, using nodes 1 and 2 to generate signatures Sig1 and Sig2, the full signature can be 0x5a6b...7c8d. Finally, a permission change record is constructed. For example, the permission change record can be {"change_record":{...},"signature":"0x5a6b...7c8d"}.

[0138] Step 6: Store the permission change record on the blockchain. As an example, first construct the attestation record. Finally, broadcast the attestation record to the blockchain. For example, the attestation record might be {"to":"0x000...000","data":{"method":"storeChange","params":{"delegation_id":"DLG-2024-001","change_record":{...}}}}}.

[0139] In the process of adopting technical solutions to solve the above-mentioned technical problem 2, the following problems often arise: dynamic permission adjustment is difficult: traditional smart contracts require hard-coded permission rules, and modifications require redeployment of the contract, resulting in poor flexibility and high maintenance costs.

[0140] Conventional solutions to these problems typically include pre-implementing multiple layers of permission determination logic within the contract code. However, the inventors considered adding permission determination logic to the code, which would increase the contract size and cost. Furthermore, upgrades would be difficult, as each adjustment to permission rules would require re-deploying the contract, leading to gaps in historical data. The following solutions are available:

[0141] In some optional implementations of some embodiments, the execution entity may perform a change operation on the permission modification request initiated by the authorization terminal based on the agency relationship record to obtain a permission change record, and store the permission change record on the blockchain, which may include the following steps:

[0142] The first step is to parse the permission modification request to obtain the modification type, modification content, and authorized terminal signature. The modification type can be the operation classification of permission adjustment. For example, expand the permission scope (EXPAND_SCOPE), reduce the permission (REDUCE_SCOPE), and suspend the permission (SUSPEND). The modification content can be a specific permission parameter adjustment value. The authorized terminal signature can be a digital signature of the request data using a private key by the authorized terminal to verify the legitimacy of the request source. The parsing method can be to extract specific fields of the permission modification request. For example, the modification type can be "REDUCE_SCOPE". The modification content can be {"max_amount": "500ETH"}. The authorized terminal signature can be "0x1a2b3c..."

[0143] The second step is to verify the legitimacy of the permission modification request based on the above-mentioned agency relationship record and perform the following steps:

[0144] The first sub-step is to obtain the current permission scope and dependency chain of the authorized terminal. The dependency chain can be a hierarchical relationship of permissions. For example, the permissions of the proxy terminal must inherit from the permissions of the authorized terminal and cannot exceed the scope.

[0145] As an example, extract the corresponding fields from the current permission scope and dependency chain in the above delegation relationship record to obtain structured information. For example, the structured information can be {"delegation_id":"DLG-001","current_permission":{"action":"transfer","max_amount":"100ETH"},"dependency_chain":["Root:0x123..."]}.

[0146] The second sub-step is to verify whether the above modification content is within the above current permission range and does not violate the constraints of the above dependency chain.

[0147] As an example, first, check whether the modified content is within the current permission range. Finally, verify whether the proxy endpoint's permissions inherit the current authorized endpoint. For example, the modified content could be max_amount: 50 ETH. The original content could be {"max_amount": "100 ETH"}. The modified content is confirmed to be legal. The dependency chain constraint could be "dependency_chain": ["Root:0x123..."]. The dependency chain constraint passes.

[0148] The third sub-step is to use the node to sign and confirm the modified content based on the preset threshold rules.

[0149] As an example, first, the hash value of the permission modification request is broadcast to all nodes. Next, each node signs the hash value using its own private key shard, obtaining a partial signature. Finally, based on the threshold scheme, the complete signature is aggregated using the threshold aggregation algorithm.

[0150] For example, the hash value can be Hash({"max_amount": "50ETH"}) = 0x1a2b3c..., and the threshold scheme can be 3 valid signatures. Then the partial signature of node 1 can be Sig1 = Sign(PartialKey1, 0x1a2b3c...). The partial signature of node 2 can be Sig2 = Sign(PartialKey2, 0x1a2b3c...). The partial signature of node 3 can be Sig3 = Sign(PartialKey3, 0x1a2b3c...). The full signature can be Sig = BLS.Aggregate(Sig1, Sig2, Sig3) = 0x5a6b7c...

[0151] The third step is to generate a structured permission change record. This record includes the permissions before and after the change, a version number, and dynamic trigger conditions. The permissions before the change can be a complete parameter snapshot before the change. The permissions after the change can be a complete parameter snapshot after the change. The version number can be an identifier that uniquely identifies the permission version, such as a hash value or an incrementing sequence number. The dynamic trigger conditions can be on-chain or off-chain conditions for the permission to take effect. For example, the permission takes effect when the ETH price is less than $2,000.

[0152] For example, the permissions before the modification can be extracted from the proxy relationship record. The permissions after the modification can be extracted from the modification content. The version number can be generated by hashing the permissions before and after the modification. The trigger condition can be the satisfaction of specific conditions, which will be encoded into the smart contract logic. For example, the change record can be {"before": {"max_amount": "100ETH"}, "after": {"max_amount": "50ETH"}, "version": "v2-8a3d5f...", "trigger_condition": "NONE"}.

[0153] The fourth step is to use the private key shards to collaboratively sign the permission change record to obtain a stored signature.

[0154] As an example, first, the hash value of the permission change record is broadcast to participating nodes. Next, each node signs the hash value using a shard of its private key, generating a partial signature. Finally, a threshold aggregation algorithm is used to aggregate the complete signature, which serves as the attestation signature. For example, the participating nodes could be Node 1 and Node 2. A partial signature could be Node 1 generating Sig1 = Sign(PartialKey1, Hash(ChangeRecord)). Node 2 generates Sig2 = Sign(PartialKey2, Hash(ChangeRecord)). The attestation signature could be 0x5a6b7c...

[0155] Step 5: Encapsulate the permission change record, the stored signature, and the authorized terminal's proxy relationship identifier into blockchain information. The blockchain information may be an on-chain information package that includes operation data, signatures, and metadata.

[0156] As an example, first, the permission change record, the aforementioned evidence signature, and the authorization terminal's proxy relationship identifier are combined into structured data, and necessary metadata (e.g., timestamp) is added. Finally, the smart contract's interface method is called to encapsulate the data into executable blockchain information. For example, the blockchain information may be {"to":"0xContractAddress","data":{"method":"updatePermission","params":{"delegation_id":"DLG-001","change_record":"..."","signature":"0x5a6b7c..."}}}.

[0157] Step 6: Broadcast the above blockchain information to the above blockchain, triggering on-chain storage and updating the above agency relationship record.

[0158] As an example, the encapsulated blockchain information is sent to the blockchain node network. The blockchain verifies the legality of the signature and the permission dependencies, confirming the validity of the information. It then updates the proxy relationship record and generates a new block that is synchronized across the entire network.

[0159] For example, the updated delegation relationship record may be {"delegation_id":"DLG-001","current_permission":{"max_amount":"50ETH"},"version":"v2-8a3d5f..."}.

[0160] The first to sixth steps mentioned above, as an inventive point of the present disclosure, solve the second technical problem mentioned in the background technology, "Deploying smart contracts to realize proxy functions requires pre-solidification of permissions, resulting in high complexity of contract code and difficulty in maintenance." The factors that lead to the above technical problems are often as follows: pre-setting multi-layer permission judgment logic in the contract code. Frequent modifications at the code level increase the workload and cost, and may also affect the normal use of the contract. After the permissions are modified, the contract needs to be redeployed, resulting in a gap in historical data. Therefore, the present disclosure designs a solution for separate storage of dynamic permission rules. The permission rules are separated from the smart contract, the permission rules are modified on the MPC network, and the permission modification results (such as hash summary) and execution signature are chained, and saved and updated on the blockchain.

[0161] The above-described embodiments of the present disclosure have the following beneficial effects: Through the on-chain processing method based on multiple terminals in some embodiments of the present disclosure, while eliminating the risk of direct private key sharing, fine-grained control of proxy terminal permissions is achieved, adapting to complex collaborative scenarios. Specifically, the risk of direct private key sharing and the inability to fine-grained control of proxy terminal permissions are caused by: once the private key is leaked, the blockchain will result in permanent asset loss, which cannot be recovered through decentralization. The public nature of the blockchain also causes the execution details of the contract to be disclosed during execution, which fails to meet the requirements of privacy scenarios. Based on this, the on-chain processing method based on multiple terminals in some embodiments of the present disclosure first receives a private key fragment transmitted by an authorized terminal via a secure channel and a structured authorization information signed by the authorized terminal, wherein the private key fragment is generated using a threshold scheme and encrypted with a public key. Thus, the private key fragment generated according to the threshold scheme physically avoids leakage caused by the completed private key transmission and is encrypted using the public key to ensure security during transmission. Then, the authorization information is verified based on the private key fragment to obtain the proxy relationship. Thus, the identity of the authorized terminal is verified through private key sharding, preventing authorization forgery. Next, a request message submitted by the proxy terminal is received, including authorization relationship information, execution task information, and the proxy terminal's public key information. This structured request message ensures operational compliance. Next, the validity of the authorization relationship information and the execution task information are verified to be within the authorized scope based on the proxy relationship record stored on the blockchain. The proxy relationship record is generated by performing a collaborative signature operation on the proxy relationship. This on-chain proxy relationship record provides a globally trusted authority status, ensuring real-time and consistent verification results. Next, the proxy terminal's public key information is encrypted and signed using the private key sharding to generate an execution signature. Generating an execution signature based on the private key shard ensures that the proxy terminal's operation requires collaborative authorization from multiple terminals. The signature encryption binds the proxy terminal's identity to prevent malicious use or substitution. Next, based on the execution result, an execution record is generated and stored on the blockchain. The execution result is the result of the proxy terminal decrypting the execution signature and executing the execution task information. Therefore, the execution record is uploaded to the blockchain, ensuring that the operation process is traceable and cannot be modified. When executing sensitive task details, they are encrypted and stored off-chain to meet privacy compliance requirements. Finally, based on the proxy relationship record, the permission modification request initiated by the authorized terminal is modified, resulting in a permission change record that is then uploaded and stored on the blockchain. This on-chain evidence of permission change records ensures that the change process is transparent and complies with consensus rules reached by multiple parties, avoiding operational delays and errors caused by manual intervention.In summary, a threshold scheme is used to split the private key and encrypt the transmission to ensure that no complete private key is leaked. Based on the dynamic update of the on-chain agency relationship records, fine-grained division and real-time adjustment of permissions are achieved. The execution details are encrypted on the chain, and unmodifiable evidence is retained on the blockchain to meet privacy compliance requirements in specific scenarios.

[0162] Further references Figure 2 As an implementation of the methods shown in the above figures, the present disclosure provides some embodiments of a multi-party terminal-based on-chain processing device. These device embodiments are similar to Figure 1 Corresponding to the method embodiments shown, the multi-party terminal-based chain processing device can be specifically applied to various electronic devices.

[0163] like Figure 2 As shown, a multi-party terminal-based on-chain processing device 200 includes: a shard receiving unit 201, a shard verification unit 202, an information acquisition unit 203, an information verification unit 204, a signature encapsulation unit 205, an execution on-chain unit 206, and a permission change unit 207. The shard receiving unit 201 is configured to receive a private key shard transmitted by an authorization terminal through a secure channel and structured authorization information signed by the authorization terminal, wherein the private key shard is a private key shard generated by a threshold scheme and encrypted with a public key. The shard verification unit 202 is configured to verify the authorization information based on the private key shard to obtain an agency relationship. The information acquisition unit 203 is configured to receive request information submitted by the agent terminal, wherein the request information includes authorization relationship information, execution task information, and agent terminal public key information. The information verification unit 204 is configured to: verify whether the above-mentioned authorization relationship information is valid and whether the above-mentioned execution task information is within the authorization scope based on the agency relationship record stored in the blockchain, wherein the above-mentioned agency relationship record is obtained after performing a collaborative signature operation on the above-mentioned agency relationship. The signature encapsulation unit 205 is configured to: sign and encrypt the above-mentioned agency terminal public key information through the above-mentioned private key sharding to obtain an execution signature. The execution chain unit 206 is configured to: generate an execution record based on the execution result, so as to store the above-mentioned execution record on the chain in the above-mentioned blockchain, wherein the above-mentioned execution result is the execution result after the above-mentioned agency terminal decrypts the above-mentioned execution signature and executes the above-mentioned execution task information. The authority change unit 207 is configured to: perform a change operation on the authority modification request initiated by the above-mentioned authorization terminal based on the above-mentioned agency relationship record, obtain a authority change record, and store the above-mentioned authority change record on the chain in the above-mentioned blockchain.

[0164] It is understandable that the units recorded in the multi-party terminal-based chain processing device 200 are similar to those in the reference Figure 1Therefore, the operations, features and beneficial effects described above for the method are also applicable to the on-chain processing device 200 based on the multi-party terminal and the units contained therein, and will not be repeated here.

[0165] Reference below Figure 3 , which shows a structural schematic diagram of an electronic device (eg, an electronic device) 300 suitable for implementing some embodiments of the present disclosure. Figure 3 The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0166] like Figure 3 As shown, the electronic device 300 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. Various programs and data required for the operation of the electronic device 300 are also stored in the RAM 303. The processing device 301, the ROM 302, and the RAM 303 are connected to each other via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0167] Typically, the following devices may be connected to the I / O interface 305: an input device 306 including, for example, a touch screen, a touchpad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 307 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 308 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 309. The communication device 309 may allow the electronic device 300 to communicate with other devices wirelessly or by wire to exchange data. Figure 3 The electronic device 300 is shown with various devices, but it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed instead. Figure 3 Each block shown in the figure may represent one device, or may represent multiple devices as needed.

[0168] In particular, according to some embodiments of the present disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of the present disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In some such embodiments, the computer program can be downloaded and installed from a network via the communication device 309, or installed from the storage device 308, or installed from the ROM 302. When the computer program is executed by the processing device 301, the above-mentioned functions defined in the method of some embodiments of the present disclosure are performed.

[0169] It should be noted that in some embodiments of the present disclosure, the computer-readable medium mentioned above may be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In some embodiments of the present disclosure, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device, or device. In some embodiments of the present disclosure, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium may be transmitted using any suitable medium, including but not limited to wires, optical cables, RF (radio frequency), etc., or any suitable combination thereof.

[0170] In some embodiments, the client and server can communicate using any currently known or future developed network protocol, such as HTTP (HyperText Transfer Protocol), and can be interconnected with any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), an internet (e.g., the Internet), and a peer-to-peer network (e.g., an ad hoc peer-to-peer network), as well as any currently known or future developed network.

[0171] The above-mentioned computer-readable medium may be included in the above-mentioned electronic device; or it may exist independently without being assembled into the electronic device. The above-mentioned computer-readable medium carries one or more programs. When the above-mentioned one or more programs are executed by the electronic device, the electronic device: receives the private key fragment transmitted by the authorization terminal through a secure channel and the structured authorization information signed by the above-mentioned authorization terminal, wherein the above-mentioned private key fragment is a private key fragment generated by a threshold scheme and encrypted with a public key; verifies the above-mentioned authorization information based on the above-mentioned private key fragment to obtain the agency relationship; receives the request information submitted by the agent terminal, wherein the above-mentioned request information includes authorization relationship information, execution task information and agent terminal public key information; verifies whether the above-mentioned authorization relationship information is valid based on the agency relationship record stored in the blockchain, so as to obtain the agency relationship information. And verify whether the above-mentioned execution task information is within the authorization scope, wherein the above-mentioned agency relationship record is obtained after performing a collaborative signature operation on the above-mentioned agency relationship; through the above-mentioned private key sharding, the above-mentioned agency terminal public key information is signed and encrypted to obtain an execution signature; according to the execution result, an execution record is generated to store the above-mentioned execution record on the chain in the above-mentioned blockchain, wherein the above-mentioned execution result is the execution result after the above-mentioned agency terminal decrypts the above-mentioned execution signature and executes the above-mentioned execution task information; according to the above-mentioned agency relationship record, a change operation is performed on the permission modification request initiated by the above-mentioned authorization terminal to obtain a permission change record, so as to store the above-mentioned permission change record on the chain in the above-mentioned blockchain.

[0172] Computer program code for performing the operations of some embodiments of the present disclosure may be written in one or more programming languages, or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, C++, and conventional procedural programming languages such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0173] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the module, program segment, or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of the boxes in the block diagram and / or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0174] The units described in some embodiments of the present disclosure may be implemented in software or in hardware. The units described may also be provided in a processor, for example, they may be described as: a processor including a shard receiving unit, a shard verification unit, an information acquisition unit, an information verification unit, a signature encapsulation unit, an execution chain unit, and an authority change unit. The names of these units do not, in some cases, constitute a limitation on the units themselves. For example, the shard receiving unit may also be described as a "unit that receives private key shards transmitted by an authorization terminal through a secure channel and structured authorization information signed by the above-mentioned authorization terminal."

[0175] The functions described above herein may be performed, at least in part, by one or more hardware logic components. For example, and without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chip (SOCs), complex programmable logic devices (CPLDs), and the like.

[0176] The above description is only an illustration of some preferred embodiments of the present disclosure and the technical principles used. Those skilled in the art should understand that the scope of the invention involved in the embodiments of the present disclosure is not limited to the technical solutions formed by the specific combination of the above-mentioned technical features, but should also cover other technical solutions formed by any combination of the above-mentioned technical features or their equivalent features without departing from the above-mentioned inventive concept. For example, the above-mentioned features are replaced with (but not limited to) technical features with similar functions disclosed in the embodiments of the present disclosure.

Claims

1. A multi-terminal on-chain processing method, comprising: Receiving a private key fragment and structured authorization information signed by the authorized terminal and transmitted by the authorized terminal through a secure channel, wherein the private key fragment is a private key fragment generated by a threshold scheme and encrypted with a public key; Verifying the authorization information according to the private key shards to obtain the agency relationship; Receiving request information submitted by the agent terminal, wherein the request information includes authorization relationship information, execution task information and agent terminal public key information; Verify whether the authorization relationship information is valid and whether the execution task information is within the authorization scope based on the agency relationship record stored in the blockchain, wherein the agency relationship record is obtained after performing a collaborative signature operation on the agency relationship; The public key information of the proxy terminal is signed and encrypted by the private key sharding to obtain an execution signature; Generate an execution record based on the execution result, and store the execution record on the blockchain, wherein the execution result is the execution result after the agent terminal decrypts the execution signature and executes the execution task information; According to the agency relationship record, a change operation is performed on the permission modification request initiated by the authorized terminal to obtain a permission change record, so as to store the permission change record on the blockchain.

2. The method according to claim 1, wherein Verifying whether the authorization relationship information is valid and whether the execution task information is within the authorization scope based on the agency relationship record stored in the blockchain includes: Extracting the authorization information to obtain the agent terminal identity; Determining whether the agent terminal identity identifier exists in the agent relationship record; In response to the presence of the proxy relationship record, obtaining the proxy terminal authority information in the proxy relationship record; Determine whether the proxy terminal authority information matches the authority content of the execution authority information, wherein the execution authority information is extracted from the execution task information.

3. The method according to claim 1, wherein Generating an execution record based on the execution result, and storing the execution record on the blockchain, includes: Transmitting the first execution information to the blockchain to trigger execution, and obtaining a first execution result, wherein the first execution information is obtained by the agent terminal decrypting the execution signature and executing the execution task information; receiving execution confirmation information, wherein the execution confirmation information is feedback information obtained by the agent terminal confirming the first execution result; combining the execution confirmation information with the first execution result according to a preset combination rule to obtain an execution record; The execution record is stored in the blockchain.

4. The method according to claim 1, wherein The step of performing a change operation on the permission modification request initiated by the authorized terminal according to the agency relationship record to obtain a permission change record, and storing the permission change record on the blockchain, includes: Extract the permission modification request to obtain the authorized terminal identity, modification content and modification permission; According to the authorized terminal identity identifier, obtaining the authorized terminal authority information in the agency relationship record; Determining whether the modification permission is consistent with the permission content of the authorized terminal permission information; In response to the permission content being in compliance, executing the modification content and obtaining an evidence record; Sign the evidence record according to the private key shards to obtain the permission change record; The permission change record is stored on the blockchain.

5. The method according to claim 1, wherein The step of signing and encrypting the public key information of the proxy terminal through the private key sharding to obtain an execution signature includes: According to a preset threshold rule, a random number fragment corresponding to the public key information of the proxy terminal is generated locally to obtain a random number fragment set; Combining each random number shard in the random number shard set according to a preset secret sharing protocol combination to obtain a complete random number set; Performing a sharding operation on the elliptic curve reference point according to the private key sharding to generate a partial signature of the proxy terminal public key information to obtain a partial signature set; Performing signature fragment aggregation on each partial signature in the partial signature set to generate complete coordinate parameters corresponding to the partial signature, thereby obtaining a complete coordinate parameter set; For each complete coordinate parameter in the complete coordinate parameter set, parsing the horizontal axis eigenvalue corresponding to the complete coordinate parameter as the first signature parameter; Generate a double verification fragment according to the public key information of the proxy terminal; Performing a cross product operation on the dual verification shard and the private key shard to generate a ciphertext intermediate; Performing calculation on the proxy terminal public key information to obtain first proxy terminal public key information; Encrypting the task execution information, the first signature parameter, and the first agent terminal public key information to obtain an encrypted signature fragment; Double-encapsulate the private key fragment and the encrypted signature fragment according to the verification public key of the proxy end to obtain first ciphertext information; Decrypting the first ciphertext information and weighted fusion according to a preset threshold rule to generate a second signature parameter; The first signature parameter and the second signature parameter are combined according to a preset combination rule to obtain the execution signature.

6. A multi-party terminal-based on-chain processing device, comprising: A fragment receiving unit is configured to receive a private key fragment transmitted by an authorized terminal through a secure channel and structured authorization information signed by the authorized terminal, wherein the private key fragment is a private key fragment generated by a threshold scheme and encrypted by a public key; A shard verification unit is configured to verify the authorization information according to the private key shards to obtain a proxy relationship; An information acquisition unit is configured to receive request information submitted by an agent terminal, wherein the request information includes authorization relationship information, execution task information and agent terminal public key information; an information verification unit configured to verify whether the authorization relationship information is valid and whether the execution task information is within the authorization scope based on an agency relationship record stored in a blockchain, wherein the agency relationship record is obtained after performing a collaborative signing operation on the agency relationship; The signature encapsulation unit is configured to sign and encrypt the public key information of the proxy terminal through the private key fragment to obtain an execution signature; an execution and uploading unit configured to generate an execution record based on an execution result, and to upload the execution record to the blockchain for storage, wherein the execution result is an execution result after the agent terminal decrypts the execution signature and executes the execution task information; The authority change unit is configured to perform a change operation on the authority modification request initiated by the authorized terminal according to the agency relationship record, obtain a permission change record, and store the permission change record on the blockchain.

7. An electronic device comprising: one or more processors; a storage device having one or more programs stored thereon, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 5.

8. A computer-readable medium having a computer program stored thereon, wherein: When the program is executed by a processor, the method according to any one of claims 1 to 5 is implemented.

Images