Advanced Smart Contracts with Decentralized Ledgers in a Multi-Tenant Environment

Abstract

Describes a method for managing data in a multi-tenant server-managed peer blockchain network. The method includes monitoring one or more fields of a first physical object of a first tenant in the peer blockchain network to determine when one or more conditions of a smart contract have been met; determining that the first physical object of the first tenant has met one or more conditions of the smart contract; and in response to determining that the first physical object of the first tenant has met one or more conditions of the smart contract, performing one or more operations of the smart contract associated with the one or more conditions, wherein the one or more operations are performed in relation to a second physical object of a second tenant in the peer blockchain network.

Description

[0001] Divisional Information

[0002] This application is a divisional application of the patent application with application number 201980076057.0, titled "Advanced Smart Contracts with Decentralized Ledger in a Multi-Tenant Environment", filed on September 18, 2019.

[0003] Cross - Reference to Related Applications

[0004] This application claims the benefit of U.S. Patent Application No. 16 / 228,528, filed on December 20, 2018, and U.S. Provisional Application No. 62 / 733,531, filed on September 19, 2018, which are hereby incorporated by reference. Technical Field

[0005] One or more embodiments relate to the field of data management; more specifically, to managing smart contracts in a multi - tenant blockchain network. Background Art

[0006] A blockchain is a continuously growing list of records / blocks linked and secured using cryptographic techniques. Specifically, each block in a blockchain can include the cryptographic hash of the immediately preceding block, the timestamp of the current block, and transaction data (e.g., addition / modification of information associated with peers in the blockchain network). Additionally, the blockchain can be shared and managed via a peer - to - peer network with a system that verifies / confirms new blocks to be added to the chain, such that blocks in the blockchain cannot be altered without changing all subsequent blocks, which requires network consensus. This architecture allows information stored within blocks to be protected using cryptographic techniques; shared / distributed using a peer - to - peer network; trusted through consensus on block addition; and made immutable by using cryptographic techniques, chain processing / linking of blocks, and peer - to - peer distribution (e.g., each peer in a blockchain network can maintain a ledger of all verified / confirmed transactions in the network).

[0007] Some blockchain networks can operate with smart contracts. A smart contract is a cryptographically verifiable contract implemented without a trusted third party. Specifically, a smart contract includes code that describes a set of conditions and a set of operations that are selectively executed in response to one or more of the set of conditions being met. For example, a smart contract can stipulate that when a first party completes a task, digital currency from a second party will be transferred to the account of the first party. These smart contracts are stored in the blockchain network and are immutable based on their inclusion in the blockchain network.

[0008] Compared with blockchain architectures, multi-tenant cloud architectures rely on centralizing information in a common database or other data structures. While cloud-based architectures offer many benefits compared to blockchain architectures, including the ability to remove many administrative functions from tenants and instead centralize those functions on a centralized system, these architectures do not provide the same level of security, trust, and information immutability during communication between tenants. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The following drawings use the same reference numerals to denote the same elements. Although the following drawings illustrate various exemplary embodiments, alternative embodiments are also within the spirit and scope of the appended claims. In the drawings:

[0010] Figure 1 A block diagram is shown illustrating a computing environment including a multi-tenant server in accordance with one exemplary embodiment.

[0011] Figure 2A and Figure 2B A method is shown of a multi-tenant server managing data in a peer-to-peer blockchain network in accordance with one exemplary embodiment, including management of smart contracts.

[0012] Figure 3A A computing environment is shown including a group of individual blockchain services for each tenant system in accordance with one exemplary embodiment.

[0013] Figure 3B A computing environment is shown including a group of shared blockchain services in accordance with another exemplary embodiment.

[0014] Figure 4 A physical object corresponding to a group of tenant systems is shown in accordance with one exemplary embodiment.

[0015] Figure 5 An exchange object is shown including a group of mappings between an exchange field and fields of a physical object in accordance with one exemplary embodiment.

[0016] Figure 6 An example of a shadow object corresponding to a tenant system is shown in accordance with one exemplary embodiment.

[0017] Figure 7 An example of a transaction object is shown in accordance with one exemplary embodiment.

[0018] Figure 8 An example of a blockchain including a group of entries / blocks is shown in accordance with one exemplary embodiment.

[0019] Figure 9A An electronic device is shown in accordance with one exemplary embodiment.

[0020] Figure 9B FIG. shows a block diagram of an environment in which a computing environment and a server can be implemented according to an exemplary embodiment. DETAILED DESCRIPTION

[0021] Figure 1 FIG. is a block diagram showing a computing environment 100 according to an exemplary embodiment. The computing environment 100 includes tenant systems 1021-1023, a multi-tenant server 104, and a group of communication networks 106. In this exemplary computing environment 100, the tenant systems 1021-1023 can be part of a peer-to-peer blockchain network 108, and the multi-tenant server 104 provides a cloud environment to manage data and various transactions of the tenant systems 1021-1023 in the peer-to-peer blockchain network 108 via a transaction queue 104A, tenant-level objects 104B, network-level objects 104C, and blockchain services 104D. In particular, the multi-tenant server 104 provides management of smart contracts through a smart contract manager 112, which is part of the blockchain service 104D.

[0022] As will be described herein, the tenant systems 1021-1023 are part of a multi-tenant environment / system managed by the multi-tenant server 104. For example, the multi-tenant server 104 can manage a multi-tenant database management system (DBMS), where users / tenants associated with the tenant systems 1021-1023 can store and / or retrieve data. A multi-tenant DBMS refers to those systems in which various elements of the hardware and software of the DBMS can be shared by one or more tenants (such as systems 1021-1023). For example, a given server (such as the multi-tenant server 104) can simultaneously process requests from a large number of tenants (such as those represented by the tenant systems 1021-1023), and a given database table can store records for a potentially much larger number of tenants. In addition to managing the multi-tenant environment / system for the tenant systems 1021-1023, as described above, the multi-tenant server 104 can also manage the peer-to-peer blockchain network 108 on behalf of the tenant systems 1021-1023. In some embodiments, the peer-to-peer blockchain network 108 can be regarded as a distributed network controlled by the multi-tenant server 104 using inputs / requests from the tenant systems 1021-1023.

[0023] Although shown with three tenants / peers (such as tenant systems 1021-1023), in other embodiments, the peer-to-peer blockchain network 108 can include more or fewer tenants / peers. For example, the peer-to-peer blockchain network 108 can include two, four, five, or more tenants / peers with corresponding tenant systems 102. Thus, the use of three tenants / peers is for illustrative purposes.

[0024] In some embodiments, the transaction generator 110 of the tenant system 102 can generate requests to (1) add a new record to a physical object associated with the tenant system 102, or (2) modify an existing record of a physical object associated with the tenant system 102. The physical object can include a set of fields for each record and is stored in a part / partition of the tenant-level object 104B of the multi-tenant server 104 associated with the corresponding tenant system 102 such that the physical object is only accessible by the tenant system 102 (e.g., tenant systems 1022 and 1023 are not permitted to read or write to the physical objects of tenant system 1021). The request can result in adding a record in a shadow object in the part / partition of the tenant-level object 104B associated with the tenant system 102. The shadow object represents uncommitted data to the physical object (i.e., data on which no consensus has been reached among peers in the peer-to-peer blockchain network 108). The transaction queue 104A can use the shadow object to generate a transaction object that will be distributed to other tenant systems 102 / such that other tenant systems 102 are available to receive consensus for the proposed addition / modification to the physical objects of the tenant system 102.

[0025] In one embodiment, the set of fields of the transaction object is a subset of the fields of the physical object, and the set of fields of the transaction object is defined by the exchange object included in the network-level object 104C. In this embodiment, the exchange object may include a set of exchange fields that will be included in the transaction object, and each exchange field of the exchange object is mapped to a field in the physical object of the tenant systems 1021-1023. For example, the physical object of tenant system 1021 may include fields A-D, the physical object of tenant system 1022 may include fields E-H, and the physical object of tenant system 1023 may include fields I-K. In this example, the first exchange field of the exchange object of the peer blockchain network 108 may be mapped to field B of tenant system 1021, field F of tenant system 1022, and field I of tenant system 1023. Similarly, the second exchange field of the exchange object of the peer blockchain network 108 may be mapped to field C of tenant system 1021, field E of tenant system 1022, and field J of tenant system 1023. Thus, when a proposal to add / modify a record of the physical object of tenant system 1021 is received, the corresponding transaction object includes a first exchange field having a value of field B from the proposed physical / shadow object and a second exchange field having a value of field C from the proposed physical / shadow object. The exchange object provides a unified transaction object via mapping metadata for verification / confirmation purposes in the peer blockchain network 108, while allowing tenant system 1021 to reveal only a specific portion of the information to other tenants / peers in the peer blockchain network 108 (e.g., sensitive information / fields in the physical object may not be included in the transaction object, which is distributed among tenant systems 1021-1023 in the peer blockchain network 108 and subsequently included in the distributed ledger).

