Distributed ledger system

Abstract

In particular, a method performed by at least one device is disclosed, the method comprising: storing a first data portion and a second data portion of at least one data block in a data storage portion assigned to at least one node, wherein the first data portion is stored as immutable data; causing first hash information to be stored in association with the first data portion as part of a distributed ledger; causing second hash information to be stored in association with the second data portion as part of the distributed ledger; obtaining modification request information related to the at least one data block; and based on the modification request information, causing the second hash information associated with the second data portion to be deleted and / or causing new second hash information to be stored in association with a new second data portion of the at least one data block as part of the distributed ledger.

Description

Technical Field

[0001] The present disclosure relates generally to distributed ledger technology, and in particular to methods, devices, and systems that enable interoperability between a distributed ledger system and nodes that may be standalone nodes, may be part of another distributed ledger system, and / or a blockchain system, on the one hand, and that enable flexible management of stored data while maintaining a high degree of data security, on the other hand. Background Art

[0002] Blockchain or blockchain-like distributed ledger systems have become popular in many application areas, including technologies underlying logistics and / or warehouse processes. For example, blockchain-like distributed ledger systems (i.e., distributed ledger systems that include at least one or more blockchain mechanisms (such as a consensus mechanism)) can provide a technical foundation for enabling data communication between entities within or outside the distributed ledger system while simultaneously achieving a high degree of data security within the distributed ledger system.

[0003] In particular, in order to maintain data security within the distributed ledger system, a specific interface is required to enable communication between the distributed ledger system and one or more nodes external to the distributed ledger system. In particular, where the one or more external nodes external to the distributed ledger system are included in another distributed ledger and / or blockchain system and / or a non-distributed ledger and / or non-blockchain system, such a specific interface may be required to enable interoperability between such external nodes and nodes of the distributed ledger system.

[0004] Furthermore, while distributed ledger systems such as blockchain systems can achieve a high degree of data security, users may not be able to modify previously stored data. For example, in traditional blockchain systems (where a data block used to record data for, for example, a transaction includes a cryptographic hash of a previous data block), a data block cannot be retroactively modified without modifying all subsequent blocks. While this architecture offers a high degree of security, it also results in a lower degree of flexibility. In particular, if, for example, a transaction requires a user's personal data and therefore needs to be included in a data block, it may not be practical to remove such personal data later, for example, once the transaction is completed and no longer required. Summary of the Invention

[0005] The present disclosure aims to provide, among other things, methods and apparatus for enabling interoperability between a distributed ledger system and at least one node, which may be a standalone node or part of a non-distributed ledger system, a distributed ledger system, and / or a blockchain system. Furthermore, the present disclosure aims to provide methods and apparatus for enabling a distributed ledger system to have a higher degree of flexibility in data management while maintaining a high degree of data security and integrity.

[0006] According to a first exemplary aspect of the present disclosure, a method performed by at least one device is disclosed, the method comprising:

[0007] - receiving or causing reception of a connection establishment message from at least one external device, or transmitting or causing transmission of the connection establishment message to the at least one external device;

[0008] - obtaining or causing to be obtained a decentralized identifier representing the external device based on the connection establishment message;

[0009] - obtaining or causing to be obtained at least one hash value generated based on at least a portion of the obtained decentralized identifier;

[0010] storing or causing to be stored, in a secured portion of a memory of a distributed ledger system comprising the peer-to-peer network, at least one hash value in association with at least a portion of the decentralized identifier based on a consensus process involving at least a subset of the nodes of the peer-to-peer network.

[0011] The method according to the first aspect of the present disclosure may be performed by at least one device that is part of or corresponds to at least one node of a peer-to-peer network comprising at least two nodes, wherein a corresponding node of the peer-to-peer network stores at least a portion of a distributed ledger. Thus, the distributed ledger may incorporate one or more features of a blockchain, for example, implementing a consensus mechanism to ensure that data subject to the consensus mechanism is only modified upon consensus among at least a subset of nodes in the peer-to-peer network.

[0012] According to a second exemplary aspect of the present disclosure, a method performed by at least one device is disclosed, the method comprising:

[0013] - storing or causing to be stored at least one data block, the storing comprising:

[0014] - storing or causing to be stored a first data portion and a second data portion of the at least one data block in a data memory portion assigned to the at least one node, wherein the first data portion is stored as immutable data;

[0015] The method further comprises:

[0016] - causing first hash information to be stored in association with the first data portion as part of the distributed ledger;

[0017] - causing second hash information to be stored in association with the second data portion as part of the distributed ledger;

[0018] - obtaining or causing to be obtained modification request information associated with the at least one data block;

[0019] - Based on the modification request information and based on a consensus process performed at at least one node of at least one set of nodes of the peer-to-peer network, causing deletion of the second hash information associated with the second data portion and / or causing new second hash information to be stored in association with a new second data portion of the at least one data block as part of the distributed ledger.

[0020] The method according to the second aspect of the present disclosure may be performed by at least one device that is part of or corresponds to at least one node of a peer-to-peer network comprising at least two nodes forming at least a portion of a distributed ledger system, wherein the respective node stores at least a corresponding portion of the distributed ledger in a distributed ledger memory portion allocated to the respective node. Thus, the distributed ledger system may incorporate one or more features of a blockchain, for example, a consensus mechanism may be implemented to ensure that data subject to the consensus mechanism is only changed if consensus is reached among at least a subset of nodes in the peer-to-peer network.

[0021] In an exemplary embodiment, a distributed ledger includes data representing one or more hash values, indices, and / or hash indices, each corresponding to corresponding data, particularly user data or payload data. Thus, in an exemplary embodiment, the data corresponding to the corresponding hash value, index, and / or hash index is stored locally on a storage device connected to and / or accessible by one or more nodes of at least a subset of nodes constituting a peer-to-peer network. Furthermore, in an exemplary embodiment, the one or more hash values, indices, and / or hash indices are maintained by the distributed ledger and are subject to a consensus mechanism that is configured such that the corresponding hash value, index, and / or hash index may only be changed or deleted if a consensus is reached between at least each node in the subset of nodes in the peer-to-peer network. It should be noted that consensus can be expressed by one or more nodes in a subset of nodes, i.e., a single node can also express consensus on adding new data blocks and / or modifying / deleting existing data blocks.

[0022] For the method according to the first aspect and / or the second aspect of the present disclosure, a device is also disclosed (and subsequently referred to as the device according to the first aspect and / or the second aspect of the present disclosure, respectively), which is configured to perform and / or control the corresponding method, or include a corresponding device for performing and / or controlling the steps of the corresponding method. In this case, all steps of the method can be controlled, or all steps of the method can be performed, or one or more steps can be controlled and one or more steps can be performed. One or more devices in these devices can also be performed and / or controlled by the same unit. For example, one or more devices in these devices can be formed by one or more processors.

[0023] For the method according to the first aspect and / or the second aspect of the present disclosure, a device (e.g., at least one device according to the first aspect and / or the second aspect, respectively) is also disclosed (and will be referred to as at least one device according to the first aspect and / or the second aspect of the present disclosure), the device comprising at least one processor and at least one memory comprising computer program code, the at least one memory and the computer program code being configured to use the at least one processor to cause the device (e.g., the device) to at least perform and / or control the method according to the first aspect and / or the second aspect of the present disclosure. In this case, all steps of the corresponding method may be controlled, or all steps of the corresponding method may be performed, or one or more steps may be controlled and one or more steps may be performed.

[0024] The at least one device according to the first and / or second aspects of the present disclosure may correspond to or include at least one fixed or portable personal computer, at least one server, at least one server system, and / or at least one mobile device, or be included therein. Thus, in an exemplary embodiment, the mobile device corresponds to or includes a smartphone, a smartwatch, a smart bracelet, a tablet computer, a notebook computer, a smart home device, an Internet of Things (IoT) device, an Internet of Medical Things (IOMT) device, and / or a data logger. The at least one device according to the first and / or second aspects may, for example, be integrated into the backend of a logistics service provider.

[0025] For the method according to the first aspect and / or the second aspect of the present disclosure, a system is also disclosed (and subsequently referred to as the system according to the first aspect and / or the second aspect of the present disclosure, respectively), the system comprising at least one device (e.g., at least one device according to the first aspect and / or the second aspect), the device being configured to perform and / or control the corresponding method, or having means for performing and / or controlling the steps of the corresponding method. In this case, all steps of the corresponding method may be controlled, or all steps of the corresponding method may be performed, or one or more steps may be controlled and one or more steps may be performed.

[0026] For the method according to the first aspect and / or the second aspect of the present disclosure, a computer program is also disclosed (and subsequently referred to as the computer program according to the first aspect and / or the second aspect of the present disclosure), which includes program instructions that cause the processor to perform and / or control the corresponding method when the computer program is run on a processor. In an exemplary embodiment, such a computer program may correspond to a source code and / or a device identification code, may be part of the source code and / or the device identification code, or may be incorporated into the source code and / or the device identification code. In this specification, a processor is intended to be understood as meaning, in particular, a control unit, a microprocessor, a microcontroller such as a microcontroller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), or a field programmable gate array (FPGA).

[0027] In this case, all steps of the method may be controlled (which in exemplary embodiments may be understood as conditional steps of the method), or all steps of the method may be executed, or one or more steps may be controlled and one or more steps may be executed. For example, the computer program may be distributed via a network such as the Internet, a telephone or mobile radio network, and / or a local area network. In non-limiting examples, the network may correspond to a wireless network, a network that at least partially employs technologies based on radio frequency identification (RFID) and / or global system for mobile communications (GSM), and / or a matching service network. The computer program may be at least partially software and / or firmware of a processor. The computer program may also be implemented at least partially in hardware. For example, the computer program may be stored on a computer-readable storage medium, such as a magnetic storage medium, an electrical storage medium, an electromagnetic storage medium, an optical storage medium, and / or other types of storage media. For example, the storage medium may be part of the processor, such as a (non-volatile or volatile) program memory of the processor or a portion thereof. For example, the storage medium is substantial, i.e., tangible and / or non-transitory.

[0028] According to a third exemplary aspect of the present disclosure, a distributed ledger system is disclosed, the distributed ledger system comprising:

[0029] - at least two nodes of a peer-to-peer network, wherein respective ones of the nodes of the peer-to-peer network store at least a portion of a distributed ledger;

[0030] - a software development kit and / or an application programming interface configured to enable transmission of connection establishment messages between at least one of the nodes of the peer-to-peer network and an external device;

[0031] a decentralized identifier acquirer configured to acquire a decentralized identifier representing the external device based on the connection establishment message;

[0032] - a hash value obtainer configured to obtain at least one hash value generated based on at least a portion of the obtained decentralized identifier;

[0033] a consensus controller configured to control, based on a consensus process involving at least a subset of nodes of the peer-to-peer network, storing the at least one hash value in association with at least a portion of the decentralized identifier in a secured portion of a memory of the distributed ledger system.

[0034] According to a fourth exemplary aspect of the present disclosure, a distributed ledger system is disclosed, comprising: a peer-to-peer network having nodes, wherein respective nodes are configured to store at least a corresponding portion of a distributed ledger in a distributed ledger memory portion allocated to the respective nodes; and at least one device that is part of or corresponds to at least one node of the peer-to-peer network and is configured to:

[0035] - storing or causing to be stored a first data portion and a second data portion of at least one data block in a data memory portion assigned to the at least one node, wherein the first data portion is stored as immutable data;

[0036] - causing first hash information to be stored in association with the first data portion as part of the distributed ledger;

[0037] - causing second hash information to be stored in association with the second data portion as part of the distributed ledger;

[0038] - obtaining or causing to be obtained modification request information associated with the at least one data block;

[0039] - Based on the modification request information and based on a consensus process performed at at least one node in the subset of nodes of the peer-to-peer network, causing deletion of the second hash information associated with the second data portion and / or causing new second hash information to be stored in association with a new second data portion of the at least one data block as part of the distributed ledger.

[0040] Exemplary embodiments of all aspects of the present disclosure may have one or more (or, for example, all) of the properties described below.

[0041] In an exemplary embodiment, the distributed ledger is a collection of digital data accessible to at least one node of the peer-to-peer network, whereby the storage of new data as part of the distributed ledger, the deletion of existing data from the distributed ledger, and / or the correction of existing data are subject to a consensus mechanism between at least a subset of the nodes of the peer-to-peer network. The subset may, for example, correspond to a group of nodes involved in application processing related to the data to be newly stored, deleted, and / or corrected. In an exemplary embodiment, the respective nodes of the peer-to-peer network include and / or are connected to a storage device that stores at least a portion of the distributed ledger (in an exemplary embodiment, a complete copy). It should be noted that, as used herein, the one or more nodes may be understood to correspond to or include at least one node and corresponding supporting hardware and one or more corresponding application services.

[0042] In an exemplary embodiment, the nodes of the peer-to-peer network correspond to or include fixed or portable personal computers, servers, server systems or cloud systems, and / or mobile devices. Thus, in an exemplary embodiment, the mobile devices correspond to or include smartphones, smart watches, smart bracelets, tablet computers, laptop computers, smart home devices, Internet of Things (IoT) devices, Internet of Medical Things (IOMT) devices, data loggers, image recognition devices, scanners, point of sale (PoS) devices, signature and / or facial recognition devices.

[0043] Thus, the distributed ledger system may correspond to a plurality of nodes, such as a plurality of computers installed at respective facilities of a company (e.g., a logistics provider). The distributed ledger may correspond to data associated with a corresponding application (e.g., an application associated with the shipment of goods). Thus, data associated with a first application (e.g., a first shipment of goods) may be stored at the respective storage devices of the nodes involved in the first shipment in the form of data blocks representing the various stages of the shipment process. For example, a first data block may include data associated with a shipment request from a client of a logistics provider, a second data block may include data associated with a confirmation from the logistics provider to the client, and a third data block may include data associated with the initial shipment stage when, for example, the goods are loaded onto a shipping vehicle, vessel, or aircraft.

[0044] While such data can be stored, for example, locally on corresponding storage devices of the nodes involved in the first shipment process or connected to these nodes, the distributed ledger system, in exemplary embodiments, is configured to assign (e.g., includes an indexer as further disclosed herein, which is configured to assign) at least one corresponding hash value and / or hash index to the corresponding data block. Thus, in exemplary embodiments, the hash value generated for the second data block associated with the application is generated independently of the first data block associated with the application (e.g., representing an application processing phase before, and in particular, immediately before, the application processing phase represented by the second data block). In particular, in exemplary embodiments, the second data block associated with the application does not include the hash value generated for the first data block associated with the application (e.g., representing an application processing phase before, and in particular, immediately before, the application processing phase or event trigger represented by the second data block). It should be noted that in the context of the present disclosure, an application may particularly correspond to or be associated with the processing of shipments, transactions, and / or smart contracts.

[0045] To enable a node of a distributed ledger system to perform application processing (e.g., processing of a shipment, transaction, or smart contract) with one or more nodes external to the distributed ledger system, the node external to the distributed ledger system may be logged in. The corresponding login process may be initiated by the external node, in which case the node of the distributed ledger system may receive a connection establishment message from the node external to the distributed ledger system, which in exemplary embodiments is an example of at least one external device. The login process may similarly be initiated by a node internal to the distributed ledger system, in which case the node may transmit a connection establishment message to the at least one external device.

[0046] In the next phase of the login process, the node of the distributed ledger system may obtain a decentralized identifier representing the external device based on the connection establishment message. Thus, in an exemplary embodiment, the node of the distributed ledger system obtains the decentralized identifier from a (software) module of the distributed ledger system (e.g., from a partner discoverer further disclosed herein), which is configured to generate the decentralized identifier based on information about the external device included in the connection establishment message, or another message received from the external device. It should be noted that the decentralized identifier may be an existing decentralized identifier (e.g., a decentralized identifier already assigned to the external device), or may be a decentralized identifier newly assigned to the external device.

[0047] Furthermore, in an alternative exemplary embodiment, a node of the distributed ledger system can obtain a decentralized identifier representing the external device from the external device. To this end, in an exemplary embodiment, the distributed ledger system and / or a node of the distributed ledger system includes a decentralized identifier resolver application programming interface (API) configured to resolve decentralized identifiers associated with and received from the external device. For example, the decentralized identifier resolver API can convert a format for defining decentralized identifiers on the external device side into a format for defining decentralized identifiers on the distributed ledger system side. It should be noted that in an exemplary embodiment, the decentralized identifier resolver API can employ or be based on global Internet standards such as W3C standards, and / or can correspond to or be based on a RESTful API. Employing the decentralized identifier resolver API can be particularly useful in situations where the external device is part of a non-distributed ledger system (e.g., a non-blockchain system), which includes multiple nodes that are assigned to corresponding decentralized identifiers generated for the non-distributed ledger system. For example, this embodiment can be suitably applied in situations where the external device is part of an SAP HANA system. In this case, in an exemplary embodiment, the distributed ledger system functions as a master server (MoS) with respect to the decentralized identifier obtained from the external device.

