Blockchain-based method and system for providing tenant security and compliance in a cloud computing environment

1. A method for enforcing smart contracts, comprising:

receiving a first proposed block comprising a first proposed block header and a first proposed transaction set, wherein the first proposed transaction comprises a first contract execution transaction (CET) that comprises a first encoded contract function call (CFC);

making a first determination, based on a performing of a block validation process on the first proposed block, that the first proposed block is valid;

committing, based on the first determination, the first proposed block into a local blockchain copy (LBC);

in response to committing the first proposed block, executing the first CFC to obtain a data query response (DQR), wherein the DQR comprises security level audit information; and

enforcing a smart contract based at least on the security level audit information,

wherein enforcing the smart contract based at least on the security level audit information, comprises:

obtaining a contract address specified in the first CET;

identifying a smart contract account associated with the contract address, wherein the smart contract is associated with the smart contract account;

retrieving, from the smart contract account, a contract token balance (CTB) specified therein;

making a second determination, based at least on the security level audit information, that a security level selection (SLS) has been applied correctly or incorrectly;

generating, based on the second determination, a token transfer transaction (TTT) using at least a security level provider (CSP) address, the CTB, and a transaction fee;

signing, using a user private key, the TTT to obtain a digital signature;

generating a transaction package using at least the TTT and the digital signature; and

broadcasting the transaction package to a set of peer blockchain nodes in a blockchain network.

2. The method of claim 1 , wherein a first CFC is an expression that passes control and a set of arguments to a subroutine of the smart contract, wherein the encoded CFC is a hexadecimal encoding of the first CFC.

3. The method of claim 1 , wherein performing of the block validation process on the first proposed block, comprises:

extracting, from the first proposed block header, a target criterion for the first proposed block;

hashing at least a portion of the first proposed block header to obtain a proposed block hash;

making a second determination that the proposed block hash satisfies the target criterion; and

identifying, based on the second determination, the first proposed block as valid.

4. The method of claim 1 , wherein the security level audit information is assessment information regarding an application of at least one security level from a security level provider (CSP) to a security level requestor (CSR).

5. The method of claim 4 , wherein the smart contract comprises a contractual term negotiated between the CSP and the CSR, wherein the contractual term is implemented as a subroutine that uses at least the security level audit information to enforce the contractual term.

6. The method of claim 1 , wherein making the second determination that the SLS has been applied correctly, comprises:

obtaining the SLS specified in the smart contract;

obtaining security level assessment (SLA) detailed in the security level audit information;

making a third determination that the SLA matches the SLS; and

making the second determination based on the third determination.

7. The method of claim 1 , wherein the transaction package is further generated using a user public key.

8. The method of claim 1 , wherein the second determination determines that the SLS has been applied correctly, and further comprising:

receiving a second proposed block comprising a second proposed block header and a second proposed transaction set, wherein the second proposed transaction set comprises the TTT;

making a third determination, based on the performing of the block validation process on the second proposed block, that the second proposed block is valid;

committing, based on the third determination, the second proposed block into the LBC; and

in response to committing the second proposed block, executing the TTT to trigger a recompense action.

9. The method of claim 8 , wherein the recompense action comprises transferring the CTB to a network user account associated with a CSP, wherein the CSP address is directed to the network user account.

10. The method of claim 1 , wherein making the second determination that the SLS has been applied incorrectly, comprises:

obtaining the SLS specified in the smart contract;

obtaining security level assessment (SLA) detailed in the security level audit information;

making a third determination that the SLA mismatches the SLS; and

making the second determination based on the third determination.

11. The method of claim 1 , wherein the second determination determines that the SLS has been applied incorrectly, and further comprising:

receiving a second proposed block comprising a second proposed block header and a second proposed transaction set, wherein the second proposed transaction set comprises the TTT;

making a third determination, based on the performing of the block validation process on the second proposed block, that the second proposed block is valid;

committing, based on the third determination, the second proposed block into the LBC; and

