Eines der wichtigen Argumente im Blockchain-Bereich ist die Frage, ob Hard Forks oder Soft Forks der bevorzugte Protokoll-Upgrade-Mechanismus sind. Der grundlegende Unterschied zwischen den beiden besteht darin, dass Soft Forks die Regeln eines Protokolls ändern streng reduzieren Der Satz an Transaktionen, der gültig ist, sodass Knoten, die den alten Regeln folgen, weiterhin in die neue Kette gelangen (vorausgesetzt, dass die Mehrheit der Miner/Validatoren den Fork implementiert), wohingegen Hard Forks ermöglichen, dass zuvor ungültige Transaktionen und Blöcke gültig werden, also Clients müssen ihre Kunden upgraden, um in der Hard-Fork-Kette zu bleiben. Es gibt auch zwei Unterarten von Hard Forks: streng expandierend Hard Forks, die die Menge der gültigen Transaktionen strikt erweitern, sodass die alten Regeln effektiv eine Soft Fork in Bezug auf die neuen Regeln sind, und bilateral Hard Forks, bei denen die beiden Regelsätze in beide Richtungen inkompatibel sind.

Hier ist ein Venn-Diagramm zur Veranschaulichung der Fork-Typen:

Die für beide häufig genannten Vorteile sind folgende.

• Hard Forks ermöglichen den Entwicklern viel mehr Flexibilität bei der Durchführung des Protokoll-Upgrades, da sie nicht darauf achten müssen, dass die neuen Regeln in die alten Regeln „passen“.
• Soft Forks sind für Benutzer bequemer, da Benutzer kein Upgrade durchführen müssen, um in der Kette zu bleiben
• Weiche Gabeln führen seltener zu einem Kettenriss
• Soft Forks erfordern wirklich nur die Zustimmung von Minern/Validatoren (denn selbst wenn Benutzer immer noch die alten Regeln verwenden, wenn die Knoten, die die Kette bilden, die neuen Regeln verwenden, gelangen auf jeden Fall nur Dinge in die Kette, die nach den neuen Regeln gültig sind); harte Gabeln erfordern Opt-in Einwilligung der Nutzer

Abgesehen davon ist ein Hauptkritikpunkt an Hard Forks oft, dass Hard Forks „zwanghaft“ seien. Die hier implizierte Art von Zwang ist keine physische Gewalt; vielmehr ist es so Zwang durch Netzwerkeffekt. Das heißt, wenn das Netzwerk die Regeln von A nach B ändert, müssen Sie, selbst wenn Sie persönlich A mögen, wenn die meisten anderen Benutzer B mögen und zu B wechseln, trotz Ihrer persönlichen Ablehnung der Änderung zu B wechseln, um eingeschaltet zu werden das gleiche Netzwerk wie alle anderen.

Befürworter von Hard Forks werden oft verspottet, weil sie versuchten, eine „feindliche Übernahme“ eines Netzwerks herbeizuführen und Benutzer zu „zwingen“, sich ihnen anzuschließen. Darüber hinaus wird das Risiko von Kettenspaltungen häufig genutzt, um Hard Forks als „unsicher“ einzustufen.

Ich persönlich bin der Meinung, dass diese Kritik falsch und darüber hinaus in vielen Fällen völlig rückständig ist. Dieser Standpunkt ist nicht spezifisch für Ethereum, Bitcoin oder eine andere Blockchain; Es ergibt sich aus allgemeinen Eigenschaften dieser Systeme und ist auf jedes dieser Systeme anwendbar. Darüber hinaus gelten die folgenden Argumente nur für kontroverse Änderungen, wenn ein großer Teil mindestens einer Wählerschaft (Miner/Validatoren und Benutzer) sie ablehnt; Wenn eine Änderung nicht umstritten ist, kann sie im Allgemeinen sicher durchgeführt werden, unabhängig vom Format des Forks.

