Vergleich der Kettenleistung

(Abschnitt: Ökosystem und Netzwerk)

1) Warum und was wir vergleichen

• Geschwindigkeiten und Verzögerungen: Inklusion, Finalisierung, Variabilität.
• Volkswirtschaften: Transaktions- und Datenkosten, Stabilität der Provisionen.
• Widerstandsfähigkeit: Reorgas, Livnes, Abbau unter Last.
• Datenverfügbarkeit: DA-Bandbreite und Byte-Kosten.
• Betriebssysteme: Anforderungen an Knoten, Größe des Zustands, Diversifizierung der Kunden.

Das Ergebnis sind zusammengefasste KPIs, mit denen Sie Ketten/Domains für bestimmte Szenarien (Zahlungen, Spiele/Mikroevents, Brücken, DA/Publikationen) auswählen können.

2) Taxonomie der Metriken (Kern)

2. 1 Bandbreite und Verzögerungen

Nachhaltige TPS/QPS (stabile Bandbreite)

Peak TPS (kurzer Peak ohne Fehler/Drop)

Time-to-Inclusion (TTI) p50/p95/p99

Time-to-Finality (TTF) p50/p95/p99 (K-Bestätigungen/Challenge-Fenster berücksichtigen)

Block Utilization% (Blockbelegung/Batcha)

Variance/Jitter Verzögerungen (σ, CV)

2. 2 Qualität und Nachhaltigkeit

Erfolgsquote (% erfolgreiche tx/events)

Reorg/Orphan Rate (Frequenz und Tiefe)

Liveness SLO Hit (Erfüllung der Zielverfügbarkeit)

Degradation Grace (kontrollierter Abbau statt Fail)

2. 3 Wirtschaft und DA

Fee p50/p95/p99 (in nativer Währung und in USD)

Cost-per-kB (DA) - Veröffentlichungspreis 1 kB Daten

Cost-per-Tx Class - Preis „Transaktionstyp“: einfache Übersetzung, Vertragsaufruf, große Calldata

Fee Volatility Index (Stabilität der Fensterprovisionen)

2. 4 Knoten und Zustand

Hardware Footprint (CPU/RAM/SSD/Netzwerk für Validator/Archivknoten)

State Growth (Zustandsgewinn/Tag)

Client Diversity Index (Verteilung von Clients/Verifikatoren)

Sync Time (Schnell-/Archiv-Sync)

2. 5 L2-Spezifität

Batch TPS (beim Sentencer), Batch Size (kB)

Time-to-Batch Inclusion и Time-to-Prove (ZK) / Challenge Window (optimistic)

DA Throughput (МБ/с) и DA Failure Rate

Settlement Latency (L2→L1 Finalisierung)

3) Messtechnik (neutral und reproduzierbar)

1. Einheitlicher Lastplan (TUP - Test Use Profiles):

TUP-Pay: kleine Überweisungen (N = 70% einfach, 30% Token).
TUP-Game: Kurzveranstaltungen mit calldata (bis zu 2-8 kB).
TUP-DEX: Verträge mit mittlerem Gas und Spitzen.
TUP-DA: große Publikationen (50-250 kB Schlachten).

2. Lastschichten: Hintergrund 60-80% des Ziel-SLO + Pulse 120-160% für 5-10 Minuten alle 30-60 Minuten.

3. Geographie und Netzwerk: mindestens 3 Regionen, RTT-Matrix, Jitter/Loss-Injektionen (0. 5–2%).

4. Client-Diversifikation: mindestens 2 Knoten Clients pro Kette (wenn verfügbar), die gleichen Versionen.

5. Telemetrie-Erfassung: korrekte Korrelation (trace-ID), Zeitsynchronisation (NTP/PTP), Config-Fixierung.

6. Abschlussfenster: explizite Einstellung K/Streitfenster; TTF zählen unter Berücksichtigung der Regeln der Kette.

7. Fehlersemantik: Fehlertaxonomie (Gas/Nonce/Limit/DA-Fail/Overload), „erwartete“ Fehler aus der Erfolgsrate ausschließen oder separat hervorheben.

4) Normalisierung und Anti-Bias

Cost Normalization: USD по курсу на `observed_at`; `fee_usd = fee_native × price_usd_at_t`.
Gas/Weight Equivalence: Vergleich nach „Betriebsklassen“, nicht nach „Rohgasen“.

Hardware-Adjusted TPS: `TPS_per_$ = Sustained_TPS / (Monthly_Node_Cost_USD)`

Fair DA Vergleich: Preis pro 1 kB und p95 Veröffentlichungsverzögerung.
Volatility Windows: Wochen-/Monatsfenster, Median und IQR statt „einmalige Rekorde“.
Cold vs Warm: Aufwärmen der Caches; Messungen nach Stabilisierung.
MEV/Peak-Provisionen: „Marktanomalien“ ausschließen oder mit einer separaten Metrik hervorheben.

5) Zusammengefasste KPIs (Gesamtwerte)

