블록 타임

권장 블록 타임

다음은 일반적인 사용 사례에 따라 블록 타임을 선택하기 위한 일반적인 가이드라인입니다. 참고로, Arbitrum Orbit 체인은 일반적으로 250ms 블록 타임을 사용하는 반면, OP Stack 체인은 일반적으로 2초를 사용합니다.

블록 타임	효과 및 트레이드오프	최적 사용 사례	고려사항
250ms – 500ms	거의 즉각적인 확인, 높은 네트워크 요구사항	대부분의 사용 사례	고성능 하드웨어와 낮은 지연 시간의 네트워크 연결이 필요합니다. 체인 재구성을 모니터링하세요.
500ms – 1s	균형 잡힌 응답성과 안정성	NFT 마켓플레이스, 소셜 플랫폼	속도와 신뢰성의 이상적인 균형. 블록 타임이 사용자 기대치를 충족하는지 철저히 테스트하세요.
1s – 2s	낮은 노드 요구사항, 합리적인 확인 속도	거버넌스, 데이터 아카이빙	덜 강력한 하드웨어에서도 잘 작동합니다. 실시간 요구사항이 없는 비용 중심 배포에 완벽합니다. (Arbitrum 생태계 외부의 많은 롤업에서 일반적인 블록 타임)

블록 타임을 선택할 때 다음 사항을 고려하세요:

애플리케이션 유형: 귀하의 dApp이 빠른 트랜잭션 확인이 필요한지(게임 및 거래와 같은) 또는 더 긴 지연을 처리할 수 있는지(거버넌스 및 기록 보관과 같은)?
트랜잭션 볼륨: 높은 처리량의 dApp은 빠른 처리를 위해 짧은 블록 타임이 더 적합하며, 낮은 볼륨의 앱은 더 긴 간격으로도 잘 작동할 수 있습니다.
노드 인프라: 귀하의 검증자는 선택한 블록 타임, 특히 최소 250ms에서 처리할 수 있는 적절한 하드웨어와 네트워크 대역폭이 필요합니다.
사용자 경험: 더 빠른 블록 타임은 더 반응이 빠른 dApp을 만들지만, 지나치게 짧은 간격은 재구성이나 네트워크 혼잡을 일으킬 수 있습니다.

보수적으로 시작하기: 확실하지 않다면 1초 블록 타임으로 시작하세요—대부분의 dApp에 좋은 균형을 제공합니다. 성능 테스트를 기반으로 미세 조정할 수 있습니다.
철저히 테스트하기: 선택한 블록 타임이 트랜잭션 지연 시간, 노드 성능 및 사용자 경험에 미치는 영향을 평가하기 위해 먼저 테스트넷에 앱체인을 배포하세요.
노드 상태 모니터링: 짧은 블록 타임(특히 250ms)은 강력한 인프라를 요구합니다. 검증자가 최적으로 작동하도록 CPU, 메모리 및 네트워크 사용량을 추적하세요.
최종성 고려하기: 블록 타임이 확인 속도에 영향을 미치지만, 트랜잭션 최종성은 합의 메커니즘에 따라 달라집니다. 자세한 내용은 Syndicate의 합의 문서를 참조하세요.
확장성 계획하기: dApp의 트랜잭션 볼륨은 시간이 지남에 따라 증가할 가능성이 높습니다. 미래 수요를 처리할 수 있는 블록 타임을 선택하거나, 체인 구성을 적절히 최적화할 준비를 하세요.