[0048] In particular, the invention enables data communication between nodes of a distributed ledger system and nodes external to the distributed ledger system based on decentralized identifiers, which can be substantially independent of the underlying technology of the system to which the external device belongs. Data communication can also be enabled between nodes of a distributed ledger system and independent nodes, nodes of another distributed ledger system, nodes of a blockchain system, nodes of a non-distributed ledger system, and / or nodes of a non-blockchain system.

[0049] Based on the obtained decentralized identifier, the node of the distributed ledger system then obtains at least one hash value generated based on at least a portion of the obtained decentralized identifier. As mentioned, in exemplary embodiments, the distributed ledger system and / or the node of the distributed ledger system includes an indexer configured to generate at least one hash value based on at least a portion of the obtained decentralized identifier. Thus, the node of the distributed ledger system can obtain the hash value from the indexer implemented at the node of the distributed ledger system or from an indexer implemented at another node of the distributed ledger system.

[0050] The at least one hash value is then stored in association with at least a portion of the decentralized identifier in a secured portion of the memory of the distributed ledger system. Thus, in an exemplary embodiment, the memory of the distributed ledger system corresponds to or includes one or more corresponding storage devices of or connected to one or more nodes of the peer-to-peer network, whereby the one or more storage devices can each store at least a portion, in particular a complete copy, of the distributed ledger. In an exemplary embodiment, the memory further includes a secured portion, i.e., a portion subject to specific security guarantees. Thus, the secured portion can be provided on a dedicated storage device of or connected to one or more nodes of the peer-to-peer network, can be distributed across corresponding storage devices of or connected to one or more nodes of the peer-to-peer network, or can be included in an external storage device (e.g., included in a cloud-based storage device).

[0051] In an exemplary embodiment, the secure portion is configured to provide identity-based access to the secure portion, for example, the secure portion provides access only to identified users. Further, in an exemplary embodiment, the secure portion is configured to encrypt the stored data, for example, to maintain the data in an encoded form so that only authorized parties can decode the encoded data to access the original information. Although aspects of the present disclosure are not limited in this respect, in an exemplary embodiment, the secure portion corresponds to or includes a vault, in particular a HashiCorp vault. In an exemplary embodiment, the vault may correspond to hardware configured to store data in a secure manner, for example, a locally deployed vault and / or a cloud-based secure key repository that may correspond to a hardware device configured to store corresponding security keys.

[0052] In an exemplary embodiment, in addition to or in lieu of the identity-based access to the secured portion, other forms of access that may be employed include one or more of the following:

[0053] - Access based on node identity, e.g., based on the type of data a node can send and receive;

[0054] - Access based on node identity, e.g., based on the node's role.

[0055] Thus, in an exemplary embodiment, the role of a node can correspond to the node affiliation (e.g., based on affiliation with a particular entity (such as a person, a group of people and / or a company)), the node's level in the entity (e.g., whether the node belongs to the entity's supply chain), a role based on the node's country, the node's economic sector, the node's site (e.g., MEA, EMEA, DXB), a user or user group level (an accounting team in a city or an individual accountant using the service).

[0056] In an exemplary embodiment, a decentralized identifier is associated with a decentralized identifier document. Thus, in an exemplary embodiment, the decentralized identifier corresponds to or includes a uniform resource locator (URL) that associates the subject identified by the decentralized identifier (e.g., an external device) with the decentralized identifier document. In an exemplary embodiment, the decentralized identifier document maintains information regarding or defining one or more public keys associated with the decentralized identifier, authentication information associated with the decentralized identifier (e.g., one or more authentication and / or verification methods), service endpoints, and / or information regarding the semantics of the subject identified by the decentralized identifier (e.g., an external device). The service endpoints can enable trusted interactions associated with the subject of the decentralized identifier (e.g., with the external device). The service endpoints can, for example, correspond to any one or more nodes of a peer-to-peer network and / or to the external device and can be identified by their corresponding addresses, such as their MAC addresses, such as, for example, by the International Mobile Equipment Identity (IMEI) in the case of mobile devices such as smartwatches or handheld devices, or by a serial number in the case of data loggers. In an exemplary embodiment, the decentralized identifier document can further include a timestamp (e.g., for audit history) and / or a signature (e.g., for integrity). In an exemplary embodiment, the decentralized identifier document may correspond to or include metadata associated with the decentralized identifier.

[0057] Thus, in an exemplary embodiment, a decentralized identifier is an identifier generated at a distributed ledger system and / or on the external device side based on the attributes of the external device and associated with a decentralized identifier document. Although decentralized identifiers according to various aspects disclosed herein are not limited in this respect, in an exemplary embodiment, the decentralized identifier includes or corresponds to a DID specified by the World Wide Web Consortium (W3C). Additionally or alternatively, in an exemplary embodiment, the decentralized identifier corresponds to a digital twin encrypted using a security key assigned to the corresponding endpoint.

[0058] Therefore, in an exemplary embodiment, the method according to the first aspect further comprises

[0059] - obtaining or causing to be obtained at least one hash value based on at least one respective address of at least one corresponding service endpoint and / or based on at least one corresponding public key included in the decentralized identifier document.

[0060] In an exemplary embodiment, the method according to the first aspect further comprises:

[0061] - distributing or causing to be distributed at least one pair of a public key and a private key to the external device;

[0062] - providing or causing to be provided the public key to the external device; and

[0063] storing or causing to be stored, based on a consensus process involving at least a subset of the nodes of the peer-to-peer network, at least the private key in association with at least a portion of the decentralized identifier in a secured portion of a memory of the distributed ledger.

[0064] Thus, a node of a distributed ledger system may include a (software) module (e.g., a partner discoverer as further disclosed herein) configured to generate a pair of public and private keys (key pairing) to be distributed (and provided) to an external device. Thus, in exemplary embodiments, the public and private keys correspond to and / or are generated based on asymmetric cryptography. In exemplary embodiments, the keys are generated based on the Elliptic Curve Digital Signature Algorithm (ECDSA), which may enable the use of smaller keys while providing a similar level of security to keys based on non-elliptic curve cryptography. Thus, in exemplary embodiments, the keys are generated based on the SECP256K1 and / or SECP156R1 curves.

[0065] In an exemplary embodiment, the method according to the first aspect further comprises:

[0066] - assigning or causing assignment to the external device of at least one partner role defining access rights and / or read / write permissions for the external device;

[0067] - Based on a consensus process involving at least a subset of nodes of the peer-to-peer network, storing or causing to be stored in a secured portion of a memory of the distributed ledger system information setting the at least one partner role in association with at least a portion of the decentralized identifier.

[0068] Thus, in an exemplary embodiment, upon logging into an external device, a partner role is assigned to the external device, which defines, for example, write access permissions that may be associated with messages transmitted from the external device to the distributed ledger system. Thus, in an exemplary embodiment, the external device may be assigned one or more partner roles for one or more applications processed between the external device and the distributed ledger system.

[0069] The method according to the first aspect further comprises:

[0070] - providing or causing to be provided the at least one hash value generated based on at least a part of the obtained decentralized identifier to the external device, in particular in association with the decentralized identifier.

[0071] By transmitting a hash value generated based on at least a portion of the obtained decentralized identifier to the external device, further data communication between the external device and the node of the distributed ledger system can be protected based on hash verification (hash pairing) of the message incoming from the external device at least on the distributed ledger system side.

[0072] In an exemplary embodiment, the method according to the first aspect further comprises:

[0073] - establishing or causing to be established a machine-to-machine pairing based on a digital twin between the external device and at least one node of the peer-to-peer network, in particular based on the decentralized identifier.

[0074] By establishing a digital twin-based machine-to-machine pairing between the external device and at least one node of the peer-to-peer network when the external device logs in (and during further data communication between the nodes of the peer-to-peer network and the external device), a further security layer is established in addition to the key pairing mechanism and hash pairing mechanism.

[0075] As disclosed above, according to a second aspect, another method is provided which is performed by at least one device, which in an exemplary embodiment corresponds to at least one device performing the method according to the first aspect. The method according to the second aspect comprises storing or causing to be stored at least one data block. Thus, as explained above, in an exemplary embodiment, the data block comprises digital data relating to a corresponding stage of application processing (in an exemplary embodiment, to a corresponding point in time of application processing). In the case of an application processing corresponding to, for example, a shipment, the data block may correspond to a stage of ordering goods or a stage of loading goods onto a shipping carrier, or further to different stages of a shipment processing. In an exemplary embodiment, the application corresponds to the processing of a shipment (e.g., of goods), a transaction (e.g., a financial transaction) and / or a smart contract.

[0076] Further, according to a second aspect, storing includes storing or causing to be stored a first data portion and a second data portion of at least one data block in a data memory portion allocated to at least one node, wherein the first data portion is stored as immutable data. In an exemplary embodiment, the second data portion is stored as mutable data. In other words, in an exemplary embodiment, the stored data block includes at least a first data portion and a second data portion, whereby the first data portion includes immutable (unchangeable) data. In an exemplary embodiment, the second data portion includes mutable (changeable) data.

[0077] Thus, the first data portion can be used to store data that will not change at a later stage, for example, data related to the application. For example, in the case of shipment, when the data block corresponds to a shipment order for specific goods, for example, the quantity and / or type of goods ordered can be stored as part of the first data portion of the corresponding data block. The second data portion can be used to store data that may need to be changed at a later stage or to store data to which access may have to be restricted at a later stage. For example, in the latter example of shipment processing, the second data portion can be used to store personal data of the subscriber (e.g., personally identifiable information PII). In other words, in an exemplary embodiment, the second data portion of at least one data block includes personal data, in particular data related to personal data (e.g., personally identifiable information PII data).

[0078] As further disclosed herein, the distributed ledger is stored in a memory of the distributed ledger system, which corresponds to or includes one or more corresponding storage devices of or connected to one or more nodes of the peer-to-peer network. A respective node in the peer-to-peer network thus stores at least a portion of the distributed ledger in a distributed ledger memory portion assigned to the respective node, whereby the distributed ledger memory portion corresponds to, is included by, or is connected to the memory and / or storage device of the respective node, or is included by it. Thus, the memory and / or storage device can be connected to the node via a wired connection and / or a wireless connection, and can correspond to an internal storage device and / or an external storage device of the node and / or can correspond to a memory portion that is available at one or more internet servers for the node, for example, can correspond to a cloud storage device assigned to the node. In other words, the distributed ledger memory portion assigned to the respective node is, in an exemplary embodiment, a distributed ledger memory portion of the respective node and / or connected to the respective node.

[0079] Likewise, the data storage portion assigned to at least one node is, in exemplary embodiments, a data storage portion of and / or connected to at least one node. Furthermore, the data storage portion can be connected to the at least one node via a wired and / or wireless connection and can correspond to internal storage and / or external storage of the at least one node and / or can correspond to a memory portion available at one or more internet servers for the at least one node, for example, a cloud storage device assigned to the at least one node. In exemplary embodiments, the data storage portion is a memory portion included by and / or connected to the at least one node and is distinct from the distributed ledger memory portion assigned to the at least one node.

[0080] In an exemplary embodiment, a distributed ledger system includes a corresponding distributed ledger memory portion and a corresponding data memory portion, wherein the corresponding distributed ledger memory portion is assigned to a corresponding one of at least two nodes in a peer-to-peer network, and the corresponding data memory portion is assigned to a corresponding one of at least two nodes in the peer-to-peer network. Thus, the corresponding distributed ledger memory portion is logically separated from the corresponding data memory portion and / or corresponds to at least a portion of a hardware component that is different from the hardware component that includes the corresponding data memory portion. For example, the distributed ledger can be stored in the distributed ledger memory portion of a first group of nodes (e.g., all nodes) in the peer-to-peer network, while data blocks related to the application can be stored in the data memory portion of only the nodes participating in the application processing. Therefore, the separation of the distributed ledger memory portion and the data memory portion enables flexible storage of distributed ledger data in a decentralized manner and achieves a high degree of data security (e.g., due to the consensus processing performed among a large number of nodes), while application-related data may only need to be stored in a subset of nodes, thereby achieving efficient utilization of storage resources.

[0081] According to a second aspect, the method further includes causing the first hash information to be stored in association with the first data portion as part of the distributed ledger, in an exemplary embodiment, in a distributed ledger memory portion assigned to the respective node. The method further includes causing the second hash information to be stored in association with the second data portion as part of the distributed ledger, in an exemplary embodiment, in a distributed ledger memory portion assigned to the respective node.

[0082] Thus, data blocks associated with an application (their first and second data portions, i.e., application data and, for example, personal information) can be stored in one or more data memory portions allocated to nodes participating in application processing, while hash information corresponding to the data blocks is stored (in an exemplary embodiment, in a decentralized manner) as part of a distributed ledger (stored in distributed ledger memory portions of nodes in a peer-to-peer network). Thus, in contrast to, for example, conventional blockchain systems in which a data block includes a cryptographic proof of a preceding data block, according to aspects of the present disclosure, hash information is stored in a distributed ledger separate from the corresponding data portion. As further disclosed herein, the hash information is stored in association with the corresponding data block, wherein, in an exemplary embodiment, this association is achieved through relationship information maintained available by an indexer of the distributed ledger system. In this way, the data security achieved by storing hash information in a distributed ledger, which may be subject to a consensus process among one or more or all nodes of the peer-to-peer network, can be combined with efficient storage usage at nodes participating in application processing.

[0083] As will be described below, the specific architecture disclosed in accordance with various aspects of the present disclosure provides a technical solution for, among other things, implementing the "right to be forgotten," i.e., the right for personal data associated with individuals participating in applications processed by a distributed ledger system to be inaccessible when no longer needed. It should be noted that this technical solution is not limited to personal data and can also restrict access to different data, if desired.

[0084] According to a second aspect, the method further comprises obtaining or causing to be obtained modification request information associated with at least one data block. In an exemplary embodiment, obtaining the modification request information associated with at least one data block comprises:

[0085] - receiving or causing to be received a request to modify or delete at least part of the data of the data block, in particular the data of the second data portion.

[0086] For example, after completing an application process for which a data block is stored as part of it, the modification request information can be received as part of or in response to a message from a node involved in the application process. The information can be received as part of or in the form of a message from, for example, a node in a peer-to-peer network or from a logged-in node outside the peer-to-peer network. For example, after completing a freight shipment, a truck driver, as further disclosed herein, can send a message requesting that his contact information be removed from the stored data associated with the shipment process.

[0087] According to the second aspect, the method further includes causing deletion of second hash information associated with the second data portion or causing new second hash information to be stored in association with a new second data portion of the at least one data block as part of the distributed ledger based on the modification request information and based on a consensus process performed at at least one node of the at least one set of nodes of the peer-to-peer network.

[0088] Thus, in an exemplary embodiment, at least one data block is part of a sequence of at least two data blocks, wherein the respective data blocks include data representing a corresponding stage of application processing (e.g., at a certain point in time) and are associated with corresponding hash information enabling access to the respective data blocks, wherein each piece of hash information forms a sequence representing the corresponding stage of application processing. In other words, in an exemplary embodiment, by causing the second hash information to be stored in association with the second data portion as part of a distributed ledger, the second data portion becomes accessible as part of the sequence of at least two data blocks representing application processing.

[0089] If at least one of the nodes explicitly agrees, for example, a node that receives the message including the modification request information, the previous second hash information is deleted or replaced with the new second hash information. For example, in the sequence of hash information items (e.g., hash indexes) (wherein a corresponding item of hash information is associated with a corresponding data block of the sequence of data blocks), the hash index associated with the second data portion of the data block to which the request relates is deleted or replaced with the new second hash index associated with the new second data portion of the data block. By thus removing the hash information item associated with the second data portion of the data block to which the modification request relates from the sequence of hash information items, the corresponding second data portion is effectively removed from the sequence of data blocks representing various stages of application processing and thus may be "forgotten" and potentially no longer accessible. In other words, in exemplary embodiments, by causing the new second hash information to be deleted or stored as part of a distributed ledger in association with the new second data portion of at least one data block, the second data portion becomes inaccessible as part of the sequence of at least two data blocks representing application processing.

[0090] In this way, the provided technical means make it possible to render data initially stored in connection with an application inaccessible, for example, after the application has been completed and the data may no longer be needed. In particular, this technical means enables distributed ledger systems to comply with the GDPR, since, in particular, personal data can be rendered inaccessible if it is no longer needed. In contrast to data blocks stored, for example, by conventional blockchain systems, the structure of data blocks and their association with hash information according to the aspects disclosed herein thus enable enhanced flexibility in rendering parts of data blocks inaccessible within the context of processing an application (such as processing a shipment, a transaction, and / or a smart contract). In the context of the GDPR, this technical means thus implements the "right to be forgotten."

[0091] In an exemplary embodiment, "based on a consensus processing performed at at least one node of at least one group of nodes of the peer network" is to be understood as "if at least one node of at least one group of nodes of the peer network expressly agrees". As mentioned, it may be sufficient, for example, if the node receiving the message comprising the modification request information expressly agrees. Likewise, alternatively, the express consent of more than one or all nodes of the peer network (e.g., the nodes of the peer network involved in the application processing) may be necessary. In an exemplary embodiment, the group of nodes of the peer network performing the consensus processing is defined in particular based on the partner role of the node transmitting the message comprising the modification request information and / or based on a decentralized identifier associated with the node transmitting the message comprising the modification request information. In an exemplary embodiment, the partner role of the node transmitting the message comprising the modification request information is set in a decentralized identifier document associated with a decentralized identifier, which decentralized identifier is associated with the node transmitting the message comprising the modification request information.

