Multi-tenant distributed ledger interfaces

A set of interfaces is described for implementing a blockchain network by a multi-tenant server, wherein the set of interfaces comprise an object mapping interface. The object mapping interface includes a set object function to designate a tenant object for use in the blockchain network based on an input object; a map function to map fields of the tenant object in a multi-tenant system managed by the multi-tenant server and fields of an exchange object used by the blockchain network based on an input set of field mappings; and a set owner function to set a tenant in the multi-tenant system as an owner of the mappings based on an input identifier.

TECHNICAL FIELD

One or more implementations relate to the field of data management; and more specifically, to use of a set of interfaces in a centralized implementation of a peer-to-peer blockchain network.

BACKGROUND

A blockchain is a continuously expanding list of records/blocks that are linked and secured using cryptography. In particular, every block in a blockchain may include a cryptographic hash of the immediately preceding block, a timestamp for the current block, and transaction data (e.g., the addition/modification of information associated with a peer in a blockchain network). Further, the blockchain may be shared and managed through a peer-to-peer network via a system of verifying/validating new blocks to be added to the chain such that a block in a blockchain cannot be altered without alteration of all subsequent blocks, which requires network consensus. This architecture allows for security of information stored within blocks through the use of cryptography; sharing/distribution of information through the use of peer-to-peer networks; trust through the use of consensus of block addition; and immutability of information stored within blocks through the use of cryptography, chaining/linking of blocks, and peer distribution (e.g., each peer in the blockchain network may maintain a ledger of all verified/validated transactions in the network).

In contrast to a blockchain architecture, a multi-tenant cloud architecture relies on centralization of information in a common database or other data structure. Although cloud-based architectures provide many benefits in comparison to blockchain architectures, including the ability to remove many management functions from tenants and instead focus these functions on a centralized system, these architectures do not provide the same level of security, trust, and immutability of information during inter-tenant communications of data.

Conventional blockchain networks are configured for specific types of transactions. Most notably, some blockchain networks are configured for coin transactions (sometimes referred to as “currency” or “token” transactions). Accordingly, data structures and objects are specially configured for these types of transactions. Since all data structures and objects, including associated functions and variables, are configured for a specific type of transaction, these blockchain networks cannot be easily extended to other types of transactions. For example, blockchain networks involving coin transactions cannot be easily extended to data transactions (e.g., data transaction related to medical records) as all data structures and objects are configured for coin transactions.

Moreover, blockchain networks are not configured for multi-tenant systems and instead operate in a distributed infrastructure. Adapting these blockchain networks for multi-tenant systems is difficult as all data structures/objects are configured for distributed infrastructures.

DETAILED DESCRIPTION

FIG.1is a block diagram illustrating a computing environment100, according to one example implementation. The computing environment100includes tenant systems1021-1023, a multi-tenant server104, and a set of communications networks106. In this example computing environment100, the tenant systems1021-1023may be part of a peer-to-peer blockchain network108and the multi-tenant server104provides a cloud environment to manage data and transactions of the tenant systems1021-1023in the peer-to-peer blockchain network108via a transaction queue104A, tenant level objects104B, network level objects104C, blockchain services104D, and blockchain interfaces104E. In particular, the multi-tenant server104provides blockchain interfaces104E that may be used for configuring the peer-to-peer blockchain network108to operate using various types of data and/or transactions (e.g., transactions involving tokens (sometimes referred to as “coins” or “currency”) or medical records).

As will be described herein, the tenant systems1021-1023are part of a multi-tenant environment/system that is managed by the multi-tenant server104. For example, the multi-tenant server104may manage a multi-tenant database management system (DBMS) in which the users/tenants associated with the tenant systems1021-1023are able to store and/or retrieve data. A multi-tenant DBMS refers to those systems in which various elements of hardware and software of the DBMS may be shared by one or more tenants (e.g., the tenant systems1021-1023). For example, a given server (e.g., the multi-tenant server104) may simultaneously process requests for a great number of tenants, and a given database table may store records for a potentially much greater number of tenants. In addition to managing a multi-tenant environment/system for the tenant systems1021-1023, as noted above, the multi-tenant server104may also manage the peer-to-peer blockchain network108on behalf of the tenant systems1021-1023. Although shown with three tenant systems102(e.g., the tenant systems1021-1023), the peer-to-peer blockchain network108may include any number of tenant systems102. In some embodiments, the peer-to-peer blockchain network108may be viewed as a distributed network that is controlled by the multi-tenant server104with inputs/requests from the tenant systems102.

In some implementations, a transaction generator110of a tenant system102may generate a request to (1) add a new record to a physical object associated with the tenant system102or (2) modify an existing record of the physical object associated with the tenant system102. The physical object may include a set of fields for each record and is stored in a portion/partition of the tenant level objects104B of the multi-tenant server104associated with the corresponding tenant system102such that the physical object is only accessible to the tenant system102(e.g., the tenant systems1022and1023are not permitted to read or write to the physical object of the tenant system1021). The request may cause the addition of a record in a shadow object in the portion/partition of the tenant level objects104B associated with the tenant system102. The shadow object represents uncommitted data to the physical object (i.e., data for which a consensus amongst the peers in the peer-to-peer blockchain network108has not yet been achieved). The shadow object may be used by the transaction queue104A for generating a transaction object, which will be distributed/made available to the other tenant systems102for receiving consensus for the proposed addition/modification to the physical object of the tenant system102.

