[HYPERLEDGER FABRIC v1.1]Key Concepts

Introduction

소개

Hyperledger Fabric은 높은 수준의 비밀성, 회복력, 유연성과 확장성을 가진 모듈러한 아키텍쳐가 기반이 된 분산 원장 플랫폼입니다.

각기 다른 요소의 추가 기능과 경제 생태계 속에 존재하는 복잡함에 적응하기 위해서 디자인 되었습니다.

Hyperledger Fabric은 다른 블록체인 솔루션과 차별화 되는 독특하게 유연하고 확장 가능한 아키텍쳐를 사용자에게 전달합니다.

기업 블록체인의 미래를 위한 계획에서 필요한 것은 완벽하게 확인가능하고 오픈소스 아키텍쳐로 만들어지는 것입니다.

이러한 부분에서 Hyperledger Fabric은 사용자의 시작 지점입니다.

Hyperledger Fabric은 처음 사용자에게 남은 소개 섹션을 훑어보며 특정 요소나 특징에 블록체인이 어떻게 작동하는 가에 대해서 숙지하는 것을 추천압니다.

이미 이해하고 있거나 이해하셨다면 Getting Started로 이동하셔서 데모, 기술적 특징, API와 같은 것을 찾으시길 바랍니다.

블록체인이란 무엇인가?

분산원장

블록체인 네트워크의 핵심은 네트워크에서 발생하는 모든 트랜잭션을 기록하는 분산원장 시스템입니다.

블록체인 원장은 분권화된 시스템으로 표현되기도 합니다. 이는 많은 네트워크 참여자 사이에서 시스템 안에서 유지보수하며 쌓인 데이터를 복제하기 때문입니다.

아래의 사진은 분권과 공동 작업이 실제 기업환경에서 거래되는 재화와 서비스를 보여줄 수 있는 강력한 특징임을 보여줍니다.

분권과 공동 작업에 더하여, 블록체인 내의 데이터는 읽기 전용입니다. 한 번 발생한 트랜잭션을 원장에 기입하면 절때 수정될 수 없다는 점을 보장하기 위해서 암호화 기법을 사용합니다.

이러한 불변성은 정보의 출처를 증명하는 것을 쉽게 만듭니다. 이는 유저가 트랜잭션 발생 이후 데이터가 조작 또는 변동되지 않았다는 것을 증명할 수 있기 때문입니다.

이것이 블록체인이 증명의 시스템으로 표현되는 이유입니다.

스마트 컨트랙트

일관된 데이터 업데이트를 지원하는 것과 모든 원장 기능의 호스팅을 가능하게 하기 위해서 블록체인 네트워크는 원장으로의 접근을 조절할 수 있도록 하는 스마트 컨트랙트를 사용합니다.

스마트 컨트랙트는 정보 보호의 핵심 메커니즘과 네트워크에 간단히 보관할 수 있을 뿐만 아니라 사용자가 특정 관점의 트랜잭션을 자동으로 발생 시킬 수 있도록 합니다.

예를 들자면, 스마트 컨트랙트는 도착 시간에 따라서 배송 비용이 달라지는 규정으로 쓰일 수 있습니다.

두 이해관계 집단이 약관에 동의하고 원장에 쓰여진 후부턴 일정 금액이 상품이 도착하는 순간 전송됩니다.

합의

트랜잭션이 블록체인 참여자로부터 승인 되었을 떄만 원장을 업데이트 하는 것과 원장 스스로 업데이트 하는 것을 보장하기 위해서,

네트워크의 원장들이 일치되도록하는 프로세스를 합의라고 합니다.

이후 스마트 컨트랙트와 합의 알고리즘에 대해서 더욱 많이 배울 예정입니다. 지금은 블록체인이 공유되고 복제된 트랜잭션 시스템이라는 것을 아는 것으로 충분합니다.

이 시스템은 스마트 컨트랙트에 의해 업데이트 되고, 합의라는 협력 프로세스를 통해서 일관되게 일치함을 유지합니다.

왜 블록체인이 유용한가요?

오늘날의 기록 시스템

오늘날의 거래 네트워크는 이전 기업환경에서 유지해온 기록 네트워크에서 근소하게 업데이트된 버젼입니다.

비즈니즈 네트워크의 구성원은 서로 거래를 합니다. 하지만 거래 기록을 각자 나누어 가지고 있습니다.

그리고 거래가 되는 모든 것들은 팔리는 순간에 출처를 기록해야만 합니다.

이를 위해 상품을 판 비즈니스 측에서 제품의 소유권을 확인할 수 있도록 항목들의 묶음을 보유하고 있어야 합니다.

이러한 비즈니스 네트워크는 아래와 같습니다.

현대 기술은 이러한 종이 기록과 돌 기록을 하드 드라이브와 클라우드 플랫폼으로 가져왔습니다.

네트워크 참여자들의 신원을 관리하기 위한 통합 시스템은 더 이상 존재하지 않습니다.

출처를 만드는 것 자체가 많은 노동력을 요구하고 거래 신뢰성을 명확히 하는 것에 오래 걸립니다.

거래를 직접 손으로 사인하고 거래를 진행하고, 모든 데이터베이스가 다른 정보를 가지고 있는 것이 결국 모든 것이 잘못되는 점으로 귀결됩니다.

가시성과 신뢰가 확실함에도, 비즈니스 네트워크에 걸치는 기록 시스템을 만드는 프로세스와 정보는 오늘날의 균열있는 접근 방식으로는 불가능합니다.

Hyperledger Fabric이란 무엇입니까?

Linux Foundation이 산업 전용 블록체인 기술로 2015년에 Hyperledger를 만들어 내었습니다.

하나의 블록체인 기준이라기 보다, 오랜 시간동안 오픈 개발과 핵심 기준 적용을 장려하는 지적 재산권을 가진 공동체 프로세스를 향한 블록체인 기술을 개발하는 방향으로 진행되고 있습니다.

Hyperledger Fabric은 Hyperledger 안에 블록체인 프로젝트 중 하나입니다. 다른 블록체인 기술과 마찬가지로 원장을 가지고 있습니다.

이 원장을 통해서 스마트 컨트랙트를 사용합니다.

이렇듯 Hyperledger는 사용자가 그들의 트랜잭션을 관리하는 시스템입니다.

Hyperledger가 다른 블록체인과 가지고 있는 차별점은 Private하고 허가가 필요하다는 점입니다.

알려지지 않은 미상의 사용자들에게 허가가 없는 작업 증명같은 트랜잭션을 유효화하고 네트워크 신뢰도를 유지하기 위한 프로토콜을 요구하는 네트워크 보다는,

Hyperledger Fabric의 사용자는 MSP(Membership Service Provider)를 통해서 사용자 등록을 해야합니다.

Hyperledger Fabric은 또한 다양한 추가 옵션을 제공합니다. 원장의 데이터가 다양한 형식으로 보관되고, 합의 메커니즘을 교환 할 수 있습니다.

또한 다른 방식의 MSP도 지원됩니다.

Hyperledger Fabric은 채널을 만들 수 있습니다. 채널은 트랜잭션별 각기 다른 분산 원장을 만들 수 있도록 합니다.

이는 특히 몇몇 사용자가 경쟁 관계고 트랜잭션 발생을 다른 사용자가 알기를 원하지 않는 네트워크에서 중요한 옵션입니다.

한 예로 특정 사용자에게만 할인을 제시하는 경우를 들 수 있습니다.

만약 채널로부터 두명의 사용자를 형성한다면, 해당 채널을 위한 원장이 복제됩니다.

원장 공유

Hyperledger Fabric은 다음의 두 가지 하부 구성요소를 포함하고 있습니다.

이는 World State와 트랜잭션 로그 입니다.

각각의 사용자들은 그들이 속한 Hyperledger Fabric 네트워크의 모든 원장의 복사본을 가지고 있습니다.

World State는 주어진 원장의 상태로 표현됩니다. 이는 원장의 데이터 베이스라고도 볼 수 있습니다.

트랜잭션 로그는 현재 World State의 값을 만들어낸 모든 요소들을 기록하고 있습니다. 이는 World State의 히스토리 업데이트라고 볼 수 있습니다.

원장은 이렇듯 World State와 트랜잭션 로그 히스토리로 구성되어 있습니다.

원장은 World State를 위한 대체 가능한 데이터를 가지고 있습니다. 기본적으로 LevelDB의 Key-Value 보관 데이터베이스 라고 불립니다.

트랜잭션 로그는 추가될 필요가 없습니다. 단순히 이는 블록체인 내 원장 데이터베이스의 변경 이전과 이후 기록을 가지고 있습니다.

스마트 컨트랙트

Hyperledger Fabric 스마트 컨트랙트는 chaincode로 작성되어 있고 어플리케이션에 의해서 원장-어플리케이션 간 상호작용이 필요할 때 블록체인 외부에서 실행됩니다.

대부분의 경우에 chaincode는 원장의 데이터베이스 요소와 상호작용을 합니다.

여기서 원장의 데이터베이스란 World state를 의미합니다. 또한 트랜잭션 로그에는 적용되지 않습니다.

Chaincode는 다양한 프로그래밍 언어로 구현될 수 있습니다. 현재는 Go언어와 Java를 지원하고 차후에 더욱 많은 언어를 지원할 계획입니다.

프라이버시

네트워크에 요구에 따라선 B2B 네트워크 내 사용자에겐 그들이 공유하는 정보량에 매우 민감할 것입니다.

그렇기 때문에 다른 네트워크에선 프라이버시가 최우선 고려사항 입니다.

Hyperledger Fabric은 상대적으로 열려있는 네트워크뿐만 아니라 채널을 이용한 프라이버시가 가장 핵심 기능 요구사항인 네트워크 또한 지원합니다.

합의

비록 사용자들의 조합으로 네트워크 속에서 만들어져 있더라도, 트랜잭션은 반드시 발생 순서에 맞추어 기록되어야 할 것입니다.

이것이 가능하도록 하기 위해서, 트랜잭션의 순서는 네트워크 내부 원장에 에러를 발생시키거나 악의적인 문제를 발생시키는 것을 막아내도록 만들어져야만 합니다.

이는 컴퓨터 공학에서 전체적으로 연구가 된 분야입니다. 따라서 이를 달성하기 위한 각자 다른 협정을 가진 다양한 방법도 가지고 있습니다.

예를 들자면, PBFT(Practical Byzantium Fault Tolerance)는 파일들이 문제 발생마저도 서로 확인하여 일치하도록 하는 복제 메커니즘을 가지고 있습니다.

대안으로서 비트코인에서는 순서를 채굴이라는 프로세스로 발생합니다. 컴퓨터 간에 암호 문제를 풀도록 경쟁하여 풀어내는 순서대로 프로세스 순서를 정합니다.

Hyperledger Fabric은 네트워크 구성자가 사용자 간에 관계를 가장 대표할 수 있는 합의 메커니즘을 선택할 수 있도록 제작되었습니다.

프라이버시와 함께, 관계 안에서 고도로 설계된 네트워크에서부터 더욱 Peer-to-Peer한 네트워크까지 포함하는 스펙트럼이 있습니다.

우리는 Hyperledger Fabric 합의 매커니즘에 대해서 더욱 많은 것을 배울 것입니다.

앞으로 SOLO,Kafka, 그리고 SBFT(Simplified Byzantium Fault Tolerance)까지 다른 문서에서 배우실 수 있을 것입니다.

어디서 더 배울 수 있을까요?

Getting Started

우리는 블록체인 안에서 가장 핵심적인 요소들을 소개할 다양한 튜토리얼을 제공합니다.

이를 통해서 어떻게 다른 유저와 상호작용 하는지 배우고, 또한 실제 코드를 사용해 구현해보면서 블록체인 네트워크 안에서 간단한 트랜잭션을 구동시켜 볼 것입니다.

또한 Hyperledger Fabric을 이용하여 블록체인 네트워크 구동에 관한 생각을 가지고 있는 사람들에게 해당되는 튜토리얼도 제공합니다.

Hyperledger Fabric Functionalities

 Hyper Fabric Model

이번 소개에서 다루어진 항목에 대한 요소와 컨셉이 샘플 트랜잭션 흐름에서 어떻게 작동하는지에 대해서 배우는 것뿐만 아니라 다루어진 요소와 컨셉에 대해서 더욱 심도있게 배웁니다.

Hyperledger Fabric 모든 기능

Hyperledger Fabric은 모듈러 블록체인 안에 기업에 맞추어 높은 수준의 비밀성, 회복력, 유연성과 확장성을 가진 분산 원장 기술을 구현한 결과물입니다.

Hyperledger Fabric은 아래의 블록체인 네트워크 기능들을 제공합니다.

유저 식별 관리

허가받은 네트워크를 사용 가능하게 하기 위해서, Hyperledger Fabric은 모든 네트워크 사용자에 대한 권한과 유져 ID를 관리할 수 있는 사용자 식별 서비스를 제공합니다.

접근 권한 리스트는 특정 네트워크 작동 권한에 대한 허가의 추가적인 단계를 사용할 수 있도록 제공합니다.

특정한 유져 ID는 Chaincode 어플리케이션 구동을 허가 받았지만, 새로운 Chaincode를 설치하는 것은 제한되어 있는 것 같은 예를 들 수 있습니다.

프라이버시와 기밀성

Hyperledger Fabric은 비즈니스 이해 관계에 따라서 경쟁하는 것을 가능하게 하고, 어떤 그룹이든 Private하게 만들 수 있고, 비밀성의 컨트랙트를 사용할 수 있게 하며,

허가된 같은 네트워크 속에서 상생할 수 있도록 합니다. Private 채널은 네트워크 사용자 중 특정한 일부에게만 트랜잭션 프라이버시와 기밀성을 사용 가능 하게하는

