Distributed ledger system

Abstract

In particular, a method performed by at least one device is disclosed, the method comprising: receiving or causing to receive, from at least one external device, or transmitting or causing to transmit, to the at least one external device, a connection establishment message; obtaining or causing to obtain, based on the connection establishment message, a decentralized identifier representative of the external device; obtaining or causing to obtain at least one hash value generated based on at least part of the obtained decentralized identifier; storing or causing to store, in a secured part of a memory of a distributed ledger system comprising a peer-to-peer network, the at least one hash value in association with the at least part of the decentralized identifier, based on a consensus process involving at least one subgroup of nodes of the peer-to-peer network.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to distributed ledger technology and, in particular, to methods, devices and systems enabling interoperability between a distributed ledger system and nodes which can be independent nodes, which can be part of another distributed ledger system and / or blockchain system. BACKGROUND

[0002] Blockchain or blockchain-like distributed ledger systems have become popular in many application fields, including technologies based on logistics and / or warehouse processes. For example, a blockchain-like distributed ledger system, i.e. a distributed ledger system comprising at least one or more blockchain mechanisms, such as a consensus mechanism, can provide a technical basis to enable data communication between entities inside or outside the distributed ledger system and, at the same time, enable a high level of data security inside the distributed ledger system.

[0003] In particular, in order to be able to maintain data security inside the distributed ledger system, a specific interface is required to enable communication between the distributed ledger system and one or more nodes outside the distributed ledger system. In particular, in case the one or more external nodes outside the distributed ledger system are comprised in another distributed ledger and / or blockchain system and / or a non-distributed ledger and / or non-blockchain system, such a specific interface can be required to enable interoperability between such external nodes and nodes of the distributed ledger system. SUMMARY

[0004] It is an object of the present disclosure to provide methods and devices enabling interoperability between a distributed ledger system and at least one node, which can be an independent node or part of a non-distributed ledger system, a distributed ledger system and / or a blockchain system.

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

[0006] - receiving or causing to receive, from at least one external device, or transmitting or causing to transmit, to the at least one external device, a connection establishment message;

[0007] - obtaining or causing to obtain, based on the connection establishment message, a decentralized identifier representing the external device;

[0008] - obtaining or causing to obtain at least one hash value generated based on at least a part of the obtained decentralized identifier;

[0009] - based on a consensus process involving at least one subgroup of nodes of the peer-to-peer network, store or cause to store at least one hash value in association with at least one part of the decentralized identifier in a secured part of a memory of a distributed ledger system comprising the peer-to-peer network.

[0010] The method according to the first aspect of the disclosure can be performed by at least one device being part of or corresponding 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 one part of a distributed ledger. Thereby, the distributed ledger can incorporate one or more features of a blockchain, e.g. a consensus mechanism can be implemented to ensure that data subject to the consensus mechanism is only changed if consensus is reached among at least a subgroup of nodes of the peer-to-peer network.

[0011] In an exemplary embodiment, the distributed ledger comprises data representing one or more hash values, indices and / or hash indices, a respective one of the hash values, indices and / or hash indices corresponding to respective data, in particular user data or payload data. Thereby, in an exemplary embodiment, the data corresponding to the respective hash values, indices and / or hash indices is stored locally at a storage device connected to and / or accessible by one or more nodes of at least a subgroup of nodes constituting the peer-to-peer network. Further, in an exemplary embodiment, the one or more hash values, indices and / or hash indices are maintained as available by the distributed ledger and subject to a consensus mechanism configured such that a respective hash value, index and / or hash index can only be changed or deleted if consensus is reached among at least the subgroup of nodes of the peer-to-peer network.

[0012] For the method according to the first aspect of the disclosure, a device is also disclosed (and is subsequently referred to as a device according to the first aspect of the disclosure) configured to perform and / or control the respective method, or comprising respective means for performing and / or controlling the steps of the respective 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 of the means can also be performed and / or controlled by the same unit. By way of example, one or more of the means can be formed by one or more processors.

[0013] For the method according to the first aspect of the disclosure, also a device (e.g. at least one device according to the first aspect) is disclosed (and is subsequently referred to as at least one device according to the first aspect of the disclosure), which device comprises at least one processor and at least one memory including a program code, wherein the memory and the program code are configured to, using the at least one processor, cause the device (e.g. the device having the processor and the memory) to at least perform and / or control the respective method. In this case, all steps of the respective method can be controlled, or all steps of the respective method can be performed, or one or more steps can be controlled and one or more steps can be performed.

[0014] The at least one device according to the first aspect of the disclosure can correspond to or comprise at least one stationary or portable personal computer, at least one server, at least one server system and / or at least one mobile device, or be comprised thereby. Thereby, in exemplary embodiments, the mobile device corresponds to or comprises a smartphone, a smartwatch, a smartband, a tablet computer, a notebook computer, a smart home device, an Internet of Things (loT) device, an Internet of Medical Things (loMT) device and / or a data logger. The at least one device according to the first aspect can for example be integrated in a backend of a logistics service provider company.

[0015] For the method according to the first aspect of the disclosure, also a system is disclosed (and is subsequently referred to as a system according to the first aspect of the disclosure), which system comprises at least one device (e.g. at least one device according to the first aspect) configured to perform and / or control the respective method, or having means for performing and / or controlling the steps of the respective method. In this case, all steps of the respective method can be controlled, or all steps of the respective method can be performed, or one or more steps can be controlled and one or more steps can be performed.

[0016] For the method according to the first aspect of the disclosure, also a computer program is disclosed (and is subsequently referred to as a computer program according to the first aspect of the disclosure), which computer program comprises program instructions which, when executed on a processor, cause the processor to perform and / or control the respective method. In exemplary embodiments, such a computer program can correspond to, be part of, or be incorporated in source code and / or device identification code. In this specification, a processor is intended to be understood as meaning especially a control unit, a microprocessor, a microcontrol unit such as a microcontroller, a digital signal processor (DSP), an application-specific integrated circuit (ASIC) or a field programmable gate array (FPGA).

[0017] In this case, all steps of the method can be controlled (which can be understood in exemplary embodiments as being conditional steps of the method), or all steps of the method can be executed, or one or more steps can be controlled and one or more steps can be executed. By way of example, the computer program can be distributable via a network, such as, for example, the Internet, a telephone network or a mobile radio network and / or a local area network. In non-limiting examples, the network can correspond, for example, to a wireless network, a network employing at least partly radio frequency identification (RFID) and / or Global System for Mobile Communications (GSM) based technologies, and / or a pairing service network. The computer program can be at least partly software and / or firmware of a processor. It can likewise be at least partly implemented as hardware. By way of example, the computer program can be stored on a computer-readable storage medium, for example, a magnetic storage medium, an electronic storage medium, an electromagnetic storage medium, an optical storage medium and / or another type of storage medium. By way of example, the storage medium can be part of the processor, for example, a (non-volatile or volatile) program memory of the processor or a part thereof. By way of example, the storage medium is substantial, i.e. tangible and / or non-transitory.

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

[0019] at least two nodes of a peer-to-peer network, wherein a respective one of the nodes of the peer-to-peer network stores at least a part of a distributed ledger;

[0020] a software development kit and / or an application programming interface configured for enabling a communication of a connection establishment message between at least one of the nodes of the peer-to-peer network and an external device;

[0021] a decentralized identifier obtainer configured for obtaining, based on the connection establishment message, a decentralized identifier representing the external device;

[0022] a hash value obtainer configured for obtaining at least one hash value generated based on at least a part of the obtained decentralized identifier;

[0023] a consensus controller configured for controlling, based on a consensus process involving at least one subgroup of the nodes of the peer-to-peer network, a storage of the at least one hash value in association with at least a part of the decentralized identifier in a secured part of a memory of the distributed ledger system.

[0024] Exemplary embodiments of all aspects of the present disclosure can have one or more (or, for example, all) of the following described properties.

[0025] In an example embodiment, the distributed ledger is a collection of digital data accessible at least by one or more nodes of the peer-to-peer network, whereby storage of new data as part of the distributed ledger, deletion of existing data of the distributed ledger and / or modification of existing data is subject to a consensus mechanism between at least a subgroup of nodes of the peer-to-peer network. The subgroup may, for example, correspond to a group of nodes involved in application processing related to the data to be newly stored, deleted and / or modified. In an example embodiment, respective nodes of the peer-to-peer network comprise and / or are connected to storage means storing at least a part of the distributed ledger, in an example embodiment a complete copy. It is noted that, as used herein, the one or more nodes can be understood to correspond to or comprise at least one node and corresponding support hardware and one or more corresponding application services. In an example embodiment, the nodes can correspond to or comprise data loggers, servers, server systems or cloud systems, image recognition devices, scanners and / or point-of-sale (PoS) devices.

[0026] In an example embodiment, the nodes of the peer-to-peer network correspond to or comprise stationary or portable personal computers, servers, server systems and / or mobile devices. Thereby, in an example embodiment, the mobile devices correspond to or comprise smartphones, smartwatches, smartbands, tablet computers, notebook computers, smart home devices, Internet of Things (IoT) devices, Internet of Medical Things (IOMT) devices, data loggers, point-of-sale (PoS) devices, signature and / or facial recognition devices.

