Blockchain-based digital file signing method and apparatus

CN115174183BActive Publication Date: 2026-07-10ANT BLOCKCHAIN TECHNOLOGY (SHANGHAI) CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
ANT BLOCKCHAIN TECHNOLOGY (SHANGHAI) CO LTD
Filing Date
2022-06-28
Publication Date
2026-07-10

Smart Images

  • Figure CN115174183B_ABST
    Figure CN115174183B_ABST
Patent Text Reader

Abstract

One or more embodiments of the specification provide a blockchain-based digital file signing method and device, applied to a signing initiator client; the method comprises: in response to a signing processing operation initiated by a signing initiator for a target digital file, determining other signing participants participating in signing the target digital file; in response to the determined other signing participants, calling decryption logic contained in a first smart contract to perform decryption processing on an encrypted target digital file stored in a blockchain; and in response to completion of the target digital file decryption processing, further calling encryption logic contained in the first smart contract to perform encryption processing on the decrypted target digital file based on public keys of the other signing participants, so that the other signing participants, in response to the obtained encrypted target digital file, perform decryption processing on the encrypted target digital file based on private keys of the other signing participants, and perform signing processing on the decrypted target digital file.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This specification relates to the field of blockchain technology in one or more embodiments, and in particular to a blockchain-based digital document signing method and apparatus. Background Technology

[0002] Organizations, businesses, public institutions, and even individuals often need to sign certain documents related to them. This includes signing documents and affixing their seals to indicate their recognition of the documents' correctness and authenticity.

[0003] With the increasing prevalence of paperless office applications, the signing of digital documents typically requires data exchange between different users. Therefore, ensuring data security during the signing process becomes a pressing issue. Summary of the Invention

[0004] This specification provides one or more embodiments of the following technical solutions:

[0005] This specification provides a blockchain-based digital document signing method, applied to a client corresponding to the signing initiator; the target digital document to be signed is encrypted and stored in the blockchain; a first smart contract for signing and managing the target digital document is deployed on the blockchain; the method includes:

[0006] In response to the signing process initiated by the signing initiator for the target digital document, other signing participants who participated in signing the target digital document are identified;

[0007] In response to the identified other signing parties, the decryption logic contained in the first smart contract is invoked to decrypt the encrypted target digital file stored in the blockchain; and,

[0008] In response to the completion of the decryption of the target digital file, the encryption logic contained in the first smart contract is further invoked to encrypt the decrypted target digital file based on the public key of the other signing participants, so that the other signing participants, in response to the obtained encrypted target digital file, decrypt the encrypted target digital file based on the private key of the other signing participants, and sign the decrypted target digital file.

[0009] This specification also provides a blockchain-based digital document signing method, applied to a client corresponding to the signing participants; the target digital document to be signed is encrypted and stored in the blockchain; a first smart contract for signing and managing the target digital document is deployed on the blockchain; the method includes:

[0010] The encrypted target digital file is obtained; wherein, when the signing initiator determines other signing participants in response to the signing processing operation initiated by the signing initiator for the target digital file, the encrypted target digital file is obtained by calling the decryption logic contained in the first smart contract to decrypt the encrypted target digital file stored in the blockchain, and in response to the completion of the decryption processing of the target digital file, the encryption logic contained in the first smart contract is further called to encrypt the decrypted target digital file based on the public keys of the other signing participants;

[0011] In response to obtaining the encrypted target digital file, the encrypted target digital file is decrypted based on the private keys of the other signing participants;

[0012] The decrypted target digital file is then signed.

[0013] This specification also provides a blockchain-based digital document signing method, applied to a blockchain service platform; the target digital document to be signed is encrypted and stored in the blockchain; a first smart contract for signing and managing the target digital document is deployed on the blockchain; the method includes:

[0014] Receive a signing request sent by the client corresponding to the signing initiator in response to the signing processing operation initiated by the signing initiator for the target digital file;

[0015] In response to the signing request, other signing parties involved in signing the target digital document are identified;

[0016] In response to the identified other signing parties, the decryption logic contained in the first smart contract is invoked to decrypt the encrypted target digital file stored in the blockchain; and,

[0017] In response to the completion of the decryption of the target digital file, the encryption logic contained in the first smart contract is further invoked to encrypt the decrypted target digital file based on the public key of the other signing participants, so that the other signing participants, in response to the obtained encrypted target digital file, decrypt the encrypted target digital file based on the private key of the other signing participants, and sign the decrypted target digital file.

[0018] This specification also provides a blockchain-based digital document signing device, applied to a client corresponding to the signing initiator; the target digital document to be signed is encrypted and stored in the blockchain; a first smart contract for signing and managing the target digital document is deployed on the blockchain; the device includes:

[0019] The determination module, in response to the signing processing operation initiated by the signing initiator for the target digital document, determines other signing participants who will participate in signing the target digital document;

[0020] The module invokes, in response to the identified other signing participants, the decryption logic contained in the first smart contract to decrypt the encrypted target digital file stored in the blockchain; and, in response to the completion of the decryption of the target digital file, further invokes the encryption logic contained in the first smart contract to encrypt the decrypted target digital file based on the public key of the other signing participants, so that the other signing participants, in response to the obtained encrypted target digital file, decrypt the encrypted target digital file based on their private key and sign the decrypted target digital file.

[0021] This specification also provides a blockchain-based digital document signing device, applied to a client corresponding to the signing participants; the target digital document to be signed is encrypted and stored in the blockchain; a first smart contract for signing and managing the target digital document is deployed on the blockchain; the device includes:

[0022] The acquisition module acquires the encrypted target digital file; wherein, the encrypted target digital file is obtained by the signing initiator when, in response to the signing processing operation initiated by the signing initiator for the target digital file, other signing participants are identified, and the decryption logic contained in the first smart contract is invoked to decrypt the encrypted target digital file stored in the blockchain; and in response to the completion of the decryption of the target digital file, the encryption logic contained in the first smart contract is further invoked to encrypt the decrypted target digital file based on the public keys of the other signing participants.

[0023] The decryption module, in response to obtaining the encrypted target digital file, decrypts the encrypted target digital file based on the private keys of the other signing participants;

[0024] The signing module performs signing processing on the decrypted target digital file.

[0025] This specification also provides a blockchain-based digital document signing device applied to a blockchain service platform; the target digital document to be signed is encrypted and stored in the blockchain; a first smart contract for signing and managing the target digital document is deployed on the blockchain; the device includes:

[0026] The receiving module receives a signing request sent by the client corresponding to the signing initiator in response to the signing processing operation initiated by the signing initiator for the target digital file;

[0027] The determination module, in response to the signing request, determines other signing participants involved in signing the target digital document;

[0028] The module invokes, in response to the identified other signing participants, the decryption logic contained in the first smart contract to decrypt the encrypted target digital file stored in the blockchain; and, in response to the completion of the decryption of the target digital file, further invokes the encryption logic contained in the first smart contract to encrypt the decrypted target digital file based on the public key of the other signing participants, so that the other signing participants, in response to the obtained encrypted target digital file, decrypt the encrypted target digital file based on their private key and sign the decrypted target digital file.

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

[0030] processor;

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

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

[0033] This specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the method as described in any of the preceding claims.

[0034] In the above technical solution, the target digital file to be signed can first be encrypted and stored in the blockchain. Subsequently, in response to the signing initiator's signing operation for the target digital file, other signing participants are identified, and the decryption logic contained in the first smart contract deployed on the blockchain for signing management of the target digital file is invoked to decrypt the encrypted target digital file stored in the blockchain. Furthermore, the encryption logic contained in the first smart contract is invoked to re-encrypt the target digital file based on the public keys of the other signing participants, so that the other signing participants, in response to the obtained encrypted target digital file, re-decrypt the encrypted target digital file based on their private keys and sign the target digital file.

[0035] Through the above methods, firstly, since the digital files stored in the blockchain are encrypted, it is impossible to directly obtain the unencrypted, original digital files from the blockchain, thus ensuring the data security of the digital files; secondly, when providing the digital files to the signatories who participate in signing the digital files, the signatories can encrypt the digital files based on their public keys, thereby avoiding data leakage during data interaction and further enhancing the data security of the digital files. Attached Figure Description