메세징 경로를 제한합니다. 트랜잭션, 사용자, 그리고 채널 정보를 포함하는 채널 안에 모든 정보는 명시적으로 채널 접근 허가를 받은 어떤 네트워크 사용자든 간에 감추어져 있고 접근이 불가능 합니다.

효율적인 프로세싱

Hyperledger Fabric은 노드 타입에 따른 네트워크 역할을 할당합니다. 네트워크에 동시성과 평행성을 제공하기 위해서, 트랜잭션 실행이 트랜잭션 순서와 커밋으로부터 분리되도록 합니다.

트랜잭션을 실행하는 것이 동시에 다양한 트랜잭션을 각각의 피어 노드에서 순서를 만드는 것을 가능하도록 하는 것보다 선행됩니다.

이 동시성은 각각의 피어에서 프로세싱 효율성을 높혀주고, 순서를 매기는 서비스로의 전송을 가속합니다.

동시 프로세싱을 할 수 있도록 하는 것 이외에도, 업무의 분할이 피어 노드가 순서를 만드는(합의) 업무 부담으로부터 자유로운 동안 순서 노드가 트랜잭션 실행과 원장 유지에 대한 수요로부터 부담을 덜 수 있습니다.

이런 역할 분담은 또한 권한 설정과 권한 부여에 대한 프로세싱도 제한합니다. 모든 피어 노드는 모든 순서 노드를 믿지 않아야 합니다. 그리고 반대로, 그 안에서 실행되는 프로세스도 다른 프로세스에게 입증을 하는 것에 대해서 독립적으로 작동될 수 있습니다.

Chaincode의 모든 기능

Chaincode 어플리케이션은 채널 안에서 트랜잭션의 특정한 타입을 실행할 수 있도록 하는 로직을 포함하고 있습니다.

예를 들어 자산의 소유주를 변환하는 것을 파라미터로 가지고 있는 Chaincode는 소유의 전송이 같은 룰과 요구사항을 적용하는 모든 트랜잭션을 믿을 수 있도록 합니다.

시스템 Chaincode는 모든 채널에서 파라미터를 구동하는 Chaincode와는 구분됩니다.

시스템 생애주기와 설정 Chaincode는 채널의 규칙을 정합니다.

보증이나 검증을 위한 시스템 Chaincode는 보증과 검증을 위한 트랜잭션을 위한 요구사항을 정의합니다.

모듈러한 디자인

Hyperledger Fabric은 네트워크 디자이너에게 기능적인 선택을 제공하기 위한 모듈러 아키텍쳐를 구현합니다.

예를 들어 식별을 위한 특정한 알고리즘, 순서(합의) 그리고 암호화같은 것들은 어느 Hyperledger Fabric에도 적용할 수 있습니다.

그에 대한 결과는 어떤 산업이나 퍼블릭 도메인에 적용할 수 있는 전체 블록체인 아키텍쳐입니다.

이를 통해 그 네트워크가 마켓이나 규제, 지리적인 범위 안에서 상호 작동 가능성을 보장하게 됩니다.

Hyperledger Fabric model

 Hyperledger Fabric 모델

이 장에선 Hyperledger Fabric이 복잡하면서도 커스터마이즈가 가능하고 기업 블록체인 솔루션으로의 적용을 충족시켜주는 핵심 디자인 특징을 소개합니다.

1. 자산 : 자산은 음식이나 클래식 차에서 미래 화폐까지 네트워크 외부의 금전적인 가치에 대한 교환을 가능하게합니다.
2. Chaincode: Chaincode 실행은 트랜잭션 합의, 노드 타임에 대한 신뢰와 검증의 요구 수준 제한, 그리고 네트워크의 확장성과 성능을 최적화 하는 것을 분리해줍니다.
3. 원장 특성: 영속성을 가진 공유 원장은 각기 채널과 SQL(효율적인 감사와 분쟁 해결을 위한 쿼리 능력)을 내포하고 있습니다.
4. 채널 간의 프라이버시: 채널은 경쟁관계의 비즈니스와 규제가 많은 산업이 일반적인 네트워크에서 자산을 교환할 수 있을 만큼 높은 수준의 프라이버시와 신뢰성을 다양한 측면에서의 트랜잭션을 가능하게 합니다.
5. 보안성과 사용자 서비스: 허가받은 사용자는 모든 트랜잭션이 공인된 규제자와 감사자가 확인하고 추적할 가능할만큼 신뢰도 있는 블록체인 네트워크를 제공합니다.
6. 합의: 합의에 대한 특별한 접근은 기업 환경에 필요한 유연성과 확장성을 가능하게 합니다.

자산

자산은 부동산과 하드웨어 같은 유형의 자산에서 계약이나 지적 재산권같은 무형의 자산까지 범위를 포함하고 있습니다.

Hyperledger Fabric은 Chaincode 트랜잭션을 사용해서 자산을 수정할 수 있는 기능을 제공합니다.

자산은 키-밸류 쌍으로서 Hyperledger Fabric 내부에 존재하게 되고 채널 원장에 트랜잭션으로 상태 변화를 기록하게 됩니다.

자산은 바이너리 값이나 JSON의 형태로 표현됩니다.

Chaincode

Chaincode는 자산과 자산 변동을 하기 위한 트랜잭션 지시를 정의하는 소프트웨어입니다.

다시 말해서, 비즈니스 로직입니다. Chaincode는 다른 데이터베이스 상태 정보나 key-value 쌍을 읽거나 바꾸도록 시행합니다.

Chaincode 기능은 원장의 현재 데이터베이스 상태에 대해서 작동하고 트랜잭션 제안을 통해서 시작됩니다.

Chaincode 실행은 새로운 key-value를 만들어내고 네트워크로 전송되어 모든 피어의 원장에 적용될 수 있습니다.

원장 특성

원장은 순서가 있고, Fabric안의 모든 상태 변동에 대한 간섭 저항성 기록입니다.

상태 변동은 트랜잭션이라는 Chaincode 호출을 하고 참여한 조직에 제출되게 되는 결과를 가집니다.

각각의 트랜잭션은 key-value 쌍 자산의 집합을 낳는 결과를 가지게 되고. 이 key-value 쌍은 원장에 만들어지거나, 업데이트 또는 삭제 됩니다.

원장은 불변하고 순서가 있는 블록 안의 기록을 위한 블록체인과 현재의 Fabric 상태를 유지하기 위한 데이터베이스 상태로 구성되어 있습니다.

채널당 하나의 원장을 가지고 있습니다. 각각의 피어는 그들이 속해 있는 모든 채널에 원장 복사본을 관리하게 됩니다.

• 키 기반의 색인, 범위 쿼리, 복합 키 쿼리를 사용한 원장에 쿼리와 업데이트
• 풍부한 쿼리 언어(CouchDB를 데이터베이스 상태로 사용한다면)를 사용한 읽기 전용 쿼리
• 데이터의 출처 시나리오를 가능하게 하는 키를 위한 원장 히스토리 쿼리와 같은 읽기 전용 쿼리
• Chaincode안에서 읽혀질 수 있는 Key/Value의 버전과 Chaincode에 씌여진 Key/Value로 이루어진 트랜잭션
• 트랜잭션은 동의하는 피어의 서명을 포함하고 순서 시스템에 제출됩니다.
• 트랜잭션은 블록으로 순서가 매겨지고 순서 시스템에 의해서 채널 내부의 피어에게 "배송"됩니다.
• 피어는 보증 정책과 집행 정책에 대한 트랜잭션을 검증합니다.
• 블록을 읽기 이전에, Chaincode가 실행되는 동안 자산의 상태 변동을 확실시 하는 버젼 체크를 수행합니다.
• 트랜잭션이 한 번 검증되거나 커밋되면 불변성을 가지게 됩니다.
• 채널 원장은 정책, 접근 권한 리스트, 그리고 다른 관련 정보를 규정하는 설정 블록을 포함.
• 채널이 포함하고 있는 MSP(Membership Service Provider)는 다른 자격 권한자로 부터 유래한 암호화 요소를 허가.

Ledger 토픽을 확인하면 데이터베이스, 저장 구조, 그리고 쿼리 능력에 대한 더욱 심도있는 학습을 하실 수 있습니다.

채널 간의 프라이버시

Hyperledger Fabric은 현재 상태의 자산의 상태를 조정하고 조절할 수 있는 Chaincode 뿐만 아니고 단위 채널 기반 불변의 원장을 이용합니다.

원장은 채널의 범위에서 존재합니다. 이는 전체 네트워크 내에서 공유되는 채널 일 수 있습니다.(모든 사용자가 1개 채널에서 작동되고 있다는 전제하에)

또는 특정한 모임의 사용자만을 위한 사유화 채널일 수도 있습니다.

후자의 시나리오에선, 이러한 사용자들이 분리된 채널을 만들고 그렇게 함으로서 그들의 트랜잭션과 원장을 분리/격리 조치 할 수 있습니다.

모든 프라이버시와 투명성 사이의 갭을 연결하고 싶은 시나리오를 해결하기 위해서, Chaincode가 오직 자산 상태에만 접근하여 읽고 쓰는 것을 필요로 하는 피어에게만 설치 할 수 있습니다.

(다시 말해서, 피어에게 Chaincode가 설치되지 않았다면, 적절하게 원장에 인터페이싱 할 수 없다는 것을 의미한다)

더욱 데이터를 애매하게 만들기 위해서, Chaincode 안의 Value값은 순서 시스템에 트랜잭션으로 보내지기 이전이나 원장에 씌여지기 이전에 AES와 같은 일반적인 암호호 알고리즘을 이용하여 부분적이거나 전체적으로 암호화 될 수 있습니다. 한번 암호화된 데이터가 원장에 씌여지면, 오직 암호키를 생성하기 위한 관계키를 보유한 유저에 의해서만 복호화 할 수 있습니다.

Chaincode 암호화에 대해서 더욱 궁금하시면, Chaincode for Developer 토픽을 확인해보세요.

보안성과 사용자 서비스

Hyperledger Fabric은 사용자가 각자의 신원을 알 수 있는 트랜잭션적인 네트워크를 지원합니다.

퍼블릭 키 인프라는 조직, 네트워크 요소, 그리고 엔드 유져나 클라이언트 어플리케이션과 관련된 암호 인증을 생성하는 것에 사용됩니다.

결과적으로, 데이터 접근 관리를 이용해서 더 넓은 네트워크와 채널 단위를 관리하고 조절할 수 있습니다.

채널의 실존성과 가능성의 묶음인 Hyperledger Fabric에서 Permissioned라는 개념은 프라이버시와 기밀성이 중요한 관련 정보인 시나리오가 어드레싱되게 합니다.

Member Service Provider(MSP) 토픽을 확인하시면 암호 구현물을 더 잘 이해할 수 있을 것입니다. 그리고 Hyperledger Fabric의 서명, 검증, 인증도 또한 이해할 수 있습니다.

합의

분산 원장 기술에서, 합의는 최근 하나의 Function 안의 특정한 알고리즘이 되었습니다. 그러나, 합의는 트랜잭션의 순서를 동의하는 것이나 차별점은 제안, 보증부터 순서, 인증, 커밋까지 전체적인 트랜잭션 흐름에서 기본적인 역할을 Hyperledger Fabric에서 강조하고 있다. 한 마디로, 합의는 트랜잭션 구성 블락에 대한 집합의 정확성 인증을 전부 확인하는 것으로 정의 될 수 있습니다.

합의는 궁극적으로 트랜잭션이 명시적 규정 범위 확인에 대한 오더와 결과를 얻어집니다. 이러한 확인과 균형은 트랜잭션의 수명 주기동안 발생하며 사용자로 하여금 트랜잭션 클래스를 보증하도록 서술되어 있는 것과 이러한 보증 정책이 시행되고 유지되기 위한 시스템의 Chaincode를 서술 하기 위해서 보증 정책을 사용하는 것을 포함하고 있습니다. 커밋이 되기 이전에, 충분한 보증이 존재하도록 하는 시스템 Chaincode를 피어가 이용할 것입니다. 그리고 이러한 보증은 적절한 실체로부터 얻어졌을 것입니다. 더욱이, 트랜잭션이 포함되어 있는 블록이 원장에 씌여지기 이전에 현재 상태의 원장이 동의를 얻는 시점에 버전 확인이 될 것 입니다.

최종적인 확인 과정은 오퍼레이션이 중복 시행되거나 데이터 통합성을 위협할만한 점으로부터 지켜주고, function을 non-static 변수로 실행되도록 허가합니다.

합의, 타당성과 버전 확인의 다중 발생 이외에도, 모든 트랜잭션 흐름 동안 신원확인을 진행합니다. 접근 제어 리스트는 네트워크의 상하 단계(순서 서비스부터 채널까지)에서 구현되고, 보내지는 데이터가 각자 다른 구조 요소에서 트랜젝션 제안으로서 서명되고, 타당성을 인증받고, 확인됩니다. 결론 짓자면, 합의는 트랜잭션 집단 순서 동의를 제한하는 것이 아니고, 오히려 트랜잭션이 발생하여 등록되는 동안의 계속되는 인증의 부산물로서 얻어지는 것입니다.

Transaction Flow 다이어그램을 확인하여 합의의 시각적 표현을 확인하십니오.

Identity

 Identity란 무엇인가요?

블록체인 네트워크에는 피어, 명령자, 클라이언트 어플리케이션, 관리자와 같은 다양한 액터가 있습니다.

이러한 각각의 액터들은 X.509 Digital Certificate을 따르는 Identity를 가지고 있습니다.

이러한 Identity는 블록체인 네트워크 안에 액터들이 리소스에 대한 허가를 결정한다는 점에서 정말 중요합니다.

