DE102020205529A1 - Verfahren und Vorrichtung zum Aushandeln intelligenter Verträge - Google Patents

Verfahren und Vorrichtung zum Aushandeln intelligenter Verträge Download PDF

Info

Publication number
DE102020205529A1
DE102020205529A1 DE102020205529.7A DE102020205529A DE102020205529A1 DE 102020205529 A1 DE102020205529 A1 DE 102020205529A1 DE 102020205529 A DE102020205529 A DE 102020205529A DE 102020205529 A1 DE102020205529 A1 DE 102020205529A1
Authority
DE
Germany
Prior art keywords
contract
following features
transaction
until
force
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102020205529.7A
Other languages
English (en)
Inventor
Alexander PODDEY
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to DE102020205529.7A priority Critical patent/DE102020205529A1/de
Publication of DE102020205529A1 publication Critical patent/DE102020205529A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3236Cryptographic 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/3239Cryptographic 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00Business processing using cryptography
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Verfahren (10) zum Aushandeln intelligenter Verträge, gekennzeichnet durch folgende Merkmale:- das zweite System und das dritte System setzen auf einem wechselseitigen Transaktionskanal einen ersten Vertrag auf (11),- das erste System und das dritte System schließen einen zweiten Vertrag, welcher das erste System zu einem Abschluss des ersten Vertrages anstelle des dritten Systems bevollmächtigt (12),- das erste System sendet dem zweiten System den zweiten Vertrag (13) und- das zweite System tätigt kraft des zweiten Vertrages den Abschluss (14) des ersten Vertrages auf dem Transaktionskanal.

