ჯაჭვების შესრულების შედარება

(განყოფილება: ეკოსისტემა და ქსელი)

1) რატომ და რას შევადარებთ

• სიჩქარე და შეფერხებები: ჩართვა, დასრულება, ცვალებადობა.
• ეკონომიკა: გარიგებისა და მონაცემების ღირებულება, კომისიების სტაბილურობა.
• სტაბილურობა: რეორგები, წვიმა, დატვირთვის დეგრადაცია.
• მონაცემთა ხელმისაწვდომობა: DA გამტარუნარიანობა და ბაიტის ღირებულება.
• ოპერატორები: კვანძების მოთხოვნები, სახელმწიფოს ზომა, მომხმარებელთა დივერსიფიკაცია.

შედეგი არის კონსოლიდირებული KPI, რომელიც საშუალებას გაძლევთ აირჩიოთ ჯაჭვები/დომენები კონკრეტული სცენარისთვის (გადახდები, თამაშები/მიკრო ტირაჟი, ხიდები, DA/პუბლიკაციები).

2) მეტრიკის ტაქსონომია (ბირთვი)

2. 1 გამტარუნარიანობა და შეფერხება

TPS/QPS (სტაბილური გამტარუნარიანობა)

Peak TPS (მოკლე მწვერვალი შეცდომების/ფრენის გარეშე)

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

დრო Finality (TTF) p50/p95/p99 (გაითვალისწინეთ K- მტკიცებულებები/გამოწვევის ფანჯარა)

Block Utilization% (ბლოკის/ბრძოლის შევსება)

Variance/Jitter შეფერხებები (CV)

2. 2 ხარისხი და სტაბილურობა

Success Rate (% წარმატებული tx/events)

Reorg/Orphan Rate (სიხშირე და სიღრმე)

Liveness SLO Hit (მიზნობრივი წვდომის განხორციელება)

Degradation Grace (კონტროლირებადი დეგრადაცია ყალბის ნაცვლად)

2. 3 ეკონომიკა და DA

Fee p50/p95/p99 (მშობლიური ვალუტით და აშშ დოლარით)

Cost-per-kB (DA) - 1 KB მონაცემების გამოქვეყნების ფასი

Cost-per-Tx Class - „გარიგების ტიპის“ ფასი: მარტივი გადაცემა, ხელშეკრულების გამოწვევა, დიდი calldata

Fee Volatility Index (ფანჯრების კომისიების სტაბილურობა)

2. 4 კვანძები და მდგომარეობა

Hardware Footprint (CPU/RAM/SSD/ქსელი სავალდებულო/საარქივო კვანძისთვის)

სახელმწიფო გროვა (სახელმწიფო ზრდა/დღე)

Client Diversity Index (მომხმარებელთა/გადამოწმების განაწილება)

Sync Time (სწრაფი/საარქივო სიგნალი)

2. 5 L2 სპეციფიკა

Batch TPS (Centencer), Batch Size (KB)

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

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

Settlement Latency (L2, L1 საბოლოო)

3) გაზომვის ტექნიკა (ნეიტრალური და რეპროდუცირებული)

1. ერთი დატვირთვის გეგმა (TUP - Test Use Profiles):

TUP-Pay: მცირე გადარიცხვები (N = 70% simple, 30% token).
TUP-Game: მოკლე მოვლენები calldata- ით (2-8 კბ-მდე).
TUP-DEX: კონტრაქტები საშუალო გაზით და ადიდებით.
TUP-DA: დიდი პუბლიკაციები (50-250 კბ ბრძოლები).

2. დატვირთვის ფენები: სამიზნე SLO + პულსი 120-160% 5-10 წუთის განმავლობაში ყოველ 30-60 წუთში.

3. გეოგრაფია და ქსელი: მინიმუმ 3 რეგიონი, RTT მატრიცა, jitter/loss ინექციები (0. 5–2%).

4. კლიენტის დივერსიფიკაცია: მინიმუმ 2 მომხმარებელი კვანძისთვის (თუ ხელმისაწვდომია), იგივე ვერსიები.

5. ტელემეტრიული შეგროვება: სწორი კორელაცია (trace-ID), დროის სინქრონიზაცია (NTP/PTP), კონფიგურაციების დაფიქსირება.

