השוואת ביצועי מעגל

(סעיף: מערכת אקולוגית ורשת)

1) מדוע ומה אנו משווים

• מהירויות ועיכובים: הכללה, סיום, שונות.
• כלכלה: עלות עסקאות ונתונים, יציבות עמלות.
• יציבות: שינויים, מקלחות, השפלה תחת עומס.
• זמינות נתונים: רוחב פס DA ועלות בייט.
• מערכות הפעלה: דרישות לצמתים, גודל מצב, גיוון לקוחות.

התוצאה היא KPI מאוחד המאפשר לך לבחור שרשראות/תחומים לתרחישים ספציפיים (תשלומים, משחקים/מיקרו-אירועים, גשרים, DA/פרסומים).

2) טקסונומיה של מדדים (ליבה)

2. 1 תפאורה ואתחול

מתקבל TPS/QPS

שיא TPS (שיא קצר ללא שגיאה/ירידה)

זמן להכללה (TTI) p50/p95/p99

זמן לסיכום (TTF) p50/p95/p99

ניצול בלוק%

וריאנס/ג 'יטר של עיכובים (סימון, CV)

2. 2 איכות וקיימות

אחוזי הצלחה (% מהאירועים המוצלחים tx/)

קצב יתום/Reorg (תדר ועומק)

הלביאה SLO להיט

השפלה גרייס (השפלה מבוקרת במקום כישלון)

2. 3 כלכלה ותובע מחוזי

Fe p50/p95/p99 (במטבע מקומי וב ־ USD)

עלות לכל kB (DA) - מחיר פרסום של 1 KB של נתונים

מחיר: העברה פשוטה, שיחת חוזה, קלדטה גדולה

אינדקס תנודתיות

2. 4 צמתים ומצבים

טביעת רגל חומרה (CPU/RAM/SSD/network for validator/archive node)

צמיחה ממלכתית

אינדקס מגוון לקוח

זמן סינכרון

2. מפרט 5 L2

Batch TPS (ב ־ Sentenser), Batch Size (KB)

Time-to-Batch Inclusion Time-to-Prove (ZK )/Challenge Window (אופטימי)

BreadPut DA (-/ExtenDA) שיעור כישלון

יישוב Latency (L2 * L1 finalization)

3) הליך מדידה (ניטראלי וראייתי)

1. פרופילי שימוש בטסט (TUP):

TUP-שלם: העברות קטנות (N = 70% פשוט, 30% אסימון).
TUP-Game: אירועים קצרים עם קלדטה (עד 2-8 KB).
אמצע גז וחוזי נחשול.
TUP-DA: פרסומים גדולים (50-250 KB באצ 'מי).

2. שכבות טעינה: רקע 60-80% מ-SLO + פולס 120-160% במשך 5-10 דקות כל 30-60 דקות.

3. גאוגרפיה ורשת: לפחות 3 אזורים, מטריצת RTT, זריקות ג 'יטר/איבוד (0. 5–2%).

4. גיוון לקוח: לפחות 2 צומת לקוחות לכל מעגל (אם זמין), גרסאות זהות.

5. אוסף טלמטריה: מתאם נכון (trace-ID), סינכרון זמן (NTP/PTP), תיקון תצורות.

6. finalization windows: הגדרה מפורשת של המחלוקת K/window; קרא TTF לוקח בחשבון כללים מעגליים.

7. שגיאה בסמנטיקה: טקסונומיה של כשלים (גז/נונס/גבול/DA-file/עומס יתר), לא כולל שגיאות ”צפויות” משיעור הצלחה או הדגשה בנפרד.

4) נורמליזציה ואנטי ־ הטיה

Normalization Cost: USD countractuset 'espected _ at'; "fe _ usd = fee_native × price_usd_at_t'.
שיווי משקל/גז: בהשוואה ל ”כיתות פעולה” ולא ל ”גזים גולמיים”.

TPS: ”TPS _ per _ $ = Sustained_TPS/( Monthly_Node_Cost_USD)”

השוואת מחיר לכל 1kB ועיכוב פרסום p95.
חלונות תנודתיים: חלונות שבועיים/חודשיים, חציוניים ו-IQR במקום ”רשומות חד פעמיות”.
קר נגד חם: מחמם את המטמונים; מדידות לאחר ייצוב.
עמלות MEV/PEAK: להוציא ”חריגות שוק” או להדגיש מטרי נפרד.

5) תקציר KPIs (סיכומים)

• (30%), Finality (25%), Cost (20%), Stability (15%), Uptime/Libeness (10%).
• גורמי משקל מוגדרים תחת התרחיש (לדוגמה, עבור תשלומי Finality/Cost, עבור DA/Dvision Referent/Stability).

Expective breadput @ SLO - TPS יציב בכפוף ל- ”TTF _ p95 light X”, ”הצלחה Y%”, ”Fe _ p95 light Z”.
עלות לשרת ל-1k מבצעים - העלות הכוללת של עיבוד 1000 פעולות מחלקה (כולל DA/התיישבות).
סופי SLA פגע% - הנתח של פעולות סופי בחלון היעד.