Hyperledger Fabric은 액터 안에 특성을 사용해서 허가 여부를 결정합니다. 그리고 Principal이라고 불리는 특별한 이름을 부여합니다.

Principal은 User Id나 Group Id와 같은 종류의 Identity입니다. 그러나 액터의 특성을 더 넓은 범위에서 포함하고 있다는 점에서

조금 더 유연합니다. 우리가 Principal에 대해서 말할 때 우리는 시스템 내부의 액터를 생각합니다.

특히 허가 여부를 결정하는 특성들을 고려합니다.

이러한 특성들은 전형적으로 액터의 조직, 조직 단위, 역할 또는 심지어는 액터의 특별한 Identity를 의미합니다.

가장 중요한 것은 Identity는 증명 가능성을 가지고 있어야 합니다.(다른 말로는 실제 Identity를 의미합니다.)

그리고 이러한 이유 때문에 이 Identity가 시스템 내부의 권한자로부터 나와야합니다.

Membership service provider(MSP)는 Hyperledger Fabric에서 Identity를 얻는 방법입니다.

더욱 특별하게도, MSP는 조직의 회원 규칙을 대표하고 조직 회원의 유효한 Identity를 운영하는 규칙을 정의 하는 것과 같은 하나의 요소입니다.

Fabric에서 기본적인 MSP를 구현할 때 전통적인 Public Key Infrastructure(PKI) Hierarchical model을 적용한 X.509 인증을 사용합니다.

Identity를 사용하는 단순한 시나리오

슈퍼 마켓에 식료품 구매를 위해서 방문했을 때를 생각해보세요. 계산대 앞에서 여러분은 Visa, Mastercard. AMEX 카드와 같은 것들만 결제가 가능하다는 것을 보실겁니다.

예를 들어 ImagineCard와 같은 다른 카드를 사용하려고 하면 계좌에 돈이 많고, 실제 거래 가능 카드 이더라도 받아들여지지 않을 것입니다.

유효한 신용카드를 가지는 것으로는 충분하지 않습니다. 무조건 슈퍼 마켓에서 받아 들여져야만 합니다. PKI와 MSP는 이런 방식으로 작동합니다.

그리고 MSP는 이 중 어떤 것이 네트워크 내부에 주어진 조직인지 확인합니다.

PKI 인증 권한자와 MSP는 비슷한 기능성을 제공합니다. PKI는 카드 제조사와 비슷합니다. PKI는 인증 가능한 많은 다른 종류의 Identity를 나누어줍니다.

한편 MSP는 매장에서 받을 수 있는 카드사 목록들과 같습니다. 매장에서 허가된 어떤 카드인지 결정합니다.

MSP는 인증 가능한 Identity를 블록 체인 내부의 사용자로 바꾸어줍니다.

PKI는 무엇인가요?

Public Key Infrastructure(PKI)는 네트워크의 보안 커뮤니케이션을 제공하는 인터넷 기술의 집합체입니다.

HTTPS의 S는 PKI에서 제공하는 것입니다. 만약 당신이 지금 이것을 웹브라우져에서 읽고 계신다면, 당신은 인증된 소스에서 나온 PKI를 사용하고 계십니다.

위의 사진은 PKI의 구성 요소입니다. PKI는 Certificate Authorities로 구성되어 있습니다.

Certificate Authorities는 서비스의 유저나 서비스 프로바이더같은 단체에 디지털 인증을 부여합니다.

그리고 사용자가 사용자 환경과 메시지 교환을 하면 그것을 증명 하게 됩니다.

A CA의 Certificate Revolution List(CRL)은 더 이상 유효하지 않은 인증의 기준을 구성합니다.

인증의 폐지는 많은 이유로 발생합니다. 예를 들자면 암호화된 Private 요소가 노출이 되는 경우에 인증이 폐지될 수 있습니다.

비록 블록체인 네트워크가 커뮤니케이션 네트워크보다 더욱 많지만, 다양한 네트워크 참여자 간의 보안 커뮤니케이션과

블록체인 내부에서 전송되는 메시지가 적절한 인증을 가지고 있는가를 확실하게 하기 위해서 블록체인 네트워크는 PKI에 의존합니다.

그러므로 PKI의 기본 개념과 왜 MSP가 중요한가를 이해하는 것은 매우 중요합니다.

PKI에는 4가지의 핵심 요소가 있습니다.

• 디지털 인증

• Public과 Private 키

• 인증 권한자

• 인증 폐지 리스트

PKI의 기본에 대해서 설명하겠습니다. 그리고 더 자세한 설명을 위해서 Wikipedia는 좋은 시작점일 수 있습니다.

디지털 인증

디지털 인증은 어떤 단체와 관련된 특성들의 집합체를 가지고 있는 일종의 문서입니다.

가장 일반적인 인증 타입은 X.509 기준을 따르는 하나의 인증입니다.

X.509 기준은 기준 내부 구조 안에서 단체 인증 세부사항을 암호화하도록 합니다.

예를 들자면, 디트로이트 미셸 자동차 생산부서의 Mary Morris라는 사람은 subject 특성 안에 이와 같은 정보를 가지게 됩니다.

C=US, ST=Michigan, L=Detroit, O=Mitchell Cars, OU=Manufacturing, CN=Mary Morris/UID=123456

Mary의 인증은 정부 주민등록번호와 유사합니다.

이 인증은 그녀가 증명할 수 있는 키로서 사용하기 위한 정보를 제공합니다.

X.509 인증의 많은 다양한 특성들이 있지만 지금은 이것들에 집중해봅시다.

위와 같이 디지털 인증은 Mary Morris를 Mary Morris라고 불리는 단체로 묘사하고 있습니다.

Mary는 인증의 하나의 Subject 입니다.

그리고 강조되어 있는 Subject 텍스트는 Mary에 대한 핵심 사실들을 전달하고 있습니다.

인증은 또한 많은 다른 종류의 정보를 보유하고 있습니다.

가장 중요하게도, Mary의 Public Key는 그녀의 Private signing Key가 배포되어 있지 않은 것과 반대로 그녀의 인증과 함께 배포되어 있습니다.

이 사인은 Private임이 유지되어야합니다.

가장 중요한 것은 Mary의 인증이 다른 조작에 의해서 인증이 유효화 되지 못하도록 암호화(비밀 쓰기)라는 수학적 기술을 활용해서 입력될 수 있습니다.

이 암호화는 Mary로 하여금 Certificate Autority(인증 권한자; CA)로 알려진 인증 배부자를 다른 단체에서 신용받는 한 그녀의 Identity를 다른 누군가에게 증명할 수 있는 인증으로 존재하게 해줍니다.

CA가 그녀의 확실한 암호화 비밀 정보(Private signing Key)를 유지해주는 한, 누구든 인증에서 알려주는 Mary에 대한 정보가 조작되지 않았다는 것에 대해서 확신할 수 있을 것입니다.

항상 Mary Morris에 대한 특별한 정보를 가지고 있을 것이기 때문에 Mary의 X.509 인증은 디지털 Identity 키로 조작이 불가능합니다.

Authentication & Public keys and Private keys

인증과 메시지 통합은 보안 커뮤니케이션의 중요한 컨셉입니다.

인증은 메시지를 교환하는 단체가 특정한 메시지를 만드는 Identity를 확신할 수 있다는 것을 요구합니다.

통합성은 메시지가 전송 간에 조작되지 않았다는 것을 요구합니다.

예를 들면, 여러분은 실제 Mary Morris와 소통하는 것이 그와 비슷한 대상과 소통하는 것보다 더욱 확실시 하고 싶으실 겁니다.

또는 Mary가 여러분께 메시지를 보냈더라도 그녀가 보낸 메시지가 교환 중에 어느 누구에게도 조작되지 않았다는 사실을 확실시하고 싶으실 겁니다.

전통적인 인증 메커니즘은 전자 서명 메커니즘을 따릅니다.

그 이름 그대로, 단체가 전자적으로 그들의 메시지를 서명할 수 있습니다.

전자 서명은 서명된 메시지의 통합성을 보장합니다.

기술적으로 말하자면, 전자 서명 메커니즘은 두 개의 암호학적으로 연결된 키를 요구합니다.

하나는 퍼블릭 키로 널리 사용되고 있고, 인증의 기점으로 작용합니다.

둘째는 프라이빗 키로 메시지의 전자 서명을 만들기 위해서 사용됩니다.

전자적으로 서명된 메시지를 받는 사람은 받은 메시지의 출처와 통합성을 보냈을 것으로 예상된 사람의 퍼블릭 키로 메시지에 포함된 서명의 유효성을 확인함으로서 인증할 수 있습니다.

프라이빗 키와 각각의 퍼블릭 키의 특별한 관계는 보안 커뮤니케이션을 가능하게 하는 암호학적 마술입니다.

각각의 키들의 특별한 수학적 관계는 프라이빗 키가 해당되는 퍼블릭 키가 맞아 떨어지고,

오직 같은 메시지에만 해당되는 메시지의 서명을 생성하기 위해서 사용될 수 있습니다.

위의 예시에서, Mary의 메시지를 인증하기 위해서 메시지에 프라이빗 키를 사용해서 메시지의 서명을 만들었습니다.

그 메시지는 그 이후 Mary가 메시지에 다시 첨부합니다.

서명은 어느 누구에게나 서명된 Mary의 퍼블릭 키를 이용해서 인증될 수 있습니다.

인증 권한자

여러분이 보신데로, 노드나 액터는 시스템에서 신뢰받는 권한자에 의해서 디지털 Identity를 발급받는 방법을 통해서

블록체인 네트워크에 참여할 수 있습니다. 가장 일반적인 케이스에선, 디지털 Identity(또는 단순화 Identity)

는 X.509 기준을 따르는 암호학적으로 유효한 디지털 서명의 형태를 가지고 있습니다.

그리고 Certificate Authority(CA)로부터 발급 받습니다.

CA는 인터넷 보안 프로토콜의 일반적인 부분입니다. 그리고 여러분은 조금 유명한 것에 대해선 들어보셨을 것 입니다.

Symantec, GeoTrust,DigiCert,GoDaddy 마지막으로 Comodo가 있습니다.

Certificate Authority는 다른 액터들에게 인증을 나누어줍니다.

이러한 인증은 CA에 의해서 서명을 받았고(CA의 프라이빗 키를 이용해서), 그리고 액터의 퍼블릭 키와 실제 액터를 묶습니다.

그리고 선택적으로 종합적인 특성들의 리스트도 묶기도 합니다.

명료하게, 만약 한사람이 CA를 믿는다면(퍼블릭 키를 알고 있기도 하면서), 특정한 액터가 인증 안에서 퍼블릭키와 묶여있고,

그리고 포함된 특성들을 가지고 있다는 것을 믿을 수 있습니다.(CA의 서명을 이용해서 액터의 인증을 유효화하면)

인증이 액터나 실제 CA의 프라이빗 키를 포함하지 않아도, 중요하게도 인증은 널리 전파될 수 있습니다.

이것은 주어진 CA로부터 발급받은 Identity의 소비자로 하여금 인증이 오직 해당하는 프라이빗 키의 보유자로부터

생설 될 수 있다는 것을 확인함으로서 Identity를 유효화 하도록 허가합니다.

블록체인 세팅에서, 네트워크와 상호작용하길 원하는 모든 액터는 identity가 필요합니다.

이 세팅에서, 여러분은 하나나 하나 이상의 CA가 디지털 관점에서 오직의 멤버를 정의하기 위해서 사용된다고 말하게 될 것입니다.

인증가능한 디지털 Identity를 위해서 조직의 액터를 위한 기본을 제공하는 것을 CA라고 합니다.

루트 CA, 중간 CA들과 신뢰 사슬

CA는 두 가지 종류가 있습니다.

하나는 루트 CA 그리고 둘째는 중간 CA라고 합니다.

왜냐하면 루트 CA는 인터넷 유져에게 수백만의 인증을 안전하게 분배해야하기 때문입니다.

그래서 중간 CA라는 부르는 것이 이 프로세스의 개념을 넓히는 것에 있어 합리적입니다.

이러한 중간 CA는 루트 CA나 다른 중간 권한자로부터 받은 그들만의 인증을 가지고 있습니다.

동시에 블록체인 안 어느 CA에서 발급받은 어떤 인증이던 간에 신뢰 사슬(Chain of Trust)을 설립을 허가하도록 합니다.

루트 CA로 추적해 나갈 수 있는 능력은 단지 CA가 여전히 보안성을 제공하는 동안 그 기능 확인을 허가하는 것뿐만 아니라(중간 CA에 신뢰를 가지고 조직에서 인증을 소모하는 것을 허가하는 것)

루트 CA의 노출을 제한하는 효과도 있습니다.이 루트 CA는 만약 밝혀진다면, 모든 신뢰 사슬을 위협할 수 있습니다.

만약 중간 CA가 밝혀진다면 노출이 조금 더 작은 부분에서 이루어 질 것입니다.

신뢰 사슬은 루트 CA와 중간 CA의 집합 중간에서 형성되며 CA가 형성되는 동안 어떤 중간 CA도 루트 CA가 되기도 하거나 루트 CA를 향한 신뢰 사슬이 되기도 합니다.

중간 CA는 다양한 조직에 인증을 발행하는 것에 관해서 큰 유연성을 제공해주고, 블록체인 시스템을 허가 관리하는 것에 매우 도움이 됩니다.

예를 들자면, 각각 다른 루트 CA를 사용하거나 같은 루트 CA를 가졌지만 다른 중간 CA를 가진 다양한 조직을 가정할 수 있습니다. 그리고 이것은 네트워크에 요구사항에 의존하게 됩니다.

Fabric CA

