CN111125242A - Transformation across organizational processes for performing via blockchain - Google Patents

Abstract

Embodiments of the present disclosure relate to transformations across organizational processes for execution via a blockchain. Example operations may include one or more of: receiving a plurality of state representations for a plurality of off-chain systems for performing a multi-party process via a blockchain, wherein each state representation identifies a transmit event and a receive event for a respective off-chain system; removing one or more events from the state representation of the out-of-chain system to generate a simplified state representation; generating an executable chain code for the block chain based on the plurality of state representations including the simplified state representation; and storing the generated chain code via the block link points of the block chain.

Description

Transformation across organizational processes for performing via blockchain

Technical Field

The present application relates generally to processes performed via blockchains, and more particularly to a system that transforms multiple organizational processes, including blockchains as intermediaries, into multiple state diagrams and performs the multiple organizational processes via blockchains based on the multiple state diagrams.

Background

A centralized database stores and maintains data at one location. The location is typically a central computing system, such as a server or mainframe computer. Information stored on a centralized database is typically accessible from a number of different points. For example, multiple users or client workstations may simultaneously operate on a centralized database based on a client/server configuration. Because of its single location, a centralized database is easy to manage, maintain and control, especially for security purposes. Within a centralized database, data integrity is maximized and data redundancy is minimized, as the single storage location of all data also means that a given data set has only one primary record. This helps to maintain the data as accurately and consistently as possible and enhances data reliability.

However, there are significant disadvantages to centralized databases. For example, a centralized database has a single point of failure. In particular, if there is no fault tolerance setting and a hardware failure occurs, all data within the database will be lost and all user work will be interrupted. In addition, centralized databases are highly dependent on network connectivity. As a result, the slower the internet connection, the longer the amount of time required for each database access. Another disadvantage is that: bottlenecks may occur when a centralized database experiences large traffic volumes. In addition, centralized databases provide limited access to data, as only one valid/useful copy of the data is maintained. As a result, multiple users may not be able to access the same piece of data simultaneously without causing problems (such as rewriting necessary data). Furthermore, because the central database is minimally free of data redundancy, if a data set is accidentally lost, it may be difficult to retrieve the data set other than through manual manipulation of the backup disk storage.

More recently, organizations have begun to collaborate via blockchains to implement multi-organizational processes. However, these processes are typically implemented inefficiently between the blockchain and the participating organizations, requiring redundant transmission, reception, storage, etc. Therefore, there is a need for a mechanism for efficiently implementing cross-organizational processes via blockchains.

Disclosure of Invention

An example embodiment may provide a system comprising one or more of: a storage device; a network interface configured to receive a plurality of state representations of a plurality of off-chain systems for performing a multi-party process via a blockchain, wherein each state representation identifies a transmit event and a receive event of a respective off-chain system; and a processor configured to perform one or more of: removing one or more events from the state representation of the out-of-chain system to generate a simplified state representation; generating an executable chain code for the block chain based on a plurality of state representations including the simplified state representation; and storing the generated chain code via a storage device.

Another example embodiment may provide a method comprising one or more of: receiving a plurality of state representations for a plurality of off-chain systems for performing a multi-party process via a blockchain, wherein each state representation identifies a transmit event and a receive event for a respective off-chain system; removing one or more events from the state representation of the out-of-chain system to generate a simplified state representation; generating an executable chain code for the block chain based on a plurality of state representations including the simplified state representation; and storing the generated chain code via the block link points of the block chain.

Another example embodiment may provide a non-transitory computer-readable medium comprising instructions that, when read by a processor, cause the processor to perform one or more of the following: receiving a plurality of state representations for a plurality of off-chain systems for performing a multi-party process via a blockchain, wherein each state representation identifies a transmit event and a receive event for a respective off-chain system; removing one or more events from the state representation of the out-of-chain system to generate a simplified state representation; generating an executable chain code for the block chain based on a plurality of state representations including the simplified state representation; and storing the generated chain code via the block link points of the block chain.

Another example embodiment may provide a system comprising one or more of: a storage configured to store chain code comprising executable steps of a multi-party process generated from a state diagram in which a blockchain is an intermediary between a plurality of out-of-chain systems; a network interface configured to receive a request to perform a multi-party process; and a processor configured to perform one or more of: processing a step of the multi-party process via execution of a stored chain code to generate a processing result for the step based on the request, the stored chain code including executable steps of the multi-party process; and storing the identification of the processing step and the generated processing result via the data chunks in the middle of the hash-linked chain of data chunks of the chain of chunks.

Another example embodiment may provide a method comprising one or more of: storing chain code comprising executable steps of a multi-party process generated from a state diagram in which a blockchain is an intermediary between a plurality of out-of-chain systems; receiving a request to execute a multi-party process; processing a step of the multi-party process via execution of a stored chain code to generate a processing result for the step based on the request, the stored chain code including executable steps of the multi-party process; and storing the identification of the processing step and the generated processing result via the data chunks in the middle of the hash-linked chain of data chunks of the chain of chunks.

Another example embodiment may provide a non-transitory computer-readable medium comprising instructions that, when read by a processor, cause the processor to perform one or more of the following: storing chain code comprising executable steps of a multi-party process generated from a state diagram in which a blockchain is an intermediary between a plurality of out-of-chain systems; receiving a request to execute a multi-party process; processing a step of the multi-party process via execution of a stored chain code to generate a processing result for the step based on the request, the stored chain code including executable steps of the multi-party process; and storing the identification of the processing step and the generated processing result via the data chunks in the middle of the hash-linked chain of data chunks of the chain of chunks.

Drawings

FIG. 1A is a schematic diagram illustrating a shared processing environment with a blockchain as an intermediary in accordance with an example embodiment.

FIG. 1B is a diagram illustrating transformation of a process description into multiple state diagrams, according to an example embodiment.

Fig. 1C is a schematic diagram illustrating a state diagram according to an example embodiment.

FIG. 1D is a schematic diagram illustrating a process model and corresponding state diagram in accordance with an example embodiment.

Fig. 2A is a schematic diagram illustrating a peer-to-peer (peer) node blockchain architecture configuration for an asset sharing scenario, according to an example embodiment.

Fig. 2B is a diagram illustrating a peer node blockchain configuration according to an example embodiment.

Fig. 3 is a schematic diagram illustrating a licensed blockchain network according to an example embodiment.

Fig. 4A through 4D are diagrams illustrating state diagrams created by transforming a process description according to an example embodiment.

Fig. 4E is a schematic diagram illustrating a process of removing an event from a starting graph according to an example embodiment.

Fig. 4F and 4G are schematic diagrams illustrating simplified state diagrams according to example embodiments.

FIG. 4H is a schematic diagram illustrating an architecture for executing chain code for performing a multi-party process, according to an example embodiment.

Fig. 5A is a schematic diagram illustrating a method of generating chain codes from multiple state diagrams, according to an example embodiment.

Fig. 5B is a schematic diagram illustrating a method of performing a multi-organizational process via a blockchain according to an example embodiment.

Fig. 6A is a schematic diagram illustrating a physical infrastructure configured to perform various operations on a blockchain in accordance with one or more operations described herein, according to an example embodiment.

FIG. 6B is a schematic diagram illustrating an intelligent contract configuration between contract parties and an intermediary server configured to execute intelligent contract terms on a blockchain, according to an example embodiment.

Fig. 6C is a schematic diagram illustrating an intelligent contract configuration between contract parties and an intermediary server configured to execute intelligent contract terms on a blockchain, according to an example embodiment.

FIG. 6D is a schematic diagram illustrating another example blockchain-based intelligent contract system in accordance with example embodiments.

Fig. 7A is a schematic diagram illustrating a process of adding a new block (block) to a block chain ledger (hedger), according to an example embodiment.

Fig. 7B is a schematic diagram illustrating the contents of a data chunk structure for a chunk chain, according to an example embodiment.

FIG. 8 is a schematic diagram illustrating an example computer system configured to support one or more of the example embodiments.

Detailed Description

It will be readily understood that the components, as generally described and illustrated in the figures herein, could be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of at least one of the methods, apparatus, non-transitory computer-readable media, and systems, as represented in the figures, is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments.

The features, structures, or characteristics as described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, use of the phrases "example embodiment," "some embodiments," or other similar language throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment. Thus, appearances of the phrases "example embodiments," "in some embodiments," "in other embodiments," or other similar language throughout this specification are not necessarily all referring to the same group of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

