[Hyperledger Fabric v1.0] 2. KEY CONCEPTS(주요개념): Hyperledger Fabric Model(하이퍼레저 패브릭 모델)

해당 글은 Hyperledger Fabric 페이지의 게시글을 번역 및 정리한 자료입니다.

원본 사이트 : http://hyperledger-fabric.readthedocs.io/en/release/fabric_model.html

 Hyperledger Fabric Model ( 하이퍼레저 패브릭 모델 )

이 섹션에서는 포괄적이지만 사용자 정의가 가능한 엔터프라이즈 블록 체인 솔루션의 약속을 이행하는 Hyperledger Fabric에 포함된 주요 디자인 기능에 대해 간략히 설명합니다.

• 자산 - 자산 정의는 전체 식품에서 골동품 자동차, 통화 선물에 이르기까지 네트워크를 통해 거의 모든 가치를 교환할 수 있습니다.
• 체인 코드 - 체인 코드 실행은 트랜잭션 순서 지정에서 노드 유형에 따라 필요한 신뢰 수준 및 검증 수준을 제한하고 네트워크 확장성과 성능을 최적화합니다.
• 원장 특징 - 변경 불가능한 공유 원장은 각 채널의 전체 거래 내역을 인코딩하며 효율적인 감사 및 분쟁 해결을 위해 SQL과 유사한 쿼리 기능을 포함합니다.
• 채널을 통한 프라이버시 - 채널은 공통 네트워크에서 자산을 교환하는 경쟁 비즈니스 및 규제 대상 산업에서 요구되는 높은 프라이버시 및 기밀성을 지닌 다차원 트랜잭션을 가능하게 합니다.
• 보안 및 회원 서비스 - 허가된 회원은 신뢰할 수있는 블록 체인 네트워크를 제공합니다. 참가자 네트워크에서는 권한 있는 규제 기관 및 감사인이 모든 거래를 탐지하고 추적할 수 있습니다.
• 컨센서스 - 컨센서스에 대한 독창적인 접근 방식은 기업에 필요한 유연성과 확장성을 제공합니다.

자산 ( Assets )

자산은 유형(부동산 및 하드웨어)에서 무형(계약 및 지적 재산)까지 다양합니다. Hyperledger Fabric은 체인 코드 트랜잭션을 사용하여 자산을 수정할 수 있는 기능을 제공합니다.

자산은 하이퍼레저 패브릭에서 키 - 값 쌍의 모음으로 표시되며 상태 변경은 채널원장에서 트랜잭션으로 기록됩니다. 자산은 바이너리 및 / 또는 JSON 형식으로 표현될 수 있습니다.

Hyperledger Composer 도구를 사용하여 Hyperledger Fabric 응용 프로그램에서 자산을 쉽게 정의하고 사용할 수 있습니다.

체인코드 ( Chaincode )

체인 코드는 자산 또는 자산을 정의하는 소프트웨어 및 자산을 수정하기 위한 거래 지시 사항입니다. 즉, 비즈니스 논리입니다. 체인 코드는 키 값 쌍 또는 다른 상태 데이터베이스 정보를 읽거나 변경하기 위한 규칙을 시행합니다. 체인 코드 기능은 원장 현재 상태 데이터베이스에 대해 실행되며 거래 제안을 통해 시작됩니다. 체인 코드 실행은 네트워크에 제출되어 모든 피어의 원장에 적용될 수 있는 일련의 키 값 쓰기(쓰기 세트)를 초래합니다.

원장 특징 ( Ledger Features )

원장은 패브릭의 모든 상태 전이에 대한 순차적 인 변경 방지 기록입니다. 상태 전이는 참여 당사자가 제출 한 체인 코드 호출 ( '트랜잭션')의 결과입니다.

자산 키 - 값의 생성으로 쌍, 업데이트 또는 삭제 세트의 각 트랜잭션 결과를 원장에 기여하고 있습니다

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

• 키 기반 조회, 범위 쿼리 및 복합 키 쿼리를 사용하여 쿼리 및 업데이트 원장
• 풍부한 쿼리 언어를 사용하는 읽기 전용 쿼리 (CouchDB를 상태 데이터베이스로 사용하는 경우)
• 읽기 전용 히스토리 쿼리 - 키에 대한 원장 이력 조회, 데이터 출처 시나리오 활성화
• 트랜잭션은 chaincode (읽기 세트)에서 읽은 키 / 값의 버전과 chaincode (쓰기 세트)로 작성된 키 / 값의 버전으로 구성됩니다.
• 트랜잭션은 모든 endorsing 피어의 서명을 포함하며 ordering 서비스에 제출됩니다.
• 트랜잭션은 블록으로 정렬되어 ordering 서비스에서 채널의 피어에게 "전달"됩니다.
• peers는 보증(endorsement) 정책에 대한 거래를 확인하고 정책을 집행합니다.
• 블록을 추가하기 전에 체인 코드 실행 시간 이후에 읽은 자산의 상태가 변경되지 않았는지 확인하기 위해 버전 검사가 수행됩니다
• 거래가 확인되고 커밋되면 불변성이 있습니다.
• 채널의 원장에는 정책, 액세스 제어 목록 및 기타 관련 정보를 정의하는 구성 블록이 있습니다
• 채널에는 멤버쉽 서비스 공급자(MSP) 인스턴스가 포함되어 있어 다른 인증 기관에서 암호 자료를 파생시킬 수 있습니다.