In one implementation, the set of fields of the transaction object is a subset of the fields of physical objects and the set of fields of the transaction object are defined by an exchange object, which is included in the network level objects104C. In this implementation, the exchange object may include a set of exchange fields, which will be included in the transaction object, and each exchange field of the exchange object is mapped to a field in the physical objects of the tenant systems102. For example, a physical object of the tenant system1021may include fields A-D, a physical object of the tenant system1022may include fields E-H, and a physical object of the tenant system1023may include fields I-K. In this example, a first exchange field of the exchange object of the peer-to-peer blockchain network108may be mapped to the field B of the tenant system1021, the field F of the tenant system1022, and the field I of the tenant system1023. Similarly, a second exchange field of the exchange object of the peer-to-peer blockchain network108may be mapped to the field C of the tenant system1021, the field E of the tenant system1022, and the field J of the tenant system1023. Accordingly, when a proposal for adding/modifying a record for the physical object of the tenant system1021is received, the corresponding transaction object includes the first exchange field with a value from field B of the proposed record in the physical/shadow object and the second exchange field with a value from field C of the proposed record in the physical/shadow object. The exchange object provides a uniform transaction object for verification/validation purposes in the peer-to-peer blockchain network108while allowing the tenant system1021to only reveal particular portions of information to other tenants/peers in the peer-to-peer blockchain network108(e.g., sensitive information/fields in physical objects may not be included in transaction objects which are distributed amongst tenant systems1021-1023in the peer-to-peer blockchain network108and later included in distributed ledgers).

As described herein, the multi-tenant server104may perform many of the functions of the peer-to-peer blockchain network108on behalf of the tenant systems102. In particular, the multi-tenant server104may include a virtual space/organization for each of the tenant systems102. Each virtual space/organization may include data and applications/services for corresponding tenant systems102and is logically separate from all other virtual spaces/organizations of other tenant systems102. For example, each virtual space/organization may include tenant level objects104B corresponding to respective tenants/tenant systems102and separate instantiations of or access to blockchain services104D. In this configuration/architecture, the virtual space/organization for each tenant system102may perform one or more blockchain functions/operations on behalf of the corresponding tenant system102. For example, in response to receipt of a request from the tenant system1021to add a new record to or modify an existing record of a physical object of the tenant system1021, the multi-tenant server104may generate a shadow object record in the virtual space/organization of the tenant system1021within the multi-tenant server104. In response, the transaction queue104A may generate a transaction object corresponding to the record in the shadow object using the exchange object of the peer-to-peer blockchain network108and a set of cryptographic keys of the tenant system1021such that the transaction object may be distributed or otherwise be made available to virtual spaces/organizations of the other tenant systems1022and1023. The virtual spaces/organizations of the other tenant systems1022and1023may thereafter analyze the transaction object to determine whether validation/verification is appropriate.

The transaction queue104A may wait for validation/verification from the virtual spaces/organizations of the tenant systems1022and1023such that consensus for the proposed alteration to the physical object of the tenant system1021is achieved. In response to this consensus, a virtual space/organization of a leader tenant system102may (1) add a record or modify a record (as appropriate) in a corresponding physical object of this leader tenant system102and (2) add a corresponding entry/block to a distributed ledger of this leader tenant system102. Thereafter, the virtual space/organization of a leader tenant system102may transmit a request to the virtual spaces/organizations of the other/remaining tenant systems102to commit the change to their physical objects (based on a mapping defined in the exchange object) and/or add a corresponding entry/block to a ledger of these other/remaining tenant systems102.

As illustrated above and as will be described in greater detail below, the cloud environment/system provided by the multi-tenant server104(e.g., the virtual spaces/organizations provided by the multi-tenant server104) may be used for managing blockchain transactions between the tenant systems1021-1023. Accordingly, the cloud environment/system implemented by the multi-tenant server104provides the same level of security, trust, and immutability of information as a blockchain network during inter-tenant communications while centralizing functionality/operations of the peer-to-peer blockchain network108. Further, the computing environment100, including the multi-tenant server104, implements the peer-to-peer blockchain network108to allow use of smart contract as described herein.

As will be described in greater detail below, the multi-tenant server104may include blockchain interfaces104E that may be used by an administrator for configuring the peer-to-peer blockchain network108. As used herein, an interface defines a set of functions and/or variables that must be included in any class or object that implements this interface. Although the inclusion of these functions and variables are dictated by the interface, the implementation/use is not controlled by the interface. For example, an interface in the blockchain interfaces104E may include a transaction message interface for facilitating a transaction message in a blockchain network. The transaction message interface may include (1) an initiating address function for setting an initiating address of a transaction message; (2) a target address function for setting a target address of the transaction message; and (3) an object selection function for selecting an object for use by the transaction message. Accordingly, the example transaction message interface indicates three functions that are required to be present in an implementing class or object, including names, types, and inputs to these three functions, but leaves the implementations open to the administrator of the blockchain network.

Each element of the computing environment100ofFIG.1will now be described in greater detail below by way of example. In some implementations, the computing environment100may include more elements than those shown inFIG.1. Accordingly, the computing environment100ofFIG.1is purely for illustrative purposes.

As shown inFIG.1and described above, the tenant systems1021-1023and the multi-tenant server104may be connected through a set of one or more communication networks106. The set of one or more communication networks106may 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 such networks. In another implementation, the tenant systems1021-1023and the multi-tenant server104may maintain a direct connection to each other via a wired or wireless medium.

Each of the tenant systems1021-1023may be a computing system that may be operated by one or more users. For example, each of the tenant systems1021-1023may be a personal computer (PC), a workstation, a laptop computer, a tablet computer, a mobile phone, a smartphone, a personal digital assistant (PDA), or the like. As will be described in greater detail below, the tenant systems1021-1023may communicate with the multi-tenant server104to modify/add/store and retrieve data.

The tenant systems1021-1023(sometimes referred to as client, peer, or user systems) may each include a screen/display (e.g., a liquid crystal (LCD) display) for presenting an interface (e.g., a graphical user interface (GUI)) to a user, including an interface presented in a web page. As will be described in greater detail below, each of the tenant systems1021-1023may include a corresponding transaction generator110for receiving input from a user (e.g., via a user interface) to alter a physical object (e.g., addition of a new record in the physical object or modification of an existing record in the physical object) or adding/updating a smart contract in the peer-to-peer blockchain network.

The tenant systems1021-1023may each be associated with one or more organizations/tenants that are managed by the multi-tenant server104. For example, users of the tenant system1021may be customers of a first organization/tenant and a user of the tenant system1022may be a customer of a second organization/tenant. Organizations/tenants may be any firm, corporation, institution, association, or society that has contracted with an administrator of the multi-tenant server104to provide users access to data stored therein via the tenant systems1021-1023.

