WO2020155167A1

WO2020155167A1 - Application of cross-organizational transactions to blockchain

Info

Publication number: WO2020155167A1
Application number: PCT/CN2019/074657
Authority: WO
Inventors: Ming Lei; Qingjian Song
Original assignee: Microsoft Technology Licensing, Llc
Priority date: 2019-02-02
Filing date: 2019-02-02
Publication date: 2020-08-06

Abstract

In embodiments of the present disclosure, there is provided an approach for applying cross-organizational transactions to the blockchain. After receiving a write request for writing data in the blockchain from one application, a decentralized shared (DS) transaction is initiated in the blockchain, and an event notification is generated for seeking an approval to the DS transaction from one or more other applications. Then, upon receiving the approval to the DS transaction from one or more other applications, the DS transaction will be approved and completed in the blockchain. Embodiments of the present disclosure provide a decentralized architecture for processing the cross-organizational transactions, and the architecture comprises an extension Application Programming Interface (API) layer to interface with smart contracts in the blockchain. According to embodiments of the present disclosure, the cross-organizational transactions can be processed transparently and automatically by use of the blockchain, thereby improving the execution efficiency of the cross-organizational transactions and ensuring data security and reliability for the cross-organizational transactions.

Description

APPLICATION OF CROSS-ORGANIZATIONAL TRANSACTIONS TO BLOCKCHAIN

BACKGROUND

A blockchain represents a decentralized and transparent technology that may record blocks across many nodes, and the blockchain may comprise a growing list of blocks that are linked using cryptography. Each block contains a cryptographic hash of a previous block, a timestamp, and transaction data, such that any block cannot be altered retroactively. Thus, the blockchain is an open distributed ledger that can record transactions in a verifiable and permanent way, which can avoid the centralized control from a single provider. Blockchain as a Service (BaaS) is a blockchain service that allows leveraging cloud-based platform to build, host and use the blockchain, and the cloud-based service provider can manage all the necessary tasks and activities to maintain the infrastructure of the blockchain platform.

Generally, there are three types of blockchain networks, including a public blockchain, a private blockchain and a consortium blockchain. A public blockchain has absolutely no access restrictions, anyone with an internet connection may send transactions to it as well as become a validator. A private blockchain is generally owned by a single organization, and the access of participant and validator is very restricted. A consortium blockchain is also a decentralized blockchain, and a number of organizations or participants may collectively operate in the blockchain. In the consortium blockchain, it allows a limited set of trusted nodes to execute a consensus protocol.

SUMMARY

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other features, advantages and aspects of embodiments of the present disclosure will be made more apparent by describing the present disclosure in more detail with reference to drawings. In the drawings, the same or like reference signs represent the same or like elements, wherein,

Fig. 1 illustrates a block diagram of a computing device/server in which one or more embodiments of the present disclosure may be implemented;

Fig. 2 illustrates an example architecture with an extension API layer to interface with smart contracts in the blockchain in which one or more embodiments of the present disclosure may be implemented;

Fig. 3 illustrates a flow chart of a method for applying a cross-organizational transaction to the blockchain according to embodiments of the present disclosure;

Fig. 4 illustrates a schematic diagram for performing a write operation on the blockchain in the example architecture with three layers according to embodiments of the present disclosure;

Fig. 5 illustrates an example transaction process for creating a cross-organizational transaction according to embodiments of the present disclosure;

Fig. 6 illustrates a workfiow for completing a DS transaction between two participants according to embodiments of the present disclosure;

Figs. 7A-7B illustrate schematic diagrams of updating a status of the DS transaction according to embodiments of the present disclosure;

Fig. 8 illustrates a flow chart of a method for processing a DS transaction in the blockchain according to embodiments of the present disclosure;

Fig. 9 illustrates a schematic diagram for performing a read operation on the blockchain in the example architecture with three layers according to embodiments of the present disclosure.

DETAILED DESCRIPTION

Embodiments of the present disclosure will be described in more detail below with reference to figures. Although the drawings show some embodiments of the present disclosure, it should be appreciated that the present disclosure may be implemented in many forms and the present disclosure should not be understood as being limited to embodiments illustrated herein. On the contrary, these embodiments are provided herein to enable more thorough and complete understanding of the present disclosure. It should be appreciated that drawing and embodiments of the present disclosure are only used for exemplary purposes and not used to limit the protection scope ofthe present disclosure.

As used herein, the term “includes” and its variants are to be read as open terms that mean “includes, but is not limited to. ” The term “based on” is to be read as “based at least in part on. ” The term “an embodiment” is to be read as “at least one embodiment. ” The term “another embodiment” is to be read as “at least one other embodiment. ” The term “some embodiments” is to be read as “at least some embodiments. ” Definitions of other terms will be given in the text below.

A cross-organizational transaction is a transaction that needs at least two organizations or participants to complete together. Traditionally, cross-organizational transactions are processed in a centralized way. For example, a single server may maintain the transaction system and data, so it requires intensive manual operations. In addition, the traditional centralized control is not transparent, and it is not trustful to the participants. Thus, traditional ways for processing the cross-organizational transactions are inefficiently.

