Zum Inhalt springen
Financial Context Wiki

Zensurwiderstand

Zensurresistenz ist ein wichtiges Konzept in den Grundkonzepten und institutionellen Grenzen der Kryptowährung. In diesem Artikel werden Definition, Funktionsprinzipien, Kernformeln, tatsächliche Fälle, Risikogrenzen und häufige Missverständnisse erläutert, um Benutzern zu helfen, den On-Chain-Mechanismus zu verstehen, anstatt sich nur die Begriffe zu merken.

Aktualisiert

Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

Direkte Antwort

Zensurresistenz ist die Fähigkeit eines Netzwerks, eine gültige Transaktion erreichbar und für eine eventuelle Aufnahme in Frage zu stellen, selbst wenn bestimmte Gateways, Peers, Builder oder Blockproduzenten dies ablehnen. Dabei handelt es sich um ein Maß an Widerstandsfähigkeit, nicht um ein Versprechen, dass jede Transaktion in den nächsten Block gelangt oder dass jeder Zugangsanbieter jeden Benutzer bedienen muss.

Der Anspruch muss die Ebene, den Akteur und das Zeitfenster benennen. Eine Basiskette kann einer anhaltenden Transaktionszensur widerstehen, während ein Wallet, ein Frontend, ein RPC-Endpunkt, eine Börse oder ein Rollup-Sequenzer den Zugriff sofort blockiert. Eine Transaktion kann sich auch aus Gründen verzögern, die nicht der Zensur unterliegen, beispielsweise aufgrund einer ungültigen Signatur, einer falschen Nonce, eines unzureichenden Guthabens, einer Gebühr, die unter der lokalen Relay-Richtlinie liegt, oder der Konkurrenz um begrenzten Blockplatz.

Wie es funktioniert

Verfolgen Sie eine unterzeichnete Transaktion durch verschiedene Phasen:

  1. Erstellung und Übermittlung. Das Wallet erstellt und signiert eine Transaktion und sendet sie dann über einen RPC-Anbieter, eine private Route oder das Peer-to-Peer-Netzwerk. Ein Gateway kann es ablehnen, ohne das Basisprotokoll zu ändern.
  2. Zulassung und Weitergabe. Knoten überprüfen die Konsensgültigkeit und ihre eigene Mempool- oder Relay-Richtlinie. Eine Transaktion kann konsensgültig sein, aber nicht von einem bestimmten Knoten weitergeleitet werden. Mehrere unabhängige Peers und Übermittlungspfade reduzieren die Abhängigkeit von einem Gatekeeper.
  3. Blockkonstruktion und -vorschlag. Ein Miner, Validator, Sequencer oder externer Builder wählt Transaktionen und deren Reihenfolge. Rotierende Produzenten machen die Ablehnung eines Akteurs nur dann vorübergehend, wenn ein erheblicher Teil der späteren Produzenten die Transaktion sehen und einbeziehen kann.
  4. Validierung und Fork-Auswahl. Andere Knoten lehnen ungültige Blöcke ab und entscheiden, welcher gültige Zweig kanonisch ist. Die unabhängige Validierung verhindert, dass ein Produzent eine ungültige Transaktion gültig macht, zwingt diesen Produzenten jedoch normalerweise nicht dazu, eine bestimmte gültige Transaktion einzuschließen.
  5. Bestätigung oder Endgültigkeit. Einbeziehung ist nicht dasselbe wie eine dauerhafte Regelung. Durch Umstrukturierungen kann eine kürzlich erfolgte Aufnahme entfernt werden; die entsprechende Bestätigungs- oder Finalitätsregel ist kettenspezifisch.

Messen Sie Ergebnisse, anstatt eine binäre Bezeichnung zu vergeben. Für eine Transaktion, die erstmals allgemein unter t_seen verfügbar und unter t_included enthalten ist:

inclusion delay = t_included - t_seen

Vergleichen Sie diese Verzögerung mit ähnlich teuren und ähnlich komplexen Transaktionen im selben Überlastungsfenster. Eine weitere nützliche Maßnahme ist:

eligible inclusion rate = included eligible transactions / observed eligible transactions

„Berechtigt“ muss Gültigkeit, Nonce, Restbetrag, Gebühr, Gas oder Gewicht, Zeitablauf und Kapazitätsregeln angeben. Andernfalls kann die übliche Gebührenauswahl oder -überlastung mit selektiver Zensur verwechselt werden.

Der Widerstand hängt von der Vielfalt in den Fehlerdomänen ab: Peers, RPCs, autonome Betreiber, Pools, Clients, Builder, Relays, Sequencer, Hosting-Anbieter und Gerichtsbarkeiten. Rohe Knotenzahlen können irreführend sein, da sich viele Knoten oder Validierungsschlüssel möglicherweise einen Controller teilen. Zwangseinschlusspfade oder Einschlusslisten können Garantien stärken, ihr Bereitstellungsstatus und ihre Bedingungen sind jedoch von Bedeutung. EIP-7805 beispielsweise ist ein Vorschlag und keine derzeit eingesetzte Ethereum-Garantie.