[0026] As described herein, the multi-tenant server 104 may perform many functions of the peer blockchain network 108 on behalf of the tenant systems 1021-1023. Specifically, the multi-tenant server 104 may include virtual spaces / organizations for each of the tenant systems 1021-1023. Each virtual space / organization may include data and applications / services for the corresponding tenant system 1021-1023 and is logically separated from all other virtual spaces / organizations of the other tenant systems 1021-1023. For example, each virtual space / organization may include tenant-level objects 104B that are separately instantiated or accessed corresponding to the corresponding tenant / tenant system 1021-1023 and the blockchain service 104D. In this configuration / architecture, the virtual space / organization of each tenant system 1021-1023 may perform one or more blockchain functions / operations on behalf of the corresponding tenant system 1021-1023. For example, in response to receiving a request from tenant system 1021 to add / insert a new record or modify / update an existing record of a physical object of tenant system 1021, the multi-tenant server 104 may generate a shadow object record in the virtual space / organization of tenant system 1021 within the multi-tenant server 104. In response, the transaction queue 104A may use the exchange objects of the peer blockchain network 108 and the set of cryptographic keys of tenant system 1021 to generate a transaction object corresponding to the record in the shadow object such that the transaction object may be distributed or otherwise made available to the virtual spaces / organizations of the other tenant systems 1022 and 1023. The virtual spaces / organizations of the other tenant systems 1022 and 1023 may then analyze the transaction object to determine if verification / confirmation is appropriate.

[0027] The transaction queue 104A may wait for verification / confirmation from the virtual spaces / organizations of tenant systems 1022 and 1023 to achieve consensus on the proposed change to the physical object of tenant system 1021. In response to the consensus, the virtual space / organization of the leading tenant system 102 may (1) add a record or modify a record (as appropriate) in the corresponding physical object of the leading tenant system 102, and (2) add a corresponding entry / block to the distributed ledger of the leading tenant system 102. Thereafter, the virtual space / organization of the leading tenant system 102 may send requests to the virtual spaces / organizations of the other / remaining tenant systems 102 to delegate the change to their physical objects (based on the mapping defined in the exchange object) and / or add the corresponding entry / block to the ledgers of these other / remaining tenant systems 102.

[0028] As will be described in more detail below, each of the tenant systems 1021 - 1023 can initiate a smart contract by initiating a transaction in the blockchain network 108 via a corresponding transaction generator 1101 - 1103. A smart contract can include a set of conditions and a set of operations that are executed in response to one or more of the set of conditions being met. For example, the set of conditions can include authorization from a patient to share / distribute the patient's medical record in the peer - to - peer blockchain network 108. In this example, the associated operation for this condition that will be executed when the condition is true (i.e., the patient provides authorization to share / distribute the patient's medical record in the peer - to - peer blockchain network 108) will be to share / distribute the patient's medical record to the tenant system 102 in the peer - to - peer blockchain network 108. In some embodiments, a smart contract can operate across multiple objects in the peer - to - peer blockchain network 108. For example, a first physical object can correspond to a patient (e.g., the first physical object associated with tenant system 1021 includes a set of patient records and a set of fields that describe a name, an address, a patient identifier, and an indication of whether the patient's medical record is authorized to be shared / distributed), while a second physical object can correspond to the patient's medical record (e.g., the second physical object associated with tenant system 1022 includes a set of patient medical records and a set of fields that describe the patient identifier associated with the record, a physician identifier, and details regarding the results of a set of medical tests). Using the above - mentioned example smart contract, where the set of conditions includes authorization from a patient to share / distribute the patient's medical record and the associated operation for this condition is to share / distribute the patient's medical record in the peer - to - peer blockchain network 108, in the case where the smart contract manager 112 determines that the patient record in the first physical object includes authorization to share / distribute the medical record, the smart contract manager 112 can initiate a transaction in the peer - to - peer blockchain network 108 corresponding to the patient's medical record in the second physical object. Thus, the smart contract in this example operates across two separate objects associated with separate tenants / peers.

[0029] As described above and as will be described in more detail below, the cloud environment / system provided by the multi - tenant server 104 (e.g., the virtual space / organization provided by the multi - tenant server 104) can be used to manage blockchain transactions between the tenant systems 1021 - 1023. Thus, during inter - tenant communication, the cloud environment / system implemented by the multi - tenant server 104 provides the same level of security, trust, and immutable information as the blockchain network while centralizing the functionality / operations of the peer - to - peer blockchain network 108. In addition, the computing environment 100 including the multi - tenant server 104 implements the peer - to - peer blockchain network 108 to allow the use of smart contracts as described herein.

[0030] This will be described in more detail by way of example below Figure 1each component of the computing environment 100. In some embodiments, the computing environment 100 may include more components than Figure 1 shown. Thus, Figure 1 the computing environment 100 is for illustrative purposes only.

[0031] As Figure 1 shown and as described above, the tenant systems 1021-1023 and the multi-tenant server 104 may be connected via a group of one or more communication networks 106. The group of one or more communication networks 106 may be, for example, a local area network (LAN), a wide area network (WAN), a global area network (GAN) such as the Internet, or a combination of these networks. In another embodiment, the tenant systems 1021-1023 and the multi-tenant server 104 may maintain a direct connection with each other via a wired or wireless medium.

[0032] Each of the tenant systems 1021-1023 may be a computing system operable by one or more users. For example, each of the tenant systems 1021-1023 may be a personal computer (PC), a workstation, a laptop computer, a tablet computer, a mobile phone, a smartphone, a personal digital assistant (PDA), etc. As will be described in more detail below, the tenant systems 1021-1023 may communicate with the multi-tenant server 104 to modify / add / store and retrieve data.

[0033] The tenant systems 1021-1023 (sometimes referred to as clients, peers, or user systems) may each include a screen / display (e.g., a liquid crystal (LCD) display) for presenting an interface to the user (e.g., a graphical user interface (GUI)), including an interface presented in a web page. As will be described in more detail below, each of the tenant systems 1021-1023 may include a corresponding transaction generator 110 for receiving input from a user (e.g., via a user interface) to change a physical object (e.g., add a new record in a physical object or modify an existing record in a physical object) or add / update a smart contract in a peer blockchain network.

[0034] The tenant systems 1021-1023 may each be associated with one or more organizations / tenants managed by the multi-tenant server 104. For example, the users of the tenant system 1021 may be customers of the first group of organizations / tenants, and the users of the tenant system 1022 may be customers of the second organization / tenant. An organization / tenant may be any company, enterprise, institution, association, or society that has contracted with the administrator of the multi-tenant server 104 to provide users with access to the data stored therein via the tenant systems 1021-1023.

[0035] In one embodiment, the multi-tenant server 104 can be any computing device that provides users with access to resources via tenant systems 1021 - 1023 and a communication network 106. For example, the multi-tenant server 104 can provide users of tenant systems 1021 - 1023 with access to one or more physical objects and / or data in one or more corresponding distributed peer-to-peer ledgers that describe changes to the physical objects. For example, the physical object of tenant system 1021 can correspond to a medical laboratory report. In this exemplary embodiment, the records in the physical object can include a laboratory report identifier field, a patient name field, a laboratory network identifier field, a laboratory test identifier field, a patient identifier field, a social security number field, and an assignment field, where the assignment field indicates when the patient has authorized the sharing / distribution of the patient's medical records in the peer blockchain network 108. When changes / alterations are desired to the physical objects of tenant system 102 (e.g., adding a new record to a physical object or modifying an existing record in a physical object), the multi-tenant server 104 uses a transaction queue 104A, tenant-level objects 104B, network-level objects 104C, and a blockchain service 104D to attempt to make these changes in the peer blockchain network 108 (e.g., changes reflected in the physical objects and the distributed ledgers associated with tenant systems 1021 - 1023).