Fabric에서 이미 빌트인된 CA 요소들을 사용자가 만든 블록체인 내트워크에 새로운 CA를 만드는 것을 허가하기 때문에 CA는 매우 중요합니다.

이 요소는 Fabric-ca라고 알려져 있으며, X.509 인증 형태를 가진 Fabric 사용자의 디지털 identity를 관리하는 것이 가능한 프라이빗 루트 CA입니다.

왜냐하면 Fabric-CA는 Fabric의 필요한 루트 CA를 목표로 만들어진 커스텀 CA이기 때문입니다.

또한 브라우저에서 일반적이거나 자동생성형 SSL 인증을 제공하는 것이 내제적으로 불가능합니다.

그러나 몇몇 CA는 Identity를 관리하는 것에 사용해야만 하기 때문에(테스트 환경에서도), Fabric-CA는 인증을 관리/배포하는 것에도 사용할 수 있습니다.

또한 상황이 적절하다면, 퍼블릭/상업용 루트 또는 중간 CA를 Identification을 제공하기 위해서 사용하는 것 역시 가능합니다.

더 많은 정보를 위해선 CA Documentation Section을 확인해보세요.

인증 폐지 리스트

인증 폐지 리스트(Certification Revocation List; CRL)은 이해하기 쉽습니다.

단지 몇가지 사유로 폐지된 인증들의 리스트입니다.

만약 아까의 매장 시나리오를 돌려보자면, CRL은 분실 신용카드와 같은 것로 볼 수 있습니다.

제삼자가 다른 파티의 Identity를 증명하려하면, 우선적으로 발급된 CA의 CRL을 통해서 인증의 폐기 여부를 확인합니다.

인증자는 CRL을 확인하지 않아도 되고, 그러나 만약 확인하지 않는다면, 발각된(compromised) Identity를 사용할 수 있는 위험성을 안고 있어야합니다.

CRL을 사용해서 인증을 확인하는 것은 여전히 유효합니다. 만약 가짜 유저가 발각된 디지털 인증을 활용해서 파티를 증명하려하면,

우선, CA CRL을 확인해서 더 이상 유효하지 않아서 리스트에 존재하지 않는다는 것을 확인하게 될 것 입니다.

주의해야할 점은 인증의 폐지는 인증의 만료와는 다르다는 것입니다.

폐지된 인증은 만료되지 않았습니다. 이러한 인증들은 다른 측면에선 여전히 유효한 인증입니다.

이는 만료된 운전면허증과 폐지된 운전면허증과 같습니다.

더 많은 정보를 원하신다면 here을 클릭해주세요.

이제 PKI가 어떻게 인증가능한 Identity를 신뢰 사슬에 배포하는지 배우셨고, 다음 단계는 블록체인 네트워크의 사용자가 어떻게 그들의 Identity를

신뢰받는 사용자로서 인증받는지에 대해서 배울 예정입니다.

이는 MSP가 작용하는 부분이고, MSP는 블록체인 내 사용자의 Identity를 주어진 조직 중 어느 조직에 속해있는지를 구분해 줍니다.

membership에 대해서 더 배우기 위해선 MSPs에 대한 개념적 문서를 확인하세요.

Membership

만약 지난 Identity 문서를 읽으셨다면, PKI가 어떻게 인증가능한 Identity를 신뢰 사슬을 통해 제공하는지 배우셨을 겁니다.

이제, 이러한 Identity가 어떻게 블록체이 네트워크 내부의 신뢰 받는 사용자로서 나타나 지기위해서 사용될 수 있는지에 대해서 배워보시겠습니다.

이 곳이 Membership Service Provider(MSP)가 활동은 시작하는 영역입니다. MSP는 어떤 루트 CA나 중간 CA가 신뢰 도메인의 사용자를 정의하기 위해서 신뢰받고 있는지를 구별해냅니다.

MSP는 사용자 identity 목록을 만듦으로서 또는 어떤 CA가 사용자의 유효한 Identity에 발급 권한이 있음을 앎으로서 , 또는 가장 일반적인 케이스일 경우 둘의 조합으로 구별해냅니다.

MSP의 힘은 누가 네트워크 참여자인지 또는 채널의 사용자 인지에 대한 단순한 목록을 만드는 정도는 뛰어넘습니다.

MSP는 일정 범위 안에서 또는 MSP가 대표하는 조직(트러스트 도메인)(예 : MSP 관리자, 조직 하위 구성원)에서 액터가 역할을 수행 할 수도 있는 특별한 역할을 식별할 수 있습니다.

그리고 또한 MSP는 네트워크나 채널 문맥 속에 접근 권한을 규정하기 위한 기반을 구성합니다.(예: 채널 관리자, 독자, 작가)

MSP의 설정은 모든 채널에 알려지고, 이 알려진 채널은 해당하는 조직에 참여하는 사용자입니다.(channel MSP의 형태로)

피어, 주문자, 클라이언트는 또한 채널 밖의 문맥에서 조직 구성원의 메시지를 인증하기 위해서 로컬 MSP 인스턴스를 유지합니다.(ILocal MSP로 알려진)

게다가, MSP는 이미 폐지된 Identity의 목록 인증을 허가합니다.(우리는 Identity 문서에서 이미 다루었지만, 이 프로세스가 어떻게 MSP로 넓혀지는지를 설명하겠습니다.)

우리는 로컬 그리고 채널 MSP에 대해서 잠시동안 조금 더 많은 내용을 설명하겠습니다. 지금부터 일반적인 상황에 MSP가 작동하는지를 설명하겠습니다.

MSP를 조직에 연결하기

조직은 구성원의 관리된 그룹이고, 다국적 기업에서 작은 꽃집까지 될 수 있는 하나의 그룹입니다.

조직에서 가장 중요한 것은 단일 MSP 이하의 구성원을 관리합니다.

이것은 우리가 나중에 설명할 X.509 인증 안에서의 조직 개념과는 다르다는 것을 주의하셔야 됩니다.

조직과 그 조직의 MSP 사이의 배타적인 관계는 조직 이후의 MSP의 이름 짓는 것을 더욱 민감하게 만듭니다.

여러분은 대부분의 정책 설정 안에 관습을 찾으실 수 있을 것입니다. 예를 들자면, 조직 org1은 MSP에선 org1-msp로 불리울 수 있습니다.

몇몇 경우에 조직은 다양한 멤버십 그룹을 요구할 수 있습니다. 예를 들면, 채널이 매우 다르게 다양한 멤버십 그룹에 요구하는 것과 같습니다.

이러한 경우에 다양한 MSP를 가지는 것이 일리가 있고, 그들을 각각 ORG2-MSP-NATIONAL, ORG2-MSP-GOVERNMENT와 같이

ORG2 안에 각각 다른 신뢰 멤버십 루트를 National 판매량 채널과 Govenment 규제 채널로 나누어 반영하는 하는 것은 일리가 있습니다.

조직을 위한 두 개의 다른 MSP 입니다. 첫 번째 설정은 MSP와 조직의 전형적인 관계를 보여줍니다. 단일 MSP는 조직 구성원의 리스트를 정의합니다.

두 번째 설정은, 각기 다른 MSP가 national, international, government 소속 조직적인 그룹을 대표하는 것에 사용됩니다.

조직적인 단위와 MSP

조직은 때론 여러 조직 단위(Organizational Unit; OU)로 나뉘며 각 조직 단위에는 특정한 책임에 대한 집합이 있습니다.

예를 들자면, ORG1 조직에서 이러한 개별 영업 방침을 반영하기 위해 조직 단위 ORG1-MANUFACTURER과 ORG1-DISTRIBUTION 조직 단위를 둘 수 있습니다.

CA가 X.509 인증을 발급하면, ou라는 인증서의 필드는 ID가 속한 사업부를 지정하게 됩니다.

OU가 블록체인 네트워크의 구성원으로 간주되는 조직의 부분을 제어하는 것에 있어서 어떤 방식으로 도움이 되는 지 차후에 알 수 있습니다.

예를 들어 ORG1-MANUFACTURING 조직 단위의 ID만 채널에 접근 할 수 있지만 ORG1-DISTRIBUTION은 채널에 접근할 수 없습니다.

마지막으로 조직 단위의 약간의 잘못된 사용일 수 있지만 컨소시엄으로 서로 다른 조직에서 서로를 구별하기 위해서 사용 할 수 있습니다.

이러한 경우에 서로 다른 조직에서는 신뢰 루트에 대해 동일한 루트 CA와 중간 CA를 사용하지만 OU의 각각 조직원의 구성원을 식별할 수 있도록 필드를 적절하게 할당합니다.

차후엔 이를 달성하기 위한 MSP 구성 방법도 알아보겠습니다.

로컬 및 채널 MSP

MSP는 채널 구성 ( 채널 MSP )과 배우의 전제 ( 로컬 MSP ) 의 로컬에서 Blockchain 네트워크의 두 위치에 나타납니다 . 노드 (피어 또는 발주자) 및 사용자 (SDK를 사용하는 CLI 또는 클라이언트 응용 프로그램을 사용하는 관리자 )에 대해 정의 된 로컬 MSP 모든 노드와 사용자는 로컬 MSP를 정의해야합니다 . 그 수준에서 관리 권한이나 참여 권한을 가진 사람과 채널 컨텍스트 (예 : 동료 조직의 관리자)를 정의합니다.

대조적으로 채널 MSP는 채널 수준에서 관리 및 참여 권한을 정의합니다 . 채널에 참여하는 모든 조직은 정의 된 MSP가 있어야합니다. 채널의 피어 및 주문자는 모두 채널 MSP에서 동일한보기를 공유하므로 채널 참여자를 올바르게 인증 할 수 있습니다. 즉, 조직이 채널에 가입하고자하는 경우 조직 구성원에 대한 신뢰 체인을 포함하는 MSP를 채널 구성에 포함시켜야합니다. 그렇지 않으면이 조직의 신원에서 비롯된 거래가 거부됩니다.

여기에서 로컬 및 채널 MSP 간의 주요 차이점은 어떻게 작동하는지가 아니라 해당 범위 입니다.

로컬 및 채널 MSP. 각 피어의 신뢰 도메인 (예 : 조직)은 피어의 로컬 MSP (예 : ORG1 또는 ORG2)에 의해 정의됩니다. 채널에서 조직의 대표는 조직의 MSP를 채널에 포함시킴으로써 성취됩니다. 예를 들어,이 그림의 채널은 ORG1과 ORG2에 의해 관리됩니다. 비슷한 원리가 네트워크, 주문자 및 사용자에게 적용되지만, 여기서는 설명의 편의를 위해 여기에 표시되지 않습니다.

로컬 MSP는 적용 대상 노드 또는 사용자의 파일 시스템에서만 정의 됩니다. 따라서 물리적 및 논리적으로 노드 나 사용자별로 하나의 로컬 MSP 만 있습니다. 그러나 채널 MSP는 채널의 모든 노드에서 사용할 수 있으므로 구성시 채널에 한 번 논리적으로 정의됩니다. 그러나 채널 MSP는 채널의 모든 노드의 파일 시스템에서 인스턴스화되고 컨센서스를 통해 동기화 된 상태로 유지됩니다 . 따라서 각 노드의 로컬 파일 시스템에 각 채널 MSP의 사본이있는 반면, 논리적으로 채널 MSP는 채널이나 네트워크에 상주하며 유지 관리됩니다.

위 그림에서와 같이 블록 체인 관리자가 스마트 계약을 설치하고 인스턴스화 할 때 발생하는 상황을 확인하여 로컬 및 채널 MSP를 사용하는 방법을 확인하는 것이 도움이 될 수 있습니다 .

관리자 B는 RCA1에 자신의 로컬 MSP에 의해 발행되고 저장된 ID로 피어에 연결합니다 . 때 B는 피어에 스마트 계약을 설치하려고, 피어는 로컬 MSP를 확인 ORG1-MSP의 신원을 확인하기 위해, B는 ORG1의 진정한 구성원입니다. 성공적으로 확인하면 설치 명령이 성공적으로 완료됩니다. 이어서 B는 채널에서 스마트 계약을 인스턴스화하려고합니다. 이는 채널 운영이므로 채널의 모든 조직이 동의해야합니다. 따라서 피어는이 명령을 성공적으로 커밋하기 전에 채널의 MSP를 확인해야합니다. (다른 일도 일어나야하지만 지금은 위에 집중해야합니다.)

채널 자체가 논리적 구성인 것처럼 채널 MSP를 관찰 할 수 있습니다 . 채널 org 동료의 로컬 파일 시스템에서 인스턴스화되고 관리되는 경우에만 물리적으로됩니다.

MSP 수준

채널 및 로컬 MSP 사이의 분리는 피어 또는 발주자 노드와 같은 로컬 리소스 및 채널 또는 네트워크 수준에서 작동하는 원장, 스마트 계약 및 컨소시엄과 같은 채널 리소스를 관리하는 조직의 요구를 반영합니다. 그것은 다른에있는 이러한 MSP를 생각하는 것이 도움이 수준 으로, 네트워크 관리 문제에 관한 높은 수준에서 MSP를 하면서 민간 자원의 관리를위한 낮은 수준의 핸들 정체성에 MSP가 . MSP는 모든 관리 수준에서 필수적입니다. 즉, 네트워크, 채널, 피어, 주문자 및 사용자에 대해 정의해야합니다.

MSP 레벨. 피어 및 발주자에 대한 MSP는 로컬이며, 채널의 MSP (네트워크 구성 채널 포함)는 해당 채널의 모든 참가자에게 공유됩니다. 이 그림에서 네트워크 구성 채널은 ORG1에 의해 관리되지만 다른 응용 프로그램 채널은 ORG1 및 ORG2에 의해 관리 될 수 있습니다. 피어는 ORG2의 구성원이며 ORG2가 관리하지만 ORG1은 그림의 순서를 관리합니다. ORG1은 RCA1의 신원을 신뢰하지만 ORG2는 RCA2의 신원을 신뢰합니다. 이들은 관리 구성표로서 누가 이러한 구성 요소를 관리 할 수 ​​있는지 반영합니다. 따라서 ORG1이 네트워크를 관리하는 동안 ORG2.MSP는 네트워크 정의에 존재합니다.

