Ultimate Guide to Tendermint

Der umfassendste Leitfaden für Tenderminzkern

en flag
fr flag
de flag
es flag
Subscribe

Lesezeit: 17 Minuten

Cosmos ist eines der vielversprechendsten Projekte da draußen. Mit Leuten wie Jae Kwon und Ethan Buchman in ihrem Team hat es viel Potenzial. Im Herzen und in seiner Seele liegt der Tendermint Core.

Ultimate Guide to Tendermint

Tendermint Core kombiniert den Tendermint Konsensus Algorithmus zusammen mit einem p2p Klatsch Protokoll. Wenn Sie also alles zusammen in den Software-Stack legen, erhalten Sie den Tendermint Core zusammen mit der Cosmos-SDK-Anwendungsebene.

Wie auch immer, bevor wir weiter reingehen, schauen wir uns an, warum Tendermint so eine Notwendigkeit ist.

Bitcoin und Blockchain

Als Satoshi Nakamoto Bitcoin schuf, machte er das erste dezentrale kryptographische System. Der bemerkenswerte Teil dieser Entdeckung war, dass er in der Lage war, das Problem des Byzantinischen Generals zu lösen, was einem Wide Area Network (WAN) half, in einer vertrauenslosen Umgebung einen Konsens zu erzielen. Bitcoin verwendete Proof-of-Work Algorithmus, um sich um ihren Konsens zu kümmern.

Allerdings kann der Hauptbeitrag von Bitcoin sehr gut darin sein, dass es die ganze Welt in die Blockchain-Technologie eingeführt hat.

Eine Blockchain ist, in der einfachsten Form, eine Zeitstempelreihe unveränderlicher Datensätze von Daten, die von einem Cluster von Computern verwaltet wird, die keiner einzelnen Entität gehören. Jeder dieser Datenblöcke (d. h. Block) ist gesichert und durch kryptographische Prinzipien (d.h. Kette) miteinander verbunden.

Mit anderen Worten, eine Blockchain ist eine deterministische Zustandsmaschine, die auf Knoten repliziert wird, die sich nicht unbedingt gegenseitig vertrauen.

Mit deterministisch meinen wir, dass, wenn die gleichen spezifischen Schritte unternommen werden, es immer zum gleichen Ergebnis führen wird.

ZB. 1 + 2 wird immer 3.

Also, was bedeutet Staat? Schauen wir uns es wrt Bitcoin und Ethereum an.

In Bitcoin ist der Status eine Liste der Salden für jedes Konto, bei der es sich um eine Liste der UTXO (Unausgegeben Transaction Output) handelt. Dieser Zustand wird über Transaktionen geändert, die den Saldo ändern.

Auf der anderen Seite ist die Anwendung in Ethereum eine virtuelle Maschine, die Smart Contracts ausführt. Jede Transaktion durchläuft die Ethereum Virtual Machine und ändert den Status entsprechend dem spezifischen Smart Contract, der darin aufgerufen wird.

Wenn Sie sich die Architektur der Blockchain-Technologie ansehen, dann werden Sie drei spezifische Ebenen:

Vernetzung: Die Verbreitung der Transaktion/Information über die Knoten

Konsens: Ermöglicht den Knoten, zu einer Entscheidung zu kommen, vorausgesetzt, 2/3 der Knoten sind nicht bösartig

Anwendung: Verantwortlich für die Aktualisierung des Status einer Reihe von Transaktionen, d. h. die Verarbeitung von Transaktionen. Bei einer Transaktion und einem Status gibt die Anwendung einen neuen Status zurück.

Für visuelle Hinweise:

Probleme mit der aktuellen Blockchain-Architektur

Stellt sich heraus, dass der Aufbau einer Blockchain von Grund auf mit all diesen 3 Schichten wirklich harte Arbeit ist. Viele Projekte bevorzugten also, indem sie die Bitcoin-Codebasis gabeln. Nun, während dies viel Zeit spart, Tatsache ist, dass sie immer noch von den Einschränkungen des Bitcoin-Protokolls Handschellen gefesselt sind. Natürlich können Sie keine komplexen Projekte ausführen, wenn Sie ein Protokoll verwenden, das für seine Durchsatzprobleme bekannt ist.

Es wurde viel besser, als Ethereum ins Spiel kam. Ethereum gab Entwicklern tatsächlich eine Plattform, die sie verwenden konnten, um ihren eigenen benutzerdefinierten Code aka Smart Contracts und Projekte zu erstellen. Wie bei Bitcoin leidet Ethereum jedoch auch unter dem gleichen Problem. Beide haben monolithische Architektur im Gegensatz zu modularen.

Monolithische Architektur vs Modulare Architektur

Monolithische Architektur bedeutet, dass alles in einem Stück zusammengesetzt ist. Wenn Software als „monolithisch“ betrachtet wird, sind die Komponenten miteinander verbunden und voneinander abhängig und das Design ist eigenständiger. In diesem Fall ist die Architektur stärker gekoppelt und die zugehörigen Komponenten müssen alle vorhanden sein, damit der Code ausgeführt oder kompiliert wird.

Während dies das System, für das es erstellt wurde, robuster macht, können Sie nicht wirklich davon ableiten und benutzerdefinierte Codes erstellen. Es ist nicht das flexibelste System. Außerdem gibt es ein anderes Problem mit diesem System. Wenn eine Komponente des Programms aktualisiert werden muss, muss die gesamte Anwendung überarbeitet werden. Das ist nicht wirklich das ideale für Situationen, oder?

Auf der anderen Seite haben wir eine modulare Architektur. Im Gegensatz zu monolithischen sind die Schichten nicht miteinander verbunden. Obwohl es vielleicht nicht so robust ist, ist es ziemlich einfach, die gesamte Anwendung zu aktualisieren, indem Sie mit den verschiedenen separaten Modulen arbeiten.

Da die Module so unabhängig sind, ermöglicht die modulare Architektur es Ihnen, einen bestimmten Abschnitt tatsächlich zu aktualisieren, ohne unvorhergesehene Änderungen am Rest des Systems zu verursachen. Iterative Prozesse sind auch in modularen Programmen viel einfacher, im Gegensatz zu monolithischen.

Tendermints Architektur und Ziele

Tendermint nutzt die modulare Architektur. Ihre Ziele sind wie folgt:

Bereitstellung der Netzwerk- und Konsensschichten einer Blockchain als Plattform, auf der verschiedene dezentrale Anwendungen erstellt werden können

Entwickler müssen sich nur um die Anwendungsebene der Blockchain kümmern und sparen alle Stunden, die sie verschwendet hätten, an dem Konsens und der Netzwerkschicht zu arbeiten.

Tendermint enthält auch das Tendermint-Konsensprotokoll, das den byzantinischen fehlertoleranten Konsensalgorithmus darstellt, der innerhalb der Tendermint-Core-Engine verwendet wird.

Schauen wir uns an, wie Tendermints Architektur aussehen wird:

Ultimate Guide to Tendermint

Wie Sie sehen können, ist die Anwendung über ein Socket-Protokoll namens APCI oder Application Blockchain Interface mit Tendermint Core verbunden. Da Tendermint Core und die darauf ausgeführte Anwendung in separaten UNIX-Prozessen ausgeführt werden, müssen sie eine Methode haben, um miteinander zu sprechen. ABCI hilft diesen beiden bei der Kommunikation.

Wie sieht das Design von ABCI aus? ABCI wird einige verschiedene Konstruktionskomponenten haben:

#1 Nachrichtenprotokoll

Paare von Anforderungs- und Antwortnachrichten

Anfragen werden durch den Konsens gestellt, während die Anwendung kümmert sich um die Antwort

Es wird mit protobuf definiert

#2 Server/Client

Die Consensus Engine führt den Client aus

Die Anwendung führt den Server

Es gibt zwei richtige Implementierungen: asynchrone rohe Bytes und grpc

#3 Blockchain-Protokoll

ABCI ist sehr verbindungsorientiert. Die drei Anschlüsse für Tendermint Core sind wie folgt:

Mempool-Verbindung: Dieser prüft, ob die Transaktionen weitergeleitet werden sollen, bevor sie festgeschrieben werden. Es kann nur CheckTX verwenden

Konsensverbindung: Diese Verbindung hilft bei der Ausführung von Transaktionen, die festgeschrieben wurden. Nachrichtensequenz ist, für jeden Block, BeginBlock, [DelivertX,...], EndBlock, Commit

Abfrageverbindung: Hilft bei der Abfrage des Anwendungsstatus. In diesem Teil werden nur Query und Info verwendet.

Alles in allem ist das Hauptziel von Tendermint, Entwicklern ein Tool zur Verfügung zu stellen, das nicht nur praktisch ist, sondern auch einen hohen Durchsatz hat. Hier sind die Eigenschaften von Tendermint, die es so verführerisch macht:

#1 Public oder Private Blockchain-kompatibel

Verschiedene Projekte haben unterschiedliche Bedürfnisse. Einige Projekte müssen ein offenes System haben, in dem jeder teilnehmen und mitwirken kann, wie Ethereum. Auf der anderen Seite haben wir Organisationen wie die Medizinindustrie, die ihre Daten nicht jedem zugänglich machen können. Für sie benötigen sie etwas wie die zulässige Blockchain.

Ok, wie kann Tendermint helfen, diese beiden Bedürfnisse zu befriedigen? Denken Sie daran, dass Tendermint nur die Vernetzung und Konsens für die Blockchain behandelt. Also, es hilft in der:

Weitergabe der Transaktion zwischen den Knoten über das Klatschprotokoll

Hilft den Validatoren, sich über den Satz von Transaktionen zu einigen, die an die Blockchain angehängt werden.

Dies bedeutet, dass die Anwendungsschicht frei definiert werden kann, wie die Entwickler sie definieren wollen. Es liegt an den Entwicklern zu definieren, wie der Validatorsatz innerhalb des Ökosystems definiert wird.

Die Entwickler können der Anwendung entweder erlauben, ein Wahlsystem zu haben, das Validatoren wählt, basierend darauf, wie viele native Tokens diese Validatoren innerhalb des Ökosystems gesteckt haben.. aka Proof-of-Stake und erstellen eine öffentliche Blockchain