In traditional blockchain platforms, there exist some other technical problems. For example, the users of the blockchain do not have enough capabilities to design and develop the smart contracts correctly. For example, Ethereum, as a blockchain platform, builds great decentralization mechanism, but it lacks the right programming model for transaction applications. Corda, as another blockchain platform, has a programming model, but it lacks good decentralization foundation. In addition, it is difficult to enable blockchain as a component to be configurable and connectable into existing applications, because there is a gap between the application interface and the low level ledger layer interface.

To this end, a new approach for applying a cross-organizational transaction to the blockchain is proposed, and an Extension API layer can be provided on top of the ledger layer. Embodiments of the present disclosure provide a decentralized architecture for processing the cross-organizational transactions, and the architecture comprises an extension API layer to interface with smart contracts in the blockchain.

According to embodiments of the present disclosure, many technical effects and improvements may be achieved. For example, the cross-organizational transactions can be processed transparently and automatically in the blockchain, thereby improving the execution efficiency of the cross-organizational transactions and ensuring data security and reliability for the cross-organizational transactions. By application of the cross-organizational transactions to the blockchain, the cross-organizational transactions can be transformed from the current centralized way with manual processes across organizations to a decentralized way with full automated experience, thereby reducing intensive manual processes and achieving automated transaction processing.

In some embodiments of the present disclosure, some built-in smart contracts may be provided in advance, and a series of smart contracts may satisfy the needs to connect multiple existing applications by the abstraction of DS transactions and DS entities. DS transactions may utilize the smart contract workflow features across multiple participants to implement the connector core functions including action and events. DS entities may keep the data like a table on ledger to have immutable records, and DS entities automatically are replicated to other nodes in the blockchain and are exposed as entity data to the applications. An extension API layer to interface with built-in smart contracts including consortium management may be provided, and the extension API layer may comprise a DS transaction API to implement connectors (such as actions and events) and a DS entity API to expose the data to applications. In some embodiments, consortium management could be wrapped as the DS transaction (s) and DS entity (s) .

According to some embodiments of the present disclosure, by using existing ledger node to deploy extension API instance, the customer cost can be saved. By having extension API on the transaction nodes belonging to different participants, a full decentralization may be achieved, as compared with the centralized application architecture on top of the decentralized blockchain layer. In addition, by providing the extension API as a seamless additional option in resource provisioning, the deployment complexity can be reduced. By reusing shared controlling, security access control and telemetry infrastructure between managed ledger and extension API, the management effort can be saved.

Reference is made below to Fig. 1 through Fig. 9 to illustrate basic principles and several example embodiments of the present disclosure herein. Fig. 1 illustrates a block diagram of a computing device/server 100 in which one or more embodiments of the present disclosure may be implemented. It would be appreciated that the computing device/server 100 described in Fig. 1 is merely for illustration but not limit the function and scope of embodiments of the present disclosure in any manners.

As shown in Fig. 1, the computing device/server 100 is in the form of a general-purpose computing device. Components of the computing device/server 100 may include, but are not limited to, one or more processor (s) or processing unit (s) 110, a memory 120, a storage device 130, one or more communication unit (s) 140, one or more input device (s) 150, and one or more output device (s) 160. The processing unit 110 may be a physical or virtual processor and perform various processes based on programs stored in the memory 120. In a multiprocessor system, a plurality of processing units may execute computer executable instructions in parallel to improve parallel processing capability of the computing device/server 100.

The computing device/server 100 typically includes various computer storage media. The computer storage media may be any media accessible by the computing device/server 100, including but not limited to volatile and non-volatile media, or removable and non-removable media. The memory 120 can be a volatile memory (for example, a register, cache, Random Access Memory (RAM) ) , non-volatile memory (for example, a Read-Only Memory (ROM) , Electrically Erasable Programmable Read-Only Memory (EEPROM) , flash memory) , or any combination thereof. The memory 120 may include a computer program 125 for providing an extension DS API according to embodiments of the present disclosure, which has one or more sets of program module configured to perform methods and functions of various embodiments described herein. The storage device 130 can be any removable or non-removable media and may include machine-readable media such as a flash drive, disk, and any other media, which can be used for storing information and/or data and accessed within the computing device/server 100.

The computing device/server 100 may further include additional removable/non-removable or volatile/non-volatile storage media. Although not shown in Fig. 1, a magnetic disk drive is provided for reading and writing from/to a removable and non-volatile disk (e.g., “a floppy disk” ) and an optical disk drive may be provided for reading or writing from/to a removable non-volatile optical disk. In such cases, each drive is connected to the bus (not shown) via one or more data media interfaces.

The communication unit 140 communicates with another computing device via communication media. Additionally, functions of components in the computing device/server 100 may be implemented in a single computing cluster or a plurality of computing machines that are communicated with each other via communication connections. Therefore, the computing device/server 100 can be operated in a networking environment using a logical connection to one or more other servers, network personal computers (PCs) , or another network node.

