블록체인 : 하이퍼레저의 구성 요소와 아키텍쳐를 이해 : 트랜잭션 처리 흐름

하이퍼레저 패브릭 컴포넌트

기존의 블록체인 플랫폼과 유사 하면서도 패브릭만이 가지는 고유한 컴포넌트들은 무엇이 있는지 살펴보겠습니다. Asset, 즉 자산은 네트워크를 통해 교환되는 모든 가치를 의미합니다. 부동산 및 하드웨어에서 지적 재산권 까지 다양한 유형의 자산이 존재합니다.

하이퍼레저 패브릭은 체인코드 의 거래를 통해 자산을 수정할 수 있는 기능을 제공합니다. 자산은 키-값 쌍의 모음으로 표시되며, 자산의 상태가 변경되면 변경사항이 원장에 트랜잭션으로 기록됩니다. 체인 코드는 앞에서 잠깐 언급했던 대로 비즈니스 로직을 의미합니다.

자산을 정의하고 자산을 수정하기 위한 거래가 포함되어 있습니다. 블록체인에 저장된 키-값 쌍을 읽고 상태를 변경하기 위한 규칙을 시행합니다. 파라미터 및 시스템을 관리하는 특별한 체인코드인 시스템 체인 코드가 존재합니다. 원장은 패브릭의 모든 상태 전이에 대한 기록입니다.

체인코드 호출 결과 자산의 상태전이가 일어나면 원장은 모든 상태 전이를 기록하여 변조를 방지합니다. 하나의 채널 당 한 개의 원장이 존재하며, 이 채널은 전체 네트워크에서 공유되거나 특정 참여자 집합만포함하도록 사유화될 수 있습니다. 사유화를 위해서 특정 참여자만 을 위해 별도의 채널을 만들고 거래 및 분장을 분리합니다.

다음으로, 하이퍼레저 패브릭에는 deploy와 invoke 두 가지 타입의 트랜잭션 이 존재합니다. Deploy 트랜잭션은 새로운 체인코드를 생성하고 블록체인 네트워크에 배포하기 위한 트랜잭션입니다. Deploy Transaction이 성공적으로 실행 되면 체인코드가 블록체인 상에 설치되고 설치된 체인코드의 ID 를 돌려 보냅니다 (반환합니다).

Invoke 트랜잭션은 deploy 트랜잭션을 통해 배포된 체인 코드를 실행하는 트랜잭션입니다. 특정 체인코드와 해당 체인코드 의 특정 함수를 참조하며, 해당 함수의 실행이 성공하면 블록체인 내에 저장된 정보를 수정할 수 있는 결과를 반환합니다. 하이퍼레저 패브릭은 세 가지 타입 의 노드가 있습니다.

클라이언트 노드는 실제 트랜잭션을 호출하는 노드로, end user 입장에서 특정 체인 코드를 호출하고 싶을 때 요청하는 노드입니다. Peer는 트랜잭션을 커밋하고 상태 정보와 원장의 복사본을 유지하는 노드입니다. 이때, endorser 역할을 하는 endorsing peer는 client의 요청을 미리 검사하고, 트랜잭션을 미리 실행하는 역할을 합니다.

Orderer 노드는 ordering service를 위한 노드로, 선택된 합의 알고리즘에 따라 트랜잭션의 순서를 정합니다. vkvs(Versioned Key Value Store)를 통해 하이퍼 레저 패브릭의 전체 상태를 저장하고 관리합니다. 그리고 MSP(membership service provider)는 허가된 블록체인을 위해 하이퍼레저 패브릭에 접속하려는 참가자의 신원을 관리하는 역할을 합니다.

 

블록체인 : 하이퍼레저의 구성 요소와 아키텍쳐를 이해 : 트랜잭션 처리 흐름 1

 

앞서 소개한 컴포넌트들을 포함하는 하이퍼레저 패브릭의 전체 구조는 그림과 같습니다. 시스템에 참여하는 멤버들의 신 원을 확인하고, 접근 권한을 관리하기 위한 msp가 있습니다. 클라이언트 노드는 사용자를 대신 해 거래를 생성하고, 체인 코드의 실행을 호출하는 노드입니다.

클라이언트 노드는 거래를 생성하여 보증 피어 노드에게 제출함으로써 거래 보증을 요청하고, 거래 보증에 대한 응답을 수집합니다. 보증 피어(Endorser)는 클라이언트의 보증 요청에 따라 해당 체인코드를 실행하고 결과를 보증하는 역할을 수행합니다.

Endorser로부터 거래 보증 응답을 수집한 클라이언트는 거래 제안 을 생성하여 순서화 서비스 노드(Orderer)에게 전달합니다. 순서화 서비스 노드는 합의 프로토콜 을 통해 보증된 거래들을 순서화 시켜 피어 노드들에게 전달하는 역할을 합니다.