In one implementation, the multi-tenant server104may be any computing device that provides users access to resources via the tenant systems102and the communication network(s)106. For example, the multi-tenant server104may provide users of the tenant systems1021-1023access to data in one or more physical objects and/or one or more corresponding distributed peer ledgers that describe changes to the physical objects. For instance, a physical object of the tenant system1021may correspond to a medical lab report. In this example implementation, the records in the physical object may include a lab report identifier field, a patient name field, a lab network identifier field, a lab test identifier field, a patient identifier field, a social security number field, and a distribution field, which indicates when a patient has authorized the sharing/distribution of medical records of the patient in the peer-to-peer blockchain network108. When an alteration/change is desired to a physical object of a system102(e.g., addition of a new record to a physical object or modification of an existing record in a physical object), the multi-tenant server104uses the transaction queue104A, the tenant level objects104B, the network level objects104C, and the blockchain services104D to attempt to make these alterations in the peer-to-peer blockchain network108(e.g., alterations reflected in physical objects and distributed ledgers associated with the tenant systems102).

The multi-tenant server104may include various elements of hardware and software of a multi-tenant system. As used herein, the term “multi-tenant system” refers to those systems in which various elements of hardware and software may be shared by one or more tenants. For example, the multi-tenant server104may simultaneously process requests for a great number of tenants, and a given database table may store records for a potentially much greater number of tenants. The multi-tenant server104may include an application platform including a framework (e.g., services and metadata) that allows applications to execute, such as the hardware or software infrastructure of the system. In one implementation, the multi-tenant server104includes separate virtual spaces/organizations (sometimes referred to as portions or partitions) for data/objects as well as services of each tenant systems1021-1023. For example, each tenant system1021-1023may be assigned a separate virtual space/organization. Each virtual space/organization is a logical partition within the multi-tenant server104and includes separate tenant level objects104B that are only accessible to that tenant system102and are inaccessible to other tenant systems102(e.g., tenant systems102cannot read and/or write tenant level objects104B of another tenant system102) in addition to services used by the multi-tenant server104on behalf of the corresponding tenant system102(e.g., blockchain services104D).

As noted above, the blockchain interfaces104E are a set of interfaces (i.e., a set of definitions/templates) for implementation by objects in a blockchain network108. The blockchain interfaces104E (1) allow for the use of various types of data and transactions in the peer-to-peer blockchain network108and/or (2) facilitate the use of the multi-tenant server104for management of the peer-to-peer blockchain network108. Accordingly, an administrator of the peer-to-peer blockchain network108may utilize the blockchain interfaces104E to configure the peer-to-peer blockchain network108for a variety of different data and transaction types that are facilitated by the multi-tenant server104.

FIG.2shows an object mapping interface200, according to one example implementation. As shown inFIG.2, the object mapping interface200(i.e., interface ObjectMapping) includes a setObject function, which takes an object value as an input parameter. In some implementations, the setObject function may set/designate an object associated with a tenant/tenant system102(e.g., a physical object associated with a tenant/tenant system102) for use in the peer-to-peer blockchain network108. The object mapping interface200may also include a complementary getObject function which returns the object originally set by the setObject function.

As also shown inFIG.2, the object mapping interface200may include a setFieldMapping function, which takes an identifier (ID) value of a tenant/tenant system102(i.e., Id tenant) and a set of fields for a field mapping (i.e., Map<String, String> fieldMapping) as a set of input parameters. In particular, one of the fields in the set of fields corresponds to a field of a physical object of a tenant/tenant system102and a second field in the set of fields corresponds to an exchange field of an exchange object of the peer-to-peer blockchain network108. Accordingly, the setFieldMapping function may be used for indicating mappings between fields of a tenant/tenant system102physical object, which was set/designated by the setObject, and exchange fields of an exchange object associated with the peer-to-peer blockchain network108. For example,FIG.3shows an exchange object302and corresponding mappings between fields3061-3069of physical objects of tenants/tenant systems102and exchange fields3041-3043that may be established using the setFieldMapping function. In this representation, each exchange field304is mapped to a single field306of a tenant/tenant system102. Accordingly, each of the fields3061-3063correspond to separate physical objects and tenants/tenant systems102, each of the fields3064-3066correspond to separate physical objects and tenants/tenant systems102, and each of the fields3067-3069correspond to separate physical objects and tenants/tenant systems102. The object mapping interface200may include a complementary getFieldMapping function that takes in an identifier value of a tenant/tenant system102as an input parameter (i.e., Id tenant) and returns fields mappings set/designated by the setFieldMapping function (i.e., Map<String, String>).

In some implementations, the object mapping interface200may correspond to an owner. For example, the setOwner function may take in an owner identifier (i.e., Id owner) as a parameter that indicates a system or party in the computing environment100that owns the field mapping set by the setFieldMapping function. For example, the field mapping may be owned by a tenant system102or a network organization that is separate from the tenant systems102and is tasked with configuring the peer-to-peer blockchain network108. The object mapping interface200may include a complementary getOwner function that returns the identifier of the owner set by the setOwner function.

The blockchain interfaces104E may additionally include a transaction message interface for facilitating a transaction in the peer-to-peer blockchain network108. For example,FIG.4shows a transaction message interface400(i.e., interface TransactionMessage), according to one example implementation. As shown inFIG.4, the transaction message interface400may include a setId function that takes in string value as an input parameter (i.e., String name), which indicates an identifier for a corresponding transaction message. The transaction message interface400may include a complementary getId function for returning a string value of a corresponding identifier of a transaction message, which was originally set by the setId function.

As shown inFIG.4, the transaction message interface400may also include a setFromAddress function and a setToAddress function, which each take a DigitalAddress value as an input parameter. For example, the setFromAddress function takes DigitalAddress fromAddress as an input parameter, which indicates an address of a recipient/target party, and the setToAddress function takes DigitalAddress toAddress as an input parameter, which indicates an address of an originating party. The transaction message interface400may also include complementary getFromAddress and getToAddress functions, which return DigitalAddress values of a recipient/target party and an originating party, respectively.

