WO2021096400A1 - Procédé de séparation d'un état privé et de transactions privées d'un état agrégé et de transactions agrégées dans un réseau de registre distribué - Google Patents

Procédé de séparation d'un état privé et de transactions privées d'un état agrégé et de transactions agrégées dans un réseau de registre distribué Download PDF

Info

Publication number
WO2021096400A1
WO2021096400A1 PCT/SE2019/051147 SE2019051147W WO2021096400A1 WO 2021096400 A1 WO2021096400 A1 WO 2021096400A1 SE 2019051147 W SE2019051147 W SE 2019051147W WO 2021096400 A1 WO2021096400 A1 WO 2021096400A1
Authority
WO
WIPO (PCT)
Prior art keywords
private
transactions
transaction
state
subset
Prior art date
Application number
PCT/SE2019/051147
Other languages
English (en)
Inventor
Remi ROBERT
Aleksandra OBESO DUQUE
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to PCT/SE2019/051147 priority Critical patent/WO2021096400A1/fr
Publication of WO2021096400A1 publication Critical patent/WO2021096400A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the present disclosure relates to the field of distributed ledger technology networks; and more specifically, to separating a private state and private transactions from an aggregate state and aggregate transactions in a distributed ledger network.
  • DLT Distributed ledger technology
  • a digital ledger permanently records digital records of transactions that occur between two participants. The records cannot be altered retroactively without the alteration of all subsequent transactions in the digital ledger and without consensus from multiple nodes in the network. Recordation of transactions in the digital ledger allows the participants to verify and audit transactions inexpensively and securely.
  • a digital ledger is maintained without a central authority or implementation.
  • the digital ledger can be a blockchain that includes blocks secured and linked to one another using cryptographic mechanisms.
  • 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 DL e.g., a blockchain
  • the DL is decentralized meaning no entity has control over the DL network, ensuring the data can’t be changed once validated on the DL.
  • public DL networks anyone, anywhere, can use the DL network to input transactions and data.
  • 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.
  • private DL networks In private DL networks, several features have been developed to allow to expose data to only a subset of the participants in the DL networks.
  • some DL networks it is possible to disclose a private transaction to only some of the participants in the network.
  • the disclosure of the private transaction to some of the participants can be achieved as follows: instead of broadcasting the transaction to all participants, the transaction is only sent to a subset of the participants that will be tasked with executing the transaction.
  • the transaction payload is not stored in the DL datastore, instead only an identifier of the transaction is recorded in the DL datastore, and the actual payload of the transaction is maintained by a transaction manager for each participant.
  • a payload of the transaction contains the actual details about the transaction (e.g., amount transferred from one participant to another participant, etc.).
  • nodes of the DL network may maintain two databases: a public database that stores the public state of the DL network (accessible by all the participants of the DL network) and one that contains the private state originating from private transactions that they were granted access to (called here the private database).
  • a node that stores a private state generates this private state by executing private transactions.
  • the private state can include the balance of accounts of some participants, where the node is allowed to view and access these accounts.
  • a host DL node might be responsible for storing the private transaction payloads related to several participants. In such a situation, the private transaction payloads from all of these users gets stored indistinctively of the participant they belong to in a transaction manager.
  • a participant that relies on another DL node for storing its private data may decide to setup their own DL node or transfer delegation to a third DL node in the network and stop relying on the other DL storing the private data.
  • the node, to which storage of private data was delegated needs to securely transmit the private data to the participant’s node or to the new host while ensuring privacy of other participants.
  • the embodiments described herein present a solution for separating a private state and private transactions from an aggregate state and aggregate transactions in a distributed ledger network.
  • the solution offers the advantage of allowing a user to securely transfer ownership of its private data, which includes the private transactions and the private state resulting from execution of these private transactions, from one DL node to another DL node.
  • the solution presented herein offers the additional advantage of accelerating the extraction process of the private transactions and the private state using data cached during the transaction evaluation process.
  • One general aspect includes a method in a node of a distributed ledger network, where the node includes a private state of the distributed ledger network that is generated based on one or more private transactions that are accessible to one or more participants but not to all participants in the distributed ledger network, the method including: identifying for a first participant in the distributed ledger network a first subset of the private transactions that includes an initial private transaction that was recorded in a digital ledger of the distributed ledger network for the first participant before any other private transaction was recorded for the first participant and the first subset of the private transactions further includes zero or more additional private transactions that were recorded in the digital ledger for the first participant and zero or more other participants after the initial private transaction; generating first and a second copy of the private state to include a state of the distributed ledger network up to a last transaction before the initial private transaction for the first participant; updating the first copy of the private state based on a second subset of the first subset of the private transactions that includes transactions that are accessible to the first participant to obtain a first private state of
  • One 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 private state of the distributed ledger network that is generated based on one or more private transactions of one or more participants that are accessible to the one or more participants but not to all participants in the distributed ledger network, and a set of computer readable instructions that when executed by the one or more processors cause the node to identify for a first participant in the distributed ledger network a first subset of the private transactions that includes an initial private transaction that was recorded in a digital ledger of the distributed ledger network for the first participant before any other private transaction was recorded for the first participant and the first subset of the private transactions further includes zero or more additional private transactions that were recorded in the digital ledger for the first participant and zero or more other participants after the initial private transaction; generate a first and a second copy of the private state to include a state of the distributed ledger network up to a last transaction before the initial private transaction for the first participant; update the first copy
  • Fig. 1 illustrates a block diagram of an exemplary private DL network, in accordance with some embodiments.
  • FIG. 2A illustrates a flow diagram of exemplary operations that can be performed for transmitting private transaction data to a participant of the DL network, in accordance with some embodiments.
  • Fig. 2B illustrates a flow diagram of exemplary operations that can be performed for identifying for a participant in the DL network a first subset of the private transactions, in accordance with some embodiments.
  • FIG. 2C illustrates a flow diagram of exemplary operations that can be performed for identifying for a participant in the DL network a first subset of the private transactions, in accordance with some embodiments.
  • Fig. 2D illustrates a flow diagram of exemplary operations that can be performed for generating a first and a second copy of the private state to include a state of the DL network up to a last transaction before the initial transaction for the first participant, in accordance with some embodiments.
  • Fig. 2E illustrates a flow diagram of exemplary operations that can be performed for updating the first and the second copy of the private state, in accordance with some embodiments.
  • Figure 2F illustrates a flow diagram of exemplary operations that can be performed for transmitting the private data to the first participant, in accordance with some embodiments.
  • Fig. 3 illustrates a block diagram for a network device that can be used for implementing one or more of the DLT nodes described herein, in accordance with some embodiments.
  • Fig. 4 illustrates a block diagram for network devices that can be used for implementing a DLT node described herein, in accordance with some embodiments.
  • 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.
  • Bracketed text and blocks with dashed borders 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.
  • 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.
  • the DL node that hosts the private data on behalf of the participant would not be acceptable for the DL node that hosts the private data on behalf of the participant to give all the data that it stores to the participant, as this is likely to disclose information that the participant is not allowed to access.
  • the DL node stores private transactions from multiple participants
  • the private state of the DL node results from private transactions of these multiple participants, therefore if the DL node were to send this private state to the participant, the participant would receive a private state that results from private transactions that it is not allowed to access (e.g., private transactions of other participants).
  • the private transactions of a participant are stored encrypted, and the decryption key might be protected by a secret held by the hosting DL node.
  • the hosting DL node in addition to separating the private data belonging to the participant, the hosting DL node also needs to adapt the encryption so that the participant can read and access its private transactions without being able to access private data of other participants that it does not have access to.
  • the embodiments described herein present a method and a node of a DL network for separating a private state in a DL network from other private states.
  • the node includes the private state that is generated based on one or more private transactions that are accessible to the one or more participants but not to all participants in the DL network.
  • a first subset of the private transactions is identified for a first participant in the DL network.
  • the first subset of the private transactions includes an initial private transaction that was recorded in an immutable record of the DL network for the participant before any other private transaction was recorded for the first participant and the first subset of the private transactions further includes zero or more additional private transactions that were recorded in the digital ledger for the first participant and zero or more other participants after the initial private transaction.
  • a first and a second copy of the private state are generated to include a state of the DL network up to a last transaction before the initial private transaction for the first participant. Payloads of the first subset of the privates transactions are retrieved.
  • the first copy of the private state is updated based on a second subset of the first subset of the private transactions that includes transactions that are accessible to the first participant to obtain a first private state of the DL network.
  • the second copy of the private state is updated based on a third subset of the first subset of the private transactions that are accessible any of the other participants to obtain a second private state of the DL network.
  • the second subset of the private transactions and the first private state of the distributed ledger network are securely transmitted to a node of the first participant.
  • the node of the participant can be owned and operated uniquely by and for the participant.
  • the node of the participant can be another host DL node that is operative to store private transactions data of the participant on behalf of the participant and private transaction data of one or more other participants.
  • the solution presented herein allows a participant of a DL network, which relied on a host node to store its private data, to securely transfer ownership of its private data from the host node to another node. Further, the transfer of the private data can be accelerated by generating an index of private transactions during the normal operations of the host DL node. In addition, the generation of a private state for the participant can also be accelerated by storing a history of states for multiple participant.
  • Fig. 1 illustrates a block diagram of an exemplary private DL network, in accordance with some embodiments.
  • DL networks namely the blockchain networks.
  • the embodiments described herein generally apply to other types of DL networks, which will not necessarily be named herein.
  • the DL network 100 includes a set of DL nodes 102A-N.
  • the DL network 100 is also in communication with one or more nodes, e.g., node 102C and node 102D, that are used by one or more participants of the DL network 100.
  • the various nodes communicate through a physical network (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.
  • the DL network 100 is operative to enable participants to have access to public data that all participants can view.
  • the DL network 100 is a blockchain network.
  • the nodes 102A-N may be permissioned to join the DL network 100 via, for example, an access control list.
  • the access control list can be managed by smart contract.
  • 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., nodes 102B, 102B, 102C, and 102D) that is used to access the DL network 100.
  • the node of the participant can be a DL node, e.g., DL node 102B or DL node 102N, or a simple node that is not part of the DL network 100.
  • the node of the participant When the node of the participant is not part of the DL network, e.g., node 102C, the node is operative to access the DL network 100 and delegate handling of its private data to a host DL node, e.g., host DL node 102 A.
  • a host DL node e.g., host DL node 102 A.
  • a DL node is a node that is operative to perform some, or all operations related to updating and maintaining the digital ledger.
  • a DL node can be a full node that stores the entire Digital ledger.
  • the DL node can be a light node, which may include only a partial list of the digital ledger.
  • the DL node may further be operative to receive transactions from nodes of participants, 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 consensus algorithm such as Proof Of Work (PoW), Proof of Stake (PoS), or other).
  • the DL network 100 includes a DL node 102A that is operative to host private data of one or more participants on behalf of these participants.
  • the DL node 102A can store the private data of the first participant 103C.
  • DL node 102A can also store the private data of one or more additional nodes such as node 102D and/or DL node 102B.
  • DL node 102A can store data of participants, which don’t have nodes on the DL network. Additionally or alternatively, DL node 102A can store data of participants which may have a node on the DL network.
  • the multiple nodes in the DL network 100 are operative to communicate and exchange messages through one or multiple communications protocols (e.g., Layer 7 to Layer 2 protocols).
  • DL node 102A includes a digital ledger 110 A, a DL network state(s) 120 A, a transaction manager 140 A, and optional index of private transactions datastore 130A and history of states 150.
  • the digital ledger e.g., digital ledger 110 A
  • the digital ledger 110 A is a complete list of every single transaction that has occurred on the DL network 100. Once transactions are written to the digital ledger 110A, they cannot be modified; the record of transactions (i.e., the digital ledger 110A) is immutable.
  • node 102A is illustrated as including digital ledger 110A, one or more other DL nodes, e.g., DL node 102B, may include a copy of all or a portion of the digital ledger 110A.
  • Digital ledger 110A includes private transactions 112A-0 and public transactions 114Q-P.
  • the public transactions 114Q-P are a subset of all public transactions that may be included in the digital ledger.
  • a public transaction is a transaction that is available to be viewed by all of the participants of the DL network 100.
  • a private transaction is only available to be viewed by some of the participants but not by all of the participants of the DL network 100.
  • the private transactions 112A-0 are a subset of all private transactions that may be included in the digital ledger 110 A.
  • each one of the private transactions 112A-0 and the public transactions 114Q-P may include a participant’s ID, 132A- P and transaction data 133A-P.
  • the participant ID is a field that identifies the participant in the DL network 100.
  • the first participant 103C may be identified with P_ID_1 that is recorded in the digital ledger with the first private transaction 112A.
  • the transaction data 133A-P includes one or more field values that define the transaction.
  • an identifier of each private transaction is stored in the transaction data instead of the payload of the transaction.
  • the payload of a transaction contains the actual details about the transaction. This ensures that the payload of any private transaction is not accessible to participants that are not recipients of the transactions.
  • the identifier of the transaction can be a hash of the payload of the transactions.
  • a recipient of the transaction refers to a participant of the DL network that is allowed to have access/view a private transaction.
  • a private transaction 112A-0 can have one or more recipients.
  • the digital ledger 110A stores the payload of the transactions consequently allowing any participant of the DL network 100 to access/view the payload of these public transactions by accessing the digital ledger 110A. While not illustrated in Fig. 1, each transaction (public or private) recorded in the digital ledger may further include additional fields.
  • the digital ledger 110A can be a blockchain.
  • transactions are collected inside blocks, e.g., block 111 A-S, that are appended to the blockchain.
  • each block may include additional fields (e.g., a block header) .
  • the digital ledger 110A can be another structure different from the blockchain that is operative to store private and public transactions.
  • the DL node 102A includes DL network 100 states 120A.
  • DL network 100 states 120A may include a private state 123 A and a public state 124 A.
  • 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 allows to directly access the current value of an entry rather than having to calculate it by traversing the entire digital ledger.
  • 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 110A to date.
  • the state can change frequently, as transactions are added in the digital ledgerllOA.
  • the state of the DL network 100 is segmented into two states: private state 123A and public state 124A.
  • the public state 124A results from the evaluation of the public transactions that are stored in the digital ledger 110A.
  • the public state is in synchronization with public states of other DL nodes in the DL network 100.
  • the private state 123 A results from evaluation of the private transactions that the DL node 102A is allowed to access/view.
  • the private state 123 A can result from private transactions of which the DL node 102A is a direct recipient as well as from private transactions of which one or more other participants are the direct recipients but have delegated the handling of their private data to the host DL node 102A.
  • the private state 123A can also result from transactions of which the first participant 103C is a recipient and which has delegated the storage of its private transactions to the DL node 102A.
  • the private state 123 A is only stored on the DL node 102A.
  • the private state 123A can also be stored on one or more additional DL nodes 102A but not on all of the DL nodes.
  • the private state 123 A can be referred to as an aggregate state that results from private transactions of the first participant as well as other private transactions of other participants.
  • the DL node 102A may further include a history of states 150.
  • the history of states 150 is a datastore that is used to store a history of the states for the multiple private participants that have a state maintained in the private state 123 A.
  • the history of states allows to quickly retrieve a past state of the private state 123 A.
  • the history of states 150 can be a database that contains copies of the private state as it was after the processing of each private transaction. Each copy can be indexed by the identifier of the private transaction that led to that state.
  • the history of states is not included in the DL node 102A.
  • the DL node 102 A includes an index of private transactions datastore 130A.
  • the index of private transactions datastore 130A may store all private transactions for each participant. Alternatively, the index of private transactions datastore 130A may store only the initial private transaction for each participant.
  • DL node 102A may add to the datastore 130A data for only a subset of the participant that have delegated handling of their private data to DL 102A.
  • the initial private transaction for a participant is the first private transaction recorded in the digital ledger 110A in a chronological order of which the participant is a recipient.
  • the index of private transactions datastore 130A stores the transaction IDs 133A- M, the list of participants that are recipients of this transactions (137A-M), and the time indicator 131A-M, which indicates the time at which the transaction was recorded in the digital ledger 110A.
  • the participant ID in the index of private transaction datastore 130A indicates that the participant is a recipient of the private transaction, i.e., the participant is able to view/access the transaction.
  • the use of the index of private transactions datastore 130A accelerates the operations of identifying a first subset of private transactions for a participant. Instead of having to scan all of the transactions present in the digital ledger to identify these transactions, the index allows the quick retrieval of these transactions.
  • the DL node 102A further includes a transactions manager 140A, which is the component tasked with securely storing the private transactions hosted by the node 102A.
  • the transaction manager 140 A includes the encrypted payloads of the private transactions 141 A.
  • the payloads are encrypted based on a private key 144A of the transaction manager 140 A.
  • the transaction manager 140A may also include payloads of the public transactions 142A (which may be encrypted or not).
  • the transaction manager 140 A only includes the encrypted payloads of the private transactions and not the payloads of the public transactions.
  • DL node 102A is operative to receive a request for retrieval of private data of a first one of the participants 103B-N and respond to this request by transmitting a current state of the first participant and private transactions of which the first participant is a recipient. This causes the DL node 102A to cease operation as a host of private data for the first participant 103C in the DL network 100. The following operations are performed to enable the DL node 102A to separate the participant’s private data and transmit them to the participant. At operation 1 (circle 1 in Fig. 1), the DL node 102A receives a request for private data retrieval for the first participant 103C.
  • the request can be received from a node of the first participant (e.g., node 102C). In another embodiment, the request can be received from a node of the first participant or alternatively from another node to which access to the private data of the first participant has been granted.
  • the request can include an indication of where the private data is to be transmitted.
  • the request may include an indication that the private data is to be transmitted to the node of the first participant, node 102C, or alternatively to another host DL node (not illustrated) that is to store the private data on behalf of the first participant 103C instead of the DL node 102A.
  • DL node 102A may not receive a request for data retrieval but may determine through an internal mechanism (e.g., timeout of a timer associated with the first participant, or expiration of a hosting service contract, load balancing mechanism, etc.) that the process of retrieval of the private data of the first participant 103C is to be initiated.
  • an internal mechanism e.g., timeout of a timer associated with the first participant, or expiration of a hosting service contract, load balancing mechanism, etc.
  • DL node 102A identifies for the first participant 103C a first subset of the private transactions.
  • the identification of the first subset of the private transactions includes determination of a first subset of transaction identifiers.
  • Each transaction identifier (ID) of the first subset of transaction identifiers uniquely identifies the transaction in the DL network 100.
  • a transaction identifier can be a hash of a payload of the transaction.
  • the first subset of the private transactions includes an initial private transaction that was recorded in the digital ledger 110A of the DL network for the first participant 103C before any other private transaction was recorded for the first participant. Thus, there are no other private transactions of which the first participant 103C is the recipient that are recorded in the digital ledger before the initial transaction.
  • the initial private transaction e.g., private transaction 112A
  • the initial private transaction can be included in a block, e.g., block 111 A, of the blockchain and no other block that precedes this block in the blockchain includes a private transaction that has the first participant 103C as a recipient.
  • the first subset of the private transactions may also include additional private transactions that were recorded in the digital ledger 110A for the first participant 103C and other participants after the initial private transaction. These additional private transactions are accessible by the DL node 102A (i.e., the DL node 102A is allowed to view, store these transactions on behalf on one or more participant in the DL network).
  • the initial private transaction is the only private transaction that is stored in the digital ledger that the DL node 102A can access, in this case the first subset of private transactions include only the initial transaction.
  • the DL node 102A may have access to one or more additional private transactions (of which the first participant 103C is a recipient or of which other participants are the recipients) that were stored in the digital ledger 110A after the initial private transaction, in this case, the first subset of private transactions includes the initial private transaction and at least an additional private transaction.
  • the additional private transaction can have the first participant 103C as a recipient, one or more other participants as recipients, or a combination of the first participant 103C and the other participants as recipients.
  • the identification of the first subset of private transactions can be performed as described with reference to Fig. 2B, by using the digital ledger 110A (circled reference 2a).
  • the identification of the first subset of private transactions can be performed as described with reference to Fig. 2C, by using the index of private transactions datastore 130A (circled reference 2b).
  • DL node 102A retrieves payloads of the first subset of the private transactions.
  • the payloads of the transactions are stored in the transaction manager 140A and are retrieved from the transaction manager 140A based on their transaction identifiers.
  • the transaction manager 140A may store the payloads as values of key- value pairs, where the keys are the transaction IDs.
  • operation 3 includes decrypting encrypted payloads of the first subset of the private transactions to obtain the payloads. The decryption of the payloads is performed with a private key 144A of the private transaction manager.
  • DL node 102A generates a first and a second copy of the private state to include a state of the DL network 100 up to a last transaction before the initial private transaction for the first participant.
  • DL node 102A determines a private state of the DL network that results from all private transactions that the DL node 102A has access to from the beginning of the digital ledger (e.g., from the genesis block when the digital ledger is a blockchain) until the last private transaction that immediately precedes the initial private transaction for the first participant.
  • Two copies of this private state are generated (first copy and second copy, which are not illustrated in Fig. 1), which are to be used to generate the first private state 125A and the second private state 127A as described in further details below.
  • the generation of the first and second copy of the private state can be performed as described with reference to Fig. 2D.
  • DL node 102A updates the first copy of the private state based on a second subset of the first subset of the private transactions that includes transactions that are accessible to the first participant 103C to obtain a first private state of the DL network 100.
  • the first private state 125A is a datastore representing the current states in the DL network 100 that reflects the effect of the private operations of the first participant. This first state 125A excludes effects by other private transactions of which the first recipient is not a recipient.
  • the private transactions that have the first participant 103C as a recipient can have one or more other participants as recipients.
  • the first private state 125 A is generated by reprocessing each of the second subset of the first subset of the private transactions and starting from the first copy of the private state determined.
  • the payloads of these transactions which are a subset of the transactions retrieved at operation 3, are used during the reprocessing to determine the first private state 125 A.
  • DL node 102A updates the second copy of the private state based on a third subset of the first subset of the private transactions that are accessible to any of the other participants to obtain a second private state of the DL network 100; and the DL node 102A generates the second private state 127 A.
  • the second private state 127A is a datastore representing the current states in the DL network 100 that reflects the effect of the private transactions of participants.
  • the participants include participants that are different from the first participant 103C as well as potentially the first participant. For example, when a private transaction of which the first participant 103C is a recipient also has another participant as a recipient, this transaction is also considered when determining the private state 127A.
  • the second state 127A considers effects by other private transactions of which the first recipient is not a recipient, the second state 127 A may further be determined by private transactions of which the first recipient is a recipient (which may include the initial private transaction of the first participant).
  • the second private state 127A is generated by reprocessing each of the third subset of the first subset of the private transactions and starting from the second copy of the private state determined.
  • the payloads of these transactions which are a subset of the transactions retrieved at operation 3, are used during the reprocessing to determine the second private state 127 A.
  • DL node 102A securely transmits the second subset of the first subset of the private transactions and the first private state of the DL network 100 to another node.
  • the other node is a node of the first participant, e.g., node 102C.
  • the other node is a node that is to act as a host for the private transactions of the first participant 103C and is not a node of the first participant.
  • This other node is authorized by the first participant 103C to host the private transactions of the first participant 103C and belongs to a third party, which is also a participant in the DL network 100.
  • the secure transmission of the second subset of the first subset of the private transactions and the first private state may include encrypting the first private state, the second subset of the first subset of the private transactions, or a combination of the first private state and the second subset of the first subset of the private transactions before being transmitted.
  • the encryption can be performed based on a shared secret key between the DL node 102A and the receiving node (e.g., node 102C) or a public key of the receiving node.
  • Fig. 2A illustrates a flow diagram of exemplary operations that can be performed for transmitting private transaction data to a participant of the DL network, in accordance with some embodiments.
  • the operations of Fig. 2A can be performed by a DL node of the distributed ledger 100, e.g., DL node 102A.
  • the DL node operates on behalf of one or more participants in the DL network and can be referred to as a host DL node.
  • the DL node may operate on behalf of a first participant.
  • the DL node 102A may receive a request for private data retrieval for a first participant 103C in the DL network 100.
  • the request can provide from a node of the first participant 103C (e.g., node 102C).
  • the request can be received from another node to which access to the private data of the first participant has been granted.
  • the request can include an indication of where the private data is to be transmitted.
  • the request may include an indication that the private data is to be transmitted to the node of the first participant 103C, node 102C, or alternatively to another host DL node (not illustrated) that is to store the private data on behalf of the first participant 103C instead of the DL node 102A.
  • DL node 102A may not receive a request for data retrieval but may determine through an internal mechanism (e.g., timeout of a timer associated with the first participant, or expiration of a hosting service contract, load balancing mechanism, etc.) that the process of retrieval of the private data of the first participant 103C is to be initiated. [0052] The flow of operations then moves to operation 204.
  • DL node 102A identifies for a first participant 103C in the DL network 100 a first subset of the private transactions. The identification of the first subset of the private transactions includes determination of a first subset of transaction identifiers.
  • Each transaction identifier (ID) of the first subset of transaction identifiers uniquely identifies the transaction in the DL network 100.
  • a transaction identifier can be a hash of a payload of the transaction.
  • the first subset of the private transactions includes an initial private transaction that was recorded in the digital ledger 110A of the DL network 100 for the first participant 103C before any other private transaction was recorded for the first participant. Thus, there are no other private transactions of which the first participant 103C is the recipient that are recorded in the digital ledger 110A before the initial transaction.
  • the initial private transaction can be included in a block of the blockchain and no other block that precedes this block in the blockchain includes a private transaction that has the first participant 103C as a recipient.
  • the first subset of the private transactions may also include additional private transactions that were recorded in the digital ledger 110A for the first participant 103C and other participants after the initial private transaction. These additional private transactions are accessible by the DL node 102A (i.e., the DL node 102A is allowed to view, store these transactions on behalf on one or more participant in the DL network 100).
  • the initial private transaction is the only private transaction that is stored in the digital ledger 110A that the DL node 102A can access, in this case the first subset of private transactions include only the initial transaction.
  • the DL node 102A may have access to one or more additional private transactions (of which the first participant 103C is a recipient or of which other participants are the recipients) that were stored in the digital ledger 110A after the initial private transaction, in this case, the first subset of private transactions includes the initial private transaction and at least an additional private transaction.
  • the additional private transaction can have the first participant 103C as a recipient, one or more other participants as recipients, or a combination of the first participl03C ant and the other participants as recipients.
  • operation 204 can be performed as described with reference to Fig. 2B.
  • operation 204 can be performed as described with reference to Fig. 2C.
  • Fig. 2B illustrates a flow diagram of exemplary operations that can be performed for identifying a first subset of the private transactions for a first participant 103C in the DL network 100, in accordance with some embodiments.
  • DL node 102A is to identify the private transactions for the first participant 103C by scanning, at operation 222, the digital ledger 110A to identify the initial private transaction for the first participant 103C and the zero or more additional private transactions.
  • the additional private transactions are transactions that have the first participant 103C as a recipient and/or private transactions that were recorded in the digital ledger 110A after the initial private transaction for the first participant.
  • Several mechanisms can be used for scanning the digital ledger 110A and identifying the first subset of private transactions.
  • the digital ledger 110A can be scanned in a chronological order starting from the first transactions recorded in the digital ledger 110A.
  • the digital ledger 110A can be scanned in a reverse chronological order such that the latest recorded transactions are scanned first.
  • the digital ledger is a blockchain and scanning the digital ledger includes scanning the multiple blocks that form the blockchain to identify the first subset of private transactions.
  • the scanning of the blockchain includes operations 221, 223, 227, 229, 231, 233, 235, and 237.
  • the determination of identifiers of private transactions includes determining from transactions included in the block, which ones are private. This can be performed by determining that the payload of the transaction is replaced with a hash of the payload. Additionally or alternatively, this can be performed by determining that a field of the transaction indicates that the transaction is private.
  • a public transaction In contrast to a private transaction, a public transaction has a field indicating that the transaction is public and/or includes the payload of the transaction. The flow of operations then moves to operation 223.
  • DL nodel02A determines based on an identifier of a private transaction whether the private transaction is stored in the transaction manager 140A.
  • the identifier of the private transaction can be a hash of the payload of the private transaction (operation 225).
  • the identifier of the private transaction can be different than the hash of the payload of the private transaction (e.g., the identifier of the private transaction can be a string determined based on the participant identity and a nonce or a hash function applied twice to the payload of the private transaction, etc.).
  • the presence of an identifier of a private transaction in the transaction manager 140A is an indication that DL 102A has access to the private transaction (i.e., is able to view/ access the payload of the private transaction).
  • the presence of the identifier of a private transaction in the transaction manager 140A can be a result of DL node 102A being a host DL node for the participant that is the recipient of this transaction and indicates that the DL node 102A is allowed to store and handle this private transaction on behalf of the participant.
  • the presence of the identifier of a private transaction in the transaction manager 140A can be a result of DL node 102A being a recipient of the private transaction.
  • operation 223 is repeated for the next private transaction in the block.
  • the identifier of the private transaction is not present in the transaction manager 140 A, it is an indication that DL node 102A is not authorized to view the private transaction and has not access to the payload of the private transaction.
  • the flow of operations moves to operation 227.
  • the identifier of the private transaction is present in the transaction manager 140A, it is an indication that DL node 102A is authorized to view the private transaction and has access to the payload of the private transaction.
  • DL node 102A retrieves the payload of the private transaction from the transaction manager 140A. In some embodiments, the operation 227 can be skipped and the retrieval of the payloads of the private transactions can be performed following the identification of the first subset of private transactions (at operation 206). The flow of operations moves to operation 229.
  • DL node 102A determines whether the initial private transaction for the first participant 103C was already found or if the first participant 103C is a recipient of private transaction. If it is determined that the initial private transaction has been determined or that the current private transaction being processed has the first participant 103C as a recipient, the flow of operations moves to operation 233.
  • the private transaction is added to the first subset of private transactions.
  • the flow of operations then moves to operation 231.
  • operation 231 a determination of whether there are more private transactions in the block is performed.
  • the flow of operations moves to operation 223 and the process is repeated for a next private transaction in the block.
  • operation 235 a determination of whether all blocks have been processed is performed.
  • the flow of operations moves to operation 221, at which a next block is processed and operations 223-235 are repeated.
  • the flow of operations moves to operation 237, at which the first subset of private transactions for the first participant 103C is output.
  • the first subset of private transactions include identifiers of private transactions.
  • the first subset of private transactions may include identifiers of the private transactions as well as the payloads of the private transactions.
  • 2C illustrates a flow diagram of exemplary operations that can be performed for identifying for a participant in the DL network 100 a first subset of the private transactions, in accordance with some embodiments.
  • the use of the index of private transactions datastore 130A accelerates the operations of identifying a first subset of private transactions for a participant. Instead of having to scan all of the transactions present in the digital ledger 110A to identify these transactions, the index allows the quick retrieval of these transactions by a lookup in the datastore of private transactions that are associated with the identifier of the participant.
  • the identification of the first subset of private transactions for the first participant 103C may include operation 224.
  • the DL node 102A determines the first subset of the private transactions from an index of private transactions datastore, e.g., index of private transactions datastore 130A.
  • the index of private transactions datastore includes for each private transaction of a fourth subset of private transactions an identifier of the private transaction, one or more identifiers of participants that can access the private transaction, and a time indicator for the private transaction that indicates a time at which the private transaction is added to the immutable record.
  • the fourth subset of private transactions may include all of the private transactions that the DL node 102A stores in the transaction manager 140 A.
  • the DL node 102A is operative to retrieve from the index 130A, the initial transaction for the first participant 103C and the time indicator associated with the initial transaction. Based on the time indicator, the DL node 102A is operative to retrieve from the index 130A all private transactions that succeed the initial private transaction (i.e., that have a time indicator indicating that the transaction was recorded after the initial private transaction for the first participant).
  • the index of private transactions datastore stores only initial private transactions for each of the participants.
  • the DL node 102A retrieves the initial private transaction for the first participant 103C from the index 130A and determines the private transactions that succeed the initial private transaction in chronological order from a combination of the digital ledger 110A and the transaction manager 140A.
  • the index of the private transactions datastore 130A stores all private transactions for each of the participants.
  • the DL node 102A is operative to retrieve the initial private transaction for the first participant 103C and based on the time indicator associated with the initial private transaction can retrieve all subsequent private transactions to include in the first subset of the private transactions.
  • operation 206 DL node 102A retrieves payloads of the first subset of the private transactions.
  • the payloads of the transactions are stored in the transaction manager 140A and are retrieved from the transaction manager 140A based on their transaction identifiers.
  • the transaction manager 140A may store the payloads as values of key-value pairs, where the keys are the transaction IDs.
  • operation 206 includes decrypting, at operation 207, encrypted payloads of the first subset of the private transactions to obtain the payloads. The decryption of the payloads is performed with a private key 144A of the private transaction manager.
  • DL node 102A generates a first and a second copy of the private state to include a state of the distributed ledger network up to a last transaction before the initial private transaction for the first participant.
  • DL node 102A determines a private state of the DL network 100 that results from all private transactions that the DL node 102 A has access to from the beginning of the digital ledger 110A (e.g., from the genesis block when the digital ledger is a blockchain) until the last private transaction that immediately precedes the initial private transaction for the first participant.
  • Two copies of this private state are generated to (first copy and second copy, which are not illustrated in Fig. 1), which are to be used to generate the first private state 125 A and the second private state 127A as described in further details below.
  • operation 208 can be performed as described with reference to Fig. 2D.
  • Fig. 2D illustrates a flow diagram of exemplary operations that can be performed for generating a first and a second copy of the private state to include a state of the distributed ledger network up to a last transaction before the initial transaction for the first participant, in accordance with some embodiments.
  • generating the first and the second copy of the private state to include the state of the DL network 100 up to a last transaction before the initial private transaction for the first participant includes operation 232.
  • DL node 102A re processes transactions from the digital ledger 110A of the DL network 100 up to a last transaction before the initial private transaction for the first participant. The re-processing of the transactions is performed by executing or evaluating the payloads of all private transactions retrieved from the transaction manager 140A.
  • generating the first and the second copy of digital ledger 110A the private state to include the state of the DL network 100 up to a last transaction before the initial private transaction for the first participant 103C may include operation 234.
  • DL node 102A may retrieve a state from a cache that stores intermediary states of the DL network 100 that corresponds to a state up to a last transaction before the initial private transaction for the first participant.
  • DL node 102A may retrieve from history of states 150 the private state of the DL network 100 that corresponds to the state that results from all private transactions that the DL node 102A has access to and which occurred before the initial state of the first participant.
  • DL node 102A updates the first copy of the private state based on a second subset of the first subset of the private transactions that includes transactions that are accessible to the first participant 103C to obtain a first private state of the DL network 100.
  • the first private state 125A is a datastore representing the current states in the DL network 100 that reflects the effect of the private operations of the first participant. This first state 125 A excludes effects by other private transactions of which the first recipient is not a recipient.
  • the private transactions that have the first participant 103C as a recipient can have one or more other participants as recipients.
  • the first private state 125A is generated by reprocessing each of the second subset of the first subset of the private transactions and starting from the first copy of the private state determined at operation 208.
  • the payloads of these transactions which are a subset of the transactions retrieved at operation 206, are used during the reprocessing to determine the first private state 125 A.
  • DL node 102A updates the second copy of the private state based on a third subset of the first subset of the private transactions that are accessible to any of the other participants to obtain a second private state of the DL network 100; and
  • the DL node 102 A generates the second private state 127 A, which is a datastore representing the current states in the DL network 100 that reflects the effect of the private transactions of participants.
  • the participants include participants that are different from the first participant 103C as well as potentially the first participant. For example, when a private transaction of which the first participant 103C is a recipient also has another participant as a recipient, this transaction is also considered when determining the private state 127A.
  • the second state 127A considers effects by other private transactions of which the first recipient is not a recipient, the second state 127 A may further be determined by private transactions of which the first recipient is a recipient (which may include the initial private transaction of the first participant).
  • the second private state 127A is generated by reprocessing each of the third subset of the first subset of the private transactions and starting from the second copy of the private state determined at operation 208.
  • the payloads of these transactions which are a subset of the transactions retrieved at operation 206, are used during the reprocessing to determine the second private state 127A.
  • updating, at operation 210, the first copy of the private state to obtain the first private state and updating, at operation 212, the second copy of the private state to obtain the second private state may be performed as described with respect to Fig. 2E.
  • Fig. 2E illustrates a flow diagram of exemplary operations that can be performed for updating the first and the second copy of the private state, in accordance with some embodiments. The operations of Fig. 2E are performed for each operation of the first subset of private transactions. In some embodiments, the transactions of the first subset of private transactions are processed in a chronological order such that a first transaction that is recorded in the digital ledger 110A before a second transaction is also processed before the second transaction.
  • DL node 102A determines whether the private transaction is accessible to the first participant. In other words, DL node 102A determines whether the private transaction is a recipient of the first participant.
  • the flow moves to operation 242.
  • DL node 102A applies the private transaction to the second copy of the private state.
  • Applying the private transaction includes processing the private transaction and updating the state of the second copy of the private state based on the effect resulting from the processing of the private transaction.
  • the processing of the private transactions includes processing the payloads of the private transactions retrieved from the transactions manager 140A. The flow of operations then moves to operation 250.
  • the flow of operations moves from operation 240 to operation 244.
  • the private transaction is added to a second subset of the first subset of the private transactions.
  • the flow of operations moves to operation 245, at which the private transaction is deleted from the transaction manager 140 A.
  • the flow of operations moves to operation 246.
  • DL node 102A applies the private transaction to the first copy of the private state. Applying the private transaction includes processing the private transaction and updating the state of the first copy of the private state based on the effect resulting from the processing of the private transaction.
  • the flow of operations moves to operation 248.
  • DL node 102A determines whether the private transaction is accessible to another participant for which DL node 102 A hosts private transactions. Upon determining that the private transaction is accessible to another recipient, the flow of operations moves to operation 242 and the second copy of the private state is further updated based on this private transaction. The update of the second copy of the private state is performed by processing of this private transaction and includes processing the payload of the private transaction as retrieved from the transactions manager 140 A. Upon determining that the private transaction is not accessible to any other recipient, the flow of operations moves to operation 250. At operation 250, DL node 102A determines if there are any remaining unprocessed private transactions in the first subset of private transactions.
  • a first private state is obtained.
  • the first private state results from the processing of private transactions that have the first participant 103C as a recipient and represent the current state of the DL network 100 for the private transactions of the first participant.
  • a second private state is obtained.
  • the second private state results from the processing of private transactions, which have other participants as recipients.
  • DL node 102A has separated the private state of the DL network 100 into two distinct private states (the first and the second private state). Further, the operations of Fig. 2E enable DL node 102A to determine the second subset of private transactions, which includes all private transactions of which the first participant 103C is a recipient.
  • DL node 102A may receive a new private transaction while being in the process of separating the private data of the first participant. If a new private transaction is received, the transaction is stored in the transaction manager and the new private transaction is automatically added to the first subset of private transactions to be processed along the other transactions for determining the second subset of private transactions and the first private state for the first participant.
  • the new private transaction can be used as described with respect to Fig. 2E to update the first private and/or the second private state.
  • the new private transaction is added to the second subset of private transactions and is used for determination of the first private state for the first participant. Additionally or alternatively, the new private transaction can be used for determination of the second private state.
  • DL node 102A securely transmits the second subset of the private transactions and the first private state of the DL network 100 to another node.
  • the other node is a node of the first participant, e.g., node 102C.
  • the other node is a node that is to act as a host for the private transactions of the first participant 103C and is not a node of the first participant. This other node is authorized by the first participant 103C to host the private transactions of the first participant 103C and belongs to a third party, which is also a participant in the DL network 100.
  • operation 214 is performed as described with reference to Fig. 2F.
  • Fig. 2F illustrates a flow diagram of exemplary operations performed for secure transmission of the second subset of the private transactions and the first private state, in accordance with some embodiments.
  • the secure transmission of the second subset of the private transactions and the first private state may include encrypting, at operation 252, the first private state, the second subset of the private transactions, or a combination of the first private state and the second subset of the private transactions before being transmitted.
  • the encryption can be performed based on a public key of the receiving node (operation 251) or a shared secret key between the DL node 102A and the receiving node (e.g., node 102C) (operation 253).
  • DL node 102A may eliminate these transactions from its transaction manager 140 A and start using the updated private state (i.e., the second private state) for the other participants. For example, the flow of operations may move to operation 214, at which the DL node 102 A stores the second private state as an updated private state of the distributed ledger for the node.
  • DL node 102A stops processing the private transactions of the first participant 103C and any new private transaction of the first participant 103C is no longer stored in the transaction manager 140 A. Following the transmission of the private data (e.g., the first private state and the second subset of private transactions), DL node 102A is no longer authorized to view/access the payloads of the private transactions of the first participant 103C.
  • the private data e.g., the first private state and the second subset of private transactions
  • FIG. 2A While the embodiments herein have been described for the retrieval of private data of a first participant 103C in the DL network 100, other embodiments can include retrieval of the private data of multiple participants. For example, the operations described with reference to Figs. 1-2F can be repeated for each participant to identify for each participant a respective second subset of private transactions that includes the private transactions of the participant and a current private state of the DL network 100 for the participant. While this approach would have the expected result, it may be considered as inefficient in extracting the private transactions and the private state. The approach described with reference to Fig. 2A could be modified to extract the private state for more than one participant as follows. Start processing of private transactions from the earliest private transaction belonging to any of the participants for which private data is to be extracted.
  • the initial private transactions is the first private transaction that is recorded in the digital ledger 110A for any of these participants.
  • Multiple copies of the private state are generated (one for each participant), up to the initial private transaction.
  • Each copy of the private state is updated based on the private transactions that are associated with a respective participant. For example, when there are N participant that need to retrieve their private data, DL node 102A can determine an updated private state for each of these N participants by determining for each private transaction that succeed the initial private transaction, which participant is a recipient of the transaction. If none of the N participants is a recipient of the private transaction and the private transaction is accessible to DL node 102A, this transaction is used to update a (N+l) private state for the DL node 102A.
  • DL node 102A obtains N+l private states and N+l subsets of transactions.
  • the N+l private states include 1) N private state, where each private state is associated with a single participant and results from the processing of private transaction of which the participant is a recipient; and 2) a private state that results from the processing private transactions that have at least another participant (which is different from the N participants) as recipient.
  • the N+l subsets of transactions include 1) N subset of private transactions, where each subset of private transactions includes private transactions of a respective one from the N participants; and 2) another subset of private transactions that includes private transactions of which have at least one other participant (different than the N participants) as a recipient.
  • the results are transmitted separately to each of the participant.
  • the private data (including the private transactions and the private state of each participant) is encrypted based on a key associated with the participant (e.g., public key or shared key).
  • the embodiments presented herein allow a DL node to split and extract the private data of a recipient from private data of multiple participants.
  • the embodiments described herein present a solution for separating a private state and private transactions from an aggregate state and aggregate transactions in a distributed ledger network.
  • the solution offers the advantage of allowing a user to securely transfer ownership of its private data, which includes the private transactions and the private state resulting from execution of these private transactions, from one DL node to another DL node.
  • the solution presented herein offers the additional advantage of accelerating the extraction process of the private transactions and the private state using data cached during the transaction evaluation process.
  • 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).
  • machine-readable media also called computer-readable media
  • machine-readable storage media e.g., magnetic disks, optical disks, solid state drives, read only memory (ROM), flash memory devices, phase change memory
  • machine-readable transmission media also called a carrier
  • carrier e.g., electrical, optical, radio, acoustical or other form of propagated signals - such as carrier waves, inf
  • an electronic device e.g., a computer
  • 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.
  • 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
  • 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.
  • NI(s) physical network interface
  • 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).
  • 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.
  • NICs network interface controller
  • 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.
  • a network device 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.).
  • the components of the DL network 100 can be implemented on one or more network devices coupled through a physical network.
  • each of the ND 102A-N can be implemented on one ND or distributed over multiple NDs.
  • 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.
  • 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.
  • FIG. 312 While one embodiment does not implement virtualization, alternative embodiments may use different forms of virtualization - represented by a virtualization layer 320.
  • the 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.
  • the computer program 311 includes instructions which when executed by the hardware 305 causes the instance 340 to perform the operations described with reference to Figs. 1-2F.
  • the DLT node 102A is implemented on a single network device.
  • Fig. 4 illustrates an exemplary embodiment in which a node is implemented on multiple network devices.
  • the DLT node 102A 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-2F can be distributed over the multiple network devices, such as each network device is operative to perform a subset of the operations described herein.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un procédé et un nœud d'un réseau de registre distribué permettant de séparer un état privé d'autres états privés. Un premier sous-ensemble des transactions privées est identifié pour un premier participant qui comprend une transaction privée initiale. Une première et une seconde copie de l'état privé sont générées de façon à comprendre un état du réseau de registre distribué jusqu'à une dernière transaction avant la transaction privée initiale du premier participant. Des données utiles d'un premier sous-ensemble des transactions privées sont récupérées. La première copie de l'état privé est mise à jour sur la base d'un second sous-ensemble du premier sous-ensemble des transactions privées qui comprend des transactions qui sont accessibles au premier participant pour obtenir un premier état privé du réseau de registre distribué. Le second sous-ensemble du premier sous-ensemble des transactions privées et du premier état privé sont transmis de manière sécurisée à un nœud du premier participant.
