[Blockchain] Fabric Gateway API, Transaction 제출 과정을 단순화
포스트 난이도: HOO_Senior
# Fabric Gateway, Hyperledger Fabric v.2.4
몇 년 전까지만 해도 하이퍼레저 패브릭 (Hyperledger Fabric)을 사용하는데 그다지 친근하지는 않았었다. 아무래도 여러 레이어들이 연결되다 보니 특정 하나의 버전만 달라져도 에러가 발생할 수 있는 경우들이 많았다. 이 외에도 많은 기능들을 직접 연결하고 작업을 해야 하다 보니 초심자에게 있어서는 접근하기 여간 쉽지 않은 부분이 있었다. 미국의 경우 각 주마다 IBM 블록체인 개발자 커뮤니티와 세미나가 존재하고 있지만 문제가 발생했을 때 서로 의견을 공유할 뿐 문제는 본인이 해결해나가야 했다.
아무튼 하이퍼레져 패브릭 2.4 버전 이후에 새롭게 업데이트된 패브릭 게이트웨어 (Fabric Gateway) API를 통해서 그전까지 있어왔던 에러 문제들을 다소 해소해주고 있다. 기존 클라이언트 SDK가 담당하던 트랜잭션 제출 및 검증 과정이 해당 API를 통해서 간소화되고 통합되다 보니 이마저도 감사할 따름이다.
하지만 아무래도 이전 버전의 하이퍼레져패브릭은 사용이 안되거나 에러가 발생할 수 있는 요소들이 있기에 혹시라도 이전 버전의 패키지나 솔루션을 사용하고 있다면 이 점을 유의해서 해당 API를 써야 한다. 솔직히 말해서 예전 버전은 더 이상 하이퍼레저에서도 서비스를 하지 않고 있으니, 최신 버전 트렌드에 맞춰 나아가야 하기에 선택의 여지가 많은 건 아니다. 이 말인즉슨, 해당 API도 추후 버전 업이 되면서 사용의 한계점이 발생할 수 있는 여지는 남아 있으니 이 점도 유의해야 한다.
# Fabric Gateway 특징
패브릭 게이트웨이 API의 가장 큰 특징은 클라이언트가 직접 여러 조직의 피어(Peers)와 상호작용하지 않고도 트랜잭션을 제출할 수 있다는 점이다. 예를 들어서 아래와 같이 다섯 가지 기능을 살펴볼 수가 있다.
- Evaluate Transaction: 체인코드 함수 호출을 통해 원장 (Ledgers)의 상태를 확인할 수 있다.
- Endorse Transaction: 승인 또는 검증 방법에 따라 필요한 Org. 또는 조직들의 피어에서 승인 서명을 수집할 수 있다.
- Submit Transaction: Approval이 난 Transaction에 대해 Ordering을 통해서 Ledgers에 기록이 가능하다.
- Comit Status Check: 트랜잭션이 원장에 성공적으로 기록되었는지 확인이 가능하다.
- Chaincode Events: 스마트 계약이 원장에 기록되었을 때 발생하는 이벤트 확인이 가능하다.
한마디로 기존 하이퍼레저 클라이언트 SDK에서는 Transaction에 대해서 직접 제출을 했어야 한다. 더 간단하게 말해서 위의 Transaction submit 관련 기능들에 대해서 표준화가 되어 있지 않고 개발자가 특성에 맞게끔 직접 기능을 작성해서 사용해 왔다.하지만 이런 Fabric gateway를 통해서 Hyperledger Application이 훨씬 편해졌다는 것이다.
간단한 이전 버전의 Fabric SDK 예시를 살펴보자면, 아래와 같다.
const contract = network.getContract('mychaincode');
const transaction = contract.createTransaction('myFunction');
// 특정 피어를 직접 지정해야 함
transaction.addEndorsingPeer(peer1);
transaction.addEndorsingPeer(peer2);
// 승인(Endorse) 요청
const endorsedTransaction = await transaction.submit();
위의 예제 코드처럼 네트워크에서 사용할 피어를 찾아야 하며, 이에 따라 측정 조직의 피어를 지정하여 트랜잭션을 승인 요청해야 한다. 이후에 승인된 트랜잭션을 직접 Ordering을 통해서 제출하고 Ledger에 제대로 적용이 되었는지를 직접 확인하는 절차를 따른다. 반면에 Fabric Gateway를 사용할 경우 위의 코드가 아래와 같이 단순화된다.
const contract = network.getContract('mychaincode');
// 표준화된 submitTransaction() API 제공
const result = await contract.submitTransaction('myFunction');# Approval Process
Fabric Gateway API에서 트랜잭션이 단순화되었다는 것은 아래와 같은 방식의 프로세스를 거쳐서 승인 또는 검증이 이뤄지기 때문이다.
- Chaincode endorsement policy: 체인코드를 배포할 때 정의된 정책
- Private data collection policy: 프라이빗 데이터 수집의 기록되는 데이터의 승인 정책
- State-based endorsement policy: 특정 Ledgers state에 대한 개별 승인 정책
# Peers
피어에 있어서도 재미있는 특징 중에 하나가 적절한 피어를 자동으로 선택하여 Transaction이 실행이 된다는 점이다. 선택에 있어서 세 가지 경우가 존재하는데, 동일 조직 내에서 최신 블록을 보유한 피어를 우선 선택한다. 또한 승인 정책을 충족하기 위해 필요한 조직들의 피어를 선택하며, 승인 과정에서 필요한 피어 정보를 Discovery를 통해서 동적 검색이 가능하다.
이 말인즉슨, 특정 조직의 피어에서만 Transaction 승인을 받아야 하는 다음 단계가 진행되도록 설정도 가능하다는 점이다. 예를 들어서 Pivate data가 포함된 트랜잭션의 경우 해당하는 특정 조직에서만 승인받도록 제한이 가능하다. 또한 클라이 어느 애플리케이션이 직접 승인받을 조직을 지정할 수도 있다.
# Errors
마지막으로 에러에 대해서 어떻게 자동으로 재시도를 수행하는지가 중요한데 아래와 같은 세 가지 방법으로 오류처리 메커니즘을 포함하고 있다.
- Retry Attempts: 피어 또는 Ordering 장애 발생 시 다른 노드로 요청 재시도가 이뤄진다.
- Error Handling: 오류 발생 시 조직 ID 한마디로 MSP ID 및 엔드포인트 정보를 포함하여 클라이언트에 반환한다.
- Timeouts: 평가 및 승인 메서드의 gRPC 요청에 대해 설정된 시간 내 응답이 없으면 Timeouts가 발생한다.
# 결론
거두절미하고 감사할 따름이다. 다만 본인 설정하고 연결하는 방식에 따라서 생각지 못한 에러들이 여전히 발생할 수 있다. 다만 마음에 드는 점 하나는 체인코드가 실행될 때 특정 이벤트가 발생하면 이를 클라이언트 애플리케이션에서 감지가 가능하다는 점이다.
뭐 프로그래밍 언에 맞는 이벤트 핸들러가 있다고 하지만 솔직히 말해서 여러 언어를 제공해 봤자 아무래도 정보를 얻을 수 있는 곳이 많지 않다 보니 차라리 언어를 특정해서 하나라도 꾸준히 많은 정보가 안정성을 유지해줬으면 하는 또 다른 욕심이 생긴다.