DEVICE FOR CARRYING OUT TRANSACTIONS AND METHOD OF OPERATION THEREOF - Patent application

Abstract

To provide a method, a system, a device, a program and a storage medium for carrying out transactions via a state channel associated with a distributed ledger technology (DLT) system, without establishing the state channel by the device for carrying out the transactions itself.SOLUTION: The method performed by a first device includes: transmitting a first message prompting a second device to establish a state channel associated with a distributed ledger technology (DLT) system for the first device; receiving, from the second device, a second message signaling that the state channel for the first device has been established; and carrying out at least one transaction via the state channel.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to, among other things, computer-implemented methods for operating a device configured to execute transactions over at least one state channel associated with, for example, a Distributed Ledger Technology (DLT) system.

[0002] Additionally, the present disclosure relates to a device for performing transactions over at least one state channel. [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] Stefan Dziembowski, Sebastian Faust, and Kristina Hostakova. 2018. General State Channel Networks. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (CCS'18). Association for Computing Machinery, New York, NY, USA, 949-966. DOI: https: / / doi.org / 10.1145 / 3243734.3243856 [Non-patent document 2] S. Dziembowski, L. Eckey, S. Faust and D. Malinowski, "Perun: Virtual Payment Hubs over Cryptocurrencies," 2019 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA, 2019, pp. 106-123, doi:10.1109 / SP.2019.00020 [Non-patent document 3] Nakamoto, Satoshi. (2009). Bitcoin: A Peer-to-Peer Electronic Cash System, https: / / bitcoin.org / bitcoin.pdf [Non-patent document 4] Patrick McCorry, Surya Bakshi, Iddo Bentov, Sarah Meiklejohn, and Andrew Miller. 2019. Pisa: Arbitration Outsourcing for State Channels. In Proceedings of the 1st ACM Conference on Advances in Financial Technologies (AFT'19). Association for Computing Machinery, New York, NY, USA, 16-30, DOI: https: / / doi.org / 10.1145 / 3318041.3355461 Summary of the Invention [Means for solving the problem]

[0004] Exemplary embodiments relate to methods, particularly computer-implemented methods, for operating a device configured to execute transactions over at least one state channel, e.g., associated with a distributed ledger technology (DLT) system, the method including the steps of: sending a first message to at least one further device, the first message causing the at least one further device to set up a state channel for the device; receiving a second message from the at least one further device, the second message signaling that a state channel for the device has been set up; and executing at least one transaction over the state channel. This, in further exemplary embodiments, enables execution of transactions over the state channel without, e.g., the device for executing the transactions itself setting up the state channel. This, in further exemplary embodiments, allows devices that may have, e.g., relatively little computing power and / or communication bandwidth and / or relatively little memory resources, or that are not capable of regularly conducting data communications with further devices, to utilize the state channel for executing transactions.

[0005] In a further exemplary embodiment, the state channel enables the exchange of state or information characterizing state between at least two party devices without using one or more of the above DLT systems in particular. Thus, various states or corresponding information can be exchanged relatively quickly via the state channel, without requiring corresponding DLT system transactions to do so. Thus, in a further exemplary embodiment, transactions performed via the state channel may also be referred to as "off-chain" transactions.

[0006] In a further exemplary embodiment, at least one state channel, such as that described in [Reference 2] below, can be used, for example, to execute transactions.

[0007] The following documents [Reference 1] and [Reference 2] are hereby expressly incorporated herein:

[0008] Stefan Dziembowski, Sebastian Faust, and Kristina Hostakova. 2018. General State Channel Networks. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (CCS'18). Association for Computing Machinery, New York, NY, USA, 949-966. DOI: https: / / doi.org / 10.1145 / 3243734.3243856 [Reference 1]

[0009] S. Dziembowski, L. Eckey, S. Faust, and D. Malinowski, "Perun: Virtual Payment Hubs over Cryptocurrencies," 2019 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA, 2019, pp. 106-123, doi:10.1109 / SP.2019.00020 [Reference 2]

[0010] In further exemplary embodiments, for example, signed transactions and / or state information and / or state updates may be transmitted via a state channel, for example between potential consumers of resources and providers of resources, or between corresponding devices.

[0011] In further exemplary embodiments, a relatively large number of (e.g., signed) transactions may be transmitted over the state channel per hour, and resources may therefore be dynamically requested and / or provided accordingly.

[0012] In a further exemplary embodiment, the state channel may be, for example, a so-called ledger channel, which may be realized, for example, by a DLT system.

[0013] In a further exemplary embodiment, the DLT system may comprise at least one blockchain and / or at least one directed acyclic graph (English: directed acyclic graph, DAG).

[0014] In a further exemplary embodiment, a blockchain can be viewed as a chain of data blocks linked together using cryptographic methods (e.g., forming a hash value for each data block), for example according to the principles of a Merkle tree, which allows for tamper-resistant data storage in the blockchain.

[0015] In further exemplary embodiments, the blockchain may be implemented in the form of a distributed or decentralized data bank, with multiple network elements ("nodes") of the blockchain network each storing data blocks of the blockchain. Fundamental aspects of blockchain technology are described, for example, in the following publications: Nakamoto, Satoshi. (2009). Bitcoin: A Peer-to-Peer Electronic Cash System, https: / / bitcoin.org / bitcoin.pdf.

[0016] In further preferred embodiments, the DLT or blockchain may store one or more smart contracts, which may, for example, allow for the storage of information, e.g., in connection with the establishment of state channels according to exemplary embodiments, but may also allow for queries and the execution of further program functions, similar to a programming language, e.g., based on information stored in the blockchain and / or transactions executed with respect to the blockchain. Thus, in further exemplary embodiments, logical links corresponding to contractual regulations and / or information characterizing resource utilization, etc., may be stored in the blockchain by one or more smart contracts.

[0017] In a further exemplary embodiment, the step of sending the first message is configured to be performed directly from the device implementing the method, i.e. for example a device for performing the transaction, to the at least one further device.

[0018] In a further exemplary embodiment, the step of sending the first message is performed from the device implementing the method, i.e. e.g. the device for performing the transaction, to the at least one further device via at least one further device or apparatus, e.g. a gateway, which is configured to receive the first message from the device for performing the transaction and then send or forward the first message to the at least one further device.

[0019] In further exemplary embodiments, this applies equally to one or more further messages described below by way of example.

[0020] In a further exemplary embodiment, the method further comprises defining an initial state for future transactions, eg over the state channel, eg configured such that the first message is created based on the initial state.

[0021] In a further exemplary embodiment, defining the initial state includes negotiating terms for future transactions, the terms may be carried by a digital contract, e.g., a contract, e.g., a smart contract. In a further exemplary embodiment, the smart contract is anchored in, e.g., a DLT system, e.g., anchored in a blockchain of the DLT system.

[0022] In a further exemplary embodiment, the method further comprises the step of sending a third message to the at least one further device, the third message causing the at least one further device to initialize monitoring equipment, which can be configured to monitor the DLT system, e.g. repeatedly, e.g. periodically, for configurable events, e.g. events on a state channel for the device. This can be advantageous, for example, when a device for performing a transaction temporarily does not have a data connection and therefore cannot receive, e.g. state updates, via the state channel.

[0023] In a further exemplary embodiment, the monitoring device is configured, for example, in accordance with [Reference 3], below, which is hereby expressly incorporated herein.

[0024] Patrick McCorry, Surya Bakshi, Iddo Bentov, Sarah Meiklejohn, and Andrew Miller. 2019. Pisa: Arbitration Outsourcing for State Channels. In Proceedings of the 1st ACM Conference on Advances in Financial Technologies (AFT'19). Association for Computing Machinery, New York, NY, USA, pp. 16-30, DOI: https: / / doi.org / 10.1145 / 3318041.3355461, [Reference 3].

[0025] In a further exemplary embodiment, the third message is configured to be included in the first message, for example combined with the first message.

[0026] In a further exemplary embodiment, the method further comprises a step of transmitting timing information to the at least one further device, the timing information characterizing the temporal behavior of the device with respect to transactions that may be performed via the state channel, for example configured such that the timing information comprises an update interval at which the device, for example the one or said monitoring devices, notifies about new states, thereby enabling the at least one further device to initialize the monitoring devices to fit in time with the update interval, i.e. to adapt the operation of the monitoring devices to the temporal behavior of the device for performing transactions.

[0027] In a further exemplary embodiment, timing information is configured to be transmitted to the at least one further device together with or after the first message.

[0028] In a further exemplary embodiment, the method is configured to further include transmitting state information characterizing the current state, e.g., to a monitoring device, whereby the monitoring device is informed about the current state of the transaction via the state channel and can, e.g., adjust its own operation accordingly.

[0029] In a further exemplary embodiment, the method further includes sending a fourth message to the at least one further device, the fourth message being configured to cause the at least one further device to delete the state channel. Thus, for example, with respect to the device for performing the transaction, deletion of the state channel by the at least one further device can also be implemented, which further reduces the burden on the device for performing the transaction.

[0030] In further exemplary embodiments, at least one further device may be configured to execute transactions in the DLT system, e.g., a) set up one or more state channels for the device, b) delete one or more state channels for the device, and c) initialize one or more monitoring devices based on timing information characterizing the device's temporal behavior with respect to transactions that may be executed via the state channels. Thus, the at least one further device may, e.g., perform steps of managing the state channels, thereby "offloading" the device for executing transactions, e.g., so that the device for executing transactions does not need to consume corresponding computation time or other resources, in further exemplary embodiments. This may, in further exemplary embodiments, reduce the complexity of the device for executing transactions.