순서화 서비스 노드로부터 블록 형태로 거래와 상태 갱신 정보를 수신 받은 committer 피어는 해당 거래를 확정합니다. 거래 정보를 저장하는 원장과 거래 실행 결과에 따른 상태정보를 저장하는 상태 저장소를 블록체인 내에 유지하는 역할을 합니다.

블록에 저장된 체인코드를 실행하면 실행 결과에 따라 변경되는 상태 정보들을 블록체인 내에 저장해야 합니다.

 

 

 

World State

하이퍼레저 패브릭에서 상태 정보를 저장하는 저장소를 world state라고 합니다. 이는 이더리움이 모든 상태 정보를 머클 페트리샤 트리를 이용해 관리하는 것과 유사합니다. 하지만 이더리움은 저장소에 account 정보를 저장하는 반면, 하이퍼레저 패브릭은 어떤 형태의 변수에 관한 정보라도 저장할 수 있습니다.

이렇게 여러 정보를 저장하기 위해 저장하고자 하는 정보의 이름인 key와 key에 대한 결과인 value 쌍으로 관리하며, 거래를 실행할 때마다 key에 대한 value가 바뀔 수 있기 때문에 이를 버전을 통해 관리하여 모든 상태 전이를 블록체인 내에 유지합니다.

값이 갱신될 때마다 새로운 버전 번호(version number)가 부여되어 기존의 키-값과 상태를 구분합니다.

 

 

 

Membership Service Provider (MSP)

블록체인 : 하이퍼레저의 구성 요소와 아키텍쳐를 이해 : 트랜잭션 처리 흐름 2

 

다음으로 네트워크 참여자의 신 원을 확인하는 MSP에 대해 알아보겠습니다. MSP는 CA를 활용하여 참여자의 신 원을 확인합니다. 하이퍼레저 패브릭에는 세 가지 타입의 공인인증기관(CA)이 존재합니다. 첫 번째로 ECA는 네트워크에 참여 하려는 참여자가 하이퍼레저 패브릭 에 등록된 참여자가 맞는지 증명 하기 위한 인증서를 발행하는 기관입니다. 그런데 만약 허가된 사용자가 블록 체인 네트워크로 거래를 브로드캐스팅 할 때 동일한 인증서를 사용한다면, 해당 거래를 모니터링하고 있는 누군가에 의해 신원이 노출될 수 있습니다.

따라서 이를 해결하기 위해 tca는 거래를 실행할 때마다 그 거래를 위한 인증서를 별도로 발행해줍니다. 네트워크에 신원을 등록하기 위한 인증서는 참여자 당 하나를 가지지만, 거래를 위한 인증서는 여러개가 존재합니다. 거래를 전송할 때마다 다른 인증서를 사용합니다.

이때 등록을 위한 인증서와 거래 를 위한 인증서는 서로 상관관계를 추론할 수 없게 생성됩니다. 따라서 거래 인증서를 이용해 거래를 전송하더라도, 해당 거래가 누구 에 의해 전송되었는지 아무도 추론할 수 없습니다.

 

블록체인 : 하이퍼레저의 구성 요소와 아키텍쳐를 이해 : 트랜잭션 처리 흐름 3

 

TLS_CA는 transport layer secure protocol에서 사용되는 인증서를 발급하는 기관 입니다. 인증기관에 대해 정리해보면, eca 는 블록체인에 접근하고자 하는 참가자의 신원을 검증한 후에 등록 인증서를 발급하는 역할을 수행 합니다. 등록된 참가자를 확인하는 데 필요한 공개키와 개인키 쌍을 생성하고 인증서에 포함합니다.

이때 참가자 등록을 위한 신원 확인 과정을 RA에 위임할 수도 있습니다. TCA는 ECA에 의해 발급된 등록 인증서 에 근거하여 신원이 확인된 참가자 에게 거래 인증서(TCert - Transaction Certificate)를 발급하는 역할을 합니다. 등록 인증서(ECert)를 기반으로 충분한 수의 거래 인증서(TCert)를 발급하며 등록 인증서를 유추할 수 있는 어떤 정보도 포함하지 않음으로써 거래비 연결성을 보장합니다.

이를 통해 참가자의 신원이 노출 되지 않을 수 있습니다. 마지막으로 TLS_CA는 신원이 확인 된 참가자를 대상으로 보안 통신 프로토콜인 TLS 프로토콜이 사용할 수 있는 인증서를 발급합니다. 아래의 다이어그램은 클라이언트 를 위한 인증서를 발급하는 과정을 보여주고 있습니다.

등록 인증 기관(ECA)에 참여자 인증서를 받으면, 해당 인증서를 가지고 내가 필요한 만큼 TCA를 발급할 수 있습니다. EC를 발급받은 클라이언트가 거래 를 전송하고자 하면, Tcert를 검색합니다. 거래 인증서가 없다면 TCA에 원하는 만큼의 인증서를 요청합니다.