The input device 150 can include one or more input devices such as a mouse, keyboard, tracking ball and the like. The output device 160 can include one or more output devices such as a display, loudspeaker, printer, and the like. The computing device/server 100 can further communicate, via the communication unit 140, with one or more external devices (not shown) such as a storage device or a display device, one or more devices that enable users to interact with the computing device/server 100, or any devices that enable the computing device/server 100 to communicate with one or more other computing devices (for example, a network card, modem, and the like) . Such communication can be performed via input/output (I/O) interfaces (not shown) . Next, reference is made below to Figs. 2-9 to specify example embodiments of the present disclosure.

Fig. 2 illustrates example architecture 200 with an extension API layer to interface with smart contracts in the blockchain in which one or more embodiments of the present disclosure may be implemented. According to embodiments of the present disclosure, an extension DS API layer is provided to interface with smart contracts in the blockchain. The inventors realize that blockchain technology is in a great position to lead the revolution wave for cross-organizational transactions, and the blockchain can transform the cross-organizational transactions from current centralized way with manual processes across organizations to a decentralized way with full automated experience.

As shown in Fig. 2, application ( “APP” ) 211, APP 212, APP 213 may be any application that runs on PC platform, mobile platform or other platforms, and these applications may be the same type of application, or may be different types of applications. APPs 211-213 may be used for processing transactions of the respective organization. In some embodiments, APP 211 may be a suite of applications, services, connectors and data platform that provides a rapid application development environment to build custom application for transaction needs. By use of the APP 211, the user from the organization may quickly build custom application that connects to the data stored in a underlying data platform or in various online and on-premises data source (s) . In some embodiments, APP 213 may be a cloud-based application that allows the user to create and automate tasks and workflows across applications and services.

In some embodiments, the applications may connect to the blockchain 225 (such as BaaS) via a DS API layer, and the blockchain 225 and the DS API layer may be provided by the blockchain platform 220. As shown in Fig. 2, APP 211 connects to blockchain 225 via DS API 221, APP 212 connects to blockchain 225 via DS API 222, and APP 213 connects to blockchain 225 via DS API 223. By use of the DS API, the cross-organizational transactions over the blockchain may be managed efficiently and automatically.

Each application may be configured with account and password, and application may use a security protocol to access the blockchain. As shown in Fig. 2, 3 DS API instances will be configured to connect the accounts with the blockchain, and 3 DS APIs may have 3 different API manager instances with different API keys.

In some embodiments, the DS API may comprise a DS transaction API and a DS entity API. The DS transaction API is used as a write interface for applications to write data in the blockchain. That is, if one application wants to write data in the blockchain, it must call a DS transaction API. The DS transaction API may interface with several types of DS transaction smart contracts in the blockchain, each DS transaction smart contract may define the corresponding authorized participants, such as the accounts that may create or approve a DS transaction. In addition, each DS transaction smart contract may also define one or more input DS entities and one or more output entities.

The DS entity API is used as a read interface for applications to read data from the blockchain. The DS entity API may interface with several types of DS entity smart contracts in the blockchain directly without calling any DS transaction API. Each DS entity smart contract may maintain a DS entity (such as a table) storing data in the blockchain to have immutable records, the DS entity smart contract may automatically replicate its data to other nodes in the blockchain. The DS entity smart contract may expose the DS entity to the applications directly. In the embodiments of the present disclosure, all DS entities are read-only from the application perspective, and they only can be updated (such as created, deleted, mutated) through the DS transaction (s) .

Fig. 3 illustrates a flow chart of a method 300 for applying a cross-organizational transaction to the blockchain according to embodiments of the present disclosure. It should be appreciated that the method 300 may be executed by the computing device/server 100 as described with reference to Fig. 1 or the blockchain platform 220 as described with reference to Fig. 2.

At 302, a DS transaction associated with a write request is initiated in a blockchain after receiving the write request from a first application, and the DS transaction is used for writing data in a DS entity which stores the data in the blockchain. For example, the blockchain platform 220 receives a write request from APP 211 via DS API 221, and the blockchain platform 220 then initiates a related DS transaction in blockchain 225.

At 304, an event notification is sent to a second application associated with the DS transaction. Since each DS transaction requires at least two participants to complete together, the blockchain platform 220 will generate an event notification and send it to the related receipt. For example, the blockchain platform 220 may send event notification to APP 213. The event notification enables the user of APP 213 to get notified of the initiated DS transaction.

At 306, the blockchain platform 220 determines whether an approval to the DS transaction is received from the second application. If an approval to the DS transaction is received from the second application, then at 308, the DS transaction is approved in the blockchain. For example, if the blockchain platform 220 receives the approval to the DS transaction from APP 213, which indicates that APP 213 agrees to this DS transaction, then the blockchain platform 220 will approve this DS transaction in the blockchain, and the data will be written in the blockchain persistently.

According to the method 300 of the present disclosure, the cross-organizational transactions can be processed transparently and automatically in the blockchain, thereby improving the execution efficiency of the cross-organizational transactions and ensuring data security and reliability for the cross-organizational transactions.

Fig. 4 illustrates a schematic diagram 400 for performing a write operation on the blockchain in the example architecture with three layers according to embodiments of the present disclosure. As shown in Fig. 4, the example architecture comprises three layers, including an application layer such as APP 410 and APP 420, a DS API layer such as DS API 430, and a ledger layer such as smart contracts 440. The ledger layer implements the DS transactions and DS entities, the DS API layer, as the off-chain service, provides high level DS API to interact with smart contracts, and the application layer comprises a connector (s) to connect blockchain functions (DS API) with various applications.