[0031] A further exemplary embodiment relates to a device for executing transactions over at least one state channel, e.g. associated with a distributed ledger technology (DLT) system, the device being configured to perform a method according to at least one of the preceding claims.

[0032] In further exemplary embodiments, the device may be configured as an Internet-of-Things device, e.g., the device is configured to perform transactions, e.g., via an existing state channel, e.g., the device is not configured to directly access one or the above DLT systems. In further exemplary embodiments, access to the DLT system may be performed by at least one further device, e.g., for setting up and / or removing a state channel.

[0033] In a further exemplary embodiment, the device may comprise at least one sensor device for determining sensor data. For example, the device may be configured as an IoT sensor device. In a further exemplary embodiment, the IoT sensor device, with support by at least one further device for access to the DLT system, may utilize a state channel for transactions, e.g., the provision or sale of sensor data in an Economy-of-Things sense, wherein the IoT sensor device may, for example, have the state channel set up or deleted and / or otherwise managed by the at least one further device.

[0034] A further exemplary embodiment relates to a method for managing a state channel associated with a distributed ledger technology (DLT) system, e.g., for at least one device for executing transactions via a state channel, e.g., for at least one device according to an embodiment, the method comprising: receiving a first message, e.g., from the device, where the first message indicates that a state channel for the device should be set up; setting up the state channel; and sending a second message to the device, where the second message signals that the state channel has been set up.

[0035] In a further exemplary embodiment, the method may further include a step of receiving a third message, e.g. from the device, where the third message indicates that the monitoring equipment should be initialized, and the monitoring equipment is configured to monitor the DLT system, e.g. repeatedly, e.g. periodically, for configurable events, e.g., for events on a state channel for the device, and optionally a step of initializing the monitoring equipment.

[0036] In a further exemplary embodiment, the method may further comprise a step of receiving timing information, e.g., from the device, characterizing the temporal behavior of the device with respect to transactions that may be performed over the state channel, e.g., the timing information may comprise an update interval at which the device, e.g., one or said monitoring devices, notifies about new states.

[0037] In a further exemplary embodiment, the method may further include receiving state information, e.g., from the device, characterizing the current state, and optionally transmitting the received state information, e.g., to a monitoring device.

[0038] In a further exemplary embodiment, the method may further include receiving a fourth message, e.g., from the device, where the fourth message indicates that the state channel should be deleted, and optionally deleting the state channel.

[0039] Further exemplary embodiments relate to a device for managing a state channel, e.g., associated with a Distributed Ledger Technology (DLT) system, for at least one device for executing transactions via a state channel, e.g., for at least one device according to an embodiment, wherein the device is configured to perform a method according to an embodiment. In further exemplary embodiments, the device for managing a state channel may also manage multiple state channels, e.g., for multiple or multiple (IoT) devices for executing transactions via one or more state channels, thus relatively removing computation and / or (data) communication intensive processes, e.g., setting up and / or deleting state channels, from the (IoT) devices.

[0040] In further exemplary embodiments, the device for managing the state channel or corresponding functionality may be realized, for example, in a mobile terminal device, such as a mobile phone or a laptop computer, or also in a fixed device, for example in the form of a software agent (computer program).

[0041] In a further exemplary embodiment, the device or corresponding functionality for managing the state channel may be realized, for example, in the form of a wallet service, i.e., a service for storing or managing private cryptographic keys, for example, for accessing the DLT system.

[0042] A further exemplary embodiment relates to a system comprising at least one device for executing transactions according to the embodiment and at least one device for managing a state channel for the at least one device for executing transactions, e.g., associated with a distributed ledger technology (DLT) system.

[0043] In a further exemplary embodiment, the system may further comprise at least one distributed ledger technology (DLT) system.

[0044] A further exemplary embodiment relates to a computer-readable storage medium containing instructions that, when executed by a computer, cause the computer to perform a method according to an embodiment.

[0045] A further exemplary embodiment relates to a computer program comprising instructions that, when executed by a computer, cause the computer to perform a method according to an embodiment.

[0046] Further exemplary embodiments relate to data carrier signals carrying and / or characterizing computer programs according to the embodiments.

[0047] Further exemplary embodiments relate to uses of the method according to the embodiments and / or the device according to the embodiments and / or the system according to the embodiments and / or the computer readable storage medium according to the embodiments and / or the computer program according to the embodiments and / or the data carrier signal according to the embodiments for at least one of the following: a) executing transactions, e.g., off-chain transactions, via at least one state channel, e.g., associated with a distributed ledger technology (DLT) system; b) managing at least one state channel, e.g., associated with a distributed ledger technology (DLT) system; c) enabling IoT (Internet-of-Things) devices to execute transactions, e.g., EoT (Economy-of-Things) transactions, via at least one state channel; d) managing at least one state channel for at least one IoT device, e.g., associated with a distributed ledger technology (DLT) system; e) managing monitoring equipment, e.g., for at least one IoT device, e.g., for executing transactions via at least one state channel, e.g., associated with a distributed ledger technology (DLT) system.

[0048] Further features, applications and advantages of the present invention will become apparent from the following description of exemplary embodiments of the invention as illustrated in the figures of the drawings, in which all features described or shown form the subject of the invention, either alone or in any combination, regardless of their abstraction in the respective claims or their dependent claims, and regardless of their expression or illustration in the description or drawings. [Brief explanation of the drawings]

