* fabric과 Goquorum등 모든 컨소시엄 블렉체인의 사용예에서 어떻게 거버넌스를 이루어서 어떻게 사용했다라는 구체적인 기술 정보 및 비용감소에 대한 결과 정보가 부족해서 아쉽다. (사용 결과에 대한 효율 증가 분석표같은건 기대도 안함)
* 컨소시엄 블록체인을 진짜 컨소시엄을 해서 제대로 합의하고 견제하면서 하려면 Fabric을 사용해야 하는게 좋으며 (기능셋이 많다.) 좀 간략히 사용하려면 quorum이나 Besu중 아무것이나 선택해도 된다. Corda는 최근 거의 사용되지 않는 듯하며, CDBC쪽에서나 소식이 들리는 듯 하다.
* 성능의 경우 체감상 예상외로 Fabric이 빠른데.. (Fabric > GoQuorum > Besu) 전체 구조상으로는 동일 RAFT컨센서스 기준으로 패브릭이 단계가 더 많으므로 (E-O-V) 불리하지만, 이더리움 계열 시스템들은 (besu, quorum) 머클패트리샤트리와 EVM 구조를 그대로 사용하고, Gas가 큰 의미가 없음에도 사용되는 Gas비용계산등 퍼블릭체인의 유산들 때문에 성능 문제가 생겼으리라 생각된다
체크1) Hyperledger Fabric에서는 기본적으로 네트워크에 트랜잭션을 보내는 user 또한 허가받은 사람만 가능하며, 그들의 실체는 X.509로 규정되어진다. 하지만 Qourum , Besu는 그냥 user 는 이더리움과 같은 공개키로 만들어지는 anonymous 이다. Genesis 파일상에서 만들어지는 어카운트들을 이용해서 주로 사용하며, ACL은 스마트컨트랙트에서 관리한다.
체크2) Hyperledger Fabric에서는 ZKP 를 Identity Mixer 모듈을 가져다가 사용한다. 패브릭에서 트랜잭션을 보낼 때 보통 X.509 인증서를 포함해서 보내게 되는데, 여기에는 User의 정보가 모두 노출되어 있다. 선택적으로 노출시키고 트랜잭션 마다의 연계성을 끊기 위해 영지식증명이 사용된다. 결론은 패브릭은 용도에 따라서 선택 할 수 있다. 노출 할 건지, 숨길 건지
체크3) Order → Execute / Validate 모델과 달리 하이퍼레저 패브릭의 EOV(Execute → Order → Validate) 모델은 이는 체인코드 실행시 발생 할 수 있는 다양한 악의적 혹은 비결정적 문제에 대해 Client 와 Validate 시점에 Endorsement Policy에 의해 걸러지게 해 최종적으로 동일한 상태를 보장 할 수 있게 도와준다. 비결정적 문제에 대해 어떻게 제한을 가 할 지는 네트워크 구성원 끼리의 거버넌스에 따라 달라 질 것이다.
3-1) Fabric에서 Endorser로 부터 반환된 R/W Set이 악의적인 결과인지 비결정적인 문제인지는 클라이언트에서 판단 할 수 없다. differentiation 을 auto resolve 할 수 있는 방법도 없다. Avis에서는 Proxy에서 과반이 아닌 Peer에 emergency recovery call 을 보내는 설계를 고려하고 있으나 더 생각을 해 봐야 한다.
3-2) Corda 는 특이하게 피어들끼리 트랜잭션을 먼저 검증한 후에, Notary를 통해 이중지불을 확인 한 후에 최종적으로 양쪽에 커밋된다. (모든 피어들이 커밋정보를 가지고 있는 것과 다르게 관심을 공유하는 피어들 끼리만 공유한다)
체크6) Hyperledger Besu는 Hyperledger 재단의 첫번째 퍼브릭(가능)제품으로써, 합의 알고리즘에 따라서 캐릭터가 달라질 수 있다. 즉 PoA계열 알고리즘을 통해서 엔터프라이즈향에 적합해 질 수도 있다. IBFT2.0 (이스탄불 BFT 2.0)은 GoQuorum의 IBFT1.0을 개선하여 적용하였다.
체크7) 성능에 관해서 제일 궁금 하실 텐데, 사실 패브릭 제외하고는 다양한 설정등에 기반한 성능지표에 대한 자료가 너무 부족하다.
체크8) Besu의 경우 그룹별 프라이빗 원장 공유로 Orion이라는 기술을 이용한다. 패브릭의 채널과 비슷하다고 보면 된다. 사실 Orion은 Qourum에도 적용 될 수 있긴 하다.
체크9) Qourum의 경우 프라이빗 트랜잭션으로 Tessera 를 이용한다. Orion과 Tessera의 차이점은 따로 블로깅 하려한다. 최근에 Besu도 Tessera를 지원하게 됬다.
최근 추가 내용
Hyperledger besu ) - EIP-1559 적용 (가스비 산정 변경, EIP-1559를 포함한 런던하드포크는 8월적용됨) - EthStat 적용
GoQuorum ) - QBFT 추가 - EIP1559랑 무관. 가스비는 여전히 무의미(0) 하며 가스개념은 존재
Hyperledger Besu ans GoQuorum 상호운용성) - 동일한 컨센서스하 (QBFT) 에서 상호운용 가능 개선 - Tessera 를 활용한 Privacy 기능이 이제 양쪽 모두에서 가능
툴 개선) - Web3js-Quorum 새로운(기능보완) web3js 라이브러리로 ConsenSys Quorum node를 좀 더 잘 사용 할 수 있게 한다.
이 글은 버전을 구분하지 않고 있으며 , 스스로가 공부하면서 메모식으로 두서 없이 정리/수정 하는 내용인지라 글 읽기가 힘들 수 있으며, 암호학 전문가가 아니기에 일부 오류룰 담고 있을 수 있음을 참고 하십시요.
이더리움을 위시한 퍼블릭 블록체인에서는 굳이 네트워크에 붙는 노드들에 대한 신뢰가 필요 없기 때문에, 이 글에서 설명 할 하이퍼레저 패브릭이나 코다에서 신뢰,허가 작업을 하기 위한 복잡한 CA 관련 기술이 필요 없습니다. 대신 이더리움은 아무나 참여하는 네트워크에 대한 신뢰를 다른 방식으로 추가 하기 위한 더 어려운 일에 도전하고 있는 상황입니다.
이 글에서는 하이퍼레저 패브릭과 코다에서 네트워크에 참여하는 노드들의 신뢰,허가작업들이 어떤게 있는지 살펴보겠습니다. 실제 메뉴얼들은 이 글 보다 훨씬 방대한 내용을 담고 있으며, 특히 허가,보안,거버넌스 부분은 패브릭의 가장 어려운 내용이라 할 수 있겠습니다.
1. CA (certificate authority)
인증 기관이라는 의미이다. 즉 내가 누구인지 혹은 이 웹싸이트가 누구인지 인증해 주는 기능을 하는 것을 말한다.예를들어 네이버에 접속한다고 치면, 사용자의 브라우저는 네이버 서버에 접속을 하게 될 것이다. 이때 중간에 무엇인가 접속 신호를 가로채서 이상한 서버로 접속 할 수도 있을텐데, 이때 브라우저는 자신이 접속한 서버가 네이버라는 것을 어떻게 알 수 있을까?
답은 네이버는 자신이 네이버라는 이름이 적힌 종이(예를들어)를 브라우저 한테 보내준다. 그럼 "아~ 네이버가 맞네" 하고 받아드린다. 응?? 뭔가 어설프다. 그 종이가 진짜 맞는지를 확인(인증)해주는 무엇인가가 필요하지 않을까? 그때 CA가 필요해진다.
여기서 공개키/비밀키에 대한 얘기를 먼저 해야겠다. 사실 이 글을 읽는 분들이라면 다 아는 것이라고 생각하지만 간단히 설명하자면, 누구든 자신의 공개키/비밀키 한쌍을 만들 수 있으며, 비밀키는 자신만 고히 간직하고, 공개키는 사람들에게 뿌린다. 이때 "안녕하세요" 라는 문서를 비밀키라는 것으로 변환시켜서 "114ae2" 라고 변경된다고 할 경우, "114ae2" 를 다시 "안녕하세요" 라고 변경하기 위해서는 공개키로 풀면된다. 이 얘기는 공개키로 풀어서 "안녕하세요" 가 나오지 않는다면 비밀키나 공개키가 잘못되었다는 것을 의미한다. 즉 엘리스가 밥에게 "사랑한다" 라고 편지를 보내며 자신의 비밀키로 변환시켜서 "224eaf3" 이 나왔다고하자. 엘리스는 "사랑한다" 라는 편지와 새로 생성된 "224eaf3" 를 중간대리자를 통해 밥에게 전달하면, 밥은 엘리스의 공개키로 "224eaf3" 를 풀었을때 "사랑한다" 가 나온다면, 아 진짜 엘리스가 보낸게 맞구나. 라고 인정할수있게 된다. 이는 부인방지가 될 수도 있는데, 엘리스 자신이 "사랑한다" 라고 보내놓고, "응 그거 내가 보낸거 아니야" 라고 부인할 수 없다는 뜻이다.
이 공개키/비밀키는 위에 언급한 CA에서 적극적으로 사용되는데, CA의 공개키는 브라우저에 뿌려져서 누구나 가지고 있게 된다.CA의 비밀키로는 네이버가 적은 "내가 네이버야" 종이를 변환해서 "3232DASF3" 라고 변환시킨후에 이 둘을 브라우저에 보내면, 브라우저는 CA의 공개키로 "3232DASF3" 를 복구 할 때 "내가 네이버야" 라고 복구된다면 신뢰 할 수 있게 되는 것이다.
끝!! ???
근데 여기서 딴지를 거는 센스있는 분들이 있을 수 있겠다. 그렇다. CA의 공개키는 브라우저에 뿌려져서 누구나 가지고 있게 된다. 이게 문제인데. 그럼 그 CA라는 놈의 공개키는 어떻게 믿을 수 있냐? 라고 말 할 수 있는데, 그땐 그 CA의 상위 CA가 인증을 해 줄 것이다. ㅎㅎ 아래 이미지를 보자.
제일 위의 Root CA 는 스스로 인증을 하며, 그 아래 CA들은 그 부모(상위) CA에 의해서 인증된다. 대략 이런 메커니즘이 있다는 것을 이해하고 하이퍼레저와 CORDA의 CA에 대해 알아보자. 조금 다른 것은 위의 CA 설명에서는 네이버라는 서버에 대한 인증이었다. HTTPS 에셔 사용되는 인증은 이런 서버에 대한 것이고, 서버가 아닌 클라이언트 즉 모든 피어가 CA 에 의해서 인증 받아서 서로에 대한 신뢰를 구축 할 수도 있는데, 하이퍼레저와 CORDA 에서는 하나의 중앙 서버가 아니라, 모든 노드들이 자신들의 인증을 CA 를 통해서 받게 된다. 탈중앙화 아니던가!!!
* 2017년에는 구글이 직접 Root CA 를 운영한다고 한다. 구글이라면 믿을 만 하지 ㅎㅎ * 하이퍼레저나 CORDA 에서는 자신의 인프라 안에서 Root CA 및 자식 CA 들이 구축된다. 즉 스스로 발급기관 역할도 한다는 것.
2.하이퍼레저 패브릭과 CA,MSP 하이퍼레즈 패브릭에서 CA(인증 기관)는사용자 등록, 블록체인에서 호출된 트랜잭션 및 블록체인의 사용자 또는 구성요소 간의 TLS 보안 연결과 관련이 있다.
2-1. 네트워크 구성 및 Fabric-CA (ver1.0~)
위의 그림은 일반적인 하이퍼레저 패브릭의 네트워크 구조도 이다. 아래와 같은 특성이 있다.
- 먼저 CA 와 Fabric-CA 는 다른 것이니 혼동하지 말자. CA 는 간단히 말해 어떤것에 대한 증명 해 줄 수 있는 문서 목록이며, MSP를 통해 기관으로의 실시간 오퍼레이션을 하며, Fabric-CA 는 CA 기능에 관한 여러가지 오퍼레이션을 하는 서비스이다. 예를들어 cryptogen 유틸을 통해 CA 들을 구성 할 수 있으며, Fabric CA Server 를 통해서도 구성 할 수 있다. - 전체 네트워크에는 중간 중간 마다 Fabric-CA 서비스가 있을 수 있다. (하나만 있어도 된다) - 전체 네트워크의 CA 들의 Root CA 도 있다. - 보통 조직마다 하나의 중간 Root CA (intermediate CA) 를 만든다. - Fabric-CA 는 고가용성을 위한 프록시가 front에 있는 클러스터로 구성하면 안정적이다. - Fabric CA에 접근해서 서비스를 받고 싶은 경우 Fabric-CA Client를 통하거나, Fabric SDK 를 통해서 이용 할 수 있다. - Fabric-CA 는 주로 도커 이미지로 실행 되며, 설정파일을 통해 백엔드에 MySQL 같은 RDB 를 이용한다. - Fabric CA 를 통해서는 아래와 같은 서비스를 제공 받을 수 있다.
각 조직,서비스등에 대한 신원 등록. LDAP 인증으로의 접속 매개. 전체네트워크 범위 msp 채널 범위 msp 조직 자체의 msp 조직 관리자의 msp 조직 유저의 msp 조직의 peer 의 msp
Enrollment 인증서 발급 (ECerts 로써 아래 따로 설명함)
인증서 갱신 및 폐지
개인적으로 아직 정확하게 cryptogen 과 Fabric-CA 의 기능상(API 갯수 및 능력) 차이점을 확인하진 않고 있으며 다음에 정리 할 예정이다. 일반적으로는 cryptogen 은 거의 모든 기반 cryptographic material 만들 수 있고, (미리 만들어 두고) 반면 Fabric-CA 는 PEER, USER, APP 에 대한 신원등록은 할 수 있으나, Orderer 는 아닌 것으로 알고 있으며, Fabric-CA 는 주로 User (admin이나 일반) 의 신원 등록 (X.509 certificates) 를 동적으로 생성/저장/갱신/폐기 하기 위해 사용하고 있는 것으로 생각한다. 따라서 cryptogen 으로 만들 수 있는 것은 미리 만들어두고, 그 후로 Fabric-CA 를 사용하는 패턴을 활용하면 될 거 같다. 참고로 Fabric-CA 에는 User의 개인키를 저장해 두고 있진 않다. 더 자세한것은 이 링크를 참고하시라. -> Fabric CA User's Guide
(Fabric 1.0 Fabric-CA)
2-2. CA 계층도 (ver 0.6)
패브릭의 CA 구조는 위의 그림과 같은데, 하나의 Root CA 로부터 가지쳐서 내려오며 상세 설명은 아래와 같다.
- Enrollment CA 는 새로운 user 를 네트워크에 등록하는데 사용되는 CA 이다. - Tranaction CA 는 등록된 사용자가 트랜잭션을 요청하는것에 사용되는 CA 이다. - TLS CA 는 사용자들이 원격피어와 통신을 할 때 보안 채널로써 활용된다. HTTPS 또한 TLS를 사용한다. - ECerts 는 CA 가 각각의 멤버 컴포넌트(사용자,서버서비스)들에게 등록에 사용하라고 발행 인증서 자체이다.RA에서 만들어진 개인증명서를 통해 발행 - TCerts 는 CA 가 사용자가 트랜잭션 요청에 사용하라고 발행하는 인증서 자체이다. ECert 를 통해 발행
각각의 CA 를 통해 각각의 ECerts / TCerts 가 최종 생성된다. 참고로 TCerts 는 1.x부터는 컨셉에서 사라진것으로 알고 있다. 대신 3번에서 소개 하는 Identity Mixer 가 사용된다.
2-3. 실제 네트워크의 허가/인증 관련 구성 (ver 1.0~) first-network 예제의 cryptogen 유틸을 이용해서 생성된 디렉토리를 보면,
위 처럼 org1 이라는 조직에 대한 ROOT CA가 있으며, 즉 조직마다 CA가 생기며, 그 아래 peers, users 각각에 대한 MSP(와 조직 ROOT CA로 부터 생성된 CA) 가 존재하고 있음을 알 수 있다. 또한 각 폴더에 생긴 인증서파일인 .pem 을 열어보면
위처럼 org1 이라는 이름의 조직을 대표하는 CA가 있고,그것은 스스로 서명을 하는 Root CA로 작동하고 있으며, 그것을 이용하여 아래와 같이 peer0,Admin,orderer 각각의 인증서가 만들어진 모습을 볼 수 있다,
이런 인증서를 기반으로 Fabric CA 서버/클라이언트를 통해 각각의 ECerts / TCerts 가 최종 생성 될 것이다. 참고로 fabcar 예제의 enrollAdmiin.js 과 registerUser.js 를 실행시키면 프로젝트의 루트에 있는 hfc-key-store 디렉토리에 아래와 같이 admin과 User에 대한 eCert 와 키 쌍을 출력 한다.
MSP (Membership Service Provider)는 이름 그대로 멤버쉽 서비스에 대한 아키텍처의 추상을 제공하는 목적의 컴포넌트이다. 인증서를 발급하거나 검증하고 사용자 및 서비스의 신원에 대한 작업과 관련된 일을 한다는 의미이다. 조직마다 보통 하나의 MSP가 있으며 MSP ID로 구분된다. 추가 정보로MSP는 네트워크 범위에서 부터 로컬의 범위에도 존재 한다.
전체네트워크 범위 msp
채널 범위 msp
조직 자체의 msp
조직 관리자의 msp
조직 유저의 msp
조직의 peer 의 msp
자 그럼 이것이 Fabric CA와는 무엇이 다른 것일까? fabric의 표준 심플인 fabric-samples/first-network 에서는 cryptogen 유틸을 통해 MSP가 작동하기 위한 초기 정보들을 제공해 주고 있다. 아래 그림과 같이 조직마다 CA (Fabric CA 서비스가 아니다) 와 MSP 를 가지고 있는 모습이다. 조직마다 생성된 CA 와 MSP 는 전체 네트워크에 정보가 공유 되어 서로 검증하는데 사용 될 수 있다. 참고로 cyrptogen 을 이용하지 않고 fabric-CA 를 이용해서 생성 할 수도 있으며 (Orderer 제외),fabric-CA 는 fabric-ca-serverinit 명령어를 통해서 디폴트로
fabric-ca-server-config.yaml
환경파일을 생성하며 디비설정등을 할 수 있으며, cryptogen 유틸은 crypto config.yaml 설정파일을 이용한다.
여기서 알 수 있는 것이 MSP,CA는 조직이 가지고 있어야 하지만, Fabric-CA 는 없어도 된다.(근데 실제 서비스에서는 없을 수가 없다) cryptogen 을 통해서 조직이 사용할 각종 신원증명 매터리얼 들을 MSP의 초기화에 제공해 주면 되는 것이다. (실제 서비스에서는 이렇게 하긴 좀 머하지 않을까?) 반대로 cryptogen 없이 Fabric-CA 를 통해서 그런 신원증명 매터리얼을 만들 수도 있다. 즉 Fabric-CA 는 어떤 기본 정보를 제공해 주는 것이고, MSP 는 그 정보를 통해서 실제 어떤 오퍼레이션을 하는 것이라고 볼 수 있을 것이다.
따라서 Fabric-CA 는 전체 네트워크에 하나만 있어도 되고, 여러개 있어도 되는 것이다. (글 초반에 말한것처럼 보통 한개가 HA로 구성되어 있을 것이다)
* 이 글을 쓸 현재는 Fabric CA 서버를 통해 생성된 사용자의enrollment certificate (eCert) 가 fabcar 예제에서는 hfc-key-store 에 저장되는데, 이것들이 MSP와 어떤 연관관계를 가지고 고 있는지는 불명확하다. 실제 MSP 폴더를 열어보면 cryptogen 으로 부터 생성된 CA 정보들(조직의 root CA, PEER CA, USER CA, ORDERE CA,TLS CA)이 존재하는데 혹시나 MSP 가 enrollment certificate (eCert) 도 관여하는지는 잘 모르겠다. Fabric-CA 서버를 통해 만들어진 enrollment certificate (eCert) 가 사용시 이것을 검증하기 위한 CA로써의 역할을 MSP 가 하지 않을까 추측하고는 있다.
체인코드에서의 MSP 사용
하이퍼레저 패브릭의 체인코드적으로 MSP 를 말하자면 "어떤 조직에 속 할 경우" 에만 "어떤 체인코드의 메소드를 호출" 할 수 있는 권한을 부여하게 하는 역할을 한다. 실제 예를 생각해 보자, 개인들은 자신의 바이오인포매틱스 정보를 제공하고, 병원은 개인들의 의료정보를 저장하고, 연구조직에서는 해당 정보들을 가져다가 분석한다고 해보면, 각자의 그룹들이 나누어 질 것이며, 해당 그룹들은 체인코드(스마트 컨트랙트)의 모든 메소드를 호출 할 수는 없을 것이다. 즉 자신의 그룹과 관련된 메소드만 호출 할 수 있을 것인데, 그럼 개인들은 어떤 메소드만을 호출 할 수 있을까? 뭐 uploadPersonalData(....) 같은 것이겠지 않을까? 연구조직이라면 GetSomeKindOfPersonsBloodInfo(....) ?
// 조직의 전용 mspID 와 certCN 을 통해서 확인하여, 호출 할 수 있는 조직을 경우에만 호출하게 제한한다. func authenticateExportingEntityOrg(mspID string, certCN string) bool { return (mspID == "ExportingEntityOrgMSP") && (certCN == "ca.exportingentityorg.trade.com") }
Hyperledger fabric 소스코드에서의 MSP 설명.
Hyperledger Fabric 의 MSP api 란?
하이퍼레저패브릭 네트워크에 참여하는 클라이언트나 피어들에게 (익명의) 증명서를 제공하기 위한 시스템의 추상 api 인터페이스이다.클라이언트는 이 증명서를 트랜잭션을 위해 사용하며, 피어들은 보증에 대한 트랜잭션 프로세싱의 결과를 인증하기 위해 사용한다. 이 인터페이스는 멤버쉽 서비스 컴포넌트 정의를 위해 사용되며, 이것을 통한 구현들은 코어 트랜잭션 프로세싱 컴포넌트의 수정없이 자연스겁게 플러그인 될 수 있을 것이다.이 소스파일은 MSP 인터페이스를 포함하고 있으며, MSPManager 는 MSPs 의 매니저를 정의하는 인터페이스이다. MSP를 호출하거나 라우팅하기 위한 매개객체로 행동한다.
type MSPManager interface { // IdentityDeserializer interface needs to be implemented by MSPManager IdentityDeserializer // Setup the MSP manager instance according to configuration information Setup(msps []MSP) error // GetMSPs Provides a list of Membership Service providers GetMSPs() (map[string]MSP, error) }
// MSP is the minimal Membership Service Provider Interface to be implemented // to accommodate peer functionality type MSP interface { // IdentityDeserializer interface needs to be implemented by MSP IdentityDeserializer // Setup the MSP instance according to configuration information Setup(config *msp.MSPConfig) error // GetVersion returns the version of this MSP GetVersion() MSPVersion // GetType returns the provider type GetType() ProviderType // GetIdentifier returns the provider identifier GetIdentifier() (string, error) // GetSigningIdentity returns a signing identity corresponding to the provided identifier GetSigningIdentity(identifier *IdentityIdentifier) (SigningIdentity, error) // GetDefaultSigningIdentity returns the default signing identity GetDefaultSigningIdentity() (SigningIdentity, error) // GetTLSRootCerts returns the TLS root certificates for this MSP GetTLSRootCerts() [][]byte // GetTLSIntermediateCerts returns the TLS intermediate root certificates for this MSP GetTLSIntermediateCerts() [][]byte // Validate checks whether the supplied identity is valid Validate(id Identity) error // SatisfiesPrincipal checks whether the identity matches // the description supplied in MSPPrincipal. The check may // involve a byte-by-byte comparison (if the principal is // a serialized identity) or may require MSP validation SatisfiesPrincipal(id Identity, principal *msp.MSPPrincipal) error }
MSP 정리
- MSP 는 멤버쉽 오퍼레이션을 위한 추상층을 제공한다. - MSP 추상층은 인증서 발생/검증 및 사용자인증에 관련된 암호적 메커니즘에 관련된 프로토콜이다. - 각 MSP 는 이름/ID 가 있어야 한다. 그 이름을 토대로 해당 멤버쉽 룰을 따르기 때문. - 시스템 레벨에서는 채널생성, 채널레벨에서는 읽기/쓰기 컨트롤, 체인코드레벨에서는 함수호출제한 역할을 한다. - 디폴트 MSP가 구현되어 있는데, RFC5280 에 따라서 다음 요소들이 포함한다. ㅇ ROT 를 위한 셀프 사인드 인증서 (X.509) ㅇ intermediate CAs 의 X.509 인증서 리스트 (ROT를 바라봐야한다) ㅇ Organizational Units 리스트 ㅇ ertificate revocation lists (CRLs) 리스트 ㅇ 자가사인된 TLS ROT ㅇ intermediate TLS CAs 의 X.509 리스트
- MSP가 돌아가기 위한 기본 암호적 요소(signing keys and certificates) 들을 만들기 위해 “Cryptogen tool” 과 Fabric CA를 이용한다. - MSP 를 셋업하기 위해 PEER & ORDERE 에는 6개의 서브폴더와 파일이 있어야 한다. (위에 폴더구성그림 참고) - 노드의 설정파일을 셋업하는 동안 mspconfig폴더와 노드의 MSP의 MSP indentifier 패스를 설정해줘야한다.peer 를 위한 mspConfigPath 그리고 orderer 를 위한 LocalMSPDir - 채널에 대한 MSP 셋업은 오더러에 채널에 대한 제네시스 블록 (오더러를 시작하기 위한 네트워크 범위의 제네시스 블록과는 다르다)을 포함하는것으로 시작한다.
3. Identity Mixer
신원보호(unlinkability, minimal attribute disclosure) 측면에서 TCert 방식의 비효율적인 문제점을 개선하기 위해 나온 기술로써 영지식증명을 활용한다. (Camenisch-Lysyanskaya (CL) signature scheme or BBS+으로 어떤 속성에 대해서 올바른 서명을 알고있다는 것을 실제 서명 자체를 노출하지 않고도 증명 할 수 있는 방식으로 Flexible public keys, Flexible credentials 라는 특징을 가지고 있다)
기존의 ECert 즉 User에 대한 신원증명서는 x.509 형식으로 되어있으며 해당 정보는 CA로 부터 발급받는데 세부정보가 모두 노출되어 있다. 따라서 해당 신원증명서를 첨부하여 트랜잭션을 호출 할 시, 자신의 정보를 모두 노출시키는 프라이버시 침해가 발생할 소지가 있다. 그렇다고 해서 신원증명서의 일부분을 제거하고 보낸다면, CA가 서명한 sign 코드는 무용지물이 될 것이고.. 이것을 보완하고자 등장한 것이 Identity Mixer 이다.
이 녀석은 위에서 말한 신원증명서의 일부 내용을 감춰서 보내도, 검증자 입장에서 CA가 인증해준 증명서라는 것을 똑같이 검증 할 수 있다. 이때 User의 public key 또한 호출 할 때 마다 변경이 가능하니,여러모로 프라이버시가 강화되는 것이다. 즉 소속을 숨겼는데, 소속을 Verifier가 알 수 있다는 의미의 영지식증명은 아니고, attribute가 바뀌었는데도 불구하고, CA가 동일하게 증명 할 수 있다는 의미의 영지식증명이다. 즉 너의 속성중무엇이 바뀌었던간에 너라는 존재가 맞다는 것에 대한 증명이다.
Fabtoken 에서 UTXO 개념으로 소유권을 관리하는데, 매번 바뀌어지는 public key를 사용하여 처리하지 않을 까 추측한다.
ECert / TCert 처럼 X.509 나 Certificate 라고 표현하지 않고, Credentials 라 표현하고 있다. 즉 서로 다른 것이다.
X.509형식의 인증서를 매번 받는게 아니라, 한번 받은 Credential로 부터 새로운 Presention Policy를 적용한 것을 이용해 트랜잭션을 보내고 있다. Verifier 는 CA의 공개키로 모든 것에 대해 검증 가능하다.
Identity Mixer 크립토패키지는 발급자 키와 credentials 를 발급하고, presentation tokens를 생성하고 검증하며 key generation, signing, verification, zero-knowledge proofs 의 기능을 가지고 있다. (각 컴포넌트에서 가져다 사용하는 라이브러리라고 생각하면 된다. Fabric-CA처럼 단독실행서비스가 아니고, Fabric-CA에서도 가져다 쓰고, Java-SDK에서도 가져다 쓰는 라이브러리이다.)
기존의 CA 서비스는Identity Mixer 크립토 패키지를 이용하여 ECert credentials 를 발급한다.
MSP는 Identity Mixer 크립토 패키지를 이용하여 트랜잭션에 대한 서명/검증을 수행한다.
각기 다른 언어로 만들어진 Client SDK를 위한 Identity Mixer 크립토 패키지가 만들어지고 있다.
표(1) 이 글은 조직 구조 특징을 그림으로 간단히 서술 할 예정이다. 일반 블록체인에 대한 이해는 있어야 해서 설명이 이해하기 쉬울지는 모르겠다. @@ 참고로 아래 그림과 같은 트랜잭션 흐름/컨센서스에 관한 대한 설명은 포함하지 않는다.
(그림1)
그림에서 각 Peer (패브릭에서 노드(서버)는 peers, orderer,CA 등으로 이루어져 있다)는 나중에 설명 할 채널 데이터(Ledger)를 저장하는 곳이라는 것만 알자.
Hyperledger Fabric vs CORDA
둘 다 엔터프라이즈 블록체인이다. 즉 어떤 참여자(조직,그룹등)든지 허가에 의해서만 참여 할 수 있다. 채굴이라는 노가다를 하지 않으며 그들의 신원은 분명하다. 별다른것 없을 것 같은 이 두가지 프라이빗 블록체인에서 가장 큰 구조(설계)적 차이점을 보이는 것은 저장하는 데이터(State,Assets,,Ledger,facts)를 어떻게 조직화하고 공유하냐 인데, 이것을 염두해두고 앞으로의 그림을 살펴보자.
채널이라는 놈이 보이는가? 이게 CORDA에는 없는 패브릭의 주요 특징이다. 채널은 서로 간에 독립한다. 즉 서로 다른 블록체인이라고 생각하면 된다. (Orderer 같은 서비스를 공유 할 수는 있다.)
따라서 채널A에서 일어나는 일들에 대해 채널B는 알 수도 없으며 검증할 수도 없다. 그렇게 하려면 소위 인터체인 (여기서는 인터채널?) 같은게 필요한데, 패브릭에서는 그딴 걸 굳이 구현 할 생각이 없는 것 같다.
(그림3)
그림3) 처럼 채널에는 해당 채널에 맞는 역할을 하는 각각의 조직이 포함되어 있으며, 그들은 서로 유기적으로 관계를 맺고 있고, 데이터(State,Assets,,Ledger,facts)도 서로 공유하며,스마트컨트랙트(패브릭에서는 체인코드라고 한다)를 통해 해당 데이터를 조작 할 수도 있게 된다. 이 조작은 MSP 라는 것을 통해 각 조직이 허가 받은 조작만 가능하도록 할 수 있다. 하이퍼레저 패브릭 1.2에서는 각 조직간의 비밀리에 유지 할 수있는 데이터를 관리하는 방식에 대한 기능도 추가 되었다.
* 채널 안에 조직들 중에 몇몇은 그룹을 짓기도 하는데 이를 콘소시엄이라고 한다. 여기선 생략.
패브릭에서는 다른조직들 간의 장부도 같은 채널내 라면 오픈되어 있는 반면에, Corda의 경우는 애초에 참여자(조직,그룹등) 간에 정보를 모두 공통적으로 가지는 방식을 배제하여 설계 하였다. 즉 위의 그림에서 벤다이어그램 식으로 수출기업과 운송업자간의 공통데이터를 수입정책협회가 알 필요가 없다고 생각한 것인데, 애초에 이렇게 설계를 하다 보니, 개별 참여자간의 데이터 Privacy 에 대한 강점이 하이퍼레저 패브릭에 비해 매우 크다고 할 수 있겠다. (서로 지향하는 바가 다르다)
위에서 각각의 겹쳐지는 조직("수출기업과 운송업체", "수입기업과 운송업체", "수입기업과 수입정책협회")을 떼어내어 그 하나 하나를 패브릭에서의 "채널" 이라고 생각 한다면, Corda 의 경우에는 채널간에도 데이터 이동이 가능하다. 무슨 얘긴가 하면 아래 그림을 보자.
그림(5)
앨리스와 밥이 하나의 채널을 이루었지만, 밥은 칼과도 채널을 만들어서 데이터 거래를 할 수 있다는 것이다. 이때 의심이 드는것이 그럼 밥은 앨리스에게도 1000원을 주고, 칼에게도 1000원을 이중지불 하면 어떻게 되냐는 것인데, Corda 에서는 Notaries라는 전체를 관장하는 서비스가 그것을 방지하는 역할을 하고 있다.
즉 Corda 는 소위 채널간의 거래를 Notraries 라는 것을 통해서 해내고 있다고 말 할 수도 있다. 물론 이런 설명은 모두 블록체인이 아닌 Corda를 블록체인 혹은 Fabric의 채널에 맞춰넣어서 하는 설명이긴 하다. (이해하기 쉽지 않을 수 있으리라 생각한다. 이해가 안간다면 모두 글쓴이 탓이다.)
정리
정리를 하자면, 패브릭은 조직(참여자)이 있으며, 서로 간련 된 조직들 끼리만 비지니스로직을 처리하고 데이터를 공유하는 "채널" 이라는 개념이 있다. 패브릭에는 이런 채널을 여러개 둘 수가 있는데, 보통 하나의 채널로 다 될 것이다. 이때 혹시 외부 채널의 어떤 조직과 상호운영하고 싶을 수가 있다면, 이건 불가하다. 또한 어떤 새로운 조직을 내 채널에 넣고 싶은데, 해당 채널의 일부데이터만 보여주고 싶은 경우도 불가하다. 예를 들어 채팅방에 누구를 초대했는데, 나와 수현이와의 대화만 보이게 하고 싶은게 불가능하다는 얘기이다. 그 채팅방의 전체대화를 공개해야한다. 하지만 패브릭 1.2 에서는 Private data 를 통해 애초에 채널내의 조직들간에 비공개로 모든 비지니스가 이루어지게 했다면, 새로운 조직을 내 채널에 추가해도 그런 염려는 없겠지만, 개인적인 생각으로 그건 좀 어거지가 아닌가 싶다. 패브릭 답지 못하다!!
코다의 경우 애초에 모든 조직들간의 장부가 서로 격리되어져 있기 때문에, 위 처럼 새로운 조직(참여자)와 커뮤니케이션을 시작하더라도 다른 참여자와 나눈 커뮤니케이션은 감추어 질 수 있다.
이제 어느 정도 어디에 패브릭과 코다를 사용해야하는지 대략 보일 것이다. 여러 참여자와 새로운 참여자가 복잡하게 얽혀 있을 금융거래 같은 곳, 기본적으로 서로간의 거래를 다른 참여자에게 노출 시키지 말아야하는 곳에서는 코다가 적합 할 것이고, 처음부터 명확한 조직들 간의 관계를 설정 해 두고, 새로운 참여자에게 비밀유지 보다는 그들 간에 신뢰에만 촛점을 맞추고, 유기적인 조직 구성에 중점을 두며, 일정 부분만 비공개로 관리하는 콘소시엄 형태라면 패브릭이 적합 하다고 볼 수 있다.
부록
Hyperledger fabric 에서 조직을 어떻게 추상화 하고, 실제 네트워크에서 어떻게 구성되는지 살펴보자.
추상조직구성)
1. 유저들을 포함한 조직을 만든다. (조직을 대표하는 인증서등도 만들어 진다) 2. 조직들을 묶어서 콘소시엄을 만든다. 3. 채널을 만들어서 원하는 조직들을 포함한다.
실 네트워크 구성)
1. 조직은 그것에 해당되는 Peer들을 선택하여 설정한다. 2. 조직이 가질 수 있는 Peer의 갯수는 1개가 될 수도, 여러개가 될 수도 있다. 3. Peer 는 실제 서버에서 돌아가는 서비스이다. (체인코드를 실행/보증/커밋하는 등 다양한 역할을 한다) 4. 조직마다 자신의 Identity 를 책임질 MSP, CA 서비스를 가지고 있다. 5. 모든 조직이 하나의 orderer 서비스를 이용할 수도 있고, 나눌 수도 있다. 6. ordereing 서비스의 초기화시 채널(조직)들의 제네시스블록을 제공한다. 7. Node(서버) 한대에 모든것을 다 집어 넣을 수도 있다. 8. orderer 서비스의 경우 저것이 SPOF 가 될 수도 있기 때문에 주키퍼를 이용해 분산코디네이팅을 해줄 수 도 있다.