• 네트워크 MSP : 네트워크 의 구성은 참가자 조직 MSP를 정의하여 네트워크의 구성원과 관리 작업 (예 : 채널 만들기)을 수행 할 권한이있는 구성원을 정의합니다.
• 채널 MSP : 채널에서 회원의 MSP를 별도로 유지 관리하는 것이 중요합니다. 채널은 조직의 특정 집합간에 사적인 통신을 제공하며 차례로 관리를 제어합니다. 채널의 MSP와 관련하여 해석되는 채널 정책은 채널에 대한 특정 작업 (예 : 조직 추가 또는 체인 코드 인스턴스 생성)에 참여할 수있는 권한을 가진 사용자를 정의합니다. 채널을 관리 할 수있는 권한과 네트워크 구성 채널 (또는 다른 채널)을 관리 할 수있는 권한 간에는 필요한 관계가 없습니다. 관리 권한은 관리 대상 범위 내에 존재합니다 (규칙이 다르게 작성되지 않은 경우 - ROLE아래 속성 에 대한 설명 참조).
• 피어 MSP : 이 로컬 MSP는 각 피어의 파일 시스템에 정의되며 각 피어에 대해 단일 MSP 인스턴스가 있습니다. 개념적으로 채널 MSP와 정확히 동일한 기능을 수행하지만, 정의 된 피어에만 적용된다는 제한이 있습니다. 피어의 로컬 MSP를 사용하여 권한 부여를 평가하는 작업의 예는 피어 전제에 체인 코드를 설치하는 것입니다.
• 발주자 MSP : 피어 MSP와 마찬가지로 발주자 로컬 MSP도 노드의 파일 시스템에 정의되어 있으며 해당 노드에만 적용됩니다. 피어 노드와 마찬가지로 주문자는 단일 조직에서 소유하므로 신뢰할 수있는 액터 또는 노드를 나열하는 단일 MSP가 있습니다.

MSP 구조

지금까지 MSP의 가장 중요한 두 요소는 해당 조직에서 액터 또는 노드의 구성원을 설정하는 데 사용 된 (루트 또는 중간) CA의 사양입니다. 그러나 멤버십 기능을 보조하기 위해이 두 가지 요소와 함께 사용되는 요소가 더 많습니다.

위의 그림은 로컬 MSP가 로컬 파일 시스템에 저장되는 방법을 보여줍니다. 비록 채널 MSP가 정확히 이런 방식으로 물리적으로 구조화되어 있지는 않지만, 그것들에 대해서 생각하는 것은 여전히 ​​유용한 방법입니다.

보시다시피 MSP에는 9 가지 요소가 있습니다. MSP 이름이 MSP 구성의 다른 요소를 나타내는 각 하위 폴더와 함께 루트 폴더 이름 인 디렉터리 구조에서 이러한 요소를 생각하는 것이 가장 쉽습니다.

이 폴더에 대해 좀 더 자세하게 설명하고 중요한 이유를 알아 보겠습니다.

• 루트 CA : 이 폴더는이 MSP가 나타내는 조직에서 신뢰하는 루트 CA의 자체 서명 된 X.509 인증서 목록을 포함합니다. 이 MSP 폴더에는 적어도 하나의 루트 CA X.509 인증서가 있어야합니다. 이는 다른 모든 인증서를 파생시켜 해당 조직의 구성원으로 간주해야하는 CA를 식별하기 때문에 가장 중요한 폴더입니다.

• 중간 CA : 이 폴더는이 조직에서 신뢰하는 중간 CA의 X.509 인증서 목록을 포함합니다. 각 인증서는 MSP의 루트 CA 중 하나 또는 서명 된 CA 체인이 궁극적으로 신뢰할 수있는 루트 CA로 연결되는 중간 CA에 의해 서명되어야합니다. 직간접 적으로 해당 조직의 구조와 관련하여 중간 CA를 사용하는 경우 중간 CA는 조직의 다른 하위 또는 조직 자체를 나타낼 수 있습니다 (예 : 상업용 CA가 조직의 ID 관리에 사용되는 경우). 후자의 경우, CA 계층 구조에서 더 낮은 다른 중간 CA를 사용하여 조직 세목을 나타낼 수 있습니다. 여기 에서 MSP 구성에 대한 모범 사례에 대한 자세한 정보를 찾을 수 있습니다. 중개 CA가없는 작동하는 네트워크를 가질 수 있으며이 경우이 폴더는 비어있을 수 있습니다. 루트 CA 폴더와 마찬가지로이 폴더는 조직의 구성원으로 간주되도록 인증서를 발급해야하는 CA를 정의합니다.

• 조직 구성 단위 (OU) : $Fabric_CFG_PATH/msp/config.yaml 디렉토리에 나열되며 조직 구성 단위 목록을 포함합니다. 구성 단위 목록은이 MSP가 대표하는 조직의 구성원으로 간주됩니다. 이는 조직의 구성원을 특정 OU가있는 ID (MSP 지정 CA 중 하나가 서명 한 ID)가있는 조직 구성원으로 제한하려는 경우에 특히 유용합니다. OU를 지정하는 것은 선택 사항입니다. OU가 목록에 없으면 루트 CA 및 중간 CA 폴더로 식별되는 MSP의 일부인 모든 ID가 조직의 구성원으로 간주됩니다.

• 관리자 : 이 폴더는이 조직의 관리자 역할을 맡은 액터를 정의하는 ID 목록을 포함합니다. 표준 MSP 유형의 경우이 목록에 하나 이상의 X.509 인증서가 있어야합니다. 액터가 관리자의 역할을한다고해서 특정 리소스를 관리 할 수있는 것은 아닙니다. 시스템 관리와 ​​관련하여 주어진 신원이 갖는 실제 권한은 시스템 자원을 관리하는 정책에 의해 결정됩니다. 예를 들어, 채널 정책은 ORG1-MANUFACTURING 관리자 에게 채널 에 새 조직을 추가 할 수있는 권한이 있음을 관리자가 지정할 수있는 권한을 지정할 수 있습니다 ORG1-DISTRIBUTION. X.509 인증서에는 ROLE속성 (예 : 액터가 지정되어 있음 admin)이 있지만 이는 블록 체인 네트워크가 아니라 조직 내에서 액터의 역할을 나타냅니다. 이것은 OU속성 의 목적과 유사합니다. 정의 된 경우 속성은 조직의 액터의 위치를 ​​나타냅니다. ROLE속성은 수 채널에 대한 정책 (예 : 인스턴스 chaincode 같은) 특정 채널 기능을 수행하는 조직 (또는 특정 조직) 권한에서 모든 관리자를 할 수 있도록 작성되어있는 경우 채널 수준에서 관리 권한을 부여하는 데 사용. 이러한 방식으로 조직 역할이 네트워크 역할을 부여 할 수 있습니다. 이것은 미국 플로리다 주에서 발행 한 운전 면허증을 소지 한 사람이 미국의 모든 주에서 운전할 수있는 권리를 갖는 것과 개념적으로 유사합니다.

• 해지 된 인증서 : 액터의 신원이 취소 된 경우 ID 자체가 아닌 신원에 관한 정보를 식별하는이 폴더에 보관됩니다. X.509 기반 ID의 경우 이러한 식별자는 SKI (Subject Key Identifier) ​​및 AKI (Authority Access Identifier)로 알려진 문자열 쌍이며 X.509 인증서를 사용하여 인증서가 없는지 확인 될 때마다 확인됩니다 취소됨. 이 목록은 개념적으로 CA의 인증서 해지 목록 (CRL)과 동일하지만 조직의 구성원 자격 해지와 관련이 있습니다. 결과적으로 로컬 또는 채널의 MSP 관리자는 CA의 업데이트 된 CRL을 발급 한 취소 인증서를 광고함으로써 조직에서 배우 또는 노드를 신속하게 취소 할 수 있습니다. 이 "목록 목록"은 선택 사항입니다. 인증서가 폐기되면서 만 채워집니다.

• 노드 신원 : 이 폴더에는 노드의 신원, 즉 KeyStore의 내용과 결합하여 노드가 채널 및 네트워크의 다른 참가자에게 보내는 메시지에서 자신을 인증 할 수있게하는 암호 자료가 들어 있습니다. X.509 기반 ID의 경우이 폴더에는 X.509 인증서 가 포함되어 있습니다 . 이것은 피어가 트랜잭션 제안 응답에 포함시키는 인증서입니다 (예 : 피어가이를 보증했음을 나타 내기 위해). 이후 검증 시간에 결과 트랜잭션의 보증 정책에 대해 확인할 수 있습니다. 이 폴더는 로컬 MSP에는 필수 항목이며 노드에 정확히 하나의 X.509 인증서가 있어야합니다. 채널 MSP에는 사용되지 않습니다.

• 개인 키용 키 저장소 : 이 폴더는 피어 또는 발주자 노드 (또는 클라이언트의 로컬 MSP)의 로컬 MSP에 대해 정의되며 노드의 서명 키를 포함합니다 . 이 키는 Node Identity 폴더에 포함 된 노드의 ID와 암호 학적으로 일치하며 데이터 서명에 사용됩니다. 예를 들어 승인 단계의 일부로 트랜잭션 제안 응답에 서명하는 데 사용됩니다. 이 폴더는 로컬 MSP에는 필수 항목이며 정확하게 하나의 개인 키가 있어야합니다. 분명히이 폴더에 대한 액세스는 피어에 대한 관리 책임이있는 사용자 인 아이디로만 제한되어야합니다. 채널 MSP의 구성에는 채널 MSP 가 서명 확인 기능이 아닌 신원 확인 기능 만 제공하기 때문에이 부분은 포함되지 않습니다.

• TLS 루트 CA : 이 폴더는 TLS 통신 을 위해이 조직 에서 트러스트 된 루트 CA의 자체 서명 된 X.509 인증서 목록을 포함합니다 . TLS 통신의 예로는 피어가 원장 업데이트를받을 수 있도록 주문자에게 연결해야 할 때입니다. MSP TLS 정보는 네트워크를 사용하는 노드 (응용 프로그램 및 관리자)가 아닌 네트워크 내부의 노드 (예 : 동료 및 주문자)와 관련이 있습니다. 이 폴더에는 하나 이상의 TLS 루트 CA X.509 인증서가 있어야합니다.

• TLS 중간 CA : 이 폴더에는 TLS 통신 을 위해이 MSP가 나타내는 조직에서 신뢰하는 중간 CA 인증서 CA 목록이 들어 있습니다 . 이 폴더는 상용 CA가 조직의 TLS 인증서에 사용될 때 특히 유용합니다. 멤버쉽 중간 CA와 마찬가지로 중간 TLS CA를 지정하는 것은 선택 사항입니다. TLS에 대한 자세한 내용은 여기를 클릭 하십시오 .

이 문서와 Identity 에 관한 문서를 읽은 경우 , Hyperledger Fabric에서 ID와 멤버십이 어떻게 작동하는지 꽤 잘 이해해야합니다. PKI와 MSP를 사용하여 블록 체인 네트워크에서 협력하는 액터를 식별하는 방법을 살펴 보았습니다. MSP가 물리적 및 논리적으로 구조화 된 방법 외에도 인증서, 공용 / 개인 키 및 신뢰의 뿌리가 어떻게 작동 하는지를 배웠습니다.

Peers

블록 체인 네트워크는 주로 피어 노드 집합으로 구성됩니다. 원장은 원장 및 Smart Contract를 호스팅하는 이유로 네트워크의 기본 요소입니다. 장부는 Smart Contract에 의해 생성 된 모든 트랙잭션을 수정 불가능 하도록 기록한다는 점을 기억하셔야합니다. Smart Contract 및 원장은 공유 프로세스와 정보 를 각각의 네트워크 에 캡슐화하기 위해서 사용됩니다 . 피어의 이러한 측면은 Hyperledger Fabric 네트워크를 이해하는 데 좋은 시작점이됩니다.

원장 및 Smart Contract, 주문자, 정책, 채널, 어플리케이션, 조직, ID 및 멤버십과 같은 블록 체인 네트워크의 다른 요소도 물론 중요합니다. 그리고 자신의 전용 토픽에 대해 자세히 알아볼 수 있습니다. 이 토픽는 피어 및 Hyperledger Fabric 블록 체인 네트워크의 다른 요소와의 관계에 중점을 둡니다.

블록 체인 네트워크는 피어 노드로 구성되며 각 노드는 원장 및 Smart Contract 사본을 보유 할 수 있습니다. 이 예시를 보시면 네트워크 N은 피어 P1, P2 및 P3에 의해 형성됩니다. P1, P2 및 P3은 각각 원장 L1의 자체 인스턴스를 유지합니다. P1, P2, P3는 체인 코드 S1을 사용하여 원장 L1 사본에 액세스합니다.

피어는 생성, 시작, 중지, 재구성 및 삭제할 수 있습니다. 관리자와 어플리케이션이 제공하는 서비스와 상호 작용할 수있는 일련의 API를 제공합니다. 이 주제에 대한 자세한 내용은 이 서비스를 참조하십시오.

전문 용어

Hyperledger Fabric은 chaincode 라고하는 기술 개념을 사용하여 Smart Contract을 구현합니다. Smart Contract란 지원되는 프로그래밍 언어 중 하나로 작성된 원장에 접근하는 간단한 코드입니다. 이 주제에서는 일반적으로 chaincode 라는 용어를 사용하겠지만, 이 용어를 사용하는 것이 익숙하시다면 Smart Contract 토픽을 읽으십시오 . 물론 Chaincode와 Smart Contract는 같은 주제입니다.