[0036] Figure 1 This is a schematic diagram illustrating a blockchain-related network environment as shown in an exemplary embodiment of this specification.

[0037] Figure 2 This is a flowchart illustrating an exemplary embodiment of a blockchain-based digital document signing method.

[0038] Figure 3 This is a schematic diagram illustrating a user interface as shown in an exemplary embodiment of this specification.

[0039] Figure 4 This is a flowchart illustrating an exemplary embodiment of this specification, showing another blockchain-based digital document signing method.

[0040] Figure 5 This is a flowchart illustrating an exemplary embodiment of this specification, showing another blockchain-based digital document signing method.

[0041] Figure 6 This is a hardware structure diagram of an electronic device containing a blockchain-based digital document signing device, as illustrated in an exemplary embodiment of this specification.

[0042] Figure 7 This is a block diagram illustrating an exemplary embodiment of a blockchain-based digital document signing device.

[0043] Figure 8 This is a block diagram illustrating another blockchain-based digital document signing device in an exemplary embodiment of this specification.

[0044] Figure 9 This is a block diagram illustrating another blockchain-based digital document signing device in an exemplary embodiment of this specification. Detailed Implementation

[0045] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0046] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0047] Blockchain is generally classified into three types: public blockchain, private blockchain, and consortium blockchain. Furthermore, combinations of these types are possible, such as a combination of private and consortium blockchains, or a combination of consortium and public blockchains.

[0048] Of the three types of blockchains mentioned above, public blockchains offer the highest degree of decentralization. Participants in a public blockchain (also known as nodes in the blockchain) can read data records on the chain, participate in transactions, and compete for the right to record new blocks. Moreover, nodes can freely join or leave the network and perform related operations.

[0049] In contrast, private blockchains have write permissions controlled by a specific organization or institution, and data read permissions are governed by the organization's regulations. That is, a private blockchain can be viewed as a weakly centralized system, with strict restrictions on the number of nodes and a relatively small number of nodes. This type of blockchain is more suitable for use within specific organizations.

[0050] Consortium blockchains fall between public and private blockchains, enabling "partial decentralization." Each node in a consortium blockchain typically has a corresponding entity or organization; nodes join the network through authorization and form a consortium of stakeholders to jointly maintain the operation of the blockchain.

[0051] In a blockchain network, a blockchain node is a logical communication entity; multiple blockchain nodes of different types can run on the same physical server or on different physical servers.

[0052] Please refer to Figure 1 , Figure 1 This is a schematic diagram illustrating a blockchain-related network environment as shown in an exemplary embodiment of this specification.

[0053] In such Figure 1 The network environment shown may include a user-side computing device 101, a server 102, and at least one blockchain system; for example, blockchain system 103, blockchain system 104, and blockchain system 105.

[0054] In one embodiment shown, the user-side computing device 101 may include various different types of user-side computing devices; for example, user-side computing devices may include PC computing devices, mobile computing devices, Internet of Things devices, and other forms of smart devices with certain computing capabilities, etc.

[0055] It should be noted that user-side computing device 101 does not mean that all user-side computing devices are in the same communication network, but is merely a collective term for these user-side computing devices.

[0056] In one embodiment shown, some computing devices in the user-side computing device 101 can be coupled to the server 102 via various communication networks; for example, device 3 is coupled to the server 102.

[0057] Some computing devices in the user-side computing device 101 may not be coupled to the server 102, but may be directly coupled to the blockchain system as blockchain nodes; for example, device 4 may be directly coupled to the blockchain system 103 as a blockchain node.

[0058] In one embodiment shown, the user-side computing device 101 may further include one or more user-side servers, such as devices 5 and 6. Some computing devices in the user-side computing device 101 may be coupled to the user-side server; for example, device 1 is coupled to device 5, and device 2 is coupled to device 6. The user-side server may further be directly coupled to the blockchain system as a blockchain node, or it may be further coupled to the server-side 102 via various communication networks; for example, device 5 may be directly coupled to the blockchain system as a blockchain node, and device 6 may be further coupled to the server-side 102.

[0059] In one embodiment shown, the user-side server can be implemented by a service entity that has established a user account system; the service entity may include the operating entity of the service carrier that provides various online and / or offline services to users. Accordingly, the operating entity may include the operator corresponding to the service carrier; for example, the operating entity may include individuals, institutions, organizations, etc., that operate and manage the service carrier.

[0060] In one embodiment shown, server 102 may also be coupled to one or more blockchain systems via various communication networks; for example, server 102 may be coupled to blockchain system 103, blockchain system 104 and blockchain system 105, etc.

[0061] In one embodiment shown, the communication network may include wired and / or wireless communication networks; for example, it may be a local area network (LAN), wide area network (WAN), Internet, or a combination thereof, implemented based on a wired access network or wireless access network (such as a mobile cellular network) provided by an operator.

[0062] In one embodiment shown, each blockchain system can maintain one or more blockchains (e.g., public blockchain, private blockchain, consortium blockchain, etc.) and include multiple blockchain nodes for hosting the aforementioned one or more blockchains; for example, such as Figure 1 The blockchain nodes 1, 2, 3, 4, and i shown can collectively support one or more blockchains. Cross-chain data access is also possible between the blockchains within each blockchain system, and between different blockchain systems themselves.

[0063] In one embodiment shown, a blockchain node can be a physical device or a virtual device implemented in a server or server cluster. For example, a blockchain node can be a physical host in a server cluster, or a virtual machine created by virtualizing the hardware resources of a server or server cluster based on virtualization technology. Each blockchain node can be coupled together to form a network through various types of communication methods (e.g., TCP / IP) to carry one or more blockchains.

[0064] In one embodiment shown, server 102 may include a BaaS platform (also known as a BaaS cloud) for providing blockchain services (BaaS, Blockchain as a Service).

[0065] BaaS platforms can provide blockchain services to user-side computing devices coupled to the BaaS platform by providing pre-written software for activities that occur on the blockchain, such as subscriptions and notifications, user authentication, database management and remote updates.

[0066] For example, a BaaS platform can provide software such as MQ (Message Queue) services; user-side computing devices coupled to the BaaS platform can subscribe to smart contracts deployed on a blockchain in a blockchain system coupled to the BaaS platform, and the contract events generated on the blockchain after the smart contract is triggered and executed; the BaaS platform can listen to the events generated on the blockchain after the smart contract is triggered and executed, and then, based on the software related to the MQ service, add the contract events to the message queue in the form of notification messages, so that user-side computing devices that subscribe to the message queue can receive notifications related to the aforementioned contract events.

[0067] For data generated outside the blockchain, it can be constructed into a standard transaction format supported by the blockchain, and then published to the blockchain. All nodes in the blockchain network will reach a consensus on the transaction. After consensus is reached, the nodes acting as ledger nodes in the blockchain network can persistently store this transaction on the blockchain.

[0068] In programmable blockchains, the functionality of smart contracts allows users to create and invoke complex logic within the blockchain network. A smart contract is a program on the blockchain that can be triggered by transactions. Smart contracts can be defined in the form of code.

[0069] After a smart contract is created, a contract account corresponding to that smart contract appears on the blockchain, and it has a specific address. The behavior of the smart contract is controlled by the contract code in the contract account, while the account storage in the contract account saves the state of the smart contract.

[0070] A transaction used to invoke a smart contract can include the address of the account initiating the call, the address of the smart contract being invoked, and the method and parameters used to invoke the smart contract. After the smart contract is invoked, its state may change; the state of the smart contract can be viewed by communicating with blockchain nodes.

[0071] Smart contracts can be executed independently by nodes in a blockchain network in a prescribed manner. All execution records and related data can be stored on the blockchain. Therefore, once such a transaction is completed, the blockchain stores an immutable and unlost transaction certificate.

[0072] Smart contracts deployed on a blockchain can typically only access the data stored on the blockchain; however, in practical applications, for some complex business scenarios implemented based on smart contract technology, smart contracts may also need to access external data stored on off-chain data entities.

[0073] In this scenario, smart contracts deployed on the blockchain can access data from off-chain data entities through oracle programs, thereby enabling data interaction between smart contracts and real-world data entities. These off-chain data entities can include centralized servers or data centers deployed off-chain.