TCA에 의해 거래 인증서를 전달받으면 거래를 배포하고 전송할 수 있습니다. 이때 TCA는 참여자의 신원 정보는 노출하지 않으면서, ECA의 공개키와 연계가 되도록 키를 생성합니다.

 

 

 

거래 처리 방식 변화

하이퍼레저 패브릭은 트랜잭션을 처리하기 위해 execute-order-validate 의 처리방식을 가지는 새로운 구조의 아키텍처를 도입했습니다. 기존 블록체인 시스템의 처리 방식 인 order-execute에 대해 먼저 설명 드린 후, 새롭게 도입된 아키텍처의 트랜잭션 처리 과정에 대해 설명 드리겠습니다.

이더리움과 같은 퍼블릭 비 허가형 블록체인 시스템부터 허가형 시스템에 이르기까지, 기존의 블록체인 시스템은 order-execute의 단계 로 스마트 컨트랙트를 처리합니다. 노드들이 거래를 생성하면, 채굴 자들은 새롭게 생성된 거래를 검증하고 블록 내에 그 거래를 저장하는 순서를 미리 정해 주변 노드들에게 전파합니다.

그 블록을 수신하는 모든 채굴자나 풀 노드들은 블록 내부의 거래들을 순서에 따라 실행하면서 거래를 검증합니다. 이처럼 블록에 거래가 저장되는 순서가 먼저 결정되고, 그다음에 거래가 실행되는 방식이 기존 블록 체인 시스템에서 실행되는 트랜잭션 처리 방식입니다.

이 경우, 모든 블록에서 거래가 실행되는 순서가 동일하며 모든 노드에서 해당 거래를 순차적으로 실행하기 때문에 성능을 저하시키는 요인 이 됩니다. order-execute 순서로 거래를 처리하는 경우 해당 시스템은 deterministic한 성질을 가져야 합니다. 그렇지 않으면, 순서를 어떻게 정하 냐에 따라 서로 다른 결과를 도출하여 합의에 도달할 수 없기 때문입니다.

non-deterministic 문제를 해결하기 위해 도입된 것이 execute-order-validate 아키텍처 입니다. 패브릭은 non-deterministic한 성격을 띄기 때문에 블록체인의 일관성 을 유지하기 위해 다음과 같은 매커니즘 을 개발했습니다. 이 방식에서는 먼저, endorsing peer 들이 새롭게 생성된 거래를 실행 합니다.

이 단계에서는 실행된 결과가 아직 블록체인에 저장되지 않은 상태입니다. 다음으로, 이 실행 결과가 포함된 거래들을 모두 Orderer peer들에게 전달하여, 모든 블록이 동일한 순서 의 트랜잭션을 가지도록 순서를 매깁니다. 이때 사전에 정의한 합의 알고리즘 에 따라 순서에 대한 합의를 이끌어냅니다.

이 순서가 정해지면, 블록체인을 유지하는 peer들은 실행 결과가 올바른지 검증합니다. 검증이 완료되면 해당 거래는 확정 되어 블록체인 내에 기록됩니다. 이러한 아키텍처는 모든 노드가 거래를 모두 실행할 필요 없이, 특정 노드들만 거래를 병렬적으로 실행하기 때문에, 전체 블록체인 네트워크의 성능을 높일 수 있습니다.

 

블록체인 : 하이퍼레저의 구성 요소와 아키텍쳐를 이해 : 트랜잭션 처리 흐름 4

 

그림을 통해 하이퍼레저 패브릭 의 거래 처리 순서를 요약해보겠습니다. 체인코드를 위한 트랜잭션을 실행하기 위해 정해진 endorser에게 실행을 의뢰합니다. Endorser는 해당 거래를 실행한 후, 결과를 다시 클라이언트에게 돌려줍니다. 이때, 거래를 실행하는 보증 피어 는 하나가 될 수도 있고 여러 개가 될 수도 있습니다.

어떤 보증 피어를 선택할 지는 체인코드 내에 명시하며, 동일한 거래 를 모든 보증 피어에서 실행하지는 않고 여러 개의 거래들이 여러 보증 피어들에서 동시에 실행됩니다. 모든 실행 결과는 거래 정보와 함께 Orderer에게 전송됩니다.

Orderer는 모든 거래들을 블록에 어느 순서로 저장할지 합의합니다. 이러한 매커니즘을 순서화한다, ordering한다고 합니다. 순서에 대한 합의가 끝나면 블록 체인을 유지하는 모든 피어들에게 해당 거래를 보내 endorser가 실행한 결과가 맞는지 검증하도록 합니다. 검증 과정에 문제가 없다면, 거래 를 확정하고 각 피어가 유지하는 원장에 기록합니다. 

 

 

 

참조

http://www.kmooc.kr/courses/course-v1:POSTECHk+CSED490U1+2021_T1/about 

블록체인 입문