CN111125242B - Transformation across organizational processes for execution via blockchain - Google Patents

Abstract

Embodiments of the present disclosure relate to transformation of cross-organizational processes for execution via blockchain. Example operations may include one or more of the following: receiving 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; removing one or more events from the state representation of the off-chain system to generate a simplified state representation; generating executable chain code for the blockchain based on the plurality of state representations including the reduced state representation; and storing the generated chain code via a blockchain node of the blockchain.

Description

Transformation across organizational processes for execution via blockchain

Technical Field

The present application relates generally to processes performed via blockchain, and more particularly to a system that transforms a multi-organization process including blockchain mediation into multiple state diagrams and performs the multi-organization process via the blockchain based on the multiple state diagrams.

Background

The 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 operate on a centralized database simultaneously based on a client/server configuration. Because of its single location, the centralized database is easy to manage, maintain, and control, particularly for security purposes. Within a centralized database, data integrity is maximized and data redundancy is minimized, since a single storage location for all data also means that a given data set has only one primary record. This helps to maintain data as accurately and consistently as possible and enhances data reliability.

However, centralized databases have significant drawbacks. For example, a centralized database has a single point of failure. In particular, if there is no fault tolerant setting and a hardware failure occurs, all data in the database will be lost and all users' work is 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: bottlenecks may occur when a centralized database experiences large traffic. Furthermore, the centralized database provides limited access to the data because 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 at the same time without causing problems, such as overwriting the necessary data. Furthermore, since the central database reaches a minimum of no data redundancy, if a data set is accidentally lost, it may be difficult to retrieve the data set other than by manual manipulation of the backup disk storage.

Recently, organizations have begun to cooperate via blockchains to implement multi-tissue processes. However, these processes are typically implemented inefficiently between the blockchain and the participating organization, requiring redundant transmission, reception, storage, etc. Thus, there is a need for a mechanism for efficiently implementing a cross-organization process via a blockchain.

Disclosure of Invention

An example embodiment may provide a system comprising one or more of the following: 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 off-chain system to generate a simplified state representation; generating executable chain code for the blockchain based on a plurality of state representations including the reduced 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 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; removing one or more events from the state representation of the off-chain system to generate a simplified state representation; generating executable chain code for the blockchain based on a plurality of state representations including the reduced state representation; and storing the generated chain code via a blockchain node of the blockchain.

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: receiving 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; removing one or more events from the state representation of the off-chain system to generate a simplified state representation; generating executable chain code for the blockchain based on a plurality of state representations including the reduced state representation; and storing the generated chain code via a blockchain node of the blockchain.

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

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

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: storing chain code, the chain code comprising executable steps of a multiparty process generated from a state diagram in which a blockchain is an intermediary between a plurality of extrachain systems; receiving a request to execute a multiparty process; processing steps of the multiparty process via execution of a stored chain code based on the request to generate a processing result for the steps, the stored chain code comprising executable steps of the multiparty process; and storing the identification of the processing step and the generated processing result via data blocks in the middle of the hashed chain of data blocks of the blockchain.

Drawings

FIG. 1A is a schematic diagram illustrating a blockchain-mediated shared processing environment in accordance with example embodiments.

FIG. 1B is a schematic diagram illustrating transforming a process description into a plurality of 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 according to an example embodiment.

Fig. 2A is a schematic diagram illustrating a peer-to-peer node blockchain architecture configuration for an asset sharing scenario in accordance with example embodiments.

Fig. 2B is a schematic diagram illustrating a peer blockchain configuration in accordance with an example embodiment.

Fig. 3 is a schematic diagram illustrating a licensed blockchain network in accordance with example embodiments.

Fig. 4A to 4D are diagrams illustrating a state diagram created through a transformation 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 multiparty process according to an example embodiment.

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

Fig. 5B is a schematic diagram illustrating a method of performing a multi-tissue process via a blockchain in accordance with an example embodiment.

Fig. 6A is a diagram illustrating a physical infrastructure configured to perform various operations on a blockchain according to one or more operations described herein, according to example embodiments.

FIG. 6B is a diagram illustrating an intelligent contract configuration intermediate contract parties and an intermediary server configured to perform intelligent contract terms on a blockchain in accordance with example embodiments.

FIG. 6C is a diagram illustrating an intelligent contract configuration intermediate contract parties and an intermediary server configured to perform intelligent contract terms on a blockchain in accordance with example embodiments.

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

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

FIG. 7B is a schematic diagram illustrating the contents of a data chunk structure for a blockchain, 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 of these figures, 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 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 application, as claimed, but is merely representative of selected embodiments.

These features, structures, or characteristics may be combined in any suitable manner in one or more embodiments as described throughout this specification. For example, the use of the phrases "an example embodiment," "some embodiments," or other similar language throughout this specification may, for example, refer to the fact that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment. Thus, appearances of the phrases "exemplary embodiment," "in some embodiments," "in other embodiments," or other similar language throughout this specification do not necessarily all refer 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, while the term "message" may have been used to describe an embodiment, the application may be applied to many types of network data, such as packets (packets), frames, datagrams, and the like. The term "message" also includes packets, frames, datagrams and any equivalents thereof. Furthermore, although certain types of messages and signaling may be depicted in the exemplary embodiments, they are not limited to certain types of messages and the application is not limited to certain types of signaling.