[0036] The multi-tenant server 104 can include various elements of the hardware and software of the multi-tenant system. As used herein, the term "multi-tenant system" refers to those systems in which various elements of the hardware and software can be shared by one or more tenants. For example, the multi-tenant server 104 can simultaneously process requests from a large number of tenants, and a given database table can store records for a potentially much larger number of tenants. The multi-tenant server 104 can include an application platform that includes an architecture (e.g., services and metadata) that allows applications to execute, such as the hardware or software infrastructure of the system. In one embodiment, the multi-tenant server 104 includes separate virtual spaces / organizations (sometimes referred to as partitions or segments) for the data / objects and services of each tenant system 1021 - 1023. For example, each tenant system 1021 - 1023 can be assigned a separate virtual space / organization. Each virtual space / organization is a logical partition within the multi-tenant server 104 and includes separate tenant-level objects 104B (e.g., tenant system 102 cannot read and / or write the tenant-level objects 104B of another tenant system 102) that are only available to that tenant system 102 and not to other tenant systems 102, in addition to services (e.g., blockchain service 104D) used by the multi-tenant server 104 on behalf of the corresponding tenant system 102.

[0037] Referring now to FIG. 2, a method 200 for a multi-tenant server 104 to manage data in a peer-to-peer blockchain network 108 will be described according to some embodiments. Specifically, the multi-tenant cloud environment provided by the multi-tenant server 104 can be used to manage smart contracts in the blockchain network 108. In some embodiments, as will be described in more detail below, a smart contract can span / operate on multiple physical objects in the peer-to-peer blockchain network 108 and can be modified through consensus in the peer-to-peer blockchain network 108.

[0038] In conjunction with Figure 1 the exemplary computing environment 100 shown, Figure 3A the exemplary computing environment 300A shown and / or Figure 3B the exemplary computing environment 300B shown will be used to describe the method 200. However, in other embodiments, the method 200 can operate in other environments, including different embodiments of the multi-tenant server 104.

[0039] As described above, the operations in the flowchart of FIG. 2 will be described with reference to exemplary embodiments of other figures. However, it should be understood that the operations of the flowchart can be performed by embodiments different from those discussed with reference to the other figures, and the embodiments discussed with reference to these other figures can perform operations different from those discussed with reference to the flowchart.

[0040] Although described and shown in a particular order in FIG. 2, the operations of the method 200 are not limited to that order. For example, one or more operations of the method 200 can be performed in a different order or in partially or fully overlapping time periods. Thus, the description and depiction of the method 200 are for illustrative purposes and are not intended to be limited to a particular embodiment.

[0041] As shown in FIG. 2, the method 200 can begin at operation 202, where the membership service 302A of the blockchain service 104D determines and / or adds groups of tenants (sometimes also referred to as peers) to the peer-to-peer blockchain network 108. In some embodiments, the peer-to-peer blockchain network 108 is identified in the network object 304A, and the tenants for the peer-to-peer blockchain network 108 (e.g., the tenants represented by the identifiers of the tenant systems 1021 - 1023) are identified in the peer object 304B. For example, the membership service 302A can determine the groups of tenants in the peer-to-peer blockchain network 108 by examining the peer object 304B at operation 202. In some embodiments, adding a tenant / tenant systems 1021 - 1023 to the peer-to-peer blockchain network 108 may require reaching a consensus through a verification / confirmation process from the current tenant / tenant systems 1021 - 1023 in the peer-to-peer blockchain network 108. In Figure 1 the exemplary computing environment 100, Figure 3Ain exemplary computing environment 300A and Figure 3B in exemplary computing environment 300B, the following is used to illustrate method 200. At operation 202, membership service 302A determines that peer blockchain network 108 includes tenant systems 1021 - 1023, which represent tenants / peers.

[0042] As described above, each of tenant systems 1021 - 1023 may include separate virtual spaces / organizations within multi - tenant server 104. Each virtual space / organization includes a separate tenant - level object 104B, which is only available to that tenant system 1021 - 1023 and not to other tenant systems 1021 - 1023 (e.g., tenant systems 1021 - 1023 cannot read and / or write to the tenant - level object 104B of another tenant system 1021 - 1023), except for services used by multi - tenant server 104 representing the corresponding tenant systems 1021 - 1023 (such as blockchain service 104D). For example, as Figure 3A shown, each of tenant systems 1021 - 1023 may be associated with separate virtual spaces / organizations 3141 - 3143 having corresponding tenant - level objects 104B1 - 104B3 (such as physical objects 3061 - 3063, shadow objects 3081 - 3083, peer ledgers 3101 - 3103, and mapping objects 3161 - 3163) and blockchain services 104D1 - 104D3 including corresponding smart contract managers 1121 - 1123. Although shown in Figure 3A as separate instantiations of blockchain services 104D1 - 104D3 for each virtual space / organization 3141 - 3143, each virtual space / organization 3141 - 3143 may instead have separate access to a single instantiation of blockchain service 104D as Figure 3B shown.

[0043] At operation 204, the membership service 302A may generate a set of public keys (PKs) and private keys / secret keys (SKs) for each tenant / tenant system 1021 - 1023 in the peer - to - peer blockchain network 108. In one embodiment, the public key is generated based on the determined private key. For example, a one - way cryptographic hash function (such as SHA256) may be used to generate the public keys of the tenant systems 1021 - 1023 based on the corresponding private keys. In one embodiment, after being generated at operation 204, the public keys and private keys / secret keys may be stored by the membership service 302A in the wallet object 304C. As will be described in more detail below, the transaction queue 104A may utilize the private keys / secret keys stored in the wallet object 304C to generate transaction objects for each of the tenant systems 1021 - 1023. Specifically, the transaction queue 104A may use the private keys / secret keys to implement the cryptographic elements of the transactions used by the peer - to - peer blockchain network 108.

[0044] At operation 206, the membership service 302A may determine an exchange object for the peer - to - peer blockchain network 108. In one embodiment, the exchange object is defined by a set of exchange fields and mapping metadata that defines the mapping between each exchange field and a field in the physical objects of the tenant systems 1021 - 1023. For example Figure 4 Physical objects 3061 - 3063 of the tenant systems 1021 - 1023 are shown respectively. In this example, the physical object 3061 corresponding to the tenant system 1021 includes records 4041 - 404 M , the records 4041 - 404 M are composed of fields 4061 - 406 N , and each record 4041 - 404 M includes values 408 N for each field 4061 - 406 1,1-M,N . Similarly, the physical object 3062 corresponding to the tenant system 1022 includes records 4101 - 410 H composed of fields 4121 - 412 G , and each record 4101 - 410 G includes values 414 H for each field 4121 - 412 1,1-G,H . Similarly, the physical object 3063 corresponding to the tenant system 1023 includes records 4161 - 416 s composed of fields 4181 - 418 Q , and each record 4161 - 416 Q includes values 420 s for each field 4181 - 418 1,1-Q,S。Each of the physical objects 3061-3063 can represent any type of data. For example, the tenant system 1021 can operate in a medical laboratory or otherwise correspond to a medical laboratory. In this example, the physical object 3061 can represent a medical laboratory report (e.g., each of the records 4041-4042 can correspond to a separate medical laboratory report). The tenant system 1022 can operate in a doctor's office or otherwise correspond to a doctor's office. In this example, the physical object 3062 can represent a patient file (e.g., each of the records 4101-410 G can correspond to a separate patient file).

[0045] For Figure 4 the exemplary physical objects 3061-3063 shown, the membership service 302A can determine the exchange object 502 that can be stored in the digital asset object 304D as shown Figure 5 . As shown Figure 5 , the exchange object 502 is defined by the exchange fields 5041-504 P and the mapping metadata that maps the exchange fields 504 to the fields of the physical object 306. In this configuration, the exchange field 5041 is mapped to the field 4062 of the physical object 3061, the field 412 H of the physical object 3062, and the field 4182 of the physical object 3063. The exchange field 5042 is mapped to the field 406 N of the physical object 3061, the field 4121 of the physical object 3062, and the field 4181 of the physical object 3063. The exchange field 504 P is mapped to the field 4061 of the physical object 3061, the field 4122 of the physical object 3062, and the field 418 S of the physical object 3063. Thus, the mapping metadata of the exchange object 502 maps / links the exchange fields 504 to the fields of the physical object 306. In some embodiments, the number of exchange fields 5041-504 P (i.e., P) is less than (1) the number of fields 4061-406 N in the physical object 3061 (i.e., N), (2) the number of fields 4121-412 H in the physical object 3062 (i.e., H), and / or (3) the number of fields 4181-418 S in the physical object 3063 (i.e., S). Thus, the generated transaction objects distributed among the tenant systems 1021-1023 and the corresponding data / information included in the distributed peer-to-peer ledger 310 may not include sensitive data.

