explicitClick to confirm you are 18+

Folge 12.3: Konsens III (PoET, PoH, BFT, pBFT, FBA, dBFT)

kryptokabinettNov 27, 2018, 1:52:39 PM
repeatthumb_upthumb_down

kryptokabinett.at ist ein Podcast/blog der sich an Anfänger und Neueinsteiger richtet.

Hallo! 

...und Willkommen!

Das ist die Nachlese der 12. Folge des kryptokabinett.at-Podcasts zum Thema: Konsensmethoden

PODCAST:

https://kryptokabinett.blogspot.com/2018/07/folge-12-konsensusethoden-in-der-12.html

In diesem dritten Post zur 12. Folge des Podcasts gibt es grundlegende Infos zu den Konsensusmethoden Proof of Elapsed Time (PoET), Proof of History (PoH), Byzantinische Fehlertoleranz (BFT), Federated Byzantine Agreement (FBA) und die Delegierte Byzantinische Fehlertoleranz (dBFT).


7.) PROOF OF ELAPSED TIME (PoET)

Der Proof of Elapsed Times (PoET) – Prüfung der abgelaufenen Zeit.

Jeder teilnehmende Node im Netzwerk generiert eine zufällige Wartezeit und wird für die angegebene Dauer in den Ruhezustand versetzt.

Derjenige, der zuerst aufwacht - also der mit der kürzesten Wartezeit - wacht auf und sendet einen neuen Block an die Blockchain, der die notwendigen Informationen an das gesamte Peer-Netzwerk sendet. Derselbe Prozess wiederholt sich dann bei jedem Block.

Wichtig ist hierbei das die gewählte Zeitdauer auch wirklich zufällig generiert und auch tatsächlich eingehalten wird und nicht absichtlich früher erwacht.

PoET ist ein Konsens-Mechanismus der in permissioned Blockchains verwendet wird. In Permissiond Blockchains müssen sich die User zuerst identifizieren bevor sie Zugang erhalten. Wie z.B. bei sawtooth.

Vorteile: ...Kostenkontrolle und Schnelligkeit

Nachteile: ...es wird spezielle Hardware benötigt und ist vor allem nur für private Blockchains geeignet.


8.) PROOF OF HISTORY (PoH)

Der Proof of History (PoH) – Die Prüfung an der Geschichte.

Hier ist die Grundidee diese, das für eine Transaktion kein Zeitstempel benötigt wird solange man nachweisen kann welche Ereignisse vor bzw. nach der Transaktion stattfanden.

Es wird also ein historischer Datensatz erstellt der belegt wann welche Ereignisse stattfanden.

Wir können so sicher sein, dass zwischen jedem Zähler, wie er erzeugt wurde, Echtzeit vergangen ist und dass die aufgezeichnete Reihenfolge jedes Zählers derselbe ist wie in Echtzeit.

PoH wird von Solana verwendet.


9.) BYZANTINE FAULT TOLERANCE (BFT)

Die Byzantinische Fehlertoleranz (BFT) ist ein klassisches Problem des verteilten Rechnens, das normalerweise mit der Geschichte der byzantinischen Generäle erklärt wird:

Das Problem ist, dass mehrere byzantinische Generäle und ihre jeweiligen Teile der byzantinischen Armee eine Stadt belagert haben. Sie müssen nun gemeinsam entscheiden, ob sie angreifen wollen oder nicht. Wenn einige Generäle ohne die anderen angreifen, endet ihre Belagerung in einer Tragödie und sie verlieren.

Die Generäle sind durch weite Entfernungen getrennt und müssen Nachrichten zur Kommunikation über die anderen Generäle weitergeben.

Es liegt nun daran zu entscheiden ob die Generäle lügen – oder die Wahrheit sagen bzw. ob ihre Nachrichten, welche über die anderen Generäle gehen gefälscht oder original sind.

Einige Cryptocurrency-Protokolle verwenden jeweils eigene Versionen von BFT, um zu einer Übereinstimmung zu kommen, jede mit ihren eigenen Vor- und Nachteilen:


Practical Byzantine Fault Tolerance (pBFT):

Eine der ersten Lösungen für dieses Problem wurde geprägt durch die praktische byzantinische Fehlertoleranz. Derzeit im Einsatz von Hyperledger Fabric, mit wenigen (<20) vorgewählten Generälen.

pBFT läuft unglaublich effizient. Und hat einen hohen Transaktionsdurchsatz Nachteile: ...sehr zentralisiert, es sind nur genehmigte Nodes (Generäle) eingesetzt.


Federated Byzantine Agreement (FBA):

Das FBA ist eine andere Klasse von Lösungen für das Problem der byzantinischen Generäle, das von Währungen wie Stellar und Ripple verwendet wird. Die allgemeine Idee ist, dass jeder byzantinische General für seine eigene Blockchain verantwortlich ist und Transaktionen sortiert wenn diese hereinkommen, um die Wahrheit zu etablieren.

Bei Ripple werden die Generäle (Validatoren) von der Ripple-Foundation vorausgewählt und bei Stellar kann jeder ein Validierer sein.

Ein unglaublicher Durchsatz, niedrige Transaktionskosten und Netzwerkskalierbarkeit sind die Vorteile. Bei Ripple spricht die Zentralisierung durch ihre Spezialisierung auf den Fiat-Bankensektor eher zu Nachteilen.


Delegierte Byzantinische Fehlertoleranz (dBFT)

Hier werden die Generäle durch die Coin-Besitzer gewählt und erst diese gewählten Generäle führen den BFT-Konsensus durch. Wird von NEO benutzt und ist sehr schnell und skalierbar.

Bei NEO werden die General-Nodes auch identifiziert (als Personen bzw. Firmen) und somit wird auch Regulierungen von Regierungsstellen/Gesetzen entsprochen.


Im Vierten Teil der Nachlese geht es um Directed  acyclic Graphs (DAG), Hashgraph und Block-Lattice...

Hier gehts zurück zum Ersten Teil der Konsensusmethoden.

Hier gehts zurück zum Zweiten Teil der Konsensusmethoden.




Proof of History

https://medium.com/solana-labs/proof-of-history-a-clock-for-blockchain-cf47a61a9274

https://solana.io/

BFT

https://web.archive.org/web/20170205142845/http://lamport.azurewebsites.net/pubs/byz.pdf

Practical Byzantine Fault Tolerance (pBFT)

http://pmg.csail.mit.edu/papers/osdi99.pdf

https://www.hyperledger.org/projects/fabric

Federated Byzantine Agreement (FBA)

https://www.stellar.org/

https://ripple.com/

Delegierte Byzantinische Fehlertoleranz (dBFT)

https://github.com/neo-project/docs/blob/master/en-us/index.md#neo-technology-implementation

https://neo.org/


https://www.minds.com/blog/view/904042026608390144


Ich bin über http://kryptokabinett.at , und ebenfalls über über Twitter und facebook erreichbar und würde mich über Likes und Kommentare freuen:

https://www.facebook.com/KryptoKabinett/

https://twitter.com/kryptokabinett


Alle bisherigen Podcastfolgen sind auf kryptokabinett.at abrufbar bzw. kann man den Podcast über folgenden RSS-Feed abonnieren:

http://feeds.soundcloud.com/users/soundcloud:users:336006123/sounds.rss

Nachtrag:

Der Podcast wurde im Juli 2017 aufgenommen und im November 2018 transkribiert.


Viel Spaß beim Nachlesen!
...und haltet Eure Privatekeys sicher!!! :)