[교육 및 세미나] 박승철의 블록체인 강의: 2강 Hyperledger Fabric의 구조

이 글은 '박승철블록체인과하이퍼레저패브릭' 강의를 듣고 개인적으로 정리한 내용입니다.

동영상 강의 : https://www.youtube.com/watch?v=rrQp-ncNFm4

박승철의 블록체인 강의: 2강 Hyperledger Fabric의 구조

 블록체인 구조

하이퍼레저 패브릭의 구조는 이더리움과 상당히 유사.

구성

레저(ledger) + 전체 상태(world state)

• 계약을 실행하는 프로그램 코드(체인코드)들이 블록에 들어있음
• 체인코드를 실행한 결과가 전체 상태(world state)에 저장됨 -> 결과에 대한 상태 정보를 저장
• 전체 상태(world state)에서는 키-값에 대한 버전을 관리함
• 레저(ledger)에는 거래 정보만 저장

전체 상태(world state)

• 거래 실행 결과에 따라 변경되는 블록체인의 상태 변화 정보를 저장
• 버전형 키-값 저장소(vKVS-versioned Key-Value Store) 형태로 모델링
• 키(key) : 체인코드(chaincode)가 사용하는 정보 이름
• 값(value) : 이름에 대응되는 정보
• 버전(version)은 특정 키와 값의 쌍의 상태를 번호(number)로 표시
• 값이 갱신될 때마다 새로운 버전 번호(version number)가 부여되어 기존의 키-값의 쌍의 상태 구분
• 전체 상태 : 블록체인의 모든 거래가 접근하는 키 집합에 대한 현재의 값과 버전 정보 집합

거래 처리 구조

거래 처리 방식 비교

기존 블록체인 시스템 : ORDERER -> EXECUTE

하이퍼레저 패브릭 : EXECUTE -> ORDER -> VALIDATE&COMMIT

• 실행을 먼저 해서 실행 결과가 포함된 거래를 포스팅
• 동일한 순서대로 저장될 수 있도록 ORDERING 작업
• 순서가 정해지면 블록체인을 유지하려고 하는 피어들이 실행 결과를 검증
• 검증에 문제가 없으면 블록체인에 저장
• 하이퍼레저 패브릭은 지정된 피어(Endorsing Peer)에만 실행을 의뢰

기존의 블록체인 시스템

• 대부분 발생한 거래들을 합의 알고리즘을 통해 순서화시킨 다음 피어(풀 노드)들에게 전달
• 블록체인을 유지하는 피어에 의해 독립적으로 처리
• 거래들은 순서가 매겨진 대로 순차적으로 실행
• 결과가 동일하게 유지되도록 하기 위해 스마트 계약 프로그램은 반드시 결정적으로(deterministically) 작성

하이퍼레저 패브릭의 거래 처리 순서

• Endorser에게만 거래를 의뢰
• Endorser는 여러 개가 될 수 있음(여러 개의 거래를 나눠서 처리하기 위해)
• Orderer에서 순서를 지정
• 블록체인을 유지하는 모든 피어들에게 결과를 전송해 검증하고, 이상이 없으면 Ledger에 저장

• 비결정적 프로그램(non-deterministic program) 지원, 거래의 병렬 처리 등을 위해 거래 처리 구조를 변경
• 실행 -> 순서화 -> 검증 및 확정의 단계로 처리
• 클라이언트는 해당 체인코드의 보증 정책에 맞는 보증 노드에게 거래를 송신하고, 거래의 실행은 보증 노드에 의해 수행
• 보증 노드는 거래 실행 결과를 별도로 자료구조(readset, writeset)에 담아 클라이언트에게 회신
• 보증 노드는 거래 실행 결과를 블록체인에 미적용
• readset : 거래를 처리하기 위해 읽은 정보
• writeset : 거래의 처리 결과 정보
• 실행 결과를 수신한 클라이언트는 순서화 서비스 채널을 통해 거래 결과를 전송
• 순서화 서비스를 수행하는 노드들은 적용하는 합의 알고리즘에 따라 그동안 발생한 거래들을 순서화
• 순서화된 거래들은 블록에 담겨 채널에 연결된 모든 피어들에게 안전하게 전달
• 거래 결과를 수신한 피어들은 거래 결과가 보증 정책에 맞게 만들어졌는지 검증하고, 적합하게 실행된 거래의 결과를 블록체인에 저장함으로써 해당 거래를 확정

