개인적으로 비트코인,이더리움만 블록체인 플랫폼이라 생각하지만, PBFT나 DPos를 사용한 체인들도 불록체인이라 말하는 사람들에 대해 틀렸다라고 말하지도 않는다. 네트워크 참여가 제한된 콘소시엄형 블록체인 (분산장부라고도 말하는)은 나름 "신뢰비용" 을 줄이는데 잘 사용 될 수 있는 자질을 가졌으므로 이것들 또한 블록체인이라고 불리는데 이제는 순수탈중앙주의자 빼고는 업계에서 합의를 한 분위기인거 같기도 하다. 당장의 호구지책도 중요하니까. 가끔 분산장부와 분산DB가 무슨 차이냐라고 묻는 사람이 있는데 이것도 큰 차이가 있는데, 첫째 악의의 노드(비잔틴)를 감안하냐, 둘째 불변이 필수적인 데이터만 저장되느냐, 마지막 세째가 바로 여기서 심플하게 이야기할 거버넌스 문제이다.
최근 공공기관이라든지 여러 블록체인 SI사업들이 활발히 진행중인데, 여기서 사용 할 만한 플랫폼은 하이퍼레저패브릭이 거의 필수라고 나는 생각한다. 이유는 쿼롬이라든지, 기타 기업차원에서 만든 (패브릭기반이 아닌) 것들은 거버넌스 작동에 대한 철학이 없으며 지원 또한 거의 없다. 반면에 하이퍼레저 패브릭은 처음부터 이 거버넌스의 중요성에 집중하였다. 거버넌스 비용을 최소화 해야 콘소시엄 블록체인을 사용하는 유일한 이유인 "신뢰비용"을 줄일 수 있을 것이며, 거버넌스에 집중해야 새로운 비지니스 모델을 만들 수 있으며 기업들은 그에 따른 이득을 얻을 수 있는 것이다. 하이퍼레저 패브릭 콘소시엄 블록체인은 거버넌스를 유연하게 만들어주어 이것을 가능하게 해주며,(물론 참여자들의 노력기반하에) 이것의 중요성을 알고 지원에 집중하고 있다. 물론 거버넌스가 아예 없는 시스템도 만들 수 있겠지만 , 이 정도면 이제 블록체인이라는 말을 쓰면 안되는 단순 분산DB일 뿐 일 것이다.
참고로 이더리움,비트코인 같은 퍼블릭체인에서의 거버넌스은 순수히 네트워크 프로토콜 상의 보상/조정 시스템에 의해서 돌아가며 모든것이 오픈되어있다. 따라서 좀 더 보안이 필요하며 세밀한 제어가 필요한 영역에서는 사용하기 힘들다.
그럼 콘소시엄 블록체인에서 거버넌스란 무엇일까?
1. IT 거버넌스
이것은 IT인프라 종류,성능,보안,배포전략등에 관한 이슈를 네트워크 참여자들의 요구에 맞추어 구성,업데이트 해가야 하는 것을 말한다. IT SLA,OSS,BSS등에 대한 최적화 전략과 합의가 필요하다.
2. 블록체인 네트워크 관리
IT거버넌스와 비슷한데, 네트워크 참여 및 비용에 관한 이슈에 집중되어 있다. 네트워크에 트랜잭션을 보낼 수 있는 사용자들을 참여/탈퇴/리소스제한에 대한 규칙을 지정하며, 네트워크 사용 및 스토리지 사용 비율에 따른 적절한 비용 분배 규칙도 지정해야 할것 이다.
3. 비지니스 네트워크 거버넌스
네트워크 공동체가 필요로한 사업모델을 수립하고 KYC절차,감사,보고등과 같은 네트워크에서 공통으로 공유하는 서비스 관리 및 법률/규제 준수 보장 전략을 수립해야한다. 콘소시엄 블록체인은 참여자들의 다양한 의미의 수익을 위해서, 공동 창조를 가능하게 해주는 플랫폼이며, 이를 위해서는 각 노드들의 적극적인 참여가 반드시 필요하다고 볼 수 있다.
이런 거버넌스를 이루기 위한 네트워크 모형 중 아래는 설립자 주도형 네트워크 인데
현재의 많은 프로젝트들이 이 수준에 머무르고 있다. 턴키를 받아서 "을" 회사에서 주도적으로 만들어 상납하는 구조이다. 네트워크의 참여자들 간의 거버넌스는 전무하며, POC 개념에 머무르고 있는데 좀 더 성숙함에 따라서 거버넌스의 중요성이 떠오를 것이며, 이것을 편하게 만들어주는 UI/UX도 절실할 것이다. 이런 적극적인 거버넌스 참여 없이는 프로젝트는 단발성에 그칠 수 밖에 없으며, 진정한 수익을 거두기도 힘들 것이다.
이번 포스트에서는 하이퍼레저 패브릭에 관련된 기술중에 가장 알려지지 않은 주제인 Recovery에 대해서 다룬다. (그냥 링크로 무임승차지만;;;; 쏘오뤼~) 오랜시간 동안 네트워크가 작동하다보면 분산 노드들 간에 일관성에 관하여 문제가 생길 수 밖에 없기 때문에, (디스크 오류등 각종 예기치 못한 상황으로) 이를 회복시켜주는 기술이 패브릭에도 필요한데..
보통 일관성이 깨지는 곳은 스토리지에 무엇인가를 쓸 때이고 보통 하이퍼레저 패브릭에서는 committer 노드에서 일어난다. 좀 더 자세히 설명해 보면 orderer로 부터 받아온 블록을 가지고 해당 블록안에 있는 트랜잭션들을 VSCC, MVCC등의 다양한 방식으로 검증 한후에, 이상이 없으면, A) 블록체인을 업데이트하고 B) 상태DB도 업데이트 하고 C) 히스토리DB도 업데이트 한다. 이렇게 모두 잘 마무리 되면 모든 노드의 저장 상태는 동일하게 되는데 ( 물론 채널과 Private Data에 따라서 달라지는 부분 제외하고)
이때, VSCC, MVCC 중에 문제가 생겼을 경우에는 저장 과정에 돌입하지 않고 그냥 리턴해 버리기 때문에, 특별한 Recovery 과정이 필요 없지만, (그냥 가쉽을 통해 블록을 가져와서 다시 VSCC 부터 시작하면 되니까), A) 블록체인을 업데이트하고 B) 상태DB를 업데이트 하는 도중에 문제가 생겼을 경우에는 특별한 조치를 취해야 한다. 또한 과연 내가 가지고 있는 상태DB가 옳은것인지 체크하는 것과 최신 상태DB의 옳음을 합의 하는 방식 그리고 어떤 체크포인트까지 상태DB가 옳은 것으로 판명됬을 경우, 그 때 까지의 블록체인을 삭제하여 공간 활용성을 높히는 것에 대해서 알아야 할 필요가 있다.
아래 링크는 그런 내용에 관해 좀 더 친절히 설명하며, 고민도 공유하고 있으니, 관심 있는 분들은 참고 하길 바란다.
이 글은 버전을 구분하지 않고 있으며 , 스스로가 공부하면서 메모식으로 두서 없이 정리/수정 하는 내용인지라 글 읽기가 힘들 수 있으며, 암호학 전문가가 아니기에 일부 오류룰 담고 있을 수 있음을 참고 하십시요.
이더리움을 위시한 퍼블릭 블록체인에서는 굳이 네트워크에 붙는 노드들에 대한 신뢰가 필요 없기 때문에, 이 글에서 설명 할 하이퍼레저 패브릭이나 코다에서 신뢰,허가 작업을 하기 위한 복잡한 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. 패브릭에서 토큰은 어떤 자산의 형태이다. (달러같은 화폐로써 정의 될 수도 있고, 자동차, 부동산나 가격이 고정되지 않은 게임 아이템이 될 수도..) 2. 패브릭에서 토큰은 체인코드의 로직 기반으로 만들어 진다. 3. 체인코드의 오너쉽 (이더리움에서 owner 처럼) 는 체인코드가 실행 된 후에 결정 된다. 즉 패브릭 네트워크를 이루는 조직들 중에 하나가 오너쉽을 가질 수 도 있으며, 조직들이 합의한 제3의 대표조직이 가질 수도? 4. 프라이버시 및 보안 문제에 대해서도 최고의 지원을 하며 (금융에 관한 사용처에 주요함) 해당 문제가 덜 중요한 곳에서도 설정을 통하여 운용 가능 하다. 프라이버시 부분에 대한 지원레벨을 낮추면 성능은 높아진다.
UTXO 와 계정
Fabtoken 은 UTXO 식으로 Ledger (정확히는 채널 장부의 상태 데이타베이스 -트랜잭션 개개의 정보는 블록체인에 로깅된다) 에 저장된다. (패브릭 자체가 account 기반이 아니다 보니, 당연하다 싶다.) 즉 트랜잭션 마다 output 이 생성되며 이것을“unspent” 상태라고 한다. 그리고 이 "unspent output" 기반으로 새로운 input 을 발생 시킬 수 있으며 input에 사용된"unspent output" 정보는 줄어드는것이 아닌 삭제되어 새로운 output 정보가 생겨 날 것이다. 이렇게 되면 account 기반에서 철수의 account = 1000 이 있을 경우, 300을 영희에게 전달하는 트랜잭션을 비잔틴이 캡쳐해서 2번 날리면 account = 400 밖에 안남는 문제가 발생하겠지만, UTXO의 경우는 철수-abc = 1000이 삭제되고, 철수-efe = 700이 새롭게 생기기 때문에, 철수-abc를 통한 이중지출은 일어나지 않게 된다.
자 여기에서 그냥 abc, efe 라고만 한다면 이것들이 철수의 자산이란것은 알 수 없을테고, 철수-abc, 철수-efe라고 Ledger에 저장된다면 개인정보에 취약성을 보이게 될 것이다. 패브릭은 이것을 어떻게 해결 했을까?
ZK-snarks
Privacy-preserving implementation using SNARKs, where ZK-snarks are used to offer the privacy properties mentioned before. The difference from the previous case lies on the cryptographic primitives used to achieve the privacy properties and the security assumptions they rely on. SNARK-based implementation of token management is not efficiently compatible with the PKI that Fabric MSPs leverage, but such an implementation can be used to evaluate the performance of implementation (2) on basic token management functionality.
Schnorr proofs
Privacy-preserving implementation that relies on Schnorr proofs [FIXMEREF]. This implementation will offer confidentiality of token ownership, type, and value, at different combinations and levels. Schnorr proofs rely on standard cryptographic assumptions and do not require any special setup, and offer a straightforward and efficient combination with the permissioned nature of Fabric.
sideDB
Privacy-preserving implementation using sideDB, where sideDB functionality is leveraged to offer privacy preserving token management. The value and type of the token can be concealed but the current owner of the asset may remain anonymous or not. Privacy properties offered in this case consider a weaker attacker model than the ones in cases (2) and (3). More specifically, such a construction requires that there is a set of parties that can see the full details of each transaction and ascertain their correctness w.r.t. double spending resistance, while tracking when a specific asset is being exchanged is possible.
예제로 이용된 재료는 이전에 만든 400라인의 go코드로 구현한 하이퍼레저 패브릭 [2]- 블록전파/Gossip 프로토콜 소스(앞으로는 gossip분산 서비스로 지칭)를 사용였는데 간단한 분산 네트워킹 예제이므로 도커/쿠버네이트 공부를 위한 좋은 재료가 될 것 입니다. 이 글은 그 예제의 연속성 상에서 기획된 글이며, 도커/쿠버네이트 내용을 한번 정도 읽어 봤다는 혹은 아래 참고 링크를 공부하면서 진행한다는 가정하에 실습을 위해 정리 한 포스트임을 알려드립니다. 각각의 기술에 대해 구체적으로 알고 싶은 분은 아래 레퍼런스를 참고 하시거나, 추가 구글링을 통해 확인 하십시요.
도커
아래 처럼 Dockerfile 을 만듭니다.
# Start from a Debian image with the latest version of Go installed # and a workspace (GOPATH) configured at /go. FROM golang
# Copy the local package files to the container's workspace. ADD . /go/src/github.com/wowlsh93/hyperledger-fabric-400-gossip
# Build the gossip command inside the container. # (You may fetch or manage dependencies here, # either manually or with a tool like "godep".) RUN go install github.com/wowlsh93/hyperledger-fabric-400-gossip/gossip
위의 도커파일을 가지고 gossip이라는 이름의 도커이미지를 만듭니다.
docker build -t gossip .
기반 이미지는 golang 을 사용하며, 빌드시 현재 프로젝트(예제를 확인하시고 github 에서 가져오세요)를 컨네이너의 /go/src/github.com/wowlsh93/hyperledger-fabric-400-gossip 위치에 복사해 놓습니다. 그리고 소스를 인스톨하여 go/src/gossip 에 실행파일을 위치 시켜 놓습니다.
-p 옵션으로 외부포트:내부포트를 포워딩 하고 -name : 이름은 gossip1 으로 임의로 정합니다. -rm : 옵션으로 컨테이너가 내려가면 자동으로 삭제되게 하고 컨테이너 실행시 /go/bin/gossip -name 127.0.0.1:28000 -ip 127.0.0.1 -port 28000 -leader 명령을 실행해 리더피어 서비스를 시작해 줍니다.
근데 컨테이너를 띄우면 에러가 나는데 컨테이너간 네트워킹을 할 수 없기 때문이며 이를 해결하기 위해 네트워킹 설정을 해야 합니다.
도커 네트워킹
1) 같은 노드에 있는 컨테이너 실습 - host 방식
도커를 처음 설치하면 none, host, bridge 세 가지 종류의 네트워크가 자동으로 설정되는데 none방식(-net=none) 으로 하면 격리된 네트워킹을 갖기 때문에 안되고, -net 옵션으로 host를 주면 모든 컨테이너가 호스트 네트워크를 같이 사용하게 되기 때문에 컨테이너간에 네트워킹이 가능해 집니다.
일단 bridge형식의 네트워크를 하나 추가로 만듭니다. 이름은 gossip-network 로 하구요.
docker network ls
NETWORK ID NAME DRIVER SCOPE
d87103af938c bridge bridge local
659368a11889 composer_default bridge local
17b35b1ad8c5 gossip-network bridge local
541d637a227c host host local
de0e0715ded6 net_basic bridge local
6b6f56779a9a none null local
docker network ls 명령어로 gossip-network 가 만들어진것을 확인합니다.
이제 각 도커 컨테이너를 시작시 옵션으로 -network=gossip-network 로 네트워크 설정을 하고, 불편한 IP주소 대신 gossip1~3처럼 컨네이너 명으로 컨테이너 끼리 통신 하게 할 수 있습니다. 컨테이너 끼리 NAT 테이블 안에서 브리지로 통신하기 때문에 굳이 -p 옵션으로 포트포워딩은 필요 없습니다. 참고로 다시 시작 할 때 컨네이터가 중단된 채 존재하기 때문에 안될 수 있는데 삭제 한 후에 해야합니다. 전체 컨테이너 삭제 명령어는 docker rm `docker ps -a -q` 입니다.
도커 컴포즈는 여러개의 컨테이너를 한방에 시작 시킬때 유용합니다. docker-compose.yaml 파일을 만들어 위의 내용을 작성합니다. 각 서비스를 구분했으며 옵션은 쉽게 이해 될 것입니다. 주의 할 점은 일반 피어는 리더피어가 생성된 후에 떠야하기때문에 depends_on옵션이 추가되었습니다.
docker-compose -p gossipnetwork up -d
-p옵션으로 네트워크를 설정해주며, -d 는 detached mode으로 로그가 안 보이기 때문에. -d 옵션을 빼거나
이제 어디서에나 도커만 있다면 이미지를 다운로드 (이미지 이름이 gossip 에서 wowlsh93/gossip:1 로 변경됨) 받아서 실행 할 수 있습니다.
docker pull wowlsh93/gossip:1
도커(컨테이너)의 장점이 gossip 서비스를 돌리기 위한 어떤 환경(go컴파일러등)이 갖추어져 있지 않더라도, 도커만 있는 곳이라면 실행 할 수 있어서 인프라 설치를 위한 공을 들일 필요가 없는거니까요.
이제 본격적으로 여러 노드에서 gossip분산 서비스를 gossip-network 를 만들어서 실행시켜 보시면 잘 될리가 없습니다. 각 네트워크는 각 노드 내부에서만 활동하기 때문인데요. 외부 네트워크주소를 입력하는 부분도 없잖아요. 당연한거죠. 다른 방법이 필요 합니다.
여기서 다룰 오버레이 네트워크는 여러 머신에서 각각의 네트워크에서 돌아가는 서비스들이 하나의 네트워크에 있는 것 처럼 만들어 주는 방식(docker swarm, hadoop yarn, apache mesos, kubernetes 등) 으로 다양하게 이루어 질 수 있는데, 여기서는 Docker 자체에서 제공하는 방식으로 만들어 볼 예정입니다.
* 사실 우리 프로그램 경우 그냥 실행시 name 옵션에서 정확한 외부 ip 를 입력해주면 잘 동작합니다. 굳이 이딴거(오버레이/스웜/쿠버네티스) 사용 할 필요도 없긴합니다. 실제 하이퍼레저 패브릭도 마찬가지입니다. 도커,쿠버네티스 같은거 사용 안해도 돌아가는 건 상관이 없어요. 각 호스트에서 디펜던시를 따로 다 설치하는 귀찮음이 있긴 하지만 오히려 첨에 실습해보는데는 더 클리어 하구요. 다만 초기 실습이 아니라 일이 되면 여러모로 추상화/자동화가 편하겠지요.
위 그림처럼 각각의 서버에 위치하더라도 하나의 네트워크처럼 작동하도록 하기 위해 이 글에서는 etcd (분산 key-value store로 zookeeper 같은 분산코디네이팅 역할을 함) 라는 것을 사용 할 건데요. 5개의 서버를 활용하여 3개에는 도커를 설치하여 우리가 만든 이미지를 다운로드 해주시고, 2개에는 etcd를 설치합니다. 저 같은 경우는 VirtualBox에 Host-only-adapter 방식으로 5개의 호스트 네트워크를 구성하였습니다. bridge 로 해도 되고 서로 ping 날려서 확인만 되면 됩니다.
얼마전에 블록체인사 CTO분들하고 대화중에 하이퍼레저 패브릭의 합의 알고리즘에 대해서 얘기하다가 "뇌정지"가 온적이 있다. 비트코인 POW부터 POS,DPOS,PBFT,텐더민트식,캐스퍼등에 대한 이해를 거친후에 더 이상은 컨센서스 알고리즘에 대한 공부는 그만 뒀고, (분산네트워킹만이라도 잘하자 싶어서..) 하이퍼레저 패브릭은 그냥 실행-오더링-커밋이지 뭐...라고 평소에 생각했었는데 이번 기회를 통해 정리를 좀 해보려 한다. 알고리즘 자체에 대한 내용이라기 보다는 전체조망이랄까? 주저리주저리 해 볼 생각이다.
거의 유일한 하이퍼레저 패브릭 서적이라고 볼 수 있는데, 이 책을 완독한 후에도 합의 관련된 이해는 할 수 는 없다. 관련 내용이 (구체적으로) 없으니까~ 즉 모든 원흉은 이 책이다. 농담이다.. 400페이지가 넘어가며 정말 많은 내용을 충실히 작성해 놓은 이 책에서 합의알고리즘 내용은 58page에 합의 항목이 나오는데 "하이퍼레저패브릭에서 합의 시스템은 보증-오더링-검증모델 기반하에 플러그인 될 수 있다. 하이퍼레저 패브릭의 오더링 서비스는 합의 시스템을 표현한다." 정도의 표현만 있다. (근데 사실 이게 핵심이자 모든것이기도 하다.)
이제 본격적으로 히스토리를 살펴보자. 하이퍼레저 패브릭 0.6버전에서는 PBFT를 사용했다고 한다. (PBFT에 대한 좀 더 구체적인 것은 여기 참고)
그림 - 하이퍼레저 패브릭 0.6
위의 0.6 도식도와 같이 오더러가 없으며, (컨센서스가 대행함) 보증하는 부분과 커미팅하는 부분이 나뉘지도 않았다. 이 Peer들끼리 아래와 같은 PBFT를 수행했으며 간락하게 설명하면
그림 - PBFT
Pre-prepare단계에서 트랜잭션을 모두 공유하고, Prepare단계에서 각자 Peer들은 트랜잭션을 받았다는 것을 알리며, Commit단계에서 각자 Peer들은 이 트랜잭션에 대해서 합의를 해준다라는 것을 모두에게 알리며 마지막으로 동료Peer들의 합의 상태에 따라서 OK인지 아닌지를 각자 확인해서 Reply 해준다.
이 알고리즘은 보통 2/3 이상의 합의가 있으면 통과이고, 대략 2n^2번의 커뮤케이션이 필요하게 된다. 즉 Peer숫자가 50개만되도 엄청 느려진다는 말이다. 처음 하이퍼레저패브릭을 설계했을때, 허가형블록체인으로 소수의 노드를 대상으로 서비스 한다고 생각 했을 테니 일리가 있지만, 무리가 따랐나보다. 1.0에서는 아키텍쳐가 달라진다. * 하이퍼레저 0.6 PBFT에 대한 좀 더 자세한 설명은 여기 근데 중국어라는게 함정 (간자체로 번역하세요)
그림 - 하이퍼레저 패브릭 1.0 Endorsing - Ordering - Validating 3단계 구조
PBFT식으로 Peer들간에 커뮤니케이션 하는 부분이 너무 느려서 없어지고, Endorsing - Ordering - Validating 3단계 구조를 기반으로 합의 알고리즘이 완성된다. Endorsing 에서는 보증역할을 맡은 Peer들이 트랜잭션에 대해 실행을 하고 결과 값 사인한후에 클라이언트에 돌려준다. 여기서 Peer들간의 커뮤니케이션은 없다. 이런 값을 오더러에게 전달하면 오더러는 트랜잭션에 순서를 매기고, 블록으로 완성 한후 Validator 에게 전달하면 Validatior에서는 보증이 어떻게 되있는지 확인하여 만족 시키면 장부에 기입한다.(좀 더 자세한 설명 여기) 자 이렇게 되면 커뮤니케이션 비용은 확실히 낮아지게 되는데 병목 부분을 생각해보면 3군데 있는데 1. Endorsing 하는 부분에서 체인코드를 실행하는 비용 2. Signning (서명 및 확인)부분이다. 3. 앞으로 말할 Ordering 서비스에 어떤 합의 알고리즘이 들어가냐의 문제이다.
Solo ordering 서비스 (테스팅 목적): 쉽게 이용되도록 만들어진 극히 간단한 서비스로써 프로덕션용은 아니다. 싱글 프로세스로 구성되어 있으며, 하나가 모든 클라이언트들에 대해 서비스 한다. 따라서 사실상 합의라는게 없다. availability 나 scalability에 대해 고려되지 않으며 따라서 이것은 그냥 테스트용~
Kafka기반 오더링 서비스(프로덕션): Pub/Sub구조의 메세지큐 미들웨어인 Kafka 기반의 ordering service 이다. Peer 오더러 클라이언트 코드가 카프카에 대해 상세히 작성되지 않도록 ab.proto 정의로 이것을 추상화 한다.Kafka는 현재 높은 처리량과 고가용성을 요구하지만 byzantine 내결함성은 요구하지 않는 운영 배치에서 선호되는 선택이다.
PBFT 오더링 서비스(지연됨): BFT적인 방식에 의해 메세지들을 나열하고 순서 매이기 위한 구현으로 만들어 질 것이다. (현재 개발중)
즉 위와 같이 구현 할 수 있으며, 현재는 Zookeeper/Kafka기반하여 속도중시/부하분산/복제와리더재선출에 의의한 HA/오더러가 순서매기는데 도움/ 정도의 역할로 외부시스템을 이용해서 이루어져 있는 것이다. 하지만 카프카가 오더러들에 대한 HA까지 보장해주진 않는다. 멀티오더러에 대해서는 node sdk를 사용하는 미들웨어 단에서 잘 작동하는 오더러에 대한 선택을 하는 수동적인 방식이 있는 것 같다. 만약 좀 더 신뢰/오더러에 대한HA를 중시하고 싶으면 BFT계열(PBFT등)를 추가 구현 할 수도 있을것이다. 개인적으로도 허가과정등을 통해 신뢰비용에 대해 어느정도 보완 했다고 판단하기 때문에 Kafka기반이면 충분하지 않나 싶기도 하는데 외부모듈을 무겁게 가져다 사용하는건 문제다. 그리고 Kafka가 하는 역할에 대해 CFT (Crash Fault Tolerance) 같은 용어를 쓰는데, BFT처럼 제대로된(?) 합의 알고리즘이 아니라, 주키퍼-카프카 구성으로 장애에 대한 대처가 가능한 상태에서 오더링을 하기 때문이다. 아무튼 개인적으로는 현재 카프카-주키퍼 오더링 부분과 앞으로 나올 Raft식의 오더링에 대한 행위에 대해서 '합의' 는 POW식의 '신뢰의 합의' 는 아니고 고전적인 분산시스템에서의 내고장 합의를 말하는 것이다. (오더러 부분도 각 조직들에 의해 권한을 분산해서 나누어 갖는 형태가 되면 신뢰의 합의까지 되겠지만 확실하지 않다. 만약 그렇게 까지 하는건 좀 오버인거 같다.)
그림 - 하이퍼레저 패브릭 로드맵
구글링을 해보면 위의 표를 많이 볼 수 있는데 1.3 에서는 RAFT오더러, 1.4에서는 BFT오더러의 구현을 계획했는데 2019년 1월 현재 1.4가 출시된 상황에서 어떻게 되었을까? What’s new in v1.3에는 RAFT오더러에 관련된 내용이 없다. What’s new in v1.4에도BFT 오더러에 대한 내용은 없다. 그럼 2.0버전에서는 어떻게 될까? 프로젝트 현황에 대해 지라 와 제안문서 살펴보니 RAFT / etcd/raft기반으로 개발중인듯 싶은데 비교적 단순한 알고리즘으로 BFT처럼 무겁지 않고 CFT 역할에 그치더라도 1) 카프카-주키퍼에 의존하지 않는 오더링 서비스를 위함. 즉 굳이 외부미들웨어 가져다 복잡하게 설치해서 쓸 필요 있냐 하는 2) 차후에 개발될 BFT 개발을 위한 기반쯤으로 생각하는 듯하다. 카프카-주키퍼 모델에 비해 성능이 어떨지에 대한 예측 및 어떻게 BFT개발을 위한 기반이 될 까에 대해서는 깊이 파보진 않았다.
제안문서 B.II) Raft 는 어떻게 BFT개발의 주춧돌이 되어 줄 수 있나? RAFT는 BFT와 마찬가지로 리더 기반 프로토콜입니다. 잘 검증 된 리더 기반 합의 프로토콜을 통합한다는 것은 Fabric이이 프로토콜 군에 대한 합의 된 (confensus) 플러그인 작성자에게 제공하는 인터페이스 개선에 초점을 맞추는 것을 의미합니다. 그러한 의미에서 Raft에 대한 실험은 우리가 PBFT 기반 오더링 서비스의 토대를 마련하는 데 도움이됩니다. 연장선 상에서 Raft가 CFT 프로토콜 임에도 불구하고 BFT 컨텍스트에서만 의미가 있는 제안 된 구현에서 특정한 결정을 내립니다. 우리는 그것을 의도적으로 수행하여 BFT 기반 서비스로 전환 할 때 Fabric 핵심 변경 사항의 수를 최소로 유지 하려고 합니다. (역주: Kafka 분산복제처리도 리더기반인데..리더가 읽기/쓰기 담당하고 팔로워는 복제만)
결국 Pluggable 하기 때문에 업체에 따라서 자신들이 만들어 추가 할 수도 있다지만 하이퍼레저 패브릭 자체에서도 추가하는데 오래걸리는데 이걸 직접 자신의 입맛에 맞게 요리해서 사용하려는 업체가 얼마나 될런지는 모르겠다. 특히 BFT알고리즘에 대한 논문은 많지만 성공적으로 구현하는것은 굉장히 어렵다.
참고로 BFT계열의 컨센서스 플러거블 라이브러리(BFT-SMART)도 있다. 현재 정식버전으로 들어 간것은 아니며 추후 RAFT 이후에 BFT계열로 SBFT가 들어갈지, BFT-SMART가 들어갈지 모르겠다. BFT-SMART는 논문상에 10,000TPS 급의 성능을 보여주며, SBFT는 아직 테스팅된게 없는것으로 알고 있다.
결론 )
개인적으로는 카프카 대체제로는 RAFT로 충분하고 BFT계열은 간단하든 복잡하는 오버스펙이라 시작할맘도 없을 거 같습니다.참고로 JP모건 애들이 만드는 콘소시엄체인은 RAFT랑 IstabulBFT 라는것을 쓰는데 패브릭도 BFT계열을 겨우 오더링하는데 사용 할 바엔 E-O-V 프로세스를 폐기하는게 낫다고 봅니다.아마 거기 아키텍트도 똑같은 생각하고 있을듯..ㅎㅎ
가. Fabric-CA 를 이용해서 각 조직의 admin msp 를 생성한다. 나. 각 조직의 admin은 조직이 가지고 있는 각 Peer의 msp 를 생성한다. ---- 여기까지가 8번 -----
인프라 (채널등) 구성하고 시작하기 다. genesis.block 을 각 조직의 공개키를 가지고 생성하여 오더러를 구동한다. 라. 각 peer 들을 구동한다. 마. 채널을 생성한다. 바. 채널에 peer들을 참여시킨다. 사. 앵커피어 업데이트 ------ 여기까지가 15번 ----
체인코드 설치 및 읽고,쓰기 아. 각 Peer에 체인코드 설치 자. 하나의 peer 에서 체인코드 인스턴스화 차. 분산원장 읽고/쓰기
설치도우미들
- FABRIC_CFG_PATH 설정 : core.yaml , configtx 관련요소를 실행시키기위한 패스정보. - configtx.yaml: 컨소시엄정보,조직정보,채널정보,오더러설정,제네시스블록,앵커피어등을 생성하기위한 설정파일이다. - core.yaml : peer를 실행시키기 위한 설정파일을 담고 있다. - orderer.yaml : orderer 를 실행시키기 위한 설정파일을 담고 있다.
퍼블릭 블록체인 (이더리움) 철학은 화폐의 이동에 대한 "신뢰 비용"을 줄이기 위해서라면 콘소시엄 블록체인 (하이퍼레저 패브릭) 철학은 조직간의 "신뢰 비용" 을 줄이기 위해서이다.(코인이 없으며 굳이 넣을 수도있겠지만 그게 의미 있는지에 대해 매우 회의적입니다. 퍼블릭체인과의 인터체이닝도 마찬가지 개념에 대한 변화가 심하며 앞으로도 계속 변화 할 것이기 때문에 쉽사리 규정짓기 힘들기도 합니다만..)
즉 하이퍼레저 패브릭을 공부하거나 먼가를 만드는 목적이 일반인들을 위해서 DApp을 만들려고 한다면 이상한거다. 또한 무슨 보안을 위해서라든지 위변조 방지를 위해서라든지 이런 구실을 만들어서 장부에 저장되는 어떤 기록에 대한 주체가 하나인 경우임에도 하이퍼레저패브릭로 해야 한다고 주장하지 말자. 보안,위변조방지,분산저장으로인한안전성등은 도구 혹은 부수효과 에 불과하다. 크나큰 낭비가 될 수 있다.
하이퍼레저 패브릭을 적용하기 위해서는 먼저 해당 분야에 "조직" 이라는 네트워크가 존재해야하며, 그 "조직" 간에 어떠한 신뢰 비용이 생기는지 대략적으로 라도 파악 할 수 있어야 한다. (장부에 담겨질 내용은 이 다음 얘기) 그런 후에 하이퍼레저패브릭이라는 나름 거대한 인프라를 구축하고 관리하는데 드는 비용보다 그 비용(당장의 신뢰비용 + 미래의 기대비용) 이 대단히 크다고 생각 할 경우, 도입 할 여지가 생기게 된다.
따라서 하이퍼레저패브릭을 하려는 업체나 개인은 그 조직들에 대한 도메인을 잘 알아야하며,(준비를 해야하며) 그 조직을 설득 할 수 있는 힘이 있어야 한다. 이 얘기는 반대로 조그마한 스타트업이나 개인이 공부하기에는 낭비가 될 수가 있다는 사실을 염두해 두어야 한다. (물론 내부 톱니바퀴를 이루는 p2p,보안,컨센서스,분산인프라 등에 대한 이론 공부는 피가되고 살이 될 수 있다. 문제는 트레이드 오프)
