[논문] Performance Evaluation for Geographically Distributed Blockchain-based Services in a Cloud Computing Environment
1 평가 방법론
(1) DEVS-형식주의 기반 평가 프레임워크
- DEVS-형식주의
: 복잡한 시스템을 구성 요소 별로 나누어 각각의 모델을 만든 후, 이를 합쳐서 전체 시스템을 표현
: 시스템을 계층적이고 모듈화된 형식으로 표현하기 쉽게 함
- EF(Experimental Framework)
: 대상 시스템의 구조 및 동작을 평가하는 측면에서 시뮬레이션 시나리오를 공식화
: 요청 생성기와 성능 평가기 모듈로 구성
: 생성기는 실험 코디네이터 모듈에 서비스를 요청하는 알고리즘을 포함
: 실험 코디네이터는 클라이언트 프로세스를 인스턴스화하여 성능 평가 대상에 요청을 보냄
(2) GDCPEA 및 GDC 로그 서버
- GDCPE(Geographically Distributed Cloud Performance Evaluation) 성능지수 측정
- 지역별 GDC(Geographically Distributed Cloud) 로그 서버 → GDCPE 앰버서더를 사용하여 측정된 시간을 수집
- 클라우 드 기반 상황에서 성능 평가 고려사항
: 각 지역의 고유한 시간대
: 각 지역의 가상머신 지분 비율 편차
: 성능 평가에 영향을 미칠 수 있는 특정 규정
: 네트워크 트래픽
- GDCPE 앰버서더와 GDC 로그 서버는 다른 시간대의 다른 지역에서 서비스를 제공
- 특정 지 역의 측정값이 동일한 지역의 GDC 로그 서버에 저장
- 특정 지역에 대한 특정 규정이 있는 경우 대사 소 프트웨어 구성 요소와 GDC 로그 서버를 구성하여 조정
- 로그 데이터 전송으로 인해 발생하는 네트워크 트래픽을 줄일 수 있음
(3) 시나리오 기반 구성 가능 설계, 블록체인 성능을 위한 클라이언트 평가
- 성능 평가를 위해 서비스와 클라이언트를 모두 설계, 구현
- 콘텐츠 전송 서비스는 소유자와 제공자에게 요금을 지불하는 콘텐츠 구매 기능
- 모든 거래는 이더리움 블록체인 인프라에서 수행
- 사용자가 콘텐츠 구매시 마다 콘텐츠 호스팅 포인트에 새로운 포인트 추가
- 클라이언트 서비스는 도착간 시간으로 평가되는 시나리오에 따라 요청 ??
- 랜덤변수의 평균값은 TimeScale 개념 적용해 서버 부하 줄임
- 클라이언트, 웹 서버, 데이터베이스, 블록체인 및 GDC 로그 서버 간의 상호 작용을 보여주는 사진
- 클라이언트: startWatching 함수로 서비스 요청 / stopWatching 함수를 호출하여 감시를 중지
- 웹 서버: 데이터베이스(loadDB 함수) 및 블록체인 구성요소와 상호작용
: checkBlance 함수 | 상 태 쿼리를 처리하여 Ethereum의 State Tri에서 잔액 정보 가져옴
: PurchaseContent 함수 | 스마트 계약을 실행하고 결과적으로 트랜잭 션이 생성
: addContentPoint | 특정 콘텐츠에 포인트를 추가하기 위해 또 다른 스마트 계약을 실행
- Algorithm1 → PurchaseContent 및 addContentPoint의 Smart Contract
2 GETH 노드의 성능 평가
- 블록체인 네트워크 성능평가를 위해 한국과 오하이오 두 개의 서로 다른 AWS 지역에 3-5개 배포
- 각 지역은 최소 하나의 Geth 노드 호스팅, 다른 지역의 Geth 노드와 통신
- 웹 서버, node.js, mysql 데이터베이스 및 Geth 노드와 20GB EBS 볼륨 인스턴스가 각 VM에 마운트
(1) GECPE
- 트랜잭션 생성
- 스마트 계약 변수와 계정 상태를 업데이트 → 트랜잭션 발생
- 유효한 트랜잭션 구조를 생성하기 위해 사용자의 공개 키에서 파생된 값인 사용자 계정 주소가 Geth 클라이언트에 제출
- 트랜잭션 헤더에 현재 시간을 기록하고 제출된 공개 키와 쌍을 이루는 개인 키로 트랜잭션에 서명
- 트랜잭션에 적절한 수수료가 포함된 것으로 확인되면 해당 마이닝이 완료될 때까지 보류 중인 트랜잭션으로 트랜잭션 풀에 대기
(2) SmartContract
- 잔고확인
- 블록체인을 제대로 운영하기 위해서는 잔고 확인이 자주 이루어져야함
- Ethereum의 계정 잔액은 블록의 가장 최근 상태를 반영
- 가장 최근의 블록 헤더는 블록 번호를 사용하여 데이터베이스에서 검색
- 잔액을 얻기 위해 RLP로 인코딩된 헤더를 포함, State Trie의 루트 해시 사용
- RLP로 인코딩된 가장 최근의 블록 헤더는 블록 번호를 사용하여 데이터베이스에서 검색 가능
- 균형을 얻기 위해 헤더 정보에 있는 State Trie의 루트 해시가 사용 → State Trie에서 잔액이 포함된 계 정의 상태 개체를 조회
(3) GDCPE ambassador
- 트랜잭션 커밋
- 커밋 트랜잭션은 블록 마이닝의 하위 작업 → nonce 값을 조회하기 전에 커밋이 수행
- 스마트 컨트랙트를 실행하는 트랜잭션 커밋에 소요되는 시간을 기록하 고 그 결과를 State Trie에 반영
- 커밋 트랜잭션은 각 트랜잭션에 할당된 새 EVM 컨텍스트에서 실행
- Geth 노드가 트랜잭션 메시지 반영에 성공하면 소모된 가스 및 EVM 실행 결과가 상태에 반영
- 커밋하는 트랜잭션은 상태 Trie를 업데이트하고 루트 해시 값을 업데이트 → 모든 트랜잭션에 대해 수행
(4) Mining Block
- 블록 채굴
- 새로운 블록을 채굴하고 합의 엔진에 따라 블록을 봉인하는 루프를 지속
- PoW(Proof-of-Work) 합의 알 고리즘의 일종인 ethash를 사용
- Keccak-256 해시를 생성하기 위해 nonce를 조회
- nonce 값 계산을 반복하여 PoW 값이 발견되면 마이닝 작업은 nonce가 포함된 블록 반환
(5) Writing Block
- 마이닝 노드에 의해 봉인 → 피어 노드에 의해 검증 → 디스크에 기록
- 전체 난이도, 영수증, 프리이미지는 키-값 쌍으로 배치 버퍼에 삽입
- 배치 버퍼 내용은 디스크의 leveldb에 직렬로 저장
- 메타데이터는 먼저 배치 버퍼에 공급되고 디스크에 순차적으로 저장
(6) Propagationg Block
- 이더리움 네트 워크에서 블록 전파는 DEVp2p 스택에서 수행
- 보안 통신을 위해 TCP 기반 RLPx 프로토콜은 사전 공유 암호화 체계를 사용하여 활용
- 메시 지 유형은 ETH 유선 프로토콜 버전에 따라 결정
- Geth 버전 eth/66의 ETH Wire Protocol
(7) Verifying Block
- 블록 검증 블록
- 블록 검증은 마이닝 블록 절차와 같은 중요한 절차
- 성능 평가 관점에서 이 절차는 마이닝 블록과 동일한 중요성으로 분석되어야 함
- 시간을 측정하기 위해 GDCPE Ambassador를 배치
- 헤더: 난이도, gasLimit 및 PoW 값을 검토
- 바디: 계산된 해시 값과 해당 해시 값을 비교