원장 및 체인 코드

피어를 조금 더 자세히 살펴 보겠습니다. 원장과 체인 코드를 모두 호스트하는 것이 피어임을 알 수 있습니다. 더 정확하게, 피어는 실제로 Instance 원장과 Instance chaincode를 호스팅합니다. 이는 Fabric 네트워크에서 고의적 이중화를 제공합니다. 그리고 그로 인해 단일 실패 지점을 피할 수 있습니다. 이 주제의 뒷부분에선 블록 체인 네트워크의 분산 된 특성에 대해 더 배우게됩니다.

피어는 원장의 인스턴스와 체인 코드의 인스턴스를 호스팅합니다. 이 예에서 P1은 원장 L1의 인스턴스와 체인 코드 S1의 인스턴스를 호스팅합니다. 개별 피어에서 호스팅되는 다양한 원장과 체인 코드가 있을 수 있습니다.

피어는 원장 및 체인 코드 의 호스트 이기 때문에 애플리케이션 및 관리자는 이러한 리소스에 액세스하려는 경우 피어와 상호 작용해야합니다. 이것이 피어가 Hyperledger Fabric 블록 체인 네트워크의 가장 기본적인 빌딩 블록으로 간주되는 이유입니다. 피어가 처음 만들어지면 원장이나 체인 코드를 가지고 있지 않습니다. 원장이 어떻게 생성되고 체인 코드가 설치되는지 나중에 알게 될 것입니다.

복수 원장

피어는 둘 이상의 원장을 호스팅 할 수 있고 유연한 시스템 설계가 가능해서 도움이됩니다. 가장 단순한 피어 구성은 하나의 원장을 갖는 것이지만 필요에 따라 피어가 둘 이상의 원장을 호스팅하는 것이 적합할 때도 있습니다.

여러 원장을 호스팅하는 피어입니다. 피어는 하나 이상의 원장을 호스팅하고 각 원장에는 0 개 이상의 체인 코드가 적용됩니다. 위의 사진에서 피어 P1이 원장 L1 및 L2를 호스팅한다는 것을 알 수 있습니다. 원장 L1은 체인 코드 S1을 사용하여 액세스됩니다. 원장 L2는 체인 코드 S1 및 S2를 사용하여 액세스 할 수 있습니다.

피어가 액세스하는 체인 코드를 호스팅하지 않고 원장 인스턴스를 호스팅하는 것이 완벽하게 가능할 수도 있지만 피어가 이와 같이 구성되는 것은 매우 드뭅니다. 대다수의 피어는 피어의 원장 인스턴스를 쿼리하거나 업데이트 할 수있는 체인 코드가 하나 이상 설치됩니다. 사용자가 외부 어플리케이션에서 사용할 수 있도록 체인 코드를 설치했는지에 대한 여부를 전달하는 것에 있어 언급 할 가치가 있으며, 피어는 항상 존재하는 특별한 시스템 체인 코드 도 가지고 있습니다 . 이 항목에서는 이러한 항목에 대해 자세히 설명하지 않습니다.

다중 Chain Code

피어가 가지고있는 원장의 수와 해당 원장에 액세스 할 수있는 체인 코드의 수 사이에는 고정된 관계가 없습니다. 피어는 많은 체인 코드와 많은 원장을 사용할 수 있습니다.

여러 체인 코드를 호스팅하는 피어의 예입니다. 각 원장에는 다수의 체인 코드가있어 액세스 할 수 있습니다. 이 예에서 피어 P1은 원장 L1 및 L2를 호스팅한다는 것을 알 수 있습니다. L1은 체인 코드 S1 및 S2에 의해 액세스되는 반면 L2는 S3 및 S1에 의해 액세스됩니다. S1은 L1과 L2 모두에 액세스 할 수 있음을 알 수 있습니다.

우리는 이후 피어에게 여러 원장이나 여러 개의 체인 코드를 호스팅 할 때 Hyperledger Fabric 의 Channel 개념 이 중요한 이유를 알아 보겠습니다.

어플리케이션 및 피어

이제 어플리케이션이 피어와 상호 작용하여 원장에 액세스하는 방법을 보여 드리겠습니다. 원장 - 쿼리 상호 작용에는 어플리케이션과 피어간에 간단한 3 단계 대화가 포함됩니다. 장부 - 갱신 상호 작용은 좀 더 복잡하고 두 가지 추가 단계가 필요합니다. Hyperledger Fabric을 시작하는 데 도움이 되도록 단계를 단순화했지만 걱정하지 마십시오. 원장 쿼리의 원장 업데이트 트랜잭션 스타일과 비교하여 어플리케이션 - 피어 상호 작용의 차이점을 이해하는 것이 가장 중요합니다.

원장 및 체인 코드에 액세스해야하는 경우 항상 피어에 연결됩니다. Hyperledger Fabric Software Development Kit(SDK)을 사용하면 프로그래머가 쉽게 어플리케이션을 작성할 수 있습니다. API를 사용하여 어플리케이션에서 피어에 연결하고 체인 코드를 호출하여 트랜잭션을 생성하고 네트워크에 트랜잭션을 제출하여 주문을 받고 분산 원장에게 커밋하고 이벤트를 수신 할 수 있을 때 이 과정이 완료된 것입니다.

피어 연결을 통해 어플리케이션은 체인 코드를 실행하여 장부를 쿼리하거나 업데이트 할 수 있습니다. 장부 쿼리 트랜잭션의 결과는 즉시 반환되는 반면 원장 업데이트는 어플리케이션, 피어 및 주문자의 상호작용보다 더욱 복잡한 상호 작용을 수반합니다. 조금 더 자세하게 조사해 봅시다.

피어는 주문자와 함께 모든 원장에게 장부가 최신 상태로 유지되도록합니다. 이 예제에서 어플리케이션 A는 P1에 연결하고 체인 코드 S1을 호출하여 원장 L1을 쿼리하거나 업데이트합니다. P1은 S1을 호출하여 쿼리 결과 또는 제안 된 원장 갱신을 포함하는 제안 응답을 생성합니다. 어플리케이션 A가 제안 응답을 받고 쿼리에 대해 프로세스가 완료되었습니다. 업데이트의 경우 A는 모든 응답에서 트랜잭션을 작성하고 주문을 위해 O1로 전송합니다. O1은 네트워크에서 블록으로 트랜잭션을 수집하여이를 P1을 포함한 모든 피어에 배포합니다. P1은 L1에 적용하기 전에 트랜잭션의 유효성을 검사합니다. L1이 업데이트되면, P1은 A가 수신 한 이벤트를 생성하여 완료를 나타냅니다.

피어는 쿼리 요구에 필요한 모든 정보가 피어의 원장 사본에 있으므로 쿼리 결과를 즉시 어플리케이션에 반환 할 수 있습니다. 피어는 다른 피어와 소통하여 어플리케이션에 쿼리를 반환하지 않습니다. 그러나 어플리케이션은 하나 이상의 피어에 연결하여 쿼리를 발행 할 수 있습니다. 예를 들어 여러 피어간에 결과를 확증하거나 정보가 부족한 것으로 의심되는 경우 다른 피어에서 최신 결과를 검색 할 수 있습니다. 날짜. 다이어그램에서 원장 쿼리는 간단한 3 단계 프로세스임을 알 수 있습니다.

업데이트 트랜잭션은 쿼리 트랜잭션과 동일한 방식으로 시작되지만 두 가지 추가 단계가 있습니다. 이라는 프로세스 - 원장 - 어플리케이션 업데이트도 원장 - 쿼리 어플리케이션과 달리 chaincode를 호출하는 피어에 연결할 수 있지만 다른 피어 먼저 변경에 동의해야하기 때문에, 개인 피어는이 시간에 원장 업데이트를 수행 할 수 없습니다 합의 . 따라서 피어는 제안 된 업데이트 (이 피어가 다른 피어의 사전 동의에 따라 적용될 업데이트)를 어플리케이션에 반환합니다 . 첫 번째 단계 인 네 번째 단계에서는 어플리케이션이 제안 된 업데이트와 일치하는 적절한 집합을 피어 네트워크 전체에 보내어 각 원장에 대한 약정을 위한 트랜잭션으로 전달해야합니다. 이것은 주문자를 사용하는 어플리케이션에 의해 달성됩니다. 트랜잭션을 블록으로 패키지화하고 이를 피어의 전체 네트워크에 배포하며, 각 피어의 원장 사본에 적용되기 전에 이를 확인할 수 있습니다. 이 전체 주문 처리가 완료되는 데 몇 시간이 걸리므로 5 단계 에서처럼 어플리케이션에 비동기 적으로 통지됩니다.

이 항목의 뒷부분에서이 주문 프로세스의 세부적인 특성에 대해 자세히 알아보고이 프로세스에 대한 자세한 내용은 트랜잭션 흐름 항목을 참조하십시오 .

피어 및 채널

이 주제는 채널이 아닌 피어에 관한 내용이지만 피어가 서로 상호 작용하는 방식을 이해하고 채널을통해 어플리케이션을 이해하는 데 약간의 시간을 투자 할 가치가 있습니다. 블록 체인 네트워크 내의 구성 요소 집합이 개인적으로 통신하고 상호 작용할 수 있는 메커니즘 입니다.

이러한 구성 요소는 일반적으로 피어 노드, 발주자 노드 및 어플리케이션이며 채널에 가입함으로써 함께 모여 해당 채널에 대한 원장의 동일한 복사본을 공동으로 공유하고 관리하는 데 동의합니다. 개념적으로 채널은 친구 그룹과 유사하다고 생각할 수 있습니다 (채널 회원은 확실히 친구 일 필요는 없습니다!). 한 사람에게는 여러 그룹의 친구가있을 수 있으며, 각 그룹에는 함께하는 활동이 있습니다. 이 그룹들은 완전히 별개의 그룹 일 수도 있고 (취미 친구들의 그룹과 비교하여 일하는 친구 그룹 일 수도 있습니다.), 또는 그들 사이에 크로스 오버가있을 수 있습니다. 그럼에도 불구하고 각 그룹은 일종의 "규칙"을 가진 자체 엔티티입니다.

채널을 사용하면 특정 피어 집합과 어플리케이션 집합이 블록 체인 네트워크 내에서 서로 통신 할 수 있습니다. 이 예시에서, 어플리케이션 A는 채널 C를 사용하여 피어 P1 및 P2와 직접 통신 할 수 있습니다.이 채널을 특정 어플리케이션과 피어 간의 통신 경로로 생각할 수 있습니다. (간략하게하기 위해 해당 다이어그램에는 주문자가 표시되지 않지만 제대로 작동하는 네트워크에 있어야합니다.)

우리는 피어들이하는 것과 같은 방식으로 채널이 존재하지 않는다는 것을 알았습니다. 채널을 물리적 피어 집단에 의해 형성된 논리적 구조로 생각하는 것이 더 적절합니다. 이 것을 이해하는 것이 중요합니다. 피어는 채널에 대한 액세스 및 관리를 위한 제어 지점을 제공합니다 .

피어 및 조직

이제 피어와 원장, 체인 코드 및 채널과의 관계를 이해하면 여러 조직이 모여 블록 체인 네트워크를 구성하는 방법을 알 수 있습니다.

블록 체인 네트워크는 단일 조직 이라기보다는 조직의 집합에 의해 관리됩니다. 피어들은 이러한 종류의 분산 네트워크가 이러한 조직에 의해 소유되고 네트워크에 대한 연결 지점이기 때문에 구축되는 방식의 핵심입니다.

여러 조직이있는 블록 체인 네트워크의 피어. 블록 체인 네트워크는 다른 조직이 소유한 피어들로 구성됩니다. 이 예에서는 네트워크를 형성하기 위해 8 명의 피어에 기여하는 4 개의 조직을 볼 수 있습니다. 채널 C는 네트워크 N-P1, P3, P5, P7 및 P8에서 이러한 피어 중 다섯 개를 연결합니다. 이 조직이 소유 한 다른 피어는이 채널에 가입하지 않았지만 일반적으로 하나 이상의 다른 채널에 가입합니다. 특정 조직에서 개발 한 어플리케이션은 다른 조직의 어플리케이션과 마찬가지로 자신의 조직의 피어와 연결됩니다. 다시 말하지만, 간단하게하기 위해이 다이어그램에는 주문자 노드가 표시되지 않습니다.

블록 체인 네트워크의 형성 과정을 파악할 수 있어야합니다. 네트워크는 자원을 제공하는 여러 조직에 의해 형성되고 관리됩니다. 피어는이 항목에서 논의하는 리소스이지만 조직에서 제공하는 리소스는 단순한 것 이상입니다. 여기서 일하는 원칙이 있습니다. 네트워크가 말 그대로 조직이 개별 리소스를 집단 네트워크에 기여하지 않으면 존재하지 않습니다. 또한 네트워크는 이러한 공동 작업 조직에서 제공하는 리소스로 확장 및 축소됩니다.

위 의 예 에서 조직이 피어를 제공하지 않은 경우 네트워크 ( N )가 존재하지 않는다는 것을 볼 수 있습니다 (주문 서비스 이외). 중앙 리소스 가 없습니다. 이는 조직이 조직에서 자원을 기여할 때까지 그리고 조직이 자원을 기여할 때까지 네트워크가 의미있는 의미로 존재하지 않는다는 사실을 반영합니다. 또한 네트워크는 개별 조직에 의존하지 않습니다. 어떤 조직이 어떤 조직에 출입 할지라도 조직이 남아있는 한 계속 존재할 것입니다. 이것은 네트워크가 분산화된다는 의미의 중심에 있습니다.

