초보자를 위한 하이퍼레저 패브릭

엔터프라이즈를 위한 블록체인 플랫폼

안녕하세요, 독자 여러분, 제 이름은 Nikolai Nefedov입니다. 저는 IBM 기술 전문가입니다. 이 기사에서는 블록체인 플랫폼인 Hyperledger Fabric을 소개하고자 합니다. 이 플랫폼은 엔터프라이즈급 비즈니스 애플리케이션(엔터프라이즈 클래스)을 구축하기 위한 것입니다. 기사의 수준은 IT 기술에 대한 기본 지식을 갖춘 준비되지 않은 독자를 위한 것입니다.

Hyperledger Fabric은 Linux Foundation의 컨소시엄인 Hyperledger 오픈 소스 프로젝트의 분기 중 하나인 오픈 소스 프로젝트입니다. Hyperledger Fabric은 원래 Digital Assets와 IBM에서 출시했습니다. Hyperledger Fabric 플랫폼의 주요 기능은 기업 애플리케이션에 중점을 둔 것입니다. 따라서 플랫폼은 빠른 거래 속도와 낮은 비용, 모든 참가자의 식별을 고려하여 개발되었습니다. 이러한 이점은 거래 확인 서비스를 분리하고 분산 레지스트리의 새로운 블록을 형성하고 인증 기관을 사용하고 참여자를 승인함으로써 달성됩니다.

내 기사는 대학에 입학하는 학생들을 등록하기 위한 시스템 프로젝트를 설명하는 Hyperledger Fabric에 대한 일련의 기사 중 일부입니다.

Hyperledger Fabric의 일반 아키텍처

Hyperledger Fabric은 네트워크 노드에 설치된 다양한 기능 구성 요소로 구성된 분산형 블록체인 네트워크입니다. Hyperledger Fabric 구성 요소는 DockerHub에서 무료로 다운로드할 수 있는 Docker 컨테이너입니다. Hyperledger Fabric은 Kubernetes 환경에서도 실행할 수 있습니다.

스마트 계약(Hyperledger Fabric 컨텍스트의 체인코드)을 작성하기 위해 Golang을 사용했습니다(Hyperledger Fabric을 사용하면 다른 언어를 사용할 수 있지만). 맞춤형 애플리케이션을 개발하기 위해 우리의 경우 Node.js를 해당 Hyperledger Fabric SDK와 함께 사용했습니다.

노드는 비즈니스 로직(스마트 계약) - 체인코드를 실행하고 분산 레지스트리(원장 데이터)의 상태를 저장하며 기타 플랫폼 시스템 서비스를 실행합니다. 노드는 논리적 단위일 뿐이며 동일한 물리적 서버에 서로 다른 노드가 존재할 수 있습니다. 훨씬 더 중요한 것은 노드가 그룹화되는 방식(신뢰할 수 있는 도메인)과 연결된 블록체인 네트워크의 기능입니다.

일반적인 아키텍처는 다음과 같습니다.

그림 1. Hyperledger Fabric의 일반 아키텍처

사용자 애플리케이션(Submitting Client)은 사용자가 블록체인 네트워크에서 작업하는 애플리케이션입니다. 작동하려면 인증을 거쳐 네트워크에서 다양한 종류의 작업에 대한 적절한 권한이 있어야 합니다.

피어(노드)는 여러 가지 역할을 합니다.

• Endorsing Peer는 트랜잭션 실행을 시뮬레이션하는 노드입니다(스마트 계약 코드 실행). 스마트 계약을 검증하고 실행한 후 노드는 실행 결과를 서명과 함께 클라이언트 애플리케이션에 반환합니다.
• Ordering Service는 여러 노드의 분산 서비스로 분산 원장의 새로운 블록을 형성하고 트랜잭션 실행을 위한 시퀀스를 생성하는 데 사용됩니다. Ordering Service는 레지스트리에 새 블록을 추가하지 않습니다(더 나은 성능을 위해 Committing Peers로 이동됨).
• 커미팅 피어 - 분산 레지스트리를 포함하고 레지스트리에 새 블록을 추가하는 노드(주문 서비스에 의해 형성됨). 모든 커밋 피어에는 분산 원장의 로컬 복사본이 포함됩니다. Committing Peer는 새 블록을 로컬에 추가하기 전에 유효성을 위해 블록 내의 모든 트랜잭션을 확인합니다.

