[Hyperledger Fabric v1.1] 2. Key Concepts: Hyperledger Fabric model

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

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

 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 다이어그램을 확인하여 합의의 시각적 표현을 확인하십니오.