[0027] Thus, the distributed ledger system can correspond to a plurality of nodes, such as a plurality of computers installed at respective facilities of a company, e.g. a logistics provider company. The distributed ledger can relate to data related to a corresponding application, such as an application related to shipment of a particular good. Thereby, data related to a first application, such as a first shipment of a good, can be stored in the form of data blocks representing various stages of the shipment process at respective storage means of nodes involved in the first shipment. For example, a first data block can comprise data related to a shipment request from a client of the logistics provider, a second data block can comprise data related to a confirmation of the client by the logistics provider, a third data block can comprise data related to an initial shipment stage when, for example, the good is loaded to a shipment vehicle, a ship or an airplane.

[0028] While such data can be stored, e.g., locally, on respective storage means of nodes involved in the first shipment process or connected to these nodes, the distributed ledger system is, in example embodiments, configured to assign (e.g., comprise an indexer as further disclosed herein configured to assign) at least one respective hash value and / or hash index to the corresponding data block. Thereby, in example embodiments, the hash value generated for the second data block related to the application is generated independently from the first data block related to the application (e.g., representing an application processing stage preceding, in particular immediately preceding, the application processing stage represented by the second data block). In particular, in example embodiments, the second data block related to the application does not comprise the hash value generated for the first data block related to the application (e.g., representing an application processing stage preceding, in particular immediately preceding, the application processing stage or event trigger represented by the second data block).

[0029] In order to enable nodes of the distributed ledger system to perform application processing (e.g., processing of shipments, transactions or smart contracts) with one or more nodes external to the distributed ledger system, the node(s) external to the distributed ledger system can be enrolled. The corresponding enrollment procedure can be initiated by the external node, in which case the node of the distributed ledger system can receive a connection establishment message from the node external to the distributed ledger system, which is, in example embodiments, an example of at least one external device. The enrollment procedure can similarly be initiated by a node internal to the distributed ledger system, in which case the node can transmit a connection establishment message to at least one external device.

[0030] In a next stage of the enrollment procedure, the node of the distributed ledger system can obtain a decentralized identifier representing the external device based on the connection establishment message. Thereby, in example embodiments, 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 as further disclosed herein) 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 can be an existing decentralized identifier (e.g., a decentralized identifier already assigned to the external device) or can be a newly assigned decentralized identifier to the external device.

[0031] Further, in alternative exemplary embodiments, a node of the distributed ledger system can obtain, from an external device, a decentralized identifier representative of the external device. To this end, the distributed ledger system and / or a node of the distributed ledger system comprises, in exemplary embodiments, a decentralized identifier resolver application programming interface (API) configured for resolving a decentralized identifier associated with the external device and received from the external device, e.g. for converting a respective format used for defining a decentralized identifier on the side of the external device into a format used for defining a decentralized identifier on the side of the distributed ledger system. It is noted that, in exemplary embodiments, the decentralized identifier resolver API can be based on or can adopt global internet standards such as W3C standards, and / or can correspond to or be based on a RESTful API. Adopting a decentralized identifier resolver API can be particularly useful in case the external device belongs to a part of a non-distributed ledger system, e.g. a non-blockchain system, which comprises a plurality of nodes assigned to respective decentralized identifiers generated for the non-distributed ledger system. For example, this embodiment can be suitably applied in case the external device is part of a SAP HANA system. In this case, the distributed ledger system acts, in exemplary embodiments, as a master of sequence (MoS) with respect to the decentralized identifier obtained from the external device.

[0032] In particular, based on the decentralized identifier, it is made possible to enable data communication between a node of the distributed ledger system and a node external to the distributed ledger system, which can basically be independent of the underlying technology of the system to which the external device belongs. It can be made possible to enable data communication between a node of the distributed ledger system and an independent node, a node of another distributed ledger system, a node of a blockchain system, a node of a non-distributed ledger system, and / or a node of a non-blockchain system.

[0033] 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 part of the obtained decentralized identifier. As mentioned above, in exemplary embodiments, the distributed ledger system and / or a node of the distributed ledger system comprises an indexer configured to generate at least one hash value based on at least a part of the obtained decentralized identifier. Thus, the node of the distributed ledger system can obtain the hash value from an indexer implemented at the node of the distributed ledger system or from an indexer implemented at another node of the distributed ledger system.

[0034] The at least one hash value is then stored in a secured part of a memory of the distributed ledger system in association with at least a part of the decentralized identifier. Thereby, in exemplary embodiments, the memory corresponds to or comprises respective storage devices of or connected to nodes of the peer-to-peer network, whereby these storage devices can store at least a part of the distributed ledger, in particular a complete copy, respectively. In exemplary embodiments, the memory further comprises a secured part, i.e. a part subject to specific security guarantees. Thereby, the secured part can be provided on dedicated storage devices of one or more of the nodes of the peer-to-peer network or connected to the one or more nodes, can be distributed over respective storage devices of one or more of the nodes of the peer-to-peer network or connected to the one or more nodes, or can be comprised in external storage devices (e.g. in cloud-based storage devices).

[0035] In exemplary embodiments, the secured part is configured for providing identity-based access to the secured part, e.g. providing access to the secured part only to identified users. Further, in exemplary embodiments, the secured part is configured for encrypting stored data, e.g. for holding data in encoded form such that only authorized parties can decode the encoded data to access the original information. While aspects of the present disclosure are not limited in this respect, in exemplary embodiments, the secured part corresponds to or comprises a vault, in particular a HashiCorp vault. In exemplary embodiments, the vault can correspond to hardware configured for storing data in a secured manner, e.g. can correspond to a locally deployed vault of hardware devices configured to store respective security keys and / or a cloud-based security key store.

[0036] In exemplary embodiments, in addition or alternatively to the identity-based access to the secured part, other forms of access that can be employed include one or more of the following:

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

[0038] - access based on a role of the node.

[0039] Thereby, in exemplary embodiments, the role of the node can correspond to a node affiliation (e.g. based on an affiliation with a particular entity such as a person, a group of people, and / or a company), a level of the node in the entity (e.g. whether the node belongs to a supply chain of the entity), a role based on a country of the node, an economic field of the node, a site of the node (e.g. MEA, EMEA, DXB), a user or user group level (a team of accountants of a certain city or a single accountant using the service).

[0040] In an example embodiment, the decentralized identifier is associated with a decentralized identifier document. Thereby, in an example embodiment, the decentralized identifier corresponds to or comprises a uniform resource locator (URL) associating the subject (e.g. the external device) identified by the decentralized identifier with the decentralized identifier document. In an example embodiment, the decentralized identifier document holds or defines available information about or defining one or more public keys associated with the decentralized identifier, authentication information (e.g. one or more authentication and / or verification methods) associated with the decentralized identifier, a service endpoint, and / or semantics about the subject (e.g. the external device) identified by the decentralized identifier. The service endpoint can enable trusted interaction associated with the subject of the decentralized identifier (e.g. with the external device). The service endpoint can for example correspond to any one or more nodes of the peer-to-peer network and / or to the external device and can be identified by their corresponding address, e.g. by their MAC address, e.g. in case of a mobile device such as a smartwatch or handheld device, by the international mobile equipment identity (IMEI), or by a serial number in case of a data logger. In an example embodiment, the decentralized identifier document can further comprise a timestamp (e.g. for auditing history) and / or a signature (e.g. for integrity). In an example embodiment, the decentralized identifier document can correspond to or comprise metadata associated with the decentralized identifier.

[0041] Thus, in an example embodiment, the decentralized identifier is an identifier generated at the distributed ledger system and / or on the side of the external device based on attributes of the external device and associated with a decentralized identifier document. Although the decentralized identifier according to aspects disclosed herein is not limited to this aspect, in an example embodiment, the decentralized identifier comprises or corresponds to a DID as specified by the World Wide Web Consortium W3C. Additionally or alternatively, in an example embodiment, the decentralized identifier corresponds to a digital twin encrypted with a security key assigned to the respective endpoint.

[0042] Thus, in an example embodiment, the method according to the first aspect further comprises

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

[0044] In an example embodiment, the method according to the first aspect further comprises:

[0045] - assigning or causing to assign at least one pair of public and private keys to the external device;

[0046] - providing or causing to provide the public key to the external device; and

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

[0048] Hence, a node of a distributed ledger system can comprise a (software) module (e.g. a buddy finder as further disclosed herein) configured to generate a pair of public and private keys to be assigned to an external device. Thereby, 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 can enable the use of smaller keys, providing a similar level of security as keys based on non-elliptic curve cryptography. Thereby, in exemplary embodiments, the keys are generated based on the SECP256K1 and / or SECP156R1 curve.

[0049] In exemplary embodiments, the method according to the first aspect further comprises:

[0050] - assigning or causing to assign to the external device at least one buddy role defining access rights and / or read / write permissions of the external device;

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

[0052] Hence, in exemplary embodiments, upon logging in the external device, the external device is assigned a buddy role defining, for example, write access permissions that can be associated with messages transmitted from the external device to the distributed ledger system. Thereby, in exemplary embodiments, the external device can be assigned one or more buddy roles for one or more applications handled between the external device and the distributed ledger system.