6. ფინალიზაციის ფანჯრები: დავის ფანჯრის K/ფანჯრის აშკარა კონფიგურაცია; TTF განიხილება ჯაჭვის წესების გათვალისწინებით.

7. შეცდომების სემანტიკა: წარუმატებლობის ტაქსონომია (გაზი/nonce/ლიმიტი/DA-fail/overload), გამორიცხავს „მოსალოდნელ“ შეცდომებს Success Rate- დან ან ცალკე გამოყოფს.

4) ნორმალიზაცია და ანტი-ოფსეტური

Cost Normalization: USD по курсу на `observed_at`; `fee_usd = fee_native × price_usd_at_t`.
Gas/Weight Equivalence: შედარება „ოპერაციების კლასებზე“ და არა „ნედლეულ გაზებზე“.

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

Fair DA Compare: ფასი 1 კბ და p95 გამოქვეყნების შეფერხება.
Volatily Windows: ყოველკვირეული/ყოველთვიური ფანჯრები, საშუალო და IQR „ერთჯერადი ჩანაწერების“ ნაცვლად.
ცივი vs Warm: გაათბეთ ქეში; გაზომვები სტაბილიზაციის შემდეგ.
MEV/პიკის კომისიები: გამორიცხეთ „ბაზრის ანომალიები“ ან ცალკეული მეტრიკა.

5) კონსოლიდირებული KPI (საბოლოო მაჩვენებლები)

• Throughput (30%), Finality (25%), Cost (20%), Stability (15%), Uptime/Liveness (10%).
• წონის კოეფიციენტები შეესაბამება სცენარს (მაგალითად, გადახდისთვის Finality/Cost, თამაშებისთვის - Throughput/Stability/DA).

Effective Throughput @ SLO - სტაბილური TPS "TTF _ p95" X ", 'Success' Y%", 'Fee _ p95 "Z' შესაბამისად.
Cost-to-Serve per 1k Ops არის 1000 კლასის ოპერაციის დამუშავების სრული ღირებულება (მათ შორის DA/settlement).
Finality SLA Hit% არის სამიზნე ფანჯარაში დასრულებული ოპერაციების წილი.

6) SLI/SLO შედარებისთვის

• 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 ფანჯარა optimistic- ისთვის.

7) დაშბორდი (რეფერენდუმის განლაგება)

Perf Lens (ნამდვილი დრო/საათი): TTI/TTF p50/p95/p99, Block Utilization, Success Rate, Fee p95, Error taxonomy.
Cost & DA: Cost/kB, Fee-volatility, DA throughput/latency, отказ DA.
Stability: Reorg Rate, Liveness SLO Hit, Burn-rate შეცდომები, ცენტრის აფთიაქი (L2).
Capacity Planning: Sustained vs Peak TPS, Hardware-Adjusted TPS, State Growth.

8) მონაცემთა სქემა და ლოგიკა (ფსევდო-SQL)

საწვავის ბრენდის ნედლეული მოვლენები

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

მეტრიული ბირთვის აგრეგაცია

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;

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) კომპოზიციური ინდექსი (გაანგარიშების მაგალითი)

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 და შუალედური მახასიათებლები

Optimistic L2: მიუთითეთ „ორმაგი“ TTF - L2 ინკლუზიურობამდე და დასრულებამდე.
ZK L2: გამოქვეყნების დრო დაყოფა L1- ში და პრუფის თაობის/გადამოწმების დრო; გაითვალისწინეთ აუზების წინააღმდეგობა.
Validium/DA autsors: DA მეტრიკები სავალდებულოა (throughput/cost/failure), წინააღმდეგ შემთხვევაში შედარება არასწორია.
ინტერჯგუფური ოპერაციები: განიხილეთ E2E TTF ხიდის სცენარებისთვის (წყარო - მიზანი), K/DA/გამოწვევის გათვალისწინებით.

11) შედარების ანტი-შაბლონები (რა ავიცილოთ თავიდან)

ერთი ჯაჭვის „რეკორდული მწვერვალის“ შედარება „საშუალო“ მეორესთან.
უგულებელყოს მონაცემების ღირებულება და კომისიების ცვალებადობა.
არ გაითვალისწინოთ ფინალიზაცია (შეადარეთ „ინკლუზია“, როგორც „ფინანსური“).
ამოიღეთ მეტრიკები „გაცხელებულ“ კვანძზე და გადაიტანეთ ცივი.
აურიეთ ოპერაციების სხვადასხვა კლასები ნორმალიზაციის გარეშე.
არ ჩაწეროთ მომხმარებლების/ჩამორთმევის ვერსიები - რეპროდუქცია იკარგება.

