DE102021212599A1 - Schutz gegen Frontrunning-Angriffe in einem verteilten Register - Google Patents

Schutz gegen Frontrunning-Angriffe in einem verteilten Register Download PDF

Info

Publication number
DE102021212599A1
DE102021212599A1 DE102021212599.9A DE102021212599A DE102021212599A1 DE 102021212599 A1 DE102021212599 A1 DE 102021212599A1 DE 102021212599 A DE102021212599 A DE 102021212599A DE 102021212599 A1 DE102021212599 A1 DE 102021212599A1
Authority
DE
Germany
Prior art keywords
miner
distributed
transaction
transactions
block
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
DE102021212599.9A
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 DE102021212599.9A priority Critical patent/DE102021212599A1/de
Priority to US17/975,753 priority patent/US20230147925A1/en
Priority to CN202211390716.8A priority patent/CN116109410A/zh
Publication of DE102021212599A1 publication Critical patent/DE102021212599A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • 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
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • 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/04Payment circuits
    • G06Q20/06Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G06Q20/0655Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed centrally
    • 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/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401Transaction verification
    • 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/08Payment architectures
    • G06Q20/085Payment architectures involving remote charge determination or related payment systems
    • 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/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3678Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
    • 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/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • 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/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825Use of electronic signatures
    • 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/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401Transaction verification
    • G06Q20/4014Identity check for transactions
    • 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/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405Establishing or using transaction specific rules

Abstract

Einige Ausführungsformen sind auf ein computer-implementiertes Verfahren zum Unterhalten eines verteilten Registers durch einen ersten Miner gerichtet. Ein Satz von Transaktionen kann aus mehreren Transaktionsanforderungen gewählt werden und in einen neu erzeugten Block für ein verteiltes Register aufgenommen werden. Durch Bewerten der Einhaltung einer oder mehrerer Auswahlregeln kann eine Gütebewertung berechnet werden. Dem Miner können zu der ersten Gütebewertung eine Menge kryptografischer Token proportional zu der ersten Gütebewertung zugewiesen werden.

