서킷 성능 비교

(섹션: 생태계 및 네트워크)

1) 왜 그리고 우리가 비교하는 것

목표는 다음을 고려하여 다양한 체인 (L1, L2, 앱 체인, validium/rolup) 의 성능을 비교할 수있는 재현 가능하고 중립적 인 방법을 만드는 것입니다

속도 및 지연: 포함, 마무리, 변동성.
경제: 거래 비용 및 데이터, 수수료의 안정성.
안정성: 재조직, 샤워, 하중 감소.
데이터 가용성: DA 대역폭 및 바이트 비용.
운영 체제: 노드, 상태 크기, 고객 다각화에 대한 요구 사항.

결과는 특정 시나리오 (지불, 게임/마이크로 이벤트, 브리지, DA/출판물) 에 대한 체인/도메인을 선택할 수있는 통합 KPI입니다.

2) 지표 분류 (코어)

2. 1 처리량 및 대기 시간

지속적인 TPS/QPS

피크 TPS (오류/드롭이없는 짧은 피크)

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

TTF (Time-to-Finality) p50/p95/p99

활용% 차단

지연의 변형/지터 (λ, CV)

2. 2 품질과 지속 가능성

성공률 (tx/이벤트의%)

Reorg/Orphan 속도 (빈도 및 깊이)

라이브니스 SLO 히트

악화 유예 (실패가 아닌 제어 된 열화)

2. 3 경제와 DA

p50/p95/p99 요금 (기본 통화 및 USD)

kB 당 비용 (DA) -데이터 1kB의 게시 가격

Tx 당 비용- "거래 유형" 가격: 간단한 이체, 계약 통화, 큰 칼다 타

수수료 변동성 지수

2. 4 노드 및 상태

하드웨어 풋 프린트 (유효성 검사기/아카이브 노드 용 CPU/RAM/SSD/네트워크)

국가 성장

고객 다양성 지수

동기화 시간

2. 5 L2 특이성

배치 TPS (Sentenser에서), 배치 크기 (kB)

배치 시간 포함 (ZK )/챌린지 창 (낙관적)

DA 처리량은 DA 실패율을 나타냅니다

정산 대기 시간 (L2 → L1 최종)

3) 측정 절차 (중립 및 재현 가능)

1. 테스트 사용 프로필 (TUP):

TUP-Pay: 소액 송금 (N = 70% 단순, 30% 토큰).
TUP- 게임: 칼다 타 (최대 2-8kB) 의 짧은 이벤트.
TUP-DEX: 중간 가스 및 서지 계약.
TUP-DA: 대규모 출판물 (50-250 kB batchami).

2. 로드 레이어: 대상 SLO + 의 배경 60-80% 는 30-60 분마다 5-10 분 동안 120-160% 펄스입니다.

3. 지리 및 네트워크: 최소 3 개 영역, RTT 매트릭스, 지터/손실 주입 (0. 5–2%).

4. 클라이언트 다양 화: 회로 당 최소 2 개의 노드 클라이언트 (사용 가능한 경우) 동일한 버전.

5. 원격 측정 수집: 올바른 상관 관계 (추적 ID), 시간 동기화 (NTP/PTP), 고정 컨피그.

6. 마무리 창: 분쟁 K/창의 명시 적 설정; 회로 규칙을 고려하여 TTF를 읽으십시오.

7. 오류 의미론: 고장 분류 (가스/논스/한계/DA 파일/과부하), 성공률에서 "예상 된" 오류를 제외하거나 별도로 강조 표시.

4) 정규화 및 안티 바이어스

비용 정규화: USD

가스/무게 동등성: "원시 가스" 가 아닌 "작동 클래스" 에 의한 비교.

하드웨어 조정 TPS: 'TPS _ per _ $ = Sustained _ TPS/( Monthly _ Node _ Cost _ USD)'

공정한 DA 비교: 1kB 당 가격 및 p95 게시 지연.
변동성 Windows: "일회성 레코드" 대신 주간/월간 창, 중앙값 및 IQR.
감기 대 따뜻함: 캐시 예열; 안정화 후 측정.
MEV/Peak 커미션: "시장 이상" 을 제외하거나 별도의 지표를 강조하십시오.

5) 요약 KPI (총계)

• 처리량 (30%), 최종 (25%), 비용 (20%), 안정성 (15%), 가동/생활 (10%).
• 가중치 요소는 시나리오에 따라 설정됩니다 (예: TP 최종/비용 지불, TP 처리량/안정성/DA 게임).

효과적인 처리량 @ SLO-안정적인 TPS는 'TTF _ p95