[0092] It should be noted that the modification request information can be confirmed through a consensus process involving one, multiple, or all nodes of the peer-to-peer network involved in the application process and / or involving one, multiple, or all nodes of the peer-to-peer network. Although confirmation of the modification request can simultaneously confirm the deletion and / or addition of one or more hash information from the distributed ledger and / or the replacement of one or more hash information to the distributed ledger, in an exemplary embodiment, the deletion of the second hash information and / or the storage of the new second hash information as part of the distributed ledger is based on a separate consensus process involving one or more or all nodes of the peer-to-peer network.

[0093] As disclosed above, the first data portion is stored as immutable data and therefore remains unchanged regardless of whether the second hash information is deleted or new second hash information is stored together with the new second data portion. In this way, necessary data that remains available in the context of the application is protected from being modified later. At the same time, although it may be sufficient to delete the second hash information without deleting the associated second data portion, or to generate a new second data portion (e.g., corresponding to the previously stored second data portion with data such as personal data removed) in addition to the previously stored second data portion and the previous second hash information associated with the previously stored second data portion that is simply replaced by the new second hash information (e.g., for certain types of data), it may still be necessary to delete or modify the stored second data portion.

[0094] Therefore, in an exemplary embodiment, the method according to the second aspect further comprises at least one of the following:

[0095] - based on the modification request information, replacing or causing replacement of at least part of the data of the second data portion with revised data;

[0096] - based on the modification request information, deleting or causing deletion of at least part of the data of the second data portion.

[0097] Therefore, in an exemplary embodiment, the method includes: if the modification request information relates to the second data portion and if at least one node in at least one group of nodes of the peer-to-peer network explicitly agrees, replacing or causing at least a portion of the data in the second data portion to be replaced with the modified data or deleting or causing at least a portion of the data in the second data portion to be deleted. In this way, a portion of the data stored in the second data portion can be replaced with new data (for example, an individual's contact information can be replaced with current contact information), a portion of the data stored in the second data portion can be removed (for example, personal information related to an individual can be removed while other information remains in the second data portion), or the second data portion can be completely removed. In the case of replacing or deleting only a portion of the second data portion, new second hash information can be stored to replace the previous second hash information, while in the case of deleting the entire second data portion, the second hash information associated with it can be deleted without replacement. Therefore, in an exemplary embodiment, the second data portion is stored as variable data.

[0098] In an exemplary embodiment, causing storage of the first hash information in association with the first data portion as part of the distributed ledger includes:

[0099] - causing an indexer of the distributed ledger system to obtain a first hash value based on the first data portion as at least a part of the first hash information; and

[0100] The step of causing the second hash information to be stored in association with the second data portion as part of the distributed ledger comprises:

[0101] - causing an indexer of the distributed ledger system to obtain a second hash value based on the second data portion as at least a part of the second hash information.

[0102] Thus, in an exemplary embodiment, the indexer is an indexer as disclosed above in the context of the first aspect. In an exemplary embodiment, the indexer corresponds to a (software) module and / or function implemented as executable code at at least one node and / or one or more other nodes of a peer-to-peer network and configured to control the functions of the indexer. In an exemplary embodiment, the indexer is implemented at one or more nodes of the peer-to-peer network. In an exemplary embodiment, the indexer is configured to assign a hash value to the data block and / or the sub-block by applying a hash function based on the corresponding data block and / or the sub-block and independently of data blocks and / or sub-blocks generated before or after the corresponding data block and / or sub-block. In particular, in an exemplary embodiment, causing the indexer of the distributed ledger system to obtain a first hash value includes causing the indexer to apply the hash function to at least a portion of the first data portion. Further, in an exemplary embodiment, causing the indexer of the distributed ledger system to obtain a second hash value includes causing the indexer to apply the hash function to at least a portion of the second data portion.

[0103] In an exemplary embodiment, the method further comprises:

[0104] -Cause the indexer to store first relationship information as accessible and / or manageable by the indexer and cause the indexer to store second relationship information as accessible and / or manageable by the indexer, wherein the first relationship information associates the first hash value with the first data portion and the second relationship information associates the second hash value with the second data portion.

[0105] In other words, in an exemplary embodiment, the relationship information associating the corresponding hash value (and / or hash index) with the corresponding data portion is maintained and available separately from the corresponding data block. In an exemplary embodiment, the first relationship information and the second relationship information are stored separately from the data block. Therefore, in contrast to conventional blockchain systems, for example, in which hash information of a previous data block is stored as part of a subsequent data block, an enhanced degree of flexibility is provided, thereby allowing the deletion or replacement of the above-mentioned hash information.

[0106] In other words, in an exemplary embodiment, the method further comprises:

[0107] If the second hash information associated with the second data portion is deleted, then:

[0108] - causing deletion of relationship information relating the second hash information to the second data portion and maintained available by the indexer; and

[0109] If causing the new second hash information to be stored in association with the new second data portion of the at least one data block as part of the distributed ledger, then:

[0110] - causing the relationship information associating the second hash information with the second data portion and kept available by the indexer to be replaced with the relationship information associating the new second hash information with the new second data portion and kept available by the indexer.

[0111] Furthermore, if the sequence of data blocks and / or the sequence of the associated pieces of hash information are relevant to an application, the indexer maintains the corresponding relationship information available. In other words, in an exemplary embodiment, the indexer maintains grouping information defining the sequence of at least two data blocks and / or the sequence of at least two pieces of hash information associated with the at least two data blocks as belonging to a group of data blocks and / or hash information corresponding to a specific application (e.g., processing of a shipment, a transaction, and / or a smart contract). Thus, in contrast to, for example, a conventional blockchain system, the distributed ledger system provides the dependency relationships between the corresponding groups of data blocks and / or hash information via an entity separate from the data blocks (via the indexer), which helps enhance the aforementioned flexibility in managing data in the distributed ledger system.

[0112] Similar to the case of storing new second hash information, in an exemplary embodiment, causing the second hash information to be deleted includes:

[0113] - Causing an indexer of the distributed ledger system to delete the relationship information stored in a manner accessible and / or manageable by the indexer and relating the second data portion to the second hash information.

[0114] In an exemplary embodiment, a distributed ledger includes at least two items of hash information, wherein a corresponding item of hash information is associated with a data block, wherein the corresponding data block includes data representing a corresponding stage of processing of an application (e.g., processing of a shipment, a transaction, and / or a smart contract) involving a group (one or more) of at least two nodes of a peer-to-peer network, and wherein the corresponding data block including the data representing the corresponding stage of the application processing is stored in at least one data storage portion of a memory portion allocated to a corresponding node in the group of nodes.

[0115] Thus, in an exemplary embodiment, respective data blocks including data representing corresponding stages of application processing are stored independently of the distributed ledger. To this end, in an exemplary embodiment, the respective data blocks are stored logically separate from the distributed ledger. Furthermore, in an exemplary embodiment, the distributed ledger is stored in a decentralized manner, wherein respective nodes of the peer-to-peer network store at least a portion of the distributed ledger in a portion of the distributed ledger memory allocated to the respective node.

[0116] In an exemplary embodiment, the method according to the first aspect or the second aspect further comprises:

[0117] - obtaining or causing to be obtained application-related messages from an external device or from a node of the peer-to-peer network;

[0118] - generating or causing the generation of a message token; and

[0119] - providing or causing to be provided the message token to the external device in response to receiving a message associated with the application.

[0120] Thus, the external device corresponds in an exemplary embodiment to an external device as disclosed in the context of the first aspect (e.g., a partner node further disclosed herein). For example, once the external device is logged in, the external device and the distributed ledger system (one or more nodes thereof) can perform processing of the application. Similarly, application-related messages can be received from nodes of a peer-to-peer network. Thus, in an exemplary embodiment, the application includes an application related to the processing of cargo shipments, general transactions, and / or smart contracts. Thus, in an exemplary embodiment, the application-related message includes a request to start application processing between an external device or a node of a peer-to-peer network and a distributed ledger system (one or more nodes thereof), such as a cargo shipment request, a reservation request, etc. In an exemplary embodiment, the application-related message may further include a request for the status of the application processed between the distributed ledger system and the external device or a node of the peer-to-peer network.

[0121] In an exemplary embodiment, a message token is generated based on information included in a message related to the application.

[0122] In an exemplary embodiment, a message token represents a state of an application processed between the distributed ledger system and the external device. Thus, in an exemplary embodiment, a message token may include or relate to a digital identity of an application processed between the distributed ledger system and the external device.

[0123] In an exemplary embodiment, the message token includes information based on which the external device can access state information about the state of an application processed between the external device and the distributed ledger system. For example, the message token may include a link based on which the external device can access an internet address / page that makes available the information about the state of the application, and can then display the information to a user of the external device, for example, via a display connected to the external device.

[0124] In an exemplary embodiment, the message token includes a quick response (QR) code configured to enable the external device to access status information about the status of an application processed between the external device and a node of the peer-to-peer network. The QR code may, for example, correspond to a salted QR code and, in an exemplary embodiment, include a hash value generated based on at least a portion of the obtained decentralized identifier. In this way, the QR code can be securely verified to be from a distributed ledger system on the external device side to prevent fraud that may result when the corresponding QR code is used by an illegal entity.

[0125] In an exemplary embodiment, the distributed ledger includes a set of hash indices and / or hash values ​​(data representing hash indices and / or hash values), wherein the corresponding hash indices and / or hash values ​​(data representing the corresponding hash indices and / or hash values) are associated with corresponding data blocks and / or corresponding portions of data blocks stored on a storage device of one or more nodes of the peer-to-peer network or connected to the one or more nodes, independently of the distributed ledger. Thus, in an exemplary embodiment, a data block represents at least a portion of the data (payload data) of an application (e.g., processing of a shipment, transaction, and / or smart contract). The data of the data block may, for example, correspond to data (at least a portion of the data) related to the content and / or participants of the application at a certain point in time (e.g., at the start time, at an intermediate time, or at a certain point in time after the application is completed). As mentioned above, one or more nodes of the peer-to-peer network may include or be connected to corresponding local storage devices for storing data related to the application involved in the one or more nodes. To provide data security, consensus, and immutability, the hash values ​​generated based on the corresponding data blocks are stored as part of the distributed ledger. Thus, in an exemplary embodiment, changes, deletions, or replacements of corresponding hash values ​​and / or hash indices stored as part of a distributed ledger are subject to a consensus process involving at least one or more nodes involved in the application processing, in particular all nodes of a peer-to-peer network.

[0126] For example, if a shipping process involves three nodes of a distributed ledger system, data related to various stages of the shipping process can be stored in the form of data blocks representing the various stages of the shipping process on corresponding storage devices of or connected to each of the three nodes involved in the shipping process. Hash values ​​and / or hash indices associated with (e.g., generated based on) the corresponding data blocks (and corresponding stages) are stored as part of the distributed ledger, such that deletion, replacement, and / or modification of the corresponding hash values ​​and / or hash indices must undergo a consensus process among at least one of the three nodes involved in the shipping process and / or one, more, or all of the nodes in the peer-to-peer network. It should be noted that in this case, the consensus process may be limited to the three nodes involved. In this way, flexibility is provided on the one hand (because access to the data can be restricted and / or modified later), while the required consensus process provides a sufficient degree of security and immutability.

[0127] In an exemplary embodiment, the method according to the first aspect and / or the method according to the second aspect is performed by the distributed ledger system. In other words, in an exemplary embodiment, the method according to the first aspect and / or the method according to the second aspect is performed by one or more nodes of a peer-to-peer network.

[0128] Thus, in an exemplary embodiment, the distributed ledger system includes an indexer (e.g., a software module or function implemented at at least one node), the indexer configured to assign corresponding hash information (e.g., first hash information and second hash information, e.g., corresponding hash values) to at least a portion of the data block and / or the sub-block (at least the first data portion and the second data portion, respectively) by applying a hash function based on corresponding data blocks of the distributed ledger and / or based on corresponding sub-blocks of the distributed ledger independently of different data blocks and / or different sub-blocks. Further, in an exemplary embodiment, corresponding relationships between hash indices and / or hash values ​​associated with a set of data blocks are stored so as to be accessible and / or manageable by the indexer.

[0129] Thus, in contrast to conventional blockchains where, for example, a data block is related to a previous data block by including a hash value generated based on the previous data block, temporal and / or content-related relationships between data blocks stored in relation to the distributed ledger of the distributed ledger system disclosed herein are maintained, for example, via a separate responsible entity (i.e., an indexer) (e.g., a software module or functionality implemented at the at least one node and / or one or more other nodes of the peer-to-peer network) to enable a certain degree of flexibility while maintaining a sufficient degree of security and immutability.

[0130] It should be noted that, while the present disclosure is not limited in this respect, the method according to the second aspect can be performed, for example, between at least one node of a peer-to-peer network and an external device. Thus, in an exemplary embodiment, obtaining or causing to be obtained modification request information associated with at least one data block includes receiving the modification request information from the external device. Furthermore, in an exemplary embodiment, storing or causing to be stored at least one data block includes storing or causing to be stored at least one data block associated with an application processed by the distributed ledger system and the external device.

[0131] Therefore, in an exemplary embodiment, the method according to the second aspect can be performed between a distributed ledger system and a logged-in external device. Therefore, in an exemplary embodiment, the method according to the second aspect comprises the following steps, which are performed in particular before the step of storing or causing the storage of at least one data block:

[0132] - receiving or causing reception of a connection establishment message from at least one external device, or transmitting or causing transmission of the connection establishment message to the at least one external device;

[0133] - obtaining or causing to be obtained a decentralized identifier representing the external device based on the connection establishment message;

[0134] - obtaining or causing to be obtained at least one hash value generated based on at least a portion of the obtained decentralized identifier;

[0135] storing or causing to be stored the at least one hash value in association with at least a portion of the decentralized identifier in a secured portion of a memory of a distributed ledger system comprising the peer-to-peer network based on a consensus process involving at least a subset of the nodes of the peer-to-peer network.

[0136] In an exemplary embodiment, the external device corresponds to or is included in a mobile device, and the mobile device includes:

[0137] - a thin client that enables the mobile device to perform the functions of a node of the distributed ledger system.

[0138] In other words, in an exemplary embodiment, the mobile device is enabled by the thin client to function as a node of the distributed ledger system and can therefore be configured to perform corresponding functions, such as, in particular, the generation of a hash value. Thus, in an exemplary embodiment, the thin client includes an indexer that enables the mobile device to be configured to generate a hash value based on at least a portion of a decentralized identifier obtained from a node of the distributed ledger system. While the mobile device is thus enabled to store or cause to be stored the hash value and / or index as part of the distributed ledger, the mobile device can be configured to store corresponding data blocks associated with applications processed between the mobile device and the distributed ledger system in an external storage device, such as a cloud storage device.

[0139] It should be understood that the present disclosure in this section is presented by way of example only and not limitation.

[0140] Other features of the present disclosure will become apparent from the following detailed description considered in conjunction with the accompanying drawings. However, it should be understood that the drawings are designed for illustrative purposes only and not as a definition of the limits of the present disclosure, with reference to the appended claims being made thereto. It should be further understood that the drawings are not drawn to scale and are intended merely to conceptually illustrate the structures and procedures described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0141] Figure 1A is a schematic high-level block diagram of a distributed ledger system;

[0142] Figure 1B is a schematic high-level block diagram of the dedicated interface;

[0143] Figure 1C is a schematic high-level block diagram of the application programming interface;

[0144] Figure 2 is an exemplary flow chart illustrating an exemplary embodiment according to the first aspect of the present disclosure;

[0145] Figure 3 It is demonstrated that Figure 2 an exemplary flow chart of an exemplary embodiment of steps of a method performed as part of a method;

[0146] Figure 4 It is demonstrated that Figure 2 methods and / or Figure 3 an exemplary flow chart of an exemplary embodiment of steps of a method performed as part of a method;

[0147] Figure 5 is an exemplary flow chart illustrating an exemplary embodiment of a message ingestion process;

[0148] Figure 6 is an exemplary flow chart illustrating an exemplary embodiment of data communication between a node and a partner node of a peer-to-peer network;

[0149] Figure 7 is an exemplary flow chart illustrating an exemplary embodiment according to the second aspect of the present disclosure;

[0150] Figure 8 is an exemplary flow chart illustrating exemplary embodiment processing of an application;

[0151] Figure 9A Schematic representation of the data storage allocated to the nodes;

[0152] Figure 9B The data blocks and corresponding hash information are schematically shown;

[0153] Figure 9C Schematic representation of data blocks, corresponding hash information, and indexers;

[0154] Figure 9D The data blocks and corresponding hash information are schematically shown;

[0155] Figure 9E Schematic representation of data blocks, corresponding hash information, and indexers;

[0156] Figure 10 is a block diagram of an exemplary embodiment of at least one apparatus according to the first aspect;

[0157] Figure 11 shows exemplary data blocks and corresponding hash indexes; and