In addition, although the term "message" may have been used to describe embodiments, the application may be applied to many types of network data, such as packets, frames, datagrams, and the like. The term "message" also includes packets, frames, datagrams, and any equivalents thereof. Further, while certain types of messages and signaling may be depicted in the exemplary embodiments, they are not limited to a certain type of message, and the application is not limited to a certain type of signaling.

Example embodiments provide methods, systems, non-transitory computer-readable media, devices, and/or networks that transform multi-organizational process descriptions into chain codes that can be implemented via a blockchain.

A decentralized database is a distributed storage system that includes a plurality of nodes in communication with each other. A blockchain is an example of a decentralized database that includes only additional immutable data structures similar to a distributed ledger that can maintain records between mutually untrusted parties. Untrusted parties may be referred to herein as peer nodes or nodes. Each peer node maintains a copy of the database record and no single peer node can modify the database record without consensus among the distributed peer nodes. For example, a peer node may perform a consensus protocol to validate a blockchain storage transaction, aggregate (group) the storage transactions into chunks, and build a hash chain over chunks. The process forms the ledger by ordering the storage transactions as needed to obtain consistency. In a public blockchain or an unlicensed blockchain, anyone can participate without a specific identity. Common blockchains typically involve local cryptocurrency and use proof of work (PoW) based consensus. On the other hand, the licensed blockchain database provides the following system: the system may protect interactions among a group of entities that share a common goal but do not fully trust each other, such as businesses that exchange funds, goods, information, etc.

The blockchain operates any programmable logic that is customized for a decentralized storage scheme and is referred to as a "smart contract" or "chain code". In some cases, there may be a dedicated chain code for management functions and parameters, referred to as a system chain code. Smart contracts are trusted distributed applications that utilize tamper-resistant properties of blockchain databases and underlying protocols between nodes called endorsement or endorsement policies. In general, blockchain transactions must typically be "endorsed" before committing (commit) to the blockchain, while transactions that are not endorsed are ignored. Typical endorsement policies allow a chain code to specify an endorsement node for a transaction in the form of a set of peer nodes that are necessary for endorsement. When the client sends the transaction to the peer node specified in the endorsement policy, the transaction is executed to validate the transaction. After validation, the transactions enter an ordering phase in which a consensus protocol is used to generate an ordered sequence of endorsed transactions that are aggregated into blocks.

A node is a communication entity of the blockchain system. A "node" may perform a logical function in the sense that multiple nodes of different types may run on the same physical server. Nodes are aggregated in a trust domain and associated with logical entities that control them in various ways. The nodes may comprise different types, such as clients or submitting client nodes that submit (submit) transaction calls to a endorsement node (e.g., a peer node) and broadcast transaction proposals to a ranking service (e.g., a ranking node). Another type of node is a peer node that can receive transactions submitted by clients, commit transactions, and maintain state and copies of the ledger of blockchain transactions. Peer nodes may also play the role of endorsement nodes, but this is not a requirement. A sequencing-service-node or sequencer (orderer) is a node that runs communication services for all nodes and implements delivery guarantees such as a broadcast to each of the peers in the system when committing a transaction and modifying the world state of a blockchain, another name for an initial blockchain transaction that typically includes control information and setup information.

The ledger is an ordered tamper-resistant record of all state transitions of the blockchain. The state transition may be caused by a chain code call (i.e., transaction) submitted by a participant (e.g., client node, sequencing node, endorsement node, peer node, etc.). A transaction may cause a set of asset key-value pairs to be committed to the ledger as one or more operands, such as create, update, delete, and so forth. The ledger includes a blockchain (also referred to as a chain) that is used to store immutable ordered records in the form of blocks. The ledger also includes a state database that maintains the current state of the blockchain. There is typically one ledger per channel. Each peer node maintains a copy of the ledger for each channel of which they are a member.

The chain is a transaction log structured as hash-linked chunks, and each chunk comprises a sequence of N transactions, where N is equal to or greater than 1. The chunk header includes a hash of the transaction of the chunk and a hash of the header of the previous chunk. In this way, all transactions on the account can be ordered and cryptographically linked together. Therefore, it is not possible to tamper with ledger data without destroying the hash link. The hash of the most recently added blockchain chunk represents each transaction that comes before it on the chain, which can ensure that all peers are in a consistent and trusted state. The chains may be stored on a peer file system (i.e., local file system, additional storage file system, cloud file system, etc.) to efficiently support the only additional nature of the blockchain workload.

The current state of the immutable ledger represents the latest value for all keys included in the chain transaction log. The current state is sometimes referred to as the world state because it represents the latest key value known to the channel. The chain code calls to execute the transaction against the current state data of the ledger. To validate these chain code interactions, the latest value of the key may be stored in the state database. The state database may simply be an indexed view of the transaction log of the chain, and thus, the state database may be regenerated from the chain at any time. The state database may be automatically restored (or generated, if needed) after the peer node starts and before the transaction is accepted.

More recently, blockchains have been used as intermediaries between multiple untrusted organizations when performing a sharing process in which each party somehow collaborates with or contributes to the overall process. Multiparty processes (or cross-organizational processes) exist in many types of domains, including: banking, healthcare, politics, real estate, law, government, leasing and sharing, education, charity, and assistance organizations, etc. Generally, these processes involve at least a transmission event (or a send event), a receive event where the transmission is received by the parties, and a store event on the blockchain that records the occurrence of the event. In this case, the large number of send events, receive events, and store events does not change the state of one or more of the parties.

Example embodiments overcome these disadvantages by converting a multi-party process description (schema) into multiple state representations (e.g., graphs, etc.), such that each of the parties has its own respective state diagram, including blockchains. Furthermore, events can be removed from the state representation, wherein the state of the party does not change as further described herein, resulting in a simplified state diagram. These simplified state diagrams can be used to develop chain code (software artifacts) that can be executed by block chain nodes to efficiently implement a multi-party process.

Some benefits of the present solution described and depicted herein include: the process model involving all parties is translated into a separate state representation for each party, simplifying the understanding of each party. Further, embodiments perform reducing the amount of storage events, transmission events, and reception events for all parties within a multi-party process by removing events from the state representation. Moreover, the current steps of the multi-party process can be identified by an immutable block chaining ledger that provides a mechanism for keeping track of the current state of the multi-party process without the need for a central intermediary.

Blockchains differ from traditional databases in that: the blockchain is not a central storage but a distributed immutable and secure storage, where nodes have to share changes of records in the storage. Some attributes inherent in and that help implement blockchains include, but are not limited to: immutable ledgers, intelligent contracts, security, privacy, decentralization, consensus, endorsement, accessibility, and the like, which are further described herein.

According to various aspects, smart contracts may be used to implement a transformational cross-organizational process. For example, a smart contract (chain code) may include instructions for executing the simplified state diagram described herein. Furthermore, the decentralized nature of the system enables the entire system to be built without relying on a central control point. Thus, trust can be created in a shared manner, without relying on authorization of a single entity.

The example embodiments provide a number of benefits over traditional databases. For example, through blockchains, embodiments do not require additional mechanisms for managing consistency and trust between parties with conflicting interests, which may incur significant costs. At the same time, traditional databases would need to be checked and balanced to prevent a single organization from accessing and controlling data for multiple parties.

FIG. 1A illustrates a blockchain mediated shared processing environment 100A, FIG. 1B illustrates transforming a process description into multiple state diagrams, and FIG. 1C illustrates an example of a state diagram, according to an example embodiment. Referring to FIG. 1A, multiple organizations, including A, B and C, cooperate to perform a shared multi-party process 110. Here, each organization executes its own respective process 102, 104, and 106, while some aspects of each process overlap with shared multi-party processes 110. According to various embodiments, shared multi-party process 110 uses blockchain 111 to record events that occur between organizations A, B and C and the blockchain.

FIG. 1B illustrates an example of a process 100B that transforms a process model into multiple state diagrams, and then converts the state diagrams into a simplified state diagram. Meanwhile, FIG. 1C provides an example of a process model 120. In the example of FIG. 1C, the process model 120 is a description of how things should happen during process execution. In other words, a "process model" may be a "process description" or a "process definition". The transition from the process model 120 to the simplified state diagrams 141-144 may be performed outside of the blockchain. For example, a person or system may provide a simplified state diagram to all blockchain peers. The process model 120 may be in XML form, but the example embodiments may also be applied to any non-XML process description.