보증 정책은 거래의 유효성을 확인하기 위한 정책입니다. 이러한 정책은 트랜잭션이 유효한 것으로 인식되기 위해 스마트 계약을 실행해야 하는 필수 노드 집합을 정의합니다.

분산 레지스트리(Lerger)는 WorlldState(State DataBase라고도 함)와 BlockChain의 두 부분으로 구성됩니다.

블록체인은 분산 원장 개체에 발생한 모든 변경 사항의 기록을 저장하는 블록 체인입니다.

WorlldState는 모든 분산 레지스트리 개체의 현재(극단) 값을 저장하는 분산 레지스트리 구성 요소입니다.

WorldState는 기본 버전의 데이터베이스입니다. LevelDB 또는 더 복잡한 CouchDB는 키-값 쌍을 포함합니다. 예: 이름 - Ivan, 성 - Ivanov, 시스템 등록 날짜 - 12.12.21/17.12.1961/XNUMX, 날짜 출생 - XNUMX년 XNUMX월 XNUMX일 등 WorldState 및 분산 원장은 지정된 채널의 모든 구성원에서 일관성이 있어야 합니다.

Hyperledger Fabric은 모든 참가자를 알고 인증하는 네트워크이므로 여기에는 전용 인증 기관인 CA(Certification Authority)가 사용됩니다. CA는 X.509 표준 및 공개 키 인프라(PKI)를 기반으로 작동합니다.

멤버십 서비스는 객체가 특정 조직 또는 채널에 속하는지 회원이 확인하는 서비스입니다.

트랜잭션은 대부분의 경우 분산 원장에 새 데이터를 기록하는 것입니다.
채널 또는 스마트 계약 생성을 위한 트랜잭션도 있습니다. 트랜잭션은 사용자 애플리케이션에 의해 시작되고 분산 원장에 대한 쓰기로 끝납니다.

채널(Channel)은 블록체인 네트워크에서 둘 이상의 참가자로 구성된 폐쇄된 서브넷으로, 제한적이지만 알려진 참가자 범위 내에서 기밀 거래를 수행하도록 설계되었습니다. 채널은 참가자, 분산 원장, 스마트 계약, 주문 서비스, WorldState에 의해 결정됩니다. 각 채널 구성원은 채널에 액세스할 수 있는 권한이 있어야 하며 다양한 종류의 거래를 수행할 수 있는 권한이 있어야 합니다. 승인은 멤버십 서비스를 사용하여 수행됩니다.

일반적인 트랜잭션 실행 시나리오

다음으로 우리 프로젝트의 예를 사용하여 트랜잭션을 실행하는 일반적인 시나리오에 대해 이야기하고 싶습니다.

내부 프로젝트의 일환으로 대학에 입학하는 학생을 등록하고 기록하도록 설계된 Hyperledger Fabric 네트워크를 만들었습니다. 우리의 네트워크는 대학 A와 대학 B가 소유한 두 조직으로 구성되어 있습니다. 각 조직에는 클라이언트 응용 프로그램과 자체 Committing 및 Endorsing Peer가 포함되어 있습니다. 또한 일반적인 주문 서비스, 회원 서비스 및 인증 기관 서비스를 사용합니다.

1) 거래 개시