[0074] In practical applications, when deploying an oracle program for a smart contract on a blockchain, a corresponding oracle smart contract can be deployed on the blockchain first. This oracle smart contract is used to maintain the external data sent by the oracle program to the smart contract on the blockchain. For example, the external data sent by the oracle program to the smart contract on the blockchain can be stored in the account storage space (storage field) of the oracle smart contract.

[0075] When a target smart contract on the blockchain is invoked, the external data required by the target smart contract can be read from the account storage space of the oracle smart contract to complete the smart contract invocation process.

[0076] It should be noted that when sending external data to smart contracts on the blockchain, oracle programs can do so either actively or passively.

[0077] In one implementation, an off-chain data entity can sign the external data that needs to be provided to the target smart contract using the private key of the oracle program and then send it to the aforementioned oracle smart contract; for example, the signed external data can be sent to the aforementioned oracle smart contract in a periodic manner.

[0078] The aforementioned oracle smart contract can maintain the CA certificate of the oracle program. After receiving external data sent by an off-chain data entity, it can use the public key of the oracle program maintained in the CA certificate to verify the signature of the external data. After successful verification, the external data sent by the off-chain data entity will be stored in the account storage space of the oracle smart contract.

[0079] In another implementation, when a target smart contract on the blockchain is invoked, if the external data required by the target smart contract is not read from the account storage space of the oracle smart contract, the oracle smart contract can use the event mechanism of the smart contract to interact with the oracle program, and the oracle program will send the external data required by the target smart contract to the account storage space of the oracle smart contract.

[0080] For example, when a target smart contract on the blockchain is invoked, if the external data required by the target smart contract is not read from the account storage space of the oracle smart contract, the oracle smart contract can generate an external data acquisition event and record the external data acquisition event in the transaction log of the transaction that invoked the smart contract, and store the transaction log in the storage space of the node device. The aforementioned oracle program can listen to the transaction log generated by the oracle smart contract stored in the storage space of the node device, and after listening to the external data acquisition event in the transaction log, respond to the listened external data acquisition event and send the external data required by the target smart contract to the aforementioned oracle smart contract.

[0081] The event mechanism of smart contracts is a way for smart contracts to interact with off-chain entities. Smart contracts deployed on a blockchain typically cannot directly interact with off-chain entities; for example, after a smart contract completes its call, it usually cannot send the result of the call to the caller point-to-point.

[0082] The results generated during the invocation of a smart contract (including intermediate and final results) are typically recorded as events in the transaction logs of the transaction that invoked the smart contract, and stored in the storage space of the blockchain node. External entities that need to interact with the smart contract can obtain the invocation results by monitoring these transaction logs stored in the blockchain node's storage space.

[0083] This specification provides a blockchain-based digital document signing technical solution. First, the target digital document to be signed can be encrypted and stored in the blockchain. Subsequently, in response to a signing operation initiated by the signing initiator, other signing participants are identified. The decryption logic contained in a first smart contract deployed on the blockchain for signing management of the target digital document is invoked to decrypt the encrypted target digital document stored in the blockchain. Further, the encryption logic contained in the first smart contract is invoked to re-encrypt the target digital document based on the public keys of the other signing participants. This allows the other signing participants to, upon receiving the encrypted target digital document, decrypt it again based on their private keys and then sign the target digital document.

[0084] In practice, on the one hand, the target digital file to be signed can be encrypted and stored in the aforementioned blockchain; on the other hand, a first smart contract for signing and managing the target digital file can be deployed on the blockchain.

[0085] For the aforementioned target digital file, the initiating party can initiate a signing process for the target digital file through the aforementioned client.

[0086] Upon detecting the aforementioned signing operation, the client can respond to the signing operation and identify other signing participants involved in signing the target digital document.

[0087] Once the client identifies the other signatories involved in signing the target digital file, it can invoke the decryption logic contained in the first smart contract to decrypt the encrypted target digital file stored in the blockchain. Since the blockchain stores the encrypted target digital file, decrypting it yields the unencrypted, original target digital file.

[0088] After decrypting the encrypted target digital file by calling the decryption logic contained in the first smart contract, i.e., decrypting the target digital file, the encryption logic contained in the first smart contract can be further called to re-encrypt the target digital file based on the public keys of the other signing participants. Subsequently, in response to the obtained re-encrypted target digital file, these signing participants can decrypt the re-encrypted target digital file based on their private keys to obtain the unencrypted, original target digital file, and then sign the target digital file.

[0089] Through the above methods, firstly, since the digital files stored in the blockchain are encrypted, it is impossible to directly obtain the unencrypted, original digital files from the blockchain, thus ensuring the data security of the digital files; secondly, when providing the digital files to the signatories who participate in signing the digital files, the signatories can encrypt the digital files based on their public keys, thereby avoiding data leakage during data interaction and further enhancing the data security of the digital files.

[0090] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating an exemplary embodiment of a blockchain-based digital document signing method.

[0091] In this embodiment, the aforementioned blockchain-based digital document signing method can be applied to a client corresponding to the signing initiator. The signing initiator can initiate a signing process for a digital document requiring signing through this client, while the client and the clients corresponding to the signing participants can interact with the blockchain to complete the signing process for the digital document. The signing initiator can be a user who initiates the signing process for the digital document; the signing participants can be users who participate in signing the digital document.

[0092] Combination such as Figure 1 In the network environment shown, the aforementioned client can run on device 4 within user-side computing device 101. The aforementioned blockchain can be any type of blockchain that provides smart contract functionality.

[0093] For any digital document to be signed (hereinafter referred to as the target digital document), it can be encrypted and stored in the aforementioned blockchain. Accordingly, a smart contract (hereinafter referred to as the first smart contract) for signing and managing the target digital document can be deployed on the blockchain.

[0094] In one embodiment shown, the target digital file can be an electronic contract. Electronic contracts typically require the joint signature of multiple parties; that is, there can be multiple signatories for an electronic contract. The term "user" can refer to an individual, an institution, an organization, etc., and this specification does not impose any limitations on this.

[0095] The aforementioned blockchain-based digital document signing method may include the following steps:

[0096] Step 202: In response to the signing process operation initiated by the signing initiator for the target digital document, determine the other signing participants who will participate in signing the target digital document.

[0097] In this embodiment, for the aforementioned target digital file, the signing initiator can initiate a signing process for the target digital file through the aforementioned client.

[0098] Specifically, the aforementioned client can output the following to the aforementioned signing initiator: Figure 3 The user interface shown is for signing digital documents. The initiating party can upload the target digital document and select the desired signing participants from all users. After uploading the target digital document and selecting the desired signing participants, they can click the "Confirm" button to trigger the signing process by the desired signing participants. In this case, the client can identify the user's click on the "Confirm" button as the signing operation initiated by the initiating party for the target digital document.

[0099] Upon detecting the aforementioned signing operation, the client can respond to the signing operation and identify other signing participants involved in signing the target digital document.

[0100] As described above, the initiating party can select the desired signing participants from all users through a user interface used for signing digital documents, thereby identifying the desired signing participants as other signing participants in signing the aforementioned target digital document.

[0101] Alternatively, based on the content of the target digital file, the required signing participants can be identified from all users; in this case, these signing participants are the users who actually need to sign the target digital file. Subsequently, these signing participants can be identified as other signing participants in signing the target digital file.

[0102] In practical applications, the initiator of signing the aforementioned target digital file can be any one of the multiple signing participants of the target digital file; or, it can be a user other than the multiple signing participants of the target digital file; this specification does not impose any restrictions on this.

[0103] If the initiating signatory is any one of the multiple signing participants, it is generally assumed that the initiating signatory has already signed the target digital file and encrypted it in the blockchain. In this case, the other signing participants may include those other than the initiating signatory.

[0104] If the initiator of the aforementioned signing is a user other than the aforementioned multiple signing participants, then the aforementioned other signing participants may include these multiple signing participants.

[0105] Step 204: In response to the identified other signing participants, invoke the decryption logic contained in the first smart contract to decrypt the encrypted target digital file stored in the blockchain.

[0106] In this embodiment, the client can invoke the first smart contract after identifying other signing parties involved in signing the target digital document.

