WO2019243359A1 - System, verfahren zum betreiben eines systems, computerprogramm und speicherprogrammierbares computerprogramm - Google Patents
System, verfahren zum betreiben eines systems, computerprogramm und speicherprogrammierbares computerprogramm Download PDFInfo
- Publication number
- WO2019243359A1 WO2019243359A1 PCT/EP2019/066078 EP2019066078W WO2019243359A1 WO 2019243359 A1 WO2019243359 A1 WO 2019243359A1 EP 2019066078 W EP2019066078 W EP 2019066078W WO 2019243359 A1 WO2019243359 A1 WO 2019243359A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- distributed ledger
- ledger system
- router
- transactions
- network
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
Definitions
- the invention relates to a system with distributed ledger systems, in particular blockchains.
- blockchain is understood to mean the blockchain system.
- a blockchain is a continuously expandable list of data records, called “blocks”. These are linked together using cryptographic methods. Each block typically contains a cryptographically secure hash of the previous block and a time stamp in the header. The block also contains transaction data ,
- Consumption information such as Gas / electricity consumption, data volume, access to programming interfaces of cloud services etc. are usually managed on a central data storage device. However, if a lot of data is generated in a short time, the throughput for storing the data is crucial. The billing and contractual terms between the trading partners must be managed and negotiated by a central, trustworthy coordination point.
- the occupants of a vehicle can use personalized services tailored to their needs. These services are created by developers or service center employees and, for example, provided by the vehicle provider. These personalized services are presented to the driver or the occupants in a vehicle in the form of an application. All participants i.e. service providers as well as service users, such as a driver, offer data. The data traffic must be logged and transparently displayed and billed for everyone.
- the invention has for its object to provide an improved and transparent billing of services that are offered in a computer network or a computer network of individual computers.
- the object is achieved by specifying a system with a network with several network nodes, which each have at least one service via an application programming Provide an interface, and a router which is configured to communicate with the multiple network nodes and to manage the application programming interfaces, and a transaction monitor,
- the router using the the first distributed ledger system can be connected for communication, and wherein a smart contract for executing and managing transactions between the router and a user is provided by the router on the first distributed ledger system, and wherein metadata generated by the transactions the transactions are logged by the transaction monitor, with a second distributed ledger system, in particular a second blockchain, with interconnected second distributed ledger system nodes, the second distributed ledger system for storing the logged metadata with the Transaction monitor is connectable, and being the second distributed ledger system m has a second consensus algorithm for block generation, and wherein the second consensus algorithm enables a shorter block generation cycle than can be achieved with the first consensus algorithm.
- a service is to be understood as the provision or processing of data or other services, for example.
- the network can in particular be designed as a peer-to-peer network.
- the network can also be designed as a private blockchain in which the participants, that is to say the individual network nodes, are known.
- the network can also be designed as a service or service cluster.
- the services offered by the individual Network nodes provided by application programming interfaces. Access to the application programming interfaces is granted using an access key. This access key is preferably limited in time or quantity.
- the router manages the successful accesses to the application programming interface and thus the services of the individual network nodes, that is, it enables the network nodes to register their application programming interfaces on a first distributed ledger system and coordinates the access.
- the router therefore manages the application programming interfaces of all network nodes and the registration of the application programming interfaces by the smart contract on the first distributed ledger system and counts the successful accesses to these application programming interfaces ,
- the router is thus virtually the "owner" of the smart contract. If the router also has its own wallet, the user can communicate directly with the router to pay for the transactions.
- the router is therefore used to publish the available application programming interfaces and to control the application programming interface access and to control application programming interface traffic.
- Each of the network nodes has at least one private key as well as its own wallet for executing the transactions, that is to say for providing the services and for receiving cryptocurrency via the first distributed ledger system.
- Each service is first signed by the network node with the private key from the wallet.
- a wallet is a data structure in which the private and public key are securely stored.
- the public key also called the public key
- the unique identifier for example an address
- a public key is a public address, also called a receiving address, to which you send the cryptocurrency, for example.
- a distributed ledger system which can also be called a decentralized database system, is networked computers that come to a consensus about the order of certain transactions and that these transactions update data.
- a blockchain is the best known variant of a distributed ledger system.
- the distributed ledger system is an electronic, public ledger known as the ledger, which is implemented as a computer-based, decentralized, distributed system made up of data blocks.
- the distributed ledger system consists of a series of data blocks, in each of which one or more transactions are combined and provided with a checksum. Transactions are data that are recorded in chronological order, traceable, unchangeable and without a central authority. Each transaction contains a public key from the node that created and signed the transaction.
- Each block typically contains a cryptographically secure hash of the previous block, a time stamp and transaction data.
- Distributed ledger systems are mainly used in peer-to-peer (p2p) networks and other networks.
- p2p network is a distributed application architecture that distributes tasks or workloads between the "peers”.
- Equal participants in the distributed ledger system are so-called distributed ledger system nodes.
- Suite who, for example, "participates” in a blockchain is considered as “Blockchain node” or “blockchain node”.
- Each blockchain node always receives a current copy of the blockchain, which is continuously updated.
- Each blockchain node that belongs to a "blockchain” therefore usually has the same rights to save the blockchain and add new blocks, i.e. to validate them.
- New blocks of the distributed ledger system are generated in a computation-intensive process, using a so-called consensus process or consensus algorithm. These newly created blocks are then added to the distributed ledger system and distributed to all distributed ledger system nodes via the network.
- a consensus algorithm thus ensures that the next block in the distributed ledger system is always the real deal and thus holds the distributed ledger system together as a decentralized, distributed database.
- the consensus algorithm therefore determines which node can validate a new block and attach it to the system.
- the consensus algorithms are based primarily on cryptographic algorithms. There are various algorithms for establishing the consensus.
- the well-known Bitcoin blockchain is currently based on the proof-of-work consensus algorithm.
- the degree of difficulty of the cryptographic problem to be solved for the generation of a valid block is adapted.
- the level of difficulty of the cryptographic to be solved Proof of work problems selected accordingly.
- the solution With the proof-of-work consensus algorithm, the solution currently takes about 10 minutes on average.
- the distributed ledger system node of the distributed ledger system checks whether the semantics and syntax transactions are correct and whether the digital signatures of the initiator, here the service provider of the transactions, match the address , A new block is then generated, in which the hash value generated is linked to the hash value of the previous block.
- the current block is distributed to all nodes. This means that every node always has a current copy of the distributed ledger system. Since all blocks are formed based on existing blocks by inserting the hash value of the previous block into a new block, a chain is formed. The transactions are thus protected against manipulation, since the chain up to the initial block, also called the Genesis block, can be traced by the chaining of the blocks.
- the chained blocks create a permanent and unchangeable record of all transactions. Since the transactions are available via the distributed ledger system, you can see from which block in the chain, for example, the content of a transaction no longer matches the previous version. The transactions are therefore protected against manipulation. Modifying a transaction in a block that had already been formed in the distributed ledger system at an earlier point in time would be possible if a checksum was created for the existing blocks.
- mining The implementation of a consensus algorithm is called "mining" in the context of a blockchain.
- miners Miners try to find a result with certain properties by executing arithmetic operations billions of times.
- Smart contracts are programmable contracts that are defined by an executable program code and are automatically executed on the distributed ledger system according to previously defined conditions. Smart contracts represent a control or business rule within a technical protocol. Smart contracts are computer protocols that represent or check contracts.
- the conditions agreed in a smart contract are secured by the distributed ledger system.
- the implementation of the contractual conditions is controlled via the associated transactions.
- Follow-up actions provided in a programmed smart contract can be carried out depending on the transaction.
- Smart contracts can be executed using state channels.
- a state channel is essentially a two-way channel between two users, or here network nodes and users who want to complete transactions with one another. Each user signs these transactions with their private key. These transactions take place entirely outside the distributed ledger system (off-chain) and only between users, which means that they can be executed very quickly compared to on-chain transactions.
- State channels can be closed at a predetermined point, for example when a predetermined amount of transactions has been carried out or after a certain period of time. As soon as a state channel is closed, the end result can be uploaded to the distributed ledger system so that it becomes official.
- Metadata is structured data that describes objects such as data, documents, people, etc. They ensure that the descriptions of different objects are based on a uniform structure. So metadata describes the actual data. They can be embedded in objects or made available in their own data record.
- Transactions between individual participants are possible off-chain through the state channels.
- transactions are the use of the various services or, for example, the payment for this use by a user, here, for example, a contractual partner.
- a state channel is first set up between two users via the smart contract in order to exchange the access key and process the payment transactions.
- the access key is only exchanged between the users when the first user has sent ether or another cryptocurrency to the second user.
- smart contracts have been negotiated individually with each network node. According to the invention, it was recognized that this task is very time-consuming and entails increasing complexity. It was also recognized that, in particular in such a network, the information about transactions is lost when a state channel is used. This leads to problems in particular when billing.
- a transaction monitor for example when the state channel is closed or when the smart contract is ended, is prompted to transfer the metadata collected about the individual transactions to a second distributed ledger system, which is used in the block generation by a second consensus algorithm is faster to cast off. Since many transactions occur on the first distributed ledger system, for example using a state channel, a second faster distributed ledger system with a higher transaction rate than the first distributed ledger system is necessary.
- the router can also be used as a transaction monitor, for example.
- the metadata of the individual transactions made collected by the transaction monitor are preferably stored in encrypted form on the second, fast distributed ledger system.
- the metadata of the transactions that is to say the interaction model between two users, is thus stored on the second faster distributed ledger system. This makes it possible to guarantee access to the transaction history to anyone who is interested in this metadata.
- the key for using the metadata is preferably stored in a smart contract on the second distributed ledger system.
- the storage of individual transactions can be made easier by storing the metadata on the second, fast distributed ledger system.
- Selected metadata can also be made publicly accessible on the second distributed ledger system, while other metadata are only made accessible to a limited group of participants.
- the invention has the effect that many transactions of the network are accumulated with the various services and are settled at a specific point in time on the second distributed ledger system.
- the various services can include, for example, the provision of data or personalized services which are prepared by the individual network nodes, for example for the occupants of a vehicle.
- the time of settlement can be democratic between the network nodes that were involved in the transactions are decided. This can be done, for example, by a virtual choice.
- the profit is advantageously weighted and distributed among the network nodes involved on the basis of the transactions which are stored by the metadata on the second distributed ledger system and are thus known.
- a distribution key has preferably been defined in advance in the smart contract.
- the invention thus enables a self-organizing infrastructure for billing services by counting the successful accesses to the application programming interfaces, without a higher-level central instance being necessary. All services / data / services offered can be accessed via the application programming interfaces of the network nodes in the entire network; it is therefore not only the access data that is provided via the router. Transparent and secure billing is therefore made possible by detailed billing with a time stamp of the services used, that is to say successful access to the application programming interfaces in the form of transactions.
- the invention also has the effect that the administrative effort for the provision of data and services is minimized.
- An image of the interaction of the services used with the user is provided without having to read the user data, i.e. it is end-to-end encrypted. All transactions including their usage details are also available for all network nodes.
- the transactions comprise at least one successful access by the user to at least one of the application programming points.
- a state channel that is configured to execute the smart contract and that is not part of the first distributed ledger system is particularly preferred. This enables transactions to be carried out more quickly.
- the metadata comprise an address and / or a hash of the smart contract. This enables clear identification and assignment.
- a cryptocurrency is provided to pay for the use of the services.
- tokens or altcoins are understood as cryptocurrency.
- tokens can be generated that act as complementary currencies in the distributed ledger system (e.g. Ethereum).
- the generated token or other cryptocurrency can be used in relation to the smart contract to buy the access key for the services offered and / or to buy metadata information about the services.
- These services can, for example, be all services of the last 24 hours of a weather service network.
- they are used as currency, especially for micropayments. This creates a "global" currency for these services.
- the router preferably has a wallet, i.e. your own wallet. With this he can receive cryptocurrency from the user as payment for the services used by the user.
- the user sends cryptocurrency to the router of the network by means of at least one transaction for the use of one or more services.
- the cryptocurrency is preferably sent using the state channel.
- the metadata comprise the exchange rate from the cryptocurrency used to fiat money, legal currency or another cryptocurrency.
- the first Distributed ledger system offers an exchange rate, ie the own token currency generated can be converted into ether, for example. This course is also included in the metadata.
- the exchange rate for a fiat currency can also be displayed or displayed instead.
- the course of the generated token to the token holder eg Ethereum
- trading analyzes can now be purchased on the second distributed ledger system, for example.
- the metadata can be stored on the second distributed ledger system using a Gossip protocol.
- This communication protocol enables robust message distribution in a distributed ledger system.
- the first consensus algorithm is preferably designed as a proof-of-work.
- PoW proof-of-work
- the participants have to solve complicated cryptographic tasks and thus validate transactions in order to generate new blocks.
- the proof-of-work on the Secure Hash Algorithm-256 the SHA-256
- the Bitcoin blockchain which costs a lot of time and electricity. This extends the block generation cycle and fewer transactions can be confirmed per unit of time.
- the second consensus algorithm is designed as a proof-of-stake.
- the cryptocurrency is not mined by solving complicated arithmetic tasks, but rather by holding and unlocking shares in a cryptocurrency in a user's wallet.
- the cryptographic calculations for proof-of-stake are much easier to perform for a computer: it only has to be proven that a certain proportion of all available cryptocurrencies are held in the respective currency.
- the decisive factor is therefore the "stake" of a user, ie the proportion of the total amount of cryptocurrency that he owns.
- the proof-of-stake uses a random algorithm. This means that the block generation cycle is considerably shorter than that of the consensus algorithm proof-of -Work.
- the second consensus algorithm is designed as a proof-of-activity.
- the proof-of-activity is a combination of proof-of-work and proof-of-stake.
- the second distributed ledger system is preferably designed as a directed acyclic graph (DAG).
- DAG directed acyclic graph
- DAG nodes do not represent nodes in the network or blocks of a distributed ledger system, but individual transactions.
- the functionality that is assumed by the distributed ledger system node in the distributed ledger system now has mutual transaction authentications.
- a distributed ledger system node must authenticate at least two other transactions in order to be able to make a transaction. If a transaction collects a minimum level of attestation in this way, it is considered verified and can be executed.
- the DAG can handle any number of transactions run simultaneously and becomes faster and faster with an increasing number of users.
- a distributed ledger system designed as a directed acyclic graph has the option of determining consensus without having to know the entire history; this makes it possible to "forget", ie the meta information can virtually disappear after a certain time.
- the second distributed ledger system is designed as a hash graph.
- each of the network nodes has at least one application programming interface and a router, the network node being designed to access the services of other network nodes by means of their application programming interface, and the router managing the application programming interfaces and the accesses to the application programming interface.
- the network nodes are connected to one another for example by a message router and can mutually access the application programming interfaces of the other network nodes in order to offer its services and / or to further process its services, for example sensor data.
- configuration interfaces and a transaction monitor
- a first distributed ledger system in particular a first blockchain, with interconnected first distributed ledger system nodes, the first distributed ledger system having a first consensus algorithm for generating blocks, and wherein the router with the first distributed -Ledger system is connected for communication, and wherein a smart contract for executing and managing transactions between the router and a user is provided by the router on the first distributed ledger system, and wherein metadata of the transactions generated by the transactions are logged by the transaction monitor,
- At least one successful access by the user to at least one of the application programming points is formed as at least one transaction.
- a state channel which is not part of the first distributed ledger system, is preferably configured to execute the smart contract. Furthermore, a cryptocurrency is provided, the user using at least one transaction Sends cryptocurrency to a router wallet for use of one or more services.
- the metadata can preferably comprise the exchange rate from the cryptocurrency used to fiat money, legal currency or another cryptocurrency.
- the metadata is stored on the second distributed ledger system using a Gossip protocol.
- the first consensus algorithm is preferably designed as a proof-of-work.
- the second consensus algorithm is also preferably designed as a proof-of-stake.
- the second distributed ledger system is designed as a directed acyclic graph (DAG) or hash graph.
- DAG directed acyclic graph
- Another object of the invention relates to a computer program comprising commands that cause the computer to execute the program to execute the method described above.
- Another object of the invention relates to a computer-readable storage medium on which the computer program as described above is stored.
- FIG. 1 schematically shows a block 100 according to the prior art.
- the transactions are not verified individually, but summarized in so-called blocks.
- Each blockchain node in the network listens for unconfirmed transactions, here transactions 1, 2, 3, 4 and tries to generate a block from these.
- Such blockchain nodes that participate in block creation are called miners.
- the transactions 1, 2, 3, 4 are then checked by the miner and stored in block 100.
- FIG. 2 schematically shows a blockchain 110 according to the prior art.
- the difficulty of generating a new block is also regulated via a parameter that is specified in the last block 100: the difficulty.
- a so-called nonce is required to form the block; a number in the block header that has no meaning, but can be varied so that the hash of the block header takes on a new value.
- 3 shows a first embodiment of the system according to the invention. This shows a network 1 with several network nodes which offer several services via application programming interfaces.
- the network node of network 1 is registered by a router with a smart contract on the first blockchain 2. The router is thus virtually the "owner" of the smart contract.
- the router counts the successful accesses to these application programming interfaces by a user.
- the router also points has its own wallet so that the user can communicate directly with the router to pay for the transactions, ie use the individual services, and thus the router is used to publish the available application programming interfaces, to control the application programming interface accesses and to control the application programming interfaces Traffic.
- the first blockchain 2 is based on Ethereum and the proof-of-work consensus algorithm.
- the application programming interfaces can be accessed at any time by the first blockchain 2, the services, however, for example the data provided are encrypted and an access key for using the services must be purchased by the user. Payment can be made using cryptocurrency, here for example ether or with those tokens that have been generated by network 1. Other users without the access key can call the application programming interfaces, but cannot use them because the services are encrypted.
- a state channel 3 is opened between the router and the user in order to carry out transactions, in particular micropayments, and to call up the various Enable services using the application programming interfaces.
- the state channel is closed, it is determined how much, for example, ether has been paid.
- the metadata 5 of the transactions which is stored in encrypted form on a second distributed ledger system by a transaction monitor present in the network and configured to log the metadata 5 of the individual transactions.
- the second distributed ledger system is designed here as a second blockchain 4 with a proof-of-stake consensus algorithm.
- the metadata 5 are stored on the second blockchain 4 using a gossip protocol 6, also called a gossip protocol.
- the second blockchain 4 offers fast storage of the metadata 5.
- the access key to this metadata 5 can be acquired using the smart contract.
- the metadata 5 can also be interesting for a second network 7, which here is also structured like the network 1, since the interaction model of a user with the network 1 is represented by the metadata 5.
- the second network 7 also has a first blockchain 8 as well as a state channel 9 and metadata 10. This metadata 10 will
- the service providers join together with the aid of a message router 11, which is designed here as a transaction monitor at the same time, to form a network 12.
- the service providers register their services offered as application programming interfaces using an asymmetrical key pair, for example RSA, ECC, etc., each through a router on the first distributed ledger system, here Ethereum 13.
- the router here manages the application programming interfaces, which a service provider for example, offers service provider A.
- Service provider A also uses services from service provider B within the network 12. This also enables the router to control application programming interfaces from, for example, service provider B.
- each service of a service provider is registered individually on Ethereum 13 by a smart contract.
- the message router 11 is able to log transactions between the service providers of the network 12, which take place in the form of successful accesses to the application programming interfaces, and thus serves as a transaction monitor.
- a user 14 who makes use of service provider A can register for his service using a smart contract and book it for a specific time or a number of accesses.
- the services for example data, are exchanged via the message router 11 within the network 12 and then forwarded to the user 14, for example by means of the state channel as transactions.
- the message router 11 serves here as a transaction monitor for logging the metadata of the transactions.
- This metadata generated by the transactions is then stored in a second distributed ledger system, here a hash graph 15, and is therefore transparent and quickly available.
- the hash graph 15 has a fast block generation cycle for storing the many off-chain transactions.
- the metadata of the transactions carried out by the various service providers are then evaluated, for example:
- the service providers of the network 12 can use a further smart contract, which is written, for example, in solidity, to define when the services of the network 12 used by the user 14 are billed using a cryptocurrency or a fiat currency, that is, when the user 14 services has to pay.
- the time for payment can be decided, for example, by a democratic election process in which all service providers have the same voting rights, for example, when a certain number of transactions have taken place or the trading price is currently favorable.
- the user 14 can then use the services of service provider A in the form of an app on his terminal, for example in his vehicle or, if they are in the form of data, for another service.
- a user 14 can also search for suitable contractual partners without needing a central instance. This means that data marketplaces are no longer required.
- FIG. 5 shows a first application of the invention.
- One or more service providers of a network 1 (FIG. 3) or a network 12 (FIG. 4) recognize the state of a driver in a vehicle 16, for example by being given access to the sensors 18 in the vehicle for evaluation. For example, this enables them to determine which secondary activities the driver is carrying out in the vehicle 16, for example whether the driver is currently looking at his smartphone.
- This information can be offered by the service providers as described above.
- a user 14 for example an insurance company, can buy this data and offer a corresponding insurance model thereon.
- the system according to the invention can take over both the data transfer and the sale of the data itself.
- a first service provider of a network 12 (FIG. 4) or a network 1 (FIG. 3) recognizes the position and time of a vehicle 16 on the road.
- a second service provider has data at the switching times of a traffic light 17 in the car.
- a third Service provider pays the first and second service provider to generate from this data, when the vehicle 16 is at a traffic light 17 and how long it will be there, and offers this generated data for sale.
- a fourth service provider buys this generated data in order to display advertisements in the vehicle via the secure channel during the idle time.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Signal Processing (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computing Systems (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Die Erfindung betrifft ein System mit einem Netzwerk mit mehreren Netzwerkknoten, welche jeweils mindestens einen Dienst über eine Anwendungsprogrammierschnittstelle bereitstellen, und einem Router, welcher zur Kommunikation mit den mehreren Netzwerkknoten und zum Verwalten der AnwendungsprogrammierSchnittstellen konfiguriert ist, und einem Transaktionsmonitor, mit einem ersten Distributed-Ledger-System, mit untereinander verbundenen ersten Distributed-Ledger-System-Knoten, wobei das erste Distributed-Ledger-System einen ersten Konsensalgorithmus zur Blockerzeugung aufweist, wobei der Router mit dem ersten Distributed-Ledger-System zur Kommunikation verbindbar ist, und wobei ein Smart Contract zur Verwaltung und Ausführung von Transaktionen zwischen dem Router und einem Nutzer auf dem ersten Distributed-Ledger-System durch den Router bereitgestellt ist, wobei durch die Transaktionen erzeugte Metadaten (5,10) der Transaktionen von dem Transaktionsmonitor protokolliert sind, mit einem zweiten Distributed-Ledger-System, mit untereinander verbundenen ersten Distributed-Ledger-System-Knoten, wobei das Distributed-Ledger-System zur Speicherung der protokollierten Metadaten mit dem Transaktionsmonitor verbindbar ist, und wobei das zweite Distributed-Ledger-System einen zweiten Konsensalgorithmus zur Blockerzeugung aufweist, und wobei durch den zweiten Konsensalgorithmus kürzeren Blockerzeugungszyklus als mit dem ersten Konsensalgorithmus bewerkstelligbar sind. Ferner betrifft die Erfindung ein Verfahren zum Betreiben eines Systems, Computerprogramm, speicherprogrammierbares Computerprogramm
Description
Beschreibung
System, Verfahren zum Betreiben eines Systems, Computerprogramm und speicherprogrammierbares Computerprogramm
Die Erfindung betrifft ein System mit Distribu- ted-Ledger-Systemen, insbesondere Blockchains. Dabei wird nachfolgend unter Blockchain das Blockchain-System verstanden. Eine Blockchain, englisch für Blockkette ist eine kontinuierlich erweiterbare Liste von Datensätzen, genannt „Blöcke". Diese sind mittels kryptographischer Verfahren miteinander verkettet. Jeder Block enthält dabei im Header typischerweise einen kryptographisch sicheren Hash des vorhergehenden Blocks und einen Zeitstempel. Ferner enthält der Block Transaktionsdaten.
Im Rahmen der Anmeldung wurden englische Informatikbegriffe zum besseren Verständnis nicht ins Deutsche übersetzt, wie dies bei Fachliteratur ebenfalls der Fall ist, da diese Informatikbe griffe für den Fachmann im Wesentlichen im englischen besser verständlich sind als eine Übersetzung ins Deutsche. So würde die Übersetzung feststehender englischer Begriffe aus der Informatik bei dem Fachmann lediglich zu Unverständnis führen.
Verbrauchsinformation wie z.B. Gas-/Stromverbrauch, Datenvo lumen, Zugriffe auf Programmierschnittstellen von Cloud Diensten etc. werden in der Regel auf einem zentralen Datenspeicher verwaltet. Fallen jedoch viele Daten in geringer Zeit an, ist der Durchsatz zur Speicherung der Daten entscheidend. Die Ab rechnungen und Vertragsbedingungen zwischen den Handelspartnern müssen von einer zentralen vertrauenswürdigen Koordinations stelle verwaltet und ausgehandelt werden.
Zum einen muss der Verbrauch von unterschiedlichen Gütern zwischen den Handelspartnern protokolliert werden. Zum anderen
müssen die Vertragsbedingungen transparent und gerecht aus gehandelt werden. Diese Aufgabe wird mit jedem Handelspartner in einem Netzwerk komplexer, da jeder Teilnehmer des Netzwerks mit jedem Partner einen eigenen Vertrag aushandelt.
So können beispielsweise die Insassen eines Fahrzeuges für sie zugeschnittene personalisierte Dienste in Anspruch nehmen. Diese Dienste werden von Entwicklern oder Service Center Mitarbeitern erstellt und beispielsweise vom Anbieter des Fahrzeugs be- reitgestellt . Dem Fahrer oder den Insassen in einem Fahrzeug werden diese personalisierten Dienste in Form einer Applikation dargestellt. Alle Teilnehmer d.h., Dienstanbieter als auch Service-Nutzer, wie einem Fahrer, bieten Daten an. Dabei muss der Datenverkehr protokolliert und für jeden transparent dargestellt und abgerechnet werden.
Der Erfindung liegt die Aufgabe zugrunde, eine verbesserte und transparente Abrechnung von Diensten, welche in einem Rech nerverbund oder ein Rechnernetzwerk von einzelnen Rechner angeboten werden, zur Verfügung zu stellen.
Diese Aufgabe wird durch ein System mit den Merkmalen des Anspruchs 1, ein Verfahren mit den Merkmalen des Anspruchs 13 als auch ein Computerprogramm mit den Merkmalen des Anspruchs 21 sowie ein computerlesbares Speichermedium mit den Merkmalen des Anspruchs 22 gelöst.
In den Unteransprüchen sind weitere vorteilhafte Maßnahmen aufgelistet, die beliebig miteinander kombiniert werden können, um weitere Vorteile zu erzielen.
Die Aufgabe wird gelöst durch die Angabe eines Systems mit einem Netzwerk mit mehreren Netzwerkknoten, welche jeweils mindestens einen Dienst über eine Anwendungsprogrammier-
Schnittstelle bereitstellen, und einem Router welcher zur Kommunikation mit den mehreren Netzwerkknoten und zum Verwalten der Anwendungsprogrammierschnittstellen konfiguriert ist, und einem Transaktionsmonitor,
mit einem ersten Distributed-Ledger-System, insbesondere einer ersten Blockchain, mit untereinander verbundenen ersten Dis- tributed-Ledger-System-Knoten, wobei das erste Distribu ted-Ledger-System einen ersten Konsensalgorithmus zur Blo ckerzeugung aufweist, wobei der Router mit dem ersten Dis tributed-Ledger-System zur Kommunikation verbindbar ist, und wobei ein Smart Contract zur Ausführung und Verwaltung von Transaktionen zwischen dem Router und einem Nutzer auf dem ersten Distributed-Ledger-System durch den Router bereitgestellt ist, und wobei durch die Transaktionen erzeugte Metadaten der Transaktionen von dem Transaktionsmonitor protokolliert sind, mit einem zweiten Distributed-Ledger-System, insbesondere einer zweiten Blockchain, mit untereinander verbundenen zweiten Distributed-Ledger-System-Knoten, wobei das zweite Distribu ted-Ledger-System zur Speicherung der protokollierten Metadaten mit dem Transaktionsmonitor verbindbar ist, und wobei das zweite Distributed-Ledger-System einen zweiten Konsensalgorithmus zur Blockerzeugung aufweist, und wobei durch den zweiten Kon sensalgorithmus ein kürzerer Blockerzeugungszyklus als mit dem ersten Konsensalgorithmus bewerkstelligbar ist.
Hierbei ist als Dienst beispielsweise das Bereitstellen oder Aufbereiten von Daten oder andere Services zu verstehen.
Das Netzwerk kann insbesondere als ein peer-to-peer Netzwerk ausgestaltet sein. Auch kann das Netzwerk als eine private Blockchain ausgestaltet sein, in welcher die Teilnehmer, das heißt die einzelnen Netzwerkknoten bekannt sind. Das Netzwerk kann auch als ein Dienst- oder Servicecluster ausgestaltet sein. In dem Netzwerk werden die angebotenen Dienste der einzelnen
Netzwerkknoten durch Anwendungsprogrammierschnittstellen be- reitgestellt . Der Zugriff auf die Anwendungsprogrammier schnittstellen wird mithilfe eines Zugriffsschlüssels gewährt. Dieser Zugriffsschlüssel ist bevorzugt zeitlich oder quantitativ beschränkt .
Der Router verwaltet die erfolgreichen Zugriffe auf die An wendungsprogrammierschnittstelle und damit die Dienste der einzelnen Netzwerkknoten, das heißt, er ermöglicht es den Netzwerkknoten ihre Anwendungsprogrammierschnittstellen auf einem ersten Distributed-Ledger-System zu registrieren und koordiniert den Zugriff. Der Router erfüllt neben der Rout funktion zwischen beispielsweise dem Nutzer und den Netzwer knoten daher die Verwaltung der Anwendungsprogrammier schnittstellen aller Netzwerknoten und die Registrierung der Anwendungsprogrammierschnittstellen durch den Smart Contract auf dem ersten Distributed-Ledger-System und zählt die er folgreichen Zugriffe auf diese Anwendungsprogrammierschnitt stellen. Der Router ist somit quasi der „Besitzer" des Smart Contracts. Hat der Router zudem ein eigenes Wallet, kann der Nutzer direkt zur Bezahlung der Transaktionen mit dem Router kommunizieren. Somit dient der Router zur Veröffentlichung der verfügbaren Anwendungsprogrammierschnittstellen, zur Kontrolle der Anwendungsprogrammierschnittstellen-Zugänge und zur Steuerung des Anwendungsprogrammierschnittstellen-Verkehrs .
Jeder der Netzwerkknoten besitzt zumindest einen privaten Schlüssel als auch ein eigenes Wallet zum Ausführen der Transaktionen, das heißt zum Bereitstellen der Dienste und zum Empfangen von Kryptowährung über das erste Distribu ted-Ledger-System.
Jeder Dienst, wird zunächst von dem erstellenden Netzwerkknoten mit dem privaten Schlüssel aus der Wallet signiert.
Ein Wallet ist dabei eine Datenstruktur, in der der private und ein öffentlicher Schlüssel sicher gespeichert werden. Mit dem öffentlichen Schlüssel, auch Public Key genannt, wird die eindeutige Kennung, beispielsweise eine Adresse, des Netz werkknotens berechnet und mit dem privaten Schlüssel signiert. Ein öffentlicher Schlüssel ist eine öffentliche Adresse, auch Empfangsadresse genannt, an die man beispielsweise die Kryp- towährung sendet.
Ein Distributed-Ledger-System, welches auch als dezentrales Datenbanksystem bezeichnet werden kann, sind vernetzte Computer, die zu einem Konsensus über die Reihenfolge von bestimmten Transaktionen kommen und darüber, dass diese Transaktionen Daten aktualisieren. Eine Blockchain ist dabei die bekannteste Va riante eines Distributed-Ledger-Systems . Das Distribu ted-Ledger-System ist ein elektronisches, öffentliches Hauptbuch das sogenannte Ledger, das als computerbasiertes, dezentralisiertes, verteiltes System aus Datenblöcken reali siert wird. Das Distributed-Ledger-System besteht aus einer Reihe von Datenblöcken, in denen jeweils eine oder mehrere Transaktionen zusammengefasst und mit einer Prüfsumme versehen sind. Transaktionen sind Daten, die in der Zeitfolge proto kolliert, nachvollziehbar, unveränderlich und ohne zentrale Instanz abgebildet sind. Jede Transaktion enthält einen öf fentlichen Schlüssel des Knotens, der die Transaktion erstellt und signiert hat.
Jeder Block enthält dabei typischerweise einen kryptographisch sicheren Hash des Vorgängerblocks, einen Zeitstempel und Transaktionsdaten.
Distributed-Ledger-Systeme werden vor allem in peer-to-peer - (p2p) -Netzwerken und anderen Netzwerken verwendet. Ein
p2p-Netzwerk ist eine verteile Anwendungsarchitektur, die Tasks oder Workloads zwischen den „Peers" verteilt. Gleichberechtigte Teilnehmer des Distributed-Ledger-Systems sind sogenannte Distributed-Ledger-System-Knoten . Jeder, der beispielsweise an einer Blockchain "teilnimmt", wird als „Blockchain-Node" oder „Blockchain-Knoten" bezeichnet. Jeder Blockchain-Knoten erhält immer eine aktuelle Kopie der Blockchain, die fortlaufend aktualisiert wird. Jeder Blockchain-Knoten, welcher zu einer „Blockchain" gehört, hat daher für gewöhnlich die gleichen Rechte, die Blockchain zu speichern und neue Blöcke hinzuzufügen, d.h. zu validieren.
Neue Blöcke des Distributed-Ledger-Systems werden in einem rechenintensiven Prozess, mit einem sogenannten Konsensver fahren oder Konsensalgorithmus erzeugt. Diese neu erzeugten Blöcke werden anschließend dem Distributed-Ledger-System hinzugefügt und über das Netzwerk an alle Distribu- ted-Ledger-System-Knoten verbreitet. Ein Konsensalgorithmus stellt also sicher, dass der nächste Block in dem Distribu ted-Ledger-System immer der einzig Wahre ist und hält somit das Distributed-Ledger-System als dezentrale, verteilte Datenbank zusammen .
Der Konsensalgorithmus bestimmt also, welcher Knoten einen neuen Block validieren und an das System anhängen darf. Die Kon sensalgorithmen beruhen dabei vor allem auf kryptografischen Algorithmen. Für die Herstellung des Konsenses gibt es ver schiedene Algorithmen.
Die bekannte Bitcoin-Blockchain basiert derzeit auf den Kon sensalgorithmus Proof-of-Work . Hierbei wird der Schwierig keitsgrad des für die Erzeugung eines gültigen Blocks zu lösenden kryptographischen Problems angepasst. Um dies zu erreichen, wird der Schwierigkeitsgrad des zu lösenden kryptographischen
Problems beim Proof-of-Work entsprechend gewählt. Die Lösung dauert bei dem Konsensalgorithmus Proof-of-Work im statischen Mittel zurzeit etwa 10 Minuten.
Der Distributed-Ledger-System-Knoten des Distribu- ted-Ledger-Systems überprüft vor dem Anhängen eines neuen Blocks, ob die Transaktionen von Semantik und Syntax richtig sind und ob die digitalen Signaturen des Initiators, hier des Dienstanbieters der Transaktionen mit der Adresse übereinstimmt. Dann wird ein neuer Block generiert, bei welchem der erzeugte Hashwert mit dem Hashwert des Vorgängerblocks verbunden wird. Der aktuelle Block wird an alle Knoten verteilt. Jeder Knoten hat dadurch jederzeit eine aktuelle Kopie des Distribu- ted-Ledger-Systems . Da alle Blöcke basierend auf bestehenden Blöcken gebildet werden, indem der Hashwert des Vorgängerblockes in einen neuen Block eingefügt wird, bildet sich eine Kette aus. Die Transaktionen sind somit vor Manipulation geschützt, da die Kette bis zu dem initialen Block, auch Genesisblock genannt, durch die Verkettung der Blöcke nachvollzogen werden kann. Durch die aneinandergeketteten Blöcke wird eine dauerhafte und un- veränderbare Aufzeichnung aller Transaktionen geschaffen. Da die Transaktionen über das Distributed-Ledger-System verfügbar sind, kann nachvollzogen werden, ab welchem Block in der Kette beispielsweise ein Inhalt einer Transaktion nicht mehr mit der vorherigen Version übereinstimmt. Die Transaktionen sind also manipulationsgeschützt hinterlegt. Ein Abändern einer Trans aktion in einem Block, der bereits zu einem früheren Zeitpunkt im Distributed-Ledger-System gebildet wurde, würde nachvoll zogen werden können, wenn eine PrüfSummenbildung über die bestehenden Blöcke nachvollzogen wird.
Das Durchführen eines Konsensalgorithmus bezeichnet man im Kontext von einer Blockchain als „Mining". Diese speziellen Knoten welche das Mining durchführen, werden Miner genannt. Die
Miner versuchen dabei, durch milliardenfache Ausführung von Rechenoperationen, ein Ergebnis mit bestimmten Eigenschaften zu finden .
Smart Contracts (Smart-Verträge) sind programmierbare Verträge, welche durch einen ausführbaren Programmcode definiert und nach zuvor festgelegten Bedingungen automatisch auf dem Distribu- ted-Ledger-System ausgeführt werden. Smart Contracts stellen eine Kontroll- oder Geschäftsregel innerhalb eines technischen Protokolls dar. Smart Contracts sind Computerprotokolle, die Verträge abbilden oder überprüfen.
Die in einem Smart Contract vereinbarten Bedingungen werden durch das Distributed-Ledger-System gesichert. Das Umsetzen der Vertragsbedingungen wird über dazugehörige durchgeführte Transaktionen kontrolliert. In einem programmierten Smart Contract vorgesehene Folgeaktionen können je nach erfolgter Transaktion durchgeführt werden. Smart Contracts können mithilfe von Statechannels durchgeführt werden.
Ein Statechannel ist im Wesentlichen ein Zwei-Wege-Kanal zwischen zwei Nutzern, oder hier Netzwerkknoten und Nutzer, die Transaktionen miteinander abschließen wollen. Jeder Nutzer unterzeichnet diese Transaktionen mit seinem privaten Schlüssel . Diese Transaktionen finden vollständig außerhalb des Distri- buted-Ledger-Systems (off-chain) und ausschließlich zwischen den Nutzern statt, was bedeutet, dass sie im Vergleich zu On-Chain-Transaktionen sehr schnell auszuführen sind. State channels können zu einem vorgegebenen Punkt geschlossen werden, beispielsweise wenn eine vorbestimmte Menge der Transaktionen ausgeführt worden ist oder nach einer gewissen Zeitdauer. Sobald ein Statechannel geschlossen wird, kann das Endergebnis in dem Distributed-Ledger-System hochgeladen werden, damit es offi ziell wird.
Metadaten sind strukturierte Daten, die Objekte, wie Daten, Dokumente, Personen usw. beschreiben. Sie bewirken, dass den Beschreibungen unterschiedlicher Objekte eine einheitliche Struktur zugrunde liegt. Metadaten beschreiben also die ei gentlichen Daten. Sie können in Objekte eingebettet sein oder in einem eigenen Datensatz zur Verfügung gestellt werden.
Transaktionen sind zwischen einzelnen Teilnehmern off-chain durch die Statechannels möglich. Transaktionen sind hier hierbei die Nutzung der verschiedenen Dienste oder beispielsweise die Bezahlung dieser Nutzung durch einen Nutzer, hier beispielsweise einen Vertragspartner. Das heißt, es können die einzelnen Transaktionen akkumuliert werden und das Endergebnis dann zu einem späteren Zeitpunkt auf beispielsweise dem Distribu- ted-Ledger-System abgelegt werden. Über den Smart Contract wird hierfür zunächst ein Statechannel zwischen zwei Nutzern auf gebaut, um den ZugriffSchlüssel auszutauschen und den Zah lungsverkehr abzuwickeln. So wird beispielsweise der Zu griffSchlüssel zwischen den Nutzern erst ausgetauscht, wenn der erste Nutzer Ether oder eine andere Kryptowährung an den zweiten Nutzer gesendet hat. Bisher wurden Smart Contracts mit jedem Netzwerkknoten individuell ausgehandelt. Erfindungsgemäß wurde erkannt, dass diese Aufgabe sehr zeitintensiv ist und eine steigende Komplexität mit sich führt. Ferner wurde erkannt, dass insbesondere in einem solchen Netzwerk die Informationen über Transaktionen bei Anwendung eines Statechannels verloren gehen. Dies führt insbesondere bei der Abrechnung zu Problemen.
Mit der Erfindung wird ein Transaktionsmonitor beispielsweise bei Schließung des Statechannels oder bei Beenden des Smart Contracts dazu veranlasst, die über die einzelnen Transaktionen gesammelten Metadaten auf einem zweiten Distribu- ted-Ledger-System, welches in der Blockerzeugung durch einen
zweiten Konsensalgorithmus schneller ist, abzulegen. Da viele Transaktionen auf dem ersten Distributed-Ledger-System bei spielsweise mittels eines Statechannels entstehen, ist ein zweites schnelleres Distributed-Ledger-System mit höherer Transaktionsrate als das erste Distributed-Ledger-System, notwendig. Als Transaktionsmonitor kann beispielsweise auch der Router verwendet werden.
Die von dem Transaktionsmonitor gesammelten Metadaten der getätigten einzelnen Transaktionen werden bevorzugt ver schlüsselt auf dem zweiten, schnellen Distributed-Ledger-System abgelegt. Somit werden die Metadaten der Transaktionen, das heißt das Interaktionsmodell zwischen zwei Nutzern auf dem zweiten schnelleren Distributed-Ledger-System gespeichert. Dadurch ist es möglich, jedem, der Interesse an diesen Metadaten hat, Zugriff auf die Transaktionshistorie zu gewährleisten. Bevorzugt wird der Schlüssel für die Nutzung der Metadaten in einem Smart Contract auf dem zweiten Distributed-Ledger-System hinterlegt.
Durch die Speicherung der Metadaten auf dem zweiten, schnellen Distributed-Ledger-System kann das Auffinden einzelner Transaktionen erleichtert werden. Auch können ausgewählte Metadaten auf dem zweiten Distributed-Ledger-System öffentlich zugänglich gemacht werden, während andere Metadaten nur einem beschränkten Teilnehmerkreis zugänglich gemacht werden.
Die Erfindung bewirkt, dass viele Transaktionen des Netzwerkes mit den verschiedenen Diensten akkumuliert und zu einem be stimmten Zeitpunkt auf dem zweiten Distributed-Ledger-System abgerechnet werden. Die verschiedenen Dienste können bei spielsweise das Bereitstellen von Daten oder personalisierten Diensten umfassen, welche von den einzelnen Netzwerkknoten beispielsweise für die Insassen eines Fahrzeugs aufbereitet werden. Der Zeitpunkt der Abrechnung kann demokratisch zwischen
den Netzwerkknoten, welche an den Transaktionen beteiligt waren, entschieden werden. Dies kann beispielsweise durch eine vir tuelle Wahl erfolgen. Der Gewinn wird vorteilhafterweise auf Grundlage der Transaktionen, welche durch die Metadaten auf dem zweiten Distributed-Ledger-System gespeichert und dadurch bekannt sind, unter den beteiligten Netzwerkknoten gewichtet und verteilt. Dabei ist bevorzugt ein Verteilungsschlüssel in dem Smart Contract vorab definiert worden. Die Erfindung ermöglicht somit eine sich selbst organisierende Infrastruktur zum Ab rechnen von Dienstleistungen durch das Zählen der erfolgreichen Zugriffe auf die Anwendungsprogrammierschnittstellen, ohne dass eine übergeordnete zentrale Instanz notwendig ist. Dabei kann auf alle angebotenen Services/Daten/Dienstleistungen über die Anwendungsprogrammierschnittstellen der Netzwerkknoten im gesamten Netzwerk zugegriffen werden; es werden daher nicht nur lediglich die Zugangsdaten über den Router bereitgestellt. Es wird daher eine transparente und sichere Abrechnung durch eine detaillierte Abrechnung mit Zeitstempel der inanspruchgenom menen Dienste, das heißt der erfolgreichen Zugriffe auf die Anwendungsprogrammierschnittstellen in Form von Transaktionen, ermöglicht .
Die Erfindung bewirkt weiterhin, dass der Verwaltungsaufwand zur Bereitstellung von Daten und Dienstleistungen minimiert wird. Es wird ein Abbild über die Interaktion der verwendeten Dienste mit dem Nutzer bereitgestellt, ohne die Nutzdaten lesen zu müssen, d.h. es ist end-to-end (Ende-zu-Ende) verschlüsselt. Auch sind alle Transaktionen inklusive deren Nutzungsdetails für alle Netzwerkknoten verfügbar.
In einer bevorzugten Ausgestaltung umfassen die Transaktionen zumindest einen erfolgreichen Zugriff des Nutzers auf zumindest eine der Anwendungsprogrammierstellen.
Besonders bevorzugt ist ein Statechannel , welcher zur Ausführung des Smart Contracts konfiguriert ist, und welcher nicht Teil des ersten Distributed-Ledger-Systems ist, vorgesehen. Dadurch können Transaktionen schneller durchgeführt werden.
In einer bevorzugten Ausgestaltung umfassen die Metadaten eine Adresse und/oder einen Hash des Smart Contracts. Dadurch ist eine eindeutige Identifizierung und Zuordnung möglich.
In einer weiteren bevorzugten Ausgestaltung ist eine Kryp- towährung zur Bezahlung der Benutzung der Dienste vorgesehen. Dabei wird hier als Kryptowährung Token oder Altcoins verstanden. Mit Hilfe des Smart Contracts können Tokens generiert werden, welche als Komplementärwährung im Distributed-Ledger-System (z.B. Ethereum) fungieren. Der generierte Token oder eine andere Kryprowährung kann in Bezug auf den Smart Contract verwendet werden, um den ZugriffSchlüssel für die angebotenen Dienste zu kaufen und/oder Metadateninformation über die Dienste einzu kaufen. Diese Dienste können beispielsweise alle Dienste der letzten 24h eines WetterServiceNetzwerkes sein. Des Weiteren werden sie als Währung, insbesondere für Mikropayments genutzt. Damit entsteht eine „globale" Währung für diese Dienste.
Bevorzugt weist der Router ein Wallet, d.h. ein eigenes Wallet, auf. Mit diesem kann er Kryptowährung vom Nutzer als Bezahlung der vom Nutzer genutzten Dienste empfangen. In weiterer be vorzugter Ausgestaltung sendet der Nutzer mittels zumindest einer Transaktion Kryptowährung für die Nutzung eines oder mehrerer Dienste an den Router des Netzwerkes. Bevorzugt erfolgt die Übersendung der Kryptowährung mittels des Statechannels .
In bevorzugter Ausgestaltung umfassen die Metadaten den Wechselkurs von der verwendeten Kryptowährung zu Fiatgeld, gesetzlichen Währung oder einer anderen Kryptowährung. Das erste
Distributed-Ledger-System, insbesondere die erste Blockchain bietet einen Wechselkurs an, d.h. die eigene generierte To kenwährung kann in z.B. Ether umgewandelt werden. Dieser Kurs wird auch in den Metadaten mitaufgenommen . Ebenso kann der Wechselkurs zu einer Fiatwährung mitangezeigt oder stattdessen angezeigt werden. Es ist also der Kurs des generierten Tokens zum Tokenträger (z.B. Ethereum) bekannt. Da die Metadaten auf dem zweiten Distributed-Ledger-System zur Verfügung gestellt werden, können mit den Metadaten nun beispielsweise Tra- dinganalysen auf dem zweiten Distributed-Ledger-System ein gekauft werden.
In einer weiteren bevorzugten Ausgestaltung sind die Metadaten mittels eines Gossip Protokolls auf dem zweiten Distribu ted-Ledger-System speicherbar. Durch dieses Kommunikations protokoll ist eine robuste Nachrichtenverteilung in einem Distributed-Ledger-System möglich .
Bevorzugt ist der erste Konsensalgorithmus als Proof-of-Work ausgestaltet. Bei dem Konsensalgorithmus Proof-of-Work (PoW) müssen die Teilnehmer komplizierte kryptografische Aufgabe lösen und damit Transaktionen validieren, um neue Blöcke zu generieren. Dabei kommt beispielsweise bei der Bitcoin-Blockchain der Proof-of-Work auf dem Secure Hash Algorithm-256, der SHA-256, zum Einsatz, welcher sehr viel Zeit und Elektrizität kostet. Dadurch verlängert sich der Blockerzeugungszyklus und es können weniger Transaktionen pro Zeiteinheit bestätigt werden.
In einer weiteren bevorzugten Ausgestaltung ist der zweite Konsensalgorithmus als Proof-of-Stake ausgestaltet. Beim Proof-of-Stake wird die Kryptowährung nicht durch das Lösen komplizierter Rechenaufgaben geschürft, sondern dadurch, dass Anteile an einer Kryptowährung in der Wallet eines Nutzers vorgehalten und entsperrt werden. Im Gegensatz zu Proof-of-Work
sind die kryptographischen Berechnungen für Proof-of-Stake für einen Computer wesentlich leichter durchzuführen: es muss lediglich bewiesen werden, dass ein gewisser Anteil aller verfügbaren Kryptowährung der jeweiligen Währung gehalten wird. Ausschlaggebend ist daher der „Stake" eines Nutzers, also der Anteil an der insgesamten Menge an Kryptowährung, die er besitzt. Zudem wird beim Proof-of-Stake ein Zufallsalgorithmus einge setzt. Dadurch ist der Blockerzeugungszyklus wesentlich kürzer als bei dem Konsensalgorithmus Proof-of-Work .
In einer weiteren bevorzugten Ausgestaltung ist der zweite Konsensalgorithmus als Proof-of-Activity ausgestaltet. Der Proof-of-Activity ist eine Kombination von Proof-of-Work und Proof-of-Stake.
Auch sind anderer Konsensalgorithmen als zweite Konsensalgo rithmus denkbar, beispielsweise der Ripple Protocol Consensus Algorithmus .
Bevorzugt ist das zweite Distributed-Ledger-System als ein gerichteter azyklischer Graph (directed acyclic graph - DAG) ausgebildet. Gerichtete azyklische Graphen sind eine Verall gemeinerung der Kettenstruktur einer Blockchain, also ist jede Blockchain ein sehr einfacher, kettenförmiger DAG. Knoten des DAG stellen nicht Knoten im Netzwerk oder Blöcke eines Distribu ted-Ledger-System dar, sondern einzelne Transaktionen. Die Funktionalität, die bei dem Distributed-Ledger-System von dem Distributed-Ledger-System-Knoten übernommen wird, kommt nun gegenseitigen Transaktionsbeglaubigungen zu. Dabei muss ein Distributed-Ledger-System-Knoten, um eine Transaktion vornehmen zu können, mindestens zwei andere Transaktionen beglaubigen. Sammelt eine Transaktion auf diese Weise ein Mindestmaß an Beglaubigungen, gilt sie als verifiziert und kann ausgeführt werden. Der DAG kann eine beliebige Anzahl von Transaktionen
gleichzeitig ausführen und wird mit einer steigenden Anzahl von Nutzern immer schneller. Ein als gerichteter azyklischer Graph ausgestaltetes Distributed-Ledger-System hat im Gegensatz zur Blockchain die Möglichkeit die Konsens zu ermitteln ohne die gesamte Historie kennen zu müssen; damit ist es möglich „zu vergessen" d.h. die Metainformation können nach einer gewissen Zeit quasi verschwinden.
Alternativ ist das zweite Distributed-Ledger-System als ein Hashgraph ausgebildet.
In einer weiteren Ausgestaltung weist jeder der Netzwerkknoten zumindest eine Anwendungsprogrammierschnittstelle und einen Router auf, wobei der Netzwerkknoten zum Zugriff auf die Dienste anderer Netzwerkknoten mittels deren Anwendungsprogrammier schnittstelle ausgebildet ist, und wobei der Router die An wendungsprogrammierschnittstellen und die Zugriffe auf die Anwendungsprogrammierschnittstelle verwaltet. Die Netzwerk knoten sind in einem solchen Fall beispielsweise durch einen Nachrichtenrouter miteinander verbunden und können gegenseitig auf die Anwendungsprogrammierschnittstellen der anderen Netzwerkknoten greifen, um dessen Dienste mitanzubieten und/oder dessen Dienste, beispielsweise Sensordaten, weiterzuverar beiten .
Ferner wird die Aufgabe gelöst durch die Angabe eines Verfahrens zum Betreiben eines Systems mit den Schritten:
- Bereitstellen eines Netzwerks mit mehreren Netzwerkknoten, welcher jeweils mindestens einen Dienst über eine An wendungsprogrammierschnittstelle bereitstellt, und eines Routers, welcher zur Kommunikation mit den mehreren Netzwerkknoten und zum Verwalten der Anwendungsprogram-
mierschnittstellen konfiguriert wird, und eines Trans aktionsmonitors,
- Bereitstellen eines ersten Distributed-Ledger-Systems , insbesondere einer ersten Blockchain, mit untereinander verbundenen ersten Distributed-Ledger-System-Knoten, wobei das erste Distributed-Ledger-System einen ersten Konsensalgorithmus zur Blockerzeugung aufweist, und wobei der Router mit dem ersten Distributed-Ledger-System zur Kommunikation verbunden wird, und wobei ein Smart Contract zur Ausführung und Verwaltung von Transaktionen zwischen dem Router und einem Nutzer auf dem ersten Distribu ted-Ledger-System durch den Router bereitgestellt wird, und wobei durch die Transaktionen erzeugte Metadaten der Transaktionen von dem Transaktionsmonitor protokolliert werden,
- Bereitstellen eines zweiten Distributed-Ledger-Systems, insbesondere einer zweiten Blockchain, mit untereinander verbundenen zweiten Distributed-Ledger-System-Knoten, wobei das zweite Distributed-Ledger-System mit dem Transaktionsmonitor zur Speicherung der protokollierten Metadaten verbunden wird, und wobei das zweite Distri buted-Ledger-System einen zweiten Konsensalgorithmus zur Blockerzeugung aufweist, und wobei durch den zweiten Konsensalgorithmus ein kürzerer Blockerzeugungszyklus als mit dem ersten Konsensalgorithmus bewerkstelligt wird.
In bevorzugter Ausgestaltung wird als zumindest eine Transaktion zumindest ein erfolgreicher Zugriff des Nutzers auf zumindest eine der Anwendungsprogrammierstellen ausgebildet.
Bevorzugt wird ein Statechannel , welcher nicht Teil des ersten Distributed-Ledger-Systems ist, zur Ausführung des Smart Contracts konfiguriert. Weiterhin ist eine Kryptowährung vorgesehen, wobei der Nutzer mittels zumindest einer Transaktion
Kryptowährung für die Nutzung eines oder mehrerer Dienste an ein Wallet des Routers sendet.
Ferner können die Metadaten den Wechselkurs von der verwendeten Kryptowährung zu Fiatgeld, gesetzlichen Währung oder einer anderen Kryptowährung bevorzugt umfassen.
In einer weiteren bevorzugten Ausgestaltung werden die Metadaten mittels eines Gossip Protokolls auf dem zweiten Distribu- ted-Ledger-System gespeichert.
Bevorzugt wird der erste Konsensalgorithmus als Proof-of-Work ausgestaltet. Weiterhin bevorzugt wird der zweite Konsensal gorithmus als Proof-of-Stake ausgestaltet.
In weiterer bevorzugter Ausgestaltung wird das zweite Dis- tributed-Ledger-System als ein gerichteter azyklischer Graph (directed acyclic graph - DAG) oder Hashgraph ausgebildet.
Die Vorteile des Verfahrens entsprechen im Wesentlichen den Vorteilen des Systems.
Ein weiterer Gegenstand der Erfindung betrifft ein Computer programm umfassend Befehle, die bei der Ausführung des Programms durch den Computer diesen veranlassen, das wie oben beschriebene Verfahren auszuführen.
Ein weiterer Gegenstand der Erfindung betrifft ein computer lesbares Speichermedium, auf dem das wie oben beschriebene Computerprogramm gespeichert wird.
Weitere Merkmale, Eigenschaften und Vorteile der vorliegenden Erfindung ergeben sich aus der nachfolgenden Beschreibung unter
Bezugnahme auf die beiliegenden Figuren. Darin zeigen sche matisch :
FIG 1: einen ersten Block nach dem Stand der Technik,
FIG 2: eine Blockchain nach dem Stand der Technik,
FIG 3: ein erstes Ausführungsbeispiel des Systems der Erfindung,
FIG 4 : ein zweites Ausführungsbeispiel des Systems der Erfindung,
FIG 5: eine erste Anwendung der Erfindung,
FIG 6: eine zweite Anwendung der Erfindung.
FIG 1 zeigt schematisch einen Block 100 gemäß dem Stand der Technik. Die Transaktionen werden nicht einzeln verifiziert, sondern in sogenannten Blöcke zusammengefasst. Jeder Block- chain-Knoten lauscht also im Netzwerk nach unbestätigten Transaktionen, hier die Transaktionen 1,2, 3, 4 und versucht, aus diesen einen Block zu generieren. Solche Blockchain-Knoten, die sich bei der Blockerzeugung beteiligen, werden Miner genannt . Die Transaktionen 1,2, 3, 4 werden dann von dem Minern geprüft und in dem Block 100 gespeichert.
FIG 2 zeigt schematisch eine Blockchain 110 gemäß dem Stand der Technik. Die Schwierigkeit einen neuen Block zu generieren, wird neben dem ausgewählten Konsensalgorithmus auch über einen Parameter geregelt, der im jeweils letzten Block 100 vorgegeben ist: die difficulty (Schwierigkeit) . Je höher die Schwierigkeit ist, desto mehr Rechenleistung ist nötig. Ferner wird zum Bilden des Blockes noch eine sogenannte Nonce benötigt; eine Zahl im Block-Header, die keinerlei Bedeutung hat, aber variiert werden kann, damit der Hash des Block-Headers einen neuen Wert annimmt.
FIG 3 zeigt eine erste Ausgestaltung des erfindungsgemäßen Systems. Dieses zeigt ein Netzwerk 1 mit mehreren Netzwerkknoten, welche mehrere Dienste über Anwendungsprogrammierschnittstellen anbieten. Die Netzwerkknoten des Netzwerks 1 registriert sich durch einen Router mit einem Smart Contract auf der ersten Blockchain 2. Der Router ist somit quasi der „Besitzer" des Smart Contracts. Der Router zählt die erfolgreichen Zugriffe auf diese Anwendungsprogrammierschnittstellen durch einen Nutzer. Der Router weist zudem ein eigenes Wallet auf, wodurch der Nutzer direkt zur Bezahlung der Transaktionen, das heißt Benutzung der einzelnen Dienste mit dem Router kommunizieren. Somit dient der Router zur Veröffentlichung der verfügbaren Anwendungspro grammierschnittstellen, zur Kontrolle der Anwendungsprogram- mierschnittstellen-Zugänge und zur Steuerung des Anwendungs programmierschnittstellen-Verkehrs .
Die erste Blockchain 2 basiert hier in diesem Beispiel auf Ethereum und dem Proof-of-Work Konsensalgorithmus. Auf die Anwendungsprogrammierschnittstellen kann von der ersten Blockchain 2 jederzeit zugegriffen werden, die Dienste, bei spielsweise die bereitgestellten Daten sind jedoch verschlüsselt und es muss ein Zugriffsschlüssel zum Verwenden der Dienste vom Nutzer gekauft werden. Dabei kann mittels Kryptowährung gezahlt werden, hier beispielsweise Ether oder mit denjenigen Tokens, welche von dem Netzwerk 1 generiert worden sind. Andere Nutzer ohne den Zugriffsschlüssel können die Anwendungsprogrammier schnittstellen zwar aufrufen, können aber, da die Dienste verschlüsselt sind, diese nicht nutzen.
Nach Erwerben des Zugriffsschlüssels wird ein Statechannel 3 zwischen dem Router und dem Nutzer geöffnet, um Transaktionen, insbesondere Mikropayments und den Aufruf der verschiedenen
Dienste mithilfe der Anwendungsprogrammierschnittstellen zu ermöglichen .
Wird der Statechannel geschlossen, so wird ermittelt wieviel beispielsweise Ether gezahlt worden ist. Zudem, insbesondere zeitgleich werden die Metadaten 5 der Transaktionen, welche durch einen im Netzwerk vorhandenen Transaktionsmonitor, welcher zur Protokollierung der Metadaten 5 der einzelnen Transaktionen konfiguriert ist, auf einem zweiten Distributed-Ledger-System verschlüsselt abgelegt.
Das zweite Distributed-Ledger-System ist hier als zweite Blockchain 4 mit einem Proof-of-Stake Konsensalgorithmus ausgestaltet. Die Metadaten 5 werden mittels eines Gossip Protokolls 6, auch Klatschprotokoll genannt, auf der zweiten Blockchain 4 abgelegt. Die zweite Blockchain 4 bietet eine schnelle Speicherung der Metadaten 5 an. Der Zugriffsschlüssel auf dieses Metadaten 5 kann mittels des Smart Contracts erworben werden .
Die Metadaten 5 können auch für ein zweites Netzwerk 7 interessant sein, welches hier ebenfalls so aufgebaut ist wie das Netzwerk 1, da sich das Interaktionsmodell eines Nutzers mit dem Netzwerk 1 durch die Metadaten 5 abbildet. Das zweite Netzwerk 7 weist ebenfalls eine erste Blockchain 8 sowie einen Statechannel 9 und Metadaten 10 auf. Diese Metadaten 10 werden
ebenfalls auf der zweiten Blockchain 4 gespeichert und sind somit verfügbar .
FIG 4 zeigt ein weiteres Ausführungsbeispiel der Erfindung. Hier schließen sich die Dienstanbieter mit Hilfe einen Nachrich tenrouters 11, welcher hier als gleichzeitig als Transakti onsmonitor ausgebildet ist, zu einem Verbund 12 zusammen.
Die Dienstanbieter registrieren ihre angebotenen Dienste als Anwendungsprogrammierschnittstellen mithilfe eines asymmet rischen Schlüsselpaares, beispielsweise RSA, ECC etc. durch jeweils einen Router auf dem ersten Distributed-Ledger-System, hier Ethereum 13. Der Router verwaltet hier die Anwendungs programmierschnittstellen, welche ein Dienstanbieter, bei spielsweise Dienstanbieter A anbietet. Dienstanbieter A greift jedoch dabei auch innerhalb des Verbundes 12 auf Dienste von Dienstanbieter B zurück. Damit kann der Router auch Anwen dungsprogrammierschnittstellen von beispielsweise Dienstan bieter B kontrollieren. In diesem Ausführungsbeispiel wird jedoch jeder Dienst eines Dienstanbieters einzeln auf Ethereum 13 durch einen Smart Contract registriert.
Der Nachrichtenrouter 11 ist in der Lage, Transaktion zwischen den Dienstanbietern des Verbundes 12, welche in Form von er folgreichen Zugriffen auf die Anwendungsprogrammierschnitt stellen stattfinden, zu protokollieren und dient somit als Transaktionsmonitor .
Ein Nutzer 14 der Dienstanbieter A Inanspruch nimmt, kann sich mit Hilfe eines Smart Contracts für dessen Dienst registrieren, und diesen für eine bestimmte Zeit oder eine Anzahl von Zugriffen buchen .
Dafür erhält er den Zugriffsschlüssel auf die Dienste und die Metadaten des Dienstanbieters A, welcher auch auf andere Dienste des Verbundes 12 zurückgreift. Die Transaktionen werden mittels Statechannel , das heißt Off-Chain durchgeführt.
Die Dienste, beispielsweise Daten werden über den Nachrich tenrouter 11 innerhalb des Verbundes 12 ausgetauscht und an schließend beispielsweise mittels des Statechannels als Transaktionen, zu dem Nutzer 14 geleitet. Der Nachrichtenrouter
11 dient hier als Transaktionsmonitor zum Protokollieren der Metadaten der Transaktionen.
Diese durch die Transaktionen erzeugten Metadaten werden dann in einem zweiten Distributed-Ledger-System, hier einem Hashgraph 15 gespeichert, und sind damit transparent und schnell verfügbar. Der Hashgraph 15 weist zur Speicherung der vielen Off-Chain Transaktionen einen schnellen Blockerzeugungszyklus auf.
Die Metadaten der erfolgten Transaktionen der verschiedenen Dienstanbieter werden anschließend ausgewertet, beispielsweise:
"Dienstanbieter A" :
{
verwendete_dienste_von_Dienstanbieter_B :
{
dienst_A: 12345 calls/h
dienst_B: 345 calls/h
}
Angebotene-Dienste :
{
Dienst_l : ws : //dienst_a_server : 7890
Dienst_2 : ws : //dienst_b_server : 7830
}
}
Die Dienstanbieter des Verbundes 12 können mit Hilfe eines weiteren Smart Contracts, welcher z.B. in Solidity geschrieben wird, definieren, wann die vom Nutzer 14 verwendeten Dienste des Verbundes 12 mittels einer Kryptowährung oder einer Fiatwährung abgerechnet werden, das heißt, wann der Nutzer 14 die Dienste zu bezahlen hat.
Der Zeitpunkt zur Bezahlung kann beispielsweise durch einen demokratischen Wahlprozess entschieden werden, bei dem alle Dienstanbieter ein gleichwertiges Stimmrecht haben, bei spielsweise, wenn eine bestimmte Anzahl an Transaktion erfolgt ist oder der Handelskurs gerade günstig steht.
Der Nutzer 14 kann die Dienste von Dienstanbieter A dann in Form einer App auf seinem Endgerät verwenden, beispielsweise in seinem Fahrzeug oder wenn sie in Form von Daten vorliegen, für eine weitere Dienstleistung verwenden.
Ein Nutzer 14 kann zudem nach passenden Vertragspartner suchen, ohne dafür eine zentrale Instanz zu benötigen. Somit werden dann keine Datenmarktplätze mehr benötigt.
FIG 5 zeigt eine erste Anwendung der Erfindung. Ein oder mehrere Dienstanbieter eines Netzwerkes 1 (FIG 3) oder eines Verbundes 12 (FIG 4) erkennen den Zustand eines Fahrers in einem Fahrzeug 16, beispielsweise indem sie Zugriff auf die Sensoren 18 in dem Fahrzeug zum Auswerten bekommt. Zum Beispiel können sie dadurch feststellen, welche Nebentätigkeiten der Fahrer im Fahrzeug 16 ausführt, beispielsweise ob der Fahrer gerade auf sein Smartphone schaut. Diese Information kann von den wie oben beschriebenen Dienstanbietern angeboten werden. Ein Nutzer 14 (FIG 4), beispielsweise eine Versicherung kann diese Daten einkaufen und ein entsprechendes Versicherungsmodell darauf anbieten. Hier kann das erfindungsgemäße System sowohl den Datentransfer als auch den Verkauf der Daten selber übernehmen.
FIG 6 zeigt eine zweite Anwendung der Erfindung. Ein erster Diensteanbieter eines Verbundes 12 (FIG 4) oder eines Netzwerkes 1 (FIG 3) erkennt die Position und Zeit eines Fahrzeugs 16 auf der Straße. Ein zweiter Dienstanbieter besitzt Daten zu Um schaltZeitpunkten einer Ampel 17 im Autovorkehr. Ein dritter
Dienstanbieter bezahlt den ersten und den zweiten Dienstan bieter, um aus diesen Daten zu generieren, wann sich das Fahrzeug 16 an einer Ampel 17 befindet und wie lange es dort stehen wird und bietet diese genierten Daten zum Verkauf an. Ein vierter Dienstanbieter kauft diese generierten Daten um über einen sicheren Kanal während der Standzeit Werbung im Fahrzeug an zuzeigen .
Entscheidend ist dabei, dass die Metadaten in schneller Zeit auf der zweiten Blockchain gespeichert werden. Durch die Entkopplung der Abrechnung über die zweite Blockchain kann hier ein schneller Datenaustausch als auch eine sichere Abrechnung ohne zentrale Instanz gewährleistet werden.
Bezugszeichenliste
100 Block einer Blockchain nach dem Stand der Technik
110 Blockchain nach dem Stand der Technik
1 Netzwerk
2 Erste Blockchain
3 Statechannel
4 zweite Blockchain
5 Metadaten
6 Gossip Protokoll
7 Zweites Netzwerk
8 Erste Blockchain des zweiten Netzwerkes
9 Statechannel des zweiten Netzwerkes
10 Metadaten des zweiten Netzwerkes
11 Nachrichtenrouter
12 Verbund
13 Ethereum
14 Nutzer
15 Hashgraph
16 Fahrzeug
17 Ampel
18 Sensoren
Claims
1. System
mit einem Netzwerk (1,7,12) mit mehreren Netzwerkknoten, welche jeweils mindestens einen Dienst über eine Anwen dungsprogrammierschnittstelle bereitstellen, und einem Router, welcher zur Kommunikation mit den mehreren Netz werkknoten und zum Verwalten der Anwendungsprogrammier schnittstellen konfiguriert ist, und einem Transaktionsmo nitor,
mit einem ersten Distributed-Ledger-System, insbesondere einer ersten Blockchain (2), mit untereinander verbundenen ersten Distributed-Ledger-System-Knoten, wobei das erste Distributed-Ledger-System einen ersten Konsensalgorithmus zur Blockerzeugung aufweist, wobei der Router mit dem ersten Distributed-Ledger-System zur Kommunikation verbindbar ist, und wobei ein Smart Contract zur Ausführung und Verwaltung von Transaktionen zwischen dem Router und einem Nutzer (14) auf dem ersten Distributed-Ledger-System durch den Router be reitgestellt ist, und wobei durch die Transaktionen erzeugte Metadaten (5,10) der Transaktionen von dem Transaktionsmo nitor protokolliert werden,
mit einem zweiten Distributed-Ledger-System, insbesondere einer zweiten Blockchain (4), mit untereinander verbundenen zweiten Distributed-Ledger-System-Knoten, wobei das Dis tributed-Ledger-System zur Speicherung der protokollierten Metadaten (5,10) mit dem Transaktionsmonitor verbunden ist, und wobei das zweite Distributed-Ledger-System einen zweiten Konsensalgorithmus zur Blockerzeugung aufweist, und wobei durch den zweiten Konsensalgorithmus ein kürzerer Blocker zeugungszyklus als mit dem ersten Konsensalgorithmus be werkstelligbar ist.
2. System nach Anspruch 1, dadurch gekennzeichnet, dass die Transaktionen zumindest einen erfolgreichen Zugriff des Nutzers (14) auf zumindest eine der Anwendungsprogrammier stellen umfassen.
3. System nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass ein Statechannel , welcher zur Ausführung des Smart Contracts konfiguriert ist, und welcher nicht Teil des ersten Dis- tributed-Ledger-Systems ist, vorgesehen ist.
4. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine Kryptowährung zur Bezahlung der Benutzung der Dienste vorgesehen ist.
5. System nach Anspruch 4, dadurch gekennzeichnet, dass der Router ein Wallet aufweist.
6. System nach Anspruch 5, dadurch gekennzeichnet, dass der Nutzer (14) mittels zumindest einer Transaktion Kryptowährung für die Nutzung eines oder mehrerer Dienste an den Router des Netzwerkes sendet.
7. System nach einem der vorhergehenden Ansprüche 5 bis 6, dadurch gekennzeichnet, dass die Metadaten (5,10) den Wechselkurs von der verwendeten Kryptowährung zu Fiatgeld, einer gesetzlichen Währung oder einer anderen Kryptowährung umfasst.
8. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Metadaten (5,10) mittels eines Gossip Protokolls (6) auf dem zweiten Distributed-Ledger-System, insbesondere der zweiten Blockchain (4), speicherbar sind.
9. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der zweite Konsensalgorithmus als Proof-of-Stake ausgestaltet ist.
10. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das zweite Distributed-Ledger-System als ein gerichteter azyklischer Graph ausgebildet ist.
11. System nach einem der vorhergehenden Ansprüche 1 bis 10, dadurch gekennzeichnet, dass das zweite Distribu ted-Ledger-System als ein Hashgraph ausgebildet ist.
12. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass jeder der Netzwerkknoten zumindest eine Anwendungsprogrammierschnittstelle und einen Router auf weist, wobei der Netzwerkknoten zum Zugriff auf die Dienste anderer Netzwerkknoten mittels deren Anwendungsprogram mierschnittstelle ausgebildet ist, und wobei der Router die Anwendungsprogrammierschnittstellen und die Zugriffe auf die Anwendungsprogrammierschnittstelle verwaltet .
13. Verfahren zum Betreiben eines Systems gekennzeichnet durch:
- Bereitstellen eines Netzwerks mit mehreren Netzwerkknoten, welcher jeweils mindestens einen Dienst über eine An wendungsprogrammierschnittstelle bereitstellt, und eines Routers, welcher zur Kommunikation mit den mehreren Netzwerkknoten und zum Verwalten der Anwendungsprogram mierschnittstellen konfiguriert wird, und eines Trans aktionsmonitors,
- Bereitstellen eines ersten Distributed-Ledger-Systems , insbesondere einer ersten Blockchain (2), mituntereinander verbundenen ersten Distributed-Ledger-System-Knoten, wobei das erste Distributed-Ledger-System einen ersten
Konsensalgorithmus zur Blockerzeugung aufweist, und wobei der Router mit dem ersten Distributed-Ledger-System zur Kommunikation verbunden wird, und wobei ein Smart Contract zur Ausführung und Verwaltung von Transaktionen zwischen dem Router und einem Nutzer auf dem ersten Distribu ted-Ledger-System durch den Router bereitgestellt wird, und wobei durch die Transaktionen erzeugte Metadaten (5, 10) der Transaktionen von dem Transaktionsmonitor protokolliert werden,
- Bereitstellen eines zweiten Distributed-Ledger-Systems , insbesondere einer zweiten Blockchain, mit untereinander verbundenen zweiten Distributed-Ledger-System-Knoten, wobei das zweite Distributed-Ledger-System mit dem Transaktionsmonitor zur Speicherung der protokollierten Metadaten (5,10) verbunden wird, und wobei das zweite Distributed-Ledger-System einen zweiten Konsensalgo rithmus zur Blockerzeugung aufweist, und wobei durch den zweiten Konsensalgorithmus ein kürzerer Blockerzeu gungszyklus als mit dem ersten Konsensalgorithmus be werkstelligt wird.
14. Verfahren zum Betreiben eines Systems nach Anspruch 13, dadurch gekennzeichnet, dass als zumindest eine Transaktion zumindest ein erfolgreicher Zugriff des Nutzers auf zumindest eine der Anwendungsprogrammierstellen ausgebildet wird.
15. Verfahren zum Betreiben eines Systems nach Anspruch 13 oder 14, dadurch gekennzeichnet, dass ein Statechannel , welcher nicht Teil des ersten Distributed-Ledger-Systems ist, zur Ausführung des Smart Contracts konfiguriert wird.
16. Verfahren zum Betreiben eines Systems nach einem der Ansprüche 13 bis 15, dadurch gekennzeichnet, dass eine Kryptowährung vorgesehen ist und der Nutzer mittels zumindest
einer Transaktion Kryptowährung für die Nutzung eines oder mehrerer Dienste an ein Wallet des Routers des Netzwerkes sendet .
17. Verfahren zum Betreiben eines Systems nach Anspruch 16, dadurch gekennzeichnet, dass die Metadaten (5,10) den Wechselkurs von der verwendeten Kryptowährung zu Fiatgeld, gesetzlichen Währung oder einer anderen Kryptowährung um fassen .
18. Verfahren zum Betreiben eines Systems nach einem der vorhergehenden Ansprüche 13 bis 17, dadurch gekennzeichnet, dass die Metadaten (5,10) mittels eines Gossip Protokolls (6) auf dem zweiten Distributed-Ledger-System gespeichert werden.
19. Verfahren zum Betreiben eines Systems nach einem der vorhergehenden Ansprüche 13 bis 18, dadurch gekennzeichnet, dass der zweite Konsensalgorithmus als Proof-of-Stake aus gestaltet wird.
20. Verfahren zum Betreiben eines Systems nach einem der vorhergehenden Ansprüche 13 bis 19, dadurch gekennzeichnet, dass das zweite Distributed-Ledger-System als ein gerichteter azyklischer Graph oder Hashgraph ausgebildet wird.
21. Computerprogramm, umfassend Befehle, die bei der Ausführung des Programms durch den Computer diesen veranlassen, das Verfahren nach einem der Ansprüche 13 bis 20 auszuführen.
22. Computerlesbares Speichermedium auf dem Computerprogramm nach Anspruch 21 gespeichert wird.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE102018210066.7 | 2018-06-21 | ||
DE102018210066.7A DE102018210066A1 (de) | 2018-06-21 | 2018-06-21 | System, Verfahren zum Betreiben eines Systems, Computerprogramm und speicherprogrammierbares Computerprogramm |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2019243359A1 true WO2019243359A1 (de) | 2019-12-26 |
Family
ID=67003477
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2019/066078 WO2019243359A1 (de) | 2018-06-21 | 2019-06-18 | System, verfahren zum betreiben eines systems, computerprogramm und speicherprogrammierbares computerprogramm |
Country Status (2)
Country | Link |
---|---|
DE (1) | DE102018210066A1 (de) |
WO (1) | WO2019243359A1 (de) |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170103468A1 (en) * | 2015-10-13 | 2017-04-13 | TransActive Grid Inc. | Use of Blockchain Based Distributed Consensus Control |
DE102016215917A1 (de) * | 2016-08-24 | 2018-03-01 | Siemens Aktiengesellschaft | Gesichertes Verarbeiten einer Berechtigungsnachweisanfrage |
-
2018
- 2018-06-21 DE DE102018210066.7A patent/DE102018210066A1/de not_active Withdrawn
-
2019
- 2019-06-18 WO PCT/EP2019/066078 patent/WO2019243359A1/de active Application Filing
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170103468A1 (en) * | 2015-10-13 | 2017-04-13 | TransActive Grid Inc. | Use of Blockchain Based Distributed Consensus Control |
DE102016215917A1 (de) * | 2016-08-24 | 2018-03-01 | Siemens Aktiengesellschaft | Gesichertes Verarbeiten einer Berechtigungsnachweisanfrage |
Also Published As
Publication number | Publication date |
---|---|
DE102018210066A1 (de) | 2019-12-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP3652656B1 (de) | Vorrichtungen zum bereitstellen einer menge von kryptographisch geschützten und gefilterten sowie sortierten transaktionsdatensätzen eines gliedes einer blockkette | |
EP3673623A1 (de) | Verfahren und steuersystem zum steuern und/oder überwachen von geräten | |
DE102016215914A1 (de) | Absichern einer Gerätenutzungsinformation eines Gerätes | |
DE102017214902A1 (de) | Indirekte Transaktionsvorgänge auf Basis einer Blockchainarchitektur | |
EP3830781A1 (de) | Verknüpfung von identitäten in einer verteilten datenbank | |
EP3743844B1 (de) | Blockchain-basiertes identitätssystem | |
EP3777088A1 (de) | Verfahren und system zum steuern einer freigabe einer ressource | |
WO2019081434A1 (de) | Verfahren und steuersystem zum steuern und/oder überwachen von geräten | |
WO2020043581A1 (de) | Blockbildungs-einrichtung und -verfahren, knoteneinrichtung und blockbestätigungs-verfahren | |
WO2019243359A1 (de) | System, verfahren zum betreiben eines systems, computerprogramm und speicherprogrammierbares computerprogramm | |
WO2020043588A1 (de) | Einrichtung und verfahren zum ermitteln einer konsensversion eines transaktionsbuchs und einrichtung und verfahren zum überwachen eines verteilten datenbanksystems | |
EP3254432A1 (de) | Verfahren zur berechtigungsverwaltung in einer anordnung mit mehreren rechensystemen | |
EP3857405A1 (de) | Datenbanksystem für ein soziales netzwerk mit verwendung von blockchain-technologie | |
WO2023036458A1 (de) | Verfahren und transaktionssystem zum übertragen von token in einem elektronischen transaktionssystems | |
WO2018130426A1 (de) | Anonymisierung einer blockkette | |
EP3619885B1 (de) | Verfahren zum blockchain basierten, asymmetrischen schlüsselmanagement und sicherheitsrelevante anlage | |
EP3618348B1 (de) | Verfahren zum betreiben eines verteilten datenbanksystems, verteiltes datenbanksystem und industrieautomatisierungssystem | |
DE102020120945A1 (de) | Verfahren zum Kommunizieren, basierend auf einer Distributed-Ledger-Technologie, zwischen einer Vielzahl von Ladestationen für Elektrofahrzeuge | |
WO2020058008A1 (de) | Verfahren zum ausführen einer applikation in einem fahrzeug, fahrzeugsystem, computerprogramm und datenträgersignal | |
EP3617976A1 (de) | Verfahren zum betreiben eines verteilten datenbanksystems, verteiltes datenbanksystem und industrieautomatisierungssystem | |
WO2020043430A1 (de) | Einrichtung und verfahren zum bereitstellen einer orakel-transaktion in einem verteilten datenbanksystem | |
DE102021212599A1 (de) | Schutz gegen Frontrunning-Angriffe in einem verteilten Register | |
DE102021130943A1 (de) | Konsensalgorithmus für distributed-ledger-technologie | |
EP3828798A1 (de) | Vorrichtung und verfahren zum bilden von datenblöcken | |
AT517151B1 (de) | Verfahren zur Autorisierung des Zugriffs auf anonymisiert gespeicherte Daten |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 19732949 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 19732949 Country of ref document: EP Kind code of ref document: A1 |