In the example of fig. 1B, the process model 120 is initially transformed into a plurality of state diagrams 131-134 (the plurality of state diagrams 131-134 may be referred to herein as state representations). Each party and blockchain may have their respective state diagrams. The state diagram identifies events to be performed by the respective parties during multi-party process 110. According to various embodiments, the multiple state diagrams 131-134 can have one or more events removed therefrom to create the simplified state diagrams 141-144. Events may be removed to improve processing efficiency. For example, consecutive receive events may not change the state of a party, and thus, at least one of the receive events may be removed.

The process model 120 shown in FIG. 1C illustrates a swim lane diagram representing the steps performed by each party for the multi-party process 110 shown in FIG. 1A. Here, the parties include a customer 122, an insurer 124 and a verifier 126 who perform the insurance claim process in a collaborative manner. The state diagrams 131-134 generated in fig. 1B may represent events performed by each respective party 122, 124, and 126 and the blockchain acting as an intermediary.

Maintaining consistency and mutual trust in cross-organizational business processes has been a long-standing challenge for the IT industry. In a centralized business (business) process within an organization, information about enterprise activities may be shared and verified, and the participants of the process trust each other. However, in a cross-organizational process, when process control is handed over to a participant outside the organization, the other party cannot verify data accuracy, perform obligations or check whether the conditions are met. As a result, moving control between segmented processes of different organizations tends to result in inconsistent and untrusted process management.

The cross-organizational business process blockchain can be used as a solution to consistency and trust issues in managing cross-organizational business processes. Transactions in a business process network across an organization can be shared and validated by participants, a mechanism that does not require participants to trust each other. Transactions between participants may also be handled by intelligent contracts (also referred to as chaining codes) that encode business logic agreed upon by all process participants. Each participant runs its own private process, while the entire process shared by the participants is managed by a blockchain as shown in fig. 1A.

While blockchain technology may help to change the level of integration and automation, using blockchains to manage cross-organizational business processes presents other challenges, including: defining the entire workflow that controls the process across organizational boundaries, the participants' private processes must fulfill the responsibilities given by the shared flow, and since blockchain based solutions still face technical challenges (such as throughput limitations, delay limitations, size limitations, and bandwidth limitations), the mechanisms built on the blockchain must be highly optimized.

To address the above-mentioned challenges, example embodiments include methods for: (1) transforming a single business process model into a plurality of state diagrams, (2) optimizing the generated state diagrams, and (3) generating intelligent contracts and participant applications from the state diagrams. Since this approach allows us to represent the entire workflow to be automatically transformed into smart contracts and Web applications, they are always consistent with each other. Embodiments transform the process model into a state diagram and are used to optimize the generated state diagram. Software artifacts, which are smart contracts and Web applications, can be generated from the state diagram.

The example embodiments differ from the existing studies in that: a simple process diagram (such as the one shown in the example of fig. 1C) may be used as an input to generate a state diagram that is the target of the model transformation. The system may delve into details regarding the manner in which messages are exchanged between participants and the manner in which software process engines, collaboration diagrams, or orchestration diagrams support the process. The state diagram has the following advantages over other behavioral representations. For example, the state diagram may represent a blockchain as well as a number of process participants, as the state diagrams communicate with each other by receiving and sending events. The status icons have been normalized and, thus, developer support, including tools and education, has been available. Furthermore, the formal aspect of the state diagram enables the composition and optimization logic to be precisely defined. The state diagram is also close to implementation, so the final software artifact can be easily built based on the state diagram.

As shown in the example of FIG. 1B, the system takes a process model as input and transforms it into a state diagram for application of blockchains and organizations. The state diagram of the organization is then reduced to an optimized state diagram, and using the results of the simplified calculations, the state diagram for the blockchain is also simplified. To define a process model, the following set of modeling elements may be used, including: a start event acting as a process trigger; an end event representing the result of the process; activities that describe work that must be done; a sequence flow showing the order in which activities are performed; a decision to create an alternative flow, wherein only one of the paths may be taken; combining the two alternative sequence paths into a path; swim lanes to classify activities according to participant roles, where a pool is provided with multiple "lanes". FIG. 1C illustrates an example insurance payment process with two decisions and one merge, where the customer, underwriter, and inspector are participants in the process.

After the process is triggered, the customer prepares the claim and submits it to the insurer, who then requests the inspector to investigate the claim. The inspector decides whether to accept the claim. If the inspector does not accept the claim, the insurer sends a decision (does not accept the claim). After receiving the decision, the client likewise decides whether to accept or notAnd (6) making a decision. In the event that the customer does not accept the decision, she updates the claim and again submits the claim to the insurer; alternatively, the process terminates. If the inspector accepts the claim, the insurer makes a payment, which will be received by the customer. To define a transformation having a process model as an input, the process model may be formalized as a 5-tuple<O；o₀；F；P；R>Where O is a set of stream objects including start and end events, activities, decisions, and merges, O₀E.o is the start event and,