Beispiel

Angenommen, eine gültige Transaktion erreicht das öffentliche Netzwerk auf Blockhöhe 840,000. Es bietet eine wettbewerbsfähige Gebühr, passt in jeden folgenden Block und bleibt gültig. Drei Produzenten lassen es weg; der vierte umfasst es in der Höhe 840,004.

  • Die beobachtete Verzögerung beträgt 4 blocks vom angegebenen Startpunkt.
  • Drei Auslassungen allein beweisen nicht die Koordination; Ordnung, Verbreitung und Produzentenpolitik bedürfen einer Untersuchung.
  • Die Aufnahme durch einen unabhängigen vierten Produzenten zeigt, dass den ersten Produzenten kein vollständiges Vetorecht eingeräumt wurde.
  • Wenn Produzenten, die 90% von Chancen kontrollieren, denselben Filter anwenden, ergibt ein vereinfachtes unabhängiges Slot-Modell die Inklusionswahrscheinlichkeit 1 - 0.90 = 10% pro Slot und die erwartete Wartezeit 1 / 0.10 = 10 slots. Korrelierte Kontroll- und echte Auswahlregeln können dieses Modell ungültig machen.

Um einen Verdacht auf Zensur zu dokumentieren, bewahren Sie die signierte Transaktion oder Kennung, erstmals gesehene Beobachtungen von unabhängigen Knoten, Gebühren- und Gültigkeitsprüfungen, Mempool-Richtlinien, Blockinhalte, Herstellerzuordnung und vergleichbare Transaktionen auf. Ein RPC-Fehler oder ein fehlender Explorer-Eintrag reichen nicht aus.

Risiken

  • False Positives: Ungültigkeit, veraltete Nonce, unzureichende Mittel, Gebührenpolitik, Kapazität oder schlechte Verbreitung können wie Zensur aussehen.
  • Konzentrierte Ordnung: Ein dominanter Pool, Builder, Relay oder Sequencer kann selektive Filterung in lange Verzögerungen verwandeln.
  • Zensur auf Zugriffsebene: Domains, App Stores, Frontends, Wallets und RPC-Anbieter können den praktischen Zugriff blockieren, während der direkte Protokollzugriff weiterhin möglich ist.
  • Korrelierte Infrastruktur: Separat aussehende Endpunkte können sich einen Betreiber, eine Cloud, einen Client, ein Relay oder eine rechtliche Gefährdung teilen.
  • Datenschutzverlust: Die Weiterverbreitung über viele Dienste kann die Reichweite verbessern und gleichzeitig IP, Timing und Transaktionsverknüpfung offenlegen.
  • Schwache Ausweichmöglichkeiten: Eine erzwungene Einbeziehung kann mit Gebühren, Kautionen, Verzögerungen, Zeitfenstern, Datenanforderungen oder privilegierten Kontrollen verbunden sein.
  • Reorganisations- und Governance-Risiko: Die Aufnahme ist möglicherweise nicht endgültig und Upgrades oder Notstandsbefugnisse können Annahmen ändern.

Verwenden Sie, wo praktisch, wirklich unabhängige Pfade. Geben Sie niemals Startphrasen oder private Schlüssel an einen RPC-, Relay- oder „Anti-Zensur“-Dienst weiter und ersetzen oder senden Sie eine Transaktion nicht erneut, ohne die Nonce- und Gebührenregeln zu verstehen.

Häufige Missverständnisse

  • „Gültig bedeutet garantierte Aufnahme.“ Gültigkeit schafft Berechtigung; Produzenten wählen immer noch Transaktionen aus, es sei denn, es gelten strengere Regeln.
  • „Dezentralisiert bedeutet unzensierbar.“ Die Konzentration kann auf Produktion, Buildern, Relays, RPCs, Frontends oder Governance verbleiben.
  • „Ein blockierter RPC beweist Kettenzensur.“ Es beweist, dass ein Zugriffspfad fehlgeschlagen ist oder die Anfrage abgelehnt hat, kein netzwerkweites Veto.
  • „Eine hohe Gebühr macht jeden Filter zunichte.“ Eine wettbewerbsfähige Gebühr zielt auf wirtschaftliche Ordnung ab, nicht auf einen expliziten Filter.
  • „Eine eventuelle Einbeziehung reicht aus.“ Eine Einbeziehung nach Ablauf einer operativen Frist kann nutzlos sein; Das Zeitfenster gehört in den Anspruch.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...