Description

  • Technisches Gebiet
  • Der vorliegend offenbarte Gegenstand betrifft ein computer-implementiertes Verfahren zum Unterhalten eines verteilten Registers, eine Server-Vorrichtung, eine Client-Vorrichtung und ein computer-lesbares Medium.
  • Hintergrund
  • Ein verteiltes Transaktionssystem, eine Transaktionsdatenbank oder ein verteiltes Register ist irgendein Protokoll in Computernetzen, das einen Konsens hinsichtlich seiner Transaktionen und ihrer Folge herbeiführt. Eine übliche Form eines derartigen Systems beruht auf einer Blockchain und bildet die Grundlage vieler sogenannter Kryptowährungen. In einer Kryptowährung werden kryptografische Token über mehrere Clients verteilt. Die Clients können die Token untereinander oder zu und von einem Market Maker übertragen. Kryptografie und verteilte Registersysteme stellen sicher, dass eine Übertragung nicht leicht gefälscht oder zurückgewiesen werden kann.
  • Die internationale Patentanmeldung WO 2019/043668 A1 offenbart eine bekannte Blockchain, in diesem Fall zum Verfolgen von Kryptowährungs-Token. Auf die Token bezogene Transaktionen wie etwa die Token-Erzeugung oder Token-Zerstörung sind in der Blockchain sichtbar.
  • Ein verteiltes Register wie etwa eine Blockchain stellt ein System mit sicherer Übertragung bereit. Dieses ermöglicht z. B., dass Token eines ersten Typs gegen Token eines zweiten Typs getauscht werden. Umgangssprachlich wird ein Token des ersten Typs gekauft und weist er einen Preis als eine Menge von Token des zweiten Typs auf. Fortgeschrittene Kryptowährungen verwenden einen als „gekrümmte Bindung“ [engl.: „Curved Bonding“] genannten Mechanismus, demgemäß algorithmisch eine als eine Bindungskurve bekannte Funktion definiert wird, die den Preis von Einheiten (Token) der Währung in Abhängigkeit von dem aktuellen Angebot an Token beeinflusst. Der Preis wird hier frei zur Angabe der Token verwendet, die getauscht werden, die nicht notwendig einen Geldwert aufweisen. Ein Token kann irgendeine beschränkte Ressource, z. B. den Zugriff auf Rechenressourcen oder dergleichen, repräsentieren und die Kryptowährung kann zum Regulieren des Zugriffs verwendet werden.
  • Das bekannte System offenbart das Managen einer Kryptowährung mit gekrümmter Bindung. In dem bekannten Verfahren wird für eine Mehrzahl von Benutzern ein Wallet im Markt bereitgestellt, das geeignet ist, verknüpfte digitale Token zu speichern, deren Wert mit Kryptowährungs-Token verknüpft ist und die für eine Transaktion in einer digitalen Marktplattform erforderlich sind. Es wird eine Kryptowährungsreserve bereitgestellt, die geeignet ist, eine Mehrzahl von Kryptowährungs-Token zu speichern. In Ansprechen darauf, dass ein Benutzer verknüpfte digitale Token von einem Marktgeschäft kauft, werden verknüpfte digitale Token zu dem Wallet des Benutzers im Markt übertragen und wird ein äquivalenter Wert von Kryptowährungs-Token an die Kryptowährungsreserve übertragen. In Ansprechen darauf, dass ein Benutzer eine Anzahl verknüpfter digitaler Token von dem Wallet des Benutzers im Markt abhebt, werden die gewünschte Anzahl verknüpfter digitaler Token aus dem Wallet des Benutzers im Markt entnommen und wird ein äquivalenter Wert von Kryptowährungs-Token aus der Kryptowährungsreserve an ein Wallet des Benutzers außerhalb des Markts übertragen, wobei das Wallet außerhalb des Markts geeignet ist, Kryptowährungs-Token außerhalb der Marktplattform zu speichern.
  • Zusammenfassung
  • Das bekannte System ist anfällig für Frontrunning-Angriffe. Ein Frontrunning-Angriff nutzt die technischen Eigenschaften des Systems für seine eigenen Zwecke.
  • Wenn ein Frontrunning einer Kauf- oder Verkaufstransaktion durchgeführt wird, könnten Miner und andere Akteure Wert von normalen Teilnehmern extrahieren. Es können zwei Klassen des Frontrunning unterschieden werden: Einerseits gibt es das kurzzeitige bis mittelfristige oder hochfrequente Frontrunning (hffr) - wobei die normalen Transaktionen nicht wesentlich verzögert werden, aber eine Angriffstransaktion in der Ausführungswarteschlange vor und direkt nach der normalen Transaktion bzw. den normalen Transaktionen platziert wird. Zum Beispiel könnte ein Miner im geheimen Einverständnis stehen und eine Transaktion am vorderen Ende der Warteschlange platzieren. Zum Beispiel kann ein Benutzer mit Kenntnis einer bevorstehenden großen Transaktion seiner Frontrunning-Transaktion eine hohe Transaktionsgebühr zuordnen, um den Miner dazu zu bringen, seine Transaktion zu priorisieren. Ein Miner ist eine elektronische Vorrichtung, üblicherweise in Form einer Server-Vorrichtung, die als ein Miner konfiguriert ist.
  • Dass ein Teil der Miner im geheimen Einverständnis stehen, kann bestimmte Transaktionen für eine längere Zeitdauer verzögern, was als aktive Zensur bezeichnet wird. Der entsprechende Angriff wird als zensurbasiertes Frontrunning (cfr) bezeichnet. Ein Beispiel wäre das Platzieren einer Kauftransaktion, daraufhin das Sperren aller Verkaufstransaktionen und nur das Zulassen von Kauftransaktionen, schließlich das Verkaufen und somit das Extrahieren des Werts vor der Verarbeitung der verzögerten Verkaufstransaktionen.
  • In verteilten Registern ist häufig akzeptiert, dass sowohl Miner als auch Clients die Reihenfolge von Transaktionen, hauptsächlich über die Höhe der einer Transaktionsanforderung zugeordneten Transaktionsgebühr, beeinflussen können - ein Client kann seine Transaktionsanforderung dadurch, dass er eine höhere Gebühr zuordnet, priorisieren, während ein Miner wahrscheinlich Transaktionsanforderungen mit einer höheren Transaktionsgebühr auswählt. Diese Flexibilität ermöglicht, dass Benutzer die Verarbeitung von Transaktionen beeinflussen - die Bezahlung für eine Tasse Kaffee erfordert keine schnelle Verarbeitung, während die Beteiligten für eine große Transaktion bevorzugen können, dass die Transaktion schnell abgeschlossen wird.
  • Leider macht es die Flexibilität, die den Einfluss auf die Reihenfolge der Verarbeitung von Zahlungen ermöglicht, akzeptabel und erwartet, dass eine Transaktion gelegentlich länger als üblich in der Reihe warten muss. Dies gibt die Gelegenheit für Angriffe. Ein Miner und insbesondere ein Satz im geheimen Einverständnis stehender Miner kann zunächst eine Kauftransaktion ausgeben und verarbeiten und danach für einige Zeit eine Verkaufstransaktion unterdrücken, worauf eine Verkaufstransaktion der Angreifer folgt. Somit klammern die Kauf- und die Verkaufsoperation eine Zeitdauer von Zensurtransaktionen ein.
  • Frontrunning-Angriffe liegen in einer ähnlichen Kategorie wie kryptografische Angriffe, Denial of Service und dergleichen. Die technischen Eigenschaften des Systems sind ausnutzend, um den Zwecken des Angreifers zu dienen. Derartige Zensurangriffe können durch nichttechnische Maßnahmen unterdrückt werden, wobei ein Miner z. B. durch Gesetz oder Vertrag verpflichtet werden kann, sich nicht an Zensur usw. zu beteiligen. Obwohl eine nichttechnische Lösung denkbar sein könnte, wird z. B. eine technische Lösung für das Problem bevorzugt. Der Erfinder hat erkannt, dass tatsächlich technische Maßnahmen möglich sind, um diese Arten von Angriffen zu mildern.
  • Falls ein Zensurangriff im Gang ist, kann eine Transaktion für eine bestimmte Zeitdauer nicht behandelt werden. Dadurch, dass die Gebühren gesenkt werden, die von Servern gesammelt werden, die keine alten Transaktionen voranbringen, kann die Teilnahme an dem Zensurangriff weniger attraktiv gemacht werden.
  • Zum Beispiel kann ein neuer Block des verteilten Registers einen Satz von Transaktionen enthalten, die aus mehreren Transaktionsanforderungen, die bei der Vorrichtung, z. B. der Server-Vorrichtung, z. B. dem Miner, empfangen wurden, gewählt werden. Zum Beispiel können sie von Clients oder von anderen Minern empfangen werden.
  • Der Miner, der den Block fertigstellt, der z. B. ein Konsens-Token in den Block aufnimmt, kann sich aus den verfügbaren Geldmitteln in Bezug auf einen neuen Block, z. B. der Summe neu geschürfter Token und Transaktionsgebühren, selbst ebenfalls eine Menge kryptografischer Token zuweisen; ein Teil kann an den Miner des Blocks übertragen werden, ein Teil kann woandershin zugewiesen werden. Zum Beispiel kann der Teil, der dem Miner nicht zugewiesen wird, in einem Pool, z. B. einem Wallet, deponiert werden. Auf einen derartigen Pool kann z. B. durch einen Regulator [engl.: „governor“], z. B. durch einen Administrator des verteilten Registers, zugegriffen werden. Wir viele Token verfügbar, z. B. geschürft, werden, wenn ein neuer Block geschürft wird, kann durch Chain-Logik bestimmt werden, kann aber ebenfalls durch einen Smart Contract bestimmt werden.
  • Gemäß einer Ausführungsform wird der Teil der Token, die beim Fertigstellen eines neuen Blocks zum Zuweisen verfügbar sind, aus einer ersten Gütebewertung berechnet.
  • Die Gütebewertung widerspiegelt, wie gut dieser Miner einen Satz von Auswahlregeln befolgt. Andere Miner können den Block nicht nur auf der Grundlage der Gültigkeit der Transaktionen oder der kryptografischen Konsistenz des Blocks, sondern auch auf der Grundlage der dem Miner zugewiesenen Token annehmen oder zurückweisen.
  • Insbesondere kann die Gütebewertung niedriger sein, falls ältere Transaktionsanforderungen nicht gewählt werden; insbesondere, falls ältere Transaktionsanforderungen mit hohen Transaktionsgebühren nicht gewählt werden. Die Güte kann z. B. dadurch berechnet werden, dass nicht gewählte Transaktionsanforderungen gezählt werden, die eine bestimmte Kombination aus Alter und Gebühren, wie sie z. B. durch eine Dringlichkeitsfunktion angegeben ist, aufweisen. In einem Sinn weiß ein Miner, der einen neuen Block empfängt und weiß, dass es alte Transaktionen gibt, die sinnvoll hätten gewählt werden sollen, wie es z. B. in einer Auswahlregel, z. B. unter Verwendung einer Dringlichkeitsfunktion, objektiv gemacht wird, dass der andere Miner - aus welchem Grund auch immer - die Reihenfolge der Transaktionen über das, was für ein flexibles System sinnvoll notwendig ist, hinaus manipuliert. Dadurch, dass der Block zurückgewiesen wird, empfängt der Miner, der den Block vorgeschlagen hat, nicht die zugeordnete Gebühr, die ihm in dem Block zugewiesen wird.
  • Es kann sein, dass Transaktionsanforderungen z. B., falls Transaktionsanforderungen auf Peer-to-Peer-Weise verteilt sind, an irgendeinem Punkt zwischen den Minern nicht vollständig synchronisiert sind. Allerdings sind ältere Transaktionsanforderungen üblicherweise synchronisiert, so dass dies die Berechnung der Gütebewertung wahrscheinlich nicht übermäßig beeinflusst. Allerdings kann dieses Problem durch Einführen einer Synchronisation der Transaktionsanforderungen, um z. B. eine vereinbarte Liste von Transaktionsanforderungen aufzubauen, gemildert werden. Dies kann durch das periodische Ausführen eines Synchronisationsprotokolls zwischen den Minern erreicht werden. Daraufhin können die Transaktionen für einen neuen Block nur aus vereinbarten Anforderungen gewählt werden. Die Synchronisation kann das Tauschen eine Ankunftszeit der Transaktionsanforderungen enthalten, so dass alle Miner das Alter der Transaktion überprüfen können.
  • Die Liste vereinbarter Transaktionsanforderungen kann in einem verteilten Register unterhalten werden, das dasselbe Register oder ein weiteres Register sein kann. Die Liste vereinbarter Transaktionsanforderungen kann exportiert werden, so dass eine Client-Vorrichtung überprüfen kann, ob ihre Transaktionsanforderungen in ihr enthalten ist.
  • Dass die Übertragung von Token zu einem Miner abhängig von seinem Verhalten gemacht wird, mildert die Zensur. Dies ist z. B. wichtig, falls Transaktionen mit einem Preis verknüpft sind, der sich mit dem Volumen von Kauf-/Verkaufsoperationen oder dergleichen ändert. Zum Beispiel tauscht eine Kryptowährung gemäß einer Ausführungsform, z. B. in einer Erzeugungsprozedur und Vernichtungsprozedur, Token einer ersten Art gegen Token einer zweiten Art und umgekehrt. In einer derartigen Ausführungsform kann die Tauschrate in dem System z. B. als eine Bindungskurve festgesetzt werden oder, z. B. durch Einführen einer Kauf-/Verkaufsmarge, von einer Bindungskurve abgeleitet werden. Die Preise von Token können ebenfalls außerhalb der direkten Kontrolle des verteilten Registersystems schwanken. Aus welchen Gründen sich die Tauschraten auch ändern, ist es erwünscht, dass zensurbasierte Angriffe gemildert werden.
  • Die Einführung einer Gütebewertung könnte mit anderen Maßnahmen, die Frontrunning weniger attraktiv machen, kombiniert werden. Zum Beispiel kann es eine Kauf-/Verkaufsmarge geben, so dass der Kaufpreis für ein Token höher als der Verkaufspreis ist. Dies macht einen Frontrunning-Angriff noch weniger effiziert.
  • Die Kombination einer Gütebewertung zusammen mit einer Kauf-Verkaufs-Marge ist besonders vorteilhaft, da sie allgemein durch irgendjemand vorgenommenes kurzzeitiges und/oder hochfrequentes Frontrunning ineffizient macht. Gleichzeitig erzwingt sie für zensurbasierte Angriffe einen notwendigen Zeitrahmen, damit der Angriff für den Angreifer wirtschaftlich vorteilhaft wird. Dieser Zeitrahmen wird über eine Kauf-Verkaufs-Marge groß, wobei dies aber der Gütebewertung die Zeit gibt, das anomale Verhalten des Miners aufzunehmen und einzuschreiten. Mit anderen Worten, eine Kauf-Verkaufs-Marge macht Angriffe wie etwa Zensurangriffe besser ‚sichtbar‘ und somit bestrafbar.
  • Eine Gütebewertung kann verwendet werden, um über Transaktionsgebühren ein gutes Verhalten zu erzwingen. Gemäß einer Ausführungsform können weitere Maßnahmen ausgelöst werden, falls die Güte unter einen Schwellenwert fällt. Derartige weitere Maßnahmen können z. B. das Verringern des Einsatzes, eine Gefängnisstrafe des Miners für eine bestimmte Zeitdauer enthalten.
  • Wenn ein Miner eine Gefängnisstrafe erhält, ist er eine Zeit lang als ein aktiver Miner ausgeschlossen. Dementsprechend kann er während dieser Zeit keine neuen Blöcke minen und keine neuen Token erhalten.
  • Zum Beispiel kann zusätzlich zum Zurückweisen des durch den mangelhaften Miner geminten Blocks (oder an dessen Stelle) ferner eine Bestrafungsroutine ausgelöst werden, falls eine Gütebewertung unter einen Schwellenwert fällt oder bestimmte Kriterien, wie sie z. B. in einem Smart Contract oder in einem Block dargelegt sind, nicht mehr erfüllt. Die Bestrafungsroutine kann in der Chain-Logik, im Registerprotokoll, im Smart Contract oder dergleichen definiert sein.
  • Eine Bestrafung auf der Grundlage einer berechenbaren Gütebewertung hat den Vorteil, dass sie durch den mangelhaften Miner selbst, aber auch durch irgendeinen anderen, z. B. an dem richtigen Management des Systems, interessierten Beteiligten leicht und objektiv überprüfbar ist. Dies vermeidet außerdem, dass ein Teil der Miner im geheimen Einverständnis stehen könnten, um einen Miner zu bestrafen, der die Bestrafungsroutine nicht verdient.
  • Es können strengere Maßnahmen als nur das Zurückweisen eines Blocks notwendig sein. Zum Beispiel wird ein Frontrunning-Angriff betrachtet, der viel Wert gewinnt. Dieser Wertgewinn kann viel größer als die üblichen Transaktionsgebühren sein und somit kann die Bestrafung über den Transaktionsgebührenanteil im Vergleich zu dem durch den Frontrunning-Angriff gemachten Gewinn vernachlässigbar sein. Durch Auslösen einer Bestrafungsroutine, z. B. automatisch oder manuell oder als ein Hybrid, kann dieses Verhalten vermieden werden.
  • Andere Elemente, die über die verspätete Behandlung oder Nichtbehandlung einer alten Transaktion hinaus in eine Gütebewertung eingehen können, können z. B. das nicht ausreichend häufige Überprüfen von Blöcken, das zu häufige offline Sein, das Berechnen falscher Werte in einem Block wie etwa kryptografischer Werte sein. Diese sind wichtige Metriken; falls ein Miner z. B. zu häufig offline ist, heißt das, dass es leichter wird, eine im geheimen Einverständnis stehende Mehrheit der verbleibenden Miner zu finden, was somit die Sicherheit des Gesamtsystems verringert.
  • Zum Beispiel kann ein Miner gemäß einer Ausführungsform eine Gütebewertung für einen anderen Miner berechnen und die Gütebewertung mit bestimmten Kriterien, z. B. einem Schwellenwert, vergleichen. Falls der Vergleich fehlschlägt, kann eine Bestrafungsroutine ausgelöst werden. Zum Beispiel müssen gemäß einer Ausführungsform eine bestimmte Anzahl weiterer Miner die Bestrafungsroutine ebenfalls auslösen.
  • Zum Beispiel können das Auslösen der Bestrafungsroutine und optional der Gütebewertung und/oder der Gütebewertungsberechnung, die zu ihr geführt haben, in einem Block des verteilten Registers veröffentlicht werden. Falls eine ausreichende Anzahl anderer Miner dasselbe tun, kann der Smart Contract die Bestrafungsroutine auslösen. Allerdings sind keine weiteren Miner notwendig, wobei z. B. der Smart Contract die Gütebewertung selbst neu berechnen und mit seinen eigenen Kriterien, um eine Auslösung oder Nichtauslösung der Bestrafungsroutine zu erreichen, vergleichen könnte.
  • Eine Gütebewertung kann eine Zahlenbewertung sein. Eine Gütebewertung kann mehrere Zahlenwerte umfassen. Ein Kriterium für die Gütebewertung kann sein, dass der Zahlenwert oder die Zahlenwerte über oder unter jeweiligen Schwellenwerten liegen. Zum Beispiel können verschiedene Werte verschiedene Aspekte der Güte, z. B. die Offline-Zeitdauer, den Rückstand alter Transaktionen und dergleichen, repräsentieren.
  • Die Kombination einer Kauf-Verkaufs-Marge, z. B. unterschiedlicher Preise für die Kauf- und Verkaufstransaktion, zusammen mit einer auf der Gütebewertung beruhenden Auslösung von Bestrafungen machen sowohl ein kurzfristiges als auch ein zensurbasiertes Frontrunning schwierig.
  • Gemäß einer Ausführungsform werden kryptografische Token eines ersten Typs durch einen Smart Contract unterhalten. Smart Contracts sind eine vorteilhafte Art und Weise, um in verteilten Registern, die Smart Contracts unterstützen, eine neue Kryptowährung zu erzeugen. Allerdings ist ein Smart Contract nicht notwendig. Zum Beispiel könnte ein Market Maker, der dieselben Prozeduren wie der Smart Contract implementiert, Teil der Chain-Logik, z. B. der Chain-Anwendungsschicht, sein. Selbst wenn der Smart Contract woanders implementiert ist, kann ein Benutzer die Prozeduren so aufrufen, als ob sie ein in dem Register definierter Smart Contract wären. Ausführungsformen, die einen Smart Contract verwenden, können dadurch, dass die Funktionen des Smart Contract in die Chain-Logik, z. B. in die Software, die das verteilte Register ausführt, aufgenommen werden, in eine Ausführungsform ohne einen Smart Contract umgewandelt werden. Der Smart Contract kann eine Erzeugungsprozedur für die Erzeugung kryptografischer Token eines ersten Typs im Tausch gegen kryptografische Token eines zweiten Typs implementieren. Zum Beispiel kann der Smart Contract eine Vernichtungsprozedur zum Vernichten kryptografischer Token eines ersten Typs im Tausch gegen kryptografische Token eines zweiten Typs implementieren. Die Token des zweiten Typs können eine anerkannte Kryptowährung, z. B. Bitcoin, Ether usw., sein. Außerdem kann der Smart Contract Informationen, die die Token des ersten Typs betreffen, insbesondere eine aktuelle Angebotsgröße, die eine aktuelle Anzahl von Krypto-Token des ersten Typs angibt, und eine Bindungskurve, die eine Funktion definiert, unterhalten.
  • Zum Beispiel kann die Menge von Krypto-Token des zweiten Typs für den Tausch durch Integrieren einer Funktion von der aktuellen Angebotsgröße bis zu einer neuen Angebotsgröße berechnet werden. Dabei ist die Funktion eine Summe der Bindungskurve und einer Anzahl weiterer Terme, wobei die weiteren Terme für die Erzeugungs- und/oder Vernichtungsprozedur einen Gebührenterm enthalten, der ein Mehrfaches der um eine Menge von Krypto-Token des ersten Typs verschobenen Bindungskurve umfasst.
  • Zum Beispiel kann die Integration über eine Erzeugungsfunktion erfolgen, während für die Vernichtung eine Vernichtungsfunktion verwendet werden kann, falls die Erzeugungsprozedur ausgelöst wird. Die Erzeugungsfunktion kann höher als die Vernichtungsfunktion sein. Zum Beispiel kann die Erzeugungsfunktion höher als eine Bindungskurve sein, während die Vernichtungsfunktion niedriger als eine Bindungskurve sein kann. Die Bindungskurve ist eine wachsende Funktion.
  • Ein Aspekt der Erfindung ist eine Server-Vorrichtung zum Unterhalten eines verteilten Registers. Die Server-Vorrichtung kann z. B. ein Miner sein. Ein Aspekt der Erfindung ist eine Client-Vorrichtung. Die Client-Vorrichtung kann z. B. von einem Benutzer verwendet werden, z. B., um das verteilte Register z. B. zum Senden von Transaktionsanforderungen zu verwenden. Falls in dem verteilten Register, möglicherweise unter Verwendung eines Smart Contract, eine weitere Kryptowährung erzeugt wird, können die Transaktionsanforderungen in dem Smart Contract Erzeugungs- oder Vernichtungsanforderungen initiieren.
  • In einem verteilten Register, das Smart Contracts ermöglicht, ist das Verhindern von Zensur besonders wichtig, da in dem verteilten Register irgendeine Anzahl von Kryptowährungen erzeugt werden könnten. Vorliegende Ausführungsformen lassen weiterhin Flexibilität bei der Auswahl von Anforderungen zu, während sie den Missbrauch mildern.
  • Ein weiterer Aspekt ist ein Verfahren zum Unterhalten eines verteilten Registers. Eine Ausführungsform des Verfahrens kann in einem Computer als ein computer-implementiertes Verfahren oder in dedizierter Hardware oder in einer Kombination beider implementiert werden. Ausführbarer Code für eine Ausführungsform des Verfahrens kann in einem Computerprogrammprodukt gespeichert sein. Beispiele von Computerprogrammprodukten enthalten Speichervorrichtungen, optische Ablagespeichervorrichtungen, integrierte Schaltungen, Server, Online-Software usw. Vorzugsweise umfasst das Computerprogrammprodukt nichttransitorischen Programmcode, der in einem computer-lesbaren Medium gespeichert ist, um eine Ausführungsform des Verfahrens auszuführen, wenn das Programm in einem Computer ausgeführt wird.
  • Gemäß einer Ausführungsform umfasst das Computerprogramm Computerprogrammcode, der dafür ausgelegt ist, alle oder einen Teil der Schritte einer Ausführungsform des Verfahrens auszuführen, wenn das Computerprogramm in einem Computer ausgeführt wird. Vorzugsweise ist das Computerprogramm in einem computer-lesbaren Medium verkörpert.
  • Ein weiterer Aspekt des vorliegend offenbarten Gegenstands ist ein Verfahren, um das Computerprogramm zum Herunterladen verfügbar zu machen.
  • Figurenliste
  • Weitere Einzelheiten, Aspekte und Ausführungsformen werden nur beispielhaft anhand der Zeichnungen beschrieben. Elemente in den Figuren sind zur Einfachheit und Klarheit dargestellt und brauchen nicht notwendig maßstabsgerecht zu sein. In den Figuren können Elemente, die bereits beschriebenen Elementen entsprechen, dieselben Bezugszeichen tragen; es zeigen schematisch:
    • 1a ein Beispiel einer Ausführungsform einer Client-Vorrichtung,
    • 1b ein Beispiel einer Ausführungsform einer Server-Vorrichtung,
    • 1c ein Beispiel einer Ausführungsform eines verteilen Registersystems,
    • 2 ein Beispiel einer Ausführungsform einer Blockchain,
    • 3a ein Beispiel einer Ausführungsform eines verteilen Registersystems,
    • 3b ein Beispiel einer Ausführungsform eines verteilen Registersystems,
    • 4 ein Beispiel einer Ausführungsform eines Verfahrens zum Unterhalten von Krypto-Token eines ersten Typs,
    • 5a ein computer-lesbares Medium mit einem beschreibbaren Teil, der ein Computerprogramm gemäß einer Ausführungsform umfasst,
    • 5b eine Darstellung eines Prozessorsystems gemäß einer Ausführungsform.
  • Bezugszeichenliste
  • Die folgende Liste von Bezugszeichen und Abkürzungen entspricht den 1a-3b, 5a, 5b und ist gegeben, um die Interpretation der Zeichnungen zu erleichtern, und ist nicht als Beschränkung der Ansprüche zu verstehen.
  • 100
    ein verteiltes Registersystem
    110, 110.1, 110.2
    eine Client-Vorrichtung
    130
    ein Prozessorsystem
    140
    ein Ablagespeicher
    150
    eine Kommunikationsschnittstelle
    160, 160.1, 160.2
    eine Server-Vorrichtung
    162
    eine Datenbank
    170
    ein Prozessorsystem
    180
    ein Ablagespeicher
    190
    eine Kommunikationsschnittstelle
    172
    ein Computernetz
    210
    eine Blockchain
    211-215
    ein Block
    220
    ein Smart Contract
    221
    eine Erzeugungsprozedur
    222
    eine Vernichtungsprozedur
    223
    eine Aktualisierungsprozedur
    231-234
    ein Zustand
    241-242
    eine Krypto-Token-Übertragung
    251-253
    ein Zeitpunkt
    300
    ein verteiltes Registersystem
    301-303
    eine Server-Vorrichtung
    311, 312
    eine Client-Vorrichtung
    320
    eine Peer-to-Peer-Übertragungsstrecke
    316
    eine Client-Server-Übertragungsstrecke
    331
    ein Transaktionsaggregator
    1000, 1001
    ein computer-lesbares Medium
    1010
    ein beschreibbarer Teil
    1020
    ein Computerprogramm
    1110
    eine bzw. mehrere integrierte Schaltungen
    1120
    eine Verarbeitungseinheit
    1122
    ein Speicher
    1124
    eine dedizierte integrierte Schaltung
    1126
    ein Kommunikationselement
    1130
    eine Verdrahtung
    1140
    ein Prozessorsystem
  • Beschreibung von Ausführungsformen
  • Obwohl der vorliegend offenbarte Gegenstand eine Ausführungsform in vielen verschiedenen Formen zulässt, sind in den Zeichnungen eine oder mehrere spezifische Ausführungsformen gezeigt und werden diese hier ausführlich beschrieben, wobei die vorliegende Offenbarung selbstverständlich als beispielhaft für die Prinzipien des vorliegend offenbarten Gegenstands anzusehen ist und nicht auf die spezifischen gezeigten und beschriebenen Ausführungsformen beschränkt werden soll.
  • Im Folgenden sind Elemente von Ausführungsformen zum Verständnis im Betrieb beschrieben. Allerdings sind die jeweiligen Elemente offenbar zum Ausführen von Funktionen, z. B. Prozeduren, ausgelegt, die als durch sie ausgeführt beschrieben werden.
  • Ferner ist der vorliegend offenbarte Gegenstand nicht nur auf die Ausführungsformen beschränkt, sondern enthält er außerdem jede weitere Kombination von Merkmalen, die hier beschrieben sind oder in voneinander verschiedenen abhängigen Ansprüchen angeführt sind.
  • 1a zeigt schematisch ein Beispiel einer Ausführungsform einer Client-Vorrichtung 110. 1b zeigt schematisch ein Beispiel einer Ausführungsform einer Server-Vorrichtung 160.
  • Zum Beispiel kann die Server-Vorrichtung 160 konfiguriert sein, ein verteiltes Register zu unterhalten. Die Server-Vorrichtung ist als ein Miner konfiguriert und wird gelegentlich als ein Miner oder als eine Mining-Vorrichtung oder als ein Schürfer oder als eine Schürfvorrichtung bezeichnet. Zum Beispiel kann der Server 160 konfiguriert sein, für das verteilte Register einen neuen Block zu erzeugen, der einen gewählten Satz von Transaktionen enthält. Die Transaktionen können durch die Server-Vorrichtung aus Transaktionen gewählt werden, die sie empfangen hat. Dem Miner sind eine gewisse Menge kryptografischer Token zugewiesen. Die Token können z. B. eine Kryptowährung sein. Die Kryptowährung kann z. B. mit dem verteilten Register verknüpft sein. Die Kryptowährung kann z. B. Bitcoin, Ether oder dergleichen sein.
  • Obwohl die Server-Vorrichtung, d. h. die Miner-Vorrichtung, die Freiheit hat, aus den der Server-Vorrichtung bekannten Transaktionsanforderungen Transaktionen zu wählen, besteht ein Interesse daran, die Auswahl innerhalb bestimmter Grenzen zu halten. Insbesondere ist es bevorzugt, falls Transaktionen nicht zu lange unverarbeitet gelassen werden. Zum Beispiel kann der Server konfiguriert sein, eine Gütebewertung zu berechnen, die ihm in Abhängigkeit von der Gütebewertung selbst Token zuweist. Beispiele sind hier gegeben.
  • Zum Beispiel kann die Client-Vorrichtung 110 konfiguriert sein, ein Wallet zu unterhalten. Zum Beispiel kann die Client-Vorrichtung 110 konfiguriert sein, an die Server-Vorrichtung 160 eine Transaktionsanforderung zu senden, um z. B. Token aus dem Wallet an ein weiteres Wallet zu übertragen. Wenn die Transaktion verarbeitet worden ist, wird sie in einem Block in dem verteilten Register widerspiegelt. Außerdem kann die Server-Vorrichtung 160, möglicherweise durch Ausführung einer Prozedur eines Smart Contract, Zugriff auf ein Wallet haben.
  • Die Client-Vorrichtung 110 kann ein Prozessorsystem 130, einen Ablagespeicher 140 und eine Kommunikationsschnittstelle 150 umfassen. Die Server-Vorrichtung 160 kann ein Prozessorsystem 160, einen Ablagespeicher 180 und eine Kommunikationsschnittstelle 190 umfassen. Die Ablagespeicher 140 und 180 können ein elektronischer Ablagespeicher sein. Der Ablagespeicher kann einen lokalen Ablagespeicher, z. B. ein lokales Festplattenlaufwerk oder einen elektronischen Speicher, umfassen. Der Ablagespeicher 140 und 180 kann einen nichtlokalen Speicher, z. B. einen Cloud-Speicher, umfassen. In dem letzteren Fall kann der Ablagespeicher 140 und 180 eine Ablagespeicherschnittstelle mit dem nichtlokalen Ablagespeicher umfassen.
  • Die Client-Vorrichtung 110 und die Server-Vorrichtung 160 können Teil eines verteilten Registersystems sein. Die Client-Vorrichtung 110 und die Server-Vorrichtung 160 können intern, mit anderen Systemen, mit einem externen Ablagespeicher, mit Eingabevorrichtungen, mit Ausgabevorrichtungen und/oder mit einem oder mehreren Sensoren über ein Computernetz kommunizieren. Das Computernetz kann ein Weitbereichsnetz, ein Intranet, ein LAN, ein WLAN usw. sein. Das Computernetz kann des Internet sein. Das System umfasst eine Verbindungsschnittstelle, die dafür ausgelegt ist, nach Bedarf innerhalb des Systems oder außerhalb des Systems zu kommunizieren. Zum Beispiel kann die Verbindungsschnittstelle einen Verbinder, z. B. einen verdrahteten Verbinder, z. B. einen Ethernet-Verbinder, einen optischen Verbinder usw., oder einen drahtlosen Verbinder, z. B. eine Antenne, z. B. eine WiFi-, eine 4G- oder eine 5G-Antenne, umfassen.
  • Die Kommunikationsschnittstelle 150 kann dafür verwendet werden, digitale Daten, z. B. Transaktionsanforderungen zum Übertragen kryptografischer Token, die z. B. eine Kryptowährung repräsentieren, und Anforderungen zum Ausführen von Erzeugungs- oder Vernichtungsprozeduren einer Kryptowährung zu senden oder zu empfangen; die Prozedur kann Bestandteil eines Smart Contract sein. Die Kommunikationsschnittstelle 190 kann verwendet werden, um digitale Daten, z. B. Transaktionsanforderungen zum Übertragen kryptografischer Token, zu senden oder zu empfangen. Die Kommunikationsschnittstelle 190 kann verwendet werden, um mit anderen Vorrichtungen zu kommunizieren, z. B., um einen neuen Block einer Blockchain zu verteilen oder um Transaktionsanforderungen zu synchronisieren.
  • Die Ausführung der Vorrichtungen 110 und 160 kann in einem Prozessorsystem, z. B. in einer oder mehreren Prozessorschaltungen, z. B. Mikroprozessoren, von denen Beispiele hier gezeigt sind, implementiert werden. Das Prozessorsystem kann eine oder mehrere GPUs und/oder CPUs umfassen. Die Vorrichtungen 110 und 160 des Systems 100 können mehrere Prozessoren umfassen, die über verschiedene Orte verteilt sein können. Zum Beispiel können die Vorrichtungen 110 und 160 Cloud-Computing verwenden.
  • Die Vorrichtungen 110 und 160 können Funktionseinheiten umfassen, die Funktionseinheiten des Prozessorsystems sein können. Zum Beispiel können die gezeigten Funktionseinheiten vollständig oder teilweise in Computeranweisungen implementiert sein, die in der Vorrichtung, z. B. in einem elektronischen Speicher der Vorrichtung, gespeichert sind und durch einen Mikroprozessor der Vorrichtung ausführbar sind. In Hybridausführungsformen werden Funktionseinheiten teilweise in Hardware, z. B. als Coprozessoren, z. B. als kryptografische Coprozessoren, implementiert und teilweise in Software gespeichert und in der Vorrichtung ausgeführt.
  • 1c zeigt schematisch ein Beispiel einer Ausführungsform eines verteilten Registersystems. Das System 100 umfasst mehrere Client-Vorrichtungen; wobei die Client-Vorrichtungen 110.1 und 110.2 gezeigt sind. Das System 100 umfasst mehrere Server-Vorrichtungen; wobei z. B. die Server-Vorrichtungen 160.1 und 160.2 gezeigt sind. Die Vorrichtungen sind über ein Computernetz 172, z. B. über das Internet, verbunden. Die Client- und die Server-Vorrichtung können gemäß einer Ausführungsform sein. Die Client-Vorrichtungen können miteinander zusammenwirken, um kryptografische Token zu übertragen. Die Client-Vorrichtungen können mit einer Server-Vorrichtung zusammenwirken, um ein kryptografisches Token von einem ersten Wallet an ein zweites Wallet zu übertragen. Eine Client-Vorrichtung kann anfordern, dass eine Server-Vorrichtung eine Erzeugungsprozedur ausführt, um neue Token eines Typs einer Kryptowährung, möglicherweise im Tausch gegen Token eines anderen Typs einer Kryptowährung, zu erzeugen. Eine Client-Vorrichtung kann anfordern, dass eine Server-Vorrichtung eine Vernichtungsprozedur zum Vernichten von Token des Typs einer Kryptowährung, möglicherweise im Tausch gegen Token des anderen Typs einer Kryptowährung, ausführt. Die Erzeugung wird gelegentlich als ein Kaufen bezeichnet, während die Vernichtung gelegentlich als Zerstören oder Verkaufen bezeichnet wird.
  • Der Ablagespeicher kann als ein elektronischer Speicher, angenommen ein Flash-Speicher, oder als ein magnetischer Speicher, angenommen eine Festplatte oder dergleichen, implementiert sein. Der Ablagespeicher kann mehrere diskrete Speicher umfassen, die zusammen den Ablagespeicher 140, 180 ergeben. Der Ablagespeicher kann einen temporären Speicher, angenommen einen RAM, umfassen. Der Ablagespeicher kann ein Cloud-Ablagespeicher sein.
  • Üblicherweise umfassen die Client-Vorrichtung 110 und die Server-Vorrichtung 160 jeweils einen Mikroprozessor, der geeignete Software ausführt, die in dem System gespeichert ist; wobei diese Software z. B. heruntergeladen und/oder in einem entsprechenden Speicher, z. B. einem flüchtigen Speicher wie etwa einem RAM oder einem nichtflüchtigen Speicher wie etwa einem Flash, gespeichert worden sein kann. Alternativ können die Systeme ganz oder teilweise in programmierbarer Logik, z. B. als eine frei programmierbare logische Anordnung (FPGA), implementiert sein. Die Systeme können ganz oder teilweise als eine sogenannte anwendungsspezifische integrierte Schaltung (ASIC), z. B. als eine integrierte Schaltung (IC), die für ihre bestimmte Verwendung nutzerangepasst ist, implementiert sein. Zum Beispiel können die Schaltungen in CMOS, z. B. unter Verwendung einer Hardwarebeschreibungssprache wie etwa Verilog, VHDL usw., implementiert sein. Insbesondere können die Client-Vorrichtung 110 und die Server-Vorrichtung 160 Schaltungen für die kryptografische Verarbeitung und/oder arithmetische Verarbeitung umfassen.
  • Eine Prozessorschaltung kann auf verteilte Weise, z. B. als mehrere Teilprozessorschaltungen, implementiert sein. Ein Ablagespeicher kann über mehrere verteilte Unterablagespeicher verteilt sein. Ein Teil oder der gesamte Speicher kann ein elektronischer Speicher, ein magnetischer Speicher usw. sein. Zum Beispiel kann der Ablagespeicher einen flüchtigen und einen nichtflüchtigen Teil aufweisen. Ein Teil des Ablagespeichers kann nur lesbar sein.
  • 2 zeigt schematisch ein Beispiel einer Ausführungsform einer Blockchain 210. Blockchains sind ein bestimmtes Beispiel für verteilte Register, von denen gezeigt worden ist, dass sie gemäß Ausführungsformen gut arbeiten. Andere Beispiele für verteilte Register können ebenfalls verwendet werden. Zum Beispiel kann das verteilte Register gemäß einer Ausführungsform ein Hash-Graph, ein Tangle oder ein Gitter sein. Das verteilte Register umfasst mehrere Blöcke, die miteinander verknüpft sind. Die Blöcke können Transaktionsdaten und Metadaten umfassen. Die Metadaten können Verknüpfungsinformationen und einen Konsensmechanismus umfassen. Ausführungsformen sind hauptsächlich mit Bezug auf eine Blockchain beschrieben, wobei aber eine derartige Ausführungsform geändert werden könnte, um einen anderen Typ eines verteilten Registers, insbesondere einen Graphen-basierten, zu verwenden.
  • Die Blockchain 210 umfasst mehrere Blöcke, die in einer Folge miteinander verknüpft sind. Die Verknüpfung kann z. B. einen Konsensmechanismus umfassen. Ein derartiger Mechanismus kann z. B. ein Proof of Work, z. B. wie in Bitcoin, sein. Der Mechanismus kann ein Proof of Stake sein. Ein Konsensmechanismus ermöglicht ein verteiltes Vertrauen in das verteilte Register. Gemäß einer Ausführungsform kann ein anderer Konsensmechanismus, z. B., wie er im Gebiet bekannt ist, verwendet werden.
  • Zur Hilfe bei der Diskussion zeigt 2 drei Punkte in der Blockchain: die Punkte 251, 252 und 253, die drei Zeitpunkten entsprechen. Beim Punkt 251 sind Blöcke bis zum Block 213, aber noch nicht der Block 213, erzeugt worden. Beim Punkt 252 sind Blöcke bis zum Block 214, aber noch nicht der Block 214, erzeugt worden. Beim Punkt 253 sind Blöcke bis zum Punkt 215, aber noch nicht der Block 215, erzeugt worden.
  • In der Blockchain 210 sind mehrere Blöcke, in diesem Fall 5 Blöcke, gezeigt: die Blöcke 211, 212, 213, 214 und 215. Es kann mehr oder weniger Blöcke geben. Ein Block kann Daten, die sich auf den Mechanismus eines verteilten Registers beziehen, z. B. Konsensdaten, aber ebenfalls andere Informationen umfassen. Insbesondere kann ein Block Transaktionen, in denen Token an eine Adresse gebunden sind, z. B. auf den öffentlichen Schlüssel eines Clients bezogen sind, der z. B. in einer Client-Vorrichtung enthalten ist, umfassen. Außerdem können Blöcke andere Informationen enthalten.
  • Ein Block in dem verteilten Register wird durch einen Miner erzeugt, der die Fähigkeit besitzt, die Konsensinformationen, sei es ein Proof of Stake oder ein Proof of Work oder dergleichen, zu erzeugen. Üblicherweise empfängt ein Miner, z. B. eine Server-Vorrichtung, z. B. direkt vom Benutzer oder von anderen Minern, die Transaktionen, die sie miteinander empfangen haben, gemeinsam nutzen, mehrere Transaktionen. Aus den empfangenen Transaktionen kann eine Auswahl getroffen werden, die wiederum in dem neuen Block der verteilten Blockchain enthalten ist. Ein Teil der Gesamtmenge der Kryptowährungs-Token, die dem neuen Block zugeordnet sind, z. B. Token, die durch die Erzeugung des Blocks selbst geschürft worden sind, und die den enthaltenen Transaktionen zugeordneten Transaktionsgebühren, können, z. B. in demselben Block, der gerade geschürft worden ist, an den Miner übertragen werden.
  • Das verteilte Register kann eine Kryptowährung implementieren. Zum Beispiel kann die Erzeugung neuer Blöcke ebenfalls neue Krypto-Token der Kryptowährung erzeugen. Üblicherweise empfangen die Miner die gesamte oder einen Teil der neu geschürften Kryptowährung. Die Krypto-Token werden mit einer bestimmten kryptografischen Identität, z. B. einer Adresse oder einem kryptografischen Schlüssel, verknüpft.
  • Interessant ist, dass dann, wenn ein verteiltes Register existiert, unter seiner Verwendung, z. B. unter Verwendung eines Smart Contract, weitere kryptografische Währungen erzeugt werden können. Zum Beispiel kann ein Block in dem verteilten Register einen Smart Contract umfassen. Der Block 211 zeigt ein Beispiel in Form eines Smart Contract 220. Üblicherweise ist ein Smart Contract in einer Computersprache geschrieben. Ein Beispiel einer Computersprache, die für Smart Contracts optimiert ist, ist Solidity. Zum Beispiel kann die Blockchain 210 gemäß einer Ausführungsform die Ethereum-Blockchain sein und kann der Smart Contract in Solidity geschrieben sein. Allerdings ist es nicht erforderlich, auf eine bestimmte Sprache oder Blockchain zu beschränken. Zum Beispiel kann die Ethereum-Blockchain verwendet werden, wie sie in der Abhandlung „Ethereum: a secure decentralised generalised transaction ledger“ von G. Wood, z. B. die Istanbul-Version 80085f7 vom 11.07.2021, beschrieben ist.
  • Zum Beispiel kann gemäß einer Ausführungsform ein zum Unterhalten von Krypto-Token eines ersten Typs konfigurierter Server konfiguriert sein, den Smart Contract von dem verteilten Register zu erhalten. Der Smart Contract kann z. B. in einem Block des verteilten Registers gespeichert sein. Der Smart Contract kann die notwendigen Prozeduren, z. B. eine Erzeugungsprozedur zum Erzeugen der Krypto-Token des ersten Typs und eine Vernichtungsprozedur für die Vernichtung von Krypto-Token des ersten Typs, implementieren. Der Smart Contract kann konfiguriert sein, die aktuelle Angebotsgröße zu unterhalten. Der Smart Contract kann eine Bindungskurve definieren.
  • Gemäß einer Ausführungsform wird die Blockchain 210 zum Erzeugen und Vernichten kryptografischer Token eines ersten Typs verwendet. Umgangssprachlich wird das Erzeugen neuer kryptografischer Token gelegentlich als ‚Kaufen‘ der Token bezeichnet; das Vernichten eines kryptografischen Tokens wird gelegentlich als ‚Verkaufen‘ der Token bezeichnet.
  • Der Smart Contract implementiert mehrere Prozeduren, einschließlich wenigstens einer Erzeugungsprozedur 221 und einer Vernichtung 222 (auch eine Verkaufsprozedur genannt). Optional kann der Contract eine Aktualisierungsprozedur 223 implementieren. Umgangssprachlich wird die Erzeugungsprozedur ebenfalls eine Kaufprozedur und die Vernichtungsprozedur 222 eine Verkaufsprozedur genannt. Dies ist nicht ganz genau, da die Token üblicherweise nicht mehr vorhanden sind, wenn sie vernichtet worden sind. Das Gesamtangebot von Token nimmt nach einer Vernichtungsaktion ab. Die Vernichtungsprozedur wird ebenfalls als eine Zerstörungsprozedur bezeichnet.
  • Der Server führt die Erzeugungsprozedur aus und erhält als Ergebnis einen neuen Zustand. Der neue Zustand kann z. B. die erhöhte Anzahl von Krypto-Token eines ersten Typs, die nun vorhanden sind, (als das Angebot bezeichnet) widerspiegeln. Außerdem kann der Server eine Transaktion, die angibt, dass die neuen kryptografischen Token an den ersten Benutzer übertragen werden, und/oder eine Transaktion, die angibt, dass die vorhandenen kryptografischen Token des zweiten Typs von dem ersten Benutzer an ein dem Smart Contract zugeordnetes Wallet übertragen werden, erhalten. Der Smart Contract wird als der Market Maker bezeichnet. Eine Menge von Token des zweiten Typs können durch den Market Maker, z. B. im Wallet, in Reserve gehalten werden. Dieser Teil des Wallets wird als der Pool oder Pool-Saldo bezeichnet. Dasselbe Wallet kann verwendet werden, um Token zu halten, die nicht Teil des Pools sind. Die Verwendung dieses Wallets kann auch nur für den Pool reserviert werden.
  • Der Server-Client schreibt in die Blockchain, enthält z. B. in einem Block den neuen Zustand und die neuen Krypto-Token des ersten Typs, wobei die übertragenen Krypto-Token des zweiten Typs in diese oder in eine andere Blockchain geschrieben werden. Token des ersten Typs und des Zustands können ebenfalls in getrennte Blockchains gelegt werden.
  • Es wird angenommen, dass ein erster Benutzer eine Anzahl von Krypto-Token eines ersten Typs kaufen möchte. Er sendet über eine Client-Vorrichtung eine Anforderung an eine Server-Vorrichtung. Die Anforderung kann an mehrere Server-Vorrichtungen gesendet werden. Die Anforderung kann z. B. Folgendes enthalten:
    • ◯ die Menge x angeforderter Krypto-Token eines ersten Typs
    • ◯ Anweisungen zum Übertragen von y Krypto-Token eines zweiten Typs
    • ◯ eine Adresse, um die Krypto-Token eines ersten Typs an sie zu binden.
  • Zum Beispiel wird betrachtet, dass die Anforderung am Punkt 252, unmittelbar, bevor der Block 214 erzeugt wird, gesendet wird.
  • Die Server-Vorrichtung liest den Smart Contract 220 aus der Blockchain aus. Der Smart Contract verwendet einen Zustand, der aktualisiert werden kann. Die Server-Vorrichtung liest den aktuellen Zustand aus der Blockchain aus. Die Blockchain 210 zeigt die Zustände 231 und 232 vor dem Punkt 252, so dass die Server-Vorrichtung den Zustand 232 ausliest.
  • Um die Menge kryptografischer Token des zweiten Typs (y) zu bestimmen, die gegen eine Menge kryptografischer Token des ersten Typs (x) getauscht werden, umgangssprachlich als der Preis bezeichnet, verwendet der Smart Contract eine Bindungskurve. Der Smart Contract kann eine Definition der Bindungskurve umfassen. Die Definition der Bindungskurve kann ebenfalls in einem Zustand sein. Die Definition der Bindungskurve kann der Smart Contract sein, bis sie eine neue Definition in einem geschriebenen Zustand überschreibt. Es wird angemerkt, dass eine Bindungskurve üblicherweise wachsend oder wenigstens nicht fallend ist.
  • Gemäß einer Ausführungsform ist der Smart Contract nicht in einem Block gespeichert, sondern für den Server über andere Mittel zugreifbar; z. B. kann der Smart Contract vor dem Ausführen der Prozeduren erhalten werden. Die Verwendung eines Smart Contract kann den Vorteil haben, dass ein Beweis für die Ausführung, z. B. irgendeiner bestimmten Prozedur, in dem verteilten Register angeordnet werden kann. Es wird angemerkt, dass selbst dann, wenn in der Chain kein Smart Contract angeordnet ist, er immer noch als einer ausgeführt werden kann, sofern andere Miner Zugriff auf seinen Code haben.
  • Tatsächlich brauchen die Prozeduren nicht einmal in einem Smart Contract implementiert zu sein, sondern können sie in herkömmlicher Software implementiert sein. Zum Beispiel kann derartige Software durch den Server vor der Ausführung erhalten werden. Die Software kann Teil der Chain-Logik-Software sein, die die Mining-Operation definiert hat.
  • Gemäß einer Ausführungsform könnte der Market Maker, z. B. der Smart Contract oder andere Software, Teil der Chain-Anwendungsschicht sein. Ein Benutzer kann die Prozeduren wie in einem Smart Contract aufrufen.
  • Falls kein Smart Contract verwendet wird, kann das Wallet oder der Pool, das bzw. der dem Smart Contract zugeordnet ist, durch ein Wallet oder einen Pool, das bzw. der dem Market Maker zugeordnet ist, z. B. durch die Software, die die Kryptowährung implementiert, ersetzt werden.
  • Es wird angemerkt, dass Kryptowährungen mit oder ohne einen Smart Contract erzeugt werden können. Es sind keine Erzeugungs- oder Vernichtungsprozeduren notwendig. Die Kryptowährung kann z. B. durch die Chain-Logik, z. B. die Software, die das verteilte Register definiert, unterhalten werden. Falls das verteilte Register allerdings für Smart Contracts konfiguriert ist, wird eine gerechte Verarbeitung der Transaktionen noch wichtiger. In einem derartigen verteilten Register können eine potentiell unbegrenzte Anzahl von Kryptowährungen definiert werden und kann sich jede von ihnen auf die gerechte Verarbeitung von Transaktionen stützen und sind sie potentiell anfällig für Frontrunning-Angriffe.
  • Außerdem wird angemerkt, dass sich Transaktionen in einer Chain auf die Übertragung einer Kryptowährung, ob durch einen Smart Contract definiert oder nicht, beziehen können, aber ebenfalls auf eine andere Transaktion beziehen können. Verteilte Register können verwendet werden, um alle Arten von Informationen sicher zu speichern.
  • Zur Vollständigkeit kann ein computer-implementiertes Verfahren zum Unterhalten von Krypto-Token eines ersten Typs in einem verteilten Register Folgendes umfassen:
    • - Erzeugen von Krypto-Token des ersten Typs im Tausch gegen Krypto-Token des zweiten Typs und Vernichten von Krypto-Token des ersten Typs im Tausch gegen Krypto-Token des zweiten Typs, Unterhalten einer aktuellen Angebotsgröße in dem verteilten Register, die eine aktuelle Anzahl von Krypto-Token des ersten Typs angibt. Das Erzeugen, Vernichten usw. kann in der Chain-Logik definiert sein oder kann in einem Smart-Contract definiert sein, z. B. in einem Block des verteilten Registers gespeichert sein. Falls eine Bindungskurve verwendet wird, kann die Menge der Krypto-Token des zweiten Typs für den Tausch durch Integrieren einer Funktion von der aktuellen Angebotsgröße bis zu einer neuen Angebotsgröße berechnet werden. Die Funktion kann die Bindungskurve oder davon abgeleitet, z. B. eine Bindungskurve und ein Gebührenterm, sein. Die Server-Vorrichtung kann z. B. für die Erzeugung, z. B., wie sie in einer Erzeugungsprozedur definiert ist, eine Menge von Krypto-Token des zweiten Typs an einen Pool übertragen und die Menge der Krypto-Token des ersten Typs, z. B. an ein Wallet, übertragen und die aktuelle Angebotsgröße um die Menge von Krypto-Token des ersten Typs erhöhen. Um z. B., wie in einer Vernichtungsprozedur definiert ist, zu vernichten, kann die Server-Vorrichtung z. B. die Menge von Krypto-Token des zweiten Typs aus einem Pool übertragen und die Menge von Krypto-Token des ersten Typs ungültig machen und die aktuelle Angebotsgröße um die Menge von Krypto-Token des ersten Typs verringern und die Menge von Krypto-Token des ersten Typs ungültig machen.
  • 3a zeigt schematisch ein Beispiel einer Ausführungsform eines verteilten Registersystems 300.
  • Das verteilte Registersystem 300 umfasst mehrere Server-Vorrichtungen. Die Server-Vorrichtungen sind als Miner für das verteilte Registersystem konfiguriert; die Server-Vorrichtungen sind zum gültigen Erzeugen neuer Blocks des verteilten Registers konfiguriert. In 3a sind drei Server-Vorrichtungen gezeigt: die Server-Vorrichtungen 301, 302 und 303. Es kann zwei Server-Vorrichtungen geben; es kann mehr als drei Server-Vorrichtungen geben.
  • Das verteilte Registersystem 300 umfasst mehrere Client-Vorrichtungen. Die Client-Vorrichtungen sind als Clients für das verteilte Registersystem konfiguriert; die Client-Vorrichtungen sind zum Senden von Transaktionsanforderungen an eine Server-Vorrichtung konfiguriert. Eine Transaktionsanforderung kann die Übertragung eines Krypto-Tokens, z. B. eines Kryptowährungs-Tokens, aus einem Wallet zu einem anderen anfordern, z. B., um das Token von einer Adresse zu einer anderen zuzuordnen, z. B., um es von einem kryptografischen Schlüssel zu einem anderen zuzuordnen. In 3a sind zwei Client-Vorrichtungen gezeigt: die Client-Vorrichtungen 311 und 312. Es kann mehr als zwei Client-Vorrichtungen geben.
  • Die Server-Vorrichtungen und die Client-Vorrichtungen sind elektronische Vorrichtungen, sie können z. B. einen Computer umfassen.
  • Die Server-Vorrichtungen sind miteinander verbunden. Dies kann z. B. unter Verwendung eines Peer-to-Peer-Netzes erfolgen. 3a zeigt Peer-to-Peer-Übertragungsstrecken 320, in diesem Fall zwischen den Server-Vorrichtungen 301 und 302 und zwischen den Server-Vorrichtungen 302 und 303. Es kann Server-Vorrichtungen, zwischen denen es keine Direktverbindung gibt, z. B. zwischen den Server-Vorrichtungen 301 und 303, geben.
  • Die Client-Vorrichtungen sind mit einer Client-Server-Übertragungsstrecke 311 mit Server-Vorrichtungen verbunden. Wie in 3a gezeigt ist, ist z. B. die Client-Vorrichtung 311 mit der Server-Vorrichtung 301 verbunden und die Client-Vorrichtung 312 mit der Server-Vorrichtung 302 verbunden. Beide Client-Server-Übertragungsstrecken und die Peer-to-Peer-Übertragungsstrecken können unter Verwendung eines Computernetzes, z. B. des Internet, implementiert sein.
  • Eine Client-Vorrichtung kann zum Senden einer Transaktionsanforderung an eine Server-Vorrichtung konfiguriert sein. Eine Server-Vorrichtung ist zum Empfangen mehrerer Transaktionen für die Aufnahme in das verteilte Register konfiguriert. Die Server-Vorrichtung kann eine Transaktionsanforderung direkt von einem Client empfangen; z. B. kann die Server-Vorrichtung 301, z. B. über die Verbindung 316, eine Transaktionsanforderung direkt von der Client-Vorrichtung 311 empfangen. Allerdings kann die Server-Vorrichtung ebenfalls ein Peer-to-Peer-Synchronisationsprotokoll implementieren. Zum Beispiel kann eine erste Server-Vorrichtung die Transaktionen, die sie von einer Client-Vorrichtung empfangen hat, an eine zweite Server-Vorrichtung senden.
  • Zum Beispiel kann eine Transaktionsanforderung, die die Server-Vorrichtung 301 von der Client-Vorrichtung 311 empfangen kann, durch die Server-Vorrichtung 301 an die Server-Vorrichtung 302 und wiederum an die Server-Vorrichtung 303 weitergeleitet werden. Es wird angemerkt, dass die Server-Vorrichtungen 301 und 303, obwohl sie keine direkte Übertragungsstrecke aufweisen, dennoch Transaktionsanforderungen auf Peer-to-Peer-Weise austauschen können. Gemäß einer Ausführungsform werden Transaktionsanforderungen auf eine dezentrale Weise empfangen. Ein Nachteil dieser Vorgehensweise ist, dass der Pool potentieller Transaktionen, die in einem Block aufzunehmen sind, nicht jederzeit für alle Miner dieselbe ist. Lösungen dieses Problems sind im Folgenden dargestellt.
  • Ein Vorteil der Peer-to-Peer-Vernetzung ist, dass die Topologie des Netzes nicht vorgegeben zu sein braucht. Solange jede Server-Vorrichtung eine oder mehrere Computeradressen anderer Server-Vorrichtungen kennt, z. B. speichert, und während das Netz verbunden bleibt, bleibt vollständige Konnektivität möglich. Anstelle eines Peer-to-Peer-Netzes könnte eine alternative Kommunikationstechnologie verwendet werden. Zum Beispiel könnte das Netz vollständig mit jeder Server-Vorrichtung verbunden sein, die mit jeder anderen Server-Vorrichtung kommuniziert. Zum Beispiel könnte das Netz zentralisiert sein. Zum Beispiel kann es eine Transaktionsanforderung oder einen neuen Block usw., um sie zu verteilen, an eine zentrale Server-Vorrichtung senden, die sie wiederum an die anderen Server-Vorrichtungen verteilt.
  • Eine Server-Vorrichtung ist konfiguriert, einen neuen Block für das verteilte Register zu erzeugen. Hierfür wählt die Server-Vorrichtung aus den mehreren Transaktionsanforderungen, die sie empfangen hat, einen Satz von Transaktionen aus. Der Satz von Transaktionen ist, möglicherweise nach etwas Neuformatierung oder nach etwas Neuschreiben, in einem Block enthalten. Eine Transaktion und eine Transaktionsanforderung können enthalten, welches Token von welcher Adresse an welche andere Adresse übertragen werden soll. Eine Transaktion kann ebenfalls mit einem Smart Contract in Beziehung stehen. Zum Beispiel kann eine Transaktionsanforderung eine Erzeugungsprozedur oder eine Vernichtungsprozedur eines Smart Contract auslösen. Für Kryptowährungen, die über einen Smart Contract erzeugt werden, sind Frontrunning-Angriffe ebenfalls eine Bedrohung.
  • Ferner enthält die Server-Vorrichtung in dem Block ein Konsens-Token. Das Konsens-Token hängt von dem bestimmten Typ des verteilten Registers ab, wobei es z. B. die Lösung zu einem kryptografischen Problem, z. B. in einem Proofof-Work-System (PoW) sein kann, oder wobei es ein Konsens-Token sein kann, um einen Proof of Stake (PoS) oder einen Proof of Authority (PoA) zu zeigen. Der Block kann ferner die Server-Vorrichtung, z. B. den Miner, der den Block erzeugt hat, angeben, wobei z. B. eine digitale Signatur der Server-Vorrichtung enthält.
  • Der Miner kann sich ebenfalls selbst eine Menge von Krypto-Token zuweisen. Ebenfalls abhängig von dem bestimmten Typ des verteilten Registers gibt es verschiedene Optionen, woher diese Token kommen. Zum Beispiel kann durch Mining eines neuen Blocks des verteilten Registers, z. B. einer Blockchain, eine Menge der Kryptowährung, z. B. wie in Bitcoin, erzeugt werden. Alles oder ein Teil dieser Menge der Kryptowährung kann der Servervorrichtung, z. B. dem Miner, der den Block erzeugt hat, zugewiesen werden. Eine zweite Quelle der Kryptowährung kann von den Transaktionen selbst kommen. Einer Transaktionsanforderung kann eine Transaktionsgebühr zugeordnet sein. Die gesamte Gebühr oder ein Teil davon kann der Server-Vorrichtung zugewiesen sein, die den neuen Block durch Mining geschürft hat. Transaktionen können ebenfalls Teil der Ausführung von Smart Contracts sein. Die Ausführung von Smart Contracts geht ebenfalls mit Transaktionsgebühren einher, die alle oder teilweise der Server-Vorrichtung zugewiesen sein können, die die Ausführung ausführt und einen Beweis dafür in dem neu erzeugten Block liefert.
  • Üblicherweise hat eine Server-Vorrichtung beim Wählen der in einen Block aufzunehmenden Transaktion eine Freiheit. Dies kann z. B. vorteilhaft sein, falls nicht alle Server-Vorrichtungen Zugriff auf dieselben Transaktionen haben. In einem derartigen Fall könnte eine Transaktion nicht einfach gewählt werden, da die Server-Vorrichtung nichts von ihr weiß. Eine Server-Vorrichtung kann ebenfalls Transaktionen, die eine größere Gebühr tragen, priorisieren. Dies ist an sich nicht notwendig schlecht. Falls eine Transaktion schnell ausgeführt werden sollte, kann ihr ein Benutzer eine hohe Transaktionsgebühr zuordnen, so dass sie schnell aufgenommen wird. Falls die Ausführung einer Transaktion nicht besonders dringlich ist, kann eine niedrigere Transaktionsgebühr zugewiesen werden. Dies kann bedeuten, dass es länger dauert, bevor sie eine Server-Vorrichtung aufnimmt, dass die Kosten aber niedriger sind.
  • Leider setzt eine vollständig freie Auswahl von Transaktionen das verteilte Registersystem einer als zensurbasiertes Frontrunning bekannten Klasse von Angriffen aus. Beim Frontrunning klammert ein Angriff eine Kauf- und eine Verkaufstransaktion um eine Folge von Kauftransaktionen ein. Die Folge von Kauftransaktionen treibt den Preis der Kryptowährung nach oben, so dass die nachfolgende Verkaufstransaktion des Angreifers in den Klammerkosten einen höheren Preis als die Kauftransaktion des Angreifers gewinnt. Um den Angriff auszuführen, muss der Angreifer wissen, dass eine Folge von Kauftransaktionen oder wenigstens eine Folge hauptsächlicher Kauftransaktionen bevorsteht. Dies kann erreicht werden, falls eine Server-Vorrichtung oder sogar mehrere Server-Vorrichtungen illegal vereinbaren, eine Weile keine Verkaufstransaktion zu wählen. Wenn die klammernde Verkaufstransaktion verarbeitet worden ist, wird der Rückstand an Verkaufstransaktionen behandelt.
  • Mit anderen Worten, Server-Vorrichtungen können ihre Macht ausnutzen, um Transaktionen für die Aufnahme in einen neuen Block dafür zu wählen, Angriffe in dem verteilten Registersystem zu ermöglichen. Diese Angriffe halten viele Typen einer Kryptowährung, so lange der Preis eines Tokens mit dem Bedarf steigt, kann ein Zensur-Frontrunning-Angriff ausgeführt werden. Insbesondere ist der Angriff gegen eine auf einer Bindungskurve beruhende Kryptowährung, z. B. eine, die in einem Smart Contract oder in einer Chain-Logik implementiert ist, möglich. Der Preis einer mit einer Bindungskurve verknüpften Kryptowährung ist mit dem Volumen existierender Token verknüpft, so dass eine Folge von Kauftransaktionen (oder Erzeugungstransaktionen) im Ergebnis einen höheren Preis hat.
  • Zensurgestütztes Frontrunning kann dadurch gemildert werden, dass es für Server-Vorrichtungen weniger attraktiv gemacht wird, an einem solchen Angriff teilzunehmen. Zum Beispiel können die kryptografischen Token, die einer Server-Vorrichtung zugewiesen werden, um einen neuen Block erfolgreich fertigzustellen, gemäß einer Ausführungsform von einer Gütebewertung abhängen. Die Gütebewertung kann durch eine Servervorrichtung dadurch berechnet werden, dass ihre Einhaltung einer oder mehrerer Auswahlregeln bewertet wird. Die Auswahlregeln geben an, wie Transaktionen für einen neuen Block des verteilten Registers gewählt werden sollten, oder geben Schranken an, welche Transaktionen gewählt werden sollten.
  • Wenn ein Block fertiggestellt wird, ordnet die Server-Vorrichtung einen Teil der verfügbaren Gebühren für den Block auf der Grundlage der Güte dieses Miners sich selbst zu. Die verbleibenden Token können, entweder implizit oder explizit, anderswo zugeordnet werden. Das verteilte Register kann z. B. konfiguriert sein, dass alle nicht zugeordneten Token automatisch in einem Pool, z. B. einem Wallet, gesammelt werden. Zum Beispiel kann der Miner die verbleibenden Token explizit anderswo, z. B. dem Pool, einem Wallet zuordnen, sie an die Initiatoren der Transaktionen zurückgeben.
  • Wenn der Block fertiggestellt ist, kann der neue Block an einen oder mehrere weitere Miner übertragen werden. Angenommen z. B., die Server-Vorrichtung 301 hat einen Block fertiggestellt, dann kann sie den Block an die Server-Vorrichtung 302 senden, die ihn schließlich an die Server-Vorrichtung 303 sendet. Eine direkte oder zentralisierte Kommunikation ist ebenfalls möglich.
  • Gemäß einer Ausführungsform könnte eine Server-Vorrichtung einen größeren Teil der verfügbaren Gebühren sich selbst zuordnen, wobei dies aber durch die anderen Server-Vorrichtungen abgefangen und korrigiert werden kann.
  • Zum Beispiel wird angenommen, dass ein erster Miner, angenommen die Server-Vorrichtung 301, einen neuen Block berechnet, einschließlich dessen, dass er Token sich selbst zuweist. Wenn der Block durch andere Server-Vorrichtungen empfangen wird, überprüfen sie die Transaktionen in dem Block, z. B., ob die Transaktion gültige Übertragungen von Token, z. B. von einem ersten Wallet zu einem zweiten Wallet, repräsentiert oder eine gültige Ausführung eines Smart Contract oder einen Teil einer gültigen Ausführung repräsentiert. Eine Server-Vorrichtung, angenommen die Server-Vorrichtung 302, die einen vermuteten neuen Block empfängt, überprüft ebenfalls, ob die durch ihren Miner, z. B. die Server-Vorrichtung 301, zugewiesenen Token gerechtfertigt sind, insbesondere durch ihre Gütebewertung gerechtfertigt sind. Falls eine der Überprüfungen, z. B. die der Transaktionsgültigkeit oder die der zugewiesenen Token, fehlschlägt, wird der Block zurückgewiesen.
  • Die Gütebewertung kann durch den Miner, z. B. die Server-Vorrichtung, die einen neuen Block erzeugt, sowie durch einen Miner, der den neuen Block überprüft, berechnet werden. Die Gütebewertung gibt die Einhaltung von Auswahlregeln des Miners, der den neuen Block erzeugt hat, an. Die Auswahlregeln geben an, wie Transaktionen für einen neuen Block aus den für den Miner für die Aufnahme verfügbaren Transaktionen gewählt werden sollen. Zum Beispiel kann eine Auswahlregel erfordern, dass eine Transaktionsanforderung, die älter als ein erster Schwellenwert ist und eine Transaktionsgebühr aufweist, die höher als ein zweiter Schwellenwert ist, gewählt werden sollte. Zum Beispiel kann eine Auswahlregel erfordern, dass eine Transaktionsanforderung gewählt werden sollte, die älter als ein erster Schwellenwert ist und eine Transaktionsgebühr besitzt, die wenigstens so hoch wie irgendeine nicht gewählte jüngere Transaktionsanforderung ist. Die Anzahl verletzter Regeln kann in Richtung einer Strafe gezählt werden. Zum Beispiel kann die Anzahl von Strafen ein Prozentsatz sein, der die zugeordneten Token verringert, usw.
  • Zusätzlich zu Auswahlregeln kann es weitere Regeln geben, die den Teil der Token, die für einen Miner verfügbar sind, angeben. Zum Beispiel kann eine Regel eine gewünschte Betriebszeit, eine Dienstqualität, eine maximale Latenzzeit zum Erzeugen eines neuen Blocks einstellen. Derartige Regeln können Güteregeln genannt werden, von denen Auswahlregeln ein besonders wichtiges Beispiel sind.
  • Die Güteregeln können in der Software, die die Server-Vorrichtungen reguliert, z. B. in der Chain-Logik, eingestellt werden. Die Güteregeln können im Prinzip festgesetzt sein, obwohl sie durch Aktualisieren der Software der Server-Vorrichtungen geändert werden können. Die Güteregeln können veröffentlicht werden und für die Server-Vorrichtungen verfügbar sein. Insbesondere können die Güteregeln in einem Block des verteilten Registers verteilt werden. Zum Beispiel können die Güteregeln durch einen Smart Contract eingestellt werden. Die Güteregeln können z. B. durch einen Regulator des Systems oder durch den Smart Contract geändert werden. Zum Beispiel können neue Güteregeln in einem neuen Block des verteilten Registers veröffentlicht werden. Neue Regeln können durch einen Smart Contract automatisch veröffentlicht werden. Zum Beispiel kann ein Smart Contract zum Einstellen vorhandener Regeln ausgelöst werden, z. B., falls ein Wachstum in einem dem Smart Contract zugeordneten Pool, z. B. einem, in dem ein Teil der einem neuen Block zugeordneten Token deponiert werden, hinter einem Ziel zurückbleibt. Neue Regeln können ebenfalls manuell, z. B. in einen Block, eingetragen werden. Falls ein Rückstand von Transaktionsanforderungen wächst, können Strafen für die Nichtauswahl alter Transaktionen erhöht werden. Derartige Regeländerungen können automatisch, z. B. durch einen Smart Contract, eingeführt werden. Zum Beispiel kann eine Regeländerung implementiert werden, falls ein Smart Contract durch eine Bedingung ausgelöst wird.
  • Auswahlregeln sind eine wichtige Anwendung von Güteregeln, da sie helfen, das zensurbasierte Frontrunning unrentabel zu machen. Falls die Token, die durch einen Satz im geheimen Einverständnis stehender Server-Vorrichtungen durch Beteiligung an der Zensur wegen des zugeordneten Bruchs von Auswahlregeln verlorengehen, mehr sind, als durch den Zensurangriff gewonnen werden, ist der Angriff nicht mehr rentabel oder ist seine Rentabilität wenigstens verringert worden. Diese technische Maßnahme macht es unwahrscheinlich, dass eine Server-Vorrichtung dazu verleitet wird, sich an Zensur zu beteiligen, da diese Art des Angriffs in dem System nicht mehr arbeitet.
  • Zum Beispiel weisen Transaktionsanforderungen gemäß einer Ausführungsform ein Alter auf, wobei die Einhaltung als niedriger bewertet wird, falls Transaktionsanforderungen mit einem hohen Alter nicht gewählt werden. Zum Beispiel kann das Alter einer Transaktionsanforderung eine Differenz zwischen einem aktuellen Zeitpunkt und Datum und dem Zeitpunkt und Datum, zu dem die Transformationsanforderung erstmals an eine Server-Vorrichtung gesendet wurde, sein.
  • Eine Auswahlregel kann sein, die älteste verfügbare Transaktionen aufzunehmen. Eine Auswahlregel kann eine Transaktionstauglichkeit, z. B. als eine Funktion des Alters und der Transaktionsgebühr, berechnen und die höchsten aufnehmen. Die Grundlage ist einerseits die an die Transaktionsanforderungen angefügte Transaktionsgebühr und andererseits das Alter.
  • Zum Beispiel kann eine Funktion die Dringlichkeit einer Transaktion als eine Funktion der an die Transaktionsanforderungen angehängten Transaktionsgebühr t und des Transaktionsalters a angeben. Zum Beispiel könnte eine Dringlichkeitsfunktion das Produkt at oder die Summe a + t sein. Zum Beispiel können das Alter und die Gebühr in der Summe oder in dem Produkt gewichtet werden, z. B. γat oder angenommen aγ1 tγ2 oder γ1a + γ2t usw. Zum Beispiel kann die Dringlichkeitsfunktion ein Polynom in der Summe oder in dem Produkt und/oder in ihren gewichteten Varianten sein usw. Allgemein kann die Dringlichkeitsfunktion eine Funktion zweier Variabler sein, die in beiden Variablen wächst.
  • Transaktionsanforderungen können als dringlich angesehen werden, falls ihre Dringlichkeitsfunktion einen Schwellenwert übersteigt. Eine Server-Vorrichtung kann bestraft werden, z. B. einen verringerten Teil der Transaktionsgebühren empfangen, falls dringliche Transaktionsanforderungen nicht behandelt werden.
  • Gemäß einer Ausführungsform wird eine Menge einer Transaktionsgebühr einer Transaktion, z. B. ein Prozentsatz, an einen Pool übertragen. Der Prozentsatz kann über das Alter abnehmen. Somit wird die effektiv ausgelesene Gebühr durch den Miner für ältere Transaktionsanforderungen größer und können die in dem Pool gesammelten Token an eine Server-Vorrichtung übertragen werden, die alte Anforderungen behandelt, um für das Mining älterer Transaktionsanforderungen einen zusätzlichen Anreiz bereitzustellen.
  • Zum Beispiel tritt der erste Miner, z. B. die Server-Vorrichtung 301, in eine Anzahl von Prüfungen ein, um zu sehen, ob der Block als gültig angenommen werden kann, wenn ein erster Miner, z. B. eine Server-Vorrichtung, z. B. die Server-Vorrichtung 301, von einem anderen Miner, z. B. von der Server-Vorrichtung 302, einen vermuteten neuen Block des verteilten Registers empfängt. Die Server-Vorrichtung überprüft herkömmliche Prüfungen. Zum Beispiel kann die Server-Vorrichtung überprüfen, ob das Token tatsächlich an das erste Wallet gebunden war oder dass das erste Wallet ausreichende Geldmittel aufwies oder dergleichen, falls der Block eine Übertragung eines Tokens von einem ersten Wallet zu einem zweiten Wallet enthält. Falls sich die Transaktion auf die Ausführung eines Smart Contract bezieht, kann die Server-Vorrichtung überprüfen, dass die richtige Ausführung der Transaktion entspricht. Zum Beispiel können Erzeugungs- und Vernichtungstransaktionen in dem Register als Transaktionen, die die Ausführung eines Smart Contract zeigen, sichtbar sein.
  • Außerdem überprüft der Server, ob die Token, die die zweite Server-Vorrichtung sich selbst zugewiesen hat, richtig sind. Zum Beispiel kann die erste Server-Vorrichtung die Gütebewertung z. B. dadurch, dass sie die Einhaltung der einen oder mehreren Auswahlregeln durch den zweiten Miner erneut bewertet, erneut berechnen. Aus der Gütebewertung kann die Menge an Gebühren berechnet werden, die zugewiesen werden können.
  • Falls irgendeine der Prüfungen fehlschlägt, wird der Block zurückgewiesen. Das heißt, dass der zweite Miner die Geldmittel nicht tatsächlich empfängt, da die neuen Blöcke nicht zu einem Teil des verteilten Registers werden.
  • Somit schlägt gemäß einer Ausführungsform ein Miner vor, überprüft der andere - und bilden sie dadurch den Konsens über Anreize/Güte und Gültigkeit des Blocks. Zum Beispiel kann gemäß einer Ausführungsform ein Ausschuss von Minern gemäß einem bestimmten Protokoll zusammenarbeiten, um einen Block vorzuschlagen. Daraufhin schlägt ein Miner den Block vor. Welcher Miner es dazu bringt, den nächsten Block vorzuschlagen, kann von den Mitgliedern, z. B. gemäß einem Miner-Auswahlprotokoll oder einer Miner-Auswahlregel, gewählt werden. Daraufhin bewerten die Miner den Block. Beim Bewerten könnten sie außerdem die Gütebewertung usw. bestimmen und einen Konsens über das Mining-Entgelt bilden. Diese Ausführungsform arbeitet gut mit einem PoS- oder PoA-System.
  • Gemäß einer Ausführungsform ist ein Satz mehrerer Server-Vorrichtungen konfiguriert, eine Server-Vorrichtung unter ihnen zu wählen, um den neuen Block vorzuschlagen, wobei die gewählte Server-Vorrichtung den neuen Block erzeugt und die verbleibenden Server-Vorrichtungen den neuen Block überprüfen. Gemäß einer Ausführungsform wird das Wählen einer Server-Vorrichtung mit dem Erzeugen einer vereinbarten Transaktionsanforderungsliste kombiniert.
  • Die Transaktionsanforderungen, die für jede der Server-Vorrichtungen sichtbar sind, können nicht immer gleich sein. insbesondere, wenn ein Peer-to-Peer-Protokoll verwendet wird, um Transaktionsanforderungen zu verteilen, kann sich die Ansicht, die jede Server-Vorrichtung von den Transaktionsanforderungen hat, unterscheiden. Eine Server-Vorrichtung kann sogar einen Anreiz haben, einige Anforderungen, z. B. als Teil eines Zensurangriffs oder um zu vermeiden, dass eine Transaktionsanforderung mit einer bestimmten hohen Transaktionsgebühr durch eine konkurrierende Server-Vorrichtung behandelt wird, nicht zu verteilen.
  • Diese Probleme können dadurch gemildert werden, dass zunächst eine vereinbarte Liste von Transaktionsanforderungen aufgestellt wird, aus der Transaktionen für einen neuen Block gewählt werden müssen. Falls in einem neuen Block Transaktionen enthalten sind, die nicht in der vereinbarten Transaktionsanforderungsliste waren, kann der neue Block durch die anderen Server-Vorrichtungen zurückgewiesen werden.
  • Zum Beispiel können die Server-Vorrichtungen gemäß einer Ausführungsform für ein Synchronisationsprotokoll konfiguriert sein, in dem Transaktionsanforderungen für die Aufnahme in das verteilte Register synchronisiert sind. Zum Beispiel kann die Server-Vorrichtung weiter Transaktionsanforderungen aneinander weiterleiten, wobei aber gelegentlich eine Server-Vorrichtung eine Momentaufnahme ihrer anstehenden Transaktionsanforderungsliste erzeugt und sie an die anderen Server-Vorrichtungen weiterleitet. Die anderen Server-Vorrichtungen können die Liste, z. B. wegen eines speziellen Status der Server-Vorrichtung, als gültig annehmen. Um eine Server-Vorrichtung für die neu vereinbarte Transaktionsanforderungsliste zu wählen, kann ein Protokoll verwendet werden.
  • Ein Vorteil einer vereinbarten Transaktionsanforderungsliste ist, dass Gütebewertungen deterministisch in jeder Server-Vorrichtung berechnet werden können. Ein weiterer Vorteil ist, dass aus einer derartigen Liste klar ist, ob Servervorrichtungen den Auswahlprozess, z. B. durch Zensieren von Verkaufs- oder Kauftransaktionen, manipulieren. Derartige Server-Vorrichtungen können über ihre Gütebewertung, aber möglicherweise ebenfalls über einen Zutrittsverbotsmechanismus [engl.: „out-of-bound mechanism“], z. B. Ausschließen der Server-Vorrichtung aus dem verteilten Registersystem, bestraft werden.
  • Zum Beispiel kann ein Miner eine Transaktionsanforderung in eine globale Transaktionsanforderungsliste einfügen. Ein Miner, der eine alte Transaktionsanforderung nicht auswählt, kann bestraft werden. Zum Beispiel kann ein überprüfender Miner ein Alter einer Transaktion in einem neuen Block durch Vergleichen der Transaktion in dem Block mit einem Zeitstempel der Transaktion in der Transaktionsanforderungsliste berechnen.
  • Gemäß einer Ausführungsform ist eine Server-Vorrichtung konfiguriert, eine Liste vereinbarter Transaktionen zur Aufnahme in das verteilte Register mit einem Satz von Minern zu erzeugen und den Satz von Transaktionen aus den vereinbarten Transaktionen zu wählen.
  • Zum Beispiel können die Miner eine Liste vereinbarter Transaktionsanforderungen in dem Pool erzeugen und signiert jeder Miner eine Hash-codierte Transaktionsanforderungs-Pool-Liste oder ähnlich.
  • Die Vereinbarung einer Liste von Transaktionsanforderungen kann, wie z. B. im Folgenden diskutiert ist, über eine zentralisierte Vorrichtung erfolgen. Das Vereinbaren einer Liste von Transaktionsanforderungen kann ebenfalls über eine Berechnung mehrerer Beteiligter erfolgen. Zum Beispiel können die Server-Vorrichtungen für ein detektierbares Rundsendeprotokoll konfiguriert sein, um eine Vereinbarung zu erzielen. Das detektierbare Rundsenden lässt einen Beteiligten eine Nachricht an alle Beteiligten, z. B. alle Server-Vorrichtungen, senden, so dass entweder alle Beteiligten dieselbe Nachricht empfangen oder alle Beteiligten vereinbaren, dass die Rundsendung fehlgeschlagen ist. Anders als bei einer vollen Rundsendung kann eine detektierbare Rundsendung über private Kanäle wie etwa ein Peer-to-Peer-Netz erzielt werden. Siehe z. B. die Abhandlung „Unconditional Byzantine agreement and multi-party computation secure against dishonest minorities from scratch“ von M. Fitzi, N. Gisin, U. M. Maurer und O. von Rotz.
  • Zum Beispiel können die Server-Vorrichtungen ihre Listen dadurch synchronisieren, dass jede von ihnen ihre lokale Liste von Transaktionsanforderungen einander zusendet. Die vereinbarte Liste kann die Vereinigung der Anforderungen in den empfangenen Listen sein.
  • Gemäß einer Ausführungsform können irgendeine oder alle der Server-Vorrichtungen die vereinbarte Liste an einen Benutzer exportieren. Zum Beispiel kann eine Webseite oder eine API oder dergleichen einer Server-Vorrichtung für den Zugriff auf die vereinbarte Liste konfiguriert sein. Dies kann durch einen Benutzer verwendet werden, um zu überprüfen, dass die Server-Vorrichtungen ehrlich sind. Darüber hinaus könnte ein Benutzer prüfen, ob es seine eingereichte Transaktionsanforderung auf die Liste geschafft hat.
  • Gemäß einer Ausführungsform reicht ein Benutzer, z. B. eine Client-Vorrichtung, eine Transaktionsanforderung an eine Server-Vorrichtung ein. Die Server-Vorrichtung sendet eine signierte Quittung zurück, die einen Zeitstempel oder eine Blocknummer enthält. Auf diese Weise kann der Benutzer später beweisen, dass seine Transaktionsanforderungen eingereicht wurden, es aber nicht auf die Liste geschafft haben oder nicht verarbeitet wurden.
  • 3b zeigt schematisch ein Beispiel einer Ausführungsform eines verteilten Registersystems. 3b zeigt einen Transaktionsanforderungsaggregator 331. Der Aggregator 331 kann in dem System 300 genutzt oder nicht genutzt werden.
  • Zum Beispiel können alle Server-Vorrichtungen irgendeine Transaktionsanforderung, die sie empfangen, an den Aggregator 331 weiterleiten. Der Aggregator 331 kann die Transaktionsanforderungen zu einer einzigen aggregierten Liste zusammenstellen, z. B. doppelte Anforderungen, z. B. an mehrere Server eingereichte Anforderungen, herausfiltern. Der Aggregator 331 kann die aggregierte Liste periodisch an die Server-Vorrichtungen senden. Aus der aggregierten Liste können Transaktionen in einem neuen Block gewählt werden, wobei es tatsächlich erforderlich sein kann, dass sie aus der aggregierten Liste gewählt werden.
  • Gemäß einer Ausführungsform kann der Aggregator 331 konfiguriert sein, eine neue Transaktionsliste an ein verteiltes Registersystem einzureichen. Das verteilte Registersystem kann ein anderes System sein, kann aber sogar dasselbe verteilte Registersystem sein.
  • Eine Client-Vorrichtung, gezeigt ist die Client-Vorrichtung 311, kann sich mit dem Aggregator 331 in Verbindung setzen, um die aktuelle vereinbarte Liste von Transaktionsanforderungen zu erhalten. Falls der Aggregator 331 in dem verteilten Register einen neuen Block sieht, können die verarbeiteten Transaktionen, z. B. die Transaktionen in dem neuen Block, aus der vereinbarten Liste entfernt werden. Die Transaktion kann von dem Aggregator 331 weiter verfügbar sein, z. B., um ihr Alter zu überprüfen.
  • 4 zeigt schematisch ein Beispiel einer Ausführungsform eines Verfahrens 500 zum Unterhalten eines verteilten Registers durch einen ersten Miner. Das Verfahren 500 umfasst Folgendes:
    • - Empfangen (510) mehrerer Transaktionsanforderungen zur Aufnahme in das verteilte Register,
    • - Wählen (520) eines Satzes von Transaktionen aus den mehreren Transaktionsanforderungen,
    • - Erzeugen (530) eines neuen Blocks für das verteilte Register, das den gewählten Satz von Transaktionen enthält,
    • - Berechnen (540) einer ersten Gütebewertung durch Bewerten der Einhaltung einer oder mehrerer Auswahlregeln durch den ersten Miner, wobei die eine oder die mehreren Auswahlregeln Regeln für das Wählen von Transaktionen für einen neuen Block des verteilten Registers angeben,
    • - Fertigstellen (550) des neuen Blocks und Übertragen des Blocks an einen oder mehrere weitere Miner, und
    • - Zuweisen (560) einer Menge kryptografischer Token proportional zu der ersten Gütebewertung zu dem ersten Miner.
  • Das Verfahren kann z. B. ein computer-implementiertes Verfahren sein. Wie der Fachmann auf dem Gebiet erkennt, sind viele verschiedene Arten der Ausführung der Verfahren möglich. Zum Beispiel kann die Reihenfolge der Schritte in der gezeigten Reihenfolge ausgeführt werden, kann die Reihenfolge der Schritte aber geändert werden oder können einige Schritte parallel ausgeführt werden. Darüber hinaus können zwischen Schritten andere Verfahrensschritte eingefügt werden. Die eingefügten Schritte können Verfeinerungen des Verfahrens wie etwa des hier beschriebenen repräsentieren oder können mit dem Verfahren unzusammenhängend sein. Zum Beispiel können einige Schritte wenigstens teilweise parallel ausgeführt werden. Darüber hinaus kann ein gegebener Schritt nicht vollständig fertiggestellt worden sein, bevor ein nächster Schritt begonnen wird.
  • Ausführungsformen des Verfahrens können unter Verwendung von Software ausgeführt werden, die Anweisungen umfasst, um zu veranlassen, dass ein Prozessorsystem das Verfahren 500 ausführt. Software kann nur jene Schritte enthalten, die durch eine bestimmte Subentität des Systems ergriffen werden. Die Software kann in einem geeigneten Ablagespeichermedium wie etwa einer Festplatte, einer Diskette, einem Speicher, einer optischen Platte usw. gespeichert sein. Die Software kann als ein Signal entlang eines Drahts oder drahtlos oder unter Verwendung eines Datennetzes, z. B. des Internet, gesendet werden. Die Software kann zum Herunterladen und/oder für die ferne Nutzung in einem Server verfügbar gemacht werden. Ausführungsformen des Verfahrens können unter Verwendung eines Bitstroms ausgeführt werden, der dafür ausgelegt ist, programmierbare Logik, z. B. eine frei programmierbare logische Anordnung (FPGA), zum Ausführen des Verfahrens zu konfigurieren.
  • Es wird gewürdigt werden, dass sich der vorliegend offenbarte Gegenstand ebenfalls auf Computerprogramme, insbesondere Computerprogramme auf oder in einem Träger, die dafür ausgelegt sind, den vorliegend offenbarten Gegenstand in die Praxis zu bringen, erstreckt. Das Programm kann in Form von Quellcode, Objektcode, einer Codezwischenquelle und Objektcode wie etwa einer teilweise kompilierten Form oder in irgendeiner anderen Form, die zur Verwendung bei der Implementierung einer Ausführungsform des Verfahrens geeignet ist, sein. Eine Ausführungsform, die sich auf ein Computerprogrammprodukt bezieht, umfasst durch einen Computer ausführbare Anweisungen, die jedem der Verarbeitungsschritte wenigstens eines der dargelegten Verfahren entsprechen. Diese Anweisungen können in Unterprogramme unterteilt sein und/oder in einer oder mehreren Dateien, die statisch oder dynamisch verknüpft sein können, gespeichert sein. Eine andere Ausführungsform, die sich auf ein Computerprogrammprodukt bezieht, umfasst durch einen Computer ausführbare Anweisungen, die jeder der Vorrichtungen, Einheiten und/oder Teile wenigstens eines der dargelegten Systeme und/oder Produkte entsprechen.
  • 5a zeigt ein computer-lesbares Medium 1000 mit einem beschreibbaren Teil 1010 und ein computer-lesbares Medium 1001, ebenfalls mit einem beschreibbaren Teil. Das computer-lesbare Medium 1000 ist in Form eines optisch lesbaren Mediums gezeigt. Das computer-lesbare Medium 1001 ist in Form eines elektronischen Speichers, in diesem Fall einer Speicherkarte, gezeigt. Das computer-lesbare Medium 1000 und 1001 kann Daten 1020 speichern, wobei die Daten Anweisungen angeben können, die, wenn sie durch ein Prozessorsystem ausgeführt werden, veranlassen, dass ein Prozessorsystem eine Ausführungsform eines Verfahrens zum Unterhalten eines verteilten Registers gemäß einer Ausführungsform ausführt. Das Computerprogramm 1020 kann in dem computer-lesbaren Medium 1000 als physikalische Marken oder durch Magnetisierung des computer-lesbaren Mediums 1000 verkörpert sein. Allerdings ist irgendeine andere geeignete Ausführungsform ebenfalls denkbar. Obwohl das computer-lesbare Medium 1000 als eine optische Platte gezeigt ist, wird darüber hinaus gewürdigt werden, dass das computer-lesbare Medium 1000 irgendein geeignetes computer-lesbares Medium wie etwa eine Festplatte, ein Festkörperspeicher, ein Flash-Speicher usw. sein kann und nicht beschreibbar oder beschreibbar sein kann.
  • Das Computerprogramm 1020 umfasst Anweisungen, um zu veranlassen, dass ein Prozessorsystem das Verfahren ausführt.
  • 5b zeigt in einer schematischen Darstellung ein Prozessorsystem 1140 gemäß einer Ausführungsform einer Vorrichtung zum Unterhalten eines verteilten Registers. Das Prozessorsystem umfasst eine oder mehrere integrierte Schaltungen 1110. Die Architektur der einen oder mehreren integrierten Schaltungen 1110 ist in 5b schematisch gezeigt. Die Schaltung 1110 umfasst eine Verarbeitungseinheit 1120, z. B. eine CPU, um Computerprogrammkomponenten zum Ausführen eines Verfahrens gemäß einer Ausführungsform und/oder zum Implementieren seiner Module oder Einheiten auszuführen. Die Schaltung 1110 umfasst einen Speicher 1122 zum Speichern von Programmcode, von Daten usw. Ein Teil des Speichers 1122 kann nur lesbar sein. Die Schaltung 1110 kann ein Kommunikationselement 1126, z. B. eine Antenne, Verbinder oder beide und dergleichen, umfassen. Die Schaltung 1110 kann eine dedizierte integrierte Schaltung 1124 zum Ausführen eines Teils oder der gesamten in dem Verfahren definierten Verarbeitung umfassen. Der Prozessor 1120, der Speicher 1122, die dedizierte IC 1124 und das Kommunikationselement 1126 können über eine Verdrahtung 1130, angenommen einen Bus, miteinander verbunden sein. Das Prozessorsystem 1110 kann für die Kontaktkommunikation und/oder kontaktlose Kommunikation unter Verwendung einer Antenne und/oder von Verbindern ausgelegt sein.
  • Gemäß einer Ausführungsform kann das Prozessorsystem 1140 z. B. eine Vorrichtung für ein verteiltes Register, eine Prozessorschaltung und eine Speicherschaltung umfassen, wobei der Prozessor dafür ausgelegt ist, in der Speicherschaltung gespeicherte Software auszuführen. Die Prozessorschaltung kann z. B. ein Intel-Core-i7-Prozessor, ein ARM Cortex-R8 usw. sein. Gemäß einer Ausführungsform kann die Prozessorschaltung ein ARM Cortex M0 sein. Die Speicherschaltung kann eine ROM-Schaltung oder ein nichtflüchtiger Speicher, z. B. ein Flash-Speicher, sein. Die Speicherschaltung kann ein flüchtiger Speicher, z. B. ein SRAM-Speicher, sein. In dem letzteren Fall kann die Vorrichtung eine nichtflüchtige Software-Schnittstelle, z. B. ein Festplattenlaufwerk, eine Netzschnittstelle usw. umfassen, die dafür ausgelegt ist, die Software bereitzustellen.
  • Es wird angemerkt, dass die oben erwähnten Ausführungsformen den vorliegend offenbarten Gegenstand vielmehr veranschaulichen als beschränken und dass der Fachmann auf dem Gebiet in der Lage ist, viele alternative Ausführungsformen zu entwerfen.
  • In den Ansprüchen sind irgendwelche zwischen Klammern angeordneten Bezugszeichen nicht als Beschränkung des Anspruchs zu verstehen. Die Verwendung des Verbs ‚umfassen‘ und seiner Konjugationen schließt die Anwesenheit anderer Elemente oder Schritte als der in einem Anspruch erwähnten nicht aus. Der einem Element vorangehende Artikel ‚ein‘ oder ‚eine‘ schließt die Anwesenheit einer Mehrzahl derartiger Elemente nicht aus. Wenn Ausdrücke wie etwa „wenigstens eines von“ einer Liste von Elementen vorangehen, repräsentieren sie eine Auswahl aller oder irgendeiner Teilmenge von Elementen aus der Liste. Zum Beispiel ist der Ausdruck „wenigstens eines von A, B und C“ so zu verstehen, dass er nur A, nur B, nur C, sowohl A als auch B, sowohl A als auch C, sowohl B als auch C oder alle von A, B und C enthält. Der vorliegend offenbarte Gegenstand kann durch Hardware, die mehrere verschiedene Elemente umfasst, und durch einen geeignet programmierten Computer implementiert werden. In dem Vorrichtungsanspruch, der mehrere Teile aufzählt, können mehrere dieser Teile durch ein und denselben Hardwaregegenstand verkörpert werden. Lediglich die Tatsache, dass bestimmte Maßnahmen in voneinander verschiedenen abhängigen Ansprüchen erwähnt sind, bedeutet nicht, dass eine Kombination dieser Maßnahmen nicht vorteilhaft verwendet werden kann.
  • Bezugnahmen in Klammern beziehen sich in den Ansprüchen auf Bezugszeichen in Zeichnungen beispielhafter Ausführungsformen oder auf Formeln von Ausführungsformen, so dass diese die Lesbarkeit des Anspruchs erhöhen. Diese Bezugsnamen sind nicht als Beschränkung des Anspruchs zu verstehen.
  • 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
    • WO 2019/043668 A1 [0003]