[0158] Figure 12 Exemplary nodes and / or node systems in communication with a distributed ledger system are shown. DETAILED DESCRIPTION

[0159] The following description is intended to enhance understanding of the present disclosure and should be understood to supplement and be read together with the description of example embodiments of the present disclosure as provided in the above Summary section of this specification.

[0160] Figure 1A is a schematic high-level block diagram of a distributed ledger system 1000 (e.g., a distributed ledger database system). According to exemplary embodiments disclosed herein, a distributed ledger is a collection of digital data accessible by one or more nodes forming or connected to a peer-to-peer network having nodes, such as fixed or portable personal computers, servers, server systems, and / or mobile devices. Figure 1AAn exemplary peer-to-peer network 100 is shown formed by a first node 101, a second node 102, a third node 103 and a fourth node 104. As indicated by the corresponding dashed lines, the peer-to-peer network 100 is not limited to the nodes exemplarily shown in the figure but may include more or fewer nodes.

[0161] In an exemplary embodiment, the distributed ledger is stored on memory 110, at least portions of which may be distributed across some or all of the nodes in peer-to-peer network 100. Thus, at least corresponding portions of the distributed ledger may be redundantly stored on some or all of the nodes in peer-to-peer network 100. In other words, in an exemplary embodiment, the corresponding nodes of peer-to-peer network 100 are configured to store at least a portion of the distributed ledger, in particular a complete copy. To this end, in an exemplary embodiment, the corresponding nodes of peer-to-peer network 100 include and / or are connected to a storage device that includes at least a portion of memory 110 for storing the at least a portion of the distributed ledger. In an exemplary embodiment, the distributed ledger includes data representing one or more hash values, indices, and / or hash indices, each corresponding to corresponding data, in particular user data or payload data. Thus, in an exemplary embodiment, data corresponding to the corresponding hash value, index, and / or hash index is stored locally on the storage device of one or more nodes forming a subset of the nodes of peer-to-peer network 100.

[0162] like Figure 1A As shown in the example, the distributed ledger is stored as a plurality of data blocks 111, 112, 113, and 114. Figure 1A As indicated by the dotted lines in FIG, it should be noted that the number of data blocks of the distributed ledger is not limited to four as exemplarily shown, but can be less than or greater than four. Figure 1AAs shown, corresponding hash values ​​identified by corresponding hash indexes #1, #2, #3, and #4 are assigned to corresponding data blocks 111, 112, 113, and 114. To this end, in an exemplary embodiment, distributed ledger system 1000 includes an indexer 121 configured to assign a corresponding hash value to at least a portion of a corresponding data block of the distributed ledger. It should be noted that more than one hash value can be assigned to a data block. For example, a data block can be divided into two or more sub-blocks or data portions (e.g., a data block can include a first data portion and a second data portion), and a corresponding hash value can be assigned to a corresponding sub-block or data portion. In an exemplary embodiment, indexer 121 is configured to assign a hash value to the data block and / or the sub-block or data portion by applying a hash function based on the corresponding data block and / or based on the sub-block or data portion. For example, indexer 121 can apply the hash function based on and / or using data included in the data block and / or sub-block or data portion. In an exemplary embodiment, indexer 121 corresponds to a software module and / or function implemented as executable code configured to control the functions of indexer 121. In an exemplary embodiment, indexer 121 is implemented at one or more nodes of peer-to-peer network 100. Further, in an exemplary embodiment, indexer 121 is configured to assign a hash value to a data block and / or a sub-block or a data portion by applying a hash function based on the corresponding data block and / or based on a sub-block or a data portion and independently of data blocks and / or sub-blocks or data portions generated before or after the corresponding data block and / or sub-block or data portion.

[0163] Thus, in exemplary embodiments, corresponding relationships between hash indices associated with a group of data blocks (e.g., a group of data blocks belonging to the same application) (which may be represented by grouping information further disclosed herein) are maintained and stored so as to be accessible and manageable by indexer 121. Thus, in contrast to conventional blockchains, distributed ledger system 1000 provides dependencies between groups of data blocks via indexer 121. Thus, distributed ledger system 1000 is provided with an enhanced degree of flexibility (since data blocks and / or corresponding sub-blocks or data portions may be modified, deleted, or replaced) while maintaining corresponding relationships between data blocks and / or corresponding sub-blocks or data portions at indexer 121. Furthermore, while deletion, replacement, and / or modification of hash information and / or data blocks may thus be possible, in exemplary embodiments, such deletion, replacement, and / or modification is subject to a consensus mechanism based on consensus controller 122, such that the level of security provided by distributed ledger system 1000 is similar to that provided by conventional blockchain technology. While a consensus mechanism may specifically allow certain data to be stored as immutable, the same mechanism may allow different data to be stored as mutable.

[0164] like Figure 1A As further shown, the distributed ledger system 1000, in the exemplary embodiment, further includes a partner discoverer 123, which, in the exemplary embodiment, is a software module and / or function implemented as executable code configured to make available partner information of one or more partner nodes, whereby the partner node may be a node in the peer-to-peer network 100 or a node that is not part of the distributed ledger system 1000. In the exemplary embodiment, the partner discoverer 123 corresponds to a software module and / or function implemented as executable code configured to control the functionality of the partner discoverer 123. In the exemplary embodiment, the partner discoverer 123 is implemented at one or more nodes in the peer-to-peer network 100. In the exemplary embodiment, the partner discoverer 123 is an application programming interface (API)-based (software) module configured to maintain (e.g., store) a registry including information related to one or more partner nodes and / or information related to one or more nodes in the peer-to-peer network and / or one or more applications associated with the one or more partner nodes. In an exemplary embodiment, the partner discoverer 123 is a (software) module configured to generate a decentralized identifier representing (e.g., identifying) a partner node based on corresponding information related to the partner node received from one or more of the nodes of the peer-to-peer network 100 and / or received from the partner node (e.g., from a dedicated interface). For example, Figure 1A A partner node 190 is shown communicating with node 104 of peer-to-peer network 100 via a dedicated interface 150. In an exemplary embodiment, dedicated interface 150 includes a software development kit (SDK) 151 and / or an application programming interface (API) 152. It should be noted that partner finder 123 can therefore correspond to an exemplary embodiment of a decentralized identifier acquirer. In an exemplary embodiment, partner finder 123 is further configured to generate a pair of public and private keys to be assigned to partner node 190, and / or to assign and / or maintain available information setting and / or defining a partner role for the partner node, the partner role defining access rights and / or read / write permissions for the partner node.

[0165] In the exemplary embodiment, distributed ledger system 1000 further includes one or more additional software modules and / or functions implemented as executable code configured to control corresponding functions and / or operations of the blockchain. In particular, in the exemplary embodiment, distributed ledger system 1000 further includes the consensus controller 122, which, in the exemplary embodiment, is a software module and / or function implemented as executable code configured to implement a consensus mechanism, specifically ensuring that new data blocks are added to the distributed ledger and / or existing data blocks are modified and / or removed from the distributed ledger only when consensus is reached among at least some or all of the nodes of peer-to-peer network 100. Furthermore, in the exemplary embodiment, consensus controller 122 is configured to control the storage of at least one hash value associated with at least a portion of a decentralized identifier in the secured portion 140 of memory 110 of distributed ledger system 1000, based on a consensus process involving at least a subset of the nodes of the peer-to-peer network. In the exemplary embodiment, consensus controller 122 is implemented at one or more nodes of peer-to-peer network 100. It should be noted that the consensus mechanism can be implemented such that one or more nodes in a node subgroup can express consensus on adding new data blocks and / or changing / deleting existing data blocks, i.e., the implementation can be such that a single node can express consensus.

[0166] like Figure 1A As exemplarily shown in , in an exemplary embodiment, the indexer 121, the consensus controller 122 and the partner discoverer 123 are implemented as corresponding modules of the controller 120, which in the exemplary embodiment corresponds to a software module and / or function implemented as an executable code configured for controlling at least the functions of the indexer 121, the consensus controller 122 and the partner discoverer 123, and the controller 120 is implemented at one or more nodes of the peer-to-peer network 100.

[0167] Referring back to the memory 110, in an exemplary embodiment, the data blocks 111, 112, 113, 114 may specifically represent the processing of a transaction, shipment, and / or smart contract. Thus, in an exemplary embodiment, the corresponding data blocks represent the stages of the transaction, shipment, and / or smart contract. The corresponding data blocks may be generated as a result of communication between one or more nodes of the peer-to-peer network 100 and a partner node (such as at least one external device). For example, the corresponding data blocks may be generated based on Figure 1A The corresponding data blocks are generated by communication between the partner node 190 and the node 104 of the peer network 100 via the dedicated interface 150. Figure 1BAs shown, the dedicated interface 150 includes a software development kit (SDK) 151 and / or an application programming interface (API) 152 in an exemplary embodiment. In an exemplary embodiment, the API 152 includes one or more content addressable APIs. In other words, the API 152 may include or correspond to a plurality of corresponding APIs provided for corresponding functions. For example, Figure 1C As shown, in an exemplary embodiment, the distributed ledger system 1000 includes a message ingestion API 152.1 implemented as part of the API 152. In an exemplary embodiment, the message ingestion API 152.1 is configured to respond to an incoming message from the partner node 190, e.g., an incoming message related to an application processed between the partner node 190 and the distributed ledger system 1000, with an interaction identifier (e.g., a message token), which can be used by the partner node 190 to query the processing status and details related to the application.

[0168] like Figure 1C As further shown, in an exemplary embodiment, the distributed ledger system 1000 includes a decentralized identifier resolver API 152.2 implemented as part of the API 152. In an exemplary embodiment, the decentralized identifier resolver API 152.2 is configured to resolve decentralized identifiers associated with and received from a partner node 190. The decentralized identifier resolver API 152.2 is particularly useful in situations where the partner node 190 is part of a non-distributed ledger system (e.g., a non-blockchain system) that includes multiple nodes assigned to respective decentralized identifiers generated for the non-distributed ledger system. In such situations, the distributed ledger system 1000 can take over the role of a master of server (MoS) with respect to decentralized identifiers.

[0169] After the onboarding process has been performed between the distributed ledger system 1000 and the partner node 190 , the partner node 190 may communicate with any one or more of the nodes of the peer-to-peer network 100 . Figure 2 2 is an exemplary flow chart 200 illustrating an exemplary embodiment according to the first aspect of the present disclosure. The flow chart 200 can be understood as illustrating an exemplary login process for logging into the partner node 190. Without limiting the scope of the present invention, it is assumed in the following that, as described above with respect to Figure 1A The disclosed peer-to-peer network 100 has nodes 104 that are connected to the peer-to-peer network 100 as described above. Figure 1AThe steps of flowchart 200 are performed when communicating with the disclosed partner node 190 (an example of an external device). It should be noted that the steps of flowchart 200 can also be performed by any one or more nodes in the peer-to-peer network 100. Thus, node 104 and / or its corresponding processor can correspond to an example of at least one device according to the first aspect disclosed herein. Furthermore, the method of flowchart 200 can be performed by the distributed ledger system 1000, for example, by one or more nodes in the peer-to-peer network 100 and / or by any of the modules of the distributed ledger system 1000 disclosed herein.

[0170] In step 201, the node 104 receives (and / or, for example, the processor of the node 104 causes the node 104 to receive) a connection establishment message from the partner node 190 (an example of the at least one external device). Alternatively, the node 104 may transmit (and / or, for example, the processor of the node 104 causes the node 104 to transmit) the connection establishment message to the partner node 190.

[0171] For example, in an exemplary embodiment, the distributed ledger system 1000 is configured to (i.e., include software modules and / or functions implemented as executable code at one or more of the nodes of the peer-to-peer network 100 and configured to control) provide at least one software development kit (SDK) to the partner node 190, e.g. Figure 1B The SDK 151 exemplarily illustrated in FIG. 1 , which enables partner node 190 to perform various operations when communicating with distributed ledger system 1000, is used. Based on SDK 151, in exemplary embodiments, partner node 190 and / or distributed ledger system 1000 are enabled to manage various interactions between distributed ledger system 1000 and partner node 190. For example, partner node 190 may use SDK 151 to send a request to node 104 to create a decentralized identifier. Furthermore, SDK 151 may include one or more libraries related to decentralized identifiers, enabling SDK 151 to perform authentication functions based on decentralized identifiers or interact with distributed ledger system 1000.

[0172] Return Reference Figure 2In step 203, node 104 obtains a decentralized identifier representing partner node 190 based on the connection establishment message. Thus, in the exemplary embodiment, the decentralized identifier is generated at distributed ledger system 1000, in the exemplary embodiment by partner discoverer 123. Alternatively or additionally, the decentralized identifier can be obtained by receiving the decentralized identifier from partner node 190. This latter scenario may apply, for example, to situations where partner node 190 itself is a node of a non-distributed ledger system (e.g., a non-blockchain network), which includes nodes configured to communicate with each other based on the decentralized identifier. An example of such a system may correspond to, for example, an SAP HANA system. In this case, the distributed ledger system may take over the role of Master of Server (MoS).

[0173] In contrast to traditional identifiers and / or identities that are typically defined with respect to centralized registries, identity providers, and certificate authorities, in exemplary embodiments, decentralized identifiers are generated by a corresponding controller (e.g., in the case of distributed ledger system 1000, partner discoverer 123), which defines what the decentralized identifier identifies. As mentioned, while the decentralized identifier may be received from partner node 190 via interface 150, a decentralized identifier identifying partner node 190 may also be received from partner node 190. In this case, for example, the distributed ledger system to which partner node 190 belongs may include a controller that has generated the decentralized identifier.

[0174] In an exemplary embodiment, a decentralized identifier (generated by partner discoverer 123 or received via interface 150) is defined in association with a decentralized identifier document. Thus, in an exemplary embodiment, the decentralized identifier corresponds to or includes a uniform resource locator (URL) that associates the subject identified by the decentralized identifier (e.g., partner node 190) with the decentralized identifier document. In an exemplary embodiment, the decentralized identifier document maintains information regarding or defining one or more public keys associated with the decentralized identifier, authentication information associated with the decentralized identifier (e.g., one or more authentication and / or verification methods), a service endpoint, and / or semantics of the subject identified by the decentralized identifier (e.g., partner node 190). The service endpoint can enable trusted interactions associated with the subject of the decentralized identifier (e.g., partner node 190). The service endpoint can, for example, correspond to any one or more nodes of peer-to-peer network 100 and / or to partner node 190 and can be identified by their corresponding addresses (e.g., by their MAC addresses). It should be noted that, in an exemplary embodiment, one or more security keys maintained by the decentralized identifier key are based on or generated in the form of a salt, whereby the salt may be understood as, for example, corresponding to random data used as an additional input to a function for creating a corresponding security key and / or hash value. In an exemplary embodiment, the decentralized identifier document may further include a timestamp (e.g., for audit history) and / or a signature (e.g., for integrity). In an exemplary embodiment, the decentralized identifier document may correspond to or include metadata associated with the decentralized identifier, for example, stored at memory 110.

[0175] Consequently, in exemplary embodiments, a decentralized identifier is an identifier generated at the distributed ledger system 1000 and / or on the partner node 190 side based on attributes of the partner node 190 (a public key provided to the partner node 190 for accessing data maintained at the distributed ledger system 1000, a service endpoint of the partner node 190, and / or an application to be executed by the partner node 190 and the distributed ledger system 1000, and / or semantics regarding the partner node 190) and associated with a decentralized identifier document. Although decentralized identifiers according to various aspects disclosed herein are not limited in this respect, in exemplary embodiments, the decentralized identifier includes or corresponds to a DID specified by the World Wide Web Consortium (W3C).

[0176] As mentioned, API 152 includes Figure 1C1. The decentralized identifier resolver API 152.2 is shown, which is configured to resolve a decentralized identifier associated with and received from a partner node 190. In particular, where the partner node 190 is part of another distributed ledger system (e.g., a blockchain system), the decentralized identifier may be associated with a decentralized identifier scheme defined at the other distributed ledger system. In this case, the decentralized identifier resolver API 152.2 is configured to resolve the decentralized identifier received from the partner node 190. In particular, in an exemplary embodiment, the decentralized identifier resolver API 152.2 is configured to resolve decentralized identifiers received from a Hyperledger Fabric blockchain platform, a Corda DLT, a multi-chain blockchain, and / or a Quorum blockchain platform.

