International Business Machines Corporation

Anna D Derbakova

Nitin Gaur

Konstantinos Christidis

Praveen Jayachandran

Srinivasan Muralidharan

Sheehan Anderson

The present disclosure relates to the enforcement of a smart contract execution hierarchy on a blockchain. A method includes receiving a submission of a first smart contract to be appended to a blockchain, comparing a priority value of the first smart contract to a priority value of a second smart contract previously appended to the blockchain, determining based on the comparison that the first smart contract has a lower priority than the second smart contract, comparing the terms of the first smart contract to the terms of the second smart contract, determining at least one of an overlap and a conflict between the terms of the first smart contract and the terms of the second smart contract, resolving any terms of the first smart contract that are determined to overlap or conflict with the terms of the second smart contract, and appending the resolved first smart contract to the blockchain.

Method and apparatus to enforce smart contract execution hierarchy on blockchain

A system, method, and computer program product provides contextual contracts across various enterprise blockchain applications. In an aspect of the present disclosure, a method is disclosed including receiving a contextual contract for addition to a blockchain. The contextual contract includes at least one state dependent term. The method further includes appending a block to the blockchain based on the received contextual contract and in response to appending the block, activating a ledger sensor for the contextual contract. The ledger sensor is configured to monitor at least one of the blockchain and at least one other blockchain for transactions that correspond to the at least one term. The method further includes receiving from the ledger sensor data about transactions that corresponding to the at least one term and finalizing the contextual contract by appending a block to the blockchain based on the received data and the contextual contract.

Using ledger sensors to enable contextual contracts across various enterprise blockchain applications

Operating conditions of a blockchain configuration may be dynamic and change automatically under certain circumstances. One example method of operation may include receiving a blockchain transaction sent from a first blockchain to a second blockchain, identifying an inter-ledger contract between the first blockchain and the second blockchain, receiving an inter-ledger message at the second blockchain from the first blockchain, and determining whether to log the blockchain transaction in the first blockchain or the second blockchain based on the inter-ledger message.

Inter-ledger messaging in a blockchain

Operating conditions of a blockchain configuration may be dynamic and change automatically under certain circumstances. One example method of operation may include one or more of identifying an existing consensus procedure used in an existing blockchain configuration, identifying current metrics associated with the existing blockchain configuration, comparing the current metrics to predefined rules, identifying one or more deviations based on the current metrics being compared to the predefined rules, and changing the existing consensus procedure to a next consensus procedure for a subsequent block in the existing blockchain configuration responsive to identifying the one or more deviations.

Changing an existing blockchain trust configuration

The creation of a private sub-blockchain from a main blockchain is disclosed including receiving a request including a trust requirement and an agility requirement, receiving monitoring data from at least one of a plurality of validator nodes of the main blockchain, the monitoring data generated by monitoring the execution of transactions and the exchange of consensus messages by one or more of the plurality of validator nodes, determining a minimum number of validator nodes required to meet the trust requirement, identifying a subset of the plurality of validator nodes of the main blockchain that meets the agility requirement based on the received monitoring data, the subset containing at least the determined minimum number of validator nodes required to meet the trust requirement, and creating a private sub-blockchain of the main blockchain, the private sub-blockchain including the identified subset of the plurality of validator nodes of the main blockchain.

System and method to dynamically setup a private sub-blockchain based on agility of transaction processing

The system, method, and computer program product described herein provides a built-in feedback mechanism for a blockchain to sanction validator nodes that consistently 'vote' in a manner that does not match the ultimate consensus. The method includes receiving a vote on whether to add a transaction to the blockchain, comparing the vote to a consensus decision on whether to add the transaction to the blockchain, determining based on the comparison that the vote does not match the consensus decision, in response to determining that the vote does not match the consensus decision, incrementing a value associated with the validator node in a feedback registry, determining that the value associated with the validator node is above a predetermined threshold value, and in response to determining that the value associated with the validator node is above the predetermined threshold, proposing a sanction of the validator node to the plurality of validator nodes.

Growing community of inventors

Durham, NC, United States of America

Anna D Derbakova