[0046] The mapping of the exchange fields 504 to the fields 406, 412, and 418 of the physical objects 3061 - 3063 indicates the relationship between the fields 406, 412, and 418 of the physical objects 3061 - 3063. For example, using the above example where the physical object 3061 represents a medical laboratory report and the physical object 3062 represents a patient file, the field 4062 of the physical object 3061 can correspond to the patient identifier for which the corresponding medical laboratory report is generated and the field 412 of the physical object 3062 H can correspond to the patient identifier for which it represents the corresponding patient file. As Figure 5 shown and as described above, these fields 4062 and 412 H are mapped to the same exchange field 5041, indicating that these fields 4062 and 412 H represent similar data (e.g., fields 4062 and 412 H both represent patient identifiers).

[0047] In some embodiments, each tenant / tenant system 1021 - 1023 can be part of multiple blockchain networks including the blockchain network 108. Each of these blockchain networks can include overlapping membership with the blockchain network 108 and / or can include additional peers / tenant systems 102. In some embodiments, the network object 304A can include the identifier of each blockchain network managed by the multi - tenant server 104, the peer object 304B can include the identifier for each peer / tenant system 102 in the blockchain networks managed by the multi - tenant server 104, the wallet object 304C can include the keys for each peer / tenant system 102 in the blockchain networks managed by the multi - tenant server 104, and the digital asset object 304D can include the exchange object 502 for each blockchain network managed by the multi - tenant server 104. In some embodiments, the tenant - level object 104B of each tenant system 102 can include a mapping object 316. Each mapping object 316 includes mapping metadata for the corresponding tenant system 102. For example, the mapping object 3161 corresponding to the tenant system 1021 includes mapping metadata that maps the exchange field 5041 to the field 4062 of the physical object 3061; mapping metadata that maps the exchange field 5042 to the field 406 N of the physical object 3061; and mapping metadata that maps the exchange field 504 P to the field 4061 of the physical object 3061. Conversely, the mapping object 3162 corresponding to the tenant system 1022 includes mapping metadata that maps the exchange field 5041 to the field 412 of the physical object 3062 Hmapping metadata; mapping metadata that maps the exchange field 5042 to the field 4121 of the physical object 3062; and mapping the exchange field 504 P to the mapping metadata of the field 4122 of the physical object 3062. Finally, the mapping object 3163 corresponding to the tenant system 1023 includes mapping metadata that maps the exchange field 5041 to the field 4182 of the physical object 3063; mapping metadata that maps the exchange field 5042 to the field 4181 of the physical object 3063; and mapping the exchange field 504 P to the field 418 of the physical object 3063 S of the mapping metadata. Therefore, each mapping object 316 only includes mapping metadata associated with the corresponding tenant system 102.

[0048] In operation 208, the smart contract manager 112 receives a smart contract request for establishing a smart contract in the peer-to-peer blockchain network 108. In one embodiment, the smart contract request is received from the tenant system 102 and defines the smart contract to be used in the peer-to-peer blockchain network 108. For example, the smart contract can include a set of conditions and a set of operations that are executed in response to one or more of the set of conditions being satisfied. For example, the set of conditions can include authorization from a patient to share / assign the patient's medical record in the peer-to-peer blockchain network 108. In this example, the associated operation for this condition that will be executed when the condition is true (i.e., the patient provides authorization to share / assign the patient's medical record in the peer-to-peer blockchain network 108) will be to share / assign the patient's medical record to the tenant system 102 in the peer-to-peer blockchain network 108. In some embodiments, the smart contract can operate across multiple objects in the peer-to-peer blockchain network 108. For example, the physical object 3061 can correspond to a patient medical record (e.g., the physical object 3061 includes a set of patient medical records 404 and a set of fields 406, and the set of fields 406 describes patient identifiers, physician identifiers, and details about the results of a set of medical tests associated with the records 404), while the physical object 3062 associated with the tenant system 1022 can correspond to a patient (e.g., the physical object 3062 includes a set of patient records 410 and a set of fields 412, and the set of fields 412 describes a name, an address, a patient identifier, and an indication as to whether the corresponding patient medical record 404 is authorized for sharing / assignment in the peer-to-peer blockchain network 108). Using the above example smart contract, where the set of conditions includes authorization from a patient to share / assign the patient's medical record and the associated operation for this condition is to share / assign the patient's medical record to the tenant system 102 in the peer-to-peer blockchain network 108, the smart contract manager 112 can initiate a transaction in the peer-to-peer blockchain network 108 corresponding to the patient medical record 404 in the physical object 3061 in the case where the smart contract manager 112 determines that the patient record 410 in the physical object 3062 includes authorization to share / assign the medical record 404 of the physical object 3061. Thus, the smart contract in this example operates across two separate physical objects 306 associated / owned by separate tenant systems 102. For purposes of explanation, method 200 will be described in connection with the above smart contract.

[0049] In operation 210, the smart contract manager 112 may attempt to obtain consensus on a smart contract from tenant systems 102 in the peer blockchain network 108. To attempt to obtain consensus on the smart contract, the event management service 302C and / or the transaction queue 104A may make the smart contract object available to tenant systems 102 in the peer blockchain network 108. In some embodiments, making the smart contract object available to other tenant systems 102 includes: the transaction queue 104A using the private key of tenant system 1021 (or a similar technique according to the blockchain protocol) to sign the smart contract object and placing the smart contract object with the applied signature in a portion / partition of the multi-tenant server 104 that is available to other tenant systems 1022 and 1023. For example, as described above, the multi-tenant server 104 may include separate virtual spaces / organizations 314 for each tenant system 102. Each virtual space / organization 314 includes data and services that are only available to that tenant system 102 and not available to other tenant systems 102. For example, the multi-tenant server 104 may pass the smart contract object from virtual space / organization 3141 of tenant system 1021 to virtual spaces / organizations 3142 and 3143 of tenant systems 1022 and 1023 (which received the initial smart contract request from tenant system 1021), such that the virtual spaces / organizations 3142 and 3143 of tenant systems 1022 and 1023 can process / analyze the smart contract object for possible verification / confirmation.

[0050] In operation 212, the transaction management service 302B may monitor responses from tenant systems 1022 and 1023 to determine whether consensus has been reached on the smart contract or whether consensus has failed to be reached. In one embodiment, the consensus management service 302D may define thresholds or rules that the transaction management service 302B uses when determining when tenant systems 1022 and 1023 have reached consensus on the smart contract. For example, in some embodiments, the consensus management service 302D may indicate that consensus requires all tenant systems 1022 and 1023 to verify / confirm the smart contract, while in other embodiments, the consensus management service 302D may indicate that consensus requires a majority of tenant systems 1022 and 1023 to verify / confirm the smart contract. In some embodiments, the consensus management service 302E indicates the rules and / or operations used by tenant systems 1022 and 1023, particularly the virtual spaces / organizations 3142 and 3143 associated with tenant systems 1022 and 1023, to determine whether the verification / confirmation of the smart contract is appropriate. For example, the consensus management service 302E may indicate that the public key of tenant system 1021 is used together with the signature and the smart contract object to determine whether the smart contract object originated from tenant system 1021 and was authorized by tenant system 1021.

[0051] At operation 214, the transaction management service 302B and the transaction queue 104A may abandon the smart contract object in response to a failure to obtain consensus from tenant systems 1022 and 1023 (e.g., failure to obtain the consensus defined / indicated by the consensus management service 302D). In some embodiments, abandoning the smart contract object may include indicating to the tenant system 1021 that sent / generated the initial smart contract request that the smart contract has been rejected by the peer blockchain network 108 (i.e., consensus in the peer blockchain network 108 has not been achieved / obtained).

[0052] In operation 216, the transaction management service 302B may submit, on behalf of the leader tenant system 102, the smart contract object on which consensus has been reached. In some implementations, the transaction management service 302B may add an entry / block in the peer ledger 310 corresponding to the smart contract object on behalf of the leader tenant system 102. Specifically, the transaction management service 302B of the virtual space / organization 314 of the leader tenant system 102 may add an entry / block in the peer ledger 310 corresponding to the smart contract object on behalf of the leader tenant system 102. The entry / block added to the peer ledger 310 may include multiple pieces of information. For example, as Figure 8 shown, each entry / block 8041-804 in the peer ledger 3101 T may include a reference to the previous entry / block 804 in the peer ledger 8021, the smart contract object (and one or more other objects), and a nonce (i.e., any number used to satisfy the requirements of the peer chain block network 108).