APP 410 may configure a connector 411 to connect to the DS API 430, while APP 420 may configure a connector 421 to connect to the DS API 430. The connector may be a standard to define the actions (such as REST API) and events (such as webhook) to automate the workflow across different applications. By use of the connector, the entity value may be obtained in a JSON object template. It is to be understood that although Fig. 4 illustrates that APP 410 and APP 420 connect to the same DS API, they may connect to different DS APIs.

As shown in Fig. 4, DS API 430 comprises DS transaction API 431 and DS entity API 432, and DS transaction API 431 is used for writing data while DS entity API 432 is used for reading data. Built-in Smart contracts 440 may include some predefined DS transaction smart contracts such as DS transaction

smart contracts

441 and 442 and some predefined DS entity smart contracts such as DS entity

smart contracts

446 and 447. DS entity smart contracts keep data records on the ledger, for example, it may be a table to keep multiple rows but have the same schema. DS transaction smart contracts may create and change DS entities, and each DS transaction may have one or more input and output DS entities. Each DS transaction smart contract may define the creating participant and need approval from other participant (s) . There is also observer role that needs not approve the transaction but could access the DS transaction. Each DS transaction smart contract may have one or more actions to create and update the DS entities. DS transaction will keep some internal states of the workflow, such as “Initiated” , “Pending” , “Exit” and “Committed” . Only committed transaction is valid, and the smart contracts will make sure the roll back to the original state if the transaction is exit.

In some embodiments, each DS entity may be defined as a JSON template and be implemented by a smart contract with the add function to append a new row of entity into the ledger. In some embodiments, each DS transaction may be also defined as a JSON template and be implemented by smart contract with methods to complete the mutation to create or update the DS entity. DS transaction smart contract may keep the input and output entity IDs and transaction state.

Continuing to refer to Fig. 4, optionally, smart contracts 440 may also comprise a consortium management smart contract 449 which may be wrapped as DS transaction (such as a transaction with many actions: AddParticipant, DeleteParticipant, UpdateParticipant, AddPolicy, DeletePolicy, UpdatePolicy) and DS entities (such as Participant and Policy) . In each scenario, each type of DS transaction may contain a plurality of actions. These actions may be implemented as functions of DS transaction smart contract, and the DS transaction smart contract may execute the actions. Each type of DS transaction may be configured with the corresponding participants through a participant set API, and the DS smart contract may define access permission of each participant based on the configurations. Generally, identification (such as blockchain account or other ledger ID) of each participant must be configured in the DS transaction. Optionally, other flexible configurations such as role and name may be also configured in the DS transaction.

The blockchain participant may invite one or more other participant (s) to join the consortium by use of the consortium management smart contract 449. For example, users A and B may import a connector definition file of the downloaded consortium management extension, and create their streams by use of the connectors. In user A’s stream, it is configured to call the connector action to invite a new participant to join the consortium, which will need user B to approve it. In user b’s stream, it is configured to use push notification to listen the connector event such as “when a new participant is invited to join consortium” , then user B’s application may send heads-up notification on his phone. User B also has configured another button stream, which is a one-click to run a workflow, including checking the data from the connector and calling connector’s approval action.

Continuing to refer to Fig. 4, as indicated by arrow 451, a write request may be transmitted from APP 410 to DS transaction API 431. Then, the DS transaction smart contract 441 initiates a DS transaction in the blockchain, as indicated by the arrow 452. As shown in Fig. 4, the DS transaction smart contract 441 may predefine that its input entity is DS entity 446 and its output entity is DS entity 447. As a result, the DS transaction smart contract 441 will execute the DS transaction, including reading data from DS entity 446 and writing the execution result in DS entity 447, as indicated by

arrows

453 and 454. However, since the DS transaction has not been approved by other participant, so the writing to DS entity 447 is just a proposal. Next, an event notification is generated and sent to APP 420 for seeking an approval to the DS transaction, as indicated by arrow 455. Once the approval to the DS transaction is received from APP 420, the DS transaction will be approved by DS transaction smart contract 441, and the proposal will be accepted by the DS entity smart contract 447. In this way, the write operations to the DS entity in the blockchain can be managed and controlled efficiently.

In some embodiments, one DS transaction may involve three or more participants, and the event notifications will be sent to all approving participants. Only after obtaining the approvals from all of the approving participants, the DS transaction can be approved in the blockchain. In this way, permission management for write operations can be guaranteed, thereby ensuring data security in the blockchain. In some embodiments, the event notification may be implemented by leveraging the leger native logs or notifications. For example, the extension DS API may listen or monitor log change through Websocket or HTTP polling, and the log change will be translated into webhook events for connector in applications of the participants.

Embodiments of the present disclosure can shorten time for the users to integrate blockchain-enabled features into existing applications from months to minutes. Low code or no code experience may be achieved for users to use the blockchain features, and it empowers users to rapidly iterate on multi-party transaction workflows without the heavy involvement of consortium application builder and operator, which maximizes the one-time investment in IT infrastructure. In addition, a standard for certified partners and industry know-how independent software vendor/system integrator (ISV/SI) may be achieved to build specialized extensions and form a strong eco-system.