Claims (13)

  1. Computer-implementiertes Verfahren (500) zum Unterhalten eines verteilten Registers durch einen ersten Miner, - Empfangen (510) mehrerer Transaktionsanforderungen zur Aufnahme in das verteilte Register, - Wählen (520) eines Satzes von Transaktionen aus den mehreren Transaktionsanforderungen, - Erzeugen (530) eines neuen Blocks für das verteilte Register, das den gewählten Satz von Transaktionen enthält, - Berechnen (540) einer ersten Gütebewertung durch Bewerten der Einhaltung einer oder mehrerer Auswahlregeln durch den ersten Miner, wobei die eine oder die mehreren Auswahlregeln Regeln zum Wählen von Transaktionen für einen neuen Block des verteilten Registers angeben, - Fertigstellen (550) des neuen Blocks und Übertragen des Blocks an einen oder mehrere weitere Miner, und - Zuweisen (560) einer Menge kryptografischer Token proportional zu der ersten Gütebewertung zu dem ersten Miner.
  2. Computer-implementiertes Verfahren zum Unterhalten eines verteilten Registers durch einen ersten Miner nach Anspruch 1, - Empfangen eines Blocks des verteilten Registers von einem zweiten Miner, - Berechnen einer zweiten Gütebewertung des zweiten Miners durch Bewerten der Einhaltung der einen oder mehreren Auswahlregeln durch den zweiten Miner, - erstes Überprüfen der Transaktionen in dem Block gegenüber dem verteilten Register, - zweites Überprüfen, dass die Menge dem zweiten Miner zugewiesener kryptografischer Token proportional zu der zweiten Gütebewertung ist, und - Zurückweisen des Blocks, falls die erste oder die zweite Überprüfung fehlschlägt.
  3. Computer-implementiertes Verfahren zum Unterhalten eines verteilten Registers durch einen ersten Miner nach einem der vorhergehenden Ansprüche, wobei - Transaktionsanforderungen ein Alter aufweisen und wobei die Einhaltung als niedriger bewertet wird, falls Transaktionsanforderungen mit einem hohen Alter nicht gewählt werden.
  4. Computer-implementiertes Verfahren zum Unterhalten eines verteilten Registers durch einen ersten Miner nach einem der vorhergehenden Ansprüche, wobei die zugewiesenen kryptografischen Token erhalten werden aus: - neuen kryptografischen Token, die mit der Erzeugung des neuen Blocks geschürft werden, und/oder aus - Transaktionsgebühren, die den gewählten Transaktionen zugeordnet sind.
  5. Computer-implementiertes Verfahren zum Unterhalten eines verteilten Registers durch einen ersten Miner nach einem der vorhergehenden Ansprüche, das das Synchronisieren von Transaktionsanforderungen für die Aufnahme in das verteilte Register mit einem zweiten Miner umfasst.
  6. Computer-implementiertes Verfahren zum Unterhalten eines verteilten Registers durch einen ersten Miner nach einem der vorhergehenden Ansprüche, das das Erzeugen einer Liste vereinbarter Transaktionsanforderungen zur Aufnahme in das verteilte Register mit einem Satz von Minern und das Wählen des Satzes von Transaktionen aus den vereinbarten Transaktionsanforderungen umfasst.
  7. Computer-implementiertes Verfahren zum Unterhalten eines verteilten Registers durch einen ersten Miner nach Anspruch 6, wobei die Einhaltung als niedriger bewertet wird, falls Transaktionsanforderungen mit einem höheren Alter in der vereinbarten Liste nicht gewählt werden.
  8. Computer-implementiertes Verfahren zum Unterhalten eines verteilten Registers durch einen ersten Miner nach einem der vorhergehenden Ansprüche, das das Exportieren der vereinbarten Liste an einen Benutzer umfasst.
  9. Computer-implementiertes Verfahren zum Unterhalten eines verteilten Registers durch einen ersten Miner nach einem der vorhergehenden Ansprüche, das das Senden einer signierten Quittung an einen Benutzer umfasst, wenn eine Transaktionsanforderung empfangen wird und/oder die Transaktionsanforderung in eine vereinbarte Liste der Transaktion aufgenommen wird.
  10. Computer-implementiertes Verfahren (500) zum Unterhalten eines verteilten Registers durch einen ersten Miner nach einem der vorhergehenden Ansprüche, wobei das Verfahren Folgendes umfasst: - Vergleichen der berechneten zweiten Gütebewertung des zweiten Miners mit bestimmten Kriterien, z. B. einem Schwellenwert, und Auslösen einer Bestrafungsroutine, falls der Vergleich fehlschlägt.
  11. Server-Vorrichtung zum Unterhalten eines verteilten Registers als ein erster Miner, wobei die Server-Vorrichtung Folgendes umfasst: - eine Kommunikationsschnittstelle, die konfiguriert ist, mehrere Transaktionsanforderungen zur Aufnahme in das verteilte Register zu empfangen, - ein Prozessorsystem, das konfiguriert ist zum: - Wählen eines Satzes von Transaktionen aus den mehreren Transaktionsanforderungen, - Erzeugen eines neuen Blocks für das verteilte Register, das den gewählten Satz von Transaktionen enthält, - Berechnen einer ersten Gütebewertung durch Bewerten der Einhaltung einer oder mehrerer Auswahlregeln durch den ersten Miner, wobei die eine oder die mehreren Auswahlregeln Regeln zum Wählen von Transaktionen für einen neuen Block des verteilten Registers angeben, - Fertigstellen des neuen Blocks und Übertragen des Blocks an einen oder mehrere weitere Miner, und - Zuweisen einer Menge kryptografischer Token proportional zu der ersten Gütebewertung zu dem ersten Miner.
  12. Client-Vorrichtung zur Verwendung eines verteilten Registers, wobei die Client-Vorrichtung Folgendes umfasst: - eine Kommunikationsschnittstelle, die konfiguriert ist, eine Transaktionsanforderung an eine Server-Vorrichtung zu senden, und - ein Prozessorsystem, das konfiguriert ist zum: - Unterhalten eines ersten Wallets mit Krypto-Token, - Senden einer Transaktionsanforderung an die Server-Vorrichtung, Anfordern der Übertragung einer Menge von Krypto-Token von dem ersten Wallet an ein zweites Wallet, wobei die Server-Vorrichtung konfiguriert ist, die Transaktionsanforderung aus mehreren Transaktionsanforderungen zu wählen, Erzeugen eines neuen Blocks für das verteilte Register, das die gewählte Transaktion enthält, Berechnen einer ersten Gütebewertung durch Bewerten der Einhaltung einer oder mehrerer Auswahlregeln durch den Miner, Fertigstellen des neuen Blocks und Übertragen des Blocks an einen oder mehrere weitere Miner, und Zuweisen einer Menge kryptografischer Token proportional zu der ersten Gütebewertung zu dem ersten Miner.
  13. Transitorisches oder nichttransitorisches computer-lesbares Medium (1000), das Daten (1020) umfasst, die Anweisungen repräsentieren, die, wenn sie durch ein Prozessorsystem ausgeführt werden, veranlassen, dass das Prozessorsystem das Verfahren nach einem der Ansprüche 1-10 ausführt.