[0053] In operation 218, the transaction management service 302B and / or the transaction queue 104A may submit, on behalf of the remaining tenant systems 102, the smart contract objects on which consensus has been reached. In some embodiments, submitting the smart contract objects by the remaining tenant systems 102 may include the leader tenant system 102 sending a request or otherwise triggering the remaining tenant systems 102 to submit the smart contract objects on which consensus has been reached. In particular, the transaction management services 302B of the virtual spaces / organizations 3141-3143 of the leader tenant systems 1021-1023 pass a request or otherwise make a request or otherwise trigger the transaction management services 302B of the virtual spaces / organizations 3141-3143 of the remaining tenant systems 1021-1023 to add blocks / entries to the corresponding peer ledgers 3101-3103. The peer ledgers 3101-3103 allow the computing environments 100, 300A, and / or 300B to maintain data transparency and auditability. Specifically, the multi-tenant server 104 provides immutability for each transaction by recording / reflecting the transaction in the peer ledgers 3101-3103, which are replicated across all tenant systems 1021-1023. As described above, the tenant systems 1021-1023 participate in a consensus mechanism to verify / confirm transactions / smart contract objects and only submit the transactions / smart contract objects to the peer ledgers 3101-3103 after verifying / confirming the transactions / smart contract objects. In some embodiments, the peer ledgers 3101-3103 may be stored in a Merkle directed acyclic graph (DAG) structure. The Merkle DAG may be represented in an Oracle and / or HBase memory.

[0054] Although operations 208-216 are described as being performed to add smart contracts to the peer blockchain network 108, in some embodiments, operations 208-216 may be similarly used to change smart contracts in the peer blockchain network 108. For example, operations 208-216 may be used to provide consensus in the peer blockchain network 108 to add or modify the conditions or operations of a smart contract that has already been submitted / established in the peer blockchain network 108.

[0055] In operation 220, the smart contract manager 112 may continuously monitor and determine whether a set of conditions of the smart contract have been met. For example, in the above example smart contract, in response to determining that the patient record 410 in the physical object 3062 includes authorization to share / assign the medical record 404 of the physical object 3061, the method 200 may move to operation 222. Conversely, in the above example smart contract, in response to determining that the patient record 410 in the physical object 3062 does not include authorization to share / assign the medical record 404 of the physical object 3061, the method 200 may remain in operation 220.

[0056] In operation 222, one or more operations associated with the set of conditions determined to be satisfied in operation 220 are performed. In the above example smart contract, the set of operations may include the smart contract manager 112 initiating a transaction in the peer-to-peer blockchain network 108 corresponding to the patient medical record 404 in the physical object 3062. For example, the patient medical record 404 may be shared / distributed in the peer-to-peer blockchain network 108 through the consensus process described herein. For example, Figure 2B illustrates the set of operations that may be performed in operation 222.

[0057] As Figure 2B shown, in operation 222A, the smart contract manager 112 may cause the transaction management service 302B of the virtual space / organization 3142 to generate a record in the shadow object 3082 corresponding to the record 410 of the physical object 3062. The shadow object 3082 may correspond to the tenant system 1022 and may include all fields 4121-412 H of the physical object 3062. The shadow object 3082 represents uncommitted data in the network 108. As will be described in more detail below, the data in the shadow object 3082 of the tenant system 1022, in addition to being represented by the peer ledgers 310 of other tenant systems 102 and the physical object 306, needs to be verified / confirmed by other tenant systems 102 through consensus before being submitted and represented by the peer ledger 3102 of the tenant system 1022.

[0058] Figure 6 illustrates an example of a shadow object 3082 corresponding to the tenant system 1022 and the physical object 3062 according to one example implementation. As shown, the shadow object 3082 includes records 6041 and 6042 corresponding to uncommitted data. For example, record 6041 may propose a submission of a record 410 corresponding to a medical laboratory report to the peer-to-peer blockchain network 108.

[0059] In operation 222B, the event management service 302C and / or the transaction queue 104A may generate a transaction object based on (1) the record 604 added to the shadow object 3082 in operation 222A and (2) the exchange object 502 of the peer-to-peer blockchain network 108. In particular, the transaction object may include values for each exchange field 5041-504 P and the transaction object includes data / field values from the record 604 in the corresponding exchange fields 5041-504 P . For example, Figure 7 illustrates an example of a transaction object 702 according to one example implementation.

[0060] As Figure 7As shown, the trading object 802 is based on the mapping between the exchange fields 5041-504 P and the fields 412 of the physical object 3062 to include all the exchange fields 5041-504 of the exchange object 502 P and the field values 606 from the records 6041 in the shadow object 3082 in place. As will be described below, the trading object 702, which will be used for illustrative purposes hereinafter, can be passed or otherwise made available to other tenant systems 102 to determine if there is consensus in the peer blockchain network 108 to submit the proposed record 410 (e.g., verify / confirm the trading object 702).

[0061] In operation 222C, the event management service 302C and the transaction queue 104A can make the trading object 702 available to other tenant systems 1021 and 1023. In some embodiments, making the trading object 702 available to other tenant systems 1021 and 1023 includes the transaction queue 104A using the private key of tenant system 1022 (or a similar technique according to the blockchain protocol) to sign the trading object 702 and placing the trading object 702 with the applied signature in a part / partition of the multi-tenant server 104 available to tenant systems 1021 and 1023. For example, as described above, the multi-tenant server 104 can include separate virtual spaces / organizations 314 for each tenant system 102. Each virtual space / organization 314 includes data and services that are only available to that tenant system 102 and not available to other tenant systems 102. In operation 223C, the multi-tenant server 104 can transfer the trading object 702 with the applied signature from the virtual space / organization 3142 of tenant system 1022 to the virtual spaces / organizations 3141 and 3143 of tenant systems 1021 and 1023 so that the virtual spaces / organizations 3141 and 3143 of tenant systems 1021 and 1023 can process / analyze the trading object 702 for possible verification / confirmation.

[0062] In operation 222D, the transaction management service 302B can monitor responses from tenant systems 1021 and 1023 to determine whether consensus has been reached or not reached regarding the transaction object 702. In one embodiment, the consensus management service 302D can define thresholds or rules for the transaction management service 302B to determine when tenant systems 1021 and 1023 reach consensus regarding the transaction object 702. For example, in some embodiments, the consensus management service 302D can indicate that consensus requires all tenant systems 1021 and 1023 to verify / confirm the transaction object 702, while in other embodiments, the consensus management service 302D can indicate that consensus requires most tenant systems 1021 and 1023 to verify / confirm the transaction object 702. In some embodiments, the consent management service 302E indicates the rules and / or operations used by tenant systems 1021 and 1023, particularly the virtual spaces / organizations 3141 and 3143 associated with tenant systems 1021 and 1023, to determine whether the verification / confirmation of the transaction object 702 is appropriate. For example, the consent management service 302E can indicate that the public key of tenant system 1022 is used together with the signature and the transaction object 702 to determine whether the transaction object 702 originated from tenant system 1022 and is authorized by tenant system 1022.

[0063] In operation 222E, the transaction management service 302B and the transaction queue 104A can abandon the transaction object 702 in response to failure to obtain consensus from tenant systems 1021 and 1023 (e.g., failure to obtain the consensus defined / indicated by the consensus management service 302D).

[0064] In operation 222F, the transaction management service 302B can submit, on behalf of the leader tenant system 102, the transaction object 702 and / or the record 604 in the shadow object 3082 corresponding to the transaction object 702 for which consensus has been reached. In some embodiments, the leader tenant system 102 can be randomly selected by the membership service 302A from among tenant systems 1021 - 1023 in the peer blockchain network 108. Submitting the transaction object 702 can include one or more of the following operations: adding the record 604 to the physical object 306 on behalf of the leader tenant system 102, and adding an entry / block in the peer ledger 310 corresponding to the transaction object 702. For example, the transaction management service 302B of the virtual space / organization 314 of the leader tenant system 102 can add an entry / block in the peer ledger 310 corresponding to the transaction object 702 on behalf of the leader tenant system 102. The entry / block added to the peer ledger 310 can include multiple pieces of information. For example, as Figure 8 shown, each entry / block 8041 - 804 in the peer ledger 3101 Tmay include a reference to a previous entry / block 804 in the peer ledger 3101, a transaction object 702 (and one or more other objects), and a random number (any amount required to satisfy the requirements of the peer blockchain network 108).