[0107] In practical applications, the client can construct the call data used to invoke the first smart contract into a standard transaction format supported by the blockchain, and publish this contract call transaction to the blockchain. All blockchain nodes within the blockchain will then reach a consensus on the contract call transaction. After consensus is reached, the blockchain node acting as the ledger node can package the contract call transaction into a block. For this contract call transaction packaged into a block, each blockchain node can respond to the contract call transaction and invoke the first smart contract.

[0108] Specifically, the aforementioned blockchain nodes can invoke the decryption logic contained in the first smart contract, that is, execute the portion of the code corresponding to the decryption logic within the first smart contract, to decrypt the encrypted target digital file stored in the blockchain. Since the blockchain stores the encrypted target digital file, in this case, by decrypting the encrypted target digital file, the unencrypted, original target digital file can be obtained.

[0109] Step 206: In response to the completion of the decryption of the target digital file, the encryption logic contained in the first smart contract is further invoked to encrypt the decrypted target digital file based on the public key of the other signing participants, so that the other signing participants, in response to the obtained encrypted target digital file, decrypt the encrypted target digital file based on the private key of the other signing participants, and sign the decrypted target digital file.

[0110] In this embodiment, after decrypting the encrypted target digital file by calling the decryption logic contained in the first smart contract, i.e., decrypting the target digital file, the encryption logic contained in the first smart contract can be further called to re-encrypt the target digital file based on the public keys of the other signing participants. Subsequently, in response to the obtained re-encrypted target digital file, these signing participants can decrypt the re-encrypted target digital file based on their private keys to obtain the unencrypted, original target digital file, and then sign the target digital file.

[0111] Taking any of the other signing participants mentioned above (hereinafter referred to as the target signing participant) as an example, the encryption logic contained in the first smart contract can be further invoked to re-encrypt the target digital file based on the target signing participant's public key. Subsequently, in response to the obtained re-encrypted target digital file, the target signing participant can decrypt the re-encrypted target digital file based on its private key to obtain the unencrypted, original target digital file, and then sign the target digital file. The target signing participant's private key and public key constitute a pair of asymmetric keys held by the target signing participant.

[0112] It should be noted that the term "signing party" in this specification may also refer to the client corresponding to the signing party.

[0113] The following describes the process of decrypting the target digital file encrypted and stored in the aforementioned blockchain, reencrypting the target digital file, re-decrypting the target digital file, and signing it. Figure 2 The embodiments shown will be described in detail.

[0114] (1) Decrypt the encrypted target digital file stored in the above blockchain.

[0115] In one embodiment shown, the target digital file can be encrypted using a symmetric key corresponding to the first smart contract and then stored in the blockchain.

[0116] In this case, when the decryption logic contained in the first smart contract is invoked to decrypt the encrypted target digital file stored in the blockchain, the decryption logic contained in the first smart contract can be invoked to decrypt the encrypted target digital file stored in the blockchain based on the symmetric key corresponding to the first smart contract.

[0117] In one embodiment shown, to further enhance data security, the node devices in the aforementioned blockchain can be equipped with a TEE (Trusted Execution Environment), and the first smart contract can be deployed within this TEE. Accordingly, the symmetric key corresponding to the first smart contract can be stored in the TEE.

[0118] Specifically, the code of the first smart contract can be encrypted using the symmetric key corresponding to the first smart contract, and the encrypted first smart contract can be deployed in the blockchain. Subsequently, the encrypted first smart contract stored in the blockchain can be loaded into the TEE, and the TEE can decrypt the encrypted first smart contract using the symmetric key and execute the code of the decrypted first smart contract to realize the call to the first smart contract.

[0119] In this case, when decrypting the encrypted target digital file stored in the blockchain based on the symmetric key corresponding to the first smart contract, the decryption can be performed on the encrypted target digital file stored in the blockchain within the TEE based on the symmetric key stored in the TEE.

[0120] (2) Re-encrypt the target digital file mentioned above.

[0121] In one embodiment shown, the node device in the aforementioned blockchain can be equipped with a TEE, and the first smart contract can be deployed within the TEE. Accordingly, the symmetric key corresponding to the first smart contract can be stored in the TEE.

[0122] In this case, when the encryption logic contained in the first smart contract is invoked to re-encrypt the target digital file based on the public keys of the other signing parties, the encryption logic contained in the first smart contract can be invoked to re-encrypt the target digital file in the TEE based on the public keys of these signing parties.

[0123] (3) Re-decrypt the target digital file and sign it.

[0124] In practical applications, the other signing participants can keep their private keys themselves; or, these signing participants can entrust their private keys to a storage system, so that when signing digital documents later, their private keys can be directly obtained from the storage system without them having to provide their private keys again, thus ensuring the data security of the private keys while providing convenience for these signing participants.

[0125] In one embodiment shown, if the other signing parties keep their private keys themselves, then these signing parties need to re-decrypt the target digital file.

[0126] When the target digital file is re-encrypted using the public keys of the other signing parties by invoking the encryption logic contained in the first smart contract, the re-encrypted target digital file is the result of the first smart contract call. In this case, a signing event for the target digital file by these signing parties can be generated and recorded in the transaction log of the contract call transaction, stored in the blockchain. This signing event may include the target digital file re-encrypted using the public keys of these signing parties.

[0127] The other signing participants can obtain the signing event by monitoring the transaction log stored in the blockchain, thereby obtaining the re-encrypted target digital file contained in the signing event. Alternatively, these signing participants can subscribe to the signing event through an SDK (Software Development Kit) deployed on the blockchain node, which acts as an event notification center. When the SDK detects the generation of the signing event, it sends it to these signing participants, allowing them to obtain the signing event and thus the re-encrypted target digital file contained within it.

[0128] Subsequently, the other signing parties may, in response to the obtained re-encrypted target digital file, decrypt the re-encrypted target digital file based on their private keys to obtain the unencrypted, original target digital file, and then sign the target digital file.

[0129] In one embodiment shown, a second smart contract may also be deployed on the blockchain for signing the target digital document based on the digital seals of the other signing participants.

[0130] In this scenario, for the other signing parties who keep their private keys, they can, on the one hand, decrypt the re-encrypted target digital file based on their private keys to obtain the unencrypted, original target digital file; on the other hand, they can generate authorization information for signing the target digital file based on their digital seals and sign the authorization information based on their private keys.

[0131] Subsequently, the other signing parties can submit the decrypted target digital file and the signed authorization information as calling parameters to the second smart contract to invoke it.

[0132] In practical applications, the other signing parties can construct the aforementioned call parameters into a standard transaction format supported by the blockchain, creating a contract call transaction. This contract call transaction is then published to the blockchain, where all blockchain nodes reach a consensus. After consensus is reached, the blockchain node acting as the ledger node packages the contract call transaction into a block. For this contract call transaction packaged into a block, each blockchain node can respond by invoking the aforementioned second smart contract.

[0133] Specifically, the blockchain node can call the signing logic contained in the second smart contract to verify the signature of the authorization information based on the public keys of the other signing participants. After the verification is successful, the decrypted target digital file can be signed based on the digital seals of these signing participants to complete the signing process of the target digital file.

[0134] In one embodiment shown, if the other signing parties escrow their private keys to a storage system, a second smart contract deployed on the blockchain for signing the target digital file based on the digital seals of these signing parties can replace these signing parties and re-decrypt the target digital file.

[0135] If the encryption logic contained in the first smart contract is invoked to re-encrypt the target digital file based on the public keys of the other signing parties, the first smart contract can continue to generate authorization information for signing the target digital file based on the digital seals of these signing parties, and obtain the private keys of these signing parties from the storage system to sign the authorization information based on their private keys.

[0136] Subsequently, the first smart contract can submit the re-encrypted target digital file and the signed authorization information as call parameters for cross-contract calls to the second smart contract, thereby enabling cross-contract calls to the second smart contract.

[0137] In practical applications, the first smart contract can create a message containing the re-encrypted target digital file and the signed authorization information based on the message call mechanism between different smart contracts, and send the message to the second smart contract. Upon receiving the message, the second smart contract can respond to the message, obtain the re-encrypted target digital file and the signed authorization information from the message, and execute the corresponding code in the code of the second smart contract based on the re-encrypted target digital file and the signed authorization information.

