DE112022000111T5

DE112022000111T5 - Wallet-System und Transaktionsverfahren

Info

Publication number: DE112022000111T5
Application number: DE112022000111.9T
Authority: DE
Inventors: Weisha Zhu
Original assignee: Fifth Force Tech Ltd; Fifth Force Technology Ltd
Current assignee: Fifth Force Tech Ltd; Fifth Force Technology Ltd
Priority date: 2022-05-19
Filing date: 2022-10-25
Publication date: 2024-01-18
Also published as: GB2623142A; GB202304532D0; US20230410092A1

Abstract

Die Erfindung betrifft ein Wallet-System und ein Transaktionsverfahren. Das Wallet-System umfasst einen Kommunikationsknoten, einen Planungsknoten und mindestens einen Backup-Knoten, wobei pro Knoten ein privater Schlüssel gespeichert wird, wobei alle privaten Schlüssel für dasselbe Konto ausgelegt sind. Zunächst generiert der Kommunikationsknoten abhängig von einer empfangenen Zahlungstransaktionsinformation eine Transaktionsanforderung und sendet die Transaktionsanforderung an den Planungsknoten (S1). Anschließend wählt der Planungsknoten als Antwort auf die Transaktionsanforderung mehrere Knoten als Signaturknoten aus (S2). Dann generiert der Planungsknoten nach einem Planen des privaten Schlüssels im Signaturknoten zum Signieren von einzelnen Zahlungstransaktionen eine Information zum erfolgreichen Signieren und meldet sie an den Kommunikationsknoten zurück (S3). Schließlich führt der Kommunikationsknoten nach einem Empfangen der Information zum erfolgreichen Signieren einen Zahlungstransaktionsvorgang durch (S4). Das System der Ausführungsbeispiele der vorliegenden Erfindung ist ein unabhängiges Cluster-System, das vollständig von einem Benutzer gesteuert wird. Es ist ein Wallet-System, das durch Kombinieren von Cluster-Technologie und Multi-Signatur-Technologie aufgebaut wurde. Und dieses System ist das erste, das eine hochsichere Speicherung und Vererbung von Vermögenswerten realisiert und eine an Web3 angepasste Transaktion ermöglicht.

Description

TECHNISCHES GEBIET
Die vorliegende Erfindung bezieht sich auf das Gebiet der Transaktionen von digitalen Vermögenswerten, und insbesondere auf ein Wallet-System und ein Transaktionsverfahren.
STAND DER TECHNIK
Web3 ist eine Reihe umfangreicher Bewegungen und Protokolle, die eingeführt wurden, um das Internet dezentraler, verifizierbarer und sicherer zu machen, d.h. um ein Internet zu realisieren, in dem ein Benutzer seine eigenen Daten kontrollieren kann. Jedoch gibt es auf dem Gebiet der Transaktionen von digitalen Vermögenswerten im Stand der Technik noch kein Wallet-System, das sich gut an Web3 anpassen kann. Daher ist die Bereitstellung eines an Web3 angepassten Wallet-Systems ein schwieriges Problem, das im Gebiet der Transaktionen von digitalen Vermögenswerten gelöst werden muss.
INHALT DER VORLIEGENDEN ERFINDUNG
Die vorliegende Erfindung stellt ein Wallet-System und ein Transaktionsverfahren bereit, um das Problem des Fehlens eines an Web3 angepassten Transaktionsmodus im Stand der Technik zu lösen, und kann durch Kombinieren von Cluster-Technologie und Multi-Signatur-Technologie ein Wallet-System erstellen, das einen an Web3 angepassten Transaktionsmodus ermöglicht.
Um den obigen Zweck zu erreichen, stellen Ausführungsbeispiele der vorliegenden Erfindung ein Wallet-System bereit, das einen Kommunikationsknoten, einen Planungsknoten und mindestens einen Backup-Knoten umfasst, wobei pro Knoten ein privater Schlüssel gespeichert wird, wobei alle privaten Schlüssel für dasselbe Konto ausgelegt sind;
wobei der Kommunikationsknoten dazu verwendet wird, eine Transaktionsanforderung abhängig von einer empfangenen Zahlungstransaktionsinformation zu generieren und die Transaktionsanforderung an den Planungsknoten zu senden;
wobei der Planungsknoten dazu verwendet wird, als Antwort auf die Transaktionsanforderung mehrere Knoten als Signaturknoten auszuwählen;
wobei der Planungsknoten ferner dazu verwendet wird, nach einem Planen des privaten Schlüssels im Signaturknoten zum Signieren von einzelnen Zahlungstransaktionen eine Information zum erfolgreichen Signieren zu generieren und an den Kommunikationsknoten zurückzumelden;
wobei der Kommunikationsknoten ferner verwendet wird, nach einem Empfangen der Information zum erfolgreichen Signieren einen Zahlungstransaktionsvorgang durchzuführen.
Als Verbesserung der obigen Lösung ist vorgesehen, dass die Zahlungstransaktionsinformation jedenfalls einen Zieltransaktionsbetrag umfasst, wobei die Transaktionsanforderung jedenfalls einen Zielsignaturmodus umfasst;
wobei das Merkmal „der Kommunikationsknoten dazu verwendet wird, eine Transaktionsanforderung abhängig von einer empfangenen Zahlungstransaktionsinformation zu generieren“ insbesondere umfasst:

dass der Kommunikationsknoten dazu verwendet wird, basierend auf einer voreingestellten Abbildungsbeziehung zwischen einem Transaktionsbetrag und einem Signaturmodus abhängig von dem Zieltransaktionsbetrag den Zielsignaturmodus zu erhalten.

Als Verbesserung der obigen Lösung ist vorgesehen, dass die Abbildungsbeziehung insbesondere lautet:

dass Transaktionsbeträge je nach Betrag in mehrere Ebenen eingeteilt sind;
wobei, wenn ein erster Transaktionsbetrag größer als ein zweiter Transaktionsbetrag ist, die Ebene des ersten Transaktionsbetrags höher als oder gleich wie die Ebene des zweiten Transaktionsbetrags ist;
wobei je höher die Ebene ist, desto mehr Unterzeichner sind im Signaturmodus erforderlich.

