Zusammenfassung
Dies ist unser fünfter Blick auf die Kontroversen rund um das OP_Return-Relaislimit von Bitcoin. Diesmal untersuchen wir einige der Spieltheorien, die im Gespräch eine Rolle spielen, und versuchen zu erklären, warum es in der Diskussion zuletzt Spannungen gab. Ein entspannteres OP_Return-Limit könnte für individuelle Node-Betreiber in allen Szenarien von Vorteil oder neutral sein, insbesondere wenn Compact Blocks und Caching von Transaktionsvalidierungsprüfungen effektiver arbeiten. Kritiker der Filterpolitik argumentieren jedoch, dass ein strengeres OP_Return-Limit dem gesamten Ökosystem zugutekommen könnte. Dies führt zu einem Konflikt zwischen der Abwehr von „Spam“ und der individuellen Nutzersouveränität, da Filterbefürworter andere Node-Betreiber dazu auffordern, möglicherweise die Leistung ihrer eigenen Nodes zu beeinträchtigen, um scheinbar dem gesamten Netzwerk zu helfen.
Überblick
BitMEX Research beschäftigt sich erneut mit dem Thema der OP_Return-Kontroverse.
- Die OP_Return-Kriege von 2014 – Dapps gegen Bitcoin-Transaktionen
- Abbau der Sicherheitsvorkehrungen von Bitcoin
- Unstoppable JPGs in privaten Schlüsseln
- Ordinals – Auswirkungen auf Node-Betreiber
In diesem Artikel betrachten wir verschiedene Perspektiven und erläutern, warum die Meinungen zu dieser Situation auseinandergehen. Ein zentraler Streitpunkt scheint die Frage zu sein, ob man einen Node ausschließlich zu eigenen Zwecken oder altruistisch betreibt, um das Netzwerk zu unterstützen. Man kann dieses Problem entweder als „Einer für Alle“ oder „Einer für mich“ betrachten.
Mehr als nur Compact Blocks
Ein zentraler Grund, warum einige Menschen das OP_Return-Relaislimit erhöhen möchten, besteht darin, Compact Blocks effektiv zu halten. Diese Technologie wurde von Bitcoin-Entwickler Matt Corrallo im April 2016 vorgeschlagen. Compact Blocks erfordert, dass der lokale Mempool in der Lage ist, vorhersagen zu können, was Miner im nächsten Block abbauen werden. Es bedeutet allerdings nicht, dass ein „einheitlicher Mempool“ über das gesamte Netzwerk erforderlich ist; individuelle Nodes können unterschiedliche Mempools haben. Wenn Sie Compact Blocks jedoch für sich nutzen möchten, benötigen Sie ein akzeptables Modell dafür, was Miner abbauen werden, und dies erfordert möglicherweise ein erhöhtes OP_Return-Limit.
Compact Blocks verbessert die Blockweitergabe im Netzwerk, da Nodes die Transaktionen bereits in ihrem Mempool haben und durch die Berechnung der voraussichtlichen Transaktionen, die im Block enthalten sind, die Notwendigkeit zur doppelten Übertragung vermeiden können. Dies hat entscheidende Vorteile wie geringere Bandbreitenkosten und macht es für Internetdienstanbieter schwieriger, die Bandbreitennutzung von Bitcoin zu erkennen. Ein weiterer wichtiger Vorteil ist die Wettbewerbsfähigkeit im Minen-Sektor; schnelleres Blockpropagation kann kleinere Miner im Vergleich zu größeren begünstigen. Daher ist Compact Blocks entscheidend für den Kampf gegen die Zentralisierung im Mining.
Einer für Alle und Alle für mich
Bitcoin Core Version 30, die bald veröffentlicht wird, erhöht das OP_Return-Relaislimit von 83 Bytes auf 100.000 Bytes, also um über 1.200-fach. Wie kann solch eine massive Erhöhung gerechtfertigt werden? Wäre eine moderate Erhöhung auf 160 Bytes nicht angemessener? Tatsächlich zeigt eine logische Überlegung, dass rein aus der Perspektive des individuellen Node-Betreibers, der Core v30 verwendet, eine Erhöhung auf 100.000 Bytes die bessere Option darstellt.
So lässt sich ein 100KB OP_Return-Relaislimit rechtfertigen
| Szenario | Auswirkungen |
|---|---|
| Minimale Annahme großer OP_Returns | Die Leistung der Compact Blocks wird nicht signifikant beeinträchtigt. Da die Nutzung von OP_Return minimal ist, gibt es keine größeren Nachteile. Die Auswirkungen sind neutral. |
| Hohe Nutzung großer OP_Returns | Die Leistung von Compact Blocks und anderen Tests wird erheblich beeinträchtigt, es sei denn, man akzeptiert große OP_Return-Transaktionen in seinen Mempool. Die Auswirkungen sind positiv. |
Fall geschlossen! Bitcoin Core ist im Recht! Da es bei größeren OP_Returns keine DoS-Probleme gibt, ist das höhere OP_Return-Limit in allen möglichen Szenarien für Ihre Node strikt besser oder gleichwertig, unabhängig davon, wie hoch die Annahme von großen OP_Returns ist. Es mag nicht viel nützen, aber es ist definitiv ein Vorteil.
Alle für einen & Einer für alle
Die Befürworter von Filtern scheinen die Angelegenheit nicht nur aus Sicht der individuellen Benutzer zu betrachten. Sie nehmen auch die breiteren spieltheoretischen Perspektiven in den Blick. In der Regel betreiben die meisten Menschen einen Node für ihren eigenen Vorteil, nicht um das Netzwerk in eine bestimmte Richtung zu lenken.
Das Standardsetting in Bitcoin Core dient nicht nur einer Einzelperson. Viele Nutzer könnten den Standardwert übernehmen, was Auswirkungen auf die Netzwerkbedingungen haben könnte. Es gibt die philosophische Idee, dass Bitcoin-Nutzer selbst souverän sind und die Core-Entwickler Software entwickeln sollten, die jedem einzelnen Nutzer zugutekommt. Mechanismen sollten aus der Basis heraus gestaltet werden, sodass das Bitcoin-Netzwerk gut funktioniert und jeder Benutzer ausschließlich in seinem eigenen Interesse handelt. Vielleicht ist das jedoch etwas utopisch und wir sind noch nicht ganz am Ziel.
Große OP_Returns werden bereits zuverlässig übermittelt
Befürworter eines großen OP_Return-Relaislimits könnten argumentieren, dass Miner große OP_Return-Outputs ohnehin zuverlässig erhalten und verarbeiten, ganz egal ob sie sie über das offene Relay-Netzwerk oder auf andere Weise erhalten. Dies scheint eine relativ neue Entwicklung zu sein, da große OP_Returns vor 2025 direkt von Minern eingereicht werden mussten. Dieses Umdenken in der Netzwerkdynamik fand statt, bevor Bitcoin Core das OP_Return-Relaislimit erhöhte.
Technische Lösung
Ein Teil des Dilemmas, das die Befürworter von Filtern ansprechen, kann weitgehend mit Technologie gemildert werden. Man könnte eine neue Node-Option entwickeln, bei der der Node nichts relayed (oder Filter hat), aber dennoch einen Mempool mit lockeren Policies hat und alle Vorblock-Validierungsprüfungen effizient durchführt.
Es ist klar, dass die Befürworter von Filtern im Idealfall die technische Grundlage für ihre Argumente stärken und gleichzeitig sicherstellen müssen, dass die Leistung ihrer Nodes nicht beeinträchtigt wird.
Fazit
Das Hauptproblem für die Befürworter von Filtern könnte sein, dass sie möglicherweise den Node, den sie betreiben möchten, nicht effizient nutzen können. Sie bitten andere Node-Betreiber, die Filter zu verwenden, die zwar dem Netzwerk nutzen könnten, aber den eigenen Interessen derjenigen, die die Filter betreiben, möglicherweise entgegenstehen. Dies führt in der Community zu Spannungen, während sich die Debatte entfaltet.
Die Gegner der Relay-Filter können einfach die Filter nicht verwenden und zufrieden bleiben. Sie müssen sich keine Gedanken über die Relay-Politik anderer Node-Betreiber machen, da Compact Blocks auch bei einer hohen Anzahl von gefilterten Nodes ordnungsgemäß funktionieren sollten.