[0177] Return Reference Figure 2In step 205, node 104 obtains at least one hash value generated based on at least a portion of the decentralized identifier obtained in step 203. For example, in an exemplary embodiment, indexer 121 of distributed ledger system 1000 is configured to generate a hash value based on at least a portion of the decentralized identifier obtained in step 203, for example, by applying a hash function to at least a portion of the decentralized identifier. Indexer 121 may therefore correspond to an exemplary embodiment of a hash value obtainer. In particular, a hash value may be obtained based on any portion of the decentralized identifier referenced in a decentralized identifier document. In particular, in an exemplary embodiment, node 104 obtains at least one hash value generated based on the corresponding addresses (e.g., MAC addresses) of one or more service endpoints and / or one or more public keys included in a decentralized identifier document associated with the decentralized identifier. Thus, in an exemplary embodiment, the service endpoint includes at least one of the address (e.g., MAC address) of node 104 and the address (e.g., MAC address) of partner node 190. In particular, in an exemplary embodiment, the indexer 121 of the distributed ledger system 1000 is configured to generate a hash value based on one or more service endpoints and / or one or more public keys included in a decentralized identifier document associated with a decentralized identifier. As mentioned, the indexer 121 (which may also be referred to as a hash generator of the distributed ledger system 1000) may be implemented as a software module of any one or more of the nodes of the peer-to-peer network 100. Thus, the node 104 may obtain the at least one hash value directly if the indexer 121 is implemented at the node 104, and / or obtain the at least one hash value indirectly if the indexer 121 is implemented at any one or more other nodes of the peer-to-peer network 100. In the latter case, the at least one hash value may be stored in a portion of the memory 110 shared by the node 104 and the one or more other nodes of the peer-to-peer network 100, such that the node 104 can access (and therefore obtain) the at least one hash value.

[0178] In other words, if Figure 2As further shown in FIG. 2 , in step 207, node 104 may, based on a consensus process involving at least a subset of the nodes of peer-to-peer network 100, store the at least one hash value, or may cause any one or more of the nodes of peer-to-peer network 100 to store the at least one hash value in association with at least a portion of the decentralized identifier (in an exemplary embodiment, in association with at least a portion of a decentralized identifier document of the decentralized identifier and / or the decentralized identifier document), in the secured portion 140 of memory 110 of distributed ledger system 1000. Note that in step 207, both the hash value and the decentralized identifier may be stored in association in the secured portion 140. In an exemplary embodiment, the consensus process may further involve partner node 190.

[0179] For example, consensus processing implemented at one or more or all of the nodes of the peer-to-peer network 100 and / or at the node 190 in the form of a consensus controller 122 may be initiated, for example, by the node 104 based on communication with the partner node 190 to obtain a consensus between the one or more nodes participating in the consensus processing, i.e., the at least one hash value may be stored at the secured portion 140 of the memory 110. Thus, in an exemplary embodiment, the consensus processing may be limited to a subset of the nodes of the peer-to-peer network 100. In an exemplary embodiment, the consensus processing is limited to a subset of the nodes of the peer-to-peer network 100 and the partner node 190. The subset of nodes of the peer-to-peer network 100 may, for example, correspond to a set of nodes involved in application processing with the partner node 190 (e.g., Figure 1A ), for the group of nodes, a login process is performed or has been performed together with the partner node 190.

[0180] In an exemplary embodiment, the secured portion 140 of the memory 110 corresponds to a dedicated portion of memory that corresponds to or includes a corresponding dedicated storage space provided at and / or connected to one, more, or all of the nodes in the peer-to-peer network 100, and / or corresponds to a cloud storage device connected to and / or accessible by one, more, or all of the nodes in the peer-to-peer network 100. In an exemplary embodiment, the secured portion 140 of the memory 110 is configured to provide identity-based access to the secured portion 140, e.g., the secured portion 140 provides access only to identified users. Further, in an exemplary embodiment, the secured portion 140 of the memory 110 is configured to encrypt stored data, e.g., to maintain the data in an encoded form such that only authorized parties can decode the encoded data to access the original information. Although aspects of the present disclosure are not limited in this respect, in an exemplary embodiment, the secured portion 140 of the memory 110 corresponds to or includes a repository, particularly a specific repository assigned to the distributed ledger, a HashiCorp repository, an on-premises repository, and / or a cloud-based secure key repository.

[0181] Furthermore, in an exemplary embodiment, node 104 is configured to provide the at least one hash value generated based on at least a portion of the obtained decentralized identifier, in particular in association with the decentralized identifier, to partner node 190. As further disclosed herein, the at least one hash value, which may in particular include a hash value generated based on endpoint information (e.g., a MAC address) of partner node 190, may enable an additional device to verify the identity of partner node 190 when communicating with partner node 190 after partner node 190 logs in, and thus may provide an additional level of security.

[0182] It should be noted that, in exemplary embodiments, the SDK 151 provided to the partner node 190 may enable the partner node 190 and the distributed ledger system 1000 to further establish a digital twin-based machine-to-machine pairing based on a decentralized identifier in exemplary embodiments. For example, the machine pairing established in this manner may enable the provision of a digital twin of at least a portion of the distributed ledger system 1000, in particular one or more nodes (e.g., node 104) of the peer-to-peer network 100, to the partner node 190.

[0183] Figure 3 It is shown as a reference Figure 2 An exemplary flowchart 300 of an exemplary embodiment of the steps of a method for performing a portion of the method of flowchart 200 is shown. Without limiting the scope of the present invention, it is assumed in the following that, as described above with respect to Figure 1AThe disclosed peer-to-peer network 100 has nodes 104 that are connected to the peer-to-peer network 100 as described above. Figure 1A The steps of flowchart 300 are performed when communicating with the disclosed partner node 190 (an example of an external device). It should be noted that the steps of flowchart 300 can also be performed by any one or more nodes in peer-to-peer network 100. Thus, node 104 and / or its corresponding processor can correspond to an example of at least one device according to the first aspect disclosed herein. Furthermore, the method of flowchart 300 can be performed by distributed ledger system 1000, for example, by one or more nodes in peer-to-peer network 100 and / or by any of the modules of distributed ledger system 1000 disclosed herein.

[0184] As shown, in step 301, at least one pair of public and private keys is distributed to partner node 190. For this purpose, for example, partner finder 123 can generate a pair of public and private keys to distribute to partner node 190, wherein, as mentioned herein, public and private keys correspond to asymmetric cryptography and / or are generated based on asymmetric cryptography. In an exemplary embodiment, the key is generated based on the elliptic curve digital signature algorithm (ECDSA), which can make it possible to use smaller keys, providing a security level similar to that of keys based on non-elliptic curve cryptography. Thus, in an exemplary embodiment, these keys are generated based on SECP256K1 and / or SECP156R1 curves. It should be noted that, in an exemplary embodiment, step 301 is performed as a step according to the method of flowchart 200, and can be performed before, after, or in conjunction with step 203.

[0185] Furthermore, in step 303, node 104 provides the public key to partner node 190, and in step 305, based on a consensus process involving at least a subset of the nodes of peer-to-peer network 100, at least the private key is stored in association with at least a portion of the decentralized identifier in the secured portion 140 of memory 101 of distributed ledger system 1000. Thus, at least the storage of the private key can be performed based on the consensus process described in the context of step 207 for storing the at least one hash value. In an exemplary embodiment, in addition to the private key, a public key is also stored in the secured portion 140 of memory 101 of distributed ledger system 1000. In particular, in an exemplary embodiment, the private key and / or the public key are added to the decentralized identifier document assigned to the decentralized identifier stored in the secured portion 140.

[0186] Figure 4 It is shown as a reference Figure 2 The flowchart 200 shown and / or referenced Figure 3An exemplary flow chart 400 of an exemplary embodiment of the steps of a method performed as part of the method of the flowchart 300 is shown. Without limiting the scope of the present invention, it is assumed in the following that, as described above with respect to Figure 1A The disclosed peer-to-peer network 100 has nodes 104 that are connected to the peer-to-peer network 100 as described above. Figure 1A The steps of flowchart 400 are performed when communicating with the disclosed partner node 190 (an example of an external device). It should be noted that the steps of flowchart 400 can also be performed by any one or more nodes in the peer-to-peer network 100. Thus, node 104 and / or its corresponding processor can correspond to an example of at least one device according to the first aspect disclosed herein. Furthermore, the method of flowchart 400 can be performed by the distributed ledger system 1000, for example, by one or more nodes in the peer-to-peer network 100 and / or by any of the modules of the distributed ledger system 1000 disclosed herein.

[0187] As shown, in step 401, at least one partner role is assigned to partner node 190 that defines access rights and / or read / write permissions for partner node 190. Thus, in this exemplary embodiment, upon logging into partner node 190, partner node 190 is assigned a partner role that defines, for example, write access permissions that may be associated with messages transmitted from partner node 190 to distributed ledger system 1000. It should be noted that partner node 190 may have one or more partner roles that may be set for one or more applications processed between partner node 190 and distributed ledger system 1000.

[0188] In step 403, information setting the at least one partner role (e.g., data corresponding to the at least one partner role) is stored in association with at least a portion of the decentralized identifier in the secured portion 140 of the memory 110 of the distributed ledger system 1000 based on a consensus process involving at least a subset of the nodes of the peer-to-peer network 100. The storage of the information setting the at least one partner role can be performed based on the consensus process as described in the context of step 207 for storing the at least one hash value. In particular, in an exemplary embodiment, the information setting the at least one partner role (e.g., data corresponding to the at least one partner role) is added to a decentralized identifier document assigned to the decentralized identifier stored in the secured portion 140.

[0189] Thus, in an exemplary embodiment, the onboarding process performed between the distributed ledger system 1000 and the partner node 190 involves one or more of the following operations: providing the SDK 151 to the partner node 190; obtaining at least one decentralized identifier of the partner node 190 at the distributed ledger system 1000; obtaining at least one pair of private and public keys for encrypting communications between the distributed ledger systems 1000 and storing at least the private key in association with the decentralized identifier in the secured portion 140 of the memory 110 of the distributed ledger system 1000; and assigning a partner role to the partner node 190.

[0190] It should be noted that by storing the at least one hash value in association with at least a portion of a decentralized identifier, a private key and / or a public key, and / or information setting a partner role assigned to partner node 190 (e.g., information about the partner role) in the secured portion 140 of memory 110 of distributed ledger system 1000, this information is made available as partner information to partner discoverer 123 in an exemplary embodiment. Therefore, after a partner node logs in, this partner information is available for all nodes of peer-to-peer network 100, or at least a subset of nodes of peer-to-peer network 100 (e.g., nodes involved in application processing with partner node 190), and can be referenced in further communications with partner node 190. Thus, even in situations where nodes of distributed ledger system 1000 communicate with entities external to the distributed ledger system, specific security can be enabled for the corresponding communications. Based on decentralized identifiers, it is possible to secure communications between partner nodes of the peer-to-peer network 100 and entities external to the distributed ledger system, regardless of whether such partner nodes themselves are part of the distributed ledger system, blockchain system, or entities independent of such systems.

[0191] Figure 5 is an exemplary flow chart 500 illustrating an exemplary embodiment of a message ingestion process by which the distributed ledger system 1000 can consume messages from a partner node (e.g., from partner node 190). Without limiting the scope of the present invention, it is assumed in the following that, as described above with respect to Figure 1A The disclosed peer-to-peer network 100 has nodes 104 that are connected to the peer-to-peer network 100 as described above. Figure 1AThe disclosed partner node 190 (an example of an external device) uses the message ingestion API 152.1 (which can be implemented at the node 104 and / or at any one or more of the nodes 102, 103, 104 of the peer-to-peer communication network) to perform the steps of the flowchart 500. It should be noted that the steps of the flowchart 500 can also be performed by any one or more of the nodes of the peer-to-peer network 100. Further, the method of the flowchart 500 can be performed by the distributed ledger system 1000, for example, by one or more nodes of the peer-to-peer network 100 and / or by any of the modules of the distributed ledger system 1000 disclosed herein. It should be noted that the method of the flowchart 500 can be performed in accordance with Figure 2 The method is executed after the login process has been executed.

[0192] like Figure 5 As shown, in step 501, node 104 obtains (or the processor of node 104 causes node 104 to obtain) an application-related message from partner node 190 (an example of an external device). In an exemplary embodiment, such a message may correspond to, for example, a message from a customer of the owner of at least a portion of distributed ledger system 1000 notifying the owner of an order (e.g., an order for a shipment of goods). It should be noted that in an exemplary embodiment, partner node 190 may be configured to send the message to node 104 of peer-to-peer network 100 using the HTTPS (Hypertext Transfer Protocol Secure) protocol.

[0193] In step 503, the message ingestion API 152.1 causes the message content(s) and / or message attachment(s) to be stored. To this end, the message ingestion API 152.1 may cause the message content(s) and / or message attachment(s) to be stored, for example, in a local storage device of the node 104, i.e., separate from the memory 110. Alternatively or in addition, the message ingestion API 152.1 may cause the message content(s) and / or message attachment(s) to be stored in a portion of the memory 110 based on, for example, a consensus process involving the consensus controller 122.

[0194] In step 505, the message ingestion API 152.1 causes generation of at least one hash value based on the message content and / or generation of at least one hash value based on the message attachments (e.g., based on communication with the indexer 121). As part of step 505, the message ingestion API 152.1 may further cause storage of the hash value(s) generated in step 505 in a portion of memory 110 based on, for example, a consensus process involving the consensus controller 122.

[0195] In step 506, message ingestion API 152.1 generates or causes the generation of a message token, and in step 507, message ingestion API 152.1 provides or causes the provision of the message token to partner node 190 (an example of an external device) in response to the message received in step 501. For example, in an exemplary embodiment, the message token includes information based on which partner node 190 can access state information about the state of an application processed between partner node 190 and node 104 of peer-to-peer network 100. For example, the message token may include a link based on which partner node 190 can access an internet address / page that maintains the information about the state of the application. Further, in an exemplary embodiment, the message token includes a quick response (QR) code (particularly a salted QR code) configured to enable partner node 190 to access the state information. For example, partner node 190 can similarly access an internet address / page that maintains state information to be accessed by partner node 190 by referencing the QR code. The QR code may further include a hash value generated based on the decentralized identifier of partner node 190 and / or based on the decentralized identifier of node 104, which may enable partner node 104 to verify the QR code. Based on this, the status information may be displayed to the user of partner node 190, for example, via a display of partner node 190 and / or connected to the partner node.

[0196] It should be noted that in step 502, the message received in step 501 may be provided to a pre-processor 104.7 (described further herein), which in an exemplary embodiment is implemented at one or more nodes of the peer-to-peer network, particularly at node 104.

[0197] Figure 6 is an exemplary flow chart 600 illustrating an exemplary embodiment of data communication between a node 104 of a peer-to-peer network 100 and a partner node 190 after the login of the partner node 190 is completed. Without limiting the scope of the present invention, it is assumed in the following that, as described above with respect to Figure 1A The disclosed peer-to-peer network 100 has nodes 104 that are connected to the peer-to-peer network 100 as described above. Figure 1A The disclosed partner node 190 (an example of an external device) performs the steps of flowchart 600 when communicating.

[0198] As shown, in step 601, node 104 sends a message including information about an update phase of an application being processed while communicating with partner node 190, the message including a message token containing the information. To this end, node 104 may (e.g., using post-processor 104.9 implemented at node 104 and described further herein) retrieve an endpoint (e.g., a MAC address) associated with partner node 190 from partner discoverer 123 based on a decentralized identifier of partner node 190. Node 104 may further combine the information about the update phase of application processing (e.g., information about an invoice) as a message payload with a verifiable credential and may sign the verifiable credential using the node's private key. Node 104 may then publish the message combined with the signed verifiable credential to the endpoint of partner node 190.

[0199] Thus, in an exemplary embodiment, the form in which the message is published to the endpoint of the partner node 190 is or includes, for example, a QR code protected by a verifiable credential signed by the private key of the node 104, in particular a salted QR code. The QR code may include a link based on which the partner node 190 can access an internet address / page that maintains the information available about the update phase of the application process. The QR code may further include a hash value generated based on the decentralized identifier of the partner node 190 and / or based on the decentralized identifier of the node 104, which hash value may enable the partner node 104 to verify the QR code. Thus, the updated state may be visible to the user of the partner node 190, for example, via a display of the partner node 190 or connected to the partner node.

[0200] In step 603, node 104 receives a response message from partner node 190, the response message including, for example, response information for verifying the application status, for example, for approving the invoice. Further, in step 605, node 104 verifies the response message. For example, based on the decentralized identifier of partner node 190 mentioned or included in the response message, a digital twin pairing, i.e., a machine-to-machine pairing, is established between node 104 and partner node 190. Further, node 104 verifies the key pairing, for example, verifies that the public key included or mentioned in the response message is consistent with the public key in the Figure 3 The public key assigned to the partner node 190 in step 301 and stored in the secured portion 140 of the memory 110 of the distributed ledger system 1000 matches the public key.

[0201] In addition to key pairing, in an exemplary embodiment, node 104 is configured to confirm that a hash value included or referenced in a received message matches a hash value generated based on at least a portion of the obtained decentralized identifier. Since the hash value is generated, in an exemplary embodiment, based specifically on endpoint information referenced in a decentralized identifier document of the decentralized identifier of partner node 190, such hash value confirmation ensures that the node from which node 104 receives the response message actually corresponds to node 190 that is subject to the onboarding process.

[0202] As a third level of security, node 104 confirms the partner role included in the response message or mentioned in the response message in the form of corresponding information. By confirming that the partner role corresponds to the partner role assigned to partner node 190 during the login process and that the partner role allows the partner node to send the response message (e.g., to approve the invoice), an additional level of security is provided, which can help prevent the distributed ledger system 1000 (e.g., via node 104) from consuming fraudulent messages.