Description

  • Die vorliegende Erfindung betrifft ein Verfahren zum Aushandeln intelligenter Verträge. Die vorliegende Erfindung betrifft darüber hinaus eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium.
  • Stand der Technik
  • Als dezentrales Transaktionssystem, Transaktionsdatenbank oder verteiltes Hauptbuch (distributed ledger) wird jegliches Protokoll in Rechnernetzen bezeichnet, das eine Übereinkunft (consensus) hinsichtlich der Abfolge bestimmter Transaktionen herbeiführt. Eine häufige Ausprägung eines solchen Systems bedient sich einer Blockkette (blockchain).
  • Das nach dem Stand der Technik am häufigsten benutzte Konsensverfahren sieht einen Arbeitsnachweis (proof of work, PoW) für die Erzeugung neuer gültiger Blöcke vor. Um einem übermäßigen Energieverbrauch durch die Erbringung derartiger Nachweise sowie einem unnötigen Anwachsen der Blockkette entgegenzuwirken, wurden sogenannte Transaktions- oder Zustandskanäle (state channels) vorgeschlagen und verallgemeinert. Einen Überblick dieser Technologie bietet COLEMAN, Jeff; HORNE, Liam; XUANJI, Li. Counterfactual: Generalized state channels. 2018.
  • DE102018210224A1 offenbart in der Ausführungsform gemäß Anspruch 6 folgendes Verfahren zum Vereinbaren einer Zusammenarbeit zwischen zwei Systemen: Das erste System sendet seine Annahmen bezüglich des zweiten Systems und seine diesem gewährten Garantien; umgekehrt sendet das zweite System dessen Annahmen bezüglich des ersten Systems und jenem gewährten Garantien. Eine Transaktionsdatenbank empfängt diese wechselseitigen Annahmen und Garantien, prüft, ob sie einander entsprechen, setzt gegebenenfalls einen zwischen den Systemen zu schließenden digitalen Sicherheitsvertrag auf und dokumentiert diesen schließlich, indem es einer Blockkette einen entsprechenden Block hinzufügt. Es sendet den Block mit dem Sicherheitsvertrag daraufhin an beide Systeme, welche die Zusammenarbeit aufnehmen, sobald sie den Block empfangen. Diese etablieren hierzu einen wechselseitigen Transaktionskanal, auf welchem sie nach Empfang des Blockes Informationen und unterschriebene Mitteilungen austauschen. Wenn eines der Systeme eine den Sicherheitsvertrag verletzende Information empfängt, ersucht es die Transaktionsdatenbank um Schlichtung. Die Transaktionsdatenbank setzt das andere System hiervon in Kenntnis, fordert von diesem die - vermeintlich den Sicherheitsvertrag verletzende - Information an und prüft letztere anhand des Vertrages.
  • Derlei intelligente Verträge (smart contracts) verkörpern die rechtsgeschäftliche Logik jedweder verteilten Anwendung (distributed application, dApp) einer Transaktionsdatenbank. DE102017214902A1 beispielsweise beschreibt einen intelligenten Vertrag zum Vorbereiten und/oder Ausführen von Transaktionen zwischen einem Halter eines Endgeräts und einem Dienstleistungsanbieter, wobei der intelligente Vertrag Bedingungen des Dienstleistungsanbieters für Dienstleistungen eines Informationsdienstleistungsanbieters, insbesondere Bedingungen über Benutzungsgebühren, vorzugsweise eine Straßenbenutzungsgebühr, und/oder für Dienstleistungen eines Servicedienstleistungsanbieters, insbesondere Bedingungen über Überlassungsgebühren, vorzugsweise über Parkgebühren, Tankgebühren, Gebühren einer Ladestation für das Endgerät und/oder Bedingungen einer Versicherung und/oder Bedingungen über Nutzungsgebühren, vorzugsweise über Gebühren einer gemeinschaftlichen Nutzung des Endgeräts zum Bereitstellen und/oder Abbrechen für eine Dienstleistung und/oder von dem Halter für dieses Endgerät definierte Bedingungen für eine Annahme und/oder eine Beendigung der Dienstleistung enthält, wobei der intelligente Vertrag in einem Berechtigungsknoten eines auf einer Blockchain basierten Computernetzwerks ausgeführt wird.
  • Offenbarung der Erfindung
  • Die Erfindung stellt ein Verfahren zum Aushandeln intelligenter Verträge, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes maschinenlesbares Speichermedium gemäß den unabhängigen Ansprüchen bereit.
  • Nach dem Stand der Technik wird der Vertrag, der die an den Transaktionskanal angeschlossenen Vertragsbeteiligten bindet, getrennt von der Blockkette gehalten, wobei der Vertrag zur Sicherstellung seiner Integrität mit einem Streuwert (hash) sowie zur Dokumentation der Übereinkunft mit einer Multisignatur (multisignature, multisig) versehen und in dieser Form bei Uneinigkeit unter den Vertragsbeteiligten hochgeladen und ausgeführt werden kann.
  • Um eine außerhalb der Kette operierende Instanz einer dApp einzurichten und Zustandsübergänge abseits der Kette (off-chain) zu vollziehen, müssen alle Kanalteilnehmer oder eine bestimmte Untermenge derselben den angestrebten Übergang signieren, um diesbezüglich eine Übereinkunft zu erzielen und nachzuweisen. Diese signierten Off-Chain-Zustände können dann im Streitfall verwendet werden, um eine Einigung in Bezug auf den resultierenden Zustand der gesamten Kette - üblicherweise den tatsächlich von den erforderlichen Kanalteilnehmern signierten Zustand - zu erzielen.
  • Der nachfolgend beschriebene Ansatz erkennt vor diesem Hintergrund die Schwierigkeit, dass der Teilnehmer eines Transaktionskanales nach dem Stand der Technik gezwungen ist, vereinbarte Zustände oder Transaktionen selbst zu signieren oder diese Aufgabe gegebenenfalls einem zum Signieren befähigten Vertreter zu übertragen, dem hierzu jedoch der private Schlüssel des Teilnehmers preiszugeben wäre. Dies hat zur Folge, dass der Kanalteilnehmer oder sein Vertreter über die Signierung einer vorgeschlagenen Transaktion bzw. eines neuen Zustandes entscheidet. In hierarchisch-modularen Ausprägungen verallgemeinerter Zustandskanäle mag es jedoch vorkommen, dass eine Signatur aufgrund einer bestehenden Verpflichtung von Dritten erzwungen werden muss, deren berechtigtes Interesse an einem Vertragsschluss zu diesem Zeitpunkt im Einzelfall von jenem des Verpflichteten abweichen kann. Entsprechendes gilt, wenn der vorgesehene Unterzeichner vom Kanal getrennt (offline) ist.
  • Ein Grundgedanke der vorgeschlagenen Lösung besteht vor diesem Hintergrund darin, Zweck und Auswirkung der Signatur als solcher - nämlich die Kennzeichnung eines Zustands oder Zustandsüberganges als vom jeweiligen Unterzeichner anerkannt - vom Vorgang des Signierens zu unterscheiden, indem letzterer wie folgt erweitert wird: Die vom betreffenden Teilnehmer oder dessen Vertreter selbst geleistete Signatur kann durch Vorlage eines Vertrages ersetzt werden, welcher für das Eintreten seiner Geltungsbedingungen dieselbe Wirkung vorsieht.
  • Ein Vorzug dieser Lösung liegt in ihrer Fähigkeit, in einer idealerweise die Vertraulichkeit wahrenden Weise ohne anfängliche Vertrauensbasis ein hierarchisch-modulares Vertrauensnetz aufzubauen.
  • Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im unabhängigen Anspruch angegebenen Grundgedankens möglich.
  • Figurenliste
  • Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
    • 1 das Flussdiagramm eines Verfahrens gemäß einer ersten Ausführungsform.
    • 2 schematisch ein Steuergerät gemäß einer zweiten Ausführungsform.
  • Ausführungsformen der Erfindung
  • 1 illustriert den grundlegenden Ablauf eines erfindungsgemäßen Verfahrens (10), welches nunmehr anhand des folgenden Anwendungsbeispiels erläutert sei: Gegeben seien drei Akteure A, B und C. B und C haben einen verallgemeinerten Zustandskanal mit einem - im einfachsten Falle - freien Wert BC_B1 und BC_C1 für einen bestimmten Zustand angelegt. Zusammenfassend lässt sich feststellen, dass B und C gemeinsam entscheiden können, einen Betrag zu sperren, der unter dem derzeit freien Wert liegt, indem sie gemeinsam eine entsprechende Transaktion signieren. Allgemeiner ausgedrückt setzen sie - womöglich sogar ohne Upload bis zur endgültigen Ablehnung bzw. Freigabe des Kanals - einen intelligenten Vertrag auf (Prozess 11), der eine beliebig komplexe dApp-Logik festschreibt, welche Übergänge zwischen dApp-Zuständen durch den auch innerhalb der Blockkette verfolgten Signierungsansatz off-chain ermöglicht, bevor das Endergebnis tatsächlich der Kette angegliedert wird.
  • Es mag für C unter bestimmten Bedingungen von Interesse sein, sich mit einem nicht am Kanal Beteiligten, z. B. dem Akteur A, darauf zu einigen, einen bestimmten Zustandsübergang auf dem Kanal BC zu signieren. Wenn diese Bedingungen erfüllt sind, soll A in die Lage versetzt werden, den Übergang auch dann zu erzwingen, wenn C dagegen oder offline ist.
  • Um dies zu erreichen, sieht der Aufbau des Kanals BC die Möglichkeit vor, das Ergebnis eines definierten Ablaufs, z. B. eines intelligenten Vertrags, als Entscheidungskriterium dafür festzulegen, ob die Wirkung der Signatur durch C eintreten soll; dies kann z. B. wie folgt umgesetzt werden: A und C schließen ihrerseits einen intelligenten Vertrag, der in einer Vertragssprache vorliegen kann, die in der virtuellen Maschine (VM) der Kette selbst oder nur von Teilnehmern des Kanals BC ausführbar ist. Dieser zweite Vertrag legt die Bedingung fest, unter der die Wirkung der Signatur von C für BC in definierten Zuständen bzw. Übergängen eintreten soll (Prozess 12).
  • Zu einem späteren Zeitpunkt, wenn C einen entsprechenden Übergang auf BC signieren sollte, aber zögert, könnte A nun - selbst oder durch einen kanalbezogenen dApp-Vertrag - B von seiner Absicht, den Übergang signieren zu lassen, in Kenntnis setzen. A sendet dazu den signierten Vertrag an B (Prozess 13), der ihn in der zugehörigen VM ausführen kann, und unterzeichnet somit gleichsam, sofern die einschlägigen Bedingungen erfüllt sind, den Übergang auf BC für C. Auf diese Weise kann B ohne Weiteres Zutun von C den zwischen ihnen auf dem Transaktionskanal aufgesetzten Vertrag schließen (Prozess 14).
  • Wenn C diesem Abschluss nicht zustimmt, etwa weil er B der Zusammenarbeit mit A beschuldigt, könnte er - wie bei verallgemeinerten Zustandskanälen üblich - die Angelegenheit an die Kette weiterleiten, indem er dieser den auf den Kanal BC bezogenen Vertrag vorlegt. Da keinerlei Vertrauen zwischen ihnen vorausgesetzt werden kann, ist die Ausführung des von B und C aufgesetzten Vertrages in der Blockkette und die daran geknüpfte Entscheidung über den Vollzug des Zustandsüberganges für sämtliche Teilnehmer der Kette verbindlich. Um sein Inkrafttreten zu prüfen, kann der zwischen B und C geschlossene Vertrag hierzu entweder - z. B. mittels eines sogenannten Orakels - externe Eingaben aus dem zwischen A und C geltenden Vertrag entgegennehmen oder diesen, sofern er in der gleichen Skriptsprache verfasst ist, unmittelbar selbst auszuführen.
  • Dieses Verfahren (10) kann beispielsweise in Software oder Hardware oder in einer Mischform aus Software und Hardware beispielsweise in einem Steuergerät (20) implementiert sein, wie die schematische Darstellung der 2 verdeutlicht.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • DE 102018210224 A1 [0004]
    • DE 102017214902 A1 [0005]
  • Zitierte Nicht-Patentliteratur
    • COLEMAN, Jeff; HORNE, Liam; XUANJI, Li. Counterfactual: Generalized state channels. 2018 [0003]