1k Ops 당 서비스 비용-1000 클래스 운영을 처리하는 데 드는 총 비용 (DA/결제 포함).
최종 SLA Hit% - 대상 창에서 마무리 된 작업 비율.

6) 비교를위한 SLI/SLO

• 지불: 'TTF _ p95 7% ',' Fee _ p95 소 $0. 01`.
• 게임/이벤트: 'TTI _ p95 5% ',' DA _ p95 λ1 '.
• DA/Publishing: 'Cost _ per _ kB 0005 ',' Publishing _ p95
• L2 정착: 낙관적 인 'Settle _ p95 소 10m' (ZK )/" 챌린지 창 ".

7) 대시 보드 (참조 레이아웃)

Perf Lens (실시간/시간): TTI/TTF p50/p95/p99, 블록 활용, 성공률, 수수료 p95, 오류 분류법.
비용 및 DA: 비용/kB, 수수료 변동성, DA 처리량/대기 시간, отка) DA.
안정성: Reorg Rate, Liveness SLO Hit, Burn-rate 오류, 가동 중지 선고 (L2).
용량 계획: 지속 대 피크 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 점수

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: L2 포함 전과 챌린지 창이 끝나기 전에 "이중" TTF를 나타냅니다.
ZK L2: 출판 시간을 L1과 증거의 생성/검증 시간으로 나눕니다. 제안자의 내결함성을 고려하십시오.
Validium/DA 아웃소싱: DA 메트릭이 필요합니다 (처리량/비용/고장). 그렇지 않으면 비교가 잘못되었습니다.
교차 체인 작업: K/DA/챌린지를 고려하여 브리지 시나리오 (istochnik → tsel) 에 대한 TTF E2E를 읽으십시오.

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, 수수료 p95, 비용/kB, 성공%.
레이더 차트 (스크립트 당): 처리량/최종/비용/안정성/활력.
시계열: 수수료 변동성, DA 대기 시간, Reorg 스파이크.
비용 × 서브 및 TTF 체인 투 클래스 매트릭스.

14) 프로세스 및 역할

벤치 마크 소유자: 방법론/도구, 버전 제어.
Infra 소유자: 노드, 클라이언트, 구성 요소, 지역.
데이터/BI: 집계, 검증, SLO 대시 보드.
보안/준수: 개인 정보 보호 및 로그 정확성 제어.
거버넌스: 결과 게시, 색인 가중치 변경.

15) 플레이 북 벤치 마크 사건

컨피그/버전의 드리프트: 즉시 시리즈를 중지하고 스냅 샷을 커밋하며 올바른 매개 변수로 다시 시작하십시오.
네트워크 이상 (계획된 이상 외부): 창을 "오염 된" 것으로 표시하고 시리즈를 반복합니다.
DA/제안 실패: 별도의 사고를 해결하고 DA/ZK 하위 시리즈를 반복하십시오.
예상치 못한 가격 변동성: 중간 USD 창을 수정하고 범위를 연결하십시오.

16) 구현 점검표

1. 시나리오 승인 (TUP) 및 요약 색인 가중치.

2. 호스트/클라이언트 구성 요소, 지역 및 네트워크 조건을 기록하십시오

3. 상관 및 시간 동기화를 통한 원격 측정 수집을 구현하십시오.
4. 수수료/DA/운영 클래스의 정규화 설정.
5. SLI/SLO 및 대시 보드 레이아웃에 동의하십시오.
6. 파일럿 실행을 수행하고 재현성을 확인하고 하중을 교정하십시오.
7. 구성 요소, 버전 및 날짜의 전체 적용으로 보고서를 게시합니다.

17) 용어집

TTI/TTF-켜기/마무리 시간.
DA-데이터 가용성 계층.
Sustained/Peak TPS-지속/피크 처리량.
활력-블록/배치를 확인하는 네트워크의 기능.
챌린지 윈도-낙관적 인 롤업의 챌린지 창.
국가 성장-네트워크 상태의 크기 증가.
노드 비용을 고려한 하드웨어 조정 TPS-처리량.

결론: 체인 성능의 올바른 비교는 "더 많은 TPS" 경주가 아니라 균일 한 시나리오, 비용 및 데이터의 정직한 정규화, 마무리 및 안정성, 투명한 구성 및 재현 가능한 테스트와 같은 분야입니다. 이 프레임 워크에 따라 생태계는 제품 용 사이트 선택에서 체인 간 아키텍처 계획에 이르기까지 비슷한 의사 결정 지표를받습니다.