In some implementations, a digital address of a target or originator of a transaction may not be known (e.g., a DigitalAddress of a target or originator). Instead, another identifier of the target or originator may be known. In these implementations, the transaction message interface400may include setFromId and setToId functions that each take in an identifier (ID) value as an input parameter (i.e., Id id). When implemented, the setFromId and setToId functions may determine a digital address of a target or originator, respectively, of a transaction (e.g., a DigitalAddress of a target or originator) and set the digital address accordingly.

In some implementations, transactions may involve various parties in the multi-tenant system/environment implemented by the multi-tenant server104. For example, the parties may include one or more of tenants, tenant systems, users, accounts, networks, and contacts. In these implementations, the setFromId and setToId functions may include a identifier level (IdLevel) value as an additional input parameter (i.e., IdLevel idLevel). The IdLevel may be an enumerated value for parties in the multi-tenant system/environment implemented by the multi-tenant server104.FIG.5shows an enumerated IdLevel500, according to one example implementation. As shown, the IdLevel500includes the enumerated values of NETWORK, TENANT, USER, ACCOUNT, and CONTACT, which correspond to various parties in the multi-tenant system/environment implemented by the multi-tenant server104. Accordingly, IdLevel values may be used by the setFromId and setToId functions to indicate a type of identifier value (i.e., Id id) such that an appropriate digital address may be determined.

As shown inFIG.4, the transaction message interface400may also include a setObjectMapping function, which takes an ObjectMapping value as an input parameter, which indicates an ObjectMapping that is used for the transaction. For example, the ObjectMapping value may correspond to an object/class implemented using the object mapping interface200. The transaction message interface400may also include complementary getObjectMapping, which returns an ObjectMapping value for the corresponding transaction.

The blockchain interfaces104E may additionally include a transaction interface for further facilitating a transaction in the peer-to-peer blockchain network108. For example,FIG.6shows a transaction interface600(i.e., interface Transaction), according to one example implementation. As shown inFIG.6, the transaction interface600may include a setId function that takes in a string value as an input parameter (e.g., String name), which indicates an identifier for a corresponding transaction. The transaction interface600may include a complementary getId function for returning a string identifier of a corresponding transaction, which was originally set by the setId function.

As shown inFIG.6, the transaction interface600may include a setTransactionMessage function that takes a transaction message400as an input parameter (i.e., TransactionMessage transactionMessage). When implemented, the setTransactionMessage function sets the transaction message400used by the corresponding transaction to the transaction message input parameter. The transaction interface600may include a complementary getTransactionMessage function that returns a transaction message400(i.e., TransactionMessage) for the corresponding transaction.

As also shown inFIG.6, the transaction interface600may include a setTransactionType function that takes a transaction type as an input parameter (e.g., TransactionType transactionType). When implemented, the setTransactionType function sets the type of the transaction message400used by the corresponding transaction to the transaction type input parameter. For example,FIG.7shows an enumerated transaction type object700(i.e., TransactionType), according to one example implementation. As shown, the enumerated values for the enumerated transaction type object700may have the values TRANSFER, APPROVE, CONSENT, SHARE_OWNERSHIP, QUERY, BALANCE_OF, and ALLOWANCE, which corresponds to the various types of transactions that may be made/used in the peer-to-peer blockchain network108. The transaction interface600may include a complementary getTransactionType function that returns a transaction type object700(e.g., TransactionType) for the corresponding transaction.

The blockchain interfaces104E may additionally include a contract interface for facilitating contracts (sometimes referred to as “smart contracts”) in the peer-to-peer blockchain network108. For example,FIG.8shows a contract interface800(i.e., interface Contract), according to one example implementation. As shown inFIG.8, the contract interface800may include an action function that takes in a Transaction600as an input parameter (e.g., Transaction transaction) and returns a Boolean value. In one implementation, the action function indicates whether a set of conditions have been met based on the Transaction600input parameter. The contract interface800may also include a runRules function that takes a set of rules (e.g., Set<rules>) as an input parameter. The set of rules may be performed/run in response to the action function indicating that a corresponding set of conditions have be met in relation to a Transaction600.

The above described interfaces allow use of various types of data and corresponding transactions in a peer-to-peer blockchain network108. In particular, the object mapping interface200allows the selection/setting and use of any type of object. However, interfaces may be provided in the blockchain interfaces104E for specific types of data and corresponding transactions. For example,FIG.9shows a token interface900, according to one example implementation. Similar to the object mapping interface200, the token interface900includes a set of functions for implementation. As shown inFIG.9, the token interface900includes a setName function that takes in a string variable (i.e., String name) as an input parameter. The setName function may be used for setting the name of a token currency that will be used by the peer-to-peer blockchain network108. The token interface900make include a complementary getName function for returning a string value of the name set by the setName function.

As also shown inFIG.9, the token interface900may include a setDecimalLimit function that takes an integer value as an input parameter (e.g., int numberOfDecimals). The integer value indicates the number of places to the right of the decimal place that are tracked for a designated token/currency. For example, a token object implementing the token interface900may track two places to the right of the decimal point as set by the setDecimalLimit function. The token interface900may include a complementary getDecimalLimit function for returning an integer value of the number of decimal places set by the setDecimalLimit function.

As additionally shown inFIG.9, the token interface900may include a setExchangeRate function that takes a currency value as an input parameter (i.e., Currency rate). The currency value indicates the exchange rate between the token object implementing the token interface900and another token/currency. For example, the setExchangeRate function may indicate that a single token is equivalent to two U.S. Dollars. The token interface900may include a complementary getExchangeRate function for returning a currency value set by the setExchangeRate function.

As finally shown inFIG.9, the token interface900may include a setFounder function that takes in an identifier (Id) value as an input parameter (e.g., Id id). The identifier value indicates the owner or administrator of the token object that implements the token interface900. For example, a tenant or tenant system102may be set by the setFounder setExchangeRate as the owner/founder of the token object that implements the token interface900. The token interface900make include a complementary getFounder function for returning an identifier of the owner/founder of the token object that implements the token interface900.