Claims (11)

  1. Verfahren (10) zum Aushandeln intelligenter Verträge zwischen einem ersten System, einem zweiten System und einem dritten System, gekennzeichnet durch folgende Merkmale: - das zweite System und das dritte System setzen auf einem wechselseitigen Transaktionskanal einen ersten Vertrag auf (11), - das erste System und das dritte System schließen einen zweiten Vertrag, welcher das erste System zu einem Abschluss des ersten Vertrages anstelle des dritten Systems bevollmächtigt (12), - das erste System weist gegenüber dem zweiten System den zweiten Vertrag nach (13) und - das zweite System tätigt kraft des zweiten Vertrages den Abschluss (14) des ersten Vertrages auf dem Transaktionskanal.
  2. Verfahren (10) nach Anspruch 1, gekennzeichnet durch folgende Merkmale: - das zweite System gliedert den ersten Vertrag einer Blockkette an, - widerspricht das dritte System dem Abschluss (14), so legt es den ersten Vertrag vor und - ein Inkrafttreten des ersten Vertrages wird in der Blockkette anhand des zweiten Vertrages geprüft.
  3. Verfahren (10) nach Anspruch 2, gekennzeichnet durch folgende Merkmale: - beim Aufsetzen (11) wird der erste Vertrag unter eine zwischen dem zweiten System und dritten System verhandelte Geltungsbedingung gestellt und - das Inkrafttreten erfolgt vorbehaltlich der Geltungsbedingung.
  4. Verfahren (10) nach Anspruch 2 oder 3, gekennzeichnet durch folgende Merkmale: - das erste System, das zweite System und das dritte System verwenden eine gemeinsame Skriptsprache und - zum Prüfen des Inkrafttretens werden der erste Vertrag und der zweite Vertrag gemeinsam in der Skriptsprache interpretiert.
  5. Verfahren (10) nach Anspruch 2 oder 3, gekennzeichnet durch folgende Merkmale: - der erste Vertrag sieht zum Prüfen seines Inkrafttretens einen Aufruf eines gemeinsamen Orakels vor und - beim Aufruf erfolgt das Prüfen durch das Orakel anhand des zweiten Vertrages.
  6. Verfahren (10) nach einem der Ansprüche 2 bis 5, gekennzeichnet durch folgende Merkmale: - der erste Vertrag regelt eine finanzielle Transaktion in einer gemeinsamen Kryptowährung und - die Blockkette dient den Systemen als verteiltes Hauptbuch der Kryptowährung.
  7. Verfahren (10) nach Anspruch 6, gekennzeichnet durch folgende Merkmale: - die Transaktion ist eine in der Kryptowährung durch das erste System abgesicherte Zahlung an das zweite System und - für die Zahlung auf dem Transaktionskanal gesperrte Zahlungsmittel werden durch das Inkrafttreten freigegeben.
  8. Verfahren (10) nach einem der Ansprüche 1 bis 7, gekennzeichnet durch mindestens eines der folgenden Merkmale: - das erste System und das zweite System sind identisch, - das erste System und das dritte System sind identisch oder - das zweite System und das dritte System sind identisch.
  9. Computerprogramm, welches eingerichtet ist, das Verfahren (10) nach einem der Ansprüche 1 bis 8 auszuführen.
  10. Maschinenlesbares Speichermedium, auf dem das Computerprogramm nach Anspruch 9 gespeichert ist.
  11. Vorrichtung (20), die eingerichtet ist, das Verfahren (10) nach einem der Ansprüche 1 bis 8 auszuführen.