[0138] Specifically, the signing logic contained in the second smart contract can be invoked across contracts. On the one hand, the private keys of these signing participants are obtained from the storage system to decrypt the re-encrypted target digital file based on the private keys of these signing participants. On the other hand, the signature of the authorization information is verified based on the public keys of these signing participants. After the verification is successful, the decrypted target digital file is further signed based on the digital seals of these signing participants to complete the signing process of the target digital file.

[0139] In practical applications, the digital seals of the other signing parties can be stored in the blockchain in advance, so that when it is necessary to use the digital seals of these signing parties in the future, the digital seals of these signing parties can be directly obtained from the blockchain.

[0140] In the above technical solution, the target digital file to be signed can first be encrypted and stored in the blockchain. Subsequently, in response to the signing initiator's signing operation for the target digital file, other signing participants are identified, and the decryption logic contained in the first smart contract deployed on the blockchain for signing management of the target digital file is invoked to decrypt the encrypted target digital file stored in the blockchain. Furthermore, the encryption logic contained in the first smart contract is invoked to re-encrypt the target digital file based on the public keys of the other signing participants, so that the other signing participants, in response to the obtained encrypted target digital file, re-decrypt the encrypted target digital file based on their private keys and sign the target digital file.

[0141] Through the above methods, firstly, since the digital files stored in the blockchain are encrypted, it is impossible to directly obtain the unencrypted, original digital files from the blockchain, thus ensuring the data security of the digital files; secondly, when providing the digital files to the signatories who participate in signing the digital files, the signatories can encrypt the digital files based on their public keys, thereby avoiding data leakage during data interaction and further enhancing the data security of the digital files.

[0142] Please refer to Figure 4 , Figure 4 This is another blockchain-based digital document signing method illustrated in an exemplary embodiment of this specification.

[0143] In this embodiment, the aforementioned blockchain-based digital document signing method can be applied to clients corresponding to the signing participants. These clients, along with the client corresponding to the signing initiator, can interact with the blockchain to complete the signing process for the digital document. The signing initiator can be a user who initiates the signing process for the digital document; the signing participants can be users who participate in signing the digital document.

[0144] Combination such as Figure 1 In the network environment shown, the aforementioned client can run on device 4 within user-side computing device 101. The aforementioned blockchain can be any type of blockchain that provides smart contract functionality.

[0145] For any digital document to be signed (hereinafter referred to as the target digital document), it can be encrypted and stored in the aforementioned blockchain. Accordingly, a smart contract (hereinafter referred to as the first smart contract) for signing and managing the target digital document can be deployed on the blockchain.

[0146] In one embodiment shown, the target digital file can be an electronic contract. Electronic contracts typically require the joint signature of multiple parties; that is, there can be multiple signatories for an electronic contract. The term "user" can refer to an individual, an institution, an organization, etc., and this specification does not impose any limitations on this.

[0147] The aforementioned blockchain-based digital document signing method may include the following steps:

[0148] Step 402: Obtain the encrypted target digital file; wherein, the encrypted target digital file is obtained by the signing initiator when, in response to the signing processing operation initiated by the signing initiator for the target digital file, other signing participants are identified, and the decryption logic contained in the first smart contract is invoked to decrypt the encrypted target digital file stored in the blockchain. In response to the completion of the decryption of the target digital file, the encryption logic contained in the first smart contract is further invoked to encrypt the decrypted target digital file based on the public keys of the other signing participants.

[0149] Step 404: In response to obtaining the encrypted target digital file, decrypt the encrypted target digital file based on the private keys of the other signing participants.

[0150] Step 406: Sign the decrypted target digital file.

[0151] In one embodiment shown, obtaining the encrypted target digital file includes:

[0152] Obtain the signing events of the other signing participants for the target digital file from the blockchain; wherein the signing events are generated by the signing initiator and stored in the blockchain; the signing events include the encrypted target digital file.

[0153] In one embodiment shown, a second smart contract is also deployed on the blockchain for signing the target digital document based on the digital seals of the other signing participants;

[0154] The signing process for the decrypted target digital file includes:

[0155] Generate authorization information for signing the target digital file based on the digital seals of the other signing participants, and sign the authorization information based on the private keys of the other signing participants;

[0156] The decrypted target digital file and the signed authorization information are submitted to the second smart contract as calling parameters to invoke the signing logic contained in the second smart contract. The signature of the authorization information is verified based on the public key of the other signing participants, and after the verification is successful, the decrypted target digital file is signed based on the digital seal of the other signing participants to complete the signing process of the target digital file.

[0157] In the above technical solution, the target digital file to be signed can first be encrypted and stored in the blockchain. Subsequently, in response to the signing initiator's signing operation for the target digital file, other signing participants are identified, and the decryption logic contained in the first smart contract deployed on the blockchain for signing management of the target digital file is invoked to decrypt the encrypted target digital file stored in the blockchain. Furthermore, the encryption logic contained in the first smart contract is invoked to re-encrypt the target digital file based on the public keys of the other signing participants, so that the other signing participants, in response to the obtained encrypted target digital file, re-decrypt the encrypted target digital file based on their private keys and sign the target digital file.

[0158] Through the above methods, firstly, since the digital files stored in the blockchain are encrypted, it is impossible to directly obtain the unencrypted, original digital files from the blockchain, thus ensuring the data security of the digital files; secondly, when providing the digital files to the signatories who participate in signing the digital files, the signatories can encrypt the digital files based on their public keys, thereby avoiding data leakage during data interaction and further enhancing the data security of the digital files.

[0159] like Figure 4 The specific implementation of each step in the embodiments described above can be referred to as follows: Figure 2 The embodiments shown are not described in detail here.

[0160] Please refer to Figure 5 , Figure 5 This is another blockchain-based digital document signing method illustrated in an exemplary embodiment of this specification.

[0161] The aforementioned blockchain-based digital document signing method can be applied to a blockchain service platform. The initiating party can initiate a signing process for a digital document requiring signing through a client corresponding to that party. The clients corresponding to the initiating party and the participating parties can interact with the blockchain service platform, which in turn can further interact with the blockchain to complete the signing process. The initiating party can be a user who initiates the signing process for the digital document; the participating parties can be users who participate in signing the digital document.

[0162] Combination such as Figure 1In the network environment shown, the client described above can run on device 3 in user-side computing device 101; the blockchain service platform described above can run on server 102. The blockchain described above can be any type of blockchain that provides smart contract functionality.

[0163] For any digital document to be signed (hereinafter referred to as the target digital document), it can be encrypted and stored in the aforementioned blockchain. Accordingly, a smart contract (hereinafter referred to as the first smart contract) for signing and managing the target digital document can be deployed on the blockchain.

[0164] In one embodiment shown, the target digital file can be an electronic contract. Electronic contracts typically require the joint signature of multiple parties; that is, there can be multiple signatories for an electronic contract. The term "user" can refer to an individual, an institution, an organization, etc., and this specification does not impose any limitations on this.

[0165] The aforementioned blockchain-based digital document signing method may include the following steps:

[0166] Step 502: Receive a signing request from the client corresponding to the signing initiator in response to the signing processing operation initiated by the signing initiator for the target digital file.

[0167] In this embodiment, for the aforementioned target digital file, the signing initiator can initiate a signing process for the target digital file through the aforementioned client.

[0168] Upon detecting the aforementioned signing operation, the client can respond to the signing operation by constructing a signing request and sending it to the blockchain service platform, enabling the blockchain service platform to receive the signing request.

[0169] Step 504: In response to the signing request, identify other signing parties involved in signing the target digital document.

[0170] In this embodiment, upon receiving the aforementioned signing request, the blockchain service platform can respond to the signing request and identify other signing participants involved in signing the target digital document.

[0171] The specific implementation of identifying other signing parties involved in signing the aforementioned target digital document can be referred to step 202 above, and will not be repeated here.

[0172] Step 506: In response to the identified other signing participants, invoke the decryption logic contained in the first smart contract to decrypt the encrypted target digital file stored in the blockchain.