Als Verbesserung der obigen Lösung ist vorgesehen, dass der private Schlüssel generiert wird, indem jeder Knoten jeweils in einem getrennten Zustand einen privaten Schlüssel für dasselbe Konto generiert.
Als Verbesserung der obigen Lösung ist vorgesehen, dass der Kommunikationsknoten ferner verwendet wird, abhängig von dem Zahlungstransaktionsvorgang im Fall, dass die Zahlungstransaktionsinformation zu Transaktionsinformationen von Non-Fungible Token gehört, nach dem Abschluss des Zahlungstransaktionsvorgangs einen Transaktionsdatensatz zu generieren und ein Kontobuch seines eigenen Knotens zu aktualisieren;
wobei der Kommunikationsknoten ferner verwendet wird, den Transaktionsdatensatz an weitere Knoten zu senden, so dass die weiteren Knoten abhängig von dem Transaktionsdatensatz das Kontobuch ihrer eigenen Knoten aktualisieren.
Als Verbesserung der obigen Lösung ist vorgesehen, dass der Planungsknoten, nachdem der Kommunikationsknoten die Transaktionsanforderung an den Planungsknoten gesendet hat und bevor der Planungsknoten den privaten Schlüssel im Signaturknoten zum Signieren von einzelnen Zahlungstransaktionen plant, ferner verwendet wird, im Fall, dass die Zahlungstransaktionsinformation zu Transaktionsinformationen von Non-Fungible Token gehört, ein zu sicherndes Kontobuch in seinem eigenen Knoten an alle Backup-Knoten zu senden, so dass die Backup-Knoten das Kontobuch ihrer eigenen Knoten mit den zu sichernden Kontobuch abgleichen und das Kontobuch ihrer eigenen Knoten aktualisieren; wobei das zu sichernde Kontobuch Informationen im Kontobuch des Planungsknotens darstellen, die nicht mit allen weiteren Knoten synchronisiert sind.
Als Verbesserung der obigen Lösung ist vorgesehen, dass der Kommunikationsknoten ferner verwendet wird, abhängig von dem Zahlungstransaktionsvorgang im Fall, dass die Zahlungstransaktionsinformation zu Transaktionsinformationen von Kryptowährung gehört, nach dem Abschluss des Zahlungstransaktionsvorgangs einen Transaktionsdatensatz zu generieren, um ein öffentliches Konto zu aktualisieren.
Als Verbesserung der obigen Lösung umfasst das Wallet-System ferner einen Ersatzknoten;
wobei der Ersatzknoten dazu verwendet wird, als Antwort auf einen von einem Benutzer eingegebenen Knotenersatzbefehl eine mit privatem Schlüssel verschlüsselte Datei eines designierten, zu ersetzenden Knotens aus der Cloud zu erhalten und eine Knotenersatzanforderung zu generieren, die an den Planungsknoten gesendet wird;
wobei der Planungsknoten ferner dazu verwendet wird, als Antwort auf die Knotenersatzanforderung die privaten Schlüssel mehrerer anderer Knoten als des zu ersetzenden Knotens zu planen, um eine mit privatem Schlüsseln verschlüsselte Datei zu signieren, so dass der Ersatzknoten die mit privatem Schlüssel verschlüsselte Datei öffnet, um einen privaten Schlüssel des zu ersetzenden Knotens zu erhalten; wobei die mit privatem Schlüssel verschlüsselte Datei des zu ersetzenden Knotens durch das Verschlüsseln des privaten Schlüssels des zu ersetzenden Knotens mit privaten Schlüsseln mehrerer weiterer Knoten erhalten wird;
wobei der Ersatzknoten ferner dazu verwendet wird, nach einem Festlegen des privaten Schlüssels des zu ersetzenden Knotens als privaten Schlüssel seines eigenen Knotens eine Knotenänderungsinformation zu generieren und an den Planungsknoten zu senden, so dass der Planungsknoten eine Knotenplanung genau durchführen kann.
Als Verbesserung der obigen Lösung ist vorgesehen, dass das Wallet-System ferner einen geerbten Knoten umfasst, wobei die Anzahl von geerbten Knoten gleich wie die Anzahl von aufgegebenen Knoten ist; wobei die aufgegebenen Knoten einen aufgegebenen Kommunikationsknoten, einen aufgegebenen Planungsknoten und einen aufgegebenen Backup-Knoten umfassen;
wobei ein geerbter Zielknoten dazu verwendet wird, als Antwort auf einen Befehl zur Benutzeranmeldung abhängig von einem Benutzernamen und einem Passwort eines der aufgegebenen Knoten eine Zuordnungsbeziehung mit einer in Cloud gespeicherten Vererbungsdatei herzustellen;
wobei der geerbte Zielknoten ferner dazu verwendet wird, als Antwort auf einen Vererbungsbefehl des Benutzers die Cloud so zu steuern, dass sie die Vererbungsdatei an ein voreingestelltes soziales Konto des Benutzers zu senden, so dass Benutzer abhängig von der Vererbungsdatei jedem geerbten Knoten einen Benutzernamen, ein Passwort und einen privaten Schlüssel, die zu dem aufgegebenen Knoten korrespondieren, zuweist; wobei in der Vererbungsdatei der Benutzernamen, das Passwort und der private Schlüssel einzelner aufgegebenen Knoten aufgezeichnet sind.
Um den obigen Zweck zu erreichen, stellen Ausführungsbeispiele der vorliegenden Erfindung ferner ein Transaktionsverfahren bereit, das auf dem Wallet-System nach einem der vorstehenden Ausführungsbeispiele basiert und das umfasst:

ein Kommunikationsknoten generiert eine Transaktionsanforderung abhängig von einer empfangenen Zahlungstransaktionsinformation und sendet die Transaktionsanforderung an den Planungsknoten;
ein Planungsknoten wählt als Antwort auf die Transaktionsanforderung mehrere Knoten als Signaturknoten aus;
der Planungsknoten generiert nach einem Planen des privaten Schlüssels im Signaturknoten zum Signieren von einzelnen Zahlungstransaktionen eine Information zum erfolgreichen Signieren und sie an den Kommunikationsknoten zurückmeldet;
der Kommunikationsknoten führt nach einem Empfangen der Information zum erfolgreichen Signieren einen Zahlungstransaktionsvorgang durch.

Im Vergleich mit dem Stand der Technik offenbart die vorliegende Erfindung ein Wallet-System und ein Transaktionsverfahren. Das Wallet-System umfasst einen Kommunikationsknoten, einen Planungsknoten und mindestens einen Backup-Knoten, wobei pro Knoten ein privater Schlüssel gespeichert wird, wobei alle privaten Schlüssel für dasselbe Konto ausgelegt sind. Zunächst generiert der Kommunikationsknoten abhängig von einer empfangenen Zahlungstransaktionsinformation eine Transaktionsanforderung und sendet die Transaktionsanforderung an den Planungsknoten. Anschließend wählt der Planungsknoten als Antwort auf die Transaktionsanforderung mehrere Knoten als Signaturknoten aus. Dann generiert der Planungsknoten nach einem Planen des privaten Schlüssels im Signaturknoten zum Signieren von einzelnen Zahlungstransaktionen eine Information zum erfolgreichen Signieren und meldet sie an den Kommunikationsknoten zurück. Schließlich führt der Kommunikationsknoten nach einem Empfangen der Information zum erfolgreichen Signieren einen Zahlungstransaktionsvorgang durch. Die Ausführungsbeispiele der vorliegenden Erfindung können durch Kombinieren von Cluster-Technologie und Multi-Signatur-Technologie ein Wallet-System aufbauen, das vollständig vom Benutzer gesteuert wird, wodurch eine an Web3 angepasste Transaktion ermöglicht wird.
KURZE BESCHREIBUNG DER ZEICHNUNGEN

1 zeigt eine schematische Strukturansicht eines Wallet-Systems gemäß Ausführungsbeispielen der vorliegenden Erfindung;
2 zeigt ein schematisches Flussdiagramm eines Transaktionsverfahrens gemäß Ausführungsbeispielen der vorliegenden Erfindung.