PCT/SE2019/051147 2019-11-13 2019-11-13 Procédé de séparation d'un état privé et de transactions privées d'un état agrégé et de transactions agrégées dans un réseau de registre distribué WO2021096400A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/SE2019/051147 WO2021096400A1 (fr) 2019-11-13 2019-11-13 Procédé de séparation d'un état privé et de transactions privées d'un état agrégé et de transactions agrégées dans un réseau de registre distribué

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SE2019/051147 WO2021096400A1 (fr) 2019-11-13 2019-11-13 Procédé de séparation d'un état privé et de transactions privées d'un état agrégé et de transactions agrégées dans un réseau de registre distribué

Publications (1)

Publication Number Publication Date
WO2021096400A1 true WO2021096400A1 (fr) 2021-05-20

Family

ID=75911382

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2019/051147 WO2021096400A1 (fr) 2019-11-13 2019-11-13 Procédé de séparation d'un état privé et de transactions privées d'un état agrégé et de transactions agrégées dans un réseau de registre distribué

Country Status (1)

Country Link
WO (1) WO2021096400A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170289111A1 (en) * 2016-04-01 2017-10-05 Jpmorgan Chase Bank, N.A. Systems and methods for providing data privacy in a private distributed ledger
WO2018057719A1 (fr) * 2016-09-21 2018-03-29 R-Stor Inc. Systèmes et procédés d'utilisation d'un registre distribué pour la gestion de données
US10320843B1 (en) * 2017-12-08 2019-06-11 Symbiont.Io, Inc. Methods, systems, and devices for encrypted electronic storage and confidential network transfer of private data through a trustless distributed ledger technology system
EP3528468A1 (fr) * 2018-02-20 2019-08-21 Nokia Technologies Oy Partage d'informations de profil

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170289111A1 (en) * 2016-04-01 2017-10-05 Jpmorgan Chase Bank, N.A. Systems and methods for providing data privacy in a private distributed ledger
WO2018057719A1 (fr) * 2016-09-21 2018-03-29 R-Stor Inc. Systèmes et procédés d'utilisation d'un registre distribué pour la gestion de données
US10320843B1 (en) * 2017-12-08 2019-06-11 Symbiont.Io, Inc. Methods, systems, and devices for encrypted electronic storage and confidential network transfer of private data through a trustless distributed ledger technology system
EP3528468A1 (fr) * 2018-02-20 2019-08-21 Nokia Technologies Oy Partage d'informations de profil

