[HyperLedger] Fabric 네트워크의 구성 방식

1. 블록체인 네트워크란?

블록체인 네트워크는 애플리케이션에 원장(Ledger) 및 스마트 계약(Smart Contract) 서비스를 제공하는 기술 인프라이다.

주로 스마트 계약은 원장 사본에 불변하게 기록되는 트랜잭션을 생성하는 데 사용된다.

 

대부분의 경우 여러 조직이 체인코드에서 트랜잭션이 호출되고 채널이 원래 구성될 때 동의한 일련의 정책에 따라 권한이 결정되는 채널을 형성한다.

정책은 조직의 동의에 따라 변경될 수 있다.

네트워크의 예시는 위와 같다.

 

2. 네트워크 생성

네트워크 또는 채널 생성의 첫 번째 단계는 구성에 동의하고 정의하는 것이다.

 

"구성 블록"으로 알려진 블록에 채널 구성(channel configuration)은 조직 R1, R2 및 R0에서 동의했다는 것이 포함된다.

구성 블록이 존재하면  채널에  물리적으로 결합된 구성 요소가 없더라도 채널이 논리적으로 존재한다고 말할수 있다.

이 구성 블록에는 구성 요소에 가입하고 채널에서 상호 작용할 수 있는 조직의 기록과 의사 결정 및 특정 결과에 도달하는 방법에 대한 구조를 정의하는 "정책"이 포함된다.

피어와 애플리케이션은 네트워크에서 중요한 행위자이지만 채널에서의 동작은 다른 어떤 요소보다 채널 구성 정책에 의해 더 많이 결정된다.

 

CA : Certificate Authority

관리자의 ID는 각 조직과 연결된 인증기관(CA)에서 생성해야 한다.

 

3. 인증 기관

인증 기관은 구성 요소를 조직에 속하는 것으로 식별하는데 사용할 수 있는 X.509 인증서를 제공하기 때문에 네트워크에서 중요한 역할을 한다. X.509에는 공개키, 디지털 서명 및 CA에 관한 정보가 들어가고 이를 개인키로 해독하여 볼 수 있다.

 

(1) 식별 기능

블록체인 네트워크의 다양한 구성 요소는 인증서를 사용하여 특정 조직의 구성원임을 서로 식별한다.

그렇기 때문에 일반적으로 블록체인 네트워크를 지원하는 하나 이상의 CA가 존재한다.

조직마다 다른 CA를 사용하는 경우가 많다.

구성원 조직에 대한 인증서 매핑은 MSP라는 구조를 통해 이루어진다.

MSP는 루트 CA 인증서에 연결된 MSP를 생성하여 조직을 정의하고 구성 요소와 ID가 루트 CA에서 생성되었음을 식별한다.

그런 다음 채널 구성은 정책을 통해 특정 권한을 조직에 할당할 수 있다.

 

(2) 트랜잭션 생성 및 유효성 검사

X.509 인증서는 클라이언트 애플리케이션에서 트랜잭션 제안 및 디지털 서명 트랜잭션에 대한 스마트 계약 트랜잭션 응답에 사용된다.

결과적으로 원장 사본을 호스팅 하는 네트워크 노드는 원장에 트랜잭션을 수락하기 전에 트랜잭션 서명이 유효한지 확인한다.

 

4. 채널에 노드 가입

피어는 원장 및 체인코드를 호스팅하기 때문에 네트워크의 기본 요소이며 채널에서 거래하는 조직이 채널에 연결하는 물리적 지점 중 하나이다.

오더러 서비스는 애플리케이션에서 승인된 트랜잭션을 수집하고 이를 트랜잭션 블록으로 정렬한 후 채널의 모든 피어 노드에 배포한다.

각 커미팅 피어에서 트랜잭션이 기록되고 원장의 로컬 사본이 적절하게 업데이트된다.

R1의 피어인 P1과 R2의 피어인 P2는 R0의 오더러 서비스인 O와 함께 채널에 가입한다.

각 조직에 속한 노드에는 해당 조직과 연결된 인증 기관에서 만든 X.509 인증서가 있다.

P1의 인증서는 CA1에 의해 생성되고 P2의 인증서는 CA2에 의해 생성되는 식이다.

 

채널의 모든 노드는 각 새 블록으로 업데이트될 채널 L1의 원장 사본을 저장한다.

오더러 서비스에는 원장의 블록체인 부분만 포함되며 상태 데이터 베이스는 포함되지 않는다.

 

5. 체인코드 설치, 승인 및 커밋

체인코드는 피어에 설치된 다음 채널에서 정의 및 커밋된다.

