Invention for Smart contract admission check, fault tolerance in a Blockchain

Invented by Vishal S. Batra, Pralhad D. Deshpande, Praveen Jayachandran, Palanivel A. Kodeswaran, Venkatraman Ramakrishna, Sayandeep Sen, International Business Machines Corp

The International Business Machines Corp invention works as follows

Background for Smart contract admission check, fault tolerance in a Blockchain

In a blockchain-based system, contracts are driven by proof that compliance has been met. This proof can come in the form either of human attestation, or by automated sensors. To ensure that the contract workflow is smooth and avoid future disputes, such proof must be able to provide evidence at a certain level of assurance. Inadequately drafted contract terms that leave room for ambiguity regarding proof levels or providers/attesters can lead to disputes and breaches. In the same way, logistical or mechanical failures in a runtime can lead to inconsistent views, failures of contractual obligations, and legal conflicts.

One example embodiment could include the following: Identifying a metric structure associated with a smartcontract stored in a Blockchain, logging an event that is part of the configuration, determining if the event supports the requirements of smart contracts, and updating smart contract on the Blockchain when the event supports the requirements of smart contracts.

Another example embodiment could include a method that involves at least one of: identifying a Blockchain metric configuration, determining if the metric configuration supports the requirements for a contract, logging the contract on blockchain when the requirements are supported by a contract on the Blockchain, determining if a Smart Contract Policy in the smart Contract matches a System Policy, and updating smart contracts on the Blockchain when the requirements are supported and the smartcontract policy matches the system policy.

Another example embodiment is an apparatus that includes at minimum one of a processor to identify a geometries associated with smart contracts stored in a Blockchain, log an event, determine if a smart-contract policy in the smart Contract matches a System Policy, and update the smart-contract on the Blockchain when the events and smart-contract policy match the system policy.

Another example embodiment could include a non-transitory computer-readable storage medium that stores instructions that, when executed, cause a processor perform at least one: Identifying a metric setup associated with smart contracts stored in a Blockchain, logging an Event, determining if a smartcontract policy in the smart Contract matches a System Policy, and updating smart contracts on the Blockchain when the Smart Contract requirements are supported by the Event and the smartcontract policy matches the System Policy.

It will be clear that the components of the present invention, as shown in the figures, can be placed in many different ways. The following description of the various embodiments of at most one method, apparatus, or system as illustrated in the attached figures is not intended as limiting the scope of the claimed application. It is only representative of some embodiments.

The instant features and structures or characteristics described in this specification can be combined in any way that suits the purposes of one or more embodiments. The usage of phrases like “example embodiments”, “some embodiments”, or similar language throughout this specification indicates that an embodiment could include a specific feature, structure, or characteristic related to the embodiment. The phrases “example embodiments”, “in some embodiments?”, “in other embodiments?”, or any other similar language throughout this specification don’t necessarily refer to the same group. Furthermore, the features, structures, and characteristics described in this specification may be combined in any way that suits the needs of one or more embodiments.

In addition, the term’message’ may be used in the description of embodiments. While the term?message? may have been used to describe embodiments, the application can be applied to any type of network data such as packet, frame, or datagram. The term “message” can also be used. The term “message” can also refer to packet, frame, or datagram. While certain types of signals and messages may be shown in certain embodiments, they are not limited by a particular type of message and the application does not limit itself to that type of signaling.

Example embodiments include an application or software procedure that monitors smart contracts enforced by blockchain so faults can anticipate and be detected before contract terms are executed. A contract can be scan and terms can identified/parsed. Backend system entities such as finance entities and supply chain entities can also be identified and examined prior to deployment on a blockchain. This will allow you to determine if the associated technology is adequate to enforce or support the contractual terms. Monitoring operations at each stage of contract execution may include checking third-party system technology for operational validity and availability. If there is a mismatch between contract terms or another entity, or process, it can be identified by creating an alarm, notification, or alert. This will identify the interested parties (e.g., seller, purchaser, or financer) and remind them that the contract standards have not been met.

Smart contracts are agreements that describe a process or workflow. They also specify terms and obligations that must be fulfilled by certain parties. An event-driven state machine can be used to review contract terms. Parties can record signatures and non-revocable data in a shared ledger. One example is that the delivery of a shipment may be signed by the receiver or a sensor attached with the shipment. To avoid future (and potential) disputes, the proof must be obtained. Contract terms that are not clearly drafted and have varying degrees or proof can lead to disputes and breaches. Inconsistencies in views or failure to comply with contractual obligations can occur due to mechanical or logistical problems.