[0053] In exemplary embodiments, the method according to the first aspect further comprises:

[0054] - providing or causing to provide to the external device 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.

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

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

[0057] - establishing or causing to establish, based on the distributed identifier, a digital-twin-based machine-to-machine pairing between the external device and at least one node of the peer-to-peer network.

[0058] 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 upon login of the external device (and upon 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 the hash pairing mechanism.

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

[0060] - obtaining or causing to obtain a message related to an application from the external device;

[0061] - generating or causing to generate a message token; and

[0062] - providing or causing to provide the message token to the external device in response to the received message related to the application.

[0063] As mentioned, once the external device is logged in, the external device and the distributed ledger system (one or more nodes thereof) can perform processing related to a respective application, such as data communication. Thereby, in an exemplary embodiment, the application comprises an application related to a shipment of goods, a general transaction, and / or a smart contract. Thereby, in an exemplary embodiment, the message related to the application comprises a request to start an application processing between the external device and the distributed ledger system, e.g. a shipment request, a booking request, etc. In an exemplary embodiment, the message related to the application can further comprise a request for a status of an application processed between the distributed ledger system and the external device.

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

[0065] In an exemplary embodiment, the message token represents a status of an application processed between the distributed ledger system and the external device. Thereby, in an exemplary embodiment, the message token can comprise or relate to a digital identity of an application processed between the distributed ledger system and the external device.

[0066] In an example embodiment, the message token comprises information based on which the external device is enabled to access state information about a state of an application processed between the external device and the distributed ledger system. For example, the message token can comprise a link based on which the external device can access an internet address / page that keeps said information about the state of the application available, which can then be displayed to a user of the external device, e.g. via a display connected to the external device.

[0067] In an example embodiment, the message token comprises a quick response (QR) code configured for enabling the external device to access state information about a state 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 can in an example embodiment comprise a hash value generated based on at least a portion of the obtained distributed identifier. In this way, the QR code can be securely verified to originate from the distributed ledger system on the external device side, to prevent fraud that can result when a corresponding QR is used by an illegitimate entity.

[0068] In an example embodiment, the distributed ledger comprises a collection of hash indices and / or hash values, wherein the respective hash indices and / or hash values are associated with corresponding data blocks and / or corresponding portions of data blocks stored at the one or more nodes of the peer-to-peer network or at storage means connected to the one or more nodes independently of the distributed ledger. As mentioned, the one or more nodes of the peer-to-peer network can comprise or be connected to respective local storage means for storing data related to applications in which the one or more nodes are involved. In order to provide data security, consensus and immutability, hash values generated based on the respective data blocks are stored as part of the distributed ledger. Thereby, changes, deletions or replacements of the respective hash values and / or hash indices stored as part of the distributed ledger are subject to a consensus process involving at least the one or more nodes involved in the respective application processing.

[0069] For example, if a shipment process involves three nodes of a distributed ledger system, data related to various stages of the shipment process can be stored at respective storage devices of or connected to the respective nodes of the three nodes involved in the shipment process in the form of data blocks representing the respective stages of the shipment process. Hash values and / or hash indices related to (e.g., generated based on) the respective data blocks (and the respective stages) are stored as part of the distributed ledger such that deletion, replacement and / or alteration of the respective hash values and / or hash indices is subject to a consensus process between at least the three nodes involved in the shipment process. It is noted that in this case, the consensus process can be limited to the three nodes involved. In this way, on the one hand flexibility is provided (as data can be modified later on), while the required consensus process provides a sufficient degree of security and immutability.

[0070] In an exemplary embodiment, the method according to the first aspect is performed by the distributed ledger system.

[0071] Thereby, in an exemplary embodiment, the distributed ledger system comprises an indexer (e.g., a software module) configured to assign corresponding hash values to at least a portion of the respective data blocks and / or the respective sub-blocks of the distributed ledger by applying a hash function based on the respective data blocks and / or based on the respective sub-blocks of the distributed ledger independently of different data blocks and / or different sub-blocks. Further, in an exemplary embodiment, the respective relationships between the hash indices and / or hash values associated with a group of data blocks are stored as accessible and / or manageable by the indexer.

[0072] Thus, in contrast to e.g. data blocks being related to preceding data blocks by a conventional blockchain comprising hash values generated based on the preceding data blocks, the temporal and / or content-related relationships between data blocks stored in relation to the distributed ledger of the distributed ledger system as disclosed herein are maintained, e.g., via a separate responsible entity (i.e., the indexer), to enable a certain flexibility while maintaining a sufficient degree of security and immutability.

[0073] In an exemplary embodiment, the external device corresponds to or is comprised in a mobile device, the mobile device comprising:

[0074] a thin client enabling the mobile device to perform the functions of a node of the distributed ledger system.

[0075] In other words, in example embodiments, the mobile device is enabled by the thin client to function as a node of the distributed ledger system, and can thus be configured to perform corresponding functions, such as in particular the generation of hash values. Accordingly, in example embodiments, the thin client comprises 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 storage of the hash value and / or index as part of the distributed ledger, the mobile device can be configured to store corresponding data blocks related to applications processed between the mobile device and the distributed ledger system in an external storage device, such as a cloud storage device.

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

[0077] Other features of the present disclosure will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, which are by way of illustration only. It will be understood that the accompanying drawings are not limiting of the present disclosure, but are merely intended to be illustrative thereof, and should be interpreted in the context of the written description being made to the appended claims. It will be further understood that the drawings are not drawn to scale and that they are merely intended to conceptually illustrate the structures and processes described herein. BRIEF DESCRIPTION OF DRAWINGS

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

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

[0080] Figure 1C is a schematic high level block diagram of an application programming interface;

[0081] Figure 2 is an example flow diagram illustrating example embodiments in accordance with a first aspect of the present disclosure;

[0082] Figure 3 is an example flow diagram illustrating steps of a method that can be performed as part of a method of Figure 2

[0083] Figure 4 is an example flow diagram illustrating steps of a method that can be performed as part of a method of Figure 2 Figure 3

[0084] Figure 5 is an example flow diagram illustrating an example embodiment of a message ingestion process; is an example flow diagram illustrating an example embodiment of a message ingestion process;​​

[0085] Figure 6 is an exemplary flowchart illustrating an exemplary embodiment of data communication between a node and a peer node of a peer-to-peer network;

[0086] Figure 7 is a block diagram of an exemplary embodiment of at least one device according to the first aspect;

[0087] Figure 8 illustrates exemplary data blocks and corresponding hash indices; and

[0088] Figure 9 illustrates an exemplary node and / or node system in communication with a distributed ledger system. DETAILED DESCRIPTION

[0089] The following description is made for the purpose of deepening the understanding of the present disclosure and should be understood as supplementing and reading together with the description of exemplary embodiments of the present disclosure as provided in the above SUMMARY section of the present specification.

[0090] 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 stationary or portable personal computers, servers, server systems, and / or mobile devices. Figure 1A is illustrated an exemplary peer-to-peer network 100 formed by a first node 101, a second node 102, a third node 103, and a fourth node 104. As indicated by the respective dashed lines, the peer-to-peer network 100 is not limited to the exemplary illustrated nodes in the drawing, but can comprise more or less nodes.

[0091] In an example embodiment, the distributed ledger is stored on the memory 110, at least parts of which can be distributed among some or all of the nodes of the peer-to-peer network 100. Thereby, at least respective parts of the distributed ledger can be stored redundantly on several or all of the nodes of the peer-to-peer network 100. In other words, in an example embodiment, respective nodes of the peer-to-peer network 100 are configured to store at least a part of the distributed ledger, in particular a complete copy. To this end, in an example embodiment, respective nodes of the peer-to-peer network 100 comprise a storage device comprising at least a part of the memory 110 for storing the at least part of the distributed ledger and / or are connected to such a storage device. In an example embodiment, the distributed ledger comprises data representing one or more hash values, indices and / or hash indices, a respective one of the hash values, indices and / or hash indices corresponding to a respective piece of data, in particular a user data or payload data. Thereby, in an example embodiment, data corresponding to a respective hash value, index and / or hash index is stored locally at a storage device of one or more nodes of a subgroup of nodes forming the peer-to-peer network 100.

[0092] As Figure 1A As exemplarily shown in Fig. 1, the distributed ledger is stored as comprising a plurality of data blocks 111, 112, 113, 114. As indicated by the dashed lines in Fig. 1, it is noted that the number of data blocks of the distributed ledger is not limited to four as exemplarily shown, but can be smaller or larger than four. Thereby, as exemplarily shown in Fig. 1, the data blocks 111, 112, 113, 114 of the distributed ledger are stored redundantly on the storage devices of the nodes 101, 102, 103, 104, 105, 106, 107, 108, 109 of the peer-to-peer network 100. Figure 1A As exemplarily shown in Fig. 1, the distributed ledger is stored as comprising a plurality of data blocks 111, 112, 113, 114. As indicated by the dashed lines in Fig. 1, it is noted that the number of data blocks of the distributed ledger is not limited to four as exemplarily shown, but can be smaller or larger than four. Thereby, as exemplarily shown in Fig. 1, the data blocks 111, 112, 113, 114 of the distributed ledger are stored redundantly on the storage devices of the nodes 101, 102, 103, 104, 105, 106, 107, 108, 109 of the peer-to-peer network 100. Figure 1AAs shown, respective hash values identified by corresponding hash indices #1, #2, #3, #4 are assigned to corresponding ones of data blocks 111, 112, 113, 114. To this end, in example embodiments, distributed ledger system 1000 includes an indexer 121 configured to assign at least one corresponding hash value for a portion of a respective data block of the distributed ledger. It is noted that more than one hash value can be assigned for a data block. For example, a data block can be separated into two or more sub-blocks, and a respective hash value can be assigned for a corresponding sub-block. In example embodiments, indexer 121 is configured to assign a hash value to a respective data block and / or sub-block by applying a hash function based on the respective data block and / or based on the sub-block. For example, indexer 121 can apply a hash function based on and / or using data included in the data block and / or sub-block. In example embodiments, indexer 121 corresponds to a software module and / or functionality implemented as executable code configured to control the functionality of indexer 121. In example embodiments, indexer 121 is implemented at one or more nodes of peer-to-peer network 100. Further, in example embodiments, indexer 121 is configured to assign a hash value to a respective data block and / or sub-block by applying a hash function based on the respective data block and / or based on the sub-block independent of data blocks and / or sub-blocks generated before and / or after the respective data block and / or sub-block. Thereby, in example embodiments, respective relationships between indices associated with a group of data blocks (e.g., a group of data blocks belonging to the same application) are maintained as 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. Thereby, distributed ledger system 1000 has an enhanced degree of flexibility (as data blocks and / or respective sub-blocks can be modified, deleted, or replaced) while maintaining respective relationships between data blocks and / or respective sub-blocks at indexer 121. Further, while deletion, replacement, and / or modification of data blocks can thus be possible, in example embodiments, such deletion, replacement, and / or modification are subject to a consensus mechanism based on consensus controller 122 such that a degree of security provided by distributed ledger system 1000 is similar to that provided by conventional blockchain technology.

[0093] As Figure 1AFurther shown, the distributed ledger system 1000 in example embodiments further comprises a partner discoverer 123, which in example embodiments is a software module and / or functionality implemented as executable code configured for keeping partner information of one or more partner nodes available, whereby a partner node can be one of the nodes of the peer-to-peer network 100 or a node not being part of the distributed ledger system 1000. In example embodiments, the partner discoverer 123 corresponds to a software module and / or functionality implemented as executable code configured for controlling the functionality of the partner discoverer 123. In example embodiments, the partner discoverer 123 is implemented at one or more nodes of the peer-to-peer network 100. In example embodiments, the partner discoverer 123 is an application programming interface (API) based (software) module configured for maintaining (e.g., storing) a registry comprising information related to one or more partner nodes and / or one or more nodes of the peer-to-peer network and / or one or more applications related to one or more partner nodes. In example embodiments, the partner discoverer 123 is a (software) module configured for generating a decentralized identifier representing (e.g., identifying) a partner node based on corresponding information related to a partner node received from one or more of the nodes of the peer-to-peer network 100 and / or received from a partner node (e.g., from a dedicated interface). For example, Figure 1A A partner node 190 is shown in communication with a node 104 of the peer-to-peer network 100 via a dedicated interface 150. In example embodiments, the dedicated interface 150 comprises a software development kit (SDK) 151 and / or an application programming interface (API) 152. It is noted that the partner discoverer 123 can thus correspond to example embodiments of the decentralized identifier obtainer. In example embodiments, the partner discoverer 123 is further configured for generating a pair of public and private keys to be assigned to the partner node 190 and / or for assigning and / or defining information of a partner role of the partner node and / or keeping this information available, the partner role defining access rights and / or read / write permissions of the partner node.

[0094] In an example embodiment, the distributed ledger system 1000 further comprises one or more further software modules and / or functionalities implemented as executable code configured for controlling respective functions and / or operations of the blockchain. In particular, in an example embodiment, the distributed ledger system 1000 further comprises a consensus controller 122 which, in an example embodiment, is a software module and / or functionality implemented as executable code configured for implementing a consensus mechanism, in particular for ensuring that a new data block is only added to the distributed ledger and / or a change is made to an existing data block and / or it is removed from the distributed ledger if consensus is reached among at least some nodes of the peer-to-peer network 100 or all of its nodes. Further, in an example embodiment, the consensus controller 122 is configured for controlling the storing of at least one hash value in association with at least one portion of a 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 one subgroup of nodes of the peer-to-peer network. In an example embodiment, the consensus controller 122 is implemented at one or more nodes of the peer-to-peer network 100.

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

[0096] Referring back to the memory 110, in an example embodiment, the data blocks 111, 112, 113, 114 can in particular represent transactions, shipments and / or smart contracts. Thereby, in an example embodiment, the respective data blocks represent stages of a transaction, a shipment and / or a smart contract. The respective data blocks can be generated as a result of a communication between one or more of the nodes of the peer-to-peer network 100 and a partner node. For example, the respective data blocks can be generated based on Figure 1A the communication between the partner node 190 and the node 104 of the peer-to-peer network 100 via the dedicated interface 150 as shown. As Figure 1B exemplarily shown, the dedicated interface 150 comprises, in an example embodiment, a software development kit (SDK) 151 and / or an application programming interface (API) 152. In an example embodiment, the API 152 comprises one or more content addressable APIs. In other words, the API 152 can comprise or correspond to a plurality of respective APIs provided for respective functions. For example, as Figure 1CAs shown, in exemplary embodiments, the distributed ledger system 1000 comprises a message ingestion API 152.1 implemented as part of the API 152. In exemplary embodiments, the message ingestion API 152.1 is configured for responding to incoming messages from the partner node 190, e.g. incoming messages related to an application being processed between the partner node 190 and the distributed ledger system 1000, with an interaction identifier (e.g. a message token) that can be used by the partner node 190 to query the processing status and details related to said application.

[0097] As Figure 1C As further shown, in exemplary embodiments, the distributed ledger system 1000 comprises a decentralized identifier resolver API 152.2 implemented as part of the API 152. In exemplary embodiments, the decentralized identifier resolver API 152.2 is configured for resolving a decentralized identifier associated with the partner node 190 and received from the partner node. The decentralized identifier resolver API 152.2 is particularly useful in case the partner node 190 belongs to a part of a non-distributed ledger system (e.g. a non-blockchain system) comprising a plurality of nodes assigned to respective decentralized identifiers generated for the non-distributed ledger system. In such a case, the distributed ledger system 1000 can take over the role of a master of servers (MoS) with respect to the decentralized identifiers.

[0098] After the login procedure has been performed between the distributed ledger system 1000 and the partner node 190, the partner node 190 can communicate with any one or more of the nodes of the peer-to-peer network 100. Figure 2 is an exemplary flowchart 200 illustrating exemplary embodiments according to the first aspect of the present disclosure. The flowchart 200 can be understood to illustrate an exemplary login procedure for logging in a partner node 190. Without limiting the scope of the present invention, in the following it is assumed that, as outlined above with respect to Figure 1A The node 104 of the peer-to-peer network 100 as disclosed above with respect to Figure 1A communicates with a partner node 190 (example of an external device) performs the steps of the flowchart 200. It should be noted that the steps of the flowchart 200 can equally be performed by any one or more of the nodes of the peer-to-peer network 100. Thereby, the node 104 and / or its corresponding processor can correspond to an example of at least one device according to the first aspect disclosed herein. Further, the method of the flowchart 200 can be performed by the distributed ledger system 1000, e.g. by one or more nodes of the peer-to-peer network 100 and / or by any one of the modules of the distributed ledger system 1000 disclosed herein.

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

[0100] For example, in example embodiments, the distributed ledger system 1000 is configured for (i.e. comprises a software module and / or functionality implemented as executable code at one or more of the nodes of the peer-to-peer network 100 and configured for controlling) providing at least one software development kit (SDK) to the partner node 190, e.g. the SDK 151 exemplarily shown in Fig. 1 1, which software development kit enables the partner node 190 to perform various operations when communicating with the distributed ledger system 1000. Based on the SDK 151, the partner node 190 and / or the distributed ledger system 1000 is enabled to manage a plurality of interactions between the distributed ledger system 1000 and the partner node 190, in example embodiments. For example, the partner node 190 can use the SDK 151 to send a request to the node 104 to create a decentralized identifier. Further, the SDK 151 can comprise one or more libraries related to decentralized identifiers, enabling the SDK 151 to perform authentication functions or interact with the distributed ledger system 1000 based on the decentralized identifier. Figure 1B

[0101] Referring back to Figure 2 In step 203, the node 104 obtains a decentralized identifier representing the partner node 190 based on the connection setup message. Thereby, in example embodiments, the decentralized identifier is generated at the distributed ledger system 1000, in example embodiments by the partner discoverer 123. Alternatively or additionally, the decentralized identifier can be obtained by receiving the decentralized identifier from the partner node 190. The latter case can apply, for example, in case the partner node 190 itself is a node of a non-distributed ledger system (e.g. a non-blockchain network) comprising nodes configured for communicating with each other based on decentralized identifiers. An example of such a system can for example correspond to a SAP HANA system. In this case, the distributed ledger system can take over the role of a master of sequence (MoS).

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

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

[0104] As a result, in example embodiments, the decentralized identifier is an identifier that is generated at the distributed ledger system 1000 and / or on the side of the partner node 190 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 with 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 aspects disclosed herein are not limited to this aspect, in example embodiments, the decentralized identifier comprises or corresponds to a DID specified by the World Wide Web Consortium, W3C.

[0105] As mentioned, the API 152 comprises Figure 1C a decentralized identifier resolver API 152.2 that is configured for resolving a decentralized identifier associated with and received from the partner node 190. In particular, in case the partner node 190 belongs to a part of another distributed ledger system (e.g., a blockchain system), the decentralized identifier can be related to a decentralized identifier scheme defined at the other distributed ledger system. In this case, the decentralized identifier resolver API 152.2 is configured for resolving the decentralized identifier received from the partner node 190. In particular, in example embodiments, the decentralized identifier resolver API 152.2 is configured for resolving a decentralized identifier received from a Hyperledger Fabric blockchain platform, from a Corda DLT, from a multi-chain blockchain, and / or from a Quorum blockchain platform.

[0106] Referring back to Figure 2In step 205, the node 104 obtains at least one hash value generated based on at least a portion of the distributed identifier obtained in step 203. For example, in an exemplary embodiment, the indexer 121 of the distributed ledger system 1000 is configured to generate a hash value based on at least a portion of the distributed identifier obtained in step 203, e.g. by applying a hash function to at least a portion of the distributed identifier. The indexer 121 can thus correspond to an exemplary embodiment of a hash value obtainer. In particular, the hash value can be obtained based on any portion of the distributed identifier referred to in the distributed identifier document. In particular, in an exemplary embodiment, the node 104 obtains at least one hash value generated based on the respective address (e.g. MAC address) of the one or more service endpoints and / or the one or more public keys included in the distributed identifier document associated with the distributed identifier. Thereby, in an exemplary embodiment, the service endpoints comprise at least one of the address (e.g. MAC address) of the node 104 and the address (e.g. MAC address) of the 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 the one or more service endpoints and / or the one or more public keys included in the distributed identifier document associated with the distributed identifier. As mentioned, the indexer 121 (which can also be referred to as a hash generator of the distributed ledger system 1000) can 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 can directly obtain the at least one hash value in case the indexer 121 is implemented at the node 104, and / or indirectly obtain the at least one hash value in case 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 can be stored in a portion of the memory 110 shared by the node 104 with the one or more other nodes of the peer-to-peer network 100, such that the node 104 has access to (and thus obtains) the at least one hash value.

[0107] In other words, as Figure 2Further shown in the method, in step 207, the node 104 can cause the at least one hash value to be stored in the secured portion 140 of the memory 110 of the distributed ledger system 1000 in association with at least a portion of the distributed identifier (in exemplary embodiments at least a portion of a distributed identifier document of the distributed identifier and / or the distributed identifier document) based on a consensus process involving at least a subset of the nodes of the peer-to-peer network 100. It is noted that in step 207, both the hash value and the distributed identifier can be stored in association in the secured portion 140. In exemplary embodiments, the consensus process can further involve the partner node 190.

[0108] For example, the consensus process implemented at one or more or all of the nodes of the peer-to-peer network 100 and / or in the form of the consensus controller 122 at the node 190 can be initiated, for example, by the node 104 based on communication with the partner node 190 to obtain consensus among the nodes participating in the consensus process, i.e., the at least one hash value can be stored at the secured portion 140 of the memory 110. Thereby, in exemplary embodiments, the consensus process can be limited to a subset of the nodes of the peer-to-peer network 100. In exemplary embodiments, the consensus process limited to a subset of the nodes of the peer-to-peer network 100 is with the partner node 190. The subset of the nodes of the peer-to-peer network 100 can for example correspond to a group of nodes involved in the application process with the partner node 190 (e.g., the nodes 101, 102, 103, and 104 shown in the method), for which group of nodes the login procedure is performed with the partner node 190. Figure 1A

[0109] ​In example embodiments, the secured portion 140 of the memory 110 corresponds to a dedicated portion of the memory that corresponds to or includes a respective dedicated storage space provided at and / or connected to one or more or all of the nodes of the peer-to-peer network 100, and / or to a cloud storage connected to and / or accessible by one or more or all of the nodes of the peer-to-peer network 100. In example embodiments, the secured portion 140 of the memory 110 is configured for providing identity-based access to the secured portion 140, e.g., the secured portion 140 provides access only to identified users. Further, in example embodiments, the secured portion 140 of the memory 110 is configured for encrypting stored data, e.g., for holding data in encoded form such that only authorized parties can decode the encoded data to access the original information. While aspects of the present disclosure are not limited in this regard, in example embodiments, the secured portion 140 of the memory 110 corresponds to or includes a library, in particular a specific library assigned to the distributed ledger, a HashiCorp library, a locally deployed library, and / or a cloud-based secure key store.

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

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

[0112] Figure 3 is an example flowchart 300 illustrating example embodiments of steps of a method that can be performed as part of the method of the flowchart 200 shown above Figure 2 is an example flowchart 300 illustrating example embodiments of steps of a method that can be performed as part of the method of the flowchart 200 shown above Figure 1AThe disclosed nodes 104 of the peer-to-peer network 100 perform the steps of the flowchart 300 when communicating with a partner node 190, e.g. as described above with respect to the method according to the first aspect of the present disclosure. Figure 1A The steps of the flowchart 300 are performed by the disclosed partner node 190 (example of an external device) when communicating. It is noted that the steps of the flowchart 300 can equally be performed by any one or more of the nodes of the peer-to-peer network 100. Thereby, the nodes 104 and / or their corresponding processors can correspond to examples of at least one device according to the first aspect of the present disclosure. Further, the method of the flowchart 300 can be performed by the distributed ledger system 1000, e.g. by one or more of the nodes of the peer-to-peer network 100 and / or by any one of the modules of the distributed ledger system 1000 disclosed herein.

[0113] As shown, in step 301, at least one pair of a public key and a private key is assigned to the partner node 190. For this purpose, e.g. the partner discoverer 123 can generate a pair of a public key and a private key to be assigned to the partner node 190, wherein the public key and the private key as referred to herein 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 can enable the use of smaller keys, providing a similar level of security as keys based on non-elliptic curve cryptography. Thereby, in exemplary embodiments, the keys are generated based on the SECP256K1 and / or SECP156R1 curve. It is noted that step 301 is performed as a step of the method according to the flowchart 200 in exemplary embodiments and can be performed before, after or in conjunction with step 203.

[0114] Further, in step 303, the node 104 provides the public key to the partner node 190 and, in step 305, based on a consensus process involving at least one subgroup of the nodes of the peer-to-peer network 100, stores at least the private key in the secured portion 140 of the memory 101 of the distributed ledger system 1000 in association with at least a portion of the decentralized identifier. Thereby, the storage of at least the private key can be performed based on a consensus process as described in the context of step 207 for storing at least one hash value. In exemplary embodiments, the public key is stored in the secured portion 140 of the memory 101 of the distributed ledger system 1000 in addition to the private key. In particular, in exemplary embodiments, 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.

[0115] Figure 4 is shown illustrating that the method according to the second aspect of the present disclosure can be performed by any one or more of the nodes of the peer-to-peer network 100 and / or by any one of the modules of the distributed ledger system 1000 disclosed herein. Figure 2 The flowchart 200 and / or the reference to the method according to the first aspect of the present disclosure is shown in the context of the distributed ledger system 1000. Figure 3An exemplary flowchart 400 of an exemplary embodiment of the method of the steps of the method performed by the part of the flowchart 300. Without limiting the scope of the present application, in the following it is assumed that, as above in relation to Figure 1A The disclosed nodes 104 of the peer-to-peer network 100 perform the steps of the flowchart 400 when communicating with the partner node 190, as above in relation to Figure 1A The disclosed partner node 190 (example of an external device) performs the steps of the flowchart 400 when communicating. It is noted that the steps of the flowchart 400 can equally be performed by any one or more of the nodes of the peer-to-peer network 100. Thereby, the node 104 and / or its corresponding processor can correspond to an example of at least one device according to the first aspect disclosed herein. Further, the method of the flowchart 400 can be performed by the distributed ledger system 1000, e.g. by one or more nodes of the peer-to-peer network 100 and / or by any one of the modules of the distributed ledger system 1000 disclosed herein.

[0116] As shown, in step 401, the partner node 190 is assigned at least one partner role defining access rights and / or read / write permissions of the partner node 190. Thereby, in this exemplary embodiment, upon logging in to the partner node 190, the partner node 190 is assigned a partner role defining, for example, write access permissions that can be associated with messages transmitted from the partner node 190 to the distributed ledger system 1000. It is noted that the partner node 190 can have one or more partner roles that can be set for one or more applications handled between the partner node 190 and the distributed ledger system 1000.

[0117] In step 403, based on the consensus process involving at least one subgroup of the nodes of the peer-to-peer network 100, information setting the at least one partner role (e.g. data corresponding to the at least one partner role) is stored in the secured part 140 of the memory 110 of the distributed ledger system 1000 in association with at least a part of the distributed identifier. The storage of the information setting the at least one partner role can be performed based on a consensus process as described in the case of step 207 for storing at least one hash value. In particular, in the 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 the distributed identifier document assigned to the distributed identifier stored in the secured part 140.

[0118] Thus, in the example embodiment, the on-boarding procedure 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 the distributed ledger system 1000, at least one decentralized identifier of the partner node 190; obtaining at least one pair of private and public keys for encrypting communications between the distributed ledger system 1000 and storing at least the private key in the secured portion 140 of the memory 110 of the distributed ledger system 1000 in association with the decentralized identifier; and assigning a partner role to the partner node 190.

[0119] It is noted that by storing the at least one hash value in the secured portion 140 of the memory 110 of the distributed ledger system 1000 in association with at least one of a portion of the decentralized identifier, the private and / or public key, and / or information about the partner role assigned to the partner node 190 (e.g., about the partner role), the information is made available to the partner discoverer 123 in the example embodiment as partner information. Thus, after the partner node is on-boarded, such partner information is made available to all nodes of the peer-to-peer network 100 or at least to a subset of the nodes of the peer-to-peer network 100 and can be referred to when further communicating with the partner node 190. Thereby, even in such cases where a node of the distributed ledger system 1000 communicates with an entity outside of the distributed ledger system, a specific security can be enabled for the corresponding communication. Based on the decentralized identifier, thus, a security of the communication can be implemented for a communication between a partner node of the peer-to-peer network 100 and an entity outside of the distributed ledger system, regardless of whether such partner node itself is part of the distributed ledger system, the blockchain system, or an entity independent of such system.

[0120] Figure 5 is an example flowchart 500 illustrating an example embodiment of a message ingestion procedure by which the distributed ledger system 1000 can consume messages from a partner node (e.g., from the partner node 190). Without limiting the scope of the present application, in the following it is assumed that the nodes 104 of the peer-to-peer network 100 as disclosed above with respect to Figure 1A Figure 1A ​When communicating, the disclosed partner node 190 (an example of an external device) uses Message Ingestion API 152.1 (which can be implemented at node 104 and / or at any one or more of nodes 102, 103, 104 in the peer-to-peer communication network) to execute the steps of flowchart 500. It should be noted that the steps of flowchart 500 can also be executed by any one or more nodes of the peer-to-peer network 100. Further, the method of flowchart 500 can be executed 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 flowchart 500 can be executed according to… Figure 2 The login process is executed after the method has been executed.

[0121] like Figure 5 As shown, in step 501, node 104 receives (or is made available to node 104 by its processor) 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 at least a portion of the owners of the distributed ledger system 1000 informing the owner of an order (e.g., an order for shipment). It should be noted that, in an exemplary embodiment, partner node 190 may be configured to send the message to node 104 of the peer-to-peer network 100 using the HTTPS (Hypertext Transfer Protocol Secure) protocol.

[0122] In step 503, Message Ingestion API 152.1 causes the storage of message content(s) and / or message attachments(s). For this purpose, Message Ingestion API 152.1 may cause the storage of message content(s) and / or message attachments(s) in, for example, local storage of node 104, i.e., independent of memory 110. Alternatively or additionally, Message Ingestion API 152.1 may cause the storage of message content(s) and / or message attachments(s) in a portion of memory 110 based on consensus processing, for example, involving consensus controller 122.

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

[0124] In step 507, the message ingestion API 152.1 generates or causes generation of a message token, and in step 508, the message ingestion API 152.1 provides or causes provision of the message token to a partner node 190 (example of an external device) in response to the message received in step 501. For example, in an exemplary embodiment, the message token comprises information based on which the partner node 190 can access state information about the state of an application processed between the partner node 190 and a node 104 of the peer-to-peer network 100. For example, the message token can comprise a link based on which the partner node 190 can access an internet address / page holding said information about the state of the application available for access. Further, in an exemplary embodiment, the message token comprises a quick response (QR) code (in particular a salted QR code) configured to enable the partner node 190 to access the state information. For example, the partner node 190 can similarly access the internet address / page holding the state information available for access by the partner node 190 by referring to the QR code. The QR code can further comprise a hash value generated based on a distributed identifier of the partner node 190 and / or based on a distributed identifier of the node 104, which hash value can enable the partner node 104 to verify the QR code. Based thereon, the state information can be displayed to a user of the partner node 190, e.g. via a display of the partner node 190 and / or connected to the partner node.

[0125] In step 509, the message ingestion API 152.1 provides the message received in step 501 to a pre-processor, which in an exemplary embodiment is implemented at one or more nodes of the peer-to-peer network, in particular at the node 104.

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

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

[0128] Thereby, in exemplary embodiments, the form the message is published to the endpoint of the partner node 190 takes or comprises a QR code, e.g., a salted QR code, protected by a verifiable credential signed by the private key of the node 104. The QR code can comprise a link based on which the partner node 190 can access an internet address / page holding said information about the update phase of the application processed available. The QR code can further comprise 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 can enable the partner node 104 to verify the QR code. Thus, the updated status can be made visible to a user of the partner node 190, e.g., via a display of the partner node 190 or connected to the partner node.

[0129] In step 603, the node 104 receives a response message from the partner node 190, the response message comprising response information, e.g., for verifying the application status, e.g., for approving the invoice. In turn, in step 605, the node 104 verifies the response message. For example, based on the decentralized identifier of the partner node 190 mentioned or comprised in the response message, a digital twin pairing, i.e., a machine-to-machine pairing, is established between the node 104 and the partner node 190. Further, the node 104 verifies the key pairing, e.g., verifies that the public key comprised or mentioned in the response message matches 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. Figure 3

[0130] ​In addition to the key pairing, in the example embodiment, the node 104 is configured to confirm that a hash value included in or referred to in the received message matches a hash value generated based on at least a portion of the obtained decentralized identifier. Since this hash value is generated in the example embodiment based on the endpoint information referred to in the decentralized identifier document of the partner node 190 specifically based on the decentralized identifier of the partner node 190, this hash value confirmation enables to ensure that the node from which the response message is received by the node 104 actually corresponds to the node 190 subject to the onboarding process.

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

[0132] Further, as Figure 6 shown, in a step 607, if the response message passes the verification, e.g. if the digital twin machine-to-machine pairing between the node 104 and the partner node 190 is successfully established, if the key pairing stored in the secured portion 140 and included in or referred to by the response message is successfully established, and if the hash value included in or referred to by the response message is confirmed to correspond to the hash value generated based on at least a portion of the obtained decentralized identifier at the time of onboarding of the partner node 190, the node 104 updates the data related to the application saved in the storage of the node 104 and / or the corresponding hash value and / or hash index related to the data saved in the memory 110.

[0133] Thus, the response message received from the partner node 190 in the step 603 can for example correspond to an approval of the delivery order already referred to in the message sent in the 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 said communication between the node 104 of the peer-to-peer network 100 and the external partner node 190, a consensus mechanism is established which advantageously enables the interoperability between the distributed ledger system 1000 and another distributed ledger system to which for example the partner node 190 can belong.

[0134] Further, referring back Figure 6 to the step 609, the node 104 sends to the partner node 190 a message including information on a new update phase of the application processing (e.g. “delivery order approved”), the message including an updated message token containing this information.

[0135] As in the case that the message token is sent to the partner node 190 in step 601, the message posted to the endpoint of the partner node 190 can take the form of or comprise, for example, a verifiable credential protected by a signature by the private key of the node 104, in particular a salted QR code. The QR code can comprise a link based on which the partner node 190 can access an internet address / page that keeps said information available about the new update phase of the application process (“invoice approved”). The QR code can further comprise a hash value generated based on the distributed identifier of the partner node 190 and / or based on the distributed identifier of the node 104, which can enable the partner node 104 to verify the QR code. Thus, the updated status can be visible to a user of the partner node 190, e.g. via a display of the partner node 190 or connected to the partner node.

[0136] At the same time, the node 104, e.g. a post-processor of the node 104 further mentioned herein, can store information indicating the success of the process, e.g. at a local storage of the node 104. Thereby, the node 104 can generate and / or update a verifiable credential, which can comprise, for example, the distributed identifier of the node 104, the distributed identifier of the partner node 190, a payload comprising a credential statement and a cryptographic proof, which can ensure the integrity of the verifiable credential. In particular, the post-processor can create or update the verifiable credential by attaching a verifiable credential (VC) Id of the message and by storing the VC to the local storage of the node 104.

[0137] In this way, the immutability of the data of the process between the node 104 of the peer-to-peer network 100 (of the distributed ledger system 1000) and the external node 190 can be established.

[0138] Figure 7 is Figure 1A a block diagram of the node 104 as an example of at least one device according to the first aspect.

[0139] Node 104 includes processor 104.1. Processor 104.1 may represent a single processor or two or more processors, which 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., program code that, when executed on processor 104.1, causes node 104 to perform embodiments of different methods). 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 permanently connected to processor 104.1 or at least partially removable from processor 104.3. Program memory 104.3 may be, for example, non-volatile memory. To name just a few examples, program memory may be, for example, flash memory; any 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. Main memory 104.2 may be, for example, volatile memory. Several non-limiting examples are given, such as RAM or DRAM memory. When executing an operating system and / or programs, main memory may be used, for example, as working memory for processor 104.1.

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