위의 예시와 같이 다른 조직의 어플리케이션 은 동일하거나 다를 수 있습니다. 그 이유는 어플리케이션이 피어의 원장 사본을 어떻게 처리하는지는 전적으로 조직에 달려 있기 때문입니다. 즉, 각각의 피어가 정확히 동일한 원장 데이터를 호스팅하더라도 어플리케이션 논리와 표시 논리가 조직마다 다를 수 있음을 의미합니다.

어플리케이션은 필요한 원장 상호 작용의 특성에 따라 조직의 피어 또는 다른 조직의 피어와 연결됩니다. 원장 - 쿼리 상호 작용의 경우 일반적으로 어플리케이션이 자체 조직의 피어와 연결됩니다. 원장 - 업데이트 상호 작용의 경우 원장 업데이트를 승인하는 데 필요한 모든 조직의 피어에게 어플리케이션을 연결해야하는 이유를 나중에 알 수 있습니다.

피어 및 신원

이제 다른 조직의 피어들이 함께 모여 블록 체인 네트워크를 구성하는 방법을 보았으므로 관리자가 조직에 피어를 할당하는 방법을 이해하는 데 잠시 시간을 할애 할 가치가 있습니다.

피어는 특정 인증 기관의 디지털 인증서를 통해 ID를 할당받습니다. X.509 디지털 인증서가이 가이드의 다른 곳에서 작동하는 방식에 대해 더 많이 읽을 수 있지만 디지털 인증서는 피어에 대한 검증 가능한 많은 정보를 제공하는 ID 카드와 같다고 생각할 수 있습니다. 네트워크의 모든 피어는 소유 조직의 관리자가 디지털 인증서를 할당받습니다 .

피어가 채널에 연결되면 디지털 인증서는 채널 MSP를 통해 소유 조직을 식별합니다. 이 예에서 P1과 P2는 CA1이 발행 한 ID를가집니다. 채널 C는 채널 구성의 정책에서 CA1의 ID가 ORG1.MSP를 사용하여 Org1과 연관되어야한다고 결정합니다. 마찬가지로 P3과 P4는 ORG2.MSP에 의해 Org2의 일부로 식별됩니다.

피어가 채널을 사용하여 블록 체인 네트워크에 연결할 때마다 채널 구성의 정책은 피어의 ID를 사용하여 해당 권한을 결정합니다. 조직에 대한 ID의 매핑은 멤버쉽 서비스 공급자(MSP) - 피어가 특정 조직의 특정 역할에 할당되는 방식을 결정하므로 이에 따라 블록 체인 리소스에 대한 적절한 액세스 권한이 부여됩니다. 또한 피어는 단일 조직에서만 소유 할 수 있으므로 단일 MSP와 연결됩니다. 이 항목의 뒷부분에서 피어 액세스 제어에 대해 자세히 알아보고이 가이드의 MSP 및 액세스 제어 정책에 대한 전체 항목을 제공합니다. 그러나 지금은 MSP가 블록 체인 네트워크에서 개별 신원과 특정 조직의 역할 간 연계를 제공한다고 생각하십시오.

그리고 잠시 빗나가려면 블록 체인 네트워크와 상호 작용하는 모든 것 뿐만 아니라 피어 가 디지털 인증서와 MSP에서 조직 정체성을 획득하십시오 . 블록 체인 네트워크와 상호 작용하려는 경우 피어, 어플리케이션, 최종 사용자, 관리자, 주문자는 ID 및 관련 MSP가 있어야합니다. 신원을 사용하여 블록 체인 네트워크와 상호 작용하는 모든 엔티티 (주체)에게 이름을 제공합니다. 이 가이드의 다른 곳에서 교장 및 조직에 관해 더 많은 것을 배울 수는 있지만, 지금은 피어에 대한 이해를 계속하기에 충분합니다.

마지막으로 피어가 실제로 위치하는 곳은 중요하지 않습니다. 클라우드 또는 조직 중 하나가 소유 한 데이터 센터 나 로컬 시스템에 상주 할 수 있습니다. 특정 조직이 소유하고 있습니다. 위의 예에서 P3은 Org1의 데이터 센터에서 호스팅 될 수 있지만 CA2와 연결된 디지털 인증서가있는 한 Org2가 소유합니다.

피어 및 주문자

우리는 피어들이 피어 - 연결된 어플리케이션에 의해 질의되고 업데이트 될 수있는 원장과 체인 코드 계약을 호스팅하는 블록 체인 네트워크를 형성하는 것을 보아 왔습니다. 그러나 어플리케이션과 피어가 서로 상호 작용하여 모든 피어의 원장이 일관성을 유지하도록하는 메커니즘은 주문 자라고불리는 특수 노드에 의해 조정되며 , 이제 우리가주의를 돌리는 노드입니다.

하나의 피어가 자체적으로 원장을 업데이트 할 수 없으므로 업데이트 트랜잭션은 쿼리 트랜잭션과 상당히 다릅니다. 이는 네트워크의 다른 피어의 동의가 필요하기 때문입니다. 피어는 네트워크의 다른 피어가 피어의 로컬 원장에 적용되기 전에 원장 업데이트를 승인해야합니다. 이 프로세스를 합의 라고 하며 쿼리보다 완료하는 데 훨씬 오래 걸립니다. 그러나 트랜잭션을 승인해야하는 모든 피어가 그렇게하고 트랜잭션이 원장에게 맡겨지면 피어는 연결된 어플리케이션에 원장이 업데이트되었음을 ​​알립니다. 이 섹션에서 피어 및 주문자가 합의 프로세스를 관리하는 방법에 대해 자세히 자세히 설명하려고합니다.

특히 원장을 업데이트하려는 어플리케이션은 3 단계 프로세스와 관련되어 있으므로 블록 체인 네트워크의 모든 피어가 원장을 서로 일관되게 유지할 수 있습니다. 첫 번째 단계에서 어플리케이션은 승인 된 보조 프로그램의 하위 집합과 함께 작동합니다 . 각 하위 프로그램 은 제안 된 원장 업데이트를 어플리케이션에 대한 보증으로 제공하지만 원장 사본에 제안 된 업데이트를 적용하지 않습니다. 두 번째 단계에서는 이러한 별도의 보증을 트랜잭션으로 수집하여 블록으로 패키지화합니다. 마지막 단계에서 이러한 블록은 각 트랜잭션이 확인 된 모든 피어로 다시 분산되어 해당 피어의 원장 사본에 적용됩니다.

알 수 있듯이 주문자 노드는이 프로세스의 핵심입니다. 따라서 어플리케이션 및 피어가 주문자를 사용하여 분산 된 복제 원장에 일관되게 적용 할 수있는 원장 업데이트를 생성하는 방법에 대해 좀 더 자세히 살펴 보겠습니다.

1 단계 : 제안

트랜잭션 워크 플로우의 1 단계에는 애플리케이션과 피어 집합 간의 상호 작용이 포함됩니다. 이는 주문자를 포함하지 않습니다. 1 단계는 제안 된 체인 코드 호출의 결과에 동의하도록 다른 조직의 승인하는 피어에게 요청하는 어플리케이션에만 관련됩니다.

1 단계를 시작하기 위해 어플리케이션은 트랜잭션 제안서를 생성하여 필요한 피어 집합을 보냅니다. 그런 다음 각 피어는 트랜잭션 제안서 응답을 생성하기 위해 트랜잭션 제안서를 사용하여 독립적으로 체인 코드를 실행합니다. 이 업데이트는 원장에 적용되지 않지만 피어가 서명하고 어플리케이션에 반환합니다. 신청서가 충분한 수의 서명 된 제안서 응답을 받으면 거래 흐름의 첫 번째 단계가 완료됩니다. 이 단계를 조금 더 자세히 살펴 보겠습니다.

거래 제안서는 승인 된 제안 응답을 반환하는 피어에 의해 독립적으로 실행됩니다. 이 예에서 애플리케이션 A1은 트랜잭션 T1 제안서 P를 생성하여 채널 C에서 피어 P1과 피어 P2 모두에게 전송합니다. P1은 트랜잭션 T1 제안서 P를 사용하여 S1을 실행하여 E1에서 보증하는 트랜잭션 T1 응답 R1을 생성합니다. 독립적으로 P2는 트랜잭션 T1 제안서 P를 사용하여 S1을 실행하여 E2로 보증하는 트랜잭션 T1 응답 R2를 생성합니다. 어플리케이션 A1은 거래 T1에 대해 두 가지 승인 된 응답, 즉 E1과 E2를받습니다.

처음에는 일련의 제안 된 원장 업데이트를 생성하기 위해 어플리케이션이 피어 집합을 선택합니다. 어떤 피어가 어플리케이션에서 선택합니까? 네트워크에 의해 승인되기 전에 제안 된 장부 변경을 승인해야하는 조직 집합을 정의 하는 보증 정책 (chaincode에 대해 정의 됨) 에 따라 달라집니다 . 이것은 사실상 합의를 달성한다는 것을 의미합니다. 문제가되는 모든 조직은 모든 ​​원장의 장부에 승인 되기 전에 제안 된 원장 변경을 승인해야합니다 .

피어는 디지털 서명을 추가하고 개인 키를 사용하여 전체 페이로드에 서명함으로써 제안 응답을 보증합니다. 이 보증은 이후에이 조직의 피어가 특정 응답을 생성했음을 입증하는 데 사용될 수 있습니다. 이 예에서 피어 P1이 조직 Org1 소유이면 보증 E1은 "원장 L1의 트랜잭션 T1 응답 R1이 Org1 피어 P1에 의해 제공되었습니다!"라는 디지털 증거에 해당합니다.

1 단계는 신청서가 충분한 피어로부터 서명 된 제안서 응답을 받으면 끝납니다. 서로 다른 피어가 동일한 거래 제안서에 대해 어플리케이션에 대해 서로 다르기 때문에 일치하지 않는 거래 응답을 반환 할 수 있습니다 . 다른 국가의 원장이있는 다른 피어에게 결과가 서로 다른 시간으로 생성되었을 수도 있습니다.이 경우 어플리케이션은 단순히 최신 제안 응답을 요청할 수 있습니다. 체인 코드가 비 결정적이기 때문에 결과는 다를 수 있습니다.. 비 결정 성은 체인 코드 및 원장의 적이며, 발생하는 경우 일관성없는 결과가 원장에게 적용될 수 없기 때문에 제안 된 거래에 심각한 문제가 있음을 나타냅니다. 개별 피어는 트랜잭션 결과가 비 결정적이라는 것을 알 수 없습니다. 비 결정 성을 감지하기 전에 트랜잭션 응답을 함께 수집하여 비교해야합니다. 엄밀히 말하면, 이것으로도 충분하지는 않지만, 비 결정성에 대해 자세히 논의하는 트랜잭션 주제에 대해서는이 논의를 연기합니다.

1 단계가 끝나면 어플리케이션은 일관성없는 트랜잭션 응답을 자유롭게 버리고이를 원할 경우 트랜잭션 워크 플로를 효과적으로 종료합니다. 나중에 애플리케이션이 일관성없는 트랜잭션 응답을 사용하여 원장을 업데이트하려고하면 거부 될 것입니다.

2 단계 : 포장

트랜잭션 워크 플로의 두 번째 단계는 패키징 단계입니다. 주문자는이 프로세스의 중추적 인 역할을합니다. 많은 애플리케이션에서 승인 된 거래 제안 응답을 포함하는 거래를받습니다. 그것은 각 거래를 다른 거래와 비교하여 주문하고, 트랜잭션의 일괄 처리를 원래의 승인하는 피어를 포함하여 주문자에게 연결된 모든 피어에게 배포 할 준비가 된 블록으로 패키지화합니다.

주문자 노드의 첫 번째 역할은 제안 된 원장 갱신을 패키지하는 것입니다. 이 예에서 어플리케이션 A1은 E1 및 E2가 승인 한 트랜잭션 T1을 순서자 O1에 전송합니다. 병행하여, 어플리케이션 A2는 E1이 승인 한 트랜잭션 T2를 발주자 O1에게 전송합니다. O1은 어플리케이션 A1의 트랜잭션 T1과 어플리케이션 A2의 트랜잭션 T2를 네트워크의 다른 어플리케이션에서 다른 트랜잭션과 함께 B2 블록으로 패키지화합니다. B2에서 트랜잭션 순서는 T1, T2, T3, T4, T6, T5입니다. 이러한 트랜잭션이 주문자 노드에 도착한 순서가 아닐 수 있습니다! (이 예제는 매우 단순화 된 주문자 구성을 보여줍니다.)

발주자는 특정 채널의 네트워크에있는 여러 어플리케이션에서 제안 된 원장 갱신을 동시에받습니다. 이 작업은 제안 된 업데이트를 잘 정의 된 순서로 정렬 하고 이후 배포를 위해 블록으로 패키지화하는 것 입니다. 이 블록은 될 것이다 블록 blockchain의! 일단 주문자가 원하는 크기의 블록을 생성하거나 최대 경과 시간 후에 블록은 특정 채널에서 연결된 모든 피어로 전송됩니다. 이 블록이 3 단계에서 어떻게 처리되는지 살펴 보겠습니다.

한 블록 내의 거래 순서가 주문자에게 거래가 도착한 순서와 반드시 같지는 않다는 점은 주목할 가치가 있습니다! 트랜잭션은 블록에 임의의 순서로 패키징 할 수 있으며 실행 순서가되는 순서입니다. 중요한 것은이 때문이다 인 것이 아니라, 엄격한 위해 어떤 순서입니다.