12) კონფიგურაცია და ტესტის პარამეტრები (ფსევდო-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) ანგარიშები და ვიზუალიზაცია

შემაჯამებელი ცხრილი სკრიპტების მიხედვით: Effective TPS, TTI/TTF p95, Fee p95, Cost/kB, Success%.
რადარის გრაფიკი (სცენარისთვის): Throughput/Finality/Cost/Stability/Liveness.
დროებითი რიგები: Fee-volatility, DA ლატენტობა, Reorg spikes.
მატრიცა „ჯაჭვის × ოპერაციის კლასი“: Cost-to-Serve და TTF.

14) პროცესები და როლები

Benchmark Owner: მეთოდოლოგია/ინსტრუმენტები, ვერსიების კონტროლი.
Infra Owner: კვანძები, კლიენტი, კონფისკაცია, რეგიონები.
Data/BI: აგრეგაციები, სისწორის შემოწმება, SLO დაშბორდები.
Security/Compliance: კონფიდენციალურობის კონტროლი და ლოგოების სისწორე.
მთავრობა: შედეგების გამოქვეყნება, ინდექსის წონის შეცვლა.

15) Playbook ინციდენტები

კონფიგურაციის/ვერსიების დრიფტი: სერიის დაუყოვნებელი გაჩერება, snapshot- ის დაფიქსირება, გადატვირთვა სწორი პარამეტრებით.
ქსელის ანომალიები (დაგეგმილი გარეთ): ფანჯრის აღნიშვნა, როგორც „დაბნეული“, სერიის განმეორება.
DA/Prover- ის მარცხი: ცალკეული ინციდენტის გამოყოფა, განმეორება DA/ZK სერიისთვის.
ფასების გაუთვალისწინებელი ცვალებადობა: ჩაწერეთ საშუალო აშშ დოლარი ფანჯრები, მიამაგრეთ დიაპაზონი.

16) განხორციელების შემოწმების სია

1. დაამტკიცეთ სკრიპტები (TUP) და შემაჯამებელი ინდექსის წონა.
2. ჩაწერეთ კვანძები/მომხმარებლები, რეგიონები და ქსელის პირობები.
3. ტელემეტრიული შეგროვების განხორციელება დროის კორელაციასთან და სინქრონიზაციასთან.
4. კონფიგურაცია fee/DA/ოპერაციების კლასების ნორმალიზებისთვის.
5. კოორდინირებული SLI/SLO და დაშბორდის მოდელები.
6. ჩაატარეთ საპილოტე სერია, შეამოწმეთ რეპროდუქცია, დატვირთეთ დატვირთვა.
7. გამოაქვეყნეთ მოხსენებები კონფიგურაციების, ვერსიების და თარიღების სრული აპლიკაციით.

17) გლოსარიუმი

TTI/TTF - ჩართვის/დასრულების დრო.
DA - მონაცემთა ხელმისაწვდომობის ფენა (Data Availability).
Sustained/Peak TPS - სტაბილური/მწვერვალი გამტარუნარიანობა.
Liveness - ქსელის უნარი დაადასტუროს ბლოკები/ბატჩები.
Challenge Window არის სადავო ფანჯარა optimistic-rollaps- ში.
სახელმწიფო გროვა არის ქსელის ზომების ზრდა.
Hardware-Adjusted TPS - გამტარუნარიანობა კვანძის ღირებულების გათვალისწინებით.

შედეგი: ჯაჭვების პროდუქტიულობის სწორი შედარება არ არის რბოლა „ვინ უფრო დიდია TPS“, არამედ დისციპლინა: ერთიანი სცენარები, ღირებულებისა და მონაცემების გულწრფელი ნორმალიზაცია, საბოლოო და სტაბილურობის აღრიცხვა, გამჭვირვალე კონფიგურაციები და რეპროდუცირებული ტესტები. ამ ჩარჩოს შემდეგ, ეკოსისტემა იღებს შედარებულ მეტრიკებს, რომლებიც შესაფერისია გადაწყვეტილების მისაღებად - პროდუქტის საიტის არჩევიდან დაწყებული ინტერჯექტორული არქიტექტურების დაგეგმვამდე.