[0141] like Figure 8 As exemplified in, Figure 1A The data blocks 111, 112, 113, and 114 shown can correspond to the data generated by... Figure 1AThe nodes 101 and 104 of the peer-to-peer network 100 shown process application processes (e.g., transactions). Since only the 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 on, for example, respective local storage (data storage) 101.4 and 104.4 comprised by or connected to the nodes 101 and 104. Further, as exemplarily indicated in Figure 7 corresponding to the respective data blocks and / or hash indices #1, #2, #3, #4 identifying the respective hash values are stored on respective storage 101.4, 102.4, 103.4 and 104.4 comprised by or connected to at least some nodes of the peer-to-peer network 100, in the exemplary embodiment all nodes of the peer-to-peer network, in the exemplary embodiment thereby forming a distributed ledger. In other words, in the exemplary embodiment, the distributed ledger comprises a collection of hash indices and / or hash values, wherein the respective hash indices and / or hash values are associated with the corresponding data blocks and / or corresponding portions of data blocks stored at the storage of one or more nodes of the peer-to-peer network or connected to the one or more nodes independently of the distributed ledger.

[0142] Referring back to Figure 7 , the processor 104.1 further controls one or more communication interfaces 101.6 configured to receive and / or transmit information. For example, the node 104 can be configured to communicate with any of the nodes 101, 102, 103 of the peer-to-peer network 100 and / or with a partner node 190 of the peer-to-peer network 100. The communication can be based on, for example, (partly) wired connections and / or (partly) wireless connections. Figure 1A