is a stream relationship, P is a set of participants, and R: o → Pi is a mapping that associates stream objects with participants. The stream relation (o; o '; t) represents the stream of objects from an object o to another object o', the stream type of which is indicated by t. While the stream type can be uniquely derived from the source object and the target object, we do not explicitly describe it.

Then, we represent the process shared by multiple organizations by means of a set of state diagrams. The blockchain-based infrastructure may be considered a state transition system, where submitted transactions are recorded as changes in state. For individual participants, state diagrams may also be used for behavioral descriptions that provide the basis for interface specification and implementation of functionality. Additionally, the interaction between process participants and blockchains can be modeled as a set of state diagrams for which events for communications are sent and received. Therefore, using state diagrams to represent the behavior and interaction of blockchains and process participants is considered a promising approach. When a state diagram is used to represent the sharing process, the mapping between two different types of models must satisfy two requirements: all communications between participants must be mediated by the blockchain to ensure consistency and trust, and all participants share the same agreed upon process.

FIG. 1D illustrates a process 160 of transforming a segmented process model with two participants A and B into corresponding state diagrams to represent the behavior of an activity. We use three state diagrams, one for the blockchain and the other for the blockchainParticipants a and B. Here we use arrows to represent the transition from one state s to another s', with the label e/a₁、...、a_nWherein e is the event to be received and a is when the transition occurs₁、...、a_nIs the event to be sent. We also describe/a in the case of a transition without a receive event or a send event, respectively₁、...、a_nAnd e.

All state diagrams being in a first state s₁，

And

and starting. When an object stream goes active, the blockchain sends event b^AAnd b^BAnd transitions to state s 2. When receiving b^AAnd b^BWhen participants A and B transition to states, respectively

And

after the end of the activity, participant A transitions to state

And sends an event f^AThe event f^AWill be received by the blockchain. The blockchain then transitions to state s³And sends an event f to be received by participant B^B. Thus, all communications are mediated by the blockchain and all participants share the same process.

Fig. 2A illustrates a blockchain architecture configuration 200, according to an example embodiment. Referring to fig. 2A, the blockchain architecture 200 may include certain blockchain elements, such as a set of blockchain link points 202. Blockchain node 202 may include one or more nodes 204-210 (these four nodes are depicted by way of example only). These nodes participate in several activities, such as blockchain transaction addition and validation processes (consensus). One or more of the blockchain nodes 204 through 210 may endorse transactions based on an endorsement policy and may provide ordering services for all blockchain link points in the architecture 200. The blockchain link point may initiate blockchain authentication and seek to write a blockchain immutable ledger stored in blockchain layer 216, a copy of which may also be stored on underlying physical infrastructure 214. The blockchain configuration may include one or more applications 224 linked to an Application Programming Interface (API)222 to access and execute stored program/application code 220 (e.g., chain code, intelligent contracts, etc.), the stored program/application code 220 may be created according to the custom configuration sought by the participant, and the stored program/application code 220 may maintain its own state, control its own assets, and receive external information. This may be deployed as a transaction and may be installed on all blockchain nodes 204 to 210 via appending to the distributed ledger.

Blockchain base or platform 212 may include various blockchain data layers, services (e.g., cryptographic trust services, virtual execution environments, etc.), and underlying physical computer infrastructure that may be used to receive and store new transactions and provide access to auditors seeking access to data entries. The blockchain layer 216 may expose an interface that provides access to the virtual execution environment necessary to handle the program code and interface to the physical infrastructure 214. The cryptographic trust service 218 may be used to verify transactions (such as asset exchange transactions) and keep information private.

The blockchain architecture configuration shown in fig. 2A may process and execute program/application code 220 via the exposed interface or interfaces and services provided by blockchain platform 212. Code 220 may control blockchain assets. For example, code 220 may store and communicate data and may be executed by nodes 204-210 in the form of intelligent contracts and associated chain codes having conditions and other code elements affected by their execution. By way of non-limiting example, smart contracts may be created to perform reminders, updates, and/or other notifications that are affected by changes, updates, and the like. Further, according to various embodiments, the smart contract may be configured to implement a cross-organizational process based on a state diagram that has been transformed from the process description. The smart contracts themselves may be used to identify rules associated with authorization and access requirements and usage of the ledger. In this example, read set 226 can be processed by one or more processing entities (e.g., virtual machines) included in blockchain layer 216. The write set 228 may include changes to key values. Physical infrastructure 214 may be utilized to retrieve any of the data or information described herein.

Within chain code, intelligent contracts may be created via high-level application and programming languages and then written to blocks in a block chain. An intelligent contract may include executable code that is registered, stored, and/or replicated with a blockchain (e.g., a distributed network of blockchain peer nodes). A transaction is the execution of intelligent contract code that may be executed in response to conditions associated with satisfying an intelligent contract. Executing the intelligent contract may trigger a (multiple) trusted modification of the state of the digital blockchain ledger. The modification(s) to the blockchain ledger caused by execution of the intelligent contract may be automatically replicated throughout the distributed network of blockchain peers by one or more consensus protocols.

The intelligent contract may write data to the blockchain in the format of key-value pairs. In addition, the intelligent contract code may read the values stored in the blockchain and use them in application operations. The intelligent contract code may write the output of various logical operations to the block chain. The code may be used to create temporary data structures in a virtual machine or other computing platform. The data written to the blockchain may be public and/or may be encrypted and kept private. The provided execution environment saves the temporary data used/generated by the smart contract in memory and then deletes the data needed for the blockchain once it is identified. According to various embodiments, the read set 226 may include current processing steps of a multi-party process. Meanwhile, write set 228 may include results of execution of processing steps, which may include identification of the steps, send and receive events performed during the processing steps, and the like.

The chain code may include a code interpretation of the intelligent contract with additional features. As described herein, chain code can be program code deployed on a computing network, where the chain code is executed and validated together by a chain validator during a consensus process. The chain code may be generated based on a block chain and a plurality of state diagrams of a plurality of off-chain systems. The chain code receives the hash and retrieves the hash associated with the data template created by using the previously stored feature extractor from the blockchain. If the hash of the hash identifier matches the hash created from the stored identifier template data, the chain code sends the authorization key to the requested service. The chain code may write blockchain data associated with the cryptographic details.

Fig. 2B illustrates an example of a transaction flow 250 between nodes of a blockchain in accordance with an example embodiment. Referring to fig. 2B, the transaction flow may include: transaction proposal 291 is sent by application client node 260 to endorsement peer node 281. The endorsement peer 281 may verify the customer signature and perform a chain code function to initiate the transaction. The output may include the chain code result, the set of key/value versions read in the chain code (read set), and the set of keys/values written in the chain code (write set). If approved, the proposal response 292 is sent back to the client 260 along with the endorsement signature. The client 260 aggregates the endorsements into a transaction payload 293 and broadcasts it to the ordering service node 284. The ordering service node 284 then delivers the ordered transaction as a chunk to all peers 281 to 283 on the channel. Each peer node 281 to 283 may validate transactions before committing to the blockchain. For example, the peer may check the endorsement policy to ensure that the properly assigned designated peer has signed the result and authenticated the signature to the transaction payload 293.

According to various embodiments, transaction 291 may include a request to perform a multi-party process in which a blockchain is an intermediary between multiple off-chain systems (such as organizations, groups, companies, users, agents, and/or the like). Transaction 291 may identify a current step to be performed, or transaction 291 may not identify a current step to be performed. The chain code may be able to determine the next step to be performed in the multi-party process based on the current key value for the state of the multi-party process that is stored on the distributed ledger (e.g., a world state database, blockchain, etc.). The request may be endorsed by one or more peer nodes and, upon successful endorsement, may be forwarded to the sorting node for inclusion within the data block and storage in the middle of the blockchain.

Client node 260 may initiate transaction 291 by building a request and sending the request to peer node 281, which is an endorsement node. Transaction proposal 291 may include a request to store information about the results of execution of subcomponents of the software model. There may be more than one endorsement node, but for convenience, one endorsement node (i.e., peer node 281) is shown here. The client 260 may include an application (e.g., a web application, etc.) that utilizes a supported Software Development Kit (SDK), such as NODE, JAVA, PYTHON, etc., that utilizes available APIs to generate a transaction proposal. Transaction proposal 291 is a request to call a chain function so that data can be read and/or written to an ledger (i.e., to write a new key-value pair for an asset). The SDK may serve as a shim (shim) to package the transaction proposal into an appropriate architectural format (e.g., a protocol buffer over Remote Procedure Calls (RPCs)) and to obtain the client's encryption credentials to generate a unique signature for the transaction proposal.

In response, endorsement peer 281 may verify that: (a) well formed transaction proposals, (b) no transaction has been submitted in the past (replay-attack protection), (c) the signature is valid, and (d) the submitter (client 260 in this example) is properly authorized to perform the proposed operation on the channel. Endorsement peer 281 may treat the transaction proposal input as an argument to the called chain code function. The chain code is then executed against the current state database to produce transaction results including response values, read sets, and write sets. According to various embodiments, the transaction results may include results of performing the current step of the multi-party process. However, at this time, the ledger is not updated. In 292, the set of values is passed back to the client's 260 SDK, which parses the payload for use by the application, as a proposal response 292 along with the signature of endorsement peer 281.

In response, the application of client 260 checks/verifies the endorsement peer signature and compares the proposal responses to determine if the proposal responses are identical. If the chain code only queries the ledger, the application will check the query response and will not typically submit the transaction to the sequencing node service 284. If the client application intends to submit the transaction to sequencing node service 284 for ledger update, the application determines whether the specified endorsement policy has been satisfied prior to submission (i.e., does all of the peer nodes required for the transaction endorse the transaction). Here, the client may include only one of the parties to the transaction. In this case, each client may have its own endorsement node, and each endorsement node will need to endorse the transaction. The architecture is such that even if an application chooses not to check for responses or otherwise forward non-endorsed transactions, the endorsement policy will still be enforced by the peer node and support the endorsement policy during the commit validation phase.

After a successful check, the client 260 aggregates the endorsements into transactions and broadcasts the transaction proposal and response in the transaction message to the ordering node 284 in step 293. The transaction may include a read/write set, an endorsement peer signature and channel ID, as well as timestamp information and multiparty process information described herein, such as identification of the current step performed, send and receive events performed during the step, and the like. The ordering node 284 need not examine the entire contents of the transaction in order to perform its operations, but rather the ordering node 284 may simply receive the transactions from all of the channels in the network, order them chronologically through the channels, and create chunks of the transaction per channel.

The block of transactions is delivered from ordering node 284 to all peer nodes 281 to 283 on the channel. Transactions within the block are verified 294 to ensure that any endorsement policy is satisfied and that the ledger state has not changed for the read set variables since the read sets were generated by transaction execution. The transaction in the block is marked as valid or invalid. Further, in step 295, each peer 281 to 283 appends the chunk to the chain of channels and commits the write set to the current state database for each valid transaction. Events are issued to notify the client application that a transaction (call) has been immutably attached to the chain, and whether the transaction has been validated or not.

Fig. 3 illustrates an example of a licensed blockchain network 300 and a certificate authority 318 that manages user roles and licenses, the licensed blockchain network 300 featuring a distributed, decentralized peer-to-peer architecture. In this example, blockchain user 302 may submit a transaction to allowed blockchain network 310. In this example, the transaction may be a deployment, call, or query, and may be issued by a client-side application utilizing the SDK, directly through the REST API, or the like. The trusted enterprise network may provide access to a regulator system 314, such as an auditor (e.g., the securities and exchange commission in the U.S. stock market). At the same time, the blockchain network operator system 308 of the node manages member permissions, such as registering the regulator system 310 as an "auditor" and the blockchain user 302 as a "customer. Auditors may be limited to querying the ledger, while clients may be authorized to deploy, invoke, and query certain types of chaining codes.

Blockchain developer system 316 writes chain code and client-side applications. Blockchain developer system 316 can deploy the chain code directly to the network through the REST interface. To include the credentials from the legacy data source 330 in chain code, the developer system 316 may access the data using an out-of-band connection. In this example, blockchain user 302 connects to the network through peer node 312. Before proceeding with any transactions, peer node 312 retrieves the user's enrollment and transaction credentials from certificate authority 318. In some cases, the blockchain user must possess these digital certificates in order to conduct transactions on the licensed blockchain network 310. At the same time, a user attempting to drive the chain code may be required to verify their credentials against the legacy data source 330. To confirm the user's authorization, the chain code may use an out-of-band connection to the data through a conventional processing platform 320.

Fig. 4A illustrates an example of a state diagram 400A for a blockchain. 4B-4D illustrate examples of state diagrams 410A, 420A, and 430A for different respective parties (client, insurer, guarantor). As shown in the example of fig. 4A, events are represented by nodes 402, which nodes 402 include links 404 therebetween to identify the order of the events. Also, a list 406 of send events and receive events is included next to the link and between the two events. The state diagram may initially include significantly more events than necessary due to the redundant storage and transport functionality associated with the multiple parties interacting with the blockchain as an intermediary.

According to various embodiments, state diagrams (e.g., state diagrams 400A-430A) may be generated using a sub-process that traverses a process model, such as process model 120 shown in the example of fig. 1C. For example, a sub-process may be defined as transforming a process model into a state diagram. As one example, a sub-process may traverse an input process model and create a state diagram according to the type of objects in the process model. The active object and the merge object may be transitioned into two state transitions, and the decision object may be transitioned into three state transitions. Appended to the transition are a send event and a receive event, the send event and the receive event comprising a communication. The logic of the sub-process may generate a state diagram with transitions that do not occur for receive events and/or transmit events. These events may be removed. Functions may be used that take tags, participants and objects as input and associate these with events that are specific to combinations of these parameters. This function can be used to generate state diagrams that communicate with each other by exchanging events of the same name. The memory map may be used to maintain a correspondence between objects in the process model and states in the state diagram. When a function accesses an object that has been previously accessed, the logic may reuse the state previously created and maintained by the memory map.

The state diagram generated from the process model may not be optimal because the events that trigger the activities in the process model are sent to all participants, even if the participants are not engaged in the activity. To reduce communication overhead in blockchain based solutions, example embodiments may remove as many events as possible. For example, two consecutive transitions that receive an event but do not send an event may identify a situation where the event may be removed. In this case, the path of the state transition is the same even if we eliminate the receive event from the first transition. Since the event is not sent from two state transitions, removing the receive event does not change the behavior observed from outside the state diagram. This principle can be generalized to the case where a state has multiple incoming transitions and/or multiple outgoing transitions. When all outgoing transitions receive events but do not send any events, we can safely remove the receive events of incoming transitions that do not send any events. In FIG. 4E, s is the state whose outgoing transition does not send any event as shown in 441. Thus, at 442, the process (procedure) may eliminate e1 from the s1 to s transition. Further, in 443, the system can remove the no-event transition and add a new transition to pass the removed transition. In 444, the system may repeat the removal steps performed in 441 through 443 for all incoming transitions of the target state. In the event that the state becomes inaccessible, we remove the state and its outgoing transitions at 445.

Fig. 4F and 4G show simplified state representations. In particular, as shown in fig. 4F, the block chain state representation 400A is simplified to a simplified representation 400B. Also, as shown in FIG. 4G, the state representations 410A, 420A, and 430A are reduced to simplified state representations 410B, 420B, and 430B.

After obtaining simplified state diagrams for blockchains and process participants, example embodiments may use these state diagrams to generate software components, including smart contracts and Web applications. FIG. 4H illustrates an overview of an architecture 450 for generating intelligent contracts and web applications, and the resulting software artifacts. Example embodiments may rely on a Hyperledger architecture (Hyperhedger Fabric), which is a blockchain framework that is the architecture for hosting intelligent contracts. For example, a chain code may include two components: a common state diagram engine and state diagram definitions. To provide an API for interacting with the hyper book structure, we use their client SDK, which is intended to be designed for node. We also create web applications that use state transition tables generated from the state diagram and interact with the hyper-ledger structure by exchanging events.

In these examples, the JSON data may be interpreted by a state diagram engine running on the hyper book structure. SCXML can be used as an intermediate language because support tools (such as graphics viewers and execution monitors) are already available, and SCXML encompasses complex constructs, such as sub-states and parallel states that help develop future extensions. When the state diagram is generated using SCXML, a specific state name and event name may be given. For state names, there may be no clues in the input process model, and therefore, uniquely generated names may be assigned to states in the state diagram. Random names may be allowable because state names are not disclosed within the state diagram. However, events are shared by multiple state diagrams, and therefore, an event must have a name that all participants can agree to. The state diagram engine on the hyper book structure accepts transactions requesting state diagram operations, such as sending events to the state diagram, which will cause state transitions. Other state diagram operations include: querying the current state and accessing the last received event. Js, an API for interacting with such functions, is provided by the hyper book architecture SDK and mode, which installs and instantiates chain code, submits transactions, and monitors events generated by the chain code.

We also generate a web application framework whose behavior conforms to the protocol defined by the state diagrams, which are presented in the form of state transition tables. The web application framework may be built based on Angular (front end web application framework in JavaScript). The application may include two customized controllers. The UI controller may first create a clickable button for all send events, enable/disable the button according to the current state, and cause a transition when the web application user clicks on the enable button. A node. js server may send and receive events and communicate with a state diagram that runs as a chain code on the blockchain.

We evaluated the effectiveness of our method using two insurance process models: marine insurance covers the loss of or the destruction of ships, cargo and docks by the sea. It involves importers, exporters and underwriters as participants, and the process model includes 22 objects and 25 streams. Reinsurance is "insured insurance" that is purchased by an insurance company and allows the insurance company to maintain reimbursement capability following a major claim event. It involves reinsurers, clients (insurance companies) and inspectors as participants, and the process model consists of 18 objects and 18 streams.

Tables 1 and 2 summarize the results of our state diagram generation and state diagram simplification logic applied to the marine insurance process and the reinsurance process, respectively. They show the number of states, transitions, receive events and transmit events before and after state diagram simplification. State diagram generation produces a set of state diagrams that work together to properly execute the process model, but the resulting state diagrams for the blockchain require a relatively large number of receive and transmit events (105 events for 22 objects in marine insurance and 93 events for 18 objects in reinsurance). By applying state diagram simplification, we can reduce the number of events by 74% and 65%, which helps us to improve the performance of the whole system. Moreover, the number of state transitions of the state diagram of the participants is reduced to 68% on average, which makes it easier to build and maintain applications that conform to the process model.

TABLE 1 experiment 1

TABLE 2 experiment 2

Fig. 5A illustrates a method 500 of generating a chain code from multiple state diagrams, according to an example embodiment. For example, method 500 may be performed by a blockchain peer node, which may be a computing system. As another example, method 500 may be performed by an out-of-chain system (such as a server, a database, a user device, a combination of devices, etc.). In some embodiments, method 500 may be performed by a combination of any of the systems.

Referring to fig. 5A, at 502, the method may include: a plurality of state representations of a plurality of off-chain systems for performing a multi-party process are received via a blockchain, wherein each state representation identifies a transmit event and a receive event of a respective off-chain system. The state representations may include state diagrams in which nodes represent events and links represent relationships between events. Events within the state representation may include transmission, reception, storage, etc. events performed by any of the systems. Each party may have its own status representation. Furthermore, the blockchain may have its own status representation.

In some embodiments, receiving may further comprise: a process description for a multi-party process comprising process steps between a plurality of off-chain systems and a blockchain is transformed into a plurality of state representations. In this case, the blockchain may be an intermediate communication system between multiple off-chain systems within a multi-party process. In some embodiments, receiving may further comprise: a blockchain state representation identifying a transmit event, a receive event, and a store event of the blockchain is received, and generating the chain code is further performed based on the blockchain state representation.

At 504, the method may include: one or more events are removed from the state representation of the out-of-chain system to generate a simplified state representation. In some embodiments, events may be removed from each of the state representations. For example, when two consecutive receive events occur without a transmit event occurring, at least one of the receive events may be removed because it does not change the state of the party. In some embodiments, removing may include: one or more events are removed based on actions performed by the out-of-chain system during the one or more events. For example, if the action is receiving an event, in some cases, the event may be removed. For example, when a receive event in a set of consecutive receive events within the state representation of the out-of-chain system can be removed. In some embodiments, removing may include: multiple receive events for the out-of-chain system are removed while all transmit events for the out-of-chain system are retained.

At 506, the method may include: an executable chain code for the block chain is generated based on a plurality of state representations including the simplified state representation, and in 508, the generated chain code is stored via block chain link points of the block chain. The chain code may be generated based on steps within a state representation in which one or more of the event steps have been removed, thereby increasing the efficiency of the multi-party process by eliminating one or more of sending events, receiving events, storing events, and the like.

Fig. 5B illustrates a method 510 of performing a multi-organizational process via a blockchain, according to an example embodiment. For example, method 510 may be performed by a blockchain peer node or a group of peer nodes. Referring to fig. 5B, at 512, the method may include: chain code is stored that includes executable steps of a multi-party process generated from a state diagram in which a blockchain is an intermediary between a plurality of out-of-chain systems. In some embodiments, a state diagram may include multiple state representations for multiple out-of-chain systems in a multi-party process. The chain code may include therein steps for performing a multi-party process, including these steps and the order of one or more steps removed from the original state diagram. In some embodiments, the chain code is based on one or more simplified state diagrams for one or more of the out-of-chain systems in which at least one receive event has been removed. For example, the state diagram can be a plurality of simplified state diagrams for a plurality of out-of-chain systems of the multi-party process, respectively, for the multi-party process.

At 514, the method may include: a request to execute a multi-party process is received. For example, the request may include: a client node requests execution of a multi-party process. In this case, the chain code may identify which step is to follow based on the most recently performed step stored in the state database of the distributed ledger including the blockchain. Here, the chain code may identify the current step based on the most recently performed step and the order of steps included in the chain code.

At 516, the method may include: processing a step of the multi-party process via executing a stored chain code to generate a processing result for the step based on the request, the stored chain code including executable steps of the multi-party process, and in 518 the method may include: the identification of the processing step and the generated processing result are stored via the data chunks in the middle of the hash-linked chain of data chunks of the chunk chain. In some embodiments, storing the identification of the processing step may include: the current execution state of the out-of-chain system included within the multi-party process is stored. In some embodiments, storing the identification of the processing step may include: events sent and/or received by the off-chain system during the execution of the processing steps of the multi-party process are stored.

In some embodiments, the method may further comprise: a plurality of peer nodes is used to verify the block-chaining result generated during processing. In some embodiments, the multi-party process may include a shared process performed by multiple off-chain systems and blockchains. In some embodiments, the method may further comprise: the next executable step of the multi-party process is processed via the blockchain based on the results of the processing steps of the multi-party process processed by the blockchain.

Fig. 6A illustrates an example physical infrastructure configured to perform various operations on a blockchain according to one or more of the example methods of operation, according to an example embodiment. Referring to FIG. 6A, an example configuration 600A includes a physical infrastructure 610 having a blockchain 620 and an intelligent contract 630, which physical infrastructure 610 may perform any operational steps 612 included in any example embodiment. According to various embodiments, step/operation 612 may comprise: a simplified state diagram of different parties in a multi-party process is implemented. Steps may represent output information or write information written to or read from one or more intelligent contracts 630 and/or blockchains 620 residing on physical infrastructure 610 of the computer system configuration. Data may be output from the executing intelligent contracts 630 and/or blockchain 620. Physical infrastructure 610 may include one or more computers, servers, processors, memories, and/or wireless communication devices.

FIG. 6B illustrates an example intelligent contract configuration between contract parties and an intermediary server configured to execute intelligent contract terms on a blockchain, according to an example embodiment. Referring to FIG. 6B, configuration 650B may represent a communication session, an asset transfer session, or a multi-party process or procedure driven by an intelligent contract 630 that explicitly identifies one or more user devices 652 and/or 656. The execution, operations, and results of the smart contract execution may be managed by the server 654. The contents of intelligent contract 630 may need to be digitally signed by one or more of entities 652 and 656, which entities 652 and 656 are both parties to the intelligent contract transaction. The results of the intelligent contract execution may be written to the blockchain as blockchain transactions.

FIG. 6C illustrates an example intelligent contract configuration intermediary between contract parties and an intermediary server configured to execute intelligent contract terms on a blockchain, according to an example embodiment. Referring to FIG. 6C, configuration 650 may represent a modified data file authentication session, communication session, asset transfer session, or a process or procedure driven by intelligence contract 630 that explicitly identifies one or more user devices 652 and/or 656. The execution, operations, and results of the smart contract execution may be managed by the server 654. The contents of intelligent contract 630 may need to be digitally signed by one or more of entities 652 and 656, which entities 652 and 656 are both parties to the intelligent contract transaction. The results of the intelligent contract execution may be written to blockchain 620 as blockchain transactions. The smart contracts 630 reside on a blockchain 620, which blockchain 620 may reside on one or more computers, servers, processors, memories, and/or wireless communication devices.

FIG. 6D illustrates a common interface for accessing logic and data of a blockchain in accordance with an example embodiment. Referring to the example of fig. 6D, an Application Programming Interface (API) gateway 662 provides a common interface for accessing blockchain logic (e.g., smart contracts 630 or other chain codes) and data (e.g., distributed ledgers, etc.). In this example, API gateway 662 is a common interface for performing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 652 and 656 to the blockchain peer (i.e., server 654). Server 654 is a blockchain network peer component that maintains a copy of the world state (which may include a key-value store) within a distributed ledger, allowing clients 652 and 656 to query data about the world state and to submit transactions into the blockchain network where the endorsement peer will run the intelligent contract 630 according to the intelligent contract 630 and the endorsement policy.

Fig. 7A illustrates a process 700 of adding a new chunk 730 to a distributed ledger 720, according to an example embodiment, and fig. 7B illustrates the contents of a chunk structure 730 for a blockchain, according to an example embodiment. Referring to fig. 7A, a client (not shown) may submit transactions to block link points 711, 712, and/or 713. The client may be instructions received from any source for enacting activities on the blockchain. As an example, a client may be an application (based on an SDK) that acts on behalf of a requestor (such as a device, person, or entity) to present transactions to a blockchain. Multiple blockchain peer nodes (e.g., blockchain nodes 711, 712, and 713) may maintain a state of the blockchain network and a copy of distributed ledger 720.

Different types of blockchain nodes/peers may exist in the blockchain network, including endorsement peers that simulate and endorse transactions proposed by clients and commit peers that verify endorsements, validate transactions, and commit transactions to ledger 720. In this example, tile link points 711, 712, and 713 may perform the roles of an endorsement node, a commit node, or both. As described herein, a transaction may include a send event, a receive event, a store event, etc. in a multi-party process that is implemented between multiple untrusted organizations.

Distributed ledger 720 includes a blockchain 722 that stores immutable sequential records in the form of blocks and a state database 724 that maintains the current state (key values) of blockchain 722. There may be one distributed ledger 720 per channel, and each peer node maintains its own copy of distributed ledger 720 for each channel of which they are a member. Block chain 722 is a transaction log that is structured as hash-linked blocks, where each block comprises a sequence of N transactions. A tile (e.g., tile 730) may include various components, such as the components shown in fig. 7B. The linking of tiles may be generated by adding a hash of the header of the previous tile within the tile header of the current tile (shown by the arrows in fig. 7A). In this manner, all transactions on blockchain 722 are ordered and cryptographically linked together, thereby preventing tampering with the blockchain data without breaking the hash link. Further, due to the link, the newest block in block chain 722 represents each transaction that comes before it. Blockchain 722 may be stored on a peer node file system (either a local storage file system or an attached storage file system) that supports only attached blockchain workloads.

The current state of blockchain 722 and distributed ledger 720 may be stored in state database 724. Here, the current state data represents the latest value for all keys included in the chain transaction log of blockchain 722. The chain code call executes the transaction against the current state in the state database 724. In order for these chain code interactions to be very efficient, the latest values for all keys may be stored in the state database 724. State database 724 may include an indexed view of the transaction logs of blockchain 722 and, therefore, state database 724 may be regenerated from the chain at any time. The state database 724 may be automatically restored (or generated, if desired) after peer startup, before the transaction is accepted.

The endorsement node receives a transaction from the client and endorses the transaction based on the simulation results. The endorsement node holds intelligent contracts that model the transaction proposal. For authentication, the endorsement node may attempt to decrypt the hashed, modified data file using the public key of the node performing the hash. The nodes required to endorse a transaction depend on the endorsement policy that may be specified within the chain code. An example of an endorsement policy is "most endorsement peer nodes must endorse a transaction". Different channels may have different endorsement policies. The endorsed transaction is forwarded by the client application to the ordering service 710.

The ordering service 710 accepts endorsed transactions, orders them into blocks, and delivers the blocks to the submitting peer. For example, the ordering service 710 may initiate a new chunk when a transaction threshold has been reached, a timer times out, or another condition. In the example of fig. 7A, block chaining point 712 is a commit peer node that has received a new data block 730 for storage on block chain 722.

The ranking service 710 may be comprised of a set of ranking service nodes. The ordering service 710 does not process transactions, smart contracts, or maintain shared ledgers. Rather, ordering service 710 may accept endorsed transactions and specify an order in which those transactions are committed to distributed ledger 720. The architecture of the blockchain network may be designed such that specific implementations of 'ordering' (e.g., Solo, Kafka, BFT, etc.) become pluggable components.

The transactions are written to distributed ledger 720 in a consistent order. The order of transactions is established to ensure that updates to state database 724 are valid when they are committed to the network. Unlike cryptocurrency blockchain systems (e.g., bitcoins, etc.) where ordering occurs by solving cryptographic challenges or mining, in this example, the parties to distributed ledger 720 may select the ordering mechanism that best fits the network, such as ordering in chronological order.

When ordering service 710 initializes new chunk 730, new chunk 730 may be broadcast to the submitting peer nodes (e.g., blockchain nodes 711, 712, and 713). In response, each commit peer validates the transaction within new block 730 by checking to ensure that the read and write sets still match the current world state in state database 724. In particular, the commit peer may determine whether the read data present at the time the endorsement node mimics the transaction is the same as the current world state in the state database 724. When a peer node is committed to validate a transaction, the transaction is written to blockchain 722 on distributed ledger 720 and state database 724 is updated with the write data in the read-write set. If the transaction fails, i.e., if the committing peer finds that the read-write set does not match the current world state in state database 724, then the transaction ordered into the block will still be included in the block, but it will be marked invalid and state database 724 will not be updated.

Referring to fig. 7B, a chunk 730 (also referred to as a data chunk) stored on a chunk chain 722 of distributed ledger 720 may include multiple data segments, such as a chunk header 732, chunk data 734, and chunk metadata 736. It should be appreciated that the various depicted blocks and their contents, such as block 730 and its contents shown in fig. 7B, are for example purposes only and are not meant to limit the scope of example embodiments. In some cases, both chunk header 732 and chunk metadata 736 may be smaller than chunk data 734, which stores the transaction data, however, this is not a requirement. Block 730 may store transaction information for N transactions (e.g., 100, 500, 1000, 2000, 3000, etc.) within block data 734. According to various embodiments, each transaction may include multi-party process data 735 within chunk data 734 added by sorting node 710. The multi-party process data 735 may include an identification of the current step being performed, the send and receive events performed during that step, and the like.

Block 730 may also include within block header 732 a link to a previous block (e.g., on block chain 722 in fig. 7A). In particular, the chunk header 732 may include a hash of the header of the previous chunk. The chunk header 732 may also include a unique chunk number, a hash of the chunk data 734 for the current chunk 730, and the like. The block number of block 730 may be unique and assigned in an incremental/sequential order starting from zero. The first block in a chain of blocks may be referred to as an originating block, which includes information about the chain of blocks, its number, data stored therein, etc.

Chunk data 734 may store transaction information for each transaction recorded within chunk 730. For example, transaction data stored within chunk data 734 may include one or more of the following: transaction type, version, timestamp (e.g., last calculated timestamp, etc.), channel ID of distributed ledger 720, transaction ID, age, payload visibility, chain code path (deployment tx), chain code name, chain code version, inputs (chain code and function), customer (creator) identification (such as public keys and certificates), customer signature, identity of endorsement node, endorsement node signature, proposal hash, chain code event, response status, namespace, read set (list of keys and versions read by transaction, etc.), write set (list of keys and values, etc.), start key, end key, key list, Merkel (Merkel) tree query digest, etc. Transaction data may be stored for each of the N transactions.

Chunk metadata 736 may store a plurality of metadata fields (e.g., as a byte array, etc.). The metadata fields may include a signature at tile creation, a reference to the last configured tile, a transaction filter that identifies valid and invalid transactions within the tile, a last offset that is persistent to the ordering service that orders the tiles, and the like. Signatures, last configuration chunk, and sequencing service node metadata may be added by the sequencing service 710. Meanwhile, a commit node of the block (such as block chain link point 712) may add valid/invalid information based on an endorsement policy, verification of read/write sets, etc. The transaction filter may include an array of bytes equal in size to the number of transactions in block data 734 and an authentication code that identifies whether the transaction is valid/invalid.

The above embodiments may be implemented in hardware, in a computer program executed by a processor, in firmware, or in a combination of the above. The computer program may be embodied on a computer readable medium, such as a storage medium. For example, a computer program may reside in random access memory ("RAM"), flash memory, read-only memory ("ROM"), erasable programmable read-only memory ("EPROM"), electrically erasable programmable read-only memory ("EEPROM"), registers, a hard disk, a removable disk, a compact disk read-only memory ("CD-ROM"), or any other form of storage medium known in the art.

An exemplary storage medium may be coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an application specific integrated circuit ("ASIC"). In the alternative, the processor and the storage medium may reside as discrete components. For example, fig. 8 illustrates an example computer system architecture 800, which example computer system architecture 800 may represent or be integrated within any of the components described above, and so on.

FIG. 8 is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the application described herein. In any case, the computing node 800 can be enabled and/or capable of performing any of the functionality set forth above. For example, the computing node 800 may perform the method illustrated and described with respect to fig. 5.

In computing node 800, there is a computer system/server 802, the computer system/server 802 is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with computer system/server 702 include, but are not limited to: personal computer systems, server computer systems, thin clients, thick clients, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computer systems, distributed cloud computing environments that include any of the above systems or devices, and the like.

Computer system/server 802 may be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer system/server 802 may be practiced in distributed cloud computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.

As shown in fig. 8, computer system/server 802 in cloud computer node 800 is in the form of a general purpose computing device. Components of computer system/server 802 may include, but are not limited to: one or more processors or processing units 804, a system memory 806, and a bus connecting the various system components (including the system memory 806 and the processing unit 804).

A bus represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, such architectures include, but are not limited to, Industry Standard Architecture (ISA) bus, micro-channel architecture (MAC) bus, enhanced ISA bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.

Computer system/server 802 typically includes a variety of computer system readable media. Such media can be any available media that can be accessed by computer system/server 802 and includes both volatile and nonvolatile media, removable and non-removable media. The system memory 806, in one embodiment, implements the flow diagrams of the other figures. The system memory 806 may include computer system readable media in the form of volatile memory, such as Random Access Memory (RAM)810 and/or cache memory 812. Computer system/server 802 may further include other removable/non-removable, volatile/nonvolatile computer system storage media. By way of example only, the storage system 814 may be used to read from and write to non-removable, nonvolatile magnetic media (not shown, but commonly referred to as "hard drives"). Although not shown, a magnetic disk drive for reading from and writing to a removable nonvolatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading from or writing to a removable nonvolatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to the bus by one or more data media interfaces. As will be further depicted and described below, memory 806 may include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the invention.

Program/utility 816, having a set (at least one) of program modules 818, may be stored in, for example, memory 806, such program modules 42 including, but not limited to, an operating system, one or more application programs, other program modules, and program data. Each of these examples, or some combination thereof, may include an implementation of a network environment. Program modules 818 generally perform the functions and/or methodologies of the various described embodiments of the invention.

As will be appreciated by one skilled in the art, various aspects of the present application may be embodied as a system, method or computer program product. Accordingly, various aspects of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," module "or" system. Furthermore, various aspects of the present application may take the form of a computer program product embodied in one or more computer-readable media having computer-readable program code embodied thereon.

The computer system/server 802 may also communicate with one or more external devices 820 (e.g., keyboard, pointing device, display 822, etc.), with one or more devices that enable a user to interact with the computer system/server 802, and/or with any devices (e.g., network card, modem, etc.) that enable the computer system/server 802 to communicate with one or more other computing devices. Such communication may occur through input/output (I/O) interfaces 824. Also, computer system/server 802 can communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN) and/or a public network such as the Internet) via network adapter 826. As shown, network adapter 826 communicates with the other components of computer system/server 802 via a bus. It should be appreciated that although not shown in the figures, other hardware and/or software components may be used in conjunction with computer system/server 802. Examples include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.