Außerdem können die Entwickler auch eine Anwendung erstellen, die einen eingeschränkten Satz von vorab genehmigten Validatoren definiert, die sich um den Konsens und die neuen Knoten kümmern, die in das Ökosystem gelangen. Dies wird als Machtnachweis bezeichnet und ist das Markenzeichen einer zulässigen oder privaten Blockchain.

#2 Hohe Leistung

Anwendungen, die über Tendermint Core gemacht werden, können eine außergewöhnliche Leistung erwarten. Tendermint Core hat eine Blockzeit von nur 1 Sekunde. Es kann auch ein Transaktionsvolumen von 10.000 Transaktionen pro Sekunde für 250-Byte-Transaktionen verarbeiten, solange die Anwendung dies zulässt.

#3 Endgültigkeit

Was ist Endgültigkeit?

Einfach ausgedrückt bedeutet das, dass eine bestimmte Aktion nicht zurückgenommen werden kann, sobald eine bestimmte Aktion ausgeführt wurde. Nehmen wir also das Beispiel einer einfachen Finanztransaktion. Angenommen, Sie kaufen einige Aktien in einem Unternehmen, nur weil ein Fehler in ihrem System, sollten Sie nicht verlieren auf das Eigentum Ihrer Aktien. Wie Sie sich vorstellen können, ist die Endgültigkeit für ein Finanzsystem äußerst kritisch. Stellen Sie sich vor, eine Millionen-Dollar-Transaktion zu machen, und am nächsten Tag ist diese Transaktion wegen eines Paniks nicht mehr gültig.

Wie wir bereits erwähnt haben, haben Bitcoin und Ethereum (bis zur vollständigen Implementierung von Casper FFG) nicht wirklich Abrechnungsfinalität. Anlässlich eines Hardfork oder eines 51% -Angriffs haben Transaktionen eine Chance, rückgängig zu werden.

Tendermint, auf der anderen Seite, gibt sofortige Finalität innerhalb von 1 Sekunde nach Abschluss der Transaktion. Gabeln werden niemals im System erstellt, solange weniger als 2/3 der Validatoren bösartig sind. Sobald ein Block erstellt wird (innerhalb einer Sekunde), können die Benutzer sicher sein, dass ihre Transaktion abgeschlossen ist.

#4 Sicherheit

Tendermint ist sicher und zwingt seine Teilnehmer, auch für ihr Handeln verantwortlich zu sein. Wie wir bereits gesagt haben, kann Zärtnerminze niemals gegabelt werden, solange weniger als 2/3 der Validatoren bösartig sind. Wenn in einigen Fällen die Blockchain Fork macht, gibt es eine Möglichkeit, die Haftung zu bestimmen. Außerdem ist Tendermint Konsens nicht nur fehlertolerant, sondern auch optimal byzantinisch fehlertolerant

#5 Einfach zu bedienen

Eine weitere tolle Sache an Tendermint ist seine Benutzerfreundlichkeit. Wie bereits erwähnt, haben sie eine modulare Architektur, in der die Anwendungsebene entsprechend angepasst werden kann. Dies ermöglicht es, bestehende Blockchain-Codebasen mühelos über ABCIs mit Tendermint zu verknüpfen. Das perfekte Beispiel dafür ist Etheremint, der im Grunde der Ethereum Virtual Machine Codebase Plug auf Tendermint ist.

Ethermint funktioniert genau wie Ethereum, profitiert aber auch von allen positiven Funktionen, die wir oben aufgeführt haben. Alle Ethereum Tools wie Metamask und Truffle sind kompatibel mit Ethermint.

#6 Skalierbarkeit

Tendermints Proof-of-Stake-Implementierung ist wesentlich skalierbarer als ein herkömmlicher Proof-of-Work Konsensus-Algorithmus. Der Hauptgrund dafür ist, dass POW-basierte Systeme kein Sharding durchführen können.

Sharding partitioniert eine Datenbank grundsätzlich horizontal und erstellt kleinere Datenbanken oder Shards, die dann parallel von den Knoten ausgeführt werden. Der Grund dafür ist, dass ein starker Mining-Pool leicht über einen Shard nehmen kann.

Tendermint ermöglicht die Implementierung von Sharding, was die Skalierbarkeit erheblich erhöht.

Tendermint Konsensus Protokoll

Ok, schauen wir uns an, wie das Tendermint-Konsensprotokoll funktioniert. Was genau ist ein Konsensprotokoll?

So definiert Wikipedia Konsensentscheidungen:

„Konsensentscheidung ist ein Gruppenentscheidungsprozess, in dem sich die Gruppenmitglieder entwickeln und sich bereit erklären, eine Entscheidung im besten Interesse des Ganzen zu unterstützen. Konsens kann professionell als eine akzeptable Lösung definiert werden, die unterstützt werden kann, auch wenn nicht der „Liebling“ jedes Einzelnen. „Konsens“ wird von Merriam-Webster definiert als, erstens, allgemeines Einvernehmen, und zweitens, Gruppensolidarität des Glaubens oder der Stimmung.“

Einfacher ausgedrückt ist der Konsens ein dynamischer Weg, um eine Einigung in einer Gruppe zu erzielen. Während die Abstimmung nur eine Mehrheitsregel ohne Gedanken über die Gefühle und das Wohlergehen der Minderheit macht, sorgt ein Konsens dagegen dafür, dass eine Einigung erzielt wird, die der gesamten Gruppe als Ganzes zugute kommen könnte.

Von einem idealistischeren Standpunkt aus kann der Konsens von einer Gruppe von Menschen, die auf der ganzen Welt verstreut sind, genutzt werden, um eine gleichberechtigtere und gerechtere Gesellschaft zu schaffen.

Eine Methode, mit der Konsensentscheidungen erzielt werden, wird als „Konsensmechanismus“ bezeichnet.

Nun, was wir definiert haben, was ein Konsens ist, schauen wir uns an, was die Ziele eines Konsensmechanismus sind (Daten aus Wikipedia).

Übereinkommenssuche: Ein Konsensmechanismus sollte so viel Einvernehmen von der Gruppe wie möglich herbeiführen.

Kollaborativ: Alle Teilnehmer sollten zusammenarbeiten, um ein Ergebnis zu erzielen, das das beste Interesse der Gruppe an erster Stelle stellt.

Genossenschaft: Alle Teilnehmer sollten ihre eigenen Interessen nicht an die erste Stelle stellen und mehr als Einzelpersonen als Team arbeiten.

Partizipativ: Der Konsensmechanismus sollte so sein, dass jeder aktiv am Gesamtprozess teilnehmen sollte.

Inklusive: So viele Menschen wie möglich sollten in den Konsensprozess einbezogen werden. Es sollte nicht wie normale Abstimmung sein, bei denen die Leute nicht wirklich Lust auf Abstimmung haben, weil sie glauben, dass ihre Stimme auf lange Sicht kein Gewicht haben wird.

Egalitarisch: Eine Gruppe, die versucht, einen Konsens zu erreichen, sollte so egalitär wie möglich sein. Was das im Grunde bedeutet, dass jede Stimme das gleiche Gewicht hat. Die Stimme einer Person kann nicht wichtiger sein als die andere.

Nun, da wir definiert haben, welche Konsensmechanismen sind und was sie anstreben sollten, müssen wir an den anderen Elefanten im Raum denken.

Welche Konsensmechanismen sollten für eine Entität wie Blockchain verwendet werden?

Vor Bitcoin gab es viele Iterationen von Peer-to-Peer-dezentralen Währungssystemen, die scheiterten, weil sie das größte Problem nicht beantworten konnten, wenn es darum ging, einen Konsens zu erreichen. Dieses Problem wird als „Byzantinischen Generäle Problem“ bezeichnet.

Problem des byzantinischen Generals

Um alles in einem Peer-to-Peer-Netzwerk zu tun, sollten alle Knoten in der Lage sein, zu einem Konsens zu kommen. Die Sache ist aber, damit dieses System funktioniert, legt es viel Wert auf die Menschen, im besten Interesse des gesamten Netzwerks zu handeln. Wie wir jedoch bereits wissen, sind Menschen nicht wirklich vertrauenswürdig, wenn es um ethisches Handeln geht. Hier kommt das Problem des byzantinischen Generals ins Spiel.

Ultimate Guide to Tendermint

Stellen Sie sich diese Situation vor.

Es gibt eine Armee, die eine gut befestigte Burg umgibt. Der einzige Weg, den sie gewinnen können, ist, wenn sie die Burg zusammen als Einheit angreifen. Sie stehen jedoch vor einem großen Problem. Die Armee ist weit voneinander entfernt und die Generäle können nicht wirklich direkt kommunizieren und den Angriff koordinieren und einige der Generäle sind korrupt.

Das einzige, was sie tun können, ist, einen Boten von General zu General zu senden. Allerdings könnte dem Boten eine Menge Dinge passieren. Die korrupten Generäle können den Messenger abfangen und die Nachricht ändern. Also, was können die Generäle tun, um sicherzustellen, dass sie einen koordinierten Angriff starten, ohne sich auf die Ethik jedes einzelnen Generals zu verlassen? Wie können sie auf vertrauenslose Weise zu einem Konsens kommen, um das zu tun, was getan werden muss?

Das ist das Problem des byzantinischen Generals und Satoshi Nakamoto löste dieses Problem mit dem Proof-of-Work (POW) Konsensus-Mechanismus.

Was ist der Arbeitsnachweis?

Lassen Sie uns überprüfen, wie POW mit dem Kontext zu unserem oben angegebenen Beispiel funktioniert. Angenommen, ein General möchte mit einem anderen General kommunizieren. Wie denkst du, wie es untergehen wird?

Eine „Nonce“ wird der ursprünglichen Nachricht hinzugefügt. Die Nonce ist ein zufälliger Hexadezimalwert.

Diese neue Nachricht wird dann gehasht. Angenommen, die Generäle stimmen vorher zu, dass sie nur Nachrichten senden, die, wenn Hashed mit 4 „0“ beginnt.

Wenn der Hashed nicht die gewünschte Anzahl von 0s liefert, wird die Nonce geändert und die Nachricht wird erneut gehasht. Dieser Vorgang wiederholt sich, bis der gewünschte Hash empfangen wird.