[0143] The processor 104.1 further controls a user interface 104.5 configured to present information to and / or receive information from a user of the node 104. The user interface 104.5 can be, for example, a user interface by means of which a user can control a stationary or portable personal computer, a server, a server system and / or a mobile device.

[0144] The components 104.2 to 104.6 of the node 104 can be connected with the processor 104.1, for example, by means of one or more serial and / or parallel buses.

[0145] As further shown in Figure 7 , the processor 104.1 can further comprise a pre-processor 104.7, an application processor 104.8 and a post-processor 104.9, the pre-processor being configured to pre-process the information received by the node 104, the application processor being configured to process the information received by the node 104, and the post-processor being configured to post-process the information received by the node 104. Figure 5 ​application-related message from the message ingestion API 152.1 in step 509. The processor 104.1 can comprise any of a pre-processor 104.7, an application processor 104.8, and a post-processor 104.9 in the form of respective functional and / or structural units. Any of the pre-processor 104.7, the application processor 104.8, and the post-processor 104.9 can further be implemented in the form of respective software modules and / or functions implemented as executable code configured for implementing the respective functions at one or more nodes of the peer-to-peer network 100.

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

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

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

[0149] To inform the partner node 190 about the application state involved in the message received in step 201 and / or a different message received from the partner node 190, the post-processor 104.9 fetches the endpoint related to the partner node 190 from the partner discoverer 123 based on the decentralized identifier of the partner node 190. Then, the post-processor 104.9 can combine the response message payload with the verifiable credential and can sign the verifiable credential with the private key of the node 104. Then, the post-processor 104.9 can publish the message combined with the signed verifiable credential to the endpoint of the partner node 190.

