ON LABELS OF THE TRANSACTIONS

TECHNICAL FIELD

[0001] The present disclosure relates to the field of distributed ledger technology networks; and more specifically, to the processing transactions in a distributed ledger network based on labels of the transactions.

BACKGROUND

[0002] Distributed ledger technology (DLT) systems are platforms used for building, running, and deploying a decentralized, distributed and public distributed ledger (DL) network. In a DL network a digital ledger permanently records digital records of transactions that occur between two parties. The records cannot be altered retroactively without the alteration of all subsequent transactions in the digital ledger and without consensus from other nodes in the network. This allows the participants to verify and audit transactions inexpensively and securely. A digital ledger is maintained without a central authority or implementation. For example, the digital ledger can be a blockchain that includes blocks secured and linked to one another using cryptographic mechanisms.

[0003] DL networks may be public (which can also be referred to as permissionless) or private (which can also be referred to as permissioned). Public DL networks are available to anyone who wants to join and use the network. In this type of DL network, anyone is allowed to read, write, or join the public DL network. The distributed ledger (e.g., a blockchain) is decentralized meaning no entity has control over the DL network, ensuring the data can’t be changed once validated on the DL. In public DL networks, anyone, anywhere, can use the DL network to input transactions and data. In contrast, while private DL networks can be similar to public DL networks in certain aspects, they have access controls that restrict those that can join the network. Private DL networks have one or multiple entities that control the network. Private DL networks are generally preferred to public DL networks for use cases with interactions between a limited number of participants.

[0004] Multiple participants (e.g., organizations, enterprises, individuals, etc.) can set up a private DL network to protect the privacy and security of their data. Typically, participation in a private DL network is initiated through an invitation. The participant in the private DL network can be validated by a node that starts the DL network (which can be referred to as a network starter) or by a set of rules. In addition to restricting access to participants, a private DL network can also restrict participants’ activities such that some transactions can only be carried out by some participants and not by other participants consequently creating an additional layer of privacy. Participation authorization can be set up by a single participant of the DL network, a regulatory authority, or a consortium of participants.

[0005] While public DL networks have limited operability, private DL networks have the potential to revolutionize many aspects of daily life. The rapid development of permissioned DL technology, coupled with interest from large enterprises, is paving the way for an increase in use of private DL networks.

[0006] Several uses of private DL network result in having different types of transactions in the same digital ledger. For example, in a billing system built on a DL network that records billing transactions from a service provider to a customer of the service provider, may be used to record transactions that are recurring and transactions that occur only once (non-recurring transactions) for a given customer in the same private digital ledger. In another example, a system may record trusted transactions and untrusted transactions in the common private digital ledger. In some scenarios, after recording the transactions, these transactions can be retrieved and stored in an application datastore to be used by applications of one or more entity (e.g., customer, the service provider, a regulatory authority, an auditing authority, etc.). In these scenarios, the applications may process non recurring transactions along with the recurring transactions, which is an expensive procedure that creates unnecessary additional transactions recorded in the same digital ledger. Further, processing transactions from the application datastore is complex as validation of transactions is not segmented based on the type of the transactions. Storing the different transactions regardless of their type in the same digital ledger unnecessarily overloads the system (e.g., the billing system, etc.) and causes more unused transactions (e.g., the non-recurring transactions, the untrusted transactions, etc.) to be stored in the same structure as more pertinent transactions (e.g., trusted, recurring transactions).

SUMMARY

[0007] An object of embodiments herein is to provide efficient and space saving methods and apparatus for recording different types of transactions in private digital ledgers. The embodiments described herein allow the filtering of the transactions in the initial stages of DL network. The embodiments presented herein allow to separate recordation of different types of transactions in separate digital ledgers. The embodiments presented herein enable the user of machine learning models in a DL network to avoid the recordation of unnecessary transactions within the same private digital ledger by leveraging the advantages of channels in the DL network.

[0008] One first general aspect includes a method of processing transactions in a distributed ledger (DL) network that is shared by a plurality of participants, the method including: determining, based on a first classifier, a first label for a first transaction of a first of the plurality of participants; determining, based on the first classifier, a second label for a second transaction of a second of the plurality of participants, where the second label is different from the first label; recording, based on the first label, the first transaction in a first private digital ledger of a first channel in the DL network, where the first channel that includes a first set of two or more DL nodes of the DL network; and recording, based on the second label, the second transaction in a second private digital ledger of a second channel in the DL network, where the second channel includes a second set of one or more DL nodes of the DL network that is different from the first set of DL nodes and the second private digital ledger is separate from the first digital ledger network.

[0009] One second general aspect includes a computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method of processing transactions in a distributed ledger (DL) network that is shared by a plurality of participants according to the first general aspect that is described above.

[0010] One third general aspect includes a node in a distributed ledger network, the node including: one or more processors; and a computer readable storage medium storing a set of computer readable instructions that when executed by the one or more processors cause the node to perform the following operations including determining, based on a first classifier, a first label for a first transaction of a first of the plurality of participants; determining, based on the first classifier, a second label for a second transaction of a second of the plurality of participants, where the second label is different from the first label; recording, based on the first label, the first transaction in a first private digital ledger of a first channel in the DL network, where the first channel that includes a first set of two or more DL nodes of the DL network; and recording, based on the second label, the second transaction in a second private digital ledger of a second channel in the DL network, where the second channel includes a second set of one or more DL nodes of the DL network that is different from the first set of DL nodes and the second private digital ledger is separate from the first digital ledger network. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The present disclosure may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the present disclosure. In the drawings:

[0012] Fig. 1A illustrates a block diagram of an exemplary private DL network, in accordance with some embodiments.

[0013] Figure IB illustrates a block diagram of an exemplary transaction label updated that can be used in a private DL network, in accordance with some embodiments.

[0014] Fig. 2A illustrates a flow diagram of exemplary operations that can be performed for processing transactions in a DL network that is shared by a plurality of participants, in accordance with some embodiments.