Der gesamte Prozess ist extrem zeitaufwendig und benötigt viel Rechenleistung.

Wenn sie nun endlich den Hash-Wert erhalten, erhält der Bote die ursprüngliche Nachricht und die Nonce und soll mit den anderen Generälen kommunizieren. Was passiert also, wenn jemand versucht, die Nachricht abzufangen? Nun, erinnern Sie sich an den Lawineneffekt der Hash-Funktionen? Die Nachricht ändert sich drastisch und da sie nicht mehr mit der erforderlichen Anzahl von „0's beginnt, werden die Leute erkennen, dass die Nachricht manipuliert wurde.

Also, um POW in den Kontext des Krypto-Mining zu stellen:

Die Bergleute versuchen kryptografische Rätsel zu lösen, um der Blockchain einen Block hinzuzufügen.

Der Prozess erfordert viel Aufwand und Rechenleistung.

Die Bergleute präsentieren dann ihren Block dem Bitcoin-Netzwerk.

Das Netzwerk überprüft dann die Authentizität des Blocks, indem es einfach den Hash überprüft, wenn er korrekt ist, wird es an die Blockchain angehängt.

Daher sollte es schwierig sein, die erforderliche Nonce und den Hash zu entdecken, jedoch zu überprüfen, ob es gültig ist oder nicht, einfach sein. Das ist die Essenz des Arbeitsnachweises.

Nun, Sie fragen sich wahrscheinlich, warum sollten die Bergleute ihre Zeit und Ressourcen opfern, um Bitcoins zu minen? Nun, stellt sich heraus, dass sie einen ziemlich gesunden wirtschaftlichen Anreiz haben:

Wenn Sie einen Block entdecken, erhalten Sie eine Blockbelohnung von 12,5 Bitcoins. Die Belohnung halbiert sich alle 210.000 Blöcke.

Sobald Sie einen Block abgebaut haben, werden Sie der temporäre Diktator des Blocks. Sie sind derjenige, der für die Inbetriebnahme von Transaktionen in den Block verantwortlich ist und haben somit Anspruch auf Transaktionsgebühren.

Es gibt nur eine begrenzte Anzahl von Bitcoins da draußen, 21 Millionen, um genau zu sein. Also, was hindert diese Miner daran, alle Bitcoins auf einmal herauszuholen?

Es stellt sich heraus, dass Bitcoin-Mining im Laufe der Zeit immer schwieriger wird. Diese Funktion wird als „Schwierigkeit“ bezeichnet, und die Schwierigkeit des Bergbaus steigt immer weiter, wenn Sie auf Bergbau halten.

Deshalb ist es heute für Solo-Miner ziemlich unmöglich, Bitcoins nur mit ihren Computern zu minen. Bergleute haben sich jetzt zusammengeschlossen und „Mining-Pools“ geschaffen, um ihre Rechenleistung zusammen zu bündeln und als Gruppe zu minieren. Diese Pools verwenden ASICs (Application-Specific Integrated Circuits), die speziell für das Mining von Bitcoins erstellt wurden.

Probleme mit POW

Es gibt drei Hauptprobleme mit den Proof-of-Work Algorithmen. Wir haben darüber bereits im Detail gesprochen, also werden wir nur einen allgemeinen Überblick machen.

Energieverschwendung: Bitcoin verbraucht mehr Energie als Irland und die Slowakische Republik. Diese riesige Energieverschwendung ist eines der Prinzipien von Bitcoin. Es ist Verschwendung wegen der Verschwendung.

Zentralisierung: Wie wir Ihnen bereits gesagt haben, verwendet Bitcoin ASICs für den Bergbau. Das Problem dabei ist, dass ASICs teuer sind, und Pools mit mehr Geld neigen dazu, mehr ASICs und folglich mehr Bergbauleistung zu haben. Daher ist Bitcoin nicht so dezentral, wie es sein will.

Skalierbarkeit: Die Architektur von POW verhindert Skalierbarkeit. Bitcoin verwaltet nur 7 Transaktionen pro Sekunde. Für ein modernes Finanzsystem reicht es einfach nicht aus.

Tendermint eingeben

Um den vielen Problemen mit dem Proof-of-Work-Konsenssystem entgegenzuwirken, schuf Jae Kwon, Absolvent der Informatik und Systemtechnik, Tendermint. Tendermint ist ein rein BFT-basiertes Protokoll, das in einer zulässigen Einstellung mit dem Proof-of-of-Stake (PoS) als zugrunde liegenden Sicherheitsmechanismus integriert ist.

Wegen der Komplexität hat Tendermint fast 4 Jahre gedauert.

Jae Kwon und Tendermint CTO Ethan Buchman wurden von Raft und PBFT inspiriert, um ein Konsenssystem zu schaffen, das das Problem des byzantinischen Generals befriedigt. Es ist

„modelliert als deterministisches Protokoll, live unter partieller Synchronie, das einen Durchsatz innerhalb der Grenzen der Latenz des Netzwerks und der einzelnen Prozesse selbst erreicht.“

In Ordnung, wir wissen, dass das eine Menge komplizierter Wörter sind, die man nacheinander werfen muss, aber um zu verstehen, was Tendermint Konsens ist und warum es so gestaltet wurde, wie es entworfen wurde, müssen Sie verstehen, was einige dieser komplizierten Begriffe bedeuten. Sie werden sehen, wie alle miteinander verbinden wie ein kompliziertes Puzzle.

#1 FLP Unmöglichkeit

Die FLP (Fischer Lynch Paterson) Unmöglichkeit besagt, dass ein Konsensalgorithmus nur 2 der folgenden 3 Eigenschaften haben kann:

Sicherheit

Garantierte Beendigung oder Lebensfähigkeit

Fehlertoleranz

Ultimate Guide to Tendermint

Bildguthaben: Mittel

Mit anderen Worten, die FLP Unmöglichkeit besagt, dass

„Kündigung und Vereinbarung (Betriebsdauer und Sicherheit) können in einem asynchronen verteilten System nicht zeitgebunden befriedigt werden, wenn es mindestens ein Fehler widerstandsfähig sein soll (sie belegen ihr Ergebnis für eine allgemeine Fehlertoleranz, die schwächer ist als die byzantinische Fehlertoleranz, da sie nur einen Fail-Stopp-Knoten — so dass BFT in FLP-Unmöglichkeit Ansprüche enthalten ist).“

Daher ist es im Grunde unmöglich, dass ein asynchrones WAN zu einem Konsens kommt, da es keine bestimmte Zeit gibt, die die Knoten benötigen, um Nachrichten zu empfangen, zu verarbeiten und auf sie zu reagieren. Dies ist offensichtlich ein großes Problem, weil es für ein großes Netzwerk von Knoten wie Bitcoin extrem unpraktisch ist, anzunehmen, dass sie synchronisiert werden.

Okay, also die Synchronität würde ein Problem sein. Allerdings warfen die Forscher Dwork, Lynch und Stockmeyers eine Rettungslinie hierher mit ihrem Papier namens „Konsens in Gegenwart von partieller Synchronie“. Dies wurde DLS Konsens genannt.

#2 DLS Konsens und Teilsynchronität

Das DLS-Papier besagt, dass zwischen einem synchronen System und einem asynchronen System ein spezielles System existiert, das „teilweise synchron“ ist. Da dieses teilweise synchrone System eine obere Grenzzeit angegeben haben kann, kann es ein praktikables BFT-Protokoll entwerfen.

Laut DLS besteht die eigentliche Herausforderung beim Entwerfen von Protokollen darin, eines zu haben, das in einem teilweise synchronen System korrekt funktioniert.

Mal sehen, wie beliebt dezentrale Protokolle wie Bitcoin und Ethereum in dieser Hinsicht funktioniert.

Bitcoin hat eine bekannte Obergrenze, die etwa 10 Minuten beträgt. So wird alle 10 Minuten ein Block von Transaktionen erzeugt. Diese Timing-Annahme wird dem Netzwerk auferlegt, so dass die Knoten 10 ganze Minuten erhalten, um die Informationen zu sammeln und sie über Klatsch zu übertragen.

What is the State machine?

Auf der anderen Seite haben wir Ethereum, das synchrone Annahmen für ihre Blöcke und Netzwerk macht, indem wir eine obere Blockzeit auf 15 Sekunden halten. Mit einer so niedrigen Blockzeit sind sie skalierbarer als Bitcoin, aber sie sind nicht wirklich so effizient. Astraleum Bergleute produzieren viele Waisenblöcke.

#3 Lebensunterbrechung und Beendigung

Die Kündigung ist eine Eigenschaft, die besagt, dass jeder richtige Prozessor schließlich eine Entscheidung treffen sollte. Die meisten Konsensalgorithmen, die wir jetzt haben, stützen sich auf synchrone Modelle für ihre Sicherheit und Beendigung. Sie haben feste Grenzen und Regeln, die bekannt sind, so dass für den Fall, dass sie nicht halten, die Kette in mehrere Protokolle

Sicher gibt es Konsensprotokolle, die in asynchronen Netzwerken funktionieren, aber nach dem FLP-Unmöglichkeitensatz, können sie nicht deterministisch sein. Das bringt uns zu....

#4 Deterministische vs. nicht-deterministische Protokolle

In der Regel hängen rein asynchrone Konsensprotokolle von nicht-deterministischen Mitgliedern wie Orakel ab, die ein hohes Maß an Unsicherheit und Komplexität mit sich bringen.

Wie geht Tendermint mit all diesen Faktoren um?

Tendermint ist ein meist asynchroner, deterministischer BFT-Konsens, bei dem Validatoren einen Anteil haben, der ihre Stimmrechte bezeichnet. Im FLP-Unmöglichkeit Dreieck bevorzugt es Fehlertoleranz und Sicherheit (Konsistenz) gegenüber der Livenität.

Tendermint schwankt ständig zwischen Perioden der Synchronie und Asynchronie. Dies bedeutet, dass, obwohl es auf Timing-Annahmen beruht, um Fortschritte zu erzielen, die Geschwindigkeit des genannten Fortschritts hängt nicht von Systemparametern ab, sondern hängt von der tatsächlichen Netzwerkgeschwindigkeit ab.