Lassen Sie uns zunächst die Frage des Zwanges diskutieren. Sowohl Hard Forks als auch Soft Forks ändern das Protokoll auf eine Weise, die einigen Benutzern möglicherweise nicht gefällt. jedem Eine Protokolländerung wird dies tun, wenn die Unterstützung nicht genau 100 % beträgt. Darüber hinaus ist es fast unvermeidlich, dass zumindest einige der Andersdenkenden schätzen in jedem Szenario den Netzwerkeffekt des Festhaltens an der größeren Gruppe mehr als ihre eigenen Präferenzen hinsichtlich der Protokollregeln. Daher sind beide Fork-Typen im Netzwerkeffekt-Sinn des Wortes erzwingend.

Es gibt jedoch einen wesentlichen Unterschied zwischen Hard Forks und Soft Forks: Bei Hard Forks handelt es sich um ein Opt-In, während bei Soft Forks den Benutzern überhaupt kein „Opt-in“ möglich ist. Damit ein Benutzer einer Hard-Fork-Kette beitreten kann, muss er persönlich das Softwarepaket installieren, das die Fork-Regeln implementiert, und die Gruppe von Benutzern, die mit einer Regeländerung noch stärker nicht einverstanden sind, als sie Netzwerkeffekte schätzen, können theoretisch einfach auf der Kette bleiben alte Kette – und praktisch gesehen ein solches Ereignis ist schon passiert.

Dies gilt sowohl für streng expandierende Hard Forks als auch für bilaterale Hard Forks. Bei Soft Forks hingegen Wenn die Verzweigung erfolgreich ist, existiert die nicht verzweigte Kette nicht. Daher, Soft Forks begünstigen institutionell eindeutig Zwang gegenüber Sezession, während Hard Forks die gegenteilige Tendenz haben. Meine eigenen moralischen Ansichten veranlassen mich dazu, die Abspaltung dem Zwang vorzuziehen, auch wenn andere möglicherweise anderer Meinung sind (das am häufigsten vorgebrachte Argument ist, dass Netzwerkeffekte wirklich sehr, sehr wichtig sind und es wichtig ist, dass „Eine Münze regiert sie alle“, obwohl es auch moderatere Versionen davon gibt).

Wenn ich raten müsste, warum Soft Forks trotz dieser Argumente oft als „weniger zwingend“ als Hard Forks angepriesen werden, würde ich sagen, dass das daran liegt, dass es sich anfühlt, als ob ein Hard Fork den Benutzer „zwingt“, ein Software-Update zu installieren Mit einem Soft Fork „müssen“ Benutzer überhaupt nichts tun. Diese Intuition ist jedoch irreführend: Es kommt nicht darauf an, ob einzelne Benutzer den einfachen bürokratischen Schritt des Klickens auf die Schaltfläche „Herunterladen“ ausführen müssen oder nicht, sondern vielmehr darauf, ob der Benutzer dies tut oder nicht gezwungen, eine Änderung der Protokollregeln zu akzeptieren die sie lieber nicht akzeptieren würden. Und nach dieser Kennzahl sind, wie oben erwähnt, beide Arten von Forks letztendlich zwanghaft, und es sind Hard Forks, die sich als etwas besser erweisen, wenn es darum geht, die Freiheit der Benutzer zu wahren.

Schauen wir uns nun höchst umstrittene Forks an, insbesondere Forks, bei denen Miner-/Validator-Präferenzen und Benutzerpräferenzen im Widerspruch stehen. Hierbei gibt es drei Fälle: (i) bilaterale Hard Forks, (ii) streng expandierende Hard Forks und (iii) sogenannte „User-Activated Soft Forks“ (UASF). Eine vierte Kategorie besteht darin, dass Bergleute einen Soft Fork aktivieren ohne Zustimmung des Benutzers; Wir werden später darauf zurückkommen.

Erstens bilaterale Hard Forks. Im besten Fall ist die Situation einfach. Die beiden Münzen werden auf dem Markt gehandelt und die Händler bestimmen den relativen Wert der beiden. Aus dem ETC/ETH-Fall haben wir überwältigende Beweise dafür, dass Miner mit überwältigender Wahrscheinlichkeit ihre Hashrate einfach auf der Grundlage des Preisverhältnisses den Coins zuweisen, um ihren Gewinn zu maximieren, unabhängig von ihren eigenen ideologischen Ansichten.