Although an exemplary embodiment of at least one of the systems, methods and non-transitory computer readable media has been illustrated in the accompanying drawings and described in the foregoing detailed description, it will be understood that the application is not limited to the disclosed embodiments, but is capable of numerous rearrangements, modifications and substitutions as set forth and defined by the following claims. For example, the capabilities of the systems in the various figures may be performed by one or more of the modules or components described herein or in a distributed architecture and may include a transmitter, a receiver, or a pair of a transmitter and a receiver. For example, all or a portion of the functionality performed by the individual modules may be performed by one or more of the modules. Further, the functionality described herein may be performed at various times and in relation to various events, either internal or external to the module or component. Also, information transmitted between the respective modules may be transmitted between the modules via at least one of: data networks, the internet, voice networks, internet protocol networks, wireless devices, wired devices, and/or via multiple protocols. Further, messages sent or received by any of the modules may be sent or received directly and/or via one or more other modules.

Those skilled in the art will appreciate that a "system" may be implemented as a personal computer, a server, a console, a Personal Digital Assistant (PDA), a cellular telephone, a tablet computing device, a smart phone, or any other suitable computing device or combination of devices. The presentation of the above-described functions as being performed by a "system" is not intended to limit the scope of the present application in any way, but rather is intended to provide one example of many embodiments. Indeed, the methods, systems, and apparatus disclosed herein may be implemented in a localized and distributed form consistent with computing techniques.