[0150] The above-mentioned onboarding process of the partner node 410 (which can comprise deploying an SDK to the partner node 410 to enable application processing between the nodes 104 of the distributed ledger system 1000 and the partner nodes 190 outside the distributed ledger system, conducting digital-twin-based machine-to-machine pairing between the nodes 104 and the partner nodes 190 based on the decentralized identifier of the partner node 104, establishing public and private keys between the nodes 104 and the partner nodes 190, which keys 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 the nodes of the distributed ledger system 1000 and nodes not comprised in the distributed ledger system 1000, in particular with nodes of a different distributed ledger system.

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

[0152] In other words, in exemplary embodiments, the thin client enables the mobile device to become a node of the distributed ledger system 1000, as compared to the case where the partner node still acts as a node of its own system, such as a non-distributed ledger system. For example, in exemplary embodiments, the thin client enables the mobile device to be configured for generating hash values and / or hash indices for storage in the memory 110 of the distributed ledger system 1000 in association with corresponding data blocks. Thereby, in exemplary embodiments, the corresponding data blocks are stored in a cloud storage device accessible to the mobile device.

[0153] Figure 9 Exemplary nodes and / or node systems are shown that are capable of communicating with the distributed ledger system 1000 based on aspects and embodiments disclosed herein. Figure 9 The distributed ledger system 1000 is schematically shown as having various layers 1110, 1120, 1130, and 1140 that enable data communication between the distributed ledger system 1000 and different nodes and / or node systems. These different layers schematically show a multi-protocol blockchain layer implemented by the distributed ledger system 1000. In particular, the multi-protocol blockchain layer implements Ethereum, Quorum, Corda, and multi-chain protocols in exemplary embodiments. The particular construction / design of the distributed ledger system 1000 allows for communication with other distributed ledger networks based on smart contracts, for example, as needed. The particular construction / design of the distributed ledger system 1000 further allows for communication with networks that are not based on distributed ledger technology (DLT).

[0154] The decentralized identifier, in particular the DID, as further disclosed herein enables reliable and secure communication between non-DLT endpoints and the distributed ledger system 1000. While the decentralized identifier (e.g., the DID) can be a public address, a hash value can be stored in the secured portion 140 of the memory 110 of the distributed ledger system 1000 (e.g., the HashiCorb library) based on the decentralized identifier, in particular the DID, and thus ensures that the public key can be shared with non-DLT partners (e.g., the partner node 190).

[0155] Figure 9 A further distributed ledger system 1100 is further shown that can correspond in structure and protocol to the distributed ledger system 1000 and can be deployed, for example, for an owner different from the owner of the distributed ledger system 1000. The system 1200 can correspond, for example, to a Hyperledger Fabric (HLF) system, the system 1300 can 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 the node 1400 can correspond to a mobile device that can store data in a cloud-based data storage 1450.

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

[0157] If the endpoint and / or node that accesses the distributed ledger system 1000 is a non-DLT endpoint / node, such as a node of the system 1300, the corresponding node (e.g., a node connected to a SAP HANA system) can be connected to the distributed ledger system 1000 via an internet (e.g., HTTPS) connection and / or a local deployment connection. In this case, the node can have a dedicated decentralized identifier, e.g., a specific DID. In this case, the distributed ledger system 1000 takes the role of a master of server (MoS). In this case, the respective messages to / from the distributed ledger system 1000, which can be accessed by a non-DLT system and / or a non-blockchain system, e.g., by a SAP HANA, can be accessed based on a decentralized identifier (e.g., DID-based access, encrypted hash value sharing using a specific QR code, and / or a peer-to-peer data service (PDS) for peer-to-peer) to verify immutability. Data can be made immutable in the distributed ledger system, while the non-DLT system and / or the non-blockchain system, e.g., the SAP HANA system, plays the role of a data sender or receiver. Any change of the respective data is communicated to the non-DLT system and / or the non-blockchain system, e.g., the SAP HANA system, which is required to provide consensus before a corresponding data block can be created at the distributed ledger system.

[0158] In an example 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 additionally, the applet / Android is configured as a node configured to interact with the distributed ledger system 1000 to enable data communication and immutability. For example, a user can download a corresponding applet / Android to implement a node, select to connect to a cloud service (such as the cloud system 1450 shown) for local data storage. Actions of the user on such an applet (e.g. a booking action) will be automatically communicated to the distributed ledger system 1000. Figure 9

[0159] The following example embodiments are also disclosed:

[0160] Embodiment 1

[0161] A method comprising:

[0162] - receiving or causing to receive, from at least one external device, or transmitting or causing to transmit, to the at least one external device, a connection establishment message;

[0163] - obtaining or causing to obtain, based on the connection establishment message, a decentralized identifier representative of the external device;

[0164] - obtaining or causing to obtain at least one hash value generated based on at least part of the obtained decentralized identifier;

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

[0166] Embodiment 2

[0167] The method according to embodiment 1, the method being 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 part of a distributed ledger.

[0168] Embodiment 3

[0169] The method according to any one of embodiments 1 or 2, wherein the decentralized identifier is associated with a decentralized identifier document, the method further comprising:​

[0170] - obtaining or causing to obtain 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.

[0171] Embodiment 4

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

[0173] - assigning or causing to assign at least one pair of public and private keys to the external device;

[0174] - providing or causing to provide the public key to the external device; and

[0175] - storing or causing to store at least the private key in a secured portion of the memory of the distributed ledger in association with at least a portion of the decentralized identifier based on a consensus process involving at least one subgroup of nodes of the peer-to-peer network.

[0176] Embodiment 5

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

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

[0179] - storing or causing to store in a secured portion of the 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 based on a consensus process involving at least one subgroup of nodes of the peer-to-peer network.

[0180] Embodiment 6

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

[0182] - providing or causing to provide to the external device 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.

[0183] Embodiment 7

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

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

[0186] Embodiment 8

[0187] The method according to any one of embodiments 1 to 7, further comprising:

[0188] - obtaining or causing to obtain, from the external device, a message related to the application;

[0189] - generating or causing to generate a message token; and

[0190] - providing or causing to provide, to the external device, the message token in response to the received message related to the application.

[0191] Embodiment 9

[0192] The method according to embodiment 8, wherein the message token comprises a quick response (QR) code configured to enable the external device to access state information about a state of the application processed between the external device and the node of the peer-to-peer network.

[0193] Embodiment 10

[0194] The method according to embodiment 9, wherein the QR code comprises the hash value generated based on at least a portion of the obtained distributed identifier.

[0195] Embodiment 11

[0196] The method according to any one of embodiments 1 to 10, the distributed ledger comprising a set of hash indices and / or hash values, wherein a respective hash index and / or hash value is associated with a corresponding data block and / or a corresponding portion of a data block stored at the distributed ledger and at a storage of one or more nodes of the peer-to-peer network or connected to the one or more nodes independently of the different data block and / or the different portion of the data block.

[0197] Embodiment 12

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

[0199] Embodiment 13

[0200] The method according to embodiment 12, wherein the distributed ledger system comprises an indexer configured to assign a corresponding hash value to at least a portion of a data block and / or a sub-block of the distributed ledger by applying a hash function based on the respective data block of the distributed ledger and / or based on the respective sub-block of the distributed ledger independently of the different data block and / or the different sub-block.

[0201] Embodiment 14

[0202] According to the method of embodiment 13, wherein the respective relationship between the hash index and / or the hash value associated with a group of data blocks is stored as accessible and / or manageable by the indexer.

[0203] Embodiment 15

[0204] A distributed ledger system comprising:

[0205] at least two nodes of a peer-to-peer network, wherein a respective one of the nodes of the peer-to-peer network stores at least a portion of a distributed ledger;

[0206] a software development kit and / or an application programming interface configured for enabling a communication of a connection establishment message between at least one of the nodes of the peer-to-peer network and an external device;

[0207] a decentralized identifier obtainer configured for obtaining, based on the connection establishment message, a decentralized identifier representing the external device;

[0208] a hash value obtainer configured for obtaining at least one hash value generated based on at least a portion of the obtained decentralized identifier;

[0209] a consensus controller configured for controlling, based on a consensus process involving at least a subgroup of the nodes of the peer-to-peer network, a storage of 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.

[0210] Embodiment 16

[0211] The distributed ledger system according to embodiment 15, further comprising a partner node; wherein the external device corresponds to or is comprised in a mobile device, the mobile device comprising:

[0212] a thin client enabling the mobile device to perform the functions of a node of the distributed ledger system.

[0213] Embodiment 17

[0214] An apparatus comprising at least one processor and at least one memory including program codes, wherein the memory and the program codes are configured to, with the at least one processor, cause the apparatus at least to perform and / or control a method as claimed in any one of embodiments 1 to 14.

[0215] Embodiment 18

[0216] An apparatus comprising means for performing the method according to any of embodiments 1 to 14.

[0217] Embodiment 19

[0218] A tangible computer-readable medium storing computer program code which, when executed by a processor, causes an apparatus to perform and / or control the method according to any of embodiments 1 to 14.

[0219] Any presented connection in the described embodiments is to be understood in the sense of the components involved being operatively coupled. These connections can thus be direct or indirect connections with any number of intermediate elements or combinations of intermediate elements, and there can only be a functional relationship between the components.

[0220] It will be understood that all presented embodiments are merely exemplary and that any feature presented for a particular exemplary embodiment can be used with any aspect of the present disclosure as such or in combination with any feature presented for the same or another particular exemplary embodiment and / or in combination with any other feature not mentioned. It will further be understood that any feature presented for a particular class of exemplary embodiments can also be used in a corresponding manner in any other class of exemplary embodiments.

Claims

1. 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 (100) comprising at least two nodes, wherein a respective one of the nodes of the peer-to-peer network (100) stores at least a part of a distributed ledger; the method comprises: - receiving or causing to receive a connection establishment message from or transmitting or causing to transmit the connection establishment message to at least one external device; - obtaining or causing to obtain a decentralized identifier representing the external device based on the connection establishment message; - obtaining or causing to obtain at least one hash value generated based on at least a part of the obtained decentralized identifier; - storing or causing to store the at least one hash value in association with at least a part of the decentralized identifier in a secured part (140) of a memory (110) of a distributed ledger system (1000) comprising the peer-to-peer network (100) based on a consensus process involving at least a subgroup of the nodes of the peer-to-peer network (100), wherein the decentralized identifier is associated with a decentralized identifier document, the method further comprising: - obtaining or causing to obtain 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.

2. The method according to claim 1, further comprising: - allocating or causing to allocate at least one pair of public and private keys to the external device; - providing or causing to provide the public key to the external device; and - storing or causing to store at least the private key in association with at least a part of the decentralized identifier in the secured part (140) of the memory (110) of the distributed ledger based on a consensus process involving at least a subgroup of the nodes of the peer-to-peer network (100).

3. The method according to claim 1 or 2, further comprising: - allocating or causing to allocate at least one partner role defining access rights and / or read / write permissions of the external device to the external device; - storing or causing to store information setting the at least one partner role in association with at least a part of the decentralized identifier in the secured part (140) of the memory (110) of the distributed ledger system based on a consensus process involving at least a subgroup of the nodes of the peer-to-peer network (100).

4. The method according to claim 1 or 2, further comprising: - providing or causing to provide the at least one hash value generated based on at least a part of the obtained decentralized identifier in association with the decentralized identifier to the external device.

5. The method according to claim 1 or 2, further comprising: - establishing or causing to establish a digital-twin-based machine-to-machine pairing between the external device and at least one node of the peer-to-peer network (100) based in particular on the decentralized identifier.

6. The method according to claim 1 or 2, further comprising: - obtaining or causing to obtain an application-related message from the external device; - generating or causing to generate a message token; and - ​ - providing or causing to provide, to the external device, the message token in response to the received message related to the application.

7. The method of claim 6, wherein, The message token comprises a quick response code configured to enable the external device to access state information about a state of the application processed between the external device and a node (104) of the peer-to-peer network (100).

8. The method of claim 7, wherein, The quick response code comprises the hash value generated based on at least a portion of the obtained decentralized identifier.

9. The method of claim 1 or 2, wherein, The distributed ledger comprises a set of hash indices and / or hash values, wherein a respective hash index and / or hash value is associated independently of the distributed ledger with a corresponding data block and / or a corresponding portion of a data block stored at a storage (101.4, 102.4, 103.4, 104.4) of one or more nodes of the peer-to-peer network (100) or connected to the one or more nodes.

10. The method of claim 1 or 2, wherein, The method is performed by the distributed ledger system (1000).

11. The method of claim 10, wherein, The distributed ledger system (1000) comprises an indexer (121) configured to assign a corresponding hash value to at least a portion of a data block and / or a sub-block by applying a hash function based on the respective data block of the distributed ledger and / or based on the respective sub-block of the distributed ledger independently of different data blocks and / or different sub-blocks.

12. The method of claim 11, wherein, A respective relationship between hash indices and / or hash values associated with a group of data blocks is stored as accessible and / or manageable by the indexer (121).

13. A distributed ledger system (1000) comprising: - at least two nodes of a peer-to-peer network (100), wherein a respective one of the nodes of the peer-to-peer network (100) stores at least a portion of a distributed ledger; - a software development kit (151) and / or an application programming interface (152) configured to enable a communication of a connection establishment message between at least one of the nodes of the peer-to-peer network (100) and an external device; - a decentralized identifier obtainer (123) configured to obtain, based on the connection establishment message, a decentralized identifier representing the external device, wherein the decentralized identifier is associated with a decentralized identifier document; - a hash value obtainer configured to obtain, 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, at least one hash value generated based on at least a portion of the obtained decentralized identifier; - a consensus controller (122) configured to control, based on a consensus process involving at least one subgroup of the nodes of the peer-to-peer network (100), a storage of the at least one hash value in the secured portion (140) of the memory (110) of the distributed ledger system (1000) in association with at least a portion of the decentralized identifier.

14. The distributed ledger system (1000) of claim 13, further comprising the external device; wherein, The external device corresponds to or is comprised in a mobile device comprising: - a display (151.1) configured to display a quick response code comprising a hash value generated based on at least a portion of a decentralized identifier representing the mobile device, wherein the hash value is associated with a corresponding data block and / or a corresponding portion of a data block stored at a storage (101.4, 102.4, 103.4, 104.4) of one or more nodes of a peer-to-peer network (100) or connected to the one or more nodes. - a thin client that enables the mobile device to perform the functions of a node of the distributed ledger system (1000).

15. An apparatus comprising at least one processor, and at least one memory including a program code, wherein, The memory and the program code are configured to, with the at least one processor, cause the apparatus at least to perform and / or control a method as claimed in any of claims 1 to 12.

Images