Embodiments of the present disclosure may be helpful to IT operators and enterprise users and so on. For example, IT operators may deploy the IT system and add the extension DS API onto specific transaction node. The users may use the consortium management interface to insert a step in existing logic application workflow, to invite a new participant into the consortium, or to approve a participant invitation with one-click experience. Connectors may be provided for connecting existing applications to extension DS API according to embodiments of the present disclosure.

Fig. 5 illustrates an example transaction process 500 for creating a cross-organizational transaction according to embodiments of the present disclosure. The example transaction process 500 relates to a supply chain scenario, and the multiple enterprises consortium includes manufactory 510, vendor 520 and factoring institution 530. According to embodiments of the present disclosure, the cross-organizational transactions may be digitalized through the blockchain.

At 551, the manufactory 510 may create a transaction 540 such as a purchase order transaction, and the transaction 540 may include the transaction identification TXID, vendor identification SID and so on, as illustrated in Fig. 5. After getting notified of the transaction 540, the vendor 520 may approve the transaction 540 at 552. Of course, if the vendor 520 disagrees with this transaction, it may choose to reject the transaction 540. After the vendor 520 approves the transaction 540, the transaction 540 is updated to be approved. During the transaction process 500, the factoring institution 530 may observe the transaction 540 and the related entity (s) .

In some embodiments, the DS transactions and the DS entities may be defined as JavaScript Object Notation (JSON) templates. For example, in the supply chain scenario of Fig. 5, an example PurchaseOrder DS entity JSON template may be defined as follow, and the PurchaseOrder entity is used to store data of purchase orders in the blockchain.

Example PurchaseOrder DS entity JSON template:

For example, in the supply chain scenario of Fig. 5, an example CreatePurchaseOrder DS transaction JSON template may be defined as follow, and the CreatePurchaseOrder DS transaction is used to create a purchase order and write the related data in DS entity in the blockchain. As shown below, for the CreatePurchaseOrder DS transaction, the input entity is null while the output entity is the PurchaseOrder DS entity. However, some DS transactions may have both the input entity (s) and the output entity (s) .

Example CreatePurchaseOrder DS transaction JSON template:

The Blockchain includes the fundamental building blocks to extend the applications to shared data through transactions across the multiple participants. For example, in the supply chain scenario, the DS entities may be summarized as PurchaseOrder, FreightTransport, MaterialDocument, Receipt, FinanceApplication, Invoice, Payments, and so on. To create and update DS entities, DS transactions are defined to complete the creation and approval across multiple participants. For example, in the supply chain scenario, the DS transactions may be summarized as CreatePurchaseOrder, CreateFreightTransport, CreateMaterialDocument, CreateFinanceApplication, PayForFactoring, PayForMaterialDocument, and so on.

Embodiments of the present disclosure can change today’s B2B application landscape from the centralized control to the decentralized shared entities and transactions managed by the consortium, thereby improving the trust (transparency, immutable log and non-repudiation) and efficiency (for example shortening the transactions from several days to nearly real time) .

Fig. 6 illustrates a workflow 600 for completing a DS transaction between two applications according to embodiments of the present disclosure. Continue with the supply chain scenario in Fig. 5, the manufactory 510 may configure its account into one application, and the vendor 520 may configure its account into another application.

At the creator’s side of the DS transaction, the entity data is input in the application of the manufactory 510 at 611. At 612, the DS transaction template (such as JSON template) may obtained based on the DS transaction type, and the function values (such as function parameter value JSON file) that include a function name and parameter of entity value may be determined from the input entity data, where the function values may be used as execution information. For example, the application may have a click button to call function to generate the JSON dictionary of a DS transaction type, a function name, parameters related to the entity. At 613, the DS transaction is executed using the obtained DS transaction template and the determined execution information, and the transaction ID may be output after execution. For example, an example JSON template for executing the DS transaction may be as below.

Example DS transaction execution JSON template:

After executing the DS transaction, a connector event of transaction created will be generated and sent to the related application (the application of the vendor 520) at 631. Next, the application of the manufactory 510 may get DS transaction status at 614, get entity value at 615, and reflect the execution result of the DS transaction at 616. For example, the application may get out of JSON template of current transaction value snapshot, which may contain created entity ID and status, and get out of JSON template of the entity value. After receiving an approval to the DS transaction from the approver, the application of the manufactory 510 will reflect the updated result in the application.

At the approver’s side of the DS transaction, the application of vendor 520 may listen to the extension connector event. An event notification is received in the application of the vendor 520 at 621. For example, the vendor 520 may get a push notification (such as an email or a mobile alert) from the application. Then, the vendor 520 will review the DS transaction in the application at 622, get the DS transaction status at 623 and get the entity value at 624 based on the transaction ID. The application may provide an approve button at 625, and the vendor may approve the DS transaction in its application at 626. Next, a connector event of transaction approved will be generated and sent to the manufactory 510 at 632. In this way, the manufactory 510 and the vendor 520 may use their respective applications to manage cross-organizational transactions in the blockchain.