[0049] [Figure 1] FIG. 1 is a simplified block diagram illustrating a schematic according to an exemplary embodiment. [Figure 2A] 5 is a schematic simplified flowchart of a method according to a further exemplary embodiment; [Figure 2B] 5 is a schematic simplified flowchart of a method according to a further exemplary embodiment; [Figure 3A] 5 is a schematic simplified flowchart of a method according to a further exemplary embodiment; [Figure 3B] 5 is a schematic simplified flowchart of a method according to a further exemplary embodiment; [Figure 3C] 5 is a schematic simplified flowchart of a method according to a further exemplary embodiment; [Figure 3D] 5 is a schematic simplified flowchart of a method according to a further exemplary embodiment; [Figure 4] FIG. 10 is a schematic simplified block diagram according to a further exemplary embodiment. [Figure 5] FIG. 10 is a schematic simplified block diagram according to a further exemplary embodiment. [Figure 6] FIG. 10 is a schematic simplified block diagram according to a further exemplary embodiment. [Figure 7A] 10 is a simplified schematic flow chart according to a further exemplary embodiment; [Figure 7B] 10 is a simplified schematic flow chart according to a further exemplary embodiment; [Figure 8] 4 is a simplified schematic timing diagram according to a further exemplary embodiment; [Figure 9] 10A-10C are schematic diagrams illustrating modes of use according to further exemplary embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0050] FIG. 1 illustrates, in schematic form, a simplified block diagram according to an exemplary embodiment, a device 200 for executing a transaction T over at least one state channel SC associated with, for example, a distributed ledger technology (DLT) system 10 is provided.

[0051] A further exemplary embodiment (see FIG. 2A) relates to a method, in particular a computer-implemented method, for operating the device 200, comprising step 102 of sending a first message N1 to at least one further device 300 (see also FIG. 1, e.g. directly or via another equipment not shown in FIG. 1, such as a gateway), whereby the first message N1 causes the at least one further device 300 to set up a state channel SC for the device 200; step 104 (FIG. 2A) of receiving a second message N2 from the at least one further device 300 (directly from the at least one further device or via another equipment not shown in FIG. 1, such as a gateway), whereby the second message N2 signals that a state channel SC for the device 200 has been set up; and step 106 (FIG. 2A) of executing at least one transaction T via the state channel SC. This allows, in further exemplary embodiments, the execution of transaction T over state channel SC, e.g., without device 200 itself setting up state channel SC for executing transaction T. This allows, in further exemplary embodiments, devices 200 that may have, e.g., relatively little computing power and / or communication bandwidth and / or relatively little memory resources, or that are not able to regularly communicate data with further devices, and / or that for other reasons are only able to perform steps that may be performed to set up a state channel at least temporarily, or possibly with limitations, to utilize state channel SC for execution 106 of transaction T.

[0052] In a further exemplary embodiment, the state channel SC enables the exchange of state or information characterizing state between at least two parties (e.g., a resource provider and a potential consumer) without the use of one or more of the above DLT systems 10. Thus, various states or corresponding information can be exchanged relatively quickly via the state channel SC, without requiring corresponding DLT system 10 transactions. DLT system 10 transactions may scale relatively poorly. Thus, in a further exemplary embodiment, transactions performed via the state channel SC may be referred to as "off-chain" transactions. In other words, in a further exemplary embodiment, the device 200 can efficiently execute a large number of transactions T via the state channel SC without having to set up or tear down the state channel SC itself.

[0053] In a further exemplary embodiment, at least one state channel SC, such as that described in [Reference 2] below, may be used to execute the transaction T, for example.

[0054] The following documents [Reference 1] and [Reference 2] are hereby expressly incorporated herein:

[0055] Stefan Dziembowski, Sebastian Faust, and Kristina Hostakova. 2018. General State Channel Networks. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (CCS'18). Association for Computing Machinery, New York, NY, USA, 949-966. DOI: https: / / doi.org / 10.1145 / 3243734.3243856 [Reference 1]

[0056] S. Dziembowski, L. Eckey, S. Faust, and D. Malinowski, "Perun: Virtual Payment Hubs over Cryptocurrencies," 2019 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA, 2019, pp. 106-123, doi:10.1109 / SP.2019.00020 [Reference 2]

[0057] In further exemplary embodiments, for example, signed transactions and / or state information and / or state updates may be transmitted via a state channel, for example between potential consumers of resources and providers of resources, or between corresponding devices.

[0058] For example, a system 1000 (FIG. 1) according to an exemplary embodiment may include devices 200, 300 and, optionally, a DLT system 10.

[0059] In further exemplary embodiments, system 1000 may also comprise at least one further device 200′ for executing transactions T over state channel SC and / or at least one further device 300′ for managing state channel SC for devices 200, 200′. In further exemplary embodiments, device 200′ may, for example, have a configuration equivalent to or at least similar to device 200. In further exemplary embodiments, device 300′ may, for example, have a configuration equivalent to or at least similar to device 300.

[0060] In a further exemplary embodiment, a relatively large number of (e.g., signed) transactions T may be transmitted per hour, e.g., between devices 200, 200′, via state channel SC, and resources executable by the transactions may be dynamically requested and / or provided accordingly.

[0061] In a further exemplary embodiment, the state channel SC may be, for example, a so-called ledger channel, which may be realized, for example, by one or the above DLT systems 10 or based on the DLT systems 10.

[0062] In a further exemplary embodiment, the DLT system 10 may comprise at least one blockchain 12 and / or at least one directed acyclic graph (English: directed acyclic graph, DAG, not shown).

[0063] In a further exemplary embodiment, the blockchain 12 can be viewed as a chain of data blocks linked together using cryptographic methods (e.g., forming a hash value for each data block), for example according to the principles of a Merkle tree, which allows for forgery-proof storage of data in the blockchain 12.

[0064] In further exemplary embodiments, the blockchain 12 may be implemented in the form of a distributed or decentralized data bank, with multiple network elements ("nodes") of the blockchain network each storing a data block of the blockchain 12. Fundamental aspects of blockchain technology are described, for example, in the following publications: Nakamoto, Satoshi. (2009). Bitcoin: A Peer-to-Peer Electronic Cash System, https: / / bitcoin.org / bitcoin.pdf.

[0065] In a further preferred embodiment, the DLT or blockchain 12 can store one or more smart contracts 14, which for example allow for the storage of information, e.g., in connection with the establishment of a state channel SC according to an exemplary embodiment, but also allow for queries and the execution of further program functions, similar to a programming language, e.g., based on information stored in the blockchain 12 and / or on transactions T executed with respect to the blockchain 12. Thereby, in further exemplary embodiments, information characterizing logical links and / or resource utilization corresponding to contractual regulations, etc., can be stored in the blockchain 12, e.g., by or in connection with at least one smart contract 14, e.g., so-called funding or anchor transactions, which can be used, e.g., to set up a state channel SC according to a further exemplary embodiment.

[0066] In a further exemplary embodiment, the step 102 of sending the first message N1 is configured to be performed directly from the device 200 implementing the method, i.e., for example, the device 200 for executing the transaction T, to at least one further device 300.

[0067] In a further exemplary embodiment, the step 102 of sending the first message N1 is performed from the device 200 implementing the method, i.e. for example the device 200 for executing the transaction T, to the at least one further device 300 via at least one further device (not shown in FIG. 1 ) or apparatus, for example a gateway, which is configured to receive the first message N1 from the device 200 and then transmit or forward the first message N1 to the at least one further device 300.

[0068] In further exemplary embodiments, this applies equally to one or more further messages N2, N3, N4, TI, ZI, which are described below by way of example.

[0069] In a further exemplary embodiment (see FIG. 2A), the method further comprises a step 100 of defining an initial state AZ for a future transaction T, for example via a state channel SC, such that a first message N1 is created based on the initial state AZ.

[0070] In a further exemplary embodiment, the step 100 of defining the initial state AZ includes negotiating the terms for a future transaction T, the terms may be held, for example, by a contract, e.g., a digital contract such as, e.g., smart contract 14, e.g., by the above-mentioned anchor transaction executable in the DLT system 10 by device 300. In a further exemplary embodiment, the smart contract 14 is, for example, anchored in the DLT system 10, e.g., anchored in the blockchain 12 of the DLT system 10.

[0071] In a further exemplary embodiment (see FIG. 2B ), the method further comprises a step 110 of sending a third message N3 to the at least one further device 300, which third message N3 causes the at least one further device 300 to initialize an optional monitoring equipment WT ( FIG. 1 ), which can be configured to monitor the DLT system 10, e.g. repeatedly, e.g. periodically, for configurable events, e.g. events on a state channel SC for the device 200. This can be advantageous, e.g., when the device 200 temporarily does not have a data connection to a device 200′ that shares and utilizes the state channel SC, and therefore cannot receive, e.g., state updates via the state channel SC.

[0072] In a further exemplary embodiment, the optional monitoring device WT is configured, for example, according to [Reference 3] below, which is hereby expressly incorporated herein.

[0073] Patrick McCorry, Surya Bakshi, Iddo Bentov, Sarah Meiklejohn, and Andrew Miller. 2019. Pisa: Arbitration Outsourcing for State Channels. In Proceedings of the 1st ACM Conference on Advances in Financial Technologies (AFT'19). Association for Computing Machinery, New York, NY, USA, pp. 16-30, DOI: https: / / doi.org / 10.1145 / 3318041.3355461, [Reference 3].

[0074] In a further exemplary embodiment, the third message N3 is included in the first message N1, for example arranged to be combined with the first message.

[0075] In a further exemplary embodiment (see FIG. 2B), the method further comprises a step 112 of transmitting timing information TI to at least one further device 300 (FIG. 1), the timing information TI characterizing the temporal behavior of the device 200 with respect to a transaction T that may be executed via the state channel SC, for example configured such that the timing information TI comprises an update interval within which the device 200, for example one or said monitoring equipment WT, notifies about a new state. This enables the at least one further device 300 to initialize the monitoring equipment WT to adapt in time to the update interval, i.e. to adapt its operation to the temporal behavior of the device 200 for executing the transaction T.

[0076] In a further exemplary embodiment, timing information TI is configured to be transmitted to the at least one further device 300 together with or after the first message N1.

[0077] In a further exemplary embodiment (see FIG. 2B), the method may further comprise a step 114 of transmitting state information ZI characterizing the current state, for example to the monitoring device WT, so that the monitoring device WT is informed about the current state of the transaction T via the state channel SC and can, for example, adjust its own behavior accordingly.

[0078] In a further exemplary embodiment, the method further comprises a step 116 of sending a fourth message N4 to the at least one further device 300, wherein the fourth message N4 is configured to cause the at least one further device 300 to delete the state channel SC. Thus, for example, with respect to the device 200 for executing transaction T, deletion of the state channel SC by the at least one further device 300 can be implemented, which further reduces the burden on the device 200 for executing transaction T.

[0079] Blocks 100-116 described above by way of example may be performed in a different order in further exemplary embodiments. In further exemplary embodiments, at least one of blocks 100-116 described above by way of example may be omitted, i.e., not performed. The same applies to the method described below by way of example.

[0080] In a further exemplary embodiment, at least one further device 300 (FIG. 1) may be configured to perform transactions in the DLT system (see double arrow A1 from FIG. 1), for example, a) set up one or the above state channels SC for device 200, b) delete one or the above state channels SC for device 200, and c) initialize optional one or the above monitoring equipment WT based on timing information TI that characterizes the temporal behavior of device 200 with respect to transactions T that may be performed via state channels SC. Thus, at least one further device 300 may, for example, perform steps of managing state channels SC, thereby, for example, “offloading” device 200, so that device 200, in a further exemplary embodiment, does not need to consume corresponding computation time or other resources. This may, in a further exemplary embodiment, reduce the complexity of device 200 for performing transactions or extend the useful life (e.g., battery operating life) of device 200.