FIG. 1. illustrates a smart contract lifecycle according to prior art on a blockchain. Referring to FIG. Referring to FIG. It may be deployed 114, as it parallels applications 122 that are running in the blockchain/ledger124. The workflow 116 can include any updates, execution of contract terms, auditing, and monitoring during the contract’s life. Once all terms have been met and the parties have completed the transaction on blockchain, the contract will expire. If an exception/branch condition is raised, which pauses the contract events 119 on the blockchain, the process could be completed 118.

FIG. 2 illustrates an illustration 200 of a smart-contract operating on a blockchain in accordance with example embodiments. Referring to FIG. FIG. 2 shows how a smart contract stored on the blockchain could include a physical infrastructure to support the contract terms, particularly when a purchase is involved. Shipping links 210 could include entities such as an exporter, trucker, or port authority. These are all necessary for exiting a country. The receiving side could be in another country?? They must have a custom’s authority of 222 and an importer business of 224. A blockchain could include any of these entities. Certain “states” may be used to identify the entities. You can use certain?states? to identify where a shipment is located at the moment and who is holding it. An event could include a shipment moving to another location or changing its custody. These events can be identified by the parties or sensors that provide information to them and recorded in the blockchain. Some actions include, but are not limited, a transfer money from one entity or another. For example, a shipment may be received and confirmed by the last shipping link. A transfer of a shipment from the exporter to their possession may be another example. A failure or dispute could include an audit determining that the shipment’s location was incorrectly attested by a possessor. The parties may not be able to fulfill their financial obligations and the contract could need to be suspended until mutual satisfaction (i.e. additional agreements). While there are occasions when a contract change is appropriate, it is important that both parties know the changes before proceeding with any additional terms. Another example is a component that is not reliable or trustworthy and causes an event. This could be a sensor to track a shipment’s location, or an action taken in the case of a recipient or accompanying party. To ensure that the events leading to these actions are within the agreed levels of assurance, it is important to review the contract specification. An extract operation might identify an

FIG. “FIG. Referring to FIG. FIG. 3 shows an example logic 300 that includes a smartcontract being executed along with a blockchain application chain 352, and blockchain contract monitoring, execution 354 and 326. The contract specification 312 is deconstructed 318 and examined 322 to identify the terms and the corresponding events and actions during contract execution. Contrary to FIG. In one embodiment, if errors, problems, or inconsistencies are identified 314, then the contract can be brought before the interested parties for possible contract amendment 316. A monitoring operation 324 is performed to continue the contract execution process based on the events 319. The workflow is resumed 326. As events occur 319 failures can also be detected 332 and fixed 334. This allows the contract to be revalidated in the blockchain. The contract will end execution, thus ending the contract’s life of 328.

A GPS sensor attached to the shipment can emit events that contain information about the shipment’s current condition and location. These events may be received by the smart contract on blockchain, which can update the shared ledger state. This example shows how a contract can be examined and matched with a system policy violation. A system policy states that GPS sensors cannot be trusted 314 and must be accompanied by at minimum one additional corroborating sensor for each location attestation event. You can amend the contract 316 to add GPS sensors or other types of sensors, such as static scanners that are deployed at ports to scan incoming cargo and/or receive information about the sensors.

Sensors such as GPS sensors, can be regularly inspected to make sure they are working properly. A GPS sensor that fails to transmit location information during a pre-determined period may be deemed a malfunction and could result in a policy violation. If there are sufficient redundant sensors to track the shipment location and provide sufficient assurance for a policy, there is no reason to raise alarm. If a GPS sensor fails, resulting in a suboptimal number or malfunctioning sensors, then remedial action might be necessary 332. This could include having the sensor repaired or replaced 334. The contract state may remain unchanged until remedial action has been taken or it could be suspended while waiting for a response. A suspension could have a time limit that would allow for cancellation.

Parties may decide to add human verifiers or deploy new sensors if they discover a violation of their contract. The blockchain can be used to detect faults and make decisions that result in dynamic changes in contract enforcement systems or entities. The blockchain can be used to fix a fault in technology systems, such as adding or taking out a GPS unit. It also allows for the replacement of unreliable human agents. While the events that drive a contract remain constant, the actors and devices that produce them may change during the workflow.