DE102020205529.7A 2020-04-30 2020-04-30 Verfahren und Vorrichtung zum Aushandeln intelligenter Verträge Pending DE102020205529A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102020205529.7A DE102020205529A1 (de) 2020-04-30 2020-04-30 Verfahren und Vorrichtung zum Aushandeln intelligenter Verträge

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102020205529.7A DE102020205529A1 (de) 2020-04-30 2020-04-30 Verfahren und Vorrichtung zum Aushandeln intelligenter Verträge

Publications (1)

Publication Number Publication Date
DE102020205529A1 true DE102020205529A1 (de) 2021-11-04

Family

ID=78267575

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020205529.7A Pending DE102020205529A1 (de) 2020-04-30 2020-04-30 Verfahren und Vorrichtung zum Aushandeln intelligenter Verträge

Country Status (1)

Country Link
DE (1) DE102020205529A1 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102017214902A1 (de) 2017-08-25 2019-02-28 Zf Friedrichshafen Ag Indirekte Transaktionsvorgänge auf Basis einer Blockchainarchitektur
DE102018210224A1 (de) 2018-06-22 2019-12-24 Robert Bosch Gmbh Verfahren und Vorrichtung zum Vereinbaren einer Zusammenarbeit zwischen einem ersten System und einem zweiten System

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102017214902A1 (de) 2017-08-25 2019-02-28 Zf Friedrichshafen Ag Indirekte Transaktionsvorgänge auf Basis einer Blockchainarchitektur
DE102018210224A1 (de) 2018-06-22 2019-12-24 Robert Bosch Gmbh Verfahren und Vorrichtung zum Vereinbaren einer Zusammenarbeit zwischen einem ersten System und einem zweiten System

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
COLEMAN, Jeff; HORNE, Liam; XUANJI, Li. Counterfactual: Generalized state channels. 2018