Example embodiments provide methods, systems, non-transitory computer readable media, devices, and/or networks that transform a multi-tissue process description into chain code that may be implemented via a blockchain.

A distributed database is a distributed storage system that includes a plurality of nodes that communicate with each other. Blockchains are examples of decentralized databases that include just additional immutable data structures similar to a distributed ledger that can maintain records between mutually untrusted parties. The 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 peers. For example, a peer node may execute a consensus protocol to validate blockchain storage transactions, aggregate (group) storage transactions into chunks, and build hash chains over chunks. The process forms a ledger by ordering stored transactions as needed to achieve consistency. In a public blockchain or license-exempt blockchain, anyone can participate without the need for a specific identity. Public blockchains typically involve local cryptocurrency and use a consensus based on proof of work (PoW). In another aspect, the licensed blockchain database provides the following system: the system may protect mutual communication among a set of entities (such as businesses exchanging funds, goods, information, etc.) that share a common goal but are not fully trusted with each other.

Blockchain operation is customized for a decentralized storage scheme and is referred to as any programmable logic of "smart contracts" or "chain codes". In some cases, there may be dedicated chain codes for management functions and parameters, referred to as system chain codes. Smart contracts are trusted distributed applications that utilize the tamper resistant nature of blockchain databases and the underlying protocol between nodes, referred to as endorsement or endorsement policies. In general, blockchain transactions must typically be "endorsed" before they are committed (commit) to the blockchain, while non-endorsed transactions 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 necessary for endorsing. When a client sends a transaction to a peer node specified in the endorsement policy, the transaction is executed to validate the transaction. After validation, the transaction enters an ordering stage in which an ordered sequence of endorsed transactions aggregated into chunks is generated using a consensus protocol.

The nodes are communication entities 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 include different types, such as clients that submit (submit) transaction calls to an endorsement node (e.g., peer node) and broadcast transaction proposals to an ordering service (e.g., ordering node), or submitting client nodes. Another type of node is a peer node that may receive transactions submitted by clients, submit transactions, and maintain the state and copy of the ledger of blockchain transactions. A peer node may also play the role of an endorsement node, but this is not a requirement. An ordering service node (ordering-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 peer nodes in the system when submitting transactions and modifying the world state of the blockchain, which is another name for an initial blockchain transaction that typically includes control information and setup information.

The ledger is an orderly 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, ordering node, endorsement node, peer node, etc.). A transaction may cause a set of asset key pairs to be submitted to the ledger as one or more operands, such as create, update, delete, etc. The ledger includes a blockchain (also referred to as a chain) that is used to store immutable ordered records in blocks. The ledger also includes a status 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 that they are members of.

A chain is a transaction log that is structured as hashed linked chunks, and each chunk includes a sequence of N transactions, where N is equal to or greater than 1. The block header includes a hash of the transaction of the block and a hash of the header of the previous block. In this way, all transactions on the ledger may be ordered and cryptographically linked together. Therefore, it is impossible to tamper with ledger data without breaking the hash link. The hash of the most recently added blockchain chunk represents each transaction on the chain that arrived before it, which may ensure that all peers are in a consistent and trusted state. Chains may be stored on peer node file systems (i.e., local file systems, attached storage file systems, cloud file systems, etc.), effectively supporting only the attached nature of blockchain workloads.

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, since it represents the latest key value known to the channel. The chain code calls for executing transactions against the current state data of the ledger. In order to validate these chain code interactions, the latest values of the keys may be stored in a state database. The state database may be just 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 is started and before the transaction is accepted.

Recently, blockchains have been used as intermediaries between multiple untrusted organizations when performing a sharing process in which each party cooperates with or contributes to the overall process in some way. Multiparty processes (or cross-organization processes) exist in many types of fields, including: banking, healthcare, politics, real estate, law, government, leasing and sharing, education, charity, assistance organizations, and the like. Typically, these processes involve at least transmission events (or send events), reception events where the transmissions are received by parties, and storage events where the occurrence of events is recorded on the blockchain. In this case, the large number of transmit events, receive events, and store events do not change the state of one or more of the parties.

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

Some benefits of the present solution described and depicted herein include: the process model involving all parties is transformed into a separate state representation for each party, simplifying the understanding of each party. Further, embodiments perform reducing the amount of stored events, transmitted events, and received events for all parties within a multiparty process by removing events from the state representation. Moreover, the current step of the multi-party process may be identified by an immutable blockchain 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 decentralized, immutable and secure storage where nodes must share changes in records in the storage. Some properties inherent in and helping to implement a blockchain include, but are not limited to: immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsements, accessibility, etc., which are further described herein.

According to various aspects, smart contracts may be used to implement transformed cross-organizational processes. For example, a smart contract (chain code) may include instructions for executing the simplified state diagrams 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 exemplary embodiments provide a number of benefits over conventional databases. For example, with blockchains, embodiments do not require additional mechanisms for managing consistency and trust among parties with a conflict of interest, which can 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 multiparty data.

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

