GH GambleHub

Devre performans karşılaştırması

(Bölüm: Ekosistem ve Ağ)

1) Neden ve neyi karşılaştırıyoruz

Amaç, aşağıdakileri dikkate alarak farklı zincirlerin (L1, L2, uygulama zinciri, validium/rollup) performansını karşılaştırmak için tekrarlanabilir ve nötr bir yol oluşturmaktır:
  • Hızlar ve gecikmeler: dahil etme, sonuçlandırma, değişkenlik.
  • Ekonomi: işlemlerin ve verilerin maliyeti, komisyonların istikrarı.
  • Stabilite: reorgs, duşlar, yük altında bozulma.
  • Veri kullanılabilirliği: DA bant genişliği ve bayt maliyeti.
  • İşletim sistemleri: düğümler için gereksinimler, durum boyutu, müşteri çeşitliliği.

Sonuç, belirli senaryolar (ödemeler, oyunlar/mikro olaylar, köprüler, DA/yayınlar) için zincirler/etki alanları seçmenize izin veren konsolide KPI'lardır.

2) Metriklerin taksonomisi (çekirdek)

2. 1 İşlem hacmi ve gecikme süresi

Sürekli TPS/QPS

Tepe TPS (hata/düşme olmadan kısa tepe)

Dahil Etme Süresi (TTI) p50/p95/p99

Zaman-Sonluluk (TTF) p50/p95/p99

Blok kullanımı %

Varyans/Gecikmelerin titreşimi (σ, CV)

2. 2 Kalite ve sürdürülebilirlik

Başarı Oranı (başarılı tx/etkinlik yüzdesi)

Reorg/Orphan Oranı (frekans ve derinlik)

Liveness SLO Hit

Degradation Grace (hata yerine kontrollü bozulma)

2. 3 Ekonomi ve DA

Ücret p50/p95/p99 (yerel para birimi cinsinden ve USD cinsinden)

kB başına maliyet (DA) - 1 kB veri yayın fiyatı

Tx Sınıfı başına maliyet - "işlem tipi" fiyat: basit transfer, sözleşme çağrısı, büyük arama verileri

Ücret Volatilite Endeksi

2. 4 Düğümler ve durum

Donanım Ayak İzi (doğrulayıcı/arşiv düğümü için CPU/RAM/SSD/ağ)

Devlet büyüme

Müşteri çeşitliliği indeksi

Zamanı senkronize et

2. 5 L2 özgüllüğü

Toplu TPS (Sentenser'de), Toplu İş Boyutu (kB)

Time-to-Batch Dahil Etme и Time-to-Prove (ZK )/Meydan Okuma Penceresi (iyimser)

DA İş Hacmi (МБ/с) и DA Arıza Oranı

Yerleşim Gecikmesi (L2 - L1 kesinleştirmesi)

3) Ölçüm prosedürü (nötr ve tekrarlanabilir)

1. Test Kullanım Profilleri (TUP):

TUP-Pay: küçük transferler (N = %70 basit, %30 belirteç).
TUP-Game: calldata ile kısa etkinlikler (2-8 kB'ye kadar).
TUP-DEX: Orta gaz ve dalgalanma sözleşmeleri.
TUP-DA: Büyük yayınlar (50-250 kB batchami).

2. Yük katmanları: Hedef SLO + darbelerinin %60-80'i arka plan Her 30-60 dakikada bir 5-10 dakika boyunca %120-160.

3. Coğrafya ve ağ: En az 3 bölge, RTT matrisi, jitter/loss enjeksiyonları (0. 5–2%).

4. İstemci çeşitlendirmesi: Devre başına en az 2 düğüm istemcisi (varsa), aynı sürümler.

5. Telemetri toplama: doğru korelasyon (trace-ID), zaman senkronizasyonu (NTP/PTP), yapılandırmaların sabitlenmesi.

6. Sonuçlandırma pencereleri: anlaşmazlık K/penceresinin açık ayarı; Devre kurallarını dikkate alarak TTF'yi okuyun.

7. Hata semantiği: hata taksonomisi (gaz/nonce/limit/DA-dosya/aşırı yük), "beklenen" hataları Başarı Oranı'ndan hariç tutun veya ayrı olarak vurgulayın.

4) Normalleşme ve anti-önyargı

Maliyet Normalleştirme: USD 'observed _ at'; 'fee _ usd = .
Gaz/Ağırlık Eşdeğerliği: "Ham gazlar" yerine "işletme sınıfları'ile karşılaştırma.