DE102021212599.9A 2021-11-09 2021-11-09 Schutz gegen Frontrunning-Angriffe in einem verteilten Register Pending DE102021212599A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE102021212599.9A DE102021212599A1 (de) 2021-11-09 2021-11-09 Schutz gegen Frontrunning-Angriffe in einem verteilten Register
US17/975,753 US20230147925A1 (en) 2021-11-09 2022-10-28 Protection against front-running attacks in a distributed ledger
CN202211390716.8A CN116109410A (zh) 2021-11-09 2022-11-08 防御分布式分类账中的抢先交易攻击

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102021212599.9A DE102021212599A1 (de) 2021-11-09 2021-11-09 Schutz gegen Frontrunning-Angriffe in einem verteilten Register

Publications (1)

Publication Number Publication Date
DE102021212599A1 true DE102021212599A1 (de) 2023-05-11

Family

ID=86053478

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021212599.9A Pending DE102021212599A1 (de) 2021-11-09 2021-11-09 Schutz gegen Frontrunning-Angriffe in einem verteilten Register

Country Status (3)

Country Link
US (1) US20230147925A1 (de)
CN (1) CN116109410A (de)
DE (1) DE102021212599A1 (de)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019043668A1 (en) 2017-09-04 2019-03-07 Lingham Investments (Pty) Ltd CRYPTOGRAPHIC MONEY SYSTEM

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019043668A1 (en) 2017-09-04 2019-03-07 Lingham Investments (Pty) Ltd CRYPTOGRAPHIC MONEY SYSTEM

