하이퍼레저 패브릭 - Hyperledger Flow

• 인증 부분, 서명 부분
• 하이퍼레저 패브릭에서 인증은 MSP(Membership Service Provider)을 이용하여 이루어짐.
• Peer, Orderer, CA 등은 모두 각자의 MSP를 가지고 있음. (local MSP)
• MSP를 통해서 채널(Channel)의 관리 권한이나 접근 권한을 관리 할 수 있다. (channel MSP)
• PKI(공개키 기분 구조)를 통해 인증하며, 파일 시스템으로 구성되어 있음
 
1. 사용자가 애플리케이션을 통해 트랜잭션 생성 요청을 보낸다.
2. 사용자는 블록체인 네트워크에서 인증서를 발급받아 클라이언트 애플리케이션에 제공한다.
3. 클라이언트 애플리케이션은 해당 사용자의 개인키를 사용하여 디지털 서명을 생성한다.
4. 서명이 포함된 트랜잭션을 생성한 클라이언트 애플리케이션은 이를 네트워크의 피어 노드에 전송한다.
5. 피어 노드는 해당 트랜잭션의 유효성을 검증한다. 서명이 검증되지 않은 트랜잭션은 블록체인 네트워크에 추가되지 않는다.
6. 검증된 트랜잭션은 블록체인 네트워크에 추가된다.
 
 

• 암, 복호화
• 일반적으로 암복호화는 Fabric 내부에서 일어나지 않고, 클라리언트 단에서 이루어진다.
• 예를 들면, 클라이언트에서 대칭키 암호화 알고리즘을 사용하여 암호화된 데이터를 트랜잭션에 넣어 전송한다.
 

• 합의 과정
• 하이퍼레저 패브릭에는 다양한 합의 알고리즘이 있는데, MDL에서는 Raft 방식을 이용한다.
• Raft 합의 알고리즘에서는 리더와 팔로워로 역할이 나뉜다.
• 리더는 클러스터에서의 모든 로그를 저장하고 복제하여 다른 노드(팔로워)들에게 주기적으로 전달하여 동기화를 유지시킨다.
• 로그에 이상이 생기거나, 과반수 이상의 노드에게 응답을 받지 못하거나, 시간초과가 일어날 경우 팔로워 중 하나가 Election(선거)을 진행한다.
• 이 때 노드들은 투표를 할 수 있고, 가장 많은 투표를 받은 노드가 리더로 선발이 된다.
 

• 트랜잭션 Query, Invoke



1. 애플리케이션은 Peer(P1)와 연결한다.
2. Peer은 체인코드를 호출하여 제안 응답(proposal response)을 생성한다.
3. 애플리케이션은 제안 응답을 수신한다. → Query의 경우, 프로세스는 여기까지가 끝이다. (밑은 Update의 경우 수행)
4. 애플리케이션은 트랜잭션을 작성하여 Orderer에게 주문을 보낸다. Orderer는 모든 Peer에게 트랜잭션을 배포한다. Peer은 Ledger에 커밋하기 전 트랜잭션의 유효성을 검사한다.
5. Ledger가 성공적으로 업데이트 되면 Peer은 애플리케이션에게 업데이트 완료를 나타내는 이벤트를 생성한다.
 
• 업데이트 트랜잭션은 쿼리 트랜잭션에서 두 가지의 추가 단계(4, 5)가 있다
• Query때와 달리 개별 Peer가 Ledger Update를 수행할 수 없다(합의 과정이 필요함). Orderer를 사용함으로써 합의 프로세스를 진행할 수 있다.

• fail 또는 오류 발생시 처리 과정
• 트랜잭션의 오류 발생 원인에 따라 처리 과정이 모두 다르다.
• 그 중 블록이 생성되지 않을 때와, 블록이 생성된 후 status가 fail인 상태로 나뉜다.
• 블록이 생성되지 않을 때 (request가 정상적이지 않을때 (체인코드 key 중복, parameter 부족 등)
• Fabric에서 에러 메세지를 반환한다. 블록이 생성되지 않으므로, 아무 일도 일어나지 않는다.
• 블록이 생성될 때(체인코드 설치 시 정책 미충족, MVCC 에러 등)
• 블록이 생성되었지만, 어떤 원인으로 블록의 status / validation 코드가 정상이 아닐 때가 있다.
• 이 블록은 유효하지 않은 블록으로 간주되며, 다른 Peer들에게 해당 블록을 전파시키지 않는다.
• Peer들 중 이 유효하지 않은 블록를 참조하는 노드가 있다면, 참조를 삭제하고 블록 동기화 작업을 진행한다.

Orderer와 Peer의 Detail Process

1. Proposal(제안)

1. 애플리케이션은 endorsement(승인)을 위해 필요한 각 Peer 집합에 트랜잭션 Proposal을 생성한다.

2. 각 endorsing Peer은 트랜잭션 Proposal을 사용하여 체인코드를 독립적으로 실행하여 애플리케이션에 보낸다. 이 업데이트는 Ledger에 적용시키지는 않는다.

3. 애플리케이션이 Proposal 응답을 수신하면 첫 단계는 완료된다.

1. 트랜잭션을 블록으로 주문 및 패키징
• 이 단계에서 애플리케이션 클라이언트는 승인된 트랜잭션 Proposal 응답을 포함하는 트랜잭션을 Ordering Service 노드에 제출한다.
• Ordering Service는 3단계에서 최종 유효성 검사 및 커밋을 위해 궁극적으로 채널의 모든 Peer에게 배포될 트랜잭션 블록을 생성한다.
• Orderer 노드는 여러 애플리케이션 클라이언트로부터 동시에 트랜잭션을 수신한다. → Orderer는 제출된 트랜잭션 배치를 정렬하고, 블록으로 패키징한다.
• 블록은 Orderer의 Ledger에 저장되고 채널에 참여한 모든 Peer들에게 배포된다.

1. 유효성 검사 및 커밋
• 트랜잭션 WorkFlow의 세번째 단계는, Orderer에서 Peer로, Ledger에 커밋될 수 있는 블록의 배포 및 유효성 검사를 포함한다.
• Orderer은 연결된 모든 Peer에게 블록을 배포한다. 모든 Peer가 Orderer에게 연결될 필요는 없다 → Gossip 프로토콜을 사용
• 채널의 각 Peer은 블록의 각 트랜잭션을 검증하여 조직의 Peer가 승인했는지, 승인이 일치하는지, 최근에 커밋됐는지 확인한다.
• 검증이 성공적으로 완료하면, 각 Peer들은 자신의 Ledger 사본에 블록을 추가한다. 프로세스가 완료되면, 연결된 애플리케이션에 트랜잭션이 처리되었음을 알릴 수 있다.