FIG. 1B illustrates an example of a process 100B that transforms a process model into a plurality of state diagrams, and then transforms the state diagrams into simplified state diagrams. 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 through 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 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 its corresponding state diagram. The state diagram identifies events to be performed by the respective parties during the multiparty process 110. According to various embodiments, the plurality of state diagrams 131-134 may have one or more events removed therefrom to create 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 steps performed by each party for the multi-party process 110 shown in FIG. 1A. Here, the parties include a customer 122, an underwriter 124, and an inspector 126 who perform an 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 the cross-organization business process has long been a long-standing challenge for the IT industry. In a centralized business (business) process within an organization, information about the activities of the enterprise can be shared and verified, and participants of the process trust each other. However, in a cross-organization process, when process control is handed over to participants outside the organization, other parties cannot verify data accuracy, perform obligations, or check whether conditions are met. As a result, moving control between segmented processes of different organizations often results in inconsistent and untrusted process management.

The cross-organization business process blockchain may be used as a solution to the consistency and trust problems in managing cross-organization business processes. Transactions in a business process network across an organization may be shared and validated by participants, a mechanism that does not require the participants to trust each other. Transactions between participants may also be handled by smart contracts (also known as chain 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 the blockchain as shown in fig. 1A.

While blockchain technology may help to change the level of integration and automation, using blockchains to manage cross-fabric business processes presents other challenges, including: defining the entire workflow of the cross-organizational boundary control process, 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 challenges mentioned above, 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 smart 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 a process model into a state diagram and are used to optimize the generated state diagram. Software artifacts may be generated from the state diagram, which are smart contracts and Web applications.

The example embodiment differs from existing studies in that: a simple process diagram (such as the simple process diagram 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 go deep into details about the manner in which messages are exchanged between participants and the manner in which the software process engine, collaboration graph, or orchestration graph support process. The state diagram has the following advantages over other behavioral representations. For example, the state diagrams may represent a blockchain and multiple process participants because the state diagrams communicate with each other by receiving and transmitting events. State diagrams have been standardized and, thus, developer support, including tools and education, has been available. Furthermore, the formal aspects of the state diagram enable precise definition of composition and optimization logic. The state diagram is also nearly implemented, 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 the process model as input and transforms it into a state diagram for the application of blockchain and organization. The organized state diagram is then reduced to an optimized state diagram, and using the results of the reduced computation, the state diagram for the blockchain is also reduced. To define a process model, a small set of modeling elements may be used, including: a start event that acts as a process trigger; an end event representing a result of the process; activities describing the work that must be done; a sequence flow showing the order in which activities are performed; creating a decision of an alternative flow, wherein only one of the paths can be taken; combining two alternative sequence paths into a combination of paths; lanes that categorize 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 merger, 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 underwriter, 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 underwriter sends a decision (does not accept the claim). After receiving the decision, the client likewise decides whether to accept the decision. In the event that the customer does not accept the decision, she updates the claim and again submits the claim to the underwriter; alternatively, the process terminates. If the inspector accepts the claim, the underwriter makes a payment that will be received by the customer. To define a transformation that takes as input a process model, the process model may be formalized as 5-tuples<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 flow relationship, P is a set of participants, and R: o→ P i is a mapping that associates a flow object with a participant. Flow relationship (o; o';t) represents an object stream from object o to another object o ', the stream type of which o' is indicated by t. When a stream type can be uniquely derived from a source object and a target object, we will not explicitly describe it.

We then 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 in which committed transactions are recorded as changes in state. For individual participants, the state diagram may also be used for behavior descriptions that provide the basis for interface specifications and implementation of functions. Additionally, interactions between process participants and blockchains can be modeled as a set of state diagrams that send and receive events for which communications are intended. Thus, the use of state diagrams to represent blockchain and process participant behavior and interactions is considered a promising approach. When a state diagram is used to represent a 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 participants a and B. Here we use arrows to denote the transition from one state s to another state s', with the label e/a ₁ 、...、a _n Wherein e is the event to be received and a when a transition occurs ₁ 、...、a _n Is the event to be transmitted. We also describe the/a in case of transition without receiving event or sending event, respectively ₁ 、...、a _n And e.

All state diagrams are in the first state s ₁ ，And->Starting. When the object stream goes active, the blockchain sends event b ^A And b ^B And transitions to state s2. When b is received ^A And b ^B At this time, participants A and B respectively transition to state +.>And->After the end of the activity, participant A transitions to state +.>And send event f ^A The event f ^A Will be received by the blockchain. The blockchain then transitions to state s ³ And transmits 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 in accordance with example embodiments. Referring to FIG. 2A, a blockchain architecture 200 may include certain blockchain elements, such as a set of blockchain nodes 202. Blockchain node 202 may include one or more nodes 204 through 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-210 may endorse transactions based on an endorsement policy and may provide ordering services for all blockchain points in the architecture 200. The blockchain node may initiate blockchain authentication and seek to write to a blockchain immutable ledger stored in the blockchain layer 216, a copy of which may also be stored on the 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, smart contracts, etc.), the stored program/application code 220 may be created according to the custom configuration sought by the participants, 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 through 210 via attachment to a distributed ledger.

The 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 rights to auditors seeking access to data items. The blockchain layer 216 may expose interfaces that provide access to the virtual execution environment necessary to handle the program code and interface with the physical infrastructure 214. 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 the program/application code 220 via the exposed interface or interfaces and services provided by the 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 through 210 in the form of smart contracts and associated chain code with conditions and other code elements affected by its execution. As a non-limiting example, smart contracts may be created to perform reminders, updates, and/or other notifications 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 the state diagram that has been transformed from the process description. The smart contract itself may be used to identify rules associated with authorization and access requirements and the use of the ledger. In this example, the read set 226 may be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216. Write set 228 may include changes to key values. The physical infrastructure 214 may be utilized to retrieve any of the data or information described herein.

Within the chain code, smart contracts can be created via high-level application and programming languages and then written to blocks in the blockchain. The smart 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 execution of smart contract code that may be executed in response to a condition associated with satisfying a smart contract. Executing the smart contract may trigger trusted modification(s) of the state of the digital blockchain ledger. The modification(s) to the blockchain ledger caused by the execution of the smart contract may be automatically replicated throughout the distributed network of blockchain peer nodes by one or more consensus protocols.

The smart contract may write data to the blockchain in the format of key-value pairs. Further, the smart contract code may read values stored in the blockchain and use them in application operations. The smart contract code may write the output of various logical operations to the blockchain. 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 temporary data used/generated by the smart contract in memory and then deletes it once the data needed for the blockchain is identified. According to various embodiments, the read-set 226 may include the current processing steps of a multiparty process. Meanwhile, the writeset 228 may include results of execution of the processing steps, which may include identification of the steps, transmit events and receive events executed during the processing steps, and so forth.

The chain code may include a code interpretation of the smart contract with additional features. As described herein, the chain code may be program code deployed on a computing network, where the chain code is executed and verified together by a chain verifier during a consensus process. The chain code may be generated based on the blockchain and multiple state diagrams of multiple off-chain systems. The chain code receives the hash and retrieves from the blockchain the hash associated with the data template created using the previously stored feature extractor. If the hash of the hash identifier matches the hash created from the stored identifier template data, the chain code sends an 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: the transaction proposal 291 is sent by the application client node 260 to the endorsing peer node 281. The endorsing peer 281 may verify the client signature and perform chain code functions to initiate the transaction. The output may include the chain code result, a set of key/value versions read in the chain code (read set), and a set of keys/values written in the chain code (write set). If approved, proposal response 292 is sent back to 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 transactions as blocks to all peer nodes 281 to 283 on the tunnel. Each peer node 281 to 283 may validate the transaction before committing to the blockchain. For example, the peer node may check an endorsement policy to ensure that the properly assigned peer node has signed the result and has 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, communities, companies, users, agents, and/or the like). Transaction 291 may identify the current step to be performed, or transaction 291 may not identify the current step to be performed. The chain code may be capable of determining a next step to be performed in the multiparty process based on a current key value for a state of the multiparty process that is stored on a distributed ledger (e.g., world state database, blockchain, etc.). The request may be endorsed by one or more peer nodes and, after successful endorsement, may be forwarded to the ordering node for inclusion within the data chunk and storage in the middle of the blockchain.

The client node 260 may initiate the transaction 291 by constructing and sending a request to the peer node 281, which is an endorsement node. The transaction proposal 291 may include a request to store information about the execution results of the 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., web application, etc.) that utilizes a supported Software Development Kit (SDK), such as NODE, JAVA, PYTHON, etc., that utilizes available APIs to generate the proposal. Transaction proposal 291 is a request to invoke a chain code function so that data can be read and/or written to a ledger (i.e., a new key-value pair written for an asset). The SDK may be used as a shim (shim) that packages the transaction proposal into an appropriate architectural format (e.g., through a protocol buffer of a Remote Procedure Call (RPC)) and obtains the client's cryptographic credentials to generate a unique signature for the transaction proposal.