Based on the use of the token interface900, other interfaces may be provided in the blockchain interfaces900to accommodate token transactions. For example,FIG.10shows a token transaction message interface1000(e.g., interface TokenTransactionMessage) that extends the transaction message interface400ofFIG.4. As shown, the token transaction message interface1000includes a setTokens function that takes a double value as an input parameter (e.g., Double tokens). The setTokens function sets the number of tokens that are distributable in the peer-to-peer blockchain network108. The token transaction message interface1000may also include a complementary getTokens function, which returns a double value corresponding to the number of tokens that are distributable in the peer-to-peer blockchain network108.

As also shown inFIG.10, the token transaction message interface1000may include a setTokenPercent function that takes a double value as an input parameter (e.g., Double percent). The token transaction message interface1000may additionally include a complementary getTokenPercent function, which returns a double value of the percent.

Similar to the extension of the transaction message interface400for use with tokens, the contract interface800may be extended for purposes of token-based contracts. For instance,FIG.11shows a token contract interface1100(e.g., interface TokenContract) that extends the contract interface800, according to one example implementation. Since the token contract interface1100is used with token transactions, the token contract interface1100may include an action function which takes a TokenTransactionMessage object as an input parameter and returns a Boolean value. Similar to the action function of the contract interface800, the action function of the token contract interface1100indicates whether a set of conditions have been met based on the TokenTransactionMessage object input parameter.

On the basis of the token contract interface1100, a token contract may be implemented. For instance,FIG.12shows a token contract1200for company A (i.e., class CompanyATokenContract) that is implemented based on the token contract interface1100, according to one example implementation. In the token contract1200ofFIG.12, the action function and the runRules function are implemented by an administrator of the peer-to-peer blockchain network108or a representative of Company A.

In some implementations, the blockchain interfaces104E may include a membership interface to create and manager consortiums. For instance,FIG.13shows a network service interface1300, according to one example implementation. As shown inFIG.13, the network service interface1300may include functions for initializing a consortium. For example, the network service interface1300may include an initialize function that takes a set of addresses corresponding to initial members of the consortium (e.g., Boolean initializeConsortium(List<DigitalAddress> memberAddresses)) and an initialize function that takes an organization identifier corresponding to initial members of the consortium (e.g., Boolean initializeConsortium(List<Id> orgIds)). As shown inFIG.13, the network service interface1300may also include functions for adding members to an initialized consortium. For example, the network service interface1300may include an add member function that takes a set of addresses corresponding to new members of the consortium (e.g., Boolean addMemberToConsortium(DigitalAddress memberAddress)) and an add member that takes an organization identifier corresponding to new members of the consortium (e.g., Boolean addMemberToConsortium(Id orgId)). As shown inFIG.13, the network service interface1300may also include functions for getting/indicating/listing members of a consortium. For example, the network service interface1300may include a get consortium members function that outputs addresses of members in the consortium (e.g., List<DigitalAddress> getConsortiumMembersByAddress( )) and a get consortium members function that outputs organization identifiers of members in the consortium (e.g., List<ID> getConsortiumMembersByOrgId( )).

Based on the interfaces described above, which may be included in the blockchain interfaces104E, the peer-to-peer blockchain network108may be configured for various different data types and corresponding transactions. In particular, the blockchain interfaces104E (1) allow for the use of various types of data and transactions in the peer-to-peer blockchain network108and/or (2) facilitate the use of the multi-tenant server104for management of the peer-to-peer blockchain network108. Accordingly, an administrator of the peer-to-peer blockchain network108may utilize the blockchain interfaces104E to configure the peer-to-peer blockchain network108for a variety of different data and transaction types that are facilitated by the multi-tenant server104.

Turning now toFIG.14, a method1400according to some implementations will be described for the multi-tenant server104to manage data in the peer-to-peer blockchain network108. In particular, the blockchain interfaces104E may be used for configuring and performing transactions in the peer-to-peer blockchain network108.

The operations of the method1400may be performed by one or more components of the example computing environment100shown inFIG.1. However, in other implementations, the method1400may operate in other environments, including different implementations of the multi-tenant server104.

As noted above, the operations in the flow diagram ofFIG.14will be described with reference to the exemplary implementations of the other figures. However, it should be understood that the operations of the flow diagram can be performed by implementations other than those discussed with reference to the other figures, and the implementations discussed with reference to these other figures can perform operations different than those discussed with reference to the flow diagrams.

Although described and shown inFIG.14in a particular order, the operations of the method1400are not restricted to this order. For example, one or more of the operations of the method1400may be performed in a different order or in partially or fully overlapping time periods. Accordingly, the description and depiction of the method1400is for illustrative purposes and is not intended to restrict to a particular implementation.

As shown inFIG.14, the method1400may commence at operation1402with the multi-tenant server104implementing the object mapping interface200for establishing mappings between fields of physical objects of tenants/tenant systems102and exchange fields of an exchange object in the peer-to-peer blockchain network108. For example, a mapping class may implement the object mapping interface200, including one or more of the set object function (e.g., setObject(Object object)), the get object function (e.g., getObject( )), set field mapping function (e.g., setFieldMapping(Id tenant, Map<String, String> fieldMapping)), the get field mapping function (e.g., getFieldMapping(Id tenant)), set owner function (e.g., setOwner(Id owner)), and get owner function (e.g., getOwner( )). For instance, implementing the object mapping interface200may include implementing (1) the set object function such that the set object function designates an object of a tenant/tenant system102(e.g., a physical object of a tenant/tenant system102)) for use in the peer-to-peer blockchain network108, (2) the set field mapping function to map fields in the set/designated tenant object and fields of an exchange object302used by the peer-to-peer blockchain network108, and (3) a set owner function to set a tenant/tenant system102as an owner of the mappings. Implementing, as used herein, includes generating and providing logic defined by code (e.g., C/C++, Java, Apex, etc.) to perform operations of an associated function, object, and/or class.

