Was sind die Nachteile bei der Aktivierung potenziell suboptimaler oder ungenutzter Opcodes in einem zukünftigen Soft Fork?

Jedes Stück zusätzlicher Konsenslogik hat Implementierungs- und laufende Wartungskosten, die dauerhaft sind und niemals entfernt werden können, ohne möglicherweise das Vermögen einiger Benutzer zu beschlagnahmen.

Als Satoshi diese Opcodes deaktivierte, ging er das Risiko ein, dass dies die Gelder einiger Benutzer zerstören würde, aber Bitcoin war jung, ihre Verwendung war anscheinend nicht vorhanden, und diese Opcodes konnten alle verwendet werden, um eine effektiv unbegrenzte Speichernutzung oder Speicherbeschädigung und Absturzknoten zu verursachen . Ich weiß nicht, ob Satoshi unbedingt klar war, dass er möglicherweise die Gelder der Menschen zerstört, aber angesichts der Bedrohung zu diesem Zeitpunkt in Bitcoins Leben (während Bitcoins sehr wenig Wert hatten), war es wahrscheinlich die richtige Entscheidung. Es wäre nicht mehr.

Jede neu eingeführte Funktionalität ist nicht nur ein Risiko für den Benutzer, sondern ein potenzielles Risiko für das gesamte Netzwerk – da Fehler darin zu Konsensinkonsistenzen, Knotenabstürzen, Verlängerungen der Verarbeitungszeiten im schlimmsten Fall oder sogar Schwachstellen bei der Remotecodeausführung führen können . Der Schutz davor erfordert Überprüfungs- und Testressourcen, die andernfalls für andere Funktionen aufgewendet werden könnten. Die Kosten sind auch keine einmaligen Kosten, da der Code gepflegt werden muss und sich später Fehler einschleichen könnten.

Zusätzliche Komplexität erschwert auch alternativen Node-Implementierungen das Leben, da sie auch jede Konsensregel implementieren müssen, und dies der Freiheit des Benutzers widerspricht, seinen eigenen Node zu ändern (oder seinen eigenen zu implementieren). Aufgrund dieser Kosten ist "vielleicht findet es jemand nützlich" kein wirklich überzeugendes Argument.

Die Kosten bedeuten auch, dass es nach der Implementierung einiger Funktionen einen Grund gibt, etwas anderes nicht zu implementieren, das damit teilweise redundant ist. Wenn also Fehler in einer Funktion einige Anwendungen, aber nicht alle töten, wird es schwieriger, eine verbesserte Alternative zu finden, die alle abdeckt die eingesetzten Nutzungen.

Was die Vorteile des Angebots eines vereinfachten und größtenteils orthogonalen Befehlssatzes betrifft, denke ich nicht, dass dies selbst viel ausmacht. Während eine Vielzahl von Operationen ein Ärgernis für jeden ist, der ein Analysetool erstellt, können die Benutzer im Allgemeinen Skripts nach Belieben unterteilen. Selbst wenn es eine Belastung darstellen würde, dass Benutzer, die gemeinsam eine Richtlinie erstellen müssen, sich auf eine gemeinsame Teilmenge einigen müssen, mit der ihre Analysetools zufrieden sind, denke ich, dass diese Kosten leicht durch die zusätzliche Funktionalität ausgeglichen werden könnten.

Wenn OP_BAR ein Fußgewehr ist und mit OP_BAZ, das weniger als eins ist, redundant ist, dann setz einfach OP_BAR auf die schwarze Liste und verwende nur OP_BAZ. Aber wenn OP_BAR zuerst implementiert wird, kann es schwierig sein zu beweisen, dass diese geringfügige Verbesserung von OP_BAZ ihre zusätzlichen Kosten wert ist. Auf diese Weise kann die Implementierung eines schwachen Features einer stärkeren Alternative im Wege stehen, die von vornherein hätte erfolgen können, wenn ein angemessener Aufwand dafür aufgewendet worden wäre. Die gleiche Aussage gilt, wenn Sie „Fußwaffe“ durch „ineffizient“ ersetzen.

Manchmal können schlecht gestaltete Funktionen negative Systemanreizeffekte haben. Beispielsweise schuf die ursprüngliche Konstruktion der zeitbasierten nlocktime einen Anreiz für Miner, über ihre aktuelle Zeit zu lügen und sie vorzuschieben, um spätere nlocktime-Transaktionen und ihre Gebühren einziehen zu können. Wenn zeitbasierte nlocktime-Transaktionen sehr üblich geworden wären, hätte dies schließlich zu einem Wettlauf nach unten führen können, bei dem alle Miner ihre Zeiten so weit wie möglich nach vorne setzten, um ihre Gebühren zu maximieren, und möglicherweise die Stabilität des Netzwerks dadurch sogar für gefährden Benutzer, die keine Sperrzeit verwenden. Glücklicherweise war nlocktime auf kompatible Weise reparierbar. In ähnlicher Weise könnten schlecht konstruierte Funktionen die Anonymitätsgruppe unnötig fragmentieren oder Benutzer dazu anregen, die Privatsphäre für alle zu reduzieren.