In response, the endorsing peer 281 may verify: (a) well-formed transaction proposals, (b) transactions that have not been submitted in the past (replay-attack protection), (c) the signature is valid, and (d) the presenter (in this example, client 260) is properly authorized to perform the proposed operation on the channel. The endorsement peer 281 may treat the transaction proposal input as an argument of the invoked chain code function. The chain code is then executed against the current state database to produce a transaction result that includes a response value, a read set, and a write set. According to various embodiments, the transaction results may include results of performing the current steps of the multiparty process. At this time, however, the ledger is not updated. At 292, the set of values is passed back as a proposal response 292 to the SDK of the client 260, along with the signature of the endorsing peer node 281, which parses the payload for use by the application.

In response, the application of client 260 checks/verifies the endorsed 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 examine the query response and will typically not submit the transaction to the ordering node service 284. If the client application intends to submit a transaction to ordering node service 284 to update the ledger, the application determines whether the specified endorsement policy has been met prior to the submission (i.e., all peer nodes required for the transaction do not endorse the transaction). Here, a client may include only one of the parties to a 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 the application chooses not to check for a response or otherwise forward an un-endorsed transaction, the endorsement policy will still be enforced by the peer node and supported during the commit validation phase.

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

The chunks of transactions are delivered from ordering node 284 to all peer nodes 281 to 283 on the tunnel. Transactions 294 within the block are validated to ensure that any endorsement policies are satisfied and that no changes in ledger state occur for the read set variables, as the read set is generated by the execution of the transaction. Transactions in a block are marked as valid or invalid. Further, in step 295, each peer node 281 to 283 appends a block to the chain of channels and, for each valid transaction, commits the write set to the current state database. An event is issued to inform the client application that the 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 certification 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 can submit a transaction to licensed 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 a REST API, or the like. The trusted enterprise network may provide access to a regulator system 314, such as an auditor (e.g., a securities exchange committee 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 "client". An auditor may be limited to querying a ledger, while a client may be authorized to deploy, invoke, and query certain types of chain codes.

The blockchain developer system 316 compiles the chain code and client-side applications. The blockchain developer system 316 may deploy the chain code directly to the network through the REST interface. To include credentials from the legacy data source 330 in the chain code, the developer system 316 can use the out-of-band connection to access the data. In this example, blockchain user 302 connects to the network through peer node 312. Peer node 312 retrieves the user's enrollment and transaction credentials from certificate authority 318 before proceeding with any transactions. 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 his 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 of a blockchain. Further, fig. 4B-4D illustrate examples of state diagrams 410A, 420A, and 430A for different respective parties (clients, underwriters, vouchers). As shown in the example of fig. 4A, events are represented by nodes 402, these nodes 402 including links 404 therebetween to identify the order of the events. Also, a list 406 of send events and receive events is included alongside 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 parties interacting with the intermediating blockchain.

According to various embodiments, state diagrams (e.g., state diagrams 400A through 430A) may be generated using a sub-process of an traversal 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 based on the types 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. Attached to the transition are a send event and a receive event, which constitute a communication. Logic of the sub-process may generate a state diagram having transitions in which no receive event and/or transmit event occurs. These events may be removed. Functions that take as input tags, participants, and objects and associate these with events that are specific to the combination of these parameters may be used. This function may 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 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 previously created and maintained state by the memory map.

The state diagram generated from the process model may not be optimal because events that trigger activities in the process model are sent to all participants even though the participants are not engaged in the activities. 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 though we eliminate the receive event from the first transition. Since no event is sent from the two state transitions, removing a received event does not change the behavior observed from outside the state diagram. The principle can be generalized to a situation where one 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 received events of incoming transitions that do not send any events. In fig. 4E, s is a state where its outgoing transition does not send any event as shown in 441. Thus, at 442, the process (procedure) may eliminate e1 from the transition from s1 to s. Further, in 443, the system may remove the event-free transition and add a new transition to pass the removed transition. At 444, the system may repeat the removal steps performed at 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 transition at 445.

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

After obtaining the simplified state diagrams for the blockchain and process participants, example embodiments may use the state diagrams to generate software components, including smart contracts and Web applications. FIG. 4H illustrates an overview of an architecture 450 for generating smart contracts and web applications and resulting software artifacts. Example embodiments may rely on a superledger structure (Hyperledger Fabric) being a blockchain framework that is an 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 superledger structure, we use its client SDK, which is intended to be designed for node. Js JavaScript runtime. We have also created web applications that use state transition tables generated from state diagrams and interact with the superledger structure by exchanging events.

In these examples, JSON data may be interpreted by a state diagram engine running on the superledger structure. SCXML may be used as an intermediate language because support tools (such as graphics viewers and execution monitors) are already available, and it encompasses complex constructs such as sub-states and parallel states that facilitate the development of future extensions. When generating a state diagram in SCXML, specific state names and event names may be given. There may be no clues in the input process model for the state names, and thus, uniquely generated names may be assigned to states in the state diagram. Random names may be permissible because state names are not disclosed within the state diagram. However, an event is 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 superledger structure accepts transactions for requesting state diagram operations, such as sending events to the state diagram, which will cause state transitions. Other state diagram operations include: query the current state and access the last received event. An API for interacting with this functionality is provided by the superledger structure SDK and mode. Js, which installs and instantiates the chain code, submits transactions, and monitors events generated by the chain code.

We also generate a web application skeleton whose behavior conforms to the protocol defined by the state diagrams, which are given 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 custom controllers. The UI controller may first create clickable buttons for all send events, enable/disable the buttons according to the current state, and cause a transition when the web application user clicks the enable button. Meanwhile, the event controller may send and receive events through the node. Js server and communicate with the state diagram running as chain code on the blockchain.

We evaluated the effectiveness of our method using two insurance process models: marine insurance covers or destroys ships, cargo and wharfs caused by the sea. It involves importers, exporters and underwriters as participants, and the process model includes 22 objects and 25 flows. Reinsurance is an "insurance of insurance" that is purchased by an insurance company and allows the insurance company to maintain repayment capabilities after a significant claim event. It involves reinsurers, clients (insurers) and inspectors as participants, and the process model includes 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 offshore insurance process and reinsurance process, respectively. They show the number of states, transitions, receive events and transmit events before and after the state diagram is reduced. The state diagram generation produces a set of state diagrams that work together to properly execute the process model, but the resulting state diagram for the blockchain requires a relatively large number of receive events and transmit events (105 events for 22 objects in offshore 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 improve the overall system performance. 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 an application that conforms 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, which may be a computing system. As another example, the method 500 may be performed by an off-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, in 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 state representation. Furthermore, the blockchain may have its own state representation.

In some embodiments, receiving may further comprise: a process description of a multi-party process including 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 out-of-chain systems within the multiparty process. In some embodiments, receiving may further comprise: a blockchain state representation is received that identifies a send event, a receive event, and a store event of the blockchain, and generating a chain code is further performed based on the blockchain state representation.

In 504, the method may include: one or more events are removed from the state representation of the off-chain system to generate a reduced state representation. In some embodiments, events may be removed from each of the state representations. For example, when two consecutive reception events occur, but no transmission event occurs, at least one of the reception events may be removed because it does not change the state of the party. In some embodiments, removing may include: the one or more events are removed based on actions performed by the off-chain system during the one or more events. For example, if the action is to receive an event, the event may be removed in some cases. For example, when a certain receive event in a set of consecutive receive events within the state representation of the off-chain system may be removed. In some embodiments, removing may include: multiple receive events of the off-chain system are removed while retaining all transmit events of the off-chain system.

In 506, the method may include: executable chain code for the blockchain is generated based on a plurality of state representations including the reduced state representation, and in 508, the generated chain code is stored via blockchain nodes of the blockchain. 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 improving the efficiency of the multiparty process by eliminating one or more send events, receive events, store events, etc.

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

In 514, the method may include: a request to perform a multiparty process is received. For example, the request may include: the client node requests to perform a multiparty process. In this case, the chain code may identify which step is next based on the most recently executed step stored in the status 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.

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

In some embodiments, the method may further comprise: multiple peers are used to validate blockchain results generated during processing. In some embodiments, the multiparty 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 multiparty process is processed via the blockchain based on the result of the processing step of the multiparty 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 example embodiments. Referring to FIG. 6A, the example configuration 600A includes a physical infrastructure 610 having a blockchain 620 and a smart contract 630, the physical infrastructure 610 may perform any of the operational steps 612 included in any of the example embodiments. According to various embodiments, step/operation 612 may include: a simplified state diagram of different parties in a multiparty process is executed. The steps may represent output information or written information written or read from one or more intelligent contracts 630 and/or blockchains 620 residing on the physical infrastructure 610 of the computer system configuration. Data may be output from the executing intelligent contracts 630 and/or blockchain 620. The physical infrastructure 610 may include one or more computers, servers, processors, memory, and/or wireless communication devices.

FIG. 6B illustrates an example smart contract configuration intermediate contract parties and an intermediary server configured to perform smart contract terms on a blockchain in accordance with example embodiments. Referring to fig. 6B, configuration 650B may represent a communication session, an asset transfer session, or a multi-party process (process) or procedure (procedure) driven by smart contract 630 that explicitly identifies one or more user devices 652 and/or 656. Execution, operation, and results of execution of the smart contract may be managed by the server 654. The contents of the smart contract 630 may require digital signatures by one or more of the entities 652 and 656, the entities 652 and 656 being both parties to the smart contract transaction. The results of the execution of the smart contract may be written to the blockchain as a blockchain transaction.

FIG. 6C illustrates an example smart contract configuration intermediate contract parties and an intermediary server configured to perform smart contract terms on a blockchain in accordance with example embodiments. Referring to fig. 6C, configuration 650 may represent a modified data file authentication session, a communication session, an asset transfer session, or a process or procedure driven by smart contract 630 that explicitly identifies one or more user devices 652 and/or 656. Execution, operation, and results of execution of the smart contract may be managed by the server 654. The contents of the smart contract 630 may require digital signatures by one or more of the entities 652 and 656, the entities 652 and 656 being both parties to the smart contract transaction. The results of the execution of the smart contract may be written to blockchain 620 as a blockchain transaction. The smart contract 630 resides on a blockchain 620, which blockchain 620 may reside on one or more computers, servers, processors, memory, and/or wireless communication devices.

FIG. 6D illustrates a common interface for accessing logic and data of a blockchain in accordance with example embodiments. 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 executing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 652 and 656 to a blockchain peer node (i.e., server 654). Server 654 is a blockchain network peer component that maintains a copy of world state (which may include a key-value store) within a distributed ledger, allowing clients 652 and 656 to query for data about world state and submit transactions into the blockchain network where an endorsing peer will run the smartcontracts 630 in accordance with smartcontracts 630 and endorsing policies.

Fig. 7A illustrates a process 700 of adding a new tile 730 to a distributed ledger 720 according to an example embodiment, and fig. 7B illustrates the contents of a tile structure 730 for a blockchain according to an example embodiment. Referring to fig. 7A, a client (not shown) may submit a transaction to blockchain nodes 711, 712, and/or 713. The client may be instructions received from any source for formulating an activity on the blockchain. As an example, a client may be an application (SDK-based) that acts on behalf of a requestor (such as a device, person, or entity) to make 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 the distributed ledger 720.

Different types of blockchain nodes/peers may exist in the blockchain network, including endorsing peers that simulate and endorse transactions proposed by clients and submitting peers that verify endorsements, validate transactions, and submit transactions to ledger 720. In this example, blockchain nodes 711, 712, and 713 may perform the role of endorsement nodes, commit nodes, or both. As described herein, a transaction may include a send event, a receive event, a store event, etc. in a multiparty process implemented between multiple untrusted organizations.

Distributed ledger 720 includes blockchain 722 that stores immutable sequential records in blocks and state database 724 that maintains the current state (key value) 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 that they are members of. Blockchain 722 is a transaction log that is structured as hashed linked blocks, wherein each block includes a sequence of N transactions. The block (e.g., block 730) may include various components, such as the components shown in fig. 7B. The linking of the blocks may be generated by adding a hash of the header of the previous block within the block header of the current block (shown by the arrow in fig. 7A). In this way, all transactions on the blockchain 722 are ordered and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash link. Further, due to the link, the latest chunk in blockchain 722 represents each transaction that arrived 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 values for all keys included in the chain transaction log for blockchain 722. The chain code call performs a transaction for the current state in the state database 724. In order to make these chain code interactions 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 log of blockchain 722 and, therefore, state database 724 may be regenerated from the chain at any time. After the peer node is started, the state database 724 may be automatically restored (or generated if needed) before the transaction is accepted.

The endorsement node receives the transaction from the client and endorses the transaction based on the simulation result. The endorsement node maintains an intelligent contract that simulates a 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 can be specified within the chain code. An example of an endorsement policy is "most endorsing peer nodes have to 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 chunks, and delivers chunks to submitting peers. For example, ordering service 710 may initiate a new chunk when a transaction threshold has been reached, when a timer expires, or when another condition. In the example of FIG. 7A, blockchain node 712 is a commit peer node that has received a new data block 730 for storage on blockchain 722.

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

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

When the ordering service 710 initializes a new block 730, the new block 730 may be broadcast to submitting peer nodes (e.g., blockchain nodes 711, 712, and 713). In response, each submitting peer node validates transactions within the new block 730 by checking to ensure that the read set and write set still match the current world state in the state database 724. In particular, the submitting peer node may determine whether the read data present when the endorsing node emulates a transaction is the same as the current world state in state database 724. When a peer node commits 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 submitting peer node finds that the read-write set does not match the current world state in state database 724, the transaction ordered into the chunk will still be included in the chunk, but it will be marked as invalid and the state database 724 will not be updated.

Referring to fig. 7B, a block 730 (also referred to as a data block) stored on blockchain 722 of distributed ledger 720 may include a plurality of data segments, such as a block header 732, block data 734, and block metadata 736. It should be understood that the various depicted blocks and their contents (such as block 730 and its contents shown in fig. 7B) are for illustrative purposes only and are not meant to limit the scope of the example embodiments. In some cases, both the block header 732 and the block metadata 736 may be smaller than the block data 734 that 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 multiparty process data 735 within chunk data 734 added by ordering node 710. Multiparty process data 735 may include an identification of the current step being performed, transmit and receive events performed during that step, and so forth.

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

The tile data 734 may store transaction information for each transaction recorded within the tile 730. For example, the transaction data stored within the tile data 734 may include one or more of the following: transaction type, version, timestamp (e.g., final calculated timestamp, etc.), channel ID of distributed ledger 720, transaction ID, epoch, payload visibility, chain code path (deployment tx), chain code name, chain code version, input (chain code and function), customer (creator) identification (such as public key and certificate), customer signature, endorsement node identity, endorsement node signature, proposal hash, chain code event, response state, 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, merck (Merkel) tree query digest, etc. Transaction data may be stored for each of the N transactions.

The block metadata 736 may store a plurality of metadata fields (e.g., as an array of bytes, etc.). The metadata fields may include a signature at the time of tile creation, a reference to the last configured tile, a transaction filter that identifies valid and invalid transactions within the tile, a last offset of the ordering service persistence that orders the tiles, and so on. The signature, last configured block, and ordering service node metadata may be added by ordering service 710. Meanwhile, a commit node of a block (such as blockchain node 712) may add valid/invalid information based on endorsement policies, verification of read/write sets, and the like. The transaction filter may include an array of bytes of a size equal to the number of transactions in the block data 734 and a validation 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, hard disk, a removable disk, a compact disc 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 any of the components described above, or any of the components integrated therein, etc.

Fig. 8 is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the present application described herein. Regardless, the computing node 800 is capable of being implemented and/or of performing any of the functionality set forth above. For example, computing node 800 may perform the method shown and described with respect to fig. 5.

In computing node 800, there is a computer system/server 802, which 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 computer devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, distributed cloud computing environments that include any of the above systems or devices, and the like.

The 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. The computer system/server 802 can 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 systems/servers 802 in cloud computer node 800 are embodied in the form of general purpose computing devices. 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 that connects the various system components (including the system memory 806 and the processing units 804).

Bus means one or more of several types of bus structures including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor, or a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include 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 is accessible by computer system/server 802 and includes both volatile and nonvolatile media, removable and non-removable media. 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 can further include other removable/non-removable, volatile/nonvolatile computer system storage media. By way of example only, storage system 814 may be used to read from and write to non-removable, nonvolatile magnetic media (not shown in the figures and commonly referred to as a "hard disk drive"). Although not shown, a magnetic disk drive for reading from and writing to a removable non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive for reading from or writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media), may be provided. In these cases, each drive may be coupled to the bus through one or more data medium 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 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 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 818 generally perform the functions and/or methods in the various embodiments described herein.

As will be appreciated by one of skill in the art, aspects of the present application may be embodied as a system, method, or computer program product. Accordingly, 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, 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 can also communicate with one or more external devices 820 (e.g., keyboard, pointing device, display 822, etc.), one or more devices that enable a user to interact with the computer system/server 802, and/or any device (e.g., network card, modem, etc.) that enables the computer system/server 802 to communicate with one or more other computing devices. Such communication may occur through an input/output (I/O) interface 824. Also, the computer system/server 802 can communicate with one or more networks such as a Local Area Network (LAN), a Wide Area Network (WAN) and/or a public network, such as the Internet, through a network adapter 826. As shown, the network adapter 826 communicates with the other components of the computer system/server 802 via a bus. It should be appreciated that although not shown, other hardware and/or software components may be utilized 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, data backup storage systems, and the like.

Although an exemplary embodiment of at least one of a system, method, and non-transitory computer readable medium 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 embodiments disclosed, 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 separate modules may be performed by one or more of the modules. Further, the functionality described herein may be performed at various times and in connection with various events, either internal or external to the modules or components. 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 a variety of protocols. Moreover, 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 is intended to provide one example of many embodiments. Indeed, the methods, systems, and apparatus disclosed herein may be implemented in localized and distributed forms consistent with computing technology.

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 partially in software for execution by various types of processors. For example, the identified executable code elements may 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, random Access Memory (RAM), 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.

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. Thus, the detailed description of the embodiments is not intended to limit the scope of the application, as claimed, but is merely representative of selected embodiments of the application.

Those of ordinary skill in the art will readily appreciate that the foregoing 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, certain modifications, variations, and alternative constructions will be apparent to those skilled in the art.

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

Claims (33)

1. A computing system, comprising:

a processor configured to generate a plurality of state representations based on a modeled communication process between a plurality of off-chain systems of a multi-party process, wherein a blockchain is an intermediary between the plurality of off-chain systems, wherein each state representation models transmit and receive events of a respective off-chain system;

Wherein the processor is further configured to remove one or more events from a state representation of an off-chain system to generate a reduced state representation, generate executable chain code for execution of the multiparty process based on the reduced state representation, and store the generated chain code via a 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 extra-chain systems within the multi-party process.

4. The computing system of claim 1, further comprising a network interface further configured to receive a blockchain state representation modeling a transmit event, a receive event, and a store event of 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 actions performed by the off-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 off-chain system.

7. The computing system of claim 1, wherein the processor is configured to remove a plurality of receive events of the off-chain system while the processor is configured to retain all transmit events of the off-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 multiparty process.

9. A method, comprising:

generating a plurality of state representations based on a modeled communication process between a plurality of off-chain systems of the multi-party process, wherein a blockchain is an intermediary between the plurality of off-chain systems, wherein each state representation models transmit and receive events of a respective off-chain system;

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

generating executable chain code for execution of the multiparty process based on the reduced state representation; and

The generated chain code is stored via a storage device.

10. The method of claim 9, further comprising: a process description of the multiparty process is transformed into the plurality of state representations, the multiparty 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 extra-chain systems within the multiparty process.

12. The method of claim 9, wherein the receiving further comprises: a blockchain state representation modeling the send, receive, and store events of the blockchain is received, and the generating of the chain code is also performed based on the blockchain state representation.

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

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

15. The method of claim 9, wherein the removing comprises: multiple receive events of the off-chain system are removed while retaining all transmit events of the off-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 the corresponding events occur within the multiparty process.

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

18. A computing system, comprising:

a network interface configured to receive a plurality of state diagrams for a plurality of participants of a multi-party process in which a blockchain is an intermediary between a plurality of extrachain systems; and

a processor configured to:

based on the successive occurrences of the same type of step, steps are removed from the plurality of state diagrams, and an ordered sequence of steps from the simplified state diagram is encoded as a blockchain smart contract;

determining a current step of the multiparty process based on a comparison of a most recently executed step in the blockchain with an encoded ordered sequence of steps in the blockchain smartcontract;

Processing the determined current step to generate a processing result; and

the generated processing results are stored by the blockchain.

19. The computing system of claim 18, wherein the processor is configured to remove at least one receive event step from the plurality of state diagrams based on successive occurrences of the at least one receive event step.

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

21. The computing system of claim 18, wherein the processor is configured to store events sent and/or received by an off-chain system, the events occurring via execution of the current step of the multiparty process.

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

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

24. The computing system of claim 18, wherein the processor is further configured to: based on the processing result of the current step, a next executable step of the multiparty process relative to the current step is processed via the blockchain.

25. A method, comprising:

receiving a plurality of state diagrams for a plurality of parties performing a multi-party process in which a blockchain is an intermediary between a plurality of extrachain systems;

based on the successive occurrences of the same type of step, steps are removed from the plurality of state diagrams, and an ordered sequence of steps from the simplified state diagram is encoded as a blockchain smart contract;

determining a current step of the multiparty process based on a comparison of a most recently executed step in the blockchain with an encoded ordered sequence of steps in the blockchain smartcontract;

processing the determined current step to generate a processing result; and

the generated processing results are stored by the blockchain.

26. The method of claim 25, wherein the removing comprises: the at least one receive event step is removed from the plurality of state diagrams based on the successive occurrence of the at least one receive event step.

27. The method of claim 25, further comprising: the current execution state of the off-chain system included within the multiparty process is stored.

28. The method of claim 25, further comprising: storing events sent and/or received by an off-chain system, the events occurring via execution of the current step of the multiparty process.

29. The method of claim 25, further comprising: a plurality of peer nodes are used to validate blockchain results generated during the processing.

30. The method of claim 25, wherein the multiparty process comprises a shared process performed by the plurality of extrachain systems and the blockchain.

31. The method of claim 25, further comprising: based on the processing result of the current step, a next executable step of the multiparty process relative to the current step is processed via the blockchain.

32. A non-transitory computer readable medium comprising instructions which, when read by a processor, cause the processor to perform the method of any one of claims 25 to 31.

33. A computer system, the computer system comprising: a model for performing the steps of any of the methods according to claims 9 to 16 and claims 25 to 31.