Similar Documents

Publication Publication Date Title
DE69500205T2 (de) Gesichertes System zur Verbindung lokaler Netzwerke über ein öffentliches Übertragungsnetzwerk
DE102017209014A1 (de) Verfahren und Vorrichtung zum Anfügen von Transaktionen an eine Blockkette
DE102012206341A1 (de) Gemeinsame Verschlüsselung von Daten
DE102015220228A1 (de) Verfahren und System zur Absicherung einer erstmaligen Kontaktaufnahme eines Mobilgeräts mit einem Gerät
EP3748521A1 (de) Verfahren zum lesen von attributen aus einem id-token
EP3157192A1 (de) Verfahren und system für eine asymmetrische schlüsselherleitung
DE102018000471A1 (de) Blockchain-basiertes Identitätssystem
DE102020213017A1 (de) Verfahren zum Bereitstellen eines Zustandskanals
EP2730050B1 (de) Verfahren zur erstellung und überprüfung einer elektronischen pseudonymen signatur
DE102020205529A1 (de) Verfahren und Vorrichtung zum Aushandeln intelligenter Verträge
DE102020213240A1 (de) Verfahren und Vorrichtung zum Abwickeln einer Transaktion zwischen mehreren Partitionen einer Blockkette
EP3376419B1 (de) System und verfahren zum elektronischen signieren eines dokuments
EP3619885B1 (de) Verfahren zum blockchain basierten, asymmetrischen schlüsselmanagement und sicherheitsrelevante anlage
DE102020205528A1 (de) Verfahren und Vorrichtung zum Abwickeln einer Transaktion
DE102020211936A1 (de) Verfahren und Vorrichtung zum Betreiben einer verteilten Anwendung
DE102006029756A1 (de) Verfahren zum Delegieren von Privilegien an eine niedriger-priviligierte Instanz durch eine höher-priviligierte Instanz
DE102020210000A1 (de) Verfahren und Vorrichtung zum Bestätigen eines Rechtsgeschäftes
DE102018221954A1 (de) Recheneinrichtung und Verfahren zum Betreiben einer Recheneinrichtung
DE102020213245A1 (de) Verfahren und Vorrichtung zum Erzeugen einer pseudozufälligen Zahlenfolge
EP3107029B1 (de) Verfahren und vorrichtung zum personalisierten elektronischen signieren eines dokuments und computerprogrammprodukt
EP3764266A1 (de) Verfahren und vorrichtung zum handeln auf einer elektronischen handelsplattform
DE102022000857B3 (de) Verfahren zur sicheren Identifizierung einer Person durch eine Verifikationsinstanz
WO1998002991A1 (de) Verfahren zur schlüsselverteilung zwischen zwei einheiten in einer isdn/internet verbindung
DE102020210810A1 (de) Verfahren und Vorrichtung zum gegenseitigen Bewerten von Leistungserbringern und Leistungsempfänger mittels einer dezentralen Transaktionsdatenbank
DE102020207563A1 (de) Verfahren und Vorrichtung zum Erteilen einer Gutschrift über einen Zahlungskanal