[0173] Step 508: In response to the completion of the decryption of the target digital file, the encryption logic contained in the first smart contract is further invoked to encrypt the decrypted target digital file based on the public key of the other signing participants, so that the other signing participants, in response to the obtained encrypted target digital file, decrypt the encrypted target digital file based on the private key of the other signing participants, and sign the decrypted target digital file.

[0174] The specific implementation of steps 506 and 508 can be referred to steps 504 and 506 above, and will not be repeated here.

[0175] In one embodiment shown, the target digital file is encrypted using a symmetric key corresponding to the first smart contract and then stored in the blockchain;

[0176] The process of decrypting the encrypted target digital file stored in the blockchain includes:

[0177] Based on the symmetric key corresponding to the first smart contract, the encrypted target digital file stored in the blockchain is decrypted.

[0178] In one embodiment shown, the first smart contract is deployed in a TEE (Telematics Equipment) mounted on a node device in the blockchain; the TEE maintains a symmetric key corresponding to the first smart contract.

[0179] The process of decrypting the encrypted target digital file stored in the blockchain based on the symmetric key corresponding to the first smart contract includes:

[0180] In the TEE, the encrypted target digital file stored in the blockchain is decrypted based on the symmetric key corresponding to the first smart contract maintained in the TEE.

[0181] The encryption process of the decrypted target digital file based on the public keys of the other signing parties includes:

[0182] The decrypted target digital file is encrypted using the public keys of the other signing parties in the TEE.

[0183] In one embodiment, the step of encrypting the decrypted target digital file based on the public key of the other signing participants, so that the other signing participants, in response to the obtained encrypted target digital file, decrypt the encrypted target digital file based on their private keys, and sign the decrypted target digital file, includes:

[0184] The decrypted target digital file is encrypted using the public keys of the other signing participants, and a signing event for the target digital file is generated by the other signing participants. The signing event is stored in the blockchain, wherein the signing event includes the encrypted target digital file, so that the other signing participants can obtain the signing event from the blockchain. In response to the signing event, the encrypted target digital file is decrypted using the private keys of the other signing participants, and the decrypted target digital file is signed.

[0185] In one embodiment shown, a second smart contract is also deployed on the blockchain for signing the target digital document based on the digital seals of the other signing participants;

[0186] The process involves encrypting the decrypted target digital file using the public keys of the other signing participants, generating a signing event for the target digital file by the other signing participants, and storing the signing event in the blockchain. The signing event includes the encrypted target digital file, enabling the other signing participants to retrieve the signing event from the blockchain. In response to the signing event, the process involves decrypting the encrypted target digital file using the private keys of the other signing participants and signing the decrypted target digital file. This includes:

[0187] The decrypted target digital file is encrypted using the public keys of the other signing participants, and a signing event for the target digital file is generated by the other signing participants. The signing event is stored in the blockchain, whereby the signing event includes the encrypted target digital file. This allows the other signing participants to retrieve the signing event from the blockchain. In response to the signing event, the encrypted target digital file is decrypted using the private keys of the other signing participants, and authorization information for signing the target digital file based on the digital seals of the other signing participants is generated. The authorization information is then signed using the private keys of the other signing participants. The decrypted target digital file and the signed authorization information are submitted as calling parameters to the second smart contract to invoke the signing logic contained in the second smart contract. The signature of the authorization information is verified using the public keys of the other signing participants, and upon successful verification, the decrypted target digital file is signed using the digital seals of the other signing participants to complete the signing process of the target digital file.

[0188] In one embodiment shown, a second smart contract is also deployed on the blockchain for signing the target digital document based on the digital seals of the other signing participants;

[0189] The step of encrypting the decrypted target digital file based on the public key of the other signing participants, so that the other signing participants, in response to the obtained encrypted target digital file, decrypt the encrypted target digital file based on their private keys, and sign the decrypted target digital file, includes:

[0190] The decrypted target digital file is encrypted using the public keys of the other signing participants, and authorization information for signing the target digital file is generated based on the digital seals of the other signing participants. The private keys stored in trust by the other signing participants are obtained, and the authorization information is signed using the private keys. The encrypted target digital file and the signed authorization information are submitted to the second smart contract as call parameters for cross-contract calls. This allows for cross-contract calls to the signing logic contained in the second smart contract. The private keys stored in trust by the other signing participants are obtained, and the encrypted target digital file is decrypted using the private keys. The signature of the authorization information is verified using the public keys of the other signing participants, and after successful verification, the decrypted target digital file is signed using the digital seals of the other signing participants to complete the signing process of the target digital file.

[0191] In one embodiment shown, the other signing parties include multiple signing parties.

[0192] In one embodiment shown, the target digital file includes an electronic contract.

[0193] like Figure 5 The specific implementation of each step in the embodiments described above can be referred to as follows: Figure 2 The embodiments shown are not described in detail here.

[0194] In the above technical solution, the target digital file to be signed can first be encrypted and stored in the blockchain. Subsequently, in response to the signing initiator's signing operation for the target digital file, other signing participants are identified, and the decryption logic contained in the first smart contract deployed on the blockchain for signing management of the target digital file is invoked to decrypt the encrypted target digital file stored in the blockchain. Furthermore, the encryption logic contained in the first smart contract is invoked to re-encrypt the target digital file based on the public keys of the other signing participants, so that the other signing participants, in response to the obtained encrypted target digital file, re-decrypt the encrypted target digital file based on their private keys and sign the target digital file.

[0195] Through the above methods, firstly, since the digital files stored in the blockchain are encrypted, it is impossible to directly obtain the unencrypted, original digital files from the blockchain, thus ensuring the data security of the digital files; secondly, when providing the digital files to the signatories who participate in signing the digital files, the signatories can encrypt the digital files based on their public keys, thereby avoiding data leakage during data interaction and further enhancing the data security of the digital files.

[0196] Corresponding to the aforementioned embodiments of the blockchain-based digital document signing method, this specification also provides embodiments of a blockchain-based digital document signing device.

[0197] This specification describes an embodiment of a blockchain-based digital document signing device that can be applied to electronic devices. The device embodiment can be implemented through software, hardware, or a combination of both. Taking software implementation as an example, as a logical device, it is formed by the processor of the electronic device loading corresponding computer program instructions from non-volatile memory into memory for execution. From a hardware perspective, such as... Figure 6The diagram shown is a hardware structure diagram of an electronic device containing the blockchain-based digital document signing device described in this specification. (Except for...) Figure 6 In addition to the processor, memory, network interface, and non-volatile memory shown, the electronic device in which the device is located in the embodiment may also include other hardware depending on the actual function of the blockchain-based digital document signing, which will not be described in detail here.

[0198] Please refer to Figure 7 , Figure 7 This is a block diagram illustrating an exemplary embodiment of a blockchain-based digital document signing device.

[0199] The aforementioned blockchain-based digital document signing device can be applied to systems such as... Figure 6 The electronic device shown has a client corresponding to the signing initiator; the target digital file to be signed is encrypted and stored in a blockchain; and a first smart contract for signing and managing the target digital file is deployed on the blockchain.

[0200] The aforementioned blockchain-based digital document signing device may include:

[0201] The determination module 701, in response to the signing processing operation initiated by the signing initiator for the target digital file, determines other signing participants who will participate in signing the target digital file;

[0202] Module 702, in response to the identified other signing participants, invokes the decryption logic contained in the first smart contract to decrypt the encrypted target digital file stored in the blockchain; and, in response to the completion of the decryption of the target digital file, further invokes the encryption logic contained in the first smart contract to encrypt the decrypted target digital file based on the public key of the other signing participants, so that the other signing participants, in response to the obtained encrypted target digital file, decrypt the encrypted target digital file based on their private key and sign the decrypted target digital file.

[0203] Please refer to Figure 8 , Figure 8 This is a block diagram illustrating an exemplary embodiment of a blockchain-based digital document signing device.

[0204] The aforementioned blockchain-based digital document signing device can be applied to systems such as... Figure 6 The electronic device shown has a client corresponding to the signing party; the target digital file to be signed is encrypted and stored in a blockchain; and a first smart contract for signing and managing the target digital file is deployed on the blockchain.

[0205] The aforementioned blockchain-based digital document signing device may include:

[0206] The acquisition module 801 acquires the encrypted target digital file; wherein, the encrypted target digital file is obtained by the signing initiator when, in response to the signing processing operation initiated by the signing initiator for the target digital file, other signing participants are identified, and the decryption logic contained in the first smart contract is invoked to decrypt the encrypted target digital file stored in the blockchain; and in response to the completion of the decryption processing of the target digital file, the encryption logic contained in the first smart contract is further invoked to encrypt the decrypted target digital file based on the public keys of the other signing participants.

[0207] The decryption module 802, in response to obtaining the encrypted target digital file, decrypts the encrypted target digital file based on the private keys of the other signing participants;

[0208] The signing module 803 performs signing processing on the decrypted target digital file.

[0209] Please refer to Figure 9 , Figure 9 This is a block diagram illustrating another blockchain-based digital document signing device in an exemplary embodiment of this specification.

[0210] The aforementioned blockchain-based digital document signing device can be applied to systems such as... Figure 6 The electronic device shown is equipped with a blockchain service platform; the target digital file to be signed is encrypted and stored in the blockchain; a first smart contract for signing and managing the target digital file is deployed on the blockchain.

[0211] The aforementioned blockchain-based digital document signing device may include:

[0212] The receiving module 901 receives a signing request sent by the client corresponding to the signing initiator in response to the signing processing operation initiated by the signing initiator for the target digital file;

[0213] The determining module 902, in response to the signing request, determines other signing participants involved in signing the target digital document;

[0214] Module 903, in response to the identified other signing participants, invokes the decryption logic contained in the first smart contract to decrypt the encrypted target digital file stored in the blockchain; and, in response to the completion of the decryption of the target digital file, further invokes the encryption logic contained in the first smart contract to encrypt the decrypted target digital file based on the public key of the other signing participants, so that the other signing participants, in response to the obtained encrypted target digital file, decrypt the encrypted target digital file based on their private key and sign the decrypted target digital file.

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

[0216] The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the technical solution in this specification, depending on actual needs.

[0217] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

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

[0219] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0220] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0221] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0222] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0223] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this specification. The singular forms “a,” “described,” and “the” used in one or more embodiments of this specification and in the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0224] It should be understood that although the terms first, second, third, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first information may also be referred to as second information without departing from the scope of one or more embodiments of this specification, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "in response to a determination," or "when," or "in the event of a determination."

[0225] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the protection scope of one or more embodiments of this specification.

Claims

1. A blockchain-based digital document signing method, applied to a client corresponding to the signing initiator; a first smart contract for signing and managing the target digital document is deployed on the blockchain; The target digital file to be signed is encrypted using a symmetric key corresponding to the first smart contract and then stored in the blockchain; the method includes: In response to the signing process initiated by the signing initiator for the target digital document, other signing participants who participated in signing the target digital document are identified; In response to the identified other signing parties, the decryption logic contained in the first smart contract is invoked to decrypt the encrypted target digital file stored in the blockchain based on the symmetric key corresponding to the first smart contract; and, In response to the completion of the decryption of the target digital file, the encryption logic contained in the first smart contract is further invoked to encrypt the decrypted target digital file based on the public key of the other signing participants. This enables the other signing participants to decrypt the encrypted target digital file based on their private keys in response to the obtained encrypted target digital file, and to sign the decrypted target digital file.

2. The method according to claim 1, wherein the first smart contract is deployed in a TEE mounted on a node device in the blockchain; the TEE maintains a symmetric key corresponding to the first smart contract; The process of decrypting the encrypted target digital file stored in the blockchain based on the symmetric key corresponding to the first smart contract includes: In the TEE, the encrypted target digital file stored in the blockchain is decrypted based on the symmetric key corresponding to the first smart contract maintained in the TEE. The encryption process of the decrypted target digital file based on the public keys of the other signing parties includes: The decrypted target digital file is encrypted using the public keys of the other signing parties in the TEE.

3. The method according to claim 1, wherein encrypting the decrypted target digital file based on the public key of the other signing participants, so that the other signing participants, in response to the obtained encrypted target digital file, decrypt the encrypted target digital file based on the private key of the other signing participants, and sign the decrypted target digital file, comprises: The decrypted target digital file is encrypted using the public keys of the other signing participants, and a signing event for the target digital file is generated by the other signing participants. The signing event is stored in the blockchain, wherein the signing event includes the encrypted target digital file, so that the other signing participants can obtain the signing event from the blockchain. In response to the signing event, the encrypted target digital file is decrypted using the private keys of the other signing participants, and the decrypted target digital file is signed.

4. The method according to claim 3, wherein a second smart contract for signing the target digital document based on the digital seals of the other signing participants is further deployed on the blockchain; The decrypted target digital file is encrypted using the public keys of the other signing participants, and a signing event for the target digital file by the other signing participants is generated. This signing event is then stored in the blockchain. The signing event includes the encrypted target digital file, enabling other signing participants to obtain the signing event from the blockchain. In response to the signing event, the encrypted target digital file is decrypted based on the private keys of the other signing participants, and the decrypted target digital file is then signed, including: The decrypted target digital file is encrypted using the public keys of the other signing participants, and a signing event for the target digital file is generated by the other signing participants. The signing event is stored in the blockchain, whereby the signing event includes the encrypted target digital file. This allows the other signing participants to retrieve the signing event from the blockchain. In response to the signing event, the encrypted target digital file is decrypted using the private keys of the other signing participants, and authorization information for signing the target digital file based on the digital seals of the other signing participants is generated. The authorization information is then signed using the private keys of the other signing participants. The decrypted target digital file and the signed authorization information are submitted as calling parameters to the second smart contract to invoke the signing logic contained in the second smart contract. The signature of the authorization information is verified using the public keys of the other signing participants, and upon successful verification, the decrypted target digital file is signed using the digital seals of the other signing participants to complete the signing process of the target digital file.

5. The method according to claim 1, wherein a second smart contract for signing the target digital document based on the digital seals of the other signing participants is further deployed on the blockchain; The step of encrypting the decrypted target digital file based on the public key of the other signing participants, so that the other signing participants, in response to the obtained encrypted target digital file, decrypt the encrypted target digital file based on their private keys, and sign the decrypted target digital file, includes: The decrypted target digital file is encrypted using the public keys of the other signing participants, and authorization information for signing the target digital file is generated based on the digital seals of the other signing participants. The private keys stored in trust by the other signing participants are obtained, and the authorization information is signed using the private keys. The encrypted target digital file and the signed authorization information are submitted to the second smart contract as call parameters for cross-contract calls. This allows for cross-contract calls to the signing logic contained in the second smart contract. The private keys stored in trust by the other signing participants are obtained, and the encrypted target digital file is decrypted using the private keys. The signature of the authorization information is verified using the public keys of the other signing participants, and after successful verification, the decrypted target digital file is signed using the digital seals of the other signing participants to complete the signing process of the target digital file.

6. The method according to claim 1, wherein the other signing parties include a plurality of signing parties.

7. The method according to claim 1, wherein the target digital file includes an electronic contract.

8. A blockchain-based digital document signing method, applied to a client corresponding to the signing participants; a first smart contract for signing and managing the target digital document is deployed on the blockchain; The target digital file to be signed is encrypted using a symmetric key corresponding to the first smart contract and then stored in the blockchain; the method includes: The encrypted target digital file is obtained by the signing initiator when, in response to the signing process operation initiated by the signing initiator for the target digital file, other signing participants are identified. The signing initiator then calls the decryption logic contained in the first smart contract to decrypt the encrypted target digital file stored in the blockchain based on the symmetric key corresponding to the first smart contract. Upon completion of the decryption of the target digital file, the signing initiator further calls the encryption logic contained in the first smart contract to encrypt the decrypted target digital file based on the public keys of the other signing participants. In response to obtaining the encrypted target digital file, the encrypted target digital file is decrypted based on the private keys of the other signing participants; The decrypted target digital file is then signed.

9. The method according to claim 8, wherein obtaining the encrypted target digital file comprises: Obtain the signing events of the other signing participants for the target digital file from the blockchain; wherein the signing events are generated by the signing initiator and stored in the blockchain; the signing events include the encrypted target digital file.