[0065] In operation 222G, the transaction management service 302B and / or the transaction queue 104A may send a request or otherwise trigger other tenant systems 102 on behalf of the leader tenant system 102 to submit the transaction object 702 to the corresponding physical object 306 and / or add a block / entry to the corresponding peer ledger 310.

[0066] As described above, the method 200 allows the multi-tenant server 104 to manage data in the peer blockchain network 108 on behalf of the tenant systems 1021-1023. Specifically, the cloud environment provided by the multi-tenant server 104 can be used for blockchain transactions between the tenant systems 1021-1023. Thus, the method 200 allows the cloud environment to provide the same level of information security, trust, and immutability as the blockchain network during tenant-to-tenant communication while centralizing the functionality / operations of the peer blockchain network 108. Additionally, the computing environment 100 including the multi-tenant server 104 implements the peer blockchain network 108 to allow the use of smart contracts as described herein, including smart contracts that operate across tenant objects and smart contracts that must be verified (introduced and modified) consensus-ly in the peer blockchain network 108.

[0067] In some embodiments, the computing environment 300A and / or 300B may be built on top of a platform 312 that includes services and / or metadata for other components used to implement the multi-tenant server 104. In some embodiments, the blockchain service 104D may include additional services such as a coin service 302F for tracking records and items associated with each tenant / peer.

[0068] As used above, the term "user" refers to an entity (such as an individual) that uses the system and / or service. A multi-tenant architecture provides each tenant with dedicated sharing of software instances and the ability (usually) to input tenant-specific data for user management, tenant-specific functions, configuration, customization, non-functional attributes, associated applications, etc. Multi-tenant contrasts with a multi-instance architecture in which separate software instances operate on behalf of different tenants. A tenant includes a group of users who share common access with specific permissions to the software instance that provides the service. A tenant can be an organization (such as a company, a department within a company, etc.). A tenant can have one or more roles with respect to the system and / or service. For example, in the context of a customer relationship management (CRM) system or service, a tenant can be a vendor that uses the CRM system or service to manage information about one or more customers of the tenant with respect to a supplier. As another example, in the context of data as a service (DAAS), a group of tenants can be the vendors that provide the data, while another group of tenants can be the customers of different vendors or the data of all vendors. As another example, in the context of platform as a service (PAAS), a group of tenants can be third-party application developers that provide applications / services, while another group of tenants can be the customers of different third-party application developers or all third-party application developers. A user can have one or more roles with respect to the system and / or service. To provide some examples, a user can be a representative (sometimes referred to as an "end user") of a tenant (such as a vendor or a customer), a representative (such as an administrator) of the company that provides the system and / or service, and / or a representative (such as a programmer) of a third-party application developer who is creating and maintaining platform as a service (PAAS) on the platform.

[0069] One or more portions of the above-described embodiments may include software and / or a combination of software and hardware. An electronic device (also referred to as a computing device, computer, etc.) includes hardware and software, such as a collection of one or more processors coupled to one or more machine-readable storage media (e.g., magnetic disks, optical disks, read-only memory (ROM), flash memory, phase change memory, solid state drive (SSD)) to store code (which consists of software instructions and which is sometimes referred to as computer program code or a computer program) for execution on the collection of processors and / or to store data. For example, an electronic device may include non-volatile memory (having slower read / write times, such as magnetic disks, optical disks, read-only memory (ROM), flash memory, phase change memory, SSD) and volatile memory (e.g., flash memory, dynamic random access memory (DRAM), static random access memory (SRAM)), where the non-volatile memory retains the code / data even when the electronic device is powered on. Because volatile memory typically has faster read / write times, during operation, the portion of the code that is to be executed by the set of processors of the electronic device is copied from the non-volatile memory to the volatile memory of the electronic device. As another example, an electronic device may include non-volatile memory (e.g., phase change memory) that stores code / data when the electronic device is powered off, and the non-volatile memory has read / write times fast enough such that the portion of the code / data that is not to be executed is not copied to volatile memory and the code / data can be provided directly to the set of processors (e.g., not loaded into the cache of the set of processors); in other words, the non-volatile memory serves as both long-term storage and main memory, and thus the electronic device may not have or may have only a small amount of volatile memory for main memory. In addition to storing code and / or data on machine-readable storage media, a typical electronic device may transmit code and / or data on one or more machine-readable transmission media (also referred to as carrier waves) (e.g., electrical, optical, radio, acoustic, or other forms of propagating signals - such as carrier waves, infrared signals). For example, a typical electronic device also includes a group of one or more physical network interfaces to establish network connections with other electronic devices (to transmit and / or receive code and / or data using the propagating signals). Thus, an electronic device may store code and / or transmit (internally and / or over a network with other electronic devices) code and / or data with one or more machine-readable media (also referred to as computer-readable media).

[0070] An electronic device is used for various purposes. For example, an electronic device (sometimes referred to as a server electronic device) can perform operations that enable it to act as a means for another electronic device (sometimes referred to as a client electronic device, client computing device, or client device) to execute client software (sometimes referred to as client code or tenant system) to communicate with a service. The server and client electronic devices can be operated by users in the roles of an administrator (also referred to as a management user) and an end user, respectively.

[0071] Figure 9A FIG. is a block diagram showing an electronic device 900 in accordance with some exemplary embodiments. Figure 9A It includes hardware 920, which includes a set of one or more processors 922, a set of one or more network interfaces 924 (wireless and / or wired), and a non-transitory machine-readable storage medium 926 in which software 928 (which includes instructions executable by the set of one or more processors 922) is stored. Each of the previously described tenant system 102 and transaction queue 104A, tenant-level object 104B, network-level object 104C, and blockchain service 104D can be implemented in one or more electronic devices 900. In one embodiment: 1) each tenant system 102 is implemented in a separate one of the electronic devices 900 (e.g., in a user electronic device operated by a user, where the software 928 represents software for implementing the tenant system 102 to interface with the transaction queue 104A, tenant-level object 104B, network-level object 104C, and blockchain service 104D (e.g., a web browser, local client, portal, command-line interface, and / or application programming interface (API) based on protocols such as Simple Object Access Protocol (SOAP), Representational State Transfer (REST), etc.); 2) the transaction queue 104A, tenant-level object 104B, network-level object 104C, and blockchain service 104D are implemented in a separate collection of one or more of the electronic devices 900 (e.g., a set of one or more server electronic devices, where the software 928 represents software for implementing the transaction queue 104A, tenant-level object 104B, network-level object 104C, and blockchain service 104D); and 3) in operation, the electronic devices implementing the tenant system 102 and the transaction queue 104A, tenant-level object 104B, network-level object 104C, and blockchain service 104D will be communicatively coupled (e.g., via a network) and will establish a connection between them (or through one or more other layers) for delegating a proposed new record or a proposed modification to an existing record in a physical object to the multi-tenant server 104. In other embodiments (e.g., embodiments where the tenant system 102 and the multi-tenant server 104 are implemented on a single electronic device 900), other configurations of the electronic device can be used.