[0203] Further, if Figure 6 As shown, in step 607, if the response message passes verification, for example, if a digital twin machine-to-machine pairing is successfully established between node 104 and partner node 190, if a key pairing stored in the security part 140 and included in or mentioned by the response message is successfully established, and if it is confirmed that the hash value included in or mentioned by the response message corresponds to a hash value generated based on at least a portion of the obtained decentralized identifier when the partner node 190 logs in, the node 104 updates the data related to the application stored in the storage device of the node 104 and / or the corresponding hash value and / or hash index related to the data stored in the memory 110.

[0204] Therefore, the response message received from partner node 190 in step 603 may, for example, correspond to the approval of the invoice mentioned in the message sent in step 601, so that the data related to the corresponding application can be updated accordingly and / or the corresponding hash value can be updated accordingly. In this way, based on the communication between node 104 of peer-to-peer network 100 and external partner node 190, a consensus mechanism is established, which advantageously enables interoperability between distributed ledger system 1000 and, for example, another distributed ledger system to which partner node 190 may belong.

[0205] Further, return to reference Figure 6 In step 609, node 104 sends a message including information about the new updated stage of application processing (eg, "invoice approved") to partner node 190, the message including an updated message token containing the information.

[0206] As in the case where the message token is sent to partner node 190 in step 601, the form that the endpoint that this message is published to partner node 190 can take is or includes, for example, a QR code protected by a verifiable credential signed by the private key of node 104, in particular a salted QR code. This QR code may include a link, based on which partner node 190 can access an internet address / page that keeps the information available about the new update stage of application processing ("invoice approved"). This QR code may further include a hash value generated based on the decentralized identifier of partner node 190 and / or based on the decentralized identifier of node 104, which hash value may enable partner node 104 to verify this QR code. Therefore, the updated state may be visible to the user of partner node 190, for example, via a display of partner node 190 or connected to the partner node.

[0207] At the same time, node 104 (e.g., a post-processor of node 104 further mentioned herein) may store information indicating successful processing, for example, in a local storage device of node 104. Thus, node 104 may generate and / or update a verifiable credential, which may include, for example, a decentralized identifier of node 104, a decentralized identifier of partner node 190, a payload including a credential statement and a cryptographic proof, which may ensure the integrity of the verifiable credential. Specifically, the post-processor may create or update the verifiable credential by attaching a verifiable credential (VC) Id to the message and storing the VC in a local storage device of node 104.

[0208] In this way, immutability of data processed between the nodes 104 (of the distributed ledger system 1000 ) of the peer-to-peer network 100 and the external nodes 190 may be established.

[0209] Figure 7 700 is an exemplary flow chart illustrating an exemplary embodiment according to the second aspect of the present disclosure. Flow chart 700 can be understood as illustrating an exemplary method of storing data (e.g., payload data related to an application) in association with corresponding hash information and restricting access to the data stored in the second data portion at least at a later point in time. Without limiting the scope of the present invention, it is assumed in the following that, as described above with respect to Figure 1A The disclosed peer-to-peer network 100 has nodes 104 that are connected to the peer-to-peer network 100 as described above. Figure 1AThe disclosed partner node 190 performs the steps of flowchart 700 when communicating. It should be noted that the steps of flowchart 700 can also be performed by distributed ledger system 1000, for example, by any one or more nodes in peer-to-peer network 100. Thus, node 104 and / or its corresponding processor can correspond to an example of at least one device according to the second aspect disclosed herein. Furthermore, the method of flowchart 700 can be performed by distributed ledger system 1000, for example, by one or more nodes in peer-to-peer network 100 and / or by any of the modules of distributed ledger system 1000 disclosed herein.

[0210] In step 710, the node 104 stores (and / or the processor of the node 104 causes the node 104 to store) at least one data block. In an exemplary embodiment, the data block contains data related to a processing stage of an application (such as the processing of a shipment, a transaction, and / or a smart contract).

[0211] Step 710 includes or may correspond to step 711 of storing or causing to be stored a first data portion and a second data portion of at least one data block in a data memory portion assigned to at least one node (node ​​104), wherein the first data portion is stored as immutable data. Thus, the first data portion may be used to store data related to the application, such as, for example, the quantity or type of goods to be shipped in the case of shipments. The second data portion may be used to store data to which access may be restricted or blocked, or to be deleted when no longer needed, such as upon completion of processing of the application. For example, the second data portion may be used to store personal data of individuals involved in processing the application.

[0212] At step 720, node 104 causes the first hash information to be stored in association with the first data portion as part of the distributed ledger. At step 730, node 104 causes the second hash information to be stored in association with the second data portion as part of the distributed ledger. In an exemplary embodiment, the first hash information and the second hash information include or correspond to first and second hash values ​​and / or first and second hash indices corresponding to the first and second hash values. The hash information can be used to correlate with the corresponding data portion with which it is associated, and thus enable access to the corresponding data portion.

[0213] In step 740, node 104 obtains modification request information associated with at least one data block. For example, node 104 may receive a message including the modification request information from a node of a peer-to-peer network or from an external device such as partner node 190. In an exemplary embodiment, the modification request information corresponds to a request to modify a portion of a data block (particularly, the second portion) and / or a request to restrict access to a portion of a data block (particularly, the second portion). Thus, in an exemplary embodiment, the request to modify a portion of a data block and / or the request to restrict access to a portion of a data block corresponds to a request to remove certain data. For example, if an individual involved in the processing of an application requests that his or her personal data be removed after the application processing is completed, the request may result in access to the personal data being restricted and / or the personal data being removed.

[0214] In step 750, node 104 causes deletion of the second hash information associated with the second data portion or causes new second hash information to be stored as part of the distributed ledger in association with a new second data portion of at least one data block based on the modification request information and based on a consensus process performed at at least one node in the at least one group of nodes in the peer-to-peer network. For example, in an exemplary embodiment, if the modification request information relates to the second data portion, e.g., corresponds to data stored in the second data portion, node 104 causes the second hash information to be deleted or causes new second hash information to be associated with the new second data portion. Further, in an exemplary embodiment, if at least one node of the peer-to-peer network involved in the application process and / or the node that received the modification request information (e.g., by receiving a corresponding message) expressly consents to the modification, node 104 causes the second hash information to be deleted or causes new second hash information to be associated with the new second data portion.

[0215] Figure 8 is an exemplary flow chart 800 illustrating an exemplary embodiment of a process involving the nodes 103 and 104 of the peer-to-peer network 100 and an application of the partner node 190. Therefore, without limiting the scope of the present invention, it is assumed in the following that, as described above with respect to Figure 1A The disclosed peer-to-peer network 100 nodes 103 and 104 and partner node 190 perform the steps of flowchart 800. Thus, flowchart 800 exemplarily refers to shipping as an example application, wherein goods are sent by a shipper, wherein the shipping process is organized by a freight forwarder and performed by a carrier such as a truck driver. In the example, node 104 performs the actions of the freight forwarder, node 103 performs the actions of the shipper, and node 190 performs the actions of the carrier. The method of flowchart 800 will be referred to as 9A to 9D To explain.

[0216] thus, Figure 9A1. The data storage 104.4 assigned to the node 104 (e.g., included by or connected to the node 104) is illustratively shown, the data storage including a distributed ledger storage portion 104.4A (which may constitute a distributed ledger) for storing at least a portion of the distributed ledger. Figure 1A ) and a data memory 104.4B for storing data related to application processing involving the node 104 (e.g., payload data). A corresponding data memory 103.4 with corresponding distributed ledger memory portion 103.4A and data memory portion 103.4B is also allocated to the node 103 (not shown in the figure).

[0217] Return to Figure 8 In step 811, node 104 receives a booking request from node 103, through which a shipment of a certain quantity and type of goods is ordered, for example. Figure 9B As shown, a corresponding data block 411 representing the booking phase of the shipping process and containing data representing the booking request is generated and stored in the data memory portion allocated to nodes 103 and 104. As further shown, data block 411 is stored in association with hash information 311 (e.g., a hash index and / or hash value), whereby hash information 311 is a genesis hash of a sequence 310 of individual hash information 311 to 317 related to the shipping application performed by nodes 103, 104, and 190, the data of the corresponding phase of which is stored in a corresponding data block in the data block sequence 400. This genesis hash information can be used as a reference to data block 411 on the one hand, and as a reference to the entire application (shipping process) on the other hand. Figure 9B The arrows shown exemplarily illustrate relationship information stored so as to be accessible and manageable by indexer 121 that associates data blocks with corresponding hash information (e.g., data block 411 with corresponding hash information 311), whereby further grouping information is stored so as to be accessible and / or manageable by indexer 121 that associates each piece of hash information 311 to 317 and / or data blocks 411 to 417 with a shipping application. It should be noted that the relationship information and / or application-related grouping information may be stored in a data storage allocated to one or more nodes of peer-to-peer network 100 involved in application processing, and / or stored by one or more other nodes of peer-to-peer network 100 so as to be accessible and / or manageable by indexer 121.

[0218] In step 812, node 104 accepts the reservation request and transmits corresponding information to node 103 in step 813, thereby confirming the reservation request. Figure 9B As shown, corresponding data blocks 412 , 413 and corresponding hash information 312 , 313 are generated according to stages 812 and 813 of the application process.

[0219] In step 814, node 104 assigns a carrier (corresponding to node 190) to transport the freight from the shipper (corresponding to node 103). For example, in step 814, the assignment may involve an individual, such as a truck driver, who is responsible for transporting the freight from the shipper, so that the assignment may involve storing personal information of the individual, such as contact information.

[0220] like Figure 9C As shown, the corresponding data block, in particular data block 414, includes a first data portion 414.1 that may specifically contain non-personal data and a second data portion 414.2 that may specifically contain personal data. Accordingly, the corresponding hash information 314 includes first hash information 314.1 and second hash information 314.2 associated with the first data portion 414.1 and the second data portion 414.2, respectively, so that the corresponding relationship information is stored so that it can be accessed and / or managed by the indexer 121.

[0221] Thus, in step 814, transport-related data (such as information related to transport time, transport route, or payment information) is stored as constant data in the first data portion 414.1. Furthermore, personal information related to the truck driver is stored in the second data portion 414.2. This personal data may include, for example, the truck driver's contact information.

[0222] In step 815, node 104 receives transport completion information, e.g., a message from the truck driver informing the truck driver that the goods were successfully delivered. Furthermore, in step 816, node 104 receives modification request information, e.g., a message from the truck driver requesting the removal of personal data, e.g., contact information. It should be noted that the present disclosure is not limited to the removal of personal data. Further exemplary requests may correspond to modifying personal data and / or modifying and / or deleting different data that may be requested to be changed and / or deleted.

[0223] In step 817, node 104 expressly consents, for example, after confirming that the request is related to data stored in the second data portion and / or receiving the modification request information from a node authorized to provide modification request information. Node 104 can confirm the node's authorization, for example, based on the node's role as included in a decentralized identifier document associated with the node's decentralized identifier. In this example, node 104 confirms that the request is related to the truck driver's personal data stored in second portion 414.2 of data block 414 and that the truck driver is authorized to send the corresponding request.

[0224] Accordingly, in step 819, the node 104 causes the deletion of the second hash information 314.2 associated with the second data portion 414.2. In this way, the second data portion 414.2 becomes inaccessible with respect to the shipping application corresponding to the data block sequence 400. In another example, if the modification information obtained in step 816 relates to a request to amend information, for example, to update contact information with a new phone number, the node 104 may, based on the modification request information and based on a consensus process performed at at least one node of the at least one group of nodes of the peer-to-peer network, cause the new second hash information to be stored as part of the distributed ledger in association with the new second data portion of the at least one data block. The latter example is in Figure 9D and Figure 9E A schematic display is given in. Figure 9D Shown Figure 9B excerpts from, and Figure 9E The second data portion 414.2 is modified to 424.2 and the new second hash information 324.2 is used to replace the previous data portion 414.2. Figure 9C The second hash information 314.2. Figure 9D and Figure 9E As shown, in response to a request to modify the data stored in the second data portion 414.1, a new second data portion 424.2 is generated to replace the second data portion 414.2, while the first data portion 414.1 (stored as unchanged data) remains unchanged. Accordingly, the second hash information 424.2 is stored in association with the new second data portion 324.2, while the previous first hash information 314.1 remains unchanged. Figure 9E As shown, the indexer 121 (e.g., relationship information and / or grouping information stored as accessible and / or manageable by the indexer 121) is updated accordingly, such that the modified data block 424 (including the unmodified first data portion 414.1 and the modified second data portion 424.2) becomes accessible as part of the data block sequence 400 rather than the previous data block 414 via the modified hash information 324 (including the unmodified first hash information 314.1 and the new second hash information 324.2).

[0225] Thus, in particular, as a result of indexer 121, data stored in the second data portion can be modified and / or deleted, such that access to data as part of the data block sequence can be prevented / restricted, and / or new data can be made accessible as part of the data block sequence, while data stored as part of the first data block remains unchanged. In this way, flexibility in managing data as needed can be enhanced, in particular to comply with GDPR. At the same time, a high level of security can be maintained for data that may need to be stored as immutable.

[0226] Figure 10 yes Figure 1A 1 is a block diagram of a node 104 as an example of at least one apparatus according to the first aspect and / or the second aspect.

[0227] Node 104 includes a processor 104.1. Processor 104.1 may represent a single processor or two or more processors that are at least partially coupled, for example, via a bus. Processor 104.1 may use working memory 104.2 and program memory 104.3 to execute program code stored in program memory 104.3 (e.g., the program code, when executed on processor 104.1, causes node 104 to perform different method embodiments). Some or all of memories 104.2 and 104.3 may also be included in processor 104.1. One or both of memories 104.2 and 104.3 may be fixedly connected to processor 104.1 or at least partially removable from processor 104.1. Program memory 104.3 may, for example, be a non-volatile memory. To name a few examples, program memory may be, for example: flash memory; any one of ROM, PROM, EPROM, and EEPROM memory; or a hard disk. Program memory 104.3 may also include an operating system for processor 104.1. The main memory 104.2 may be, for example, a volatile memory. To name a few non-limiting examples, the working memory may be, for example, RAM or DRAM memory. The main memory may, for example, be used as working memory for the processor 104.1 when executing an operating system and / or programs.