[0015] Fig. 2B illustrates a flow diagram of exemplary operations that can be performed for recording a transaction in a private digital ledger of a channel, in accordance with some embodiments.

[0016] Fig. 2C illustrates a flow diagram of exemplary operations that can be performed for updating the label associated with an entry for the transaction, in accordance with some embodiments.

[0017] Fig. 3 illustrates a block diagram for a network device that can be used for implementing one or more of the DL nodes described herein, in accordance with some embodiments.

[0018] Fig. 4 illustrates a block diagram for network devices that can be used for implementing a DL node described herein, in accordance with some embodiments.

DETAILED DESCRIPTION

[0019] The following description describes methods and apparatus for separating a private state and private transactions from an aggregate state and aggregate transactions in a distributed ledger network. In the following description, numerous specific details such as logic implementations, opcodes, means to specify operands, 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 of the present disclosure. It will be appreciated, however, by one skilled in the art that the embodiments may be practiced without such specific details. In other instances, control structures, gate level circuits and full software instruction sequences have not been shown in detail in order not to obscure the embodiments. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.

[0020] References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described. [0021] Bracketed text and blocks with dashed borders (e.g., large dashes, small dashes, dot-dash, and dots) may be used herein to illustrate optional operations that add additional features to some embodiments. However, such notation should not be taken to mean that these are the only options or optional operations, and/or that blocks with solid borders are not optional in certain embodiments.

[0022] In the following description and claims, the terms “coupled” and “connected,” along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. “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. “Connected” is used to indicate the establishment of communication between two or more elements that are coupled with each other.

[0023] The embodiments described herein present methods and apparatuses for processing transactions in a DL network that is shared by a plurality of participants. A first label is determined for a first transaction of a first of the plurality of participants based on a first classifier. A second label for a second transaction of a second of the plurality of participants is determined based on the first classifier, where the second label is different from the first label. The first transaction is recorded in a first private digital ledger of a first channel in the DL network, based on the first label. The first channel includes a first set of two or more DL nodes of the DL network. The second transaction is recorded in a second private digital ledger of a second channel in the DL network, based on the second label. The second channel includes a second set of one or more DL nodes of the DL network that is different from the first set of DL nodes and the second private digital ledger is separate from the first DL network. [0024] The methods and apparatus described herein present several advantages with respect to conventional private DL networks. The allocation of separate channels to different types of transactions, where the transaction types are defined based on a label associated with the transaction, allow to save processing space and time in DL networks. For example, when the transactions are each associated with a recurring or non-recurring label, each transaction is processed and recorded based on the associated label in a separate one of two channels, consequently causing a transaction associated with a recurring label to be stored in a first private DL and a transaction associated with a non-recurring label to be stored in a second private DL that is different from the first private DL. Some embodiments may include additional performance improvements by placing the classification operation into first and second label within a channel. Further as transactions are separated into two types by being associated with two different labels, and the different types of transactions are stored in different digital ledgers memory space is saved during the processing of smart contracts for accessing or validating these transactions. The use of channelization, i.e., processing of transaction within respective channels, speeds up the transaction evaluation process (which can be referred to as mining in some DL networks).

[0025] Fig.lA illustrates a block diagram of an exemplary system for processing transactions in a DL network 100 based on labels associated with the transactions, in accordance with some embodiments. In the following description some examples will be described for a particular type of DL networks, namely the blockchain networks. However, the embodiments described herein generally apply to other types of DL networks, which will not necessarily be named herein.

[0026] The DL network 100 includes a set of participant nodes 102A-N, a set of nodes 109 A-F a first classifier 110A, a transactions history datastore 112A, a transaction label updater 180, a transaction endorser 130, a first channel 140A, and a second channel 140B. The various components of the DL network 100 communicate through a physical network (supported by wired, wireless, or a combination of wired and wireless networking technology) that is not illustrated. The DL network 100 is a private distributed ledger that is operative to enable participants in the network to have access to private data while other participants in the network cannot access this private data. In some embodiments, in addition to enabling access to private data, the DL network 100 is operative to enable participants to have access to public data that all participants can view. In some embodiments, the DL network is a blockchain network. [0027] A participant in the DL network 100 is an entity that can participate and contribute to transactions with other participants in the ledger. The participant can be a person, an organization, a program run on a processor, etc. The participant is associated with a node (e.g., participant nodes 102A-N) that is used to access the DL network 100. In addition, a participant can own one or more additional nodes that can be part of the DL network 100. For example, each of the DL nodes 109A-E can belong to one of the participants of the DL network. Thus, a node of a participant can be a DL node, e.g., DL node 109A to 109E, or a simple node that is not part of the DL network 100. A participant can also be referred to as an organization, or an entity in the DL network 100.

[0028] In some embodiments, each participant may own one or more DL nodes that are part of a private channel or an additional DL network that are not illustrated in the Fig. 1A. The private channel or additional DL network can be different from the first private channel and different from the second private channel. For example, the additional DL network may also include a public digital ledger that is open and available for any participant that wants to join this public network and the participants may have one or more of DL nodes that are part of the public DL network. Alternatively or additionally, each participant may have one or more DL nodes that are part of one or more other private channels, which are not illustrated in Fig. 1A.

[0029] Each of the participant nodes 102A-F is an electronic computing device that allows a participant to generate one or more transactions that are to be recorded in a private digital ledger of the DL network 100. A transaction may include a transaction identifier, a participant identifier, a transaction date, and a transaction amount. In some embodiments, the transaction may further include an identification of a plan or service that the participant has subscribed to. The service can be provided by a service provider (e.g., telecommunication service provider), which is also a participant in the DL network 100. Other examples of services can be contemplated without departing from the scope of the present embodiments. In other embodiments, the transaction does not include a service identifier. In some embodiments, the transaction may include an identifier of a second participant that is a destination of the transaction. The transaction identifier is uniquely associated with the transaction for a given participant. The participant identifier is uniquely associated with the participant that is generating the transaction. In some embodiments, the transaction can be transmitted to DL node 109F through an API call, an HTTP request, or any other call. The transaction can be part of a set of transactions that are sent from the participant node 102A. In some embodiments, the transactions are transmitted in an XML document, a JSON document, or any other data interchange format.