AUSFÜHRLICHE BESCHREIBUNG
Die technischen Lösungen in den Ausführungsbeispielen der vorliegenden Erfindung werden nachstehend unter Bezugnahme auf die beigefügten Zeichnungen der Ausführungsbeispiele der vorliegenden Erfindung klar und vollständig beschrieben. Offensichtlich sind die beschriebenen Ausführungsbeispiele nur ein Teil der Ausführungsbeispiele der vorliegenden Erfindung und umfassen nicht alle Ausführungsbeispiele. Alle anderen Ausführungsbeispiele, die vom Durchschnittsfachmann auf der Grundlage der Ausführungsbeispiele in der vorliegenden Erfindung ohne schöpferischen Aufwand erzielt werden, sollten in den Schutzumfang der vorliegenden Erfindung fallen.
Unter Bezugnahme auf 1 wird eine schematische Strukturansicht eines Wallet-Systems, das durch Ausführungsbeispiele der vorliegenden Erfindung bereitgestellt wird, dargestellt, wobei das Wallet-System einen Kommunikationsknoten, einen Planungsknoten und mindestens einen Backup-Knoten umfasst, wobei pro Knoten ein privater Schlüssel gespeichert wird, wobei alle privaten Schlüssel für dasselbe Konto ausgelegt sind;
wobei der Kommunikationsknoten dazu verwendet wird, eine Transaktionsanforderung abhängig von einer empfangenen Zahlungstransaktionsinformation zu generieren und die Transaktionsanforderung an den Planungsknoten zu senden;
wobei der Planungsknoten dazu verwendet wird, als Antwort auf die Transaktionsanforderung mehrere Knoten als Signaturknoten auszuwählen;
wobei der Planungsknoten ferner dazu verwendet wird, nach einem Planen des privaten Schlüssels im Signaturknoten zum Signieren von einzelnen Zahlungstransaktionen eine Information zum erfolgreichen Signieren zu generieren und an den Kommunikationsknoten zurückzumelden;
wobei der Kommunikationsknoten ferner verwendet wird, nach einem Empfangen der Information zum erfolgreichen Signieren einen Zahlungstransaktionsvorgang durchzuführen.
Es sollte angegeben werden, dass die einzelnen Knoten (Kommunikationsknoten, Planungsknoten und Backup-Knoten) ein elektronisches Gerät wie etwa ein Mobiltelefon, ein Computer oder ein Server sein kann, was hier nicht beschränkt ist. Ein kleines Cluster-System, das für Geldbörsen geeignet ist, wird durch ein Great-Free-Distributed-Language bereitgestellt. Das System liegt vollständig in der Hand eines Benutzers, ohne dass externe Geräte oder externes Personal zur Steuerung erforderlich sind. Das System ist ein Master-Slave-System, das auf einem Peer-to-Peer-Netzwerk aufgebaut ist, wobei die Rollen der Knoten je nach Bedarf miteinander ausgetauscht werden können, wobei alle Knoten über die Funktion der Signatur mit privatem Schlüssel verfügen. Der Kommunikationsknoten ist für eine externe Kommunikation zuständig und dient als Brücke für den Informationsaustausch zwischen der Außenseite des Systems und dem Inneren des Systems. Der Planungsknoten fungiert als interner Planer des Systems, führt eine Informationsinteraktion mit weiteren Knoten durch und ermöglicht, dass das System aufgrund einer Clusterplanung über eine Multi-Signatur-Funktion verfügt. Es versteht sich, dass zur weiteren Verbesserung der Sicherheit der Zahlungstransaktion Verifikationsfunktionen wie Gesichtserkennung, Passworterkennung oder Fingerabdruckerkennung an einem elektronischen Gerät, auf dem sich die Knoten befinden, vorgesehen werden können, wobei erst nach einer erfolgreichen Verifizierung das Signieren, der Zahlungstransaktionsvorgang und dergleichen erfolgen können. Beispielsweise löst der Planungsknoten nach dem Auswählen eines Signaturknotens einen Verifizierungsvorgang aus; alternativ löst der Kommunikationsknoten nach dem Empfangen einer Information zum erfolgreichen Signieren einen Verifizierungsvorgang aus. Das Verifizierungsverfahren und der Verifizierungszeitpunkt können vom Benutzer gemäß den tatsächlichen Bedürfnissen eingestellt werden und sind hier nicht beschränkt.
Insbesondere besteht das Wallet-System aus einem Kommunikationsknoten, einem Planungsknoten und einem Backup-Knoten. Die Anzahl der Backup-Knoten wird durch die spezifische Anwendung des Systems bestimmt. Pro Knoten wird ein privater Schlüssel, wobei diese privaten Schlüssel für dasselbe Konto ausgelegt sind. Das heißt, für jedes Konto ist ein Clustersystem erforderlich, um das Konto zu verwalten. Wenn Geld auf ein weiteres Konto überwiesen werden muss, verarbeitet der für die Kommunikation mit der Außenwelt zuständige Kommunikationsknoten nach Erhalt der Zahlungstransaktionsinformation die Zahlungstransaktionsinformation, um eine Transaktionsanforderung zu generieren und die Transaktionsanforderung an den Planungsknoten innerhalb des Systems zu senden. Der Planungsknoten wählt mehrere Knoten aus allen Knoten im System als Signaturknoten aus, indem er auf die empfangene Transaktionsanforderung antwortet. Die Anzahl von Signaturknoten wird durch die voreingestellten Regeln für die Anzahl der Signaturen bestimmt, wobei der Signaturknoten ein Planungsknoten, ein Kommunikationsknoten oder ein Backup-Knoten sein. Die Auswahl von Signaturknoten wird durch die voreingestellten Auswahlregeln bestimmt, und kann eine zufällige Auswahl oder eine Knotenauswahl durch Voreinstellen von Prioritäten usw. sein, was hier nicht beschränkt ist. Der Planungsknoten plant den Signierknoten so, dass der Signierknoten seinen eigenen privaten Schlüssel zum Signieren der aktuellen Zahlungstransaktion verwendet, und generiert dann eine Information zum erfolgreichen Signieren und meldet sie an den Kommunikationsknoten zurück, so dass der Kommunikationsknoten ein Signal zum Ausführen der Transaktion erhält, wodurch der Zahlungstransaktionsvorgang durchgeführt wird.
Im Vergleich mit dem Stand der Technik offenbart die vorliegende Erfindung ein Wallet-System. Das Wallet-System umfasst einen Kommunikationsknoten, einen Planungsknoten und mindestens einen Backup-Knoten, wobei pro Knoten ein privater Schlüssel gespeichert wird, wobei alle privaten Schlüssel für dasselbe Konto ausgelegt sind. Zunächst generiert der Kommunikationsknoten abhängig von einer empfangenen Zahlungstransaktionsinformation eine Transaktionsanforderung und sendet die Transaktionsanforderung an den Planungsknoten. Anschließend wählt der Planungsknoten als Antwort auf die Transaktionsanforderung mehrere Knoten als Signaturknoten aus. Dann generiert der Planungsknoten nach einem Planen des privaten Schlüssels im Signaturknoten zum Signieren von einzelnen Zahlungstransaktionen eine Information zum erfolgreichen Signieren und meldet sie an den Kommunikationsknoten zurück. Schließlich führt der Kommunikationsknoten nach einem Empfangen der Information zum erfolgreichen Signieren einen Zahlungstransaktionsvorgang durch. Die Ausführungsbeispiele der vorliegenden Erfindung können durch Kombinieren von Cluster-Technologie und Multi-Signatur-Technologie ein Wallet-System aufbauen, das vollständig vom Benutzer gesteuert wird, wodurch eine an Web3 angepasste Transaktion ermöglicht wird.
In einer Ausführungsform ist vorgesehen, dass die Zahlungstransaktionsinformation jedenfalls einen Zieltransaktionsbetrag umfasst, wobei die Transaktionsanforderung jedenfalls einen Zielsignaturmodus umfasst;
wobei das Merkmal „der Kommunikationsknoten dazu verwendet wird, eine Transaktionsanforderung abhängig von einer empfangenen Zahlungstransaktionsinformation zu generieren“ insbesondere umfasst:

Insbesondere muss die von dem Kommunikationsknoten empfangenen Zahlungstransaktionsinformation einen Zieltransaktionsbetrag enthalten. In der vorliegenden Ausführungsform wird der Zielsignaturmodus durch den Zieltransaktionsbetrag bestimmt. Der Kommunikationsknoten fragt die Abbildungsbeziehung zwischen dem voreingestellten Transaktionsbetrag und dem Signaturmodus ab und findet einen dem Zieltransaktionsbetrag entsprechende Signaturmodus als Zielsignaturmodus. Dabei kann es sich bei dem Signaturmodus um eine Bestimmung, welcher Knoten der Signaturknoten ist, oder um eine Einstellung der Anzahl der Signaturknoten handeln, was hier nicht beschränkt ist.
In einer Ausführungsform lautet die Abbildungsbeziehung insbesondere:

Insbesondere ist die Abbildungsbeziehung zwischen dem Transaktionsbetrag und dem Signaturmodus tatsächlich eine Abbildungsbeziehung zwischen dem Transaktionsbetrag und der Anzahl von Unterzeichnern (also der Anzahl von Signaturknoten), die beim Aufbauen des Systems durch den Benutzer eingestellt wurde und während einer nachfolgenden Anwendung des Systems durch den Benutzer gemäß den tatsächlichen Anforderungen modifiziert werden kann. Die Transaktionsbeträge werden je nach Betrag in eine voreingestellte Anzahl von Ebenen eingeteilt. Je größer der Transaktionsbetrag, desto höher die Ebene (einschließlich eines Falls von unterschiedlichen Transaktionsbeträge in derselben Ebene, der in Form einer stückweisen Funktion auftritt). Je höher die Ebene, desto mehr Unterzeichner werden im entsprechenden Signaturmodus benötigt. Dadurch, dass unterschiedliche Anzahlen von Unterzeichnern je nach Transaktionsbetrag ausgewählt werden, werden sowohl die Bequemlichkeit der Zahlungstransaktion als auch die Sicherheit der Zahlungstransaktion berücksichtigt.
Beispielhaft wird angenommen, dass im System drei Knoten, und zwar ein Kommunikationsknoten, ein Planungsknoten und ein Backup-Knoten, vorliegen, dass jeder Knoten mit einem privaten Schlüssel versehen ist, dass eine Multi-Signatur implementiert ist und dass eine 3-1-Multi-Signatur (nur eine Signatur mit privatem Schlüssel ist erforderlich), eine 3-2-Multi-Signatur (zwei Signaturen mit privatem Schlüssel sind erforderlich) und eine 3-3-Multi-Signatur (alle Signaturen mit privatem Schlüssel sind erforderlich) voreingestellt sind, ist die voreingestellte Abbildungsbeziehung spezifisch wie folgt: Ein Signaturmodus, der einem Transaktionsbetrag von weniger als oder gleich wie 3.000 Yuan entspricht, ist 3-1-Multi-Signatur; ein Signaturmodus, der einem Transaktionsbetrag von mehr als 3.000 Yuan und weniger als oder gleich wie 10.000 Yuan entspricht, ist 3-2-Multi-Signatur; und ein Signaturmodus, der einem Transaktionsbetrag von mehr als 10.000 Yuan entspricht, ist 3-3-Multi-Signatur.
Es sollte angegeben werden, dass die Abbildungsbeziehung auf das vorstehende spezifische Beispiel beschränkt ist und gemäß tatsächlichen Situationen eingestellt werden kann. Es versteht sich, das die minimale Anzahl der Unterzeichner 0 ist und die maximale Anzahl Unterzeichner gleich wie die Anzahl der privaten Schlüssel ist. Die spezifische Anzahl der Ebenen von privaten Schlüsseln wird vom Benutzer eingestellt. Die minimale Anzahl der Ebenen ist 1 und die maximale Anzahl der Ebenen hängt von der Anzahl der privaten Schlüssel im System ab und entspricht der der Anzahl der privaten Schlüssel plus 1 entspricht.
In einer Ausführungsform ist vorgesehen, dass die Zahlungstransaktionsinformation ferner eine Information zum Transaktionspartner umfasst.
Dann umfasst das Durchführen eines Zahlungstransaktionsvorgangs insbesondere, dass der Zieltransaktionsbetrag abhängig von der Information zum Transaktionspartner an einen Transaktionspartner überwiesen wird. Detailliert müssen beim Durchführen eines Zahlungstransaktionsvorgangs durch den Kommunikationsknoten der Zieltransaktionsbetrag und die Information zum Transaktionspartner (Konto des Transaktionspartners) geklärt werden, bevor der Zieltransaktionsbetrag an den Transaktionspartner überwiesen werden kann.
In einer Ausführungsform ist vorgesehen, dass der private Schlüssel generiert wird, indem jeder Knoten jeweils in einem getrennten Zustand einen privaten Schlüssel für dasselbe Konto generiert.
Da das Wallet-System ein Peer-to-Peer-Netzwerk ist, kann insbesondere die Generierung jedes privaten Schlüssels in einem getrennten Zustand durchgeführt werden. Das „getrennt“ hier bezieht sich auf einen Zustand, in dem ein Knoten von anderen Knoten getrennt ist. Der private Schlüssel jedes Knotens wird von dem Knoten selbst generiert. Jeder Knoten hat nur den privaten Schlüssel seines eigenen Knotens und nicht die privaten Schlüssel anderer Knoten, wodurch die Möglichkeit, beim Angriff eines bestimmten Knotens die privaten Schlüssel anderer Knoten preiszugeben, vermieden wird und die Sicherheitsleistung des Systems verbessert wird.
In einer Ausführungsform ist vorgesehen, dass der Kommunikationsknoten ferner verwendet wird, abhängig von dem Zahlungstransaktionsvorgang im Fall, dass die Zahlungstransaktionsinformation zu Transaktionsinformationen von Non-Fungible Token gehört, nach dem Abschluss des Zahlungstransaktionsvorgangs einen Transaktionsdatensatz zu generieren und ein Kontobuch seines eigenen Knotens zu aktualisieren;
wobei der Kommunikationsknoten ferner verwendet wird, den Transaktionsdatensatz an weitere Knoten zu senden, so dass die weiteren Knoten abhängig von dem Transaktionsdatensatz das Kontobuch ihrer eigenen Knoten aktualisieren.
Nachdem der Kommunikationsknoten den Zahlungstransaktionsvorgang durchgeführt hat, muss insbesondere ein Kontobuch, zu dem das Konto gehört, aktualisiert werden. Für unterschiedliche Arten von Konten wird das Kontobuch auf unterschiedliche Weise gespeichert. Wenn die vom Kommunikationsknoten empfangenen Zahlungstransaktionsinformation eine Zahlungstransaktionsinformation über Non-Fungible Token (NFT) ist, bedeutet dies, dass das Konto zu Konten von Non-Fungible Token gehört. Jeder Knoten des Systems wird mit einem Teil-Kontobuch versehen ist. Nachdem der Zahlungstransaktionsvorgang abgeschlossen ist, generiert der Kommunikationsknoten abhängig von dem Zahlungstransaktionsvorgang einen Transaktionsdatensatz und sendet den Transaktionsdatensatz an weitere Knoten (Planungsknoten, Backup-Knoten), so dass die weiteren Knoten abhängig von dem Transaktionsdatensatz das Kontobuch ihrer eigenen Knoten aktualisieren, wodurch eine Datensynchronisierung und -sicherung realisiert werden. Es versteht sich, dass während jeder Zahlungstransaktion der Kommunikationsknoten als Brücke für die Interaktion mit externen Informationen und der Planungsknoten für Signatursplaner online sein müssen. Daher sind die Kontobücher des Kommunikationsknotens und des Planungsknotens identisch und zeichnen alle Transaktionen auf, während der Backup-Knoten nur als ein Anbieter von privaten Schlüsseln dient und nicht in Echtzeit online sein muss. Daher kann es Fälle geben, in denen das Kontobuch des Backup-Knotens nicht in Echtzeit aktualisiert wird.
Weiterhin generiert jeder Knoten Vermögensinformationen abhängig von seinem eigenen Kontobuch. Wenn der Knoten einen vom Benutzer eingegebenen Befehl zur Vermögensabfrage empfängt, werden die Vermögensinformationen auf einem Anzeigebildschirm angezeigt, damit Benutzer die Vermögensinformationen sehen kann.
Weiterhin ist der Planungsknoten auch zur Informationsinteraktion mit einem externen voreingestellten Transaktionssystem „kettenfreie Plattform“ verwendet. Dabei stellt die kettenfreie Plattform jeweils eine Informationsinteraktion mit weiteren Wallet-Systemen her. In praktischen Anwendungen wird die kettenfreie Plattform zur Verfolgung von Überweisungen verwendet. Wenn die kettenfreie Plattform erkennt, dass eine Zahlung eingegangen ist, wird eine Information zur erfolgreichen Transaktion generiert und an beide an der Transaktion beteiligten Partner zurückgemeldet, so dass die beiden an der Transaktion beteiligten Partner sich über den Abschluss der Transaktion informiert sind.
In einer Ausführungsform ist vorgesehen, dass der Planungsknoten, nachdem der Kommunikationsknoten die Transaktionsanforderung an den Planungsknoten gesendet hat und bevor der Planungsknoten den privaten Schlüssel im Signaturknoten zum Signieren von einzelnen Zahlungstransaktionen plant, ferner verwendet wird, im Fall, dass die Zahlungstransaktionsinformation zu Transaktionsinformationen von Non-Fungible Token gehört, ein zu sicherndes Kontobuch in seinem eigenen Knoten an alle Backup-Knoten zu senden, so dass die Backup-Knoten das Kontobuch ihrer eigenen Knoten mit den zu sichernden Kontobuch abgleichen und das Kontobuch ihrer eigenen Knoten aktualisieren; wobei das zu sichernde Kontobuch Informationen im Kontobuch des Planungsknotens darstellen, die nicht mit allen weiteren Knoten synchronisiert sind.
Insbesondere bezieht sich das zu sichernde Kontobuch auf Kontobuch-Informationen, die nicht vollständig gesichert wurden (d. h. es gibt noch einen Backup-Knoten, der nicht synchronisiert ist). Und das zu sichernde Kontobuch wird in einem Pufferbereich für zu sichernde Kontenbücher im Planungsknoten zwischengespeichert. Um die Genauigkeit der Datensicherung zu verbessern, muss der Planungsknoten vor dem Senden des zu sichernden Kontobuchs an den Backup-Knoten das zu sichernde Kontobuch mit dem eigenen Kontobuch des Planungsknotens abgleichen und es dann übertragen, wenn das zu sichernde Kontobuch richtig ist. Da es nicht garantiert werden kann, dass der Backup-Knoten in Echtzeit online ist, muss der Planungsknoten vor jeder Überweisung das zu sichernde Kontobuch zum Abgleich an einen Online-Backup-Knoten senden, damit das Kontobuch des Backup-Knotens mit dem des Planungsknoten synchronisiert wird. Während der Synchronisation kann der Abgleich abhängig von Zeitstempeln einzelner Daten im Kontobuch erfolgen. Nachdem der Planungsknoten die Transaktionsanforderung erhalten hat, ist er darüber informiert, dass eine Transaktion bevorsteht. Um sicherzustellen, dass Kontenbücher vor der Überweisung synchronisiert werden können, sendet der Planungsknoten vor der Planung von Signaturen ein in seinem eigenen Knoten zwischengespeichertes, zu sicherndes Kontenbuch an einen Online-Backup-Knoten, damit der Backup-Knoten eine Datensynchronisierung durchführt.
In einer Ausführungsform ist vorgesehen, dass der Kommunikationsknoten ferner verwendet wird, abhängig von dem Zahlungstransaktionsvorgang im Fall, dass die Zahlungstransaktionsinformation zu Transaktionsinformationen von Kryptowährung gehört, nach dem Abschluss des Zahlungstransaktionsvorgangs einen Transaktionsdatensatz zu generieren, um ein öffentliches Konto zu aktualisieren.
Insbesondere wenn das System Transaktionen von Kryptowährung bedient, gibt es kein Kontobuch lokal im System. Stattdessen wird ein öffentliches Kontobuch verwendet, um Transaktionen aufzuzeichnen. Nachdem der Zahlungstransaktionsvorgang abgeschlossen ist, generiert der Kommunikationsknoten abhängig von dem Zahlungstransaktionsvorgang einen entsprechenden Transaktionsdatensatz und sendet den Transaktionsdatensatz an einen vollständigen Knoten der Kryptowährung, wobei der vollständige Knoten für die Verwaltung und Aktualisierung des öffentlichen Kontos zuständig ist. Es versteht sich, dass der Prozess beendet ist, nachdem ein Transaktionsdatensatz generiert und an das öffentliche Konto gesendet wurde. Das öffentliche Konto kann abhängig von dem Transaktionsdatensatz aktualisiert werden. Für das Wallet-System wird der Transaktionsdatensatz in einen temporären Datenpool eines vollständigen Knotens der Kryptowährung gesendet.
Weiterhin dient das Wallet-System als ein kettenfreies System, wobei ein von jedem Knoten im Wallet-System gespeichertes Kontobuch ein Teil-Kontobuch ist, wobei das Wallet-System die Speicherung von Teil-Kontobüchern, NFT-Metadaten und Indizes des kettenlosen Systems unterstützt und auch den privaten Schlüssel der Kryptowährung enthält.
In einer Ausführungsform ist vorgesehen, dass das Wallet-System ferner einen Ersatzknoten umfasst;
wobei der Ersatzknoten dazu verwendet wird, als Antwort auf einen von einem Benutzer eingegebenen Knotenersatzbefehl eine mit privatem Schlüssel verschlüsselte Datei eines designierten, zu ersetzenden Knotens aus der Cloud zu erhalten und eine Knotenersatzanforderung zu generieren, die an den Planungsknoten gesendet wird;
wobei der Planungsknoten ferner dazu verwendet wird, als Antwort auf die Knotenersatzanforderung die privaten Schlüssel mehrerer anderer Knoten als des zu ersetzenden Knotens zu planen, um eine mit privatem Schlüsseln verschlüsselte Datei zu signieren, so dass der Ersatzknoten die mit privatem Schlüssel verschlüsselte Datei öffnet, um einen privaten Schlüssel des zu ersetzenden Knotens zu erhalten; wobei die mit privatem Schlüssel verschlüsselte Datei des zu ersetzenden Knotens durch das Verschlüsseln des privaten Schlüssels des zu ersetzenden Knotens mit privaten Schlüsseln mehrerer weiterer Knoten erhalten wird;
wobei der Ersatzknoten ferner dazu verwendet wird, nach einem Festlegen des privaten Schlüssels des zu ersetzenden Knotens als privaten Schlüssel seines eigenen Knotens eine Knotenänderungsinformation zu generieren und an den Planungsknoten zu senden, so dass der Planungsknoten eine Knotenplanung genau durchführen kann.
Insbesondere konfiguriert das System, wie in 1 gezeigt, auch einen Cloud-Speicher (Backup-Cloud-Speicher, Planungs-Cloud-Speicher, Kommunikations-Cloud-Speicher) für jeden Knoten. Der Cloud-Speicher kann ein Cloud-Speichersystem wie eine Familien-Cloud oder ein interplanetares Dateisystem (InterPlanetary File System, IPFS) sein, was hier nicht beschränkt ist. Nachdem der Knoten einen privaten Schlüssel generiert hat, verschlüsselt er den privaten Schlüssel seines eigenen Knotens, um eine mit dem privaten Schlüssel verschlüsselte Datei (Smart-Vertrag) zu erhalten, und sendet die mit dem privaten Schlüssel verschlüsselte Datei an einen Cloud-Speicher, der seinem eigenen Knoten entspricht, für einen Cloud-Backup des privaten Schlüssels. Beispielsweise kann die mit dem privaten Schlüssel verschlüsselte Datei durch private Schlüssel weiterer Knoten entschlüsselt werden, wie z. B. 3-2-Multi-Signatur. Wenn ein Gerät verloren geht, antwortet der Ersatzknoten (ein neues Gerät) auf den vom Benutzer eingegebenen Knotenersatzbefehl und greift über das voreingestellte Passwort auf den Cloud-Speicher zu, der dem verlorenen Gerät entspricht, lädt die mit dem privaten Schlüssel verschlüsselte Datei aus der Cloud herunter und generiert eine Knotenersatzanforderung, die an den Planungsknoten gesendet wird. Als Antwort auf die Knotenersatzanforderung plant der Planungsknoten private Schlüssel anderer Geräte als des verlorenen Geräts, um die mit privatem Schlüssel verschlüsselte Datei in dem neuen Gerät zu entschlüsseln, so dass das neue Gerät den privaten Schlüssel des verlorenen Geräts erhält. Anschließend stellt das neue Gerät den erhaltenen privaten Schlüssel als seinen eigenen privaten Schlüssel ein, generiert eine Knotenänderungsinformation und sendet sie an den Planungsknoten, so dass der Planungsknoten das neue Gerät im nachfolgenden Transaktionsprozess genau planen kann.
Wenn der Benutzer in einer Ausführungsform das alte Gerät durch ein neues Gerät ersetzen möchte, liefert das alte Gerät als Antwort auf einen vom Benutzer eingegebenen Befehl zum Transferieren des privaten Schlüssels seinen eigenen privaten Schlüssel an das neue Gerät. Insbesondere generiert das alte Gerät einen QR-Code des privaten Schlüssels gemäß seinem eigenen privaten Schlüssel als Antwort auf einen vom Benutzer eingegebenen Befehl zum Transferieren des privaten Schlüssels. Und das neue Gerät erhält den entsprechenden privaten Schlüssel durch Scannen des QR-Codes des privaten Schlüssels.
In einer Ausführungsform ist vorgesehen, dass das Wallet-System ferner einen geerbten Knoten umfasst, wobei die Anzahl von geerbten Knoten gleich wie die Anzahl von aufgegebenen Knoten ist; wobei die aufgegebenen Knoten einen aufgegebenen Kommunikationsknoten, einen aufgegebenen Planungsknoten und einen aufgegebenen Backup-Knoten umfassen;
wobei ein geerbter Zielknoten dazu verwendet wird, als Antwort auf einen Befehl zur Benutzeranmeldung abhängig von einem Benutzernamen und einem Passwort eines der aufgegebenen Knoten eine Zuordnungsbeziehung mit einer in Cloud gespeicherten Vererbungsdatei herzustellen;
wobei der geerbte Zielknoten ferner dazu verwendet wird, als Antwort auf einen Vererbungsbefehl des Benutzers die Cloud so zu steuern, dass sie die Vererbungsdatei an ein voreingestelltes soziales Konto des Benutzers zu senden, so dass Benutzer abhängig von der Vererbungsdatei jedem geerbten Knoten einen Benutzernamen, ein Passwort und einen privaten Schlüssel, die zu dem aufgegebenen Knoten korrespondieren, zuweist; wobei in der Vererbungsdatei der Benutzernamen, das Passwort und der private Schlüssel einzelner aufgegebenen Knoten aufgezeichnet sind.
Insbesondere wird die Vererbung des privaten Schlüssels verwendet, wenn alle ursprünglichen Knoten verloren gegangen sind. Die Vererbungsdatei zeichnet Benutzernamen aller Knoten im Wallet-System, Passwörter und privaten Schlüssel, die den Benutzernamen entsprechen, auf. Im Fall, dass das ursprüngliche Gerät (aufgegebener Knoten) verloren geht, antwortet das neue Gerät (geerbter Zielknoten) auf einen Befehl zur Benutzeranmeldung, meldet sich gemäß einem Benutzernamen und Passwort eines der aufgegebenen Knoten an und stellt Verbindung mit dem Cloud-Speicher her, der dem aufgegebenen Knoten entspricht. D.h., eine Zuordnungsbeziehung zwischen dem neuen Gerät und der im Cloud-Speicher gespeicherten geerbten Datei wird hergestellt. Als Antwort auf den Vererbungsbefehl des Benutzers steuert das neue Gerät nach einem voreingestellten Zeitraum den entsprechenden Cloud-Speicher derart, dass er die Vererbungsdatei an ein voreingestelltes soziales Benutzerkonto (wie E-Mail, SMS usw.) sendet. Dabei kann der voreingestellte Zeitraum vom Benutzer gemäß den tatsächlichen Bedürfnissen eingestellt werden. Nach dem voreingestellten Zeitraum wird eine voreingestellte Vererbungs-Erinnerungsnachricht angezeigt, beispielsweise durch eine Sprachübertragung oder eine Textanzeige. Der Benutzer kann Benutzernamen, Passwörter und private Schlüssel abhängig von der empfangenen Vererbungsdatei einer voreingestellten Anzahl neuer Geräte (geerbte Knoten) zuweisen, um ursprüngliche Geräte zu ersetzen. Die Anzahl der neuen Geräte entspricht der Anzahl der ursprünglichen Geräte. Wenn das neue Gerät den Vererbungsbefehl des Benutzers empfängt, erhält es ferner die Verifizierungsfragen zur Vererbung, die in der Cloud vorgespeichert sind, damit der Benutzer solche Fragen beantworten kann. Wenn die Antworten des Benutzers auf die Verifizierungsfragen eine voreingestellte Genauigkeitsrate erfüllen, fährt das neue Gerät mit dem nächsten Vorgang fort.
Nachdem die Vererbung des privaten Schlüssels abgeschlossen ist, generiert ein geerbter Kommunikationsknoten beim Empfang der Zahlungstransaktionsinformation ferner eine Transaktionsanforderung und sendet die Transaktionsanforderung an einen geerbten Planungsknoten. Dabei umfassen die geerbten Knoten einen geerbten Kommunikationsknoten, einen geerbten Planungsknoten und mindestens einen geerbten Backup-Knoten.
Der geerbte Planungsknoten plante als Antwort auf die Transaktionsanforderung alle privaten Schlüssel von geerbten Knoten, um Zahlungstransaktionen zu signieren, wonach eine Information zum erfolgreichen Signieren generiert ist und an den geerbten Kommunikationsknoten gesendet wird.
Der geerbte Kommunikationsknoten führt nach dem Empfang der Information zum erfolgreichen Signieren einen Zahlungstransaktionsvorgang durch.
Es versteht sich, dass der Verlust des Geräts eine gewisse Unsicherheit mit sich bringt. Daher muss nach der Vererbung des privaten Schlüssels eine Transaktion mit allen privaten Schlüsseln gleichzeitig signiert werden, um das Risiko zu verringern. Wenn der Benutzer das Risiko weiter reduzieren möchte, kann er außerdem ein neues Wallet-System aufbauen, alle Vermögenswerte im ursprünglichen Wallet-System zur Vermögensverwaltung auf das neue Wallet-System übertragen und das ursprüngliche Wallet-System verwerfen, um den Zweck der Verbesserung der Vermögenssicherheit zu erreichen.
Weiterhin verfügt das Wallet-System über eine Selbsttestfunktion für die Programmsicherheit, um sicherzustellen, dass das Programm unversehrt ist, die Synchronisierung abgeschlossen ist und die Konten korrekt sind. Im Allgemeinen wird ein Selbsttest durchgeführt, wenn das elektronische Gerät, in dem sich der Knoten befindet, eingeschaltet wird.
Das Wallet-System kann außerdem als unabhängige Anwendung dazu verwendet werden, Zahlungstransaktionen direkt durchzuführen, und kann auch mit Anwendungen von Drittanbietern gekoppelt werden, um Zahlungen bei Anwendungen von Drittanbietern durchzuführen, da das elektronische Gerät, auf dem sich der Kommunikationsknoten befindet, auch Anwendungen von Drittanbietern (z. B. zentralisierte Anwendungen wie WeChat und Alipay) betrifft. Daher ist es notwendig, den Schnittstellenstandard der API-Schnittstelle der Anwendungen von Drittanbietern zu erhalten, um die API-Schnittstelle des Wallet-Systems zu konfigurieren, so dass das Wallet-System reibungslos mit einem Drittsystem für die Transaktionszahlung gekoppelt werden kann.
Die Ausführungsbeispiele der vorliegenden Erfindung können durch Kombinieren von Cluster-Technologie und Multi-Signatur-Technologie ein Wallet-System aufbauen, das vollständig vom Benutzer gesteuert wird, wodurch eine an Web3 angepasste Transaktion ermöglicht wird.
Unter Bezugnahme auf das schematische Flussdiagramm des in 2 gezeigten Transaktionsverfahrens stellen Ausführungsbeispiele der vorliegenden Erfindung ferner ein Transaktionsverfahren bereit, das auf das Wallet-System nach einem der vorstehenden Ausführungsbeispiele angewendet wird, und das folgende Schritte umfasst:

S 1: ein Kommunikationsknoten generiert eine Transaktionsanforderung abhängig von einer empfangenen Zahlungstransaktionsinformation und sendet die Transaktionsanforderung an den Planungsknoten;
S2: ein Planungsknoten wählt als Antwort auf die Transaktionsanforderung mehrere Knoten als Signaturknoten aus;
S3: der Planungsknoten generiert nach einem Planen des privaten Schlüssels im Signaturknoten zum Signieren von einzelnen Zahlungstransaktionen eine Information zum erfolgreichen Signieren und sie an den Kommunikationsknoten zurückmeldet;
S4: der Kommunikationsknoten führt nach einem Empfangen der Information zum erfolgreichen Signieren einen Zahlungstransaktionsvorgang durch.

Es sollte angegeben werden, dass für den spezifischen Arbeitsprozess des Transaktionsverfahrens auf den Arbeitsprozess des Wallet-Systems in den vorstehend beschriebenen Ausführungsbeispiele verwiesen werden kann, was hier nicht wiederholt wird.
Im Vergleich mit dem Stand der Technik offenbart die vorliegende Erfindung ein Transaktionsverfahren. Zunächst generiert der Kommunikationsknoten abhängig von einer empfangenen Zahlungstransaktionsinformation eine Transaktionsanforderung und sendet die Transaktionsanforderung an den Planungsknoten. Anschließend wählt der Planungsknoten als Antwort auf die Transaktionsanforderung mehrere Knoten als Signaturknoten aus. Dann generiert der Planungsknoten nach einem Planen des privaten Schlüssels im Signaturknoten zum Signieren von einzelnen Zahlungstransaktionen eine Information zum erfolgreichen Signieren und meldet sie an den Kommunikationsknoten zurück. Schließlich führt der Kommunikationsknoten nach einem Empfangen der Information zum erfolgreichen Signieren einen Zahlungstransaktionsvorgang durch. Die Ausführungsbeispiele der vorliegenden Erfindung können durch Kombinieren von Cluster-Technologie und Multi-Signatur-Technologie ein Wallet-System aufbauen, das vollständig vom Benutzer gesteuert wird, wodurch eine an Web3 angepasste Transaktion ermöglicht wird.