데이터베이스, 저장소 구조 및 "쿼리 기능"에 대한 자세한 내용은 Ledger 항목을 참조하십시오.

채널을 통한 개인 정보 보호 ( Privacy through Channels )

Hyperledger Fabric은 채널별로 불변 원장을 사용하고 자산의 현재 상태 (즉, 키 값 쌍 업데이트)를 조작하고 수정할 수있는 체인 코드를 사용합니다. 원장은 채널 범위에 존재합니다. 모든 참가자가 하나의 공통 채널에서 운영되고 있다고 가정하면 전체 네트워크에서 공유 할 수 있습니다. 또는 특정 참여자 집합 만 포함하도록 사유화 할 수 있습니다.

후자의 시나리오에서,이 참여자는 별도의 채널을 작성하여 거래 및 원장을 분리 / 분리합니다. 전체 투명성과 프라이버시 사이의 차이를 좁히고 자하는 시나리오를 해결하기 위해 체인 코드는 자산 상태에 액세스하여 읽기 및 쓰기를 수행해야하는 피어에만 설치할 수 있습니다 (즉, 체인 코드가 피어에 설치되어 있지 않은 경우 , 원장과 적절하게 인터페이스 할 수 없습니다). 데이터를 더 잘 모호하게하기 위해 체인 코드 내의 값은 장부에 추가하기 전에 AES와 같은 공통 암호화 알고리즘을 사용하여 부분적으로 또는 전체적으로 암호화 할 수 있습니다.

보안 및 회원 서비스 ( Security & Membership Services )

Hyperledger Fabric은 모든 참가자가 신원을 알고있는 트랜잭션 네트워크를 지원합니다. 공개 키 인프라는 조직, 네트워크 구성 요소 및 최종 사용자 또는 클라이언트 응용 프로그램에 연결된 암호화 인증서를 생성하는 데 사용됩니다. 결과적으로 데이터 액세스 제어는 광범위한 네트워크 및 채널 수준에서 조작되고 제어 될 수 있습니다. Hyperledger Fabric의 "허가 된"개념은 채널의 존재 및 기능과 함께 개인 정보 및 기밀성이 중요한 관심사 인 시나리오를 해결하는 데 도움이됩니다.

암호화 구현 및 Hyperledger Fabric에서 사용되는 서명, 확인, 인증 방법을 더 잘 이해 하려면 Membership Service Provider (MSP) 항목을 참조하십시오.

컨센서스 ( Consensus )

분배 원장 기술에서 합의는 최근에 단일 기능 내에서 특정 알고리즘과 동의어가되었습니다. 그러나 합의는 단순히 거래 순서에 동의하는 것 이상의 의미를 지니 며, 이러한 차별화는 제안 및 보증, 주문, 검증 및 약속에 이르기까지 전체 거래 흐름에서 기본적인 역할을 통해 Hyperledger Fabric에서 강조됩니다. 요컨대, 합의는 블록을 구성하는 일련의 트랜잭션의 정확성에 대한 완전한 원 검증으로 정의됩니다.

컨센서스는 블록 트랜잭션의 순서와 결과가 명시적인 정책 기준 검사를 충족하면 궁극적으로 달성됩니다. 이러한 확인 및 잔액은 거래의 수명주기 동안 발생하며 특정 거래 클래스를 보증해야하는 특정 회원 및 시스템 체인 코드를 보증하는 보증 정책의 사용을 포함하여 이러한 정책이 시행되고 유지되도록합니다. 공약을하기 전에 동료들은 이러한 시스템 체인 코드를 사용하여 충분한 보증이 존재하고 해당 단체에서 파생되었음을 확인합니다. 또한 트랜잭션이 포함 된 블록이 원장에 추가되기 전에 원장의 현재 상태가 동의되거나 동의되는 버전 확인이 수행됩니다.

수많은 승인, 유효성 및 버전 검사가 수행되는 것 외에도 트랜잭션 흐름의 모든 방향에서 진행중인 신원 확인이 진행 중입니다. 액세스 제어 목록은 네트워크의 계층 구조 (채널에 대한 서비스 주문)에서 구현되며 트랜잭션 제안이 다른 아키텍처 구성 요소를 통과 할 때 페이로드는 반복적으로 서명, 확인 및 인증됩니다. 결론적으로, 합의는 일련의 거래의 합의 된 주문에만 국한되는 것이 아니라 오히려 거래 제안이 의결에서 약속까지 진행되는 동안 진행되는 검증의 부산물로서 달성되는 중요한 특성입니다.

컨센서스를 시각적으로 나타내는 트랜잭션 흐름도를 확인하십시오 .