Auch, Tendermint Gabeln nie in Gegenwart von Asynchronie, wenn weniger als 1/3 der Validatoren korrupt/sorglos sind. Das ist der Grund, warum Tendermint byzantinisch fehlertolerant ist. Wie wir bereits gesagt haben, konzentriert sich Tendermint auf Sicherheit über der Lebenslosigkeit. Wenn also mehr als ein Drittel der Validatoren bösartig sind, wird die Tendermint-Blockchain anstelle des Netzwerk-Forking einfach vorübergehend zum Stillstand kommen, bis mehr 2/3 -Validatoren zu einem Konsens kommen.

Tendermint ist auch völlig deterministisch und es gibt keine Zufälligkeit im Protokoll. Die Führungskräfte im System werden alle in einer deterministischen Version über eine definierte mathematische Funktion gewählt. So können wir tatsächlich mathematisch beweisen, dass sich das System so verhält, wie es sich verhalten soll.

Tendermint - Der Nachweis des Pfahlsystems

In einem Proof of Stake (POS) System haben wir bestimmte Leute, die „Validatoren“ genannt werden. Diese Validatoren sperren einen Einsatz im System ein. Danach haben sie die Verantwortung, auf den Block zu setzen, von dem sie glauben, dass er neben der Blockchain hinzugefügt wird. Wenn der Block hinzugefügt wird, erhalten sie eine Belohnung, die proportional zu ihrem Einsatz ist.

In Ordnung, so funktioniert ein generisches POS. Sehen wir uns nun an, wie Zärtnerminze funktioniert.

Machen wir uns zunächst mit einigen Begriffen vertraut, die wir verwenden werden:

Ein Netzwerk besteht aus vielen Knoten. Knoten, die mit einem bestimmten Knoten verbunden sind, werden als Peers bezeichnet.

Der Konsensprozess findet in einer bestimmten Blockhöhe H statt. Der Prozess zur Bestimmung des nächsten Blocks besteht aus mehreren Runden.

Die Runde besteht aus vielen Staaten, die sind: NewHeight, Propose, Prevote, Precommit und Commit. Jeder Status wird als Roundstep oder nur „step“ bezeichnet.

Ein Knoten wird gesagt, dass er auf einer bestimmten Höhe, rund und Schritt oder bei (H, R, S) oder bei (H, R) kurz ist, um den Schritt wegzulassen.

Etwas vorab abzustimmen oder vorzusprechen bedeutet, eine Prevovoice-Abstimmung oder eine Precommit-Abstimmung für etwas auszustrahlen.

Wenn ein Block 2/3 der Prevotes bei (H, R) erhält, wird er Proof-of-Lock-Change oder POLC genannt.

Was ist die Staatsmaschine?

Die Staatsmaschine ist sozusagen der Motor des Tendermint-Protokolls. Das folgende Diagramm gibt Ihnen eine gute Vorstellung davon, wie es aussehen wird:

What is the State machine?

Okay, was ist hier los?

Erinnerst du dich an die Staaten, die jede Runde durchläuft? NewHeight, Prompt, Prevote, Precommit und Commit.

Von diesen bestehen „Propose, Prevote, Precommit“ aus einer Runde, während die anderen beiden Sonderrunden sind. In einem idealen Szenario würde sich der Staatsübergang wie folgt verhalten:

NewHeight - (Propose - Prevote - Precommit) + - Commit - NewHeight -...

Aber so kann es nicht immer funktionieren. Es können mehrere Runden erforderlich sein, bevor der Block festgeschrieben wird. Im Folgenden sind die Gründe, warum mehrere Runden benötigt werden können:

Der benannte Antragsteller kann nicht anwesend sein.

Der vorgeschlagene Block könnte ungültig sein.

Der Block breitete sich nicht rechtzeitig aus.

2/3 der Prävotes wurden nicht rechtzeitig von den Validator-Knoten empfangen.

Auch wenn + 2/3 der Präventionsvorschläge notwendig sind, um zum nächsten Schritt voranzukommen, könnte mindestens ein Validator null gewählt haben oder böswillig für etwas anderes gestimmt haben.

2/3 der Precommits für den Block wurden nicht empfangen, obwohl Prevootes möglicherweise empfangen wurden.

Was passiert in jedem Zustand?

Also, nun schauen wir uns jeden einzelnen Staat an und sehen, wie das Ganze zusammenkommt.

Vorschlagen

In diesem Stadium schlägt der benannte Antragsteller, d. h. der ausgewählte Knoten einen Block vor, der bei (H, R) hinzugefügt werden soll. Diese Phase endet auf zwei Arten:

Der Block wird vorgeschlagen und das tritt in die Prevoot-Phase.

Die Zeit des Antragstellers, den Block zu wählen, läuft ab, mit dem er sowieso in die Prevo-Phase eintritt.

Vorabstimmen

Jetzt kommen wir zur Prevoz-Bühne. In diesem Stadium muss jeder Validator eine Entscheidung treffen.

Wenn der Validator irgendwie auf einem vorgeschlagenen Block aus einer vorherigen Runde gesperrt ist, melden sie sich automatisch ab und übertragen diesen Block.

Wenn der Validator einen akzeptablen Vorschlag für die aktuelle Runde erhalten hatte, unterzeichnen und senden ein Prevote für den vorgeschlagenen Block aus.

Wenn sie jedoch etwas Fisches mit dem Vorschlag finden oder überhaupt keinen Vorschlag erhalten haben (zB wenn die Zeit des Antragstellers abgelaufen ist), dann unterschreiben sie mit einem „nil“ Prevote.

In dieser Phase findet keine Blocklockierung statt.

Während dieser Zeit propagieren alle Knoten die Prävotes im gesamten System über das Klatschprotokoll.

Vorbegehen

Jetzt geben wir den letzten Schritt der „Runde“ genannt „precommit“. Beim Eintritt in diese Phase gehen die Validatoren vor ihrer Entscheidung, indem sie ihre Vorurte ausstrahlen. Eines der folgenden drei Szenarien kann passieren:

Wenn der Validator 2/3 der Prävodierungen für bestimmte akzeptable Blöcke erhält, meldet sich der Validator ab und sendet ihr Precommit an den Block aus. Sie werden auch in den Block eingesperrt. Ein Prüfer kann auf jeweils nur einen Block sperren.

Wenn der Validator jedoch mehr als 2/3 von NUL erhält, dann entsperren sie und Precommits werden zu „NIL“.

Schließlich, wenn sie keine Supermehrheit von 2/3 überhaupt erhalten haben, dann unterschreiben sie nichts oder sperren nichts.

Während dieser Phase klatschen die Knoten kontinuierlich über die Precommits im gesamten Netzwerk.

Am Ende, wenn der vorgeschlagene Block mehr als 2/3 Precommits erhält, bewegen wir uns auf den Schritt „Commit“. Wenn sie diese Stufe jedoch nicht erreichen, treten sie in die „Propose“ -Phase der nächsten Runde ein.

Begehen

Der Commit-Status ist kein Teil der „Runde“. Zusammen mit NewHeight ist es eine der beiden Sonderrunden. Während des Commit-Status werden zwei parallele Bedingungen überprüft, um zu sehen, ob sie erfüllt werden oder nicht.

Erstens müssen die Validatoren den Block empfangen, der vom Netzwerk vorab festgeschrieben wurde. Sobald das getan ist, unterschreiben sie und senden ihr Engagement.

Zweitens müssen sie warten, bis sie mindestens 2/3 Precommits für den Block erhalten haben.

Sobald dies getan ist, wird der Block an das Netzwerk gebunden.

NeueHeight

Erhöht die Blockhöhe einfach um 1, um zu zeigen, dass der Block hinzugefügt wurde.

Auswahl der Validatoren

Wie Sie vielleicht schon verstanden haben, ist die Auswahl der anfänglichen Validatoren entscheidend für die Funktion des Kosmos. Also, wie genau werden sie ausgewählt?

Im Gegensatz zu Bitcoin, wo jeder jederzeit ein Bergmann werden kann, gibt es nur so viele Validatoren, die das Tendermint-System aufnehmen kann. Da Validatoren einzeln viele Funktionen ausführen müssen, führt die Erhöhung der Anzahl der Validatoren nur zu Verzögerungen.

Aus diesem Grund entschied sich Cosmos für 100 Validatoren während des Genesis-Tages (d. h. für den Tag der Spendenaktion) zu entscheiden. Die Zahl der Validatoren wird jedes Jahr um 13% steigen, bis 10 Jahre, wenn sie sich auf 300 begleichen wird.

Ultimate Guide to Tendermint

Also, was ist mit Ergebnissen?

Wie im Whitepaper des Kosmos feststeht:

„Tendermint bietet außergewöhnliche Leistung. In Benchmarks von 64 Knoten, die auf 7 Rechenzentren auf 5 Kontinenten verteilt sind, kann Tendermint Consensus Tausende von Transaktionen pro Sekunde verarbeiten, mit Commit-Latenzen in der Größenordnung von ein bis zwei Sekunden. Bemerkenswert ist, dass die Leistung von weit über tausend Transaktionen pro Sekunde auch unter harten kontradiktorischen Bedingungen aufrechterhalten wird, wobei Validatoren abstürzen oder böswillig erstellte Stimmen ausstrahlen.“

Die folgende Grafik untermauern die oben genannte Behauptung:

Casper vs Tendermint

Zusammen mit Tendermint ist Casper eine weitere beliebte Implementierung des POS-Protokolls.

Während Tendermint sich auf Sicherheit konzentriert, liegt Caspers Fokus auf der lebendigen Lebensweise, mit der FLP Unmöglichkeit. Also, was passiert in Casper während einer Gabel?

Casper FFG wird es ermöglichen, dass eine Blockchain weiter gebaut wird, während auch die Eigenschaft hat, dass alle Knoten sich bewusst sind, dass diese Kette nicht abgeschlossen ist. So kann die Blockchain ohne Endgültigkeit verfügbar bleiben. Die Validatoren der Kette haben die Wahl, sich zur Gabelkette zu bewegen. Wenn mehr als 2/3 der Validatoren stimmen, wechseln sie die Ketten.

Plus, Casper hat einen berühmten Schrägmechanismus. Jede Art von böswilligen Angriff wird dazu führen, dass Validatoren ihren Einsatz sofort aufgeschlitzt werden.