Hyperledger Fabric SDK를 사용하는 사용자 애플리케이션은 트랜잭션 요청을 시작하고 스마트 계약을 통해 노드에 요청을 보냅니다. 요청은 분산 원장(Ledger)에서 변경하거나 읽을 수 있습니다. 대학생 회계 시스템의 테스트 구성의 예를 고려하면 클라이언트 응용 프로그램은 호출된 스마트 계약의 보증 정책에 포함된 대학 A와 B의 노드에 트랜잭션 요청을 보냅니다. 노드 A는 신입생을 등록하는 대학에 위치한 노드이고, 노드 B는 다른 대학에 위치한 노드입니다. 트랜잭션이 분산 원장에 저장되기 위해서는 비즈니스 로직에 따라 트랜잭션을 승인해야 하는 모든 노드가 동일한 결과로 성공적으로 스마트 계약을 실행해야 합니다. 노드 A의 사용자 애플리케이션은 Hyperledger Fabric SDK 도구를 사용하여 Endorsement 정책(승인 정책)을 수신하고 트랜잭션 요청을 보낼 노드를 찾습니다. 분산 원장에 특정 데이터를 읽거나 쓰기 위해 특정 스마트 컨트랙트(체인코드 함수)를 호출(호출)하라는 요청입니다. 기술적으로 클라이언트 SDK는 트랜잭션 매개변수가 있는 객체를 전달하는 API의 해당 기능을 사용하고 클라이언트 서명을 추가하고 gRPC를 통해 프로토콜 버퍼를 통해 이 데이터를 적절한 노드(보증 피어)로 보냅니다.

그림 2. 트랜잭션 개시

2) 스마트 컨트랙트 실행

트랜잭션 수행 요청을 받은 노드(Endorsing Peers)는 클라이언트 서명을 확인하고 모든 것이 정상이면 요청 데이터가 있는 개체를 가져오고 스마트 계약 실행 시뮬레이션을 실행합니다(체인코드 기능). 이 데이터로. 스마트 계약은 거래의 비즈니스 논리, 특정 조건 및 지침 집합입니다(이 경우 학생 수표, 신입생인지, 이미 등록되었는지, 나이 확인 등). 스마트 계약을 실행하려면 WorldState의 데이터도 필요합니다. Endorsing 피어에 대한 스마트 계약 시뮬레이션의 결과로 두 개의 데이터 세트(읽기 세트 및 쓰기 세트)를 얻습니다. 읽기 세트 및 쓰기 세트는 원래 및 새 WorldState 값입니다. (신규 - 스마트 계약을 시뮬레이트하여 얻은 의미에서).

그림 3. 스마트 컨트랙트 실행

3) 클라이언트 애플리케이션에 데이터 반환

스마트 계약의 시뮬레이션 후 Endorsing Peer는 초기 데이터와 시뮬레이션 결과, 인증서로 서명된 RW 세트를 클라이언트 애플리케이션에 반환합니다. 이 단계에서는 분산 원장에 변경 사항이 없습니다. 클라이언트 응용 프로그램은 Endorsing Peer의 서명을 확인하고 전송된 원본 트랜잭션 데이터와 반환된 데이터를 비교합니다(즉, 트랜잭션이 시뮬레이션된 원본 데이터가 손상되었는지 확인). 트랜잭션이 레지스트리에서 데이터를 읽기 위한 것일 경우 클라이언트 애플리케이션은 그에 따라 필요한 읽기 세트를 수신하고 이 트랜잭션은 일반적으로 분산 레지스트리를 변경하지 않고 성공적으로 완료됩니다. 레지스트리의 데이터를 변경해야 하는 트랜잭션의 경우 클라이언트 애플리케이션은 추가로 Endorsing 정책이 구현되었는지 확인합니다. 클라이언트 애플리케이션이 Endorsement Policy 실행 결과를 확인하지 않을 수 있지만, 이 경우 Hyperledger Fabric 플랫폼은 레지스트리에 트랜잭션을 추가하는 단계에서 노드(Comitting Peers)의 정책 확인을 제공합니다.

그림 4. 클라이언트 애플리케이션에 데이터 반환

4) Ordering Peer에게 RW 세트 보내기

클라이언트 애플리케이션은 관련 데이터와 함께 트랜잭션을 주문 서비스로 보냅니다. 여기에는 RW 세트, 보증 피어의 서명 및 채널 ID가 포함됩니다.