It should be noted that some of the system features described in this specification have been presented as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom Very Large Scale Integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, or the like.

Modules may also be implemented, at least in part, in software for execution by various types of processors. An identified unit of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module. Further, the modules may be stored on a computer readable medium, which may be, for example, a hard disk drive, a flash memory device, a Random Access Memory (RAM), a magnetic tape, or any other such medium used to store data.

Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network.

It will be readily understood that the components of the present application, as generally described and illustrated in the figures herein, could be arranged and designed in a wide variety of different configurations. Therefore, the detailed description of the embodiments is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments of the application.

Those of ordinary skill in the art will readily appreciate that the above may be practiced with steps in a different order and/or with hardware elements in configurations other than those disclosed. Thus, while the present application has been described based upon these preferred embodiments, it would be apparent to those skilled in the art that certain modifications, variations, and alternative constructions would be apparent.

While the preferred embodiments of the present application have been described, it is to be understood that the described embodiments are illustrative only, and that the scope of the present application is to be limited only by the appended claims when considered in light of the full range of equivalents and modifications thereto (e.g., protocols, hardware devices, software platforms, etc.).

Claims (35)

1. A computing system, comprising:

a storage device;

a network interface configured to receive, via a blockchain, a plurality of state representations of a plurality of off-chain systems for a multi-party process, wherein each state representation identifies a transmit event and a receive event of a respective off-chain system; and