Selbst wenn einige Bergleute ideologische Präferenzen für die eine oder andere Seite bekunden, ist es äußerst wahrscheinlich, dass es genügend Bergleute gibt, die bereit sind, etwaige Diskrepanzen zwischen Preisverhältnis und Hashpower-Verhältnis auszugleichen und die beiden in Einklang zu bringen. Wenn ein Miner-Kartell versucht, sich zu bilden, um nicht in einer Kette zu schürfen, besteht ein überwältigender Anreiz, abzuwandern.

Hier gibt es zwei Randfälle. Die erste besteht darin, dass aufgrund eines ineffizienten Schwierigkeitsanpassungsalgorithmus der Wert des Minings der Münze sinkt, weil der Preis sinkt, die Schwierigkeit jedoch nicht als Ausgleich sinkt, was das Mining sehr unrentabel macht und es keine Miner gibt, die bereit sind, zu einem bestimmten Zeitpunkt zu minen Verlust, die Kette weiter voranzutreiben, bis ihre Schwierigkeit wieder ins Gleichgewicht kommt. Dies war bei Ethereum nicht der Fall, kann aber durchaus sein bei Bitcoin der Fall sein. Daher kann es sein, dass die Minderheitenkette einfach nie in Gang kommt und daher zugrunde geht. Beachten Sie, dass die normative Frage von ob das eine gute Sache ist oder nicht hängt von Ihren Ansichten zu Zwang versus Sezession ab; Wie Sie sich aus dem, was ich oben geschrieben habe, vorstellen können, glaube ich persönlich, dass solche Algorithmen zur Schwierigkeitsanpassung gegen Minderheitenketten schlecht sind.

Der zweite Randfall besteht darin, dass bei einer sehr großen Disparität die große Kette die kleinere Kette zu 51 % angreifen kann. Selbst bei einem ETH/ETC-Split mit einem Verhältnis von 10:1 ist dies nicht geschehen; Es ist also sicherlich keine Selbstverständlichkeit. Es besteht jedoch immer eine Möglichkeit, wenn Bergleute in der dominanten Kette Zwang bevorzugen, anstatt eine Abspaltung zuzulassen und nach diesen Werten zu handeln.

Schauen wir uns als Nächstes die strikt expandierenden Hard Forks an. In einem SEHF gibt es die Eigenschaft, dass die nicht gespaltene Kette nach den gespaltenen Regeln gültig ist. Wenn die Gabel also einen niedrigeren Preis hat als die nicht gegabelte Kette, hat sie weniger Hashpower als die nicht gegabelte Kette, und Daher wird die nicht gegabelte Kette am Ende als die längste Kette akzeptiert sowohl nach Original-Client- als auch nach Forked-Client-Regeln – und so die gegabelte Kette“wird vernichtet".

Es wird argumentiert, dass daher eine starke inhärente Tendenz gegen den Erfolg einer solchen Abspaltung besteht, da die Möglichkeit, dass die abgespaltene Kette vernichtet wird, in den Preis eingebaut wird, was den Preis nach unten drückt, was es noch wahrscheinlicher macht, dass die abgespaltene Kette zerstört wird vernichtet ... Dieses Argument scheint mir stark zu sein, und daher ist es ein sehr guter Grund, es vorzubringen jedem umstrittene Hard Fork bilateral statt strikt expandierend.

Die Entwickler von Bitcoin Unlimited schlagen vor, dieses Problem zu beheben Manuelles Erstellen der bilateralen Hard Fork nachdem es passiert, aber eine bessere Wahl wäre es, die Bilateralität zu integrieren; Im Bitcoin-Fall kann man beispielsweise eine Regel hinzufügen, um einen ungenutzten Opcode zu verbieten, und dann eine Transaktion mit diesem Opcode in der nicht gespaltenen Kette durchführen, sodass die nicht gespaltene Kette von da an unter den gespaltenen Regeln gilt als für immer ungültig angesehen. Im Fall von Ethereum sind aufgrund verschiedener Details zur Funktionsweise der Zustandsberechnung fast alle Hard Forks fast automatisch bilateral. Andere Ketten können je nach Architektur unterschiedliche Eigenschaften haben.