At operation1404, the multi-tenant server104implements the transaction message interface400based on a mapping object. For example, a transaction message class may implement the transaction message interface400, including one or more of the set identifier function (e.g., setId(String name)), the get identifier function (e.g., getId( )), the set from address function (e.g., setFromAddress(DigitalAddress fromAddress)), the get from address function (e.g., getFromAddress( )), the set to address function (e.g., setToAddress(DigitalAddress toAddress)), the get to address function (e.g., getToAddress( )), the set from identifier function (e.g., setFromId(Id id, IMDLIdLevel idLevel)), the get from identifier function (e.g., getFromId( )), the set to identifier (e.g., setToId(Id id, IMDLIdLevel idLevel)), the get to identifier function (e.g., getToId( )), the set object mapping function (e.g., setObjectMapping ObjectMapping objectMapping)), and the get object mapping function (e.g., ObjectMapping getObjectMapping( )). For instance, implementing the transaction message interface400may include implementing (1) an initiating address function (e.g., the set from address function or the set from identifier function) to set an initiating address of a transaction/transaction message object, (2) a target address function (e.g., the set to address function or the set to identifier function) to set a target address of the transaction/transaction message object, and (3) a set object mapping function to select an object mapping object for use in the transaction/transaction message object.

At operation1406, the multi-tenant server104implements the transaction interface600based on a transaction message object. For example, a transaction class may implement the transaction interface600, including one or more of the set identifier function (e.g., setId(String name)), the get identifier function (e.g., getId( )), the set transaction message function (e.g., getTransactionMessage(TransactionMessage transactionMessage)), the get transaction message function (e.g., getTransactionMessage( )), the set transaction type function (e.g., setTransactionType(TransactionType TransactionType)), and the get transaction type function (e.g., TransactionType getTransactionType( )). For instance, implementing the transaction interface600may include implementing (1) the set transaction message function to set a transaction message object for use in the transaction and (2) the set transaction type function to set a type of the transaction from a set of transaction types (e.g., a transfer of a record, approval of a change to an object, sharing ownership of a record, and a query).

At operation1408, the multi-tenant server104implements the contract interface800based on a transaction object. For example, a contract class may implement the contract interface800, including one or more of an action function (e.g., action(Transaction transaction)) to indicate a set of actions to be performed based on the transaction object in response to performance of the contract object and a rules function (e.g., runRules(Set<rules>)) to indicate a set of rules, wherein the set of actions are performed in response to the set of rules being met based on the transaction object.

At operation1410, the multi-tenant server104may perform a transaction on behalf of a party in the peer-to-peer blockchain network108(e.g., a tenant system102) using the implemented object mapping interface200, transaction message interface400, transaction interface600, and/or contract interface800(e.g., using the mapping class, transaction message class, transaction class, and/or contract class). For example, the multi-tenant server104may use functions of an object/class implementing the object mapping interface200to (1) set/select objects of parties in the peer-to-peer blockchain network108, (2) set mappings between fields of the objects and an exchange object, and/or (3) set an owner of the mapping. The multi-tenant server104may thereafter use functions of an object/class implementing the transaction message interface400to (1) set an address of a target/destination party for the transaction, (2) set an address of an originating party for the transaction, and (3) set/select an object defining mappings used by the transaction (e.g., a mapping object implementing the object mapping interface200). The multi-tenant server104may thereafter use functions of an object/class implementing the transaction interface600to (1) set/select a transaction object (e.g., a transaction object implementing the transaction message interface400) and/or (2) set/select a transaction type for the transaction. Optionally, the multi-tenant server104may thereafter use functions of an object/class implementing the contract interface800to establish a smart contract.

As used above, the term “user” is a generic term referring to an entity (e.g., an individual person) using a system and/or service. A multi-tenant architecture provides each tenant with a dedicated share of a software instance and the ability (typically) to input tenant specific data for user management, tenant-specific functionality, configuration, customizations, non-functional properties, associated applications, etc. Multi-tenancy contrasts with multi-instance architectures, where separate software instances operate on behalf of different tenants. A tenant includes a group of users who share a common access with specific privileges to a software instance providing a service. A tenant may be an organization (e.g., a company, department within a company, etc.). A tenant may have one or more roles relative to a system and/or service. For example, in the context of a customer relationship management (CRM) system or service, a tenant may be a vendor using the CRM system or service to manage information the tenant has regarding one or more customers of the vendor. As another example, in the context of Data as a Service (DAAS), one set of tenants may be vendors providing data and another set of tenants may be customers of different ones or all of the vendors' data. As another example, in the context of Platform as a Service (PAAS), one set of tenants may be third party application developers providing applications/services and another set of tenants may be customers of different ones or all of the third-party application developers. A user may have one or more roles relative to a system and/or service. To provide some examples, a user may be a representative (sometimes referred to as an “end user”) of a tenant (e.g., a vendor or customer), a representative (e.g., an administrator) of the company providing the system and/or service, and/or a representative (e.g., a programmer) of a third-party application developer that is creating and maintaining an application(s) on a Platform as a Service (PAAS).

One or more parts of the above implementations 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 set 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 drives (SSDs)) to store code (which is composed of software instructions and which is sometimes referred to as computer program code or a computer program) for execution on the set of processors and/or to store data. For instance, an electronic device may include non-volatile memory (with slower read/write times, e.g., magnetic disks, optical disks, read only memory (ROM), Flash memory, phase change memory, SSDs) and volatile memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)), where the non-volatile memory persists code/data even when the electronic device is turned off or when power is otherwise removed, and the electronic device copies that part of the code that is to be executed by the set of processors of that electronic device from the non-volatile memory into the volatile memory of that electronic device during operation because volatile memory typically has faster read/write times. As another example, an electronic device may include a non-volatile memory (e.g., phase change memory) that persists code/data when the electronic device is turned off, and that has sufficiently fast read/write times such that, rather than copying the part of the code/data to be executed into volatile memory, the code/data may be provided directly to the set of processors (e.g., loaded into a cache of the set of processors); in other words, this non-volatile memory operates as both long term storage and main memory, and thus the electronic device may have no or only a small amount of volatile memory for main memory. In addition to storing code and/or data on machine-readable storage media, typical electronic devices can transmit code and/or data over one or more machine-readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustical or other form of propagated signals—such as carrier waves, infrared signals). For instance, typical electronic devices also include a set of one or more physical network interface(s) to establish network connections (to transmit and/or receive code and/or data using propagating signals) with other electronic devices. Thus, an electronic device may store and transmit (internally and/or with other electronic devices over a network) code and/or data with one or more machine-readable media (also referred to as computer-readable media).

