Database Transaction Guaranteed Commitment

1. A system, comprising: a committer node in a blockchain network, the committer node storing a smart contract, the committer node configured to: receive a blockchain transaction including a lock request to lock a partial state of the smart contract, the lock request including a submitter identifier and a lock delay; validate the lock request; commit a blockchain block including the submitter identifier to a blockchain, of the blockchain network, after the lock delay; and commit a blockchain block not including the submitter identifier to the blockchain with no delay.

2. The system of claim 1 , wherein the lock request further comprises: a smart contract identifier and one or more keys, and wherein the lock delay comprises a number of blocks or a period of time.

3. The system of claim 2 , wherein, when the committer node validates the lock request, the committer node is further configured to: verify with the one or more keys that the lock request was submitted by a valid client or node of the blockchain network; verify that the smart contract identifier matches the stored smart contract identifier; verify that the submitter identifier applies to a client or node allowed to submit a lock request for the smart contract; identify any other active lock requests currently active for the smart contract; and reject the lock request if an active lock request is identified.

4. The system of claim 1 , wherein the committer node is further configured to: commit the blockchain transaction to the blockchain without further validation, in response to the committer node not identifying an active lock request; invalidate and do not commit the blockchain transaction, in response to the blockchain transaction being submitted by a node or peer that does not match the submitter identifier; and commit the blockchain transaction to the blockchain block, in response to an active lock request being submitted by a node or peer that matches the submitter identifier.

5. The system of claim 1 , wherein the committer node is further configured to: upgrade a previous lock request in response to the submitter identifier matching a submitter identifier for the previous lock request, and reject the lock request in response to the submitter identifier not matching the submitter identifier for the previous lock request.

6. The system of claim 1 , wherein the committer node is further configured to: release a lock associated with the lock request after one of: the blockchain transaction is committed to the blockchain, or the blockchain transaction includes an instruction to release the lock.

7. The system of claim 1 , wherein the lock request expires in response to one of: an expiration of time period, or a number of blocks the lock request is active within the lock request.

8. A method, comprising: receiving, by a committer node a blockchain network, a blockchain transaction including a lock request that locks a partial state of a smart contract, the lock request comprising a submitter identifier and a lock delay, the method further comprising: validating the lock request; committing a blockchain block including the submitter identifier to a blockchain, of the blockchain network, after the lock delay; and committing a blockchain block not including the submitter identifier to the blockchain with no after the lock delay.

9. The method of claim 8 , wherein the lock request further comprises: a smart contract identifier and one or more keys, and wherein the lock delay comprises a number of blocks or a period of time.

10. The method of claim 9 , wherein the validating the lock request comprises: verifying using the one or more keys, by the committer node or peer, that the lock request was submitted by a valid client or node of the blockchain network; verifying that the smart contract identifier matches a stored smart contract identifier for the smart contract; verifying that the submitter identifier applies to a client or node allowed to submit a lock request for the smart contract; identifying any other active lock requests currently active for the smart contract; and rejecting the lock request if an active lock request is identified.

11. The method of claim 8 , further comprising: committing the blockchain transaction to the block without further validating, in response to the committer node not identifying an active lock request; invalidating and not committing the blockchain transaction, in response to the blockchain transaction being submitted by a node or peer that does not match the submitter identifier; and committing the blockchain transaction to the blockchain block, in response to an active lock request being submitted by a node or peer that matches the submitter identifier.

12. The method of claim 8 , further comprising: upgrading a previous lock request in response to the submitter identifier matching a submitter identifier for the previous lock request; and rejecting the lock request in response to the submitter identifier not matching the submitter identifier for the previous lock request.

13. The method of claim 8 , further comprising: releasing the lock request in response to one of: committing the blockchain transaction to the blockchain; or the blockchain transaction including an instruction to release the lock.

14. The method of claim 8 , wherein the lock request expires in response to one of: an expiration of time period, or a number of blocks the lock request is active within the lock request.

15. A non-transitory computer readable medium configured to store one or more instructions that when executed read by a processor of a committer node of a blockchain network cause the processor to perform: receiving a blockchain transaction including a lock request that locks a partial state of a smart contract, the lock request comprising a submitter identifier and a lock delay; validating the lock request; committing a blockchain block including the submitter identifier to a blockchain, of the blockchain network, after the lock delay; and committing a blockchain block not including the submitter identifier to the blockchain with no after the lock delay.

16. The non-transitory computer readable medium of claim 15 , wherein the lock request further comprises: a smart contract identifier and one or more keys, and wherein the lock delay comprises a number of blocks or a period of time.

17. The non-transitory computer readable medium of claim 16 , wherein the validating the lock request comprises: verifying using the one or more keys, by the committer node or peer, that the lock request was submitted by a valid client or node of the blockchain network; verifying that the smart contract identifier matches a stored smart contract identifier for the smart contract; verifying that the submitter identifier applies to a client or node allowed to submit a lock request for the smart contract; identifying any other active lock requests currently active for the smart contract; and rejecting the lock request if an active lock request is identified.

18. The non-transitory computer readable medium of claim 15 , wherein the one or more instructions further cause the processor to perform: committing the blockchain transaction to the block without further validating, in response to the committer node not identifying an active lock request; invalidating and not committing the blockchain transaction, in response to the blockchain transaction being submitted by a node or peer that does not match the submitter identifier; and committing the blockchain transaction to the blockchain block, in response to an active lock request being submitted by a node or peer that matches the submitter identifier.

19. The non-transitory computer readable medium of claim 15 , wherein the one or more instructions further cause the processor to perform: upgrading a previous lock request in response to the submitter identifier matching a submitter identifier for the previous lock request; and rejecting the lock request in response to the submitter identifier not matching the submitter identifier for the previous lock request.

20. The non-transitory computer readable medium of claim 15 , wherein the lock request expires in response to one of: an expiration of time period, or a number of blocks the lock request is active within the lock request, and wherein the one or more instructions further cause the processor to perform: releasing the lock request in response to one of: committing the blockchain transaction to the blockchain; or the blockchain transaction including an instruction to release the lock.