Claims

Wallet-System, dadurch gekennzeichnet, dass es einen Kommunikationsknoten, einen Planungsknoten und mindestens einen Backup-Knoten umfasst, wobei pro Knoten ein privater Schlüssel gespeichert wird, wobei alle privaten Schlüssel für dasselbe Konto ausgelegt sind; wobei der Kommunikationsknoten dazu verwendet wird, eine Transaktionsanforderung abhängig von einer empfangenen Zahlungstransaktionsinformation zu generieren und die Transaktionsanforderung an den Planungsknoten zu senden (S 1); wobei der Planungsknoten dazu verwendet wird, als Antwort auf die Transaktionsanforderung mehrere Knoten als Signaturknoten auszuwählen (S2); wobei der Planungsknoten ferner dazu verwendet wird, nach einem Planen des privaten Schlüssels im Signaturknoten zum Signieren von einzelnen Zahlungstransaktionen eine Information zum erfolgreichen Signieren zu generieren und an den Kommunikationsknoten zurückzumelden (S3); wobei der Kommunikationsknoten ferner verwendet wird, nach einem Empfangen der Information zum erfolgreichen Signieren einen Zahlungstransaktionsvorgang durchzuführen (S4); wobei das Wallet-System ferner einen Ersatzknoten umfasst; wobei der Ersatzknoten dazu verwendet wird, als Antwort auf einen von einem Benutzer eingegebenen Knotenersatzbefehl eine mit privatem Schlüssel verschlüsselte Datei eines designierten, zu ersetzenden Knotens aus der Cloud zu erhalten und eine Knotenersatzanforderung zu generieren, die an den Planungsknoten gesendet wird; wobei der Planungsknoten ferner dazu verwendet wird, als Antwort auf die Knotenersatzanforderung die privaten Schlüssel mehrerer anderer Knoten als des zu ersetzenden Knotens zu planen, um eine mit privatem Schlüsseln verschlüsselte Datei zu signieren, so dass der Ersatzknoten die mit privatem Schlüssel verschlüsselte Datei öffnet, um einen privaten Schlüssel des zu ersetzenden Knotens zu erhalten; wobei die mit privatem Schlüssel verschlüsselte Datei des zu ersetzenden Knotens durch das Verschlüsseln des privaten Schlüssels des zu ersetzenden Knotens mit privaten Schlüsseln mehrerer weiterer Knoten erhalten wird; wobei der Ersatzknoten ferner dazu verwendet wird, nach einem Festlegen des privaten Schlüssels des zu ersetzenden Knotens als privaten Schlüssel seines eigenen Knotens eine Knotenänderungsinformation zu generieren und an den Planungsknoten zu senden, so dass der Planungsknoten eine Knotenplanung genau durchführen kann.
Wallet-System nach Anspruch 1, dadurch gekennzeichnet, dass die Zahlungstransaktionsinformation jedenfalls einen Zieltransaktionsbetrag umfasst, wobei die Transaktionsanforderung jedenfalls einen Zielsignaturmodus umfasst; wobei das Merkmal „der Kommunikationsknoten dazu verwendet wird, eine Transaktionsanforderung abhängig von einer empfangenen Zahlungstransaktionsinformation zu generieren“ insbesondere umfasst: dass der Kommunikationsknoten dazu verwendet wird, basierend auf einer voreingestellten Abbildungsbeziehung zwischen einem Transaktionsbetrag und einem Signaturmodus abhängig von dem Zieltransaktionsbetrag den Zielsignaturmodus zu erhalten.
Wallet-System nach Anspruch 2, dadurch gekennzeichnet, dass die Abbildungsbeziehung insbesondere lautet: dass Transaktionsbeträge je nach Betrag in mehrere Ebenen eingeteilt sind; wobei, wenn ein erster Transaktionsbetrag größer als ein zweiter Transaktionsbetrag ist, die Ebene des ersten Transaktionsbetrags höher als oder gleich wie die Ebene des zweiten Transaktionsbetrags ist; wobei je höher die Ebene ist, desto mehr Unterzeichner sind im Signaturmodus erforderlich.
Wallet-System nach Anspruch 1, dadurch gekennzeichnet, dass der private Schlüssel generiert wird, indem jeder Knoten jeweils in einem getrennten Zustand einen privaten Schlüssel für dasselbe Konto generiert.
Wallet-System nach Anspruch 1, dadurch gekennzeichnet, dass der Kommunikationsknoten ferner verwendet wird, abhängig von dem Zahlungstransaktionsvorgang im Fall, dass die Zahlungstransaktionsinformation zu Transaktionsinformationen von Non-Fungible Token gehört, nach dem Abschluss des Zahlungstransaktionsvorgangs einen Transaktionsdatensatz zu generieren und ein Kontobuch seines eigenen Knotens zu aktualisieren; wobei der Kommunikationsknoten ferner verwendet wird, den Transaktionsdatensatz an weitere Knoten zu senden, so dass die weiteren Knoten abhängig von dem Transaktionsdatensatz das Kontobuch ihrer eigenen Knoten aktualisieren.
Wallet-System nach Anspruch 1, dadurch gekennzeichnet, dass der Planungsknoten, nachdem der Kommunikationsknoten die Transaktionsanforderung an den Planungsknoten gesendet hat und bevor der Planungsknoten den privaten Schlüssel im Signaturknoten zum Signieren von einzelnen Zahlungstransaktionen plant, ferner verwendet wird, im Fall, dass die Zahlungstransaktionsinformation zu Transaktionsinformationen von Non-Fungible Token gehört, ein zu sicherndes Kontobuch in seinem eigenen Knoten an alle Backup-Knoten zu senden, so dass die Backup-Knoten das Kontobuch ihrer eigenen Knoten mit den zu sichernden Kontobuch abgleichen und das Kontobuch ihrer eigenen Knoten aktualisieren; wobei das zu sichernde Kontobuch Informationen im Kontobuch des Planungsknotens darstellen, die nicht mit allen weiteren Knoten synchronisiert sind.
Wallet-System nach Anspruch 1, dadurch gekennzeichnet, dass der Kommunikationsknoten ferner verwendet wird, abhängig von dem Zahlungstransaktionsvorgang im Fall, dass die Zahlungstransaktionsinformation zu Transaktionsinformationen von Kryptowährung gehört, nach dem Abschluss des Zahlungstransaktionsvorgangs einen Transaktionsdatensatz zu generieren, um ein öffentliches Konto zu aktualisieren.
Wallet-System nach Anspruch 1, dadurch gekennzeichnet, dass das Wallet-System ferner einen geerbten Knoten umfasst, wobei die Anzahl von geerbten Knoten gleich wie die Anzahl von aufgegebenen Knoten ist; wobei die aufgegebenen Knoten einen aufgegebenen Kommunikationsknoten, einen aufgegebenen Planungsknoten und einen aufgegebenen Backup-Knoten umfassen; wobei ein geerbter Zielknoten dazu verwendet wird, als Antwort auf einen Befehl zur Benutzeranmeldung abhängig von einem Benutzernamen und einem Passwort eines der aufgegebenen Knoten eine Zuordnungsbeziehung mit einer in Cloud gespeicherten Vererbungsdatei herzustellen; wobei der geerbte Zielknoten ferner dazu verwendet wird, als Antwort auf einen Vererbungsbefehl des Benutzers die Cloud so zu steuern, dass sie die Vererbungsdatei an ein voreingestelltes soziales Konto des Benutzers zu senden, so dass Benutzer abhängig von der Vererbungsdatei jedem geerbten Knoten einen Benutzernamen, ein Passwort und einen privaten Schlüssel, die zu dem aufgegebenen Knoten korrespondieren, zuweist; wobei in der Vererbungsdatei der Benutzernamen, das Passwort und der private Schlüssel einzelner aufgegebenen Knoten aufgezeichnet sind.
Transaktionsverfahren basierend auf einem Wallet-System nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass es umfasst: ein Kommunikationsknoten generiert eine Transaktionsanforderung abhängig von einer empfangenen Zahlungstransaktionsinformation und sendet die Transaktionsanforderung an den Planungsknoten; ein Planungsknoten wählt als Antwort auf die Transaktionsanforderung mehrere Knoten als Signaturknoten aus; der Planungsknoten generiert nach einem Planen des privaten Schlüssels im Signaturknoten zum Signieren von einzelnen Zahlungstransaktionen eine Information zum erfolgreichen Signieren und sie an den Kommunikationsknoten zurückmeldet; der Kommunikationsknoten führt nach einem Empfangen der Information zum erfolgreichen Signieren einen Zahlungstransaktionsvorgang durch; ein Ersatzknoten erhält als Antwort auf einen von einem Benutzer eingegebenen Knotenersatzbefehl eine mit privatem Schlüssel verschlüsselte Datei eines designierten, zu ersetzenden Knotens aus der Cloud und generiert eine Knotenersatzanforderung, die an den Planungsknoten gesendet wird; der Planungsknoten plant als Antwort auf die Knotenersatzanforderung die privaten Schlüssel mehrerer anderer Knoten als des zu ersetzenden Knotens, um eine mit privatem Schlüsseln verschlüsselte Datei zu signieren, so dass der Ersatzknoten die mit privatem Schlüssel verschlüsselte Datei öffnet, um einen privaten Schlüssel des zu ersetzenden Knotens zu erhalten; wobei die mit privatem Schlüssel verschlüsselte Datei des zu ersetzenden Knotens durch das Verschlüsseln des privaten Schlüssels des zu ersetzenden Knotens mit privaten Schlüsseln mehrerer weiterer Knoten erhalten wird; der Ersatzknoten generiert nach einem Festlegen des privaten Schlüssels des zu ersetzenden Knotens als privaten Schlüssel seines eigenen Knotens eine Knotenänderungsinformation und sendet sie an den Planungsknoten, so dass der Planungsknoten eine Knotenplanung genau durchführen kann.