주문 서비스 - 이름에 따라 이 서비스의 주요 기능은 들어오는 트랜잭션을 올바른 순서로 구축하는 것입니다. 뿐만 아니라 분산 레지스트리의 새 블록을 형성하고 새로 생성된 블록을 모든 커밋 노드로 보장하여 분산 레지스트리(커밋 피어)를 포함하는 모든 노드에서 데이터 일관성을 보장합니다. 동시에 주문 서비스 자체는 레지스트리를 변경하지 않습니다. 주문 서비스는 시스템의 중요한 구성 요소이므로 여러 노드의 클러스터입니다. Ordering Service는 트랜잭션의 유효성을 검사하지 않고 단순히 특정 채널 ID로 트랜잭션을 수락하고 들어오는 트랜잭션을 특정 순서로 정렬하고 분산 원장의 새로운 블록을 형성합니다. 하나의 Ordering Service는 동시에 여러 채널에 서비스를 제공할 수 있습니다. Ordering Service에는 올바른(변경되지 않은) 트랜잭션 대기열을 유지 관리하는 Kafka 클러스터가 포함되어 있습니다(포인트 7 참조).

그림 5. Ordering Peer에 RW 세트 전송

5) 생성된 블록을 Committing Peer에게 전송

Ordering Service에서 형성된 블록은 모든 네트워크 노드에 브로드캐스팅됩니다. 새로운 블록을 받은 각 노드는 Endorsing Policy 준수 여부를 확인하고 모든 Endorsing Peer가 스마트 계약 시뮬레이션 결과 동일한 결과(Write Set)를 받았는지 확인하고 원래 값이 변경됨(즉, - 읽기 세트 - 트랜잭션 시작 이후 스마트 계약이 WorldState에서 읽은 데이터). 모든 조건이 충족되면 트랜잭션이 유효한 것으로 표시되고 그렇지 않으면 트랜잭션이 유효하지 않음 상태를 받습니다.

그림 6. 생성된 블록을 Committing Peer에게 전송

6) 레지스트리에 블록 추가

각 노드는 분산 원장의 로컬 사본에 트랜잭션을 추가하고 트랜잭션이 유효하면 WorldState(현재 상태)에 각각 Write Set을 적용하고 트랜잭션의 영향을 받은 객체의 새로운 값을 기록합니다. . 트랜잭션이 유효하지 않은 토큰을 받은 경우(예: 동일한 블록 내에서 동일한 객체를 가진 두 개의 트랜잭션이 있는 경우 원래 값이 다른 트랜잭션에 의해 이미 변경되었기 때문에 트랜잭션 중 하나는 유효하지 않습니다. ). 이 트랜잭션도 유효하지 않은 마커로 분산 원장에 추가되지만 이 트랜잭션의 Write Set은 WorldState의 현재 상태에 적용되지 않으므로 트랜잭션에 참여하는 객체를 변경하지 않습니다. 그 후 트랜잭션이 분산 원장에 영원히 추가되었다는 알림과 트랜잭션의 상태, 즉 유효 여부 ...

그림 7. 레지스트리에 블록 추가

주문 서비스

주문 서비스는 해당 ZooKeeper 노드가 있는 Kafka 클러스터와 주문 서비스 클라이언트와 Kafka 클러스터 사이에 있는 주문 서비스 노드(OSN)로 구성됩니다. Kafka 클러스터는 분산된 내결함성 흐름(메시지) 관리 플랫폼입니다. Kafka의 각 채널(주제)은 새 레코드 추가만 지원하는 변경 불가능한 레코드 시퀀스입니다(기존 레코드 삭제 불가). 토픽 구조의 그림은 다음과 같습니다. 블록체인 플랫폼을 구축하는 데 사용되는 것은 Kafka의 이 속성입니다.

kafka.apache.org에서 가져옴

• 그림 8. 주문 서비스 주제 구조*

유용한 링크

Youtube - Hyperledger 프로젝트로 비즈니스용 블록체인 구축
하이퍼레저 패브릭 문서
하이퍼레저 패브릭: 허가된 블록체인을 위한 분산 운영 체제

감사의 말

기사를 준비하는 데 도움을 준 동료들에게 깊은 감사를 표합니다.
니콜라이 마리나
이고르 카포프
드미트리 고르바초프
알렉산더 젬초프
예카테리나 구세바

출처 : habr.com