devops

Quorum Blockchain Transaction 지연시간 테스트 (Latency Test) 본문

DevOps/Chain

Quorum Blockchain Transaction 지연시간 테스트 (Latency Test)

vata500 2023. 2. 22. 21:53
반응형

Latency

블록체인의 확장성을 평가할 때 가장 많이 언급되는 TPS(Transaction per Seconds)는 말 그대로 1초에 몇 개의 트랜잭션을 처리하는 지를 확인하는 지표다. 하지만 단순히 TPS로만 평가하기엔 부족하다. 전송된 트랜잭션이 포함된 블록이 생성되어야, 실제 트랜잭션이 처리되었다고 판단할 수 있기 때문이다.

유저의 액션이 완결성 있게 실행되기까지 걸리는 시간을 블록이 생성된 시간으로 평가하기 위해서 Latency를 체크해야 한다. Latency는 처리량보다 지연시간을 기준으로 체인의 확장성을 평가하는 주요 지표라고 볼 수 있다.

Quorum Blockchain

쿼럼은 JP모건에서 개발하고 현재 Consensys에서 인수하여 지속적으로 디벨롭 중인 Private Blockchain이다. 크게 3가지의 합의알고리즘을 지원하고 있다. 엔터프라이즈 용으로 많이 사용하기 때문에 높은 확장성을 보이지만, 지정된 노드만이 Validator로 참여할 수 있기 때문에 아주 낮은 수준의 탈중앙화로 구현되었다.

Consensys에서는 QBFT가 Consensys에서 엔터프라이즈 용으로 가장 완성도가 높은 합의 알고리즘이며 IBFT는 보안적인 부분에서 한 단계 아래의 알고리즘이라고 하며, RAFT는 개발/테스트 용도로 사용하는 것을 권장하고 있다.

이 세 합의 알고리즘의 Latency를 확인해보았다.

Latency Test

 ...
    const start = new Date().getTime()
    data.startTime = start

    await web3.eth
    .sendSignedTransaction(EncodedTx) 
    .then(function(receipt){
      PrevNonce = latestNonce
      data.txhash = receipt.transactionHash
      const end = new Date().getTime()
      data.endTime = end
      data.latency = end-start
     })
      
  ...
주요 코드 부분을 시간 순서도 설명하면,
 
  1. getTime을 통해서 현재 시간을 ms단위의 숫자로 받는다.
  2. sendSignedTransaction()을 통해서 16진수로 인코딩된 서명된 트랜잭션을 전송한다.
  3. 전송된 트랜잭션이 포함된 블록이 생성되면 응답받는 receipt를 기준으로 getTime을 실행한다
  4. 1) 와 3)의 차이만큼을 Latency로 선언한다.
 
ms \ Consensus QBFT IBFT RAFT
Latency 1
2040
5042
16
Latency 2
1046
3032
21
Latency 3
2046
4038
21
Latency 4
3037
7041
27
Latency 5
1040
4036
20
평균
1841
4637
21

테스트 결과, QBFT는 1.841초, IBFT는 4.637초, RAFT는 0.021초라는 평균 지연시간을 확인할 수 있었다.

물론 QBFT와 IBFT는 blockperiod(블록 생성시간, s), RAFT는 raftblocktime(블록 생성시간, ms) 값에 따라서 지연시간의 차이가 있을 수 있으나, 모두 최소값으로 설정했다는 점을 참고하길 바란다.

  QBFT IBFT RAFT
Instance type c5.xlarge(4 vCPU, 8GiB Memory) c5.xlarge(4 vCPU, 8GiB Memory) c5.xlarge(4 vCPU, 8GiB Memory)
The number of validator 7 7 3
blocktime 1 second 1 second 1 millisecond

AWS을 활용했고, 체인 퍼포먼스에 최적화된 스펙은 아니다. 그래서 스케일업으로 지연시간과 TPS의 성능도 조금 더 개선될 수 있다고 생각한다.

Raft 테스트 결과

실제 테스트에서 네트워크 상태 체크를 위한 간단한 쿼리를 보내 응답받는 시간을 체크하는 것도 중요할 듯하다.

반응형
Comments