[0072] In an electronic device using computing virtualization, a collection of one or more processors 922 typically execute software to instantiate a virtualization layer 908 and software containers 904A - R (e.g., using operating system - level virtualization, the virtualization layer 908 represents the kernel of the operating system (or a shim executing on top of a base operating system), which allows the creation of multiple software containers 904A - R (representing separate user - space instances and also referred to as virtualization engines, virtual private servers, or jails), and these software containers can each be used to execute a group of one or more applications; using full virtualization, the virtualization layer 908 represents a hypervisor (sometimes referred to as a virtual machine monitor (VMM)) or hypervisor executing on top of a host operating system, and the software containers 904A - R each represent a tightly isolated form of a software container called a virtual machine, which is run by the hypervisor and may include a guest operating system; for para - virtualization, the operating system or application running with the virtual machine may be aware of the virtualization for optimization purposes. Similarly, in an electronic device using computing virtualization, during operation, an instance of software 928 (shown as instance 906A) executes within software container 904A on virtualization layer 908. In an electronic device not using computing virtualization, instance 906A executes on top of a host operating system on a "bare - metal" electronic device 900. The instantiation of instance 906A, along with the virtualization layer 908 and software containers 904A - R (if implemented) are collectively referred to as software instance 902.

[0073] Alternative embodiments of the electronic device can have various variations different from the above - described embodiments. For example, customized hardware and / or accelerators can also be used in the electronic device.

[0074] A network device (ND) is an electronic device that communicatively interconnects other electronic devices on a network (e.g., other network devices, user electronic devices, server electronic devices, etc.). Some network devices are "multi - service network devices" that provide support for multi - networking functions (e.g., routing, bridging, switching, layer 2 aggregation, session border control, quality of service, and / or user management), and / or provide support for multi - application services (e.g., data, voice, and video).

[0075] Figure 9Bis a block diagram of an environment in which tenant systems 1021 - 1023 and multi - tenant server 104 can be deployed. System 940 includes hardware (a group of one or more electronic devices) and software for providing service 942, which includes transaction queue 104A, tenant - level object 104B, network - level object 104C, and blockchain service 104D. System 940 is coupled to user electronic devices 980A - S via network 982. Service 942 can be an on - demand service that makes it available to one or more of users 984A - S who work for one or more other organizations (sometimes referred to as external users), such that these organizations do not have to concern themselves with building and / or maintaining the system, but instead use service 942 when needed (e.g., according to the demands of users 984A - S). Service 942 can communicate with each other and / or with one or more of user electronic devices 980A - S via one or more application programming interfaces (APIs) (e.g., Representational State Transfer (REST) APIs). User electronic devices 980A - S are operated by users 984A - S.

[0076] In one embodiment, system 940 is a multi - tenant cloud computing architecture that supports multiple services, such as customer relationship management (CRM) services (e.g., Sales Cloud sold by salesforce.com), contract / proposal / quote services (e.g., Salesforce CPQ sold by salesforce.com), customer support services (e.g., Service Cloud and Field Service Lightning sold by salesforce.com), marketing services (e.g., Marketing Cloud, Salesforce DMP, and Pardot sold by salesforce.com), commerce services (e.g., Commerce Cloud Digital, Commerce Cloud Order Management, and Commerce Cloud Store sold by salesforce.com), communication with external business data sources (e.g., Salesforce Connect sold by salesforce.com), productivity services (e.g., Quip sold by salesforce.com), data as a service (DAAS) (e.g., Database.com sold by salesforce.com TM )), platform as a service (PAAS) (e.g., execution runtimes and application development tools sold by salesforce.com, such as Heroku TM Enterprise, Thunder, and and Lightning), analytics services (such as Einstein Analytics, Sales Analytics, and / or Service Analytics sold by salesforce.com), community services (such as Community Cloud and Chatter sold by salesforce.com), Internet of Things (IoT) services (such as Salesforce IoT and IoT Cloud sold by salesforce.com), industry-specific services (such as Financial Services Cloud and Health Cloud sold by salesforce.com), and / or Infrastructure as a Service (IAAS) (such as virtual machines, servers, and / or storage). For example, system 940 may include an application platform 944 that enables PAAS to create, manage, and execute one or more applications developed by a provider of the application platform 944, users who access system 940 via one or more user electronic devices 980A-S, or third-party application developers who access system 940 via one or more user electronic devices 980A-S.

[0077] In some embodiments, one or more services 942 may utilize one or more multi-tenant databases 946 for tenant data 948 and a system data store 950 for system data 952 available to system 940. In certain embodiments, system 940 includes a group of one or more servers that run on server electronic devices and are configured to process requests for any authorized user associated with any tenant (users and / or tenants have no server affinity with a particular server). User electronic devices 980A-S communicate with the servers of system 940 to request and update tenant-level data and system-level data hosted by system 940, and in response, system 940 (such as one or more servers in system 940) may automatically generate one or more Structured Query Language (SQL) statements (such as one or more SQL queries) designed to access desired information from one or more multi-tenant databases 946 and / or the system data store 950.

[0078] In some embodiments, service 942 is implemented using virtual applications created at runtime in response to queries from user electronic devices 980A-S and based on metadata, including: 1) metadata describing constructs common to multiple tenants (e.g., forms, reports, workflows, user access rights, business logic); and / or 2) tenant-specific metadata describing tenant-specific constructs (e.g., tables, reports, dashboards, interfaces, etc.) and stored in a multi-tenant database. To this end, program code 960 can be a runtime engine that materializes application data from the metadata; that is, there is a clear separation between the compiled runtime engine (also referred to as the system kernel), tenant data, and metadata, which enables independent updates to the system kernel and tenant-specific application programs and architectures without the risk of actually affecting other application programs and architectures. Additionally, in one embodiment, application platform 944 includes an application settings mechanism that supports application developers in creating and managing applications, and application developers can save them as metadata through a save routine. Calls to these applications, including transaction queue 104A, tenant-level object 104B, network-level object 104C, and blockchain service 104D, can be encoded using a procedural language / structured object query language (PL / SOQL) that provides a programming language-style interface. A detailed description of some PL / SOQL language embodiments is discussed in U.S. Patent No. 7,730,478, titled "METHOD AND SYSTEM FOR ALLOWING ACCESS TO DEVELOPED APPLICATIONS VIA A MULTI-TENANT ON-DEMAND DATABASE SERVICE," commissioned by Craig Weissman on September 21, 2007. Calls to the application can be detected by one or more system processes that manage obtaining the application metadata of the tenant making the call and executing the metadata as an application within a software container (e.g., virtual machine).

[0079] Network 982 can be any one or any combination of a LAN (local area network), WAN (wide area network), telephone network, wireless network, peer-to-peer network, star network, token ring network, hub network, or other suitable configurations. The network can follow one or more network protocols, including Institute of Electrical and Electronics Engineers (IEEE) protocols, 3rd Generation Partnership Project (3GPP) protocols, or similar wired and / or wireless protocols, and can include one or more intermediate devices for routing data between system 940 and user electronic devices 980A-S.

[0080] Each user electronic device 980A-S (such as a desktop personal computer, a workstation, a laptop computer, a personal digital assistant (PDA), a smart phone, etc.) generally includes one or more user interface devices, such as a keyboard, a mouse, a trackball, a touchpad, a touch screen, a pen, etc., for interacting with pages, tables, applications, and other information provided by the system 940 in combination with a graphical user interface (GUI) provided on a display (such as a monitor screen, a liquid crystal display (LCD), etc.). For example, the user interface device can be used to access data and applications stored in the main memory of the system 940 and perform searches on the stored data, or otherwise allow the user 984 to interact with various GUI pages that can be presented to the user 984. The user electronic device 980A-S can communicate with the system 940 using TCP / IP (Transmission Control Protocol and Internet Protocol) and use other networking protocols at a higher network level for communication, such as the Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), Andrew File System (AFS), Wireless Application Protocol (WAP), File Transfer Protocol (FTP), Network File System (NFS), application programming interfaces (APIs) based on protocols such as Simple Object Access Protocol (SOAP), Representational State Transfer (REST), etc. In an example using HTTP, one or more user electronic devices 980A-S can include an HTTP client (commonly referred to as a "browser") for sending HTTP messages to and receiving HTTP messages from the server of the system 940, thereby allowing the user 984 of the user electronic device 980A-S to access, process, and view information, pages, and applications available to it from the system 940 via the network 982.

[0081] In the above description, in order to provide a more thorough understanding, many specific details are set forth, such as resource partitioning / sharing / copying implementations, types and interrelationships of system components, and logical partitioning / integration options. However, those skilled in the art should understand that the present invention can be practiced without these specific details. In other instances, control structures, logical implementations, operation codes, means for specifying operands, and complete software instruction sequences are not shown in detail because those of ordinary skill in the art will be able to practice the described content without undue experimentation from the included description.

[0082] References in the specification to "one embodiment", "exemplary embodiment", etc. indicate that the described embodiment may include a particular feature, structure, or characteristic, but each embodiment may not necessarily include that particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is considered within the knowledge of those skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments, whether or not explicitly described.

[0083] In this document, parenthetical text and blocks with dashed borders (such as large dashes, small dashes, dot-dashes, and dots) may be used to illustrate optional operations and / or structures for adding additional features to some embodiments. However, this notation should not be taken to mean that these are the only options or alternative operations, and / or that blocks with solid boundaries are not alternatives in some embodiments.