[0030] A DL node 109 is a node that is operative to perform some, or all operations related to updating and maintaining a digital ledger (e.g., 106A or 106B). For example, a DL node 109 can be a full node that stores the entire digital ledger. Alternatively, the DL node 109 can be a light node, which may include only a partial list of the digital ledger. The DL node 109 may further be operative to receive transactions from nodes of participants 102, evaluate the transactions, and validates them to be added to the digital ledger based on a consensus algorithm (such as Proof of Work (PoW), Proof of Stake (PoS), or other). A DL node 109 can be referred to as a peer node or peer. In some embodiments, in addition to hosting a copy of the distributed ledger, a DL node 109 can also store copies of smart contracts 133. Smart contracts and digital ledgers are used to encapsulate the shared processes and shared information in a network, respectively. DL nodes 109 can be created, started, stopped, reconfigured, and even deleted. In some implementations, DL nodes 109 expose a set of APIs that enable administrators and applications (e.g., participant nodes 102A-N) to interact with the services that they provide.

[0031] Each DL node 109 has an identity assigned to them, a DL node identifier. In some embodiments, the DL node identifier can be a digital certificate assigned to the DL node 109 from a certificate authority (not illustrated in Fig. 1A). For example, the digital certificate can be a X.509 digital certificate. The digital certificate provides verifiable information about a DL node 109.

[0032] The first classifier 110A receives one or more transactions and determines for each one of the transactions a corresponding label. The first classifier 110A determines a first label for the first transaction 101A and a second label for the second transaction 101B. In some embodiments, the first label indicates that the first transaction is recurring, and the second label indicates that the second transaction is nonrecurring (e.g., the second transaction is a one-time transaction). The classification of the first and the second transaction can be performed based on one or multiple parameters. In one embodiment, the classification can be performed based on the customer identifier associated with the transaction. The customer identifier uniquely identify the participant in the DL network 100. In other embodiments, one or more additional parameters can be used by the classifier 110A to determine a label for a transaction. For example, the classification can be performed based on a service identifier that uniquely identifies a service offered to a participant. [0033] In the following description some examples will be described with respect to a first label being a recurring label and a second label being a non-recurring label. In some embodiments, a transaction associated with the “recurring” label can be a transaction that occurs multiple times for a given participant and a given service over a period of time. A transaction associated with the “non-recurring” can be a transaction that occurs only once during that same period of time for a given participant and a given service. While the embodiments herein are described with respect to recurring and non-recurring transactions, in other embodiments, different pairs of labels can be used without departing from the scope of the present embodiments. For example, the labels can be trusted and untrusted, where a trusted transaction is associated with a participant that is trusted in the DL network and for which a transaction can be added to the digital ledger, and the untrusted transaction is associated with a participant that is not yet trusted in the DL network and for which a transaction cannot yet be added to the digital ledger.

[0034] In some embodiments, the first classifier 110A implements a modified logistic regression. The modified logistic regression can be used in the DL network 100 as a generalized model in the form of logistic function that predicts if a transaction may be associated with the first or the second label depending on the training done with an available dataset. The available dataset is stored in the transaction(s) history datastore 112A. The transaction(s) history datastore 112A may include a training data set that is used for training the first classifier 110A as well as new transactions received through the DL network 100 and recorded in the DL network 100.

[0035] The logistic regression is based on a logistic function f(z):

[0036]

[0037] The input of the logistic function is z and the output is /( z). The logistic function can take a transaction as an input parameter and the output is confined to values between 0 and 1. The output here represents a probability of the label of the transaction is the first or the second label. In some embodiments, the variable z represents the exposure to some set of independent variables which is a set of transaction parameters, while /(z) represents the probability of an outcome.

[0038] In some embodiments, the variable z can be defined as [0040] where, is called the "intercept" and the b for i=l...k and are called the "regression coefficients" of transaction parameters X _j , ... , X/

[0041] The intercept is the value of z when the value of all transaction parameters are zero. Each one of the regression coefficients describes the size of contribution of the transaction parameter towards the label to be associated with the transaction. The logistic regression_provides an accumulated weight model to infer if a transaction z is to be associated with the first or the second label.

[0042] In some embodiments, each newly uploaded transaction is classified by the first classifier 110A based on the participant’s identifier and a current transaction date and time when compared with date and time of a previous transaction for the same participant’s identifier. In some embodiments, when the first label is “recurring” and the second label is “non-recurring,” upon receipt of the first transaction 101A for a first participant 102, if the first classifier 110A determines that the number of transactions associated with the first participant’s identifier exceeds a predetermined threshold value, the first transaction is associated with the first label. Alternatively, upon receipt of the second transaction 101B for the second participant, if the classifier 110B determines that the number of transactions associated with the second participant’s identifier does not exceed the predetermined threshold value, the second transaction is associated with the second label. In some embodiments, if the number of parameters that relate to the transactions is more complex, then advanced machine learning methods such as deep learning neural network (convolutional neural network (CNN), recurrent neural network (RNN), deep reinforcement learning (DQL), etc.,) can be used as the first classifier 110A.

[0043] The DL nodes 109A-D and 109F form a first channel 140A and the DL node 109E and DL node 109F form a second channel 140B. The second channel 140B is separate from the first channel 140A. A channel is a mechanism by which a set of components within a DL network 100 can communicate and transact privately.