6) SLI/SLO להשוואה

• תשלומים: 'TTF _ p95', '10', 'הצלחה 99. 7% ',' Fee _ p95 alm 0 $. 01`.
• משחקים/אירועים: 'TTI _ p95 500 ms', 'TTF _ p95 lind 3', 'הצלחה 99. 5%, 'DA _ p95 store 1' s.
• DA/Publishing: "עלות _ per _ kB lood 0 $. 0005 ',' Publish _ p95 lood 2s' s ',' Finality _ p95 lord 60 '.
• יישוב L2: 'יישוב _ p95 light 10m' (ZK )/' חלון אתגר 'לאופטימיות.

7) לוחות מחוונים (פריסות התייחסות)

עדשת Perf (זמן/שעה): TTI/TTF p50/p95/p999, ניצול בלוקים, שיעור הצלחה, Fe p95, טקסונומיה שגיאה.
עלות & DA: עלות/KB, תנודתיות-Fe, DA fresput/latency, DA.
יציבות: Reorg Rate, Libeness SLO Hit, Burn-rate שגיאות, Uptime Surfenser (L2).
תכנון קיבולת: מתמשך נגד Peak TPS, חומרה-מותאמת TPS, צמיחה מדינית.

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;

אפקטיבי דרך @ 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) אינדקס מרוכב (דוגמה לחישוב)

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 ותכונות בין השרשרת

אופטימי L2: ציין ”כפול” TTF - לפני L2-inclusion ולפני סוף חלון האתגרים.
ZK L2: לחלק את זמן הפרסום ל ־ L1 ואת זמן ההוכחה/אימות הדור; קחו בחשבון את האשמה בסובלנות של המאבטחים.
Validium/DA outsource: DA metrics דרושים (הפקה/עלות/כשל), אחרת ההשוואה אינה נכונה.
פעולות חוצה שרשרת: קרא E2E TTF לתרחישי גשר (istochnik ac tsel), תוך התחשבות באתגר 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) דיווח והדמיה

טבלת סיכום לפי תרחיש: TPS יעיל, TTI/TTF p95, Fe p95, עלות/kB, הצלחה%.
תרשים מכ "ם (לכל תסריט): דרך/סופית/עלות/יציבות/לביאה.
סדרות זמן: Fe-תנודתיות, DA Latency, קוצים Reorg.
עלות x לשרת ומטריצת TTF שרשרת לכיתה.

14) תהליכים ותפקידים

Benchmark בעלים: מתודולוגיה/כלים, בקרת גירסה.
בעל אינפרה: צמתים, לקוחות, תצורות, אזורים.
נתונים/BI: צבירה, אימות, לוחות מחוונים SLO.
אבטחה/ציות: שליטה בפרטיות ותקינות של יומנים.
ממשל: פרסום תוצאות, שינוי משקל אינדקס.

15) תקריות הספסל של ספר המשחקים

סחיפה של הגדרות/גרסאות: לעצור מיד את הסדרה, לבצע צילום, להפעיל מחדש עם פרמטרים נכונים.
חריגות רשת (מחוץ לתוכניות): סימון החלון כ ”מזוהם”, חזרה על הסדרה.
כשל DA/Prover: יחיד החוצה תקרית נפרדת, לחזור על תת סדרה DA/ZK.
תנודתיות מחירים בלתי צפויה: לתקן את חלון USD החציוני, לחבר טווח.

16) רשימת מימושים

1. אישור תרחישים (TUP) ומשקולות אינדקס סיכום.
2. הקלט תצורות מארח/לקוח, אזורים, ותנאי רשת.
3. יישום אוסף טלמטריה עם מתאם וסנכרון זמן.
4. הגדרת נורמליזציה של שיעורי תשלום/DA/operation.
5. מסכים על SLI/SLO ופריסות לוח מחוונים.
6. לנהל ריצת טייס, לאמת את הרבייה, לכייל עומסים.
7. פרסמו דוחות עם יישום מלא של תצורות, גרסאות ותאריכים.

17) גלוסרי

TTI/TTF - זמן לעבור הפעלה/סיום.
שכבת זמינות נתונים.
מתמשך/שיא TPS - מתמשך/שיא תפוקה.
לבינס - היכולת של הרשת לאשר בלוקים/חבורות.
חלון אתגר - חלון אתגר בהילוכים אופטימיים.
צמיחה מדינית - עלייה בגודל של מדינת הרשת.
חומרה מותאם TPS - דרך, לוקח בחשבון את העלות של הצומת.

שורה תחתונה: ההשוואה הנכונה של ביצועי שרשרת אינה גזע ”מי יותר TPS”, אלא משמעת: תרחישים אחידים, נורמליזציה כנה של עלות ונתונים, חשבונאות לסיכום ויציבות, הגדרות שקופות ומבחני רבייה. בעקבות מסגרת זו, המערכת האקולוגית מקבלת מדדי קבלת החלטות דומים - החל בבחירת אתר למוצר וכלה בתכנון ארכיטקטורות בין-שרשרת.