Donanım Ayarlı TPS: 'TPS _ per _ $ = Sustained_TPS/( Monthly_Node_Cost_USD)'

Adil DA Karşılaştırma: 1kB başına fiyat ve p95 yayın gecikmesi.
Volatilite Pencereleri: Haftalık/aylık pencereler,'tek seferlik kayıtlar "yerine medyan ve IQR.
Soğuk vs Sıcak: Önbellekleri ısıtmak; Stabilizasyondan sonra ölçümler.
MEV/Peak komisyonları: "piyasa anomalilerini" hariç tutar veya ayrı bir metriği vurgular.

5) Özet KPI'lar (toplamlar)

Çekirdek Performans Puanı (CPS) - 0.. 100, ağırlık toplamı:
  • Verimlilik (%30), Kesinlik (%25), Maliyet (%20), Kararlılık (%15), Çalışma Süresi/Yaşanabilirlik (%10).
  • Ağırlıklandırma faktörleri senaryo altında ayarlanır (örneğin, ↑Finality/Cost ödemeler için, ↑Throughput/Stability/DA oyunlar için).

Etkili Verim @ SLO - 'TTF _ p95 ≤ X', 'Başarı ≥ Y %', 'Fee _ p95 ≤ Z'ye tabi istikrarlı TPS.
1k Ops başına Cost-to-Serve - 1000 sınıfı işlemlerin (DA/yerleşim dahil) işlenmesinin toplam maliyeti.
Finality SLA Hit % - hedef pencerede tamamlanan işlemlerin payı.

6) Karşılaştırma için SLI/SLO

SLO örnekleri (komut dosyası):
  • Ödemeler: 'TTF _ p95 ≤ 10s', 'Başarı ≥ 99. %7 ',' Fee _ p95 ≤ $0. 01`.
  • Oyunlar/Etkinlikler: 'TTI _ p95 ≤ 500ms', 'TTF _ p95 ≤ 3s', 'Başarı ≥ 99. 5 % ',' DA _ p95 ≤ 1s '.
  • DA/Yayıncılık: 'Cost _ per _ kB ≤ $0. 0005 ',' Publish _ p95 ≤ 2s ',' Finality _ p95 ≤ 60s '.
  • L2 Yerleşim:' Settle _ p95 ≤ 10m '(ZK )/iyimser için" meydan okuma penceresi ".

7) Gösterge Panoları (referans düzenleri)

Perf Lens (gerçek zamanlı/saat): TTI/TTF p50/p95/p99, Blok Kullanımı, Başarı Oranı, Ücret p95, Hata taksonomisi.
Maliyet ve DA: Maliyet/kB, Ücret oynaklığı, DA verimi/gecikmesi отказ DA.
Kararlılık: Reorg Rate, Liveness SLO Hit, Burn-rate hataları, uptime sentenser (L2).
Kapasite Planlama: Sürekli ve Tepe TPS, Donanım Ayarlı TPS, Durum Büyümesi.

8) Veri şeması ve mantığı (pseudo-SQL)

Ham kıyaslama etkinlikleri

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

Metrik Çekirdek Toplama

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;

Etkili Verim @ SLO Puanı

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) Bileşik endeks (hesaplama örneği)

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
💡 'normalize (x, p10, p90)' - yüzdelik dilimlere göre [0,1]'e doğrusal dönüşüm; 'invert (y) = 1 − y'.

10) L2 ve zincirler arası özellikler

İyimser L2: TTF'yi "ikiye katlayın" - meydan okuma penceresinin L2-inclusion ve bitiminden önce.
ZK L2: Yayınlama süresini L1'e ve kanıtın üretim/doğrulama süresine bölün; Proverlerin hata toleransını dikkate alın.
Validium/DA dış kaynak: DA metrikleri gereklidir (verim/maliyet/başarısızlık), aksi takdirde karşılaştırma yanlıştır.
Çapraz zincir işlemleri: K/DA/challenge dikkate alınarak köprü senaryoları için TTF E2E okuyun (istochnik - tsel).

11) Anti-karşılaştırma kalıpları (kaçınılması gerekenler)