• Throughput (30%), Finality (25%), Cost (20%), Stability (15%), Uptime/Liveness (10%).
• Die Gewichtungsfaktoren werden dem Szenario angepasst (z. B. für ↑Finality/Cost-Zahlungen, für ↑Throughput/Stability/DA-Spiele).

Effective Throughput @ SLO ist ein nachhaltiges TPS unter Einhaltung von 'TTF _ p95 ≤ X', 'Success ≥ Y%', 'Fee _ p95 ≤ Z'.
Cost-to-Serve per 1k Ops - Gesamtkosten für die Verarbeitung von 1000 Operationen der Klasse (einschließlich DA/Siedlung).
Finality SLA Hit% - Anteil der im Zielfenster finalisierten Transaktionen.

6) SLI/SLO zum Vergleich

• Payments: `TTF_p95 ≤ 10s`, `Success ≥ 99. 7%`, `Fee_p95 ≤ $0. 01`.
• Games/Events: `TTI_p95 ≤ 500ms`, `TTF_p95 ≤ 3s`, `Success ≥ 99. 5%`, `DA_p95 ≤ 1s`.
• DA/Publishing: `Cost_per_kB ≤ $0. 0005`, `Publish_p95 ≤ 2s`, `Finality_p95 ≤ 60s`.
• L2 Settlement: 'Settle _ p95 ≤ 10m' (ZK )/' Challenge Window 'für optimistic.

7) Dashboards (Referenzlayouts)

Perf Lens (real time/hour): TTI/TTF p50/p95/p99, Block Utilization, Success Rate, Fee p95, Error taxonomy.
Cost & DA: Cost/kB, Fee-volatility, DA throughput/latency, отказ DA.
Stabilität: Reorg Rate, Liveness SLO Hit, Burn-Rate Fehler, Sentencer Aptame (L2).
Capacity Planning: Sustained vs Peak TPS, Hardware-Adjusted TPS, State Growth.

8) Datenschema und Logik (Pseudo-SQL)

Rohe Benchmark-Ereignisse

sql
CREATE TABLE bench_events (
id TEXT PRIMARY KEY,
chain_id TEXT, layer TEXT,     -- L1    L2    app scenario TEXT,           -- payments    game    dex    da sent_at TIMESTAMPTZ,
included_at TIMESTAMPTZ,
finalized_at TIMESTAMPTZ,
size_bytes INT,
status TEXT,            -- success    fail_gas    fail_da    fail_overload...
fee_native NUMERIC, fee_usd NUMERIC,
region TEXT, client TEXT, node_profile TEXT
);

Aggregation des Kerns von Metriken

sql
WITH base AS (
SELECT,
EXTRACT(EPOCH FROM (included_at - sent_at)) AS tti_s,
EXTRACT(EPOCH FROM (finalized_at - sent_at)) AS ttf_s
FROM bench_events
WHERE status LIKE 'success%'
)
SELECT chain_id, scenario,
PERCENTILE_CONT(0. 5) WITHIN GROUP (ORDER BY tti_s) AS tti_p50,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY tti_s) AS tti_p95,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY ttf_s) AS ttf_p95,
AVG(fee_usd) AS fee_avg_usd,
100. 0 SUM(CASE WHEN status='success' THEN 1 ELSE 0 END) / COUNT() AS success_rate
FROM bench_events
GROUP BY chain_id, scenario;

Bewertung von Effective Throughput @ SLO

sql
SELECT chain_id, scenario,
COUNT() / NULLIF(EXTRACT(EPOCH FROM (MAX(sent_at) - MIN(sent_at))),0) AS tps_effective
FROM bench_events
WHERE status='success'
AND EXTRACT(EPOCH FROM (finalized_at - sent_at)) <=:ttf_p95_slo
AND fee_usd <=:fee_p95_slo
GROUP BY chain_id, scenario;

9) Verbundindex (Berechnungsbeispiel)

yaml weights:
throughput: 0. 30 finality:  0. 25 cost:    0. 20 stability: 0. 15 liveness:  0. 10

scoring:
throughput: normalize(Sustained_TPS, p10, p90)
finality:  invert(normalize(TTF_p95, p10, p90))
cost:    invert(normalize(Fee_p95_usd, p10, p90))
stability: invert(normalize(Var_TTF, p10, p90) + normalize(ReorgRate, p10, p90)/2)
liveness:  SLO_hit_pct

10) L2 und Zwischenkettenmerkmale

Optimistic L2: „dual“ TTF angeben - vor L2-Inklusion und vor Ende des Challenge-Fensters.
ZK L2: Teilen Sie die Veröffentlichungszeit in L1 und die Erzeugungs-/Prüfzeit; die Fehlertoleranz der Prüflinge berücksichtigen.
Validium/DA-Outsider: DA-Metriken sind erforderlich (throughput/cost/failure), ansonsten ist der Vergleich nicht korrekt.
Zwischenkettenoperationen: Zählen Sie die TTF- E2E für Brückenszenarien (istochnik→tsel) unter Berücksichtigung von K/DA/Challenge.

11) Anti-Vergleichsmuster (was zu vermeiden ist)