블록 내에서의 트랜잭션의 엄격한 주문은 Hyperledger Fabric을 동일한 트랜잭션을 여러 블록으로 패키징 할 수있는 다른 블록 체인과 조금 다릅니다. Hyperledger Fabric에서는 이러한 일이 발생할 수 없습니다 . 거래가 블록에 쓰여지면 장부의 위치가 확실하게 보장되기 때문에 주문자 컬렉션에 의해 생성 된 블록이 최종 이라고합니다. Hyperledger Fabric의 최종성은 원장 포크 로 알려진 비참한 사건이 발생할 수 없다는 것을 의미 합니다. 블록에서 트랜잭션을 캡처하면 추후 시점에서 해당 트랜잭션에 대한 내역을 다시 쓸 수 없습니다.

우리는 또한 피어가 원장과 체인 코드를 호스팅하는 반면에 주문자는 그렇지 않음을 알 수 있습니다. 주문자에게 도착한 모든 거래는 기계적으로 하나의 블록에 포장되어 있습니다. 주문자는 거래의 가치에 대해 아무런 판단도하지 않습니다. 이것은 Hyperledger Fabric의 중요한 동작입니다. 모든 트랜잭션은 엄격한 순서로 정렬되며, 트랜잭션은 삭제되거나 우선 순위가 결정됩니다.

2 단계가 끝나면 주문자는 제안 된 거래 업데이트를 수집하고 주문하고,이를 블록으로 포장하여 배포 할 수있는 간단하지만 중요한 프로세스에 책임이 있음을 확인합니다.

3 단계 : 유효성 검사

거래 워크 플로의 최종 단계에는 주문자로부터 피어에게 블록을 배포하고 이후 유효성 검사를 수행하여 장부에 적용 할 수 있습니다. 특히, 각 피어에서 블록 내의 모든 트랜잭션은 장부에 적용되기 전에 모든 관련 조직에서 일관되게 보증되도록 유효성이 검사됩니다. 실패한 트랜잭션은 감사를 위해 보관되지만 장부에 적용되지 않습니다.

주문자 노드의 두 번째 역할은 피어에 블록을 배포하는 것입니다. 이 예에서, 순서 Y O1은 블록 B2를 피어 P1과 피어 P2로 분 h합니다. 피어 P1은 블록 B2를 처리하여 새로운 블록이 P1의 원장 L1에 추가됩니다. 병렬 적으로 피어 P2는 블록 B2를 처리하여 새로운 블록이 P2의 원장 L1에 추가됩니다. 이 프로세스가 완료되면 원장 L1이 피어 P1 및 P2에서 일관되게 업데이트되고 각각 연결된 어플리케이션에 트랜잭션이 처리되었음을 알릴 수 있습니다.

3 단계는 주문자가 블록을 연결된 모든 피어에게 배포하는 것으로 시작됩니다. 피어는 새로운 블록이 생성되면 주문자에게 연결된 모든 피어가 새 블록의 사본을 전송하도록 채널의 주문자에게 연결됩니다. 각 피어는이 블록을 독립적으로 처리하지만 채널의 다른 모든 피어와 정확히 같은 방식으로 처리합니다. 이렇게하면 원장이 일관되게 유지 될 수 있습니다. 모든 피어가 발주자와 연결될 필요는 없다는 점도 주목할 가치가 있습니다. 피어는 험담 프로토콜을 사용하여 블록을 다른 피어에게 캐스케이드 할 수 있으며 , 이들은 또한 독자적으로 처리 할 수 ​​있습니다. 그러나 그 토론을 다른 시간에 남겨 둡시다!

블록을 수신하면 피어는 각 트랜잭션을 블록에 나타나는 순서대로 처리합니다. 모든 거래에 대해 각 피어는 트랜잭션 을 생성 한 체인 코드 의 보증 정책 에 따라 필요한 조직이 해당 트랜잭션을 보증했는지 확인 합니다. 예를 들어, 일부 거래는 단일 조직이 보증해야하는 반면, 다른 거래는 유효한 것으로 간주되기 전에 여러 보증을 요구할 수 있습니다. 이 유효성 확인 프로세스는 모든 관련 조직이 동일한 결과 또는 결과를 생성했음을 검증합니다.

트랜잭션이 올바르게 승인되면 피어는이를 원장에게 적용하려고 시도합니다. 이렇게하려면 피어가 원장 일관성 검사를 수행하여 제안 된 업데이트가 생성되었을 때 원장의 현재 상태가 원장의 상태와 호환되는지 확인해야합니다. 트랜잭션이 완전히 승인 된 경우에도 항상 가능하지는 않습니다. 예를 들어 다른 트랜잭션이 원장의 동일한 자산을 업데이트하여 트랜잭션 업데이트가 더 이상 유효하지 않아 더 이상 적용 할 수 없게 될 수 있습니다. 이러한 방식으로 각 피어의 원장 사본은 각각 동일한 유효성 검사 규칙을 따르므로 네트워크를 통해 일관되게 유지됩니다.

피어가 각 개별 트랜잭션의 유효성을 성공적으로 검사 한 후 원장을 업데이트합니다. 실패한 트랜잭션은 원장에 적용되지 않지만 성공적인 거래와 같이 감사 목적으로 유지됩니다. 이는 피어 블록이 블록의 각 트랜잭션에서 유효하거나 유효하지 않은 표시기를 제외하고 주문자로부터 수신 된 블록과 거의 동일 함을 의미합니다.

3 단계에서는 체인 코드 실행이 필요하지 않습니다. 이는 1 단계에서만 수행되며 중요합니다. 즉, 체인 코드는 블록 체인 네트워크 전체가 아닌 승인 노드에서만 사용할 수 있어야합니다. 이는 체인 코드의 논리를 기밀로 유지하여 조직을지지하는 데 도움이되는 경우가 많습니다. 이는 거래를 승인했는지 여부에 상관없이 채널의 모든 피어에게 공유되는 체인 코드 (거래 제안서 응답)의 출력과 대조됩니다. 이 인증 피어링 전문가는 확장 성을 높이기 위해 설계되었습니다.

마지막으로, 블록이 피어의 원장에게 맡길 때마다 해당 피어는 적절한 이벤트를 생성합니다 . 블록 이벤트 는 전체 블록 컨텐츠를 포함하는 반면, 블록 트랜잭션 이벤트 는 블록의 각 트랜잭션의 유효성 검증 또는 무효화 여부와 같은 요약 정보만을 포함합니다. 체인 코드 실행이 생성 한 체인 코드 이벤트도이 시점에 게시 할 수 있습니다. 어플리케이션은 이러한 이벤트 유형에 대해 등록 할 수 있으므로 이벤트 유형을 통지 할 수 있습니다. 이러한 통지는 트랜잭션 워크 플로의 세 번째이자 마지막 단계입니다.

요약하면 3 단계는 주문 원이 원장에 일관되게 적용하여 생성 한 블록을 확인합니다. 트랜잭션을 블록으로 엄격하게 정렬하면 각 피어는 트랜잭션 업데이트가 블록 체인 네트워크 전체에 일관되게 적용되는지 확인할 수 있습니다.

주문자 및 합의

이 전체 트랜잭션 워크 플로우 프로세스는 모든 피어가 주문자가 중재하는 프로세스에서 트랜잭션의 순서 및 내용에 대한 합의에 도달했기 때문에 합의 라고 합니다. 합의는 여러 단계의 프로세스이며, 프로세스가 완료되면 어플리케이션은 원장 업데이트 만 통보됩니다. 이는 다른 피어에서 약간 다른 시간에 발생할 수 있습니다.

우리는 향후 발주자 주제에 대해 더 자세하게 발주자에 대해 논의 할 예정이지만, 당분간은 발주자를 피어 신청서의 장부 업데이트를 수집하여 배포하여 장부에 검증하고 포함시키는 노드로 생각하십시오.

그게 다야! 이제 Hyperledger Fabric과 관련된 피어 및 다른 구성 요소에 대한 둘러보기를 마쳤습니다. 우리는 피어들이 네트워크를 구성하고 체인 코드와 장부를 구성하고 트랜잭션 제안 및 응답을 처리하며 일관되게 트랜잭션 업데이트를 적용하여 장부를 최신 상태로 유지하는 것을 여러 측면에서 가장 근본적인 요소로 인식했습니다.

Ledger

원장 (ledger)은 모든 상태 전이에 대해 순서를 변경하고 변조를 방지하는 기록입니다. 상태 전이는 참여 당사자가 제출 한 체인 코드 호출 ( "트랜잭션")의 결과입니다. 각 트랜잭션은 생성, 갱신 또는 삭제와 같이 원장에게 커밋되는 일련의 자산 키 - 값 쌍을 생성합니다.

원장은 불변의 시퀀스 된 레코드를 블록으로 저장하는 블록 체인 (chainchain)과 현재 상태를 유지하는 상태 데이터베이스로 구성됩니다. 채널 당 1 개의 원장이 있습니다. 각 피어는 회원 인 각 채널에 대해 원장 사본을 보관합니다.

체인

체인은 각 블록에 N 개의 트랜잭션 시퀀스가 ​​들어있는 해시 - 링크 블록으로 구성된 트랜잭션 로그입니다. 블록 헤더는 이전 블록의 헤더 해시뿐만 아니라 블록 트랜잭션의 해시를 포함합니다. 이렇게하면 원장의 모든 트랜잭션이 순서가 지정되고 함께 암호로 링크됩니다. 즉 해시 링크를 손상시키지 않고 원장 데이터를 무단으로 변경할 수 없습니다. 최신 블록의 해시는 이전에 온 모든 트랜잭션을 나타내므로 모든 피어가 일관되고 신뢰할 수있는 상태에 있음을 보장 할 수 있습니다.

체인은 피어 파일 시스템 (로컬 또는 연결된 스토리지)에 저장되어 효율적으로 블록 체인 작업 부하의 추가 전용 특성을 지원합니다.

상태 데이터베이스

원장의 현재 상태 데이터는 체인 트랜잭션 로그에 포함 된 모든 키의 최신 값을 나타냅니다. 현재 상태는 채널에 알려진 모든 최신 키 값을 나타내므로 때로는 세계 상태라고합니다.

체인 코드 호출은 현재 상태 데이터에 대해 트랜잭션을 실행합니다. 이러한 체인 코드 상호 작용을 매우 효율적으로 만들기 위해 모든 키의 최신 값이 상태 데이터베이스에 저장됩니다. 상태 데이터베이스는 단순히 체인의 트랜잭션 로그에 대한 인덱싱 된 뷰이므로 언제든지 체인에서 다시 생성 할 수 있습니다. 상태 데이터베이스는 트랜잭션이 수락되기 전에 피어 시작시 자동으로 복구됩니다 (또는 필요한 경우 생성됩니다).

상태 데이터베이스 옵션에는 LevelDB 및 CouchDB가 포함됩니다. LevelDB는 피어 프로세스에 포함 된 기본 상태 데이터베이스이며 키 코드 값 쌍으로 체인 코드 데이터를 저장합니다. CouchDB는 체인 코드 데이터를 JSON으로 모델링 할 때 추가 쿼리 지원을 제공하는 선택적 대체 외부 상태 데이터베이스로서 JSON 컨텐트에 대한 풍부한 쿼리를 허용합니다. 참조 국가 데이터베이스로 CouchDB를을 CouchDB를에 대한 자세한 정보를 얻을 수 있습니다.

거래 흐름

높은 수준에서 트랜잭션 흐름은 응용 프로그램 클라이언트가 특정 승인하는 동료에게 보내는 트랜잭션 제안으로 구성됩니다. 인증 피어는 클라이언트 서명을 확인하고 체인 코드 기능을 실행하여 트랜잭션을 시뮬레이트합니다. 출력은 chaincode 결과, chaincode (읽기 세트)에서 읽은 키 - 값 버전 세트 및 chaincode (쓰기 세트)로 작성된 키 / 값 세트입니다. 제안서 응답은 보증 서명과 함께 고객에게 반송됩니다.

클라이언트는 보증 페이 션을 트랜잭션 페이로드로 어셈블하고이를 주문 서비스로 브로드 캐스트합니다. 주문 서비스는 정렬 된 트랜잭션을 채널의 모든 피어에게 블록으로 전달합니다.

committal 전에 동료는 거래를 확인합니다. 먼저 지정된 피어의 정확한 할당이 결과에 서명하고 트랜잭션 페이로드에 대해 서명을 인증하는지 확인하기 위해 보증 정책을 확인합니다.

둘째, 동료는 데이터 무결성을 보장하고 이중 지출과 같은 위협으로부터 시스템을 보호하기 위해 트랜잭션 읽기 세트에 대한 버전 확인을 수행합니다. Hyperledger Fabric은 트랜잭션을 병렬 처리하여 (엔도 서별로) 처리량을 늘리고 모든 피어가 커밋시 다른 트랜잭션이 읽은 데이터를 수정하지 않았는지 확인합니다. 즉, 체인 코드 실행 중에 읽은 데이터가 실행 (승인) 시간 이후 변경되지 않았으므로 실행 결과가 여전히 유효하며 원장 상태 데이터베이스에 커밋 될 수 있습니다. 읽은 데이터가 다른 트랜잭션에 의해 변경된 경우 블록의 트랜잭션은 유효하지 않은 것으로 표시되고 원장 상태 데이터베이스에 적용되지 않습니다. 클라이언트 응용 프로그램에 경고가 표시됩니다.

참고 항목 트랜잭션 흐름 , 세트 의미를 읽기 - 쓰기 및 국가 데이터베이스로 CouchDB를 거래 구조, 동시성 제어 및 상태 DB에 깊은 다이빙에 대한 항목을 참조하십시오.

Use Cases

Hyperledger 요구 사항 WG는 많은 블록 체인 사용 사례를 문서화하고 여기 에 인벤토리를 유지 관리합니다 .