Also Published As

Publication number Publication date
CN116109410A (zh) 2023-05-12
US20230147925A1 (en) 2023-05-11

Similar Documents

Publication Publication Date Title
CN109242681B (zh) 资产数据的存储方法、装置、设备及系统
Wood Polkadot: Vision for a heterogeneous multi-chain framework
DE69833381T2 (de) Vorrichtung und verfahren zum verifizieren ehrlicher spieltransaktionen in einem kommunikationsnetz
DE69919020T2 (de) Methode und system zur durchführung von schnellen elektronischen lotterien
DE112021002797T5 (de) Datenschutzerhaltende architektur für genehmigungspflichtige blockchains
CN108805627B (zh) 媒体资源分配方法、装置、系统、介质及设备
CN112740252A (zh) 使用智能合约的区块链交易安全性
CN107742352A (zh) 基于区块链及智能合约的去中心化抽签/排队方法及系统
DE102019129050A1 (de) Systeme und verfahren zur gemeinsamen nutzung von fahrzeugen über peer-to-peer-netzwerke
Gu et al. Empirical measurements on pricing oracles and decentralized governance for stablecoins
CN109726249B (zh) 一种去中心化芯片研发交易数据存储方法及系统
DE102004014131A1 (de) Verfahren und System zum Abrechnen von Wertpapiergeschäften
Kothapalli et al. Smartcast: An incentive compatible consensus protocol using smart contracts
DE112007003476T5 (de) Anonymes Matching-System für den Pakethandel
DE102018009949A1 (de) Übertragungsverfahren zum flexiblen Übertragen von spezifisch teilbaren elektronischen Münzdatensätzen
CN111201751B (zh) 用于仲裁区块链中数据真实性的方法和系统
Decker On the scalability and security of bitcoin
DE102021212599A1 (de) Schutz gegen Frontrunning-Angriffe in einem verteilten Register
US20230073427A1 (en) Decentralized hard exchange
WO2020043588A1 (de) Einrichtung und verfahren zum ermitteln einer konsensversion eines transaktionsbuchs und einrichtung und verfahren zum überwachen eines verteilten datenbanksystems
CN115687526A (zh) 一种基于区块链和联邦学习的地震数据模型共享方法
DE112021000619T5 (de) Adaptive zustandsverwaltung für statusunabhängige services
DE102021130943A1 (de) Konsensalgorithmus für distributed-ledger-technologie
EP3764266A1 (de) Verfahren und vorrichtung zum handeln auf einer elektronischen handelsplattform
CN113435949B (zh) 基于智能合约的去中心化联邦机器学习方法、系统及存储介质