Crypto Prices

Bitcoin kann vorerst keine Soft Forks aktivieren, sagt der Drivechain-Ersteller

vor 17 Stunden
5 minuten gelesen
4 ansichten

Einführung in die Herausforderungen von Bitcoin-Soft Forks

Bitcoin hat seit der Aktivierung von Taproot im Jahr 2021 keinen einzigen vorgeschlagenen Soft Fork aktivieren können. Dies führt dazu, dass Paul Sztorc, der Ersteller des Drivechain-Vorschlags und CEO von LayerTwo Labs, argumentiert, dass das Netzwerk in absehbarer Zeit keine solchen Upgrades genehmigen kann. Sztorc äußerte sich gegenüber crypto.news und wies darauf hin, dass die gescheiterte Aktivierung von BIP-110 auf ein Problem hinweist, das weit über ein umstrittenes Bitcoin-Upgrade hinausgeht.

„Alle Soft Forks seit Taproot konnten nicht aktiviert werden, und dies war keine Ausnahme“,

sagte Sztorc.

Der Zusammenbruch von BIP-110

Seine Einschätzung folgt dem Zusammenbruch von BIP-110, einem vorgeschlagenen temporären Soft Fork, der darauf abzielte, einige Formen von nicht-finanziellen Daten, die in Bitcoin-Transaktionen gespeichert sind, einzuschränken. Der Vorschlag erhielt während eines Schwierigkeitszeitraums von 2.016 Blöcken nur 51 unterstützende Blöcke, was zu einem Miner-Signal von 2,53 % führte. Die durchsetzenden Knoten von BIP-110 trennten sich später am Block 961.632 am 8. August vom dominierenden Bitcoin-Netzwerk. Der neue Zweig produzierte nur zwei Blöcke, bevor er zum Stillstand kam, während die Hauptkette weiterhin Blöcke in ihrem gewohnten Tempo verarbeitete.

Die Schwierigkeiten bei der Unterstützung von Konsensänderungen

Das Ergebnis von BIP-110 verdeutlichte, wie schwierig es für Entwickler geworden ist, Unterstützung für Änderungen der Konsensregeln von Bitcoin zu sichern, so Sztorc. 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, wie frühere Miner-Daten zeigten. Die durchsetzende Software trat dennoch in einen obligatorischen Signalisierungszeitraum am Block 961.632 ein. Knoten, die BIP-110 betrieben, wiesen dann Blöcke zurück, die keine Unterstützung signalisierten, obwohl die meisten Miner weiterhin auf der nicht durchsetzenden Bitcoin-Kette arbeiteten. Bis zum 9. August blieb der Minderheitszweig am Block 961.633 eingefroren, während die Hauptkette 111 Blöcke voraus war.

Technische Details und Vorschläge

OCEANs BIP-110-Endpunkt zeigte zu diesem Zeitpunkt etwa 257 Petahashes pro Sekunde, die dem Zweig zugewiesen waren, während der Strategie-Vorsitzende Michael Saylor schätzte, dass etwa 99,85 % der Hash-Power von Bitcoin bei der dominierenden Kette verblieben. Der Stillstand der zwei Blöcke wurde schwerwiegender, da der Zweig die Mining-Schwierigkeit von Bitcoin von 127,48 Billionen geerbt hatte. Ohne genügend Rechenleistung konnten die Miner die verbleibenden Blöcke, die für eine Anpassung der Schwierigkeit erforderlich waren, nicht schnell produzieren.

BIP-110, offiziell als Reduced Data Temporary Softfork bezeichnet, schlug sieben Konsensbeschränkungen vor, die 52.416 Blöcke lang waren, was ungefähr einem Jahr bei der normalen Blockrate von Bitcoin entspricht. Zu den Regeln gehörten eine Obergrenze von 83 Bytes für OP_RETURN-Ausgaben, ein Limit von 256 Bytes für bestimmte Datenübertragungen und Einschränkungen, die einige Taproot-Funktionen betrafen. Unterstützer, darunter der Bitcoin Knots-Wartungsleiter Luke Dashjr, argumentierten, dass die Beschränkungen die willkürliche Datenspeicherung im Zusammenhang mit Inschriften reduzieren und Bitcoin auf monetäre Transaktionen konzentrieren würden. Kritiker wie Saylor und Blockstream-Mitbegründer Adam Back äußerten Bedenken, dass der Vorschlag die Neutralität von Bitcoin untergraben könnte, indem er Transaktionsstrukturen ablehnt, die das Netzwerk derzeit akzeptiert.