[0084] In the following description and claims, the term "coupled" and its derivatives may be used. "Coupled" is used to indicate that two or more elements can be in direct physical or electrical contact with each other, cooperate or interact with each other, or may not be in direct physical or electrical contact.

[0085] The operations in the flowcharts are described with reference to exemplary embodiments in other figures. However, the operations of the flowcharts may be performed by embodiments different from those discussed with reference to the other figures, and the embodiments discussed with reference to these other figures may perform operations different from those discussed with reference to the flowcharts.

[0086] Although the flowcharts in the figures illustrate a particular order of operations performed by certain embodiments, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0087] Although the above description includes several exemplary embodiments, those skilled in the art will recognize that the present invention is not limited to the described embodiments and can be implemented by modification and variation within the spirit and scope of the appended claims. Therefore, the description is illustrative rather than restrictive.

Claims

1. A method for managing data in a peer - to - peer blockchain network for a multi - tenant server, the method comprising: generating, by the multi - tenant server, an exchange object for the peer - to - peer blockchain network, wherein the exchange object includes a group of one or more exchange fields and a group of mappings between each exchange field of the group of one or more exchange fields and corresponding fields of at least (i) a first physical object associated with a first tenant in the peer - to - peer blockchain network and (ii) a second physical object associated with a second tenant in the peer - to - peer blockchain network; monitoring, by the multi - tenant server, one or more fields of the first physical object to determine when one or more conditions of a smart contract have been met; and in response to determining that the first physical object of the first tenant has met the one or more conditions of the smart contract, performing, by the multi - tenant server, one or more operations of the smart contract, wherein performing the one or more operations includes generating a transaction object having a group of one or more fields corresponding to the group of one or more exchange fields of the exchange object, such that the transaction object is made available to tenants of the peer - to - peer blockchain network to attempt to obtain consensus on proposed changes to a physical object associated with one of the tenants.

2. The method according to claim 1, further comprising: determining, by the multi - tenant server, consensus to add the smart contract to the peer - to - peer blockchain network.

3. The method according to claim 1, further comprising: in response to determining consensus on the smart contract in the peer - to - peer blockchain network, submitting, by the multi - tenant server, the smart contract to the peer - to - peer blockchain network, wherein submitting the smart contract to the peer - to - peer blockchain network includes adding a first set of blocks to the ledgers of all tenants in the peer - to - peer blockchain network, the all tenants including the first tenant, the second tenant, and the third tenant.

4. The method according to claim 1, further comprising: determining, by the multi - tenant server, consensus on a modification to the smart contract in the peer - to - peer blockchain network; and in response to determining consensus on the modification in the peer - to - peer blockchain network, submitting, by the multi - tenant server, the modification to the smart contract to the peer - to - peer blockchain network, wherein submitting the modification to the peer - to - peer blockchain network includes adding a second set of blocks to the ledgers of all tenants in the peer - to - peer blockchain network, the all tenants including the first tenant, the second tenant, and the third tenant.

5. The method according to claim 1, wherein the one or more operations are performed in relation to the second physical object.

6. The method according to claim 1, wherein the transaction object is generated on behalf of a second tenant in the peer - to - peer blockchain network, and wherein the one or more operations further include making the transaction object available to a third tenant in the peer - to - peer blockchain network on behalf of the second tenant to attempt to obtain consensus to change a third physical object corresponding to the third tenant based on data in the second physical object of the second tenant.

7. The method according to claim 6, wherein the transaction object includes the set of exchange fields and data values from the second physical object in the exchange fields corresponding to the mapping.

8. A non-transitory machine-readable storage medium storing instructions that, when executed by a processor, cause the processor to perform a set of operations, including: generating an exchange object for a peer-to-peer blockchain network, wherein the exchange object includes a set of one or more exchange fields and a set of mappings between each exchange field in the set of one or more exchange fields and corresponding fields of at least (i) a first physical object associated with a first tenant in the peer-to-peer blockchain network and (ii) a second physical object associated with a second tenant in the peer-to-peer blockchain network; monitoring one or more fields of the first physical object to determine when one or more conditions of a smart contract have been met; and in response to determining that the first physical object of the first tenant has met the one or more conditions of the smart contract, performing one or more operations of the smart contract, wherein performing the one or more operations includes generating a transaction object having a set of one or more fields corresponding to the set of one or more exchange fields of the exchange object, such that the transaction object is available to tenants of the peer-to-peer blockchain network to attempt to obtain consensus on a proposed change to a physical object associated with one of the tenants.

9. The non-transitory machine-readable storage medium according to claim 8, wherein the operations that the instructions cause the processor to perform further include: determining consensus to add the smart contract to the peer-to-peer blockchain network.

10. The non-transitory machine-readable storage medium according to claim 8, wherein the operations that the instructions cause the processor to perform further include: in response to determining consensus of the smart contract in the peer-to-peer blockchain network, submitting the smart contract to the peer-to-peer blockchain network, wherein submitting the smart contract to the peer-to-peer blockchain network includes adding a first set of blocks to the ledgers of all tenants in the peer-to-peer blockchain network, the all tenants including the first tenant, the second tenant, and the third tenant.

11. The non-transitory machine-readable storage medium according to claim 8, wherein the operations that the instructions cause the processor to perform further include: determining consensus on a modification to the smart contract in the peer-to-peer blockchain network; and in response to determining consensus of the modification in the peer-to-peer blockchain network, submitting the modification of the smart contract to the peer-to-peer blockchain network, wherein submitting the modification to the peer-to-peer blockchain network includes adding a second set of blocks to the ledgers of all tenants in the peer-to-peer blockchain network, the all tenants including the first tenant, the second tenant, and the third tenant.

12. The non-transitory machine-readable storage medium according to claim 8, wherein the one or more operations are performed in relation to the second physical object.

13. The non-transitory machine-readable storage medium according to claim 8, wherein a second tenant in the peer-to-peer blockchain network generates the transaction object, and wherein the one or more operations further include making the transaction object available to a third tenant in the peer-to-peer blockchain network on behalf of the second tenant to attempt to obtain a consensus to change a third physical object corresponding to the third tenant based on data in the second physical object of the second tenant.

14. The non-transitory machine-readable storage medium according to claim 13, wherein the transaction object includes the set of exchange fields and data values from the second physical object in the exchange fields corresponding to the mapping.

15. A multi-tenant server for managing data in a peer-to-peer blockchain network, the multi-tenant server comprising: a non-transitory machine-readable storage medium storing a blockchain service; and a processor coupled to the non-transitory machine-readable storage medium, the processor executing the blockchain service to: generate an exchange object for the peer-to-peer blockchain network, wherein the exchange object includes a set of one or more exchange fields and a set of mappings between each exchange field in the set of one or more exchange fields and corresponding fields of at least (i) a first physical object associated with a first tenant in the peer-to-peer blockchain network and (ii) a second physical object associated with a second tenant in the peer-to-peer blockchain network; monitor one or more fields of the first physical object to determine when one or more conditions of a smart contract have been met; and in response to determining that the first physical object of the first tenant has met the one or more conditions of the smart contract, perform one or more operations of the smart contract, wherein performing the one or more operations includes generating a transaction object having a set of one or more fields corresponding to the set of one or more exchange fields of the exchange object, making the transaction object available to tenants of the peer-to-peer blockchain network to attempt to obtain a consensus on a proposed change to a physical object associated with one of the tenants.

16. The multi-tenant server according to claim 15, wherein the blockchain service further determines a consensus to add the smart contract to the peer-to-peer blockchain network.

17. The multi-tenant server according to claim 15, wherein the blockchain service further submits the smart contract to the peer-to-peer blockchain network in response to determining a consensus of the smart contract in the peer-to-peer blockchain network, wherein submitting the smart contract to the peer-to-peer blockchain network includes adding a first set of blocks to the ledgers of all tenants in the peer-to-peer blockchain network, the all tenants including the first tenant, the second tenant, and the third tenant.

18. The multi-tenant server according to claim 15, wherein the one or more operations are performed in relation to the second physical object.

19. The multi-tenant server according to claim 15, wherein the transaction object is generated on behalf of a second tenant in the peer blockchain network, and wherein the blockchain service also makes the transaction object available to a third tenant in the peer blockchain network on behalf of the second tenant, to attempt to obtain consensus to change a third physical object corresponding to the third tenant based on data in the second physical object of the second tenant.

20. The multi-tenant server according to claim 19, wherein the transaction object includes the set of exchange fields and data values from the second physical object in the corresponding mapped exchange fields.

Images