Invoice access method and apparatus based on blockchain, and electronic device

1. A method based on a blockchain, comprising:

receiving a creation request initiated by a creation user for a target invoice through a client of the creation user;

determining an invoice issuer and an invoice receiver of the target invoice in response to the creation request;

invoking an encryption logic provided in a smart contract to separately encrypt plaintext data of the target invoice based on keys corresponding to the invoice issuer and the invoice receiver, and adding encrypted ciphertext data of the target invoice and user identifiers of the invoice issuer and the invoice receiver of the target invoice to the blockchain;

receiving an access request initiated by an access user for accessing the target invoice through a client of the access user;

determining, in response to the access request, whether the access user has an authority to access the target invoice; and

in response to the access user having the authority to access the target invoice, invoking a decryption logic provided in the smart contract to decrypt the ciphertext data of the target invoice stored in the blockchain, and returning decrypted plaintext data of the target invoice to the client.

2. The method according to claim 1 , wherein:

the smart contract provides an access authority verification logic for the access user; and

the determining whether the access user has the authority to access the target invoice includes:

invoking the access authority verification logic provided in the smart contract to determine whether the access user has the authority to access the target invoice.

3. The method according to claim 1 , wherein the separately encrypting the plaintext data of the target invoice based on the keys corresponding to the invoice issuer and the invoice receiver includes:

encrypting plaintext data of the target invoice based on a first key corresponding to the invoice issuer to obtain first ciphertext data;

encrypting the plaintext data of the target invoice based on a second key corresponding to the invoice receiver to obtain second ciphertext data; and

the adding the encrypted ciphertext data of the target invoice and the user identifiers of the invoice issuer and the invoice receiver of the target invoice to the blockchain for storage includes:

adding a corresponding relationship between the first ciphertext data and a user identifier of the invoice issuer to the blockchain for storage; and

adding a corresponding relationship between the second ciphertext data and a user identifier of the invoice receiver to the blockchain for storage.

4. The method according to claim 1 , wherein:

the access request includes a user identifier of the access user; and

the determining whether the access user has the authority to access the target invoice includes:

obtaining the user identifiers of the invoice issuer and the invoice receiver of the target invoice;

determining whether the user identifier of the access user matches at least one of the user identifiers of the invoice issuer or the invoice receiver; and

in response to that the user identifier of the access user matching at least one of the user identifiers of the invoice issuer or the invoice receiver, determining that the access user has the authority to access the target invoice.

5. The method according to claim 1 , wherein the decrypting the ciphertext data of the target invoice stored in the blockchain includes:

decrypting, based on a key corresponding to the access user, the ciphertext data of the target invoice stored in the blockchain.

6. The method according to claim 1 , wherein:

the smart contract further provides a key distribution logic; and

the method comprises:

receiving a registration request initiated by a user by using a client; and

invoking the key distribution logic in the smart contract in response to the registration request, and writing a corresponding relationship between a user identifier of the user and a key distributed to the user into the smart contract.

7. An electronic device, comprising:

a processor; and

a memory storing machine-executable instructions,

wherein by reading and executing the machine-executable instructions that are stored in the memory, the processor is enabled to implement acts including:

receiving a creation request initiated by a creation user for a target invoice through a client of the creation user;

determining an invoice issuer and an invoice receiver of the target invoice in response to the creation request; and

separately encrypting plaintext data of the target invoice based on keys corresponding to the invoice issuer and the invoice receiver, and adding encrypted ciphertext data of the target invoice and user identifiers of the invoice issuer and the invoice receiver of the target invoice to a blockchain;

receiving an access request initiated by an access user for accessing the target invoice through a client of the access user;

determining, in response to the access request, whether the access user has an authority to access the target invoice; and

in response to the access user having the authority to access the target invoice, decrypting the ciphertext data of the target invoice stored in the blockchain, and returning decrypted plaintext data of the target invoice to the client.

8. The electronic device according to claim 7 , wherein

the determining whether the access user has the authority to access the target invoice includes:

invoking a smart contract to determine whether the access user has the authority to access the target invoice.

9. The electronic device according to claim 7 , wherein the separately encrypting the plaintext data of the target invoice based on the keys corresponding to the invoice issuer and the invoice receiver includes:

encrypting plaintext data of the target invoice based on a first key corresponding to the invoice issuer to obtain first ciphertext data;

encrypting the plaintext data of the target invoice based on a second key corresponding to the invoice receiver to obtain second ciphertext data; and

