Porównanie wydajności obwodu

(Sekcja: Ekosystem i sieć)

1) Dlaczego i co porównujemy

• Prędkości i opóźnienia: włączenie, finalizacja, zmienność.
• Ekonomia: koszt transakcji i danych, stabilność prowizji.
• Stabilność: reorgs, prysznice, degradacja pod obciążeniem.
• Dostępność danych: przepustowość i koszt bajtu DA.
• Systemy operacyjne: wymagania dotyczące węzłów, wielkości państwa, dywersyfikacji klientów.

Wynikiem są skonsolidowane KPI, które pozwalają wybrać łańcuchy/domeny dla określonych scenariuszy (płatności, gry/mikroprzedsiębiorstwa, mosty, DA/publikacje).

2) Taksonomia mierników (rdzeń)

2. 1 Przepustowość i opóźnienie

Trwały TPS/QPS

Szczyt TPS (krótki szczyt bez błędu/spadku)

Czas do włączenia (TTI) p50/p95/p99

Czas do końca (TTF) p50/p95/p99

Wykorzystanie bloku%

Wariancja/Jitter opóźnień (, CV)

2. 2 Jakość i zrównoważony rozwój

Wskaźnik sukcesu (% udanych tx/zdarzeń)

Wskaźnik Reorg/Sierota (częstotliwość i głębokość)

Livity SLO Hit

Grace degradacji (kontrolowana degradacja zamiast awarii)

2. 3 Gospodarka i DA

Opłata p50/p95/p99 (w walucie ojczystej i w USD)

Cost-per-kB (DA) - cena publikacji 1 kB danych

Cost-per-Tx Class - „typ transakcji” cena: prosty transfer, wywołanie umowy, duża calldata

Wskaźnik zmienności opłat

2. 4 Węzły i status

Footprint sprzętowy (CPU/RAM/SSD/network for validator/archive node)

Wzrost państwa

Wskaźnik różnorodności klienta

Czas synchronizacji

2. 5 Specyfika L2

Batch TPS (w Sentenser), Batch Size (kB)

Włączenie czasowe do partii - Czas-do-Prove (ZK )/Okno wyzwań (optymistyczne)

Współczynnik awarii DA Δput (М,/,) - DA

Opóźnienie rozliczeń (L2 → finalizacja L1)

3) Procedura pomiaru (neutralna i powtarzalna)

1. Profile zastosowań testowych (TUP):

TUP-Pay: małe transfery (N = 70% proste, 30% token).
TUP-Game: krótkie wydarzenia z calldata (do 2-8 kB).
TUP-DEX: Kontrakty na gaz średni i kontrakty na przekroczenie prędkości.
TUP-DA: duże publikacje (50-250 kB batchami).

2. Warstwy obciążenia: tło 60-80% docelowych impulsów SLO + 120-160% przez 5-10 minut co 30-60 minut.

3. Geografia i sieć: co najmniej 3 regiony, matryca RTT, zastrzyki jitter/strata (0. 5–2%).

4. Dywersyfikacja klienta: co najmniej 2 klienci węzłów na obwód (jeśli dostępne), identyczne wersje.

5. Kolekcja telemetrii: poprawna korelacja (trace-ID), synchronizacja czasu (NTP/PTP), konfiguracje mocowania.

6. Okna finalizacji: wyraźne ustawienie sporu K/window; Przeczytaj TTF z uwzględnieniem zasad obwodu.

7. Semantyka błędów: taksonomia awarii (gaz/nonce/limit/DA-file/overload), wyłączenie błędów „oczekiwanych” ze wskaźnika sukcesu lub wyróżnienie oddzielnie.

4) Normalizacja i anty-stronniczość

Koszt Normalizacja: USD мрса на 'observed _ at'; 'fee _ usd = fee_native × price_usd_at_t'.
Równoważność gazu/masy: porównanie przez „klasy operacyjne”, a nie „gazy surowe”.

Regulowany sprzętowo TPS: 'TPS _ per _ $ = Sustained_TPS/( Monthly_Node_Cost_USD)'

Fair DA Porównaj: cena za 1kB i p95 opóźnienie publikacji.
Okna zmienności: Okna tygodniowe/miesięczne, mediana i IQR zamiast „rekordów jednorazowych”.
Cold vs Ciepło: podgrzewanie buforów; pomiary po ustabilizowaniu.
Prowizje MEV/Peak: wykluczyć „anomalie rynkowe” lub podkreślić oddzielną metrykę.

5) Zestawienie KPI (ogółem)

• Przepustowość (30%), Finalność (25%), Koszt (20%), Stabilność (15%), Uptime/Livity (10%).
• Współczynniki korygujące są tworzone zgodnie ze scenariuszem (na przykład w odniesieniu do gier w kategorii „Na zakończenie ”/„ Koszty płatności”, „Na przykład” w przypadku gier „na rzecz stabilności”).

Efektywna przepustowość @ SLO - stabilny TPS podlegający 'TTF _ p95 ≤ X', 'Success ≥ Y%', 'Fee _ p95 ≤ Z'.
Cost-to-Serve na 1k Ops - całkowity koszt przetwarzania 1000 operacji klasy (w tym DA/rozliczenie).
Finalność SLA Hit% - udział operacji zakończonych w oknie docelowym.

6) SLI/SLO do porównania

