In diese Blogserie geben wir einen tieferen Einblick in die Themen IOTA und Hashgraph und die dahinter liegenden Konzepte:
- IOTA – Einführung
- IOTA – Praktische Beispiele
- Hedera Hashgraph – Einführung: Was ist Hashgraph?
- Hedera Hashgraph – Praktische Beispiele
Nachdem die beiden ersten Teile der Blogserie IOTA beleuchtet haben, werde ich mich in den beiden folgenden Artikeln dem Thema Hashgraph nähern. Fokus des ersten Artikels ist es, den Hashgraph-Consensus-Algorithmus zu erläutern. Im zweiten Teil werde ich dann Beispiele auf Basis der Hedera-Plattform zeigen.
Was ist Hashgraph?
In den beiden vorherigen Artikeln haben wir uns mit IOTA beschäftigt. Wir haben gesehen, dass IOTA als Distributed-Ledger-Plattform betrachtet werden kann, deren technologische Basis das Tangel ist. Bei Hashgraph handelt es sich zunächst nur um die technologische Basis für den Consensus-Algorithmus und die dafür notwendige Datenstruktur.
Eine konkrete Umsetzung des Hashgraph-Consensus-Algorithmus erfolgte durch das Unternehmen Swirlds Inc. Hierbei handelt es sich um die Referenzimplementierung des durch das Unternehmen patentierten Algorithmus. Zur Umsetzung eines Distributed Ledger auf Basis des Hashgraph-Algorithmus wurde das Unternehmen Hedera Hashgraph gegründet.
Eine der größten Herausforderungen in verteilten Systemen besteht darin, einen Konsens über stattgefundene Ereignisse herzustellen. In verteilten Systemen ist dabei abzusichern, dass fehlerhafte Ereignisse beziehungsweise Manipulationen erkannt und ausgeschlossen werden können. Dieses Problem wird auch als das „Problem der byzantinischen Generäle“ bezeichnet.
Unter der Annahme, dass es Teilnehmer im Netz gibt, denen man nicht vertraut, ergibt sich die Frage, wie man sicher sein kann, dass keine falschen oder gefälschten Nachrichten im Netz verteilt werden. Die Lösung des Problems besagt, dass nicht mehr als 1/3 der Teilnehmer (Knoten) im Netz Angreifer oder Verräter sein dürfen. Wenn wir zum Beispiel fünf Knoten im Netz haben, dann müssen mindestens vier (wg. 5*2/3=3,33) die einfache Ja- / Nein-Frage nach der Richtigkeit einer Transaktion mit Ja beantworten, um eine Transation zu bestätigen. Unter dieser Annahme ist ein System dann auch byzantinisch fehlertolerant, was eine sehr wichtige Eigenschaft des Hashgraph-Algorithmus ist.
Grundkonzepte und -begriffe
Zum Verständnis des Hashgraphs ist es notwendig, einige Grundkonzepte und -begriffe zu erläutern. Diese bilden die Basis auf denen der Hashgraph-Consensus-Algorithmus beruht.
Im nachfolgenden Text werden zum großen Teil die englischen Begriffe verwendet, die auch in der Beschreibung des „Hashgraph Consensus Algorithm“ (SWIRLDSTECHREPORTSWIRLDS-TR-2016-01) verwendet werden, da eine Übersetzung nicht in jedem Fall einen Mehrwert für das Verständnis mit sich bringt.
- Transactions – Jeder Teilnehmer kann zu jeder Zeit eine signierte Transaktion erstellen. Alle Knoten erhalten eine Kopie und die Community erzeugt eine byzantinische Übereinkunft bezüglich der Reihenfolge dieser Transaktionen.
- Fairness - Für eine kleine Gruppe von Angreifern ist es schwer, die durch Konsens bestimmte Reihenfolge der Transaktionen zu beeinflussen. In der Blockchain könnte ein Miner über die Reihenfolge im Block entscheiden oder darüber, welche Transaktionen er bevorzugt verarbeitet. Im Hashgraph gibt es keine Möglichkeit, dass ein Individuum die Konsensreihenfolge von Transaktionen beeinflusst.
- Gossip - Informationen werden von jedem Mitglied sofort an andere zufällig ausgewählte Mitglieder verteilt.
- Hashgraph – Ist die Datenstruktur, die dokumentiert, wer mit wem in welcher Reihenfolge Informationen ausgetauscht hat.
- Gossip about Gossip - Der Hashgraph wird mittels Gossip-Protokoll verbreitet. Die Informationen, die ausgetauscht werden, sind die Historie des Informationsaustausches selbst.
- Virtual Voting – Jeder beteiligte Knoten besitzt eine Kopie des Hashgraphs. Damit kann er berechnen welche Stimme ein anderer Knoten ihm geschickt hätte, wenn sie eine traditionelle byzantinische Übereinkunft mittels Versenden von Stimmen durchgeführt hätten. Jeder Knoten kann eine byzantinische Übereinkunft über eine beliebige Anzahl von Entscheidungen erzielen, ohne einen anderen Knoten befragen zu müssen. Der lokale Hashgraph alleine reicht aus.
- Famous Witnesses - Eine Community könnte eine Liste von n Transaktionen in eine Reihenfolge bringen, indem sie separate byzantinische Übereinkunfte mit O(n log n) in Form von verschiedenen Ja-/ Nein-Fragen der Form „kam das Event x vor dem Event y?“ ausführt. Eine schnellere Methode ist die Auswahl einiger Events (Punkte im Hashgraph), die Witnesses (Zeugen) genannt werden. Diese Events werden wiederum als Famous Witnesses bezeichnet, wenn im Hashgraph gezeigt werden kann, dass die meisten Knoten das Event nach seiner Erstellung erhalten haben.
- Strongly Seeing - Wenn zwei beliebige Events x und y im Hashgraph gegeben sind, kann sofort berechnet werden, ob das Event x das Event y stark sehen (Strongly Seeing) kann. Dies ist genau dann der Fall, wenn der Pfad von x nach y über genügend unterschiedliche Knoten geht, also von anderen Mitgliedern gesehen wird.
Auf dieser Basis kann bewiesen werden, wenn Knoten A und B beide in der Lage sind, die virtuelle Abstimmung von Knoten C für eine gegebene Frage zu berechnen, erhalten A und B die gleiche Antwort.
Gossip about Gossip und der Hashgraph
Der Konsensalgorithmus, der bei Hashgraph zum Einsatz kommt, basiert auf dem Gossip-Protokoll. Übertragen in die echte Welt bedeutet das soviel wie: Erzähle dem größten Tratscher ein Geheimnis und du kannst sicher sein, dass es in kürzester Zeit die gesamte Gruppe kennt. Auch der Büroflurfunk funktioniert vergleichbar und jeder weiß, dass die Verbreitung der Informationen schnell und zuverlässig funktioniert.
Unter technischen Gesichtspunkten besteht unsere verteilte Welt aus einzelnen Knoten, die Informationen halten und verteilen. Eine neue Information wird von einem Knoten an zufällige weitere Knoten übermittelt. Diese Knoten tun wiederum selbiges. Somit verbreitet sich die Information rasend schnell über das gesamte Netz.
In der nachfolgenden Abbildung 1 sieht man vier Knoten (A, B, C, D). Dabei handelt es sich um sogenannte Fullnodes, die Teilnehmer in einem Netzwerk repräsentieren. Wenn der Knoten A eine Transaktion T1 verschickt, dann wird diese Transaktion in eine Nachricht (Event) gepackt und auf Basis des Gossip-Protokolls verschickt.
Dies bedeutet, dass der Knoten A die Nachricht an zufällige Knoten verschickt. Von diesen Knoten wird die Nachricht wiederum an weitere zufällige Knoten geschickt. Abbildung 2 zeigt schematisch die Nachrichtenverteilung. Der Knoten A verschickt die Nachricht mit der Transaktion T1 an die Knoten D und C. Der Knoten D verschickt die Nachricht wiederum an den Knoten B.
Wenn Knoten D nun ebenfalls eine Transaktion (T2) zu verschicken hat, dann verschickt er die Nachricht wie in Abbildung 3 zu sehen an Knoten B und A. Der Knoten A nimmt diese Nachricht verschickt diese an Knoten C.
Alle Knoten erlangen das Wissen über die einzelne Nachricht zu unterschiedlichen Zeitpunkten.
Wird das Verschicken und Verteilen der Nachrichten aus dem vorgenannten Beispiel in einen Graph übertragen, der nach oben den Verlauf der Nachrichtenverteilung widerspiegelt, dann handelt es sich dabei um den Hashgraph, wie ihn Abbildung 4 zeigt.
Die verschickte Nachricht ist im Hashgraph ein Event (Kreis). Dieses bildet den Container für eine Menge von Transaktionen.
Wenn der Knoten D sein Event an Knoten B verschickt, dann erzeugt Knoten B ein neues Event, das über eine definierte Struktur einen Verweis auf das Sender-Event besitzt und einen Verweis auf das letzte eigenen Event. Alle Events in dem Diagramm sind dabei über kryptographische Hashes verbunden.
Das Event, welches der Knoten B nach Empfang des Events von Knoten D erzeugt, enthält zwei Hashwerte der beiden Eltern-Events. Dies sind der Hash des eigenen vorherigen Events von B (Self-Parent) und der Hash des von D empfangenen Events (Other-Parent).
Das Event enthält auch neue Transaktionen, den Timestamp mit dem Zeitpunkt der Event-Erstellung und die vom Knoten B erzeugte Signatur des Events. Durch die Verknüpfung der Parent-Events mittels ihrer Hashwerte entsteht ein gerichteter Graph über die Events und ihre Vorfahren. Auf Basis dieser Struktur ist reproduzierbar, wann welche Events erstellt wurden und wer diese wann erhalten hat. Somit gibt es eine Historisierung über den Tratsch, das Gossip about Gossip.
Auf dieser Basis besitzt der Hashgraph für alle beteiligten aktiven Knoten große Vorteile. Alle Knoten werden sehr schnell über Transaktionen in den Events informiert und jeder weiß, wann der andere über das Event informiert wurde. Da der Hashgraph über die Zeit wächst, wird es gerade im oberen Teil des Graphen unterschiedliche Subsets der Events in den Knoten geben. Weiter unten werden aber sehr schnell alle genau den gleichen Stand der Events haben.
Dies ist die Grundlage für die virtuelle Abstimmung, das Virtual Voting.
Der Konsens-Algorithmus
Grundlagen des Algorithmus
Das Ziel des Konsensalgorithmus ist es, in einer Gruppe einen Konsens über die Echtheit und die Reihenfolge von Transaktionen zu erzielen, wobei kein Mitglied der Gruppe den anderen Mitgliedern vertraut.
Dazu ist es notwendig, die Konsensreihenfolge (Consensus Order) über den Konsenszeitstempel (Consensus Timestamp) herzustellen. Dabei genügt es nicht, dass jeder Knoten jedes Event kennt, sondern es muss eine Einigkeit darüber hergestellt werden, wann ein Event für die im Netz beteiligten Knoten sichtbar war.
Der Consensus Timestamp wird ermittelt aus dem Median der Empfangszeit der Events in den einzelnen Knoten.
Der Hashgraph-Algorithmus ist in seiner Umsetzung byzantinisch fehlertolerant. Das bedeutet, dass dieser gegen Angriffe in einem definierten Umfang geschützt ist.
Die Umsetzung der meisten byzantinische Fehlerprotokolle erfordert es, dass die Knoten jeweils allen anderen ihre Abstimmung zu einer bestimmten Fragestellung senden. Dies bedeutet bei n Knoten für eine Abstimmung einer Ja- / Nein-Frage sind mindestens O(n2) Abstimmungsnachrichten im Netz zu verteilen.
An dieser Stelle kommt eine der Stärken des Hashgraphs zum Tragen, das Virtual Voting. Alle Knoten haben den prinzipiell gleichen Hashgraph. Dieser ist im oberen Bereich des Graphen nicht exakt gleich, aber die Knoten haben immer einen konsistenten Stand. Dies bedeutet, dass zwei Knoten, die das Event x im Hashgraph haben, auf beiden Knoten auch immer die beiden identischen Vorfahren existieren.
Die Abbildung 5 zeigt dies beispielhaft an einem Stand des Hashgraphs in den Knoten A und C, nach der Synchronisation des Events x durch den Knoten B. Aufgrund der Eigenschaft, dass ein Event immer einen Verweis auf sein eigenes Vorgängerevent (Self-Parent) und das Event, von dem eine Synchronisation von Events erhalten (Other-Parent) besitzt, müssen beide Strukturen in dieser Position identisch sein. Auf dieser Basis können sowohl Knoten A als auch Knoten C das Abstimmungsverhalten des Knoten B virtuell ermitteln.
Wenn ein Knoten versuchen würde, Events zu manipulieren, dann könnte er zum Beispiel zwei Events erzeugen, die jeweils auf das gleiche Self-Parent Event verweisen. In Abbildung 6 werden die beiden Events x und y durch den Knoten B erzeugt, die beide auf das Self-Parent Event z verweisen. Damit würde ein unzulässiger fork entstehen.
Abbildung 6: Manipulation von Events in einem Knoten
Wenn der Knoten B das Event x an Knoten A und das Event y an Knoten D verteilt, dann würden beide Knoten zunächst von der Manipulation nichts merken und würden unterschiedlich für die beiden Events x und y abstimmen, da ein Knoten das jeweils andere Event zu dem Zeitpunkt nicht kennt.
Die Abbildung 7 zeigt den Hashgraph von Knoten A und D nach der Verteilung der Events x und y. Beide Knoten erzeugen nach Empfang jeweils ein neues Event w und v mit dem Verweis auf ihr Self-Parent Event und das Event x für Knoten A und das Event y für Knoten D. Daran ist leicht zu erkennen, das Event w im Knoten A das Event x sieht aber nicht Event y. Knoten D sieht hingegen das Event y über das Event v aber nicht das Event x.
Der Konsensalgorithmus von Hashgraph verhindert die hier konstruierte Manipulationsmöglichkeit auf Basis des Konzepts, dass ein Event immer mit einem eigenen Vorfahren und dem Vorfahren aus der Synchronisation verknüpft sein muss und dem Konzept des Strongly Seeing, das später im Detail noch beschrieben wird.
Die orangenen Events in Abbildung 7 zeigen, was in den Knoten bei weiteren Synchronisationen auf Basis des Gossip-Protokolls passieren würde. Der Knoten A würde das Event v vom Knoten D erhalten und kann dieses nicht mehr in seinen Hashgraph einfügen, da das Event y nicht existiert. Dieses kann nicht eingefügt werden, da es auf das Event z verweist, das aber schon durch den Verweis des Events x belegt ist. Hier wird die Manipulation erkannt und alle Events des Knotens B werden nicht mehr berücksichtigt.
Die einzelnen Schritte des Konsensalgorithmus
Der Algorithmus basiert auf zwei parallellaufenden Prozessen. In einem Prozess werden alle bekannten Events an zufällige, andere Knoten verteilt. Im zweiten Prozess werden alle Events verarbeitet, die der Knoten von anderen Knoten erhält. Die Herstellung des Konsens erfolgt im Zuge der Verarbeitung der empfangenen Events.
Die Verarbeitung der erhaltenen Events gliedert sich in die folgenden Schritte:
- Wenn die beiden Hashwerte des erhaltenen Events Events des lokalen Hashgraph referenzieren, wird das erhaltene Event in den Hashgraph eingefügt
- Es wird ein neues Event zu der empfangenen Synchronisation generiert
- Ermittlung der Runde für das Event (Round Created)
- Für das erste Event jedes Knotens in jeder Runde (die Zeugen (Witnesses)) wird bestimmt, ob dieses Famous ist oder nicht
- Bestimmen der Reihenfolge der Events
Am Ende des Durchlaufs ist für einzelne Events (nicht alle) eine Konsensreihenfolge und ein Konsenszeitstempel bestimmt und es wurde ein Konsens über die Validität der Events und deren Transaktionen hergestellt.
In den folgenden Abschnitten stelle ich die drei letzten Schritte der Eventverarbeitung im Detail dar. Die ersten beiden Schritte bei der Eventverarbeitung werde ich nicht weiter detaillieren, da sich aus der schon beschriebenen Datenstruktur eines Events leicht nachvollziehen lässt, was hier passiert.
Ermittlung der Runde von Events (Round Created)
Die Einteilung in Runden ist von Bedeutung, da die ersten Events einer Runde die Events sind, die im Zuge der virtuellen Abstimmungen (Virtual Votes) betrachtet werden. Ein erstes Event jedes Knotens in einer Runde wird Witness (Zeuge) genannt. In Abbildung 8 sind das alle magentafarbenen Events.
Eine neue Runde R+1 wird immer dann erzeugt, wenn das einzufügende Event mehr als 2n/3 der Witness Events der bisherigen Runde R stark sieht (Strongly See). Dies bedeutet, dass die Mehrzahl der Witness Events von dem betrachteten Event über einen Pfad erreichbar sein muss, der über mehr als 2n/3 der Knoten führt (Supermajority).
Mit der Bestimmung der Runde ist auch die Festlegung, ob es sich um ein Witness Events handelt, verbunden.
Ist ein Witness Event Famous?
Um zu bestimmen, ob ein Witness Event der Runde R Famous ist, müssen möglichst viele der Witness Events der folgenden Runde R+1 dieses Event sehen. Im Beispiel der Abbildung 9 ist über das Virtual Voting die Frage zu beantworten, ob das Event B2 ein Famous Witness Event ist.
Alle Witness Events A3, B3, C3 und D3 der Folgerunde R+1 stimmen virtuell ab, ob sie das Event B2 sehen. Alle Events stimmen in diesem Beispiel mit Ja. Alle sehen das Event B2, da jedes Event (A3, B3, C3, D3) das Event B2 über einen Pfad (grüne Linien) erreichen kann.
Dabei muss der Pfad ausschließlich über die Vorfahren, also abwärts, verlaufen. Zunächst hat nur jedes einzelne Event eine Abstimmung abgegeben, ob es B2 sieht. Damit ist noch nicht bekannt, wie viele Events B2 sehen. So wird es notwendig zu zählen, wie viele Events die Frage, ob sie Event B2 sehen, mit Ja beantworten.
Das Zählen der Abstimmung erfolgt, indem für jedes Event (A3, B3, C3, D3) bestimmt wird, ob ein Witness Event der Folgerunde diese Events stark sieht (Strongly See). Dies ist immer dann gegeben, wenn das betrachtete Event über Pfade erreichbar ist, die über 2n/3 der Knoten verlaufen, der sogenannten Supermajority.
In Abbildung 10 kann man erkennen, dass das Event A3 von B4 über Pfade erreichbar ist, die über die Knoten A, B und C verlaufen. Damit sehen drei von vier Knoten das Event A3, was im Sinne des byzantinischen Fehlerprotokolls notwendig ist.
Nun zurück zum Zählen der Abstimmung, ob Event B2 ein Famous Witness Event ist. Abbildung 10 visualisiert zunächst das Sammeln der Abstimmungen für die Events A3 und B3. Dabei werden beide Events über den roten Pfad über die Knoten A und B und über den orangenen Pfad über die Knoten B und D gesehen. Damit sammelt B4 die Stimmen von A3 und B3 und beantwortet die Frage, ob B4 die Events A3 und B3 Strongly Sees mit Ja.
In der Abbildung 11 erfolgt die Abstimmung für die Events C3 und D3. Auch hier kann man über den roten und orangenen Pfad sehen, dass beide Events über die Knoten B, C und D zu sehen sind.
Das Event B4 hat für alle vier Events (A3-D3) ein Ja als Abstimmungsergebnis erhalten. Damit ist die Gesamtabstimmung ja, also ist entschieden, dass das Event B2 Famous ist. Sobald eine Entscheidung Ja oder Nein getroffen ist, ist die Wahl beendet.
Sollte es vorkommen, dass eine Entscheidung nicht möglich ist, weil das Event zum Beispiel zweimal Ja und zweimal Nein sammelt, erfolgt eine Prüfung mit einem anderen Witness Event (zum Beispiel D4).
Wenn wir nun das Event C2 betrachten (s. Abbildung 12), um zu prüfen, ob diese Event Famous ist, würde B4 erneut die Abstimmungen sammeln. Das Ergebnis wäre nein, da nicht mehr als 2n/3 der Knoten das Event C2 sehen.
Damit steht fest, dass das Event C2 nicht Famous ist. Die Entscheidung, ob ein Event Famous ist, wird für alle Witness Events durchgeführt. Dies wird mit jeder Eventverarbeitung für die Witness Events wiederholt bis eine Entscheidung vorliegt.
In unserem Beispiel ergibt sich das folgende Bild (s. Abbildung 13)
Die Events A1-D1 und A2, B2 und D3 sind Famous. Auf dieser Basis kann man nun die Reihenfolge der Events, insbesondere für die bisher nicht betrachteten hellblauen Events, bestimmen.
Bestimmen der Reihenfolge der Events
Um einen Konsens bezüglich der Reihenfolge der Transaktionen beziehungsweise Nachrichten herzustellen, ist es notwendig, den Consensus Timestamp zu ermitteln. Der Consensuns Timestamp ist definiert durch den Median der Zeiten, zu dem die Knoten das Event gesehen haben. Dies ist nicht mit der Zeit gleichzusetzen, zu der das Event von einem Knoten erzeugt wurde.
Das auf dem einleitenden Beispiel zum Gossip-Protokoll aufbauende folgende Beispiel verdeutlicht das Prinzip. Die Verteilung der einzelnen Nachrichten erfolgt zwischen den verschiedenen Knoten, die diese zu unterschiedlichen Zeitpunkten erhalten (s. Abbildung 14).
Über einen Zeitstempel ist bekannt, wann jeder Knoten jede Nachricht bekommen hat. Jetzt werden alle Zeitstempel einer Nachricht sortiert und der Median der Empfangszeiten der Nachricht aller Knoten repräsentiert den Zeitpunkt, zu dem die meisten Knoten im Netz die Nachricht erhalten haben. Dieser Zeitstempel ist der Consensus Timestamp und definiert die Reihenfolge der Transaktionen beziehungsweise Nachrichten.
In dem Beispiel (s. Abbildung 14) ist die Nachricht in dem hellblauen Umschlag (Median: 12:09:44) vor der Nachricht in dem dunkelblauen Umschlag (12:09:46) für die Community sichtbar, auch wenn im Knoten B die dunkelblaue vor der hellblauen Nachricht eingetroffen ist.
Die konkrete Umsetzung innerhalb des Hashgraph-Algorithmus erfolgt in drei Schritten:
- Ermitteln der Round Received für frühere Events (in welcher Runde sehen alle Knoten das Event)
- Bestimmen des Konsenszeitstempels (Consensus Timestamp)
- Bestimmen der Konsensreihenfolge (Consensus Order)
Nach der Bestimmung der Famous Witness Events (grüne Events in Abbildung 15), muss festgelegt werden, in welcher Runde die nicht Witness Events von den anderen Knoten gesehen werden.
Wenn man das schwarze Event in Abbildung 15 betrachtet, dann haben alle Famous Witness Events (A2, B2, D2) der Runde 2 einen Pfad zum Event, das heißt sie sehen alle das schwarze Event. Dies bedeutet, dass das schwarze Event den Round Received Wert = 2 erhält. Das bedeutet in Runde 2 sehen es die meisten Knoten.
Betrachtet man das Self-Parent Event vom Event B2, dann ist leicht zu erkennen, dass dieses nicht von den Events A2 und D2 über einen Pfad erreichbar und somit nicht sichtbar ist für A2 und D2. Dieses Event ist daher nicht in Runde 2 sichtbar.
Für jedes Event einer Runde ist der Consensus Timestamp zu ermitteln. Dies ist der Median des Zeitpunktes, an dem die Knoten das Event erstmalig gesehen haben. In Abbildung 15 sieht der Knoten B das schwarze Event erstmalig über das Event B2 und der Knoten D sieht das Event erstmalig im Event D2. Für den Knoten A ist es der Zeitpunkt der Erzeugung des schwarzen Events selbst.
Für alle weiteren Events erfolgt ebenso die Bestimmung der Round Received und des Consensus Timestamps. Im Ergebnis sind in diesem Beispiel alle schwarzen Events und die Events A1—D1 in Runde 2 sichtbar für die Knoten.
Im letzten Schritt werden alle Events einer Runde auf Basis ihres Consensus Timestamps sortiert. Damit ist die Consensus Order innerhalb der Runde erstellt. Über die Reihenfolge der Runden ist dann auch eine Gesamtreihenfolge aller Events und ihrer Transaktionen erstellt.
Damit haben wir die theoretischen Grundlagen des Algorithmus behandelt und man kann diesen sehr vielversprechenden Ansatz für die Konsensbildung in einem Distributed Ledger betrachten. Wie sich dieser durchsetzen wird, wird die Zukunft zeigen. Hier ist ein sehr großes Hindernis möglicherweise das auf dem Algorithmus liegende Patent.
Den praktischen Einsatz des Algorithmus auf der Hedera-Plattform werden wir uns dann im nächsten Blogbeitrag ansehen. Ein Einsatz des Hashgraph-Algorithmus ist natürlich auch in anderen Bereichen vorstellbar, in denen verteilte Anwendungen eine Rolle spielen, zum Beispiel bei Online-Spielen oder Marktplätzen.
Noch Fragen?
Wie können Sie Chancen und mögliche Einsatzfelder von Blockchain-Lösungen identifizieren und diese in Ihrer Organisation umsetzen? Erfahren Sie, wie wir Sie beim Thema Blockchain unterstützen können:
Nico Heinze - ist Projektmanager bei der iteratec GmbH in München. In den vergangenen Jahren setzten sein Team und er immer wieder völlig neuartige Anwendungen um.