Bir zincirin "rekor zirvesini" diğerinin "ortalamasıyla" karşılaştırın.
Veri maliyetlerini ve komisyon volatilitesini göz ardı edin.
Sonlandırmayı göz ardı edin ("dahil etme'yi" sonlandırma'olarak karşılaştırın).
Metrikleri "sıcak'bir düğümde çekin ve soğuk bir düğüme aktarın.
Normalleştirme olmadan farklı işlem sınıflarını karıştırın.
İstemci sürümleri/yapılandırmaları yapmayın - tekrarlanabilirlik kaybolur.

12) Test konfigürasyonları ve parametreleri (sözde 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) Raporlama ve görselleştirme

Senaryoya göre özet tablosu: Etkili TPS, TTI/TTF p95, Fee p95, Maliyet/kB, Başarı %.
Radar grafiği (senaryo başına): Verim/Kesinlik/Maliyet/Kararlılık/Canlılık.
Zaman serisi: Ücret volatilitesi, DA gecikmesi, Reorg sivri uçları.
Maliyet × to-Serve ve TTF zincir-sınıf matrisi.

14) Süreçler ve roller

Benchmark Sahibi: metodoloji/araçlar, sürüm kontrolü.
Infra Sahibi: düğümler, istemciler, yapılandırmalar, bölgeler.
Veri/BI: toplama, doğrulama, SLO panoları.
Güvenlik/Uyumluluk: Gizliliğin kontrolü ve günlüklerin doğruluğu.
Yönetişim: sonuçları yayınlama, dizin ağırlıklarını değiştirme.

15) Playbook kıyaslama olayları

Yapılandırmaların/sürümlerin sürüklenmesi: seriyi hemen durdurun, anlık görüntü verin, doğru parametrelerle yeniden başlatın.
Ağ anomalileri (planlananların dışında): Pencereyi "kirlenmiş'olarak işaretleme, diziyi tekrarlama.
DA/prover hatası: Ayrı bir olay ortaya çıkar, DA/ZK alt serisini tekrarlayın.
Beklenmedik fiyat oynaklığı: medyan USD penceresini sabitleyin, bir aralık ekleyin.

16) Uygulama kontrol listesi

1. Senaryoları (TUP) ve özet dizin ağırlıklarını onaylayın.
2. Ana bilgisayar/istemci yapılandırmalarını, bölgelerini ve ağ koşullarını kaydedin.
3. Korelasyon ve zaman senkronizasyonu ile telemetri toplama uygulamak.
4. Ücret/DA/işlem sınıflarının normalleştirilmesini ayarlayın.
5. SLI/SLO ve pano düzenleri üzerinde anlaşın.
6. Bir pilot çalıştırma yapın, tekrarlanabilirliği doğrulayın, yükleri kalibre edin.
7. Yapılandırmaların, sürümlerin ve tarihlerin tam uygulamasıyla raporları yayınlayın.

17) Sözlük

TTI/TTF - açma/sonlandırma zamanı.
DA - Veri Kullanılabilirliği katmanı.
Sürekli/En Yüksek TPS - sürekli/en yüksek verim.
Canlılık - ağın blokları/partileri onaylama yeteneği.
Meydan Okuma Penceresi - iyimser toplamalarda bir meydan okuma penceresi.
State Growth - ağ durumunun boyutunda bir artış.
Donanım Ayarlı TPS - düğümün maliyetini dikkate alarak iş hacmi.

Alt satır: Zincir performansının doğru karşılaştırılması "kimin daha fazla TPS" yarışı değil, bir disiplindir: tekdüze senaryolar, maliyet ve verilerin dürüst bir şekilde normalleştirilmesi, kesinleştirme ve istikrarın muhasebeleştirilmesi, şeffaf yapılandırmalar ve tekrarlanabilir testler. Bu çerçeveyi takiben, ekosistem karşılaştırılabilir, karar verme ölçütleri alır - bir ürün için bir site seçmekten zincirler arası mimarileri planlamaya kadar.

Contact

Bizimle iletişime geçin

Her türlü soru veya destek için bize ulaşın.Size yardımcı olmaya her zaman hazırız!

Telegram
@Gamble_GC
Entegrasyona başla

Email — zorunlu. Telegram veya WhatsApp — isteğe bağlı.

Adınız zorunlu değil
Email zorunlu değil
Konu zorunlu değil
Mesaj zorunlu değil
Telegram zorunlu değil
@
Telegram belirtirseniz, Email’e ek olarak oradan da yanıt veririz.
WhatsApp zorunlu değil
Format: +ülke kodu ve numara (örneğin, +90XXXXXXXXX).

Butona tıklayarak veri işlemenize onay vermiş olursunuz.