• Płatności: „TTF _ p95 ≤ 10s',” Sukces ≥ 99. 7% ',' Opłata _ p95 ≤ 0 USD. 01`.
• Gry/Wydarzenia: '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'.
• Rozrachunek L2: 'Settle _ p95 ≤ 10m' (ZK )/' challenge window 'dla optymizmu.

7) Deski rozdzielcze (układ odniesienia)

Obiektywy Perf (czas rzeczywisty/godzina): TTI/TTF p50/p95/p99, Wykorzystanie bloku, Wskaźnik sukcesu, Opłata p95, Taksonomia błędu.
Koszt & DA: Koszt/kB, Zmienność opłat, przepustowość/opóźnienie DA, откаz DA.
Stabilność: Wskaźnik Reorg, Livity SLO Hit, Błędy prędkości spalania, sentenser uptime (L2).
Planowanie pojemności: Trwały vs Peak TPS, Sprzęt dostosowany TPS, Wzrost stanu.

8) Schemat i logika danych (pseudo-SQL)

Nieprzetworzone zdarzenia wzorcowe

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
);

Agregacja jądra metrycznego

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;

Efektywna przepustowość @ SLO Score

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) Wskaźnik złożony (przykład obliczeń)

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) Cechy L2 i międzysieciowe

Optymistyczny L2: wskazać „podwójny” TTF - przed L2-inclusion i przed końcem okna wyzwania.
ZK L2: podzielić czas publikacji na L1 i czas generowania/weryfikacji dowodu; wziąć pod uwagę tolerancję błędów u kontrolerów.
Validium/DA outsource: wymagane są wskaźniki DA (przepustowość/koszt/awaria), w przeciwnym razie porównanie jest nieprawidłowe.
Operacje cross-chain: czytaj E2E TTF dla scenariuszy mostowych (istochnik → tsel), biorąc pod uwagę K/DA/challenge.

11) Wzorce antykonkurencyjne (czego należy unikać)

Porównaj "rekordowy szczyt' jednego łańcucha z" średnią "drugiego.
Ignorowanie kosztów danych i zmienności prowizji.
Ignoruj finalizację (porównaj „włączenie” jako „finalność”).
Strzelać metryki na „ciepłym” węźle i przenieść do zimnego.
Mieszać różne klasy operacji bez normalizacji.
Nie akceptuj wersji/konfiguracji klienta - odtwarzalność jest stracona.

12) Konfiguracje i parametry badań (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) Sprawozdawczość i wizualizacja

Tabela podsumowująca według scenariusza: Efektywny TPS, TTI/TTF p95, Opłata p95, Koszt/kB, Sukces%.
Wykres radarowy (na skrypt): Przepustowość/Finalność/Koszt/Stabilność/Urok.
Seria czasu: Zmienność opłat, opóźnienie DA, kolce Reorg.
Koszt × macierz łańcucha do klasy do obsługi i TTF.

14) Procesy i role

Właściciel benchmark: metodologia/narzędzia, kontrola wersji.
Infra Owner: węzły, klienci, konfiguracje, regiony.
Dane/BI: agregacje, walidacja, deski rozdzielcze SLO.
Bezpieczeństwo/Zgodność: kontrola prywatności i poprawności dzienników.
Zarządzanie: publikowanie wyników, zmiana wagi indeksu.

15) Incydenty wzorcowe Playbook

Dryf konfiguracji/wersji: natychmiast zatrzymać serię, popełnić migawkę, ponownie uruchomić z poprawnymi parametrami.
Anomalie sieciowe (poza planowanymi): oznaczanie okna jako „skażone”, powtarzanie serii.
Awaria DA/prover: wydzielić oddzielny incydent, powtórzyć podgrupę DA/ZK.
Nieoczekiwana zmienność cen: naprawić średnie okno USD, dołączyć zakres.

16) Lista kontrolna wdrażania

1. Zatwierdzać scenariusze (TUP) i współczynniki sumaryczne.
2. Rejestruj konfiguracje hosta/klienta, regiony i warunki sieciowe.
3. Wdrożyć kolekcję telemetrii z korelacją i synchronizacją czasu.
4. Ustaw normalizację klas opłat/DA/operacji.
5. Uzgodnić układy SLI/SLO i deski rozdzielczej.
6. Przeprowadzić operację pilotażową, sprawdzić odtwarzalność, skalibrować obciążenia.
7. Publikuj raporty z pełnym zastosowaniem konfiguracji, wersji i dat.

17) Słownik

TTI/TTF - czas na włączenie/finalizację.
DA - warstwa dostępności danych.
Utrzymany/szczytowy TPS - utrzymany/szczytowy przepustowość.
Livity - zdolność sieci do potwierdzenia bloków/partii.
Wyzwanie okno - okno wyzwanie w optymistycznych rollups.
Wzrost państwa - wzrost wielkości państwa sieci.
Regulowany sprzętowo TPS - przepustowość, biorąc pod uwagę koszt węzła.

Najważniejsze: prawidłowe porównanie wydajności łańcucha nie jest wyścigiem „kto jest bardziej TPS”, ale dyscypliną: jednolite scenariusze, uczciwą normalizację kosztów i danych, rozliczanie finalizacji i stabilności, przejrzyste konfiguracje i powtarzalne testy. Zgodnie z tymi ramami ekosystem otrzymuje porównywalne, decyzyjne mierniki - od wyboru miejsca na produkt do planowania architektur międzysystemowych.