Die Zukunft von Bitcoin-Soft Forks

Sztorc betonte, dass BIP-110 kein isolierter Misserfolg sei und verwies auf die fehlende Aktivierung anderer vorgeschlagener Soft Forks seit Taproot. Taproot wurde am Block 709.632 am 14. November 2021 aktiviert, nachdem Miner den Speedy Trial-Prozess genutzt hatten, um ihre Bereitschaft zu signalisieren. Das Upgrade führte Schnorr-Signaturen und neue Taproot-Ausgaberegeln ein, ohne nicht-upgradierte Knoten auf eine separate Blockchain zu zwingen. Seitdem sind Vorschläge, die darauf abzielen, Funktionen hinzuzufügen oder die Skriptregeln von Bitcoin zu ändern, ohne Aktivierung unter Diskussion geblieben.

Sztorc nannte OP_CAT als Beispiel und beschrieb es als eine kleine Codeänderung, die in der ursprünglichen Software von Bitcoin erschien und Unterstützung von Entwicklern angezogen hat.

„Nichts kann – nicht einmal OP_CAT, das nur 13 Zeilen Code umfasst und in der ursprünglichen Software war und viel Unterstützung hatte“,

sagte er, als er gefragt wurde, wie BIP 300 den Widerstand gegen Konsensänderungen überwinden könnte.
OP_CAT würde es Bitcoin-Skripten ermöglichen, zwei Datenelemente zu verbinden. Satoshi Nakamoto deaktivierte die Operation 2010 aus Sicherheitsgründen, aber ein späterer Vorschlag versuchte, sie durch einen rückwärtskompatiblen Soft Fork wiederherzustellen. Unterstützer sagen, dass der Opcode Entwicklern helfen könnte, Covenants, Tresore, Brücken und andere programmierbare Ausgabebedingungen zu erstellen. Der OP_CAT-Vorschlag hängt jedoch weiterhin von einer technischen Überprüfung und ausreichendem Einvernehmen unter Bitcoin-Entwicklern, Minern, Knotenbetreibern und Nutzern ab.

Koordinationsprobleme und Drivechains

Andere Vorschläge stehen vor demselben Koordinationsproblem. BIP-360 schlägt beispielsweise einen neuen Ausgabetyp vor, der darauf ausgelegt ist, post-quanten Signaturen durch einen Soft Fork zu unterstützen. Die Autoren präsentieren das Design als möglichen Weg für Benutzer, Gelder in quantenresistente Adressen zu bewegen, obwohl die Aktivierung die Art von Netzwerkvereinbarung erfordern würde, die Sztorc zufolge Bitcoin nicht mehr erreichen kann.

Drivechains sind so konzipiert, dass Entwickler verschiedene Regeln und Anwendungen auf opt-in Sidechains testen können, anstatt wiederholt Änderungen an der Basis-Schicht von Bitcoin vorzunehmen. Unter BIP 300 könnten Benutzer BTC zwischen Bitcoin und separaten Sidechains durch einen Zwei-Wege-Peg bewegen. Jede Sidechain könnte ihre eigenen Regeln anwenden, was Entwicklern ermöglicht, Privatsphäre-Systeme, Smart Contracts, schnellere Transaktionen oder andere Funktionen zu testen, ohne dass jeder Bitcoin-Nutzer diese übernehmen muss. Sidechains würden auch separate Marken und Software beibehalten, die Sztorc mit bestehenden Systemen wie Liquid und Lightning verglich. Benutzer könnten wählen, ob sie Gelder in eine bestimmte Kette bewegen möchten, während die Basisregeln von Bitcoin nach dem ursprünglichen Drivechain-Upgrade unverändert bleiben würden.