[0081] Communication between the device 300 and the optional monitoring equipment WT is represented by the double arrow A2 in Figure 1. Communication between the optional monitoring equipment WT and the DLT system 10 is represented by the double arrow A3 in Figure 1.

[0082] Communication between optional device 200' and optional device 300' is represented by double arrows N1', N2' in Figure 1. Communication between optional device 300' and DLT system 10 is represented by double arrow A1' in Figure 1.

[0083] A further exemplary embodiment relates to a device 200 (FIG. 1) for executing a transaction T via at least one state channel SC, e.g. associated with a distributed ledger technology (DLT) system 10, the device 200 being configured to perform a method according to an embodiment.

[0084] In a further exemplary embodiment, it is contemplated that the device 200 is configured as an IoT (Internet-of-Things) device 200, e.g., the device 200 is configured to execute transactions T, e.g., via an existing state channel SC, and is not configured to directly access, e.g., one or the above DLT systems 10. In a further exemplary embodiment, access to the DLT system 10 can be performed by at least one further device 300, e.g., for setting up and / or deleting a state channel SC.

[0085] In a further exemplary embodiment, the device 200 may comprise at least one sensor equipment for determining sensor data. For example, the device 200 may be configured as an IoT sensor device 200. In a further exemplary embodiment, the IoT sensor device 200, with support by at least one further device 300 for access to the DLT system 10, may utilize a state channel SC for transactions T, such as, for example, the provision or sale of sensor data in the sense of EoT (Economy-of-Things), the IoT sensor device 200 being able to, for example, set up or delete and / or otherwise manage the state channel SC by the at least one further device 300. In a further exemplary embodiment, the device 200 executes transactions for the provision and / or sale of sensor data, or in general, of the resource itself, for example by so-called commitment transactions via the state channel.

[0086] A further exemplary embodiment (see FIG. 3A) relates to a method for managing a state channel SC associated with, for example, a distributed ledger technology (DLT) system 10, for at least one device for executing transactions T via the state channel SC, for example for at least one device 200, 200′ according to an embodiment, the method comprising a step 150 of receiving one or said first message N1, for example from the device 200 (directly or indirectly, i.e. the message N1 can also be sent from the device 200, for example to a gateway, which forwards the message N1 to the device 300 for performing the method according to FIG. 3A), where the first message N1 indicates that a state channel SC for the device 200 should be set up; a step 152 of setting up the state channel SC; and a step 154 ​​of sending a second message N2 to the device 200 (directly or, for example, via the gateway), where the second message N2 signals that the state channel SC has been set up and can be used in the future, for example by the device 200.

[0087] In a further exemplary embodiment (see FIG. 3B ), the method may further comprise a step 160 of receiving one or said third message N3, for example from the device 200, where the third message N3 indicates that the monitoring equipment WT should be initialized, and where the monitoring equipment WT is configured to monitor the DLT system 10, for example repeatedly, for example periodically, for configurable events, for example for events on a state channel SC for the device 200, and optionally a step 162 of initializing the monitoring equipment WT.

[0088] In a further exemplary embodiment (see FIG. 3C ), the method further comprises a step 165 of receiving timing information TI, for example from the device 200, characterizing the temporal behavior of the device 200 with respect to transactions T that may be performed via the state channel SC, for example the timing information TI being configured to comprise an update interval at which the device 200, for example one or said monitoring equipment WT, notifies about a new state.

[0089] In a further exemplary embodiment (see FIG. 3D ), the method may further comprise a step 167 of receiving state information ZI characterizing the current state, for example from the device 200, and optionally a step 169 of transmitting the received state information ZI, for example to the monitoring equipment WT. This avoids the need for the device 200 itself to transmit its state information ZI to the monitoring equipment WT. This may therefore, in a further exemplary embodiment, be performed rather by the device 300.

