[Hyperledger Fabric v1.0] 5. ARCHITECTURE(아키텍트): Ledger(원장)

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

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

 Ledger(원장)

원장은 패브릭의 모든 상태 전이에 대한 순차적인 변조 방지 기록입니다. 상태 전이는 참여 당사자가 제출한 체인 코드 호출 ( '트랜잭션')의 결과입니다. 각 트랜잭션은 생성, 업데이트 또는 삭제와 같이 원장에게 커밋되는 일련의 자산 키 - 값 쌍을 생성합니다.

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

Chain(체인)

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

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

State Database(상태 데이터베이스)

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

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

Transaction Flow(거래 흐름)

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

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

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

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

트랜잭션 구조, 동시성 제어 및 상태 DB에 대해 자세히 알아 보려면 트랜잭션 흐름 및 읽기 - 쓰기 세트 의미 항목을 참조하십시오.

State Database options(상태 데이터베이스 옵션)

상태 데이터베이스 옵션에는 LevelDB 및 CouchDB (베타)가 포함됩니다. LevelDB는 피어 프로세스에 포함 된 기본 키 / 값 상태 데이터베이스입니다. CouchDB는 선택적 대체 외부 상태 데이터베이스입니다. LevelDB 키 / 값 저장소와 마찬가지로 CouchDB는 체인 코드로 모델링 된 모든 이진 데이터를 저장할 수 있습니다 (CouchDB 첨부 기능은 비 JSON 바이너리 데이터에 내부적으로 사용됩니다). 그러나 JSON 문서 저장소 인 CouchDB는 체인 코드 값 (예 : 에셋)을 JSON 데이터로 모델링 할 때 체인 코드 데이터에 대한 추가 쿼리를 추가적으로 지원합니다.

LevelDB 및 CouchDB는 키 가져 오기 및 설정 (자산)과 키 기반 쿼리와 같은 핵심 체인 코드 작업을 지원합니다. 키는 범위별로 쿼리 할 수 ​​있으며 복합 키는 여러 매개 변수에 대해 등가 쿼리를 사용할 수 있도록 모델링 할 수 있습니다. 예를 들어 (owner, asset_id)의 복합 키를 사용하여 특정 엔티티가 소유 한 모든 자산을 조회 할 수 있습니다. 이러한 키 기반 쿼리는 원장에 대한 읽기 전용 쿼리와 원장을 업데이트하는 트랜잭션에 사용할 수 있습니다.

자산(Asset)을 JSON으로 모델링하고 CouchDB를 사용하는 경우 체인 코드 내의 CouchDB JSON 쿼리 언어를 사용하여 체인 코드 데이터 값에 대해 복잡한 리치 쿼리를 수행 할 수도 있습니다. 이러한 유형의 쿼리는 원장의 내용을 이해하는 데 탁월합니다. 이러한 유형의 쿼리에 대한 제안 응답은 일반적으로 클라이언트 응용 프로그램에 유용하지만 일반적으로 주문 서비스에 대한 트랜잭션으로 제출되지는 않습니다. 실제로 패브릭은 결과 세트가 풍부한 쿼리의 경우 체인 코드 실행과 커밋 시간 사이에 안정적이라는 것을 보장하지 않으므로 응용 프로그램이 결과 집합이 체인 코드 실행 시간과 안정성을 보장 할 수없는 한 풍부한 쿼리가 업데이트 트랜잭션에 사용하기에 적합하지 않습니다. 커밋 시간, 또는 후속 트랜잭션의 잠재적 변경을 처리 할 수 ​​있습니다. 예를 들어, Alice가 소유 한 모든 자산에 대해 풍부한 쿼리를 수행하고이를 Bob으로 전송하는 경우 체인 코드 실행 시간과 커밋 시간 사이에 다른 트랜잭션으로 Alice에 새 자산을 할당 할 수 있습니다.이 '팬텀'항목을 놓치게됩니다.

CouchDB는 피어와 함께 별도의 데이터베이스 프로세스로 실행되므로 설정, 관리 및 작업과 관련하여 추가 고려 사항이 있습니다. 기본 임베디드 LevelDB로 시작하는 것을 고려해 볼 수 있으며 추가로 복잡한 리치 쿼리가 필요한 경우 CouchDB로 이동하십시오. 체인 코드 자산 데이터를 JSON으로 모델링하는 것이 좋습니다. 그러면 나중에 필요할 경우 복잡한 리치 쿼리를 수행 할 수 있습니다.

CouchDB를 상태 데이터베이스로 사용하려면 /fabric/sampleconfig/core.yaml stateDatabase 섹션을 구성하십시오.