Risiken und Herausforderungen für die Bitcoin-Governance

Auf die Frage, ob mehrere Drivechains die Liquidität fragmentieren und Benutzer unsicher lassen könnten, welchen Implementierungen sie vertrauen sollten, 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 jedoch weiterhin mit dem gleichen unmittelbaren Hindernis konfrontiert sein, das in Sztorcs Einschätzung identifiziert wurde: BIP 300 selbst benötigt eine Konsensänderung bei Bitcoin. Ohne Aktivierung können Entwickler das vorgeschlagene Abhebungssystem nicht als Teil der Netzwerkregeln implementieren.

„Es kann nicht“, sagte Sztorc, als er gefragt wurde, wie BIP 300 den Widerstand überwinden könnte, der andere Vorschläge gestoppt hat. BIP 300 würde Bitcoin-Minern eine wichtige Rolle bei der Genehmigung von Abhebungen von Drivechains zuweisen, eine Regelung, die Bedenken hinsichtlich Diebstahl, Zensur und Miner-Kollusion aufgeworfen hat. Nach dem Vorschlag würden Abhebungsanträge ausstehen, während Miner darüber durch Bitcoin-Blöcke abstimmen. Ein Antrag, der während des erforderlichen Abstimmungszeitraums genügend Unterstützung erhält, könnte BTC aus dem Sidechain-Peg freigeben. Sztorc erklärte, dass das Sicherheitsmodell teilweise von dem wirtschaftlichen Wert abhängt, den eine beliebte Sidechain für Miner schafft.

„Wenn die Kette beliebt ist, wird sie Gebühren für Miner generieren. Wenn diese Gebühreneinnahmen groß sind, relativ zur Anzahl der im Umlauf befindlichen Münzen auf dem L2, dann wird sie sicher sein.“

Benutzer müssten daher die Beziehung zwischen den Gebühreneinnahmen der Sidechain, den Anreizen der Miner und dem Wert von BTC, der innerhalb des Pegs gehalten wird, bewerten. Kritiker argumentieren, dass Miner koordinieren könnten, um eine ungültige Abhebung zu genehmigen, während Unterstützer behaupten, dass ein Angriff auf eine profitable Sidechain zukünftige Gebühreneinnahmen zerstören und das Vertrauen in das System schädigen könnte.

Schlussfolgerung

Für US-Teilnehmer hat BIP-110 bereits gezeigt, wie amerikanische Mining-Betriebe in Bitcoin-Governance-Streitigkeiten verwickelt werden können. Der Foundry USA Pool bat Mining-Kunden, vor der obligatorischen Frist über das Signalisieren von BIP-110 abzustimmen, während Strategy, ein an der US-Börse gelistetes Unternehmen und einer der größten Unternehmensinhaber von Bitcoin, den Vorschlag öffentlich durch Saylor ablehnte. Der gescheiterte Fork stellte auch ein praktisches Risiko für Inhaber dar, da BIP-110 keinen automatischen Replay-Schutz beinhaltete. Bitcoin-Entwickler Kevin Loaec warnte, dass eine Transaktion, die auf einem Zweig gesendet wird, möglicherweise auf den anderen kopiert werden könnte, was vor dem Fork gehaltene Münzen gefährden würde, wenn Benutzer versuchten, Vermögenswerte auf der Minderheitskette zu bewegen oder zu verkaufen, ohne sie zuvor zu trennen. Die Unterstützer von BIP-110 bereiteten auch Code für eine mögliche Änderung des Proof-of-Work vor, die es dem stillgelegten Zweig ermöglichen würde, den bestehenden Mining-Algorithmus von Bitcoin aufzugeben. Der Code beinhaltete eine konfigurierbare Hard-Fork-Zeit, obwohl Entwickler Chris Guida es als Notfallmaßnahme beschrieb und kein Aktivierungsdatum festgelegt hatte.

Beliebt