[0044] These components are typically DL nodes 109 and applications. In some embodiments, the components can also include an orderer (not shown in Fig. 1). Each of these components joins the channel (e.g., channel 140A and/or channel 140B) and, by joining a channel, they agree to collaborate to collectively share and manage identical copies of the digital ledger associated with that channel. Components of two channels might be totally separate, or alternatively there can be some crossover between them. For example, the first channel 140A and the second channel 140B share the DL node 109F. Nevertheless, each group of components is its own entity, with a respective set of rules. Each one of the channels, e.g., 140A and 140B, allows a specific set of DL nodes 109 and applications to communicate with each other within the DL network 100. A channel can be viewed as a pathway for communications between particular applications and DL nodes 109. A channel is a logical structure that is formed by a collection of physical DL nodes 109. Each DL node 109 that is part of a channel provides the control point for access to, and management of, the channel.

[0045] Whenever a DL node 109 connects using a channel, e.g., the first or the second channel, to the DL network 100, a policy in the channel configuration uses the DL node’s identity, e.g., the DL node identifier, to determine its rights. In some embodiments, the mapping of DL node identity to organization is provided by a component called a Membership Service Provider (MSP). The MSP determines how a DL node 109 gets assigned to a specific role in a particular participant and accordingly how the DL node 109 gains appropriate access to the resources in the DL network 100. For example, the MSP may be used to provide access to each one of the channels 140A-B. Moreover, a DL node 109 can be owned only by a single participant, and is therefore associated with a single MSP.

[0046] Each DL node 109 may include one or more digital ledgers and one or more DL network state(s). In some embodiments, the DL node 109 may include a private digital ledger that is associated with the respective channel to which the DL node 109 belongs. In some embodiments, the DL node may further include a public digital ledger (not illustrated in Lig. 1A) that is public to any participant in the DL network 100. Lor example, each one of the DL nodes 109A-D and 109L that are part of the first channel 140A includes a first private digital ledger 106A and a first private state 107A. The private digital ledger 106A is a complete list of every single transaction that has occurred in the first channel 140A. Once transactions are written to the first private digital ledger, they cannot be modified; the record 106A is immutable. While DL nodes 109 A-D and 109L are illustrated as including the first digital ledger 106A, one or more other DL nodes (not illustrated) and which may be part of the first channel, may include a copy of all or a portion of the digital ledger 106A. While the first channel 140A is illustrated as including five DL nodes (109A-D and 109F), this is intended to be exemplary, other implementations, where a different number of DL nodes are contemplated.

[0047] Additionally, each one of the DL nodes 109E and 109F that are part of the second channel 140B includes a second private digital ledger 106B and a second private state 107B. The private digital ledger 106B is a complete list of every single transaction that has occurred in the second channel 140B. Once transactions are written to the second private digital ledger 106B, they cannot be modified; the record is immutable. While nodes 109E and 109F are illustrated as including the second digital ledger 106B, one or more other DL nodes (not illustrated) and which may be part of the first channel, may include a copy of all or a portion of the digital ledger 106B.

[0048] In one example, the first digital ledger 106A and the second digital ledger 106B can be a first and a second blockchains. In this example, transactions are collected inside blocks, that are appended to the blockchain. In addition to the transactions, each block may include additional fields (e.g., a block header) . In other examples, the digital ledgers 106A- B can be another structure different from the blockchain that is operative to store private and public transactions.

[0049] In some embodiments, the first channel 140A may include significantly greater number of nodes than the second channel 140B resulting in a higher level of security and trustworthiness in the network than the second channel 140B. In addition the second channel 140B may include a small number of nodes (e.g., a single node) that causes processing of transactions with the second label to be efficient without the need for large resources (e.g., storage, processing, etc.).

[0050] The DL nodes 109 A-D and 109F include a first private states 107A. A state of the DL network 100 is a datastore (e.g., a database) that holds current values of a set of ledger states. The state of the DL network 100 can be referred to as the world state. The state of the DL network 100 allows to directly access the current value of an entry rather than having to calculate it by traversing the entire digital ledger. For example, the state of the DL network 100 may include entries that represent the state of each participant in the DL network 100. The state of a participant can be expressed as a key-value pair, where the key is the participant’s ID, and the value is the current value of the state for that participant based on all transactions recorded in the digital ledger to date. The state can change frequently, as transactions are added in the digital ledger 106A-B.

[0051] In the illustrated example, the state of the DL network is a private state, first private state 107A and second private state 107B. In some embodiments, each DL node 109 may further include a public state of the DL network 100 (not illustrated), which results from the evaluation of the public transactions that are stored in a public digital ledger of the DL network 100. The first private state 107A results from evaluation of the private transactions that are associated with the first label and that are recorded in the first channel 140A. The first private state 107A is stored in each one of the DL nodes 109A-D that are part of the first channel 140A. The second private state 107B results from evaluation of the private transactions that are associated with the second label and that are recorded in the second channel 140B. The second private state 107B is stored in each one of the DL nodes that are part of the second channel 140B.

[0052] The use of the first and the second channels 140A-B provide an efficient sharing of infrastructure while maintaining data and communications privacy. The two channels are independent consequently enabling separation of transaction recordation based on the labels associated with the transactions. Thus, a channel provides a completely separate communication mechanism between a set of participants. In the discussed embodiments, the use of the first or the second channel for recording a transaction is conditioned to the type of label that is associated with that transaction. The first channel 140A is used when the transaction is associated with the first label, while the second channel 140B is used when the transaction is associated with the second label.

[0053] In some embodiments, the DL node 109F may include the first classifier 110A and the transaction endorser 130. In other embodiments, the DL node 109F may include the transaction endorser 130 only and the first classifier 110A may be external to the DL node 109F. The transaction endorser 130 is operative to 1) receive the transactions after being labeled by the first classifier 110A, 2) validates (or endorses) the transactions to be included in one of the first channel or the second channel, and 3) once the transactions are deemed valid to be included in the DL network 100 they are transmitted to the DL nodes 109 of the respective channel to be included in the private digital ledger 106A-B of the channel 140A- B.

