Ist das SPV-Client-Modell skalierbar?

SPV-Clients verbinden sich in der Regel mit Full-Node-Peers und legen Filter dafür fest, welche Informationen sie herunterladen. Wie viele SPV-Peers kann ein einzelner vollständiger Knoten normalerweise unterstützen?

Ist es vernünftig zu erwarten, dass sich Millionen von SPV-Knotenbenutzern mit ~6.000 vollständigen Knoten verbinden?

Antworten (1)

Im Allgemeinen hat BIP37 Bloom Filtering SPV eine schreckliche Skalierung, obwohl es schwer zu sagen ist, wie schlecht es in der Realität ist.

  • Jeder Peer muss die gesamte Blockchain ab dem letzten Kontakt mit dem Netzwerk synchronisieren, im schlimmsten Fall sind das ca. 50GB. Der Knoten muss jeden einzelnen Block von der Festplatte laden, ihn nach den Spezifikationen des Clients filtern und das Ergebnis zurückgeben. Der Betrag wächst bis zum Ende von Bitcoin oder Zeit, je nachdem, was zuerst eintritt. Ohne einige Protokolländerungen ist das Pruning nicht mit BIP37 SPV kompatibel, da es erwartet, dass alle Blöcke auf allen Hosts verfügbar sind.

  • Für jede synchronisierte Brieftasche muss jeder eingehende Block und jede Transaktion einzeln gefiltert werden. Dies beinhaltet eine nicht vernachlässigbare Menge an CPU-Zeit und muss für jeden Peer der Reihe nach für jedes Inventarelement durchgeführt werden.

    • Es ist unklar, wie viel CPU-Leistung ein durchschnittlicher Knoten hat, aber zumindest ein Teil der Knoten läuft auf der Unterseite der Barrel-Hardware wie ein Raspberry Pi, der höchstwahrscheinlich nicht mehr als ein paar Peers gleichzeitig bedienen kann Zeit.

      In ähnlicher Weise wird ein großer Teil der Listening-Knoten auf preisgünstigen VPS-Anbietern gehostet, die einen einzigen gemeinsam genutzten Kern und eine extrem schlechte Leistung bieten. OVH hat 300, Hetzner hat 300 , Digital Ocean hat 124, CloudAtCost ist mit 6 wirklich das Schlusslicht.

  • BIP37 ist anfällig für triviale Denial-of-Service-Angriffe, es ist Democode verfügbar , der in der Lage ist, Knoten durch schnelle Inventarisierungsanforderungen durch Filter lahmzulegen, was zu kontinuierlicher Festplattensuche und hoher CPU-Auslastung führt. Es ist verlockend zu sagen, dass Kunden einen Arbeitsnachweis (aber dies ist auf einem batteriebetriebenen Gerät wie einem Telefon unmöglich) oder Mikrozahlungen (unmöglich, wenn ein Knoten noch nicht weiß, dass er Geld erhalten hat) verwenden könnten, aber keines von beiden bietet wirklich eine klare Lösung .

  • Es gibt wahrscheinlich auch viel weniger als 6000 lauschende Knoten, einige sind beschnitten, was für einen SPV-Client zur Synchronisierung ziemlich nutzlos ist, viele lauschen sowohl auf IPv4 als auch auf IPv6 und werden daher in dieser Anzahl dupliziert. Die tatsächliche Anzahl der tatsächlichen Knoten liegt wahrscheinlich eher bei 5000, und die Anzahl von ihnen, die keine Uplinks mit DFÜ-Geschwindigkeit verwenden, ist wesentlich geringer.

Ist es vernünftig zu erwarten, dass sich Millionen von SPV-Knotenbenutzern mit ~6.000 vollständigen Knoten verbinden?

Absolut nicht, schon allein deshalb, weil der Code standardmäßig auf maximal 117 eingehende Verbindungen gesetzt ist, was rund einer halben Million insgesamt verfügbarer Sockets im Netzwerk entspricht (von denen die meisten heute bereits verbraucht sind).