In some embodiments, connectors of the applications may include a plurality of actions, such as ExecuteTransaction, ApproveTransaction, GetEntityTemplate, GetEntityValue, GetTransactionTemplate and GetTransactionStatus. In some embodiments, the connectors may include a plurality of events, such as EntityCreated, EntityAttached, EntityUpdated, TransactionApproved and TransactionRejected.

Figs. 7A-7B illustrate schematic diagrams 700 and 750 of updating a status of the DS transaction according to embodiments of the present disclosure. As shown in Fig. 7A, the blockchain 710 comprises a plurality of nodes, such as

nodes

711, 712, 713, 714, 715 and 716. APP 720 is connected to the node 712 via DS API 721, while APP 730 is connected to the node 715 via DS API 731. As indicated by arrow 741, after APP 720 performs a write operation on the blockchain 710, a DS transaction is initiated in the blockchain 710, with the transaction identification TXID “10001” . The current status of the transaction “10001” is “Initiated” and is stored in the node 712, as shown at 745. Next, the DS transaction “10001” and its status will be synchronized to other nodes (such as

nodes

712, 713, 714, 715 and 716) in the blockchain automatically. As a result, node 715 also comprises the information of DS transaction “10001” and its status.

As shown in Fig. 7B, after getting notified of the DS transaction “10001” , APP 730 sends an approval to the DS transaction to node 715 via DS API 731, as indicated by arrow 751. The DS transaction “10001” is approved in the blockchain 710, and its status is updated to be “Committed” to indicate a completion of the DS transaction. Likewise, the DS transaction “10001” and its status will be synchronized from node 715 to other nodes in the blockchain automatically, and the node 712 will have the latest status of the DS transaction “10001” , as shown at 745. In this way, the status of the DS transaction can be maintained and updated dynamically in the blockchain, and can be synchronized to all nodes in the blockchain, thereby ensuing data reliability and consistency.

Fig. 8 illustrates a flow chart of a method 800 for processing a DS transaction in the blockchain according to embodiments of the present disclosure. It should be appreciated that the method 800 may be executed by the computing device/server 100 as described with reference to Fig. 1, the blockchain platform 220 as described with reference to Fig. 2 or any node in blockchain 710 as described with reference to Figs. 7A and 7B. In addition, the method 800 may be an example implementation of the method 300 of Fig. 3.

At 802, a write request is received from a first application. At 804, the blockchain platform determines whether a write condition is satisfied. For example, if DS entity to be read and/or written involves another DS transaction that has not been approved, it means the value in the DS entity is not an approved version; instead, it is a proposed version of another DS transaction. In this case, the DS entity is regarded as not satisfying the write condition.

If the write condition is not satisfied at 804, the writing of the data in the DS entity is stopped, and an error message is generated at 806, which indicates that the DS entity cannot be written. If the write condition is satisfied at 804, data is written in the corresponding DS entity as a proposal at 808, and an event notification is generated and sent to a second application at 810. In some embodiments, the event notification may comprise an identification of the DS transaction, an identification of the DS entity and a blockchain account address.

At 812, the blockchain platform determines whether an approval to the DS transaction is received from the second application. If an approval to the DS transaction is received from the second application at 812, the DS application is approved in the blockchain and its status will be updated at 814. If an approval to the DS transaction has not been received from the second application, at 816, the blockchain platform determines whether a rejection to the DS transaction is received from the second application. If a rejection to the DS transaction is received from the second application at 816, the DS application is rejected in the blockchain, and its status will be updated at 818. Next, the DS entity written by the DS transaction will be rolled back to an original version. If a rejection to the DS transaction has not been received from the second application at 816, which means neither an approval nor a rejection is received from the second application, then the status may be maintained unchanged at 820.

Fig. 9 illustrates a schematic diagram 900 for performing a read operation on the blockchain in the example architecture with three layers according to embodiments of the present disclosure. As indicated by arrow 951, a read request may be transmitted from APP 420 to DS entity API 432 so as to read data in the blockchain. Since the read operations do not change the data in the blockchain, embodiments of the present disclosure retrieve data from the associated DS entity 447 in the blockchain directly without initiating any DS transaction via the DS transaction API 431. Then, the retrieved data is directly sent to APP 420 via the DS entity API 432. Thus, according to embodiments, the DS transaction API is used for interfacing with the DS transaction smart contracts and is used for the write operations, while the DS entity API is used for interfacing with the DS entity smart contracts and is used for read operations.

The functionally described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-Programmable Gate Arrays (FPGAs) , Application-specific Integrated Circuits (ASICs) , Application-specific Standard Products (ASSPs) , System-on-a-chip systems (SOCs) , Complex Programmable Logic Devices (CPLDs) , and the like.

Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowcharts and/or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of this disclosure, a machine readable medium may be any tangible medium that may contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine readable medium may be a machine readable signal medium or a machine readable storage medium. A machine readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation may also be implemented in multiple embodiments separately or in any suitable sub-combination.

Some example embodiments of the present disclosure are listed below.