Electronic devices are used for a variety of purposes. For example, an electronic device (sometimes referred to as a server electronic device) may execute code that cause it to operate as one or more servers used to provide a service to another electronic device(s) (sometimes referred to as a client electronic device, a client computing device, or a client device) that executes client software (sometimes referred to as client code or a tenant system) to communicate with the service. The server and client electronic devices may be operated by users respectively in the roles of administrator (also known as an administrative user) and end user.

FIG.15Ais a block diagram illustrating an electronic device1500according to some example implementations.FIG.15Aincludes hardware1520comprising a set of one or more processor(s)1522, a set of one or more network interfaces1524(wireless and/or wired), and non-transitory machine-readable storage media1526having stored therein software1528(which includes instructions executable by the set of one or more processor(s)1522). Each of the previously described tenant systems102and the transaction queue104A, the tenant level objects104B, the network level objects104C, and the blockchain services104D may be implemented in one or more electronic devices1500. In one implementation: 1) each of the tenant systems102is implemented in a separate one of the electronic devices1500(e.g., in user electronic devices operated by users where the software1528represents the software to implement tenant systems102to interface with the transaction queue104A, the tenant level objects104B, the network level objects104C, the blockchain services104D, and the blockchain interfaces104E (e.g., a web browser, a native client, a portal, a command-line interface, and/or an application program interface (API) based upon protocols such as Simple Object Access Protocol (SOAP), Representational State Transfer (REST), etc.)); 2) the transaction queue104A, the tenant level objects104B, the network level objects104C, the blockchain services104D, and the blockchain interfaces104E are implemented in a separate set of one or more of the electronic devices1500(e.g., a set of one or more server electronic devices where the software1528represents the software to implement the transaction queue104A, the tenant level objects104B, the network level objects104C, the blockchain services104D, and the blockchain interfaces104E); and 3) in operation, the electronic devices implementing the tenant systems102and the transaction queue104A, the tenant level objects104B, the network level objects104C, the blockchain services104D, and the blockchain interfaces104E would be communicatively coupled (e.g., by a network) and would establish between them (or through one or more other layers) connections for submitting a proposed new record or a proposed modification to an existing record in a physical object to the multi-tenant server104. Other configurations of electronic devices may be used in other implementations (e.g., an implementation in which the tenant systems102and the multi-tenant server104are implemented on a single electronic device1500).

In electronic devices that use compute virtualization, the set of one or more processor(s)1522typically execute software to instantiate a virtualization layer1508and software container(s)1504A-R (e.g., with operating system-level virtualization, the virtualization layer1508represents the kernel of an operating system (or a shim executing on a base operating system) that allows for the creation of multiple software containers1504A-R (representing separate user space instances and also called virtualization engines, virtual private servers, or jails) that may each be used to execute a set of one or more applications; with full virtualization, the virtualization layer1508represents a hypervisor (sometimes referred to as a virtual machine monitor (VMM)) or a hypervisor executing on top of a host operating system, and the software containers1504A-R each represent a tightly isolated form of a software container called a virtual machine that is run by the hypervisor and may include a guest operating system; with para-virtualization, an operating system or application running with a virtual machine may be aware of the presence of virtualization for optimization purposes). Again, in electronic devices where compute virtualization is used, during operation an instance of the software1528(illustrated as instance1506A) is executed within the software container1504A on the virtualization layer1508. In electronic devices where compute virtualization is not used, the instance1506A on top of a host operating system is executed on the “bare metal” electronic device1500. The instantiation of the instance1506A, as well as the virtualization layer1508and software containers1504A-R if implemented, are collectively referred to as software instance(s)1502.

FIG.15Bis a block diagram of an environment where the tenant systems1021-1023and the multi-tenant server104may be deployed, according to some implementations. A system1540includes hardware (a set of one or more electronic devices) and software to provide service(s)1542, including the transaction queue104A, the tenant level objects104B, the network level objects104C, the blockchain services104D, and the blockchain interfaces104E. The system1540is coupled to user electronic devices1580A-S over a network1582. The service(s)1542may be on-demand services that are made available to one or more of the users1584A-S working for one or more other organizations (sometimes referred to as outside users) so that those organizations do not need to necessarily be concerned with building and/or maintaining a system, but instead makes use of the service(s)1542when needed (e.g., on the demand of the users1584A-S). The service(s)1542may communication with each other and/or with one or more of the user electronic devices1580A-S via one or more Application Programming Interface(s) (APIs) (e.g., a Representational State Transfer (REST) API). The user electronic devices1580A-S are operated by users1584A-S.

In one implementation, the system1540is a multi-tenant cloud computing architecture supporting multiple services, such as a customer relationship management (CRM) service (e.g., Sales Cloud by salesforce.com, Inc.), a contracts/proposals/quotes service (e.g., Salesforce CPQ by salesforce.com, Inc.), a customer support service (e.g., Service Cloud and Field Service Lightning by salesforce.com, Inc.), a marketing service (e.g., Marketing Cloud, Salesforce DMP, and Pardot by salesforce.com, Inc.), a commerce service (e.g., Commerce Cloud Digital, Commerce Cloud Order Management, and Commerce Cloud Store by salesforce.com, Inc.), communication with external business data sources (e.g., Salesforce Connect by salesforce.com, Inc.), a productivity service (e.g., Quip by salesforce.com, Inc.), database as a service (e.g., Database.com™ by salesforce.com, Inc.), Data as a Service (DAAS) (e.g., Data.com by salesforce.com, Inc.), Platform as a Service (PAAS) (e.g., execution runtime and application (app) development tools; such as, Heroku™ Enterprise, Thunder, and Force.com® and Lightning by salesforce.com, Inc.), an analytics service (e.g., Einstein Analytics, Sales Analytics, and/or Service Analytics by salesforce.com, Inc.), a community service (e.g., Community Cloud and Chatter by salesforce.com, Inc.), an Internet of Things (IoT) service (e.g., Salesforce IoT and IoT Cloud by salesforce.com, Inc.), industry specific services (e.g., Financial Services Cloud and Health Cloud by salesforce.com, Inc.), and/or Infrastructure as a Service (IAAS) (e.g., virtual machines, servers, and/or storage). For example, system1540may include an application platform1544that enables PAAS for creating, managing, and executing one or more applications developed by the provider of the application platform1544, users accessing the system1540via one or more of user electronic devices1580A-S, or third-party application developers accessing the system1540via one or more of user electronic devices1580A-S.

