Fabric Gateway

• Hyperledger Fabric v2.4 피어에 도입된 서비스
• Fabric 네트워크에 트랜잭션을 제출하기 위한 간소화된 최소 API를 제공
• 이전 클라이언트 SDK에 배치된 요구 사항(예: 다양한 조직의 피어로부터 트랜잭션 승인 수집)은 피어 내에서 실행되는 Fabric Gateway 서비스에 위임되어 v2.4에서 단순화된 애플리케이션 개발 및 트랜잭션 제출을 가능하게 합니다.

클라이언트 애플리케이션 작성

• Fabric Gateway 클라이언트 API(Go, Node 또는 Java) 중 하나를 사용
• Fabric Gateway( 게이트웨이 라고도 함 )는 다음 트랜잭션 단계를 관리
  • 트랜젝션 제안 평가
    • 단일 피어에서 스마트 컨트렉트(체인코드) 기능을 호출하고 결과를 클라이언트에 반환
    • 일반적으로 원장을 업데이트하지 않고 원장의 현재 상태를 쿼리하는 데 사용
    • 게이트웨이는 게이트웨이 피어와 동일한 조직의 피어를 선택하고 원장 블록 높이가 가장 높은 피어를 선택
    • 게이트웨이 조직에서 사용 가능한 피어가 없으면 다른 조직에서 피어를 선택
  • 트랜젝션 제안 보증
    • 결합된 서명 정책(아래 참조)을 만족시키기에 충분한 보증 응답을 수집
    • 서명을 위해 클라이언트에게 준비된 트랜잭션 봉투를 반환
  • 트렌젝션 제출
    • 서명된 트랜잭션 봉투가 주문 서비스에 전송되어 원장에 커밋
  • 커밋 상태(유효성/무효화) 이벤트 대기
  • 체인코드 이벤트 수신
    • 트랜잭션이 원장에 커밋될 때 스마트 계약 기능에서 발생하는 이벤트에 응답 가능
• Fabric Gateway 클라이언트 API는 Endorse/Submit/CommitStatus 작업을 단일 차단 SubmitTransaction 함수로 결합하여 한 줄의 코드로 트랜잭션 제출을 지원
• 유연한 애플리케이션 패턴을 지원하기 위해 개별 작업을 호출할 수 있습니다.

클라이언트 애플리케이션 API

• 게이트웨이와 해당 클라이언트 API는 클라이언트 애플리케이션 개발자로서 Fabric 네트워크와 연결된 인프라 로직에 대해 걱정할 필요 없이 애플리케이션의 비즈니스 로직에 집중할 수 있도록 설계
• ㄴ=> API는 피어 및 체인코드와 같은 운영 추상화보다는 조직 및 계약과 같은 논리적 추상화를 제공
• 참고 - 분명히 관리 API는 이러한 운영 추상화를 노출하기를 원하지만 이것은 관리 API가 아님

게이트웨이가 트랜잭션 제안을 승인하는 방법

• 트랜잭션이 원장에 성공적으로 커밋되려면 보증 정책을 충족하기 위해 충분한 수의 보증이 필요
• 조직으로부터 보증을 받으려면 peer 중 하나에 연결하고 원장 사본에 대해 트랜잭션 제안을 시뮬레이션(실행).
• 피어는 제안의 이름과 인수로 지정된 대로 체인코드 함수를 호출하고 읽기-쓰기 세트를 빌드(및 서명)하여 트랜잭션을 시뮬레이션
• 읽기-쓰기 세트에는 현재 원장 상태와 해당 함수의 상태 가져오기/설정 명령에 대한 응답으로 제안된 변경 사항이 포함
• 트랜잭션에 적용되는 하나이상의 보증정책은 호출되는 체인코드 기능의 구현에 따라 다름.
  • 체인코드 보증 정책
    • 채널 구성원이 조직에 대한 체인코드 정의를 승인할 때 동의한 정책
    • 체인코드 함수가 다른 체인코드의 함수를 호출하는 경우 두 정책을 모두 충족해야 함.
  • 개인 데이터 수집 승인 정책
    • 체인코드 함수가 개인 데이터 컬렉션의 상태에 쓰는 경우 해당 컬렉션에 대한 보증 정책이 해당 상태에 대한 체인코드 정책을 재정의
    • 체인코드 기능이 개인용 데이터 콜렉션에서 읽는 경우 해당 콜렉션의 구성원인 조직으로 제한
  • state 기반 보증(SBE) 정책.
    • key-level signature 정책이라고도 함
    • 개별 상태에 적용할 수 있으며 개인 데이터 수집 상태에 대한 체인코드 정책 또는 수집 정책을 재정의
    • 보증 정책 자체는 원장에 저장되며 새 transactions으로 업데이트 가능
• 트랜잭션 제안에 적용할 보증 정책의 조합은 체인코드 런타임에 결정
• Fabric Gateway는 다음 프로세스를 사용하여 클라이언트를 대신하여 트랜잭션 보증의 복잡성을 관리
  • 게이트웨이 피어의 조직(MSP ID)에서 원장 블록이 가장 많은 피어를 보증 피어로 선택
    • 게이트웨이 피어 조직 내의 모든 피어는 게이트웨이 피어에 연결하는 클라이언트 애플리케이션에서 신뢰한다고 가정
  • 트랜잭션 제안은 선택된 보증 피어에서 시뮬레이트
    • 이 시뮬레이션은 액세스된 상태에 대한 정보와 결합할 보증 정책(보증 피어의 원장에 저장된 개별 상태 기반 정책 포함)을 캡처
  • 캡처된 정책 정보는 ChaincodeInterest protobuf 구조로 조립되고 제안된 트랜잭션에 특정한 승인 계획을 도출하기 위해 검색 서비스로 전달
  • 게이트웨이는 계획의 모든 정책을 충족하는 데 필요한 조직의 보증을 요청하여 보증 계획을 적용.
    • 각 조직에 대해 게이트웨이 피어는 원장 블록이 가장 많은 피어의 보증을 요청