a processor configured to remove one or more events from a state representation of an out-of-chain system to generate a reduced state representation, generate an executable chain code for the block chain based on the plurality of state representations including the reduced state representation, and store the generated chain code via the storage device.

2. The computing system of claim 1, wherein the processor is further configured to transform a process description of the multi-party process to the plurality of state representations, the multi-party process including process steps between the plurality of off-chain systems and the blockchain.

3. The computing system of claim 2, wherein the blockchain is an intermediate communication system between the plurality of off-chain systems within the multi-party process.

4. The computing system of claim 1, wherein the network interface is further configured to receive a blockchain state representation of a transmit event, a receive event, and a store event that identify the blockchain, and the processor is further configured to generate the chain code based on the blockchain state representation.

5. The computing system of claim 1, wherein the processor is configured to remove the one or more events based on an action performed by the out-of-chain system in association with the one or more events.

6. The computing system of claim 1, wherein the processor is configured to remove a receive event from a set of consecutive receive events within the state representation of the out-of-chain system.

7. The computing system of claim 1, wherein the processor is configured to remove multiple receive events of the out-of-chain system while the processor is configured to retain all transmit events of the out-of-chain system.

8. The computing system of claim 1, wherein the state representation comprises a state diagram in which events are represented by nodes in the state diagram, and the nodes are arranged based on an order in which the events occur within the multi-party process.