[0090] In a further exemplary embodiment (see FIG. 3D ), the method may further comprise a step 170 of receiving one or said fourth message N4, for example from the device 200, where the fourth message N4 indicates that the state channel SC should be deleted, and optionally a step 172 of deleting the state channel SC. This may be done, for example, by the device 300 executing a corresponding transaction, for example a so-called settlement transaction, with the DLT system 10.

[0091] A further exemplary embodiment relates to a device 300, 300′ (FIG. 1) for managing a state channel SC, e.g., associated with one or the above-mentioned distributed ledger technology (DLT) system 10, e.g., for at least one device 200, 200′ according to an embodiment, for executing a transaction T via a state channel SC, wherein the device 300, 300′ is configured to perform a method according to an embodiment (see, e.g., FIGS. 3A-3D ). In a further exemplary embodiment, the device 300, 300′ for managing a state channel SC may also manage multiple state channels SC, e.g., for multiple or multiple (IoT) devices 200, 200′ for executing transactions via one or more state channels, thus relatively removing computation- and / or (data-) communication-intensive processes, e.g., setting up and / or deleting state channels SC, from the (IoT) devices 200, 200′.

[0092] In further exemplary embodiments, the device 300, 300′ for managing the state channel SC or corresponding functionality may also be realized in a mobile terminal device, e.g., a mobile phone or a laptop computer, or in a fixed device, e.g., in the form of a software agent (computer program).

[0093] In a further exemplary embodiment, the device 300, 300′ for managing the state channel SC or corresponding functionality may be realized, for example, in the form of a wallet service, i.e., in the form of a service for storing or managing private cryptographic keys for accessing the DLT system 10.

[0094] A further exemplary embodiment (see FIG. 1 ) relates to a system 1000 comprising at least one device 200 for executing a transaction T according to an embodiment and at least one device 300 for managing a state channel SC for the at least one device for executing transactions, e.g. associated with one or said distributed ledger technology (DLT) system 10, e.g. for the at least one device 200 for executing transaction T.

[0095] In a further exemplary embodiment, the system 1000 may further comprise at least one distributed ledger technology (DLT) system 10.

[0096] 4 shows a simplified block diagram according to a further exemplary embodiment. An arrangement 200" or 300" is shown, which may, for example, in a further exemplary embodiment, comprise at least one of the devices 200, 200', 300, 300' according to FIG. 1. It should be noted that the devices 200, 300 according to the further exemplary embodiments comprise in principle structurally equivalent structures 200", 300", but may differ significantly from each other, for example with respect to computing power and / or memory capacity and / or communication bandwidth.

[0097] The configuration 200'', 300'' comprises a computing device 202 ("computer") having at least one computing core 202a and a memory device 204 allocated to the computing device 202 for at least temporary storage of at least one of the following elements: a) data DAT; b) a computer program PRG, in particular for implementing a method according to an embodiment.

[0098] In a further preferred embodiment, the data DAT may at least temporarily and / or partially include data of a transaction T, which in the case of device 200'' is, for example, data of a commitment transaction T via the state channel SC, and in the case of device 300'' is, for example, data of a funding or anchor transaction for setting up the state channel SC and / or data of a settlement transaction for deleting the state channel SC.

[0099] In a further preferred embodiment, the memory device 204 comprises a volatile memory 204a (eg, a working memory (RAM)) and / or a non-volatile memory 204b (eg, a flash EEPROM).

[0100] In further exemplary embodiments, the computing device 202 may comprise at least one of the following elements: a microprocessor (μP), a microcontroller (μC), an application-specific integrated circuit (ASIC), a system-on-a-chip (SoC), a programmable logic device (e.g., an FPGA, a field programmable gate array), a hardware circuit, a graphics processor (GPU, a graphics processing unit), or any combination thereof.

[0101] A further exemplary embodiment relates to a computer-readable storage medium SM including instructions PRG, which, when executed by a computer 202, cause the computer 202 to perform a method according to an embodiment.

[0102] A further exemplary embodiment relates to a computer program PRG comprising instructions, which when executed by a computer 202, cause the computer 202 to perform a method according to an embodiment.

[0103] A further exemplary embodiment relates to a data carrier signal DCS characterizing and / or transmitting a computer program PRG according to an embodiment. The data carrier signal DCS can be received, for example, via the optional data interface 206 of the device 200, and in a further exemplary embodiment can also transmit, via the data interface 206, for example, one or more of the messages N1, N2 or the information TI, ZI, and / or other information that can be or is to be transmitted, for example, via the state channel SC, and in the case of the device 300″, for example, information that can be transmitted between the device 300″ and the DLT system 10 (see, for example, the double arrow A1 from FIG. 1 ) and / or information that can be transmitted between the device 300″ and the monitoring equipment WT (see, for example, the double arrow A2 from FIG. 1 ).

[0104] In a further preferred embodiment, the device 200'' comprises an optional resource interface 208 for providing a resource R, which may for example comprise or be configured as a sensor device 208. Thus, in this example, the device 200 may sell its sensor data SD to a further device 200' via a state channel SC, for example in the framework of a commitment transaction T.

[0105] In a further preferred embodiment, in return for the sensor data SD, an amount of currency or information characterizing this amount can be transmitted from a purchaser 200′ of the sensor data SD over the state channel SC, for example also by means of a commitment transaction T, which transmission can also take the form of a so-called micropayment, i.e. a small payment. In this way, in a further exemplary embodiment, the sensor data SD can be traded or sold at a relatively small granularity (e.g. individual sensor data values ​​corresponding to a relatively small payment).

[0106] In further exemplary embodiments, information regarding payments may be utilized as an alternative or complement to information characterizing a currency or type of currency, which may be included, for example, in a smart contract 14 associated with a state channel SC, characterizing at least one of the following elements: property or asset or asset value, cost, money, cryptocurrency, promissory note, voucher, etc.

[0107] 5 shows a simplified block diagram according to a further exemplary embodiment. Two party devices 400, 410 are shown, which may be, for example, a resource provider 400 and a potential resource consumer 410. The resource may be, for example, electrical energy.

[0108] The provider 400 is assigned a device 401, which can communicate with the DLT system 10' (see double arrow A13) and can also communicate with a consumer 410 or at least one component 412 of the consumer 410 directly (or via a gateway (not shown)), for example outside the DLT system 10', i.e. off-chain (see double arrow A10).

[0109] In a further exemplary embodiment, the consumer 410 is assigned a device 411, which in its functionality at least partially corresponds to the device 200 according to the exemplary embodiment described above. The device 411 communicates with a further device 412 of the consumer 410 (see double arrow A11), which in its functionality at least partially corresponds, for example, to the device 300 according to the exemplary embodiment described above. Via communication A11, the device 411 can exchange, for example, messages N1, N2, N3, N4 or information TI, ZI with the further device 412 of the consumer 410, for example, causing the further device 412 of the consumer 412 to establish a state channel for, for example, a direct exchange of commitment transactions with, for example, the device 401 of the provider 400 (see double arrow A10). For this purpose, the further device 412 of the consumer 410 can perform data communication with, for example, the DLT system 10′ (see double arrow A12).

[0110] In a further exemplary embodiment, the DLT system 10′ is assigned a state channel framework 11′, which allows for example the management (e.g., setup, deletion, etc.) of state channels, for example in the sense of [Reference 2].

[0111] Collectively, the two party devices 400, 410, in further exemplary embodiments, can perform on-chain transactions A12, A13, i.e., transactions with the DLT system 10′, e.g., funding or anchor transactions and / or settlement transactions, as well as off-chain transactions A10, e.g., commitment transactions.