In one aspect, there is provided a computer-implemented method. The method comprises: in response to receiving a write request from a first application, initiating a decentralized shared (DS) transaction associated with the write request in a blockchain, wherein the DS transaction is used for writing data in a DS entity which stores the data in the blockchain; sending an event notification to a second application associated with the DS transaction; and in response to receiving an approval to the DS transaction from the second application, approving the DS transaction in the blockchain.

In some embodiments, wherein the initiating the DS transaction in the blockchain comprises: determining, from the write request, execution information comprising a DS transaction type, a function name and an entity value; obtaining a DS transaction template based on the DS transaction type; and executing the DS transaction using the obtained DS transaction template and the determined execution information.

In some embodiments, wherein the executing the DS transaction comprises: in response to the DS entity involving a further DS transaction that has not been approved, forgoing writing of the data in the DS entity; and generating an error message indicating that the DS entity is unable to be written.

In some embodiments, wherein the executing the DS transaction comprises: in response to a write condition being satisfied, writing the data in the DS entity as a proposal; and generating, based on the DS transaction template, the event notification indicating an identification of the DS transaction, an identification of the DS entity and a blockchain account address.

In some embodiments, wherein the approving the DS transaction in the blockchain comprises: obtaining a status of the DS transaction based on the identification of the DS transaction; and updating the status of the DS transaction to indicate a completion of the DS transaction.

In some embodiments, wherein the DS transaction and the DS entity are defined as JavaScript Object Notation (JSON) templates and implemented as smart contracts in the blockchain, and the updating the status of the DS transaction comprises: storing the updated status of the DS transaction in a first node in the blockchain; and synchronizing the updated status of the DS transaction to a second node in the blockchain.

In some embodiments, the method further comprises: in response to receiving a rejection to the DS transaction from the second application, rejecting the DS transaction in the blockchain; updating a status of the DS transaction to indicate a failure of the DS transaction; and rolling back the DS entity to a previous version.

In some embodiments, the method further comprises: in response to receiving a read request from the second application, retrieving data from a DS entity associated with the read request in the blockchain without initiating a DS transaction via a DS transaction Application Programming Interface (API) ; and sending the retrieved data to the second application via a DS entity API, wherein the DS transaction API interfaces with a DS transaction smart contract and the DS entity API interfaces with a DS entity smart contract.

In some embodiments, wherein the approving the DS transaction in the blockchain comprises: sending a further event notification to a third application associated with the DS transaction, wherein the DS transaction is predefined to be approved by both the second application and the third application; and in response to receiving a first approval from the second application and a second approval from the third application, approving the DS transaction in the blockchain.

In another aspect, there is provided an electronic device. The electronic device comprises a processing unit and a memory coupled to the processing unit and storing instructions thereon. The instructions, when executed by the processing unit, perform acts comprising: in response to receiving a write request from a first application, initiating a decentralized shared (DS) transaction associated with the write request in a blockchain, wherein the DS transaction is used for writing data in a DS entity which stores the data in the blockchain; sending an event notification to a second application associated with the DS transaction; and in response to receiving an approval to the DS transaction from the second application, approving the DS transaction in the blockchain.

In some embodiments, wherein the DS transaction and the DS entity are defined as JavaScript Object Notation (JSON) templates and implemented as smart contracts in the blockchain, and the updating the status of the DS transaction comprises: storing the updated status of the DS transaction in a the device in the blockchain; and synchronizing the updated status of the DS transaction to a further device in the blockchain.

In some embodiments, wherein the instructions, when executed by the processing unit, further perform acts comprising: in response to receiving a rejection to the DS transaction from the second application, rejecting the DS transaction in the blockchain; updating a status of the DS transaction to indicate a failure of the DS transaction; and rolling back the DS entity to a previous version.

In some embodiments, wherein the instructions, when executed by the processing unit, further perform acts comprising: in response to receiving a read request from the second application, retrieving data from a DS entity associated with the read request in the blockchain without initiating a DS transaction via a DS transaction Application Programming Interface (API) ; and sending the retrieved data to the second application via a DS entity API, wherein the DS transaction API interfaces with a DS transaction smart contract and the DS entity API interfaces with a DS entity smart contract.

In a further aspect, there is provided a computer program product. The computer program product is stored in a non-transitory computer storage medium and comprises machine-executable instructions. The instructions, when executed on a device, cause the device to perform acts comprising: in response to receiving a write request from a first application, initiating a decentralized shared (DS) transaction associated with the write request in a blockchain, wherein the DS transaction is used for writing data in a DS entity which stores the data in the blockchain; sending an event notification to a second application associated with the DS transaction; and in response to receiving an approval to the DS transaction from the second application, approving the DS transaction in the blockchain.

In some embodiments, wherein the DS transaction and the DS entity are defined as JavaScript Object Notation (JSON) templates and implemented as smart contracts in the blockchain, and the updating the status of the DS transaction comprises: storing the updated status of the DS transaction in the device in the blockchain; and synchronizing the updated status of the DS transaction to a further device in the blockchain.

In some embodiments, wherein the instructions, when executed on a device, further cause the device to perform acts comprising: in response to receiving a rejection to the DS transaction from the second application, rejecting the DS transaction in the blockchain; updating a status of the DS transaction to indicate a failure of the DS transaction; and rolling back the DS entity to a previous version.

