Bitcoins Peer To Peer wie im Detail?

Moin,

gern nehme auch gern Linkempfehlungen an; evtl. vermischen sich mehrere Fragestellungen:

Was genauer versteht Bitcoin unter Peer To Peer allgemein oder genauer in Hinblick auf: wie finden Validierungssprozesse der Nodes bei Bitcoin statt? Es wird immer hingenommen, dass es sich um ein Peer to Peer handelt, allerdings gibt es da auch Unterschiede in der - ich nenne es mal - Prozesskette (senden, Protokoll, Acknowledgment, usw.). Mir sind Verfahren bekannt TCP (ISO OSI).

Fragen:

Herrscht ein Round Robin Algorithmus oder ein „kürzester Weg“-Algorithmus? Heißt, werden Miner begünstigt, die einen geografischen Vorteil haben?
Wie und wann findet Synchronisation im Netzwerk statt? Wann ist ein Validierungsprozess wirklich dezentral (Multicast nicht möglich, weil TCP → P to P)? Werden Anfragen broadcastet in das gesamte Netzwerk verschickt und das Abarbeiten sind die Folge einzelner Peer to Peer Verbindungen (asynchron)? Wie halten einzelne Rechner Nachrichten vor, die abgearbeitet werden (Queuing auf Memory- oder Storage-Ebene)?

Grüße,
aka rwels scala

Nicht direkt. Allerdings willst du als Miner möglichst schnell alle Transaktionen und neue Blöcke kennen. D.h. du bist an guter Konnektivität im Netzwerk interessiert.

Das ist eine Art gossip protocol:

Wenn du lieber lesen willst, als Blocktrainer binge watchen, schau mal hier:

Eine formale Erklärung des Protokolls findest du hier:
https://en.bitcoin.it/wiki

1 „Gefällt mir“

Top! Danke!

Vor allem in Bezug auf

Werden Anfragen broadcastet in das gesamte Netzwerk verschickt und das Abarbeiten sind die Folge einzelner Peer to Peer Verbindungen (asynchron)? Wie halten einzelne Rechner Nachrichten vor, die abgearbeitet werden (Queuing auf Memory- oder Storage-Ebene)?

wird weiter unten die Fragen im Großen und Ganzen mit Diffusion beantwortet, wie das Netzwerk Lastspitzen vermeidet bzw. welche Art von Floodprotection eingebaut ist.

Das finde ich auch einen sehr interessanten Punkt, generell bei Peer-to-Peer Netzwerken!

Da es Cardano noch nicht so lange gibt, kann man dort beobachten, welche Auswirkungen verschiedene Parameter haben. Das ist kein Bitcoin, aber vielleicht von den Grundgedanken und -problemen her trotzdem interessant.

Bei Cardano werden durch eine Zufallsfunktion in jedem Slot (Slot-Länge = 1 s) ein oder mehrere Slot Leader bestimmt, die einen Block erzeugen dürfen. Da in einem Slot mehrere Block Producer Nodes das Zufallskriterium erfüllen können, gibt es hin und wieder Slot Battles, d.h. beide produzieren einen Block.

Zu Beginn im Testnetz (ITN) war es noch so, dass dann der Block gewählt wurde, der am schnellsten im Großteil des Netzwerks verteilt war. Das hat natürlich die Stake Pool Betreiber einerseits geärgert, da sie evtl. früher dran, aber trotzdem verloren haben. Andererseits hat es dazu geführt, dass viele versucht haben einen möglichst „zentralen“ Serverstandort zu haben. Dadurch haben sich Nodes auf Servern in Rechenzentren um Frankfurt zentralisiert. Diese die Zentralisierung auf einige Hosting Anbieter und auf eine Region ist natürlich unschön.

Im Cardano Mainnet wurde das geändert. Bei mehreren Blöcken im gleichen Slot wird vom Protokoll heutzutage zufällig entschieden welcher gültig bleibt, unabhängig von Time Delays. D.h. in Bezug auf Slot Battles ist der Server Standort nicht mehr entscheidend.

Außerdem ist die Cardano Zufallsfunktion so parametriert, dass es im Mittel nur alle 20 Slots einen Slot Leader gibt (20 s). Trotzdem kann es durch Zufälligkeit auch in näher aneinander liegenden Slots dazu kommen, dass Slot Leader bestimmt werden. Das ist Vergleichbar zur mittleren Zeit von 10 min bei Bitcoin.

Erstellt ein Stake Pool im Slot n den Block k, kann es vorkommen, dass im Slot n+1 schon wieder ein Block von einer anderen Node erzeugt wird, aber der Block k bei dieser Node noch nicht bekannt ist, da er nicht schnell genug über das Netzwerk übertragen wurde („Height Battles“). Der Block k wird dann verworfen (Longest Chain Selection Rule).
Auch aus diesem Grund ist es wichtig, dass jede Block Producer Node möglichst gut an das restliche Netz angebunden ist.

Bzgl. der Cardano Slot Battles ist die Cardano Lösung aktuell ähnlich fair wie Bitcoin, da unabhängig vom exakten Zeitpunkt der Blockerstellung und der Block Propagation Time (abhängig von Network Latency) zufällig bestimmt wird, welcher Block gültig ist.
Wenn bei Bitcoin zwei Blöcke fast gleichzeitig gefunden und im Netzwerk verteilt werden, ist es auch eine Art Zufallsentscheidung, für welchen Block zuerst ein Nachfolger gefunden wird.

Auch bei den Cardano Height Battles verhält es sich ähnlich zu Bitcoin. Wenn die Block Propagation Time über das Netzwerk zu groß ist, habe ich ein erhöhtes Risiko den produzierten Block zu verlieren.
Wenn bei Bitcoin zwei Blöcke fast gleichzeitig gefunden werden, ist auch der Miner im Vorteil, der seinen Block schneller in einem größeren Teil des Netzwerks verteilen kann.

Bei Cardano hätte man den kleinen Vorteil, dass man komplett unabhängig von der Network Latency werden könnte (optimal für Dezentralität), indem man sicherstellt, dass ausreichend Zeit zwischen zwei aktiven Slots ist.
Das müssten allerdings dann mindestens 5…10 s sein. Hierzu gibt es interessante praktische Tests und Analysen von IOHK, die in der zweiten Hälfte dieses Videos gezeigt werden. Es dauert doch länger als man denkt, um etwas bis in die entferntesten Punkte des Internets zu übertragen.

Es wird aber sicher Gründe geben, die ich nicht kenne, warum man das nicht macht.

Falls ihr Fehler seht, immer her damit. Ich bin da beileibe kein Experte.

1 „Gefällt mir“