Der letzte oben erwähnte Fork-Typ ist der benutzeraktivierte Soft Fork. In einer UASF aktivieren Benutzer die Soft-Fork-Regeln, ohne sich die Mühe zu machen, einen Konsens von den Minern einzuholen; Von den Bergleuten wird erwartet, dass sie sich einfach aus wirtschaftlichen Interessen anschließen. Wenn viele Nutzer nicht mit der UASF mitmachen, wird es zu einem Coin-Split kommen, und das wird zu einem Szenario führen, das mit dem der streng expandierenden Hard Fork identisch ist, außer – und das ist der wirklich clevere und hinterlistige Teil des Konzepts – Der gleiche „Vernichtungsrisiko“-Druck, der die gegabelte Kette in einer streng expandierenden harten Gabel stark benachteiligt, begünstigt stattdessen die gegabelte Kette in einem UASF stark. Auch wenn eine UASF optional ist, nutzt sie wirtschaftliche Asymmetrie, um sich auf den Erfolg auszurichten (obwohl die Tendenz nicht absolut ist; wenn eine UASF entschieden unpopulär ist, wird sie keinen Erfolg haben und einfach zu einer Kettenspaltung führen).

Allerdings sind UASFs ein gefährliches Spiel. Nehmen wir zum Beispiel an, dass die Entwickler eines Projekts einen UASF-Patch erstellen möchten, der einen nicht verwendeten Opcode, der zuvor alle Transaktionen akzeptierte, in einen Opcode umwandelt, der nur Transaktionen akzeptiert, die den Regeln einer coolen neuen Funktion entsprechen, wenn auch einer solchen politisch oder technisch umstritten und den Bergleuten unangenehm. Bergleute haben eine clevere und hinterhältige Möglichkeit, sich zu wehren: Sie können einseitig einen durch Miner aktivierten Soft Fork implementieren, der dazu führt, dass alle Transaktionen, die die durch den Soft Fork erstellte Funktion verwenden, immer fehlschlagen.

Jetzt haben wir drei Regelsätze:

1. Die ursprünglichen Regeln, bei denen Opcode X immer gültig ist.
2. Die Regeln, bei denen Opcode X nur gültig ist, wenn der Rest der Transaktion den neuen Regeln entspricht
3. Die Regeln, bei denen Opcode X immer ungültig ist.

Beachten Sie, dass (2) eine Soft-Fork in Bezug auf (1) und (3) eine Soft-Fork in Bezug auf (2) ist. Nun besteht ein starker wirtschaftlicher Druck zugunsten von (3), sodass der Soft Fork sein Ziel nicht erreicht.

Die Schlussfolgerung ist diese. Soft Forks sind ein gefährliches Spiel, und sie werden noch gefährlicher, wenn sie umstritten sind und die Bergleute beginnen, sich zu wehren. Auch die strikte Erweiterung von Hard Forks ist ein gefährliches Spiel. Durch Miner aktivierte Soft Forks wirken zwanghaft; Vom Benutzer aktivierte Soft Forks sind weniger zwingend, wenn auch aufgrund des wirtschaftlichen Drucks immer noch recht zwanghaft, und sie bergen auch ihre Gefahren. Wenn Sie wirklich eine umstrittene Änderung vornehmen möchten und entschieden haben, dass sich die hohen sozialen Kosten dafür lohnen, führen Sie einfach einen sauberen bilateralen Hard Fork durch, nehmen Sie sich etwas Zeit, um einen angemessenen Wiederholungsschutz hinzuzufügen, und lassen Sie den Markt das regeln .

Quelle: https://vitalik.eth.limo/general/2017/03/14/forks_and_markets.html

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• PlatoData.Network Vertikale generative KI. Motiviere dich selbst. Hier zugreifen.
• PlatoAiStream. Web3-Intelligenz. Wissen verstärkt. Hier zugreifen.
• PlatoESG. Kohlenstoff, CleanTech, Energie, Umwelt, Solar, Abfallwirtschaft. Hier zugreifen.
• PlatoHealth. Informationen zu Biotechnologie und klinischen Studien. Hier zugreifen.
• BlockOffsets. Modernisierung des Eigentums an Umweltkompensationen. Hier zugreifen.
• Quelle: Datenintelligenz von Platon.