In some embodiments, wherein the instructions, when executed on a device, further cause the device to perform acts comprising: in response to receiving a read request from the second application, retrieving data from a DS entity associated with the read request in the blockchain without initiating a DS transaction via a DS transaction Application Programming Interface (API) ; and sending the retrieved data to the second application via a DS entity API, the DS transaction API interfaces with a DS transaction smart contract and the DS entity API interfaces with a DS entity smart contract.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter specified in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

A computer-implemented method, comprising:

in response to receiving a write request from a first application, initiating a decentralized shared (DS) transaction associated with the write request in a blockchain, the DS transaction being used for writing data in a DS entity which stores the data in the blockchain;

sending an event notification to a second application associated with the DS transaction; and

in response to receiving an approval to the DS transaction from the second application, approving the DS transaction in the blockchain.
The method according to claim 1, wherein the initiating the DS transaction in the blockchain comprises:

determining, from the write request, execution information comprising a DS transaction type, a function name and an entity value;

obtaining a DS transaction template based on the DS transaction type; and

executing the DS transaction using the obtained DS transaction template and the determined execution information.
The method according to claim 2, wherein the executing the DS transaction comprises:

in response to the DS entity involving a further DS transaction that has not been approved, forgoing writing of the data in the DS entity; and

generating an error message indicating that the DS entity is unable to be written.
The method according to claim 2, wherein the executing the DS transaction comprises:

in response to a write condition being satisfied, writing the data in the DS entity as a proposal; and

generating, based on the DS transaction template, the event notification indicating an identification of the DS transaction, an identification of the DS entity and a blockchain account address.
The method according to claim 4, wherein the approving the DS transaction in the blockchain comprises:

obtaining a status of the DS transaction based on the identification of the DS transaction; and

updating the status of the DS transaction to indicate a completion of the DS transaction.
The method according to claim 5, wherein the DS transaction and the DS entity are defined as JavaScript Object Notation (JSON) templates and implemented as smart contracts in the blockchain, and the updating the status of the DS transaction comprises:

storing the updated status of the DS transaction in a first node in the blockchain; and

synchronizing the updated status of the DS transaction to a second node in the blockchain.
The method according to claim 1, further comprising:

in response to receiving a rejection to the DS transaction from the second application, rejecting the DS transaction in the blockchain;

updating a status of the DS transaction to indicate a failure of the DS transaction; and

rolling back the DS entity to a previous version.
The method according to claim 1, further comprising:

in response to receiving a read request from the second application, retrieving data from a DS entity associated with the read request in the blockchain without initiating a DS transaction via a DS transaction Application Programming Interface (API) ; and

sending the retrieved data to the second application via a DS entity API, the DS transaction API interfacing with a DS transaction smart contract, and the DS entity API interfacing with a DS entity smart contract.
The method according to claim 1, wherein the approving the DS transaction in the blockchain comprises:

sending a further event notification to a third application associated with the DS transaction, the DS transaction being predefined to be approved by both the second application and the third application; and

in response to receiving a first approval from the second application and a second approval from the third application, approving the DS transaction in the blockchain.
An electronic device, comprising:

a processing unit;

a memory coupled to the processing unit and storing instructions thereon, the instructions, when executed by the processing unit, performing acts comprising:

in response to receiving a write request from a first application, initiating a decentralized shared (DS) transaction associated with the write request in a blockchain, the DS transaction being used for writing data in a DS entity which stores the data in the blockchain;

sending an event notification to a second application associated with the DS transaction; and

in response to receiving an approval to the DS transaction from the second application, approving the DS transaction in the blockchain.
The device according to claim 10, wherein the initiating the DS transaction in the blockchain comprises:

determining, from the write request, execution information comprising a DS transaction type, a function name and an entity value;

obtaining a DS transaction template based on the DS transaction type; and

executing the DS transaction using the obtained DS transaction template and the determined execution information.
The device according to claim 11, wherein the executing the DS transaction comprises:

in response to the DS entity involving a further DS transaction that has not been approved, forgoing writing of the data in the DS entity; and

generating an error message indicating that the DS entity is unable to be written.
The device according to claim 11, wherein the executing the DS transaction comprises:

in response to a write condition being satisfied, writing the data in the DS entity as a proposal; and

generating, based on the DS transaction template, the event notification indicating an identification of the DS transaction, an identification of the DS entity and a blockchain account address.
The device according to claim 13, wherein the approving the DS transaction in the blockchain comprises:

obtaining a status of the DS transaction based on the identification of the DS transaction; and

updating the status of the DS transaction to indicate a completion of the DS transaction.
A computer program product stored in a non-transitory computer storage medium and comprises machine-executable instructions which, when executed on a device, cause the device to perform acts comprising:

in response to receiving a write request from a first application, initiating a decentralized shared (DS) transaction associated with the write request in a blockchain, the DS transaction being used for writing data in a DS entity which stores the data in the blockchain;

sending an event notification to a second application associated with the DS transaction; and

in response to receiving an approval to the DS transaction from the second application, approving the DS transaction in the blockchain.