Fabric에서 피어 조직이 원장과 상호 작용하는 방식을 정의하는 비즈니스 놀리는 스마트 컨트랙트에 포함되어 있다.

체인코드라고 하는 스마트 컨트랙트가 포함된 구조는 해당 피어에 설치되고 해당 피어 조직의 승인을 받고 채널에 커밋된다.

이러한 방식으로 피어에서 물리적으로 호스팅 되지만 채널에는 논리적으로 호스팅 되는 체인코드를 고려할 수 있다.

오더러 노드는 일반적으로 트랜잭션을 제안하지 않으므로 주문 서비스에는 체인코드가 설치되지 않는다.

체인코드를 설치, 승인 및 커밋하는 프로세스를 체인코드의 "라이프 사이클"라고 한다.

 

체인코드 정의 내에서 제공되는 가장 중요한 정보는 보증 정책이다.

다른 조직이 원장 사본에 트랜잭션을 승인하기 전에 어떤 조직이 트랜잭션을 승인해야 하는지 설명한다.

보증 정책은 사용 사례에 따라 채널의 구성원 조합으로 설정할 수 있다.

 

6. 채널에서 애플리케이션 사용

스마트 컨트랙트가 커밋된 후 클라이언트 애플리케이션을 사용하여 Fabric 게이트웨이 서비스를 통해 체인코드에서 트랜잭션을 호출할 수 있다.

트랜잭션 제안은 트랜잭션 응답을 생성하는 데 사용하는 체인코드에 대한 input 역할을 한다.

피어 노드인 R1과 R2가 채널에 완전히 참여하고 있음을 알 수 있다.

그들의 애플리케이션은 스마트 컨트랙트 S5를 통해 원장 L1에 액세스 하여 보증 정책에 지정된 조직임을 보증하고 원장에 기록되는 트랜잭션을 생성할 수 있다.

 

7. 여러 채널에 결합

이전과 마찬가지로 CC2가 생성되었으므로 채널에 연결된 구성요소가 없더라도 채널이 논리적으로 존재한다고 말할 수 있다.

 

(1) 구성요소를 새 채널에 가입

이 채널에는 C1의 원장과 완전히 분리된 원장인 L2가 있다.

R2가 두 채널에 가입되어 있어도 두 채널이 완전히 별개로 나눠진다.

C1과 C2 모두 동일한 오더링 서비스 조직인 R0가 가입되어 있지만 서로 다른 오더러 노드가 각 채널에 서비스를 제공한다.

두 채널이 서로 구별되지만 "네트워크"로 결합된 구성 요소로 생각할 수 있다.

이러한 의미에서 "네트워크"는 특정 조직의 관점에서 내가 구성원인 모든 채널과 내가 소유한 모든 구성요소로 존재하는 것으로 볼 수 있다.

 

8. 기존 채널에 조직 추가

채널이 성숙해지면 그 구성도 성숙해져 채널에 변화가 오는 것은 당연하다.

조직을 추가할 때 채널을 수정하는 것보다 채널에 새 조직을 추가하는 것이 일반적이다.

 

권한 및 사용 권한은 채널 수준에서 정의된다.

조직이 한 채널의 관리자라고 해서 다른 채널의 관리자가 되는 것은 아니다.

각 채널은 고유한 관리 영역이며 제공하는 사용 사례에 맞게 완전히 사용자가 지정할 수 있다.

조직 추가하는 프로세스

(1) 새 조직의 권한과 역할을 정한다. 이러한 권한의 전체 범위는 R3가 C1에 추가되기 전에 동의해야 한다.

(2) 결정이 반영되도록 관련 체인코드를 포함하여 채널을 업데이트한다.

(3) 조직은 피어 노드를 채널에 가입시키고 참여를 시작한다.

 

채널 구성을 업데이트하면 다시 업데이트될 때까지 채널 구성 역할을 하는 새로운 구성 블록 CC1.1이 생성된다.

구성이 변경되더라도 채널은 여전히 존재하고 P1과 P2는 여전히 채널에 가입되어 있기 때문에 다시 추가할 필요는 없다.

 

9. 새로 가입한 채널에 기존 구성 요소 추가

 

C2에 결합된 P3를 C1에 추가한다. 이렇게 하면 P3는 C1의 원장인 L1을 가져온다.

R3는 R1 및 R2와 동등한 권한을 받았다고 가정해 보자.

체인코드 S5가 R3를 포함하도록 채널에서 재정의되고 재승인되었기 때문에 R3는 S5를 설치하고 거래를 시작할 수 있다.

A3도 이제 C1에서 트랜잭션을 호출할 수 있다.

 

---

출처 - https://hyperledger-fabric.readthedocs.io/en/release-2.5/