Es ist leicht, sich erfundene Funktionen vorzustellen, die negative systemische Effekte erzeugen würden: ZB OP_BOBSIG, wo ein Txout, der es verwendet, ohne Einschränkungen ausgegeben werden kann, solange Bob den gesamten Block signiert hat – eine äußerst effiziente Wahl für diejenigen, die Bob vertrauen. Und es scheint harmlos für Leute, die es nicht benutzen, bis Sie bedenken, dass es Bob-Vertrauensleuten einen unfairen Vorteil verschafft, Bobs Mining einen unfairen Vorteil verschafft und Bob letztendlich die Kontrolle über das gesamte System übertragen könnte. Systematische Effekte sind jedoch ein weniger häufiges Problem, da sie eine Funktion erfordern, die attraktiv genug ist, damit Menschen sie verwenden, aber für das System als Ganzes unattraktiv ist. Es ist immer noch ein Faktor, der berücksichtigt werden muss.

Anders als in Eckfällen mit Systemeffekten würden die meisten Bitcoin-Experten zustimmen, dass der Eigentümer eines Fonds völlige Freiheit haben sollte, wie er ihn verwaltet – auch wenn das bedeutet, dass er manchmal einen ineffizienten oder weniger persönlichen sicheren Weg wählen könnte. Best Practices können außerhalb des Systems selbst angesprochen werden. Da die Konsensregeln jedoch von allen Knoten implementiert werden müssen und nicht entfernt werden können, entstehen Kosten. Diese Kosten schaffen Situationen, in denen sich die Wahl zwischen einem schlecht und einem gut konstruierten Betrieb – oder einfach nur zwischen zwei völlig unterschiedlichen Betrieben – bis zu einem gewissen Grad gegenseitig ausschließt. Aus diesem Grund muss ein neues Feature nicht nur sicher für das Netzwerk sein, es sollte auch eindeutig nützlich sein,

Es gibt eine andere Überlegung als die Sicherstellung einer begrenzten Ressourcennutzung in allen Randfällen für einen Opcode, die von anderen im IRC kurz diskutiert wurde und die ich hier zusammenfassen werde.

Es gibt verschiedene philosophische Ansätze, um zukünftige Opcodes für Bitcoin zu entwerfen. Eine Dimension ist, ob Operationscodes unter Verwendung eines RIS-Ansatzes (reduzierter Befehlssatz) oder eines CIS-Ansatzes (komplexer Befehlssatz) entworfen werden sollten. Ein Ansatz mit reduziertem Befehlssatz (RIS) führt zu Opcodes mit minimaler Funktionalität, aber sie können wie Bausteine ​​mit anderen Opcodes kombiniert werden, um eine größere Funktionalität zu schaffen (dh UNIX-ähnlich). Ein komplexer Befehlssatz (CIS) führt zu Opcodes, die eine vollständige und bestimmte Funktionalität bieten.

Eine weitere Dimension betrifft die Sicherheit und ob Opcodes so konzipiert sein sollten, dass sie Footguns verhindern und Programmierer daran hindern, Skripte zu erstellen, die auf eine Weise missbraucht werden können, die möglicherweise die Sicherheit der Benutzer beeinträchtigen könnte. Die Alternative besteht darin, sich nicht so viele Gedanken über die Benutzersicherheit zu machen, maximale Flexibilität zuzulassen und Sicherheitsbedenken in höhere abstrakte Schichten (z. B. Miniskript, Richtlinie, Deskriptoren usw.) zu verschieben.

Diese beiden Dimensionen sind nicht vollständig orthogonal. Wenn diese Dimensionen nicht berücksichtigt werden, erhalten Sie am Ende einen Haufen neuer Opcodes (und Sighash-Flags), die aktiviert sind, und es ist nicht klar, welche Opcodes wofür verwendet werden sollten und welche Anleitung (falls vorhanden) zu ihrer Verwendung angeboten werden sollte sicher. Als Satoshi Opcodes aktivierte und deaktivierte, hatte er/sie nicht das Verständnis, das wir im Jahr 2021 haben, und hatte es nicht mit einem System zu tun, das Milliarden von Dollar mit höheren Schichten speichert und überträgt, abhängig von Änderungen an der Basisschicht.