Bitcoin hat es versäumt, jeden vorgeschlagenen Soft Fork zu aktivieren, seit Taproot 2021 live ging, was den Drivechain-Erfinder Paul Sztorc zu der Argumentation veranlasste, dass das Netzwerk in absehbarer Zukunft keine derartige Aktualisierung genehmigen kann.
Zusammenfassung
- BIP-110 erhielt 2,53 % Miner-Unterstützung, bevor sein durchsetzender Zweig nach zwei Blöcken ins Stocken geriet.
- Paul Sztorc sagte, jeder vorgeschlagene Soft Fork seit Taproot habe es versäumt, aktiviert zu werden.
- Drivechains würden experimentelle Regeln auf separate Chains legen, aber zuerst eine Änderung des Bitcoin-Konsenses erfordern.
- Sztorc sagte, dass Sidechain-Gebühreneinnahmen den Anreiz der Miner beeinflussen würden, Drivechain-Auszahlungen zu schützen.
Paul Sztorc, CEO von LayerTwo Labs und Schöpfer des Drivechain-Vorschlags, sagte gegenüber crypto.news, dass die gescheiterte Aktivierung von BIP-110 auf ein Problem hinweist, das weit über eine einzelne umstrittene Bitcoin-Aktualisierung hinausgeht.
„Alle Soft Forks seit Taproot haben es versäumt, aktiviert zu werden, und dies war keine Ausnahme“, sagte Sztorc.
Seine Einschätzung folgte dem Zusammenbruch von BIP-110, einem vorgeschlagenen temporären Soft Fork, der darauf abzielte, einige Formen nicht-finanzieller Daten zu beschränken, die in Bitcoin-Transaktionen gespeichert werden. Der Vorschlag erhielt nur 51 unterstützende Blöcke während einer 2.016-Block-Schwierigkeitsperiode, was das Miner-Signalisieren bei 2,53 % beließ.
BIP-110 durchsetzende Nodes spalteten sich später am 8. August bei Block 961.632 vom dominanten Bitcoin-Netzwerk ab. Der neue Zweig produzierte nur zwei Blöcke, bevor er ins Stocken geriet, während die Hauptkette weiterhin Blöcke in ihrem üblichen Tempo verarbeitete.
BIP-110-Ausfall deutet auf einen eingefrorenen Bitcoin-Aktualisierungsprozess hin
Das BIP-110-Ergebnis zeigte laut Sztorc, wie schwierig es geworden ist, Unterstützung für Änderungen an Bitcoins Konsensregeln zu sichern.
Der freiwillige Aktivierungsprozess des Vorschlags erforderte, dass 55 % der Blöcke Unterstützung signalisieren. Bis zum 2. August war das Ziel mathematisch unerreichbar geworden, da nur 28 der ersten 1.108 Blöcke signalisiert hatten, so frühere Miner-Daten.
Seine durchsetzende Software trat dennoch bei Block 961.632 in eine obligatorische Signalisierungsperiode ein. Nodes, die BIP-110 ausführten, lehnten dann Blöcke ab, die keine Unterstützung signalisierten, obwohl die meisten Miner weiterhin auf der nicht durchsetzenden Bitcoin-Kette aufbauten.
Bis zum 9. August blieb der Minderheitszweig bei Block 961.633 eingefroren, während die Hauptkette 111 Blöcke vorrückte. OCEANs BIP-110-Endpunkt zeigte zu diesem Zeitpunkt etwa 257 Petahashes pro Sekunde, die dem Zweig zugewiesen waren, während Strategy Executive Chairman Michael Saylor schätzte, dass ungefähr 99,85 % der Hashleistung von Bitcoin bei der dominanten Kette geblieben waren.
Der Stillstand der Zwei-Block-Kette wurde schwerwiegender, weil der Zweig Bitcoins Mining-Schwierigkeit von 127,48 Billionen erbte. Ohne genügend Rechenleistung konnten seine Miner die verbleibenden Blöcke, die erforderlich waren, um eine Schwierigkeitsanpassung zu erreichen, nicht schnell produzieren.
BIP-110, formell als Reduced Data Temporary Softfork bezeichnet, schlug sieben Konsensbeschränkungen vor, die 52.416 Blöcke dauern sollten, oder ungefähr ein Jahr bei Bitcoins normaler Blockrate. Die Regeln umfassten eine Obergrenze von 83 Bytes für OP_RETURN-Ausgaben, ein Limit von 256 Bytes für bestimmte Daten-Pushes und Beschränkungen, die einige Taproot-Funktionen betrafen.
Unterstützer, darunter der Bitcoin-Knots-Maintainer Luke Dashjr, argumentierten, dass die Beschränkungen willkürliche Datenspeicherung, die mit Inscriptions verbunden ist, reduzieren und Bitcoin auf monetäre Transaktionen fokussiert halten würden. Kritiker wie Saylor und der Blockstream-Mitbegründer Adam Back sagten, der Vorschlag könnte Bitcoins Neutralität untergraben, indem er Transaktionsstrukturen ablehnt, die das Netzwerk derzeit akzeptiert.
Selbst OP_CAT steht vor derselben Bitcoin-Konsensbarriere
Sztorc sagte, BIP-110 sei kein isolierter Fehlschlag gewesen, und verwies auf die fehlende Aktivierung anderer vorgeschlagener Soft Forks seit Taproot.
Taproot wurde am 14. November 2021 bei Block 709.632 aktiviert, nachdem Miner den Speedy-Trial-Prozess genutzt hatten, um Bereitschaft zu signalisieren. Die Aktualisierung führte Schnorr-Signaturen und neue Taproot-Ausgaberegeln ein, ohne nicht aktualisierte Nodes auf eine separate Blockchain zu zwingen.
Seitdem sind Vorschläge, die Funktionen hinzufügen oder Bitcoins Skriptregeln ändern sollen, ohne Aktivierung in Diskussion geblieben. Sztorc nannte OP_CAT als Beispiel und beschrieb es als eine kleine Codeänderung, die in Bitcoins ursprünglicher Software erschien und Unterstützung von Entwicklern angezogen hat.
„Nichts kann das – nicht einmal OP_CAT, das nur 13 Zeilen Code umfasst, in der ursprünglichen Software enthalten war und viel Unterstützung hatte“, sagte er auf die Frage, wie BIP 300 den Widerstand gegen Konsensänderungen überwinden könnte.
„Bitcoin kann in absehbarer Zukunft keine Soft Forks aktivieren.“
OP_CAT würde es Bitcoin-Skripten ermöglichen, zwei Datenelemente zu verbinden. Satoshi Nakamoto deaktivierte die Operation im Jahr 2010 aus Sicherheitsgründen, doch ein späterer Vorschlag zielte darauf ab, sie durch einen abwärtskompatiblen Soft Fork wiederherzustellen.
Befürworter sagen, der Opcode könnte Entwicklern helfen, Covenants, Vaults, Bridges und andere programmierbare Ausgabebedingungen zu erstellen. Allerdings hängt der OP_CAT-Vorschlag weiterhin von technischer Prüfung und ausreichender Zustimmung unter Bitcoin-Entwicklern, Minern, Node-Betreibern und Nutzern ab.
Andere Vorschläge stehen vor demselben Koordinationsproblem. BIP-360 beispielsweise schlägt einen neuen Output-Typ vor, der darauf ausgelegt ist, Post-Quanten-Signaturen durch einen Soft Fork zu unterstützen. Seine Autoren präsentieren das Design als einen möglichen Weg für Nutzer, Gelder in quantenresistente Adressen zu verschieben, obwohl die Aktivierung die Art von Netzwerkvereinbarung erfordern würde, die laut Sztorc Bitcoin nicht mehr erreichen kann.
Drivechains würden Experimente von Bitcoins Basisschicht wegbewegen
Drivechains sind darauf ausgelegt, Entwicklern zu ermöglichen, verschiedene Regeln und Anwendungen auf Opt-in-Sidechains zu testen, anstatt wiederholte Änderungen an Bitcoins Basisschicht anzustreben.
Unter BIP 300 könnten Nutzer BTC zwischen Bitcoin und separaten Sidechains über einen Zwei-Wege-Peg bewegen. Jede Sidechain könnte ihre eigenen Regeln anwenden, wodurch Entwickler Privatsphäre-Systeme, Smart Contracts, schnellere Transaktionen oder andere Funktionen testen könnten, ohne dass jeder Bitcoin-Nutzer sie übernehmen müsste.
Sidechains würden auch separate Marken und Software pflegen, was Sztorc mit bestehenden Systemen wie Liquid und Lightning verglich. Nutzer könnten wählen, ob sie Gelder in eine bestimmte Chain verschieben, während Bitcoins Basisregeln nach dem anfänglichen Drivechain-Upgrade unverändert blieben.
Auf die Frage, ob mehrere Drivechains die Liquidität fragmentieren und Nutzer unsicher darüber lassen könnten, welchen Implementierungen sie vertrauen sollen, verglich Sztorc das Modell mit Entwicklern, die separate Altcoins starten.
„Jede Drivechain wird ihre eigene Marke haben, genau wie Liquid, Lightning usw.“, sagte er.
Drivechains würden weiterhin vor demselben unmittelbaren Hindernis stehen, das in Sztorcs Einschätzung identifiziert wurde: BIP 300 selbst benötigt eine Konsensänderung auf Bitcoin. Ohne Aktivierung können Entwickler ihr vorgeschlagenes Auszahlungssystem nicht als Teil der Netzwerkregeln einsetzen.
„Es kann nicht“, sagte Sztorc auf die Frage, wie BIP 300 den Widerstand überwinden könnte, der andere Vorschläge gestoppt hat.
Miner-Kontrolle bleibt der zentrale Sicherheitsstreitpunkt von Drivechain
BIP 300 würde Bitcoin-Minern eine Hauptrolle bei der Genehmigung von Auszahlungen aus Drivechains zuweisen, eine Regelung, die Bedenken hinsichtlich Diebstahl, Zensur und Miner-Kollusion hervorgerufen hat.
Unter dem Vorschlag würden Auszahlungsanfragen ausstehend bleiben, während Miner über sie durch Bitcoin-Blöcke abstimmen. Eine Anfrage, die über den erforderlichen Abstimmungszeitraum genügend Unterstützung erhält, könnte BTC aus dem Sidechain-Peg freigeben.
Sztorc sagte, das Sicherheitsmodell hänge teilweise vom wirtschaftlichen Wert ab, den eine populäre Sidechain für Miner schafft.
„Wenn die Chain populär ist, wird sie Gebühren für Miner generieren. Wenn diese Gebühreneinnahmen im Verhältnis zur Anzahl der im Umlauf befindlichen Coins auf der L2 groß sind, dann wird sie sicher sein.“
Nutzer müssten daher die Beziehung zwischen Sidechain-Gebühreneinnahmen, Miner-Anreizen und dem Wert der im Peg gehaltenen BTC bewerten. Kritiker argumentieren, dass Miner sich koordinieren könnten, um eine ungültige Auszahlung zu genehmigen, während Befürworter behaupten, dass ein Angriff auf eine profitable Sidechain zukünftige Gebühreneinnahmen zerstören und das Vertrauen in das System beschädigen könnte.
Für US-Teilnehmer hat BIP-110 bereits gezeigt, wie amerikanische Mining-Operationen in Bitcoin-Governance-Streitigkeiten involviert werden können. Foundry USA Pool bat Mining-Kunden, vor dem Pflichtzeitraum über BIP-110-Signalisierung abzustimmen, während Strategy, ein an der US-Börse notiertes Unternehmen und einer der größten Unternehmens-Bitcoin-Halter, den Vorschlag durch Saylor öffentlich ablehnte.
Der gescheiterte Fork stellte für Halter auch ein praktisches Risiko dar, da BIP-110 keinen automatischen Replay-Schutz enthielt. Der Bitcoin-Entwickler Kevin Loaec warnte, dass eine auf einem Zweig gesendete Transaktion möglicherweise auf den anderen kopiert werden könnte, wodurch Coins von vor dem Fork gefährdet würden, wenn Nutzer versuchten, Vermögenswerte auf der Minderheitskette zu bewegen oder zu verkaufen, ohne sie zuvor zu trennen.
Die Unterstützer von BIP-110 bereiteten außerdem Code für eine mögliche Proof-of-Work-Änderung vor, die es dem ins Stocken geratenen Zweig ermöglichen würde, Bitcoins bestehenden Mining-Algorithmus aufzugeben. Der Code enthielt eine konfigurierbare Hard-Fork-Zeit, obwohl der Entwickler Chris Guida ihn als Notfallmaßnahme bezeichnete und kein Aktivierungsdatum festgelegt hatte.






