KEEP!T Column: 하이퍼레저 패브릭(Hyperledger Fabric)의 거래(트랜잭션) 흐름

안녕하세요. 킵잇입니다.

하이퍼레저 패브릭의 용어 몇 개와 하이퍼레저 패브릭 공식 문서에 기반하여 표준적인 거래 흐름을 설명드리고자 합니다.

월드스테이트(World State) : 하이퍼레저 패브릭의 용어이며 모든 원장의 '현재 상태'를 의미합니다. 패브릭에서는 원장에 모든 데이터를 넣지 않으며 거래내역만을 기록합니다. 실제 데이터는 월드스테이트라는 일종의 데이터베이스에 저장합니다. 블록체인은 모든 원장들의 기록을 의미합니다. 일반적으로 원장의 현재 값이 필요한데, 항상 쉽게 이용할 수 있어 매우 유용한 부분입니다. 장부 상태의 현재 값을 얻기 위해서 '전체 블록체인'을 뒤질 필요가 없습니다. 단지 월드스테이트만 있다면 바로 현재 값을 얻을 수 있습니다.

체인코드(Chaincode) : 이더리움에서의 스마트 계약과 같은 의미입니다. 사용자가 매번 직접 조작하지 않아도 미리 작성된 코드에 따라 원장의 내용을 바꾸는 기능을 합니다. 더불어 정보 자체에 대한 접근을 권한에 따라 일정정도 차단하는 기능(Encapsulation)도 가지고 있습니다.

신원(Identity) : 디지털 신원에는 패브릭에서 사용 권한을 결정하는데 몇개의 추가 속성이 있습니다. 신원과 연관된 속성의 결합체에 특별한 이름인 주체(Principal)가 주어집니다. 주체는 특정 신원에 대한 광범위한 속성을 포함할 수 있기에 좀 더 유연합니다.

멤버십 서비스 공급자(Membership Service Provider) : 당연히 신원을 확인이 가능하려면 신뢰할 수 있는 기관이 있어야겠지요. 우리가 가지고 있는 주민등록증의 경우에도 발급 기관이 적혀있어 신뢰성을 담보하는 것인데요. 하이퍼레저 패브릭에서는 멤버십 서비스 공급자(MSP)가 그 역할을 합니다. 피어의 구성 요소로써, 클라이언트로부터 들어오는 트랜잭션 요청을 확인하고 트랜잭션 결과에 서명(보증)할 수 있습니다.

트랜잭션 흐름

표준적인 자산 거래의 트랜잭션 매커니즘입니다.

채소인 무를 사고 파는 두 명의 클라이언트 A와 클라이언트 B가 등장합니다.

가정

채널이 설정되어 실행 중인 것으로 가정합니다. 애플리케이션 사용자는 조직의 CA(인증기관, Certificate Authority)에 등록하고 네트워크 인증에 필요한 필수 암호화 자료를 받습니다.

체인코드(무 시장의 초기 상태를 나타내는 키-값쌍 포함)가 피어에 설치되고 채널에 인스턴스화 됩니다. 체인코드에는 트랜잭션 명령어 세트와 합의된 무 가격을 정의하는 논리 구조가 있습니다. 피어 A와 피어 B가 모든 거래를 보증해야 한다는 것을 명시해 놓은 체인코드에 대한 보증 정책(Endorsement policy)도 마련되어 있습니다.

1. 클라이언트 A가 트랜잭션을 시작합니다.

무슨 일이지? - 클라이언트 A가 무 구입 요청(Request)을 보냅니다. 요청은 클라이언트 A와 클라이언트 B를 대표하는 피어 A와 피어 B를 대상으로 합니다. 보증 정책(Endorsement Policy)에 따르면 두 피어가 모든 트랜잭션을 보증해야 하므로 이 요청은 피어 A와 피어 B에게 갑니다.

다음으로 트랜잭션 제안(Proposal)이 작성됩니다. 노드, 자바, 파이썬을 활용하는 애플리케이션은 트랜잭션 제안을 생성하는 사용 가능한 API들 중 하나를 활용합니다.

제안은 원장에 데이터를 읽거나 쓸 수 있는(자산에 대한 새 키-값쌍을 작성하는) 체인코드 기능을 호출해달라는 요청입니다.

2. 보증 피어들이 서명을 확인하고 트랜잭션을 실행합니다.

보증 피어들은 몇가지를 확인합니다.
(1) 트랜잭션 제안이 잘 구성되었는지
(2) 이전에 제출되지 않은 것(리플레이 어택 방지)[https://en.wikipedia.org/wiki/Replay_attack]
(3) 서명이 유효한지(MSP를 사용)
(4) 제출자 (클라이언트 A)가 당 채널에서 제안된 연산을수행할 수 있도록 적절하게 승인되었는지 여부

보증 피어들은 호출된 체인코드의 기능에 대한 아규먼트로 트랜잭션 제안을 입력 받습니다. 그리고 현재 상태 데이터베이스에 대해 체인코드를 실행하고 응답된 값, 읽기 세트, 쓰기 세트를 포함하는 트랜잭션 결과를 생성합니다.

이 부분에서는 원장의 업데이트가 이루어지지 않습니다.

이러한 값 세트들은 보증 피어의 서명과 함께, 어플리케이션의 페이로드를 분석하는 '제안 응답'으로 반환됩니다.

3. 제안 응답들을 점검합니다.

어플리케이션은 보증 피어 서명을 확인하고 제안 응답들을 대조하여 제안 응답이 동일한지를 확인합니다.

체인코드가 원장만을 쿼리한 경우에, 애플리케이션은 쿼리 응답을 검사하고 '오더링 서비스'에 트랜잭션을 보내지 않습니다.

클라이언트 애플리케이션이 원장을 업데이트하기 위해 '오더링 서비스'에 트랜잭션을 제출하려는 경우, 애플리케이션은 지정된 보증 정책이 충족되었는지(즉 피어 A와 피어 B가 모두 보증했는가)를 결정합니다. 이 아키텍처는 애플리케이션이 응답을 검사하지 않거나 미보증된 트랜잭션을 선택하더라도, 보증 정책은 피어들에 의해 수행되고 커밋 확인 단계에서 각각의 피어에서 따로 검증됩니다.

4. 클라이언트는 보증을 트랜잭션으로 조합합니다.

애플리케이션은 '오더링 서비스'에 대한 트랜잭션 메시지 내의 트랜잭션 제안과 응답을 '브로드캐스트'합니다.

트랜잭션에는 '읽기/쓰기 세트', 보증 피어의 서명, 채널 ID가 포함됩니다.

'오더링 서비스'는 트랜잭션 수행을 위해 전체 내용을 검사할 필요가 없고, 네트워크의 모든 채널로부터 트랜잭션을 받고, 채널별로 시간순으로 정렬하여 채널당 트랜잭션 블록을 생성합니다. SOLO와 Kafka 방식의 두 가지 합의 알고리즘이 있는데요, SOLO의 경우는 테스트용으로만 사용할 것을 권장합니다.