멤버십 서비스 제공자 구조

요구 사항

• 책임성(accountability) 보장
• 프라이버시(privacy) 보장

• 허가된 사용자만 접근할 수 있도록 멤버십 서비스를 제공
• 누가 뭘 했는지를 추적할 수 있어서, 책임 소재를 물을 수 있음
• 거래를 요청할 때마다 자신의 신원 정보는 수집할 수 없도록..

책임성(accountability) 보장

• 모든 참가자의 행위에 대한 정당한 책임 부여
• 참가자의 행위 추적
• 참가자가 자신의 행위 부인 방지
• 다른 참가자의 행위에 대해 부당하게 책임지지 않는 것을 보장
• 제3자를 통한 참가자의 행위 감사(audit) 보장

프라이버시(privacy) 보장

• 거래 익명성(transaction anonymity) 보장
• 거래 비연결성(transaction unlinkability) 보장

하이퍼레저 패브릭의 PKI 구조

• 노드나 클라이언트 모두 인증 기관(CA: Certification Authority)
• ECA(Enrollment Certification Authority) : 등록된 참여자가 맞다는 것을 인증하는 인증서 발행
• TCA(Transaction Certification Authority) : 등록된 사용자가 거래를 Posting할 때마다 다른 거래 인증서를 발행(누가 보냈는지 모르게 하기 위해서. 거래를 수행할 때마다 동일한 인증서를 사용하면 누군가가 모니터링하면서 누가 보냈는지를 알 수도 있으니까.)
• 등록된 참여자마다 ECA는 한 개가 있지만, TCA는 여러 개가 있음
• ECA와 TCA 사이의 상관 관계를 절대 추론할 수 없도록 설계됨(누구인지 추론할 수 없도록)
• TLS_CA(TLS Certification Authority) : TLS 프로토콜에서 상대방을 인증할 때 사용하는 TLS 인증서 발행

※ TLS(Transport Layer Security) : https 통신이 가능하도록 만들어주는 프로토콜. SSL의 Standard 버전.

ECA(Enrollment CA)

• 블록체인에 접근하고자 하는 참가자의 신원을 검증한 후에 등록 인증성(ECert - Enrollment Certificate)를 발급하는 역할을 수행
• 등록된 참가자를 확인하는 데 필요한 공개키와 개인키 쌍의 생성을 포함
• 참가자 등록을 위한 신원 확인은 등록 기관(RA - Registration Authority)에 위임 가능
• 신원 확인 방법과 확인 결과의 전달 방법은 응용의 요구사항에 따라 달라질 수 있음

TCA(Transaction CA)

• ECA에 의해 발급된 등록 인증서에 근거하여 신원이 확인된 참가자에게 거래 인증서(TCert - Transaction Certificate)를 발급하는 역할
• 등록 인증서(ECert)를 기반으로 충분한 수의 거래 인증서(TCert)를 발급
• 등록 인증서를 유추할 수 있는 어떤 정보도 포함하지 않음으로써 참가자의 신원이 노출되지 않도록 보장
• 각 거래 인증서는 동일 등록 인증서를 통해 발급된 다른 거래 인증서와의 연관성 정보를 포함하지 않음으로써 거래 비연결성 보장

TLS_CA(Transport Layer Security CA)

• 신원이 확인된 참가자를 대상으로 보안 통신 프로토콜인 TLS 프로토콜이 사용할 수 있는 인증서를 발급
• 네트워크 연결을 설정하는 등록된 참가자를 확인하는 데 필요한 공개키와 개인키 쌍의 생성 포함

멤버십 서비스 제공 절차

사용자와 클라이언트에 대한 멤버십 서비스 제공 과정

• 등록 인증 기관(ECA)에 참여자 인증서를 받으면, 해당 인증서를 가지고 내가 필요한 만큼 TCA를 발급 가능
• ECA의 공개키와 연계가 되도록 키를 생성
• 자신의 신원 정보는 노출하지 않음