in response to committing the second proposed block, executing the TTT to trigger a remedial action.

12. The method of claim 11 , wherein the remedial action comprises transferring the CTB to a network user account associated with a CSR, wherein the CSR address is directed to the network user account.

13. A blockchain network, comprising:

a plurality of blockchain nodes comprising a first blockchain node comprising a processor and a memory and apprising a first role as a security level provider (CSP) and a second blockchain node comprising a second processor and apprising a second role as a data feed service (DFS), wherein the first blockchain node is programmed to:

receive, broadcasted from the second blockchain node, a first proposed block comprising a first proposed block header and a first proposed transaction set, wherein the first proposed transaction comprises a first contract execution transaction (CET) that comprises a first encoded contract function call (CFC);

make a first determination, based on a performing of a block validation process on the first proposed block, that the first proposed block is valid;

commit, based on the first determination, the first proposed block into a local blockchain copy (LBC) residing on the first blockchain node; in response to committing the first proposed block, execute the first CFC to obtain a data query response (DQR), wherein the DQR comprises security level audit information; and

enforce a smart contract based at least on the security level audit information wherein enforcing the smart contract based at least on the security level audit information, comprises:

obtaining a contract address specified in the first CET;

identifying a smart contract account associated with the contract address;

wherein the smart contract is associated with the smart contract account;

retrieving, from the smart contract account, a contract token balance (CTB) specified therein; making a second determination, based at least on the security level audit information, that a security level selection (SLS) has been applied correctly or incorrectly;

generating, based on the second determination, a token transfer transaction (TTT) using at least a security level provider (CSP) address, the CTB, and a transaction fee;

signing, using a user private key, the TTT to obtain a digital signature; generating a transaction package using at least the TTT and the digital signature; and broadcasting the transaction package to a set of peer blockchain nodes in a blockchain network.

14. The blockchain network of claim 13 , further comprising:

a third blockchain node, in the blockchain network, apprising a third role as a security level requestor (CSR),

wherein enforcing the smart contract triggers a remedial action directed to the CSR.

15. The blockchain network of claim 13 , further comprising:

a third blockchain node, in the blockchain network, apprising a third role as a blockchain block generator (BBG).

16. The blockchain network of claim 13 , wherein the first blockchain node comprises protection measures for implementing at least one security level, wherein each protection measure is one selected from a group consisting of a preventative production measure and a reactive protection measure.

17. The blockchain network of claim 16 , wherein the at least one security level is at least one selected from a group consisting of a data level security (DLS), a virtualization level security (VLS), a management level security (MLS), a network level security (NLS), and an infrastructure level security (ILS).

18. A non-transitory computer readable medium (CRM) comprising computer readable program code, which when executed by a computer processor, enables the computer processor to:

receive a first proposed block comprising a first proposed block header and a first proposed transaction set, wherein the first proposed transaction comprises a first contract execution transaction (CET) that comprises a first encoded contract function call (CFC);

make a first determination, based on a performing of a block validation process on the first proposed block, that the first proposed block is valid;

commit, based on the first determination, the first proposed block into a local blockchain copy (LBC);

in response to committing the first proposed block, execute the first CFC to obtain a data query response (DQR), wherein the DQR comprises security level audit information; and

enforce a smart contract based at least on the security level audit information,

wherein enforcing the smart contract based at least on the security level audit information, comprises:

obtaining a contract address specified in the first CET;

identifying a smart contract account associated with the contract address, wherein the smart contract is associated with the smart contract account;

retrieving, from the smart contract account, a contract token balance (CTB) specified therein;

making a second determination, based at least on the security level audit information, that a security level selection (SLS) has been applied correctly or incorrectly;

generating, based on the second determination, a token transfer transaction (TTT) using at least a security level provider (CSP) address, the CTB, and a transaction fee;

signing, using a user private key, the TTT to obtain a digital signature;

generating a transaction package using at least the TTT and the digital signature; and

broadcasting the transaction package to a set of peer blockchain nodes in a blockchain network.