Vergleichen Sie den „Rekord-Peak“ einer Kette mit dem „Durchschnitt“ einer anderen.
Ignorieren Sie die Kosten der Daten und die Volatilität der Gebühren.
Finalisierung nicht berücksichtigen („inclusion“ mit „finality“ vergleichen).
Nehmen Sie Metriken an einem „warmen“ Knoten auf und übertragen Sie sie auf einen kalten.
Mischen Sie verschiedene Klassen von Operationen ohne Normalisierung.
Keine Client-/Config-Versionen erfassen - Reproduzierbarkeit geht verloren.

12) Testkonfigurationen und Parameter (Pseudo-YAML)

yaml benchmark:
scenarios:
- name: payments mix: { simple_transfer: 0. 7, token_transfer: 0. 3 }
slo: { ttf_p95_s: 10, success_pct: 99. 7, fee_p95_usd: 0. 01 }
- name: game mix: { small_event_2kb: 0. 6, medium_event_8kb: 0. 4 }
slo: { tti_p95_ms: 500, ttf_p95_s: 3 }
- name: da mix: { batch_50kb: 0. 5, batch_250kb: 0. 5 }
slo: { publish_p95_s: 2, cost_kb_usd: 0. 0005 }
load:
background_utilization_pct: 70 spikes: { multiplier: 1. 4, duration_min: 10, period_min: 45 }
regions: [eu-central, us-east, ap-south]
network_faults: { loss_pct: 1. 0, jitter_ms: 50 }
node_profiles:
validator: { cpu: "16c", ram_gb: 64, ssd_nvme_tb: 2, bw_gbps: 1 }
archive:  { cpu: "32c", ram_gb: 128, ssd_nvme_tb: 8, bw_gbps: 2 }

13) Berichterstattung und Visualisierung

Szenarioübersicht: Effective TPS, TTI/TTF p95, Fee p95, Cost/kB, Success%.
Radar-Chart (pro Szenario): Throughput/Finality/Cost/Stability/Liveness.
Zeitreihen: Fee-Volatilität, DA-Latenz, Reorg-Spikes.
Die Matrix „Kette × Klasse der Operation“: Cost-to-Serve und TTF.

14) Prozesse und Rollen

Benchmark Owner: Methodik/Tools, Versionskontrolle.
Infra Owner: Knoten, Kunden, Configs, Regionen.
Daten/BI: Aggregationen, Korrektheitsprüfung, SLO Dashboards.
Sicherheit/Compliance: Kontrolle der Privatsphäre und Korrektheit der Protokolle.
Governance: Ergebnisse veröffentlichen, Indexgewichte ändern.

15) Playbook der Benchmark-Vorfälle

Config/Versionsdrift: Sofortiger Serienstopp, Snapshot-Fixierung, Neustart mit korrekten Parametern.
Netzwerkanomalien (außerhalb der Planung): Fenster als „kontaminiert“ markieren, Serie wiederholen.
DA/Prouver-Ausfall: Einzelvorfall markieren, Teilserie DA/ZK wiederholen.
Unvorhergesehene Preisvolatilität: Fixieren Sie den Median USD des Fensters, befestigen Sie die Range.

16) Checkliste Umsetzung

1. Genehmigen Sie Skripte (TUPs) und Gewichte des Zusammenfassungsindex.
2. Notieren Sie die Configs von Knoten/Clients, Regionen und Netzwerkbedingungen.
3. Implementieren Sie Telemetrie-Sammlung mit Korrelation und Zeitsynchronisation.
4. Normalisierung von Fee/DA/Operations-Klassen einrichten.
5. SLI/SLO und Dashboardlayouts abstimmen.
6. Führen Sie eine Pilotserie durch, überprüfen Sie die Reproduzierbarkeit, kalibrieren Sie die Lasten.
7. Veröffentlichen Sie Berichte mit einer vollständigen Anwendung von Config, Versionen und Datumsangaben.

17) Glossar

TTI/TTF - Zeit bis zum Einschalten/Finalisieren.
DA - Datenverfügbarkeitsschicht (Data Availability Layer).
Nachhaltig/Peak TPS - Nachhaltige/Peak-Bandbreite.
Liveness - die Fähigkeit des Netzwerks, Blöcke/Batchi zu bestätigen.
Das Challenge Window ist ein Anfechtungsfenster in optimistischen Rollaps.
State Growth - Erhöhung der Größe des Netzwerkzustands.
Hardware-Adjusted TPS - Bandbreite unter Berücksichtigung der Knotenkosten.

Fazit: Ein korrekter Vergleich der Kettenleistung ist kein Wettlauf „wer ist größer als TPS“, sondern eine Disziplin: einheitliche Szenarien, ehrliche Normalisierung von Kosten und Daten, Berücksichtigung von Finalisierung und Nachhaltigkeit, transparente Configs und reproduzierbare Tests. Diesem Rahmen folgend erhält das Ökosystem vergleichbare, entscheidungsfähige Metriken - von der Standortwahl für das Produkt bis zur Planung von Interchain-Architekturen.