In some implementations, one or more of the service(s)1542may utilize one or more multi-tenant databases1546for tenant data1548, as well as system data storage1550for system data1552accessible to system1540. In certain implementations, the system1540includes a set of one or more servers that are running on server electronic devices and that are configured to handle requests for any authorized user associated with any tenant (there is no server affinity for a user and/or tenant to a specific server). The user electronic devices1580A-S communicate with the server(s) of system1540to request and update tenant-level data and system-level data hosted by system1540, and in response the system1540(e.g., one or more servers in system1540) automatically may generate one or more Structured Query Language (SQL) statements (e.g., one or more SQL queries) that are designed to access the desired information from the one or more multi-tenant database1546and/or system data storage1550.

In some implementations, the service(s)1542are implemented using virtual applications dynamically created at run time responsive to queries from the user electronic devices1580A-S and in accordance with metadata, including: 1) metadata that describes constructs (e.g., forms, reports, workflows, user access privileges, business logic) that are common to multiple tenants; and/or 2) metadata that is tenant specific and describes tenant specific constructs (e.g., tables, reports, dashboards, interfaces, etc.) and is stored in a multi-tenant database. To that end, the program code1560may be a runtime engine that materializes application data from the metadata; that is, there is a clear separation of the compiled runtime engine (also known as the system kernel), tenant data, and the metadata, which makes it possible to independently update the system kernel and tenant-specific applications and schemas, with virtually no risk of one affecting the others. Further, in one implementation, the application platform1544includes an application setup mechanism that supports application developers' creation and management of applications, which may be saved as metadata by save routines. Invocations to such applications, including the transaction queue104A, the tenant level objects104B, the network level objects104C, the blockchain services104D, and the blockchain interfaces104E, may be coded using Procedural Language/Structured Object Query Language (PL/SOQL) that provides a programming language style interface. A detailed description of some PL/SOQL language implementations is discussed in U.S. Pat. No. 7,730,478 entitled, METHOD AND SYSTEM FOR ALLOWING ACCESS TO DEVELOPED APPLICATIONS VIA A MULTI-TENANT ON-DEMAND DATABASE SERVICE, by Craig Weissman, filed Sep. 21, 2007. Invocations to applications may be detected by one or more system processes, which manages retrieving application metadata for the tenant making the invocation and executing the metadata as an application in a software container (e.g., a virtual machine).

Network1582may be any one or any combination of a LAN (local area network), WAN (wide area network), telephone network, wireless network, point-to-point network, star network, token ring network, hub network, or other appropriate configuration. The network may comply with one or more network protocols, including an Institute of Electrical and Electronics Engineers (IEEE) protocol, a 3rd Generation Partnership Project (3GPP) protocol, or similar wired and/or wireless protocols, and may include one or more intermediary devices for routing data between the system1540and the user electronic devices1580A-S.

Each user electronic device1580A-S (such as a desktop personal computer, workstation, laptop, Personal Digital Assistant (PDA), smart phone, etc.) typically includes one or more user interface devices, such as a keyboard, a mouse, a trackball, a touch pad, a touch screen, a pen or the like, for interacting with a graphical user interface (GUI) provided on a display (e.g., a monitor screen, a liquid crystal display (LCD), etc.) in conjunction with pages, forms, applications and other information provided by system1540. For example, the user interface device can be used to access data and applications hosted by system1540, and to perform searches on stored data, and otherwise allow a user1584to interact with various GUI pages that may be presented to a user1584. User electronic devices1580A-S might communicate with system1540using TCP/IP (Transfer Control Protocol and Internet Protocol) and, at a higher network level, use other networking protocols to communicate, such as Hypertext Transfer Protocol (HTTP), FTP, Andrew File System (AFS), Wireless Application Protocol (WAP), File Transfer Protocol (FTP), Network File System (NFS), an application program interface (API) based upon protocols such as Simple Object Access Protocol (SOAP), Representational State Transfer (REST), etc. In an example where HTTP is used, one or more user electronic devices1580A-S might include an HTTP client, commonly referred to as a “browser,” for sending and receiving HTTP messages to and from server(s) of system1540, thus allowing users1584of the user electronic device1580A-S to access, process and view information, pages and applications available to it from system1540over network1582.

In the above description, numerous specific details such as resource partitioning/sharing/duplication implementations, types and interrelationships of system components, and logic partitioning/integration choices are set forth in order to provide a more thorough understanding. It will be appreciated, however, by one skilled in the art, that the invention may be practiced without such specific details. In other instances, control structures, logic implementations, opcodes, means to specify operands, and full software instruction sequences have not been shown in detail since those of ordinary skill in the art, with the included descriptions, will be able to implement what is described without undue experimentation.

In the following description and claims, the term “coupled,” along with its derivatives, may be used. “Coupled” is used to indicate that two or more elements, which may or may not be in direct physical or electrical contact with each other, co-operate or interact with each other.

The operations in the flow diagrams are be described with reference to the exemplary implementations in the other figures. However, the operations of the flow diagrams can be performed by implementations other than those discussed with reference to the other figures, and the implementations discussed with reference to these other figures can perform operations different than those discussed with reference to the flow diagrams.

While the flow diagrams in the figures show a particular order of operations performed by certain implementations, it should be understood that such order is exemplary (e.g., alternative implementations may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

While the above description includes several exemplary implementations, those skilled in the art will recognize that the invention is not limited to the implementations described and can be practiced with modification and alteration within the spirit and scope of the appended claims. The description is thus illustrative instead of limiting.