[0054] The embodiments herein will be described with respect to a first transaction 101A that is received from the participant node 102A and the second transaction 101B received from the participant node 102N. The first classifier 110A classifies the first transaction 101A with a first label and the second transaction 101B with a second label.

[0055] The transaction endorser 130 records the first transaction 101A in the first private digital ledger 106A of the first channel 140A in the DL network 100 based on the first label. The transaction endorser 130 records the second transaction 101B in the second private digital ledger 106B of the second channel 140B in the DL network 100, based on the second label. The second private digital ledger 106B is separate from the first DL network 106A. Thus, depending on the label that is associated with a transaction, the transaction is recorded in a different one of the first or the second private digital ledger. [0056] In some embodiments, the DL network is a blockchain network. In some of these embodiments, the transaction endorser 130 may include a channel configurator 134 and a smart contract invoker 132. The smart contract invoker 132 is operative to invoke the smart contracts 133A or 133B, depending on the label associated with a transaction, for recording the transaction in the respective one of the first and the second private digital ledgers 106A- B. The smart contract, 133A or 133B, is computer code running on top of the DL network 100 that contains a set of rulesets to create new blocks based on the transactions received from the first classifier 110A and send the new blocks to the channel configurator 134. The channel configurator 134 is operative to split the incoming transactions to the specific channel, i.e., the first or the second channel 140A-B. Further the channel configurator 134 may transmit the transaction details, and block information such as a block identifier, channel identifier, and one or more additional meta data associated with the transaction to the transaction label updater 180.

[0057] In some embodiments, an administrator may define an endorsement policy used by the transaction endorser 130 for executing the smart contracts 133A-B . The endorsement policy applies equally to all smart contracts defined within the same chaincode deployed to a channel. In some embodiments, the first smart contract and the second smart contract can be deployed based on a same chaincode with different endorsement policies. Alternatively, the first smart contract and the second smart contract can be deployed based on different chaincodes.

[0058] The transactions are sent to each one of the first and the second channel. For example, the first transaction 101A is sent to the first channel 140A and the second transaction 101B is sent to the second channel 140B. While a single transaction is illustrated, typically multiple transaction with the same label can be sent to a respective channel. For example, a first block including multiple transactions with a first label are sent to the first channel 140A and a second block including multiple transactions with the second label are sent to the second channel 140B. In some embodiments, the block is sent to each of the DL nodes 109 of the respective channel.

[0059] In some embodiments, upon receipt of a block, a DL node 109 processes each transaction in the sequence in which it appears in the block. For every transaction, each DL node 109 verifies that the transaction has been endorsed by the required transaction endorser according to the endorsement policy of the smart contract which generated the transaction, the first or the second transaction. For example, some transactions may only need to be endorsed by a single participant, whereas others may require multiple endorsements before they are considered valid. This process of validation verifies that all relevant participant have generated the same outcome or result. If a transaction has been endorsed correctly, the DL node 109 will attempt to apply it to the private ledger, the first or the second private digital ledger 106A-B. After a DL node 109 has successfully validated each individual transaction, it updates the respective private digital ledger 106A or 106B. Failed transactions are not applied to the private digital ledger 106A-B, but they may be retained for audit purposes, as are successful transactions.

[0060] The embodiments described herein present methods and apparatuses for enabling separate recordation of transactions in multiple channels based on labels associated with the transactions to be recorded. The allocation of separate channels to different types of transactions, where the transaction types are defined based on the label associated with each transaction, allows to save processing space and time in DL networks. For example, when the transactions are each associated with a recurring or non-recurring label, each transaction is processed and recorded based on the associated label in a separate one of two channels, consequently causing a transaction associated with a recurring label to be stored in a first private DL 106A and a transaction associated with a non-recurring label to be stored in a second private DL 106B that is different from the first private DL 106A. Some embodiments may include additional performance improvements by placing the classification operation into first and second label within a channel. Memory space can be well managed including the processing of contracts during dynamic transactions. The use of channelization, i.e., processing of transaction within respective channels, speeds up the transaction evaluation process (which can be referred to as mining in some DL networks). [0061] Figure IB illustrates a block diagram of an exemplary transaction label updated that can be used in a private DL network, in accordance with some embodiments. The transaction label updater 180 includes a transaction state datastore 150, a DL node 109G, an application datastore 170, a second classifierllOB. The transaction label updater 180 is operative to update the label associated with a transaction previously recorded in the DL network 100, e.g., in the first digital ledger 106A of the DL network 100, and update the entry associated with this transaction in the transaction(s) history datastore 112A based on the new label.

[0062] The transaction state datastore 150 receives from the transaction endorser 130 a block identifier of the block that is to include the transactions to be recorded in the DL network 100, a status of the block indicating that these transactions are new transactions to be included in the DL network 100 and that they have still not been recorded in a digital ledger of the DL network 100, and a channel identifier of the channel that is to be used to record the block. The transaction endorser 130 may transmit a first block ID identifying the first block that includes the first transaction associated with the first label, a first block status that indicates that the transactions of the first block are new, and a first channel ID that identifies the first channel 140A. The transaction endorser 130 may transmit a second block ID identifying the second block that includes the second transaction associated with the second label, a second block status that indicates that the transactions of the second block are new, and a second channel ID that identifies the second channel 140A. In some embodiments, the transaction state datastore 150 stores the information received from the transaction endorser 130. In other embodiments, the information is not stored and is passed immediately to the DL node 109G.

[0063] The DL node 109G is operative to receive the first block ID and the first channel ID and retrieve based on the first smart contract 133 A, through the smart contract invoker 132, the first cryptographic transaction identifier that uniquely identifies the first transaction of the first block from the first digital ledger 106A. The DL node 109G determines based on the first channel ID that the transactions for the first block are to be retrieved from the first digital ledger 106A. The DL node 109G is then operative to invoke the first smart contract 133A based on the first block ID to read from the first digital ledger 106A the set of transactions that includes the first transaction. While the embodiments are described that a first transaction is retrieved for the first block, one of ordinary skill in the art would understand that when the block includes several transactions, these transactions are also retrieved from the first digital ledger 106 A based on the block identifier and the channel identifier.