Similar Documents

Publication Publication Date Title
US11018850B2 (en) Concurrent transaction processing in a high performance distributed system of record
US11228590B2 (en) Data processing method and apparatus based on mobile application entrance and system
US20210406250A1 (en) Method and system for reducing the size of a blockchain
JP2021508877A (ja) 高性能分散型記録システム
JP2022508247A (ja) 信頼度ベースのコンセンサスを伴う高性能分散型記録システム
US20190363938A1 (en) System and method for network infrastructure analysis and convergence
EP3815294B1 (fr) Procédé et appareil de mise en oeuvre d'un élément de traitement de transaction à chaîne de blocs distribué dans un centre de données
CN109167660B (zh) 选举代表节点设备方法、装置、计算机设备及存储介质
US11296892B2 (en) Secure inter-service communications in a cloud computing system
WO2018229531A1 (fr) Systèmes et procédés de sécurité de dispositifs connectés au réseau
CN114756519A (zh) 与无状态同步节点的托管文件同步
US11470065B2 (en) Protection of private data using an enclave cluster
JP2020522767A (ja) ブロックチェーンシステムのノード間の通信を確立するための方法及びデバイス
US20150286496A1 (en) Systems and methods for enlisting single phase commit resources in a two phase commit transaction
US11961074B2 (en) Method and system for a network device to obtain a trusted state representation of the state of the distributed ledger technology network
US20220046028A1 (en) Method and system for determining a state of an account in a network device running a light client protocol of a distributed ledger technology network
US9729625B1 (en) Personal cloud network
US20220085976A1 (en) Distributed session resumption
CN111092958A (zh) 一种节点接入方法、装置、系统及存储介质
WO2021096400A1 (fr) Procédé de séparation d'un état privé et de transactions privées d'un état agrégé et de transactions agrégées dans un réseau de registre distribué
US20230198747A1 (en) Policy-aware distributed ledger networks
Ramesh et al. Public auditing for shared data with efficient user revocation in the cloud
US11989279B2 (en) Method and system for service image deployment in a cloud computing system based on distributed ledger technology
CN110390516B (zh) 用于数据处理的方法、装置和计算机存储介质
CN112162967A (zh) 工控系统数据安全的拟态存储系统及方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19952572

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19952572

Country of ref document: EP

Kind code of ref document: A1