[0112] 6 schematically shows a simplified block diagram according to a further exemplary embodiment, in which two party devices 400, 410 can perform on-chain transactions A21, A23, A24 as well as off-chain transaction A22, where the data exchange according to the double arrow A22 corresponds to an off-chain transaction (e.g. of commitment type) via, for example, a state channel, which can be set up by device 402 (e.g. similar to or identical to device 300 according to FIG. 1) for device 401 (e.g. similar to or identical to device 200 according to FIG. 1).

[0113] In a further exemplary embodiment, the device 411 is configured equivalently, ie identically or at least similarly to the device 200 or 200', for example according to FIG. 1 .

[0114] In a further exemplary embodiment, the device 413 is configured equivalently, i.e. identically or at least similarly, to the device 300 or 300', for example according to Figure 1. In a further exemplary embodiment, the device 413 may also comprise the functionality of a wallet service, i.e. a service for storing or managing private cryptographic keys, for example for accessing the DLT system 10'.

[0115] In a further exemplary embodiment, party device 410 is assigned an optional gateway 414, which receives, for example, a message from device 411, for example, a message of type N1 (a request to device 413 to set up a state channel for device 411), and forwards it, for example, to device 413, which sets up, for example, a state channel for device 411. For example, gateway 414 can also receive, for example, a message of type N2 from device 413 (information that a state channel is being set up), and forward it to device 411. Similarly, gateway 414, in a further exemplary embodiment, can also exchange or forward further or other messages between at least two of devices 411, 413, 415.

[0116] In a further exemplary embodiment, the party device 410 is assigned optional monitoring equipment 415, which can observe DLT transactions, for example, in the DLT system 10′, for example, with respect to the device 411. In a further exemplary embodiment, data exchange between the optional monitoring equipment 415 and the device 411 can also occur via the gateway 414.

[0117] Figure 7A schematically shows a simplified block diagram according to a further exemplary embodiment, in which region BR1 can be assigned to a first party (e.g., a consumer), region BR2 can be assigned to, for example, the DLT system 10 (Figure 1) or an optional associated state channel framework (e.g., according to [Reference 2]), and region BR3 can be assigned to, for example, a second party (e.g., a resource provider).

[0118] In a further exemplary embodiment, one or more of the following elements are assigned to consumer BR1: a) a device 200, e.g., an IoT device 200, for executing a transaction T (Fig. 1) on a state channel SC; b) a device 300 for managing a state channel SC for the device 200, for example associated with the DLT system 10; c) Monitoring equipment WT. In a further exemplary embodiment, one or more of the following elements are assigned to provider BR3: a) a device 200′, for example an IoT device 200′, for executing a transaction T (FIG. 1) on a state channel SC; b) a device 300′ for managing a state channel SC for a device 200′, for example associated with the DLT system 10, which device 300′ may also have the functionality of a wallet service, for example; c) Monitoring equipment WT', d) Gateway GW.

[0119] In a further exemplary embodiment, block B1 represents an initialization or negotiation 100 of an initial state (see FIG. 2A ), e.g., the conclusion of an agreement between devices 200, 200′, which may be characterized, e.g., by a digital contract, e.g., a smart contract 14 (FIG. 1 ), which in a further exemplary embodiment may also be anchored, e.g., in the DLT system 10, e.g., by execution of a corresponding anchor transaction by at least one of devices 300, 300′. In a further exemplary embodiment, devices 200, 200′ perform the negotiation 100 off-chain, i.e., e.g., without a transaction with the DLT system 10 (see arrows e1, e2), where arrow e1 represents, e.g., a message that an initial state is generated or communicated to device 200′, and arrow e2 represents, e.g., a message that the initial state is confirmed by device 200′.

[0120] In a further exemplary embodiment, block B2 represents a process for creating state channel SC (FIG. 1). Device 200 sends message e3 to device 300, e.g., corresponding to message N1 according to FIGS. 1 and 2A, causing device 300 to establish state channel SC for device 200. Arrow e4 represents initialization or establishment of state channel SC for device 200 by device 300.

[0121] In a further exemplary embodiment, device 200′ may alternatively or complementary have device 300′ set up one or the above state channels SC for device 200′ for transaction T with device 200, with device 200′ sending a corresponding message e5 to gateway GW, which forwards the message to device 300′ in the form of message e6. Arrow e6′ represents the initialization or establishment of state channel SC for device 200′ by device 300′.

[0122] In a further exemplary embodiment, the device 300 sends a message e7 (corresponding for example to message N2 according to FIG. 1, FIG. 2A) to the device 200' in block B3 after the establishment e4 of the state channel SC.

[0123] In a further exemplary embodiment, after the establishment e6' of the state channel SC, the device 300' sends messages e8, e9 (corresponding, for example, to message N2 in Figures 1 and 2A) to the device 200' via the gateway GW in block B3.

[0124] In a further exemplary embodiment, device 300 initializes, in block B4, optional monitoring equipment WT for monitoring e11 of transactions of DLT system 10 on state channel SC (see arrow e10), and monitoring equipment WT notifies device 300 of the confirmation of the initialization, for example by message e12. In a further exemplary embodiment, device 300 can convey timing information TI (see FIG. 3C) of device 200 by monitoring equipment WT message e10, device 300 having possibly received timing information TI from device 200 in advance (for example with message e3 (FIG. 7A)). Thus, monitoring equipment WT can adapt its operation, for example its temporal behavior when monitoring DLT transactions in DLT system 10, to the temporal behavior of device 200.

[0125] In a further exemplary embodiment, in block B5 similar to block B4, a further monitoring device WT' can be initialized (see arrow e13), this time in the provider's domain BR3, for example for device 200', to monitor (e14) DLT transactions in the DLT system 10 related to the state channel SC on which device 200' performs transactions with device 200. The monitoring device WT' can confirm the initialization of device 300', for example by message e15.

[0126] In a further exemplary embodiment, at block B6, a transaction may be executed, e.g., an off-chain transaction, i.e., a commitment transaction may be executed, e.g., directly between devices 200, 200′, e.g., featuring a proposal e16 and / or an approval e17 of a new state.

[0127] In a further exemplary embodiment, in block B7 associated with the acceptance of the new state e17, a message e18 (see also block B8) can be sent from the device 200 to the monitoring equipment WT, informing the monitoring equipment WT of this new state accepted by the device 200′. This knowledge allows the monitoring equipment WT, for example future DLT transactions possibly decided by the monitoring equipment WT, to be properly evaluated (e.g., the state characterized by the DLT transaction can be evaluated as correct when it corresponds to a state conveyed by the device 200 and also accepted on the part of the device 200′).

[0128] Alternatively, in a further exemplary embodiment, device 200' may reject the new state proposed by device 200 (see arrow e19).

[0129] In a further exemplary embodiment, arrow e20 represents a proposal for a new state on the part of device 200'.

[0130] In a further exemplary embodiment, device 200 may approve the new state proposed by message e20 on the part of device 200' in block B9 (see arrow e21), and device 200' notifies device 300' of the approval e21 via the gateway by messages e22, e23 (see block B10).

[0131] Alternatively, device 200 may, in a further exemplary embodiment, reject the new state proposed by device 200' (see arrow e24).

[0132] In further exemplary embodiments, for example at block B11 (see FIG. 7B), the state channel SC (FIG. 1) utilized thereafter for off-chain transactions e16, 17, e19, e20, e21, e24 by device 200, 200′ can be deleted, for example by device 300 (see arrow e26) and / or by device 300′ (see arrow e29), for example by executing one or more so-called settlement transactions in DLT system 10. In further exemplary embodiments, device 200 or 200′ can cause device 300 and / or 300′ to delete the state channel (similar to message N4 according to FIG. 2B) (see arrows e25 or e27, e28).