[0064] The DL node 109G is further operative to receive the second block ID and the second channel ID and retrieve based on the second smart contract 133B, through the smart contract invoker 132, the second cryptographic transaction identifier that uniquely identifies the second transaction of the first block from the second digital ledger 106B. The DL node 109G determines based on the second channel ID that the transactions for the second block are to be retrieved from the second digital ledger 106B. The DL node 109G is then operative to invoke the second smart contract 133B based on the second block ID to read from the second digital ledger 106B the set of transactions that includes the second transaction. While the embodiments are described that a second transaction is retrieved for the second block, one of ordinary skill in the art would understand that when the block includes several transactions, these transactions are also retrieved from the second digital ledger 106B based on the block identifier and the channel identifier.

[0065] The DL node 109G is operative to update the status of the block in the transaction state datastore 150. For example, the status of the block can be updated from “new” to “old.” The updated status of the block indicates that the transactions of the block have been recorded in a digital ledger of the DL network 100, e.g., the first digital ledger 106A or the second digital ledger 106B. In some embodiments, the status of the block may be updated upon determination that the transactions are stored in the application datastore 170.

[0066] The DL node 109G is operative to store the retrieved transactions, e.g., first transaction 101A and second transaction 101B in the application datastore 170 making the transactions available for one or more entities. For example, one or more participant nodes 102Q-R can be used to access these transactions. The transactions can be used for multiple services such as a billing service, or other. The participant node 102Q-R can be electronic computing devices that run an application that takes transactions as input. In some embodiments, the transactions can be indexed based on a cryptographic transaction identifier associated with the transaction and which uniquely identifies the transaction. In some embodiments, the cryptographic transaction identifier can be generated by the transaction endorser 130 when the transaction endorser records the transaction. In some embodiments, the cryptographic transaction identifier can be generated based on a transaction identifier as received from the participant nodes 102A-N, a participant identifier, a transaction date and time that indicates the time and date of generation of the transaction, a processing date and time which indicates the time and date the transaction is received by the transaction endorser 130. This cryptographic transaction identifier uniquely identifies each transaction and is used to store the transactions and retrieve the transaction in the application datastore 170. The cryptographic transaction identifier is also used to identify the transaction is a respective private digital ledger. For example, the first transaction 101A is uniquely identified with the first cryptographic transaction identifier and the second transaction 101B is uniquely identified with the second cryptographic transaction identifier.

[0067] The application datastore 170 is also used by a second classifier 110B. The second classifier 110B is used to determine whether the second transaction 101B is to be associated with the first label instead of the second label. In some embodiments, determining that the second transaction 101B is to be associated with the first label instead of the second label can be performed based at least in part on a time indicator of the second transaction 101B and one or more time indicators of one or more previous transactions for the same second participant.

[0068] In response to determining that the second transaction 101B is to be associated with the first label instead of the second label, an entry of the transaction history datastore 112A is updated for the second transaction 101B, where the second transaction 101B is associated with the first label instead of the second label.

[0069] The transaction history datastore 112A can then be used with the first classifier for classifying a new transaction that is received in the DL network 100. In some embodiments, the new transaction can be for the second participant. In other embodiments, the new transaction can be for another participant that is different from the second participant. The classification of the new transactions is performed at least in part based on the updated entry of the transaction history datastore 112A for the second transaction 101B causing the new transaction to be processed based on the first label. The new transaction is recorded in the first private digital ledger 106A of the first channel based on the first label.

[0070] Alternatively, upon the second classifier 110B may determine that the second transaction 101B is not to be updated to be associated with a different label, e.g., the first label instead of the second label. In response to determining that the second transaction 10 IB is not to be associated with the first label instead of the second label, an entry of the transaction history datastore 112A is not updated for the second transaction. The transaction history datastore 112A is used with the first classifier 110A for classifying a new transaction that is received in the DL network 100. In some embodiments, the new transaction can be for the second participant. In other embodiments, the new transaction can be for another participant that is different from the second participant. The classification of the new transactions is performed at least in part based on the entry of the transaction history datastore 112A for the second transaction 101B causing the new transaction to be processed based on the second label. The new transaction is recorded in the second private digital ledger 106B of the second channel 140B based on the second label.

[0071] In some embodiments, the second classifier 110B is based on a reinforcement learning method. For example, the reinforcement learning method validates with the application datastore 170 if a new transaction stored is recurring or non-recurring based on the date time difference between the previous transaction date and time and the new transaction triggering to change the status based on a threshold. Where the threshold is considered as a reward mechanism of the reinforcement learning method. [0072] When the number of transactions for the same participant exceeds the threshold value then reinforcement learning method updates the corresponding label of the transaction to the second label causing the next transaction to be processed in the first channel 140A of the DL network 100.

[0073] The operations in the flow diagrams of Fig. 2A-C will be described with reference to the exemplary embodiments of Fig. 1A-B. However, it should be understood that the operations of the flow diagrams can be performed by embodiments of the invention other than those discussed with reference to Fig. 1A-B, and the embodiments of the invention discussed with reference to Fig. 1A-B can perform operations different than those discussed with reference to the flow diagrams of Fig. 2A-C.

[0074] Fig. 2A illustrates a flow diagram of exemplary operations that can be performed for processing transactions in a DL network that is shared by a plurality of participants, in accordance with some embodiments.

[0075] At operation 202 a first label is determined for a first transaction of a first of the plurality of participants 102. The determination of the first label is performed based on the first classifier 110A. In the embodiments herein, the first of the plurality of participants 102 can be referred to as the first participant. The flow then moves to operation 204. In some embodiments, the first label indicates that the first transaction 101A for the first participant is recurring.

