Folgendes habe ich gelesen:
Beide Forks erzeugen einen Split, aber ein Hard Fork erzeugt zwei Blockchains und ein Soft Fork soll zu einer führen.
Betrachten wir 2 Situationen:
Die maximale Blockgröße beträgt 1 MB und Bitcoin hat eine neue Version eingeführt, die die Blockgröße um 1 erhöht hat, sodass sie jetzt 2 MB beträgt. Nun, dies wird als Hard Fork bezeichnet, da neue Versionen nicht mit den alten kompatibel wären, denn wenn neue Versionen einen Block (sagen wir 1,5 MB) lösen, würden alte es nicht akzeptieren. (HINWEIS: Wenn alte Blöcke an neue senden (da alte nur Blöcke mit weniger als 1 lösen würden, würden neue es immer akzeptieren)); Neue können also nicht mit alten kommunizieren, aber alte können mit neuen kommunizieren.
Die Blockgröße betrug 1 MB und jetzt haben wir sie um 0,5 verringert, sodass sie jetzt 0,5 MB beträgt. Jetzt sind neue Versionen mit den alten kompatibel, denn neue Versionen würden immer Blöcke mit 0,5 MB oder weniger lösen und wenn sie es an alte senden, würden sie es akzeptieren. (HINWEIS: Wenn alte Blöcke an neue senden (da alte Blöcke möglicherweise mit 0,8 MB lösen, würden neue sie nicht akzeptieren)); Neue können also mit alten kommunizieren, aber alte nicht mit neuen.
Stimmen Sie dem oben Gesagten zu? Wenn ja, warum heißt es in meinem ersten Satz: that a soft work is meant to result in one? Es wird nicht zu einer führen, denn wenn alte Blöcke größer als 0,5 MB lösen, würden neue es nicht akzeptieren, also hätten wir immer noch eine andere Version von Blockchains. Irgendeine Idee?
UPDATE: @Murch, Sie sagen im zweiten, dass, da die kleinen Blöcke (von neuen Knoten) für die alten Knoten akzeptabel sind, große Blockknoten in die kleine Blockkette reorganisiert werden.
Wenn eine 5%-Minderheit (die an alten großen Blockketten arbeiten) einen Block löst, werden ihn nur diese 5%-Knoten zu ihren Ketten hinzufügen. 95 % tun dies nicht, da sie eine kleinere Begrenzung der Blockgröße haben. Jetzt haben 5 % der Minoritätsknoten den letzten Block, der sich vom letzten Block der 95 %-Mehrheit unterscheidet. (Die Länge beider Ketten ist gleich - das könnte gewesen sein, da nach dem Teilen der Ketten 5 % es im selben Seed wie 95 % gelöst haben an ihrer jeweiligen Kette). Wenn die Mehrheit von 95 % jetzt einen neuen Block produziert und ihn mit 5 % teilt, werden sie ihn immer noch nicht hinzufügen, da der Prev-Hash dieses neu geteilten Blocks nicht mit dem Hash ihres letzten Blocks übereinstimmt. In diesem Fall wird also die Mehrheit von 95% schneller einen neueren Block produzieren (zumindest jetzt sind die Längen nicht gleich), also teilt die Mehrheit jetzt 2-3 Blöcke mit der Minderheit, da sie die längste Kette hat, und deshalb wird die Minderheit dies tun sich an die Mehrheit anpassen s Kette am Ende. Ist meine Erklärung und mein Verständnis korrekt?
Ihre Beobachtung ist richtig, außer dass erwartet wird, dass ein Fork von einer großen Mehrheit von Nodes und Minern im Netzwerk aktiviert wird. Die jüngste Soft Fork hatte eine Aktivierungsschwelle von 950 Blöcken in bestimmten Segmenten von 1.000 Blöcken, was die Bereitschaft (95 % Hashrate) für die neuen Regeln signalisiert.
Unter der Annahme, dass nur 5 % der Mining-Power die neuen Regeln nicht befolgen:
Erhöhen der Blockgröße : 95 % der Mining-Power erlauben jetzt größere Blöcke, 5 % erzwingen weiterhin das kleinere Limit. Sobald ein Block mit den neuen Regeln gefunden wird, verwerfen die alten Nodes, die keine größeren Blöcke zulassen, die Hauptkette und starten ihre eigene Kettenspitze. Die Minderheitskette bewegt sich viel langsamer und wird daher von der Mehrheit der Bergleute und Knoten ignoriert. Unter der Annahme, dass die Anteile der Spaltung stabil bleiben, bleiben die beiden Ketten unversöhnlich. Um die Spaltung des Netzwerks zu beheben, müsste eine Seite die Regeln der anderen Seite einräumen und übernehmen.
Verringern der Blockgröße: Etwa 1 von 20 Blöcken wird die von der Mehrheit durchgesetzte Grenze überschreiten. Nur Knoten, die noch die alten Regeln verwenden, akzeptieren den größeren Block, alle anderen Knoten ignorieren ihn. Die Mehrheit der Hashrate wird die Big-Block-Minderheit schnell überholen. Da die kleinen Blöcke für die alten Knoten akzeptabel sind, werden große Blockknoten in die kleine Blockkette reorganisiert, sobald diese Kettenspitze einen umfassenderen Arbeitsnachweis hat. Da sich die Schwierigkeit zwischen Kettenspitzen nur über Schwierigkeitsanpassungen unterscheiden kann, passiert dies in der Regel immer dann, wenn die kleine Blockkette um einen Block in der Höhe nach vorne zieht. Da der Big Block nun Teil einer veralteten Kettenspitze wird, verliert der Miner, der den Big Block erstellt hat, seine Blockbelohnung. Wenn also eine kurze Chainfork mit großen Blöcken auftritt, konvergiert das Netzwerk schließlich wieder auf die kleinere Chain.
Soft Fork und Hard Fork sind hier, wenn man es genau nehmen will, Aussagen über die Bedingungen , unter denen sich alle Nodes garantiert irgendwann auf die gleiche Chain einigen. Es geht also darum, dauerhafte Gabelungen zu vermeiden und die Bedingungen, um sie zu vermeiden. Temporäre Aufteilungen sind immer möglich, auch wenn überhaupt keine Konsensänderung vorliegt.
Eine Änderung der Konsensregel wird als Soft-Forking-Änderung bezeichnet, wenn garantiert ist, dass keine dauerhafte Spaltung auftritt, wenn eine Mehrheit der Hashrate die neue Änderung annimmt. Es sind Mechanismen vorhanden, mit denen Miner ihre Bereitschaft signalisieren können, und die Aktivierung erfolgt normalerweise nur, wenn eine große Mehrheit der Hashrate signalisiert. Dies ist der Fall, wenn neue Blöcke sowohl von alten als auch von neuen Nodes akzeptiert werden, denn selbst wenn alte Nodes weiter minen, werden sie es nie schaffen, die längere Kette aufzubauen – stattdessen werden die neuen Nodes sie übertreffen und die alten wechseln zu Aufbauend auf der Mehrheitskette der neuen Knoten nach jedem Block.
Eine Hard Forking-Änderung ist eine Änderung, bei der die Mehrheit der Hashrate, die sie annimmt, nicht ausreicht. Diese erfordern normalerweise effektiv eine 100-prozentige Übernahme der Hashrate (oder häufiger eine 100-prozentige Übernahme der Node-Software).
Nika Kuraschwili
Mursch