• 게이트웨이는 사용 가능한 피어와 주문 서비스 노드 모두의 연결 세부 정보를 가져옴
• 트랜잭션 제안을 보증하는 데 필요한 피어 조합을 계산하기 위해 검색 서비스에 의존
• ㄴ=> 검색 서비스는 게이트웨이 서비스가 활성화된 피어에서 항상 활성화된 상태로 유지
• 게이트웨이 보증 프로세스는 모든 조직의 동료에게 전달해서는 안 되는 민감한 개인 정보를 포함하는 경우가 많기 때문에 임시 데이터로 제안에 전달된 개인 데이터에 대해 더 제한적
  • 이 경우 게이트웨이는 보증 조직 집합을 액세스할(읽기 또는 쓰기) 개인 데이터 컬렉션의 구성원으로 제한
  • 임시 데이터에 대한 이 제한이 보증 정책을 충족하지 않는 경우 게이트웨이는 개인 데이터에 액세스할 수 있는 권한이 없는 조직에 개인 데이터를 전달x -> 클라이언트에 오류를 반환
  • ㄴ 트랜잭션을 승인해야 하는 조직을 명시적으로 정의하도록 클라이언트 애플리케이션을 작성

특정 보증 피어 대상 지정

• 경우에 따라 클라이언트 애플리케이션은 트랜잭션 제안을 평가하거나 승인할 조직을 명시적으로 선택
  • ex) 일시적인 데이터에는 종종 개인 데이터 컬렉션에만 기록되어야 하는 개인 정보 또는 민감한 정보가 포함되어 있으므로 보증 조직의 영역이 제한됨.
    • ㄴ 이러한 경우 클라이언트 응용 프로그램은 응용 프로그램의 개인 정보 보호 및 보증 요구 사항을 모두 충족하도록 보증 조직을 명시적으로 지정 가능
    • ㄴ-> 게이트웨이는 지정된 각 조직에서 블록 수가 가장 많은 승인 피어를 선택
    • if 클라이언트가 보증 정책을 충족하지 않는 조직 집합을 지정하는 경우, 트랜잭션은 지정된 peer에 의해 보증되고 ordering을 위해 제출될 수 있지만, 나중에 유효성 검사 및 커밋 단계에서채널의 모든 피어에 의해 트랜잭션이 무효화 됨.
    • ㄴ-> 이 무효화된 트랜잭션은 원장에 기록되지만 트랜잭션의 업데이트는 채널 피어의 상태 데이터베이스에 기록되지 않음.
  
  

재시도 및 오류 처리

재시도

• 게이트웨이는 검색 서비스 정보를 사용하여 사용할 수 없는 피어 또는 주문 노드로 인해 실패한 트랜잭션을 재시도
• 조직이 여러 피어 또는 ordering 노드를 실행 중인 경우 다른 알맞은 노드가 시도
• 조직이 거래 제안을 승인하지 못하면 다른 제안이 선택
• 조직이 완전히 보증하지 못하면 보증 정책을 충족하는 다른 조직 그룹이 대상이 됨.
• 보증 정책을 만족하는 사용 가능한 피어 조합이 없는 경우에만 게이트웨이가 재시도를 중지
• 게이트웨이는 승인 피어의 가능한 모든 조합이 한 번 시도될 때까지 재시도를 계속 함.

오류 처리

• Fabric Gateway는 네트워크 피어 및 주문 노드에 대한 gRPC 연결을 관리
• 게이트웨이 서비스 요청 오류가 네트워크 피어 또는 ordering 노드(예: 게이트웨이 외부)에서 발생한 경우, 게이트웨이는 오류, 엔드포인트, 조직(MSP ID) 정보를 메시지 세부 정보 필드의 클라이언트에 반환
• 세부 정보 필드가 비어 있으면 오류가 게이트웨이 피어에서 발생한 것

타임아웃

• Fabric Gateway Evaluate 및 Endorse 메서드는 게이트웨이 외부의 피어에 gRPC 요청
• 클라이언트가 이러한 모든 응답을 기다려야 하는 시간을 제한하기 위해 타임 아웃을 검
• 피어 core.yaml 구성 파일의 게이트웨이 섹션에서 peer.gateway.endorsementTimeout 값을 재정의 가능
• 위와 같이 Fabric Gateway Submit 메서드는 승인된 트랜잭션을 브로드캐스트하기 위해 주문 서비스 노드에 gRPC 연결 생성
• 개별 주문 노드가 응답할 때까지 클라이언트가 기다려야 하는 시간을 제한
• 피어 core.yaml 구성 파일의 게이트웨이 섹션에서 peer.gateway.broadcastTimeout 값을 재정의 가능
• Fabric Gateway 클라이언트 API는 또한 클라이언트 애플리케이션에서 호출될 때 각 게이트웨이 메서드에 대한 기본 및 호출별 시간 초과를 설정하기 위한 메커니즘을 제공.

이벤트 수신

• 게이트웨이는 클라이언트 애플리케이션에서 체인코드 이벤트를 수신하기 위해 클라이언트 애플리케이션에 간소화된 API를 제공
• 클라이언트 API는 언어별 관용구를 사용하여 이러한 이벤트를 처리하는 메커니즘을 제공
  
  

출처
패브릭 게이트웨이