[Hyperledger Fabric v1.0] 5. ARCHITECTURE(아키텍트): Transaction Flow(거래 흐름)

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

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

 Transaction Flow(거래 흐름)

이 문서는 표준 자산 교환 중에 발생하는 트랜잭션 메커니즘에 대해 설명합니다. 시나리오에는 무를 사고 파는 두 명의 고객 A와 B가 포함됩니다. 이들은 각각 네트워크를 통해 거래를 보내고 원장과 상호 작용하는 동료를가집니다.

Assumptions(가정)

이 플로우는 채널이 설정되어 실행 중이라고 가정합니다. 응용 프로그램 사용자는 조직의 인증 기관 (CA)을 등록 및 등록하고 네트워크 인증에 필요한 필수 암호화 자료를 다시 수신합니다.

무 코드 시장의 초기 상태를 나타내는 일련의 키 값 쌍을 포함하는 체인 코드가 피어에 설치되고 채널에 인스턴스화됩니다. 체인 코드는 일련의 거래 지시 사항과 무에 대해 합의 된 가격을 정의하는 로직을 포함합니다. 이 체인 코드에 대한 보증 정책이 설정되어있어 peerA와 peerB가 트랜잭션을 보증해야한다는 것을 나타냅니다.

1. 클라이언트 A, 트랜잭션 시작

무슨 일이야? - 고객 A가 무를 구입하라는 요청을 보냈습니다. 요청은 각각 클라이언트 A와 클라이언트 B를 대표하는 peerA와 peerB를 대상으로합니다. 보증 정책은 두 피어가 모든 트랜잭션을 보증해야한다는 것을 나타내므로 요청은 peerA와 peerB로 이동합니다. 다음으로 거래 제안이 구성됩니다. 지원되는 SDK (노드, 자바, 파이썬)를 활용하는 애플리케이션은 트랜잭션 제안서를 생성하는 사용 가능한 API 중 하나를 사용합니다. 제안은 체인 코드 기능을 호출하여 데이터를 판독기에 쓰거나 쓰기 (즉, 자산에 대한 새로운 키 값 쌍 작성) 할 수 있도록하는 요청입니다. SDK는 트랜잭션 제안서를 적절하게 설계된 형식 (gRPC를 통한 프로토콜 버퍼)으로 패키지화하기위한 shim 역할을하며 사용자의 암호화 자격 증명을 사용하여이 트랜잭션 제안서의 고유한 서명을 생성합니다.

2. 피어를 인증하고 트랜잭션을 실행하는 것을 보증하는 피어

(1) 거래 제안서가 잘 형성되었는지

(2) 과거에 제출되지 않았는지 (재생 공격 보호)

(3) 서명이 유효한지 (MSP 사용)

(4) 제출자 (예 : 클라이언트 A)가 해당 채널에서 제안 된 작업을 수행 할 수 있도록 적절한 권한을 부여 받았음을 나타냅니다. (즉, 각 인증 피어는 제출자가 채널의 작성자 정책을 충족하는지 확인합니다)

{MSP는 클라이언트에서 도착한 거래 요청을 확인하고 거래 결과 (보증)에 서명 할 수있는 피어 구성 요소입니다. * 쓰기 정책은 채널 생성시 정의되며 해당 채널에 트랜잭션을 제출할 수있는 사용자를 결정합니다.} *

3. 제안 응답 검사

응용 프로그램은 승인 피어 서명을 확인하고 제안 응답 (페이로드 표현을 포함 할 용어 용어에 대한 링크)을 비교하여 제안 응답이 동일하고 지정된 보증 정책이 충족되었는지 확인합니다 (예 : peerA 및 peerB 양측지지). 응용 프로그램이 응답을 조사하지 않거나 다른 방법으로 전달되지 않은 트랜잭션을 전달하는 경우에도 정책은 여전히 ​​동료와 시행 확인 단계에서 유지됩니다.

4. 클라이언트가 보증을 트랜잭션으로 어셈블

응용 프로그램은 거래 제안서와 응답을 "거래 메시지"내에서 주문 서비스로 "방송"합니다. 트랜잭션에는 읽기 / 쓰기 세트, 승인 피어 서명 및 채널 ID가 포함됩니다. Ordering Service는 트랜잭션을 수행하기 위해 트랜잭션의 전체 내용을 검사 할 필요가 없으며 네트워크의 모든 채널에서 트랜잭션을 수신하고 채널별로 시간순으로 순서를 지정하며 채널당 트랜잭션 블록을 생성합니다.

5. 거래가 확인되고 commit 됨

거래 블록은 채널의 모든 피어에게 전달됩니다. 블록 내의 트랜잭션은 보증 정책이 충족되고 트랜잭션 집합에 의해 읽기 집합이 생성 되었기 때문에 읽기 집합 변수에 대한 원장 상태가 변경되지 않았는지 확인하기 위해 유효성이 검사됩니다. 블록의 트랜잭션은 유효하거나 유효하지 않은 것으로 태그가 지정됩니다.

6. 원장 업데이트

각 피어는 블록을 채널의 체인에 추가하고 유효한 트랜잭션마다 쓰기 세트가 현재 상태 데이터베이스에 커밋됩니다. 클라이언트 응용 프로그램에 트랜잭션 (호출)이 체인에 영구적으로 추가되었음을 알리고 트랜잭션의 유효성을 검사했는지 유효하지 않은지 여부를 알리는 이벤트가 생성됩니다.

※ 참고 : 서버 측 흐름과 프로토 버퍼를 더 잘 이해 하려면 스윔 레인 다이어그램을 참조하십시오.