[0133] In a further exemplary embodiment, a challenge-period is initiated by the deletion of the state channel SC (see arrow e30). For example, during the challenge period, the state characterized by the payment transactions e26, e29 can be repudiated when at least one party takes the view that the state characterized by the payment transactions e26, e29 is incorrect, e.g., due to tampering by one of the parties.

[0134] In a further exemplary embodiment, for example, the monitoring device WT, after receiving information e31 (see block B12) regarding the deletion e26, e29 of the state channel SC, checks whether the state characterized by the payment transactions e26, e29 is correct, for example by comparing it with the information obtained by message e18 (Figure 7A).

[0135] For example, as long as the monitoring device WT has knowledge of a newer (i.e. more recent in time) state, the monitoring device WT can register this newer state with the DLT system 10 in block B13 (see arrow e33).

[0136] In a further exemplary embodiment, for example, the monitoring device WT′, after receiving information e34 regarding the registration e33 of a newer state on the part of the monitoring device WT, checks whether the newer state is correct, for example by comparing it with the information obtained by messages e22, 23 (FIG. 7A) (block B14, see arrow e35).

[0137] As long as the monitoring device WT' considers the newer state to be valid, it can register this newer state in the DLT system 10 (see arrow e36 in block B15), thus, for example, determining the validity of the newer state, so to speak.

[0138] In a further exemplary embodiment, the device 300 closes the state channel SC (see arrow e37) and optionally informs the device 200 about the closure (see arrow e38).

[0139] In a further exemplary embodiment, the device 300' closes the state channel SC (see arrow e39) and optionally notifies the device 200' about the closure (see arrows e40, e41).

[0140] 8 is a simplified timing diagram according to a further exemplary embodiment. Region R1 shows transactions, e.g., commitment transactions, associated with device 200 (FIGS. 1, 7A, 7B), here four by way of example, one of which is labeled with reference symbol e50.

[0141] In region R2, the processes associated with the monitoring equipment WT are illustrated, with arrow e51 representing the device 200 informing the monitoring equipment WT about the new state e50. Now, in a further exemplary embodiment, the monitoring equipment WT starts monitoring e52 of the DLT system 10.

[0142] In a further exemplary embodiment, arrow e53 represents that the device 200 again informs the monitoring equipment WT about the new state, whereby for example the monitoring of the DLT system 10 by the monitoring equipment WT continues (see reference sign e54). The monitoring equipment WT then publishes the new state in block e55.

[0143] Area R3 represents a challenge period e56 (see also arrow e30 from Figure 7A) followed by an execution period e57 (execution period), during which the current state is executed or confirmed, for example again by transactions with the DLT system 10 (Figure 1).

[0144] In region R4, as in region R1, transactions (not individually numbered), e.g., commitment transactions, associated with device 200′ (FIGS. 1, 7A, 7B), are shown, here by way of example, as four. Arrow e58 represents the publication of a new state over state channel SC, e.g., initiating challenge period e56 as described above.

[0145] In a further exemplary embodiment, double arrow e59 represents the update interval of device 200, and double arrow e60 represents a period corresponding to the sum of update interval e59, monitoring e54, and publication e55. In a further preferred embodiment, period e60 is shorter than challenge period e56, thereby ensuring that reliable conflict resolution is possible even when, for example, device 200's data connection is at least temporarily interrupted. Thus, in a further exemplary embodiment, it is feasible that closure of the state channel (e.g., including settlement and conflict resolution) does not compromise the security guarantees of the protocol for transactions over state channel SC, even in configurations or environments in which devices 200, 200′, for example, have only limited data connectivity with each other.

[0146] In a further exemplary embodiment, the variables characterizing the temporal behavior of the components of the system 1000 (FIG. 1) are:

[0147] a) Challenge period CP: The time during which a party device (e.g., device 200) can respond to a state S(n) proposed, for example, by a commitment transaction. In a further exemplary embodiment, the challenge period can be used, for example, at the time of a conflict, to disclose a newer state S(m) (where m > n).

[0148] b) Update interval AI: The time interval of device 200 (see, for example, arrow e18 from FIG. 7A) at which device 200 notifies an optional monitoring device WT of a new state. For example, in an IoT device​​​​​​​​​​​​​​​​​A further exemplary embodiment (see FIG. 9 ) includes a) executing 502 a transaction T, e.g., an off-chain transaction, via at least one state channel SC, e.g., associated with a distributed ledger technology (DLT) system 10; b) managing 504 the at least one state channel SC, e.g., associated with the DLT system 10; c) enabling 506 an Internet-of-Things (IoT) device 200, 200′ to execute a transaction T, e.g., an Economy-of-Things (EoT) transaction, via the at least one state channel SC; d) configuring 508 a state channel SC for the at least one IoT device 200, 200′; The present invention relates to the use 500 of a method according to an embodiment and / or a device according to an embodiment and / or a system according to an embodiment and / or a computer readable storage medium according to an embodiment and / or a computer program according to an embodiment and / or a data carrier signal according to an embodiment for at least one of the following elements: e) managing 508, e.g. at least one state channel SC associated with the DLT system 10; e) managing 510, e.g. monitoring equipment WT, WT' for at least one device 200, 200' for executing transactions T via at least one state channel SC associated with the DLT system 10, e.g. for at least one IoT device 200, 200'.

[0153] Further exemplary embodiments enable a separation, e.g., in physical and / or logical terms, between the management (e.g., setup, deletion) of state channel SC and the execution of transactions T over state channel SC. Thus, for example, device 300 may be used for DLT communication, e.g., DLT communication may be available for, e.g., setting up and deletion of state channel SC, while device 200 executes transactions T over one or more state channels SC. This allows, for example, that a device 200 with relatively few computational or memory or communication resources may also be involved in protocols, e.g., layer 2 protocols, i.e., protocols for, e.g., state channel SC, or may utilize these protocols for, e.g., peer-to-peer transactions T, e.g., between devices 200, 200′, while device 200 need not be concerned about DLT communication, since the DLT communication is executed by, e.g., device 300, 300′. In particular, further exemplary embodiments enable, for example, devices 200, 200′ to not communicate with DLT system 10, yet guarantees regarding safety and reliability enabled by the Layer 2 protocol are still obtained or provided with respect to off-chain transactions T of devices 200, 200′.

[0154] Further exemplary embodiments and applications are described below, each of which can be used individually and / or in combination with one or more of the embodiments described above as examples.

[0155] In a further exemplary embodiment, the party 400, 410 (FIG. 5) may be an operator of a charging infrastructure for charging electrical energy storage devices, such as a charging station, or having a plurality of charging stations. In a further exemplary embodiment, another party may be an owner of a vehicle fleet, or an owner or driver of a vehicle.

[0156] To establish a state channel, e.g., for charging, for example, a vehicle to which device 200 (FIG. 1) is assigned and a charging station to which device 200′ is assigned agree on an initial state (see also, e.g., optional step 100 from FIG. 2A and / or arrows e1, e2 from FIG. 7A). In further exemplary embodiments, device 200, 200′ transmits the initial state, characterized by, e.g., a digital contract 14, to a respective further device 300, 300′ (see, e.g., arrows e3, e5, e6 from FIG. 7A), which device 300, 300′ is provided to set up a state channel for, e.g., device 200, 200′.