[0076] At operation 204, a second label is determined for a second transaction 101B of a second of the plurality of participants, based on the first classifier 110A. The second label is different from the first label. In the embodiments herein, the second the plurality of participants can be referred to as the second participant. In some embodiments, the second label indicates that the second transaction 101B for the second participant is non-recurring. The flow of operations then moves to operation 206.

[0077] At operation 206, the first transaction 101A is recorded in a first private digital ledger 106A of a first channel 140A in the DL network 100 based on the first label. The first channel 140A includes a first set of two or more DL nodes of the DL network, e.g., DL nodes 109A-D and 109F. The flow of operations then moves to operation 208.

[0078] At operation 208, the second transaction 101B is recorded in a second private digital ledger 106B of a second channel 140B in the DL network 100. The second channel 140B includes a second set of one or more DL nodes 109E and 109F of the DL network 100 that is different from the first set of DL nodes 109A-D 109F. The second private digital ledger 106B is separate from the first DL network 106A. Thus, depending on the label that is associated with a transaction, the transaction is recorded in a different one of the first or the second private digital ledger 106B.

[0079] Fig. 2B illustrates a flow diagram of exemplary operations that can be performed for recording a transaction in a private digital ledger of a channel, in accordance with some embodiments. The flow of operations includes operations 222, 224, and 226. Each one of the operations 222, 224, and 226 can be performed for the first or the second transaction 101. In some embodiments, the operations of Fig. 2B can be performed by the transaction endorser 130.

[0080] At operation 222, the transaction endorser 130 determines, based on the label for the transaction 101, which one of the first and the second channels 140 is to be used for recording the transaction 101. In some embodiments, the transaction endorser 130 determines (operation 222A), based on the first label, that the first channel 140A is to be used for recording the first transaction 101A. In some embodiments, the transaction endorser 130 determines (operation 222B), based on the second label, that the second channel 140B is to be used for recording the second transaction.

[0081] At operation 224, the transaction endorser 130 invokes a smart contract 133 of a respective one of the first and the second channels 140 for validating the transaction. In some embodiments, the transaction endorser 130 invokes (operation 224B) a first smart contract 133A of the first channel 140A for validating the first transaction 101A. In some embodiments, the transaction endorser 130 invokes (operation 224B) a second smart contract 133B of the second channel 140B for validating the second transaction 101B.

[0082] At operation 226, the transaction endorser 130 transmits the transaction 101 to a set of DL nodes 109 of the respective one of the first and the second channels 140 to be added to a respective one of the first and the second private digital ledgers 106. In some embodiments, the transaction endorser 130 transmits (operation 226A) the first transaction 101 A to the first set of DL nodes 109 of the first channel 140A to be added to the first private digital ledger 106A. In other embodiments, the transaction endorser 130 transmits (operation 226B) the second transaction 101B to the second set of DL nodes 109 of the second channel to be added to the second private digital ledger 106B.

[0083] Fig. 2C illustrates a flow diagram of exemplary operations that can be performed for updating the label associated with an entry for the transaction, in accordance with some embodiments. In some embodiments, the DL network 100 may include the transaction label updater 180. In other embodiments, the DL network 100 may not include the transaction label updater 180. The transaction label updater 180 is operative to update the label associated with a transaction previously recorded in the DL network 100, e.g., in the first digital ledger 106A of the DL network 100, and update the entry associated with this transaction 101 in the transaction(s) history datastore 112A based on the new label.

[0084] At operation 232, based on a second classifier 110B, a determination that the second transaction 101B is to be associated with the first label instead of the second label is performed. In some embodiments, determining that the second transaction 101B is to be associated with the first label instead of the second label can be performed based at least in part on a time indicator of the second transaction 101B and one or more time indicators of one or more previous transactions for the same second participant.

[0085] In response to determining that the second transaction 101B is to be associated with the first label instead of the second label, an entry of the transaction history datastore 112A is updated for the second transaction 101B, where the second transaction 101B is associated with the first label instead of the second label.

[0086] At operation 238, the transaction history datastore 112A is used with the first classifier 110A for classifying a new transaction that is received in the DL network 100. In some embodiments, the new transaction can be for the second participant. In other embodiments, the new transaction can be for another participant that is different from the second participant. The classification of the new transactions is performed at least in part based on the updated entry of the transaction history datastore 112A for the second transaction 101B causing the new transaction to be processed based on the first label. At operation 240, the new transaction is recorded in the first private digital ledger 106A of the first channel 140A based on the first label.

[0087] Alternatively, upon determining, at operation 232, that the second transaction 101B is not to be updated to be associated with a different label, e.g., the first label instead of the second label, the flow of operations moves to operations 242-246.

[0088] In response to determining that the second transaction 101B is not to be associated with the first label, an entry of the transaction history datastore 112A is not updated for the second transaction 101B at operation 242.

[0089] At operation 244, the transaction history datastore 112A is used with the first classifier 110A for classifying a new transaction that is received in the DL network 100. In some embodiments, the new transaction can be for the second participant. In other embodiments, the new transaction can be for another participant that is different from the second participant. The classification of the new transactions is performed at least in part based on the entry of the transaction history datastore 112A for the second transaction 101B causing the new transaction to be processed based on the second label. At operation 246, the new transaction is recorded in the second private digital ledger 106B of the second channel 140B based on the second label.

Exemplary application:

[0090] The embodiments described herein can be used in multiple scenarios. In one embodiment, the system can be used to offer a billing service where transactions between multiple service providers and customers are recorded in the digital ledgers of the DL network. In these embodiments, the first label can indicate whether the transaction for a given service and a given customer is recurring and the second label can indicate whether the transactions for the given service and given customer is non-recurring.