FIG. “FIG. Referring to FIG. Referring to FIG. 4, a policy management sample 400 could include an admission check. This may include an examination 412, and recommendations 414 based upon the types and numbers of policies in a policy data base 416. The contract can be executed continuously until it is resolved, as policies are matched 422 to 424. You can store policies on the blockchain or in a separate database. The contract specification can include policies and a policy manager. The policy specification can include trust information that includes maps of sensors and other relevant information. You can also set threshold trust levels that are based upon a specific product shipment.

According to some examples, a “system” is a device or devices that perform a task or generate information in furtherance of negotiated workflow. A device or set of devices that perform a task or generate information to support contract workflow. (e.g. GPS sensors tracking shipment location). An “entity” An agent performing a specific action or entering information into an existing contract to continue the workflow. (e.g., port authority manager attesting that shipment arrived at its destination). To implement a smart contract one can use multiple programming languages and platforms, such as GO for IBM or SOLIDITY to ETHEREUM. FIG. 2 shows the details of parties, states, events and actions. 2. This is an example of an international deal. This could be goods being exported to one another and the financial transaction being mediated between the seller’s and buyer’s respective banks. Smart contract terms and tracking can be used to track the shipment’s progress and compare them with other authorities (e.g., truckers and ports). A smart contract is created and encoded in this case to include an importer who may apply for and receive a letter credit from a bank, and then present it to the exporter as a promise of future payments. The exporter can prepare the shipment and send it via a known carrier, if required by contract terms. The documents detailing the contents, their value, and the shipping date can be sent to the bank by the exporter once the shipment has been dispatched. The shipment’s progress through various stages can be attested to by the carrier and other documents. Once the goods arrive at their destination, and the bank of the importer receives documentation from the exporter; a money transfer can be accepted so that the goods may pass to the exporter.

The smart contract code could have a workflow embedded into its structure, similar to the one shown in FIG. 3. The code is then compiled and distributed onto the blockchain nodes. These nodes are distributed and under the control and supervision of the parties listed in FIG. 2. These include the importer, exporter and banks as well as shippers, shippers, and any other authorities. The code is event-driven. This means that when one party executes a particular action (e.g. an exporter shipping goods), the blockchain nodes execute it in parallel and update the shared ledger state using consensus procedures in blockchain. There are a number end states to the contract. One is successful shipment, followed by payment. Other ends are when different parties fail to perform their part faithfully (e.g. shipper not transporting goods for some reason).

Notifications may be sent to one or more parties in the event of failure. They can either suspend the contract while they fix or resolve the problem or decide that the contract terms remain valid and continue the process. The decision is up to the users, whether they are one or many users, or based upon a predetermined factor. In the event of a violation of direct contract, the smart contract can also suspend itself. A state that is not ready to ship a shipment, but has yet to receive payment, could be an example. A shipment moving from one stage to the next (e.g. truck to ship, ship-to port, port-to-customs etc.) is an example event. An event could be the trigger that causes the state or parties to be identified in a metric configuration audit. An event could cause a log to become written. This log contains information about the parties and current state, as well as the most recent event. An importer’s Bank may approve a letter-of credit application. An exporter might dispatch a shipment or obtain documents. Or, an importer bank could pay an exporter. A metric configuration or metric measurement may refer to a group of people, events or current states that have occurred recently or are about. Exporters, shipping companies, port authorities and manufacturers are all examples of parties. A state may refer to a current situation, such as a specific time, place, item, or possessor. These events could include a change of possession, transfer funds from one party, a new shipment status or a change to the shipment status.

One example is that the exporter might not accept terms of the importer?s bank letter credit and may terminate the deal. Or, the exporter could fail to ship a shipment on time. The shipper/carrier might not be able to transport the shipment to its destination port. Or, the exporter may not have valid shipping documents. This could result in the exporter losing its right to receive payment. An example of this is a bank refusing to honor terms of a letter credit to an importer and not clearing payment to it after the shipment has reached its destination. One example embodiment is a way to inspect a contract for defects and to monitor progress to catch technological and human errors. The blockchain contains records of transactions and updates to a ledger state.