[0157] Once the state channel SC of all involved party devices has been initialized (arrows e4, e6'), devices 200, 200' are notified thereof (arrows e7, e8, e9) and can now execute transaction T via the state channel SC.

[0158] If charging is expected to take a longer period, e.g., several hours, in a further exemplary embodiment, the automobile or charging station may accordingly update the monitoring equipment WT, WT′ by their respective devices 200, 200′, e.g., repeatedly, e.g., periodically, e.g., every 30 minutes (therefore, the update interval AI is, as an example, 30 minutes), which reduces connections that may be provided or required on the part of the devices 200, 200′ and thus saves resources (e.g., bandwidth, energy). Based on this, in a further exemplary embodiment (update interval AI=30 minutes), the challenge period is set to more than 30 minutes.

[0159] A further exemplary embodiment relates to an application in the field of sharing economy, the principle of which is based on the idea of ​​renting out items such as tools, e.g. power tools (e.g. drills), etc., for which a fee is paid for use during the rental period.

[0160] At a rental station for power tools, modalities for renting, for example, a drill, such as payment per usage period, maximum usage period, rental period, etc., can be negotiated (see optional step 100 from FIG. 2A and / or arrows e1, e2 from FIG. 7A). A state channel SC is then established, for example between the device 200, 200′ assigned to the user or borrower and the drill or lender, for example by means of a corresponding further device 300, 300′. Via the state channel SC, for example, direct payment can be made for a configurable or negotiated usage period, and for corresponding, for example, peer-to-peer data transmission between the devices 200, 200′, for example, local wired and / or wireless communication protocols can be used, for example, for the state channel SC.

[0161] To conserve the electrical energy of the loaned drill, in a further exemplary embodiment, the drill may have limited data communication, e.g., once every 24 hours, e.g., to communicate a new state. Thus, in a further exemplary embodiment, the challenge period may be set to more than 24 hours. In a further exemplary embodiment, the challenge period may also be adapted, i.e., extended or shortened, e.g., dynamically (during the presence of the state channel SC). For example, when the drill's device 200' is expected to be offline (without data connection) for a longer period of time, e.g., a week, or for the entire agreed-upon loan period (e.g., due to use at a construction site where communication for the device 200' is not possible), the challenge period may be extended accordingly, e.g., to more than a week.

Claims

1. A method, in particular a computer-implemented method, for operating a device (200) configured to execute transactions over at least one state channel associated with a distributed ledger technology (DLT) system (10), comprising the step (102) of sending a first message (N1) to at least one further device (300), wherein said first message (N1) informs said at least one further device (300) for said device (200) of a state channel between said device (200) and a third device (200'). a step (102) of setting up a state channel (SC) for said device (200); a step (104) of receiving a second message (N2) from said at least one further device (300), said second message (N2) signaling that said state channel (SC) for said device (200) has been set up; and a step (106) of performing at least one transaction (T) between said device (200) and said third device (200') via said state channel (SC).

2. The method of claim 1, further comprising a step (100) of defining an initial state (AZ) for future transactions via the state channel (SC), wherein the first message (N1) is created based on the initial state.

3. 3. The method of claim 1, further comprising the step of: sending a third message (N3) to the at least one further device (300), the third message (N3) causing the at least one further device (300) to initialize a monitoring device (WT) (e10), the monitoring device (WT) being configured to repeatedly and periodically monitor the DLT system (10) for configurable events on the state channel (SC) for the device (200).

4. 4. The method of claim 3, wherein said third message (N3) is included in said first message (N1) and is combined with said first message (N1).

5. 5. The method according to claim 3 or 4, further comprising a step (112) of transmitting timing information (TI) to the at least one further device (300), wherein the timing information (TI) characterizes the temporal behavior of the device (200) with respect to transactions (T) that may be performed via the state channel (SC), and wherein the timing information (TI) comprises an update interval (e59) at which the device (200) or the monitoring equipment (WT) notifies about a new state.

6. 6. The method of claim 5, wherein said timing information (TI) is transmitted to said at least one further device (300) together with said first message (N1) or after said first message (N1).

7. The method according to any one of claims 3 to 6, further comprising the step of transmitting (114) state information (ZI) characterizing the current state to said monitoring device (WT).

8. 8. The method according to claim 1, further comprising the step of sending (116) a fourth message (N4) to the at least one further device (300), wherein the fourth message (N4) causes the at least one further device (300) to delete the state channel (SC).

9. 6. The method of claim 5, wherein the at least one further device (300) is configured to perform transactions in the DLT system (10) by a) setting up one or the state channels (SC) for the device (300), b) deleting one or the state channels (SC) for the device (300), and c) initializing one or the monitoring equipment WT based on a plurality of or the timing information (TI) characterizing the temporal behavior of the device (200) with respect to transactions that may be performed via the state channels (SC).

10. A device (200) for executing transactions via at least one state channel associated with a distributed ledger technology (DLT) system (10), the device (200) being configured to implement a method according to any one of claims 1 to 9.

11. 11. The device (200) of claim 10, configured as an Internet-of-Things device, wherein the device (200) is configured to perform transactions over an existing State Channel (SC), and wherein the device (200) is not configured to directly access one or the DLT systems (10).

12. The device (200) according to claim 10 or 11, comprising at least one sensor device (208) for determining sensor data (SD).

13. A method for managing a state channel (SC) associated with a distributed ledger technology (DLT) system (10) for at least one device (200) for executing transactions via said state channel (SC), comprising: a step (150) in which at least one further device (300) receives from said device (200) a first message (N1), said first message (N1) indicating for said device (200) that a state channel (SC) between said device (200) and a third device (200′) should be set up; a step (150) in which the first device (200) and the third device (200') execute at least one transaction (T) via the state channel (SC); a step (152) in which the at least one further device (300) sets up the state channel (SC); and a step (154) in which the at least one further device (300) sends a second message N2 to the device (200), the second message (N2) signaling that the state channel (SC) has been set up.

14. The method of claim 13, further comprising a step (160) of receiving a third message (N3) from the device (200), the third message (N3) indicating that a monitoring device (WT) should be initialized (162), the monitoring device (WT) being configured to repeatedly and periodically monitor the DLT system (10) for configurable events relating to the state channel (SC) for the device (200), and optionally a step (162) of initializing the monitoring device (WT).

15. The method of claim 14, further comprising a step (165) of receiving timing information (TI) from the device (200), the timing information (TI) characterizing the temporal behavior of the device (200) with respect to transactions (T) that may be executed via the state channel (SC), and the timing information (TI) including an update interval (AI) at which the device (200) or the monitoring equipment (WT) notifies about a new state.

16. A method according to any one of claims 3 to 7, or 9, or 14, or 15, further comprising a step (167) of receiving state information (ZI) characterizing the current state from the device (200), and optionally a step (169) of transmitting the received state information (ZI) to the monitoring equipment (WT).

17. A method according to any one of claims 1 to 9 or 13 to 16, further comprising a step (170) of receiving a fourth message (N4) from the device (200), the fourth message (N4) indicating that the state channel (SC) should be deleted, and optionally a step (172) of deleting the state channel (SC).

18. A device (300) for managing a state channel (SC) associated with a distributed ledger technology (DLT) system (10) for at least one device (200) for executing transactions via the state channel (SC), the device (300) being configured to perform the method of any one of claims 13 to 17.

19. A system (1000) comprising at least one device (200) according to any one of claims 10 to 12 and at least one device (300) according to claim 18.

20. 20. The system (1000) of claim 19, further comprising at least one distributed ledger technology (DLT) system (10).

21. A computer-readable storage medium (SM) comprising instructions (PRG), which, when executed by a computer (202), cause the computer (202) to perform the method of any one of claims 1 to 9 or 13 to 17.

22. A computer program (PRG) comprising instructions, which when executed by a computer (202), cause the computer (202) to perform a method according to any one of claims 1 to 9 or 13 to 17.

Images