[0091] In another example, the DL system 100 can be used in supply chains and logistics systems. In these systems, there are many different actors which include suppliers, transporters (i.e. tmck, train, plane), warehouses, customs, insurers, consolidators, buyers, etc. Each of these actors has a small piece of information about a shipment (i.e. first step/last step, and/or previous step/next step, and/or arrival/departure time, or product condition, etc.). As a result, significant problems can ensue if errors are made or bad actors become involved in a process. Key challenges for logistics and supply chains stem from a lack of process transparency, inefficient communication between the actors, and the inclusion of players that may not be trustworthy. Additional problems may include missed hand-offs, bad actors that steal products or money, lost records or paperwork, fraudulent or counterfeit products, weather delays, etc.

[0092] The use of the proposed DL network can handle the challenges in logistics and supply chains in an automated way by ensuring the security and transparency in the transactions. For example, the first label can indicate whether a participant in the DL network (e.g., one of the actors listed above) can be trusted, and the second label can indicate whether the participant in the DL network cannot be trusted. Therefore, the transactions of trusted parties are recorded in the first private digital ledger of the first channel while transactions of untrusted parties are recorded in the second private digital ledger of the second channel that is separate from the first private digital ledger and the first channel.

Architecture:

[0093] An electronic device stores and transmits (internally and/or with other electronic devices over a network) code (which is composed of software instructions and which is sometimes referred to as computer program code or a computer program) and/or data using machine-readable media (also called computer-readable media), such as machine-readable storage media (e.g., magnetic disks, optical disks, solid state drives, read only memory (ROM), flash memory devices, phase change memory) and 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). Thus, an electronic device (e.g., a computer) includes hardware and software, such as a set of one or more processors (e.g., wherein a processor is a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, other electronic circuitry, a combination of one or more of the preceding) coupled to one or more machine-readable storage media to store code for execution on the set of processors and/or to store data. For instance, an electronic device may include non-volatile memory containing the code since the non-volatile memory can persist code/data even when the electronic device is turned off (when power is removed), and while the electronic device is turned on that part of the code that is to be executed by the processor(s) of that electronic device is typically copied from the slower non-volatile memory into volatile memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)) of that electronic device. Typical electronic devices also include a set or one or more physical network interface(s) (NI(s)) to establish network connections (to transmit and/or receive code and/or data using propagating signals) with other electronic devices. For example, the set of physical NIs (or the set of physical NI(s) in combination with the set of processors executing code) may perform any formatting, coding, or translating to allow the electronic device to send and receive data whether over a wired and/or a wireless connection. In some embodiments, a physical NI may comprise radio circuitry capable of receiving data from other electronic devices over a wireless connection and/or sending data out to other devices via a wireless connection. This radio circuitry may include transmitter(s), receiver(s), and/or transceiver(s) suitable for radiofrequency communication. The radio circuitry may convert digital data into a radio signal having the appropriate parameters (e.g., frequency, timing, channel, bandwidth, etc.). The radio signal may then be transmitted via antennas to the appropriate recipient(s). In some embodiments, the set of physical NI(s) may comprise network interface controller(s) (NICs), also known as a network interface card, network adapter, or local area network (LAN) adapter. The NIC(s) may facilitate in connecting the electronic device to other electronic devices allowing them to communicate via wire through plugging in a cable to a physical port connected to a NIC. One or more parts of an embodiment of the disclosure may be implemented using different combinations of software, firmware, and/or hardware.

[0094] A network device (ND) is an electronic device that communicatively interconnects other electronic devices on the network (e.g., other network devices, end-user devices). Some network devices are “multiple services network devices” that provide support for multiple networking functions (e.g., routing, bridging, switching, Layer 2 aggregation, session border control, Quality of Service, and/or subscriber management), and/or provide support for multiple application services (e.g., data, voice, and video, etc.). In the embodiments described above the components of the DL network 100 can be implemented on one or more network devices coupled through a physical network. For example, each of the participant nodes 102A-N, participant nodes 102Q-R, and DL nodes 109A-G can be implemented on one ND or distributed over multiple NDs.

[0095] Fig. 3 illustrates a block diagram for a network device that can be used for implementing one or more of the DL nodes 109 or the participant nodes 102 described herein, in accordance with some embodiments. According to one embodiment, the network device is an electronic device which includes hardware 305. Hardware 305 includes one or more processors 314, network communication interfaces 360 coupled with a computer readable storage medium 312. The computer readable storage medium 312 may include a computer program 311.

[0096] While one embodiment does not implement virtualization, alternative embodiments may use different forms of virtualization - represented by a virtualization layer 320. In these embodiments, the node instance 340 and the hardware that executes it form a virtual server which is a software instance of the modules stored on the computer readable storage medium 312.

[0097] The computer program 311 includes instructions which when executed by the hardware 305 causes the node instance 340 to perform the operations described with reference to Figs. 1A-2C. In this embodiment, each of one or more of the DL nodes 109A- G or the participant nodes 102A-N, or 102Q-R is implemented on a single network device. [0098] Fig. 4 illustrates an exemplary embodiment in which a node is implemented on multiple network devices. In the illustrated example, the node 409 is distributed over multiple network devices 430A-430K, where each network device has a similar architecture as network device 330. The multiple network devices 430A-430K are coupled through one or more links and can be located in a same geographical location or remote from one another. The operations described with reference to the embodiments of Figs. 1 A-2C can be distributed over the multiple network devices, such as each network device is operative to perform a subset of the operations described herein. In some embodiments, each of one or more of the DL nodes 109A-G or the participant nodes 102A-N, or 102Q-R can be implemented as the node 409. [0099] While the flow diagrams in the figures show a particular order of operations performed by certain embodiments of the disclosure, 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.).

[00100] While the disclosure has been described in terms of several embodiments, those skilled in the art will recognize that the disclosure is not limited to the embodiments described, can be practiced with modification and alteration within the spirit and scope of the appended claims. The description is thus to be regarded as illustrative instead of limiting.