[0228] The data storage 104.4 may be configured to keep data available, such as application data (in the data storage 104B) related to an application processed, for example, between the node 104 and the partner node 190. The node 104 may include the data storage 104.4 and / or may be connected to the data storage 104.4. The data storage 104 may form Figure 1A In other words, in the exemplary embodiment, the node 104 includes (in the distributed ledger memory portion 104.4A) a data memory 104.4 that stores at least a portion of the distributed ledger, in particular a complete copy. It should be noted that Figure 1A The nodes 101, 102 and 103 of the peer-to-peer network 100 (and those not in Figure 1AEach of the potential other nodes of the peer-to-peer network 100 shown in FIG. 1 may include a corresponding data store that stores at least a portion of the distributed ledger, and in particular, a complete copy. It should be noted that it may not be necessary for a corresponding node of the peer-to-peer network 100 to store a complete copy of the distributed ledger. In an exemplary embodiment, a subgroup of the nodes of the peer-to-peer network may store a corresponding portion of the distributed ledger, which may be related to one or more applications processed by the corresponding nodes of the peer-to-peer network 100 belonging to the subgroup.

[0229] like Figure 11 As exemplarily shown in Figure 10 a to Figure 10 discussed in detail in the context of e, Figure 1A The data blocks 111, 112, 113, 114 shown in FIG may correspond to the data blocks 111, 112, 113, 114 shown in FIG. Figure 1A The application process (e.g., transaction) is shown to be processed by nodes 101 and 104 of the peer-to-peer network 100. Since only nodes 101 and 104 of the peer-to-peer network 100 participate in the transaction, the corresponding data blocks 111, 112, 113, 114 can be stored, for example, on the respective local storage devices (data storage portions of the respective data storage) 101.4 and 104.4 included in or connected to the nodes 101 and 104. Figure 11 As exemplarily indicated in FIG, respective hash values ​​corresponding to respective data chunks and / or hash indexes #1, #2, #3, and #4 identifying the respective hash values ​​are stored on respective storage devices 101.4, 102.4, 103.4, and 104.4 included in or connected to at least some of the nodes of the peer-to-peer network 100 (in the exemplary embodiment, all of the nodes of the peer-to-peer network) (in respective distributed ledger memory portions), thereby forming a distributed ledger in the exemplary embodiment. In other words, in the exemplary embodiment, the distributed ledger includes a set of hash indexes and / or hash values, wherein the respective hash indexes and / or hash values ​​are associated with respective data chunks and / or respective portions of data chunks stored on storage devices of or connected to one or more nodes of the peer-to-peer network, independent of the distributed ledger.

[0230] Return Reference Figure 10 , the processor 104.1 further controls one or more communication interfaces 104.6 configured to receive and / or send information. For example, the node 104 may be configured to communicate with any of the nodes 101, 102, 103 of the peer-to-peer network 100 and / or with Figure 1A The communication may be based on a (eg, partially) wired connection and / or a (eg, partially) wireless connection, for example.

[0231] Processor 104.1 further controls a user interface 104.5 configured to present information to a user of node 104 and / or receive information from such a user. User interface 104.5 may be, for example, a user interface by which a user can control a fixed or portable personal computer, server, server system and / or mobile device.

[0232] Components 104 . 2 to 104 . 6 of node 104 may be connected to processor 104 . 1 , for example, by means of one or more serial and / or parallel buses.

[0233] like Figure 10 As further shown, the processor 104.1 may further include a pre-processor 104.7, an application processor 104.8, and a post-processor 104.9. The pre-processor is configured to Figure 5 In step 502, the application-related message is received from the message ingestion API 152.1. The processor 104.1 may include any of the pre-processor 104.7, the application processor 104.8, and the post-processor 104.9 in the form of corresponding functional and / or structural units. Any of the pre-processor 104.7, the application processor 104.8, and the post-processor 104.9 may further be implemented in the form of corresponding software modules and / or functions implemented as executable code, which is configured to implement the corresponding functions at one or more nodes of the peer-to-peer network 100.

[0234] Thus, after having received a message related to an application processed between a partner node 190 and a node 104 of a peer-to-peer network 100, the pre-processor 104.7 is specifically configured to extract a decentralized identifier from the payload of the received message and, based on the extracted decentralized identifier, retrieve partner information from the partner discoverer 123 to verify the partner information present in the message payload. The pre-processor 104.7 is further configured to obtain the partner role of the partner node 190 based on the extracted decentralized identifier (i.e., information defining the access rights and / or read / write permissions of the partner node 190).

[0235] After having retrieved and verified the partner information from partner discoverer 123, pre-processor 104.7 then passes the message to application processor 104.8. In an exemplary embodiment, application processor 104.8 may be a customized module customized based on one or more applications to be processed between partner node 190 and node 104 of peer-to-peer network 100. Based on the specific application mentioned in the received message, application processor 104.8 processes the message and, upon successful processing, passes the message to post-processor 104.9 for further processing.

[0236] The post-processor is configured to obtain the address of partner node 190 (e.g., the partner response service address) from partner discoverer 123. The post-processor is further configured to store information indicating successful message processing, for example, at a local storage device of node 104 (e.g., data storage 104.4). For example, in an exemplary embodiment, the post-processor is configured to generate and / or update a verifiable credential, which may include, for example, a decentralized identifier of node 104 of peer-to-peer network 100, a decentralized identifier of partner node 190, a payload including a credential statement and a cryptographic proof, which may ensure the integrity of the verifiable credential (VC). In particular, the post-processor may create or update the verifiable credential by attaching the VC ID to the message and storing the VC in the local storage device of node 104.

[0237] In order to inform partner node 190 about the message received in step 201 and / or the application state related to the different messages received from partner node 190, post-processor 104.9 obtains the endpoint associated with partner node 190 from partner discoverer 123 based on the decentralized identifier of partner node 190. Post-processor 104.9 can then combine the response message payload with the verifiable credential and can sign the verifiable credential with the private key of node 104. Post-processor 104.9 can then publish the message combined with the signed verifiable credential to the endpoint of partner node 190.

[0238] The onboarding process of the partner node 410 disclosed in the context of the first aspect of this document (which may include: deploying an SDK to the partner node 410 to enable application processing between the node 104 of the distributed ledger system 1000 and the partner node 190 external to the distributed ledger system; performing digital twin-based machine-to-machine pairing between the node 104 and the partner node 190 based on the decentralized identifier of the partner node 104; establishing public and private keys between the node 104 and the partner node 190, which are protected in the secured portion 140 of the memory 110 of the distributed ledger system 1000; establishing a hash value based on at least a portion of the decentralized identifier of the partner node 190; and assigning a partner role to the partner node 190) enables data communication between a node of the distributed ledger system 1000 and a node not included in the distributed ledger system 1000 (in particular, with a node portion of a different distributed ledger system).

[0239] While nodes communicating with the distributed ledger system (such as partner node 190) can specifically correspond to fixed or portable personal computers, servers, and / or server systems, in exemplary embodiments, partner node 190 (as an example of an external device) corresponds to or is part of a mobile device. In this case, SDK 151 corresponds to a client SDK designed for the mobile device. In exemplary embodiments, the mobile device includes a thin client corresponding to a node of the distributed ledger system 1000, wherein the thin client specifically includes indexer 121 and / or partner discoverer 123.

[0240] In other words, compared to a situation where a partner node still functions as a node of its own system (such as a non-distributed ledger system), in an exemplary embodiment, the thin client enables the mobile device to become a node of the distributed ledger system 1000. For example, in an exemplary embodiment, the thin client enables the mobile device to be configured to generate a hash value and / or a hash index to be stored in association with a corresponding data block in the memory 110 of the distributed ledger system 1000. Thus, in an exemplary embodiment, the corresponding data block is stored in a cloud storage device accessible to the mobile device.

[0241] Figure 12 Exemplary nodes and / or node systems are shown that can communicate with the distributed ledger system 1000 based on various aspects and embodiments disclosed herein. Figure 12 A distributed ledger system 1000 is schematically illustrated, shown as having various layers 1110, 1120, 1130, and 1140 that enable data communication between distributed ledger system 1000 and various nodes and / or node systems. These various layers schematically illustrate the multi-protocol blockchain layer implemented by distributed ledger system 1000. In particular, in exemplary embodiments, the multi-protocol blockchain layer implements Ethereum, Quorum, Corda, and Multichain protocols. The specific architecture / design of distributed ledger system 1000 allows for communication with other distributed ledger networks, such as those based on smart contracts, as needed. The specific architecture / design of distributed ledger system 1000 further allows for communication with networks not based on distributed ledger technology (DLT).

[0242] As further disclosed herein, decentralized identifiers (in particular, DIDs) enable reliable security of communications between non-DLT endpoints and the distributed ledger system 1000. While the decentralized identifier (e.g., DID) may be a public address, a hash value based on the decentralized identifier, in particular, the DID, may be stored in the secured portion 140 (e.g., a HashiCorb library) of the memory 110 of the distributed ledger system 1000, thereby ensuring that public keys can be shared with non-DLT partners (e.g., partner nodes 190).

[0243] Figure 12 Further shown is another distributed ledger system 1100, which may correspond to the distributed ledger system 1000 in structure and protocol, and may be deployed, for example, for an owner different from the owner of the distributed ledger system 1000. System 1200 may correspond, for example, to a Hyperledger Fabric (HLF) system, system 1300 may correspond, for example, to a non-blockchain system (e.g., to a Software as a Service (SAAS) system, a Platform as a Service (PAAS) system, and / or an Infrastructure as a Service (SAAS) system), and node 1400 may correspond to a mobile device that may store data in a cloud-based data storage device 1450.

[0244] like Figure 12 As shown, endpoints of distributed ledger system 1000 can be accessed based on different methods. Distributed ledger system 1000 can be accessed by a system such as distributed ledger system 1100 that shares a structure and protocol with distributed ledger system 1000, or by a different distributed ledger system such as HLF system 1200. If the endpoint (and / or corresponding node) accessing distributed ledger system 1000 is an HLF endpoint (node), the HLF protocol is activated at distributed ledger system 1000. If the endpoint accessing distributed ledger system 1000 is a Quorum or Corda endpoint, the Quorum protocol or the Corda protocol, respectively, is activated.

[0245] If the endpoints and / or nodes accessing distributed ledger system 1000 are non-DLT endpoints / nodes, such as nodes of system 1300, the corresponding nodes (e.g., nodes connected to the SAP HANA system) can connect to distributed ledger system 1000 via an internet (e.g., HTTPS) connection and / or an on-premises connection. In this case, the nodes can have dedicated decentralized identifiers, such as specific DIDs. In this case, distributed ledger system 1000 assumes the role of Master of Server (MoS). In this case, corresponding messages to / from distributed ledger system 1000 (which can be accessed by non-DLT and / or non-blockchain systems, such as SAP HANA) can be accessed based on the decentralized identifier (e.g., DID-based access, sharing of cryptographic hash values ​​using specific QR codes, and / or peer-to-peer data services (PDS)) to verify immutability. Data can be immutable in the distributed ledger system, while the non-DLT and / or non-blockchain system (e.g., SAP HANA system) acts as the data sender or receiver. Any changes to the corresponding data are transmitted to a non-DLT system and / or a non-blockchain system (e.g., a SAP HANA system), which is required to provide consensus before the corresponding data block can be created at the distributed ledger system.

[0246] In an exemplary embodiment, the distributed ledger system can specifically communicate with an application (e.g., applet / Android) provided on a mobile device. To this end, the applet / Android can communicate with the application layer of the distributed ledger system 1000 based on a decentralized identifier of the applet / Android and / or the mobile device. The distributed ledger system can host hash values ​​and application data to confirm immutability. Alternatively or in addition, the applet / Android is configured as a node that is configured to interact with the distributed ledger system 1000 to achieve data communication and immutability. For example, a user can download a corresponding applet / Android to implement a node, choose to connect to a cloud service (such as Figure 12 The cloud system 1450 shown in the figure is used for local data storage. The user's actions on such applet (for example, booking actions) will be automatically transmitted to the distributed ledger system 1000.

[0247] The following example embodiments are also disclosed:

[0248] Example 1

[0249] A method performed by at least one device, wherein the at least one device is part of or corresponds to at least one node of a peer-to-peer network comprising at least two nodes, wherein a respective one of the nodes of the peer-to-peer network stores at least a portion of a distributed ledger; the method comprising:

[0250] - receiving or causing reception of a connection establishment message from at least one external device, or transmitting or causing transmission of the connection establishment message to the at least one external device;

[0251] - obtaining or causing to be obtained a decentralized identifier representing the external device based on the connection establishment message;

[0252] - obtaining or causing to be obtained at least one hash value generated based on at least a portion of the obtained decentralized identifier;

[0253] storing or causing to be stored the at least one hash value in association with at least a portion of the decentralized identifier in a secured portion of a memory of a distributed ledger system comprising the peer-to-peer network based on a consensus process involving at least a subset of the nodes of the peer-to-peer network.

[0254] Example 2

[0255] The method of embodiment 1, wherein the decentralized identifier is associated with a decentralized identifier document, the method further comprising:

[0256] - obtaining or causing to be obtained the at least one hash value based on at least one respective address of at least one corresponding service endpoint and / or based on at least one corresponding public key comprised in the decentralized identifier document.

[0257] Example 3

[0258] The method according to any one of embodiments 1 or 2, further comprising:

[0259] - distributing or causing to be distributed at least one pair of a public key and a private key to the external device;

[0260] - providing or causing to be provided the public key to the external device; and

[0261] storing or causing to be stored, based on a consensus process involving at least a subset of the nodes of the peer-to-peer network, at least the private key in association with at least a portion of the decentralized identifier in a secured portion of a memory of the distributed ledger.

[0262] Example 4

[0263] The method according to any one of embodiments 1 to 3, further comprising:

[0264] - assigning or causing assignment to the external device of at least one partner role defining access rights and / or read / write permissions for the external device;

[0265] - Based on a consensus process involving at least a subset of nodes of the peer-to-peer network, storing or causing to be stored in a secured portion of a memory of the distributed ledger system information setting the at least one partner role in association with at least a portion of the decentralized identifier.

[0266] Example 5

[0267] The method of any one of embodiments 1 to 4, further comprising:

[0268] - providing or causing to be provided the at least one hash value generated based on at least a part of the obtained decentralized identifier to the external device, in particular in association with the decentralized identifier.

[0269] Example 6

[0270] The method of any one of embodiments 1 to 5, further comprising:

[0271] - establishing or causing to be established a machine-to-machine pairing based on a digital twin between the external device and at least one node of the peer-to-peer network, in particular based on the decentralized identifier.

[0272] Example 7

[0273] The method according to any one of embodiments 1 to 6, further comprising

[0274] - storing or causing to be stored at least one data block, the storing comprising:

[0275] - storing or causing to be stored a first data portion and a second data portion of the at least one data block in a data memory portion assigned to the at least one node, wherein the first data portion is stored as immutable data;

[0276] The method further comprises:

[0277] - causing first hash information to be stored in association with the first data portion as part of the distributed ledger;

[0278] - causing second hash information to be stored in association with the second data portion as part of the distributed ledger;

[0279] - obtaining or causing to be obtained modification request information associated with the at least one data block;

[0280] - Based on the modification request information and based on a consensus process performed at at least one node of at least one set of nodes of the peer-to-peer network, causing deletion of the second hash information associated with the second data portion and / or causing new second hash information to be stored in association with a new second data portion of the at least one data block as part of the distributed ledger.

[0281] Example 8

[0282] A method performed by at least one device, wherein the at least one device is part of or corresponds to at least one node of a peer-to-peer network comprising at least two nodes forming at least part of a distributed ledger system, wherein the respective node stores at least a respective portion of a distributed ledger in a portion of a distributed ledger memory allocated to the respective node; the method comprising:

[0283] - storing or causing to be stored at least one data block, the storing comprising:

[0284] - storing or causing to be stored a first data portion and a second data portion of the at least one data block in a data memory portion assigned to the at least one node, wherein the first data portion is stored as immutable data;

[0285] The method further comprises:

[0286] - causing first hash information to be stored in association with the first data portion as part of the distributed ledger;

[0287] - causing second hash information to be stored in association with the second data portion as part of the distributed ledger;

[0288] - obtaining or causing to be obtained modification request information associated with the at least one data block;

[0289] - Based on the modification request information and based on a consensus process performed at at least one node of at least one set of nodes of the peer-to-peer network, causing deletion of the second hash information associated with the second data portion and / or causing new second hash information to be stored in association with a new second data portion of the at least one data block as part of the distributed ledger.

[0290] Example 9

[0291] A method according to any one of embodiments 7 or 8, wherein the at least one data block is part of a sequence of at least two data blocks, wherein the corresponding data block includes data representing a corresponding stage of application processing and is associated with corresponding hash information capable of accessing the corresponding data block, wherein each hash information forms a sequence representing a corresponding stage of the application processing.

[0292] Example 10

[0293] The method of any one of embodiments 7 to 9, further comprising at least one of the following:

[0294] - based on the modification request information, replacing or causing replacement of at least part of the data of the second data portion with revised data;

[0295] - based on the modification request information, deleting or causing deletion of at least part of the data of the second data portion.

[0296] Example 11

[0297] The method of any one of embodiments 7 to 10, wherein the data storage portion is a memory portion included by and / or connected to the at least one node and is different from a distributed ledger memory portion allocated to the at least one node.

[0298] Example 12

[0299] The method according to any one of embodiments 7 to 11, wherein obtaining the modification request information includes:

[0300] - receiving or causing to be received a request to modify or delete at least part of the data of the data block, in particular the data of the second data portion.

[0301] Example 13

[0302] The method of any one of embodiments 7 to 12, wherein causing the first hash information to be stored in association with the first data portion as part of the distributed ledger (310) comprises:

[0303] - causing the indexer (221) of the distributed ledger system to obtain a first hash value (314.1) based on the first data portion (414.1) as at least a part of the first hash information (314.1); and

[0304] Wherein, causing the second hash information to be stored in association with the second data portion as part of the distributed ledger (310) comprises:

[0305] - causing the indexer (221) of the distributed ledger system to obtain a second hash value (314.1) based on the second data portion (414.1) as at least a part of the second hash information (314.1); the method further comprising:

[0306] -Cause the indexer to store first relationship information as accessible and / or manageable by the indexer and cause the indexer to store second relationship information as accessible and / or manageable by the indexer, the first relationship information associating the first hash value with the first data portion, the second relationship information associating the second hash value with the second data portion.

[0307] Example 14

[0308] The method according to any one of embodiments 7 to 13, wherein causing deletion of the second hash information comprises:

[0309] - causing the indexer (221) of the distributed ledger system to delete the relationship information stored so as to be accessible and / or manageable by the indexer and relating the second data portion to the second hash information.

[0310] Example 15

[0311] A method according to any one of embodiments 13 or 14, wherein the relationship information is stored in a data storage portion allocated to one or more nodes of the peer network involved in application processing, and / or stored by one or more other nodes of the peer network so as to be accessible and / or manageable by an indexer.

[0312] Example 16

[0313] A method according to any one of embodiments 13 to 15, wherein the indexer corresponds to a module and / or function implemented as an executable code at at least one node and / or one or more other nodes of the peer network and configured to control the functions of the indexer.

[0314] Example 17

[0315] The method according to any one of embodiments 7 to 16, wherein the distributed ledger includes at least two items of hash information, wherein a corresponding item of hash information is associated with a data block, wherein the corresponding data block includes data representing a corresponding stage of processing of an application of a group of nodes of the at least two nodes of the peer-to-peer network, and wherein the corresponding data block including data representing the corresponding stage of processing of the application is stored in at least one data memory portion of the memory portion allocated to the corresponding node in the node subgroup.

[0316] Example 18

[0317] The method according to any one of embodiments 7 to 17, wherein the corresponding data block including data representing the corresponding stage of the application processing is stored independently of the distributed ledger.

[0318] Example 19

[0319] The method of any one of embodiments 7 to 18, wherein the distributed ledger is stored in a decentralized manner, wherein a respective node of the peer-to-peer network stores at least a portion of the distributed ledger in a portion of the distributed ledger memory allocated to the respective node.

[0320] Example 20

[0321] The method according to any one of embodiments 7 to 19, wherein the second data portion of the at least one data block includes personal data, in particular data related to personal data.

[0322] Example 21

[0323] The method of any one of embodiments 7 to 20, wherein the second data portion is made accessible as part of a sequence of at least two data blocks representing application processing by causing the second hash information to be stored in association with the second data portion as part of the distributed ledger.

[0324] Example 22

[0325] The method according to any one of embodiments 7 to 21, wherein the second data portion is rendered inaccessible as part of a sequence of at least two data blocks representing application processing by causing deletion of second hash information associated with the second data portion.

[0326] Example 23

[0327] The method according to any one of embodiments 7 to 22, wherein the data block includes digital data related to the application at the corresponding point in time.

[0328] Example 24

[0329] The method of any one of embodiments 7 to 23, wherein the application corresponds to a process for a shipment, a transaction, and / or a smart contract.

[0330] Example 25

[0331] The method according to any one of embodiments 7 to 24, wherein the second data portion of the data block is stored as variable data.

[0332] Example 26

[0333] The method of any one of embodiments 1 to 25, further comprising:

[0334] - obtaining or causing to be obtained application-related messages from an external device or from a node of the peer-to-peer network;

[0335] - generating or causing the generation of a message token; and

[0336] - providing or causing to be provided the message token to the external device in response to receiving a message associated with the application.

[0337] Example 27

[0338] A method according to embodiment 26, wherein the message token includes a quick response (QR) code, which is configured to enable the external device to access status information about the status of an application processed between the external device and the node of the peer network.

[0339] Example 28

[0340] The method of embodiment 27, wherein the QR code includes a hash value generated based on at least a portion of the obtained decentralized identifier.

[0341] Example 29

[0342] The method of any one of embodiments 1 to 28, wherein the distributed ledger corresponds to or includes a set of hash indices and / or hash values, wherein the corresponding hash indices and / or hash values ​​are associated independently of the distributed ledger with corresponding data blocks and / or corresponding portions of data blocks stored at a storage device of one or more nodes of the peer-to-peer network or connected to the one or more nodes.

[0343] Example 30

[0344] The method according to any one of embodiments 1 to 29, wherein the method is performed by the distributed ledger system.

[0345] Example 31

[0346] The method according to any one of embodiments 13 to 30, wherein the distributed ledger system includes the indexer, the indexer being configured to assign corresponding hash information to at least a portion of the data block and / or the sub-block by applying a hash function based on the corresponding data block of the distributed ledger and / or based on the corresponding sub-block of the distributed ledger independently of the different data blocks and / or different sub-blocks.

[0347] Example 32

[0348] The method according to any one of embodiments 13 to 31, wherein corresponding relationships between hash indices and / or hash values ​​associated with a group of data blocks are stored to be accessible and / or manageable by the indexer.

[0349] Example 33

[0350] The method of any one of embodiments 1 to 32, wherein the decentralized identifier is associated with a decentralized identifier document, the method further comprising:

[0351] - obtaining or causing to be obtained the at least one hash value based on at least one respective address of at least one corresponding service endpoint and / or based on at least one corresponding public key comprised in the decentralized identifier document.

[0352] Example 34

[0353] The method of any one of embodiments 1 to 33, further comprising:

[0354] - distributing or causing to be distributed at least one pair of a public key and a private key to the external device;

[0355] - providing or causing to be provided the public key to the external device; and

[0356] storing or causing to be stored, in the secured portion of the memory of the distributed ledger, at least the private key in association with at least a portion of the decentralized identifier based on a consensus process involving at least a subset of the nodes of the peer-to-peer network.

[0357] Example 35

[0358] The method of any one of embodiments 1 to 34, further comprising:

[0359] - assigning or causing assignment to the external device of at least one partner role defining access rights and / or read / write permissions for the external device;

[0360] - Based on a consensus process involving at least a subset of nodes of the peer-to-peer network, storing or causing to be stored in a secured portion of a memory of the distributed ledger system information setting the at least one partner role in association with at least a portion of the decentralized identifier.

[0361] Example 36

[0362] A method according to embodiment 35, wherein the set of nodes of the peer network that performs the consensus processing is specifically defined based on the partner role of the node that transmits the message including the modification request information and / or based on a decentralized identifier associated with the node that transmits the message including the modification request information.

[0363] Example 37

[0364] The method of any one of embodiments 1 to 36, further comprising:

[0365] - providing or causing to be provided the at least one hash value generated based on at least a part of the obtained decentralized identifier to the external device, in particular in association with the decentralized identifier.

[0366] Example 38

[0367] The method of any one of embodiments 1 to 37, further comprising:

[0368] - establishing or causing to be established a machine-to-machine pairing based on a digital twin between the external device and at least one node of the peer-to-peer network, in particular based on the decentralized identifier.

[0369] Example 39

[0370] A distributed ledger system, comprising:

[0371] - at least two nodes of a peer-to-peer network, wherein respective ones of the nodes of the peer-to-peer network store at least a portion of a distributed ledger;

[0372] - a software development kit and / or an application programming interface configured to enable transmission of connection establishment messages between at least one of the nodes of the peer-to-peer network and an external device;

[0373] a decentralized identifier acquirer configured to acquire a decentralized identifier representing the external device based on the connection establishment message;

[0374] - a hash value obtainer configured to obtain at least one hash value generated based on at least a portion of the obtained decentralized identifier;

[0375] a consensus controller configured to control, based on a consensus process involving at least a subset of nodes of the peer-to-peer network, storing the at least one hash value in association with at least a portion of the decentralized identifier in a secured portion of a memory of the distributed ledger system.

[0376] Example 40

[0377] The distributed ledger system according to embodiment 39 further includes the external device;

[0378] The external device corresponds to a mobile device or is included in the mobile device, and the mobile device includes:

[0379] - a thin client that enables the mobile device to perform the functions of a node of the distributed ledger system.

[0380] Example 41

[0381] A distributed ledger system comprising a peer-to-peer network having nodes, wherein a respective node is configured to store at least a corresponding portion of a distributed ledger in a portion of a distributed ledger memory allocated to the respective node; the system comprising at least one device being part of or corresponding to at least one node of the peer-to-peer network and configured to:

[0382] - storing or causing to be stored a first data portion and a second data portion of at least one data block in a data memory portion assigned to the at least one node, wherein the first data portion is stored as immutable data;

[0383] - causing first hash information to be stored in association with the first data portion as part of the distributed ledger;

[0384] - causing second hash information to be stored in association with the second data portion as part of the distributed ledger;

[0385] - obtaining or causing to be obtained modification request information associated with the at least one data block;

[0386] - Based on the modification request information and based on a consensus process performed at at least one node in the subset of nodes of the peer-to-peer network, causing deletion of the second hash information associated with the second data portion or causing new second hash information to be stored in association with a new second data portion of the at least one data block.

[0387] Example 42

[0388] An apparatus comprising means for performing the method according to any one of embodiments 1 to 7.

[0389] Example 43

[0390] An apparatus comprising means for performing the method according to any one of embodiments 8 to 38.

[0391] Example 44

[0392] An apparatus comprising at least one processor and at least one memory containing computer program code, the at least one memory and the computer program code being configured to, with the at least one processor, cause the apparatus to perform the steps of the method according to any one of embodiments 1 to 7.

[0393] Example 45

[0394] The device of embodiment 44, wherein the device is part of or corresponds to at least one node of a peer-to-peer network comprising at least two nodes, wherein a respective one of the nodes of the peer-to-peer network stores at least a portion of a distributed ledger.

[0395] Example 46

[0396] An apparatus comprising at least one processor and at least one memory containing computer program code, wherein the at least one memory and the computer program code are configured to use the at least one processor to cause the apparatus to perform the steps of the method according to any one of embodiments 8 to 38.

[0397] Example 47

[0398] The device of embodiment 46, wherein the at least one device is part of or corresponds to at least one node of a peer-to-peer network comprising at least two nodes forming at least a portion of a distributed ledger system, wherein the respective node stores at least a corresponding portion of the distributed ledger in a distributed ledger memory portion allocated to the respective node.

[0399] Example 48

[0400] A computer program code, when executed by a processor, causes an apparatus to perform the method according to any one of embodiments 1 to 7.

[0401] Example 49

[0402] A computer program code, which, when executed by a processor, causes an apparatus to perform the method according to any one of embodiments 8 to 38.

[0403] Example 50

[0404] A non-transitory computer-readable storage medium having computer program code stored therein, wherein the computer program code, when executed by a processor, causes at least one device to perform the steps of the method according to any one of embodiments 1 to 7.

[0405] Example 51

[0406] A non-transitory computer-readable storage medium having computer program code stored therein, wherein the computer program code, when executed by a processor, causes at least one device to perform the steps of the method according to any one of embodiments 8 to 38.

[0407] Any connections presented in the described embodiments will be understood in the sense that the components involved are operatively coupled. Therefore, these connections may be direct or indirect connections with any number of intermediate elements or combinations of intermediate elements, and there may only be functional relationships between the components.

[0408] It will be understood that all presented embodiments are exemplary only, and that any feature presented for a particular exemplary embodiment may be used with any aspect of the present disclosure, either by itself or in combination with any feature presented for the same or another particular exemplary embodiment and / or in combination with any other features not mentioned. It will be further understood that any feature presented for a particular category of exemplary embodiments may also be used in a corresponding manner in any other category of exemplary embodiments.

Claims

1. A method performed by at least one device (101, 101.1, 102, 103, 104), wherein: The at least one device (101, 101.1, 102, 103, 104) is part of or corresponds to at least one node of a peer-to-peer network (100) comprising at least two nodes (101, 102, 103, 104) forming at least part of a distributed ledger system (1000), wherein the respective node (101, 102, 103, 104) stores at least a respective portion of a distributed ledger in a distributed ledger memory portion (104.4A) allocated to the respective node (101, 102, 103, 104); the method comprising: - storing (710) or causing to be stored at least one data block (414), said storing comprising: - storing (711) or causing to be stored a first data portion (414.1) and a second data portion (414.2) of the at least one data block (414) in a data memory portion (104.4B) assigned to the at least one node (101, 102, 103, 104), wherein the first data portion (414.1) is stored as immutable data; The method further comprises: - causing (720) storing the first hash information (314.1) in association with the first data portion (414.1) as part of the distributed ledger; - causing (730) second hash information (314.2) to be stored in association with the second data portion (414.2) as part of the distributed ledger; - obtaining (740) or causing to be obtained modification request information associated with the at least one data block (414); - based on the modification request information and based on a consensus process performed at at least one node (101, 102, 103, 104) of at least one set of nodes (101, 102, 103, 104) of the peer-to-peer network (100), causing (750) the deletion of second hash information (314.2) associated with the second data portion (414.2) and / or causing new second hash information (324.2) to be stored in association with a new second data portion (424.2) of the at least one data block (414) as part of the distributed ledger.

2. The method according to claim 1, wherein The at least one data block (414) is part of a sequence (400) of at least two data blocks, wherein respective data blocks (411, 412, 413, 414, 415, 416, 417) comprise data representing respective stages of application processing and are associated with respective hash information (311, 312, 313, 314, 315, 316, 317) enabling access to the respective data blocks (411, 412, 413, 414, 415, 416, 417), wherein respective pieces of hash information (311, 312, 313, 314, 315, 316, 317) form a sequence (310) representing respective stages of application processing.

3. The method according to any one of claims 1 to 2, further comprising at least one of the following: - based on the modification request information, replacing or causing to be replaced at least part of the data of the second data portion (414.2) with modified data (424.2); - Based on the modification request information, deleting or causing deletion of at least part of the data of the second data portion (414.2).

4. The method according to any one of claims 1 to 3, wherein The data memory portion (104.4B) is a memory portion included by the at least one node (101, 102, 103, 104) and / or connected to the at least one node, and is different from the distributed ledger memory portion (104.4A) allocated to the at least one node (101, 102, 103, 104).

5. The method according to any one of claims 1 to 4, wherein Obtaining the modification request information includes: - receiving or causing to be received a request to modify or delete at least part of the data of the data block (414), in particular the data of the second data part (414.2).

6. The method according to any one of claims 1 to 5, wherein Causing the first hash information (314.1) to be stored in association with the first data portion (414.1) as part of the distributed ledger (310) includes: - causing the indexer (221) of the distributed ledger system (1000) to obtain a first hash value (314.1) based on the first data portion (414.1) as at least a part of the first hash information (314.1); and wherein causing the second hash information (314.2) to be stored in association with the second data portion (414.2) as part of the distributed ledger (310) comprises: - causing the indexer (221) of the distributed ledger system (1000) to obtain a second hash value (314.2) based on the second data portion (414.2) as at least a part of the second hash information (314.2); the method further comprising: - Cause the indexer (121) to store first relationship information as accessible and / or manageable by the indexer (121) and cause the indexer to store second relationship information as accessible and / or manageable by the indexer (121), wherein the first relationship information associates the first hash value with the first data portion (414.1) and the second relationship information associates the second hash value with the second data portion.

7. The method according to any one of claims 1 to 6, wherein Causing deletion of the second hash information includes: - causing the indexer (121) of the distributed ledger system (1000) to delete relationship information, the relationship information being stored so as to be accessible and / or manageable by the indexer (121) and associating the second data portion with the second hash information.

8. The method according to any one of claims 6 or 7, wherein The relationship information is stored in a data memory portion allocated to one or more of the nodes (101, 102, 103, 104) of the peer-to-peer network (100) involved in application processing, and / or is stored by one or more other nodes (101, 102, 103, 104) of the peer-to-peer network (100) so as to be accessible and / or manageable by the indexer (121).

9. The method according to any one of claims 6 to 8, wherein The indexer (121) corresponds to a module and / or function, which is implemented as an executable code at at least one node (101, 102, 103, 104) and / or one or more other nodes (101, 102, 103, 104) of the peer-to-peer network and is configured to control the function of the indexer (121).

10. The method according to any one of claims 1 to 9, wherein The distributed ledger comprises at least two items of hash information, wherein a respective item of hash information is associated with a data block, wherein the respective data block comprises data representing a corresponding stage of application processing by a group of nodes (101, 102, 103, 104) of the at least two nodes (101, 102, 103, 104) of the peer-to-peer network (100), wherein the respective data block comprising data representing the corresponding stage of application processing is stored in at least one data memory portion of a memory portion allocated to a respective node (101, 102, 103, 104) of the subgroup of nodes (101, 102, 103, 104).

11. The method according to any one of claims 1 to 10, wherein Respective data blocks including data representing corresponding stages of the application processing are stored independently of the distributed ledger.

12. The method according to any one of claims 1 to 11, wherein The distributed ledger is stored in a decentralized manner, wherein respective nodes (101, 102, 103, 104) of the peer-to-peer network (100) store at least a portion of the distributed ledger in a portion of the distributed ledger memory allocated to the respective node (101, 102, 103, 104).

13. The method according to any one of claims 1 to 12, wherein The second data portion of the at least one data block comprises personal data, in particular data related to the personal data.

14. The method according to any one of claims 1 to 13, wherein By causing the second hash information to be stored in association with the second data portion as part of the distributed ledger, the second data portion becomes accessible as part of a sequence of at least two data blocks representing application processing.

15. The method according to any one of claims 1 to 14, wherein By causing deletion of the second hash information associated with the second data portion, the second data portion is rendered inaccessible as part of a sequence of at least two data blocks representing application processing.

16. The method according to any one of claims 1 to 15, wherein The application corresponds to the processing of shipments, transactions, and / or smart contracts.

17. The method according to any one of claims 1 to 16, wherein The second data portion of the data block is stored as variable data.

18. A distributed ledger system (1000) comprising a peer-to-peer network (100) having nodes (101, 102, 103, 104), wherein: The respective nodes (101, 102, 103, 104) are configured to store at least a corresponding portion of a distributed ledger in a portion of a distributed ledger memory allocated to the respective nodes; the system comprising at least one device being part of or corresponding to at least one node of the peer-to-peer network (100) and configured to: - storing (711) or causing to be stored a first data portion (414.1) and a second data portion (414.2) of at least one data block (414) in a data memory portion assigned to the at least one node, wherein the first data portion (414.1) is stored as immutable data; - causing (720) storing first hash information in association with the first data portion (414.1) as part of the distributed ledger; - causing (730) storing second hash information in association with the second data portion (414.2) as part of the distributed ledger; - obtaining (740) or causing to be obtained modification request information associated with the at least one data block (414); - Based on the modification request information and based on a consensus process performed at at least one node in the subgroup of nodes (101, 102, 103, 104) of the peer-to-peer network (100), causing (750) the deletion of second hash information associated with the second data portion (414.2) or causing new second hash information to be stored in association with a new second data portion (414.2) of the at least one data block (414).

19. An apparatus comprising at least one processor and at least one memory containing computer program code, the at least one memory and the computer program code being configured to, with the at least one processor, cause the apparatus to perform the steps of the method according to any one of claims 1 to 17.

20. Computer program code which, when executed by a processor, causes an apparatus to perform the method according to any one of claims 1 to 17.

Images