Wie sollten wir Transaktionen pro Sekunde bewerten?

Ich glaube nicht, dass du das realistisch machen kannst. Ethereum hat keine theoretische Obergrenze für die Anzahl der Transaktionen. Wenn Sie mehr Transaktionen einschieben, als die Blöcke hineinpassen, werden die Blockgrößen allmählich erhöht, um sie zu berücksichtigen, also ist es theoretisch unbegrenzt.

In der Praxis beginnen die Netzwerklaufzeit, die alte Blockverarbeitung in Full Nodes und die neue Transaktionsverarbeitung in Minern, nachdem die Blockgröße über einen bestimmten Schwellenwert geschoben wurde, ihre Rechenkapazität zu sättigen. Dieser Schwellenwert wäre Ihr Durchsatzlimit. Das Problem ist, dass dies stark von den Netzwerkteilnehmern abhängt (dh wenn Full Nodes große Maschinen mit viel Bandbreite sind, wird dies hoch sein; während kleine Nodes mit geringer Bandbreite dies nach unten ziehen).

Alles in allem könnten Sie einen gewissen Durchsatz für Ihr eigenes privates Netzwerk messen, aber es wird nicht einmal im Entferntesten das Hauptnetzwerk widerspiegeln (das höher oder niedriger sein kann). Die einzige Möglichkeit, die Kapazität des Hauptnetzwerks genau zu messen, besteht darin, es im Wesentlichen mit Transaktionen zu SPAMen, was Sie eine enorme Menge kosten würde.

Vor dem Start von Frontier (seitdem eine Menge Polituren, Korrekturen, Leistungsoptimierungen und Optimierungen vorgenommen wurden) hatten wir ein olympisches Testnetzwerk und verteilten Preise, um Dinge auszuprobieren und zu überlasten. Dann haben wir, glaube ich, einen Durchsatz von etwa 25 TPS erreicht, aber auch das war ein Bruchteil unserer aktuellen Netzwerkgröße und Ressourcen, von deren Einfluss wir keine Ahnung haben. Der Rekord für das Hauptnetz (dh echte, bezahlte Transaktionen) lag bei etwa 8 TPS, aber das tat dem System nicht einmal weh.

Bei eris haben wir an einer Benchmarking-Suite gearbeitet.

Die Grundidee, die wir verfolgen, besteht darin, zunächst ein Netzwerk aus einer festgelegten Konfigurationssuite aufzubauen (gleiches Rechenzentrum, verschiedene Knotennummern, übergreifende Rechenzentren, übergreifende Cloud-Anbieter usw.).

Dann führen wir dieses Netzwerk gegen eine festgelegte Anzahl von Transaktionen aus (im Grunde peitschen wir den Mempool aus), bei denen Txes zufällig über verschiedene Netzwerkknoten gesendet werden.

Später fügen wir eine Reihe von Grundverträgen hinzu und peitschen den Mempool mit Anrufübertragungen.

Innerhalb weniger Monate werden wir das Testframework stabil genug für Open Source und umfassendere Berichte haben.

Wir tun dies nicht auf unserer Seite, gehen aber davon aus, dass ein ähnliches Paradigma sowohl für Geth- als auch für Hydra-Clients funktionieren würde.