the adding the encrypted ciphertext data of the target invoice and the user identifiers of the invoice issuer and the invoice receiver of the target invoice to the blockchain for storage includes:

adding a corresponding relationship between the first ciphertext data and a user identifier of the invoice issuer to the blockchain for storage; and

adding a corresponding relationship between the second ciphertext data and a user identifier of the invoice receiver to the blockchain for storage.

10. The electronic device according to claim 7 , wherein:

the access request includes a user identifier of the access user; and

the determining whether the access user has the authority to access the target invoice includes:

obtaining the user identifiers of the invoice issuer and the invoice receiver of the target invoice;

determining whether the user identifier of the access user matches at least one of the user identifiers of the invoice issuer or the invoice receiver; and

in response to the user identifier of the access user matching at least one of the user identifiers of the invoice issuer or the invoice receiver, determining that the access user has the authority to access the target invoice.

11. The electronic device according to claim 7 , wherein the decrypting the ciphertext data of the target invoice stored in the blockchain includes:

decrypting, based on a key corresponding to the access user, the ciphertext data of the target invoice stored in the blockchain.

12. The electronic device according to claim 7 , wherein:

the acts include:

receiving a registration request initiated by a user by using a client; and

in response to the registration request, invoking a smart contract to distribute a key to the user and writing a corresponding relationship between a user identifier of the user and the key distributed to the user into the smart contract.

13. A non-transitory computer-readable storage medium storing computer-executable instructions, which when executed by a processor, configure the processor to implement acts including:

receiving a creation request initiated by a creation user for a target invoice through a client of the creation user;

determining an invoice issuer and an invoice receiver of the target invoice in response to the creation request; and

invoking an encryption logic provided in a smart contract to separately encrypt plaintext data of the target invoice based on keys corresponding to the invoice issuer and the invoice receiver, and adding encrypted ciphertext data of the target invoice and user identifiers of the invoice issuer and the invoice receiver of the target invoice to a blockchain;

receiving an access request initiated by an access user for accessing the target invoice through a client of the access user;

determining, in response to the access request, whether the access user has an authority to access the target invoice; and

in response to the access user having the authority to access the target invoice, invoking a decryption logic provided in the smart contract to decrypt the ciphertext data of the target invoice stored in the blockchain, and returning decrypted plaintext data of the target invoice to the client.

14. The non-transitory computer-readable storage medium according to claim 13 , wherein:

the smart contract provides an access authority verification logic for the access user; and

the determining whether the access user has the authority to access the target invoice includes:

invoking the access authority verification logic provided in the smart contract to determine whether the access user has the authority to access the target invoice.

15. The non-transitory computer-readable storage medium according to claim 13 , wherein the separately encrypting the plaintext data of the target invoice based on the keys corresponding to the invoice issuer and the invoice receiver includes:

encrypting plaintext data of the target invoice based on a first key corresponding to the invoice issuer to obtain first ciphertext data;

encrypting the plaintext data of the target invoice based on a second key corresponding to the invoice receiver to obtain second ciphertext data; and

the adding the encrypted ciphertext data of the target invoice and the user identifiers of the invoice issuer and the invoice receiver of the target invoice to the blockchain for storage includes:

adding a corresponding relationship between the first ciphertext data and a user identifier of the invoice issuer to the blockchain for storage; and

adding a corresponding relationship between the second ciphertext data and a user identifier of the invoice receiver to the blockchain for storage.

16. The non-transitory computer-readable storage medium according to claim 13 , wherein:

the access request includes a user identifier of the access user; and

the determining whether the access user has the authority to access the target invoice includes:

obtaining the user identifiers of the invoice issuer and the invoice receiver of the target invoice;

determining whether the user identifier of the access user matches at least one of the user identifiers of the invoice issuer or the invoice receiver; and

in response to the user identifier of the access user matching at least one of the user identifiers of the invoice issuer or the invoice receiver, determining that the access user has the authority to access the target invoice.

17. The non-transitory computer-readable storage medium according to claim 13 , wherein the decrypting the ciphertext data of the target invoice stored in the blockchain includes:

decrypting, based on a key corresponding to the access user, the ciphertext data of the target invoice stored in the blockchain.

18. The non-transitory computer-readable storage medium according to claim 13 , wherein:

the smart contract further provides a key distribution logic; and

the acts include:

receiving a registration request initiated by a user by using a client; and

invoking the key distribution logic in the smart contract in response to the registration request, and writing a corresponding relationship between a user identifier of the user and a key distributed to the user into the smart contract.