10. The method according to claim 8, wherein a second smart contract for signing the target digital document based on the digital seals of the other signing participants is further deployed on the blockchain; The signing process for the decrypted target digital file includes: Generate authorization information for signing the target digital file based on the digital seals of the other signing participants, and sign the authorization information based on the private keys of the other signing participants; The decrypted target digital file and the signed authorization information are submitted to the second smart contract as calling parameters to invoke the signing logic contained in the second smart contract. The signature of the authorization information is verified based on the public key of the other signing participants, and after the verification is successful, the decrypted target digital file is signed based on the digital seal of the other signing participants to complete the signing process of the target digital file.

11. A blockchain-based digital document signing method, applied to a blockchain service platform; a first smart contract for signing and managing target digital documents is deployed on the blockchain; The target digital file to be signed is encrypted using a symmetric key corresponding to the first smart contract and then stored in the blockchain; the method includes: Receive a signing request sent by the client corresponding to the signing initiator in response to the signing processing operation initiated by the signing initiator for the target digital file; In response to the signing request, other signing parties involved in signing the target digital document are identified; In response to the identified other signing parties, the decryption logic contained in the first smart contract is invoked to decrypt the encrypted target digital file stored in the blockchain based on the symmetric key corresponding to the first smart contract; and, In response to the completion of the decryption of the target digital file, the encryption logic contained in the first smart contract is further invoked to encrypt the decrypted target digital file based on the public key of the other signing participants. This enables the other signing participants to decrypt the encrypted target digital file based on their private keys in response to the obtained encrypted target digital file, and to sign the decrypted target digital file.

12. The method according to claim 11, wherein the first smart contract is deployed in a TEE mounted on a node device in the blockchain; the TEE maintains a symmetric key corresponding to the first smart contract; The process of decrypting the encrypted target digital file stored in the blockchain based on the symmetric key corresponding to the first smart contract includes: In the TEE, the encrypted target digital file stored in the blockchain is decrypted based on the symmetric key corresponding to the first smart contract maintained in the TEE. The encryption process of the decrypted target digital file based on the public keys of the other signing parties includes: The decrypted target digital file is encrypted using the public keys of the other signing parties in the TEE.

13. The method according to claim 11, wherein encrypting the decrypted target digital file based on the public key of the other signing participants, so that the other signing participants, in response to the obtained encrypted target digital file, decrypt the encrypted target digital file based on the private key of the other signing participants, and sign the decrypted target digital file, comprises: The decrypted target digital file is encrypted using the public keys of the other signing participants, and a signing event for the target digital file is generated by the other signing participants. The signing event is stored in the blockchain, wherein the signing event includes the encrypted target digital file, so that the other signing participants can obtain the signing event from the blockchain. In response to the signing event, the encrypted target digital file is decrypted using the private keys of the other signing participants, and the decrypted target digital file is signed.

14. The method according to claim 13, wherein a second smart contract for signing the target digital document based on the digital seals of the other signing participants is further deployed on the blockchain; The decrypted target digital file is encrypted using the public keys of the other signing participants, and a signing event for the target digital file by the other signing participants is generated. This signing event is then stored in the blockchain. The signing event includes the encrypted target digital file, enabling other signing participants to obtain the signing event from the blockchain. In response to the signing event, the encrypted target digital file is decrypted based on the private keys of the other signing participants, and the decrypted target digital file is then signed, including: The decrypted target digital file is encrypted using the public keys of the other signing participants, and a signing event for the target digital file is generated by the other signing participants. The signing event is stored in the blockchain, whereby the signing event includes the encrypted target digital file. This allows the other signing participants to retrieve the signing event from the blockchain. In response to the signing event, the encrypted target digital file is decrypted using the private keys of the other signing participants, and authorization information for signing the target digital file based on the digital seals of the other signing participants is generated. The authorization information is then signed using the private keys of the other signing participants. The decrypted target digital file and the signed authorization information are submitted as calling parameters to the second smart contract to invoke the signing logic contained in the second smart contract. The signature of the authorization information is verified using the public keys of the other signing participants, and upon successful verification, the decrypted target digital file is signed using the digital seals of the other signing participants to complete the signing process of the target digital file.

15. The method according to claim 11, wherein a second smart contract for signing the target digital document based on the digital seals of the other signing participants is further deployed on the blockchain; The step of encrypting the decrypted target digital file based on the public key of the other signing participants, so that the other signing participants, in response to the obtained encrypted target digital file, decrypt the encrypted target digital file based on their private keys, and sign the decrypted target digital file, includes: The decrypted target digital file is encrypted using the public keys of the other signing participants, and authorization information for signing the target digital file is generated based on the digital seals of the other signing participants. The private keys stored in trust by the other signing participants are obtained, and the authorization information is signed using the private keys. The encrypted target digital file and the signed authorization information are submitted to the second smart contract as call parameters for cross-contract calls. This allows for cross-contract calls to the signing logic contained in the second smart contract. The private keys stored in trust by the other signing participants are obtained, and the encrypted target digital file is decrypted using the private keys. The signature of the authorization information is verified using the public keys of the other signing participants, and after successful verification, the decrypted target digital file is signed using the digital seals of the other signing participants to complete the signing process of the target digital file.

16. The method of claim 11, wherein the other signing parties include a plurality of signing parties.

17. The method of claim 11, wherein the target digital file comprises an electronic contract.

18. A blockchain-based digital document signing device, applied to a client corresponding to the signing initiator; a first smart contract for signing and managing the target digital document is deployed on the blockchain; The target digital document to be signed is encrypted using a symmetric key corresponding to the first smart contract and then stored in the blockchain; the device includes: The determination module, in response to the signing processing operation initiated by the signing initiator for the target digital document, determines other signing participants who will participate in signing the target digital document; The module invokes, in response to the identified other signing participants, the decryption logic contained in the first smart contract to decrypt the encrypted target digital file stored in the blockchain based on the symmetric key corresponding to the first smart contract; and, in response to the completion of the decryption of the target digital file, further invokes the encryption logic contained in the first smart contract to encrypt the decrypted target digital file based on the public key of the other signing participants, so that the other signing participants, in response to the obtained encrypted target digital file, decrypt the encrypted target digital file based on their private key and sign the decrypted target digital file.

19. A blockchain-based digital document signing device, applied to a client corresponding to the signing participants; a first smart contract for signing and managing the target digital document is deployed on the blockchain; The target digital document to be signed is encrypted using a symmetric key corresponding to the first smart contract and then stored in the blockchain; the device includes: The acquisition module acquires the encrypted target digital file; wherein, the encrypted target digital file is obtained by the signing initiator when, in response to the signing processing operation initiated by the signing initiator for the target digital file, other signing participants are identified, and the decryption logic contained in the first smart contract is invoked to decrypt the encrypted target digital file stored in the blockchain based on the symmetric key corresponding to the first smart contract. Upon completion of the decryption of the target digital file, the encryption logic contained in the first smart contract is further invoked to encrypt the decrypted target digital file based on the public keys of the other signing participants. The decryption module, in response to obtaining the encrypted target digital file, decrypts the encrypted target digital file based on the private keys of the other signing participants; The signing module performs signing processing on the decrypted target digital file.

20. A blockchain-based digital document signing device, applied to a blockchain service platform; a first smart contract for signing and managing target digital documents is deployed on the blockchain; The target digital document to be signed is encrypted using a symmetric key corresponding to the first smart contract and then stored in the blockchain; the device includes: The receiving module receives a signing request sent by the client corresponding to the signing initiator in response to the signing processing operation initiated by the signing initiator for the target digital file; The determination module, in response to the signing request, determines other signing participants involved in signing the target digital document; The module invokes, in response to the identified other signing participants, the decryption logic contained in the first smart contract to decrypt the encrypted target digital file stored in the blockchain based on the symmetric key corresponding to the first smart contract; and, in response to the completion of the decryption of the target digital file, further invokes the encryption logic contained in the first smart contract to encrypt the decrypted target digital file based on the public key of the other signing participants, so that the other signing participants, in response to the obtained encrypted target digital file, decrypt the encrypted target digital file based on their private key and sign the decrypted target digital file.

21. An electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 1-17 by executing the executable instructions.

22. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the method as described in any one of claims 1-17.