Schlussfolgerung

Also, da hast du es. Wir hoffen, dass wir Ihnen so viele wertvolle Informationen wie möglich gegeben haben. Was halten Sie von Tendermint und seinem Potenzial? Sound off auf den Kommentarbereich unten!

Lesezeit: 17 Minuten Cosmos ist eines der vielversprechendsten Projekte da draußen. Mit Leuten wie Jae Kwon und Ethan Buchman in ihrem Team hat es viel Potenzial. Im Herzen und in seiner Seele liegt der Tendermint Core. Tendermint Core kombiniert den Tendermint Konsensus Algorithmus zusammen mit einem p2p Klatsch Protokoll. Wenn Sie also alles zusammen in den Software-Stack legen, erhalten Sie den Tendermint Core zusammen mit der Cosmos-SDK-Anwendungsebene. Wie auch immer, bevor wir weiter reingehen, schauen wir uns an, warum Tendermint so eine Notwendigkeit ist. Bitcoin und Blockchain Als Satoshi Nakamoto Bitcoin schuf, machte er das erste dezentrale kryptographische System. Der bemerkenswerte Teil dieser Entdeckung war, dass er in der Lage war, das Problem des Byzantinischen Generals zu lösen, was einem Wide Area Network (WAN) half, in einer vertrauenslosen Umgebung einen Konsens zu erzielen. Bitcoin verwendete Proof-of-Work Algorithmus, um sich um ihren Konsens zu kümmern. Allerdings kann der Hauptbeitrag von Bitcoin sehr gut darin sein, dass es die ganze Welt in die Blockchain-Technologie eingeführt hat. Eine Blockchain ist, in der einfachsten Form, eine Zeitstempelreihe unveränderlicher Datensätze von Daten, die von einem Cluster von Computern verwaltet wird, die keiner einzelnen Entität gehören. Jeder dieser Datenblöcke (d. h. Block) ist gesichert und durch kryptographische Prinzipien (d.h. Kette) miteinander verbunden. Mit anderen Worten, eine Blockchain ist eine deterministische Zustandsmaschine, die auf Knoten repliziert wird, die sich nicht unbedingt gegenseitig vertrauen. Mit deterministisch meinen wir, dass, wenn die gleichen spezifischen Schritte unternommen werden, es immer zum gleichen Ergebnis führen wird. ZB. 1 + 2 wird immer 3. Also, was bedeutet Staat? Schauen wir uns es wrt Bitcoin und Ethereum an. In Bitcoin ist der Status eine Liste der Salden für jedes Konto, bei der es sich um eine Liste der UTXO (Unausgegeben Transaction Output) handelt. Dieser Zustand wird über Transaktionen geändert, die den Saldo ändern. Auf der anderen Seite ist die Anwendung in Ethereum eine virtuelle Maschine, die Smart Contracts ausführt. Jede Transaktion durchläuft die Ethereum Virtual Machine und ändert den Status entsprechend dem spezifischen Smart Contract, der darin aufgerufen wird. Wenn Sie sich die Architektur der Blockchain-Technologie betrachten, dann werden Sie drei spezifische Ebenen: Netzwerk: Die Verbreitung der Transaktion/Informationen in den Knoten Konsens: Ermöglicht den Knoten, um eine Entscheidung vorausgesetzt 2/3 der Knoten sind nicht-bösartig Anwendung: Verantwortlich für die Aktualisierung der Staat, der eine Reihe von Transaktionen gegeben hat, d. h. die Verarbeitung von Transaktionen. Bei einer Transaktion und einem Status gibt die Anwendung einen neuen Status zurück. Für visuelle Hinweise: Probleme mit der aktuellen Blockchain-Architektur stellt sich heraus, dass das Erstellen einer Blockchain von Grund auf mit all diesen 3 Schichten wirklich harte Arbeit ist. Viele Projekte bevorzugten also, indem sie die Bitcoin-Codebasis gabeln. Nun, während dies viel Zeit spart, Tatsache ist, dass sie immer noch von den Einschränkungen des Bitcoin-Protokolls Handschellen gefesselt sind. Natürlich können Sie keine komplexen Projekte ausführen, wenn Sie ein Protokoll verwenden, das für seine Durchsatzprobleme bekannt ist. Es wurde viel besser, als Ethereum ins Spiel kam. Ethereum gab Entwicklern tatsächlich eine Plattform, die sie verwenden konnten, um ihren eigenen benutzerdefinierten Code aka Smart Contracts und Projekte zu erstellen. Wie bei Bitcoin leidet Ethereum jedoch auch unter dem gleichen Problem. Beide haben monolithische Architektur im Gegensatz zu modularen. Monolithische Architektur vs Modulare Architektur Monolithische Architektur bedeutet, dass alles in einem Stück zusammengesetzt ist. Wenn Software als „monolithisch“ betrachtet wird, sind die Komponenten miteinander verbunden und voneinander abhängig und das Design ist eigenständiger. In diesem Fall ist die Architektur stärker gekoppelt und die zugehörigen Komponenten müssen alle vorhanden sein, damit der Code ausgeführt oder kompiliert wird. Während dies das System, für das es erstellt wurde, robuster macht, können Sie nicht wirklich davon ableiten und benutzerdefinierte Codes erstellen. Es ist nicht das flexibelste System. Außerdem gibt es ein anderes Problem mit diesem System. Wenn eine Komponente des Programms aktualisiert werden muss, muss die gesamte Anwendung überarbeitet werden. Das ist nicht wirklich das ideale für Situationen, oder? Auf der anderen Seite haben wir eine modulare Architektur. Im Gegensatz zu monolithischen sind die Schichten nicht miteinander verbunden. Obwohl es vielleicht nicht so robust ist, ist es ziemlich einfach, die gesamte Anwendung zu aktualisieren, indem Sie mit den verschiedenen separaten Modulen arbeiten. Da die Module so unabhängig sind, ermöglicht die modulare Architektur es Ihnen, einen bestimmten Abschnitt tatsächlich zu aktualisieren, ohne unvorhergesehene Änderungen am Rest des Systems zu verursachen. Iterative Prozesse sind auch in modularen Programmen viel einfacher, im Gegensatz zu monolithischen. Tendermints Architektur und Ziele Tendermint nutzt die modulare Architektur. Ihre Ziele sind wie folgt: Stellen Sie die Netzwerk- und Konsensschichten einer Blockchain als Plattform bereit, auf der verschiedene dezentrale Anwendungen erstellt werden können Entwickler müssen sich nur um die Anwendungsebene der Blockchain kümmern, sparen Sie alle Stunden, die sie verschwendet hätten, am Konsens zu arbeiten und auch die Netzwerkschicht. Tendermint enthält auch das Tendermint-Konsensprotokoll, das ist der byzantinische fehlertolerante Konsensalgorithmus, der innerhalb der Tendermint Core-Engine verwendet wird. Schauen wir uns an, wie die Architektur von Tendermint aussehen wird: Wie Sie sehen können, ist die Anwendung über ein Socket-Protokoll namens APCI mit Tendermint Core verbunden. oder Application Blockchain Interface. Da Tendermint Core und die darauf ausgeführte Anwendung in separaten UNIX-Prozessen ausgeführt werden, müssen sie eine Methode haben, um miteinander zu sprechen. ABCI hilft diesen beiden bei der Kommunikation. Wie sieht das Design von ABCI aus? ABCI wird einige verschiedene Design-Komponenten haben: #1 Message Protocol Paare von Anforderungs- und Antwortnachrichten Anfragen werden durch den Konsens gemacht, während die Anwendung kümmert sich um die Antwort Es wird mit protobuf #2 Server/Client definiert Die Konsensus-Engine führt den Client aus Die Anwendung führt den Server Es gibt zwei richtige Implementierungen: async raw Bytes und grpc #3 Blockchain Protocol ABCI ist sehr verbindungsorientiert. Die drei Verbindungen für Tendermint Core sind wie folgt: Mempool-Verbindung: Diese prüft, ob die Transaktionen weitergeleitet werden sollen, bevor sie festgeschrieben werden. Es kann nur ChecktX Consensus Verbindung verwenden: Diese Verbindung hilft bei der Ausführung von Transaktionen, die festgeschrieben wurden. Nachrichtensequenz ist, für jeden Block, BeginBlock, [DelivertX,...], EndBlock, Commit Query Connection: Hilft bei der Abfrage des Anwendungsstatus. Dieser Teil verwendet nur Query und Info Alles in allem, das Hauptziel von Tendermint ist es, Entwicklern ein Tool zur Verfügung zu stellen, das nicht nur praktisch ist, sondern auch einen hohen Durchsatz hat. Hier sind die Eigenschaften von Tendermint, die es so verführerisch macht: #1 Public oder Private Blockchain Compatible Verschiedene Projekte haben unterschiedliche Bedürfnisse. Einige Projekte müssen ein offenes System haben, in dem jeder teilnehmen und mitwirken kann, wie Ethereum. Auf der anderen Seite haben wir Organisationen wie die Medizinindustrie, die ihre Daten nicht jedem zugänglich machen können. Für sie benötigen sie etwas wie die zulässige Blockchain. Ok, wie kann Tendermint helfen, diese beiden Bedürfnisse zu befriedigen? Denken Sie daran, dass Tendermint nur die Vernetzung und Konsens für die Blockchain behandelt. So hilft es bei der: Propagation der Transaktion zwischen den Knoten über das Klatschprotokoll Hilft den Validatoren, sich über die Menge von Transaktionen zu einigen, die an die Blockchain angehängt wird. Dies bedeutet, dass die Anwendungsschicht frei definiert werden kann, wie die Entwickler sie definieren wollen. Es liegt an den Entwicklern zu definieren, wie der Validatorsatz innerhalb des Ökosystems definiert wird. Die Entwickler können der Anwendung entweder erlauben, ein Wahlsystem zu haben, das Validatoren wählt, basierend darauf, wie viele native Tokens diese Validatoren innerhalb des Ökosystems gesteckt haben.. aka Proof-of-Stake und erstellen eine öffentliche Blockchain Plus, die Entwickler können auch eine Anwendung erstellen, die eine eingeschränkte Menge definiert von vorab genehmigten Validatoren, die sich um den Konsens und die neuen Knoten kümmern, die in das Ökosystem gelangen. Dies wird als Proof-of-Authority bezeichnet und ist das Markenzeichen einer zulässigen oder privaten Blockchain. #2 High Performance Applications, die über Tendermint Core erstellt werden, können außergewöhnliche Leistung erwarten. Tendermint Core hat eine Blockzeit von nur 1 Sekunde. Es kann auch ein Transaktionsvolumen von 10.000 Transaktionen pro Sekunde für 250-Byte-Transaktionen, solange die Anwendung dies zulässt. #3 Finality Was ist Finality? Einfach ausgedrückt bedeutet das, dass eine bestimmte Aktion nicht zurückgenommen werden kann, sobald eine bestimmte Aktion ausgeführt wurde. Nehmen wir also das Beispiel einer einfachen Finanztransaktion. Angenommen, Sie kaufen einige Aktien in einem Unternehmen, nur weil ein Fehler in ihrem System, sollten Sie nicht verlieren auf das Eigentum Ihrer Aktien. Wie Sie sich vorstellen können, ist die Endgültigkeit für ein Finanzsystem äußerst kritisch. Stellen Sie sich vor, eine Millionen-Dollar-Transaktion zu machen, und am nächsten Tag ist diese Transaktion wegen eines Paniks nicht mehr gültig. Wie wir bereits erwähnt haben, haben Bitcoin und Ethereum (bis zur vollständigen Implementierung von Casper FFG) nicht wirklich Abrechnungsfinalität. Anlässlich eines Hardfork oder eines 51% -Angriffs haben Transaktionen eine Chance, rückgängig zu werden. Tendermint, auf der anderen Seite, gibt sofortige Finalität innerhalb von 1 Sekunde nach Abschluss der Transaktion. Gabeln werden niemals im System erstellt, solange weniger als 2/3 der Validatoren bösartig sind. Sobald ein Block erstellt wird (innerhalb einer Sekunde), können die Benutzer sicher sein, dass ihre Transaktion abgeschlossen ist. #4 Security Tendermint ist sicher und zwingt seine Teilnehmer, auch für ihre Handlungen verantwortlich zu sein. Wie wir bereits gesagt haben, kann Zärtnerminze niemals gegabelt werden, solange weniger als 2/3 der Validatoren bösartig sind. Wenn in einigen Fällen die Blockchain Fork macht, gibt es eine Möglichkeit, die Haftung zu bestimmen. Plus, Tendermint Konsens ist nicht nur fehlertolerant, es ist optimal byzantinisch fehlertolerant #5 Einfach zu bedienen Eine weitere tolle Sache an Tendermint ist seine Benutzerfreundlichkeit. Wie bereits erwähnt, haben sie eine modulare Architektur, in der die Anwendungsebene entsprechend angepasst werden kann. Dies ermöglicht es, bestehende Blockchain-Codebasen mühelos über ABCIs mit Tendermint zu verknüpfen. Das perfekte Beispiel dafür ist Etheremint, der im Grunde der Ethereum Virtual Machine Codebase Plug auf Tendermint ist. Ethermint funktioniert genau wie Ethereum, profitiert aber auch von allen positiven Funktionen, die wir oben aufgeführt haben. Alle Ethereum Tools wie Metamask und Truffle sind mit Ethermint kompatibel. #6 Scalability Tendermints Proof-of-Stake-Implementierung ist wesentlich skalierbarer als ein herkömmlicher Proof-of-Work-Konsensus-Algorithmus. Der Hauptgrund dafür ist, dass POW-basierte Systeme kein Sharding durchführen können. Sharding partitioniert eine Datenbank grundsätzlich horizontal und erstellt kleinere Datenbanken oder Shards, die dann parallel von den Knoten ausgeführt werden. Der Grund dafür ist, dass ein starker Mining-Pool leicht über einen Shard nehmen kann. Tendermint ermöglicht die Implementierung von Sharding, was die Skalierbarkeit erheblich erhöht. Tendermint Consensus Protocol Ok, also schauen wir uns an, wie das Tendermint Konsensus Protokoll funktioniert. Was genau ist ein Konsensprotokoll? So definiert Wikipedia Konsensentscheidung: „Konsensentscheidung ist ein Gruppenentscheidungsprozess, in dem Gruppenmitglieder sich entwickeln und sich bereit erklären, eine Entscheidung im besten Interesse des Ganzen zu unterstützen. Konsens kann professionell als eine akzeptable Lösung definiert werden, die unterstützt werden kann, auch wenn nicht der „Liebling“ jedes Einzelnen. „Konsens“ wird von Merriam-Webster definiert als, erstens, allgemeines Einvernehmen, und zweitens, Gruppensolidarität des Glaubens oder der Stimmung.“ Einfacher ausgedrückt ist der Konsens ein dynamischer Weg, um eine Einigung in einer Gruppe zu erzielen. Während die Abstimmung nur eine Mehrheitsregel ohne Gedanken über die Gefühle und das Wohlergehen der Minderheit macht, sorgt ein Konsens dagegen dafür, dass eine Einigung erzielt wird, die der gesamten Gruppe als Ganzes zugute kommen könnte. Von einem idealistischeren Standpunkt aus kann der Konsens von einer Gruppe von Menschen, die auf der ganzen Welt verstreut sind, genutzt werden, um eine gleichberechtigtere und gerechtere Gesellschaft zu schaffen. Eine Methode, mit der Konsensentscheidungen erzielt werden, wird als „Konsensmechanismus“ bezeichnet. Nun, was wir definiert haben, was ein Konsens ist, schauen wir uns an, was die Ziele eines Konsensmechanismus sind (Daten aus Wikipedia). Übereinkommenssuche: Ein Konsensmechanismus sollte so viel Einvernehmen von der Gruppe wie möglich herbeiführen. Kollaborativ: Alle Teilnehmer sollen zusammenarbeiten, um ein Ergebnis zu erzielen, das das Interesse der Gruppe an erster Stelle stellt. Genossenschaft: Alle Teilnehmer sollten ihre eigenen Interessen nicht an die erste Stelle stellen und mehr als Einzelpersonen als Team arbeiten. Partizipativ: Der Konsensmechanismus sollte so sein, dass jeder aktiv am Gesamtprozess teilnehmen sollte. Inklusive: So viele Menschen wie möglich sollten in den Konsensprozess einbezogen werden. Es sollte nicht wie normale Abstimmung sein, bei denen die Leute nicht wirklich Lust auf Abstimmung haben, weil sie glauben, dass ihre Stimme auf lange Sicht kein Gewicht haben wird. Egalitarisch: Eine Gruppe, die versucht, einen Konsens zu erreichen, sollte so egalitär wie möglich sein. Was das im Grunde bedeutet, dass jede Stimme das gleiche Gewicht hat. Die Stimme einer Person kann nicht wichtiger sein als die andere. Nun, da wir definiert haben, welche Konsensmechanismen sind und was sie anstreben sollten, müssen wir an den anderen Elefanten im Raum denken. Welche Konsensmechanismen sollten für eine Entität wie Blockchain verwendet werden? Vor Bitcoin gab es viele Iterationen von Peer-to-Peer-dezentralen Währungssystemen, die scheiterten, weil sie das größte Problem nicht beantworten konnten, wenn es darum ging, einen Konsens zu erreichen. Dieses Problem wird als „Byzantinischen Generäle Problem“ bezeichnet. Problem des Byzantinischen Generals Um alles in einem Peer-to-Peer-Netzwerk zu erreichen, sollten alle Knoten in der Lage sein, zu einem Konsens zu kommen. Die Sache ist aber, damit dieses System funktioniert, legt es viel Wert auf die Menschen, im besten Interesse des gesamten Netzwerks zu handeln. Wie wir jedoch bereits wissen, sind Menschen nicht wirklich vertrauenswürdig, wenn es um ethisches Handeln geht. Hier kommt das Problem des byzantinischen Generals ins Spiel. Stellen Sie sich diese Situation vor. Es gibt eine Armee, die eine gut befestigte Burg umgibt. Der einzige Weg, den sie gewinnen können, ist, wenn sie die Burg zusammen als Einheit angreifen. Sie stehen jedoch vor einem großen Problem. Die Armee ist weit voneinander entfernt und die Generäle können nicht wirklich direkt kommunizieren und den Angriff koordinieren und einige der Generäle sind korrupt. Das einzige, was sie tun können, ist, einen Boten von General zu General zu senden. Allerdings könnte dem Boten eine Menge Dinge passieren. Die korrupten Generäle können den Messenger abfangen und die Nachricht ändern. Also, was können die Generäle tun, um sicherzustellen, dass sie einen koordinierten Angriff starten, ohne sich auf die Ethik jedes einzelnen Generals zu verlassen? Wie können sie auf vertrauenslose Weise zu einem Konsens kommen, um das zu tun, was getan werden muss? Das ist das Problem des byzantinischen Generals und Satoshi Nakamoto löste dieses Problem mit dem Proof-of-Work (POW) Konsensus-Mechanismus. Was ist der Arbeitsnachweis? Lassen Sie uns überprüfen, wie POW mit dem Kontext zu unserem oben angegebenen Beispiel funktioniert. Angenommen, ein General möchte mit einem anderen General kommunizieren. Wie denkst du, wie es untergehen wird? Eine „Nonce“ wird der ursprünglichen Nachricht hinzugefügt. Die Nonce ist ein zufälliger Hexadezimalwert. Diese neue Nachricht wird dann gehasht. Angenommen, die Generäle stimmen vorher zu, dass sie nur Nachrichten senden, die, wenn Hashed mit 4 „0" s beginnt. Wenn der Hashed nicht die gewünschte Anzahl von 0s gibt, wird die Nonce geändert und die Nachricht wird erneut gehashed. Dieser Vorgang wiederholt sich, bis der gewünschte Hash empfangen wird. Der gesamte Prozess ist extrem zeitaufwendig und benötigt viel Rechenleistung. Wenn sie nun endlich den Hash-Wert erhalten, erhält der Bote die ursprüngliche Nachricht und die Nonce und soll mit den anderen Generälen kommunizieren. Was passiert also, wenn jemand versucht, die Nachricht abzufangen? Nun, erinnern Sie sich an den Lawineneffekt der Hash-Funktionen? Die Nachricht ändert sich drastisch und da sie nicht mehr mit der erforderlichen Anzahl von „0's beginnt, werden die Leute erkennen, dass die Nachricht manipuliert wurde. Also, um POW in den Kontext des Krypto-Mining zu stellen: Die Bergleute versuchen, kryptografische Rätsel zu lösen, um der Blockchain einen Block hinzuzufügen. Der Prozess erfordert viel Aufwand und Rechenleistung. Die Bergleute präsentieren dann ihren Block dem Bitcoin-Netzwerk. Das Netzwerk überprüft dann die Authentizität des Blocks, indem es einfach den Hash überprüft, wenn er korrekt ist, wird es an die Blockchain angehängt. Daher sollte es schwierig sein, die erforderliche Nonce und den Hash zu entdecken, jedoch die Überprüfung ob es gültig ist oder nicht, sollte einfach sein. Das ist die Essenz des Arbeitsnachweises. Nun, Sie fragen sich wahrscheinlich, warum sollten die Bergleute ihre Zeit und Ressourcen opfern, um Bitcoins zu minen? Nun, stellt sich heraus, dass sie einen ziemlich gesunden wirtschaftlichen Anreiz haben: Wenn Sie einen Block entdecken, erhalten Sie eine Blockbelohnung von 12,5 Bitcoins. Die Belohnung halbiert sich alle 210.000 Blöcke. Sobald Sie einen Block abgebaut haben, werden Sie der temporäre Diktator des Blocks. Sie sind derjenige, der für die Inbetriebnahme von Transaktionen in den Block verantwortlich ist und haben somit Anspruch auf Transaktionsgebühren. Es gibt nur eine begrenzte Anzahl von Bitcoins da draußen, 21 Millionen, um genau zu sein. Also, was hindert diese Miner daran, alle Bitcoins auf einmal herauszuholen? Es stellt sich heraus, dass Bitcoin-Mining im Laufe der Zeit immer schwieriger wird. Diese Funktion wird als „Schwierigkeit“ bezeichnet, und die Schwierigkeit des Bergbaus steigt immer weiter, wenn Sie auf Bergbau halten. Deshalb ist es heute für Solo-Miner ziemlich unmöglich, Bitcoins nur mit ihren Computern zu minen. Bergleute haben sich jetzt zusammengeschlossen und „Mining-Pools“ geschaffen, um ihre Rechenleistung zusammen zu bündeln und als Gruppe zu minieren. Diese Pools verwenden ASICs (Application-Specific Integrated Circuits), die speziell für das Mining von Bitcoins erstellt wurden. Probleme mit POW Es gibt drei Hauptprobleme mit den Proof-of-Work Algorithmen. Wir haben darüber bereits im Detail gesprochen, also werden wir nur einen allgemeinen Überblick machen. Energieverschwendung: Bitcoin verbraucht mehr Energie als Irland und die Slowakische Republik. Diese riesige Energieverschwendung ist eines der Prinzipien von Bitcoin. Es ist Verschwendung wegen der Verschwendung. Zentralisierung: Wie wir Ihnen bereits gesagt haben, verwendet Bitcoin ASICs für den Bergbau. Das Problem dabei ist, dass ASICs teuer sind, und Pools mit mehr Geld neigen dazu, mehr ASICs und folglich mehr Bergbauleistung zu haben. Daher ist Bitcoin nicht so dezentral, wie es sein will. Skalierbarkeit: Die Architektur von POW verhindert Skalierbarkeit. Bitcoin verwaltet nur 7 Transaktionen pro Sekunde. Für ein modernes Finanzsystem reicht es einfach nicht aus. Geben Sie Tendermint So, um den vielen Problemen mit dem Proof-of-Work-Konsens-System entgegenzuwirken, Jae Kwon, ein Absolvent der Informatik und Systemtechnik, schuf Tendermint. Tendermint ist ein rein BFT-basiertes Protokoll, das in einer zulässigen Einstellung mit dem Proof-of-of-Stake (PoS) als zugrunde liegenden Sicherheitsmechanismus integriert ist. Wegen der Komplexität hat Tendermint fast 4 Jahre gedauert. Jae Kwon und Tendermint CTO Ethan Buchman wurden von Raft und PBFT inspiriert, um ein Konsenssystem zu schaffen, das das Problem des byzantinischen Generals befriedigt. Es ist „modelliert als deterministisches Protokoll, live unter partieller Synchronie, das Durchsatz innerhalb der Grenzen der Latenz des Netzwerks und der einzelnen Prozesse selbst erreicht.“ In Ordnung, wir wissen, dass das eine Menge komplizierter Wörter sind, die man nacheinander werfen muss, aber um zu verstehen, was Tendermint Konsens ist und warum es so gestaltet wurde, wie es entworfen wurde, müssen Sie verstehen, was einige dieser komplizierten Begriffe bedeuten. Sie werden sehen, wie alle miteinander verknüpfen wie ein kompliziertes Puzzle. #1 FLP Unmöglichkeit Die FLP (Fischer Lynch Paterson) Unmöglichkeit besagt, dass ein Konsensalgorithmus nur 2 der folgenden 3 Eigenschaften haben kann: Safety Guaranteed Termination oder Liveness Fault Tolerance Image Credit: Medium In Mit anderen Worten besagt die FLP-Unmöglichkeit, dass „sowohl die Kündigung als auch die Vereinbarung (Livenität und Sicherheit) in einem asynchronen verteilten System nicht zeitgebunden erfüllt werden können, wenn es widerstandsfähig gegenüber mindestens einem Fehler sein soll (sie belegen ihr Ergebnis für eine allgemeine Fehlertoleranz, die schwächer ist als byzantinische Fehlertoleranz, da es nur einen Fail-Stopp-Knoten benötigt — daher ist BFT in FLP-Unmöglichkeitenbehauptungen enthalten).“ Daher ist es im Grunde unmöglich, dass ein asynchrones WAN zu einem Konsens kommt, da es keine bestimmte Zeit gibt, die die Knoten benötigen, um Nachrichten zu empfangen, zu verarbeiten und auf sie zu reagieren. Dies ist offensichtlich ein großes Problem, weil es für ein großes Netzwerk von Knoten wie Bitcoin extrem unpraktisch ist, anzunehmen, dass sie synchronisiert werden. Okay, also die Synchronität würde ein Problem sein. Allerdings Forscher Dwork, Lynch und Stockmeyers warfen eine Rettungslinie hierher mit dem Papier „Konsens in Gegenwart von partieller Synchronie“. Dies hieß DLS Konsens. #2 DLS Consensus and Partial Synchronocity Das DLS Paper besagt, dass zwischen einem synchronen System und einem asynchronen System ein spezielles System existiert, das „teilweise synchron“ ist. Da dieses teilweise synchrone System eine obere Grenzzeit angegeben haben kann, kann es ein praktikables BFT-Protokoll entwerfen. Laut DLS besteht die eigentliche Herausforderung beim Entwerfen von Protokollen darin, eines zu haben, das in einem teilweise synchronen System korrekt funktioniert. Mal sehen, wie beliebt dezentrale Protokolle wie Bitcoin und Ethereum in dieser Hinsicht funktioniert. Bitcoin hat eine bekannte Obergrenze, die etwa 10 Minuten beträgt. So wird alle 10 Minuten ein Block von Transaktionen erzeugt. Diese Timing-Annahme wird dem Netzwerk auferlegt, so dass die Knoten 10 ganze Minuten erhalten, um die Informationen zu sammeln und sie über Klatsch zu übertragen. Auf der anderen Seite haben wir Ethereum, das synchrone Annahmen für ihre Blöcke und Netzwerk macht, indem wir eine obere Blockzeit auf 15 Sekunden halten. Mit einer so niedrigen Blockzeit sind sie skalierbarer als Bitcoin, aber sie sind nicht wirklich so effizient. Astraleum Bergleute produzieren viele verwaiste Blöcke. #3 Liveness and Termination ist eine Eigenschaft, die besagt, dass jeder richtige Prozessor schließlich eine Entscheidung treffen sollte. Die meisten Konsensalgorithmen, die wir jetzt haben, stützen sich auf synchrone Modelle für ihre Sicherheit und Beendigung. Sie haben feste Grenzen und Regeln, die so bekannt sind, dass für den Fall, dass sie nicht halten, die Kette Forks in mehrere Protokolle Sicher gibt es Konsensprotokolle, die in asynchronen Netzwerken arbeiten, aber gehen von der FLP Unmöglichkeit Theorem, sie können nicht deterministisch sein. Das bringt uns zu.... #4 Deterministische vs. Non-deterministische Protokolle Normalerweise hängen rein asynchrone Konsensprotokolle von nicht-deterministischen Mitgliedern wie Orakel ab, die ein hohes Maß an Unsicherheit und Komplexität beinhalten. Wie geht Tendermint mit all diesen Faktoren um? Tendermint ist ein meist asynchroner, deterministischer BFT-Konsens, bei dem Validatoren einen Anteil haben, der ihre Stimmrechte bezeichnet. Im FLP-Unmöglichkeit Dreieck bevorzugt es Fehlertoleranz und Sicherheit (Konsistenz) gegenüber der Livenität. Tendermint schwankt ständig zwischen Perioden der Synchronie und Asynchronie. Dies bedeutet, dass, obwohl es auf Timing-Annahmen beruht, um Fortschritte zu erzielen, die Geschwindigkeit des genannten Fortschritts hängt nicht von Systemparametern ab, sondern hängt von der tatsächlichen Netzwerkgeschwindigkeit ab. Auch, Tendermint Gabeln nie in Gegenwart von Asynchronie, wenn weniger als 1/3 der Validatoren korrupt/sorglos sind. Das ist der Grund, warum Tendermint byzantinisch fehlertolerant ist. Wie wir bereits gesagt haben, konzentriert sich Tendermint auf Sicherheit über der Lebenslosigkeit. Wenn also mehr als ein Drittel der Validatoren bösartig sind, wird die Tendermint-Blockchain anstelle des Netzwerk-Forking einfach vorübergehend zum Stillstand kommen, bis mehr 2/3 -Validatoren zu einem Konsens kommen. Tendermint ist auch völlig deterministisch und es gibt keine Zufälligkeit im Protokoll. Die Führungskräfte im System werden alle in einer deterministischen Version über eine definierte mathematische Funktion gewählt. So können wir tatsächlich mathematisch beweisen, dass sich das System so verhält, wie es sich verhalten soll. Tendermint - Das Proof of Stake System In einem Proof of Stake (POS) System haben wir bestimmte Leute, die „Validatoren“ genannt werden. Diese Validatoren sperren einen Einsatz im System ein. Danach haben sie die Verantwortung, auf den Block zu setzen, von dem sie glauben, dass er neben der Blockchain hinzugefügt wird. Wenn der Block hinzugefügt wird, erhalten sie eine Belohnung, die proportional zu ihrem Einsatz ist. In Ordnung, so funktioniert ein generisches POS. Sehen wir uns nun an, wie Zärtnerminze funktioniert. Machen wir uns zunächst mit einigen Begriffen vertraut, die wir verwenden werden: Ein Netzwerk besteht aus vielen Knoten. Knoten, die mit einem bestimmten Knoten verbunden sind, werden als Peers bezeichnet. Der Konsensprozess findet in einer bestimmten Blockhöhe H statt. Der Prozess zur Bestimmung des nächsten Blocks besteht aus mehreren Runden. Die Runde besteht aus vielen Staaten, die sind: NewHeight, Propose, Prevote, Precommit, und Commit. Jeder Status wird als Roundstep oder nur „step“ bezeichnet. Ein Knoten wird gesagt, dass er auf einer bestimmten Höhe, rund und Schritt oder bei (H, R, S) oder bei (H, R) kurz ist, um den Schritt wegzulassen. Etwas vorab abzustimmen oder vorzusprechen bedeutet, eine Prevovoice-Abstimmung oder eine Precommit-Abstimmung für etwas auszustrahlen. Wenn ein Block 2/3 der Prevotes bei (H, R) erhält, wird er Proof-of-Lock-Change oder POLC genannt. Was ist die Staatsmaschine? Die Staatsmaschine ist sozusagen der Motor des Tendermint-Protokolls. Das folgende Diagramm gibt Ihnen eine gute Vorstellung davon, wie es aussehen wird: Ok, was ist hier los? Erinnerst du dich an die Staaten, die jede Runde durchläuft? NewHeight, Prompt, Prevote, Precommit und Commit. Von diesen bestehen „Propose, Prevote, Precommit“ aus einer Runde, während die anderen beiden Sonderrunden sind. In einem idealen Szenario würde sich der Staatsübergang wie folgt verhalten: NewHeight - (Propose - Prevote - Precommit) + - Commit - NewHeight -... Aber so kann es nicht immer funktionieren. Es können mehrere Runden erforderlich sein, bevor der Block festgeschrieben wird. Im Folgenden sind die Gründe, warum mehrere Runden erforderlich sind: Der benannte Antragsteller kann nicht anwesend sein. Der vorgeschlagene Block könnte ungültig sein. Der Block breitete sich nicht rechtzeitig aus. 2/3 der Prävotes wurden nicht rechtzeitig von den Validator-Knoten empfangen. Obwohl + 2/3 der Prävodierungen notwendig sind, um zum nächsten Schritt voranzukommen, könnte mindestens ein Validator für etwas anderes gestimmt haben oder böswillig gestimmt haben. 2/3 der Precommits für den Block wurden nicht empfangen, obwohl Prävodierungen erhalten wurden. Was passiert in jedem Zustand? Also, nun schauen wir uns jeden einzelnen Staat an und sehen, wie das Ganze zusammenkommt. Vorschlagen In dieser Phase schlägt der benannte Antragsteller, d. h. der ausgewählte Knoten schlägt einen Block vor, der bei (H, R) hinzugefügt werden soll. Diese Phase endet auf eine von zwei Arten: Der Block wird vorgeschlagen und das tritt in die Prevoe-Phase. Die Zeit des Antragstellers, den Block zu wählen, läuft ab, mit dem er sowieso in die Prevo-Phase eintritt. Prevote Jetzt kommen wir zur Prevoot-Phase. In diesem Stadium muss jeder Validator eine Entscheidung treffen. Wenn der Validator irgendwie auf einem vorgeschlagenen Block aus einer vorherigen Runde gesperrt ist, melden sie sich automatisch ab und übertragen diesen Block. Wenn der Validator einen akzeptablen Vorschlag für die aktuelle Runde erhalten hatte, unterzeichnen und senden ein Prevote für den vorgeschlagenen Block aus. Wenn sie jedoch etwas Fisches mit dem Vorschlag finden oder überhaupt keinen Vorschlag erhalten haben (zB wenn die Zeit des Antragstellers abgelaufen ist), dann unterschreiben sie mit einem „nil“ Prevote. In dieser Phase findet keine Blocklockierung statt. Während dieser Zeit propagieren alle Knoten die Prävotes im gesamten System über das Klatschprotokoll. Precommit Jetzt geben wir den letzten Schritt der „Runde“ genannt „precommit“. Beim Eintritt in diese Phase gehen die Validatoren vor ihrer Entscheidung, indem sie ihre Vorurte ausstrahlen. Eines der folgenden drei Szenarien kann passieren: Wenn der Validator 2/3 der Prävodierungen für bestimmte akzeptable Blöcke erhält, meldet sich der Validator ab und sendet ihr Precommit an den Block. Sie werden auch in den Block eingesperrt. Ein Prüfer kann auf jeweils nur einen Block sperren. Wenn der Validator jedoch mehr als 2/3 von NUL erhält, dann entsperren sie und Precommits werden zu „NIL“. Schließlich, wenn sie keine Supermehrheit von 2/3 überhaupt erhalten haben, dann unterschreiben sie nichts oder sperren nichts. Während dieser Phase klatschen die Knoten kontinuierlich über die Precommits im gesamten Netzwerk. Am Ende, wenn der vorgeschlagene Block mehr als 2/3 Precommits erhält, bewegen wir uns auf den Schritt „Commit“. Wenn sie diese Stufe jedoch nicht erreichen, treten sie in die „Propose“ -Phase der nächsten Runde ein. Commit Der Commit-Status ist kein Teil der „Runde“. Zusammen mit NewHeight ist es eine der beiden Sonderrunden. Während des Commit-Status werden zwei parallele Bedingungen überprüft, um zu sehen, ob sie erfüllt werden oder nicht. Erstens müssen die Validatoren den Block empfangen, der vom Netzwerk vorab festgeschrieben wurde. Sobald das getan ist, unterschreiben sie und senden ihr Engagement. Zweitens müssen sie warten, bis sie mindestens 2/3 Precommits für den Block erhalten haben. Sobald dies getan ist, erhält der Block an das Netzwerk gebunden. NewHeight erhöht einfach die Blockhöhe um 1, um zu zeigen, dass der Block hinzugefügt wurde. Die Auswahl der Validatoren Wie Sie vielleicht bereits verstanden haben, ist die Auswahl der anfänglichen Validatoren entscheidend für die Funktion des Kosmos. Also, wie genau werden sie ausgewählt? Im Gegensatz zu Bitcoin, wo jeder jederzeit ein Bergmann werden kann, gibt es nur so viele Validatoren, die das Tendermint-System aufnehmen kann. Da Validatoren einzeln viele Funktionen ausführen müssen, führt die Erhöhung der Anzahl der Validatoren nur zu Verzögerungen. Aus diesem Grund entschied sich Cosmos für 100 Validatoren während des Genesis-Tages (d. h. für den Tag der Spendenaktion) zu entscheiden. Die Zahl der Validatoren wird jedes Jahr um 13% steigen, bis 10 Jahre, wenn sie sich auf 300 begleichen wird. Also, was ist mit Ergebnissen? Wie das Whitepaper des Kosmos sagt: „Tendermint bietet außergewöhnliche Leistungen. In Benchmarks von 64 Knoten, die auf 7 Rechenzentren auf 5 Kontinenten verteilt sind, kann Tendermint Consensus Tausende von Transaktionen pro Sekunde verarbeiten, mit Commit-Latenzen in der Größenordnung von ein bis zwei Sekunden. Bemerkenswert ist, dass die Leistung von weit über tausend Transaktionen pro Sekunde auch unter harten kontradiktorischen Bedingungen aufrechterhalten wird, wobei Validatoren abstürzen oder böswillig erstellte Stimmen ausstrahlen.“ Die folgende Grafik unterstützt den oben gemachten Anspruch: Casper vs Tendermint Zusammen mit Tendermint ist Casper eine weitere beliebte Implementierung des POS-Protokolls. Während Tendermint sich auf Sicherheit konzentriert, liegt Caspers Fokus auf der lebendigen Lebensweise, mit der FLP Unmöglichkeit. Also, was passiert in Casper während einer Gabel? Casper FFG wird es ermöglichen, dass eine Blockchain weiter gebaut wird, während auch die Eigenschaft hat, dass alle Knoten sich bewusst sind, dass diese Kette nicht abgeschlossen ist. So kann die Blockchain ohne Endgültigkeit verfügbar bleiben. Die Validatoren der Kette haben die Wahl, sich zur Gabelkette zu bewegen. Wenn mehr als 2/3 der Validatoren stimmen, wechseln sie die Ketten. Plus, Casper hat einen berühmten Schrägmechanismus. Jede Art von böswilligen Angriff wird dazu führen, dass Validatoren ihren Einsatz sofort aufgeschlitzt werden. Fazit Also, da haben Sie es. Wir hoffen, dass wir Ihnen so viele wertvolle Informationen wie möglich gegeben haben. Was halten Sie von Tendermint und seinem Potenzial? Sound off auf den Kommentarbereich unten!

Like what you read? Give us one like or share it to your friends

1

1
Discussion

Please to comment
Nicolas Cantu
Member
Blocks:0
Nicolas Cantu

Ultra great article ! The most easiest way to try:… Read more »

Join Blockgeeks

Create an account to access our exclusive point system, get instant notifications for new courses, workshops, free webinars and start interacting with our enthusiastic blockchain community. Don’t miss out and join right now!

Already have an account? Sign In