9. A method, comprising:

receiving, via a blockchain, a plurality of state representations for a plurality of off-chain systems performing a multi-party process, wherein each state representation identifies a transmit event and a receive event for a respective off-chain system;

removing one or more events from the state representation of the out-of-chain system to generate a simplified state representation;

generating an executable chain code for the block chain based on the plurality of state representations including the simplified state representation; and

storing the generated chain code via block link points of the block chain.

10. The method of claim 9, further comprising: transforming a process description of the multi-party process to the plurality of state representations, the multi-party process including process steps between the plurality of off-chain systems and the blockchain.

11. The method of claim 10, wherein the blockchain is an intermediate communication system between the plurality of off-link systems within the multi-party process.

12. The method of claim 9, wherein the receiving further comprises: receiving a blockchain state representation identifying a transmit event, a receive event, and a store event of the blockchain, and the generating of the chain code is further performed based on the blockchain state representation.

13. The method of claim 9, wherein the removing comprises: removing the one or more events based on actions performed by the out-of-chain system during the one or more events.

14. The method of claim 9, wherein the removing comprises: removing a receive event from a set of consecutive receive events within the state representation of the out-of-chain system.

15. The method of claim 9, wherein the removing comprises: removing a plurality of receive events of the out-of-chain system while retaining all transmit events of the out-of-chain system.

16. The method of claim 9, wherein the state representation comprises a state diagram in which events are represented by nodes in the state diagram, and the nodes are arranged based on an order in which corresponding events occur within the multi-party process.

17. A non-transitory computer readable medium comprising instructions that when read by a processor cause the processor to perform the method of any of claims 9 to 16.

18. A computing system, comprising:

a storage device configured to store chain code comprising executable steps of a multi-party process generated from a state diagram in which a blockchain is an intermediary between a plurality of out-of-chain systems;

a network interface configured to receive a request to execute the multi-party process; and

a processor configured to process steps of the multi-party process via execution of the stored chain code to generate processing results for the steps based on the request, the stored chain code including the executable steps of the multi-party process, and store an identification of the processed steps and the generated processing results via data chunks in a hashed linked chain of data chunks of the chain of chunks.

19. The computing system of claim 18, wherein the chain code is based on one or more simplified state diagrams for one or more of the out-of-chain systems in which at least one receive event has been removed.

20. The computing system of claim 18, wherein the processor is configured to store a current execution state of an out-of-chain system included within the multi-party process.

21. The computing system of claim 18, wherein the processor is configured to store events sent and/or received by an out-of-chain system that occur via execution of the processed steps of the multi-party process.

22. The computing system of claim 18, wherein the state diagram comprises a plurality of simplified state diagrams of the multi-party process for the plurality of out-of-chain systems of the multi-party process, respectively.

23. The computing system of claim 18, wherein the processor is further configured to verify blockchain results via a plurality of peer nodes.

24. The computing system of claim 18, wherein the multi-party process comprises a shared process performed by the plurality of off-chain systems and the blockchain.

25. The computing system of claim 18, wherein the processor is further configured to: processing a next executable step of the multi-party process via the blockchain based on a result of the processed step of the multi-party process processed by the blockchain.

26. A method, comprising:

storing chain code comprising executable steps of a multi-party process generated from a state diagram in which a blockchain is an intermediary between a plurality of out-of-chain systems;

receiving a request to execute the multi-party process;

processing steps of the multi-party process via execution of the stored chain code to generate processing results for the steps based on the request, the stored chain code including the executable steps of the multi-party process; and

storing, via a data chunk in a hash-linked chain of data chunks of the chain of chunks, an identification of the step that was processed and the generated processing result.

27. The method of claim 26, wherein the chain code is based on one or more simplified state diagrams for one or more of the out-of-chain systems in which at least one receive event has been removed.

28. The method of claim 26, wherein storing the identification of the step that was processed comprises: storing a current execution state of an out-of-chain system included within the multi-party process.

29. The method of claim 26, wherein storing the identification of the step that was processed comprises: storing events sent and/or received by an off-chain system during the execution of the processed steps of the multi-party process.

30. The method of claim 26, wherein the state diagram comprises a plurality of simplified state diagrams of the multi-party process for the plurality of out-of-chain systems of the multi-party process, respectively.

31. The method of claim 26, further comprising: a plurality of peer nodes is used to verify the block chaining result generated during the processing.

32. The method of claim 26, wherein the multi-party process comprises a shared process performed by the plurality of off-chain systems and the blockchain.

33. The method of claim 26, further comprising: processing a next executable step of the multi-party process via the blockchain based on a result of the processed step of the multi-party process processed by the blockchain.

34. A non-transitory computer readable medium comprising instructions that when read by a processor cause the processor to perform the method according to any one of claims 26 to 33.

35. A computer system, the computer system comprising: a model to perform the steps of any method according to claims 9 to 16 and claims 26 to 33.

Images